JP7351661B2 - Terminal device, base station device, and control method - Google Patents

Description

The present invention relates to a terminal device, a base station device, and a control method .

Radio access systems and radio networks for cellular mobile communications (hereinafter referred to as "Long Term Evolution (LTE: registered trademark)" or "Evolved Universal Terrestrial Radio Access: EUTRA"), and core networks (hereinafter referred to as "Evolved "Packet Core: EPC") is being considered in the 3rd Generation Partnership Project (3GPP). EUTRA is also referred to as E-UTRA.

Additionally, in 3GPP, LTE-Advanced Pro, which is an extension technology of LTE, and NR (New Radio technology), which is a new radio access technology, are being developed as radio access methods and radio network technologies for fifth-generation cellular systems. Studies and standards are being developed (Non-Patent Document 1). Further, 5 Generation Core Network (5GC), which is a core network for the 5th generation cellular system, is also being studied (Non-Patent Document 2).

3GPP RP-170855, “Work Item on New Radio (NR) Access Technology” 3GPP TS 23.501 v15.3.0, “System Architecture for the 5G System; Stage 2” 3GPP TS 36.300, v15.3.0, “Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terestrial Radio Access N etwork (E-UTRAN); Overall description; Stage 2” 3GPP TS 36.331 v15.4.0, “Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specific ions” 3GPP TS 36.323 v15.3.0, “Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP) specific ation” 3GPP TS 36.322 V15.3.0, “Evolved UNIVERSAL TERESTRIAL RADIO ACCESS (E -UTRA); RADIO LINK CONTROL (RLC) Protocol SPECIFICATI ON " 3GPP TS 36.321 v15.3.0, “Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specific on” 3GPP TS 37.340v 15.3.0, “Evolved Universal Terrestrial Radio Access (E-UTRA) and NR; Multi-Connectivity; Stage 2” 3GPP TS 38.300v 15.3.0, “NR; NR and NG-RAN Overall description; Stage 2” 3GPP TS 38.331 v15.4.0, “NR; Radio Resource Control (RRC); Protocol specifications” 3GPP TS 38.323 v15.3.0, “NR; Packet Data Convergence Protocol (PDCP) specification” 3GPP TS 38.322 v15.3.0, “NR; Radio Link Control (RLC) protocol specification” 3GPP TS 38.321 v15.3.0, “NR; Medium Access Control (MAC) protocol specification” 3GPP TS 23.401 v15.0.0, “General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Ne twork (E-UTRAN) access” 3GPP TS 23.502 v15.3.0, “Procedure for 5G System; Stage 2” 3GPP TS 37.324 v15.1.0, “NR; Service Data Adaptation Protocol (SDAP) specification” 3GPP Draft_Report_v1. doc, “Report of 3GPP TSG RAN2#105 meeting, Athens, Greece” http://www. 3gpp. org/ftp/TSG_RAN/WG2_RL2/TSGR2_105/Report/Draft_Report_v1. zip 3GPP RP-181544, “Revised WID: Even further mobility enhancement in E-UTRAN” 3GPP RP-181433, “New WID: NR mobility enhancements” 3GPP R2-1901364, “Detail for non-split bearer option for simultaneous connectivity”

As part of the LTE technology study, a mechanism to further expand the existing LTE mobility expansion technology is being considered. Furthermore, in the study of NR technology, mechanisms to expand existing NR mobility technology are being considered. (Non-patent Documents 18, 19). These studies mainly include the study of Reduce User Data Interruption (RUDI), a technology that brings the interruption of user data transmission and reception close to 0 ms when moving between cells to which a base station device and a terminal device are connected (during handover). , and handover robustness improvements.

In RUDI, a mechanism is being considered in which two protocol stacks exist simultaneously for one cell group, but detailed terminal operations for efficiently controlling mobility have not yet been studied.

One aspect of the present invention has been made in view of the above circumstances, and one of the objects is to provide a terminal device, a method, and an integrated circuit that can efficiently control mobility.

(1) In order to achieve the above object, one embodiment of the present invention takes the following measures. That is, a first embodiment of the present invention is a terminal device that communicates with a base station device, which includes a receiving unit that receives an RRC message from the base station device, and a processing unit that performs processing based on the RRC message. The RRC message includes settings for each of one or more cell groups, and based on the fact that the RRC message includes first information, the RRC message includes settings for a certain cell group (first cell group). A MAC entity (second MAC entity) different from the existing MAC entity (first MAC entity) of the first cell group is generated, and information regarding the logical channel (second MAC entity) is generated in the settings for the first cell group. 2), a second MAC entity is configured using a logical channel according to the second information.

(2) A second embodiment of the present invention is a base station device that communicates with a terminal device, comprising a transmitting unit that transmits an RRC message to the terminal device, and a processing unit that generates the RRC message, The RRC message includes one or more settings for each cell group, and based on including the first information in the RRC message, the existing settings for a certain cell group (first cell group) The terminal device generates a MAC entity (second MAC entity) different from the MAC entity (first MAC entity) of one cell group, and the second MAC entity is added to the settings for the first cell group. Contains information (second information) regarding the logical channel for setting up the logical channel.

(3) A third embodiment of the present invention is a method applied to a terminal device communicating with a base station device, which includes the steps of receiving an RRC message from the base station device; processing, the RRC message includes settings for each of one or more cell groups, and based on the first information being included in the RRC message, a certain cell group (a first Generate a MAC entity (second MAC entity) different from the MAC entity (first MAC entity) of the existing first cell group for the cell group), and configure the settings for the first cell group. If information regarding a logical channel (second information) is included, a second MAC entity is configured using a logical channel according to the second information.

(4) A fourth embodiment of the present invention is a method applied to a base station device communicating with a terminal device, which includes the steps of transmitting an RRC message to the terminal device, and generating the RRC message. and, the RRC message includes settings for each of one or more cell groups, and based on including first information in the RRC message, a configuration for a certain cell group (first cell group) is provided. On the other hand, the terminal device generates a MAC entity (second MAC entity) different from the MAC entity (first MAC entity) of the existing first cell group, and the settings for the first cell group include: Information regarding the logical channel for configuring the second MAC entity (second information) is included.

(5) A fifth embodiment of the present invention is an integrated circuit installed in a terminal device communicating with a base station device, which has a function of receiving an RRC message from the base station device, and a function based on the RRC message. and a function for performing a process based on the fact that the RRC message includes settings for each of one or more cell groups, and that the RRC message includes first information. , generates a MAC entity (second MAC entity) different from the existing MAC entity of the first cell group (first MAC entity) for a certain cell group (first cell group), and If the configuration for one cell group includes information regarding a logical channel (second information), a second MAC entity is configured using the logical channel according to the second information.

(6) A sixth embodiment of the present invention is an integrated circuit that is implemented in a base station device that communicates with a terminal device, and has a function of transmitting an RRC message to the terminal device and generating the RRC message. function for the base station apparatus, the RRC message includes settings for each of one or more cell groups, and based on including the first information in the RRC message, a certain cell causing the terminal device to generate a MAC entity (second MAC entity) different from the MAC entity (first MAC entity) of the existing first cell group for the group (first cell group); Information (second information) regarding a logical channel for configuring a second MAC entity is included in the configuration for the first cell group.

Note that these comprehensive or specific aspects may be realized by a system, an apparatus, a method, an integrated circuit, a computer program, or a recording medium. It may be realized by any combination of the following.

According to one aspect of the present invention, a terminal device can realize efficient mobility processing.

1 is a schematic diagram of a communication system according to each embodiment of the present invention. FIG. 4 is a protocol stack diagram of UP and CP of a terminal device and a base station device in E-UTRA in each embodiment of the present invention. FIG. 4 is a protocol stack diagram of UP and CP of a terminal device and a base station device in NR in each embodiment of the present invention. The figure which shows an example of the flow of the procedure for various settings in RRC208 and/or RRC308 in each embodiment of this invention. FIG. 1 is a block diagram showing the configuration of a terminal device in each embodiment of the present invention. FIG. 1 is a block diagram showing the configuration of a base station device in each embodiment of the present invention. An example of processing related to handover in EUTRA in each embodiment of the present invention. An example of processing related to handover in NR in each embodiment of the present invention. An example of conditions for starting and stopping each timer in the embodiment of the present invention. An example of the mobilityControlInfo information element in the embodiment of the present invention. Another example of the mobilityControlInfo information element in the embodiment of the present invention. An example of a reconfiguration information element with synchronization according to an embodiment of the present invention. Another example of the reconfiguration information element with synchronization in the embodiment of the present invention. ASN included in a message regarding reconfiguration of an RRC connection in an NR in an embodiment of the present invention. An example of one description. ASN included in a message regarding reconfiguration of an RRC connection in E-UTRA in the embodiment of this invention. An example of one description. The figure which shows an example of the flow of process A in embodiment of this invention. The figure which shows an example of the flow of process B in embodiment of this invention. The figure which shows an example of the flow of process C in embodiment of this invention. The figure which shows an example of the flow of process H in embodiment of this invention. In each embodiment of the present invention, the ASN. An example of one description. In each embodiment of the present invention, the ASN. Another example of 1 description. FIG. 3 is a block diagram showing the configuration of a protocol set in the UE 122 in each embodiment of the present invention. An example of the processing method of the PDCP entity 2200 in each embodiment. An example of a downlink reception processing method of the PDCP entity 2200 in each embodiment. An example of an uplink transmission processing method of the PDCP entity 2200 in each of the present embodiments. Another example of the processing method of the PDCP entity 2200 in each embodiment. The figure which shows another example of the flow of process E in embodiment of this invention. FIG. 7 is a diagram showing another example of the flow of processing B in the embodiment of the present invention. The figure which shows another example of the flow of processing LA in embodiment of this invention.

Embodiments of the present invention will be described in detail below with reference to the drawings.

LTE (and LTE-A Pro) and NR are different radio access technologies (Radio
Access Technology (RAT). Further, NR may be defined as a technology included in LTE. LTE may be defined as a technology included in NR. Further, LTE that can be connected to NR using Multi Radio Dual connectivity may be distinguished from conventional LTE. Further, LTE whose core network is 5GC may be distinguished from conventional LTE whose core network is EPC. This embodiment may be applied to NR, LTE and other RATs. The following description uses terms related to LTE and NR, but may be applied in other technologies using other terms. Furthermore, the term E-UTRA in this embodiment may be replaced with the term LTE, and the term LTE may be replaced with the term E-UTRA.

FIG. 1 is a schematic diagram of a communication system according to each embodiment of the present invention.

The E-UTRA 100 is a radio access technology described in Non-Patent Document 3, etc., and is composed of a cell group (CG) made up of one or more frequency bands. The eNB (E-UTRAN Node B) 102 is a base station device of the E-UTRA 100. EPC (Evolved Packet Core) 104 is a core network described in Non-Patent Document 14 and the like, and was designed as a core network for E-UTRA 100. The interface 112 is an interface between the eNB 102 and the EPC 104, and includes a control plane (CP) through which control signals pass and a user plane (UP) through which user data passes.

NR106 is a radio access technology described in Non-Patent Document 9 and the like, and is composed of a cell group (CG) configured of one or more frequency bands. gNB (g Node B) 108 is a base station device of NR 106. The 5GC 110 is a core network described in Non-Patent Document 2, and is designed as a core network for the NR 106, but may also be used as a core network for the E-UTRA 100 that has the function of connecting to the 5GC 110. Hereinafter, the E-UTRA 100 may include an E-UTRA 100 having a function of connecting to the 5GC 110.

Interface 114 is an interface between eNB 102 and 5GC 110, interface 116 is an interface between gNB 108 and 5GC 110, interface 118 is an interface between gNB 108 and EPC 104, and interface 120 is an interface between eNB 102 and gNB 108. Face 124 is EPC104 and 5GC110 It is an interface between The interface 114, the interface 116, the interface 118, the interface 120, the interface 124, etc. may be an interface that passes only the CP, only the UP, or both the CP and the UP. Further, the interface 114, the interface 116, the interface 118, the interface 120, the interface 124, etc. may not exist depending on the communication system provided by the communication carrier.

The UE 122 is a terminal device compatible with either or all of the E-UTRA 100 and the NR 106. As described in any or all of Non-Patent Document 3 and Non-Patent Document 9, when the UE 122 connects to the core network via any or all of the E-UTRA 100 and the NR 106, the UE 122 and A logical path called a radio bearer (RB) is established between any or all of the E-UTRA 100 and NR 106. The radio bearer used for CP is called a signaling radio bearer (SRB), and the radio bearer used for UP is called a data radio bearer (DRB Data Radio Bearer). Each RB is assigned an RB identifier (RB Identity or RB ID) and is uniquely identified. The RB identifier for SRB is called an SRB identifier (SRB Identity, or SRB ID), and the RB identifier for DRB is called a DRB identifier (DRB Identity, or DRB ID).

As described in Non-Patent Document 3, when the core network to which the UE 122 is connected is the EPC 104, each DRB established between the UE 122 and any or all of the E-UTRA 100 and the NR 106 is further connected to the EPC 104. It is uniquely linked to each EPS (Evolved Packet System) bearer that passes through the network. Each EPS bearer is assigned an EPS bearer identifier (Identity, or ID) and is uniquely identified. Furthermore, the same QoS is guaranteed for data passing through the same EPS bearer.

As described in Non-Patent Document 9, when the core network to which the UE 122 is connected is the 5GC 110, one or more DRBs established between the UE 122 and any or all of the E-UTRA 100 and the NR 106 are Furthermore, the PDU (Packet
Data Unit) is linked to one of the sessions. Each PDU session has one or more QoS flows. Each DRB may be mapped with one or more QoS flows existing in the associated PDU session, or may not be mapped with any QoS flow. Each PDU session is identified by a PDU session identifier (Identity, or ID). Each QoS flow is also identified by a QoS flow identifier. Furthermore, the same QoS is guaranteed for data passing through the same QoS flow.

EPC 104 does not have any or all of PDU sessions and QoS flows, and 5GC 110 does not have EPS bearers. In other words, when the UE 122 is connected to the EPC 104, the UE 122 has information on the EPS bearer, and when the UE 122 is connected to the 5GC 110, the UE 122 has information on any or all of the PDU session and QoS flow. .

FIG. 2 is a protocol stack diagram of the UP and CP of the terminal device and the base station device in the E-UTRA radio access layer in each embodiment of the present invention.

FIG. 2(A) is a protocol stack diagram of the UP used when the UE 122 communicates with the eNB 102 in the E-UTRA 100.

A PHY (Physical layer) 200 is a wireless physical layer, and provides a transmission service to an upper layer using a physical channel. The PHY200 is a higher-level MAC (Medium), which will be described later.
It is connected to the Access Control layer 202 via a transport channel. Data moves between the MAC 202 and the PHY 200 via the transport channel. Data is transmitted and received between the PHY of the UE 122 and the eNB 102 via a wireless physical channel.

The MAC 202 is a medium access control layer that maps various logical channels to various transport channels. The MAC 202 is connected to a higher-level RLC (Radio Link Control layer) 204, which will be described later, through a logical channel. Logical channels are broadly classified according to the type of information to be transmitted, and are divided into control channels that transmit control information and traffic channels that transmit user information. The MAC 202 has functions such as a function to control the PHY 200 to perform intermittent reception and transmission (DRX/DTX), a function to execute a random access procedure, a function to notify information on transmission power, a function to perform HARQ control, etc. (Non-patent Document 7).

The RLC 204 segments the data received from the upper PDCP (Packet Data Convergence Protocol Layer) 206, which will be described later, and adjusts the data size so that the lower layer can appropriately transmit the data. This is the radio link control layer (radio link control layer). The RLC 200 also has a function to guarantee the QoS (Quality of Service) required by each piece of data. That is, the RLC 204 has functions such as data retransmission control (Non-Patent Document 6).

The PDCP 206 is a packet data convergence protocol layer (packet data convergence protocol layer) for efficiently transmitting IP packets, which are user data, over a wireless section. The PDCP 206 may have a header compression function that compresses unnecessary control information. Furthermore, the PDCP 206 may also have a data encryption function. (Non-patent document 5).

Note that the data processed in the MAC 202, RLC 204, and PDCP 206 are respectively referred to as MAC PDU (Protocol Data Unit), RLC PDU, and PDCP PDU. Further, data passed from the upper layer to the MAC 202, RLC 204, and PDCP 206, or data passed to the upper layer, are respectively referred to as MAC SDU (Service Data Unit), RLC SDU, and PDCP SDU.

Furthermore, in order to distinguish between data-use and control-use PDCP PDUs, they may be called PDCP DATA PDUs (PDCP Data PDUs) and PDCP CONTROL PDUs (PDCP Control PDUs), respectively. Furthermore, in order to distinguish between data-use and control-use RLC PDUs, they may be called RLC DATA PDUs (RLC Data PDUs) and RLC CONTROL PDUs (RLC Control PDUs), respectively.

FIG. 2(B) is a protocol stack diagram of the CP used when the UE 122 communicates with the eNB 102 and the MME (Mobility Management Entity), which is a logical node that provides functions such as authentication and mobility management, in the E-UTRA 100. .

In addition to PHY 200, MAC 202, RLC 204, and PDCP 206, the CP protocol stack includes RRC (Radio Resource Control layer) 208 and NAS (non Access Strarum) 210. The RRC 208 performs processes such as establishing, re-establishing, suspending, and resuming RRC connections, and resetting RRC connections, such as radio bearer (RB) and cell group. The radio link control layer (radio link control layer), which performs settings such as establishment, modification, and release, and controls logical channels, transport channels, and physical channels, as well as handover and measurement settings layer). The RB may be divided into a signaling radio bearer (SRB) and a data radio bearer (DRB), and the SRB is used as a path for transmitting an RRC message that is control information. It's okay. The DRB may be used as a path for transmitting user data. Each RB may be configured between the eNB 102 and the RRC 208 of the UE 122. Further, a portion of the RB that is composed of the RLC 204 and the MAC 202 may be called an RLC bearer (Non-Patent Document 4). In addition, for the NAS layer that carries signals between the MME and UE 122, some or all layers of PHY 200, MAC 202, RLC 204, PDCP 206, and RRC 208 that carry signals and data between UE 122 and eNB 102 are (Access Strarum) layer.

The functional classification of the MAC 202, RLC 204, PDCP 206, and RRC 208 described above is an example, and some or all of the functions may not be implemented. Further, part or all of the functions of each layer may be included in other layers.

Note that the IP layer and the TCP (Transmission Control Protocol) layer, UDP (User Datagram Protocol) layer, application layer, etc. above the IP layer are upper layers of the PDCP layer (not shown). Further, the RRC layer and the NAS (non-access strum) layer are also upper layers of the PDCP layer (not shown). In other words, the PDCP layer is a layer below the RRC layer, NAS layer, IP layer, TCP (Transmission Control Protocol) layer above the IP layer, UDP (User Datagram Protocol) layer, and application layer.

FIG. 3 is a protocol stack diagram of the UP and CP of the terminal device and the base station device in the NR radio access layer in each embodiment of the present invention.

FIG. 3(A) is a protocol stack diagram of the UP used when the UE 122 communicates with the gNB 108 in the NR 106.

A PHY (Physical layer) 300 is a wireless physical layer of NR, and may provide a transmission service to an upper layer using a physical channel. The PHY 300 may be connected to a higher-level MAC (Medium Access Control layer) 302, which will be described later, via a transport channel. Data may be moved between MAC 302 and PHY 300 via a transport channel. Data may be transmitted and received between the PHY of the UE 122 and the gNB 108 via a wireless physical channel.

Here, the physical channel will be explained.

The following physical channels may be used in wireless communication between the terminal device and the base station device.

PBCH (Physical Broadcast Channel)
PDCCH (Physical Downlink Control Channel)
PDSCH (Physical Downlink Shared Channel)
PUCCH (Physical Uplink Control Channel)
PUSCH (Physical Uplink Shared CHannel)
PRACH (Physical Random Access Channel)

PBCH is used to broadcast system information required by terminal devices.

Further, in NR, the PBCH may be used to broadcast a time index (SSB-Index) within the period of a synchronization signal block (also referred to as an SS/PBCH block).

The PDCCH is used to transmit (or carry) downlink control information (DCI) in downlink wireless communication (wireless communication from the base station device 3 to the terminal device). Here, one or more DCIs (which may be referred to as DCI formats) are defined for transmission of downlink control information. That is, a field for downlink control information is defined as DCI and mapped to information bits. PDCCH is transmitted on PDCCH candidates. The terminal device monitors a set of PDCCH candidates in the serving cell. Monitoring means attempting to decode the PDCCH according to a certain DCI format. A certain DCI format may be used for PUSCH scheduling in the serving cell. PUSCH may be used for transmitting user data, RRC messages, and the like.

PUCCH may be used to transmit uplink control information (UCI) in uplink wireless communication (wireless communication from a terminal device to a base station device). Here, the uplink control information may include channel state information (CSI) used to indicate the state of a downlink channel. Furthermore, the uplink control information may include a scheduling request (SR) used to request UL-SCH resources. Further, the uplink control information may include HARQ-ACK (Hybrid Automatic Repeat request ACKnowledgement).

The PDSCH may be used to transmit downlink data (DL-SCH: Downlink Shared Channel) from the MAC layer. In the case of downlink, it is also used to transmit system information (SI), random access response (RAR), and the like.

PUSCH may be used to transmit HARQ-ACK and/or CSI along with uplink data (UL-SCH: Uplink Shared Channel) or uplink data from the MAC layer. Furthermore, it may be used to transmit only CSI or only HARQ-ACK and CSI. That is, it may be used to transmit only the UCI. The PDSCH or PUSCH may also be used to transmit RRC signaling (also referred to as RRC message) and MAC control elements. Here, in the PDSCH, the RRC signaling transmitted from the base station device may be common signaling to multiple terminal devices within the cell. Further, the RRC signaling transmitted from the base station device may be dedicated signaling (also referred to as dedicated signaling) for a certain terminal device. That is, the terminal device-specific (UE-specific) information may be transmitted to a certain terminal device using dedicated signaling. Further, the PUSCH may be used to transmit UE Capability in the uplink.

PRACH may be used to transmit random access preambles. PRACH handles initial connection establishment procedures, handover procedures, connection re-establishment procedures, synchronization (timing adjustment) for uplink transmissions, and requests for PUSCH (UL-SCH) resources. to show May be used for.

The MAC 302 is a medium access control layer that maps various logical channels to various transport channels. The MAC 302 may be connected to a higher-level RLC (Radio Link Control layer) 304, which will be described later, through a logical channel. Logical channels are broadly classified according to the type of information to be transmitted, and may be divided into control channels that transmit control information and traffic channels that transmit user information. The MAC 302 has a function of controlling the PHY 300 to perform intermittent reception and transmission (DRX/DTX), a function of executing a random access procedure, a function of notifying information on transmission power, a function of performing HARQ control, etc. (Non-patent Document 13).

The RLC 304 performs radio link control to segment data received from the upper PDCP (Packet Data Convergence Protocol Layer) 206, which will be described later, and adjusts the data size so that the lower layer can appropriately transmit the data. layer (radio link control layer). Furthermore, the RLC 304 may also have a function to guarantee QoS (Quality of Service) required by each data. That is, the RLC 304 may have functions such as data retransmission control (Non-Patent Document 12).

The PDCP 306 is a packet data convergence protocol layer (packet data convergence protocol layer) that efficiently transmits IP packets, which are user data, in a wireless section. The PDCP 306 may have a header compression function that compresses unnecessary control information. Furthermore, the PDCP 306 may also have data encryption and data integrity protection functions (Non-Patent Document 11).

SDAP (Service Data Adaptation Protocol) 310 maps the downlink QoS flow sent from the 5GC 110 to the terminal device via the base station device and the DRB, and the mapping from the terminal device to the terminal device via the base station device. This is a service data adaptation protocol layer (service data adaptation protocol layer) that has a function of mapping an uplink QoS flow sent to the 5GC 110 and a DRB and storing mapping rule information (Non-Patent Document 16).

