Terminal device and method

Abstract

This terminal device has a first RLC bearer for receiving one-to-many MBS and a second RLC bearer for receiving one-to-one MBS, the first RLC bearer and the second RLC bearer are linked to the same PDCP entity, and when a PDCP status report is created, the PDCP entity submits the PDCP status report only to the second RLC bearer.

Description

Technical Field

[0003]

[0001] The present invention relates to a terminal device and a method. This application claims priority to Japanese Patent Application No. 2020-172376, 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. For example, in 3GPP, E-UTRA (Evolved Universal Terrestrial Radio Access) was started as a radio access technology (RAT) for cellular mobile communication systems for the 3.9th generation and 4th generation, and technical studies and standardization were carried out. 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), LTE-Advanced Pro (LTE-A Pro). (Non-Patent Document 2, etc.)

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

[0004] RAT) and technical studies and standardization were started. Even now, in 3GPP, technical studies and standardization of extended technologies of NR are being carried out. (Non-Patent Document 1, etc.) [Prior art documents] [Non-patent literature]

[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 project] [Problems that the invention aims to solve]

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

[0007] Transmission using MBSFN involves transmitting multicast / broadcast data using PMCH (Physical Multicast Channel) within an MBSFN (Multicast-Broadcast Single-Frequency Network) area consisting of multiple cells. In contrast, transmission using SC-PTM involves transmitting multicast / broadcast data within a single cell. At this stage, multicast data is sent using PDSCH (Physical Downlink Shared Channel). To act with faith.

[0008] Meanwhile, Multicast Broadcast Service (MBS) is being considered as an extension of NR. When implementing MBS via NR, it is necessary to consider NR-specific technologies different from E-UTRA, as well as core networks standardized for 5G. However, detailed operations for efficiently controlling MBS using NR are still under consideration. I haven't done that.

[0009] One aspect of the present invention has been made in view of the above circumstances, and which uses NR to efficiently perform MBS One of the objectives is to provide controllable terminal devices, base station devices, and methods. [Means for solving the problem]

[0010] To achieve the above objective, one aspect of the present invention employs the following means. That is, one aspect of the present invention is a terminal device that communicates with a base station device, wherein the terminal device comprises a first RLC bearer for receiving MBS signals one-to-many and a second RLC bearer for receiving MBS signals one-to-one. The first RLC bearer and the second RLC bearer are associated with the same PDCP entity, and when the PDCP entity generates a PDCP status report, it submits the PDCP status report only to the second RLC bearer.

[0011] Another aspect of the present invention is a method for a terminal device to communicate with a base station device, wherein the terminal device has a first RLC bearer for one-to-many reception of MBS and a second RLC bearer for one-to-one reception of MBS, and the first RLC bearer and the second RLC bearer are the same PDCP entity Linked to the i, when the PDCP entity creates a PDCP status report, the PDCP status report is submitted only to the second RLC bearer.

[0012] These general or specific aspects may be implemented in a system, apparatus, method, integrated circuit, computer program, or recording medium, or may be implemented in any combination of a system, apparatus, method, integrated circuit, computer program, and recording medium.

Advantages of the Invention

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

Brief Description of the Drawings

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

Embodiments for Carrying Out the Invention

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

[0016] LTE (and LTE-A, LTE-A Pro) and NR may be defined as different radio access technologies (RATs). Also, NR may be defined as a technology included in LTE. Also, LTE may be defined as a technology included in NR. Also, LTE that can be connected with NR and Multi Radio Dual connectivity (MR-DC) may be distinguished from conventional LTE. Also, LTE using 5GC in the core network may be distinguished from conventional LTE using EPC in the core network. Note that conventional LTE may be LTE that does not implement technologies standardized after Release 15 in 3GPP. Embodiments of the present invention may be applied to NR, LTE, and other RATs. In the following description, terms related to LTE and NR will be used for explanation, but embodiments of the present invention may be applied to other technologies using other terms. Also, the term E-UTRA in embodiments of the present invention may be replaced with the term LTE, and the term LTE may be replaced with the term E-UTRA. In the following description, terms related to LTE and NR will be used for explanation, but embodiments of the present invention may also be applied to other technologies using other terms. Also, in embodiments of the present invention, the term E-UTRA may be replaced with the term LTE, and the term LTE may be replaced with the term E-UTRA.

[0017] ​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.

[0018] 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.

[0019] E-UTRA100 may be a wireless access technology. Also, E-UTRA100 is between UE122 and eNB102. It may be an air interface. The air interface between UE122 and eNB102 may be called the Uu interface. eNB (E-UTRAN Node B)102 is the base of E-UTRA100 It may be a ground station device. 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 eNBs may be called E-UTRAN.

[0020] The EPC (Evolved Packet Core) 104 may be the core network. Interface 112 is the 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 is located within the EPC104, specifically the Mobility Management Entity (MME: not shown). It may be terminated there. The user plane interface of interface 112 is within EPC104 Termination may be done at a Bing gateway (S-GW: not shown). The control plane interface of interface 112 may be called the S1-MME interface. User play of interface 112 The interface can be called the S1-U interface.

[0021] 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.

[0022] NR106 is a wireless access technology. Also, NR106 is an air interface between UE122 and gNB108. It may be an air interface. The air interface between UE122 and gNB108 may be called the Uu interface. gNB (g Node B)108 may be the base station equipment for NR106. The gNB108 may have the NR protocol described below. The NR protocol includes the NR User Plane (UP) protocol and the NR Control Plane (CP) protocol described below. It may be composed of Tocol. gNB108 may terminate the NR User Plane (UP) protocol and the NR Control Plane (CP) protocol to UE122.

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

[0024] 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.

[0025] eNB102 may have the function to connect to 5GC110. eNB102 that has the function to connect to 5GC110 may be called ng-eNB. Interface 114 is the interface between eNB102 and 5GC110, and NG It can be called an interface. The control plane through which control signals pass is the interface 114. There exists an interface, and / or a user plane interface through which user data passes. The control plane interface of interface 114 may be terminated by the Access and Mobility Management Function (AMF: not shown) in 5GC110. The lane interface may be terminated by a User Plane Function (UPF: not shown) within the 5GC110. The control plane interface of interface 114 may be called the NG-C interface. The user plane interface of interface 114 may be called the NG-U interface. A wireless access network consisting of ng-eNB or gNB may be referred to as NG-RAN. NG-RAN, E-UTRAN, eNB, ng-eNB, and gNB may also simply be referred to as a network.

[0026] 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. Also, the eNB102 connected to the 5GC110 and the gNB108 connected to the 5GC110 are connected via interface 120. Good. The interface 120 between eNB102 connected to 5GC110 and gNB108 connected to 5GC110 is It can be called the Xn interface.

[0027] gNB108 may have the function to connect to EPC104. A gNB108 that has the function to connect to EPC104 may be called an en-gNB. Interface 118 is the interface between gNB108 and EPC104, S1 It can be called an interface. Interface 118 is a user interface through which user data passes. A lane interface may exist. User plane interface of interface 118 The line may be terminated at the S-GW (not shown) in EPC104. User plane of interface 118 The interface may be called the S1-U interface. Furthermore, the eNB102 connected to EPC104 and the gNB108 connected to EPC104 may be connected via interface 120. eNB102 connected to EPC104 The interface 120 between the EPC104 and the gNB108 is called the X2 interface. stomach.

[0028] Interface 124 is the interface between EPC104 and 5GC110, and is either CP only or UP only. or it may be an interface that passes through both CP and UP. Also, interface 114, Some or all of the interfaces, such as interface 116, interface 118, interface 120, and interface 124, may not exist depending on the communication system provided by the telecommunications carrier, etc.

[0029] 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.

[0030] 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 in CP is a signaling radio bearer (SRB). It is acceptable to call it that. Furthermore, the radio bearers used in UP may be called Data Radio Bearers (DRB). Each radio bearer is assigned a Radio Bearer Identifier (Identity: ID). It is acceptable to do so. A radio bearer identifier for SRB may be called an SRB identifier (SRB Identity, or SRB ID). A radio bearer identifier for DRB may be called a DRB identifier (DRB Identity, or DRB ID).

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

[0032] 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 will be further established within 5GC110. It may be associated with one of the PDU (Packet Data Unit) sessions. Each PDU session may have one or more QoS flows. Each DRB may be associated with one or more QoS flows. Each PDU session can be mapped, or it can not be mapped to any QoS flow. Each QoS flow 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.

[0033] EPC104 does not need to have a PDU session and / or QoS flow. Also, 5GC110 does not need to have an EPS bearer. When UE122 is connected to EPC104, UE122 does not have information about the EPS bearer. It will have information, but it does not need to have information within the PDU session and / or QoS flow. Also, when UE122 is connected to 5GC110, UE122 will have information within the PDU session and / or QoS flow, but it does not need to have information about the EPS bearer.

[0034] 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.

[0035] Figure 2 is a diagram showing an example of the E-UTRA protocol architecture according to an embodiment of the present invention. Figure 3 is a diagram showing an example of the NR protocol architecture according to an embodiment of the present invention. The functions of each protocol described with reference to Figure 2 and / or Figure 3 are closely related to embodiments of the present invention. This is only a part of the functionality, and it may have other functions. In the embodiments of the present invention, the uplink (UL) may be a link from a terminal device to a base station device. Also, in each embodiment of the present invention, the downlink (DL) may be a link from a base station device to a terminal device.

[0036] 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.

[0037] 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.

[0038] Figure 2(B) is a diagram of the E-UTRA control plane (CP) protocol configuration. As shown in Figure 2(B), in the E-UTRA 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. In Rotokol, the NAS (Non-Access Stratum) 210, which is a non-AS (Access Stratum) layer, may be a protocol between UE122 and MME. That is, NAS210 may be a protocol that terminates at MME on the network side.

[0039] Figure 3(B) is a diagram of the NR control plane (CP) protocol configuration. As shown in Figure 3(B), the NR CP In Rotokol, the RRC308, which is the wireless resource control layer, is the protocol between UE122 and gNB108. It may be a protocol. That is, RRC308 may be a protocol that terminates with gNB108 on the network side. Also, in the E-UTRAN CP protocol, NAS312, which is a non-AS layer, may be a protocol between UE122 and AMF. That is, NAS312 may be a protocol that terminates with AMF on the network side. It's fine if it's a lu.

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

[0041] 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.

[0042] 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-specific PHY, NR-specific MAC, NR-specific RLC, NR-specific RLC, and NR-specific RRC, respectively. Also, PHY200, MAC302, RLC304, PDCP306, and RRC308 are sometimes referred to as NR-specific PHY, MAC302, RLC304, PDCP306, and RRC308, respectively. These are sometimes written as NR PHY, NR MAC, NR RLC, NR PDCP, NR RRC, etc.

[0043] This section describes entities in the AS layer of E-UTRA and / or NR. Entities possessing some or all of the functions of the MAC layer may be called MAC entities. Entities possessing some or all of the functions of the RLC layer may be called RLC entities. The functions of the PDCP layer are also described. An entity possessing some or all of the functions of the SDAP layer may be called a PDCP entity. An entity possessing some or all of the functions of the SDAP layer may be called an SDAP entity. Functions of the RRC layer An entity that possesses some or all of the characteristics may be called an RRC entity. MAC entities, RLC entities, PDCP entities, SDAP entities, and RRC entities may be replaced with MAC, RLC, PDCP, SDAP, and RRC, respectively.

[0044] Furthermore, the data provided from MAC, RLC, PDCP, and SDAP to lower layers, and / or the data provided to MAC, RLC, PDCP, and SDAP from lower layers, may be referred to as MAC PDU (Protocol Data Unit), RLC PDU, PDCP PDU, and SDAP PDU, respectively. This refers to the data provided, and / or the data provided to higher layers from MAC, RLC, PDCP, and SDAP. These can be called MAC SDU (Service Data Unit), RLC SDU, PDCP SDU, and SDAP SDU, respectively. Furthermore, a segmented RLC SDU can be referred to as an RLC SDU segment.

