GB2475851A

GB2475851A - Handover system based on backhaul link information

Info

Publication number: GB2475851A
Application number: GB0921076A
Authority: GB
Inventors: Sivapathalingham Sivavakeesar; Sundarampillai Janaaththanan
Original assignee: Sharp Corp
Current assignee: Sharp Corp
Priority date: 2009-12-01
Filing date: 2009-12-01
Publication date: 2011-06-08
Also published as: WO2011068237A1; GB0921076D0

Abstract

Optimal handover of user equipment in a wireless telecommunications system is achieved based on backhaul link information. A source node 4 operable to control a wireless communication session with a mobile telephone 6 and a relay node 1, 2, 3, performs the steps of: establishing that the user equipment desires to handover from said source node; having said source node obtain backhaul link information of the relay node; and based on said backhaul link information, establishing whether or not to perform said handover. In determining whether to perform a handover, a source node may requests backhaul link information from a plurality of neighbouring nodes for use in the determination process.

Description

Handover System and Method thereof

Technical Field

The present invention relates to a system and method for performing a handover in telecommunication systems, and particularly, to a system and method for performing a handover including a relay, and even more particularly between a pair of relays.

Background

The first release of the LTE was referred to as release-8, and provided a peak rate of 300 Mbps, a radio network delay of less than 5rns, an increase in spectrum efficiency and new architecture to reduce cost and simplify operation.

LTE-A or LTE Advanced is currently being standardized by the 3GPP as an enhancement of LTE. LTE mobile communication systems are expected to be deployed from 2010 onwards as a natural evolution of GSM and UIMTS.

Being defined as 3.9G (3G+) technology, LTE does not meet the requirements for 4G, also called IMT Advanced, that has requirements such as peak data rates up to 1 Gbps.

In April 2008, 3GPP agreed the plans for future work on Long Term Evolution (LTE). A first set of 3GPP requirements on LTE Advanced was approved in June 2008. The standard calls for a peak data rate of 1 Gbps and also targets faster switching between power states and improved performance at the cell edge.

The efficient use of relays are imperative in LIE-A. They provide an economical mechanism to improve the system capacity, link throughput and therefore the cell-edge performance, and also extend the cell coverage. However, given that LTE-A calls for a peak data rate of 1 Gbps, relays typically operate in small cells to support the peak data rate.

th LTE-A, a number of different architecture alternatives have been suggested. Particularly, the following four architecture alternatives have been identified for supporting relays in LTE-A: -Alternative 1: Full-L3 relay, transparent for D-eNB -Alternative 2: Proxy Si/X2 -Alternative 3: RN bearers terminate in D-eNB -Alternative 4: Si UP(U-plane) terminated in D-eNB Out of these four alternatives, Alternatives 1,2 and 3 can be considered to belong to the same group of solutions in the sense that Alternatives 2 and 3 are enhanced variants of Alternative 1, being the baseline solution. In case of Alternative 4 there are also multiple variants, which are based on a different approach as compared to the previous three alternatives. The differences are, in the main, concerned with the Application Protocols used. A brief summary of some of the features of these alternatives is provided below.

In Alternatives 1, 2 and 3, the U-plane of the Si interface is terminated at the RN(Relay Node). In the Alternative 1, the U-plane packets of a UE served by the RN are delivered via a Relay's P/S-GW(PDN/Service-Gateway). The IJE's P/S-GW maps the incoming lIP packets to the GTP(GPRS Tunneling Protocol) tunnels corresponding to the EPS(Evolved Packet System) bearer of the UE and sends the tunnelled packets to the lIP address of the RN.

The tunnelled packets are routed to the RN via the Relay's P/S-GW, as if they were packets destined to the RN as a UE.

In Alterative 4, the U-plane of the SI interface is terminated at the D-eNB. The PGW/SGW serving the UE maps the incoming IP packets to the GTP tunnels corresponding to the EPS bearer of the UE and sends the tunnelled packets to the IP address of the D-eNB. Upon the D-eNB receiving the tunnelled packets from the S-GW, the received packets are de-tunnelled, and the inner user IP packets are mapped to Un radio bearers corresponding to the EPS bearer of the UE.

Each EPS bearer of a UE connected to the RN is mapped to separate radio bearers over the Un interface (one-to-one mapping). In order to identify individual UE bearers on the Un interface a UE identifier needs to be added to one of the PDCP, RLC or MAC protocol layers; i.e., some parts of the legacy MAC/RLC/PDCP protocols would need to be modified.

The present application thus seeks to provide efficiencies in cell edge performance, and to avoid wastage of resources and latency.

Disclosure of the Invention

According to the present invention there is provided a method of performing a handover in a telecommunications system, the system comprising: a source node operable to control a wireless communication session with a user equipment; and a relay node, wherein said method comprises the steps of: i) establishing that the user equipment desires to handover from said source node; ii) having said source node obtain backhaul link information of the relay; iii) based on said backhaul link information, establishing whether or not to perform said handover.

