Method and Apparatus for Channel Traffic Congestion Avoidance in a Mobile Communication System

Abstract

Embodiments of the invention provide apparatus, a method and a computer readable product for avoiding traffic congestion in a mobile communication system. In an exemplary embodiment there is provided an apparatus, including at least one controller and a memory storing a computer program which are arranged to receive and read a series of blocks on a first channel, to determine whether there is congestion on the basis of said series of blocks, and, in the event that the determination is that there is no congestion, to transmit a channel request on a second channel.

Description

TECHNICAL FIELD

Embodiments of the invention relate to mobile communications networks, and in particular to channel traffic congestion detection and management in a mobile communication system.

BACKGROUND

In mobile communication systems a cell is managed by a base station, BS. Any communication traffic in or out of or within the cell is routed via the BS. The communication is usually sent along a number of channels, each channel being assigned to control or data traffic of a particular kind. One example is the Broadcast Control Channel, BCCH, used by a BS to provide a mobile node or Mobile Station, MS, in the cell with control information. Other examples include the Common Control Channel, CCCH, comprising of paging, random access, access grant and notification channels used for control signaling during connection establishment.

At times when many MSs are trying to communicate at the same time in a cell, the control or data traffic can become higher than the BS is capable of handling and the data channels that are used then become congested. In practice this means that some of the mobile station's (MSs) traffic will not be handled in a timely manner. Congestion may occur on uplink channels (RACH) or on downlink channels.

To enable devices to communicate freely even under heavy data or control traffic a protocol has been developed wherein a MS has to require a data channel access before starting to communicate. In a system such as the GERAN (GSM EDGE Radio Access Network, GSM—Global System for Mobile communication, EDGE—Enhanced Data rates for GSM Evolution) mobile stations have to send a CHANNEL REQUEST message or an EGPRS CHANNEL REQUEST message on a channel named RACH (Radio Access Channel). If the BS is able to handle the communication a message is sent out granting access on a channel named AGCH (Access Granted CHannel). If the BS is not able to handle the communication, a message rejecting the access is sent out on the same channel. The BS may fail to correctly receive the RACH message e.g. if simultaneous RACH messages collide or if the radio link quality is not sufficient. In this case no response is sent to the mobile station at all. Should such a response not be received a MS would resend the request over the RACH. However, during periods of congestion, these requests lead to increased control traffic and therefore add to the congestion. It should be noted that congestion may occur on either of an upload channel and a download channel or on both.

Therefore, it would be beneficial to control the access requests so as not to burden the base stations unnecessarily and thereby alleviate the congestion in a cell.

A procedure during which the MS requests resources for control or data traffic is commonly known as the random access procedure. The MS initiates the random access procedure by transmitting a request message. When the MS sends a request message such as a CHANNEL REQUEST message or an EGPRS CHANNEL REQUEST message on a channel named RACH, the MS expects to receive a response from the BS within a given time derived from broadcast parameters. The MS is not allowed to retransmit the request earlier than this time. The BS may not respond to the request message due to one of the following reasons. Firstly, because the request message was not received correctly due to the congestion on the RACH channel or due to poor link conditions. Secondly, because the BS cannot send the response within the time constraints due to the congestion on a channel named AGCH. In either case the random access procedure is delayed by the waiting time between the retransmissions of the request messages.

It would be beneficial to estimate the cause of delay in the BS response and allow for shorter waiting time between the retransmissions of the request messages (i.e. faster random access procedure) if the estimation suggests the cause of the delay is an incorrect reception of the request message due to poor link conditions.

SUMMARY

In a first exemplary embodiment there is provided an apparatus comprising at least one controller arranged to: receive and read a series of blocks on a first channel; determine whether there is congestion on the basis of said series of blocks; and, in the event that the determination is that there is no congestion, transmit a channel request on a second channel. The apparatus may be embodied as or within a user equipment such as a mobile handset. In one embodiment, the apparatus is a chip or chipset (eg. an integrated circuit or a programmed processor).

In one arrangement to be used in a GERAN system the first channel is the ACCESS GRANTED CHANNEL, AGCH, and the second channel is the REQUEST ACCESS CHANNEL, RACH.

