Congestion Control in a Telecommunications Network

[0001] In general, the invention relates to a method and telecommunications network configured to control congestion in a network. More specifically, the invention relates to congestion control in a network used for communication between machines.

BACKGROUND OF THE INVENTION [0002] Telecommunications networks providing wireless access (eg GSM, UMTS, WiMax, LTE) have been significantly improved in recent years. In such networks, voice and data services can be provided on terminals with high mobility, i.e. communication terminals are not limited to a given location and can move freely throughout the entire area covered by the network. A telecommunications network gateway node enables connection to another network, for example an IP-based network such as the Internet.

[0003] The availability of such a telecommunications network connected to another network has forced the use of further services, including those relating to so-called machine-to-machine (M2M) services. M2M applications usually include hundreds, thousands or millions of telecommunications modules, each of which acts as a communication terminal in a telecommunications network. The example includes electronic reading, e.g. "Smart" electricity meters in households, a large customer base using a telecommunications network from a server connected to the next network. Other examples include sensors, gauges, vending machines or coffee machines, etc., which can be equipped with communication modules to send status information to a data center via a telecommunication network. Such devices can also be monitored by the server. For example, the data center can store data and / or create a schedule for maintenance workers who will carry out repairs or fill the machine, meter, sensor, etc.

[0004] The characteristics of some M2M applications are that the frequency of data exchange with the server is low, e.g. once a day, etc. in the case of a smart electricity meter.

[0005] Typically, there is agreement between the telecommunications network operator and the owner / operator of the server or data center regarding communication parameters regarding the owners of any of the communication terminals. For example, the telecommunications parameters relate to the QoS class and the maximum transmission rate that is available for a carrier in a telecommunications network to support data sessions between a given communication terminal and a server or data center. For example, in a GPRS or UMTS telecommunications network, the communication parameters are contained in the PDP Context of the communication terminal. In other networks, e.g. LTE or cable networks, communication parameters are provided in similar contexts.

