JP7846085B2 - Terminal equipment, base station equipment, and method - Google Patents

Description

The present invention relates to terminal equipment, base station equipment, and methods.
This application claims priority to Japanese Patent Application No. 2021-41284, filed in Japan on March 15, 2021, and the contents of that application 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 wireless access, core networks, and services.

For example, E-UTRA (Evolved Universal Radio Regressive Radio Access) was initiated by 3GPP as a Radio Access Technology (RAT) for 3.9th and 4th generation cellular mobile communication systems, with technical review and standardization underway. Currently, 3GPP is also reviewing and standardizing extensions to E-UTRA. E-UTRA is also known as Long Term Evolution (LTE: registered trademark), and its extensions are sometimes referred to as LTE-Advanced (LTE-A) and LTE-Advanced Pro (LTE-A Pro).

Furthermore, NR (New Radio, or NR Radio Access) has been initiated by 3GPP as a Radio Access Technology (RAT) for 5th Generation (5G) cellular mobile communication systems, with technical studies and standards development underway. Currently, 3GPP is also conducting technical studies and standards development for extensions of NR.

3GPP TS 38.300v 16.4.0,"NR;NR and NG-RAN Overall description; Stage 2" pp10-134 3GPP TS 36.300 v16.4.0,"Evolved Universal Terrestrial Radio Access (E-UTRA)and Evolved Universal Terrestrial Radio Access Network (E-UTRAN);Overall description; Stage 2" pp19-362 3GPP TS 38.331 v16.3.1,"NR;Radio Resource Control (RRC);Protocol specifications"pp21-881 3GPP TS 36.331 v16.3.0,"Evolved Universal Terrestrial Radio Access (E-UTRA);Radio Resource Control (RRC);Protocol specifications" pp25-1015 3GPP TS 37.340 v16.4.0,"EvolvedUniversal Terrestrial Radio Access (E-UTRA)and NR; Multi-Connectivity; Stage 2" pp7-77 3GPP TS 38.321 v16.3.0, "NR;Medium Access Control (MAC) protocol specification" pp8-152

As an extension of NR (New Radio), dual connectivity (also called multi-connectivity) technology enables high-capacity data communication using multiple cell groups, allowing one or more base station devices and terminal devices to communicate. In this dual connectivity, terminal devices need to monitor each cell group for the presence of messages addressed to them in order to communicate within each cell group. Terminal devices need to constantly monitor multiple cell groups to ensure low-latency communication when high-capacity data communication occurs, which leads to the problem of consuming a lot of power. Therefore, consideration has been given to technologies that monitor some cell groups at a low frequency or stop them altogether (cell group dormant technology).

Currently, the focus of discussion in cell group dormancy is on how to handle cells that are always in an active state (SpCells), but it is also necessary to consider other types of cells.

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

To achieve the above objective, one aspect of the present invention employs the following means. That is, one aspect of the present invention is a terminal device having a first cell group and a second cell group, wherein the second cell group has a first cell, the first cell belongs to a first timing advance group, the first timing advance group has a first timer, and the terminal device includes a processing unit for clearing a grant type 1 configured uplink grant, wherein when the first timer expires, the processing unit clears the grant type 1 configured uplink grant based on the second cell group not being inactive, and does not clear the grant type 1 configured uplink grant based on the second cell group being inactive.

Furthermore, one aspect of the present invention is a communication method applicable to a terminal device having a first cell group and a second cell group configured, wherein the second cell group has a first cell configured, the first cell belongs to a first timing advance group, the first timing advance group has a first timer configured, the configured uplink grant of grant type 1 is cleared, and when the first timer expires, the configured uplink grant of grant type 1 is cleared based on the fact that the second cell group is not in an inactive state, and the configured uplink grant of grant type 1 is not cleared based on the fact that the second cell group is in an inactive state.

One aspect of the present invention is a base station device that communicates with a terminal device, wherein the terminal device is configured with a first cell group and a second cell group, the second cell group is configured with a first cell, the first cell belongs to a first timing advance group, the first timing advance group is configured with a first timer, and the base station device includes a processing unit that clears a configured uplink grant of grant type 1, and when the first timer expires, the processing unit clears the configured uplink grant of grant type 1 based on the fact that the second cell group is not inactive, and does not clear the configured uplink grant of grant type 1 based on the fact that the second cell group is inactive.

Furthermore, one aspect of the present invention is a communication method applied to a base station device that communicates with a terminal device, wherein the terminal device is configured with a first cell group and a second cell group, the second cell group is configured with a first cell, the first cell belongs to a first timing advance group, the first timing advance group is configured with a first timer, the configured uplink grant of grant type 1 is cleared, and when the first timer expires, the configured uplink grant of grant type 1 is cleared based on the fact that the second cell group is not in an inactive state, and the configured uplink grant of grant type 1 is not cleared based on the fact that the second cell group is in an inactive state.

These comprehensive or specific embodiments may be implemented as systems, devices, methods, integrated circuits, computer programs, or recording media, or as any combination of systems, devices, methods, integrated circuits, computer programs, and recording media.

According to one aspect of the present invention, terminal devices, base station devices, methods, and integrated circuits can realize efficient communication control processing.

A schematic diagram of a communication system according to an embodiment of the present invention. A diagram showing an example of the E-UTRA protocol configuration according to an embodiment of the present invention. A diagram showing an example of the NR protocol configuration according to the present invention. A diagram showing an example of a procedure flow for various settings in an RRC according to an embodiment of the present invention. A block diagram showing the configuration of a terminal device in an embodiment of the present invention. A block diagram showing the configuration of a base station device in an embodiment of the present invention. An example of an ASN.1 description included in a message regarding the reconfiguration of the RRC connection in NR in an embodiment of the present invention. An example of an ASN.1 description included in a message regarding the reconfiguration of the RRC connection in E-UTRA in an embodiment of the present invention. An example of a process related to SCG dormancy in an embodiment of the present invention. An example of a process relating to SCG activation in an embodiment of the present invention. An example of a treatment for inactivating SCG in an embodiment of the present invention. An example of processing related to a configured uplink grant of grant type 1 in an embodiment of the present invention. An example of processing related to a configured uplink grant of grant type 1 in an embodiment of the present invention. An example of a process for determining whether or not the SCG in an embodiment of the present invention is in an inactive state.

Hereinafter, embodiments of the present invention will be described in detail 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. Furthermore, LTE that can connect with NR via Multi Radio Dual connectivity (MR-DC) may be distinguished from conventional LTE. Furthermore, LTE using 5GC in the core network may be distinguished from conventional LTE using 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 terms related to LTE and NR, but embodiments of the present invention may be applied to other technologies using other terms. Also, 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, will be described when the wireless access technology is E-UTRA or NR. However, the embodiments of the present invention may be used with other wireless access technologies. The names of each node and entity in the embodiments of the present invention may be different.

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

E-UTRA100 may be a wireless access technology. E-UTRA100 may also be an air interface between UE122 and eNB102. The air interface between UE122 and eNB102 may be called the Uu interface. eNB (E-UTRAN Node B)102 may be the base station equipment for E-UTRA100. eNB102 may have the E-UTRA protocol described below. The E-UTRA protocol may consist of the E-UTRA User Plane (UP) protocol and the E-UTRA Control Plane (CP) protocol described below. eNB102 may terminate the E-UTRA User Plane (UP) protocol and the E-UTRA Control Plane (CP) protocol with respect to UE122. The wireless access network configured with eNB may be called E-UTRAN.

The EPC (Evolved Packet Core) 104 may be a core network. Interface 112 is an interface between eNB 102 and EPC 104 and may be called the S1 interface. Interface 112 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 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 called the S1-MME interface. The user plane interface of interface 112 may be called the S1-U interface.

One or more eNB102s may be connected to the EPC104 via interface 112. Interfaces may exist between multiple eNB102s connected to the EPC104 (not shown). Interfaces between multiple eNB102s connected to the EPC104 may be called X2 interfaces.

NR106 may be a wireless access technology. NR106 may also be an air interface between UE122 and gNB108. The air interface between UE122 and gNB108 may be called the Uu interface. gNB108 may be the base station equipment for NR106. gNB108 may have the NR protocol described below. The NR protocol may consist of the NR User Plane (UP) protocol and the NR Control Plane (CP) protocol described below. gNB108 may terminate the NR User Plane (UP) protocol and the NR Control Plane (CP) protocol to UE122.

5GC110 may be the core network. Interface 116 is the interface between gNB108 and 5GC110 and may be called the 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 be terminated by the Access and Mobility Management Function (AMF: not shown) in 5GC110. The user plane interface of interface 116 may be terminated by the User Plane Function (UPF: not shown) in 5GC110. The control plane interface of interface 116 may be called the NG-C interface. The user plane interface of interface 116 may be called the NG-U interface.

One or more gNB108s may be connected to the 5GC110 via interface 116. Interfaces may exist between multiple gNB108s connected to the 5GC110 (not shown). The interfaces between multiple gNB108s connected to the 5GC110 may be called Xn interfaces.

eNB102 may have the function of connecting to 5GC110. eNB102 having the function of connecting to 5GC110 may be called ng-eNB. Interface 114 is the interface between eNB102 and 5GC110 and may be called NG interface. 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 interface 114 may be terminated at the Access and Mobility Management Function (AMF: not shown) in 5GC110. The user plane interface of interface 114 may be terminated at the User Plane Function (UPF: not shown) in 5GC110. The control plane interface of interface 114 may be called NG-C interface. The user plane interface of interface 114 may be called NG-U interface. A wireless access network consisting of ng-eNB or gNB may be called NG-RAN. NG-RAN, E-UTRAN, eNB, ng-eNB, and gNB may simply be called a network.

One or more eNB102s may be connected to the 5GC110 via interface 114. Interfaces may exist between multiple eNB102s connected to the 5GC110 (not shown). Interfaces between multiple eNB102s connected to the 5GC110 may be called Xn interfaces. Furthermore, an eNB102 connected to the 5GC110 and a gNB108 connected to the 5GC110 may be connected via interface 120. Interface 120 between an eNB102 connected to the 5GC110 and a gNB108 connected to the 5GC110 may be called Xn interfaces.

gNB108 may have the function of connecting to EPC104. A gNB108 that has the function of connecting to EPC104 may be called an en-gNB. Interface 118 is the interface between gNB108 and EPC104 and may be called the S1 interface. Interface 118 may have a user plane interface through which user data passes. The user plane interface of interface 118 may be terminated at the S-GW (not shown) in EPC104. The user plane interface of interface 118 may be called the S1-U interface. Also, eNB102 connected to EPC104 and gNB108 connected to EPC104 may be connected by interface 120. Interface 120 between eNB102 connected to EPC104 and gNB108 connected to EPC104 may be called the X2 interface.

Interface 124 is the interface between EPC104 and 5GC110, 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.

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. Furthermore, UE122 may be a terminal device capable of simultaneously wireless connection with eNB102 and gNB108. UE122 may have the E-UTRA protocol and/or the NR protocol. Note that the wireless connection may be a Radio Resource Control (RRC) connection.

When UE122 communicates with eNB102 and/or gNB108, a wireless connection may be established by establishing a radio bearer (RB) between UE122 and eNB102 and/or gNB108. The radio bearer used for CP may be called a signaling radio bearer (SRB). The radio bearer used for UP may be called a data radio bearer (DRB). Each radio bearer may be assigned a radio bearer identifier (Identity: ID). The radio bearer identifier for SRB may be called an SRB identifier (SRB Identity, or SRB ID). The radio bearer identifier for DRB may be called a DRB identifier (DRB Identity, or DRB ID).