Preferably the source node is a.relay node, and most preferably a type 1 relay node.

However, in an alternative embodiment, it is preferred that the source node is a controlling eNB.

In a preferred embodiment, the source node is a relay node in a first domain controlled by a first controlling node. The relay node may be located in the first domain. Alternatively, the relay node may be located in a second domain controlled by a second controlling node.

Preferably the first and second controlling nodes are eNBs.

Preferably, the source node obtains backhaul link information details of a plurality of relay nodes operable to receive handover of the wireless communication session, and, based on said backhaul link information, selects the most suitable relay node.

It is preferred that after deciding that a handover is necessary, said source node requests backhaul information from the relay prior to determining whether or not to perform said handover.

Preferably the telecommunication system comprises a plurality of domains, each domain being controlled by a controlling eNB, wherein at least one of said domains is operable to support one or more relay nodes. It is particularly preferably that, for neighbouring domains, the controlling eNBs and the relays included therein periodically exchange backhaul link information. The frequency of the exchange may vary depending on various factors, including the time of the day.

In a particularly preferred arrangement, each node within a given domain will periodically exchange backhaul information.

Should a handover occur between nodes in neighbouring domains, the source node may request backhaul information from the node in the neighbouring domain.

According to a second aspect of the present invention, there is provided a source node in a telecommunications system operable to control a wireless link to a user equipment, and, based on a measurement report from said user equipment control a handover to a second node, wherein said source node is configured to receive backhaul link information from the second node and determine whether or not a handover should be performed based on said backhaul link information. Said second node being a different access node in said telecommunications system from said source node.

Preferably said source node is operable to periodically receive reports from said second node regarding its backhaul link information. Alternatively, it is preferred that the source node is operable to request said backhaul link information prior to performing said handover.

It is preferred that the said second node is a relay, and particularly a type 1 relay. It is also preferred that said source node is a relay, and particularly a type I relay.

In a preferred embodiment, the source node comprises a relay located within a domain controlled by a controlling eNB. It is preferred that the controlling node, said source node and any further nodes in said domain periodically exchange backhaul link information.

It is preferred that the telecommunications network comprises a plurality of domains, and if a handover is desired between two nodes in separate domains that the source node either requests the backhaul link information of the target node, or immediately requests handover thereto.

According to a third aspect of the present invention there is provided a telecommunications system comprising a plurality of controlling nodes, each controlling respective domains, wherein at some one of said domains comprises one or more relay nodes, wherein, in each domain, nodes periodically exchange backhaul link information with one another, such that said backhaul link information is used to determine optimal handovers within said domain.

Preferably, if a handover is required between nodes in different domains, the node controlling the user session requests backhaul information from possible target nodes, and selects the optimal node using said backhaul information.

In order that the present invention be more readily understood, specific embodiments will now be described with reference to the accompanying drawings.

Description of the figures

Figure 1 shows an exemplary illustration of a typical relay handover; Figure 2 shows the preparation phase of a handover in a first embodiment; Figure 3 shows a first alternative of the preparation phase of a handover as applicable to relay architecture alternative one in a second embodiment; Figure 4 shows a first alternative of the preparation phase of a handover as applicable to relay architecture alternative two in a second embodiment; Figure 5 shows a first alternative of the preparation phase of a handover as applicable to relay architecture alternative three in a second embodiment; Figure 6 shows a first alternative of the preparation phase of a handover as applicable to relay architecture alternative four in a second embodiment; Figure 7 shows a second alternative of the preparation phase of a handover as applicable to relay architecture alternative one in a second embodiment; Figure 8 shows a second alternative of the preparation phase of a handover as applicable to relay architecture alternative two in a second embodiment; Figure 9 shows a second alternative of the preparation phase of a handover as applicable to relay architecture alternative three in a second embodiment; Figure 10 shows a second alternative of the preparation phase of a handover as applicable to relay architecture alternative four in a second embodiment; and Figure 11 shows the preparation phase of a handover in a third embodiment.

Specific Description

Relaying has been considered for LTE-A as an economical mechanism to improve the system capacity, link throughput and thus the cell-edge performance and to extend the coverage.

Given that the relays (relay nodes) generally operate in small cells in order to support the 1 Gbps downlink peak rate, it is likely that there will be many scenarios where the frequency of user equipment (LIE) handover when a session/call is in progress will be high. Much depends on the mobility pattern of UEs and the approximate relay cell radius.

In LTE-A, relays are generally defined in two categories: type 1 and type 2. Type 1 relay nodes have their own PCI(Physical Cell ID) and are operable to transmit its common charmellsignals. liEs receive scheduling information and HARQ feedback directly from the relay node. It is also possible for type 1 relay nodes to appear differently to eNBs to allow for further performance enhancement.

By contrast, type 2 relay nodes do not have a separate PCI, and are transparent to UEs.

