TARGET CELL

TECHNICAL FIELD

Embodiments presented herein relate to mobility management, and particularly to methods, a mobility management node, a policy and charging rules function node, computer programs, and a computer program product for mobility management of a user equipment.

BACKGROUND

In communications networks, there may be a challenge to obtain good performance and capacity for a given communications protocol, its

parameters and the physical environment in which the communications network is deployed.

One parameter of the communications network may be the level of

congestion for different parts of the communications network, such as for different cells of a cellular communications network. In general terms, network nodes such as a Mobility Management Entity

(MME) or a Serving General packet radio service Support Node (SGSN) may receive and store congestion level information from a radio access network congestion awareness function (RCAF), or a similar function, or from the RAN or from the PCRF generating congestion levels for the congested cells for congested cells.

It has in solution 1.5.5 ^m 3GPP TR 23.705 for the Universal Terrestrial Radio Access Network (UTRAN) and the Evolved-UTRAN (E-UTRAN) been suggested that the RCAF sends the congestion level of the congested cells.

The congestion information may be used by a policy and charging rules function (PCRF) to initiate certain actions to overcome the congestion.

In UTRAN and in E-UTRAN, in the context of a handover or serving radio network subsystem (SRNS) relocation procedures, the information of the target cell (i.e., the served cell to which a user equipment (UE) is relocated to) is available if a Tracking Area (TA) Update or Routing Area Update (RAU) is performed at the end of the handover or SRNS relocation procedure.

Further, a Tracking Area Update (TAU) together with a handover will only occur if the target cell is in a different TA than the TA list that the UE is registered to in the source cell (i.e., the served cell to which the UE belongs to prior to being relocated). Also a Routing Area Update, together with a handover or SRNS relocation, will only occur if the target cell is in a different routing area than the routing area of the source cell. Other situations for triggering a Tracking Area update or a Routing area Update are described in 3GPP TS 23.401 version 12.4.0 clause 5.5.1.2.2 and 3GPP TS 23.060 version 12.4.0 clause 6.9.2.2.1.

The target radio access network node (such as an evolved NodeBs (eNBs) or a radio network controller (RNC)) is known at handover or SRNS relocation procedure. If only the UE is known at the eNB or RNC level (and not cell level) a best guess can be made on what congestion the UE is experiencing.

If a UE is moved into congestion (by mobility or going from idle to connected state) or out of congestion during the time interval between two consecutive congestion information messages are sent, then the action taken by the policy and charging rules function (PCRF) may be wrong (i.e. the policy decision may be that the bit rate level is too high or too low compared to the desired bit rate level based on the true congestion level of the UE), until the next congestion reporting notification is received by the PCRF.

Hence, there is still a need for an improved handling of cell information.

SUMMARY

An object of embodiments herein is to provide efficient delivery of cell information.

According to a first aspect there is presented a method for mobility management of a user equipment. The method is performed by a mobility management node. The method comprises acquiring, at time intervals, congestion indications for a user equipment. The method comprises acquiring at least one of an indication of cell change and change to connected state for the user equipment. The method comprises, in response thereto, notifying a Policy and Charging Rules Function (PCRF) of the user equipment about the indication for the user equipment.

Advantageously this enables cell information to be efficiently provided to the PCRF.

Advantageously, the congestion indications may be used by the mobility management node to build up the knowledge of congested cells or radio access network nodes, for example to build a congestion reporting list for cells and user equipment.

Advantageously, the notifying may be performed by the mobility

management node without any restriction on the reporting interval.

Advantageously this prevents uncertain and incorrect actions to be made by the PCRF in between ordinary update intervals of a radio access network congestion awareness function (RCAF), or a similar function, reporting congestion information to the PCRF. In turn this may enable notification of a proper and a more correct behaviour of user equipment in between

congestion reporting notifications which may be sent from the RCAF, or a similar function, to the PCRF. This may also reduce the risk for error situations in the PCRF of subscribers indicating a no longer valid congestion level.

According to a second aspect there is presented a mobility management node for mobility management of a user equipment. The mobility management node comprises a processing unit. The processing unit is configured to acquire, at time intervals, congestion indications for a user equipment. The processing unit is configured to acquire at least one of an indication of cell change and change to connected state for the user equipment. The processing unit is configured to, in response thereto, notify a Policy and Charging Rules Function (PCRF) of the user equipment about the indication for the user equipment.

According to a third aspect there is presented a computer program for mobility management of a user equipment, the computer program

comprising computer program code which, when run on a processing unit, causes the processing unit to perform a method according to the first aspect.

According to a fourth aspect there is presented a method for mobility management of a user equipment. The method is performed by a Policy and Charging Rules Function (PCRF). The method comprises acquiring, during at least one of at time intervals and at a congestion state change for a user equipment, and from a radio access network congestion awareness function (RCAF) or a similar function, ordinary congestion reporting notifications for the user equipment. The method comprises acquiring, independently of the ordinary congestion reporting notifications and from a mobility management node, a notification about at least one of cell change and change to connected state for the user equipment.

