Communication control method, user equipment, chip set, program, and communication system

Abstract

To achieve an improved multicast / broadcast service.SOLUTION: In a mobile communication system, a communication control method includes transmitting, by user equipment 100 in an RRC inactive state, during a random access procedure, an RRC Resume Request message for resuming RRC connection to a network node to start an RRC Connection Resume procedure. The RRC Resume Request message has an information element indicating the reason for resuming the RRC connection. When the RRC Connection Resume procedure is triggered to receive an MBS multicast service, the user equipment in the RRC inactive state sets the value of the information element to a predetermined value to start the RRC Connection Resume procedure.SELECTED DRAWING: Figure 9

Description

[Technical Field]

[0001] The present disclosure relates to a communication control method, a user device, a chipset, a program, and a communication system. [Background technology]

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

[0003] [Non-Patent Document 1] 3GPP technical specification "3GPP TS 38.300 V16.3.0 (2020-09)" Summary of the Invention

[0004] A communication control method according to a first aspect is a communication control method used in a mobile communication system that provides a multicast broadcast service (MBS) from a network node to a user equipment. The communication control method includes the user equipment in an RRC inactive state initiating an RRC connection resume procedure by transmitting an RRC Resume Request message to the network node during a random access procedure to resume an RRC connection. The RRC Resume Request message includes an information element indicating a reason for resuming the RRC connection. When the user equipment is in the RRC inactive state and the RRC connection resume procedure is triggered for receiving an MBS multicast service, the user equipment sets a value of the information element to a predetermined value and initiates the RRC connection resume procedure.

[0005] A user equipment according to a second aspect is a user equipment that communicates with a network node that provides a multicast and broadcast service (MBS). The user equipment includes a controller. When the user equipment is in an RRC inactive state, the controller initiates an RRC Connection Resume procedure by sending an RRC Resume Request message to the network node during a random access procedure, the RRC Resume Request message including an information element indicating a reason for resuming an RRC connection. When the user equipment is in the RRC inactive state, the controller sets a value of the information element to a predetermined value and initiates the RRC Connection Resume procedure when the RRC Connection Resume procedure is triggered for reception of an MBS multicast service.

[0006] A chipset according to a third aspect is a chipset for controlling a user equipment (UE) that communicates with a network node providing a multicast and broadcast service (MBS). The chipset performs a process of initiating an RRC connection resume procedure by transmitting an RRC Resume Request message including an information element indicating a reason for resuming an RRC connection to the network node during a random access procedure when the UE is in an RRC inactive state. The process of initiating the RRC connection resume procedure includes a process of setting a value of the information element to a predetermined value when the UE is in the RRC inactive state and the RRC connection resume procedure is triggered for receiving an MBS multicast service.

[0007] A program according to a fourth aspect causes a user equipment (UE) communicating with a network node providing a multicast and broadcast service (MBS) to perform a process of initiating an RRC connection resume procedure by transmitting an RRC Resume Request message including an information element indicating a reason for resuming an RRC connection to the network node during a random access procedure when the user equipment is in an RRC inactive state, the process of initiating the RRC connection resume procedure including a process of setting a value of the information element to a predetermined value when the RRC connection resume procedure is triggered for receiving an MBS multicast service when the user equipment is in the RRC inactive state.

[0008] A fifth aspect of the present invention relates to a communication system including a network node providing a multicast / broadcast service (MBS) and a user device. In the communication system, the user device in an RRC inactive state initiates an RRC connection resume procedure by transmitting an RRC Resume Request message to the network node during a random access procedure, the RRC connection resume message including an information element indicating a reason for resuming an RRC connection. When the user device is in the RRC inactive state and the RRC connection resume procedure is triggered for receiving an MBS multicast service, the user device sets the value of the information element to a predetermined value and initiates the RRC connection resume procedure. [Brief explanation of the drawings]

[0009] [Figure 1] 1 is a diagram illustrating a configuration of a mobile communication system according to an embodiment. [Figure 2] FIG. 1 is a diagram illustrating a configuration of a UE (user equipment) according to an embodiment. [Figure 3] A diagram showing the configuration of a gNB (base station) according to one embodiment. [Figure 4] FIG. 10 is a diagram showing the configuration of a protocol stack of a radio interface of a user plane that handles data. [Figure 5] FIG. 1 is a diagram showing the configuration of a protocol stack of a radio interface of a control plane that handles signaling (control signals). [Figure 6] FIG. 2 is a diagram illustrating a correspondence relationship between downlink logical channels and transport channels according to an embodiment. [Figure 7] FIG. 1 is a diagram illustrating a method for distributing MBS data according to an embodiment. [Figure 8] FIG. 1 illustrates a multicast session joining procedure according to one embodiment. [Figure 9]FIG. 4 is a diagram illustrating an example of operation according to the first embodiment. [Figure 10] FIG. 10 is a diagram illustrating an example of operation according to the second embodiment. [Figure 11] FIG. 10 is a diagram illustrating an operation according to the first modification of the second embodiment. [Figure 12] FIG. 10 is a diagram illustrating an operation according to the second modification of the second embodiment. [Figure 13] FIG. 1 is a diagram showing an overview of the agreement regarding MBS setting. [Figure 14] FIG. 10 is a diagram showing the configuration of distribution mode 1. [Figure 15] FIG. 10 is a diagram showing the configuration of settings for distribution mode 2. DETAILED DESCRIPTION OF THE INVENTION

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

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

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

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

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

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

