JP7802678B2 - Terminal device, base station device, and method - Google Patents

Description

The present invention relates to a terminal device, a base station device, and a method.
This application claims priority to Japanese Patent Application No. 2020-173019, filed on October 14, 2020, the contents of which are incorporated herein by reference.

The 3rd Generation Partnership Project (3GPP), a standardization project for cellular mobile communication systems, is conducting technical studies and developing standards for cellular mobile communication systems, including radio access, core networks, services, etc.

For example, technical studies and standardization of E-UTRA (Evolved Universal LTE Terrestrial Radio Access) have begun at 3GPP as a radio access technology (RAT) for 3.9G and 4G cellular mobile communication systems. 3GPP is currently conducting technical studies and standardization of E-UTRA extension technologies. E-UTRA is also known as Long Term Evolution (LTE: registered trademark), and the extension technologies are sometimes referred to as LTE-Advanced (LTE-A) and LTE-Advanced Pro (LTE-A Pro).

In addition, 3GPP has begun technical studies and standardization of NR (New Radio, or NR Radio access) as a radio access technology (RAT) for 5th Generation (5G) cellular mobile communication systems. 3GPP is currently conducting technical studies and standardization of NR extension technologies.

3GPP TS 38.300v 16.2.0,"NR;NR and NG-RAN Overall description; Stage 2" pp10-134 3GPP TS 36.300 v16.2.0,"Evolved Universal Terrestrial Radio Access (E-UTRA)and Evolved Universal Terrestrial Radio Access Network (E-UTRAN);Overall description; Stage 2" pp19-361 3GPP TS 38.331 v16.2.0,"NR;Radio Resource Control (RRC);Protocol specifications"pp21-861 3GPP TS 36.331 v16.1.0,"Evolved Universal Terrestrial Radio Access (E-UTRA);Radio Resource Control (RRC);Protocol specifications" pp25-1012 3GPP TS 37.340 v16.2.0,"EvolvedUniversal Terrestrial Radio Access (E-UTRA)and NR; Multi-Connectivity; Stage 2" pp6-67 3GPP TS 38.321 v16.1.0, "NR;Medium Access Control (MAC) protocol specification" pp8-148

To enable high-volume data communications, an extension of NR is dual connectivity (also known as multi-connectivity), which uses multiple cell groups to allow communication between one or more base station devices and a terminal device. With this dual connectivity, in order to communicate in each cell group, the terminal device must monitor each cell group for messages addressed to it. To ensure low-latency communications when large volumes of data communications occur, the terminal device must constantly monitor multiple cell groups, consuming a lot of power. Therefore, technology to monitor some cell groups less frequently or to stop monitoring them altogether (cell group deactivation technology) is being studied.

In addition to the behavior of terminal devices when a cell group is in an inactive state, it is also necessary to consider the behavior of terminal devices when activating (recovering) from an inactive state.

One aspect of the present invention has been made in consideration of the above-mentioned circumstances, and one of its objectives is to provide a terminal device, base station device, and method that can efficiently perform communication control.

In order to achieve the above object, one aspect of the present invention takes the following measures. That is, one aspect of the present invention is a terminal device that communicates with a base station device, and includes: a receiving unit that receives a first RRC message from the base station device, the first RRC message including parameters for synchronous reconfiguration of an SpCell of a first cell group; and a processing unit that resumes suspended radio bearers based on the reception of the first RRC message, and the processing unit determines whether to resume all suspended radio bearers based on whether the first RRC message includes first information.

Another aspect of the present invention is a base station device that communicates with a terminal device, comprising: a transmitting unit that transmits a first RRC message to the terminal device, the RRC message including parameters for synchronous reconfiguration of an SpCell of a first cell group; and a processing unit that causes the terminal device to resume suspended radio bearers based on the transmission of the first RRC message, and the processing unit causes the terminal device to determine whether to resume all suspended radio bearers depending on whether the first RRC message includes first information.

Another aspect of the present invention is a method applied to a terminal device communicating with a base station device, comprising the steps of receiving a first RRC message from the base station device, the first RRC message including parameters for synchronous reconfiguration of an SpCell of a first cell group, and resuming suspended radio bearers based on the reception of the first RRC message, and determining whether to resume all suspended radio bearers based on whether the first RRC message includes first information.

Another aspect of the present invention is a method applied to a base station device communicating with a terminal device, comprising the steps of: transmitting a first RRC message to the terminal device, the first RRC message including parameters for synchronous reconfiguration of an SpCell of a first cell group; and causing the terminal device to resume suspended radio bearers based on the transmission of the first RRC message, and causing the terminal device to determine whether to resume all suspended radio bearers depending on whether the first information is included in the first RRC message.

Another aspect of the present invention is an integrated circuit implemented in a terminal device that communicates with a base station device, which causes the terminal device to perform the functions of receiving a first RRC message from the base station device, the first RRC message including parameters for synchronous reconfiguration of an SpCell of a first cell group, and resuming suspended radio bearers based on the reception of the first RRC message, and the processing unit determines whether to resume all suspended radio bearers based on whether the first information is included in the first RRC message.

Another aspect of the present invention is an integrated circuit implemented in a base station device that communicates with a terminal device, which causes the base station device to perform the functions of transmitting a first RRC message to the terminal device, the first RRC message including parameters for synchronous reconfiguration of an SpCell of a first cell group, and of causing the terminal device to resume suspended radio bearers based on the transmission of the first RRC message, and the processing unit causes the terminal device to determine whether to resume all suspended radio bearers based on whether the first information is included in the first RRC message.

In addition, these comprehensive or specific aspects may be realized as a system, device, method, integrated circuit, computer program, or recording medium, or as any combination of a system, device, method, integrated circuit, computer program, and recording medium.

According to one aspect of the present invention, a terminal device, a base station device, a method, and an integrated circuit can realize efficient communication control processing.

1 is a schematic diagram of a communication system according to an embodiment of the present invention. FIG. 1 is a diagram illustrating an example of an E-UTRA protocol configuration according to an embodiment of the present invention. FIG. 1 is a diagram of an example of an NR protocol configuration according to an embodiment of the present invention. FIG. 2 is a diagram showing an example of a flow of procedures for various settings in an RRC according to an embodiment of the present invention. FIG. 2 is a block diagram showing the configuration of a terminal device according to an embodiment of the present invention. FIG. 1 is a block diagram showing a configuration of a base station device according to an embodiment of the present invention. An example of an ASN.1 description included in a message regarding re-establishment of an RRC connection in NR in an embodiment of the present invention. 10 is an example of an ASN.1 description included in a message regarding re-establishment of an RRC connection in E-UTRA according to an embodiment of the present invention. 3 shows an example of ASN.1 description of an RRC reconfiguration message according to an embodiment of the present invention. 10 shows an example of ASN.1 description of a cell group configuration information element in the embodiment of the present invention. 10 shows an example of an ASN.1 description of SpCell settings in an embodiment of the present invention. 10 is an example of ASN.1 description of a synchronization-attached reconfiguration information element according to an embodiment of the present invention. 10 shows an example of an ASN.1 description of a ServingCellConfigCommon information element in the embodiment of the present invention. 10 shows an example of ASN.1 description of an SCell configuration information element according to an embodiment of the present invention. 10 shows an example of processing by a terminal device according to an embodiment of the present invention.

The following describes in detail the embodiments of the present invention with reference to the drawings.

LTE (and LTE-A, LTE-A Pro) and NR may be defined as different radio access technologies (RATs). NR may also be defined as a technology included in LTE. LTE may also be defined as a technology included in NR. LTE that can connect to NR via Multi Radio Dual connectivity (MR-DC) may be distinguished from conventional LTE. LTE that uses 5GC in the core network may be distinguished from conventional LTE that uses EPC in the core network. Conventional LTE may refer to LTE that does not implement technologies standardized in 3GPP Release 15 or later. Embodiments of the present invention may be applied to NR, LTE, and other RATs. The following description uses terminology related to LTE and NR, but embodiments of the present invention may also be applied to other technologies that use other terminology. The term E-UTRA in embodiments of the present invention may be replaced with the term LTE, and the term LTE may be replaced with the term E-UTRA.

In the embodiments of the present invention, the names of each node and entity and the processing at each node and entity when the radio access technology is E-UTRA or NR are described, but the embodiments of the present invention may be used for other radio access technologies. The names of each node and entity in the embodiments of the present invention may be different names.

Figure 1 is a schematic diagram of a communication system relating to an embodiment of the present invention. Note that the functions of each node, radio access technology, core network, interface, etc. described using Figure 1 are only some of the functions closely related to the embodiment of the present invention, and other functions may also be included.

E-UTRA 100 may be a radio access technology. E-UTRA 100 may also be the air interface between UE 122 and eNB 102. The air interface between UE 122 and eNB 102 may be referred to as the Uu interface. eNB (E-UTRAN Node B) 102 may be a base station device for E-UTRA 100. eNB 102 may have the E-UTRA protocol described below. The E-UTRA protocol may be composed of the E-UTRA User Plane (UP) protocol described below and the E-UTRA Control Plane (CP) protocol described below. eNB 102 may terminate the E-UTRA User Plane (UP) protocol and the E-UTRA Control Plane (CP) protocol for UE 122. A radio access network composed of eNBs may be referred to as E-UTRAN.

EPC (Evolved Packet Core) 104 may be a core network. Interface 112 is an interface between eNB 102 and EPC 104 and may be referred to as an S1 interface. Interface 112 may include a control plane interface through which control signals pass and/or a user plane interface through which user data passes. The control plane interface of interface 112 may terminate at a Mobility Management Entity (MME: not shown) in EPC 104. The user plane interface of interface 112 may terminate at a Serving Gateway (S-GW: not shown) in EPC 104. The control plane interface of interface 112 may be referred to as an S1-MME interface. The user plane interface of interface 112 may be referred to as an S1-U interface.

Note that one or more eNBs 102 may be connected to the EPC 104 via an interface 112. An interface may exist between multiple eNBs 102 connected to the EPC 104 (not shown). The interface between multiple eNBs 102 connected to the EPC 104 may be referred to as an X2 interface.

NR106 may be a radio access technology. NR106 may also be an air interface between UE122 and gNB108. The air interface between UE122 and gNB108 may be referred to as a Uu interface. gNB (g Node B)108 may be a base station device of NR106. gNB108 may have the NR protocol described below. The NR protocol may consist of the NR user plane (User Plane: UP) protocol described below and the NR control plane (Control Plane: CP) protocol described below. gNB108 may terminate the NR user plane (User Plane: UP) protocol and the NR control plane (Control Plane: CP) protocol for UE122.

5GC110 may be a core network. Interface 116 is an interface between gNB108 and 5GC110 and may be referred to as an NG interface. Interface 116 may have a control plane interface through which control signals pass and/or a user plane interface through which user data passes. The control plane interface of interface 116 may terminate in an Access and Mobility Management Function (AMF: not shown) within 5GC110. The user plane interface of interface 116 may terminate in a User Plane Function (UPF: not shown) within 5GC110. The control plane interface of interface 116 may be referred to as an NG-C interface. The user plane interface of interface 116 may be referred to as an NG-U interface.

Note that one or more gNBs 108 may be connected to 5GC 110 via interface 116. An interface may exist between multiple gNBs 108 connected to 5GC 110 (not shown). The interface between multiple gNBs 108 connected to 5GC 110 may be referred to as an Xn interface.

The eNB102 may have the ability to connect to the 5GC110. The eNB102 with the ability to connect to the 5GC110 may be referred to as an ng-eNB. The interface 114 is an interface between the eNB102 and the 5GC110 and may be referred to as an NG interface. The interface 114 may have a control plane interface through which control signals pass and/or a user plane interface through which user data passes. The control plane interface of the interface 114 may terminate in the Access and Mobility Management Function (AMF: not shown) within the 5GC110. The user plane interface of the interface 114 may terminate in the User Plane Function (UPF: not shown) within the 5GC110. The control plane interface of the interface 114 may be referred to as an NG-C interface. The user plane interface of the interface 114 may be referred to as an NG-U interface. A radio access network consisting of an ng-eNB or a gNB may be referred to as an NG-RAN. The NG-RAN, E-UTRAN, eNB, ng-eNB, gNB, etc. may simply be referred to as a network.

Note that one or more eNB102 may be connected to 5GC110 via interface 114. An interface may exist between multiple eNB102 connected to 5GC110 (not shown). The interface between multiple eNB102 connected to 5GC110 may be referred to as an Xn interface. Furthermore, an eNB102 connected to 5GC110 and a gNB108 connected to 5GC110 may be connected via interface 120. The interface 120 between an eNB102 connected to 5GC110 and a gNB108 connected to 5GC110 may be referred to as an Xn interface.

The gNB108 may have the ability to connect to the EPC104. A gNB108 with the ability to connect to the EPC104 may be referred to as an en-gNB. Interface 118 is an interface between the gNB108 and the EPC104 and may be referred to as an S1 interface. Interface 118 may have a user plane interface through which user data passes. The user plane interface of interface 118 may terminate at an S-GW (not shown) in the EPC104. The user plane interface of interface 118 may be referred to as an S1-U interface. Furthermore, the eNB102 connecting to the EPC104 and the gNB108 connecting to the EPC104 may be connected by interface 120. The interface 120 between the eNB102 connecting to the EPC104 and the gNB108 connecting to the EPC104 may be referred to as an X2 interface.

Interface 124 is an interface between EPC 104 and 5GC 110, and may be an interface that passes only CP, only UP, or both CP and UP. Furthermore, some or all of interfaces such as interface 114, interface 116, interface 118, interface 120, and interface 124 may not exist depending on the communication system provided by the telecommunications carrier, etc.

UE122 may be a terminal device capable of receiving broadcast information and paging messages transmitted from eNB102 and/or gNB108. UE122 may also be a terminal device capable of wireless connection with eNB102 and/or gNB108. UE122 may also be a terminal device capable of simultaneously establishing a wireless connection with eNB102 and a wireless connection with gNB108. UE122 may have the E-UTRA protocol and/or the NR protocol. The wireless connection may be a Radio Resource Control (RRC) connection.

When UE122 communicates with eNB102 and/or gNB108, a radio connection may be established by establishing a radio bearer (RB) between UE122 and eNB102 and/or gNB108. A radio bearer used for CP may be referred to as a signaling radio bearer (SRB). A radio bearer used for UP may be referred to as a data radio bearer (DRB Data Radio Bearer). Each radio bearer may be assigned a radio bearer identity (ID). A radio bearer identifier for an SRB may be referred to as an SRB identity (SRB ID). A radio bearer identifier for a DRB may be referred to as a DRB identity (DRB ID).

UE122 may also be a terminal device capable of connecting to EPC104 and/or 5GC110 via eNB102 and/or gNB108. If the core network to which eNB102 and/or gNB108, with which UE122 communicates, is connected is EPC104, each DRB established between UE122 and eNB102 and/or gNB108 may further be uniquely linked to each EPS (Evolved Packet System) bearer passing through EPC104. Each EPS bearer may be identified by an EPS bearer identifier (Identity, or ID). Furthermore, the same QoS may be guaranteed for data such as IP packets and Ethernet frames passing through the same EPS bearer.

Furthermore, if the core network to which eNB102 and/or gNB108, with which UE122 communicates, is connected is 5GC110, each DRB established between UE122 and eNB102 and/or gNB108 may be further linked to one of the PDU (Packet Data Unit) sessions established within 5GC110. One or more QoS flows may exist in each PDU session. Each DRB may be mapped to one or more QoS flows, or may not be mapped to any QoS flow. Each PDU session may be identified by a PDU session identifier (Identity, Identifier, or ID). Furthermore, each QoS flow may be identified by a QoS flow identifier (Identity, Identifier, or ID). Furthermore, the same QoS may be guaranteed to data such as IP packets and Ethernet frames passing through the same QoS flow.

