COMMUNICATION CONTROL METHOD, USER EQUIPMENT, AND PROCESSOR

Abstract

This communication control method for use in a mobile communication system which provides a multicast broadcast service (MBS) to a user device from a base device comprises: performing, at the base station, a header compression process for omitting transmission of header information which is static information included in a header of a MBS packet and transmitting a compressed MBS packet having undergone the header compression process; and transmitting, after the start of transmission of the compressed MBS packet at the base station, the header information separately from the compressed MBS packet.

Description

[Technical field]

[0001] The present invention relates to a communication control method for use in a mobile communication system. [Background technology]

[0002] In recent years, the fifth generation (5G) mobile communication system has been attracting attention. NR (New Radio), the radio access technology (RAT) of the 5G system, has features such as high speed, large capacity, high reliability, and low latency compared to LTE (Long Term Evolution), the fourth generation radio access technology. [Prior art documents] [Non-patent literature]

[0003] [Non-Patent Document 1] 3GPP technical specification "3GPP TS 38.300 V16.3.0 (2020-09)" 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, and includes the steps of: the base station transmitting a compressed MBS packet that has been subjected to header compression processing while performing a header compression processing that omits transmission of header information, which is static information contained in the header of the MBS packet; and after the base station starts transmitting the compressed MBS packet, transmitting the header information separately from the compressed MBS packet.

[0005] A communication control method according to a second 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, and includes the steps of: the user device receiving an MBS packet from the base station; and a PDCP (Packet Data Convergence Protocol) entity of the user device setting a PDCP sequence number contained in the MBS packet first received from the base station as an initial value of a variable to be used for a specified PDCP operation.

[0006] A communication control method according to a third 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 method comprising the steps of: receiving an MBS packet from the base station via an MBS data bearer; and a Service Data Adaptation Protocol (SDAP) layer of the user device determining that an SDAP header is not added to the MBS packet, thereby performing an S for the MBS packet. D.A. and passing the MBS packet to a higher layer without performing a P-header removal process.

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

[0008] [Figure 1] 1 is a diagram showing a configuration of a mobile communication system according to an embodiment; [Diagram 2] FIG. 1 is a diagram illustrating a configuration of a UE (user equipment) according to an embodiment. [Diagram 3] A diagram showing the configuration of a gNB (base station) according to one embodiment. [Figure 4] A diagram showing the configuration of a protocol stack of a wireless interface of a user plane that handles data. [Diagram 5] FIG. 2 is a diagram showing the configuration of a protocol stack of a radio interface of a control plane that handles signaling (control signals). [Figure 6] FIG. 2 is a diagram showing a correspondence relationship between downlink logical channels and transport channels according to an embodiment. [Figure 7] FIG. 2 is a diagram illustrating a method for distributing MBS data according to an embodiment. [Figure 8] A diagram showing the Layer 2 structure of a gNB in ​​a downlink according to one embodiment. [Figure 9] FIG. 1 is a diagram illustrating an example of the operation of a mobile communication system regarding a header compression process according to an embodiment. [Figure 10] FIG. 11 is a diagram showing another example of operation of the mobile communication system regarding the header compression process according to an embodiment. [Figure 11] A diagram showing an example of the operation of a mobile communication system regarding PDCP variables according to one embodiment. [Figure 12] A diagram showing data flow in a gNB and a UE according to one embodiment. [Figure 13] FIG. 11 is a diagram illustrating an example of an operation of multiplexing multiple logical channels according to an embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] The introduction of multicast and broadcast services to the 5G system (NR) is being considered. It is hoped that the NR multicast and broadcast services will provide improved services compared to the LTE multicast and broadcast services.

[0010] Therefore, an object of the present invention is to provide an improved multicast / broadcast service.

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

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

[0013] As shown in FIG. 1, the mobile communication system includes a user equipment (UE) 100, a 5G radio access network (NG-RAN) 10, and a 5G core network (5GC) 20.

