Communication control method, base station, user equipment, and processor

Abstract

Provided is a communication control method to be used in a mobile communications system that provides Multicast and Broadcast Services (MBS) from a base station to a user device. In this method, the user device, which receives MBS data via an MBS communication path, transmits, to the base station, notification information for notifying the base station of a request from the user device related to the settings of a unicast communication path associated with the MBS communication path.

Description

[Technical Field]

[0001] The present invention relates to a communication control method used 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.2.0 (2020-07)" Summary of the Invention

[0004] The communication control method of the 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 user device receiving MBS data via an MBS communication path transmitting notification information to the base station to notify the user device of its wishes regarding the setting up of a unicast communication path associated with the MBS communication path.

[0005] The communication control method of the 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 MBS data via an MBS bearer transmitting feedback information to the base station to identify target MBS data, which is the MBS data that was unsuccessfully received; and the base station retransmitting the target MBS data to the user device based on the feedback information using a unicast bearer associated with the MBS bearer.

[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, and includes the base station transmitting MBS data via an MBS bearer setting a logical channel identifier related to the MBS to the user device. [Brief explanation of the drawings]

[0007] [Figure 1] 1 is a diagram illustrating a configuration of a mobile communication system according to an embodiment. [Figure 2] 1 is a diagram illustrating a configuration of a UE (user equipment) according to an embodiment. [Figure 3] A diagram showing the configuration of a gNB (base station) according to an embodiment. [Figure 4] FIG. 10 is a diagram showing the configuration of a protocol stack of a radio interface of a user plane that handles data. [Figure 5] FIG. 1 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 illustrating a correspondence relationship between downlink logical channels and transport channels according to the embodiment. [Figure 7] FIG. 10 is a diagram illustrating an overview of an operation according to an embodiment. [Figure 8]FIG. 10 is a diagram illustrating an example of an operation according to an embodiment. [Figure 9] FIG. 10 illustrates an example of a retransmission operation using a unicast bearer according to one embodiment. [Figure 10] FIG. 10 is a diagram illustrating a specific example of a retransmission operation using a unicast bearer according to one embodiment. [Figure 11] FIG. 10 is a diagram illustrating an operation according to the first modification. [Figure 12] FIG. 10 is a diagram illustrating an operation according to a second modified example. [Figure 13] FIG. 10 is a diagram illustrating an operation according to a third modified example. DETAILED DESCRIPTION OF THE INVENTION

[0008] The introduction of multicast and broadcast services into the 5G system (NR) is being considered. The NR multicast and broadcast services are expected to provide improved services compared to the LTE multicast and broadcast services.

[0009] Therefore, an object of the present disclosure is to realize an improved multicast / broadcast service.

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

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

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

[0013] 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).

[0014] The NG-RAN 10 includes a base station (called a "gNB" in a 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 a 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, etc. 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 that performs wireless communication with a UE 100. One cell belongs to one carrier frequency.

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

[0016] 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 NAS (Non-Access Stratum) signaling. The UPF controls data forwarding. The AMF and UPF are connected to the gNB 200 via an NG interface, which is an interface between a base station and a core network.

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

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

[0019] 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 a radio signal received by the antenna into a baseband signal (received signal) and outputs the baseband signal to the control unit 130.

[0020] The transmitting unit 120 performs various transmissions under the control of the control unit 130. The transmitting 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.

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

[0022] FIG. 3 is a diagram showing the configuration of a gNB200 (base station) according to the embodiment.

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

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

[0025] 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 a radio signal received by the antenna into a baseband signal (received signal) and outputs the baseband signal to the control unit 230.

[0026] 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 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 processes.

[0027] The backhaul communication unit 240 is connected to neighboring 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., functionally divided), and both units may be connected via an F1 interface.

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

[0029] As shown in Figure 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.

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

[0031] 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 UE 100 and the MAC layer of gNB 200 via a transport channel. The MAC layer of 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 allocated to UE 100.

[0032] The RLC layer transmits data to the RLC layer on the receiving side using the functions of the MAC layer and 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 logical channels.

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

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

[0035] 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).

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

[0037] RRC signaling for various settings is transmitted between the RRC layer of UE100 and the RRC layer of gNB200. 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 UE100 and the RRC of gNB200, UE100 is in an RRC connected state. When there is no connection (RRC connection) between the RRC of UE100 and the RRC of gNB200, UE100 is in an RRC idle state. When the connection between the RRC of UE100 and the RRC of gNB200 is suspended, UE100 is in an RRC inactive state.

[0038] The NAS layer, which is positioned 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 300.

