Communication control method, user device, processor, and program

Abstract

In NR (New Radio) multicast and broadcast services, we will provide improved services compared to LTE (Long Term Evolution) multicast and broadcast services. [Solution] A communication control method used in a mobile communication system that provides multicast broadcast service (MBS) from a base station to user equipment, wherein the base station maps one or more QoS (Quality of Service) flows belonging to one MBS session to multiple MBS data bearers, and the base station sets one RNTI (Radio Network Temporary Identifier) ​​for multiple logical channels corresponding to multiple MBS data bearers.

Description

Technical Field

[0001] The present invention relates to a communication control method used in a mobile communication system.

Background Art

[0002] In recent years, the fifth-generation (5G) mobile communication system has attracted attention. NR (New Radio), which is a radio access technology (RAT) of the 5G system, has characteristics such as high speed, large capacity, high reliability, and low latency compared to LTE (Long Term Evolution), which is a fourth-generation radio access technology.

Prior Art Documents

Non-Patent Documents

[0003]

Non-Patent Document 1

Summary of the Invention

[0004] A communication control method according to a first aspect is a communication control method used in a mobile communication system that provides a multicast / broadcast service (MBS) from a base station to a user device, the base station performing a header compression process that omits transmission of header information, which is static information included in the header of an MBS packet, and transmitting a compressed MBS packet on which the header compression process has been performed, and after starting transmission of the compressed MBS packet, the base station transmitting the header information separately from the compressed MBS packet.

[0005] A second aspect of the communication control method is a communication control method used in a mobile communication system that provides multicast broadcast service (MBS) from a base station to a user device, comprising: the user device receiving an MBS packet from the base station; and the PDCP (Packet Data Convergence Protocol) entity of the user device setting the PDCP sequence number included in the first MBS packet received from the base station as the initial value of a variable used for a predetermined PDCP operation.

[0006] A third aspect of the communication control method is a communication control method used in a mobile communication system that provides multicast broadcast service (MBS) from a base station to a user device, comprising: the user device receiving an MBS packet from the base station via an MBS data bearer; and the Service Data Adaptation Protocol (SDAP) layer of the user device assuming that the MBS packet does not have an SDAP header, and passing the MBS packet to a higher layer without performing SDAP header removal processing on the MBS packet.

[0007] A fourth aspect of the communication control method is a communication control method used in a mobile communication system that provides multicast broadcast service (MBS) from a base station to user equipment, comprising: the base station mapping one or more Quality of Service (QoS) flows belonging to one MBS session to a plurality of MBS data bearers; and the base station multiplexing and transmitting a plurality of logical channels corresponding to the plurality of MBS data bearers using a single Radio Network Temporary Identifier (RNTI). [Brief explanation of the drawing]

[0008] [Figure 1] This figure shows the configuration of a mobile communication system according to one embodiment. [Figure 2]This diagram shows the configuration of a UE (User Equipment) according to one embodiment. [Figure 3] This diagram shows the configuration of a gNB (base station) according to one embodiment. [Figure 4] This diagram shows the protocol stack configuration of the user plane wireless interface that handles data. [Figure 5] This diagram shows the protocol stack configuration of the wireless interface of the control plane that handles signaling (control signals). [Figure 6] This figure shows the correspondence between the logical channel and the transport channel of a downlink according to one embodiment. [Figure 7] This figure shows a method for distributing MBS data according to one embodiment. [Figure 8] This figure shows the layer 2 structure of the gNB in ​​a downlink according to one embodiment. [Figure 9] This figure shows an example of the operation of a mobile communication system related to header compression processing according to one embodiment. [Figure 10] This figure shows another example of operation of a mobile communication system related to header compression processing according to one embodiment. [Figure 11] This figure shows an example of the operation of a mobile communication system with respect to PDCP variables according to one embodiment. [Figure 12] This figure shows the data flow in a gNB and UE according to one embodiment. [Figure 13] This figure shows an example of multiplex transmission operation across multiple logical channels according to one embodiment. [Modes for carrying out the invention]

[0009] The introduction of multicast broadcast services into 5G systems (NR) is being considered. It is desirable that NR multicast broadcast services provide improved service compared to LTE multicast broadcast services.

[0010] Therefore, the present invention aims to realize an improved multicast broadcast service.

[0011] A mobile communication system according to an embodiment will be described with reference to the drawings. In the drawings, identical or similar parts are denoted by the same or similar reference numerals.

[0012] (Configuration of mobile communication systems) First, the configuration of the mobile communication system according to the embodiment will be described. Figure 1 is a diagram showing the configuration of a mobile communication system according to one embodiment. This mobile communication system conforms to the 5th Generation System (5GS) of the 3GPP® standard. In the following description, 5GS will be used as an example, but the mobile communication system may also have an LTE (Long Term Evolution) system applied to it, or a 6th Generation (6G) system applied to it, at least partially.

