WO2022080339A1 - Terminal device and method - Google Patents

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

Terminal devices and methods

The present invention relates to terminal devices and methods.
The present application claims priority with respect to Japanese Patent Application No. 2020-172376 filed in Japan on October 13, 2020, the contents of which are incorporated herein by reference.

In the 3rd Generation Partnership Project (3GPP), which is a standardization project for cellular mobile communication systems, technical studies and standard development of cellular mobile communication systems including wireless access, core networks, services, etc. have been carried out. There is.

For example, E-UTRA (Evolved Universal Terrestrial Radio Access) has started technical studies and standardization as a radio access technology (Radio Access Technology: RAT) for cellular mobile communication systems for the 3.9th and 4th generations in 3GPP. rice field. At 3GPP, technical studies and standardization of E-UTRA extended technology are still underway. In addition, E-UTRA is also referred to as LongTermEvolution (LTE: registered trademark), and the extended technology may be referred to as LTE-Advanced (LTE-A) or LTE-Advanced Pro (LTE-A Pro). (Non-Patent Document 2 etc.)

In addition, NR (New Radio or NR Radio access) is a radio access technology (Radio Access Technology: RAT) for cellular mobile communication systems for the 5th generation (5th Generation: 5G) in 3GPP, and technical studies and standard formulation are underway. It was started. At 3GPP, technical studies and standardization of NR extended technology are still underway. (Non-Patent Document 1 etc.)

MBMS (Multimedia Broadcast Multicast Service) transmission technology has been standardized in order to provide multicast / broadcast services as one of the studies on E-UTRA extended technology. For MBMS transmission, transmission using MBSFN (Multicast Broadcast Single Frequency Network) or SC-PTM (Single Cell Point-To-Multipoint) is used.

For transmission using MBSFN, multicast / broadcast data is transmitted using PMCH (Physical Multicast Channel) in MBSFN (Multicast-Broadcast Single-Frequency Network) area units consisting of multiple cells. On the other hand, in the transmission using SC-PTM, multicast data is transmitted using PDSCH (Physical Downlink Shared Channel) on a cell-by-cell basis.

On the other hand, a multicast / broadcast service (Multicast Broadcast Service: MBS) is being considered as an extension technology for NR. When performing MBS via NR, it is necessary to consider NR-specific technologies that are different from E-UTRA and core networks that have been standardized for 5G. However, the detailed operation for efficiently controlling MBS using NR has not yet been investigated.

One aspect of the present invention has been made in view of the above circumstances, and one of the objects is to provide a terminal device, a base station device, and a method capable of efficiently controlling MBS using NR. do.

In order to achieve the above object, one aspect of the present invention has taken the following measures. That is, one aspect of the present invention is a terminal device that communicates with the base station device, and the terminal device receives the MBS one-to-one with the first RLC bearer for receiving one-to-many MBS. The first RLC bearer and the second RLC bearer are associated with the same PDCP entity, and the PDCP entity creates the PDCP status report, the PDCP status report. Is submitted only to the second RLC bearer.

Further, one aspect of the present invention is a method of a terminal device that communicates with a base station device, wherein the terminal device receives a one-to-one MBS with a first RLC bearer for receiving one-to-many MBS. The first RLC bearer and the second RLC bearer are associated with the same PDCP entity, and the PDCP entity creates the PDCP status report, the PDCP. Submit the status report only to the second RLC bearer mentioned above.

It should be noted that these comprehensive or specific embodiments may be realized in a system, an apparatus, a method, an integrated circuit, a computer program, or a recording medium, and the system, an apparatus, a method, an integrated circuit, a computer program, and a recording medium may be realized. It may be realized by any combination of.

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

The schematic diagram of the communication system which concerns on embodiment of this invention. The figure of an example of the E-UTRA protocol composition which concerns on embodiment of this invention. The figure of an example of the NR protocol composition which concerns on embodiment of this invention. The figure which shows an example of the flow of the procedure for various setting in RRC which concerns on embodiment of this invention. The block diagram which shows the structure of the terminal apparatus in embodiment of this invention. The block diagram which shows the structure of the base station apparatus in embodiment of this invention. An example of the ASN.1 description contained in the message relating to the reconfiguration of the RRC connection in NR according to the embodiment of the present invention. An example of the ASN.1 description contained in the message regarding the resetting of the RRC connection in E-UTRA in the embodiment of the present invention. The figure which shows the flow of the procedure for setting MBMS reception using SC-PTM. The figure which shows an example of the ASN.1 description which represents a field and / or an information element included in SIB20 (System Information Block Type 20). A diagram showing an example of an ASN.1 description representing a field and / or an information element contained in an SC-PTM configuration message (SCPTM Configuration). The figure which shows an example of the flow of the MBS reception procedure in NR in embodiment of this invention.

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

LTE (and LTE-A, LTE-A Pro) and NR may be defined as different radio access technologies (Radio Access Technology: RAT). NR may also be defined as a technique included in LTE. LTE may also be defined as a technique included in NR. In addition, LTE that can be connected to NR by MultiRadio Dual connectivity (MR-DC) may be distinguished from conventional LTE. In addition, LTE using 5GC for the core network may be distinguished from conventional LTE using EPC for the core network. Note that conventional LTE may be LTE that does not implement the technology 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, but embodiments of the present invention may be applied in other techniques using other terms. Further, the term E-UTRA in the embodiment 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 embodiment of the present invention, the names of the nodes and entities when the wireless access technique is E-UTRA or NR, the processing in each node and the entity, and the like will be described. It may be used for other wireless access techniques. The name of each node or entity in the embodiment of the present invention may be another name.

FIG. 1 is a schematic diagram of a communication system according to an embodiment of the present invention. The functions of each node, wireless access technique, core network, interface, etc. described with reference to FIG. 1 are some functions closely related to the embodiment of the present invention, and may have other functions.

E-UTRA100 may be a wireless access technology. The E-UTRA100 may be an air interface between the UE 122 and the eNB 102. The air interface between UE122 and eNB102 may be called the Uu interface. The eNB (E-UTRAN Node B) 102 may be a base station device of the E-UTRA100. The eNB 102 may have the E-UTRA protocol described below. The E-UTRA protocol may be composed of the E-UTRA user plane (User Plane: UP) protocol described later and the E-UTRA control plane (Control Plane: CP) protocol described later. The eNB 102 may terminate the E-UTRA user plane (User Plane: UP) protocol and the E-UTRA control plane (Control Plane: CP) protocol for the UE 122. A radio access network composed of eNB may be called E-UTRAN.

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

Note that one or more eNB 102s may be connected to the EPC 104 via the interface 112. An interface may exist between multiple eNB 102s connected to the EPC 104 (not shown). The interface between a plurality of eNB 102s connected to the EPC 104 may be called an X2 interface.

NR106 may be a wireless access technology. Further, the NR106 may be an air interface between the UE 122 and the gNB 108. The air interface between UE122 and gNB108 may be called the Uu interface. The gNB (gNodeB) 108 may be a base station device of the NR106. The gNB108 may have the NR protocol described below. The NR protocol may be composed of the NR user plane (User Plane: UP) protocol described later and the NR control plane (Control Plane: CP) protocol described later. The gNB 108 may terminate the NR user plane (User Plane: UP) protocol and the NR control plane (Control Plane: CP) protocol for the UE 122.

5GC110 may be a core network. Interface 116 is an interface between gNB 108 and 5GC 110 and may be referred to as an NG interface. The interface 116 may include a control plane interface through which control signals pass and / or a user plane interface through which user data passes. The control plane interface of the interface 116 may be terminated by the Access and mobility Management Function (AMF: not shown) in the 5GC110. The user plane interface of the interface 116 may be terminated by the User Plane Function (UPF: not shown) in the 5GC110. The control plane interface of interface 116 may be called an NG-C interface. The user plane interface of interface 116 may be called an NG-U interface.

Note that one or more gNB108s may be connected to the 5GC110 via the interface 116. An interface may exist between multiple gNB108s connected to the 5GC110 (not shown). The interface between multiple gNB108s connected to the 5GC110 may be called the Xn interface.

The eNB 102 may have a function to connect to the 5GC110. The eNB 102 that has the function of connecting to the 5GC110 may be called ng-eNB. Interface 114 is the interface between eNB 102 and 5GC110 and may be referred to as the NG interface. The interface 114 may include a control plane interface through which control signals pass and / or a user plane interface through which user data passes. The control plane interface of the interface 114 may be terminated by the Access and mobility Management Function (AMF: not shown) in the 5GC110. The user plane interface of the interface 114 may be terminated by the User Plane Function (UPF: not shown) in the 5GC110. The control plane interface of interface 114 may be called an NG-C interface. The user plane interface of interface 114 may be called an NG-U interface. A radio access network composed of ng-eNB or gNB may be referred to as NG-RAN. NG-RAN, E-UTRAN, eNB, ng-eNB, gNB, etc. may be simply referred to as a network.

Note that one or more eNB 102s may be connected to the 5GC110 via the interface 114. An interface may exist between multiple eNB 102s connected to the 5GC110 (not shown). The interface between multiple eNB 102s connected to the 5GC110 may be referred to as the Xn interface. Further, the eNB 102 connected to the 5GC110 and the gNB108 connected to the 5GC110 may be connected by the interface 120. The interface 120 between the eNB 102 connected to the 5GC110 and the gNB108 connected to the 5GC110 may be referred to as an Xn interface.

GNB108 may have a function to connect to EPC104. The gNB 108 that has the function of connecting to the EPC104 may be called en-gNB. Interface 118 is the interface between gNB 108 and EPC 104 and may be referred to as the S1 interface. The interface 118 may have a user plane interface through which user data passes. The user plane interface of interface 118 may be terminated by S-GW (not shown) in EPC104. The user plane interface of interface 118 may be called the S1-U interface. Further, the eNB 102 connected to the EPC 104 and the gNB 108 connected to the EPC 104 may be connected by the interface 120. The interface 120 between the eNB 102 connected to the EPC 104 and the gNB 108 connected to the EPC 104 may be referred to as the X2 interface.

Interface 124 is an interface between EPC104 and 5GC110, and may be an interface through CP only, UP only, or both CP and UP. Further, some or all of the interfaces 114, interface 116, interface 118, interface 120, interface 124, etc. may not exist depending on the communication system provided by the telecommunications carrier or the like.

UE122 may be a terminal device capable of receiving notification information and paging messages transmitted from eNB102 and / or gNB108. The UE 122 may be a terminal device capable of wireless connection with the eNB 102 and / or the gNB 108. The UE 122 may be a terminal device capable of wirelessly connecting to the eNB 102 and wirelessly to the gNB 108 at the same time. UE122 may have an E-UTRA protocol and / or an NR protocol. The wireless connection may be a Radio Resource Control (RRC) connection.

When the UE 122 communicates with the eNB 102 and / or the gNB 108, a wireless connection may be made by establishing a wireless bearer (RB: Radio Bearer) between the UE 122 and the eNB 102 and / or the gNB 108. The radio bearer used for CP may be called a signaling radio bearer (SRB: Signaling Radio Bearer). The wireless bearer used for UP may be called a data wireless bearer (DRB Data Radio Bearer). A wireless bearer identifier (Identity: ID) may be assigned to each wireless bearer. The radio bearer identifier for SRB may be referred to as an SRB identifier (SRB Identity or SRB ID). The radio bearer identifier for DRB may be referred to as a DRB identifier (DRB Identity or DRB ID).

The UE 122 may be a terminal device that can be connected to the EPC 104 and / or the 5GC110 via the eNB 102 and / or the gNB 108. If the eNB 102 with which the UE 122 communicates and / or the core network to which the gNB 108 is connected is the EPC 104, each DRB established between the UE 122 and the eNB 102 and / or the gNB 108 further goes through each EPS within the EPC 104. (Evolved Packet System) It may be uniquely associated with the bearer. Each EPS bearer may be identified by an EPS bearer identifier (Identity, or ID). Further, the same QoS may be guaranteed for data such as IP packets passing through the same EPS bearer and Ethernet (registered trademark) frames.

Further, when the connection destination core network of the eNB 102 and / or the gNB 108 with which the UE 122 communicates is 5GC110, each DRB established between the UE 122 and the eNB 102 and / or the gNB 108 is further established in the 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 mapped to one or more QoS flows and may not be associated with any QoS flow. Each PDU session may be identified by a PDU session identifier (Identity, Identifier, or ID). Further, each QoS flow may be identified by the QoS flow identifier Identity, Identifier, or ID). Further, the same QoS may be guaranteed for data such as IP packets and Ethernet frames that pass through the same QoS flow.

The EPC104 does not have to have a PDU session and / or a QoS flow. Also, the 5GC110 does not have to have an EPS bearer. When the UE122 is connected to the EPC104, the UE122 has information on the EPS bearer, but not in the PDU session and / or QoS flow. Also, when the UE122 is connected to the 5GC110, the UE122 has information in the PDU session and / or QoS flow, but does not have to have the EPS bearer information.

In the following description, eNB 102 and / or gNB 108 are also simply referred to as a base station device, and UE 122 is also simply referred to as a terminal device or UE.

FIG. 2 is a diagram of an example of the E-UTRA protocol configuration according to the embodiment of the present invention. Further, FIG. 3 is a diagram of an example of the NR protocol configuration according to the embodiment of the present invention. It should be noted that the functions of the respective protocols described with reference to FIGS. 2 and / or 3 are some functions closely related to the embodiment of the present invention, and may have other functions. In the embodiment of the present invention, the uplink (UL) may be a link from the terminal device to the base station device. Further, in each embodiment of the present invention, the downlink (downlink: DL) may be a link from the base station device to the terminal device.

Figure 2 (A) is a diagram of the E-UTRA user plane (UP) protocol stack. As shown in FIG. 2 (A), the E-UTRANUP protocol may be a protocol between UE122 and eNB102. That is, the E-UTRANUP protocol may be a protocol terminated by eNB 102 on the network side. As shown in Fig. 2 (A), the E-UTRA user plane protocol stack consists of PHY (Physical layer) 200, which is a wireless physical layer (radio physical layer), and MAC (Medium), which is a medium access control layer (medium access control layer). From Access Control) 202, RLC (Radio Link Control) 204, which is a wireless link control layer (wireless link control layer), and PDCP (Packet Data Convergence Protocol) 206, which is a packet data convergence protocol layer (packet data convergence protocol layer). May be configured.