According to a fifth aspect there is presented a Policy and Charging Rules Function (PCRF) node for mobility management of a user equipment. The PCRF node comprises a processing unit. The processing unit is configured to acquire, during at least one of at time intervals and at a congestion state change for a user equipment, and from a radio access network congestion awareness function (RCAF), or a similar function, ordinary congestion reporting notifications for the user equipment. The processing unit is configured to acquire, independently of the ordinary congestion reporting notifications and from a mobility management node, a notification about at least one of cell change and change to connected state for the user equipment.

According to a sixth aspect there is presented a computer program for mobility management of a user equipment, the computer program

comprising computer program code which, when run on a processing unit, causes the processing unit to perform a method according to the fourth aspect.

According to a seventh aspect there is presented a computer program product comprising a computer program according to at least one of the third aspect and the sixth aspect, and a computer readable means on which the computer program is stored. The computer readable means may be non-transitory computer readable means.

It is to be noted that any feature of the first, second, third, fourth, fifth, sixth and seventh aspects may be applied to any other aspect, wherever

appropriate. Likewise, any advantage of the first aspect may equally apply to the second, third, fourth, fifth, sixth, and/or seventh aspect, respectively, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following detailed disclosure, from the attached dependent claims as well as from the drawings. Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to "a/an/the element, apparatus, component, means, step, etc." are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.

BRIEF DESCRIPTION OF THE DRAWINGS

The inventive concept is now described, by way of example, with reference to the accompanying drawings, in which: Fig 1 is a schematic diagram illustrating a communication network according to embodiments;

Fig 2 is a schematic diagram illustrating parts of a radio access network according to embodiments; Fig 3a is a schematic diagram showing functional units of a mobility management node according to an embodiment;

Fig 3b is a schematic diagram showing functional modules of a mobility management node according to an embodiment; Fig 4a is a schematic diagram showing functional units of a policy and charging rules function node according to an embodiment;

Fig 4b is a schematic diagram showing functional modules of a policy and charging rules function node according to an embodiment;

Fig 5 shows one example of a computer program product comprising computer readable means according to an embodiment; and

Figs 6, 7, 8 and 9 are flowcharts of methods according to embodiments.

DETAILED DESCRIPTION

The inventive concept will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the inventive concept are shown. This inventive concept may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the inventive concept to those skilled in the art. Like numbers refer to like elements throughout the description. Any step or feature illustrated by dashed lines should be regarded as optional.

Fig 1 is a schematic diagram illustrating a communications network 10 where embodiments presented herein can be applied. The communications network 10 of Fig 10 comprises a number of functional nodes and entities 11a, lib, 12, 13, 14, 15, 16, 17, 18, 19 the functionality thereof which as such is know in the art. Fig 1 further comprises a functional node 21 which may comprise any of the functional nodes 11a, and 11b. In Fig 1 also interfaces between the functional nodes and entities 11a, nb-19, and 21 are provided. The functionality of the functional nodes and entities na, nb-19, and 21 will be briefly summarized next.

In general terms, the radio access network (RAN) 16 implements a radio access technology (RAT) for a device (such as a mobile phone, a computer, or any remotely controlled machine) to connect to the communications network 10. Two examples of RANs 16 are UTRAN and E-UTRAN. Conceptually, the RAN 16 thus resides between the device and the core network (CN) part of the communications network 10. Devices such as mobile phones, computers, and remotely controlled machines are varyingly known as user equipment (UE), terminal equipment, mobile station (MS), etc. and are herein collectively referred to as a UE.

In general terms, the RAN 16 is associated with an Operations,

administration and management/maintenance functionality, denoted RAN OAM 15. In general terms, the packet data network (PDN) 14 provides services and data to a UE operatively connected to the RAN 16.

In general terms, the serving gateway (SGW) 17 routes and forwards user data packets, whilst also acting as the mobility anchor for the user plane during inter-eNB handovers and as the anchor for mobility between Long Term Evolution (LTE) and other 3GPP technologies.

In general terms, the PDN gateway (or policy and charging enforcement function (PCEF)) 18 provides connectivity from the UE to external packet data networks, such as the PDN 14, by being the point of exit and entry of traffic for the UE. In general terms, the Policy and Charging Rules Function (PCRF) 13 is a functional entity that encompasses policy control decision and flow based charging control functionalities. The PCRF 13 provides network control regarding the service data flow detection, gating, QoS (Quality of Service) and flow based charging (except credit management) towards the PCEF 18. In general terms, the Traffic Detection Function (TDF) 19 is a functional entity that performs application detection and reporting of a detected application.