[0013] As shown in Figure 1, the mobile communication system includes User Equipment (UE) 100, a 5G Next Generation Radio Access Network (NG-RAN) 10, and a 5G Core Network (5GC) 20.

[0014] UE100 is a mobile wireless communication device. UE100 can be any device used by a user, but examples include mobile phone terminals (including smartphones), tablet terminals, notebook PCs, communication modules (including communication cards or chipsets), sensors or devices attached to sensors, vehicles or devices attached to vehicles (Vehicle UE), and aircraft or devices attached to aircraft (Aerial UE).

[0015] NG-RAN 10 includes base stations (referred to as "gNB" in the 5G system) 200. The gNBs 200 are interconnected via the Xn interface, which is an interface between base stations. The gNB 200 manages one or more cells. The gNB 200 performs wireless communication with the UE 100 that has established a connection with its cell. The gNB 200 has a radio resource management (RRM) function, a routing function for user data (hereinafter simply referred to as "data"), a measurement control function for mobility control and scheduling, etc. "Cell" is used as a term indicating the smallest unit of a wireless communication area. "Cell" is also used as a term indicating a function or resource for performing wireless communication with the UE 100. One cell belongs to one carrier frequency.

[0016] Note that the gNB can also be connected to the EPC (Evolved Packet Core), which is the core network of LTE. The base station of LTE can also be connected to the 5GC. The base station of LTE and the gNB can also be connected via an interface between base stations.

[0017] The 5GC 20 includes an AMF (Access and Mobility Management Function) and a UPF (User Plane Function) 300. The AMF performs various mobility controls for the UE 100, etc. The AMF manages the mobility of the UE 100 by communicating with the UE 100 using NAS (Non-Access Stratum) signaling. The UPF performs transfer control of data. The AMF and the UPF are connected to the gNB 200 via the NG interface, which is an interface between the base station and the core network.

[0018] FIG. 2 is a diagram showing the configuration of a UE 100 (user equipment) according to an embodiment.

[0019] As shown in FIG. 2, the UE 100 includes a receiving unit 110, a transmitting unit 120, and a control unit 130.

[0020] The receiving unit 110 performs various types of reception under the control of the control unit 130. The receiving unit 110 includes an antenna and a receiver. The receiver converts the radio signal received by the antenna into a baseband signal (received signal) and outputs it to the control unit 130.

[0021] The transmitting unit 120 performs various types of transmissions under the control of the control unit 130. The transmitting unit 120 includes an antenna and a transmitter. The transmitter converts the baseband signal (transmission signal) output by the control unit 130 into a wireless signal and transmits it from the antenna.

[0022] The control unit 130 performs various controls on the UE100. The control unit 130 includes at least one processor and at least one memory. The memory stores programs executed by the processor and information used for processing by the processor. The processor may include a baseband processor and a CPU (Central Processing Unit). The baseband processor performs modulation, demodulation, encoding, and decoding of baseband signals. The CPU executes programs stored in memory and performs various processing.

[0023] Figure 3 shows the configuration of a gNB200 (base station) according to one embodiment.

[0024] As shown in Figure 3, the gNB200 comprises a transmitting unit 210, a receiving unit 220, a control unit 230, and a backhaul communication unit 240.

[0025] The transmitting unit 210 performs various types of transmissions under the control of the control unit 230. The transmitting unit 210 includes an antenna and a transmitter. The transmitter converts the baseband signal (transmission signal) output by the control unit 230 into a radio signal and transmits it from the antenna.

[0026] The receiving unit 220 performs various types of reception under the control of the control unit 230. The receiving unit 220 includes an antenna and a receiver. The receiver converts the radio signal received by the antenna into a baseband signal (received signal) and outputs it to the control unit 230.

[0027] The control unit 230 performs various controls in the gNB200. The control unit 230 includes at least one processor and at least one memory. The memory stores programs executed by the processor and information used for processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation, demodulation, encoding, and decoding of baseband signals. The CPU executes programs stored in memory and performs various processing.

[0028] The backhaul communication unit 240 is connected to an adjacent base station via an inter-base station interface. The backhaul communication unit 240 is connected to the AMF / UPF300 via a base station-core network interface. The gNB may consist of a CU (Central Unit) and a DU (Distributed Unit) (i.e., functionally separated), and the two units may be connected via an F1 interface.

[0029] Figure 4 shows the configuration of the protocol stack for the user plane's wireless interface that handles data.

[0030] As shown in Figure 4, the user plane radio interface protocol has a physical (PHY) layer, a MAC (Medium Access Control) layer, an RLC (Radio Link Control) layer, a PDCP (Packet Data Convergence Protocol) layer, and an SDAP (Service Data Adaptation Protocol) layer.

[0031] The PHY layer performs encoding / decoding, modulation / demodulation, antenna mapping / demapping, and resource mapping / demapping. Data and control information are transmitted between the UE100's PHY layer and the gNB200's PHY layer via a physical channel.