Figure 3 (A) is a diagram of the NR user plane (UP) protocol stack. As shown in FIG. 3 (A), the NRUP protocol may be a protocol between UE122 and gNB108. That is, the NRUP protocol may be a protocol terminated by gNB108 on the network side. As shown in FIG. 3A, the E-UTRA user plane protocol stack consists of PHY300, which is a wireless physical layer, MAC302, which is a medium access control layer, RLC304, which is a wireless link control layer, and PDCP306, which is a packet data convergence protocol layer. , And the service data adaptation protocol layer (service data adaptation protocol layer) SDAP (Service Data Adaptation Protocol) 310 may be configured.

Figure 2 (B) is a diagram of the E-UTRA control plane (CP) protocol configuration. As shown in FIG. 2B, in the E-UTRAN CP protocol, the RRC (Radio Resource Control) 208, which is a radio resource control layer (radio resource control layer), may be a protocol between UE 122 and eNB 102. That is, RRC208 may be a protocol terminated by eNB 102 on the network side. Further, in the E-UTRAN CP protocol, the NAS (Non Access Stratum) 210, which is a non-AS (Access Stratum) layer (non-AS layer), may be a protocol between UE 122 and MME. That is, NAS210 may be a protocol terminated by MME on the network side.

Figure 3 (B) is a diagram of the NR control plane (CP) protocol configuration. As shown in FIG. 3B, in the NRCP protocol, the radio resource control layer RRC308 may be a protocol between UE122 and gNB108. That is, RRC308 may be a protocol terminated by gNB108 on the network side. Further, 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 terminated by AMF on the network side.

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

In the embodiment of the present invention, the E-UTRA protocol and the NR protocol are not distinguished below, and PHY (PHY layer), MAC (MAC layer), RLC (RLC layer), PDCP (PDCP layer), RRC ( The terms RRC layer) and NAS (NAS layer) may be used. In this case, the PHY (PHY layer), MAC (MAC layer), RLC (RLC layer), PDCP (PDCP layer), RRC (RRC layer), and NAS (NAS layer) are the PHY (PHY layer) of the E-UTRA protocol. ), MAC (MAC layer), RLC (RLC layer), PDCP (PDCP layer), RRC (RRC layer), NAS (NAS layer), and NR protocol, PHY (PHY layer), MAC (MAC) Layer), RLC (RLC layer), PDCP (PDCP layer), RRC (RRC layer), NAS (NAS layer) may be used. The SDAP (SDAP layer) may be an SDAP (SDAP layer) of the NR protocol.

Further, in the embodiment of the present invention, when the E-UTRA protocol and the NR protocol are distinguished below, the PHY200, MAC202, RLC204, PDCP206, and RRC208 are referred to as the PHY for E-UTRA or the PHY for LTE, E-UTRA, respectively. MAC or LTE MAC, E-UTRA RLC or LTE RLC, E-UTRA PDCP or LTE PDCP, and E-UTRA RRC or LTE RRC. In addition, PHY200, MAC202, RLC204, PDCP206, and RRC208 can be used 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, respectively. It may be described as RRC or LTE RRC. When distinguishing between the E-UTRA protocol and the NR protocol, the PHY300, MAC302, RLC304, PDCP306, and RRC308 are called NR PHY, NR MAC, NR RLC, NR RLC, and NR RRC, respectively. There are also things. In addition, PHY200, MAC302, RLC304, PDCP306, and RRC308 may be described as NRPHY, NRMAC, NRRLC, NRPDCP, NRRRC, etc., respectively.

Explain the entity in the AS layer of E-UTRA and / or NR. An entity that has some or all of the functions of the MAC layer may be called a MAC entity. An entity that has some or all of the functions of the RLC layer may be called an RLC entity. An entity that has some or all of the functions of the PDCP layer may be called a PDCP entity. An entity that has some or all of the functions of the SDAP layer may be called an SDAP entity. An entity that has some or all of the functions of the RRC layer may be called an RRC entity. The MAC entity, RLC entity, PDCP entity, SDAP entity, and RRC entity may be paraphrased as MAC, RLC, PDCP, SDAP, and RRC, respectively.

The data provided from the lower layer to MAC, RLC, PDCP, SDAP and / or the data provided to MAC, RLC, PDCP, SDAP from the lower layer are referred to as MAC PDU (Protocol Data Unit) and RLC, respectively. It may be called PDU, PDCP PDU, SDAP PDU. In addition, the data provided from the upper layer to MAC, RLC, PDCP, SDAP and / or the data provided to the upper layer from MAC, RLC, PDCP, SDAP are referred to as MAC SDU (Service Data Unit) and RLC SDU, respectively. , PDCP SDU, SDAP SDU. Also, the segmented RLC SDU may be called the RLC SDU segment.

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

Here, the physical channel will be described.

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

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

PBCH may be used to notify the system information required by the terminal device.

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

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

PUCCH may be used to transmit uplink control information (UCI) in uplink wireless communication (wireless communication from a terminal device to a base station device). Here, the uplink control information may include channel state information (CSI: Channel State Information) used to indicate the state of the downlink channel. Further, the uplink control information may include a scheduling request (SR: Scheduling Request) used for requesting a UL-SCH (UL-SCH: Uplink Shared CHannel) resource. Further, the uplink control information may include HARQ-ACK (Hybrid Automatic Repeat request ACK knowledgement).

PDSCH may be used for transmission of downlink data (DL-SCH: Downlink Shared CHannel) from the MAC layer. Further, in the case of a downlink, it may be used for transmission of system information (SI: System Information) and random access response (RAR: Random Access Response).

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

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

An example of the MAC function will be explained. The MAC may be referred to as a MAC sublayer. The MAC may have a function of mapping various logical channels (logical channels: Logical Channels) to the corresponding transport channels. The logical channel may be identified by a logical channel identifier (LogicalChannelIdentity or LogicalChannelID). The MAC may be connected to the upper RLC by a logical channel (logical channel). The logical channel may be divided into a control channel for transmitting control information and a traffic channel for transmitting user information, depending on the type of information to be transmitted. Further, the logical channel may be divided into an uplink logical channel and a downlink logical channel. The MAC may have the function of multiplexing MAC SDUs belonging to one or more different logical channels and providing them to the PHY. The MAC may also have the function of demultiplexing the MAC PDU provided by the PHY and providing it to the upper layer via the logical channel to which each MAC SDU belongs. In addition, the MAC may have a function of performing error correction through HARQ (Hybrid Automatic Repeat reQuest). In addition, the MAC may have a scheduling report (Scheduling Report: SR) function that reports scheduling information. The MAC may have a function of performing priority processing between terminal devices by using dynamic scheduling. Further, the MAC may have a function of performing priority processing between logical channels in one terminal device. The MAC may have a function of prioritizing overlapping resources in one terminal device. E-UTRA MAC may have a function to identify Multimedia Broadcast Multicast Services (MBMS). Further, the NR MAC may have a function of identifying a multicast / broadcast service (Multicast Broadcast Service: MBS). The MAC may have the ability to select a transport format. MAC has a function to perform intermittent reception (DRX: Discontinuous Reception) and / or intermittent transmission (DTX: Discontinuous Transmission), a function to execute a random access (Random Access: RA) procedure, and a power to notify information on transmittable power. It may have a headroom report (Power Headroom Report: PHR) function, a buffer status report (Buffer Status Report: BSR) function, etc. to notify the data amount information of the transmission buffer. The 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. Further, the MAC PDU may include a MAC control element (MAC control element: MAC CE), which is an element for performing control in the MAC.

The logical channel for uplink (UL: Uplink) and / or downlink (DL: Downlink) used in E-UTRA and / or NR will be described.

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

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

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

DCCH (Dedicated Control Channel) is a logical channel for transmitting dedicated control information in a one-to-point bi-directional manner between a terminal device and a base station device. It's okay to have it. The dedicated control information may be control information dedicated to each terminal device. DCCH may be used when the terminal device has an RRC connection.

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

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

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

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

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

Explain the mapping between the logical channel and the transport channel of the uplink in E-UTRA and / or NR.

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

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

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

Explain the mapping between the logical channel and the transport channel of the downlink in E-UTRA and / or NR.

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

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

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

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

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

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

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

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

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

An example of RLC functions will be explained. RLC may be referred to as an RLC sublayer. The E-UTRA RLC may have a function of segmenting and / or concatenation the data provided from the PDCP of the upper layer and providing it to the lower layer (lower layer). E-UTRA RLC may have a function of reassembling and re-ordering the data provided from the lower layer and providing it to the upper layer. The NR RLC may have a function of adding a sequence number independent of the sequence number added by the PDCP to the data provided by the PDCP of the upper layer. In addition, NR RLC may have the function of segmenting the data provided by PDCP and providing it to the lower layer. Further, NR RLC may have a function of reassembling the data provided from the lower layer and providing it to the upper layer. In addition, RLC may have a data retransmission function and / or a retransmission request function (Automatic Repeat reQuest: ARQ). In addition, RLC may have a function to correct errors by ARQ. Control information indicating data that needs to be retransmitted, which is sent from the receiving side of RLC to the transmitting side in order to perform ARQ, may be called a status report. Also, the status report transmission instruction sent from the sender side of RLC to the receiver side may be called a pole. RLC may also have a function to detect data duplication. RLC may also have a data discard function. The RLC may have three modes: transparent mode (TM: Transparent Mode), non-response mode (UM: Unacknowledged Mode), and response mode (AM: Acknowledged Mode). In TM, the data received from the upper layer is not divided and the RLC header need not be added. The TM RLC entity is a uni-directional entity and may be configured as a transmitting TM RLC entity or as a receiving TM RLC entity. In UM, data received from the upper layer is divided and / or combined, RLC header is added, etc., but data retransmission control does not have to be performed. The UMRLC entity may be a unidirectional entity or a bi-directional entity. If the UMRLC entity is a unidirectional entity, the UMRLC entity may be configured as a sending UMRLC entity or as a receiving UMRLC entity. If the UM RLC entity is a bidirectional entity, the UM RRC entity may be configured as a UM RLC entity consisting of a transmitting side and a receiving side. In AM, data received from the upper layer may be divided and / or combined, an RLC header may be added, and data retransmission control may be performed. The AMRLC entity is a bidirectional entity and may be configured as an AMRLC consisting of a transmitting side and a receiving side. The data provided to the lower layer by TM and / or the data provided from the lower layer may be referred to as TMDPDU. Further, the data provided to the lower layer by UM and / or the data provided from the lower layer may be referred to as UMD PDU. Further, the data provided to the lower layer by AMD or the data provided from the lower layer may be called AMD PDU. The RLC PDU format used in E-UTRA RLC and the RLC PDU format used in NR RLC may be different. Further, the RLC PDU may include an RLC PDU for data and an RLC PDU for control. The RLC PDU for data may be referred to as an RLC DATA PDU (RLC Data PDU, RLC data PDU). Further, the control RLC PDU may be called an RLC CONTROL PDU (RLC Control PDU, RLC control PDU, RLC control PDU).

An example of the PDCP function will be explained. PDCP may be referred to as a PDCP sublayer. PDCP may have a function to maintain the sequence number. The PDCP may also have a header compression / decompression function for efficiently transmitting user data such as IP packets and Ethernet frames in the wireless section. The protocol used for IP packet header compression / decompression may be called the ROHC (Robust Header Compression) protocol. The protocol used for Ethernet frame header compression / decompression may be called the EHC (Ethernet (registered trademark) Header Compression) protocol. The PDCP may also have a data encryption / decryption function. The PDCP may also have the function of data integrity protection / integrity verification. The PDCP may also have a re-ordering function. The PDCP may also have a PDCP SDU retransmission function. In addition, PDCP may have a function of discarding data using a discard timer (discard timer). The PDCP may also have a Duplication function. The PDCP may also have a function of discarding duplicate received data. The 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. Further, the PDCP PDU may include a PDCP PDU for data and a PDCP PDU for control. The PDCP PDU for data may be referred to as a PDCP DATA PDU (PDCP Data PDU, PDCP data PDU). Further, the control PDCP PDU may be called a PDCP CONTROL PDU (PDCP Control PDU, PDCP control PDU, PDCP control PDU).

In PDCP, the COUNT value may be used when performing encryption or integrity protection processing. The COUNT value may be composed of HFN (Hyper Frame Number), which is a PDCP state variable, and a sequence number (SN: Sequence Number) added to the header of the PDCP PDU. The sequence number may be incremented by 1 each time the sending PDCP entity generates a PDCP DATA PDU. The HFN may be incremented by 1 each time the sequence number reaches the maximum value in the transmit PDCP entity and the receive PDCP entity. Further, in order to manage the COUNT value in the sending PDCP entity and the receiving PDCP entity, some or all of the following state variables (state variables) (A) to (F) may be used.
(A) A state variable that indicates the COUNT value of the PDCP SDU to be sent next. It may be a state variable named TX_NEXT.
(B) In this PDCP entity, a state variable indicating the sequence number of the PDCP SDU to be transmitted next. It can be a state variable named Next_PDCP_TX_SN.
(C) A state variable that represents the HFN value used to generate the COUNT value for the PDCP PDU in this PDCP entity. It can be a state variable named TX_HFN.
(D) A state variable that indicates the COUNT value of the PDCP SDU that is expected to be received next in the receiving PDCP entity. It may be a state variable named RX_NEXT.
(E) In the receiving PDCP entity, a state variable indicating the sequence number of the PDCP SDU that is expected to be received next. It can be a state variable named Next_PDCP_RX_SN.
(F) A state variable that represents the HFN value used to generate the COUNT value for the received PDCP PDU in this PDCP entity. It may be a state variable named RX_HFN.

