WO2013136657A1

WO2013136657A1 - Eps mobility management by user equipments

Info

Publication number: WO2013136657A1
Application number: PCT/JP2013/000541
Authority: WO
Inventors: Sivapathalingham Sivavakeesar
Original assignee: Sharp Kabushiki Kaisha
Priority date: 2012-03-16
Filing date: 2013-01-31
Publication date: 2013-09-19
Also published as: GB201204630D0; GB2500248A

Abstract

A relay node comprising a backhaul link to a first D-eNB, wherein, following handover of the backhaul link to a second D-eNB, the relay node is operable to enforce access class barring for UEs supported by the relay node to restrict tracking area update signalling. The first D-eNB and the second D-eNB belong to different tracking areas.

Description

EPS MOBILITY MANAGEMENT BY USER EQUIPMENTS

The present invention relates to IDLE mode mobility handling. This invention is particularly relevant when associated with user equipments (UEs) being served by a relay that changes D-eNB attachment, as applicable in the context of 3GPP Long Term Evolution (LTE)-Advanced.

The first release of LTE was referred to as release-8, and provided a peak rate of 300 Mbps, a radio network delay of less than 5ms, 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 have already been deployed in some parts of the world as a natural evolution of GSM and UMTS.

In April 2008, 3GPP agreed to the plans for future work on Long Term Evolution (LTE) - i.e., LTE-A. 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 radio access in the LTE and LTE-A standard is generally termed Evolved Universal Terrestrial Radio Access Network (E-UTRAN). Certain types of E-UTRANs entities are termed eNode-Bs, and others are termed relays or relay nodes.

The network uses a new Packet Core - the Evolved Packet Core (EPC) network architecture to support the E-UTRAN.

Figure 1 shows a simplified arrangement of an LTE wireless telecommunications network 10. There is provided a base station 12 - the eNodeB, or more simply an eNB - a relay node 14 (sometimes abbreviated to RN) and two user equipments 16, 18 (sometimes abbreviated to UEs). Further details of LTE architecture may be found at www.3gpp.org.

The relay node comprises a two-way wireless link to the eNB. It will be understood that each relay in the network will have a link to a controlling eNB. The link from the relay node to the eNB is often termed the backhaul link, and is achieved by the Un interface. Each eNB is linked to the core network, and this link is the eNB's backhaul link. The controlling eNB is sometimes referred to as a donor eNB, 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.

An UE connected directly to a D-eNB is considered to be directly linked, or to comprise a direct link. Such a UE may be termed a Macro UE, or a M-UE. UE 16 shown in Figure 1 is an M-UE.

A UE's connection to a relay node is termed an access link. A UE connected to a relay node is often termed R-UE. UE 18 shown in Figure 1 is an R-UE.

Relaying is considered as an economical way of extending the coverage of a wireless communication system by improving the cell-edge throughput and system capacity. 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 channel/signals. UEs 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.

Elements of the core network are also shown in figure 1. These include a Mobile Management Entity (MME) 24, a serving gateway (SGW), a PDN gateway (PDN GW), a home subscriber server (HSS) and a serving GPRS support node (SGSN). Details of these may be found at www.3gpp.org. However, to aid understanding of the present arrangement, a brief description of the MME is now provided. The MME is the key control-node for the LTE access-network. It is responsible for idle mode UE tracking and paging procedure including retransmissions (ie in relation to UEs in RRC_IDLE mode). It is involved in the bearer activation/deactivation process and is also responsible for choosing the SGW for a UE at the initial attach and at time of intra-LTE handover involving Core Network (CN) node relocation. It is responsible for authenticating the user (by interacting with the HSS). The Non-Access Stratum (NAS) signalling terminates at the MME and it is also responsible for generation and allocation of temporary identities to UEs (the non-access stratum is a functional layer in the UMTS wireless telecommunications protocol stack between a core network and the user equipments). The layer supports signalling and traffic between those two elements. It checks the authorization of the UE to camp on the service provider's Public Land Mobile Network (PLMN) and enforces UE roaming restrictions. The MME is the termination point in the network for ciphering/integrity protection for NAS signalling and handles the security key management. Lawful interception of signalling is also supported by the MME. The MME also provides the control plane function for mobility between LTE and 2G/3G access networks with interface S3 terminating at the MME from the SGSN. The MME also terminates interface S6a towards the home HSS for roaming UEs.

The geographical area covered by the wireless telecommunications network is divided into discrete, non-overlapping areas, termed tracking areas (TAs). Each TA is assigned a unique Tracking Area ID (TAI). The use and functions of the TA are analogous to the Location Areas employed by GSM. Figure 3 shows a relationship between tracking areas and cells. As will be seen, tracking areas typically comprise multiple cells.

A TA is defined as a set of contiguous cells. The identity of the TA the cell belongs to is termed a Tracking Area Identity (TAI). TAs do not overlap with each other. In legacy systems, the dimensioning of TA is typically a network engineering issue. .

A tracking area identity (TAI) is constructed from a MCC (Mobile Country Code), a MNC (Mobile Network Code), and a TAC (Tracking Area Code). A TAC is broadcast in every E-UTRAN cell (SIB1) along with other identities. A UE is operable to construct the TAI of the cell from this chosen PLMN identity and the TAC received on the broadcast system information. A UE is operable to store a list of tracking area identities ("TAI list") identifying the tracking areas by which it is served. The TAI list can be assigned or updated by an MME when, for example, the UE connects to a network, on a periodic basis, or when the UE detects is has entered a tracking area not in its TAI list and sends a tracking area update ("TAU").