In general terms, the serving GPRS support node (SGSN) lib or Mobility Management Entity (MME) 11a, as part of a mobility management (MM) node 21, is responsible for signalling from and to the UEs within its geographical service area. At least one of the SGSN 11b and the MME 11a may be part of a mobility management (MM) node 21. Its tasks include packet routing and transfer (only applicable for the SGSN lib), mobility

management (attach/detach and location management), logical link management, and authentication and charging functions. It is responsible for idle state UE paging and tagging procedure including retransmissions. It is involved in the bearer activation/deactivation process and is also responsible for choosing the SGW for a UE at the initial attach and at time of intra- LTE handover involving Core Network (CN) node relocation. It is responsible for authenticating the user. Further details of the MM node 21 will be disclosed below. The MM node 21 and the PCRF 13 may be operatively connected via a direct interface (for example denoted an MM-PCRF interface, as in Fig 1).

In general terms, a RAN congestion awareness function (RCAF) 12, or a similar function, collects (raw) data from the RAN OAM 15, such as congestion information originating from the cells of the RAN (see, Fig 2 and its description below), and transmits congestion reporting data including the congestion levels (per cells) to the PCRF 13, SGSN lib and MME 11a.

Fig 2 is a schematic diagram illustrating a radio access network (RAN) 20. The RAN 20 may be the RAN 16 of the communications network 10 in Fig 1. Particularly, Fig 2 schematically illustrates a handover (as schematically illustrated by the dotted line 25) of a user equipment (UE) 24 from a source cell 23a to a target cell 23b in the RAN 20. The source cell 23a is served by a source RAN node 22a. As schematically illustrated the source RAN node 22a serves cells SCi, SC2, and SC3. The target cell 23b is served by a target RAN node 22b. The source RAN node 22a and the target RAN node 22b may be embodied as evolved NodeBs (eNBs) or radio network controllers (RNCs). As schematically illustrated the target RAN node 22b serves cells TCi, TC2, and TC3. As the skilled person understands, although three cells SCi, SC2, and SC3 are associated with the source RAN node 22a, there may in practical implementations be less than three or more than three cells associated with the source RAN node 22a. As the skilled person also understands, although three cells TCi, TC2, and TC3 are associated with the target RAN node 22b, there may in practical implementations be less than three or more than three cells associated with the target RAN node 22b. The cells SCi, SC2, SC3, TCi, TC2, TC3 may collect and transmit congestion information towards the RCAF 12, or a similar function. The source RAN node 22a and the target RAN node 22b are operatively connected (through at least one interface) to a source MM node 21a, and a target MM node 21b. In turn, the source MM node 21a and the target MM node 21b are operatively connected (through at least one interface) to each other. The source MM node 21a and the target MM node 21b may be embodied as Mobility Management Entities (MMEs) 11a or Serving General packet radio service Support Nodes (SGSNs) 11b (see, Figure 1). Further details of the MM nodes 21a, 21b will be disclosed below.

According to 3GPP TS 23.401, there are two procedures in E-UTRAN for the MME 11a to get the cell-ID from the target eNB, namely the so-called

Location reporting procedure and the so-called Tracking Area Update (TAU) procedure when the UE is in the so-called connected state.

According to 3GPP TS 23.060, there are two procedures in UTRAN for the SGSN 11b to get the cell-ID from the target RNC, namely the so-called Location reporting procedure and the so-called Routing Area Update (RAU) procedure when the UE 24 is in the so-called connected state. Going from idle to connected state will make the MME 11a or SGSN 11b aware of the used RAN node (eNB or RNC) and cell information.

There may exist a time interval between two consecutive congestion reporting from the RCAF, or a similar function, 12 to the PCRF 13 when no new congestion information is sent to PCRF. If a UE 24 has moved in or out of congestion (mobility or idle to connected state) during this time, the PCRF 13 is unaware of the congestion state for this UE 24.

If a UE 24 is moved into congestion (by mobility or going from idle to connected state) or out of congestion during the time interval between two consecutive congestion information messages are sent from the RCAF 12, or a similar function, to the PCRF 13, then any action taken by the PCRF 13 may be wrong. For example, the policy decision of the PCRF 13 may be that the bit rate level is too high or too low compared to the desired bit rate level based on the true congestion level of the UE 24, until the next congestion reporting notification is received by the PCRF 13 from the RCAF 12 or a similar function.

The embodiments disclosed herein relate to mobility management of a user equipment 24. The proposed mobility management of the user equipment 24 may provide efficient delivery of cell information, thereby avoiding (or at least lowering the risk) that the PCRF makes an incorrect policy decision for the user equipment 24. In order to obtain such mobility management there is provided a mobility management node, a method performed by the mobility management node, a computer program comprising code, for example in the form of a computer program product, that when run on a processing unit, causes the processing unit to perform the method of the mobility

