The invention relates to the field of load balancing. In particular, the invention relates to methods, apparatuses, and a computer program product for enhancements to support mobility load balancing for relay.
Relay is a technique for improving e.g. the coverage of high data rates, group mobility, temporary network deployment, the cell-edge throughput and/or providing coverage in new areas. A Relay Node (RN) helps an enhanced NodeB (eNB) to communicate with user equipments (UE) that is located at the cell edge by forwarding the data from the UE to the eNB and vice versa. An eNB in a relay configuration is also named Donor eNB (DeNB). This is specified in more detail in 3rd Generation Partnership Project (3GPP) technical report (TR) 36.814 V9.0.0, “Further Advancements for E-UTRA Physical Layer Aspects” (Chapter 9).
As example of a relay architecture is shown in
The eNB shown in
The relay according to Type-1 is an inband relay with resource partitioning. The link between DeNB and RN shares the same carrier frequency with the links between RN and UE and no adequate antenna isolation is used. At this time, the DeNB assigns dedicated sub-frames to links between DeNB and RN, but PRBs of which can also be assigned to DeNB's UEs.
The relay according to Type-1b is an inband relay with resource partitioning. The link between DeNB and RN shares the same carrier frequency with the links between RN and UE, but adequate antenna isolation is used. At this time, the DeNB does not need to assign dedicated sub-frames to links between DeNB and RN. All sub-frames of DeNB are shared by DeNB's RNs and UEs.
The relay according to Type-1a is an outband relay. The link between DeNB and RN uses different carrier frequencies than links between RN and UE. The DeNB does not need to assign dedicated sub-frames to links between DeNB and RN. All sub-frames of DeNB are shared by DeNB's RNs and UEs.
The Mobile Load Balancing (MLB) is one of the most important self-organizing network (SON) features defined in Release 9 for load balancing between eNBs (cf. 3rd Generation Partnership Project (3GPP) technical specification (TS) 36.423 V9.3.0). MLB solution relies on resource status exchanged between neighbors, by X2 message of Resource Status Update. Resource status of neighbors is used by eNB to judge whether MLB should be executed. If it should be executed, mobility parameters to this neighbor will be changed to trigger UEs handover between them.
So far, four MLB parameters are defined in TS36.423 to describe the resource status of one eNB.
The parameter Hardware Load Indicator indicates the status of the Hardware Load experienced by the cell.
The parameter Radio Resource Status indicates the usage of the physical resource blocks (PRBs) in downlink and uplink by the cell.
The parameter S1 TNL Load Indicator indicates the status of the S1 Transport Network Load experienced by the cell.
The parameter Composite Available Capacity Group indicates the overall available resource level in the cell in downlink and uplink.
In order to support MLB also in relay deployment, the straight forward solution is that DeNB/RN works as an eNB to exchange resource status with its neighbors also with X2 message of Resource Status Update to its neighbors. In this case, MLB solution can be reused also in relay deployment without enhancements or modification.
However, with the concept of MLB, the resource status of the backhaul of the eNB is one of the most important inputs to the calculation of S1 TNL Load Indicator and Composite Available Capacity Group at the RN. And the resource status of RN's backhaul link may not be able to be known by RN in some scenarios.
In case of Type-1a and Type-1b, all the available resources that are indicated by four MLB parameters from the DeNB can be used by RN on Un interface, if required. All sub-frames can be used to multiplex the DeNB-UE link and DeNB-RN link because the RN-UE link operates on a different carrier (Type-1a) or the isolation between DeNB-RN link and RN-UE links are enough that the TD multiplexing is not needed among them.
In this case, the RN can induce the resource status of its backhaul link based on MLB parameters in X2 message of Resource Status Update from DeNB.
But it is noted that in real network implementation, an operator may configure a resource division policy on DeNB, e.g. up to 30% resource of DeNB can be used for all its DeNB-RN links while 70% of the resources and probably the unused DeNB-RN link resources are left for its DeNB-UE links. In this case, the RN can still not induce the resource status of its backhaul link just based on MLB parameters from the DeNB, since it describes the resource status of DeNB-UE link, but not DeNB-RN link.
In case of Type-1, if a fixed number of sub-frames are assigned to backhaul link, which will be shared by all RNs, the RN can also not induce the resource status of its backhaul link just based on the resource MLB parameters from the DeNB, since it describes the resource status of DeNB-UE link, but not DeNB-RN link.
If the resource status of the DeNB-RN link is missing from RN, the RN cannot calculate the S1 TNL Load Indicator and Composite Available Capacity Group, since resource status of backhaul is one of important inputs for the calculation of these two parameters. If RN cannot calculate the above MLB parameters, the MLB between RN and its neighbors can not really work.
In the following, three different solutions are proposed in order to solve the above issues. The proposed solutions are preferably for Type-1 relay, but can be also for Type-1a and Type-1b relay.
According to the present invention, there are provided methods, apparatuses and a computer program product for enhancements to support Mobility Load Balancing for relay.
According to an aspect of the invention there is provided a method comprising:
According to further refinements of the invention as defined under the above aspects,
According to another aspect of the invention there is provided a method comprising:
According to another aspect of the invention there is provided a method comprising:
According to further refinements of the invention as defined under the above aspects,
According to another aspect of the invention there is provided an apparatus comprising:
According to further refinements of the invention as defined under the above aspects,
According to another aspect of the invention there is provided an apparatus comprising:
According to another aspect of the invention there is provided an apparatus comprising:
According to further refinements of the invention as defined under the above aspects,
According to a still further aspect of the invention there is provided a computer program product including a program for a processing device, comprising software code portions for performing the steps of the methods as defined above when the program is run on the processing device.
According to a still further aspect of the invention there is provided a computer program product as defined above, wherein the computer program product comprises a computer-readable medium on which the software code portions are stored.
According to a still further aspect of the invention there is provided a computer program product as defined above, wherein the program is directly loadable into an internal memory of the processing device.
According to another aspect of the invention there is provided an apparatus comprising:
According to another aspect of the invention there is provided an apparatus comprising:
According to another aspect of the invention there is provided an apparatus comprising:
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, embodiments of the present invention are described by referring to general and specific examples of the embodiments. 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.
With relay, the DeNB controls both the DeNB-UE link and also the DeNB-RN link. Then, the DeNB has the best knowledge of the resource status of both the DeNB-UE link and the DeNB-RN link. In the following, three embodiments of the invention are described. According to the first embodiment, the DeNB calculates the S1 TNL Load Indicator and the Composite Available Capacity Group for the RN. According to the second embodiment, the RN itself calculates the S1 TNL Load Indicator and the Composite Available Capacity Group. According to the third embodiment, the DeNB uses the S1 TNL Load Indicator of the Resource Status Update message that is sent to the RN to indicate the resource status of the relay nodes' Un backhaul link. This enables the RN calculating the parameter Composite Available Capacity Group by itself.
According to the first embodiment, the DeNB calculates the S1 TNL Load Indicator and the Composite Available Capacity Group for the RN.
In the first embodiment, when the RN sends the X2 message of Resource Status Update to its DeNB, it only calculates and fills the parameters Hardware Load Indicator and Radio Resource Status of the four MLB parameters. The parameters S1 TNL Load Indicator and the Composite Available Capacity Group are left empty or set to zero, since the RN cannot calculate these two parameters if Backhaul Load Information is missing.
When the DeNB receives the X2 message of Resource Status Update from its RN, before forwarding this message, if required, the DeNB calculates and fills in the above two empty parameters S1 TNL Load Indicator and the Composite Available Capacity Group.
The calculation of S1 TNL Load Indicator is mainly based on the DeNB's knowledge to resource status of DeNB-RN link.
The calculation of Composite Available Capacity Group is based on both Hardware Load Indicator and Radio Resource Status from RN, and DeNB's knowledge to resource status of DeNB-RN link.
After filling in the S1 TNL Load Indicator and the Composite Available Capacity Group, the DeNB sends it to the neighbors but also to the Rn that has initiated the message because the RN needs to know the announced values for S1 TNL Load Indicator and the Composite Available Capacity Group.
As shown in
The DeNB 50 comprises a receiving unit 51 that receives the Resource Status Update message from the RN. The receiving unit 51 is connected to a calculating unit 52 which calculates the parameters S1 TNL Load Indicator and the Composite Available Capacity Group. Then, a placing unit 53 connected to the calculating unit 52 places the parameters calculated by the calculating unit 52 into the Resource Status Update message. A forwarding unit 54 connected to the placing unit 53 forwards the Resource Status Update message to the RN and to other eNBs connected to the DeNB 50.
According to the second embodiment, the RN calculates the parameters S1 TNL Load Indicator and the Composite Available Capacity Group by itself. In order to support the RN to calculate all MLB parameters by itself, the resource status of the DeNB-RN link should be provided to the RN in advance, since it is mandatory for the calculation of the MLB Parameters.
In the second embodiment, a message Backhaul Load Info is defined, which describes the load status of the DeNB-RN link. The DeNB then sends this Backhaul Load Info message to the RN, when the resource status of DeNB-RN link is changed and needs to be known by the RN, if the change is big enough to impact the MLB between the RN and its neighbors.
As to the transmission of the Backhaul Load Info message from the DeNB to the RN, there are several possibilities.
The Backhaul Load Info message can be defined as one information element (IE) to be carried by an available radio resource controller (RRC) message or a new defined RRC message. In this regard, it is noted that this message is not limited to the Backhaul Load Info message and that another name may be used in a future standard to replace the Backhaul Load Info message with the same concept and philosophy in the context of the present invention.
As an alternative, the Backhaul Load Info message can be defined as one IE to be carried by an available X2 message or a new defined X2 message.
It is noted that this is not limited to RRC or X2 messages and any other message from the DeNB to the RN can also be used for this purpose (i.e. MAC).
For example, the information could also be sent via a S1 Mobility Management Entity (MME) Configuration Transfer message. In such a case, a SON Information IE is included in the MME Configuration Transfer message. This IE could be enhanced with the Backhaul Load Info message.
The Backhaul Load Info message can include the following information, but is not limited thereto.
The Backhaul Load Info message can include the parameter Composite Available Capacity Group of the DeNB-RN link. This parameter is obtained depending on available information about the DeNB-RN link, such as available PRBs, QoS type of traffic, link condition with this Rn, and so on.
The message can further include resource planning for different QoS traffic by the DeNB and/or any other required information, which can help the RN to calculate MLB parameters more accurately.
The RN uses the Backhaul Load Info message from the DeNB to calculate the MLB Parameters, such as S1 TNL Load Indicator and Composite Available Capacity Group, by itself.
According to the second embodiment, the RN can calculate the parameters S1 TNL Load Indicator and Composite Available Capacity Group more accurately based on a more accurate resource status of its backhaul link, and thus can provide better performance.
As shown in
The RN 60 comprises a receiving unit 61 which receives the RRC, x2 or any other message from the DeNB including Backhaul Load Info. Then, a calculating unit 62 connected to the receiving unit 61 calculates the four MLB parameters Hardware Load Indicator, Radio Resource Status, S1 TNL Load Indicator and Composite Available Capacity Group. Then, the RN 60 forwards the Resource Status Update message including the four parameters calculated by the calculating unit 62 via a forwarding unit 63 connected to the calculating unit 62 to the DeNB. The DeNB may then forward this message to the other eNBs connected thereto, as described above.
According to the third embodiment, the DeNB indicates the S1 TNL Load Indicator to RN, and RN calculates the parameter Composite Available Capacity Group by itself.
In third embodiment, when DeNB sends Resource Status Update to RN, S1 TNL Load Indicator within this message actually does not indicate the backhaul resource status of DeNB, but indicate the backhaul resource status of RN.
The RN uses the S1 TNL Load Indicator from DeNB, which describes its backhaul resource status, to calculate the Composite Available Capacity Group, by itself.
When S1 TNL Load Indicator and Composite Available Capacity Group are available, RN further calculate other two parameters and then send the Resource Status Update to DeNB.
As shown in
The RN 70 comprises a receiving unit 71 which receives the X2 message from the DeNB including the parameter S1 TNL Load Indicator. Then, a calculating unit 72 connected to receiving unit 71 calculates the Composite Available Capacity Group based on S1 TNL Load Indicator from DeNB, and also other MLB parameters Hardware Load Indicator, Radio Resource Status. Then, the RN 70 forwards the Resource Status Update message including the four parameter calculated by the calculating unit 72 via a forwarding unit 53 connected to the calculating unit 72 to the DeNB. Then DeNB may then forward this message to the other eNBs connected thereto, as described above.
As described above, specific embodiments of the present invention provides a procedure for allowing neighbor eNBs of a relay node to understand the backhaul and radio resources available at the relay node by either allowing the RN to calculate such resource or by providing the RN with overall available resource information. Thus, a relay node is allowed to provide valid load and resource information to neighbor eNBs.
In the foregoing exemplary description of the RN and the DeNB, only the units that are relevant for understanding the principles of the invention have been described using functional blocks. The DeNB and RN may comprise further units that are necessary for their respective operation. However, a description of these units is omitted in this specification. The arrangement of the functional blocks of the devices is not construed to limit the invention, and the functions may be performed by one block or further split into sub-blocks.
For the purpose of the present invention as described herein above, it should be noted that
It is noted that the embodiments and general and specific 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 scope of the appended claims.
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/EP10/61835 | 8/13/2010 | WO | 00 | 4/1/2013 |