[0039] The UE 100 has an application layer and the like in addition to the radio interface protocol.

[0040] (MBS) Next, an MBS according to an embodiment will be described. The MBS is a service for transmitting data from the NG-RAN 10 to the UE 100 by broadcast or multicast, i.e., point-to-multipoint (PTM) data. The MBS may also be called an MBMS (Multimedia Broadcast and Multicast Service). Note that use cases (service types) of the MBS include public safety communications, mission-critical communications, V2X (Vehicle to Everything) communications, IPv4 or IPv6 multicast distribution, IPTV, group communications, and software distribution.

[0041] 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 the correspondence relationship between downlink logical channels and transport channels according to an embodiment.

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

[0043] The logical channels used for SC-PTM transmission are the 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 the DL-SCH (Downlink Shared Channel). SC-PTM transmission is primarily designed 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 the PDCCH (Physical Downlink Control Channel) and PDSCH (Physical Downlink Shared Channel), which allows for dynamic resource allocation.

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

[0045] In the following description, MBS data refers to data transmitted by MBS, but in the following embodiments, MBS data may be transmitted by unicast. The MBS control channel refers to the MCCH or SC-MCCH, and the MBS traffic channel refers to the MTCH or SC-MTCH.

[0046] The network can provide different MBS services for each MBS session. The MBS service 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 service identifier. Such an MBS service identifier may also be called an MBS session identifier or a multicast group identifier. The MBS service identifier may include a group Radio Network Temporary Identifier (RNTI).

[0047] (Mobile communication system operation) Next, the operation of the mobile communication system will be described, assuming the above-mentioned mobile communication system and MBS.

[0048] (1) Unicast bearer setup operation FIG. 7 is a diagram showing an outline of the operation according to one embodiment.

[0049] As shown in Figure 7, UE 100a and UE 100b establish an MBS bearer with gNB 200. An MBS bearer is a bearer used for MBS transmission and MBS reception of MBS data. The gNB 200 transmits the same MBS data to UE 100a and UE 100b by multicast (or broadcast) via the MBS bearer.

[0050] The UE 100b has established a unicast bearer associated with the MBS bearer with the gNB 200. A unicast bearer is a bearer used for unicast communication. The gNB 200 and the UE 100b perform unicast communication related to the MBS via the unicast bearer. The unicast bearer is used for the following highly reliable MBS delivery.

[0051] The unicast bearer may be used for dual transmission using the MBS bearer and the unicast bearer. The gNB 200 transmits the same MBS data dually using the MBS bearer and the unicast bearer. The cell transmitting the MBS bearer may be different from the cell transmitting the unicast bearer.

[0052] The unicast bearer may be used as an alternative path (alternative transmission path) for the MBS bearer. When it becomes difficult for the UE 100b to continue receiving the MBS via the MBS bearer, the gNB 200 switches the transmission of MBS data to the UE 100b to the unicast bearer.

[0053] The unicast bearer may be used for retransmission of MBS data. The gNB 200 unicasts the MBS data that the UE 100b failed to receive via the MBS bearer to the UE 100b using the unicast bearer.

[0054] In the example shown in Fig. 7, the UE 100a has not established a unicast bearer associated with the MBS bearer with the gNB 200. From the viewpoint of saving radio resources and power consumption, if there is no problem with the MBS reception quality of the UE 100a, it is preferable that the UE 100a not establish a unicast bearer. On the other hand, if the MBS reception quality of the UE 100a has deteriorated, it is preferable that the UE 100a establish a unicast bearer to enable highly reliable MBS reception.

[0055] In one embodiment, the UE 100 receiving MBS data via the MBS bearer transmits notification information to notify the gNB 200 of a preference of the UE 100 regarding the establishment of a unicast bearer associated with the MBS bearer. The notification information is information indicating at least one of a preference of the UE 100 to establish a unicast bearer, a preference for dual reception using the MBS bearer and the unicast bearer, a preference for reception switching from the MBS bearer to the unicast bearer, and a preference for retransmission using the unicast bearer.

[0056] Note that receiving MBS data does not necessarily mean actually receiving the MBS data, but may also mean attempting to receive the MBS data (being interested in receiving the MBS data).

[0057] The UE 100 may transmit the notification information in response to the reception quality falling below a certain standard when receiving an MBS via an MBS bearer.

[0058] The notification information may include at least one of an MBS bearer identifier (bearer identifier), a unicast bearer identifier (bearer identifier), an MBS service identifier corresponding to the MBS data, a cell identifier corresponding to the MBS bearer, a cell identifier corresponding to the unicast bearer, measurement results regarding MBS reception, and information indicating that the MBS reception quality has fallen below a certain standard.