Note that the data processed in the MAC 302, RLC 304, PDCP 306, and SDAP 310 are respectively referred to as MAC PDU (Protocol Data Unit), RLC PDU, PDCP PDU, and SDAP PDU. Furthermore, data passed from the upper layer to the MAC 302, RLC 304, PDCP 306, and SDAP 310, or data passed to the upper layer, are respectively referred to as MAC SDU (Service Data Unit), RLC SDU, PDCP SDU, and SDAP SDU.

Furthermore, in order to distinguish between SDAP PDUs for data and control, they may be called SDAP DATA PDUs (SDAP Data PDUs) and SDAP CONTROL PDUs (SDAP Control PDUs), respectively. Furthermore, in order to distinguish between data-use and control-use PDCP PDUs, they may be called PDCP DATA PDUs (PDCP Data PDUs) and PDCP CONTROL PDUs (PDCP Control PDUs), respectively. Furthermore, in order to distinguish between data-use and control-use RLC PDUs, they may be called RLC DATA PDUs (RLC Data PDUs) and RLC CONTROL PDUs (RLC Control PDUs), respectively.

FIG. 3B is a protocol stack diagram of the CP used when the UE 122 communicates with the gNB 108 and an AMF (Access and Mobility Management function), which is a logical node that provides functions such as authentication and mobility management, in the NR 106. .

In addition to PHY 300, MAC 302, RLC 304, and PDCP 306, the CP protocol stack includes RRC (Radio Resource Control layer) 308 and NAS (non Access Strarum) 312. The RRC 308 performs processes such as establishing, re-establishing, suspending, and resuming RRC connections, and resetting RRC connections, such as radio bearer (RB) and cell group (Cell Group). The radio link control layer (radio link control layer), which performs settings such as establishment, modification, and release, and controls logical channels, transport channels, and physical channels, as well as handover and measurement settings layer). The RB may be divided into a signaling radio bearer (SRB) and a data radio bearer (DRB), and the SRB is used as a path for transmitting an RRC message that is control information. You can. The DRB may be used as a path for transmitting user data. Each RB may be configured between the gNB 108 and the RRC 308 of the UE 122. Further, a portion of the RB that is composed of the RLC 304 and the MAC 302 may be called an RLC bearer (Non-Patent Document 10). In addition, for the NAS layer that carries signals between the AMF and UE 122, some or all layers of PHY 300, MAC 302, RLC 304, PDCP 306, RRC 308, and SDAP 310 that carry signals and data between UE 122 and gNB 108 may be referred to as an AS (Access Stratum) layer.

Furthermore, the following SRBs may be defined from SRB0 to SRB3. SRB0 may be an SRB for an RRC message using a logical channel CCCH (Common Control Channel). SRB1 may be the SRB for RRC messages (which may include piggybacked NAS messages) and for NAS messages before the establishment of SRB2, all of which are used by the logical channel DCCH (Dedicated Control Channel). It's okay to be rejected. SRB2 may be an SRB for NAS messages, and all logical channels DCCH may be used. Further, SRB2 may have a lower priority than SRB1. The SRB3 may be an SRB for a specific RRC message when the UE 122 is configured with EN-DC, NGEN-DC, NR-DC, etc., and all logical channels DCCH may be used. Further, other SRBs may be prepared for other uses.

The functional classification of the MAC 302, RLC 304, PDCP 306, SDAP 310, and RRC 308 described above is an example, and some or all of the functions may not be implemented. Moreover, a part or all of the functions of each layer (each layer) may be included in another layer (layer).

Note that the IP layer and the TCP (Transmission Control Protocol) layer, UDP (User Datagram Protocol) layer, application layer, etc. above the IP layer are upper layers of any or all of the SDAP layer and PDCP layer ( (not shown). Further, the RRC layer and the NAS (non-access strum) layer may also be upper layers of any or all of the SDAP layer and the PDCP layer (not shown). In other words, any or all of the SDAP layer and the PDCP layer are the RRC layer, the NAS layer, the IP layer, and the TCP (Transmission Control Protocol) layer above the IP layer, the UDP (User Datagram Protocol) layer, and the application layer. It is a lower layer of any or all of the following.

In each embodiment of the present invention, SIP (Session Initiation Protocol), SDP (Session Description Protocol), etc. used in IMS, and RTP (Real-time Transport Pr) used for media communication or media communication control are used. otocol), RTCP It is assumed that any or all of Real-time Transport Control Protocol (HTTP), HyperText Transfer Protocol (HTTP), and codecs for various media belong to the application layer.

Note that any or all of the establishment, configuration, and control of the physical layer, MAC layer, RLC layer, PDCP layer, and SDAP layer of the terminal device may be performed by the RRC layer of the terminal device. Further, the RRC layer of the terminal device may establish and/or configure the physical layer, MAC layer, RLC layer, PDCP layer, and SDAP layer according to the RRC message transmitted from the RRC layer of the base station device. In addition, the MAC layer (MAC layer), RLC layer (RLC layer), PDCP layer (PDCP layer), and SDAP layer (SDAP layer) are respectively MAC sublayer (MAC sublayer), RLC sublayer (RLC sublayer), and PDCP sublayer It may also be called a layer (PDCP sublayer) or an SDAP sublayer (SDAP sublayer).

Note that each layer belonging to the AS layer or the function of each layer that is configured in any or all of the terminal device and the base station device may be referred to as an entity. In other words, the physical layer (PHY layer), MAC layer, RLC layer, and PDCP layer are established, configured, and controlled in any or all of the terminal device and the base station device. , SDAP layer, and RRC layer, or the functions of each layer may be respectively referred to as a physical entity (PHY entity), MAC entity, RLC entity, PDCP entity, SDAP entity, and RRC entity. Furthermore, each layer may include one or more entities. Furthermore, any or all of the establishment, configuration, and control of the PDCP entity and the RLC entity may be performed for each radio bearer. Furthermore, any or all of the establishment, configuration, and control of the MAC entity may be performed for each cell group. Further, the SDAP entity may be established, configured, and/or controlled for each PDU session.

Note that the COUNT value may be used when performing encryption or integrity protection processing in the PDCP layer or PDCP entity. The COUNT value may include a HFN (Hyper Frame Number) and a sequence number (SN) added to the header of the PDCP PDU. The sequence number may be incremented by 1 each time a PDCP DATA PDU is generated by a PDCP layer or a PDCP entity on the transmitting side. HFN may be incremented by 1 each time the sequence number reaches the maximum value.

In each embodiment of the present invention, in order to distinguish between the E-UTRA protocol and the NR protocol, the MAC 202, RLC 204, PDCP 206, and RRC 208 are referred to as MAC for E-UTRA, MAC for LTE, and E-UTRA, respectively. It is also called RLC for E-UTRA or RLC for LTE, PDCP for E-UTRA or PDCP for LTE, and RRC for E-UTRA or RRC for LTE. Furthermore, the MAC 302, RLC 304, PDCP 306, and RRC 308 may be referred to as NR MAC, NR RLC, NR RLC, and NR RRC, respectively. Alternatively, it may be written as E-UTRA PDCP, LTE PDCP, NR PDCP, etc. using spaces.

Further, as shown in FIG. 1, the eNB 102, gNB 108, EPC 104, and 5GC 110 may be connected via an interface 112, an interface 116, an interface 118, an interface 120, and an interface 114. Therefore, in order to support various communication systems, the RRC 208 in FIG. 2 may be replaced with the RRC 308 in FIG. 3. Further, the PDCP 206 in FIG. 2 may be replaced with the PDCP 306 in FIG. 3. Further, the RRC 308 in FIG. 3 may include the functions of the RRC 208 in FIG. 2. Further, the PDCP 306 in FIG. 3 may be the PDCP 206 in FIG. 2. Furthermore, in the E-UTRA 100, NR PDCP may be used as the PDCP even when the UE 122 communicates with the eNB 102.

Next, the state transition of the UE 122 in LTE and NR will be explained. The UE 122 connecting to the EPC has an RRC connection established.
has been established), it may be in the RRC_CONNECTED state. The UE 122 may also be in the RRC_INACTIVE state (if the UE 122 is connected to the 5GC) when the RRC connection is dormant. If those are not the case, the UE 122 may be in the RRC_IDLE state.

Note that the UE 122 connected to the EPC does not have the RRC_INACTIVE state,
RRC connection dormancy may be initiated by the E-UTRAN. In this case, when the RRC connection is suspended, the UE 122 retains the UE's AS context and an identifier (resumeIdentity) used for resumption, and transitions to the RRC_IDLE state. When the UE 122 retains the UE's AS context, and the E-UTRAN permits the restoration of the RRC connection, and the UE 122 needs to transition from the RRC_IDLE state to the RRC_CONNECTED state, the suspended RRC Connection restoration may be initiated by a higher layer (eg NAS layer).

That is, the definition of suspension may be different between the UE 122 that connects to the EPC and the UE 122 that connects to the 5GC. In addition, all of the procedures for returning from hibernation or Some parts may be different.

Note that the RRC_CONNECTED state, RRC_INACTIVE state, and RRC_IDLE state may be respectively referred to as a connected state (connected mode), an inactive state (inactive mode), and an idle state (idle mode).

