Terminal devices, methods, and integrated circuits

Abstract

The present invention is a terminal device for communicating with a base station device. The terminal device includes: a receiving unit that receives an RRC message including multicast / broadcast service (MBS) configuration information from the base station device; and a processing unit that includes MBS session information, the MBS session information including PDU session information, and the processing unit performs the following processing: based on the terminal device stopping the reception of the MBS session, releasing the MBS radio bearer used for receiving the MBS session, and notifying an upper layer of part or all of the MBS session information.

Description

Technical Field

[0001] This invention relates to terminal devices, methods, and integrated circuits.

[0002] This application claims priority to Japanese Patent Application No. 2020-79035, filed in Japan on April 28, 2020, the contents of which are incorporated herein by reference. Background Technology

[0003] The 3rd Generation Partnership Project (3GPP), a standardization initiative for cellular mobile communication systems, has conducted technical research and developed standards for cellular mobile communication systems, including radio access, core network, and services.

[0004] For example, 3GPP initiated technical research and standardization for E-UTRA (Evolved Universal Terrestrial Radio Access) as a radio access technology (RAT) for 3.9G and 4G cellular mobile communication systems. Currently, 3GPP is also conducting technical research and standardization for E-UTRA extension technologies. It should be noted that E-UTRA is also called Long Term Evolution (LTE: registered trademark), and the extension technologies are referred to as LTE-Advanced (LTE-A) and LTE-Advanced Pro (LTE-A Pro).

[0005] Furthermore, NR (New Radio or NR Radio access) technology research and standardization have begun within 3GPP as a radio access technology (RAT) for cellular mobile communication systems targeting the 5th Generation (5G). Currently, NR extension technologies are also under research and standardization within 3GPP.

[0006] Existing technical documents

[0007] Non-patent literature

[0008] Non-patent document 1: 3GPP RP-193248, “New Work Item on NR Multicast and Broadcast Services”

[0009] Non-patent document 2: 3GPP TS 23.501v15.3.0, “System Architecture for the 5G System; Stage 2”

[0010] Non-patent document 3: 3GPP TS 36.300v15.3.0, "Evolved Universal Terestrial Radio Access (E-UTRA) and Evolved Universal Terestrial Radio Access Network (E-UTRAN); Overall description; Stage 2"

[0011] Non-patent literature 4: 3GPP TS 36.331v15.4.0, "Evolved Universal Terestrial RadioAccess (E-UTRA); Radio Resource Control (RRC); Protocol specifications"

[0012] Non-patent literature 5: 3GPP TS 36.323v15.3.0, "Evolved Universal Terestrial RadioAccess (E-UTRA); Packet Data Convergence Protocol (PDCP) specification"

[0013] Non-patent document 6: 3GPP TS 36.322v15.3.0, "Evolved Universal Terestrial RadioAccess (E-UTRA); Radio Link Control (RLC) protocol specification"

[0014] Non-patent document 7: 3GPP TS 36.321v15.3.0, "Evolved Universal Terestrial RadioAccess (E-UTRA); Medium Access Control (MAC) protocol specification"

[0015] Non-patent literature 8: 3GPP TS 37.340v 15.8.0, "Evolved Universal Terestrial Radio Access (E-UTRA) and NR; Multi-Connectivity; Stage 2"

[0016] Non-patent literature 9: 3GPP TS 38.300v 15.3.0, "NR; NR and NG-RAN Overall description; Stage 2"

[0017] Non-patent literature 10: 3GPP TS 38.331v15.4.0, "NR; Radio Resource Control (RRC); Protocol specifications"

[0018] Non-patent document 11: 3GPP TS 38.323v15.3.0, "NR; Packet Data Convergence Protocol (PDCP) specification"

[0019] Non-patent document 12: 3GPP TS 38.322v15.3.0, "NR; Radio Link Control (RLC) protocol specification"

[0020] Non-patent literature 13: 3GPP TS 38.321v15.3.0, "NR; Medium Access Control (MAC) protocol specification"

[0021] Non-patent document 14: 3GPP TS 23.401v15.0.0, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access"

[0022] Non-patent document 15: 3GPP TS 26.346v16.3.0, "Multimedia Broadcast / Multicast Service (MBMS); Protocols and codecs"

[0023] Non-patent document 16: 3GPP TS 37.324v15.1.0, "NR; Service Data Adaptation Protocol (SDAP) specification" Summary of the Invention

[0024] The problem the invention aims to solve

[0025] As part of the research on extended technologies for E-UTRA, MBMS (Multimedia Broadcast Multicast Service) transmission technology was standardized to provide multicast / broadcast services. MBMS transmission utilizes either MBSFN (Multicast Broadcast Single Frequency Network) or SC-PTM (Single Cell Point-to-Multipoint).

[0026] In transmissions using MBSFN (Multicast-Broadcast Single-Frequency Network), the PMCH (Physical Multicast Channel) is used to transmit multicast / broadcast data, with the MBSFN area consisting of multiple cells as the unit. Conversely, in transmissions using SC-PTM (Single-Cell Streaming Network), the PDSCH (Physical Downlink Shared Channel) is used to transmit multicast data, with the cell as the unit.

[0027] On the other hand, Multicast Broadcast Service (MBS) as an extension technology of NR was studied (Non-Patent Document 1). When performing MBS via NR, it is necessary to consider NR-specific technologies that differ from E-UTRA, the core network for which standards have been developed for 5G, etc. However, detailed procedures for efficiently receiving MBS using NR have not yet been studied.

[0028] One aspect of the present invention is made in view of the above-mentioned problems, and one of its objectives is to provide a terminal device, method, and integrated circuit that can efficiently receive MBS using NR.

[0029] Technical solution

[0030] To achieve the above objectives, one aspect of the present invention adopts the following approach. Specifically, one aspect of the present invention is a terminal device that communicates with a base station device. This terminal device includes: a receiving unit that receives an RRC message from the base station device, including multicast / broadcast service (MBS) configuration information; and a processing unit, wherein the MBS configuration information includes MBS session information, the MBS session information includes PDU session information, and the processing unit performs the following processing: based on the terminal device stopping the reception of the MBS session, releasing the MBS radio bearer used for receiving the MBS session, and notifying an upper layer of part or all of the MBS session information.

[0031] A method for a terminal device to communicate with a base station device, wherein the terminal device receives an RRC message from the base station device including configuration information of a multicast / broadcast service (MBS), the MBS configuration information including MBS session information including PDU session information, the terminal device stops receiving the MBS session, releases the MBS radio bearer used for receiving the MBS session, and notifies an upper layer of a portion or all of the MBS session information.

[0032] It should be noted that these specific solutions can be implemented by systems, devices, methods, integrated circuits, computer programs, or recording media, or by any combination of systems, devices, methods, integrated circuits, computer programs, and recording media.

[0033] Beneficial effects

[0034] According to one aspect of the present invention, the terminal device can efficiently receive MBS using NR. Attached Figure Description

[0035] Figure 1 This is a schematic diagram of the communication system according to various embodiments of the present invention.

[0036] Figure 2 This is a protocol stack diagram of the UP and CP of the terminal device and the base station device in the E-UTRA of various embodiments of the present invention.

[0037] Figure 3 This is a protocol stack diagram of the UP and CP of the terminal device and the base station device in the NR of various embodiments of the present invention.

[0038] Figure 4 This is a diagram illustrating an example of the flow of various settings in RRC208 and / or RRC308 according to various embodiments of the present invention.

[0039] Figure 5 This is a block diagram illustrating the configuration of the terminal device according to various embodiments of the present invention.

[0040] Figure 6 This is a block diagram illustrating the configuration of a base station device according to various embodiments of the present invention.

[0041] Figure 7 This is an example of an ASN.1 description included in the message related to the resetting of the RRC connection in the NR of an embodiment of the present invention.

[0042] Figure 8 This is an example of an ASN.1 description included in a message related to the resetting of an RRC connection in an E-UTRA embodiment of the present invention.

[0043] Figure 9 This is a flowchart illustrating the setup process for MBMS reception using SC-PTM.

[0044] Figure 10 This is a diagram illustrating an example of the ASN.1 description of the fields and / or information elements included in SIB20 (System Information Block Type 20).

[0045] Figure 11 This is a diagram illustrating an example of an ASN.1 description of the fields and / or information elements included in an SC-PTM Configuration message.

[0046] Figure 12 This is a diagram illustrating an example of the configuration of an SDAP sublayer representing an embodiment of the present invention.

[0047] Figure 13 This is a diagram illustrating an example of the process for setting up MBS reception in NR according to an embodiment of the present invention. Detailed Implementation

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

[0049] LTE (and LTE-A, LTE-A Pro) and NR can be defined as different Radio Access Technologies (RATs). Furthermore, NR can be defined as a technology included in LTE. LTE can be defined as a technology included in NR. Furthermore, LTE capable of connecting to NR via Multi Radio Dual connectivity can be distinguished from existing LTE. Furthermore, LTE with a 5GC core network can be distinguished from existing LTE with an EPC core network. This implementation can be applied to NR, LTE, and other RATs. In the following description, terms associated with LTE and NR are used, but this implementation can also be applied to other technologies using other terms. Furthermore, the term E-UTRA in this implementation can be replaced with the term LTE, and vice versa.

[0050] Figure 1 This is a schematic diagram of the communication system according to various embodiments of the present invention.

[0051] E-UTRA100 is a radio access technology described in Non-Patent Document 3, etc., comprising a Cell Group (CG) consisting of one or more frequency bands. eNB (E-UTRAN Node B) 102 is the base station device of E-UTRA100. EPC (Evolved Packet Core) 104 is the core network described in Non-Patent Document 14, etc., designed as a core network for E-UTRA100. Interface 112 is the interface between eNB102 and EPC104, containing a control plane (CP) through which control signals pass and a user plane (UP) through which user data passes.

[0052] NR106 is a radio access technology described in Non-Patent Document 9, etc., which includes a Cell Group (CG) consisting of one or more frequency bands. gNB (g Node B) 108 is a base station device for NR106. 5GC110 is a core network described in Non-Patent Document 2, etc., designed as a core network for NR106, but can also be used as a core network for E-UTRA100 with the function of connecting to 5GC110. The following E-UTRA100 may include E-UTRA100 with the function of connecting to 5GC110.

[0053] Interface 114 is the interface between eNB102 and 5GC110; interface 116 is the interface between gNB108 and 5GC110; interface 118 is the interface between gNB108 and EPC104; interface 120 is the interface between eNB102 and gNB108; and interface 124 is the interface between EPC104 and 5GC110. Interfaces 114, 116, 118, 120, and 124 can be interfaces that connect only to the CP, only to the UP, or both the CP and UP. Furthermore, interfaces 114, 116, 118, 120, and 124 may not exist depending on the communication system provided by the telecommunications operator.

[0054] UE122 is a terminal device corresponding to either or both of E-UTRA100 and NR106. As described in either or both of Non-Patent Document 3 and Non-Patent Document 9, when UE122 connects to the core network via either or both of E-UTRA100 and NR106, a logical path called a Radio Bearer (RB) is established between UE122 and either or both of E-UTRA100 and NR106. The radio bearer used for CP is called a Signaling Radio Bearer (SRB), and the radio bearer used for UP is called a Data Radio Bearer (DRB). Each RB is uniquely identified by being assigned an RB Identity (or RB ID). The RB identifier used for SRB is called an SRB Identity (or SRB ID), and the RB identifier used for DRB is called a DRB Identity (or DRB ID).

[0055] As described in Non-Patent Document 3, when the destination core network of UE122 is EPC104, each DRB already established between UE122 and either or all of E-UTRA100 and NR106 is further uniquely associated with each EPS (Evolved Packet System) bearer within EPC104. Each EPS bearer is uniquely identified by being assigned an EPS bearer identifier (Identity or ID). Furthermore, the same QoS is guaranteed for data transmitted through the same EPS bearer.

