Invention titles: master node, secondary node, and methods thereof
Technical field
[0001]
This disclosure relates to a wireless communication system, and particularly to recovery from a failure of a master cell group (MCG) in multi-connectivity (e.g., Dual Connectivity).
Background technology
[0002]
The 3rd Generation Partnership Project (3GPP) discusses fast recovery of MCG failures when Multi-Radio Dual Connectivity (MR-DC) is being performed (eg, Non-Patent Document 1-). See 5). The MCG failure is, for example, Radio Link Failure (RLF). Fast MCG Recovery is a master node (MN) and User Equipment (UE) via the Secondary Cell Group (SCG) provided by the secondary node (SN) for recovery of MCG failure when MR-DC is performed. Utilize the transmission of signaling between. This allows Fast MCG Recovery to quickly recover the MCG link (or MCG failure) using other methods than the Radio Resource Control (RRC) connection re-establishment, such as the intra-MN handover procedure or the inter-MN handover procedure. Enables (recovery). In 5G NR, a procedure called Reconfiguration with sync is specified, which is used for handover and MR-DC PS Cell (Primary SCG Cell or Primary Secondary Cell) change and SN change. The intra-MN handover and the inter-MN handover in the present specification may include the SN release of the MR-DC within the handover procedure. The inter-MN handover in the present specification may include a role change between the MN and the SN. In the role change, the SN (and MN) of the MR-DC before the handover is the MR-DC in the handover procedure. MN (and SN) will be changed to.
[0003]
Signaling required for Fast MCG recovery (i.e., MN RRC messages) is transferred between MN and UE via the SCG leg or SRB3 of Split Signaling Bearer1 (SRB1). Split SRB1 is an SRB between MN and UE for RRC messages and includes a Radio Link Control (RLC) bearer in the MCG and an RLC bearer in the SCG. Split SRB1 supports transmission over MCG and SCG, allowing duplication of RRC Protocol Data Units (PDUs) generated by MN. However, since the MN RRC messages sent by Split SRB1 are protected by the MN security key, the SN cannot know the contents of the MN RRC messages and sends the MN RRC messages transparently to the UE. do. The RLC bearers in the MCG and SCG of the Split SRB are called the MCG leg (or MCG part) and SCG leg (or SCG part), respectively. SRB3, on the other hand, is a direct SRB between the SN and the UE and can be used by the SN to send SN RRC messages to the UE in DC in the SCG cell. Note that the Fast MCG recovery may be triggered (executed) only after the security of the Access Stratum (AS) layer has been activated and SRB2 and at least one DRB have been established.
Prior art literature
Non-patent literature
[0004]
Non-Patent Document 1: Ericsson: “Fast MCG recovery in MR-DC”, 3GPP TSG-RAN WG2 # 105 R2-1901414, February 2019
Non-Patent Document 2: Ericsson: “Fast MCG recovery in (NG) EN-DC”, 3GPP TSG-RAN WG2 # 105 R2-1901416, February 2019
Non-Patent Document 3: Qualcomm Incorporated: “Fast Recovery from MCG failure”, 3GPP TSG-RAN WG2 # 105 R2-1900113, February 2019
Non-Patent Document 4: Huawei, HiSilicon: “MCG failure recovery via split SRB1”, 3GPP TSG-RAN WG2 # 106 R2-1907493, May 2019
Non-Patent Document 5: Huawei, HiSilicon: “Discussion on MCG failure recovery via SRB3”, 3GPP TSG-RAN WG2 # 106 R2-1907497, May 2019
Outline of the invention
Problems to be solved by the invention
[0005]
The inventors examined fast MCG recovery and found various problems. For example, if the UE sends an MN RRC message (e.g., MCG Failure Information message) indicating an MCG failure to the MN via the SCG leg of split SRB1, the SN cannot know the content of the MN RRC message. That is, in the procedure for transmitting MCG failure information via split SRB1, the SN cannot know the occurrence of MCG failure. However, it may be useful for the SN to know the occurrence of MCG failure (or the execution of MCG recovery). For example, as mentioned above, in fast MCG recovery, signaling between MN and UE (MN RRC messages) is transferred via SN. Therefore, the SN needs to control (or adjust) the timing of modifying or releasing the settings or resources in the SN so as not to interfere with the transfer of the MN RRC message between the MN and the UE. might exist. For example, knowing the occurrence of an MCG failure (or performing an MCG recovery) allows the SN to make such controls (or adjustments).
[0006]
One of the objectives to be achieved by the embodiments disclosed herein is to provide devices, methods, and programs that enable the SN to know the occurrence of an MCG failure. It should be noted that this object is only one of the purposes that the embodiments disclosed herein seek to achieve. Other objectives or issues and novel features will be apparent from the description or accompanying drawings herein.
Means to solve problems
[0007]
In the first aspect, the master node includes at least one memory and at least one processor coupled to the at least one memory. The at least one processor is intended to support dual connectivity that allows the wireless terminal to use the Master Cell Group (MCG) provided by the master node and the Secondary Cell Group (SCG) provided by the secondary node. It is composed. In addition, the at least one processor is configured to send a display associated with the failure of the MCG to the secondary node. Further, the at least one processor sets a Radio Resource Control (RRC) message related to the recovery of the failure of the MCG between the master node and the radio terminal and via both the MCG and the SCG. It is configured to transmit to the radio terminal via the SCG portion of the split signaling radio bearer that supports the transmission.
[0008]
In the second aspect, the secondary node comprises at least one memory and at least one processor coupled to said at least one memory. The at least one processor is intended to support dual connectivity that allows the wireless terminal to use the Master Cell Group (MCG) provided by the master node and the Secondary Cell Group (SCG) provided by the secondary node. It is composed. In addition, the at least one processor is configured to receive indications related to the failure of the MCG from the master node. Further, the at least one processor sets a Radio Resource Control (RRC) message related to the recovery of the failure of the MCG between the master node and the radio terminal and via both the MCG and the SCG. It is configured to transmit to the radio terminal via the SCG portion of the split signaling radio bearer that supports the transmission.
[0009]
In the third aspect, the method performed by the master node is (a) wireless dual connectivity using the Master Cell Group (MCG) provided by the master node and the Secondary Cell Group (SCG) provided by the secondary node. Related to controlling the master node to enable the terminal, (b) sending a display related to the failure of the MCG to the secondary node, and (c) recovering the failure of the MCG. Radio Resource Control (RRC) messages are configured between the master node and the radio terminal and via the SCG portion of the split signaling radio bearer that supports transmission via both the MCG and the SCG. Includes sending to wireless terminals.
[0010]
In the fourth aspect, the method performed by the secondary node is (a) wireless dual connectivity using the Master Cell Group (MCG) provided by the master node and the Secondary Cell Group (SCG) provided by the secondary node. To control the secondary node to enable the terminal, (b) to receive indications related to the failure of the MCG from the master node, and (c) to recover from the failure of the MCG. The relevant Radio Resource Control (RRC) message is set between the master node and the radio terminal and via the SCG portion of the split signaling radio bearer that supports transmission via both the MCG and the SCG. Includes transmitting to the wireless terminal.
[0011]
In the fifth aspect, the program includes an instruction group (software code) for causing the computer to perform the method according to the third or fourth aspect described above when the program is read by the computer.
The invention's effect
[0012]
According to the above aspect, it is possible to provide a device, a method, and a program that enable the SN to know the occurrence of an MCG failure.
A brief description of the drawing
[0013]
FIG. 1 is a diagram showing a configuration example of a wireless communication network according to an embodiment.
FIG. 2 is a sequence diagram showing an example of the operation of MN and SN according to the embodiment.
FIG. 3 is a float showing an example of the operation of MN according to the embodiment.It's a jar.
FIG. 4 is a flowchart showing an example of the operation of the SN according to the embodiment.
FIG. 5 is a sequence diagram showing an example of the operation of MN and SN according to the embodiment.
FIG. 6 is a sequence diagram showing an example of the operation of MN and SN according to the embodiment.
FIG. 7 is a sequence diagram showing an example of the operation of MN and SN according to the embodiment.
FIG. 8 is a sequence diagram showing an example of the operation of MN and SN according to the embodiment.
FIG. 9 is a sequence diagram showing an example of the operation of MN and SN according to the embodiment.
FIG. 10 is a sequence diagram showing an example of the operation of MN and SN according to the embodiment.
FIG. 11 is a sequence diagram showing an example of the operation of MN and SN according to the embodiment.
FIG. 12 is a sequence diagram showing an example of the operation of MN and SN according to the embodiment.
FIG. 13 is a sequence diagram showing an example of the operation of MN and SN according to the embodiment.
FIG. 14 is a sequence diagram showing an example of the operation of MN and SN according to the embodiment.
FIG. 15 is a sequence diagram showing an example of the operation of MN and SN according to the embodiment.
FIG. 16 is a sequence diagram showing an example of the operation of MN and SN according to the embodiment.
FIG. 17 is a sequence diagram showing an example of the operation of MN and SN according to the embodiment.
FIG. 18 is a diagram showing an example of the format of the RRC TRANSFER message according to the embodiment.
FIG. 19 is a sequence diagram showing an example of the operation of CU and DU according to the embodiment.
FIG. 20 is a diagram showing an example of the format of the DL RRC MESSAGE TRANSFER message according to the embodiment.
FIG. 21 is a sequence diagram showing an example of the operation of MN and SN according to the embodiment.
FIG. 22 is a sequence diagram showing an example of the operation of MN and SN according to the embodiment.
FIG. 23 is a sequence diagram showing an example of the operation of the UE according to the embodiment.
FIG. 24 is a sequence diagram showing an example of the operation of MN and SN according to the embodiment.
FIG. 25 is a sequence diagram showing an example of the operation of MN and SN according to the embodiment.
FIG. 26 is a sequence diagram showing an example of the operation of MN and SN according to the embodiment.
FIG. 27 is a diagram showing an example of the format of the RRC TRANSFER message according to the embodiment.
FIG. 28 is a sequence diagram showing an example of the operation of MN and SN according to the embodiment.
FIG. 29 is a diagram showing an example of the format of the MN MODIFICATION INDICATION message according to the embodiment.
FIG. 30 is a diagram showing an example of a format of a CG-ConfigInfo information element according to an embodiment.
FIG. 31 is a sequence diagram showing an example of the operation of MN and SN according to the embodiment.
FIG. 32 is a sequence diagram showing an example of the operation of MN and SN according to the embodiment.
FIG. 33 is a sequence diagram showing an example of the operation of MN and SN according to the embodiment.
FIG. 34 is a sequence diagram showing an example of the operation of MN and SN according to the embodiment.
FIG. 35 is a sequence diagram showing an example of the operation of MN and SN according to the embodiment.
FIG. 36 is a sequence diagram showing an example of the operation of MN and SN according to the embodiment.
FIG. 37 is a sequence diagram showing an example of the operation of MN and SN according to the embodiment.
FIG. 38 is a sequence diagram showing an example of the operation of MN and SN according to the embodiment.
FIG. 39 is a sequence diagram showing an example of the operation of MN and SN according to the embodiment.
FIG. 40 is a block diagram showing a configuration example of MN according to an embodiment.
FIG. 41 is a block diagram showing a configuration example of a UE according to an embodiment.
Embodiment for carrying out the invention
[0014]
In the following, specific embodiments will be described in detail with reference to the drawings. In each drawing, the same or corresponding elements are designated by the same reference numerals, and duplicate explanations are omitted as necessary for the sake of clarity of explanation.
[0015]
The plurality of embodiments described below can be implemented independently or in combination as appropriate. These plurality of embodiments have novel features that differ from each other. Therefore, these plurality of embodiments contribute to solving different purposes or problems, and contribute to different effects.
[0016]
The plurality of embodiments shown below will be described mainly for the 3GPP Long Term Evolution (LTE) system and the 5th generation mobile communication system (5G system). However, these embodiments may be applied to other wireless communication systems that support techniques similar to 3GPP's multi-connectivity (e.g., Dual Connectivity). The term LTE as used herein includes improvements and developments of LTE and LTE-Advanced to enable interworking with the 5G System, unless otherwise noted. In addition to NR (New Radio), the 5G System also includes a network configuration in which LTE eNodeB (eNB) connects to the 5G core network (5GC). The LTE eNB at this time is also called ng-eNB. ng-eNB is also called eNB / 5GC because it is an eNB connected to 5GC. On the other hand, 5G gNB that realizes DC together with LTE eNB that connects to Evolved Packet Core (EPC) is also called en-gNB.
[0017]