The UE AS context held by the UE 122 includes the current RRC settings, the current security context, the PDCP state including the ROHC (RObust Header Compression) state, and the C-RNTI (Cell Radio The information may include all or part of a Network Temporary Identifier, a cell identifier (cellIdentity), and a physical cell identifier of the PCell that is the connection source. Note that the UE AS context held by any or all of the eNB 102 and gNB 108 may include the same information as the UE AS context held by the UE 122, or the information contained in the UE AS context held by the UE 122. may contain information different from that.

The security context refers to the encryption key at the AS level, the NH (Next Hop
information including all or some of the following: NCC (Next Hop Chaining Counter parameter) used for deriving the next hop access key, an identifier of the selected AS-level encryption algorithm, and a counter used for replay protection. It may be.

FIG. 4 is a diagram showing an example of a flow of procedures for various settings in the RRC 208 and/or the RRC 308 in each embodiment of the present invention. FIG. 4 is an example of a flow when an RRC message is sent from the base station device (eNB 102 and/or gNB 108) to the terminal device (UE 122).

In FIG. 4, the base station device creates an RRC message (step S400). To create an RRC message in a base station device, the base station device uses broadcast information (SI: System
This may be done when distributing information (Information) or paging information, or when the base station determines that it is necessary to have a specific terminal perform processing, such as security settings or RRC connection (connection). ) (radio bearer processing (establishment, change, release, etc.), cell group processing (establishment, addition, change, release, etc.), measurement setting, handover setting, etc.), RRC connection state release, etc. It may be done on occasion. RRC messages may also be used for handover commands to different RATs. The RRC message includes information (parameters) for various information notifications and settings. In specifications regarding RRC such as Non-Patent Document 4 or Non-Patent Document 10, these parameters are called fields and/or information elements, and are referred to as ASN. 1 (Abstract Syntax Notation One).

In FIG. 4, the base station device next transmits the created RRC message to the terminal device (step S402). Next, the terminal device performs processing such as setting, if necessary, according to the above-mentioned received RRC message (step S404).

Note that the creation of the RRC message is not limited to the example described above, and may be created for other purposes as described in Non-Patent Document 4, Non-Patent Document 10, and the like.

For example, the RRC message may be used for settings related to Dual Connectivity (DC) and Multi-Radio Dual Connectivity (MR-DC) described in Non-Patent Document 8.

Dual Connectivity (DC) refers to a cell group configured by two base station devices (nodes), that is, a master cell group (MCG) configured by a master node (Master Node: MN) and a secondary node (Secondary node). The technology may be one in which data communication is performed using both radio resources of a secondary cell group (SCG) constituted by a node (SN). Further, the master node and the secondary node may be the same node (the same base station device). Furthermore, the MR-DC described in Non-Patent Document 8 is a system in which cells of both E-UTRA and NR RATs (Radio Access Technology) are grouped by RAT and allocated to UEs, and radio resources of both MCG and SCG are allocated to the UE. It may also be a technology that performs data communication using . In MR-DC, the master node refers to the main RRC functions related to MR-DC, such as adding secondary nodes, establishing, changing, and releasing RBs, adding, changing, releasing, and handover MCGs, etc. The secondary node may be a base station that has some RRC functions, such as SCG change and release.

In the MR-DC described in Non-Patent Document 8, the RRC of the RAT on the master node side may be used to configure both the MCG and SCG. For example, when the core network is EPC104 and the master node is eNB102 (also referred to as extended eNB102), EN-DC (E-UTRA-NR Dual Connectivity) is the MR-DC, the core network is 5GC110, and the master node is 5GC110. In NGEN-DC (NG-RAN E-UTRA-NR Dual Connectivity), which is the MR-DC when the eNB 102 is the eNB 102, the E-UTRA RRC message described in Non-Patent Document 4 is transmitted and received between the eNB 102 and the UE 122. It's okay to be. In this case, the RRC message may include not only LTE (E-UTRA) configuration information but also NR configuration information described in Non-Patent Document 10. Further, the RRC message sent from the eNB 102 to the UE 122 may be sent from the eNB 102 to the UE 122 via the gNB 108. In addition, the configuration of this RRC message is used for E-UTRA/5GC (option 5 described in Non-Patent Document 17) in which the eNB 102 (enhanced eNB) uses 5GC as a core network in a non-MR-DC. It's okay.

Conversely, in the MR-DC described in Non-Patent Document 8, the core network is 5GC 110 and the master node is gNB 108. In NE-DC (NR-E-UTRA Dual Connectivity), The NR RRC message described in Non-Patent Document 10 may be transmitted and received between the gNB 108 and the UE 122. In this case, the RRC message may include not only the NR configuration information but also the LTE (E-UTRA) configuration information described in Non-Patent Document 4. Further, the RRC message sent from the gNB 108 to the UE 122 may be sent from the gNB 108 to the UE 122 via the eNB 102.

Note that, not only when using MR-DC, the E-UTRA RRC message sent from the eNB 102 to the UE 122 may include an NR RRC message, and the NR RRC message sent from the gNB 108 to the UE 122. The RRC message may include an E-UTRA RRC message.

Further, a network configuration in which the master node is the eNB 102 and the EPC 104 is the core network may be called E-UTRA/EPC. Further, a network configuration in which the master node is the eNB 102 and the 5GC 110 is the core network may be called E-UTRA/5GC. Further, a network configuration in which the master node is the gNB 108 and the 5GC 110 is the core network may be called NR or NR/5GC. Also, this name does not have to be limited to the case where DC is set. When a DC is not set, the above-mentioned master node may refer to a base station device that communicates with a terminal device.

FIG. 14 shows an ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.DELTA.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.DELTA.ASN.DELTA.ASN.ASN.ASN.ASN.DELTA.ASN.ASN.ASN.ASN.ASN.ASN.ASN. This is an example of one description. Further, FIG. 15 shows an ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.ASN.DELTA.ASN.ASN.ASN.ASN.ASN.ASN.ASN.DELTA..ASN.ASN.DELTA..ASN.ASN.DELTA.ASN.ASN.ASN.ASN. This is an example of one description. ASN. In example 1, <omitted> and <omitted> refer to ASN. It is not a part of the notation in item 1, and indicates that other information is omitted. Note that information elements may be omitted even in places where there is no description of <omitted> or <omitted>. Please note that ASN. An example of 1 is ASN. This notation does not exactly follow the No. 1 notation method, but is an example of the parameter of a message related to resetting an RRC connection in the embodiment of the present invention, and other names and other notations may be used. Also, ASN. In order to avoid complicating the explanation, Example 1 shows only examples related to main information closely related to the present invention. In addition, ASN. The parameters described in 1 are sometimes referred to as information elements, without distinguishing them into fields, information elements, etc. Further, in the embodiment of the present invention, ASN. Parameters such as fields and information elements described in 1 may also be referred to as information. Note that the message regarding RRC connection reconfiguration may be an RRC reconfiguration message in NR or an RRC connection reconfiguration message in E-UTRA.

The information element represented by RadioBearerConfig in FIG. 14 is an information element related to the configuration of radio bearers such as SRB and DRB, and includes a PDCP configuration information element and an SDAP configuration information element, which will be described later. The information element represented by SRB-ToAddMod, which is included in the information element represented by RadioBearerConfig, may be information indicating SRB (signaling radio bearer) configuration, and is an SRB configuration information element or a signaling radio bearer configuration information element. Sometimes it can be said that. Further, the information element represented by SRB-ToAddModList may be a list of information indicating SRB settings. The information element represented by DRB-ToAddMod, which is included in the information element represented by RadioBearerConfig, may be information indicating DRB (data radio bearer) configuration, and is a DRB configuration information element or data radio bearer configuration information element. Sometimes it can be said that. The information element represented by DRB-ToAddModList may be a list of information indicating DRB settings. Note that any or all of the SRB settings and DRB settings may be referred to as radio bearer settings.

The information element represented by SRB-Identity in the SRB configuration information element is information on the SRB identifier (SRB Identity) of the SRB to be added or changed, and is an identifier that uniquely identifies the SRB in each terminal device. Also good. It may also be referred to as an SRB identifier information element, a radio bearer identifier information element, or a signaling radio bearer identifier information element.

The information element represented by DRB-Identity in the DRB configuration information element is information on the DRB identifier (DRB Identity) of the DRB to be added or changed, and is an identifier that uniquely identifies the DRB in each terminal device. Also good. It may also be referred to as a DRB identifier information element, a radio bearer identifier information element, or a data radio bearer identifier information element. Although the value of the DRB identifier is an integer value from 1 to 32 in the example of FIG. 14, it may take another value. In the case of a DC, the DRB identifier is unique within the scope of the UE 122.

The information element represented by cnAssociation in the DRB configuration information element may be an information element indicating whether to use EPC 104 or 5GC 110 for the core network, and may also be called a core network association information element. . That is, when the UE 122 connects to the EPC, the DRB is associated with the EPS bearer identifier information element (eps-BearerIdentity) in the cnAssociation or the EPS bearer identity (EPS bearer identity) that is the value of the EPS bearer identifier information element, When the UE 122 connects to the 5GC 110, the DRB is an SDAP entity configured according to the SDAP configuration information element (sdap-Config) described below, or a PDU session information element described later or a PDU session included in the SDAP configuration information element. It may be associated with the PDU session identifier that is the value of the information element or the PDU session indicated by the PDU session information element. That is, the information represented by cnAssociation includes an EPS bearer identifier information element (eps-BearerIdentity) when using the EPC 104 in the core network such as when using EN-DC, and when using the core network 5GC 110, If EN-DC is not used, an information element (sdap-Config) indicating SDAP settings may be included.

The information element represented by sdap-Config may be information regarding the configuration or reconfiguration of the SDAP entity that determines the mapping method between QoS flows and DRBs when the core network is the 5GC 110. This may also be referred to as the SDAP configuration information element.

The field or information element indicated by pdu-session or PDU-SessionID included in the SDAP configuration information element is a field or information element that corresponds to the value of the radio bearer identifier information element included in the DRB configuration information element including this SDAP configuration information element. It may be a PDU session identifier of a PDU session described in Non-Patent Document 2 to which a QoS flow mapped to a bearer belongs, and may also be referred to as a PDU session identifier information element. The value of the PDU session identifier information element may be a non-negative integer. Further, in each terminal device, a plurality of DRB identifiers may correspond to one PDU session identifier.

The information element indicated by mappedQoS-FlowsToAdd included in the SDAP configuration information element corresponds (map) to the radio bearer corresponding to the value of the radio bearer identifier information element included in the DRB configuration information element including this SDAP configuration information element. The information may also be information indicating a list of QoS Flow Identity (QFI) information elements (described later) of the QoS flow to be mapped or additionally mapped, and may also be referred to as a QoS flow information element to be added. be. The above-mentioned QoS flow may be a QoS flow of a PDU session indicated by the PDU session information element included in this SDAP configuration information element.

Additionally, the information element indicated by mappedQoS-FlowsToRelease included in the SDAP configuration information element corresponds to the radio bearer corresponding to the value of the radio bearer identifier information element included in the DRB configuration information element including this SDAP configuration information element ( The QoS flow information element to be released may be information indicating a list of QoS flow identifier (QFI) information elements (described later) of the QoS flows whose correspondence relationship is to be released among the QoS flows that are Sometimes it can be said that. The above-mentioned QoS flow may be a QoS flow of a PDU session indicated by the PDU session information element included in this SDAP configuration information element.

The information element indicated by the QFI may be a QoS flow identifier that uniquely identifies a QoS flow, as described in Non-Patent Document 2, and may also be referred to as a QoS flow identifier information element. The value of the QoS flow identifier information element may be a non-negative integer. Also, the value of the QoS flow identifier information element may be unique for a PDU session.

In addition, the SDAP configuration information element includes an uplink header information information element that indicates whether or not an uplink SDAP header exists in uplink data to be transmitted via the configured DRB, and A downlink header information element that indicates whether a downlink SDAP header exists in the downlink data received via the downlink, and default bearer information that indicates whether the configured DRB is a default radio bearer (default DRB). It may also include elements.

In addition, the information element represented by pdcp-Config or PDCP-Config in the SRB configuration information element and the DRB configuration information element is the NR for establishing or changing the PDCP 306 for SRB and/or DRB. It may be an information element related to the settings of a PDCP entity, and may be called a PDCP setting information element. Information elements related to the configuration of the NR PDCP entity include an information element indicating the size of the uplink sequence number, an information element indicating the size of the downlink sequence number, and an information element indicating the profile of header compression (RoHC: RObust Header Compression). , a re-ordering timer information element, and the like.

The information element represented by DRB-ToReleaseList included in the information element represented by RadioBearerConfig may include information indicating one or more DRB identifiers to be released.

The information element represented by RadioResourceConfigDedicated in FIG. 15 may be an information element used for setting, changing, releasing, etc. a radio bearer. The information element represented by SRB-ToAddMod, which is included in the information element represented by RadioResourceConfigDedicated, may be information indicating SRB (signaling radio bearer) configuration, and is not an SRB configuration information element or a signaling radio bearer configuration information element. There are some other words. The information element represented by SRB-ToAddModList may be a list of information indicating SRB settings. The information element represented by DRB-ToAddMod, which is included in the information element represented by RadioResourceConfigDedicated, may be information indicating DRB (data radio bearer) configuration, and is not a DRB configuration information element or a data radio bearer configuration information element. There are some other words. The information element represented by DRB-ToAddModList may be a list of information indicating DRB settings. Note that any or all of the SRB settings and DRB settings may be referred to as radio bearer settings.

The information element represented by SRB-Identity in the SRB configuration information element is information on the SRB identifier (SRB Identity) of the SRB to be added or changed, and is an identifier that uniquely identifies the SRB in each terminal device. Also good. It may also be referred to as an SRB identifier information element, a radio bearer identifier information element, or a signaling radio bearer identifier information element. The information element represented by SRB-Identity in FIG. 15 may be an information element having the same role as the information element represented by SRB-Identity in FIG. 14.

The information element represented by DRB-Identity in the DRB settings is information on the DRB identifier (DRB Identity) of the DRB to be added or changed, and even if it is a DRB identifier that uniquely identifies the DRB in each terminal device. good. It may also be referred to as a DRB identifier information element, a radio bearer identifier information element, or a data radio bearer identifier information element. Although the value of the DRB identifier is an integer value from 1 to 32 in the example of FIG. 15, it may take another value. The information element represented by DRB-Identity in FIG. 15 may be an information element having the same role as the information element represented by DRB-Identity in FIG. 14.

The information element represented by eps-BearerIdentity in the DRB configuration information element may be an EPS bearer identifier that uniquely identifies the EPS bearer in each terminal device. The information element represented by eps-BearerIdentity is sometimes referred to as an EPS bearer identifier information element. Although the value of the EPS bearer identifier is an integer value from 1 to 15 in the example of FIG. 15, it may take another value. The information element represented by eps-BearerIdentity in FIG. 15 may be an information element having the same role as the information element represented by eps-BearerIdentity in FIG. 14. Further, the EPS bearer identifier and the DRB identifier may have a one-to-one correspondence in each terminal device.

In addition, the information element represented by pdcp-Config or PDCP-Config in the SRB configuration information element and the DRB configuration information element is an E-configuration information element for establishing or changing the PDCP 206 for SRB and/or DRB. It may be an information element regarding the configuration of a UTRA PDCP entity, and may also be referred to as a PDCP configuration information element. E-UTRA
The information elements related to the configuration of the PDCP entity include an information element indicating the size of the sequence number, an information element indicating the profile of header compression (RoHC: RObust Header Compression), re-ordering timer information, etc. Also good.

Further, some or all of the information elements shown in FIG. 14 or 15 may be optional. That is, the information elements shown in FIG. 14 or 15 may be included in the message regarding resetting the RRC connection depending on necessity and conditions. In addition to the information element regarding radio bearer configuration, the message regarding RRC connection reconfiguration may also include an information element indicating that full configuration is applied. An information element that means that full settings are applied may be represented by an information element name such as fullConfig, or true, enable, etc. may be used to indicate that full settings are applied.

The information element represented by DRB-ToReleaseList included in the information element represented by RadioResourceConfigDedicated may include information indicating one or more DRB identifiers to be released.

In the following description, the eNB 102 and/or gNB 108 will also be simply referred to as a base station device, and the UE 122 will also be simply referred to as a terminal device.

One serving cell provides the mobility information of the NAS when the RRC connection is established or re-established or at handover. When the RRC connection is re-established or during handover, one serving cell provides security input. This serving cell is referred to as a primary cell (PCell). Also, depending on the capabilities of the terminal device, one or more serving cells (secondary cells, SCells) may be additionally configured in addition to the primary cell.

Furthermore, a set of serving cells composed of two subsets may be configured for the terminal device. The two subsets are a cell group (master cell group) consisting of one or more serving cells including a primary cell (PCell), and one or more serving cells including a primary secondary cell (PSCell) but not including a primary cell. It may also be configured with one or more cell groups (secondary cell groups) consisting of. The primary secondary cell may be a cell in which PUCCH resources are configured.

An example of an operation related to radio link failure (RLF) by a terminal device connected to RRC will be described.

The terminal device receives the value (t310 or t313) of a timer (for example, T310 or T313) for detecting physical layer problems of the serving cell, and out-of-synchronization (OoS) from the base station device in the serving cell. Information such as N310 and N313, which are the thresholds for the number of detections during synchronization (IS: in-sync), and N311 and N314, which are the thresholds for the number of detections during synchronization (IS: in-sync), is obtained through broadcast information and RRC messages to individual users. . Further, the value of the timer and the threshold value of the number of times may be set to default values. Further, the names of the timers may be different between EUTRA and NR.

For radio link monitoring, the physical layer processing unit of the terminal device monitors the radio link quality of the serving cell based on information such as the received power of the received reference signal and/or the received power of the synchronization signal and/or the packet error rate. is estimated to be worse than a specific threshold value (Qout) for a specific period (for example, _{TEvaluate_Qout} =200ms), an "out-of-synchronization" is sent to the RRC layer processing unit, which is an upper layer. of-sync)”. Further, the physical layer processing unit determines whether the radio link quality of the serving cell is high for a specific period (for example, TEvaluate _{_} Qin = 100 ms) and is estimated to exceed a specific threshold (Qin), it notifies the RRC layer processing unit, which is an upper layer, that it is "in-sync". Note that the physical layer processing unit may notify the upper layer of out-of-synchronization or synchronization at a specific interval (for example, TReport_sync=10 ms) or more.

Here, for example, the threshold Qout is determined based on the block error rate of the downlink control channel (PDCCH) transmission, which is hypothetical based on predetermined parameters and which is based on the assumption that the downlink radio link cannot be reliably received. (Block error rate) may be defined as a level at which the block error rate is a first specific rate. Also, for example, the threshold Qin is set such that the downlink radio link quality is significantly more reliably received than the state of Qout, and furthermore, the block error rate of the hypothetical downlink control channel transmission based on predetermined parameters is It may be defined as a level that is a certain proportion of 2. Furthermore, a plurality of block error rates (levels of the threshold Qout and the threshold Qin) may be defined based on the frequency used, the subcarrier interval, the type of service, and the like. Further, the first specific ratio and/or the second specific ratio may be predetermined values defined in the specifications. Further, the first specific percentage and/or the second specific percentage may be values notified or broadcast from the base station device to the terminal device.

A terminal device may perform radio link monitoring in a serving cell (eg, PCell and/or PSCell) using some type of reference signal (eg, cell-specific reference signal (CRS)). Further, the terminal device receives a setting (RadioLink Monitoring Config) indicating which reference signal is used for radio link monitoring in the serving cell (for example, PCell and/or PSCell) from the base station device, and selects one or more of the configured reference signals. Radio link monitoring may be performed using multiple reference signals (referred to here as RLM-RS). Furthermore, the terminal device may perform wireless link monitoring using other signals. The physical layer processing unit of the terminal device may notify the upper layer that the synchronization is in progress when the serving cell (for example, PCell and/or PSCell) satisfies the conditions for the synchronization to be in progress.

The wireless link monitoring settings may include information indicating a purpose of monitoring and identifier information indicating a reference signal. For example, monitoring purposes may include monitoring for wireless link failures, beam failures, or both. Further, for example, the identifier information indicating the reference signal may include information indicating an identifier (SSB-Index) of a synchronization signal block (SSB) of a cell. That is, the reference signal may include a synchronization signal. Further, for example, the identifier information indicating the reference signal may include information indicating an identifier linked to a channel state information reference signal (CSI-RS) set in the terminal device.

In the primary cell, the RRC layer processing unit of the terminal device starts or restarts the timer (T310) when it consecutively receives out-of-synchronization notifications from the physical layer processing unit a predetermined number of times (N310 times). (Restart). Further, the RRC layer processing unit of the terminal device may stop the timer (T310) when it receives a synchronizing message consecutively a predetermined number of times (N311 times). The RRC layer processing unit of the terminal device may perform a transition to an idle state or a procedure for re-establishing an RRC connection when the timer (T310) expires. For example, the operation of the terminal device may differ depending on the establishment state of AS Security. If AS Security has not been established, the terminal device may transition to the RRC IDLE state, and if AS Security has been established, the terminal device may perform an RRC connection re-establishment procedure. Furthermore, in determining whether to start or restart the timer T310, a condition may be added that none of the timer T300, timer T301, timer T304, and timer T311 is running.

FIG. 9 shows an example of conditions for starting, stopping, and expiring each of the timers of EUTRA. Note that similar conditions may be applied to NR, although the timer name and/or message name may be different.

In addition, in the primary secondary cell, the RRC layer processing unit of the terminal device starts a timer (T313) or It may be restarted. Further, the RRC layer processing unit of the terminal device may stop the timer (T313) when it receives a synchronizing message consecutively a predetermined number of times (N314 times). The RRC layer processing unit of the terminal device may execute an SCG failure information procedure for notifying the network of an SCG failure when the timer (T313) expires.

In addition, in SpCell (PCell in MCG and PSCell in SCG), if the RRC layer processing unit of the terminal device receives a predetermined number of consecutive times (N310 times) of out of synchronization notified from the physical layer processing unit in each SpCell, The timer (T310) of the SpCell may be started or restarted. Further, the RRC layer processing unit of the terminal device may stop the timer (T310) of the SpCell when it receives synchronization in progress a predetermined number of times (N311 times) in each SpCell. When the timer (T310) of each SpCell expires, the RRC layer processing unit of the terminal device performs a transition to an idle state or a procedure for re-establishing an RRC connection if the SpCell is a PCell. Good too. Further, if the SpCell is a PSCell, an SCG failure information procedure for notifying the network of an SCG failure may be executed.

The above explanation is an example in which discontinuous reception (DRX) is not set in the terminal device. When DRX is configured on the terminal device, the RRC layer processing unit of the terminal device physically controls the period for measuring radio link quality and the notification interval to the upper layer to take different values than when DRX is not configured. It may also be set for the layer processing section. Note that even when DRX is set, when the timers (T310, T313) are running, the period for measuring the radio link quality to estimate synchronization and the notification interval to the upper layer are set. It may also be a value when DRX is not set.

For example, in order to detect an early physical layer problem, the RRC layer processing unit of the terminal device may set a timer to (T314) may be started. Further, the RRC layer processing unit of the terminal device may stop the timer (T314) when it receives synchronization in progress a predetermined number of times (N311 times) while T314 is running.

For example, in order to detect early physical layer improvement, the RRC layer processing unit of the terminal device may set a timer to (T315) may be started. Further, the RRC layer processing unit of the terminal device may stop the timer (T315) when it receives synchronization in progress a predetermined number of times (N311 times) while T315 is running.

Also, for example, when reporting measurements to the base station device, if the measurement settings are set to perform the first measurement (for example, to perform measurement using timer T312), if timer T310 is running If the timer T312 is not running, start the timer T312. The RRC layer processing unit of the terminal device may stop the timer (T312) when it receives a synchronizing message consecutively a predetermined number of times (N311 times).

Further, the RLM-RS may be undefined if it is not explicitly or implicitly set by the network. That is, the terminal device does not need to monitor the radio link if the RLM-RS is not configured from the network (for example, the base station device).

Further, the RLM-RS is a reference signal used in radio link monitoring, and a plurality of RLM-RSs may be set in the terminal device. One RLM-RS resource may be one SS block or one CSI-RS resource (or port).

Further, radio link monitoring using CRS may be performed in the EUTRA cell, and radio link monitoring using RLM-RS may be performed in the NR cell, but the present invention is not limited thereto.

Detection of wireless link failure based on wireless link monitoring will be described.

The terminal device is notified of a random access problem by the MAC layer of the MCG when timer T310 expires, when timer T312 expires, or when none of a plurality of specific timers are running. , or when notified from the RLC layer of the MCG that SRB or DRB retransmissions have reached the maximum number of retransmissions, the terminal device determines that a wireless link failure has been detected in the MCG. The specific timers do not include timer T310 and timer T312.

The problem with random access is that when the number of random access preamble retransmissions reaches a predetermined number in the MAC entity, if the random access preamble transmission was performed in the SpCell, the MAC entity of the cell group that includes that SpCell The information may be notified to an upper layer (RRC entity here).

When the terminal device determines that a wireless link failure has been detected in the MCG, the terminal device stores various information as wireless link failure information. If the security of the AS is not activated, the release reason is set to "other" and the process of leaving RRC_CONNECTED is started. If AS security is activated, initiate the RRC connection re-establishment procedure.

The terminal device is notified when the timer T313 expires, or when the MAC layer of the SCG is notified of a random access problem, or when the RLC layer of the SCG is notified that the maximum number of retransmissions has been reached. , the terminal device determines that a wireless link failure has been detected in the SCG, and starts processing to report information related to the SCG wireless link failure to the base station device.

When the timer T314 expires, the terminal device determines that an "early out of synchronization" event has been detected, and starts processing to report related information to the base station device.

When the timer T315 expires, the terminal device determines that the "early synchronization" event has been detected, and starts processing to report related information to the base station device.

The RRC connection re-establishment procedure will be explained.

The purpose of the RRC connection re-establishment procedure is to re-establish the RRC connection, and may involve a SRB1 recovery procedure, security reactivation, and PCell-only configuration.

The RRC connection re-establishment procedure may be started when any of the following conditions (A) to (E) are met.
(A) When a wireless link failure in MCG is detected (B) When handover fails (in NR, when reconfiguration with synchronization in MCG fails)
(C) When mobility to another RAT fails (D) When a failure of integrity check related to SRB1 or SRB2 is notified from the lower layer (E) When reconfiguration of RRC connection fails time

When the RRC connection re-establishment procedure is started, the terminal device executes some or all of the following processes (A) to (J).
(A) If timer T310 is running, stop timer T310. (B) If timer T312 is running, stop timer T312. (C) If timer T313 is running, stop timer T313. (C) If timer T314 is running, stop timer T314 (D) Start timer T311 (E) Suspend all RBs except SRB0 (F) Reset MAC (G ) Release the MCG's SCell if configured (H) Apply the default physical channel configuration (I) Apply the default MAC main configuration to the MCG (J) Execute the cell selection procedure

When the optimal cell of the same RAT is selected by the cell selection procedure, the terminal device performs the following processing.

If the terminal device is connected to 5GC and the selected cell can be connected only with EPC, or if the terminal device is connected to EPC and the selected cell can only be connected with 5GC, set the release reason as "RRC connection failure". , and executes an action to leave RRC_CONNECTED. Otherwise, it stops timer T311, starts timer T301, and starts sending an RRC connection reestablishment request message.

When the timer T311 expires, the terminal device sets the release reason as "RRC connection failure" and executes an action to leave RRC_CONNECTED.

If the timer T301 expires, or if the selected cell is no longer the optimal cell in terms of cell selection criteria, the terminal device performs an action to leave RRC_CONNECTED with the release reason as "RRC connection failure".

Handover will be explained.

In EUTRA, an example of processing related to handover between the same RATs (that is, between EUTRAs) will be described using FIG. 7. The explanation using FIG. 7 is an example, and some processes may be omitted or other processes may be included. Alternatively, another process may be performed as the process related to handover.

In FIG. 7, the handover source base station device (Source eNB) configures the terminal device to measure adjacent cells (step S701).

The terminal device performs the measurement set by the Source eNB, and reports the measurement result to the Source eNB based on the reporting conditions (Step S702).

The Source eNB determines handoff of the terminal device based on information such as the reported measurement results (step S703).

The Source eNB issues a handover request message containing information necessary for handover preparation to the base station device (Target eNB) that is the handover destination (step S704).

Admission control may be performed at the Target eNB. Target eNB configures the required resources. (Step S705).

The Target eNB sends a handover request acknowledgment message (HANDOVER REQUEST ACKNOWLEDGE message) to the Source eNB (step S706). The handover request approval message includes a container that is transparently sent to the terminal device as an RRC message for performing the handover. The container contains some or all of the following: the new C-RNTI, the Target eNB's security algorithm identifier for the selected security algorithm, the dedicated random access channel preamble (Random Access Preamble), and the target cell's system information. may be included.

The Source eNB receives the container (mobility control information) information element (Information) received from the Target eNB.
A first RRC connection reconfiguration message (RRCConnectionReconfiguration message) containing Element:IE) is sent to the terminal device (step S707).

Note that when a make-before-break handover (Make-Before-Break HO: MBB-HO) is configured by the first RRC connection reconfiguration message, the terminal device receives the first RRC connection reconfiguration message. After that, the connection with the Source eNB is maintained at least until the Target eNB performs the first uplink transmission. Note that the above-mentioned make-before-break handover may be selected from a plurality of settings. For example, it may be determined that the make-before-break handover has been set by setting the field makeBeforeBreak-r14 included in the already specified mobilityControlInfo information element to True. Further, for example, it may be determined that the make-before-break handover has been set by including newly defined makeBeforeBreak-r16 in the field of the mobilityControlInfo information element and setting makeBeforeBreak-r16 to True. Further, the field makeBeforeBreak-r16 may take an information element including various settings as a value.

The Source eNB sends an SN STATUS TRANSFER message to the Target eNB to convey the reception status of the uplink PDCP sequence number and the transmission status of the downlink PDCP sequence number (step S708).

If RACH-less handover is not configured by the first RRC connection reconfiguration message, the terminal device performs synchronization with the Target eNB and accesses the target cell using the random access channel. do. At this time, if a dedicated random access preamble is indicated by the first RRC connection reconfiguration message, a contention-free random access procedure is executed, and if it is not indicated, a contention-free random access procedure is executed. (Contention-based) random access procedure is executed. If RACH-less handover is configured by the first RRC connection reconfiguration message, the terminal device performs synchronization with the Target eNB (step S709).

If RACH-less handover has not been configured by the first RRC connection reconfiguration message, the Target eNB returns uplink allocation and timing advance information to the terminal device (step S710).

If RACH-less handover is configured by the first RRC connection reconfiguration message, and periodic pre-allocated uplink grant is obtained by the first RRC connection reconfiguration message. If not, the terminal device receives an uplink grant via the PDCCH of the target cell. The terminal device uses the first available uplink grant after synchronizing with the target cell (step S710a).

When RACH-less handover is not configured and the terminal device successfully accesses the target cell, the terminal device sends an RRC Connection Reconfiguration Complete message to the Target eNB in order to confirm the handover. send to This RRC connection reconfiguration completion message indicates the completion of the handover procedure of the terminal device. The RRC connection reconfiguration completion message includes the C-RNTI, and the Target eNB verifies the C-RNTI of the received RRC connection reconfiguration completion message.

When RACH-less handover is configured and the terminal device receives an uplink grant, the terminal device sends an RRC Connection Reconfiguration Complete message to the Target eNB in order to confirm the handover. . The RRC connection reconfiguration completion message includes the C-RNTI, and the Target eNB verifies the C-RNTI of the received RRC connection reconfiguration completion message. When the terminal device receives a UE contention resolution identity MAC control element from the Target eNB, the handover procedure of the terminal device is completed (step S711).

The Target eNB sends a path switch request (PATH SWITCH REQUEST) message to the MME to notify that the terminal device has changed cells (step S712).

The MME sends a MODIFY BEARER REQUEST message to the serving gateway (S-GW) (step S713).

The S-GW switches the downlink data path to the target side. The S-GW sends one or more end marker packets to the Source eNB and releases user plane resources to the Source eNB (step S714).

The S-GW sends a MODIFY BEARER RESPONSE message to the MME (step S715).

The MME confirms the path switching request using a path switching request acknowledgment (PATH SWITCH REQUEST ACKNOWLEDGE) message (step S716).

The Target eNB sends a UE context release (UE
CONTEXT RELEASE) message to indicate a successful handover and trigger the release of resources by the Source eNB. The Target eNB may send this message after receiving the path switching request approval message (step S717).

The Source eNB may release radio and C-plane related resources for the UE context upon receiving the UE context release message. The ongoing data transfer may be continued (step S718).

When the timer T304 expires, the terminal device executes some or all of the following processes (A) to (D).
(A) deeming the dedicated random access channel configuration configured by the first RRC connection reconfiguration message to be unavailable; (B) determining the dedicated physical channel configuration and the MAC layer primary configuration; and Return the terminal device settings to the settings used in the handover source PCell, excluding semi-persistent schedule settings. (C) Accumulate related information as handover failure information ( D) Start the RRC connection re-establishment procedure and end the RRC connection re-establishment procedure.

Details of the processing of the terminal device that received the first RRC connection reconfiguration message will be described. The first RRC connection reconfiguration message may include a mobility control information (mobilityControlInfo) information element. The mobilityControlInfo information element includes parameters related to network-controlled mobility from other RATs to EUTRA or within EUTRA (for example, target cell identifier and carrier frequency information).

If the terminal device receives an RRC connection reconfiguration message (first RRC connection reconfiguration message) containing the mobilityControlInfo information element and is able to comply with the configuration of the message, the terminal device performs the following (A) to (G). Perform some or all of the processing.
(A) If timer T310 is running, stop timer T310. (B) If timer T312 is running, then stop timer T312. (C) If timer T314 is running, stop timer T314. (D) Start timer T304 with the value (t304) included in the mobilityControlInfo information element. (E) If carrier frequency information is included, that frequency is determined to be the frequency of the target cell, and the carrier frequency information is If not included, determine the frequency of the source PCell as the frequency of the target cell (F) If the access restriction timer is running, stop that timer (G) Synchronize with the downlink of the target cell start

In NR, an example of processing related to handover between the same RATs (that is, between NRs) will be described using FIG. 8. The explanation using FIG. 8 is an example, and some processes may be omitted or other processes may be included. Alternatively, another process may be performed as the process related to handover.

In FIG. 8, the handover source base station device (Source gNB) configures the terminal device to measure adjacent cells, and the terminal device performs the measurement configured from the Source gNB and reports the measurement results to the Source gNB (step S801).

The Source gNB determines handoff of the terminal device based on information such as the reported measurement results (step S802).

The Source gNB issues a handover request message containing information necessary for handover preparation to the base station device (Target gNB) that is the handover destination (step S803).

Admission control may be performed by the Target gNB (step S804).

The Target gNB prepares for handover and sends a HANDOVER REQUEST ACKNOWLEDGE message to the Source gNB (step S805). The handover request approval message includes a container that is transparently sent to the terminal device as an RRC message for performing the handover.

The Source gNB sends the container (first RRC Reconfiguration message) received from the Target gNB to the terminal device (Step S806). The RRC reconfiguration message includes the target cell identifier, the new C-RNTI, the Target gNB's security algorithm identifier for the selected security algorithm, the set of dedicated random access channel resources, and the UE-specific CSI-RS. configuration, common random access channel resources, and target cell system information.

Note that when a make-before-break handover (Make-Before-Break HO: MBB-HO) is set by the first RRC reconfiguration message, the terminal device performs the following after receiving the first RRC reconfiguration message. , the connection with the Source gNB may be maintained at least until the Target gNB performs the first uplink transmission.

The Source eNB sends an SN STATUS TRANSFER message to the Target gNB to convey the reception status of the uplink PDCP sequence number and the transmission status of the downlink PDCP sequence number (step S807).

If RACH-less handover is not configured by the first RRC reconfiguration message, the terminal device performs synchronization with the Target eNB and accesses the target cell using the random access channel. . At this time, if a dedicated random access preamble is indicated by the first RRC reconfiguration message, a contention-free random access procedure is executed, and if it is not indicated, a contention-free random access procedure is executed. A contention-based) random access procedure may be performed. If RACH-less handover is configured by the first RRC reconfiguration message, the terminal device performs synchronization to the Target gNB.

If RACH-less handover has not been configured by the first RRC reconfiguration message, the Target gNB may return uplink allocation and timing advance information to the terminal device.

If RACH-less handover is configured by the first RRC reconfiguration message and a periodic pre-allocated uplink grant is not obtained by the first RRC reconfiguration message. If not, the terminal device receives an uplink grant via the PDCCH of the target cell. The terminal device uses the first available uplink grant after synchronizing with the target cell.

When RACH-less handover is not configured and the terminal device successfully accesses the target cell, the terminal device sends an RRC Reconfiguration Complete message to the Target gNB to confirm the handover. You can send it. This RRC reconfiguration complete message may indicate the completion of the handover procedure of the terminal device. The RRC reconfiguration complete message includes a C-RNTI, and the Target gNB may verify the C-RNTI of the received RRC reconfiguration complete message.

When RACH-less handover is configured and the terminal device receives an uplink grant, the terminal device may send an RRC Reconfiguration Complete message to the Target gNB to confirm the handover. . The RRC reconfiguration complete message includes a C-RNTI, and the Target gNB may verify the C-RNTI of the received RRC reconfiguration complete message. The handover procedure of the terminal device may be completed when the terminal device receives a UE contention resolution identity MAC control element from the Target gNB (step S808).

The Target eNB sends a path switch request (PATH SWITCH REQUEST) message to the AMF in order to have the 5GC switch the downlink data path to the Target gNB and establish an NG-C interface instance to the Target gNB (step S809).

5GC switches the downlink data path to Target gNB. The UPF sends one or more end marker packets to the Source eNB and
Release user plane resources to gNB (step S810).

The AMF confirms the path switching request using a path switching request acknowledgment (PATH SWITCH REQUEST ACKNOWLEDGE) message (step S811).

The Target gNB sends a UE context release (UE
CONTEXT RELEASE) message to indicate the success of the handover and trigger the release of resources by the Source gNB. The Target gNB may send this message after receiving the Path Switch Request Acceptance message from the AMF. The Source gNB may release radio and C-plane related resources for the UE context upon receiving the UE context release message. The ongoing data transfer may be continued (step S812).

