Patent Application
20150031363
The present invention relates to apparatuses, methods and a computer program product for improving evaluations of handover failures, and for enabling handling different HO triggers for a SON MRO solution.
The following meanings for the abbreviations used in this specification apply:
eNB enhanced Node-B
HetNet Heterogeneous networks
HOF Handover failure
LTE Long term evolution
MLB Mobility load balancing
MRO Mobility robustness optimization
NRT Non real time
RLF Radio link failure
RNTI Radio network temporary identifier
RRC Radio resource control
RT Real time
SON Self organized network
TS Traffic steering
UE User equipment
Embodiments of the present invention relate to LTE and LTE-A, and in more detail to SON MRO (Mobility Robustness Optimisation) mechanism, which was first developed in Rel.9 LTE system. It was based on RRC re-establishment procedure and inter-eNB notifications: when one eNB detected a re-establishment attempt, it informed about the eNB where the failure happened about this re-establishment attempt. That eNB, based on the information provided in the notification, could discover the reason of the failure (and possibly further notify the eNB where the problem started) based on still available UE context and possibly additional measurements provided from the UE.
In Rel.10 this mechanism was changed: since network information is not always precise (HO command may fail in delivery) and not complete if the UE context is missing (which is the case if the re-establishment fails and the C-RNTI is lost), the Rel.10 MRO solution was based on the information reported from the UE. This is very precise if certain assumptions are made concerning the situations: that all the HOs are triggered only because of radio reasons and the triggering criteria are the same for all the UEs. Those assumptions are needed, because the UE is not aware of the HO process at the eNB and receives only the HO command, therefore can not report back anything that lead to the handover decision in the eNB.
In Re1.11, the MRO-MLB (or MRO—traffic steering, in general) coordination is still considered as a possible focus area. Since activity of MLB may trigger HOs that are not related to radio conditions (actually, usually against radio conditions, which may lead to failures), the assumptions made in Rel.10 may not hold any longer. Also, different criteria may be used in HetNet deployment, where pico cells may be used to handle particular types of UEs and therefore HO triggering to those pico cells may be different than those to other macro cells.
Thus, the Rel.10 MRO solution is based on the UE report, which, while providing detailed radio conditions of the failure, does not tell anything about the triggering condition at the source eNB. If it can be assumed all the HOs are carried out because of radio conditions (mobility) and that all users are treated in the same way (the same trigger point), this could be sufficient. However, in a modern network, in presence of other SON features, this is too general, though.
In the following, two examples for illustrating the problem are described.
If the HO trigger point is different for different types of users (differentiation may be based, for example, on mobility type or service class), the information that a given HO failed because it was triggered too late is not sufficient: the network will have to guess which of the trigger points is wrong. That may lead to correcting the one that is actually set well and increasing failure rate even more.
If there is any other feature running that may trigger HOs also for non-radio reasons (for example, MLB or traffic steering policies) and such HO leads to a failure, the information about the failure provided later from the UE will trigger an MRO analysis. Eventually, the HO will be treated as a radio-driven one. If corrective action is applied, the setting for radio-driven HOs will be amended and likely their failure rate even increased.
A solution to the above defined problem that would create yet another MRO mechanism is not likely: principles of Rel.10 MRO solution are not considered to be changed in Rel.11.
Hence, summarizing, the SON MRO mechanism defined in Rel.10 is based solely on the information provided from the UE that suffered connection failure. Since the network can not use the UE context, all the information that lead to the HO decision is lost. This may mean the problem that caused the failure can not be corrected, if there are more than one trigger point (handover threshold or cause).
Embodiments of the present invention address this situation and aim to improve possibilities for analyzing a cause for a connection failure.
According to a first aspect of embodiments of the present invention an apparatus is provided which comprises a transceiver configured to provide a connection with at least one network node, and a processor configured to receive, via the transceiver, information enabling handover and/or apparatus type identification related to a handover and to store the information enabling handover and/or apparatus type identification.
According to a second aspect of embodiments of the present invention an apparatus is provided which comprises a transceiver configured to provide a connection with at least one a user equipment, and a processor configured to carry out a handover related procedure concerning a user equipment, to establish information enabling handover and/or apparatus type identification related to the handover, and to send the information enabling handover and/or apparatus type identification via the transceiver to the user equipment.
According to a third aspect of embodiments of the present invention an apparatus is provided which comprises a transceiver configured to provide a connection to at least another network node, and a processor configured to receive and send inter-node messages related to a failure analysis process, to receive, via the transceiver, a failure indicating message containing the information enabling handover and/or apparatus type identification, and to analyze a cause for the connection failure based on the failure indicating message containing the information enabling handover and/or apparatus type identification.
According to a fourth aspect of embodiments of the present invention a method is provided which comprises
According to a fifth aspect of embodiments of the present invention a method is provided which comprises
According to a sixth aspect of embodiments of the present invention a method is provided which comprises
Advantageous developments are defined in the dependent claims.
Thus, according to embodiments of the present invention, an apparatus such as a user equipment is provided with information enabling handover and/or apparatus type identification, which can later be used for analyzing the cause for a connection failure.
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:
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.
The UE may also comprise a memory 12 for storing data and programs, by means of which the processor 11 may carry out its corresponding functions, and in which the handover trigger information can be stored.
Similar as the UE 1, also the eNB 2 may comprise a memory 23 for storing data and programs, by means of which the processor 21 may carry out its corresponding functions.
Thus, according to certain embodiments of the present invention, the UE 1 receives information enabling handover and/or apparatus type identification related to the handover from the eNB 2, i.e., the source eNB to which the UE was connected before the handover attempt. In case of a connection failure (e.g., a handover failure or a radio link failure) in the source eNB or target eNB, the information enabling handover and/or apparatus type identification can be sent to the eNB 2 so that reasons for the failure can be evaluated based on the information enabling handover and/or apparatus type identification.
For example, the information enabling handover and/or apparatus type identification may be a handover trigger information which is sent during a handover initiation message such as a HO command (as an example for a handover related message). In case of a failure, the information is returned to the eNB that triggered the erroneous HO. In this way, the handover conditions that might have caused the failure can be identified and evaluated.
Another example for the information enabling handover and/or apparatus type identification is user equipment type information which is sent during a connection reconfiguration message from the controlling eNB to the user equipment. In case of a failure, the information is returned to the eNB. In this way, the failure can be evaluated based on the UE type, for example whether the UE was moving with high speed, whether the UE type carried out non-real time applications or the like.
Hence, according to the above general embodiments of the invention, further information is available to evaluate handover failures and, thus, to enhance robustness of a mobile network.
Detailed embodiments are described in the following by referring to
Thus, according to an embodiment as shown in
In detail, the source eNB (e.g., eNB 2 shown in
The information provided to the UE with the HO command may be “direct”, i.e. a detailed list of trigger thresholds, HO cause, QoS class and any other factor that the eNB might take into account when initializing the HO. In this way, detailed information would be easily available when evaluating the reason for the failure.
However, such a list could be rather long, burdensome for the UE to handle and possibly still incomplete, since the HO algorithm is proprietary and therefore it may take into account almost infinite number of factors. Therefore, preferably, an “indirect” information is passed to the UE: the source eNB assigns internally an identifier to a HO triggering condition. This identifier, or a codepoint, in a form of a relatively short number, is passed to every UE that is handed over based on these triggering conditions. If a HO goes wrong, the concerned UE reports the identifier as part of or together with the RLF Report. Then, when the source eNB where the failure occurred or the eNB which started the erroneous HO receives the identifier returned from the UE (forwarded in the RLF INDICATION and possibly in the HO REPORT), it can match it internally to the actual HO trigger. Therefore, the HO cause can be recalled and trigger conditions that were wrong can be identified correctly. It is important to note that this form does not reveal anything about the HO algorithm itself.
The signal flow shown in
In 3-1, the source eNB, indicated as eNB B, sends a HO command to the UE, which includes a HO trigger identifier #2 as mentioned above. In the following HO attempt, the UE performs a RACH access in 3-2, and sends a RRC Re-config complete message in 3-3 to the target eNB, indicated as eNB A. In 3-4, the eNB B sends a UE context release to the eNB A, in order to inform the source eNB about HO success and to release the resources in the source ENB A. Therefore, after this no UE-context information is available at the eNB B, as indicated in 3-5.
Now, it is assumed that the connection fails in eNB A. Hence, the UE creates and stores a RLF report, including the HO trigger identifier #2, in 3-6. After this, the UE tries to re-connect to the source eNB B by performing a RRC re-establishment (with the indication of a failure) in 3-7 and performing RRC setup in 3-8. In 3-9, UE information including the RLF report established by the UE in 3-6 is exchanged. The RLF report is sent to the last serving eNB A in a RLF indication message in 3-10. Thereafter, the eNB A performs the failure cause analysis and, after detecting the first HO from eNB B was erroneous, it sends a HO report including the RLF report to the eNB B in 3-11, so that thereafter a RLF report analysis can be carried out in 3-12. In particular, it is checked to which HO condition the HO trigger identifier #2 is mapped, for example whether the HO was due to radio reasons, or due to non-real time user or high speed user.
The HO trigger identifier as mentioned above could be used only if the UE received the HO command. Therefore, it would not be reported in case of too late HO, as then the UE does not receive the command. In order to enable differentiation of the UE type (e.g. fast UEs may need to be triggered sooner than slow ones; NRT UEs may be excluded from MRO resolution, because connection failure is less problematic in their case), another identifier may be introduced: UE type identifier. This one may be assigned with RRC reconfiguration, stored in the RLF report in case of a failure and reported after reconnection. It is important to store the UE type in the RLF report right after the failure in order to avoid overriding it with a new classification when the UE reconnects after the failure to another cell.
In this case, in 4-1, the eNB A sends a RRC connection reconfiguration message in 4-1 to the UE. The RRC connection reconfiguration (RRC Conn Reconfig) message includes the above reference user type identifier (UE type id). If then the handover failure occurs, the UE creates and stores a RLF report, including the user type identifier, in 4-2. 4-3 to 4-6 are similar to 3-7 to 3-10 of
It is noted that the HO trigger identifier and the UE type identifier are independent from each other: their usage in the MRO algorithm may be adapted, depending if only one or both together are used. For example, if only the HO trigger identifier is used, in the eNB implementation, different UE types may be assigned different HO trigger IDs. However, if the UE type identifier is used, then this id may cover UE type, while the HO trigger identifier may correspond to the HO cause only.
In the following, a general embodiment of an apparatus involved in analyzing the connection failure is described by referring to
An example for the above eNB is eNB B shown in
However, the analysis also includes a check that the cause for the connection failure lies not in the present eNB. Hence, the processor 51 may be further configured to send the information enabling handover and/or apparatus type identification to the node controlling the cell where the connection failure started.
An example for this function is sending the RLF indication in 3-10 shown in
Similar as the eNB 2 shown in
For an actual implementation of the above embodiments, following changes in the RRC signaling could be considered:
1) The information about the HO trigger point and/or UE type is passed to the UE. This can be done as a new IE with the RRC setup/reconfiguration message, with or without MobilityInfo. Since the information concerns the HO, the option “RRC Reconfiguration with MobilityInfo” seems the most logical. In that case, the added IE contains a certain identifier or codepoint, as described above. If the codepoint option is decided, the additional field can be of limited length.
2) In case of RLF (or HOF), the UE stores this identifier or the codepoint, for example as information element of the RLF report.
3) The identifier or the codepoint, likely as a part of the RLF Report, is provided when the UE reconnects to an eNB. This report is then transparently forwarded to the eNB where the failure happened, so changes in X2AP RLF INDICATION are not needed. If needed, the report may then be forwarded further in the X2AP HO REPORT.
Thus, summarizing, according to embodiments of the present invention, a method is provided to map the conditions under which a connection failure occurred (e.g. HO cause, trigger conditions QoS combination and further more) to a failure event reported by UE. Providing this HO trigger to the UE helps it provide better information back to the network.
That is, when a handover is triggered, the source eNB generates a “HO trigger ID” for the set of conditions that triggered the handover. The “HO trigger ID” is sent to the UE in handover related signaling, and stored in the RLF Report if the UE subsequently experiences connection failure. If the RLF Report is later retrieved by the network and passed to the source eNB, the “HO trigger ID” can be considered (along with other information) by the SON MRO algorithm for determining the cause of the connection failure and what actions to take.
In addition or alternatively, a “UE type ID” could be signaled to the UE for the set of “non-HO related” characteristics of the UE which may be useful in SON MRO analysis. Similar to “HO trigger ID”, it is stored by the UE in the RLF Report if the UE subsequently experiences connection failure.
Thus, according to certain embodiments, just a single short value is passed to the UE, as a IE, and then it is reported it back in case of a handover failure. The UE is informed about the ID of the handover trigger, which is later found when the UE reports back the ID.
According to the embodiment described above, it is proposed to give the UE a code point or ID (e.g. 8 bit) which is then included in the RLF report and from that the node where the RLF happened the failure can be uniquely categorized.
It is noted that the above embodiments of the present invention basically follow the Rel10 approach which is based on information hold in UE (in contrast to Rel9 which is based on UE context hold in the network). Rel10 is more flexible in terms that it does rely on context storage within the network, i.e. UE can provide RLF reports after days and problem can still be analyzed. Cell changes are not only triggered by mobility and even if they are mobility triggered, failures are more or less critical depending on service type, etc.
In the Rel10 philosophy the network does not remember anything. There is no unique UE ID, like C-RNTI, recalled after the UE passes to idle and then reconnects. So the base stations cannot remember, hence, any kind of information which might be of interest for MRO must be conveyed by the UE.
There are several reasons for going that way. Main reason was that there might be cases where the RLF reports are not sent immediately, but up to 48 hours after the RLF (e.g., when the UE stays in a 3G network in the meantime which does not support RLF report). A temporal identifier such as C-RNTI could not be blocked that long.
Hence, according to embodiments of the present invention, the UE and/or the HO triggering conditions are marked (e.g., whether it is real time/non-real time (RT/NRT), this HO is due to traffic steering (TS)/radio conditions, the UE is in a specific location (street1/street2), etc.). In case of a failure, this marking goes to the network, and finally back to the cell which has caused the failure. And then it can “remember”, i.e. it can react appropriately. For example, it can ignore all failures from NRT users, if they are seen as less burdensome for the users. Alternatively thresholds may be changed only for certain UEs, (e.g., only for users in a certain location, e.g. on particular street (street1)). Moreover, also it would be possible to not change mobility thresholds if the RLF was caused by TS.
Thus, according to embodiments of the present invention, an improved way of analyzing handover failures is provided.
It is noted that the embodiments and the present invention in general is not limited to the specific examples given above.
For example, the information enabling handover and/or apparatus type identification is not limited to handover trigger information and UE type only, and also other suitable information for evaluating a handover failure can be used.
According to the above-described embodiments, the information enabling handover and/or apparatus type identification (e.g., HO trigger and/or UE type identifier) are sent, in case of a re-connection of the UE after recovery from the failure, within the RLF report (as an example for connection failure related information), as shown by 3-9 in
Moreover, the embodiments described above are related to LTE and LTE-A. However, the embodiments and the invention are also applicable to other network structures, as long as it is possible to send corresponding information in handover related message to a UE and to store it there.
Hence, according to embodiments of the present invention, apparatuses and methods are provided by which a user equipment receives information enabling handover and/or apparatus type identification related to a handover, and stores the information enabling handover and/or apparatus type identification. In case of a connection failure, the stored information enabling handover and/or apparatus type identification may later be used to evaluate the cause for the connection failure.
According to a further aspect of embodiments of the present invention an apparatus is provided which comprises
According to a still further aspect of embodiments of the present invention an apparatus is provided which comprises
According to another aspect of embodiments of the present invention a method is provided which comprises
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
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.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/EP2012/051434 | 1/30/2012 | WO | 00 | 10/16/2014 |