[0016] The NG-RAN 10 includes a base station (called a "gNB" in a 5G system) 200. The gNBs 200 are connected to each other via an Xn interface, which is an interface between base stations. The gNB 200 manages one or more cells. The gNB 200 performs wireless communication with a UE 100 that has established a connection with its own cell. The gNB 200 has a radio resource management (RRM) function, a routing function for user data (hereinafter simply referred to as "data"), 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.

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

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

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

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

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

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

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

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

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

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

[0027] The receiving unit 220 performs various types of reception under the control of the control unit 230. The receiving unit 220 includes an antenna and a receiver. The receiver converts a radio signal received by the antenna into a baseband signal (received signal) and outputs the baseband signal to the control unit 230.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0047] Furthermore, MBS data refers to data provided by an MBS, an MBS control channel refers to an MCCH or SC-MCCH, and an MBS traffic channel refers to an MTCH or SC-MTCH. However, MBS data may also be transmitted via unicast. MBS data may also be referred to as an MBS packet or MBS traffic.

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

[0049] MBS sessions include broadcast sessions and multicast sessions.

[0050] A broadcast session is a session for delivering a broadcast service. The broadcast service provides services to all UEs 100 within a specific service area for applications that do not require high-reliability QoS. The broadcast service is available to UEs 100 in all RRC states (RRC idle state, RRC inactive state, and RRC connected state).

[0051] A multicast session is a session for delivering a multicast service. The multicast service provides a service to a group of UEs 100 participating in the multicast session for applications that require highly reliable QoS. The multicast service is mainly available to UEs 100 in an RRC connected state. In the multicast service, MBS data is transmitted by multicast. Such MBS data is called multicast data. In the multicast service, the gNB 200 transmits the same multicast data to multiple UEs 100 that belong to a group of UEs 100 using the same radio resources.

[0052] In order to receive multicast data, the UE 100 needs to transition to the RRC connected state.

[0053] The operation of the UE 100 transitioning from the RRC idle state to the RRC connected state is called RRC connection establishment. The operation of the UE 100 transitioning from the RRC inactive state to the RRC connected state is called RRC connection resume. When the UE 100 decides to perform RRC connection establishment or RRC connection resume, it accesses the gNB 200 via a random access procedure.

[0054] A typical random access procedure includes Msg1 (message 1) from UE 100 to gNB 200, Msg2 (message 2) from gNB 200 to UE 100, Msg3 (message 3) from UE 100 to gNB 200, Msg4 (message 4) from gNB 200 to UE 100, and Msg5 (message 5) from UE 100 to gNB 200. In the case of a two-step random access procedure, Msg1 and Msg3 are combined into one message (MsgA), and Msg2 and Msg4 are combined into one message (MsgB).

[0055] Msg1 is a random access preamble from the UE 100 to the gNB 200. Msg2 is a random access response from the gNB 200 to the UE 100.

[0056] In the case of RRC connection establishment, the UE 100 transmits an RRC Setup Request message in Msg3. The gNB 200 transmits an RRC Setup message in Msg4. In response to receiving the RRC Setup message, the UE 100 transitions from the RRC idle state to the RRC connected state. After transitioning to the RRC connected state, the UE 100 transmits an RRC Setup Complete message in Msg5.

[0057] In the case of RRC connection resume, UE 100 transmits an RRC Resume Request message in Msg3. gNB 200 transmits an RRC Resume message in Msg4. UE 100 transitions from the RRC inactive state to the RRC connected state in response to receiving the RRC Resume message. After transitioning to the RRC connected state, UE 100 transmits an RRC Resume Complete message in Msg5.

[0058] In the random access procedure, the gNB 200 can reject access from the UE 100. When the gNB 200 rejects access from the UE 100, the gNB 200 transmits a message in Msg4 indicating that the access from the UE 100 is rejected. Such a message is an RRC Reject message in the case of RRC connection establishment, and an RRC Resume Reject message in the case of RRC connection resume.

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

[0060] 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 of the MBS data (replication), and distributes the data.

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

[0062] In 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) will be referred to as an "MBS connection."

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

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

[0065] On the other hand, in 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) terminates at the UE 100.

[0066] (Multicast session joining procedure) FIG. 8 is a diagram illustrating a procedure for joining a multicast session according to an embodiment.

[0067] As shown in FIG. 8, in step S1, the UE 100 is in an RRC connected state.

[0068] In step S2, the UE 100 transmits a session join request message to the AMF 300 (core network device). The session join request message includes session identification information (e.g., TMGI, session identifier, or group RNTI) that identifies the multicast session in which the UE 100 is interested. The session join request message is a NAS message and is transmitted to the AMF 300 via the gNB 200.

[0069] In step S3, AMF 300 transmits a session join accept message to UE 100 to accept session participation. The session join accept message is a NAS message, and is transmitted to UE 100 via gNB 200. The session join accept message includes permission information indicating permission to receive multicast data. UE 100 that receives the session join accept message understands that it is permitted to receive multicast data in the multicast session in which UE 100 is interested.

[0070] After receiving the session join accept message, the UE 100 may transition to an RRC idle state or an RRC inactive state before the multicast session starts. When the multicast session starts, the UE 100 may transition to an RRC connected state to receive multicast data.

[0071] (First embodiment) The first embodiment relates to a random access procedure for receiving multicast data.

[0072] As described above, the multicast service is available to the UE 100 in the RRC connected state. Therefore, the UE 100 in the RRC idle state or the RRC inactive state needs to transition to the RRC connected state via a random access procedure in order to receive multicast data from the gNB 200.