[0014] The UE 100 is a mobile wireless communication device. The UE 100 may be any device that is used by a user, and may be, for example, a mobile phone terminal (including a smartphone), a tablet terminal, a notebook PC, a communication module (including a communication card or a chipset), a sensor or a device provided in a sensor, a vehicle or a device provided in a vehicle (Vehicle UE), or an aircraft or a device provided in an aircraft (Aerial UE).

[0015] The NG-RAN 10 includes a base station (called "gNB" in the 5G system) 200. The gNBs 200 are connected to each other via an 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 own 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, and the like. The term "cell" is used to indicate the smallest unit of a wireless communication area. The term "cell" is also used to indicate a function or resource for performing wireless communication with the UE 100. One cell belongs to one carrier frequency.

[0016] In addition, gNBs can also be connected to the Evolved Packet Core (EPC), which is the core network of LTE. LTE base stations can also be connected to 5GC. LTE base stations and gNBs can also be connected via an inter-base station interface.

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

[0018] FIG. 2 is a diagram showing a 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 .

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

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

[0022] The control unit 130 performs various controls in the UE 100. 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 in the processing by the processor. The processor may include a baseband processor and a CPU (Central Processing Unit). The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals. The CPU executes programs stored in the memory to perform various processing.

[0023] FIG. 3 is a diagram showing the configuration of a gNB 200 (base station) according to one embodiment.

[0024] As shown in FIG. 3, the gNB 200 includes a transmitter 210, a receiver 220, a control unit 230, and a backhaul communication unit 240.

[0025] The transmission unit 210 performs various transmissions under the control of the control unit 230. The transmission unit 210 includes an antenna and a transmitter. The transmitter converts a 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 receptions under the control of the control unit 230. The receiving unit 220 includes an antenna and a receiver. The receiver converts a radio signal received by the antenna into a baseband signal (received signal) and outputs the baseband signal to the control unit 230.

[0027] The control unit 230 performs various controls in the gNB 200. 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 in the processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals. The CPU executes programs stored in the memory to perform various processing.

[0028] The backhaul communication unit 240 is connected to adjacent base stations via an inter-base station interface. The backhaul communication unit 240 is connected to the AMF / UPF 300 via a base station-core network interface. Note that the gNB is composed of a CU (Central Unit) and a DU (Distributed Unit) (i.e., the functions are divided), and both units may be connected to each other via an F1 interface.

[0029] FIG. 4 is a diagram showing the configuration of a protocol stack of a radio interface of a user plane that handles data.

[0030] As shown in FIG. 4, the user plane radio interface protocol includes a physical (PHY) layer, a medium access control (MAC) layer, a radio link control (RLC) layer, a packet data convergence protocol (PDCP) layer, and a service data adaptation protocol (SDAP) 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 PHY layer of the UE 100 and the PHY layer of the gNB 200 via a physical channel.

[0032] The MAC layer performs data priority control, retransmission processing using hybrid ARQ (HARQ), random access procedures, etc. Data and control information are transmitted between the MAC layer of the UE 100 and the MAC layer of the gNB 200 via a transport channel. The MAC layer of the gNB 200 includes a scheduler. The scheduler determines the uplink and downlink transport format (transport block size, modulation and coding scheme (MCS)) and the resource blocks to be assigned to the UE 100.

[0033] The RLC layer transmits data to the RLC layer on the receiving side by using the functions of the MAC layer and the PHY layer. Data and control information are transmitted between the RLC layer of the UE 100 and the RLC layer of the gNB 200 via a logical channel.

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

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

[0036] FIG. 5 is a diagram showing the configuration of a protocol stack of a radio interface of a control plane that handles signaling (control signals).

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

