Terminal equipment, base station equipment, and method

Abstract

The present invention provides a terminal device comprising: a reception unit that receives a first message from a base station device; and a processing unit. The first message is transmitted from the base station device via MCCH. The processing unit determines that ROHC is applied to a first MBS, if setting information which is for the first MBS and which is included in the first message includes a parameter pertaining to the ROHC. The processing unit determines that the ROHC is not applied to the first MBS, if the setting information which is for the first MBS and which is included in the first message does not include a parameter pertaining to the ROHC. On the basis of the fact that the ROHC is applied to the first MBS, the processing unit acquires ROHC context for use in the first MBS.

Description

Technical Field

[0001] The present invention relates to a terminal device, a base station device, and a method. This application claims priority to Japanese Patent Application No. 2020-172374, filed on October 13, 2020, the content of which is incorporated herein by reference.

Background Art

[0002] In the 3rd Generation Partnership Project (3GPP), which is a standardization project for cellular mobile communication systems, technical studies and standardization of cellular mobile communication systems, including radio access, core network, services, etc., are being conducted.

[0003] For example, in 3GPP, E-UTRA (Evolved Universal Terrestrial Radio Access) was started for technical study and standardization as a radio access technology (RAT) for cellular mobile communication systems for the 3.9th and 4th generations. Even now, in 3GPP, technical studies and standardization of extended technologies of E-UTRA are being conducted. Note that E-UTRA is also referred to as Long Term Evolution (LTE: registered trademark), and extended technologies may also be referred to as LTE-Advanced (LTE-A) and LTE-Advanced Pro (LTE-A Pro). (Non-Patent Document 2, etc.)

[0004] Also, in 3GPP, NR (New Radio, or NR Radio access) was started for technical study and standardization as a radio access technology (RAT) for cellular mobile communication systems for the 5th generation (5G). Even now, in 3GPP, technical studies and standardization of extended technologies of NR are being conducted. (Non-Patent Document 1, etc.)

Prior Art Documents

[0005] [Non-Patent Document 1] 3GPP TS 38.300v 16.2.0,"NR;NR and NG-RAN Overall description; Stage 2" pp10-134 [Non-Patent Document 2] 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 [Overview of the Initiative] [Problems that the invention aims to solve]

[0006] As one of the technologies being considered for E-UTRA's extension, MBMS (Multimedia Broadcast Multicast Service) transmission technology has been standardized to provide multicast / broadcast services. MBMS transmission uses MBSFN (Multicast Broadcast Single Frequency Network) or SC-PTM (Single Cell Point-To-Multipoint) transmission.

[0007] Transmission using MBSFN (Multicast-Broadcast Single-Frequency Network) transmits multicast / broadcast data using PMCH (Physical Multicast Channel) on a per-cell basis within an MBSFN area (Multicast-Broadcast Single-Frequency Network) consisting of multiple cells. In contrast, transmission using SC-PTM transmits multicast data on a per-cell basis using PDSCH (Physical Downlink Shared Channel).

[0008] On the other hand, Multicast Broadcast Service (MBS) is being considered as an extension of NR technology. When implementing MBS via NR, it is necessary to consider 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 studied.

[0009] One aspect of the present invention has been made in view of the above circumstances, and one of its objectives is to provide a terminal device, a base station device, and a method that can efficiently control an MBS using NR. [Means for solving the problem]

[0010] To achieve the above objective, one aspect of the present invention employs the following means. Specifically, one aspect of the present invention is a terminal device that communicates with a base station device, comprising a receiving unit that receives a first message from the base station device and a processing unit, wherein the first message is transmitted from the base station device using a Multicast Control Channel (MCCH), and the processing unit determines that if the configuration information for a first Multicast Broadcast Service (MBS) contained in the first message includes parameters relating to Robust Header Compression (ROHC), ROHC is applied to the first MBS, and if the configuration information for the first MBS contained in the first message does not include parameters relating to ROHC, ROHC is not applied to the first MBS, and based on the application of ROHC to the first MBS, the processing unit obtains the ROHC context used for the first MBS.

[0011] Another aspect of the present invention is a base station device that communicates with a terminal device, comprising a transmitting unit that transmits a first message to the terminal device and a processing unit, wherein the base station device transmits the first message using a Multicast Control Channel (MCCH), and the processing unit causes the terminal device to determine that Robust Header Compression (ROHC) is applied to the first Multicast Broadcast Service (MBS) if the configuration information for the first MBS included in the first message includes parameters related to ROHC, and determines that ROHC is not applied to the first MBS if the configuration information for the first MBS included in the first message does not include parameters related to ROHC, and causes the terminal device to obtain an ROHC context used for the first MBS based on the determination that ROHC is applied to the first MBS.

[0012] Another aspect of the present invention is a method for a terminal device to communicate with a base station device, wherein the terminal device receives a first message from the base station device, the first message is transmitted from the base station device using a Multicast Control Channel (MCCH), and if the configuration information for a first Multicast Broadcast Service (MBS) contained in the first message includes parameters relating to Robust Header Compression (ROHC), it is determined that ROHC is applied to the first MBS; if the configuration information for the first MBS contained in the first message does not include parameters relating to ROHC, it is determined that ROHC is not applied to the first MBS, and based on the application of ROHC to the first MBS, the terminal device obtains the ROHC context used for the first MBS.

[0013] Another aspect of the present invention is a method for a base station device to communicate with a terminal device, comprising: transmitting a first message to the terminal device; transmitting the first message from the base station device using a Multicast Control Channel (MCCH); causing the terminal device to determine that Robust Header Compression (ROHC) is applied to the first Multicast Broadcast Service (MBS) if the configuration information for the first MBS included in the first message includes parameters relating to ROHC; determining that ROHC is not applied to the first MBS if the configuration information for the first MBS included in the first message does not include parameters relating to ROHC; and causing the terminal device to acquire an ROHC context used for the first MBS based on the determination that ROHC is applied to the first MBS.

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

[0015] According to one aspect of the present invention, terminal equipment, base station equipment, and methods can achieve efficient MBS control using NR. [Brief explanation of the drawing]

[0016] [Figure 1] A schematic diagram of a communication system according to an embodiment of the present invention. [Figure 2] A diagram showing an example of the E-UTRA protocol configuration according to an embodiment of the present invention. [Figure 3] A diagram showing an example of the NR protocol configuration according to the present invention. [Figure 4] A diagram showing an example of a procedure flow for various settings in an RRC according to an embodiment of the present invention. [Figure 5] Block diagram showing the configuration of the terminal device in an embodiment of the present invention. [Figure 6] Block diagram showing the configuration of the base station device in an embodiment of the present invention. [Figure 7] An example of an ASN.1 description included in a message related to RRC connection reconfiguration in NR in an embodiment of the present invention. [Figure 8] An example of an ASN.1 description included in a message related to RRC connection reconfiguration in E-UTRA in an embodiment of the present invention. [Figure 9] Diagram showing the flow of procedures for setting up MBMS reception using SC-PTM. [Figure 10] Diagram showing an example of an ASN.1 description representing fields and / or information elements included in SIB20 (System Information Block Type 20). [Figure 11] Diagram showing an example of an ASN.1 description representing fields and / or information elements included in the SC-PTM configuration message (SCPTMConfiguration). [Figure 12] Diagram showing an example of the flow of MBS reception procedures in NR in an embodiment of the present invention.

Embodiments for Carrying Out the Invention

[0017] Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

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

[0019] In the embodiments of the present invention, the names of each node and entity, and the processing at each node and entity, will be described when the wireless access technology is E-UTRA or NR. However, the embodiments of the present invention may be used with other wireless access technologies. The names of each node and entity in the embodiments of the present invention may be different.

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

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

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

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

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

[0025] 5GC110 may be the core network. Interface 116 is the interface between gNB108 and 5GC110 and may be called the NG interface. Interface 116 may have a control plane interface through which control signals pass, and / or a user plane interface through which user data passes. The control plane interface of interface 116 may be terminated by the Access and Mobility Management Function (AMF: not shown) in 5GC110. The user plane interface of interface 116 may be terminated by the User Plane Function (UPF: not shown) in 5GC110. The control plane interface of interface 116 may be called the NG-C interface. The user plane interface of interface 116 may be called the NG-U interface.

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

[0027] eNB102 may have the function to connect to 5GC110. eNB102 having the function to connect to 5GC110 may be called ng-eNB. Interface 114 is the interface between eNB102 and 5GC110 and may be called NG interface. Interface 114 may have a control plane interface through which control signals pass, and / or a user plane interface through which user data passes. The control plane interface of interface 114 may be terminated at the Access and Mobility Management Function (AMF: not shown) in 5GC110. The user plane interface of interface 114 may be terminated at the User Plane Function (UPF: not shown) in 5GC110. The control plane interface of interface 114 may be called NG-C interface. The user plane interface of interface 114 may be called NG-U interface. A wireless access network consisting of ng-eNB or gNB may be called NG-RAN. NG-RAN, E-UTRAN, eNB, ng-eNB, and gNB may simply be called a network.

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

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

[0030] Interface 124 is the interface between EPC104 and 5GC110, and may be an interface that passes only CP, only UP, or both CP and UP. In addition, 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.

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

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

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

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

[0035] EPC104 does not need to have PDU sessions and / or QoS flows. Similarly, 5GC110 does not need to have an EPS bearer. When UE122 is connected to EPC104, UE122 will have information about the EPS bearer, but it does not need to have information about the PDU sessions and / or QoS flows. Similarly, when UE122 is connected to 5GC110, UE122 will have information about the PDU sessions and / or QoS flows, but it does not need to have information about the EPS bearer.

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

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

[0038] Figure 2(A) is a diagram of the E-UTRA user plane (UP) protocol stack. As shown in Figure 2(A), the E-UTRA UP protocol may be a protocol between UE122 and eNB102. That is, the E-UTRA UP protocol may be a protocol that terminates at eNB102 on the network side. As shown in Figure 2(A), the E-UTRA user plane protocol stack may consist of a radio physical layer (PHY) 200, a medium access control layer (MAC) 202, a radio link control layer (RLC) 204, and a packet data convergence protocol layer (PDCP) 206.

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

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

[0041] 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, the RRC308, which is the radio resource control layer, may be the protocol between the UE122 and the gNB108. That is, the RRC308 may be a protocol that terminates at the gNB108 on the network side. Also, in the E-UTRAN CP protocol, the NAS312, which is a non-AS layer, may be the protocol between the UE122 and the AMF. That is, the NAS312 may be a protocol that terminates at the AMF on the network side.

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

