Handover failure handling

METHOD IMPLEMENTED IN A WIRELESS TRANSMISSION AND RECEPTION UNIT AND WIRELESS TRANSMISSION AND RECEPTION UNIT

FIELD OF THE INVENTION

[001] This application relates to wireless communication systems. BACKGROUND

[002] In Step 2 of an evolved universal terrestrial radio access network (E-UTRAN), the cases in which the wireless transmission and reception unit (WTRU) selects a cell that belongs to the same eNode B after a link failure radio (RL) are listed for further study (FFS). It has been proposed that if the WTRU selects a cell other than the same eNode B, the activity cannot be resumed without interaction between the WTRU and eNode B. Currently, the radio access network 2 (RAN2) specifies that if the WTRU selects a cell from a different eNode B, it needs to go to sleep through radio resource control (RRC).

[003] Currently, RAN2 decisions on RL failure are determined based on two phases. The two phases govern the behavior associated with RL failures and are shown in figure 1.

[004] A first phase starts when a radio problem is detected, which generates an RL failure detection. As a result, there is no WTRU-based mobility based on a timer or other criteria (such as counting) (T1).

[005] A second phase begins when a radio link failure is detected, which generates RRC_Idle. WTRU-based mobility is still available, which is timer-based (T2).

[006] Table 1 below describes how mobility is currently handled with respect to an RL failure.

Table 1

Mobility and Failure of Radio Links

<td>Cases</td><td>First phase</td><td>Second level</td><td>T2 expired</td>

<td>UE returns to the same cell</td><td>Proceed as if there is no radio problem</td><td>The activity cannot be resumed without interaction between the UE and the</td><td>Go via RRC_IDLE</td>

Petition 870190112801, of 11/04/2019, p. 15/36

2/15

<td></td><td></td><td>eNode B. The procedure to be used is FFS, usually not via RRC_IDLE</td><td></td>

<td>EU selects a different cell from the same eNode B</td><td>AT</td><td>FFS</td><td>Go via RRC_IDLE</td>

<td>EU selects a cell from a different eNode B</td><td>AT</td><td>Go via RRC_IDLE</td><td>Go via RRC_IDLE</td>

[007] A recent proposal divides the handover into 2 (two) phases similar to the

RL and suggests a handover failure handling procedure.

[008] In the first phase, the WTRU tries to synchronize and have access to the target cell, such as during a T1 timer. In the second phase, the WTRU aborted the handover, as it failed, and tries to reestablish the lost connection to the network, such as during a T2 timer. After the second phase, the UE enters RRC_IDLE.

[009] Figure 2 shows the two phases that govern the behavior associated with handover failure during mobility controlled by the network according to the current proposal.

[0010] The first phase begins with a first attempt to synchronize to a target cell; and generates a handover failure detection. During this period, there is no mobility based on WTRU, which is based on a timer or other criterion (such as counting) (T1).

[0011] The second phase begins with the detection of a handover failure, which generates RRC_IDLE. WTRU-based mobility is still available based on the Timer (T2).

[0012] Table 2 describes how mobility is handled with respect to a handover failure.

Table 2

Handover and Mobility Failure

<td>Cases</td><td>First phase</td><td>Second level</td><td>T2 expired</td>

Petition 870190112801, of 11/04/2019, p. 16/36

3/15

<td>EU enters target cell</td><td>It continues as if there were no radio problems</td><td>The activity can be resumed without interaction between the UE and eNode B, the UE performs a random access procedure according to 10.1.5.</td><td>Go via RRC_IDLE</td>

<td>UE returns to source cell</td><td>AT</td><td>The activity cannot be resumed without interaction between the UE and eNode B, the UE performs the Random Access Procedure in accordance with 10.1.5</td><td>Go via RRC_IDLE</td>

<td>EU selects a cell other than target cell or source</td><td>AT</td><td>Go via RRC_IDLE</td><td>Go via RRC_IDLE</td>

