COMMUNICATION CONTROL METHOD, USER EQUIPMENT, PROCESSOR AND NETWORK NODE

Abstract

A communication control method according to one embodiment is used in a mobile communication system providing a multicast / broadcast service (MBS). The communication control method includes: a base station transmitting, to a group comprising a plurality of user devices, a group notification indicating the validity of a multicast session corresponding to the group; and the base station receiving random access preambles transmitted from the user stations in response to the receipt of the group notification. The transmission of the group notification includes the base station transmitting the group notification at different timings to each of a plurality of sub-groups obtained by dividing up the group.

Description

[Technical field]

[0001] The present disclosure relates to a communication control method, a base station, and a user device used in a mobile communication system. [Background technology]

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

[0003] [Non-Patent Document 1] 3GPP technical specification "3GPP TS 38.300 V16.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). The communication control method includes a base station transmitting a group notification to a group of multiple user devices, the group notification indicating activation of a multicast session corresponding to the group, and the base station receiving a random access preamble transmitted from the user devices in response to receiving the group notification. Transmitting the group notification includes the base station transmitting the group notification at different timings to each of multiple subgroups obtained by dividing the group.

[0005] A communication control method according to a second aspect is a communication control method used in a mobile communication system providing a multicast / broadcast service (MBS). The communication control method includes a user equipment in an RRC idle state or an RRC inactive state receiving, from a base station, a group notification indicating that an MBS session corresponding to a group to which the user equipment belongs is activated, the user equipment determining a transmission timing for transmitting a random access preamble to the base station after receiving the group notification, and transmitting the random access preamble at the determined timing. Determining the transmission timing includes determining the transmission timing to be different from other user equipments belonging to the group.

[0006] A base station according to a third aspect includes a processor that executes the communication control method according to the first aspect.

[0007] A user device according to a fourth aspect includes a processor that executes the communication control method according to the second aspect. [Brief description of the drawings]

[0008] [Figure 1] 1 is a diagram showing a configuration of a mobile communication system according to an embodiment; [Diagram 2] FIG. 1 is a diagram illustrating a configuration of a UE (user equipment) according to an embodiment. [Diagram 3] A diagram showing the configuration of a gNB (base station) according to one embodiment. [Figure 4] A diagram showing the configuration of a protocol stack of a wireless interface of a user plane that handles data. [Diagram 5] FIG. 2 is a diagram showing the configuration of a protocol stack of a radio interface of a control plane that handles signaling (control signals). [Figure 6] FIG. 2 is a diagram showing a correspondence relationship between downlink logical channels and transport channels according to an embodiment. [Figure 7] FIG. 2 is a diagram illustrating a method for distributing MBS data according to an embodiment. [Figure 8] A diagram showing a split MBS bearer according to one embodiment. [Figure 9] FIG. 2 is a diagram illustrating a multicast session participation process of a mobile communication system according to an embodiment. [Figure 10] FIG. 2 is a diagram showing a process related to the priority of a UE 100 in a mobile communication system according to an embodiment. [Figure 11] FIG. 2 is a diagram showing a basic sequence of operations of a mobile communication system according to one embodiment. [Figure 12] A diagram showing a gNB200-led operation pattern of a mobile communication system according to one embodiment. [Figure 13] FIG. 2 is a diagram showing a first pattern of a UE 100-led operation in a mobile communication system according to an embodiment. [Figure 14] FIG. 11 is a diagram showing a second pattern of the UE 100-led operation of the mobile communication system according to an embodiment. [Figure 15] FIG. 11 is a diagram showing a third pattern of UE 100-led operation in the mobile communication system according to an embodiment. [Figure 16] FIG. 11 is a diagram showing a fourth pattern of the UE 100-led operation in the mobile communication system according to an embodiment. [Figure 17] FIG. 11 is a diagram showing a fifth pattern of a UE 100-led operation in a mobile communication system according to an embodiment. [Figure 18] FIG. 1 illustrates an existing paging record list. [Figure 19] FIG. 13 shows a new record list. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0010] Therefore, an object of the present disclosure is to provide a communication control method and a user device that 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, a configuration of a mobile communication system according to an embodiment will be described. FIG. 1 is a diagram showing a configuration of a mobile communication system according to an embodiment. This mobile communication system complies with the 3GPP standard 5th Generation System (5GS). In the following description, 5GS will be taken as an example, but the mobile communication system may be at least partially applied to an LTE (Long Term Evolution) system. Also, the mobile communication system may be at least partially applied to a 6th Generation (6G) system.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0026] The receiving unit 220 performs various 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.

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

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

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

[0030] As shown in FIG. 4, the user plane radio interface protocol includes a physical (PHY) layer, a medium access control (MAC) layer, a radio link control (RLC) layer, a packet data convergence protocol (PDCP) layer, and a service data adaptation protocol (SDAP) layer.

[0031] The PHY layer performs encoding / decoding, modulation / demodulation, antenna mapping / demapping, and resource mapping / demapping. Data and control information are transmitted between the PHY layer of the UE 100 and the PHY layer of the gNB 200 via a physical channel.

[0032] The MAC layer performs data priority control, retransmission processing using Hybrid 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 a transport channel. The MAC layer of gNB200 includes a scheduler. The scheduler determines the uplink and downlink transport format (transport block size, modulation and coding scheme (MCS)) and the resource blocks to be assigned to UE100.

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

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

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

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

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

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

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

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

[0041] (MBS) Next, an MBS according to an embodiment will be described. The MBS is a service that enables broadcast or multicast, that is, point-to-multipoint (PTM) data transmission from the NG-RAN 10 to the UE 100. The MBS may be called a Multimedia Broadcast and Multicast Service (MBMS). Note that use cases (service types) of the MBS include public safety communication, mission critical communication, V2X (Vehicle to Everything) communication, IPv4 or IPv6 multicast distribution, IPTV (Internet Protocol TeleVision), group calling, and software distribution.

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

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

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

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

[0046] Moreover, MBS data refers to data provided by the MBS. The MBS control channel refers to the MCCH or SC-MCCH. The MBS traffic channel refers to the MTCH or SC-MTCH. However, the MBS data may be transmitted by unicast. The MBS data may be called an MBS packet or MBS traffic.

[0047] The network can provide different MBS services for each MBS session. The MBS session is identified by at least one of a Temporary Mobile Group Identity (TMGI) and a session identifier (Session ID), and at least one of these identifiers is called an MBS session identifier. Such an MBS session identifier may be called an MBS service identifier or a multicast group identifier. The MBS session identifier may be a G-RNTI, which will be described later.

[0048] The MBS sessions include multicast sessions and broadcast sessions.

[0049] A multicast session is a session for delivering a multicast service. The multicast service provides services to a group of UEs 100 participating in the multicast session for applications that require reliable QoS. The multicast session is available to UEs 100 in an RRC connected state. The multicast session may also be available to UEs 100 in an RRC inactive state. In the following, MBS data transmitted by multicast (MBS data belonging to a multicast session) is referred to as multicast data.

[0050] A broadcast session is a session for delivering a broadcast service. The broadcast service provides a service to all UEs 100 within a specific service area. The broadcast session is available to UEs 100 in all RRC states (RRC idle state, RRC inactive state, and RRC connected state).

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

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

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

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

[0055] The MBS connection may be referred to as a Shared MBS Traffic delivery connection or a shared transport. The MBS connection terminates in the NG-RAN 10 (i.e., the gNB 200). The MBS connection may have a one-to-one correspondence with the MBS session.

[0056] gNB200 selects either PTP (Point-to-Point: unicast) or PTM (Point-to-Multipoint: multicast or broadcast) transmission method at its own discretion, and transmits MBS data to UE100 using the selected transmission method.

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