[0043] In the embodiments of the present invention, the E-UTRA protocol and the NR protocol are not distinguished below, and the terms PHY (PHY layer), MAC (MAC layer), RLC (RLC layer), PDCP (PDCP layer), RRC (RRC layer), and NAS (NAS layer) may be used. In this case, PHY (PHY layer), MAC (MAC layer), RLC (RLC layer), PDCP (PDCP layer), RRC (RRC layer), and NAS (NAS layer) may be the PHY (PHY layer), MAC (MAC layer), RLC (RLC layer), PDCP (PDCP layer), RRC (RRC layer), and NAS (NAS layer) of the E-UTRA protocol, or the PHY (PHY layer), MAC (MAC layer), RLC (RLC layer), PDCP (PDCP layer), RRC (RRC layer), and NAS (NAS layer) of the NR protocol. Furthermore, SDAP (SDAP layer) may be the SDAP (SDAP layer) of the NR protocol.

[0044] Furthermore, in embodiments of the present invention, when distinguishing between the E-UTRA protocol and the NR protocol, PHY200, MAC202, RLC204, PDCP206, and RRC208 may be referred to as E-UTRA PHY or LTE PHY, E-UTRA MAC or LTE MAC, E-UTRA RLC or LTE RLC, E-UTRA PDCP or LTE PDCP, and E-UTRA RRC or LTE RRC, respectively. Also, PHY200, MAC202, RLC204, PDCP206, and RRC208 may be described as E-UTRA PHY or LTE PHY, E-UTRA MAC or LTE MAC, E-UTRA RLC or LTE RLC, E-UTRA PDCP or LTE PDCP, and E-UTRA RRC or LTE RRC, respectively. Furthermore, when distinguishing between the E-UTRA protocol and the NR protocol, PHY300, MAC302, RLC304, PDCP306, and RRC308 are sometimes referred to as NR PHY, NR MAC, NR RLC, NR RLC, and NR RRC, respectively. Also, PHY200, MAC302, RLC304, PDCP306, and RRC308 may be described as NR PHY, NR MAC, NR RLC, NR PDCP, and NR RRC, respectively.

[0045] This section describes entities in the AS layer of E-UTRA and / or NR. Entities that possess some or all of the functions of the MAC layer may be called MAC entities. Entities that possess some or all of the functions of the RLC layer may be called RLC entities. Entities that possess some or all of the functions of the PDCP layer may be called PDCP entities. Entities that possess some or all of the functions of the SDAP layer may be called SDAP entities. Entities that possess some or all of the functions of the RRC layer may be called RRC entities. MAC entities, RLC entities, PDCP entities, SDAP entities, and RRC entities may be replaced with MAC, RLC, PDCP, SDAP, and RRC, respectively.

[0046] Furthermore, the data provided from MAC, RLC, PDCP, and SDAP to lower layers, and / or the data provided from lower layers to MAC, RLC, PDCP, and SDAP, may be referred to as MAC PDU (Protocol Data Unit), RLC PDU, PDCP PDU, and SDAP PDU, respectively. Also, the data provided from higher layers to MAC, RLC, PDCP, and SDAP, and / or the data provided from MAC, RLC, PDCP, and SDAP to higher layers, may be referred to as MAC SDU (Service Data Unit), RLC SDU, PDCP SDU, and SDAP SDU, respectively. In addition, a segmented RLC SDU may be referred to as an RLC SDU segment.

[0047] An example of PHY functionality is described below. The terminal device's PHY may have the function of receiving data transmitted from the base station device's PHY via the Downlink (DL) physical channel. The terminal device's PHY may also have the function of transmitting data to the base station device's PHY via the Uplink (UL) physical channel. The PHY may be connected to the higher-level MAC via a Transport Channel. The PHY may transfer data to the MAC via the Transport Channel. The PHY may also receive data from the MAC via the Transport Channel. In the PHY, an RNTI (Radio Network Temporary Identifier) ​​may be used to identify various control information.

[0048] Now, let's discuss physical channels.

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

[0050] 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)

[0051] PBCH may be used to broadcast system information required by terminal devices.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0065] MTCH (Multicast Traffic Channel) may be a point-to-multipoint downlink channel for transmitting data from a base station 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.

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

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

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

[0069] This section describes the mapping between logical channels and transport channels for uplinks in E-UTRA and / or NR.

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

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

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

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

[0074] BCCH may be mapped to a downlink transport channel, which is a BCH (Broadcast Channel) and / or DL-SCH (Downlink Shared Channel).

[0075] PCCH may be mapped to PCH (Paging Channel), which is a downlink transport channel.

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

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

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

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

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

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

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

[0083] An example of RLC functionality is described below. RLC may be called an RLC sublayer. E-UTRA RLC may have the function of segmenting and / or concatenating data provided from the upper layer PDCP and providing it to the lower layer. E-UTRA RLC may have the function of reassembling and reordering data provided from the lower layer and providing it to the upper layer. NR RLC may have the function of adding a sequence number to data provided from the upper layer PDCP that is independent of the sequence number added by the PDCP. NR RLC may also have the function of segmenting the data provided from the PDCP and providing it to the lower layer. NR RLC may also have the function of reassembling data provided from the lower layer and providing it to the upper layer. RLC may also have a data retransmission function and / or automatic repeat request (ARQ) function. RLC may also have a function to perform error correction using ARQ. The control information sent from the receiver to the transmitter of RLC to perform ARQ, indicating data that needs to be retransmitted, may be called a status report. The instruction to send a status report sent from the transmitter to the receiver of RLC may be called a poll. RLC may also have a function to detect data duplication. RLC may also have a function to discard data. RLC may have three modes: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). In TM, data received from the upper layer is not split, and an RLC header is not required. A TM RLC entity is a unidirectional entity and may be configured as a transmitting TM RLC entity or a receiving TM RLC entity.UM performs data splitting and / or merging, adds an RLC header, etc., received from higher layers, but does not need to control data retransmission. UM RLC entities may be unidirectional or bidirectional. If a UM RLC entity is unidirectional, it may be configured as a transmitting UM RLC entity or a receiving UM RLC entity. If a UM RLC entity is bidirectional, it may be configured as a UM RLC entity consisting of a transmitting side and a receiving side. AM performs data splitting and / or merging, adds an RLC header, and controls data retransmission, etc., received from higher layers. AM RLC entities are bidirectional entities and may be configured as AM RLC consisting of a transmitting side and a receiving side. Data provided to lower layers by TM, and / or data provided from lower layers, may be called TMD PDUs. Furthermore, data provided to lower layers by UM, and / or data provided by lower layers, may be called UMD PDUs. Similarly, data provided to lower layers by AM, or data provided by lower layers, may be called AMD PDUs. The RLC PDU format used in E-UTRA RLC and the RLC PDU format used in NR RLC may be different. Additionally, there may be data RLC PDUs and control RLC PDUs. Data RLC PDUs may be called RLC DATA PDUs (RLC Data PDUs). Similarly, control RLC PDUs may be called RLC CONTROL PDUs (RLC Control PDUs).

[0084] This section describes some examples of PDCP functionality. PDCP may be referred to as the PDCP sublayer. PDCP may have a function for maintaining sequence numbers. PDCP may also have a header compression / decompression function for efficiently transmitting user data such as IP packets and Ethernet frames over the wireless section. The protocol used for compressing and decompressing IP packet headers may be called the ROHC (Robust Header Compression) protocol. The protocol used for compressing and decompressing Ethernet frame headers may be called the EHC (Ethernet® Header Compression) protocol. PDCP may also have data encryption / decryption functionality. PDCP may also have data integrity protection / verification functionality. PDCP may also have a re-ordering function. PDCP may also have a PDCP SDU retransmission function. PDCP may also have a data discard function using a discard timer. PDCP may also have a multiplexing function. Furthermore, PDCP may have a function to discard duplicate received data. A PDCP entity is a bidirectional entity and may consist of a transmitting PDCP entity and a receiving PDCP entity. The PDCP PDU format used in E-UTRA PDCP and the PDCP PDU format used in NR PDCP may be different. In addition, there may be data PDCP PDUs and control PDCP PDUs. A data PDCP PDU may be called a PDCP DATA PDU (PDCP Data PDU). A control PDCP PDU may be called a PDCP CONTROL PDU (PDCP Control PDU).

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

[0086] Furthermore, in PDCP, reordering may be defined as the process of storing PDCP SDUs in a receive buffer (reordering buffer) and passing the PDCP SDUs to the upper layer in the order of the COUNT values ​​obtained from the header information of the PDCP DATA PDU. 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 passed to the upper layer, the stored PDCP SDUs may be passed to the upper layer in the order of their 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 to a PDCP SDU and stored in the reordering buffer. All lost PDCP DATA PDUs may then be received, converted to PDCP SDUs, and then passed to the upper layer. In reordering, a reordering timer (a timer named t-Reordering) may be used to detect the loss of PDCP data PDUs. In addition, some or all of the following state variables (A) to (F) may be used for reordering. (A) A state variable in the receiving PDCP entity that indicates the COUNT value of the next PDCP SDU expected to be received. This state variable may be named RX_NEXT. (B) A state variable in the receiving PDCP entity that indicates the sequence number of the next PDCP SDU that is expected to be received. This state variable may be named Next_PDCP_RX_SN. (C) A state variable in this PDCP entity that represents the HFN value used to generate the COUNT value for the received PDCP PDU. This state variable may be named RX_HFN. (D) A state variable in the receiving PDCP entity that indicates the COUNT value of the first PDCP PDU among the PDCP SDUs waiting to be received that have not been delivered to the upper layer. This state variable may be named RX_DELIV. (E) A state variable in the receiving PDCP entity that indicates the sequence number of the PDCP PDU of the PDCP SDU that was last delivered to the upper layer. This state variable may be named Last_Submitted_PDCP_RX_SN. (F) A state variable in the receiving PDCP entity that indicates the next COUNT value after the COUNT value of the PDCP PDU that started the reordering timer. This state variable may be named RX_REORD or Reordering_PDCP_RX_COUNT.

[0087] This section describes status reporting in PDCP. In a DRB (AM DRB: Acknowledged Mode Data Radio Bearer) using an Acknowledged Mode RLC, where the transmission of PDCP status reports is configured from the upper layer, a receiving PDCP entity may trigger a PDCP status report when any of the following conditions (A) to (D) are met. Also, in a DRB (UM DRB: Unacknowledged Mode Data Radio Bearer) using an Unacknowledged Mode RLC, where the transmission of PDCP status reports is configured from the upper layer, a 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.

[0088] When the transmission of a PDCP status report is triggered, the receiving PDCP entity may create a PDCP status report. The creation of the PDCP status report may be performed by storing information about the PDCP SDUs awaiting reception, including the COUNT value of the first PDCP SDU among the PDCP SDUs awaiting reception that have not been distributed to the upper layer, in the PDCP control PDU for the PDCP status report. The receiving PDCP entity that has created the PDCP status report may submit the created PDCP status report to the lower layer via the transmitting PDCP entity.