[0045] An example of PHY functionality is described below. The PHY of the terminal device receives downlink from the PHY of the base station device. The terminal device's PHY may have the function of receiving data transmitted via a Downlink (DL) physical channel. The terminal device's PHY may have the function of transmitting data to the base station device's PHY via an 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 transfer data from the MAC via the Transport Channel. You may provide the data. In the PHY, you may use RNTI (Radio Network Temporary Identifier) ​​to identify various control information.

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

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

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

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

[0050] Furthermore, in NR, PBCH is the period of the synchronization signal block (also called SS / PBCH block). It may be used to report the internal time index (SSB-Index).

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

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

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

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

[0055] PRACH may be used to send a random access preamble. PRACH is used in the initial connection establishment procedure, handover procedure, connection re-establishment procedure, etc. This indicates synchronization (timing adjustment) for link transmission and a request for PUSCH (UL-SCH) resources. It may be used for that purpose.

[0056] This section describes an example of MAC functionality. MAC can be called a MAC sublayer. MAC handles various logical channels and their corresponding transports. It may have the function to map to logical channels. Logical channels may be identified by a Logical Channel Identity (Logical Channel ID). MAC may be connected to the higher-level RLC via a logical channel. Logical channels may be divided into control channels for transmitting control information and user information depending on the type of information being transmitted. The traffic channels to be transmitted may be divided. Furthermore, logical channels may be divided into uplink logical channels and downlink logical channels. MAC may be one or more different MAC may have the function of multiplexing MAC SDUs belonging to a logical channel and providing them to the PHY. MAC may also have the function of demultiplexing MAC PDUs provided by the PHY and providing them to the upper layer via the logical channel to which each MAC SDU belongs. MAC may also It may have a function to perform error correction through HARQ (Hybrid Automatic Repeat request). MAC also reports scheduling information. MAC may have a Scheduling Report (SR) function. MAC may have a function to prioritize processing between terminal devices using dynamic scheduling. MAC may also have a function to prioritize a single terminal The MAC may have the function to perform priority processing between logical channels within the device. It may have a function to prioritize the processing of overlapping resources. The E-UTRA MAC may have a function to identify Multimedia Broadcast Multicast Services (MBMS). Also, the NR MAC , Multicast Broadcast Service (MBS) It's fine to have a separate function. Macs have a function to select the transport format. Good. MAC may have functions for intermittent reception (DRX) and / or intermittent transmission (DTX), execution of random access (RA) procedures, a power headroom report (PHR) function that notifies information on transmittable power, a buffer status report (BSR) function that notifies information on the amount of data in the transmit buffer, etc. NR MAC may have a bandwidth adaptation (BA) function. Also, the MAC PDU format used in E-UTRA MAC and the MAC PDU format used in NR MAC may be different. In addition, MAC PDU may have functions in MAC. MAC control elements (MAC CEs), which are elements for performing control, may be included.

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

[0058] BCCH (Broadcast Control Channel) is used for system information (SI), etc. It may be a downlink logic channel for broadcasting control information.

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

[0060] CCCH (Common Control Channel) may be a logical channel for transmitting control information between a terminal device and a base station device. CCCH is used when the terminal device does not have an RRC connection. It is permissible to use it. Furthermore, CCCH may be used between a base station device and multiple terminal devices.

[0061] DCCH (Dedicated Control Channel) is a logical channel for transmitting dedicated control information bidirectionally (point-to-point) between terminal equipment and base station equipment. That's fine. Dedicated control information may be control information specific to each terminal device. DCCH may be used when the terminal device has an RRC connection.

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

[0063] MTCH (Multicast Traffic Channel) transmits data from base station equipment to terminal equipment. It may be a point-to-multipoint downlink channel for this purpose. The MTCH may be a multicast logical channel. The MTCH may be used by a terminal device only when the terminal device receives MBMS.

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

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

[0066] SC-MCCH (Single Cell Multicast Control Channel) is a point-to-multipoint system used to send MBMS control information for one or more SC-MCCHs from a base station to a terminal device. It can be a downlink channel. SC-MCCH is a logical channel for multicast. Good. SC-MCCH means that the terminal device receives MBMS using SC-PTM, or the terminal device uses SC-PTM. It may only be used by the relevant terminal device when it is interested in receiving MBMS.

[0067] Logical channel and transport channel of the uplink in E-UTRA and / or NR Let's explain mapping.

[0068] CCCH is an uplink transport channel, UL-SCH (Uplink Shared Channel). It can be mapped to this.

[0069] DCCH is an uplink transport channel, also known as UL-SCH (Uplink Shared Channel). It can be mapped to this.

[0070] DTCH is an uplink transport channel, UL-SCH (Uplink Shared Channel). It can be mapped to this.

[0071] Logical channel and transport channel of the downlink in E-UTRA and / or NR Let's explain mapping.

[0072] BCCH is a downlink transport channel, also known as BCH (Broadcast Channel), and / or This can be mapped to DL-SCH (Downlink Shared Channel).

[0073] PCCH is mapped to PCH (Paging Channel), which is a downlink transport channel. That's fine.

[0074] CCCH is a Downlink Shared Channel (DL-SCH), which is a downlink transport channel. It can be mapped to this.

[0075] DCCH is a Downlink Shared Channel (DL-SCH), which is a downlink transport channel. It can be mapped to this.

[0076] DTCH stands for Downlink Shared Channel (DL-SCH), which is a downlink transport channel. It can be mapped to this.

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

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

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

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

[0081] 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 is The NR RLC may have the function of reassembling and reordering the data provided from the lower layer and providing it to the upper layer. The NR RLC provides the data provided from the PDCP of the upper layer with a sequence number independent of the sequence number added by the PDCP. The NR RLC may have a function to add numbers. The NR RLC may also have a function to segment the data provided by the PDCP and provide it to lower layers. Furthermore, the NR RLC may have a function to reassemble the data provided by lower layers and provide it to higher layers. The RLC may also have a data retransmission function and / or an automatic repeat request (ARQ) function. The RLC may also have a function to perform error correction using ARQ. To perform ARQ, control information indicating the data requiring retransmission is sent from the RLC receiver to the transmitter. It can be called a status report. Also, the status is sent from the RLC transmitter to the receiver. The instruction to send a report can be called a "poll." Also, RLC detects data duplication. It may have the function to perform. RLC may also have the function to discard data. RLC has Transparent Mode (TM), Unacknowledged Mode (UM), and Response There can be three modes (AM: Acknowledged Mode). In TM, data received from the upper layer is not split, and the RLC header does not need to be added. TM RLC entities are unidirectional. A unidirectional entity, and a transmitting™ RLC entity. It may be set as, or as a receiving™ RLC entity. In UM, it is a higher layer. The received data will be split and / or combined, an RLC header will be added, etc., but data retransmission control is not required. The UM RLC entity may be a unidirectional entity or a bidirectional entity. If the UM RLC entity is a unidirectional entity, it may be set as a transmitting UM RLC entity or a receiving UMRLC entity. If the UM RLC entity is a bidirectional entity In some cases, UM RRC entities are on both the transmitting and receiving sides. It may be configured as an AM RLC entity consisting of the following. AM may perform splitting and / or joining of data received from the upper layer, adding an RLC header, data retransmission control, etc. The AM RLC entity is a bidirectional entity and may be configured as an AM RLC consisting of a transmitting side and a receiving side. Note that TM provides to the lower layer The data provided by and / or from lower layers may be called a TMD PDU. The data provided by and / or from lower layers in UM may be called a UMD PDU. The data provided by or from lower layers in AM may be called an AMD PDU. The RLC PDU format used in E-UTRA RLC and the RLC PDU format used in NR RLC may be different. Furthermore, there may be data RLC PDUs and control RLC PDUs. The data RLC PDU may be called an RLC DATA PDU (RLC Data PDU). Good. Also, the control RLC PDU can be called an RLC CONTROL PDU (RLC Control PDU, RLC Control PDU, RLC Control PDU).

[0082] This section describes an example of PDCP functionality. PDCP can be referred to as the PDCP sublayer. PDCP may have the function of maintaining sequence numbers. Furthermore, PDCP efficiently transmits user data such as IP packets and Ethernet frames over the wireless section. It may have a header compression / decompression function for this purpose. 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(registered trademark) Header Compression) protocol. Furthermore, PDCP may also have data encryption and decryption functions. Additionally, PDCP may also have data integrity protection and integrity verification functions. Good. PDCP may also have a re-ordering function. PDCP may also have a PDCP SDU retransmission function. PDCP may also have a data discard function using a discard timer. PDCP may also have a duplication function. 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. Also, the PDCP PDU format used in E-UTRA PDCP and the PDCP PDU format used in NR PDCP may be different. Furthermore, a PDCP PDU may include: It is acceptable to have both a data-oriented PDCP PDU and a control-oriented PDCP PDU. The data-oriented PDCP PDU may be called a PDCP DATA PDU (PDCP Data PDU). The control-oriented PDCP PDU may be called a PDCP CONTROL PDU (PDCP Control PDU).

[0083] In PDCP, the COUNT value may be used when performing encryption or integrity protection processing. The COUNT value is a PDCP state variable, HFN (Hyper Frame Number), and is added to the header of the PDCP PDU. It may consist of a sequence number (SN). The sequence number is Each time a PDCP DATA PDU is generated in the transmitting PDCP entity, 1 may be incremented. HFN may be incremented each time the sequence number reaches its maximum value in both the transmitting and receiving PDCP entities. Additionally, COUNT in both the transmitting and receiving PDCP entities may be incremented. To manage values, some or all of the following state variables (A) through (F) may be used. (A) A state variable that indicates the COUNT value of the next PDCP SDU to be sent. Named TX_NEXT It can be a Tate variable. (B) In this PDCP entity, indicate the sequence number of the next PDCP SDU to be transmitted. State variable. It can be named Next_PDCP_TX_SN. (C) HFN used to generate the COUNT value of PDCP PDU in this PDCP entity A state variable that represents a value. It can 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) In the receiving PDCP entity, the sequence of PDCP SDUs that are expected to be received next A state variable indicating the 'next_PDCP_RX_SN' number. It can 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.

[0084] Furthermore, in PDCP, reordering refers to the receiving buffer of the PDCP SDU. This process involves storing the data in a 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 the received PDCP DATA PDU is the same as 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 received PDCP DATA PDU has not been received (a PDCP DATA PDU has been lost), the received PDCP DATA PDU is converted to a PDCP SDU and stored in the reordering buffer, all the lost PDCP DATA PDUs are received, and the PDCP SDUs are passed to the PDCP SDU. After conversion, the process of passing the data to the upper layer may be performed. In reordering, a reordering timer (named t-Reordering) is used to detect the loss of PDCP data PDUs. A timer may be used. Additionally, some or all of the following state variables (A) through (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) In the receiving PDCP entity, the sequence of PDCP SDUs that are expected to be received next A state variable indicating the 'next_PDCP_RX_SN' number. It can 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) In ​​the receiving PDCP entity, the PDCP SDUs awaiting reception that have not been distributed to the upper layer This is a state variable that shows the COUNT value of the first PDCP PDU. The state variable is named RX_DELIV. That's fine. (E) In the receiving PDCP entity, the PDCP PDU of the PDCP SDU that was last delivered to the upper layer A state variable indicating the sequence number. The state is named Last_Submitted_PDCP_RX_SN. It can be a variable. (F) In the receiving PDCP entity, the PDCP PDU that started the reordering timer A state variable that indicates the next COUNT value after the current COUNT value. This can be a state variable named RX_REORD or a state variable named Reordering_PDCP_RX_COUNT.

[0085] This section explains status reporting in PDCP. In a DRB (AM DRB: Acknowledged Mode Data Radio Bearer) using Acknowledged Mode RLC, where the transmission of PDCP status reports is configured from a higher layer, a receiving PDCP entity triggers the PDCP status report when any of the following conditions (A) to (D) are met. This is also good. In addition, in a DRB (UM DRB: Unacknowledged Mode Data Radio Bearer) that uses RLC in Unacknowledged Mode and is configured to send PDCP status reports from the upper layer, The receiving PDCP entity may trigger a PDCP status report when it satisfies condition (C) below. (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) This PDCP environment allows the upper layer to release DAPS (Dual Active Protocol Stack). The Titi has been reconfigured and a parameter named "daps source release" has been set. ru.

[0086] 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.