In a second exemplary embodiment, there is provided a method reading a series of blocks on a first channel; determining, on the basis of said series of blocks, whether there is congestion; if the determination is that there is congestion, waiting; and if the determination is that there is no congestion, transmitting a channel request on a second channel.

In a third exemplary embodiment, there is provided a radio network node such as a base station which comprises at least one processor configured to broadcast a waiting time.

In a further exemplary embodiment, there is provided a radio network node such as a base station, said base station comprising at least one processor configured to set a congestion flag based on a queue length on a first channel and include the flag in an assignment message to be transmitted.

The aforementioned base station and/or an apparatus according to the above embodiments may be implemented within a mobile communication system.

According to a further exemplary embodiment, there is provided an apparatus comprising at least one controller arranged to transmit a channel request on a second channel and to receive and read a series of blocks on a first channel so as to determine whether there is congestion, and if not, retransmitting a channel request on the second channel. The apparatus may be embodied as or within a user equipment such as a mobile handset. In one embodiment, the apparatus is a chip or chipset (eg. an integrated circuit or a programmed processor).

In a further exemplary embodiment, there is provided a computer program comprising code comprising a set of instructions, which, when executed by a data-processing system, causes the data processing system to: read a series of blocks on a first channel; determine whether there is congestion on the basis of the series of blocks; and in the event that the determination is that there is no congestion, to transmit a channel request on a second channel.

In one embodiment, the computer program product is stored on a computer readable medium. The computer readable medium may be, but is not limited to, a removable memory card, a removable memory module, a magnetic disk, an optical disk, a holographic memory or a magnetic tape. A removable memory module may be, for example, a USB memory stick, a PCMCIA card or a smart memory card.

It should be noted that congestion may occur on either of an upload channel and a download channel or on both or on a channel for both upload and download and the teachings herein apply equally to these different arrangements.

The teachings herein facilitate a reduction in congestion on data traffic channels by enabling user equipment to monitor the traffic on the channels and only make requests when there is no congestion.

A further benefit is that priority is given to some devices either requiring lower priority devices to adhere to the processes described herein or by giving lower priority devices longer waiting times.

Furthermore, a user equipment, when configured with an apparatus according to the first exemplary embodiment, may be dynamically informed of the congestion status by a base station or other network component.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are included to provide a further understanding and constitute a part of this specification, illustrate embodiments and together with the description help to explain the principles. In the drawings:

FIG. 1a is a block diagram illustrating an apparatus according an embodiment according to the teachings herein;

FIG. 1b is a block diagram illustrating an apparatus according an embodiment according to the teachings herein;

FIG. 2a is a flowchart according to an embodiment of a method discussed herein;

FIG. 2b is a flowchart according to an embodiment of a method discussed herein;

FIG. 2c is a flowchart according to an embodiment of a method discussed herein;

FIG. 2d is a flowchart according to an embodiment of a method discussed herein;

FIG. 2e is a flowchart according to an embodiment of a method discussed herein;

FIG. 2f is a flowchart according to an embodiment of a method discussed herein;

FIG. 2g is a flowchart according to an embodiment of a method discussed herein;

FIG. 2h is a flowchart according to an embodiment of a method discussed herein.

FIG. 2i is a flowchart according to an embodiment of a method discussed herein.

DETAILED DESCRIPTION

Reference will now be made in detail to the embodiments of the present invention, examples of which are illustrated in the accompanying drawings.

FIG. 1a is a block diagram illustrating an apparatus according to an embodiment. The apparatus comprises at least one controller 100, such as a processor, a memory 110 and a communication interface 120. In one embodiment the apparatus is a computer chip. In the memory 110 computer instructions are stored which are adapted to be executed on the processor 110. The communication interface 120 is adapted to receive and send information to and from the processor 100. FIG. 1a is an example embodiment of an ASIC.

FIG. 1b is an example embodiment of a mobile station including an apparatus according to an embodiment; in addition to the components shown in FIG. 1a, the mobile station comprises a radio frequency interface 125 for communicating between apparatuses and a man-machine interface (MMI) 126 for communicating between the apparatus and a user. Such an MMI may include a touch pad, a display, a keypad, audio in and output and/or a touch display as are known (not shown). The mobile station further comprises an antenna 130 and a second memory 140 that comprises user applications such as a message handling application, a voice call handling application, a text editor, an internet browser application and drivers for further devices to be connected to or incorporated in the apparatus, such as a camera module for example. In one embodiment memories 110 and 140 are incorporated within the same memory module.

