WO2014086396A1

WO2014086396A1 - Enabling mobility setting negotiations for different user groups

Info

Publication number: WO2014086396A1
Application number: PCT/EP2012/074348
Authority: WO
Inventors: Krzysztof Kordybach; Richard Waldhauser; Bernhard Wegmann; Ingo Viering
Original assignee: Nokia Solutions And Networks Oy
Priority date: 2012-12-04
Filing date: 2012-12-04
Publication date: 2014-06-12

Abstract

An eNB uses the Mobility Settings Change procedure to instruct another eNB to change the mobility configuration (i.e. the handover trigger) only for UEs of a defined UE group; the UE group identification is included in a Mobility Information Information Element (IE).

Description

DESCRIPTION Title

Enabling mobility setting negotiations for different user groups

Field of the Invention

The present invention relates to an apparatus, a method and a computer program product for providing enabling mobility setting negotiations for different user groups, in particular for the self organizing networks (SON) and mobility load balancing (MLB) use case.

Related background Art

The following meanings for the abbreviations used in this specification apply:

CRE cell range expansion eNB enhanced Node-B

HetNet Heterogeneous networks

HO Handover LTE Long term evolution

LTE-A LTE-Advanced

MLB Mobility load balancing

MRO Mobility robustness optimization

NRT Non real time OAM Operation and maintenance RT Real time

SON Self organized network

UE User equipment

Embodiments of the present invention relate to LTE and LTE-A, and in more detail to self organizing networks (SON).

One of the SON features is MLB which is based on a mobility change procedure that enables negotiating HO settings between two cells.

The mobility setting change procedure, specified at X2AP, enables an eNB to request its neighbour eNB to change HO settings of a given cell. The negotiations concern a pair of cells under the control of the involved eNBs. The requesting eNB informs which of its own cells is the subject of the procedure and it may inform also of own planned change. The change itself is expressed as a difference or differential values ("delta"), i.e. not absolute values, but a relative step is informed. The requested eNB may approve the request or reject it - in the latter case, if the proposed delta was too big, the rejecting eNB may offer boundaries of the change. The procedure has been enabled as the main tool for MLB, though in theory it may also be applied for MRO.

The main problem of the procedure is that it works globally, i.e. it assumes mobility configuration for all the UEs is the same, or that the same change is to be applied to all UEs.

That is, SON use cases in previous releases (Rel.9-Rel.10) enabled automatic detection of problems and correction assuming "typical user", i.e. given policy was assumed to work for any UE active in the network. However, growing differences between capabilities of UEs of different releases combined with different services (including real-time services) and HetNet deployments (assumed almost default now) proved that approach overly simplistic. Thus, the current procedures are rather inflexible.

Summary of the Invention

Embodiments of the present invention address the situation where the change proposed in the mobility setting change procedure must be applied to all UEs served within the considered cell. They aim at overcoming the above-described problems and to achieve more flexible mobility setting negotiations carried out for different user groups, as for SON MLB, for example.

According to a first aspect of the invention, an apparatus is provided which comprises a connection unit configured to provide a connection to a communication network, and a processor configured to control a cell serving at least one user equipment, to assign the at least one user equipment to at least one user group, and to negotiate mobility configurations with a network control element controlling another cell based on the user group.

According a second aspect of the present invention, a method is provided which comprises controlling a cell serving at least one user equipment, assigning the at least one user equipment to at least one user group, and negotiating mobility configurations with a network control element controlling an- other cell based on the user group.

Modifications of the first and second aspects are defined in the dependent claims.

According to a third aspect of the present invention, a computer program product is provided which comprises code means for performing a method according to the second aspect and/or its modifications when run on a processing means or module. The computer program product may be embodied on a computer-readable medium.

Brief Description of the Drawings

These and other objects, features, details and advantages will become more fully apparent from the following detailed description of embodiments of the present invention which is to be taken in conjunction with the appended drawings, in which:

