JP7772709B2 - Terminal device and method - Google Patents

Description

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

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

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

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

3GPP TS 38.300v 16.2.0,"NR;NR and NG-RAN Overall description; Stage 2" pp10-134 3GPP TS 36.300 v16.2.0,"Evolved Universal Terrestrial Radio Access (E-UTRA)and Evolved Universal Terrestrial Radio Access Network (E-UTRAN);Overall description; Stage 2" pp19-361

As part of the E-UTRA extension technology studies, MBMS (Multimedia Broadcast Multicast Service) transmission technology is being standardized to provide multicast/broadcast services. MBMS transmission uses MBSFN (Multicast Broadcast Single Frequency Network) or SC-PTM (Single Cell Point-To-Multipoint) transmission.

Transmission using MBSFN transmits multicast/broadcast data using the PMCH (Physical Multicast Channel) in an MBSFN (Multicast-Broadcast Single-Frequency Network) area consisting of multiple cells. In contrast, transmission using SC-PTM transmits multicast data in a cell-by-cell manner using the PDSCH (Physical Downlink Shared Channel).

Meanwhile, Multicast Broadcast Service (MBS) is being considered as an extension technology of NR. When implementing MBS via NR, it is necessary to take into account NR-specific technologies that differ from E-UTRA, as well as core networks standardized for 5G. However, detailed operations for efficiently controlling MBS using NR have not yet been considered.

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

In order to achieve the above object, one aspect of the present invention provides the following means. That is, one aspect of the present invention provides a terminal device that communicates with a base station device, the terminal device establishes a radio bearer, the RLC entity of the radio bearer is an RLC entity in unacknowledged mode, the RLC entity of the radio bearer is linked to a PDCP entity of the radio bearer, and the PDCP entity creates a PDCP status report based on a PDCP data recovery request from a higher layer and submits the PDCP status report to the RLC entity.

Another aspect of the present invention is a method for a terminal device communicating with a base station device, in which the terminal device establishes a radio bearer, the RLC entity of the radio bearer is an RLC entity in unacknowledged mode, the RLC entity of the radio bearer is linked to a PDCP entity of the radio bearer, and the PDCP entity creates a PDCP status report based on a PDCP data recovery request from an upper layer, and submits the PDCP status report to the RLC entity.

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

According to one aspect of the present invention, a terminal device, a base station device, and a method can realize efficient MBS control using NR.

1 is a schematic diagram of a communication system according to an embodiment of the present invention. FIG. 1 is a diagram illustrating an example of an E-UTRA protocol configuration according to an embodiment of the present invention. FIG. 1 is a diagram of an example of an NR protocol configuration according to an embodiment of the present invention. FIG. 2 is a diagram showing an example of a flow of procedures for various settings in an RRC according to an embodiment of the present invention. FIG. 2 is a block diagram showing the configuration of a terminal device according to an embodiment of the present invention. FIG. 1 is a block diagram showing a configuration of a base station device according to an embodiment of the present invention. An example of an ASN.1 description included in a message regarding re-establishment of an RRC connection in NR in an embodiment of the present invention. 10 is an example of an ASN.1 description included in a message regarding re-establishment of an RRC connection in E-UTRA according to an embodiment of the present invention. FIG. 10 is a diagram showing a procedure flow for setting up MBMS reception using SC-PTM. FIG. 10 is a diagram showing an example of an ASN.1 description representing fields and/or information elements included in SIB20 (System Information Block Type 20). A figure showing an example of an ASN.1 description representing fields and/or information elements included in an SC-PTM configuration message (SCPTMConfiguration). FIG. 1 is a diagram showing an example of a flow of an MBS reception procedure in NR according to an embodiment of the present invention.

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

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

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

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

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

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

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

NR106 may be a radio access technology. NR106 may also be an air interface between UE122 and gNB108. The air interface between UE122 and gNB108 may be referred to as the Uu interface. gNB (g Node B)108 may be a base station device of NR106. gNB108 may have the NR protocol described below. The NR protocol may consist of the NR User Plane (UP) protocol described below 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 for UE122.

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

In addition, one or more gNB108 may be connected to 5GC110 via interface 116. An interface may exist between multiple gNB108 connected to 5GC110 (not shown). The interface between multiple gNB108 connected to 5GC110 may be called an Xn interface.

eNB102 may have the ability to connect to 5GC110. An eNB102 with the ability to connect to 5GC110 may be referred to as an ng-eNB. Interface 114 is an interface between eNB102 and 5GC110 and may be referred to as an 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 terminate in the Access and Mobility Management Function (AMF: not shown) in 5GC110. The user plane interface of interface 114 may terminate in the User Plane Function (UPF: not shown) in 5GC110. The control plane interface of interface 114 may be referred to as an NG-C interface. The user plane interface of interface 114 may be referred to as an NG-U interface. A radio access network consisting of an ng-eNB or a gNB may be referred to as an NG-RAN. NG-RAN, E-UTRAN, eNB, ng-eNB, gNB, etc. may simply be referred to as a network.

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

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

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

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

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

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

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

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

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

Figure 2 is a diagram of an example of 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. Note that the functions of each protocol described using Figure 2 and/or Figure 3 are only some of the functions closely related to the embodiment of the present invention, and other functions may also be included. Note that in the embodiment of the present invention, the uplink (UL) may be a link from the terminal device to the base station device. Also, in each embodiment of the present invention, the downlink (DL) may be a link from the base station device to the terminal device.

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

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

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

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

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

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

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

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

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

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

Now let's explain the physical channels.

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

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

PBCH can be used to broadcast system information required by terminal devices.

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

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

The PUCCH may be used to transmit uplink control information (UCI) in uplink wireless communication (wireless communication from a terminal device to a base station device). Here, the uplink control information may include channel state information (CSI) used to indicate the state of the downlink channel. The uplink control information may also include a scheduling request (SR) used to request UL-SCH (Uplink Shared CHannel) resources. The uplink control information may also include a hybrid automatic repeat request ACKnowledgement (HARQ-ACK).

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

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

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

An example of 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 (or logical channel ID). MAC may be connected to the higher-level RLC via logical channels. Depending on the type of information being transmitted, logical channels may be divided into control channels that transmit control information and traffic channels that transmit user information. Logical channels may also be divided into uplink logical channels and downlink logical channels. 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 by 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). The MAC may also have a scheduling report (SR) function that reports scheduling information. The MAC may also have a function that performs prioritized processing between terminal devices using dynamic scheduling. The MAC may also have a function that performs prioritized processing between logical channels within one terminal device. The MAC may also have a function that performs prioritized processing of overlapping resources within one terminal device. The E-UTRA MAC may have a function that identifies Multimedia Broadcast Multicast Services (MBMS). The NR MAC may also have a function that identifies Multicast/Broadcast Services (MBS). The MAC may have a function that selects a transport format. The MAC may have a function that performs discontinuous reception (DRX) and/or discontinuous transmission (DTX), a function that executes random access (RA) procedures, a power headroom report (PHR) function that notifies information about the available transmission power, a buffer status report (BSR) function that notifies information about the amount of data in the transmission buffer, etc. The NR MAC may have a bandwidth adaptation (BA) function. The MAC PDU format used in the E-UTRA MAC may differ from the MAC PDU format used in the NR MAC. The MAC PDU may also include a MAC control element (MAC CE), which is an element for controlling the MAC.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

An example of the RLC function is described below. RLC may be called an RLC sublayer. E-UTRA RLC may have the function of segmenting and/or concatenating data provided by PDCP in the upper layer and providing it to the lower layer. E-UTRA RLC may have the function of reassembling and reordering data provided by the lower layer and providing it to the upper layer. NR RLC may have the function of adding a sequence number independent of the sequence number added by PDCP to data provided by PDCP in the upper layer. NR RLC may also have the function of segmenting data provided by PDCP and providing it to the lower layer. NR RLC may also have the function of reassembling data provided by the lower layer and providing it to the upper layer. RLC may also have the function of data retransmission and/or retransmission request (Automatic Repeat reQuest: ARQ). RLC may also have a function for performing error correction using ARQ. The control information sent from the receiving side of RLC to the transmitting side to indicate data that needs to be retransmitted in order to perform ARQ may be called a status report. The instruction to send a status report sent from the transmitting side of RLC to the receiving side may be called a poll. RLC may also have a function for detecting 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 segmented, and an RLC header does not need to be added. The TM RLC entity is a unidirectional entity and may be configured as a transmitting TM RLC entity or a receiving TM RLC entity. In UM, data received from the upper layer is segmented and/or combined, an RLC header is added, etc., but data retransmission control is not required. The UM RLC entity may be a unidirectional entity or a bidirectional entity. If the UM RLC entity is a unidirectional entity, it may be configured as a transmitting UM RLC entity or a receiving UMRLC entity. If the UM RLC entity is a bidirectional entity, it may be configured as a UM RLC entity consisting of a transmitting side and a receiving side. In AM, it may perform functions such as segmenting and/or combining data received from a higher layer, adding an RLC header, and controlling data retransmission. The AM RLC entity is a bidirectional entity and may be configured as an AM RLC consisting of a transmitting side and a receiving side. Note that data provided to a lower layer and/or data provided from a lower layer in TM may be referred to as a TMD PDU. Also, data provided to a lower layer and/or data provided from a lower layer in UM may be referred to as a UMD PDU. Also, data provided to a lower layer or data provided from a lower layer in AM may be referred to as an AMD PDU. The RLC PDU format used in E-UTRA RLC and the RLC PDU format used in NR RLC may be different. RLC PDUs may include data RLC PDUs and control RLC PDUs. Data RLC PDUs may be called RLC DATA PDUs (RLC Data PDUs). Control RLC PDUs may be called RLC CONTROL PDUs (RLC Control PDUs).

An example of PDCP functionality is described below. PDCP may be called a PDCP sublayer. PDCP may have a function for maintaining sequence numbers. PDCP may also have a header compression/decompression function for efficiently transmitting user data such as IP packets and Ethernet frames over wireless interfaces. The protocol used for IP packet header compression/decompression may be called the ROHC (Robust Header Compression) protocol. The protocol used for Ethernet frame header compression/decompression may be called the EHC (Ethernet (registered trademark) Header Compression) protocol. PDCP may also have a data encryption/decryption function. PDCP may also have data integrity protection/verification functions. PDCP may also have a re-ordering function. PDCP may also have a PDCP SDU retransmission function. PDCP may also have a data discard function using a discard timer. PDCP may also have a duplication function. PDCP may also have a function to discard duplicated received data. The PDCP entity is a bidirectional entity and may consist of a transmitting PDCP entity and a receiving PDCP entity. The PDCP PDU format used in E-UTRA PDCP may differ from the PDCP PDU format used in NR PDCP. PDCP PDUs may include data PDCP PDUs and control PDCP PDUs. The data PDCP PDU may be called the PDCP DATA PDU (PDCP Data PDU). The control PDCP PDU may be called the PDCP CONTROL PDU (PDCP Control PDU).