[0038] Between the RRC layer of the UE 100 and the RRC layer of the gNB 200, RRC signaling for various settings is transmitted. The RRC layer controls logical channels, transport channels, and physical channels according to the establishment, re-establishment, and release of radio bearers. When there is a connection (RRC connection) between the RRC of the UE 100 and the RRC of the gNB 200, the UE 100 is in an RRC connected state. When there is no connection (RRC connection) between the RRC of the UE 100 and the RRC of the gNB 200, the UE 100 is in an RRC idle state. When the connection between the RRC of the UE 100 and the RRC of the gNB 200 is suspended, the UE 100 is in an RRC inactive state.

[0039] The NAS layer, which is located above the RRC layer, performs session management, mobility management, etc. NAS signaling is transmitted between the NAS layer of the UE 100 and the NAS layer of the AMF 300B.

[0040] In addition, the UE 100 has an application layer and the like in addition to the protocol of the radio interface.

[0041] (MBS) Next, an MBS according to an embodiment will be described. The MBS is a service that transmits data from the NG-RAN 10 to the UE 100 by broadcast or multicast, that is, point to multipoint (PTM). The MBS may be called an MBMS (Multimedia Broadcast and Multicast Service). Note that use cases (service types) of the MBS include public safety communication, mission critical communication, V2X (Vehicle to Everything) communication, IPv4 or IPv6 multicast distribution, IPTV, group communication, 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. Fig. 6 is a diagram showing a correspondence relationship between downlink logical channels and transport channels 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 designed mainly for multi-cell transmission, and in an MBSFN area consisting of multiple cells, each cell synchronously transmits the same signal (same data) in 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 designed mainly for single cell transmission, and transmits data by broadcast or multicast on a cell-by-cell basis. The physical channels used for SC-PTM transmission are PDCCH (Physical Downlink Control Channel) and PDSCH (Physical Downlink Control Channel), which allows dynamic resource allocation.

[0045] In the following, an example in which an MBS is provided using the SC-PTM transmission method will be mainly described, but an MBS may also be provided using the MBSFN transmission method. Also, an example in which an MBS is provided by multicast will be mainly described. Therefore, MBS may be read as multicast. However, an MBS may also be provided by broadcast.

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

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

[0048] FIG. 7 is a diagram showing a method for delivering MBS data according to an embodiment.

[0049] As shown in Fig. 7, MBS data (MBS Traffic) is distributed from a single data source (application service provider) to multiple UEs. A 5G CN (5GC) 20, which is a 5G core network, receives the MBS data from the application service provider, creates a copy (replication) of the MBS data, and distributes it.

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

[0051] In the shared MBS data delivery, a connection is established between NG-RAN 10, which is a 5G radio access network (5G RAN), and 5GC 20, and MBS data is delivered from 5GC 20 to NG-RAN 10. Hereinafter, such a connection (tunnel) is referred to as an "MBS connection."

[0052] The MBS connection may be called a Shared MBS Traffic delivery connection or a shared transport. The MBS connection terminates in the NG-RAN 10 (i.e., the gNB 200). The MBS connection may correspond one-to-one with the MBS session. The gNB 200 selects either PTP (Point-to-Point: unicast) or PTM (Point-to-Multipoint: multicast or broadcast) at its own discretion, and transmits MBS data to the UE 100 in the selected manner.

[0053] On the other hand, in the individual MBS data delivery, a unicast session is established between the NG-RAN 10 and the UE 100, and the MBS data is delivered individually from the 5GC 20 to the UE 100. Such a unicast may be called a PDU session. The unicast (PDU session) is terminated at the UE 100.

[0054] In the following embodiment, an example in which gNB200 transmits MBS of PTM will be mainly described.

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

[0056] FIG. 8 is a diagram showing a layer 2 structure of gNB200 in the 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, since there is a one-to-one correspondence between logical channels and RLC channels, and a one-to-one correspondence between RLC channels and radio bearers, there is also a one-to-one correspondence between logical channels and radio bearers. In contrast, there is not a one-to-one correspondence between QoS flows and radio bearers. For this reason, the SDAP layer performs a process of associating (mapping) QoS flows with radio bearers.