[0006] It is well known that communication parameters can be controlled using the PCC (policy and charging control) architecture. An example of PCC architecture is described in 3GPP TS 23.203. Regulation control is a known process in communication networks, while the regulation control unit points to the regulation enforcement unit, e.g. how to control media resources, e.g. IP-CAN ( IP Connectivity Access Network. IP-CAN bearers can include bearers in GPRS or UMTS communication networks, EPS bearers in LTE communication networks, DOCSIS service flow in cable communication networks, etc. Control of regulations can be used to control the characteristics of QoS in telecommunications networks.

[0007] Despite the fact that the traffic generated by each communication terminal is within set limits, defined by communication parameters (e.g. PDP Context), and despite the fact that these restrictions are strictly enforced at the moment when the terminal attempts to exceed the intentional limit or not, overloading may occur. For example, when a large number of energy meters, each of which rarely exchanges data with the server, attempts to exchange data with the server at the same time, the connection between the telecommunications network and the server in the next network may be overloaded or overloading may occur in other parts of the telecommunications network . Congestion can occur on both the uplink and downlink, i.e. data sent from terminals to the server or sent from the server to the communication terminals.

[0008] At present, the telecommunications network operator has no means to effectively prevent or control such overloading.

[0009] US 6865185 discloses a method and system for queuing traffic in a wireless network that includes receiving packet streams for transmission in a wireless network. Each packet includes a flow identifier and is assigned to one of many virtual groups based on such identifier. The virtual group includes discrete transmission resources. Each packet is queued in the assigned virtual group for transmission in the wireless network.

[0010] As can be seen, there is a need for a more flexible method of controlling overload. SUMMARY OF THE INVENTION [0011] A method of congestion control in a telecommunications network has been disclosed. The telecommunications network supports one or several active sessions between the server and at least the first and second communication terminals, providing at least the first and second bearers for such terminals. [0012] At least the first and second communication terminals are assigned to a group for which a common identifier is stored group. In addition, the first individual overload parameter for the first carrier and the second individual overload parameter for

- the second medium of the first and second communication terminals are or have been recorded. A group load indicator is defined for the terminal group corresponding to the common group identifier. The group load indicator is monitored and compared with the group load condition for a group of at least the first and second communication terminals corresponding to the common group identifier. The overload is controlled by adjusting at least one of the first individual overload parameter of the first carrier and the second individual overload parameter of the second carrier when the group load identifier satisfies the group load condition.

[0013] The method can be applied to one or several nodes (gateways) of a telecommunications network.

[0014] A computer program implementing the method and a medium comprising such a computer program will also be disclosed. Parts of the program can be distributed in a telecommunications network to perform distributed functions.

[0015] Furthermore, a telecommunications network is disclosed that is configured to allow data sessions between the server and at least the first and second communication terminals, providing at least the first and second bearers. The first storage node of the telecommunications network stores the common group identifier assigned to the group comprising at least the first and second communication terminals. The second storage node, possibly the same node as the first storage node, stores the first individual overload parameter for the first carrier and the second overload parameter for the second carrier with respect to the first and second communication terminals, respectively. A monitoring module is provided that is configured to monitor in the telecommunications network a group load indicator of at least the first and second communication terminals corresponding to the common group identifier. In addition, an analyzer is provided which is configured to compare the group load indicator with the group load condition for a group comprising at least the first and second communication terminals corresponding to a common group identifier. The telecommunications network includes an overload controller configured to control overload by regulating at least the first individual overload parameter of the first carrier and the second individual overload parameter of the second carrier when the group load indicator meets the group load conditions.

[0016] It should be appreciated that the disclosed method and telecommunications network can control congestion occurring in the telecommunications network itself and / or in the subsequent network between the telecommunications network and the server.

[0017] It should also be remembered that the stage of monitoring the group load indicator and the stage of comparing the monitored group load indicator with the group load condition need not necessarily constitute two separate successive stages and can be integrated e.g. into a single stage.

[0018] Furthermore, the communication terminal typically uses a single bearer in the telecommunications network to support one or more data sessions between the communication terminal and the server. The common group identifier may then refer to a communication terminal that corresponds to a one-to-one medium. However, in the case where the communication terminals use more than one bearer, the group identifiers can be assigned based on the bearer, so that a single communication terminal can be assigned to several groups.

[0019] The individual congestion parameters of the group terminals carriers are the congestion communication parameters of the contexts (eg PDP Context) of the individual terminals in the group. An example of an overload parameter includes a (maximum) data rate that is agreed with the carrier. The group load indicator refers to the actually measured load at a specific point in time or period of time for groups of terminals. For example, the group load indicator is a measure of the actual transmission rate used by the terminals, which rate is monitored in the telecommunications network. The group load condition is the condition after which the regulation of the overload parameters of the individual carriers of the group terminals is started. For example, a group load condition includes a group rate threshold. When the monitored actual baud rate of the terminals exceeds the group baud rate threshold, the agreed media overload parameters (at least one or more) of the individual terminals are adjusted. The set overload parameters are then implemented, which avoids or reduces overloading.

[0020] Detecting that the group load condition is met does not necessarily mean that actual overload has occurred. The group overload condition can be defined so that the regulation of the individual overload parameters is started before the overload condition occurs. For example, choosing a lower threshold value as a group load condition can prevent overloading, not just solve it, which would be the case with a higher threshold value.

[0021] Actions to resolve congestion may also include activities other than limiting the maximum transmission rates of individual terminals, including modifying the QoS attributes of one or more terminals. As an alternative, the terminals in the group can be (temporarily) allocated additional bandwidth.

[0022] The disclosed method and telecommunications network, in addition to defining (values) of parameters regarding the capacity of individual communication terminals, allows to define a group load condition for communication terminals belonging to a group identified by a common group identifier. By monitoring the group load indicator of a group of terminals, the group load condition allows the telecommunications network operator to predict overload by comparing the group load indicator with the group load condition and react by adjusting individual parameters of the group overload and implement them to avoid or reduce overload caused by group terminals.

[0023] For example, a telecommunications network operator may define a baud rate threshold for a group of communication terminals. When the baud rate exceeds the group baud rate threshold, the telecommunications network operator has the ability to reduce the agreed baud rate of individual communication terminals to relieve congestion in the telecommunications network.

[0024] The embodiment shown in claim 2 allows overload control of terminals that require access to a telecommunications network. The terminal requiring access to the telecommunications network and assigned to the defined group for which the overload condition is met will be compared with the set individual overload parameter of its own set carrier to avoid or limit the overload that could occur if the new terminal allows access to the network with unset parameter value.

[0025] The embodiment shown in claim 3 provides the advantage of setting the time to adjust individual overload parameters based on the most current data exchange time.

[0026] The embodiment shown in claim 4 allows the recovery of the common identifier of the group to which a given terminal belongs based on the individual identifiers of that terminal. In this form, the common group identifier remains unknown to the terminal. Examples of individual terminal identifiers include IMSI, terminal number, application number, etc.

[0027] The embodiment shown in claim 5 defines that the baud rate is an important parameter for congestion control.

[0028] The embodiment shown in claim 6 provides flexibility to the owner / operator of the M2M server, enabling the assignment of communication terminals to one or several groups and (temporary) adjustment of the individual congestion parameters of one or more communication terminals in the group. The server owner / operator can flexibly regulate (value) the overload parameter of one or more individual terminals in a group until the group overload condition of all communication terminals is met.

[0027] The embodiment shown in claim 7 allows the individual communication terminal to be assigned to multiple groups and to apply various suitable group loading conditions to these groups.

[0030] The embodiment shown in claim 8 allows gradual (e.g. stepwise) adjustment of the parameters of the overload threshold of individual communication terminals of a given group.

[0031] Terminals for which the overload parameters will be or have been adjusted should preferably be informed (e.g. by means of signal messages) about the adjustment of the carrier characteristics, e.g. to reduce the maximum transmission rate for data transmission in the direction of the uplink, as defined in the examples

- the executions given in claims 9-15. Group terminals for which overload parameters are not regulated need not be notified.

[0032] If regulation information is to be transmitted to a significant number of communication terminals, this can lead to significant signal traffic in the network. The embodiments of claims 13 and 16 use a common group identifier. From the common group identifier, you can download individual communication parameters of the group for which the message is intended, in the appropriate (lower) place in the telecommunications infrastructure.

[0033] The embodiment shown in claim 14 further restricting traffic in a telecommunications network defines that information containing a common group identifier is sent in one or several parts of the telecommunications network and is received by communication terminals belonging to the group. In this embodiment, the communication terminals have or have been informed of the common group identifier and use this information to recover a regulation information message that is included in the transmission.

[0034] Hereinafter, embodiments of the invention will be described in greater detail. It should be recognized that these examples do not limit the scope of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS [0035] In the drawings:

FIG. 1 is a diagram of the state of the art telecommunications network connecting communication terminals to a server via another network.

FIG. 2 is a schematic diagram of the state of the art PCC architecture that is used in the telecommunications network shown in FIG. 1;

FIG. 3A and 3B show an individual subscription record and group record according to an embodiment of the invention;

FIG. 4 is a diagram of a telecommunications network according to an embodiment of the invention;

FIG. 5A and 5B show an individual PCC rule and a group rule according to an embodiment of the invention that is used in the congestion control method implemented in the telecommunications network shown in FIG. 4 in combination with the records in FIG. 3A and 3B;

FIG. 6A and 6B are signal flow diagrams showing examples of a telecommunications node providing by a server;

FIG. 7A-7C are diagrams showing the use of the baud rate with restrictions, the baud rate used and the signal flow diagram illustrating the overload control method according to an embodiment of the invention;

FIG. 8 is a signal flow diagram showing an embodiment of the PDP context group modification procedure initiated by GGSN;

-7FIG. 9 is a diagram of a telecommunications network including an information channel center; and

FIG. 10 is a signal flow diagram showing an embodiment of a PDP context group modification procedure initiated by GGSN using information channel technology.

DETAILED DESCRIPTION OF THE DRAWINGS [0036] FIG. 1 schematically represents a telecommunications network 1. Telecommunications network 1 enables data sessions between server 2 and terminal 3 through a network of 4 data packets, where the terminal access to telecommunications network 1 is wireless.

[0037] In the telecommunications network shown in FIG. 1, three generations of telecommunications networks are presented in a schematic and simplified manner. A more detailed description of the architecture and general information can be found in 3GPP TS23.002, which has been included in this description by reference in its entirety.

[0038] The lower branch of FIG. 1 shows the GPRS or UMTS telecommunications network including the Gateway GPRS Support Node (GGSN), the additional GPRS Service Node (SGSN) and the RAN or UTRAN (Radio Access Network) radio access network ). For GSM / EDGE (GERAN) radio access networks, RAN includes a BSC (Base Station Controller) connected to several base station transceivers (BTS). Base Station Transceivers), which, however, was not shown. For UMTS radio access networks (UTRAN), RAN includes a Radio Network Controller (RNC) connected to multiple NodeBs, also not shown. The GGSN and SGSN nodes are connected to the Home Location Register (HLR), which contains information about subscribing to terminals 3.

