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

Abstract

To provide a communication method, user equipment, a mobile communication system, a program, and a chip set for allowing the user equipment in an RRC inactive state to perform multicast reception, in a mobile communication system providing a multicast / broadcast service (MBS).SOLUTION: User equipment UE 100, which is in a ratio resource control (RRC) inactive state and participates in a multicast session, receives a paging message for notifying the start of the multicast session from a network node gNB 200, and determines whether to make a transition from the RRC inactive state to an RRC connected state. The paging message includes session information on the multicast session, and identification information for specifying one or more pieces of user equipment UE 100 to be transitioned to the RRC connected state.SELECTED DRAWING: Figure 9

Description

[Technical Field]

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

[0002] The 3GPP (3rd Generation Partnership Project) has defined technical specifications for NR (New Radio), a fifth-generation (5G) radio access technology. Compared to LTE (Long Term Evolution), a fourth-generation (4G) radio access technology, NR offers higher speed, larger capacity, higher reliability, and lower latency. 3GPP has also defined technical specifications for 5G / NR multicast / broadcast services (MBS) (see, for example, Non-Patent Document 1). [Prior art documents] [Non-patent literature]

[0003] [Non-Patent Document 1] 3GPP Technical Specification: TS 38.300 V17.1.0 Summary of the Invention

[0004] A communication method according to a first aspect is a communication method used in a mobile communication system providing a multicast / broadcast service (MBS), and includes the steps of: a user equipment (UE) in a radio resource control (RRC) inactive state and participating in a multicast session receiving a paging message from a network node (or a network device) notifying the start of the multicast session; and a step of the user equipment determining, in response to receiving the paging message, whether to transition from the RRC inactive state to an RRC connected state. The paging message includes session information related to the multicast session and identification information associated with the session information and for identifying one or more UEs to transition to the RRC connected state among a plurality of UEs participating in the multicast session. The determining step includes a step of determining whether to transition to the RRC connected state based on the session information and the identification information.

[0005] A communication method according to a second aspect is a communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), and includes the steps of: a user equipment receiving, from a network node, configuration information that is configured individually for the user equipment; the user equipment, which is in a radio resource control (RRC) inactive state and has already joined a multicast session, receiving, from the network node, a paging message notifying the start of the multicast session; and the user equipment, in response to receiving the paging message, deciding whether to transition from the RRC inactive state to an RRC connected state. The paging message includes a session identifier that indicates the multicast session. The configuration information is information that indicates whether the user equipment is to make the decision taking the session identifier into consideration.

[0006] A communication method according to a third aspect is a communication method used in a mobile communication system providing a multicast / broadcast service (MBS), the method comprising: a step of: a user equipment (UE) in a radio resource control (RRC) inactive state and having joined a multicast session receiving, from a network node, a paging message notifying a start of the multicast session; and a step of the user equipment determining, in response to receiving the paging message, whether to transition from the RRC inactive state to an RRC connected state. The determining step includes a step of determining, when the paging message includes a session identifier indicating the multicast session in which the user equipment has joined, whether to transition to the RRC connected state based on whether the user equipment has a multicast configuration required to receive the multicast session.

[0007] A communication method according to a fourth aspect is a communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), and includes the steps of: a user equipment that is in a radio resource control (RRC) inactive state and has joined a multicast session receiving a paging message from a network node, the paging message including identification information indicating that all user equipments that have joined any of the multicast sessions are to be called; and the user equipment determining, based on the inclusion of the identification information in the paging message, to transition from the RRC inactive state to an RRC connected state. [Brief explanation of the drawings]

[0008] [Figure 1] 1 is a diagram illustrating a configuration of a mobile communication system according to an embodiment. [Figure 2] 1 is a diagram illustrating a configuration of a UE (user equipment) according to an embodiment. [Figure 3] A diagram showing the configuration of a gNB (base station) according to an embodiment. [Figure 4]FIG. 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. 10 is a diagram illustrating an operation that enables a UE in an RRC inactive state to perform multicast reception. [Figure 7] FIG. 10 is a diagram for explaining an operation of calling each UE in an RRC inactive state by group notification. [Figure 8] FIG. 1 is a diagram showing the structure of a paging message in Release 17 of the 3GPP technical specifications. [Figure 9] FIG. 4 is a diagram showing an example of a first operation pattern according to the first embodiment. [Figure 10] FIG. 6 is a diagram illustrating an example of a second operation pattern according to the first embodiment. [Figure 11] FIG. 10 is a diagram illustrating an example of UE operation in a third operation pattern according to the first embodiment. [Figure 12] FIG. 10 is a diagram illustrating an example of the operation of a mobile communication system according to a modification of the first embodiment. [Figure 13] FIG. 10 is a diagram illustrating an example of operation of the mobile communication system according to the second embodiment. [Figure 14] FIG. 10 is a diagram illustrating an example of operation of the mobile communication system according to the third embodiment. [Figure 15] FIG. 10 is a diagram illustrating an example of operation of the mobile communication system according to the fourth embodiment. DETAILED DESCRIPTION OF THE INVENTION

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

[0010] (1) First embodiment First, the first embodiment will be described.

[0011] (1.1) System Configuration FIG. 1 is a diagram showing the configuration of a mobile communication system 1 according to an embodiment. The mobile communication system 1 conforms to the 3GPP standard 5th Generation System (5GS). In the following description, 5GS is used as an example, but the mobile communication system may also be at least partially applied to an LTE (Long Term Evolution) system. The mobile communication system may also be at least partially applied to a sixth generation (6G) system.

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

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

[0014] 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 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 (hereinafter simply referred to as "frequency").

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

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

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

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

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

[0020] The control unit 130 performs various controls and processes in the UE 100. Such processes include processes of each layer described below. The operations of the UE 100 described above and below may be operations under the control of the control unit 230. 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 processes.

[0021] 3 is a diagram showing the configuration of a gNB 200 (base station) according to an embodiment. The gNB 200 includes a transmitter 210, a receiver 220, a controller 230, and a backhaul communication unit 240. The transmitter 210 and the receiver 220 constitute a wireless communication unit that performs wireless communication with the UE 100. The backhaul communication unit 240 constitutes a network communication unit that performs communication with the CN 20.

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

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

[0024] The control unit 230 performs various controls and processes in the gNB 200. Such processes include processes for each layer, which will be described later. The operations of the gNB 200 described above and below may be operations under the control of the control unit 230. 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, etc. The CPU executes programs stored in the memory to perform various processes.

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

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

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

[0028] The PHY layer performs encoding / decoding, modulation / demodulation, antenna mapping / demapping, and resource mapping / demapping. Data and control information are transmitted between the PHY layer of UE100 and the PHY layer of gNB200 via a physical channel. The PHY layer of UE100 receives downlink control information (DCI) transmitted from gNB200 on a physical downlink control channel (PDCCH). Specifically, UE100 performs blind decoding of the PDCCH using a radio network temporary identifier (RNTI) and acquires successfully decoded DCI as DCI addressed to the UE. The DCI transmitted from gNB200 has CRC parity bits scrambled by the RNTI added.

[0029] The MAC layer performs data priority control, retransmission processing using Hybrid Automatic Repeat reQuest (HARQ), random access procedures, etc. Data and control information are transmitted between the MAC layer of UE100 and the MAC layer of gNB200 via transport channels. The MAC layer of gNB200 includes a scheduler, which determines the uplink and downlink transport format (transport block size, modulation and coding scheme (MCS)) and the resource blocks to be allocated to UE100.

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

[0031] The PDCP layer performs header compression / decompression, encryption / decryption, etc.

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

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

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

[0035] 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 in accordance with the establishment, re-establishment, and release of radio bearers. When there is a connection (RRC connection) between the RRC of UE100 and the RRC of gNB200, UE100 is in an RRC connected state. When there is no connection (RRC connection) between the RRC of UE100 and the RRC of gNB200, UE100 is in an RRC idle state. When the connection between the RRC of UE100 and the RRC of gNB200 is suspended, UE100 is in an RRC inactive state.

[0036] 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 300A. Note that the UE 100 has an application layer and the like in addition to the radio interface protocol. Also, a layer lower than the NAS layer is referred to as an AS layer.

[0037] (1.2) Overview of MBS The mobile communication system 1 can perform resource-efficient distribution by using a multicast / broadcast service (MBS).

[0038] In the case of a multicast communication service (also referred to as "MBS multicast"), the same service and the same specific content data are simultaneously provided to a specific set of UEs. That is, not all UEs 100 within a multicast service area are permitted to receive the data. The multicast communication service is delivered to the UEs 100 using a multicast session, which is a type of MBS session. The UEs 100 can receive the multicast communication service in an RRC connected state using mechanisms such as Point-to-Point (PTP) and / or Point-to-Multipoint (PTM) delivery. The UEs 100 may also receive the multicast communication service in an RRC inactive (or RRC idle) state. Such a delivery mode is also referred to as "Delivery Mode 1".