Each relay in the network will have a link to a controlling eNB. This link is often termed the backhaul link. Each eNB will be linked to the core network, and this link is the eNB's backhaul link. The controlling eNB is sometimes referred to as a donor eND, or D-eNB. A D-eNB controls network traffic within a domain. Said domain may include a plurality of further nodes. Domains located geographically next to one another may be termed neighbouring domains.

A typical relay handover scenario is illustrated in Figure 1, where UE 6 and UE 7 are two user terminals being served by two different relay nodes: Relay 1 and Relay 2, respectively. In this scenario UE 7 is effectively stationary whereas UE 6 is moving away from Relay 1 in the direction indicated by the arrow A. The signal quality in the downlink of UE 6 tends to become weaker the further away it moves from Relay 1. Consequently, liE 6 is more likely to be handed over to one of the following nodes, depending on the quality of service measurements reported by UE 6 to Relay 1 as well as the respective resource availability: Relay 3, D-eNB 4, and D-eNB 5. The present arrangement has particular advantage if Relay 3 is selected as the optimal target for handover.

It is envisaged that the present arrangement is highly suited to type I relays, although is not limited thereto. Indeed, the present arrangement also finds use with type 2 relays.

Handover will be a frequent phenomenon with an introduction of relays in LTE-A. Further, the 3GPP considers in-band relays and such in-band relays need to configure MBSFN(Multimedia Broadcast multicast service Single Frequency Network) sub-frames in the access link in order to enable backhaul down link transmission and thus avoiding self-interference. Given that time division multiplexing (TDM) is used in the backhaul in order to further minimise self-interference and MBSFN sub-frames caimot be configured at sub-frames 0, 4, 5 or 9 of a radio frame (as these sub-frames are used for network control signals), resources in the backhaul are scarce.

Accordingly, the source eNB considers the resource availability and qualities of both access and backhaul links of the target relay before a handover is attempted. Considering further Figure 1, if UE 6 moves towards Relay 3, such that it is determined that the quality of service would be higher if a handover was made between Relay I and Relay 3, D-eNB 4 first ascertains the backhaul link between Relay 3 and D-eNB 5 and uses this information to decide whether or not to proceed with the handover.

During the handover between two relays, and given that at least two backhaul links are involved, the handover decision is made not only the quality of the access links, but also the bottleneck and link quality of the backihaul links as well. In order to make a handover success, it is important to consider both links, unlike the conventional handover methods where measuring the quality of the access link is enough. For instance, suppose a handover is between Relay 1 and Relay 3 in Figure 1, and the handover is going to be performed in a conventional way between two relays. Type 1 relay nodes are like a conventional eNBs in terms of the core functionalities, a conventional handover will consider only the access links.

Once the handover request is accepted without checking the load-level or quality level of the backhaul link, the handover agreed at the access link levels may fail due to resource unavailability or poor link quality in the backhaul link. Given that the occurrence of this relay handover failure leads to unnecessary wastage of resources and introduction of significant latency, it is desirable that it should be minimised or avoided.

In order to mitigate the above problem in relay handover and thereby avoiding the unnecessary resource utilisation, efficient signalling procedures are required for relay handover, especially in the relay handover preparation phase. According to this, the source relay node decides the suitable target node based on the resource availability on both the access and backhaul links, in case a relay is considered for a target node and the periodic quality measurement report pertaining to the access links obtained from the UE. The respective backhaul link information of the candidate target nodes can be made available at the source relay node proactively, reactively or in a combination of the two -termed a hybrid strategy hereinafler. In the Proactive Strategy, the immediate neighbouring D-eNBs and relays exchange periodic quality, load and resource availabilities of their respective backhaul links to each other, so that any source node will know such information in priory to any handover attempt. In the case of Reactive Strategy such backhaul link information is made available on-demand at the time of handover. In the Hybrid Strategy, a mixture of both the proactive and reactive strategies is used. Alternatively, in another embodiment, at certain times in the day, the system may use the Proactive Strategy, and at others the Reactive Strategy.

The Proactive Strategy facilitates quicker handover preparation phase but at the expense of increased signalling overhead. Moreover, in the case of the Proactive Strategy, the information available at the source node may go stale at the time of a handover; and this depends on the dynamic variations of the network loading within the cell and the update frequency. The more often nodes exchange backhaul link related information, the more accurate the information will be. The Reactive Strategy tends to have increased latency in the handover preparation phase while keeping the signalling overhead minimum. Accordingly, it is preferred that the present system uses a hybrid strategy combining the two systems.

The three strategies differ in the perspectives of the signalling procedures involved during the handover preparation phase -i.e., the signalling procedures for the execution phase are the same. The three strategies will now be described in turn.