Location management for UEs in RRC_IDLE mode (ie those UEs currently inactive) is important, as the network requires location information, especially in the case of UE-terminated session setup or push services. To reduce the overhead in the E-UTRAN (eNBs and RNs) and processing in the UE, IDLE mode procedures do not require the network to know each UE location with a high-degree of accuracy. All UE-related information in the access network is normally released during long periods of inactivity. This state is called EPS Connection Management IDLE (ECM-IDLE). A UE is in ECM-IDLE state when no NAS signalling connection between UE and network exists. In ECM-IDLE state, a UE performs cell selection/reselection according to TS 36.304 and PLMN selection according to TS 23.122.

The MME retains the UE-context and the information about established bearers during idle periods. To allow the network to contact an ECM-IDLE UE, the UE updates the network with its new location whenever it moves out of its current Tracking Area (TA) using a Tracking Area Update (TAU). The MME is responsible for keeping track of the user location while the UE is in ECM-IDLE. A TAU becomes applicable after the UE has completed the Attach procedure and moved into the EMM REGISTERED state. Tracking area updates can be triggered in either RRC-IDLE or RRC-CONNECTED mode, but the UE must be in RRC-CONNECTED mode to actually complete the procedure.

Accordingly, the UE in state EMM-REGISTERED shall initiate the tracking area updating procedure by sending a TRACKING AREA UPDATE REQUEST message to the MME, when:
a) the UE detects entering a tracking area that is not in the list of tracking areas that the UE previously registered in the MME, unless the UE is configured for "AttachWithIMSI" as specified in 3GPP TS 24.368 [15A] or 3GPP TS 31.102 and is entering a tracking area in a new PLMN that is neither the registered PLMN nor in the list of equivalent PLMNs;
b) the periodic tracking area updating timer T3412 expires;
c) the UE enters EMM-REGISTERED.NORMAL-SERVICE and the UE's TIN indicates "P-TMSI";
d) the UE performs an inter-system change from S101 mode to S1 mode and has no user data pending;
e) the UE receives an indication from the lower layers that the RRC connection was released with cause "load balancing TAU required";
f) the UE deactivated EPS bearer context(s) locally while in EMM-REGISTERED.NO-CELL-AVAILABLE, and then returns to EMM-REGISTERED.NORMAL-SERVICE;
g) the UE changes the UE network capability information or the MS network capability information or both;
h) the UE changes the UE specific DRX parameter;
i) when the UE receives an indication of "RRC Connection failure" from the lower layers and has no signalling or user uplink data pending (i.e when the lower layer requests NAS signalling connection recovery);
j) when the UE enters S1 mode after 1xCS fallback;
k) due to manual CSG selection the UE has selected a CSG cell whose CSG identity and associated PLMN identity are not included in the UE's Allowed CSG list or in the UE's Operator CSG list;
l) the UE reselects an E-UTRAN cell while it was in GPRS READY state or PMM-CONNECTED mode;
m) the UE supports SRVCC to GERAN or UTRAN or supports vSRVCC to UTRAN and changes the mobile station classmark 2 or the supported codecs, or the UE supports SRVCC to GERAN and changes the mobile station classmark 3;
n) the UE changes the radio capability for GERAN or cdma2000 (Registered Mark) or both;
o) the UE's usage setting or the voice domain preference for E-UTRAN change in the UE;
p) the UE activates mobility management for IMS voice termination as specified in 3GPP TS 24.008, annex P.2, and the TIN indicates "RAT-related TMSI";
q) the UE performs an intersystem change from A/Gb mode to S1 mode and the TIN indicates "RAT-related TMSI", but the UE is required to perform tracking area updating for IMS voice termination as specified in 3GPP TS 24.008, annex P.4; or
r) upon reception of a paging indication using S-TMSI, if the timer T3346 is running and the UE's TIN indicates "P-TMSI".

Figure 2 depicts the complete TAU procedure.

Tracking area update procedure on the backhaul can operate in a legacy way. However access link TAU by R-UEs served by a mobile relay, or a relay that changes its network attachment, needs to be re-engineered.

Access to the network air interface, especially at a loaded condition can be controlled with the use of Access Class Barring (ACB). This is a mechanism to discourage regular users from accessing a cell and it applies to mobile originating requests. Its typical uses are to reserve cells for operator activities (e.g., maintenance, growth, etc.) and to reduce access overload in time of emergency or congestion situations. For normal use, access barring rate and barring time may be broadcast in case of congestion. For the special categories (see below), 1-bit barring status can be broadcast for each access class. Barring parameters could be configured independently for mobile originating data and mobile originating signalling attempts. For emergency calls, a separate 1-bit barring status is indicated. Access class barring can be appropriately employed to solve the TAU signalling problem on the access link.

All UEs are divided into sixteen access classes (0 - 15). Access to the network is, to a certain extent, dependent upon access class.

ACB uses a number of protocols -termed barring causes - to implement the desired functions.

Further details regarding Access control, ACB and barring causes may be found in TS22.011.