In PDCP, re-ordering means that the PDCP SDU is stored in the receive buffer (reordering buffer), and the PDCP SDU is placed in the upper layer in the order of the COUNT values obtained from the header information of the PDCP DATA PDU. It may be a process for delivery. In reordering, if the COUNT value of the received PDCP data PDU is the COUNT value of the first PDCP SDU that has not yet been passed to the upper layer, the stored PDCP SDU is received by the upper layer in the order of the COUNT value. You may perform the process of passing. That is, in reordering, if a PDCP data PDU with a COUNT value smaller than the COUNT value of the received PDCP data PDU cannot be received (PDCP data PDU is lost), the received PDCP data PDU is used as PDCP SDU. It may be converted to and stored in the reordering buffer, all the lost PDCP data PDUs may be received, converted to PDCP SDU, and then passed to the upper layer. In reordering, a reordering timer (a timer named t-Reordering) may be used to detect the loss of PDCP data PDUs. Further, for reordering, some or all of the following state variables (state variables) (A) to (F) may be used.
(A) A state variable that indicates the COUNT value of the PDCP SDU that is expected to be received next in the receiving PDCP entity. It may be a state variable named RX_NEXT.
(B) A state variable indicating the sequence number of the PDCP SDU that is expected to be received next in the received PDCP entity. It can be a state variable named Next_PDCP_RX_SN.
(C) A state variable that represents the HFN value used to generate the COUNT value for the received PDCP PDU in this PDCP entity. It may be a state variable named RX_HFN.
(D) In the received PDCP entity, a state variable indicating the COUNT value of the first PDCP PDU among the PDCP SDUs waiting to be received that have not been delivered to the upper layer. It may be a state variable named RX_DELIV.
(E) In the received PDCP entity, a state variable indicating the sequence number of the PDCP PDU of the PDCP SDU that was last delivered to the upper layer. It may be a state variable named Last_Submitted_PDCP_RX_SN.
(F) In the received PDCP entity, a state variable that indicates the COUNT value next to the COUNT value of the PDCP PDU that started the reordering timer. It may be a state variable named RX_REORD or a state variable named Reordering_PDCP_RX_COUNT.

Status reporting in PDCP will be described. In DRB (AM DRB: Acknowledged Mode Data Radio Bearer) using RLC of Acknowledged Mode in which transmission of PDCP status report is set from the upper layer, the receiving PDCP entity satisfies one of the following conditions (A) to (D). When met, you may trigger the PDCP status report. In addition, in DRB (UM DRB: Unacknowledged Mode Data Radio Bearer) using RLC of Unacknowledged Mode in which transmission of PDCP status report is set from the upper layer, when the receiving PDCP entity meets the following conditions (C), PDCP You may also trigger a status report.
(A) The upper layer requests the re-establishment of the PDCP entity.
(B) The upper layer requests PDCP data recovery.
(C) The upper layer requests an uplink data switch.
(D) The upper layer has reconfigured this PDCP entity to release the DAPS (Dual Active Protocol Stack), and a parameter named daps source release has been set.

When sending the PDCP status report is activated, the receiving PDCP entity may create the PDCP status report. To create a PDCP status report, the PDCP control PDU for the PDCP status report contains information on the PDCP SDU waiting to be received, including the COUNT value of the first PDCP PDU waiting to be received that has not been delivered to the upper layer. It may be done by doing. The receiving PDCP entity that created the PDCP status report may submit the created PDCP status report to a lower layer via the sending PDCP entity.

In the embodiment of the present invention, it may be determined that the PDCP entity of UMDRB, which is set to send the PDCP status report from the upper layer, has requested PDCP data recovery from the upper layer. The PDCP entity of UMDRB that determines that PDCP data recovery is requested from the upper layer creates a PDCP status report in the receiving PDCP entity based on the PDCP data recovery request from the upper layer, and the sending PDCP entity. The created PDCP status report may be submitted to the lower layer via. The lower layer may be the UM RLC entity of the RLC bearer associated with the PDCP entity. In the embodiment of the present invention, only when the UMDRB is not a DAPS bearer, the PDCP entity of the UMDRB to which the PDCP status report transmission is set from the upper layer is requested to recover the PDCP data from the upper layer. You can judge the matter. The DAPS bearer may be a bearer in which one or more RLC entities for the source cell and one or more RLC entities for the target cell are associated with the PDCP entity. Further, the PDCP data recovery described above may be another name meaning that the PDCP is requested to send a status report from the upper layer.

Explain ROHC. In embodiments of the present invention, ROHC may be paraphrased as the ROHC protocol. ROHC may have a function of compressing and decompressing header information such as IP, UDP, TCP, and RTP. In ROHC, the compressor may have a header compression function that compresses the header information. Also, in ROHC, the decompressor may have a header decompression function to decompress the header information. The compressor may perform header compression using the context possessed by the compressor. The decompression machine may decompress the header using the context possessed by the decompression machine. In embodiments of the present invention, the context may be paraphrased as a ROHC context. The context in the decompressor may be generated by receiving all the header information from the compressor. The context in the compressor and decompressor may be retained for each IP flow. A context identifier (Context Identifier: CID) may be used to identify the context. Information on the maximum value of the context identifier, profile information indicating the method of header compression / decompression, etc. may be negotiated between the compressor and the decompression machine before header compression / decompression.

In ROHC, header information may be classified into static parts and dynamic parts. The static part of the header information in ROHC may be information that hardly changes among the header information of each packet belonging to the IP flow. The static part of the header information in ROHC is, for example, information including a source address, a destination address, a version in an IPv4 header or an IPv6 header, a source port in a UDP header or a TCP header, a destination port, and the like. It's okay. Further, the dynamic part of the header information in ROHC may be information that can change for each packet among the header information of each packet belonging to the IP flow. The dynamic part of the header information in ROHC includes, for example, trahook class in IPv6 header, hop limit, Type of service in IPv4 header, Time to Live, check sum in UDP header, RTP sequence number in RTP header, RTP time stamp, etc. It may be information.

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

The ROHC decompressor may have three states: NC (NoContext) state, SC (StaticContext) state, and FC (FullContext) state. The initial state of the defroster may be NC state. When the context is acquired in the NC state and the header is decompressed correctly, the transition to the FC state may be performed. If header decompression fails continuously in the FC state, it may transition to the SC state or NC state.

There may be three ROHC processing modes: U-mode (Unidirectional mode), O-mode (Bidirectional Optimistic mode), and R-mode (Bidirectional Reliable mode). In U-mode, it is not necessary to use ROHC feedback packets. In U-mode, the transition from low compression mode to high compression mode in the compressor, that is, the transition from IR state to FO state, and / or the transition from FO state to SO state, and / or from IR state to SO state. The transition may be performed by transmitting a fixed number of packets. Also, in U-mode, the transition from high compression mode to low compression mode in the compressor, that is, the transition from SO state to FO state, and / or the transition from FO state to IR state, and / or from SO state to IR. The transition to the state may be performed at regular intervals, so that the information necessary for header decompression may be periodically transmitted to the decompression machine. In O-mode, the decompressor may send a ROHC feedback packet to the compressor to request the compressor to update the context. In R-mode, the compressor may transition from the low compression mode to the high compression mode by receiving the header decompression success notification by the ROHC feedback packet from the decompression machine. Further, in the R-mode, the compressor may transition from the high compression mode to the low compression mode by receiving the context update request by the ROHC feedback packet from the decompression machine. The ROHC processing mode may be started from U-mode. The transition of the processing mode of ROHC may be determined by the defroster. The decompressor may use the ROHC feedback packet to urge the compressor to transition to the processing mode.

An example of SDAP functions will be explained. SDAP is a service data adaptation protocol layer (service data adaptation protocol layer). SDAP maps the downlink QoS flow sent from the 5GC110 to the terminal device via the base station device and the data radio bearer (DRB) (mapping), and / or from the terminal device via the base station device. It may have a function to map the uplink QoS flow sent to the 5GC110 with the DRB. SDAP may also have a function to store mapping rule information. In addition, SDAP may have a function of marking a QoS flow identifier (QoS Flow ID: QFI). The SDAP PDU may include a data SDAP PDU and a control SDAP PDU. SDAP PDU for data may be called SDAP DATA PDU (SDAP Data PDU, SDAP data PDU). Further, the control SDAP PDU may be called an SDAP CONTROL PDU (SDAP Control PDU, SDAP control PDU, SDAP control PDU). Note that there may be one SDAP entity for the terminal device for the PDU session.

An example of the function of RRC will be explained. The RRC may have a broadcast function. The RRC may have a calling (paging) function from EPC104 and / or 5GC110. The RRC may have a call (paging) function from the eNB 102 that connects to the gNB 108 or 5GC100. The RRC may also have an RRC connection management function. The RRC may also have a wireless bearer control function. The RRC may also have a cell group control function. The RRC may also have a mobility control function. Further, the RRC may have a terminal device measurement reporting and a terminal device measurement reporting control function. The RRC may also have a QoS management function. The RRC may also have a function of detecting and recovering a wireless link failure. RRC uses RRC messages for notification, paging, RRC connection management, wireless bearer control, cell group control, mobility control, terminal device measurement reporting and terminal device measurement reporting control, QoS management, detection and recovery of wireless link failures, etc. You may go. The RRC message or parameter used in E-UTRA RRC may be different from the RRC message or parameter used in NR RRC.

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

The RRC message sent using BCCH may include, for example, a master information block (MIB), each type of system information block (System Information Block: SIB), and others. RRC message may be included. The RRC message sent using the PCCH may include, for example, a paging message, or may include other RRC messages.

RRC messages sent in the uplink (UL) direction using CCCH include, for example, RRC Setup Request message (RRC Setup Request), RRC Resume Request Message (RRC Resume Request), RRC Reestablishment Request Message (RRC Reestablishment Request), and RRC. A system information request message (RRC System Info Request) may be included. Further, for example, an RRC connection request message (RRC Connection Request), an RRC connection restart request message (RRC Connection Resume Request), an RRC connection reestablishment request message (RRC Connection Reestablishment Request), and the like may be included. It may also contain other RRC messages.

RRC messages sent in the downlink (DL) direction using CCCH include, for example, RRC Connection Reject message, RRC Connection Setup message, RRC Connection Reestablishment message, and RRC. A connection reestablishment refusal message (RRC Connection Reestablishment Reject) or the like may be included. Further, for example, an RRC reject message (RRC Reject), an RRC setup message (RRC Setup), an RRC restart message (RRC Resume), and the like may be included. It may also contain other RRC messages.

RRC messages sent in the uplink (UL) direction using DCCH include, for example, measurement report message (Measurement Report), RRC connection reconfiguration completion message (RRC Connection Reconfiguration Complete), RRC connection setup completion message (RRC Connection Setup Complete), An RRC connection reestablishment completion message (RRC Connection Reestablishment Complete), a security mode completion message (Security Mode Complete), a UE capability information message (UE Capability Information), and the like may be included. Also, for example, measurement report message (Measurement Report), RRC reconfiguration completion message (RRC Reconfiguration Complete), RRC setup completion message (RRC Setup Complete), RRC reestablishment completion message (RRC Reestablishment Complete), RRC resumption completion message (RRC Resume Complete). ), Security mode completion message (Security Mode Complete), UE capability information message (UE Capability Information), counter check response message (Counter Check Response), and the like may be included. It may also contain other RRC messages.

RRC messages sent in the downlink (DL) direction using DCCH include, for example, RRC connection reconfiguration message (RRC Connection Reconfiguration), RRC connection release message (RRC Connection Release), security mode command message (Security Mode Command), and UE capability. Inquiry messages (UE Capability Inquiry) etc. may be included. Also, for example, RRC reconfiguration message (RRC Reconfiguration), RRC restart message (RRC Resume), RRC release message (RRC Release), RRC reestablishment message (RRC Reestablishment), security mode command message (Security Mode Command), UE capability inquiry message. (UE Capability Inquiry), counter check message (Counter Check), etc. may be included. It may also contain other RRC messages.

An example of NAS functions will be explained. NAS may have an authentication function. NAS may also have the ability to manage mobility. The NAS may also have a security control function.

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

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

Next, the state transition of UE122 in LTE and NR will be explained. The UE 122 connected to the EPC or 5GC may be in the RRC_CONNECTED state when the RRC connection is established (RRC connection has been established). The state in which the RRC connection is established may include the state in which the UE 122 holds a part or all of the UE context described later. Further, the state in which the RRC connection is established may include a state in which the UE 122 can transmit and / or receive unicast data. UE122 may also be in the RRC_INACTIVE state when the RRC connection is suspended. Further, the UE 122 may be in the RRC_INACTIVE state when the UE 122 is connected to the 5GC and the RRC connection is suspended. UE122 may be in the RRC_IDLE state when it is neither in the RRC_CONNECTED state nor in the RRC_INACTIVE state.

If UE122 is connected to EPC, it does not have RRC_INACTIVE status, but E-UTRAN may start hibernation of RRC connection. When the UE122 is connected to the EPC, when the RRC connection is suspended, the UE122 may hold the AS context of the UE and the identifier (resume Identity) used for the resume (resume) and transition to the RRC_IDLE state. In the upper layer of the RRC layer of UE122 (for example, NAS layer), UE122 holds the AS context of UE, and E-UTRAN allows the return of RRC connection (Permit), and UE122 is from the RRC_IDLE state. When it is necessary to transition to the RRC_CONNECTED state, the reinstatement of the suspended RRC connection may be started.

The definition of hibernation may be different between UE122 connected to EPC104 and UE122 connected to 5GC110. Also, when UE122 is connected to the EPC (when it is hibernating in the RRC_IDLE state) and when UE122 is connected to 5GC (when it is hibernating in the RRC_INACTIVE state), the UE122 returns from hibernation. All or part of the procedure may be different.

The RRC_CONNECTED state, RRC_INACTIVE state, and RRC_IDLE state may be called the connected state (connected mode), the inactive state (inactive mode), and the idle state (idle mode), respectively, and the RRC connected state (RRC connected mode). , RRC inactive state (RRC inactive mode), RRC idle state (RRC idle mode) may be called.

The UE AS context held by UE122 is the current RRC setting, the current security context, the PDCP state including the ROHC (RObust Header Compression) state, and the C-RNTI (Cell Radio) used in the PCell of the connection source (Source). Information may include all or part of a Network Temporary Identifier), a cell identifier, and a physical cell identifier of the PCell of the connection source. The AS context of the UE held by any or all of the eNB 102 and gNB 108 may include the same information as the AS context of the UE held by the UE 122, or the information contained in the AS context of the UE held by the UE 122. May contain different information.

The security context is the encryption key at the AS level, NH (Next Hop parameter), NCC (Next Hop Chaining Counter parameter) used to derive the access key for the next hop, the identifier of the selected AS level encryption algorithm, and replay protection. It may be information containing all or part of the counters used for.