management node. In order to obtain such mobility management there is further provided a policy and charging rules function (PCRF) node 13, a method performed by the PCRF node 13, a computer program comprising code, for example in the form of a computer program product, that when run on a processing unit, causes the processing unit to perform the method of the PCRF node 13.

Fig 3a schematically illustrates, in terms of a number of functional units, the components of a mobility management (MM) node 21, 21a, 21b according to an embodiment. The mobility management node 21 may take the role of a source MM node 21a and/or a target MM node 21b depending on which functionality of the mobility management node 21 is requested. A processing unit 31 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), application specific integrated circuit (ASIC), field programmable gate arrays (FPGA) etc., capable of executing software instructions stored in a computer program product 51a (as in Fig 5), e.g. in the form of a storage medium 33. Thus the processing unit 31 is thereby arranged to execute methods as herein disclosed. The a storage medium 33 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory. The mobility management node 21, 21a, 21b may further comprise a communications interface 32 for communications with other entities and devices of the RAN 20 and/or the communications network 10 over interfaces such as any of Si-MME, Iu, Nq, Nq', S11, S4, and an interface to the a PCRF node 13. The processing unit 31 controls the general operation of the mobility management node 21, 21a, 21b e.g. by sending data and control signals to the communications interface 32 and the storage medium 33, by receiving data and reports from the communications interface 32, and by retrieving data and instructions from the storage medium 33. Other components, as well as the related

functionality, of the mobility management node 21, 21a, 21b are omitted in order not to obscure the concepts presented herein.

Fig 3b schematically illustrates, in terms of a number of functional modules, the components of a mobility management node 21, 21a, 21b according to an embodiment. The mobility management node 21, 21a, 21b of Fig 3b comprises a number of functional modules; an acquire module 31a, and a notify module 41b. The mobility management node 21, 21a, 21b of Fig 3b may further comprises a number of optional functional modules, such as a detect module 31c. The functionality of each functional module 3ia-c will be further disclosed below in the context of which the functional modules 3ia-c may be used. In general terms, each functional module 3ia-c may be implemented in hardware or in software. The processing unit 31 may thus be arranged to from the storage medium 33 fetch instructions as provided by a functional module 3ia-c and to execute these instructions, thereby performing any steps as will be disclosed hereinafter.

The mobility management node 21, 21a, 21b may be provided as a standalone device or as a part of a further device. For example, as noted above, the mobility management node 21, 21a, 21b may be provided in a Mobility Management Entity (MME) 11a. For example, as also noted above, the mobility management node 21, 21a, 21b may be provided in a Serving General packet radio service Support Node (SGSN) 11b. Hence the herein disclosed mobility management node 21, 21a, 21b may incorporate the functionality of the MME 11a and/or the SGSN lib and may thus replace the MME 11a and/or the SGSN 11b. According to one embodiment the source MM node 21a and the target MM node 21b is one and the same MM node 21a, 21b. The herein disclosed mobility procedures may thus either involve a change of

MME/SGSN or not. Fig 4a schematically illustrates, in terms of a number of functional units, the components of a policy and charging rules function (PCRF) node 13 according to an embodiment. A processing unit 41 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), application specific integrated circuit (ASIC), field programmable gate arrays (FPGA) etc., capable of executing software instructions stored in a computer program product 51b (as in Fig 5), e.g. in the form of a storage medium 43. Thus the processing unit 41 is thereby arranged to execute methods as herein disclosed. The a storage medium 43 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory. The PCRF node 13 may further comprise a communications interface 32 for communications with other entities and devices of the RAN 20 and/or the communications network 10 over interfaces such as any of Np, Rx, Sd, Gx, and an interface to an MM node 21 (and thus an interface to any of an MME 11a and an SGSN lib). The processing unit 41 controls the general operation of the PCRF node 13 e.g. by sending data and control signals to the communications interface 42 and the storage medium 43, by receiving data and reports from the communications interface 42, and by retrieving data and instructions from the storage medium 43. Other components, as well as the related functionality, of the PCRF node 13 are omitted in order not to obscure the concepts presented herein.

Fig 4b schematically illustrates, in terms of a number of functional modules, the components of a PCRF node 13 according to an embodiment. The PCRF node 13 of Fig 4b comprises an acquire module 41a. The PCRF node 13 of Fig 4b may further comprises a number of optional functional modules, such as any of a determine module 41b, an update module 41c, and an identify module 4 id. The functionality of each functional module 4ia-d will be further disclosed below in the context of which the functional modules 4ia-d may be used. In general terms, each functional module 4ia-d may be implemented in hardware or in software. The processing unit 41 may thus be arranged to from the storage medium 43 fetch instructions as provided by a functional module 4ia-d and to execute these instructions, thereby performing any steps as will be disclosed hereinafter.