[0058] (Split MBS Bearer) Next, a split MBS bearer according to one embodiment will be described.

[0059] The gNB200 can set an MBS bearer separated into a PTP communication path and a PTM communication path (hereinafter, appropriately referred to as a "split MBS bearer") to the UE100. 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 enhance reliability by dually transmitting the same MBS data using both PTP (PTP communication path) and PTM (PTM communication path).

[0060] The predetermined layer that terminates the split 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 the split 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.

[0061] 8 is a diagram showing a split MBS bearer according to an embodiment. In the following, a PTP communication path is called a PTP leg, and a PTM communication path is called a PTM leg. Also, a functional unit corresponding to each layer is called an entity. Also, in the PTM leg, MBS data is transmitted by multicast.

[0062] As shown in Fig. 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.

[0063] Each of the gNB 200 and the UE 100 has two RLC entities provided for each leg, one MAC entity, and one PHY entity. The 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.

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

[0065] 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 MBS bearer needs to be set from the gNB 200 to the UE 100, and the PTM leg needs to 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 data using this PTM leg if the PTM leg is in a deactivation state.

[0066] Also, in order for the gNB200 and the UE100 to perform PTP transmission (unicast) of MBS data 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 data using this PTP leg if the PTP leg is in an inactive state.

[0067] 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., blind decoding of the PDCCH is performed using the G-RNTI). The UE 100 may monitor the PDCCH only at a scheduling opportunity for the MBS session.

[0068] In a state in which the PTM leg is deactivated, the UE 100 does not monitor the PDCCH to which the G-RNTI associated with the MBS session is applied (that is, does not perform blind decoding of the PDCCH using the G-RNTI).

[0069] UE 100 monitors the PDCCH to which the C-RNTI is applied when the PTP leg is activated. When discontinuous reception (DRX) is set in the PTP leg, UE 100 monitors the PDCCH in the set on duration (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.

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

[0071] It is assumed that the split MBS bearer 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.

[0072] (Mobile communication system operation) Next, the operation of the mobile communication system according to an embodiment will be described.

[0073] In the following, it is mainly assumed that UE100 in the RRC connected state receives MBS data (i.e., multicast data) transmitted from gNB200. For this reason, it is assumed that the MBS session is a multicast session and the MBS session identifier is a multicast session identifier (e.g., TMGI, Session ID, or G-RNTI). The multicast session is mapped to a PTM bearer (or MRB (Multicast Radio Bearer)). The PTM bearer is composed of PTP (or PTP leg) and / or PTM (or PTM leg). The MBS traffic channel (MTCH) is used to transmit the multicast data from gNB200 to UE100.

[0074] Hereinafter, the gNB 200 and the AMF 300 may be collectively referred to as "network devices" as appropriate. The AMF 300 is an example of a core network (CN) device. The AMF 300 manages multicast sessions in cooperation with a session management device. The session management device is another example of a CN device.

[0075] (Multicast session joining process) Next, a multicast session participation process in the mobile communication system according to an embodiment will be described.

[0076] FIG. 9 is a diagram showing a multicast session participation process in a mobile communication system according to an embodiment.

[0077] As shown in Fig. 9, in step S11, UE 100 is in an RRC connected state. 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 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.

[0078] In step S12, the UE 100 transmits a session join request message requesting participation in the target multicast session to the AMF 300. The session join request message includes a multicast session identifier (e.g., TMGI) that identifies the target multicast session. The session join request message is a NAS message and is transmitted to the AMF 300 via the gNB 200.

[0079] In step S13, the AMF 300 transmits a session join accept message to the UE 100 to accept the participation in the target multicast session. The session join accept message is a NAS message, and is transmitted to the UE 100 via the gNB 200. As a result, the UE 100 participates in the target multicast session. "Joining the target multicast session" refers to registering the UE 100 in the CN device as a member of a UE group (multicast group) that receives the multicast session. Note that the participation in the multicast session may be performed when the multicast session is in a valid state (transmitting). Also, the participation in the multicast session may be performed when the multicast session is in a disabled state (waiting for transmission to start or transmission is suspended).

[0080] After receiving the session participation acceptance message, if the multicast session is in an invalid state, the UE 100 may transition to an RRC idle state or an RRC inactive state. That is, the gNB 200 transmits an RRC Release message to the UE 100 participating in the multicast session in an invalid state. The identifier of the UE 100 participating in the multicast session, which is registered in the CN device, may be notified to the gNB 200 via the AMF 300. Information on whether the multicast session is in an active state or an invalid state may be notified from the AMF 300 to the gNB 200. For example, it may be notified by a multicast session activation message (Multicast Session Activation) or a multicast session deactivation message (Multicast Session Deactivation).

[0081] (Processing regarding priority of UE100) Next, a process related to the priority of the UE 100 in the mobile communication system according to an embodiment will be described. Here, the "priority of the UE 100" means the access priority of the UE 100 for a multicast session. For example, for a certain multicast session, a UE 100 with a high priority can preferentially access the gNB 200 providing the multicast session over a UE 100 with a low priority. For example, a UE 100 for public safety has a priority 3 (high priority), and a UE 100 with a premium user contract has a priority 2 (medium priority). Note that a general UE 100 may have a priority 1 (low priority). The gNB 200 or the AMF 300 acquires the priority of the UE 100. The gNB 200 or the AMF 300 may use the acquired priority of the UE 100 in a process of dividing a UE group, which will be described later.

[0082] FIG. 10 is a diagram showing a process related to the priority of the UE 100 in the mobile communication system according to an embodiment.

[0083] As shown in FIG. 10, in step S21, UE 100 judges whether or not priority access is granted for a target multicast session (a multicast session in which UE 100 participates or a multicast session in which UE 100 has an interest). Specifically, UE 100 judges that priority access is granted when at least one of the following conditions is satisfied: 1) The NAS entity of UE 100 has received a notification of priority access permission from AMF 300. 2) Priority access is permitted by the user contract of UE 100 (for example, information indicating that priority access is permitted is written in a SIM (Subscriber Identity Module) mounted in UE 100). ) 3) An application that requires priority handling among applications of the UE 100 (for example, a public safety application) is being executed.

[0084] When the UE 100 determines that the priority access is granted, in step S22, the UE 100 transmits a priority access request for requesting the gNB 200 for a priority access right. The gNB 200 receives the priority access request from the UE 100. The priority access request includes information indicating the priority of the UE 100 corresponding to the priority access of the UE 100. In this way, the gNB 200 acquires the priority of the UE 100. Note that the gNB 200 may consider a UE 100 that does not transmit a priority access request (i.e., a UE 100 that is not granted priority access) to have a low priority. The gNB 200 may use the priority of the UE 100 in a process of dividing a UE group, which will be described later.

[0085] Here, the priority access request is transmitted in one of the following ways.

[0086] 1) The UE 100 transmits a priority access request using a "cause" information element in an RRC Setup Request message or an RRC Resume Request message that the UE 100 transmits when transitioning to a connected state for the above-mentioned multicast session participation process. For example, the UE 100 sets the value of the "cause" information element to the priority of the UE 100. Here, a "cause" information element for multicast (for example, "Multicast Priority Access") may be newly provided in order to distinguish it from the priority of unicast communication.

[0087] 2) The UE 100 transmits a priority access request by using a specific PRACH (Physical Random Access Channel) resource in a random access preamble transmitted when the UE 100 transitions to a connected state for the above-mentioned multicast session participation process. The specific PRACH resource may be set from the gNB 200 via a common control channel (system information block, SIB) or a dedicated control channel (RRC Reconfiguration).