[0089] In the embodiments of the present invention, a PDCP entity of a UM DRB configured to send PDCP status reports from a higher layer may determine that a request for PDCP data recovery has been received from the higher layer. The PDCP entity of the UM DRB, having determined that a request for PDCP data recovery has been received from the higher layer, 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 the lower layer via the transmitting PDCP entity. The lower layer may be the UM RLC entity of the RLC bearer associated with the PDCP entity. In the embodiments of the present invention, a PDCP entity of a UM DRB configured to send PDCP status reports from a higher layer may determine that a request for PDCP data recovery has been received from the higher layer only if the UM DRB is not a DAPS bearer. A DAPS bearer may be a bearer to which one or more RLC entities for source cells and one or more RLC entities for target cells are associated with the PDCP entity. Furthermore, the aforementioned PDCP data recovery may have a different name, meaning a request from a higher layer to the PDCP to send a status report.

[0090] ROHC will now be described. In embodiments of the present invention, ROHC may be replaced with ROHC protocol. ROHC may have functions for 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. The compressor may perform header compression using a context held by the compressor. The decompressor may perform header decompression using a context held by the decompressor. In embodiments of the present invention, context may be replaced with ROHC context. The context in the decompressor may be generated by receiving all header information from the compressor. Contexts in the compressor and decompressor may be held for each IP flow. A context identifier (CID) may be used to identify the context. Information such as the maximum value of the context identifier and profile information indicating the header compression / decompression method may be negotiated between the compressor and decompressor before header compression / decompression is performed.

[0091] In ROHC, header information may be classified into static parts and dynamic parts. The static part of header information in ROHC may be the information in the header of each packet belonging to an IP flow that hardly changes. For example, the static part of header information in ROHC may include the source address, destination address, and version in IPv4 and IPv6 headers, and the source port and destination port in UDP and TCP headers. The dynamic part of header information in ROHC may be the information in the header of each packet belonging to an IP flow that can change from packet to packet. For example, the dynamic part of header information in ROHC may include the traffic class and hop limit in IPv6 headers, the Type of service and Time to Live in IPv4 headers, the checksum in UDP headers, and the RTP sequence number and RTP timestamp in RTP headers.

[0092] A ROHC compressor may have three states: IR (Initialization and Refresh), FO (First Order), and SO (Second Order). When the IR state is used, the compressor may send all header information to the decompressor without compressing it. When the FO state is used, the compressor may compress most of the static portion of the header information to be compressed, sending some static and dynamic portions uncompressed to the decompressor. When the SO state is used, the header compression ratio is maximized, and the compressor may send only limited information, such as the RTP sequence number.

[0093] The ROHC decompressor may have 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 the header decompression is performed correctly, the decompressor may transition to the FC state. If header decompression fails repeatedly in the FC state, the decompressor may transition to the SC state or the NC state.

[0094] There may be three processing modes for ROHC: U-mode (Unidirectional mode), O-mode (Bidirectional Optimistic mode), and R-mode (Bidirectional Reliable mode). In U-mode, ROHC feedback packets do not need to be used. In U-mode, the transition from low compression mode to high compression mode in the compressor, i.e., the transition from the IR state to the FO state, and / or the transition from the FO state to the SO state, and / or the transition from the IR state to the 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 the SO state to the FO state, and / or the transition from the FO state to the IR state, and / or the transition from the SO state to the IR state, may be performed at regular intervals, thereby periodically sending the information necessary for header decompression to the decompressor. In O-mode, the decompressor may request a context update from the compressor by sending ROHC feedback packets to the compressor. In R-mode, the compressor may transition from low-compression mode to high-compression mode upon receiving a header decompression success notification via an ROHC feedback packet from the decompressor. Also in R-mode, the compressor may transition from high-compression mode to low-compression mode upon receiving a context update request via an ROHC feedback packet from the decompressor. The ROHC processing mode may start from U-mode. The decompressor may decide the transition of the ROHC processing mode. The decompressor may use an ROHC feedback packet to prompt the compressor to transition the processing mode.

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

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

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

[0098] RRC messages sent using BCCH may include, for example, a Master Information Block (MIB), a System Information Block (SIB) of each type, or other RRC messages. RRC messages sent using PCCH may include, for example, a paging message or other RRC messages.

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

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

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

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

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

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

[0105] Furthermore, the layers above the AS layer of the terminal device (not shown) may include the IP layer, and above the IP layer, the TCP (Transmission Control Protocol) layer, UDP (User Datagram Protocol) layer, etc. Also, the Ethernet layer may exist above the AS layer of the terminal device. The layer above the AS layer of the terminal device may be called the PDU layer. The PDU layer may include the IP layer, TCP layer, UDP layer, Ethernet layer, etc. Above the IP layer, TCP layer, UDP layer, Ethernet layer, PDU layer, etc., there may be an application layer. The application layer may include SIP (Session Initiation Protocol) and SDP (Session Description Protocol) used in IMS (IP Multimedia Subsystem), one of the service networks standardized by 3GPP. Also, 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. Also, the application layer may include codecs for various media. Furthermore, the RRC layer may be a higher layer than the SDAP layer.

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

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

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

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

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

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

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

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

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

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

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

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

[0118] The wireless bearer will be described below. For E-UTRA, SRB0 to SRB2 may be defined, or other SRBs may be defined. For NR, SRB0 to SRB3 may be defined, or other SRBs may be defined. SRB0 may be an SRB for RRC messages that are transmitted and / or received using the logical channel CCCH. SRB1 may be an SRB for RRC messages and for NAS messages before SRB2 is established. RRC messages transmitted and / or received using SRB1 may include piggybacked NAS messages. The logical channel DCCH may be used for all RRC and NAS messages transmitted and / or received using SRB1. SRB2 may be an SRB for NAS messages and for RRC messages containing logged measurement information. The logical channel DCCH may be used for all RRC and NAS messages transmitted and / or received using SRB2. Furthermore, SRB2 may have a lower priority than SRB1. SRB3 may be an SRB for transmitting and / or receiving specific RRC messages when EN-DC, NGEN-DC, NR-DC, etc., are configured on the terminal device. All RRC and NAS messages transmitted and / or received using SRB3 may use the logical channel DCCH. Other SRBs may be provided for other purposes. DRB may be a wireless bearer for user data. RRC messages transmitted and / or received using DRB may use the logical channel DTCH.

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

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

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

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

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

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

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

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

[0127] In Figure 4, the base station device creates an RRC message (step S400). The creation of an RRC message by the base station device may be done in order for the base station device to distribute broadcast information (SI: System Information) or paging information. The creation of an RRC message by the base station device may also be done in order for the base station device to perform processing on a specific terminal device. Processing to be performed on a specific terminal device may include, for example, security settings, RRC connection reconfiguration, handover to a different RAT, suspension of RRC connection, and release of RRC connection. RRC connection reconfiguration processing may include, for example, control of radio bearers (establish, change, release, etc.), control of cell groups (establish, add, change, release, etc.), measurement settings, handover, security key update, etc. The creation of an RRC message by the base station device may also be done in order to respond to an RRC message sent from a terminal device. Responses to RRC messages sent from a terminal device may include, for example, responses to RRC setup requests, responses to RRC reconnection requests, and responses to RRC restart requests. RRC messages contain parameters for various information notifications and settings. These parameters may be called fields and / or information elements and may be described using the ASN.1 (Abstract Syntax Notation One) notation scheme. In embodiments of the present invention, parameters may also be referred to as information.

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

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

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

[0131] Furthermore, not only when using MR-DC, the RRC message for E-UTRA sent from eNB102 to UE122 may include an RRC message for NR, and the RRC message for NR sent from gNB108 to UE122 may include an RRC message for E-UTRA.

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

[0133] In Figure 7, the information element represented by RadioBearerConfig may be an information element used for setting, changing, releasing, etc., of radio bearers such as SRB and DRB. The information element represented by RadioBearerConfig may include the PDCP setting information element and SDAP setting information element described later. The information element represented by RadioBearerConfig may be rephrased as a radio bearer setting information element or radio bearer setting. The information element represented by SRB-ToAddMod, which is included in the information element represented by RadioBearerConfig, may be an information element indicating SRB (signaling radio bearer) settings. The information element represented by SRB-ToAddMod may be rephrased as an SRB setting information element or SRB setting. Also, the information element represented by SRB-ToAddModList may be a list of SRB settings. The information element represented by DRB-ToAddMod, which is included in the information element represented by RadioBearerConfig, may be an information element indicating DRB (data radio bearer) settings. The information element represented by DRB-ToAddMod may be rephrased as a DRB setting information element or DRB setting. The information element represented by DRB-ToAddModList may be a list of DRB settings. Note that SRB settings and DRB settings may also be referred to as wireless bearer settings.

[0134] The field represented by srb-Identity within the SRB configuration information element contains information about the SRB identifier (SRB Identity) of the SRB being added or modified, and may be an identifier that uniquely identifies the SRB on each terminal device. The field represented by srb-Identity within the SRB configuration information element may be referred to as the SRB identifier field or SRB identifier. The SRB identifier may also be referred to as the wireless bearer identifier.

[0135] The field represented by drb-Identity within the DRB configuration information element contains information about the DRB identifier (DRB Identity) of the DRB being added or modified, and may be an identifier that uniquely identifies the DRB on each terminal device. The field represented by drb-Identity within the DRB configuration information element may also be referred to as the DRB identifier field or DRB identifier. In the example in Figure 7, the value of the DRB identifier is an integer value from 1 to 32, but it may take a different value. 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 wireless bearer identifier.

[0136] The field represented by cnAssociation in the DRB configuration information element may be a field indicating whether the wireless bearer is associated with the field represented by eps-bearerIdentity (described later) or with the information element represented by SDAP-Config (described later). The field represented by cnAssociation may be rephrased as the core network association field or core network association. The field represented by cnAssociation may include the EPS bearer identifier field (eps-bearerIdentity) described later when the terminal device is connected to EPC104. The field represented by cnAssociation may also include the information element (SDAP-Config) indicating the SDAP configuration described later when the terminal device is connected 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 rephrased as the EPS bearer identifier field or EPS bearer identifier.

[0137] The information elements represented by SDAP-Config may also be information related to the configuration or reconfiguration of an SDAP entity. The information elements represented by SDAP-Config may be referred to as SDAP configuration information elements or SDAP configurations.

[0138] The field indicated by "pdu-session" in the SDAP configuration information element may be the PDU session identifier of the PDU session to which the QoS flow mapped to the relevant wireless 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 a PDU session. Furthermore, the relevant wireless bearer may be the DRB associated with the DRB identifier in the DRB configuration that includes this SDAP configuration field.

[0139] The field indicated by `mappedQoS-FlowsToAdd` in the SDAP configuration information element may be information indicating a list of QoS flow identifier (QFI: QoSFlow Identity) fields of uplink QoS flows to be additionally mapped to the relevant wireless bearer. The field indicated by `mappedQoS-FlowsToAdd` may be rephrased as the QoS flow field to be added or the QoS flow to be added. The aforementioned QoS flow may be the QoS flow of the PDU session indicated by the PDU session included in this SDAP configuration information element. The relevant wireless bearer may be the DRB associated with the DRB identifier in the DRB configuration that includes this SDAP configuration field.