The apparatus may, for example, be a mobile node, user equipment, cellular phone, a mobile terminal, an Application Specific Integrated Circuit (ASIC), an Integrated Chip (IC) or any chip.

The apparatus is adapted to be part of a radio network. The network may be a GSM-Edge Radio Access Network (GERAN). The network may also be any cellular radio access network such as, for example, an E-UTRAN or a UMTS Terrestrial Radio Access Network (UTRAN). Such a system comprises a number of base stations each handling a cell. At least one User Equipment, UE, is part of a cell and its mobility is handled by the cell's base station. A UE may be mobile and is thus able to move between cells.

FIG. 2 shows a series of flow charts each according to an embodiment of the teachings herein; in the description below, the User Equipment is alternatively referred to as a Mobile Station MS and User Equipment UE.

In the arrangement shown in FIG. 2a, a MS detects if there is congestion 210. If there is no congestion the MS proceeds with sending a CHANNEL REQUEST message or an EGPRS PACKET CHANNEL REQUEST message on a Request Access Channel, RACH 250. If there is congestion the MS waits 260 and then again detects if there is congestion 210.

An apparatus of the MS is configured to determine if a network node, such as a base station, BS, has received a request message, namely the foregoing RACH message, from the MS, and if such a message has been received then the apparatus is configured to apply a random delay or waiting time before repeating the RACH transmission.

Alternatively, an apparatus of the MS is configured to determine if a network node, such as a base station, BS, has received a request message, namely the foregoing RACH message, from the MS, and if such a message has not been received then the apparatus is configured to apply a shorter random delay or waiting time before repeating the RACH transmission.

The apparatus may also be configured to determine if a network node, such as a base station, BS, has received a request message, namely the foregoing RACH message, from the MS, if congestion is detected.

This avoids unnecessary delays when there is no congestion.

In the following reference will be made to FIGS. 1 and 2 simultaneously as the apparatus of FIG. 1 is adapted to execute the method of FIG. 2.

In the embodiment shown in FIG. 2b, the controller 100 of the apparatus is configured to detect that there is congestion 210 by receiving through the communication interface 120 a series of blocks 220 that have been transmitted on a channel, such as the AGCH. In a system such as a GERAN system it is possible to detect whether there is congestion by monitoring the AGCH channel as, if there is not enough traffic to fully utilize the capacity of the BS, the BS will transmit blocks with L2 fill frames.

In one embodiment the processor therefore reads or decodes the blocks 220 being transmitted and counts the number of L2 fill frames 225. If the number of fill frames is 0 (zero) there is congestion.

The series of blocks has a length of N and in one embodiment N is in the range 3 to 15. In alternative embodiments N may be in the range of 2 to 4, take the value of 3, of 5 or of 10. In such an embodiment the controller 100 is free to perform other tasks when there is congestion after having decoded the N blocks. It should be noted that longer series provide for a more accurate determination of the congestion, but also take a longer time to decode. A tradeoff of which parameter to prioritise is a matter for a system designer.

In one embodiment the series of blocks does not have a specified length, but the controller is configured to read blocks until a L2 fill frame is detected. This enables the processor to start transmitting the channel request message as soon as it is detected that there is no congestion. However, this may result in the controller becoming occupied in reading many blocks unnecessarily if there is congestion, i.e. the processor 100 keeps decoding until the congestion is dissolved. In such an embodiment step 260 described with reference to FIG. 2 is not needed.

In the embodiment shown in FIG. 2c, the controller 100 is further configured to count 230 the number of assignment messages such as IMMEDIATE ASSIGNMENT messages and IMMEDIATE ASSIGNMENT REJECT messages that are decoded or read in the series of blocks having been read 220. In this embodiment the controller is configured to determine a ratio between the L2 fill frames and the IMMEDIATE ASSIGNMENT messages and IMMEDIATE ASSIGNMENT REJECT messages 235. If this ratio is below a threshold value T then it is determined that there is no congestion.

In one embodiment the threshold value T takes a value in the range of 1 to 3. In other embodiments the threshold value T may be 1:9 1:3 or 2:5.