[0088] 3) The UE 100 transmits a priority access request in a UE Assistance Information message or Msg5. In this case, the UE 100 transmits a priority access request in a UE Assistance Information message or Msg5. Multicast session The multicast session identifier may be transmitted in the UE Assistance Information message or in Msg5.

[0089] The UE 100 may transmit the priority access request only when the target multicast session is in an invalid state. Alternatively, the UE 100 may transmit the priority access request only when the multicast bearer is not configured by the RRC Reconfiguration message.

[0090] The gNB 200 may use a priority access request transmitted from the UE 100 for access restriction. That is, the gNB 200 permits access from the UE 100 with a high priority. Permitting access may be any of transmitting a positive response (Msg2) to reception of a random access preamble (Msg1) and transmitting a positive response (RRC Setup or RRC Resume) (Msg4) to an RRC Setup Request or an RRC Resume Request (Msg3). The gNB 200 may reject access from the UE 100. Rejecting access may be any of transmitting a negative response in Msg2 to Msg1 or not transmitting a response, transmitting a Msg4 negative response to Msg3 or not transmitting a response, and transmitting Msg5 and subsequent RRC Releases.

[0091] In step S23, the gNB 200 may transmit information indicating the priority of the UE 100 to the AMF 300. As a result, the AMF 300 acquires the priority of the UE 100. The AMF 300 may use the acquired priority of the UE 100 in a process of dividing a UE group, which will be described later.

[0092] In step S24, gNB200 transmits an affirmative response to the priority access request received in step S22 to UE100.

[0093] In step S25, the UE 100 transitions to an RRC idle state or an RRC inactive state. If the multicast session is not enabled within a certain period after receiving the positive response, the UE 100 may transition to an RRC idle state or an RRC inactive state. Alternatively, the gNB 200 may release the RRC connection (i.e., send an RRC Release).

[0094] Next, an example will be described in which gNB200 acquires the priority of UE100 from AMF300.

[0095] First, the AMF 300 acquires the priority of the UE 100 regarding the multicast session from a PCF (Policy Control Function). The PCF is a device that manages contract information of the UE 100. For example, the PCF notifies the AMF 300 of the priority of the UE 100 for each TMGI from the contract information.

[0096] Secondly, the AMF 300 transmits information indicating the priority of the UE 100 to the gNB 200. As a result, the gNB 200 acquires the priority of the UE 100. The AMF 300 transmits the information indicating the priority of the UE 100 to the gNB 200 by using, for example, a UE context modification message which is a type of NG-AP (Application protocol) message.

[0097] (Basic sequence of operation of a mobile communication system) Next, a basic sequence of operations of the mobile communication system according to one embodiment will be described.

[0098] FIG. 11 is a diagram showing a basic sequence of operations of a mobile communication system according to an embodiment.

[0099] As shown in FIG. 11, in step S101, the UE 100 is in an RRC connected state.

[0100] In step S102, the UE 100 (NAS entity) performs a multicast session participation process for participating in the target multicast session on the network device.

[0101] In step S103, the UE 100 transitions to an RRC idle state or an RRC inactive state. Specifically, the UE 100 transitions to the RRC idle state or the RRC inactive state by receiving an RRC Release message from the gNB 200. Prior to step S103, the UE 100 may transmit to the gNB 200 an RRC message (e.g., a UE Assistance Information message) including an information element that prompts the UE 100 to transition to the RRC idle state or the RRC inactive state.

[0102] In step S104, the UE 100 starts monitoring the group notification from the gNB 200. The group notification may be a paging message transmitted from the gNB 200. The group notification may also be a message transmitted from the gNB 200 on a multicast control channel (MCCH). If the group notification is a paging message, the UE 100 monitors the group notification at a paging occasion (PO) of a paging frame (PF) that is set periodically. If the group notification is a message transmitted on the MCCH, the UE 100 monitors the MCCH according to information that sets the monitoring timing of the MCCH. The UE 100 may obtain the information from the SIB. The monitoring timing of the MCCH is set periodically.

[0103] In step S105, the gNB 200 transmits a group notification addressed to a UE group including the UE 100. The gNB 200 may transmit a group notification (paging message) to the UE 100 in response to a paging request from the AMF 300. The gNB 200 may transmit a group notification (paging message or MCCH) to the UE 100 in response to receiving a multicast session activation message (Multicast Session Activation) from the AMF 300. The group notification may include one or more of a multicast session identifier associated with the UE group, an identifier of each UE 100 belonging to the UE group, and a multicast session identifier associated with the identifier of the UE 100. Multicast session UE 100 that has received a group notification including a multicast session identifier or its own identifier can recognize that the target multicast session in which it has participated has been enabled. "The target multicast session has been enabled" may mean that transmission of multicast data has started in the target multicast session. Also, "the target multicast session has been enabled" may mean that the target multicast session has become in a state in which transmission of multicast data can be started.

[0104] In step S106, UE100 performs a random access procedure with gNB200 for receiving the target multicast session.

[0105] Specifically, first, the UE 100 transmits a random access preamble to the gNB 200. The random access preamble is transmitted via a PRACH (Physical Random Access Channel). A plurality of periodically occurring PRACH transmission opportunities may be set in the UE 100. Such PRACH transmission opportunities may be set in the UE 100 by an SIB or an RRC Release message transmitted by the gNB 200. In general, the UE 100 transmits the random access preamble at the first available PRACH opportunity (first PRACH opportunity) after the timing of receiving the group notification.

[0106] Secondly, in response to receiving the random access preamble from UE100, gNB200 transmits a random access response (message 2 (Msg2)) to UE100.

[0107] Third, the UE 100 transmits a message 3 (Msg3) to the gNB 200 in response to receiving the random access response from the gNB 200. If the UE 100 is in an RRC idle state, the message 3 is an RRC Setup Request message. If the UE 100 is in an RRC inactive state, the message 3 is an RRC Resume Request message.

[0108] Fourth, in response to receiving the message 3 from the UE 100, the gNB 200 transmits a message 4 (Msg4) to the UE 100. If the UE 100 is in an RRC idle state, the message 4 is an RRC Setup message. If the UE 100 is in an RRC inactive state, the message 4 is an RRC Resume message. Then, the UE 100 transitions to an RRC connected state.

[0109] Fifth, in response to receiving the message 4 (Msg4), the UE 100 transmits a message 5 (Msg5) to the gNB 200. The message 5 is an RRC Setup Complete message or an RRC Resume Complete message.

[0110] Note that the UE 100 may perform a two-step random access procedure. In this case, Msg1 and Msg3 are integrated into one message (MsgA), and Msg2 and Msg4 are integrated into one message (MsgB).

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

[0112] In step S108, 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 (multicast radio bearer) setting.

[0113] In such a basic sequence, when the number of UEs 100 (UEs 100 in an RRC idle state or an RRC inactive state) in a UE group (multicast group) is large, many UEs 100 transmit random access preambles to the gNB 200 simultaneously in response to receiving a group notification. This causes a problem of PRACH overload. Such PRACH overload may cause frequent PRACH collisions, resulting in access delays or inability of the UEs 100.

[0114] (gNB200-led operation pattern) Next, we will explain the gNB200-led operation pattern of the mobile communication system according to one embodiment.

[0115] In the gNB200-led operation pattern, the gNB200 transmits a group notification to a UE group, indicating the activation of a multicast session corresponding to the UE group. In transmitting the group notification, the gNB200 transmits the group notification at different timings to each of a plurality of subgroups obtained by dividing the UE group. This causes the transmission timing of the group notification to differ for each subgroup. Therefore, the transmission timing of the random access preamble is distributed among the subgroups. Thus, overload of the PRACH is suppressed.