[0059] FIG. 8 is a diagram illustrating an example of an operation according to an embodiment.

[0060] As shown in Fig. 8, in step S101, the gNB 200 performs MBS transmission of MBS data. The UE 100 starts receiving the MBS data. The UE 100 is in an RRC connected state, an RRC idle state, or an RRC inactive state. However, the UE 100 may be in a state where it is interested in receiving MBS data but has not yet started receiving the MBS data. The state where it is interested in receiving MBS data may be a state where a user or an application has requested reception of MBS data.

[0061] In step S102, UE100 transmits notification information to gNB200 to notify UE100 of its wishes regarding the establishment of a unicast bearer associated with the MBS bearer.

[0062] The UE 100 may transmit notification information when the reception quality during MBS reception falls below a certain standard. The reception quality may be reception quality related to packet loss. For example, the reception quality falling below a certain standard refers to the occurrence of a reception error, the packet loss (packet loss rate or packet loss amount) exceeding a threshold, or the number of HARQ NACKs (transmissions) exceeding a threshold. The reception quality may be reception quality related to reception power. For example, the reception quality falling below a certain standard refers to the reception power or reception quality (RSRP, RSRQ, SINR, etc.) falling below a threshold. These thresholds may be set in the UE 100 by the gNB 200 in advance, or the UE 100 may determine the thresholds from QoS parameters of the MBS service. The UE 100 may transmit notification information when the reception quality during MBS reception continues to fall below a certain standard for a certain period of time. This certain period of time may be set in the UE 100 by the gNB 200 in advance. In addition, UE100 may transmit notification information to gNB200 regardless of the MBS reception status.

[0063] The notified information indicates at least one of a desire by the UE 100 to establish a unicast bearer (and / or associate a unicast bearer with an MBS bearer), a desire for duplication reception using an MBS bearer and a unicast bearer, a desire for reception switching from an MBS bearer to a unicast bearer, and a desire for retransmission using a unicast bearer. The desire for dual reception may be a desire for an already established bearer or a desire for a newly established bearer. Instead of a desire for reception switching from an MBS bearer to a unicast bearer, reception switching from a unicast bearer to an MBS bearer may be desired. The notified information may be an information element indicating a desire for high reliability reception (e.g., highReliabilityENUM(true)). Whether high reliability is required may be set by an upper layer (such as an application) of the UE 100. The notified information may be associated with an MBS service identifier (or group RNTI) and / or a bearer identifier (logical channel identifier). The notification information may be "report information that the reception condition of the MBS bearer has deteriorated" rather than notifying a clear preference.

[0064] The notification information may include at least one of the following: target bearer identifier, MBS bearer identifier, unicast bearer identifier (which may be a logical channel identifier), target MBS service identifier, target cell identifier (identifier of the cell corresponding to the current MBS bearer and / or the cell corresponding to the unicast bearer), measurement results (e.g., RSRP / RSRQ / SINR, MBS packet loss, etc.), cause information (e.g., the reception quality during MBS reception has fallen below a certain standard), and the sequence number of the MBS that the user wishes to start receiving.

[0065] When UE 100 is in the RRC connected state, UE 100 may include the notification information in a UE Assistance Information message or an MBS Interest Indication message, which are types of RRC messages, and transmit the message. When UE 100 is in the RRC idle state or the RRC inactive state, UE 100 may include the notification information in Msg3 (RRC Setup Request message or RRC Resume Request message) or Msg5 (RRC Setup Complete message or RRC Resume Complete message), which are messages used in the random access procedure, and transmit the message. In this case, the notification information may be cause information (Cause) to be included in the message. When UE 100 is in the RRC connected state, the RRC idle state, or the RRC inactive state, UE 100 may transmit a random access preamble used in the random access procedure as the notification information. In this case, a dedicated PRACH resource for notification is allocated in advance from gNB 200 to UE 100, for example, by system information.

[0066] In step S103, the gNB 200 performs configuration for the UE 100 based on the notification information from the UE 100. For example, the gNB 200 performs one of the following: configuration for the UE 100 to establish a unicast bearer (and / or associate the unicast bearer with the MBS bearer), configuration for duplication reception using the MBS bearer and the unicast bearer, configuration for reception switching from the MBS bearer to the unicast bearer, and configuration for retransmission using the unicast bearer. If the gNB 200 cannot establish a unicast bearer for the UE 100, it may perform handover of the UE 100. Based on the notification information, the gNB 200 may only take into consideration in scheduling, such as changing the modulation and coding scheme (MCS) for MBS transmission. If the UE 100 is in an RRC idle state or an RRC inactive state, the gNB 200 may establish an RRC connection with the UE 100.

