WO2014001463A2

WO2014001463A2 - Method for congestion control in mobile networks and mobile network with congestion control

Info

Publication number: WO2014001463A2
Application number: PCT/EP2013/063536
Authority: WO
Inventors: Tarik Taleb; Andreas Kunz
Original assignee: NEC Europe Ltd
Current assignee: NEC Europe Ltd
Priority date: 2012-06-27
Filing date: 2013-06-27
Publication date: 2014-01-03
Anticipated expiration: 2014-12-27
Also published as: WO2014001463A3

Description

METHOD FOR CONGESTION CONTROL IN MOBILE NETWORKS AND MOBILE NETWORK WITH CONGESTION CONTROL

The present invention relates to a method for congestion control in mobile networks as well as to a mobile network with congestion control, wherein said mobile network includes a core network and a radio access network.

Mobile operators fear congestion at their core network, impacting both their control and data planes and that is due to the foreseen deployment of billions/trillions of machine type communications (MTC) devices and also millions of smart mobile phones and associated traffic. Some mobile operators have already experienced congestion at their networks due to the penetration of smart mobile phones.

As an attempt to alleviate congestion at mobile networks, the Core Network Overload (CNO) Study Item was initiated in 3GPP during SA2 #79 (see for reference: "Study on Core Network Overload Solutions", TR 23.843 VO.4.0 (201 1 - 04), hereinafter denoted [1]). The scope of CNO SID got broadened in Release 12, as now the study includes more core network interfaces (e.g., S1 -AP, S1-MME, S6a/b/d, Gx, Rx, S1 1 , S5, S4, S8) identified for further analysis (see for reference: "Core Network Overload Solutions Study", Work Item Description, TD SP- 1202620, June 2012). The objectives of this new SID are:

• identify and document scenarios that may result in signalling overload for core network entities and that are not yet covered by other work items, like the event outlined above, denial of service attacks, misbehaving/non- compliant mobiles,

• analyse the criticality of the scenarios and determine whether it is required to take actions for the identified scenarios

• study ways to mitigate and handle signalling overload scenarios that are identified to be critical.

In [1], a number of solutions have been proposed to deal with congestion at the control plane of the core network. Most of the solutions deal with congestion at the nodal level, i.e. congestion control is performed on a basis per mobile terminal. However, this is resulting in a large number of signaling messages, when the system is under heavy load.

In view of the above it is an objective of the present invention to improve and further develop a method for congestion control in mobile networks and a mobile network with congestion control of the initially described type in such a way that congestion is avoided more effectively.

In accordance with the invention, the aforementioned object is accomplished by a method comprising the features of claim 1. According to this claim such a method is characterized that a core network node performs the following steps:

identifying mobile stations having the same or similar subscription features and/or the same or a similar behavior towards the mobile network,

dynamically grouping at least a subset of said identified mobile stations, and assigning said grouped mobile stations a unique group ID.

Furthermore, the above mentioned objective is accomplished by a mobile network with congestion control comprising the features of claim 20. According to this claim such a mobile network is characterized in that core network nodes comprise means for identifying mobile stations having the same or similar subscription features and/or the same or a similar behavior towards the mobile network, and wherein said core network nodes are further configured to dynamically group at least a subset of said identified mobile stations and to assign said grouped mobile stations a unique group ID.

Still further, the above mentioned objective is accomplished by a network node for deployment in the core network of a mobile network comprising the features of claim 21. According to this claim such a network node is characterized in that it is configured to

identify mobile stations having the same or similar subscription features and/or the same or a similar behavior towards the mobile network,

dynamically group at least a subset of said identified mobile stations, and assign said grouped mobile stations a unique group ID. According to the invention it has been recognized that the signaling load in times of overload situations can be minimized by enabling core network nodes to dynamically group mobile stations with common or at least similar subscription features and/or with common or at least similar behavior towards the mobile network and to assign a unique group ID for such group of subscribed stations. By applying a dynamic grouping algorithm in accordance with the present invention it becomes possible to address many mobile terminals at the same time, thereby significantly reducing the amount of signaling. Furthermore, as an effect of the present invention the use of network node interfaces is optimized (e.g., handling messages from UEs belonging to the same group in bulk), and the amount of processing core network nodes will also be reduced.