PDU sessions and/or QoS flows may not exist in EPC104. Also, EPS bearers may not exist in 5GC110. When UE122 is connected to EPC104, UE122 has information about EPS bearers but may not have information about PDU sessions and/or QoS flows. Also, when UE122 is connected to 5GC110, UE122 has information about PDU sessions and/or QoS flows but may not have information about EPS bearers.

In the following description, eNB102 and/or gNB108 will also be referred to simply as base station devices, and UE122 will also be referred to simply as terminal devices or UEs.

Figure 2 is a diagram of an example of an E-UTRA protocol architecture according to an embodiment of the present invention. Figure 3 is a diagram of an example of an NR protocol architecture according to an embodiment of the present invention. Note that the functions of each protocol described using Figure 2 and/or Figure 3 are only some of the functions closely related to the embodiment of the present invention, and other functions may also be included. Note that in the embodiments of the present invention, the uplink (UL) may be a link from a terminal device to a base station device. Also, in each embodiment of the present invention, the downlink (DL) may be a link from a base station device to a terminal device.

Figure 2(A) is a diagram of the E-UTRA user plane (UP) protocol stack. As shown in Figure 2(A), the E-UTRAN UP protocol may be a protocol between the UE 122 and the eNB 102. That is, the E-UTRAN UP protocol may be a protocol that terminates at the eNB 102 on the network side. As shown in Figure 2(A), the E-UTRA user plane protocol stack may be composed of a PHY (Physical layer) 200, which is the radio physical layer, a MAC (Medium Access Control) 202, which is the medium access control layer, a RLC (Radio Link Control) 204, which is the radio link control layer, and a PDCP (Packet Data Convergence Protocol) 206, which is the packet data convergence protocol layer.

Figure 3(A) is a diagram of the NR user plane (UP) protocol stack. As shown in Figure 3(A), the NRUP protocol may be a protocol between the UE 122 and the gNB 108. That is, the NR UP protocol may be a protocol that terminates at the gNB 108 on the network side. As shown in Figure 3(A), the E-UTRA user plane protocol stack may be composed of a radio physical layer, PHY 300, a medium access control layer, MAC 302, a radio link control layer, RLC 304, a packet data convergence protocol layer, PDCP 306, and a service data adaptation protocol layer, SDAP (Service Data Adaptation Protocol) 310.

Figure 2(B) is a diagram of the E-UTRA control plane (CP) protocol configuration. As shown in Figure 2(B), in the E-UTRAN CP protocol, RRC (Radio Resource Control) 208, which is the radio resource control layer, may be a protocol between UE 122 and eNB 102. In other words, RRC 208 may be a protocol that terminates at eNB 102 on the network side. Also, in the E-UTRAN CP protocol, NAS (Non Access Stratum) 210, which is the non-AS (Access Stratum) layer, may be a protocol between UE 122 and MME. In other words, NAS 210 may be a protocol that terminates at MME on the network side.

Figure 3(B) is a diagram of the NR control plane (CP) protocol configuration. As shown in Figure 3(B), in the NR CP protocol, RRC308, which is a radio resource control layer, may be a protocol between UE122 and gNB108. That is, RRC308 may be a protocol that terminates at gNB108 on the network side. Also, in the E-UTRAN CP protocol, NAS312, which is a non-AS layer, may be a protocol between UE122 and AMF. That is, NAS312 may be a protocol that terminates at AMF on the network side.

The AS (Access Stratum) layer may be a layer that terminates between the UE 122 and the eNB 102 and/or the gNB 108. In other words, the AS layer may be a layer that includes some or all of the PHY 200, MAC 202, RLC 204, PDCP 206, and RRC 208, and/or a layer that includes some or all of the PHY 300, MAC 302, RLC 304, PDCP 306, SDAP 310, and RRC 308.

Note that in the embodiments of the present invention, the terms PHY (PHY layer), MAC (MAC layer), RLC (RLC layer), PDCP (PDCP layer), RRC (RRC layer), and NAS (NAS layer) may be used hereinafter without distinguishing between the E-UTRA protocol and the NR protocol. In this case, PHY (PHY layer), MAC (MAC layer), RLC (RLC layer), PDCP (PDCP layer), RRC (RRC layer), and NAS (NAS layer) may respectively refer to the PHY (PHY layer), MAC (MAC layer), RLC (RLC layer), PDCP (PDCP layer), RRC (RRC layer), and NAS (NAS layer) of the E-UTRA protocol, or the PHY (PHY layer), MAC (MAC layer), RLC (RLC layer), PDCP (PDCP layer), RRC (RRC layer), and NAS (NAS layer) of the NR protocol. The SDAP (SDAP layer) may also be the SDAP (SDAP layer) of the NR protocol.

Furthermore, in the embodiments of the present invention, when distinguishing between E-UTRA protocols and NR protocols, PHY200, MAC202, RLC204, PDCP206, and RRC208 may be referred to as E-UTRA PHY or LTE PHY, E-UTRA MAC or LTE MAC, E-UTRA RLC or LTE RLC, E-UTRA PDCP or LTE PDCP, and E-UTRA RRC or LTE RRC, respectively. PHY200, MAC202, RLC204, PDCP206, and RRC208 may also be referred to as E-UTRA PHY or LTE PHY, E-UTRA MAC or LTE MAC, E-UTRA RLC or LTE RLC, E-UTRA PDCP or LTE PDCP, and E-UTRA RRC or LTE RRC, respectively. Furthermore, when distinguishing between E-UTRA protocols and NR protocols, PHY 300, MAC 302, RLC 304, PDCP 306, and RRC 308 may be referred to as NR PHY, NR MAC, NR RLC, NR RLC, and NR RRC, respectively. Furthermore, PHY 200, MAC 302, RLC 304, PDCP 306, and RRC 308 may be referred to as NR PHY, NR MAC, NR RLC, NR PDCP, and NR RRC, respectively.

This section describes entities in the AS layer of E-UTRA and/or NR. An entity that has some or all of the functions of the MAC layer may be referred to as a MAC entity. An entity that has some or all of the functions of the RLC layer may be referred to as an RLC entity. An entity that has some or all of the functions of the PDCP layer may be referred to as a PDCP entity. An entity that has some or all of the functions of the SDAP layer may be referred to as an SDAP entity. An entity that has some or all of the functions of the RRC layer may be referred to as an RRC entity. The MAC entity, RLC entity, PDCP entity, SDAP entity, and RRC entity may be referred to as MAC, RLC, PDCP, SDAP, and RRC, respectively.

Note that data provided from MAC, RLC, PDCP, and SDAP to lower layers, and/or data provided from lower layers to MAC, RLC, PDCP, and SDAP, may be referred to as MAC PDU (Protocol Data Unit), RLC PDU, PDCP PDU, and SDAP PDU, respectively. Also, data provided from higher layers to MAC, RLC, PDCP, and SDAP, and/or data provided from MAC, RLC, PDCP, and SDAP to higher layers may be referred to as MAC SDU (Service Data Unit), RLC SDU, PDCP SDU, and SDAP SDU, respectively. Also, segmented RLC SDUs may be referred to as RLC SDU segments.

An example of the PHY functions will be described. The PHY of the terminal device may have the function of receiving data transmitted from the PHY of the base station device via the downlink (DL) physical channel. The PHY of the terminal device may have the function of transmitting data to the PHY of the base station device via the uplink (UL) physical channel. The PHY may be connected to the higher MAC via a transport channel. The PHY may pass data to the MAC via the transport channel. The PHY may also be provided with data from the MAC via the transport channel. In the PHY, an RNTI (Radio Network Temporary Identifier) may be used to identify various control information.

Now let's explain the physical channels.

The physical channels used for wireless communication between a terminal device and a base station device may include the following physical channels:

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 may be used to broadcast system information required by terminal devices.

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

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

The 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 the downlink channel. The uplink control information may also include a scheduling request (SR) used to request UL-SCH (Uplink Shared CHannel) resources. The uplink control information may also include a hybrid automatic repeat request ACKnowledgement (HARQ-ACK).

The PDSCH may be used to transmit downlink data (DL-SCH: Downlink Shared CHannel) from the MAC layer. In the case of downlink, it may also be used to transmit system information (SI: System Information) and random access responses (RAR: Random Access Responses).

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

The PRACH may be used to transmit a random access preamble. The PRACH may also be used for initial connection establishment procedures, handover procedures, connection re-establishment procedures, synchronization (timing adjustment) for uplink transmissions, and to indicate requests for PUSCH (UL-SCH) resources.

An example of the functionality of MAC is described below. MAC may be called a MAC sublayer.

The MAC may have the function of mapping various logical channels to corresponding transport channels. Logical channels may be identified by a logical channel identity (or logical channel ID). The MAC may be connected to the higher-level RLC via logical channels. Depending on the type of information being transmitted, logical channels may be divided into control channels that transmit control information and traffic channels that transmit user information. Logical channels may also be divided into uplink logical channels and downlink logical channels. The MAC may have the function of multiplexing MAC SDUs belonging to one or more different logical channels and providing them to the PHY. The MAC may also have the function of demultiplexing MAC PDUs provided by the PHY and providing them to the higher layer via the logical channel to which each MAC SDU belongs.

The MAC may also have the function of performing error correction through HARQ (Hybrid Automatic Repeat reQuest). The MAC may also have a scheduling report (SR) function that reports scheduling information. The MAC may also have the function of performing priority processing between terminal devices using dynamic scheduling. The MAC may also have the function of performing priority processing between logical channels within a single terminal device. The MAC may also have the function of performing priority processing of overlapping resources within a single terminal device.

The E-UTRA MAC may have the ability to identify Multimedia Broadcast Multicast Services (MBMS), and the NR MAC may have the ability to identify Multicast/Broadcast Services (MBS).

The MAC may have the function of selecting a transport format. The MAC may also have the function of performing discontinuous reception (DRX) and/or discontinuous transmission (DTX), the function of executing random access (RA) procedures, the function of reporting power availability (Power Headroom Report (PHR)), the function of reporting buffer status (Buffer Status Report (BSR)), and the like.

NR MAC may have a Bandwidth Adaptation (BA) function. The MAC PDU format used in E-UTRA MAC may differ from the MAC PDU format used in NR MAC. The MAC PDU may also include a MAC control element (MAC CE), which is an element used for control in MAC.

This article describes the uplink (UL) and/or downlink (DL) logical channels used in E-UTRA and/or NR.

BCCH (Broadcast Control Channel) may be a downlink logical channel for broadcasting control information such as system information (SI).

PCCH (Paging Control Channel) may be a downlink logical channel for carrying paging messages.

CCCH (Common Control Channel) may be a logical channel for transmitting control information between a terminal device and a base station device. CCCH may be used when the terminal device does not have an RRC connection. CCCH may also be used between a base station device and multiple terminal devices.

DCCH (Dedicated Control Channel) may be a logical channel for transmitting dedicated control information bidirectionally, point-to-point, between a terminal device and a base station device. Dedicated control information may be control information dedicated to each terminal device. DCCH may be used when the terminal device has an RRC connection.

DTCH (Dedicated Traffic Channel) may be a logical channel for transmitting user data point-to-point between a terminal device and a base station device. DTCH may be a logical channel for transmitting dedicated user data. Dedicated user data may be user data dedicated to each terminal device. DTCH may exist in both the uplink and downlink.

MTCH (Multicast Traffic Channel) may be a point-to-multipoint downlink channel for transmitting data from a base station device to a terminal device. MTCH may be a multicast logical channel. MTCH may be used by a terminal device only when the terminal device receives MBMS.

The MCCH (Multicast Control Channel) may be a point-to-multipoint downlink channel for transmitting MBMS control information for one or more MTCHs from a base station device to a terminal device. The MCCH may be a multicast logical channel. The MCCH may be used by a terminal device only when the terminal device receives MBMS or is interested in receiving MBMS.

SC-MTCH (Single Cell Multicast Traffic Channel) may be a point-to-multipoint downlink channel for transmitting data from a base station device to a terminal device using SC-PTM. SC-MTCH may be a logical channel for multicast. SC-MTCH may be used by a terminal device only when the terminal device receives MBMS using SC-PTM (Single Cell Point-To-Multipoint).

SC-MCCH (Single Cell Multicast Control Channel) may be a point-to-multipoint downlink channel for sending MBMS control information for one or more SC-MTCHs from a base station device to a terminal device. SC-MCCH may be a multicast logical channel. SC-MCCH may be used by a terminal device only when the terminal device receives MBMS using SC-PTM or when the terminal device is interested in receiving MBMS using SC-PTM.

This section describes the mapping of logical channels and transport channels for the uplink in E-UTRA and/or NR.

The CCCH may be mapped to the UL-SCH (Uplink Shared Channel), which is an uplink transport channel.

The DCCH may be mapped to the uplink transport channel, UL-SCH (Uplink Shared Channel).

DTCH may be mapped to the uplink transport channel, UL-SCH (Uplink Shared Channel).

This section describes the mapping of logical channels and transport channels for the downlink in E-UTRA and/or NR.

The BCCH may be mapped to the downlink transport channel BCH (Broadcast Channel) and/or DL-SCH (Downlink Shared Channel).

The PCCH may be mapped to the PCH (Paging Channel), which is a downlink transport channel.

The CCCH may be mapped to the downlink transport channel, DL-SCH (Downlink Shared Channel).

The DCCH may be mapped to the downlink transport channel, DL-SCH (Downlink Shared Channel).

DTCH may be mapped to DL-SCH (Downlink Shared Channel), which is a downlink transport channel.

MTCH may be mapped to MCH (Multicast Channel), which is a downlink transport channel.

The MCCH may be mapped to the MCH (Multicast Channel), which is a downlink transport channel.

The SC-MTCH may be mapped to the DL-SCH (Downlink Shared Channel), which is a downlink transport channel.

The SC-MTCH may be mapped to the DL-SCH (Downlink Shared Channel), which is a downlink transport channel.

An example of the functionality of RLC is described below. RLC may be referred to as the RLC sublayer.

E-UTRA RLC may have the function of segmenting and/or concatenating data provided by the upper layer PDCP and providing it to the lower layer. E-UTRA RLC may have the function of reassembling and reordering data provided by the lower layer and providing it to the upper layer.

NR RLC may have the function of adding a sequence number to data provided by PDCP in the upper layer that is independent of the sequence number added by PDCP. NR RLC may also have the function of segmenting data provided by PDCP and providing it to the lower layer. NR RLC may also have the function of reassembling data provided by the lower layer and providing it to the upper layer. NR RLC may also have the function of retransmitting data and/or requesting retransmission (Automatic Repeat reQuest: ARQ).

RLC may also have the ability to perform error correction using ARQ. The control information sent from the receiving side of RLC to the transmitting side to indicate data that needs to be retransmitted in order to perform ARQ may be called a status report. The instruction to send a status report sent from the transmitting side of RLC to the receiving side may be called a poll. RLC may also have the ability to detect data duplication. RLC may also have the ability to discard data.

RLC may have three modes: transparent mode (TM), unacknowledged mode (UM), and acknowledged mode (AM). In TM, data received from higher layers is not segmented and RLC headers need not be added. The TM RLC entity is a unidirectional entity and may be configured as a transmitting TM RLC entity or a receiving TM RLC entity. In UM, data received from higher layers is segmented and/or combined, RLC headers are added, etc., but data retransmission control is not required. The UM RLC entity may be a unidirectional entity or a bidirectional entity. If the UM RLC entity is a unidirectional entity, it may be configured as a transmitting UM RLC entity or a receiving UM RLC entity. If the UM RLC entity is a bidirectional entity, it may be configured as a UM RLC entity consisting of a transmitting side and a receiving side. In AM, it may perform operations such as segmenting and/or combining data received from a higher layer, adding an RLC header, and controlling data retransmission. The AM RLC entity is a bidirectional entity and may be configured as an AM RLC consisting of a transmitting side and a receiving side. Note that data provided to a lower layer in TM and/or data provided from a lower layer may be referred to as a TMD PDU. Also, data provided to a lower layer in UM and/or data provided from a lower layer may be referred to as a UMD PDU. Also, data provided to a lower layer in AM or data provided from a lower layer may be referred to as an AMD PDU.