Furthermore, UE122 may 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, then each DRB established between UE122 and eNB102 and/or gNB108 may be uniquely associated with 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 UE122 communicates with eNB102 and/or gNB108 is connected is 5GC110, each DRB established between UE122 and eNB102 and/or gNB108 may be further associated with one of the PDU (Packet Data Unit) sessions established within 5GC110. Each PDU session may have one or more QoS flows. 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). Each QoS flow may also be identified by a QoS flow identifier (Identity, Identifier, or ID). Furthermore, the same QoS may be guaranteed for data such as IP packets and Ethernet frames passing through the same QoS flow.

EPC104 does not need to have PDU sessions and/or QoS flows. Similarly, 5GC110 does not need to have an EPS bearer. When UE122 is connected to EPC104, UE122 will have EPS bearer information, but not information within PDU sessions and/or QoS flows. Similarly, when UE122 is connected to 5GC110, UE122 will have information within PDU sessions and/or QoS flows, but not information within EPS bearers.

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

Figure 2 is a diagram of an example of the E-UTRA protocol architecture according to an embodiment of the present invention. Figure 3 is a diagram of an example of the NR protocol architecture according to an embodiment of the present invention. The functions of each protocol described using Figure 2 and/or Figure 3 are some functions closely related to the embodiments of the present invention, and other functions may be present. 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-UTRA UP protocol may be a protocol between UE122 and eNB102. That is, the E-UTRA UP protocol may be a protocol that terminates at eNB102 on the network side. As shown in Figure 2(A), the E-UTRA user plane protocol stack may consist of a radio physical layer (PHY) 200, a medium access control layer (MAC) 202, a radio link control layer (RLC) 204, and a packet data convergence protocol layer (PDCP) 206.

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 the protocol between UE122 and gNB108. That is, the NR UP protocol may be a protocol that terminates at gNB108 on the network side. As shown in Figure 3(A), the E-UTRA user plane protocol stack may consist of the wireless physical layer PHY300, the media access control layer MAC302, the wireless link control layer RLC304, the packet data convergence protocol layer PDCP306, and the service data adaptation protocol layer (service data adaptation protocol layer) SDAP (Service Data Adaptation Protocol)310.

Figure 2(B) shows the configuration of the E-UTRAN control plane (CP) protocol. As shown in Figure 2(B), in the E-UTRAN CP protocol, the Radio Resource Control (RRC) 208, which is the radio resource control layer, may be a protocol between the UE122 and the eNB102. That is, the RRC208 may be a protocol that terminates at the eNB102 on the network side. Also, in the E-UTRAN CP protocol, the Non Access Stratum (NAS) 210, which is the non-Access Stratum (AS) layer, may be a protocol between the UE122 and the MME. That is, the NAS210 may be a protocol that terminates at the MME on the network side.

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

The Access Stratum (AS) layer may be a layer that terminates between UE122 and eNB102 and/or gNB108. That is, the AS layer may be a layer containing some or all of PHY200, MAC202, RLC204, PDCP206, and RRC208, and/or a layer containing some or all of PHY300, MAC302, RLC304, PDCP306, SDAP310, and RRC308.

In the embodiments of the present invention, the E-UTRA protocol and the NR protocol are not distinguished below, and the terms PHY (PHY layer), MAC (MAC layer), RLC (RLC layer), PDCP (PDCP layer), RRC (RRC layer), and NAS (NAS layer) may be used. In this case, PHY (PHY layer), MAC (MAC layer), RLC (RLC layer), PDCP (PDCP layer), RRC (RRC layer), and NAS (NAS layer) may be 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, respectively, 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. Furthermore, SDAP (SDAP layer) may be the SDAP (SDAP layer) of the NR protocol.

Furthermore, in embodiments of the present invention, when distinguishing between the E-UTRA protocol and the NR protocol, 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. Also, PHY200, MAC202, RLC204, PDCP206, and RRC208 may be described 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 the E-UTRA protocol and the NR protocol, PHY300, MAC302, RLC304, PDCP306, and RRC308 are sometimes referred to as NR PHY, NR MAC, NR RLC, NR RLC, and NR RRC, respectively. Also, PHY200, MAC302, RLC304, PDCP306, and RRC308 may be described 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. Entities possessing some or all of the functions of the MAC layer may be called MAC entities. Entities possessing some or all of the functions of the RLC layer may be called RLC entities. Entities possessing some or all of the functions of the PDCP layer may be called PDCP entities. Entities possessing some or all of the functions of the SDAP layer may be called SDAP entities. Entities possessing some or all of the functions of the RRC layer may be called RRC entities. MAC entities, RLC entities, PDCP entities, SDAP entities, and RRC entities may be replaced with MAC, RLC, PDCP, SDAP, and RRC, respectively.

Furthermore, the data provided from MAC, RLC, PDCP, and SDAP to lower layers, and/or the 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. Similarly, the data provided from higher layers to MAC, RLC, PDCP, and SDAP, and/or the 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. Additionally, a segmented RLC SDU may be referred to as an RLC SDU segment.

An example of PHY functionality is described below. The terminal device's PHY may have the function of receiving data transmitted from the base station device's PHY via the Downlink (DL) physical channel. The terminal device's PHY may also have the function of transmitting data to the base station device's PHY via the Uplink (UL) physical channel. The PHY may be connected to the higher-level MAC via a Transport Channel. The PHY may transfer data to the MAC via the Transport Channel. The PHY may also receive 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 discuss physical channels.

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

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.

Furthermore, in NR, PBCH may be used to announce the time index (SSB-Index) within the period of a block of synchronization signals (also called an SS/PBCH block).

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

PUCCH may be used to transmit Uplink Control Information (UCI) in uplink wireless communication (wireless communication from terminal equipment to base station equipment). Here, Uplink Control Information may include Channel State Information (CSI), which is used to indicate the state of the downlink channel. Furthermore, Uplink Control Information may include a Scheduling Request (SR), which is used to request UL-SCH (Uplink Shared Channel) resources. Furthermore, Uplink Control Information may include HARQ-ACK (Hybrid Automatic Repeat Request ACKnowledgement).

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

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

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

An example of MAC functionality is described below. MAC may be called a MAC sublayer. MAC may have the function of mapping various logical channels to corresponding transport channels. Logical channels may be identified by a Logical Channel Identity (Logical Channel ID). MAC may be connected to the higher-level RLC via logical channels. Logical channels may be divided into control channels that transmit control information and traffic channels that transmit user information, depending on the type of information being transmitted. Logical channels may also be divided into uplink logical channels and downlink logical channels. MAC may have the function of multiplexing MAC SDUs belonging to one or more different logical channels and providing them to the PHY. MAC may also have the function of demultiplexing MAC PDUs provided from the PHY and providing them to the higher layer via the logical channel to which each MAC SDU belongs. MAC may also have the function of performing error correction through HARQ (Hybrid Automatic Repeat reQuest). MAC may also have a scheduling report (SR) function that reports scheduling information. MAC may have a function to perform priority processing between terminal devices using dynamic scheduling. MAC may also have a function to perform priority processing between logical channels within a single terminal device. MAC may also have a function to perform priority processing for overlapping resources within a single terminal device. E-UTRA MAC may have a function to identify Multimedia Broadcast Multicast Services (MBMS). NR MAC may also have a function to identify Multicast Broadcast Service (MBS). MAC may have a function to select the transport format. MAC may have functions for performing discontinuous reception (DRX) and/or discontinuous transmission (DTX), executing random access (RA) procedures, a power headroom report (PHR) function that notifies information on available power for transmission, a buffer status report (BSR) function that notifies information on the amount of data in the transmit buffer, and so on. NR MAC may have a Bandwidth Adaptation (BA) function. Furthermore, the MAC PDU format used in E-UTRA MAC and the MAC PDU format used in NR MAC may be different. Additionally, MAC PDU may include MAC control elements (MAC CE), which are elements used for control within the MAC.

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

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

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

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

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

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

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

A Multicast Control Channel (MCCH) may be a point-to-multipoint downlink channel for sending MBMS control information for one or more MTCHs from a base station device to a terminal device. An MCCH may be a multicast logical channel. An 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 to a terminal device using SC-PTM. SC-MTCH may be a multicast logical channel. 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-MCCHs 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 between logical channels and transport channels for uplinks in E-UTRA and/or NR.

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

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

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

This section describes the mapping between logical channels and transport channels in downlinks in E-UTRA and/or NR.

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 Paging Channel (PCH), which is a downlink transport channel.

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

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

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

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

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

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

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

An example of RLC functionality is described below. RLC may be called an RLC sublayer. E-UTRA RLC may have the function of segmenting and/or concatenating data provided from the upper layer PDCP and providing it to the lower layer. E-UTRA RLC may have the function of reassembling and reordering data provided from the lower layer and providing it to the upper layer. NR RLC may have the function of adding a sequence number to the data provided from the upper layer PDCP that is independent of the sequence number added by the PDCP. NR RLC may also have the function of segmenting the data provided from the PDCP and providing it to the lower layer. NR RLC may also have the function of reassembling data provided from the lower layer and providing it to the upper layer. RLC may also have a data retransmission function and/or retransmission request function (Automatic Repeat reQuest: ARQ). RLC may also have a function to perform error correction using ARQ. The control information sent from the receiver to the transmitter of RLC to perform ARQ, indicating data that needs to be retransmitted, may be called a status report. The instruction to send a status report sent from the transmitter to the receiver of RLC may be called a poll. RLC may also have a function to detect data duplication. RLC may also have a data discard function. RLC may have three modes: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). In TM, data received from the upper layer is not split, and an RLC header is not required. The TM RLC entity is a unidirectional entity and may be set as a transmitting TM RLC entity or a receiving TM RLC entity. In UM, data received from the upper layer is split and/or combined, an RLC header is added, etc., but data retransmission control is not required. A UM RLC entity may be a unidirectional or bidirectional entity. If a UM RLC entity is a unidirectional entity, it may be configured as a transmitting UM RLC entity or a receiving UM RLC entity. If a 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. AM may perform operations such as splitting and/or combining data received from higher layers, adding RLC headers, and controlling data retransmission. An AM RLC entity is a bidirectional entity and may be configured as an AM RLC consisting of a transmitting side and a receiving side. Data provided to lower layers by TM, and/or data provided from lower layers, may be called TMD PDUs. Similarly, data provided to lower layers by UM, and/or data provided from lower layers, may be called UMD PDUs. Furthermore, data provided to lower layers by AM, or data provided from lower layers, may be called AMD PDUs. The RLC PDU format used in E-UTRA RLC and the RLC PDU format used in NR RLC may be different. Furthermore, there may be both data RLC PDUs and control RLC PDUs. The data RLC PDU may be called an RLC DATA PDU (RLC Data PDU). The control RLC PDU may be called an RLC CONTROL PDU (RLC Control PDU).