[0039] The upper branch of FIG. 1 presents the next generation telecommunications network, generally known as LTE (Long Term Evolution, mobile data standard) or EPS (Evolved Packet System, developed packet system). Such a network includes a PDN gateway (P-GW) and a service gateway (S-GW). The E-UTRAN network in EPS includes a developed NodeB (eNodeB or eNB) providing wireless communication of the terminal 3, which is connected to S-GW via a packet network. The S-GW gateway is connected to the HSS (Home Subscriber Server) and MME (Mobility Management Entity) units to send signals. The HSS server includes the SPR subscription profile memory.

[0040] For more information on the overall architecture of EPS networks, see 3GPP TS 23.401.

[0041] Of course, architectures other than those defined by 3GGP, e.g. WiMAx or cable networks, may also be used in the context of this invention.

[0042] Since the invention as defined in the appended claims relates generally to this type of network, a more detailed description regarding the GPRS / UMTS network will be provided below.

[0043] For this type of network, SGSN typically controls after connecting between telecommunication network 1 and terminal 3. It should be remembered that telecommunication network 1 basically includes many SGSN, each of which SGSN is usually connected to several BSC / RNCs to package services for terminals 3 via several base stations / NodeB.

[0044] The GGSN node is connected to a network of 4 data packets, e.g. the Internet, a company network or another operator's network. On the other hand, GGSN is connected to one or more SGSN.

[0045] The GGSN is configured to receive data units for terminal 3 from server 2 via network 4 (downlink) and to send data units to server 2 received from terminal 3 (uplink).

[0046] In an M2M environment, a single server 2 is used when communicating with a large number of terminals 3. Individual terminals 3 can be defined by individual identifiers, for example, an IP address, IMSI or other terminal identifier.

[0047] FIG. 2 shows the PCC architecture known from 3GGP TS 23.203, which description is incorporated herein by reference in its entirety, which can be included in telecommunications network 1 GPRS, UMTS, LTE or other.

[0048] The central element in the PCC architecture shown in FIG. 2 is the PCRF (policy and charging rules) function. The PCRF function makes decisions regarding regulations related to quality of service (QoS) and treatment of service data sessions in the IP-CAN network. IP-CAN is a network that is able to support IP-CAN media, through which data sessions can be defined. IP-CAN carriers are IP transmission paths defined by e.g. performance, delay, error bit rate.

[0049] When making decisions, the PCRF takes into account subscription information received from the SPR via the Sp interface and information on IP-CAN capabilities. The PCRF function formats the decisions regarding regulations in so-called PCC rules. PCC rules are a collection of information that enables detection of service data flow and provides control parameters in terms of regulations and / or loading. The PCC rule contains, among other things, information to detect service data flow (e.g. 5-fold source / destination IP address, source / destination port number, protocol) and information on the required QoS and load treatment regarding service data flow. It also includes the maximum transfer rate allowed for service data flow, separately for uplink and link

-9zstępującego. PCC rules can be pre-defined or provided dynamically, and then can be redefined during an IP-CAN session.

[0050] The PCRF function sends decisions, formatted as PCC rules, towards the PCEF (Policy and Charging Enforcement Function) function via the Gx interface. In addition, PCRF informs PCEF about network events that it wants to be notified of.

[0051] The PCEF function includes detecting the flow of services, implementing regulations and functionalities regarding flow-based charging. These functions are implemented in accordance with the PCC rules obtained from PCRF (dynamic PCC rules) or defined in the PCEF itself (previously defined PCC rules). In addition, PCEF informs PCRF via the Gx interface about network events requiring notification to PCRF. The PCEF function is located in a Gateway Node, e.g. GGSN or P-GW in FIG. 1) which connects IP-CAN with the external 4 packet data network. The network 4 connected to server 2 can be any network or network connection that supports communication between telecommunications network gateway 1 and server 2, e.g. a dedicated line (copper cable or optical fiber connecting the gateway to server 2), IP backbone network, etc.