[0039] In the case of a broadcast communication service (also referred to as "MBS broadcast"), the same service and the same specific content data are simultaneously provided to all UEs 100 in a geographical area. That is, all UEs 100 within the broadcast service area are authorized to receive the data. The broadcast communication service is delivered to the UEs 100 using a broadcast session, which is a type of MBS session. The UEs 100 can receive the broadcast communication service in any of the RRC idle state, RRC inactive state, and RRC connected state. Such a delivery mode is also referred to as "delivery mode 2".

[0040] The main logical channels used for MBS delivery are the Multicast Traffic Channel (MTCH), the Dedicated Traffic Channel (DTCH), and the Multicast Control Channel (MCCH). The MTCH is a PTM downlink channel for transmitting MBS data of either a multicast session or a broadcast session from the network 10 to the UE 100. The DTCH is a PTP channel for transmitting MBS data of a multicast session from the network 10 to the UE 100. The MCCH is a PTM downlink channel for transmitting MBS broadcast control information associated with one or more MTCHs from the network 10 to the UE 100.

[0041] Regarding the configuration for MBS broadcast, a UE 100 in an RRC idle state, an RRC inactive state, or an RRC connected state receives MBS configuration for a broadcast session (e.g., parameters required for MTCH reception) via the MCCH. The parameters required for MCCH reception (MCCH configuration) are provided via system information. Specifically, System Information Block Type 20 (SIB20) includes the MCCH configuration. SIB Type 21 (SIB21) includes information on service continuity for MBS broadcast reception. The MCCH provides a list of all broadcast services, including ongoing sessions, transmitted on the MTCH. The broadcast session-related information includes an MBS session identifier (e.g., a Temporary Mobile Group Identity (TMGI)), associated MTCH scheduling information, and information on neighboring cells providing specific services on the MTCH.

[0042] On the other hand, with regard to MBS multicast, in the current 3GPP technical specifications, the UE 100 can receive data of a multicast session only in the RRC connected state. When the UE 100 that has joined a multicast session is in the RRC connected state and the multicast session is activated, the gNB 200 transmits an RRC reconfiguration message including an MBS configuration for the multicast session to the UE 100. Such an MBS configuration is also referred to as a multicast radio bearer (MRB) configuration, an MTCH configuration, or a multicast configuration. Such an MRB configuration (MRB-ToAddMod) includes other parameters such as an MBS session identifier (mbs-SessionId), an MRB identifier (mrb-Identity), and a PDCP configuration (pdcp-Config) for the MRB (multicast MRB) to be configured for the UE 100.

[0043] In the following embodiment, an operation that enables the UE 100 in the RRC inactive state to perform multicast reception will be mainly described. Fig. 6 is a diagram showing an overview of the operation.

[0044] Possible solutions for the UE 100 in the RRC inactive state to perform multicast reception include a solution based on delivery mode 1 shown in FIG. 6(a) and a solution based on delivery mode 2 shown in FIG. 6(b).

[0045] In the delivery mode 1-based solution shown in Figure 6(a), in step S1, the gNB 200 transmits an RRC Reconfiguration message including an MBS configuration (multicast configuration) for a multicast session to the UE 100 in the RRC connected state. The UE 100 receives multicast data on the MTCH via the multicast session (multicast MRB) based on the multicast configuration received in the RRC Reconfiguration message.

[0046] In step S2, the gNB 200 transmits an RRC Release message to the UE 100 in the RRC Connected state to transition the UE 100 to the RRC Inactive state. The RRC Release message includes a configuration (Suspend Config.) for the RRC Inactive state.

[0047] In step S3, in response to the reception of the RRC Release message in step S2, the UE 100 transitions from the RRC connected state to the RRC inactive (INACTIVE) state.

[0048] In step S4, the UE 100 in the RRC inactive state continues to use the multicast configuration of step S1 to receive multicast data on the MTCH via the multicast session.

[0049] This enables the UE 100 in the RRC inactive state to perform multicast reception. Note that although an example of performing multicast configuration using an RRC Reconfiguration message has been described, multicast configuration may also be performed using an RRC Release message.

[0050] Both the RRC Reconfiguration message and the RRC Release message are RRC messages transmitted individually to a UE on a Dedicated Control Channel (DCCH), and are hereinafter also referred to as dedicated RRC messages.

[0051] On the other hand, in the delivery mode 2-based solution shown in Fig. 6(b), in step S11, the gNB 200 transmits an RRC Release message to the UE 100 in the RRC Connected state to transition the UE 100 to the RRC Inactive state. The RRC Release message includes a configuration for the RRC Inactive state (Suspend Config.).

[0052] In step S12, in response to the reception of the RRC Release message in step S11, the UE 100 transitions to an RRC inactive (INACTIVE) state.

[0053] In step S13, the gNB 200 transmits an MCCH including an MBS setting (multicast setting) for the multicast session. The UE 100 receives the MCCH. Note that the UE 100 receives the SIB 20 prior to receiving the MCCH, and receives the MCCH based on the SIB 20. Note that the MCCH transmission (and reception) may be performed before step S11 or simultaneously with step S11.

[0054] In step S14, the UE 100 in the RRC inactive state receives multicast data on the MTCH via the multicast session based on the multicast configuration received on the MCCH in step S13. This enables the UE 100 in the RRC inactive state to perform multicast reception.

[0055] (1.3) Group Notification When UE 100 that has joined a multicast session is in an RRC connected state and the multicast session is activated, gNB 200 transmits an RRC Reconfiguration message including an MBS configuration (i.e., multicast configuration) related to the multicast session to UE 100. If there is then (temporarily) no data to be transmitted to UE 100 for the multicast session, gNB 200 may transition UE 100 to an RRC idle state or an RRC inactive state.

[0056] Current MBS technical specifications stipulate group notification using paging messages. A gNB 200 supporting MBS notifies each UE 100 in an RRC idle state and each UE 100 in an RRC inactive state using group notification when a multicast session is activated by the core network (CN) 20 or when the gNB 200 has multicast session data to distribute. The trigger for sending such a group notification, i.e., the activation of a multicast session or the occurrence of multicast session data, is called the "start of a multicast session." The occurrence of multicast session data is also called data availability.

[0057] The paging message used as group notification includes an MBS session identifier (specifically, TMGI) for collectively calling UEs 100 in an RRC idle state and UEs 100 in an RRC inactive state that have joined the associated multicast session. This allows for collective calling of UEs in groups that have joined the multicast session, rather than calling each UE individually. Note that the paging message used as group notification is scheduled by a PDCCH to which a paging RNTI (P-RNTI) is applied. Each UE 100 in an RRC idle state and each UE 100 in an RRC inactive state that have joined the multicast session receives the group notification by monitoring a paging channel (PCCH: Paging Control Channel).

[0058] FIG. 7 is a diagram for explaining an operation of calling each UE 100 in the RRC inactive state by group notification.

[0059] In the illustrated example, each UE 100 (UE 100a to 100c) in the RRC inactive state is assumed to have already joined multicast session #A. When the gNB 200 detects the start of multicast session #A, it generates a paging message (group notification) including an identifier of multicast session #A (hereinafter referred to as "TMGI#A") and transmits the paging message. Paging in which a paging message is generated by the gNB 200 in this manner is also referred to as RAN-initiated paging.

[0060] The RRC layer of each UE 100 (UE 100a to 100c) in the RRC inactive state receives the paging message from the gNB 200 and recognizes that the paging message contains TMGI#A of the joined multicast session #A. Each UE 100 (UE 100a to 100c) in the RRC inactive state notifies its upper layer (e.g., application layer) of TMGI#A from its RRC layer, causing the upper layer to recognize the start of the joined multicast session. In response to an instruction from the upper layer, the RRC layer decides to transition to the RRC connected state. As a result, each UE 100 (UE 100a to 100c) in the RRC inactive state starts an RRC recovery process to transition to the RRC connected state.

[0061] In this way, the group notification makes it possible to collectively call a group consisting of UEs 100 (UEs 100a to 100c) in the RRC inactive state that have already participated in a multicast session. However, for example, for UEs 100 that are capable of multicast reception in the RRC inactive state (e.g., UEs 100 with valid multicast settings), it may not be necessary to transition to the RRC connected state using the group notification. When a UE 100 is in the RRC inactive state, power consumption can be reduced compared to the RRC connected state, so it is preferable for such UEs 100 to maintain the RRC inactive state from the perspective of power consumption reduction. Furthermore, if a large number of UEs 100 transition from the RRC inactive state to the RRC connected state, the load on the gNB 200 increases, which may cause network congestion.