[0140] Furthermore, the field indicated by `mappedQoS-FlowsToRelease` in the SDAP configuration information element may be information indicating a list of QoS flow identifier information elements of QoS flows whose correspondence is to be released from among the QoS flows mapped to the relevant wireless bearer. The field indicated by `mappedQoS-FlowsToRelease` may be rephrased as the QoS flow field to be released or the QoS flow to be released. The QoS flow mentioned above may be the QoS flow of the PDU session indicated by the PDU session included in this SDAP configuration information element. Also, the relevant wireless bearer may be the DRB associated with the DRB identifier in the DRB configuration that includes this SDAP configuration field.

[0141] The SDAP configuration information element may also include fields indicating whether or not an uplink SDAP header exists in the uplink data transmitted via the relevant wireless bearer, fields indicating whether or not a downlink SDAP header exists in the downlink data received via the relevant wireless bearer, and fields indicating whether or not the relevant wireless bearer is the default wireless bearer (default DRB). The relevant wireless bearer may be the DRB associated with the DRB identifier in the DRB configuration that includes this SDAP configuration field.

[0142] Furthermore, the information elements represented by PDCP-Config within the SRB configuration information elements and DRB configuration information elements may also be information elements related to the configuration of an NR PDCP entity. The information elements represented by PDCP-Config may be referred to as PDCP configuration information elements or PDCP configurations. Information elements related to the configuration of an NR PDCP entity may include fields indicating the size of the uplink sequence number, fields indicating the size of the downlink sequence number, fields indicating the RObust Header Compression (ROHC) profile, and fields indicating the value of the re-ordering timer.

[0143] The information element represented by DRB-ToReleaseList, which is included in the information element represented by RadioBearerConfig, may contain information indicating one or more DRB identifiers to be released.

[0144] In Figure 8, the information element represented by RadioResourceConfigDedicated may be an information element used for setting, changing, releasing, etc., the radio bearer. The information element represented by SRB-ToAddMod, which is included in the information element represented by RadioResourceConfigDedicated, may be information indicating the SRB (Signaling Radio Bearer) setting. The information element represented by SRB-ToAddMod may be rephrased as the SRB setting information element or SRB setting. The information element represented by SRB-ToAddModList may be a list of information indicating the SRB setting. The information element represented by DRB-ToAddMod, which is included in the information element represented by RadioResourceConfigDedicated, may be information indicating the DRB (Data Radio Bearer) setting. The information element represented by DRB-ToAddMod may be rephrased as the DRB setting information element or DRB setting. The information element represented by DRB-ToAddModList may be a list of information indicating the DRB setting. Note that SRB setting, DRB setting, or any or all of them may be referred to as radio bearer setting.

[0145] The field represented by srb-Identity within the SRB configuration information element contains information about the SRB identifier (SRB Identity) of the SRB being added or modified, and may be an identifier that uniquely identifies the SRB on each terminal device. The field represented by srb-Identity within the SRB configuration information element may be referred to as the SRB identifier field or SRB identifier. The SRB identifier may also be referred to as the wireless bearer identifier. The SRB identifier in Figure 8 may have the same role as the SRB identifier in Figure 7.

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

[0147] The field represented by eps-BearerIdentity within 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 be referred to as the EPS bearer identifier field or EPS bearer identifier. In the example in Figure 8, the value of the EPS bearer identifier is an integer value from 1 to 15, but it may take 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.

[0148] Furthermore, the information elements represented by PDCP-Config within the SRB configuration information elements and DRB configuration information elements may be information elements related to the configuration of the E-UTRA PDCP entity. The information elements represented by PDCP-Config may be referred to as PDCP configuration information elements or PDCP configurations. Information elements related to the configuration of the E-UTRA PDCP entity may include fields indicating the size of the sequence number, fields indicating the profile of RObust Header Compression (ROHC), and fields indicating the value of the re-ordering timer.

[0149] Furthermore, the SRB configuration information elements shown in Figure 8 may include fields related to E-UTRA RLC entity settings (not shown). The fields related to E-UTRA RLC entity settings may be referred to as RLC setting fields or RLC settings. Also, the SRB configuration information elements shown in Figure 8 may include information elements related to logical channel settings (not shown). The information elements related to logical channel settings may be referred to as logical channel setting information elements or logical channel settings.

[0150] Furthermore, the DRB configuration information elements shown in Figure 8 may also include information elements related to E-UTRA RLC entity configuration (not shown). The information elements related to E-UTRA RLC entity configuration may be referred to as RLC configuration information elements or RLC configuration. In addition, the DRB configuration information elements 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 logical channel identifier field or logical channel identifier. Furthermore, the DRB configuration information elements shown in Figure 8 may also include information elements related to logical channel configuration (not shown). The information elements related to logical channel configuration may be referred to as logical channel configuration information elements or logical channel configuration. Note that the logical channel identifier may be linked to the wireless bearer identifier.

[0151] The information element represented by DRB-ToReleaseList, which is included in the information element represented by RadioResourceConfigDedicated, may contain information indicating one or more DRB identifiers to be released.

[0152] In NR, information elements related to RLC bearer settings, such as information elements related to NR RLC entity settings for each radio bearer, information elements indicating logical channel identifier (identity: ID) information, and information elements related to logical channel settings, may be included in the cell group setting information elements (not shown) rather than being represented by the RadioBearerConfig in Figure 7. The cell group setting information elements may be included in the message regarding the reconfiguration of the RRC connection. The cell group setting information elements may be rephrased as cell group setting information elements or cell group settings. The NR RLC entity setting information elements may be rephrased as RLC setting information elements or RLC settings. The information elements indicating logical channel identifier information may be rephrased as logical channel identifier information elements or logical channel identifiers. The logical channel identifier may be associated with the radio bearer identifier.

[0153] 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 the message regarding the reconfiguration of the RRC connection as needed and under certain conditions. In addition to information elements related to the wireless bearer configuration, the message regarding the reconfiguration of the RRC connection may also include fields that indicate that the full configuration is applied. The field that indicates that the full configuration is applied may be represented by an information element name such as fullConfig, and may use true, enable, etc. to indicate that the full configuration is applied.

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

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

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

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

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

[0159] Figures 9 to 11 illustrate the overview of MBMS transmission / reception operation using SC-PTM. Note that the terms MBMS, MBMS service, and MBMS session used in the following explanation may be synonymous and interchangeable.

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

[0161] As shown in Figure 9, the processing unit 602 of eNB102 creates an RRC message, SIB20 (System Information Block type 20), and transmits it to UE122 via BCCH from the transmitting unit 600. The receiving unit 500 of UE122 receives SIB20. (Step S900).

[0162] SIB20 includes information necessary for obtaining control information (specifically, SC-MCCH) related to MBMS transmission using SC-PTM. For example, SIB20 includes fields such as sc-mcch-ModificationPeriod, which indicates the period during which the contents of SC-MCCH may be changed; sc-mcch-RepetitionPeriod, which indicates the transmission (retransmission) time interval of SC-MCCH in terms of the number of radio frames; sc-mcch-Offset, which indicates the offset of the radio frame in which SC-MCCH is scheduled; sc-mcch-FirstSubframe, which indicates the subframe in which SC-MCCH is scheduled; sc-mcch-duration, which indicates the duration of the subframe in which SC-MCCH is scheduled; and / or some or all of the information elements.

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

[0164] SC-PTM configuration information includes control information applicable to MBMS reception. For example, SC-PTM configuration information includes fields such as sc-mtch-InfoList, which contains the settings for each SC-MTCH in the cell transmitting the information, and scptm-NeighbourCellList, which is a list of neighboring cells providing MBMS, and / or some or all of the information elements.

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

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

[0167] The processing unit 502 of UE122 receives the MBMS session via the established SC-MRB in accordance with the SC-PTM setting message described above (step S906). Prior to receiving the MBMS session, the processing unit 502 of UE122 may create an MBMS Interest Indication message to notify eNB102 that it is interested in receiving or will receive MBMS services via SC-MRB, and send it to eNB102 from the transmission unit 504 (not shown). The MBMS Interest Indication message may include information on whether to prioritize MBMS service reception over unicast reception. The MBMS Interest Indication 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 Indication message may also be sent when SIB20 is received during a handover, or when SIB20 is received during the re-establishment of the RRC connection.

[0168] The processing unit 502 of UE122 may perform SC-MRB release processing to stop receiving MBMS sessions (step S908). SC-MRB release processing may be initiated, for example, when stopping a received MBMS session, when leaving a cell where SC-MRB is established, when interest in MBMS services is lost, or when reception of MBMS services is suppressed due to the limits of UE capabilities. SC-MRB release processing may be performed when UE122 is in the RRC_IDLE state or when UE122 is in the RRC_CONNECTED state. When performing SC-MRB release processing, the processing unit 502 of UE122 may perform some or all of the following processes (A) to (B). (A) Release the SC-MRB RLC entities and associated MAC and physical layer settings. (B) The release of the SC-MRB is notified to the upper layer by sending the tmgi and sessionId corresponding to the released SC-MRB.

[0169] The above outlines the operation of setting up MBMS reception using SC-PTM. In addition to MBMS transmission from base station equipment and MBMS reception at terminal equipment using SC-PTM (hereinafter referred to as MBMS transmission / reception), MBMS transmission / reception using MBSFN has also been standardized. However, both MBMS transmission / reception using SC-PTM and MBSFN use E-UTRA as the RAT. Multicast Broadcast Service (MBS) transmission / reception using NR as the RAT has not yet been standardized.

[0170] An example of the operation of UE122 and gNB108 in an embodiment of the present invention will be explained using Figure 12. Note that the terms MBS, MBS service, MBS session, and MBS bearer used in the embodiment of the present invention may be equivalent in meaning and may be interchangeable. Furthermore, the terms MBS, MBS service, and MBS session used in the embodiment of the present invention may also be equivalent in meaning to MBMS, MBMS service, and MBMS session. In the embodiment of the present invention, an MBS radio bearer may be established and / or configured in UE122 for MBS reception. Similarly, an MBS radio bearer may be established and / or configured in gNB108 for MBS transmission. In the embodiment of the present invention, the MBS radio bearer is described using the name MRB (Multicast Radio Bearer), but it may be referred to by another name. Furthermore, in embodiments of the present invention, the MRB established and / or configured in UE122 may be an MRB for receiving MBS in a point-to-multipoint manner, or an MRB for receiving MBS in a point-to-point manner. Also, in embodiments of the present invention, the MRB for receiving MBS in a point-to-multipoint manner and the MRB for receiving MBS in a point-to-point manner may be the same MRB. That is, one MRB may have the capability to receive MBS in a point-to-multipoint manner and the capability to receive MBS in a point-to-point manner. If one MRB has the capability to receive MBS in a point-to-multipoint manner and the capability to receive MBS in a point-to-one manner, the MRB may include one or more RLC bearers for receiving and / or transmitting MBS in a point-to-multipoint manner, and one or more RLC bearers for receiving and / or transmitting MBS in a point-to-one manner. If a single MRB has the capability to receive MBS in a one-to-many manner and the capability to receive MBS in a one-to-one manner, then one or more RLC bearers for receiving and / or transmitting MBS in a one-to-many manner, and one or more RLC bearers for receiving and / or transmitting MBS in a one-to-one manner, may be associated with a single PDCP entity.Furthermore, one or more QoS flows may be associated with an MRB. Note that an MRB used for receiving MBS on a one-to-one (point-to-point) basis may also be a DRB.

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