[0087] In this embodiment of the present invention, a PDCP entity of a UM DRB that is configured to send a PDCP status report 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 that has determined that a request for PDCP data recovery has been received from the higher layer may, based on the request for PDCP data recovery from the higher layer, create a PDCP status report in the receiving PDCP entity and submit the created PDCP status report to the lower layer via the transmitting PDCP entity. The lower layer is the UM RLC entity of the RLC bearer associated with the PDCP entity. That's fine. In the embodiments of the present invention, if the UM DRB is not a DAPS bearer, the PDCP entity of the UM DRB that has been configured to send a PDCP status report from the upper layer may determine that it has been requested to perform PDCP data recovery from the upper layer. 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 above-mentioned PDCP data recovery may be any other name that means requesting the PDCP to send a status report from the upper layer.

[0088] ROHC will be explained. In the embodiments of the present invention, ROHC may be replaced with ROHC protocol. ROHC has the function of compressing header information such as IP, UDP, TCP, and RTP, and It may have a decompression function. In ROHC, the compressor may have a header compression function that compresses header information. Also in ROHC, the decompressor may have a header decompression function that decompresses header information. The compressor may perform header compression using the context it possesses. The decompressor may perform header decompression using the context it possesses. In the 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. The context in the compressor and decompressor may be maintained for each IP flow. A context identifier (CID) may be used to identify the context. Information on the maximum value of the context identifier, header compression / decompression. Profile information, which indicates the method, is compressed before header compression / decompression. Negotiations can take place between the machine and the defrosting machine.

[0089] In ROHC, header information is divided into static parts and dynamic parts. They can be similar. The static part of header information in ROHC can be the information in the header of each packet belonging to an IP flow that hardly changes. Examples of static parts of header information in ROHC are 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 information may include the following. Furthermore, the dynamic part of the header information in ROHC may be the information within the header information of each packet belonging to an IP flow that can change from packet to packet. The dynamic part of the header information in ROHC may include, for example, the traffic class and hop limit in the IPv6 header, the Type of service and Time to Live in the IPv4 header, the checksum in the UDP header, and the RTP sequence number and RTP timestamp in the RTP header. That's fine.

[0090] ROHC compressors have IR (Initialization and Refresh) states and FO (First Order) states. There can be three states: Tate, SO (Second Order) state, and IR state. If available, the compressor may send all header information to the decompressor without compressing it. If the FO state is used, the compressor may compress most of the static portion of the header information to be compressed, and send some static and dynamic portions to the decompressor uncompressed. If the SO state is used, the header compression ratio will be the highest, and the compressor will send RTP Only limited information, such as sequence numbers, may be transmitted.

[0091] The ROHC decompressor can have three states: NC (No Context) state, SC (Static Context) state, and FC (Full Context) state. The initial state of the decompressor is the NC state. This is acceptable. If the context is obtained in the NC state and the header decompression is performed correctly, the system may transition to the FC state. If header decompression fails repeatedly in the FC state, the system may transition to the SC state or the NC state.

[0092] 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.

[0093] This section describes an example of SDAP functionality. SDAP is a Service Data Adaptive Protocol Layer (SAP). SDAP is a bis-data adaptive protocol layer. SDAP transmits data from the 5GC110 to the terminal via the base station equipment. Mapping the downlink QoS flow sent to the device with the data radio bearer (DRB) (map SDAP may have the function of mapping (mapping) and / or mapping the uplink QoS flow sent from the terminal device to the 5GC110 via the base station device to the DRB. SDAP may also have the function of storing mapping rule information. SDAP may also have the function of storing QoS flow identifiers (QoS Flow ID: QFI). It may have a function to perform marking. Furthermore, an SDAP PDU may consist of a data SDAP PDU and a control SDAP PDU. The data SDAP PDU may be called an SDAP DATA PDU (SDAP Data PDU). The control SDAP PDU may be called an SDAP CONTROL PDU (SDAP Control PDU). Note that there may be only one SDAP entity for each PDU session of a terminal device.

[0094] An example of RRC functionality is described below. RRC may have broadcast functionality. RRC may have paging functionality from EPC104 and / or 5GC110. It is permissible to have it. The RRC may have a paging function from the eNB102 connected to the gNB108 or 5GC100. The RRC may also have an RRC connection management function. The RRC may also have a wireless base It may have an error control function. The RRC may also have a cell group control function. Furthermore, the RRC may have a mobility control function. The RRC may also have terminal device measurement reporting. The RRC may also have a terminal device measurement reporting control function. Furthermore, the RRC may have a QoS management function. Furthermore, the RRC may have a wireless link failure detection and recovery function. The RRC may also have an RRC Me Using messages, broadcasting, paging, RRC connection management, wireless bearer control, and cell group management are performed. You may perform mobility control, terminal device measurement reporting and terminal device measurement reporting control, QoS management, wireless link failure detection and recovery, etc. Furthermore, if used in E-UTRA RRC... The RRC messages and parameters used may differ from those used in NR RRC.

[0095] RRC messages may be sent using the logical channel BCCH, or the logical channel PCCH. It may be sent using, or it may be sent using the CCCH of the logical channel, or it may be sent using the DCCH of the logical channel, or it may be sent using the MCCH of the logical channel.

[0096] 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.

[0097] RRC messages sent in the uplink (UL) direction using CCCH include, for example, RRC Setup Request messages, RRC Resume Request messages, RRC Reestablishment Request messages, and RRC System Information Request messages. This may include messages such as RRC System Info Request. Other examples include RRC Connection Request, RRC Connection Resume Request, and RRC Connection Reestablishment Request. This may include, for example, other RRC messages.

[0098] RRC messages sent in the downlink (DL) direction using CCCH include, for example, RRC Connection Reject messages, RRC Connection Setup messages, RRC Connection Reestablishment messages, and RRC Connection Reestablishment Reject messages. Good. It may also include messages such as RRC Reject, RRC Setup, and RRC Resume. It's okay to be born.

[0099] RRC messages sent in the uplink (UL) direction using DCCH include, for example, measurement report messages. Sage (Measurement Report), RRC Connection Reconfiguration Complete message, RRC Connection Setup Complete message, RRC Connection Reestablishment Complete message This may include messages such as Security Mode Complete and UE Capability Information. It may also include, for example, Measurement Report, RRC Reconfiguration Complete, and RRC Set... RRC Setup Complete message, RRC Reestablishment Complete message, RRC Resume Complete message, security mode This includes messages such as Security Mode Complete, UE Capability Information, and Counter Check Response. It is acceptable to include other RRC messages.

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

[0101] Let's explain an example of NAS functionality. A NAS may have authentication functionality. Also, a NAS can be mobile... It should have a mobility management function. Also, a NAS should have security control functions. You can have it.

[0102] The aforementioned functions of PHY, MAC, RLC, PDCP, SDAP, RRC, and NAS are just examples, and some of each function may be present. Not all of these features need to be implemented. Also, some or all of the functionality of each layer may be included in other layers.

[0103] Furthermore, above the AS layer of the terminal device (not shown), there are the IP layer, and above the IP layer, the TCP (Transmission Control Protocol) layer, UDP (User Datagram Protocol) layer, etc. It is permissible to do so. Furthermore, an 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. IP layer, TCP layer, UDP layer, etc. An application layer may exist above layers such as the Ethernet layer and PDU layer. The application layer may include SIP (Session Initiation Protocol) and SDP (Session Description Protocol), which are used in IMS (IP Multimedia Subsystem), one of the service networks standardized by 3GPP. RTP (Real-time Transport Protocol) is used for communication, and / or RTCP (Real-time Transport Control Protocol), HTTP (HyperText Transfer Protocol), etc. are used for media communication control. Rotor may be included. The application layer may also include codecs for various media. The RRC layer may be a layer above the SDAP layer.

[0104] 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 in which an RRC connection has been established may include the state in which UE122 holds some or all of the UE context described below. The state in which an RRC connection has been established may also include the state in which UE122 can send and / or receive unicast data. Furthermore, when the RRC connection is suspended, UE122 may be in the RRC_INACTIVE state. Also, UE122 may be in the RRC_INACTIVE state when it is connected to a 5GC and the RRC connection is suspended. When neither in the RRC_INACTIVE state nor the RRC_INACTIVE state, UE122 may be in the RRC_IDLE state.

[0105] Note that when UE122 is connected to EPC, it does not have the RRC_INACTIVE state, but E-UTRAN The RRC connection may be suspended. If UE122 is connected to EPC, when 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 layer above the RRC layer of UE122 (e.g., the NAS layer) will transition to the RRC_IDLE state if UE122 retains the UE's AS context, E-UTRAN has permitted the resumption of the RRC connection, and UE122 has transitioned from the RRC_IDLE state to the RRC_CONNECTED state. When it is necessary to transition to a different state, the resumption of a suspended RRC connection may be initiated.

[0106] The definition of "sleep" may differ between the UE122 connected to EPC104 and the UE122 connected to 5GC110. Furthermore, when UE122 is connected to EPC (in a dormant state of RRC_IDLE) and when UE122 is connected to 5GC (in a dormant state of RRC_INACTIVE), the UE122 recovers from dormancy. The conclusions can differ in all or part.

[0107] Note that the RRC_CONNECTED state, RRC_INACTIVE state, and RRC_IDLE state are referred to as the connection state. It can be called connected mode, inactive mode, or idle mode, or RRC connected mode, RRC inactive mode, or RRC idle mode.

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

[0109] 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.

[0110] This section describes cell groups, which are configured on terminal devices by base station equipment. A cell group may consist of one special cell (SpCell). Furthermore, 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. Note that the MAC entity is the master cell group. When associated with a Master Cell Group (MCG), SpCell may mean Primary Cell (PCell). Similarly, when a MAC entity is associated with a Secondary Cell Group (SCG), SpCell may mean Primary SCG Cell (PSCell). If not specified, SpCell can mean PCell. PCell, PSCell, and SCell are service It is a SpCell. SpCell may support PUCCH transmission and contention-based random access, and SpCell may also be always activated. 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 used when the terminal device re-establishes the RRC connection. It may be a cell used in the connection re-establishment procedure. Also, PCell is used during handover. A cell may be used in the dam access procedure. A PSCell may be used in the random access procedure when adding a secondary node (SN), as described later. A SpCell may be used for purposes other than those mentioned above. If a cell group consists of a SpCell and one or more SCells, it can be said that a carrier aggregation (CA) is set up for this cell group. For configured terminal devices, a cell that provides additional wireless resources to a SpCell can be considered an SCell.

[0111] A group of serving cells configured by RRC, with the uplink within that group configured. For cells that are being referred to as the same timing reference cell and the same time A cell group that uses the Timing Advance value can be called a Timing Advance Group (TAG). Also, a TAG that includes a MAC entity SpCell is TAG can refer to the Primary Timing Advance Group (PTAG). Any TAG other than PTAG can refer to the Secondary Timing Advance Group (STAG).

[0112] Furthermore, in venues where Dual Connectivity (DC) or Multi-Radio Dual Connectivity (MR-DC) is implemented. In addition, cell groups may be added to terminal devices from base station devices. DC refers to the first base A cell group is formed by a ground station device (first node) and a second base station device (second node). It is acceptable for this to be a technology that uses wireless resources to perform data communication. MR-DC is included in DC. It is acceptable for this to be a technical concept. To perform data center operations, the first base station equipment may add a second base station equipment. The first base station equipment may be called a Master Node (MN). The cell group formed by the Master Node may be called a Master Cell Group (MCG). The second base station equipment may be called a Secondary Node (SN). Furthermore, the cell group formed by the secondary node may be called a Secondary Cell Group (SCG). Note that the master node and secondary node are the same base station equipment. It may be configured within the structure.

[0113] 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.

[0114] 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.

[0115] In a terminal device, there may be one MAC entity for each cell group. For example, if a DC or MR-DC is configured in the terminal device, there may be one MAC entity for the MCG and one MAC entity for the SCG. The MAC entity for the MCG in the terminal device may exist in all states (RRC idle state, RRC connected state, and RRC inactive state). In terminal devices (such as state), it may always be established. Also, the MAC entity for SCG in a terminal device may be created by the terminal device when SCG is set up in the terminal device. Also, the MAC entity for each cell group of the terminal device The configuration may be performed by receiving an RRC message from the base station equipment. In EN-DC and NGEN-DC, the MAC entity for MCG may be an E-UTRA MAC entity. The MAC entity for SCG may be an NR MAC entity. Also, in NE-DC Furthermore, the MAC entity for MCG may be an NR MAC entity, and the MAC entity for SCG may be an E-UTRA MAC entity. Also, in NR-DC, MCG and SCG The MAC entities for each can both be NR MAC entities. Note that there is one MAC entity for each cell group, and there is one MAC entity for each SpCell. It can be rephrased as "exists." Also, one MAC entity for each cell group can be rephrased as one MAC entity for each SpCell.

[0116] Let me explain about wireless bearers. In E-UTRA, SRB0 through SRB2 may be defined, and... Other SRBs may be defined. NR may have SRB0 through SRB3 defined, and other SRBs may be defined. SRB0 may be an SRB for RRC messages transmitted and / or received using the logical channel CCCH. SRB1 may be an SRB for RRC messages and for NAS messages before SRB2 is established. RRC messages transmitted and / or received using SRB1 may include piggybacked NAS messages. All RRC and NAS messages transmitted and / or received using SRB1 include logical The DCCH channel may be used. SRB2 may be an SRB for NAS messages and for RRC messages containing logged measurement information. All RRC and NAS messages transmitted and / or received using this method have a logical chat. Nell's DCCH may be used. Also, SRB2 may have a lower priority than SRB1. SRB3 is a specific RRC message when EN-DC, NGEN-DC, NR-DC, etc. are configured on the terminal device. It may be an SRB for transmitting and / or receiving. Transmitting and / or receiving using SRB3 All RRC and NAS messages may use the DCCH logical channel. Other SRBs may be provided for other purposes. The DRB may be a wireless bearer for user data. RRC messages transmitted and / or received using the DRB A logical channel (DTCH) may be used for this purpose.

[0117] This section describes wireless bearers in terminal devices. Wireless bearers include RLC bearers. Good. An RLC bearer may consist of one or two RLC entities and a logical channel. When a bearer has two RLC entities, the RLC entity is the TM RLC entity. and / or in a unidirectional UM mode RLC entity, this may be a transmitting RLC entity and a receiving RLC entity. SRB0 may consist of one RLC bearer. RLC bearer of SRB0 SRB0 may consist of TM's RLC entity and logical channel. SRB0 may always be established in terminal devices in all states (RRC idle state, RRC connected state, and RRC inactive state, etc.). SRB1 may be established and / or set on a 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 AM's RLC entity and logical channel. SRB2 may be established and / or set on a terminal device by an RRC message received from the base station device by a terminal device in the RRC connected state with AS security activated. SRB2 consists of one PDCP entity, It may consist of one or more RLC bearers. The RLC bearer of SRB2 may consist of AM RLC entities and logical channels. Note that the PDCP on the base station equipment side of SRB1 and SRB2 may be located on the master node. SRB3 is a second in EN-DC, NGEN-DC, or NR-DC. When a secondary node is added or a secondary node is changed, a DRB may be established and / or configured on the 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. 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 bearers of SRB3 may consist of an AM RLC entity and a logical channel. The base station side PDCP of SRB3 may be located on the secondary node. DRB is established and / or configured on the 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. Sage may establish and / or configure one or more DRBs on a terminal device. A DRB may consist of one PDCP entity and one or more RLC bearers. The RLC bearers of a DRB may consist of AM or UM RLC entities and logical channels.

[0118] In MR-DC, a wireless bearer on the master node where PDCP is located can be called an MN-terminated bearer. Also, in MR-DC, a secondary node A wireless bearer on which a PDCP is placed is called an SN-terminated bearer. That's fine. Also, in MR-DC, a wireless bearer where the RLC bearer exists only in the MCG can be called an MCG bearer. Furthermore, in MR-DC, if the RLC bearer exists only in the SCG... A wireless bearer that has both an MCG and an SCG can be called an SCG bearer. Also, in a DC, a wireless bearer that has both an RLC bearer and an SCG can be called a split bearer.

[0119] 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.

[0120] For RLC bearers established and / or configured in cell groups 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 cell groups 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 an MN termination MCG bearer may be either E-UTRA PDCP or NR PDCP. That is acceptable. Also, if EN-DC is set on the terminal device, other bearer-type wireless base The PDCP established and / or set for the Ara, i.e., the MN termination split bearer, MN termination SCG bearer, SN termination MCG bearer, SN termination split bearer, and SN termination SCG bearer, is NR PDCP This is acceptable. Also, if NGEN-DC, NE-DC, or NR-DC is configured on the terminal device, all PDCP entities established and / or configured for wireless bearers in the bearer type. It is acceptable for it to be NR PDCP.

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

[0122] Note that regardless of whether MR-DC is configured or not, the master node is eNB102 and EPC104 is the core The network configuration can be called E-UTRA / EPC. A network configuration with eNB102 as the master node and 5GC110 as the core network can be called E-UTRA / 5GC. A network configuration with gNB108 as the master node and 5GC110 as the core network can be called NR, or NR / 5GC. MR-DC If this setting is not configured, the master node mentioned above may refer to the base station device that communicates with the terminal device.

[0123] Next, we will explain handover in LTE and NR. Handover may be the process by which UE122, which is 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). Note that the information element named MobilityControlInfo mentioned above is called Mobility Control Configuration Information. This can be rephrased as an element, or mobility control setting, or mobility control information. Furthermore, the information element named ReconfigurationWithSync mentioned above can be referred to as a synchronized reconfiguration information element, or synchronized This can be rephrased as reconfiguration with sync. Furthermore, the RRC message instructing a handover may be a message indicating movement to another RAT's cell (e.g., MobilityFromEUTRACommand or MobilityFromNRCommand). Also, handover can be rephrased as reconfiguration with sync. Additionally, the conditions under which UE122 can perform a handover are: AS security is activated, SRB2 is established, and at least one DRB is established. It may include some or all of the things that are present.