Figs 6 and 7 are flow charts illustrating embodiments of methods for mobility management as performed by the mobility management node 21, 21a, 21b. Figs 8 and 9 are flow charts illustrating embodiments of methods for mobility management as performed by the PCRF node 13. The methods are

advantageously provided as computer programs 52a, 52b. Fig 5 shows one example of a computer program product 51a, 51b comprising computer readable means 53. On this computer readable means 53, at least one computer program 52a, 52b can be stored, which at least one computer program 52a, 52b can cause the processing units 31, 41 and thereto

operatively coupled entities and devices, such as the communications interfaces 32, 42 and the storage media 33, 43, to execute methods according to embodiments described herein. The computer programs 52a, 52b and/or computer program products 51a, 51b may thus provide means for performing any steps as herein disclosed. In the example of Fig 5, the computer program product 51a, 51b is illustrated as an optical disc, such as a CD (compact disc) or a DVD (digital versatile disc) or a Blu-Ray disc. The computer program product 51a, 51b could also be embodied as a memory, such as a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), or an electrically erasable programmable read-only memory (EEPROM) and more particularly as a non-volatile storage medium of a device in an external memory such as a USB (Universal Serial Bus) memory. Thus, while the at least one computer program 52a, 52b is here schematically shown as a track on the depicted optical disk, the at least one computer program 52a, 52b can be stored in any way which is suitable for the computer program product 51a, 51b.

Reference is now made to Fig 6 illustrating a method for mobility

management of a user equipment 24 according to an embodiment. The method is performed by a mobility management (MM) node 21, 21b.

The method comprises, in a step S102, acquiring, at time intervals, congestion indications for a user equipment 24. Examples of such time intervals will be provided below. Examples of from where the congestion indications may be acquired will be provided below. The method further comprises, in a step S104, acquiring at least one of an indication of cell change and change to connected state for the user equipment 24. The congestion indications may be used by the MM node 21, 21b to build up the knowledge of congested cells or RAN nodes, for example to build a congestion reporting list for cells and user equipment 24. The acquiring in step S104 serves as a trigger for the mobility management node 21 to send a notification to the PCRF 13. The method further comprises, in a step S106, notifying a Policy and Charging Rules Function (PCRF) of the user equipment 24 about the indication for the user equipment 24. Step S106 is thus triggered by step S104. Examples of further information that may be transmitted in the notification in step S106 will be provided below. The notifying in step S106 may be performed by the MM node 21, 21b without any restriction on the reporting interval.

Embodiments relating to further details of mobility management will now be disclosed. The congestion indications may be acquired at predetermined time intervals. The predetermined time intervals may or may not be regular intervals. For example, the acquiring in step S102 may occur separated by ni seconds during a first period, separated by n2 seconds during a second period, and separated by ηβ seconds during a third period, and so on, where ni, n2, and n2 may take the same or different values. Thus, the predetermined time interval may mean that the acquiring in step S102 is always done separated by a fixed interval of ni=n2=n2 seconds. Alternatively the predetermined time interval may mean that the acquiring in step S102 is done separated by a varying interval of ni, n2, or ηβ seconds. Yet alternatively the predetermined time interval may mean that the acquiring in step S102 is done separated by a varying interval that is predetermined by some function and/or network node in the network 10. In turn the function and/or network node may

predetermine the time intervals based on various parameters, conditions, information from other network nodes/functions, etc. According to embodiments the MM node 21, 21b is configured to notify the PCRF 13 of further information. Examples relating thereto will be described next.

According to an embodiment the notifying in step S106 comprises

information about a congestion level change for the user equipment 24. The congestion level change may pertain to one of a change from a state of no congestion to a state of congestion, a change from a state of congestion to a state of no congestion, a change from a state of a first level of congestion to a state of a second level of congestion for the user equipment 24, a change from an unknown state of congestion to a state of congestion, a change from an unknown state of congestion to a state of no congestion. The congestion indications may thus relate to unknown congestion, no congestion, a first level of congestion, and a second level of congestion, and so on, for the user equipment 24.

For example, the notifying may comprise information about at least one of: identity of a radio access network (RAN) node 22a, 22b of the user equipment 24, identity of a cell 23a, 23b of the user equipment 24, and identity, such as an International Mobile Subscriber Identity (IMSI) of the user equipment 24. For example, the notifying may comprise information about a congestion level of at least one of: a RAN node 22a, 22b of the user equipment, and a cell 23a, 23b of the user equipment 24. For example, the notifying may comprise information about at least one of: location of the user equipment 24, congestion level state of the user equipment 24, and a UE event (such as a state change from idle to connected state or vice versa) of the user equipment 24. In this respect the wording "cell of the user equipment" shall be interpreted as a cell in which the user equipment is located (immediately before or after handover/relocation). Further, in this respect the wording "RAN node of the user equipment" shall be interpreted as a RAN node providing network coverage to the user equipment (in either idle or connected state). According to embodiments the RAN node 22b is an eNB. According to alternative embodiments the RAN node 22b is an RNC.

