Handling radio link failure and handover failure

The present invention relates to a wireless communication system.

In the Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Stage 2, the radio transmit / receive unit (WTRU) selects cells that belong to the same eNodeB after the radio link (RL) failure is listed as a For Further Study (FFS). .. It has been proposed that if the WTRU selects different cells from the same eNodeB, the activity cannot be resumed without the interaction between the WTRU and the eNodeB. Currently, Radio Access Network 2 (RAN2) specifies that when a WTRU selects a cell from a different eNodeB, the WTRU must proceed via a radio resource control (RRC) idle.

Currently, RAN2 decisions regarding RL disorders are based on two phases. These two phases determine the behavior associated with RL failure and are shown in Figure 1.

The first phase begins when a radio problem is detected, which leads to RL failure detection. As a result, there is no WTRU-based mobility based on timers or other (eg counting) criteria (T1).

The second phase begins when a radio link failure is detected, which leads to an RRC Idle. WTRU-based mobility is still available, and this mobility is timer-based (T2).

Table 1 below shows how mobility is currently handled for RL failures.

<tables num="1"><img file="JP2013059121A_D0001.tif" /></tables>

Recent proposals divide the handover into two phases similar to RL failures, and propose similar handover failure handling procedures.

In the first phase, the WTRU attempts to synchronize and access the target cell, for example during timer T1. In the second phase, the WTRU terminates the handover due to a failure and attempts to reestablish the lost connection to the network, for example during timer T2. After the second phase, the UE enters RRC_IDLE.

Figure 2 shows two phases that determine the behavior associated with handover failures during mobility controlled by the network according to the current proposal.

The first phase begins at the time of the first synchronization attempt to the target cell and leads to handover failure detection. During this time, there is no WTRU-based mobility, and this WTRU-based mobility is based on timers or other (eg, counting) criteria (T1).

The second phase begins at the time of the handover failure detection, and this handover failure detection leads to RRC_IDLE. WTRU-based mobility is still available based on the timer (T2).

Table 2 shows how mobility is handled with respect to handover failures.

<tables num="2"><img file="JP2013059121A_D0002.tif" /></tables>

Also, non-conflict-based random access during handover can now be used. Therefore, the current non-conflict-based random access procedure shown in Figure 3 involves the allocation of random access preambles via dedicated signaling on the downlink (DL), where the eNodeB is 6-bit non-conflicting with the WTRU. Assign a random access preamble (ie, a random access preamble not included in the set broadcast on BCH). This preamble uses media access control (MAC) signaling (for example, Layer 1 (L1) / Layer 2 (L2) control channels or MAC control packet data units (PDUs)) in case of DL data arrival. It is signaled via a handover (HO) command generated by the target eNodeB and transmitted from the source eNodeB for handover.

The WTRU then sends a non-competitive random access preamble assigned by the uplink RACH. The random access response from eNB is sent on DL-SHC. The response is semi-synchronous for message 1 (in a flexible window whose size is one or more transmission timing intervals (TTIs)) and is C-RNTI or RA-RNTI (FFS) on the L1 / L2 control channel. ) Is addressed.

The random access response includes at least timing alignment information and initial UL authorization for handover and timing alignment information for DL data arrival. In addition, the RA preamble identifier is addressed to the Routing Area Radio Network Temporary Identifier (RA-RNTI) on the L1 / L2 control channel.

This response is addressed to only one WTRU in one downlink shared channel (DL-SCH) message when addressed to cell RNTI (C-RNTI) on the L1 / L2 control channel, L1 / L2. When addressed to RA-RNTI on the control channel, it is addressed to one or more WTRUs in a DL-SCH message.

<p> There is a need for improved methods and equipment to handle radio link failures and handover failures.</p>

<p> The disclosed methods and devices are used to handle RL and handover failures based on context transfer details and RACH procedures that enhance the failure handling procedure. After an RL failure, the radio transmit / receive unit (WTRU), along with the WTRU identity, evolved Node-B (eNB) and / or the cell as an information element (IE) for RRC connection requests and / or cell update messages or other RRC messages. Including identity.</p><p> A more detailed understanding can be obtained from the following description given as an example along with the accompanying drawings.</p>