[0116] 12 is a diagram showing an operation pattern led by the gNB 200 in the mobile communication system according to an embodiment. Here, differences from the above-described basic sequence will be mainly described.

[0117] As shown in Figure 12, step S In 201, a UE group division process is performed. The subject of the UE group division process may be the gNB 200. Also, the subject of the UE group division process may be the AMF 300.

[0118] Next, an example in which the UE group division process is performed by gNB200 will be described.

[0119] First, the gNB 200 divides a UE group corresponding to a multicast session into a plurality of subgroups. The gNB 200 divides the UE group so that, for example, the number of UEs 100 belonging to each subgroup does not exceed an upper limit value (X). The gNB 200 may determine the upper limit value according to the amount of PRACH resources available in a cell managed by the gNB 200 itself. For example, if the PRACH is not overloaded even if X UEs 100 simultaneously transmit random access preambles to the gNB 200, the gNB 200 sets the upper limit value to X. When the gNB 200 acquires the priority of the UE 100 in the above-mentioned process related to the priority of the UE 100, the gNB 200 may divide the UE group based on the priority of the UE 100. For example, the gNB 200 divides the UE group so that UEs 100 having the same priority belong to the same subgroup. In addition, it is desirable that the gNB 200 sets the upper limit value of a subgroup of a UE 100 with a high priority lower than the upper limit values ​​of other subgroups.

[0120] Second, the gNB 200 assigns a subgroup identifier to each of a plurality of subgroups obtained by dividing the UE group. The gNB 200 may further assign an RNTI (subgroup RNTI: SG-RNTI) together with the subgroup identifier.

[0121] Thirdly, the gNB 200 notifies the UE 100 belonging to the subgroup identified by the subgroup identifier of the subgroup identifier. The subgroup identifier is notified from the gNB 200 to the UE 100 in, for example, a multicast session participation process. For example, the gNB 200 notifies the UE 100 of the subgroup identifier corresponding to a certain multicast session together with a participation acceptance message corresponding to the multicast session. The gNB 200 may notify the UE 100 of the subgroup identifier in an RRC Reconfiguration message or an RRC Release message. The gNB 200 may notify the UE 100 of the SG-RNTI corresponding to the subgroup identifier together with the subgroup identifier. The SG-RNTI is used to decode the PDSCH corresponding to the group notification. The gNB 200 may notify the UE 100 of the multicast session identifier corresponding to the subgroup identifier together with the subgroup identifier.

[0122] The subject of the UE group division process may be the AMF 300. In this case, the AMF 300 notifies the gNB 200 of an identifier of each subgroup and an identifier of each UE 100 belonging to the subgroup.

[0123] In the following, it is assumed that the UE group corresponding to the multicast session is divided into two subgroups. The two subgroups include a subgroup (first subgroup) identified by a subgroup identifier "SG#1" and a subgroup (second subgroup) identified by a subgroup identifier "SG#2". Each subgroup includes at least one UE 100. In FIG. 12, the UE 100 belonging to the first subgroup is indicated as "UE 100-1", and the UE 100 belonging to the second subgroup is indicated as "UE 100-2". It is also assumed that the UE 100 belonging to the first subgroup has a high priority, and the UE 100 belonging to the second subgroup has a low priority.

[0124] In step S202, the UE 100 (the UE 100-1 and the UE 100-2) transitions to an RRC idle state or an RRC inactive state.

[0125] In step S203, UE 100 (UE 100-1 and UE 100-2) starts monitoring the group notification from gNB 200. When SG-RNTI is notified in step S201, UE 100 may monitor the group notification using the SG-RNTI. This allows UE 100 to omit decoding of a PDSCH corresponding to a group notification that is not addressed to a subgroup to which UE 100 belongs.

[0126] In step S204, the gNB 200 transmits a group announcement addressed to the first subgroup. The group announcement includes the subgroup identifier "SG#1". Such a group announcement may include a multicast session identifier (e.g., TMGI) of the multicast session to be enabled. If the subgroup identifier is unique among the multicast sessions, such a group announcement may not include the multicast session identifier.

[0127] Here, since the UE 100 belonging to the first subgroup has a high priority, the gNB 200 transmits a group notification addressed to the first subgroup before transmitting a group notification to the second subgroup (a subgroup to which the UE 100 having a low priority belongs). This allows the UE 100 having a high priority to access the gNB 200 with higher priority than the UE 100 having a low priority.

[0128] In step S205, UE 100-1 determines whether or not the subgroup identifier "SG#1" notified to itself (i.e., the subgroup identifier "SG#1" notified in step S201) is included in the group notification received in step S204. When UE 100-1 determines that "SG#1" is included in the group notification, UE 100-1 performs a random access procedure with gNB 200 in step S206. Note that in this case, UE 100 may notify gNB 200 that UE 100 has high priority by using a "cause" information element in an RRC Setup Request message or an RRC Resume Request message.

[0129] The operations in steps S206 to S208 are similar to those in steps S106 to S108.

[0130] In step S209, the gNB 200 transmits a group notification addressed to the second subgroup. The group notification includes the subgroup identifier “SG#2”.

[0131] In step S210, UE 100-2 judges whether or not the subgroup identifier "SG#2" notified in step S201 is included in the group notification received in step S209. When UE 100-2 judges that "SG#2" is included in the group notification, UE 100-2 performs a random access procedure with gNB 200 in step S211. Here, when UE 100-2 judges that "SG#2" is not included in the group notification, UE 100-2 continues to monitor the group notification without performing the random access procedure. When UE 100-2 includes a multicast session identifier of the multicast session in which UE 100-2 participates and does not include the subgroup identifier "SG#2" notified to UE 100-2, UE 100-2 continues to monitor the group notification without performing the random access procedure. That is, even if UE 100-2 grasps the activation of the multicast session in which UE 100-2 participates in response to the reception of the group notification, if UE 100-2 is not a target of the group notification, UE 100-2 continues to monitor the group notification without performing the random access procedure.

[0132] The operations in steps S211 to S213 are similar to those in steps S106 to S108.

[0133] In the gNB200-led operation pattern, the gNB200 may notify the UE100-1 having a high priority of the activation of the multicast session by using a unicast paging message instead of a group notification. Such a unicast paging message includes a multicast session identifier (e.g., TMGI) of the multicast session to be activated. In response to receiving such a unicast paging message, the UE100-1 performs a random access procedure with the gNB200, transitions to an RRC connected state, and receives multicast data.

[0134] The gNB 200 transmits a unicast paging message prior to the group notification. If the UE 100 to be notified is in an RRC idle state, the unicast paging message is transmitted by CN (Core Network) paging. If the UE 100 to be notified is in an RRC inactive state, the unicast paging message is transmitted by RAN (Radio Access Network) paging.

[0135] CN paging is paging initiated by the AMF 300. A unicast paging message transmitted by CN paging includes a 5G-S temporary mobile subscriber identity (5G-S-TMSI) assigned to the UE 100 by the AMF 300 as an identifier of the UE 100 to be paged.

[0136] The RAN paging is paging initiated by the gNB 200. A unicast paging message transmitted by the RAN paging includes an Inactive-RNTI (I-RNTI) assigned to the UE 100 by the gNB 200 as an identifier of the UE 100 to be paged.

[0137] (UE100-led operation pattern) Next, a UE 100-led operation pattern of the mobile communication system according to an embodiment will be described.