[0172] Figure 12 shows an example of the MBS reception procedure in NR according to an embodiment of the present invention. In this embodiment, the parameters and / or information may be fields and / or information elements in ASN.1.

[0173] As shown in Figure 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 obtaining control information related to MBS transmission, and send it from the transmitting unit 600 to the UE122. The receiving unit 500 of the UE122 receives the above-mentioned first SIB. The above-mentioned first SIB may be transmitted via the BCCH logical channel or via another logical channel. Furthermore, the information necessary for obtaining control information related to MBS transmission mentioned above may also be information related to the MCCH (Multicast Control Channel) logical channel (sometimes referred to as MCCH in the following description). The above-mentioned MCCH may be a point-to-multipoint downlink channel for sending MBS control information, and / or MBS setting information, and / or MBS information to one or more MTCH (Multicast Traffic Channel) logical channels (sometimes referred to as MTCH in the following description) from the gNB108 to the UE122. Furthermore, the MTCH mentioned above may be a point-to-multipoint downlink channel for transmitting MBS data from gNB108 to UE122. The MCCH mentioned above may also be a multicast control channel. The MTCH mentioned above may also be a multicast traffic channel. The MTCH mentioned above may only be used by UE122 when UE122 receives MBS. The MCCH mentioned above may also be referred to by other names such as MBS-MCCH or NR-MCCH. The MTCH mentioned above may also be referred to by other names such as MBS-MTCH or NR-MTCH. Furthermore, the MCCH mentioned above may be mapped to a downlink transport channel called MCH (Multicast Channel), or to a downlink transport channel called DL-SCH (Downlink Shared Channel).Furthermore, the aforementioned MTCH may be mapped to a downlink transport channel, which is an MCH (Multicast Channel), or to a downlink transport channel, which is a DL-SCH (Downlink Shared Channel). Also, the MBS control information and / or MBS configuration information and / or MBS information for one or more MTCH logical channels, as described above, may be included in the first SIB described above, or in a second SIB separate from the first SIB described above. (Step S1200).

[0174] The first SIB described above may include some or all of the following parameters: a parameter indicating the period during which the contents of the MCCH may be changed; a parameter relating 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; and so on. The parameter relating to the transmission (retransmission) time interval of the MCCH described above may also be expressed in terms of the number of radio frames.

[0175] Next, the processing unit of gNB108 may create an RRC message to be transmitted via the MCCH described above and transmit it from the transmitting unit 600. The receiving unit 500 of UE122 may receive the RRC message transmitted via the MCCH described above based on the setting of the first SIB described above. A dedicated RNTI (Radio Network Temporary Identifier) ​​may be used to identify the MCCH transmission described above. The value of the dedicated RNTI for identifying the MCCH transmission described above may be a specific value, or the value may be set by the first SIB described above. In the embodiment of the present invention, the RRC message transmitted via the MCCH described above will be described using the message name "MBS setting information message," but a different message name may be used. (Step S1202)

[0176] The above-described MBS configuration information message may include one or more MBS MTCH parameters, which are parameters for MBS reception. For example, just as the information elements shown in SC-MTCH-InfoList in Figure 11 include one or more information elements shown in SC-MTCH-Info in the form of a list, one or more MBS MTCH parameters may be included in the above-described MBS configuration information message 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 a first MBS session, and a second MBS MTCH parameter may exist for a second MBS session. In the embodiments of the present invention, the parameters for MBS reception described above are referred to as MBS MTCH parameters, but they may be referred to by other names.

[0177] The MBS MTCH parameters may include some or all of the following parameters: parameters relating to MBS session information, parameters indicating RNTI identifying multicast groups (MTCHs destined for specific groups), parameters indicating logical channel identifiers, parameters relating to DRX information for MTCHs, parameters indicating a list of neighboring cells providing the same MBS, parameters indicating whether ROHC applies to the MBS session, parameters relating to ROHC used in the MBS session, parameters relating to HFN (Hyper Frame Number), parameters relating to COUNT, and parameters relating to the status report timer. The parameters relating to MBS session information mentioned above may include some or all of the following parameters, for example, parameters indicating TMGI (Temporary Mobile Group Identity), which is an identifier for the MBS, parameters indicating Session ID, which is an identifier for the MBS (or MBMS) session, parameters indicating the PDU session to which the MBS session belongs, and parameters indicating the QoS flow used in the MBS session. Furthermore, some or all of the above MBS MTCH parameters may be included in the first SIB mentioned above, or in the second SIB mentioned above, or in a third SIB separate from the first and second SIBs mentioned above.

[0178] The parameter indicating the list of neighboring cells providing the same MBS may also include a parameter indicating the list of neighboring cells providing the same MBS via MTCH and / or MRB, or a parameter indicating the list of neighboring cells providing the same MBS via unicast and / or DTCH and / or DRB.

[0179] Furthermore, the MBS configuration information message and / or MBS MTCH parameters may include parameters relating to MRB configuration. The parameters relating to MRB configuration may include some or all of the following: an identifier for identifying the MRB, SDAP configuration information elements, and PDCP configuration information elements. The parameters relating to MRB configuration described above may also include one or more RLC bearer configuration information elements. The RLC bearer configuration information elements described above may include some or all of the RLC configuration information elements for establishing and / or configuring RLC entities, and logical channel information elements for logical channel configuration. The RLC bearer configuration information elements described above may also be included in an information element separate from the MRB configuration and may be linked to the parameters relating to MRB configuration by an identifier for identifying the MRB described above. The MRB configuration described above may also include a parameter for identifying RLC bearers that receive MBS in a one-to-many relationship. The MRB configuration described above may also include a parameter for identifying RLC bearers that receive MBS in a one-to-one relationship. The parameter that identifies an RLC bearer receiving MBS in a one-to-many relationship, and / or the parameter that identifies an RLC bearer receiving MBS in a one-to-one relationship, may be a logical channel identifier. The parameter that indicates whether ROHC is applied to the MBS session, and / or the parameter related to ROHC used in the MBS session, and / or the parameter related to HFN (Hyper Frame Number), and / or the parameter related to COUNT, and / or the parameter related to the status report timer, etc., may be included in the parameters related to MRB settings or in the PDCP configuration information elements. The parameter that indicates the PDU session, and / or the parameter indicating the QoS flow, etc., may be included in the parameters related to MRB settings or in the SDAP configuration information elements. The parameter that indicates the PDU session, etc., may also be a PDU session ID.

[0180] UE122 receives an MBS configuration information message from the receiving unit 500, and the processing unit 502 may perform the process of starting to receive an MBS session of interest. (Step S1204)

[0181] In step S1204, the processing unit 502 of UE122 may determine from the MBS configuration information message received in step S1202 whether or not ROHC applies to the MBS session of interest. The determination of whether or not ROHC applies to the MBS session of interest may be made by whether or not the above-mentioned parameter indicating whether or not ROHC applies is included in the above-mentioned MBS configuration information message and / or MBS MTCH parameter. That is, if the above-mentioned parameter indicating whether or not ROHC applies is included in the above-mentioned MBS configuration information message and / or MBS MTCH parameter for the MBS session of interest, it may be determined that ROHC applies, and if the above-mentioned parameter indicating whether or not ROHC applies is not included in the above-mentioned MBS configuration information message and / or MBS MTCH parameter for the MBS session of interest, it may be determined that ROHC does not apply. Alternatively, the determination of whether or not ROHC applies may be made based on the value of the above-mentioned parameter indicating whether or not ROHC applies included in the above-mentioned MBS configuration information message and / or MBS MTCH parameter for the MBS session of interest. In other words, if the parameter indicating whether or not ROHC is applied, included in the above-mentioned MBS configuration information message and / or the MBS MTCH parameter for the MBS session of interest, is a value indicating that ROHC is applied, then it can be determined that ROHC is applied. Conversely, if the parameter indicating whether or not ROHC is applied, included in the above-mentioned MBS configuration information message and / or the MBS MTCH parameter for the MBS session of interest, is a value indicating that ROHC is not applied, then it can be determined that ROHC is not applied. Alternatively, the determination of whether or not ROHC is applied can be made by whether or not the above-mentioned MBS configuration information message and / or the MBS MTCH parameter for the MBS session of interest includes the above-mentioned parameter regarding ROHC used in the MBS session. In other words, if the above-mentioned MBS configuration information message and / or the MBS MTCH parameter for the MBS session of interest includes the above-mentioned parameter regarding ROHC used in the MBS session, then it can be determined that ROHC is applied.Furthermore, if the above-mentioned MBS configuration information message and / or the MBS MTCH parameters for the MBS session of interest do not include parameters related to ROHC used in the MBS session, it can be assumed that ROHC is not applied. Note that the MBS session of interest may be rephrased as the session that UE122 wants to receive, the session that UE122 is trying to receive, etc.

[0182] The parameters related to ROHC used in the above-mentioned MBS session may include some or all of the following: parameters related to the maximum value of the context identifier (CID) used in ROHC, parameters related to the profile used in ROHC, and parameters indicating whether to continue or reset the ROHC header compression protocol during PDCP re-establishment. The parameters related to ROHC used in the above-mentioned MBS session may also include parameters 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 parameters related to the timing at which all header information is obtained may include some or all of the following: parameters indicating the period during which some or all of all header information may be changed, parameters indicating the time interval in which all header information is transmitted in terms of the number of wireless frames, parameters indicating the offset of the wireless frame in which the transmission of all header information is scheduled, parameters indicating the slot in which the transmission of all header information is scheduled, and parameters indicating the window length of the slot in which the transmission of all header information is scheduled. The above-mentioned all header information may be all header information among the header information (IP header, UDP header, TCP header, RTP header, etc.) that is subject to compression in ROHC. Furthermore, the timing at which all the above header information is obtained may be rephrased as the timing at which the ROHC context information is obtained. Furthermore, the timing at which all the above header information is obtained may be rephrased as the timing at which it is transmitted using the IR state and / or FO state and / or SO state. The timing at which all the header information is obtained may be the timing at which UE122 begins to receive MBS or MTCH. Furthermore, the timing at which all the above header information is obtained may be the timing at which UE122 should begin to receive MBS or MTCH.

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