An eNB controls user access through broadcast of access class barring parameters in a SIB2 (SystemInformationBlockType2) and UEs perform actions according to Access Class in USIM. Access classes 0 - 9 are for regular users and their access is controlled by barring causes ac-BarringFactor and ac-BarringTime in SIB2. Accordingly, "rand" generated by the UE has to pass the "persistent" test in order for the UE to access. By setting barring causes ac-BarringFactor to a lower value, the access for a regular user is restricted (UE must generate a "rand" that is lower than the threshold in order to access) while priority users with AC 11 - 15 can access without any restriction. For users initiating emergency calls (AC 10), their access is controlled by a Boolean ac-BarringForEmergency. For UEs with AC 11- 15, access is controlled by another Boolean ac-BarringForSpecialAC.

Extended Access Barring (EAB) is a mechanism for a network operator to control mobile originating access attempts from UEs that are configured for EAB in order to prevent overload of the access network and/or the core network. In congestion situations, the operator can restrict access from UEs configured for EAB while permitting access from other UEs.

If a SystemInformationBlockType2 includes the barring causes ac-BarringInfo and the barring causes ac-BarringForMO-Signalling is present, and depending on how the corresponding bit in the ac-BarringForSpecialAC contained in ac-BarringForMO-Signalling is set for at least one of these Access Classes, access to the cell can be made barred.

Two attempts trying to address this issue have been made, and both of them have drawbacks. The first solution does not solicit any change in the way a relay node shares a TAI on the access link with the D-eNB or the way a R-UE camped on a relay node reacts when a new TAI is advertised as and when a relay gets a new TAI assigned. Here, the relay node will receive new TAIs on the access link. This will cause each R-UEs to trigger a TAU. This solution does not expect any change to the existing specification, but it will result in Avalanche of TAUs - hence, this solution is not preferable.

According to the second existing solution, a relay is assigned a unique TAI that will not change under normal circumstances (e.g., due to mobility). A relay under this solution does not share the same TAI as that of the D-eNB. This solution only functions if mobile relays do not come into close proximity with each other. This is unlikely as it will be common for (e.g.) trains/coaches carrying mobile relays to come closer to each other. When this happens R-UEs served by different relays will each trigger an avalanche of TAU signalling when they detect different TAIs being broadcast by different mobile relays. M-UEs will also react when they detect a TAI of a mobile relay and also lead to significant TAU signalling.

This second existing solution creates overlapping TAs that goes against the previously agreed arrangement (i.e., non-overlapping TAs as agreed with R3-070412) and requires additional effort or procedures in the network to trace moving TAs.

According to the one aspect of the present invention a relay node comprises a backhaul link to a first D-eNB, wherein, following handover of the backhaul link to a second D-eNB, said first D-eNB and said second D-eNB belonging to different tracking areas, said relay node is operable to enforce access class barring for UEs supported by the relay node to restrict tracking area update signalling.

According to the another aspect of the present invention a D-eNB in a first tracking area operable to receive a backhaul link of a relay node from a second D-eNB in a second tracking area, wherein on receipt of said backhaul link, the D-eNB imposes access class barring to restrict user equipment tracking area update signalling.

According to the another aspect of the present invention a user equipment is operable to maintain a record of cell-id information for a cell in which it is active and a tracking area identity list, wherein, on receipt of a tracking area identity not on said tracking area identity list, said user equipment (UE) ascertains if the cell-id has changed, and if so initiates a tracking area update.

According to the another aspect of the present invention a telecommunications system comprises a relay node, a first D-eNB and a second D-eNB, wherein said relay node maintains a unique tracking area identity, such that, when said relay node is handed over between said first D-eNB and said second D-eNB, said relay node maintains its tracking area identity, and both said relay node and said second D-eNB perform Access Class Barring or Extended Access Class Barring to limit tracking area update signalling.

Figure 1 shows an overview of LTE architecture. Figure 2 shows a simplified overview of the relationship between tracking areas and cells. Figure 3 shows an overview of TAU procedure. Figure 4 shows a flow diagram illustrating an embodiment of the present invention.

The present embodiments are provided to avoid an avalanche of tracking area updates (TAU) being triggered when a new tracking area code (TAC) is detected by UEs, while minimising the impact on existing specifications.

Each user equipment (UE) maintains a list of tracking area identities (TAIs) of tracking areas in which the UE is likely to be found. This aids the network in finding the UE when it is in an RRC_IDLE state. For example, it may be that the UE maintains a list of most visited TAs, or the last n-number of TAs.

According to current specifications, whenever a UE detects a new TAI from a E-UTRAN, via the broadcast control channel (BCCH), the UE compares the detected TAI with its list of TAIs. If the newly detected TAI is different to those maintained on its list, a UE would typically initiate a TAU procedure. This allows the network to monitor UE locations to within a reasonable area within the network.

However, mobile relay nodes are becoming more common. Mobile relay nodes may be located on a vehicle such as a train or bus. In a packed environment like a train, there will likely be many UEs being supported by the mobile relay. When a group of UEs under a mobile relay are triggered to perform TAU at the same time (because they would each detect a TAI at the same time, and it is highly likely that the new TAI will not be present on their respective TAI lists) it will result in avalanche of signalling. This is undesirable as this signalling will load the network unnecessarily. Potentially, this TAU-related signalling will starve UEs from making connections to the network for other purposes (e.g., making a call). Hence, it is necessary for this to be contained.