[0124] This document describes the flow of RRC messages transmitted and received between terminal devices and base station devices. Figure 4 shows the procedure for various settings in the RRC according to an embodiment of the present invention. This figure shows an example of the flow. Figure 4 shows an example of the flow when an RRC message is sent from the base station equipment (eNB102, and / or gNB108) to the terminal equipment (UE122).

[0125] In Figure 4, the base station device creates an RRC message (step S400). The creation of the RRC message by the base station device involves the base station device receiving broadcast information (SI: System Information) and page This may be done to distribute ping information. Also, the creation of RRC messages in base station equipment is The base station equipment may perform processing on a specific terminal device. The processing to be performed on a specific terminal device may include, for example, security settings, RRC connection reconfiguration, and other This may include processes such as handover to a RAT, suspension of RRC connection, and release of RRC connection. RRC connection reconfiguration processes may include, for example, control of wireless bearers (establish, change, release, etc.), control of cell groups (establish, add, change, release, etc.), measurement setting, handover, security key update, etc. Furthermore, the creation of RRC messages in the base station equipment is as follows: This may be done in response to an RRC message sent from a terminal device. Responses to transmitted RRC messages include, for example, responses to RRC setup requests and RRC reconnection requests. This may include responses to requests, responses to RRC restart requests, etc. RRC messages include various informational notifications and parameters for configuration. These parameters are fields and / or information Elements are often referred to as such and are described using a syntax called ASN.1 (Abstract Syntax Notation One). It is permissible to do so. In the embodiments of this invention, the term "parameter" may also be used interchangeably with "information."

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

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

[0128] 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, it is transmitted and received between eNB102 and UE122. The RRC message of E-UTRA may contain the RRC message of NR in container form. Also, in NE-DC, the RRC message of NR transmitted and received between gNB108 and UE122 may contain the RRC message of E-UTRA in container form. RRC messages for SCG side configuration may be transmitted and received between the master node and the secondary node.

[0129] Furthermore, not only when using MR-DC, but also when sending the RRC message for E-UTRA from eNB102 to UE122 The sage may contain an RRC message for NR, and the RRC message for NR sent from gNB108 to UE122 may contain an RRC message for E-UTRA.

[0130] This section describes an example of parameters included in an RRC message regarding the reconfiguration of an RRC connection in NR, as shown in Figure 4. This is an example of an ASN.1 description representing fields and / or information elements related to wireless bearer settings. Figure 8 also shows the message regarding the reconfiguration of the RRC connection in E-UTRA, as shown in Figure 4. This is an example of an ASN.1 description representing fields and / or information elements related to wireless bearer settings included in the document. In the examples of ASN.1 in embodiments of the present invention, not limited to Figures 7 and 8, <omitted> and <omitted> indicate that other information is omitted, not part of the ASN.1 notation. Information elements may also be omitted where <omitted> or <omitted> is not present. Furthermore, the examples of ASN.1 in embodiments of the present invention do not strictly follow the ASN.1 notation method. The examples of ASN.1 in embodiments of the present invention represent examples of parameters in an RRC message in embodiments of the present invention, and other names or notations may be used. Also, the explanation of the ASN.1 examples is... To avoid complexity, only examples of key information closely related to one embodiment of the present invention are shown. Furthermore, parameters described in ASN.1 are not distinguished as fields, information elements, etc. In some cases, all of these are referred to as information elements. Also, in the embodiment of the present invention, the RRC message The fields, information elements, etc., included and described in ASN.1 can also be referred to as information. It can also be called a meter. Note that the message regarding the resetting of the RRC connection may be the RRC reset message in NR, or the RRC connection reset message in E-UTRA. It can be a message.

[0131] In Figure 7, the information elements represented by RadioBearerConfig may be information elements used for setting, changing, releasing, etc., radio bearers such as SRB and DRB. The base may include PDCP configuration information elements and SDAP configuration information elements, as described later. RadioBearerConfig The information element represented by may be referred to as the wireless bearer configuration information element or wireless bearer configuration. The information element represented by SRB-ToAddMod is included in the information element represented by RadioBearerConfig. This may be an information element indicating the SRB (Signaling Radio Bearer) setting. The information element represented may be referred to as the SRB configuration information element or SRB configuration. The information element represented as SRB-ToAddModList may be a list of SRB configurations. The information element represented as DRB-ToAddMod, which is included in the information element represented as RadioBearerConfig, is DRB (Data Radio Bearer ) This may be an information element that indicates the setting. The information element represented by DRB-ToAddMod may be DRB setting information This can be rephrased as an 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 rephrased as wireless bearer settings.

[0132] The field represented by srb-Identity within the SRB configuration information element is information about the SRB identifier (SRB Identity) of the SRB to be added or modified, and may be an identifier that uniquely identifies the SRB on each terminal device. This can be referred to as the SRB identifier field, or simply the SRB identifier. This can be rephrased as a "radar identifier."

[0133] The field represented by drb-Identity within the DRB configuration information element is information about the DRB identifier (DRB Identity) of the DRB to be added or modified, and may be an identifier that uniquely identifies the DRB on each terminal device. This can be referred to as the DRB identifier field, or simply the DRB identifier. While the DRB identifier value in the example in Figure 7 is an integer between 1 and 32, it can take other values. For DC, the DRB identifier is UE122. It may be unique within its scope. Also, the DRB identifier may be replaced with the wireless bearer identifier. .

[0134] In the DRB configuration information elements, the field represented by cnAssociation is associated with the wireless bearer, either with the field represented by eps-bearerIdentity (described later) or with the field represented by SDAP-Config (described later). This field may indicate whether an information element is associated with another information element. It is represented by cnAssociation. The field may be referred to 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 connects to EPC104. The field may include an information element (SDAP-Config) that indicates the SDAP settings described later when the terminal device is connected to the core network 5GC110. The field indicated by eps-bearerIdentity may be a field that indicates an EPS bearer identifier that identifies the EPS bearer. The indicated field may be referred to as the EPS bearer identifier field or EPS bearer identifier.

[0135] The information elements represented by SDAP-Config are related to the configuration or reconfiguration of SDAP entities. It may also be the case that the information elements represented by SDAP-Config are SDAP configuration information elements or SDAP settings. You can rephrase it.