An example of PDCP functionality is described below. PDCP may be called the 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 the wireless section. The protocol used for compressing and decompressing IP packet headers may be called the ROHC (Robust Header Compression) protocol. The protocol used for compressing and decompressing Ethernet frame headers may be called the EHC (Ethernet® Header Compression) protocol. PDCP may also have data encryption/decryption functionality. PDCP may also have data integrity protection/verification functionality. 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 multiplexing function. Furthermore, PDCP may have a function to discard duplicate received data. A 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 and the PDCP PDU format used in NR PDCP may be different. In addition, there may be 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).

An example of SDAP functionality is described below. SDAP is a Service Data Adaptive Protocol Layer (SPD). SDAP may have the functionality to map downlink QoS flows sent from the 5GC110 to the terminal device via the base station equipment to the Data Radio Bearer (DRB), and/or to map uplink QoS flows sent from the terminal device to the 5GC110 via the base station equipment to the DRB. SDAP may also have the functionality to store mapping rule information. SDAP may also have the functionality to mark QoS flow identifiers (QoS Flow ID: QFI). Note that there may be data SDAP PDUs and control SDAP PDUs. Data SDAP PDUs may be called SDAP DATA PDUs (SDAP Data PDUs). Control SDAP PDUs may be called SDAP CONTROL PDUs (SDAP Control PDUs). Note that there may be one SDAP entity for each PDU session in the terminal device.

An example of RRC functionality is described below. RRC may have broadcast functionality. RRC may have paging functionality from EPC104 and/or 5GC110. RRC may have paging functionality from eNB102 connected to gNB108 or 5GC100. RRC may also have RRC connection management functionality. RRC may also have wireless bearer control functionality. RRC may also have cell group control functionality. RRC may also have mobility control functionality. RRC may also have terminal device measurement reporting and terminal device measurement reporting control functionality. RRC may also have QoS management functionality. RRC may also have wireless link failure detection and recovery functionality. The RRC may use RRC messages to perform functions such as broadcasting, paging, RRC connection management, wireless bearer control, cell group control, mobility control, terminal device measurement reporting and terminal device measurement reporting control, QoS management, and wireless link failure detection and recovery. Note that the RRC messages and parameters used in E-UTRA RRC may differ from those used in NR RRC.

RRC messages may be sent using logical channels BCCH, PCCH, CCCH, DCCH, or MCCH.

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

RRC messages sent in the uplink (UL) direction using CCCH may include, for example, RRC Setup Request, RRC Resume Request, RRC Reestablishment Request, and RRC System Info Request. They may also include, for example, RRC Connection Request, RRC Connection Resume Request, and RRC Connection Reestablishment Request. Other RRC messages may also be included.

RRC messages sent in the downlink (DL) direction using CCCH may include, for example, RRC Connection Reject messages, RRC Connection Setup messages, RRC Connection Reestablishment messages, and RRC Connection Reestablishment Reject messages. They may also include, for example, RRC Reject messages and RRC Setup messages. Other RRC messages may also be included.

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

RRC messages sent in the downlink (DL) direction using DCCH may include, for example, RRC Connection Reconfiguration messages, RRC Connection Release messages, Security Mode Command messages, and UE Capability Enquiry messages. They may also include, for example, RRC Reconfiguration messages, RRC Resume messages, RRC Release messages, RRC Reestablishment messages, Security Mode Command messages, and UE Capability Enquiry messages. Other RRC messages may also be included.

Let's describe some examples of NAS functionality. A NAS may have authentication capabilities. It may also have mobility management capabilities. Furthermore, a NAS may have security control capabilities.

The aforementioned PHY, MAC, RLC, PDCP, SDAP, RRC, and NAS functions are merely examples, and some or all of each function may not be implemented. Furthermore, some or all of the functions of each layer may be included in other layers.

Furthermore, the 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, UDP (User Datagram Protocol) layer, etc. The Ethernet layer may also exist above the AS layer of the terminal device. The layer above the AS layer of the terminal device may be called the PDU layer. The PDU layer may include the IP layer, TCP layer, UDP layer, Ethernet layer, etc. Above the IP layer, TCP layer, UDP layer, Ethernet layer, PDU layer, etc., there may be an application layer. The application layer may include SIP (Session Initiation Protocol) and SDP (Session Description Protocol), which are 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. Furthermore, the RRC layer may be a higher layer than the SDAP layer.

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

Furthermore, if UE122 is connected to EPC, it does not have the RRC_INACTIVE state, but E-UTRAN may initiate the suspension of the RRC connection. When UE122 is connected to EPC and the RRC connection is suspended, UE122 may transition to the RRC_IDLE state, retaining the UE's AS context and the identifier (resumeIdentity) used for resuming. The upper layer of the UE122's RRC layer (e.g., the NAS layer) may initiate the resumption of the suspended RRC connection if UE122 retains the UE's AS context, E-UTRAN has permitted the resumption of the RRC connection, and UE122 needs to transition from the RRC_IDLE state to the RRC_CONNECTED state.

The definition of hibernation may differ between UE122 connected to EPC104 and UE122 connected to 5GC110. Furthermore, the procedure for UE122 to resume from hibernation may differ in whole or in part depending on whether UE122 is connected to EPC (hibernating in RRC_IDLE state) or UE122 is connected to 5GC (hibernating in RRC_INACTIVE state).

Furthermore, the RRC_CONNECTED state, RRC_INACTIVE state, and RRC_IDLE state can be referred to as connected mode, inactive mode, and idle mode, respectively, or as RRC connected mode, RRC inactive mode, and RRC idle mode.

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

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

This section describes cell groups configured by base station equipment for terminal devices. A cell group may consist of one Special Cell (SpCell). Alternatively, a cell group may consist of one SpCell and one or more Secondary Cells (SCells). In other words, a cell group may consist of one SpCell and, optionally, one or more SCells. A cell group may also be described as a set of cells (set of cell(s)). When a MAC entity is associated with a Master Cell Group (MCG), SpCell may mean a Primary Cell (PCell). When a MAC entity is associated with a Secondary Cell Group (SCG), SpCell may mean a Primary SCG Cell (PSCell). When a MAC entity is not associated with a cell group, SpCell may mean a PCell. PCell, PSCell, and SCell are serving cells. SpCell may support PUCCH transmission and contention-based random access, and SpCell may always be active. 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. PCell may also be a cell used in the RRC connection re-establishment procedure when a terminal device re-establishes an RRC connection. PCell may also be a cell used in the random access procedure during handover. PSCell may be a cell used in the random access procedure when adding a secondary node (SN), as described later. SpCell may also be a cell used for purposes other than those described above. When a cell group consists of SpCell and one or more SCells, it can be said that carrier aggregation (CA) is set up in this cell group. Furthermore, a cell that provides additional radio resources to SpCell for a terminal device with CA set up can be considered an SCell.

A group of serving cells configured by RRC that uses the same timing reference cell and the same timing advance value for cells with uplinks configured within that group may be called a Timing Advance Group (TAG). Furthermore, a TAG containing a MAC entity SpCell may be considered a Primary Timing Advance Group (PTAG). TAGs other than PTAGs may be considered Secondary Timing Advance Groups (STAG).

Furthermore, when Dual Connectivity (DC) or Multi-Radio Dual Connectivity (MR-DC) is implemented, cell groups may be added to terminal devices from the base station equipment. DC is a technology that uses the radio resources of cell groups configured by a first base station equipment (first node) and a second base station equipment (second node) to perform data communication. MR-DC is a technology included in DC. In order to perform DC, the first base station equipment may add a second base station equipment. The first base station equipment may be called the Master Node (MN). The cell group configured by the master node may be called the Master Cell Group (MCG). The second base station equipment may be called the Secondary Node (SN). The cell group configured by the secondary node may be called the Secondary Cell Group (SCG). Note that the master node and secondary node may be configured within the same base station equipment.

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

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

Furthermore, in a terminal device, there may be one MAC entity for each cell group. For example, when a DC or MR-DC is configured in a 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 a terminal device may always be established in all states of the terminal device (RRC idle state, RRC connected state, and RRC inactive state, etc.). The MAC entity for the SCG in a terminal device may be created by the terminal device when the SCG is configured in the terminal device. In addition, the MAC entities for each cell group of the terminal device may be established when the terminal device receives an RRC message from the base station device. In EN-DC and 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. Also, in 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. Furthermore, in NR-DC, MAC entities for both MCG and SCG may be NR MAC entities. Note that the statement that there is one MAC entity for each cell group can be rephrased as "there is one MAC entity for each SpCell." Similarly, the statement that there is one MAC entity for each cell group can be rephrased as "one MAC entity for each SpCell."

The wireless bearer will be described below. For E-UTRA, SRB0 through SRB2 may be defined, or other SRBs may be defined. For NR, SRB0 through SRB3 may be defined, or other SRBs may be defined. SRB0 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 SRB2 is established. 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. The logical channel DCCH may be used for all RRC and NAS messages transmitted and/or received using SRB2. Furthermore, SRB2 may 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 on the terminal device. All RRC and NAS messages transmitted and/or received using SRB3 may use the logical channel DCCH. Other SRBs may be provided for other purposes. DRB may be a wireless bearer for user data. RRC messages transmitted and/or received using DRB may use the logical channel DTCH.

The wireless bearer in the terminal device is described below. The wireless bearer may include an RLC bearer. An RLC bearer may consist of one or two RLC entities and a logical channel. If there are two RLC entities in the RLC bearer, the RLC entities may be a TM RLC entity and/or a transmit RLC entity and a receive RLC entity in unidirectional UM mode. SRB0 may consist of one RLC bearer. The RLC bearer of SRB0 may consist of the RLC entity of TM and a logical channel. SRB0 may always be established in the terminal device in all states (RRC idle state, RRC connected state, and RRC inactive state, etc.). SRB1 may be established and/or set in the terminal device by an RRC message received from the base station device when the terminal device transitions from the RRC idle state to the 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 on a terminal device by an RRC message received from the base station device by a terminal device in an RRC connection 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. Note that the PDCP on the base station side of SRB1 and SRB2 may be located on the master node. SRB3 may be established and/or configured on a terminal device by an RRC message received from the base station device by a terminal device in an RRC connection state with AS security activated when a secondary node is added or when a secondary node is changed in an EN-DC, NGEN-DC, or NR-DC. 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 on the base station side of SRB3 may be located on a secondary node. One or more DRBs may be established and/or configured on a terminal device by an RRC message received from the base station device by a terminal device in an RRC connection state with AS security activated. The DRB may consist of one PDCP entity and one or more RLC bearers. The RLC bearer of the DRB may consist of an AM or UM RLC entity and a logical channel.

In MR-DC, a wireless bearer with a PDCP on the master node may be called an MN-terminated bearer. Similarly, a wireless bearer with a PDCP on the secondary node may be called an SN-terminated bearer. Furthermore, in MR-DC, a wireless bearer with an RLC bearer only on the MCG may be called an MCG bearer. Similarly, a wireless bearer with an RLC bearer only on the SCG may be called an SCG bearer. Finally, in a DC, a wireless bearer with an RLC bearer on both the MCG and SCG may be called a split bearer.

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

For RLC bearers established and/or configured in a cell group composed of E-UTRA, the established and/or configured RLC entities may be E-UTRA RLC. Similarly, for RLC bearers established and/or configured in a cell group composed of NR, the established and/or configured RLC entities may be NR RLC. When EN-DC is configured in a terminal device, the PDCP entities established and/or configured for MN-terminated MCG bearers may be either E-UTRA PDCP or NR PDCP. Furthermore, when EN-DC is configured in a terminal device, the PDCP established and/or configured for other bearer types of wireless bearers, namely MN-terminated split bearers, MN-terminated SCG bearers, SN-terminated MCG bearers, SN-terminated split bearers, and SN-terminated SCG bearers, may be NR PDCP. Additionally, when NGEN-DC, NE-DC, or NR-DC is configured in a terminal device, the PDCP entities established and/or configured for wireless bearers of all bearer types may be NR PDCP.