The phenomenon of an avalanche of TAU signalling occurs when cells having different TAIs come closer to each other. This is a likely occurrence when the network comprises mobile relays. For example, this occurs whenever a train/coach or the like carrying a relay crosses the borders of cells belonging to different D-eNBs or whenever two or more trains/coaches carrying relays come closer to each other. The present arrangement pertains to the control of avalanche effect resulting from TAU signalling due to a TA change. This scheme requires that each relay shares the same TAI as that of the D-eNB. As a result, each mobile relay in a given tracking area will take the same TAI and hence the chances that two or more relays having different TAIs getting closer to each other will be minimal.

The only situation that can lead to undesirable TAU signalling is when a relay is handed over to a new D-eNB that does not share the same TAI - i.e., at the time of backhaul handover.

Type 1 relay nodes are considered to have UE-part and an eNB-part - with the UE-part a D-eNB sees a relay as a UE whereas with an eNB part an R-UE sees a relay as an eNB. More details of this arrangement may be found in GB0921331.5 by Sharp Kabushiki Kaisha, the details of which are incorporated herein by reference. Accordingly, whenever the backhaul is successfully handed over to a new D-eNB, the UE-part will check whether the new TAI being advertised on the backhaul is different from the old one when it is attached to the previous D-eNB or does not appear in the TAI-list. In either case, prior to notifying the new TAI through a system information change on the access link, either the destination D-eNB or the mobile relay will impose Access Class Barring restricting their respective UEs (M-UEs for the D-eNB and R-UEs for the mobile relay) from originating TAU signalling in the region where the mobile relay region comes in contact with that of the destination D-eNB. Accordingly, whenever a relay node is about to be handed over to a D-eNB that belongs to a different TA than that of the relay node, the relay node will enforce ACB so that R-UEs that are already camped on to the relay will be cut off from the network from the perspectives of mobile originated signalling, and/or especially TAU signalling.

A particular relay will not have to always enforce TAU signalling specific ACB at every cell border, because it is not necessary when the source D-eNB and the target D-eNB (from a relay handover perspective) belong to the same TA.

Access class barring is a probabilistic technique in that if a random number drawn by the UE is lower than the ac-BarringFactor, access is allowed; otherwise the access is barred. Accordingly, not every UE is prevented from initiating TAU signalling for a given time period as specified by ac-BarringTime; instead only a limited number of UEs. The value of ac-BarringFactor can be modified by the operator depending on how popular a given area in terms of UE population, for instance. In a preferred arrangement, existing barring cause ac-BarringFor MO-Signalling - as defined in SystemInformationBlockType2 -can be used to impose ACB to limit TAU signalling after a TAI change.

Thus, the purpose of the present arrangement is not to prevent every UE connected with a given E-UTRAN from initiating a TAU on detecting a new TAI, but to restrict the number so as to not overload the network.

This arrangement can be implemented under the provision of Service Specific Access Control as defined in TS 22.011 whereby independent access control for telephony services (MMTEL) for mobile originating session requests from idle-mode or this arrangement can be implemented using extended ACB as defined in section 4.3.4 of TS22.011 V11.2.0 (2011-12). This mechanism minimizes service availability degradation (i.e. radio resource shortage) due to the mass simultaneous mobile originating session requests and maximizes the availability of the wireless access resources for non-barred services.

To restrict only TAU signalling, a new barring cause (ac-BarringInfo) or information (e.g., ac-BarringForEmergency, ac-BarringForMO-Signalling and ac-BarringForMO-Data) is introduced. This new barring cause is called ac-BarringForTAU-Signalling. This cause bars mobile originating TAU signalling. It is captured in SystemInformationBlockType2 field descriptions, as specified in TS 36.331 - this is exemplarily indicated in the two equally preferably ASNs set out below.

