Communication control method, user device, network node, program, chipset, and mobile communication system
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2025-10-27
- Publication Date
- 2026-04-09
AI Technical Summary
Existing multicast and broadcast services in 5G systems face inefficiencies in delivering multicast broadcast services (MBS) due to high power consumption and interrupted unicast communication when receiving MBS traffic in the RRC connected state.
A communication control method that allows for MBS configuration to be partially transmitted by dedicated signaling in the RRC connected state, reducing the need for continuous monitoring of broadcast signaling and minimizing power consumption.
Enables efficient MBS reception in the RRC connected state without interrupting unicast communication, thereby reducing power consumption and maintaining network performance.
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
[Technical Field]
[0001] The present disclosure relates to a communication control method, a base station, a program, a processor, a user device, and 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 base station transmitting an MBS setting including at least information necessary for receiving a broadcast session by broadcast signaling, and the base station transmitting at least a part of the MBS setting to the user device in an RRC (Radio Resource Control) connected state by dedicated signaling.
[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 base station transmitting mode designation information to the user device that specifies either a first delivery mode or a second delivery mode as the delivery mode for the MBS, wherein the first delivery mode is a delivery mode in which MBS settings required for MBS reception are transmitted from the base station to the user device by dedicated signaling, and the second delivery mode is a delivery mode in which the MBS settings are transmitted from the base station to the user device by broadcast signaling.
[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 steps of: the user device transmitting an MBS interest notification message to the base station, the MBS interest notification message including MBS session information related to the user device's desired MBS session; and, if the user device determines that it has not received dedicated signaling from the base station after transmitting the MBS interest notification message, the dedicated signaling including MBS settings required to receive the MBS session, the user device attempts to receive broadcast signaling including the MBS settings.
[0007] A communication control method according to a fourth 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 attempting to receive broadcast signaling including MBS settings required to receive a desired MBS session of the user device; and, if the user device does not receive the broadcast signaling from the base station, sending an MBS interest notification message to the base station that includes MBS session information regarding the desired MBS session. [Brief explanation of the drawings]
[0008] [Figure 1]1 is a diagram illustrating a configuration of a mobile communication system according to an embodiment. [Figure 2] FIG. 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 one 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. 1 is a diagram illustrating an overview of MBS traffic distribution according to one embodiment. [Figure 7] FIG. 10 illustrates a distribution mode according to an embodiment. [Figure 8] FIG. 1 illustrates a split MBS bearer according to one embodiment. [Figure 9] FIG. 10 is a diagram illustrating an example of operation in a first distribution mode according to an embodiment. [Figure 10] FIG. 10 is a diagram illustrating an example of the configuration of an RRC Reconfiguration message according to one embodiment. [Figure 11] FIG. 10 is a diagram illustrating an example of operation in a second distribution mode according to an embodiment. [Figure 12] FIG. 10 is a diagram showing variations of MBS settings in the second distribution mode according to one embodiment. [Figure 13] FIG. 10 is a diagram illustrating an example of the configuration of a broadcast message according to an embodiment. [Figure 14] FIG. 4 is a diagram illustrating an example of an operation of a first operation pattern according to an embodiment. [Figure 15] FIG. 10 is a diagram illustrating an example of an operation of a second operation pattern according to an embodiment. [Figure 16] FIG. 10 is a diagram illustrating an example of an operation of a third operation pattern according to an embodiment. [Figure 17] FIG. 10 is a diagram illustrating an example of an operation of a fourth operation pattern according to an embodiment. [Figure 18]FIG. 10 is a diagram illustrating an example of the structure of a distribution mode 1 setting. [Figure 19] FIG. 1 is a diagram illustrating two-stage configuration in LTE SC-PTM. DETAILED DESCRIPTION OF THE INVENTION
[0009] 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.
[0010] Therefore, an object of the present disclosure is to realize an improved multicast / broadcast service.
[0011] A mobile communication system according to an embodiment will be described with reference to the drawings. In the 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, the configuration of the mobile communication system according to the embodiment will be described.
[0013] 1 is a diagram showing the configuration of a mobile communication system according to an embodiment. This mobile communication system conforms to the 3GPP standard 5th Generation System (5GS). In the following description, 5GS is used as an example, but the mobile communication system may also be at least partially based on an LTE (Long Term Evolution) system and / or a 6th Generation (6G) system.
[0014] 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.
[0015] The UE 100 is a mobile wireless communication device. The UE 100 may be any device used by a user. For example, the UE 100 may be a mobile phone terminal (including a smartphone), a tablet terminal, a laptop 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), and / or an aircraft or a device provided in an aircraft (Aerial UE).
[0016] 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"), and / or a measurement control function for mobility control and scheduling. 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.
[0017] 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.
[0018] 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.
[0019] FIG. 2 is a diagram showing a configuration of a UE 100 (user equipment) according to an embodiment.
[0020] As shown in FIG. 2, the UE 100 includes a receiving unit 110, a transmitting unit 120, and a control unit .
[0021] 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.
[0022] 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.
[0023] 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.
[0024] FIG. 3 is a diagram showing the configuration of a gNB200 (base station) according to one embodiment.
[0025] As shown in FIG. 3, the gNB 200 includes a transmitter 210, a receiver 220, a controller 230, and a backhaul communication unit 240.
[0026] 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.
[0027] 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.
[0028] 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.
[0029] 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.
[0030] FIG. 4 is a diagram showing the configuration of a protocol stack of a radio interface of a user plane that handles data.
[0031] 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.
[0032] 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.
[0033] The MAC layer performs data priority control, retransmission processing using Hybrid Automatic Repeat reQuest (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, which 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.
[0034] 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.
[0035] The PDCP layer performs header compression / decompression and encryption / decryption.
[0036] The SDAP layer maps IP 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 is not necessary.
[0037] 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).
[0038] 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.
[0039] 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.
[0040] The NAS layer 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.
[0041] The UE 100 has an application layer and the like in addition to the radio interface protocol.
[0042] (MBS) Next, an MBS according to an embodiment will be described.
[0043] MBS is a service that enables broadcast or multicast, i.e., point-to-multipoint (PTM) data transmission, from the NG-RAN 10 to the UE 100. Possible use cases (service types) of MBS include public safety communications, mission-critical communications, V2X (Vehicle to Everything) communications, IPv4 or IPv6 multicast distribution, IPTV, group communications, and software distribution.
[0044] The broadcast service is for applications that do not require highly reliable QoS, and provides service to all UEs 100 within a specific service area. An MBS session used for the broadcast service is called a broadcast session.
[0045] A multicast service provides services to a group of UEs 100 participating in the multicast service, rather than to all UEs 100. An MBS session used for a multicast service is called a multicast session. A multicast service can provide the same content to a group of UEs 100 in a more radio-efficient manner than a broadcast service.
[0046] FIG. 6 is a diagram illustrating an overview of MBS traffic distribution according to one embodiment.
[0047] As shown in Figure 6, MBS traffic is distributed from a single data source (application service provider) to multiple UEs. A 5G core network (5G CN (5GC)) 20 receives the MBS traffic from the application service provider, creates copies of the MBS traffic (replication), and distributes the copies.
[0048] From the 5GC20 perspective, two multicast delivery methods are possible: 5GC Shared MBS Traffic delivery and 5GC Individual MBS Traffic delivery.
[0049] In the 5GC individual MBS traffic delivery method, the 5GC 20 receives a single copy of MBS data packets and delivers individual copies of those MBS data packets to individual UEs 100 via a Protocol Data Unit (PDU) session for each UE 100. Therefore, one PDU session for each UE 100 needs to be associated with a multicast session.
[0050] In the 5GC shared MBS traffic delivery method, first, the 5GC 20 receives a single copy of the MBS data packets and delivers the single copy of the MBS data packets to a RAN node (i.e., the gNB 200). Second, the gNB 200 delivers them to one or more UEs 100.
[0051] From the perspective of the RAN (5G RAN) 10, two delivery methods are possible for transmitting MBS traffic over the air in the 5GC shared MBS traffic delivery method: PTP (Point-to-Point) and PTM (Point-to-Multipoint).
[0052] In the PTP distribution method, the gNB 200 distributes individual copies of the MBS data packets wirelessly to each UE 100. On the other hand, in the PTM distribution method, the gNB 200 distributes a single copy of the MBS data packet wirelessly to a group of UEs 100. The gNB 200 dynamically decides whether to use PTM or PTP as the distribution method for MBS traffic to one UE 100.
[0053] The PTP distribution method and the PTM distribution method are mainly related to the user plane. There are two control modes for MBS traffic distribution: a first distribution mode and a second distribution mode. Figure 7 is a diagram showing the distribution modes according to one embodiment.
[0054] As shown in Fig. 7, the first delivery mode (Delivery mode 1) is a delivery mode available to the UE 100 in the RRC connected state, and is a delivery mode for high QoS requirements. The first delivery mode is used only for a multicast session among MBS sessions. In one embodiment, it is assumed that the first delivery mode is used for a multicast session, but the first delivery mode may also be used for a broadcast session. The first delivery mode may also be available to the UE 100 in the RRC idle state or the RRC inactive state.
[0055] In one embodiment, the configuration of MBS reception in the first distribution mode is performed by dedicated signaling (also referred to as "unicast signaling"). Specifically, the configuration of MBS reception in the first distribution mode is performed by an RRC Reconfiguration message (or an RRC Release message), which is an RRC message transmitted by unicast from the gNB 200 to the UE 100. The first distribution mode enables advanced MBS traffic distribution using a split MBS bearer, which will be described later.
[0056] The MBS reception configuration includes MBS traffic channel information (hereinafter referred to as "MTCH information") regarding the MBS traffic channel carrying MBS traffic. The MTCH information includes MBS session information regarding the MBS session and scheduling information (hereinafter referred to as "MTCH scheduling information") for the MBS traffic channel corresponding to the MBS session.
[0057] The MBS traffic channel is a type of logical channel and is sometimes called an MTCH (Multicast Traffic Channel). The MBS traffic channel is mapped to a DL-SCH (Downlink Shared Channel), which is a type of transport channel.
[0058] The second delivery mode (Delivery mode 2) is a delivery mode that can be used not only by UE 100 in the RRC connected state but also by UE 100 in the RRC idle state or RRC inactive state, and is a delivery mode for low QoS requirements. The second delivery mode is used for a broadcast session among MBS sessions. However, the second delivery mode may also be applicable to a multicast session.
[0059] The setting of MBS reception in the second distribution mode is performed by broadcast signaling. Specifically, the setting of MBS reception in the second distribution mode is performed by a logical channel, such as a BCCH (Broadcast Control Channel) or an MCCH (Multicast Control Channel), that is broadcast from the gNB 200 to the UE 100. Hereinafter, such a control channel may be referred to as an MBS control channel.
[0060] The network can provide different MBS services for each MBS session. An MBS session is identified by at least one of a TMGI (Temporary Mobile Group Identity), a session identifier, and a group RNTI (Radio Network Temporary Identifier). At least one of the TMGI and the session identifier is called an MBS session identifier. The TMGI, the session identifier, and the group RNTI are collectively called MBS session information. The MBS session identifier may also be called an MBS service identifier or a multicast group identifier.
[0061] (Split MBS bearer) Next, a split MBS bearer according to one embodiment will be described. The split MBS bearer can be used in the first delivery mode described above.
[0062] The gNB200 can configure the UE100 with an MBS bearer separated into a PTP communication path and a PTM communication path (hereinafter referred to as a "split MBS bearer" as appropriate). This allows the gNB200 to dynamically switch the transmission of MBS traffic to the UE100 between PTP (PTP communication path) and PTM (PTM communication path). Alternatively, the gNB200 can improve reliability by using both PTP and PTM to transmit the same MBS traffic twice. Alternatively, the gNB200 can improve reliability by initially transmitting MBS traffic to multiple UE100 using PTM and retransmitting the MBS traffic to a specific UE100.
[0063] The predetermined layer that terminates splitting is the MAC layer (HARQ), the RLC layer, the PDCP layer, or the SDAP layer. In the following, an example in which the predetermined layer that terminates splitting is the PDCP layer will be mainly described, but the predetermined layer may be the MAC layer (HARQ), the RLC layer, or the SDAP layer.
[0064] 8 is a diagram showing a split MBS bearer according to one embodiment. Hereinafter, a PTP communication path is referred to as a PTP leg, and a PTM communication path is referred to as a PTM leg. Furthermore, a functional unit corresponding to each layer is referred to as an entity.
[0065] 8, each of the PDCP entity of the gNB 200 and the PDCP entity of the UE 100 separates an MBS bearer, which is a bearer (data radio bearer) used for MBS, into a PTP leg and a PTM leg. Note that a PDCP entity is provided for each bearer.
[0066] Each of the gNB 200 and the UE 100 has two RLC entities, one MAC entity, and one PHY entity, each of which is provided for each leg. A PHY entity may be provided for each leg. In the case of dual connectivity in which the UE 100 communicates with two gNBs 200, the UE 100 may have two MAC entities.
[0067] The PHY entity transmits and receives data of the PTP leg using a Cell Radio Network Temporary Identifier (C-RNTI) that is assigned one-to-one to the UE 100. The PHY entity transmits and receives data of the PTM leg using a Group Radio Network Temporary Identifier (G-RNTI) that is assigned one-to-one to the MBS session. The C-RNTI is different for each UE 100, but the G-RNTI is a common RNTI for multiple UEs 100 receiving one MBS session.
[0068] In order to perform PTM transmission (multicast or broadcast) of MBS traffic from the gNB 200 to the UE 100 using a PTM leg, a split MBS bearer must be set from the gNB 200 to the UE 100, and the PTM leg must be activated. In other words, even if a split MBS bearer is set to the UE 100, the gNB 200 cannot perform PTM transmission of MBS traffic using this PTM leg if the PTM leg is in a deactivation state.
[0069] Furthermore, in order for the gNB200 and the UE100 to perform PTP transmission (unicast) of MBS traffic using a PTP leg, a split MBS bearer must be set from the gNB200 to the UE100, and the PTP leg must be activated. In other words, even if a split MBS bearer is set to the UE100, the gNB200 cannot perform PTP transmission of MBS traffic using this PTP leg if the PTP leg is in an inactive state.
[0070] In a state in which the PTM leg is activated, the UE 100 monitors a PDCCH (Physical Downlink Control Channel) to which a G-RNTI associated with the MBS session is applied (i.e., the UE 100 performs blind decoding of the PDCCH using the G-RNTI). The UE 100 may monitor the PDCCH only at a scheduling opportunity for the MBS session.
[0071] When the PTM leg is deactivated, UE 100 does not monitor the PDCCH to which the G-RNTI associated with the MBS session is applied (i.e., does not perform blind decoding of the PDCCH using the G-RNTI).
[0072] UE 100 monitors a PDCCH to which a C-RNTI is applied when a PTP leg is activated. When discontinuous reception (DRX) is configured in a PTP leg, UE 100 monitors the PDCCH in a configured on duration (OnDuration). When a cell (frequency) associated with an MBS session is designated, UE 100 may monitor the PDCCH of the cell even if the cell is deactivated.
[0073] When the PTP leg is deactivated, the UE 100 may monitor the PDCCH to which the C-RNTI is applied in preparation for normal unicast downlink transmission other than MBS traffic. However, when a cell (frequency) associated with an MBS session is specified, the UE 100 may not monitor the PDCCH for the MBS session.
[0074] It is assumed that the split MBS bearer described above is set up by an RRC message (e.g., an RRC Reconfiguration message) sent by the RRC entity of gNB200 to the RRC entity of UE100.
[0075] (An example of the first distribution mode) Next, an example of the first distribution mode will be described.
[0076] 9 is a diagram showing an example of operation in the first distribution mode according to one embodiment, in which non-essential steps are indicated by dashed lines.
[0077] As shown in Fig. 9, in step S11, the UE 100 in the RRC connected state transmits an MBS Interest Indication (MII) message to the gNB 200. The MII message includes MBS session information related to the desired MBS session of the UE 100 (i.e., the MBS session in which the UE 100 is interested in receiving). The gNB 200 learns the desired MBS session of the UE 100 by receiving the MII message. In this operation pattern, the MII message is a type of RRC message.
[0078] In step S12, the gNB 200 transmits MBS configuration required for receiving the desired MBS session of the UE 100 by dedicated signaling. In one embodiment, the dedicated signaling is an RRC Reconfiguration message. However, the dedicated signaling may also be an RRC Release message.
[0079] In step S13, the UE 100 transmits a response message in response to the dedicated signaling received in step S12 to the gNB 200. The response message is, for example, an RRC Reconfiguration Complete message. The gNB 200 receives the response message.
[0080] In step S14, the gNB 200 transmits (e.g., multicasts) MBS traffic via the MTCH in accordance with the MBS configuration set in step S12. Here, the gNB 200 may perform advanced MBS traffic distribution using a split MBS bearer. The UE 100 receives the MBS traffic.
[0081] Fig. 10 is a diagram illustrating a configuration example of an RRC Reconfiguration message according to an embodiment. As illustrated in Fig. 10, the RRC Reconfiguration message transmitted from the gNB 200 to the UE 100 includes, as an information element, an MBS setting required for MBS reception.
[0082] The MBS configuration in the RRC Reconfiguration message includes MTCH information. The MBS configuration in the RRC Reconfiguration message may further include RRC Connected-only configuration that is applicable only to MBS reception in the RRC Connected state.
[0083] The MTCH information may be a common setting for all RRC states (i.e., RRC connected state, RRC idle state, and RRC inactive state). The MTCH information includes MBS session information (at least one of an MBS session identifier and a group RNTI) and MTCH scheduling information. The MTCH scheduling information includes at least one of an MTCH transmission occasion and a transmission BWP (Bandwidth Part).
[0084] Here, the group RNTI is an RNTI commonly assigned to a group of UEs 100. The transmission occasion is a candidate timing (e.g., subframe) at which the gNB 200 transmits MBS traffic using the MTCH. The transmission BWP is a BWP at which the gNB 200 transmits MBS traffic using the MTCH. The BWP is a bandwidth portion narrower than the frequency bandwidth of one cell and is used to limit the operating bandwidth of the UE 100.
[0085] On the other hand, the RRC Connected dedicated configuration includes configuration related to a split MBS bearer, etc. The RRC Connected dedicated configuration includes, for example, at least one of a bearer configuration for a split MBS bearer, a dynamic switching configuration between PTP and PTM, and a PTP leg configuration. Note that the PTM leg configuration can be used in the RRC idle state or the RRC inactive state, and therefore may be included in the MTCH information. The RRC Connected dedicated configuration may include a HARQ feedback configuration.
[0086] (An example of the second distribution mode) Next, an example of the second distribution mode will be described. Fig. 11 is a diagram showing an example of operation of the second distribution mode according to an embodiment. In the second distribution mode, the UE 100 may be in any of the RRC states of an RRC connected state, an RRC idle state, and an RRC inactive state.
[0087] As shown in Fig. 11, in step S21, the gNB 200 transmits MBS settings required for MBS reception by broadcast signaling. The broadcast signaling is signaling that is periodically transmitted by the BCCH and / or the MCCH. In the following, an example in which the broadcast signaling is signaling that is transmitted by the MCCH will be mainly described. The UE 100 receives the broadcast signaling.
[0088] In step S22, the gNB 200 transmits (for example, broadcasts) MBS traffic via the MTCH in accordance with the MBS configuration set in step S21. The UE 100 receives the MBS traffic.
[0089] FIG. 12 is a diagram showing variations of MBS settings in the second distribution mode according to one embodiment.
[0090] As shown in Fig. 12, the gNB 200 provides MCCH scheduling information to the UE 100 through a system information block (SIB) transmitted through the BCCH. The UE 100 receives the MCCH (i.e., MBS configuration) based on the SIB received from the gNB 200, and receives the MTCH (i.e., MBS traffic) based on the received MCCH. Such configuration is sometimes called two-step configuration.
[0091] Alternatively, the gNB 200 may provide the MBS configuration to the UE 100 by an SIB. In this case, the UE 100 receives the MTCH (i.e., MBS traffic) based on the SIB received from the gNB 200. Such configuration may be referred to as one-step configuration.
[0092] The gNB 200 may configure multiple MCCHs within one of its own cells. Each MCCH may have a different scheduling (e.g., transmission period). Any of the MCCHs may be provided on demand in response to a request from the UE 100.
[0093] 13 is a diagram illustrating an example of the configuration of a broadcast message according to an embodiment. The broadcast message corresponds to broadcast signaling that provides an MBS configuration.
[0094] As shown in Figure 13, the broadcast message transmitted from gNB200 to UE100 includes MBS settings required for MBS reception as information elements.
[0095] The MBS setting in the broadcast message includes one or more MTCH information. Figure 13 shows an example in which the broadcast message includes multiple MTCH information corresponding to multiple MBS sessions (multiple MTCHs).
[0096] (First operation pattern) Next, a first operation pattern according to one embodiment will be described.
[0097] As described above, in the second distribution mode, the UE 100 can receive MBS traffic (i.e., receive MBS) in any of the RRC connected state, the RRC idle state, and the RRC inactive state. In addition, in the second distribution mode, the UE 100 needs to monitor periodically transmitted broadcast signaling in order to receive MBS.
[0098] However, when the UE 100 in the RRC connected state attempts to receive MBS traffic delivered in the second delivery mode, it may need to interrupt unicast communication with the gNB 200 and periodically monitor broadcast signaling, which is inefficient. Also, there is a concern that the power consumption of the UE 100 may increase.
[0099] In a first operation pattern according to an embodiment, the gNB 200 transmits an MBS configuration (i.e., an MBS configuration for the second distribution mode) including at least information necessary for receiving a broadcast session by broadcast signaling. The gNB 200 also transmits at least a part of the MBS configuration to the UE 100 in an RRC connected state by dedicated signaling.
[0100] As a result, even when the UE 100 in the RRC connected state attempts to receive MBS traffic delivered in the second delivery mode, the UE 100 can acquire the MBS configuration without interrupting unicast communication with the gNB 200. This can solve the above-mentioned problem.
[0101] Specifically, the UE 100 in the RRC connected state receives the MBS using the MBS configuration transmitted by the dedicated signaling, without periodically monitoring the broadcast signaling.
[0102] 14 is a diagram showing an example of an operation of a first operation pattern according to one embodiment, in which non-essential steps are indicated by dashed lines.
[0103] 14, in step S101, the gNB 200 periodically transmits broadcast signaling including an MBS configuration. The UE 100a in the RRC idle state or the RRC inactive state receives the broadcast signaling.
[0104] In step S102, the UE 100b in the RRC connected state transmits an MII message including MBS session information related to its desired MBS session to the gNB 200. The gNB 200 recognizes the desired MBS session of the UE 100b by receiving the MII message. The UE 100b may establish a session for its desired MBS session in its upper layer (NAS). The AMF may establish a tunnel for the MBS session between the gNB 200 and the UPF.
[0105] In step S103, the gNB 200 transmits an MBS configuration required for receiving the MBS session desired by the UE 100b by dedicated signaling (an RRC Reconfiguration message). Here, the MBS configuration transmitted by the gNB 200 by dedicated signaling is at least a part of the MBS configuration transmitted by the gNB 200 by broadcast signaling. The UE 100b receives the MBS configuration transmitted by the dedicated signaling. Therefore, the UE 100b does not need to periodically monitor the broadcast signaling.
[0106] In step S103, gNB200 may notify UE100b by including notification information in dedicated signaling that it does not need to monitor broadcast signaling.
[0107] In steps S104 and S105, the gNB 200 transmits (for example, broadcasts) MBS traffic via the MTCH in accordance with the MBS configuration of the MBS session configured in steps S101 and S103. The UEs 100a and 100b receive the MBS traffic.
[0108] When the gNB200 changes the scheduling of the MTCH, the gNB200 transmits the changed MTCH scheduling information by broadcast signaling. As a result, the gNB200 updates the MBS setting of the UE100a. When the gNB200 changes the scheduling of the MTCH, the gNB200 transmits the changed MTCH scheduling information to the UE100b by dedicated signaling. As a result, the gNB200 updates the MBS setting of the UE100b.
[0109] The dedicated signaling may include timing information indicating a predetermined timing for applying the MTCH scheduling information. In this case, the UE 100b applies (or activates) the MTCH scheduling information at a predetermined timing after receiving the dedicated signaling. The predetermined timing may be an absolute time such as a system frame number (SFN), a subframe number, and / or a global positioning system (GPS) time, and / or a relative time such as a timer threshold. When a timer is used, the UE 100b starts the timer upon receiving the dedicated signaling and determines the time when the timer expires as the predetermined timing. This prevents timing discrepancies between the UEs 100, even when the gNB 200 configures MTCH scheduling changes for each of multiple UEs 100 by RRC Reconfiguration.
[0110] (Second operation pattern) Next, a second operation pattern according to one embodiment will be described, focusing mainly on the differences from the above-described operation patterns.
[0111] When the gNB 200 provides multiple MBS sessions, some of the MBS sessions may be provided in the first distribution mode (e.g., multicast sessions) and some in the second distribution mode (e.g., broadcast sessions). In this case, it is desirable that the UE 100 be able to appropriately determine whether to receive its desired MBS session in the first distribution mode or the second distribution mode.
[0112] In a second operation pattern according to one embodiment, the gNB200 transmits mode designation information to the UE100, which designates either a first delivery mode or a second delivery mode as the delivery mode for the MBS. Here, the first delivery mode is a delivery mode in which the MBS configuration is transmitted from the gNB200 to the UE100 by dedicated signaling. The second delivery mode is a delivery mode in which the MBS configuration is transmitted from the gNB200 to the UE100 by broadcast signaling.
[0113] For example, the gNB 200 transmits MBS session information related to an MBS session and mode designation information associated with the MBS session information. This allows the UE 100 to appropriately determine whether to receive its desired MBS session in the first delivery mode or the second delivery mode. Specifically, if the UE 100 is interested in receiving the MBS session indicated by the MBS session information received from the gNB 200, the UE 100 receives the MBS configuration in the delivery mode indicated by the mode designation information associated with the MBS session information.
[0114] 15 is a diagram showing an example of an operation of the second operation pattern according to one embodiment, in which non-essential steps are indicated by dashed lines.
[0115] As shown in FIG. 15, in step S201, the gNB 200 transmits MBS session information related to the MBS session and mode designation information associated with the MBS session information to the UE 100. The mode designation information may be, for example, 1-bit flag information that is "1" for the first distribution mode and "0" for the second distribution mode. The mode designation information may be indicated implicitly. For example, no mode designation information is present in the first distribution mode, and mode designation information is present in the second distribution mode. Conversely, mode designation information may be present in the first distribution mode, and mode designation information may not be present in the second distribution mode.
[0116] The mode designation information may be information as to whether the MBS configuration can be received by dedicated signaling or by broadcast signaling, and / or designation (or selection) information as to which signaling the UE 100 should receive the MBS configuration by.
[0117] Such a set of MBS session information and mode designation information is transmitted to UE 100 by any one of an SIB, an MCCH, and an RRC Reconfiguration message. Multiple sets of MBS session information and mode designation information may be included in one message. That is, mode designation information for each of multiple MBS sessions provided by gNB 200 may be notified to UE 100.
[0118] When the UE 100 is in an RRC idle state or an RRC inactive state, the UE 100 can receive the MBS session information and the mode designation information via the SIB or the MCCH. When the UE 100 is in an RRC connected state, the UE 100 can receive the MBS session information and the mode designation information via the SIB, the MCCH, or an RRC Reconfiguration message.
[0119] In step S202, UE100 determines, based on the MBS session information in the message received in step S201, whether its desired MBS session is provided by gNB200. If UE100 determines that its desired MBS session is provided by gNB200, UE100 determines, based on the mode designation information in the message received in step S201, in which of the first delivery mode and the second delivery mode its desired MBS session should be received (step S203).
[0120] When the UE 100 determines that its desired MBS session is to be received in the first delivery mode, it receives an MBS configuration transmitted by dedicated signaling from the gNB 200 (step S204). The UE 100 may notify the gNB 200 of its desired MBS session information to prompt the dedicated signaling transmission. The notification may be the above-mentioned MII.
[0121] On the other hand, when UE100 determines to receive its desired MBS session in the second delivery mode, it receives the MBS configuration transmitted by broadcast signaling from gNB200 (step S205). Assume that this broadcast signaling can be received only in the RRC idle state or the RRC inactive state, and UE100 is in the RRC connected state. In such a case, UE100 transmits to gNB200 a Release Assistance Indication (RAI) message for transitioning to the RRC idle state or the RRC inactive state. As a result, UE100 may receive the broadcast signaling after transitioning to the RRC idle state or the RRC inactive state.
[0122] In step S206, UE100 receives MBS traffic (MTCH) of its desired MBS session based on the MBS configuration received from gNB200.
[0123] (Third movement pattern) Next, a third operation pattern according to one embodiment will be described, focusing mainly on the differences from the above-described operation patterns.
[0124] As described above, there may be a mixture of MBS sessions provided in the first distribution mode (e.g., multicast sessions) and MBS sessions provided in the second distribution mode (e.g., broadcast sessions). In such a case, UE 100 does not know in which distribution mode its desired MBS session will be provided from gNB 200. In this operation pattern, UE 100 first attempts to receive its desired MBS session in the first distribution mode. Next, if this attempt fails, UE 100 assumes that its desired MBS session is provided in the second distribution mode, and attempts to receive its desired MBS session in the second distribution mode.
[0125] That is, in a third operation pattern according to an embodiment, the UE 100 transmits an MII message including MBS session information related to its own desired MBS session to the gNB 200. After transmitting the MII message, if the UE 100 determines that it has not received dedicated signaling including an MBS setting required for receiving its own desired MBS session from the gNB 200, the UE 100 attempts to receive broadcast signaling including the MBS setting.
[0126] Here, if the UE 100 does not receive dedicated signaling including an MBS setting required for receiving the desired MBS session within a predetermined time after transmitting the MII message, the UE 100 may attempt to receive broadcast signaling.
[0127] Alternatively, if UE100 receives information from gNB200 indicating that the MBS settings required to receive the desired MBS session are transmitted by broadcast signaling, UE100 may attempt to receive the broadcast signaling.
[0128] 16 is a diagram showing an example of an operation of a third operation pattern according to one embodiment, in which non-essential steps are indicated by dashed lines.
[0129] In step S301, UE 100 in an RRC connected state transmits an MII message including MBS session information related to its desired MBS session to gNB 200. By receiving the MII message, gNB 200 grasps the desired MBS session of UE 100. UE 100 may establish a session for its desired MBS session in its upper layer (NAS). AMF may establish a tunnel for the MBS session between gNB 200 and UPF.
[0130] In step S302, in response to the transmission of the MII message, the UE 100 may start a timer for timing a predetermined time. This predetermined time (timer value) may be set in advance in the UE 100 by the gNB 200, or may be a predetermined fixed value (for example, four radio frames).
[0131] In step S303, the gNB 200 determines that the desired MBS session of the UE 100 is being provided in the second distribution mode. If the gNB 200 is providing the MBS session information in the first distribution mode, the gNB 200 uses an RRC Reconfiguration message to perform MBS configuration for the first distribution mode for the UE 100. Here, the description will proceed assuming that it has been determined that the desired MBS session is being provided in the second distribution mode.
[0132] In step S304, the gNB 200 transmits a notification to the UE 100 indicating that the desired MBS session of the UE 100 is being provided in the second delivery mode. This notification may be the above-mentioned mode designation information.
[0133] In step S305, UE 100 determines that its desired MBS session is provided in the second delivery mode. For example, if UE 100 does not receive dedicated signaling including MBS settings required for receiving the desired MBS session from gNB 200 within a predetermined time (during timer operation) after transmitting the MII message, UE 100 determines that the desired MBS session is provided in the second delivery mode. In other words, if the timer expires without receiving dedicated signaling including MBS settings required for receiving the desired MBS session, UE 100 determines that the desired MBS session is provided in the second delivery mode. Alternatively, UE 100 may determine that the desired MBS session is provided in the second delivery mode based on the notification of step S304.
[0134] In step S306, UE 100 receives an MBS configuration transmitted by broadcast signaling from gNB 200. Assume that this broadcast signaling can be received only in the RRC idle state or the RRC inactive state, and UE 100 is in the RRC connected state. In this case, UE 100 transmits an RAI message to gNB 200 for transitioning to the RRC idle state or the RRC inactive state. As a result, UE 100 may receive the broadcast signaling after transitioning to the RRC idle state or the RRC inactive state.
[0135] In step S307, UE100 receives MBS traffic (MTCH) of its desired MBS session based on the MBS configuration received from gNB200 in step S306.
[0136] (4th movement pattern) Next, a fourth operation pattern according to one embodiment will be described, focusing mainly on the differences from the above-described operation patterns.
[0137] As described above, there may be a mixture of MBS sessions provided in the first distribution mode (e.g., multicast sessions) and MBS sessions provided in the second distribution mode (e.g., broadcast sessions). In such a case, UE 100 does not know in which distribution mode gNB 200 will provide its desired MBS session. In this operation pattern, UE 100 first attempts to receive its desired MBS session in the second distribution mode. Next, if this attempt fails, UE 100 assumes that its desired MBS session is provided in the first distribution mode, and attempts to receive its desired MBS session in the first distribution mode.
[0138] That is, in a fourth operation pattern according to one embodiment, UE 100 attempts to receive broadcast signaling including MBS settings required for receiving its desired MBS session. If UE 100 does not receive broadcast signaling including the MBS settings from gNB 200, UE 100 transmits an MII message including MBS session information related to the desired MBS session to gNB 200. In this way, in response to receiving the MII message, gNB 200 can transmit the MBS settings required for receiving the desired MBS session to UE 100 by dedicated signaling.
[0139] 17 is a diagram showing an example of an operation of a fourth operation pattern according to one embodiment, in which non-essential steps are indicated by dashed lines.
[0140] In step S401, UE100 receives broadcast signaling including MBS configuration from gNB200.
[0141] In step S402, the UE 100 determines that its desired MBS session is not provided in the second delivery mode based on the broadcast signaling received in step S401. Specifically, the UE 100 determines that the broadcast signaling received in step S401 does not include MTCH information corresponding to its desired MBS session.
[0142] In step S403, UE100 transmits an MII message including MBS session information related to its desired MBS session to gNB200. By receiving the MII message, gNB200 grasps the desired MBS session of UE100. UE100 may establish a session for its desired MBS session in its upper layer (NAS). AMF may establish a tunnel for the MBS session between gNB200 and UPF.
[0143] Note that, if the UE 100 is in an RRC idle state or an RRC inactive state in step S401, prior to step S403, the UE 100 performs a random access procedure for transitioning from the RRC idle state or the RRC inactive state to an RRC connected state with the gNB 200. The UE 100 may notify the gNB 200 of its desired MBS session using a message (for example, Msg1, MsgA, Msg3, or Msg5) transmitted during this random access procedure as an MII message.
[0144] In step S404, the gNB 200 transmits, to the UE 100, dedicated signaling including an MBS configuration required for receiving the desired MBS session of the UE 100. The UE 100 receives the MBS configuration through the dedicated signaling.
[0145] In step S405, UE100 receives MBS traffic (MTCH) of its desired MBS session based on the MBS configuration received from gNB200 in step S404.
[0146] In this operation pattern, instead of setting the MBS in step S404, the gNB 200 may notify the UE 100 that the MBS session will not be provided. Alternatively, the gNB 200 may instruct the UE 100 to receive the MBS session by unicast (the PDU session shown in FIG. 6). In this case, the UE 100 attempts to receive the MBS session by unicast as shown in FIG. 6.
[0147] (Other embodiments) The above-described operation patterns are not limited to being performed independently, but some steps of two or more operation patterns can be combined with each other for execution.
[0148] In the above-described 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). Also, the base station may be a relay node such as an IAB (Integrated Access and Backhaul) node. The base station may be a DU (Distributed Unit) of the IAB node.
[0149] 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.
[0150] 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).
[0151] 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.
[0152] This application claims priority to U.S. Provisional Application No. 63 / 136,486 (filed January 12, 2021), the entire contents of which are incorporated herein by reference.
[0153] (Addendum) (introduction) A revised work item on Multicast Broadcast Service (MBS) for NR was approved. It was agreed to introduce two delivery modes for MBS as follows:
[0154] In Rel-17, R2 specifies the following two modes: 1: Delivery mode for high QoS (reliability, delay) requirements available in Connected (UE may be able to switch to other states if there is no data reception, but this is yet to be determined). 2: Delivery mode for "low" QoS requirements. UE may receive data even when inactive / idle (details to be determined). R2 assumes that (as in R17) delivery mode 1 is used only for multicast sessions. ·R2 assumes that delivery mode 2 is used for broadcast sessions. The applicability of delivery mode 2 to multicast sessions requires further study. No Data: If there is no data ongoing in the multicast session, the UE may remain in RRC Connected. Other cases require further consideration.
[0155] Regarding distribution mode 2, the following MBS setting outline was agreed upon:
[0156] The UE receives the MBS configuration via BCCH and / or MCCH (TBD) (in case of broadcast / distribution mode 2), which can be received in idle / inactive mode. Connected mode requires further study. A notification mechanism is used to notify changes in MBS control information.
[0157] This appendix considers the control plane aspects of NR MBS, taking into account the LTE eMBMS mechanism and the latest RAN2 agreements.
[0158] (Discussion) As agreed upon by RAN2, the two delivery modes at this time are summarized in Table 1.
[0159] [Table 1]
[0160] (Distribution mode 1 setting) Delivery mode 1 is primarily being considered for data reception in RRC Connected, but configuration aspects have not yet been agreed upon. While it may be quite straightforward for MBS configuration to be provided by RRC reconfiguration, receiving MCCH in Connected, like LTE eMBMS, is still under consideration. Given the high QoS expected for delivery mode 1, it should involve, for example, PTP / PTM split bearers and / or lossless handover. Since these UE-specific configurations are meaningless if provided via MCCH, in our view, RRC reconfiguration should be used to configure delivery mode 1.
[0161] Proposal 1: In delivery mode 1, RAN2 should agree to use RRC reconfiguration for MBS configuration.
[0162] On the other hand, WID clearly indicates that RRC Connected and Idle / Inactive should have maximum commonality in terms of MBS configuration, as follows, but RAN2 agreed on separate delivery modes for multicast and broadcast sessions.
[0163] With the aim of maintaining maximum commonality in the configuration of PTM reception between the RRC Connected and RRC Idle / Inactive states, this document specifies the changes required to enable reception of PTM transmissions by UEs in the RRC Idle / Inactive state.
[0164] Even though the RRC messages for these delivery modes are different, to achieve the objective of WID, the structure and IEs of the MBS configuration should be aligned as much as possible between the two delivery modes. For example, the RRC reconfiguration for delivery mode 1 includes delivery mode 1-specific information such as PTP / PTM split bearer and handover-related information in addition to the MTCH scheduling information, which is a common block with delivery mode 2. Therefore, the details require further study at this point.
[0165] Proposal 2: RAN2 should agree to aim for maximum commonality between the two delivery modes in terms of MBS configuration, e.g., by using common structures and IEs.
[0166] 18 indicates only the MTCH scheduling information, i.e., the MTCH configuration related to the MBS session information. In the case of distribution mode 1, neighboring cell information is not required.
[0167] Further study is needed to determine whether a UE can be released to idle / inactive status when there is no ongoing data for a multicast session. In other words, whether an idle / inactive UE can receive MBS data via delivery mode 1 is also needed. As agreed by RAN2, the baseline is that a UE should be kept in delivery mode 1, i.e., RRC connected, for multicast sessions requiring high QoS. However, other / exceptional cases are still worth considering.
[0168] During the email discussion, some companies pointed out that due to congestion, the network may not be able to keep all UEs connected. Other companies also pointed out that UEs do not need to stay connected all the time due to uplink activity, QoS requirements, and / or UE power consumption.
[0169] From the RAN2 perspective, it may be considered beneficial for both the network and the UE to support this feature. It is assumed that whether / when the UE is released to inactive mode is up to the gNB implementation, and whether the UE is released to idle mode is up to the core network. One concern regarding MBS data reception in idle mode is that the gNB releases the UE context, while the UE context is retained in inactive mode. This means that the controllability of the gNB may be lost, which may contradict the general concept of delivery mode 1. Therefore, RAN2 should agree that delivery mode 1 can be received by the UE at least in inactive mode, but further consideration is needed in idle mode.
[0170] Proposal 3: In distribution mode 1, RAN2 should agree that UE can receive distribution mode 1 at least inactively. Further study is needed in idle.
[0171] If proposal 3 is acceptable, it is not clear how the idle / inactive MBS configuration is provided to the UE. Three options are possible:
[0172] Option 1: RRC reconfiguration An idle / inactive UE continues to apply the MBS configuration provided by RRC reconfiguration. This option is simple as the UE simply reuses the MBS configuration originally provided for RRC Connected. However, some UE behavior may need to be considered when transitioning to idle / inactive and / or resuming RRC Connected, e.g., how to handle PTP / PTM split bearer configuration if configured.
[0173] Option 2: RRC Release Idle / inactive UEs apply the MBS configuration provided by RRC release. This option is straightforward but may not be efficient, as it is doubtful whether the MBS configuration will be different from the one previously provided by RRC reconfiguration.
[0174] Option 3: Switching the distribution mode from Mode 1 to Mode 2 The UE is switched from distribution mode 1 to distribution mode 2 before being released to idle / inactive. This option is another simple solution, as distribution mode 2 is designed to be able to receive data in all RRC states as agreed by RAN2. However, packet loss and / or delays can be expected during switching, e.g., due to MCCH acquisition.
[0175] Each option has its advantages and disadvantages, but in our view, Option 1 is slightly preferable from the perspective of simplicity and efficiency. RAN2 should consider, but not be limited to, the above options and discuss how to provide a delivery mode 1 configuration for data reception in idle / inactive mode.
[0176] Proposal 4: If Proposal 3 can be agreed upon, RAN2 should discuss how the UE is provided with the delivery mode 1 configuration for inactive data reception.
[0177] (Distribution mode 2 setting) In LTE SC-PTM, configuration is provided by two messages: SIB20 and SC-MCCH. SIB20 provides SC-MCCH scheduling information, and SC-MCCH provides SC-MTCH scheduling information including G-RNTI and TMGI, and neighbor cell information.
[0178] The advantage of the two-stage configuration in LTE as shown in Figure 19 is that SC-MCCH scheduling is independent from SIB20 scheduling in terms of recurrence period, duration, modification period, etc. This facilitates frequent scheduling / updating of SC-MCCH, especially for delay-sensitive services and / or UEs that join the session late. According to WID, this is also true for NR MBS, as one of the applications is group communication, etc.
[0179] Observation 1: In LTE, the two-stage configuration using SIB20 and SC-MCCH lends itself to different scheduling of these control channels, which also lends itself to NR MBS.
[0180] Proposal 5: RAN2 should agree to use a two-stage configuration with different messages for NR MBS, such as SIB20 for SC-PTM and SC-MCCH.
[0181] In addition to Proposal 5, NR MBS is envisioned to support the various types of use cases described in WID. It is noted that NR MBS should be appropriately designed for various requirements, ranging from delay-sensitive applications such as mission-critical and V2X to delay-tolerant applications such as IoT, in addition to other aspects of requirements ranging from lossless applications such as software distribution to UDP-type streaming such as IPTV. Some of these services may be covered by Delivery Mode 2, while other services with "high QoS requirements" require Delivery Mode 1. In this sense, it would be beneficial for gNBs to have the option to use Delivery Mode 2 for multicast sessions.
[0182] Also, since RAN2 has already agreed to allow data reception in RRC Connected, it is easy to allow RRC Connected UEs to receive MBS configuration. It would be pointless if the UE had to transition to idle / inactive just to acquire MCCH. While it is easy to allow Connected UEs to receive MCCH, it may not be optimal in terms of scheduling flexibility (since the UE may need to "gap") and / or UE power consumption (since the UE needs to monitor "SC-RNTI" in addition to C-RNTI and G-RNTI). Therefore, whether the UE receives MBS configuration via MCCH or RRC reconfiguration may require further discussion.
[0183] These two challenges remain, but in general, from our perspective there seems to be no technical reason to limit them.
[0184] Proposal 6: RAN2 should agree that delivery mode 2 can be used for multicast sessions in addition to broadcast sessions.
[0185] Proposal 7: In distribution mode 2, RAN2 should agree that MBS configuration can be received by RRC connected UEs. Whether this should be via MCCH or RRC reconfiguration needs further study.
[0186] In light of Proposal 6, the control channel design for delivery mode 2 should consider flexibility and its resource efficiency. Otherwise, for example, when delay-tolerant and delay-sensitive services are configured together on one control channel, the control channel may need to be scheduled frequently to meet the delay requirements from the delay-sensitive service, which may result in more signaling overhead.
[0187] Objective A of SA2 SI is about enabling general MBS services over 5GS, and identified use cases that may benefit from this capability include (but are not limited to) public safety, mission-critical, V2X applications, transparent IPv4 / IPv6 multicast distribution, IPTV, over-the-air software distribution, group communications, and IoT applications.
[0188] Observation 2: The NR MBS control channel for distribution mode 2 needs to be flexible and resource efficient for different types of use cases.
[0189] One possibility is to consider whether it is necessary to separate the configured channels for different use cases, as shown in Figure 12. For example, one MCCH may frequently provide delay-sensitive services, while another MCCH may sparsely provide delay-tolerant services. In LTE SC-PTM, a cell is limited to having only one SC-MCCH. However, considering that more use cases than LTE are expected, NR MBS distribution mode 2 should remove this limitation. If multiple MCCHs are permitted in a cell, each MCCH has different scheduling settings, such as a recurrence period, that can be optimized for specific services. Further consideration is needed to determine how a UE identifies the MCCH that provides the service of interest.
[0190] Proposal 8: In distribution mode 2, RAN2 should discuss whether multiple MCCHs are supported in a cell, which was not present in LTE.
[0191] Furthermore, a new paradigm in NR is the support of on-demand SI transmission. This concept can be reused for MCCH in distribution mode 2, i.e., on-demand MCCH. For example, MCCH for delay-tolerant services is provided on-demand, thus optimizing signaling resource consumption. Of course, the network has other options to provide MCCH periodically, i.e., not on-demand, for delay-sensitive services, etc.
[0192] Proposal 9: In delivery mode 2, RAN2 should discuss the option of providing MCCH on an on-demand basis, which was not present in LTE.
[0193] Another possibility that may be further considered is merging these messages, i.e., one-stage configuration, as shown in Figure 12. For example, the SIB provides MTCH scheduling information directly, i.e., without the MCCH. This would provide optimization for delay-tolerant services and / or power-sensitive UEs. For example, a UE may request the SIB (on-demand), and the gNB may start providing the SIB and corresponding services after requests from multiple UEs. These UEs do not need to monitor the repeatedly broadcasted MCCH.
[0194] Proposal 10: In distribution mode 2, RAN2 should discuss options such as SIB providing MTCH scheduling information directly if multicast reception without MCCH (i.e., one-stage configuration) is supported.
[0195] (Indication of Interest / Counting) LTE eMBMS specifies two methods for collecting UE's receiving / interested services, i.e., MBMS Interest Indication (MII) and MBMS Counting, to allow the network to make appropriate decisions on MBMS data delivery, including starting / stopping MBMS sessions. The MII triggered by the UE contains information related to the interested MBMS frequencies, interested MBMS services, MBMS priority, and MBMS ROM (Receive Only Mode). The Counting Response triggered by the network via a Counting Request for a specific MBMS service contains information related to the interested MBSFN area and MBMS service.
[0196] These methods were introduced for different purposes: MII is primarily used by the network to ensure that the UE can continue to receive the services it is interested in while in the connected state, while counting is used to allow the network to determine if a sufficient number of UEs are interested in receiving the service.
[0197] Observation 3: In LTE e MBMS, two kinds of UE assistance information are introduced for different purposes: MBMS Interest Indication is introduced for scheduling in the NB, and MBMS Counting is introduced for session control in the MCE.
[0198] For NR MBS, multicast services such as group communication use cases are expected, and the network already has complete knowledge of the MBS services that UEs in the Connected state are receiving / interested in. Therefore, assistance information from the UE, for example, for determining PTP / PTM distribution, is not useful to the network. However, as we understand it, the same does not apply to broadcast services and / or UEs in the Idle / Inactive state. Especially for broadcast services, the problem solved by counting with MII in LTE eMBMS, i.e., Observation 3, still exists in NR MBS. Therefore, RAN2 needs to consider whether assistance information such as MII and counting can be useful for NR MBS.
[0199] Note that MBMS ROM information in MII and information about MBSFN area in Counting Response are not required in Rel-17, since ROM and SFN are not supported as described in WID.
[0200] Proposal 11: RAN2 needs to agree to introduce UE assistance information for NR MBS, e.g., MBS Interest Indication and / or MBS Counting.
[0201] If you agree with Proposal 11, it is worth considering extensions on top of LTE eMBMS. In LTE eMBMS, even if the majority of UEs are in RRC idle state and receiving broadcast services, neither MII nor counting can collect information from idle UEs. In our understanding, this is one of the remaining issues with LTE eMBMS from the perspective of session control and resource efficiency.
[0202] In NR MBS, the same problem can exist for idle / inactive UEs. For example, the network does not know whether idle / inactive UEs are not receiving / interested in the broadcast service. Therefore, the network may continue to provide PTM transmissions even if no UEs are receiving the service. If the gNB is aware of the interest of idle / inactive UEs, such unnecessary PTM should be avoided. Conversely, if PTM is stopped while there are still idle / inactive UEs receiving the service, many UEs may request a connection at the same time, which is also undesirable.
[0203] Therefore, it is worth considering whether to introduce a mechanism to collect UE assistance information, specifically for MBMS counting, from idle / inactive UEs. Obviously, it would be desirable for idle / inactive UEs to be able to report information without transitioning to RRC Connected. This could be achieved, for example, if PRACH resource partitioning associated with MBS services were introduced for such reporting.
[0204] Proposal 12: RAN2 should consider whether UE assistance information such as MBS counting is also collected from UEs in idle / inactive state.
Claims
1. A communication control method to be performed by a user device in a mobile communication system that provides multicast broadcast services (MBS), The MBS configuration, which includes the information necessary to receive the MBS session, is received from the network node via the RRC (Radio Resource Control) Release message, The user device is in an RRC inactive state, and if the MBS settings are changed, the change in the MBS settings is received from the network node via a multicast control channel relating to the MBS session. Communication control method.
2. A user device in a mobile communication system that provides multicast broadcast service (MBS), The system includes a receiving unit that receives MBS settings, which include information necessary for receiving MBS sessions, from a network node via an RRC (Radio Resource Control) Release message. The receiving unit, when the user device is in an RRC inactive state and the MBS settings are changed, receives the change in the MBS settings from the network node via the multicast control channel relating to the MBS session. User device.
3. A network node in a mobile communication system that provides multicast broadcast services (MBS), The system includes a transmission unit that transmits MBS settings, including information necessary for the user device to receive an MBS session, to the user device via an RRC (Radio Resource Control) Release message. The transmitting unit, when the user device is in an RRC inactive state and the MBS settings are changed, transmits the change in the MBS settings to the user device via the multicast control channel for the MBS session. Network node.
4. A user device in a mobile communication system that provides multicast broadcast services (MBS), The process involves receiving MBS settings, including information necessary for receiving an MBS session, from a network node via an RRC (Radio Resource Control) Release message, and If the user device is in an RRC inactive state and the MBS settings are changed, the device will perform the following process: receive the change in MBS settings from the network node via the multicast control channel for the MBS session. program.
5. A chipset for user equipment in a mobile communication system that provides multicast broadcast services (MBS), The MBS configuration, which includes the information necessary to receive the MBS session, is received from the network node via the RRC (Radio Resource Control) Release message, If the user device is in an RRC inactive state and the MBS settings are changed, the device will receive the change in the MBS settings from the network node via the multicast control channel for the MBS session and perform the following actions: Chipset.
6. A mobile communication system that provides multicast broadcast services (MBS), The system comprises user equipment and network nodes. The aforementioned network node is The user device transmits the MBS settings, which include the information necessary for receiving the MBS session, to the user device via an RRC (Radio Resource Control) Release message. If the user device is in an RRC inactive state and the MBS settings are changed, the change in the MBS settings is transmitted to the user device via the multicast control channel for the MBS session. The User device is The network node receives the MBS configuration, which includes the information necessary to receive the MBS session, via the RRCRelease message. If the user device is in an RRC inactive state and the MBS settings are changed, the change in the MBS settings is received from the network node via the multicast control channel for the MBS session. Mobile communication system.