[0138] In the UE100-led operation pattern, the UE100 in the RRC idle state or the RRC inactive state receives a group notification from the gNB200 indicating that a multicast session corresponding to the UE group to which the UE100 belongs is activated. After receiving the group notification, the UE100 determines a transmission timing for transmitting a random access preamble to the gNB200. The UE100 transmits the random access preamble at the determined timing. In determining the transmission timing, the UE100 determines the transmission timing so as to be different from other UE100 belonging to the UE group. As a result, the transmission timing of the random access preamble is distributed among the UE100 belonging to the UE group. Thus, overload of the PRACH is suppressed.

[0139] (First pattern of UE100-led operation) Next, a first pattern of the UE 100-led operation of the mobile communication system according to an embodiment will be described.

[0140] In a first pattern of the UE100-led operation, the UE100 in the RRC idle state or the RRC inactive state receives a paging message from the gNB200 as a group notification. After receiving the paging message, the UE100 determines a transmission timing for transmitting a random access preamble to the gNB200. The UE100 transmits the random access preamble at the determined timing. In determining the transmission timing, if a predetermined condition is satisfied, the UE100 determines a PRACH transmission opportunity corresponding to a paging reception opportunity at which the paging message is received as the transmission timing, and if the predetermined condition is not satisfied, the UE100 determines a PRACH transmission opportunity corresponding to a paging reception opportunity next to the paging reception opportunity at which the paging message is received as the transmission timing. As a result, the transmission timing of the random access preamble is distributed among the UE100 according to the predetermined condition. Thus, overload of the PRACH is suppressed.

[0141] 13 is a diagram showing a first pattern of the UE 100-led operation of the mobile communication system according to one embodiment. Here, differences from the above-mentioned operation patterns will be mainly described.

[0142] 13, the UE 100 has already performed the multicast session join process and is in the RRC idle state or the RRC inactive state. In the first pattern, it is assumed that the group notification is a paging message.

[0143] 13, in step S301, the UE 100 starts monitoring a group notification (paging message) from the gNB 200. The UE 100 monitors the group notification (paging message) in the PO of the PF that is periodically set.

[0144] In step S302, the UE 100 receives a group notification (paging message) from the gNB 200. Here, the group notification (paging message) includes an identifier (for example, TMGI) of a multicast session in which the UE 100 participates.

[0145] In step S303, the UE 100 determines whether or not a predetermined condition is satisfied. If it is determined that the predetermined condition is satisfied (step S303: YES), the UE 100 starts a random access procedure at a first timing in step S304. Specifically, the UE 100 starts a random access procedure at the first timing. Preamble (step S304a). On the other hand, when it is determined that the predetermined condition is not satisfied (step S303: NO), UE 100 starts the random access procedure at a second timing that is later than the first timing in step S305. Specifically, UE 100 transmits a random access preamble at the second timing (step S305a). In other words, when it is determined that the predetermined condition is not satisfied, UE 100 suspends transmission of the random access preamble, and transmits the suspended random access preamble when the second timing arrives.

[0146] Next, the above-mentioned "first timing", "second timing", and "predetermined condition" will be described.

[0147] An example of the first timing is a PRACH transmission opportunity corresponding to a PO for which the group notification has been received. Here, the meaning of "PRACH transmission opportunity corresponding to a PO" differs depending on whether an association between a PO and a PRACH transmission opportunity is configured in the gNB 200.

[0148] If gNB200 does not set an association between a PO and a PRACH transmission opportunity, the "PRACH transmission opportunity corresponding to a PO" is the first available PRACH opportunity after the PO.

[0149] When the gNB 200 sets the association between the PO and the PRACH transmission opportunity, the "PRACH transmission opportunity corresponding to the PO" is the PRACH transmission opportunity associated with the PO, which is indicated by information for setting the association. The association between the PO and the PRACH transmission opportunity may be 1:1, 1:N, or N:1. For example, N PRACH transmission opportunities are associated with one PO (in the case of 1:N). In the case of 1:N, the UE 100 may randomly select one of the N PRACH transmission opportunities. The information for setting the association may be notified to the UE 100 by a SIB. The information for setting the association may be notified to the UE 100 by an RRC Release message that transitions the UE 100 to an RRC idle / inactive state.

[0150] An example of the second timing is a PRACH transmission opportunity corresponding to the next PO of the PO in which the group notification is received. That is, in this case, the UE 100 regards the group notification as having been received in the next PO and transmits a random access preamble in the PRACH transmission opportunity corresponding to the next PO. Since the PO is determined based on the identifier (5G-S-TMSI) of the UE 100, such a second timing is distributed among the UEs 100 belonging to the UE group.

[0151] The first timing and the second timing may be autonomously determined by the UE 100. The second timing may be a timing subsequent to the first timing.

[0152] "Satisfying a predetermined condition" refers to at least one of the following: 1) Extended DRX is configured in UE 100. 2) A time window for paging reception is configured in UE 100, and UE 100 has received a group notification at the last paging opportunity in the time window. 3) A timer is configured in UE 100.

[0153] Regarding 1), when extended DRX is configured in UE100, the time interval between POs is longer than when normal DRX is configured, so in order to reduce delays in receiving the multicast session, UE100 transmits a random access preamble at the first timing.

[0154] Regarding 2), the UE 100 is set by the gNB 200 a time window including multiple POs. The time window is set by parameters (time window parameters) such as a start position (origin), a window time length, and a window period. The time window parameters are notified from the gNB to the UE by an SIB, an RRC Release message, etc. The UE 100 basically monitors paging during the time window. After a certain time window ends, the UE 100 does not monitor paging until the next time window arrives. When the UE 100 receives a group notification at the last PO in the time window, the UE 100 transmits a random access preamble at a first timing. In this case, since the next PO occurs for the UE 100 after the window period, the UE 100 transmits a random access preamble at a first timing in order to reduce a delay in receiving a multicast session. In addition, even if UE 100 receives a group notification outside the time window (i.e., UE 100 wakes up late and receives the group notification after the time window has ended), UE 100 also transmits a random access preamble at the first timing.

[0155] Regarding 3), a timer for delaying the transmission timing of the random access preamble is set in the UE 100 by the gNB 200. The UE 100 starts the timer in response to receiving the group notification, and transmits the random access preamble at the PRACH transmission opportunity (second timing) corresponding to the first PO after the timer expires. Such a timer may be set individually for the UE 100 in the UE group corresponding to the multicast session. This distributes the transmission timing of the random access preamble among the UEs 100.

[0156] The UE 100 transitions to an RRC connected state by the random access procedure performed in step S304 or step S305, and receives multicast data.

[0157] (Second pattern of UE100-led operation) Next, a second pattern of the UE 100-led operation of the mobile communication system according to an embodiment will be described.

[0158] In a second pattern of UE 100-initiated operation, UE 100 starts a timer in response to receiving a group notification. UE 100 determines a PRACH transmission opportunity after the timer expires as the transmission timing of the random access preamble. The timer is set individually for UE 100. This distributes the transmission timing of the random access preamble between UEs 100.

[0159] 14 is a diagram showing a second pattern of operation led by the mobile communication system UE 100 according to an embodiment. Here, differences from the above-mentioned operation pattern will be mainly described.

[0160] In the initial state of FIG. 14, the UE 100 has already performed the multicast session join process, and is in the RRC idle state or the RRC inactive state.

[0161] As shown in FIG. 14, the operations in steps S401 and S402 are similar to the operations in steps S301 and S302.

[0162] In step S403, the UE 100 starts a timer (standby timer) in response to receiving the group notification. The timer value of the standby timer is set by the gNB 200 or the AMF 300. The timer value is set for each UE 100. Note that, when the UE 100 belongs to a subgroup (i.e., when the above-mentioned UE group division process is performed), the timer value may be set for each subgroup.

[0163] In step S404, the timer expires.

