Communication method, user device, mobile communication system, program, and chipset
Patent Information
- Application Number
- JP2024550366
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2023-09-27
- Filing Date
- 2023-09-27
- Publication Date
- 2025-06-03
- Estimated Expiration
- 2043-09-27
Abstract
Description
Communication Method
[0001] The present disclosure relates to a communication method for use in a mobile communication system.
[0002] The 3rd Generation Partnership Project (3GPP) defines the technical specifications for NR (New Radio), a fifth-generation (5G) wireless access technology. Compared to LTE (Long Term Evolution), a fourth-generation (4G) wireless access technology, NR has features such as high speed, large capacity, high reliability, and low latency. 3GPP defines the technical specifications for 5G / NR multicast / broadcast services (MBS) (see, for example, Non-Patent Document 1).
[0003] 3GPP Technical Specification: TS 38.300 V17.1.0
[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), the method comprising 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 providing a multicast / broadcast service (MBS), the method comprising the steps of: a user equipment (UE) receiving, from a network node, configuration information to be configured individually for the UE; 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, determining whether to transition from the RRC inactive state to an RRC connected state. The paging message includes a session identifier indicating the multicast session. The configuration information is information indicating whether to cause the user equipment to make the decision taking the session identifier into account.
[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 a paging message from a network node 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, when the paging message includes a session identifier indicating the multicast session in which the user equipment has joined, determining 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.
[0008] 1 is a diagram showing the configuration of a mobile communication system according to an embodiment. FIG. 1 is a diagram showing the configuration of a UE (user equipment) according to an embodiment. FIG. 2 is a diagram showing the configuration of a gNB (base station) according to an embodiment. FIG. 3 is a diagram showing the configuration of a protocol stack of a radio interface of a user plane that handles data. FIG. 4 is a diagram showing the configuration of a protocol stack of a radio interface of a control plane that handles signaling (control signals). FIG. 5 is a diagram for explaining an operation that enables a UE in an RRC inactive state to perform multicast reception. FIG. 6 is a diagram for explaining an operation of calling each UE in an RRC inactive state by group notification. FIG. 7 is a diagram showing the configuration of a paging message in Release 17 of the 3GPP technical specifications. FIG. 8 is a diagram showing an example of a first operation pattern according to the first embodiment. FIG. 9 is a diagram showing an example of a second operation pattern according to the first embodiment. FIG. 10 is a diagram showing an example of an operation of a UE in a third operation pattern according to the first embodiment. FIG. 11 is a diagram showing an example of an operation of a mobile communication system according to a modified example of the first embodiment. FIG. 12 is a diagram showing an example of an operation of a mobile communication system according to the second embodiment. FIG. 13 is a diagram showing an example of an operation of a mobile communication system according to the third embodiment. FIG. 14 is a diagram showing an example of an operation of a mobile communication system according to a fourth embodiment.
[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). While the following description will be given using 5GS as an example, the mobile communication system may also be at least partially based on an LTE (Long Term Evolution) system. The mobile communication system may also be at least partially based on a 6th Generation (6G) system.
[0012] The mobile communication system 1 includes a user equipment (UE) 100, a 5G radio access network (NG-RAN: Next Generation Radio Access Network) 10, and a 5G core network (5GC: 5G Core Network) 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 that is used by a user. For example, the UE 100 may be a mobile phone terminal (including a smartphone) and / or a tablet terminal, a notebook PC, a communication module (including a communication card or a chipset), a sensor or a device provided in a sensor, a vehicle or a device provided in a vehicle (Vehicle UE), or an aircraft or a device provided in an aircraft (Aerial UE).
[0014] The NG-RAN 10 includes a base station (called a "gNB" in a 5G system) 200. The gNBs 200 are connected to each other via an Xn interface, which is an interface between base stations. The gNB 200 manages one or more cells. The gNB 200 performs wireless communication with a UE 100 that has established a connection with its own cell. The gNB 200 has a radio resource management (RRM) function, a routing function for user data (hereinafter simply referred to as "data"), a measurement control function for mobility control and scheduling, and the like. The term "cell" is used to indicate the smallest unit of a wireless communication area. The term "cell" is also used to indicate a function or resource for wireless communication with the UE 100. One cell belongs to one carrier frequency (hereinafter simply referred to as "frequency").
[0015] In addition, gNBs can also be connected to the Evolved Packet Core (EPC), which is the core network of LTE. LTE base stations can also be connected to 5GC. LTE base stations and gNBs can also be connected via an inter-base station interface.
[0016] The 5GC20 includes an AMF (Access and Mobility Management Function) and a UPF (User Plane Function) 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 the 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 an 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 communicates with the CN 20.
[0022] The transmitting unit 210 performs various transmissions under the control of the control unit 230. The transmitting 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 described below. 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. The CPU executes programs stored in the memory to perform various processes.
[0025] The backhaul communication unit 240 is connected to adjacent 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 is composed of a CU (Central Unit) and a DU (Distributed Unit) (i.e., functionally divided), and the two units may be connected by 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 the successfully decoded DCI as DCI addressed to the UE. The DCI transmitted from gNB200 has a CRC parity bit 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 the UE 100 and the MAC layer of the gNB 200 via a transport channel. The MAC layer of the gNB 200 includes a scheduler. The scheduler determines the uplink and downlink transport format (transport block size, modulation and coding scheme (MCS)) and the resource blocks to be allocated to the UE 100.
[0030] The RLC layer transmits data to the receiving RLC layer 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 a logical channel.
[0031] The PDCP layer performs header compression / decompression, encryption / decryption, and the like.
[0032] The SDAP layer maps IP flows, which are units for Quality of Service (QoS) control by the core network, to radio bearers, which are units for QoS control by the Access Stratum (AS). Note that if the RAN is connected to the EPC, SDAP may not be required.
[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 an RRC (Radio Resource Control) layer and an NAS (Non-Access Stratum) 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 according to the establishment, re-establishment, and release of radio bearers. When there is a connection (RRC connection) between the RRC of UE100 and the RRC of gNB200, UE100 is in an RRC connected state. When there is no connection (RRC connection) between the RRC of UE100 and the RRC of gNB200, UE100 is in an RRC idle state. When the connection between the RRC of UE100 and the RRC of gNB200 is suspended, UE100 is in an RRC inactive state.
[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 called an AS layer.
[0037] (1.2) Overview of MBS The mobile communication system 1 can perform resource-efficient distribution using multicast / broadcast services (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 permitted 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, the RRC inactive state, and the RRC connected state. This delivery mode is also referred to as "delivery mode 2".
[0040] The main logical channels used for MBS distribution 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, the UE 100 in the RRC idle state, the RRC inactive state, or the RRC connected state receives the MBS configuration for the 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, the system information block type 20 (SIB20) includes the MCCH configuration. Note that the 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., TMGI (Temporary Mobile Group Identity)), related MTCH scheduling information, and information on neighboring cells providing a specific service on the MTCH.
[0042] On the other hand, with regard to MBS multicast, in the current 3GPP technical specifications, UE 100 can only receive multicast session data in the RRC connected state. When UE 100 that has joined a multicast session is in the RRC connected state and the multicast session is activated, gNB 200 transmits an RRC reconfiguration message including MBS configuration for the multicast session to UE 100. Such MBS configuration is also referred to as multicast radio bearer (MRB) configuration, MTCH configuration, or multicast configuration. Such 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 in 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 distribution mode 1 based solution shown in FIG. 6( a) and a distribution mode 2 based solution shown in FIG. 6( b).
[0045] In the distribution mode 1-based solution shown in Figure 6 (a), in step S1, gNB200 transmits an RRC Reconfiguration message including an MBS setting (multicast setting) for the multicast session to UE100 in the RRC connected state. UE100 receives multicast data on the MTCH via the multicast session (multicast MRB) based on the multicast setting 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 setting (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 state.
[0048] In step S4, the UE 100 in the RRC inactive state continues to use the multicast setting in 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] The RRC Reconfiguration message and the RRC Release message are both 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 distribution 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 setting (Suspend Config.) for the RRC inactive state.
[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, gNB200 transmits an MCCH including an MBS setting (multicast setting) for the multicast session. UE100 receives the MCCH. Note that UE100 receives SIB20 prior to receiving the MCCH, and receives the MCCH based on SIB20. Note that MCCH transmission (and reception) may be performed before step S11 or may be performed 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 setting 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 UE100 that has joined a multicast session is in an RRC connected state and the multicast session is activated, gNB200 sends an RRC Reconfiguration message including an MBS setting (i.e., multicast setting) related to the multicast session to UE100. If there is then (temporarily) no data to be transmitted to UE100 for the multicast session, gNB200 may transition UE100 to an RRC idle state or an RRC inactive state.
[0056] The current MBS technical specifications stipulate group notification using paging messages. A gNB 200 that supports MBS uses group notification to notify each UE 100 in an RRC idle state and each UE 100 in an RRC inactive state 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 the UEs 100 in an RRC idle state and the UEs 100 in an RRC inactive state that have joined the associated multicast session. This allows for a collective call on a group basis of UEs 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 participated in multicast session #A. When 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 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 TMGI #A of the joined multicast session #A is included in the paging message. Each UE 100 (UE 100a to 100c) in the RRC inactive state notifies its upper layer (e.g., application layer) of the TMGI #A from its RRC layer, so that the upper layer recognizes the start of the joined multicast session. The RRC layer decides to transition to the RRC connected state in response to an instruction from the upper layer. 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, according to the group notification, it is possible to call a group consisting of UEs 100 (UEs 100a to 100c) in the RRC inactive state that have already participated in the 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 by group notification. When the 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, and there is a concern that network congestion may occur.
[0062] In the following embodiments, a method will be described in which the 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 an RRC idle state, and I-RNTI-Value when the UE 100 is in an RRC inactive state. If the UE 100's UE identifier is included in the paging record list (pagingRecordList), the UE 100 determines to transition to an 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 participated in a multicast session includes the session identifier (TMGI) of the multicast session in which the UE 100 has participated 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, 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), a new information element associated with session information (e.g., TMGI) in the paging message is introduced. 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 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 multiple UEs 100 that have already joined the multicast session. This makes it possible to selectively transition the UEs 100 specified in the list among the UEs 100 that have already 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 an RRC inactive state and has already joined a multicast session, receives a paging message notifying the start of the multicast session from gNB 200. UE 100 determines whether to transition from the RRC inactive state to the RRC connected state in response to receiving the paging message. The paging includes the following information (a) and (b).
[0070] (a) Session information regarding 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 identifiers of the UEs 100 that are to be transitioned to the RRC connected state among the plurality of UEs 100 that have already joined the multicast session.
[0072] UE 100, which is in an RRC inactive state and has already joined a multicast session, determines whether to transition to an RRC connected state based on (a) session information and (b) a 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 a 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 the multicast setting required for receiving the 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 setting in the dedicated RRC message.
[0075] In step S102, gNB200 transmits multicast data on MTCH via the multicast session based on the multicast setting of step S101. UE100 may receive multicast data on MTCH via the multicast session based on the multicast setting 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 a multicast session based on the multicast setting set in step S101 or S103 (or the multicast setting broadcast on the MCCH). The UE 100 may receive multicast data on the MTCH via a multicast session based on the multicast setting 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 participated in the multicast session #A and are in an RRC inactive state. That is, the gNB 200 determines UEs 100 to maintain in an RRC inactive state from among the UEs 100 that have already participated in the multicast session #A and are in an RRC inactive state.
[0080] In step S107, 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.
[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 a paging record list (pagingRecordList). The new UE identifier list is a list consisting of UE identifiers (I-RNTIs) of UEs 100 that are to transition to an RRC connected state upon recovery (resume) 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 may not be provided for each multicast session (TMGI). For example, the new UE identifier list may be a list of UE identifiers associated with a multicast session start (not for each session) (details of such an operation will be described in a fourth embodiment).
[0085] In step S108, the UE 100 in the RRC inactive state checks whether the paging message received in step S107 includes session information (TMGI) of the session in which the UE 100 has participated. If the paging message does not include session information (TMGI) of the session in which the UE 100 has participated (step S108: NO), the UE 100 in the RRC inactive state determines to maintain the RRC inactive state without transitioning to the RRC connected state.
[0086] On the other hand, if the paging message includes session information (TMGI) 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 UE identifier (I-RNTI) is included in the new UE identifier list in the paging message. If its 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] In addition, when the paging message includes session information (TMGI) 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 an RRC inactive state. The notification may be performed only when the UE 100's own UE identifier (I-RNTI) 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, the UE 100 in the RRC inactive state decides to transition to the RRC connected state. In that case, in step S111, 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 S112). Here, the RRC layer of the UE 100 may notify the upper layer that it will receive the TMGI in the RRC connected state.
[0089] If the new UE identifier list includes the UE's own UE identifier (I-RNTI) (step S109: YES), the UE 100 may check whether it has a valid multicast setting for the joined multicast session. If the UE 100 has a valid multicast setting, it may determine that multicast reception is possible in the RRC inactive state and may decide to maintain the RRC inactive state. On the other hand, if the UE 100 does not have a valid multicast setting, it may determine that it needs to transition to the RRC connected state in order to acquire a valid multicast setting 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 the third embodiment described later.
[0090] (1.4.2) Second operation pattern according to the first embodiment In the above-described first operation pattern, 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 UEs 100 that have already participated in the multicast session and are in an RRC inactive state to an 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 be transitioned to the RRC connected state. The all designation information is identification information indicating that all of the plurality of UEs 100 that have already participated in 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 an RRC inactive state, receives the paging message. In this operation pattern, the UE 100 determines to transition to an RRC connected state based on the fact that session information (for example, the TMGI of the multicast session in which the UE 100 has participated) is included in the paging message and all designation information is included in the paging message.
[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 first operation pattern described above will be explained, and overlapping explanations 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, the multicast session is assumed to be multicast session #A indicated by TMGI #A. In this operation pattern, the gNB 200 determines that all of the multiple UEs 100 that have joined the multicast session #A and are in the RRC inactive state will transition to the RRC connected state.
[0096] In step S127, 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.
[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, the UE 100 in the RRC inactive state checks whether or not the paging message received in step S127 includes session information (TMGI) of the session in which the UE 100 has participated. If the paging message does not include session information (TMGI) of the session in which the UE 100 has participated (step S128: NO), the UE 100 in the RRC inactive state determines to maintain the RRC inactive state without transitioning to the RRC connected state.
[0101] On the other hand, if the paging message includes session information (TMGI) 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 all the designation information, the UE 100 performs an operation similar to the first operation pattern described above.
[0102] In addition, if the paging message includes session information (TMGI) in which the UE 100 has participated (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, the UE 100 in the RRC inactive state determines to transition to the RRC connected state. In that case, in step S131, 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 S132).
[0104] (1.4.3) Third Operation Pattern According to First Embodiment In the above-described first operation pattern, it is possible to selectively call UEs 100 that have joined a multicast session and are in an RRC inactive state 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 a UE 100 in an RRC inactive state decides to transition to an RRC connected state if the TMGI of a multicast session in which the UE 100 has participated is included in a paging message.
[0106] Therefore, if there is a UE 100 among multiple UEs 100 in an RRC inactive state that has already participated in a multicast session that you want to transition to an RRC connected state, you can individually configure the new UE identifier list for that UE 100 in advance (for example, by configuring it using a dedicated RRC message) to be invalid, and then you can transition that UE 100 to an 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 an RRC inactive state and have already participated in a multicast session to an RRC connected state, the new UE identifier list for those UEs 100 can be collectively configured in advance (for example, configured via MCCH) to be invalid, and then those UEs 100 can be transitioned to an RRC connected state by a paging message including the TMGI of the multicast session.
[0108] That is, in the third operation pattern, the gNB 200 transmits to the UE 100 configuration information indicating whether the new UE identifier list (identification information) is valid. 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 to transition to the RRC connected state based on the session information (TMGI) in the paging message without considering the new UE identifier list (identification information). 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, the same treatment may also be applied to all the specified information of the second operation pattern.
[0109] 11 is a diagram showing an example of the operation of the UE 100 in the third operation pattern according to the first embodiment. It is assumed that the UE 100 has already joined the multicast session prior to this operation. Here, differences from the first and second operation patterns 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 designated 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 the MCCH for the UE 100 in the RRC inactive state.
[0111] In step S142, UE100 in an RRC inactive state receives a paging message (group notification) from gNB200 including a paging group list (pagingGroupList) and a new UE identifier list (or all specified information).
[0112] In step S143, the UE 100 in the RRC inactive state checks whether the session information (TMGI) of the multicast session in which the 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), the 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 setting 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 determines 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 or not 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 according to the first embodiment described above, an example has been 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 the multiple UEs 100 that have already joined 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 modified example, 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, the multicast session is assumed to be multicast session #A indicated by TMGI #A. In this modified example, the gNB 200 determines which UEs 100 among multiple UEs 100 that have already joined the multicast session #A and are in an RRC inactive state will not transition to an RRC connected state.
[0123] In step S107a, 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.
[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., a Block list) including the UE identifier of each UE 100 that is not to be transitioned to the RRC connected state among the plurality of 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, the UE 100 in the RRC inactive state checks whether the paging message received in step S107a includes information (TMGI) of the session that the UE 100 has participated in. If the paging message does not include information (TMGI) of the session that the UE 100 has participated in (step S108: NO), the UE 100 in the RRC inactive state determines to maintain the RRC inactive state without transitioning to the RRC connected state.
[0127] On the other hand, if the paging message includes session information (TMGI) 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 determines to maintain the RRC inactive state without transitioning to the RRC connected state.
[0128] In addition, if the paging message includes session information (TMGI) in which the UE 100 has already participated (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 determines to transition to the RRC connected state. In that 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 on 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 enabling UEs 100 in an RRC inactive state that have already participated in a multicast session to be selectively called by a group notification.
[0131] In this embodiment, the UE 100 receives setting information set individually for each UE from the gNB 200. The setting information is information indicating whether the UE 100 determines whether to transition to the RRC connected state in consideration of the session identifier (TMGI) in the paging message. That is, the setting information according to this embodiment is information that sets whether the UE 100 should ignore the paging group list (pagingGroupList) in the paging message.
[0132] UE100, which is in an RRC inactive state and has already joined the multicast session, receives a group notification notifying the start of the multicast session, i.e., a paging message including a session identifier (TMGI) indicating the multicast session, from gNB200. When the setting information indicates that UE100 is to execute an RRC recovery decision taking into account the session identifier (TMGI), UE100 determines whether to transition to an RRC connected state based on the session identifier (TMGI). On the other hand, when the setting information indicates that UE100 is not to execute an RRC recovery decision taking into account the session identifier (TMGI), it 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 the 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 to respond to the group notification to the UE 100 by 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 a multicast session based on the multicast setting set in step S201 or S203 (or the multicast setting broadcast on the MCCH). The UE 100 may receive multicast data on the MTCH via a multicast session based on the multicast setting transmitted on the MCCH from the gNB 200.
[0138] In step S206, gNB200 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, gNB200 generates a paging message used as group notification and transmits the paging message on the PCCH. UE100 receives the paging message. The paging message includes a paging group list (pagingGroupList). The paging group list (pagingGroupList) includes TMGI#A indicating the multicast session to be started.
[0140] In step S208, the 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, the 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), the UE 100 in the RRC inactive state maintains the RRC inactive state without transitioning to the RRC connected state.
[0141] If the paging group list (pagingGroupList) is set to be valid (step S208: YES), in step S209, the 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 the UE 100 has participated. If the paging group list (pagingGroupList) does not include the session identifier (TMGI) of the multicast session in which the UE 100 has participated (step S209: NO), the 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 the UE 100 has participated (step S209: YES), in step S210, the UE 100 in the RRC inactive state decides to transition to the RRC connected state. Note that if the paging message includes session information (TMGI) in which the UE 100 has participated (step S209: YES), the RRC layer of the UE 100 may notify its upper layer of the TMGI. Then, in step S211, 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 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 the UE 100 in the RRC inactive state that has already participated in a multicast session has a valid multicast setting for the multicast session, the 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 the UE 100 in the RRC inactive state that has already participated in a multicast session is capable of multicast reception without transitioning to the RRC connected state, the UE 100 may not need to transition to the RRC connected state even when read by the group notification.
[0145] In this embodiment, when a session identifier (TMGI) indicating a multicast session in which UE 100 has joined is included in a paging message (group notification), UE 100 determines whether to transition to an RRC connected state based on whether UE 100 has multicast settings necessary for receiving the multicast session. Specifically, when the session identifier (TMGI) is included in the paging message (group notification), UE 100 determines to transition to an RRC connected state based on the fact that UE 100 does not have the multicast settings. On the other hand, when the session identifier (TMGI) is included in the paging message (group notification), UE 100 determines to maintain an RRC inactive state based on the fact that UE 100 has the multicast settings.
[0146] 14 is a diagram showing an example of the 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, the 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 the UE 100 has participated. If the paging group list (pagingGroupList) does not include the session identifier (TMGI) of the multicast session in which the UE 100 has participated (step S308: NO), the UE 100 in the RRC inactive state maintains the RRC inactive state without transitioning to the RRC connected state.
[0149] If the paging group list (pagingGroupList) includes the session identifier (TMGI) of the multicast session in 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 in which the UE 100 has joined. If valid multicast settings are available (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) in 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 that multicast reception will be performed in the RRC inactive state.
[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 determines to transition to an 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, the paging group list (pagingGroupList) in the paging message includes multiple TMGIs, which may increase the size of the paging message. For example, when a video distribution application such as a television broadcast is implemented using MBS, it is conceivable that multicasting will start simultaneously on each channel at a certain time. Therefore, in this embodiment, it is possible to simultaneously call all UEs 100 waiting for multicast sessions, regardless of TMGI.
[0153] Specifically, in this embodiment, a UE 100 that is in an RRC inactive state and has joined a multicast session receives a paging message from the gNB 200, including identification information (flag information) indicating that all UEs 100 that have joined any of the multicast sessions are to be called. The UE 100 determines to transition from the RRC inactive state to the RRC connected state based on the inclusion of the identification information in the paging message. As a result, the identification information (flag information) can be included instead of the paging group list (pagingGroupList) in the paging message, thereby reducing the size of the paging message.
[0154] 15 is a diagram showing an example of the 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 start of multiple multicast sessions is detected. 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 identification information (flag information) according to this embodiment may be applied. When the gNB 200 does not apply the identification information (flag information) according to this embodiment, the paging group list (pagingGroupList) consisting of the multiple TMGIs may be included in the paging message.
[0157] In step S407, the gNB 200 transmits a paging message on the PCCH including identification information (flag information) indicating that all UEs 100 participating in any multicast session are to be called. UEs 100 in an 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, the UE 100 in the RRC inactive state determines to transition to the RRC connected state. In this case, the RRC layer of the UE 100 may notify its upper layer of the TMGI of the multicast session to be started (the multicast session in which the UE 100 has already joined). The RRC layer of the 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 the 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 S411).
[0161] (5) Other Embodiments In the above-described embodiment and its modified examples, multicast reception in the RRC inactive state has been mainly described, but the operation according to the above-described embodiment may be applied to multicast reception in the RRC idle state. That is, the "RRC inactive state" in the operation according to the above-described embodiment and its modified examples may be read as the "RRC idle state." In the RRC idle state, RRC restoration (Resume) is read as RRC establishment (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 embodiments and examples, 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 the UE 100 or the gNB 200. The program may be recorded on a computer-readable medium. Using a computer-readable medium, the program can be installed on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transitory recording medium. The non-transitory recording medium is not particularly limited, and may be, for example, a recording medium such as a CD-ROM or a DVD-ROM. Furthermore, circuits that execute each process performed by the UE 100 or the gNB 200 may be integrated, and at least a portion of the UE 100 or the gNB 200 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 are additional notes regarding the features of the above-described embodiment.
[0170] (Supplementary Note 1) A communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: a step 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 notifying the start of the multicast session; and a step of the user equipment deciding, in response to receiving the paging message, whether to transition from the RRC inactive state to an RRC connected state, wherein the paging message includes: session information regarding the multicast session; and identification information that is associated with the session information and is used to identify one or more user equipments that are to transition to the RRC connected state among a plurality of user equipments that have joined the multicast session; and the deciding step includes a step of deciding whether to transition to the RRC connected state based on the session information and the identification information.
[0171] (Supplementary Note 2) The communication method according to Supplementary Note 1, wherein the identification information is a list including an identifier of each user equipment among the plurality of user equipments to be transitioned to the RRC connected state, and 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 identifier of the user equipment being included in the list.
[0172] (Supplementary Note 3) The communication method according to Supplementary Note 2, wherein the paging message includes, as the identification information, all designation information instead of the list when the network node transitions all of the plurality of user equipments to the RRC connected state, and the determining step includes a step of determining to transition to the RRC connected state based on the session information and the all designation information being included in the paging message.
[0173] (Supplementary Note 4) The communication method according to Supplementary Note 1, wherein the identification information is a list including a user equipment identifier of each user equipment among the plurality of user equipments that is not to be transitioned to the RRC connected state, and 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 a user equipment identifier of the user equipment not being included in the list.
[0174] (Supplementary Note 5) The communication method according to any one of Supplementary Notes 1 to 4, further comprising the step of receiving, from the network node, configuration information indicating whether the identification information is valid or not, and wherein the determining step includes the step of determining, when the configuration information indicates that the identification information is invalid, whether to transition to the RRC connected state based on the session information without taking the identification information into consideration.
[0175] (Supplementary Note 6) The communication method according to Supplementary Note 5, wherein the step of receiving the configuration information includes the step of receiving a dedicated RRC message including the configuration information.
[0176] (Supplementary Note 7) A communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: a step in which a user equipment receives, from a network node, configuration information that is configured individually for the user equipment; a step in which the user equipment, which is in a radio resource control (RRC) inactive state and has already joined a multicast session, receives, from the network node, a paging message notifying the start of the multicast session; and a step in which the user equipment decides, in response to receiving the paging message, whether to transition from the RRC inactive state to an RRC connected state, wherein the paging message includes a session identifier that indicates the multicast session, and the configuration information is information that indicates whether the user equipment is to make the decision taking into account the session identifier.
[0177] (Supplementary Note 8) The communication method according to Supplementary Note 7, wherein the determining step includes: determining whether to transition to the RRC connected state based on the session identifier when the setting information indicates that the user equipment is to make the determination taking into account the session identifier; and determining whether to transition to the RRC connected state without based on the session identifier when the setting information indicates that the user equipment is not to make the determination taking into account the session identifier.
[0178] (Supplementary Note 9) A communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: a step of: the user equipment, which is in a radio resource control (RRC) inactive state and has joined a multicast session, receiving from a network node a paging message notifying the start of the multicast session; and a step of the user equipment, in response to receiving the paging message, deciding whether or not to transition from the RRC inactive state to an RRC connected state, wherein the deciding step includes a step of deciding whether or not to transition to the RRC connected state based on whether or not the user equipment has multicast settings 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.
[0179] (Supplementary Note 10) The communication method according to Supplementary Note 9, wherein 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.
[0180] (Supplementary Note 11) A communication method used in a mobile communication system providing a multicast / broadcast service (MBS), comprising: a step of receiving, from a network node, a paging message including identification information indicating that the user equipment, which is in a radio resource control (RRC) inactive state and has joined a multicast session, will page all user equipments that have joined any of the multicast sessions; and a step of 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.
[0181] (7) Supplementary Notes The following supplementary notes are provided for the above-mentioned embodiments. Introduction The work item on enhanced MBS (eMBS) aims to support multicast reception by UEs in inactivity as follows: - Specify support for multicast reception by UEs in RRC inactive state. - PTM configuration for UEs receiving multicast in RRC inactive state - Study the impact of mobility and state transitions on UEs receiving multicast in RRC inactive state (seamless / lossless mobility is not mandatory).
[0182] RAN2#119e has 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 delivery modes: one for multicast sessions called "Delivery Mode 1" and one for broadcast sessions called "Delivery Mode 2". In Delivery Mode 1, MTCH reception is configured by RRCReconfiguration only for UEs in Connected state, while in Delivery Mode 2, MTCH reception is configured by MCCH for UEs in all RRC states.
[0184] RAN2#119e has defined these delivery modes as candidates for multicast reception in inactive mode, namely option 1 and option 2.
[0185] For PTM configuration distribution, RAN2 further considers the following solutions: Option 1: Dedicated signaling Option 2: SIB+MCCH based solution A "mix" of options is not excluded.
[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 motivation 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 the inactive state, the UE performs DRX for paging monitoring and reduces power consumption. If option 2 is used for multicast reception in the inactive state, the UE needs to perform additional DRX activity, i.e., MCCH monitoring, which will result in additional power consumption. Therefore, it is inconsistent with 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 RRC Resume 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 be changed frequently during the session." Also, RAN2#119e agrees that "continuity of multicast service 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 problems with network congestion or UE power consumption.
[0193] Furthermore, 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 settings.
[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 is supported in at least the following scenarios, assuming that the UE already has a valid PTM configuration: - Scenario 1: The UE was receiving multicast in Connected mode, but entered Inactive mode and continues receiving multicast. - Scenario 2: The UE joined a multicast session and was induced to enter Inactive mode. Further study is required for the case where the state changes, such as when service is no longer provided in Inactive mode.
[0198] RRC state change may have many aspects from the network and UE perspective, so it will be explained case by case below.
[0199] Subcase 1: Releasing / Stopping a Multicast Session RAN2#119e has 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 needs to monitor the MTCH unless the PTM configuration is deleted. From the perspective of UE power saving, it is desirable 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 even 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 consideration is required as to 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, inactive UEs should be notified and agree to stop monitoring the PTM / MTCH as soon as possible.
[0205] Sub-case 2: Selective Transition RAN2#119e reached the following agreement for sub-case 2: It is up to the gNB to decide whether UE(s) can receive a multicast session inactively. Further study is needed on what information to provide to the gNB to make such a decision (related to the discussion of SA2). It is supported for the gNB to send one multicast session to both Connected and Inactive UEs in the same cell. How the gNB configures this needs 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's capabilities, the UE's assistance information, and / or the CN's assistance information (if specified), in the same way as currently, i.e., by RRC Release with Suspend Config. Therefore, no enhancements regarding the selective transition of UEs are foreseen for the RRC release message.
[0207] On the other hand, when the gNB pages a UE inactively, it sends a multicast active notification, i.e., a RAN paging message including a TMGI. However, according to the current specification, if the paging message includes a TMGI of interest, all UEs initiate an RRC Resume procedure. If the gNB includes only the UE-ID for selective paging (i.e., no TMGI for paging selected Rel-18 UEs), it cannot page Rel-17 UEs that are inactive and waiting for multicast activation. Therefore, RAN2 needs to discuss whether it needs to extend the multicast active notification 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] Sub-case 3: QoS Enforcement RAN2#119e has reached the following agreements related to sub-case 3: HARQ feedback and PTP are not supported for multicast reception with RRC inactive.
[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 type.
[0211] On the other hand, in multicast sessions, ensuring QoS / reliability is an important issue. RAN2#119e proposes introducing 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 must transition to Connected and use HARQ feedback / retransmission or PTP (or Split MRB) 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 needs to transition to the connected state every time it moves to a cell edge or performs cell reselection, which may not be optimal in some deployments from the viewpoint 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 will transition to connected if the reception quality becomes worse than a threshold (e.g., RSRP or BLER).
[0216] Sub-case 4: Mobility and Service Continuity RAN2#119e agreed to the following statement for sub-case 4: Continuity of multicast service after cell reselection in RRC inactive state (i.e. without restarting RRC connection) is supported (if the new cell configuration is available to the UE). Further study is needed on whether the UE may need 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 session configuration is not available in the new cell for the inactive UE, the UE needs to restart the RRC connection to obtain the multicast MRB configuration.
[0217] In Rel-17 Delivery Mode 1, the PTM configuration is provided by the RRCReconfiguration message, so the UE must always be in the Connected state to receive the PTM configuration. To avoid transitioning to the Connected state, it is possible to provide the updated PTM configuration using an RRCRelease message. 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 is 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 WID. In Rel-17, it is clear that the PTM configuration for distribution 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 specifications may 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 method is to have the PTM configuration 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 method is that inactive UEs do not need to be reconfigured and can continue to receive MTCH within the RNA. However, because the RNA is UE-specific, this increases network complexity.
[0222] A more flexible and less complicated method 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-related, UE-specific, RNA-related, 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 scope for such configurations.
[0224] Proposal 6: For a distribution mode 1 based solution, RAN2 should discuss whether the configuration for receiving MTCH is valid for the serving cell or for the area (RNA, cell list, etc.).
[0225] 1: Mobile communication system 10: RAN 20: CN 100: UE (user equipment) 110: Receiving unit 120: Transmitting unit 130: Control unit 200: gNB (base station) 210: Transmitting unit 220: Receiving unit 230: Control unit 240: Backhaul communication unit
Claims
1. A communication method used in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: A user equipment that is in a radio resource control (RRC) inactive state and has already participated in a multicast session receives a paging message for notifying the start of the multicast session from a network node; The user equipment determines whether to transition from the RRC inactive state to the RRC connected state in response to receiving the paging message; The paging message includes: Session information regarding the multicast session; Setting information that is associated with the session information and is for maintaining a user equipment that has already participated in the multicast session in the RRC inactive state; The determining includes determining whether to transition to the RRC connected state based on the session information and the setting information. A communication method.
2. A user equipment used in a mobile communication system that provides a multicast / broadcast service (MBS), comprising: A receiving unit that receives, from a network node, a paging message for notifying the start of a multicast session, wherein the user equipment is in a radio resource control (RRC) inactive state and has already participated in the multicast session; A control unit that determines whether to transition from the RRC inactive state to the RRC connected state in response to receiving the paging message; The paging message includes: Session information regarding the multicast session; Setting information that is associated with the session information and is for maintaining a user equipment that has already participated in the multicast session in the RRC inactive state; The control unit determines whether to transition to the RRC connected state based on the session information and the setting information. A user equipment.
3. A mobile communication system that provides a multicast / broadcast service (MBS), comprising: A user equipment that is in a radio resource control (RRC) inactive state and has already participated in a multicast session receives a paging message for notifying the start of the multicast session from a network node. The user equipment determines whether to transition from the RRC inactive state to the RRC connected state in response to receiving the paging message, The paging message includes session information regarding the multicast session, and setting information associated with the session information for maintaining the user equipment that has already participated in the multicast session in the RRC inactive state. The determining includes determining whether to transition to the RRC connected state based on the session information and the setting information. A mobile communication system.
4. A user equipment used in a mobile communication system that provides a multicast / broadcast service (MBS), wherein the user equipment is in an RRC inactive state and has already participated in a multicast session, and executes a process of receiving a paging message for notifying the start of the multicast session from a network node, and executes a process of determining whether to transition from the RRC inactive state to the RRC connected state in response to receiving the paging message, The paging message includes session information regarding the multicast session, and setting information associated with the session information for maintaining the user equipment that has already participated in the multicast session in the RRC inactive state. The determining process includes a process of determining whether to transition to the RRC connected state based on the session information and the setting information. A program.
5. A chipset of a user equipment used in a mobile communication system that provides a multicast / broadcast service (MBS), wherein the user equipment is in an RRC inactive state and has already participated in a multicast session, and receives a paging message for notifying the start of the multicast session from a network node, and determines whether to transition from the RRC inactive state to the RRC connected state in response to receiving the paging message, The paging message includes session information regarding the multicast session, and Configuration information for maintaining the user equipment that has participated in the multicast session in the RRC inactive state, associated with the session information, wherein the determining includes determining whether to transition to the RRC connected state based on the session information and the configuration information Chipset.