According to a preferred embodiment the group ID may be exchanged among core network nodes, which e.g. in an LTE scenario may include in particular, but not limited to, eNB (eNodeB), MME (Mobility Management Entity), S-GW (Serving- Gateway), P-GW (PDN-Gateway), PCEF (Policy and Charging Enforcement Function), PCRF (Policy and Charging Rule Function), etc. These core network nodes may then make a local binding between the received group ID and the respective mobile terminals' identifiers.

According to another preferred embodiment the core network nodes may use the group ID for enforcing a certain network policy regarding a particular network procedure, in particular mobility management procedure (e.g., TAU,RAU, LAU, Attach, Location Update, etc.), or session management procedure (e.g, PDN connectivity request, PDP context activation request, etc.).

Advantageously, the group ID is constructed by a core network node upon receiving the subscription data of a mobile terminal that attaches to the mobile network. When a mobile terminal attaches to the mobile network and the relevant core network node, upon receiving the subscriber data/profile, constructs a group ID, it may be provided that the group ID is not only shared with other core network nodes, but is also provide to the relevant node in the radio access network. Moreover, the core network node may provide the group ID to the mobile stations, which may then store the group ID and use it in following service requests, session setups, dedicated bearer requests and/or mobility management related procedures.

Stemming from the fact that there could be many scenarios whereby a mobile network node (eNB, MME, P-GW, MTC-IWF, etc) needs to deal with sending a mass of messages (i.e., at both user plane and control plane) from a group of UEs (e.g., MTC devices) with some information elements in common to the same target node at nearly the same time, in WO 201 1/141 154 A1 it was proposed to hold such messages at a node for a specific time or till a number of messages is received, aggregating their content while avoiding duplicate information elements, and handling them in bulk to the receiving node. In this way, the message contents can be compacted considerably. Moreover, the effort of parsing the parameters of many messages is also reduced to a minimum, which shall reduce by a large factor the time spent for processing the messages at the receiving node. Whilst handling messages with common information elements in bulk has advantages, its main drawback is the delay it adds in processing the messages.

In order to achieve the goal of the "bulk message handling solution" in reducing the amount of traffic sent on EPS (Evolved Packet System) interfaces, but without compromising the delay in handling messages, it is provided in accordance with a preferred embodiment of the present invention that core network nodes dynamically create and manage profile IDs that refer to a single or a set of attributes, in particular information elements, that are common in messages relevant to a group of mobile stations belonging to (or supposedly belonging to) a group being identified by a unique group ID. This can be applied on a wide range of different interfaces and mobile network nodes, and it enables an efficient usage of the group IDs. Advantageously, the profile IDs are used to replace the common information elements (lEs), thereby reducing message sizes on different interfaces and further alleviating congestion. The importance of replacing common lEs in messages by a profile ID, similar in spirit to Robust Header Compression (ROCH), becomes even more significant knowing that the size of messages is increasing with every release of the specifications. According to a preferred embodiment the profile ID creation may be triggered by a scheduled communication from subscripted stations, e.g. from MTC devices or from certain applications smart phones, known by the mobile network a priori. Alternatively or additionally, the profile ID creation may be triggered by the reception of a number of messages of the same procedure with common Information Elements and regarding a number of subscripted stations belonging to the same group identified by a specific group ID and that is within a predefined period of time. The profile ID can be a random value or, alternatively, it may be created in form of a function of the group ID of the relevant group of mobile stations, possibly combined with other metrics. In this context, the group ID can be either explicitly indicated in the messages, or it can be inferred from the identifiers (and/or other information elements) of relevant mobile stations, inferred from subscription data of mobile stations downloaded on demand or a priori from HLR/HSS or another relevant node, or inferred from a mapping between the relevant procedure and the locations (e.g., cells, tracking areas, service areas, etc.) of the relevant mobile stations. With respect to an efficient sharing of the profile ID, it may be provided that the entity having created the profile ID - sender - communicates the profile ID to at least one other entity - receiver - in a profile ID notification message. The notification message may further include information regarding the features of said profile ID, event type and/or instructions for the receiver when to delete the profile ID.