When the timer T304 expires, the terminal device executes some or all of the following processes (A) to (D).
(A) If the MCG's timer T304 expires, release the configuration of the MCG's dedicated random access channel configured by the first RRC connection reconfiguration message. (B) If the MCG's timer T304 expires, Return the settings of the terminal device to the settings used in the handover source PCell (D) If the timer T304 of the MCG expires, start the RRC connection re-establishment procedure (E) If the timer T304 of the SCG expires Once expired, release the SCG dedicated random access channel configuration configured by the first RRC connection reconfiguration message. (E) If the SCG timer T304 expires, the SCG synchronous reconfiguration has failed. Begin the process of reporting

The details of the processing of the terminal device that received the first RRC reconfiguration message will be explained.
The first RRC reconfiguration message may include a reconfiguration with synchronization (reconfigurationWithSync) information element. The reconfigurationWithSync information element may be included in the SpCell configuration for each cell group (MCG or SCG) in the RRC reconfiguration message. The reconfigurationWithSync information element includes parameters related to reconfiguration with synchronization to the target SpCell (eg, target SpCell configuration, new identifier of the terminal device, etc.).

A terminal device that receives an RRC reconfiguration message (first RRC reconfiguration message) including the reconfigurationWithSync information element performs some or all of the following processes (A) to (E).
(A) If security is not activated, set the release reason to "other" and start the process of leaving RRC_CONNECTED. The process of leaving RRC_CONNECTED may be the process of going to RRC_IDLE.
(B) If the timer T310 of the target SpCell is running, stop the timer T310 of the target SpCell. (C) Start the timer T304 of the target SpCell with the value (t304) included in the reconfigurationWithSync information element. (D) If downlink frequency information is included, that frequency is determined to be the SSB frequency of the target cell, and if downlink frequency information is not included, the SSB frequency of the source SpCell is determined. Determine the frequency as the SSB frequency of the target cell (E) Start synchronization to the target cell's downlink

As mentioned above, in EUTRA and/or NR, when make-before-break handover (Make-Before-Break HO: MBB-HO) is configured for a terminal device, the terminal device The connection with the Source eNB or Source gNB is maintained until link transmission is performed. Currently, timer T310 stops when the first RRC connection reconfiguration message or the first RRC reconfiguration message is received. Therefore, in the subsequent serving cell (source cell) of the Source eNB or Source gNB, the terminal device cannot determine whether or not the situation is considered to be a wireless link failure due to a physical layer problem. Additionally, if the timer T304 is running, it is determined whether or not the serving cell (source cell) of the Source eNB or Source gNB is in a situation where a wireless link failure is considered to be due to a random access problem notified from the MAC layer. The terminal device cannot make a decision. Furthermore, in the source cell, when the maximum number of RLC retransmissions is reached, it is considered that the radio link has failed, and an RRC connection re-establishment procedure is executed.

Next, conditional handover will be explained. In NR, conditional handover includes an information element (conditional handover setting) that includes the information included in the reconfiguration information element with synchronization, and information indicating the conditions for applying the information element (conditional handover condition). It may be RRC reconfiguration using an RRC reconfiguration message. In LTE, conditional handover refers to RRC that includes an information element (conditional handover configuration) that includes information included in the mobility control information information element and information that indicates the conditions for applying the information element (conditional handover condition). It may be an RRC connection reconfiguration using a connection reconfiguration message.

In NR, the conditional handover settings may include some or all of the settings (A) to (F) below.
(A) Cell group configuration information (CellGroupConfig)
(B) Information indicating whether it is fully configured (C) NAS layer message (D) System information (E) Measurement settings (F) Radio bearer settings

The cell group configuration information may include some or all of the settings (1) to (6) below.
(1) Cell group identifier (2) RLC bearer information (3) Cell group MAC layer configuration information (4) Cell group physical (PHY) layer configuration information (5) SpCell configuration information (relay with synchronization) (may include configuration information elements)
(6) SCell information

Further, the radio bearer settings may include some or all of the following settings (1) to (3).
(1) SRB settings (2) DRB settings (3) Security settings (for example, information about the integrity protection algorithm and encryption algorithm for SRB and/or DRB (securityAlgorithmConfig), whether the master (MCG) or secondary (SCG) information indicating whether to use the key (keyToUse, etc.)

In LTE, the conditional handover configuration may include some or all of the configurations (A) to (E) below.
(A) Measurement settings (B) Mobility control information information elements (C) NAS layer messages (D) Radio resource settings (E) Security settings (e.g. regarding integrity protection algorithms and encryption algorithms for SRB and/or DRB) Information (SecurityAlgorithmConfig))

The radio resource settings may include some or all of the settings (1) to (4) below.
(1) SRB information (2) DRB information (3) Cell group MAC layer configuration information (4) Cell group physical (PHY) layer configuration information

In LTE and/or NR, conditional handover conditions may include some or all of the conditions (A) to (D) below.
(A) The handover destination (target) cell has become better than the current (source) PCell plus the offset. (B) The handover destination (target) cell has become better than a certain threshold and the PCell has become better than the current (source) PCell with an offset. (C) The handover destination (target) cell has become better than a certain threshold (D) No conditions (execute immediately)

For comparison under the above conditional handover conditions, RSRP is used as quantity,
RSRQ and/or RS-SINR may be used. Further, which amount to use may be set from the network. Further, information indicating which amount to use may be included in the conditional handover condition.

The conditional handover setting and/or the information element indicating the conditional handover condition may be included as part of the RRC message at the handover source, or a container (information storing a bit string) included in the RRC message may be included. element).

Various embodiments of the present invention will be described based on the above description. Note that each process explained above may be applied to each process omitted in the following description.

An example will be shown in which MBB-HO is efficiently performed by changing the procedure related to wireless link monitoring in MBB-HO.

First, the RRC layer processing unit of the UE 122 receives the physical layer processing unit from the physical layer processing unit in the primary cell (PCell), which is the SpCell of the MCG, under a specific condition (first condition), regardless of whether or not the timer T304 is running. The timer (T310) may be started or restarted when the notified out-of-synchronization is received a predetermined number of times (N310 times) in succession. Further, the RRC layer processing unit of the UE 122 may stop the timer (T310) when it receives a synchronizing message consecutively a predetermined number of times (N311 times). Furthermore, in determining whether to start or restart the timer T310, the condition may be added that none of the timer T300, timer T301, and timer T311 is running.

The RRC layer processing unit of the UE 122 determines that a wireless link failure has been detected in the MCG when any of the following conditions (A) to (E) is satisfied.
(A) When timer T310 expires (B) When timer T312 expires (C) When none of timer T300, timer T301, timer T304, and timer T311 are running, from the MAC entity of MCG (D) Under the first condition, while timer T304 is running, an indication of a random access problem is received from the MAC entity of the MCG. (E) SRB or when a notification is received from the RLC layer of the MCG indicating that DRB retransmissions have reached the maximum number of retransmissions.

The first condition may be that makeBeforeBreak-r16 is set in the UE 122. The fact that makeBeforeBreak-r16 is set may mean that, for example, in the case of EUTRA, the UE 122 receives an RRC connection reconfiguration message in which makeBeforeBreak-r16 is included in the field of the mobilityControlInfo information element. Furthermore, the fact that makeBeforeBreak-r16 is set may mean that, for example, in the case of NR, makeBeforeBreak-r16 receives an RRC reconfiguration message included in the field of the reconfiguration information element with synchronization. Furthermore, makeBeforeBreak-r16 is not set, for example, in the case of EUTRA, the UE 122 may receive an RRC connection reconfiguration message in which makeBeforeBreak-r16 is not included in the field of the mobilityControlInfo information element. Also, the fact that makeBeforeBreak-r16 is not set means that, for example, in the case of EUTRA, the UE 122 sets makeBeforeBreak-r1 whose value is False.
6. The RRC connection reconfiguration message may be received. Further, the fact that makeBeforeBreak-r16 is not set may mean, for example, in the case of NR, receiving an RRC reconfiguration message in which makeBeforeBreak-r16 is not included in the field of the reconfiguration information element with synchronization.

Further, the fact that makeBeforeBreak-r16 is set means that, for example, in the case of EUTRA, the UE 122 receives an RRC connection reconfiguration message in which makeBeforeBreak-r16 is included in the radio resource configuration (radioBearerConfigDedicated) information element specific to the terminal device. It's fine. Further, the fact that makeBeforeBreak-r16 is configured may mean that, for example, in the case of NR, makeBeforeBreak-r16 receives an RRC reconfiguration message included in a field of a data radio bearer configuration information element.

makeBeforeBreak-r16 may have, for example, an enumerated type value that includes true, or may have an information element that includes information necessary for make-before-break handover as a value.

Further, the condition (E) may be the following (E2).
(E2) When a notification indicating that the SRB or DRB retransmission has reached the maximum number of retransmissions is received from the RLC layer of the MCG while none of the timers T300, T301, T304, and T311 are running; or under the first condition, when timer T304 is running and a notification is received from the RLC layer of the MCG indicating that the SRB or DRB retransmission has reached the maximum number of retransmissions;

When the UE 122 determines that a wireless link failure has been detected in the MCG, the UE 122 stores various information as wireless link failure information. If the security of the AS is not activated, the release reason may be set to "other" and the process of leaving RRC_CONNECTED may be started.

Also, if AS security is activated, if under the first condition, suspend transmission of some or all of the SRB and/or DRB of the MCG, and reset the MAC entity of the MCG. It's fine.

Also, if AS security is activated, an RRC connection re-establishment procedure may be initiated, if not under the first condition.

The RRC connection re-establishment procedure may be started when any of the following conditions (A) to (E) are met.
(A) When an MCG wireless link failure is detected when the first condition is not met (B) When handover fails (in NR, when reconfiguration with synchronization in MCG fails)
(C) When mobility to another RAT fails (D) When a failure of integrity check related to SRB1 or SRB2 is notified from the lower layer (E) When reconfiguration of RRC connection fails time

Furthermore, when any of the above conditions is met, if the first condition is that the handover source MCG has not detected a wireless link failure, the handover is performed without starting the RRC connection re-establishment procedure. A procedure may be initiated to notify the handover source MCG of the failure.

If the first condition is that makeBeforeBreak-r16 is set in the UE 122, it is set when the timer T304 expires or when the procedure for notifying the handover failure in the handover source MCG is started. makeBeforeBreak-r16 may be released.

When the RRC connection re-establishment procedure is started, the UE 122 executes some or all of the following processes (A) to (J).
(A) If timer T310 is running, stop timer T310. (B) If timer T312 is running, stop timer T312. (C) If timer T313 is running, stop timer T313. (C) If timer T314 is running, stop timer T314 (D) Start timer T311 (E) Suspend all RBs except SRB0 (F) Reset MAC (G ) Release the MCG's SCell, if configured. (H) Apply the default physical channel configuration. (I) Apply the default MAC main configuration to the MCG. (J) Perform the cell selection procedure.

Next, in the handover process, after the UE 122 transmits an RRC connection reconfiguration completion message or an RRC reconfiguration completion message to the target cell, the MCG after handover (also referred to as Target MCG or Current MCG) and the MCG of the handover source are transmitted. The case of transmitting and receiving data via both cell groups with (Source MCG) (operating with dual protocol stack) is being considered. An example of processing in that case is shown below. Note that the following processing is not limited to the case of dual protocol stack, but can be applied to other cases as well.

First, in the primary cell that is the SpCell of the Source MCG, the RRC layer processing unit of the UE 122 determines whether or not the timer T304 of the Source MCG is running under a specific condition (first condition). When the out-of-synchronization notification from the layer processing unit is received consecutively a predetermined number of times (N310 times), the timer (T310) of the Source MCG may be started (Start) or restarted (Restart). Further, the RRC layer processing unit of the UE 122 may stop the timer (T310) when receiving synchronization in progress a predetermined number of times (N311 times) from the physical layer processing unit of the Source MCG. Further, in determining whether to start or restart the timer T310, a condition may be added that none of the source MCG timer T300, the source MCG timer T301, and the source MCG timer T311 are running.

The RRC layer processing unit of the UE 122 determines that a radio link failure has been detected in the Source MCG when any of the following conditions (A) to (E) are satisfied.
(A) When timer T310 of Source MCG expires (B) When timer T312 of Source MCG expires (C) When timer T300, timer T301, timer T304, and timer T311 of Source MCG all run. (D) Under the first condition, when timer T304 of the Source MCG is running, an indication of a random access problem is received from the MAC entity of the Source MCG. (E) When a notification is received from the RLC layer of the Source MCG indicating that SRB or DRB retransmissions have reached the maximum number of retransmissions.

The first condition may be that makeBeforeBreak-r16 is set in the UE 122.

Further, the first condition may be that either makeBeforeBreak-r14 or makeBeforeBreak-r16 is set in the UE 122.

Further, the condition (E) may be the following (E2).
(E2) When none of the timers T300, T301, T304, and T311 of the Source MCG are running, the RLC layer of the Source MCG sends a notification indicating that SRB or DRB retransmissions have reached the maximum number of retransmissions. or under the first condition, when timer T304 is running, when a notification is received from the RLC layer of the Source MCG indicating that the maximum number of SRB or DRB retransmissions has been reached.

When the UE 122 determines that a radio link failure is detected in the Source MCG, the UE 122 may suspend transmission of some or all of the SRB and/or DRB of the Source MCG, and reset the MAC entity of the Source MCG.

When makeBeforeBreak-r16 is set in the Current MCG, the UE 122 may consider the MCG to be the Source MCG.

Further, the UE 122 may consider the handover source MCG to be the Source MCG when the first uplink grant is allocated by PDCCH in the handover destination cell.

Furthermore, when transmitting the RRC reconfiguration completion message, the UE 122 may consider the handover source MCG to be the Source MCG.

Furthermore, when the UE 122 receives a UE contention resolution identity MAC control element from the Target gNB, the UE 122 may consider the handover source MCG to be the Source MCG.

Furthermore, if a Source MCG already exists when makeBeforeBreak-r16 is set in the Current MCG, the UE 122 may release this MCG and consider the Current MCG as a new Source MCG.

In this way, the process of detecting the radio link failure of the Source MCG and the
By distinguishing the MCG from the radio link failure detection processing, unnecessary re-establishment processing in MBB-HO can be prevented and efficient mobility can be achieved.

An example of the operation of MBB-HO will be explained. Here, an example is shown in which an RRC reconfiguration message including CellGroupConfig including a reconfiguration information element with synchronization is used in NR. Note that in the description of each process below, there is a description that an information element is received, but unless otherwise specified, this may mean that the information element is included in the RRC reconfiguration message that triggered each process. . Furthermore, the information elements used in each process may be associated with the information elements used in Non-Patent Document 10, unless otherwise specified.

The terminal device executes processing A based on the received CellGroupConfig information element. Further, the terminal device executes processing L based on the received masterKeyUpdate information element. Further, the terminal device executes processing I based on the received RadioBearerConfig information element.

Note that each item of each process described below is given an indentation and a code. For example, processing A, processing B, processing C, and processing H are interpreted to have the flows shown in FIGS. 16, 17, 18, and 19, respectively, and other processing is similarly interpreted.

(Processing A) The following processing is performed based on the received CellGroupConfig information element.
(A-0) If CellGroupConfig includes SpCell configuration information (spCellConfig information element) that includes reconfiguration information with synchronization, and the reconfiguration information with synchronization includes information indicating that this RRC reconfiguration is MBB-HO ( For example, if MakeBeforeBreak-r16) is included,
(A-0-1) The current terminal device settings (source settings) may be copied and used as the target settings, and the following processing may be performed on the copied target settings unless otherwise specified. . For example, in the case of MBB-HO, the "current terminal device settings" of each process may be considered to be the "current terminal device target settings." For example, the settings to be duplicated include (1) bearer settings (for example, SRB settings, DRB settings, etc.), (2) cell group settings (for example, SpCell settings, SCell settings, settings for each entity, etc.). ), (3) variables held within the terminal device (measurement settings (VarMeasConfig), measurement results (VarMeasReportList), timers, counters, etc.), (4) security-related settings (for example, each key), or All may be included. Further, the configuration of the bearer to be duplicated may not include the configuration regarding SRB. That is, for DRB, both source settings and target settings may be managed, and for SRB, settings may be switched from source settings to target settings without duplicating the settings. Further, information that allows it to be determined whether or not to duplicate the SRB configuration may be included in the RRC reconfiguration message including reconfiguration with synchronization. For example, the information may be included in MakeBeforeBreak-r16.
(A-1) If CellGroupConfig includes SpCell configuration information (spCellConfig information element) including synchronized reconfiguration information (A-1-1) Process B described later is executed.
(A-1-2) If in a suspended state, resume all suspended radio bearers and resume transmission on the SCG for all radio bearers.
(A-2) If CellGroupConfig includes a list of RLC bearers to be released (rlc-BearerToReleaseList information element) (A-2-1) Process C described below is executed.
(A-3) If CellGroupConfig includes a list of RLC bearers to be added and/or modified (rlc-BearerToAddModList information element),
(A-3-1) Execute processing D, which will be described later.
(A-4) If CellGroupConfig includes the MAC settings of the cell group (mac-CellGroupConfig information element),
(A-4-1) Configure the MAC entity of this cell group in process E, which will be described later. Note that in each embodiment of the present invention, "configuring" the terminal device using the information element included in the RRC message may mean applying information included in the information element to the configuration of the terminal device.
(A-5) If CellGroupConfig includes a list of SCells to be released (sCellToReleaseList information element) (A-5-1) The SCells are released in process F described later.
(A-6) If CellGroupConfig includes SpCell configuration information (spCellConfig information element),
(A-6-1) SpCell is set in process G, which will be described later.
(A-7) If CellGroupConfig includes a list of SCells to be added and/or modified (sCellToAddModList information element) (A-7-1) Addition and/or modification of SCells is executed in process H described later.

(Processing B)
(B-1) If the security of the AS has not been activated, the process of transitioning to RRC_IDLE is executed and process B is ended.
(B-2) If it is running, stop the timer T310 of the corresponding SpCell.
(B-3) Start the timer T304 of the corresponding SpCell with the timer value of t304 included in the reconfiguration with synchronization.
(B-4) If frequency information (frequencyInfoDL) is included,
(B-4-1) The target SpCell is considered to be a cell with the SSB frequency indicated by frequencyInfoDL and the physical cell identifier indicated by the physical cell identifier information (physCellId) included in the reconfiguration with synchronization.
(B-5) Otherwise,
(B-5-1) The target SpCell is considered to be a cell with the physical cell identifier indicated by the physical cell identifier information (physCellId) included in the reconfiguration with synchronization at the SSB frequency of the source SpCell.
(B-6) Start synchronization of the target SpCell with the downlink.
(B-7) Apply default BCCH settings.
(B-8) If necessary, obtain a master information block (MIB), which is one of the broadcast information.
(B-9) If the reconfiguration with synchronization includes information indicating that it is MBB-HO,
(B-9-1) If there is no MAC entity in the target cell group,
(B-9-1-1) Generate a MAC entity for a target cell group (also simply referred to as a target MAC entity).
(B-9-2) Apply default MAC cell group settings to the target MAC entity.
(B-9-3) If set, consider the SCell of the target cell group to be in a deactivated state.
(B-9-4) Apply the value of newUE-Identity as the C-RNTI of the target cell group.
(B-10) Otherwise,
(B-10-1) Reset the MAC entity of this cell group.
(B-10-2) If set, consider the SCell of this cell group to be in a deactivated state.
(B-10-3) Set the value of newUE-Identity to C- of this cell group.
Apply as RNTI.
(B-11) Configure the lower layer based on the SpCell configuration (spCellConfigCommon) included in the reconfiguration with synchronization.
(B-12) If necessary, configure the lower layer based on other information included in the reconfiguration with synchronization.

(Processing C)
(C-1a) For each logical channel identifier (logicalChannelIdentity) value that is part of the current terminal device configuration and included in the rlc-BearerToReleaseList, or (C-1b) As a result of the release of the SCG, For each logical channel identifier value that is released,
(C-1-1) Release the corresponding logical channel and the RLC entity linked to the logical channel.

(Processing D)
The following processing is performed for each RLC bearer configuration (RLC-BearerConfig) included in the received rlc-BearerToAddModList information element.
(D-1) If the current terminal device settings include the RLC bearer of the received logical channel identifier,
(D-1-1) If information indicating that RLC is to be re-established (reestablishRLC) is received,
(D-1-1-1) Re-establish the RLC entity (D-1-2) Re-configure the RLC entity according to the received RLC configuration (rlc-Config).
(D-1-3) Reconfigure the logical channel according to the received MAC logical channel configuration (mac-LogicalChannelConfig).
(D-2) Otherwise,
(D-2-1) If the logical channel identifier and RLC settings for SRB are not included,
(D-2-1-1) Establish an RLC entity according to the default settings.
(D-2-2) Otherwise,
(D-2-2-1) Establish an RLC entity according to the received RLC configuration (rlc-Config).
(D-2-3) If the logical channel identifier and MAC logical channel settings for SRB are not included,
(D-2-3-1) Set the MAC entity corresponding to the logical channel according to the default settings.
(D-2-4) Otherwise,
(D-2-4-1) Configure the MAC entity corresponding to the logical channel according to the received MAC logical channel configuration.
(D-2-5) This logical channel is associated with the PDCP entity based on the radio bearer identifier information (servedRadioBearer) included in the RLC bearer configuration.

(Processing E)
(E-1) If the reconfiguration target by CellGroupConfig is SCG and SCG MAC is not part of the current terminal device configuration,
(E-1-1) Generate an SCG MAC entity.
(E-2) Re-configure the MAC main configuration of the cell group according to the MAC cell group configuration (mac-Cell) excluding settings related to addition, modification, and/or release of timing advance group (TAG). Set.
(E-3) If the received MAC cell group configuration includes information regarding TAG release (tag-ToReleaseList),
(E-3-1) If the TAG identifier included in the tag-ToReleaseList is part of the current terminal device settings, release the TAG indicated by the TAG identifier for each TAG identifier.
(E-4) If the received MAC cell group configuration includes information on adding and/or modifying TAG (tag-ToAddModList),
(E-4-1) If the TAG identifiers included in tag-ToAddModList are not part of the current terminal device settings, for each TAG identifier,
(E-4-1-1) Add a TAG corresponding to the TAG identifier according to the received timing advance timer.
(E-4-2) If the TAG identifiers included in tag-ToAddModList are part of the current terminal device settings, for each TAG identifier,
(E-4-2-1) Reset the TAG corresponding to the TAG identifier according to the received timing advance timer.

(Processing F)
(F-1) If the release was triggered by receiving the SCell release list (sCellToReleaseList),
(F-1-1) For each SCell index (sCellIndex) value included in sCellToReleaseList,
(F-1-1-1) If the current terminal device settings include an SCell with the value of sCellIndex,
(F-1-1-1-1) Release the SCell.

(Processing G)
(G-1) If the SpCell configuration includes radio link failure (RLF) timer and constant information (rlf-TimersAndConstants), then
(G-1-1) Set RLF timers and constants for this cell group according to rlf-TimersAndConstants.
(G-2) Otherwise, if rlf-TimersAndConstants is not configured for this cell group,
(G-2-1) Using the timer and constant values received in the system information, set the RLF timer and constant for this cell group.
(G-3) If SpCell configuration includes individual SpCell configuration (spCellConfigDedicated),
(G-3-1) Configure SpCell according to spCellConfigDedicated.
(G-3-2) If set, the BWP indicated by the identifier (firstActiveUplinkBWP-Id) of the first active uplink BWP (Bandwidth part) is considered to be the active uplink BWP.
(G-3-3) If set, the BWP indicated by the identifier (firstActiveDownlinkBWP-Id) of the first active downlink BWP (Bandwidth part) is considered to be the active downlink BWP.
(G-3-4) If the reference signal used for radio link monitoring is reset by the received individual SpCell configuration,
(G-3-4-1) If it is running, stop the timer T310 corresponding to SpCell.
(G-3-4-2) Stop counters N310 and N311.