In PDCP, the COUNT value may be used when performing encryption or integrity protection processing. The COUNT value may be composed of the PDCP state variable HFN (Hyper Frame Number) and the sequence number (SN: Sequence Number) added to the header of a PDCP PDU. The sequence number may be incremented by one each time a PDCP DATA PDU is generated in the transmitting PDCP entity. The HFN may be incremented by one each time the sequence number reaches its maximum value in the transmitting PDCP entity and the receiving PDCP entity. In addition, some or all of the following state variables (A) to (F) may be used to manage the COUNT value in the transmitting PDCP entity and the receiving PDCP entity.
(A) A state variable indicating the COUNT value of the next PDCP SDU to be transmitted. This may be a state variable named TX_NEXT.
(B) A state variable indicating the sequence number of the next PDCP SDU to be transmitted in this PDCP entity. This may be a state variable named Next_PDCP_TX_SN.
(C) A state variable representing the HFN value used to generate the COUNT value of the PDCP PDU in this PDCP entity. This may be a state variable named TX_HFN.
(D) A state variable indicating the COUNT value of the PDCP SDU that is expected to be received next in the receiving PDCP entity. This may be a state variable named RX_NEXT.
(E) A state variable indicating the sequence number of the next PDCP SDU that is expected to be received in the receiving PDCP entity. This may be a state variable named Next_PDCP_RX_SN.
(F) A state variable representing the HFN value used to generate the COUNT value for a received PDCP PDU in this PDCP entity. This may be a state variable named RX_HFN.

Furthermore, in PDCP, reordering may refer to a process of storing PDCP SDUs in a receive buffer (reordering buffer) and delivering the PDCP SDUs to a higher layer in the order of the COUNT values obtained from the header information of the PDCP DATA PDUs. In reordering, if the COUNT value of a received PDCP DATA PDU is the COUNT value of the first PDCP SDU that has not yet been delivered to a higher layer, the stored PDCP SDUs may be delivered to the higher layer in the order of the COUNT values. In other words, in reordering, if a PDCP data PDU with a COUNT value smaller than the COUNT value of the received PDCP data PDU has not been received (a PDCP data PDU has been lost), the received PDCP data PDU may be converted into a PDCP SDU and stored in the reordering buffer, and all lost PDCP data PDUs may be received, converted into PDCP SDUs, and then delivered to a higher layer. In reordering, a reordering timer (a timer named t-Reordering) may be used to detect loss of PDCP data PDUs, and some or all of the following state variables (A) to (F) may be used for reordering.
(A) A state variable indicating the COUNT value of the PDCP SDU that is expected to be received next in the receiving PDCP entity. This may be a state variable named RX_NEXT.
(B) A state variable indicating the sequence number of the next PDCP SDU that is expected to be received in the receiving PDCP entity. This may be a state variable named Next_PDCP_RX_SN.
(C) A state variable representing the HFN value used to generate the COUNT value for a received PDCP PDU in this PDCP entity. This may be a state variable named RX_HFN.
(D) A state variable indicating the COUNT value of the first PDCP PDU among the PDCP SDUs waiting to be received and not yet delivered to the upper layer in the receiving PDCP entity. This state variable may be named RX_DELIV.
(E) A state variable indicating the sequence number of the PDCP PDU of the PDCP SDU last delivered to the upper layer in the receiving PDCP entity. This may be a state variable named Last_Submitted_PDCP_RX_SN.
(F) In the receiving PDCP entity, a state variable indicating the COUNT value next to the COUNT value of the PDCP PDU that started the reordering timer. This may be a state variable named RX_REORD or a state variable named Reordering_PDCP_RX_COUNT.

This section explains status reporting in PDCP. In a DRB (AM DRB: Acknowledged Mode Data Radio Bearer) using RLC in acknowledged mode, for which transmission of PDCP status reports is configured by higher layers, the receiving PDCP entity may trigger a PDCP status report when any of the following conditions (A) to (D) is met. Also, in a DRB (UM DRB: Unacknowledged Mode Data Radio Bearer) using RLC in unacknowledged mode, for which transmission of PDCP status reports is configured by higher layers, the receiving PDCP entity may trigger a PDCP status report when the following condition (C) is met.
(A) The upper layer requests the re-establishment of the PDCP entity.
(B) The upper layer requests PDCP data recovery.
(C) The upper layer requests an uplink data switch.
(D) The upper layer reconfigures this PDCP entity to release DAPS (Dual Active Protocol Stack), and a parameter named daps source release is set.

When the transmission of a PDCP status report is initiated, the receiving PDCP entity may create a PDCP status report by storing information about the PDCP SDUs waiting to be received, including the COUNT value of the first PDCP PDU among the PDCP SDUs waiting to be received that have not yet been delivered to the upper layer, in the PDCP control PDU for the PDCP status report. The receiving PDCP entity that created the PDCP status report may submit the created PDCP status report to the lower layer via the transmitting PDCP entity.

In an embodiment of the present invention, a PDCP entity of a UM DRB configured by a higher layer to transmit a PDCP status report may determine that a higher layer has requested PDCP data recovery. A PDCP entity of a UM DRB that has determined that a higher layer has requested PDCP data recovery may create a PDCP status report in the receiving PDCP entity based on the request for PDCP data recovery from the higher layer, and submit the created PDCP status report to a lower layer via the transmitting PDCP entity. The lower layer may be a UM RLC entity of an RLC bearer associated with the PDCP entity. In an embodiment of the present invention, a PDCP entity of a UM DRB configured by a higher layer to transmit a PDCP status report may determine that a higher layer has requested PDCP data recovery only if the UM DRB is not a DAPS bearer. A DAPS bearer may be a bearer in which one or more RLC entities for the source cell and one or more RLC entities for the target cell are associated with the PDCP entity. The above-mentioned PDCP data recovery may also be called by another name, which means that an upper layer requests the PDCP to send a status report.

ROHC will now be described. In an embodiment of the present invention, ROHC may be referred to as the ROHC protocol. ROHC may have the function of compressing and decompressing header information such as IP, UDP, TCP, and RTP. In ROHC, a compressor may have a header compression function that compresses header information. Also, in ROHC, a decompressor may have a header decompression function that decompresses header information. A compressor may perform header compression using a context held by the compressor. A decompressor may perform header decompression using a context held by the decompressor. In an embodiment of the present invention, a context may be referred to as a ROHC context. The context in the decompressor may be generated by receiving all header information from the compressor. The context in the compressor and decompressor may be held for each IP flow. A context identifier (CID) may be used to identify the context. Information on the maximum value of the context identifier, profile information indicating the header compression/decompression method, etc. may be negotiated between the compressor and decompressor before header compression/decompression is performed.

In ROHC, header information may be classified into static parts and dynamic parts. The static part of the header information in ROHC may be information that rarely changes among the header information of each packet belonging to an IP flow. The static part of the header information in ROHC may be information including, for example, the source address, destination address, and version in an IPv4 header or IPv6 header, and the source port and destination port in a UDP header or TCP header. The dynamic part of the header information in ROHC may be information that may change from packet to packet among the header information of each packet belonging to an IP flow. The dynamic part of the header information in ROHC may be information including, for example, the traffic class and hop limit in an IPv6 header, the type of service and time to live in an IPv4 header, the checksum in a UDP header, the RTP sequence number and RTP timestamp in an RTP header.

A ROHC compressor may exist in three states: IR (Initialization and Refresh), FO (First Order), and SO (Second Order). When the IR state is used, the compressor may not compress the header information to be compressed and may send all header information to the decompressor. When the FO state is used, the compressor may compress most of the static parts of the header information to be compressed and send some static and dynamic parts to the decompressor without compressing them. When the SO state is used, the header compression rate is highest and the compressor may send only limited information such as the RTP sequence number.

A ROHC decompressor may exist in three states: NC (No Context), SC (Static Context), and FC (Full Context). The initial state of the decompressor may be the NC state. If the context is acquired in the NC state and header decompression is performed correctly, the decompressor may transition to the FC state. If header decompression fails consecutively in the FC state, the decompressor may transition to the SC or NC state.

There may be three ROHC processing modes: U-mode (Unidirectional mode), O-mode (Bidirectional Optimistic mode), and R-mode (Bidirectional Reliable mode). In U-mode, ROHC feedback packets may not be used. In U-mode, the transition from low compression mode to high compression mode in the compressor, i.e., the transition from IR state to FO state, and/or the transition from FO state to SO state, and/or the transition from IR state to SO state, may be performed by sending a certain number of packets. Also, in U-mode, the transition from high compression mode to low compression mode in the compressor, i.e., the transition from SO state to FO state, and/or the transition from FO state to IR state, and/or the transition from SO state to IR state, may be performed at regular intervals, thereby periodically sending information necessary for header decompression to the decompressor. In O-mode, the decompressor may request a context update from the compressor by sending a ROHC feedback packet to the compressor. In R-mode, the compressor may transition from low compression mode to high compression mode by receiving a header decompression success notification from the decompressor via a ROHC feedback packet. Also, in R-mode, the compressor may transition from high compression mode to low compression mode by receiving a context update request from the decompressor via a ROHC feedback packet. The ROHC processing mode may start from U-mode. The transition of the ROHC processing mode may be determined by the decompressor. The decompressor may prompt the compressor to transition the processing mode using a ROHC feedback packet.

An example of SDAP functionality is described below. SDAP is a service data adaptation protocol layer. SDAP may have the function of mapping the downlink QoS flow sent from 5GC110 to the terminal device via the base station device to a data radio bearer (DRB), and/or the function of mapping the uplink QoS flow sent from the terminal device to 5GC110 via the base station device to a DRB. SDAP may also have the function of storing mapping rule information. SDAP may also have the function of marking the QoS flow identifier (QoS Flow ID: QFI). SDAP PDUs may include 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). There may be one SDAP entity in the terminal device per PDU session.

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

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

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

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

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

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

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

Here is an example of NAS functions: The NAS may have authentication functions. The NAS may also have mobility management functions. The NAS may also have security control functions.

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

In addition, layers above the AS layer of the terminal device (not shown) may include the IP layer, and above the IP layer, the TCP (Transmission Control Protocol) layer, the UDP (User Datagram Protocol) layer, etc. Furthermore, an Ethernet layer may be present above the AS layer of the terminal device. This may be called the PDU layer above the AS layer of the terminal device. The PDU layer may include the IP layer, TCP layer, UDP layer, Ethernet layer, etc. An application layer may be present above the IP layer, TCP layer, UDP layer, Ethernet layer, PDU layer, etc. The application layer may include SIP (Session Initiation Protocol) and SDP (Session Description Protocol) used in IMS (IP Multimedia Subsystem), which is one of the service networks standardized by 3GPP. Furthermore, the application layer may 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. Furthermore, the application layer may include various media codecs, etc. The RRC layer may also be a layer above the SDAP layer.

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

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