[0073] In the random access procedure, the gNB200 can reject access from the UE100. For example, when the amount of radio resources available in the gNB200 is small (when a value indicating the amount of available radio resources is equal to or less than a threshold), the gNB200 rejects access from a new UE100 in order to secure radio resources to be allocated to UE100 already under the control of the gNB200. The gNB200 may reject access from the UE100 for reasons such as a high load level or a high degree of congestion.

[0074] On the other hand, in a case where the gNB200 has already transmitted multicast data, the multicast data is transmitted to multiple UEs 100 using the same radio resources, and therefore even if the number of UEs 100 receiving the multicast data increases, it is highly likely that the amount of radio resources available to the gNB200 will not decrease, and it is also highly likely that the load level and congestion degree of the gNB200 will not increase. Therefore, in such a case, from the viewpoint of effective use of radio resources, it is better for the gNB200 not to reject UEs 100 that access the gNB200 to receive multicast data.

[0075] However, in the existing specifications, there is no means for the gNB 200 to determine whether the UE 100 will access the gNB 200 to receive multicast data. The first embodiment is an embodiment that solves this problem.

[0076] In the first embodiment, the UE 100 transmits predetermined information to the gNB 200 during a random access procedure. The predetermined information indicates that the UE 100 accesses the gNB 200 to receive multicast data from the gNB 200.

[0077] FIG. 9 is a diagram illustrating an example of operation according to the first embodiment.

[0078] 9, in step S101, the UE 100 is in an RRC idle state or an RRC inactive state in the cell of the gNB 200. The UE 100 may start step S101 after a multicast session join procedure.

[0079] When UE100 decides to receive multicast data from gNB200, in step S102, UE100 starts a random access procedure with gNB200. In step S102, UE100 transmits a random access preamble (Msg1) to gNB200.

[0080] In step S103, UE100 receives a random access response (Msg2) from gNB200.

[0081] In step S104, the UE 100 transmits Msg3 including predetermined information to the gNB 200. The predetermined information indicates that the UE 100 will access the gNB 200 to receive multicast data from the gNB 200. If the UE 100 is in an RRC idle state in step S101, the Msg3 is an RRC Setup Request message, and if the UE 100 is in an RRC inactive state in step S101, the Msg3 is an RRC Resume Request message.

[0082] When step S101 is started after the multicast session join procedure, UE 100 may transmit session identification information (e.g., TMGI, session identifier, or group RNTI) that identifies the accepted multicast session together with the predetermined information. When step S101 is started before the start of the multicast session join procedure and the RRC connection is for performing the multicast session join procedure, UE 100 may notify the predetermined information.

[0083] If Msg3 is an RRC Setup Request message, the UE 100 may transmit the predetermined information using an existing information element called EstablishmentCause in the RRC Setup Request message. EstablishmentCause is an information element indicating the reason for establishing an RRC connection. For example, the UE 100 sets the value of EstablishmentCause to "multicast access" and transmits the RRC Setup Request message. The gNB 200, which receives the EstablishmentCause with the value set to "multicast access", understands that the UE 100 is requesting establishment of an RRC connection with the gNB 200 to receive multicast data. The UE 100 may transmit the predetermined information using a new information element in the RRC Setup Request message. The new information element is an information element different from EstablishmentCause.

[0084] If Msg3 is an RRC Resume Request message, the UE 100 may use an existing information element called resumeCause in the RRC Resume Request message. resumeCause is an information element indicating the reason for resuming the RRC connection. For example, the UE 100 sets the value of resumeCause to "multicast access" and transmits the RRC Resume Request message. The gNB 200, which receives resumeCause with the value set to "multicast access", understands that the UE 100 requests the resumption of the RRC connection with the gNB 200 in order to receive multicast data. The UE 100 may transmit predetermined information using a new information element in the RRC Resume Request message. The new information element is an information element different from resumeCause.

[0085] In step S105, the gNB 200 determines whether to permit access from the UE 100 based on the predetermined information. For example, if the Msg3 from the UE 100 includes the predetermined information and the gNB 200 is transmitting multicast data, the gNB 200 determines to permit the UE 100. If the gNB 200 receives session identification information together with the predetermined information in step S104, the gNB 200 determines in step S105 whether to permit access from the UE 100, taking the session identification information into consideration. For example, if the multicast session identified by the session identification information matches the multicast session to which the multicast data being transmitted by the gNB 200 belongs, the gNB 200 determines to permit (i.e., reject) access from the UE 100. On the other hand, if the multicast session identified by the session identification information does not match the multicast session to which the multicast data being transmitted by the gNB 200 belongs, the gNB 200 determines not to permit (i.e., reject) access from the UE 100.

[0086] If gNB200 determines in step S105 to permit access from UE100, in step S106, UE100 receives Msg4 (the above-mentioned RRC Setup message or RRC Resume message) from gNB200 indicating that access is permitted.

[0087] In step S107, the UE 100 transitions to the RRC connected state.

[0088] In step S108, the UE 100 transmits Msg5 (the above-mentioned RRC Setup Complete message or RRC Resume Complete message).

[0089] In step S109, UE100 receives multicast data from gNB200.

[0090] In the first embodiment, the UE 100 may transmit predetermined information in Msg1. In this case, the UE 100 receives, from the gNB 200, information indicating a special PRACH (Physical Random Access Channel) resource to be used when accessing to receive multicast data, and transmits a random access preamble using the special PRACH resource. When the gNB 200 receives the random access preamble transmitted using the special PRACH resource from the UE 100, the gNB 200 understands that the UE 100 will access the gNB 200 to receive multicast data. The information indicating the special PRACH (Physical Random Access Channel) resource is transmitted in a system information block (SIB) broadcast by the gNB 200.