The cell group (Cell Group) set from the base station device to the terminal device will be explained. A cell group may be composed of one special cell (Special Cell: SpCell). Further, the cell group may be composed of one SpCell and one or a plurality of secondary cells (Secondary Cell: S Cell). That is, a cell group may consist of one SpCell and optionally one or more SCells. When the MAC entity is associated with the master cell group (Master Cell Group: MCG), SpCell may mean the primary cell (Primary Cell: PCell). When the MAC entity is associated with a secondary cell group (Secondary Cell Group: SCG), SpCell may mean a primary SCG cell (Primary SCG Cell: PS Cell). Also, SpCell may mean PCell if the MAC entity is not associated with a cell group. PCell, PSCell and SCell are serving cells. SpCell may support PUCCH transmission and contention-based Random Access, and SpCell may always be activated. The PCell may be a cell used for the RRC connection establishment procedure when the terminal device in the RRC idle state transitions to the RRC connection state. The PCell may also be a cell used in the RRC connection reestablishment procedure in which the terminal device reestablishes the RRC connection. Further, the PCell may be a cell used for a random access procedure at the time of handover. The PSCell may be a cell used for a random access procedure when a secondary node (Secondary Node: SN), which will be described later, is added. Further, the SpCell may be a cell used for a purpose other than the above-mentioned uses. When a cell group is composed of SpCell and one or more SCells, it can be said that carrier aggregation (CA) is set in this cell group. Further, a cell that provides additional radio resources to SpCell for a terminal device in which CA is set may mean SCell.

Timing of serving cell groups set by RRC that use the same timing reference cell and the same timing advance value for the cells in which the uplink is set. It may be called an advance group (Timing Advance Group: TAG). Further, the TAG including the SpCell of the MAC entity may mean the Primary Timing Advance Group (PTAG). Further, a TAG other than the above PTAG may mean a secondary timing advance group (STAG).

When Dual Connectivity (DC) or Multi-Radio Dual Connectivity (MR-DC) is performed, a cell group may be added from the base station device to the terminal device. DC is a technology for performing data communication using the radio resources of the cell group configured by the first base station device (first node) and the second base station device (second node). good. MR-DC may be a technique included in DC. The first base station appliance may add a second base station appliance to perform DC. The first base station device may be called a master node (MasterNode: MN). Further, the cell group composed of the master node may be called a master cell group (Master Cell Group: MCG). The second base station device may be called a secondary node (SN). A cell group composed of a secondary node may be called a secondary cell group (SCG). The master node and the secondary node may be configured in the same base station device.

Also, when DC is not set, the cell group set in the terminal device may be called MCG. Further, when DC is not set, the SpCell set in the terminal device may be PCell.

MR-DC may be a technique for performing DC using E-UTRA for MCG and NR for SCG. Further, MR-DC may be a technique for performing DC using NR for MCG and E-UTRA for SCG. Further, MR-DC may be a technique for performing DC using NR for both MCG and SCG. As an example of MR-DC that uses E-UTRA for MCG and NR for SCG, there may be EN-DC (E-UTRA-NR Dual Connectivity) that uses EPC for the core network, and NGEN- that uses 5GC for the core network. There may be DC (NG-RAN E-UTRA-NR Dual Connectivity). Further, as an example of MR-DC using NR for MCG and E-UTRA for SCG, NE-DC (NR-E-UTRA Dual Connectivity) using 5GC for the core network may be used. Further, as an example of MR-DC that uses NR for both MCG and SCG, there may be NR-DC (NR-NR Dual Connectivity) that uses 5GC for the core network.

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

Explain the wireless bearer. SRB0 to SRB2 may be defined in the SRB of E-UTRA, and other SRBs may be defined. SRB0 to SRB3 may be defined for SRB of NR, and other SRBs may be defined. SRB0 may be an SRB for RRC messages transmitted and / or received using the CCCH of the logical channel. 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 NAS messages that have been piggybacked. DCCH of the logical channel may be used for all RRC messages and NAS messages transmitted and / or received using SRB1. SRB2 may be an SRB for NAS messages and for RRC messages containing logged measurement information. DCCH of the logical channel may be used for all RRC messages and NAS messages transmitted and / or received using SRB2. Also, SRB2 may have a lower priority than SRB1. The SRB3 may be an SRB for transmitting and / or receiving a specific RRC message when EN-DC, NGEN-DC, NR-DC, etc. are set in the terminal device. DCCH of the logical channel may be used for all RRC messages and NAS messages transmitted and / or received using SRB3. Also, other SRBs may be prepared for other uses. The DRB may be a wireless bearer for user data. The logical channel DTCH may be used for RRC messages transmitted and / or received using the DRB.

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

In MR-DC, the wireless bearer in which the PDCP is placed on the master node may be called the MN terminal (terminated) bearer. Also, in MR-DC, the radio bearer in which the PDCP is placed on the secondary node may be called the SN terminated bearer. In MR-DC, a wireless bearer in which RLC bearer exists only in MCG may be called MCG bearer. Further, in MR-DC, a wireless bearer in which RLC bearer exists only in SCG may be called SCG bearer. In DC, a radio bearer in which RLC bearers exist in both MCG and SCG may be called a split bearer.

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

The RLC entity established and / or set for the RLC bearer established and / or set in the cell group composed of E-UTRA may be E-UTRA RLC. The RLC entity established and / or set for the RLC bearer established and / or set in the cell group composed of NR may be NR RLC. When EN-DC is set for the terminal device, the PDCP entity established and / or set for the MN-terminated MCG bearer may be either E-UTRA PDCP or NR PDCP. Also, when EN-DC is configured on the terminal device, for other bearer type radio bearers, namely MN-terminated split bearer, MN-terminated SCG bearer, SN-terminated MCG bearer, SN-terminated split bearer, and SN-terminated SCG bearer. The PDCP established and / or set may be NR PDCP. When NGEN-DC, NE-DC, or NR-DC is set for the terminal device, the PDCP entity established and / or set for the wireless bearer in all bearer types may be NR PDCP. ..

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

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

Next, the handover in LTE and NR will be described. The handover may be a process in which the UE 122 in the RRC connected state changes the serving cell. The handover may be performed when the UE 122 receives an RRC message instructing the handover from the eNB 102 and / or gNB 108. The RRC message instructing the handover may be a message regarding the resetting of the RRC connection including the parameter instructing the handover (for example, the information element named MobilityControlInfo or the information element named ReconfigurationWithSync). The above-mentioned information element named MobilityControlInfo may be rephrased as a mobility control setting information element, a mobility control setting, or a mobility control information. The above-mentioned information element named Reconfiguration WithSync may be rephrased as a reconfiguration information element with synchronization or a reconfiguration with synchronization. The RRC message instructing the handover may be a message indicating the movement of another RAT to a cell (for example, MobilityFromEUTRACommand or MobilityFromNRCommand). In addition, handover may be paraphrased as reconfiguration with sync. In addition, the conditions under which the UE 122 can perform handover include a part or all of the fact that AS security is activated, SRB2 is established, and at least one DRB is established. good.

The flow of RRC messages sent and received between the terminal device and the base station device will be explained. FIG. 4 is a diagram showing an example of a flow of procedures for various settings in the RRC according to the embodiment of the present invention. FIG. 4 is an example of a flow when an RRC message is sent from the base station device (eNB 102 and / or gNB 108) to the terminal device (UE122).

In Fig. 4, the base station device creates an RRC message (step S400). The RRC message may be created in the base station device so that the base station device distributes broadcast information (SI: System Information) and paging information. Further, the RRC message may be created in the base station device so that the base station device can perform processing on a specific terminal device. The process to be performed on a specific terminal device may include, for example, security-related settings, RRC connection resetting, handover to a different RAT, suspension of RRC connection, release of RRC connection, and the like. RRC connection resetting processes include, for example, wireless bearer control (establishment, modification, release, etc.), cell group control (establishment, addition, modification, release, etc.), measurement setting, handover, security key update, etc. May be included. Further, the RRC message may be created in the base station device in order to respond to the RRC message transmitted from the terminal device. The response to the RRC message transmitted from the terminal device may include, for example, a response to an RRC setup request, a response to an RRC reconnection request, a response to an RRC restart request, and the like. RRC messages include parameters for various information notifications and settings. These parameters may be called fields and / or information elements, and may be described using a description method called ASN.1 (Abstract Syntax Notation One). In the embodiment of the present invention, the parameter may be paraphrased as information.

In FIG. 4, the base station device then sends the created RRC message to the terminal device (step S402). Next, the terminal device performs processing when processing such as setting is required according to the received RRC message (step S404). The processed terminal device may send an RRC message for response to the base station device (not shown).

The RRC message is not limited to the above example, and may be used for other purposes.

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

Not limited to using MR-DC, the RRC message for E-UTRA transmitted from eNB 102 to UE122 may include the RRC message for NR, and the RRC for NR transmitted from gNB 108 to UE 122 may be included. The message may include an RRC message for E-UTRA.

An example of the parameters included in the RRC message regarding the resetting of the RRC connection will be explained. FIG. 7 is an example of an ASN.1 description representing a field and / or information element relating to the radio bearer configuration included in the message relating to the reconfiguration of the RRC connection in NR in FIG. Further, FIG. 8 is an example of an ASN.1 description representing a field and / or an information element related to the radio bearer setting included in the message regarding the resetting of the RRC connection in E-UTRA in FIG. Not limited to FIGS. 7 and 8, in the example of ASN.1 in the embodiment of the present invention, <omitted> and <omitted> are not a part of the notation of ASN.1 and other information is omitted. Show that you are. Information elements may be omitted even where there is no description of <omitted> or <omitted>. In the embodiment of the present invention, the example of ASN.1 does not correctly follow the ASN.1 notation method. In the embodiment of the present invention, the example of ASN.1 describes an example of the parameters of the RRC message in the embodiment of the present invention, and other names and other notations may be used. Further, the example of ASN.1 shows only an example relating to the main information closely related to one embodiment of the present invention in order to avoid complicated explanation. The parameters described in ASN.1 may be referred to as information elements without distinguishing them into fields, information elements, and the like. Further, in the embodiment of the present invention, the fields, information elements, etc. described in ASN.1 included in the RRC message may be paraphrased as information or may be paraphrased as parameters. The message regarding the resetting of the RRC connection may be an RRC resetting message in NR or an RRC connection resetting message in E-UTRA.

The information element represented by RadioBearerConfig in FIG. 7 may be an information element used for setting, changing, releasing, etc. of wireless bearers such as SRB and DRB. The information element represented by RadioBearerConfig may include a PDCP setting information element described later and an SDAP setting information element. The information element represented by RadioBearerConfig may be paraphrased as a radio bearer setting information element or a radio bearer setting. The information element represented by SRB-ToAddMod included in the information element represented by RadioBearerConfig may be an information element indicating the SRB (signaling radio bearer) setting. The information element represented by SRB-ToAddMod may be paraphrased as an SRB setting information element or an SRB setting. The information element represented by SRB-ToAddModList may be a list of SRB settings. The information element represented by DRB-ToAddMod included in the information element represented by RadioBearerConfig may be an information element indicating a DRB (data radio bearer) setting. The information element represented by DRB-ToAddMod may be paraphrased as a DRB setting information element or a DRB setting. The information element represented by DRB-ToAddModList may be a list of DRB settings. The SRB setting and the DRB setting may be paraphrased as a wireless bearer setting.

The field represented by srb-Identity in the SRB setting information element is the SRB identifier (SRB Identity) information of the SRB to be added or changed, and may be an identifier that uniquely identifies the SRB in each terminal device. .. The field represented by srb-Identity in the SRB setting information element may be paraphrased as an SRB identifier field or an SRB identifier. Further, the SRB identifier may be paraphrased as a wireless bearer identifier.

The field represented by drb-Identity in the DRB setting information element is the information of the DRB identifier (DRB Identity) of the DRB to be added or changed, and may be an identifier that uniquely identifies the DRB in each terminal device. .. The field represented by drb-Identity in the DRB setting information element may be paraphrased as a DRB identifier field or a DRB identifier. The value of the DRB identifier is an integer value from 1 to 32 in the example of FIG. 7, but another value may be taken. For DCs, the DRB identifier may be unique within the scope of UE122. Further, the DRB identifier may be paraphrased as a wireless bearer identifier.

In the DRB setting information element, the field represented by cnAssociation determines whether the wireless bearer is associated with the field represented by eps-bearerIdentity described later or the information element represented by SDAP-Config described later. It may be the field shown. The field represented by cnAssociation may be paraphrased as a core network association field or a core network association. The field represented by the cnAssociation may include an EPS bearer identifier field (eps-bearerIdentity) described later when the terminal device connects to the EPC104. Further, the field represented by the cnAssociation may include an information element (SDAP-Config) indicating the SDAP setting described later when the terminal device is connected to the core network 5GC110. The field indicated by eps-bearerIdentity may be a field indicating an EPS bearer identifier that identifies the EPS bearer. The field indicated by eps-bearerIdentity may be paraphrased as an EPS bearer identifier field or an EPS bearer identifier field.

The information element represented by SDAP-Config may be information related to the setting or resetting of the SDAP entity. The information element represented by SDAP-Config may be rephrased as the SDAP setting information element or the SDAP setting.

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

The field indicated by mappedQoS-FlowsToAdd included in the SDAP setting information element is information indicating a list of QoS flow identifier (QFI: QoSFlowIdentity) fields of the uplink QoS flow to be additionally mapped to the corresponding radio bearer. good. The field indicated by mappedQoS-FlowsToAdd may be paraphrased as an additional QoS flow field or an additional QoS flow. The above-mentioned QoS flow may be the QoS flow of the PDU session indicated by the PDU session included in the SDAP setting information element. The corresponding wireless bearer may be a DRB associated with a DRB identifier in the DRB setting including this SDAP setting field.

In addition, the field indicated by mappedQoS-FlowsToRelease included in the SDAP setting information element indicates a list of QoS flow identifier information elements of the QoS flows that release the correspondence among the QoS flows mapped to the corresponding radio bearer. It may be information. The field indicated by mappedQoS-FlowsToRelease may be rephrased as a QoS flow field to be released or a QoS flow to be released. The above-mentioned QoS flow may be the QoS flow of the PDU session indicated by the PDU session included in the SDAP setting information element. The corresponding wireless bearer may be a DRB associated with a DRB identifier in the DRB setting including this SDAP setting field.