[0062] In the following embodiments, a method will be described in which UEs 100 that have joined a multicast session and are in an RRC inactive state can be selectively called by a paging message (group notification).

[0063] Here, an example of the structure of a general paging message will be described. Fig. 8 is a diagram showing the structure of a paging message in Release 17 of the 3GPP technical specifications. Note that Fig. 8 is an excerpt from the RRC layer technical specification "TS38.331."

[0064] A paging message may include a paging record list (pagingRecordList) and / or a paging group list (pagingGroupList). A group notification is a paging message that includes a paging group list (pagingGroupList).

[0065] The paging record list (pagingRecordList) is a list consisting of one or more paging records (PagingRecord). Each paging record (PagingRecord) includes the UE identifier (ue-Identity) of the UE 100 to be called. The UE identifier (ue-Identity) is NG-5G-S-TMSI when the UE 100 is in the RRC idle state, and is I-RNTI-Value when the UE 100 is in the RRC inactive state. When the paging record list (pagingRecordList) includes its own UE identifier, the UE 100 decides to transition to the RRC connected state.

[0066] On the other hand, the paging group list (pagingGroupList) is a list consisting of one or more session identifiers (TMGI). When the UE 100 in the RRC inactive state (and the RRC idle state) that has already joined a multicast session includes the session identifier (TMGI) of the multicast session in which the UE 100 has joined in the paging group list (pagingGroupList), the UE 100 decides to transition to the RRC connected state.

[0067] (1.4) Operation according to the first embodiment In the first embodiment, a new information element associated with session information (e.g., TMGI) in a paging message is introduced in order to selectively call UEs 100 that have joined a multicast session and are in an RRC inactive state by a paging message (group notification). The new information element is identification information for identifying one or more UEs 100 that are to transition to an RRC connected state among the multiple UEs 100 that have joined the multicast session.

[0068] (1.4.1) First Operation Pattern According to the First Embodiment In the first operation pattern according to the first embodiment, the identification information is a list including the UE identifier of each UE 100 to be transitioned to the RRC connected state among the plurality of UEs 100 that have joined the multicast session. This makes it possible to selectively transition the UEs 100 specified in the list among the UEs 100 that have joined the multicast session and are in the RRC inactive state to the RRC connected state.

[0069] Specifically, in this operation pattern, UE 100, which is in the RRC inactive state and has already joined a multicast session, receives a paging message notifying the start of the multicast session from gNB 200. In response to receiving the paging message, UE 100 determines whether to transition from the RRC inactive state to the RRC connected state. The paging message includes the following information (a) and (b):

[0070] (a) Session information about a multicast session

[0071] (b) A list (also referred to as a “new UE identifier list”) that is associated with the session information and includes the UE identifier of each UE 100 that is to be transitioned to the RRC connected state among the multiple UEs 100 that have already joined the multicast session.

[0072] UE 100, which is in the RRC inactive state and has already joined a multicast session, determines whether to transition to the RRC connected state based on (a) session information and (b) the new UE identifier list. For example, UE 100 determines to transition to the RRC connected state based on the fact that session information corresponding to the multicast session in which UE 100 has joined is included in the paging message and that UE 100's own UE identifier is included in the new UE identifier list.

[0073] 9 is a diagram showing an example of a first operation pattern according to the first embodiment. It is assumed that, prior to this operation, the UE 100 has already joined the multicast session.

[0074] In step S101, the gNB 200 may transmit multicast settings required for receiving a multicast session (i.e., multicast reception) to the UE 100 in the RRC connected state in a dedicated RRC message (in the illustrated example, an RRC Reconfiguration message). The UE 100 may receive the multicast settings in the dedicated RRC message.

[0075] In step S102, the gNB 200 transmits multicast data on the MTCH via the multicast session based on the multicast configuration of step S101. The UE 100 may receive multicast data on the MTCH via the multicast session based on the multicast configuration of step S101.

[0076] In step S103, the gNB 200 transmits an RRC Release message including Suspend config. to the UE 100. The UE 100 receives the RRC Release message. The RRC Release message may include multicast settings required for receiving a multicast session.

[0077] In step S104, in response to the reception of the RRC Release message in step S103, the UE 100 transitions from the RRC connected state to the RRC inactive state.

[0078] The UE 100 that has transitioned to the RRC inactive state monitors a paging message used as group notification. The UE 100 in the RRC inactive state may wait for the start of a multicast session. Alternatively, in step S105, the UE 100 in the RRC inactive state may receive multicast data on the MTCH via the multicast session based on the multicast configuration set in step S101 or S103 (or the multicast configuration broadcast on the MCCH). The UE 100 may receive multicast data on the MTCH via the multicast session based on the multicast configuration transmitted on the MCCH from the gNB 200.

[0079] In step S106, the gNB 200 may detect the start of a multicast session. Here, it is assumed that the multicast session is multicast session #A indicated by TMGI #A. The gNB 200 determines UEs 100 to transition to an RRC connected state from among the UEs 100 that have already joined the multicast session #A and are in an RRC inactive state. In other words, the gNB 200 determines UEs 100 to maintain in an RRC inactive state from among the UEs 100 that have already joined the multicast session #A and are in an RRC inactive state.

[0080] In step S107, the gNB 200 generates a paging message to be used as the group notification and transmits the paging message on the PCCH. The UE 100 receives the paging message.

[0081] The paging message includes a paging group list (pagingGroupList), which is an example of session information. The paging group list (pagingGroupList) includes TMGI#A, which indicates the multicast session to be started.

[0082] In this operation pattern, the paging message further includes a new UE identifier list associated with the session information. The new UE identifier list is a list different from the paging record list (pagingRecordList). The new UE identifier list is a list including UE identifiers (I-RNTIs) of UEs 100 that are to transition to the RRC connected state upon the restoration of the RRC connection.

[0083] A new UE identifier list may be provided for each entry of the paging group list (pagingGroupList) (i.e., for each TMGI). In this case, the paging message may include multiple new UE identifier lists, each associated with a different multicast session (TMGI).

[0084] Alternatively, the new UE identifier list does not need to be provided for each multicast session (TMGI). For example, the new UE identifier list may be a list of UE identifiers associated with multicast session starts (not for each session) (details of such an operation will be described in the fourth embodiment).

[0085] In step S108, UE 100 in the RRC inactive state checks whether the paging message received in step S107 includes information about the session (TMGI) to which UE 100 has already participated. If the paging message does not include information about the session (TMGI) to which UE 100 has already participated (step S108: NO), UE 100 in the RRC inactive state decides to maintain the RRC inactive state without transitioning to the RRC connected state.

[0086] On the other hand, if the paging message includes information (TMGI) of the session in which the UE 100 has already participated (step S108: YES), in step S109, the UE 100 in the RRC inactive state checks whether its own UE identifier (I-RNTI) is included in the new UE identifier list in the paging message. If its own UE identifier (I-RNTI) is not included in the new UE identifier list (step S109: NO), the UE 100 in the RRC inactive state decides to maintain the RRC inactive state without transitioning to the RRC connected state.

[0087] If the paging message includes information (TMGI) of the session in which the UE 100 has participated (step S108: YES), the RRC layer of the UE 100 may notify its upper layer of the TMGI. In addition, the RRC layer may notify its upper layer that it will receive the TMGI in the RRC inactive state. This notification may be performed only when the UE identifier (I-RNTI) of the UE 100 is not included in the new UE identifier list.

[0088] If its own UE identifier (I-RNTI) is included in the new UE identifier list (step S109: YES), in step S110, UE 100 in the RRC inactive state decides to transition to the RRC connected state. In this case, in step S111, UE 100 in the RRC inactive state starts an RRC recovery procedure and transmits an RRC Resume Request message to gNB 200. By the RRC recovery procedure, UE 100 transitions from the RRC inactive state to the RRC connected state (step S112). Here, the RRC layer of UE 100 may notify upper layers that it will receive the TMGI in the RRC connected state.

[0089] If its own UE identifier (I-RNTI) is included in the new UE identifier list (step S109: YES), UE 100 may check whether it has valid multicast configuration for the joined multicast session. If it has valid multicast configuration, UE 100 may consider that multicast reception is possible in the RRC inactive state and may decide to maintain the RRC inactive state. On the other hand, if it does not have valid multicast configuration, UE 100 may consider that it needs to transition to the RRC connected state in order to acquire valid multicast configuration and may decide to transition from the RRC inactive state to the RRC connected state (step S110). Details of such an operation will be described in a third embodiment described later.