Proactive Strategy Figure 2 shows the preparation phase of a Proactive Strategy handover. The system is based on the network illustrated in Figure 1. Relays 1, 2, 3 and D-eNBs 4, 5 periodically exchange quality, load and resource availability information of their respective relay backhaul links to their immediate neighbouring relays and eNBsID-eNBs. The exchange is controlled by the serving or packet gateway 10 in Figure 2. As an example, the arrangement shown in figure 1, Relay I may be considered as a source node, controlling wireless communication with a UE, D-eNB 4 may be considered as a controlling eNB and Relay 2 a further node associated with the domain of D-eNB 4.

Consequently, nodes are aware of the present load, resource availability and quality information of every backhaul link in the immediate neighbourhood and thus the source node is able to make a quick decision whether or not to attempt a handover if at least the target node or the source node is a relay.

In addition, as in the legacy LTE system, each and every UEs periodically sends the UE measurement report to their respective serving nodes(source nodes). This report contains the access link quality measurement results of the neighbour-list including that of the serving node(source node) as well. On receiving the report, the source node will continuously monitor the instantaneous QoS experienced by each tIE in the access link. If the source node is a relay, it will monitor the quality of the backhaul link as well. If the QoS supported by the source node to any of its liEs is below the threshold level defined by the system (both in the access link and backhaul link, if any), it will attempt to handover the liE to a suitable target node. The source node will begin evaluating the resource availability of the possible target nodes starting with the target node with the highest QoS. The evaluation process will be terminated once a target node with sufficient (i.e., both access and backhaul, if any) resource and sufficient link (e.g., both the access and backhaul, if any) quality is found.

In order to enable sessionlcall continuity, the source node will initiate a Handover Request to the chosen target node via NAS, X2-AP or RRC depending on the relay architecture and type of source and target nodes. Because of the periodical information exchange between the nodes, the source node knows the resource and link quality information of the possible target relay candidates prior to a handover attempt, and thus the handover failure rate will be minimal.

It should be noted that much depends on the accuracy of the information being available to the source node, and which in turn depends on the frequency of the information exchange. If the source node has nearly up-to-date information, the handover will very likely succeed. In case the source node has stale information, the handover attempt may fail.

In response to the Handover Request command, the target node will send an acknowledgement(Handover Request Ack) to the source node after performing the admission control and resource allocation. If the target node is a relay, the target relay has to perform admission control for both access and backhaul links by liaising with its respective D-eNB and it involves allocation of the required resources (both radio and buffer) on both links. In case the admission control process fails, the target node candidate will immediately send a Handover Request Nack to the source node.

The strategy of exchanging backhaul link quality, resource availability and load prior to any handover attempt can be implemented in different ways depending on the relay architectures; a general handover signalling procedures during handover preparation phase of the Proactive Strategy is shown in Figure 2. This is explained in more depth below.

With the step 1 of Figure 2, a source node will be indicated the instantaneous resource availability, load-level and link-quality of neighbouring relays' backhauls at regular intervals or at the time when any of triggering condition are fulfilled.

Thus, on receiving a UE 6 Measurement Report, the source node(Relay 1) can determine whether a handover is imminent. If it is the case, based on the results of neighbour-list measurement report from the liE 6 in question pertaining to their access links, the source node(Relay 1) can short-list the possible target node candidates. If any of the possible target candidates is a relay, and it appears to be the optimum candidate among all the target node candidates, the source node(Relay 1) will check its backhaul link using the periodic backhaul related report and select it as the final target candidate provided that the resource availability and quality of the backhaul link is good enough to support the TIE in question. Once the handover decision is made at the source node(Relay 1), it will initiate to send the Handover Request to the target node. On receiving the Handover Request command the target relay candidate(Relay 3) will allocate the required resources both on the access and backhaul links and respond to the source node positively.

An advantage of this approach is that the speed of preparation phase is improved because the source node is able to evaluate the resource availability of the target relay node without initiating any additional signalling or incurring additional unnecessary latency. This is beneficial given the vast amount of relay deployment to be foreseen by operators to meet the key LTE-A requirement of supporting a peak data rate of 1Gbps in the downlink. As mentioned before, the handover will be successful only when source nodes have up-to-date information as stale information will have detrimental effects. This in turn requires more frequent information exchange. However, this will increase the signalling cost.

Reactive Strategy The system is also based on the network illustrated in Figure 1. In this embodiment the nodes do not periodically exchange backhaul link information with one another in the immediate neighbourhood. Instead, at the time of a handover, the source node(Relay 1) acquires on-demand the backhaul information selectively, in case the possible target node candidates include one or more relay nodes. A drawback of this embodiment is the latency involved due to the need to collect information from a plurality of target node on-demand. This is because the optimal target node selection requires the knowledge of the neighbouring node's resource availability and link quality. If this information is not available to the source node(Relay 1), the handover may fail.

Hence, in this reactive approach there is a need to trade off the latency against handover failure rate. Two alternatives are possible, and for ease of understanding will be termed hereinafter the first Reactive Strategy and the second Reactive Strategy.