In NR, the DRB established and/or configured on the terminal device may be associated with one PDU session. One SDAP entity may be established and/or configured for one PDU session on the terminal device. The SDAP entities, PDCP entities, RLC entities, and logical channels established and/or configured on the terminal device may be established and/or configured by RRC messages received by the terminal device from the base station device.

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

Next, we will explain handover in LTE and NR. Handover may be the process by which UE122 in an RRC connection state changes the serving cell. Handover may occur when UE122 receives an RRC message instructing a handover from eNB102 and/or gNB108. An RRC message instructing a handover may be a message concerning the reconfiguration of the RRC connection that includes a parameter instructing a handover (for example, an information element named MobilityControlInfo or an information element named ReconfigurationWithSync). The information element named MobilityControlInfo may be rephrased as a mobility control setting information element, mobility control setting, or mobility control information. The information element named ReconfigurationWithSync may be rephrased as a synchronized reconfiguration information element, or synchronized reconfiguration. Furthermore, an RRC message instructing a handover may be a message indicating movement to another RAT's cell (for example, MobilityFromEUTRACommand or MobilityFromNRCommand). The term "handover" can also be rephrased as "reconfiguration with sync." Furthermore, the conditions under which UE122 can perform a handover may include some or all of the following: AS security is activated, SRB2 is established, and at least one DRB is established.

The flow of RRC messages transmitted and received between a terminal device and a base station device will be described. 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 is 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 Figure 4, the base station device creates an RRC message (step S400). The creation of an RRC message by the base station device may be performed in order for the base station device to distribute broadcast information (SI: System Information) or paging information. The creation of an RRC message by the base station device may also be performed in order for the base station device to perform processing on a specific terminal device. Processing to be performed on a specific terminal device may include, for example, security settings, RRC connection reconfiguration, handover to a different RAT, suspension of RRC connection, and release of RRC connection. RRC connection reconfiguration processing may include, for example, control of radio bearers (establish, change, release, etc.), control of cell groups (establish, add, change, release, etc.), measurement settings, handover, security key update, etc. The creation of an RRC message by the base station device may also be performed in response to an RRC message sent from a terminal device. Responses to RRC messages sent from a terminal device may include, for example, responses to RRC setup requests, responses to RRC reconnection requests, and responses to RRC restart requests. RRC messages contain various information notifications and configuration information (parameters). These parameters may be called fields and/or information elements and may be described using the ASN.1 (Abstract Syntax Notation One) notation scheme.

In Figure 4, the base station device then transmits the created RRC message to the terminal device (step S402). The terminal device then performs any necessary processing, such as configuration, according to the received RRC message (step S404). The terminal device that has performed the processing may then transmit a response RRC message to the base station device (not shown).

RRC messages may be used for purposes other than those mentioned above.

In MR-DC, the RRC on the master node side may be used to transfer RRC messages for SCG side settings (cell group settings, wireless bearer settings, measurement settings, etc.) to and from terminal devices. For example, in EN-DC or NGEN-DC, the RRC message for E-UTRA transmitted and received between eNB102 and UE122 may contain the RRC message for NR in container form. Similarly, in NE-DC, the RRC message for NR transmitted and received between gNB108 and UE122 may contain the RRC message for E-UTRA in container form. RRC messages for SCG side settings may be transmitted and received between the master node and secondary nodes.

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

This section describes an example of parameters included in an RRC message regarding the reconfiguration of an RRC connection. Figure 7 is an example of an ASN.1 description representing fields and/or information elements related to wireless bearer settings included in a message regarding the reconfiguration of an RRC connection in NR, as shown in Figure 4. Figure 8 is also an example of an ASN.1 description representing fields and/or information elements related to wireless bearer settings included in a message regarding the reconfiguration of an RRC connection in E-UTRA, as shown in Figure 4. In the examples of ASN.1 in the embodiments of the present invention, not limited to Figures 7 and 8, <omitted> and <omitted> indicate that other information has been omitted, not part of the ASN.1 notation. Information elements may also be omitted where there is no <omitted> or <omitted> notation. Note that the examples of ASN.1 in the embodiments of the present invention do not strictly follow the ASN.1 notation method. The examples of ASN.1 in the embodiments of the present invention are examples of parameters in an RRC message in the embodiments of the present invention, and other names or notations may be used. Furthermore, to avoid complicating the explanation, only examples of ASN.1 relating to key information closely related to one embodiment of the present invention are shown. Note that parameters described in ASN.1 are sometimes referred to as information elements without distinction between fields, information elements, etc. Also, in embodiments of the present invention, fields, information elements, etc. described in ASN.1 included in RRC messages may be referred to as information or parameters. Note that the message relating to the resetting of the RRC connection may be an RRC reset message in NR or an RRC connection reset message in E-UTRA.

This section describes cell activation and deactivation. In terminal devices communicating via dual connectivity, the Master Cell Group (MCG) and Secondary Cell Group (SCG) are configured by the message regarding the reconfiguration of the RRC connection described 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 called a PCell. The SpCell of the SCG is also called a PSCell. Cell deactivation does not apply to SpCells, but may apply to SCells.

Furthermore, cell deactivation may not apply to PCells but may apply to PSCells. In this case, the cell deactivation process may differ between SpCells and SCells.

Cell activation and deactivation may be handled by MAC entities present in each cell group. SCells configured on a terminal device may be activated and/or deactivated by some or all of (A) to (C) below.
(A) Reception of MAC CE indicating SCell activation/inactivation
(B) SCell deactivation timer set for each SCell that does not have PUCCH set.
(C) RRC parameters (sCellState) set for each SCell configured in the terminal device.

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

(Processing AD)
If the RRC parameter (sCellState) set for the SCell during SCell configuration is set to activated, or if a MAC CE to activate the SCell is received, the MAC entity of UE122 performs action (AD-1). Otherwise, if a MAC CE to deactivate the SCell is received, or if the SCell deactivation timer expires for an activated SCell, the MAC entity of UE122 performs action (AD-2). If an uplink grant or downlink assignment is notified by the PDCCH of an activated SCell, or if an uplink grant or downlink assignment for an activated SCell is notified by the PDCCH of a serving cell, or if a MAC PDU is sent for a configured uplink grant, or if a MAC PDU is received for a configured downlink assignment, the MAC entity of UE122 restarts the SCell deactivation timer associated with that SCell. If the SCell becomes deactivated, the MAC entity of UE122 performs action (AD-3).

(Process AD-1)
If, in NR, this SCell was inactive before receiving the MAC CE that activates it, or if the RRC parameter (sCellState) set for this SCell during SCell configuration is set to activated, then the MAC entity of UE122 performs either process (AD-1A) or process (AD-1B).
Additionally, the MAC entity in UE122 starts the SCell inactivity timer associated with that SCell, or restarts it (if it has already started).
If the Active DL BWP is not a Dormant BWP (described below), the MAC entity of UE122 will perform some or all of the following (A) and (B).
(A) Reinitialize all suspended configured uplink grants of grant type 1 associated with this SCell according to any stored configuration.
(B) Trigger PHR.
If a MAC CE is received to activate a SCell, and the BWP indicated by the first Active Downlink BWP-Id set in the RRC message for that SCell is not set to a Dormant BWP, the MAC entity of UE122 performs processing (AD-1A). If a MAC CE is received to activate a SCell, and the BWP indicated by the first Active Downlink BWP-Id set in the RRC message for that SCell is set to a Dormant BWP, the MAC entity of UE122 performs processing (AD-1B). In addition, the MAC entity of UE122 performs some or all of the following (A) to (B).
(A) Activate the BWP indicated by the first active downlink BWP identifier (firstActiveDownlinkBWP-Id) set in the RRC message.
(B) Activate the BWP indicated by the first active uplink BWP identifier (firstActiveUplinkBWP-Id) set in the RRC message.

(Process AD-1A)
The MAC entity of UE122 activates SCell and applies (performs) normal SCell operations, including some or all of the following (A) through (E).
(A) Transmission of sounding reference signal (SRS) in this SCell
(B) Reporting of channel status information (CSI) for this SCell
(C) Monitoring of PDCCH in this SCell
(D) Monitoring of PDCCH for this SCell (if scheduling is performed for this SCell in other serving cells)
(E) If PUCCH is set, PUCCH transmission in this SCell

(Process AD-1B)
The MAC entity in UE122 stops the BWP inactivity timer for this serving cell if it is running.

(Process AD-2)
The MAC entity in UE122 performs some or all of the following (A) through (F).
(A) Inactivate this SCell.
(B) Stop the SCell deactivation timer associated with this SCell.
(C) Inactivate all activated BWP associated with this SCell.
(D) Clear all configured downlink assignments and/or all configured uplink grants of grant type 2 associated with this SCell.
(E) Suspend all configured uplink grants of Grant Type 1 associated with this SCell.
(F) Flushes the HARQ buffer associated with this SCell.

(Process AD-3)
The MAC entity in UE122 performs some or all of the following (A) through (D).
(A) Do not send SRS with this SCell.
(B) Do not report a CSI for this SCell.
(C) Do not send PUCCH, UL-SCH, and/or RACH with 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.

Furthermore, as mentioned above, when an SCell is added, its initial state may be set by an RRC message.

Here, we will explain the SCell deactivation timer. For SCells for which PUCCH is not set, the value of the SCell deactivation timer (information about the time at which the timer is considered to have expired) may be notified via an RRC message. For example, if the RRC message notifies that the value of the SCell deactivation timer is 40ms, then in the above process (AD), the timer will be considered to have expired when the notified time (40ms in this case) has elapsed without the timer stopping after it has been started or restarted. The SCell deactivation timer may also be named a timer called sCellDeactivationTimer.

Here, we will explain the parameter (timeAlignmentTimer) set in RRC to maintain time alignment on the uplink (UL).

A timeAlignmentTimer may be set for each TAG. Additionally, a timeAlignmentTimer may control the period over which MAC entities consider serving cells belonging to the associated TAG to be synchronized with the UL time. The timeAlignmentTimer is also referred to as TAT.

When the timeAlignmentTimer associated with the PTAG expires, the MAC entity performs some or all of the following actions (A) through (E).
(Processing PT)
(A) Flushes the HARQ buffers for all serving cells belonging to the PTAG.
(B) Notify the RRC to release PUCCH for all serving cells belonging to the PTAG, if any.
(C) Notify RRC to release SRS for all serving cells belonging to PTAG, if any.
(D) Clear all configured downlink assignments and/or all configured uplink grants.
(E) Assume that all running timeAlignmentTimers have expired.

When the timeAlignmentTimer associated with the STAG expires, the MAC entity performs some or all of the following actions (A) through (D) for all serving cells belonging to this TAG.
(A) Flushes the HARQ buffer.
(B) Notify RRC of the release of PUCCH if any exist.
(C) Notify RRC of the release of SRS if any exist.
(D) Clear all configured downlink assignments and/or all configured uplink grants.

Now, let's explain the bandwidth portion (BWP).