[0056] As described in Non-Patent Document 9, when the destination core network of UE122 is 5GC110, one or more DRBs already established between UE122 and either or all of E-UTRA100 and NR106 are further associated with one of the PDU (Packet Data Unit) sessions to be established within 5GC110. One or more QoS flows exist in each PDU session. Each DRB may or may not be associated with any QoS flow. Each PDU session is identified by a PDU session identifier (Identity or ID). Furthermore, each QoS flow is identified by a QoS flow identifier. Moreover, the same QoS is guaranteed for data passing through the same QoS flow.

[0057] In EPC104, neither PDU session nor QoS flow exists, and EPS bearer does not exist in 5GC110. When UE122 is connected to EPC104, UE122 has EPS bearer information but does not have either PDU session or QoS flow information. When UE122 is connected to 5GC110, UE122 has either PDU session or QoS flow information but does not have EPS bearer information.

[0058] It should be noted that in the following description, eNB102 and / or gNB108 will be referred to as base station devices only, and UE122 will be referred to as terminal devices only.

[0059] Figure 2 This is a protocol stack diagram of the UP and CP of the terminal device and base station device of the E-UTRA Radio Access Layer in various embodiments of the present invention.

[0060] Figure 2 (A) is the protocol stack diagram of the UP used when UE122 communicates with eNB102 in E-UTRA100.

[0061] PHY (Physical layer) 200 is the radio physical layer, providing transmission services to the upper layer using a physical channel. PHY 200 connects to the upper-level MAC (Medium Access Control layer) 202 (described later) via a transport channel. Data moves between MAC 202 and PHY 200 via the transport channel. Data transmission and reception between the PHYs of UE122 and eNB102 occur via the radio physical channel. In PHY 200, RNTI (Radio Network Temporary Identifier) ​​is used to identify various control information.

[0062] MAC202 is a medium access control layer that maps multiple logical channels to multiple transmission channels. MAC202 connects to the higher-level RLC (Radio Link Control layer) 204 (described later) via logical channels. Logical channels are broadly classified according to the type of information transmitted, into control channels for transmitting control information and service channels for transmitting user information. MAC202 has functions such as controlling PHY200 for discontinuous reception (DRX) and / or discontinuous transmission (DTX), performing random access procedures, notifying transmission power, and performing HARQ control (Non-Patent Document 7).

[0063] The uplink (UL) and / or downlink (DL) used in E-UTRA are described using logical channels.

[0064] BCCH (Broadcast Control Channel) can be a downlink logical channel used to broadcast control information such as System Information (SI).

[0065] The PCCH (Paging Control Channel) can be a downlink logical channel used to transport paging messages. Additionally, the PCCH can also be used to notify of changes in system information.

[0066] The Common Control Channel (CCCH) can be a logical channel used to transmit control information between UE122 and eNB102. The CCCH can also be used when UE122 does not have an RRC (Radio Resource Control) connection (described later). Furthermore, the CCCH can be used between a base station and multiple terminal devices.

[0067] The DCCH (Dedicated Control Channel) can be a logical channel used for transmitting dedicated control information between UE122 and eNB102 in a point-to-point, bidirectional manner. Dedicated control information can refer to control information specific to each terminal device. The DCCH can also be used when UE122 has an RRC (Radio Resource Control) connection with eNB102, as described later.

[0068] DTCH (Dedicated Traffic Channel) can be a logical channel used to transmit user data point-to-point between UE122 and eNB102.

[0069] The MTCH (Multicast Traffic Channel) can be a point-to-multipoint downlink channel used for transmitting data from eNB102 to UE122. The SC-MTCH can be used by UE122 only if UE122 receives MBMS.

[0070] The MCCH (Multicast Control Channel) can be a point-to-multipoint downlink channel used to send MBMS control information for one or more MTCHs from eNB102 to UE122. The MCCH can also be used by UE122 only when UE122 receives MBMS or when UE122 is interested in receiving MBMS.

[0071] The SC-MTCH (Single Cell Multicast Traffic Channel) can be a point-to-multipoint downlink channel used for transmitting data from eNB102 to UE122 using SC-PTM. The SC-MTCH can also be used by UE122 only if UE122 is receiving MBMS using SC-PTM (Single Cell Point-To-Multipoint).

[0072] The SC-MCCH (Single Cell Multicast Control Channel) can be a point-to-multipoint downlink channel used to send MBMS control information for one or more SC-MTCHs from eNB102 to UE122. The SC-MCCH can also be used by UE122 only when UE122 is using SC-PTM to receive MBMS or when UE122 is interested in using SC-PTM to receive MBMS.

[0073] The mapping between the logical channel and the transport channel in the uplink of E-UTRA is explained.

[0074] CCCH can be mapped to UL-SCH (Uplink Shared Channel), which serves as the uplink transmission channel.

[0075] DCCH can also be mapped to UL-SCH (Uplink Shared Channel), which serves as the uplink transmission channel.

[0076] DTCH can also be mapped to UL-SCH (Uplink Shared Channel), which serves as the uplink transmission channel.

[0077] The mapping between logical channels and transport channels in the downlink of E-UTRA is explained.

[0078] BCCH can be mapped to BCH (Broadcast Channel) and / or DL-SCH (Downlink Shared Channel), which are used as downlink transmission channels.

[0079] PCCH can be mapped to PCH (Paging Channel), which serves as a downlink transport channel.

[0080] CCCH can be mapped to DL-SCH (Downlink Shared Channel), which serves as the downlink transmission channel.

[0081] DCCH can also be mapped to DL-SCH (Downlink Shared Channel), which serves as a downlink transmission channel.

[0082] DTCH can also be mapped to DL-SCH (Downlink Shared Channel), which serves as a downlink transmission channel.

[0083] MTCH can be mapped to MCH (Multicast Channel), which serves as a downlink transport channel.

[0084] MCCH can also be mapped to MCH (Multicast Channel), which is used as a downlink transmission channel.

[0085] SC-MTCH can also be mapped to DL-SCH (Downlink Shared Channel), which serves as a downlink transmission channel.

[0086] SC-MTCH can also be mapped to DL-SCH (Downlink Shared Channel), which serves as a downlink transmission channel.

[0087] RLC204 is a radio link control layer that segments data received from the upper-level PDCP (Packet Data Convergence Protocol Layer) 206 (described later) and adjusts the data size to enable the lower layer to transmit data appropriately. RLC204 has three modes: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). In TM mode, no segmentation of data received from the upper layer and no appending of RLC headers are performed. In UM mode, segmentation of data received from the upper layer and appending of RLC headers are performed, but retransmission control is not performed. In AM mode, segmentation of data received from the upper layer, appending of RLC headers, and retransmission control are performed. The retransmission control function can be used to ensure the requested QoS (Quality of Service) of each data transmission. During data retransmission control, information about undelivered data sent from the RLC receiver to the transmitter is called a status report. Furthermore, the instruction to send a reminder status report from the transmitting side of the RLC to the receiving side is called polling. It should be noted that sometimes data sent to the lower layer under TM is called TMD PDU, data sent to the lower layer under UM is called UMD PDU, and data sent to the lower layer under AM is called AMD PDU. (Non-Patent Document 6).

[0088] PDCP206 is a packet data convergence protocol layer used for efficient transmission of user data such as IP packets over wireless networks. PDCP206 can have header compression functionality to compress unnecessary control information. Furthermore, PDCP206 can also have data encryption functionality. Additionally, PDCP206 can also have re-ordering functionality (Non-Patent Document 5).

[0089] It should be noted that the data processed in MAC202, RLC204, and PDCP206 are respectively referred to as MAC PDU (Protocol Data Unit), RLC PDU, and PDCP PDU. Furthermore, the data transferred from the upper layer to MAC202, RLC204, or PDCP206, or transferred to the upper layer, are respectively referred to as MAC SDU (Service Data Unit), RLC SDU, and PDCP SDU. Additionally, the segmented RLC SDU is referred to as an RLC SDU segment.

[0090] Furthermore, to distinguish between data and control uses, PDCP PDUs can also be referred to as PDCP DATA PDUs (PDCPData PDU, PDCP Data PDU) and PDCP CONTROL PDUs (PDCP Control PDU, PDCP Control PDU, PDCP Control PDU). Similarly, to distinguish between data and control uses, RLC PDUs can also be referred to as RLC DATA PDUs (RLC Data PDU, RLC Data PDU) and RLC CONTROL PDUs (RLC Control PDU, RLC Control PDU, RLC Control ODU).

[0091] Figure 2 (B) is the protocol stack diagram of the CP used when UE122 communicates with eNB102 and MME (Mobility Management Entity), which is a logical node that provides authentication, mobility management and other functions, in E-UTRA100.

[0092] In the CP protocol stack, besides PHY200, MAC202, RLC204, and PDCP206, there are also RRC (Radio Resource Control layer) 208 and NAS (Non-Access Strarum) 210. RRC208 is a radio link control layer that handles RRC connection establishment, re-establishment, suspending, and resuming; RRC connection reconfiguration, such as the establishment, modification, and release of radio bearers (RBs) and cell groups; control of logical channels, transport channels, and physical channels; and handover and measurement settings. RBs can be divided into Signaling Radio Bearers (SRBs) and Data Radio Bearers (DRBs). SRBs can be used as paths for sending RRC messages as control information. DRBs can be used as paths for sending user data. Each RB can be configured between eNB102 and UE122's RRC208. Furthermore, the portion of the RB consisting of RLC204 and the logical channel can be referred to as the RLC bearer (Non-Patent Document 4). Additionally, for the NAS layer that transmits signals between the MME and UE122, a portion or all of the layers from PHY200, MAC202, RLC204, PDCP206, and RRC208 that transmit signals and data between UE122 and eNB102 can be referred to as the AS (Access Strarum) layer.

[0093] In addition, SRBs can be defined as SRB0 to SRB2, or other SRBs. SRB0 can be an SRB used for RRC messages via the Common Control Channel (CCCH) using a logical channel. SRB1 can be an SRB used for RRC messages (potentially including piggybacked NAS messages) and NAS messages before the establishment of SRB2, or it can use the Dedicated Control Channel (DCCH) entirely. SRB2 can be an SRB used for NAS messages, or it can use the DCCH entirely using a logical channel. Furthermore, SRB2 can have a lower priority than SRB1.

[0094] Furthermore, RRC messages can be transmitted using the BCCH, PCCH, or MCCH of a logical channel. RRC messages transmitted using the BCCH may include, for example, the Master Information Block (not described in Patent Document 4), various types of System Information Blocks, or other RRC messages. Similarly, RRC messages transmitted using the MCCH may include, for example, paging messages (not described in Patent Document 4), or other RRC messages. RRC messages transmitted using the MCCH may include, for example, MBSFN (Multicast Broadcast Single Frequency Network) Area Configuration (not described in Patent Document 4), MBMS Continuing Requests, or other RRC messages.

[0095] The functional classification of MAC202, RLC204, PDCP206, and RRC208 described above is an example; it is not necessary to implement only some or all of these functions. Furthermore, some or all of the functions of each layer can be included in other layers.

[0096] It should be noted that the IP layer and the layers above it, such as TCP (Transmission Control Protocol), UDP (User Datagram Protocol), and the application layer, are above the PDCP layer (not shown). Furthermore, the RRC layer and NAS (non-access cascade) layer are also above the PDCP layer (not shown). In other words, the PDCP layer is below the RRC layer, NAS layer, IP layer, and the layers above it, such as TCP (Transmission Control Protocol), UDP (User Datagram Protocol), and the application layer.