[0164] In step S405, the UE 100 performs a random access procedure, where the UE 100 may transmit a random access preamble at the first available PRACH transmission opportunity after the timer expires.

[0165] After that, the UE 100 transitions to an RRC connected state by the random access procedure performed in step S405, and receives the multicast data.

[0166] (Third pattern of UE100-led operation) Next, a third pattern of the UE 100-led operation of the mobile communication system according to an embodiment will be described.

[0167] In a third pattern of UE100-initiated operation, the probability of transmitting a random access preamble is set for UE100 from gNB200 or AMF300. When a random number generated by UE100 is equal to or greater than the probability, UE100 transmits the random access preamble at a PRACH transmission opportunity corresponding to the timing of receiving a group notification. When the random number is less than the probability, UE100 transmits the random access preamble at a PRACH transmission opportunity next to the PRACH transmission opportunity. As a result, the transmission timing of the random access preamble is distributed among UE100 according to the probability set in UE100. Thus, overload of PRACH is suppressed.

[0168] In the third pattern, the probability may be set according to the priority of the UE 100. The probability may be set such that the higher the priority of the UE 100, the lower the probability.

[0169] In the third pattern, the UE 100 may further be configured with a scaling factor from the gNB 200 or the AMF 300. The scaling factor is intended to reduce the probability. For example, the UE 100 compares the generated random number with an initial value of the probability (a value set by the network) in the first preamble transmission attempt. Then, the UE 100 compares the generated random number with the value of the probability to which the scaling factor is applied in the second preamble transmission attempt. This can alleviate the problem that some UEs 100 cannot transmit a preamble within a certain period of time.

[0170] In the third pattern, the UE 100 may further be configured by the gNB 200 or the AMF 300 with an upper limit value for the number of attempts to transmit a random access preamble. When the number of attempts reaches the upper limit value, the UE 100 immediately transmits a preamble. This can solve the problem that some UEs 100 cannot transmit a preamble within a certain period of time.

[0171] 15 is a diagram showing a third pattern of the UE 100-led operation of the mobile communication system according to an embodiment. Here, differences from the above-mentioned operation patterns will be mainly described.

[0172] In the initial state of FIG. 15, the UE 100 has already performed the multicast session join process, and is in the RRC idle state or the RRC inactive state.

[0173] 15, in step S501, the UE 100 receives a group notification. Here, the group notification includes an identifier (for example, TMGI) of a multicast session in which the UE 100 participates.

[0174] In step S502, the first available PRACH transmission opportunity after receiving the group announcement (the PRACH transmission opportunity corresponding to the timing of receiving the group announcement) arrives.

[0175] In step S503, the UE 100 sets the number of transmission attempts (N) of the random access preamble to one.

[0176] In step S504, the UE 100 determines whether the number of attempts (N) reaches the upper limit value. If the number of attempts (N) does not reach the upper limit value (step S504: NO), the UE 100 advances the process to step S505.

[0177] In step S505, the UE 100 generates a random number. The random number is a natural number in the range of "0" to "1".

[0178] In step S506, UE 100 compares the generated random number with the set probability. If the random number is equal to or greater than the probability (step S506: YES), UE 100 transmits a random access preamble (step S507). That is, in this case, UE 100 transmits a random access preamble at the first PRACH transmission opportunity. Then, in step S508, UE 100 transitions to an RRC connected state by performing a random access procedure. Then, in step S509, UE 100 starts receiving multicast data.

[0179] On the other hand, if the random number is less than the probability (step S506: NO), the UE 100 advances the process to step S510.

[0180] In step S510, the UE 100 determines that the next PRACH transmission opportunity has arrived, and proceeds to step S511. That is, the UE 100 suspends transmission of the random access preamble until the next PRACH transmission opportunity arrives.

[0181] In step S511, the UE 100 increments the number of attempts (N) by 1, and returns the process to step S504. Here, if the number of attempts reaches the upper limit (step S504: YES), the UE 100 transmits a random access preamble (step S507).

[0182] UE100 is the second and subsequent La In the random access preamble transmission attempt, control may be performed to lower the probability. When a scaling factor is configured in the UE 100, the UE 100 may perform control to lower the probability by using the scaling factor.

[0183] Next, control patterns 1 to 3 for lowering the probability will be described. Here, the description will proceed on the assumption that the probability set in the UE 100 is "0.6" and the scaling factor set in the UE 100 is "0.5".

[0184] Control pattern 1: In control pattern 1, the probability is calculated using the following formula:

[0185] Probability (threshold) = [NW-configured probability]÷[counter value] Here, "Probability (threshold)" is the probability to be compared in step S506. [NW-configured probability] is the probability set in the UE 100. [Counter value] is the number of trials (N).

[0186] In this case, in step S506, the probability of comparing with the first random number is "0.6." The probability of comparing with the second random number is "0.3" (=0.6 / 2). The probability of comparing with the third random number is "0.2" (=0.6 / 3).

[0187] Control pattern 2: In control pattern 2, the probability is calculated using the following formula:

[0188] Probability (threshold) = [NW-configured probability]÷([counter value]×[scaling factor]) In this case, in step S506, the probability of comparing with the first random number is "0.6". The probability of comparing with the second random number is "0.15" (=0.6 / 2×0.5). The probability of comparing with the third random number is "0.15" (=0.3×0.5).

[0189] Control pattern 3: In control pattern 3, the probability is calculated using the following formula:

[0190] Probability(threshold) = [previous probability]÷[scaling factor] In this case, in step S506, the probability of comparing with the first random number is "0.6". The probability of comparing with the second random number is "0.3" (=0.6×0.5). The probability of comparing with the third random number is "0.15" (=0.3×0.5).

[0191] In each of the above control patterns, the UE 100 assumes a case where the random number is equal to or greater than the probability and transmits the random access preamble, but a case where the random number is equal to or less than the probability and transmits the random access preamble is also considered. In this case, the probability is calculated by the following formula.

[0192] Probability (threshold) = [previous probability] + ((1 - [previous probability]) ÷ [scaling factor]) In this case, the probability of comparing with the first random number is "0.6". The probability of comparing with the second random number is "0.8" (=0.6+((1-0.6)×0.5)). The probability of comparing with the third random number is "0.9" (=0.8+((1-0.8)×0.5)).

[0193] In a fifth pattern of the UE 100-initiated operation, the scaling factor may be used to correct the random number generated by the UE 100. That is, the random number is multiplied by the scaling factor. This makes it possible to increase the PRACH transmission probability by using the random number to which the scaling factor is applied, even if the probability is the same.

[0194] (Fourth pattern of UE100-led operation) Next, a fourth pattern of the UE 100-led operation of the mobile communication system according to an embodiment will be described.

[0195] In a fourth pattern of the UE 100-initiated operation, the UE 100 transmits a random access preamble at a PRACH transmission opportunity determined based on the identifier of the UE 100. In this way, the transmission timing of the random access preamble is distributed according to the identifier of the UE 100, and overload of the PRACH is suppressed.

[0196] 16 is a diagram showing a fourth pattern of the UE 100-led operation of the mobile communication system according to an embodiment. Here, differences from the above-mentioned operation patterns will be mainly described.

[0197] In the initial state of FIG. 16, the UE 100 has already performed the multicast session join process, and is in the RRC idle state or the RRC inactive state.

[0198] 16, in step S601, the UE 100 receives a group notification. Here, the group notification includes an identifier (for example, TMGI) of a multicast session in which the UE 100 participates.

[0199] In step S602, the UE 100 determines a PRACH transmission opportunity to transmit a random access preamble, based on the identifier of the UE 100. Specifically, the UE 100 determines a PRACH transmission opportunity that satisfies the condition shown in the following formula as a PRACH transmission opportunity to transmit a random access preamble.