[0059] The PDCP layer has a PDCP entity provided for each radio bearer. Each PDCP entity has a function to perform processing by RoHC (Robust Header Compression). In the following, an example in which RoHC is used as a header compression protocol will be described, but other protocols, for example, EHC (Ethernet Header Compression), may also be used. The RoHC function performs compression processing of IP headers (hereinafter simply referred to as "header compression processing"). Data to which RoHC is applied is user data that flows on a data radio 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 PDCP layer of the gNB 200 (hereinafter referred to as the "gNB-side RoHC function") performs header compression by RoHC before performing encryption. On the other hand, the RoHC function of the PDCP layer of the UE 100 (hereinafter referred to as the "UE-side RoHC function") performs header decompression (header restoration) by RoHC after performing deciphering.

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

[0062] In the FO state, most of the static fields (parameters that hardly change on a packet-by-packet basis) of the header information subject to RoHC compression are compressed. Some static fields and dynamic fields (parameters that change on a packet-by-packet basis) are sent to the RoHC function on the UE side without being compressed.

[0063] In the SO state, the header compression rate is the highest. By transmitting only the RTP sequence number from the gNB RoHC function, the UE RoHC function can restore the target header.

[0064] On the other hand, the UE side RoHC function transitions through, for example, the No Context (NC) state, the Static Context (SC) state, and the Full Context (FC) state in that order. The initial state of the UE side RoHC function is the NC state, which does not contain information required for header decompression (header decompression context) and cannot perform decompression processing correctly. When the UE side RoHC function receives the header decompression context, it transitions to the FC state. Thereafter, successive header decompression failures trigger transitions to the SC state and then the NC state.

[0065] By applying such header compression by RoHC to PTM transmission of MBS packets, it is possible to reduce the overhead caused by the header. However, RoHC is a header compression protocol that is mainly intended for unicast, and the following problems may occur.

[0066] UE 100, which has participated in an MBS session from the beginning, can receive an uncompressed MBS packet that has not undergone header compression processing from gNB 200, obtain header information from the uncompressed MBS packet, and retain information necessary for header decompression (header decompression context).

[0067] On the other hand, the UE 100 that joined the MBS session halfway through cannot receive the uncompressed MBS packet that has not been subjected to the header compression process from the gNB 200, and therefore cannot hold the information required for header decompression (header decompression context) and cannot restore the target header. Therefore, there is a problem that the UE 100 that joined the MBS session halfway through cannot normally perform the reception process of the MBS packet.

[0068] In one embodiment, the following method enables a UE 100 that joins an MBS session midway through to normally receive an MBS packet.

[0069] In one embodiment, the gNB 200 transmits a compressed MBS packet that has been subjected to the header compression process while performing a header compression process that omits transmission of header information, which is static information included in the header of the MBS packet. After starting transmission of the compressed MBS packet, the gNB 200 transmits the header information separately from the compressed MBS packet.

[0070] As a result, UE 100 that has joined an MBS session midway can hold the header information (header decompression context) by receiving the header information transmitted from gNB 200 separately from the compressed MBS packet. Therefore, UE 100 that has joined an MBS session midway can normally perform reception processing of the MBS packet. Specifically, UE 100 that has received the compressed MBS packet and the header information restores the header of the received compressed MBS packet using the received header information.

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

[0072] For example, the gNB 200 transmits the header information through a control channel for MBS (MBS control channel) transmitted by broadcast. In this case, the gNB 200 may periodically transmit the header information through the MBS control channel.

[0073] The gNB 200 may transmit the header information by a dedicated control channel (DCCH: Dedicated Control CHannel) transmitted by unicast. In this case, the gNB 200 may transmit the header information to the UE 100 when setting the UE 100 to receive MBS.

[0074] FIG. 9 is a diagram showing an example of the operation of the mobile communication system regarding the header compression process according to an embodiment.

[0075] 9, in step S101, the gNB 200 starts MBS transmission for a certain MBS session. In step S102, the UE 100A that initially participates in the MBS session starts MBS reception for the MBS session. The UE 100A is in an RRC connected state, an RRC idle state, or an RRC inactive state.