[0097] Figure 3 This is a protocol stack diagram of the UP and CP of the terminal device and the base station device in the NR wireless access layer of various embodiments of the present invention.

[0098] Figure 3 (A) is the protocol stack diagram of the UP used when UE122 communicates with gNB108 in NR106.

[0099] PHY (Physical layer) 300 is the Radio Physical layer of NR, which can provide transmission services to the upper layer using a physical channel. PHY 300 can connect to the upper-level MAC (Medium Access Control layer) 302 (described later) via a transport channel. Data can move between MAC 302 and PHY 300 via the transport channel. Data can be sent and received between the PHY of UE122 and gNB108 via the radio physical channel. RNTI (Radio Network Temporary Identifier) ​​can be used in PHY 200 to identify various control information.

[0100] Here, the physical channel will be explained.

[0101] The following physical channels can be used in wireless communication between terminal devices and base station devices.

[0102] PBCH (Physical Broadcast Channel)

[0103] PDCCH (Physical Downlink Control Channel)

[0104] PDSCH (Physical Downlink Shared Channel)

[0105] PUCCH (Physical Uplink Control Channel)

[0106] PUSCH (Physical Uplink Shared Channel)

[0107] PRACH (Physical Random Access Channel)

[0108] PBCH is used to broadcast system information required by the terminal device.

[0109] In addition, in NR, PBCH can be used as a time index (SSB-Index) within the period of a block of broadcast synchronization signals (also known as SS / PBCH block).

[0110] The PDCCH is used to transmit (or transport) Downlink Control Information (DCI) in downlink wireless communication (wireless communication from base station device 3 to terminal device). Here, one or more DCIs (also called DCI formats) are defined for the transmission of downlink control information. That is, fields for downlink control information are defined as DCIs and mapped to information bits. The PDCCH is transmitted in PDCCH candidates. The terminal device monitors the set of PDCCH candidates in the serving cell. Monitoring means attempting to decode the PDCCH according to a certain DCI format. A certain DCI format can be used for PUSCH scheduling in the serving cell. PUSCH can be used for transmitting user data, transmitting RRC messages, etc.

[0111] PUCCH can 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) indicating the state of the downlink channel. Furthermore, the uplink control information may include a scheduling request (SR) for requesting UL-SCH resources. Additionally, the uplink control information may include HARQ-ACK (Hybrid Automatic Repeat request ACK knowledgement).

[0112] PDSCH can be used to send downlink data from the MAC layer (DL-SCH: Downlink SharedCHannel). In addition, in the case of downlink, it is also used to send system information (SI), random access response (RAR), etc.

[0113] PUSCH can be used to transmit HARQ-ACK and / or CSI along with uplink data (UL-SCH: Uplink Shared Channel) or uplink data from the MAC layer. Additionally, PUSCH can be used to transmit only CSI or only HARQ-ACK and CSI. That is, PUSCH can also be used to transmit only UCI. Furthermore, PDSCH or PUSCH can be used to transmit RRC signaling (also known as RRC messages) and MAC control elements. Here, in PDSCH, the RRC signaling transmitted from the base station device can be signaling shared by multiple terminal devices within the cell. Furthermore, the RRC signaling transmitted from the base station device can also be signaling dedicated to a specific terminal device (also known as dedicated signaling). That is, dedicated signaling can be used to transmit terminal device-specific (UE-specific) information to a specific terminal device. Additionally, PUSCH can be used to transmit UE capabilities in the uplink.

[0114] PRACH can be used to send random access preambles. PRACH can be used to indicate the initial connection establishment process, the handover procedure, the connection re-establishment process, synchronization (timing adjustment) sent for the uplink, and requests for PUSCH (UL-SCH) resources.

[0115] MAC302 is a medium access control layer that maps multiple logical channels to multiple transmission channels. MAC302 can connect to the higher-level RLC (Radio Link Control layer) 304 (described later) via logical channels. Logical channels can be broadly classified according to the type of information transmitted, into control channels transmitting control information and service channels transmitting user information. MAC302 may have functions such as controlling PHY300 for intermittent transmit / receive (DRX / DTX), executing random access procedures, notifying transmit power information, and performing HARQ control (Non-Patent Document 13).

[0116] The uplink (UL) and / or downlink (DL) used in NR are described using logical channels.

[0117] BCCH (Broadcast Control Channel) can be a downlink logical channel used to broadcast control information such as System Information (SI).

[0118] PCCH (Paging Control Channel) can be a downlink logical channel used to transport paging messages.

[0119] The Common Control Channel (CCCH) can be a logical channel used to transmit control information between UE122 and gNB108. The CCCH can also be used when UE122 does not have an RRC connection. Furthermore, the CCCH can be used between the base station and multiple terminal devices.

[0120] The DCCH (Dedicated Control Channel) can be a logical channel used to transmit dedicated control information between UE122 and gNB108 in a point-to-point, bidirectional manner. Dedicated control information can refer to control information specific to each terminal device. The DCCH can also be used when UE122 has an RRC connection.

[0121] A DTCH (Dedicated Traffic Channel) can be a logical channel used to transmit user data point-to-point between UE122 and gNB108. A DTCH can exist on both the uplink and downlink sides.

[0122] The mapping between logical channels and transport channels in the uplink of NR is explained.

[0123] CCCH can be mapped to UL-SCH (Uplink Shared Channel), which serves as the uplink transmission channel.

[0124] DCCH can also be mapped to UL-SCH (Uplink Shared Channel), which serves as the uplink transmission channel.

[0125] DTCH can also be mapped to UL-SCH (Uplink Shared Channel), which serves as the uplink transmission channel.

[0126] The mapping between logical channels and transport channels in the downlink of NR is explained.

[0127] BCCH can be mapped to BCH (Broadcast Channel) and / or DL-SCH (Downlink Shared Channel) as downlink transmission channels.

[0128] PCCH can be mapped to PCH (Paging Channel), which serves as a downlink transport channel.

[0129] CCCH can be mapped to DL-SCH (Downlink Shared Channel), which serves as the downlink transmission channel.

[0130] DCCH can also be mapped to DL-SCH (Downlink Shared Channel), which serves as a downlink transmission channel.

[0131] DTCH can also be mapped to DL-SCH (Downlink Shared Channel), which serves as a downlink transmission channel.

[0132] RLC304 is a radio link control layer that segments data received from the upper-level PDCP (Packet Data Convergence Protocol Layer) 306 (described later) and adjusts the data size to enable appropriate data transmission by lower layers. RLC304 has three modes: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). In TM mode, no segmentation of data received from the upper layer and no appending of RLC headers are performed. In UM mode, segmentation of data received from the upper layer and appending of RLC headers are performed, but retransmission control is not performed. In AM mode, segmentation of data received from the upper layer, appending of RLC headers, and retransmission control are performed. The retransmission control function can be used to ensure the requested QoS (Quality of Service) of each data transmission. During data retransmission control, information about undelivered data sent from the RLC receiver to the transmitter is called a status report. Furthermore, the instruction to send a urging status report from the transmitting side of the RLC to the receiving side is called polling. It should be noted that sometimes data sent to the lower layer under TM is called TMD PDU, data sent to the lower layer under UM is called UMD PDU, and data sent to the lower layer under AM is called AMD PDU. (Non-Patent Document 12).

[0133] PDCP306 is a packet data convergence protocol layer used for efficient transmission of user data such as IP packets over wireless networks. PDCP306 can have header compression functionality to compress unnecessary control information. Furthermore, PDCP306 can also have data encryption and data integrity protection functions. In addition, PDCP306 can also have re-ordering functionality (Non-Patent Document 11).

[0134] SDAP (Service Data Adaptation Protocol) 310 is a Service Data Adaptation Protocol layer with the following functions: establishing (mapping) the correspondence between the downlink QoS flow sent from 5GC110 to the terminal device via the base station device and the DRB, and mapping the uplink QoS flow sent from the terminal device to 5GC110 via the base station device and the DRB, and storing mapping rule information (Non-Patent Document 16).

[0135] It should be noted that the data processed in MAC302, RLC304, PDCP306, and SDAP310 are respectively referred to as MAC PDU (Protocol Data Unit), RLC PDU, PDCP PDU, and SDAP PDU. Furthermore, the data transferred from the upper layer to MAC302, RLC304, PDCP306, and SDAP310, or the data transferred to the upper layer, are respectively referred to as MAC SDU (Service Data Unit), RLC SDU, PDCP SDU, and SDAP SDU. Additionally, the segmented RLC SDU is referred to as an RLC SDU segment.

[0136] Furthermore, to distinguish between data and control uses, SDAP PDUs can also be referred to as SDAP DATA PDUs (SDAPData PDU, SDAP Data PDU) and SDAP CONTROL PDUs (SDAP Control PDU, SDAP Control PDU, SDAP Control PDU). Similarly, to distinguish between data and control uses, PDCP PDUs can also be referred to as PDCP DATA PDUs (PDCPData PDU, PDCP Data PDU) and PDCP CONTROL PDUs (PDCP Control PDU, PDCP Control PDU, PDCP Control PDU). Finally, to distinguish between data and control uses, RLC PDUs can also be referred to as RLC DATA PDUs (RLC Data PDU, RLC Data PDU) and RLC CONTROL PDUs (RLC Control PDU, RLC Control PDU, RLC Control PDU).

[0137] Figure 3 (B) is the protocol stack diagram of the CP used when UE122 communicates with gNB108 and AMF (Access and Mobility Management function), which is a logical node that provides authentication, mobility management and other functions, in NR106.

[0138] In the CP protocol stack, besides PHY300, MAC302, RLC304, and PDCP306, there are also RRC (Radio Resource Control layer) 308 and NAS (non-access strawrum) 312. RRC308 is a radio link control layer that handles RRC connection establishment, re-establishment, suspending, and resuming; RRC connection reconfiguration, such as establishing, changing, and releasing radio bearers (RBs) and cell groups; control of logical channels, transport channels, and physical channels; and handover and measurement settings. RBs can be divided into signaling radio bearers (SRBs) and data radio bearers (DRBs). SRBs can be used as paths for sending RRC messages as control information. DRBs can be used as paths for sending user data. The configuration of each RB can be performed between the gNB108 and UE122's RRC308. Furthermore, the portion of the RB consisting of RLC304 and the logical channel can also be referred to as the RLC bearer (Non-Patent Document 10). Additionally, relative to the NAS layer that transmits signals between the AMF and UE122, some or all of the layers among PHY300, MAC302, RLC304, PDCP306, RRC308, and SDAP310 that transmit signals and data between UE122 and gNB108 can be referred to as the AS (Access Strarum) layer.

[0139] In addition, SRBs can be defined as SRB0 to SRB3, or other SRBs. SRB0 can be an SRB for RRC messages using the Common Control Channel (CCCH). SRB1 can be an SRB for RRC messages (possibly including piggybacked NAS messages) and NAS messages before the establishment of SRB2, or it can use the Dedicated Control Channel (DCCH) entirely. SRB2 can be an SRB for NAS messages, or it can use the DCCH entirely. Furthermore, SRB2 can have a lower priority than SRB1. SRB3 can be an SRB for specific RRC messages when UE122 is configured with EN-DC, NGEN-DC, NR-DC, etc. (described later), or it can use the DCCH entirely. Other SRBs can also be prepared for other purposes.

[0140] Furthermore, RRC messages can be transmitted using either the BCCH or PCCH of the logical channel. RRC messages transmitted using the BCCH may include, for example, the Master Information Block (MIB) described in Non-Patent Document 10, various types of System Information Blocks (SIBs), and other RRC messages. RRC messages transmitted using the BCCH may include, for example, paging messages described in Non-Patent Document 10, and other RRC messages.