[0136] The field indicated by pdu-session in the SDAP configuration information element is the corresponding wireless bearer The field indicated by pdu-session may be the PDU session identifier of the PDU session to which the QoS flow mapped to belongs. It can be rephrased as a session identifier. A PDU session identifier is the PDU session identifier of a PDU session. It may be a configuration identifier. Also, the relevant wireless bearer is the DRB containing this SDAP configuration field. It can refer to the DRB associated with the DRB identifier in the settings.

[0137] 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 indicated field may be rephrased as the additional QoS flow field or additional QoS flow. The above-mentioned QoS flow is the PDU set indicated by the PDU session included in this SDAP configuration information element. It can be a QoS flow for the configuration. Also, the relevant wireless bearer includes this SDAP configuration field. It can refer to the DRB associated with the DRB identifier in the DRB settings.

[0138] Furthermore, the field indicated by `mappedQoS-FlowsToRelease` included in the SDAP configuration information element may be information indicating a list of QoS flow identifier information elements of QoS flows whose correspondence should be released from among the QoS flows mapped to the relevant wireless bearer. The field indicated by `mappedQoS-FlowsToRelease` is referred to as the QoS flow field to be released or the QoS flow to be released. You can change it. The QoS flow described above is the PDU session indicated by the PDU included in this SDAP configuration information element. This can be the session's QoS flow. Also, the relevant wireless bearer is the SDAP configuration field. This can refer to the DRB associated with the DRB identifier in the DRB settings that include it.

[0139] In addition, the SDAP configuration information elements include a field indicating whether or not an uplink SDAP header exists in the uplink data transmitted via the relevant wireless bearer, a field indicating whether or not a downlink SDAP header exists in the downlink data received via the relevant wireless bearer, and a field indicating whether or not the relevant wireless bearer is the default wireless bearer (default DRB). The field may include an indication of this. The relevant wireless bearer may be the DRB associated with the DRB identifier in the DRB setting that includes this SDAP setting field.

[0140] Furthermore, the information elements represented by PDCP-Config within the SRB configuration information elements and DRB configuration information elements The element may also be an information element related to the configuration of the NR PDCP entity. The information element represented by PDCP-Config may be rephrased as a PDCP configuration information element or PDCP configuration. The information elements related to the settings 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.

[0141] 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.

[0142] In Figure 8, the information element represented by RadioResourceConfigDedicated is the setting of the wireless bearer. It may be an information element used for modification, release, etc. The information element represented by SRB-ToAddMod, which is included in the information element represented by RadioResourceConfigDedicated, is SRB (Signaling Radio). The information may also indicate the bearer setting. The information element represented by SRB-ToAddMod is the SRB setting This can be rephrased as an 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, is information indicating the DRB (Data Radio Bearer) setting. It may be a report. The information element represented by DRB-ToAddMod may be rephrased as DRB setting information element or DRB setting. The information element represented by DRB-ToAddModList is a list of information indicating the DRB setting. It is acceptable. Furthermore, either or all of the SRB and / or DRB settings can be referred to as wireless bearer settings.

[0143] The field represented by srb-Identity within the SRB configuration information element is information about the SRB identifier (SRB Identity) of the SRB to be added or modified, and may be an identifier that uniquely identifies the SRB on each terminal device. This can be referred to as the SRB identifier field, or simply the SRB identifier. This can be referred to as a R identifier. The SRB identifier in Figure 8 may have the same role as the SRB identifier in Figure 7.

[0144] In the DRB settings, the field represented by drb-Identity is the DRB identity of the DRB being added or modified. This is information about the DRB Identity, an identifier that uniquely identifies the DRB on each terminal device. It is acceptable. The field represented by drb-Identity within the DRB configuration information element can be referred to as the DRB identifier field or simply the DRB identifier. In the example in Figure 8, the value of the DRB identifier is an integer from 1 to 32, but it can take a different value. Also, the DRB identifier can be referred to as the wireless bearer identifier. To put it another way, the DRB identifier in Figure 8 may have the same role as the DRB identifier in Figure 7.

[0145] The field represented by eps-BearerIdentity within the DRB configuration information elements is for 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 can take a different value. This is acceptable. The EPS bearer identifier in Figure 8 may have the same role as the EPS bearer identifier in Figure 7. Furthermore, the EPS bearer identifier and the DRB identifier may correspond one-to-one in each terminal device.

[0146] Furthermore, the information elements represented by PDCP-Config within the SRB configuration information elements and DRB configuration information elements. This may be an information element related to the configuration of the E-UTRA PDCP entity. The information element represented by PDCP-Config may be referred to as a PDCP configuration information element or PDCP configuration. The information elements related to the settings include a field indicating the size of the sequence number, a field indicating the RObust Header Compression (ROHC) profile, and a reordering field. It may include fields that show the value of the re-ordering timer, etc.

[0147] 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.

[0148] 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.

[0149] The information element represented by RadioResourceConfigDedicated contains DRB-ToReleaseList The represented information element may include information indicating one or more DRB identifiers to be released.

[0150] 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, are represented in RadioBearerConfig in Figure 7. This information may be included in the cell group setting information element, rather than as an information element (not shown). The cell group setting information element is included in the message regarding the reconfiguration of the RRC connection. It is acceptable to refer to the information element regarding cell group settings as the cell group setting information element or cell group setting. The information element regarding NR RLC entity settings is referred to as the RLC setting This can be rephrased as an information element or RLC setting. The information element that indicates logical channel identifier information is The logical channel identifier information element or logical channel identifier may be used as alternative terms. The logical channel configuration information element may be used as a logical channel configuration information element or logical channel identifier. The logical channel identifier may be associated with a wireless bearer identifier.

[0151] 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.

[0152] 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.

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

[0154] 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 is eNB102. It is fine to use either gNB108 or gNB108. Furthermore, the processing unit 502 includes some or all of the functions of various layers (e.g., physical layer, MAC layer, RLC layer, PDCP layer, SDAP layer, RRC layer, and NAS layer). Good. That is, the processing unit 502 includes a physical layer processing unit, a MAC layer processing unit, an RLC layer processing unit, and a PDCP layer processing unit. The R&D unit, SDAP processing unit, RRC layer processing unit, and NAS layer processing unit may include some or all of them.

[0155] Figure 6 is a block diagram showing the configuration of a base station device in an embodiment of the present invention. To avoid making the explanation complicated, Figure 6 shows the main aspects closely related to one embodiment of the present invention. Only the components are shown. The base station equipment mentioned above may be either eNB102 or gNB108.

[0156] The base station device shown in Figure 6 consists of a transmitting unit 600 that sends RRC messages etc. to UE122, a processing unit 602 that creates an RRC message including parameters and sends it to UE122 so that the processing unit 502 of UE122 can perform processing, and a receiving unit 604 that receives RRC messages etc. from 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 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 The NAS layer processing unit may include part or all of it.

[0157] 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.

[0158] Figure 9 is a diagram showing the procedure flow for setting up MBMS reception using SC-PTM. Figure 10 is Figure 9 shows an example of an ASN.1 description representing a field and / or information element included in SIB20 (System Information Block Type 20). Figure 11 also shows an example of an ASN.1 description representing a field and / or information element included in the SC-PTM configuration message (SCPTMConfiguration) in Figure 9.

[0159] 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 transmission unit 600. The receiving unit 500 receives the SIB20. (Step S900).

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

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

[0162] The SC-PTM configuration information includes control information applicable to MBMS reception. For example, the SC-PTM configuration information includes a field represented by sc-mtch-InfoList including the settings of each SC-MTCH in the cell transmitting the information, and a field represented by scptm-NeighbourCellList which is a list of adjacent cells providing MBMS, and includes some or all of fields and / or information elements such as these. A field represented by sc-mtch-InfoList including the settings of each SC-MTCH in the cell transmitting the information, and a field represented by scptm-NeighbourCellList which is a list of adjacent cells providing MBMS, and includes some or all of fields and / or information elements such as these. And includes some or all of fields and / or information elements such as these.

[0163] The sc-mtch-InfoList contains information elements represented by one or more SC-MTCH-Info. Each SC-MTCH-Info includes a field represented by mbmsSessionInfo which is information of the MBMS session, a field represented by g-RNTI which is a Radio Network Temporary Identifier (RNTI) identifying a multicast group (specifically, the SC-MTCH destined for a specific group), DRX information for the SC-MTCH a field represented by sc-mtch-schedulingInfo which is such, and information of neighbouring cells where the MBMS session can receive using the SC-MTCH a field represented by sc-mtch-neighbourCell, including some or all of fields such as etc. mbmsSessionInfo includes a field represented by tmgi which is an identifier identifying the MBMS bearer service a Temporary Mobile Group Identity (TMGI), and a field represented by sessionId which is an identifier of the MBMS session, including some or all of fields such as etc.

[0164] The processing unit 502 of UE122 may perform an SC-MRB (Single Cell MBMS Point to Multipoint Radio Bearer) establishment process which is a radio bearer for receiving an MBMS session using SC-PTM in order to start receiving an MBMS session of interest (step S904). The SC-MRB establishment process may be triggered, for example at the start of the MBMS session, when UE122 enters a cell where the MBMS service of interest is provided via the SC-MRB, when having an interest in the MBMS service, when the limit of UE capabilities where the reception of the MBMS service was suppressed is removed, etc. The SC-MRB establishment process may be performed when UE122 is in the RRC_IDLE state or may be performed when UE122 is in the RRC_CONNECTED state ​​​ This is also acceptable. When the UE122's processing unit 502 performs the SC-MRB establishment process, it 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) Set up an SC-MTCH logical channel to apply to the established SC-MRB, and the MAC entity, Upon receiving the SC-PTM configuration message described above, the cell is instructed to receive the MBMS session in accordance with the SC-PTM configuration message. (C) For the established SC-MRB, configure the physical layer based on the sc-mtch-InfoList described above. ru. (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.

[0165] 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 the MBMS service via SC-MRB, and send it to eNB102 from the transmission unit 504 (not shown). The MBMS interest notification message may also include information on whether to prioritize MBMS service reception over unicast reception. Furthermore, the MBMS interest notification message may be sent when transitioning to the RRC_CONNECTED state after receiving SIB20, or after transitioning to the RRC_CONNECTED state. The MBMS interest notification message may also include information on whether to prioritize MBMS service reception over unicast reception. It may be sent when SIB20 is received during a handover, or when SIB20 is received during the re-establishment of the RRC connection.