The definition of dormancy may differ between UE122 connected to EPC104 and UE122 connected to 5GC110. In addition, all or part of the procedure for UE122 to return from dormancy may differ between when UE122 is connected to EPC (when it is dormant in RRC_IDLE state) and when UE122 is connected to 5GC (when it is dormant in RRC_INACTIVE state).

The RRC_CONNECTED state, RRC_INACTIVE state, and RRC_IDLE state may also be referred to as the connected mode, inactive mode, and idle mode, respectively, or as the RRC connected mode, RRC inactive mode, and RRC idle mode.

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

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

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

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

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

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

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

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

Explaining radio bearers. SRB0 to SRB2 may be defined as SRBs for E-UTRA, or other SRBs may be defined. SRB0 to SRB3 may be defined as SRBs for NR, 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 the establishment of SRB2. RRC messages transmitted and/or received using SRB1 may include piggybacked NAS messages. The logical channel DCCH may be used for all RRC messages and NAS messages transmitted and/or received using SRB1. SRB2 may be an SRB for NAS messages and for RRC messages including logged measurement information. The logical channel DCCH may be used for all RRC messages 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 in the terminal device. The logical channel DCCH may be used for all RRC messages and NAS messages transmitted and/or received using SRB3. Other SRBs may also be prepared for other uses. DRB may be a radio bearer for user data. The logical channel DTCH may be used for RRC messages transmitted and/or received using DRBs.

This section describes radio bearers in a terminal device. A radio bearer may include an RLC bearer. An RLC bearer may consist of one or two RLC entities and logical channels. If an RLC bearer has two RLC entities, the RLC entities may be a TM RLC entity and/or a transmitting RLC entity and a receiving RLC entity in a unidirectional UM mode RLC entity. SRB0 may consist of one RLC bearer. The RLC bearer of SRB0 may consist of a TM RLC entity and a logical channel. SRB0 may always be established in a terminal device in all states (such as RRC idle state, RRC connected state, and RRC inactive state). SRB1 may be established and/or configured in the terminal device by an RRC message received from the base station device when the terminal device transitions from RRC idle state to RRC connected state. SRB1 may consist of one PDCP entity and one or more RLC bearers. The RLC bearer of SRB1 may consist of an AM RLC entity and a logical channel. SRB2 may be established and/or configured in a terminal device by an RRC message received from a base station device by a terminal device in an RRC connected state with AS security activated. SRB2 may consist of a 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 device side of SRB1 and SRB2 may be placed in the master node. SRB3 may be established and/or configured in a terminal device by an RRC message received from a base station device by a terminal device in an RRC connected state with AS security activated when a secondary node is added or changed in 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 a 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 device side of SRB3 may be placed in a secondary node. One or more DRBs may be established and/or configured in the terminal device by an RRC message received from the base station device by the terminal device in an RRC connected 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 radio bearer in which a PDCP is placed in the master node may be called an MN terminated bearer. Also, in MR-DC, a radio bearer in which a PDCP is placed in a secondary node may be called an SN terminated bearer. Also, in MR-DC, a radio bearer in which an RLC bearer exists only in an MCG may be called an MCG bearer. Also, in MR-DC, a radio bearer in which an RLC bearer exists only in an SCG may be called an SCG bearer. Also, in DC, a radio bearer in which an RLC bearer exists in both an MCG and an SCG may be called a split bearer.

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

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

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

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

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

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

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

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

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

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

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

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

In Figure 7, the information element represented by RadioBearerConfig may be an information element used to configure, change, release, etc., radio bearers such as SRBs and DRBs. The information element represented by RadioBearerConfig may include the PDCP configuration information element and the SDAP configuration information element described below. The information element represented by RadioBearerConfig may also be referred to as a radio bearer configuration information element or radio bearer configuration. The information element represented by SRB-ToAddMod included in the information element represented by RadioBearerConfig may be an information element indicating SRB (signaling radio bearer) configuration. The information element represented by SRB-ToAddMod may also be referred to as an SRB configuration information element or SRB configuration. Furthermore, the information element represented by SRB-ToAddModList may be a list of SRB configurations. The information element represented by DRB-ToAddMod included in the information element represented by RadioBearerConfig may be an information element indicating DRB (data radio bearer) configuration. The information element represented by DRB-ToAddMod may also be referred to as a DRB configuration information element or DRB configuration. The information element represented by DRB-ToAddModList may be a list of DRB configurations. Note that SRB configuration and DRB configuration may also be referred to as radio bearer configuration.

The field represented by srb-Identity in the SRB configuration information element is the SRB identity information of the SRB to be added or changed, and may be an identifier that uniquely identifies the SRB in each terminal device. The field represented by srb-Identity in the SRB configuration information element may also be referred to as the SRB identifier field or SRB identifier. The SRB identifier may also be referred to as the radio bearer identifier.

The field represented by drb-Identity in the DRB setting information element contains information about the DRB identifier (DRB Identity) of the DRB to be added or changed, and may be an identifier that uniquely identifies the DRB in each terminal device. The field represented by drb-Identity in the DRB setting information element may also be referred to as the DRB identifier field or DRB identifier. In the example of Figure 7, the value of the DRB identifier is an integer value between 1 and 32, but it may take on other values. In the case of DC, the DRB identifier may be unique within the scope of UE122. The DRB identifier may also be referred to as the radio bearer identifier.

The field represented by cnAssociation in the DRB configuration information element may be a field indicating whether the radio bearer is associated with the field represented by eps-bearerIdentity described below, or with the information element represented by SDAP-Config described below. The field represented by cnAssociation may be referred to as a core network association field or core network association. The field represented by cnAssociation may include an EPS bearer identifier field (eps-bearerIdentity) described below when the terminal device connects to EPC104. The field represented by cnAssociation may also include an information element (SDAP-Config) indicating the SDAP configuration described below when the terminal device connects to the core network 5GC110. The field represented by eps-bearerIdentity may be a field indicating an EPS bearer identifier that identifies the EPS bearer. The field represented by eps-bearerIdentity may be referred to as an EPS bearer identifier field or EPS bearer identifier.

The information element represented by SDAP-Config may be information related to the configuration or reconfiguration of an SDAP entity. The information element represented by SDAP-Config may be referred to as an SDAP configuration information element or SDAP configuration.

The field indicated by pdu-session included in the SDAP configuration information element may be the PDU session identifier of the PDU session to which the QoS flow mapped to the corresponding radio bearer belongs. The field indicated by pdu-session may be referred to as the PDU session identifier field or PDU session identifier. The PDU session identifier may be the PDU session identifier of the PDU session. Furthermore, the corresponding radio bearer may be the DRB associated with the DRB identifier of the DRB configuration including this SDAP configuration field.

The field indicated by mappedQoS-FlowsToAdd included in the SDAP configuration information element may be information indicating a list of QoS Flow Identity (QFI) fields of uplink QoS flows to be additionally mapped to the corresponding radio bearer. The field indicated by mappedQoS-FlowsToAdd may be referred to as the QoS flow field to be added or the QoS flow to be added. The above-mentioned QoS flow may be the QoS flow of the PDU session indicated by the PDU session included in this SDAP configuration information element. Furthermore, the corresponding radio bearer may be the DRB associated with the DRB identifier of the DRB configuration including this SDAP configuration field.

Furthermore, the field indicated by mappedQoS-FlowsToRelease included in the SDAP configuration information element may be information indicating a list of QoS flow identifier information elements of the QoS flows to be released from the correspondence among the QoS flows mapped to the corresponding radio bearer. The field indicated by mappedQoS-FlowsToRelease may be referred to as the QoS flow field to be released or the QoS flow to be released. The above-mentioned QoS flow may be the QoS flow of the PDU session indicated by the PDU session included in this SDAP configuration information element. Furthermore, the corresponding radio bearer may be the DRB associated with the DRB identifier of the DRB configuration including this SDAP configuration field.

The SDAP configuration information element may also include a field indicating whether an uplink SDAP header is present in the uplink data transmitted via the corresponding radio bearer, a field indicating whether a downlink SDAP header is present in the downlink data received via the corresponding radio bearer, and a field indicating whether the corresponding radio bearer is the default radio bearer (default DRB). The corresponding radio bearer may also refer to the DRB associated with the DRB identifier of the DRB configuration including this SDAP configuration field.

In addition, the information element represented by PDCP-Config among the SRB configuration information element and the DRB configuration information element may be an information element regarding the configuration of the NR PDCP entity. The information element represented by PDCP-Config may be referred to as the PDCP configuration information element or PDCP configuration. The information element regarding the configuration of the NR PDCP entity may include a field indicating the size of the uplink sequence number, a field indicating the size of the downlink sequence number, a field indicating the profile of the RObust Header Compression (ROHC), a field indicating the value of the re-ordering timer, etc.

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

In Figure 8, the information element represented by RadioResourceConfigDedicated may be an information element used for setting up, changing, releasing, etc. a radio bearer. The information element represented by SRB-ToAddMod included in the information element represented by RadioResourceConfigDedicated may be information indicating SRB (signaling radio bearer) setting. The information element represented by SRB-ToAddMod may be referred to as an SRB setting information element or SRB setting. The information element represented by SRB-ToAddModList may be a list of information indicating SRB setting. The information element represented by DRB-ToAddMod included in the information element represented by RadioResourceConfigDedicated may be information indicating DRB (data radio bearer) setting. The information element represented by DRB-ToAddMod may be referred to as a DRB setting information element or DRB setting. The information element represented by DRB-ToAddModList may be a list of information indicating DRB setting. Note that any or all of the SRB setting and DRB setting may be referred to as radio bearer setting.

The field represented by srb-Identity in the SRB configuration information element is the SRB identifier (SRB Identity) information of the SRB to be added or changed, and may be an identifier that uniquely identifies the SRB in each terminal device. The field represented by srb-Identity in the SRB configuration information element may also be referred to as the SRB identifier field or SRB identifier. The SRB identifier may also be referred to as the radio bearer identifier. The SRB identifier in Figure 8 may have the same role as the SRB identifier in Figure 7.

The field represented by drb-Identity in the DRB setting contains information about the DRB identifier (DRB Identity) of the DRB to be added or changed, and may be an identifier that uniquely identifies the DRB in each terminal device. The field represented by drb-Identity in the DRB setting information element may also be referred to as the DRB identifier field or DRB identifier. In the example of Figure 8, the value of the DRB identifier is an integer value between 1 and 32, but it may take on a different value. The DRB identifier may also be referred to as the radio bearer identifier. The DRB identifier in Figure 8 may have the same role as the DRB identifier in Figure 7.