[0032] The MAC layer performs data priority control, retransmission processing using Hybrid ARQ (HARQ), and random access procedures. Data and control information are transmitted between the MAC layer of the UE100 and the MAC layer of the gNB200 via the transport channel. The MAC layer of the gNB200 includes a scheduler. The scheduler determines the transport format for the up and down links (transport block size, modulation and coding scheme (MCS)) and the resource blocks to be allocated to the UE100.

[0033] The RLC layer transmits data to the receiving RLC layer using the functions of the MAC layer and PHY layer. Data and control information are transmitted between the UE100's RLC layer and the gNB200's RLC layer via a logical channel.

[0034] The PDCP layer performs header compression / decompression, and encryption / decryption.

[0035] The SDAP layer maps IP flows, which are the units under which the core network performs QoS (Quality of Service) control, to wireless bearers, which are the units under which the AS (Access Stratum) performs QoS control. Note that if the RAN is connected to the EPC, the SDAP is not required.

[0036] Figure 5 shows the configuration of the protocol stack of the wireless interface of the control plane that handles signaling (control signals).

[0037] As shown in Figure 5, the protocol stack of the control plane's wireless interface has an RRC (Radio Resource Control) layer and a NAS (Non-Access Stratum) layer instead of the SDAP layer shown in Figure 4.

[0038] RRC signaling for various settings is transmitted between the RRC layer of the UE100 and the RRC layer of the gNB200. The RRC layer controls the logical channel, transport channel, and physical channel in response to the establishment, re-establishment, and release of the radio bearer. If there is a connection (RRC connection) between the RRC of the UE100 and the RRC of the gNB200, the UE100 is in the RRC connected state. If there is no connection (RRC connection) between the RRC of the UE100 and the RRC of the gNB200, the UE100 is in the RRC idle state. If the connection between the RRC of the UE100 and the RRC of the gNB200 is suspended, the UE100 is in the RRC inactive state.

[0039] The NAS layer, located above the RRC layer, handles session management and mobility management, among other things. NAS signaling is transmitted between the UE100's NAS layer and the AMF300B's NAS layer.

[0040] In addition to the wireless interface protocol, the UE100 also has an application layer and other components.

[0041] (MBS) Next, an MBS according to one embodiment will be described. MBS is a service that transmits data from NG-RAN10 to UE100 via broadcast or multicast, i.e., one-to-many (PTM: Point To Multipoint). MBS may also be called MBMS (Multimedia Broadcast and Multicast Service). Use cases (service types) of MBS include public security communications, mission-critical communications, V2X (Vehicle to Everything) communications, IPv4 or IPv6 multicast distribution, IPTV, group communications, and software distribution.

[0042] There are two types of MBS transmission methods in LTE: MBSFN (Multicast Broadcast Single Frequency Network) transmission and SC-PTM (Single Cell Point To Multipoint) transmission. Figure 6 shows the correspondence between the logical channel and the transport channel of a downlink according to one embodiment.

[0043] As shown in Figure 6, the logical channels used for MBSFN transmission are MTCH (Multicast Traffic Channel) and MCCH (Multicast Control Channel), and the transport channel used for MBSFN transmission is MCH (Multicast Control Channel). MBSFN transmission is primarily designed for multi-cell transmission, and in an MBSFN area consisting of multiple cells, each cell synchronously transmits the same signal (same data) using the same MBSFN subframe.

[0044] The logical channels used for SC-PTM transmission are SC-MTCH (Single Cell Multicast Traffic Channel) and SC-MCCH (Single Cell Multicast Control Channel), and the transport channel used for SC-PTM transmission is DL-SCH (Downlink Shared Channel). SC-PTM transmission is primarily designed for single-cell transmission, performing broadcast or multicast data transmission on a cell-by-cell basis. The physical channels used for SC-PTM transmission are PDCCH (Physical Downlink Control Channel) and PDSCH (Physical Downlink Shared Channel), enabling dynamic resource allocation.

[0045] The following primarily describes an example of MBS being provided using the SC-PTM transmission method, but MBS may also be provided using the MBSFN transmission method. Furthermore, the description will primarily describe an example of MBS being provided via multicast. Therefore, MBS may be interpreted as multicast. However, MBS may also be provided via broadcast.

[0046] Furthermore, MBS data refers to data transmitted by MBS, the MBS control channel refers to MCCH or SC-MCCH, and the MBS traffic channel refers to MTCH or SC-MTCH. However, MBS data may also be transmitted by unicast. MBS data may also be called MBS packets or MBS traffic.

[0047] The network can provide different MBS services for each MBS session. An MBS session is identified by at least one of the following: TMGI (Temporary Mobile Group Identity) and a session identifier, and at least one of these identifiers is called the MBS session identifier. Such an MBS session identifier may also be called an MBS service identifier or a multicast group identifier.

[0048] Figure 7 shows a method for distributing MBS data according to one embodiment.