[0076] If the header information is not notified via a control channel (MBS control channel or dedicated control channel), the UE 100A may determine that it has been instructed to obtain the header information from the received packet, as in normal cases, or that the packet has been transmitted uncompressed.

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

[0078] In step S104, when the PDCP layer of the UE 100A receives an uncompressed MBS packet from the gNB 200, the PDCP layer acquires header information to be compressed from the received uncompressed MBS packet, and retains the header information (header decompression context).

[0079] In step S105, gNB200 transmits the compressed MBS packet that has been header compressed via the MBS traffic channel using PTM.

[0080] In step S106, when the PDCP layer of the UE 100A receives the compressed MBS packet from the gNB 200, it restores the header of the received compressed MBS packet using the header information retained in step S104, and passes the MBS packet to an upper layer.

[0081] After that, in step S107, the UE 100B joins the MBS session midway and starts MBS reception for the MBS session. The UE 100B is in an RRC connected state, an RRC idle state, or an RRC inactive state.

[0082] In step S108, the gNB 200 transmits the header information, the transmission of which has been omitted by the header compression process, via a control channel (MBS control channel or dedicated control channel). When transmitting a message including the header information, the gNB 200 may include at least one of an MBS traffic channel identifier corresponding to the header information, an MBS session identifier (group RNTI, TMGI, and / or service ID) corresponding to the header information, a QoS flow identifier corresponding to the MBS session, a bearer identifier, an RLC channel identifier, and a logical channel identifier in the message.

[0083] In step S109, when the PDCP layer of the UE 100B receives the header information from the gNB 200, the PDCP layer of the UE 100B holds the received header information (header decompression context). The PDCP layer of the UE 100B may hold the above-mentioned identifier received from the gNB 200 in association with the header information (header decompression context). Note that, when the header information is notified from the gNB 200, the UE 100B may determine that it has been instructed that the header information cannot be acquired (or does not need to be acquired) from the received packet.

[0084] In step S110, gNB200 transmits the compressed MBS packet that has been header compressed via the MBS traffic channel using PTM.

[0085] In step S111, when the PDCP layer of the UE 100B receives the compressed MBS packet from the gNB 200, it restores the header of the received compressed MBS packet using the header information retained in step S109, and passes the MBS packet to an upper layer.

[0086] In step S112, when the PDCP layer of the UE 100A receives the compressed MBS packet from the gNB 200, it restores the header of the received compressed MBS packet using the header information retained in step S104, and passes the MBS packet to an upper layer.

[0087] 10 is a diagram showing another operation example of the mobile communication system related to the header compression process according to an embodiment. In this operation example, the gNB 200 transmits uncompressed MBS packets that have not been subjected to the header compression process at a predetermined period. Specifically, the gNB 200 transmits uncompressed MBS packets at a predetermined period after starting to transmit compressed MBS packets that have been subjected to the header compression process.

[0088] As shown in FIG. 10, the operations in steps S201 to S207 are similar to the operations in steps S101 to S107 in FIG.

[0089] In step S208, the gNB 200 transmits the uncompressed MBS packet in PTM via an MBS traffic channel. The gNB 200 may transmit the uncompressed MBS packet via a control channel (MBS control channel or dedicated control channel).

[0090] In step S209, when the PDCP layer of the UE 100B receives an uncompressed MBS packet from the gNB 200, the PDCP layer acquires header information to be compressed from the received uncompressed MBS packet and retains the header information (header decompression context).

[0091] The operations in steps S210 to S212 are similar to the operations in steps S110 to S112 in FIG.

[0092] In this operation example, the gNB 200 may determine the predetermined period for transmitting the uncompressed MBS packets according to the QoS requirement of the MBS session. Alternatively, the period length determined according to the QoS requirement of the MBS session may be notified to the gNB 200 from the core network (AMF, etc.). Note that the period length is determined according to the allowable amount of access delay of the UE 100 to the MBS session.