[0090] (1.4.2) Second Operation Pattern According to the First Embodiment In the first operation pattern described above, assuming that the new UE identifier list is a "list of UE identifiers for performing RRC recovery," if the gNB200 wants to transition all of the multiple UE100s that have already participated in the multicast session and are in the RRC inactive state to the RRC connected state, the gNB200 must include all UE identifiers in the list, which may increase the size of the paging message.

[0091] Therefore, in the second operation pattern, when the gNB 200 transitions all of the plurality of UEs 100 to the RRC connected state, the paging message includes all designation information instead of the new UE identifier list as identification information for identifying the UEs 100 to transition to the RRC connected state. The all designation information is identification information indicating that all of the plurality of UEs 100 that have joined the multicast session and are in the RRC inactive state are designated.

[0092] The UE 100, which has already participated in the multicast session and is in the RRC inactive state, receives the paging message. In this operation pattern, the UE 100 determines to transition to the RRC connected state based on the fact that the paging message contains session information (for example, the TMGI of the multicast session in which the UE 100 has participated) and all designation information.

[0093] 10 is a diagram showing an example of the second operation pattern according to the first embodiment. Prior to this operation, it is assumed that the UE 100 has already joined the multicast session. Here, differences from the above-described first operation pattern will be described, and overlapping descriptions will be omitted.

[0094] The operations in steps S121 to S125 are the same as those in the first operation pattern described above.

[0095] In step S126, the gNB 200 may detect the start of a multicast session. Here, it is assumed that the multicast session is multicast session #A indicated by TMGI #A. In this operation pattern, the gNB 200 determines to transition all of the multiple UEs 100 that have joined multicast session #A and are in the RRC inactive state to the RRC connected state.

[0096] In step S127, the gNB 200 generates a paging message to be used as the group notification and transmits the paging message on the PCCH. The UE 100 receives the paging message.

[0097] The paging message includes a paging group list (pagingGroupList), which is an example of session information. The paging group list (pagingGroupList) includes TMGI#A, which indicates the multicast session to be started.

[0098] In this operation pattern, the paging message further includes all designation information associated with the session information. The all designation information is identification information (for example, flag information) for designating all UE identifiers.

[0099] In the paging message, the all-designation information may be associated with any entry in the paging group list (pagingGroupList) (i.e., any TMGI). Alternatively, the all-designation information may not be provided for each multicast session (TMGI). For example, the all-designation information may be identification information that designates all UE identifiers associated with the start of a multicast session (not for each session) (details of such an operation will be described in the fourth embodiment).

[0100] In step S128, UE 100 in the RRC inactive state checks whether the paging message received in step S127 includes information about the session (TMGI) to which UE 100 has already participated. If the paging message does not include information about the session (TMGI) to which UE 100 has already participated (step S128: NO), UE 100 in the RRC inactive state decides to maintain the RRC inactive state without transitioning to the RRC connected state.

[0101] On the other hand, if the paging message includes information (TMGI) of the session in which the UE 100 has already participated (step S128: YES), in step S129, the UE 100 in the RRC inactive state checks whether the paging message includes all the designation information associated with the session information. If the paging message does not include all the designation information (step S129: NO), the UE 100 in the RRC inactive state determines to maintain the RRC inactive state without transitioning to the RRC connected state. However, if the paging message includes the above-mentioned new UE identifier list instead of the all the designation information, the UE 100 performs an operation similar to the first operation pattern described above.

[0102] If the paging message includes information about the session in which the UE 100 has participated (TMGI) (step S128: YES), the RRC layer of the UE 100 may notify its upper layer of the TMGI.

[0103] If the paging message includes the all-specification information (step S129: YES), in step S130, UE 100 in the RRC inactive state determines to transition to the RRC connected state. In this case, in step S131, UE 100 in the RRC inactive state starts an RRC recovery process and transmits an RRC Resume Request message to gNB 200. By the RRC recovery process, UE 100 transitions from the RRC inactive state to the RRC connected state (step S132).

[0104] (1.4.3) Third Operation Pattern According to the First Embodiment In the above-described first operation pattern, it is possible to selectively call UEs 100 in an RRC inactive state that have already joined a multicast session by group notification by including in the paging message a new UE identifier list that is not specified in Release 17 of the 3GPP technical specifications. Specifically, only UEs 100 specified in the new UE identifier list are transitioned from the RRC inactive state to the RRC connected state.

[0105] On the other hand, Release 17 of the 3GPP technical specifications specifies that UE 100 in the RRC inactive state decides to transition to the RRC connected state if the TMGI of a multicast session in which UE 100 has joined is included in a paging message.

[0106] Therefore, if there is a UE 100 among multiple UEs 100 in the RRC inactive state that has already participated in a multicast session that you want to transition to the RRC connected state, you can individually configure that UE 100 in advance (for example, by configuring it using a dedicated RRC message) to disable the new UE identifier list, and then you can transition that UE 100 to the RRC connected state using a paging message that includes the TMGI of that multicast session.

[0107] Alternatively, if it is desired to transition all of multiple UEs 100 that are in the RRC inactive state and have already participated in a multicast session to the RRC connected state, the new UE identifier list for each of the UEs 100 can be collectively disabled in advance (for example, by setting this via MCCH), and then the UEs 100 can be transitioned to the RRC connected state by a paging message including the TMGI for the multicast session.

[0108] That is, in the third operation pattern, the gNB 200 transmits configuration information indicating whether or not the new UE identifier list (identification information) is valid to the UE 100. The UE 100 receives the configuration information. When the configuration information indicates that the new UE identifier list (identification information) is invalid, the UE 100 determines whether or not to transition to the RRC connected state based on the session information (TMGI) in the paging message, without taking the new UE identifier list (identification information) into consideration. That is, when the configuration information indicates that the new UE identifier list (identification information) is invalid, the UE 100 performs the operation specified in Release 17 of the 3GPP technical specifications. Note that although the new UE identifier list of the first operation pattern has been described as an example, all the specified information of the second operation pattern may be handled in the same manner.

[0109] 11 is a diagram showing an example of the operation of UE 100 in the third operation pattern according to the first embodiment. Prior to this operation, it is assumed that UE 100 has already joined a multicast session. Here, differences from the first and second operation patterns described above will be explained, and overlapping explanations will be omitted.

[0110] In step S141, the UE 100 receives, from the gNB 200, configuration information for setting whether to enable or disable the new UE identifier list (and / or all specified information) in the group notification. The gNB 200 may transmit the configuration information by including it in a dedicated RRC message (an RRC Reconfiguration message or an RRC Release message). The gNB 200 may transmit the configuration information on an MCCH for the UE 100 in the RRC inactive state.

[0111] In step S142, UE100 in the RRC inactive state receives a paging message (group notification) from gNB200, which includes a paging group list (pagingGroupList) and a new UE identifier list (or all specified information).

[0112] In step S143, UE 100 in the RRC inactive state checks whether session information (TMGI) of the multicast session in which UE 100 has participated is included in the paging group list (pagingGroupList) in the paging message. If the session information (TMGI) is not included in the paging group list (pagingGroupList) (step S143: NO), UE 100 maintains the RRC inactive state.

[0113] If the session information (TMGI) is included in the paging group list (pagingGroupList) (step S143: YES), the UE 100 checks whether the new UE identifier list (and / or all the designated information) is enabled or not, based on the configuration information of step S141. If the new UE identifier list (and / or all the designated information) is disabled (step S144: NO), in step S146, the UE 100 in the RRC inactive state decides to transition to the RRC connected state, and starts the RRC recovery process.

[0114] If the new UE identifier list (and / or all the designation information) is enabled (step S144: YES), in step S145, the UE 100 in the RRC inactive state checks whether the UE 100 itself is designated in the new UE identifier list (or all the designation information) in the paging message received in step S142. If the UE 100 itself is not designated (step S145: NO), the UE 100 maintains the RRC inactive state.

[0115] If the UE 100 itself is designated (step S145: YES), in step S146, the UE 100 in the RRC inactive state decides to transition to the RRC connected state, and starts the RRC recovery process.

[0116] (1.5) Modification of the First Embodiment In the first operation pattern of the first embodiment described above, an example was described in which the new UE identifier list associated with the session information in the paging message is a list (i.e., an Allowed list) including the UE identifiers of each UE 100 that is to be transitioned to the RRC connected state among multiple UEs 100 that have already participated in the multicast session.

[0117] However, the new UE identifier list may be a list (i.e., a block list) including the UE identifier of each UE 100 that is not to be transitioned to the RRC connected state among the multiple UEs 100 that have joined the multicast session. In such a modified example, the UE 100 in the RRC inactive state determines to transition to the RRC connected state based on the session information being included in the paging message and the UE identifier of the UE 100 not being included in the new UE identifier list.