[0013] In addition, the use of random access not based on contention during the handover is currently allowed. Thus, the random access procedure not based on current contention, shown in figure 3, includes the assignment of a Preamble of Random Access by means of dedicated signaling on the lower link (DL), in which eNode B assigns a WTRU a Preamble of Random Access without contention with 6 (six) bits (that is, a Preamble of Random Access that is not within the set transmitted in BCH). The preamble is signaled by means of a handover command (HO) generated by a target eNode B and sent by the source eNode B to the handover, using media access control (MAC) signaling (such as layer 1 control channel) (L1) / layer 2 (L2) or MAC control packet data unit (PDU)) in case of DL data arrival.

[0014] The WTRU then transmits the Preamble of Random Access without contention assigned in the RACH on the upper link. An eNB Random Access Response is sent over DL-SCH. The response is almost synchronous (in a flexible window whose size is one or more transmission time intervals (TTI)) with message 1 and is addressed to C-RNTI or RA-RNTI (FFS) in control channel L1 / L2 .

Petition 870190112801, of 11/04/2019, p. 17/36

4/15

[0015] The WTRU then transmits the Preamble of Random Access without contention assigned in RACH on the top link. An eNB Random Access Response is sent on the DL-SCH. The response is almost synchronous (within a flexible window whose size is one or more transmission time intervals (TTI)) with message 1 and is addressed to C-RNTI or RA-RNTI (FFS) on the control channel L1 / L2.

[0016] The Random Access Response includes at least time alignment information, an initial UL grant for the handover and time alignment information for arrival of DL data. In addition, the RA preamble identifier is assigned to the temporary routing area radio network identifier (RA-RNTI) on the L1 / L2 control channel.

[0017] The response is intended for only one WTRU in a lower link shared channel message (DL-SCH) if it is addressed to the cell's RNTI (C-RNTI) on the L1 / L2 control channel or one or more WTRUs in a DL-SCH message if addressed to RA-RNTI on the L1 / L2 control channel.

[0018] There is a need for an improved method and apparatus for handling handover failures and radio links.

SUMMARY OF THE INVENTION

[0019] The method and apparatus described are used to handle handover and RL failures based on details of context transfer and RACH procedures that improve handover failure procedures. After an RL failure, a wireless transmission and reception unit (WTRU) includes the identity of an evolved Node B (eNB) and / or cell as an information element (IE) in an RRC connection request and / or a cell update message or any other RRC message along with a WTRU identity.

BRIEF DESCRIPTION OF THE FIGURES

[0020] A more detailed understanding can be obtained from the following description, provided as an example in conjunction with the attached figures, in which:

figure 1 shows a conventional radio link failure;

figure 2 shows a conventional handover failure;

- figure 3 shows a random access procedure not based on contention

Petition 870190112801, of 11/04/2019, p. 18/36

Conventional 5/15;

figure 4 is a diagram of the wireless communication system; and

- figure 5 shows a flow chart of a described method of handling a radio link failure.

DETAILED DESCRIPTION

[0021] When indicated below, the terminology wireless transmission and reception unit (WTRU) includes, but is not limited to, user equipment (UE), mobile station, fixed or mobile subscriber unit, pager, cell phone , personal digital assistant (PDA), computer or any other type of user device capable of operating in a wireless environment. When indicated below, the base station terminology includes, but is not limited to, a Node B, location controller, access point (AP) or any other type of interface device capable of operating in a wireless environment.

[0022] With reference to figure 4, an LTE wireless communication network (NW), for example, comprises one or more WTRUs 20, each of which includes a processor 21, one or more Nodes B 30, in which each includes a processor 31, and one or more cells 40. Each cell 40 comprises one or more B Nodes (NB or eNB) 30. Each of processors 21 and 31 is configured to implement a described method of handling a handover failure and radio link (RL).

[0023] Throughout the method described, context information designates any one of the Radio Resource Control (RRC) contexts, security contexts, Packet Data Convergence Protocol (PDCP) contexts or any context of layer that can proceed during mobility. For the sake of brevity, however, the expression context or context of RRC can be used for each of the types of context described above.

[0024] When an RL failure is detected by WTRU 20, WTRU 20 initiates mobility procedures (ie, new cell selection). In the normal cell selection procedure, the WTRU 20 reselects any available cell after the RL failure and, through a cell update or request for a radio resource control (RRC) connection, the WTRU 20 sends its identity of WTRU to an eNode B (eNB) 30. ENB 30, using the received WTRU identity, detects whether WTRU 20