[0049] As shown in Figure 7, MBS data (MBS Traffic) is delivered from a single data source (application service provider) to multiple UEs. The 5G core network, 5G CN (5GC)20, receives MBS data from the application service provider, creates copies of the MBS data (replication), and delivers them.

[0050] From the perspective of 5GC20, two delivery methods are possible: Shared MBS Traffic delivery and Individual MBS Traffic delivery.

[0051] In shared MBS data distribution, a connection is established between NG-RAN10, a 5G wireless access network (5G RAN), and 5GC20, and MBS data is distributed from 5GC20 to NG-RAN10. Hereafter, this connection (tunnel) will be referred to as the "MBS connection".

[0052] The MBS connection may also be called a Shared MBS Traffic Delivery connection or a shared transport. The MBS connection terminates at NG-RAN10 (i.e., gNB200). The MBS connection may have a one-to-one correspondence with an MBS session. The gNB200 decides whether to use PTP (Point-to-Point: unicast) or PTM (Point-to-Multipoint: multicast or broadcast) and sends the MBS data to the UE100 using the selected method.

[0053] On the other hand, in individual MBS data distribution, a unicast session is established between NG-RAN10 and UE100, and MBS data is individually distributed from 5GC20 to UE100. Such a unicast may also be called a PDU session. The unicast (PDU session) terminates at UE100.

[0054] In the following embodiment, we will mainly describe an example in which the gNB200 performs MBS transmission of PTM.

[0055] (Header compression process) Next, a header compression process according to one embodiment will be described.

[0056] Figure 8 shows the layer 2 structure of the gNB200 in a downlink according to one embodiment.

[0057] As shown in Figure 8, the physical layer provides transport channels to the MAC layer. The MAC layer provides logical channels to the RLC layer. The RLC layer provides RLC channels to the PDCP layer. The PDCP layer provides radio bearers to the SDAP layer. The SDAP layer provides QoS flows.

[0058] Here, logical channels and RLC channels have a one-to-one correspondence, and RLC channels and wireless bearers also have a one-to-one correspondence; therefore, logical channels and wireless bearers also have a one-to-one correspondence. In contrast, QoS flows and wireless bearers do not have a one-to-one correspondence. For this reason, the SDAP layer performs a process to associate (map) QoS flows with wireless bearers.

[0059] The PDCP layer has a PDCP entity provided for each wireless bearer. Each PDCP entity has the function of performing processing using RoHC (Robust Header Compression). Below, an example of using RoHC as the header compression protocol is described, but other protocols, such as EHC (Ethernet Header Compression), may also be used. The RoHC function performs IP header compression processing (hereinafter simply referred to as "header compression processing"). The data to which RoHC applies is user data flowing on the data wireless bearer. Headers that can be compressed by RoHC include, for example, RTP, UDP, TCP, and IP headers.

[0060] In the downlink, the RoHC function of the gNB200's PDCP layer (hereinafter referred to as the "gNB-side RoHC function") performs RoHC-based header compression before encryption (ciphering). On the other hand, the RoHC function of the UE100's PDCP layer (hereinafter referred to as the "UE-side RoHC function") performs RoHC-based header decompression (header restoration) after deciphering.

[0061] The gNB-side RoHC function transitions through states in the following order, for example: IR (Initialization and Refresh) state, FO (First Order) state, and SO (Second Order) state. In the IR state, the gNB-side RoHC function does not compress (i.e., omit transmission of) the header information to be compressed, and sends all header information to the UE-side RoHC function.

[0062] In FO (Forwarded) mode, most of the static fields (parameters that hardly change per packet) in the header information subject to RoHC compression are compressed. Some static fields and dynamic fields (parameters that change per packet) are sent to the UE-side RoHC function without compression.

[0063] In the SO state, the header compression ratio is at its highest. By sending only the RTP sequence number from the gNB's RoHC function, the UE's RoHC function can restore the target header.

[0064] On the other hand, the UE-side RoHC function transitions through states in the following order, for example: NC (No Context) state, SC (Static Context) state, and FC (Full Context) state. The initial state of the UE-side RoHC function is the NC state, where the information necessary for header decompression (header decompression context) is missing, and the decompression process cannot be performed correctly. When the UE-side RoHC function receives the header decompression context, it transitions to the FC state. Subsequently, it will transition to the SC state and then the NC state in response to successive header decompression failures.

[0065] Applying RoHC-based header compression to PTM transmission of MBS packets can reduce header overhead. However, RoHC is primarily a header compression protocol designed for unicast, and the following problems may arise.

[0066] A UE100 that joined an MBS session from the beginning can receive uncompressed MBS packets from the gNB200 that have not undergone header compression, retrieve header information from the uncompressed MBS packets, and hold the information necessary for header decompression (header decompression context).

[0067] On the other hand, UE100, which joins an MBS session midway, cannot receive uncompressed MBS packets from gNB200 that have not undergone header compression. Therefore, it cannot retain the information necessary for header decompression (header decompression context), and thus cannot restore the target header. Consequently, UE100, which joins an MBS session midway, has the problem of not being able to properly process the reception of MBS packets.