[0200] UE-ID mod M=[PRACH occasion count](or SFN) mod M Here, "UE-ID" is 5G-S-TMSI or I-RNTI.

[0201] "PRACH occasion count" is a count value for each PRACH transmission opportunity. When only one PRACH transmission opportunity is provided per frame, "PRACH occasion count" is SFN (System Frame Number).

[0202] "M" is a period. "M" is set in the UE 100 by the gNB 200 or the AMF 300. "M" is determined by one of the following methods.

[0203] 1) "M" is determined based on the QoS of the multicast service (e.g., the amount of access delay allowed). In this case, the larger the amount of delay allowed, the larger M is determined, and the smaller the amount of delay allowed, the smaller "M" is determined. 2) "M" is determined based on the capacity of the PRACH resource (or the impact on the unicast service). In this case, the larger the capacity (or the impact), the larger "M" is determined, and the smaller the capacity (or the impact), the smaller "M" is determined.

[0204] According to the above formula, the transmission timing of the random access preamble is distributed according to the identifier of the UE 100.

[0205] In step S603, the UE 100 transmits a random access preamble in the PRACH transmission opportunity determined in step S602. Then, in step S604, the UE 100 transitions to an RRC connected state by performing a random access procedure. Then, in step S605, the UE 100 starts receiving multicast data.

[0206] In the fourth pattern of the UE 100-initiated operation, the subgroup identifier in the above-described gNB 200-initiated operation pattern may be used instead of the identifier of the UE 100. In this case, the identifier of the UE 100 (or the UE-ID) may be read as the subgroup identifier.

[0207] (Fifth pattern of UE100-led operation) Next, a fifth pattern of the UE 100-led operation of the mobile communication system according to an embodiment will be described.

[0208] In the fifth pattern of the UE 100-led operation, at least one of the processes of the second to fourth patterns described above is set for the UE 100.

[0209] In the fifth pattern, the RRC layer of the UE 100 notifies the NAS layer of the UE 100 that the group notification has been received. The NAS layer notifies the RRC layer of access information indicating an access class or an access identifier. If the access information matches the specific access information, the UE 100 transmits a random access preamble at the first PRACH transmission opportunity after the timing of receiving the group notification (the PRACH transmission opportunity corresponding to the timing of receiving the group notification). If the access information does not match the specific access information, the UE 100 performs the at least one process.

[0210] 17 is a diagram showing a fifth pattern of the UE 100-led operation of the mobile communication system according to one embodiment. Here, differences from the above-mentioned operation patterns will be mainly described.

[0211] In step S701, the UE 100 (RRC layer) is in an RRC idle state or an RRC inactive state.

[0212] In step S702, UE100 (RRC layer) starts monitoring for group notification from gNB200.

[0213] In step S703, the UE 100 (RRC layer) , G Receive a loop notification from the gNB 200, where the group notification includes an identifier of the multicast session (e.g., TMGI).

[0214] In step S704, the RRC layer of the UE 100 notifies the NAS layer of the UE 100 of the identifier of the multicast session notified in step S703.

[0215] In step S705, the NAS layer of the UE 100 judges whether or not it is interested in the multicast session corresponding to the notified identifier. If it is judged that it is interested, in step S706, the NAS layer requests the RRC layer to access the gNB 200. In response to the request, the NAS layer notifies the RRC layer of an AC (Access Class) and / or an AI (Access Identity). The AC and / or AI may be determined by the access priority of the UE 100. The access priority of the UE 100 may be determined by the above-mentioned "processing related to the priority of the UE 100".

[0216] In step S707, the RRC layer determines whether or not at least one of the notified AC and / or AI is a specific value (specific access information). The specific value may be notified (set) by the gNB 200. The specific value may also be hard-coded (a value determined by a specification). If at least one of the AC and / or AI is a specific value (step S707: YES), in step S708, the UE 100 performs a random access procedure with the gNB 200. Specifically, the UE 100 transmits a random access preamble at the first PRACH transmission opportunity after the timing of receiving the group notification.

[0217] On the other hand, if neither AC nor AI is a specific value (step S707: NO), in step S709, UE 100 suspends transmission of the random access preamble. After that, UE 100 executes at least one of the above-mentioned second to fourth pattern processes set in UE 100. For example, if a waiting timer of the second pattern is set in UE 100, UE 100 starts the waiting timer. If a probability of the third pattern is set in UE 100, UE 100 generates a random number and compares it with the probability.

[0218] (Sixth pattern of UE100-led operation) Next, a sixth pattern of the UE 100-led operation of the mobile communication system according to an embodiment will be described.

[0219] In a sixth pattern of the UE 100-initiated operation, the UE 100 is assigned a PRACH transmission opportunity by the gNB 200. After receiving the group notification, the UE 100 transmits a random access preamble in the PRACH transmission opportunity.

[0220] In the sixth pattern, first, the gNB 200 notifies the UE 100 of the PRACH transmission opportunity allocated to the UE 100 by an SIB or an RRC Release message. Second, the UE 100 receives a group notification from the gNB 200. Third, the UE 100 transmits a random access preamble in the PRACH transmission opportunity allocated to the UE 100.

[0221] In addition, when UE 100 has a high access priority for a multicast session, even if it is configured to execute at least one of the first to sixth patterns described above, it may ignore these settings and transmit a random access preamble at the first available PRACH transmission opportunity in response to receiving a group notification.

[0222] (Other embodiments) The above-mentioned motion patterns are not limited to being performed independently, but can be performed by combining two or more motion patterns. For example, some steps of one motion pattern may be added to another motion pattern. Some steps of one motion pattern may be replaced with some steps of another motion pattern.

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

[0224] A program may be provided that causes a computer to execute each process performed by the UE 100 or the gNB 200. The program may be recorded in a computer-readable medium. Using the computer-readable medium, it is possible to install the program in the computer. Here, the computer-readable medium on which the program is recorded may be a non-transient recording medium. The non-transient recording medium is not particularly limited, and may be, for example, a recording medium such as a CD-ROM or a DVD-ROM.

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

[0226] As used in this disclosure, the terms "based on" and "depending on" do not mean "based only on" or "depending only on," unless otherwise specified. 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 "based at least in part on." Additionally, "obtain / acquire" may mean obtaining information from stored information, from information received from other nodes, or by generating information. The terms "include," "comprise," and variations thereof do not mean including only the items listed, but may include only the items listed, or may include additional items in addition to the items listed. Additionally, the term "or" as used in this disclosure is not intended to be an exclusive or. Additionally, any reference to elements using designations such as "first," "second," etc., as used in this disclosure is not intended to 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 a first and a second element 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 are intended to include the plural unless the context clearly indicates otherwise.

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

[0228] This application claims priority to U.S. Provisional Application No. 63 / 186,525 (filed May 10, 2021), the entire contents of which are incorporated herein by reference.

[0229] (Additional Note) (introduction) A revised work item on NR Multicast and Broadcast Services (MBS) was approved in RAN#88. The group notification was discussed in RAN2#113bis-e and the following agreements were reached: · Support multicast group notification for MBS support nodes. · For distribution mode 1, the UE is not expected to monitor the group notification channels in the RRC connected state. · Whether RAN2 needs to handle the PRACH capacity issue due to group notification needs further study. · Use the same Group Notification ID for both RRC idle and RRC inactive states. Reply LS: For non-supporting nodes, use of the MBS Session ID does not work as it affects non-MBS nodes. Unicast paging does work. · To support nodes, it is possible to use the MBS session ID. · Short post email discussion for LS replies.