[0067] (2) Retransmission operation using unicast bearer Next, a retransmission operation using a unicast bearer according to one embodiment will be described. Because the above-mentioned duplication of transmission and reception results in poor utilization of radio resources, it is preferable to use the unicast bearer only for retransmission of MBS data during MBS transmission and reception.

[0068] In one embodiment, UE100, which is receiving MBS data via an MBS bearer, transmits feedback information to gNB200 to identify target MBS data, which is MBS data that has failed to be received. Based on the feedback information from UE100, gNB200 retransmits the target MBS data to UE100 by unicast using a unicast bearer associated with the MBS bearer. In this way, gNB200 performs the initial transmission of MBS data by MBS transmission, and uses unicast transmission only for retransmissions when reception of this MBS data fails. This makes it possible to improve the reliability of MBS and the utilization efficiency of radio resources.

[0069] UE100 may transmit feedback information when a certain period of time has passed without receiving MBS data via the MBS bearer, or when the number of packets of MBS data that have failed to be received via the MBS bearer has exceeded a threshold.

[0070] The feedback information may include at least one of sequence number information for identifying MBS data that the UE 100 failed to receive and an identifier related to the MBS bearer.

[0071] 9 is a diagram illustrating an example of a retransmission operation using a unicast bearer according to an embodiment. In this example, it is assumed that the UE 100 is in an RRC inactive state and that an MBS bearer and a unicast bearer have been established.

[0072] 9, in step S201, the gNB 200 performs MBS transmission of MBS data. The UE 100 starts receiving the MBS data.

[0073] In step S202, the UE 100 detects a failure in receiving the MBS data. The UE 100 detects the sequence number of the MBS data (packet) that has failed to be received. No. The detection of a reception failure means that a data decoding error has occurred or the reception waiting timer has timed out.

[0074] In step S203, if a predetermined condition is met, UE100 transmits feedback information based on step S202 to gNB200.

[0075] The predetermined condition is one or a combination of multiple conditions including a condition that a timer has expired, a condition that the number of unsuccessfully received packets (count value) has exceeded a threshold, and a condition that an instruction has been given from a higher layer (e.g., RRC, application).

[0076] Regarding the condition that the timer has expired, the UE 100 restarts the timer (restarts from zero) every time it receives a packet corresponding to MBS data. The timer value may be set by the gNB 200, or may be set to a period during which an upper layer (such as an MBS application) in the UE 100 can wait for the arrival of a packet (for example, a period within which video is not distorted). When the timer value is set by an application, the UE 100 may notify the gNB 200 of the set value in advance.

[0077] Regarding the condition that the number of unsuccessfully received packets (count value) exceeds a threshold, the UE 100 resets (restarts from zero) the number of unsuccessfully received packets (count value) when transmitting feedback information. The threshold may be set to the UE 100 by a higher layer or the gNB 200. The threshold may be zero (i.e., immediate transmission when one packet fails). In other words, the UE 100 may perform a notification when a reception failure occurs.

[0078] Regarding the condition that the instruction is given from a higher layer (e.g., RRC, application), the instruction may be any of the following: an instruction to re-establish or re-configure an entity of a layer (e.g., PDCP) terminating a bearer, an instruction to release a lower layer (e.g., RLC, etc.), an instruction to switch between unicast and MBS, and a data recovery request (e.g., during handover).

[0079] The UE 100 transmits a PDCP status control PDU (Protocol Data Unit) as feedback information to the gNB 200. Alternatively, the UE 100 may transmit an RRC message, a MAC CE (Control Element), or an RLC control PDU as feedback information to the gNB 200. If an MBS layer is present, the UE 100 may transmit an MBS layer control packet to the gNB 200 as feedback information.

[0080] The feedback information includes at least one of sequence number information for identifying MBS data that the UE 100 failed to receive and an identifier related to the MBS bearer. The sequence number information may be a list of packet sequence numbers that failed to be received. The sequence number information may include the sequence number (starting point) at which reception first failed and the number of packets (length of burst failure) at which consecutive reception failures occurred thereafter (which may include the first sequence number). The sequence number information may include the sequence number (starting point) at which reception first failed and bitmap information (e.g., "0": reception failed, "1": reception successful) indicating the reception status of each packet thereafter (which may include the first sequence number). Alternatively, the sequence number information may be information related to packets that were successfully received (e.g., sequence numbers). The identifier related to the MBS bearer may be an MBS service identifier, a group RNTI, a bearer identifier, and / or a logical channel identifier.