The herein disclosed embodiments are applicable, for example, in mobility procedures involving a handover procedure, an SRNS relocation procedure, and a procedure including SRNS relocation. During or after a handover procedure or an SRNS relocation procedure or a procedure including SRNS relocation, the target eNB/RNC or the target cell information may be detected by the MM node 21. For example, the congestion indications may be acquired by detecting a congestion indication during a handover of the user equipment from a source cell to a target cell. For example, the congestion indications may be acquired during a relocation of the user equipment from a source cell to a target cell. The relocation may be a serving radio network sub- system, SRNS, relocation. For example, the congestion indications may be acquired during a procedure including a serving radio network sub-system, SRNS, relocation of the user equipment from a source cell to a target cell. The congestion indications may be acquired as congestion notifications. The congestion notifications may be acquired from the RCAF 12 or a similar function. The congestion indications may be acquired from a RAN node 22a, 22b of the user equipment 24. The congestion notifications may be provided as processed congestion data from the RCAF 12 or a similar function or a PCRF different from the PCRF notified about the indication for said user equipment in step S106. For example, the RCAF 12, or a similar function, may be enabled to acquire congestion indications and therefrom generate congestion notifications which may be provided, for example, to the MM node 21. The congestion notifications may additionally or alternatively be provided by the RCAF 12, or a similar function, to the PCRF 13 or to a PCRF, such as a PCRF different from, or identical to, the PCRF notified about the indication for said user equipment in step S106. The PCRF different from the PCRF notified about the indication for said user equipment in step S106 may then in turn provide the congestion notification(s) to the MM node 21.

Congestion indications may be regarded as raw congestion data whilst congestion notifications may be regarded as processed congestion data.

The herein disclosed embodiments are applicable, for example, in both a roaming situation and in a non-roaming situation. For example, according to a roaming situation the target cell 23b may be served by different network operator than the network operator of the UE 24. For example, according to a non-roaming situation the target cell 23b may be served by a network operator different than the network operator of the UE 24.

The herein disclosed embodiments are applicable, for example, in mobility procedures when the user equipment 24 enters E-UTRAN and UTRAN as well as within E-UTRAN and UTRAN. Embodiments relating thereto will now be disclosed in turn. As will be further disclosed below, the mobility procedure may be a handover procedure or an SRNS relocation procedure or a procedure including SRNS relocation. l8

The mobility procedure may take part within E-UTRAN (i.e., where the source cell 23a and the target cell 23b are within E-UTRAN). Hence, according to an embodiment the source cell 23a is served by a source evolved NodeB (eNB) and the target cell 23b is served by a target eNB. The mobility procedure may take part within UTRAN (i.e., where the source cell 23a and the target cell 23b are within UTRAN). Hence, according to an embodiment the source cell 23a is served by a source Radio Network

Controller (RNC), and the target cell 23b is served by a target RNC.

The mobility procedure may involve an inter RAT handover to E-UTRAN (i.e., where the source cell 23a is not within E-UTRAN, and where the target cell 23b is with E-UTRAN). Hence, according to an embodiment the target cell 23b is served by a target eNB, and the source cell 23a is served by a network node using a different radio access technology (RAT) than used by the target eNB. The mobility procedure may involve an inter RAT handover to UTRAN (i.e., where the source cell 23a is not within UTRAN, and where the target cell 23b is within UTRAN). Hence, according to an embodiment the target cell 23b is served by a target RNC, and the source cell 23a is served by a network node using a different RAT than used by the target RNC. Reference is now made to Fig 7 illustrating methods for mobility

management of a user equipment 24 as performed by the mobility

management (MM) node 21, 21b according to further embodiments.

As noted above, the congestion indications may be triggered by an event. Particularly, according to embodiments, UE events are used as notification conditions. Thus, the processing unit 31 of the MM node 21, 21b may be configured to, in an optional step Si04a, detecting an event of the user equipment 24 pertaining to at least one of tracking area update of the user equipment, and routing area update of the user equipment. The processing unit 31 of the MM node 21, 21b may additionally or optionally be configured to, in an optional step Si04b detect an event of the user equipment pertaining to one of a handover, a serving radio network subsystem, SRNS, relocation, or a procedure involving SRNS relocation of the user equipment.

