UE Configuration for Multicast Reception

Abstract

A method for setting a user equipment (UE) of a wireless communication system, which has previously participated in a multicast session, to perform multicast reception is disclosed. The method in a UE operating in a non-connected radio resource control (RRC) state (such as the RRC_INACTIVE state) includes receiving a notification indicating that the multicast session has been activated, sending an MBS setup request message for requesting setup information for receiving multicast data, and receiving an MBS setup message including the setup information for setting the UE to perform multicast data reception. A method in a base station is also disclosed.

Description

Technical Field

[0001] The present invention generally relates to configuring or setting up a user equipment (UE) of a wireless communication system for multicast reception, and more particularly to configuring or setting up multicast reception in a non-connected RRC state (e.g., RRC_INACTIVE state) including a multicast / broadcast service (MBS) radio bearer (MRB).

Background Art

[0002] Wireless communication systems are mainly deployed to address a wide range of applications, from mobile broadband, massive machine type communication to ultra-reliable low-latency communication (URLLC). Such systems enable multiple user equipments (UEs) or mobile terminals to share the wireless medium to exchange some types of data content (e.g., video, audio, messaging, etc.) via a radio access network (RAN) through one or more base stations.

[0003] Examples of such wireless multi-connection communication systems include systems based on 3rd Generation Partnership Project (3GPP (registered trademark)) standards such as the 4th Generation (4G) Long Term Evolution (LTE) or the recent 5th Generation (5G) New Radio (NR) system, or systems based on IEEE 802.11 standards such as Wi-Fi.

[0004] The requirements of 5G NR include service requirements related to multicast and broadcast services abbreviated as MBS.

[0005] In the case of broadcast communication services, the same service and the same specific content data are provided simultaneously to all UEs within a geographical area (i.e., all UEs within the broadcast service area are permitted to receive the data). Broadcast communication services are delivered to UEs using a broadcast session. In the case of multicast communication services, the same service and the same specific content data are provided simultaneously to an individual set of UEs (i.e., not all UEs within the multicast service area are permitted to receive the data). Multicast communication services are delivered to UEs using a multicast session.

[0006] With the support of multicast / broadcast technologies, the network can operate in a more efficient way than unicast. Specific use cases that can benefit from this MBS functionality include public safety and mission critical, V2X applications, IPTV, live video, and software delivery via wireless and IoT applications. 3GPP began building functional support for MBS in 5G NR in Release 17.

[0007] In 5G NR, the Radio Resource Control (RRC) protocol operates in the control plane between the UE and the base station (gNB) and provides the UE with three different states, namely, the RRC_CONNECTED state, the RRC_INACTIVE state, and the RRC_IDLE state, as defined in 3GPP specification TS 38.331. At startup, the UE is in the RRC_IDLE state and changes to the RRC_CONNECTED state when establishing an RRC connection with the gNB. When the RRC connection is released, the UE returns to the RRC_IDLE state. When in the RRC_CONNECTED state, the RRC connection can be interrupted by the gNB and the UE moves to the RRC_INACTIVE state. When the UE is in the RRC_INACTIVE state, the UE cannot communicate with the 5G system, but both the gNB and the UE continue to maintain the RRC connection context. Therefore, the transition from the RRC_INACTIVE state to the RRC_CONNECTED state is faster than the RRC connection establishment from the RRC_IDLE state to the RRC_CONNECTED state.