[0081] In step S204, the gNB 200 identifies the packets that UE 100 failed to receive based on the feedback information in step S203, and retransmits the packets via the unicast bearer. Here, the gNB 200 may perform the following internal operation. Specifically, when UE 100 performs feedback notification using the timer, the gNB 200 considers that a packet that has elapsed in time after packet transmission has been successfully received by all UEs 100. In other words, the gNB 200 starts a timer for each packet transmission, and when the timer expires, deletes the packet from the retransmission buffer (excludes it from being subject to retransmission).

[0082] The UE 100 attempts to receive the retransmission packet on a unicast bearer. The UE 100 may perform reordering on the received retransmission packet in a termination layer (for example, PDCP).

[0083] Note that, instead of unicast retransmission in step S204, the gNB200 may perform MBS retransmission using an MBS bearer different from the MBS bearer used in step S201. The different MBS bearer may be an MBS bearer dedicated to retransmission, for example, with a low MCS. Alternatively, retransmission may be performed using a bearer (logical channel) for the secondary leg of MBS duplication.

[0084] The gNB200 may also combine the unicast retransmission in step S204 with retransmission of the MBS bearer. For example, packets that many UEs have failed to receive may be retransmitted using an MBS bearer, and packets that few UEs have failed to receive may be retransmitted using a unicast bearer. Here, the MBS bearer may be the same as the MBS bearer used in step S201, or a different MBS bearer (MBS bearer dedicated to retransmission) may be used as described above. Combining these retransmission methods allows more efficient delivery of data to multiple UEs.

[0085] FIG. 10 is a diagram illustrating a specific example of a retransmission operation using a unicast bearer according to an embodiment.

[0086] 10, the gNB 200 and the UE 100 have established an MBS bearer B1 and a unicast bearer B2. Specifically, the MBS bearer B1 and the unicast bearer B2 are established between the PDCP entity of the gNB 200 and the PDCP entity of the UE 100 (i.e., terminated in the PDCP layer).

[0087] In step S301, the PDCP entity of gNB200 transmits PDCP packets "1" to "4" to UE100 via MBS bearer B1. Here, for example, PDCP packet "3" is lost in the wireless section, and the PDCP entity of UE100 successfully receives PDCP packets "1," "2," and "4," but fails to receive PDCP packet "3."

[0088] In step S302, the PDCP entity of UE100 feeds back to gNB200, as feedback information, a PDCP status packet (status control PDU) indicating that reception of PDCP packet "3" has failed.

[0089] In step S303, the PDCP entity of gNB200 retransmits PDCP packet "3" via unicast bearer B2 based on the PDCP status packet from UE100. The PDCP entity of UE100 receives PDCP packet "3" via unicast bearer B2. The PDCP entity of UE100 may perform PDCP packet ordering and discard duplicate packets.

[0090] (Example of change) Next, a modified example of the above-described embodiment will be described, focusing mainly on the differences from the above-described embodiment. The modified example is an example that focuses mainly on the operation of the RLC layer.

[0091] There are three operating modes for the RLC layer: AM (Acknowledged Mode), UM (Unacknowledged Mode), and TM (Transparent Mode). Of these modes, only AM supports a retransmission function using Automatic Repeat reQuest (ARQ). In AM, retransmission control is performed by sending ACK / NACK feedback (specifically, feedback of the STATUS PDU of the RLC layer) from the receiving RLC entity to the transmitting RLC entity.

[0092] In LTE multicast services, the operation mode of the RLC entity is set to UM. However, if a mechanism that enables AM to be applied to NR multicast services can be realized, it is believed that the reliability and flexibility of multicast communication can be improved. For this reason, in this modification, it is assumed that the RLC operates in AM.

[0093] When UE 100 transmits RLC feedback (STATUS PDU) to gNB 200, gNB 200 needs to be able to identify which logical channel identifier the feedback corresponds to. In particular, when gNB 200 is transmitting MBS for multiple MBS services, it is difficult to perform appropriate retransmission control if it is not clear which MBS service the feedback corresponds to.

[0094] In this modification, the gNB 200 that transmits MBS data via the MBS bearer sets a logical channel identifier (LCID) related to the MBS to the UE 100. This enables communication control related to the MBS to be performed in a detailed manner for each logical channel.

[0095] In a modified example, the gNB 200 may set the same logical channel identifier for MBS transmission of MBS data from the gNB 200 to the UE 100 and unicast transmission related to the MBS. This makes it possible to clarify the correspondence relationship between the MBS transmission and the unicast transmission.