<figref num="1">It is a figure which shows the conventional wireless link failure.</figref><figref num="2">It is a figure which shows the conventional handover failure.</figref><figref num="3">It is a figure which shows the conventional non-competition-based random access procedure.</figref><figref num="4">It is a figure which shows the wireless communication system.</figref><figref num="5">It is a flow chart which shows the disclosed method of handling a wireless link failure.</figref>

When referred to below, the term "wireless transmit / receive unit (WTRU)" refers to user equipment (UE), mobile stations, fixed or mobile subscriber units, pagers, cell phones, personal digital assistants (PDAs), computers, Or any other type of user device that can operate in a wireless environment, but is not limited to these. When referred to below, the term "base station" includes, but is limited to, Node-B, site controllers, access points (APs), or any other type of interface device that can operate in a wireless environment. Not done.

Referring to FIG. 4, the LTE wireless communication network (NW) 10 is, for example, one or more WTRU 20 each containing a processor 21 and one or more Node B 30 each containing a processor 31 and 1 Includes one or more cells 40. Each cell 40 contains one or more Node B (NB or eNB) 30. Processors 21 and 31, respectively, are configured to implement the disclosed methods of handling radiolink (RL) failures and handover failures.

Throughout the methods disclosed, contextual information refers to any of the Radio Resource Control (RRC) contexts, security contexts, Packet Data Concentration Protocol (PDCP) contexts, or any layer of context that can be continued during mobility. However, for the sake of brevity, term contexts or RRC contexts can be used for each of the types of contexts disclosed above.

When the RL failure is detected by WTRU 20, WTRU 20 initiates a mobility procedure (ie, cell reselection). In a normal cell reselection procedure, WTRU 20 reselects to any available cell after an RL failure, and via cell update or radio resource control (RRC) connection request, WTRU 20 gives its WTRU identity. Send to eNodeB (eNB) 30. The eNB 30 uses the received WTRU identity to detect if the WTRU 20 was under the control of this eNB 30 before the radio link failure occurred.

After a wireless link (RL) or handover (HO) failure, the WTRU 20 has its WTRU identity (eg TMSI / IMSI) as an information element (IE) in an RRC connection request, cell update message, or any other RRC message. Disclose methods and devices that include / IMEI or any other UE identity) as well as eNB identities and / or cell identities.

After the WTRU 20 camps on the eNB (ie, the target eNB) after cell reselection, the information contained in IE is sent to the target eNB. If the target eNB that WTRU 20 camps on is different from the eNB that WTRU 20 camps on before the RL failure (ie, the source eNB), then the target eNB is the eNB identity and / or cell ID contained in IE. Use to contact the source eNB to inform the source eNB about the identity of WTRU 20. The target eNB then requests the source eNB to send the context parameters for WTRU 20. In the alternative, the target eNB can also inform the source eNB about the cell identity.

If the source eNB finds contextual information that matches the identity of WTRU 20, the source eNB sends that contextual information to the target eNB. The target eNB can send a cell update for WTRU 20, an RRC connection request, or a response to an RRC procedure initiated by any other WTRU, indicating that WTRU 20 can reuse the previous context.

If the context is not found by the source eNB, the target eNB executes the cell update / RRC connection establishment procedure or any other RRC procedure. In this case, when the target eNB receives a request from WTRU 20 to reestablish the RRC connection, the target eNB signals all of the Layer 1 and Layer 2/3 parameters because it has signaled for the new RRC connection. The WTRU 20 can then remove all stored contextual information that was applicable to the old cell. Alternatively, if no context is found, WTRU 20 goes to RRC Idle without waiting for timer T2 to expire and resumes the procedure or waits for timer T2 to expire before proceeding to RRC Idle. Can be done.

The IE disclosed contains information about the eNB that WTRU 20 last camp on, but may be included by WTRU 20. According to this alternative, processor 21 includes an eNB identity and / or a cell identity in IE only when it detects a handover failure .

The target eNB that WTRU 20 camps on is the same as the source eNB before the failure, and the eNB finds the context of WTRU 20 (it by checking if the eNB has a context that matches the identity of WTRU 20). If the eNB receives an RRC CONNECTION REQUEST from WTRU 20 (or receives an RRC procedure initiated by any other WTRU), before WTRU 20 fails. You can instruct them to use the same context information that the WTRU had. Otherwise, the eNB can signal all Layer 1 and Layer 2/3 parameters to WTRU 20 as the eNB signals a new RRC connection. The WTRU 20 can then delete all stored contextual information.

