Communication method, network device, mobile communication system, chipset, and program

Abstract

To provide a communication method, a network device, a mobile communication system, a chip set, a program, and a user device capable of smoothing MBS reception.SOLUTION: The communication method includes transmitting, by a second network device, information indicating a support status of a multicast and broadcast service (MBS) function to a first network device, receiving, by the second network device, a paging message for MBS including a TMGI from the first network device after transmitting the information indicating the support status of the MBS function, and transmitting, by the second network device, the paging message including the TMGI to a user equipment in an RRC inactive state or an RRC idle state in response to receiving the paging message for MBS.SELECTED DRAWING: Figure 14

Description

[Technical Field]

[0001] The present disclosure relates to a communication method, a network device, a mobile communication system, a chipset, and a program used in a mobile communication system. [Background technology]

[0002] The 3GPP (3rd Generation Partnership Project) standard defines the technical specifications for NR (New Radio), a fifth-generation (5G) wireless access technology. Compared to LTE (Long Term Evolution), a fourth-generation (4G) wireless access technology, NR offers higher speed, larger capacity, higher reliability, and lower latency. 3GPP is currently discussing the formulation of technical specifications for multicast and broadcast services (MBS) in 5G systems (see, for example, Non-Patent Document 1). [Prior art documents] [Non-patent literature]

[0003] [Non-Patent Document 1] 3GPP contribution: RP-201038, “WID revision: NR Multicast and Broadcast Services” Summary of the Invention

[0004] A communication method according to a first aspect is a communication method executed by a user equipment in a mobile communication system, the communication method including: receiving, while in an RRC inactive state, a paging message including a TMGI from a base station; and, if the user equipment has joined an MBS session indicated by the TMGI, initiating a procedure for transitioning from the RRC inactive state to an RRC connected state.

[0005] A user equipment according to a second aspect is a user equipment for use in a mobile communication system, and includes: a receiver that receives a paging message including a TMGI from a base station when the user equipment is in an RRC inactive state; and a controller that initiates a procedure for transitioning from the RRC inactive state to an RRC connected state when the user equipment participates in an MBS session indicated by the TMGI.

[0006] A communication method according to a third aspect is a communication method used in a mobile communication system, comprising: a first network device included in a network of the mobile communication system receiving a message from a second network device included in the network, the message including MBS capability information regarding whether the second network device supports a Multicast Broadcast Service (MBS) function; the first network device generating a first paging message based on the MBS capability information, the first network device using the first paging message to notify the start of an MBS session; and the first network device transmitting the first paging message to the second network device.

[0007] A network device according to a fourth aspect is a network device included in a network of a mobile communication system, and has a receiving unit that receives a message from another network device included in the network, the message including Multicast Broadcast Service (MBS) capability information regarding whether the other network device supports an MBS function, a control unit that generates a first paging message used to notify the start of an MBS session based on the MBS capability information, and a transmitting unit that transmits the first paging message to the other network device. [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] 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. 2 is a diagram illustrating a configuration of an AMF (management device) according to an embodiment. [Figure 5] FIG. 10 is a diagram showing the configuration of a protocol stack of a radio interface of a user plane that handles data. [Figure 6] 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 7] FIG. 1 is a diagram illustrating an overview of MBS traffic distribution according to an embodiment. [Figure 8] FIG. 10 is a diagram illustrating a distribution mode according to the embodiment. [Figure 9] FIG. 1 is a diagram illustrating a split multicast radio bearer (MRB) according to an embodiment. [Figure 10] FIG. 10 is a diagram illustrating an operation related to group notification according to the embodiment. [Figure 11] FIG. 2 is a diagram illustrating an operation of the mobile communication system according to the first embodiment. [Figure 12] FIG. 2 is a diagram illustrating a first example of the first embodiment. [Figure 13] FIG. 10 is a diagram illustrating a second example of the first embodiment. [Figure 14] FIG. 10 is a diagram illustrating a third example of the first embodiment. [Figure 15] FIG. 10 is a diagram illustrating an operation of the mobile communication system according to the second embodiment. [Figure 16] FIG. 10 is a diagram illustrating a specific example of an operation in the second embodiment. [Figure 17] This is a diagram showing option A in the appendix. [Figure 18] FIG. 10 is a diagram showing option B in the appendix. DETAILED DESCRIPTION OF THE INVENTION

[0009] In MBS, it is believed that MBS reception, particularly reception of multicast sessions, can be facilitated by utilizing a paging mechanism to notify user equipment in an RRC (Radio Resource Control) idle state or an RRC inactive state of the start of an MBS session.

[0010] Therefore, the present disclosure provides a communication method, a network device, and a user device that utilize a paging mechanism to facilitate MBS reception.

[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] [First embodiment] (Configuration of a mobile communication system) FIG. 1 is a diagram showing the configuration of a mobile communication system according to a first embodiment. The mobile communication system 1 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 applied to an LTE (Long Term Evolution) system. The mobile communication system may also be at least partially applied to a sixth generation (6G) system.

[0013] The mobile communication system 1 includes a user equipment (UE) 100, a 5G radio access network (NG-RAN) 10, and a 5G core network (5GC) 20. Hereinafter, the NG-RAN 10 may be simply referred to as the RAN 10. The 5GC 20 may be simply referred to as the core network (CN) 20.

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