[0096] (1) Change example 1 In Modification 1, the gNB 200 sets, in the UE 100, a logical channel identifier for transmitting RLC layer feedback information (STATUS PDU of the RLC layer) for the MBS data from the UE 100 to the gNB 200. This allows the gNB 200 to know the logical channel through which the RLC layer feedback information for the MBS data is transmitted, thereby enabling appropriate retransmission control.

[0097] In Modification 1, the gNB200 sets the same logical channel identifier for MBS transmission of MBS data from the gNB200 to the UE100 and for unicast transmission of the MBS. Specifically, this unicast transmission is for transmitting RLC layer feedback information for the MBS data from the UE100 to the gNB200.

[0098] FIG. 11 is a diagram illustrating the operation according to the first modification.

[0099] 11, the gNB 200 provides two MBS services to the UE 100. One MBS service is assigned an MBS service identifier "TMGI#1", and the other MBS service is assigned an MBS service identifier "TMGI#2".

[0100] gNB200 has a transmitting RLC entity #1 (RLC#1) that transmits MBS data (Multicast data) of "TMGI#1" and a transmitting RLC entity #2 (RLC#2) that transmits MBS data of "TMGI#2". Meanwhile, UE100 has a receiving RLC entity #1 (RLC#1) that receives MBS data of "TMGI#1" and a receiving RLC entity #2 (RLC#2) that receives MBS data of "TMGI#2".

[0101] First, the gNB 200 associates a logical channel identifier for MBS with an MBS service identifier (or group RNTI) and sets it in the UE 100. Figure 11 shows an example in which the gNB 200 sets "LCID#1" as the logical channel identifier corresponding to "TMGI#1" and sets "LCID#2" as the logical channel identifier corresponding to "TMGI#2". In this way, since the logical channel identifier is different for each MBS service identifier, the feedback logical channel identifier is also different, making it possible to identify them.

[0102] The gNB 200 configures the logical channel identifier in the UE 100 by including the logical channel identifier in system information (SIB: System Information Block) transmitted to the UE 100 via a broadcast control channel (BCCH: Broadcast Control Channel), in MBS control information transmitted to the UE 100 via an MBS control channel, or in a message (e.g., an RRC message) transmitted to the UE 100 via UE dedicated signaling. The gNB 200 may configure the UE 100 with a set of the logical channel identifier and an MBS service identifier (e.g., TMGI) and / or group RNTI.

[0103] In Modification 1, one logical channel identifier is used both as the logical channel identifier used for MBS reception and as the logical channel identifier used for uplink transmission for feedback. In Fig. 11, the logical channel identifier "LCID#2" is assigned to the MBS traffic channel (e.g., (SC-)MTCH), which is the logical channel used for MBS reception, and the logical channel identifier "LCID#2" is assigned to the logical channel (e.g., DTCH) used for uplink transmission for feedback. Note that SC-MTCH is an abbreviation for Single Cell Multicast Traffic Channel, and DTCH is an abbreviation for Dedicated Traffic Channel.

[0104] Next, in steps S401 to S403, the RLC entity #2 of the gNB200 transmits MBS data to the UE100 via the MBS traffic channel, and transmits an RLC polling packet to the UE100. Specifically, the gNB200 sets the P (Polling bit) field included in an AMD (Acknowledged Mode Data) PDU to 1 and transmits the RLC polling packet. The RLC entity #2 of the UE100 receives the MBS data and the RLC polling packet from the gNB200.

[0105] In steps S404 to S406, in response to receiving the polling packet, the RLC entity #2 of the UE 100 transmits a STATUS PDU including ACK / NACK information of the MBS data by unicast via the DTCH to the gNB 200. The RLC entity #2 of the gNB 200 receives the STATUS PDU from the UE 100.

[0106] In steps S407 to S409, based on the STATUS PDU, the RLC entity #2 of the gNB 200 retransmits the packet (RLC packet) that the UE 100 failed to receive to the UE 100 by MBS transmission or unicast transmission (DTCH). Here, the MBS control channel ((SC-)MCCH) is used for MBS transmission to retransmit the packet that the UE 100 failed to receive, but the retransmission may also be performed using the MBS traffic channel.

[0107] (2) Change example 2 Modification 2 will be described, focusing mainly on the differences from Modification 1. In Modification 2, the gNB200 sets different logical channel identifiers for MBS transmission of MBS data from the gNB200 to the UE100 and unicast transmission of the MBS. Alternatively, the gNB200 may not assign a logical channel identifier for MBS transmission of MBS data from the gNB200 to the UE100.