[0091] In the first embodiment, the UE 100 may transmit predetermined information in Msg 5. The UE 100 may transmit session identification information together with the predetermined information in Msg 5. The gNB 200 may perform mobility control (e.g., handover) of the UE 100 based on the information received in Msg 5.

[0092] Msg3, Msg4, and Msg5 in the first embodiment may be used for RRC connection re-establishment. In this case, Msg3 is an RRC Reestablishment Request, Msg4 is an RRC Reestablishment, and Msg5 is an RRC Reestablishment Complete. In this case, in step S101, the UE 100 is in an RRC connected state and has detected an RLF (Radio Link Failure).

[0093] In the first embodiment, the predetermined information may indicate that the UE 100 does not transmit or receive unicast data, or that the UE 100 does not transmit data. The gNB 200 that receives such predetermined information can recognize that allowing the UE 100 is unlikely to reduce the amount of radio resources available to the gNB 200.

[0094] In the first embodiment, an example in which identification information is notified using a four-step random access procedure has been described, but this may also be applied to a two-step random access procedure. In the two-step random access procedure, Msg1 and Msg3 are transmitted as MsgA, and Msg2 and Msg4 are transmitted as MsgB. Therefore, when notifying identification information using a two-step random access procedure, the identification information may be transmitted in MsgA.

[0095] (Second embodiment) The second embodiment is an embodiment related to the operation of the NAS layer of the UE 100 before the random access procedure for receiving multicast data is started.

[0096] FIG. 10 is a diagram illustrating an example of operation according to the second embodiment.

[0097] 10, in step S201, the UE 100 is in an RRC idle state or an RRC inactive state in a cell of the gNB 200. The UE 100 may start step S201 after a multicast session join procedure.

[0098] In step S202, the NAS layer of the UE 100 acquires the start time of a multicast session in which the UE 100 is interested. The NAS layer may acquire the start time through notification from the AMF 300. The NAS layer may acquire the start time from user service information (USD: User Service Description) stored in advance in the UE 100. The user service information is information of the application layer (service layer). For each MBS service, the user service information includes at least one of an MBS service identifier (e.g., TMGI), the start time and end time of the MBS session, a frequency, and an MBMS service area identifier.

[0099] In step S203, the NAS layer of the UE 100 determines whether the start time has arrived. If the NAS layer determines that the start time has arrived (S203: YES), in step S204, the NAS layer provides a request to the RRC layer of the UE 100, requesting that the UE 100 access the gNB 200. If step S201 is initiated after a multicast session join procedure, the NAS layer may provide session identification information that identifies the accepted multicast session together with the request.

[0100] In step S205, the UE 100 (lower layers such as an RRC layer, a MAC layer, and a PHY layer) performs a random access procedure with the gNB 200. In the random access procedure, the UE 100 may transmit the predetermined information in the first embodiment.

[0101] After UE100 transitions to the RRC connected state via the random access procedure, it receives multicast data from gNB200.

[0102] (Modification 1 of the second embodiment) Next, an operation according to Modification 1 of the second embodiment will be described, focusing on differences from the second embodiment. In Modification 1, the NAS layer provides a request to the RRC layer before the start time arrives.

[0103] FIG. 11 is a diagram illustrating an operation according to the first modification of the second embodiment.

[0104] The operations in steps S301 and S302 are the same as those in steps S201 and S202.

[0105] In step S303, the NAS layer of the UE 100 provides a request for the UE 100 to access the gNB 200 to the RRC layer of the UE 100 before the start time arrives. For example, the NAS layer provides the request when permission is obtained in the multicast session join procedure. The NAS layer provides information indicating the start time and the request to the RRC layer.

[0106] In step S304, the lower layer of the UE 100 suspends the execution of the random access procedure.

[0107] In step S305, the lower layer of the UE 100 determines whether or not the start time has arrived. If the lower layer determines that the start time has arrived (S305: YES), the lower layer performs a random access procedure in step S306.

[0108] (Modification 2 of the second embodiment) Next, the operation of the second modification of the second embodiment will be described, focusing mainly on the differences from the first modification.

[0109] FIG. 12 is a diagram illustrating an operation according to the second modification of the second embodiment.

[0110] The operations of steps S401 to S404 are the same as the operations of steps S301 to S304, except that in step S403, the NAS layer of the UE 100 does not need to notify the RRC layer of the start time.

[0111] In step S405, the NAS layer of the UE 100 receives a session start notification from the AMF 300. The session start notification is a notification indicating that a multicast session will start. The session start notification may be included in a paging message. The session start notification may include session identification information (e.g., TMGI, session identifier, or group RNTI) of the multicast session to be started.

[0112] In step S406, the NAS layer of the UE 100 notifies the RRC layer that a multicast session is to start. If the session start notification includes session identification information, the NAS layer also notifies the RRC layer of the session identification information.

[0113] In step S407, the UE 100 (lower layers such as the RRC layer, MAC layer, and PHY layer) starts a random access procedure in response to the notification.

[0114] Here, when the RRC layer of UE100 receives session identification information along with the request in step S403, it compares the session identification information with the session identification information included in the session start notification received in S406, and if the two match, it may start a random access procedure.

[0115] In the second modification, in step S405, the RRC layer of the UE 100 may receive the session start notification. The gNB 200 may broadcast the session start notification in an SIB. For example, the session start may be notified by adding session identification information (e.g., TMGI, session identifier, or group RNTI) of the multicast session to be started to the SIB. Alternatively, the notification may be made by RAN paging. The RAN paging may include session identification information for starting the session. The UE 100 (lower layers such as the RRC layer, MAC layer, and PHY layer) starts a random access procedure in response to the notification.