FIG. 1 shows a configuration example of a wireless communication network according to this embodiment. The wireless communication network according to the present embodiment includes a master node (MN) 1 and a secondary node (SN) 2. MN1 and SN2 communicate with each other via the inter-node interface 103. Although not shown, at least MN1 may be connected to the core network and SN2 may also be connected to the core network. UE3 communicates with MN1 and SN2 via air interfaces 101 and 102 to perform dual connectivity (DC) of master cell group (MCG) and secondary cell group (SCG). An MCG is a group of serving cells associated with (or provided with) MN1 and is a SpCell (ie, Primary Cell (PCell)) and optionally one or more secondary cells (Secondary). Cells (SCells)), on the other hand, an SCG is a group of serving cells associated with (or provided with) SN2, the SCG's primary cell and optionally one or more secondary cells ( Includes Secondary Cells (SCells). The SCG's primary cell is the Primary SCG Cell (PSCell) or the Primary Secondary Cell (PSCell). The PSCell is the SCG's Special Cell (SpCell). ).
[0018]
Each of MN1 and SN2 may be an Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (EUTRAN) node or an NG-RAN (Next generation Radio Access Network) node. The EUTRAN node may be eNB or en-gNB. The NG-RAN node may be gNB or ng-eNB. The Radio Access Technology (RAT) of MN1 may be different from that of SN2.
[0019]
DC may be Multi-Radio Dual Connectivity (MR-DC). MR-DC includes E-UTRA-NR Dual Connectivity (EN-DC), NR-E-UTRA DC (NE-DC), NG-RAN EN-DC (NGEN-DC), and NR-NR DC (NR DC). )including. EN-DC uses EPC, while NE-DC, NGEN-DC, and NR DC use 5GC.
[0020]
FIG. 2 shows an example of signaling of MN1 and SN2. In step 201, the MN1 sends a message to the SN2 related to modifying or releasing the settings or resources in the SN2 with respect to the DC. That is, the message is a control message of the interface between RAN nodes (i.e., Xn interface or X2 interface). The message may be a message requesting the SN2 to modify or release the settings or resources in the SN2 with respect to the DC. As shown in FIG. 2, the message in step 201 may be an SN MODIFICATION REQUEST message or an SN RELEASE REQUEST message. The SN MODIFICATION REQUEST message is sent from the MN to the SN to request modification of the settings or resources in the SN2 for the DC. On the other hand, the SN RELEASE REQUEST message is sent from the MN to the SN to request the release of settings or resources in the SN2. Instead, the message in step 201 may be a new XnAP / X2AP message (e.g., MN MODIFICATION NOTIFICATION message). The settings in SN2 may be, for example, SCG setting information (e.g., SCG configuration) or bearer setting information (e.g., Radio bearer configuration) that SN2 sets and transmits to UE3 and is also held by SN2. The resources in SN2 are, for example, the resources of the signaling connection between MN1 and SN2 associated with UE3, the SCG radio resources set by SN2 for UE3, or the UE3. It may be terminal information (eg, UE context).
[0021]
Further, the message in step 201 explicitly or implicitly indicates that the modification or release of the SN2 configuration (or resource) is related to the MCG failure (e.g., MCG RLF) or its recovery. In other words, the message in step 201 explicitly or implicitly indicates that the modification or release of the SN2 configuration (or resource) is due to an MCG failure. For example, the message may include an indication of an MCG failure. The indication may indicate, for example, that an MCG failure has occurred, that an MCG failure has been detected, or that the type of MCG failure (e.g., MCG failure type). Further or instead, the message may include an indication of recovery from an MCG failure (or MCG link). The indication may indicate, for example, that it is intended, intended, or attempted to recover from an MCG failure (or MCG link). Further or instead, the message may include an indication of recovery of the MCG failure (or MCG link) via the SN (or SCG, or split SRB, or SRB3). RLF is an example of MCG failure. The MCG failure may be, for example, a handover failure, a MN (MCG) reconfiguration failure (Reconfiguration with sync failure, or Reconfiguration failure), or an integrity protection check failure. Seeds of MCG disorders The class may indicate any of these other MCG disorders.
[0022]
This allows SN2 to know that the modification or release of the settings (or resources) required by the message in step 201 is due to an MCG failure. In other words, SN2 can know that the message in step 201 is associated with an MCG failure or its recovery (recovery). Therefore, SN2 can distinguish the message of step 201 from other SN MODIFICATION and SN RELEASE REQUEST messages that are not related to MCG recovery. In other words, SN2 can distinguish messages about modification or release of SN settings (or resources) sent from MN1 to SN2 for recovery of MCG failure (or MCG link) from other messages.
[0023]
In some implementations, MN1 responds to receiving MCG failure information (MCG failure information or MCG failure indication) from UE3 via SN2 (ie, split SRB, or SRB3 and Xn / X2). You may decide to start the recovery procedure. The MCG recovery procedure may be split SRB, or intra-MN handover or inter-MN handover with the transfer of MN RRC messages via SRB3 and Xn / X2. Then, the MN1 may send the message of step 201 to the SN2 in the MCG recovery procedure. Further, in the MCG recovery procedure, the MN1 may send an MN RRC message related to the recovery of the MCG failure to the UE3 via the SCG (i.e., split SRB or SRB3). In other words, SN2 may send MN RRC messages related to recovery from MCG failure and sent from MN1 to UE3 via SCG (i.e., split SRB or SRB3).
[0024]
Instead, MN1 decides to start the MCG recovery procedure in response to (autonomously) detecting the MCG failure independently of receiving MCG failure information from UE3, and the message in step 201. May be sent to SN2. Further, in the MCG recovery procedure, the MN1 may send an MN RRC message related to the recovery of the MCG failure to the UE3 via the SCG (i.e., split SRB or SRB3). The detection of MCG failure in MN1 is not limited to this, but may be the same as the detection method in the conventional LTE or NR wireless network. For example, an MCG failure can be an uplink or downlink data transmission success / failure status (eg, RLC retransmission count), uplink radio quality status (eg, Sounding Reference Signal (SRS) reception power or reception quality), or It may be determined based on any of the downlink radio quality status (eg, CQI report value, Synchronization Signal / PBCH block (SSB) or CSI-RS RSRP, RSRQ or SINR value).
[0025]
Further, SN2 may perform step 202. In step 202, SN2 determines whether the modification or release of the configuration (or resource) in SN2 requested by the message in step 201 is related to the MCG failure or its recovery. In other words, SN2 determines if the message in step 201 is associated with the MCG disaster recovery procedure. In other words, SN2 determines whether the message in step 201 is due to an MCG failure. If it is determined that the message is due to an MCG failure (or associated with an MCG failure recovery procedure), SN2 sends an MN RRC message from MN1 to UE3 via SN2 (ie, split SRB or SRB3). Postpones modification or release of settings (or resources) in SN2 until certain conditions associated with are met. The MN RRC message is sent to recover from an MCG failure (or MCG link). The MN RRC message may be, for example, an MN RRC (Connection) Reconfiguration message including a reconfigurationWithSync information element (IE) or mobilityControlInfo IE.
[0026]
SN2 may postpone only some of the plurality of modifications or releases requested by the message in step 201. Specifically, SN2 may postpone modifications or releases that may prevent the transmission of RRC messages from MN1 to UE3 via SN2 (i.e., split SRB or SRB3). In some implementations, SN2 may defer the security key update (correction) applied to the direct radio bearer (e.g., SRB3, DRB) between SN2 and UE3. Further or instead, SN2 may postpone Layer 2 reconfiguration (any one or combination of e.g., PDCP re-establishment, PDCP data recovery, RLC re-establishment, and MAC reset). In some implementations, SN2 may postpone the release of resources for signaling connections between MN1 and SN2 associated with UE3. Further or instead, SN2 may postpone the release of the radio resource (e.g., SCG configuration) assigned to UE3. Further or instead, SN2 may postpone the release of terminal information (e.g., UE context) associated with UE3. According to such an operation, the SN2 controls (or adjusts) the timing of setting or modifying or releasing the setting or resource in the SN2 so as not to interfere with the transfer of the MN RRC message via the SN2 between the MN1 and the UE3. can.
[0027]
The predetermined conditions associated with the transmission of the MN RRC message via SN2 may include, for example, at least one of the following examples. In some implementations, the given condition may include that SN2 has completed sending the MN RRC message to UE3. In some implementations, the predetermined condition may include that the SN2 has received a response transmitted by the UE3 in response to the reception of the MN RRC message. In the case where the MN RRC is forwarded via the Split SRB, the response from UE3 may be one or both of the hybrid automatic repeat request (HARQ) Acknowledgement (ACK) and the RLC ARQ ACK. On the other hand, in the case where MN RRC is transferred via SRB3, the response from UE3 may be an SN RRC (Connection) Reconfiguration Complete message from UE3. Further, in some implementations, the predetermined condition may include that SN2 receives an SN Reconfiguration Complete message from MN1 (in the case of intra-MN handover) or target MN (in the case of inter-MN handover).
[0028]
FIG. 3 is a flowchart showing an example of the operation of MN1. In step 301, the MN1 initiates the MCG failure recovery procedure in response to the detection of the MCG failure. As described above, the MN1 may detect the MCG failure based on the reception of the MCG failure information from the UE3, or may autonomously detect the MCG failure independently of the reception of the MCG failure information. good.
[0029]
In step 302, MN1 explicitly or implicitly indicates in the MCG recovery procedure that the modification or release of the configuration (or resource) in SN2 is related to the MCG failure or its recovery, SN MODIFICATION REQUEST or SN RELEASE. Send a REQUEST message to SN2. As mentioned above, the MN1 may send another XnAP / X2AP message to the SN2 that is different from the SN MODIFICATION / RELEASE REQUEST message. The message in step 302 causes the SN2 to postpone the modification or release of the settings (or resources) in the SN2 until certain conditions associated with the transmission of the MN RRC message via the SN2 are met.
[0030]
FIG. 4 is a flowchart showing an example of the operation of SN2. In step 401, SN2 receives an SN MODIFICATION REQUEST or SN RELEASE REQUEST message from MN1. In step 402, SN2 determines whether the modification or release of the configuration (or resource) in SN2 requested by the message in step 401 is related to the MCG failure or its recovery, based on the message in the message in step 401. judge. In other words, SN2 determines if the message in step 401 is associated with the MCG disaster recovery procedure. In other words, SN2 determines whether the message in step 401 is due to an MCG failure. If the message is related to an MCG failure or recovery thereof, SN2 will be SN2 until certain conditions associated with the transmission of the MN RRC message from MN1 to UE3 via SN2 (ie, split SRB or SRB3) are met. Postpone the modification or release of the settings (or resources) in (step 403).
[0031]