[0108] That is, different logical channels are used for MBS transmission of MBS data from gNB200 to UE100 and for unicast transmission of MBS data. Therefore, gNB200 has two RLC entities for one MBS service "TMGI#2", a transmitting RLC entity #1 that performs MBS transmission and a receiving RLC entity #2 that receives feedback information. UE100 has two RLC entities for one MBS service "TMGI#2", a receiving RLC entity #1 that performs MBS reception and a transmitting RLC entity #2 that transmits feedback information.

[0109] Under such a premise, cooperative operation between the receiving RLC entity #1 and transmitting RLC entity #2 in the UE 100 is required to appropriately perform feedback to the gNB 200. In the UE 100, the receiving RLC entity #1 notifies the transmitting RLC entity #2 of the reception status of the MBS data (RLC packets).

[0110] Furthermore, in order to properly perform retransmission to the UE 100, cooperation between the transmitting RLC entity #1 and the receiving RLC entity #2 in the gNB 200 is required. In the gNB 200, the receiving RLC entity #2 notifies the transmitting RLC entity #1 of information on the STATUS PDU from the UE 100.

[0111] FIG. 12 is a diagram showing the operation according to the second modification.

[0112] As shown in FIG. 12, the gNB 200 sets a unicast bearer to the UE 100, and for the unicast bearer, sets up a link between the unicast bearer and the MBS bearer (for feedback transmission) together with the logical channel identifier “LCID#2”. # 2” and the MBS service identifier “TMGI#2”.

[0113] In steps S501 to S503, the RLC entity #1 of the gNB200 transmits MBS data to the UE100 via the MBS traffic channel and transmits an RLC polling packet to the UE100. The RLC entity #1 of the UE100 receives the MBS data and the RLC polling packet from the gNB200.

[0114] In step S504, the RLC entity #1 of the UE 100 notifies the RLC entity #2 corresponding to the linked logical channel identifier "LCID#2" of information for generating a STATUS PDU (for example, ACK / NACK for each sequence number, specifically, information on each field of the RLCSTATUS PDU). This notification may be performed via an upper layer (such as the RRC layer).

[0115] In step S505, the RLC entity #2 of the UE 100 generates a STATUS PDU based on the notification information received from the RLC entity #1, and passes the STATUS PDU to the lower layer (MAC).

[0116] In step S506, the PHY layer of UE100 transmits a STATUS PDU to gNB200 via PUSCH (Physical Uplink Shared CHannel).

[0117] In step S507, the RLC entity #2 of the gNB 200 notifies the corresponding RLC entity #1 for MBS of the information of the STATUS PDU from the UE 100. This notification may be performed via a higher layer (such as an RRC layer).

[0118] In steps S509 to S511, based on the STATUS PDU, the RLC entity #1 of the gNB 200 retransmits the packet (RLC packet) that the UE 100 failed to receive to the UE 100 by MBS transmission. Here, the MBS control channel ((SC-)MCCH) is used for MBS transmission to retransmit the packet that the reception failed to perform, but the retransmission may also be performed using the MBS traffic channel.

[0119] (3) Change example 3 Modification example 3 will be described mainly focusing on the differences from modifications 1 and 2. In modification example 1, the same logical channel identifier was set for MBS transmission of MBS data from gNB200 to UE100 and for feedback transmission from UE100 to gNB200. In contrast, in modification example 3, gNB200 sets the same logical channel identifier for MBS transmission of MBS data from gNB200 to UE100 and for unicast transmission from gNB200 to UE100 (specifically, unicast transmission of MBS data).

[0120] In the third modification, the RLC entity of the gNB 200 maps the MBS data to at least one of the MBS traffic channel and the unicast traffic channel. In this way, the same logical channel is used for MBS transmission and unicast transmission of the MBS data from the gNB 200 to the UE 100, while enabling highly reliable communication using two paths (the MBS traffic channel and the unicast traffic channel).

[0121] FIG. 13 is a diagram showing the operation according to the third modification.

[0122] As shown in Fig. 13, the gNB 200 sets the same logical channel identifier "LCID#3" for the MBS and unicast. This setting method is the same as that in the above-mentioned modification example 1. Note that the gNB 200 may set the MBS logical channel identifier in the MBS control channel, and set the unicast logical channel identifier (the same identifier as the MBS logical channel identifier) ​​in UE dedicated signaling, for example.

[0123] In step S601, the RLC entity #1 of the gNB 200 switches the output path for input data (MBS data). For example, the RLC entity #1 of the gNB 200 maps the data to an MBS traffic channel when transmitting MBS data, and maps the data to a DTCH when transmitting unicast data.