The field represented by eps-BearerIdentity in the DRB configuration information element may be an EPS bearer identifier that uniquely identifies the EPS bearer in each terminal device. The field represented by eps-BearerIdentity may also be referred to as the EPS bearer identifier field or EPS bearer identifier. The value of the EPS bearer identifier is an integer value from 1 to 15 in the example of Figure 8, but it may take on a different value. The EPS bearer identifier in Figure 8 may have the same role as the EPS bearer identifier in Figure 7. Furthermore, there may be a one-to-one correspondence between the EPS bearer identifier and the DRB identifier in each terminal device.

Furthermore, among the SRB configuration information elements and DRB configuration information elements, the information element represented by PDCP-Config may be an information element for the configuration of an E-UTRA PDCP entity. The information element represented by PDCP-Config may be referred to as the PDCP configuration information element or PDCP configuration. The information element for the configuration of an E-UTRA PDCP entity may include a field indicating the size of the sequence number, a field indicating the profile of RObust Header Compression (ROHC), a field indicating the value of the re-ordering timer, etc.

Furthermore, the SRB configuration information element shown in Figure 8 may further include a field related to E-UTRA RLC entity configuration (not shown). The field related to E-UTRA RLC entity configuration may be referred to as an RLC configuration field or RLC configuration. Further, the SRB configuration information element shown in Figure 8 may include an information element related to logical channel configuration (not shown). The information element related to logical channel configuration may be referred to as a logical channel configuration information element or logical channel configuration.

The DRB configuration information element shown in Figure 8 may further include an information element regarding E-UTRA RLC entity configuration (not shown). The information element regarding E-UTRA RLC entity configuration may be referred to as an RLC configuration information element or RLC configuration. The DRB configuration information element shown in Figure 8 may include a field indicating logical channel identifier (identity: ID) information. The field indicating logical channel identifier (identity: ID) information may be referred to as a logical channel identifier field or logical channel identifier. The DRB configuration information element shown in Figure 8 may further include an information element regarding logical channel configuration (not shown). The information element regarding logical channel configuration may be referred to as a logical channel configuration information element or logical channel configuration. The logical channel identifier may be linked to a radio bearer identifier.

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

Note that in NR, information elements regarding RLC bearer configuration, such as information elements regarding NR RLC entity configuration for each radio bearer, information elements indicating logical channel identifier (ID) information, and information elements regarding logical channel configuration, may be included in information elements regarding cell group configuration (not shown) rather than in information elements represented by RadioBearerConfig in Figure 7. Information elements regarding cell group configuration may be included in messages regarding RRC connection reconfiguration. Information elements regarding cell group configuration may be referred to as cell group configuration information elements or cell group configuration. Information elements regarding NR RLC entity configuration may be referred to as RLC configuration information elements or RLC configuration. Information elements indicating logical channel identifier information may be referred to as logical channel identifier information elements or logical channel identifiers. Information elements regarding logical channel configuration may be referred to as logical channel configuration information elements or logical channel identifiers. Note that logical channel identifiers may be linked to radio bearer identifiers.

Furthermore, some or all of the fields and information elements described using Figure 7 or Figure 8 may be optional. That is, the fields and information elements described using Figure 7 or Figure 8 may be included in messages related to RRC connection reconfiguration as needed or required. Furthermore, messages related to RRC connection reconfiguration may include, in addition to information elements related to radio bearer configuration, fields indicating that full configuration is applied. Fields indicating that full configuration is applied may be represented by information element names such as fullConfig, and true, enable, etc. may be used to indicate that full configuration is applied.

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

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

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

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

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

An overview of MBMS transmission/reception operations using SC-PTM is explained using Figures 9 to 11. Note that the terms MBMS, MBMS service, and MBMS session used in the following explanation may have equivalent meanings and may be interchangeable.

Figure 9 is a diagram showing the flow of the procedure for configuring MBMS reception using SC-PTM. Figure 10 is a diagram showing an example of an ASN.1 description representing the fields and/or information elements included in SIB20 (System Information Block Type 20) in Figure 9. Figure 11 is a diagram showing an example of an ASN.1 description representing the fields and/or information elements included in the SC-PTM configuration message (SCPTMConfiguration) in Figure 9.

As shown in FIG. 9, the processing unit 602 of the eNB102 creates an RRC message, SIB20 (System Information Block type 20), and transmits it to the UE122 via the BCCH from the transmission unit 600. The reception unit 500 of the UE122 receives the SIB20 (step S900).

SIB20 includes information necessary for acquiring control information (specifically, SC-MCCH) related to MBMS transmission using SC-PTM. For example, SIB20 includes some or all of the following fields and/or information elements: a field represented by sc-mcch-ModificationPeriod indicating the period during which the content of SC-MCCH may be changed; a field represented by sc-mcch-RepetitionPeriod indicating the transmission (retransmission) time interval of SC-MCCH in terms of the number of radio frames; a field represented by sc-mcch-Offset indicating the offset of the radio frame in which SC-MCCH is scheduled; a field represented by sc-mcch-FirstSubframe indicating the subframe in which SC-MCCH is scheduled; and a field represented by sc-mcch-duration indicating the duration of the subframe in which SC-MCCH is scheduled.

Next, the processing unit of eNB102 creates an SC-PTM configuration message (SCPTM Configuration), which is an RRC message, and transmits it from the transmitting unit 600 via the SC-MCCH. The receiving unit 500 of UE122 receives the SC-PTM configuration information based on the settings in SIB20. At the physical layer, the SC-RNTI (Single Cell RNTI) is used to transmit the SC-MCCH (step S902).

The SC-PTM configuration information includes control information applicable to MBMS reception. For example, the SC-PTM configuration information includes some or all of the following fields and/or information elements: a field represented by sc-mtch-InfoList, which contains the configuration of each SC-MTCH in the cell transmitting the information; and a field represented by scptm-NeighborCellList, which is a list of neighboring cells providing MBMS.

The sc-mtch-InfoList contains one or more information elements represented by SC-MTCH-Info. Each SC-MTCH-Info contains some or all of the following fields: a field represented by mbmsSessionInfo, which contains information about the MBMS session; a field represented by g-RNTI, which is the RNTI (Radio Network Temporary Identifier) that identifies the multicast group (specifically, the SC-MTCH addressed to a specific group); a field represented by sc-mtch-schedulingInfo, which contains DRX information for the SC-MTCH; and a field represented by sc-mtch-neighbourCell, which contains information about neighboring cells from which the MBMS session can receive signals using the SC-MTCH. The mbmsSessionInfo contains some or all of the following fields: an identifier that identifies the MBMS bearer service, a field represented by tmgi, which is the TMGI (Temporary Mobile Group Identity); and a field represented by sessionId, which is the MBMS session identifier.

To start receiving an MBMS session of interest, the processing unit 502 of the UE 122 may perform a process to establish an SC-MRB (Single Cell MBMS Point to Multipoint Radio Bearer), which is a radio bearer for receiving an MBMS session using SC-PTM (step S904). The SC-MRB establishment process may be initiated, for example, at the start of the MBMS session, when the UE 122 enters a cell in which the MBMS service of interest is provided via the SC-MRB, when the UE 122 becomes interested in the MBMS service, or when a UE capability limit that inhibits reception of the MBMS service is removed. The SC-MRB establishment process may be performed when the UE 122 is in the RRC_IDLE state or when the UE 122 is in the RRC_CONNECTED state. When performing the SC-MRB establishment process, the processing unit 502 of the UE 122 may perform some or all of the following processes (A) to (D).
(A) Establish an RLC entity according to the default settings of SC-MCCH and SC-MTCH.
(B) Configure an SC-MTCH logical channel applicable to the SC-MRB to be established, and instruct the MAC entity to receive the MBMS session in accordance with the above-mentioned SC-PTM configuration message for the cell that received the above-mentioned SC-PTM configuration message.
(C) For the SC-MRB to be established, configure the physical layer based on the above-mentioned sc-mtch-InfoList.
(D) The establishment of the SC-MRB is notified to the upper layer by notifying the tmgi and sessionId corresponding to the established SC-MRB.

The processing unit 502 of the UE 122 receives the MBMS session via the established SC-MRB in accordance with the above-mentioned SC-PTM setting message (step S906). Before receiving the MBMS session, the processing unit 502 of the UE 122 may create an MBMS interest notification message (MBMSInterestIndication) to notify the eNB 102 that it will receive or is interested in receiving the MBMS service via the SC-MRB, and transmit the message to the eNB 102 via the transmitting unit 504 (not shown). The MBMS interest notification message may include information on whether MBMS service reception is prioritized over unicast reception. The MBMS interest notification message may also be sent when transitioning to the RRC_CONNECTED state after receiving SIB20, or after transitioning to the RRC_CONNECTED state. The MBMS interest notification message may also be sent when SIB20 is received during handover, or when SIB20 is received during re-establishment of the RRC connection.

The processing unit 502 of the UE 122 may perform an SC-MRB release process to stop receiving the MBMS session (step S908). The SC-MRB release process may be initiated, for example, when stopping the receiving MBMS session, when moving away from the cell where the SC-MRB is established, when interest in the MBMS service is lost, when reception of the MBMS service is suppressed due to a limit in the UE capability, etc. The SC-MRB release process may be performed when the UE 122 is in the RRC_IDLE state, or when the UE 122 is in the RRC_CONNECTED state. When performing the SC-MRB release process, the processing unit 502 of the UE 122 may perform some or all of the following processes (A) and (B).
(A) Release the RLC entity of the SC-MRB to be released and the associated MAC and physical layer configurations.
(B) The upper layer is notified of the release of the SC-MRB by notifying the tmgi and sessionId corresponding to the released SC-MRB.

The above provides an overview of the operations related to configuring MBMS reception using SC-PTM. In addition to MBMS transmission from a base station device and MBMS reception at a terminal device using SC-PTM (hereinafter referred to as MBMS transmission/reception), MBMS transmission/reception using MBSFN has also been standardized. However, MBMS transmission/reception using SC-PTM and MBMS transmission/reception using MBSFN use E-UTRA as the RAT. Multicast Broadcast Service (MBS) transmission/reception using NR as the RAT has not yet been standardized.