The RLC PDU format used in E-UTRA RLC may differ from the RLC PDU format used in NR RLC. RLC PDUs may include data RLC PDUs and control RLC PDUs. Data RLC PDUs may be called RLC DATA PDUs (RLC Data PDUs). Control RLC PDUs may be called RLC CONTROL PDUs (RLC Control PDUs).

An example of the functionality of PDCP is described below. PDCP may be referred to as a PDCP sublayer.

PDCP may have a function for maintaining sequence numbers. PDCP may also have a header compression/decompression function for efficiently transmitting user data such as IP packets and Ethernet frames over wireless interfaces. The protocol used for IP packet header compression/decompression may be called the ROHC (Robust Header Compression) protocol. The protocol used for Ethernet frame header compression/decompression may be called the EHC (Ethernet (registered trademark) Header Compression) protocol. PDCP may also have a data encryption/decryption function. PDCP may also have a data integrity protection/verification function. PDCP may also have a re-ordering function. PDCP may also have a PDCP SDU retransmission function. PDCP may also have a data discard function using a discard timer. PDCP may also have a duplication function. PDCP may also have a function for discarding duplicately received data.

The PDCP entity is a bidirectional entity and may consist of a transmitting PDCP entity and a receiving PDCP entity. The PDCP PDU format used in E-UTRA PDCP may differ from the PDCP PDU format used in NR PDCP. PDCP PDUs may include data PDCP PDUs and control PDCP PDUs. A data PDCP PDU may be called a PDCP DATA PDU (PDCP Data PDU). A control PDCP PDU may be called a PDCP CONTROL PDU (PDCP Control PDU).

Here is an example of the functionality of SDAP. SDAP is the Service Data Adaptation Protocol Layer.

The SDAP may have the function of mapping the downlink QoS flow sent from 5GC110 to the terminal device via the base station device to a data radio bearer (DRB), and/or the function of mapping the uplink QoS flow sent from the terminal device to 5GC110 via the base station device to a DRB. The SDAP may also have the function of storing mapping rule information. The SDAP may also have the function of marking the QoS flow identifier (QoS Flow ID: QFI). Note that SDAP PDUs may include data SDAP PDUs and control SDAP PDUs. The data SDAP PDU may be called the SDAP DATA PDU (SDAP Data PDU). The control SDAP PDU may be called the SDAP CONTROL PDU (SDAP Control PDU). Note that there may be one SDAP entity in the terminal device per PDU session.

An example of RRC functionality is described below.

RRC may have a broadcast function. RRC may have a paging function from EPC104 and/or 5GC110. RRC may have a paging function from eNB102 connected to gNB108 or 5GC100. RRC may also have an RRC connection management function. RRC may also have a radio bearer control function. RRC may also have a cell group control function. RRC may also have a mobility control function. RRC may also have terminal device measurement reporting and terminal device measurement reporting control functions. RRC may also have a QoS management function. RRC may also have a radio link failure detection and recovery function. The RRC may use RRC messages to perform broadcasting, paging, RRC connection management, radio bearer control, cell group control, mobility control, terminal device measurement reporting and terminal device measurement reporting control, QoS management, radio link failure detection and recovery, etc. Note that the RRC messages and parameters used in E-UTRA RRC may differ from the RRC messages and parameters used in NR RRC.

The RRC message may be sent using the BCCH of the logical channel, may be sent using the PCCH of the logical channel, may be sent using the CCCH of the logical channel, may be sent using the DCCH of the logical channel, or may be sent using the MCCH of the logical channel.

RRC messages sent using the BCCH may include, for example, a Master Information Block (MIB), various types of System Information Blocks (SIBs), or other RRC messages. RRC messages sent using the PCCH may include, for example, paging messages or other RRC messages.

RRC messages sent in the uplink (UL) direction using the CCCH may include, for example, an RRC setup request message (RRC Setup Request), an RRC resume request message (RRC Resume Request), an RRC reestablishment request message (RRC Reestablishment Request), an RRC system information request message (RRC System Info Request), etc. They may also include, for example, an RRC connection request message (RRC Connection Request), an RRC connection resume request message (RRC Connection Resume Request), an RRC connection reestablishment request message (RRC Connection Reestablishment Request), etc. They may also include other RRC messages.

RRC messages sent in the downlink (DL) direction using the CCCH may include, for example, an RRC connection reject message (RRC Connection Reject), an RRC connection setup message (RRC Connection Setup), an RRC connection reestablishment message (RRC Connection Reestablishment Reject), an RRC connection reestablishment reject message (RRC Connection Reestablishment Reject), etc. They may also include, for example, an RRC reject message (RRC Reject), an RRC setup message (RRC Setup), etc. They may also include other RRC messages.

RRC messages sent in the uplink (UL) direction using the DCCH may include, for example, a Measurement Report message, an RRC Connection Reconfiguration Complete message, an RRC Connection Setup Complete message, an RRC Connection Reestablishment Complete message, a Security Mode Complete message, and a UE Capability Information message. They may also include, for example, a Measurement Report message, an RRC Reconfiguration Complete message, an RRC Setup Complete message, an RRC Reestablishment Complete message, an RRC Resume Complete message, a Security Mode Complete message, and a UE Capability Information message. Other RRC messages may also be included.

RRC messages sent in the downlink (DL) direction using the DCCH may include, for example, an RRC connection reconfiguration message, an RRC connection release message, a security mode command message, a UE capability inquiry message, etc. They may also include, for example, an RRC reconfiguration message, an RRC resume message, an RRC release message, an RRC reestablishment message, a security mode command message, a UE capability inquiry message, etc. Other RRC messages may also be included.

An example of NAS functions is described below. The NAS may have authentication functions. The NAS may also have mobility management functions. The NAS may also have security control functions.

The above-mentioned PHY, MAC, RLC, PDCP, SDAP, RRC, and NAS functions are examples, and some or all of the functions may not be implemented. Furthermore, some or all of the functions of each layer may be included in another layer.

In addition, layers above the AS layer of the terminal device (not shown) may include the IP layer, and above the IP layer, the TCP (Transmission Control Protocol) layer, the UDP (User Datagram Protocol) layer, etc. Furthermore, an Ethernet layer may be present above the AS layer of the terminal device. This may be called the PDU layer above the AS layer of the terminal device. The PDU layer may include the IP layer, TCP layer, UDP layer, Ethernet layer, etc. An application layer may be present above the IP layer, TCP layer, UDP layer, Ethernet layer, PDU layer, etc. The application layer may include SIP (Session Initiation Protocol) and SDP (Session Description Protocol) used in IMS (IP Multimedia Subsystem), one of the service networks standardized by 3GPP. The application layer may also include RTP (Real-time Transport Protocol) used for media communication, and/or protocols such as RTCP (Real-time Transport Control Protocol) and HTTP (HyperText Transfer Protocol) for media communication control. The application layer may also include codecs for various media. The RRC layer may also be a layer above the SDAP layer.

Next, we will explain the states and state transitions of UE122 in LTE and NR.

When UE122 connected to EPC or 5GC has an RRC connection established, UE122 may be in the RRC_CONNECTED state. The state in which an RRC connection is established may include a state in which UE122 holds some or all of the UE context described below. The state in which an RRC connection is established may also include a state in which UE122 can transmit and/or receive unicast data. UE122 may be in the RRC_INACTIVE state when the RRC connection is suspended. UE122 may be in the RRC_INACTIVE state when UE122 is connected to 5GC and the RRC connection is suspended. When UE122 is neither in the RRC_CONNECTED state nor in the RRC_INACTIVE state, UE122 may be in the RRC_IDLE state.

Note that when UE122 is connected to the EPC, it does not have the RRC_INACTIVE state, but the suspension of the RRC connection may be initiated by E-UTRAN. When UE122 is connected to the EPC, when the RRC connection is suspended, UE122 may transition to the RRC_IDLE state, retaining the UE's AS context and an identifier (resumeIdentity) used for resumption. A layer above the RRC layer of UE122 (e.g., the NAS layer) may initiate the restoration of the suspended RRC connection when UE122 retains the UE's AS context, the E-UTRAN has permitted the restoration of the RRC connection, and UE122 needs to transition from the RRC_IDLE state to the RRC_CONNECTED state.

The definition of RRC connection suspension may differ between UE122 connected to EPC104 and UE122 connected to 5GC110. Furthermore, all or part of the procedure for UE122 to resume from RRC connection suspension may differ between when UE122 is connected to EPC (when suspended in RRC_IDLE state) and when UE122 is connected to 5GC (when suspended in RRC_INACTIVE state).

The RRC_CONNECTED state, RRC_INACTIVE state, and RRC_IDLE state may be referred to as the RRC connected mode, RRC inactive mode, and RRC idle mode, respectively, or, if there is no risk of misunderstanding, may simply be referred to as the connected mode, inactive mode, and idle mode.

The UE AS context held by UE122 may be information including all or part of the following: the current RRC settings, the current security context, the PDCP state including the ROHC (Robust Header Compression) state, the C-RNTI (Cell Radio Network Temporary Identifier) used in the source PCell, the cell identifier (cellIdentity), and the physical cell identifier of the source PCell. Note that the UE AS context held by either or all of eNB102 and gNB108 may include the same information as the UE AS context held by UE122, or may include information different from the information included in the UE AS context held by UE122.

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

This section describes cell groups configured by a base station device for a terminal device. A cell group may consist of only one special cell (SpCell). Alternatively, a cell group may consist of one SpCell and one or more secondary cells (SCells). That is, a cell group may consist of one SpCell and, optionally, one or more SCells. Note that if a MAC entity is associated with a master cell group (MCG), the SpCell may refer to the primary cell (PCell). Also, if a MAC entity is associated with a secondary cell group (SCG), the SpCell may refer to the primary SCG cell (PSCell). Also, if a MAC entity is not associated with a cell group, the SpCell may refer to the PCell. The PCell, PSCell, and SCell are serving cells. The SpCell may support PUCCH transmission and contention-based random access. The SpCell may always be in an activated state. The PCell may be a cell used in the RRC connection establishment procedure when a terminal device in an RRC idle state transitions to an RRC connected state. The PCell may also be a cell used in the RRC connection re-establishment procedure when a terminal device re-establishes an RRC connection. The PCell may also be a cell used in the random access procedure during handover. The PSCell may be a cell used in the random access procedure when a secondary node (SN) is added, as described below. The SpCell may also be a cell used for purposes other than those described above. Note that when a cell group is composed of an SpCell and one or more SCells, it may be said that carrier aggregation (CA) is configured for this cell group. Note that a cell providing additional radio resources to the SpCell for a terminal device in which CA is configured may refer to an SCell.

A group of serving cells configured by RRC that uses the same timing reference cell and the same timing advance value for the cells with uplink configured within it may be called a Timing Advance Group (TAG). Furthermore, a TAG that includes the SpCell of a MAC entity may refer to a Primary Timing Advance Group (PTAG). Furthermore, a TAG other than the above PTAG may refer to a Secondary Timing Advance Group (STAG).

Furthermore, when Dual Connectivity (DC) or Multi-Radio Dual Connectivity (MR-DC) is performed, a cell group may be added from the base station device to the terminal device. DC may be a technology that performs data communication using the radio resources of cell groups configured by a first base station device (first node) and a second base station device (second node). MR-DC may be a technology included in DC. To perform DC, the first base station device may add a second base station device. The first base station device may be called a master node (MN). The cell group configured by the master node may be called a master cell group (MCG). The second base station device may be called a secondary node (SN). The cell group configured by the secondary node may be called a secondary cell group (SCG). The master node and secondary node may be configured within the same base station device.

Furthermore, when a DC is not configured, the cell group configured in the terminal device may be called an MCG.Furthermore, when a DC is not configured, the SpCell configured in the terminal device may be a PCell.

Note that MR-DC may be a technology that performs DC using E-UTRA for the MCG and NR for the SCG. MR-DC may also be a technology that performs DC using NR for the MCG and E-UTRA for the SCG. MR-DC may also be a technology that performs DC using NR for both the MCG and SCG. Examples of MR-DC that use E-UTRA for the MCG and NR for the SCG include EN-DC (E-UTRA-NR Dual Connectivity), which uses EPC in the core network, and NGEN-DC (NG-RAN E-UTRA-NR Dual Connectivity), which uses 5GC in the core network. An example of MR-DC that uses NR for the MCG and E-UTRA for the SCG is NE-DC (NR-E-UTRA Dual Connectivity), which uses 5GC in the core network. An example of MR-DC that uses NR for both the MCG and SCG is NR-DC (NR-NR Dual Connectivity), which uses 5GC in the core network.

In a terminal device, one MAC entity may exist for each cell group. For example, when DC or MR-DC is configured in the terminal device, there may be one MAC entity for the MCG and one MAC entity for the SCG. The MAC entity for the MCG in the terminal device may always be established in the terminal device in all states (RRC idle state, RRC connected state, RRC inactive state, etc.). The MAC entity for the SCG in the terminal device may be created by the terminal device when an SCG is configured in the terminal device. The MAC entity for each cell group in the terminal device may be configured by the terminal device receiving an RRC message from the base station device. In an EN-DC and an NGEN-DC, the MAC entity for the MCG may be an E-UTRA MAC entity, and the MAC entity for the SCG may be an NR MAC entity. In a NE-DC, the MAC entity for the MCG may be an NR MAC entity, and the MAC entity for the SCG may be an E-UTRA MAC entity. In NR-DC, both the MAC entities for the MCG and SCG may be NR MAC entities. The existence of one MAC entity for each cell group may be rephrased as the existence of one MAC entity for each SpCell. The existence of one MAC entity for each cell group may be rephrased as the existence of one MAC entity for each SpCell.

Explains radio bearers. SRB0 to SRB2 may be defined for E-UTRA SRBs, or other SRBs may be defined. SRB0 to SRB3 may be defined for NR SRBs, or other SRBs may be defined.

SRBO may be an SRB for RRC messages transmitted and/or received using the logical channel CCCH.

SRB1 may be an SRB for RRC messages and for NAS messages before the establishment of SRB2. RRC messages transmitted and/or received using SRB1 may include piggybacked NAS messages. The logical channel DCCH may be used for all RRC and NAS messages transmitted and/or received using SRB1.

SRB2 may be an SRB for NAS messages and for RRC messages containing logged measurement information. All RRC and NAS messages sent and/or received using SRB2 may use the logical channel DCCH. SRB2 may also have a lower priority than SRB1.

SRB3 may be an SRB for transmitting and/or receiving specific RRC messages when EN-DC, NGEN-DC, NR-DC, etc. are configured in the terminal device. The logical channel DCCH may be used for all RRC messages and NAS messages transmitted and/or received using SRB3. Other SRBs may also be provided for other uses. DRB may be a radio bearer for user data. The logical channel DTCH may be used for RRC messages transmitted and/or received using DRB.

This section describes radio bearers in a terminal device. Radio bearers may include RLC bearers. RLC bearers may consist of one or two RLC entities and logical channels. If an RLC bearer has two RLC entities, the RLC entities may be TM RLC entities, and/or a transmitting RLC entity and a receiving RLC entity in a unidirectional UM mode RLC entity.