(Processing H)
(H-1) For each value of sCellIndex included in sCellToAddModList that is not part of the current terminal device settings,
(H-1-1) Add SCell corresponding to sCellIndex.
(H-1-2) Set the lower layer to consider the SCell to be in an inactive state.
(H-1-3) For each measurement identifier in the measurement identifier list (measIdList) of the variable that holds measurement settings (VarMeasConfig),
(H-1-3-1a) If the SCell cannot be applied to the measurement corresponding to the measurement identifier, and
(H-1-3-1b) If this SCell is included in the list of triggered cells (cellsTriggeredList) defined by the variable (VarMeasReportList) that holds the measurement report for this measurement identifier,
(H-1-3-1-1) Delete this SCell from the list of triggered cells (cellsTriggeredList) defined by the variable (VarMeasReportList) that holds the measurement report for this measurement identifier.
(H-2) For each value that is part of the current terminal device settings among the sCellIndex values included in sCellToAddModList,
(H-2-1) Change the SCell settings corresponding to sCellIndex.

(Processing I)
(I-1) If RadioBearerConfig includes srb3-ToRelease,
(I-1-1) Release the PDCP entity and SRB identifier of SRB3.
(I-2) If RadioBearerConfig includes SRB-ToAddModList,
(I-2-1) Execute addition and/or reconfiguration of SRB.
(I-3) If RadioBearerConfig includes drb-ToReleaseList,
(I-3-1) DRB is released in process J, which will be described later.
(I-4) If RadioBearerConfig includes DRB-ToAddModList,
(I-4-1) DRB addition and/or resetting is executed in process K described later.
(I-5) Release all SDAP entities that are not associated with the DRB, and notify the upper layer of the release of the user plane resources of the PDU sessions associated with the released SDAP entities.

In the process I, in the case of MBB-HO, in the process of adding, resetting, and/or releasing an SRB, two settings, the source setting and the target setting, are managed, and the process I is applied to the target setting. Instead of executing Process I-1 and Process I-2, the current SRB settings may be reset using Process I-1 and Process I-2. That is, the SRB may manage one configuration. In this case, the SRB configuration of the source before reconfiguration for reverting may be separately held in case the handover fails.

As the process I-5, in the case of MBB-HO, all SDAP entities that are not linked to either the DRB of the source setting or the DRB of the target setting are released, and all the SDAP entities that are linked to the released SDAP entity are The upper layer may be notified of the release of the user plane resources for the PDU sessions that have been created. For example, if MBB-HO is performed based on an RRC reconfiguration message that includes reconfiguration with synchronization, the source The SDAP entity associated with the (target) DRB and/or the target DRB does not release the (target) DRB when the source DRB is released by receiving a message to release the source settings. All unlinked SDAP entities may be released, and an upper layer may be notified of the release of user plane resources of PDU sessions linked to the released SDAP entities.

The above-mentioned "receiving a message to release the source settings" may be rephrased as detecting a certain request. The above-mentioned certain request may be rephrased as certain information. Detecting a certain request may mean that a received RRC message includes a specific information element (for example, an information element that instructs release of the source configuration), or that a received MAC control element contains a specific information element. Information (for example, information instructing release of source configuration) may be included, or the SpCell may receive an initial uplink grant. Detecting a certain request may also be the success of a random access procedure. Detecting a certain request means that (A) reconfiguration with synchronization is included in SpCellConfig, (B) the random access procedure detects a message notifying completion of RRC reconfiguration (for example, RRC connection reconfiguration in the case of LTE). In either or both cases, the random access procedure is triggered by an RRC entity's submission to a lower layer to send a configuration complete message, or an RRC reconfiguration complete message if NR. It may be something that was successful. Furthermore, detecting a certain request may be something detected by the implementation of the terminal device.

(Processing J)
(J-1a) for each DRB identifier included in the drb-ToReleaseList that is part of the current terminal device configuration; or (J-1b) for each DRB identifier that is released as a result of a full configuration. for,
(J-1-1) Release the PDCP entity and DRB identifier.
(J-1-2) If an SDAP entity linked to this DRB is set,
(J-1-2-1) Indicates the release of the DRB to the SDAP linked to this DRB.
(J-1-3) If DRB is linked to the EPS bearer identifier,
(J-1-3-1) If no new bearer is added in either NR or E-UTRA with the same EPS bearer identifier,
(J-1-3-1-1) Notify the upper layer of the release of the DRB and the EPS bearer identifier of the released DRB.

As the above process J-1-3-1, in the case of MBB-HO, if a new bearer is not added to the same EPS bearer in either the source or target settings, the DRB is released and released. The EPS bearer identifier of the DRB may be notified to the upper layer. For example, if MBB-HO is performed based on an RRC reconfiguration message including reconfiguration with synchronization, the same message will be used until the target cell receives a message (e.g. RRC message, MAC CE, etc.) that releases the source configuration. If the EPS bearer is associated with a bearer in either the source or target settings, the release of the DRB and the EPS bearer identifier of the released DRB are not notified to the upper layer, and the source settings are changed. When a source DRB is released by receiving a release message, if no new bearer with the same EPS bearer identifier is added in either NR or E-UTRA, the release of the DRB and the release of the released DRB are performed. The EPS bearer identifier may also be notified to the upper layer.

(Processing K)
(K-1) For each DRB identifier included in DRB-ToAddModList that is not part of the current terminal device configuration,
(K-1-1) Establish a PDCP entity and configure the PDCP entity according to the received PDCP configuration (pdcp-Config).
(K-1-2) If the PDCP entity of this DRB is not set to cipheringDisabled,
(K-1-2-1a) If the handover target RAT is E-UTRA/5GC, or
(K-1-2-1b) If the terminal device connects only to E-UTRA/5GC,
(K-1-2-1-1) A PDCP entity is set using the encryption algorithm and key setting of Non-Patent Document 4.
(K-1-2-2) Otherwise,
(K-1-2-2-1) Set up the PDCP entity with an encryption algorithm according to the security settings (securityConfig) and link it to the master key (KeNB or KgNB) or secondary key (S-KgNB) Apply the key indicated by the parameter (keyToUse).
(K-1-3) If the PDCP entity of this DRB is set to integrity protect,
(K-1-3-1) Set the PDCP entity with an integrity protection algorithm according to the security settings (securityConfig), and set the parameters linked to the master key (KeNB or KgNB) or secondary key (S-KgNB) Apply the key indicated by (keyToUse).
(K-1-4) If SDAP settings (sdap-Config) are included,
(K-1-4-1) If the SDAP of the received PDU session does not exist,
(K-1-4-1-1) Establish the SDAP entity.
(K-1-4-1-2) If the SDAP of the received PDU session did not exist prior to receiving this reconfiguration,
(K-1-4-1-2-1) Notify the upper layer of the establishment of user plane resources for the PDU session.
(K-1-4-2) Set the SDAP entity according to the received SDAP settings, and link the DRB and the SDAP entity.
(K-1-5) If DRB is linked to the EPS bearer identifier,
(K-1-5-1) If the DRB was configured by the NR or E-UTRA to the same EPS bearer identifier prior to receipt of this reconfiguration;
(K-1-5-1-1) Link the established DRB with the corresponding EPS bearer identifier.
(K-1-5-2) Otherwise,
(K-1-5-2-1) Notify the upper layer of the establishment of the DRB and the EPS bearer identifier of the established DRB.
(K-2) For each DRB identifier included in DRB-ToAddModList, which is part of the current terminal device settings,
(K-2-1) If the parameter re-establishPDCP is set
(K-2-1-1a) If the handover target RAT is E-UTRA/5GC, or
(K-2-1-1b) If the terminal device connects only to E-UTRA/5GC,
(K-2-1-1-1) If the PDCP entity of this DRB is not set to cipheringDisabled,
(K-2-1-1-1-1) A PDCP entity is set using the encryption algorithm and key setting of Non-Patent Document 4.
(K-2-1-2) Otherwise,
(K-2-1-2-1) If the PDCP entity of this DRB is not set to cipheringDisabled,
(K-2-1-2-1-1) Set up the PDCP entity with the encryption algorithm according to the security settings (securityConfig) and link it to the master key (KeNB or KgNB) or secondary key (S-KgNB) The key indicated by the specified parameter (keyToUse) is applied.
(K-2-1-2-2) If the PDCP entity of this DRB is set to integrity protect,
(K-2-1-2-2-1) Configure the PDCP entity with the integrity protection algorithm according to the security settings (securityConfig) and link it to the master key (KeNB or KgNB) or secondary key (S-KgNB). The key indicated by the attached parameter (keyToUse) is applied.
(K-2-1-3) If drb-ContinueROHC is included in pdcp-Config,
(K-2-1-3-1) Notify the lower layer that drb-ContinueROHC is set.
(K-2-1-4) Re-establish the PDCP entity for this DRB.
(K-2-2) Otherwise, if recoverPDCP is set,
(K-2-2-1) Trigger execution of data recovery for the PDCP entity of this DRB.
(K-2-3) If PDCP settings are included,
(K-2-3-1) Reconfigure the PDCP entity according to the received PDCP configuration.
(K-2-4) If SDAP settings are included,
(K-2-4-1) Reconfigure the SDAP entity according to the received SDAP configuration.
(K-2-4-2) For each QFI added by mappedQoS-FlowsToAdd, if a QFI value has been set, the QFI value is released from the old DRB.

As the process K-1-4-1-2, in the case of MBB-HO, if the SDAP of the received PDU session does not exist in either the source configuration or the target configuration prior to receiving this reconfiguration. If so, the establishment of user plane resources for that PDU session may be notified to the upper layer. Or, as the above process K-1-4-1-2, in the case of MBB-HO, if the SDAP of the received PDU session did not exist in the source configuration prior to receiving this reconfiguration, then The establishment of user plane resources for the PDU session may be notified to upper layers.

In the above process K-1-5-2, in the case of MBB-HO, if the DRB is set to the same EPS bearer identifier by NR or E-UTRA, also in the configuration of the source, prior to receiving this reconfiguration, the target If it is not configured in the configuration, the establishment of the DRB and the EPS bearer identifier of the established DRB may be notified to the upper layer. Or, in said procedure K-1-5-2, in the case of MBB-HO, if the DRB is set by NR or E-UTRA to the same EPS bearer identifier in the source configuration prior to receiving this reconfiguration. If not configured, the establishment of the DRB and the EPS bearer identifier of the established DRB may be notified to the upper layer.

(Processing L)
(L-1) If the terminal device is connected to E-UTRA/EPC,
(L-1-1) If sk-Counter is received,
(L-1-1-1) Update the S-KgNB key based on the KgNB key and the received sk-Counter.
(L-1-1-2) Generate (Delive) the KRRCenc key and KUPenc key. The KRRCenc key is a key used to protect the RRC signal generated from the KgNB using the encryption algorithm. Further, KUPenc is a key used to protect user plane traffic (user data) generated from KgNB using an encryption algorithm.
(L-1-1-3) Generate a KRRCint key and a KUPint key from the KgNB key. The KRRCint key is a key used to protect the RRC signal generated from the KgNB with the integrity algorithm. Further, KUPint is a key used to protect user plane traffic (user data) generated from KgNB using an integrity algorithm.
(L-2) Otherwise,
(L-1-2) If the received masterKeyUpdate includes nas-Container,
(L-1-2-1) Forward the NAS-Container to the upper layer.
(L-1-3) If keySetChangeIndicator is "true",
(L-1-3-1) Generate or update KgNB based on KAMF.
(L-1-4) Otherwise,
(L-1-4-1) Generate or update a KgNB key based on the current KgNB key or NextHop (NH).
(L-1-5) Store the value of nextHopChainingCount.
(L-1-6) A key related to the KgNB key is generated as follows.
(L-1-6-1) If SecurityConfig includes securityAlgorithmConfig,
(L-1-6-1-1) Generate the KRRCenc key and KUPenc key linked to cipheringAlgorithm included in securityAlgorithmConfig from the KgNB key.
(L-1-6-1-2) Generate the KRRCint key and KUPint key linked to integrityProtAlgorithm included in securityAlgorithmConfig from the KgNB key.
(L-1-6-2) Otherwise,
(L-1-6-2-1) Generate the KRRCenc key and KUPenc key linked to the current cipheringAlgorithm from the KgNB key.
(L-1-6-2-2) Generate the KRRCint key and KUPint key linked to the current integrityProtAlgorithm from the KgNB key.

An example of the operation of MBB-HO will be explained. Here, an example is shown in which an RRC connection reconfiguration message including a mobility control information (mobilityControlInfo) information element is used in LTE. In addition, in the description of each process below, there is a description that an information element is received, but unless otherwise specified, this does not mean that the information element is included in the RRC connection reconfiguration message that triggered each process. good. Furthermore, the information elements used in each process may be associated with the information elements used in Non-Patent Document 4, unless otherwise specified.

The terminal device receives the RRC connection reconfiguration message including mobilityControlInfo, and if the terminal device can comply with the settings included in this message, executes the next process LA.

(Processing LA)
(LA-1) Start timer T304 using the timer value of t304 included in mobilityControlInfo.
(LA-2) If carrierFreq is included,
(LA-2-1) The cell whose physical cell identifier on the frequency indicated by carrierFreq is indicated by targetPhysCellId is regarded as the target PCell.
(LA-3) Otherwise,
(LA-3-1) The cell whose physical cell identifier on the frequency of the source PCell is indicated by targetPhysCellId is regarded as the target PCell.
(LA-4) Start synchronization of the target PCell to the downlink.
(LA-5) If makeBeforeBreak is set,
(LA-5-1) After the terminal device stops uplink transmission and/or downlink reception with the source cell, it performs the remaining processing of this procedure thereafter, including resetting the MAC.
(LA-6) If makeBeforeBreak-r16 is set,
(LA-6-1) Copy the current terminal device settings (source settings) and use them as the target settings. Unless otherwise specified, the resetting process that follows will be performed on the copied target settings. It's okay to be. For example, in the case of MBB-HO, the "current terminal device settings" of each process may be considered to be the "current terminal device target settings." For example, the settings to be duplicated include (1) bearer settings (e.g. SRB settings, DRB settings, etc.), (2) cell group settings (e.g. SpCell settings, SCell settings, RLC entity settings, MAC (entity settings, PHY settings, etc.), (3) internal variables (measurement settings (VarMeasConfig), measurement results (VarMeasReportList), timers, counters, etc.), (4) security-related settings (e.g., each key), some of or all may be included. Further, the configuration of the bearer to be duplicated may not include the SRB configuration. That is, for DRB, both source settings and target settings may be managed, and for SRB, settings may be switched from source settings to target settings without duplicating the settings. Furthermore, information that allows it to be determined whether or not to duplicate the SRB settings may be included in the RRC connection reconfiguration message including mobilityControlInfo. For example, the information may be included in MakeBeforeBreak-r16.
(LA-7) If set, reset the MCG MAC and SCG MAC. If MakeBeforeBreak-r16 is set, the MAC of the source MCG and the MAC of the SCG may not be reset. Alternatively, if MakeBeforeBreak-r16 is set, the source MAC may not be reset here, but the target MAC may be reset.
(LA-8) Re-establish PDCP for all established radio bearers configured with PDCP configuration. If MakeBeforeBreak-r16 is set, PDCP re-establishment applies only to the target PDCP. Alternatively, in the case of Single PDCP, which will be described later, if MakeBeforeBreak-r16 is set and a PDCP to which the target radio bearer is linked already exists, the establishment and/or re-establishment of the PDCP may not be performed. . That is, if MakeBeforeBreak-r16 is set, PDCP may be established and/or re-established if there is no PDCP linked to the target radio bearer.
(LA-9) Re-establish the MCG RLC and SCG RLC, if configured, for all established radio bearers.
(LA-10) Apply the value of newUE-Identity as C-RNTI.
(LA-11) Configure the lower layer according to the received cell-common radio resource configuration (radioResourceConfigCommon).
(LA-12) Configure the lower layer according to other information included in the received mobilityControlInfo.
(LA-13) If the received RRC connection reconfiguration message includes sCellToReleaseList,
(LA-13-1) Execute release of SCell.
(LA-14) If the received RRC connection reconfiguration message includes sCellGroupToReleaseList, then
(LA-14-1) Execute release of SCell group.
(LA-15a) If the received RRC connection reconfiguration message includes scg-Configuration,
(LA-15b) If the current terminal device setting is one or more split DRBs (Split
DRB) and the received RRC connection reconfiguration message includes DRB-ToAddModList;
(LA-15-1) Execute SCG resetting.
(LA-16) If the received RRC connection reconfiguration message includes a terminal device-specific radio resource configuration (radioResourceConfigDedicated),
(LA-16-1) Radio resource setting is executed in processing LB, which will be described later.
(LA-17) If the RRC connection reconfiguration message includes security settings (securityConfigHO-v1530),
(LA-17-1) If nas-Container is received,
(LA-17-1-1) Transfer the NAS-Container to the upper layer.
(LA-17-2) If keyChangeIndicator-r15 is received and keyChangeIndicator-r15 is "true",
(LA-17-2-1) Update the KeNB key based on the KAMF key.
(LA-17-3) Otherwise,
(LA-17-3-1) Update the KeNB key based on the current KeNB or NextHop (NH).
(LA-17-4) Store the value of nextHopChainingCount-r15.
(LA-17-5) If securityAlgorithmConfig-r15 is received,
(LA-17-5-1) Generate a KRRCint key linked to the received integrityProtAlgorithm.
(LA-17-5-2) Generate the KRRCenc key and KUPenc key linked to the received cipheringAlgorithm. The KRRCenc key is a key used to protect the RRC signal generated from the KeNB key using the encryption algorithm. Further, KUPenc is a key used to protect user plane traffic (user data) generated from the KeNB key using an encryption algorithm.
(LA-17-6) Otherwise,
(LA-17-6-1) Generate the KRRCint key linked to the current integrityProtAlgorithm from the KeNB key.
(LA-17-6-2) Generate the KRRCenc key and KUPenc key linked to the current cipheringAlgorithm from the KeNB key.
(LA-18) If the received RRC connection reconfiguration message includes sCellToAddModList, then
(LA-18-1) Add and/or modify SCell.
(LA-19) If the received RRC connection reconfiguration message includes sCellGroupToAddModList,
(LA-19-1) Add and/or modify SCell groups.
(LA-20) If the received RRC connection reconfiguration message includes measConfig,
(LA-20-1) Execute measurement settings.
(LA-21) Execute automatic deletion of measurement identifier.
(LA-22) Submit an RRC Connection Reconfiguration Complete message to lower layers for transmission.
(LA-23) If the MAC succeeds in the random access procedure,
(LA-23-1) Stop the timer T304 and end this procedure.

(Processing LB)
(LB-1) If the received radioResourceConfigDedicated includes SRB-ToAddModList,
(LB-1-1) Execute SRB addition and/or resetting in processing LC to be described later.
(LB-2) If the received radioResourceConfigDedicated includes drb-ToReleaseList,
(LB-2-1) Execute DRB release in processing LD, which will be described later.
(LB-3) If the received radioResourceConfigDedicated includes DRB-ToAddModList,
(LB-3-1) Addition and/or resetting of DRB is executed in processing LE to be described later.
(LB-4) If the received radioResourceConfigDedicated includes mac-MainConfig,
(LB-4-1) In processing LF to be described later, the main setting of the MAC is executed.

(Processing LC)
(LC-1) For each SRB identifier included in SRB-ToAddModList that is not part of the current terminal device configuration,
(LC-1-1) Establish a PDCP entity with the current security settings.
(LC-1-2) If you receive rlc-BearerConfigSecondary with the value "Setup",
(LC-1-2-1) Establish a secondary MCG RLC entity according to the received rlc-BearerConfigSecondary and associate it with the DCCH logical channel.
(LC-1-2-2) Set to activate duplication for the PDCP entity of E-UTRA.
(LC-2) For each SRB identifier included in the SRB-ToAddModList that is part of the current terminal device settings,
(LC-2-1) If pdcp-verChange is included (that is, if it is a change from NR PDCP to E-UTRA PDCP)
(LC-2-1-1) Establish the E-UTRA PDCP entity with the current security settings.
(LC-2-1-2) Link the primary RLC of this SRB with the established PDCP entity.
(LC-2-1-3) Release the NR PDCP of this SRB.
(LC-2-2) Reconfigure the primary RLC entity according to the received rlc-Config.
(LC-2-3) Reconfigure the primary DCCH logical channel according to the received logical channel configuration (logicalChannelConfig).
(LC-2-4) If rlc-BearerConfigSecondary with the value "release" is included,
(LC-2-4-1) Release the secondary MCG RLC entity and the DCCH logical channel associated with it.
(LC-2-5) If you receive rlc-BearerConfigSecondary with the value "Setup",
(LC-2-5-1) If the current SRB configuration does not include a secondary RLC bearer,
(LC-2-5-1-1) Establish a secondary MCG RLC entity according to the received rlc-BearerConfigSecondary and associate it with the DCCH logical channel.
(LC-2-5-1-2) Set to activate duplication for the PDCP entity of E-UTRA.
(LC-2-5-2) Otherwise,
(LC-2-5-2-1) Reconfigure the secondary MCG RLC entity according to the received rlc-BearerConfigSecondary and associate it with the DCCH logical channel.

(Processing LD)
(LD-1a) For each DRB identifier included in the drb-ToReleaseList that is part of the current terminal device configuration, or
(LD-2b) For each DRB identifier value released as a result of full configuration,
(LD-2-1) If this DRB release is the result of full setting,
(LD-2-1-1) Release the E-UTRA or NR PDCP entity.
(LD-2-2) Otherwise, if DRB is configured with PDCP configuration,
(LD-2-2-1) Release the E-UTRA PDCP entity.
(LD-2-3) Otherwise,
(LD-2-3-1) Re-establish the RLC entity for this DRB.
(LD-2-4) Release the RLC entity.
(LD-2-5) Release the DTCH logical channel.
(LD-2-6) If the terminal device is connected to the EPC,
(LD-2-6-1) If DRB is configured with PDCP configuration and a new DRB is added with the same EPS bearer identifier by either DRB-ToAddModList, nr-radioBearerConfig1, or nr-radioBearerConfig2. If not,
(LD-2-6-1-1) If this procedure is triggered by handover,
(LD-2-6-1-1-1) After successful handover, notify the upper layer of the release of the DRB and the EPS bearer identifier of the released DRB.
(LD-2-6-1-2) Otherwise,
(LD-2-6-1-2-1) Immediately notify the upper layer of the release of the DRB and the EPS bearer identifier of the released DRB.

(Processing LE)
(LE-1) For each DRB identifier included in DRB-ToAddModList that is not part of the current terminal device configuration,
(LE-1-1) If DRB-ToAddModListSCG is not received or DRB-ToAddModListSCG does not include the value of the DRB identifier,
(LE-1-1-1) If pdcp-Config is included, establish a PDCP entity according to pdcp-Config and configure it with the current MCG security settings.
(LE-1-1-2) If rlc-Config is included, establish MCG RLC according to rlc-Config.
(LE-1-1-3) If a logical channel identifier (logicalChannelIdentity) and a logical channel configuration (logicalChannelConfig) are included, the MCG Establish a DTCH logical channel.
(LE-1-1-4) If rlc-BearerConfigSecondary with the value "Setup" is included,
(LE-1-1-4-1) Establish a secondary MCG RLC entity according to rlc-BearerConfigSecondary and associate it with the DTCH logical channel. Then, the established RLC entity is linked to the E-UTRA PDCP having the same DRB identifier value in the current terminal device configuration.
(LE-1-2) If DRB is configured with the same EPS bearer identifier,
(LE-1-2-1) Link the established DRB to its EPS bearer identifier.
(LE-1-3) Otherwise, if the DRB-ToAddModList entry contains pdcp-config (i.e., if the bearer is established with PDCP in E-UTRA),
(LE-1-3-1) Notify the upper layer of the establishment of the DRB and the EPS bearer identifier of the established DRB.
(LE-2) For each DRB identifier included in DRB-ToAddModList that is part of the current terminal device settings,
(LE-2-1) Reconfigure each layer and/or bearer according to the included configuration.