This embodiment provides a specific example of the operation of MN1 and SN2 described in the first embodiment. The configuration example of the wireless communication network according to the present embodiment is the same as the example shown in FIG. In this embodiment, in response to the detection of MCG failure when split SRB (eg, split SRB1) is set between MN1 and UE3, MN1 is accompanied by SN change for recovery of MCG failure. No intra-MN handover is performed.
[0032]
FIG. 5 shows an example of signaling of MN1 and SN2 performed in an intra-MN handover procedure without SN change. In step 501, MN1 sends an SN MODIFICATION REQUEST message to SN2. The SN MODIFICATION REQUEST message requests SN2 to modify (or update) the settings or resources associated with UE3 in SN2. For example, the message indicates new security key information in order to request modification (or update) of the security key (eg, SgNB Security Key) applied to the bearer terminated to SN2. You may.
[0033]
The SN MODIFICATION REQUEST message in step 501 further includes an indication to SN2 that the message is associated with an MCG failure or recovery thereof. The indication may be referred to, for example, MCG failure recovery notification, MCG link recovery notification, or MCG failure notification. The display may be an IE or Cause value included in the message. Alternatively, the Cause value may be, for example, MCG Radio Connection With UE Lost, or MCG RLF. In response to receiving such indication, SN2 postpones the modification of the settings (or resources) in SN2.
[0034]
In step 502, SN2 is the MN of SN (or SCG) resource modification for UE3.Send a SN MODIFICATION REQUEST ACKNOWLEDGE message to MN1 to confirm the request from 1. The message may include a CG-Config message generated by SN2. The CG-Config message includes the SCG radio configuration (one or both of e.g., scg-CellGroupConfig and scg-RB-Config) generated by SN2 based on the SN MODIFICATION REQUEST message of step 501.
[0035]
In step 503, MN1 sends an MN RRC message (e.g., RRC Reconfiguration including reconfigurationWithSync) to UE3 via the SCG leg of split SRB1. Specifically, the MN1 sends an RRC TRANSFER message to the SN2 that includes an encapsulating Packet Data Convergence Protocol (PDCP) Protocol Data Unit (PDU). SN2 receives the RRC TRANSFER message and sends a PDCP PDU (encapsulating the MN RRC message) to UE3 via the SCG leg of Split SRB1. In 5G terminology, the PDCP PDU is also called a PDCP-C PDU because it is a PDCP PDU that includes the RRC message of the Control Plane (CP). The PDCP PDU of the PDCP hosted by the gNB Central Unit (CU) Control Plane (CP) is also called the PDCP-C PDU.
[0036]
When the UE3 receives the MN RRC message in step 503, it follows the RRC setting information (eg, securityConfig (HO) and one or both of the sk-Counter) included in the MN RRC message, and performs an intra-MN handover without SN change. To execute. The MN RRC message may include an SN RRC message (or SN RRC setting) for an intra-MN handover without SN change. In this case, the MCG RRC entity of UE3 passes the SN RRC message to the SCG RRC entity of UE3. UE3 executes an intra-MN handover without SN change according to the MN RRC message and the SN RRC message.
[0037]
In step 504, SN2 sends the PDCP PDU (encapsulating the MN RRC message) to UE3 and then the SN (SCG) resource (eg, SCG) for UE3 requested by the SN MODIFICATION REQUEST message of step 501. Modify (update) the settings or resources in SN2. The SN2 may modify (update) the SN (SCG) resource in response to sending the PDCP PDU to the UE3. That is, in the example of FIG. 5, the MN-initiated SN Modification Preparation procedure interacts with the RRC Transfer procedure (or MN RRC reconfiguration procedure). In other words, the MN-initiated SN Modification Preparation procedure is associated with the RRC Transfer procedure (or MN RRC reconfiguration procedure). In some implementations, if SN2 receives an SN MODIFICATION REQUEST message from MN1 (eg, right after), it also receives another RRC TRANSFER message, which is sent by Split SRB in the SN RRC container (eg). , PDCP-C PDU), SN2 prioritizes transmission of the SN RRC container to UE3 over the SN Modification Preparation procedure.
[0038]
FIG. 6 shows a modified example of the procedure shown in FIG. The operations of MN1 and SN2 in steps 601 to 603 are similar to those in steps 501 to 503. In step 604, the SN2 receives the HARQ-ACK (and RLC ARQ-ACK) from the UE3. The HARQ-ACK (and RLC ARQ-ACK) is a Medium Access Control (MAC) sublayer (and) of UE3 to SN2 in response to reception of the MN RRC message in step 603 via the SCG leg (ie, SCG RLC bearer). It is sent to the RLC sublayer).
[0039]
In step 605, after receiving the HARQ-ACK (and RLC ARQ-ACK) from UE3, SN2 modifies (updates) the SN (SCG) resource for UE3 requested by the SN MODIFICATION REQUEST message of step 601. ) Is executed. The SN2 may modify (update) the SN (SCG) resource in response to receiving the HARQ-ACK (and RLC ARQ-ACK) from the UE3. That is, in the example of FIG. 6, the MN-initiated SN Modification Preparation procedure interacts with the RRC Transfer procedure (or MN RRC reconfiguration procedure). In other words, the MN-initiated SN Modification Preparation procedure is associated with the RRC Transfer procedure (or MN RRC reconfiguration procedure). In some implementations, if SN2 receives an SN MODIFICATION REQUEST message from MN1 (eg, right after), it also receives another RRC TRANSFER message, which is sent by Split SRB in the SN RRC container (eg). , PDCP-C PDU), SN2 prioritizes transmission of the SN RRC container to UE3 over the SN Modification Preparation procedure.
[0040]
In normal handover, the UE is allowed to omit the transmission of HARQ-ACK (and RLC ARQ-ACK) for receiving the RRC (Connection) Reconfiguration message including reconfigurationWithSync IE (or mobilityControlInfo IE). .. However, if UE3 receives a reconfigurationWithSync IE (or mobilityControlInfo IE) via the SCG leg of the Split SRB as shown in FIG. 6, the UE3 must send HARQ-ACK (and RLC ARQ-ACK) to SN2. May work with. Even if UE3 operates to always transmit HARQ-ACK (and RLC ARQ-ACK) to SN2 only when UE3 reports the detection of MCG failure to MN1 via SCG and SN2. good. Specifically, for example, when UE3 has transmitted MCG Failure Information, UE3 may operate in this way. Instead, the UE 3 may operate in this way if a predetermined time has not elapsed since the UE 3 transmitted the MCG Failure Information. Instead, the UE 3 may behave in this way if the UE 3 is allowed to send MCG Failure Information. Instead, the UE 3 may operate in this way when the UE 3 has received the setting information for transmission of the MCG Failure Information from the MN.
[0041]
FIG. 7 shows another modification of the procedure shown in FIG. Steps 701 to 704 are the same as steps 601 to 604 of FIG. However, the HARQ-ACK (and RLC ARQ-ACK) transmission in step 704 may be omitted. In step 705, UE3 sends an RRC Reconfiguration Complete message to MN1 via a new PCell dictated by SpCellConfig IE (servCellIndex) that includes ReconfigurationWithSync IE. If MobilityControlInfo IE is used instead of ReconfigurationWithSync IE, the new PCell may be specified by the targetPhysCellId contained in the IE. In step 706, MN1 sends an SN RECONFIGURATION COMPLETE message to SN2. In the SN RECONFIGURATION COMPLETE message, UE3 successfully applied the SCG radio settings (one or both of eg, scg-CellGroupConfig and scg-RB-Config) contained in the SN MODIFICATION REQUEST ACKNOWLEDGE message in step 702. Show that.
[0042]
In step 707, after receiving the SN RECONFIGURATION COMPLETE message from MN1, SN2 modifies (updates) the SN (SCG) resource for UE3 requested by the SN MODIFICATION REQUEST message in step 701. The SN2 may modify (update) the SN (SCG) resource in response to receiving the SN RECONFIGURATION COMPLETE message. That is, in the example of FIG. 7, the MN-initiated SN Modification Preparation procedure interacts with the SN Reconfiguration Complete procedure. In other words, the MN-initiated SN Modification Preparation procedure is associated with the SN Reconfiguration Complete procedure.
[0043]
In some implementations, if MN1 admits a terminal information (eg, UE context) modification (ie SN MODIFICATION REQUEST) that requires a report on the success of the RRC reconfiguration procedure, SN2 will SN1 to MN1. A timer (eg, T DCoverall, TXn DCoverall) may be started when sending a MODIFICATION REQUEST ACKNOWLEDGE message. Then, when the SN2 receives the SN RECONFIGURATION COMPLETE message, the timer may be stopped. In addition, if SN2 receives an additional RRC TRANSFER message after receiving an SN MODIFICATION REQUEST message from MN1 (eg, right after), it will be sent by Split SRB in the SN RRC container (eg, PDCP-C). If it contains a PDU), SN2 prioritizes transmission of the SN RRC container to UE3 over the SN Modification Preparation procedure. That is, SN2 corrects the terminal information (i) at least until it receives the SN RECONFIGURATION COMPLETE message..e. Do not modify (update) SN (SCG) resources.
[0044]
FIG. 8 shows another modification of the procedure shown in FIG. As described above, new XnAP / X2AP messages may be used in place of the SN MODIFICATION REQUEST / ACKNOWLEDGE messages. In the example of FIG. 8, MN1 sends an MN MODIFICATION NOTIFICATION message to SN2 (step 801). The MN MODIFICATION NOTIFICATION message indicates to SN2 that the SCG modification (or reconfiguration) associated with the MCG modification (or modification or reconfiguration) is required. Like the SN MODIFICATION REQUEST message, the MN MODIFICATION NOTIFICATION message requests SN2 to modify (or update) the settings or resources for UE3 in SN2. The MN MODIFICATION NOTIFICATION message may include an indication to SN2 that the message is associated with an MCG failure or recovery thereof. Alternatively, the transmission of the MN MODIFICATION NOTIFICATION message itself may be associated with the MCG failure or its recovery (ie, may mean the MCG failure or its recovery). In other words, the MN MODIFICATION NOTIFICATION message is sent to recover from the MCG failure, and by receiving the message (in response to the reception), SN2 recognizes that MN1 is trying to recover from the MCG failure. May be.
[0045]
In step 802, SN2 sends an MN MODIFICATION NOTIFICATION RESPONSE message to MN1 to confirm the request from MN1 for SN (SCG) resource modification for UE3. The message may include a CG-Config message generated by SN2, similar to the SN MODIFICATION REQUEST ACKNOWLEDGE message.
[0046]
In step 803, similarly to step 503, MN1 transmits an MN RRC message (e.g., RRC Reconfiguration including reconfigurationWithSync) to UE3 via the SCG leg of split SRB1. However, in step 803, a new XnAP / X2AP message (eg, MN MODIFICATION REQUEST message) is used instead of the RRC TRANSFER message. The MN MODIFICATION REQUEST message indicates to SN2 that the MN RRC message associated with the MCG modification needs to be forwarded to UE3.
[0047]
In step 804, SN2 receives HARQ-ACK (and RLC ARQ-ACK) from UE3. The HARQ-ACK (and RLC ARQ-ACK) transmission in step 804 may be omitted.
[0048]
In step 805, SN2 modifies the SN (SCG) resource for UE3 requested by the MN MODIFICATION NOTIFICATION message in step 801 after sending the PDCP PDU (encapsulating the MN RRC message) to UE3. Update) is executed. The SN2 may modify (update) the SN (SCG) resource in response to sending the PDCP PDU to the UE3. Alternatively, after receiving the HARQ-ACK (and RLC ARQ-ACK) from the UE3, the SN (SCG) resource for the UE3 may be modified (updated). The SN2 may modify (update) the SN (SCG) resource in response to receiving the HARQ-ACK (and RLC ARQ-ACK) from the UE3.
[0049]
Similar to the procedure of FIG. 7, in FIG. 8, SN2 modifies the SN (SCG) resource for UE3 requested by the MN MODIFICATION NOTIFICATION message of step 801 after receiving the SN RECONFIGURATION COMPLETE message from MN1. (Update).
[0050]
The MN MODIFICATION NOTIFICATION message of step 801 and the MN MODIFICATION NOTIFICATION RESPONSE message of step 802, and the MN MODIFICATION REQUEST message of step 803 may be specified as one (series) procedure. In this procedure, these operations may be performed as a series of operations (that is, in association with each other). The procedure may be referred to, for example, the MN MODIFICATION preparation procedure or the MN RECOVERY preparation procedure.
[0051]
FIG. 9 shows a specific example of the procedure shown in FIGS. 5 to 7. Steps 904 to 906 of FIG. 9 correspond to steps 501 to 503 of FIG. 5, steps 601 to 603 of FIG. 6, and steps 701 to 703 of FIG. 7. Step 907 of FIG. 9 corresponds to step 604 of FIG. 6 and step 704 of FIG. Steps 909 and 910 of FIG. 9 correspond to steps 705 and 706 of FIG.
[0052]
In step 901 of FIG. 9, UE3 detects an MCG failure (e.g., MCG RLF). In step 902, UE3 transmits MCG failure information to MN1 via the SCG leg of Split SRB1. The RRC TRANSFER message may be used to transfer MCG failure information from SN2 to MN1. In step 903, the MN1 determines the MCG failure recovery procedure in response to receiving the MCG failure information. This MCG failure recovery procedure includes an intra-MN handover procedure (ie, steps 904-911) without SN change.
[0053]
FIG. 10 shows a specific example of the procedure shown in FIG. Steps 1004 to 1007 in FIG. 10 correspond to steps 801 to 804 in FIG. Steps 1001 to 1003 in FIG. 10 are the same as steps 901 to 903 in FIG. Steps 1008 to 1011 in FIG. 10 are the same as steps 908 to 911 in FIG.
[0054]