[0068] In one embodiment, the following method enables a UE100 that joins an MBS session midway through to successfully process MBS packets.

[0069] In one embodiment, the gNB200 performs header compression, which omits the transmission of header information, which is static information included in the header of the MBS packet, and then transmits the compressed MBS packet. After starting to transmit the compressed MBS packet, the gNB200 transmits the header information separately from the compressed MBS packet.

[0070] As a result, UE100, which joins an MBS session midway, can retain header information (header decompression context) by receiving header information transmitted from gNB200 separately from the compressed MBS packet. Therefore, UE100, which joins an MBS session midway, can successfully process the reception of MBS packets. Specifically, UE100, having received the compressed MBS packet and header information, uses the received header information to reconstruct the header of the received compressed MBS packet.

[0071] In one embodiment, the gNB200 transmits compressed MBS packets over an MBS traffic channel. The gNB200 transmits header information over a channel different from the MBS traffic channel.

[0072] For example, the gNB200 transmits header information via a control channel for MBS (MBS control channel) that is transmitted by broadcast. In this case, the gNB200 may periodically transmit header information via the MBS control channel.

[0073] The gNB200 may also transmit header information via a Dedicated Control Channel (DCCH) that transmits by unicast. In this case, the gNB200 may also send the header information to the UE100 when configuring the UE100 for MBS reception.

[0074] Figure 9 shows an example of the operation of a mobile communication system related to header compression processing according to one embodiment.

[0075] As shown in Figure 9, in step S101, gNB200 starts MBS transmission for a certain MBS session. In step S102, UE100A, which has been participating in the MBS session from the beginning, starts MBS reception for that MBS session. UE100A is in the RRC connected state, RRC idle state, or RRC inactive state.

[0076] If header information is not notified on the control channel (MBS control channel or individual control channel), the UE100A may, as usual, assume that it has been instructed to obtain header information from the received packet, or that the packet has been transmitted uncompressed.

[0077] In step S103, the gNB200 transmits uncompressed MBS packets via PTM over the MBS traffic channel.

[0078] In step S104, when the PDCP layer of UE100A receives an uncompressed MBS packet from gNB200, it obtains the header information to be compressed from the received uncompressed MBS packet and stores the header information (header decompression context).

[0079] In step S105, the gNB200 sends the compressed MBS packet, which has undergone header compression processing, via the MBS traffic channel using PTM.

[0080] In step S106, when the PDCP layer of UE100A receives a compressed MBS packet from gNB200, it uses the header information held in step S104 to reconstruct the header of the received compressed MBS packet and passes the MBS packet to the upper layer.

[0081] Subsequently, in step S107, UE100B joins the MBS session midway through and begins MBS reception for that session. UE100B is in either the RRC Connected state, the RRC Idle state, or the RRC Inactive state.

[0082] In step S108, the gNB200 transmits header information that has been omitted from transmission due to header compression via a control channel (MBS control channel or individual control channel). When the gNB200 transmits a message containing header information, it may include in the message at least one of the following: the identifier of the MBS traffic channel corresponding to the header information, the identifier of the MBS session corresponding to the header information (group RNTI, TMGI, and / or service ID), the identifier of the QoS flow corresponding to the MBS session, the bearer identifier, the RLC channel identifier, or the logical channel identifier.

[0083] In step S109, when the UE100B's PDCP layer receives header information from the gNB200, it stores the received header information (header decompression context). The UE100B's PDCP layer may also store the above identifier received from the gNB200 in association with the header information (header decompression context). Furthermore, if the UE100B receives header information from the gNB200, it may determine that it is instructed not to obtain (or not to obtain) header information from the received packet.

[0084] In step S110, the gNB200 transmits a compressed MBS packet, which has undergone header compression processing, via the MBS traffic channel using a PTM.

[0085] In step S111, when the PDCP layer of UE100B receives a compressed MBS packet from gNB200, it uses the header information held in step S109 to reconstruct the header of the received compressed MBS packet and passes the MBS packet to the upper layer.

[0086] In step S112, when the PDCP layer of UE100A receives a compressed MBS packet from gNB200, it uses the header information held in step S104 to reconstruct the header of the received compressed MBS packet and passes the MBS packet to the upper layer.

[0087] Figure 10 shows another example of operation of a mobile communication system relating to header compression processing according to one embodiment. In this example, the gNB200 transmits uncompressed MBS packets, which have not undergone header compression processing, at predetermined intervals. Specifically, the gNB200 transmits uncompressed MBS packets at predetermined intervals after starting to transmit compressed MBS packets that have undergone header compression processing.

[0088] As shown in Figure 10, the operation of steps S201 to S207 is the same as the operation of steps S101 to S107 in Figure 9.

[0089] In step S208, the gNB200 transmits uncompressed MBS packets via PTM over the MBS traffic channel. The gNB200 may also transmit uncompressed MBS packets over a control channel (MBS control channel or individual control channel).