Petition 870190112801, of 11/04/2019, p. 19/36

6/15 was under the control of this eNB 30 before the radio link failure occurred.

[0025] A method and apparatus are described in which, after a handover failure (HO) or radio link (RL), the WTRU 20 includes its WTRU identity (such as TMSI / IMSI / IMEI or any other identity of UE) and the eNB identity and / or cellular identity as an information element (IE) in the RRC connection request, the cellular update message or any other RRC message.

[0026] After the WTRU 20 takes shelter over an eNB (that is, target eNB) after the new cell selection, the information included in the IE is transmitted to the target eNB. If the target eNB in ​​which the WTRU 20 is housed is different from the eNB for which the WTRU 20 was housed before the RL failure (ie source eNB), the target eNB contacts the source eNB, using the eNB identity and / or cell ID included in IE, to inform the source eNB of the identity of the WTRU 20. The target eNB then requests the source eNB to transmit context parameters from WTRU 20. Alternatively, the target eNB can also inform the source eNB of the cellular identity.

[0027] If the source eNB finds context information that matches the identity of the WTRU 20, the source eNB transmits the context information to the target eNB. The target eNB can then send a response to the cellular update of the WTRU 20, the RRC connection request or any other RRC procedure initiated by WTRU, which indicates that the WTRU 20 can reuse the previous context.

[0028] If the context is not found by the source eNB, the target eNB performs procedures for cell update / establishment of RRC connections or any other RRC procedure. In this case, when the target eNB receives a request to reestablish an RRC connection via WTRU 20, it signals all the parameters of Layer 1 and / or Layer 2/3 that would have signaled for a new RRC connection. The WTRU 20 can then delete any stored context information that was applicable to the old cell. Alternatively, if the context is not found, WTRU 20 can enter as RRC Idle without waiting for timer T2 to end and resume procedures or wait for timer t2 to end in RRC Idle.

[0029] The described IE, which includes information about the eNB in ​​which WTRU 20 was last housed, can be included by WTRU 20. According to this alternative, the

Petition 870190112801, of 11/04/2019, p. 20/36

715 processor 21 includes the eNB identity and / or cellular identity in IE only upon detection of a handover failure.

[0030] If the target eNB, in which the WTRU 20 is housed, is the same source eNB before the failure and if the eNB finds a context for the WTRU 20 (eNB finds out by verifying that it has a context that matches the identity WTRU 20), eNB, upon receipt of a WTRU 20 RRC CONNECTION REQUEST (or upon receipt of any other RRC procedure initiated by WTRU), you can tell WTRU 20 to use the same context information you had before the failure occurred. Otherwise, eNB will be able to signal all Layer 1 and Layer 2/3 parameters to WTRU 20 that eNB would signal for a new RRC connection. The WTRU 20 can then delete any stored context information.

[0031] A flow chart of the described method used by processor 21 of WTRU 20 to handle an RL failure is described below. Upon detection of an RL failure (step 500), WTRU 20 conducts an initial access procedure to obtain access to a selected target eNB (step 501). The WTRU 20 then transmits an IE to the target eNB that includes at least the eNB ID for a source eNB on which the WTRU 20 was previously housed (step 502). The WTRU 20 then receives the RRC context of the target eNB (step 503) after obtaining the context by the target eNB, such as from the source eNB.

[0032] According to the method described, the length of the period in which the target eNB maintains the context of radio access control (RAC) is preferably determined based on implementation. This is also the case in determining whether the transfer of context information between the target eNB and the source eNB occurs only on a radio link failure.

[0033] If the target eNB in ​​which the WTRU 20 is housed is the same source eNB in ​​which the WTRU 20 had taken shelter before the handover, upon receipt of a WTRU 20 RRC CONNECTION REQUEST or receipt of any another RRC procedure initiated by the WTRU, may indicate to the WTRU 20 that it uses the same context information that it had before the failure occurred.

Petition 870190112801, of 11/04/2019, p. 21/36

8/15