SRB0 may consist of one RLC bearer. The RLC bearer of SRB0 may consist of a TM RLC entity and a logical channel. SRB0 may always be established in a terminal device in all states (such as RRC idle state, RRC connected state, and RRC inactive state). SRB1 may be established and/or configured in a terminal device by an RRC message received from a base station device when the terminal device transitions from an RRC idle state to an RRC connected state. SRB1 may consist of one PDCP entity and one or more RLC bearers. The RLC bearer of SRB1 may consist of an AM RLC entity and a logical channel. SRB2 may be established and/or configured in a terminal device by an RRC message received from a base station device by a terminal device in an RRC connected state with AS security activated. SRB2 may consist of one PDCP entity and one or more RLC bearers. The RLC bearer of SRB2 may consist of an AM RLC entity and a logical channel. The PDCPs of SRB1 and SRB2 on the base station device side may be placed in the master node. When a secondary node in EN-DC, NGEN-DC, or NR-DC is added or the secondary node is changed, one SRB3 may be established and/or configured in the terminal device by an RRC message received from the base station device by a terminal device in an RRC connected state with AS security activated. SRB3 may be a direct SRB between the terminal device and the secondary node. SRB3 may consist of one PDCP entity and one or more RLC bearers. The RLC bearer of SRB3 may consist of an AM RLC entity and a logical channel. The PDCP of SRB3 on the base station device side may be placed in the secondary node.

One or more DRBs may be established and/or configured in a terminal device by an RRC message received from a base station device by a terminal device in an RRC connected state with AS security activated. A DRB may consist of one PDCP entity and one or more RLC bearers. An RLC bearer of a DRB may consist of an AM or UM RLC entity and a logical channel.

In MR-DC, a radio bearer in which a PDCP is placed in the master node may be called an MN terminated bearer. In MR-DC, a radio bearer in which a PDCP is placed in a secondary node may be called an SN terminated bearer. In MR-DC, a radio bearer in which an RLC bearer exists only in an MCG may be called an MCG bearer. In MR-DC, a radio bearer in which an RLC bearer exists only in an SCG may be called an SCG bearer. In DC, a radio bearer in which an RLC bearer exists in both an MCG and an SCG may be called a split bearer.

When MR-DC is configured in a terminal device, the bearer type of SRB1 and SRB2 established/and/or configured in the terminal device may be an MN terminated MCG bearer and/or an MN terminated split bearer. Also, when MR-DC is configured in a terminal device, the bearer type of SRB3 established/and/or configured in the terminal device may be an SN terminated SCG bearer. Also, when MR-DC is configured in a terminal device, the bearer type of the DRB established/and/or configured in the terminal device may be any of all bearer types.

For an RLC bearer established and/or configured in a cell group configured with E-UTRA, the RLC entity established and/or configured may be an E-UTRA RLC. For an RLC bearer established and/or configured in a cell group configured with NR, the RLC entity established and/or configured may be an NR RLC. When an EN-DC is configured in the terminal device, the PDCP entity established and/or configured for an MN-terminated MCG bearer may be either an E-UTRA PDCP or an NR PDCP. When an EN-DC is configured in the terminal device, the PDCP entity established and/or configured for radio bearers of other bearer types, i.e., MN-terminated split bearers, MN-terminated SCG bearers, SN-terminated MCG bearers, SN-terminated split bearers, and SN-terminated SCG bearers, may be an NR PDCP. When an NGEN-DC, NE-DC, or NR-DC is configured in the terminal device, the PDCP entity established and/or configured for radio bearers of all bearer types may be an NR PDCP.

In NR, a DRB established and/or configured in a terminal device may be associated with one PDU session. One SDAP entity may be established and/or configured for one PDU session in the terminal device. The SDAP entity, PDCP entity, RLC entity, and logical channel established and/or configured in the terminal device may be established and/or configured by an RRC message received by the terminal device from the base station device.

Regardless of whether MR-DC is configured, a network configuration in which the master node is eNB102 and EPC104 is the core network may be called E-UTRA/EPC. A network configuration in which the master node is eNB102 and 5GC110 is the core network may be called E-UTRA/5GC. A network configuration in which the master node is gNB108 and 5GC110 is the core network may be called NR or NR/5GC. When MR-DC is not configured, the above-mentioned master node may refer to the base station device that communicates with the terminal device.

Next, handover in LTE and NR will be described. Handover may be a process in which UE 122 in an RRC connected state changes its serving cell. Handover may be performed when UE 122 receives an RRC message instructing handover from eNB 102 and/or gNB 108. The RRC message instructing handover may be a message related to reconfiguration of the RRC connection that includes a parameter instructing handover (e.g., an information element named MobilityControlInfo or an information element named ReconfigurationWithSync). Note that the above-mentioned information element named MobilityControlInfo may be referred to as a mobility control setting information element, mobility control setting, or mobility control information. Note that the above-mentioned information element named ReconfigurationWithSync may be referred to as a reconfiguration with synchronization information element, or reconfiguration with synchronization. The RRC message instructing handover may be a message indicating movement to a cell of another RAT (e.g., MobilityFromEUTRACommand or MobilityFromNRCommand). Alternatively, handover may be referred to as reconfiguration with sync. The conditions under which UE 122 can perform handover may include some or all of the following: AS security is activated, SRB2 is established, and at least one DRB is established.

In addition, the terminal device may perform processing that does not change the serving cell based on an RRC message instructing a handover. In other words, the terminal device may perform handover processing with the same cell as the current serving cell as the target cell.

The following describes the flow of RRC messages transmitted and received between a terminal device and a base station device. Figure 4 is a diagram showing an example of the flow of procedures for various settings in RRC according to an embodiment of the present invention. Figure 4 shows an example of the flow when an RRC message is sent from a base station device (eNB102 and/or gNB108) to a terminal device (UE122).

In FIG. 4, the base station device creates an RRC message (step S400). The base station device may create an RRC message in order to distribute system information (SI) or paging information. The base station device may also create an RRC message in order to have a specific terminal device perform a process. The process to be performed by a specific terminal device may include, for example, security settings, RRC connection reconfiguration, handover to a different RAT, RRC connection suspension, and RRC connection release. The RRC connection reconfiguration process may include, for example, radio bearer control (establishment, modification, release, etc.), cell group control (establishment, addition, modification, release, etc.), measurement settings, handover, and security key update. The base station device may also create an RRC message in order to respond to an RRC message transmitted from the terminal device. The response to the RRC message transmitted from the terminal device may include, for example, a response to an RRC setup request, a response to an RRC reconnection request, or a response to an RRC resumption request. An RRC message includes various information (parameters) for notification and configuration. These parameters may be called fields and/or information elements, and may be described using a description format called ASN.1 (Abstract Syntax Notation One).

In Figure 4, the base station device then transmits the created RRC message to the terminal device (step S402). The terminal device then performs processing such as setting if necessary in accordance with the received RRC message (step S404). After performing the processing, the terminal device may transmit an RRC message in response to the base station device (not shown).

RRC messages may be used for other purposes, not limited to the examples above.

In MR-DC, the RRC on the master node side may be used to transfer RRC messages for SCG side configuration (cell group configuration, radio bearer configuration, measurement configuration, etc.) between the terminal device. For example, in EN-DC or NGEN-DC, NR RRC messages may be included in the form of containers in E-UTRA RRC messages transmitted and received between eNB102 and UE122. In NE-DC, E-UTRA RRC messages may be included in the form of containers in NR RRC messages transmitted and received between gNB108 and UE122. RRC messages for SCG side configuration may be transmitted and received between the master node and secondary node.

In addition, regardless of whether MR-DC is used, the RRC message for E-UTRA transmitted from eNB102 to UE122 may include an RRC message for NR, and the RRC message for NR transmitted from gNB108 to UE122 may include an RRC message for E-UTRA.

An example of parameters included in an RRC message related to RRC connection reconfiguration is described below. Figure 7 is an example of an ASN.1 description representing fields and/or information elements related to radio bearer configuration included in a message related to RRC connection reconfiguration in NR in Figure 4. Figure 8 is an example of an ASN.1 description representing fields and/or information elements related to radio bearer configuration included in a message related to RRC connection reconfiguration in E-UTRA in Figure 4. In the ASN.1 examples in embodiments of the present invention, including but not limited to Figures 7 and 8, the symbols <Omitted> and <Omitted> are not part of the ASN.1 notation and indicate that other information has been omitted. Note that information elements may be omitted even in places where the symbols <Omitted> or <Omitted> are not used. Note that the ASN.1 examples in embodiments of the present invention do not strictly follow the ASN.1 notation. The ASN.1 examples in embodiments of the present invention represent an example of parameters of an RRC message in embodiments of the present invention, and other names and notations may be used. In addition, to avoid complication of explanation, the ASN.1 examples only show examples of main information closely related to one embodiment of the present invention. Note that parameters described in ASN.1 may not be distinguished as fields, information elements, etc., but may all be referred to as information elements. In addition, in the embodiment of the present invention, fields, information elements, etc. described in ASN.1 included in an RRC message may be referred to as information or parameters. Note that the message related to the reconfiguration of the RRC connection may be an RRC reconfiguration message in NR or an RRC connection reconfiguration message in E-UTRA.

This section explains cell activation and deactivation. In a terminal device communicating using dual connectivity, the master cell group (MCG) and secondary cell group (SCG) are configured using the message related to the reconfiguration of the RRC connection mentioned above. Each cell group may consist of a special cell (SpCell) and zero or more other cells (secondary cells: SCell). The SpCell of the MCG is also referred to as a PCell. The SpCell of the SCG is also referred to as a PSCell. Cell deactivation does not apply to SpCells, but may apply to SCells.

Also, cell deactivation may not be applied to PCells but may be applied to PSCells. In this case, cell deactivation may be a different process for SpCells and SCells.

Cell activation and deactivation may be processed by a MAC entity that exists for each cell group. An SCell configured in a terminal device may be activated and/or deactivated by the following (A), (B), and/or (C).
(A) Receipt of MAC CE indicating SCell activation/deactivation
(B) SCell inactivity timer configured for each SCell for which PUCCH is not configured (SCell is deactivated based on the expiration of the timer)
(C) SCell state (sCellState) set for each SCell by an RRC message (the SCell is activated based on the SCell state field being included in the SCell configuration)

Specifically, the MAC entity of the terminal device may perform some or all of the following processes (AD) for each SCell configured in the cell group.

(Processing AD)
(1) If the RRC parameter (SCell state) is set to activated when the SCell is configured, or if a MAC CE for activating the SCell is received, the MAC entity of the UE 122 performs the process (AD-1). Otherwise, if a MAC CE for deactivating the SCell is received, or if the SCell inactivity timer expires for an SCell in the active state, the MAC entity of the UE 122 performs the process (AD-2).
(2) If an uplink grant or downlink allocation is notified by the PDCCH of an active SCell, or if an uplink grant or downlink allocation for an active SCell is notified by the PDCCH of a serving cell, or if a MAC PDU is transmitted in the configured uplink grant, or if a MAC PDU is received in the configured downlink allocation, the MAC entity of UE 122 restarts the SCell inactivity timer associated with that SCell.
(3) If the SCell becomes inactive, the MAC entity of the UE 122 performs the process (AD-3).

(Process AD-1)
The MAC entity of the terminal device may perform some or all of the following (1) to (3).
(1) If, in NR, this SCell was in an inactive state before receiving a MAC CE activating this SCell, or if the RRC parameter (sCellState) configured for the SCell at the time of SCell configuration is set to activated, the MAC entity of UE 122 performs process (AD-1-1).
(2) The MAC entity of the UE 122 starts, or restarts (if already started), the SCell inactivity timer associated with that SCell.
(3) If the Active DL BWP is not a Dormant BWP, the MAC entity of the UE 122 (re)initializes a suspended Type 1 configured uplink grant associated with this SCell according to the stored configuration, if any, and the MAC entity of the UE 122 triggers a PHR.

(Process AD-1-1)
The MAC entity of the terminal device may perform some or all of the following (1) to (3).
(1) If the BWP indicated by the first active downlink BWP identifier (firstActiveDownlinkBWP-Id) set in the RRC message for that SCell is not set to a dormant BWP, the MAC entity of UE 122 performs process (AD-1-1-1).
(2) If the BWP indicated by the first active downlink BWP identifier (firstActiveDownlinkBWP-Id) configured in the RRC message for that SCell is configured as a dormant BWP, the MAC entity of UE 122 stops the BWP inactivity timer (bwp-InactivityTimer) for this serving cell if it is running.
(3) The MAC entity of UE122 activates the downlink BWP indicated by the first active downlink BWP identifier (firstActiveDownlinkBWP-Id) and the uplink BWP indicated by the first active uplink BWP identifier (firstActiveUplinkBWP-Id) configured in the RRC message for that SCell.

(Process AD-1-1-1)
The MAC entity of the terminal device may activate the SCell at a predetermined timing and apply (perform) normal SCell operations including some or all of the following (A) to (E).
(A) Transmission of Sounding Reference Signal (SRS) in this SCell
(B) Reporting of Channel State Information (CSI) for this SCell
(C) Monitoring PDCCH in this SCell
(D) Monitoring of PDCCH for this SCell (when scheduling for this SCell is performed in another serving cell)
(E) If PUCCH is configured, PUCCH transmission on this SCell

(Process AD-2)
The MAC entity of the terminal device may perform some or all of the following (A) to (D):
(A) This SCell is deactivated at a predetermined timing.
(B) Stop the SCell inactivity timer associated with this SCell.
(C) Deactivate all Active BWPs associated with this SCell.
(D) Flushes the HARQ buffer associated with this SCell.

(Process AD-3)
The MAC entity of the terminal device may perform some or all of the following (A) to (D):
(A) Do not transmit SRS on this SCell.
(B) Do not report CSI for this SCell.
(C) Do not transmit PUCCH, UL-SCH, and/or RACH on this SCell.
(D) Do not monitor the PDCCH of this SCell and/or the PDCCH for this SCell.

As described above, the MAC entity performs processing (AD) to activate and deactivate SCells.

Also, as mentioned above, when an SCell is added, the initial state of the SCell may be set by an RRC message.

Here, the SCell deactivation timer will be explained. For an SCell for which PUCCH is not configured, the value of the SCell deactivation timer (information regarding the time at which the timer is considered to have expired) may be notified by an RRC message. For example, if information indicating 40 ms as the value of the SCell deactivation timer is notified by an RRC message, the timer is considered to have expired when the notified time (here, 40 ms) has elapsed in the above process (AD) since the timer was started or restarted without being stopped. The SCell deactivation timer may also be a timer named sCellDeactivationTimer.

Here, we will explain the bandwidth portion (BWP).

A BWP may be part or all of the band of the serving cell. A BWP may also be referred to as a carrier BWP. One or more BWPs may be configured in a terminal device. A BWP may be configured by information included in broadcast information associated with a synchronization signal detected in initial cell search. A BWP may also be a frequency bandwidth associated with the frequency at which initial cell search is performed. A BWP may also be configured by RRC signaling (e.g., dedicated RRC signaling). A downlink BWP (DL BWP) and an uplink BWP (UL BWP) may also be configured separately. One or more uplink BWPs may also be associated with one or more downlink BWPs. Furthermore, the correspondence between the uplink BWP and the downlink BWP may be a predetermined correspondence, or may be correspondence based on RRC signaling (e.g., Dedicated RRC signaling), or may be correspondence based on physical layer signaling (e.g., Downlink Control Information (DCI) notified on a Downlink Control Channel), or may be a combination thereof.

A BWP may consist of a group of consecutive physical resource blocks (PRBs). Furthermore, parameters for the BWP of each component carrier (one or more BWPs) may be configured for a connected terminal device. The BWP parameters for each component carrier may include some or all of the following: (A) type of cyclic prefix, (B) subcarrier spacing, (C) frequency location of the BWP (e.g., start location or center frequency location on the lower frequency side of the BWP) (for example, ARFCN may be used for the frequency location, or an offset from a specific subcarrier of the serving cell may be used. The offset may be in units of subcarriers or resource blocks. Both the ARFCN and the offset may be configured.), (D) bandwidth of the BWP (e.g., the number of PRBs), (E) resource configuration information for the control signal, and (F) center frequency location of the SS block (for example, ARFCN may be used for the frequency location, or an offset from a specific subcarrier of the serving cell may be used. The offset may be in units of subcarriers or resource blocks. Both the ARFCN and the offset may be configured.). Furthermore, the resource configuration information for the control signal may be included in the configuration of the BWP for at least some or all of the PCell and/or PSCell.