[0116] In the above-described second embodiment, an example in which the UE 100 receives multicast data has been described. As another example, the UE 100 is interested in receiving broadcast data (MBS data transmitted by broadcast). When the start time of the broadcast session arrives, the NAS layer of the UE 100 notifies the RRC layer of this fact. In response to the notification, the RRC layer starts receiving the SIB for MBS and / or the MBS control channel.

[0117] (Other embodiments) The above-described embodiments and modifications of the embodiments are not limited to being implemented independently, but can also be implemented by combining two or more embodiments.

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

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

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

[0121] This application claims priority to U.S. Provisional Application No. 63 / 164688 (filed March 23, 2021), the entire contents of which are incorporated herein by reference.

[0122] (Addendum) (introduction) A revised work item on NR Multicast and Broadcast Services (MBS) was approved in RAN#88. RAN2#112-e agreed to introduce two delivery modes for MBS as follows:

[0123] In Rel-17, R2 specifies two modes. · 1: One delivery mode for high QoS (reliability, delay) requirements available in the Connected state (currently undetermined if no data is received, the UE may be able to switch to another state). 2: One delivery mode for "low" QoS requirements. The UE can also receive data in inactive / idle state (details to be determined). R2 assumes (as in R17) that delivery mode 1 is used only for multicast sessions. R2 assumes that delivery mode 2 is used for broadcast sessions. The applicability of delivery mode 2 to multicast sessions requires further study.

[0124] No Data: If there is no ongoing data in the multicast session, the UE can stay in RRC Connected state. Other cases require further consideration.

[0125] Regarding distribution mode 2, the following additional agreement was reached on the outline of MBS settings:

[0126] The UE receives the MBS configuration (in broadcast / distribution mode 2) via BCCH and / or MCCH (TBD). This can be received in idle / inactive mode. Connected mode requires further consideration (depending on UE capacity, location of service provided, etc.). A notification mechanism is used to notify changes in MBS control information.

[0127] In RAN2#113-e, the details of distribution mode 2 were agreed upon as follows: Both idle / inactive UEs and connected mode UEs can receive MBS services transmitted by NR MBS delivery mode 2 (already agreed broadcast services, others yet to be determined). Whether a connected mode UE can receive this depends on the network provisioning of the service (e.g., on which frequency), the UE connected mode configuration, and the UE capabilities.

[0128] The two-step based approach (BCCH and MCCH) adopted in LTE SC-PTM is reused for transmitting PTM settings for NR MBS distribution mode 2.

[0129] We assume that the LTE SC-PTM mechanism of connected UEs can be reused to receive PTM configuration for NR MBS delivery mode 2, i.e., the broadcast-based method.

[0130] It is assumed that the MCCH change notification mechanism is used to notify the change in MCCH configuration due to the start of a session for NR MBS delivery mode 2 (other cases require further consideration).

[0131] It is assumed that MBS interest indication is supported by UEs in connected mode for broadcast services (typically it is assumed that there are no mandatory network requirements and that network action is up to the network).

[0132] MBS interest indication is not supported for UEs in idle / inactive mode with NRMBS delivery mode 2.

[0133] For service continuity purposes, we envision some information being provided to NR MBS Delivery Mode 2 (contents requiring further consideration - e.g., reconsideration based on progress of other groups such as USD, SAI / TMGI, etc.).

[0134] Further study is needed to support frequency-based UE recognition of MBS services for service continuity in NR MBS delivery mode 2 (i.e., reusing the LTE SC-PTM mechanism).

[0135] Support for frequency prioritization during cell reselection for service continuity in NR MBS delivery mode 2 requires further study (i.e., reusing the LTE SC-PTM mechanism).

[0136] P2: It is pending whether UEs receiving multicast can be released to RRC inactive / idle state and continue receiving multicast. Further discussion should restrict RRC to inactive.

[0137] This appendix considers the control plane aspects of NR MBS, taking into account the LTE eMBMS mechanisms and the latest RAN2 agreements.

[0138] (Discussion) At this point, according to the RAN2 agreement cited in Section 1 and the report of the LS response to SA2, the characteristics of the two delivery modes can be summarized in Figure 13.

[0139] (Distribution mode 1 settings) Delivery mode 1 primarily considers data reception in the RRC connected state, but the details of the configuration have not yet been agreed upon. Considering that delivery mode 1 will be used for high QoS services, it must include, for example, PTP / PTM split bearer and / or lossless handover. Since it is irrelevant whether these UE-specific configurations are provided via MCCH, it is quite simple to say that RRC reconfiguration must be used to configure delivery mode 1. The LS response to SA2 indeed confirmed that RRC reconfiguration is used for MBS configuration and session start notification.

[0140] Observation 1: For delivery mode 1, RRC reconfiguration is used for MBS configuration and notification by session start.

[0141] On the other hand, WID clearly indicates that the RRC Connected and Idle / Inactive states should have maximum commonality in terms of MBS configuration, although RAN2 agreed to separate delivery modes for multicast and broadcast sessions, respectively.

[0142] For PTM reception configuration, it specifies the changes required to enable reception of PTM transmissions by UEs in RRC Idle / RRC Inactive state, with the aim of maintaining maximum commonality between RRC Connected and RRC Idle / RRC Inactive states.

[0143] Even if the RRC messages for these delivery modes are different, to achieve the objectives of WID, the IEs and structure of MBS configuration must be aligned as much as possible between the two delivery modes, as pointed out in the discussion of RAN2#112-e. For example, the RRC reconfiguration for delivery mode 1 includes MTCH scheduling information, which is a common block with delivery mode 2, as well as delivery mode 1-specific information such as PTP / PTM split bearer and handover-related information, which requires further discussion at this point.