In one embodiment the IMMEDIATE ASSIGNMENT messages and/or IMMEDIATE ASSIGNMENT REJECT messages comprises a congestion flag (a 1 bit logical marker) which is set (the bit is set to 1 in one embodiment) by a base station if there is congestion and not set (the bit is set to 0 in one embodiment) if there is no congestion.

In the embodiment shown in FIG. 2d the controller is adapted to read a series of blocks 220 and determine 240 if a block contains a congestion flag which is set if there is congestion and if a block contains a congestion flag which is not set if there is no congestion.

The series of blocks has a length of N and in one embodiment N is in the range 3 to 15. In alternative embodiments N may be in the range of 2 to 4, take the value of 3, of 5 or of 10. In such an embodiment the controller 100 is free to perform other tasks when there is congestion after having decoded the N blocks.

In one embodiment the series of blocks does not have a specified length, but the controller is configured to read blocks until a not set congestion flag is detected. This enables the processor to start transmitting the channel request as soon as it is detected that there is no congestion. However, this may result in the controller becoming occupied in reading many blocks unnecessarily if there is no congestion, i.e. the processor 100 keeps decoding until the not set congestion bit is received.

By having a congestion flag, the apparatus is enabled to be dynamically informed of the congestion status by a network node such as a base station or other network component.

In one such embodiment a network node such as a base station or other network component is configured to set the congestion flag based on the current queue length for the AGCH.

In one such embodiment a network node such as a base station or other network component is configured to set the congestion flag more accurately based on implementation specific criteria that include other factors such as the packet utilization.

The controller 100 may be configured to determine the waiting time based on the number of channels and/or their availability; additionally or alternatively the controller 100 may be configured to employ a statistical analysis of the channel usage to predict when congestion is about to arise and/or to dissolve to determine a waiting time.

In one such embodiment a network node such as a base station or other network component is configured to set the congestion flag more accurately based on a combination of implementation specific criteria that includes other factors such as the packet channel utilization and the current queue length for the AGCH.

The process of checking for congestion may be run in the background such that the apparatus does not need to perform a congestion check each time a channel is to be requested, as the apparatus is notified of the congestion status by the base station. A copy of the congestion flag may be stored in the memory 110 of the apparatus for quick and easy reference.

FIG. 2e shows a combination of the embodiments above as has been described with reference to FIGS. 1, 2a, 2b, 2c, and 2d.

In one embodiment the controller 100 is configured to wait between attempts to determine whether there is congestion or not.

The step of waiting (260) may involve the apparatus waiting a pre-determined time period WT before making another attempt to detect the congestion. The time to wait WT may be standard specific. As will be appreciated, if the time to wait WT is set to zero (0) the controller 100 is configured to continuously read blocks until it is detected that there is no congestion.

In the embodiment shown in FIG. 2f, the controller 100 is configured to listen to a broadcast channel, such as a Broadcast Control Channel, BCCH, on which a base station is transmitting a waiting time WT 252. In such an embodiment a base station is configured to broadcast a waiting time WT. This enables a base station to control how long different MSs are to wait and thus allow the base station to both control the traffic on the channels (reducing unnecessary attempts) and order a further priority scheme among devices (lower priority devices get longer waiting times).

The controller 100 may be configured to determine a waiting time WT based on other broadcast parameters related to non-congested behavior such as time between request retransmission and maximum allowed number of retransmissions

In the embodiment shown in FIG. 2g, the controller 100 is configured to increase the waiting time WT in accordance with the number of times that an attempt to detect congestion has been made, step 254. The waiting time may increase linearly with the number of attempts, for example through a formula such as:

WT=number of attempts*Constant.

In an alternative embodiment the controller 100 may be configured to base the waiting time on a geometric series.

In a yet further embodiment the waiting time may increase non-linearly with the number of attempts, for example through a formula such as:

WT=Constant ̂ number of attempts.

In the embodiment shown in FIG. 2h, the controller 100 is configured to increase the waiting time WT with the number of IMMEDIATE ASSIGNMENT and/or IMMEDIATE ASSIGNMENT REJECT messages received 256. The waiting time may increase linearly with the number of messages received, for example through a formula such as:

WT=number of messages*Constant.

In an alternative embodiment the controller 100 may be configured to base the waiting time on a geometric series.