Advantageously, storage of the group ID and/or the profile ID may be deleted and/or updated via dedicated signaling messages and/or based on a particular trigger, scenario or event, such as a flag in the last message relevant to the profile, after a timeout, after receiving a total number of messages, based on an event detected by the node, or based on instructions and terms agreed on in advance between the relevant nodes. According to a preferred embodiment the messages that are subject to profile ID creation may be messages on interfaces using Diameter. For instance, according to one specific embodiment the messages may be messages regarding update location requests, for instance as defined in TS 29.272, section 5.2.1.1 , where the relevant information elements in Update Location request message are (M ... Mandatory, O...Optional, C... Conditional):

- IMSI (M),

- Supported Features (O),

- Terminal Information (O),

- ULR Flags (M),

- Visited PLMN Id M (M),

- RAT Type (M),

- SGSN number (C)

- Homogeneous support of IMS Voice over PS Sessions (o)

- V-GMLC address (C)

- Active APN (o)

- UE SRVCC Capability (C) Only IMSI and Terminal Information will differ between the many requests to be handled; this means that a profile ID based on the group ID of the UEs involved in the Update Location Requests could be used to compact the message content.

According to another specific embodiment the messages may be messages regarding cancel location requests. Here, the relevant information elements are:

- IMSI (M)

- Supported Features (O)

- Cancellation Type (M)

- CLR Flags (O)

Only IMSI will differ between the many Cancel Location requests to be handled. If only IMSI and Cancellation Type are contained in the Cancel Location Requests, creating a profile ID for handling these messages may not be efficient. Indeed, since these messages are not highly delay-sensitive, they can be hold for a while and handled in bulk.

According to still another specific embodiment the messages may be messages regarding CC-Request commands. The CCR command is sent by the PCEF to the PCRF in order to request PCC rules for a bearer, provision IP flow mobility routing rules, indicate bearer, PCC rule or IP flow mobility routing rule related events or the termination of the IP CAN bearer and/or session. Its format is as follows:

Message Format:

<CC-Request> ::= < Diameter Header: 272, REQ, PXY >

< Session-Id >

{ Auth-Application-ld }

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

{ CC-Request-Type }

{ CC-Request-Number }

[ Destination-Host ]

[ Origin-State-Id ]

*[ Subscription-Id ]

*[ Supported-Features ]

[ TDF-lnformation ]

[ Network-Request-Support ]

*[ Packet-Filter-lnformation ]

[ Packet-Filter-Operation ]

[ Bearer-Identifier ]

[ Bearer-Operation ]

[ Framed-IP-Address ]

[ Framed-IPv6-Prefix ]

[ IP-CAN-Type ]

[ 3GPP-RAT-Type ]

[ RAT-Type ]

[ Termination-Cause ] [ User-Equipment-lnfo ]

[ QoS-lnformation ]

[ QoS-Negotiation ]

[ QoS-Upgrade ]

[ Default-EPS-Bearer-QoS ]

0*2[ AN-GW-Address ]

[ 3GPP-SGSN-MCC-MNC ]

[ 3GPP-SGSN-Address ]

[ 3GPP-SGSN-IPv6-Address ]

[ RAI ]

[ 3GPP-User-Location-lnfo]

[ 3GPP-MS-TimeZone ]

[ Called-Station-ld ]

[ PDN-Connection-ID ]

[ Bearer-Usage ]

[ Online ]

[ Offline ]

*[ TFT-Packet-Filter-lnformation ]

*[ Charging-Rule-Report]

*[ ADC-Rule-Report ]