[0093] The predetermined period in which the gNB 200 transmits the uncompressed MBS packet may be linked (synchronized) with the modification timing (modification boundary) of the MBS control channel. For example, the gNB 200 transmits uncompressed data in the same subframe as the modification boundary of the MBS control channel (or in the MBS traffic channel transmission opportunity immediately thereafter).

[0094] The predetermined period in which the gNB 200 transmits the uncompressed MBS packets is preferably a timing synchronized between the UE 100 and the gNB 200. For example, the gNB 200 transmits the uncompressed packets in a frame calculated by the formula "SFN mod 256=0". Here, SFN means the system frame number. Alternatively, the uncompressed packets may be transmitted in a frame calculated by the formula "SFN mod N=0", where N is a value set by the gNB 200 to the UE 100.

[0095] (Handling PDCP variables) Next, the PDCP variables according to one embodiment will be described.

[0096] The PDCP layer of the UE 100 sets and updates PDCP variables according to the PDCP sequence number (PDCP SN) included in the packet received from the gNB 200. Usually, the UE 100B sets the initial value of the PDCP variable to zero, and updates (increments) the PDCP variable in response to the reception of a packet from the gNB 200.

[0097] UE 100 that has participated in an MBS session from the beginning can sequentially update the PDCP variables to the latest state. On the other hand, UE 100 that participates in an MBS session halfway through may receive an MBS packet having a PDCP sequence number whose value is significantly different from the initial value, and may not be able to perform the PDCP layer operation (predetermined PDCP operation) normally.

[0098] In one embodiment, the following method enables a UE 100 that joins an MBS session midway to perform a predetermined PDCP operation normally.

[0099] In one embodiment, the PDCP entity of UE 100 sets the PDCP sequence number included in the MBS packet first received from gNB 200 as the initial value of a variable (PDCP variable) used for a predetermined PDCP operation. That is, when receiving an MBS packet transmitted in PTM, the PDCP entity of UE 100 does not set the PDCP variable to zero, but sets the PDCP sequence number included in the MBS packet first received from gNB 200 as the initial value of the PDCP variable. This enables UE 100, which has joined an MBS session midway, to perform the predetermined PDCP operation normally.

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

[0101] The PDCP variables used for the 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 that is waiting to be received and has not yet been provided to the upper layer. Usually, the initial values ​​of RX_NEXT and RX_DELIV are "0".

[0102] The PDCP variable used for packet reordering may 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, the UE 100 may receive a packet with a sequence number of PDCP SDU sequence number If it is smaller than , the packet is discarded.

[0103] FIG. 11 is a diagram illustrating an example of an operation of a mobile communication system regarding PDCP variables according to an embodiment.

[0104] As shown in FIG. 11, in step S301, the gNB 200 starts MBS transmission for a certain MBS session. In step S302, the UE 100A, which initially participates in the MBS session, starts MBS reception for the MBS session. The UE 100A is in an RRC connected state, an RRC idle state, or an RRC inactive state. The UE 100A may receive and execute the setting of an MBS bearer (PDCP) from the gNB 200.

[0105] In step S303, the gNB 200 transmits an MBS packet (PDCP packet) by PTM via the MBS bearer. The sequence number (PDCP sequence number) included in the PDCP header of this MBS packet (PDCP packet) is assumed to be “0”.

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

[0107] After that, in step S305, the UE 100B joins the MBS session midway and starts MBS reception for the MBS session. The UE 100B is in an RRC connected state, an RRC idle state, or an RRC inactive state. The UE 100B may receive and execute the setting of the MBS bearer (PDCP) from the gNB 200.

[0108] In step S306, the gNB 200 transmits an MBS packet (PDCP packet) in PTM via the MBS bearer. The sequence number (PDCP sequence number) included in the PDCP header of this MBS packet (PDCP packet) is assumed to be “n”. Here, “n” is an integer equal to or greater than 1.