[0144] Proposal 1: RAN2 should agree to aim for maximum commonality between the two delivery modes in terms of MBS configuration, e.g., by using common structures and IEs.

[0145] It should be noted that "MCCH" in Figure 14 refers only to MTCH scheduling information, i.e., MTCH configuration related to MBS session information. For distribution mode 1, neighboring cell information is not required.

[0146] However, further study is needed to determine whether a UE can be released to an idle / inactive state when there is no ongoing data for a multicast session. In other words, whether an idle / inactive UE can receive MBS data via delivery mode 1 is still needed. As agreed by RAN2, the baseline assumption is that delivery mode 1 requires the UE to remain RRC connected for multicast sessions, and high QoS is required. However, other / exceptional cases are worth considering.

[0147] In email discussions, some companies pointed out that the network may not be able to keep all UEs connected due to congestion, while several others pointed out that UEs do not need to stay connected all the time due to uplink inactivity, QoS requirements, and / or UE power consumption.

[0148] The above points may be beneficial for both the network and the UE. However, it is understood that whether / when the UE is released to the inactive state is up to the gNB implementation, and whether the UE is released to the idle state is up to the core network. One concern regarding MBS data reception in the idle state is that if the gNB releases the UE context (which is usually only retained in the inactive state, not the idle state), it could mean that the controllability of the gNB may be lost. This may contradict the concept of distribution mode 1. Therefore, the RAN2#113-e agreement states that "Future discussions should limit RRC to the inactive state." Therefore, RAN2 needs to agree that distribution mode 1 can be received by UEs at least in the inactive state.

[0149] Proposal 2: For delivery mode 1, RAN2 must agree that the UE can receive MBS data at least in the RRC inactive state.

[0150] If proposal 2 is acceptable, it is unclear how the idle / inactive MBS configuration is provided to the UE. Three options are possible:

[0151] Option 1: RRC Reconfiguration A UE in idle / inactive state continues to apply the MBS configuration provided by RRC reconfiguration. This option is simple as the UE simply reuses the MBS configuration originally provided for RRC Connected. However, some UE behavior needs to be clarified when transitioning to idle / inactive state and / or returning to RRC Connected state (e.g. how to handle PTP / PTM split bearer configuration, if configured). Option 2: RRC Release The UE in idle / inactive state applies the MBS configuration provided by the RRC release. Although this option seems simple, it may not be efficient, as it is doubtful whether the MBS configuration will be different from the one previously provided by the RRC reconfiguration. Option 3: Switch the delivery mode from Mode 1 to Mode 2 Before the UE is released to the idle / inactive state, it is switched from distribution mode 1 to distribution mode 2. This option is another simple solution, as distribution mode 2 is designed to be able to receive data in all RRC states as agreed by RAN2. However, it may be expected that packet loss and delays may occur during the switchover, for example due to MCCH acquisition.

[0152] Each option has its advantages and disadvantages, but in our view, Option 1 is slightly preferable for simplicity and efficiency. RAN2 needs to explain how to provide UEs with delivery mode 1 configuration for data reception in idle / inactive state, including but not limited to the above options.

[0153] Proposal 3: If Proposal 2 is agreed upon, RAN2 needs to discuss how the delivery mode 1 configuration for data reception in inactive state is provided to the UE.

[0154] (Distribution mode 2 settings) In LTE SC-PTM, the configuration is provided by two messages: SIB20 and SC-MCCH. SIB20 provides SC-MCCH scheduling information. SC-MCCH provides SC-MTCH scheduling information including G-RNTI and TMGI, and neighbor cell information. It has been agreed to reuse the same mechanism for NR MBS.

[0155] NR MBS is expected to support the various types of use cases outlined in the WID. NR MBS must be appropriately designed for a variety of requirements, from delay-sensitive applications such as mission-critical and V2X to delay-tolerant applications such as IoT, in addition to other aspects of the requirements ranging from lossless applications such as software distribution to UDP-type streaming such as IPTV. Some of these services may be covered by delivery mode 2, while others with "high QoS requirements" require delivery mode 1. In this sense, it is beneficial for gNBs to be able to choose to use delivery mode 2 for multicast sessions.

[0156] This issue was left for further consideration from RAN2#112-e to RAN2#113-e, but in general, from our point of view there seems to be no technical reason to restrict it.

[0157] Proposal 4: RAN2 should agree that delivery mode 2 can be used for multicast sessions in addition to broadcast sessions.

[0158] In light of Proposal 4, the control channel design for delivery mode 2 needs to consider flexibility and its resource efficiency. Otherwise, more signaling overhead may occur, for example, when delay-tolerant and delay-sensitive services are configured together on one control channel. This may require the control channel to be scheduled more frequently to meet the delay requirements from delay-sensitive services.

[0159] Objective A of the SA2 SI concerns the enablement of general MBS services over 5GS, and use cases identified that could benefit from this capability include (but are not limited to) public safety and mission-critical, V2X applications, transparent IPv4 / IPv6 multicast delivery, IPTV, software delivery over wireless, group communications, and IoT applications.

[0160] Observation 2: The control channel for delivery mode 2 needs to be flexible and resource efficient for different types of use cases.

[0161] One possibility is to consider whether the configuration channels need to be separated for different use cases, as shown in Figure 15. For example, one MCCH may provide frequent delay-sensitive services, while another MCCH may provide sparsely delay-tolerant services. LTE SC-PTM is limited to only one SC-MCCH per cell. However, considering that NR MBS distribution mode 2 is expected to support more use cases than LTE, this limitation should be removed. If multiple MCCHs are permitted in a cell, each MCCH has different scheduling settings, such as a recurrence period that can be optimized for a specific service. Further consideration is needed to determine how a UE can identify the MCCH that serves a specific service.