Using Figure 12, an example of the operation of UE122 and gNB108 in an embodiment of the present invention will be described. Note that the terms MBS, MBS service, MBS session, and MBS bearer used in the embodiment of the present invention may have equivalent meanings and may be interchangeable. Also, the terms MBS, MBS service, and MBS session used in the embodiment of the present invention may have equivalent meanings to MBMS, MBMS service, and MBMS session. Also, in the embodiment of the present invention, an MBS radio bearer may be established and/or configured in UE122 for MBS reception. Also, an MBS radio bearer may be established and/or configured in gNB108 for MBS transmission. Also, in the embodiment of the present invention, the MBS radio bearer will be described using the name MRB (Multicast Radio Bearer), but it may be called something else. Furthermore, in an embodiment of the present invention, the MRB established and/or configured in the UE 122 may be an MRB for receiving an MBS in a point-to-multipoint manner, or may be an MRB for receiving an MBS in a point-to-point manner. Furthermore, in an embodiment of the present invention, the MRB for receiving an MBS in a point-to-multipoint manner and the MRB for receiving an MBS in a point-to-point manner may be the same MRB. That is, one MRB may have the capability to receive an MBS in a point-to-multipoint manner and the capability to receive an MBS in a point-to-point manner. When one MRB has the capability to receive an MBS in a point-to-multipoint manner and the capability to receive an MBS in a point-to-point manner, the MRB may include one or more RLC bearers for receiving and/or transmitting an MBS in a point-to-multipoint manner and one or more RLC bearers for receiving and/or transmitting an MBS in a point-to-point manner. When one MRB has the capability to receive MBSs one-to-many and one-to-one, one or more RLC bearers for receiving and/or transmitting MBSs one-to-many and one or more RLC bearers for receiving and/or transmitting MBSs one-to-one may be associated with one PDCP entity. One or more QoS flows may be associated with the MRB. Note that the MRB for receiving MBSs one-to-one (point-to-point) may be a DRB.

Receiving and/or transmitting an MBS in a one-to-many manner may mean receiving and/or transmitting the MBS via a multicast logical channel such as MTCH or SC-MTCH. Receiving and/or transmitting an MBS in a one-to-one manner may mean receiving and/or transmitting the MBS via a dedicated user data logical channel such as DTCH. In embodiments of the present invention, receiving and/or transmitting an MBS in a one-to-many manner may be rephrased as receiving and/or transmitting the MBS via multicast. In embodiments of the present invention, receiving and/or transmitting an MBS in a one-to-one manner may be rephrased as receiving and/or transmitting the MBS via unicast. When receiving and/or transmitting an MBS in a one-to-one manner, security may be applied. When receiving and/or transmitting an MBS in a one-to-many manner, security may not be applied. Security may include ciphering and deciphering, and/or integrity protection and verification.

Figure 12 shows an example of the flow of the MBS reception procedure in NR in an embodiment of the present invention. Note that in this embodiment, parameters and/or information may be fields and/or information elements in ASN.1.

As shown in FIG. 12, the processing unit 602 of the gNB108 may create a first SIB (System Information Block), which is one of the RRC messages, to broadcast information necessary for acquiring control information related to MBS transmission, and transmit the first SIB to the UE122 via the transmitting unit 600. The receiving unit 500 of the UE122 receives the first SIB. Note that the first SIB may be transmitted via the BCCH logical channel or via another logical channel. The information necessary for acquiring the control information related to the MBS transmission may also be information related to the MCCH (Multicast Control Channel) logical channel (also referred to as the MCCH in the following description). The MCCH may be a point-to-multipoint downlink channel for transmitting MBS control information, MBS setting information, and/or MBS information for one or more MTCH (Multicast Traffic Channel) logical channels (also referred to as the MTCH in the following description) from the gNB108 to the UE122. The above-mentioned MTCH may be a point-to-multipoint downlink channel for transmitting MBS data from the gNB 108 to the UE 122. The above-mentioned MCCH may be a multicast control channel. The above-mentioned MTCH may be a multicast traffic channel. The above-mentioned MTCH may be used by the UE 122 only when the UE 122 receives the MBS. The above-mentioned MCCH may be called by other names such as MBS-MCCH or NR-MCCH. The above-mentioned MTCH may be called by other names such as MBS-MTCH or NR-MTCH. The above-mentioned MCCH may be mapped to a downlink transport channel, MCH (Multicast Channel), or may be mapped to a downlink transport channel, DL-SCH (Downlink Shared Channel). The above-mentioned MTCH may be mapped to a downlink transport channel, MCH (Multicast Channel), or may be mapped to a downlink transport channel, DL-SCH (Downlink Shared Channel). The MBS control information, MBS configuration information, and/or MBS information for one or more MTCH logical channels may be included in the first SIB or in a second SIB separate from the first SIB (step S1200).

The above-mentioned first SIB may include some or all of the following parameters: a parameter indicating the period during which the content of the MCCH may be changed; a parameter related to the transmission (retransmission) time interval of the MCCH; a parameter indicating the offset of the radio frame in which the MCCH is scheduled; a parameter indicating the slot in which the MCCH is scheduled; a parameter indicating the duration of the slot in which the MCCH is scheduled; etc. The above-mentioned parameter related to the transmission (retransmission) time interval of the MCCH may be expressed in terms of the number of radio frames.

Next, the processing unit of gNB108 may create an RRC message to be transmitted on the above-mentioned MCCH and transmit it from the transmission unit 600. The reception unit 500 of UE122 may receive the RRC message transmitted on the above-mentioned MCCH based on the setting of the above-mentioned first SIB. A dedicated RNTI (Radio Network Temporary Identifier) for identifying the above-mentioned MCCH transmission may be used for the above-mentioned MCCH transmission. Furthermore, a specific value may be used as the value of the dedicated RNTI for identifying the above-mentioned MCCH transmission, or a value may be set by the above-mentioned first SIB. In the embodiment of the present invention, the RRC message transmitted on the above-mentioned MCCH is described using the message name MBS setting information message, but it may also have a different message name. (Step S1202)

The above-mentioned MBS configuration information message may include one or more MBS MTCH parameters, which are parameters for MBS reception. For example, one or more MBS MTCH parameters may be included in the above-mentioned MBS configuration information message in the form of a list, just as the information element indicated by SC-MTCH-InfoList in FIG. 11 includes one or more information elements indicated by SC-MTCH-Info in the form of a list. Furthermore, MBS MTCH parameters may exist for each MBS session. For example, a first MBS MTCH parameter may exist for the first MBS session, and a second MBS MTCH parameter may exist for the second MBS session. Note that in the embodiments of the present invention, the above-mentioned parameters for MBS reception are described using the name MBS MTCH parameters, but they may be named differently.

MBS MTCH parameters may include some or all of the following parameters: parameters related to MBS session information, a parameter indicating the RNTI that identifies the multicast group (MTCH addressed to a specific group), a parameter indicating a logical channel identifier, a parameter related to DRX information for the MTCH, a parameter indicating a list of neighboring cells that provide the same MBS, a parameter indicating whether ROHC is applied to the MBS session, parameters related to the ROHC used for the MBS session, parameters related to the HFN (Hyper Frame Number), parameters related to the COUNT, and parameters related to the status report timer. The above-mentioned parameters related to MBS session information may include some or all of the following parameters: a parameter indicating the TMGI (Temporary Mobile Group Identity), which is an identifier that identifies the MBS; a parameter indicating the Session ID, which is an identifier for the MBS (or MBMS) session; a parameter indicating the PDU session to which the MBS session belongs; a parameter indicating the QoS flow used for the MBS session. Furthermore, some or all of the above-mentioned MBS MTCH parameters may be included in the above-mentioned first SIB, may be included in the above-mentioned second SIB, or may be included in a third SIB separate from the above-mentioned first SIB and second SIB.

In addition, the parameter indicating the list of neighboring cells that provide the same MBS as mentioned above may include a parameter indicating a list of neighboring cells that provide the same MBS via MTCH and/or MRB, or may include a parameter indicating a list of neighboring cells that provide the same MBS via unicast and/or DTCH and/or DRB.

The MBS configuration information message and/or MBS MTCH parameters may also include parameters related to MRB configuration. The parameters related to MRB configuration may include some or all of parameters including an identifier for identifying an MRB, an SDAP configuration information element, and a PDCP configuration information element. The above-mentioned parameters related to MRB configuration may also include one or more RLC bearer configuration information elements. The above-mentioned RLC bearer configuration information elements may include some or all of RLC configuration information elements for establishing and/or configuring an RLC entity and logical channel information elements for configuring logical channels. The above-mentioned RLC bearer configuration information elements may also be included in information elements separate from the MRB configuration and may be linked to the parameters related to MRB configuration by an identifier for identifying the MRB, etc. The above-mentioned MRB configuration may also include a parameter for identifying an RLC bearer that receives an MBS in a one-to-many manner. The above-mentioned MRB configuration may also include a parameter for identifying an RLC bearer that receives an MBS in a one-to-one manner. The parameter for identifying the RLC bearer receiving the MBS in a one-to-many manner and/or the parameter for identifying the RLC bearer receiving the MBS in a one-to-one manner may be a logical channel identifier. The parameter indicating whether ROHC is applied to the MBS session, and/or the parameters related to ROHC used in the MBS session, and/or the parameters related to the HFN (Hyper Frame Number), and/or the parameters related to the COUNT, and/or the parameters related to the status report timer, etc., may be included in the parameters related to MRB configuration or in the PDCP configuration information element. The parameter indicating the PDU session and/or the parameters indicating the QoS flow, etc., may be included in the parameters related to MRB configuration or in the SDAP configuration information element. The parameter indicating the PDU session may be a PDU session ID.

UE 122 receives the MBS setting information message from the receiver 500, and the processor 502 may perform processing to start receiving the MBS session of interest. (Step S1204)

In step S1204, the processing unit 502 of the UE 122 may determine, from the MBS configuration information message received in step S1202, whether ROHC applies to the MBS session of interest. The determination of whether ROHC applies to the MBS session of interest may be made based on whether the above-mentioned MBS configuration information message and/or MBS MTCH parameters include a parameter indicating whether ROHC applies. That is, if the above-mentioned MBS configuration information message and/or MBS MTCH parameters for the MBS session of interest include a parameter indicating whether ROHC applies, it may be determined that ROHC applies; and if the above-mentioned MBS configuration information message and/or MBS MTCH parameters for the MBS session of interest do not include a parameter indicating whether ROHC applies, it may be determined that ROHC does not apply. The determination of whether ROHC applies may also be made based on the value of the parameter indicating whether ROHC applies, which is included in the above-mentioned MBS configuration information message and/or MBS MTCH parameters for the MBS session of interest. That is, if a parameter indicating whether ROHC is applied, which is included in the above-mentioned MBS configuration information message and/or MBS MTCH parameters for the MBS session of interest, has a value indicating that ROHC is applied, it may be determined that ROHC is applied. If a parameter indicating whether ROHC is applied, which is included in the above-mentioned MBS configuration information message and/or MBS MTCH parameters for the MBS session of interest, indicates that ROHC is not applied, it may be determined that ROHC is not applied. Furthermore, the determination of whether ROHC is applied may be based on whether the above-mentioned MBS configuration information message and/or MBS MTCH parameters for the MBS session of interest include parameters related to ROHC used for the MBS session. That is, if the above-mentioned MBS configuration information message and/or MBS MTCH parameters for the MBS session of interest include parameters related to ROHC used for the MBS session, it may be determined that ROHC is applied. Furthermore, if the above-mentioned MBS configuration information message and/or MBS MTCH parameters for the MBS session of interest do not include parameters related to ROHC used for the MBS session, it may be determined that ROHC is not applied. The MBS session of interest may be rephrased as a session that the UE 122 wants to receive, or a session that the UE 122 is about to receive.