[0118] It should be noted that the paging message is not limited to including only one of the Allowed list and the Block list, and may include both the Allowed list and the Block list.

[0119] Similarly, the all-designation information described in the second operation pattern according to the first embodiment may be identification information (flag information) indicating that all of the plurality of UEs 100 are not to be transitioned to the RRC connected state. That is, when all of the plurality of UEs 100 are not to be transitioned to the RRC connected state, the paging message includes the all-designation information instead of the new UE identifier list. In such a modification, the UE 100 in the RRC inactive state includes a step of determining to transition to the RRC connected state based on the session information being included in the paging message and the all-designation information not being included in the paging message.

[0120] 12 is a diagram showing an example of operation of the mobile communication system 1 according to this modification. Prior to this operation, it is assumed that the UE 100 has already joined the multicast session. Here, differences from the first operation pattern of the first embodiment described above will be explained, and overlapping explanations will be omitted.

[0121] The operations in steps S101 to S105 are the same as those in the first embodiment.

[0122] In step S106a, the gNB 200 may detect the start of a multicast session. Here, it is assumed that the multicast session is multicast session #A indicated by TMGI #A. In this modified example, the gNB 200 determines UEs 100 that have joined multicast session #A and are in the RRC inactive state and that should not be transitioned to the RRC connected state.

[0123] In step S107a, the gNB 200 generates a paging message to be used as the group notification and transmits the paging message on the PCCH. The UE 100 receives the paging message.

[0124] The paging message includes a paging group list (pagingGroupList), which is an example of session information. The paging group list (pagingGroupList) includes TMGI#A, which indicates the multicast session to be started.

[0125] In this modification, the paging message includes a new UE identifier list (i.e., Block list) including the UE identifier of each UE 100 that is not to transition to the RRC connected state among the multiple UEs 100 that have already joined the multicast session. In the paging message, the new UE identifier list may be associated with any entry (i.e., any TMGI) of a paging group list (pagingGroupList).

[0126] In step S108a, UE 100 in the RRC inactive state checks whether the paging message received in step S107a includes information (TMGI) of the session in which UE 100 has participated. If the paging message does not include information (TMGI) of the session in which UE 100 has participated (step S108: NO), UE 100 in the RRC inactive state decides to maintain the RRC inactive state without transitioning to the RRC connected state.

[0127] On the other hand, if the paging message includes information (TMGI) of the session in which the UE 100 has already participated (step S108: YES), in step S109, the UE 100 in the RRC inactive state checks whether its own UE identifier is included in the new UE identifier list in the paging message. If its own UE identifier is included in the new UE identifier list (step S109a: YES), the UE 100 in the RRC inactive state decides to maintain the RRC inactive state without transitioning to the RRC connected state.

[0128] If the paging message includes information about the session in which the UE 100 has participated (TMGI) (step S108a: YES), the RRC layer of the UE 100 may notify its upper layer of the TMGI.

[0129] If the UE identifier of the UE 100 is not included in the new UE identifier list (step S109a: NO), in step S110a, the UE 100 in the RRC inactive state decides to transition to the RRC connected state. In this case, in step S111a, the UE 100 in the RRC inactive state starts an RRC recovery process and transmits an RRC Resume Request message to the gNB 200. By the RRC recovery process, the UE 100 transitions from the RRC inactive state to the RRC connected state (step S112a).

[0130] (2) Second embodiment Next, the second embodiment will be described, focusing mainly on the differences from the first embodiment. In this embodiment, whether or not to respond to a group notification defined in Release 17 of the 3GPP technical specifications is set in advance for each UE, thereby making it possible to selectively call UEs 100 in an RRC inactive state that have already participated in a multicast session by a group notification.

[0131] In this embodiment, the UE 100 receives configuration information that is set individually for each UE from the gNB 200. The configuration information is information indicating whether the UE 100 is to execute a decision to transition to an RRC connected state in consideration of a session identifier (TMGI) in a paging message. That is, the configuration information according to this embodiment is information that sets whether the UE 100 should ignore a paging group list (pagingGroupList) in a paging message.

[0132] UE 100, which is in an RRC inactive state and has already joined a multicast session, receives a group notification notifying the start of a multicast session, i.e., a paging message including a session identifier (TMGI) indicating the multicast session, from gNB 200. When the configuration information indicates that UE 100 is to make an RRC recovery decision taking into account the session identifier (TMGI), UE 100 determines whether to transition to an RRC connected state based on the session identifier (TMGI). On the other hand, when the configuration information indicates that UE 100 is not to make an RRC recovery decision taking into account the session identifier (TMGI), UE 100 determines whether to transition to an RRC connected state without based on the session identifier (TMGI).

[0133] 13 is a diagram showing an example of operation of the mobile communication system 1 according to this embodiment. Prior to this operation, it is assumed that the UE 100 has already joined the multicast session. Here, differences from the above-described embodiment will be described, and overlapping descriptions will be omitted.

[0134] The operations of steps S201 and S202 are the same as those of the first embodiment. However, in step S201, the gNB 200 may transmit configuration information indicating whether or not to react to the group notification to the UE 100 by using an RRC Reconfiguration message.

[0135] In step S203, the gNB 200 transmits an RRC Release message including "Suspend config." to the UE 100. The UE 100 receives the RRC Release message. The RRC Release message may include configuration information indicating whether or not to react to the group notification.

[0136] In step S204, in response to the reception of the RRC Release message in step S203, the UE 100 transitions from the RRC connected state to the RRC inactive state.

[0137] The UE 100 that has transitioned to the RRC inactive state monitors a paging message used as group notification. The UE 100 in the RRC inactive state may wait for the start of a multicast session. Alternatively, in step S205, the UE 100 in the RRC inactive state may receive multicast data on the MTCH via the multicast session based on the multicast configuration set in step S201 or S203 (or the multicast configuration broadcast on the MCCH). The UE 100 may receive multicast data on the MTCH via the multicast session based on the multicast configuration transmitted on the MCCH from the gNB 200.

[0138] In step S206, the gNB 200 may detect the start of a multicast session. Here, it is assumed that the multicast session is multicast session #A indicated by TMGI#A.

[0139] In step S207, the gNB 200 generates a paging message used as group notification and transmits the paging message on the PCCH. The UE 100 receives the paging message. The paging message includes a paging group list (pagingGroupList). The paging group list (pagingGroupList) includes a TMGI#A indicating the multicast session to be started.

[0140] In step S208, UE 100 in the RRC inactive state checks whether to respond to the group notification received in step S207 based on the configuration information in step S201 or S203. That is, UE 100 checks whether the paging group list (pagingGroupList) in the paging message received in step S207 is set to enabled or disabled. If the paging group list (pagingGroupList) is set to disabled (step S208: NO), UE 100 in the RRC inactive state does not transition to the RRC connected state but remains in the RRC inactive state.

[0141] If the paging group list (pagingGroupList) is set to valid (step S208: YES), in step S209, UE 100 in the RRC inactive state checks whether or not the paging group list (pagingGroupList) includes the session identifier (TMGI) of the multicast session in which UE 100 has participated. If the paging group list (pagingGroupList) does not include the session identifier (TMGI) of the multicast session in which UE 100 has participated (step S209: NO), UE 100 in the RRC inactive state maintains the RRC inactive state without transitioning to the RRC connected state.

[0142] If the paging group list (pagingGroupList) includes the session identifier (TMGI) of the multicast session in which UE 100 has participated (step S209: YES), UE 100 in the RRC inactive state decides to transition to the RRC connected state in step S210. Note that if the paging message includes session information (TMGI) in which UE 100 has participated (step S209: YES), the RRC layer of UE 100 may notify its upper layer of the TMGI. Then, in step S211, UE 100 in the RRC inactive state starts an RRC recovery procedure and transmits an RRC Resume Request message to gNB 200. By the RRC recovery procedure, UE 100 transitions from the RRC inactive state to the RRC connected state (step S212).

[0143] (3) Third embodiment Next, the third embodiment will be described, focusing mainly on the differences from the first and second embodiments.

[0144] As described above, when UE 100 in the RRC inactive state and having joined a multicast session has a valid multicast setting for the multicast session, UE 100 may determine to maintain the RRC inactive state even when receiving a paging message (group notification) including a session identifier (TMGI) of the multicast session. In other words, when UE 100 in the RRC inactive state and having joined a multicast session is capable of multicast reception without transitioning to the RRC connected state, UE 100 may not transition to the RRC connected state even when read by the group notification.