This embodiment provides a specific example of the operation of MN1 and SN2 described in the first embodiment. The configuration example of the wireless communication network according to the present embodiment is the same as the example shown in FIG. In this embodiment, in response to the detection of MCG failure when split SRB (eg, split SRB1) is set between MN1 and UE3, MN1 is accompanied by SN change for recovery of MCG failure. Do not perform inter-MN handover.
[0055]
FIG. 11 shows an example of signaling of MN1 and SN2 performed in an inter-MN handover procedure without SN change. In step 1101, MN1 sends an SN RELEASE REQUEST message to SN2. MN1 includes the UE Context Kept Indicator IE set to “True” in the SN RELEASE REQUEST message to indicate to SN2 that the UE context in SN2 is kept.
[0056]
The SN RELEASE REQUEST message in step 1101 further includes an additional indication to SN2 that the message is associated with an MCG failure or recovery thereof. The additional indication may be referred to, for example, MCG failure recovery notification, MCG link recovery notification, or MCG failure notification. The display may be an IE or Cause value included in the message. In response to receiving the additional indication, SN2 postpones the release of settings (or resources) within SN2. Specifically, SN2 may postpone the release of resources for signaling connections between MN1 and SN2 associated with UE3. Further or instead, SN2 may postpone the release of radio resources allocated to UE3.
[0057]
In step 1102, SN2 sends an SN RELEASE REQUEST ACKNOWLEDGE message to MN1 in order to confirm the request from MN1 to release the SN (SCG) resource for UE3.
[0058]
In step 1103, MN1 sends an MN RRC message (e.g., RRC Reconfiguration including reconfigurationWithSync) to UE3 via the SCG leg of split SRB1. Step 1103 is the same as step 503 of FIG.
[0059]
In step 1104, SN2 releases the SN (SCG) resource for UE3 requested by the SN RELEASE REQUEST message in step 501 after sending the PDCP PDU (encapsulating the MN RRC message) to UE3. Execute. SN2 may release SN (SCG) resources in response to sending PDCP PDUs to UE3. That is, in the example of FIG. 11, the MN-initiated SN Release procedure interacts with the RRC Transfer procedure (or MN RRC reconfiguration procedure). In other words, the MN-initiated SN Release procedure is associated with the RRC Transfer procedure (or MN RRC reconfiguration procedure). In some implementations, if SN2 receives an SN RELEASE REQUEST message from MN1 (eg, right after), it also receives another RRC TRANSFER message, which is sent by Split SRB in the SN RRC container (eg). , PDCP-C PDU), SN2 prioritizes transmission of the SN RRC container to UE3 over the SN Release procedure.
[0060]
FIG. 12 shows a modified example of the procedure shown in FIG. The operations of MN1 and SN2 in steps 1201 to 1203 are the same as those in steps 1101 to 1103. In step 1204, SN2 receives HARQ-ACK (and RLC ARQ-ACK) from UE3. The HARQ-ACK (and RLC ARQ-ACK) is transmitted from UE3 to the MAC sublayer (and RLC sublayer) of SN2 in response to reception of the MR RRC message in step 1203 via the SCG leg (ie, SCG RLC bearer). Will be done.
[0061]
In step 1205, SN2 performs the release of the SN (SCG) resource for UE3 requested by the SN RELEASE REQUEST message of step 1201 after receiving the HARQ-ACK (and RLC ARQ-ACK) from UE3. do. SN2 may release SN (SCG) resources in response to receiving HARQ-ACK (and RLC ARQ-ACK) from UE3. That is, in the example of FIG. 12, the MN-initiated SN Release procedure interacts with the RRC Transfer procedure (or MN RRC reconfiguration procedure). In other words, MN-initiated S The N Release procedure is associated with the RRC Transfer procedure (or MN RRC reconfiguration procedure). In some implementations, if SN2 receives an SN RELEASE REQUEST message from MN1 (eg, right after), it also receives another RRC TRANSFER message, which is sent by Split SRB in the SN RRC container (eg). , PDCP-C PDU), SN2 prioritizes transmission of the SN RRC container to UE3 over the SN Release procedure.
[0062]
In normal handover, the UE is allowed to omit the transmission of HARQ-ACK (and RLC ARQ-ACK) for receiving the RRC (Connection) Reconfiguration message including reconfigurationWithSync IE (or mobilityControlInfo IE). .. However, if UE3 receives a reconfigurationWithSync IE (or mobilityControlInfo IE) via the SCG leg of the Split SRB as shown in FIG. 12, the UE3 must send HARQ-ACK (and RLC ARQ-ACK) to SN2. May work with. Even if UE3 operates to always transmit HARQ-ACK (and RLC ARQ-ACK) to SN2 only when UE3 reports the detection of MCG failure to MN1 via SCG and SN2. good. Specifically, for example, when UE3 has transmitted MCG Failure Information, UE3 may operate in this way. Instead, the UE 3 may operate in this way if a predetermined time has not elapsed since the UE 3 transmitted the MCG Failure Information. Instead, the UE 3 may behave in this way if the UE 3 is allowed to send MCG Failure Information. Instead, the UE 3 may operate in this way when the UE 3 has received the setting information for transmission of the MCG Failure Information from the MN.
[0063]
FIG. 13 shows another modification of the procedure shown in FIG. Steps 1301 to 1304 are the same as steps 1201 to 1204 in FIG. However, the HARQ-ACK (and RLC ARQ-ACK) transmission in step 1304 may be omitted. In step 1305, UE3 sends an RRC Reconfiguration Complete message to target MN4 via a new PCell dictated by SpCellConfig IE (servCellIndex) that includes ReconfigurationWithSync IE. If MobilityControlInfo IE is used instead of ReconfigurationWithSync IE, the new PCell may be specified by the targetPhysCellId contained in the IE. In step 1306, the target MN4 sends an SN RECONFIGURATION COMPLETE message (or MN RECONFIGURATION COMPLETE message) to SN2.
[0064]
In step 1307, SN2 releases the SN (SCG) resource for UE3 requested by the SN RELEASE REQUEST message in step 1301 after receiving the SN RECONFIGURATION COMPLETE message from target MN4. SN2 may release SN (SCG) resources in response to receiving an SN RECONFIGURATION COMPLETE message. That is, in the example of FIG. 13, the MN-initiated SN Release procedure interacts with the SN Reconfiguration Complete procedure. In other words, the MN-initiated SN Release procedure is associated with the SN Reconfiguration Complete procedure. Instead of step 1306, the target MN4 may send the MN RECONFIGURATION COMPLETE message to the source MN1 and the source MN1 may send the SN RECONFIGURATION COMPLETE message to the SN2.
[0065]
The procedure of FIG. 11 may be further modified. New XnAP / X2AP messages may be used in place of the SN RELEASE REQUEST / ACKNOWLEDGE messages. For example, the MN MODIFICATION NOTIFICATION / RESPONSE message may be used, similar to the procedure in FIG. Further or instead, a new XnAP / X2AP message (eg, the MN MODIFICATION REQUEST message in FIG. 8) may be used in place of the RRC TRANSFER message. As described with respect to FIG. 8, the MN MODIFICATION NOTIFICATION message, the MN MODIFICATION RESPONSE message, and the MN MODIFICATION REQUEST message may be collectively defined as one (series) procedure.
[0066]
FIG. 14 shows a specific example of the procedure shown in FIGS. 11 to 13. Steps 1406-1408 in FIG. 14 correspond to steps 1101 to 1103 in FIG. 11, steps 1201 to 1203 in FIG. 12, and steps 1301 to 1303 in FIG. Steps 1409 and 1410 in FIG. 14 correspond to steps 1305 and 1306 in FIG. In FIG. 14, when SN2 receives an SN RECONFIGURATION COMPLETE message (or MN RECONFIGURATION COMPLETE message) from target MN4 (step 1410), the SN (SCG) resource for UE3 requested by the SN RELEASE REQUEST message in step 1406. May be released except for the UE3 terminal information (eg, UE context). For example, SN2 may release radio resources (e.g., source SCG lower layer configuration (e.g., CellGroupConfig)) associated with UE3 for MR-DC with source MN1.
[0067]
In step 1401 of FIG. 14, UE3 transmits MCG failure information to MN1 via the SCG leg of Split SRB1. MN1 determines the MCG failure recovery procedure according to the reception of MCG failure information. This MCG failure recovery procedure includes an inter-MN handover procedure without SN changes (ie, steps 1402-1413). The inter-MN handover procedure without SN modification includes signaling with the Core Network (CN) 5 for the path switch (step 1411). When the SN2 receives the UE CONTEXT RELEASE message from the source MN1 (step 1413), the SN2 holds the terminal-related resources of UE3 for MR-DC with the source MN1 (eg, C with the source MN1 related to the UE context). -release the plane resource).
[0068]