The ROHC-related parameters used in the MBS session may include some or all of the following: a parameter related to the maximum value of the context identifier (CID) used in ROHC; a parameter related to the profile used in ROHC; and a parameter indicating whether to continue or reset the ROHC header compression protocol upon PDCP re-establishment. The ROHC-related parameters used in the MBS session may also include a parameter related to the timing at which all header information is obtained. The timing at which all header information is obtained may be the period during which all header information is obtained. The parameter related to the timing at which all header information is obtained may include some or all of the following: a parameter indicating the period during which some or all of the header information may be changed; a parameter indicating the time interval in radio frames for transmitting all header information; a parameter indicating the offset of the radio frame during which transmission of all header information is scheduled; a parameter indicating the slot during which transmission of all header information is scheduled; and a parameter indicating the window length of the slot during which transmission of all header information is scheduled. The all header information may be all header information (IP header, UDP header, TCP header, RTP header, etc.) that is to be compressed in ROHC. The timing when all of the above-mentioned header information is obtained may be rephrased as the timing when ROHC context information is obtained. The timing when all of the above-mentioned header information is obtained may be rephrased as the timing when the header information is transmitted using the IR state, the FO state, and/or the SO state. The timing when all of the header information is obtained may be the timing when the UE 122 starts receiving an MBS or an MTCH. The timing when all of the above-mentioned header information is obtained may be the timing when the UE 122 should start receiving an MBS or an MTCH.

Furthermore, in step S1204, the processing unit 502 of UE122 that determines that ROHC applies to the MBS session of interest may determine that it is necessary to acquire ROHC context information based on the fact that ROHC applies to the MBS session of interest.Furthermore, in step S1204, the processing unit 502 of UE122 that determines that ROHC does not apply to the MBS session of interest may determine that it is not necessary to acquire ROHC context information based on the fact that ROHC does not apply to the MBS session of interest.

Furthermore, in step S1204, when the processing unit 502 of UE122 determines that ROHC applies to the MBS session of interest or that ROHC context information needs to be acquired, it may perform ROHC context acquisition processing. The above-mentioned ROHC context acquisition processing may be UE122 transitioning from the RRC_IDLE state or the RRC_INACTIVE state to the RRC_CONNECTED state. The transition of UE122 from the RRC_IDLE state to the RRC_CONNECTED state may be performed by UE122 sending an RRC setup request message to gNB108 and receiving an RRC setup message from gNB108 as a response message to the above-mentioned RRC setup request message. The transition of UE122 from the RRC_INACTIVE state to the RRC_CONNECTED state may be performed by UE122 sending an RRC resumption request message to gNB108 and receiving an RRC resumption message or an RRC setup message from gNB108 as a response message to the above-mentioned RRC resumption request message. Additionally, when UE 122 transitions from RRC_IDLE state or RRC_INACTIVE state to RRC_CONNECTED state, or after UE 122 transitions from RRC_IDLE state or RRC_INACTIVE state to RRC_CONNECTED state, UE 122 may send an RRC message to gNB 108 containing information about MBS sessions of interest.

An MRB for one-to-one reception of an MBS session or a DRB for receiving an MBS session may be established and/or configured for a UE 122 that has transitioned to the RRC_CONNECTED state. An MRB for one-to-one reception of an MBS session may be a radio bearer including one or more RLC bearers for one-to-many reception of an MBS session and one or more RLC bearers for one-to-one reception of an MBS session. Establishing and/or configuring an MRB for one-to-one reception of an MBS session may mean establishing and/or configuring an additional RLC bearer for one-to-one reception of an MRB session to an MRB that only has an RLC bearer for one-to-many reception of an MRB session. The additional establishment and/or configuration of an RLC bearer for one-to-one reception of an MRB session may mean associating the established and/or configured RLC bearer for one-to-one reception of an MBS session with the PDCP entity of the MRB that has only an RLC bearer for one-to-multiple reception of an MRB session. The ROHC context acquisition process may be performed by the UE 122 receiving the MBS session of interest one-to-one (step S1206).

Furthermore, the above-mentioned ROHC context acquisition process in step S1204 may be performed by UE122 in accordance with ROHC-related parameters included in the above-mentioned MBS configuration information message and/or MBS MTCH parameters for the MBS session of interest. For example, UE122 may acquire timing information regarding when all header information is obtained in accordance with the above-mentioned parameters regarding when all header information is obtained, and acquire ROHC context information at the timing when all header information is obtained. Note that UE122 may acquire timing information regarding when all header information is obtained in UE122's RRC in accordance with the above-mentioned parameters regarding when all header information is obtained, and notify UE122's MAC entity of information including some or all of the acquired timing information, thereby acquiring ROHC context information at the timing when all header information is obtained. Furthermore, when UE122's RRC notifies UE122's MAC entity of information including some or all of the acquired timing information, it may also send information on the RNTI used for one-to-many reception of the MBS session. In addition, in the RRC_IDLE state, the RRC_INACTIVE state, or the RRC_CONNECTED state, the UE 122 may perform a ROHC context acquisition process in accordance with the ROHC-related parameters included in the above-mentioned MBS configuration information message and/or the MBS MTCH parameters for the MBS session of interest. The timing at which all of the above-mentioned header information is obtained may also be referred to as the timing at which the IR state, the FO state, and/or the SO state are used. The timing at which all of the above-mentioned header information is obtained may also be referred to as the timing at which ROHC context information is obtained. The timing at which all of the above-mentioned header information is obtained may also be referred to as the timing at which reception of an MBS or MTCH starts. The timing at which all of the above-mentioned header information is obtained may also be referred to as the timing at which all of the information included in headers that are subject to header compression in ROHC (such as IP header, UDP header, TCP header, and RTP header) is obtained (step S1206).

Also, in step S1204, if the processing unit 502 of UE 122 determines that ROHC does not apply to the MBS session of interest or that acquisition of ROHC context information is not necessary, the processing unit 502 of UE 122 may determine that transition to the RRC_CONNECTED state for the purpose of acquiring ROHC context information is not necessary. Also, in step S1204, if the processing unit 502 of UE 122 determines that ROHC does not apply to the MBS session of interest or that acquisition of ROHC context information is not necessary, the processing unit 502 of UE 122 may receive the MBS service in the RRC_IDLE state or the RRC_INNACTIVE state without acquiring ROHC context information. Also, in step S1204, if the processing unit 502 of UE 122 determines that ROHC does not apply to the MBS session of interest or that acquisition of ROHC context information is not necessary, the processing unit 502 of UE 122 may receive the MBS service in the RRC_CONNECTED state without acquiring ROHC context information. (Step S1206)

In step S1204, the processing unit 502 of the UE 122 may determine whether the MBS configuration information message received in step S1202 includes a parameter related to the HFN (Hyper Frame Number) for the MBS session of interest. The above-mentioned parameter related to the HFN may be a parameter related to the HFN that the gNB 108 uses or is using for MBS session transmission. The above-mentioned parameter related to the HFN may be a parameter indicating that the UE 122 needs to obtain the value of the HFN that the gNB 108 uses or is using for MBS session transmission. The HFN that the gNB 108 uses or is using for the MBS session transmission MBS session may be the HFN that is a state variable of the transmitting PDCP entity that the gNB 108 uses or is using for MBS session transmission. When sending the MBS configuration information message, the gNB 108 may set the HFN parameter to the latest value of the HFN of the transmitting PDCP entity that the gNB 108 uses or is using for MBS session transmission. Furthermore, the above-mentioned HFN-related parameters may be parameters related to the timing at which the HFN value is transmitted from the gNB 108 using the MCCH or MTCH. The timing at which the HFN value is transmitted from the gNB 108 using the MCCH or MTCH may include, for example, some or all of a parameter indicating a period at which the HFN value may be changed, a parameter indicating the time interval at which the HFN value is transmitted in radio frames, a parameter indicating the offset of the radio frame at which the HFN value is scheduled, a parameter indicating the slot at which the HFN value is scheduled, and a parameter indicating the window length of the slot at which the HFN value is scheduled. At the timing at which the HFN value is transmitted, the gNB 108 may transmit an RRC message and/or a PDCP control PDU containing the latest HFN value of the transmitting PDCP entity that the gNB 108 uses or is using for the MBS session transmission, the last HFN value used for the MBS session transmission, or the HFN value to be used for the next MBS session transmission.

In step S1204, if the processing unit 502 of UE122 determines that the received MBS configuration information message includes parameters related to HFN for the MBS session of interest, the RRC of UE122 may obtain the HFN value according to the above-mentioned parameters related to HFN and notify the PDCP entity of the MRB of UE122. The RRC of UE122 may also perform processing so that the PDCP entity of the MRB of UE122 can obtain the HFN value according to the above-mentioned parameters related to HFN. The RRC of UE122 may obtain timing information for when the HFN value is sent according to the above-mentioned parameters related to the timing at which the HFN value is sent, and notify the MAC entity of UE122 of information including some or all of the obtained timing information, thereby processing so that the RRC of UE122 and/or the PDCP entity of the MRB can obtain the HFN value at the timing at which the HFN value is sent. Furthermore, when the RRC of UE 122 notifies the MAC entity of UE 122 of information including some or all of the acquired timing information, it may also send information about the RNTI used for one-to-many reception of the MBS session. The PDCP entity of the MRB of UE 122 may set the HFN value notified from the upper layer or the HFN value acquired by receiving the PDCP control PDU as the HFN of the receiving PDCP entity.

Also, in step S1204, if the processing unit 502 of UE122 determines that the received MBS configuration information message contains parameters related to HFN for the MBS session of interest, UE122 may transition from the RRC_IDLE state or the RRC_INACTIVE state to the RRC_CONNECTED state. The RRC of UE122 in the RRC_CONNECTED state may acquire the HFN value by receiving an RRC message including the HFN value from gNB108 via the DCCH. The RRC of UE122 may notify the PDCP entity of the MRB of UE122 of the acquired HFN value. The PDCP entity of the MRB of UE122 may set the HFN value notified from the upper layer as the HFN of the receiving PDCP entity.