[0184] Furthermore, in step S1204, if the processing unit 502 of UE122 determines that ROHC applies to the MBS session of interest, or that it is necessary to obtain ROHC context information, it may perform the process of obtaining the ROHC context. The above-mentioned process of obtaining the ROHC context may be performed by 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 restart request message to gNB108 and receiving an RRC restart message or an RRC setup message from gNB108 as a response message to the above-mentioned RRC restart request message. Furthermore, when UE122 transitions from the RRC_IDLE state or RRC_INACTIVE state to the RRC_CONNECTED state, or after UE122 has transitioned from the RRC_IDLE state or RRC_INACTIVE state to the RRC_CONNECTED state, UE122 may send an RRC message to gNB108 containing information about MBS sessions of interest.

[0185] When UE122 transitions to the RRC_CONNECTED state, an MRB for receiving MBS sessions on a one-to-one basis or a DRB for receiving MBS sessions may be established and / or configured. An MRB for receiving MBS sessions on a one-to-one basis may be a wireless bearer that includes one or more RLC bearers for receiving MBS sessions on a one-to-many basis, and one or more RLC bearers for receiving MBS sessions on a one-to-one basis. Furthermore, establishing and / or configuring an MRB for receiving MBS sessions on a one-to-one basis may mean that an RLC bearer for receiving MRB sessions on a one-to-one basis is additionally established and / or configured in an MRB that only has RLC bearers for receiving MRB sessions on a one-to-many basis. Establishing and / or configuring an additional RLC bearer for receiving MRB sessions on a one-to-one basis means associating the established and / or established RLC bearer for receiving MBS sessions on a one-to-one basis with the MRB PDCP entity that has only the aforementioned RLC bearer for receiving MRB sessions on a one-to-many basis. The acquisition of the ROHC context described above may be performed by UE122 receiving the aforementioned MBS sessions of interest on a one-to-one basis. (Step S1206)

[0186] Furthermore, the ROHC context acquisition process in step S1204 may be performed by UE122 according to the ROHC-related parameters included in the MBS configuration information message and / or the MBS MTCH parameters for the MBS session of interest. For example, UE122 may acquire timing information for when all header information is available, according to the parameters for when all header information is available, and acquire the ROHC context information at the time when all header information is available. Alternatively, UE122 may acquire timing information for when all header information is available, according to the parameters for when all header information is available, in its RRC, and notify the MAC entity of UE122 of information including some or all of the acquired timing information, thereby acquiring the ROHC context information at the time when all header information is available. When UE122's RRC notifies the MAC entity of information including some or all of the acquired timing information, it may also send RNTI information used for one-to-many reception of MBS sessions. Furthermore, UE122 may, in the RRC_IDLE, RRC_INACTIVE, or RRC_CONNECTED state, perform the process of obtaining the ROHC context according to the ROHC-related parameters included in the MBS configuration information message and / or MBS MTCH parameters for the MBS session of interest. The timing at which all the above header information is obtained may be rephrased as the timing at which the IR state and / or FO state and / or SO state are used. The timing at which all the above header information is obtained may also be rephrased as the timing at which ROHC context information is obtained. The timing at which all the above header information is obtained may also be rephrased as the timing at which MBS or MTCH reception begins. Furthermore, the timing at which all the above header information is obtained may be rephrased as another term meaning the timing at which all information included in the headers subject to header compression in ROHC (IP header, UDP header, TCP header, RTP header, etc.) is obtained. (Step S1206)

[0187] Furthermore, in step S1204, if the processing unit 502 of UE122 determines that ROHC is not applied to the MBS session of interest, or determines that it is not necessary to obtain ROHC context information, 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 ROHC context information. Furthermore, in step S1204, if the processing unit 502 of UE122 determines that ROHC is not applied to the MBS session of interest, or determines that it is not necessary to obtain ROHC context information, the processing unit 502 of UE122 may receive the MBS service in the RRC_IDLE state or RRC_INNACTIVE state without obtaining ROHC context information. Furthermore, in step S1204, if the processing unit 502 of UE122 determines that ROHC is not applied to the MBS session of interest, or determines that it is not necessary to obtain ROHC context information, the processing unit 502 of UE122 may receive the MBS service in the RRC_CONNECTED state without obtaining ROHC context information. (Step S1206)

[0188] In step S1204, the processing unit 502 of UE122 may determine whether the MBS configuration information message received in step S1202 contains parameters related to the Hyper Frame Number (HFN) for an MBS session of interest. The HFN parameters mentioned above may be parameters related to the HFN that gNB108 uses or is using for MBS session transmission. The HFN parameters mentioned above may also be parameters indicating that UE122 needs to obtain the value of the HFN that gNB108 uses or is using for MBS session transmission. The HFN that gNB108 uses or is using for MBS session transmission may be the HFN that is a state variable of the transmitting PDCP entity that gNB108 uses or is using for MBS session transmission. When gNB108 sends an MBS configuration information message, it may set the latest value of the HFN of the transmitting PDCP entity that gNB108 uses or is using for MBS session transmission as the HFN parameter. Furthermore, the parameters relating to HFN mentioned above may be parameters relating to the timing at which the HFN value is sent from gNB108 using MCCH or MTCH. The timing at which the HFN value is sent from gNB108 using MCCH or MTCH may include some or all of the following: a parameter indicating the period during which the HFN value may be changed; a parameter indicating the time interval at which the HFN value is sent in terms of the number of radio frames; a parameter indicating the offset of the radio frame in which the HFN value is scheduled; a parameter indicating the slot in which the HFN value is scheduled; and a parameter indicating the window length of the slot in which the HFN value is scheduled. At the timing at which the HFN value is sent, gNB108 may set and send in an RRC message and / or PDCP control PDU the latest value of the HFN of the transmitting PDCP entity that gNB108 uses or is using for MBS session transmission, or the last HFN value used for MBS session transmission, or the HFN value to be used for the next MBS session transmission.

[0189] In step S1204, if the processing unit 502 of UE122 determines that the received MBS configuration information message contains parameters related to HFN for an MBS session of interest, the RRC of UE122 may obtain the value of HFN according to the above-mentioned parameters related to HFN and notify the PDCP entity of the MRB of UE122. Alternatively, the RRC of UE122 may process the PDCP entity of the MRB of UE122 to obtain the value of HFN according to the above-mentioned parameters related to HFN. The RRC of UE122 may obtain the timing information for when the value of HFN is sent according to the above-mentioned parameters related to the timing of when the value of HFN is sent, and notify the MAC entity of UE122 of information including some or all of the obtained timing information, thereby processing the PDCP entity of UE122 to obtain the value of HFN at the timing when the value of HFN is sent. Furthermore, when the UE122's RRC notifies the MAC entity of information that includes some or all of the timing information it has acquired, it may also send the RNTI information used for one-to-many reception of MBS sessions. The UE122's MRB's PDCP entity 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.

[0190] Furthermore, in step S1204, if the processing unit 502 of UE122 determines that the received MBS configuration information message contains parameters related to HFN for an MBS session of interest, UE122 may transition from the RRC_IDLE state or RRC_INACTIVE state to the RRC_CONNECTED state. The RRC of UE122 in the RRC_CONNECTED state may obtain the value of HFN by receiving an RRC message containing the value of HFN from gNB108 via DCCH. The RRC of UE122 may notify the PDCP entity of the MRB of UE122 of the obtained 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.

[0191] In step S1204, the processing unit 502 of UE122 may determine whether the MBS configuration information message received in step S1202 contains parameters related to COUNT for the MBS session of interest. The above-mentioned parameters related to COUNT may be parameters related to the COUNT value that gNB108 uses or is using for MBS session transmission. The above-mentioned parameters related to COUNT may also be parameters indicating that UE122 needs to obtain the value of COUNT that gNB108 uses or is using for MBS session transmission. The COUNT value that gNB108 uses or is using for MBS session transmission may be the COUNT value, which is a state variable of the transmitting PDCP entity that gNB108 uses or is using for MBS session transmission. When gNB108 sends an MBS configuration information message, it may set the latest value of the COUNT value of the transmitting PDCP entity that gNB108 uses for MBS session transmission as the parameter related to COUNT. Furthermore, the parameters relating to COUNT mentioned above may be parameters relating to the timing at which the COUNT value is sent from gNB108 using MCCH or MTCH. The timing at which the COUNT value is sent from gNB108 using MCCH or MTCH may include some or all of the following: a parameter indicating the period during which the COUNT value may be changed; a parameter indicating the time interval at which the COUNT value is sent in the number of 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 sent, gNB108 may set and send in an RRC message and / or PDCP control PDU the latest value of the COUNT value of the transmitting PDCP entity that gNB108 uses or is using for MBS session transmission, or the last COUNT value used for MBS session transmission, or the COUNT value to be used for the next MBS session transmission.

[0192] In step S1204, if the processing unit 502 of UE122 determines that the received MBS configuration information message contains parameters related to COUNT for an MBS session of interest, the RRC of UE122 may obtain the COUNT value according to the above-mentioned parameters related to COUNT and notify the PDCP entity of the MRB of UE122. Alternatively, the RRC of UE122 may process the data according to the above-mentioned parameters related to COUNT so that the PDCP entity of the MRB of UE122 can obtain the COUNT value. The RRC of UE122 may obtain timing information regarding the sending of the COUNT value according to the above-mentioned parameters related to the timing of the sending of the COUNT value, and notify the MAC entity of UE122 of information including some or all of the obtained timing information so that the RRC of UE122 and / or the PDCP entity of the MRB can obtain the COUNT value at the time the COUNT value is sent. When the RRC of UE122 notifies the MAC entity of information including some or all of the obtained timing information, it may also send RNTI information used for one-to-many reception of MBS sessions. The PDCP entity of the MRB in UE122 may set the COUNT value obtained by notification from the upper layer or by receiving the PDCP control PDU as the COUNT value of the receiving PDCP entity.

[0193] Furthermore, in step S1204, if the processing unit 502 of UE122 determines that the received MBS configuration information message contains parameters related to COUNT for an MBS session of interest, UE122 may transition from the RRC_IDLE state or RRC_INACTIVE state to the RRC_CONNECTED state. The RRC of UE122 in the RRC_CONNECTED state may obtain the COUNT value by receiving an RRC message containing the COUNT value from gNB108 via DCCH. The RRC of UE122 may notify the PDCP entity of the MRB of UE122 of the obtained 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.

[0194] Furthermore, in step S1204, when the PDCP entity of the MRB of UE122 sets the COUNT value obtained by receiving the COUNT value notified from the upper layer or the PDCP control PDU as the COUNT value of the receiving PDCP entity, the receiving side of the PDCP entity may set a state variable indicating the COUNT value of the next PDCP SDU that is expected to be received. Also, when the PDCP entity of the MRB of UE122 sets the COUNT value obtained by receiving the COUNT value notified from the upper layer or the PDCP control PDU as the COUNT value of the receiving PDCP entity, the receiving side of the PDCP entity 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 yet been distributed to the upper layer. Furthermore, when the UE122 MRB's PDCP entity sets the COUNT value obtained by receiving the COUNT value notified from the upper layer or the PDCP control PDU as the COUNT value of the receiving PDCP entity, the aforementioned COUNT value may be set by dividing it into the HFN portion and the SN (Sequence Number) portion.