This embodiment provides a specific example of the operation of MN1 and SN2 described in the first embodiment. The configuration example of the wireless communication network according to the present embodiment is the same as the example shown in FIG. In this embodiment, in response to the detection of MCG failure when split SRB (eg, split SRB1) is set between MN1 and UE3, MN1 is accompanied by SN release for recovery of MCG failure. Perform the MN to gNB change procedure.
[0069]
FIG. 15 shows a specific example of the MN to gNB change procedure with SN release. In step 1501 of FIG. 15, UE3 transmits MCG failure information to MN1 via the SCG leg of Split SRB1. MN1 determines the MCG failure recovery procedure according to the reception of MCG failure information. This MCG disaster recovery procedure includes a MN to gNB change procedure (ie, steps 1502-1513) with SN release.
[0070]
In step 1504, MN1 (i.e., source MN) sends an SN RELEASE REQUEST message to SN2. The SN RELEASE REQUEST message of step 1504 further includes an indication to SN2 that the message is associated with an MCG failure or recovery thereof. The indication may be referred to, for example, MCG failure recovery notification, MCG link recovery notification, or MCG failure notification. The display may be an IE or Cause value included in the message. In response to receiving such indications, SN2 postpones the release of settings (or resources) within SN2. Specifically, SN2 may postpone the release of resources for signaling connections between MN1 and SN2 associated with UE3. In addition, SN2 may postpone the release of terminal information (e.g., UE context) associated with UE3. In addition, SN2 may postpone the release of radio resources (e.g., SCG configuration) associated with UE3.
[0071]
In step 1505, SN2 sends an SN RELEASE REQUEST ACKNOWLEDGE message to MN1 to confirm the request from MN1 to release the SN (SCG) resource for UE3.
[0072]
In step 1506, MN1 sends an MN RRC message (e.g., RRC Reconfiguration including reconfigurationWithSync) to UE3 via the SCG leg of split SRB1. Step 1506 is similar to step 503 in FIG. 5 and step 1103 in FIG.
[0073]
In some implementations, SN2 responds to sending a PDCP PDU (encapsulating the MN RRC message) to UE3 (step 1506), as requested by the SN RELEASE REQUEST message in step 1504. You may free the SN (SCG) resources for this. Alternatively, the SN2 may release the SN (SCG) resource in response to receiving HARQ-ACK (and RLC ARQ-ACK) from the UE3 (step 1507). Alternatively, SN2 may release SN (SCG) resources in response to receiving an SN RECONFIGURATION COMPLETE message (or MN RECONFIGURATION COMPLETE message) from target gNB6 (step 1509). For example, the SN2 may release the SN (SCG) resource for the UE3 requested by the SN RELEASE REQUEST message in step 1504, except for the UE3 terminal information (e.g., UE context).
[0074]