[0124] Here, the RLC entity #1 of the gNB 200 may perform double transmission (duplication transmission). In this case, the RLC entity #1 of the gNB 200 duplicates the RLC PDU and maps one PDU to the MBS traffic channel and the other to the DTCH. Note that the RLC sequence number of the source PDU and the destination PDU are the same (i.e., the duplication is performed after assigning a sequence number).

[0125] In step S602 and / or step S603, the RLC entity #1 of gNB200 passes data (AMD PDU or UMD PDU) to the logical channel to which it is mapped.

[0126] In step S604 and / or step S605, the PHY layer (PHY entity) of the gNB 200 performs PDSCH transmission using the G-RNTI for the MBS traffic channel and the C-RNTI for the DTCH. The PHY layer of the UE 100 performs PHY processing and receives the PDSCH.

[0127] In step S606 and / or step S607, the MAC layer (MAC entity) of the UE 100 performs MAC processing, demaps the data to the MBS control channel and / or DTCH, and passes the data to the RLC entity #1 corresponding to the relevant logical channel identifier.

[0128] In step S608, the RLC entity #1 of the UE 100 performs RLC processing, extracts the MBS data, and passes the data to a higher layer. Here, the RLC entity #1 of the UE 100 collectively performs sequence control, retransmission control, and the like, regardless of the MBS control channel and the DTCH.

[0129] If the polling bit field is "1", in steps S609 to S611, the RLC entity #1 of the UE 100 transmits a STATUS PDU on the DTCH.

[0130] (Other embodiments) The above-described embodiments and modifications are not limited to being implemented independently, but may be implemented in combination of two or more embodiments and / or two or more modifications.

[0131] 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 on a computer-readable medium. Using the computer-readable medium, the program can be installed on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transitory recording medium. The non-transitory recording medium is not particularly limited, and may be, for example, a recording medium such as a CD-ROM or a DVD-ROM.

[0132] 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 (chipset, SoC).

[0133] 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 can be made within the scope that does not deviate from the gist of the invention.

[0134] This application claims priority from Japanese Patent Application No. 2020-133053 (filed August 5, 2020), the entire contents of which are incorporated herein by reference.

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: The base station transmitting MBS data via an MBS bearer transmits an RRC message to the user equipment, the RRC message including an identifier of a logical channel for unicast associated with the MBS bearer and an identifier of a PTM logical channel associated with the MBS bearer. Communication control method.

2. The logical channel for unicast is a logical channel for transmitting feedback information of an RLC (Radio Link Control) layer for the MBS data from the user equipment to the base station. The communication control method according to claim 1 .

3. In the user equipment, a first RLC entity corresponding to the identifier of the PTM logical channel notifies a second RLC entity corresponding to the identifier of the logical channel for unicast of a reception status of the RLC packet of the MBS data. The communication control method according to claim 2 .

4. When the reception quality of the user equipment in an RRC inactive state while receiving the MBS data falls below a threshold, transmitting an RRC Resume Request message including cause information; the user equipment in the RRC inactive state establishing an RRC connection with the base station based on the RRC Resume Request message. The communication control method according to claim 1 .

5. A user device, A receiver receives an RRC message from a base station that transmits Multicast Broadcast Service (MBS) data via an MBS bearer, the RRC message including an identifier of a logical channel for unicast associated with the MBS bearer and an identifier of a PTM logical channel associated with the MBS bearer. User equipment.

6. a processor for controlling a user device, receiving an RRC message from a base station transmitting Multicast and Broadcast Service (MBS) data via an MBS bearer, the RRC message including an identifier of a logical channel for unicast associated with the MBS bearer and an identifier of a PTM logical channel associated with the MBS bearer; Processor.

7. A base station transmitting Multicast and Broadcast Service (MBS) data over an MBS bearer, comprising: a transmitter configured to transmit an RRC message to a user equipment, the RRC message including an identifier of a logical channel for unicast associated with the MBS bearer and an identifier of a PTM logical channel associated with the MBS bearer; Base station.

8. To the user device, receiving an RRC message from a base station transmitting Multicast Broadcast Service (MBS) data via an MBS bearer, the RRC message including an identifier of a logical channel for unicast associated with the MBS bearer and an identifier of a PTM logical channel associated with the MBS bearer; program.

9. A mobile communication system that provides a multicast broadcast service (MBS) from a base station to a user device, comprising: the base station transmitting MBS data via an MBS bearer; The base station transmits to the user equipment an RRC message including an identifier of a logical channel for unicast associated with the MBS bearer and an identifier of a PTM logical channel associated with the MBS bearer. Mobile communication system.

Images