Particular examples based on the above disclosed embodiments and relating to how and when the congestion indications may be acquired by the MM node 21 will now be disclosed. Any congestion change may be a consequence of the user equipment 24 changing from idle state to connected state, or taking part in a handover, or taking part in an SRNS relocation, or taking part in a procedure including SRNS relocation. Examples of information the MM node 21, 21b may notify the PCRF 13 have been provided above; the eNB/RNC or cell for the user equipment 24, the congestion level associated with the eNB/RNC and/or the cell, an UE event (e.g., the user equipment 24 changing from idle state to connected state, or taking part in a handover, or taking part in an SRNS relocation, or taking part in a procedure including SRNS relocation occurs). As noted above, the MM node 21 may notify the PCRF 13 about such information. There may be conditions when the MM node 21 should notify the PCRF node 13 about such information.

For example, the MM node 21 may notify the PCRF node 13 about such information if the user equipment 24 performs a Tracking Area Update or Routing Area Update and the congestion level from the source (old) cell 23a is a different value then the target (new) congestion level status, associated with the target (new) cell 23b and/or RAN node 22b (eNB/RNC) as stored in the MM node 21, the congestion level (associated with the target (new) cell 23b and/or RAN node 22b (eNB/RNC) will be reported to the PCRF 13.

If there is no congestion level reported (stored in the source (old) MM node 21a (MME 11a or SGSN lib) for the source (old) cell 23a and/or RAN node 22a (eNB/RNC) then there will be a congestion level reporting from the target (new) MM node 21b (MME 11a or SGSN lib) to the PCRF 13. Absence of a congestion level associated with the target (new) cell 23b and/or RAN node 22b (eNB/RNC) in the target (new) MM node 21b (MME 11a or SGSN 11b) may be treated as "no congestion" in the target (new) cell 23b and/or RAN node 22b (eNB/RNC). Alternatively, if there is a congestion level, associated with the target (new) cell 23b and/or RAN node 22b (eNB/RNC), and stored in the MM node 21 (MME 11a or SGSN lib) it may be reported to the PCRF 13 independently of the congestion level associated with the source (old) cell 23a and/or RAN node 22a (eNB/RNC), for example if the

congestion level associated with the source (old) cell 23a and/or RAN node 22a (eNB/RNC) is not known by the target (new) MM node 21a (MME 11a or SGSN 11b).

For example, the MM node 21 may notify the PCRF node 13 about such information if the user equipment 24 changes from idle to connected state and the congestion level from the previous congestion reporting for that user equipment 24 (for example as provided by a first instance of the acquiring in step S102 or a previous acquiring in step S104) is a different value than the latest congestion level (stored in MM node 21), associated with the cell/RAN node, the congestion level, associated with the cell/RAN, may be reported by the MM node 21 to the PCRF 13. If there is no previous congestion level reported (stored in MM node 21 for that particular user equipment 24) then only if the existing congestion level, associated with the cell/RAN, indicates a congestion, there may be a notification from the MM node 21 to the PCRF 13. Absence of an existing congestion level may be treated as "no congestion". Alternatively, if there is an existing congestion level, associated with the cell/RAN, and stored in the MM node 21 it may be notified by the MM node 21 to the PCRF 13.

For example, the MM node 21 may notify the PCRF node 13 about such information if the user equipment 24 experiences a handover, an SRNS relocation, a procedure including SRNS relocation and the congestion level from the source (old) cell 23a and/or RAN node 22a (eNB/RNC) is a different value than the existing congestion level status for the target (new) cell 23b and/or RAN node 22b (eNB/RNC) stored in the MM node 21 for that user equipment 24, the congestion level, associated with the target (new) cell 23b and/or RAN node 22b (eNB/RNC) may be reported to the PCRF 13. If there is no congestion level reported (stored in the source (old) MME node 21a (MME na or SGSN lib) for the (old) cell 23a and/or RAN node 22a

(eNB/RNC) then the congestion level, associated with the target (new) cell 23b and/or RAN node 22b (eNB/RNC) may be notified by the target (new) MME node 21b (MME 11a or SGSN lib) to the PCRF 13. Absence of an existing congestion level may be treated as "no congestion". Alternatively, if there is an existing congestion level, associated with the cell/RAN, and stored in the MM node 21 it may be notified by the MM node 21 to the PCRF 13.

Reference is now made to Fig 8 illustrating a method for mobility

management of a user equipment 24 according to an embodiment. The method is performed by a policy and charging rules function (PCRF) node 13.

The processing unit 41 of the PCRF node 13 is configured to, in a step S202, acquire ordinary congestion reporting notifications for a user equipment 24. The ordinary congestion reporting notifications are acquired during at least one of at time intervals and at a congestion state change for the user equipment 24. The ordinary congestion reporting notifications are acquired from a radio access network congestion awareness function (RCAF) 12 or a similar function implementing the functionality of the RCAF 12.

The processing unit 41 of the PCRF node 13 is configured to, in a step S204, acquire, a notification about at least one of cell change and change to connected state for the user equipment 24 from a mobility management node 21, 21b and independently of the ordinary congestion reporting notifications.

Hence, if the PCRF 13 detects a congestion change for the user equipment 24, as reported from either an MME 11a or an SGSN lib, the new congestion information may be stored and taken into account. Reference is now made to Fig 9 illustrating methods for mobility

management of a user equipment 24 as performed by the policy and charging rules function (PCRF) node 13 according to further embodiments.

The PCRF 13 may take action (such as a policy decision) according to the notification. Hence, according to an embodiment the processing unit 41 of the PCRF node 13 is configured to, in an optional step S206, determine a policy decision for the user equipment 24 based on the notification for the user equipment 24.

The PCRF 13 may prioritize congestion level change over ordinary

notifications. Hence, according to an embodiment the policy decision for the user equipment UE overrules a policy decision determined based on the ordinary congestion reporting notifications for the user equipment 24.

The PCRF 13 may clean up old subscriber congestion information stored in the PCRF 13, for example when the user equipment 24 is not being in a congestion cell 23a, 23b or RAN node 22a, 22b any longer. Particularly, according to an embodiment the notification for the user equipment 24 comprises information about a UE event the user equipment 24. The processing unit 41 of the PCRF node 13 may then be configured to, in an optional step S208, update subscriber congestion information of the user equipment 24 based on the UE event of the user equipment 24.

The PCRF 13 may find old congestion information based on the notification. For example, the UE event (connected state, handover, SRNS relocation, SRNS relocation related) is used by PCRF to find out if there is some old information such as in a mobility situation where the UE has changed congestion level and then the congestion mitigation actions, PCC rules, etc. needs to be changed. Hence, in embodiments where the notification for the user equipment 24 comprises information about a UE event of the user equipment 24, the processing unit 41 of the PCRF node 13 may be configured to, in an optional step S210, identify subscriber congestion information of the user equipment 24 previously stored by the PCRF 13 based on the UE event of the user equipment 24. Other examples are where the user equipment 24 enters connected state and needs to quickly be throttled due to congestion (first example) or where the user equipment 24 goes to a non-congested situation (second example) and in such situations perform correct congestion mitigation (first and second example) or not (first example). The UE event may be combined with the location information cell/eNB/RNC etc. to find the stored congestion information for the user equipment 24.

In summary, there have been disclosed methods for mobility management of a user equipment according to which, for example, if a user equipment 24 changes congestion state, changes to a congestion state or changes to a non- congestion state during the time interval between two consecutive congestion indications, notifications are sent to the PCRF 13 from the RCAF 12 or a similar function, the (target) MM node 21 (such as the (target) MME 11a or the (target) SGSN 11b)) is aware of the target RAN node 22 (such as the target eNB or target RNC) or target cell 23b. According to some embodiments disclosed herein the MM node 21 detects this congestion change and sends a notification which, for example may indicate the congestion change, directly to the PCRF 13, for example over a MM-PCRF interface. The PCRF 13 may then take the correct action, in between two ordinary consecutive congestion reporting sent from the RCAF or a similar function 12 to PCRF 13.

Reasons for a congestion change may, for example, be due to mobility in the connected state or going from idle state to connected state.

For example, mobility of a user equipment 24 in a connected state (for example, as part of handover, SRNS relocation or a procedure including SRNS relocation) and/or when the user equipment 24 goes from Idle to connected state may result in a report from the MM node 21 to the PCRF 13 if the MM node 21 detects a congestion change for the user equipment 24. The report may comprise information such as, but not limited to, the location, congestion level state and mobility UE event. The inventive concept has mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the inventive concept, as defined by the appended patent claims. For example, some of the herein disclosed embodiments relate to examples where the PCRF 13 comprises updated congestion level information per cell. Hence, the congestion indications may be acquired from the PCRF that is notified about the indication for said user equipment, or from another PCRF. The PCRF may thus be configured to provide congestion indications to the MM node 21. The MM node 21 (MME 11a or SGSN lib) may by the PCRF 13 be requested to send cell changes for specific user equipment to the PCRF 13.

Further, some of the herein disclosed embodiments relate to examples where the RCAF 12, or similar information, sends congestion information to the PCRF 13 without sending congestion information to the MM node 21, In such cases the MM node 21 may act as a proxy between the RCAF 12 and the PCRF 13 and be configured to acquire congestion indications by extracting congestion information sent from the RCAF 12 to the PCRF 13. According to the schematic diagram of Fig 1 there is an interface denoted Np between the RCAF 12 and the PCRF 13. This interface should thus be regarded as optional since when the MM node 21 acts as proxy between the RCAF 12 and the PCRF 13 this interface is replaced by the interfaces Nq/Nq' and MM-PCRF.

It is also understood that, for example, the terms "source" and "target" may be replaced by the terms "old", "previous", "past", or "current" and "new", "current", "next", or "future", respectively, etc. as long as the technical meaning of the terms is consistent with the herein disclosed context in which terms "source" and "target" are used.