Fig. 1 shows simplified structures of eNBs involved in mobility setting negotiations according to an embodiment of the present invention.

Fig. 2 shows a signal flow illustrating example mobility setting negotiations according to an embodiment of the present invention.

Detailed Description of embodiments

In the following, description will be made to embodiments of the present invention. It is to be understood, however, that the description is given by way of example only, and that the described embodiments are by no means to be understood as limiting the present invention thereto.

However, before explaining embodiments of the present invention in detail, the problem to be solved by the invention is described in more detail.

As mentioned above, the current procedure for SON MLB is performed globally, i.e. it assumes the negotiated mobility configuration change for all the UEs in the cell is the same. In reality, this may not be true because of very different reasons: MRO correction may be needed for some UEs only;

Policy for HO actions may be different for different services;

Some UEs may not be capable of being handed over to some cells, e.g. if cell range expansion (CRE) is used.

Therefore, it is preferable to enable mobility setting change to be applied to some types of UEs only. This may apply to statically defined groups (e.g. RT/NRT service, CRE-capable / non-capable UEs, etc.), or to groups defined by operator.

There is also a topic likely to be addressed in Rel.12 SON, namely "SON for user groups". SON for user groups aims at enabling differentiating SON policies (and actions) among users, i.e. to enable SON to apply different policies for different users/UEs. First step was made in Rel.1 1 , where MRO mechanism was equipped with features enabling tracing user types (or even particular UEs) and apply corrections to those that have problems.

The solution enabled for MRO in Rel.1 1 is based on Mobility Information IE, which is a 32 bit string and can be passed in the HO REQUEST to the target. If that UE later fails and the cause of the failure is recognized as too early HO or a HO to wrong cell, the Mobility Information is returned to the responsible eNB in the HO REPORT. The intention is clear: the source may assign a short info about the user's type/group (e.g. UE's capabilities) and when it fails, it will be recalled. This is partly described in PCT/EP2012/051434, for example.

In the following, a general embodiment of the present invention is described by referring to Fig. 1 . In particular, Fig. 1 shows two eNBs 1 and 2 (eNB_A and eNB_B), which may be involved in a mobility setting negotiation. The structure of both eNBs is the same.

The eNBs are examples for an apparatus applying an embodiment of the present invention. It is noted that an eNB is only an example, and also other suitable network elements could be applied. Moreover, the apparatus may also be only a part of the eNB.

The eNB 1 (2) comprises a processor 1 1 (21 ) and a connection unit 12 (22). The connection unit 12 (22) is configured to provide a connection to a communication network.

In the following, eNB_A (denoted by reference sign 1 ) is taken as an example. The processor 1 1 is configured to control a cell serving at least one user equipment (denoted by reference number 3), to assign the at least one user equipment to at least one user group, and to negotiate mobility configurations with a network control element (e.g., eNB_B denoted by 2), which controls another cell, with respect to the user group.

Thus, negotiation of the mobility configuration is effected based on a user group basis. The user groups can be freely formed so that a large flexibility can be achieved.

Optionally, the eNB_A 1 and the eNB_B 2 may further comprise memories 13 and 23 re- spectively, for storing data and programs, by means of which the respective processors 1 1 and 21 may carry out their corresponding functions.

The negotiation may be carried out such that a request for changing a mobility configura- tion regarding at least one user group may be sent from eNB_A to eNB_B. The eNB_B may then decide whether to accept the request or not and send a corresponding response to eNB_A. In case the requested change of the mobility configuration is not accepted, eNB_A may suggest a different mobility configuration to eNB_B.

The user group mentioned in the mobility configuration negotiation described above may be identified with a mobility information, and, in more detail, may be in a mobility information element (e.g., Mobility Information IE). Mobility information may be used to identify any UE characteristics: mobility configuration, service, terminal capabilities etc. It may be defined by network configuration how the value is assigned and what it identifies.