SystemInformationBlockType2 information element (embodiment 1)
-- ASN1START
SystemInformationBlockType2 ::= SEQUENCE {
ac-BarringInfo SEQUENCE {
ac-BarringForEmergency BOOLEAN,
ac-BarringForMO-Signalling AC-BarringConfig OPTIONAL, -- Need OP
ac-BarringForTAU-Signalling AC-BarringConfig OPTIONAL, -- Need OP
ac-BarringForMO-Data AC-BarringConfig OPTIONAL -- Need OP
} OPTIONAL, -- Need OP
radioResourceConfigCommon RadioResourceConfigCommonSIB,
ue-TimersAndConstants UE-TimersAndConstants,
freqInfo SEQUENCE {
ul-CarrierFreq ARFCN-ValueEUTRA OPTIONAL, -- Need OP
ul-Bandwidth ENUMERATED {n6, n15, n25, n50, n75, n100}
OPTIONAL, -- Need OP
additionalSpectrumEmission AdditionalSpectrumEmission
},
mbsfn-SubframeConfigList MBSFN-SubframeConfigList OPTIONAL, -- Need OR
timeAlignmentTimerCommon TimeAlignmentTimer,
...
}
AC-BarringConfig ::= SEQUENCE {
ac-BarringFactor ENUMERATED {
p00, p05, p10, p15, p20, p25, p30, p40,
p50, p60, p70, p75, p80, p85, p90, p95},
ac-BarringTime ENUMERATED {s4, s8, s16, s32, s64, s128, s256, s512},
ac-BarringForSpecialAC BIT STRING (SIZE(5))
}
MBSFN-SubframeConfigList ::= SEQUENCE (SIZE (1..maxMBSFN-Allocations)) OF MBSFN-SubframeConfig
MBSFN-SubframeConfig ::= SEQUENCE {
radioframeAllocationPeriod ENUMERATED {n1, n2, n4, n8, n16, n32},
radioframeAllocationOffset INTEGER (0..7),
subframeAllocation CHOICE {
oneFrame BIT STRING (SIZE(6)),
fourFrames BIT STRING (SIZE(24))
}
}
-- ASN1STOP
SystemInformationBlockType2 information element (embodiment 2)
SystemInformationBlockType2 ::= SEQUENCE {
ac-BarringInfo SEQUENCE {
ac-BarringForEmergency BOOLEAN,
ac-BarringForMO-Signalling AC-BarringConfig OPTIONAL, -- Need OP
ac-BarringForMO-Data AC-BarringConfig OPTIONAL -- Need OP
} OPTIONAL, -- Need OP
radioResourceConfigCommon RadioResourceConfigCommonSIB,
ue-TimersAndConstants UE-TimersAndConstants,
freqInfo SEQUENCE {
ul-CarrierFreq ARFCN-ValueEUTRA OPTIONAL, -- Need OP
ul-Bandwidth ENUMERATED {n6, n15, n25, n50, n75, n100}
OPTIONAL, -- Need OP
additionalSpectrumEmission AdditionalSpectrumEmission
},
mbsfn-SubframeConfigList MBSFN-SubframeConfigList OPTIONAL, -- Need OR
timeAlignmentTimerCommon TimeAlignmentTimer,
...
lateNonCriticalExtension OCTET STRING OPTIONAL, -- Need OP
[[ ssac-BarringForMMTEL-Voice-r9 AC-BarringConfig OPTIONAL, -- Need OP
ssac-BarringForMMTEL-Video-r9 AC-BarringConfig OPTIONAL -- Need OP
]],
[[ ac-BarringForCSFB-r10 AC-BarringConfig OPTIONAL -- Need OP
]],
[[ ac-BarringForTAU-Signalling AC-BarringConfig OPTIONAL -- Need OP
]]
}

The new barring cause can be accommodated in SystemInformationBlockType2 under the provision of non-critical or critical extension mechanisms as specified in A3.3 and A4 of TS 36.331. The new barring cause can be accommodated while making use of the extension maker provided after the timeAlignmentTImerCommon information element of the current SystemInformationBlockType2. However, those skilled in the art will realise that modification of how the new ac-BarringInfo is introduced in the SystemInformationBlockType2 in terms of how the NAS notifies the barring cause to the AS, and vice versa.

A set of operational procedures for a first embodiment are depicted in Fig. 4. This set of procedures are executed within a mobile relay or a relay node that changes its network attachment (i.e., changing the D-eNBs for various reasons such as load-balancing).

Referring to Fig. 4, a relay monitors whether its backhaul is handed over to a new D-eNB (destination D-eNB) from the originally serving D-eNB (Source D-eNB). If the relay node affirms that the backhaul has been handed over, the relay will subsequently check whether the new TAI that it shares with the new D-eNB (i.e., destination D-eNB) is different from the previous TAI. If the TAI is not different, no action is taken, and the mechanism is reset. If the TAI is different, the relay node will impose ACB within its region. For imposing ACB, the relay node can use existing barring causes such as ac-BarringForMO-Signalling along with the appropriate ac-BarringFactor and ac-BarringTime barring causes. In order to specifically prevent a UE from unnecessarily initiating only TAU related signalling a new barring cause termed ac-BarringForTAU-Signalling may be provided. The barring cause may be used along with the appropriate ac-BarringFactor and ac-BarringTime. Once the ac-BarringTime has timed out, the relay can lift the ACB.

Thus, preferred embodiments particularly relate to an arrangement with a relay node comprising a backhaul link to a first D-eNB (also termed Source D-eNB). When handover of the backhaul link to a second D-eNB (also termed destination D-eNB) occurs, and the first D-eNB and second D-eNB belonging to different tracking areas, the relay node is operable to enforce access class barring for UEs supported by the relay node to restrict tracking area update signalling.

Two options are available: the access class barring can use a dedicated barring cause to restrict tracking area updates (the ac-barringforTAU-signalling barring cause); or use barring cause ac-barringforMO-signalling to restrict tracking area updates. Both are equally preferred. In the second option, it is preferred that the barring causes are adapted to only limit tracking area updates. The access class barring uses one of the access class barring configuration parameters such as ac-Barring factor to determine an access threshold, wherein the access threshold is adaptive based upon network conditions.

In particularly preferred arrangements the relay is a mobile relay mounted upon a vehicle.

The relay node will actively determine if the first D-eNB and the second D-eNB belong to different tracking areas, and also will monitor for when its backhaul link is handed over between D-eNBs.

According to an embodiment, in order for second D-eNB to detect that the relay that is more likely to be handed over to it has been using a different TAI from what is used by the second D-eNB, the handover request can include the TAI being used by the relay. Unless a relay and the first/Source D-eNB share the same TAI, the first/Source node can prompt the relay to send its TAI information to it - this can happen before a first/source D-eNB initiates a Handover Request command to a second/destination D-eNB. With this information, the second D-eNB according to this embodiment is able to determine whether its TAI is different from the TAI that is used by the relay. If these TAIs are different, the second D-eNB according to this embodiment will impose ACB in its region to control TAU. Alternatively, according to another embodiment, the second/destination D-eNB can learn the TAI of the relay being handed over directly from the relay itself or from the source D-eNB any time between the time the second/destination D-eNB received the Handover Request and the time the successful handover of a relay is made.