A BWP may be part or all of the bandwidth of a serving cell. A BWP may also be called a Carrier BWP. One or more BWPs may be configured on a terminal device. A BWP may be configured by information contained in broadcast information associated with a synchronization signal detected during the initial cell search. Another BWP may be a frequency bandwidth associated with the frequency at which the initial cell search is performed. A BWP may also be configured by RRC signaling (e.g., Dedicated RRC signaling). Furthermore, downlink BWPs (DL BWPs) and uplink BWPs (UL BWPs) may be configured separately. One or more uplink BWPs may also be associated with one or more downlink BWPs. Furthermore, the mapping between the uplink BWP and the downlink BWP may be a default mapping, a mapping by RRC signaling (e.g., Dedicated RRC signaling), a mapping by physical layer signaling (e.g., downlink control information (DCI) notified via the downlink control channel), or a combination of these.

A BWP may consist of a group of consecutive Physical Resource Blocks (PRBs). Furthermore, parameters for each component carrier's BWP (one or more BWPs) may be set for a connected terminal device. The BWP parameters for each component carrier may include some or all of the following: (A) the type of cyclic prefix, (B) the subcarrier spacing, (C) the frequency position of the BWP (e.g., the starting position or central frequency position on the lower frequency side of the BWP) (the frequency position may be, for example, an ARFCN or an offset from a specific subcarrier of the serving cell. The unit of the offset may be in subcarrier units or resource block units. Both ARFCN and offset may be set.), (D) the bandwidth of the BWP (e.g., the number of PRBs), (E) resource configuration information for the control signals, and (F) the center frequency position of the SS block (the frequency position may be, for example, an ARFCN or an offset from a specific subcarrier of the serving cell. The unit of the offset may be in subcarrier units or resource block units. Both ARFCN and offset may be set.). Additionally, resource configuration information for the control signals may be included in the BWP settings for at least some or all of the PCell and/or PSCell.

A terminal device may transmit and receive data using one or more configured BWPs, specifically the active BWP (Active BWP). For a single serving cell associated with a terminal device, one or more BWPs may be configured so that, at any given time, a maximum of one uplink BWP and/or one downlink BWP are active. 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 set in a single serving cell. BWP switching in a serving cell is used to activate an inactive BWP (also called an inactive BWP) and deactivate an activated BWP.

BWP switching is controlled by the MAC entity itself for the PDCCH indicating downlink allocation or uplink grant, BWP inactivity timer, RRC signaling, or initiation of a random access procedure. The active BWP of a serving cell is indicated by the RRC or PDCCH.

Next, we will explain dormant BWPs. Entering or leaving a dormant BWP is done by switching BWPs. This control is performed by PDCCH for each SCell or for groups called Dormancy SCell Groups. The setting of dormancy SCell Groups is indicated by RRC signaling. Also, in the current specification, dormant BWPs apply only to SCells. Note that a dormant BWP is not something that changes a BWP into a dormant state, but rather it can be interpreted as one BWP set for dormancy among one or more BWPs set for the UE. Also, there may be multiple BWPs set for dormancy on the UE.

A BWP may be indicated as a dormant BWP by the absence of certain parameters in its configuration. For example, a BWP may be indicated as a dormant BWP by the absence of the PDCCH-Config information element, which is an information element for setting UE-specific PDCCH parameters included in the configuration of a downlink BWP. Alternatively, a BWP may be indicated as a dormant BWP by the absence of some of the parameters included in the PDCCH-Config information element, which is an information element for setting UE-specific PDCCH parameters included in the configuration of a downlink BWP. For example, a BWP may be indicated as a dormant BWP by the absence of some or all of the settings for the search space, which are set by the PDCCH-Config information element and define where and/or how to search for PDCCH candidates.

Furthermore, in certain settings, the setting of a dormant BWP for SpCells such as PCell and PSCell, and PUCCH SCells capable of transmitting PUCCH signals, may be disabled.

When a UE receives a PDCCH via SpCell indicating that it is exiting a dormant BWP outside of a set period (active time), it activates the downlink BWP indicated by the first downlink BWP identifier previously notified via RRC signaling.

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

Upon receiving a PDCCH indicating entry into a dormant BWP, the UE activates the downlink BWP indicated by the third downlink BWP identifier (dormantDownlinkBWP-Id) previously notified via RRC signaling.

The above-mentioned entry into and exit from dormant BWPs (Blockwork Programs) is performed by switching BWPs. 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 PDCCH, which indicates entering a dormant BWP, and PDCCH, which indicates exiting a dormant BWP.

For example, a UE configured for intermittent reception (DRX) in a SpCell may monitor the PDCCH with 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 may decide to switch the Active DL BWP based on the bitmap information contained in the DCI format 2_6 payload. For example, if a bit in the bitmap is associated with a dormant SCell group, and the bit is 1, the UE may switch to another pre-configured BWP if the Active DL BWP is a dormant BWP, or remain in that BWP if the Active DL BWP is not a dormant BWP. Alternatively, if the bit is 0, the UE may switch the BWP so that the Active DL BWP becomes a dormant BWP.

During the DRX's active time, the UE does not need to monitor the PDCCH for the purpose of detecting DCI format 2_6.

A UE configured for intermittent reception (DRX) in SpCell may monitor the PDCCH with the SpCell's Active BWP during the DRX active time to detect a certain DCI format (e.g., DCI formats 0_1 and 1_1). 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 dormant SCell groups determines the switching of the Active DL BWP based on the bitmap information contained in the DCI format 0_1 or DCI format 1_1 payload. For example, if a bit in the bitmap is associated with a dormant SCell group, and the bit is 1, the UE may switch to another pre-configured BWP if the Active DL BWP is a dormant BWP, or remain in that BWP if the Active DL BWP is not a dormant BWP. Alternatively, if the bit is 0, the UE may switch the BWP so that the Active DL BWP becomes a dormant BWP. Furthermore, the aforementioned "another pre-configured BWP" may be a different BWP from the "another pre-configured BWP" used in the explanation 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's active time.

Monitoring the PDCCH to indicate the exit of dormant BWP may involve monitoring the PDCCH outside of the DRX's active time for the purpose of detecting DCI format 2_6, and monitoring the PDCCH during the DRX's active time for the purpose of detecting DCI format 0_1 and DCI format 1_1.

In each activated serving cell where a BWP is set, the MAC entity shall, if the BWP is activated (an Active BWP) and is not a dormant BWP, perform some or all of (A) through (H) below.
(A) Send UL-SCH with that BWP.
(B) If a PRACH occasion is configured, send a RACH in that BWP.
(C) Monitor the PDCCH with that BWP.
(D) If PUCCH is configured, send PUCCH using that BWP.
(E) Report the CSI using that BWP.
(F) If SRS is configured, send SRS using that BWP.
(G) Receive DL-SCH with that BWP.
(H) Initialize the configured uplink grant of Grant Type 1 that was configured and suspended in that BWP.

In each activated serving cell where a BWP is set, the MAC entity performs some or all of (A) through (G) below if the BWP is activated (active BWP) and is dormant BWP.
(A) If the BWP inactivity timer for this BWP serving cell is running, stop it.
(B) Do not monitor the PDCCH of that BWP.
(C) Do not monitor PDCCH for that BWP.
(D) DL-SCH will not be received in that BWP.
(F) Do not send SRS with that BWP.
(G) Do not send UL-SCH with that BWP.
(H) Do not send RACH with that BWP.
(I) Do not send a PUCCH with 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 if beam failure is detected, perform beam failure recovery.

If the BWP is deactivated, the MAC entity will perform some or all of the following actions (A) through (I).
(A) Do not send UL-SCH with that BWP.
(B) Do not send RACH with that BWP.
(C) Do not monitor PDCCH with that BWP.
(D) Do not send a PUCCH with that BWP.
(E) Do not report CSI in that BWP.
(F) Do not send SRS with that BWP.
(G) Do not receive DL-SCH with that BWP.
(H) Clear the Grant Type 2 Configured Ascending Link Grant set in that BWP.
(I) Suspend the configured uplink grant of the inactive BWP (Inactive BWP) Grant Type 1.

Next, we will describe the random access procedure in a UE with BWP configured. When a random access procedure is initiated in a serving cell, the MAC entity performs some or all of the following processes (A) through (E) in the selected carrier of that serving cell.
(A) If the resource (occasion) sending PRACH is not configured for the Active UL BWP, (A1) the Active UL BWP is switched to the BWP indicated by the RRC parameter (initialUplinkBWP), and (A2) if the serving cell is a SpCell, the Active UL BWP is switched to the BWP indicated by the RRC parameter initialDownlinkBWP.
(B) If the resource (occasion) that sends PRACH is configured for the Active UL BWP, and the serving cell is a SpCell, and the Active DL BWP and Active UL BWP do not have the same identifier (bwp-Id), then the Active DL BWP is switched to a BWP with the same identifier as the Active UL BWP.
(C) If the BWP inactivity timer associated with this serving cell's Active DL BWP is running, stop this timer.
(D) If the serving cell is SCell, and if the BWP inactivity timer associated with the SpCell's Active DL BWP is running, stop this timer.
(E) Execute a random access procedure on the Active DL BWP of SpCell and the Active UL BWP of this serving cell.

Next, we will explain the BWP inactivity timer. For each activated serving cell on which a BWP inactivity timer is set, the MAC entity performs the following (A) action. The BWP inactivity timer may also be named a timer called bwp-InactivityTimer.
(A) If a default downlink BWP identifier (defaultDownlinkBWP-Id) is set and the Active DL BWP is not the BWP indicated by the identifier (dormantDownlinkBWP-Id), or if a default downlink BWP identifier (defaultDownlinkBWP-Id) is not set, the Active DL BWP is not initialDownlinkBWP, and the Active DL BWP is not the BWP indicated by the identifier (dormantDownlinkBWP-Id), then the MAC entity performs the following (B) and (D).
(B) If an Active DL BWP receives a PDCCH addressed to C-RNTI or CS-RNTI indicating a downlink assignment or uplink grant, or if an Active DL BWP receives a PDCCH addressed to C-RNTI or CS-RNTI indicating a downlink assignment or uplink grant, or if a MAC PDU is sent in a configured uplink grant, or if a MAC PDU is received in a configured downlink assignment, the MAC entity performs the following (C):
(C) If no random access procedure associated with this serving cell is currently running, or if a running random access procedure associated with this serving cell is successfully completed by receiving a PDCCH addressed to C-RNTI, start or restart the BWP inactivity timer associated with the Active DL BWP.
(D) If the BWP inactivity timer associated with the Active DL BWP expires, the MAC entity performs the following action (E):
(E) If a defaultDownlinkBWP-Id is set, the BWP will be switched to the BWP indicated by this defaultDownlinkBWP-Id; otherwise, the BWP will be switched to initialDownlinkBWP.

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

Next, we will describe the procedures for detecting and recovering beam failures.

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

If the MAC entity has triggered at least one beam failure recovery (BFR) by the beam failure recovery procedure and it has not been canceled, it performs the following action (A):
(A) If the UL-SCH resource can include the SCell's BFR MAC CE and its subheaders, taking into account the logical channel priority, then include the SCell's BFR MAC CE and its subheaders. Otherwise, if the UL-SCH resource can include the SCell's truncated BFR MAC CE and its subheaders, taking into account the logical channel priority, then include the SCell's truncated BFR MAC CE and its subheaders. Otherwise, trigger a scheduling request for SCell beam failure recovery.