[0090] In step S209, when the PDCP layer of UE100B receives an uncompressed MBS packet from gNB200, it obtains the header information to be compressed from the received uncompressed MBS packet and stores the header information (header decompression context).

[0091] The operation of steps S210 to S212 is the same as the operation of steps S110 to S112 in Figure 9.

[0092] In this example, the gNB200 may determine a predetermined period for transmitting uncompressed MBS packets in accordance with the QoS request of the MBS session. Alternatively, the period length determined in accordance with the QoS request of the MBS session may be notified to the gNB200 from the core network (AMF, etc.). The period length is determined by the tolerance of the UE100's access delay to the MBS session.

[0093] The predetermined period at which the gNB200 transmits uncompressed MBS packets may be linked to (synchronized with) the timing of changes to the MBS control channel (modification boundary). For example, the gNB200 transmits uncompressed data in the same subframe (or the immediately following MBS traffic channel transmission opportunity) as the modification boundary of the MBS control channel.

[0094] The predetermined period at which gNB200 transmits uncompressed MBS packets should preferably be a timing synchronized between UE100 and gNB200. For example, gNB200 transmits uncompressed packets in a frame calculated using the formula "SFN mod 256=0", where SFN represents the system frame number. Alternatively, uncompressed packets may be transmitted in a frame calculated using the formula "SFN mod N=0", where N is a value set by gNB200 to UE100.

[0095] (Handling of PDCP variables) Next, we will describe the PDCP variables according to one embodiment.

[0096] The UE100's PDCP layer sets and updates PDCP variables according to the PDCP sequence number (PDCP SN) contained in packets received from the gNB200. Typically, the UE100B sets the initial value of the PDCP variables to zero and updates (increments) the PDCP variables in response to packets received from the gNB200.

[0097] A UE100 that joins an MBS session from the beginning can sequentially update its PDCP variables and bring them to the latest state. On the other hand, a UE100 that joins an MBS session midway may receive MBS packets with PDCP sequence numbers that are significantly different from their initial values, which could prevent it from performing the PDCP layer operations (predetermined PDCP operations) correctly.

[0098] In one embodiment, the following method enables a UE100 that joins an MBS session midway through to perform predetermined PDCP operations correctly.

[0099] In one embodiment, the PDCP entity of UE100 sets the PDCP sequence number contained in the first MBS packet received from gNB200 as the initial value of a variable (PDCP variable) used for a predetermined PDCP operation. That is, when the PDCP entity of UE100 receives an MBS packet transmitted via PTM, it does not set the PDCP variable to zero, but rather sets the PDCP sequence number contained in the first MBS packet received from gNB200 as the initial value of the PDCP variable. This enables UE100, which joined the MBS session midway, to perform the predetermined PDCP operation correctly.

[0100] In one embodiment, the predetermined PDCP operation is at least one of the following: receive window control and packet reordering operation.

[0101] The PDCP variables used for receive window control may be at least one of RX_NEXT and RX_DELIV. RX_NEXT is the sequence number of the next PDCP SDU expected to be received. RX_DELIV is the sequence number of the oldest PDCP SDU waiting to be received but not yet provided to the upper layer. Typically, the initial values ​​of RX_NEXT and RX_DELIV are "0".

[0102] The PDCP variable used for packet reordering may also be RX_REORD. RX_REORD is the sequence number of the PDCP SDU that started the timer indicating the maximum time to wait for packet reordering. For example, UE100 discards a received packet if its sequence number is less than RX_DELIV.

[0103] Figure 11 shows an example of the operation of a mobile communication system with respect to PDCP variables according to one embodiment.

[0104] As shown in Figure 11, in step S301, gNB200 starts MBS transmission for a certain MBS session. In step S302, UE100A, which is participating in the MBS session from the beginning, starts MBS reception for that MBS session. UE100A is in the RRC connected state, RRC idle state, or RRC inactive state. UE100A may receive and perform the MBS bearer (PDCP) configuration from gNB200.

[0105] In step S303, the gNB200 transmits an MBS packet (PDCP packet) via the MBS bearer using PTM. Assume that the sequence number (PDCP sequence number) included in the PDCP header of this MBS packet (PDCP packet) is "0".

[0106] In step S304, when the PDCP layer of UE100A receives an MBS packet from gNB200, it sets the PDCP sequence number "0" contained in the received MBS packet as the initial value of the PDCP variable and performs a predetermined PDCP operation.

[0107] Subsequently, in step S305, UE100B joins the MBS session midway and begins MBS reception for that session. UE100B is in the RRC Connected, RRC Idle, or RRC Inactive state. UE100B may also receive and execute the MBS Bearer (PDCP) configuration from gNB200.

[0108] In step S306, the gNB200 transmits an MBS packet (PDCP packet) via the MBS bearer using PTM. The sequence number (PDCP sequence number) included in the PDCP header of this MBS packet (PDCP packet) is "n", where "n" is an integer greater than or equal to 1.