[0162] Proposal 5: For distribution mode 2, RAN2 needs to consider whether the cell supports multiple MCCHs, which was not supported in LTE.

[0163] Furthermore, a new paradigm in NR is the support of on-demand SI transmission. This concept can be reused for MCCH in delivery mode 2, i.e., on-demand MCCH. For example, MCCH for delay-tolerant services is provided on-demand, thus optimizing signaling resource consumption. Of course, the network has another option to provide MCCH periodically, i.e., not on-demand, for example, for delay-sensitive services.

[0164] Proposal 6: For delivery mode 2, RAN2 should discuss options if MCCH, which was not available in LTE, is provided on an on-demand basis.

[0165] Another possibility is to further consider merging these messages, i.e., one-step configuration as shown in Figure 15. For example, the SIB provides MTCH scheduling information directly, i.e., without MCCH, providing optimization for delay-tolerant services and power-sensitive UEs. For example, a UE can request an SIB (on-demand), and the gNB can start providing the SIB and corresponding services after requests from multiple UEs. These UEs do not need to monitor the repeatedly broadcasted MCCH.

[0166] Proposal 7: For distribution mode 2, RAN2 should discuss options if multicast reception without MCCH is supported (i.e., one-step configuration), e.g., the SIB provides MTCH scheduling information directly.

[0167] It was agreed to introduce MCCH change notification, which is expected to be similar to the notification in LTE SC-PTM. At the very least, the UE will be notified of MCCH changes upon session start.

[0168] According to the latest LTE specifications, "When the network changes (part of) the SC-MCCH information, regarding a change in the first subframe available for SC-MCCH transmission in a recurrence period, it shall notify BL UEs, UEs in CE, or UEs other than NB-IoT UEs of the change." This may be interpreted as meaning that SC-MCCH change notification does not need to be limited to a certain extent at the start of a session.

[0169] If MCCH change notification is not provided during an MBS session, the UE must constantly decode the MCCH at every MCCH change boundary to check whether the MCCH has been updated. This is inefficient in terms of UE power consumption compared to decoding only the MCCH change notification. Therefore, MCCH change notification must be provided every time a configuration change occurs, not just at the start of a session.

[0170] Proposal 8: For distribution mode 2, RAN2 needs to discuss whether MCCH change notification is provided every time MCCH information is changed.

[0171] (Interest Indication / Count) To enable the network to make appropriate decisions on MBMS data delivery, including starting / stopping MBMS sessions, LTE eMBMS specifies two methods for collecting UEs' receiving / interested services: MBMS Interest Indication (MII) and MBMS Counting. The MII triggered by the UE contains information related to the target MBMS frequency, the target MBMS service, MBMS priority, and MBMS ROM (Receive Only Mode). The Counting Response triggered by the network via a Counting Request for a specific MBMS service contains information related to the target MBSFN area and MBMS service.

[0172] These methods were introduced for different purposes: the MII is primarily used by the network to ensure that the UE continues to receive the service of interest while connected, while the count is used to allow the network to determine whether a sufficient number of UEs are interested in receiving the service.

[0173] Observation 3: In LTE eMBMS, two kinds of UE assistance information are introduced for different purposes: MBMS Interest Indication for scheduling in the eNB, and MBMS Count for session control in the MCE.

[0174] For NR MBS, we agreed that MBS interest indication is supported in the RRC connected state, but not in the idle / inactive state. Based on this, it is worth considering additional enhancements to LTE eMBMS. In LTE eMBMS, even if the majority of UEs are receiving broadcast services in the RRC idle state, neither MII nor counting can collect information from idle UEs. This is, in our understanding, one of the remaining issues with LTE eMBMS from the perspective of session control and resource efficiency.

[0175] In NR MBS, the same problem can occur for idle / inactive UEs, i.e., delivery mode 2 of broadcast sessions. For example, the network does not know whether idle / inactive UEs are not receiving / interested in the broadcast service. Therefore, the network may continue to provide PTM transmissions even when no UEs are receiving the service. If the gNB knows the interest of idle / inactive UEs, it must avoid such unnecessary PTM transmissions. Conversely, if PTM stops while there are still idle / inactive UEs receiving the service, a large number of UEs may send connection requests simultaneously, which is also undesirable.

[0176] It is therefore worth considering whether to introduce a mechanism to collect UE assistance information, especially MBMS counts, from idle / inactive UEs. Needless to say, it would be desirable for these idle / inactive UEs to be able to report information without going RRC connected. This could be achieved, for example, if PRACH resource partitioning associated with MBS services were introduced for such reporting.

[0177] It is important to note that there is no MCE in NR MBS, which means that the MCE functionality is integrated within the gNB. In this sense, it is RAN2 that decides whether counting is required in NRMBS, regardless of what RAN3 decides from the network interface perspective.

[0178] Proposal 9: RAN2 needs to discuss whether MBS counts are implemented and whether they are collected from UEs in idle / inactive state.

[0179] Appendix 1 A communication control method used in a mobile communication system that provides a multicast broadcast service (MBS) from a network node to a user device, comprising: the user equipment in an RRC inactive state initiating an RRC Connection Resume procedure by sending an RRC Resume Request message to the network node during a random access procedure to resume an RRC connection; the RRC Resume Request message includes an information element indicating a reason for resuming the RRC connection; When the user equipment is in the RRC inactive state, if the RRC Connection Resume procedure is triggered for receiving an MBS multicast service, the user equipment sets the value of the information element to a predetermined value and starts the RRC Connection Resume procedure. Communication control method.