SCell dormancy is achieved by activating the dormant BWP within the SCell. Furthermore, even when an SCell is dormant, CSI measurement, automatic gain control (AGC), and beam management, including beam failure recovery, may be performed within the SCell.

Next, we will explain SCG deactivation.

Deactivation of the SCG may mean that a MAC entity is associated with the SCG and that the cell group corresponding to the MAC entity is deactivated. Activation of the SCG may mean that a MAC entity is associated with the SCG and that the cell group corresponding to the MAC entity is activated.

In LTE and/or NR, the state in which the SCG is deactivated (the state in which the SCG is dormant) may be a state in which the terminal device performs some or all of the following (A) to (K) in its SCG's SpCell (PSCell).
(SD-1)
(A) Do not send SRS with this SpCell.
(B) Measure the CSI for this SpCell.
(C) Do not report CSI for this SpCell.
(D) Do not send PUCCH, UL-SCH, and/or RACH with this SpCell.
(E) Do not monitor the PDCCH of this SpCell, and/or the PDCCH for this SpCell.
(F) This SpCell performs intermittent reception (DRX).
(G) Do not monitor the PDCCH of this SpCell, and/or the PDCCH for this SpCell, addressed to C-RNTI, MCS-C-RNTI, and/or CS-RNTI, which indicate the uplink grant for UL-SCH transmission on this SpCell.
(H) The BWP is activated on this SpCell, and the PDCCH of this SpCell, and/or the PDCCH for this SpCell, addressed to C-RNTI, MCS-C-RNTI, and/or CS-RNTI, which indicate the uplink grant in the aforementioned BWP, are not monitored.
(I) Automatic Gain Control (AGC), beam management including beam failure recovery, and/or radio link monitoring (RLM) will not be performed in this SpCell.
(J) Suspend some or all of the configured uplink grants of Grant Type 1 associated with this SpCell.
(K) Do not stop the timeAlignmentTimer (TAT) associated with the TAG (PTAG) containing this SpCell.

In LTE and/or NR, the state in which the SCG is activated (the state in which the SCG is not dormant) is a state in which the terminal device performs some or all of the following (A) to (K) in its SCG's SpCell (PSCell).
(SA-1)
(A) Send SRS using this SpCell.
(B) Measure the CSI for this SpCell.
(C) Report CSI for this SpCell.
(D) Send PUCCH, UL-SCH, and/or RACH with this SpCell.
(E) Monitor the PDCCH of this SpCell and/or the PDCCH for this SpCell.
(F) This SpCell performs intermittent reception (DRX).
(G) Monitor the PDCCH of this SpCell and/or the PDCCH for this SpCell, addressed to C-RNTI, MCS-C-RNTI, and/or CS-RNTI, which indicate the uplink grant for UL-SCH transmission on this SpCell.
(H) The BWP is activated in this SpCell and the PDCCH of this SpCell, and/or the PDCCH for this SpCell, are monitored, addressed to C-RNTI, MCS-C-RNTI, and/or CS-RNTI, which indicate the uplink grant in the aforementioned BWP.
(I) This SpCell performs automatic gain control (AGC), beam management including beam failure recovery, and/or radio link monitoring (RLM).
(J) Initialize some or all suspended Configured Uplink Grants of Grant Type 1 associated with this SpCell.
(K) Start the timeAlignmentTimer (TAT) associated with the TAG (PTAG) containing this SpCell (again).

In LTE and/or NR, a terminal device may determine that an SCG is inactive based on some or all of (A) through (K) below. Note that the messages and control elements described in (A) through (F) below may also be notified to the terminal device from cell groups other than the SCG in question.
(SD-2)
(A) Receipt of an RRC message instructing the deactivation of the SCG.
(B) Reception of MAC control element instructing SCG deactivation
(C) Receipt of an RRC message instructing the deactivation of SpCell
(D) Reception of MAC control element instructing SpCell deactivation
(E) Receiving other RRC messages
(F) Reception of other MAC control elements
(G) Expiration of the deactivation timer for SCG
(H) Expiration of the PSCell's inactivity timer
(i) Initiation of a random access procedure resulting from a scheduling request triggered to send a MAC PDU containing a MAC SDU.
(J) Starting the random access procedure
(K) Initiation of a random access procedure resulting from a scheduling request (in other words, initiated by the MAC entity itself)

Figure 11 shows an example of an embodiment. In Figure 11, the processing unit 502 of UE122 determines that the SCG is in an inactive state based on (SD-2) above (step S1100). Furthermore, the processing unit 502 of UE122 performs the operation in the inactive state based on the above determination (step S1102).

In LTE and/or NR, a terminal device may determine that an SCG is not inactive based on some or all of (A) through (K) below. Note that the messages and control elements described in (A) through (F) below may also be notified to the terminal device from cell groups other than the SCG in question. An SCG being inactive may also mean that the SCG is active.
(SA-2)
(A) Receipt of an RRC message instructing the activation of the SCG.
(B) Reception of MAC control element that instructs activation of SCG
(C) Receipt of an RRC message instructing SpCell to be activated.
(D) Receipt of MAC control element instructing SpCell activation
(E) Receiving other RRC messages
(F) Reception of other MAC control elements
(G)SCG inert timer
(H)PSCell Inactive Timer
(i) Initiation of a random access procedure resulting from a scheduling request triggered to send a MAC PDU containing a MAC SDU.
(J) Starting the random access procedure
(K) Initiation of a random access procedure resulting from a scheduling request (in other words, initiated by the MAC entity itself)

Figure 10 shows an example of an embodiment. In Figure 10, the processing unit 502 of UE122 determines that the SCG is not in an inactive state based on (SA-2) above (step S1000). Furthermore, based on the above determination, the processing unit 502 of UE122 performs the operation as in the active state (step S1002).

A terminal device that performs SCG deactivation may perform some or all of the following processes (A) to (F) in the SCG.
(SD-3)
(A) Set all SCells to an inactive state.
(B) Assume that all SCell deactivation timers associated with active SCells have expired.
(C) All SCell inactivity timers associated with dormant SCells are considered to have expired.
(D) Do not start or restart the SCell inactive timer associated with any SCell.
(E) Ignore MAC CEs that activate SCell. For example, in process (AD), if a MAC CE that activates SCell is received and SCG deactivation is not instructed (or SCG is not in an inactive state), process (AD-1) is performed.
(F) The above process (AD-2) is performed. For example, if the process (AD) is instructed to deactivate the SCG (or the SCG becomes inactive), the process (AD-2) is performed.

A terminal device that performs SCG activation may perform the following processes (A) and/or (B) in the SCG.
(SA-3)
(A) Perform procedure (AD-1) to activate all SCells.
(B) When SCG activation is performed based on an RRC message, if the RRC message includes parameters related to random access to a SpCell (PSCell), a random access procedure is initiated in that SpCell based on the notified parameters.

Figure 9 shows an example of an embodiment. In Figure 9, UE122 receives a message (RRC message) from eNB102 or gNB108 notifying it to put the SCG into an inactive state (sleep state) (step S900). Based on the above notification, UE122 controls the cells of the SCG other than the SpCell (second cell) (i.e., SCell) to enter an inactive state (step S902).

The above operation enables efficient state changes in the process of deactivating the SCG without the UE122's transmitter 504 having to independently transmit a MAC CE to change the SCell state of the SCG to an inactive state. Furthermore, when SCG deactivation is performed based on an RRC message, conventionally, the initial state was set at the RRC layer and the state change was performed at the MAC layer. However, the above operation allows for efficient state changes of the SCG while avoiding mismatches between instructions at the RRC layer and the MAC layer.

When an SCG is inactive, all uplink transmissions may be stopped at the SCG. In this case, information about the SCG may be transmitted in other cell groups (e.g., MCGs). Alternatively, information about the SCG may be transmitted at the activated SCG. Furthermore, when an SCG is inactive, some or all uplink transmissions may be permitted at the SCG. Here, we will describe an example of performing uplink transmissions at an SCG when the SCG is inactive.

For example, we will describe beam failure recovery when beam control (beam management), including beam failure recovery, is performed in an inactive SCG SpCell.

The MAC entity may have a beam failure recovery procedure set up by the RRC for each serving cell. In an inactive SCG, the beam failure recovery procedure may be set up and/or performed only in SpCells, or in an inactive SCG, the beam failure recovery procedure may be set up and/or performed in SpCells and some or all of the SCells. Beam failures are detected by counting beam failure instance notifications sent from the lower layers (PHY layers) to the MAC entity. The MAC entity may perform some or all of the following processes (A), (B), and (C) in each serving cell for beam failure detection.
(A) If a beam failure instance notification is received from a lower layer, start or restart the timer (beamFailureDetectionTimer) and increment the counter (BFI-COUNTER) by 1. If the value of BFI_COUNTER is greater than or equal to the set 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 on the SpCell. Note that if beam recovery is not triggered on the SCell, it is not necessary to trigger beam failure recovery for the SCell here. In other words, the process of starting a random access procedure on the SpCell may only be performed if the serving cell is an SpCell.
(B) If the beamFailureDetectionTimer for this serving cell expires, or if the settings for beamFailureDetectionTimer, beamFailureInstanceMaxCount, and/or the reference signal for beam failure detection are changed by a higher layer, set BFI_COUNTER to 0.
(C) If the serving cell is a SpCell and the random access procedure is successfully completed, set BFI_COUNTER to 0, stop the timer (beamFailureRecoveryTimer), and consider the beam failure recovery procedure to have been successfully completed. Otherwise, if the serving cell is an SCell and receives a PDCCH addressed to C-RNTI indicating a new uplink grant to transmit information for beam failure recovery of the SCell (e.g., information contained in the SCell BFR MAC CE), or if the SCell is inactive, set BFI_COUNTER to 0, consider the beam failure recovery procedure to have been successfully completed, and cancel all beam failure recoveries (BFRs) triggered for this serving cell.

The MAC entity, if at least one beam failure recovery (BFR) has been triggered by the beam failure recovery procedure and has not been canceled, will trigger a scheduling request for SCell beam failure recovery as needed.

When a scheduling request is triggered, the MAC entity of the SCG initiates a random access procedure in the SpCell if no valid PUCCH resources are configured for the pending scheduling request.

As mentioned above, a random access procedure in a SpCell (PSCell) may be initiated in an inactive SCG by a scheduling request from a MAC entity to send a MAC PDU containing a MAC CE, or directly by a MAC entity. In this case, the MAC PDU may not contain a MAC SDU.

On the other hand, a random access procedure in a SpCell (PSCell) may be initiated in an inactive SCG by a scheduling request to send a MAC PDU containing data from higher layers, such as user data and RRC messages (MAC SDU).

This section describes the Power Headroom Report (PHR). The PHR procedure is used to provide some or all of the following information (A) through (C) to the serving gNB.
(A) Difference between the nominal UE's maximum transmit power and the estimated UL-SCH transmit power per activated serving cell.
(B) The difference between the maximum transmit power of the nominal UE and the estimated transmit power of UL-SCH and/or PUCCH on the SpCell of other MAC entities.
(C) Difference between the maximum transmit power of the nominal UE and the estimated transmit power of the SRS per activated serving cell.