[0195] Furthermore, in step S1204, if the processing unit 502 of UE122 determines that the MBS session of interest does not contain any parameters related to HFN, and / or that the MBS session of interest does not contain any parameters 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. Furthermore, in step S1204, if the processing unit 502 of UE122 determines that the MBS session of interest does not contain any parameters related to HFN, and / or that the MBS session of interest does not contain any parameters 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. Furthermore, in step S1204, if the processing unit 502 of UE122 determines that the MBS session of interest does not contain parameters related to HFN, and / or that the MBS session of interest does not contain parameters related to COUNT, the processing unit 502 of UE122 may receive the MBS service in the RRC_CONNECTED state without obtaining the HFN value and / or the COUNT value. (Step S1206)

[0196] In step S1204, the processing unit 502 of UE122 may determine whether the MBS configuration information message received in step S1202 contains parameters related to the status report timer for the MBS session of interest. The parameters related to the status report timer mentioned above may be the value of the timer used for sending PDCP status reports. If it is determined that the received MBS configuration information message contains parameters related to the status report timer for the MBS session of interest, the processing unit 502 of UE122 may set the value of the timer used for sending the received PDCP status report. The timer used for sending PDCP status reports may be used by the UE122's PDCP entity to detect a PDCP PDU or a loss of a PDCP PDU. The timer used for sending PDCP status reports may be a timer that runs only once per PDCP entity. The timer used for sending PDCP status reports may also be started or restarted when UE122 detects a PDCP PDU or a loss of a PDCP PDU. For example, the timer used for sending PDCP status reports may be started or restarted when the UE122's PDCP receives a PDCP data PDU from a lower layer, based on the following conditions: the timer used for sending PDCP status reports is not running, and / or the state variable indicating the COUNT value of the next PDCP SDU to be received (for example, a state variable named RX_NEXT) is greater than the state variable indicating the COUNT value of the first PDCP PDU among the PDCP SDUs waiting to be received that have not been distributed to the upper layer (for example, a state variable named RX_DELIV). The timer used for sending PDCP status reports may also be stopped and / or reset when the UE122 has no more PDCP PDUs or PDCP PDU losses.For example, the timer used for sending PDCP status reports may be stopped and / or reset based on the fact that the timer used for sending PDCP status reports is running, and / or that the state variable indicating the COUNT value of the next PDCP SDU to be received (for example, a state variable named RX_NEXT) is equal to the 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 upper layer (for example, a state variable named RX_DELIV). The above "equal to" may be rephrased as "greater than" or "equal to". The above "equal to" may also be rephrased as "less than" or "equal to". Furthermore, the status report of the MRB's PDCP entity may be triggered based on the expiration of the timer used for sending PDCP status reports. Furthermore, the timer used for sending PDCP status reports may be stopped and / or reset based on the PDCP entity being requested to suspend from the upper layer. Furthermore, the timer used for sending PDCP status reports may be stopped and / or reset based on the PDCP entity being requested to re-establish from the upper layer. Furthermore, the timer used for sending PDCP status reports may be stopped and / or reset based on the PDCP entity being requested to be reconfigured from a higher layer.

[0197] Furthermore, an MRB may be established and / or configured for each MBS session that UE122 is interested in. If multiple MRBs are established and / or configured for UE122, the processing in step S1204 may be performed on the corresponding MRB.

[0198] In step S1206, before starting to receive an MBS session of interest, the processing unit 502 of UE122 may perform one or more MRB establishment processes to start receiving an MBS session of interest. An MRB establishment process may be initiated, for example, at the start of the MBS session, based on the fact that UE122 has entered a cell where the MBS service of interest is provided via MRB, has become interested in the MBS service, or the limitation of UE capability that was suppressing the reception of the MBS service has been removed. An MRB establishment process may be performed when UE122 is in the RRC_IDLE state, when UE122 is in the RRC_INACTIVE state, or when UE122 is in the RRC_CONNECTED state. Alternatively, an MRB establishment process may be initiated when UE122 is in the RRC_CONNECTED state and receives, or has received, an RRC message from gNB108 via DCCH indicating that an MRB should be established. The RRC message indicating the establishment of the above-mentioned MRB may include some or all of the parameters included in the MBS configuration information message in step S1202 described above. The processing unit 502 of UE122 may perform the MRB establishment process using configuration information that includes some or all of the default configuration information for each entity held by UE122, the parameters related to MBS configuration included in the MBS configuration information message received via MCCH in step S1202, and the parameters related to MBS configuration included in the RRC message indicating the establishment of the above-mentioned MRB received via DCCH.

[0199] When the processing unit 502 of UE122 performs the MRB establishment process, it may perform some or all of the following processes (A) to (M). (A) If an SDAP entity does not exist in the PDU session that provides MBS, and / or in the PDU session corresponding to the parameter 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 the default settings for MRB establishment, or according to the settings received from gNB108. (C) Establish and / or configure RLC entities according to the default settings for MRB establishment or the settings received from the base station. (D) Establish and / or configure RLC entities for RLC bearers that receive MBS in a one-to-many manner, according to the default settings for MRB establishment or the settings received from the base station. (E) Set the logical channel of the RLC bearer that receives MBS in a one-to-many manner to the MAC entity, according to the default settings for MRB establishment or the settings received from the base station. (F) Associate the RLC bearer or the logical channel of the RLC bearer established and / or set in process (D) and / or process (E) with the PDCP entity established and / or set in process (B). (G) Establish and / or configure the RLC entity of the RLC bearer that receives MBS one-to-one, according to the default settings for MRB establishment or the settings received from the base station. (H) Set the logical channel of the RLC bearer that receives MBS one-to-one to the MAC entity according to the default settings for MRB establishment or the settings received from the base station. (I) Associate the RLC bearer or the logical channel of the RLC bearer established and / or set in process (G) and / or process (H) with the PDCP entity established and / or set in process (B). (J) Associate the SDAP entity with the established MRB. (K) The establishment of the MRB is notified to the upper layer by notifying it of some or all of the following information: the TMGI, Session ID, PDU session ID, and QoS flow corresponding to the established MRB. (L) If the encryption function is not disabled for the PDCP entity of this MRB, the encryption algorithm is set for the PDCP entity established in process (B), and the master key or secondary key is applied according to the parameter that indicates whether to use the master key or the secondary key. (M) If integrity protection is set for the PDCP entity of this MRB, the integrity protection algorithm is set for the PDCP entity established in process (B), and the master key or secondary key is applied according to a parameter indicating whether to use the master key or the secondary key.

[0200] The processing unit 502 of UE122, which has established one or more MRBs, may create a PDCP status report and send it to gNB108 if a PDCP status report is triggered in the PDCP entities of one or more MRBs. When the processing unit 502 of UE122 has created a PDCP status report in the PDCP entities of an MRB, it may submit the created PDCP status report to the RLC entities of RLC bearers that receive MBS on a one-to-one basis and are associated with the PDCP entities of the MRBs, but does not need to submit it to the RLC entities of RLC bearers that receive MBS on a one-to-many basis and are associated with the PDCP entities of the MRBs. The above statement, "The created PDCP status report should be submitted to the RLC entity of the RLC bearer that receives MBS on a one-to-one basis and is linked to the MRB's PDCP entity, but it is not necessary to submit it to the RLC entity of the RLC bearer that receives MBS on a one-to-many basis and is linked to the MRB's PDCP entity," can be rephrased as, "The created PDCP status report should only be submitted to the RLC entity of the RLC bearer that receives MBS on a one-to-one basis and is linked to the MRB's PDCP entity." Furthermore, PDCP reporting in the MRB's PDCP entity may only be initiated for MRBs that have been configured to send PDCP status reports from a higher layer. (Step S1208)

[0201] Furthermore, in step S1208, if a PDCP status report is triggered in one or more MRB PDCP entities, the processing unit 502 of UE122 may determine whether an RLC bearer that receives MBS on a one-to-one basis is associated with the MRB PDCP entity, and based on the determination that an RLC bearer that receives MBS on a one-to-one basis is associated, create a PDCP status report and submit the created status report only to the RLC entity of the RLC bearer that receives MRB on a one-to-one basis as described above. Alternatively, if a PDCP status report is triggered in an MRB PDCP entity, the processing unit 502 of UE122 may determine whether an RLC bearer that receives MBS on a one-to-one basis is associated with the MRB PDCP entity, and based on the determination that an RLC bearer that receives MBS on a one-to-one basis is not associated, it may not create a PDCP status report.

[0202] Furthermore, in step S1208, if a PDCP status report is triggered in one or more MRB PDCP entities, the processing unit 502 of UE122 creates a PDCP status report, determines whether an RLC bearer that receives MBS on a one-to-one basis is associated with the MRB PDCP entity, and based on the finding that an RLC bearer that receives MBS on a one-to-one basis is associated, it may submit the created PDCP status report only to the RLC entity of the RLC bearer that receives the MRB on a one-to-one basis. Also, if a PDCP status report is triggered in an MRB PDCP entity, the processing unit 502 of UE122 creates a PDCP status report, determines whether an RLC bearer that receives MBS on a one-to-one basis is associated with the MRB PDCP entity, and based on the finding that an RLC bearer that receives MBS on a one-to-one basis is not associated, it does not need to submit the created PDCP status report to the lower layer. Furthermore, if a PDCP status report is triggered in the MRB's PDCP entity, the UE122's processing unit 502 may create a PDCP status report, determine whether an RLC bearer that receives MBS on a one-to-one basis is associated with the MRB's PDCP entity, and discard the created PDCP status report if it determines that no RLC bearer that receives MBS on a one-to-one basis is associated.

[0203] Furthermore, the RLC entity of the RLC bearer that receives the MBS on a one-to-one basis as described above may be an AM RLC entity. Also, the RLC entity to which the RLC bearer that receives the MBS on a one-to-one basis as described above is associated may be a bidirectional UM RLC entity. Furthermore, the RLC entity to which the RLC bearer that receives the MBS on a one-to-one basis as described above is associated may be a transmitting UM RLC entity and / or receiving UMRLC entity of a unidirectional UM RLC entity.