In the following, a more detailed embodiment of the present invention is described.

The main idea of the present embodiment is an extension of the mobility change proce- dure to enable the application of MLB to dedicated user groups. It can be based on the groups used for MRO purposes, but in general it can be a very dynamic association of users, because every eNB may define own groups.

The solution according to the present embodiment uses the Mobility Information IE. The Mobility Information is a value assigned at the eNB to a group of UEs in order to identify that group. The assignment of the mobility information IE to a given UE group may be based on, for example, dedicated handover thresholds used for these UEs and/or other values which are necessary for defining mobility of an user equipment. Alternatively, the same Mobility Information may be assigned to UEs using the same service. In a particular embodiment, the eNB may assign different Mobility Information for each served UE thus forming single-UE groups and enabling per-UE mobility negotiations.

If an eNB assigns a certain value of the Mobility Information to some of the UEs being connected or camping in a cell controlled by the eNB, the same value may be used when mobility setting change is requested. In that case, the eNB receiving the X2 MOBILITY CHANGE REQUEST would consider and possibly apply the requested change only to users that have arrived or will arrive from the sender and that bear the corresponding Mobility Information value.

An example is described in the following by referring to Fig. 2 showing a signaling flow between two eNBs (eNB_A and eNB_B, e.g., as shown in Fig. 1 ), operating cells A and B.

In S1 , eNB_A hands over a UE_1 to eNB_B with assigned Mobility Information (Ml) "X".

In S2, eNB_A requests eNB_B to change mobility configuration for users "X". In S3 eNB_B accepts the change; and eNB_B applies new mobility configuration for UE_1 . If no UE has been handed over to the eNB_B with Ml "X" (i.e., S1 did not happen), the new settings are not applied to any UE served or camping in eNB_B. In particular in a scenario where the operator configured (via OAM) all its eNBs to create the same groups and to identify them identically, eNB_B may apply the change to its users that are identified as belonging to the group identified with the mobility information "X".

In S4, eNB_A hands over a UE_2 to eNB_B with assigned Ml Ύ", and in S5, eNB_B uses _default_ mobility settings for this UE.

In S6, eNB_A hands over a UE_3 to eNB_B with assigned Ml "X". Therefore, in S7, eNB_B uses modified mobility settings for this UE;

The solution bears certain challenges, related mainly to the fact that eNB receiving the MOBILITY CHANGE REQUEST (eNB_B above) with certain Mobility Information does not know how this value was derived, unless the operator configured all eNBs to use particular Mobility Information for UEs of given characteristics. Therefore, it may serve UEs that would be associated at the sender (eNB_A above) to the group, but the receiver does not know it. In that case, the receiver may try to hand over such UE to the sender using old/default mobility configuration; or it may assign an own group to those UEs and to try to negotiate colliding mobility setting change with the sender. Below both cases are considered.

The first challenge has to be considered in the context of the scenarios where mobility setting change is applied: these are overload situations, when an eNB tries to hand over certain types of UEs to a neighbour for offloading. Therefore, if that neighbour sends a HO REQUEST with UE context hinting the UE belongs to the group that is rather to be kept out, the request may be rejected. The rejection may also inform the UE belongs to a group that has previously been associated with negotiated mobility settings.

Thus, when eNB_A has assigned given mobility information to a group of UEs and it receives a handover request for a user equipment (e.g., UE 3) sent from eNB_B corresponding to a UE that would belong to the UE group defined in eNB_A, the eNB_A may reject the handover request, if the eNB_A has negotiated the mobility settings for this group before. In that case, a rejection response is sent to the requesting network control element, wherein the rejection response may comprise information regarding the mobility information or a cause value indicating that a handover of this user equipment is not accepted because it belongs to a group whose mobility settings have been modified.