(Processing LF)
(LF-1) Addition and modification of secondary timing advance group (STAG),
and/or reconfigure the MAC main configuration according to the MA main configuration information element (mac-MainConfig), excluding settings related to release.
(LF-2) If the received mac-MainConfig includes information regarding STAG release (stag-ToReleaseList),
(LF-2-1) If the STAG identifier included in the stag-ToReleaseList is part of the current terminal device settings, release the STAG indicated by the STAG identifier for each STAG identifier.
(LF-3) If the received mac-MainConfig includes information about adding and/or modifying STAG (stag-ToAddModList),
(LF-3-1) If the STAG identifiers included in stag-ToAddModList are not part of the current terminal device settings, for each TAG identifier,
(LF-3-1-1) Add the STAG corresponding to the STAG identifier according to the received timeAlignmentTimerSTAG.
(LF-3-2) If the STAG identifiers included in stag-ToAddModList are part of the current terminal device settings, for each STAG identifier,
(LF-3-2-1) Reset the STAG corresponding to the STAG identifier according to the received timeAlignmentTimerSTAG.

Another example of the operation of MBB-HO will be explained. Here, an example is shown in which an RRC reconfiguration message including conditional handover configuration is used in NR.

For example, a conditional handover information element may be included in the RRC message transmitted by the base station device. The conditional handover information element may include a list including one or more information elements (conditional handover settings) including information included in the synchronized reconfiguration information element. Further, the conditional handover information element may include an information element (conditional handover condition) indicating a condition for applying the conditional handover setting to each, some, or all of the conditional handover settings.

The conditional handover configuration may include some or all of the information included in RadioBearerConfig and CellGroupConfig. Further, the conditional handover setting may include information indicating that it is MBB-HO. Further, the conditional handover condition may include threshold information for determining whether the condition is satisfied using a reference signal. Further, the conditional handover condition may include information instructing to immediately apply the conditional handover setting. For example, if the conditional handover condition indicates information that instructs to immediately apply the conditional handover configuration, and the conditional handover configuration includes information indicating that it is MBB-HO, the conditional handover configuration includes By executing the processing A and processing I based on the information, MBB-HO can be realized. Of course, even if the conditional handover condition is another condition, by executing the process A and process I based on the information included in the conditional handover setting when the condition is satisfied, Conditional MBB-HO can be realized.

In the NR MBB-HO, the terminal device may have a common PDCP (Single PDCP) configuration for the source and target.

For example, when the core network is 5GC, in the source configuration, the logical channel, DRB (or SRB), and RLC bearer are linked by the RLC bearer configuration, and further, the DRB, PDCP entity, and PDU session are linked by drb-ToAddMod. is linked. Similarly, in target settings, the RLC bearer settings link the logical channel, DRB (or SRB), and RLC bearer, and drb-ToAddMod links the DRB (or SRB), PDCP entity, and PDU session. Can be linked. In this case, for example, logical channels, DRBs (or SRBs), and/or RLC bearers that are associated with the same DRB identifier (or SRB identifier) in the source configuration and target configuration are associated with one PDCP. You can. Furthermore, for example, logical channels, DRBs (or SRBs), and/or RLC bearers that are linked to the same PDU session in the source settings and target settings may be linked to one PDCP. Further, DRBs having the same DRB identifier in the source setting and target setting may be collectively regarded as one DRB. Further, SRBs having the same SRB identifier in the source setting and the target setting may be collectively regarded as one SRB.

For example, if the core network is 5GC, in the source configuration, the logical channel, DRB (or SRB), and RLC bearer are linked by the RLC bearer configuration, and further, the DRB, PDCP entity, and PDU session are linked by drb-ToAddMod. is linked. Similarly, in target settings, the RLC bearer settings link the logical channel, DRB (or SRB), and RLC bearer, and drb-ToAddMod links the DRB (or SRB), PDCP entity, and PDU session. Can be linked. In this case, for example, logical channels, DRBs (or SRBs), and/or RLC bearers that are associated with the same DRB identifier (or SRB identifier) in the source configuration and target configuration are associated with one SDAP. It's okay.

Further, for example, when the core network is EPC, the DRB (or SRB), PDCP entity, logical channel, RLC entity (and/or RLC bearer), and EPS bearer are linked in the source configuration. Similarly, in setting a target, a DRB (or SRB), a PDCP entity, a logical channel, an RLC entity (and/or an RLC bearer), and an EPS bearer are linked. In this case, for example, logical channels and RLC entities (and/or RLC bearers) associated with the same DRB identifier (or SRB identifier) in the source configuration and target configuration are associated with one PDCP entity. Good too. Also, for example, if the logical channel, RLC entity (and/or RLC bearer), and DRB (or SRB) that are linked to the same EPS bearer identifier in the source configuration and target configuration are linked to one PDCP, Good too.

In the above case, the terminal device may consider that the source and target PDCP settings linked to one PDCP are the same. Alternatively, the terminal device may apply the target PDCP settings to the source PDCP settings. Further, DRBs having the same DRB identifier in the source setting and target setting may be collectively regarded as one DRB. Further, SRBs having the same SRB identifier in the source setting and target setting may be collectively regarded as one SRB.

Additionally, if the source DRB (or SRB) and target DRB with the same DRB identifier are linked to one PDCP entity, the source and target security keys (e.g., KUPenc, KUPint, KRRCenc, and/or KRRCint, etc.) ), one PDCP entity manages multiple security keys.

Another example of the operation of MBB-HO will be explained. Here, an example is shown in which an RRC connection reconfiguration message including conditional handover configuration is used in LTE.

For example, a conditional handover information element may be included in the RRC message transmitted by the base station device. The conditional handover information element may include a list including one or more information elements (conditional handover settings) including information included in the mobilityControlInfo information element. Further, the conditional handover information element may include an information element (conditional handover condition) indicating a condition for applying the conditional handover setting to each, some, or all of the conditional handover settings.

The conditional handover configuration may include part or all of the information included in the cell-common radio resource configuration (radioBearerConfigCommon) and the terminal device-specific radio resource configuration (radioBearerConfigDedicated). Further, the conditional handover setting may include information indicating that it is MBB-HO (for example, MakeBeforeBreak-r16). Further, the conditional handover condition may include threshold information for determining whether the condition is satisfied using a reference signal. Further, the conditional handover condition may include information instructing to immediately apply the conditional handover setting. For example, if the conditional handover condition indicates information that instructs to immediately apply the conditional handover configuration, and the conditional handover configuration includes information indicating that it is MBB-HO, the conditional handover configuration includes By executing the processing LA based on the information, MBB-HO can be realized. Of course, even if the conditional handover condition is another condition, if the condition is satisfied, by executing the processing LA based on the information included in the conditional handover setting, the conditional MBB - HO can be realized.

In the LTE MBB-HO (MakeBeforeBreak-r16), the terminal device may have a common PDCP (Single PDCP) configuration for the source and target.

For example, if the core network is 5GC, in the source configuration, the logical channel, DRB (or SRB), and RLC bearer are linked by the RLC bearer configuration, and further, the DRB, PDCP entity, and PDU session are linked by drb-ToAddMod. is linked. Similarly, in target settings, the RLC bearer settings link the logical channel, DRB (or SRB), and RLC bearer, and drb-ToAddMod links the DRB (or SRB), PDCP entity, and PDU session. Can be linked. In this case, for example, logical channels, DRBs (or SRBs), and/or RLC bearers that are associated with the same DRB identifier (or SRB identifier) in the source configuration and target configuration are associated with one PDCP. It's okay. Furthermore, for example, logical channels, DRBs (or SRBs), and/or RLC bearers that are linked to the same PDU session in the source settings and target settings may be linked to one PDCP.

For example, if the core network is 5GC, in the source configuration, the logical channel, DRB (or SRB), and RLC bearer are linked by the RLC bearer configuration, and further, the DRB, PDCP entity, and PDU session are linked by drb-ToAddMod. is linked. Similarly, in target settings, the RLC bearer settings link the logical channel, DRB (or SRB), and RLC bearer, and drb-ToAddMod links the DRB (or SRB), PDCP entity, and PDU session. Can be linked. In this case, for example, logical channels, DRBs (or SRBs), and/or RLC bearers that are associated with the same DRB identifier (or SRB identifier) in the source configuration and target configuration are associated with one SDAP. It's okay.

Further, for example, when the core network is EPC, the DRB (or SRB), PDCP entity, logical channel, RLC entity (and/or RLC bearer), and EPS bearer are linked in the source configuration. Similarly, in setting a target, a DRB (or SRB), a PDCP entity, a logical channel, an RLC entity (and/or an RLC bearer), and an EPS bearer are linked. In this case, for example, logical channels and RLC entities (and/or RLC bearers) associated with the same DRB identifier (or SRB identifier) in the source configuration and target configuration are associated with one PDCP entity. Good too. Also, for example, if the logical channel, RLC entity (and/or RLC bearer), and DRB (or SRB) that are linked to the same EPS bearer identifier in the source configuration and target configuration are linked to one PDCP, Good too.

In the above case, the terminal device may consider that the source and target PDCP settings linked to one PDCP are the same. Alternatively, the terminal device may apply the target PDCP settings to the source PDCP settings. Further, DRBs having the same DRB identifier in the source setting and target setting may be collectively regarded as one DRB. Further, SRBs having the same SRB identifier in the source setting and target setting may be collectively regarded as one SRB.

In addition, when a source DRB and a target DRB (or SRB) with the same DRB identifier are linked to one PDCP entity, the source and target security keys (for example, KUPenc) are different, so in one PDCP entity, Manage multiple security keys.

Note that the MakeBeforeBreak-r16 may include information indicating which layer of the target is generated or not generated until the connection to the target is completed.

In the case of NR, the above (processing E) may include the following processing (E2-1). For example, as shown in FIG. 27, process (E2-1) may be executed between process (E-1) and process (E-2), but the process is not limited to this. In addition, in the case of LTE, the above (processing LF) may include the following processing (E2-1). For example, the process (E2-1) may be executed before the process (LF-1), but the process is not limited to this.
(E2-1) If it is MBB-HO and the MAC entity (also referred to as secondary MAC entity) for the target does not exist as part of the current terminal device configuration,
(E2-1-1) Generate a secondary MAC entity.

Thereby, a MAC entity can be appropriately generated in processing based on the settings of the MAC layer.

Furthermore, in the case of NR, the process within the scope of process (B-9) of the above (process B) may be, for example, process (B2-9) as shown in FIG. Furthermore, in the case of MBB-HO, the settings for "this cell group" in the process (B-9) and subsequent processes in the process (B) may be applied to the target.
(B2-9) If the reconfiguration with synchronization includes information indicating that it is MBB-HO,
(B2-9-1) If the MAC entity (also referred to as secondary MAC entity) for the target does not exist as part of the current terminal device configuration,
(B2-9-1-1) The existing MAC entity (also referred to as primary MAC entity) of this cell group is not reset.
(B2-9-1-2) Generate a secondary MAC entity.
(B2-9-2) Apply default MAC cell group settings to the secondary MAC entity. Alternatively, the same settings as the primary MAC entity may be applied to the secondary MAC entity.
(B2-9-3) Reset the secondary MAC entity.
(B2-9-4) If set, consider the SCell of this cell group to be in a deactivated state.
(B2-9-5) Apply the value of newUE-Identity as the C-RNTI of this cell group.

In addition, in the case of LTE, the processing within the scope of processing (LA-6) to processing (LA-7) in the above (processing LA) is, for example, processing (LA2-6) and processing (LA2- 7).
(LA2-6) If makeBeforeBreak-r16 is set,
(LA2-6-1) Copy the current terminal device settings (source settings) and use them as the target settings. Unless otherwise specified, the resetting process that follows will be performed on the copied target settings. It's okay to be. For example, in the case of MBB-HO, the "current terminal device settings" of each process may be considered to be the "current terminal device target settings." For example, the settings to be duplicated include (1) bearer settings (e.g. SRB settings, DRB settings, etc.), (2) cell group settings (e.g. SpCell settings, SCell settings, RLC entity settings, MAC (entity settings, PHY settings, etc.), (3) internal variables (measurement settings (VarMeasConfig), measurement results (VarMeasReportList), timers, counters, etc.), (4) security-related settings (e.g., each key), some of or all may be included. Further, the configuration of the bearer to be duplicated may not include the SRB configuration. That is, for DRB, both source settings and target settings may be managed, and for SRB, settings may be switched from source settings to target settings without duplicating the settings. Furthermore, information that allows it to be determined whether or not to duplicate the SRB settings may be included in the RRC connection reconfiguration message including mobilityControlInfo. For example, the information may be included in MakeBeforeBreak-r16. Further, the replication may involve the creation of entities (eg, RLC entity, MAC entity) in each layer.
(LA2-6-2) If the MAC entity (also referred to as secondary MAC entity) for the target does not exist as part of the current terminal device configuration,
(LA2-6-2-1) The existing MAC entity (also referred to as primary MAC entity) of this cell group is not reset.
(LA2-6-2-2) Generate a secondary MAC entity.
(LA2-6-3) Reset the secondary MAC entity if necessary.
(LA2-7) Otherwise (LA2-7-1) If set, reset the MCG MAC and SCG MAC.

Thereby, even if the NR RRC reconfiguration message does not include MAC cell group configuration, a MAC entity can be appropriately generated. Moreover, when the MAC main setting is not included in the EUTRA RRC connection reconfiguration message, a MAC entity can be appropriately generated.

In addition, in (Processing I), (Processing J), or other processing, when the terminal device receives a message to release the source settings, the terminal device releases the current primary MAC entity and transfers the current secondary MAC entity to the current secondary MAC entity. The entity may be considered the primary MAC entity. Further, when the terminal device receives a message to release the source configuration, it resets the current primary MAC entity, does not consider the current primary MAC entity as the primary MAC entity, and changes the current secondary MAC entity to the primary MAC entity. May be considered as an entity.

Thereby, the MAC entity can be appropriately managed.

In each of the above processes, handover (also referred to as MBB-HO) is executed when makeBeforeBreak-r16 is included in the settings of the master cell group, and handover (also referred to as MBB-HO) is executed when makeBeforeBreak-r16 is included in the settings of the secondary cell group. A secondary cell group change (also referred to as MBB-SCG Change) may be performed.

The terminal device also determines whether (1) it supports execution of either MBB-HO or MBB-SCG Change that maintains communication using two or more cell groups (for example, Dual Connectivity or Multi Connectivity). (2) Information indicating whether to support execution of MBB-HO while maintaining communication using two or more cell groups (for example, Dual Connectivity); (4) information indicating whether or not to support the execution of MBB-SCG Change while maintaining communication (for example, Dual Connectivity); (4) information indicating whether to support the execution of both MBB-HO and MBB-SCG Change while maintaining Dual Connectivity; The base station device may be notified of part or all of the information indicating the information. For example, the information may be included in a message (for example, UECapabilityInformation) that notifies the base station device 3 of the wireless access capability of the terminal device. Further, the information may be notified as information that does not depend on the band combination supported by the terminal device. Further, the information may be notified as information for each band combination supported by the terminal device. Further, the information does not need to be notified to the base station device.

Furthermore, the terminal device may release one or more cell groups other than the MCG and perform MBB-HO. The terminal device may perform the MBB-HO when it does not support the execution of MBB-HO that maintains communication using two or more cell groups. Furthermore, the terminal device may release one or more cell groups other than MCG and execute MBB-SCG Change. The terminal device may execute the MBB-SCG Change when it does not support executing the MBB-SCG Change while maintaining communication using two or more cell groups. Furthermore, the terminal device may execute a normal secondary cell group change (SCG Change) other than MBB-SCG Change. The terminal device may change the secondary cell group when it does not support the execution of MBB-SCG Change that maintains communication using two or more cell groups. SCG Change may be rephrased as SCG reconfiguration with sync. Moreover, handover (HO) may be rephrased as MCG reconfiguration with sync.

FIG. 10 is an ASN. This is an example of one description. Further, FIG. 11 shows the ASN. This is another example of one description. Further, FIG. 12 shows the ASN.ASN.RRC reconfiguration message of the NR in FIG. This is an example of one description. Further, FIG. 13 shows the ASN.ASN.RRC reconfiguration message of the NR in FIG. This is another example of one description.

The information element represented by mobilityControlInfo in FIGS. 10 and 11 is an information element that includes parameters related to network-controlled mobility to EUTRA. The information element represented by mobilityControlInfo may include some or all of the following information (A) to (H).
(A) Target physical cell identifier (B) t304 indicating time information from start to expiration of timer T304
(C) newUE-Identity indicating the new identifier (C-RNTI) of the UE 122
(D) Radio resource configuration (E) Dedicated random access channel configuration (F) makeBeforeBreak-r14, which is a parameter for configuring the existing (Release 14) make-before-break handover
(G) rach-Skip-r14, which is a parameter for setting RACH-less handover
(H) makeBeforeBreak-r16, which is a parameter for setting make-before-break handover in this embodiment

FIG. 10 shows an example where makeBeforeBreak-r16 is an enumerated type, and FIG. 11 shows an example where makeBeforeBreak-r16 has the information element MakeBeforeBreak-r16 as a value and the information element MakeBeforeBreak-r16 has multiple fields. .

The information element represented by reconfiguration with synchronization in FIGS. 12 and 13 is, for example, an information element including parameters related to handover of PCell and addition or modification of PSCell. The information element represented by reconfiguration with synchronization may include some or all of the following information (A) to (F).
(A) SpCell settings (B) t304 indicating time information from start to expiration of timer T304
(C) newUE-Identity indicating the new identifier (RNTI) of the UE 122
(D) Setting of dedicated random access channel (E) makeBeforeBreak-r16, which is a parameter for setting make-before-break handover in this embodiment
(F) rach-Skip-r16, a parameter for setting RACH-less handover

FIG. 12 shows an example in which makeBeforeBreak-r16 is an enumerated type, and FIG. 13 shows an example in which makeBeforeBreak-r16 has the information element MakeBeforeBreak-r16 as a value, and the information element MakeBeforeBreak-r16 has multiple fields. .

Furthermore, some or all of the fields shown in FIGS. 10 to 13 may be optional. That is, the fields shown in FIGS. 10 to 13 may be included in the message depending on conditions.

Note that the eNB 102 or gNB 108 may be able to set whether or not to apply make-before-break handover (MBB-HO) for each radio bearer. When setting whether or not to apply make-before-break handover for each radio bearer, parameters related to make-before-break handover are radio bearer settings (information element indicated by SRB-ToAddMod and/or information indicated by DRB-ToAddMod). element) (lower hierarchy), or may exist under the information element indicated by PDCP-Config. Additionally, when setting whether to apply make-before-break handover for each radio bearer, the parameters related to make-before-break handover must be present under the radio bearer configuration or under the information element indicated by PDCP-Config. Instead, information on the radio bearer to which make-before-break handover is applied may be present above the radio bearer settings (in an upper layer).

FIG. 20 shows parameters (information elements or fields) for setting whether to apply make-before-break handover (MBB-HO) to a radio bearer to be established or configured in each embodiment of the present invention. , ASN. An example of 1 is shown below. The example in FIG. 20 shows an example in which there is a parameter under PDCP-Config for configuring whether or not to apply make-before-break handover to the radio bearer to be established or configured. It can exist anywhere. In addition, the above-mentioned "whether or not make-before-break handover is applied to the radio bearer to be established or configured" can be paraphrased with similar expressions such as "whether or not the radio bearer to be established or configured performs make-before-break handover." It's okay. In addition, the above-mentioned "whether or not to apply make-before-break handover to the radio bearer to be established or configured" can be changed to "whether or not to apply make-before-break handover to the PDCP entity" or "whether or not the PDCP entity applies make-before-break handover to the radio bearer to be established or configured." The PDCP entity may have a first setting and a second setting.'' The above-mentioned first setting may be a source (handover source) setting in handover. Further, the above-mentioned second setting may be a target (handover destination) setting in handover. Further, the above-mentioned first setting may be a primary setting. Further, the above-mentioned second setting may be a secondary setting. Also, it may be an expression that means that a make-before-break handover is performed by configuring both the source configuration and the target configuration, and/or both the primary configuration and the secondary configuration in one PDCP entity. However, it may be expressed in other words.

In the example of FIG. 20, the field expressed as mbb-drb is used as the parameter for "whether or not to apply make-before-break handover to the radio bearer to be established or configured," but other names may be used. It may be a field and/or an information element. (A) of FIG. 20 shows an example where mbb-drb is an enumerated type, and (B) of FIG. 20 shows an example where mbb-drb has the information element MBB-DRB as a value, and the information element MBB-DRB is Here is an example with one or more fields. In (A) of FIG. 20, if the field expressed as mbb-drb is included or is true, the PDCP entity configured in this PDCP-Config and/or the radio to which the PDCP entity is associated It may also indicate that the bearer is subject to make-before-break handover. In addition, in (B) of FIG. 20, the MBB-DRB information element includes, as settings for the handover destination, the identifier of the cell group of the handover destination (a field named targetCellGroupId), and the logical information associated with this PDCP entity at the handover destination. Some or all of the channel identifier (field named targetLogicalChannelIdentity) and other parameters (not shown) may be included.

Note that the field represented by mbb-drb shown in FIG. 20 exists as an option only when a parameter equivalent to makeBeforeBreak-r16 shown in the examples of FIGS. 10 to 13 is set; If a parameter equivalent to makeBeforeBreak-r16 shown in the example of FIG. 13 is not set, it may be assumed that the field represented by mbb-drb does not exist.

In FIG. 21, ASN. An example of 1 is shown below. As shown in FIG. 21, as one of the parameters of the information element of MakeBeforeBreak-r16 in FIG. 11 and/or FIG. 13 (for example, parameter A or parameter B shown in FIG. 11 and/or FIG. 13), the make-before-break handover There may also be information on radio bearers to which this applies. In the example of FIG. 21, fields expressed as mbb-drb and mbb-drbList (list of mbb-drb) are used as parameters for "information on radio bearers to which make-before-break handover is applied." However, it may be a field with another name and/or an information element. As shown in FIG. 21, the information on the radio bearer to which the above-described make-before-break handover is applied includes the radio bearer identifier (field expressed as drb-Identity) of the radio bearer to which the above-described make-before-break handover is applied, and the handover information. Some or all of the identifier of the previous cell group (field named targetCellGroupId), the logical channel identifier (field named targetLogicalChannelIdentity) linked to this PDCP entity at the handover destination, and other parameters (not shown) It may be. Furthermore, in the example of FIG. 21, if the parameter "information on radio bearers to which make-before-break handover is applied" does not exist, make-before-break handover is applied to all radio bearers or all data radio bearers. You may do so. Furthermore, although only data radio bearer (DRB) information is shown as "radio bearer information to which make-before-break handover is applied" in FIG. 21, signaling radio bearer (SRB) information may also be included.

FIG. 5 is a block diagram showing the configuration of the terminal device (UE 122) in each embodiment of the present invention. In order to avoid complicating the explanation, FIG. 5 shows only the main components closely related to the present invention.

The UE 122 shown in FIG. 5 includes a receiving unit 500 that receives an RRC message etc. from a base station device, and any one of various information elements (IE: Information Element), various fields, various conditions, etc. included in the received message. Alternatively, it includes a processing unit 502 that performs processing according to all setting information, and a transmitting unit 504 that transmits RRC messages and the like to the base station device. The above-mentioned base station device may be the eNB 102 or the gNB 108. Furthermore, the processing unit 502 may include some or all of the functions of various layers (eg, physical layer, MAC layer, RLC layer, PDCP layer, RRC layer, and NAS layer). That is, the processing unit 502 may include some or all of the physical layer processing unit, MAC layer processing unit, RLC layer processing unit, PDCP layer processing unit, RRC layer processing unit, and NAS layer processing unit.