In step S1204, the processing unit 502 of the UE 122 may determine whether the MBS configuration information message received in step S1202 includes a COUNT-related parameter for the MBS session of interest. The above-mentioned COUNT-related parameter may be a parameter related to the COUNT value that the gNB 108 uses or is using for MBS session transmission. The above-mentioned COUNT-related parameter may be a parameter indicating that the UE 122 needs to obtain the COUNT value that the gNB 108 uses or is using for MBS session transmission. The COUNT value that the gNB 108 uses or is using for the MBS session transmission MBS session may be the COUNT value, which is a state variable of the transmitting PDCP entity that the gNB 108 uses or is using for MBS session transmission. When sending the MBS configuration information message, the gNB 108 may set the COUNT-related parameter to the latest value of the COUNT value of the transmitting PDCP entity that the gNB 108 uses for MBS session transmission. Furthermore, the above-mentioned parameter related to COUNT may be a parameter related to the timing at which the COUNT value is transmitted from the gNB 108 using the MCCH or MTCH. The timing at which the COUNT value is transmitted from the gNB 108 using the MCCH or MTCH may include, for example, some or all of a parameter indicating a period at which the COUNT value may be changed, a parameter indicating the time interval at which the COUNT value is transmitted in radio frames, a parameter indicating the offset of the radio frame in which the COUNT value is scheduled, a parameter indicating the slot in which the COUNT value is scheduled, and a parameter indicating the window length of the slot in which the COUNT value is scheduled. At the timing at which the COUNT value is transmitted, the gNB 108 may set the latest COUNT value of the transmitting PDCP entity that the gNB 108 uses or is using for MBS session transmission, the last COUNT value used for MBS session transmission, or the COUNT value to be used for the next MBS session transmission in an RRC message and/or a PDCP control PDU, and transmit the set value.

In step S1204, if the processing unit 502 of UE122 determines that the received MBS configuration information message includes parameters related to COUNT for the MBS session of interest, the RRC of UE122 may obtain a COUNT value according to the above-mentioned parameters related to COUNT and notify the PDCP entity of the MRB of UE122. The RRC of UE122 may also perform processing so that the PDCP entity of the MRB of UE122 can obtain the COUNT value according to the above-mentioned parameters related to COUNT. The RRC of UE122 may obtain timing information for when the COUNT value is sent according to the above-mentioned parameters related to the timing at which the COUNT value is sent, and notify the MAC entity of UE122 of information including some or all of the obtained timing information, thereby processing so that the RRC of UE122 and/or the PDCP entity of the MRB can obtain the COUNT value at the timing at which the COUNT value is sent. When the RRC of UE122 notifies the MAC entity of UE122 of information including some or all of the obtained timing information, the RNTI information used for one-to-many reception of the MBS session may also be sent together. The PDCP entity of the MRB of UE 122 may set the COUNT value of the receiving PDCP entity to the COUNT value notified from the upper layer or obtained by receiving a PDCP control PDU.

Also, in step S1204, if the processing unit 502 of UE122 determines that the received MBS configuration information message includes parameters related to COUNT for the MBS session of interest, UE122 may transition from the RRC_IDLE state or the RRC_INACTIVE state to the RRC_CONNECTED state. The RRC of UE122 in the RRC_CONNECTED state may acquire the COUNT value by receiving an RRC message including a COUNT value from gNB108 via DCCH. The RRC of UE122 may notify the PDCP entity of the MRB of UE122 of the acquired COUNT value. The PDCP entity of the MRB of UE122 may set the COUNT value notified from the upper layer as the COUNT value of the receiving PDCP entity.

Furthermore, in step S1204, when the PDCP entity in the MRB of UE 122 sets the COUNT value notified from a higher layer or the COUNT value obtained by receiving a PDCP control PDU as the COUNT value of the receiving PDCP entity, it may set a state variable indicating the COUNT value of the PDCP SDU that is expected to be received next on the receiving side of the PDCP entity.Furthermore, when the PDCP entity in the MRB of UE 122 sets the COUNT value notified from a higher layer or the COUNT value obtained by receiving a PDCP control PDU as the COUNT value of the receiving PDCP entity, it may set a state variable indicating the COUNT value of the first PDCP PDU among the PDCP SDUs waiting to be received that have not been delivered to the higher layer on the receiving side of the PDCP entity. Furthermore, when the PDCP entity of the MRB of UE 122 sets the COUNT value notified from a higher layer or the COUNT value obtained by receiving a PDCP control PDU as the COUNT value of the receiving PDCP entity, the above-mentioned COUNT value may be set separately into an HFN part and an SN (Sequence Number) part.

Also, in step S1204, if the processing unit 502 of UE122 determines that the MBS session of interest does not include a parameter related to HFN and/or that the MBS session of interest does not include a parameter related to COUNT, the processing unit 502 of UE122 may determine that it is not necessary to transition to the RRC_CONNECTED state for the purpose of obtaining the HFN value and/or the COUNT value.Also, in step S1204, if the processing unit 502 of UE122 determines that the MBS session of interest does not include a parameter related to HFN and/or that the MBS session of interest does not include a parameter related to COUNT, the processing unit 502 of UE122 may receive the MBS service in the RRC_IDLE state or the RRC_INNACTIVE state without obtaining the HFN value and/or the COUNT value. Also, in step S1204, if the processing unit 502 of the UE 122 determines that the parameter related to HFN is not included in the MBS session of interest and/or if the processing unit 502 of the UE 122 determines that the parameter related to COUNT is not included in the MBS session of interest, the processing unit 502 of the UE 122 may receive the MBS service in the RRC_CONNECTED state without acquiring the value of HFN and/or the value of COUNT (step S1206).

In step S1204, the processing unit 502 of the UE 122 may determine whether the MBS configuration information message received in step S1202 includes parameters related to the status report timer for the MBS session of interest. The above-mentioned parameters related to the status report timer may be the value of the timer used for transmitting a PDCP status report. If it is determined that the received MBS configuration information message includes parameters related to the status report timer for the MBS session of interest, the processing unit 502 of the UE 122 may set the value of the timer used for transmitting the received PDCP status report. The timer used for transmitting the PDCP status report may be used by the PDCP entity of the UE 122 to detect a PDCP PDU or a PDCP PDU loss. The timer used for transmitting the PDCP status report may be a timer that runs only once per PDCP entity. Furthermore, the timer used for transmitting the PDCP status report may be started or restarted when the UE 122 detects a PDCP PDU or a PDCP PDU loss. For example, the timer used for transmitting the PDCP status report may be started or restarted based on the following conditions: the timer is not running when the PDCP in the UE 122 receives a PDCP data PDU from a lower layer; and/or the state variable indicating the COUNT value of the next PDCP SDU expected to be received (e.g., a state variable named RX_NEXT) is greater than the state variable indicating the COUNT value of the first PDCP PDU among the waiting PDCP SDUs that have not been delivered to the upper layer (e.g., a state variable named RX_DELIV). The timer used for transmitting the PDCP status report may also be stopped and/or reset when the UE 122 no longer experiences any PDCP PDU or PDCP PDU loss. For example, a timer used for transmitting a PDCP status report may be stopped and/or reset based on the timer being running and/or based on a state variable indicating a COUNT value of the next PDCP SDU expected to be received (e.g., a state variable named RX_NEXT) being equal to a state variable indicating a COUNT value of the first PDCP PDU among the waiting PDCP SDUs that have not yet been delivered to the upper layer (e.g., a state variable named RX_DELIV). The above "equal" may be rephrased as "greater than" or "equal." The above "equal" may be rephrased as "less than" or "equal." A status report of the PDCP entity in the MRB may be initiated based on expiration of the timer used for transmitting a PDCP status report. The timer used for transmitting a PDCP status report may be stopped and/or reset based on the PDCP entity being requested to suspend by the upper layer. The timer used for transmitting a PDCP status report may be stopped and/or reset based on the PDCP entity being requested to re-establish by the upper layer. Additionally, the timer used for transmitting PDCP status reports may be stopped and/or reset based on the PDCP entity being requested to be reconfigured by upper layers.

Note that an MRB may be established and/or configured for each MBS session of interest to UE122. If multiple MRBs are established and/or configured for UE122, the processing in step S1204 may be performed for the corresponding MRB.

In step S1206, before starting reception of the MBS session of interest, the processing unit 502 of the UE 122 may perform one or more MRB establishment procedures to start reception of the MBS session of interest. The MRB establishment procedure may be initiated, for example, at the start of the MBS session, when the UE 122 enters a cell in which the MBS service of interest is provided via an MRB, when the UE 122 becomes interested in the MBS service, or when a UE capability limit that inhibits reception of the MBS service is removed. The MRB establishment procedure may be performed when the UE 122 is in the RRC_IDLE state, when the UE 122 is in the RRC_INACTIVE state, or when the UE 122 is in the RRC_CONNECTED state. The MRB establishment procedure may also be initiated when the UE 122 receives, or has received, an RRC message via the DCCH from the gNB 108 indicating establishment of an MRB when the UE 122 is in the RRC_CONNECTED state. The RRC message suggesting the establishment of the MRB may include some or all of the parameters included in the MBS configuration information message in the above-mentioned step S1202. The processing unit 502 of the UE 122 may perform the MRB establishment process using configuration information including some or all of the default configuration information for each entity held by the UE 122, the parameters related to the MBS configuration included in the MBS configuration information message received via the MCCH in step S1202, and the parameters related to the MBS configuration included in the RRC message suggesting the establishment of the MRB received via the above-mentioned DCCH.

When performing the MRB establishment process, the processing unit 502 of the UE 122 may perform a process including some or all of the following processes (A) to (M).
(A) If an SDAP entity does not exist in the PDU session providing the MBS and/or in the PDU session corresponding to the parameters indicating the PDU session included in the parameters related to MBS configuration, establish and/or configure an SDAP entity.
(B) Establish a PDCP entity according to default settings for MRB establishment or according to settings received from gNB108.
(C) Establish and/or configure an RLC entity according to default settings for MRB establishment or settings received from the base station.
(D) Establish and/or configure an RLC entity of an RLC bearer that receives MBS one-to-many according to default settings for MRB establishment or settings received from the base station.
(E) Configure the logical channel of the RLC bearer that receives MBS one-to-many in the MAC entity according to the default configuration for MRB establishment or the configuration received from the base station.
(F) Associating the RLC bearer or the logical channel of the RLC bearer established and/or configured in process (D) and/or process (E) with the PDCP entity established and/or configured in process (B).
(G) Establish and/or configure an RLC entity of an RLC bearer that receives MBS one-to-one according to default settings for MRB establishment or settings received from the base station.
(H) Configure the logical channel of the RLC bearer that receives the MBS one-to-one in the MAC entity according to the default configuration for MRB establishment or the configuration received from the base station.
(I) Associate the RLC bearer or the logical channel of the RLC bearer established and/or configured in process (G) and/or process (H) with the PDCP entity established and/or configured in process (B).
(J) Associate the SDAP entity with the established MRB.
(K) Notify the upper layer of the establishment of the MRB by notifying the upper layer of information including some or all of the TMGI, Session ID, PDU Session ID, and QoS flow corresponding to the established MRB.
(L) If ciphering disabled is not configured for the PDCP entity of this MRB, configure the encryption algorithm for the PDCP entity established in step (B) and apply the master key or secondary key according to the parameter indicating whether to use the master key or secondary key.
(M) If integrity protection is configured for the PDCP entity of this MRB, configure the integrity protection algorithm for the PDCP entity established in step (B) and apply the master key or secondary key according to the parameter indicating whether to use the master key or secondary key.