According to an embodiment, the second D-eNB can impose ACB in the region (say, affected regions) where the relay is likely to be handed over after it receives the handover request command. Alternatively, according to another embodiment, it can impose ACB, once a relay is successfully handed over to it. According to another alternative embodiment, the second D-eNB can impose the ACB in the affected regions any time between the time it received the Handover Request and the time the successful handover of a relay is made.

The destination D-eNB can also impose ACB in the regions/cells that coincide with that of a recently handed over mobile relays. It can learn from the Source D-eNB from which a relay is handed over whether the relay and its own cells belong to the same Tracking Area and hence uses the same TAI. The handover request from a Source D-eNB can include such information.

In a further preferred arrangement a D-eNB in a first tracking area operable to receive a backhaul link of a relay node (such as a mobile relay node) from a second D-eNB in a second tracking area. On receipt of the backhaul link, the D-eNB imposes access class barring to restrict user equipment tracking area update signalling. It is particularly preferred that the D-eNB receives from the second D-eNB in a handover request details of the second D-eNB's tracking area identity.

In preferred embodiments both the relay node and the destination D-eNB will use ACB to restrict TAU signalling for both R-UEs and M-UEs.

In an alternative arrangement it is possible to limit unnecessary TAU signalling by adapting UE functions. This scheme requires only UEs to restrict unnecessary TAU signalling without change on the network-side. According to this scheme relays are allowed to share the same TAI as that of the D-eNB. An R-UE will keep an account of the cell-id of the cell which it camps on and the TAI of the cell. Whenever the RRC passes tracking area information on to the NAS of the UE, it will also pass the cell-id, sometimes called the physical cell identifier (PCI). In addition, the NAS of every UE will maintain the CELL-ID (e.g., PCI) of the cell it camps on in a local cache which is subject to a timeout. Whenever it receives a TAI that is not in the TAI-list, it will check to see whether it still camps on the same cell. It will initiate the TAU due to TAI change only if both cell-ID and TAI are changed.

If the cell-id stays the same, but a new TAI is detected, an R-UE may initiate a TAU. This is determined randomly. The R-UE will generate a random number, and will initiate a TAU only if a random number generated is lower than a predetermined constant value. By making this TAU triggering random, this arrangement will limit the Avalanche effect without compromising the network traceability.

According to an embodiment, in order to avoid unnecessary TAU registration under the multi-TA Registration scheme, an R-UE is expected to monitor the cell-ID, cell-type and TAI-list. Accordingly, if the cell-id stays the same and the camped on cell is a mobile relay, a UE will not initiate a TAU due to TAI change. Also, if a UE is currently camped on a fixed cell, it will not initiate TAU whenever a TAC/TAI from a mobile relay is detected. Future release UEs should be able to identify cell-type (i.e., moving/fixed relay, eNB, D-eNB etc.) in order to control unnecessary TAU Signalling. According to an embodiment, cell-type information is included in the in the E_UTRA BCH system information (SI) broadcast in addition to namely PCI and TAC. This way, unnecessary TAU signalling attempts by UEs with an introduction of mobile relays as per multi-TA registration can be minimised or avoided completely. This solution is agnostic and hence is applicable to situations where a relay is assigned a unique TAI that will not change under normal circumstances (e.g., due to mobility) or where a relay can share the same TAI as that of the D-eNB it attaches to.

In this preferred embodiment a UE is operable to maintain a record of cell-id information for a cell in which it is camped on and a tracking area identity list. On receipt of a tracking area identity not on said tracking area identity list, the UE ascertains if the cell-id has changed, and if so initiates a tracking area update - ie the UE must move between cells and enter a new tracking area (one not on its TAI list) to automatically issue a TAU.

Preferably, if the UE determines that the tracking area identity is not on its tracking area identity list, but the cell-id remains unchanged, the UE will randomly determine whether or not to send a tracking area update. The UE generates a random number, and only initiates a tracking area update if said random number is below a predetermined threshold.

In relation to the above embodiment, a mobile telecommunications system comprising such a user equipment functions such that, within the UE, the access spectrum (AS) passes new cell-ids to the non-access stratum (NAS), when passing tracking area identity information.

In a further embodiment, a relay is assigned a unique TAI that will not change under normal circumstances (e.g., due to mobility). In other words, according to this further embodiment a relay does not change its TAI under any circumstance nor does it share the same TAI as that of the D-eNB. In this further embodiment, whenever such a relay gets its backhaul handed over to a D-eNB that has a different TAI, both the relay and D-eNB concerned will impose access class barring or extended access class barring as specified in TS 22.011, for instance in their respective serving regions, in order to prevent R-UES and M-UEs from initiating unnecessary TAUs.

According to an embodiment, in order to accommodate a situation where two or more moving/fixed relays using completely different TAIs get close to each other, provisions are made for each such relay to impose ACB on its respective access link whenever the backhaul detects a different TAI that is not listed in the TAI-list of the backhaul. In other words, according to an embodiment, the UE-part of a given relay detects a new TAI, it will coordinate with the eNB-part of the same relay to impose ACB on its access link.