In addition to this, the SDAP setting information element includes a field indicating whether or not the uplink SDAP header exists in the uplink data transmitted via the corresponding wireless bearer, and the downlink data received via the corresponding wireless bearer. May include a field indicating whether or not the downlink SDAP header exists, a field indicating whether or not the corresponding radio bearer is the default radio bearer (default DRB), and the like. The corresponding wireless bearer may be a DRB associated with a DRB identifier in the DRB setting including this SDAP setting field.

Further, the information element represented by PDCP-Config in the SRB setting information element and the DRB setting information element may be an information element related to the setting of the NR PDCP entity. The information element represented by PDCP-Config may be paraphrased as a PDCP setting information element or a PDCP setting. Information elements related to the setting of the NR PDCP entity include a field indicating the size of the uplink sequence number, a field indicating the size of the downlink sequence number, a field indicating the profile of header compression (ROHC: RObustHeaderCompression), and reordering. (Re-ordering) A field indicating the value of the timer may be included.

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

The information element represented by RadioResourceConfigDedicated in FIG. 8 may be an information element used for setting, changing, releasing, etc. of the wireless bearer. The information element represented by SRB-ToAddMod included in the information element represented by RadioResourceConfigDedicated may be information indicating the SRB (signaling radio bearer) setting. The information element represented by SRB-ToAddMod may be paraphrased as an SRB setting information element or an 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 included in the information element represented by RadioResourceConfigDedicated may be information indicating the DRB (data radio bearer) setting. The information element represented by DRB-ToAddMod may be paraphrased as a DRB setting information element or a DRB setting. The information element represented by DRB-ToAddModList may be a list of information indicating the DRB setting. In addition, any one or all of SRB setting and DRB setting may be paraphrased as wireless bearer setting.

The field represented by srb-Identity in the SRB setting information element is the SRB identifier (SRB Identity) information of the SRB to be added or changed, and may be an identifier that uniquely identifies the SRB in each terminal device. .. The field represented by srb-Identity in the SRB setting information element may be paraphrased as an SRB identifier field or an SRB identifier. Further, the SRB identifier may be paraphrased as a wireless bearer identifier. The SRB identifier in FIG. 8 may have the same role as the SRB identifier in FIG. 7.

The field represented by drb-Identity in the DRB setting is the information of the DRB identifier (DRB Identity) of the DRB to be added or changed, and may be an identifier that uniquely identifies the DRB in each terminal device. The field represented by drb-Identity in the DRB setting information element may be paraphrased as a DRB identifier field or a DRB identifier. The value of the DRB identifier is an integer value from 1 to 32 in the example of FIG. 8, but another value may be taken. Further, the DRB identifier may be paraphrased as a wireless bearer identifier. The DRB identifier in FIG. 8 may have the same role as the DRB identifier in FIG. 7.

The field represented by eps-BearerIdentity in the DRB setting information element may be an EPS bearer identifier that uniquely identifies the EPS bearer in each terminal device. The field represented by eps-BearerIdentity may be paraphrased as an EPS bearer identifier field or an EPS bearer identifier field. The value of the EPS bearer identifier is an integer value from 1 to 15 in the example of FIG. 8, but another value may be used. The EPS bearer identifier in FIG. 8 may have the same role as the EPS bearer identifier in FIG. 7. Further, the EPS bearer identifier and the DRB identifier may have a one-to-one correspondence in each terminal device.

Further, among the SRB setting information element and the DRB setting information element, the information element represented by PDCP-Config may be an information element related to the setting of the E-UTRA PDCP entity. The information element represented by PDCP-Config may be paraphrased as a PDCP setting information element or a PDCP setting. Information elements related to the setting of the E-UTRA PDCP entity include a field indicating the size of the sequence number, a field indicating the profile of header compression (ROHC: RObust Header Compression), and a field indicating the value of the re-ordering timer. May be included.

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

Further, the DRB setting information element shown in FIG. 8 may further include an information element related to the E-UTRA RLC entity setting (not shown). The information element related to the E-UTRA RLC entity setting may be rephrased as the RLC setting information element or the RLC setting. Further, the DRB setting information element shown in FIG. 8 may include a field indicating logical channel identifier (identity: ID) information. A field indicating logical channel identifier (identity: ID) information may be paraphrased as a logical channel identifier field or a logical channel identifier. Further, the DRB setting information element shown in FIG. 8 may include an information element related to the logical channel setting (not shown). The information element related to the logical channel setting may be paraphrased as the logical channel setting information element or the logical channel setting. The logical channel identifier may be associated with the wireless bearer identifier.

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

In NR, the information element related to RLC bearer setting such as the information element related to NR RLC entity setting for each radio bearer, the information element indicating logical channel identifier (identity: ID) information, and the information element related to logical channel setting is RadioBearerConfig in FIG. It may be included in the information element related to the cell group setting instead of the information element represented by (not shown). Information elements related to cell group settings may be included in the message regarding resetting the RRC connection. The information element related to the cell group setting may be paraphrased as a cell group setting information element or a cell group setting. The information element related to the NR RLC entity setting may be paraphrased as the RLC setting information element or the RLC setting. The information element indicating the logical channel identifier information may be paraphrased as a logical channel identifier information element or a logical channel identifier. The information element related to the logical channel setting may be paraphrased as the logical channel setting information element or the logical channel identifier. The logical channel identifier may be associated with the wireless bearer identifier.

Further, some or all fields and information elements described with reference to FIG. 7 or FIG. 8 may be optional. That is, the fields and information elements described with reference to FIG. 7 or FIG. 8 may be included in the message regarding the resetting of the RRC connection as necessary or conditional. In addition to the information element related to the wireless bearer setting, the message regarding the resetting of the RRC connection may include a field indicating that the full setting is applied. The field meaning that the full setting is applied may be represented by an information element name such as fullConfig, and may be indicated by using true, enable, etc. to indicate that the full setting is applied.

Based on the above description, various embodiments of the present invention will be described. In addition, each process described above may be applied to each process omitted in the following description.

FIG. 5 is a block diagram showing the configuration of the terminal device (UE122) according to the embodiment of the present invention. In addition, in order to avoid complicated explanation, FIG. 5 shows only the main components closely related to one embodiment of the present invention.

The UE 122 shown in FIG. 5 includes a receiving unit 500 that receives an RRC message or the like from a base station device, a processing unit 502 that performs processing according to parameters included in the received message, and a transmitting unit that transmits an RRC message or the like to the base station device. It consists of 504. The above-mentioned base station apparatus may be eNB 102 or gNB 108. In addition, the processing unit 502 may include some or all of the functions of various layers (for example, physical layer, MAC layer, RLC layer, PDCP layer, SDAP layer, RRC layer, and NAS layer). That is, the processing unit 502 includes a physical layer processing unit, a MAC layer processing unit, an RLC layer processing unit, a PDCP layer processing unit, an SDAP processing unit, an RRC layer processing unit, and a part or all of the NAS layer processing unit. It's okay.

FIG. 6 is a block diagram showing the configuration of the base station apparatus according to the embodiment of the present invention. In addition, in order to avoid complicated explanation, FIG. 6 shows only the main components closely related to one embodiment of the present invention. The above-mentioned base station apparatus may be eNB 102 or gNB 108.

The base station apparatus shown in FIG. 6 has a transmission unit 600 that transmits an RRC message or the like to the UE 122, and a processing unit that creates an RRC message including parameters and transmits the RRC message to the UE 122 to cause the processing unit 502 of the UE 122 to perform processing. It consists of a receiving unit 604 that receives RRC messages and the like from 602 and UE 122. In addition, the processing unit 602 may include some or all of the functions of various layers (for example, physical layer, MAC layer, RLC layer, PDCP layer, SDAP layer, RRC layer, and NAS layer). That is, the processing unit 602 includes a physical layer processing unit, a MAC layer processing unit, an RLC layer processing unit, a PDCP layer processing unit, an SDAP processing unit, an RRC layer processing unit, and a part or all of the NAS layer processing unit. It's okay.

Fig. 9 to Fig. 11 will be used to explain the outline of MBMS transmission / reception operation using SC-PTM. The terms MBMS, MBMS service, and MBMS session, which are used in the following description, may have the same meaning or may be paraphrased with each other.

FIG. 9 is a diagram showing the flow of the procedure for setting MBMS reception using SC-PTM. FIG. 10 is a diagram showing an example of an ASN.1 description representing a field and / or an information element included in SIB20 (System Information Block Type 20) in FIG. Further, FIG. 11 is a diagram showing an example of an ASN.1 description representing a field and / or an information element included in the SC-PTM configuration message (SCPTM Configuration) in FIG.

As shown in FIG. 9, the processing unit 602 of the eNB 102 creates an RRC message SIB20 (System Information Block type 20) and transmits it from the transmitting unit 600 to the UE 122 via BCCH. The receiver 500 of UE122 receives SIB20. (Step S900).

SIB20 includes information necessary for acquiring control information (specifically, SC-MCCH) related to MBMS transmission using SC-PTM. For example, SIB20 is a field represented by sc-mcch-ModificationPeriod that indicates the period in which the contents of SC-MCCH can be changed, and sc-mcch-RepetitionPeriod that indicates the transmission (retransmission) time interval of SC-MCCH by the number of wireless frames. Fields represented, fields represented by sc-mcch-Offset indicating the offset of the radio frame to which SC-MCCH is scheduled, fields represented by sc-mcch-FirstSubframe indicating the subframe to which SC-MCCH is scheduled. , Fields such as sc-mcch-duration indicating the duration of the subframe in which the SC-MCCH is scheduled, and / or include some or all of the information elements.

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

SC-PTM setting information includes control information applicable to MBMS reception. For example, the SC-PTM setting information is represented by a field represented by sc-mtch-InfoList containing the setting of each SC-MTCH in the cell transmitting the information, and by scptm-NeighbourCellList which is a list of adjacent cells providing MBMS. Fields, etc., and / or include some or all of the information elements.

The sc-mtch-InfoList contains information elements represented by one or more SC-MTCH-Info. Each SC-MTCH-Info is a field represented by mbmsSessionInfo, which is MBMS session information, and is an RNTI (Radio Network Temporary Identifier) that identifies a multicast group (specifically, SC-MTCH addressed to a specific group). -Fields represented by RNTI, fields represented by sc-mtch-schedulingInfo, which is DRX information for SC-MTCH, and sc-mtch, which is information on neighboring cells that the MBMS session can receive using SC-MTCH. -Includes some or all of the fields represented by neighborCell, etc. mbmsSessionInfo is a part of the fields such as the identifier that identifies the MBMS bearer service, the field represented by tmgi that is TMGI (Temporary Mobile Group Identity), and the field represented by sessionId that is the identifier of the MBMS session. Including all.

The processing unit 502 of UE122 establishes SC-MRB (Single Cell MBMS Point to Multipoint Radio Bearer), which is a wireless bearer for receiving MBMS sessions using SC-PTM, in order to start receiving MBMS sessions of interest. Processing may be performed (step S904). The SC-MRB establishment process is performed, for example, at the start of the MBMS session, when the MBMS service of interest to UE122 enters a cell provided via SC-MRB, or when the MBMS service becomes interested. It may be activated when the limit of the UE ability for which reception of is suppressed is removed. The SC-MRB establishment process may be performed when the UE 122 is in the RRC_IDLE state, or may be performed when the UE 122 is in the RRC_CONNECTED state. When performing the SC-MRB establishment process, the processing unit 502 of the UE 122 may perform a part or all of the following processes (A) to (D).
(A) Establish an RLC entity according to the default settings of SC-MCCH and SC-MTCH.
(B) Set the SC-MTCH logical channel to be applied to the SC-MRB to be established, and set the MAC entity to the cell that received the above SC-PTM configuration message for the MBMS session according to the above SC-PTM configuration message. Instruct so that you can receive.
(C) For the SC-MRB to be established, set the physical layer based on the above sc-mtch-InfoList.
(D) Notify the upper layer of the establishment of SC-MRB by notifying the tmgi and sessionId corresponding to the established SC-MRB.

The processing unit 502 of UE122 receives the MBMS session via the established SC-MRB according to the above SC-PTM setting message (step S906). Prior to receiving the MBMS session, the processing unit 502 of the UE 122 notifies the eNB 102 that the MBMS service is received or is interested in receiving the MBMS service via the SC-MRB. (MBMSInterestIndication) may be created and transmitted from the transmitter 504 to the eNB 102 (not shown). The MBMS interest notification message may include information on whether or not MBMS service reception is prioritized over unicast reception. Further, the MBMS interest notification message may be sent at the time of transitioning to the RRC_CONNECTED state after receiving SIB20, or after transitioning to the RRC_CONNECTED state. Further, the MBMS interest notification message may be sent when SIB20 is received at the time of handover, or may be sent when SIB20 is received at the time of reestablishing the RRC connection.

The processing unit 502 of UE122 may perform SC-MRB release processing in order to stop the reception of the MBMS session (step S908). The SC-MRB release process is, for example, when the receiving MBMS session is stopped, when the SC-MRB leaves the established cell, when the interest in the MBMS service is lost, and the MBMS service is limited to the UE capability. It may be activated when reception is suppressed. The SC-MRB release process may be performed when the UE 122 is in the RRC_IDLE state, or may be performed when the UE 122 is in the RRC_CONNECTED state. When performing the SC-MRB release process, the processing unit 502 of the UE 122 may perform a part or all of the following processes (A) to (B).
(A) Release the SC-MRB RLC entity to be released, and the related MAC and physical layer settings.
(B) Notify the release of SC-MRB by notifying the upper layer of tmgi and sessionId corresponding to the released SC-MRB.

The outline of the operation related to the setting of MBMS reception using SC-PTM has been explained above. In addition to MBMS transmission / reception in terminal equipment from base station equipment using SC-PTM (hereinafter referred to as MBMS transmission / reception), MBMS transmission / reception using MBSFN is also standardized. However, MBMS transmission / reception using SC-PTM and MBMS transmission / reception using MBSFN use E-UTRA as the RAT. Multicast broadcast service (MBS: Multicast Broadcast Service) transmission / reception using NR as RAT has not been standardized yet.