When a PDCP status report is initiated in the PDCP entity of one or more MRBs, the processing unit 502 of UE 122 that has established one or more MRBs may create a PDCP status report and transmit it to gNB 108. When the processing unit 502 of UE 122 creates a PDCP status report in the PDCP entity of the MRB, it may submit the created PDCP status report to the RLC entity of the RLC bearer that is associated with the PDCP entity of the MRB and receives MBSs in a one-to-one manner, but may not submit it to the RLC entity of the RLC bearer that is associated with the PDCP entity of the MRB and receives MBSs in a one-to-many manner. The above statement "The created PDCP status report is submitted to the RLC entity of the RLC bearer associated with the PDCP entity of the MRB that receives MBS one-to-one, but does not need to be submitted to the RLC entity of the RLC bearer associated with the PDCP entity of the MRB that receives MBS one-to-many" can be rephrased as "The created PDCP status report may be submitted only to the RLC entity of the RLC bearer associated with the PDCP entity of the MRB that receives MBS one-to-one." Note that PDCP reporting in the PDCP entity of the MRB may be initiated only for MRBs for which PDCP status report transmission has been configured by the upper layer (step S1208).

Furthermore, in step S1208, when a PDCP status report is initiated in the PDCP entities of one or more MRBs, the processing unit 502 of UE122 determines whether an RLC bearer that receives MBSs one-to-one is associated with the PDCP entity of the MRB, and, based on the fact that an RLC bearer that receives MBSs one-to-one is associated with the PDCP entity of the MRB, creates a PDCP status report and submits the created status report only to the RLC entity of the RLC bearer that receives the MBSs one-to-one. Furthermore, when a PDCP status report is initiated in the PDCP entity of the MRB, the processing unit 502 of UE122 determines whether an RLC bearer that receives MBSs one-to-one is associated with the PDCP entity of the MRB, and, based on the fact that an RLC bearer that receives MBSs one-to-one is not associated with the PDCP entity of the MRB, does not need to create a PDCP status report.

Furthermore, in step S1208, if a PDCP status report is initiated in the PDCP entities of one or more MRBs, the processing unit 502 of UE122 creates a PDCP status report, determines whether an RLC bearer that receives MBSs one-to-one is associated with the PDCP entity of the MRB, and, based on the fact that an RLC bearer that receives MBSs one-to-one is associated, may submit the created PDCP status report only to the RLC entity of the RLC bearer that receives the MBSs one-to-one. Furthermore, if a PDCP status report is initiated in the PDCP entity of the MRB, the processing unit 502 of UE122 creates a PDCP status report, determines whether an RLC bearer that receives MBSs one-to-one is associated with the PDCP entity of the MRB, and, based on the fact that an RLC bearer that receives MBSs one-to-one is not associated, may not submit the created PDCP status report to lower layers. In addition, when a PDCP status report is initiated in the PDCP entity of the MRB, the processing unit 502 of the UE 122 creates a PDCP status report, determines whether an RLC bearer that receives the MBS one-to-one is associated with the PDCP entity of the MRB, and discards the created PDCP status report if an RLC bearer that receives the MBS one-to-one is not associated with the PDCP entity of the MRB.

Furthermore, the RLC entity of the RLC bearer that receives the above-mentioned MBS one-to-one may be an AM RLC entity. Furthermore, the RLC entity associated with the RLC bearer that receives the above-mentioned MBS one-to-one may be a bidirectional UM RLC entity. Furthermore, the RLC entity associated with the RLC bearer that receives the above-mentioned MBS one-to-one may be a transmitting UM RLC entity and/or a receiving UMRLC entity of a unidirectional UM RLC entity.

In step S1208, the PDCP status report may be initiated based on a request for transmission of a PDCP status report from the RRC layer or a higher layer. The above-mentioned request for transmission of a PDCP status report from the RRC layer or a higher layer may be a request for PDCP data recovery from the RRC layer or a higher layer. In step S1208, the PDCP status report may also be initiated based on one or more RLC bearers associated with the PDCP entity of the MRB being released, suspended, or deactivated. In step S1208, the PDCP status report may also be initiated based on the expiration of the above-mentioned status report timer set in step S1204 in the PDCP entity. In step S1208, the PDCP status report may also be initiated based on a switch of the RLC bearer receiving the MRB. The above-mentioned "the RLC bearer receiving the MRB has been switched" may mean that the RLC bearer receiving the MRB has been switched from an RLC bearer receiving MBS one-to-many to an RLC bearer receiving MBS one-to-one. Also, the above-mentioned "the RLC bearer receiving the MRB has been switched" may mean that the RLC bearer receiving the MRB has been switched from an RLC bearer receiving MBS one-to-one to an RLC bearer receiving MBS one-to-many.

Also, in step S1208, if the RRC message received by UE122 from gNB108 includes a parameter indicating a request for UE122 to transmit a PDCP status report to one or more MRBs of UE122, the processing unit 502 of UE122 may request the PDCP layer of UE122's MRB to transmit a PDCP status report from the RRC of UE122. Note that the above-mentioned RRC message may be an RRC message sent via a DCCH or an RRC message sent via an MCCH. Also, the parameter indicating the request for UE122 to transmit a PDCP status report to one or more MRBs may include an identifier for identifying the MRB and some or all of parameters related to MBS session information. Also, in step S1208, if UE122 receives an RRC message indicating a request for UE122 to transmit a PDCP status report from gNB108, the processing unit 502 of UE122 may request the PDCP layer of UE122's MRB to transmit a PDCP status report from the RRC of UE122. The RRC message requesting the transmission of the PDCP status report may be an RRC message sent via a DCCH or an RRC message sent via an MCCH. The RRC message requesting the transmission of the PDCP status report may include an identifier for identifying the MRB and some or all of parameters related to information about the MBS session.

In step S1208, the processing unit 502 of the UE 122 may perform a counter check process based on receiving an RRC message for counter check (counter check message) for one or more MRBs of the UE 122 from the gNB 108, and may report the result to the gNB 108 by setting it in an RRC message for counter check response (counter check response message). The RRC message for counter check may include some or all of an identifier for identifying the MRB, parameters related to MBS session information, and most significant bit (MSB) values of COUNT values in the uplink direction and/or downlink direction associated with the MRB. The RRC message for counter check may be a message from the gNB 108 to the UE 122, notifying the UE 122 of the MSB value of the current COUNT value associated with the MSB of the gNB 108 and requesting the UE 122 to report a comparison result between the MSB value of the current COUNT value associated with the MSB of the UE 122 and the MSB value of the current COUNT value associated with the MSB of the UE 122 to the gNB 108. In the counter check process, the processing unit 502 of the UE 122 may perform a process including some or all of the following processes (A) to (D) on the MRB established in the UE 122.
(A) If the MRB is a unidirectional bearer and there is no COUNT for the uplink direction and/or downlink direction, the COUNT value for the direction in which there is no COUNT value is assumed to be '0'.
(B) For an MRB in which the RRC message for counter check does not include an identifier for identifying the MRB and/or parameters related to MBS session information, the COUNT value for the uplink direction and/or downlink direction held by UE 122 is set in the RRC message for counter check response.
(C) For an MRB in which the RRC message for counter check includes the MSB value of the COUNT value for the uplink direction and/or downlink direction, if the MSB value of the received COUNT value for the uplink direction and/or downlink direction is different from the COUNT value for the uplink direction and/or downlink direction held by UE 122, the COUNT value for the uplink direction and/or downlink direction held by UE 122 is set in the RRC message for counter check response.
(D) For an MRB in which the RRC message for counter check includes an identifier for identifying the MRB and/or parameters related to MBS session information, the COUNT value for the uplink direction and/or downlink direction held by UE 122 is set in the RRC message for counter check response.

Note that in the above explanation, the MBS session of interest can be replaced with MBS session.

In the above description, the RLC bearer that receives the MBS one-to-one may also refer to the RLC bearer that transmits feedback regarding the MBS to gNB108.

Note that in the above description, the RLC bearer may be referred to as an RLC entity. Also, in the above description, the RLC bearer may be referred to as a logical channel.

Note that in the above description, the PDCP entity may be a receiving PDCP entity and/or a transmitting PDCP entity.

Note that in the above explanation, ROHC can be replaced with Ethernet Header Compression (EHC).

In this way, in an embodiment of the present invention, by making it possible to send a PDCP status report when PDCP data recovery is requested from a higher layer even in the case of UM DRB, it is possible to provide a terminal device, base station device, and method that can efficiently control MBS using NR.

The radio bearers in the above description may be some or all of the DRB, SRB, and MRB.

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

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

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

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

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

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

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

(1) A terminal device communicating with a base station device, wherein the terminal device establishes a radio bearer, the RLC entity of the radio bearer is an RLC entity in unacknowledged mode, the RLC entity of the radio bearer is linked to a PDCP entity of the radio bearer, and the PDCP entity creates a PDCP status report based on a PDCP data recovery request from an upper layer and submits the PDCP status report to the RLC entity.

(2) A method for a terminal device communicating with a base station device, wherein the terminal device establishes a radio bearer, the RLC entity of the radio bearer is an RLC entity in unacknowledged mode, the RLC entity of the radio bearer is linked to a PDCP entity of the radio bearer, and the PDCP entity creates a PDCP status report based on a PDCP data recovery request from an upper layer, and submits the PDCP status report to the RLC entity.

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

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

Furthermore, "computer-readable recording medium" may include a medium that dynamically stores a program for a short period of time, such as a communication line when transmitting a program via a network such as the Internet or a communication line such as a telephone line, or a medium that stores a program for a fixed period of time, such as volatile memory within a computer system that serves as a server or client in such cases. Furthermore, the above-mentioned program may be one that realizes some of the functions described above, or may be one that can realize the functions described above in combination with a program already stored in the computer system.

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

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

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

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

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

Claims (2)

A terminal device that communicates with a base station device,
The terminal device establishes a radio bearer, and an RLC entity of the radio bearer is an RLC entity in an unacknowledged mode;
The RLC entity of the radio bearer is associated with a PDCP entity of the radio bearer;
the PDCP entity generates a PDCP status report based on the fact that PDCP data recovery has been requested by an upper layer and that an RLC bearer that receives MBS one-to-one is associated with the PDCP entity , and submits the PDCP status report to the RLC entity;
Terminal device. A method for a terminal device communicating with a base station device, comprising:
The terminal device establishes a radio bearer, and an RLC entity of the radio bearer is an RLC entity in an unacknowledged mode;
The RLC entity of the radio bearer is associated with a PDCP entity of the radio bearer;
the PDCP entity generates a PDCP status report based on the fact that PDCP data recovery has been requested by an upper layer and that an RLC bearer that receives MBS one-to-one is associated with the PDCP entity , and submits the PDCP status report to the RLC entity;
method.