[0145] In this embodiment, when a paging message (group notification) contains a session identifier (TMGI) indicating a multicast session in which UE 100 has joined, UE 100 determines whether to transition to the RRC connected state based on whether UE 100 has multicast settings required to receive the multicast session. Specifically, when the paging message (group notification) contains the session identifier (TMGI), UE 100 determines to transition to the RRC connected state based on the fact that UE 100 does not have the multicast settings. On the other hand, when the paging message (group notification) contains the session identifier (TMGI), UE 100 determines to maintain the RRC inactive state based on the fact that UE 100 has the multicast settings.

[0146] 14 is a diagram showing an example of operation of the mobile communication system 1 according to this embodiment. Prior to this operation, it is assumed that the UE 100 has already joined the multicast session. Here, differences from the above-described embodiment will be described, and overlapping descriptions will be omitted.

[0147] The operations in steps S301 to S307 are the same as those in the above-described embodiment.

[0148] In step S308, UE 100 in the RRC inactive state checks whether the paging group list (pagingGroupList) in the received paging message includes the session identifier (TMGI) of the multicast session in which UE 100 has participated. If the paging group list (pagingGroupList) does not include the session identifier (TMGI) of the multicast session in which UE 100 has participated (step S308: NO), UE 100 in the RRC inactive state does not transition to the RRC connected state but remains in the RRC inactive state.

[0149] If the paging group list (pagingGroupList) includes the session identifier (TMGI) of the multicast session to which the UE 100 has joined (step S308: YES), in step S309, the UE 100 in the RRC inactive state checks whether it has multicast settings (i.e., valid multicast settings) for the multicast session to which the UE 100 has joined. If valid multicast settings are included (step S309: YES), the UE 100 in the RRC inactive state maintains the RRC inactive state without transitioning to the RRC connected state. Note that, if the paging message includes session information (TMGI) to which the UE 100 has joined (step S308: YES), the RRC layer of the UE 100 may notify its upper layer of the TMGI. Furthermore, the RRC layer may notify the upper layer that it has multicast settings related to the TMGI. The notification may be a notification to perform multicast reception in the RRC inactive state described above.

[0150] If the UE 100 does not have a valid multicast configuration (step S309: NO), in step S310, the UE 100 in the RRC inactive state decides to transition to the RRC connected state. Then, in step S311, the UE 100 in the RRC inactive state starts an RRC recovery process and transmits an RRC Resume Request message to the gNB 200. By the RRC recovery process, the UE 100 transitions from the RRC inactive state to the RRC connected state (step S312).

[0151] (4) Fourth embodiment Next, the fourth embodiment will be described, focusing mainly on the differences from the first to third embodiments.

[0152] When multiple multicast sessions are started simultaneously, multiple TMGIs are included in the paging group list (pagingGroupList) in the paging message, which may increase the size of the paging message. For example, when a video distribution application such as a television broadcast is realized using MBS, it is conceivable that multicasting will start simultaneously on all channels at a certain time. Therefore, in this embodiment, it is possible to simultaneously call all UEs 100 that are waiting for multicast sessions, regardless of TMGI.

[0153] Specifically, in this embodiment, UE 100, which is in the RRC inactive state and has joined a multicast session, receives a paging message including identification information (flag information) indicating that all UEs 100 participating in any of the multicast sessions are to be called from gNB 200. UE 100 determines to transition from the RRC inactive state to the RRC connected state based on the fact that the paging message includes the identification information. This allows the size of the paging message to be reduced because the identification information (flag information) can be included instead of the paging group list (pagingGroupList) in the paging message.

[0154] 15 is a diagram showing an example of operation of the mobile communication system 1 according to this embodiment. Prior to this operation, it is assumed that the UE 100 has already joined the multicast session. Here, differences from the above-described embodiment will be described, and overlapping descriptions will be omitted.

[0155] The operations in steps S401 to S405 are the same as those in the above-described embodiment.

[0156] In step S406, the gNB 200 detects the start of multiple multicast sessions. In this embodiment, the gNB 200 decides to simultaneously page the UE 100 for all of the multiple multicast sessions (from another perspective, multiple TMGIs). However, even when the gNB 200 detects the start of one multicast session, the gNB 200 may apply the identification information (flag information) according to this embodiment. When the gNB 200 does not apply the identification information (flag information) according to this embodiment, the gNB 200 may include a paging group list (pagingGroupList) consisting of the multiple TMGIs in the paging message.

[0157] In step S407, the gNB 200 transmits a paging message on the PCCH, the paging message including identification information (flag information) indicating that all UEs 100 participating in any multicast session are to be called. The UEs 100 in the RRC inactive state receive the paging message. The paging message does not include a paging group list (pagingGroupList).

[0158] In step S408, the UE 100 in the RRC inactive state checks whether the identification information is included in the paging message received in step S407. The identification information may be, for example, an identifier such as "MBS multicast" or "All TMGIs".

[0159] If the identification information is included in the paging message received in step S407 (step S408: YES), in step S409, UE 100 in the RRC inactive state decides to transition to the RRC connected state. In this case, the RRC layer of UE 100 may notify its upper layer of the TMGI of the multicast session to be started (the multicast session in which UE 100 has already joined). The RRC layer of UE 100 may notify its upper layer that all TMGIs will be receivable.

[0160] Then, in step S410, the UE 100 in the RRC inactive state starts an RRC recovery procedure and transmits an RRC Resume Request message to the gNB 200. As a result of the RRC recovery procedure, the UE 100 transitions from the RRC inactive state to the RRC connected state (step S411).

[0161] (5) Other embodiments In the above-described embodiment and its modifications, multicast reception in the RRC inactive state has been mainly described, but the operations according to the above-described embodiment may also be applied to multicast reception in the RRC idle state. That is, the "RRC inactive state" in the operations according to the above-described embodiment and its modifications may be read as the "RRC idle state." In the RRC idle state, RRC Resume is read as RRC Establishment.

[0162] The above-described operational flows are not limited to being implemented independently, but can also be implemented by combining two or more operational flows. For example, some steps of one operational flow may be added to another operational flow, or some steps of one operational flow may be replaced with some steps of another operational flow. In each flow, it is not necessary to execute all steps, and only some steps may be executed.

[0163] In the above-described embodiment and example, an example in which the base station is an NR base station (gNB) has been described, but the base station may be an LTE base station (eNB) or a 6G base station. The base station may also be a relay node such as an IAB (Integrated Access and Backhaul) node. The base station may also be a DU of the IAB node. The UE 100 may also be an MT (Mobile Termination) of the IAB node.

[0164] Also, the term "network node" primarily refers to a base station, but may also refer to a device in the core network or part of a base station (CU, DU, or RU).

[0165] A program may be provided that causes a computer to execute each process performed by UE100 or gNB200. The program may be recorded on a computer-readable medium. The computer-readable medium can be used to install the program 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. Furthermore, circuits that execute each process performed by UE100 or gNB200 may be integrated, and at least a part of UE100 or gNB200 may be configured as a semiconductor integrated circuit (chip set, SoC: System on a chip).

[0166] As used in this disclosure, the terms "based on" and "depending on / in response to" do not mean "based only on" or "depending only on," unless expressly stated otherwise. The term "based on" means both "based only on" and "based at least in part on." Similarly, the term "depending on" means both "depending only on" and "depending at least in part on." The terms "include," "comprise," and variations thereof do not mean including only the listed items, but may mean including only the listed items or may include additional items in addition to the listed items. Additionally, the term "or," as used in this disclosure, is not intended to mean an exclusive or. Furthermore, any reference to elements using designations such as "first," "second," etc., as used in this disclosure does not generally limit the quantity or order of those elements. These designations may be used herein as a convenient method of distinguishing between two or more elements. Thus, a 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 way. In this disclosure, where articles are added by translation, such as a, an, and the in English, these articles shall include the plural unless the context clearly indicates otherwise.

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

[0168] This application claims priority to U.S. Provisional Application No. 63 / 410,719 (filed September 28, 2022), the entire contents of which are incorporated herein by reference.

[0169] (6) Supplementary notes The following additional notes are about the features of the above-described embodiment.

[0170] (Appendix 1) A communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: a user equipment in a radio resource control (RRC) inactive state and having joined a multicast session receiving a paging message from a network node notifying the start of the multicast session; the user equipment determining whether to transition from the RRC inactive state to an RRC connected state in response to receiving the paging message; The paging message is session information relating to the multicast session; Identification information associated with the session information and for identifying one or more user equipments to be transitioned to the RRC connected state among a plurality of user equipments that have already joined the multicast session; The determining step includes a step of determining whether to transition to the RRC connected state based on the session information and the identification information. Communication method.

[0171] (Appendix 2) The identification information is a list including identifiers of each user equipment among the plurality of user equipments to be transitioned to the RRC connected state, The determining step includes determining to transition to the RRC connected state based on the session information being included in the paging message and the identifier of the user equipment being included in the list. 1. A communication method as described in Appendix 1.