An example of the operation of UE122 and gNB108 in the embodiment of the present invention will be described with reference to FIG. The terms MBS, MBS service, MBS session, and MBS bearer used in the embodiments of the present invention may have the same meaning or may be paraphrased with each other. Further, the terms MBS, MBS service, and MBS session used in the embodiment of the present invention may be terms having the same meanings as MBMS, MBMS service, and MBMS session. Further, in the embodiment of the present invention, an MBS radio bearer may be established and / or set in the UE 122 for MBS reception. In addition, a wireless bearer for MBS may be established and / or set for MBS transmission in gNB108. Further, in the embodiment of the present invention, the wireless bearer for MBS will be described by using the name MRB (Multicast Radio Bearer), but another name may be used. Further, in the embodiment of the present invention, the MRB established and / or set in the UE 122 may be an MRB for receiving MBS in a point-to-multipoint manner, and may be an MRB for receiving MBS in a one-to-one manner. It may be an MRB for receiving (point-to-point). Further, in the embodiment of the present invention, the MRB for receiving MBS on a one-to-many basis (Point-to-Multipoint) and the MBS on a one-to-one basis (Point-to-Point) are received. The MRB for this may be the same MRB. That is, one MRB may have the ability to receive MBS one-to-many and the ability to receive MBS one-to-one. If one MRB has the ability to receive MBS one-to-many and one-to-many MBS, then the MRB has one or more RLCs to receive and / or transmit MBS one-to-many. It may include bearers and one or more RLC bearers for one-to-one reception and / or transmission of MBS. One or more RLC bearers for receiving and / or transmitting MBS one-to-many, where one MRB has the ability to receive MBS one-to-many and one-to-one MBS. And one or more RLC bearers for one-to-one reception and / or transmission of MBS may be associated with one PDCP entity. Further, one or more QoS flows may be associated with the MRB. The MRB for receiving MBS on a one-to-one basis (point-to-point) may be DRB.

Receiving and / or transmitting MBS on a one-to-many basis may mean receiving and / or transmitting MBS via a logical channel for multicast such as MTCH or SC-MTCH. Further, receiving and / or transmitting MBS on a one-to-one basis may mean receiving and / or transmitting MBS via a dedicated user data logic channel such as DTCH. In the embodiment of the present invention, receiving and / or transmitting MBS on a one-to-many basis may be paraphrased as receiving and / or transmitting MBS by multicast. Further, in the embodiment of the present invention, receiving and / or transmitting MBS on a one-to-one basis may be paraphrased as receiving and / or transmitting MBS on a unicast basis. Also, when receiving and / or transmitting MBS on a one-to-one basis, security may be applied. Also, when receiving and / or transmitting MBS one-to-many, security does not have to be applied. Security may be ciphering and deciphering, and / or integrity protection and verification.

FIG. 12 is a diagram showing an example of the flow of the MBS reception procedure in NR in the embodiment of the present invention. In this embodiment, the parameter and / or information may be a field and / or an information element in ASN.1.

As shown in FIG. 12, the processing unit 602 of gNB108 creates a first SIB (System Information Block), which is one of the RRC messages, in order to broadcast the information necessary for acquiring the control information related to MBS transmission. , May be transmitted from the transmitter 600 to UE122. The receiver 500 of the UE 122 receives the first SIB described above. The above-mentioned first SIB may be transmitted via the BCCH logical channel, or may be transmitted via another logical channel. Further, the information necessary for acquiring the control information related to the above-mentioned MBS transmission may be information related to the MCCH (Multicast Control Channel) logical channel (sometimes referred to as MCCH in the following description). The above-mentioned MCCH is MBS control information and / or MBS setting information for one or more MTCH (Multicast Traffic Channel) logical channels (sometimes referred to as MTCH in the following description) from gNB108 to UE122, and / Alternatively, it may be a point-to-multipoint downlink channel for sending MBS information. Further, the above-mentioned MTCH may be a one-to-multipoint downlink channel for transmitting MBS data from gNB108 to UE122. Further, the above-mentioned MCCH may be a multicast control channel. Further, the above-mentioned MTCH may be a multicast traffic channel. The MTCH mentioned above may be used by a UE 122 only if it receives an MBS. The above-mentioned MCCH may be referred to by another name such as MBS-MCCH or NR-MCCH. Further, the above-mentioned MTCH may be referred to by another name such as MBS-MTCH, NR-MTCH and the like. Further, 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. Further, 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. Further, the above-mentioned MBS control information and / or MBS setting 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 the above-mentioned first SIB. It may be included in a second SIB separate from the SIB. (Step S1200)

The first SIB described above includes, for example, a parameter indicating a period in which the contents of the MCCH can be changed, a parameter indicating the transmission (retransmission) time interval of the MCCH, a parameter indicating the offset of the radio frame to which the MCCH is scheduled, and the MCCH being scheduled. It may include some or all of parameters such as a parameter indicating the slot to be played, a parameter indicating the duration of the slot to which the MCCH is scheduled, and the like. The above-mentioned parameter related to the transmission (retransmission) time interval of MCCH may be indicated by the number of radio frames.

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 receiver 500 of the UE 122 may receive the RRC message transmitted by the MCCH described above based on the setting of the first SIB described above. For the above-mentioned MCCH transmission, a dedicated RNTI (Radio Network Temporary Identifier) for identifying the above-mentioned MCCH transmission may be used. Further, as the value of the dedicated RNTI for identifying the above-mentioned MCCH transmission, a specific value may be used, or a value may be set by the above-mentioned first SIB. In the embodiment of the present invention, the RRC message transmitted by the MCCH described above will be described using the message name MBS setting information message, but may be another message name. (Step S1202)

The above-mentioned MBS setting information message may include one or more MBS MTCH parameters, which are parameters for receiving MBS. For example, the MBS MTCH parameter is one or more such that the information element represented by SC-MTCH-InfoList in FIG. 11 contains one or more information elements represented by SC-MTCH-Info in the form of a list. The MBS MTCH parameters may be included in the above MBS configuration information message in the form of a list. Also, the MBS MTCH parameter may be present for each MBS session. For example, the first MBS MTCH parameter may be present for the first MBS session, and the second MBS MTCH parameter may be present for the second MBS session. In the embodiment of the present invention, the above-mentioned parameters for MBS reception will be described using the name MBS MTCH parameter, but may be another name.

MBS MTCH parameters provide parameters for MBS session information, parameters for RNTI to identify multicast groups (MTCH addressed to a specific group), parameters for logical channel identifiers, parameters for DRX information for MTCH, and the same MBS. Parameters indicating the list of adjacent cells to be used, parameters indicating whether ROHC is applied to the MBS session, parameters related to ROHC used for the MBS session, parameters related to HFN (HyperFrameNumber), parameters related to COUNT, and status report timer. It may include some or all of the parameters such as the parameters related to. The above-mentioned parameters related to MBS session information include, for example, a parameter indicating TMGI (Temporary Mobile Group Identity) which is an identifier for identifying MBS, a parameter indicating Session ID which is an identifier of MBS (or MBMS) session, and an MBS session. It may include some or all of the parameters such as the parameter indicating the PDU session and the parameter indicating the QoS flow used for the MBS session. Further, some or all of the above-mentioned MBS MTCH parameters may be contained in the above-mentioned first SIB, the above-mentioned second SIB, the above-mentioned first SIB and the above-mentioned first SIB. It may be included in a third SIB, which is separate from the second SIB.

It should be noted that the above-mentioned parameter indicating the list of adjacent cells providing the same MBS may include a parameter indicating the list of adjacent cells providing the same MBS via MTCH and / or MRB. Parameters indicating a list of adjacent cells that provide the same MBS via unicast and / or DTCH and / or DRB may be included.

Further, the MBS setting information message and / or the MBS MTCH parameter may include a parameter related to the MRB setting. The parameters related to the MRB setting may include a part or all of the parameters including the identifier identifying the MRB, the SDAP setting information element, and the PDCP setting information element. Further, the parameters related to the MRB setting described above may include one or more RLC bearer setting information elements. The above-mentioned RLC bearer setting information element may include a part or all of an RLC setting information element for establishing and / or setting an RLC entity, and a logical channel information element for logical channel setting. Further, the above-mentioned RLC bearer setting information element may be included in an information element different from the MRB setting, and may be associated with a parameter related to the MRB setting by the above-mentioned identifier for identifying the MRB or the like. The MRB settings described above may also include parameters that identify RLC bearers that receive MBS one-to-many. The MRB settings described above may also include parameters that identify RLC bearers that receive MBS on a one-to-one basis. The parameter for identifying the RLC bearer that receives the MBS one-to-many and / or the parameter for identifying the RLC bearer that receives the MBS one-to-one may be a logical channel identifier. In addition, the parameter indicating whether ROHC is applied to the above-mentioned MBS session, and / or the parameter related to ROHC used for the MBS session, and / or the parameter related to HFN (HyperFrameNumber), and / or the parameter related to COUNT, And / or parameters related to the timer of the status report may be included in the parameters related to the MRB setting, or may be included in the PDCP setting information element. Further, the above-mentioned parameters indicating the PDU session and / or the parameters indicating the QoS flow may be included in the parameters related to the MRB setting, or may be included in the SDAP setting information element. Further, the parameter indicating the above-mentioned PDU session may be a PDU session ID.

The UE 122 may receive the MBS setting information message from the receiving unit 500, and the processing unit 502 may perform a process of starting the reception of the MBS session of interest. (Step S1204)

In step S1204, the processing unit 502 of UE122 may determine whether or not ROHC is applied to the MBS session of interest from the MBS setting information message received in step S1202. The determination of whether ROHC is applied to the MBS session of interest is determined by whether the above-mentioned MBS setting information message and / or MBS MTCH parameter includes a parameter indicating whether or not the above-mentioned ROHC is applied. It may be done depending on whether or not. That is, if the above-mentioned MBS setting information message and / or the MBS MTCH parameter for the MBS session of interest contains a parameter indicating whether or not ROHC is applied, it is determined that ROHC is applied, and the above-mentioned If the MBS setting information message and / or the MBS MTCH parameter for the MBS session of interest does not include a parameter indicating whether or not ROHC is applied, it may be determined that ROHC is not applied. In addition, whether or not ROHC is applied is determined by the above-mentioned MBS setting information message and / or the value of the parameter indicating whether or not the above-mentioned ROHC included in the MBS MTCH parameter for the MBS session of interest is applied. You can go. That is, if the parameter indicating whether ROHC is applied or not included in the above-mentioned MBS setting information message and / or the MBS MTCH parameter for the MBS session of interest is a value indicating that ROHC is applied, ROHC The parameter indicating whether ROHC is applied or not, which is included in the above-mentioned MBS setting information message and / or MBS MTCH parameter for the MBS session of interest, indicates that ROHC is not applied. In that case, it may be judged that ROHC does not apply. In addition, whether or not ROHC is applied is determined by whether or not the above-mentioned MBS setting information message and / or the MBS MTCH parameter for the MBS session of interest includes the parameter related to ROHC used for the above-mentioned MBS session. You may judge by. That is, if the MBS setting information message and / or the MBS MTCH parameter for the MBS session of interest includes the parameter related to ROHC used for the MBS session, it may be determined that ROHC is applied. If the MBS setting information message and / or the MBS MTCH parameter for the MBS session of interest does not include the parameter related to ROHC used for the MBS session, it may be determined that ROHC is not applied. The MBS session you are interested in can be rephrased as a session that UE122 wants to receive, a session that UE122 is about to receive, and so on.

The parameters related to ROHC used in the above-mentioned MBS session are the parameter related to the maximum value of the Context identifier (CID) used for ROHC, the parameter related to the profile used for ROHC, and PDCP reestablishment (PDCP re). -Establishment) may include some or all of the parameters indicating whether to continue or reset the ROHC header compression protocol. Further, the parameters related to ROHC used in the above-mentioned MBS session may include parameters related to the timing at which all header information is obtained. The timing at which all the above-mentioned header information is obtained may be a cycle in which all the header information is obtained. The above-mentioned parameters related to the timing at which all header information is obtained are parameters indicating a cycle in which some or all of all header information can be changed, and the time interval in which all header information is transmitted is indicated by the number of wireless frames. Parameters, parameters indicating the offset of the radio frame where transmission of all header information is scheduled, parameters indicating the slots where transmission of all header information is scheduled, period of slots where transmission of all header information is scheduled (window) It may include some or all of the parameters indicating length). All the above-mentioned header information may be all header information among the header information (IP header, UDP header, TCP header, RTP header, etc.) to be compressed in ROHC. Further, the timing at which all the above header information is obtained may be rephrased as the timing at which ROHC context information is obtained. Further, the timing at which all the above header information is obtained may be rephrased as the timing at which the IR state and / or the FO state and / or the SO state are transmitted. The timing at which all the header information is obtained may be the timing at which the UE 122 starts receiving MBS or MTCH. Further, the timing at which all the above header information is obtained may be the timing at which the UE 122 should start receiving MBS or MTCH.

Further, in step S1204, the processing unit 502 of UE122, which determines that ROHC is applied to the MBS session of interest, needs to acquire ROHC context information based on the fact that ROHC is applied to the MBS session of interest. You can judge that. Also, in step S1204, the processing unit 502 of UE122, which determines that ROHC is not applied to the MBS session of interest, does not need to acquire ROHC context information based on the fact that ROHC is not applied to the MBS session of interest. You can judge.

Further, in step S1204, the processing unit 502 of UE122, which determines that ROHC is applied to the MBS session of interest or determines that it is necessary to acquire ROHC context information, may perform the ROHC context acquisition process. The ROHC context acquisition process described above may be that the UE 122 transitions 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 may be performed by the UE122 sending an RRC setup request message to gNB108 and receiving an RRC setup message from gNB108 as a response message to the above-mentioned RRC setup request message. In the transition from the RRC_INACTIVE state of UE122 to the RRC_CONNECTED state, UE122 sends an RRC restart request message to gNB108, and gNB108 receives an RRC restart message or RRC setup message as a response message to the above-mentioned RRC restart request message. May be done by. 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 informs gNB108 about the MBS session of interest. You may send an RRC message containing it.