[0052] The SPR contains all subscription information necessary for PCFR to make decisions regarding regulations based on subscription for individual communication terminals 3 based on individual subscriber identifier, e.g. IMSI. Subscription information is required by PCRF via the Sp. Interface. The SPR may also notify the PCRF when the subscription information has changed. SPR does not necessarily lead to duplication of subscription information on the network. For example, the SPR may contain HSS or HLR.

[0053] As shown in FIG. 1, group G of terminals 3 may be connected or allow connection to telecommunications network 1 to enable data session with server 2 via telecommunications network and packet network 4. To identify this type of terminal group 3 according to the subject of the invention, HLR and / or SPR may store the common group identifier for the group record, in addition to individual subscription records containing the above-mentioned subscription information for individual terminals 3.

[0054] FIG. 3A and 3B show the individual subscription record and the group record. The individual subscription record contains subscription information, individually for each terminal 3. The individual subscription record contains, for example, an individual subscription identifier, individual QoS and load rules, which may include the maximum transfer speed towards the uplink and the downlink (possibly different for the uplink and the downlink), guaranteed uplink and downlink transmission speed, other congestion control information and / or other subscription information.

[0055] The group record contains, for example, a group identifier, information about the whole group, for example a group load condition, congestion regulation regulations, and a list of identifiers of communication terminals or carriers that belong to the group. Individual subscription records for communication terminals 3 in group G and group record are connected by group identifier and individual subscription identifiers i.e. the group G group record has a common group identifier and a list of identifiers for communication terminals 3 or carriers that belong to group G. The individual subscription record for a communication terminal in group G may also contain the group identifier for group G to which terminal 3 is assigned. The inclusion of a group identifier in individual subscription records may be beneficial in cases where communication terminals require information about the G group to which they are assigned. An example of this is given below, where the common group identifier is included in the transmit signal. Communication terminals 3 requiring information about the group to which they are assigned are able to recover (select) information from the transmission signal that is relevant to the group.

[0056] It should be remembered that a single communication terminal 3 can be assigned to more than one group.

[0057] There are no specific requirements for forming groups. Groups may e.g. (partially) overlap or be in individual elements of a group. You can also apply a hierarchical structure in which G group subgroups are created (e.g. all terminals supported from a specific SGSN / S-GW). It is also not required for all terminals to be included in a group. In the context of overload control, group formation will be based on an assessment of where overload can occur.

[0058] Providing a group record for a group of communication terminals 3 enables new and innovative methods to be implemented in a telecommunications network 1. Examples include the effective transmission of messages to group 3 communication terminals, access control for a group of communication terminals 3, and flexibility regarding congestion control.

[0059] Combinations of the above examples will be described below.

[0060] FIG. 4 shows a telecommunications network 1 comprising the PCC * architecture modified with respect to the PCC architecture shown in FIG. 2, which will be described in detail below. The first and second communication terminals 3A, 3B belonging to group G communicate with server 2 (e.g. in the case of smart electricity meters in households to send measurement data to the server).

[0061] Between terminals 3A, 3B and the gateway (in this case GGSN) of the telecommunications network, the carriers IP-CAN A1 and B1 (in this case the defined PDP Contexts) are defined. Data transported using IP-CAN media are subjected to QoS processing associated with the IP-CAN media. Data sessions A2, B2 in between

- terminals 3A, 3B and server 2 are supported by IP-CAN A1, B1 carriers in the telecommunications network, and then supported in network 4.

[0062] To ensure that A1 and B1 carriers obtain appropriate QoS characteristics, when determining the carrier, PCEF * consults PCRF * via the Gx * interface. The PCRF * function is then consulted with the SPR * via the Sp * interface regarding relevant subscription information. The PCRF * function decides on the regulations and informs PCEF * via the Gx * interface. The PCEF * function implements these decisions.

[0063] Accordingly, telecommunications network 1 may use group information for terminals 3A, 3B according to an embodiment of the invention, for more effective congestion control.

[0064] In an embodiment of the invention, the Px and / or Py interfaces allow communication between server 2 and SPR * and / or PCRF *, as will be described in more detail with reference to FIG. 6A and 6B.

[0065] The group record as shown in FIG. 3B, applies to many communication terminals 3A, 3B, whose A2-B2 data sessions with server 2 are handled by A1-B1 carriers, respectively. Group records are included in the SPR *. The group information in the group records includes, for example, a baud rate threshold that corresponds to the sum of the baud rates of all carriers A1, B1 of terminals 3A, 3B in group G. The sum of the maximum transmission rate values ​​of all individual subscriptions to 3A, 3B terminals or all A1, B1 carriers of terminals 3A, 3B in group G may be greater than the transmission rate value specified for group G to benefit from the statistical phenomenon, which is that it is very unlikely that all communication terminals 3 in group G simultaneously exchange data with server 2 at the maximum data rate specified for individual subscription records.

[0066] The group record as shown in FIG. 3B, may include a group identifier, identification of an individual ID subscription (e.g., IMSI) of terminals or bearers in the group, and information about the group, e.g. the above-mentioned aggregated rate of transmission threshold for group G.

[0067] A group record may also lead to the addition of group identification in individual subscriptions that are placed in the group. An individual subscription can be included in many group subscriptions.

[0068] Decisions regarding the regulations taken by PCRF * for individual communication terminals 3A, 3B are sent via the Gx * interface to PCEF *. The PCEF * function implements these decisions.

[0069] When the group load condition is met, for example, when the above sum of the baud rate threshold specified in the group information for the G group is exceeded, PCFR * is notified by PCEF * and PCRF * regulates individual regulation decisions leading to a change of at least one carrier