The information described in (A), (B), and (C) above may be referred to as Type 1 power headroom, Type 2 power headroom, and Type 3 power headroom, respectively. Furthermore, information including some or all of (A) through (C) above may be referred to simply as power headroom.

A MAC CE containing only one set of information regarding the power headroom type, the target cell, and the maximum transmit power in that cell may be referred to as a Single Entry PHR MAC CE. A MAC CE containing multiple sets of information regarding the power headroom type, the target cell, and the maximum transmit power in that cell may be referred to as a Multiple Entry PHR MAC CE.

For any MAC entity, a MAC entity in the UE may trigger a PHR if an uplink is configured for that MAC entity, and a SCell is activated that is not set to a dormant BWP, and the BWP indicated by the first active downlink BWP identifier (firstActiveDownlinkBWP-Id) configured in the RRC message is not set to a dormant BWP. Furthermore, a MAC entity in the UE may trigger a PHR if a PSCell is newly added or modified.

For any MAC entity, if an activated BWP of a SCell with an uplink configured in that MAC entity is changed from a dormant (DL) BWP to a non-dormant DL BWP, the MAC entity in the UE may trigger a PHR. The above BWP change may also be represented as a BWP switch.

If a MAC entity has an uplink resource allocated for a new transmission, the MAC entity in the UE may perform some or all of the following actions (A) and (B).
(A) If this uplink resource is the first one since the MAC was last reset, start the timer (phr-PeriodicTimer).
(B) If the procedure for a PHR stipulates that the UE's MAC entity will trigger at least one PHR and that this trigger will not be canceled, and if the MAC CE for the PHR set to be sent by the UE's MAC entity can be contained within the allocated uplink resources in addition to the subheader of this MAC CE, taking into account the logical channel priority, then some or all of the following processes (B-1) through (B-5) shall be performed.
(B-1) If the MAC CE being received is a Multiple Entry PHR MAC CE, perform some or all of the following processes (C-1) through (C-3).
(C-1) For each activated serving cell with an uplink configured and associated with any MAC entity in the same UE, where the activated DL BWP is not a dormant (DL) BWP, obtain the Type 1 or Type 3 power headroom value for the uplink carrier associated with the NR serving cell and E-UTRA serving cell. If the MAC entity associating the serving cell has uplink resources allocated for transmission on this serving cell, or if another MAC entity in the same UE is configured and has uplink resources allocated for transmission on this serving cell, and the higher layer has determined to calculate the maximum transmit power based on the power used for actual transmission on this serving cell, obtain this maximum transmit power value from the physical layer.
(C-2) If the UE is allowed to report the type 2 power headroom for the SpCell of another MAC entity of the same UE, obtain the value of that type 2 power headroom if that MAC entity is an E-UTRA MAC entity, and if it is determined at a higher layer that the maximum transmit power is calculated based on the power used for actual transmission in the SpCell of that MAC entity, obtain this maximum transmit power value from the physical layer.
(C-3) After considering the priority of the logical channel, a Multiple Entry PHR MAC CE is generated and sent based on the values reported from the physical layer.
(B-2) If the MAC CE to be received is a Single Entry PHR MAC CE, the Type 1 power headroom value for the uplink carrier associated with the PCell and the associated maximum transmit power value are obtained from the physical layer, and a Single Entry PHR MAC CE is generated and transmitted based on these values, taking into account the priority of the logical channel.
(B-3) Start or restart the timer (phr-PeriodicTimer).
(B-4) Start or restart the timer (phr-ProhibitTimer).
(B-5) Cancel all triggered PHRs.

Based on the above description, various embodiments of the present invention will now be described. Note that any processes omitted in the following description may be replaced by the processes described above.

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 a complicated explanation, Figure 5 shows only the main components closely related to one embodiment of the present invention.

The UE122 shown in Figure 5 consists of a receiving unit 500 that receives RRC messages etc. from the base station equipment, a processing unit 502 that processes according to the parameters contained in the received message, and a transmitting unit 504 that transmits RRC messages etc. to the base station equipment. The base station equipment mentioned above may be an eNB102 or a gNB108. Furthermore, the processing unit 502 may include some or all of the functions of various layers (for example, the physical layer, MAC layer, RLC layer, PDCP layer, SDAP layer, RRC layer, and NAS layer). That is, the processing unit 502 may include some or all of the physical layer processing unit, MAC layer processing unit, RLC layer processing unit, PDCP layer processing unit, SDAP layer processing unit, RRC layer processing unit, and NAS layer processing unit.

Figure 6 is a block diagram showing the configuration of a base station device in an embodiment of the present invention. To avoid a complicated explanation, Figure 6 shows only the main components closely related to one embodiment of the present invention. The base station device described above may be either an eNB102 or a gNB108.

The base station device shown in Figure 6 consists of a transmitting unit 600 that sends RRC messages, etc., to the UE122, a processing unit 602 that creates an RRC message including parameters and sends it to the UE122, causing the processing unit 502 of the UE122 to perform processing, and a receiving unit 604 that receives RRC messages, etc., from the UE122. Furthermore, the processing unit 602 may include some or all of the functions of various layers (for example, the physical layer, MAC layer, RLC layer, PDCP layer, SDAP layer, RRC layer, and NAS layer). That is, the processing unit 602 may include some or all of the physical layer processing unit, MAC layer processing unit, RLC layer processing unit, PDCP layer processing unit, SDAP layer processing unit, RRC layer processing unit, and NAS layer processing unit.

An example of the processing of a terminal device in an embodiment of the present invention will be explained using Figure 10. The processing of the terminal device in the embodiment of the present invention, as explained using Figure 10, is expected to have effects such as eliminating the need for the terminal device to monitor multiple cell groups and reducing power consumption.

Figure 10 shows an example of processing of a terminal device in an embodiment of the present invention. The processing unit 502 of UE122 may determine that the SCG is not in an inactive state based on (SA-2) above (step S1000). Alternatively, the processing unit 502 of UE122 may perform operations in an active state based on the above determination (step S1002).

An example of UE122 operation in the active state is described below. In the active state, UE122 may perform some or all of the processes shown in (SA-1) above in each of the SpCells and/or one or more SCells in a given cell group.

The active state may be a state in which the SCG is activated. The active state described above may also be a state in which the SCG has resumed from a dormant state. Furthermore, the active state described above may be a state in which the SCG is not dormant. The active state described above may also be a state to which the SCG transitions from an inactive state when a random access procedure is initiated due to a scheduling request triggered to send a MAC PDU containing a MAC SDU. Furthermore, the active state described above may also be a state to which the SCG transitions from an inactive state when the RRC entity instructs the SCG to resume from a dormant state.

In step S1000, the processing unit 502 of UE122 may determine the transition when the SCG has completed its transition from the inactive state to the active state. Alternatively, the processing unit 502 of UE122 may determine the transition while the SCG is transitioning from the inactive state to the active state.

UE122 may transition the SCG from an inactive state to an active state (in other words, activate the SCG) upon receiving information to activate the SCG. UE122 may also transition the SCG from an inactive state to an active state upon receiving information instructing the SCG to resume from a dormant state. Furthermore, UE122 may transition the SCG from an inactive state to an active state upon receiving information instructing the SpCell to resume from a dormant state. UE122 may also transition the SCG from an inactive state to an active state upon receiving other information. Additionally, UE122 may transition the SCG from an inactive state to an active state based on a timer related to SCG dormancy. Furthermore, UE122 may transition the SCG from an inactive state to an active state based on a timer related to PSCell dormancy. Finally, UE122 may 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 containing a MAC SDU. Furthermore, UE122 may transition the SCG from an inactive state to an active state when initiating a random access procedure. Also, UE122 may transition the SCG from an inactive state to an active state when initiating a random access procedure resulting from a scheduling request (in other words, initiated by the MAC entity itself). The MAC entity of UE122 may also obtain instructions to activate the SCG, instructions to wake the SCG from a dormant state, instructions to wake the SpCell from a dormant state, and/or other information from the RRC entity of UE122. After the MAC entity obtains the aforementioned information from the RRC entity, UE122 may determine that the SCG is not inactive, as shown in (SA-2) above, and transition the SCG from an inactive state to an active state. When transitioning the SCG from an inactive state to an active state, UE122 may perform the processing shown in (SA-3) above.

An example of the processing of a terminal device in an embodiment of the present invention will be explained using Figure 11.

Figure 11 shows an example of the processing of a terminal device in an embodiment of the present invention. The processing unit 502 of UE122 may determine that the SCG is in an inactive state based on (SD-2) above (step S1100). Alternatively, the processing unit 502 of UE122 may perform operations in the inactive state based on the above determination (step S1102).

An example of the operation of UE122 in the inactive state described above is explained below. In the inactive state, UE122 may perform some or all of the processing shown in (SD-1) above in a SpCell of a cell group and/or one or more SCells.

The inactive state may be a state in which the SCG is deactivated. The inactive state described above may also be an entry into a dormant SCG. Furthermore, the inactive state described above may be a dormant state of the SCG. The inactive state may also be a state in which the Active BWP of the SCG's SpCell and/or one or more SCells are dormant BWPs. Furthermore, the inactive state described above may be a state to which the SCG transitions from the active state when a random access procedure is initiated due to a scheduling request triggered to send a MAC PDU containing a MAC SDU. Furthermore, the inactive state described above may be a state to which the SCG transitions from the active state when an RRC entity instructs entry into a dormant state.

In step S1100, the processing unit 502 of UE122 may determine the transition when the SCG has completed its transition from the active state to the inactive state. Alternatively, the processing unit 502 of UE122 may determine the transition while the SCG is transitioning from the active state to the inactive state.

UE122 may transition the SCG from the active state to the inactive state when it receives information instructing it to deactivate the SCG. UE122 may also transition the SCG from the active state to the inactive state when it receives information instructing it to enter a dormant SCG. Furthermore, UE122 may transition the SCG from the active state to the inactive state when it receives information instructing it to enter dormancy. UE122 may also transition the SCG from the active state to the inactive state when it receives other information. Additionally, UE122 may transition the SCG from the active state to the inactive state when the timer for SCG dormancy expires. Furthermore, UE122 may transition the SCG from the active state to the inactive state when the timer for PSCell dormancy expires. The MAC entity of UE122 may also obtain instructions to deactivate the SCG, instructions to enter a dormant SCG, instructions for SpCell dormancy, and/or other information from the RRC entity of UE122. Furthermore, after the MAC entity obtains the aforementioned information from the RRC entity, UE122 may determine that the SCG is in an inactive state, as shown in (SD-2) above, and transition the SCG from an active state to an inactive state. When transitioning the SCG from an active state to an inactive state, UE122 may perform the processing shown in (SD-3) above.

An example of the processing of a terminal device in an embodiment of the present invention will be explained using Figure 12.

Figure 12 shows an example of processing of a terminal device in an embodiment of the present invention. The processing unit 502 of UE122 may clear the configured uplink grant of grant type 1 when a condition that includes some or all of the following (A) to (B) occurs (step S1200) (step S1202). The processing unit 602 of eNB102 and/or gNB108 may cause UE122 to clear the configured uplink grant of grant type 1 when a condition that includes some or all of the following (A) to (B) occurs. The condition that includes some or all of (A) to (B) may also include conditions other than (A) and (B).
(A) The TAT associated with the PTAG expires.
(B) SCG is not in an inactive state.