In the UE 122 that has transitioned to the RRC_CONNECTED state, an MRB for receiving an MBS session on a one-to-one basis or a DRB for receiving an MBS session may be established and / or set. MRB for receiving MBS sessions on a one-to-one basis is one or more RLC bearers for receiving MBS sessions on a one-to-many basis and one or more for receiving MBS sessions on a one-to-one basis. It may be a wireless bearer including the RLC bearer of. Also, establishing and / or setting an MRB to receive an MBS session on a one-to-one basis means receiving an MRB session on a one-to-one basis to an MRB that has only an RLC bearer to receive an MRB session on a one-to-many basis. The RLC bearer for this may be additionally established and / or set. An additional RLC bearer for receiving MRB sessions on a one-to-one basis is established and / or configured as described above for an established and / or established RLC bearer for receiving an MBS session on a one-to-one basis. , May be associated with an MRB PDCP entity that has only an RLC bearer to receive MRB sessions one-to-many. The above-mentioned ROHC context acquisition process may be performed by the UE 122 receiving the above-mentioned interested MBS session on a one-to-one basis. (Step S1206)

Further, the above-mentioned ROHC context acquisition process in step S1204 may be performed according to the parameters related to ROHC included in the above-mentioned MBS setting information message and / or MBS MTCH parameter for the MBS session of interest. For example, the UE 122 may acquire the timing information at which all the header information is obtained according to the above-mentioned parameters related to the timing at which all the header information is obtained, and may acquire the ROHC context information at the timing when all the header information is obtained. The UE 122 acquires the timing information from which all the header information is obtained according to the parameters related to the timing at which all the header information is obtained in the RRC of the UE 122, and the information including a part or all of the acquired timing information is the UE 122. ROHC context information may be acquired at the timing when all header information is obtained by notifying the MAC entity of. In addition, when notifying the MAC entity of UE122 of the information including a part or all of the timing information acquired by RRC of UE122, the information of RNTI used for one-to-many reception of the MBS session may be sent together. In the RRC_IDLE state, RRC_INACTIVE state, or RRC_CONNECTED state, UE122 performs the ROHC context acquisition process according to the parameters related to ROHC included in the above-mentioned MBS setting information message and / or MBS MTCH parameter for the MBS session of interest. You can go. The timing at which all the above header information is obtained may be rephrased as the timing at which the IR state and / or the FO state and / or the SO state are used. Further, the timing at which all the above header information is obtained may be rephrased as the timing at which ROHC context information is obtained. Further, the timing at which all the above header information is obtained may be rephrased as the timing at which reception of MBS or MTCH is started. Further, the timing at which all the above-mentioned header information is obtained means the timing at which all the information contained in the header (IP header, UDP header, TCP header, RTP header, etc.) subject to header compression in ROHC is obtained. Can be paraphrased into the term. (Step S1206)

If, in step S1204, the processing unit 502 of the UE 122 determines that ROHC is not applied to the MBS session of interest, or that it is not necessary to acquire the ROHC context information, the processing unit 502 of the UE 122 determines that the ROHC context information is not applied. It may be judged that the transition to the RRC_CONNECTED state for the purpose of acquisition is not necessary. If, in step S1204, the processing unit 502 of the UE 122 determines that ROHC is not applied to the MBS session of interest, or that it is not necessary to acquire the ROHC context information, the processing unit 502 of the UE 122 is in the RRC_IDLE state or RRC_INNACTIVE. In the state, MBS service may be received without acquiring ROHC context information. If, in step S1204, the processing unit 502 of the UE 122 determines that ROHC is not applied to the MBS session of interest, or that it is not necessary to acquire the ROHC context information, the processing unit 502 of the UE 122 determines that the RRC_CONNECTED state is used. MBS service may be received without acquiring ROHC session information. (Step S1206)

In step S1204, the processing unit 502 of UE122 may determine whether the MBS setting information message received in step S1202 contains a parameter related to HFN (HyperFrameNumber) for the MBS session of interest. The above-mentioned HFN-related parameters may be HFN-related parameters used or used by gNB108 for MBS session transmission. The above-mentioned HFN-related parameter may be a parameter indicating that the UE 122 needs to acquire the value of the HFN used or used by the gNB 108 for MBS session transmission. The HFN used or used by gNB108 for MBS session transmission may be an HFN which is a state variable of the transmitting PDCP entity used or used by gNB108 for MBS session transmission. The gNB 108 may set the latest value of the HFN of the transmitting PDCP entity that the gNB 108 uses or uses for MBS session transmission as a parameter for HFN when transmitting the MBS configuration information message. Further, the above-mentioned parameter related to HFN may be a parameter related to the timing at which the value of HFN is sent from gNB108 using MCCH or MTCH. The timing at which the HFN value is sent from gNB108 using MCCH or MTCH is, for example, a parameter indicating the period during which the HFN value can be changed, a parameter indicating the time interval at which the HFN value is transmitted by the number of radio frames, and HFN. Some or all of the parameters that indicate the offset of the radio frame for which the value is scheduled, the parameter that indicates the slot for which the HFN value is scheduled, and the parameter that indicates the window length for which the HFN value is scheduled. May include. gNB108 is the latest HFN value of the transmitting PDCP entity that gNB108 uses or uses for MBS session transmission, or the last HFN value used for MBS session transmission, when the HFN value is sent. , Or the value of HFN used for the next MBS session transmission may be set in the RRC message and / or PDCP control PDU and transmitted.

If, in step S1204, 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 determines the parameters related to HFN described above. You may get the value of HFN according to and notify the PDCP entity of MRB of UE122. Further, the RRC of UE122 may be processed so that the PDCP entity of MRB of UE122 can acquire the value of HFN according to the above-mentioned parameters related to HFN. The RRC of UE122 acquires the timing information regarding the timing at which the HFN value is sent, and notifies the MAC entity of UE122 of the information including a part or all of the acquired timing information. Thereby, the RRC of UE122 and / or the PDCP entity of MRB may be processed so that the value of HFN can be acquired at the timing when the value of HFN is sent. In addition, when notifying the MAC entity of UE122 of the information including a part or all of the timing information acquired by RRC of UE122, the information of RNTI used for one-to-many reception of the MBS session may be sent together. The PDCP entity of MRB of UE122 may set the value of HFN notified from the upper layer or the value of HFN acquired by receiving the PDCP control PDU as the HFN of the receiving PDCP entity.

If, in step S1204, the processing unit 502 of the UE 122 determines that the received MBS setting information message contains parameters related to HFN for the MBS session of interest, the UE 122 is moved from the RRC_IDLE state or the RRC_INACTIVE state. , RRC_CONNECTED state may be transitioned. The RRC of UE122 in the RRC_CONNECTED state may acquire the HFN value by receiving the RRC message including the HFN value from gNB108 via DCCH. The RRC of UE122 may notify the PDCP entity of MRB of UE122 of the above-mentioned acquired HFN value. The PDCP entity of MRB of UE122 may set the value of HFN notified from the upper layer as the HFN of the receiving PDCP entity.

In step S1204, the processing unit 502 of UE122 may determine whether the MBS setting information message received in step S1202 contains a parameter related to COUNT for the MBS session of interest. The parameter related to COUNT described above may be a parameter related to the COUNT value used or used by gNB108 for MBS session transmission. The above-mentioned COUNT parameter may be a parameter indicating that the UE 122 needs to acquire the COUNT value used or used by gNB108 for MBS session transmission. The COUNT value used or used by gNB108 for MBS session transmission may be the COUNT value which is the state variable of the transmitting PDCP entity used or used by gNB108 for MBS session transmission. When sending the MBS setting information message, gNB108 may set the latest value of the COUNT value of the transmitting PDCP entity used by gNB 108 for MBS session transmission in the parameter related to COUNT. Further, the above-mentioned parameter related to COUNT may be a parameter related to the timing at which the COUNT value is sent from gNB108 using MCCH or MTCH. The timing at which the COUNT value is sent from gNB108 using MCCH or MTCH is, for example, a parameter indicating the cycle in 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 radio frames, and the COUNT value being scheduled. It may include some or all of a parameter indicating the offset of the radio frame, a parameter indicating a slot in which the COUNT value is scheduled, and a parameter indicating the period (window length) of the slot in which the COUNT value is scheduled. gNB108 is the latest COUNT value of the transmitting PDCP entity used or used by gNB108 for MBS session transmission at the time the COUNT value is sent, or the last COUNT value used for MBS session transmission. Alternatively, the COUNT value used for the next MBS session transmission may be set in the RRC message and / or the PDCP control PDU and transmitted.

If, in step S1204, the processing unit 502 of UE122 determines that the received MBS configuration information message contains a parameter related to COUNT for the MBS session of interest, the RRC of UE122 determines the parameter related to COUNT described above. You may get the COUNT value according to and notify the PDCP entity of MRB of UE122. Further, the RRC of UE122 may perform processing so that the PDCP entity of MRB of UE122 can acquire the COUNT value according to the above-mentioned parameters related to COUNT. The RRC of UE122 is a parameter related to the timing when the COUNT value is sent as described above. Therefore, by acquiring the timing information when the COUNT value is sent and notifying the MAC entity of UE122 of the information including a part or all of the acquired timing information. , It may be processed so that the RRC of UE122 and / or the PDCP entity of MRB can acquire the COUNT value at the timing when the COUNT value is sent. In addition, when notifying the MAC entity of UE122 of the information including a part or all of the timing information acquired by RRC of UE122, the information of RNTI used for one-to-many reception of the MBS session may be sent together. The PDCP entity of the MRB of UE122 may set the COUNT value notified from the upper layer or obtained by receiving the PDCP control PDU as the COUNT value of the receiving PDCP entity.

If, in step S1204, the processing unit 502 of the UE 122 determines that the received MBS setting information message contains a parameter related to COUNT for the MBS session of interest, the UE 122 is moved from the RRC_IDLE state or the RRC_INACTIVE state. , RRC_CONNECTED state may be transitioned. The RRC of UE122 in the RRC_CONNECTED state may acquire the COUNT value by receiving the RRC message including the COUNT value from gNB108 via DCCH. The RRC of UE122 may notify the PDCP entity of MRB of UE122 of the obtained COUNT value described above. The PDCP entity of MRB of UE122 may set the COUNT value notified from the upper layer as the COUNT value of the receiving PDCP entity.

Further, in step S1204, when the PDCP entity of MRB of UE122 sets the COUNT value notified from the upper layer or the COUNT value acquired by receiving the PDCP control PDU as the COUNT value of the receiving PDCP entity. , On the receiving side of the PDCP entity, it may be set in a state variable indicating the COUNT value of PDCP SDU that is expected to be received next. Also, when the PDCP entity of MRB of UE122 sets the COUNT value notified from the upper layer or the COUNT value acquired by receiving the PDCP control PDU as the COUNT value of the receiving PDCP entity, the PDCP entity On the receiving side, it may be set in a state variable indicating the COUNT value of the first PDCP PDU among the PDCP SDUs waiting to be received that have not been delivered to the upper layer. Also, when the PDCP entity of MRB of UE122 sets the COUNT value notified from the upper layer or the COUNT value acquired by receiving the PDCP control PDU as the COUNT value of the receiving PDCP entity, the above-mentioned COUNT The value may be set separately for the HFN part and the SN (Sequence Number) part.

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

In step S1204, the processing unit 502 of UE122 may determine whether the MBS setting information message received in step S1202 contains a parameter related to the timer of the status report for the MBS session of interest. The parameter related to the timer of the above-mentioned status report may be the value of the timer used for transmitting the PDCP status report. If it is determined that the received MBS configuration information message contains parameters related to the timer of the status report for the MBS session of interest, the processing unit 502 of UE122 will use the timer used to send the received PDCP status report. You may set the value. The timer used to send the PDCP status report may be used by the PDCP entity of UE122 to detect the loss of PDCP PDU or PDCP PDU. The timer used to send the PDCP status report may be a timer that runs only once per PDCP entity. Further, the timer used for transmitting the PDCP status report may be started or restarted when the UE 122 detects the loss of the PDCP PDU or the PDCP PDU. For example, the timer used to send the PDCP status report is that when the PDCP of UE122 receives the PDCP data PDU from the lower layer, the timer used to send the PDCP status report is not running and / or is received next. The state variable indicating the COUNT value of the PDCP SDU that is expected to be (for example, the state variable named RX_NEXT) indicates the COUNT value of the first PDCP PDU among the PDCP SDUs waiting to be received that have not been delivered to the upper layer. It may be started or restarted based on a condition that includes being larger than a variable (eg, a state variable named RX_DELIV). Further, the timer used for transmitting the PDCP status report may be stopped and / or reset when the UE 122 has no loss of PDCP PDU or PDCP PDU. For example, the timer used to send a PDCP status report is a state variable that indicates that the timer used to send a PDCP status report is running and / or the COUNT value of the PDCP SDU that is expected to be received next. For example, based on the fact that the state variable named RX_NEXT) is equal to the state variable indicating the COUNT value of the first PDCP PDU among the PDCP SDUs waiting to be received that have not been delivered to the upper layer (for example, the state variable named RX_DELIV). , Stop and / or may be reset. The above equality may be paraphrased as greater than or equal to. Further, the above equality may be paraphrased as less than or equal. Also, the status report of the PDCP entity of MRB may be triggered based on the expiration of the timer used to send the PDCP status report. Also, the timer used to send the PDCP status report may be stopped and / or reset based on the PDCP entity being requested to suspend by the higher layer. Also, the timer used to send the PDCP status report may be stopped and / or reset based on the PDCP entity being requested to be reestablished by the higher layer. Also, the timer used to send the PDCP status report may be stopped and / or reset based on the PDCP entity being requested to be reset by the upper layer.

MRB may be established and / or set for each MBS session in which UE122 is interested. When a plurality of MRBs are established and / or set in UE122, the processing in step S1204 may be performed on the corresponding MRB.

In step S1206, before starting the reception of the MBS session of interest, the processing unit 502 of the UE 122 may perform one or more MRB establishment processes in order to start the reception of the MBS session of interest. .. In the MRB establishment process, for example, at the start of the MBS session, the MBS service that UE122 is interested in enters the cell provided via MRB, the MBS service is interested, and the reception of the MBS service is suppressed. It may be activated based on the fact that the limit of the UE ability that has been used has been removed. The MRB establishment process may be performed when the UE 122 is in the RRC_IDLE state, may be performed when the UE 122 is in the RRC_INACTIVE state, or may be performed when the UE 122 is in the RRC_CONNECTED state. Further, the MRB establishment process may be started based on the fact that the RRC message suggesting that the MRB is established from gNB108 is received via DCCH when the UE 112 is in the RRC_CONNECTED state. The RRC message suggesting establishing the MRB described above may include some or all of the parameters contained in the MBS configuration information message in step S1202 described above. The processing unit 502 of UE122 establishes the default setting information for each entity owned by UE122, the parameters related to the MBS setting included in the MBS setting information message received via MCCH in step S1202, and the MRB received via DCCH described above. The MRB establishment process may be performed using the setting information including some or all of the parameters related to the MBS setting included in the RRC message suggesting the operation.

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