-12 active terminals 3A, 3B in group G. The PCRF function * sends the set individual decisions regarding regulations to PCEF * via the Gx terminal *. This can, for example, lead to a proportional limitation of the maximum transmission rate for A1 and / or B1 bearers and reduce the user transmission rate that is exchanged in A2 and / or B2 data sessions between terminals 3A, 3B and server 2.

[0070] It should be remembered that detection of fulfillment of a group load condition and reporting an event to PCRF * can also be performed by entities other than PCEF *, including entities in locations other than the location of PCEF * (e.g. in SGN / S-GW or on interface connecting GGSN / P-GW with SGSN / S-GW), as will be described with reference to FIG. 8.

[0071] In addition to PCEF * notifying PCRF * when the overload condition is met, it may include additional information contained in the notification regarding the overload condition being met. The PCRF * function can also manage for PCEF * to monitor and report additional information. An example of additional information that can be monitored and reported by PCEF * is a list of identifiers that identify one or more media (or data sessions or terminals) with which data has recently been exchanged. Additional information can help PCRF * when setting decisions regarding the regulations and priorities of media (or data sessions or terminals) to which the PCC rules will apply in the first place, thus leading to a more direct form of solving congestion problems.

[0072] FIG. 5A and 5B show examples of individual PCC rule and group rule. Despite the fact that the group rule differs from the common PCC rule, in this description they are called the PCC rule. The PCEF * function receives PCC rules from PCRF * to implement them. As shown, individual PCC rules contain information identifying the individual PCC rule, information used by PCEF *, for detection of associated IP flow, and required QoS and tariff information, e.g. implementation of maximum uplink and downlink link speed, guaranteed speed uplink and descending link transmission, IP DiffServ DSCP designation as well as other congestion data.

[0073] The group rule (FIG. 5B) similarly contains group rule identification information, information used by PCEF * to detect IP flow for a group (which can be summed based on individual flow detection information specified in individual PCC rules for carriers in group) and in particular the group load condition.

[0074] In an alternative embodiment (shown in dashed line in FIG. 5B), the group rule may include the PCC rule ID for terminals / carriers in the group, which information may be used to determine flow detection for the terminals / carriers in the group.

[0075] As already mentioned in the summary of the invention, the disclosed method and system provide flexibility to the user / operator of the server 2. Interaction between

Server 2 and SPR * via the Px interface as shown in FIG. 6A, may e.g. lead to the creation of a group record, adaptation of such a record, adjustment of overload threshold parameters for individual terminals 3, regulation of other information in a group record, e.g. how to set active carriers in a group after fulfilling the group load condition (see group record on FIG. 3B), etc. As shown in FIG. 6B, PCRF * can also work with server 2 via a policy implementation request to get information through a policy implementation message on how to set active media in a group. Alternatively, the server may push this information to PCRF *. Of course, this information can be retrieved from SPR * via the Sp * interface. In addition, using from the Px interface, in the group record and / or the individual subscription record, you can include further information about the subgroups in the group and / or information on how (e.g. to what level) and / or in what order to set individual overload parameters.

[0076] FIG. 7A and 7B provides a first example of a method of congestion control in telecommunications network 1 using the PCC * architecture shown in FIG. 4.

[0077] FIG. 7A shows an example of the use of active 3A-3D terminals that enable PCEF * and PCRF * to work together. The 3A-3D terminals have been assigned common group identifiers, and thus belong to the G group. Individual overload parameters, in this case the maximum MBR transmission rate subscribed, is 40, for terminals 3A, 3B and 20 for terminals 3C and 3D. All 3A-3D terminals have bearers enabling active data sessions on the GPRS network 1 shown in FIG. 1. The GLC1 group load condition is defined so that overload should be reported when the aggregate baud rate monitored for the group exceeds 80. The PCEF * function has also been notified by PCRF * and monitors the group load indicator, e.g. the aggregate baud rate for group G. For example, it should be assumed that the actual transmission rate for terminals 3A, 3B is only 30, for terminal 3C just 10, and for 3D terminal just 5, as shown by the shaded field. Then, PCEF * can monitor a group load indicator of 75 that does not meet the group load condition. Alternatively, PCEF * can detect the group load condition in a more direct way, without explicitly specifying the value of the aggregate baud rate for the group, e.g., by comparing the aggregate baud rate for the group with a reference rate, e.g. in a bucket of chips or a similar set at a rate of 80. In yet another embodiment, PCEF * can monitor the baud rate separately for each communication terminal 3, for example as part of an existing PCC rule, and sum the values ​​for each of the terminals in group G to obtain a group load condition for group G.