FIG. 6 is a block diagram showing the configuration of a base station device in each embodiment of the present invention. In order to avoid complicating the explanation, FIG. 6 shows only the main components closely related to the present invention. The above-mentioned base station device may be the eNB 102 or the gNB 108.

The base station device shown in FIG. 6 includes a transmitting unit 600 that transmits an RRC message etc. to the UE 122, and any or all configuration information of various information elements (IE: Information Elements), various fields, various conditions, etc. The UE 122 is configured to include a processing section 602 that causes the processing section 502 of the UE 122 to perform processing by creating an included RRC message and transmitting it to the UE 122, and a receiving section 604 that receives the RRC message and the like from the UE 122. Furthermore, the processing unit 602 may include some or all of the functions of various layers (eg, physical layer, MAC layer, RLC layer, PDCP layer, RRC layer, and NAS layer). That is, the processing unit 602 may include some or all of the physical layer processing unit, MAC layer processing unit, RLC layer processing unit, PDCP layer processing unit, RRC layer processing unit, and NAS layer processing unit.

FIG. 22 is a block diagram showing the configuration of a protocol established and/or set in the UE 122 in each embodiment of the present invention. In order to avoid complicating the explanation, FIG. 22 shows only the main components closely related to the present invention. In the UE 112 shown in FIG. 22, a PDCP entity 2200, an RLC entity 2202, and an RLC entity 2204 are established and/or configured. Note that the PDCP entity 2200, RLC entity 2202, and RLC entity 2204 do not always exist, but may exist only when established and/or configured by the RRC layer, which is an upper layer. Further, the RLC entity 2202 and/or the RLC entity 2204 is not limited to one RLC entity, but may be a plurality of RLC entities. Note that the PDCP entity may be referred to as a PDCP layer or as PDCP. Furthermore, the PDCP entity 2202 may include one or more PDCP subentities for performing some functions of PDCP. Further, the RLC entity may be referred to as an RLC layer or RLC. Further, the RLC entity 2202 may be part of a first RLC bearer, and the RLC 2204 may be part of a second RLC bearer different from the first RLC bearer. In each embodiment of the present invention, RLC entity 2202 and RLC entity 2204 may be referred to as RLC bearer 2202 and RLC bearer 2204, respectively. Further, the RLC entity 2202 may be linked to a first cell group, and the RLC 2204 may be linked to a second cell group different from the first cell group. In each embodiment of the present invention, RLC entity 2202 and RLC entity 2204 may be referred to as cell group 2202 and cell group 2204, respectively. Further, a first MAC entity may exist in the first cell group, and a second MAC entity different from the first MAC entity may exist in the second cell group.

Next, protocol processing in the UE 122 in the embodiment of the present invention will be described using FIG. 4 and FIGS. 22 to 26.

In FIG. 4, the RRC layer of the eNB 102 or gNB 108 creates a message for resetting an RRC connection (step S400), and transmits it to the RRC layer of the UE 122 (step S402). If the message for reconfiguring the RRC connection includes parameters related to PDCP, the RRC layer of the UE 122 establishes the PDCP entity, configures the PDCP entity, and sends the message to the PDCP entity according to the parameters related to PDCP described above. requests, provides an encryption algorithm and an encryption key to the PDCP entity, provides an integrity protection algorithm and an integrity protection key to the PDCP entity, etc. The above-mentioned parameters related to PDCP may include parameters related to PDCP re-establishment, PDCP recovery, security, etc. in addition to PDCP settings (PDCP-Config). If the above-mentioned message for reconfiguring the RRC connection includes applying make-before-break handover (MBB-HO), the RRC layer of UE 122 applies MBB-HO to the radio bearer. Settings related to MBB-HO may be performed for the linked PDCP entity (step S404).

In addition, in step S404, if the message for reconfiguring the RRC connection includes parameters related to the cell group settings, the RRC layer of the UE 122 configures the cell group according to the parameters related to the cell group settings. Configure settings, etc. For example, if parameters related to the above cell group configuration include RLC configuration or parameters related to RLC bearers, an RLC entity is established and/or configured. The above-mentioned RLC entity may be established when a logical channel identifier to which the above-mentioned RLC configuration is associated is not configured in the above-mentioned cell group. In addition, when the RLC entity is established, the RRC layer of the UE 122 selects one of the RLC entity, RLC bearer, and logical channel based on the above-mentioned RLC configuration or the radio bearer identifier to which the RLC bearer configuration is associated. Any or all may be associated with a PDCP entity. The RRC layer of the UE 122 may associate any or all of the above-mentioned RLC entities, RLC bearers, and logical channels with PDCP entities that are associated with the same radio bearer identifier. Further, the RRC layer of the UE 122 may associate any or all of the above-mentioned RLC entities, RLC bearers, and logical channels with subentities of the PDCP entity. If there are multiple sub-entities of the PDCP entity, information regarding the sub-entities to be associated may be included in the above-mentioned message for reconfiguring the RRC connection.

FIG. 23 is an example of a processing method of the PDCP entity 2200 in each embodiment. The RLC entity 2202 may be associated with the PDCP entity 2200 or a first sub-entity (not shown) of the PDCP entity 2200 as a first RLC entity. The PDCP entity 2200 uses the encryption algorithm and encryption key provided from the upper layer RRC layer, the integrity protection algorithm and integrity protection key provided from the upper layer RRC layer, and the state of header compression (RoHC). , and other information may be associated with the RLC entity 2202. In addition, the encryption algorithm and encryption key, the integrity protection algorithm and integrity protection key provided from the upper layer RRC layer, the state of header compression (RoHC), and other information are linked to the RLC entity 2202. Some or all of the RoHC) may be applied as a state (step S2300).

Next, the PDCP entity 2200 or the second sub-entity of the PDCP entity 2200 performs one of the following (A) to (G) based on the first request from the upper layer, the RRC layer. Part or all of the processing may be performed. Note that the second sub-entity of the PDCP entity 2200 described above may be established and/or configured based on the first request being made from the RRC layer, which is an upper layer. (Step S2302)
(A) The RLC entity 2204 linked to the PDCP entity 2200 is regarded as a second RLC entity, and/or the second sub-entity of the PDCP entity 2200 and the RLC entity 2204 are linked.
(B) The information (some or all of the encryption algorithm and encryption key, the integrity protection algorithm and integrity protection key, the RoHC state, and other information) linked to the RLC entity 2202 in step S2300, Retained as part or all of the first information, that is, the first encryption algorithm, the first encryption key, the first integrity guarantee algorithm, the first integrity guarantee key, and the first RoHC state. .
(C) Applying the encryption algorithm and encryption key provided from the upper layer as a second encryption algorithm and second encryption key, and/or linking to the RLC entity 2204.
(D) Apply the integrity protection algorithm and integrity protection key provided from the upper layer as a second integrity protection algorithm and second integrity protection key, and/or link to the RLC entity 2204.
(E) Start the header compression protocol in NC (No Context) state in unidirectional mode (U-mode) as a second RoHC state for downlink reception from RLC entity 2204.
(F) Start the header compression protocol in the IR (Initialization and Refresh) state in unidirectional mode (U-mode) as the second RoHC state for uplink transmission to the RLC entity 2204.
(G) Other processing.

Note that the processes (E) and/or (F) in step S2302 may be performed only when continuation of the header compression protocol is not set by the RRC layer, which is an upper layer. Further, if continuation of the header compression protocol is set by the RRC layer, which is an upper layer, in step S2302, the first RoHC state for downlink reception described above and the first RoHC state for uplink transmission described above are set. The RoHC state may be copied to a second RoHC state for downlink reception and a second RoHC state for uplink transmission, respectively, or the RoHC state may be copied to the first RoHC state and the second RoHC state. It is also possible to have a common RoHC state without dividing it. Note that even if continuation of the header compression protocol is not set by the RRC layer, which is an upper layer, the RoHC state may not be divided into the first RoHC state and the second RoHC state, but may be a common RoHC state. Furthermore, based on the first request described above, the RoHC state may not be divided into the first RoHC state and the second RoHC state, but may be a common RoHC state. Hereinafter, in step S2302, if the RoHC state is not divided into a first RoHC state and a second RoHC state and they have a common RoHC state, in step S2400 and step S2500, which will be described later, The RoHC state and the second RoHC state may be referred to as a common RoHC state.

In step S2302, the first request may be a request to perform MBB-HO or a request to re-establish a PDCP entity. Further, in step 2302, upon receiving the first request from the upper layer, the PDCP entity 2200 further determines that the PDCP entity 2200 that received the above-mentioned first request, or Based on the fact that the first setting has been performed for the linked radio bearer, some or all of the processes (A) to (G) in step S2302 described above may be performed. The above-mentioned first setting may be a setting related to MBB-HO performed by the RRC layer, which is an upper layer. The above-mentioned settings related to MBB-HO may be to adapt MBB-HO, or to configure one of the second RLC entity, second RLC bearer, second logical channel, and second cell group. The settings may be related to some or all of the settings.

Further, in step 2302, upon receiving the first request from the upper layer, the PDCP entity 2200 further determines that the PDCP entity 2200 that received the above-mentioned first request, or Based on the fact that the first setting described above has not been performed for the associated radio bearer, some or all of the following (H) to (S) may be performed.
(H) For downlink reception from RLC entity 2204, reset the header compression protocol and start the header compression protocol in NC (No Context) state in unidirectional mode (U-mode). This process may be performed when continuation of the header compression protocol is not set by the RRC layer, which is an upper layer.
(I) Reset the header compression protocol and start the header compression protocol in the IR (Initialization and Refresh) state in unidirectional mode (U-mode) for uplink transmission to the RLC entity 2204; This process may be performed when continuation of the header compression protocol is not set by the RRC layer, which is an upper layer.
(J) On the transmitting side, set TX_NEXT (a variable meaning the COUNT value or sequence number to be assigned to the next PDCP SDU when transmitting the next PDCP SDU) to the initial value for the UM DRB.
(K) During processing of the first request, apply the encryption algorithm and encryption key provided by the upper layer.
(L) During processing of the first request, apply the integrity protection algorithm and integrity protection key provided by the upper layer.
(M) On the transmitting side, the corresponding PDCP SDU is received from the upper layer even though a sequence number is assigned to the UM DRB in the PDCP SDU, but it is not sent to the lower layer as a PDCP PDU. transmission is performed in the order of the COUNT values assigned before processing the first request. At this time, there is no need to restart the timer for deleting the transmitted PDCP SDU.
(N) On the transmitting side, transmit or retransmit PDCP SDUs whose successful transmission has not been confirmed by the lower layer to the AM DRB in the order of the COUNT values assigned before processing the first request. I do. At this time, header compression may be performed. Further, at this time, encryption and/or integrity protection may be performed using the assigned COUNT value.
(O) At the receiving side, process the PDCP DATA PDU received from the lower layer by processing the first request.
(P) On the receiving side, the stored PDCP SDUs are delivered to the upper layer in the order of the COUNT value to the UM DRB. At this time, the header may be restored. Further, this process may be performed when a reordering timer is running or when reordering is set. If the above-mentioned reordering timer is running, the above-mentioned reordering timer may be stopped and the above-mentioned reordering timer may be reset.
(Q) On the receiving side, headers are restored for all PDCP PDUs stored in the AM DRB. This process may be performed when continuation of the header compression protocol is not set by the RRC layer, which is an upper layer.
(R) On the receiving side, for the UM DRB, RX_NEXT (a variable that means the COUNT value of the PDCP SDU expected to be received next) and/or RX_DELIV (a variable that means the COUNT value of the PDCP SDU that is expected to be received next) Set the variable (meaning the COUNT value of the first PDCP SDU) to the initial value.
(S) Other processing.

Further, in step 2302, upon receiving the above-mentioned first request from the upper layer, the first sub-entity of the PDCP entity 2200 and/or the second sub-entity of the PDCP entity 2200 performs the following from (H) to ( You may perform some or all of S).
(H) Start header compression protocol in NC (No Context) state in unidirectional mode (U-mode) for downlink reception. This process may be performed when continuation of the header compression protocol is not set by the RRC layer, which is an upper layer.
(I) Start the header compression protocol in the IR (Initialization and Refresh) state in unidirectional mode (U-mode) for uplink transmission. This process may be performed when continuation of the header compression protocol is not set by the RRC layer, which is an upper layer.
(J) On the transmitting side, set TX_NEXT (a variable meaning the COUNT value or sequence number to be assigned to the next PDCP SDU when transmitting the next PDCP SDU) to the initial value for the UM DRB.
(K) During processing of the first request, apply the encryption algorithm and encryption key provided by the upper layer.
(L) During processing of the first request, apply the integrity protection algorithm and integrity protection key provided by the upper layer.
(M) On the transmitting side, the corresponding PDCP SDU is received from the upper layer even though a sequence number is assigned to the UM DRB in the PDCP SDU, but it is not sent to the lower layer as a PDCP PDU. transmission is performed in the order of the COUNT values assigned before processing the first request. At this time, there is no need to restart the timer for deleting the transmitted PDCP SDU.
(N) On the transmitting side, transmit or retransmit PDCP SDUs whose successful transmission has not been confirmed by the lower layer to the AM DRB in the order of the COUNT values assigned before processing the first request. I do. At this time, header compression may be performed. Further, at this time, encryption and/or integrity protection may be performed using the assigned COUNT value.
(O) At the receiving side, process the PDCP DATA PDU received from the lower layer by processing the first request.
(P) On the receiving side, the stored PDCP SDUs are delivered to the upper layer in the order of the COUNT value to the UM DRB. At this time, the header may be restored. Further, this process may be performed when a reordering timer is running or when reordering is set. If the above-mentioned reordering timer is running, the above-mentioned reordering timer may be stopped and the above-mentioned reordering timer may be reset.
(Q) On the receiving side, headers are restored for all PDCP PDUs stored in the AM DRB. This process may be performed when continuation of the header compression protocol is not set by the RRC layer, which is an upper layer.
(R) On the receiving side, for the UM DRB, RX_NEXT (a variable that means the COUNT value of the PDCP SDU expected to be received next) and/or RX_DELIV (a variable that means the COUNT value of the PDCP SDU that is expected to be received next) Set the variable (meaning the COUNT value of the first PDCP SDU) to the initial value.
(S) Other processing.
Note that these processes may be performed based on the above-described first setting being performed.

Further, in step S2302, a first sub-entity, a first RLC entity, first information (a first encryption algorithm and a first encryption key, a first integrity protection algorithm and a first integrity protection (key, first RoHC state, first other information) refers to the subentity, RLC entity for the handover source (source) in MBB-HO, and/or for the handover source cell group, and/or for the primary. , may be information. Further, in step S2302, a second sub-entity, a second RLC entity, second information (a second encryption algorithm and a second encryption key, a second integrity protection algorithm and a second integrity protection key, second RoHC state, second other information) is a subentity, RLC entity for the handover target in MBB-HO, and/or for the handover target cell group, and/or for the secondary. , may be information.

Furthermore, some or all of the processes (A) to (G) in step S2302 may be performed without being based on the first request being made from the RRC layer, which is an upper layer.

FIG. 24 is an example of a downlink reception processing method of the PDCP entity 2200 in each embodiment. Note that step S2400 described below is based on the fact that some or all of the steps S2300 and S2302 described above have been performed, or that some or all of the steps S2300 and S2302 described above have been performed. may be further carried out after this has been carried out.

In addition, the PDCP entity 2200, the first sub-entity of the PDCP entity 2200, and the second sub-entity of the PDCP entity 2200 in step S2400 described below are shown in some or all of the above-described steps S2300 and S2302, respectively. The PDCP entity 2200 may be a first sub-entity of the PDCP entity 2200, or a second sub-entity of the PDCP entity 2200. Further, the first RLC entity and the second RLC entity in step S2400 described below refer to the first RLC entity and the second RLC entity shown in some or all of step S2300 and step S2302 described above, respectively. It may be. In addition, the first encryption algorithm, first encryption key, second encryption algorithm, and second encryption key in step S2400 described below are a part of step S2300 and step S2302 described above, respectively. Alternatively, the first encryption algorithm, first encryption key, second encryption algorithm, and second encryption key shown in all of the above may be used. In addition, the first integrity protection algorithm, first integrity protection key, second integrity protection algorithm, and second integrity protection key in step S2400 described below are respectively referred to in step S2300 and step S2302 described above. The first integrity protection algorithm, the first integrity protection key, the second integrity protection algorithm, and the second integrity protection key shown in some or all of them may be used. In addition, the first RoHC state and the second RoHC state in step S2400 described below are the first RoHC state and the second RoHC state shown in some or all of step S2300 and step S2302 described above, respectively. It may be.

When the above-mentioned PDCP entity 2200 receives a PDCP DATA PDU from the above-mentioned first RLC entity, or the first sub-entity of the above-mentioned PDCP entity 2200, the following (A) to (C) and (G) Some or all of these processes may be performed. If the above-mentioned PDCP entity 2200 receives a PDCP DATA PDU from the above-mentioned second RLC entity, or the second sub-entity of the above-mentioned PDCP entity 2200, one of the following (D) to (G) Part or all of the processing may be performed. (Step S2400)
(A) Decryption is performed using the first encryption algorithm described above, the first encryption key described above, and the COUNT value obtained from the header of the PDCP DATA PDU received from the first RLC entity described above. .
(B) using the first integrity protection algorithm described above, the first integrity protection key described above, and the COUNT value obtained from the header of the PDCP DATA PDU received from the first RLC entity described above; Verify.
(C) Header restoration is performed using the first RoHC state described above.
(D) Perform decryption using the second encryption algorithm described above, the second encryption key described above, and the COUNT value obtained from the header of the PDCP DATA PDU received from the second RLC entity described above. .
(E) using the second integrity protection algorithm described above, the second integrity protection key described above, and the COUNT value obtained from the header of the PDCP DATA PDU received from the second RLC entity described above; Verify.
(F) Header restoration is performed using the second RoHC state described above.
(G) Other processing.
Note that (G) Other processing includes ``identifying the COUNT value using the reception window value'' and ``identifying the COUNT value using the COUNT value of the first PDCP SDU that has not yet been delivered to the upper layer.'' or if a PDCP Data PDU with the same COUNT value as the specified COUNT value has already been received, discard this PDCP Data PDU." and "If the integrity verification fails. , notify the upper layer of integrity verification failure.'' may or may not include some or all of the above.

In step S2400, re-ordering may be performed before header restoration is performed in (C) or (F), after header restoration is performed, or both before and after header restoration is performed. Reordering may be a process for storing PDCP SDUs in a reception buffer and delivering the PDCP SDUs to an upper layer in the order of COUNT values obtained from header information of PDCP DATA PDUs. In addition, reordering means that when the COUNT value of the received PDCP Data PDU is the COUNT value of the first PDCP SDU that has not yet been delivered to the upper layer, the stored PDCP SDUs are transferred to the upper layer in the order of the COUNT value. It may be a process that includes a process of passing the information to the other party. Further, the above-described reordering may be performed in a reordering subentity (not shown) of the PDCP entity 2200. The reordering sub-entity of the above-mentioned PDCP entity 2200 receives this PDCP SDU from the first sub-entity of the above-mentioned PDCP entity 2200 and/or the second sub-entity of the above-mentioned PDCP entity 2200, together with the PDCP SDU after header restoration. The COUNT value of the PDCP SDU may also be passed together.

Further, in step S2400, the first sub-entity of the above-mentioned PDCP entity 2200 and/or the second sub-entity of the above-mentioned PDCP entity 2200 performs the following from (H) to (M) based on the respective sub-entity settings. ) may be performed.
(H) Identify the COUNT value using the reception window value.
(I) Perform decoding using the specified COUNT value.
(J) Perform integrity verification using the specified COUNT value. If the integrity verification fails, the upper layer is notified of the failure of the integrity verification.
(K) If the specified COUNT value is less than the COUNT value of the first PDCP SDU that has not yet been delivered to the upper layer, or if a PDCP Data PDU with the same COUNT value as the specified COUNT value has already been received. , this PDCP Data PDU is discarded.
(L) Reordering processing is performed, and if the header is not restored, the header is restored, and the PDCP SDU is delivered to the upper layer.
(M) Other processing.

Note that the process in step S2400 may be performed based on the first setting being performed for the above-mentioned PDCP entity 2200 or the radio bearer to which the above-mentioned PDCP entity 2200 is associated. The first setting described above may be the first setting in step S2302 described above. That is, settings related to MBB-HO may be made by the RRC layer, which is an upper layer. The above-mentioned settings related to MBB-HO may be to adapt MBB-HO, or to configure one of the second RLC entity, second RLC bearer, second logical channel, and second cell group. The settings may be related to some or all of the settings. Furthermore, when the above-mentioned first setting is performed for the above-mentioned PDCP entity 2200 or the radio bearer to which the above-mentioned PDCP entity 2200 is associated, out of order delivery must be set. It's okay to be. Setting out-of-order delivery may include setting not to perform reordering before header restoration in MBB-HO.

Further, in step S2400, a first sub-entity, a first RLC entity, a first encryption algorithm and a first encryption key, a first integrity protection algorithm and a first integrity protection key, a first The RoHC state refers to subentities, RLC entities, encryption algorithms and encryption keys, and integrity protection algorithms for the handover source in MBB-HO, and/or for the handover source cell group, and/or for the primary. and an integrity protection key and RoHC state. Further, in step S2400, a second sub-entity, a second RLC entity, a second encryption algorithm and a second encryption key, a second integrity protection algorithm and a second integrity protection key, a second The RoHC state refers to the subentity, RLC entity, encryption algorithm and encryption key, and integrity protection algorithm for the handover target in MBB-HO, and/or for the handover destination cell group, and/or for the secondary. and an integrity protection key and RoHC state.

FIG. 25 is an example of an uplink transmission processing method of the PDCP entity 2200 in each of the present embodiments. Note that step 2500 described below is based on the fact that some or all of the steps S2300 and S2302 described above have been performed, or that some or all of the steps S2300 and S2302 described above have been performed. may be further carried out after this has been carried out.

In addition, the PDCP entity 2200, the first sub-entity of the PDCP entity 2200, and the second sub-entity of the PDCP entity 2200 in step S2500 described below are shown in some or all of the above-described steps S2300 and S2302, respectively. The PDCP entity 2200 may be a first sub-entity of the PDCP entity 2200, or a second sub-entity of the PDCP entity 2200. Further, the first RLC entity and the second RLC entity in step S2500 described below refer to the first RLC entity and the second RLC entity shown in some or all of step S2300 and step S2302 described above, respectively. It may be. In addition, the first encryption algorithm, first encryption key, second encryption algorithm, and second encryption key in step S2500 described below are a part of step S2300 and step S2302 described above, respectively. Alternatively, the first encryption algorithm, first encryption key, second encryption algorithm, and second encryption key shown in all of the above may be used. In addition, the first integrity protection algorithm, first integrity protection key, second integrity protection algorithm, and second integrity protection key in step S2500 described below are respectively referred to in step S2300 and step S2302 described above. The first integrity protection algorithm, the first integrity protection key, the second integrity protection algorithm, and the second integrity protection key shown in some or all of them may be used. In addition, the first RoHC state and the second RoHC state in step S2500 described below are the first RoHC state and the second RoHC state shown in some or all of step S2300 and step S2302 described above, respectively. It may be.