When the PDCP status report is started in the PDCP entity of one or more MRBs, the processing unit 502 of UE122 that has established one or more MRBs may create a PDCP status report and send it to gNB108. When the processing unit 502 of UE122 creates a PDCP status report in the PDCP entity of MRB, the created PDCP status report is linked to the PDCP entity of MRB to the RLC entity of RLC bearer that receives MBS on a one-to-one basis. It is not necessary to submit to the RLC bearer RLC entity that receives MBS one-to-many, which is associated with the PDCP entity of MRB. Submit the above-mentioned "Created PDCP status report to RLC bearer RLC entity that receives MBS one-to-one, which is associated with MRB PDCP entity, and MBS one-to-many associated with MRB PDCP entity. "You do not have to submit it to the RLC entity of the RLC bearer received by.", "The created PDCP status report is linked to the PDCP entity of MRB, and the RLC entity of the RLC bearer that receives MBS on a one-to-one basis. You may submit it only to. " Note that PDCP reporting in the PDCP entity of MRB may be activated only for MRB for which PDCP status report transmission is set from the upper layer. (Step S1208)

Further, in step S1208, when the PDCP status report is activated in one or more MRB PDCP entities, the processing unit 502 of UE122 associates the MRB PDCP entity with an RLC bearer that receives MBS on a one-to-one basis. Create a PDCP status report based on the fact that the RLC bearer that receives MBS on a one-to-one basis is linked, and the created status report is received on an RLC on a one-to-one basis as described above. You may only submit to Beara's RLC entity. In addition, when the PDCP status report is activated in the PDCP entity of the MRB, the processing unit 502 of the UE 122 determines whether the RLC bearer that receives the MBS on a one-to-one basis is associated with the PDCP entity of the MRB, and sets the MBS to 1. It is not necessary to create a PDCP status report based on the fact that the RLC bearer received on a one-to-one basis is not linked.

Further, in step S1208, when the PDCP status report is started in one or more MRB PDCP entities, the processing unit 502 of UE122 creates a PDCP status report and assigns MBS to the MRB PDCP entity on a one-to-one basis. Determine if the RLC bearer to be received is linked, and receive the MBS on a one-to-one basis. It may only be submitted to the RLC entity of the RLC bearer. In addition, the processing unit 502 of UE122 creates a PDCP status report when the PDCP status report is started in the PDCP entity of MRB, and is the RLC bearer that receives MBS on a one-to-one basis linked to the PDCP entity of MRB? It is not necessary to submit the created PDCP status report to the lower layer based on the fact that the RLC bearer that receives MBS on a one-to-one basis is not linked. In addition, the processing unit 502 of UE122 creates a PDCP status report when the PDCP status report is started in the PDCP entity of MRB, and is the RLC bearer that receives MBS on a one-to-one basis linked to the PDCP entity of MRB? You may discard the created PDCP status report based on the fact that the RLC bearer that receives MBS on a one-to-one basis is not linked.

Further, the RLC entity of the RLC bearer that receives the above-mentioned MBS on a one-to-one basis may be an AM RLC entity. Further, the RLC entity associated with the RLC bearer that receives the above-mentioned MBS on a one-to-one basis may be a bidirectional UM RLC entity. Further, the RLC entity associated with the RLC bearer that receives the above-mentioned MBS on a one-to-one basis may be a transmission UMRLC entity and / or a reception UMRLC entity of a unidirectional UMRLC entity.

In step S1208, the PDCP status report may be started based on the request for transmission of the PDCP status report from the RRC layer or the upper layer. The request for transmission of the PDCP status report from the above-mentioned RRC layer or higher layer may mean that the PDCP data recovery is requested from the RRC layer or higher layer. Further, in step S1208, the activation of the PDCP status report may be performed based on the release, suspension, or deactivation of one or more RLC bearers associated with the PDCP entity of MRB. Further, in step S1208, the PDCP status report may be activated when the timer of the above-mentioned status report set in step S1204 has expired in the PDCP entity. Further, in step S1208, the activation of the PDCP status report may be performed based on the fact that the RLC bearer that receives the MRB is switched. The above-mentioned switching of the RLC bearer that receives the MRB means that the RLC bearer that receives the MRB has switched from the RLC bearer that receives the MBS one-to-many to the RLC bearer that receives the MBS one-to-one. good. In addition, the above-mentioned RLC bearer that receives MRB is switched because the RLC bearer that receives MRB is switched from the RLC bearer that receives MBS one-to-one to the RLC bearer that receives MBS one-to-many. May be.

Further, in step S1208, if the RRC message received by the UE 122 from the gNB 108 contains a parameter indicating a request for PDCP status report transmission to one or more MRBs of the UE 122, the processing unit 502 of the UE 122 determines the UE 122. The RRC may request the PDCP layer of the MRB of UE122 to send a PDCP status report. The above-mentioned RRC message may be an RRC message sent via DCCH or an RRC message sent via MCCH. Also, the parameters that mean the request for PDCP status report transmission to one or more MRBs described above may include an identifier that identifies the MRB and some or all of the parameters related to the information of the MBS session. Further, in step S1208, when UE122 receives an RRC message indicating a request for PDCP status report transmission from gNB108, the processing unit 502 of UE122 transmits a PDCP status report from RRC of UE122 to the PDCP layer of MRB of UE122. May be requested. The RRC message meaning the request for transmission of the PDCP status report described above may be an RRC message sent via DCCH or an RRC message sent via MCCH. The RRC message, which means 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 related to the MBS session information.

Further, in step S1208, the processing unit 502 of the UE 122 performs a counter check process based on the fact that the RRC message (counter check message) for the counter check is received from the gNB 108 to one or more MRBs of the UE 122. Then, the result may be set in an RRC message (counter check response message) for a counter check response and reported to gNB108. The above-mentioned RRC message for counterchecking is an identifier that identifies the MRB, parameters related to MBS session information, and the most significant bit of the uplink and / or downlink COUNT value associated with the MRB. : MSB) May include some or all of the values. The above RRC message for countercheck informs gNB108 to UE122 of the MSB value of the current COUNT value associated with the MSB of gNB108 and the MSB of the current COUNT value associated with the MSB of UE122. It may be a message requesting that the comparison result with the value be reported from UE122 to gNB108. In the counter check process, the processing unit 502 of the UE 122 may perform a process including a part or all of the following processes (A) to (D) on the MRB established in the UE 122.
(A) If the MRB is a unidirectional bearer and there is no COUNT for the uplink direction and / or the downlink direction, the COUNT value in the direction where the COUNT value does not exist is assumed to be '0'.
(B) For MRBs that do not contain an identifier that identifies the MRB and / or a parameter related to MBS session information in the RRC message for counter checking, COUNT for the uplink direction and / or downlink direction held by UE122. Set the value in the RRC message for the countercheck response.
(C) The RRC message for countercheck contains the MSB value of the COUNT value in the uplink direction and / or the downlink direction for the MRB received above in the uplink direction and / or the downlink direction. If the MSB value of the COUNT value is different from the COUNT value in the uplink direction and / or the downlink direction held by UE122, the COUNT value for the uplink direction and / or the downlink direction held by UE122 is counter-checked. Set to RRC message for.
(D) For MRBs whose RRC message for countercheck contains an identifier that identifies the MRB and / or a parameter related to MBS session information, COUNT for the uplink direction and / or downlink direction held by UE122. Set the value in the RRC message for the countercheck response.

In the above explanation, the MBS session you are interested in may be paraphrased as an MBS session.

In the above explanation, the RLC bearer that receives MBS on a one-to-one basis may be an RLC bearer that sends feedback to MBS to gNB108.

In the above explanation, RLC bearer may be paraphrased as RLC entity. Further, in the above description, the RLC bearer may be paraphrased as a logical channel.

In the above description, the PDCP entity may be a receiving PDCP entity and / or a transmitting PDCP entity.

In the above explanation, ROHC may be paraphrased as Ethernet Header Compression (EHC).

Thus, in the embodiment of the present invention, the terminal device efficiently controls the MBS using NR by transmitting the PDCP status report only to the RLC bearer that receives the MBS on a one-to-one basis. Can provide terminal devices, base station devices, and methods that can be used.

The radio bearer in the above description may be a part or all of DRB, SRB, and MRB.

Further, in the above explanation, expressions such as "associate", "associate", and "associate" may be paraphrased with each other.

Further, in the above explanation, "the above" may be paraphrased as "the above".

Also, in the above explanation, "SCG SpCell" may be paraphrased as "PS Cell".

Further, in the example of each process in the above description or the example of the flow of each process, some or all of the steps may not be executed. Further, in the example of each process in the above description or the example of the flow of each process, the order of the steps may be different. Further, in the example of each process in the above description or the example of the flow of each process, some or all the processes in each step may not be executed. Further, in the example of each process in the above description or the example of the flow of each process, the order of the processes in each step may be different. Further, in the above description, "doing B based on being A" may be paraphrased as "doing B". That is, "doing B" may be executed independently of "being A".

In the above explanation, "A may be paraphrased as B" may include the meaning of paraphrasing B as A in addition to paraphrasing A as B. Further, in the above description, when "C may be D" and "C may be E" are described, "D may be E" may be included. Further, in the above description, when "F may be G" and "G may be H" are described, "F may be H" may be included.

Further, in the above description, when the condition "A" and the condition "B" are contradictory, the condition "B" may be expressed as the "other" condition of the condition "A". good.

Hereinafter, various aspects of the terminal device and the method according to the embodiment of the present invention will be described.

(1) A terminal device that communicates with a base station device, wherein the terminal device is a first RLC bearer for receiving one-to-many MBS and a second RLC for receiving one-to-one MBS. Having a bearer, the first RLC bearer and the second RLC bearer are associated with the same PDCP entity, and when the PDCP entity creates a PDCP status report, the PDCP status report is referred to as the second. Submit only to RLC bearers.

(2) A method of a terminal device that communicates with a base station device, wherein the terminal device is a first RLC bearer for receiving one-to-many MBS, and a second for receiving MBS one-to-one. The first RLC bearer and the second RLC bearer are associated with the same PDCP entity, and when the PDCP entity creates a PDCP status report, the PDCP status report is linked to the PDCP status report. Submit only to the second RLC bearer.

The program that operates on the device according to one aspect of the present invention is a program that controls a Central Processing Unit (CPU) or the like to operate a computer so as to realize the functions of the above-described embodiment related to one aspect of the present invention. There may be. The program or the information handled by the program is temporarily read into volatile memory such as Random Access Memory (RAM) at the time of processing, or stored in non-volatile memory such as flash memory or Hard Disk Drive (HDD), and is required. The CPU reads, corrects, and writes accordingly.

It should be noted that a part of the apparatus in the above-described embodiment may be realized by a computer. In that case, a program for realizing this control function may be recorded on a computer-readable recording medium, and the program recorded on the recording medium may be read by a computer system and executed. The term "computer system" as used herein is a computer system built into a device and includes hardware such as an operating system and peripheral devices. Further, the "computer-readable recording medium" may be any of a semiconductor recording medium, an optical recording medium, a magnetic recording medium, and the like.

Furthermore, a "computer-readable recording medium" is a medium that dynamically holds a program for a short period of time, such as a communication line when a program is transmitted via a network such as the Internet or a communication line such as a telephone line. In that case, a program may be held for a certain period of time, such as a volatile memory inside a computer system serving as a server or a client. Further, the above-mentioned program may be for realizing a part of the above-mentioned functions, and may be further realized for realizing the above-mentioned functions in combination with a program already recorded in the computer system.

Further, each functional block or feature of the device used in the above-described embodiment can be implemented or executed in an electric circuit, that is, typically an integrated circuit or a plurality of integrated circuits. Electrical circuits designed to perform the functions described herein can be general purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or others. Programmable Logic Devices, Discrete Gate or Transistor Logic, Discrete Hardware Components, or Combinations thereof. The general purpose processor may be a microprocessor or instead the processor may be a conventional processor, controller, microcontroller, or state machine. The general-purpose processor or each of the above-mentioned circuits may be composed of a digital circuit or an analog circuit. In addition, when an integrated circuit technology that replaces the current integrated circuit appears due to advances in semiconductor technology, it is also possible to use an integrated circuit based on this technology.

The invention of the present application is not limited to the above-described embodiment. In the embodiment, an example of the device has been described, but the present invention is not limited to this, and the present invention is not limited to this, and the stationary or non-movable electronic device installed indoors and outdoors, for example, an AV device, a kitchen device, and the like. It can be applied to terminal devices or communication devices such as cleaning / washing equipment, air conditioning equipment, office equipment, vending machines, and other living equipment.

As described above, the embodiment of the present invention has been described in detail with reference to the drawings, but the specific configuration is not limited to this embodiment, and design changes and the like within a range not deviating from the gist of the present invention are also included. Further, one aspect of the present invention can be variously modified within the scope of the claims, and the technical aspects of the present invention can also be obtained by appropriately combining the technical means disclosed in the different embodiments. Included in the range. Further, the elements described in the above-described embodiment include a configuration in which elements having the same effect are replaced with each other.

One aspect of the present invention is used in, for example, a communication system, a communication device (for example, a mobile phone device, a base station device, a wireless LAN device, or a sensor device), an integrated circuit (for example, a communication chip), a program, or the like. be able to.

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 (2)

1. A terminal device that communicates with a base station device.
   The terminal device has a first RLC bearer for one-to-many MBS reception and a second RLC bearer for one-to-one MBS reception.
   The first RLC bearer and the second RLC bearer are linked to the same PDCP entity.
   When the PDCP entity creates a PDCP status report, it submits the PDCP status report only to the second RLC bearer.
   Terminal device.
2. It is a method of a terminal device that communicates with a base station device.
   The terminal device has a first RLC bearer for one-to-many MBS reception and a second RLC bearer for one-to-one MBS reception.
   The first RLC bearer and the second RLC bearer are linked to the same PDCP entity.
   When the PDCP entity creates a PDCP status report, it submits the PDCP status report only to the second RLC bearer.
   Method.

Images