The objective of the first Reactive Strategy is to bring down the inevitable latency resulting from the reactive operations. Handover success is less important. The objective of the second Reactive Strategy is to prioritise handover success, irrespective of the length of time the information acquiring phase takes.

Accordingly, based on the access link quality measurement report, if a source node determines that a handover is necessary it will compile a list of target nodes based on the access link quality measurements. The remainder of the preparation phase depends on which Reactive Strategy (first or second) is adopted.

In the first Reactive Strategy, depending on the access link quality and other load-balancing criteria being imposed, the source node(Relay 1) will first select the best target node candidate. However, if the best target node is a relay 3, the backhaul link quality and resource availability is important for a successful handover. In this embodiment, this information is not available prior to the measurement report to the source node. Hence, the source node(Relay 1) determines whether or not a handover is to be attempted purely based on the access link quality information, even if the target node is a Relay 3.

Whenever the source node initiates a handover due to link quality degradation or load-balancing purposes, it will send a Handover Request to the chosen target node either via NAS, X2-AP or via RRC, depending on the relay architecture alternatives. If the target node is a relay, the target relay will in turn initiate a Resource Allocation Request to its respective D-eNB 5 for the purpose of setting aside or allocating the required amount of radio resources, especially in the backhaul link, before it responds to the source node. If the D-eNB 5 of the target Relay 3 does not have enough backhaul resources (i.e., MBSFN sub-frames cannot be configured to enable DL backhaul transmission), it rejects the handover attempt and notifies the target Relay 3. The target Relay 3 in turn sends the negative response to the originator of the Handover Request (i.e. source node(Relay 1)). If the D-eNB 5 has adequate radio and buffer resources, it first allocates said required resources and notifies the target Relay 3 using a command, which for example may be a Resource Allocation Response. The target relay candidate can thus locally reserve resources on the access-link, in case it has the required amount of resources, and respond positively using a Handover Request Ack. This Resource Allocation Request and Resource Allocation Response can be realised using a new set of NAS, X2-AP and/or RRC signalling depending on the availability of interfaces between a D-eNB and one of its relays.

The rest of the procedures will follow as usual, and the complete signalling flow diagrams for the first Reactive Strategy as applicable to different relay architecture alternatives are shown in Figures 3, 4, 5 and 6. In this connection, Figure 3 relates directly to architecture Alternative 1, and shows an S/P-GW for both the relay node 12 and the user equipment 10.

Figure 4 shows an example of the arrangement for architecture Alternative 2. Here only a S/P-GW 10 for the UE is provided. Figure 5 shows the architecture for Alternative 3. In this architecture alternative, the gateway (RN) is co-located at the D-eNB. Finally, Figure 6 shows the arrangement for architecture Alternative 4.

Figures 3, 4, 5 and 6 illustrates the operations of the first Reactive Strategy, as applicable to different relay architecture alternatives. For illustrative purposes, the scenario where the handover is between two relays belonging to different D-eNBs is used, although the proposed solution applies equally to any other handover scenarios as well where a target node and/or the source node (only in the case of Alternative 4) happens to be a relay. The reference numerals used in these sections correspond to those used in Figure 1.

As it can be seen from the figures, this measurement taking and reporting process pertaining to an access link occurs first. When the Source node(Relay 1) anticipates an imminent handover due to signal quality degradation or load balancing, it will initiate the Handover Request to the target node(Relay 3). As the target node(Relay 3) is a relay, it will send the Resource Allocation Request to its respective D-eNB 5 for the purpose of reserving resource in the backhaul link, if it is available. D-eNB 5 will perform an admission control and respond with a Resource Allocation Response either positively or negatively depending on the backhaul resource availability. The rest of the procedures are going to be the same as those of any conventional handover except in the case of relay Architecture 4.

In relay Architecture 4, in addition to the envisaged handover operation, the D-eNB will start buffering the required SDUs(Service Data Units) on seeing an imminent handover only when the source node happens to be a relay. With this arrangement, the buffer forwarding can be from the D-eNB 4 serving the Source Relay I as opposed to this being initiated from the source relay itself.

According to second Reactive Strategy, the source node(Relay 1) will first short-list possible target relays based on the measurement reports received for the access links. Subsequently, the source node(Relay 1) obtains the relevant backhaul information pertaining to those short-listed target relay candidates on-demand by contacting either their relevant D-eNBs 4, 5 or the short-listed relays themselves using special signalling commands such as "Backhaul Link Information Request" and "Backhaul Link Information Response". Once the backhaul information is available for the possible target relays, the source node(Relay 1) will collate the backhaul information with the access link quality information acquired from the neighbour-list measurement reports and find the most appropriate target node. The source node will then initiate a Handover Request to the chosen target node 3. The operations involved in the second Reactive Strategy may incur some latency because of the need to gather relevant backhaul information from possible target relay candidates or from their D-eNBs.

Figures 7, 8, 9 and 10 illustrates the operations of the second Reactive Strategy, as applicable to relay architecture Alternatives 1, 2, 3 and 4 respectively.