[0166] 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 the cell where the SC-MRB is established, when interest in the MBMS service is lost, when the reception of the MBMS service is suppressed due to the limits of UE capabilities, etc. SC-MRB release processing may be performed when UE122 is in the RRC_IDLE state, or when UE122 is in the RRC_CONNECTED state. This may be done at the following time. When the processing unit 502 of UE122 performs the SC-MRB release process, it 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. ru. (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.

[0167] 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 is also standardized. However, both MBMS transmission / reception using SC-PTM and MBMS transmission / reception using MBSFN use E-UTRA as the RAT. The transmission and reception of multicast broadcast services (MBS) using NR (Network Rating) are not yet standardized.

[0168] An example of the operation of UE122 and gNB108 in an embodiment of the present invention will be explained using Figure 12. The terms used in the embodiments of this invention are MBS, MBS service, and MBS. Session and MBS bearer may be equivalent terms and can be used interchangeably. Furthermore, the terms MBS, MBS service, and MBS session, which are used in embodiments of the present invention, are terms that have the same meaning as MBMS, MBMS service, and MBMS session. This is also good. Furthermore, in an embodiment of the present invention, a wireless bearer for MBS reception is established in UE122. And / or may be set. Also, a wireless bearer for MBS transmission may be established and / or set in gNB108. In the embodiments of the present invention, the wireless bearer for MBS is described using the name MRB (Multicast Radio Bearer), but it may be called by another name. Also, in the embodiments of the present invention, the MRB established and / or set in UE122 may be an MRB for receiving MBS in a point-to-multipoint manner, or for receiving MBS in a point-to-one manner. It may be an MRB for receiving via Point-to-Point. Also, in embodiments of the present invention Furthermore, the MRB used for receiving MBS in a point-to-multipoint manner and the MRB used 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-point manner, the MRB may have 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 MBS in a point-to-point manner. It may include one or more RLC bearers for signaling and / or transmitting. One MRB may transmit one MBS. If an RLC bearer has the capability to receive MBS in a multi-to-many manner and the capability to receive MBS one-to-one, 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 one-to-one, may be associated with a single PDCP entity. Furthermore, one or more QoS flows may be associated with an MRB. Note that an MRB for receiving MBS one-to-one (point-to-point) may also be a DRB.

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

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

[0171] As shown in Figure 12, the processing unit 602 of gNB108 may create a first SIB (System Information Block), which is one of the RRC messages, in order to broadcast the information necessary for obtaining control information related to MBS transmission, and send it from the transmitting unit 600 to UE122. The receiving unit 500 of UE122 is above The first SIB described above is received. The first SIB described above may be transmitted via the BCCH logical channel or via another logical channel. Also, regarding the MBS transmission described above... The information required to acquire control information is the MCCH (Multicast Control Channel) logical channel (and This may also be information related to MCCH (which may be referred to as MCCH in the following explanation). The MCCH mentioned above refers to MBS control information and / or MBS configuration information sent from gNB108 to UE122 for one or more MTCH (Multicast Traffic Channel) logical channels (which may be referred to as MTCH in the following explanation). And / or it may be a point-to-multipoint downlink channel for sending MBS information. Also, the above MTCH is a point-to-multipoint downlink channel for sending MBS data from gNB108 to UE122. It can also be a point-to-multipoint downlink channel. Also, the above MCCH is a multipoint link. It may also be a multicast control channel. Furthermore, the aforementioned MTCH may also be a multicast traffic channel. The aforementioned MTCH will only be used by UE122 when UE122 receives an MBS. Therefore, it is acceptable to use it. Note that the above-mentioned MCCH is also known by other names such as MBS-MCCH and NR-MCCH. It is also acceptable to refer to the aforementioned MTCH by other names such as MBS-MTCH, NR-MTCH, etc. Also, the above-mentioned MCCH may be mapped to an MCH (Multicast Channel), which is a downlink transport channel, or may be mapped to a DL-SCH (Downlink Shared Channel), which is a downlink transport channel. Also, the above-mentioned MTCH may be mapped to an MCH (Multicast Channel), which is a downlink transport channel, or may be mapped to a DL-SCH (Downlink Shared Channel), which is a downlink transport channel. Also, the above-mentioned The MBS control information, and / or MBS configuration information, and / or MBS information for one or more MTCH logical channels may be included in the above-mentioned first SIB, or may be included in a second SIB different from the above-mentioned first SIB . (Step S1200)

[0172] The above-mentioned first SIB may include some or all of the parameters such as, for example, a parameter indicating the period in which the content of the MCCH can be changed, a parameter related to the transmission (retransmission) time interval of the MCCH, a parameter indicating the offset of the radio frame in which the MCCH is scheduled, a parameter indicating the slot in which the MCCH is scheduled, a parameter indicating the period of the slot in which the MCCH is scheduled, etc. Note that the parameter related to the transmission (retransmission) time interval of the above-mentioned MCCH may be indicated by the number of radio frames.

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

[0174] The above-mentioned 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-mentioned MBS configuration information message in the form of a list. Also, MBS MTCH parameters exist for each MBS session. Yes, that's fine. For example, for the first MBS session, the first MBS MTCH parameter is the second MBS A second MBS MTCH parameter may exist for each session. In the implementation configuration, the parameters for MBS reception described above are called MBS MTCH parameters. I will use a specific name for this explanation, but another name may be used.

[0175] The MBS MTCH parameter is a parameter related to information about the MBS session, multicast. Parameters indicating the RNTI that identifies the loop (MTCH addressed to a specific group), parameters indicating the logical channel identifier, parameters regarding DRX information for the MTCH, parameters indicating a list of neighboring cells providing the same MBS, and parameters indicating whether ROHC applies to the MBS session. Parameters related to ROHC used in MBS sessions, parameters related to HFN (Hyper Frame Number), parameters related to COUNT, and timers for status reports. It may include some or all of the parameters such as the parameters mentioned above. The parameters related to the information include, for example, some or all of the following parameters: a parameter indicating TMGI (Temporary Mobile Group Identity), which is an identifier for the MBS; a parameter indicating the Session ID, which is an identifier for the MBS (or MBMS) session; a parameter indicating the PDU session to which the MBS session belongs; and a parameter indicating the QoS flow used for the MBS session. It may also include some or all of the above-mentioned MBS MTCH parameters. Furthermore, some or all of the above-mentioned first SIB may be included in the above-mentioned second SIB, or in a third SIB separate from the above-mentioned first and second SIBs.

[0176] 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.

[0177] Furthermore, the MBS configuration information message and / or MBS MTCH parameter are parameters related to the MRB configuration. Meters may be included. Parameters relating to MRB settings may include some or all of the following parameters: an identifier for identifying the MRB, SDAP setting information elements, and PDCP setting information elements. Furthermore, the above-mentioned parameters relating to MRB settings may include one or more RLC bearer setting information elements. The above-mentioned RLC bearer configuration information elements 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. Furthermore, the above-mentioned RLC bearer configuration information elements may be included in an information element separate from the MRB configuration and may be linked to parameters related to the MRB configuration by an identifier that identifies the above-mentioned MRB. Furthermore, the above-mentioned MRB configuration may include a parameter that identifies an RLC bearer that receives MBS in a one-to-many relationship. Furthermore, the above-mentioned MRB configuration may include a parameter that identifies an RLC bearer that receives MBS in a one-to-one relationship. The following parameters may be included: Parameters that identify the RLC bearer that receives the above MBS in a one-to-many manner, and The parameter that identifies the RLC bearer receiving the MBS on a one-to-one basis is the logical channel identifier. That is acceptable. Note that the parameter indicating whether or not ROHC applies to the above-mentioned MBS session... , and / or parameters related to ROHC used in MBS sessions, and / or parameters related to HFN (Hyper Frame Number), and / or parameters related to COUNT, and / or Parameters related to the status report timer are included in the parameters related to MRB settings. It may be included, or it may be included in the PDCP configuration information elements. Also, it may indicate the PDU session as described above. Parameters, and / or parameters indicating the QoS flow, etc., are related to the MRB settings. It may be included, or it may be included in the SDAP configuration information element. Also, the above PDU session is indicated. The parameter may also be the PDU session ID.

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

[0179] In step S1204, the processing unit 502 of UE122 receives the MBS settings in step S1202. Based on the regular information messages, determine whether or not ROHC applies to the MBS session you are interested in. Good. To determine whether ROHC applies to an MBS session of interest, check the MBS configuration information message and / or MBS MTCH parameter mentioned above, which indicates whether ROHC applies. This may be done depending on whether or not a meter is included. That is, the above-mentioned MBS setting information message and If the MBS MTCH parameters for the MBS session of interest include a parameter indicating whether or not ROHC applies, then it is determined that ROHC applies, and the above MBS settings are applied. If the informational message and / or the MBS MTCH parameters for the MBS session of interest do not include a parameter indicating whether or not ROHC applies, it can be assumed that ROHC does not apply. Furthermore, the determination of whether or not ROHC applies is based on the ROHC included in the aforementioned MBS configuration informational message and / or the MBS MTCH parameters for the MBS session of interest. This can be done by the value of a parameter that indicates whether or not it will be done. That is, the above MBS setting information message If the parameter indicating whether ROHC applies, included in the MBS MTCH parameters for the and / or MBS session of interest, is a value indicating that ROHC should be applied, then it is determined that ROHC should be applied, and the above MBS configuration information message and / or the MBS session of interest are sent accordingly. If the parameter indicating whether or not ROHC applies, included in the MBS MTCH parameters, indicates that ROHC does not apply, then it can be concluded that ROHC does not apply. The determination of whether or not ROHC applies is made in the above-mentioned MBS configuration information message and / or the MBS session of interest. The MBS MTCH parameters for this include the parameters related to ROHC used in the MBS session mentioned above. You can make a judgment based on whether or not the data is included. That is, if the above-mentioned MBS configuration information message and / or the MBS MTCH parameters for the MBS session of interest include parameters related to ROHC used in the MBS session, you can determine that ROHC is applied. If the parameters do not include the parameters related to ROHC used in the MBS session In this case, it can be concluded that the ROHC does not apply. Furthermore, the MBS session of interest can be rephrased as the session that UE122 wants to receive, or the session that UE122 is attempting to receive. .

[0180] The parameters related to ROHC used in the above-mentioned MBS session are used for ROHC A parameter related to the maximum value of the context identifier (CID) in ROHC. This may include some or all of the parameters related to the profile used, and parameters indicating whether to continue or reset the ROHC header compression protocol during PDCP re-establishment. It also includes the ROHC used in the aforementioned MBS session. The parameters may include parameters relating 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 relating to the timing at which all header information is obtained may include some or all of the following parameters: a parameter indicating the period during which some or all of all header information may be changed; a parameter indicating the time interval in which all header information is transmitted in terms of the number of wireless frames; a parameter indicating the offset of the wireless frame in which the transmission of all header information is scheduled; a parameter indicating the slot in which the transmission of all header information is scheduled; and a parameter indicating the window length of the slot in which the transmission of all header information is scheduled. It may include the following. All of the above header information refers to all header information among the headers that are subject to compression in ROHC (IP header, UDP header, TCP header, RTP header, etc.). 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.

[0181] Furthermore, in step S1204, the processing unit 502 of UE122, having determined that ROHC applies to the MBS session of interest, determines that ROHC applies to the MBS session of interest. It is reasonable to conclude that obtaining text information is necessary. Also, in step S1204, interest If the processing unit 502 of UE122 determines that ROHC does not apply to a particular MBS session, it may conclude 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.

[0182] 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 is performed when UE122 is RRC_IDLE The transition may be from the RRC_IDLE state or the RRC_INACTIVE state to the RRC_CONNECTED state. The transition from the RRC_IDLE state to the RRC_CONNECTED state of UE122 is when UE122 sets up RRC for gNB108. Send a request message and receive a response from gNB108 to the above RRC setup request message. This can be done by receiving an RRC setup message as a response message. Also, the transition of UE122 from the RRC_INACTIVE state to the RRC_CONNECTED state is when UE122 communicates with gNB108 about RRC reconnection. Send an open request message and receive a response message from gNB108 to the above RRC restart request message. This can be done by receiving RRC restart messages or RRC setup messages. Also, when UE122 transitions from the RRC_IDLE state or RRC_INACTIVE state to the RRC_CONNECTED state, or after UE122 transitions from the RRC_IDLE state or RRC_INACTIVE state to the RRC_CONNECTED state, UE122 sends an RRC message to gNB108 containing information about the MBS session of interest. You can send a message.

[0183] 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 is one or more RLC bears for receiving MBS sessions on a one-to-many basis. A radio bearer including one or more RLC bearers for receiving MBS sessions one-to-one. It is acceptable to do so. Also, establish and / or configure an MRB for receiving MBS sessions one-to-one. This means that an MRB that only has an RLC bearer for receiving MRB sessions in a one-to-many manner will have an MRB session An additional RLC bearer may be established and / or configured for receiving MRB sessions on a one-to-one basis. , an RLC bearer for receiving an established and / or established MBS session one-to-one, as described above This may involve associating the MRB's PDCP entity with only an RLC bearer for receiving MRB sessions in a one-to-many manner. The above ROHC context acquisition process is of interest to UE122. This may be done by receiving an MBS session on a one-to-one basis. (Step S1206)

[0184] Furthermore, the process of obtaining the ROHC context in step S1204 is performed by UE122 as described above. This may be done according to the parameters related to ROHC included in the configuration information message and / or the MBS MTCH parameters for the MBS session of interest. For example, UE122 has all of the above headers According to the parameters regarding the timing at which the header information is obtained, the timing information for when all header information is obtained can be acquired, and ROHC context information can be acquired at the timing when all header information is obtained. Note that UE122 will acquire all the above header information in the RRC of UE122. ROHC context information may be obtained at the timing when all header information is available by obtaining timing information that includes some or all of the obtained timing information according to the parameters regarding the timing when all header information is available, and notifying the MAC entity of UE122 of the information that includes some or all of the obtained timing information. Also, when the RRC of UE122 notifies the MAC entity of UE122 of the information that includes some or all of the obtained timing information, it may also send RNTI information used for one-to-many reception of MBS sessions. Note that in the RRC_IDLE state, RRC_INACTIVE state, or RRC_CONNECTED state, the UE122 receives the above-mentioned MBS configuration information message and / or the MBS MTCH parameters for the MBS session of interest, which include parameters related to ROHC. The process of obtaining the ROHC context in accordance with the above may be performed. 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. 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 reception of MBS or MTCH begins. It is also acceptable to do so. Furthermore, the timing at which all of the above header information can be obtained is when all of the headers that are subject to header compression in ROHC (IP header, UDP header, TCP header, RTP header, etc.) are included. This can be rephrased using other terminology that refers to the timing at which the information is obtained. (Step S1206)

[0185] Furthermore, in step S1204, if the processing unit 502 of UE122 determines that ROHC is not applied to the MBS session of interest, or that it is not necessary to obtain ROHC context information, the processing unit 502 of UE122 transitions to the RRC_CONNECTED state for the purpose of obtaining ROHC context information. It can be determined that no relocation is necessary. Also, in step S1204, the processing unit 502 of UE122 is of interest It was determined that ROHC does not apply to a certain MBS session, or that obtaining ROHC context information is necessary. If it is determined that it is not necessary, the processing unit 502 of UE122 will enter the RRC_IDLE state or the RRC_INNACTIVE state. In this case, it is permissible to receive MBS services without obtaining ROHC context information. In step S1204, if the processing unit 502 of UE122 determines that ROHC is not applied to the MBS session of interest, or that it is not necessary to obtain ROHC context information, then UE122 Processing unit 502 may receive the MBS service without obtaining ROHC context information while in the RRC_CONNECTED state. (Step S1206)

[0186] In step S1204, the processing unit 502 of UE122 receives the MBS settings in step S1202. You may determine whether the regular information message contains parameters related to the Hyper Frame Number (HFN) for an MBS session of interest. The HFN parameters mentioned above may be those that gNB108 uses or is using for MBS session transmission. The above-mentioned parameter relating to HFN may also be a parameter 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, gNB108 uses MBS The HFN of the transmitting PDCP entity used or currently used for session transmission. The latest value may be set as the parameter related to HFN. The above-mentioned parameter related to HFN refers to the parameter related to the timing at which the HFN value is sent from gNB108 using MCCH or MTCH. It is fine to be a data. What is the timing when the HFN value is sent from gNB108 using MCCH or MTCH? For example, a parameter indicating the period during which the HFN value may change, a parameter indicating the time interval in which the HFN value is transmitted in terms of the number of wireless frames, and an offset of the wireless frame in which the HFN value is scheduled. One of the following parameters: a parameter indicating the slot, a parameter indicating the slot in which the HFN value is scheduled, and a parameter indicating the duration (window length) of the slot in which the HFN value is scheduled. It may include part or all of it. gNB108, at the time the HFN value is sent, will determine the HFN of the transmitting PDCP entity that gNB108 uses or is using for MBS session transmission. The new value, or the last HFN value used in the MBS session transmission, or the next MBS session transmission The value of the HFN to be used may be set in the RRC message and / or the PDCP control PDU and transmitted.

[0187] In step S1204, if the processing unit 502 of UE122 determines that the received MBS configuration information message contains parameters related to HFN for the MBS session of interest, 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. In addition, the RRC of UE122 may obtain the value of HFN according to the above-mentioned parameters related to HFN Therefore, it is acceptable to process the PDCP entity of the MRB in UE122 so that it can obtain the value of HFN. The UE122's RRC obtains the timing information for when the HFN value is sent, and notifies the UE122's MAC entity of the information including some or all of the obtained timing information, thereby determining the timing of when the HFN value is sent. It is good to process the UE122's RRC and / or MRB's PDCP entities so that they can obtain the HFN value. Furthermore, when the UE122's RRC notifies the UE122's MAC entity of information including 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 receives the HFN value notified from the upper layer. , or the value of HFN obtained by receiving a PDCP control PDU, is used in the receiving PDCP enterprise It's okay to set it as the HFN for the typography.

[0188] 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. In the RRC_CONNECTED state, the RRC of UE122 receives an RRC message containing the HFN value from gNB108. Alternatively, the HFN value can be obtained by receiving via DCCH. The RRC of UE122 is as described above. The acquired HFN value may also be notified to the PDCP entity of the UE122's MRB. An entity may set the HFN value notified from the upper layer as the HFN of the receiving PDCP entity.

[0189] In step S1204, the processing unit 502 of UE122 receives the MBS settings in step S1202. You may determine whether the regular information message 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 COUNT value that gNB108 uses or is using for MBS session transmission. The COUNT value that gNB108 uses or is using for MBS session transmission It may be the COUNT value, which is a state variable of the transmitting PDCP entity used for or currently using the transmission. When gNB108 sends an MBS configuration information message, gNB108 is MBS The latest value of the COUNT of the transmitting PDCP entity used for transmission. You may set this as a parameter related to COUNT. The above-mentioned parameter related to COUNT is a parameter related to the timing at which the COUNT value is sent from gNB108 using MCCH or MTCH. It's okay. The timing at which the COUNT value is sent from gNB108 using MCCH or MTCH is, for example, A parameter indicating the period during which the COUNT value can be changed, a parameter indicating the time interval in which the COUNT value is transmitted in terms of the number of wireless frames, and an offset of the wireless frame in which the COUNT value is scheduled. Some of the parameters that indicate the COUNT value, the parameter that indicates the slot in which the COUNT value is scheduled, and the parameter that indicates the window length of the slot in which the COUNT value is scheduled, or It may include everything. gNB108 will send the latest COUNT value of the transmitting PDCP entity that gNB108 uses or is using for MBS session transmission at the time the COUNT value is sent. The value of, or the last COUNT value used in MBS session transmission, or the value used in the next MBS session transmission The COUNT value may be set in the RRC message and / or PDCP control PDU and sent.

[0190] In step S1204, if the processing unit 502 of UE122 determines that the received MBS configuration information message contains parameters related to COUNT for the 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. According to the data, the PDCP entity of the MRB in UE122 is processed to obtain the COUNT value. It is also acceptable. The RRC of UE122 follows the parameters regarding the timing of when the above COUNT value is sent. Then, obtain the timing information of when the COUNT value is sent, and obtain part or all of the obtained timing information. By notifying the MAC entity of UE122 of the information including , the timing at which the COUNT value is sent In the process, the UE122 RRC and / or MRB PDCP entities are configured to obtain the COUNT value. It is permissible to do so. Also, when the UE122's RRC notifies the UE122's MAC entity of information including 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 receives the COUNT value obtained by being notified from the upper layer or by receiving the PDCP control PDU, and sends it to the receiving PDCP entity. It can be set as the COUNT value for the ty.

[0191] 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. In the RRC_CONNECTED state, the RRC of UE122 receives an RRC message containing the COUNT value from gNB108. The COUNT value can also be obtained by receiving it via DCCH. The RRC of UE122 is as described above. The acquired COUNT value may also be notified to the PDCP entity of the MRB in UE122. The PDCP entity of the MRB in UE122 receives the COUNT value notified from the upper layer to the receiving PDCP entity. You can set this as the COUNT value for Tee.

[0192] Also, in step S1204, the PDCP entity of the MRB in UE122 receives notification from the upper layer. When setting the received COUNT value, or the COUNT value obtained by receiving a PDCP control PDU, as the COUNT value of a receiving PDCP entity, the receiving side of the PDCP entity Then, you may set the state variable to indicate the COUNT value of the next PDCP SDU that is expected to be received. The PDCP entity of the UE122 MRB receives the COUNT value notified from the upper layer, or the COUNT value obtained by receiving the PDCP control PDU, and the receiving PDCP entity's COUNT value When setting it as such, the receiving side of the PDCP entity may set the state variable to indicate 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. Also, the PDCP entity of the UE122 MRB may set the COUNT value notified from the upper layer, or the PDCP control PDU The COUNT value obtained by receiving is the COUNT value of the receiving PDCP entity and When setting it, the above COUNT value is divided into the HFN part and the SN (Sequence Number) part. You can set it.

[0193] 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 the MBS session of interest If it is determined that the parameter for COUNT is not included in the selection, the processing unit 502 of UE122 transitions to the RRC_CONNECTED state for the purpose of obtaining the HFN value and / or the COUNT value. It can be determined that it is not necessary. Also, in step S1204, the processing unit 502 of UE122 is of interest If it is determined that a certain MBS session does not contain parameters related to HFN, and / or if it is determined that a particular MBS session of interest does not contain parameters related to COUNT, In this case, the processing unit 502 of UE122 may receive the MBS service without obtaining the HFN value and / or COUNT value in the RRC_IDLE state or RRC_INNACTIVE state. Also, 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 the MBS session of interest does not contain parameters related to COUNT. If it is determined that the necessary parameters are not included, the processing unit 502 of UE122 will call RRC_CONNECTED In this state, the MBS service may be received without obtaining the HFN value and / or COUNT value. (Step S1206)

[0194] In step S1204, the processing unit 502 of UE122 receives the MBS settings in step S1202. In the regular information message, the status report timer will be set for the MBS session of interest. You may determine if it contains parameters related to the status report timer. The parameters related to the status report timer mentioned above may be the value of the timer used to send the PDCP status report. If you determine that the received MBS configuration information message contains parameters related to the status report timer for the MBS session of interest, then UE122 The processing unit 502 sets the value of the timer used for sending the received PDCP status report. Good. The timer used for sending PDCP status reports is the PDCP entity of UE122. This may be used to detect a PDCP PDU or a loss of a PDCP PDU. The timer used to send the PDCP status report may be a timer that runs only once per PDCP entity. Furthermore, the timer used for sending PDCP status reports may be started or restarted when UE122 detects a PDCP PDU or a loss of a PDCP PDU. The timer used for sending the signal is determined by whether the timer used for sending the PDCP status report is running when the UE122's PDCP receives a PDCP data PDU from a lower layer, and / or whether the state variable (e.g., a state variable named RX_NEXT) that indicates the COUNT value of the next PDCP SDU to be received is running, and whether the state variable (e.g., a state variable named RX_DELIV) that indicates 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 is running. It may be started or restarted based on conditions including being greater than the stated value. The timer used for sending the PDCP status report is set so that the UE122 does not lose any PDCP PDUs or PDCP PDUs. It may be stopped and / or reset when it becomes necessary. For example, when sending a PDCP status report. The timer used is the timer used for sending the PDCP status report, which is running, and / or the state that indicates the COUNT value of the next PDCP SDU to be received. A variable (for example, a state variable named RX_NEXT) is waiting to be received and has not been sent to the upper layer. A state variable (for example, RX_DELIV) that indicates the COUNT value of the first PDCP PDU among the PDCP SDUs. It may be stopped and / or reset based on being equal to the state variable (name). The "equal" in the above can be rephrased as "greater than" or "equal to". Also, the "equal" mentioned above can 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 the PDCP status report. Furthermore, the timer used for sending the PDCP status report is triggered when the PDCP entity is from a higher layer. The timer used for sending PDCP status reports may be stopped and / or reset based on a request for suspension. The timer used for sending PDCP status reports may also be stopped and / or reset based on a request for re-establishment from a higher layer of the PDCP entity. The timer used for port transmission may be stopped and / or reset based on the PDCP entity being requested to reconfigure from a higher layer.

[0195] 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.

[0196] In step S1206, before starting to receive the MBS session of interest, the processing of UE122 The control unit 502 may perform one or more MRB establishment processes to initiate reception of an MBS session of interest. The MRB establishment process may be performed, for example, at the start of the MBS session if UE122 is interested The fact that an MBS service with a certain feature has entered a cell that is provided via MRB, and that people are interested in MBS services This is based on the fact that the limitations on UE capabilities that were suppressing the reception of MBS services have been removed, etc. It may be started in this state. The 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. It is also acceptable. Furthermore, the MRB establishment process is initiated when UE112 is in the RRC_CONNECTED state and receives an RRC message from gNB108 via DCCH indicating that MRB should be established, or based on the receipt of such a message. It may be started. The RRC message suggesting 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 above. The processing unit 502 of UE122 contains the default configuration information for each entity held by UE122. In step S1202, the MBS setting information message received via MCCH is included in the MBS setting The configuration information includes some or all of the parameters related to the MBS settings contained in the RRC message that suggests establishing the MRB received via the DCCH mentioned above. You may then proceed with the MRB establishment process.

[0197] When the processing unit 502 of UE122 performs the MRB establishment process, it performs some or all of the following processes (A) to (M). You may perform processing that includes "te". (A) An SDAP entity exists in the PDU session that provides MBS, and / or in the PDU session that corresponds to the parameter indicating the PDU session included in the parameters related to the MBS configuration. If not already present, 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) According to the default settings for MRB establishment, or the settings received from the base station, RLC To establish and / or set up an entity. (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) RLC bearer or RLC bearer ro established and / or set in process (D) and / or process (E) Associate the digital channel with the PDCP entity established and / or configured 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) RLC bearer or RLC bearer ro established and / or set in process (G) and / or process (H) Associate the digital channel with the PDCP entity established and / or configured in process (B). (J) Associate the SDAP entity with the established MRB. (K) For the upper layer, the TMGI, Session ID, and PDU session ID corresponding to the established MRB. The establishment of MRB is indicated by notifying information that includes some or all of the QoS flow. (L) If the encryption function is not disabled for the PDCP entity of this MRB, the encryption algorithm is applied to the PDCP entity established in process (B). Set the parameters and apply the master key or secondary key according to the parameters indicating whether to use the master key or the secondary key. (M) If integrity protection is set for the PDCP entity of this MRB, process (B) For established PDCP entities, an integrity protection algorithm is set, and either the master key or the secondary key is applied according to a parameter indicating whether to use the master key or the secondary key.