[0141] The functional classification of MAC302, RLC304, PDCP306, SDAP310, and RRC308 described above is an example; it is not necessary to implement only some or all of the functions. Furthermore, some or all of the functions of each layer can also be included in other layers.

[0142] It should be noted that, as described in Non-Patent Document 2, the layer above the AS layer (not shown) can also be referred to as the PDU layer. The PDU layer can include the IP layer and any one or all of the layers above the IP layer, such as the TCP (Transmission Control Protocol) layer, the UDP (User Datagram Protocol) layer, and other layers. The application layer can be above the PDU layer or included within the PDU layer. It should be noted that the PDU layer can be the layer above the AS layer for the user plane. Furthermore, the RRC layer and the NAS (non-access strut) layer can also be the layers above any one or all of the SDAP layer and the PDCP layer (not shown). In other words, any one or all of the SDAP layer and the PDCP layer can be the layers below the RRC layer, the NAS layer, the IP layer, and any one or all of the layers above the IP layer, such as the TCP (Transmission Control Protocol) layer, the UDP (User Datagram Protocol) layer, and the application layer.

[0143] It should be noted that, in the various embodiments of the present invention, any or all of the following, which are standardized service networks in 3GPP and used in IMS (IP Multimedia Subsystem): SIP (Session Initiation Protocol), SDP (Session Description Protocol), RTP (Real-time Transport Protocol), RTCP (Real-time Transport Control Protocol), HTTP (Hypertext Transfer Protocol), etc., as well as various media codecs, can belong to the application layer.

[0144] It should be noted that the physical layer, MAC layer, RLC layer, PDCP layer, and SDAP layer of the terminal device can be established, configured, and controlled through the RRC layer of the terminal device, or all of them. Furthermore, the RRC layer of the terminal device can establish and / or configure the physical layer, MAC layer, RLC layer, PDCP layer, and SDAP layer based on RRC messages sent from the RRC layer of the base station device. Alternatively, the MAC layer, RLC layer, PDCP layer, and SDAP layer can be referred to as MAC sublayer, RLC sublayer, PDCP sublayer, and SDAP sublayer, respectively.

[0145] It should be noted that the AS layer or its functions, which are configured in either or all of the terminal device and base station device, can also be referred to as entities. That is, the physical layer (PHY layer), MAC layer, RLC layer, PDCP layer, SDAP layer, and RRC layer, or their functions, that are established, configured, and controlled in either or all of the terminal device and base station device can be referred to as physical entities (PHY entity), MAC entity, RLC entity, PDCP entity, SDAP entity, and RRC entity, respectively. Furthermore, each layer may include one or more entities of that layer. Additionally, PDCP entities and RLC entities can be established, configured, and controlled on a per-radio-bearer basis, or all of them. Furthermore, MAC entities can be established, configured, and controlled on a per-cell-group basis, or all of them. Furthermore, SDAP entities can be established, configured, and controlled on a per-PDU-session basis, or all of them.

[0146] It should be noted that the COUNT value can be used in the PDCP layer or PDCP entity for encryption or integrity protection processing. The COUNT value can consist of the HFN (Hyper Frame Number) and the sequence number (SN) appended to the header of the PDCP PDU. The sequence number is incremented by 1 each time a PDCP DATA PDU is generated in the PDCP layer or PDCP entity on the sending side. The HFN is incremented by 1 each time the sequence number reaches its maximum value. Furthermore, some or all of the state variables (A) to (F) below can be used to manage the COUNT value on both the sending and receiving sides.

[0147] (A) represents the state variable indicating the COUNT value of the PDCP SDU to be sent next. It can also be a state variable with the name TX_NEXT as described in Patent Document 11.

[0148] (B) is a status variable representing the sequence number of the next PDCP SDU to be sent in this PDCP entity. It can also be a status variable with the name Next_PDCP_TX_SN, which is not described in Patent Document 5.

[0149] (C) represents the HFN value, which is used to generate the COUNT value of the PDCP PDU in this PDCP entity. It can also be a state variable with the name TX_HFN, which is not described in Patent Document 5.

[0150] (D) represents a state variable indicating the COUNT value of the PDCP SDU to be received next at the receiving side of the PDCP entity. It can also be a state variable with the name RX_NEXT as described in Patent Document 11.

[0151] (E) represents a state variable indicating the sequence number of the next PDCP SDU to be received at the receiving side of this PDCP entity. It can also be a state variable with a name other than Next_PDCP_RX_SN as described in Patent Document 5.

[0152] (F) represents the state variable used to generate the HFN value for the COUNT value of the received PDCP PDU in this PDCP entity. It can also be a state variable with the name RX_HFN, which is not described in Patent Document 5.

[0153] Furthermore, in the PDCP layer or PDCP entity, re-ordering can refer to storing PDCP SDUs in the receive buffer and delivering them to the upper layer according to the order of the COUNT values ​​obtained from the header information of the PDCP DATA PDU. Re-ordering can also include the following process: if the COUNT value of the received PDCP data PDU is the COUNT value of the first PDCP SDU that has not yet been delivered to the upper layer, the stored PDCP SDUs are delivered to the upper layer according to the order of their COUNT values. That is, it can be the following process: in re-ordering, if a PDCP data PDU with a COUNT value smaller than the received PDCP data PDU cannot be received (PDCP data PDU loss), the received PDCP data PDU is converted into a PDCP SDU and stored in the re-ordering buffer. After all the lost PDCP data PDUs have been received and converted into PDCP SDUs, they are delivered to the upper layer. A reordering timer (a timer with the name t-Reordering as described in Non-Patent Document 11 or Non-Patent Document 5) can also be used during reordering to detect the loss of PDCP data PDUs. Furthermore, some or all of the state variables (A) to (F) below can be used for reordering.

[0154] (A) represents a state variable indicating the COUNT value of the PDCP SDU to be received next at the receiving side of the PDCP entity. It may also be a state variable with the name RX_NEXT as described in Patent Document 11.

[0155] (B) represents a state variable indicating the sequence number of the next PDCP SDU to be received at the receiving side of this PDCP entity. It can also be a state variable with a name other than Next_PDCP_RX_SN as described in Patent Document 5.

[0156] (C) represents the state variable used to generate the HFN value for the COUNT value of the received PDCP PDU in this PDCP entity. It can also be a state variable with the name RX_HFN, which is not described in Patent Document 5.

[0157] (D) represents the state variable indicating the COUNT value of the first PDCP SDU in the waiting PDCP SDUs that has not been transmitted to the upper layer at the receiving side of the PDCP entity. It can also be a state variable with the name RX_DELIV as described in Patent Document 11.

[0158] (E) represents a state variable indicating the sequence number of the PDCP PDU that was last transmitted to the upper-layer PDCP SDU on the receiving side of this PDCP entity. It can also be a state variable with the name Last_Submitted_PDCP_RX_SN, as described in Patent Document 5.

[0159] (F) represents the state variable for the next COUNT value of the PDCP PDU that triggers the reordering timer on the receiving side of the PDCP entity. It can also be a state variable named RX_REORD as described in Non-Patent Document 11 or a state variable named Reordering_PDCP_RX_COUNT as described in Non-Patent Document 5.

[0160] It should be noted that, in the various embodiments of the present invention, to distinguish between the E-UTRA protocol and the NR protocol, MAC202, RLC204, PDCP206, and RRC208 will be referred to as E-UTRA MAC or LTE MAC, E-UTRA RLC or LTE RLC, E-UTRA PDCP or LTE PDCP, and E-UTRA RRC or LTE RRC, respectively. Furthermore, MAC302, RLC304, PDCP306, and RRC308 will be referred to as NR MAC, NR RLC, NR RLC, and NR RRC, respectively. Alternatively, spaces may be used to denote terms such as E-UTRA PDCP or LTE PDCP, NR PDCP, etc.

[0161] In addition, such as Figure 1 As shown, eNB102, gNB108, EPC104, and 5GC110 can be connected via interfaces 112, 116, 118, 120, and 114. Therefore, to accommodate various communication systems, Figure 2 RRC208 can be replaced with Figure 3 RRC308. In addition, Figure 2 PDCP206 can also be replaced with Figure 3 PDCP306. In addition... Figure 3 The RRC308 may include Figure 2 The functions of RRC208. In addition. Figure 3 PDCP306 can be Figure 2 PDCP206. Furthermore, in E-UTRA100, even when UE122 is communicating with eNB102, NR PDCP can be used as the PDCP.

[0162] Next, the state transitions of UE122 in LTE and NR will be explained. When an RRC connection has been established, UE122 connected to the EPC or 5GC can be in the RRC_CONNECTED state. The state of having an RRC connection can include UE122 maintaining some or all of the UE context described later. Furthermore, the state of having an RRC connection can also include UE122 being able to send and / or receive unicast data. Additionally, UE122 can be in the RRC_INACTIVE state when the RRC connection is terminated (if UE122 is connected to the 5GC). If these conditions are not met, UE122 can be in the RRC_IDLE state.

[0163] It should be noted that UE122 connected to the EPC does not have the RRC_INACTIVE state, but it can initiate the termination of the RRC connection via E-UTRAN. In this case, when the RRC connection is terminated, UE122 retains the UE's AS context and the resumeIdentity for recovery and transitions to the RRC_IDLE state. When UE122 retains the UE's AS context, allows the recovery of the RRC connection via E-UTRAN, and UE122 needs to transition from the RRC_IDLE state to the RRC_CONNECTED state, the recovery of the terminated RRC connection can be initiated via a higher layer (e.g., the NAS layer).

[0164] That is, the definition of abort can be different for UE122 connected to EPC and UE122 connected to 5GC. In addition, the process of UE122 recovering from abort can be wholly or partially different in the case of UE122 connected to EPC (aborted in RRC_IDLE state) and the case of UE122 connected to 5GC (aborted in RRC_INACTIVE state).

[0165] It should be noted that the RRC_CONNECTED, RRC_INACTIVE, and RRC_IDLE states can be referred to as connected mode, inactive mode, and idle mode, respectively. They can also be referred to as RRC connected mode, RRC inactive mode, and RRC idle mode.

[0166] The AS context of the UE maintained by UE122 may include all or a portion of the following information: the current RRC settings, the current security context, the PDCP state including the ROHC (Robust Header Compression) state, the C-RNTI (Cell Radio Network Temporary Identifier) ​​used in the PCell of the connection source, the cell identifier, and the physical cell identifier of the PCell of the connection source. It should be noted that the AS context of the UE maintained by either or both of eNB102 and gNB108 may include the same information as the AS context of the UE maintained by UE122, or it may include information different from the information included in the AS context of the UE maintained by UE122.

[0167] Security context can refer to all or part of the information in the following: encryption key at the AS level, NH (Next Hop parameter), NCC (Next Hop Chaining Counter parameter) derived from the access key used for the next hop, identifier of the selected AS-level encryption algorithm, and counters used for playback protection.

[0168] Next, handover in LTE and NR will be explained. Handover can refer to the process of UE122 changing its serving cell in the RRC connection state. Handover can occur when UE122 receives an RRC message indicating handover from eNB102 and / or gNB108. The RRC message indicating handover can be a message related to the reconfiguration of the RRC connection, including parameters indicating handover (e.g., an information element named MobilityControlInfo as described in Non-Patent Document 4 or an information element named ReconfigurationWithSync as described in Non-Patent Document 10), or it can be a message indicating movement to a cell of another RAT (e.g., MobilityFromEUTRACommand as described in Non-Patent Document 4 or MobilityFromNRCommand as described in Non-Patent Document 10). Furthermore, the conditions under which UE122 can perform handover may include some or all of the following: AS security is activated, SRB2 has been established, or at least one DRB has been established.