Referring to Figures 7, 8, 9 and 10, this following describes the operation of the second Reactive Strategy, as applicable to the four different relay architecture alternatives (as describes above). This embodiment considers what may be considered as the worst case scenario, where the handover is between two relay nodes belonging to two different D-eNBs, although the proposed solution applicable equally to any other handover scenarios.

Measurement taking and reporting processes pertaining to access link and any direct link (a link between a D-eNB and a UE) take place initially. Whenever the source node(Relay 1) anticipates an imminent handover due to signal quality degradation or load balancing, it will first short-list the possible target relay candidates based on the measurement report received for the access link. Subsequently, the source node(Relay 1) seeks the relevant backhaul information pertaining to those short-listed target relay candidates on demand by contacting either their relevant D-eNBs 5 or the candidate target nodes(Relay 3). The source node(Relay 1) initiates the Backhaul Link Information Request, using a proposed command for requesting the backhaul information relevant to those short-listed target relay candidates, either to those target relay nodes or to the relevant D-eNBs. In response to this request, the relevant relay nodes or the D-eNBs will send Backhaul Link Information Response, a newly proposed command for responding to the Backhaul Link Information Request command, to the source node through NAS, RRC or X2-AP signalling protocol depending on the relay architecture alternatives.

Once the backhaul link information is available for the possible target relay candidates, the source node(Relay 1) will collate the backhaul information with the access link quality information acquired from the neighbour-list measurement reports and find the most appropriate target node for successful handover. The source node(Relay 1) will then initiate the Handover Request command to the selected target node. If the target node happens to be a relay, it will send the Resource Allocation Request to its respective D-eNB 5 for the purpose of reserving resource in the backhaul link, if it is available. The given D-eNB will perform an admission control and respond with a Resource Allocation Response either positively or negatively depending on the backhaul resource availability. The rest of the procedures is the same as those of a conventional handover, except in the case of relay architecture Alternative 4.

In relay Architecture 4, in addition to the envisaged handover operation, the D-eNB will start buffering the required SDUs on seeing an imminent handover only when the source node is a relay. With this arrangement, the buffer forwarding can be from the D-eNB 4 serving the source node(Relay 1) as opposed to this being initiated from the source relay itself.

The handover success rate for the second Reactive Strategy is generally higher than that of the first Reactive Strategy. However, the second Reactive Strategy may incur additional latency because of the need to check the backhaul link quality and resource availability of the possible target relay candidates (i.e., short-listed candidates). Although this additional latency incurred will be less in the case of first Reactive Strategy in comparison with the second Reactive Strategy, the handover failure rate may be high in this case due to the fact that a Handover Request is triggered without knowledge as to the resource availability or quality of the backhaul links involved.

The Reactive Strategy as a whole has the desirable feature of incurring less signalling overhead when compared to that of the Proactive Strategy. However, it incurs additional latency because of the need to acquire relevant backhaul information.

Hybrid Strategy This strategy is formed by proportionately combining the previous two strategies (proactive and reactive) so as to synergise the inherent advantages independently available in each of those strategies. An objective of the Hybrid Strategy is to balance the advantages and disadvantages of both the proactive and reactive approaches in terms of the latency and the signalling overhead incurred.

Accordingly, the present strategy allows network nodes entities to exchange their relay backhaul information to each other within their D-eNB domain. This technique diminishes the signalling overhead to a certain extent which would otherwise be high in the Proactive Strategy.

At the time of a handover, based on the proactive backhaul information exchange within each D-eNB domain, if the source node is able to find a relay as target node that belongs to the same D-eNB domain, and the resource availability in both the access and backhaul links pertaining to those target relay are satisfactory, a handover can be made satisfactorily to the target relay node (or the best of them if there are a plurality) that belongs to the same D-eNB domain as that of the source node.

If an appropriate target relay is not located within the domain of a source node, or any other suitable target node found, the source node applies either the first Reactive Strategy or second Reactive Strategy. If the first Reactive Strategy is used under these circumstances, the source node will immediately send the Handover Request to one of the target relays belonging to a neighbouring D-eNB domain without any knowledge as to their backhaul links.

If the second Reactive Strategy is used, the source node will reactively acquire respective backhaul information from the possible target relay candidates that belong to the neighbouring D-eNB domains and based on such information the source node will handover to the most suitable target relay. These reactive strategies may not be always needed as described previously. The system will follow any of the reactive strategies only when the source node realises that a handover cannot be executed using the prior knowledge available at the source node.

Given that the UEs 6,7 periodically transmit their UE measurement reports pertaining to their neighbour-lists, the source node(Relay 1) can use this information along with the available prior backhaul link information so as to ensure if a handover can be performed according to the Proactive Strategy. In case the decision is positive the handover will be executed according to the Proactive Strategy and in all the other cases it will be according to the mixture of both proactive and reactive strategies.