This embodiment provides a specific example of the operation of MN1 and SN2 described in the first embodiment. Wireless communication network according to this embodimentThe configuration example of K is the same as the example shown in FIG. In this embodiment, in response to the detection of MCG failure when split SRB (eg, split SRB1) is set between MN1 and UE3, MN1 changes SN to gNB change for recovery of MCG failure. (Role change) Perform the procedure.
[0075]
FIG. 16 shows a specific example of the SN to gNB change procedure. In step 1601 of FIG. 16, UE3 transmits MCG failure information to MN1 via the SCG leg of Split SRB1. MN1 determines the MCG failure recovery procedure according to the reception of MCG failure information. This MCG disaster recovery procedure includes an SN to gNB change procedure (ie, steps 1602 to 1610).
[0076]
In step 1602, MN1 (i.e., source MN) sends a HANDOVER REQUEST message to SN2. The HANDOVER REQUEST message of step 1602 may include information that explicitly or implicitly indicates that the SN2 is expected to manage the UE3 as an MN (or Standalone (SA)) after the handover. For example, MN1 may indicate it by including the UE Context Reference at the SgNB IE in the message. On the other hand, upon receiving the information (eg, UE Context Reference at the SgNB IE), SN2 performs a handover for UE3 performing MR-DC with MN1 as (target) MN (or SA). You may understand (or recognize) that you are expected (or required) to accept UE3.
[0077]
In step 1603, the SN2 sends a HANDOVER REQUEST ACKNOWLEDGE message to the MN1 to indicate that it accepts the UE3 handover. The SN2 may include the UE Context Kept Indicator IE in the message (set to i.e., True) to indicate to the MN1 that the SN2 manages the UE3 as an MN (or SA).
[0078]
In step 1604, MN1 (i.e., source MN) sends an SN RELEASE REQUEST message to SN2. The SN RELEASE REQUEST message of step 1604 may include the UE Context Kept Indicator IE. In addition, the SN RELEASE REQUEST message includes an indication to SN2 that the message is associated with an MCG failure or recovery thereof. The indication may be referred to, for example, MCG failure recovery notification, MCG link recovery notification, or MCG failure notification. The display may be an IE or Cause value included in the message. In response to receiving such indications, SN2 postpones the release of settings (or resources) within SN2. Specifically, SN2 may postpone the release of resources for signaling connections between MN1 and SN2 associated with UE3. In addition, SN2 may postpone the release of terminal information (e.g., UE context) associated with UE3. In addition, SN2 may postpone the release of radio resources (e.g., SCG lower layer configuration) associated with UE3 for MR-DC with source MN1.
[0079]
In step 1605, SN2 sends an SN RELEASE REQUEST ACKNOWLEDGE message to MN1 to confirm the request from MN1 to release the SN (SCG) resource for UE3.
[0080] [0080]
In step 1606, MN1 sends an MN RRC message (e.g., RRC Reconfiguration including reconfigurationWithSync) to UE3 via the SCG leg of split SRB1. Step 1606 is the same as step 503 in FIG. 5 and step 1103 in FIG. That is, the SN2 is the target RAN node (MN or SA gNB) of the handover, but operates as the source SN at least until the transmission of the MN RRC message.
[0081]
In some implementations, SN2 responds to sending a PDCP PDU (encapsulating the MN RRC message) to UE3 (step 1606), as requested by the SN RELEASE REQUEST message in step 1604 of UE3. You may free the SN (SCG) resources for this. Instead, SN2 releases the SN (SCG) resource for MR-DC with source MN1 in response to receiving HARQ-ACK (and RLC ARQ-ACK) from UE3 (step 1607). You may.
[0082]