[0169] Figure 4This is a diagram illustrating an example of the flow of procedures for various settings in RRC208 and / or (and / or) RRC308 according to various embodiments of the present invention. Figure 4 This is an example of a procedure in which an RRC message is sent from a base station device (eNB102 and / or gNB108) to a terminal device (UE122).

[0170] exist Figure 4 In step S400, the base station device generates an RRC message. The generation of the RRC message in the base station device can occur when the base station device transmits broadcast information (SI: System Information) or paging information, or when it is determined that the base station device needs to process a specific terminal device, such as security-related settings, resetting of the RRC connection (processing of wireless bearers (establishment, modification, release, etc.), processing of cell groups (establishment, addition, modification, release, etc.), determination settings, handover settings, etc.), and release of the RRC connection status. Furthermore, the RRC message can be used as a handover command to different RATs. The RRC message includes information (parameters) for various information notifications and settings. In specifications related to RRC, such as Non-Patent Document 4 or Non-Patent Document 10, these parameters may also be referred to as fields and / or information elements, and are described using the ASN.1 (Abstract Syntax Notation One) notation.

[0171] exist Figure 4 Next, the base station device sends the generated RRC message to the terminal device (step S402). Then, the terminal device processes the received RRC message if necessary (step S404).

[0172] It should be noted that the generation of RRC messages is not limited to the examples above. As described in Non-Patent Document 4, Non-Patent Document 10, etc., they can also be generated for other purposes.

[0173] For example, RRC messages can be used for settings related to dual connectivity (DC) and multi-radio dual connectivity (MR-DC) as described in Non-Patent Document 8.

[0174] Dual Connectivity (DC) can refer to the following technology: data communication is performed using the radio resources of two cell groups (nodes) composed of two base station devices: a Master Cell Group (MCG) composed of a Master Node (MN) and a Secondary Cell Group (SCG) composed of Secondary Nodes (SN). Furthermore, the Master Node and Secondary Node can be the same node (the same base station device). Additionally, MR-DC can refer to the technology described in Non-Patent Document 8, which involves cell grouping of the cells of both the E-UTRA and NR RATs (Radio Access Technology) and allocating them to the UE per RAT, utilizing the radio resources of both the MCG and SCG for data communication; it can also refer to dual connectivity (DC) using the NR RAT. In MR-DC, a primary node can refer to a base station that has the main RRC functions of MR-DC, such as adding secondary nodes, establishing, changing and releasing RBs, adding, changing, releasing and switching MCGs, etc. A secondary node can refer to a base station that has some RRC functions, such as changing and releasing SCGs.

[0175] In the MR-DC described in Non-Patent Document 8, the RRC of the RAT on the master node side can be used to configure both the MCG and SCG. For example, in the EN-DC (E-UTRA-NR Dual Connectivity) of the MR-DC where the core network is EPC104 and the master node is eNB102 (also known as extended eNB102), and in the NGEN-DC (NG-RAN E-UTRA-NR Dual Connectivity) of the MR-DC where the core network is 5GC110 and the master node is eNB102, the E-UTRA RRC message described in Non-Patent Document 4 can be sent and received between eNB102 and UE122. In this case, the RRC message can include not only LTE (E-UTRA) configuration information, but also NR configuration information described in Non-Patent Document 10. Furthermore, RRC messages sent from eNB102 to UE122 can also be sent from eNB102 to UE122 via gNB108. Additionally, the configuration of this RRC message can also be used by eNB102 (extended eNB) to use 5GC as the core network in E-UTRA / 5GC.

[0176] Furthermore, conversely, in the MR-DC described in Non-Patent Document 8, in the NE-DC (NR-E-UTRA Dual Connectivity) of the MR-DC where the core network is 5GC110 and the master node is gNB108, RRC messages for NR as described in Non-Patent Document 10 can be sent and received between gNB108 and UE122. In this case, the RRC message can include not only NR configuration information but also LTE (E-UTRA) configuration information as described in Non-Patent Document 4. Furthermore, the RRC message sent from gNB108 to UE122 can also be sent from gNB108 to UE122 via eNB102.

[0177] It should be noted that, not limited to the use of MR-DC, the E-UTRA RRC message sent from eNB102 to UE122 may include the NR RRC message, and the NR RRC message sent from gNB108 to UE122 may include the E-UTRA RRC message.

[0178] Furthermore, a network configuration with eNB102 as the master node and EPC104 as the core network can also be called E-UTRA / EPC. Similarly, a network configuration with eNB102 as the master node and 5GC110 as the core network can be called E-UTRA / 5GC. Additionally, a network configuration with gNB108 as the master node and 5GC110 as the core network can be called NR or NR / 5GC. Moreover, this designation is not limited to the case where a DC is configured. In the absence of a DC, the aforementioned master node can refer to a base station device that communicates with the terminal device.

[0179] Figure 7 It means in Figure 4 An example of an ASN.1 description of fields and / or information elements related to radio bearer settings included in a message related to the reconfiguration of an RRC connection in the NR. Furthermore, Figure 8 It means in Figure 4 An example of an ASN.1 description of fields and / or information elements related to radio bearer settings included in a message related to the reconfiguration of an RRC connection in E-UTRA. Not limited to... Figure 7 , Figure 8In the examples of ASN.1 in the embodiments of the present invention, "<omitted>" and "<omitted in the middle>" indicate the omission of other information, rather than the omission of a part of the ASN.1 description. It should be noted that information elements may also be omitted where there is no "<omitted>" or "<omitted in the middle>". It should be noted that in the embodiments of the present invention, the examples of ASN.1 do not correctly follow the ASN.1 description method, but rather describe an example of parameters of a message related to the resetting of an RRC connection in the embodiments of the present invention; other names and descriptions may also be used. Furthermore, to avoid complicating the explanation, the examples of ASN.1 only represent examples of key information closely related to one embodiment of the present invention. It should be noted that sometimes the parameters described by ASN.1 are not distinguished as fields, information elements, etc., but are all referred to as information elements. Furthermore, in the embodiments of the present invention, the parameters such as fields and information elements included in the RRC message and described by ASN.1 are sometimes referred to as information. It should be noted that the message related to the resetting of the RRC connection can refer to the RRC reset message in NR or the RRC connection reset message in E-UTRA.

[0180] exist Figure 7 The information elements represented by RadioBearerConfig are related to the settings of radio bearers such as SRB and DRB, including the PDCP setting information elements and SDAP setting information elements mentioned later. The information elements represented by SRB-ToAddMod within the information elements represented by RadioBearerConfig can represent SRB (Signaling Radio Bearer) settings, and are sometimes referred to as SRB setting information elements or signaling radio bearer setting information elements. Additionally, the information elements represented by SRB-ToAddModList can be a list of SRB setting information. Similarly, the information elements represented by DRB-ToAddMod within the information elements represented by RadioBearerConfig can represent DRB (Data Radio Bearer) settings, and are sometimes referred to as DRB setting information elements or data radio bearer setting information elements. The information elements represented by DRB-ToAddModList can be a list of DRB setting information. It should be noted that sometimes either or both of SRB settings and DRB settings are referred to as radio bearer settings.

[0181] The information element represented by SRB-Identity in the SRB configuration information element is the SRB identifier (SRB Identity) of the SRB to be added or changed, or it can be an identifier that uniquely identifies the SRB in each terminal device. Sometimes, the information element represented by SRB-Identity in the SRB configuration information element is also called the SRB identifier information element, radio bearer identifier information element, or signaling radio bearer identifier information element.

[0182] The information element represented by DRB-Identity in the DRB configuration information element is the DRB identifier (DRB Identity) of the DRB to be added or changed, or it can be an identifier that uniquely identifies the DRB in each terminal device. Sometimes, the information element represented by DRB-Identity in the DRB configuration information element is also called the DRB identifier information element, radio bearer identifier information element, or data radio bearer identifier information element. Figure 7 In the example, the DRB identifier is set to an integer value from 1 to 32, but other values ​​are also possible. In the case of DC, the DRB identifier is unique within the range of UE122.

[0183] The information element represented by cnAssociation in the DRB configuration information element can be an information element indicating whether EPC104 or 5GC110 is used in the core network, and is sometimes also referred to as the core network association establishment information element. That is, when UE122 is connected to EPC, the DRB is associated with the EPS bearer identifier information element (eps-BearerIdentity) in cnAssociation or the EPS bearer identifier (EPS beareridentity) as the value of the EPS bearer identifier information element. When UE122 is connected to 5GC110, the DRB is associated with the SDAP entity set according to the SDAP configuration information element (sdap-Config) described later, or the PDU session information element included in the SDAP configuration information element described later, or the PDU session identifier as the value of the PDU session information element, or the PDU session shown by the PDU session information element. That is, the information represented by cnAssociation may include the EPS bearer identifier information element (eps-BearerIdentity) in the case of using EPC104 in the core network when using EN-DC, and the information element representing SDAP configuration (sdap-Config) in the case of using core network 5GC110, i.e., when not using EN-DC.

[0184] In the case of a core network of 5GC110, the information element represented by sdap-Config can be information related to the setting or resetting of SDAP entities that determines the mapping method between QoS flows and DRBs (map). Sometimes it is also referred to as SDAP setting information element.

[0185] The field or information element represented by pdu-session or PDU-SessionID included in the SDAP configuration information element can be the PDU session identifier of the QoS flow to which the radio bearer establishes a mapping (map) corresponding to the value of the radio bearer identifier information element belongs, as described in Non-Patent Document 2. It is sometimes also referred to as the PDU session identifier information element. The value of the PDU session identifier information element can be a non-negative integer. Furthermore, in each terminal device, one PDU session identifier can correspond to multiple DRB identifiers.

[0186] The information element represented by `mappedQoS-FlowsToAdd` included in the SDAP configuration information element can be information from a list of QoS flow representations (QFI: QoS Flow Identity) information elements (sometimes referred to as appended QoS flow information elements) included in the DRB configuration information element of this SDAP configuration information element, which correspond to the radio bearer identifier information element's value and are either mapped or appended to it. The aforementioned QoS flow can be the QoS flow of the PDU session shown in the PDU session information element included in this SDAP configuration information element.

[0187] Furthermore, the information element represented by `mappedQoS-FlowsToRelease` included in the SDAP configuration information element can be information from a list of QoS flow representations (QFI: QoS Flow Identity) information elements (sometimes referred to as released QoS flow information elements) included in the DRB configuration information element of this SDAP configuration information element, which corresponds to the value of the radio bearer identifier information element and is associated with the radio bearer. The aforementioned QoS flow can be the QoS flow of the PDU session shown in the PDU session information element included in this SDAP configuration information element.

[0188] The information element represented by QFI can be a QoS flow identifier, which uniquely identifies a QoS flow as described in Non-Patent Document 2, and is sometimes referred to as a QoS flow identifier information element. The value of the QoS flow identifier information element can be a non-negative integer. Furthermore, the value of the QoS flow identifier information element can be unique for a PDU session.

[0189] In addition, the SDAP configuration information elements may include, besides, an uplink header information element indicating whether uplink data transmitted via the configured DRB contains an uplink SDAP header, a downlink header information element indicating whether downlink data received via the configured DRB contains a downlink SDAP header, and a default bearer information element indicating whether the configured DRB is the default radio bearer (default DRB).

[0190] Furthermore, the information elements represented by pdcp-Config or PDCP-Config in the SRB configuration information elements and DRB configuration information elements can be information elements related to the configuration of the NRPDCP entity used for establishing and changing PDCP306 for SRB and / or DRB, and are sometimes also referred to as PDCP configuration information elements. Information elements related to the configuration of the NR PDCP entity may include information elements indicating the size of the uplink sequence number, information elements indicating the size of the downlink sequence number, information elements indicating the header compression (RoHC) profile, re-ordering timer information elements, etc.