A terminal device may transmit and receive in an active BWP among one or more configured BWPs. Of one or more BWPs configured for a serving cell associated with the terminal device, up to one uplink BWP and/or up to one downlink BWP may be configured to be active BWPs at any given time. An activated downlink BWP is also referred to as an Active DL BWP. An activated uplink BWP is also referred to as an Active UL BWP.

Next, we will explain BWP deactivation. One or more BWPs may be configured in one serving cell. BWP switching in the serving cell is used to activate a deactivated BWP (also called an inactive BWP) and deactivate an activated BWP.

BWP switching is controlled by the PDCCH indicating a downlink assignment or uplink grant, the BWP inactivity timer, RRC signaling, or the MAC entity itself due to the initiation of a random access procedure. Active BWP in the serving cell is indicated by RRC or PDCCH.

Next, we will explain dormant BWP. Entering or leaving a dormant BWP is performed by BWP switching. This control is performed by the PDCCH for each SCell or for each group called a dormant SCell group. The configuration of a dormant SCell group is indicated by RRC signaling. In the current specifications, dormant BWP only applies to SCells. Note that dormant BWP does not change a BWP to a dormant state, but can be interpreted as one BWP that is configured for dormancy among one or more BWPs configured for a UE. There may also be multiple BWPs configured for dormancy for a UE.

The fact that a BWP is a dormant BWP may be indicated by the absence of certain parameters in the BWP configuration. For example, the absence of a PDCCH-Config information element, which is an information element for configuring UE-specific PDCCH parameters, included in the downlink BWP configuration, may indicate that the BWP is a dormant BWP. Furthermore, the fact that some of the parameters included in the PDCCH-Config information element, which is an information element for configuring UE-specific PDCCH parameters, included in the downlink BWP configuration, are not configured (not included) may indicate that the BWP is a dormant BWP. For example, the fact that some or all of the search space-related settings, which are configured by the PDCCH-Config information element and define where and/or how PDCCH candidates are searched (searched), are not configured (not included) may indicate that the BWP is a dormant BWP.

In addition, in some configurations, the setting of dormant BWP for SpCells such as PCells and PSCells and PUCCH SCells on which PUCCH can be transmitted may not be supported.

When a UE receives a PDCCH in the SpCell indicating that it will exit a dormant BWP outside a certain set period (active time), it activates the downlink BWP indicated by the first downlink BWP identifier previously notified by RRC signaling.

When a UE receives a PDCCH in the SpCell indicating that it will exit a dormant BWP within a certain set period (active time), it activates the downlink BWP indicated by the second downlink BWP identifier previously notified by RRC signaling.

When a UE receives a PDCCH indicating entry into a dormant BWP, it activates the downlink BWP indicated by the third downlink BWP identifier (dormantDownlinkBWP-Id) that was previously notified by RRC signaling.

The above-mentioned entry and exit into and exit from dormant BWPs are performed by BWP switching, and when a new BWP is activated, the previously active BWP is deactivated. In other words, when exiting a dormant BWP, the dormant BWP is deactivated, and when entering a dormant BWP, the dormant BWP is activated.

Here, we will explain the PDCCH indicating entry into a dormant BWP and the PDCCH indicating exit from a dormant BWP.

For example, a UE configured with discontinuous reception (DRX) in an SpCell may monitor the PDCCH in the SpCell's Active BWP to detect a certain DCI format (e.g., DCI format 2_6) outside of the DRX active time. The CRC of the DCI format may be scrambled with a certain RNTI (e.g., PS-RNTI). A UE configured with a dormant SCell group determines the switching of the Active DL BWP based on the bitmap information included in the payload of DCI format 2_6. For example, if a certain bit in the bitmap is associated with a dormant SCell group and the bit is 1, the UE may perform BWP switching to another pre-configured BWP if the Active DL BWP is a dormant BWP, or may remain at that BWP if the Active DL BWP is not a dormant BWP. Alternatively, if the bit is 0, the UE may perform BWP switching so that the Active DL BWP becomes a dormant BWP.

The UE does not need to monitor the PDCCH for the purpose of detecting DCI format 2_6 during DRX active time.

A UE configured for discontinuous reception (DRX) in the SpCell may monitor the PDCCH in the SpCell's Active BWP to detect a certain DCI format (e.g., DCI formats 0_1 and 1_1) during DRX active time. The CRC of the DCI format may be scrambled with a certain RNTI (e.g., C-RNTI or MCS-C-RNTI). A UE configured for a dormant SCell group determines the switching of the Active DL BWP based on the bitmap information included in the payload of DCI format 0_1 or DCI format 1_1. For example, if a certain bit in the bitmap is associated with a dormant SCell group and the bit is 1, the UE may perform BWP switching to another pre-configured BWP if the Active DL BWP is a dormant BWP; if the Active DL BWP is not a dormant BWP, the UE may remain at that BWP. Alternatively, if the bit is 0, the UE may perform BWP switching so that the Active DL BWP becomes a dormant BWP. Furthermore, the "different pre-set BWP" may be a BWP different from the "different pre-set BWP" used in the description of DCI format 2_6.

The UE does not need to monitor the PDCCH for the purpose of detecting DCI format 0_1 and DCI format 1_1 outside of the DRX active time.

Monitoring the PDCCH indicating exiting dormant BWP may mean monitoring the PDCCH for the purpose of detecting DCI format 2_6 outside of DRX active time, and monitoring the PDCCH for the purpose of detecting DCI format 0_1 and DCI format 1_1 during DRX active time.

In each activated serving cell in which a BWP is configured, the MAC entity may perform some or all of the following (A) to (H) if the BWP is activated (active BWP) and is not a dormant BWP:
(A) Transmit UL-SCH with that BWP.
(B) If a PRACH occasion is configured, transmit the RACH in that BWP.
(C) Monitor the PDCCH with that BWP.
(D) If PUCCH is configured, transmit PUCCH in that BWP.
(E) Report the CSI in that BWP.
(F) If SRS is configured, send SRS in that BWP.
(G) Receive DL-SCH with that BWP.
(H) Initialize any configured uplink grants of grant type 1 that were set up and suspended in that BWP.

In each activated serving cell in which a BWP is configured, the MAC entity may perform some or all of the following (A) to (G) if the BWP is activated (active BWP) and if the BWP is dormant BWP.
(A) If the BWP inactivity timer of the serving cell for this BWP is running, stop it.
(B) Do not monitor the PDCCH of that BWP.
(C) Do not monitor the PDCCH for that BWP.
(D) DL-SCH is not received in that BWP.
(F) Do not send SRS with that BWP.
(G) Do not transmit UL-SCH in that BWP.
(H) Do not transmit RACH in that BWP.
(I) Do not transmit PUCCH in that BWP.
(J) Clear the configured downlink assignment and the configured uplink grant of grant type 2 associated with that SCell.
(K) Suspend the configured uplink grant of grant type 1 associated with that SCell.
(L) If beam failure settings are configured, detect beam failure and perform beam failure recovery if beam failure is detected.

A MAC entity may, if a BWP is deactivated, do some or all of the following:
(A) Do not transmit UL-SCH in that BWP.
(B) Do not transmit a RACH in that BWP.
(C) Do not monitor the PDCCH in that BWP.
(D) Do not transmit PUCCH in that BWP.
(E) Not reporting a CSI in that BWP.
(F) Do not send SRS with that BWP.
(G) DL-SCH is not received on that BWP.
(H) Clear the configured uplink grant of grant type 2 set in that BWP.
(I) Suspend the configured uplink grant of grant type 1 of the deactivated BWP (inactive BWP).

Next, we will explain the random access procedure for a UE configured with BWP. When initiating the random access procedure in a serving cell, the MAC entity may perform some or all of the following steps (A) to (E) on the selected carrier of the serving cell.
(A) If the resource (occasion) for transmitting the PRACH is not configured for the Active UL BWP, (A1) switch the Active UL BWP to the BWP indicated by the RRC parameter (initialUplinkBWP), and (A2) if the serving cell is an SpCell, switch the Active UL BWP to the BWP indicated by the RRC parameter initialDownlinkBWP.
(B) If the resource (occasion) for transmitting the PRACH is configured for the Active UL BWP, if the serving cell is an SpCell and the Active DL BWP and the Active UL BWP do not have the same identifier (bwp-Id), the Active DL BWP is switched to a BWP with the same identifier as the Active UL BWP's identifier.
(C) If the BWP inactivity timer associated with the Active Downlink BWP of this serving cell is running, stop this timer.
(D) If the serving cell is an SCell, stop the BWP inactivity timer associated with the SpCell's Active DL BWP if this timer is running.
(E) Perform the random access procedure on the Active DL BWP of the SpCell and the Active UL BWP of this serving cell.

Next, the BWP inactivity timer will be described. For each activated serving cell for which the BWP inactivity timer is set, the MAC entity performs the following process (A). The BWP inactivity timer may also be a timer named bwp-InactivityTimer.
(A) If the default downlink BWP identifier (defaultDownlinkBWP-Id) is configured and the Active DL BWP is not the BWP indicated by the identifier (dormantDownlinkBWP-Id), or if the default downlink BWP identifier (defaultDownlinkBWP-Id) is not configured and the Active DL BWP is not the initialDownlinkBWP and the Active DL BWP is not the BWP indicated by the identifier (dormantDownlinkBWP-Id), the MAC entity performs the following processes (A-1) and (A-2).
(A-1) If a PDCCH addressed to the C-RNTI or CS-RNTI indicating a downlink assignment or uplink grant is received in an Active DL BWP, or if a PDCCH addressed to the C-RNTI or CS-RNTI indicating a downlink assignment or uplink grant for an Active DL BWP is received, or if a MAC PDU is sent with a configured uplink grant or a MAC PDU is received with a configured downlink assignment, the MAC entity performs the following process (A-1-1).
(A-1-1) If a random access procedure associated with this serving cell is not in progress or an ongoing random access procedure associated with this serving cell is successfully completed by receiving a PDCCH addressed to the C-RNTI, start or restart the BWP inactivity timer associated with the Active DL BWP.
(A-2) If the BWP inactivity timer associated with the Active DL BWP expires, the MAC entity performs the following process (A-2-1).
(A-2-1) If defaultDownlinkBWP-Id is set, BWP switching is performed to the BWP indicated by this defaultDownlinkBWP-Id, and if not, BWP switching is performed to the initialDownlinkBWP.

Furthermore, if the MAC entity receives a PDCCH for BWP switching and switches the Active DL BWP, it may perform the following process (A).
(A) If the default downlink BWP identifier (defaultDownlinkBWP-Id) is set and the switched-to Active DL BWP is not the BWP indicated by the identifier (dormantDownlinkBWP-Id), and if the switched-to Active DL BWP is not the BWP indicated by dormantDownlinkBWP-Id, start or restart the BWP inactivity timer associated with the Active DL BWP.

Next, we will explain the procedures for beam failure detection and recovery.

In the MAC entity, a beam failure recovery procedure may be configured by RRC for each serving cell. Beam failure is detected by counting beam failure instance notifications notified to the MAC entity from the lower layer (PHY layer). The MAC entity may perform some or all of the following processes (A), (B), and (C) for each serving cell to detect beam failure.
(A) If a beam failure instance notification is received from the lower layer, start or restart the timer (beamFailureDetectionTimer) and increment the counter (BFI-COUNTER) by 1. If the value of BFI_COUNTER is equal to or greater than the configured threshold (beamFailureInstanceMaxCount), perform the process in (A-1) below.
(A-1) If the serving cell is an SCell, trigger beam failure recovery (BFR) for this serving cell; otherwise, start a random access procedure in the SpCell.
(B) If the beamFailureDetectionTimer for this serving cell expires, or if the beamFailureDetectionTimer, beamFailureInstanceMaxCount, and/or reference signal settings for beam failure detection are changed by higher layers, set BFI_COUNTER to 0.
(C) If the serving cell is an SpCell and the random access procedure is completed successfully, set BFI_COUNTER to 0, stop the timer (beamFailureRecoveryTimer), and consider the beam failure recovery procedure to be completed successfully. Otherwise, if the serving cell receives a PDCCH addressed to the C-RNTI on the SCell that indicates a new uplink grant for transmitting information for beam failure recovery of the SCell (e.g., information contained in the SCell BFR MAC CE), or if the SCell is in an inactive state, set BFI_COUNTER to 0, consider the beam failure recovery procedure to be completed successfully, and cancel all beam failure recoveries (BFRs) triggered for this serving cell.

The MAC entity shall perform the following process (A) if at least one Beam Failure Recovery (BFR) has been triggered by the Beam Failure Recovery procedure and has not been canceled.
(A) If the UL-SCH resource can contain the BFR MAC CE of the SCell and its subheader taking into account the priority of the logical channel, include the BFR MAC CE of the SCell and its subheader. Otherwise, if the UL-SCH resource can contain the truncated BFR MAC CE of the SCell and its subheader taking into account the priority of the logical channel, include the truncated BFR MAC CE of the SCell and its subheader. Otherwise, trigger a scheduling request for SCell beam failure recovery.

The dormancy of an SCell is achieved by activating the dormant BWP for that SCell. Even when an SCell is in the dormant state, CSI measurement, automatic gain control (AGC), and beam management including beam failure recovery may be performed for that SCell.

Next, we will explain how to add an SCG PSCell and zero or more SCells to a terminal device.

The addition of a PSCell and zero or more SCells to the SCG may be performed by an RRC message related to the reconfiguration of the RRC connection. Figures 9 to 13 are example ASN.1 descriptions representing fields and/or information elements related to the addition of a PSCell and zero or more SCells to the SCG included in a message related to the reconfiguration of the RRC connection in NR.

In order to avoid complicating the explanation, the messages and/or information elements in each diagram may differ from the actual message structure and/or information element structure, with some structured fields and information elements expanded and/or fields and information elements not directly related to the explanation omitted.

As shown in Fig. 9, an RRC reconfiguration message (RRCReconfiguration message) may be used to add a PSCell and zero or more SCells of an SCG. The RRC reconfiguration message may include some or all of the following information (A) to (E). The RRC reconfiguration message may also include other information.
(A) RRC transaction identifier (rrc-TransactionIdentifier)
(B) Configuration for adding, modifying, and releasing radio bearers (radioBearerConfig)
(C) Secondary cell group settings (secondaryCellGroup)
(D) Master cell group settings (masterCellGroup)
(E) RRC configuration of secondary cell group in MR-DC (mrdc-SecondaryCellGroupConfig)

When an RRC reconfiguration message is notified to a terminal device using SRB3, the SCG configuration may be notified by the setting (C) above in the RRC Reconfiguration message. Also, when an RRC reconfiguration message is notified to a terminal device using SRB1, the SCG configuration may be notified by an RRC reconfiguration message generated by the secondary node, which is included in the RRC Reconfiguration message generated by the master node using (E) above. In this case, the SCG configuration may be notified by the setting (C) above included in the RRC reconfiguration message generated by the secondary node. Also, a separate message may be used for SCG configuration.

The configuration of the secondary cell group may be provided by a cell group configuration information element (CellGroupConfigIE). As shown in Figure 10, the cell group configuration information element may include some or all of the following information (A) to (H). The cell group configuration information element may also include other information.
(A) Cell group identifier (cellGroupId)
(B) Configuration for adding and/or modifying RLC bearers (rlc-BearerToAddModList)
(C) Configuration for RLC bearer release (rlc-BearerToReleaseList)
(D) MAC configuration for this cell group (mac-CellGroupConfig)
(E) PHY configuration for this cell group (physicalCellGroupConfig)
(F) SpCell configuration (spCellConfig)
(G) Settings for adding and modifying SCells (sCellToAddModList)
(H) Settings for releasing SCells (sCellToReleaseList)

SpCells may be added and/or configured by the SpCell configuration in (F) above, and SCells may be added, modified, and/or released by the configurations in (G) and (H) above. These may also be done by other messages.