[0034] As the technicians in the subject will understand, the shelter of WTRU 20 in the same cell or the same eNB in ​​which it had sheltered before the RL failure helps to save network resources. Thus, the described method may alternatively include that the WTRU 20 during the cell selection procedure after the RL failure considers the identity of the source eNB, in order to prefer cells of the source eNB over cells of a different eNB. According to this alternative, it may be preferable for WTRU 20 to give priority to an eNB detected in the following order: the last cell in which it was previously housed; a cell of the same eNode B in which it was previously housed; and the cell of any other eNode B.

[0035] The other parameters of new cell selection may or may not be considered by WTRU 20 during a radio link failure situation, as the quick shelter and start of the call are the main criteria after the failure; having only the eNB identity (or cell identity), together with the cell's signal strength, is sufficient to conduct cell selection through radio link failure. According to this method, the identities (eNB and cell) can be transmitted in the system information messages together with the cell ID.

[0036] For a handover failure, a method is described in which, when the WTRU 20 moves to a different cell and the different cell belongs to the same eNB, based on the identity of the WTRU 20, the eNB for which the WTRU 20 moved identifies if it has the context of WTRU 20. If eNB has the context, eNB signals to WTRU 20 that it uses the same context as above. The WTRU 20 is capable of using the same context, since the context is stored with respect to eNB and not with respect to the cell. According to this method, the same cell selection priority described above for an RL failure described above applies to eNB handover failures, as an alternative method.

[0037] When the WTRU 20 moves to a cell of a different eNB, a procedure similar to that described above can be used for a radio link failure. It should be noted that, during this handover procedure, the last eNB identity that the WTRU 20 may have stored may be the source eNB or the target eNB, depending on which stage of the handover procedure has failed. According to this

Petition 870190112801, of 11/04/2019, p. 22/36

9/15 described method, it is preferable that the WTRU 20 stores the source eNB as the last eNB in ​​which it was housed until the successful end of the handover. In addition, the procedure itself would not be affected, regardless of whether the WTRU sends the identity of the source eNB or target eNB to the final eNB in ​​which it is housed.

[0038] An important aspect of being able to recover the context is that the WTRU shelters in a cell and sends message 1 (that is, the Preamble of Random Access) in the RACH procedure as soon as possible. If there is a delay in this process, eNB may have excluded the context, in order to render the context recovery procedure useless. Consequently, a method of improving the Random Access Channel (RACH) procedure for handover and RL failures is described. According to this method, a dedicated subscription is allocated to WTRU 20 during the handover procedure. The allocated dedicated signature is then used to access the source cell after an RL or handover failure. The HO command, for example (or any signaling message), assigns WTRU 20 two dedicated signatures, one to be used by WTRU 20 to access the target cell and the other to be used by WTRU 20 to access the source cell (or any other cell) in case of failure (such as if WTRU 20 does not manage access to the target cell).

[0039] If the handover is successfully terminated, WTRU 20 may (implicitly or explicitly) release the signature back to the network in the handover confirmation message. In the event of a failure during the handover procedure, the WTRU 20 can use this second dedicated subscription and try to access the network as soon as possible. As the WTRU 20 uses a dedicated signature, it is able to recover more quickly from a failure.

[0040] Alternatively, a set of dedicated signatures is transmitted on the broadcast channel (BCH) defined exclusively for RL failure, which is used by WTRU 20 in the event of a handover or RL failure. In another alternative, a set of dedicated universal signatures, valid across all cells, can be used for RL failures. This set of dedicated universal signatures can be sent in the handover message or transmitted in the system information messages. The WTRU can then use that universal dedicated subscription after the failure to

Petition 870190112801, of 11/04/2019, p. 23/36

10/15 access to any cell.

[0041] An alternative RACH procedure is described in which, instead of assigning a dedicated signature to WTRU 20, which is used in the event of failure, at least one of the signatures (such as Preamble of Random Access) in the current set transmitted on BCH can be identified / reserved for access to the cell after the failure. According to this alternative, the WTRU 20 obtains the reserved signatures from the BCH (or the Handover Command (HO) can inform the WTRU 20 of the reserved signatures to be used in case of failure). After the WTRU 20 learns the reserved signatures, the WTRU 20 uses this reserved sign if it experiences a handover or RL failure.