[0230] This appendix describes the details of group notification and the PRACH capacity issue. (Discussion) Group notification in distribution mode 1 According to the SA2 LS, group notification is used for multicast session activation. RAN2 agreed that group notification based on MBS session ID is possible in NG-RAN nodes supporting MBS and the same group notification ID is used for both idle and inactive UEs.

[0231] Observation 1: Group notification based on the MBS session ID is sent by a gNB supporting MBS to UEs in idle / inactive state upon activation of a multicast session.

[0232] The email discussion specified two options for group notification: · Option 1: Paging-based group notification. · Option 2: MCCH based group notification.

[0233] Option 1 is very simple since idle / inactive UEs need to monitor paging as in legacy, i.e. unicast regardless of their interest in receiving multicast, and it may minimize UE power consumption for receiving group notifications (this will be discussed later).

[0234] Option 2 is a possible solution since MCCH is introduced for multicast reception for UEs in idle / inactive state in addition to connected state. However, it is a bit strange to use MCCH for distribution mode 1 since it was agreed that MCCH is only introduced for distribution mode 2. Also, distribution modes 1 and 2 should maintain maximum commonality in terms of, for example, using common IEs for MTCH, configuration, but should be as independent procedures as possible.

[0235] Therefore, RAN2 needs to agree that group notification reuses the existing paging mechanism.

[0236] Proposal 1: RAN2 needs to agree that the existing paging mechanism be reused for group notification.

[0237] If we agree with Proposal 1, we need to discuss how to integrate group notification into existing paging. Current paging messages contain a paging record list, which is a list of UE identities to be paged, i.e. 5G-S-TMSI or I-RNTI. For paging-based group notification, two options are considered:

[0238] Option A: The MBS session ID is listed in the existing paging record list.

[0239] Option B: The MBS Session ID appears in the new record list.

[0240] Option A might be technically feasible as shown in Figure 18, but it requires allowing the unicast UE ID and the MBS Session ID to coexist in the same record, since the UE ID cannot be removed from the paging record without backward compatibility. Another sub-option could be to add the MBS Session ID within the paging UE ID, but this is a bit odd as the MBS Session ID is not a UE ID.

[0241] In other words, the MBS session ID is a different concept from the 5G-S-TMSI or I-RNTI.

[0242] As shown in Figure 19, option B is feasible and simple, it does not conflict with existing IE concepts, and it is not likely to impact legacy UEs.

[0243] Therefore, RAN2 needs to agree to define a new record list in the paging message, namely option B.

[0244] Proposal 2: RAN2 needs to agree to define a new record list for group announcements within the existing paging message.

[0245] There is some discussion about whether group notification and unicast paging are received at the same time. From the UE's point of view, the additional power consumption for receiving group notification needs to be minimized. In particular, group paging is for UEs in idle / inactive state. If proposal 2 is acceptable, the UE receives paging messages at PF / PO, just like in legacy. Therefore, it does not matter whether the UE is interested in multicast reception or not. That is, a UE interested in multicast reception can check the group notification without additional wake-up.

[0246] Observation 2: From the UE's perspective, additional wake-up opportunities impact the UE's power consumption.

[0247] To achieve this, the gNB may need to repeatedly send group notifications during one paging DRX cycle (e.g., 320 ms) to ensure that all UEs receive the paging message. From the NW perspective, there may be a concern about paging capacity. However, this is not a problem in practice, since group paging is integrated within the existing paging message. That is, group notifications can be sent with any paging for any UE and any unicast MT access. For example, even if paging resources are loaded, some UEs still have paging and group notifications are piggybacked as in proposal 2. If there is no MT access, i.e., no unicast paging transmission, paging can only be sent for group notifications, since paging resources are not loaded.

[0248] Observation 3: From the NW perspective, repeated group announcements during one paging cycle have little impact on the load of paging resources.

[0249] Proposal 3: RAN2 needs to agree that the UE only monitors the existing PF / PO to receive group notifications, i.e., no additional wake-up time is required.

[0250] PRACH capacity issues: The PRACH capacity issue needs further study: group notification will result in many UEs being paged simultaneously, leading to many PRACH collisions, and therefore potential access delays regardless of whether the service is multicast or unicast.

[0251] Option I: Leave it to the gNB implementation.

[0252] Depending on the implementation, it is always possible for the gNB to prepare more resources before the start of a multicast session, which may be necessary especially for high QoS services. However, changing the PRACH resources requires modifying the SIB, which may be problematic if many multicast sessions are activated in a short time.

[0253] Option II: A mechanism is introduced to spread the PRACH transmission.

[0254] This problem can be solved if some UEs start PRACH transmission while other UEs have to wait for it even if they receive a group notification at the same time. Several possible mechanisms are considered, such as a waiting timer, RAND-based hashing, UE ID-based hashing, TMGI (or MBS Session ID) subgrouping, etc. The drawback is that additional standardization work is required.

[0255] PRACH capacity is certainly an issue for group notification in distribution mode 1. Therefore, RAN2 needs to discuss ways to solve the issue, including the above options and other methods.

[0256] Proposal 4: RAN2 needs to discuss how to solve the PRACH capacity issue, for example, by gNB implementation or new standard mechanisms.

Claims

1. A communication control method for use in a mobile communication system providing a multicast and broadcast service (MBS), comprising: a network node sending a group notification to a group of user equipment indicating activation of a multicast session corresponding to said group; receiving, by the network node, a random access preamble transmitted from the user equipment in response to receiving the group announcement; the user devices belonging to the group receiving the group notification; The method further comprises transmitting the random access preamble to the network node, depending on whether or not the user equipment receives a subgroup identifier that identifies a subgroup to which the user equipment belongs. Communications control method.

2. A user equipment supporting reception of a Multicast and Broadcast Service (MBS), comprising: a receiving unit configured to receive from a network a group notification transmitted to a group of a plurality of user devices, the group notification indicating an enablement of a multicast session corresponding to the group; a transmitter configured to transmit a random access preamble to the network node in response to receiving the group advertisement; the user device belonging to the group receives the group notification; The transmission unit transmits the random access preamble to the network node depending on whether or not a subgroup identifier that identifies a subgroup to which the user equipment belongs is received. User equipment.

3. 1. A processor for controlling a user equipment supporting reception of a Multicast and Broadcast Service (MBS), comprising: receiving a group notification from a network, the group notification being sent to a group of multiple user devices and indicating an activation of a multicast session corresponding to the group; in response to receiving the group announcement, transmitting a random access preamble to the network node; the user device belonging to the group receives the group notification; The transmitting process includes a process of transmitting the random access preamble to the network node depending on whether or not a subgroup identifier that identifies a subgroup to which the user equipment belongs is received. Processor.

4. A network node for providing a Multicast and Broadcast Service (MBS), comprising: a transmitter for transmitting a group notification to a group of a plurality of user devices, the group notification indicating an enablement of a multicast session corresponding to the group; A receiving unit that receives a random access preamble transmitted from the user equipment in response to receiving the group notification, The transmission unit transmits the group notification to the user devices belonging to the group; The receiving unit receives the RAM access preamble transmitted from the user equipment depending on whether or not a subgroup identifier for identifying a subgroup to which the user equipment belongs is received. Network node.

5. A chipset for a user device, comprising: receiving a group notification from a network, the group notification being sent to a group of a plurality of user devices, indicating an enablement of a multicast session corresponding to the group; and transmitting a random access preamble to the network node in response to receiving the group announcement; the user device belonging to the group receives the group notification; The transmitting step includes transmitting the random access preamble to the network node depending on whether or not a subgroup identifier that identifies a subgroup to which the user equipment belongs is received. Chipset.

Images