The second case, when the peer eNB allocates own user group/type to UEs with the same characteristics and negotiates conflicting mobility setting change should also be considered in the context of overload: this basically means that both eNBs are overloaded and try to resolve it in the same way. It is therefore unlikely that an overloaded eNB will accept any mobility setting request - so the conflict will not arise. If it does, however, e.g. due to bad implementation or configurations, most likely no HO will be executed anyway: the moment first UE is tried to be handed over, it will be rejected, as described above.

Both of the challenges can also be eliminated, if the operator configures eNBs to use the same Mobility Information values for UEs of the same characteristics. The solution according to the detailed embodiment as described above comprises the following elements:

Assignment of the Mobility Information to a UE or a group of UE served or camping in the eNB and passing it in the HANDOVER REQUEST, when a UE is handed over; the Mobility Information defined for MRO may be re-used here;

Addition of the Mobility Information to the MOBILITY CHANGE REQUEST; and

Optionally: addition of Mobility Information or a special cause value to the HANDOVER PREPARATION FAILURE.

Therefore, a potential solution would be to extend the X2AP MOBILITY CHANGE REQUEST message with an IE enabling matching with the Mobility Information IE. The IE may correspond to the Mobility Information IE that is part of the X2AP HO REQUEST (32 bit string). If the option of enhancing of the rejection is considered, then the X2AP HAND- OVER PREPARATION FAILURE message should also bear that new IE, or, alternatively, a new cause value should be defined to inform the requesting eNB the HO failed because the UE belongs to a group that is to be offloaded.

The idea is based on the allocation of the UEs to groups, or forming the Mobility Infor- mation. This is a similar problem as in case of existing Rel.1 1 MRO solution and therefore there can be the same assignment for both, MRO and MLB. The actual forming of the groups and/or of the mobility information is, however, not particularly limited, and will be up to the eNB implementation.

The advantage of this solution compared with the prior art is the flexibility. An eNB is free to define any group which it considers optimal, or may be configured by the operator to use network-wide groups. If the group has been defined locally in the eNB, it does not have to be agreed with the neighbour - just as the Rel1 1 solution for MRO. Due to this commonality to MRO, the MLB group distinction can directly follow the MRO definition, which is a significant benefit since obviously MRO and MLB have a very tight collaboration (both change the cell boundary).

It is noted that the embodiments and the present invention in general is not limited to the specific examples given above.

For example, in the embodiment described above in connection with Fig. 2, it was described that eNB_A sends the mobility information (e.g., "X") which it applies for a UE (e.g., UE_1 ) of a group to the eNB_B. That is, in this case the mobility information "X" is already applied by eNB_A. However, alternatively, the eNB_A could wait with applying of the mobility information "X" for the specific group until receiving a corresponding acknowledgement from eNB_B.

Hence, according to embodiments of the present invention, the mobility setting change (e.g., in SON MLB) is enhanced such that negotiations concern only selected groups of UEs. Moreover, the measures according to the embodiments leave full freedom concerning the way the groups are defined to the implementation or configuration.

Thus, according to embodiments of the present invention, an apparatus and a method are provided by which a cell serving at least one user equipment is controlled, the at least one user equipment is assigned to at least one user group, and mobility configurations are negotiated with a network control element controlling another cell based on the user group.

According to another aspect of embodiments of the present invention, an apparatus is provided which comprises means for controlling a cell serving at least one user equipment, means for assigning the at least one user equipment to at least one user group, and means for negotiating mobility configurations with a network control element con- trolling another cell based on the user group.

It is to be understood that any of the above modifications can be applied singly or in combination to the respective aspects and/or embodiments to which they refer, unless they are explicitly stated as excluding alternatives.

For the purpose of the present invention as described herein above, it should be noted that