[0198] 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 entity of one or more MRBs. If a status report is created, the created PDCP status report will be sent to the MRB's PDCP Engine. The report should be submitted to the RLC bearer RLC entity that receives MBS on a one-to-one basis and is linked to Titi, but not to the RLC bearer RLC entity that receives MBS on a one-to-many basis and is linked to the MRB's PDCP entity. "Submit the RLC entity of the RLC bearer that receives MBS on a one-to-one basis and is linked to Titi, but do not need 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 PDCP entity of the MRB." This should be changed to "Submit the created PDCP status report to the PDCP entity of the MRB." Submit only to RLC entities of RLC bearers that receive MBS one-to-one and are associated with Titi. It is acceptable to say, "You may do so." Furthermore, the PDCP reporting in the MRB's PDCP entity... The activation of the system occurs when the higher layer has configured the MRB to send PDCP status reports. This may be done. (Step S1208)

[0199] Furthermore, in step S1208, the processing unit 502 of UE122 controls the PDCP entities of one or more MRBs. When a PDCP status report is triggered in the system, it determines whether an RLC bearer that receives MBS on a one-to-one basis is associated with the MRB's PDCP entity, and then determines whether an RLC bearer that receives MBS on a one-to-one basis is associated with the MBS. Based on the fact that they are linked, a PDCP status report should be created and submitted only to the RLC entity of the RLC bearer that receives the aforementioned MRB on a one-to-one basis. Furthermore, the processing unit 502 of UE122 receives the PDCP status report in the MRB's PDCP entity. When activated, an RLC bearer that receives MBS on a one-to-one basis is associated with the MRB's PDCP entity. Based on the determination of whether or not an RLC bearer is associated with a one-to-one MBS connection, it is not necessary to create a PDCP status report.