[0172] (Appendix 3) When the network node transitions all of the plurality of user equipments to the RRC connected state, the paging message includes, as the identification information, all designation information instead of the list; The determining step includes a step of determining to transition to the RRC connected state based on the session information being included in the paging message and the all-specification information being included in the paging message. 2. A communication method as described in Appendix 2.

[0173] (Appendix 4) the identification information is a list including user equipment identifiers of each user equipment among the plurality of user equipments that is not to transition to the RRC connected state; The determining step includes determining to transition to the RRC connected state based on the session information being included in the paging message and a user equipment identifier of the user equipment not being included in the list. 1. A communication method as described in Appendix 1.

[0174] (Appendix 5) receiving configuration information from the network node indicating whether the identification information is valid; The determining step includes a step of determining whether to transition to the RRC connected state based on the session information without taking the identification information into consideration when the configuration information indicates that the identification information is invalid. 5. A communication method according to any one of claims 1 to 4.

[0175] (Appendix 6) The step of receiving the configuration information includes the step of receiving a dedicated RRC message including the configuration information. 1. A communication method as described in Appendix 5.

[0176] (Appendix 7) A communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: receiving, by the user equipment, configuration information to be individually configured for the user equipment from the network node; the user equipment in a radio resource control (RRC) inactive state and having joined a multicast session receiving a paging message from the network node indicating the start of the multicast session; the user equipment determining whether to transition from the RRC inactive state to an RRC connected state in response to receiving the paging message; the paging message includes a session identifier indicating the multicast session; The setting information is information indicating whether or not the user device is to make the decision taking into account the session identifier. Communication method.

[0177] (Appendix 8) The determining step includes: If the configuration information indicates that the user equipment is to make the decision taking into account the session identifier, determining whether to transition to the RRC connected state based on the session identifier; When the setting information indicates that the user equipment is not to perform the decision taking into account the session identifier, determining whether to transition to the RRC connected state without based on the session identifier. 7. A communication method as described in Appendix 7.

[0178] (Appendix 9) A communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: the user equipment being in a radio resource control (RRC) inactive state and having joined a multicast session receiving a paging message from a network node notifying the start of the multicast session; the user equipment determining whether to transition from the RRC inactive state to an RRC connected state in response to receiving the paging message; The determining step includes a step of determining whether to transition to the RRC connected state based on whether the user equipment has multicast configuration required to receive the multicast session, when the paging message includes a session identifier indicating the multicast session in which the user equipment has joined. Communication method.

[0179] (Appendix 10) The determining step includes a step of determining to transition to the RRC connected state based on the fact that the user equipment does not have the multicast configuration when the session identifier is included in the paging message. 9. A communication method as described in Appendix 9.

[0180] (Appendix 11) A communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: receiving, from a network node, a paging message including identification information indicating that the user equipment in a radio resource control (RRC) inactive state and having joined a multicast session should page all user equipments that have joined any of the multicast sessions; and determining, by the user equipment, to transition from the RRC inactive state to an RRC connected state based on the identification information being included in the paging message. Communication method.

[0181] (7) Supplementary Notes Supplementary notes regarding the above-described embodiment will be added. introduction The work item on Enhanced MBS (eMBS) aims to support multicast reception by UEs during inactivity as follows: -Specifies support for multicast reception by UEs in RRC inactive state. PTM setting for UE receiving multicast in RRC inactive state Investigating the impact of mobility and state transitions on UEs receiving multicast in RRC inactive state (seamless / lossless mobility is not required).

[0182] RAN2#119e initiated discussions for this purpose and reached a set of agreements, on which the details of multicast reception in inactive mode are discussed in this appendix.

[0183] Discussion Delivery Mode Baseline Rel-17 specifies two distribution modes: one for multicast sessions called "Distribution Mode 1" and one for broadcast sessions called "Distribution Mode 2." In Distribution Mode 1, MTCH reception is configured by RRCReconfiguration only for UEs in the connected state, while in Distribution Mode 2, MTCH reception is configured by MCCH for UEs in all RRC states.

[0184] RAN2#119e defined that these delivery modes are candidates for multicast reception in inactive mode, namely, Option 1 and Option 2.

[0185] Regarding PTM configuration distribution, RAN2 will further consider the following solutions: Option 1: Dedicated Signaling Option 2: Solution based on SIB+MCCH This does not preclude a "mix" of options.

[0186] According to the addendum submitted in RAN2#119e, support for multicast reception in inactive mode is motivated by two reasons: network congestion and UE power saving.

[0187] Observation 1: Network congestion and UE power saving are the motivations for inactive multicast reception.

[0188] According to this addendum, option 1 is superior to option 2 in terms of signaling overhead, which directly impacts network congestion. In other words, from a motivational point of view, it does not make sense to allow additional signaling overhead due to SIB20 and MCCH transmissions when the network is in a congested state.

[0189] Observation 2: The signaling overhead due to MCCH transmission is significant under conditions of network congestion.

[0190] From the perspective of a UE in inactive state, the UE performs DRX for paging monitoring, reducing power consumption. If option 2 is used for multicast reception in inactive state, the UE needs to perform additional DRX activity, i.e., MCCH monitoring, which incurs additional power consumption. Therefore, it does not match the UE's motivation to reduce power consumption.

[0191] Observation 3: MCCH monitoring activity incurs additional UE power consumption in RRC inactivity.

[0192] Of course, Option 1 requires the UE to initiate the RRCResume procedure when the MBS configuration is provided or updated. However, it clarifies that "once the MRB is configured and the session is active, the configuration will not change frequently during the session." Also, RAN2#119e agrees that "continuation of multicast services after cell reselection in the RRC inactive state (i.e., without restarting the RRC connection) is supported (if the new cell configuration is available to the UE)." Therefore, there are no major issues with network congestion or UE power consumption.

[0193] Also, Rel-17 specifies that multicast services will be provided in so-called delivery mode 1 (option 1), and there is a common understanding in RAN2 that this is a fundamental concept of multicast design. There is no reason to make such a drastic change between releases.

[0194] Considering the above, option 1 is a simple way to provide PTM configuration.

[0195] Proposal 1: RAN2 should agree that PTM configuration is provided by dedicated signaling, i.e., option 1.

[0196] RRC State Transitions In RAN2#119e, it was stated that further study was required regarding RRC state changes.

[0197] In Rel-18, multicast reception for an inactive UE supports at least the following scenarios, assuming the UE already has a valid PTM configuration: Scenario 1: The UE was receiving multicast in the Connected state, but enters the Inactive state and continues receiving multicast. Scenario 2: The UE joins a multicast session and is induced to be inactive. Further consideration is required for cases where the status changes, such as when the service is no longer provided due to inactivity.

[0198] RRC state changes can have many aspects from the network and UE perspective, so they are explained case by case below.

[0199] Subcase 1: Releasing / Stopping a Multicast Session RAN2#119e defined subcase 1 as an example.

[0200] Further consideration is required for cases where the status changes, such as when the service is no longer provided due to inactivity.

[0201] If an inactive UE is receiving an MBS service, the multicast session is released or stopped, and the gNB stops transmitting PTM / MTCH accordingly. In this case, there is no reason for the UE to continue monitoring the MTCH, but the UE must monitor the MTCH unless the PTM configuration is deleted. From the perspective of UE power saving, it is desirable for the UE to stop monitoring the MTCH as soon as possible.

[0202] Observation 4: It is inefficient in terms of UE power consumption for the UE to continue monitoring the PTM / MTCH after the multicast session has been released or deactivated.

[0203] Therefore, the UE needs to be notified by the gNB of the release / inactivation of the configured multicast session. Further study is required on whether release and inactivation should be handled separately and which signaling (e.g. MACCE or paging) should be used for this notification.

[0204] Proposal 2: When a multicast session is released or deactivated, the inactive UEs should be notified and agree to stop monitoring the PTM / MTCH as soon as possible.

[0205] Subcase 2: Selective Transition RAN2#119e reached the following agreement regarding Subcase 2: It is up to the gNB to decide whether the UE(s) can receive the multicast session inactively. What information should be provided to the gNB to make such a decision requires further study (related to the discussion in SA2). It is supported for a gNB to send one multicast session to both connected and inactive UEs in the same cell, but how the gNB configures this requires further study. It is assumed that the network can select which UEs receive in RRC Inactive and which UEs receive in RRC Connected, and can move UEs between states for multicast service reception.

[0206] When releasing a UE to inactivity, the gNB can select the UE to release based on the UE capabilities, the UE assistance information, and / or the CN assistance information (if specified), in the same way as currently, i.e., by RRC Release with Suspend Config. Therefore, no enhancements regarding selective transition of UEs are foreseen for the RRC release message.