[0204] In step S1208, the PDCP status report may be triggered based on a request for transmission of a PDCP status report from the RRC layer or a higher layer. The 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 triggered based on the release, suspension, or deactivation of one or more RLC bearers associated with the PDCP entity of the MRB. In step S1208, the PDCP status report may also be triggered when the status report timer set in step S1204 expires in the PDCP entity. In step S1208, the PDCP status report may also be triggered based on a switchover of the RLC bearer receiving the MRB. The above-mentioned switching of the RLC bearer receiving the MRB may mean that the RLC bearer receiving the MRB has switched from an RLC bearer receiving MBS in a one-to-many manner to an RLC bearer receiving MBS in a one-to-one manner. Alternatively, the above-mentioned switching of the RLC bearer receiving the MRB may mean that the RLC bearer receiving the MRB has switched from an RLC bearer receiving MBS in a one-to-one manner to an RLC bearer receiving MBS in a one-to-many manner.

[0205] Furthermore, in step S1208, if the RRC message received by UE122 from gNB108 contains parameters indicating a request for UE122 to send a PDCP status report to one or more MRBs, the processing unit 502 of UE122 may request the PDCP layer of UE122's MRB to send a PDCP status report from UE122's RRC. The RRC message mentioned above may be an RRC message sent via DCCH or an RRC message sent via MCCH. The parameters indicating a request for one or more MRBs to send a PDCP status report may include some or all of the identifiers that identify the MRBs and the parameters related to MBS session information. Furthermore, in step S1208, if UE122 receives an RRC message from gNB108 indicating a request for PDCP status report transmission, the processing unit 502 of UE122 may request the PDCP layer of UE122's MRB to send a PDCP status report from UE122's RRC. The RRC message indicating the request to send the PDCP status report may be sent via DCCH or via MCCH. The RRC message indicating the request to send the PDCP status report may include an identifier to identify the MRB and some or all of the parameters relating to the MBS session information.

[0206] Furthermore, in step S1208, the processing unit 502 of UE122 may, based on receiving an RRC message for counterchecking (countercheck message) from gNB108 to one or more MRBs of UE122, perform a countercheck process and report the result to gNB108 in an RRC message for countercheck response (countercheck response message). The aforementioned RRC message for counterchecking may include an identifier for identifying the MRB, parameters related to MBS session information, and some or all of the most significant bit (MSB) values ​​of the uplink and / or downlink COUNT values ​​associated with the MRB. The aforementioned RRC message for counterchecking may be a message from gNB108 to UE122 requesting that UE122 report the result of comparing it with the current MSB value of the COUNT value associated with the MSB of gNB108 to gNB108. In the counter check process, the processing unit 502 of UE122 may perform some or all of the following processes (A) to (D) on the MRB established in UE122. (A) If the MRB is a unidirectional bearer and there is no COUNT for the uplink and / or downlink directions, assume that the COUNT value for the direction in which no COUNT value exists is '0'. (B) For MRBs whose RRC message for counter check does not contain parameters related to an identifier that identifies the MRB and / or MBS session information, the COUNT values ​​held by UE122 for the uplink and / or downlink directions are set in the RRC message for counter check response. (C) For an MRB whose RRC message for counter checking includes the MSB value of the COUNT value in the uplink direction and / or downlink direction, if the received MSB value of the COUNT value in the uplink direction and / or downlink direction differs from the COUNT value in the uplink direction and / or downlink direction held by UE122, the COUNT value for the uplink direction and / or downlink direction held by UE122 is set in the RRC message for counter checking response. (D) For MRBs whose RRC message for counter check includes parameters relating to an identifier that identifies the MRB and / or information about the MBS session, the COUNT values ​​held by UE122 for the uplink direction and / or downlink direction are set in the RRC message for counter check response.

[0207] In the above explanation, you may simply refer to the MBS session you are interested in as "MBS session".

[0208] In the above explanation, the RLC bearer that receives MBS on a one-to-one basis may also refer to the RLC bearer that sends feedback to the gNB108 for the MBS.

[0209] In the above explanation, "RLC bearer" may be replaced with "RLC entity." Also, in the above explanation, "RLC bearer" may be replaced with "logical channel."

[0210] In the above explanation, the PDCP entity may refer to the receiving PDCP entity and / or the transmitting PDCP entity.

[0211] In the above explanation, ROHC may be replaced with Ethernet Header Compression (EHC).

[0212] Thus, in the embodiments of the present invention, the terminal device can acquire the ROHC context even in multicast, and the present invention provides a terminal device, base station device, and method that can efficiently control the MBS using NR.

[0213] The wireless bearer in the above description may be some or all of the DRB, SRB, and MRB.

[0214] Furthermore, in the above explanation, expressions such as "link," "correspond," and "associate" may be used interchangeably.

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

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

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

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

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

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

[0221] (1) A terminal device that communicates with a base station device, comprising a receiving unit that receives a first message from the base station device and a processing unit, wherein the first message is transmitted from the base station device using a Multicast Control Channel (MCCH), and the processing unit determines that if the configuration information for the first Multicast Broadcast Service (MBS) contained in the first message includes parameters relating to Robust Header Compression (ROHC), ROHC is applied to the first MBS, and if the configuration information for the first MBS contained in the first message does not include parameters relating to ROHC, ROHC is not applied to the first MBS, and based on the fact that ROHC is applied to the first MBS, the processing unit obtains the ROHC context used for the first MBS.

[0222] (2) A base station device that communicates with a terminal device, comprising a transmitting unit that transmits a first message to the terminal device and a processing unit, wherein the base station device transmits the first message using a Multicast Control Channel (MCCH), and the processing unit causes the terminal device to determine that Robust Header Compression (ROHC) is applied to the first Multicast Broadcast Service (MBS) if the configuration information for the first MBS included in the first message includes parameters relating to ROHC, and causes the terminal device to determine that ROHC is not applied to the first MBS if the configuration information for the first MBS included in the first message does not include parameters relating to ROHC, and based on the determination that ROHC is applied to the first MBS, causes the terminal device to obtain an ROHC context used for the first MBS.

[0223] (3) A method for a terminal device to communicate with a base station device, wherein the terminal device receives a first message from the base station device, the first message is transmitted from the base station device using a Multicast Control Channel (MCCH), and if the configuration information for a first Multicast Broadcast Service (MBS) contained in the first message includes parameters relating to Robust Header Compression (ROHC), it is determined that ROHC is applied to the first MBS; if the configuration information for the first MBS contained in the first message does not include parameters relating to ROHC, it is determined that ROHC is not applied to the first MBS, and based on the fact that ROHC is applied to the first MBS, the terminal device obtains the ROHC context used for the first MBS.

[0224] (4) A method for a base station device to communicate with a terminal device, comprising: sending a first message to the terminal device; sending the first message from the base station device using a Multicast Control Channel (MCCH); causing the terminal device to determine that Robust Header Compression (ROHC) is applied to the first Multicast Broadcast Service (MBS) if the configuration information for the first MBS included in the first message includes parameters relating to ROHC; causing the terminal device to determine that ROHC is not applied to the first MBS if the configuration information for the first MBS included in the first message does not include parameters relating to ROHC; and causing the terminal device to obtain an ROHC context used for the first MBS based on the fact that ROHC is applied to the first MBS.

[0225] A program that operates in a device according to one aspect of the present invention may be a program that controls a Central Processing Unit (CPU), etc., to make the computer function in order to realize the functions of the above-described embodiment according to one aspect of the present invention. The program or information handled by the program is temporarily loaded into volatile memory such as Random Access Memory (RAM) during processing, or stored in non-volatile memory such as flash memory or a Hard Disk Drive (HDD), and read, modified, and written by the CPU as needed.

[0226] Furthermore, a part of the apparatus in the above-described embodiment may be implemented using a computer. In that case, the program for implementing this control function may be recorded on a computer-readable recording medium, and the program recorded on this recording medium may be loaded into a computer system and executed. The term "computer system" here refers to a computer system built into the apparatus, and includes hardware such as an operating system and peripheral devices. The "computer-readable recording medium" may be any of the following: a semiconductor recording medium, an optical recording medium, a magnetic recording medium, etc.

[0227] Furthermore, "computer-readable recording media" may include those that dynamically hold programs for a short period of time, such as communication lines used when transmitting programs via networks such as the Internet or communication lines such as telephone lines, as well as those that hold programs for a certain period of time, such as volatile memory within the computer system acting as a server or client in such cases. In addition, the above-mentioned program may be for the purpose of realizing some of the functions described above, and may also be a program that can realize the above-mentioned functions in combination with a program already recorded in the computer system.

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

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

[0230] While embodiments of this invention have been described in detail above with reference to the drawings, the specific configuration is not limited to these embodiments, and design modifications and the like that do not depart from the gist of this invention are also included. Furthermore, various modifications are possible within the scope of the claims for one aspect of the present invention, and embodiments obtained by appropriately combining the technical means disclosed in different embodiments are also included in the technical scope of the present invention. In addition, configurations in which elements described in the above embodiments that produce similar effects are substituted for each other are also included. [Industrial applicability]

[0231] 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. [Explanation of Symbols]

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

Claims

1. A terminal device that communicates with a base station device, The base station device comprises a receiving unit that receives a first message and a processing unit, The first message is transmitted from the base station equipment using the Multicast Control Channel (MCCH), The processing unit determines that Robust Header Compression (ROHC) is applied to the first Multicast Broadcast Service (MBS) if the configuration information for the first MBS included in the first message includes parameters related to ROHC, and determines that ROHC is not applied to the first MBS if the configuration information for the first MBS included in the first message does not include parameters related to ROHC. Based on the fact that ROHC is applied to the first MBS and that the MRB for receiving the first MBS is an MRB for receiving MBS sessions on a one-to-one basis, the ROHC context used for the first MBS is obtained. Terminal device.

2. A base station device that communicates with terminal devices, The terminal device comprises a transmission unit that transmits a first message and a processing unit, The first message is transmitted from the base station device using the Multicast Control Channel (MCCH). The processing unit causes the terminal device to determine that Robust Header Compression (ROHC) is applied to the first Multicast Broadcast Service (MBS) if the configuration information for the first MBS included in the first message includes parameters related to ROHC, and to determine that ROHC is not applied to the first MBS if the configuration information for the first MBS included in the first message does not include parameters related to ROHC. Based on the fact that ROHC is applied to the first MBS and that the MRB for receiving the first MBS is an MRB for receiving MBS sessions on a one-to-one basis, the terminal device is made to acquire the ROHC context used for the first MBS. Base station equipment.

3. A method for a base station device to communicate with a terminal device, The first message is sent to the aforementioned terminal device. The first message is transmitted from the base station device using the Multicast Control Channel (MCCH). The terminal device is instructed to determine that Robust Header Compression (ROHC) is applied to the first Multicast Broadcast Service (MBS) if the configuration information for the first MBS included in the first message includes parameters related to ROHC, and to determine that ROHC is not applied to the first MBS if the configuration information for the first MBS included in the first message does not include parameters related to ROHC. Based on the fact that ROHC is applied to the first MBS and that the MRB for receiving the first MBS is an MRB for receiving MBS sessions on a one-to-one basis, the terminal device is made to acquire the ROHC context used for the first MBS. method.

Images