[0109] In step S307, when the UE100B's PDCP layer first receives an MBS packet (PDCP packet) via the MBS bearer, it sets the PDCP sequence number "n" contained in the first received MBS packet as the initial value of the PDCP variable and performs a predetermined PDCP operation. For example, the UE100B's PDCP layer sets RX_DELIV = the sequence number "n" of the packet and RX_NEXT = the sequence number "n" of the packet. Alternatively, it may be (n+1) mod [SN size].

[0110] In step S308, when the UE100A's PDCP layer receives an MBS packet (PDCP packet) via the MBS bearer, it updates the PDCP variable with the PDCP sequence number "n" contained in the received MBS packet.

[0111] In step S309, the gNB200 transmits an MBS packet (PDCP packet) via the MBS bearer using PTM. Assume that the sequence number (PDCP sequence number) included in the PDCP header of this MBS packet (PDCP packet) is "n+1".

[0112] In step S310, when the UE100B's PDCP layer receives an MBS packet (PDCP packet) via the MBS bearer, it updates the PDCP variable with the PDCP sequence number "n+1" contained in the received MBS packet.

[0113] In step S311, when the PDCP layer of UE100A receives an MBS packet (PDCP packet) via the MBS bearer, it updates the PDCP variable with the PDCP sequence number "n+1" contained in the received MBS packet.

[0114] In this example, the initial values ​​of each PDCP variable were updated from the received MBS packet, but this is not limited to this. The initial values ​​of each PDCP variable may also be set from gNB200 to UE100. For example, UE100B, which performs MBS reception midway, may be given the initial values ​​of each PDCP variable from gNB200 when MBS reception settings are configured in dedicated signalling.

[0115] (Handling of SDAP headers) Next, an SDAP header according to one embodiment will be described.

[0116] Figure 12 shows the data flow in gNB200 and UE100. This section describes the downlink.

[0117] As shown in Figure 12, the SDAP layer of the gNB200 maps QoS flows to wireless bearers and adds an SDAP header containing the QoS flow identifier to the SDAP SDU (i.e., IP packet) before passing it to the PDCP layer. On the other hand, the SDAP layer of the UE100 receives the SDAP PDU from the PDCP layer, removes the SDAP header attached to the SDAP PDU, and passes the SDAP SDU (i.e., IP packet) to the upper layer.

[0118] Here, the SDAP header includes a QoS flow identifier, but in the case of MBS, which only has a downlink, this QoS flow identifier is not very meaningful for the reasons 1 to 3 below. For this reason, MBS will use a format without an SDAP header to reduce overhead.

[0119] Reason 1: Reflective mapping (the process of determining the QoS flow identifier of an uplink packet from the QoS flow identifier of a downlink packet) does not require a QoS flow identifier in the case of MBS.

[0120] Reason 2: While QoS flows are the smallest unit of QoS control within the core network, wireless QoS control is at the bearer level, and there is no specific QoS control within the UE100. Therefore, a QoS flow identifier is not necessary for an MBS that only handles downlinks.

[0121] Reason 3: Even if an uplink for feedback exists, the feedback is at the HARQ, RLC, and PDCP layers, not at the SDAP layer, and since it is a control PDU, control at the QoS flow level is not necessary.

[0122] Therefore, in one embodiment, the UE100, which receives an MBS packet from the gNB200 via the MBS data bearer, assumes at the SDAP layer that the received MBS packet does not have an SDAP header attached, and passes the MBS packet (IP packet) to the upper layer without performing any SDAP header removal processing on the MBS packet.

[0123] This eliminates the need for explicit configuration of whether or not an SDAP header is present in the RRC layer for MBS data bearers. Regardless of the SDAP header setting in the RRC, the UE100 determines that MBS data bearers are transmitted without an SDAP header. In other words, even if the UE100 receives configuration information (RRC configuration information) regarding the SDAP layer setting from the gNB200, it does not perform SDAP header removal processing on the received MBS packets, regardless of that configuration information, and passes the MBS packets to the upper layer.

[0124] (Multiplex transmission of multiple logical channels) Next, a logical channel according to one embodiment will be described.

[0125] In typical unicast transmissions, the gNB200 can multiplex multiple logical channels for multiple applications using a single C-RNTI (Cell Radio Network Temporary Identifier), i.e., a single PDSCH (Physical Downlink Shared Channel).

[0126] In the case of MBS, it is thought that PTP transmission allows for the multiplexing and transmission of MBS packets (logical channels for MBS) and regular unicast packets (logical channels for unicast) using a single C-RNTI (single PDSCH), similar to unicast transmission.

[0127] On the other hand, in the case of PTM transmission, since it is a simultaneous transmission to a large number of UEs and the transmission timing (period) differs for each MBS service, it is generally considered that multiple logical channels cannot be multiplexed with one group RNTI (one PDSCH).