[0042] Another alternative is described in which higher access classes are used to handle RL failures. According to this alternative, WTRU 20 associates the handling of RL failures with a higher class service and, in this way, it would end up selecting again for the network with a lower setback and higher priority. In this scenario, when WTRU 20 attempts to access a cell after an RL failure, as WTRU 20 would have a higher access class service, and therefore would attempt to access network 10 with less or no backward interval between their different attempts at RACH. In this way, WTRU 20 after an RL failure may have a higher probability of accessing the network compared to other WTRUs with lower service and access class, which would generate longer backward intervals.

[0043] In another alternative method of accessing RACH, the WTRU 20 raises its power more quickly so that the network has a higher possibility of detection and, therefore, prioritizes the given WTRU 20. Table 3 describes the mobility of the WTRU 20 during an RL failure according to this method described.

Table 3

Mobility and Failure of Radio Links

<td>Cases</td><td>First phase</td><td>Second level</td><td>T2 expired</td><td>Cell selection priority</td>

<td>EU returns to the same</td><td>Continue as if not</td><td>The activity cannot be resumed without</td><td>Go via RRC_IDLE</td><td> 1</td>

Petition 870190112801, of 11/04/2019, p. 24/36

11/15

<td>cell</td><td>radio problems had occurred</td><td>interaction between WTRU and eNode B, the procedure to be used is FFS, usually not through RRC_IDLE</td><td></td><td></td>

<td>EU selects a different cell from the same eNode B</td><td>AT</td><td>The activity cannot be resumed without interaction between the WTRU and eNode B.</td><td>Go via RRC_IDLE</td><td> 2</td>

<td>EU selects a cell from a different eNode B</td><td>AT</td><td>The activity cannot be resumed without interaction between the WTRU and eNode B, the procedure to be used is FFS, normally not via RRC_IDLE</td><td>Go via RRC_IDLE</td><td> 3</td>

[0044] For the second phase, in order to resume activity when WTRU 20 returns to the same cell, or when WTRU 20 selects a different cell from the same eNode B or a different eNB, a method is described in which the WTRU 20 has access to the cell through the random access procedure. The non-access layer identity (NAS) used in the random access process is also used by eNB to determine if eNB has a stored RRC context for that WTRU 20. If eNB finds a RRC context that matches the identity of the WTRU 20, eNB sends, in response to the RRC CONNECTION REQUEST, a message (such as RRC CONNECTION RESPONSE) or any other RC procedure initiated by the WTRU , which tells WTRU 20 to reuse the RRC context it has stored.

[0045] If the eNB does not find a RRC context that matches the identity of the WTRU 20, the new eNB comes into direct contact with the previously housed eNB using the eNB identity transmitted by WTRU 20. As described above, alternatively, the eNB can derive the WTRU identity or the WTRU context from

Petition 870190112801, of 11/04/2019, p. 25/36

12/15

Mobile Administration Entity (MME).

[0046] If a context is found and transferred in the old eNB, it sends, in response to the RRC CONNECTION REQUEST, a message (such as RRC CONNECTION RESPONSE) or any other RRC procedure initiated by the WTRU that indicates to the WTRU 20 that reuses the RRC context it has stored. If the context is not found in the new or old eNB, an RRC connection establishment procedure takes place and WTRU 20 discards the RRC contexts it has stored. In this case, when the network sends a response to the RRC procedure initiated by the WTRU, network 20 indicates whether WTRU 20 can establish the stack using the old context information it had before the failure or network 10 transmits new parameters in the message. response for the WTRU 20 to configure your battery. After the WTRU 20 receives the reply message from the network 10 and processes it, the WTRU 20 transmits a complete message to the network 10 which indicates to the network 10 that it has finished the configuration on its side.

[0047] Table 4 below describes the mobility of the WTRU 20 during a handover failure according to the method described.

Table 4

Handover and Mobility Failure

<td>Cases</td><td>First phase</td><td>Second level</td><td>T2 expired</td><td>Cell selection priority</td>

<td>EU enters target cell</td><td>Continue as if there were no radio problems</td><td>The activity cannot be resumed without interaction between the UE and eNode B</td><td>Go via RRC_IDLE</td><td> 1</td>