- an access technology via which signaling is transferred to and from a network element may be any technology by means of which a network element or sensor node can access another network element or node (e.g. via a base station or generally an access node). Any present or future technology, such as WLAN (Wireless Local Access Network), WiMAX (Worldwide Interoperability for Microwave Access), LTE, LTE-A, Bluetooth, Infrared, and the like may be used; although the above technologies are mostly wireless ac- cess technologies, e.g. in different radio spectra, access technology in the sense of the present invention implies also wired technologies, e.g. IP based access technologies like cable networks or fixed lines but also circuit switched access technologies; access technologies may be distinguishable in at least two categories or access domains such as packet switched and circuit switched, but the existence of more than two access domains does not impede the invention being applied thereto,

- usable communication networks, stations and transmission nodes may be or comprise any device, apparatus, unit or means by which a station, entity or other user equipment may connect to and/or utilize services offered by the access network; such services include, among others, data and/or (audio-) visual communication, data download etc.; - a user equipment or communication network element (station) may be any device, apparatus, unit or means by which a system user or subscriber may experience services from an access network, such as a mobile phone or smart phone, a personal digital assistant PDA, or computer, or a device having a corresponding functionality, such as a modem chipset, a chip, a module etc., which can also be part of a UE or attached as a separate element to a UE, or the like;

- method steps likely to be implemented as software code portions and being run using a processor at a network element or terminal (as examples of devices, apparatuses and/or modules thereof, or as examples of entities including apparatuses and/or modules therefore), are software code independent and can be specified using any known or future de- veloped programming language as long as the functionality defined by the method steps is preserved;

- generally, any method step is suitable to be implemented as software or by hardware without changing the idea of the invention in terms of the functionality implemented;

- method steps and/or devices, units or means likely to be implemented as hardware components at the above-defined apparatuses, or any module(s) thereof, (e.g., devices carrying out the functions of the apparatuses according to the embodiments as described above, eNode-B etc. as described above) are hardware independent and can be implemented using any known or future developed hardware technology or any hybrids of the- se, such as MOS (Metal Oxide Semiconductor), CMOS (Complementary MOS), BiMOS (Bipolar MOS), BiCMOS (Bipolar CMOS), ECL (Emitter Coupled Logic), TTL (Transistor- Transistor Logic), etc., using for example ASIC (Application Specific IC (Integrated Circuit)) components, FPGA (Field-programmable Gate Arrays) components, CPLD (Complex Programmable Logic Device) components or DSP (Digital Signal Processor) compo- nents;

- devices, units or means (e.g. the above-defined apparatuses, or any one of their respective means) can be implemented as individual devices, units or means, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device, unit or means is preserved;

- an apparatus may be represented by a semiconductor chip, a chipset, or a (hardware) module comprising such chip or chipset; this, however, does not exclude the possibility that a functionality of an apparatus or module, instead of being hardware implemented, be implemented as software in a (software) module such as a computer program or a computer program product comprising executable software code portions for execution/being run on a processor;

- a device may be regarded as an apparatus or as an assembly of more than one apparatus, whether functionally in cooperation with each other or functionally independently of each other but in a same device housing, for example. It is noted that the embodiments and examples described above are provided for illustrative purposes only and are in no way intended that the present invention is restricted thereto. Rather, it is the intention that all variations and modifications be included which fall within the spirit and scope of the appended claims.

Claims

1 . An apparatus comprising a connection unit configured to provide a connection to a communication network, and a processor configured to control a cell serving at least one user equipment, to assign the at least one user equipment to at least one user group, and to negotiate mobility configurations with a network control element controlling an- other cell based on the user group.

2. The apparatus according to claim 1 , wherein the processor is configured to negotiate the mobility configuration by sending a request for changing a mobility configuration regarding at least one user group to the network control element, and receiving a response from the network control element informing whether the requested change of the mobility configuration is accepted or not.

3. The apparatus according to claim 1 , wherein the processor is configured to negotiate the mobility configuration by receiving a request for changing a mobility configuration regarding at least one user group from the network control element, checking whether the requested change of the mobility configuration is acceptable and sending a response to the network control element informing whether the request- ed change of the mobility configuration is accepted or not.