The above SpCell settings may include some or all of the following information (A) to (D), as shown in Fig. 11. The SpCell settings may also include other information.
(A) Index for identifying serving cells (servCellIndex)
(B) Reconfiguration with Sync
(C) Information on timer values and constants used to determine radio link failures (rlf-TimersAndConstants)
(D) SpCell device-specific parameter configuration (spCellConfigDedicated)

The above-mentioned information elements for synchronized reconfiguration may include some or all of the following information (A) to (D), as shown in Fig. 12. The synchronized reconfiguration information may also include other information.
(A) SpCell cell-specific parameter settings (spCellConfigCommon)
(B) New UE identifier (UE-Identity) value (newUE-Identity)
(C) Value of timer T304 (t304)
(D) RACH terminal device specific parameter setting (rach-ConfigDedicated)

The above-mentioned RACH terminal device-specific parameter settings may include parameters (CFRA) used for continuation-free random access. If this CFRA is not included in the settings, the terminal device may perform contiguous random access in the random access procedure. The CFRA may include information on the RA occasion used for contiguous random access.

The above-mentioned configuration of the cell-specific parameters of the SpCell may be provided by an information element (ServingCellConfigCommon IE) used to configure the cell-specific parameters of the serving cell. The information element used to configure the cell-specific parameters of the serving cell may include some or all of the following information (A) to (D), as shown in Fig. 13. Furthermore, the information element used to configure the cell-specific parameters of the serving cell may also include other information.
(A) Physical cell identifier (physCellId)
(B) Downlink common parameters in the cell (downlinkConfigCommon)
(C) Uplink common parameters in the cell (uplinkConfigCommon)
(D) Configuration of terminal device-specific parameters (including some cell-specific parameters) of SCell (sCellConfigDedicated)
(E) SSB subcarrier spacing information (ssbSubcarrierSpacing)

Downlink common parameters for a cell may include downlink frequency information (frequencyInfoDL) and/or initial downlink BWP information (initialDownlinkBWP). The downlink frequency information may include information on the SSB frequency used in this serving cell.

The above-mentioned configuration for adding or modifying an SCell may be provided by one or more SCell configuration information elements (SCellConfigIE). The SCell configuration information element may include some or all of the following information (A) to (D), as shown in Fig. 14. The SCell configuration information element may also include other information.
(A) Identifier for identifying SCell (sCellIndex)
(B) Configuring cell-specific parameters for SCell (sCellConfigCommon)
(C) Configuration of terminal device-specific parameters (including some cell-specific parameters) of SCell (sCellConfigDedicated)
(D) Information instructing activation/inactivation of SCell (sCellState-r16)

As an example, we will explain the procedure for adding a PSCell and zero or more SCells to an SCG using the above RRC messages and information elements. Note that the RRC messages and information elements used in the explanation are examples, and the names and structures when implemented are not limited to these.

The RRC entity of the terminal device that has received the RRCReconfiguration message may perform some or all of the following (A) to (F). The terminal device that has received the RRCReconfiguration message may also perform other processing.
(A) If the RRCReconfiguration contains a masterCellGroup, then process (BD-1) for the master cell group based on this masterCellGroup.
(B) If the RRCReconfiguration includes a secondaryCellGroup, process (BD-1) is performed on the secondary cell group based on this secondaryCellGroup.
(C) If the RRCReconfiguration contains a radioBearerConfig, configure the radio bearer based on this radioBearerConfig.
(D) Set the content to be included in the RRC reconfiguration complete message.
(E) If the SpCell configuration (spCellConfig) of the received secondary cell group configuration includes reconfigurationWithSync, start the random access procedure in that SpCell.
(F) If the SpCell configuration (spCellConfig) of the MCG or SCG includes reconfigurationWithSync and the above random access procedure is successfully completed in the NR cell group, stop timer T304 for that cell group.

(Process BD-1)
The RRC entity of the terminal device may perform some or all of the following (A) to (G).
(A) If CellGroupConfig includes spCellConfig including reconfigurationWithSync, the RRC entity of the terminal device performs some or all of the following (1) to (3).
(1) Execute process (BD-2).
(2) Resume all suspended radio bearers.
(3) Resume SCG transmission for all radio bearers if suspended.
(B) If the CellGroupConfig contains an rlc-BearerToReleaseList, release of the RLC bearer is performed based on this rlc-BearerToReleaseList.
(C) If CellGroupConfig contains rlc-BearerToAddModList, add and/or modify RLC bearers based on this rlc-BearerToAddModList.
(D) If the CellGroupConfig contains a mac-CellGroupConfig, configure the MAC entity of this cell group based on this mac-CellGroupConfig.
(E) If sCellToReleaseList is included in CellGroupConfig, release of SCell is performed based on this sCellToReleaseList.
(F) If the CellGroupConfig contains an spCellConfig, configure the SpCell based on this spCellConfig.
(G) If the CellGroupConfig contains sCellToAddModList, add and/or modify SCells based on this sCellToAddModList.

(Process BD-2)
The RRC entity of the terminal device may perform some or all of the following (A) to ().
(A) If AS security is not activated, execute the process to transition to RRC_IDLE and end the procedure.
(B) Start timer T304 for the SpCell (to be configured) using the value of t304 included in reconfigurationWithSync.
(C) If downlink frequency information (frequencyInfoDL) is included in reconfigurationWithSync, the cell indicated by the physical cell identifier (physCellId) included in reconfigurationWithSync at the SSB frequency indicated in frequencyInfoDL is determined to be the target SpCell.
(D) If the downlink frequency information (frequencyInfoDL) is not included in reconfigurationWithSync, the cell indicated by the physical cell identifier (physCellId) included in reconfigurationWithSync at the SSB frequency of the original SpCell (Source SpCell) is determined to be the target SpCell.
(E) Initiate downlink synchronization of the target SpCell.
(F) Acquire the MIB of the target SpCell.
(G) If a specific bearer (DAPS bearer) is not established, perform some or all of the following steps (1) to (4).
(1) Reset the MAC entity of this cell group.
(2) If an SCell not included in SCellToAddModList is configured in this cell group, this SCell is put into an inactive state.
(3) The value of newUE-Identity is applied as the C-RNTI of this cell group.
(4) Configure the lower layer based on the received spCellConfigCommon.

Next, timer T304 will be explained. Timer T304 may exist for each cell group. Furthermore, the value (time information at which the timer expires) of a certain timer (here, timer T304) may be notified by an RRC message. For example, if an RRC message notifies information indicating a timer value of 1000 ms, the timer may be considered to have expired if the notified time (1000 ms in this example) has passed since the timer was started or restarted without the timer being stopped.

Based on receiving an RRC reconfiguration message including reconfigurationWithSync, the terminal device may start timer T304 for the cell group to which the reconfigurationWithSync setting applies.

The terminal device may stop timer T304 for the cell group to which the reconfigurationWithSync setting applies based on the successful completion of random access to the target SpCell indicated by reconfigurationWithSync.

The terminal device may stop timer T304 for the SCG based on the release of the SCG.

The terminal device may perform the RRC connection re-establishment procedure if the MCG timer T304 expires and if a specific bearer (DAPS bearer) is not configured.

When SCG timer T304 expires, the terminal device may notify the network of the failure of the synchronized reconfiguration by initiating an SCG failure information procedure.

Further explanation will be given of the behavior of the terminal device when SCG timer T304 expires.

If timer T304 of the secondary cell group expires, the RRC entity of the terminal device performs the following process (A) if MCG transmission is not suspended, and performs the following process (B) if MCG transmission is suspended.
(A) If the terminal device specific preamble provided in rach-ConfigDedicated is set, release it and start the SCG failure information procedure to report the failure of the SCG synchronized reconfiguration.
(B) Initiate the RRC connection re-establishment procedure.

Next, we will explain the SCG failure information procedure. This procedure may also be referred to as the SCG failure information procedure.

This procedure may be used to notify the E-UTRAN or NR master node of an SCG failure experienced by the terminal device.

The RRC entity of the terminal device may initiate this procedure to report an SCG failure when MCG or SCG transmission is not suspended and any of the following conditions (A) to (D) is met:
(A) A radio link failure of the SCG is detected. (B) A synchronization setting failure of the SCG is detected. (C) A setting failure of the SCG is detected. (D) An integrity check failure for the SRB3 is notified from the lower layer of the SCG.

The RRC entity of the terminal device initiating this procedure performs some or all of the following steps (A) to (E).
(A) Suspend SCG transmission for all SRBs and DRBs.
(B) Reset the SCG MAC.
(C) If timer T304 in this SCG is running, stop it.
(D) If conditional reconfiguration for PSCell change is set, stop this evaluation.
(E) Set the content to be included in the SCG Failure Information (SCGFailureInformation) message and submit this message to the lower layer for transmission.

The lower layer of the RRC of the terminal device may send the above-mentioned SCG failure information (SCGFailureInformation) message to the base station device.

Next, we will explain the activation and deactivation of SCG.

In LTE and/or NR, a state in which the SCG is deactivated (SCG inactive state) may be included as part of the RRC_CONNECTED state.

In LTE and/or NR, a state in which an SCG is deactivated (SCG deactivated state) may be a state in which a terminal device performs some or all of the following (A) to (J) in the SpCell (PSCell) of that SCG and/or in all cells of that SCG.
(A) Do not transmit SRS in that cell.
(B) Do not report CSI for that cell.
(C) Do not transmit PUCCH, UL-SCH, and/or RACH in that cell.
(D) Do not monitor the PDCCH of that cell and/or the PDCCH for that cell.
(E) Not monitoring the PDCCH of that cell and/or the PDCCH for that cell addressed to the C-RNTI, MCS-C-RNTI, and/or CS-RNTI indicating an uplink grant for UL-SCH transmission in that cell.
(F) Do not perform automatic gain control (AGC) on that cell.
(G) No beam management, including beam failure recovery, is performed in that cell.
(H) Radio Link Monitoring (RLM) is not performed in that cell.
(I) In that cell, the BWP that has been set as a dormant BWP is called the active BWP.
(J) The C-RNTI is not monitored on the PDCCH in the activated dormant BWP of the cell.

Furthermore, entering the SCG inactive state may also be referred to as entering the deactivated SCG. The SCG inactive state may also be a state in which the Active BWPs of all cells in the SCG are dormant BWPs. The above-mentioned SCG inactive state may also be a state to which a transition occurs from the SCG activated state (SCG active state), described below, when an RRC entity instructs entry into the deactivated SCG.

In LTE and/or NR, the SCG activated state (SCG active state) may be included as part of the RRC_CONNECTED state.

In LTE and/or NR, an activated state of an SCG (SCG activated state) may be a state in which a terminal device performs some or all of the following (A) to (J) in the SpCell (PSCell) of that SCG and/or in any cell of that SCG.
(A) Transmit SRS in that cell.
(B) Report the CSI for that cell.
(C) Transmit PUCCH, UL-SCH, and/or RACH in that cell.
(D) Monitor the PDCCH of that cell and/or the PDCCH for that cell.
(E) Monitor the PDCCH of that cell and/or the PDCCH for that cell addressed to the C-RNTI, MCS-C-RNTI, and/or CS-RNTI indicating an uplink grant for UL-SCH transmission in that cell.
(F) Automatic gain control (AGC) is performed on that cell.
(G) The cell performs beam management including beam failure recovery.
(H) Radio Link Monitoring (RLM) is performed in that cell.
(I) In that cell, a BWP that has been set as a dormant BWP is not set as an activated BWP (Active BWP).
(J) Monitor the C-RNTI on the PDCCH in the activated BWP of that cell.

Furthermore, entering the SCG active state may also be referred to as entering the activated SCG. The SCG active state may also be a state in which the Active BWPs of the SCG's SpCell and/or one or more SCells are not Dormant BWPs. The above-mentioned SCG inactive state may also be a state to which the SCG transitions from an inactive state (SCG inactive state) when an RRC entity instructs the SCG to leave the inactivated SCG.

In LTE and/or NR, a terminal device may transition an SCG to an inactive state (in other words, may deactivate an SCG) based on receiving some or all of the following (A) to (B). Note that the messages and control elements in (A) to (B) below may be notified to the terminal device from a cell group other than the SCG. Furthermore, each piece of information may be notified to the terminal device by an RRC message, a MAC information element, or a physical control channel.
(A) Information instructing inactivation of SCG
(B) Information instructing SpCell inactivation

The terminal device may also transition the SCG from an active state to an inactive state based on a timer related to the deactivation of the SCG. The terminal device may also transition the SCG from an active state to an inactive state based on a timer related to the deactivation of the PSCell.

The terminal device may also transition the SCG from an inactive state to an active state when initiating a random access procedure due to a scheduling request (in other words, initiated by the MAC entity itself).The MAC entity of the terminal device may also obtain instructions to activate the SCG, instructions to resume from an inactive SCG, instructions to resume from a dormant state of the SpCell, and/or other information from the RRC entity of the terminal device.

In LTE and/or NR, a terminal device may transition an SCG from an inactive state to an active state (in other words, may activate an SCG) based on receiving some or all of the following (A) to (D). Note that the messages and control elements (A) to (D) below may be notified to the terminal device from a cell group other than the SCG. Furthermore, each piece of information may be notified to the terminal device via an RRC message, a MAC information element, or a physical control channel.
(A) Information that directs SCG activation
(B) Information that directs the return of SCG from its inactive state (Resume)
(C) Information that directs SpCell activation
(D) Information that directs the return of SpCell from its inactivated state

The terminal device may also transition the SCG from an inactive state to an active state based on a timer related to the deactivation of the SCG. The terminal device may also transition the SCG from an inactive state to an active state based on a timer related to the deactivation of the PSCell.

The terminal device may also transition the SCG from an inactive state to an active state when initiating a random access procedure resulting from a scheduling request triggered to transmit a MAC PDU including a MAC SDU. The terminal device may also transition the SCG from an inactive state to an active state when initiating a random access procedure.

The terminal device may also transition the SCG from an inactive state to an active state when initiating a random access procedure due to a scheduling request (in other words, initiated by the MAC entity itself).The MAC entity of the terminal device may also obtain instructions to activate the SCG, instructions to resume from an inactive SCG, instructions to resume from a dormant state of the SpCell, and/or other information from the RRC entity of the terminal device.

Inactivation of SCG may also be referred to as entering a dormant SCG. Inactivation of SCG may also refer to the activation of the dormant BWP of the SpCells in the cell group. Inactivation of SCG may also be referred to as SCG dormancy or SCG suspension.

When an SCG is in a deactivated state, all uplink transmissions in the SCG may be stopped. In this case, information about the SCG may be transmitted in another cell group (e.g., MCG). Alternatively, information about the SCG may be transmitted in the SCG that has left the deactivated state (activated SCG).

A random access procedure in an SpCell (PSCell) may be initiated in a deactivated SCG by the MAC entity triggering a scheduling request to transmit a MAC PDU containing a MAC CE, or directly by the MAC entity. In this case, the MAC PDU may not contain a MAC SDU.

On the other hand, a random access procedure in the SpCell (PSCell) may be initiated in a deactivated SCG by triggering a scheduling request to transmit a MAC PDU containing data (MAC SDU) from a higher layer, such as user data or an RRC message.

The return of an SCG from an inactivated state (activation of an SCG) may also be referred to as leaving a dormant SCG. Furthermore, the return of an SCG from an inactivated state may also be a BWP switch from a dormant BWP to another (non-dormant) BWP in the SpCell of the cell group.

The return of SCG from an inactivated state may also be referred to as SCG activation.