[0008] In 3GPP Release 17, when the UE is in the RRC_IDLE state, RRC_INACTIVE state, or RRC_CONNECTED state, the UE can receive MBS broadcasts, and MBS multicasts can only be received when the UE is in the RRC_CONNECTED state. For Release 18, the plan is to further enable MBS multicast reception when the UE is in the RRC_INACTIVE state. See, for example, Section 3 of 3GPP RP-213568 titled "New WID: Enhancements of NR Multicast and Broadcast Services" (3GPP TSG RAN Meeting#94-e, source CATT). The purpose is to make it possible to increase the density of UEs receiving multicast data from a single cell. In fact, having UEs in the RRC_INACTIVE state leads to a downsizing of the overall UE control plane footprint, thereby enabling the gNB to handle more UEs. In addition, constantly maintaining the UE in the RRC_CONNECTED state is not power-efficient. As a result, the advantage of also supporting multicast for RRC_INACTIVE state UEs has been recognized.

[0009] In Release 17, the MBS multicast session follows the state transitions defined in Figure 4.3-1 of 3GPP TS 23.247 v17.3.0. The 5G nodes involved in MBS session management are described in Section 5.1, "General Architecture," of TS 23.247 v17.3.0. In this document, "session" always refers to the "MBS session."

[0010] The session management procedures include session creation (7.1.1.2 or 7.1.1.3 of TS 23.247), session activation (7.2.5.2 of TS 23.247), and session establishment and participation (7.2.1.3 of TS 23.247).

[0011] At the beginning, there is no session. The session is created in response to a request from an AF (Application Function). As part of the creation process, an MBS session identifier is assigned, a multicast service area is determined, and the session is announced to UEs within the service area. The multicast service area is defined in 3GPP TS 22.146 version 17.0.0, section 3 "Definitions". The multicast service area is determined for each multicast service. One multicast service can initiate multiple multicast sessions. The multicast service area can be of a size less than or equal to the PLMN (Public Land Mobile Network) coverage area.

[0012] When a session is created, the first UE that sends a join request for that session triggers session establishment towards the NG-RAN ((one or more) gNBs included in the multicast service area). Subsequent join requests from other UEs do not trigger session establishment. The session establishment procedure includes PDU session establishment by the UE, session join request by the UE (associating the PDU session with the MBS session), and resource reservation from the core to the NG-RAN for the delivery of MBS data for the first join request.

[0013] Also, when a session is created, the session can be activated by triggering the MB-SMF (MBS Session Management Function). The trigger condition reflects the availability of multicast data from the application. The session activation procedure includes NG-RAN resource reservation.

[0014] The NG-RAN configures the UE to receive multicast data only when both session activation and MBS session establishment have been performed.

[0015] The start of the session activation and session establishment processes is in response to different triggers. In the case of session activation, the trigger is the availability of multicast data from the application. In the case of session establishment, the trigger is the presence of at least one UE in the service area that sends a request to join the multicast session.

[0016] The establishment of an MBS session at the UE is performed when the UE is in the RRC_CONNECTED state. Therefore, the gNB may decide to switch the UE to the RRC_INACTIVE state before MBS multicast data becomes available through session activation. As a result, when the session is activated, the NG-RAN (at least one gNB) must notify and configure the UE that is participating in the session but is in the RRC_INACTIVE state.

[0017] The current version of the specification does not provide procedures for notifying or configuring the UE in the RRC_INACTIVE state. In the RRC_INACTIVE state, the UE is not assumed to receive data from the application, and access to the control plane is restricted.

[0018] In Release 17, several mechanisms were proposed to address the case of broadcast reception in the RRC_INACTIVE state. The document TS 38.300 version 17.0.0 in section 16.10.6.2 describes the use of the MCCH (MBS control channel) by the gNB to provide configurations for UEs in any RCC state, including the RRC_INACTIVE state. In fact, the MCCH channel is accessible from UEs in the RRC_INACTIVE state and is well adapted to transmit notifications and configuration parameters. However, the MCCH is actually accessible from all UEs without security limitations for MBS multicast services, because access to multicast data requires prior authorization for each UE during the joining procedure. Multicast configurations should be made available only to UEs that have obtained the appropriate authorization during the joining procedure.

[0019] As part of the ongoing discussion regarding Release 18, document S2-2200599 proposes to switch the UE back to the RRC_CONNECTED state, execute the configuration, and then switch it back to the RRC_INACTIVE state. This solution seems to be functional, but having UEs in the RRC_INACTIVE state may prevent the goal of offloading the gNB when the UE density is high, which is due to the additional signaling and other resources required for the switch to the RRC_CONNECTED state to perform the UE configuration and then switch back to the RRC_INACTIVE state.

[0020] Therefore, it is desirable to provide at least one solution to enable UEs that have previously participated in a multicast session to be configured to receive multicast data when the multicast session is activated while they remain in the RRC_INACTIVE state. SUMMARY OF THE INVENTION

[0021] According to a first aspect of the present invention, there is provided a method for setting a user equipment (UE) of a wireless communication system, which has previously participated in a multicast session, to perform multicast reception. The method includes, in a UE operating in a non-connected radio resource control (RRC) state, receiving a notification indicating that a multicast session has been activated, transmitting an MBS setup request message for requesting setup information for receiving multicast data, and receiving an MBS setup message including setup information for setting the UE to receive multicast data.

[0022] In one example, the non-connected RRC state is the RRC_INACTIVE state.

[0023] The notification may be a paging message (e.g., a group paging message) transmitted by a base station, and may include an MBS session id for identifying the activated multicast session and an MBS session activation cause for indicating that the multicast session has been activated (e.g., by a core network).

[0024] In one example, the MBS setup request message includes an identifier for identifying the activated multicast session, such as a temporary mobile group identity (TMGI) or an MBS session id.

[0025] The setup information may include setup information for at least one MBS radio bearer (MRB).

[0026] According to a second aspect of the present invention, there is provided a method in a base station controlling a cell in which one or more user equipments (UEs) are camped, as described in claim 13 of the appended patent claims.

[0027] Therefore, the UE can be kept in the non-connected RRC state (e.g., RRC_INACTIVE state) throughout the entire process, and can obtain the settings necessary for multicast data reception as soon as they become available.

[0028] By sending a notification indicating that the multicast session has been activated by the MBS session activation, the UE can determine that the notification is related to the MBS session activation, which is useful for preventing the UE from automatically starting the RRC resume procedure and switching to the RRC_CONNECTED state. Further, by configuring the UE in the RRC_INACTIVE state after the notification that the multicast session has been activated, it is possible to avoid requiring the UE to switch to the RRC_CONNECTED state during the activation of the multicast MBS session, which means that the number of UEs in the RRC_CONNECTED state can be reduced, and as a result, the congestion in the gNB can be reduced. Further, in one example, when the notification sent by the base station is a group paging message, using the group paging message is simpler than having to page each UE individually, but a modified UE may attempt to join the session earlier in order to tamper with the multicast session. By having the MBS setting request / response protocol executed by the UE to request MBS settings, the gNB can perform an access permission check and can reject the settings for the modified UE (e.g., by not responding to the MBS setting request message sent by the modified UE).

[0029] The notification can be a group paging message transmitted by a base station and received at a UE, and the group paging message can include an identifier for identifying an activated multicast session and / or information for indicating that the multicast session has been activated. The information for indicating that the multicast session has been activated can include an MBS session activation cause. In one example, the MBS setup request message is an RRCResumeRequest message, and the MBS setup message is an RRCRelease with a suspend setup message. After receiving an MBS setup request message from a UE in a non-connected RRC state (e.g., RRC_INACTIVE), transmitting an RRCRelease with a suspend setup message is useful for preventing the UE from starting an RRC resume procedure and switching to the RRC_CONNECTED state, and thus, while still configuring the UE for the activated MBS session, maintaining the UE in the non-connected RRC state using a simple procedure (i.e., without requiring a lot of signaling).

[0030] According to a third aspect of the present invention, there is provided an apparatus for a user equipment (UE) device / apparatus as recited in claim 25 of the appended patent claims.

[0031] According to a fourth aspect of the present invention, there is provided an apparatus for a base station as recited in claim 26 of the appended claims.

[0032] Further exemplary features of the present invention are described in the other independent claims and the dependent claims.

[0033] Any feature in one aspect of the present invention may be applied, in any suitable combination, to other aspects of the present invention. In particular, method aspects may be applied to apparatus / device / unit aspects, and vice versa.

[0034] Furthermore, features implemented in hardware may be implemented in software, and vice versa. Any reference to software and hardware features in this specification should be construed accordingly. For example, according to other aspects of the present invention, there is provided a computer program including instructions which, when the program is executed by a processing unit, cause the processing unit to execute the method of any of the above aspects or examples, and a computer-readable storage medium carrying the computer program. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Various aspects of the present invention will now be described below with reference to the following drawings for purposes of illustration only.

[0036]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5a

Figure 5b

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

MODE FOR CARRYING OUT THE INVENTION

[0037] FIG. 1 shows an exemplary wireless communication system 100, and in particular, a mobile wireless communication system such as a 5th generation (5G) New Radio (NR) system that supports multicast and broadcast services (MBS). In the following description, embodiments and examples of embodiments of the present invention will be described with respect to the 5G NR system, but it should be understood that the present invention is not limited to the 5G NR system and can be used in any wireless communication system that supports MBS or similar services.

[0038] System 100 includes a user equipment (UE) 101 (or 151), which is served by a base station 110 to communicate with a core network such as a 5G core network 102, and can be, for example, inside a vehicle or part of a vehicle. The UE can be any wireless device such as a wireless communication device or apparatus or terminal, an IoT device, a machine type communication (MTC) device, a device-to-device (D2D) terminal, a user device (e.g., smartphone, laptop, mobile phone, tablet, camera, game console, wearable device), etc., capable of wirelessly communicating with one or more core networks via one or more radio access networks. The base station 110 is a network node that provides an access point to the core network for the UE and is part of a radio access network (RAN) composed of base stations 110 and 111. In NR, the base station is called a next-generation node B (gNB), the RAN is a next-generation (NG) RAN, and the core network is called a 5GC. Hereinafter, the terms RAN node, base station, and gNB are used interchangeably. The base stations 110 and 111 are interconnected using an Xn interface implemented on a wired or wireless link 130 (defined in 3GPP document TS 38.423). Each base station is connected to the core network 102 using an NG interface implemented on wired or wireless links 140 and 141 (defined in 3GPP document TS 38.413).

[0039] Each of these base stations controls one or more cells. For example, base station 110 controls cell 120, and base station 111 controls cell 121. A cell is a geographical area of a radio network defined by the frequency used in the cell for transmitting data. A cell can be uniquely identified by a UE from the identification information broadcast over the geographical area. Each base station 110, 111 can serve several UEs such as UE 101 or UE 151. When a UE establishes an RRC connection with a base station (as discussed below), the base station to which the UE is connected is called the serving base station or source base station of the UE, and the cell controlled by the serving base station and on which the UE camps is called the serving cell. The interface between the gNB and the UE is the Uu interface that uses the protocol sublayers SDAP (Service Data Adaptation Protocol), PDCP (Packet Data Convergence Protocol), RLC (Radio Link Control), MAC (Medium Access Control), PHY (Physical) in the user plane and the protocol sublayers RRC (Radio Resource Control), PDCP, RLC, MAC, PHY in the control plane.

[0040] Figure 2 shows a block diagram of a UE device 205 such as UE 101 or UE 151 of FIG. 1 in which the present invention can be implemented according to one or more embodiments of the present invention. The UE includes components for transmitting and receiving communications, including a UE communication management unit 220, an I / O controller 255, a transceiver 235, an antenna set 245, a memory 225, and a processor (CPU: Central Processing Unit) 215. All of these elements communicate with each other.

[0041] Memory 225 includes a RAM (Random Access Memory), a ROM (Read Only Memory), or a combination of both, or, as a non-limiting example, a mass storage device such as a disk or a solid state drive. Basic Input Output System (BIOS) instructions may be stored in the memory 225.

[0042] Processor 215 is configured to execute machine-readable instructions. Execution of these machine-readable instructions causes the UE to perform various functions. These functions may be related to transmission or interaction with peripheral devices such as, for example, a keyboard, a screen, a mouse, etc. (not shown in FIG. 2). The processor may execute an operating system such as, for example, iOS, windows, Android, etc. Processor 215 may be a single processor or may include two or more processors that perform the processing required for the operation of UE 205. The number of processors and the allocation of processing functions to the processors are design choices for those skilled in the art.

[0043] I / O controller 255 enables these interactions with external peripheral devices by providing the required hardware and by managing input and output signals.

[0044] Transceiver 235 is configured to provide bi-directional wireless communication with other wireless devices. For example, it provides the modems and frequency shifters required to connect to one or more wireless networks such as Wi-Fi, Bluetooth, LTE, 5G NR, etc.

[0045] Wireless communication uses an antenna set 245 adapted to the spectrum of the frequency-converted signal issued from the baseband modem. Antenna set 245 may be limited to one antenna, but preferably includes several antennas to provide beamforming capabilities.

[0046] The UE communication management unit 220 processes the establishment, control, and release of UE communication with the radio access network. The UE periodically receives from the base station an indication of the slots available for communication between the UE and the base station. Thereby, the UE grasps, regardless of whether they belong to the control plane or the data plane, where to expect incoming data or where it must transmit its outgoing data in terms of time and frequency. In an exemplary implementation, the UE communication management unit 220 implements the Uu interface.

[0047] FIG. 3 shows a block diagram of a base station device 305 such as the base stations 110 and 111 of FIG. 1 in which the present invention can be implemented according to one or more embodiments of the present invention. The base station device 305 includes components for transmitting and receiving communication, including a base station communication management unit 320, a core network communication management unit 355, a transceiver 335, an antenna set 345, a memory 325, a processor (CPU) 315, and an inter-station communication management unit 365. All of these elements communicate with each other.

[0048] The base station communication management unit 320 processes communication with a plurality of UEs. It is involved in the establishment, control, and release of these communications. In an exemplary implementation, the base station communication management unit 320 implements the Uu interface. The base station communication management unit 320 includes a scheduler that allocates time-frequency slots for different UE communications. Information regarding the schedule of these slots is periodically transmitted to the UEs involved.

[0049] The core network communication management unit 355 manages the communication of the base station with the core network. It may provide a standardized NG interface as defined by 3GPP standards to support these communications.

[0050] The transceiver 335 is configured to provide bi-directional wireless communication with other wireless devices. These devices can be UEs or even other base stations. The transceiver 335 provides the modems and frequency shifters necessary to simultaneously connect to multiple UEs using different multiple frequency carriers in Time Division Duplex (TDD) or Frequency Division Duplex (FDD). The transceiver 335 is connected to an antenna set 345, which may be limited to one antenna, but preferably includes several antennas to provide beamforming capabilities.

[0051] The memory 325 includes a RAM, a ROM, or a combination of both, or as a non-limiting example, a mass storage device such as a disk or a solid state drive. BIOS instructions can be stored in the memory 325 to support the operating system.

[0052] The inter-site communication management unit 365 manages communications with other base stations. The inter-site communication management unit 365 can provide a standardized Xn interface as defined by the 3GPP standards to support these communications.

[0053] Figure 4 is a flowchart 400 showing the RRC connection states and transitions for a UE in 5G NR. The RRC protocol operates between the UE and the base station (gNB) and is defined in the 3GPP specification TS 38.331 for 5G NR. The state names of the UE are prefixed with "NR" for New Radio. Other prefixes are used for other radio interfaces such as the LTE radio interface. For simplicity, the radio technology prefixes are omitted in the following description.

[0054] Radio Resource Control (RRC) is a layer within the 5G NR protocol stack. It exists only in the control plane, UE, and gNB. The behavior and functions of the base station and UE are governed by the current RRC state of the UE. In 5G NR, three distinct RRC states are defined for the UE: the RRC_IDLE state 401, the RRC_CONNECTED state 402, and the RRC_INACTIVE state 403.

[0055] At startup, the UE is in the RRC_IDLE state 401. The UE performs radio link quality measurements and executes a cell selection evaluation process (as defined in 3GPP specification TS 38.304) to identify the target gNB of the connection. The UE state changes to the RRC_CONNECTED state 402 in response to the establishment of an RRC connection with the target gNB that becomes the serving gNB for the UE. Hereinafter, the source base station (or source gNB) may also be referred to as the serving base station or serving gNB. If there is no radio activity for some time, the RRC connection may be released by the source gNB, and the RRC state of the UE changes back to the RRC_IDLE state 401.

[0056] Releasing the RRC connection is interesting for capacity utilization and power saving, but it is not ideal from the perspective of latency. The overhead when establishing the RRC connection requires additional signaling that causes delay. To address this drawback, the RRC_INACTIVE state 403 has been introduced in 5G NR. When the UE is in the RRC_INNACTIVE state 403, the UE cannot communicate with the 5G system, but both the source gNB (e.g., the last serving gNB) and the UE save the UE context or configuration. The saved UE context or configuration contains information for facilitating the quick resumption of the connection. The information may include the security context (e.g., security parameters such as security keys, UE security capabilities, etc.), measurement settings, radio settings (e.g., UE radio capabilities), information regarding bearers, PDU session context, etc. For this reason, when in the RRC_CONNECTED state 402, the RRC connection may be suspended by the source gNB (Release with suspend), and the UE transitions to the RRC_INACTIVE state 403. From the RRC_INACTIVE state 403, the UE may be switched back to the RRC_CONNECTED state 402 by the gNB (Resume), and the UE applies the saved UE context or configuration. The RRC resume message is sent by the gNB in response to receiving the RRC resume request message from the UE.

[0057] The UE can transition from either the RRC_CONNECTED state or the RRC_INNACTIVE state to the RRC_IDLE state in response to an RRC release command received from the gNB.

[0058] The mobility procedure for moving a UE from one cell to another depends on the RRC state of the UE. In the RRC_CONNECTED state, the mobility procedure called handover is controlled by the network, and the source gNB makes a decision to trigger the handover procedure based on the measurement reports provided by the UE. In the RRC_INACTIVE and RRC_IDLE states (e.g., non-connected state), the mobility procedure is called cell reselection and is managed by the UE itself.

[0059] In the RRC_INACTIVE state, a RAN notification area (RNA) can be set for the UE by the network. For example, the message that transitions the UE to the RRC_INACTIVE state includes information indicating the RNA. The RNA is an area where the UE can move without notifying the network. When a UE in the RRC_INACTIVE state moves to a cell that is not part of the currently assigned RNA, the UE performs a location update procedure that enables the RAN (e.g., the serving gNB) to update the RNA assigned to the UE. In other words, the UE has the possibility to request an RNA update to inform about the change of the RNA. As part of the cell reselection process, when the UE selects a cell managed by the target gNB from the RNA, the UE sends a resume request to the target gNB, which has three available options: to keep the UE in the RRC_INACTIVE state, to set the UE to the RRC_IDLE state, or to set the UE to the RRC_CONNECTED state.

[0060] In the RRC_IDLE state, paging procedures are initiated by the core network to notify the UE that it has to resume the connection. In the RRC_INACTIVE state, the paging procedures are initiated by the NG RAN (i.e., the last gNB that set the UE to the RRC_INACTIVE state).

[0061] Returning to FIG. 1, UE 101 is assumed to be in the RRC_INACTIVE state and receiving multicast data of one or more multicast MBS sessions generated by multicast application server 103. The multicast data is provided to base station 111, which controls cell 121 on which UE 101 is camped, via link 141, through core network 102 and transport bearer 106 (also known as a GTP-U tunnel). Thereafter, the multicast data is transmitted from base station 111 to UE 101 through MBS radio bearer (MRB) 154. FIG. 1 further shows that UE 151 is receiving data through MRB 153. In point-to-multipoint transmission of data from base station 111, MRB 154 is the same MRB as MRB 153. In point-to-point transmission, MRB 154 and 153 are different. A radio bearer is a set of PHY (layer 1) parameters and MAC (layer 2) parameters that enables an upper layer data connection between a UE and a gNB. In 5G NR, multiple types of radio bearers are defined, including SRB (Signalling Radio Bearer) for the control plane, DRB (Data Radio Bearer) that enables point-to-point communication (unicast) with one UE in the user plane, and MRB that enables both point-to-point communication and point-to-multipoint communication (multicast / broadcast) with multiple UEs in the user plane.

[0062] The MBS session participation procedure is used by the UE to notify the 5GC of the interest in participating in a multicast MBS session, as defined in 3GPP TS 23.247. The first received UE participation request triggers the establishment of the multicast MBS session for the NG RAN and the UE. Before sending a participation request for the multicast MBS session, the UE must establish a PDU session that can be associated with the (one or more) multicast sessions, using the procedures as defined in TS 23.502. Further, the UE must know at least the MBS session id of the multicast group(s) that the UE can participate in, via the service announcements broadcast by the network. To participate in a multicast group, the UE sends a PDU session modification request for the associated PDU session, including one or more MBS session ids and the participation request. The (one or more) MBS session ids indicate the (one or more) multicast MBS sessions that the UE wishes to participate in.

[0063] To participate in an MBS session, the UE must be in the RRC_CONNECTED state.

[0064] Figures 5a and 5b both show exemplary message flows for an exemplary scenario of the MBS session development from creation to activation. Figure 5a shows an exemplary message flow for the creation and establishment of an MBS session, and Figure 5b shows an exemplary message flow for the activation of the MBS session.

[0065] Referring initially to FIG. 5a, a UE, e.g., UE 101 (which could also be UE 151), boots up and enters the RRC_IDLE state 500. During step 501, the UE connects to the nearest gNB as a result of the cell selection process defined in section 5.2.3 of TS 38.304 (e.g., in the case of FIG. 1, UE 101 connects to gNB 111). Once connected to the gNB, the UE enters the RRC_CONNECTED state 502. Thereafter, the UE executes a registration process, i.e., procedure 503, which aims at the identification of the UE in the core network, i.e., 5GC 102, the checking of the UE subscription, and the application of authorisations. The registration procedure is detailed in section 4.2.2.2 of TS 23.502.

[0066] After registration, the UE creates a first PDU session via the PDU session establishment procedure 504. The first PDU session is a default PDU session that enables access to 5G core services. This PDU session may later be associated with an MBS session. The PDU session establishment procedure is defined in section 4.3.2 of TS 23.502.

[0067] The AF (Application Function) 104 creates a multicast session in the 5G core 102 in response to a request from the application server 103. The MBS session creation procedure 505 for creating a multicast session is defined in section 7.1.1 of TS 23.247. The creation of the session is controlled by the AF 104 (Application Function) and upon completion, an MBS session id (e.g., TMGI for Temporary Mobile Group Identity) is assigned for the multicast session and the session creation.

[0068] When a multicast session is created, the AF 104 performs a service announcement 506 towards the UE. For example, the AF 104 sends a service announcement message. The service announcement message contains multicast session information, and the multicast session information includes, among other things, the multicast MBS session id, service area description (or information), and session description information. The service announcement is described in section 6.11 of TS 23.247. Some UEs may not need to receive the service announcement message. For example, the service information provided in the service announcement may be pre-configured in some UEs. Also, UEs that are not connected during the service announcement can access the service information by directly querying the AF 104 (application function) or MBSF (MBS service function) within the core network 102.

[0069] (Collectively identified by reference sign 521) There is no timing dependency between the UE connection / registration / PDU session establishment procedure and the (collectively identified by reference sign 522) MBS session creation / announcement procedure. Both 521 and 522 are executed independently of each other and may occur at any time.

[0070] Once the UE 101 is registered with the core network 102, the default PDU session is established, and the multicast service information is obtained, the UE can participate in the multicast session by sending or executing a join request 507 to the core network 102. The multicast session information (such as the multicast MBS session id as described above) is obtained by the UE after receiving the service announcement message 506, or by pre - configuration, or by querying information from the core network (the message flows for pre - configuration or querying of session information are not shown in Figure 5a or Figure 5b). To participate in the multicast session, the UE can reuse the previously created default PDU session (at 504) and send a PDU session modification request that includes the multicast session id (TMGI). As a result, the PDU session modification request is considered a join request (507). Another possibility is to establish a dedicated MBS PDU session that includes the multicast session id for the join request 507.

[0071] Upon receiving the join request 507, the core network 102 executes the multicast session establishment procedure 508. During the session establishment procedure 508, the core network 102 verifies the UE's subscription and authorization level and checks whether the UE is permitted to access the multicast session (i.e., checks whether the UE is one of the specific multicast groups for which the UE is permitted to receive the multicast session). Also, as part of the session establishment procedure 508, the core network 102 sets up the resources necessary in the core network to carry the multicast data from the application server 103 to the relevant gNB. The relevant gNB is defined by the multicast service area information established in the session creation step 505. The join procedure 507 and the multicast session establishment procedure 508 are defined in Section 7.2.1 of TS 23.247.

[0072] In the example shown in Figure 5a, the gNB of the NG-RAN (e.g., gNB 111) determines to switch the UE 101 to the RRC_INACTIVE state 510 by transmitting an RRC Release message 509 (Section 6.2.2 of TS 38.331). The most common reason is load management, and the gNB determines to offload its control plane load by switching some UEs to RRC_INACTIVE. Also, ongoing discussions for Release 18 propose that both the UE and the core network provide additional information to the gNB to assist the gNB in making the decision to switch some UEs to the RRC_INACTIVE state. The additional information may include capacity information from both the UE and the core network indicating the ability to transmit or receive multicast data in the RRC_INACTIVE state. Other information may also be provided by the UE to indicate the preferred state for receiving multicast data, i.e., RRC_INACTIVE or RRC_CONNECTED.

[0073] Referring also to Figure 5b here, when the UE is in the RRC_INACTIVE state 510, the UE performs a cell reselection process 511 as a background task. This process manages UE mobility and enables the UE to "reselet" a new gNB according to the new UE location. Cell reselection is described in detail in Section 5.2.4 of TS 38.304. In this example, it is assumed that depending on the movement of the UE, the NG-RAN node is either gNB 110 or gNB 111.

[0074] When an MBS session is created (505), the AF 104 (Application Function) within the core network 102 can be triggered to activate the multicast session (i.e., MBS session activation 512). The trigger for activating the multicast session is independent of the join and session establishment procedures (collectively identified by reference numeral 523). One possible trigger is the availability of data from the application server 103. Multicast session activation is described in Section 7.2.5.2 of TS 23.247. The main result of this procedure is the reservation of RAN (Radio Access Network) resources by the gNB. These resources enable the communication of multicast data to UEs that are already participating in the multicast session. RAN resource allocation includes MRB configuration (MBS radio bearer configuration). Each gNB uses specific settings for the MRB for the multicast session.

[0075] When the multicast session is activated upon completion of MBS session activation 512, the core network 102 may need to page some UEs to notify them of the availability of multicast data. RRC_INACTIVE UEs need to be paged because, as explained at 510, although RRC_INACTIVE UEs are still in a mobile state and can enter the cell of another gNB, neither the new gNB (target gNB) nor the first gNB (source gNB) recognizes the movement of the UE at this step (i.e., at the timing when the multicast session is activated 512). The core network 102 sends a group page request to the gNB having the MBS session id (not shown in Figure 5b), and then each gNB sends a request for group paging 513 having the multicast session id.

[0076] Upon receiving the group page message 513, the RRC_INACTIVE UE must prepare to resume the RRC connection during process 515.

[0077] As part of the preparation for resuming the RRC connection, UE 101 executes a random access procedure towards the gNB (PRACH procedure 516, where PRACH represents the physical random access channel). The PRACH procedure aims to update the UE's system information when the UE moves to another cell or when the UE's system information has not been updated for some time. Subsequently, UE 101 executes and completes a connection resumption procedure that includes transmitting an RRCResumeRequest message (not shown in Figure 5b) at 517. The connection resumption procedure 517 follows the RRC connection procedure detailed in TS 38.331.

[0078] When the RRC connection procedure is completed, the UE is in the RRC_CONNECTED state 518.

[0079] Only in the steps when UE 101 is in the RRC_CONNECTED state 518, gNB 111 can transmit a multicast configuration (including MRB information) to the UE in step 519. This step includes transmitting an RRCReconfiguration message (Section 6.2.2 of TS 38.331) that contains the MRB information.

[0080] When the UE applies the received multicast configuration, it can receive multicast data at 520.

[0081] As described in the introduction section, if the UE has to switch from the RRC_INACTIVE state to the RRC_CONNECTED state to perform the settings for multicast reception, the additional signaling and other resources required to configure the UE in the RRC_CONNECTED state will cause a load problem in the NG-RAN node (gNB), i.e., there are too many UEs in the RRC_CONNECTED state. Therefore, the advantage of switching the UE to the RRC_INACTIVE state to avoid congestion is lost or at least reduced. For example, as described above, paging, PRACH, and MBS setting processes for resuming to the RRC_CONNECTED state may cause link congestion and delay problems.

[0082] Here, FIG. 9 shows the steps of a method 900 for configuring a UE of a wireless communication system to set up multicast reception according to an embodiment of the present invention. Referring to FIG. 9, this method is executed by the UE. The wireless communication system may be, for example, the wireless communication system 100 of FIG. 1, the UE may be UE 101, and the method 900 may include the UE 205 of FIG. 2 executed by the processor 215.

[0083] UE 101 operates in a non-connected Radio Resource Control (RRC) state (such as the RRC_INACTIVE state) and has previously participated in one or more multicast sessions. For example, as described above, UE 101 executes the join session procedure by sending a join request 507 (such as a PDU session change request including a multicast session id) to the core network 102 or by establishing an individual MBS PDU session. The multicast session to be set for the UE is not currently activated, and thus the UE is in a non-connected state or the RRC_INACTIVE state. As described above with reference to FIG. 4, in the non-connected RRC state (e.g., the RRC_INACTIVE state), UE 101 cannot communicate with the core network 102, but the UE context or settings are stored in the UE and the RAN (e.g., if the UE has not moved or has not moved from the cell controlled by the last serving gNB, the last serving gNB that may control the cell in which the UE is currently camping), and this information is useful for accelerating the transition of the UE to the connected state. In the example shown in FIG. 1, UE 101 is camping in a cell 121 controlled by a base station 111 or gNB 111.

[0084] Put simply, in step 901, the UE (e.g., UE 101) receives a notification indicating that the multicast session it previously participated in has been activated. In one example, as will be described in more detail below with reference to FIGS. 6 and 7, the core network 102 activates the multicast session (e.g., when there is multicast data to be transmitted), and a notification is sent from the core network 102 to the UE via a base station (e.g., a gNB serving a cell covering the MBS service area for the multicast session) in response to the activation of the MBS session. The notification (e.g., group page message 603 in FIGS. 6 and 7) may include an identifier (e.g., MBS session id and / or TMGI) for identifying the activated multicast session, and may also include information indicating that the multicast session has been activated (e.g., MBS session activation cause information indicating that the reason for the notification is the activation of the multicast MBS session). The notification may be a paging message such as a group page that may include a field that can be set to "mbs session activation" when the multicast session is activated. As described above, the paging message is transmitted by all gNBs covering the multicast service area, and thus, in step 901, UE 101 may receive the paging message from at least one of the gNBs covering the multicast service area, such as gNB 111. When the UE is in the RRC - INACTIVE state, when the multicast session is activated, the network does not know where the UE is located (e.g., the UE may have changed cells), and thus, sending a notification (e.g., a paging message) is useful for notifying the UE (and other UEs that previously participated in the multicast session within each cell of the MBS service area) of the multicast session activation (activation).

[0085] After receiving a notification of multicast session activation, the UE can determine whether the notification indicates that a multicast session that the UE has previously participated in has been activated, based on the information included in the notification (e.g., an identifier for identifying the activated multicast session, and / or based on the presence of information indicating that the multicast session has been activated if included in the notification). If the identifier for identifying the activated multicast session included in the notification matches the identifier for the multicast session that the UE has previously participated in (stored in the UE at the completion of the participation procedure), and / or the information indicating that the multicast session has been activated, the UE determines that the notification indicates that a multicast session that the UE has previously participated in has been activated.

[0086] In one example, after receiving a notification of multicast session activation, for example, in response to determining that the notification indicates that a multicast session that the UE has previously participated in has been activated, UE 101 may perform a random access procedure towards the base station (e.g., referred to as the source base station or serving base station) that controls the cell in which UE 101 is currently camping. In the example shown in FIG. 1, the source base station of UE 101 camping in cell 121 is gNB 111. The random access procedure may be a PRACH (Physical Random Access Channel) procedure defined in Section 5.2.2.3.3 of TS 38.311 to update the UE's system information if required. For example, updating the UE's system information (e.g., context information about the UE) may be required when the system information is not up-to-date, which may occur when certain conditions are met, such as when the UE has moved to another cell or when the system information has not been updated for some time.

[0087] After receiving a notification of multicast session activation, for example, in response to a determination that the notification indicates that a multicast session that the UE has previously participated in has been activated, the UE sends or transmits, in step 902, an MBS setup request message for requesting setup information for receiving multicast data in a non-connected RRC state such as the RRC_INACTIVE state for the activated multicast session. The MBS setup request message is transmitted to the base station (e.g., the source base station or the serving base station) that controls the cell in which the UE is camping in response to the receipt of the notification. For example, in the case of the configuration of FIG. 1, the UE 101 transmits an MBS setup request message for requesting setup information for receiving multicast data in a non-connected RRC state such as the RRC_INACTIVE state for the activated multicast session to the source gNB 111. The MBS setup request message can be a new RRC message or an RRC Resume Request message or a System Information Block (SIB) reception request, as will be described in more detail below.

[0088] The MBS setup request message (e.g., the MBS setup request message 607 in FIGS. 6 and 7) may include an identifier for identifying the activated multicast session (e.g., an MBS session id and / or a Temporary Mobile Group Identity (TMGI)). In other words, it is an identifier indicating the MBS session for which the setup is requested. Further, the MBS setup request message may include UE identification information for identifying the UE 101 such as an IMSI, an IMEI, etc., and / or authentication information (ueMAC-I) such as an authentication token used when authenticating the UE 101.

[0089] In step 903, UE 101 receives an MBS configuration message including configuration information for setting the UE to receive multicast data in a non-connected RRC state such as the RRC_INACTIVE state for an activated multicast session. The MBS configuration message is transmitted by a base station (e.g., a source base station or a serving base station) that controls the cell in which the UE is camping, in response to the reception of an MBS configuration request message. For example, in the configuration of FIG. 1, UE 101 receives an MBS configuration message for setting the UE to receive multicast data in a non-connected RRC state such as the RRC_INACTIVE state for an activated multicast session, from gNB 111. The MBS configuration message (e.g., the MBS configuration message 609 of FIGS. 6 and 7) can be an RRCReconfiguration message, or an RRCRelease or RRCResume message accompanied by a suspend configuration message, or an SIB message, as will be described in more detail below.

[0090] In one example, the configuration information includes configuration information for at least one multicast radio bearer (MRB) (e.g., the configuration of at least one MRB to be used by gNB 111 for an activated multicast session). Note that one or more MRBs can be associated with one MBS session. The MRB configuration information can include setup information for the packet data convergence protocol (PDCP) and the service data adaptation protocol (SDAP).

[0091] In response to receiving the MBS configuration message, the UE 101 configures itself to receive multicast data in the non-connected RRC state (e.g., RRC_INACTIVE state) based on the configuration information in the received MBS configuration message. In other words, the UE 101 performs radio bearer configuration and configures itself to receive multicast data of the activated multicast session from a base station (e.g., source gNB 111) (e.g., sets up the user plane in the UE 101 according to the radio configuration of the base station).

[0092] Once the UE 101 is configured, the UE 101 can receive data from the gNB 111 for the multicast session.

[0093] Steps 901, 902, and 903 are executed while the UE 101 is operating in the non-connected RRC state (e.g., RRC_INACTIVE state). In addition, the configuration of the UE 101 and the reception of multicast data by the UE are also executed while the UE 101 is operating in the non-connected RRC state (e.g., RRC_INACTIVE state). Therefore, the UE 101 is maintained in the RRC_INACTIVE state throughout the process and can obtain the settings required for receiving multicast data from the network (e.g., gNB 111 or core network 102) as soon as it becomes available.

[0094] Next, referring also to FIG. 10, which shows the steps of a method 1000 for use in configuring a UE of a wireless communication system to set up multicast reception in accordance with an embodiment of the present invention. The method 1000 is executed at a base station (e.g., a source base station or a serving base station) that controls a cell in which one or more UEs are camped. The wireless communication system can be, for example, the wireless communication system 100 of FIG. 1. With respect to the example shown in FIG. 1, the base station executing the method 1000 can be the base station 111 or gNB 111 that controls cell 121, and the one or more UEs include UE 101 and 151 that are currently camped on cell 121 (the current serving cell). The base station can include the base station 305 of FIG. 3, where the method 1000 is executed by the processor 315. UE 101 operates in a non-connected radio resource control (RRC) state (such as the RRC_INACTIVE state) and has previously participated in one or more multicast sessions as described above with reference to FIG. 9.

[0095] Briefly stated, in step 1001, the base station (e.g., gNB 111) sends a notification indicating that the multicast session has been activated. In an example described in more detail below with reference to FIGS. 6 and 7, the core network 102 activates the multicast session (e.g., when there is multicast data to be transmitted) as part of the MBS session activation procedure (e.g., the MBS session activation procedure shown in 512 of FIG. 5a and 602 of FIG. 6, which is further detailed in section 7.2.5 of TS 23.247), and sends an MBS session activation message (e.g., a group page request) to the base station (e.g., gNB) that provides a cell covering the MBS service area for the multicast session (e.g., identified by the MBS session id). This message notifies the base station of the MBS session activation and requires the base station to notify the RRC_INACTIVE UEs that have previously joined the multicast session of the MBS session activation. In response to the message from the core network 102, the base station 111 (along with other base stations covering the MBS service area) sends a notification indicating that the multicast session that the UE has previously participated in has been activated. The notification sent by the base station may include an identifier (e.g., MBS session id and / or TMGI) for identifying the activated multicast session, and may also include information indicating that the multicast session has been activated (e.g., MBS session activation cause information indicating that the reason for the notification is the activation of the multicast MBS session). The notification may be a paging message such as a group page that may include a field that can be set to "mbs session activation" when the multicast session is activated.Thus, in the example of FIG. 1, the base station or gNB 111 transmits a paging message in step 1001, and the paging message should be received by at least the UEs located within cell 121 served by gNB 111.

[0096] In one example, the base station or gNB may determine whether a UE can receive multicast in the RRC_INACTIVE state and whether the AF 104 (Application Function) permits the reception of multicast data by a UE in the RRC_INACTIVE state. If the gNB determines that a UE can receive multicast in the RRC_INACTIVE state and the AF 104 (Application Function) permits the reception of multicast data by a UE in the RRC_INACTIVE state, the gNB may transmit a group paging message (i.e., an extended group paging message) including an identifier (e.g., MBS session id and / or TMGI) for identifying the activated multicast session and information indicating that the multicast session has been activated (e.g., MBS session activation cause information - this indicates that the cause of the notification is the activation of the multicast MBS session). Otherwise, if the gNB determines that a UE cannot receive multicast in the RRC_INACTIVE state or the AF 104 (Application Function) does not permit the reception of multicast data by a UE in the RRC_INACTIVE state, the gNB transmits a standard group paging message 513 as shown in FIG. 5b. Both the UE capabilities and the AF capabilities are known at the gNB after session establishment 523. The gNB may further take into account the UE preference for receiving in connected mode or non-connected mode (which is also known at session establishment).

[0097] Upon receiving the notification, each UE can determine whether the notification indicates the activation of a multicast session that the UE has previously participated in, based on the identifier of the activated multicast session and the presence of information indicating that the multicast session has been activated.

[0098] In step 1002, the base station 111 receives an MBS configuration request message for requesting configuration information for receiving multicast data in a non-connected RRC state such as the RRC_INACTIVE state for the activated multicast session. The MBS configuration request message operates in a non-connected RRC state (such as the RRC_INACTIVE state) and is received from at least one of one or more UEs that have previously participated in the multicast session. For example, the at least one UE may be UE 101 that is camped on cell 121, operates in the RRC_INACTIVE state, and has previously participated in the activated multicast session. The at least one UE 101 receives a notification from the base station and, in response to determining that the notification indicates the activation of a multicast session that the at least one UE has previously participated in, transmits an MBS configuration request message. The MBS configuration request message may be a new RRC message or an RRC Resume Request message or a system information block (SIB) reception request, as described with reference to FIG. 9.

[0099] The MBS configuration request message may include an identifier (e.g., MBS session id and / or TMGI) for identifying the activated multicast session. In other words, it is an identifier indicating the MBS session for which the configuration is requested. Further, the MBS configuration request message may include UE identification information (such as IMSI, IMEI, etc.) for identifying at least one UE 101 and / or authentication information (ueMAC-I) such as an authentication token used for authenticating at least one UE 101.

[0100] In one example, upon receiving an MBS configuration request message, the base station or gNB 111 processes the MBS configuration request message, which may include collecting or obtaining information necessary to construct UE configurations for at least one UE so that the at least one UE can receive multicast data for an activated multicast session. Once the UE configurations are known (including steps of radio access network (RAN) resource reservation), the base station or gNB 111 transmits an MBS configuration message to at least one UE in step 1003. The MBS configuration message includes configuration information for configuring at least one UE for receiving multicast data in a non-connected RRC state such as the RRC_INACTIVE state for an activated multicast session. In one example, the configuration information includes configuration information for at least one multicast radio bearer (MRB) (e.g., the configuration of at least one MRB to be used by the gNB 111 and at least one UE 101 for communication of multicast data for an activated multicast session). Note that one or more MRBs can be associated with one MBS session. The MRB configuration information may include setup information for the packet data convergence protocol (PDCP) and the service data adaptation protocol (SDAP).

[0101] The MBS configuration message is transmitted by a base station (e.g., a source or serving base station) that controls the cell in which at least one UE is camping, to at least one UE, and is transmitted in response to receiving an MBS configuration request message from the at least one UE. For example, in the configuration of FIG. 1 where UE 101 is transmitting an MBS configuration request message, gNB 111 transmits an MBS configuration message to UE 101 to configure UE 101 to receive multicast data in a non-connected RRC state such as the RRC_INACTIVE state for an activated multicast session. As described above with reference to FIG. 9 and explained in more detail below, the MBS configuration message can be an RRCReconfiguration message, or an RRCRelease message with a suspend configuration message, or an RRCResume message, or an SIB message.

[0102] If two or more UEs are in a non-connected RRC state, and have previously participated in the same multicast session, and are camping on the same cell controlled by a base station, each of the UEs that have previously participated in the multicast session (and thus have knowledge of the multicast session identifier), in response to a notification transmitted by the base station that includes the multicast session identifier for the multicast session, transmits an MBS configuration request message to the base station that controls the cell. Thereafter, the base station transmits an MBS configuration message to each of the UEs in response to each of the MBS configuration request messages received at the base station.

[0103] By sending a notification indicating that the multicast session has been activated in the MBS session activation, the UE can determine that the notification is related to the MBS session activation, which is useful for preventing the UE from automatically starting the RRC resume procedure and switching to the RRC_CONNECTED state. Further, by setting the UE in the RRC_INACTIVE state after the notification that the multicast session has been activated, it is possible to avoid requiring the UE to switch to the RRC_CONNECTED state during the multicast MBS session activation, which means that the number of UEs in the RRC_CONNECTED state can be reduced, and as a result, the congestion in the gNB can be reduced. Further, in one example, when the notification sent by the base station is a group paging message, using the group paging message is simpler than having to page all UEs individually, but a modified UE may attempt to join the session earlier in order to tamper with the multicast session. By having the MBS setup request / response protocol executed by the UE to request MBS setup, the gNB can perform an access permission check and reject the setup for the modified UE (e.g., by not responding to the MBS setup request message sent by the modified UE).

[0104] Next, also refer to FIG. 6 showing an exemplary message flow according to an exemplary embodiment of the present invention. The message flow will be described with reference to the wireless communication system of FIG. 1. In this case, the UE is UE 101, the NG RAN is gNB 110 (in the case of UE 101 in cell 121) or gNB 111 (when UE 101 is in cell 120), the 5GC is the core network 102, and the application server is the MBS application service 103.

[0105] In this example, as described above with reference to FIG. 5a, procedures such as UE registration 521, MBS session creation 522, UE participation 523, and the switching of the UE to RRC_INACTIVE 509 have already been performed.

[0106] UE 101 executes a cell reselection process 601 as a background task in the RRC_INACTIVE state 600. This process manages UE mobility and enables the "reselection" of a new gNB according to the new UE location. Cell reselection is described in detail in Section 5.2.4 of TS 38.304. In this example, it is assumed that the NG-RAN node serving the cell where UE 101 is camping is either gNB 110 or gNB 111, which is aware of the movement of the UE.

[0107] The AF 104 (Application Function) in the core network 102 can be triggered to activate a multicast session (MBS session activation 602). MBS session activation is described in Section 7.2.5.2 of TS 23.247. The main result of this procedure is the reservation of RAN (Radio Access Network) resources by the gNB. These resources enable the communication of multicast data to UEs that have already participated in the multicast session. RAN resource allocation includes the MRB (MBS Radio Bearer) setup for the communication of multicast data.

[0108] When a multicast session is activated, the core network 102 may need to page some UEs in order to notify them of the availability of multicast data. RRC_INACTIVE UEs need to be paged, which, as explained in 601, is because although RRC_INACTIVE UEs are still in motion and can enter the cells of another gNB, neither the new gNB (target gNB) nor the first or last serving gNB (source gNB) recognizes the movement of the UE at this step and does not know which cell the UE is currently located in. The core network 102 sends a group paging request to the gNB using the MBS session id (not shown), whereby each gNB sends group paging (as described above with reference to FIGS. 9 and 10, group paging is an example of a notification sent by the gNB to the UE) to the RRC_INACTIVE UEs. However, unlike the processing of the paging message described above with reference to FIG. 5b (e.g., processing 515 of the paging of the group paging message 513), according to the embodiments of the present invention, the UE shall not request to resume the RRC connection in response to the paging message (so as to remain in the non-connected RRC state), and thus, the group paging sent by the gNB is extended so that the UE can adopt a behavior different from that described above for processing the paging at 515 when processing the paging message. In order to reach the RRC_INACTIVE UEs, each gNB may send a group paging / paging message or notification 603 that includes a multicast session activation paging cause indicating that the multicast session has been activated, in addition to the multicast session id for identifying the activated multicast session. The multicast session id is, for example, a TMGI (Temporary Mobile Group Identity) obtained as a result of the MBS session creation 522.In one example, the destination UE may not be explicitly listed by the ue_identity (i.e., the UE identity assigned by the upper layer) in the notification 603 (thus, it can be regarded as a group paging message).

[0109] In one example, the base station or gNB may determine whether the UE can receive multicast in the RRC_INACTIVE state and whether the AF 104 (Application Function) permits the reception of multicast data by the UE in the RRC_INACTIVE state. If the gNB determines that the UE can receive multicast in the RRC_INACTIVE state and the AF 104 (Application Function) permits the reception of multicast data by the UE in the RRC_INACTIVE state, the gNB may send a group paging message (i.e., an extended group paging message) including an identifier for identifying the activated multicast session (e.g., MBS session id and / or TMGI) and information indicating that the multicast session has been activated (e.g., MBS session activation cause information - this indicates that the cause of the notification is the activation of the multicast MBS session). Otherwise, if the gNB determines that the UE cannot receive multicast in the RRC_INACTIVE state or the AF 104 (Application Function) does not permit the reception of multicast data by the UE in the RRC_INACTIVE state, the gNB sends a standard group paging message 513 as shown in Figure 5b. Both the UE capabilities and the AF capabilities are known to the gNB after session establishment 523. The gNB may further consider the UE preference for receiving in the connected mode or non-connected mode (which is also known in session establishment).

[0110] Based on Section 5.3.2.3 of Version 17.0.0 of 3GPP TS 38.331, the paging message reception by the UE may proceed as follows:

[0111] 1> If the TMGI is included in the pagingGroupList contained in the Paging message, for each TMGI: 2> If the UE is participating in the MBS session indicated by the TMGI included in the pagingGroupList: 3> Transfer the TMGI to the upper layer; 1> In RRC_INACTIVE, if the UE is participating in one or more MBS sessions indicated by the TMGI included in the pagingGroupList; and 1> If the ue-Identity not included in any of the PagingRecord is included in the Paging message and does not match the UE identity assigned by the upper layer: 2> If the paging cause includes MBS_session activation 3> (For example, as will be described with reference to FIGS. 6 to 10 and / or as described below in the description of exemplary procedures for configuring the UE to perform multicast reception with reference to the sections and subsections of TS 38.331 version 17.0.0) Start the RRC_INACTIVE multicast reception procedure according to 5.3.X 2> Other cases , set resumeCause as follows and start the RRC connection resume procedure according to 5.3.13: 3> If Access Identity 1 is set for the UE by the upper layer: 4> resumeCause is set to mps-PriorityAccess; 3> Or, if Access Identity 2 is set for the UE by the upper layer: 4> resumeCause is set to mcs-PriorityAccess; 3> Or, if one or more access identities equal to 11 to 15 are set for the UE by the upper layer: 4> resumeCause is set to highPriorityAccess; 3> In other cases: 4> resumeCause is set to mt-Access.

[0112] The paging message can be as follows: JPEG2025522273000002.jpg140154TIFF2025522273000003.tif65154

[0113] When receiving a new group paging message 603, the UE detects both the multicast session id (TMGI) and the multicast session activation paging cause within the group paging message 603, and then executes process 604. For each UE (such as UE 101) that has joined the multicast session identified by the multicast session id, process 604 includes starting to receive multicast data and preparing to remain in the RRC_INACTIVE state.

[0114] Next, as an option, UE 101 executes a random access procedure towards the gNB (such as PRACH procedure 517, etc., where PRACH represents the physical random access channel). This procedure enables UE 101 to update its system information if necessary.

[0115] Next, UE 101 sends an MBS configuration request message 607 to request the gNB 111 to send configuration information that enables UE 101 to receive multicast data corresponding to the activated session as signaled in the paging message 603.

[0116] Each time the gNB receives an MBS configuration request message from the UE, it prepares an MBS configuration message 609 and transmits the MBS configuration message 609 to the UE 101 as a response. In this message, the UE finds the MBS radio bearer configuration parameters to be applied to receive multicast data corresponding to the activated MBS session. The MBS radio bearer information element includes the setup information of PDCP (Packet Data Convergence Protocol) and SDAP (Service Data Adaptation Protocol) determined at the time of radio resource reservation. When the MBS radio bearer is configured in the UE 101, multicast data can be received while remaining in the RRC_INACTIVE mode (610).

[0117] Figure 7 is a flowchart showing an exemplary method executed by a UE according to an example embodiment of the present invention. This method can be executed by the UE 205 in FIG. 2 (e.g., by the CPU 215 executing instructions stored in the memory 225), and corresponds to processing the message flows 603 to 610 in FIG. 6.

[0118] First, during step 700, the communication management unit 220 receives an incoming frame from the transceiver 235 and decodes it as a paging message (e.g., paging message 603) from the base station (110, 111), and the paging message is received on the PCCH (Paging Control Channel). The paging message format is defined in section 6.2.2 of TS 38.331, except for the paging cause field that is modified in this example of the embodiment of the present invention to add a new cause called "mbs session activation".

[0119] During step 701, the UE 205 checks whether the TMGI (Temporary Mobile Group Identity) of the multicast session participated in at 523 exists in the PagingGroupList-r17 field of the received paging message. The TMGI is used as a multicast session id for identifying the activated multicast session and is stored in the memory 225. If the stored TMGI of the UE is not found in the paging message 603 (no branch in step 701), the process ends (step 709).

[0120] If the stored TMGI of the UE is found in the paging message (yes branch in step 701), during step 702, the ue_identity field of each PagingRecord field of the received paging message is compared with the identity of the UE itself. If the ue_identity field matches the identity of the UE itself defined by the upper layer (no branch in step 702), the process ends (step 709).

[0121] Otherwise, if the ue_identity field does not match the identity of the UE itself defined by the upper layer (yes branch in step 702), during step 703, the paging cause field of the paging record is read. If the paging cause is not set to "mbs session activation" (no branch in step 703), during step 704, the RRC connection is resumed according to section 5.3.13 of TS 38.331.

[0122] In another example where the TMGI and the paging cause are included in the paging message, step 702 may be omitted. This is because the UE can determine from the TMGI and the paging cause whether the paging message is relevant to an MBS session that the UE has participated in and that has been activated without the need to check for a match in the UE_identity field. Step 702 may be performed to ensure backward compatibility with previous releases that a UE with a matching UE identity may require to switch to RRC_CONNECTED.

[0123] When the paging cause is set to "mbs session activation" (yes branch in step 703), during step 705, the relevance of the system information stored in the UE's memory 225 is evaluated. If the gNB selected during the cell reselection process 511 / 601 is different from the gNB that performed the RRC connection release 509, the UE's system information is obsolete. Also, if the gNB has not changed between 509 and 511 / 601 but a long time has elapsed since the RRC connection release 509, the UE's system information is also considered obsolete.

[0124] If it is determined that the system information is obsolete and thus needs to be updated (yes branch in step 705), during step 706, the UE 205 updates the system information by performing the PRACH (Physical Random Access Channel) procedure defined in section 5.2.2.3.3 of TS 38.311.

[0125] Step 707 is performed when the system information has been updated (706) or when it has been evaluated as relevant (no branch in step 705). During this step 707, the UE 205 sends an MBS configuration request message 607 to request the gNB (e.g., gNB 111) to send configuration information that enables the UE to receive multicast data corresponding to the activated session signaled in the received paging message 603.

[0126] In one example, the MBS setup request message 607 is implemented as a new RRC message transmitted on signaling radio bearer 0 on the CCCH (Common Control Channel). The message includes at least an identifier (e.g., TMGI) of the activated multicast session as received in the paging message 603, and may also include a UE identity as stored in the system information. For example, the UE identity can be a short I-RNTI (Inactive - Radio Network Temporary Identifier) value or a full I-RNTI value.

[0127] Alternatively, the MBS setup request message 607 is implemented as a modified RRCResume request message as defined in Section 6.2.2 of TS 38.331, having an additional field including the TMGI.

[0128] Next, during step 708, the UE 101 receives an MBS setup message 609 from the gNB. In this MBS setup message 609, the UE 205 finds the MBS radio bearer setup parameters to be applied for receiving the multicast data corresponding to the MBS session activation notified in the paging message 603. Details of the MBS radio bearer information element are described in Section 6.3.2 of TS 38.331. This includes the setup information of PDCP (Packet Data Convergence Protocol) and SDAP (Service Data Adaptation Protocol), enabling the UE to receive multicast data while remaining in the RRC_INACTIVE state.

[0129] In one example, the MBS configuration message 609 is implemented as a new RRC message transmitted by the gNB on signaling radio bearer 1 (SRB1) on the CCCH (Common Control Channel). The message includes at least an RRC transaction identifier and an MBS configuration information element defined in section 6.3.2 of TS 38.331.

[0130] When the MBS radio bearer configuration is completed, multicast data can be received while remaining in the RRC_INACTIVE mode, and the process ends (step 709).

[0131] FIG. 8 is a flowchart showing an exemplary method performed by a base station (e.g., gNB) according to an example of an embodiment of the present invention. This method can be performed by the base station 305 of FIG. 3 (e.g., by the CPU 315 executing instructions stored in the memory 325) and corresponds to processing the message flows 603-610 of FIG. 6.

[0132] During step 800, the base station or gNB 305 receives a multicast session active activation notification or message from the core network 102 as part of the MBS session activation 512 / 602. This step is described in more detail in section 7.2.5 of TS 23.247. It includes radio resource reservation by the gNB to enable multicast data to be transmitted over the radio network and reach the UE.

[0133] As part of the session activation procedure, the core network 102 requests the gNBs (305, 110, 111) to send paging messages to RRC_INACTIVE UEs that have previously participated in the multicast session in order to notify the UEs that the multicast session has been activated. During step 801, each gNB 305 may send one page or paging message (e.g., paging message 603) that includes a PagingGroupList-r17 field that may include the TMGI (Temporary Mobile Group Identity) of the multicast session that is activated and signaled at 512 / 602. The TMGI is used as the multicast session id to identify the activated multicast session. The paging cause field of the paging message (e.g., in the PagingRecord field) is set to "mbs session activation". The paging message format is defined in section 6.2.2 of TS 38.331, except that the paging cause field is modified in this example of an embodiment of the present invention to add a new cause field called "mbs session activation". The gNB inputs the UE's identity into the eu_identity field of the paging message to identify RRC_INACTIVE UEs that have previously participated in the multicast session.

[0134] In one example, the base station or gNB may determine whether the UE can receive multicast in the RRC_INACTIVE state and whether the AF 104 (Application Function) permits the reception of multicast data by the RRC_INACTIVE state UE. If the gNB determines that the UE can receive multicast in the RRC_INACTIVE state and the AF 104 (Application Function) permits the reception of multicast data by the RRC_INACTIVE state UE, the gNB may send a group paging message (i.e., an extended group paging message) including an identifier (e.g., MBS session id and / or TMGI) for identifying the activated multicast session and information indicating that the multicast session has been activated (e.g., MBS session activation cause information - this indicates that the cause of the notification is the activation of the multicast MBS session). Otherwise, if the gNB determines that the UE cannot receive multicast in the RRC_INACTIVE state or the AF 104 (Application Function) does not permit the reception of multicast data by the RRC_INACTIVE state UE, the gNB sends a standard group paging message 513 as shown in FIG. 5b. Both the UE capabilities and the AF capabilities are known at the gNB after session establishment 523. The gNB may further take into account the UE preference for reception in the connected mode or non-connected mode (which is also known in session establishment).

[0135] During step 802, the gNB 305 waits for a message from an RRC_INACTIVE UE that is located within the cell served by the gNB 305 and has previously participated in a multicast session.

[0136] Some UEs may have participated in a multicast session while in another cell, and other UEs may have participated in a multicast session within the gNB's cell, but a significant amount of time has passed without refreshing the system information. In both cases, the system information for these UEs is probably old (i.e., obsolete) and needs to be updated. Therefore, if a UE determines that its system information needs to be updated, the UE executes a PRACH (Physical Random Access Channel) procedure to refresh the system information as specified in Section 5.2.2.3.3 of TS 38.331 (the yes branch in step 803). As part of the PRACH procedure, the gNB 305 may optionally request additional UE context information from an adjacent gNB (in step 804). The additional context information may include the MBS session participation information established in 523. For example, if the UE session participation procedure was executed by a UE connected to another gNB, the gNB 305 obtains the MBS session participation information such as the MBS session id from that other gNB.

[0137] Next, all relevant UEs (e.g., all RRC_INACTIVE UEs located within the cell controlled by the gNB 305 and that have previously participated in a multicast session) transmit an MBS configuration request message as described in step 707.

[0138] Whenever the gNB 305 receives an MBS configuration request message from the UE, at step 806, the gNB 305 prepares an MBS configuration message 609 and transmits the MBS configuration message 609 to the requesting UE. In this MBS configuration message, the UE finds the MBS radio bearer configuration parameters to be applied for receiving multicast data corresponding to the activated MBS session. Details of the MBS radio bearer information element are described in Section 6.3.2 of TS 38.331. It includes the PDCP (Packet Data Convergence Protocol) and SDAP (Service Data Adaptation Protocol) setup information determined at step 800 when performing radio resource reservation. The MBS configuration message may further include an MBS session identifier. For example, other fields of the MBS information element such as the session identifier are fetched from the memory 325, where they are stored during session establishment 523 or UE context fetch 804.

[0139] The following provides details of an exemplary procedure for configuring the UE to perform multicast reception with reference to the sections and subsections of TS 38.331 version 17.0.0. MBSConfigRequest corresponds to the MBS configuration request message described above.

[0140] The purpose of this procedure is to set up multicast reception in the RRC_INACTIVE state, including one or more multicast MRBs. This procedure is new and shall have a definitive numbering when later referred to by number 5.3.X.

[0141] Start The UE starts the procedure when the upper layer or the AS (when responding to RAN paging) requests multicast reception in the RRC_INACTIVE state. Before starting this procedure, the UE shall ensure that it has valid and up-to-date essential system information as specified in Section 5.2.2.2. Upon the start of the procedure, the UE shall do the following: 1> If the resumption of the RRC connection is triggered by a response to an NG-RAN paging: 2> Select "0" as the Access Category; 2> Execute the integrated access control procedure defined in 5.3.14 using the selected Access Category and one or more Access Identities provided by the upper layer; 3> If the access attempt is prohibited, the procedure ends; Actions related to the transmission of MBSConfigRequest or BSConfigRequest1 message The UE shall configure the content of the MBSConfigRequest or MBSConfigRequest1 message as follows: 1> If the field useFullResumeID is signaled in SIB1: 2> Select MBSConfigRequest1 as the message to use; 2> Set ueIdentity to the saved fullI-RNTI value; 1> In other cases: 2> Select MBSConfigRequest as the message to use; 2> Set ueIdentity to the saved shortI-RNTI value; 1> Reconstruct the PDCP entity for SRB1; 1> Resume SRB1; 1> Transmit the selected message MBSConfigRequest or MBSConfigRequest1 to the lower layer. Receiving MBSConfiguration by UE The UE shall do the following: 1> If radioBearerConfig is included in RRCResume: 2> Execute the radio bearer configuration according to 5.3.5.6;

[0142] Message definition - MBSConfigRequest The MBSConfigRequest message is used to request settings for multicast reception in the RRC_INACTIVE state. Signaling Radio Bearer: SRB0 RLC-SAP: TM Logical Channel: CCCH Direction: From UE to network TIFF2025522273000004.tif115154

[0143] - MBSConfigurationRequest1 The MBSConfigurationRequest1 message is used to request settings for multicast reception in the RRC_INACTIVE state. Signaling Radio Bearer: SRB0 RLC-SAP: TM Logical Channel: CCCH1 Direction: From UE to network TIFF2025522273000005.tif124154

[0144] - MBSConfiguration The MBSConfiguration message is used to set up multicast reception in the RRC_INACTIVE state. Signaling Radio Bearer: SRB1 RLC-SAP: AM Logical Channel: DCCH Direction: From network to UE TIFF2025522273000006.tif102154

[0145] Although the present invention has been described with reference to embodiments, it should be understood that the present invention is not limited to the disclosed embodiments. As defined in the appended claims, those skilled in the art will understand that various changes and modifications may be made without departing from the scope of the present invention. All of the features disclosed in the specification (including any of the appended claims, the abstract and the drawings), and / or all of the steps of any method or process so disclosed, may be combined in any combination except combinations where at least some of such features and / or steps are mutually exclusive. Each feature disclosed in the specification (including any of the appended claims, the abstract and the drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. For this reason, unless expressly stated otherwise, each feature disclosed is only an example of a general series of equivalent or similar functions.

[0146] In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used.

[0147] In the foregoing embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the functions may be stored on a computer-readable medium as one or more instructions or codes, or transmitted via a computer-readable medium and executed by a hardware-based processing unit.

[0148] A computer-readable medium can include a computer-readable storage medium corresponding to a tangible medium such as a data storage medium, or a communication medium including any medium that facilitates transfer of a computer program from one location to another, for example, according to a communication protocol. Thus, a computer-readable medium can generally correspond to (1) a tangible computer-readable storage medium that is non-transitory, or (2) a communication medium such as a signal or a carrier wave. A data storage medium can be any available medium that can be accessed by one or more computers or one or more processors to retrieve instructions, code, and / or data structures for implementing the techniques described in this disclosure. A computer program product can include a computer-readable medium.

[0149] By way of example and not limitation, such a computer-readable storage medium can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other medium that can be used to store the desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, coaxial cables, optical fiber cables, twisted pair, Digital Subscriber Line (DSL), or wireless technologies such as infrared, radio, and microwave, when the instructions are transmitted from a website, server, or other remote source, coaxial cables, optical fiber cables, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of the medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but instead are directed to non-transitory, tangible storage media. As used herein, disk and disc include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc, where disk typically magnetically reproduces data and disc optically reproduces data with a laser. Combinations of the above should also be included within the scope of computer-readable media.

Claims

1. A user equipment (UE) of a wireless communication system, a method for setting the UE that has previously participated in a multicast session to perform multicast reception, the method comprising, in the UE operating in a non-connected radio resource control (RRC) state, receiving a notification indicating that the multicast session has been activated, transmitting an MBS setting request message for requesting setting information for the reception of multicast data, receiving an MBS setting message including setting information for setting the UE to perform reception of multicast data, A method comprising the above.

2. The method according to claim 1, further comprising setting the UE to receive multicast data in a non-connected RRC state based on the setting information.

3. The method according to claim 2, wherein the setting includes performing a radio bearer setting.

4. The method according to claim 2 or 3, wherein after the setting, data for the multicast session is received.

5. The method according to any one of claims 1 to 4, wherein the notification is a paging message.

6. The method according to any one of claims 1 to 5, wherein the notification is a paging message transmitted by a base station, including an MBS session id for identifying the activated multicast session and an MBS session activation cause for indicating that the multicast session has been activated.

7. The method according to any one of claims 1 to 6, wherein the notification includes information indicating that the multicast session has been activated, and an identifier for identifying the activated multicast session, and includes at least one of the above.

8. The method according to any one of claims 1 to 7, wherein the notification is a group paging message.

9. The method according to any one of claims 1 to 4, The notification is a group paging message including an identifier for identifying the activated multicast session and information for indicating that the multicast session has been activated, The MBS setup request message is an RRC Resume Request message, The MBS setup message is an RR CRelease with a suspend setup message, method.

10. The method according to claim 9, The information for indicating that the multicast session has been activated includes an MBS session activation cause, method.

11. The method according to any one of claims 1 to 10, further comprising determining whether the notification indicates that a multicast session that the UE has previously participated in has been activated based on the information included in the notification, Transmitting the MBS setup request message includes transmitting the MBS setup request message in response to determining that the notification indicates that a multicast session that the UE has previously participated in has been activated, method.

12. The method according to any one of claims 1 to 11, The notification is transmitted by a base station, The method further includes performing a random access procedure towards the base station to update the system information of the UE if necessary after receiving the notification, method.

13. A method in a base station controlling a cell in which one or more user equipments (UEs) are camped, transmitting a notification indicating that a multicast session has been activated; receiving, from at least one of the one or more UEs that are operating in a non-connected RRC state and that have previously participated in the multicast session, an MBS setup request message for requesting setup information for receiving the multicast data; transmitting, to the at least one of the one or more UEs, an MBS setup message including setup information for setting the at least one UE to receive the multicast data in response to the received MBS setup request message; including a method.

14. The method according to claim 13, The notification is a paging message, method.

15. The method according to claim 13 or 14, wherein the notification is a paging message transmitted by a base station, including an MBS session id and an MBS session activation cause for indicating that the multicast session has been activated.

16. The method according to any one of claims 13 to 15, wherein the notification includes at least one of information indicating that the multicast session has been activated, and an identifier for identifying the activated multicast session.

17. The method according to any one of claims 13 to 16, wherein the notification is a group paging message.

18. The method according to claim 13, wherein the notification is a group paging message including an identifier for identifying the activated multicast session and information for indicating that the multicast session has been activated, the MBS setting request message is an RRCResumeRequest message, and the MBS setting message is an RRCRelese with a suspend setting message.

19. The method according to claim 18, wherein the information for indicating that the multicast session has been activated includes an MBS session activation cause.

20. The method according to any one of claims 1 to 19, wherein the non-connected RRC state is an RRC_INACTIVE state.

21. The method according to any one of claims 1 to 20, wherein the MBS setting request message includes an identifier for identifying the activated multicast session.

22. The method according to claim 21, wherein the identifier is a Temporary Mobile Group Identity (TMGI) or an MBS session id.

23. The method according to claim 21 or 22, wherein the MBS setting request further includes at least one of UE identification information for identifying the UE, and authentication information used for authenticating the UE.

24. The method according to any one of claims 1 to 23, wherein A method, wherein the configuration information includes configuration information of at least one multicast radio bearer (MRB). **Claim 25** An apparatus for a user equipment (UE), comprising one or more processors configured to execute the method according to any one of claims 1 to 12 and claims 20 to 24 when dependent on claim 1. **Claim 26** An apparatus for a base station, comprising one or more processors configured to execute the method according to any one of claims 13 to 19 and claims 20 to 24 when dependent on claim 13. **Claim 27** A computer program comprising instructions which, when executed by a computer, cause the computer to execute the method according to any one of claims 1 to 24. **Claim 28** A computer-readable medium carrying the computer program according to claim 27.

Images