[0191] The information element represented by RadioBearerConfig, which includes the information element represented by DRB-ToReleaseList, can include information indicating one or more DRB identifiers to be released.

[0192] exist Figure 8The information element represented by RadioResourceConfigDedicated can also be an information element used for setting, changing, or releasing radio bearers. The information element represented by SRB-ToAddMod included in the information element represented by RadioResourceConfigDedicated can be information representing SRB (Signaling Radio Bearer) settings, sometimes also referred to as SRB setting information element or signaling radio bearer setting information element. The information element represented by SRB-ToAddModList can be a list of information representing SRB settings. The information element represented by DRB-ToAddMod included in the information element represented by RadioResourceConfigDedicated can be information representing DRB (Data Radio Bearer) settings, sometimes also referred to as DRB setting information element or data radio bearer setting information element. The information element represented by DRB-ToAddModList can be a list of information representing DRB settings. It should be noted that sometimes either or both of SRB settings and DRB settings are referred to as radio bearer settings.

[0193] The information element represented by SRB-Identity in the SRB configuration information element is the SRB identifier (SRB Identity) of the SRB to be added or changed, or it can be an identifier that uniquely identifies the SRB in each terminal device. Sometimes, the information element represented by SRB-Identity in the SRB configuration information element is also called the SRB identifier information element, radio bearer identifier information element, or signaling radio bearer identifier information element. Figure 8 The information element represented by SRB-Identity can also be related to Figure 7 Information elements represented by SRB-Identity have the same function.

[0194] In DRB configuration, the information element represented by DRB-Identity is the DRB identifier (DRB Identity) of the DRB to be added or changed, or it can be an identifier that uniquely identifies the DRB in each terminal device. Sometimes, the information element represented by DRB-Identity in DRB configuration is also called DRB identifier information element, radio bearer identifier information element, or data radio bearer identifier information element. Figure 8 In the example, the DRB identifier is set to an integer value from 1 to 32, but other values ​​are also possible. Figure 8 The information element represented by DRB-Identity can also be related to Figure 7 Information elements represented by DRB-Identity have the same function.

[0195] The information element represented by eps-BearerIdentity in the DRB configuration information element can be an EPS bearer identifier that uniquely identifies the EPS bearer in each terminal device. The information element represented by eps-BearerIdentity is sometimes also called the EPS bearer identifier information element. Figure 8 In the example, the EPS carrier identifier is set to an integer value from 1 to 15, but other values ​​are also possible. Figure 8 The information element represented by eps-BearerIdentity can also be related to Figure 7 The information element represented by eps-BearerIdentity has the same function. Furthermore, the EPS bearer identifier and the DRB identifier can be matched one-to-one in each terminal device.

[0196] Furthermore, the information elements represented by pdcp-Config or PDCP-Config in the SRB configuration information elements and DRB configuration information elements can be information elements related to the establishment and modification of PDCP206 for SRB and / or DRB, and are sometimes referred to as PDCP configuration information elements. Information elements related to the configuration of the E-UTRA PDCP entity may include information elements indicating the serial number size, information elements indicating the header compression (RoHC) profile, re-ordering timer information elements, etc.

[0197] also, Figure 7 or Figure 8 Some or all of the information elements shown may be optional. That is... Figure 7 or Figure 8 The information elements shown can be included in messages related to resetting the RRC connection as needed and under certain conditions. Furthermore, in addition to information elements related to radio bearer settings, messages related to resetting the RRC connection may also include information elements indicating the application of a full configuration. Information elements indicating the application of a full configuration can be represented by information element names such as `fullConfig`, or by using terms such as `true` or `enable` to indicate the application of a full configuration.

[0198] The information element represented by RadioResourceConfigDedicated, which includes the information element represented by DRB-ToReleaseList, can include information indicating one or more DRB identifiers to be released.

[0199] During the establishment, re-establishment, or handover of an RRC connection, a serving cell provides NAS mobility information. During the re-establishment or handover of an RRC connection, a serving cell provides security input. This serving cell can be referenced as the primary cell (PCell). Furthermore, depending on the capabilities of the terminal device, one or more serving cells (secondary cells, SCells) can be added and configured along with the primary cell.

[0200] Furthermore, a set of serving cells consisting of two subsets can be configured for the terminal device. These two subsets can consist of: a cell group (primary cell group) comprising one or more serving cells including a primary cell (PCell) and one or more cell groups (secondary cell group) comprising one or more serving cells including a primary secondary cell (PSCell) but not a primary cell. The primary and secondary cells can be cells configured with PUCCH resources. It should be noted that PCell and / or PSCell can also be referred to as a special cell (SpCell).

[0201] Based on the above description, various embodiments of the present invention will be described. It should be noted that the processes described above can be applied to the processes omitted in the following description.

[0202] Figure 5 This is a block diagram illustrating the configuration of the terminal device (UE122) according to various embodiments of the present invention. It should be noted that, to avoid unnecessary detail, in... Figure 5 Only the main components closely related to one embodiment of the invention are shown.

[0203] Figure 5 The UE122 shown comprises a receiving unit 500 that receives RRC messages from a base station device, a processing unit 502 that processes configuration information based on any or all of the various information elements (IEs), fields, and conditions included in the received messages, and a transmitting unit 504 that sends RRC messages to the base station device. The base station device mentioned above sometimes refers to eNB102 and sometimes to gNB108. Furthermore, the processing unit 502 may include some or all of the functions of various layers (e.g., physical layer, MAC layer, RLC layer, PDCP layer, RRC layer, and NAS layer). That is, the processing unit 502 may include some or all of the physical layer processing unit, MAC layer processing unit, RLC layer processing unit, PDCP layer processing unit, RRC layer processing unit, and NAS layer processing unit.

[0204] Figure 6 This is a block diagram illustrating the configuration of a base station apparatus according to various embodiments of the present invention. It should be noted that, to avoid unnecessary detail, in... Figure 6Only the main components closely related to one embodiment of the invention are shown. The base station device described above sometimes refers to eNB102 and sometimes to gNB108.

[0205] Figure 6 The base station apparatus shown includes: a transmitting unit 600 that transmits RRC messages to UE 122; a processing unit 602 that generates RRC messages including configuration information such as various information elements, various fields, and various conditions, and transmits them to UE 122 for processing by the processing unit 502 of UE 122; and a receiving unit 604 that receives RRC messages from UE 122. Furthermore, the processing unit 602 may include some or all of the functions of various layers (e.g., physical layer, MAC layer, RLC layer, PDCP layer, RRC layer, and NAS layer). That is, the processing unit 602 may include some or all of the physical layer processing unit, MAC layer processing unit, RLC layer processing unit, PDCP layer processing unit, RRC layer processing unit, and NAS layer processing unit.

[0206] use Figures 9-11 This section provides a summary of the MBMS sending / receiving operations using SC-PTM. It should be noted that the terms MBMS, MBMS service, and MBMS session used in the following description are synonyms and can be used interchangeably.

[0207] Figure 9 This is a flowchart illustrating the setup process for MBMS reception using SC-PTM. Figure 10 It means Figure 9 The diagram shows an example of the ASN.1 description of the fields and / or information elements included in SIB20 (System Information Block Type 20). Furthermore, Figure 11 It means Figure 9 The diagram shows an example of an ASN.1 description of the fields and / or information elements included in the SC-PTM Configuration message.

[0208] like Figure 9 As shown, the processing unit 602 of eNB102 generates SIB20 (System Information Block type 20) as an RRC message and sends it from the sending unit 600 to UE122 via BCCH. The receiving unit 500 of UE122 receives SIB20. (Step S900)

[0209] As described in Non-Patent Document 4, SIB20 includes information required to acquire control information (specifically, SC-MCCH) related to the transmission of MBMS using SC-PTM. For example, SIB20 includes some or all of the following fields and / or information elements: a field represented by sc-mcch-ModificationPeriod indicating the period during which the content of SC-MCCH can be modified; a field represented by sc-mcch-RepetitionPeriod indicating the transmission (retransmission) time interval of SC-MCCH by the number of radio frames; a field represented by sc-mcch-Offset indicating the offset of the radio frame scheduling SC-MCCH; a field represented by sc-mcch-FirstSubframe indicating the subframe scheduling SC-MCCH; and a field represented by sc-mcch-duration indicating the duration of the subframe scheduling SC-MCCH.

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

[0211] (Step S902).

[0212] As described in Non-Patent Document 4, the SC-PTM configuration information includes control information applicable to MBMS reception. For example, the SC-PTM configuration information includes some or all of the fields and / or information elements, such as fields represented by sc-mtch-InfoList (which includes the configurations of each SC-MTCH in the cell that transmits the information) and fields represented by scptm-NeighbourCellList (which is a list of neighboring cells providing MBMS).