In the embodiment shown in FIG. 2i, the controller 100 is configured to set the waiting time WT to a random number 258. This improves the synchronization of many UEs simultaneously waiting for congestion to disappear or a new congestion might occur should all waiting UEs send their requests at the same time.

It should be noted that the random element may be added in all embodiments described above. For example, the formula for the waiting time of FIG. 2g becomes

WT=number of attempts*Constant+Random

or

WT=number of attempts*Constant*Random.

The random element may be taken from a range that increases with the number of attempts and/or messages. For example the random element could be taken from the range [constant1, constant2*nbr of attempts].

It should be noted that in the embodiments above the waiting time is proportionate to one or more parameters of the system, wherein it should be noted that the waiting time is not necessarily directly proportionate to the parameters.

The embodiments described hereinbefore in association with FIGS. 1 and 2 may be used in any combination with each other. Several of the embodiments may be combined together to form a further embodiment.

The exemplary embodiments can be included within any suitable device, for example, including any suitable servers, workstations, PCs, laptop computers, PDAs, Internet appliances, handheld devices, cellular telephones, wireless devices, other devices, and the like, capable of performing the processes of the exemplary embodiments, and which can communicate via one or more interface mechanisms, including, for example, Internet access, telecommunications in any suitable form (for instance, voice, modem, and the like), wireless communications media, one or more wireless communications networks, cellular communications networks, 3G communications networks, 4G communications networks Public Switched Telephone Network (PSTNs), Packet Data Networks (PDNs), the Internet, intranets, a combination thereof, and the like.

It is to be understood that the exemplary embodiments are for exemplary purposes, as many variations of the specific hardware used to implement the exemplary embodiments are possible, as will be appreciated by those skilled in the hardware art(s). For example, the functionality of one or more of the components of the exemplary embodiments can be implemented via one or more hardware devices, or one or more software entities such as modules.

The exemplary embodiments can store information relating to various processes described herein. This information can be stored in one or more memories, such as a hard disk, optical disk, magneto-optical disk, RAM, and the like. One or more databases can store the information used to implement the exemplary embodiments of the present inventions. The databases can be organized using data structures (e.g., records, tables, arrays, fields, graphs, trees, lists, and the like) included in one or more memories or storage devices listed herein. The processes described with respect to the exemplary embodiments can include appropriate data structures for storing data collected and/or generated by the processes of the devices and subsystems of the exemplary embodiments in one or more databases.

All or a portion of the exemplary embodiments can be implemented by the preparation of application-specific integrated circuits or by interconnecting an appropriate network of conventional component circuits, as will be appreciated by those skilled in the electrical art(s).

As stated above, the components of the exemplary embodiments can include computer readable medium or memories according to the teachings of the present inventions and for holding data structures, tables, records, and/or other data described herein. Computer readable medium can include any suitable medium that participates in providing instructions to a processor for execution. Such a medium can take many forms, including but not limited to, non-volatile media, volatile media, transmission media, and the like. Non-volatile media can include, for example, optical or magnetic disks, magneto-optical disks, and the like. Volatile media can include dynamic memories, and the like. Transmission media can include coaxial cables, copper wire, fiber optics, and the like. Transmission media also can take the form of acoustic, optical, electromagnetic waves, and the like, such as those generated during radio frequency (RF) communications, infrared (IR) data communications, and the like. Common forms of computer-readable media can include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, any other suitable magnetic medium, a CD-ROM, CDRW, DVD, any other suitable optical medium, punch cards, paper tape, optical mark sheets, any other suitable physical medium with patterns of holes or other optically recognizable indicia, a RAM, a PROM, an EPROM, a FLASH-EPROM, any other suitable memory chip or cartridge, a carrier wave or any other suitable medium from which a computer can read.

While the present inventions have been described in connection with a number of exemplary embodiments, and implementations, the present inventions are not so limited, but rather cover various modifications, and equivalent arrangements, which fall within the purview of the various embodiments.

The embodiments described hereinbefore in association with FIGS. 1 and 2 may be used in any combination with each other. Several of the embodiments may be combined together to form a further embodiments.

It is obvious to a person skilled in the art that with the advancement of technology, the basic idea may be implemented in various ways. The invention and its embodiments are thus not limited to the examples described above; instead they may vary within the scope of the claims.

Claims