[0109] In step S307, when the PDCP layer of the UE 100B receives an MBS packet (PDCP packet) via the MBS bearer for the first time, it sets the PDCP sequence number "n" included in the first received MBS packet as the initial value of the PDCP variable, and performs a predetermined PDCP operation. For example, the PDCP layer of the UE 100B sets RX_DELIV=sequence number "n" of the packet, and RX_NEXT=sequence number "n" of the packet. Alternatively, it may set it to (n+1) mod [SN size].

[0110] In step S308, when the PDCP layer of the UE 100A receives the MBS packet (PDCP packet) via the MBS bearer, the PDCP layer updates the PDCP variables with the PDCP sequence number "n" included in the received MBS packet.

[0111] In step S309, the gNB 200 transmits an MBS packet (PDCP packet) by PTM via the MBS bearer. The sequence number (PDCP sequence number) included in the PDCP header of this MBS packet (PDCP packet) is assumed to be “n+1”.

[0112] In step S310, when the PDCP layer of the UE 100B receives an MBS packet (PDCP packet) via the MBS bearer, the PDCP layer updates the PDCP variables with the PDCP sequence number "n+1" included in the received MBS packet.

[0113] In step S311, when the PDCP layer of the UE 100A receives an MBS packet (PDCP packet) via the MBS bearer, the PDCP layer updates the PDCP variables with the PDCP sequence number "n+1" included in the received MBS packet.

[0114] In this operation example, the initial value of each PDCP variable is updated from the received MBS packet, but this is not limited to the above. The initial value of each PDCP variable may be set in the UE 100 by the gNB 200. For example, the UE 100B that performs MBS mid-reception may be given the initial value of each PDCP variable by the gNB 200 when MBS reception setting is performed by dedicated signaling.

[0115] (SDAP header handling) Next, the SDAP header according to an embodiment will be described.

[0116] 12 is a diagram showing a data flow in the gNB 200 and the UE 100. Here, the downlink will be described.

[0117] As shown in Fig. 12, the SDAP layer of the gNB 200 performs a process of associating (mapping) a QoS flow with a radio bearer, and also adds an SDAP header including an identifier of the QoS flow to an SDAP SDU (i.e., an IP packet) and passes the SDAP SDU (i.e., an IP packet) to the PDCP layer. On the other hand, the SDAP layer of the UE 100 receives an SDAP PDU from the PDCP layer, removes the SDAP header added to the SDAP PDU, and passes the SDAP SDU (i.e., an IP packet) to a higher layer.

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