An example of processing a configured uplink grant of grant type 1 in step S1202 is described below. If the TAT associated with the PTAG in UE122 expires in step S1200 and the SCG is not inactive, the MCG in UE122 and/or the MAC entity for the SCG may clear the configured uplink grant of grant type 1.

An example of the processing of a terminal device in an embodiment of the present invention will be explained using Figure 13.

Figure 13 shows an example of the processing of a terminal device in an embodiment of the present invention. The processing unit 502 of UE122 does not need to clear the configured uplink grant of grant type 1 when a condition including some or all of (A) to (B) below occurs (step S1300) (step S1302). The processing unit 602 of eNB102 and/or gNB108 may consider that UE122 has not cleared the configured uplink grant of grant type 1 when a condition including some or all of (A) to (B) below occurs. The condition including some or all of (A) to (B) may include conditions other than (A) and (B).
(A) The TAT associated with the PTAG expires.
(B) SCG is in an inactive state.

An example of processing of a configured uplink grant of grant type 1 in step S1302 is described below. If the TAT associated with the PTAG in UE122 expires in step S1300 and the SCG is inactive, the MCG in UE122 and/or the MAC entity for the SCG do not need to clear the configured uplink grant of grant type 1. For example, the MAC entity may keep some or all of the suspended configured uplink grants of grant type 1 in a suspended state. Alternatively, the MAC entity may perform the above processing (PT) on a grant other than the configured uplink grant of grant type 1.

An example of the processing of a terminal device in an embodiment of the present invention will be explained using Figure 14.

Figure 14 shows an example of the processing of a terminal device in an embodiment of the present invention. The processing unit 502 of UE122 determines whether the SCG is inactive when the TAT associated with the PTAG expires (step S1400). If it is not inactive, it may clear the grant type 1 configured uplink grant; if it is inactive, it may not clear it (step S1402). The transmitting unit 600 of eNB102 and/or gNB108 may transmit information (for example, information instructing the SCG to be inactive) to UE122 that is used to determine whether or not to clear the grant type 1 configured uplink grant when the TAT associated with the PTAG expires. Furthermore, the processing unit 602 of eNB102 and/or gNB108 may assume that UE122 does not clear the grant type 1 configured uplink grant when the SCG is inactive and the TAT associated with the PTAG expires.

An example of the process in step S1400 is described below. In step S1400, if the TAT has expired, UE122 may determine whether the SCG is inactive or not, as shown in (SD-2) and/or (SA-2) above.

An example of processing of a configured uplink grant of grant type 1 in step S1402 is described below. If it is determined in step S1400 that the SCG is not inactive, the MCG in UE122 and/or the MAC entity for the SCG may clear the configured uplink grant of grant type 1. Alternatively, if it is determined in step S1400 that the SCG is inactive, the MCG in UE122 and/or the MAC entity for the SCG do not need to clear the configured uplink grant of grant type 1, and may perform the above processing (PT) on grants other than the configured uplink grant of grant type 1. For example, the MAC entity may keep some or all of the suspended configured uplink grants of grant type 1 in a suspended state. Furthermore, before it is determined in step S1400 that the SCG is inactive, the MCG in UE122 and/or the MAC entity for the SCG may suspend the configured uplink grant of grant type 1.

Thus, in this embodiment of the present invention, it is possible to trigger the transmission of necessary uplink signals even when the SCG is in a dormant state. Furthermore, power saving is possible by monitoring only the necessary signals when the SCG is in a dormant state.

In the above description, each wireless bearer may be a DRB, an SRB, or both a DRB and an SRB.

Furthermore, in the above explanation, expressions such as "link," "correspond," and "associate" can be used interchangeably.

Furthermore, in the above explanation, "the aforementioned..." may be replaced with "the aforementioned...".

Furthermore, in the above explanation, "SCG's SpCell" may be replaced with "PSCell".

In the above explanation, "dormant state" may be replaced with "inactive state," and "state after recovery from dormancy" may be replaced with "active state." Furthermore, in the above explanation, "activation" and "inactivation" may be replaced with "active state" and "inactive state," respectively.

In the above explanation, "transition from X to Y" can be rephrased as "become X to Y." Also, "cause a transition" can be rephrased as "decide on a transition." Furthermore, "activated BWP" can be rephrased as "Active BWP."

Furthermore, in the examples of processes or process flows described above, some or all of the steps do not need to be executed. Also, in the examples of processes or process flows described above, the order of the steps may differ. Also, in the examples of processes or process flows described above, some or all of the processes within each step do not need to be executed. Also, in the examples of processes or process flows described above, the order of the processes within each step may differ. Furthermore, in the above description, "perform B based on the fact that A is true" can be rephrased as "perform B." That is, "performing B" may be performed independently of "being true A."

Furthermore, in the above explanation, "A may be replaced with B" may include not only replacing A with B, but also replacing B with A. Also, in the above explanation, if it states "C may be D" and "C may be E," it may also include "D may be E." Also, in the above explanation, if it states "F may be G" and "G may be H," it may also include "F may be H."

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

The following describes various embodiments of the terminal device and method according to the present invention.

(1) A first embodiment of the present invention is a terminal device having a first cell group and a second cell group, wherein the second cell group has a first cell, the first cell belongs to a first timing advance group, the first timing advance group has a first timer, and the terminal device includes a processing unit for clearing a grant type 1 configured uplink grant, wherein when the first timer expires, the processing unit clears the grant type 1 configured uplink grant based on the second cell group not being inactive, and does not clear the grant type 1 configured uplink grant based on the second cell group being inactive.

(2) A second embodiment of the present invention is a communication method applied to a terminal device having a first cell group and a second cell group configured, wherein the second cell group has a first cell configured, the first cell belongs to a first timing advance group, the first timing advance group has a first timer configured, the configured uplink grant of grant type 1 is cleared, and when the first timer expires, the configured uplink grant of grant type 1 is cleared based on the fact that the second cell group is not in an inactive state, and the configured uplink grant of grant type 1 is not cleared based on the fact that the second cell group is in an inactive state.

(3) A third embodiment of the present invention is a base station device that communicates with a terminal device, wherein the terminal device is configured with a first cell group and a second cell group, the second cell group is configured with a first cell, the first cell belongs to a first timing advance group, the first timing advance group is configured with a first timer, and the base station device includes a processing unit that clears a configured uplink grant of grant type 1, wherein when the first timer expires, the processing unit clears the configured uplink grant of grant type 1 based on the fact that the second cell group is not inactive, and does not clear the configured uplink grant of grant type 1 based on the fact that the second cell group is inactive.

(4) A fourth embodiment of the present invention is a communication method applied to a base station device that communicates with a terminal device, wherein the terminal device is configured with a first cell group and a second cell group, the second cell group is configured with a first cell, the first cell belongs to a first timing advance group, the first timing advance group is configured with a first timer, the configured uplink grant of grant type 1 is cleared, the configured uplink grant of grant type 1 is cleared when the first timer expires based on the fact that the second cell group is not inactive, and the configured uplink grant of grant type 1 is not cleared based on the fact that the second cell group is inactive.

A program operating in a device according to one aspect of the present invention may be a program that controls a Central Processing Unit (CPU) or the like to make the computer function in order to realize the functions of the above-described embodiment according 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 read, modified, and written by the CPU as needed.

Furthermore, a part of the apparatus in the above-described embodiment may be implemented using a computer. In that 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 read and executed by the computer system. The term "computer system" here refers to a computer system built into the apparatus, and includes hardware such as the operating system and peripheral devices. The "computer-readable recording medium" may be any of the following: semiconductor recording medium, optical recording medium, magnetic recording medium, etc.

Furthermore, "computer-readable recording media" may include those that dynamically hold programs for a short period of time, such as communication lines used when transmitting programs via networks such as the Internet or communication lines such as telephone lines, as well as those that hold programs for a certain period of time, such as volatile memory within a computer system acting as a server or client in such cases. Moreover, the program described above may be intended to implement only a part of the aforementioned functions, and may also be a program that can implement the aforementioned functions in combination with a program already recorded in the computer system.

Furthermore, each functional block or feature of the apparatus used in the embodiments described above may be implemented or executed by an electrical circuit, typically an integrated circuit or a combination of integrated circuits. Electrical circuits designed to perform the functions described herein may include general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gates or transistor logic, discrete hardware components, or combinations thereof. The general-purpose processor may be a microprocessor, or alternatively, a conventional processor, controller, microcontroller, or state machine. The general-purpose processor, or each of the aforementioned circuits, may consist of digital or analog circuits. Also, if advances in semiconductor technology lead to the emergence of integrated circuit technologies that replace current integrated circuits, integrated circuits using such technologies may be used.

Furthermore, the present invention is not limited to the embodiments described above. Although the embodiments describe an example of a device, the present invention is not limited thereto and can be applied to stationary or non-movable electronic devices installed indoors or outdoors, such as terminal devices or communication devices for AV equipment, kitchen equipment, cleaning and washing machines, air conditioning equipment, office equipment, vending machines, and other household appliances.

The embodiments of this invention have been described in detail above with reference to the drawings, but the specific configuration is not limited to these embodiments, and design changes and the like that do not depart from the gist of this invention are also included. Furthermore, one aspect of the present invention can be modified in various ways 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. In addition, configurations in which elements described in the above embodiments that produce similar effects are substituted for each other 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
106 NR
108 gNB
110 5GC
112, 114, 116, 118, 120, 124 Interfaces
122 UE
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 unit
504, 600 Transmitter

Claims (3)

A terminal device in which a master cell group (MCG) and a secondary cell group (SCG) are configured,
The aforementioned SCG is configured with a primary secondary cell (PSCell) .
The aforementioned PSCell belongs to the Primary Timing Advance Group (PTAG) ,
The aforementioned PTAG is configured with a time alignment timer (TAT) .
Equipped with a processing unit that clears the configured upward link grant of Grant Type 1,
When the aforementioned TAT expires,
The processing unit clears the configured uplink grant of grant type 1 based on the fact that the SCG is not in an inactive state.
A terminal device that does not clear the configured uplink grant of grant type 1 based on the fact that the SCG is in an inactive state. A communication method applicable to terminal equipment configured with a master cell group (MCG) and a secondary cell group (SCG) ,
The aforementioned SCG is configured with a primary secondary cell (PSCell) .
The previous PSCell belonged to the Primary Timing Advance Group (PTAG) ,
The aforementioned PTAG is configured with a time alignment timer (TAT) .
Clear the Grant Type 1 Configured Ascending Link Grant,
When the aforementioned TAT expires,
Based on the fact that the SCG is not in an inactive state, the configured upward link grant of the grant type 1 is cleared.
A communication method that does not clear the configured uplink grant of grant type 1 based on the fact that the SCG is in an inactive state. A base station device that communicates with terminal devices,
The terminal device is configured with a master cell group (MCG) and a secondary cell group (SCG) .
The aforementioned SCG is configured with a primary secondary cell (PSCell) .
The aforementioned PSCell belongs to the Primary Timing Advance Group (PTAG) ,
The aforementioned PTAG is configured with a time alignment timer (TAT) .
It is equipped with a processing unit that clears the configured upward link Grant of Grant Type 1.
When the aforementioned TAT expires,
The processing unit clears the configured upward link grant of the grant type 1 based on the fact that the SCG is not in an inactive state.
A base station device that prevents the configured uplink grant of grant type 1 from being cleared based on the fact that the SCG is in an inactive state.