[0207] On the other hand, when a gNB pages an inactive UE, it sends a multicast active notification, i.e., a RAN paging message that includes a TMGI. However, according to the current specification, if the paging message includes a TMGI of interest, all UEs initiate the RRCResume procedure. If the gNB includes only the UE-ID for selective paging (i.e., without a TMGI to page selected Rel-18 UEs), it cannot page Rel-17 UEs that are inactive and waiting for multicast activation. Therefore, RAN2 needs to discuss whether the multicast active notification should be extended to page a subset of UEs.

[0208] Proposal 3: RAN2 needs to discuss whether it needs to enhance multicast active notification (i.e., RAN paging using TMGI) to page a subset of UEs.

[0209] Subcase 3: QoS Enforcement RAN2#119e reached the following agreements related to Subcase 3: HARQ feedback and PTP are not supported in RRC inactive multicast reception.

[0210] According to the agreement, inactive multicast reception is similar to MBS broadcast reception (so-called delivery mode 2) specified in Rel-17. MBS broadcast is best-effort.

[0211] On the other hand, for multicast sessions, ensuring QoS / reliability is a key issue. RAN2#119e proposes the introduction of reception quality thresholds such as RSRP and BLER, which are expected to be used to ensure a certain level of QoS requirements for multicast reception. They are also useful for the network to manage QoS requirements. If inactive multicast reception cannot meet the corresponding QoS requirements, the UE should transition to connected and use HARQ feedback / retransmission or PTP (or SplitMRB) to guarantee reception quality.

[0212] Observation 5: Multicast sessions should ensure certain QoS requirements even when the UE is inactive.

[0213] Regarding the RSRP threshold, since NRMBS assumes single-cell transmission, it is considered that the UE must always transition to connected state whenever it moves to a cell edge or performs cell reselection, which may not be optimal in some deployments from the perspective of network congestion and UE power saving.

[0214] The BLER threshold is considered to be easier to ensure QoS requirements, so if RRC state transitions based on reception quality are to be introduced, these options need to be discussed.

[0215] Proposal 4: RAN2 should agree that an inactive UE transitions to connected when the reception quality becomes worse than a threshold (e.g., RSRP or BLER).

[0216] Subcase 4: Mobility and Service Continuity RAN2#119e agreed to the following statement for Subcase 4: Continuation of multicast services after cell reselection in RRC inactive state (i.e. without restarting the RRC connection) is supported (if the new cell configuration is available to the UE). Further study is needed to determine if there are cases where the UE needs to restart the connection. Also, the impact of inter-GNB mobility on RAN3 needs further study. When cell reselection to a neighboring cell occurs during an active multicast session, if the inactive UE does not have a session configuration available in the new cell, the UE must resume the RRC connection to obtain the multicast MRB configuration.

[0217] In Rel-17 Delivery Mode 1, the PTM configuration is provided by an RRCReconfiguration message, so the UE must always be in the Connected state to receive the PTM configuration. To avoid transitioning to the Connected state, an RRC Release message can be used to provide the updated PTM configuration. In this case, when the UE sends an RRCResumeRequest message, the gNB responds with an RRCRelease message containing the PTM configuration. Therefore, the UE does not need to transition to the Connected state to receive the updated PTM configuration. Such a procedure can be used during cell reselection (i.e., initiated by the UE when the PTM configuration is not available in the new cell) or RAN paging (i.e., initiated by the network when the PTM configuration needs to be updated).

[0218] Proposal 5: RAN2 should agree that RRCRelease be enhanced to provide PTM configuration.

[0219] Another issue to consider is the impact of UE mobility under the assumption that "seamless / lossless mobility is not required," as stated in the WID. In Rel-17, it is clear that the PTM configuration for delivery mode 1 is valid only in the cell where the UE is configured. When a handover is performed, the target cell reconfigures the UE with a new PTM configuration. On the other hand, when an inactive UE performs idle mode mobility, the starting point can be considered as the moment when the existing PTM configuration is no longer valid in the reselected cell (i.e., the new cell).

[0220] The simplest solution with minimal impact on the specification would be to always require an inactive UE to transition to Connected (e.g., before or after performing cell reselection) so that the UE can be handed over from the serving cell to the target cell or reconfigured by the reselected cell.

[0221] A more efficient approach would be to ensure that the PTM configuration is valid within the RNA, so the gNB must be able to apply the same configuration within the RNA of each UE. The advantage of this approach is that inactive UEs do not need to be reconfigured and can continue to receive MTCH within the RNA. However, this increases network complexity because the RNA is UE-specific.

[0222] A more flexible and less complex approach is for the gNB to provide a cell list in the configuration, whereby the configuration is considered valid for the cells in the list. The cell list can be configured as cell-specific, DU / CU-associated, UE-specific, RNA-associated, MRB area-specific, or MBS service area-specific, but this is up to the NW implementation.

[0223] Therefore, RAN2 should discuss whether to introduce area scopes with such settings.

[0224] Proposal 6: For a distribution mode 1 based solution, RAN2 should discuss whether the configuration for receiving MTCH is valid in the serving cell or in the area (e.g., RNA or cell list). [Explanation of symbols]

[0225] 1: Mobile communication system 10:RAN 20 :CN 100: UE (user equipment) 110: Receiving unit 120: Transmitter 130: Control unit 200:gNB (base station) 210: Transmission unit 220: Receiving unit 230: Control unit 240: Backhaul communication unit

Claims

1. A communication method for use in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: receiving, from a network node, a paging message indicating the start of the multicast session, by a user equipment in a radio resource control (RRC) inactive state and having joined the multicast session; determining, by the user equipment, whether to transition from the RRC inactive state to an RRC connected state in response to receiving the paging message; The paging message is session information for paging a plurality of user devices that have joined the multicast session; Configuration information including identification information of each user equipment to be transitioned to the RRC connected state among a plurality of user equipments that have already joined the multicast session; The determining step includes, when the configuration information includes identification information of the user equipment, initiating an RRC recovery procedure by the user equipment. Communication method.

2. A user equipment for use in a mobile communication system providing a multicast / broadcast service (MBS), comprising: a receiving unit configured to receive a paging message from a network node, the paging message indicating a start of the multicast session, the user equipment being in a radio resource control (RRC) inactive state and having joined a multicast session; a control unit that determines whether to transition from the RRC inactive state to an RRC connected state in response to reception of the paging message, The paging message is session information for paging a plurality of user devices that have joined the multicast session; Configuration information including identification information of each user equipment to be transitioned to the RRC connected state among a plurality of user equipments that have already joined the multicast session; The control unit starts an RRC recovery process when the configuration information includes identification information of the user equipment. User equipment.

3. A mobile communication system providing a multicast / broadcast service (MBS), comprising: a user equipment in a radio resource control (RRC) inactive state and having joined a multicast session receives a paging message from a network node notifying the start of the multicast session; The user equipment determines whether to transition from the RRC inactive state to an RRC connected state in response to receiving the paging message; The paging message is session information for paging a plurality of user devices that have joined the multicast session; Configuration information including identification information of each user equipment to be transitioned to the RRC connected state among a plurality of user equipments that have already joined the multicast session; The determining step includes, when the configuration information includes identification information of the user equipment, initiating an RRC recovery procedure by the user equipment. Mobile communication system.

4. A user equipment for use in a mobile communication system providing a multicast / broadcast service (MBS), the user equipment being in a radio resource control (RRC) inactive state and having joined a multicast session, receiving a paging message from a network node indicating the start of the multicast session; and determining whether to transition from the RRC inactive state to an RRC connected state in response to reception of the paging message; The paging message is session information for paging a plurality of user devices that have joined the multicast session; Configuration information including identification information of each user equipment to be transitioned to the RRC connected state among a plurality of user equipments that have already joined the multicast session; The process of determining includes a process of starting an RRC recovery process by the user equipment when the configuration information includes identification information of the user equipment. program.

5. A chipset for a user equipment for use in a mobile communication system providing a multicast / broadcast service (MBS), comprising: the user equipment being in a radio resource control (RRC) inactive state and having joined a multicast session, receiving a paging message from a network node indicating the start of the multicast session; determining whether to transition from the RRC inactive state to an RRC connected state in response to receiving the paging message; The paging message is session information for paging a plurality of user devices that have joined the multicast session; Configuration information including identification information of each user equipment to be transitioned to the RRC connected state among a plurality of user equipments that have already joined the multicast session; The determining step includes, when the configuration information includes identification information of the user equipment, initiating an RRC recovery procedure by the user equipment. Chipset.

Images