1. An apparatus for use in controlling congestion in a cell of a communications network, the apparatus comprising at least one controller and a memory storing a computer program which are arranged to:

receive and read a series of blocks on a first channel;

determine whether there is congestion on the basis of said series of blocks; and,

in the event that the determination is that there is no congestion, initiate an access procedure by transmitting a channel request on a second channel.

2. The apparatus according to claim 1, the controller with the memory and the computer program being further arranged to: count a number of fill frames and determine if the number of fill frames is greater than zero and if so determine that there is no congestion.

3. The apparatus according to claim 2, the controller with the memory and the computer program being further arranged to: count a number of assignment messages and determine a ratio between the number of fill frames and the assignment messages and determine if the ratio is greater than a threshold value and if so determine that there is no congestion.

4. The apparatus according to claim 1, the controller with the memory and the computer program being further arranged to decode an assignment message, wherein said assignment message comprises a congestion flag, wherein the controller is arranged to determine that there is congestion if the congestion flag is set.

5. The apparatus according to claim 1, wherein the series of blocks has a predetermined length (N).

6. The apparatus according to claim 1, the controller with the memory and the computer program being further arranged to wait for a waiting time before performing another attempt to determine whether there is congestion or not.

7. The apparatus according to claim 6, wherein the waiting time includes a random element.

8. The apparatus according to claim 6, wherein the waiting time is proportionate to the number of attempts to determine whether there is congestion or not.

9. The apparatus according to claim 6, the controller with the memory and the computer program being further arranged to receive the waiting time from a network node, such as a base station.

10. The apparatus according to claim 9, wherein the waiting time is based on at least one implementation specific criterion.

11. A method of controlling congestion in a cell of a communications network, the method comprising:

reading a series of blocks on a first channel;

determining, on the basis of said series of blocks, whether there is congestion;

if the determination is that there is congestion, waiting; and

if the determination is that there is no congestion, initiating an access procedure by transmitting a channel request on a second channel.

12. A method according to claim 11, wherein the method comprises counting a number of fill frames and determining if the number of fill frames is greater than zero, and if so, determining that there is no congestion.

13. A method according to claim 12, wherein the method comprises counting a number of assignment messages and determining a ratio between the number of fill frames and the assignment messages, and determining if the ratio is greater than a threshold value, and if so, determining that there is no congestion.

14. A method according to claim 11, wherein the method comprises decoding an assignment message, wherein said assignment message comprises a congestion flag, and determining that there is congestion if the congestion flag is set.

15. A method according to claim 11, wherein the method comprises waiting for a waiting time before performing another attempt to determine whether there is congestion or not.

16. A memory storing a computer program comprising a set of instructions, which, when executed by a data-processing system, causes the data processing system to:

read a series of blocks on a first channel;

determine whether there is congestion on the basis of the series of blocks; and

in the event that the determination is that there is no congestion, to initiate an access procedure by transmitting a channel request on a second channel.

17. (canceled)

18. The apparatus according to claim 1, the controller with the memory and the computer program being further arranged to determine whether there is congestion based on whether said series of blocks comprises a flag indicating that there is congestion.

19. The apparatus according to claim 18, wherein the flag indicating there is congestion is in at least one of an IMMEDIATE ASSIGNMENT message or an IMMEDIATE ASSIGNMENT REJECT message.

20. The apparatus according to claim 1, wherein the first channel is an access grant channel and the second channel is a random access channel.

21. The method according to claim 11, wherein determining whether there is congestion comprises checking said series of blocks for a flag indicating that there is congestion.

22. The method according to claim 21, wherein the flag indicating there is congestion is in at least one of an IMMEDIATE ASSIGNMENT message or an IMMEDIATE ASSIGNMENT REJECT message.

23. The method according to claim 11, wherein the first channel is an access grant channel and the second channel is a random access channel.

24. The memory according to claim 16, wherein the set of instructions, when executed, causes the data processing system to determine whether there is congestion based on whether said series of blocks comprises a flag indicating that there is congestion.

25. The memory according to claim 24, wherein the flag indicating there is congestion is in at least one of an IMMEDIATE ASSIGNMENT message or an IMMEDIATE ASSIGNMENT REJECT message.

26. The memory according to claim 16, wherein the first channel is an access granted channel and the second channel is a random access channel.