*[ Application-Detection-lnformation ]

*[ Event-Trigger]

[ Event-Report-Indication]

[ Access-Network-Charging-Address ] *[ Access-Network-Charging-ldentifier-Gx ] *[ CoA-lnformation ]

*[ Usage-Monitohng-lnformation ]

[ Routing-Rule-lnstall ]

[ Routing-Rule-Remove ]

[ Maximum-Bandwidth ]

[ Logical-Access-ID ]

[ Physical-Access-ID ]

*[ Proxy- Info ]

*[ Route-Record ] *[ AVP ]

From this format, it can be said that for UEs belonging to the same group, it is very likely to have many common Information Elements in the CC request messages issued regarding these UEs and/or their bearers. Creating a profile ID to refer to these common information elements and sending it instead of all common lEs would definitely reduce the amount of traffic exchanged on the Gx interface. Additionally, it would reduce the processing load at PCRF.

There are several ways how to design and further develop the teaching of the present invention in an advantageous way. To this end it is to be referred to the patent claims subordinate to patent claim 1 on the one hand and to the following explanation of preferred embodiments of the invention by way of example, illustrated by the drawing on the other hand. In connection with the explanation of the preferred embodiments of the invention by the aid of the drawing, generally preferred embodiments and further developments of the teaching will be explained. In the drawing

Fig. 1 is a flow diagram illustrating an embodiment of the present invention in connection with an attach procedure of a mobile station to a mobile network, and the basic components of a computing system with secure and

Fig. 2 is a schematic view showing a method of message compression using a unique profile ID in accordance with an embodiment of the present invention.

Fig. 1 illustrates an embodiment of the present invention in connection with an Attach Procedure as described in document 3GPP TS 23.401 V1 1.5.0 (2013-03), section 5.3.2. However, it is to be understood that embodiments of the present invention can be realized in connection with many other different scenarios. Since it is assumed that those skilled in the art are sufficiently familiar with the 23.401 Attach Procedure, the description of some general parts of the procedure are omitted here, while only those parts relevant for the present invention are described in detail hereinafter.

When the MME (Mobility Management Entity) receives the subscriber profile of the UE (User Equipment) attaching to the mobile network from the HLR/HSS in step 1 1 in the Update Location Ack message, then the MME or another relevant core network node in accordance with the present invention constructs a grouping identifier - group ID -, which e.g. may be based on one or more of the following not exclusive list of information:

- EPS subscribed QoS profile

- IMSI

- MSISDN

- Tracking Area List

- CSG ID

- CSG membership

- UE Radio Access Capability

- UE Specific DRX Parameters

- Selected CN operator id

- Access Restriction

- APN-OI Replacement

- Subscribed UE-AMBR

- Subscribed RFSP Index

- CSG Subscription Data

- LI PA Allowed

- Subscribed Periodic RAU/TAU Timer

- MPS CS priority

- MPS EPS priority

- Voice Support Match Indicator

- APN Restriction

- APN Subscribed

- MS Info Change Reporting Action

- low access priority

- EPS bearer QoS - eNodeB Address in Use for S1 -MME

The creation of the group identifier can be for all UEs requesting Attach or to a set of UEs with particular subscription features (e.g. UEs with low access priority). As regards the latter case, the grouping of UEs can be based on solely one parameter, e.g. UE's low access priority. However, if the operator wants to perform grouping on a finer granularity, the network can group UEs based on further multiple Information Elements, such as UEs camping in a particular area. In the embodiment described in connection with Fig. 1 , the constructed grouping identifier is then provided to the eNB in the Attach Accept in step 17 and further to the UE in step 18 in the RRM Connection Reconfiguration message. If the UE receives the group ID, it may store the grouping identifier and use it in following service requests/session setups/dedicated bearer request and mobility management related procedures, e.g. Tracking Area Update. The group identifier can be also provided to other core network nodes such as S-GW in Step 12, to P- GW in Step 13, and then to PCRF in Step 14. Local binding between the group ID and one or multiple UE's identifiers is made at the receiving nodes (e.g., eNB, S- GW, P-GW, PCRF, etc).