The configuration example of the wireless communication network according to this embodiment is the same as the example shown in FIG. The present embodiment provides an improvement on the RRC TRANSFER message sent from MN1 to SN2 to forward the MN RRC message.
[0083]
FIG. 17 shows an example of the operation of MN1 and SN2 according to the present embodiment. In step 1701, MN1 sends an RRC TRANSFER message to SN2. MN1 may include information about the MN RRC message contained in the RRC TRANSFER message (e.g., Delivery Requirement IE, or Delivery Priority IE) in the RRC TRANSFER message. The Delivery Requirement IE indicates whether or not the MN RRC message should be delivered to UE3. The Delivery Priority IE indicates whether the MN RRC message should be delivered to UE3 in preference to other messages or information.
[0084]
FIG. 18 shows a specific example of the format of the RRC TRANSFER message including Delivery Requirement IE. In the example in Figure 18, if the Delivery Requirement IE value is set to “essential”, this means that the PDCP PDU (encapsulating the MN RRC message) should always be delivered to UE3. ..
[0085]
Note that the SN2 may include a Central Unit (CU) (e.g., gNB-CU) and one or more Distributed Units (DUs) (e.g., gNB-DUs). Further, the CU may include a Control Plane (CP) Unit (e.g., gNB-CU-CP) and one or more User Plane (UP) Units (e.g., gNB-CU-UP). In this case, as shown in FIG. 19, the CU (or CU-CP) 1901 sends the Delivery Requirement IE to the message (F1AP: DL RRC MESSAGE TRANSFER message) sent to the DU1902 to forward the RRC message to UE3. It may be included (step 1911).
[0086]
FIG. 20 shows a specific example of the format of the DL RRC MESSAGE TRANSFER message including Delivery Requirement IE. In the example of FIG. 20, if the value of Delivery Requirement IE is set to "essential", this means that the PDCP PDU (encapsulating the RRC message) should always be delivered to UE3.
[0087]
FIG. 21 shows an example of the MCG recovery procedure. In the example of FIG. 21, in response to the detection of MCG failure when split SRB (eg, split SRB1) is set between MN1 and UE3, MN1 changes the SN to recover from the MCG failure. Perform inter-MN handover without accompanying.
[0088]
The procedure of FIG. 21 is similar to that of FIG. However, in the procedure of FIG. 21, the RRC Transfer procedure (step 2106) is performed before the SN Release procedure (steps 2107 and 2108). In step 2106, MN1 sends an MN RRC message (e.g., RRC Reconfiguration including reconfigurationWithSync) to UE3 via the SCG leg of split SRB1. Specifically, MN1 sends an RRC TRANSFER message containing the PDCP PDU encapsulating the MN RRC message to SN2. The RRC TRANSFER message indicates that the PDCP PDU should always be delivered to UE3. The RRC TRANSFER message may include a Delivery Requirement IE set to “essential”. On the other hand, in step 2107, the MN1 does not have to include in the SN RELEASE REQUEST message an indication indicating its association with the MCG failure or its recovery.
[0089]
According to the procedure of FIG. 21, if the SN2 has received the RRC TRANSFER message (step 2106) including the Delivery Requirement IE set to “essential”, it is requested by the SN RELEASE REQUEST message (step 2107). Release of resources for UE3 can be deferred (deferred) until delivery of the PDCP PDU (encapsulating the MN RRC message) to UE3 is complete. When Delivery Priority IE is used instead of Delivery Requirement IE and the value of the IE is set to "high", SN2 may operate in the same manner as described above.
[0090]
The procedure of FIG. 21 may be modified as follows. For example, the SN Release procedure (corresponding to steps 2107 and 2108 of FIG. 21) may be performed prior to the RRC Transfer procedure (corresponding to step 2106 of FIG. 21). At this time, the SN RELEASE REQUEST message may not include an indication that it is associated with the MCG failure or its recovery. If the SN2 receives an RRC TRANSFER message containing the Delivery Requirement IE after receiving the SN RELEASE REQUEST message and the value of that IE is set to "essential", the SN2 releases the settings (or resources) in the SN2. put off. This allows SN2 to suspend (defer) the release of resources for UE3 required by the SN RELEASE REQUEST message until delivery of the PDCP PDU (encapsulating the MN RRC message) to UE3 is complete.
[0091]
<7th Embodiment>
The configuration example of the wireless communication network according to this embodiment is the same as the example shown in FIG. The present embodiment provides an improvement of inter-node messages (i.e., XnAP / X2AP messages) sent from MN1 to SN2.
[0092]
As already explained, the XnAP / X2AP message requesting SN2 to modify or change the settings (or resources) in SN2 for UE3 is an MCG failure.