[0213] The sc-mtch-InfoList includes information elements represented by one or more SC-MTCH-Info objects. Each SC-MTCH-Info object includes some or all of the following fields: mbmsSessionInfo (information for MBMS sessions), g-RNTI (RNTI for Radio Network Temporary Identifier, identifying a multicast group; sc-mtch-schedulingInfo (DRX information for SC-MTCHs); and sc-mtch-neighbourCell (information for neighboring cells capable of receiving the MBMS session using the SC-MTCH). The mbmsSessionInfo object includes some or all of the following fields: tmgi (identifier for MBMS bearer services, TMGI, Temporary Mobile Group Identifier, as described in Non-Patent Document 15); and sessionId (identifier for MBMS sessions, as described in Non-Patent Document 15).

[0214] The processing unit 502 of UE122 can perform SC-MRB (Single Cell MBMS Point to Multipoint Radio Bearer) establishment processing as a radio bearer for receiving MBMS sessions using SC-PTM, for initiating reception of an interested MBMS session (step S904). The SC-MRB establishment processing can be initiated, for example, when the MBMS session begins, when UE122 enters a cell providing an interested MBMS service via SC-MRB, when interested in MBMS service, or when the restriction on UE capabilities suppressing MBMS service reception is removed. The SC-MRB establishment processing can also be performed when UE122 is in the RRC_IDLE state, or when UE122 is in the RRC_CONNECTED state. The processing unit 502 of UE122 can also perform some or all of the following processes (A) to (D) during the SC-MRB establishment processing.

[0215] (A) Create the RLC entity according to the default settings of SC-MCCH and SC-MTCH.

[0216] (B) Configure the SC-MTCH logical channel applied to the SC-MRB to be established, and instruct the MAC entity to receive the MBMS session according to the SC-PTM configuration message for the cell that receives the above-mentioned SC-PTM configuration message.

[0217] (C) For the SC-MRB to be established, set the physical layer based on the above sc-mtch-InfoList.

[0218] (D) The establishment of the SC-MRB is notified to the upper layer by notifying the tmgi and sessionId corresponding to the established SC-MRB.

[0219] The processing unit 502 of UE122 receives the MBMS session via the established SC-MRB according to the SC-PTM setting message described above (step S906). Alternatively, before receiving the MBMS session, the processing unit 502 of UE122 generates an MBMS Interest Indication message to notify eNB102 of its interest in receiving MBMS service via SC-MRB or its interest in receiving MBMS service, and sends it from the sending unit 504 to eNB102 (not shown). The MBMS Interest Indication message may also include information on whether MBMS service reception takes precedence over unicast reception. Furthermore, the MBMS Interest Indication message may be sent after receiving SIB20 and transitioning to the RRC_CONNECTED state, or after transitioning to the RRC_CONNECTED state. Additionally, the MBMS Interest Indication message may be sent if SIB20 is received during handover, or if SIB20 is received during the re-establishment of the RRC connection.

[0220] The processing unit 502 of UE122 can perform SC-MRB release processing to stop the reception of the MBMS session (step S908). SC-MRB release processing can be initiated, for example, when stopping a currently receiving MBMS session, when leaving a cell where SC-MRB has been established, when losing interest in MBMS service, or when MBMS service reception is suppressed due to limitations in UE capabilities. SC-MRB release processing can also be performed when UE122 is in the RRC_IDLE state, or when UE122 is in the RRC_CONNECTED state. When performing SC-MRB release processing, the processing unit 502 of UE122 can also perform some or all of the following processes (A) to (B).

[0221] (A) Release the RLC entity of the SC-MRB to be released and the associated MAC and physical layer settings.

[0222] (B) The release of the SC-MRB is communicated to the upper layer by notifying the tmgi and sessionId corresponding to the released SC-MRB.

[0223] The above provides a summary of the operation of setting up MBMS reception using SC-PTM. As described in Non-Patent Document 4, MBMS reception (hereinafter referred to as MBMS transmission / reception) from MBMS transmission / reception devices of base station equipment using SC-PTM has also been standardized for MBMS transmission / reception using MBSFN. However, in both MBMS transmission / reception using SC-PTM as described in Non-Patent Document 4 and MBMS transmission / reception using MBSFN, E-UTRA is used as the RAT. Multicast / broadcast Service (MBS) transmission / reception using NR as the RAT has not yet been standardized.

[0224] use Figures 12-13 An example of the operation for setting up MBS reception according to an embodiment of the present invention will be described. It should be noted that the terms MBS, MBS service, and MBS session used in the embodiments of the present invention may be terms with the same meaning and can be used interchangeably. Furthermore, the terms MBS, MBS service, and MBS session used in the embodiments of the present invention may also be terms with the same meaning as MBMS, MBMS service, and MBMS session described in Non-Patent Document 4, etc. Furthermore, in the embodiments of the present invention, MRB may also refer to the radio bearer established in UE122 for MBS reception. Furthermore, MRB may also refer to the radio bearer established in gNB108 for MBS transmission.

[0225] Figure 12 This is a diagram illustrating an example of the configuration of an SDAP sublayer representing an embodiment of the present invention. Figure 12 (A) is an example of RLC-SAP (RLC-Service Access Point) existing between the SDAP sublayer and the RLC sublayer. Figure 12 In example (A), the MBS session data received via the MRB in UE122 can be delivered to the SDAP entity as an RLC SDU within the aforementioned MRB's RLC entity. Furthermore, in Figure 12In example (A), it is also possible that in gNB108, the QoS flow of data associated with MBS session is established with the MRB in the SDAP entity of gNB108, and the data of the MBS session sent from the core network is submitted as SDAPPDU to the RLC entity that has established the corresponding MRB.

[0226] Figure 12 (B) is an example of PDCP-SAP (PDCP-Service Access Point) existing between the SDAP sublayer and the PDCP sublayer. Figure 12 In example (B), MBS session data received via the MRB in UE122 can be delivered from the MRB's RLC entity to the MRB's PDCP entity as an RLC SDU. The PDCP entity delivering the RLC SDU may not perform any processing on the delivered RLC SDU, i.e., the PDCP PDU, and deliver it as is to the SDAP entity as a PDCP SDU. Furthermore, in Figure 12 In example (B), it is also possible that, in gNB108, the QoS flow of data associated with the MBS session and the mapping between the MRB are established in the SDAP entity of gNB108, and the data of the MBS session sent from the core network is submitted as an SDAP PDU to the PDCP entity that has established the corresponding MRB. The PDCP entity that delivers the SDAP PDU may not perform any processing on the delivered SDAP PDU, i.e., PDCP SDU, and deliver it as is to the RLC entity of the MRB as a PDCP PDU. That is, in Figure 12 In example (B), the PDCP entity can also exist as a transparent entity without any processing. Furthermore, in Figure 12 In example (B), the PDCP entity can also exist as an entity that performs processing as part of a PDCP sublayer.

[0227] It should be noted that "association" can also be called "bundle" or other similar terms. Furthermore, "establishing a correspondence" can also be called "map" or other similar terms.

[0228] Here, the relationship between MRB, SDAP entities, and PDU sessions in embodiments of the present invention will be explained. One or more DRBs can be associated with an SDAP entity associated with the MRB. That is, the SDAP entity can be established and / or configured in common with MBS services and unicast services. Furthermore, a PDU session can correspond to both MBS services and unicast services, providing MBS services and / or unicast services. Additionally, a single SDAP entity common to both MBS services and unicast services can be established and / or configured for a PDU session. Furthermore, an SDAP entity associated with an MRB may not be associated with a DRB used for both MBS services and unicast services. Furthermore, a single SDAP entity for MBS services (for MRB) and a single SDAP entity for unicast services (for DRB) can be established and / or configured for a PDU session. Furthermore, a PDU session for MBS services can exist separately from a PDU session for unicast services. Furthermore, a single SDAP entity for MBS services can be established and / or configured for a PDU session for MBS services. Alternatively, SDAP entities may not be established and / or configured in the PDU session used for MBS services. Alternatively, at least one MRB and / or at least one DRB may be established in the PDU session. Furthermore, the establishment and / or configuration of the SDAP entity associated with the MRB establishment may occur when UE122 transitions from the RRC_IDLE state and / or RRC_INACTIVE state to the RRC_CONNECTED state. Additionally, the establishment and / or configuration of the SDAP entity associated with the MRB establishment may also occur when UE122 is in the RRC_INACTIVE state and / or RRC_CONNECTED state.

[0229] Figure 13 This is a diagram illustrating an example of the process for setting up MBS reception in NR according to an embodiment of the present invention. It should be noted that, in this embodiment, parameters may refer to fields and / or information elements in ASN.1.

[0230] like Figure 13As shown, the processing unit 602 of gNB108 can also generate a System Information Block (SIB) as one of the RRC messages, which is used to broadcast information required for obtaining control information related to MBS transmission, and sends it to UE122 through the sending unit 600. The receiving unit 500 of UE122 receives the aforementioned SIB. (Step S900) It should be noted that the aforementioned SIB can also be sent via the BCCH logical channel. In addition, the information required for obtaining control information related to MBS transmission can also refer to information related to the MCCH (Multicast Control Channel) logical channel. The aforementioned MCCH can refer to a point-to-multipoint downlink channel used to send MBS control information for one or more MTCH (Multicast Traffic Channel) logical channels from gNB108 to UE122. In addition, the aforementioned MTCH can refer to a point-to-multipoint downlink channel used to send MBS data from gNB108 to UE122. The aforementioned MTCH can also be used by UE122 only when UE122 receives MBMS. It should be noted that the MCCH mentioned above can also be called MBS-MCCH, NR-MCCH, or other names. Similarly, the MTCH mentioned above can also be called MBS-MTCH, NR-MTCH, or other names. Furthermore, MBS transmission can also be performed via MRB. Additionally, the MCCH mentioned above can be mapped to the MCH (Multicast Channel) as a downlink transmission channel, and it can also be mapped to the DL-SCH (Downlink Shared Channel) as a downlink transmission channel. Likewise, the MTCH mentioned above can be mapped to the MCH (Multicast Channel) as a downlink transmission channel, and it can also be mapped to the DL-SCH (Downlink Shared Channel) as a downlink transmission channel.

[0231] The aforementioned SIB may include, for example, some or all of the following parameters: parameters indicating the period during which the MCCH content can be modified; parameters related to the MCCH transmission (retransmission) time interval; parameters indicating the offset of the radio frame scheduling the MCCH; parameters indicating the subframes scheduling the MCCH; and parameters indicating the period of the subframes scheduling the MCCH. It should be noted that the aforementioned parameters related to the MCCH transmission (retransmission) time interval can also be represented by the number of radio frames.

[0232] Next, the processing unit of gNB108 can generate the RRC message to be transmitted in the MCCH and transmit it through the transmitting unit 600. The receiving unit 500 of UE122 can receive the RRC message transmitted in the MCCH based on the SIB settings. A dedicated RNTI (Radio Network Temporary Identifier) ​​for identifying the MCCH transmission can be used in the transmission of the MCCH (step S1302). In the embodiment of the present invention, the message name MBS setting information message is used to describe the RRC message transmitted in the MCCH, but other message names may also be used.

[0233] The MBS configuration information described above may include control information applicable to MBS reception. For example, the MBS configuration information may include some or all of the following fields: parameters related to MBS session information, parameters representing the RNTI indicating the identification of a multicast group (MTCH with a specific group as the destination), parameters related to DRX information used for the MTCH, and parameters representing a list of neighboring cells providing the same MBS. The parameters related to the MBS session information described above may include, for example, some or all of the following parameters: parameters representing the TMGI (Temporary Mobile Group Identity) as an identifier for the MBS (or MBMS) bearer service as described in Non-Patent Document 15; parameters representing the Session ID as an identifier for the MBS (or MBMS) session as described in Non-Patent Document 15, parameters representing the PDU session to which the MBS (or MBMS) bearer service and / or the MBS session belong; and parameters representing the QoS flow used for the MBS (or MBMS) bearer service and / or the MBS session.

[0234] It should be noted that a list may include some or all of the parameters included in the MBS configuration information described above. The parameters included in the list may exist relative to each MTCH (or each MBS service) in the cell where the MCCH is transmitted. Furthermore, the parameter representing the list of neighboring cells providing the same MBS may include parameters representing the list of neighboring cells providing the same MBS via MTCH and / or MRB, or parameters representing the list of neighboring cells providing the same MBS via unicast and / or DTCH and / or DRB. Furthermore, the parameter representing a PDU session may refer to the PDU session ID described in Non-Patent Document 2, etc. Furthermore, the parameters representing a PDU session and / or QoS flow may be included in the parameters representing SDAP settings.

[0235] The processing unit 502 of UE122 can perform MRB establishment processing to begin receiving an MBS session of interest (step S1304). MRB establishment processing can be initiated, for example, when the MBS session begins, when UE122 enters a cell providing an MBS service of interest via MRB, when it becomes interested in MBS services, or when restrictions on UE capabilities that inhibit MBS service reception are removed. MRB establishment processing can be performed when UE122 is in RRC_IDLE state, RRC_INACTIVE state, or RRC_CONNECTED state. The processing unit 502 of UE122 can also perform some or all of the following processes (A) to (G) during MRB establishment processing. It should be noted that process (A) can be performed when UE122 is in RRC_CONNECTED state and / or RRC_INACTIVE state. It should be noted that the (F) process can be performed when UE122 is in the RRC_CONNECTED state, or when UE122 is in the RRC_CONNECTED state and / or the RRC_INACTIVE state. Furthermore, the (F) process can also be performed when UE122 transitions from the RRC_IDLE state and / or the RRC_INACTIVE state to the RRC_CONNECTED state.

[0236] (A) If there is no SDAP entity in the PDU session that corresponds to the parameters of the PDU session included in the MBS settings, create and / or set up the SDAP entity.

[0237] (B) Create the PDCP entity according to the default settings related to MRB creation.

[0238] (C) Create the RLC entity according to the default settings related to MRB creation.

[0239] (D) Configure the MTCH logical channel to be used for the MRB to be established, and instruct the MAC entity to receive the MBS session to be received.

[0240] (E) For the MRB to be established, the physical layer is configured based on the received MBS settings.

[0241] (F) Associate the SDAP entity with the established MRB.

[0242] (G) The establishment of the MRB is communicated to the upper layer by notifying the upper layer of some or all of the information in the TMGI, session ID, PDU session ID, and QoS flow corresponding to the established MRB.

[0243] The processing unit 502 of UE122 receives the MBS session via the established MRB according to the PTM setting message described above (step S1306). Alternatively, before receiving the MBS session, the processing unit 502 of UE122 generates an RRC message to notify gNB108 of receiving MBS service via MRB or of interest in receiving MBS service, and sends it to eNB102 (not shown) via the sending unit 504. It should be noted that in the embodiment of the present invention, the message name MBS InterestIndication is used to describe the RRC message for notifying gNB108 of receiving MBS service via MRB or of interest in receiving MBS service, but other message names may also be used. The MBS InterestIndication message may also include information on whether MBS service reception takes precedence over other unicast receptions. In addition, the MBS interest notification message may also include the following information: whether the same MBS service can be received via DTCH and / or DRB if the MBS service cannot be received from a cell that can receive MBS service via MTCH and / or MRB, but the same MBS service can be received via DTCH and / or DRB upon moving to a cell that can receive the same MBS service via DTCH and / or DRB. Furthermore, the MBS interest notification message may also be sent after receiving the SIB described in step S1300, upon transitioning to the RRC_CONNECTED state, or after transitioning to the RRC_CONNECTED state. Furthermore, the MBS interest notification message may be sent if the SIB described in step S1300 is received during handover, upon receiving the SIB described in step S1300 during the re-establishment of the RRC connection, or upon receiving the SIB described in step S1300 during the transition from the RRC_INACTIVE state to the RRC_CONNECTED state.

[0244] The processing unit 502 of UE122 can also perform MRB release processing to stop the reception of the MBMS session (step S1308). MRB release processing can be initiated, for example, when stopping a currently receiving MBS session, when leaving a cell with an established MRB, when leaving a cell capable of receiving MBS services using MRB, when losing interest in MBS services, or when suppressing MBS service reception due to limitations on UE capabilities. MRB release processing can be performed when UE122 is in the RRC_IDLE state, when UE122 is in the RRC_INACTIVE state, or when UE122 is in the RRC_CONNECTED state. The processing unit 502 of UE122 can also perform some or all of the following processes (A) to (D) during MRB release processing. It should be noted that process (D) below can be performed only when UE122 is in the RRC_CONNECTED state and / or the RRC_INACTIVE state.

[0245] (A) Release the PDCP entity of the MRB to be released.

[0246] (B) Release the RLC entity of the MRB to be released and the associated MAC and physical layer settings.

[0247] (C) The release of the MRB is communicated to the upper layer by notifying the upper layer of some or all of the information in the TMGI, session ID, PDU session ID, and QoS stream corresponding to the released MRB.

[0248] (D) For SDAP entities that do not have associated MRBs and / or DRBs, release the SDAP entity.

[0249] It should be noted that, in the embodiments of the present invention, when UE122 receives a message related to the resetting of the RRC connection and establishes a DRB, that is, when the DRB identifier included in the message related to the resetting of the RRC connection does not exist in the settings of UE122, the processing unit 502 of UE122 notifies the upper layer that user plane resources for the PDU session have been established, based on the existence of an SDAP entity for the PDU session corresponding to the field shown in the pdu-session included in the message related to the resetting of the RRC connection, and the established or to be established DRB is the first DRB for the SDAP entity and / or the PDU session. It should be noted that the above-mentioned situation of "in the case of the existence of an SDAP entity for the PDU session corresponding to the field shown in pdu-session, and the established or to be established DRB is the first DRB for the above-mentioned SDAP entity and / or the above-mentioned PDU session" can refer to the case where the above-mentioned SDAP entity is the SDAP entity established when the MRB is established, and the case where the first DRB for the above-mentioned SDAP entity and / or the above-mentioned PDU session is to be established or has already been established.

[0250] Furthermore, in an embodiment of the present invention, after the UE122 receives a message related to the reconfiguration of the RRC connection and performs processing related to the configuration of the radio bearer, it may notify the upper layer that the user plane resources of the aforementioned SDAP entity that does not have an associated DRB are released, based on the existence of such SDAP entities in the SDAP entity database. Alternatively, in an embodiment of the present invention, after the UE122 receives a message related to the reconfiguration of the RRC connection and performs processing related to the configuration of the radio bearer, it may release the aforementioned SDAP entity that does not have an associated DRB and / or MRB, based on the existence of such SDAP entities in the SDAP entity database.

[0251] Thus, in the embodiments of the present invention, UE122 can efficiently receive MBS using NR.

[0252] The radio bearers mentioned above can be DRB, SRB, or both DRB and SRB.

[0253] Furthermore, in the above explanation, expressions such as "related", "establish correspondence", and "establish association" can be used interchangeably.

[0254] Furthermore, in the examples of processes or processes described above, some or all of the steps may not be performed. Furthermore, the order of the steps may differ in the examples of processes or processes described above. Furthermore, in the examples of processes or processes described above, some or all of the processes in each step may not be performed. Furthermore, the order of the processes in each step may differ in the examples of processes or processes described above. Furthermore, in the above description, "perform B based on A" may also be changed to "perform B". That is, "perform B" may also be performed independently of "is A".

[0255] It should be noted that, in the above explanation, "A can be renamed B" includes not only renaming A to B, but also renaming B to A. Furthermore, in the above explanation, when "C can be D" and "C can be E" are stated, it can include the case where "D can be E". Additionally, in the above explanation, when "F can be G" and "G can be H" are stated, it can include the case where "F can be H".

[0256] Furthermore, in the above explanation, when condition "A" is the opposite of condition "B", condition "B" can be expressed as an "other" condition of condition "A".

[0257] Hereinafter, various embodiments of the terminal device according to the present invention will be described.

[0258] (1) One embodiment of the present invention is a terminal device that communicates with a base station device. The terminal device includes: a receiving unit that receives an RRC message including multicast / broadcast service (MBS) configuration information from the base station device; and a processing unit that includes MBS session information and PDU session information in the MBS configuration information. The processing unit performs the following processing: based on the terminal device stopping the reception of the MBS session, releasing the MBS radio bearer used for receiving the MBS session, and notifying an upper layer of part or all of the MBS session information.

[0259] (2) The terminal device according to (1), wherein the MBS is associated with the SDAP entity by a radio bearer and sets the SDAP entity for the PDU session.

[0260] (3) According to the terminal device described in (2), wherein the processing unit of the terminal device further releases the SDAP entity in the absence of a radio bearer associated with the SDAP entity, based on the fact that the terminal device stops receiving the MBS session.

[0261] (4) The terminal device according to (1) or (2) or (3), wherein the release of the MBS radio bearer includes a part or all of the release of the PDCP entity of the MBS radio bearer, the release of the RLC entity, the release of the logical channel setting, and the release of the physical layer.

[0262] (5) A method for a terminal device to communicate with a base station device, wherein the terminal device receives an RRC message including configuration information of a multicast / broadcast service (MBS), the configuration information of the MBS including MBS session information, the MBS session information including PDU session information, the terminal device stops receiving the MBS session, releases the MBS wireless bearer used for receiving the MBS session, and notifies an upper layer of a portion or all of the MBS session information.

[0263] (6) According to the method of (5), wherein the MBS is associated with the SDAP entity by a radio bearer and the SDAP entity is configured for the PDU session.

[0264] (7) According to the method of (6), wherein the processing unit further releases the SDAP entity in the absence of a radio bearer associated with the SDAP entity, based on the terminal device stopping the reception of the MBS session.

[0265] (8) The method according to (5) or (6) or (7), wherein the release of the MBS radio bearer includes a part or all of the release of the PDCP entity of the MBS radio bearer, the release of the RLC entity, the release of the logical channel setting, and the release of the physical layer.

[0266] In one embodiment of the present invention, the program operating in the apparatus may be a program that controls the Central Processing Unit (CPU) or similar components to achieve the functions described in the above-described embodiments of the present invention, thereby enabling the computer to perform its functions. During processing, the program or the information processed by the program is temporarily read into volatile memory such as Random Access Memory (RAM) or stored in non-volatile memory such as Flash Memory or Hard Disk Drive (HDD), and is read, modified, or written by the CPU as needed.

[0267] It should be noted that a portion of the device described in the above embodiments can be implemented using a computer. In this case, the program for implementing the control function can be recorded on a computer-readable recording medium, and the control function can be implemented by reading the program recorded on the recording medium into a computer system and executing it. Here, "computer system" refers to a computer system built into the device, and is configured to include hardware such as an operating system and peripherals. Furthermore, the "computer-readable recording medium" can be any of a semiconductor recording medium, an optical recording medium, a magnetic recording medium, etc.

[0268] Furthermore, a "computer-readable recording medium" can include: a medium that dynamically stores a program for a short period of time, such as a communication line in the case of transmitting a program via a network such as the Internet or a communication line such as a telephone line; or a medium that stores a program for a fixed period of time, such as volatile memory within a computer system that serves as a server or client in this case. In addition, the program can be a program used to implement the functions described above, or it can be a program that can implement the functions described above by combining with programs already recorded in the computer system.

[0269] Furthermore, the functional blocks or features of the apparatus used in the above embodiments can be implemented or executed by circuits, typically by integrated circuits or multiple integrated circuits. Circuits designed to perform the functions described in this specification may include: general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic elements, discrete gate or transistor logic, discrete hardware components, or combinations thereof. A general-purpose processor may be a microprocessor, or alternatively, a conventional processor, controller, microcontroller, or state machine. The general-purpose processor or the circuits described above may be constructed from digital circuits or analog circuits. Furthermore, in cases where advancements in semiconductor technology have led to the development of integrated circuit technologies that replace existing integrated circuits, integrated circuits based on such technologies may also be used.

[0270] It should be noted that the invention described in this application is not limited to the embodiments described above. While one example of the device is described in the embodiments, the invention is not limited thereto and can be applied to fixed or non-movable electronic devices installed indoors or outdoors, such as AV equipment, kitchen equipment, cleaning / washing equipment, air conditioning equipment, office equipment, vending machines, and other terminal devices or communication devices in daily life.

[0271] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the specific configuration is not limited to these embodiments, and design changes that do not depart from the spirit of the present invention are also included. Furthermore, various modifications can be made to one aspect of the present invention within the scope shown in the technical solution. Embodiments obtained by appropriately combining the technical means disclosed in different embodiments are also included within the technical scope of the present invention. In addition, configurations obtained by replacing elements that have the same effect as those described in the above embodiments are also included.

[0272] Industrial availability

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

[0274] Explanation of reference numerals in the attached figures

[0275] 100 E-UTRA

[0276] 102 eNB

[0277] 104 EPC

[0278] 106 NR

[0279] 108 gNB

[0280] 110 5GC

[0281] Interfaces 112, 114, 116, 118, 120, and 124

[0282] 122 UE

[0283] 200, 300 PHY

[0284] 202, 302 MAC

[0285] 204, 304 RLC

[0286] 206, 306 PDCP

[0287] 208, 308 RRC

[0288] 310 SDAP

[0289] 210, 312 NAS

[0290] Receiving Departments 500 and 604

[0291] 502 and 602 processing departments

[0292] 504, 600 Sending Department

Claims

1. A terminal device for communicating with a base station device, the terminal device comprising: The receiving unit receives an RRC message from the base station device, including configuration information for the Multicast Broadcast Service (MBS); and Processing department, in which The MBS configuration information includes MBS session information. The processing unit: When the MRB used to receive the MBS session is released, the SDAP associated with the MRB is released if the SDAP entity has no associated MRB.

2. A method for a terminal device to communicate with a base station device, the method comprising: The base station device receives an RRC message including configuration information for the Multicast Broadcast Service (MBS), wherein... The MBS configuration information includes MBS session information. When the MRB used to receive the MBS session is released, the SDAP associated with the MRB is released if the SDAP entity has no associated MRB.

Images