If the mobile network experiences a nodal overload situation (e.g. at HLR/HSS, MME, etc.) and would therefore normally have to reject mobility management requests from the mobile terminals, it can now use the grouping identifier for applying (Extended) Access Class Barring at the eNBs to address multiple UEs belonging to a specific group at the same time, e.g., to deal with mobility management messages, by S-GW, P-GW, PCRF for e.g., handling session management messages and/or policy and charging control messages in bulk to optimize the usage of network interfaces. Generally, if a UE of a special group sends a request, it will be identified by the eNB by looking at the group ID indicated in the request message from UE or by referring to the binding between the group ID and the UE's identifier (if the group ID is not available in the request message from UE), and the request message will be rejected at the eNB and a backoff timer will start in the UE and the UE can repeat the request when the backoff timer expires, according to the extended access class barring mechanism. The group ID can be also used by S-GW, P-GW, PCEF, and/or PCRF for session management, policy and charging control, and messages from UEs belonging to the same group identified by a unique group identifier can be handled in bulk.

Fig. 2 schematically illustrates an embodiment of the present invention in which messages with common lEs are compressed by using a unique profile ID created and managed following a specific logic using the group ID of relevant UEs. It is noted that this kind of signaling message compression can be applied between any two entities that exchange messages between them over a particular interface, as shown in Fig. 2 for the case of a first network entity, denoted sender, communicating with a second network entity, denoted receiver.

In the illustrated embodiment, based on a particular trigger or event, the sender creates a profile identified by a unique ID. For instance, the trigger may be a scheduled communication from MTC devices. Alternatively, the event that triggers the profile ID creation may be the reception, within a predefined period of time, of a predefined number of messages related to a particular procedure regarding a number of subscribed stations belonging to the same group identified by a specific group ID. The profile ID is generated in such a way that it refers to a set of attributes, in particular to a set of common Information Elements.

As a second step, the sender communicates the profile ID and its features to the receiver, optionally along with instructions on when to delete the profile at the receiver, event type, etc. This notification can be either in the form of a dedicated signaling message or it can be inserted in the first relevant message sent after the profile creation. The profile notification message can be optionally acknowledged by the receiver. In response, the receiver stores the profile ID and its attributes. For the subsequent messages relevant to the profile, the sender does not insert the common Information Elements; instead it inserts only the profile ID. In this way, the amount of communication on the interface between the two entities can be reduced. It is noted that for the purpose of simplicity only two signaling messages related to UE1 and UE2, respectively, are depicted in Fig. 2. However, as will be appreciated by those skilled in the art, in real scenarios there will be much more messages related to a higher number of UEs. Generally, the higher the number of UEs being addressed by the procedure, the higher is the degree of congestion alleviation that can be achieved.

Storage of the profile and relevant information at the receiver and/or sender can be deleted either via a dedicated signaling messages or a trigger can be sent in the last message relevant to the profile sent from the sender to the receiver. Alternatively, the receiver/sender can delete information on the profile after a timeout during which no relevant message is received, after a specific timeout initially indicated by the sender or a third party, or after receiving a total number of messages, or based on an event detected by the receiver/sender. Using the same logic used in creating profile IDs, a node such as MME, SGSN, MSCA LR can create unique group IDs, in a dynamic way, for UEs based on the frequency at which their relevant messages of a particular procedure (e.g., mobility management procedure such as attach request, RAU, LAU, TAU requests, location update request, etc; session management procedure such as PDN connectivity request, activate PDP context request, etc) are transmitted. For instance, when a MME receives a number N of RAU request messages from N different UEs with a certain priority level during a specific period of time, the MME may create a group ID that will refer to this set of UEs and the ones that have similar subscription features and will be sending RAU request messages over another specific period of time. The MME may use this group ID to e.g., enforce any NAS level mobility management or session management congestion control handling, such as (extended) access class barring at RAN addressing UEs that are identified as belonging to the group ID. This operation can be carried out for example when the MME gets congested or when the MME becomes aware of the congestion of HLR/HSS based on long delay in responses from HLR/HSS, based on explicit notification from HLR/HSS, O&M or another mobile network node. The group IDs can be managed in the same way as the profile IDs: Its storage and relevant information can be deleted or updated either via a dedicated signaling message, based on a trigger, after a timeout during which no message relevant to the group ID and the procedure is received, after a specific timeout initially set up, after receiving a total number of messages relevant to the group ID, or based on an event detected by the node storing the group ID. Many modifications and other embodiments of the invention set forth herein will come to mind the one skilled in the art to which the invention pertains having the benefit of the teachings presented in the foregoing description and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