The exchange of backhaul link information is limited to network nodes located within a D-eNB domain as shown in Figure 11. However, the neighbour-list of the UE in question may include relays/eNBs belonging to the same D-eNB domain as that of the source node, and relays/eNBs belonging to different D-eNB domains. Because of the exchange of backhaul related information within a D-eNB domain, the source node is able to know the backhaul link information of possible target relay candidates that belong to the same D-eNB domain.

Using the access and backhaul CQI information pertaining to the relays belonging to the same D-eNB domain as that of the source node ahd only access link CQI information pertaining to nodes belonging to different D-eNB domains, the source node is able to decide on the possible target node candidate. In the illustrated example, it is assumed that the best target candidates chosen based on the access link information fall within a different D-eNB domain perhaps due to the fact that backhaul andlor access links of those relay candidates belonging to the same D-eNB domain are not good enough, and hence the required information of the chosen target relay candidates' backhaul link is not readily available to the source node; i.e., the handover is between two relays that belong to different D-eNBs, Given that the source node I is not able to get the backhaul information pertaining to the target relay candidates with the periodical backhaul information exchange as they belong to two different D-eNB domains, the source node 1 will resort to the Reactive Strategy for the handover as shown by operations 5, 6 and 7 of Figure 7. Accordingly, the source node will selectively seek backhaul information from the possible target relay candidates that belong to different D-eNB domain, and choose the best target node/relay. In Figure 7 only the first Reactive Strategy is shown although the second Reactive Strategy can also be applied. The rest of the operations are similar to those applicable to a conventional handover attempt.

In the Hybrid Strategy, the source node typically uses the first Reactive Strategy (only the first Reactive Strategy is illustrated in Figure 11). However, in case the second Reactive Strategy is used, the source node 1 will send a signalling command called "Backhaul Link Information Request" either to the selected target relay candidates or their respective D-eNBs, and receive a response using the "Backhaul Link Information Response" command.

In all the above cases, it is assumed that MBSFN sub-frames may have to be configured in the access link in order to provide backward compatibility to legacy terminals and eNBs.

Moreover, these MBSFN sub-frames may be configured statically at the time of relay start-up, and if it is the case, the target relay candidate may know the backhaul link's resource availability. In other words, if this is the case, the relay may have knowledge about the load-level of the backhaul link prior to a handover. However, it is very likely that the MBSFN sub-frame configuration will be very dynamic depending on the exact number of UEs a relay supports. This is because static allocation may lead to poor resource utilisation if the particular relay is under-utilised at any period. With the dynamic configuration, the target relay may not have knowledge as to the resource availability in the backhaul link at the time it receives a handover Request, and hence, it needs to check this with its D-eNB, especially in the Reactive Strategies.

This way of checking with the D-eNB as part of a handover involving target relay may lead to another potential benefit in the case of relay architecture Alternative 4 when the source node happens to also be a relay: when the D-eNB learns of an attempted handover, it can start buffering the required SDUs locally. This can minimise or completely avoid unnecessary handover triggered buffer forwarding of data back to the D-eNB that were originally sent by the D-eNB.

Industrial applicability

The present arrangements are highly relevant in LTE-A, but also applicable for WiMAX (both IEEE 802.1 6e and IEEE 802.20) and Long range WiFi.

It will be appreciated that the presently described embodiments are for illustrative purposes only, and that the present invention should be defined by the appended claims.

Claims