A flow diagram of the disclosed method used by processor 21 of WTRU 20 to handle RL failures is described below. Upon detection of an RL failure (step 500), WTRU 20 performs an initial access procedure to gain access to the selected target eNB (step 501). The WTRU 20 then sends an IE containing at least the eNB ID of the source eNB that the WTRU 20 previously camped to the target eNB (step 502). The WTRU 20 then receives the RRC context from the target eNB after the context is obtained by the target eNB, for example, from the source eNB (step 503).

According to the disclosed method, the duration of the period during which the target eNB maintains a radio access control (RAC) context is preferably determined on an implementation basis. This also applies to determining whether the transfer of contextual information between the target eNB and the source eNB occurs only in the event of a wireless link failure.

Started when receiving an RRC CONNECTION REQUEST from WTRU 20 or by any other WTRU if the target eNB that WTRU 20 is camping on is the same as the source eNB that WTRU 20 was camping on before the handover. Upon receipt of the RRC procedure, WTRU 20 can be instructed to use the same context information that WTRU 20 had before the failure occurred.

Those skilled in the art should recognize that WTRU 20 camping in the same cell or eNB that was camping prior to the RL failure will help save network resources. Therefore, the disclosed method is an alternative, in which WTRU 20 takes into account the source eNB identity during the cell selection procedure after an RL failure, thereby allowing cells from the source eNB to cells from other eNBs. It can include giving priority. According to this alternative, the WTRU 20 has the last cell it was camping on, the cell from the same eNodeB it was camping on, and all the other cells from eNodeB. In order, it may be preferable to prioritize the detected eNBs.

Other parameters for cell reselection may or may not be considered by WTRU 20 during a radio link failure situation. This is because quick camp and call initiation are the main criteria after a failure, and having only the eNB identity (or cell identity) along with the cell signal strength makes cell selection in the event of a wireless link failure. Because it is enough. According to this method, the identity (eNB and cell) can be broadcast in the system information message along with the cell ID.

For a handover failure, when WTRU 20 moves to a different cell and the different cells belong to the same eNB, the eNB moved by WTRU 20 identifies whether it has a WTRU 20 context based on the WTRU 20 identity. Disclose the method. If the eNB has a context, the eNB signals WTRU 20 to use the same context as before. WTRU 20 can use the same context because the context is stored for the eNB rather than for the cell. According to this method, the same priorities as the cell selection described above for the RL failure disclosed above apply to the eNB handover failure as an alternative method.

When the WTRU 20 moves to a cell from a completely different eNB, a procedure similar to that disclosed above for radio link failure can be used. During such a handover procedure, the last eNB identity that the WTRU 20 can store may be the source eNB or the target eNB, depending on at what stage of the procedure the handover failed. Please note that there is. According to this disclosed method, the WTRU 20 preferably stores the source eNB as the last eNB it camps on until the handover is successful and complete. Also, the procedure itself is unaffected regardless of whether the WTRU sends the identity of the source eNB or the target eNB to the last eNB it camps on.

An important aspect of being able to retrieve content is for the WTRU to camp in a cell and send message 1 (ie, a random access preamble) in a RACH procedure as soon as possible. If there is a delay in this process, the eNB may finish removing the context and thus render the context retrieval procedure useless. Therefore, a method of enhancing the random access channel (RACH) procedure is disclosed for RL failures and handover failures. According to this method, a dedicated signature is assigned to WTRU 20 during the handover procedure. The assigned dedicated signature is then used to access the source cell after an RL or handover failure. For example, the HO command (or any signaling message) is used by WTRU 20 to access the target cell in the event of a failure (for example, if WTRU 20 could not access the target cell). The other is a WTRU to access the source cell (or any other cell) Assign two dedicated signatures used by 20 to WTRU 20.

If the handover is successful and complete, WTRU 20 returns to the network (implicitly or explicitly) in the handover confirmation message to release the signature. In the event of a failure during the handover procedure, the WTRU 20 can use this second dedicated signature to attempt to access the network as soon as possible. The WTRU 20 uses a dedicated signature so you can recover more quickly from a failure.

In the alternative, a set of dedicated signatures is broadcast within a broadcast channel (BCH) set exclusively for RL failures, which is used by WTRU 20 in the event of an RL failure or handover failure. Another alternative is to use a set of universal signatures that are valid across all cells for RL failures. This set of universal signatures can be sent in a handover message or broadcast in a system information message. The WTRU can then use this universal signature after a failure to access any cell.