The scope of the claims
[Claim 1]
It is a master node
At least one memory and
With at least one processor coupled to the at least one memory,
Equipped with
The at least one processor is
Supports dual connectivity that allows wireless terminals to use the Master Cell Group (MCG) provided by the master node and the Secondary Cell Group (SCG) provided by the secondary node.
Send the display related to the failure of the MCG to the secondary node,
A split signaling radio that is configured between the master node and the radio terminal and supports transmission via both the MCG and the SCG for Radio Resource Control (RRC) messages related to the recovery of the failure of the MCG. Configured to transmit to the wireless terminal via the SCG portion of the bearer,
Master node.
[Claim 2]
The at least one processor is configured to send a first message to the secondary node relating to configuration or resource modification or release within the secondary node with respect to the dual connectivity.
The first message includes the display.
The indication expressly or implicitly indicates that the modification or release is associated with the failure or recovery of the failure of the MCG.
The master node according to claim 1.
[Claim 3]
The first message causes the secondary node to postpone the modification or release of the setting or the resource until certain conditions associated with the transmission of the RRC message via the secondary node are met.
The master node according to claim 2.
[Claim 4]
The predetermined condition includes that the secondary node has completed transmission of the RRC message to the wireless terminal.
The master node according to claim 3.
[Claim 5]
The predetermined condition includes that the secondary node receives a response transmitted by the wireless terminal in response to the reception of the RRC message.
The master node according to claim 3.
[Claim 6]
The first message requests the setting or modification of the resource,
The setting or the resource includes a security key applied to a direct wireless bearer between the secondary node and the wireless terminal.
The master node according to any one of claims 2 to 5.
[Claim 7]
The first message requests the setting or the release of the resource,
The configuration or the resource includes a resource for a signaling connection between the master node and the secondary node associated with the wireless terminal.
The master node according to any one of claims 2 to 5.
[Claim 8]
The at least one processor is configured to send a second message carrying the RRC message to the secondary node in order to deliver the RRC message to the wireless terminal.
The second message expressly or implicitly indicates that the delivery of the RRC message is related to the failure of the MCG or the recovery of the failure.
The master node according to any one of claims 1 to 7.
[Claim 9]
The at least one processor is configured to send a second message carrying the RRC message to the secondary node in order to deliver the RRC message to the wireless terminal.
The second message indicates to the secondary node that the RRC message should always be delivered.
The master node according to any one of claims 1 to 7.
[Claim 10]
The at least one processor is configured to transmit to the radio terminal permission to switch the uplink primary path of the split signaling radio bearer from the MCG to the SCG.
The master node according to any one of claims 1 to 9.
[Claim 11]
The permission responds to the detection of the failure of the MCG by the radio terminal while receiving the permission, and the information of the failure of the MCG is transmitted through the SCG portion of the split signaling radio bearer. Causes the wireless terminal to transmit to the master node.
The permission causes the wireless terminal to perform an RRC connection reestablishment procedure in response to the detection of the failure of the MCG by the wireless terminal when the permission is not received.
The master node according to claim 10.
[Claim 12]
The at least one processor causes the wireless terminal to instruct the wireless terminal whether to perform the RRC connection reestablishment procedure or the MCG recovery procedure when the wireless terminal detects the failure of the MCG. Configured,
The MCG recovery procedure comprises transmitting information about the failure of the MCG from the radio terminal to the master node via the SCG portion of the split signaling radio bearer.
The master node according to any one of claims 1 to 9.
[Claim 13]
It is a secondary node
At least one memory and
With at least one processor coupled to the at least one memory,
Equipped with
The at least one processor is
Supports dual connectivity that allows wireless terminals to use the Master Cell Group (MCG) provided by the master node and the Secondary Cell Group (SCG) provided by the secondary node.
Received the display related to the failure of the MCG from the master node,
A split signaling radio that is configured between the master node and the radio terminal and supports transmission via both the MCG and the SCG for Radio Resource Control (RRC) messages related to the recovery of the failure of the MCG. Configured to transmit to the wireless terminal via the SCG portion of the bearer,
Secondary node.
[Claim 14]
The at least one processor is configured to receive a first message from the master node relating to the configuration or resource modification or release within the secondary node with respect to the dual connectivity.
The first message includes the display.
The indication expressly or implicitly indicates that the modification or release is associated with the failure or recovery of the failure of the MCG.
The secondary node according to claim 13.
[Claim 15]
The at least one processor is
Whether or not the modification or release is related to the failure or the failure of the MCG is determined based on the display.
In response to determining that the modification or release is related to the failure or the failure of the MCG, the RRC message has been associated with transmission from the master node to the radio terminal via the secondary node. It is configured to postpone the modification or release of the setting or the resource until certain conditions are met.
The secondary node according to claim 14.
[Claim 16]
The predetermined condition includes that the secondary node has completed transmission of the RRC message to the wireless terminal.
The secondary node according to claim 15.
[Claim 17]
The predetermined condition includes that the secondary node receives a response transmitted by the wireless terminal in response to the reception of the RRC message.
The secondary node according to claim 15.
[Claim 18]
The first message requests the setting or modification of the resource,
The setting or the resource includes a security key applied to a direct wireless bearer between the secondary node and the wireless terminal.
The secondary node according to any one of claims 14 to 17.
[Claim 19]
The first message requests the setting or the release of the resource,
The configuration or the resource includes a resource for a signaling connection between the master node and the secondary node associated with the wireless terminal.
The secondary node according to any one of claims 14 to 17.
[Claim 20]
The at least one processor is configured to receive a second message carrying the RRC message from the master node.
The second message expressly or implicitly indicates that the delivery of the RRC message is related to the failure of the MCG or the recovery of the failure.
The secondary node according to any one of claims 13 to 19.
[Claim 21]
The at least one processor is configured to receive a second message carrying the RRC message from the master node.
The second message indicates to the secondary node that the RRC message should always be delivered.
The secondary node according to any one of claims 13 to 19.
[Claim 22]
It is a method performed by the master node,
Controlling the master node to enable dual connectivity to the wireless terminal using the Master Cell Group (MCG) provided by the master node and the Secondary Cell Group (SCG) provided by the secondary node.
Sending a display related to the failure of the MCG to the secondary node, and
A split signaling radio that is configured between the master node and the radio terminal and supports transmission via both the MCG and the SCG for Radio Resource Control (RRC) messages related to the recovery of the failure of the MCG. Sending to the wireless terminal via the SCG part of the bearer,
How to prepare.
[Claim 23]
It is a method performed by a secondary node,
Controlling the secondary node to enable dual connectivity to the wireless terminal using the Master Cell Group (MCG) provided by the master node and the Secondary Cell Group (SCG) provided by the secondary node.
Receiving the display related to the failure of the MCG from the master node,
A split signaling radio that is configured between the master node and the radio terminal and supports transmission via both the MCG and the SCG for Radio Resource Control (RRC) messages related to the recovery of the failure of the MCG. Sending to the wireless terminal via the SCG part of the bearer,
How to prepare.
[Claim 24]
A non-temporary computer-readable medium containing a program to make a computer perform the method for a master node.
The above method is
Controlling the master node to enable dual connectivity to the wireless terminal using the Master Cell Group (MCG) provided by the master node and the Secondary Cell Group (SCG) provided by the secondary node.
Controlling the master node to send a display related to the failure of the MCG to the secondary node, and
A split signaling radio that is configured between the master node and the radio terminal and supports transmission via both the MCG and the SCG for Radio Resource Control (RRC) messages related to the recovery of the failure of the MCG. Control the master node to transmit to the wireless terminal via the SCG part of the bearer To control,
A non-temporary computer-readable medium.
[Claim 25]
A non-temporary computer-readable medium containing a program that allows a computer to perform the method performed by a secondary node.
The above method is
Controlling the secondary node to enable dual connectivity to the wireless terminal using the Master Cell Group (MCG) provided by the master node and the Secondary Cell Group (SCG) provided by the secondary node.
Controlling the secondary node to receive the display related to the failure of the MCG from the master node,
A split signaling radio that is configured between the master node and the radio terminal and supports transmission via both the MCG and the SCG for Radio Resource Control (RRC) messages related to the recovery of the failure of the MCG. Controlling the secondary node to transmit to the wireless terminal via the SCG portion of the bearer,
A non-temporary computer-readable medium.