A terminal device that deactivates an SCG may perform some or all of the following processes (A) to (F) in the SCG.
(A) All SCells are in an inactive state.
(B) All SCell inactivity timers associated with the active SCell are considered to have expired.
(C) All SCell inactivity timers associated with the dormant SCell are considered to have expired.
(D) Do not start or restart the SCell inactivity timers associated with all SCells.
(E) Ignore the MAC CE that activates the SCell. For example, in the process (AD), if a MAC CE that activates the SCell is received and an instruction to deactivate the SCG has not been issued (or the SCG is not in a deactivated state), perform process (AD-1).
(F) Execute the process (AD-2). For example, when inactivation of SCG is instructed in the process (AD) (or when SCG is inactivated), the process (AD-2) is executed.

A terminal device that restores an SCG from an inactivated state may perform some or all of the following processes (A) to (D) in the SCG.
(A) To activate all SCells, process (AD-1) is executed.
(B) All SCells remain in the deactivated state. However, since they are not in the deactivated state, for example, if a MAC CE to activate an SCell is received in the process (AD), since no instruction to deactivate the SCG has been given (or the SCG is not in the deactivated state), the process (AD-1) may be performed.
(C) When the SCG returns from the deactivated state based on an RRC message, if this RRC message includes parameters related to random access to some or all SCells, a random access procedure is initiated on the target SCell based on the notified parameters.
(D) When the recovery of the SCG from an inactivated state is performed based on an RRC message, if this RRC message includes information specifying the state of the SCell, a decision is made based on that information as to whether the state of each SCell should be set to an active state or an inactive state.

Based on the above explanation, various embodiments of the present invention will be described. Note that the processes described above may be applied to the processes omitted in the following explanation.

Figure 5 is a block diagram showing the configuration of a terminal device (UE122) in an embodiment of the present invention. Note that, to avoid complicating the explanation, Figure 5 shows only the main components closely related to one embodiment of the present invention.

The UE 122 shown in FIG. 5 comprises a receiver 500 that receives RRC messages and the like from a base station device, a processor 502 that performs processing according to parameters included in the received messages, and a transmitter 504 that transmits RRC messages and the like to the base station device. The base station device mentioned above may be the eNB 102 or the gNB 108. The processor 502 may include some or all of the functions of various layers (e.g., the physical layer, MAC layer, RLC layer, PDCP layer, SDAP layer, RRC layer, and NAS layer). That is, the processor 502 may include some or all of the physical layer processing section, MAC layer processing section, RLC layer processing section, PDCP layer processing section, SDAP processing section, RRC layer processing section, and NAS layer processing section.

Figure 6 is a block diagram showing the configuration of a base station device in an embodiment of the present invention. Note that, to avoid complicating the explanation, Figure 6 shows only the main components that are closely related to one embodiment of the present invention. The above-mentioned base station device may be eNB102 or gNB108.

The base station apparatus shown in FIG. 6 comprises a transmitter 600 that transmits RRC messages and the like to UE 122, a processor 602 that creates an RRC message including parameters and transmits it to UE 122, causing the processor 502 of UE 122 to process it, and a receiver 604 that receives RRC messages and the like from UE 122. Furthermore, the processor 602 may include some or all of the functions of various layers (e.g., the physical layer, MAC layer, RLC layer, PDCP layer, SDAP layer, RRC layer, and NAS layer). That is, the processor 602 may include some or all of the physical layer processor, MAC layer processor, RLC layer processor, PDCP layer processor, SDAP processor, RRC layer processor, and NAS layer processor.

The following describes various examples of terminal device processing in embodiments of the present invention.

Figure 15 is a diagram showing an example of processing by a terminal device in an embodiment of the present invention.

The terminal device (UE122) receives an RRC message from the base station device (eNB102 or gNB108) (step S1500). This RRC message may include information for determining whether to activate or deactivate the secondary cell group.

The terminal device may initiate a random access procedure in the SpCell of this secondary cell group based on whether the received RRC message contains information indicating that the secondary cell group is to be in an active state or does not contain information indicating that the secondary cell group is to be in an inactive state.The terminal device may not initiate a random access procedure in the SpCell of this secondary cell group based on whether the received RRC message contains information indicating that the secondary cell group is to be in an inactive state or does not contain information indicating that the secondary cell group is to be in an active state (step S1502).

The terminal device may also start the first timer based on the fact that the received RRC message includes information indicating that the secondary cell group is to be activated or does not include information indicating that the secondary cell group is to be deactivated. The terminal device may not start the first timer based on the fact that the received RRC message includes information indicating that the secondary cell group is to be deactivated or does not include information indicating that the secondary cell group is to be activated. The terminal device may stop the first timer based on the successful completion of the random access procedure in the SpCell of the secondary cell group. The terminal device may also stop the first timer when the secondary cell group is released and/or deactivated. The terminal device may initiate an SCG failure information procedure to report SCG failure information when the first timer expires. The SCG failure information may include information indicating that SCG activation has failed.

The terminal device may place a cell group in an inactive state based on the fact that the received RRC message contains information indicating that the cell group should be placed in an inactive state or does not contain information indicating that the cell group should be placed in an active state.The terminal device may place a cell group in an active state based on the fact that the received RRC message contains information indicating that the cell group should be placed in an active state or does not contain information indicating that the cell group should be placed in an inactive state, and based on the fact that the random access procedure in the SpCell for that cell group has been successfully completed.

This allows terminal devices to efficiently activate and deactivate cell groups.

An example is shown below in which the above RRC message is an RRC reconfiguration message. The terminal device receives an RRC reconfiguration message from a base station device (eNB102 or gNB108). This RRC reconfiguration message may include information for determining whether to activate or deactivate the secondary cell group.

When the secondary cell group configuration included in the RRC reconfiguration message includes a synchronized reconfiguration information element, the terminal device (1) initiates a random access procedure based on whether the received RRC reconfiguration message includes information indicating that the secondary cell group is to be activated or does not include information indicating that the secondary cell group is to be deactivated, and (2) does not initiate a random access procedure based on whether the received RRC reconfiguration message includes information indicating that the secondary cell group is to be deactivated or does not include information indicating that the secondary cell group is to be activated.

Furthermore, the terminal device does not start timer T304 based on the fact that the received RRC reconfiguration message contains information indicating that the secondary cell group is to be deactivated, even if the secondary cell group configuration in this RRC reconfiguration message contains a synchronized reconfiguration information element. Alternatively, the terminal device starts timer T304 based on the fact that the secondary cell group configuration in this RRC reconfiguration message contains a synchronized reconfiguration information element, and stops timer T304 based on the fact that the received RRC reconfiguration message contains information indicating that the secondary cell group is to be deactivated or does not contain information indicating that the secondary cell group is to be activated.

This allows the terminal device to efficiently activate and deactivate cell groups using RRC reconfiguration messages.

This section explains how to indicate whether an SCG is in an active or inactive state when adding a PSCell of an SCG and zero or more SCells to a terminal device.

The terminal device receives an RRC message to add a PSCell of the SCG and zero or more SCells. This RRC message may be the RRC reconfiguration message shown in Figure 9. When a PSCell is added, the RRC message may include a synchronized reconfiguration information element that includes configuration of cell-specific parameters of the SpCell, such as a physical cell identifier.

The RRC message may also include information indicating whether the SCG is to be activated or deactivated. For example, the information may be included in the configuration of the target cell group (e.g., a cell group configuration information element). For example, the information may also be included in a synchronized reconfiguration information element included in the cell group configuration information element of the target cell group. The information may also be included in any information element included in the RRC message.

The information may be information indicating whether the cell group is to be in an active state or an inactive state. The information may also be information indicating that the cell group is to be in an active state. In this case, the cell group may be in an inactive state based on the absence of this information. The information may also be information indicating that the cell group is to be in an inactive state. In this case, the cell group may be in an active state based on the absence of this information. The information may also be information indicated by other information elements. Note that if the information is not included in the settings of the target cell group, the information may include information indicating which cell group is the target. Note that if there is only one cell group (secondary cell group) that can be the target, the information does not need to include information indicating which cell group is the target.

For example, the information may be a field (scgState-r17) having the value "deactivated" of the ENUMERATED type. In this case, the terminal device may determine that the field (scgState-r17) having the value "deactivated" is a cell group that deactivates the target cell group when it is included in the RRC message, and may determine that the target cell group is a cell group that activates the target cell group based on the absence of this field in the RRC message. Also, for example, the information may be a field (scgState-r17) having the values "deactivated" and "activated" of the ENUMERATED type. In this case, the terminal device may determine that the field (scgState-r17) having the value "deactivated" is a cell group that deactivates the target cell group when it is included in the RRC message, and may determine that the target cell group is a cell group that activates the target cell group based on the absence of this field in the RRC message, and may determine that the RRC message is not a message for activating and/or deactivating a cell group based on the absence of this field in the RRC message.

In a terminal device that receives an RRC reconfiguration message, the RRC entity of the terminal device may perform some or all of the following (A) to (D).
(A) If the RRCReconfiguration includes a secondaryCellGroup, the following (A-1) to (A-7) are executed for the secondary cell group based on this secondaryCellGroup.
(A-1) If CellGroupConfig includes spCellConfig including reconfigurationWithSync, the RRC entity of the terminal device performs some or all of the following (A-1-1) to (A-1-9).
(A-1-1) If AS security is not activated, execute the process to transition to RRC_IDLE and end the procedure.
(A-1-2) Timer T304 for the SpCell (to be configured) is started using the value of t304 included in reconfigurationWithSync. Here, if the RRC reconfiguration message includes information indicating that the cell group to be configured is to be deactivated, timer T304 may not be started. If the RRC reconfiguration message includes information indicating that the cell group to be configured is to be deactivated, timer T304 may be stopped if it is running.
(A-1-3) If downlink frequency information (frequencyInfoDL) is included in reconfigurationWithSync, the cell indicated by the physical cell identifier (physCellId) included in reconfigurationWithSync at the SSB frequency indicated in frequencyInfoDL is determined to be the target SpCell.
(A-1-4) If the downlink frequency information (frequencyInfoDL) is not included in reconfigurationWithSync, the cell indicated by the physical cell identifier (physCellId) included in reconfigurationWithSync at the SSB frequency of the original SpCell (Source SpCell) is determined to be the target SpCell.
(A-1-5) Start downlink synchronization of the target SpCell.
(A-1-6) Acquire the MIB of the target SpCell.
(A-1-7) If a specific bearer (DAPS bearer) is not configured, perform some or all of the following steps (A-1-7-1) to (A-1-7-4).
(A-1-7-1) Reset the MAC entity of this cell group.
(A-1-7-2) If an SCell not included in SCellToAddModList is set in this cell group, this SCell is put into an inactive state.
(A-1-7-3) The value of newUE-Identity is applied as the C-RNTI of this cell group.
(A-1-7-4) Configure the lower layer based on the received spCellConfigCommon.
(A-1-8) Resume all suspended radio bearers. Here, if the RRC reconfiguration message includes information indicating that the cell group to be configured is to be deactivated, some suspended radio bearers (e.g., SRB3) may not be restored (or all suspended radio bearers except for some radio bearers (e.g., SRB3) may be restored). If the RRC reconfiguration message includes information indicating that the cell group to be configured is to be deactivated, some radio bearers (e.g., SRB3) may be suspended.
(A-1-9) If the SCG transmission for all radio bearers is suspended, it is resumed. Here, if the RRC reconfiguration message includes information indicating that the cell group to be configured is to be deactivated, the SCG transmission for all radio bearers may be suspended.
(A-2) If the CellGroupConfig contains an rlc-BearerToReleaseList, release of the RLC bearer is performed based on this rlc-BearerToReleaseList.
(A-3) If CellGroupConfig includes rlc-BearerToAddModList, add and/or modify RLC bearers based on this rlc-BearerToAddModList.
(A-4) If the CellGroupConfig contains a mac-CellGroupConfig, the MAC entity of this cell group is configured based on this mac-CellGroupConfig.
(A-5) If sCellToReleaseList is included in CellGroupConfig, release of SCell is performed based on this sCellToReleaseList.
(A-6) If the CellGroupConfig contains an spCellConfig, configure the SpCell based on this spCellConfig.
(A-7) If sCellToAddModList is included in CellGroupConfig, add and/or modify SCells based on this sCellToAddModList.
(B) Set the content to be included in the RRC reconfiguration complete message.
(C) If the SpCell configuration (spCellConfig) of the received secondary cell group configuration includes "reconfigurationWithSync", the random access procedure is initiated in that SpCell. Here, if the RRC reconfiguration message includes information indicating that the cell group to be configured is to be deactivated, the random access procedure may not be initiated in the SpCell of the target cell group. Also, if the RRC reconfiguration message includes information indicating that the cell group to be configured is to be deactivated, the MAC entity of the cell group to be configured may be notified that the cell group is to be deactivated.
(D) If the SpCell configuration (spCellConfig) of the MCG or SCG includes "reconfigurationWithSync" and the random access procedure is successfully completed in the NR cell group, timer T304 of the cell group is stopped. Here, if the RRC reconfiguration message includes information indicating that the cell group to be configured is to be deactivated, timer T304 of the cell group may be stopped if the SpCell configuration (spCellConfig) of the MCG or SCG includes "reconfigurationWithSync." Also, if the RRC reconfiguration message includes information indicating that the cell group to be configured is to be deactivated, the MAC entity of the cell group to be configured may be notified that the cell group is to be activated.

The terminal device may also stop T304 for an SCG based on the SCG being released and/or becoming inactive.

The terminal device may place a secondary cell group in an inactive state based on the fact that the received RRC configuration message contains information indicating that the secondary cell group is to be placed in an inactive state or does not contain information indicating that the secondary cell group is to be placed in an active state.The terminal device may place a secondary cell group in an active state based on the fact that the received RRC configuration message contains information indicating that the secondary cell group is to be placed in an active state or does not contain information indicating that the secondary cell group is to be placed in an inactive state, and based on the fact that the random access procedure in the SpCell of the secondary cell group has been successfully completed.

This allows the terminal device to efficiently activate and deactivate cell groups using RRC reconfiguration messages.

In addition, the above procedure can also be applied to indicating whether an SCG configured in a terminal device is in an active or inactive state without adding a PSCell and/or SCell to the SCG.

We describe another method for indicating to a terminal device whether an SCG is active or inactive.

The terminal device receives an RRC message. This RRC message may be the RRC reconfiguration message shown in Figure 9 or may be another RRC message.

The RRC message may include information indicating whether the SCG is in an active or inactive state.

The information may be information indicating whether to activate or deactivate a cell group. The information may also be information indicating that a cell group should be activated. In this case, the cell group may be deactivated based on the absence of this information. The information may also be information indicating that a cell group should be deactivated. In this case, the cell group may be activated based on the absence of this information. The information may also be information indicated by other information elements. Note that if the information is not included in the configuration of the target cell group, the information may include information indicating which cell group is the target. Note that if there is only one cell group (secondary cell group) that can be the target, the information does not need to include information indicating which cell group is the target. The information indicating that a cell group should be activated may also include an information element (rach-ConfigDedicated) that includes terminal device-specific parameters used in the random access procedure.

In a terminal device that receives an RRC message that includes information indicating that a cell group is to be activated or that does not include information indicating that a cell group is to be deactivated, the RRC entity of the terminal device may perform some or all of the following (A) to (F).
(A) A second timer (also referred to as timer T304X) for the SpCell of the target cell group is started. The value used for the second timer may be included in the RRC message, the value of t304 may be used, or a default value may be used.
(B) Resume all suspended radio bearers.
(C) Resume SCG transmission for all radio bearers if suspended.
(D) Initiate a random access procedure in the SpCell of the target cell group.
(E) When the random access procedure is successfully completed in the target cell group, the second timer for the cell group is stopped.
(F) Notify the MAC entity of the target cell group that the cell group has become active.

In addition, in a terminal device that receives an RRC message that includes information indicating that a cell group is to be in an inactive state or that does not include information indicating that a cell group is to be in an active state, the RRC entity of the terminal device may perform some or all of the following (A) to (D).
(A) If the second timer (also referred to herein as timer T304X) for the SpCell of the target cell group is running, stop it.
(B) Suspend some radio bearers (e.g., SRB3).
(C) Suspend SCG transmission for all radio bearers.
(D) Notify the MAC entity of the target cell group that the cell group has become inactive.