[0078] If PCEF * indicates that the GLC1 overload group condition is met (as a result of, for example, increasing the 3D terminal's baud rate from 5 to 20, as shown in FIG. 7A using the down arrow for the 3D terminal), the group condition must be met load GLC1 runs PCEF * so that it sends this condition to

* -14PCRF8. The PCEF * function can optionally provide additional information regarding the severity of the situation so that PCRF * can take it into account.

[0079] The PCRF * function sets individual PCC rules for at least one of the communication terminals in group G. In Fig. 7A, the maximum transmission rate (MBR) values ​​of the 3A-3D communication terminals are represented by MBRA - MBRD. In this example, PCRF * decides to reduce proportionally the maximum transmission rate parameter of the 3A and 3B communication terminals, i.e. MBRA and MBRB, from 40 to 20. The PCEF * function, after receiving the updated PCC rule from PCRF *, adjusts the individual MBRA congestion parameters - MBRD carriers (in this case, only MBRA and MBRB require adjustment), as shown by the downward arrows for MBRA and MBRB. Associated terminals 3A and 3B will reduce the transmission speed to 20 or less. In the event that the terminal does not adapt to the adjusted data session communication parameter, for example MBR, it will be enforced by PCEF * in the normal way. In this example, the individual congestion (MBR) parameters are set to 20. Telecommunication network 1 will provide a transmission speed of no more than 80 at this time, and the GLC1 group load condition will not be met.

[0080] The proportional downward adjustment of the individual value of the overload parameter may for example be implemented to a predetermined lower value or by subtracting a specific value from the current value of the parameter or be implemented by taking a fraction (e.g. 70%) of the current value of the parameter. The proportional down adjustment of the parameter value can thus be different within a group.

[0081] The PCEF * function may notify PCRF * when the summed transmission rate returns to the specified limits again. The PCRF * function can also instruct PCEF * to apply a specific hysteresis before notifying the overload condition has expired.

[0082] Adjustment of individual congestion parameters, e.g. the maximum MBR bit rate value may be implemented in steps along with feedback from PCEF *, e.g. every one step. The amount of up-regulation and their dispersion among IP-CAN carriers or 3A-3D terminals is determined by PCRF *. For example, dispersion may be predefined in a group record stored in SPR * or PCRF * may consult server 2 providing a Py interface as shown in FIG. 6B or upward regulation may be requested by the communication terminal, which is subject to PCRF * approval in the normal manner.

[0083] It should be appreciated that the adjustment of individual overload parameters, both downward and upward adjustment, can be carried out according to the various types of regulations which have been described above. Group congestion regulation regulations can be included in a group record, which is schematically shown in FIG. 3B.

[0084] As shown in FIG. 7A, a second GLC2 group load condition can be defined that functions as a lower level actuator for the PCEF * notification PCRF * starting. When the GLC2 group load condition is no longer met, PCRF * may decide to scale one or several previously set PCC rules for the 3A-3D terminals in Group D that could benefit from a higher transmission rate.

[0085] FIG. 7B shows the communication diagram between PCEF * and PCRF * in the above-mentioned example of uplink traffic.

[0086] In step 1, PCEF * determines that the GLC1 or GLC2 group load condition is met. In the present example, PCEF * detects that the aggregate baud rate of communication terminals 3 in group G exceeds the set value at a given point in time.

[0087] In step 2, PCEF * notifies PCRF * of the fact that the GLC1 group load condition is met.

[0088] In step 3, PCRF * makes a new decision regarding regulations, for example a decision to downscale the maximum data rate (MBR) parameter for PCC rules and, consequently, for carriers of Group 3A and 3B terminals G. Information on which the media and / or parameters should be adjusted, determined by overload parameter regulation regulations, or is e.g. obtained from SPR * or from server 2 as shown in FIG. 6A and as described above.

[0089] In step 4, PCEF * is informed of the adjusted individual PCC rules, shown in FIG. 5A, for terminals 3A and 3B. Updated group rules can also be forwarded to PCEF * when telecommunication network operator 1, for example, requests the GLC1 and / or GLC2 congestion condition adaptation.

[0090] In step 5, IP-CAN data carriers of telecommunications terminals (in this example: for terminal 3A and terminal 3B) are modified according to a set PCC rule for a given telecommunications terminal. Each of the terminals involved (in this example: terminals 3A and 3B) is informed about the set value of individual overload parameters (in this example the reduced MBR value), and thus the terminal will have the opportunity to behave appropriately.

[0091] While these messages can be sent to each of the terminals (in this example: terminals 3A and 3B) separately from the GGSN gateway, it may be beneficial to use a group identifier for group G and send a group update request to the network node that is located downstream of telecommunication network 1 to adjust data session communication parameters (e.g. PDP Context and IP-CAN bearer) of group G communication terminals This will be explained in greater detail below with reference to FIG. 8 ff.

[0092] In step 6, PCEF * implements new individual PCC rules, using part of the adjusted PCC rule for (in this example) terminals 3A and 3B.

Finally, in step 7, PCEF * informs PCRF * of successful completion of the adjustment of IP-CAN bearers and, if possible, of setting the adjusted group load condition.

[0094] Of course, the process can be repeated from step 1 for subsequent notifications associated with the same (possibly adjusted) group load condition or other conditions and / or can be repeated from step 3, for example, to further reduce individual overload parameters when previous downward adjustment did not solve the overload problem or to instruct upward adjustment when PCRF * makes such a decision.

[0095] When the PCRF * is notified of an overload condition, the PCRF * may, in addition to adjusting the media (s) overload parameter, also decide to adjust the regulations to provide QoS resources for additional media that may need to be implemented or for additional sessions data that can be activated in a group. This is shown in FIG. 7C for the 3E terminal. For example, PCRF * may also decide to adjust the maximum transmission rate that can be made available to additional media or sessions in group G from a value of e.g. 40 to a value of e.g. 10. If an additional 3E terminal in group G requested the provision of an additional MBRE medium e.g. 40, PCRF * will make a decision regarding regulations. In this case, PCRF * will not grant the requested MBRE at level 40, which would otherwise be possible, but will issue a PCC MBRE rule at level 10, shown by a downward pointing arrow for the 3E terminal.

[0096] As above, the availability of the group record and common group identifier can be used both in the overload control method and the system described above and for other purposes described in the application "Information transmission in a machine-to-machine telecommunications network" consisting of the same date, which is incorporated by reference in its entirety in the description.

[0097] In general, the common group identifier can be used to set IP-CAN bearers, e.g. PDP Context or IP-CAN parameter, of a large number of communication terminals. Currently, modifications initiated by the given PDP Context network are supported by most modern telecommunications network technologies. Current technologies include the transmission of signals between at least a network node and each of the communication terminals.

[0098] In a known method, the modification of the PDP Context of the carriers of each of the communication terminals involved includes a signal load proportional to the number of IP-CAN carriers (usually, the number of terminals). In other words, IP-CAN carrier modification messages occur on individual media. PDP Context modification procedures are described, for example, in 3GPP TS 23.060. In addition, the load obtains the maximum value when initiating modifications on a significant number of communication terminals, which may for example be necessary in the above-described method and congestion control system in which the communication terminals 3

- G groups must be informed about PCC rules regulation for uplink communication. The peak value is also seen in the case of working load of specific network elements.

[0099] The common group identifier of the communication terminals may be used to limit the signal load in the network during the initiation of regulation of individual congestion parameters for carriers of a significant number of communication terminals. In addition, the peak value of the signal load and the working load of the network elements can be reduced in this way.

[0100] For example, the IPCAN carrier group modification procedure may be used, which includes modification of the IP-CAN carrier of individual communication terminals 3. (Sub) groups are determined using common group identifiers (sub) in HLR or HSS / SPR, and communication terminals can be assigned to one or more of these groups.

[0101] Such a group modification procedure may, for example, be initiated at the network node as GGSN / P-GW or SGSN / S-GW when it detects that such modification has been started (see the previous embodiment meeting the overload condition).

[0102] FIG. 8 is an example of a PDP Context group modification procedure initiated by GGSN for group G including 3A-3Z communication terminals.

[0103] In the first step, after starting (not shown), GGSN transfer a Group PDP Context Update Request to one or more SGSN. For example, this message contains the common group identifier obtained from the group record stored in HLR / SPR * or HSS / SPR *. This message also includes the QoS Requests parameter informing about the desired QoS profile for each of the G group media. In this case, there is a significant increase in performance, because only one request is sent from GGSN to SGSN as opposed to the state of the art, in which update requests are requested for each carrier individually. The PDP Context Update Group Request may contain IP-CAN bearer adjustment for the overload control and telecommunications network described above 1.

[0104] The SGSN acquires the involved 3A-3Z communication terminals from the Group Context Update Request PDP received from the GGSN by cooperating with the HLR using a common group identifier. Information on individual 3A-3Z communication terminals (i.e. their individual identifiers) can be retrieved from the HLR and / or saved to SGSN after recovery.

[0105] The SGSN sends in Step 2 a PDP Context Modification Request message to each 3A-3Z terminal, including, among others, newly negotiated QoS. Newly negotiated QoS may be restricted by SGSN.

[0106] Each terminal 3A-3Z can confirm the PDP Context Modification Request in step 2 by returning the SGPN Context Modification Accept message to SGSN. if

The terminal 3A-3Z will not accept the newly negotiated QoS, it may instead deactivate the PDP context using the PDP Context Deactivation procedure initiated by the terminal. The SGSN may then perform a PDP Context Deactivation procedure initiated by the terminal (not shown).

[0107] At least in UMTS networks, PDP Context modification also includes RAB (Radio Access Bearer) modification. RAB modifications are carried out immediately after the PDP Context Modification Request (stage 2) or after the PDP Context Modification Acceptance (stage 3) in stage 4, for each individual 3A-3Z communication terminal. Alternatively, the RAB modification is performed after receiving the PDP Context Modification Acceptance in step 3 for each of the terminals.

[0108] After receiving a PDP Context Modification Accept message from all 3A-3Z terminals or after completing all RAB modification procedures (for UMTS networks), SGSN returns to the GGSN the Group Response PDP Context Update message. This message contains, for example, the same common group identifier that is contained in the Group PDP Context Update Request received from the GGSN. When exchanging the signal message, it is also possible to use a transaction identifier whose value is assigned by GGSN, and GGSN includes it in the request in step 1, and whose SGSN value is included in the response in step 5, possibly as an alternative to the group identifier.

[0109] Group PDP Context Modification, as shown in FIG. 8 may also be initiated by SGSN, for example, when the SGSN or its associated unit detects an overload condition as described above. In such a situation, SGSN can advantageously immediately initiate Group PDP Context Modification, not just report an overload condition to another network node (e.g. to GGSN or to PCEF *) and allow other network entities to take appropriate action. In this case, it is assumed that a group has been defined in which all data sessions (communication terminals) belonging to the group are controlled by SGSN. Then, a similar procedure is carried out to that described for FIG. 8, wherein the interactions with GGSN in the first and last steps, described in the case of FIG. 8 are omitted. However, during or after the modification, SGSN notifies GGSN of the modification for which notification the common group identifier for the SGSN group can be used. In addition, SGSN may send a Group PDP Context Update Request to GGSN, and GGSN may respond with an appropriate message sent to SGSN to take into account information (e.g. restrictions) available on GGSN.

[0110] It will be appreciated that the PDP Context Group Modification procedure as described in FIG. 8, is not limited to modifications regarding overload control or modification of individual overload parameters that may affect elimination or reduction of overload. The procedure can also be used in other circumstances where many PDP Contexts or similar in other types of networks are modified, and can also be used in

-19 relative to other parameters, for example Access Point Name (APN) modification, QoS class modification, DiffServ DSCP designation, etc.

[0111] In certain circumstances, it may be useful to send the message to a group of communication terminals. These messages contain a common group identifier and may e.g. contain information on overload control or other communication terminals 3 relevant to group G. In these cases, communication terminals 3 should have (access) a common group identifier to recover (select) specific information from communication. This information regarding the common group identifier can for example be obtained during the procedure of joining the telecommunications network 1 in which the common group identifier (identifiers) can be retrieved from the individual subscription record (see FIG. 3A) and sent to the terminal. The common group identifier can also be saved or pre-programmed in the (module) communication terminal 3.

[0112] Examples of transmission may use cell broadcast center (CBC) which is known by this name. Various architectures are possible, e.g. where CBC is connected to several SGSN / S-GW and / or to several GGSN / PG-W, as shown in FIG. 9. Again, the message transmission can be initiated by SGSN or by GGSN. Information channel services are described in 3GPP TS 23.041.

[0113] FIG. 10 shows a scheme of modifying the PDP Context of the G group of 3A-3Z terminals, with GGSN initiating a Group PDP Context Update Request after starting (step 1) modifying the PDP Context as previously described, and the CBC is controlled by SGSN.

[0114] In step 2, the GGSN sends a Group PDP Context Update Request to one or several SGSNs. This request contains at least the common group identifier for the G group of 3A-3Z communication terminals that need to be modified, and the parameters indicating the appropriate QoS for the carriers of the 3A-3Z communication terminals in group G. To ensure that all relevant SGSNs receive this request, GGSN can use different methods. One of them is the GGSN sending a request to all SGSN with which it connects. Another is that the GGSN selects the relevant SGSN (by consulting the HLR / HSS) and sends the request only to the appropriate SGSN. Yet another way is that the GGSN sets up a multicast group for each group in which the message will be sent. Then, SGSN, when a PDP Context is prepared for a terminal belonging to a specific G group, informs GGSN that it has been saved to receive all messages sent in groups in a group associated with the G group. In the event of a Group PDP Context Update Request, GGSN must only enter a single message in a multicast group associated with group G to ensure that all relevant SGSNs (which are assigned to the group) receive a message.

[0115] The SGSN uses a broadcast or multicast technology to inform the 3A-3Z terminals in group G about the request to update the PDP context group. More

In detail, in this embodiment, information channels (CB, Cell Broadcast) are used. The SGSN operates like CBE (Cell Broadcast Entity) (see 3GPP TS 23.041). Defines the geographical areas known as news feed areas in which messages should be broadcast. These should be all SGSN related channels. In step 3, SGSN sends the requested CB messages to the CBC. The CB message contains the PDP Context Modification Request Group parameter, the common group identifier for the G group and the parameter (parameters) indicating the requested QoS for the PDP Contexts in the G group.

[0116] In step 4a, the CBC sends the CB message in Save-Replace messages to RAN, i.e. to one or more BSC / RNC according to the (defined) information channel area. In turn, RAN, via the SMS Emission Request, requests the broadcast of a CB message in the areas defined in step 4b. The CB message also contains the common group identifier for the G group. Each of the communication terminals receiving a broadcast message is then able to determine whether the received message is intended for such a terminal. This happens when at least one of the group identifiers in the received message matches at least one of the terminal's group identifiers. The communication terminal having the IDG group ID for the group G will thus recognize that the received broadcast message which includes the IDG group identifier is intended for this terminal as shown in step 4b in FIG. 10, and other terminals that have received such a message may ignore it (not shown in FIG. 10). Alternatively, if multiple information channels are available, the group identifier may determine to which channel the communication terminals should be tuned. In response to Save-Replace, RAN sends the Report Successfully, in step 4c. The broadcast of the message in stage 4 corresponds to the specification of Communication Channel Services, see 3GPP TS 23.041.

[0117] After receiving all Report-Success messages from the RAN, i.e. from all BSC / RNC involved, in step 5 the CBC sends the CB message report to the SGSN. In addition, the 3A-3Z communication terminals, after receiving the CB message and after recognizing the message as intended for them, in step 4b accept the modification requests made in stages 6a-6z. Each of them sends a standard PDP Context Modification Acceptance message (possibly together with the identification of the G group of 3A-3Z communication terminals to which the PDP Context belongs) to SGSN. As above, it is also common to use a transaction identifier whose value should be assigned by SGSN, and SGSN will include it in the PDP Context Modification Request in the CB message request in step 3, and the 3A-3Z terminals include this value in their answers in step 6a-6z.

[0118] In steps 7a-7z, the RAB modification is performed for each of the 3A3Z terminals individually after receiving the message 6a-6z Accepting PDP Context Modification for the individual terminal. Again, steps 7a-7z can also be implemented after holding all individual PDP Context Modification Acceptance messages (steps 6a-6z).

[0119] After performing PDP Context Modification procedures from all 3A-3Z terminals in group G, SGSN returns the PDP Context Update Group Response Response to GGSN in step 8. This message contains at least the common group identifier for group G. As above, it is also possible to use a transaction identifier whose value is assigned by GGSN, and GGSN includes it in the PDP Context Update Request in step 2, and whose SGSN value is included in the response in step 8.

[0120] Finally, the GGSN may inform the unit that has started the group modification of PDP Contexts as a result of modification of the PDP Context (step 9).

[0121] As known, other variants of the embodiment shown in FIG. 10. For example, GGSN may run the CBC to send a modification request to the 3A-3Z communication terminals in group G. Then, information channels will interact between GGSN and CBC as a replacement for such interaction between SGSN and CBC. In this case, stage 2 will include an information message from GGSN to SGSN, which will also include a notification that GGSN will act as CBE (Cell Broadcast Entity).

[0122] In another embodiment, SGSN (instead of GGSN) will be started to initiate the modification for group G of communication channels 3A-3Z. The SGSN may then send a Group PDP Context Update Request to GGSN, and the GGSN may return a Group PDP Context Update Response message to SGSN.

[0123] In yet another embodiment, the SGSN is started to initiate a modification of the group G of the 3A-3Z communication terminals (as in the previous embodiment), but the GGSN will act as a CBE. The SGSN node, running internally, sends a Group PDP Context Update Request to GGSN. The GGSN node returns the PDP Context Update Group Response message to SGSN. Information channels interact with GGSN and CBC, and GGSN informs SGSN which will act as CBE.

Anna Stenzel Patent Attorney