[0015] The NG-RAN 10 includes a base station (called 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.

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

[0017] The 5GC20 includes an Access and Mobility Management Function (AMF) and a User Plane Function (UPF) 300. The AMF performs various mobility controls for the UE 100. The AMF manages the mobility of the UE 100 by communicating with the UE 100 using 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.

[0018] 2 is a diagram showing the configuration of a UE 100 (user equipment) according to the first embodiment. The UE 100 includes a receiving unit 110, a transmitting unit 120, and a control unit 130. The receiving unit 110 and the transmitting unit 120 constitute a wireless communication unit that performs wireless communication with the gNB 200.

[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 and processes in the UE 100. Such processes include processes of each layer, which will be described later. The control unit 130 includes at least one processor and at least one memory. The memory stores programs executed by the processor and information used in the processes 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] 3 is a diagram showing the configuration of the gNB200 (base station) according to the first embodiment. The gNB200 includes a transmitter 210, a receiver 220, a controller 230, and a backhaul communication unit 240. The transmitter 210 and the receiver 220 constitute a wireless communication unit that performs wireless communication with the UE 100. The backhaul communication unit 240 constitutes a network communication unit that performs communication with the CN20.

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

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

[0025] The control unit 230 performs various controls and processes in the gNB 200. Such processes include processes for each layer, which will be described later. The control unit 230 includes at least one processor and at least one memory. The memory stores programs executed by the processor and information used in the processes 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.

[0026] The backhaul communication unit 240 is connected to neighboring base stations via an Xn interface, which is an interface between base stations. The backhaul communication unit 240 is connected to the AMF / UPF 300 via an NG interface, which is an interface between a base station and a core network. Note that the gNB 200 may be configured (i.e., functionally divided) with a CU (Central Unit) and a DU (Distributed Unit), and both units may be connected via an F1 interface, which is a fronthaul interface.

[0027] 4 is a diagram showing the configuration of the AMF 300A (management device) according to the first embodiment. The AMF 300A includes a communication unit 310 and a control unit 320.

[0028] The communication unit 310 is connected to the gNB 200 via an NG interface, which is an interface between a base station and a core network. The communication unit 310 communicates with the gNB 200.

[0029] The control unit 320 performs various controls and processes in the AMF 300A. Such processes include the processes of each layer, which will be described later. The control unit 320 includes at least one processor and at least one memory. The memory stores programs executed by the processor and information used in the processes by the processor. The processor may include a CPU. The CPU executes programs stored in the memory to perform various processes.

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

[0031] 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 UE100 and the PHY layer of gNB200 via a physical channel. The PHY layer of UE100 receives downlink control information (DCI) transmitted from gNB200 on a physical downlink control channel (PDCCH). Specifically, UE100 performs blind decoding of the PDCCH using a radio network temporary identifier (RNTI) and acquires successfully decoded DCI as DCI addressed to the UE. The DCI transmitted from gNB200 has CRC parity bits scrambled by the RNTI added.

[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 UE100 and the MAC layer of gNB200 via transport channels. The MAC layer of gNB200 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 UE100.

[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, encryption / decryption, etc.

[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. 6 is a diagram showing the configuration of a protocol stack of a radio interface of a control plane that handles signaling (control signals).

[0038] 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 300A. Note that the UE 100 has an application layer and the like in addition to a radio interface protocol.

[0041] (MBS Overview) An overview of the MBS according to the first embodiment will be described. The 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 the MBS include public safety communications, mission-critical communications, V2X (Vehicle to Everything) communications, IPv4 or IPv6 multicast distribution, IPTV (Internet Protocol Television), group communications, and software distribution.

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

[0043] A multicast service provides a service not to all UEs 100 but to a group of UEs 100 participating in the multicast service (multicast session). 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 wirelessly efficient manner than a broadcast service.

[0044] FIG. 7 is a diagram showing an outline of MBS traffic distribution according to the first embodiment.

[0045] MBS traffic (MBS data) is distributed from a single data source (application service provider) to multiple UEs. A 5G core network (5GC) 20 receives the MBS data from the application service provider, creates a copy of the MBS data (replication), and distributes it.

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

[0047] 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 PDU session for each UE 100. Therefore, one PDU session for each UE 100 needs to be associated with the multicast session.

[0048] In the 5GC shared MBS traffic delivery method, the 5GC 20 receives a single copy of MBS data packets and delivers the single copy of those MBS packets to a RAN node (i.e., the gNB 200). The gNB 200 receives the MBS data packets via an MBS tunnel connection and delivers them to one or more UEs 100.

[0049] From the perspective of the RAN (5G RAN) 10, there are two possible delivery methods for transmitting MBS data over the air in the 5GC shared MBS traffic delivery method: PTP (Point-to-Point) and PTM (Point-to-Multipoint). PTP stands for unicast, and PTM stands for multicast and broadcast.

[0050] In the PTP distribution method, the gNB 200 distributes individual copies of the MBS data packet 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 can dynamically determine whether to use PTM or PTP as the distribution method for MBS data for one UE 100.

[0051] The PTP distribution method and the PTM distribution method are mainly related to the user plane. There are two control modes for MBS data distribution: a first distribution mode and a second distribution mode.

[0052] FIG. 8 is a diagram showing distribution modes according to the first embodiment.

[0053] The first delivery mode (Delivery mode 1) is a delivery mode that can be used by the UE 100 in the RRC connected state and is a delivery mode for high QoS requirements. The first delivery mode is used for a multicast session among MBS sessions. However, 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.

[0054] The setting of MBS reception in the first distribution mode is performed by UE-dedicated signaling. For example, the setting 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.

[0055] The MBS reception configuration includes MBS traffic channel configuration information (hereinafter referred to as "MTCH configuration information") related to the configuration of an MBS traffic channel carrying MBS data. The MTCH configuration information includes MBS session information related to an MBS session and scheduling information for the MBS traffic channel corresponding to this MBS session. The scheduling information for the MBS traffic channel may include a discontinuous reception (DRX) configuration for the MBS traffic channel. The discontinuous reception configuration may include one or more parameters: a timer value (On Duration Timer) defining an on-duration (on duration), a timer value (Inactivity Timer) extending the on-duration, a scheduling interval or DRX cycle (Scheduling Period, DRX Cycle), a start subframe offset value (Start Offset, DRX Cycle Offset) for the scheduling or DRX cycle, a start delay slot value (Slot Offset) for the on-duration timer, a timer value (Retransmission Timer) defining the maximum time until retransmission, and a timer value (HARQ RTT Timer) defining the minimum interval until DL allocation for HARQ retransmission.

[0056] The MBS traffic channel is a type of logical channel and is sometimes referred to as an MTCH. The MBS traffic channel is mapped to a downlink shared channel (DL-SCH), which is a type of transport channel.

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

[0058] The setting of MBS reception in the second distribution mode is performed by broadcast signaling. For example, the setting of MBS reception in the second distribution mode is performed by a logical channel broadcast from the gNB 200 to the UE 100, such as a broadcast control channel (BCCH) and / or a multicast control channel (MCCH). The UE 100 can receive the BCCH and the MCCH using, for example, a dedicated RNTI predefined in a technical specification. The RNTI for BCCH reception may be SI-RNTI, and the RNTI for MCCH reception may be MCCH-RNTI.

[0059] In the second distribution mode, UE100 may receive MBS data in the following three procedures. First, UE100 receives MCCH configuration information via a SIB (MBS-SIB) transmitted on a BCCH from gNB200. Second, UE100 receives an MCCH from gNB200 based on the MCCH configuration information. The MCCH transmits the MTCH configuration information. Third, UE100 receives an MTCH (MBS data) based on the MTCH configuration information. Hereinafter, MTCH configuration information and / or MCCH configuration information may be referred to as MBS configuration information.

[0060] In the first distribution mode and the second distribution mode, the UE 100 may receive the MTCH using a group RNTI (G-RNTI) assigned by the gNB 200. The G-RNTI corresponds to an RNTI for MTCH reception. The G-RNTI may be included in the MBS reception configuration (MTCH configuration information).

[0061] The network can provide different MBS services for each MBS session. An MBS session is identified by at least one of a Temporary Mobile Group Identity (TMGI), a source-specific IP multicast address (consisting of a source unicast IP address of an application function, application server, etc., and an IP multicast address indicating the destination address), a session identifier, and a G-RNTI. At least one of the TMGI, the source-specific IP multicast address, and the session identifier is called an MBS session identifier (MBS session ID). The TMGI, the source-specific IP multicast address, the session identifier, and the G-RNTI are collectively called MBS session information.

[0062] 9 is a diagram illustrating a split multicast radio bearer (MRB) according to the first embodiment. The MRB may be a type of data radio bearer (DRB). The split MRB may be used in the first delivery mode described above.

[0063] The gNB200 can configure the UE100 with an MRB separated into a PTP communication path and a PTM communication path. This allows the gNB200 to dynamically switch the transmission of MBS data to the UE100 between PTP (PTP communication path) and PTM (PTM communication path). Alternatively, the gNB200 can improve reliability by dual-transmitting the same MBS data using both PTP (PTP communication path) and PTM (PTM communication path). Hereinafter, the PTP communication path will be referred to as a PTP leg, and the PTM communication path will be referred to as a PTM leg. Furthermore, the functional units corresponding to each layer will be referred to as entities.

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

[0065] The PDCP entity of the gNB 200 and the PDCP entity of the UE 100 each separate an MRB, 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 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 data from the gNB 200 to the UE 100 using a PTM leg, a split MRB must be configured from the gNB 200 to the UE 100, and the PTM leg must be activated. In other words, even if a split MRB is configured in the UE 100, the gNB 200 cannot perform PTM transmission of MBS data 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 data using a PTP leg, a split MRB must be configured from the gNB200 to the UE100, and the PTP leg must be activated. In other words, even if a split MRB is configured in the UE100, the gNB200 cannot perform PTP transmission of MBS data 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 to which a G-RNTI associated with an MBS session is applied (i.e., performs blind decoding of the PDCCH using the G-RNTI). The UE 100 may monitor the PDCCH only at scheduling opportunities 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 during a configured on validity period (OnDuration). When a cell (frequency) associated with an MBS session is specified, UE 100 may monitor the PDCCH of the cell even if the cell is deactivated.

[0073] In a state in which the PTP leg is deactivated, the UE 100 may monitor a PDCCH to which a C-RNTI is applied in preparation for normal unicast downlink transmission other than MBS data. 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 MRB as described above is configured by an RRC message (e.g., an RRC Reconfiguration message) sent by the RRC entity of gNB200 to the RRC entity of UE100.

[0075] 10 is a diagram showing operations related to group notification according to the first embodiment. Here, it is mainly assumed that in the first delivery mode, UE100 in the RRC connected state receives MBS data (i.e., multicast data) transmitted by multicast from gNB200. For this reason, it is assumed that the MBS session is a multicast session. The multicast session is mapped to a PTM leg or a PTM bearer (MRB). The MBS traffic channel (MTCH) is used to transmit the multicast data from the gNB200 to UE100.

[0076] After joining the multicast session, UE 100 transitions to an RRC idle state or an RRC inactive state and waits for the start of the multicast session. UE 100 receives, in the RRC idle state or the RRC inactive state, a group notification indicating the start (activation) of the multicast session in which UE 100 is participating, which is transmitted from the network to the group to which UE 100 belongs. The group notification is assumed to be a type of paging message. UE 100 transitions to an RRC connected state in response to receiving the group notification, and receives multicast data of the multicast session from gNB 200.

[0077] Hereinafter, the RAN 10 (gNB 200) and the CN 20 (especially the AMF 300A) will be collectively referred to as the "network" as appropriate. The AMF 300A is an example of a core network (CN) device. The AMF 300A manages MBS sessions (multicast sessions) in cooperation with a session management device. The session management device may be a (MB-)SMF.

[0078] In step S1, the UE 100 is in an RRC connected state. The UE 100 is assumed to have an interest in a certain multicast session (hereinafter referred to as a "target multicast session"). "Interested in a multicast session" means that an upper layer of the UE 100 requests or desires to receive the multicast session. The upper layer includes a NAS layer. The upper layer may further include an application.

[0079] In step S2, UE 100 (NAS entity) performs a multicast session join procedure with the network to join the targeted multicast session. For example, UE 100 joins the targeted multicast session by sending a first NAS message to AMF 300A requesting participation in the targeted multicast session and receiving a second NAS message from AMF 300A approving participation in the targeted multicast session. "Joining the targeted multicast session" means registering UE 100 with the CN device as a member of a UE group (multicast group) that receives the multicast session. Note that participation in a multicast session may be performed when the multicast session is in an enabled state (transmitting). Participation in a multicast session may also be performed when the multicast session is in an disabled state (waiting for transmission to start or transmission suspended).

[0080] In step S3, UE 100 transitions to an RRC idle state or an RRC inactive state. Specifically, UE 100 transitions to the RRC idle state or the RRC inactive state by receiving an RRC release message from gNB 200. Prior to step S3, UE 100 may transmit to gNB 200 an RRC message (e.g., a UE Assistance Information message) including an information element prompting UE 100 to transition to the RRC idle state or the RRC inactive state. gNB 200 may determine to transition UE 100 to the RRC idle state or the RRC inactive state depending on whether a multicast session in which UE 100 is interested is in an invalid state.

[0081] In step S4, the UE 100 starts monitoring for a group notification from the gNB 200. The group notification may be a paging message transmitted from the gNB 200. For example, the UE 100 monitors for the group notification at a paging occasion (PO) of a paging frame (PF) that is set periodically. The group notification may notify the start of a session of a multicast session. The session start may be the activation of a multicast session from a disabled state.

[0082] In step S5, the gNB 200 transmits a group notification addressed to a group including the UE 100 or a group in which the UE 100 is interested. The gNB 200 may transmit a group notification (paging message) to the UE 100 in response to a paging request (group notification request) from the AMF 300A. The group notification may include at least one of a multicast session identifier indicating the group, an identifier of each UE belonging to the group, and a multicast session identifier associated with the identifier. The UE 100 that receives the group notification including such an identifier can recognize that the target multicast session in which it has joined has started. The start of the target multicast session may mean that transmission of multicast data has been enabled in the target multicast session. The start of the target multicast session may mean that transmission of multicast data in the target multicast session has become possible to start.

[0083] In step S6, UE100 performs a random access procedure with gNB200 to receive the target multicast session.

[0084] In step S7, the UE 100 transitions to an RRC connected state by a random access procedure.

[0085] In step S8, the UE 100 receives multicast data of the target multicast session from the gNB 200 in the RRC connected state. Before receiving the data, the gNB 200 may perform a setting for the UE 100 to receive the target multicast session. The setting is, for example, an RRC Reconfiguration message including an MRB setting.

[0086] (Mobile communication system operation) The operation of the mobile communication system 1 according to the first embodiment will be described.

[0087] In the above-described operation related to the group notification, if the gNB 200 does not have the MBS function, it cannot properly handle the group notification (specifically, a paging message including an MBS session identifier) ​​from the AMF 300A. In this case, the AMF 300A may transmit to the gNB 200 a paging message including an identifier of the UE 100 participating in the multicast session, instead of a paging message including an MBS session identifier.

[0088] As a result, when a multicast session is started, a gNB200 that supports the MBS function transmits a paging message including an MBS session identifier as a group notification, and a gNB200 that does not support the MBS function transmits a paging message including a UE identifier as a group notification. Therefore, if the AMF300A does not know whether the gNB200 supports the MBS function, there is a problem that the AMF300A cannot generate an appropriate paging message.

[0089] Note that paging initiated by the AMF 300A is called CN paging. CN paging is mainly used to call the UE 100 in the RRC idle state. In contrast, paging initiated by the RAN 10 (gNB 200) is called RAN paging. RAN paging is used to call the UE 100 in the RRC inactive state. It is considered that the above-mentioned problems also occur in RAN paging.

[0090] FIG. 11 is a diagram showing the operation of the mobile communication system 1 according to the first embodiment.

[0091] In step S11, a first NW device included in a network (NW) of the mobile communication system 1 receives a message from a second NW device included in the NW, the message including MBS capability information regarding whether the second NW device supports a multicast broadcast service (MBS) function.

[0092] In step S12, the first NW device generates a first paging message used to notify the start of an MBS session based on the MBS capability information received in step S11. For example, the first NW device generates a first paging message including an MBS session identifier indicating an MBS session in response to the MBS capability information indicating that the second NW device supports the MBS function. On the other hand, the first NW device generates a first paging message including a UE identifier indicating UE 100 participating in the MBS session in response to the MBS capability information indicating that the second NW device does not support the MBS function.

[0093] In step S13, the first NW device transmits the first paging message generated in step S12 to the second NW device. The second NW device transmits a second paging message via wireless communication based on the first paging message from the first NW device. The second paging message may be a type of RRC message.

[0094] This allows the first NW device to appropriately generate a paging message to be used as a group notification depending on whether the second NW device supports the MBS function. Therefore, by utilizing the paging mechanism, it is possible to appropriately notify the UE 100 in the RRC idle state or the RRC inactive state of the start of an MBS session, thereby facilitating MBS reception, particularly reception of a multicast session.

[0095] In step S11, if the second NW device does not support the MBS function, the first NW device may receive a message including MBS capability information indicating that the second NW device does not support the MBS function, thereby clearly understanding that the second NW device does not support the MBS function.

[0096] The first NW device may be the AMF 300A (management device) included in the CN 20. The second NW device may be the gNB 200 included in the RAN 10. The AMF 300A may receive a message including MBS capability information over the NG interface between the AMF 300A and the gNB 200. This enables the AMF 300A to appropriately generate a CN paging message (first paging message) to be used as group notification depending on whether the gNB 200 supports the MBS function.

[0097] In this embodiment, the communication unit 310 of the AMF 300A constitutes a receiver that receives a message from the gNB 200, the message including MBS capability information regarding whether the gNB 200 supports the MBS function. The control unit 320 of the AMF 300A generates a CN paging message (first paging message) used to notify the start of an MBS session based on the MBS capability information. The communication unit 310 of the AMF 300A constitutes a transmitter that transmits the first paging message to other NW devices.

[0098] Alternatively, the first NW device may be a gNB 200 included in the RAN 10. The second NW device may be a neighboring gNB 200 included in the RAN 10. The gNB 200 may receive a message including MBS capability information over the Xn interface between the gNB 200 and the neighboring gNB 200. This enables the gNB 200 to appropriately generate and transmit a RAN paging message (first paging message) to be used as group notification depending on whether the neighboring gNB 200 supports the MBS function. For example, the gNB 200 transmits, as the first paging message, a RAN paging message including an MBS session identifier indicating the MBS session to be started to the neighboring gNB 200 that supports the MBS function.

[0099] In this embodiment, the backhaul communication unit 240 of the gNB 200 constitutes a receiver that receives a message from a neighboring gNB 200, the message including MBS capability information indicating whether the neighboring gNB 200 supports the MBS function. The control unit 230 of the gNB 200 generates a RAN paging message (first paging message) used to notify the start of an MBS session based on the MBS capability information. The communication unit 310 of the AMF 300A constitutes a transmitter that transmits the first paging message to other network devices.

[0100] Alternatively, the first NW device may be a CU included in the gNB200. The second NW device may be a DU included in the gNB200. The CU may receive a message including MBS capability information over the F1 interface between the CU and the DU. This enables the gNB200 to appropriately generate and transmit a paging message (first paging message) used as group notification depending on whether neighboring gNB200s support the MBS function. Note that the DU includes lower layers in the above-mentioned protocol stack (e.g., RLC layer, MAC layer, and PHY layer). The CU includes upper layers in the above-mentioned protocol stack (e.g., RRC layer, SDAP layer, and PDCP layer).

[0101] The message including the MBS capability information may be a setup message used to set up a network interface (e.g., an NG interface, an Xn interface, or an F1 interface). This allows the first NW device to know the MBS-related capabilities of the second NW device when setting up the network interface with the second NW device.

[0102] The message including the MBS capability information may be a configuration update message used for updating the configuration of the second NW device, so that the first NW device can grasp the MBS-related capabilities of the second NW device when updating the configuration of the second NW device.

[0103] The MBS capability information may include at least one of information indicating the presence or absence of an MBS function, information indicating the presence or absence of a function to perform MBS reception setting by UE 100-dedicated signaling (e.g., a function of the first distribution mode), information indicating the presence or absence of a function to perform MBS reception setting by broadcast signaling (e.g., a function of the second distribution mode), information indicating the presence or absence of a function to distribute a multicast session (e.g., a function of the first distribution mode), information indicating the presence or absence of a function to distribute a broadcast session (e.g., a function of the second distribution mode), and information indicating the presence or absence of a function to handle split MRBs. The MBS capability information may include this information for each cell managed by the second NW device. This allows the first NW device to grasp detailed MBS-related capabilities for each cell of the second NW device.

[0104] (Example) Next, based on the above-described configuration and operation, first to third examples of the first embodiment will be described. These examples are not limited to being implemented independently, but may be implemented by combining two or more examples. Furthermore, in the operational flow of each example, it is not necessary to execute all steps, and only some of the steps may be executed. Furthermore, the order of the steps in the operational flow of each of the following examples may be changed.

[0105] (1) First Example 12 is a diagram illustrating a first example of the first embodiment. In the first example, the first NW device is an AMF 300A (management device) included in the CN 20, and the second NW device is a gNB 200 included in the RAN 10. The first example is an example related to CN paging.

[0106] In step S101, the gNB 200 transmits an NG SETUP REQUEST message to the AMF 300A to set up an NG interface with the AMF 300A. The NG SETUP REQUEST message may include at least one piece of capability information from among information indicating support for the MBS function, information indicating support for each of the first distribution mode function and the second distribution mode function, and information indicating support for each of the multicast session distribution and broadcast session distribution functions. The NG SETUP REQUEST message may include information associating the above capability information with a cell (cell identifier). For example, the NG SETUP REQUEST message may include a set of a cell identifier and capability information for each cell managed by the gNB 200. Instead of the NG SETUP REQUEST message, the capability information (and a cell identifier) ​​may be included in a RAN CONFIGURATION UPDATE message.

[0107] AMF300A determines the MBS capabilities of gNB200 through messages from gNB200.

[0108] In step S102, the AMF 300A transmits an NG SETUP RESPONSE message to the gNB 200. The NG SETUP RESPONSE message may include at least one of the following information for the AMF 300A (CN 20): information indicating that the MBS function is supported, information indicating that the multicast session distribution function / broadcast session distribution function is supported, information indicating that 5GC shared MBS traffic distribution (Shared delivery) is supported, and an MBS session identifier during or before distribution. The AMF 300A may transmit this information to the gNB 200 by including it in a RAN CONFIGURATION UPDATE ACKNOWLEDGE message or an AMF CONFIGURATION UPDATE message instead of the NG SETUP RESPONSE message.

[0109] In step S103, AMF 300A determines (detects) the start of an MBS session by receiving an MBS session start notification from the (MB-)SMF. The MBS session start notification may be an MBS Session Notification Request message for starting multicast. The MBS session start notification may be an MBS Session Resource Setup Request message for starting broadcast.

[0110] In step S104, the AMF 300A generates a PAGING message (first paging message) to be transmitted to the gNB 200. If the gNB 200 supports the MBS function, the AMF 300A includes an MBS session identifier (Session ID, TMGI, Source Specific IP Multicast Address, etc.) in the PAGING message. Alternatively, another message (for example, a newly defined message) may be used instead of the PAGING message. If the gNB 200 does not support the MBS function, the AMF 300A includes in the PAGING message an identifier (5G-S-TMSI) of the UE 100 in CM_IDLE state participating in the MBS session. Note that these identifiers may be included in the message in list format (multiple identifiers).

[0111] In step S105, AMF300A sends the PAGING message to gNB200.

[0112] In step S106, based on the information in the PAGING message, the gNB 200 transmits a paging message (second paging message) to the UE 100 via RRC. The second paging message includes an MBS session identifier of the MBS session to be started or a UE identifier of the UE 100 participating in the MBS session.

[0113] Upon receiving the second paging message from the gNB200, the UE100 checks whether the second paging message contains an MBS session identifier of the MBS session in which the UE100 is participating (i.e., an MBS session in which the UE100 is interested in receiving) or its own UE identifier. If such an identifier is contained in the second paging message, the UE100 starts an operation to receive MBS data of the MBS session. For example, the UE100 performs a random access procedure with the gNB200 to transition to an RRC connected state (step S107), and receives MBS reception configuration (MTCH configuration) from the gNB200 by UE-dedicated RRC signaling (e.g., an RRC Reconfiguration message) (step S108). The UE100 then receives the MBS data from the gNB200.

[0114] In addition, if gNB200 does not support the MBS function, UE100 may receive MBS data using a unicast PDU session shown in Figure 7.

[0115] (2) Second Example 13 is a diagram illustrating a second example of the first embodiment. In the second example, the first NW device is gNB200A, and the second NW device is gNB200B that is adjacent to gNB200A. The second example is an example related to RAN paging.

[0116] In step S201, the gNB200B sends an XN SETUP REQUEST message to the gNB200A to set up an Xn interface with the gNB200A. The XN SETUP REQUEST message may include at least one of capability information: information indicating support for the MBS function; information indicating support for the first distribution mode function / the second distribution mode function; information indicating support for the multicast session distribution function / the broadcast session distribution function; PTP / PTM function; and information indicating support for split MRB. The XN SETUP REQUEST message may also include information associating the capability information with a cell (cell identifier). For example, the XN SETUP REQUEST message may include a set of a cell identifier and capability information for each cell managed by the gNB200B. The XN SETUP REQUEST message may also include information regarding the MBS session being provided by the gNB200B, such as at least one of an MBS session identifier, a serving cell ID, and a distribution mode. Instead of the XN SETUP REQUEST message, the capability information may be included in the NG-RAN NODE CONFIGURATION UPDATE message.

[0117] gNB200A learns of gNB200B's MBS capabilities through messages from gNB200B.

[0118] In step S202, gNB200A sends an XN SETUP RESPONSE message to gNB200B. The XN SETUP RESPONSE message may include the capability information and cell identifier (but information about gNB200A) as described above. Instead of the XN SETUP RESPONSE message, the capability information (and cell identifier) ​​may be included in an NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message.

[0119] In step S203, the gNB200A detects the start of an MBS session by receiving a notification of the start of an MBS session from the AMF300A (for example, a PAGING message for group notification or an MBS Session Start message). The gNB200A detects from the UE context information it holds that the UE100 interested in the MBS session is in an RRC inactive state. Note that the gNB200 has previously received information on the UE100 participating in the MBS session from the CN20, and is aware of the MBS interest information for each UE100.

[0120] In step S204, the gNB200A decides to perform RAN paging and generates a RAN PAGING message (Xn-AP) to transmit to the gNB200B. If the gNB200B supports the MBS function, the gNB200A includes in the RAN PAGING message an MBS session identifier (Session ID, TMGI, Specific IP Multicast Address, etc.) of the MBS session. Alternatively, a different message (e.g., a newly defined message) may be used instead of the RAN PAGING message. If the gNB200B does not support the MBS function, the gNB200A includes in the message a UE identifier (I-RNTI) of the UE100 in an RRC inactive state that is participating in the MBS session. Note that these identifiers may be included in the message in list format (multiple identifiers).

[0121] In step S205, gNB200A transmits the RAN PAGING message (first paging message) to gNB200B.

[0122] In step S206, based on the information in the RAN PAGING message, the gNB 200B transmits a paging message (second paging message) via RRC to the UE 100. The second paging message includes an MBS session identifier of the MBS session to be started or a UE identifier of the UE 100 participating in the MBS session.

[0123] The operations in steps S207 to S209 are the same as those in the first embodiment.

[0124] (3) Third Example 14 is a diagram illustrating a third example of the first embodiment. In the third example, the first NW device is a CU201 of a gNB200, and the second NW device is a DU202 of the gNB200.

[0125] In step S301, the DU 202 transmits an F1 SETUP REQUEST message to the CU 201 to set up an F1 interface with the CU 201. The F1 SETUP REQUEST message may include at least one of capability information, such as information indicating support for the MBS function, information indicating support for the first distribution mode function / the second distribution mode function, information indicating support for the multicast session distribution function / the broadcast session distribution function, the PTP / PTM function, and information indicating support for split MRB. The F1 SETUP REQUEST message may include information associating the capability information with a cell (cell identifier). For example, the DU 202 may include a set of a cell identifier and capability information for each cell managed by the DU 202. Instead of the F1 SETUP REQUEST message, the capability information (and a cell identifier) ​​may be included in a GNB-DU CONFIGURATION UPDATE message.

[0126] In step S302, the CU 201 sends an F1 SETUP RESPONSE message to the DU 202. The F1 SETUP RESPONSE message may include the capability information as described above. Instead of the F1 SETUP RESPONSE message, the capability information of the CU 201 may be included in a GNB-CU CONFIGURATION UPDATE message.

[0127] The CU201 obtains the MBS capability of the DU202 through a message from the DU202, and obtains capability information for the gNB200 as a whole. The CU201 uses this information to communicate with the AMF300A in the first embodiment or with neighboring gNB200 in the second embodiment. The CU201 may control not to use split MRB configuration for DU202 that does not support the MBS function. The CU201 may execute the paging procedure (steps S303 to S309) based on the MBS capability of the DU202, as in the first and second embodiments.

[0128] [Second embodiment] The second embodiment will be described mainly focusing on the differences from the first embodiment described above.

[0129] In the first embodiment described above, based on a group notification (second paging message) from the gNB 200, multiple UEs 100 may simultaneously initiate a random access procedure. Specifically, multiple UEs 100 may transmit random access preambles to the gNB 200 on a physical random access channel (PRACH). Such random access is generally contention-based random access, and PRACH resources (particularly, random access preambles) may compete among the UEs 100. When such competition occurs, the UEs 100 cannot transition to the RRC connected state and cannot receive the multicast session delivered in the first delivery mode.

[0130] Meanwhile, in LTE, a technique has been introduced in which UE 100 performs cell reselection using a paging message in order to distribute the load among cells (see, for example, 3GPP TS36.304 and TS36.331). Such a technique is sometimes called MCLD (multi-carrier load distribution), particularly one-shot MCLD. MCLD allows multiple UEs 100 in one cell to be distributed to other frequencies or other cells, and is therefore considered to be able to suppress the above-mentioned PRACH contention. In the second embodiment, it is mainly assumed that a request to perform cell reselection (cell reselection by MCLD) and group notification are performed using the same paging message.

[0131] In such a case, if the UE 100 prioritizes the group notification and starts the random access procedure without performing cell reselection, it is not possible to suppress PRACH contention. Therefore, when a request to perform cell reselection and group notification are performed in the same paging message, the UE 100 starts the random access procedure after performing cell reselection.

[0132] FIG. 15 is a diagram showing the operation of the mobile communication system 1 according to the second embodiment.

[0133] In step S21, UE100, which is in an RRC idle state or an RRC inactive state, receives a paging message from gNB200, which includes request information requesting cell reselection and an information element (hereinafter referred to as a "predetermined information element") for determining whether UE100 needs to transition to an RRC connected state.

[0134] In step S22, the UE 100 determines that it is necessary to transition to the RRC connected state based on a predetermined information element included in the paging message received in step S21. For example, the predetermined information element is an MBS session identifier indicating the MBS session to be started. The UE 100 determines that it is necessary to transition to the RRC connected state if it is interested in receiving the MBS session indicated by the MBS session identifier included in the paging message. Alternatively, the predetermined information element may be the UE identifier of the UE to be called. The UE 100 determines that it is necessary to transition to the RRC connected state if the UE identifier included in the paging message matches its own UE identifier.

[0135] In step S23, the UE 100 performs cell reselection in response to the request information included in the paging message received in step S21. For example, the UE 100 probabilistically selects a target for cell reselection from among candidate cells or candidate frequencies based on its own unique identifier. Information on the candidate cells or candidate frequencies may be provided to the UE 100 in a system information block from the gNB 200. Each candidate cell or each candidate frequency may be associated with an adjustment value that adjusts the probability that the candidate cell or candidate frequency is selected. The UE 100 selects a target for cell reselection based on a value calculated from its own unique identifier and the adjustment value, and performs cell reselection to the selected target by setting the selected target to the highest priority for cell reselection.

[0136] In step S24, the UE 100 starts a procedure (random access procedure) for transitioning to an RRC connected state in the reselected cell.

[0137] In this way, when the execution request for cell reselection and the group notification are performed in the same paging message, the UE 100 can suppress PRACH contention by starting the random access procedure after performing cell reselection, thereby enabling smooth MBS reception.

[0138] FIG. 16 is a diagram showing a specific example of the operation in the second embodiment.

[0139] In step S2001, gNB200 decides to send a group notification (paging) to notify the start of an MBS session, for example, in response to receiving a PAGING message from AMF300A.

[0140] In step S2002, the gNB 200 detects that the PRACH capacity of its own cell is insufficient. For example, the gNB 200 detects from its own UE context information that the number of UEs 100 waiting for the start of the MBS session in an RRC idle state or an RRC inactive state exceeds a certain threshold (e.g., set by OAM). Then, the gNB 200 decides to perform PRACH distribution (MCLD).

[0141] In step S2003, the gNB 200 transmits a paging message via RRC. The paging message includes request information (Redistribution Indication) instructing one-shot MCLD (cell reselection) and an MBS session identifier or UE identifier for group notification. The UE 100 receives the paging message.

[0142] In step S2004, the UE 100 detects that the received paging message includes both an instruction to start an MBS session that the UE 100 is interested in (calling) and an instruction to perform one-shot MCLD (cell reselection). The UE 100 first selects a cell (target) according to the MCLD setting.

[0143] In step S2005, the UE 100 performs cell reselection.

[0144] In step S2006, the UE 100 transitions to the RRC connected state by performing a random access procedure in the reselected cell. For example, the UE 100 transmits a PRACH (Msg1), receives a random access response (Msg2), transmits an RRC Setup Request message or an RRC Resume Request message (Msg3), and receives Contention resolution (Msg4) in this order.

[0145] In step S2007, the gNB 200 transmits an RRC Reconfiguration message for configuring an MRB to the UE 100. Alternatively, the gNB 200 may hand over the UE 100 to an appropriate cell (MBS serving cell).

[0146] In step S2008, the UE 100 receives the MBS data.

[0147] [Other embodiments] In the above-described embodiment and example, an example has been described in which the first NW device changes the content of the paging message (group notification) transmitted to the second NW device depending on whether the second NW device supports the MBS function. However, the present invention is not limited to this. The first NW device may change the content of the UE context transmitted to the second NW device depending on whether the second NW device supports the MBS function. For example, when the gNB 200 supports the MBS function, the AMF 300A may transmit to the gNB 200 information indicating whether the gNB 200 is participating in an MBS session as a UE context. Alternatively, when the neighboring gNB 200B supports the MBS function, the gNB 200A may transmit interest information regarding the UE's MBS session to the neighboring gNB 200B in the UE context transfer during handover.

[0148] Furthermore, the first NW device may determine whether to establish an MBS session or perform handover, depending on the detailed MBS capability information of the second NW device. For example, the AMF 300A may determine whether to establish a multicast session (whether to send a multicast session establishment request) and / or whether to establish a broadcast session (whether to send a broadcast session establishment request) to the gNB 200. Alternatively, the gNB 200A may determine whether to execute handover of a UE receiving an MBS session to the neighboring gNB 200B.

[0149] The above-mentioned operational flows are not limited to being implemented independently, but can also be implemented by combining two or more operational flows. For example, some steps of one operational flow may be added to another operational flow, or some steps of one operational flow may be replaced with some steps of another operational flow.

[0150] In the above-described embodiment and example, 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) or a 6G base station. The base station may also be a relay node such as an IAB (Integrated Access and Backhaul) node. The base station may also be a DU of the IAB node. The user equipment may also be an MT (Mobile Termination) of the IAB node.

[0151] A program may be provided that causes a computer to execute each process performed by UE100 or gNB200. 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 DVD-ROM. Furthermore, 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).

[0152] As used in this disclosure, the terms "based on" and "depending on" do not mean "based only on" or "depending only on," unless expressly stated otherwise. The term "based on" means both "based only on" and "based at least in part on." Similarly, the term "depending on" means both "based only on" and "at least in part on." Furthermore, "obtain" may mean obtaining information from stored information, obtaining information from information received from another node, or obtaining information by generating the information. The terms "include," "comprise," and variations thereof do not mean including only the listed items, but may also mean including only the listed items or including additional items in addition to the listed items. Furthermore, as used in this disclosure, the term "or" is not intended to mean an exclusive or. Furthermore, any reference to elements using designations such as "first," "second," etc., as used in this disclosure does not generally limit the quantity or order of those elements. These designations may be used herein as a convenient method of distinguishing between two or more elements. Thus, reference to first and second elements does not imply that only two elements may be employed therein or that the first element must precede the second element in some manner. In this disclosure, where articles are added by translation, such as a, an, and the in English, these articles shall include the plural unless the context clearly indicates otherwise.

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

[0154] This application claims priority to U.S. Provisional Application No. 63 / 228257 (filed August 2, 2021), the entire contents of which are incorporated herein by reference.

[0155] [Note] (introduction) A revised work item on NR Multicast and Broadcast Services (MBS) was approved in RAN#88. The group notice was discussed in RAN2#113bis-e and the following agreement was reached:

[0156] MBS support node multicast support group notification In distribution mode 1, the UE is not expected to monitor the RRC Connected group notification channel. Further study is needed to determine whether RAN2 needs to handle the PRACH capacity issue due to group notification. The same group notification ID is used for both the RRC idle and RRC inactive states. Reply LS For non-supporting nodes, using the MBS session ID will not work as it will impact non-MBS nodes. Unicast paging will work.

[0157] To support the nodes, it is possible to use the MBS session ID.

[0158] Short post email discussion for LS's reply.

[0159] RAN2#114-e uses paging messages for group notification.

[0160] Use PCCH for multicast activation notification (also used for MBS support nodes).

[0161] Verify that the MBS session ID is conveyed in the notification.

[0162] The use of paging in all (legacy) POs using PRNTI is a baseline assumption (other variations can be discussed).

[0163] This appendix explains the details of group notification and PRACH capacity issues.

[0164] (Discussion) Group notification in distribution mode 1 Checking the Baseline Assumptions RAN2 agreed that "use of PCCH for multicast activation notification (even for MBS support nodes)" and "use of paging in all (legacy) POs using PRNTI is the baseline assumption (other modifications can be discussed)." These can be interpreted as the need to extend legacy paging for group notification. This extension is intended to be similar to the ETWS / CMAS notification concept in LTE. These agreements are beneficial for power consumption from the UE perspective and have little impact on paging resource load from the NW perspective.

[0165] Finding 1: Observation 1The baseline assumptions made by RAN2 are beneficial for UE power consumption and have negligible impact on paging resource load.

[0166] In RAN2#114-e, some companies supporting individual P-RNTIs, individual POs, and / or individual paging messages have expressed concerns about the potential impact of increasing UE power consumption, especially for legacy UEs. The impact of the RAN2 baseline (i.e., Finding 1) on legacy UEs should be analyzed in comparison with MBS services provided via unicast (i.e., PDU sessions). This is because this was the only methodology up to Rel-16. With unicast, all UEs interested in MBS services must be paged using the legacy mechanism, i.e., one-by-one paging. These unicast paging messages are received by legacy UEs and consume additional power proportional to the number of unicast paging transmissions from UEs interested in the MBS service. Therefore, sending a group notification to all legacy POs using the legacy P-RNTI in a single paging DRX cycle is expected to have a similar impact on legacy UEs and may even be beneficial for power savings when there are many UEs interested in the MBS service.

[0167] Observation 2: Power consumption for legacy UEs is not an issue with group notification.

[0168] It has also been pointed out that group notifications should only be sent in POs for UEs interested in MBS services. If no UE misses the group notification, it would be beneficial to reduce the signaling overhead, but we assume that such optimizations can be handled by the NW implementation.

[0169] Observation 3: Optimizing the use of legacy POs depends on the deployment of the network.

[0170] Therefore, RAN2 needs to make sure that it reuses the legacy P-RNTI and legacy PO and extends the legacy paging message for group notification, at least from the UE's point of view, and the UE only needs to monitor paging within its own PO, which means it is the same as legacy paging.

[0171] Proposal 1: RAN2 should ensure that, at least from the UE's perspective, group notification uses legacy paging messages sent on all legacy POs with legacy P-RNTIs.

[0172] Extending existing paging messages If Proposal 1 is agreed, it will be necessary to discuss how to integrate group notification into the existing paging message. The current paging message contains a PagingRecordList, which is a list of UE-IDs to be paged, i.e., 5G-S-TMSI or I-RNTI. There are two possible options for group notification via paging:

[0173] Option A: The session ID of the MBS is entered in the existing PagingRecord list (an example is shown in FIG. 15).

[0174] Option B: The session ID of the MBS will be displayed in a new list (an example is shown in Figure 16).

[0175] Option A may be technically feasible as in the example above, but unless backward compatibility can be ignored, the UE-ID cannot be removed from the PagingRecord, so the unicast UE-ID and the MBS session ID must coexist in the same record. Adding the MBS session ID to the PagingUE-ID can be considered. However, since the MBS session ID is not a UE-ID, it is a different concept from 5G-S-TMSI and I-RNTI, which seems a bit strange.

[0176] Option B is feasible and simple as the above example, does not conflict with existing IE concepts, and reuses the LTE ETWS / CMAS notification extension concepts, so it is unlikely to affect legacy UEs.

[0177] Therefore, RAN2 needs to agree to define a new list, i.e., option B, in the paging message.

[0178] Proposal 2: RAN2 should agree to define a new list for group notification within the existing paging message.

[0179] PRACH capacity issues problem definition Further study is needed to address the PRACH capacity issue. Due to group notification, many UEs are paged simultaneously, resulting in many PRACH collisions. Furthermore, four Rel-17 WIs (RedCap, SDT, Coverage Enhancements, and RAN Slicing) currently plan to use PRACH partitioning for unique message 1 indications, which may affect the overall PRACH capacity. Therefore, in Rel-17 networks, increased PRACH collisions may result in delayed access latency, regardless of whether the service is multicast or unicast.

[0180] Generally, PRACH capacity is handled by appropriate network implementations. For example, a gNB can prepare more resources before a multicast session starts. However, in addition to the nature of group notifications and the numerous Msg1 indications mentioned above, some observations suggest that this may not be the case in Rel-17. On the other hand, network implementations have indicated that to avoid PRACH collisions, UEs can be kept in the RRC connected state until a multicast session is started / activated or until the session is deactivated. Needless to say, a UE in the RRC connected state transmits significantly more signals than a UE in the idle / inactive state, which is undesirable from the perspective of both UE power consumption and network resource efficiency. This makes it a rather costly option just to avoid PRACH collisions.

[0181] Observation 4: The NW implementation option of keeping the UE in RRC Connected state just to avoid PRACH transmission from the UE is unfavorable from the perspective of both UE power consumption and spectral efficiency.

[0182] It is certain that PRACH capacity will be an issue in group notification in distribution mode 1. Therefore, RAN2 needs to discuss how to solve this problem.

[0183] Proposal 3: RAN2 should discuss how to solve the PRACH capacity problem due to group notification, either by NW implementation or by standard mechanisms to distribute PRACH transmissions.

[0184] Possible solution approaches If Proposal 3 proposes the introduction of a standard mechanism for distributing PRACH transmissions from multiple UEs, two approaches are possible:

[0185] Approach A: Frequency Domain Diffusion This method aims to distribute PRACH transmissions across multiple frequencies. A similar issue was addressed in Rel-13 LTE by the Multicarrier Load Distribution (MCLD) method, which allows idle UEs to be redistributed across multiple frequencies. Therefore, the gNB may choose to redistribute the PRACH immediately before sending a group notification. The drawback of this approach is that if other frequencies do not provide the desired MBS service via PTM, the UE must either provide the MBS service via unicast or perform a handover to a frequency that does provide PTM.

[0186] Approach B: Time-Domain Diffusion This method aims to distribute PRACH transmissions across multiple timings. It is assumed that certain transmission opportunities are required, where a set of UEs are allowed PRACH and other sets of UEs are prohibited. The drawbacks of this method are that it requires a new mechanism, so more standard efforts are needed to determine how UEs are grouped and how PRACH transmission opportunities are identified, and there is an access delay because some UEs must wait a certain period of time after receiving the group notification before transmitting PRACH.

[0187] Each of these approaches has its own advantages and disadvantages, as briefly explained above, so RAN2 should discuss which approach is preferable, if necessary, in light of the actual deployment scenarios of NR MBS.

[0188] Proposal 4: Depending on the conclusions of Proposal 4 and Proposal 3, RAN2 needs to further discuss whether PRACH transmissions from multiple UEs should be extended in the frequency domain and / or the time domain. [Explanation of symbols]

[0189] 1: Mobile communication system 100:UE 110: Receiving unit 120: Transmitter 130: Control unit 200 :gNB 201:CU 202 :DU 210: Transmission unit 220: Receiving unit 230: Control unit 240: Backhaul communication unit 300A:AMF 310: Communications Department 320: Control unit

Claims

1. 1. A communication method comprising: transmitting information indicating a support status of a multicast broadcast service (MBS) function from the second network device to the first network device; receiving an MBS paging message including a TMGI from the first network device after the second network device transmits information indicating the support status of the MBS function; The second network device, in response to receiving the MBS-specific paging message, sends a paging message including the TMGI to a user equipment in an RRC inactive state or an RRC idle state; have Communication method.

2. The paging message for MBS is different from the RAN paging message for unicast. The communication method according to claim 1 .

3. The method further comprises receiving, by the second network device, an RRC message from the user equipment in the RRC inactive state or the RRC idle state to initiate a procedure for transitioning to an RRC connected state. The communication method according to claim 1 or 2.

4. The first network device is a centralized unit (CU) included in a base station, and the second network device is a distributed unit (DU) included in the base station. The communication method according to claim 1 or 2.

5. A network device, a transmitter for transmitting information indicating a support status of a multicast broadcast service (MBS) function to other network devices; a receiving unit for receiving an MBS paging message including a TMGI from the other network device after transmitting the information indicating the support status of the MBS function; Equipped with In response to receiving the MBS paging message, the transmitter transmits a paging message including the TMGI to a user equipment in an RRC inactive state or an RRC idle state. Network equipment.

6. A mobile communication system having a first network device and a second network device, The second network device transmits information indicating a support status of a multicast broadcast service (MBS) function to the first network device; the second network device receives an MBS paging message including a TMGI from the first network device after transmitting information indicating the support status of the MBS function; In response to receiving the MBS paging message, the second network device transmits a paging message including the TMGI to a user equipment in an RRC inactive state or an RRC idle state. Mobile communication system.

7. 1. A chipset for a network device, comprising: transmitting information indicating support status of a multicast broadcast service (MBS) function to other network devices; receiving an MBS paging message including a TMGI from the other network device after transmitting the information indicating the support status of the MBS function; In response to receiving the MBS paging message, transmitting a paging message including the TMGI to a user equipment in an RRC inactive state or an RRC idle state. Chipset.

8. To the network device, transmitting information indicating support status of a multicast broadcast service (MBS) function to other network devices; receiving an MBS paging message including a TMGI from the other network device after transmitting the information indicating the support status of the MBS function; In response to receiving the MBS paging message, a process of transmitting a paging message including the TMGI to a user equipment in an RRC inactive state or an RRC idle state is executed. program.

Images