[0119] Reason 1: Reflective mapping (the operation 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: A QoS flow is the smallest unit of QoS control within a core network, but in wireless communication, QoS control is performed on a bearer basis, and there is no particular QoS control within UE 100, so a QoS flow identifier is not required for a downlink-only MBS.

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

[0122] For this reason, in one embodiment, the UE 100 receiving the MBS packet from the gNB 200 via the MBS data bearer assumes that the received MBS packet does not have an SDAP header in the SDAP layer, and performs S D.A. The MBS packet (IP packet) is passed to the upper layer without removing the P header.

[0123] This eliminates the need to explicitly set the presence or absence of an SDAP header in the RRC layer for the MBS data bearer. The UE 100 determines that the MBS data bearer is transmitted without an SDAP header, regardless of the setting of the presence of an SDAP header in the RRC. In other words, even if the UE 100 receives setting information (RRC setting information) regarding the setting of the SDAP layer from the gNB 200, the UE 100 does not set the S for the received MBS packet regardless of the setting information. D.A. The MBS packet is passed to the upper layer without removing the P header.

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

[0125] In the case of normal unicast transmission, the gNB200 can multiplex and transmit multiple logical channels corresponding to multiple applications using one C-RNTI (Cell Radio Network Temporary Identifier), i.e., one PDSCH (Physical Downlink Shared Channel).

[0126] In the case of MBS, in PTP transmission, it is considered that MBS packets (logical channel for MBS) and normal unicast packets (logical channel for unicast) can be multiplexed and transmitted using one C-RNTI (one PDSCH), similar to unicast transmission.

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

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

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

[0130] In one embodiment, the gNB 200 maps one or more QoS flows belonging to one MBS session to multiple MBS data bearers in the SDAP layer. Then, the gNB 200 multiplexes and transmits multiple logical channels corresponding to the multiple MBS data bearers in one RNTI (one group RNTI). This allows efficient transmission of multiple logical channels.

[0131] FIG. 13 is a diagram illustrating an example of an operation of multiplexing a plurality of logical channels according to an embodiment.

[0132] As shown in Fig. 13, in the gNB 200 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 equal to or greater than 2. Multiple QoS flows belonging to one MBS session refer to multiple QoS flows associated with one session identifier. The RLC layer of the gNB 200 passes the MBS data of k logical channels corresponding to the k bearers (k RLC channels) to the MAC layer.

[0133] The MAC layer of the gNB 200 multiplexes MBS data of k logical channels with one group RNTI and transmits the multiplexed data. Specifically, the physical (PHY) layer of the gNB 200 transmits allocation information of a PDSCH carrying the MBS data to the UE 100 by a PDCCH (Physical Downlink Control Channel) to which one group RNTI is applied.

[0134] In this way, gNB200 multiplexes and transmits different logical channels in one group RNTI only when different QoS flows mapped to different logical channels are associated with one MBS session.

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

[0136] Here, since these k logical channels are transmitted with the same group RNTI, the UE 100 may determine that these logical channels are associated with one MBS session.

[0137] Then, the SDAP layer of the UE 100 passes the MBS data of the k bearers (multiple QoS flows) to a higher layer (for example, an application layer).

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

[0139] A program may be provided that causes a computer to execute each process performed by the UE 100 or the gNB 200. The program may be recorded in a computer-readable medium. Using the computer-readable medium, it is possible to install the program in the 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, and may be, for example, a recording medium such as a CD-ROM or a DVD-ROM.

[0140] In addition, circuits that execute each process performed by UE100 or gNB200 may be integrated, and at least a part of UE100 or gNB200 may be configured as a semiconductor integrated circuit (chip set, SoC).

[0141] The above describes the embodiments in detail with reference to the drawings, but the specific configuration is not limited to that described above, and various design changes, etc. are possible without departing from the spirit of the invention.

[0142] This application claims priority to U.S. Provisional Application No. 63 / 093386 (filed October 19, 2020), the entire contents of which are incorporated herein by reference. [Explanation of symbols]

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

Claims

1. 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, comprising: receiving an MBS packet from the base station by the user equipment; A PDCP (Packet Data Convergence Protocol) entity of the user equipment sets an initial value of a PDCP variable used for receiving window control based on a PDCP sequence number included in an MBS packet first received from the base station; The PDCP variable is at least one of a sequence number of a PDCP SDU that is expected to be received next and a sequence number of the oldest PDCP SDU that is waiting to be received and has not yet been provided to an upper layer. Communications control method.

2. A receiver for receiving a Multicast Broadcast Service (MBS) packet from a base station; A control unit that sets an initial value of a PDCP variable used for receiving window control based on a PDCP (Packet Data Convergence Protocol) sequence number included in an MBS packet first received from the base station, The PDCP variable is at least one of a sequence number of a PDCP SDU that is expected to be received next and a sequence number of the oldest PDCP SDU that is waiting to be received and has not yet been provided to an upper layer. User equipment.

3. A processor for controlling a user equipment, receiving a Multicast Broadcast Service (MBS) packet from a base station; and setting an initial value of a PDCP (Packet Data Convergence Protocol) variable used for receiving window control based on a PDCP sequence number included in the MBS packet first received from the base station; The PDCP variable is at least one of a sequence number of a PDCP SDU that is expected to be received next and a sequence number of the oldest PDCP SDU that is waiting to be received and has not yet been provided to an upper layer. Processor.

Images