The terminal device may stop the second timer for the SCG based on the SCG being released and/or the SCG becoming inactive.

The operation of the terminal device when the second timer expires is described below.

If the second timer of the secondary cell group expires, the RRC entity of the terminal device performs the following process (A) if the MCG transmission is not suspended, and performs the following process (B) if the MCG transmission is suspended.
(A) If the terminal device specific preamble provided in rach-ConfigDedicated is set, release it and start the SCG failure information procedure to report the failure of the SCG synchronized reconfiguration.
(B) Initiate the RRC connection re-establishment procedure.

This allows terminal devices to efficiently activate and deactivate cell groups using RRC messages.

This section explains the mechanism of conditional reconfiguration in NR. The network may configure one or more target SpCell candidates in the terminal device through conditional reconfiguration. The terminal device may evaluate the conditions for each configured target SpCell candidate. The terminal device may select one of the cells from each target SpCell candidate that satisfies the execution conditions associated with each candidate and apply the conditional reconfiguration associated with that cell. The network may provide the configuration for the target SpCell to the terminal device using a conditional reconfiguration information element (ConditionalReconfiguration IE). The terminal device may store the conditional reconfiguration information provided in the conditional reconfiguration information element in a variable (VarConditionalReconfig) as one or more entries.

When a terminal device receives an RRC reconfiguration message, if the SCG's SpCell configuration (spCellConfig) includes reconfigurationWithSync, if this RRC reconfiguration message is a message to activate an SCG configured in the terminal device and in an inactive state, or a message to deactivate an SCG configured in the terminal device and in an active state, it may retain the variable (VarConditionalReconfig); if this RRC reconfiguration message is not a message to activate an SCG configured in the terminal device and in an inactive state, or a message to deactivate an SCG configured in the terminal device and in an active state, it may delete all entries in the variable (VarConditionalReconfig).

An example of an embodiment will be described. A terminal device communicating with a base station device receives from the base station device a first RRC message instructing the addition of an SpCell to a first cell group, and a second RRC message instructing the first cell group to transition from a first state in which the SpCell does not monitor the PDCCH to a second state in which the SpCell monitors the PDCCH. The terminal device may include a processing unit that starts a first timer upon reception of the first RRC message and starts a second timer upon reception of the second RRC message. The processing unit of the terminal device may further generate failure information for the first cell group based on expiration of the first timer or the second timer.

For example, the first cell group may be a secondary cell group. The first RRC message may be an RRC reconfiguration message including a synchronized reconfiguration information element. The second RRC message may be an RRC reconfiguration message or another RRC message. The first timer may be timer T304. The first state may be a state in which an SCG is deactivated. The second state may be a state in which an SCG is activated. The generation of failure information for the first cell group may be the initiation of an SCG failure information procedure.

The processing unit may also stop the first timer based on the satisfaction of any one of the following conditions: random access to the SpCell has been successfully completed, the first cell group has been released, and the first cell group has entered the first state. The processing unit may also stop the second timer based on the satisfaction of any one of the following conditions: random access to the SpCell has been successfully completed, the first cell group has been released, and the first cell group has entered the first state.

An example of an embodiment will be described. A terminal device may include a receiver that receives a first RRC message including parameters for synchronous reconfiguration of an SpCell of a first cell group from a base station device, and a processor that starts a first timer based on the reception of the first RRC message. The processor may determine whether to start the first timer based on whether first information is included in the first RRC message, and may generate failure information for the first cell group based on expiration of the first timer.

The first cell group may be a secondary cell. The synchronized reconfiguration may be a synchronized reconfiguration information element included in an RRC reconfiguration message, or part of the information included in the synchronized reconfiguration information element. That is, the first RRC message may be an RRC reconfiguration message. The first information may be information indicating that the first cell group is to be deactivated. It may also indicate that the first cell group is to be activated if the first information is not included. The first timer may be timer T304. The generation of failure information for the first cell group may be the initiation of an SCG failure information procedure.

An example of an embodiment will be described. A terminal device may include a receiver that receives a first RRC message including parameters for synchronous reconfiguration of an SpCell of a first cell group from a base station device, a processor that processes the first RRC message, and a transmitter that transmits a random access preamble in the SpCell based on the reception of the first RRC message. The processor may determine whether to transmit the random access preamble in the SpCell based on whether first information is included in the first RRC message.

The first cell group may be a secondary cell. The synchronization reconfiguration may be a synchronization-with-reconfiguration information element included in the RRC reconfiguration message, or part of the information included in the synchronization-with-reconfiguration information element. That is, the first RRC message may be an RRC reconfiguration message. The first information may be information indicating that the first cell group is to be deactivated. Alternatively, it may indicate that the first cell group is to be activated when the first information is not included.

An example of an embodiment will be described. A terminal device may include a receiving unit that receives a first RRC message including parameters for synchronous reconfiguration of an SpCell of a first cell group from the base station device, and a processing unit that resumes suspended radio bearers based on the reception of the first RRC message. The processing unit may determine whether to resume all suspended radio bearers based on whether first information is included in the first RRC message. The processing unit may also determine whether to resume SCG transmission for all suspended radio bearers based on whether first information is included in the first RRC message.

The first cell group may be a secondary cell. The synchronization reconfiguration may be a synchronization-with-reconfiguration information element included in the RRC reconfiguration message, or part of the information included in the synchronization-with-reconfiguration information element. That is, the first RRC message may be an RRC reconfiguration message. The first information may be information indicating that the first cell group is to be deactivated. Alternatively, it may indicate that the first cell group is to be activated when the first information is not included.

In the above explanation, an example was shown in which a base station device uses an RRC reconfiguration message (first message) including a synchronized reconfiguration information element, or another RRC message (second message), to instruct a terminal device to activate and deactivate a cell group that has been configured (set) in the terminal device. However, this is not limited to this, and the first message may be used to activate a cell group and the second message to deactivate the cell group, or the second message may be used to activate a cell group and the first message to deactivate a cell group.

In addition, the RRC entity of the terminal device that deactivates the SCG may perform some or all of the following (A) to (E).
(A) Suspend SCG transmission for all SRBs and DRBs.
(B) Reset the SCG MAC.
(C) If the first timer in this SCG is running, stop it.
(D) If conditional reconfiguration for PSCell change is set, stop this evaluation.
(E) Submit to the lower layer for transmission a message indicating completion of deactivation.

In addition, the RRC entity of the terminal device that activates the SCG may perform some or all of the following (A) to (D).
(A) Resume SCG transmission for all SRBs and DRBs.
(B) Reset the SCG MAC.
(C) If conditional reconfiguration for PSCell changes is configured, start (or resume) this evaluation.
(D) Submit to the lower layer for transmission of a message indicating completion of activation.

Furthermore, "including information indicating that the cell group is to be in an inactive state" does not necessarily mean that the terminal device directly includes information indicating that the cell group is to be in an inactive state. For example, "including information indicating that the cell group is to be in an inactive state" may simply mean that the first information is included, or that the second information is not included. The terminal device may perform the above-mentioned processing based on the inclusion of the first information or the absence of the second information. Similarly, "including information indicating that the cell group is to be in an active state" does not necessarily mean that the terminal device directly includes information indicating that the cell group is to be in an active state. For example, "including information indicating that the cell group is to be in an active state" may simply mean that the second information is included, or that the first information is not included. The terminal device may perform the above-mentioned processing based on the inclusion of the second information or the absence of the first information.

In addition, the above-mentioned reconfiguration with synchronization information element (ReconfigurationWithSync) is always included when configuring a secondary cell group (A) adding a PSCell, (B) resuming SCG transmission in NR-DC or (NG)EN-DC from a suspended state, (C) updating system information required in the PSCell, and (D) changing the security key of the AS, but it may also be included when activating and/or deactivating an SCG.

"Including information indicating that a cell group is to be in an inactive state" may include not including information indicating that a cell group is to be in an active state. Similarly, "Including information indicating that a cell group is to be in an active state" may include not including information indicating that a cell group is to be in an inactive state.

Furthermore, activation (deactivation) of a cell group and activation (deactivation) of the SpCells of that cell group may be interchangeable terms. Similarly, placing a cell group in an active state (inactive state) and placing the SpCells of that cell group in an active state (inactive state) may be interchangeable terms.

The radio bearer in the above description may be a DRB, an SRB, or a combination of a DRB and an SRB.

In addition, in the above explanation, expressions such as "link," "associate," and "associate" may be used interchangeably.

Also, in the above explanation, "the above-mentioned" can be replaced with "the above-mentioned."

Also, in the above explanation, "SCG SpCell" can be replaced with "PSCell."

In the above explanation, "dormant state" may be rephrased as "inactive state," and "state after recovery from dormant state" may be rephrased as "active state." Furthermore, in the above explanation, "activated" and "inactivated" may be rephrased as "active state" and "inactive state," respectively.

In the above explanation, "transition from X to Y" can be rephrased as "X becomes Y." Also, "activated BWP" can be rephrased as "Active BWP."

In addition, in each example of processing or example of processing flow in the above description, some or all of the steps may not be executed. In addition, in each example of processing or example of processing flow in the above description, the order of the steps may be different. In each example of processing or example of processing flow in the above description, some or all of the processing within each step may not be executed. In addition, in each example of processing or example of processing flow in the above description, the order of the processing within each step may be different. In addition, in the above description, "doing B based on A being true" may be rephrased as "doing B". In other words, "doing B" may be executed independently of "being A".

In the above explanation, "A may be replaced with B" may mean replacing A with B, as well as replacing B with A. Also, in the above explanation, when it is stated that "C may be D" and "C may be E", it may also include "D may be E". Also, in the above explanation, when it is stated that "F may be G" and "G may be H", it may also include "F may be H".

Also, in the above explanation, if condition "A" and condition "B" are contradictory conditions, condition "B" may be expressed as an "other" condition of condition "A."

The following describes various aspects of the terminal device and method in embodiments of the present invention.

(1) A first embodiment of the present invention is a terminal device that communicates with a base station device, comprising: a receiving unit that receives a first RRC message from the base station device, the RRC message including parameters for synchronous reconfiguration of an SpCell of a first cell group; and a processing unit that resumes suspended radio bearers based on the reception of the first RRC message, and the processing unit determines whether to resume all suspended radio bearers based on whether the first RRC message includes first 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 to the terminal device a first RRC message including parameters for synchronous reconfiguration of an SpCell of a first cell group; and a processing unit that causes the terminal device to resume suspended radio bearers based on the transmission of the first RRC message, and the processing unit causes the terminal device to determine whether to resume all suspended radio bearers depending on whether the first information is included in the first RRC message.

(3) A third embodiment of the present invention is a method applied to a terminal device communicating with a base station device, comprising the steps of receiving a first RRC message from the base station device, the first RRC message including parameters for synchronous reconfiguration of an SpCell of a first cell group, and resuming suspended radio bearers based on the reception of the first RRC message, and determining whether to resume all suspended radio bearers based on whether the first RRC message includes first information.

(4) A fourth embodiment of the present invention is a method applied to a base station device communicating with a terminal device, comprising the steps of: transmitting a first RRC message to the terminal device including parameters for synchronous reconfiguration for an SpCell of a first cell group; and causing the terminal device to resume suspended radio bearers based on the transmission of the first RRC message, and causing the terminal device to determine whether to resume all suspended radio bearers depending on whether the first information is included in the first RRC message.

(5) A fifth embodiment of the present invention is an integrated circuit implemented in a terminal device that communicates with a base station device, and causes the terminal device to perform the functions of receiving a first RRC message from the base station device, the first RRC message including parameters for synchronous reconfiguration of an SpCell of a first cell group, and resuming suspended radio bearers based on the reception of the first RRC message, and the processing unit determines whether to resume all suspended radio bearers based on whether the first information is included in the first RRC message.

(6) A sixth embodiment of the present invention is an integrated circuit implemented in a base station device that communicates with a terminal device, and causes the base station device to perform the functions of transmitting a first RRC message to the terminal device, the first RRC message including parameters for synchronous reconfiguration of an SpCell of a first cell group, and of causing the terminal device to resume suspended radio bearers based on the transmission of the first RRC message, and the processing unit causes the terminal device to determine whether to resume all suspended radio bearers depending on whether the first information is included in the first RRC message.

A program running on an apparatus relating to one aspect of the present invention may be a program that controls a central processing unit (CPU) or the like to cause a computer to function so as to realize the functions of the above-described embodiment relating to one aspect of the present invention. The program or information handled by the program is temporarily loaded into volatile memory such as random access memory (RAM) during processing, or stored in non-volatile memory such as flash memory or a hard disk drive (HDD), and is read, modified, and written by the CPU as needed.

It should be noted that a portion of the device in the above-described embodiments may be implemented by a computer. In this case, the program for implementing this control function may be recorded on a computer-readable recording medium, and the program recorded on this recording medium may be loaded into a computer system and executed. The term "computer system" as used here refers to a computer system built into the device, and includes hardware such as an operating system and peripheral devices. Furthermore, the term "computer-readable recording medium" may be any of a semiconductor recording medium, optical recording medium, magnetic recording medium, etc.

Furthermore, "computer-readable recording medium" may include a 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, or a medium that stores a program for a fixed period of time, such as volatile memory within a computer system that serves as a server or client in such cases. Furthermore, the above-mentioned program may be one that realizes some of the functions described above, or may be one that can realize the functions described above in combination with a program already stored in the computer system.

Additionally, each functional block or feature of the device used in the above-described embodiments may be implemented or performed by an electrical circuit, typically an integrated circuit or multiple integrated circuits. The electrical circuit designed to perform the functions described herein may include a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or a combination thereof. The general-purpose processor may be a microprocessor, or alternatively, the processor may be a conventional processor, controller, microcontroller, or state machine. The general-purpose processor or each of the aforementioned circuits may be composed of digital circuits or analog circuits. Furthermore, if advances in semiconductor technology result in the emergence of integrated circuit technologies that can replace current integrated circuits, integrated circuits based on those technologies may also be used.

Note that the present invention is not limited to the above-described embodiment. While the embodiment describes an example of a device, the present invention is not limited to this and can be applied to terminal devices or communication devices such as stationary or non-mobile electronic devices installed indoors or outdoors, such as AV equipment, kitchen equipment, cleaning/washing equipment, air conditioning equipment, office equipment, vending machines, and other household appliances.

Although the embodiments of the present invention have been described in detail above with reference to the drawings, the specific configuration is not limited to this embodiment and includes design modifications within the scope of the gist of the invention. Furthermore, various modifications of one aspect of the present invention are possible within the scope of the claims, and embodiments obtained by appropriately combining the technical means disclosed in different embodiments are also included in the technical scope of the present invention. Furthermore, configurations in which elements described in the above embodiments are substituted for elements that achieve the same effect are also included.

One aspect of the present invention can be used, for example, in communication systems, communication equipment (e.g., mobile phone devices, base station devices, wireless LAN devices, or sensor devices), integrated circuits (e.g., communication chips), or programs.

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

Claims (2)

A terminal device that communicates with a base station device,
a receiving unit that receives a first RRC message including parameters for synchronous reconfiguration of an SpCell of a first cell group from the base station device;
a processing unit that initiates downlink synchronization to a target Spcell indicated by the parameter based on reception of the first RRC message;
Equipped with
the processing unit determines whether to start a first timer based on whether first information is included in the first RRC message;
determining that the synchronization reestablishment has failed based on the expiration of the first timer;
Terminal device. A method applied to a terminal device that communicates with a base station device ,
receiving a first RRC message including parameters for synchronous reconfiguration of an SpCell of a first cell group in the terminal device;
initiating downlink synchronization to a target SpCell indicated by the parameter based on receiving the first RRC message;
determining that resynchronization has failed based on the expiration of a first timer;
and
determining whether to start the first timer based on whether first information is included in the first RRC message;
method.