[0180] Appendix 2 1. A user equipment in communication with a network node providing a multicast and broadcast service (MBS), comprising: a control unit for initiating an RRC Connection Resume procedure by sending an RRC Resume Request message to the network node during a random access procedure when the user equipment is in an RRC inactive state, the RRC Resume Request message including an information element indicating a reason for resuming the RRC connection; When the user equipment is in the RRC inactive state, the control unit sets the value of the information element to a predetermined value and starts the RRC connection resume procedure when the RRC connection resume procedure is triggered for receiving an MBS multicast service. User equipment.

[0181] Appendix 3 A chipset for controlling a user device that communicates with a network node that provides a multicast and broadcast service (MBS), comprising: If the user equipment is in an RRC inactive state, during a random access procedure, perform a process of initiating an RRC Connection Resume procedure by sending an RRC Resume Request message to the network node, the RRC Resume Request message including an information element indicating a reason for resuming the RRC connection; The process of initiating the RRC Connection Resume procedure includes a process of setting a value of the information element to a predetermined value when the RRC Connection Resume procedure is triggered for receiving an MBS multicast service when the user equipment is in the RRC inactive state. Chipset.

[0182] Appendix 4 A user device communicating with a network node providing a multicast and broadcast service (MBS) If the user equipment is in an RRC inactive state, during a random access procedure, the user equipment performs a process of initiating an RRC Connection Resume procedure by sending an RRC Resume Request message to the network node, the RRC Resume Request message including an information element indicating a reason for resuming the RRC connection; The process of initiating the RRC Connection Resume procedure includes a process of setting a value of the information element to a predetermined value when the RRC Connection Resume procedure is triggered for receiving an MBS multicast service when the user equipment is in the RRC inactive state. program.

[0183] Appendix 5 A communication system comprising a network node providing a multicast and broadcast service (MBS) and a user device, the user equipment in an RRC inactive state initiates an RRC Connection Resume procedure by sending an RRC Resume Request message to the network node during a random access procedure, the RRC Resume Request message including an information element indicating the reason for resuming the RRC connection; When the user equipment is in the RRC inactive state, if the RRC Connection Resume procedure is triggered for receiving an MBS multicast service, the user equipment sets the value of the information element to a predetermined value and starts the RRC Connection Resume procedure. Communication system. [Explanation of symbols]

[0184] 10: Radio Access Network (NG-RAN) 20: Core network (5GC) 100: User equipment (UE) 110: Receiving unit 120: Transmitter 130: Control unit 200: Base station (gNB) 210: Transmission unit 220: Receiving unit 230: Control unit 240: Backhaul communication unit 300:AMF / UPF

Claims

1. A communication control method used in a mobile communication system that provides a multicast broadcast service (MBS) from a network node to a user device, comprising: the user equipment in an RRC inactive state initiating an RRC Connection Resume procedure by sending an RRC Resume Request message to the network node during a random access procedure to resume an RRC connection; The RRC Resume Request message includes an information element indicating a reason for resuming the RRC connection; When the user equipment is in the RRC inactive state and the RRC Connection Resume procedure is triggered for receiving an MBS multicast service, the user equipment sets the value of the information element to a predetermined value and starts the RRC Connection Resume procedure. Communication control method.

2. 1. A user equipment in communication with a network node providing a multicast and broadcast service (MBS), comprising: a control unit for initiating an RRC Connection Resume procedure by sending an RRC Resume Request message to the network node during a random access procedure when the user equipment is in an RRC inactive state, the RRC Resume Request message including an information element indicating a reason for resuming an RRC connection; If the user equipment is in the RRC inactive state, when the RRC Connection Resume procedure is triggered for receiving an MBS multicast service, the control unit sets the value of the information element to a predetermined value and starts the RRC Connection Resume procedure. User equipment.

3. 1. A chipset for controlling user equipment in communication with a network node providing a multicast broadcast service (MBS), comprising: If the user equipment is in an RRC inactive state, during a random access procedure, perform a process of initiating an RRC Connection Resume procedure by sending an RRC Resume Request message to the network node, the RRC Resume Request message including an information element indicating a reason for resuming an RRC connection; The process of initiating the RRC Connection Resume procedure includes a process of setting a value of the information element to a predetermined value when the RRC Connection Resume procedure is triggered for receiving an MBS multicast service when the user equipment is in the RRC inactive state. Chipset.

4. A user equipment communicating with a network node providing a multicast and broadcast service (MBS), comprising: If the user equipment is in an RRC inactive state, during a random access procedure, execute a process of initiating an RRC Connection Resume procedure by sending an RRC Resume Request message to the network node, the RRC Resume Request message including an information element indicating a reason for resuming an RRC connection; The process of initiating the RRC Connection Resume procedure includes a process of setting a value of the information element to a predetermined value when the RRC Connection Resume procedure is triggered for receiving an MBS multicast service when the user equipment is in the RRC inactive state. program.

5. A communication system comprising a network node providing a multicast and broadcast service (MBS) and a user equipment, the system comprising: The user equipment in an RRC inactive state initiates an RRC Connection Resume procedure during a random access procedure by sending an RRC Resume Request message to the network node, the RRC Resume Request message including an information element indicating a reason for resuming the RRC connection; When the user equipment is in the RRC inactive state and the RRC Connection Resume procedure is triggered for receiving an MBS multicast service, the user equipment sets the value of the information element to a predetermined value and starts the RRC Connection Resume procedure. Communication system.

Images