An alternative RACH procedure is disclosed, which does not assign the WTRU 20 a dedicated signature to be used in case of failure, but at least one of the signatures in the current set broadcast over BCH ( For example, a random access preamble) can be identified / reserved for cell access after a failure. According to this alternative, WTRU 20 gets a reserved signature from BCH (or a handover (HO) command can tell WTRU 20 about a reserved signature to use in the event of a failure). .. The WTRU 20 uses this reserved signature if it experiences an RL or handover failure after knowing the reserved signature.

Disclose another alternative that uses a higher access class for RL fault handling. According to this alternative, WTRU 20 associates RL fault handling with higher access class services, thus ending with reselection to networks with less backoff and higher priority. In this scenario, when WTRU 20 attempts to access a cell after an RL failure, WTRU 20 has a higher access class service and therefore has less backoff interval or back between its different RACH attempts. Attempts to access network 10 without an off-interval. Therefore, the WTRU 20 can have a higher probability of accessing the network after an RL failure compared to other WTRUs (having a longer backoff interval) with lower access class services.

In another alternative for RACH access, the WTRU 20 ramps up its output more quickly, and as a result, the network has a higher chance of detecting that WTRU and therefore prioritizes a given WTRU 20. To give. Table 3 shows the mobility of WTRU 20 during RL failure with this disclosed method.

<tables num="3"><img file="JP2013059121A_D0003.tif" /></tables>

For the second phase, WTRU 20 accesses the cell via a random access procedure to resume activity when WTRU 20 returns to the same cell or when WTRU 20 selects a different cell or different eNB from the same eNodeB. Disclose the method. The non-access stratum (NAS) identity used in the random access procedure is also used by the eNB to determine if the eNB has an RRC context stored for its WTRU 20. If the eNB finds an RRC context that matches the identity of WTRU 20, the eNB responds to the RRC CONNECTION REQUEST with a message (eg, RRC CONNECTION RESPONSE) or an RRC procedure initiated by any other WTRU. Instruct WTRU 20 to send and reuse the RRC context it stores.

If the eNB does not find an RRC context that matches the identity of the WTRU 20, the new eNB will contact the previously camped eNB directly using the eNB identity sent by the WTRU 20. As disclosed above, in the alternative, the eNB can derive the WTRU identity or WTRU context from the Mobile Management Entity (MME).

If the context is found and transferred within the old eNB, the old eNB sends a message (for example, RRC CONNECTION RESPONSE) or an RRC procedure initiated by any other WTRU in response to the RRC CONNECTION REQUEST. , Tells WTRU 20 to reuse the RRC context it stores. If the context is not found in either the new eNB or the old eNB, an RRC connection establishment procedure is performed and WTRU 20 destroys the RRC context it contains. In this case, when the network sends a response to the RRC procedure initiated by WTRU 20, network 10 can set up the stack using the old contextual information that WTRU 20 stored before the failure. Alternatively, network 10 sends a new parameter in the response message for WTRU 20 to set up its stack. After WTRU 20 receives and processes the response message from network 10, WTRU 20 20 sends a completion message to network 10 indicating to network 10 that it has completed the configuration on the WTRU 20 side.

Table 4 below shows the mobility of the WTRU 20 during a handover failure by the disclosed method.

<tables num="4"><img file="JP2013059121A_D0004.tif" /></tables>

For the second phase, WTRU 20 accesses the cell via a random access procedure to resume activity when WTRU 20 returns to the same cell or when WTRU 20 selects a different cell or different eNB from the same eNB. Disclose the method. The non-access stratum (NAS) identity used in the random access procedure is also used by the eNB to determine if the eNB has an RRC context stored for its WTRU 20. If the eNB finds an RRC context that matches the identity of WTRU 20, the eNB responds to the RRC CONNECTION REQUEST with a message (eg, RRC CONNECTION RESPONSE) or an RRC procedure initiated by any other WTRU. Instruct WTRU 20 to send and reuse the RRC context it stores.

If the eNB does not find an RRC context that matches the identity of WTRU 20, the new eNB will contact the previously camped eNB directly using the eNB identity sent by WTRU 20. As disclosed above, in the alternative, the eNB can derive the WTRU identity or WTRU context from the MME.