[0128] However, since the core network (5GC20) performs QoS control on a per-QoS flow basis, a single MBS service may have multiple QoS flows. As mentioned above, the SDAP layer of the gNB200 maps QoS flows to bearers (=logical channels).

[0129] Therefore, multiple QoS flows belonging to a single MBS service can be mapped to different logical channels and multiplexed and transmitted at the MAC layer using a single RNTI (a single group RNTI).

[0130] In one embodiment, the gNB200 maps one or more QoS flows belonging to a single MBS session to multiple MBS data bearers at the SDAP layer. The gNB200 then multiplexes and transmits the multiple logical channels corresponding to these multiple MBS data bearers using a single RNTI (a single group RNTI). This enables efficient transmission of multiple logical channels.

[0131] Figure 13 shows an example of the operation of multiplex transmission of multiple logical channels according to one embodiment.

[0132] As shown in Figure 13, in the gNB200 that performs PTM transmission of MBS data, the SDAP layer maps multiple QoS flows belonging to one MBS session to k bearers, where k is an integer greater than or equal to 2. Multiple QoS flows belonging to one MBS session refer to multiple QoS flows associated with one session identifier. The RLC layer of the gNB200 passes the MBS data for k logical channels corresponding to the k bearers (k RLC channels) to the MAC layer.

[0133] The MAC layer of the gNB200 multiplexes and transmits MBS data from k logical channels using a single group RNTI. Specifically, the physical (PHY) layer of the gNB200 transmits the assignment information of the PDSCH carrying the MBS data to the UE100 via a PDCCH (Physical Downlink Control Channel) to which a single group RNTI is applied.

[0134] Thus, the gNB200 multiplexes and transmits different QoS flows mapped to different logical channels within a single group RNTI only when those different logical channels are associated with a single MBS session.

[0135] On the other hand, the physical (PHY) layer of UE100 receives the PDSCH associated with the group RNTI. If the decoded PDSCH contains k logical channels, the MAC layer of UE100 passes the MBS data to the RLC layer via the corresponding logical channels.

[0136] Here, UE100 may determine that these k logical channels are associated with a single MBS session, since they were transmitted within the same RNTI group.

[0137] The UE100's SDAP layer then passes the MBS data for k bearers (multiple QoS flows) to a higher layer (e.g., the application layer).

[0138] (Other embodiments) In the above embodiment, an example was described in which the base station is an NR base station (gNB), but the base station may also be an LTE base station (eNB). Furthermore, the base station may be a relay node such as an IAB (Integrated Access and Backhaul) node. The base station may also be a DU (Distributed Unit) of an IAB node.

[0139] A program may be provided that causes a computer to perform each of the processes that UE100 or gNB200 performs. The program may be recorded on a computer-readable medium. Using a computer-readable medium, it is possible to install the program on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transient recording medium. The non-transient recording medium is not particularly limited, but may be a recording medium such as a CD-ROM or DVD-ROM.

[0140] Alternatively, the circuits that perform each process carried out by the UE100 or gNB200 may be integrated, and at least a portion of the UE100 or gNB200 may be configured as a semiconductor integrated circuit (chipset, SoC).

[0141] Although the embodiments have been described in detail above with reference to the drawings, the specific configuration is not limited to those described above, and various design changes can be made without departing from the gist of the invention.

[0142] This application claims priority to U.S. Provisional Application No. 63 / 093386 (filed October 19, 2020), the entirety of which is incorporated into the specification of this application. [Explanation of Symbols]

[0143] 10: NG-RAN (5G RAN) 20:5GC(5G CN) 100 :UE 110: Receiving unit 120: Transmitter 130: Control Unit 200 :gNB 210: Transmitter 220: Receiving unit 230: Control Unit 240: Backhaul Communications Department

Claims

1. A communication control method used in a mobile communication system that provides multicast broadcast services (MBS) from a base station to user equipment, The base station maps one or more QoS (Quality of Service) flows belonging to one MBS session to multiple MBS data bearers, The base station sets one RNTI for multiple logical channels corresponding to the multiple MBS data bearers. Communication control method.

2. User equipment that supports multicast broadcast services (MBS), The system includes a receiving unit that receives configuration information from a base station to set a single RNTI for multiple logical channels corresponding to multiple MBS data bearers mapped to one or more QoS (Quality of Service) flows belonging to a single MBS session. User device.

3. A processor for controlling user equipment that supports multicast broadcast services (MBS), This process involves receiving configuration information from the base station to set a single RNTI for multiple logical channels corresponding to multiple MBS data bearers mapped to one or more QoS (Quality of Service) flows belonging to a single MBS session. Processor.

4. User equipment that supports multicast broadcast services (MBS) This process involves receiving configuration information from a base station to set a single RNTI for multiple logical channels corresponding to multiple MBS data bearers mapped to one or more QoS (Quality of Service) flows belonging to a single MBS session. program.

5. A system having the user device and base station described in claim 2.

Images