C l a i m s

1. Method for congestion control in mobile networks, wherein said mobile network includes a core network and a radio access network,

c h a r a c t e r i z e d i n that a core network node performs the following steps:

2. Method according to claim 1 , wherein said group ID is exchanged among core network nodes, which make a local binding between said group ID and the respective mobile terminals' identifiers.

3. Method according to claim 1 or 2, wherein the core network nodes use said group ID for enforcing a certain network policy regarding a particular network procedure, in particular mobility management procedure or session management procedure.

4. Method according to any of claims 1 to 3, wherein said group ID is constructed by a core network node upon receiving the subscription data of a mobile terminal that attaches to the mobile network.

5. Method according to any of claims 1 to 4, wherein the core network node provides said group ID to the relevant nodes in said radio access network.

6. Method according to any of claims 1 to 5, wherein said group ID is provided to the mobile stations.

7. Method according to claim 6, wherein the mobile stations use said group ID in following service requests, session setups, dedicated bearer requests and/or mobility management related procedures.

8. Method according to any of claims 1 to 7, wherein core network nodes dynamically create profile IDs that refer to a single or a set of attributes, in particular information elements, that are common in messages relevant to a group of mobile stations being identified by a unique group ID.

9. Method according to claim 8, wherein said profile IDs are used to replace said common information elements.

10. Method according to claim 8 or 9, wherein said profile ID creation is triggered by a scheduled communication from subscripted stations known by said mobile network a priori.

1 1. Method according to any of claims 8 to 10, wherein said profile ID creation is triggered by the reception of a number of messages of the same procedure with common Information Elements and regarding a number of subscripted stations belonging to the same group identified by a specific group ID and that is within a predefined period of time.

12. Method according to any of claims 8 to 1 1 , wherein said profile ID is created in form of a random value or as a function of said group ID of the relevant group of mobile stations.

13. Method according to any of claims 8 to 12, wherein the entity having created said profile ID - sender - communicates said profile ID to at least one other entity - receiver - in a profile ID notification message.

14. Method according to claim 13, wherein the notification includes the features of said profile ID, event type and/or instructions for said receiver when to delete said profile ID.

15. Method according to any of claims 1 to 14, wherein storage of said group ID and/or said profile ID is deleted and/or updated via dedicated signaling messages and/or based on a particular trigger.

16. Method according to any of claims 8 to 15, wherein said messages include messages on interfaces using Diameter.

17. Method according to any of claims 8 to 16, wherein said messages include messages regarding update location requests.

18. Method according to any of claims 8 to 17, wherein said messages include messages regarding cancel location requests.

19. Method according to any of claims 8 to 18, wherein said messages include messages regarding CC-Request commands.

20. Mobile network with congestion control, wherein said mobile network includes a core network and a radio access network,

c h a r a c t e r i z e d i n that core network nodes comprise means for identifying mobile stations having the same or similar subscription features and/or the same or a similar behavior towards the mobile network, and wherein said core network nodes are further configured to dynamically group at least a subset of said identified mobile stations and to assign said grouped mobile stations a unique group ID.

21. Network node for deployment in the core network of a mobile network, c h a r a c t e r i z e d i n that the network node is configured to execute a method according to any of claims 1 to 19.