A method performed by a base station includes generating a request for resource status information, sending the generated request to a neighboring base station, receiving one or more resource status update messages from the neighboring base station in response to the requested resource status information, and performing load balancing operations in dependence upon the received one or more resource status update messages.
|
7. A method performed by a base station, the method comprising:
receiving, at the base station, a resource status request from a neighboring base station;
sending, to the neighboring base station, one or more resource status update messages based on the resource status request,
wherein said one or more resource status update messages include data identifying a physical resource block usage for guaranteed bit rate (GBR) traffic.
11. A base station, comprising:
a transceiver configured to receive, at the base station, a resource status request from a neighboring base station;
wherein the transceiver is further configure to transmit, to the neighboring base station, one or more resource status update messages based on the resource status request,
wherein said one or more resource status update messages include data identifying a physical resource block usage for guaranteed bit rate (GBR) traffic.
9. A base station, comprising:
a transceiver; and
a controller,
wherein the controller is configured to:
control the transceiver to receive, at the base station, a resource status request from a neighboring base station;
control the transceiver to send, to the neighboring base station, one or more resource status update messages based on the resource status request,
wherein said one or more resource status update messages include data identifying a physical resource block usage for guaranteed bit rate (GBR) traffic.
1. A method performed by a base station, the method comprising:
sending, from the base station, to a neighboring base station, a resource status request;
receiving one or more resource status update messages from the neighboring base station,
wherein the one or more resource status update messages are transmitted, by the neighboring base station, based on the resource status request,
wherein said one or more resource status update messages include data identifying a physical resource block usage for guaranteed bit rate (GBR) traffic; and
performing load balancing operations in dependence upon the received one or more resource status update messages.
10. A base station, comprising:
a transceiver configured to transmit, from the base station, a resource status request to a neighboring base station and configured to receive one or more resource status update messages from the neighboring base station,
wherein the one or more resource status update messages are transmitted, by the neighboring base station, based on the resource status request,
wherein said one or more resource status update messages include data identifying a physical resource block usage for guaranteed bit rate (GBR) traffic; and
a controller configured to perform load balancing operations in dependence upon the received one or more resource status update messages.
8. A base station, comprising:
a transceiver; and
a controller,
wherein the controller is configured to:
control the transceiver to send a resource status request, from the base station, to a neighboring base station;
control the transceiver to receive one or more resource status update messages from the neighboring base station,
wherein the one or more resource status update messages are transmitted, by the neighboring base station, based on the resources status request,
wherein said one or more resource status update messages include data identifying a physical resource block usage for guaranteed bit rate (GBR) traffic; and
perform load balancing operations in dependence upon the received one or more resource status update messages.
13. A communication system, comprising:
a base station comprising a transceiver operable to transmit a resource status request, from the base station, to a neighboring base station and operable to receive one or more resource status update messages from the neighboring base station based on the resource status request,
wherein said one or more resource status update messages include data identifying a physical resource block usage for guaranteed bit rate (GBR) traffic;
a controller operable to perform load balancing operations in dependence upon the received one or more resource status update messages; and
a mobile terminal configured for handover from said base station in accordance with said load balancing operations performed by said base station.
2. A method as claimed in
3. A method as claimed in
4. A method as claimed in
5. A method as claimed in
6. A method as claimed in
12. A mobile terminal configured for handover, from a base station adapted to perform a method according to
14. A non-transitory computer-readable storage medium tangibly embodying a program of machine-readable instructions executable by a digital processing apparatus to perform the method of
15. A non-transitory computer-readable storage medium tangibly embodying a program of machine-readable instructions executable by a digital processing apparatus to perform the method of
16. A method as claimed in
17. A method as claimed in
18. A method as claimed in
19. A method as claimed in
20. A method as claimed in
|
|||||||||||||||||||||||||||||||||||||
The present Application is a Continuation Application of U.S. patent application Ser. No. 13/678,875, filed on Nov. 16, 2012, which was a Continuation Application of U.S. patent application Ser. No. 12/735,418, filed on Jul. 14, 2010, now U.S. Pat. No. 8,442,547 B2, which was a National Stage Application No. PCT/JP2009/052120, filed on Feb. 3, 2009, which was based on the United Kingdom Patent Application No. 0802023.2, filed on Feb. 4, 2008, the entire contents of which are incorporated herein by reference.
Technical Field
The present invention relates to mobile telecommunication networks, particularly but not exclusively networks operating according to the 3GPP standards or equivalents or derivatives thereof. The invention has particular although not exclusive relevance to the Long Term Evolution (LTE) of UTRAN (called Evolved Universal Radio Access Network (E-UTRAN)).
Background Art
In a mobile telephone network, load balancing is required to share scarcely available radio resources and the processing load between available base stations (referred to as eNBs in E-UTRAN). In order that this load balancing can take place, load measurements are made by the base stations and shared with the neighbouring base stations, so that decisions on load balancing can be taken. In the RAN1#51B is meeting in Seville 14 to 18 Jan. 2008, the load balancing mechanism was discussed. In particular, RAN1 discussed the physical layer measurements needed to support efficient load balancing and agreed that the measurements of the physical resource block usage in the uplink and the downlink are relevant for load balancing. They have proposed the following four different measurements for this purpose:
All these measurements are defined as a ratio (percentage) of the used Physical Resource Blocks (PRBs) for a type of traffic over the available PRBs in the same direction over a certain time interval, and are measured per cell. Any non-scheduled transmissions and retransmissions should also be counted as used.
Further, RAN 1 believes that it would be sufficient if this control is done at a periodicity in the order of seconds to minutes, or even at a slower rate depending on the expected traffic fluctuation such as for busy hours.
However, details of the signalling of this information between the base stations for load balancing have yet to be defined.
Although for efficiency of understanding for those of skill in the art the invention will be described in detail in the context of a 3G system, the principles of the handover procedure can be applied to other systems, e.g. other CDMA or wireless systems in which mobile devices or User Equipment (UE) communicate with one of several other devices (corresponding to eNB) with the corresponding elements of the system changed as required.
Embodiments of the present invention aim to provide efficient techniques for signaling these measurements between the base stations.
According to one exemplary aspect, the present invention provides a method performed by a EUTRAN base station comprising: sending a request for load balancing measurements to a neighbouring EUTRAN base station; receiving one or more resource status update messages from the neighbouring EUTRAN base station in response to the requested resource status information; and performing load balancing operations in dependence upon the received one or more resource status messages.
The base station may also use load balancing measurements for itself and use these also for performing the load balancing operations. These measurements may be measured directly by the base station.
The one or more status update messages may include data identifying the physical resource block usage for real time and/or non-real time traffic on the uplink or the downlink.
The requesting base station may request the other base station to provide the status updates at a specific time, periodically or in response to one or more specific events. The event may be, for example, when usage of a resource by the neighbouring base station exceeds a defined threshold and/or when the uplink interference level exceeds a defined threshold.
The request preferably defines a time period over which the load measurements are obtained. Additionally, where the neighbouring base station has a plurality of associated cells, the request may identify a subset of those cells for which the measurements are requested.
The base station can control handover of one or more associated mobile communication devices to another cell or base station in dependence upon the one or more received resource status update messages. It can do this, for example, by dynamically controlling Handover and Cell re-selection parameters in dependence upon the one or more received resource status update messages.
This exemplary aspect of the invention also provides a method performed by a EUTRAN base station comprising: receiving a request for resource status information from a neighbouring EUTRAN base station; generating one or more resource status update messages including one or more load balancing measurements; and sending the generated one or more resource status update messages to the requesting base station.
The invention also provides corresponding base stations for performing the above methods.
The invention provides, for all methods disclosed, corresponding computer programs or computer program products for execution on corresponding equipment, the equipment itself (user equipment, nodes or components thereof) and methods of updating the equipment.
An exemplary embodiment of the invention will now be described, by way of example, with reference to the accompanying drawings in which:
Each of the Base stations 5 includes an “S1” interface for interfacing with the core telephone network 7 and an “X2” interface for interfacing with neighbouring base stations 5. Load balancing measurements made by the base stations 5 are sent to the neighbouring base stations 5 over the X2 interface. In this exemplary embodiment, the measurement reports are transmitted between the base stations 5 using a Master/Slave signalling mechanism, in which a Master base station 5-1 requests measurement reports from a Slave base station 5-2 in a defined format and periodicity etc, and in which the Slave base station 5-2 responds in the requested manner. Each base station 5 will act as Master when gathering load balancing information from neighbouring base stations 5 and as a Slave when providing its own load balancing information to neighbouring base stations 5. In this way, each base station 5 can obtain the load balancing information it wants, at the periodicity it wants and in the format it wants. This makes interoperability between different makes of base station 5 easier and will significantly reduce unnecessary traffic over the X2 interface.
Base Station
In the above description, the base station 5 is described for ease of understanding as having a number of discrete modules (such as the load balancing module, handover module, resource measurement module etc). Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the invention, in other applications, for example in systems designed with the inventive features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities.
Load Balancing—Signalling Mechanism
In this exemplary embodiment, the base stations 5 selectively provide load information when requested by their neighbours. A base station 5-1 may request a neighbouring base station 5-2 to send load information in the format it likes (based on the Radio Resource Management (RRM) algorithm that is implemented by the requesting base station 5-1). For example the requesting base station 5-1 may indicate in a Resource Status Request (generated by the resource status request module 35) to the neighbouring base stations 5-2 if it needs load information to be reported just once, or periodically, or in an event driven fashion whenever any of one or more events occurs. The base station 5-2 that receives the request then responds at the appropriate time/event in a Resource Status Update (generated by the Resource status update module 36). In this way, the requesting base station 5-1 is acting as a “Master” and the responding base station 5-2 is acting as a “Slave”. The scheduling used is illustrated in
Details of Resource Status Request Message
The Master base station 5-1 will send a Resource Status Request to the Slave base station 5-2 requesting it to report its physical resource block usage information. The Resource Status Request will include a Reporting Characteristics Information Element (IE), which indicates whether this reporting shall be once, or periodically, or event driven, in which case the event is also specified. If the Reporting Characteristics IE is not set, then, in this embodiment, the Slave base station 5-2 shall send the Resource Status Update only once.
In this exemplary embodiment, a separate message to stop the Resource Status Update is not needed. Instead, the Master base station 5-1 sends the same request message, with the Reporting Characteristics IE value set to zero. The Slave base station 5-2 shall interpret this message as a request to stop the Resource Status Update reporting, which it will process immediately and acknowledge with a similar value of zero in a corresponding Resource Status Update message.
Where the Resource Status Request message requests event triggered reports for multiple events, it may also specify thresholds for those events. For example, the Master base station 5-1 may request a Slave base station 5-2 to report to it whenever its Total Physical Resource Block usage is above 95%, indicating a near congestion situation. Similarly, the Slave may be asked to report if the downlink transmitted power exceeds a certain threshold value.
In this exemplary embodiment, the Resource Status Request message generated by the Master base station 5-1 may include the “Averaging Time” to specify the measurement interval for producing the information requested by the Master base station 5-1. If this value is not specified, then the Slave base station 5-2 will apply a default value.
In this exemplary embodiment, the Resource Status Request message generated by the Master base station 5-1 may include a Reporting Time to specify a periodic reporting based on the Master bases station's internal RRM algorithm. If this value is not specified, the Slave base station 5-2 may apply a default value.
As will be understood by those skilled in the art, each base station 5 may control several different cells and, in this embodiment. The Resource Status Request message generated by the Master base station 5-1 may also include the cell Id's of the cells for which it is interested in receiving the resource load information. If this value is not specified, the slave base station 5-2 will report the resource load status of all its cells.
Details of Resource Status Update Message
In this exemplary embodiment, the Resource Status Update message shall include a Reporting Characteristics IE to indicate the reason for the report. A couple of values in the Reporting Characteristics IE could be reserved to indicate congestion in the cell either in the UL or in the DL direction in terms of Physical layer resources or any other type of processing resources. A Resource Status Update message with a congestion indication can also be autonomously sent by Slave base stations 5-2 to the neighbouring Master base stations 5-1 who have requested Resource status updates whenever congestion is detected. Further, the Slave base stations 5-2 can autonomously send the Resource Status Update message when the congestion is resolved. A Resource Status Update message can also be autonomously sent by a Slave base station 5-2 to the neighbouring Master base stations 5-1 who have requested Resource status updates whenever UL interference exceeds a particular threshold in its own cell, thus incorporating the existing procedure “Load Information” in it.
The Resource Status Update message will also include the relevant measurements requested by the Master base station 5-1:
As mentioned above, in general, each base station 5 will have both the Master (in Asking Resource Status Information) and Slave (Providing Resource Status Reports) roles. However, a base station 5 may not implement a load balancing algorithm and in this case shall act only as a Slave in providing the Resource Status Reports to neighbouring base stations 5, which may be considered to be mandatory.
In an alternative exemplary embodiment, there could be a more sophisticated procedure where the Slave base station 5-2 responds to a Resource Status Request such as in the manner illustrated in
As those skilled in the art will appreciate, with the signalling discussed above, load reporting can be performed based on the Reporting period specified by the Master base station 5-1, thereby allowing the Master base station 5-1 to effectively utilize the received resource status information even in a multi vendor scenario, where implementation specific algorithms are run in different base stations 5. Furthermore, redundant signalling over the X2 interface 25 can be reduced.
Load Information Procedure
Presently 3GPP Standard document TS 36.423 defines a Load Information Procedure, the purpose of which is to transfer the uplink Interference Overload Indication between intra-frequency neighboring base stations 5 for interference coordination purposes. Overload Indications are sent when the base station 5 experiences too high interference levels in the UL on some resource blocks due to a mobile telephone 3 at the cell edge using high power to transmit UL data. Base stations 5 that receive this message, should in principle, ask the mobile telephone 3 to reduce the UL transmit power that is causing the interference.
A base station 5 initiates the procedure by sending a Load Information message to intra-frequency neighbouring base stations 5. The Load information Procedure is used to send interference overload indications when the base station 5 experiences too high interference levels on some resource blocks.
The Resource Status update procedure described above can incorporate this Load Information Procedure if the Resource Status Update messages can be autonomously sent by the Slave base stations 5-2 to the neighbouring Master base stations 5-1 that have requested the Resource status update and have intra frequency cells whenever the UL interference exceeds a particular threshold in its own cell. Such a merged procedure could be called either a Resource Status Update or Load Information Procedure, whichever is more appropriate.
Associated SON Functionality
The load information obtained by the base station 5 in the above manner can be utilized to dynamically control Handover and Cell (Re-)Selection parameters of a cell controlled by the base station 5, through an internal SON entity (which is a self organizing Network that provides RRM functionality within the base station 5). In other words, the load information obtained can be used to control how the base station 5 selects which cell a mobile telephone 5 should be passed to as the telephone 3 roams within the network's coverage area. This is illustrated in
Cell re-selection parameters that could be updated include:
(How to apply it to the Intra frequency case is FFS (for further study) as it is based on ranking of cells.)
Hand Over parameters that can be configured include:
A detailed exemplary embodiment has been described above. As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above embodiment whilst still benefiting from the inventions embodied therein.
In the above exemplary embodiment, a mobile telephone based telecommunications system was described. As those skilled in the art will appreciate, the signalling and handover techniques described in the present application can be employed in other communications system. Other communications nodes or devices may include user devices such as, for example, personal digital assistants, laptop computers, web browsers, etc.
In the above exemplary embodiments, a number of software modules were described. As those skilled will appreciate, the software modules may be provided in compiled or un-compiled form and may be supplied to the base station or to the mobile telephone as a signal over a computer network, or on a recording medium. Further, the functionality performed by part or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates the updating of base station 5 and the mobile telephones 3 in order to update their functionalities.
Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.
The following is a detailed description of the way in which the present inventions may be implemented in the currently proposed 3GPP LTE standard. Whilst various features are described as being essential or necessary, this may only be the case for the proposed 3GPP LTE standard, for example due to other requirements imposed by the standard. These statements should not, therefore, be construed as limiting the present invention in any way.
In the RAN1#51Bis meeting, the load balancing mechanism was discussed. A reply LS in [1] has been sent to RAN 2 and RAN 3 to inform the outcomes of the agreements in RAN 1. In this contribution we provide further details about the signalling involved in order to have the achieve the load balancing.
Measurement Definitions
RAN1 has discussed the physical layer measurements needed to support efficient load balancing and have agreed that the measurements of the physical resource block usage in uplink and downlink are relevant for this use case. They have proposed 4 different measurements listed below for this purpose
M1 Physical resource block usage for GBR (real time traffic) on UL
M2 Physical resource block usage for non-real traffic on UL
M3 Physical resource block usage for GBR (real time) traffic on DL
M4 Physical resource block usage for non-real traffic on DL
All these measurements are defined as a ratio (percentage) of the used PRBs for a type of traffic over the available PRBs in the some direction over a certain time interval, and are measured per cell. Any non-scheduled transmissions and retransmissions should also be counted as used.
Further, RAN 1 believes that it is would be sufficient if this control is done at a periodicity in the order of seconds to minutes, or even at a slower rate depending on the expected traffic fluctuation such as for busy hours.
Details of the signalling for load balancing mechanism is yet to be defined. In the next section we explore different options of how the measured quantities are signalled over X2 interface and what parameters Handover and reselection parameters could be re-configured.
Signalling Over X2
4.1. All eNB Informs Measured Load Information to Other Neighbors
This is the simplest scenario where each eNBs informs measured load information to all the neighbors to which they have an established X2 connection by sending for example: Resource Status Update Message periodically. Alternatively, this information may be piggy-backed on dedicated messages.
As different vendors eNBs may implement different algorithms which would process the Resource Status Update Report at different intervals, using a one fixed interval for reporting may result in reports being sent too frequently and the eNB just discarding large number of these reports. For example if the Load balancing algorithm operates every 5 seconds, a Resource Status Update reporting interval is fixed at say 1 sec then 4 out of 5 reports may be discarded.
4.2. eNB Requests Load Information Selectively from Neighbor eNBs
An eNB may request the neighbouring eNB to send load information in the fashion it likes (based on the implemented RRM algorithm.) For example the requesting eNB may indicate in the Resource Status Request to the neighbouring eNB if it needs Load information to be reported just once, or periodically, or in an event driven fashion whenever any of the corresponding multiple event occurs.
We call this as a Master Slave configuration where the requesting eNB is the master and can request the information in the format it desires.
Details of Resource Status Request Message
Details of Resource Status Update Message
It should be noted that in general each eNB is having both the Master (in Asking Resource Status Information) and Slave (Providing Resource Status Reports) roles. However, an eNB may not implement a load balancing algorithm and in this case shall act only as a slave in providing the Resource Status report to neighbouring eNB which may be considered to be mandatory.
Alternatively we could have more sophisticated procedure similar to Common Measurement Procedure defined in UMTS over iur interface where there is a response to a Resource Status Request such as Resource Status Response as shown in
Such a procedure will require 5 messages as compared to Master Slave Configuration proposed in
Such an options would allow reporting of the load information based on the Reporting period specified by the Master eNB so that it could effectively utilize resource status information in multi vendor scenario allowing the implementation specific algorithms perform efficiently. Furthermore, the redundant signalling over X2 could be reduced.
Relation to Load Information Procedure
Presently Load information Procedure is defined in [3]. The purpose of the Load indication procedure is to transfer the uplink Interference Overload Indication between intra-frequency neighboring eNodeBs for interference coordination purpose.
An eNodeB initiates the procedure by sending LOAD INFORMATION message to intra-frequency neighbouring eNodeBs (see,
The proposed Resource Status update procedure can incorporate the above procedure if the Resource Status Update Report could be autonomously sent by slave eNB to the neighbouring Master eNBs who have requested Resource status update and have intra frequency cells whenever UL interference exceeds a particular threshold in its own cell. Hence for the sake of simplicity we propose to merge these to procedures together. We could call the merged procedure either as Resource Status Update or Load Information Procedure, whichever seems more appropriate.
Associated SON Functionality
The Load Information within the eNB can be utilized to dynamically control Handover and Cell (Re-) Selection parameters of the cell controlled by eNB through internal SON entity. The mechanism is shown in
Cell re-selection parameters that could be updated are. [How to apply it to Intra frequency case is FFS as it is based in ranking of cells.]
Hand Over parameters that can be configured are
In this contribution we discuss various options for exchanging information about the Resource Status between eNBs. We believe that Master/Slave kind configuration would be very flexible in providing the resource status reports to the implementation specific RRM algorithms in a multi-vendor scenario and should be adopted. We urge RAN 3 to agree on the proposed Master/Slave kind of reporting option and the associated text proposal in [4] for X2AP specs.
Further we also discuss the handover and Cell Reselection parameters that could be optimized in the associated SON functionality and if agreeable some details could be captured in Stage 2 TS.
This application is based upon and claims the benefit of priority from United Kingdom patent application No. 0802023.2, filed on Feb. 4, 2008, the disclosure of which is incorporated herein in its entirety by reference.
| Patent | Priority | Assignee | Title |
| Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
| Oct 29 2014 | NEC Corporation | (assignment on the face of the patent) | / |
| Date | Maintenance Fee Events |
| Jun 04 2021 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
| Date | Maintenance Schedule |
| Dec 12 2020 | 4 years fee payment window open |
| Jun 12 2021 | 6 months grace period start (w surcharge) |
| Dec 12 2021 | patent expiry (for year 4) |
| Dec 12 2023 | 2 years to revive unintentionally abandoned end. (for year 4) |
| Dec 12 2024 | 8 years fee payment window open |
| Jun 12 2025 | 6 months grace period start (w surcharge) |
| Dec 12 2025 | patent expiry (for year 8) |
| Dec 12 2027 | 2 years to revive unintentionally abandoned end. (for year 8) |
| Dec 12 2028 | 12 years fee payment window open |
| Jun 12 2029 | 6 months grace period start (w surcharge) |
| Dec 12 2029 | patent expiry (for year 12) |
| Dec 12 2031 | 2 years to revive unintentionally abandoned end. (for year 12) |