Claims 1. A method of performing a handover in a telecommunications system, the system comprising: a source node operable to control a wireless communication session with a user equipment; and a relay node, wherein said method comprises the steps of: i) establishing that the user equipment desires to handover from said source node; ii) having said source node obtain backhaul link information of the relay node; and iii) based on said backhaul link information, establishing whether or not to perform said handover.
2. A method according to claim 1, wherein the source node is another relay node.
3. A method according to claim 2, wherein the source node obtains backhaul link information details of a plurality of relay nodes operable to receive handover of the wireless communication session, and, based on said backhaul link information, selects the optimal relay node.
4. A method according to any preceding claim, wherein, after receiving a measurement report including an access link quality from the user equipment, said source node requests backhaul information from said relay node prior to determining whether or not to perform said handover.
5. A method according to any preceding claim, wherein the telecommunication system comprises a plurality of domains, each domain being controlled by a controlling eNB, wherein at least one of said domains is operable to support one or more relay nodes, such that, for neighbouring domains, the controlling eNBs and the relays included therein periodically exchange backhaul link information.
6. A method according to any of claims 1 to 4, wherein the telecommunication system comprises a plurality of domains, each domain being controlled by a controlling eNB, wherein at least one of said domains is operable to support one or more relay nodes, and wherein each node within a given domain will periodically exchange backhaul information with nodes only in said domain.
7. A method according to claim 6, wherein, should a handover occur between nodes in neighbouring domains, the source node may request backhaul information from the node in the neighbouring domain.
8. A source node in a telecommunications system operable to control a wireless link to a user equipment, and, based on a measurement report from said user equipment control a handover to a second node, wherein said source node is configured to receive backhaul link information from the second node and determine whether or not a handover should be performed based on said backhaul link information.
9. A source node according to claim 8, operable to periodically receive reports from said second node regarding its backhaul link information.
10. A source node according to claim 8, operable to request said backhaul link information prior to performing said handover.
11. A source node according to any of claims 8 to 10, wherein one or both of the source node and the second node is a relay.
12. A source node according to claim 8, wherein, the source node comprises a relay located within a domain controlled by a controlling eNB, and the controlling eNB, said source node and any further nodes in said domain periodically exchange backhaul link information.
13. A source node according to claim 12, wherein the telecommunications system comprises a plurality of domains, and if a handover is desired between two nodes in different domains that the source node either requests the backhaul link information of a target node, or immediately requests handover thereto.
14. A source node according to any of claims 8 to 13, wherein a plurality of nodes, all which are operable to function as the second node, with an optimal node decided based on their respective backhaul links.
15. A telecommunications system comprising a plurality of controlling nodes, each controlling respective domains, wherein some of said domains comprises one or more relay nodes from the plurality of controlling nodes, wherein, in each domain, said one or more relay nodes periodically exchange backhaul link information with one another, such that said backhaul link information is used to determine optimal handovers within said domain.
16. A telecommunications system according to claim 15, wherein if a handover is required between nodes in different domains, the node controlling a user session requests backhaul information from possible target nodes, and selects an optimal node using said backhaul information.Amendments to the claims have been filed as follows.Claims 1. A method of performing a handover in a telecommunications system, the system comprising: a source node operable to control a wireless communication session with a user equipment; and a plurality of target nodes, including one or more relay nodes each being controlled by a respective controlling node, wherein said method comprises the steps of: i) establishing that the user equipment desires to handover from said source node; ii) having said source node obtain backhaul link information of the relay node; and iii) based on said backhaul link information, establishing whether or not to perform said handover.2. A method according to claim 1, wherein the source node is another relay node.3. A method according to claim 2, wherein the source node obtains backhaul link information details of a plurality of relay nodes operable to receive handover of the wireless communication session, and, based on said backhaul link information, selects the optimal relay node.4. A method according to any preceding claim, wherein, after receiving a measurement report including an access link quality from the user equipment, said source node requests backhaul information from said relay node prior to determining whether or not to perform said handover.5. A method according to any preceding claim, wherein the telecommunication system comprises a plurality of domains, each domain being controlled by a controlling eNB, wherein at least one of said domains is operable to support one or more relay nodes, such that, for neighbouring domains, the controlling eNBs and the relays included therein periodically exchange backhaul link information.6. A method according to any of claims 1 to 4, wherein the telecommunication system comprises a plurality of domains, each domain being controlled by a controlling eNB, wherein at least one of said domains is operable to support one or more relay nodes, and wherein each node within a given domain will periodically exchange backhaul information with nodes only in said domain.Q 7. A method according to claim 6, wherein, should a handover occur between nodes in C0 neighbouring domains, the source node may request backhaul information from the node in the neighbouring domain.8. A source node in a telecommunications system operable to control a wireless link to a user equipment, and, based on a measurement report containing access link quality measurement results from said user equipment control a handover to a second node, wherein said source node is configured to receive backhaul link information from the second node and determine whether or not a handover should be performed based on said backhaul link information.9. A source node according to claim 8, operable to periodically receive reports from said second node regarding its backhaul link information.10. A source node according to claim 8, operable to request said backhaul link information prior to performing said handover.11. A source node according to any of claims 8 to 10, wherein one or both of the source node and the second node is a relay.12. A source node according to claim 8, wherein, the source node comprises a relay located within a domain controlled by a controlling eNB, and the controlling eNB, said source node and any further nodes in said domain periodically exchange backhaul link information.13. A source node according to claim 12, wherein the telecommunications system Q comprises a plurality of domains, and if a handover is desired between two nodes in different C0 domains that the source node either requests the backhaul link information of a target node, or immediately requests handover thereto.14. A source node according to any of claims 8 to 13, wherein a plurality of nodes, all which are operable to function as the second node, with an optimal node decided based on their respective backhaul links.15. A telecommunications system comprising a plurality of controlling nodes, each controlling respective domains, wherein some of said domains comprises one or more relay nodes from the plurality of controlling nodes, wherein, in each domain, said one or more relay nodes periodically exchange backhaul link infomrntion, including link signal strength of the backhaul links of the relay nodes with their respective controlling nodes, with one another, such that said backhaul link information is used to determine optimal handovers within said domain.16. A telecommunications system according to claim 15, wherein if a handover is required between nodes in different domains, the node controlling a user session requests backhaul information from possible target nodes, and selects an optimal node using said backhaul information. r r Co r