According to a first aspect of the present invention there is provided a relay node comprising a backhaul link to a first D-eNB, wherein, following handover of the backhaul link to a second D-eNB, said first D-eNB and said second D-eNB belonging to different tracking areas, said relay node is operable to enforce access class barring for UEs supported by the relay node to restrict tracking area update signalling. This arrangement is advantageous in that it will restrict the number of R-UEs from each initiating a TAU, and hence avoid significant resource wastage with multiple unnecessary signalling.

In one embodiment, the access class barring uses a dedicated barring cause to restrict tracking area updates. This may be termed ac-barringforTAU-signalling. However, in an equally preferred embodiment the access class barring uses an existing barring cause ac-barringforMO-signalling to restrict tracking area updates. The ac-barringforMO-signalling barring cause would prevent all mobile originating signalling attempts, namely Attach, Detach and TAU while in operation. As such, it is preferred that the barring causes are adapted to only limit tracking area updates. The time period that these barring causes remain operational is controlled by the relay node, and may vary dependent upon network conditions.

E-UTRAN are operable to form combinations of access control based on the type of access attempt, e.g. mobile originating and mobile terminating, or location registration. More details of this may be found in TS 22.011. Based on this, the relay node is able to adapt existing barring causes to limit only TAU signalling, where appropriate. Thus, the preferred arrangement functions such that appropriate barring causes, as specified in relevant 3GPP standards, are adapted to only limit tracking area updates.

Preferably the access class barring uses one of the access class barring configuration parameters such as ac-Barring factor to determine an access threshold. It is also preferred that the access threshold is adaptive based upon network conditions.

It is particularly preferred that the relay is a mobile relay mounted upon a vehicle. The relay node may be advantageously mounted upon a train on a bus. Given that many commuters may travel on buses, coaches or high speed trains, it is desirable to avoid the need to each UE to handover D-eNBs every time the vehicle passes through a cell. By mounting a relay upon a vehicle there results in the need to only handover the relay node's backhaul link when moving between cells.

Preferably the relay node actively determines if the first D-eNB and the second D-eNB belong to different tracking areas.

It is preferred that the relay node monitors for when its backhaul link is handed over between D-eNBs and impose the ACB.

According to a second aspect of the present invention there is provided a D-eNB in a first tracking area operable to receive a backhaul link of a relay node from a second D-eNB in a second tracking area, wherein on receipt of said backhaul link, the D-eNB imposes access class barring to restrict user equipment tracking area update signalling.

This arrangement will avoid an avalanche of TAU signalling from M-UEs.

Preferably the D-eNB receives from the second D-eNB in a handover request details of the second D-eNB's tracking area identity. By receiving this information in the initial handover request the D-eNB is able to timely initiate ACB to restrict M-UEs from each sending a TAU on the approach of a mobile relay.

Preferably the D-eNB receives from the second D-eNB in a handover request details of the tracking area identity of the relay being handed over to it. By receiving this information in the initial handover request the D-eNB is able to timely initiate ACB to restrict M-UEs from each sending a TAU on the approach of a mobile relay.

The above aspects reflect enhancements to the network side of a wireless telecommunications system, and would function with legacy user equipments.

It will be appreciated that the present invention is also directed to a wireless telecommunications network comprising a D-eNB according to the second aspect, and a relay node according to the first aspect. When used in conjunction, the D-eNB will stop an avalanche TAU effect for M-UEs, whilst the relay node will stop an avalanche TAU effect for R-UEs.

According to a third aspect of the present invention there is provided a user equipment operable to maintain a record of cell-id information of a cell where it is camped on at the NAS-level and a tracking area identity list, wherein, on receipt of a tracking area identity not on said tracking area identity list, said user equipment (UE) ascertains if the cell-id has changed, and if so initiates a tracking area update.

This arrangement does not require modification to existing network systems, and only requires changes to UEs.

Preferably, if the UE determines that the tracking area identity is not on its tracking area identity list, but the cell-id remains unchanged, the UE will randomly determine whether or not to send a tracking area update.

Preferably the UE generates a random number, and only initiates a tracking area update if said random number is below a predetermined threshold.

In a preferred embodiment, a mobile telecommunications system comprises a user equipment of the third aspect of the present invention, wherein within the UE, the access spectrum passes new cell-ids to the non-access stratum (NAS), when passing the TAI information. The access stratum (AS) is a functional layer in the UMTS wireless telecom protocol stack between the network and UE.

A problem that an embodiment of the present invention seeks to address is that, if not controlled, whenever a Mobile Relay (MR) gets its backhaul handed over to a different D-eNB having a TAI being different from that of an MR, Avalanche of TAU signalling will be caused that would starve UEs from connecting to the network for making calls for instance. In contrast, an embodiment having the features of claim 1 enables an MR to impose a access class barring whenever this happens. That is, according to an embodiment, the ACB is used to contain Avalanche of TAU signalling whenever there is a large group mobility is involved.

According to an embodiment having the features of claim 2, to restrict only TAU signalling, a new barring cause (ac-BarringInfo) or information (e.g., ac-BarringForEmergency, ac-BarringForMO-Signalling and ac-BarringForMO-Data) is introduced. This new barring cause is called ac-BarringForTAU-Signalling. With this, an embodiment having the features of claim 2 can prevent UEs from making only TAU signalling but UEs that would like to attach/detach are allowed to initiate their operations which will be stopped if a generic barring cause like ac-BarringForMO-Signalling is used.

According to an embodiment having the features of claim 3, existing barring cause (ac-BarringInfo) or information such as ac-BarringForMO-Signalling can also be used.