4. The apparatus according to claim 2 or 3, wherein the processor is configured to, in case the requested change of the mobility configuration is accepted, apply the mobility configuration to a user group of user equipments served or camping in the cell controlled by the processor.

5. The apparatus according to any one of the claims 1 to 4, wherein the mobility configuration is identified with mobility information.

6. The apparatus according to any one of the claims 1 to 5, wherein information re- garding the mobility configuration is included in a mobility information element.

7. The apparatus according to claim 6, wherein the processor is configured to include the mobility information element in a handover request to the network control element.

8. The apparatus according to any one of the claims 1 to 7, wherein the processor is configured to perform negotiating of the mobility configuration as part of a mobility setting change procedure.

9. The apparatus according to any one of the claims 1 to 8, wherein the processor is configured to determine whether a handover of a user equipment requested from the network control element is accepted or not based on the user equipment characteristics of a user group to which the user equipment belongs, and, in case the handover request is not accepted, to send a rejection response to the network control element.

10. The apparatus according to claim 9, wherein the rejection response comprises information regarding the mobility configuration or a cause value indicating that a handover of user equipments is not accepted because it belongs to a user group whose mobility configuration has previously been negotiated.

1 1. The apparatus according to any one of the claims 1 to 10, wherein the processor is configured to p perform negotiating of the mobility configuration as part of mobility load balancing.

12. The apparatus according to any one of the claims 1 to 1 1 , wherein user groups are defined in the same way as in the network control element.

13. A system comprising a plurality of apparatuses according to any one of the claims 1 to 12, wherein the user groups are defined for all apparatuses in the same way.

14. A method comprising controlling a cell serving at least one user equipment, assigning the at least one user equipment to at least one user group, and negotiating mobility configurations with a network control element controlling another cell based on the user group.

15. The method according to claim 15, wherein the mobility configuration is negotiated by sending a request for changing a mobility configuration regarding at least one user group to the network control element, and receiving a response from the network control element informing whether the requested change of the mobility configuration is accepted or not.

16. The method according to claim 14, wherein the mobility configuration is negotiated by receiving a request for changing a mobility configuration regarding at least one user group from the network control element, checking whether the requested change of the mobility configuration is acceptable and sending a response to the network control element informing whether the requested change of the mobility configuration is accepted or not.

17. The method according to claim 15 or 16, further comprising applying the mobility configuration to a user group of user equipments served or camping in the cell controlled by the method, in case the requested change of the mobility configuration is accepted.

18. The method according to any one of the claims 14 to 17, wherein the mobility con- figuration is identified with mobility information.

19. The method according to any one of the claims 14 to 18, wherein information regarding the mobility configuration is included in a mobility information element.

20. The method according to claim 19, further comprising including the mobility information element in a handover request to the network control element.

21 . The method according to any one of the claims 14 to 20, wherein negotiating of the mobility configuration is performed as part of a mobility setting change procedure.

22. The method according to any one of the claims 14 to 21 , further comprising determining whether a handover of a user equipment requested from the network control element is accepted or not based on the user equipment characteristics of a user group to which the user equipment belongs, and, in case the handover request is not accepted, sending a rejection response to the network control element.

23. The method according to claim 22, wherein the rejection response comprises information regarding the mobility configuration or a cause value indicating that a handover of user equipments is not accepted because it belongs to a user group whose mobility configuration has previously been negotiated.

24. The method according to any one of the claims 14 to 23, wherein negotiating of the mobility configuration is performed as part of mobility load balancing.

25. The method according to any one of the claims 14 to 24, wherein user groups are defined in the same way as in the network control element.

26. A computer program product comprising code means for performing a method according to any one of the claims 14 to 25 when run on a processing means or module.

27. The computer program product according to claim 26, wherein the computer program product is embodied on a computer-readable medium.