If the context is found and transferred within the old eNB, the old eNB sends a message (for example, RRC CONNECTION RESPONSE) or an RRC procedure initiated by any other WTRU in response to the RRC CONNECTION REQUEST. , Tells WTRU 20 to reuse the RRC context it stores. If the context is not found in either the new eNB or the old eNB, the normal RRC connection establishment procedure is performed and WTRU 20 preferably destroys the RRC context it contains. The use of cell selection priority columns in Tables 3 and 4 is an alternative, regardless of priority, if the disclosed procedure still uses other cell selection / reselection priorities. Note that it is applicable.

Embodiment 1. A method of wireless communication carried out by a wireless transmission / reception unit (WTRU). To detect failures that include at least one of a wireless link (RL) failure and a handover (HO) failure, Sending a radio transmit / receive unit (WTRU) identity and an information element (IE) containing at least one of the source Node B identity and the source cell identity to access the target node. Receiving contextual information from target Node B, at least partially based on IE A method characterized by including. 2. The method according to embodiment 1, further comprising performing cell reselection to select an available target Node B. 3. The method described in any of the previous embodiments, wherein the source Node B identity is taken into account when selecting an available target Node B. 4. Reselecting is First try to reselect to source Node B, Source Node Attempting to go back and reselect the source cell associated with the source cell identity when B is unavailable The method according to any of the previous embodiments comprising. 5. The method according to embodiment 4, wherein the target Node B and the target cell are different from the source Node B and the source cell. 6. The method according to any of the previous embodiments, further comprising storing contextual information prior to the detected failure. 7. The method according to any one of embodiments 1 to 6, wherein the context information includes an instruction to use the stored context information. 8. The method according to any one of embodiments 1 to 6, wherein the context information includes context information different from the stored context information. 9. The method according to any of the previous embodiments, further comprising accessing the network using at least one of the use of a smaller backoff or a higher rampup of power. 10. Includes receiving at least one assigned dedicated signature during handover, which ensures that the dedicated signature is used to access the source cell after a radio link (RL) failure or handover failure. The method according to any of the previous embodiments, characterized by that. 11. The method of embodiment 10, wherein at least one dedicated signature is received via a handover command. 12. Further includes receiving a handover command containing two assigned dedicated signatures, one of which is used to access target Node B and the other of which is subject to RL or handover failure. The method according to embodiment 10, characterized in that it is used to access the source Node B in case. 13. The method of embodiment 12, further comprising releasing two dedicated signatures when the handover is complete. 14. At least one dedicated signature from the set of signatures is any Node after an RL or handover failure The method according to any of the previous embodiments, characterized in that it is reserved on a broadcast channel to access any cell from B. 15. The method of embodiment 14, wherein the set of signatures reserved for dedicated access is received within a handover command. 16. A wireless transmitter / receiver unit comprising a processor configured to perform the method described in any of the previous embodiments. 17. Node B, comprising a processor configured to perform the method described in any of the previous embodiments. 18. A processor characterized in that it is configured to perform the method described in any of the previous embodiments.

The features and elements have been described above in specific combinations, but each feature or element may be used alone without other features and elements or in various combinations with or without other features and elements. Can be done. The methods or flow diagrams provided herein can be implemented in computer programs, software, or firmware embedded in computer-readable storage media for execution by general purpose computers or processors. Examples of computer-readable storage media include read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, internal hard disks and magnetic media such as removable disks, optical magnetic media, and CD-ROM disks. And includes optical media such as digital versatile discs (DVDs).

Suitable processors are, for example, general purpose processors, special purpose processors, traditional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors associated with DSP cores, controllers, microcontrollers, and application specific integrated circuits. Includes application specific integrated circuits (ASICs), field programmable gate array (FPGA) circuits, any other type of integrated circuits (ICs), and / or state machines.

Use software-related processors to implement radio frequency transceivers, user equipment (UEs), terminals, base stations, wireless network controllers (RNCs), or any host computer used in wireless transceiver units (WTRUs). be able to. WTRU includes cameras, video camera modules, video phones, speakerphones, vibrating devices, speakers, microphones, television receivers, hands-free headsets, keyboards, Bluetooth® modules, frequency modulation (FM) radio units, LCDs. Display (LCD) display unit, organic light emitting diode (OLED) display unit, digital music player, media player, video game player module, internet browser, and / or any wireless local area network (WLAN) module or ultra wideband (UWB) ) Can be used with modules implemented in hardware and / or software, such as modules.