If the PDCP entity 2200 or the first subentity of the PDCP entity 2200 does not detect the second request, the PDCP entity 2200 or the first subentity of the PDCP entity 2200 performs the following (A) to (D) and ( Some or all of I) may be performed. In addition, the PDCP entity 2200 or a second sub-entity of the PDCP entity 2200, based on detecting the second request, performs one of the following (E) to (I) on the PDCP SDU received from the upper layer. Part or all of the processing may be performed. (Step S2500)
(A) Header compression is performed using the first header compression process described above.
(B) Encryption is performed using the first encryption algorithm described above, the first encryption key described above, and the COUNT value linked to the PDCP SDU described above.
(C) Integrity protection is performed using the first integrity protection algorithm described above, the first integrity protection key described above, and the COUNT value linked to the PDCP SDU described above.
(D) Deliver the created PDCP PDU to the first RLC entity described above.
(E) Header compression is performed using the second header compression process described above.
(F) the above second encryption algorithm, the above second encryption key, and the above PDC;
Encryption is performed using the COUNT value linked to the PSDU.
(G) Integrity protection is performed using the second integrity protection algorithm described above, the second integrity protection key described above, and the COUNT value linked to the PDCP SDU described above.
(H) Deliver the created PDCP PDU to the above-mentioned second RLC entity.
(I) Other processing.
Note that the PDCP entity 2200, or the first subentity of the PDCP entity 2200, or the second subentity of the PDCP entity 2200 has multiple associated RLC entities in (D) and/or (H). In this case, some or all of (D-1) (H-1) and (D-2) (H-2) may also be performed.
(D-1) (H-1) If PDCP duplication is activated, if it is a PDCP Data PDU, it is duplicated and submitted to both associated RLC entities; if it is a PDCP Control PDU, it is Submit to the primary RLC entity.
(D-2) (H-2) If PDCP duplication is not activated, if the two associated RLC entities belong to different cell groups and are pending for initial transmission, If the total amount of PDCP data volume and RLC data volume of two associated RLC entities is greater than or equal to the uplink data threshold, submit the PDCP PDU to the primary RLC entity or the secondary RLC entity; (The two associated RLC entities belong to different and the same cell groups and/or are pending for initial transmission, the PDCP data volume and the total RLC data volume of the two associated RLC entities) If the amount is less than the uplink data threshold, then submit the PDCP PDU to the primary RLC entity.

Further, in step S2500, based on the fact that the PDCP entity 2200 or the first sub-entity of the PDCP entity 2200 has not detected the second request, the first sub-entity of the PDCP entity 2200 receives the second request from the upper layer. Based on the set first information, some or all of the following processes (J) to (R) may be performed on the PDCP SDU. In addition, in step S2500, the PDCP entity 2200 or the second sub-entity of the PDCP entity 2200 detects the second request, and the first sub-entity of the PDCP entity 2200 receives the PDCP received from the upper layer. Some or all of the following processes (J) to (R) may be performed on the SDU based on the set second information.
(J) If a discard timer is set, start the discard timer.
(K) Associate the COUNT value corresponding to TX_NEXT (a variable meaning the COUNT value or sequence number assigned to the next PDCP SDU when transmitting that PDCP SDU) with the received PDCP SDU.
(L) Perform header compression.
(M) Encrypt using TX_NEXT.
(N) Perform integrity protection using TX_NEXT.
(O) Calculate and set the sequence number from TX_NEXT.
(P) Increment TX_NEXT by 1.
(Q) Submit the created PDCP Data PDU to the lower layer as follows.
(Q-1) When one RLC entity is associated with a sub-entity, a PDCP PDU is submitted to this associated RLC entity.
(Q-2) When two RLC entities are associated with a subentity:
(Q-2-1) If PDCP duplication is activated, if it is a PDCP Data PDU, it will be duplicated and submitted to both associated RLC entities, and if it is a PDCP Control PDU, it will be sent to the primary RLC entity. Submit to entity.
(Q-2-2) If PDCP duplication is not activated, if the two associated RLC entities belong to different cell groups, the PDCP data volume pending for initial transmission and the total amount of RLC data volumes of the two associated RLC entities is equal to or greater than the uplink data threshold, then the PDCP PDU is submitted to the primary RLC entity or the secondary RLC entity, and the other (2 The total amount of PDCP data volume and RLC data volume of two associated RLC entities belonging to different and same cell groups and/or pending for initial transmission is If the uplink data is less than the threshold, then submit the PDCP PDU to the primary RLC entity.
(R) Other processing.

In step S2500 described above, the second request may be detected by receiving the second request from an upper layer or a lower layer. Further, in step S2500 described above, the method of detecting the second request may be a method of detecting the second request by expiring a timer set in the PDCP entity 2200 to detect the second request. . Further, in step S2500 described above, the method of detecting the second request may be a method of detecting the second request by implementation of the terminal device.

Note that in step S2500 described above, the second request may be a request to switch the submission destination of the PDCP PDU from the first RLC entity described above to the second RLC entity described above in the transmission process. , may be a request to perform MBB-HO. In addition, the second request mentioned above refers to the PDCP in the transmission process when performing MBB-HO.
Any other name may be used as long as the request means switching the PDU submission destination from the first RLC entity described above to the second RLC entity described above.

Note that the process in step S2302 (F) described above may be performed after the second request described above is detected or immediately before the second request described above is detected.

Note that the process in step S2500 may be performed based on the first setting being performed for the above-mentioned PDCP entity 2200 or the radio bearer to which the above-mentioned PDCP entity 2200 is associated. The first setting described above may be the first setting in step S2302 described above. That is, settings related to MBB-HO may be made by the RRC layer, which is an upper layer. The above-mentioned settings related to MBB-HO may be to adapt MBB-HO, or to configure one of the second RLC entity, second RLC bearer, second logical channel, and second cell group. The settings may be related to some or all of the settings. Further, the process of step S2500 may be performed based on the case where the PDCP entity 2200 is further associated with two or more RLC entities.

Furthermore, if two or more RLC entities are associated with the PDCP entity 2200, and the first setting described above is not performed, the PDCP entity 2200 performs the following (S) to ( Some or all of U) may be performed.
(S) If PDCP duplication is activated, the PDCP
For Data PDUs, it is duplicated and submitted to both associated RLC entities; for PDCP Control PDUs, it is submitted to the primary RLC entity.
(T) If PDCP duplication is not activated, if the two associated RLC entities belong to different cell groups, the PDCP data volume pending for initial transmission and the two If the total amount of RLC data volume of the associated RLC entities is equal to or greater than the uplink data threshold, the PDCP PDU is submitted to the primary RLC entity or the secondary RLC entity, and the other (two associated The total amount of PDCP data volume and RLC data volume of two associated RLC entities belonging to different and same cell groups and/or pending for initial transmission is the same as that of uplink data. If less than the threshold), submit the PDCP PDU to the primary RLC entity.
(U) Other processing.

Further, in step S2500, a first sub-entity, a first RLC entity, a first encryption algorithm and a first encryption key, a first integrity protection algorithm and a first integrity protection key, a first The RoHC state refers to subentities, RLC entities, encryption algorithms and encryption keys, and integrity protection algorithms for the handover source in MBB-HO, and/or for the handover source cell group, and/or for the primary. and an integrity protection key and RoHC state. Further, in step S2500, a second sub-entity, a second RLC entity, a second encryption algorithm and a second encryption key, a second integrity protection algorithm and a second integrity protection key, a second The RoHC state refers to the subentity, RLC entity, encryption algorithm and encryption key, and integrity protection algorithm for the handover target in MBB-HO, and/or for the handover destination cell group, and/or for the secondary. and an integrity protection key and RoHC state.

Further, the MAC entity of the second cell group described above, in which the second RLC entity described above is configured, sends the first notification to the upper layer after receiving the first uplink grant from the base station device. It's okay. The first notification may be a notification regarding the reception of the first uplink grant, or may be a notification regarding the reception of the first uplink grant, or may be a notification regarding the reception of the first uplink grant, or the first notification may be a notification regarding the reception of the first uplink grant. The notification may mean switching to some or all of the cell groups. Note that after the MAC entity receives the first uplink grant from the base station device, the process of sending the first notification to the upper layer may be performed based on the fact that MBB-HO is configured.

FIG. 26 is another example of the processing method of the PDCP entity 2200 in each embodiment. Note that step S2600 described below is based on the fact that some or all of the steps S2300 and S2302 described above have been performed, or that some or all of the steps S2300 and S2302 described above have been performed. may be further carried out after this has been carried out.

In addition, the PDCP entity 2200, the first sub-entity of the PDCP entity 2200, and the second sub-entity of the PDCP entity 2200 in step S2600 described below are shown in some or all of the above-described steps S2300 and S2302, respectively. The PDCP entity 2200 may be a first sub-entity of the PDCP entity 2200, or a second sub-entity of the PDCP entity 2200. In addition, the first RLC entity and the second RLC entity in step S2600 described below refer to the first RLC entity and the second RLC entity shown in some or all of step S2300 and step S2302 described above, respectively. It may be an entity. In addition, the first encryption algorithm, first encryption key, second encryption algorithm, and second encryption key in step S2600 described below are a part of step S2300 and step S2302 described above, respectively. Alternatively, the first encryption algorithm, first encryption key, second encryption algorithm, and second encryption key shown in all of the above may be used. In addition, the first integrity protection algorithm, first integrity protection key, second integrity protection algorithm, and second integrity protection key in step S2600 described below are respectively referred to in step S2300 and step S2302 described above. The first integrity protection algorithm, the first integrity protection key, the second integrity protection algorithm, and the second integrity protection key shown in some or all of them may be used. In addition, the first RoHC state and the second RoHC state in step S2600 described below are the first RoHC state and the second RoHC state shown in some or all of step S2300 and step S2302 described above, respectively. It may be. Further, the first setting in step S2600 described below may be the first setting in step S2302 described above.

When the PDCP entity 2200 detects the third request, it may perform some or all of the following (A) to (K). (Step S2600)
(A) Consider the second RLC entity described above as the first RLC entity.
(B) The second radio bearer associated with the second RLC entity described above is regarded as the first radio bearer.
(C) The second RLC bearer associated with the second RLC entity described above is regarded as the first RLC bearer.
(D) The second cell group to which the second RLC entity is associated is regarded as the first cell group.
(E) The second MAC entity to which the second RLC entity is linked is regarded as the first MAC entity.
(F) The above-mentioned second encryption algorithm and the above-mentioned second encryption key are regarded as the first encryption algorithm and the first encryption key, respectively.
(G) The above second integrity protection algorithm and the above second integrity protection key are regarded as a first integrity protection algorithm and a first integrity protection key, respectively.
(H) Consider the second RoHC state described above as the first RoHC state.
(I) Delete the first setting described above.
(J) Consider the second sub-entity of the PDCP entity 2200 described above as the first sub-entity of the PDCP entity 2200.
(K) Other processing.

The detection of the third request in step S2600 described above may mean that the first RLC entity is released and/or stopped in step S2300 and/or step S2302 described above. Further, the detection of the third request in step S2600 described above may be the detection of the second request in step S2500 described above. Further, the detection of the third request in step S2600 described above may be performed by a timer set in the PDCP entity 2200 expiring to detect the third request. Further, the third request in step S2600 described above may be detected by receiving the third request from an upper layer or a lower layer. Further, in step S2600 described above, the method of detecting the second request may be a method of detecting the second request by implementation of the terminal device.

Further, in step S2600, a first sub-entity, a first RLC entity, a first radio bearer, a first RLC bearer, a first cell group, a first MAC entity, a first encryption algorithm, and a first The encryption key, the first integrity protection algorithm, the first integrity protection key, and the first RoHC state are for the handover source in MBB-HO and/or for the handover source cell group. and/or the primary subentity, RLC entity, radio bearer, RLC bearer, cell group, MAC entity, encryption algorithm and encryption key, integrity protection algorithm and integrity protection key, RoHC state. Further, in step S2600, a second sub-entity, a second RLC entity, a second radio bearer, a second RLC bearer, a second cell group, a second MAC entity, a second encryption algorithm, and a second The encryption key, the second integrity protection algorithm, the second integrity protection key, and the second RoHC state are for the handover target in MBB-HO and/or for the handover target cell group. and/or secondary sub-entities, RLC entities, radio bearers, RLC bearers, cell groups, MAC entities, encryption algorithms and keys, integrity protection algorithms and keys, RoHC states.

In this way, in the embodiment of the present invention, efficient communication can be performed during handover of the UE 122.

In the above description, expressions such as "linked," "corresponding," and "associated" may be used interchangeably.

In the above description, "in the case of MBB-HO" means that when performing RRC connection reconfiguration including MobilityControlInfo in LTE, or when performing RRC reconfiguration including reconfiguration with synchronization in NR, in the source cell. It may be a case of transmitting and/or receiving in the target cell while continuing to transmit and/or receive user data, or it may be expressed by other names that mean equivalent operations. . In addition, "in the case of MBB-HO" means that in LTE or NR, a specific information element (for example, the MakeBeforeBreak-r16 information element shown in FIGS. 10 to 13 and 21, and/or mbb-drb) may be included in the RRC reconfiguration message. In addition, "in the case of MBB-HO" is a case where the time during which data communication is not possible between the terminal device and the base station device (disruption time) is set to zero milliseconds (0 msec) or close to zero milliseconds. It may be a thing, or it may be expressed by another name that means this.

In the above description, "MBB-HO settings" refers to the settings that are used in the source cell when performing RRC connection reconfiguration including MobilityControlInfo in LTE, or when performing RRC reconfiguration including reconfiguration with synchronization in NR. It may be a setting for transmitting and/or receiving data in the target cell while continuing to transmit and/or receive user data, or it may be expressed by another name that means an equivalent setting. good. In addition, "MBB-HO settings" refers to specific information elements (for example, the MakeBeforeBreak-r16 information element shown in FIGS. 10 to 13 and 21, and/or the information shown in FIGS. 20 to 21) in LTE or NR. mbb-drb) may be included in the RRC reconfiguration message. In addition, "in the case of MBB-HO" is a case where the time during which data communication is not possible between the terminal device and the base station device (disruption time) is set to zero milliseconds (0 msec) or close to zero milliseconds. It may be a thing, or it may be expressed by another name that means this.

Furthermore, in the above description, "applying make-before-break handover (MBB-HO)" refers to when performing RRC connection reconfiguration including MobilityControlInfo in LTE, or when performing RRC reconfiguration including reconfiguration with synchronization in NR. When doing so, it may be applied to transmit and/or receive user data in the target cell while continuing to transmit and/or receive user data in the source cell, or equivalent processing may be applied. It may also be expressed by other names. In addition, "applying MBB-HO" means that in LTE or NR, a specific information element (for example, the MakeBeforeBreak-r16 information element shown in FIGS. 10 to 13 and 21, and/or (mbb-drb) is included in the RRC reconfiguration message. Furthermore, "applying MBB-HO" means processing to reduce the time during which data communication is unavailable between the terminal device and the base station device (disruption time) to zero milliseconds (0 msec) or to bring it close to zero milliseconds. It may be applied, or it may be expressed by another name that means this.

Note that in each embodiment of the present invention, handover may be referred to as reconfiguration with sync. For example, make-before-break handover may be referred to as reset with make-before-break synchronization.

In addition, in the above description, "A may be replaced with B" may include the meaning of replacing A with B, as well as replacing B with A.

In the above description, the primary subentity, primary RLC entity, and/or primary MAC entity of PDCP is the source side (for example, handover source or SCG Change source) when performing reconfiguration with synchronization (for example, handover or SCG Change). ) or can be an entity. The primary subentity of PDCP, the primary RLC entity, and/or the primary MAC entity may be an entity that is or can be a target of RRC reconfiguration that is not synchronous reconfiguration (for example, handover or SCG Change). The PDCP secondary subentity, secondary RLC entity, and/or secondary MAC entity is an entity that becomes the target side (for example, handover destination or SCG Change destination) when performing reconfiguration with synchronization (for example, handover or SCG Change). It's fine. The PDCP secondary subentity, the secondary RLC entity, and/or the secondary MAC entity may be an entity that exists only in the presence of the PDCP primary subentity, the primary RLC entity, and/or the primary MAC entity. . Also, the primary subentity of PDCP, the primary RLC entity, and/or the primary MAC entity may be an entity that exists in the absence of the secondary subentity of PDCP, the secondary RLC entity, and/or the secondary MAC entity. .

Hereinafter, various aspects of the terminal device and the base station device in the embodiment of the present invention will be described.

(1) A first embodiment of the present invention is a terminal device that communicates with a base station device, which includes a receiving unit that receives an RRC message from the base station device, and a process that performs processing based on the RRC message. The RRC message includes settings for each cell group, and the RRC message includes settings for a certain cell group (first cell group) based on the first information included in the RRC message. to generate a MAC entity (second MAC entity) different from the MAC entity (first MAC entity) of the existing first cell group, and add information regarding the logical channel ( second information), a second MAC entity is configured using a logical channel according to the second information.

(2) In the first embodiment, the first MAC entity is a primary MAC entity, and the second MAC entity is a secondary MAC entity.

(3) In the first embodiment, when the terminal device detects release or suspension of the first MAC entity or a second request, the terminal device assigns the second MAC entity as the primary MAC entity. MAC entity.

(4) A second embodiment of the present invention is a base station device that communicates with a terminal device, comprising a transmitting unit that transmits an RRC message to the terminal device, and a processing unit that generates the RRC message, The RRC message includes one or more settings for each cell group, and based on including the first information in the RRC message, the existing settings for a certain cell group (first cell group) The terminal device generates a MAC entity (second MAC entity) different from the MAC entity (first MAC entity) of one cell group, and the second MAC entity is added to the settings for the first cell group. Contains information (second information) regarding the logical channel for setting up the logical channel.

(5) A third embodiment of the present invention is a method applied to a terminal device communicating with a base station device, which includes the steps of receiving an RRC message from the base station device; processing, the RRC message includes settings for each of one or more cell groups, and based on the first information being included in the RRC message, a certain cell group (a first Generate a MAC entity (second MAC entity) different from the MAC entity (first MAC entity) of the existing first cell group for the cell group), and configure the settings for the first cell group. If information regarding a logical channel (second information) is included, a second MAC entity is configured using a logical channel according to the second information.

(6) A fourth embodiment of the present invention is a method applied to a base station device communicating with a terminal device, which includes the steps of transmitting an RRC message to the terminal device, and generating the RRC message. and, the RRC message includes settings for each of one or more cell groups, and based on including first information in the RRC message, a configuration for a certain cell group (first cell group) is provided. On the other hand, the terminal device generates a MAC entity (second MAC entity) different from the MAC entity (first MAC entity) of the existing first cell group, and the settings for the first cell group include: Information regarding the logical channel for configuring the second MAC entity (second information) is included.

(7) A fifth embodiment of the present invention is an integrated circuit installed in a terminal device that communicates with a base station device, which has a function of receiving an RRC message from the base station device, and a function based on the RRC message. and a function for performing a process based on the fact that the RRC message includes settings for each of one or more cell groups, and that the RRC message includes first information. , generates a MAC entity (second MAC entity) different from the existing MAC entity of the first cell group (first MAC entity) for a certain cell group (first cell group), and If the configuration for one cell group includes information regarding a logical channel (second information), a second MAC entity is configured using the logical channel according to the second information.

(8) A sixth embodiment of the present invention is an integrated circuit installed in a base station device that communicates with a terminal device, which has a function of transmitting an RRC message to the terminal device and generating the RRC message. function for the base station apparatus, the RRC message includes settings for each of one or more cell groups, and based on including the first information in the RRC message, a certain cell causing the terminal device to generate a MAC entity (second MAC entity) different from the MAC entity (first MAC entity) of the existing first cell group for the group (first cell group); Information (second information) regarding a logical channel for configuring a second MAC entity is included in the configuration for the first cell group.

The program that runs on the device related to the present invention may be a program that controls the Central Processing Unit (CPU) or the like to make the computer function so as to realize the functions of the above-described embodiments related to the present invention. . Programs or information handled by programs are temporarily read into volatile memory such as Random Access Memory (RAM) during processing, or stored in non-volatile memory such as flash memory or Hard Disk Drive (HDD), and then transferred as needed. Reading, modification, and writing are performed by the CPU accordingly.

Note that a part of the apparatus in the embodiment described above may be realized by a computer. In that case, the program for realizing this control function is recorded on a computer-readable recording medium, and the program recorded on the recording medium is read into the computer system and executed. Good too. The "computer system" herein refers to a computer system built into the device, and includes hardware such as an operating system and peripheral devices. Further, the "computer-readable recording medium" may be any semiconductor recording medium, optical recording medium, magnetic recording medium, etc.

Furthermore, a ``computer-readable recording medium'' refers to a computer-readable storage medium that dynamically stores a program for a short period of time, such as a communication line when transmitting a program via a network such as the Internet or a communication line such as a telephone line. It may also include a device that retains a program for a certain period of time, such as a volatile memory inside a computer system that serves as a server or client. Further, the above-mentioned program may be one for realizing a part of the above-mentioned functions, or may be one that can realize the above-mentioned functions in combination with a program already recorded in the computer system. .

Additionally, each functional block or feature of the apparatus used in the embodiments described above may be implemented or performed in an electrical circuit, typically an integrated circuit or multiple integrated circuits. An electrical circuit designed to perform the functions described herein may be a general purpose processor, digital signal processor (DSP), application specific integrated circuit (ASIC), field programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic, discrete hardware components, or combinations thereof. A general purpose processor may be a microprocessor, or in the alternative, the processor may be a conventional processor, controller, microcontroller, or state machine. The general-purpose processor or each of the circuits described above may be configured with a digital circuit or an analog circuit. Further, if an integrated circuit technology that replaces the current integrated circuit emerges due to advances in semiconductor technology, it is also possible to use an integrated circuit based on this technology.

Note that the present invention is not limited to the above-described embodiments. Although an example of the device has been described in the embodiment, the present invention is not limited thereto, and can be applied to stationary or non-movable electronic devices installed indoors or outdoors, such as AV devices, kitchen devices, It can be applied to terminal devices or communication devices such as cleaning/washing equipment, air conditioning equipment, office equipment, vending machines, and other household equipment.

Although the embodiments of the present invention have been described above in detail with reference to the drawings, the specific configuration is not limited to these embodiments, and may include design changes within the scope of the gist of the present invention. Furthermore, the present invention can be modified in various ways within the scope shown in the claims, and embodiments obtained by appropriately combining technical means disclosed in different embodiments are also included within the technical scope of the present invention. It will be done. Also included are configurations in which the elements described in the above embodiments are replaced with each other and have similar effects.

100 E-UTRA
102 eNB
104 EPC
106NR
108 gNB
110 5GC
112, 114, 116, 118, 120, 124 Interface 122 UE
200, 300 PHY
202, 302 MAC
204, 304 RLC
206, 306 PDCP
208, 308 RRC
310 SDAP
210, 312 NAS
500, 604 Receiving section 502, 602 Processing section 504, 600 Transmitting section 2200 PDCP entity 2202, 2204 RLC entity

Claims (3)

A terminal device that communicates with a base station device,
a receiving unit that receives an RRC message from the base station device;
a processing unit that performs processing based on the RRC message;
Equipped with
The RRC message includes settings for a first cell group,
When the RRC message includes first information, a second MAC entity different from the existing first cell group MAC entity (first MAC entity) for the first cell group is generated. ,
the first MAC entity is reset if the RRC message does not include first information;
Terminal device. A base station device that communicates with a terminal device,
a transmitter that transmits an RRC message to the terminal device;
a processing unit that generates the RRC message;
Equipped with
The RRC message includes settings for a first cell group,
Based on including the first information in the RRC message, a MAC entity (second MAC entity) different from an existing MAC entity (first MAC entity) of the first cell group for the first cell group MAC entity) in the terminal device,
causing the first MAC entity to reset based on not including first information in the RRC message;
Base station equipment. A control method used for a base station device communicating with a terminal device, the control method comprising:
Sending an RRC message to the terminal device;
generating the RRC message;
Equipped with
The RRC message includes settings for a first cell group,
Based on including the first information in the RRC message, a MAC entity (second MAC entity) different from an existing MAC entity (first MAC entity) of the first cell group for the first cell group MAC entity) in the terminal device,
causing the first MAC entity to reset based on not including first information in the RRC message;
Control method.

Images