[0200] Furthermore, in step S1208, the processing unit 502 of UE122 controls the PDCP entities of one or more MRBs. When a PDCP status report is triggered in the system, it creates a PDCP status report and determines whether an RLC bearer that receives MBS on a one-to-one basis is associated with the MRB's PDCP entity. Based on the fact that an RLC bearer receives MBS on a one-to-one basis, the created PDCP status report is submitted only to the RLC entity of the RLC bearer that receives MRB on a one-to-one basis as described above. Good. Also, the processing unit 502 of UE122 reports the PDCP status report in the MRB's PDCP entity. When the system is activated, it creates a PDCP status report and determines whether an RLC bearer that receives MBS on a one-to-one basis is associated with the MRB's PDCP entity. Based on the fact that it is not linked, the created PDCP status report does not need to be submitted to the lower layer. Also, processing unit 502 of UE122 handles the PDCP status in the MRB's PDCP entity. When the report is triggered, it creates a PDCP status report and the PDCP entity of the MRB. Next, determine whether an RLC bearer that receives MBS on a one-to-one basis is associated with it, and if no RLC bearer that receives MBS on a one-to-one basis is associated, you may discard the created PDCP status report.

[0201] Furthermore, the RLC entity of the RLC bearer that receives the aforementioned MBS on a one-to-one basis is the AM RLC entity. It is fine to be a ty. Also, the RLC bearer that receives the above MBS on a one-to-one basis is linked to the RLC envelope A "titi" can be a bidirectional UM RLC entity. Furthermore, it can receive the aforementioned MBS on a one-to-one basis. The RLC entity to which the believing RLC bearer is associated may be the transmitting UM RLC entity and / or receiving UM RLC entity of a unidirectional UM RLC entity.

[0202] In step S1208, the PDCP status report may be initiated based on a request for the transmission of a PDCP status report from the RRC layer or a higher layer. A request for a PDCP status report from the layer or a higher layer means that the RRC layer It may be that a request for PDCP data recovery was made from the Y or higher layer. Also, in step S1208, the activation of the PDCP status report is linked to one of the PDCP entities of the MRB or This is based on the fact that multiple RLC bearers have been released, suspended, or deactivated. It is acceptable to do so. Also, in step S1208, the activation of the PDCP status report is performed. The timer for the status report set in the S1204 is set to the PDCP entity. It may be carried out upon completion of the procedure. Also, in step S1208, the PDCP status Port activation may be performed based on a switch in the RLC bearer receiving MRB. The above-mentioned switch in the MRB-receiving RLC bearer means that the RLC bearer receiving 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. Good. Also, the above statement that the RLC bearer receiving the MRB has switched means that the RLC bearer receiving the MRB has switched from an RLC bearer that receives MBS on a one-to-one basis to an RLC bearer that receives MBS on a one-to-many basis. It's fine even if it's something that happened.

[0203] Also in step S1208, the processing unit 502 of UE122 receives RRC messages from gNB108. The message indicates a request for UE122 to send PDCP status reports to one or more MRBs. If the parameters are relevant, the RRC of UE122 may request the PDCP layer of the MRB of UE122 to send a PDCP status report. Note that the above RRC message is sent via DCCH. The RRC message may be sent via MCCH or via PDCP. The parameters that signify the request to send a PDCP status report to one or more MRBs as described above may include an identifier that identifies the MRB and some or all of the parameters relating to the MBS session information. Also in step S1208, the processing unit 502 of UE122 When UE122 receives an RRC message from gNB108 indicating a request to send a PDCP status report, UE122 may request the PDCP layer of UE122's MRB to send a PDCP status report from its RRC. The message may be an RRC message sent via DCCH, or it may be sent via MCCH. The RRC message may be any such message. The RRC message signifying the request to send the PDCP status report described above may include an identifier that identifies the MRB and some or all of the parameters relating to the MBS session information.

[0204] Furthermore, in step S1208, the processing unit 502 of UE122 receives one or more UE122 from gNB108. Based on the receipt of an RRC message for counterchecking (countercheck message) for the MRB, a countercheck process may be performed, and the result may be set in an RRC message for countercheck response (countercheck response message) and reported to gNB108. The aforementioned RRC message for counterchecking identifies the MRB. Identifier, parameters related to MBS session information, and the most significant bit (MSB) of the COUNT value in the uplink and / or downlink directions associated with the MRB. This may include some or all of the following: RRC message for the counter check mentioned above. The gNB108 notifies the UE122 of the MSB value of the current COUNT value associated with the MSB of the gNB108, and the UE122 then sends the comparison result of this with the MSB value of the current COUNT value associated with the MSB of the UE122 to the gNB108. The message may be a request to report to [the appropriate entity]. 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) The MRB is a unidirectional bearer, in the uplink direction and / or downlink direction If no COUNT exists, the COUNT value in the direction where no COUNT value exists is assumed to be '0'. (B) For MRBs whose RRC message for counter check does not contain parameters relating to an identifier that identifies the MRB and / or MBS session information, the UE122 has The COUNT value for the top-link direction and / or down-link direction is set in the RRC message for the counter check response. (C) RRC message for counter check, uplink direction and / or downlink For the MRB which contains the MSB value of the COUNT value in the link direction, the received uplink If the MSB value of the COUNT value in the direction and / or downlink direction differs from the COUNT value in the uplink direction and / or downlink direction held by UE122, then the uplink value held by UE122 The COUNT value for the direction and / or downlink direction is set in the RRC message for the counter check response. (D) For MRBs whose RRC message for counter checks contains parameters relating to an identifier that identifies the MRB and / or MBS session information, UE122 has the ability to The COUNT value for the pop-in direction and / or down-link direction is set in the RRC message for the counter check response.

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

[0206] In the above explanation, an RLC bearer that receives MBS on a one-to-one basis refers to a feed to MBS. It could also refer to an RLC bearer that sends back to the gNB108.

[0207] 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."

[0208] In the above explanation, PDCP entities refer to receiving PDCP entities and / or sending entities. It is acceptable for it to be a trustworthy PDCP entity.

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

[0210] Thus, in the embodiment of the present invention, the terminal device receives the PDCP status report from the MBS. By transmitting only to RLC bearers that receive the signal one-to-one, the MBS can be efficiently controlled using NR. We can provide terminal equipment, base station equipment, and methods that enable this.

[0211] In the above description, the wireless bearer may be some or all of the DRB, SRB, and MRB. stomach.

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

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

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

[0215] 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" is equivalent to "being true A." It can be executed independently.

[0216] 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".

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

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

[0219] (1) A terminal device that communicates with a base station device, wherein the terminal device has a first RLC bearer for receiving MBS one-to-many signals and a second RLC bearer for receiving MBS one-to-one signals, and the first RLC bearer and the second RLC bearer are associated with the same PDCP entity, and the PDCP If the entity creates a PDCP status report, it will submit the PDCP status report only to the second RLC bearer.

[0220] (2) A method for a terminal device to communicate with a base station device, wherein the terminal device has a first RLC bearer for receiving MBS in a one-to-many manner and a second RLC bearer for receiving MBS in a one-to-one manner. The first RLC bearer and the second RLC bearer are associated with the same PDCP entity, and when the PDCP entity generates a PDCP status report, it submits the PDCP status report only to the second RLC bearer.

[0221] 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 the information handled by the program is temporarily stored in volatile memory such as Random Access Memory (RAM) during processing. It is read into the system, or stored in non-volatile memory such as flash memory or a hard disk drive (HDD), and read, modified, and written to by the CPU as needed.

[0222] 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.

[0223] 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.

[0224] 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 plurality 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), and field-programmable circuits. This may include a multi-gate array (FPGA), other programmable logic devices, discrete gate or transistor logic, discrete hardware components, or a combination thereof. The general-purpose processor may be a microprocessor, or alternatively, a conventional processor, controller, microcontroller, or state machine. The general-purpose processor, or each of the aforementioned circuits, may consist of digital or analog circuits. Furthermore, if advances in semiconductor technology lead to the emergence of integrated circuit technologies that replace current integrated circuits, integrated circuits using such technologies may also be used.

[0225] 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.

[0226] 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]

[0227] 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]

[0228] 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 terminal device has a first RLC bearer for receiving MBS signals in a one-to-many manner, and a second RLC bearer for receiving MBS signals in a one-to-one manner. The first RLC bearer and the second RLC bearer are associated with the same PDCP entity. The PDCP entity, upon receiving a request from the base station device to transmit a PDCP status report via the MCCH of the first RLC bearer, creates a PDCP status report and submits the PDCP status report only to the second RLC bearer. Terminal device.

2. A method for a terminal device to communicate with a base station device, The terminal device has a first RLC bearer for receiving MBS signals in a one-to-many manner, and a second RLC bearer for receiving MBS signals in a one-to-one manner. The first RLC bearer and the second RLC bearer are associated with the same PDCP entity. The PDCP entity, upon receiving a request from the base station device to transmit a PDCP status report via the MCCH of the first RLC bearer, creates a PDCP status report and submits the PDCP status report only to the second RLC bearer. method.

Images