<td>UE returns to the source cell</td><td>AT</td><td>The activity cannot be resumed without interaction between EU and eNode B</td><td>Go via RRC_IDLE</td><td> 2</td>

<td>EU selects</td><td>AT</td><td>Activity cannot</td><td>Go via RRC_IDLE</td><td> 3</td>

Petition 870190112801, of 11/04/2019, p. 26/36

13/15

<td>a different cell of the same eNode B</td><td></td><td>be summarized without interaction between UE and eNode B, the procedure to be used is FFS, normally not via RRC_IDLE</td><td></td><td></td>

<td>EU selects a cell from a different eNode B</td><td>AT</td><td>The activity cannot be resumed without interaction between the UE and the eNode b, the procedure to be used is FFS, normally not via RRC_IDLE</td><td>go via RRC_IDLE</td><td> 4</td>

[0048] For the second phase, in order to resume the activity when the WTRU 20 returns to the same cell or when the WTRU 20 selects a different cell from the same eNB or a different eNB, a method in which the WTRU 20 has cell access through the random access procedure. The non-access layer identity (NAS) used in the random access procedure is also used by eNB to determine whether eNB has a stored RRC context for WTRU 20. If eNB finds a stored RRC context for WTRU 20. If eNB finds a RRC context that matches the identity of WTRU 20, eNB sends a message in response to the RRC CONNECTION REQUEST (such as CONNECTION RESPONSE RRC) or any other RRC procedure initiated by WTRU that tells WTRU 20 to reuse the RRC context it has stored.

[0049] If the eNB does not find a RRC context that matches the identity of the WTRU 20, the new eNB comes in direct contact with the previously housed eNB using the eNB identity transmitted by WTRU 20. As described above, alternatively, the eNB can derive the WTRU identity or the WTRU context from the MME.

[0050] If a context is found and transferred in the old eNB, it sends in

Petition 870190112801, of 11/04/2019, p. 27/36

14/15 response to the RRC CONNECTION REQUEST a message (such as RRC CONNECTION RESPONSE) or any other RRC procedure initiated by the WTRU, which tells WTRU 20 to reuse the RRC context it has stored. If the context is not found in the new or old eNB, there is a procedure for establishing a normal RRC connection and the WTRU 20 preferably discards the RRC contexts it has stored. It should be noted that the use of the cell selection priority column in Tables 3 and 4 is an alternative method and that, regardless of the priority, the procedure described is still applicable if other selection and new selection priorities are used.

[0051] Although the characteristics and elements are described above in specific combinations, each characteristic or element can be used alone, without the other characteristics and elements or in various combinations with or without the other characteristics and elements. The methods or flowcharts provided herein may be implemented in a computer program, software or firmware embedded in computer-readable storage media for execution by a general purpose computer or processor. Examples of computer-readable storage media include read-only memory (ROM), random access memory (RAM), registry, cache memory, semiconductor memory devices, magnetic media such as internal hard drives and removable disks, magnetic media optical and optical media such as CD-ROM discs and digital versatile discs (DVDs).

[0052] Suitable processors include, for example, a general purpose processor, special purpose processor, conventional processor, digital signal processor (DSP), a series of microprocessors, one or more microprocessors in association with a DSP core, controller , microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Portal Sets (FPGAs) circuits, any other type of integrated circuit (IC) and / or state machine.

[0053] A processor in association with software can be used to implement a radio frequency transceiver for use in a wireless transmission and reception unit (WTRU), user equipment (UE), terminal, base station, network controller, radio (RNC) or any host computer. The WTRU can be

Petition 870190112801, of 11/04/2019, p. 28/36

15/15 used in conjunction with modules, implemented in hardware and / or software, such as a camera, video camera module, videophone, headset, vibration device, speaker, microphone, television transceiver, headset handsfree ear, keyboard, Bluetooth® module, frequency modulated radio (FM) unit, liquid crystal display unit (LCD), organic light-emitting diode (OLED) unit, digital music device, device from media, video game module, Internet browser and / or any wireless local area network (WLAN) or Ultra Wide Band (UWB) module.