According to an embodiment, introduction of the new barring cause (ac-BarringInfo) ac-BarringForTAU-Signalling is to control only UE's attempt to initiate TAU Signalling.

As specified in TS 36.331, one of the access class barring configuration parameters such as ac-BarringFactor can be used to adjust the extend of ACB required.

According to an embodiment having the features of claim 6, by selecting an ideal Value for depending on factors like the popularity of a given place/train etc., TAU can be appropriately contained.

According to an embodiment, this kind of ACB can be used whenever MRs are deployed too.

According to an embodiment, whenever MR is deployed, it is the duty of MR to constantly monitor whether it moves into a new tracking area.

According to an embodiment, whenever MR is deployed, it is the duty of MR to constantly monitor whether backhaul Handover has OR more likely to be taken place and to impose ACB under such circumstances.

According to an embodiment, D-eNB imposes ACB whenever a backhaul has been handed over to it from another D-eNB - both of them belong to different tracking areas.

According to an embodiment having the features of claim 11, in order for the first D-eNB in the first tracking area to decide whether OR not to deploy ACB by knowing in advance whether the Second D-eNB belongs to a different tracking area, the Second D-eNB's tracking Area is notified in the Handover Request command.

An embodiment having the features of claim 14 seeks to control TAU without expecting any change on the network side; instead, by making a UE intelligent, TAU is contained appropriately.

According to an embodiment, UEs are expected to monitor cell-ID change and TAI-change.

According to an embodiment having the features of claim 16, whenever TAI changes happens whilst being camped on the same cell OR MR, a UE will initiate TAU randomly.

According to an embodiment having the features of claim 17, cell-Id information is passed from the AS to NAS of a UE and is cached.

According to an embodiment having the features of claim 18, ACB is employed to contain Avalanche of TAU signalling even when an MR takes a unique TAI that does not change with its network attachment.

According to an embodiment having the features of claim 19, ACB is employed to contain Avalanche of TAU signalling even when an MR takes a unique TAI that does not change with its mobility.

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

Most relevant in LTE-A, although its applicability cannot be ruled out for WiMAX (both IEEE 802.16e and IEEE 802.20) and Long range WiFi.

Claims

A relay node comprising a backhaul link to a first D-eNB, wherein, following handover of the backhaul link to a second D-eNB, said first D-eNB and said second D-eNB belonging to different tracking areas, said relay node is operable to enforce access class barring for UEs supported by the relay node to restrict tracking area update signalling.
A relay node according to claim 1, wherein said access class barring uses a dedicated barring cause to restrict tracking area updates.
A relay node according to claim 1, wherein said access class barring uses barring cause ac-barringforMO-signalling to restrict tracking area updates.
A relay node according to claim 1 or 3, wherein existing barring causes as specified in 3GPP standards are adapted to only limit tracking area updates.
A relay node according to any preceding claim, wherein said access class barring uses one of the access class barring configuration parameters such as ac-Barring factor to determine an access threshold.
A relay node according to claim 5, wherein the access threshold is adaptive based upon network conditions.
A relay node according to any preceding claim, wherein said relay is a mobile relay mounted upon a vehicle.
A relay node according to any preceding claim, wherein the relay node actively determines if the first D-eNB and the second D-eNB belong to different tracking areas.
A relay node according to any preceding claim, wherein the relay node monitors for when its backhaul link is handed over between D-eNBs.
A D-eNB in a first tracking area operable to receive a backhaul link of a relay node from a second D-eNB in a second tracking area, wherein on receipt of said backhaul link, the D-eNB imposes access class barring to restrict user equipment tracking area update signalling.
A D-eNB according to claim 10, wherein said D-eNB receives from the second D-eNB in a handover request details of the second D-eNB's tracking area identity.
A D-eNB according to claim 10, wherein said D-eNB receives from the second D-eNB in a handover request details of the relay's tracking area identity.
A wireless telecommunications network comprising a D-eNB according to any of claims 10 to 12, and a relay node according to any of claims 1 to 9.
A user equipment operable to maintain a record of cell-id information for a cell in which it is active and a tracking area identity list, wherein, on receipt of a tracking area identity not on said tracking area identity list, said user equipment (UE) ascertains if the cell-id has changed, and if so initiates a tracking area update.
A user equipment according to claim 14, wherein if the UE determines that the tracking area identity is not on its tracking area identity list, but the cell-id remains unchanged, the UE will randomly determine whether or not to send a tracking area update.
A user equipment according to claim 15, wherein the UE generates a random number, and only initiates a tracking area update if said random number is below a predetermined threshold.
A mobile telecommunications system comprising a user equipment according to any of claims 14 to 16 wherein, within the UE, the access spectrum passes new cell-ids to the non-access stratum (NAS), when passing tracking area identity information.
A telecommunications system comprising a relay node, a first D-eNB and a second D-eNB, wherein said relay node maintains a unique tracking area identity, such that, when said relay node is handed over between said first D-eNB and said second D-eNB, said relay node maintains its tracking area identity, and both said relay node and said second D-eNB perform Access Class Barring or Extended Access Class Barring to limit tracking area update signalling.
The telecommunications system of claim 18, wherein said relay node is a mobile relay node.
The telecommunications system of claim 18, wherein said second D-eNB receives from the first D-eNB in a handover request details of the relay's tracking area identity.