MBS multicast settings

Abstract

A method and apparatus for providing MBS multicast data reception configuration parameters to a UE (user equipment). A user equipment (UE) of a wireless communication system receives multicast pre-configuration information for a multicast (MBS) session for which the UE has requested to join, the multicast pre-configuration information can be received before and / or after activation of the multicast session. The UE is configured to receive multicast data via the multicast session according to the multicast (pre-)configuration information. Establishment of the multicast session requested by the UE is performed in a base station that controls a cell serving the user equipment (UE).

Description

[Technical Field]

[0001] The present invention relates generally to providing a UE (User Equipment) with configuration parameters for receiving MBS multicast data, and particularly, but not exclusively, to configuring the UE to receive MBS multicast data when the UE is in either an RRC_CONNECTED state or an RRC_INACTIVE state. [Background technology]

[0002] Wireless communication systems are primarily deployed to address a wide range of applications, from mobile broadband and large scale machine-type communications to Ultra Reliable Low Latency Communications (URLLC). Such systems enable multiple user equipments (UEs) or mobile terminals to share a wireless medium for exchanging several types of data content (e.g., video, voice, messaging, etc.) over a radio access network (RAN) through one or more base stations.

[0003] Examples of such wireless multiple-access communication systems include systems based on the 3rd Generation Partnership Project (3GPP®) standards, such as Fourth Generation (4G) Long Term Evolution (LTE) or the more recent Fifth Generation (5G) New Radio (NR) systems, or systems based on the IEEE 802.11 standards, such as Wi-Fi.

[0004] The 5G NR requirements 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 geographic area (i.e., all UEs within the broadcast service area are authorized to receive the data). Broadcast communication services are delivered to UEs using broadcast sessions. In the case of multicast communication services, the same service and the same specific content data are provided simultaneously to a dedicated set of UEs (i.e., not all UEs within the multicast service area are authorized to receive the data). Multicast communication services are delivered to UEs using multicast sessions.

[0006] Support for multicast / broadcast technologies allows networks to operate in a more efficient manner than unicast. Specific use cases that can benefit from this MBS capability include public safety and mission-critical, V2X applications, IPTV, live video, software distribution over the air, 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 on the control plane between the UE and the base station (gNB) and provides three different states for the UE, namely, the RRC_CONNECTED state, the RRC_INACTIVE state, and the RRC_IDLE state, as defined in the 3GPP specification TS 38.331. At startup, the UE is in the RRC_IDLE state, and the UE changes to the RRC_CONNECTED state upon establishment of an RRC connection with the gNB. If 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 transitions 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 know 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, a UE can receive MBS broadcasts when it is in RRC_IDLE, RRC_INACTIVE, or RRC_CONNECTED state, but can receive MBS multicasts only when it is in RRC_CONNECTED state. For Release 18, the plan is to also enable MBS multicast reception when the UE is in 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 objective is to enable a higher density of UEs receiving multicast data from a cell. In fact, having UEs in RRC_INACTIVE state leads to a downsizing of the overall UE control plane footprint, thereby allowing a gNB to handle more UEs. In addition, constantly maintaining UEs in RRC_CONNECTED state is not power efficient. Consequently, the benefits of also supporting multicast for UEs in RRC_INACTIVE state are recognized.

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

[0010] 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), session establishment and joining (7.2.1.3 of TS 23.247).

[0011] At the start, no session exists. A session is created at the request of an AF (Application Function). As part of the creation process, an MBS session identifier is assigned, a multicast service area is defined, and the session is announced to UEs within the service area. Multicast service areas are specified in 3GPP TS 22.146 version 17.0.0, section 3 "Definitions". A multicast service area is defined per multicast service. One multicast service can initiate multiple multicast sessions. A multicast service area can be smaller 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 to the session triggers session establishment towards the NG-RAN (gNB(s) 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, a 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 delivery of MBS data for the first join request.

[0013] Once a session is created, the MB-SMF (MBS Session Management Function) can be triggered to activate the session. 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 are achieved.

[0015] The initiation 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 an application, and in the case of session establishment, the trigger is the presence of at least one UE within the service area sending a request to join the multicast session.

[0016] The establishment of an MBS session in a 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 the MBS multicast data is available through session activation. As a result, when a session is activated, the NG-RAN (at least one gNB) must notify and configure UEs that are participating in the session but are in the RRC_INACTIVE state.

[0017] The current version of the specification does not provide a procedure for informing or configuring a UE in RRC_INACTIVE state, which is not expected to receive data from applications and has limited access to the control plane.

[0018] In Release 17, several mechanisms were proposed to address the case of broadcast reception in the RRC_INACTIVE state. Document TS 38.300 version 17.0.0 in section 16.10.6.2 describes the use of the MCCH (MBS Control Channel) by a gNB to provide configuration to UEs in any RCC state, including the RRC_INACTIVE state. In fact, the MCCH channel is accessible to UEs in the RRC_INACTIVE state and is well suited to transmit notification and configuration parameters. However, the MCCH is actually accessible to all UEs without any restrictions, which poses security issues for MBS multicast services, since access to multicast data requires prior authorization for each UE during the join procedure. The multicast configuration should only be available to UEs that have obtained the appropriate authorization during the join procedure. Furthermore, MCCH content may need to be transmitted periodically and is therefore not bandwidth-efficient.

[0019] As part of the ongoing discussions on Release 18, document S2-2200599 proposes switching the UE back to RRC_CONNECTED state, performing configuration, and switching it back to RRC_INACTIVE state. While this solution appears to be functional, having UEs in RRC_INACTIVE state may defeat the purpose of offloading the gNB in cases of high UE density due to the additional signaling and other resources required to switch to RRC_CONNECTED state, perform UE configuration, and then switch it back to RRC_INACTIVE state.

[0020] It is therefore desirable to provide at least one solution to enable a UE that has previously joined a multicast session to be configured to receive multicast data if that multicast session is activated while it remains in RRC_INACTIVE state. Summary of the Invention

[0021] According to one aspect of the present invention, multicast pre-configuration information for a multicast session is provided, the multicast pre-configuration information being received before activation of the multicast session, and configuring a UE to receive multicast data via the multicast session according to the multicast pre-configuration information. The method may include sending a request to join the multicast session to a core network via a base station. The multicast pre-configuration information may be received from the base station.

[0022] The multicast pre-configuration information may be included in at least one of a radio resource control (RRC) message and a system information block (SIB). The pre-configuration information may include at least one of the following: - Radio bearer configuration information associated with low Quality of Service (QoS) transmission; - Radio bearer configuration information associated with high quality of service (QoS) transmission; - Discontinuous reception (DRX) setting information, and - Neighbor cell multicast configuration information.

[0023] The pre-configuration information including radio bearer configuration information associated with low quality of service (QoS) transmissions may be for configuring the UE when the UE is operating in a disconnected (RRC) state. The pre-configuration information including radio bearer configuration information associated with high quality of service (QoS) transmissions may be for configuring the UE when the UE is in a connected (RRC) state.

[0024] The multicast pre-configuration information may include updating existing configuration information for receiving multicast data via the multicast session, and the configuring may include using the pre-configuration information to update a configuration of the UE to receive multicast data via the multicast session.

[0025] The method may further include receiving data for the multicast session after performing the configuration according to the multicast pre-configuration information.

[0026] The multicast pre-configuration information may be received at the time of or after the establishment of the multicast session.

[0027] The multicast pre-configuration information may be received in a message for transitioning the UE to an unconnected RRC state, which may be an RRC_INACTIVE state.

[0028] The multicast pre-configuration information may be received in an RRC release message (eg, together with or as part of an RRC release message).

[0029] The multicast pre-configuration information may be received while the UE is operating in a Disconnected RRC state.

[0030] The multicast pre-configuration information may be received after a cell reselection process that causes the UE to camp on a base station.

[0031] The method includes receiving, after a cell reselection process, a notification indicating that a multicast pre-configuration is available for the multicast session; The method may include the UE sending a multicast pre-configuration request to a base station, and the multicast pre-configuration information being received from the base station in response to the sent request.

[0032] The multicast preconfiguration request may be sent after performing a Physical Random Access Channel (PRACH) procedure performed with the base station in response to a notification indicating that multicast preconfiguration information is available.

[0033] The cell reselection process includes sending information from the UE to a base station when a new cell is selected as a result of the cell reselection process. The method may include sending a target base station identifier to the base station, the target base station identifier identifying a target base station associated with the new cell. Additionally or alternatively, the method may include sending multicast session identification information to the target base station associated with the new cell to identify one or more multicast sessions in which the UE has joined.

[0034] The method may further include receiving notification of activation of the multicast session after receiving the multicast pre-configuration information.

[0035] In response to receiving the notification, the UE may be configured according to the multicast pre-configuration information.

[0036] The notification of activation may be any one of a paging message, an RRC message, and a system information block (SIB).

[0037] The UE may be operating in a Disconnected RRC state when it receives notification of activation of the multicast session, where the notification of activation is received after a cell reselection process that causes the UE to camp on the base station.

[0038] A request may be sent for multicast reception and / or multicast feedback information after reception of multicast data, and in response further multicast configuration data may be received at the UE.

[0039] The cell reselection process may include transmitting information from the UE to the base station indicating a multicast session identification for a multicast session in which the UE has joined.

[0040] In a further aspect according to the present invention, there is provided a method in a base station controlling a cell serving a user equipment (UE), the method comprising: performing establishment of a multicast session requested by the UE; and transmitting multicast pre-configuration information for the multicast session to the UE prior to activation of the multicast session.

[0041] The base station may receive a request to join a multicast session from a UE and transmit the request to join the multicast session to a core network. The base station may receive information from the core network to establish the multicast session. The establishment of the multicast session may be performed between the UE, the base station, and the core network.

[0042] The multicast pre-configuration information may be included in at least one of a radio resource control (RRC) message and a system information block (SIB).

[0043] The pre-configuration information may include one or more of the following: - Radio bearer configuration information dedicated to low Quality of Service (QoS) transmissions; - Radio bearer configuration information dedicated to high quality of service (QoS) transmission, - Discontinuous reception (DRX) setting information, and - Neighbor cell multicast configuration information.

[0044] The pre-configuration information including radio bearer configuration information associated with low quality of service (QoS) transmissions may be for configuring the UE when the UE is operating in a disconnected (RRC) state. The pre-configuration information including radio bearer configuration information associated with high quality of service (QoS) transmissions may be for configuring the UE when the UE is in a connected (RRC) state.

[0045] The multicast pre-configuration information may include updates to existing configuration information for receiving multicast data via a multicast session.

[0046] The method can include transmitting data for the multicast session to the UE according to the multicast pre-configuration information.

[0047] The multicast pre-configuration information may be sent at the time of or after the establishment of the multicast session.

[0048] The multicast pre-configuration information may be sent to the UE in a message to place the UE in a disconnected RRC state.

[0049] The multicast pre-configuration information may be sent in (together with or as part of) an RRC release message.

[0050] The multicast pre-configuration information may be transmitted to the UE when the UE is operating in a Disconnected RRC state.

[0051] The multicast pre-configuration information may be transmitted after a cell reselection process that causes the UE to camp on a base station.

[0052] After the cell reselection process, a notification indicating multicast pre-configuration may be sent, or a multicast pre-configuration request may be received from the UE, and multicast pre-configuration data may be sent in response to receiving the request.

[0053] The multicast pre-configuration request may be received after performing a physical random access channel (PRACH) procedure with the UE.

[0054] The cell reselection process may include sending information from the UE to the base station when a new cell is selected as a result of the cell reselection process.

[0055] The method may include receiving, as the source base station, a target base station identifier identifying a target base station associated with the new cell. Alternatively or additionally, the method may include receiving, as the target base station associated with the new cell, multicast session identification information for identifying one or more multicast sessions joined by the UE, indicating multicast session identification information of the multicast sessions joined by the UE.

[0056] A notification of the activation of the multicast session can be sent to the UE.

[0057] The notification of activation may be at least one of a paging message, an RRC message, and a SIB.

[0058] Optionally, the UE is operating in a Disconnected RRC state when the notification of the activation of the multicast session is sent, and the notification of activation is sent to the UE by the base station after a cell reselection process that causes the UE to camp on the base station.

[0059] The method may further include receiving a request for multicast reception and / or multicast feedback information from the UE after transmitting the multicast data to the UE, and in response, transmitting further multicast configuration data for the multicast session to the UE.

[0060] The cell reselection process may include transmitting information from the UE to the base station indicating multicast session identification information for one or more multicast sessions in which the UE has joined.

[0061] According to another aspect of the present invention, there is provided a method in a user equipment (UE) of a wireless communication system, the method including: receiving, for a multicast session in which the UE has requested to join, multicast pre-configuration information for the multicast session; and configuring the UE in accordance with the multicast pre-configuration information to receive multicast data via the multicast session.

[0062] Multicast preconfiguration information may be configuration information (data) that is received and stored to be applied later in an appropriate (or predetermined) situation. For example, according to one or more embodiments, it is received before multicast (MBS) session activation of the session to which the preconfiguration information relates. Alternatively, or additionally, the UE may receive multicast data after multicast (MBS) session activation, and the network provides the preconfiguration data to preconfigure the UE to receive multicast data after cell switching as a result of a cell reselection process. Depending on the implementation, it may be used to configure the UE before and / or after multicast (MBS) session activation.

[0063] The method can include transmitting a request to join a multicast session to a core network via a base station.

[0064] The multicast pre-configuration information may be received from a base station (e.g., a gNB or NG-RAN node).

[0065] The multicast pre-configuration information may be included in at least one of a radio resource control (RRC) message, a system information block (SIB), and an MBS control channel (MCCH) message.

[0066] According to one or more embodiments, the pre-configuration information includes at least one of the following: - Radio bearer configuration information associated with low Quality of Service (QoS) transmission (e.g., a multicast radio bearer "MRB2" configuration dedicated to receiving multicast data with low QoS for the candidate UE), - Radio bearer configuration information associated with high Quality of Service (QoS) transmissions (e.g., multicast radio bearer "MRB1" configuration primarily addressed to UEs in RRC_CONNECTED state with high QoS), - An inactive reception indicator that indicates to the UE when the UE is able to receive multicast data in a non-connected RRC state (for example, an RRC_INACTIVE reception indication that the gNB indicates to the UE when the UE is able to receive multicast data in an RRC_INACTIVE state); - Information identifying a group of UEs in the same cell that are interested in receiving multicast data (G-RNTI identifying a group of UEs in the same cell that are interested in receiving multicast data), - A multicast pre-configuration ID (e.g., a Temporary Mobile Group Identity (TMGI)) that identifies the configuration applied by the UE and associated with the multicast (MBS) session ID; - Discontinuous reception (DRX) setting information, - Neighbor cell multicast configuration information (e.g., applied when a candidate UE performs handover or cell reselection), and - Cell identity information (e.g., cell ID(s)) for identifying one or more cells to which the preconfiguration should be applied.

[0067] The multicast pre-configuration information may include updating existing configuration information for receiving multicast data via the multicast session, and the configuring may include using the pre-configuration information to update a configuration of the UE to receive multicast data via the multicast session.

[0068] The method may further include receiving data for the multicast session after performing configuration according to the multicast pre-configuration information.

[0069] The multicast pre-configuration information may be received prior to activation of the multicast session.

[0070] The multicast pre-configuration information may be received at the time of or after the establishment of the multicast session.

[0071] Notification of activation of the multicast session may be received after receiving the multicast pre-configuration information.

[0072] In response to receiving the notification, the UE may be configured according to the multicast pre-configuration information.

[0073] The notification of activation may be any one of a paging message, an RRC message, a system information block (SIB), and an MBS control channel (MCCH) message.

[0074] The UE may be operating in a non-connected RRC state (e.g., RRC_INACTIVE state) when it receives notification of activation of the multicast session. The activation notification may be received after a cell reselection process that causes the UE to camp on a base station.

[0075] A request for multicast reception and / or multicast feedback information may be transmitted after receiving the multicast data, and in response further multicast configuration data is received at the UE.

[0076] The cell reselection process may include transmitting information from the UE to the base station indicating multicast session identification information for one or more multicast sessions in which the UE has joined.

[0077] The multicast pre-configuration information may be received after activation of the multicast session.

[0078] The multicast pre-configuration information may be received in a message to place the UE in a non-connected RRC state (eg, an RRC_INACTIVE state).

[0079] The multicast pre-configuration information may be received in an RRC release message (eg, an RRC release message with SuspendConfig).

[0080] The multicast pre-configuration information may be received while the UE is operating in a non-connected RRC state (eg, RRC_INACTIVE state).

[0081] The multicast pre-configuration information may be received after a determination that a multicast configuration modification is necessary, for example, after a cell reselection process that causes the UE to camp on a base station (e.g., a different base station than the base station with which the UE previously established its configuration for a multicast session). Additionally or alternatively, the base station may control the cell that the UE was already capping, but a configuration update of the base station may cause a multicast configuration modification.

[0082] The method further comprises: receiving, after a cell reselection process, a notification indicating that a multicast pre-configuration is available for the multicast session; and The method may include: the UE sending a multicast pre-configuration request to the base station, and the multicast pre-configuration information being received from the base station in response to the sent request.

[0083] The multicast pre-configuration request may be sent after performing a physical random access channel (PRACH) procedure with the base station in response to an indication that multicast pre-configuration information is available.

[0084] The cell reselection process may include sending information from the UE to the base station when a new cell is selected as a result of the cell reselection process.

[0085] The method may include transmitting a target base station identifier to a base station, the target base station identifier identifying the target base station associated with the new cell.

[0086] The method can include transmitting, to a target base station associated with the new cell, multicast session identification information to identify one or more multicast sessions in which the UE has joined.

[0087] The method further comprises, while the UE is operating in a Disconnected RRC state: receiving, before the cell reselection process, multicast data for an active multicast session according to a configuration for the base station on which the UE is camped before the cell reselection; - The pre-configuration information is for configuring the UE to receive multicast data from a multicast session from the base station where the UE is camped after cell reselection.

[0088] The cell reselection process may include the UE detecting if there are cells within the multicast service area for which the UE does not have a corresponding multicast configuration.

[0089] The request for multicast pre-configuration information may include at least one of G-RNTI information and multicast session identification information, where the G-RNTI information is used by the UE to decode the received multicast data.

[0090] According to a further aspect of the present invention, there is provided a method in a base station (gNB or NG-RAN node) controlling a cell serving a user equipment (UE), the method comprising: performing establishment of a multicast session requested by the UE; and transmitting multicast pre-configuration information for the multicast session to the UE.

[0091] The method can include receiving a request from the UE to join a multicast session from the UE, and sending the request to join the multicast session to a core network.

[0092] A multicast session may be established between a UE, a base station (NG-RAN node), and a core network (e.g., a 5G core network).

[0093] The multicast pre-configuration information may be included in at least one of a radio resource control (RRC) message and a system information block (SIB).

[0094] The pre-configuration information may include one or more of the following: - Radio bearer configuration information dedicated to low Quality of Service (QoS) transmission (e.g., multicast radio bearer "MRB2" configuration dedicated to receiving multicast data with low QoS for the candidate UE), - Radio bearer configuration information dedicated to high Quality of Service (QoS) transmissions (e.g., multicast radio bearer "MRB1" configuration primarily addressed to UEs in RRC_CONNECTED state with high QoS), - An inactive reception indication that indicates to the UE (one or more) when the UE is capable of receiving multicast data in a non-connected RRC state (for example, an RRC_INACTIVE reception indication that the gNB indicates to the UE when the UE is capable of receiving multicast data in an RRC_INACTIVE state); - Information identifying a group of UEs in the same cell that are interested in receiving multicast data (e.g., RRC_INACTIVE reception indication, where the gNB indicates to the UE if it is able to receive multicast data in the RRC_INACTIVE state), - A multicast pre-configuration ID (e.g., a Temporary Mobile Group Identity (TMGI)) that identifies the configuration applied by the UE and associated with the multicast session ID. - Discontinuous reception (DRX) setting information, - Neighbor cell multicast configuration information (e.g., applied when a candidate UE performs handover or cell reselection), and - Cell identity information (e.g., cell ID(s)) for identifying one or more cells to which the preconfiguration should be applied.

[0095] The multicast pre-configuration information may include updates to existing configuration information for receiving multicast data via a multicast session.

[0096] The method may further include transmitting data for the multicast session to the UE according to the multicast pre-configuration information.

[0097] The multicast pre-configuration information may be transmitted prior to activation of the multicast session.

[0098] The multicast pre-configuration information may be sent at the time of or after the establishment of the multicast session.

[0099] The method may further include sending a notification of the activation of the multicast session to the UE.

[0100] The notification of activation may be at least one of a paging message, an RRC message, and a SIB.

[0101] In one or more embodiments, the UE is operating in a non-connected RRC state (e.g., RRC_INACTIVE state) when the notification of activation of the multicast session is sent, and the notification of activation is sent to the UE by the base station after a cell reselection process.

[0102] The method may further include receiving a request for multicast reception and / or multicast feedback information from the UE after transmitting the multicast data to the UE, and in response, transmitting further multicast configuration data for the multicast session to the UE.

[0103] The cell reselection process may include transmitting information from the UE to the base station indicating multicast session identification information for one or more multicast sessions in which the UE has joined.

[0104] In one or more embodiments, the multicast pre-configuration information is transmitted after activation of the multicast session.

[0105] The multicast pre-configuration information may be sent to the UE in a message to place the UE in a non-connected RRC state (eg, an RRC_INACTIVE state).

[0106] The multicast pre-configuration information may be sent in an RRC release message.

[0107] The multicast pre-configuration information may be transmitted to the UE when the UE is operating in a Disconnected RRC state.

[0108] The multicast pre-configuration information may be transmitted after a cell reselection process that causes the UE to camp on a base station.

[0109] The method further comprises: sending a notification after the cell reselection process indicating that multicast preconfiguration information is available for the multicast session; receiving a multicast pre-configuration request from the UE, wherein multicast pre-configuration information is transmitted in response to receiving the request.

[0110] The multicast pre-configuration request may be received after performing a physical random access channel (PRACH) procedure with the UE.

[0111] The cell reselection process may include receiving information at the base station from the UE when a new cell has been selected as a result of the cell reselection process.

[0112] The method can include receiving, as a source base station, a target base station identifier that identifies a target base station associated with the new cell.

[0113] The method can include receiving multicast session identification information to identify one or more multicast sessions in which the UE has joined as a target base station associated with the new cell.

[0114] The UE may be set to a non-connected RRC state (e.g., an RRC_INACTIVE state). The base station may control a cell for which it has been determined that a multicast configuration modification is necessary. For example, the base station may control a cell on which the UE should be camped after a cell reselection process (e.g., a base station different from the base station for which the UE previously established its configuration for the multicast session). Alternatively, the base station may control a cell on which the UE was already capping, but a configuration update of the base station may cause a multicast configuration modification. The method may further include receiving a request from the UE for multicast pre-configuration information corresponding to the base station.

[0115] The method may further include sending a notification to the UE that the multicast pre-configuration information is available.

[0116] According to one or more embodiments, the notification is sent when the base station detects that a multicast configuration modification is required for the UE to receive multicast data in one or more cells controlled by the base station.

[0117] According to one or more embodiments, the notification is sent when the base station is notified of a modification of the multicast configuration in one or more cells controlled by another base station.

[0118] The method may further include checking that the UE has a context that enables the UE to receive multicast data for the multicast session before sending the updated multicast configuration information for the multicast session.

[0119] In a further aspect according to the present invention, there is provided a method in a user equipment (UE) (e.g., at least one UE) of a wireless communication system. The UE is configured to receive multicast data of an activated multicast session (i.e., an already activated multicast session). The method includes sending a request to a base station for updated (e.g., new) multicast configuration information for the activated multicast session (i.e., the updated multicast configuration information may be configured to replace any existing (e.g., initial or old) multicast configuration information that the UE has previously obtained), receiving the updated multicast configuration information from the base station, and configuring the UE according to the updated multicast configuration information to receive multicast data of the activated multicast session.

[0120] The method may include, in response to determining that a multicast configuration modification of the UE is necessary to receive (e.g., continue to receive) multicast data for the activated multicast session, sending a request to the base station. Prior to determining the requirement for multicast configuration modification, the UE may have already received multicast configuration information corresponding to the activated multicast session. In situations where the previously received multicast configuration information is no longer valid for receiving data for the session, a method according to this aspect advantageously reconfigures the UE with updated multicast configuration information such that the UE can continue to receive multicast data for the activated multicast session.

[0121] The previous (e.g., initial) multicast configuration information of the UE may be obtained before or after MBS session activation (establishment), for example, according to a method described in a related aspect described herein. Optionally, the previous multicast configuration information may be obtained before MBS session activation when the UE is in an unconnected RRC (e.g., RRC_INACTIVE) state or when the UE is in an RRC_CONNECTED state.

[0122] Alternatively, the UE's previous multicast configuration information may be obtained after MBS session activation when the UE is in an unconnected RRC (eg, RRC_INACTIVE) state.

[0123] The method may include the UE determining that updated multicast configuration information is required to receive multicast data for the activated multicast session. Advantageously, the UE may determine the requirement for updated multicast configuration information before sending a request to the base station.

[0124] The UE may determine that a multicast configuration modification is necessary (eg, the method may include the UE detecting a requirement for a multicast modification).

[0125] The UE may be set to an unconnected RRC state (e.g., when a request is sent to the base station). Optionally, when the UE is in an unconnected RRC (e.g., RRC_INACTIVE) state, the UE determines that it does not have an updated multicast configuration to receive multicast data (e.g., from a base station) for an activated multicast session.

[0126] The method can include sending a request to the base station in response to a reselection process. The reselection process can include the UE camping on a cell controlled by the base station (e.g., as described herein). For example, the UE may initiate a handover or reselection to the base station when configured in a Disconnected RRC state.

[0127] The method can include sending the request to the base station in response to a configuration update of the base station (e.g., a modification of the multicast configuration can be triggered by a configuration update of the base station). The configuration update can include a reset of the base station due to, for example, an error in the network and / or the base station.

[0128] The method can include receiving, at the UE, a notification that updated multicast configuration information is available. The notification can be received from a base station. A request for the updated multicast configuration information can be transmitted in response to the notification indicating the updated multicast configuration information is available.

[0129] The request for updated multicast configuration may be sent after performing a physical random access channel (PRACH) procedure with the base station.

[0130] Optionally, before sending the request for updated multicast configuration information (e.g., before determining that a multicast configuration change is necessary), the UE may have previously obtained (e.g., initial or previous) multicast configuration information that does not allow (e.g., no longer enables) the UE to receive multicast data for the activated multicast session (e.g., from the base station).

[0131] Through this method, the UE may remain in a disconnected state while continuing to receive multicast data from the activated multicast session.

[0132] In a further aspect according to the present invention, there is provided a method in a user equipment (UE) (e.g., at least one UE) of a wireless communication system. The UE is configured to receive multicast data of an activated multicast session (i.e., a multicast session that is already activated), and in this case, a modification of a multicast configuration of the UE is necessary (e.g., because multicast configuration information previously obtained by the UE for receiving multicast data of the activated multicast session is not valid (e.g., is no longer valid) for receiving multicast data from a base station). The method includes sending a request for multicast configuration information for the activated multicast session to a base station, receiving multicast configuration information corresponding to the base station, and configuring the UE according to the multicast configuration information to receive multicast data of the activated multicast session. Further optional statements of the previous aspect also apply to this aspect.

[0133] In yet another aspect according to the present invention, there is provided a method in a base station for controlling a cell. The base station is configured to serve user equipment (UE) (e.g., at least one UE) with multicast data of an activated multicast session (i.e., an already activated multicast session). The method includes receiving a request from the UE for updated multicast configuration information for the activated multicast session (i.e., the updated multicast configuration information may be configured to replace any existing (e.g., initial or old) multicast configuration information that the UE has previously obtained), and transmitting the updated multicast configuration information for the activated multicast session to the UE.

[0134] The previous (e.g., initial) multicast configuration information of the UE may be obtained before or after MBS session activation, for example, according to a method described in any one of the related aspects described herein. Optionally, the previous multicast configuration information may be obtained while the UE is in an unconnected RRC (e.g., RRC_INACTIVE) state or before MBS session activation when the UE is in an RRC_CONNECTED state. Alternatively, the previous multicast configuration information may be obtained after MBS session activation when the UE is in an unconnected RRC (e.g., RRC_INACTIVE) state.

[0135] The method may include receiving a request from the UE after determining that a modification of the multicast configuration of the UE is necessary to receive (e.g., continue to receive) multicast data for the activated multicast session. Prior to the determination of the requirement for the multicast configuration modification, the UE may have already received multicast configuration information corresponding to the activated multicast session. In situations where the previously received multicast configuration information is no longer valid, a method according to this aspect advantageously provides updated multicast configuration information to the UE, thereby enabling the UE to continue receiving multicast data for the activated multicast session while remaining in a disconnected state.

[0136] Optionally, the method may include the base station determining, before receiving the request for updated multicast configuration information from the UE, that updated multicast configuration information is necessary for the UE to receive multicast data for the activated multicast session. In this manner, the base station may detect that a multicast configuration modification is necessary (e.g., the method may include detecting, at the base station, a need for a multicast modification (e.g., update)).

[0137] The UE may be placed in an unconnected RRC state (e.g., when a request is received by the base station). The method may include the base station determining that the UE in the unconnected RRC state does not have an updated multicast configuration necessary to receive multicast data for an activated multicast session.

[0138] Optionally, the method includes receiving a request from the UE after a reselection process, which causes the UE to camp on a cell controlled by the base station. The reselection process may include the UE camping on a cell controlled by the base station (e.g., as described herein). For example, the UE may initiate a handover or reselection to the base station when set to a Disconnected RRC state. Any multicast configuration information previously transmitted by the base station may not have been received by the UE currently camped on a cell controlled by the base station.

[0139] The method may include receiving a request from the UE after a configuration update of the base station. In this manner, a modification of the multicast configuration may occur due to the configuration update of the base station. For example, before the configuration update, the base station may send multicast configuration information to the UE to enable the UE to receive multicast data for a multicast session. However, due to the modification of the multicast configuration of the UE, the previously sent multicast configuration information no longer enables the UE to receive multicast data for the activated session.

[0140] The method can further include the base station sending a notification to the UE that updated multicast configuration information is available, where the notification can be one of a paging message, an RRC message, a system information block (SIB), and an MBS control channel (MCCH) message.

[0141] The multicast setup request may be sent after performing a physical random access channel (PRACH) procedure with the UE.

[0142] Through this method, the UE may remain in a disconnected state while continuing to receive multicast data from the activated multicast session.

[0143] In a further aspect according to the present invention, there is provided a method in a base station controlling a cell serving user equipment (UE) (e.g., at least one UE). The base station is configured to provide multicast data of an activated multicast session (i.e., an already activated multicast session) to the UE, whereby a modification of a multicast configuration obtained by the UE is required (e.g., a multicast configuration previously obtained by the UE for receiving multicast data of the activated multicast session is no longer valid). The method includes receiving a request from the UE for (updated) multicast configuration information for the activated multicast session, and transmitting the corresponding (updated) multicast configuration information to the base station to the UE. The further optional statements of the previous aspect also apply to this aspect.

[0144] In a further aspect according to the invention, there is provided a device comprising user equipment configured to perform a method according to any of the method aspects outlined above with respect to a UE performed method.

[0145] In yet another aspect according to the invention there is provided a device comprising a base station configured to perform a method according to any of the method aspects described above with respect to the method performed by the base station.

[0146] Also provided is a (computer) program comprising instructions which, when executed by a computer, cause the computer to carry out a method according to any of the method aspects described above.

[0147] The program may be provided on its own or may be carried on, by or within a (computer-readable) carrier medium. The carrier medium may be non-transitory, for example a storage medium, in particular a computer-readable storage medium. The carrier medium may also be transitory, for example a signal or other transmission medium. The signal may be transmitted via any suitable network, including the Internet. Further features of the invention are characterized by the independent and dependent claims.

[0148] In any of the above aspects, the multicast session may include a session in which data is transmitted from the network to one or more UEs, with participating UEs having particular properties or particular profiles / configurations that entitle the UEs to receive data via the multicast session. The multicast session may be, for example, a 5th Generation (5G) New Radio (NR) multicast and broadcast (MBS) session as specified in 5G NR Release 17.

[0149] Any apparatus features described herein may also be provided as method features, and vice versa. As used herein, means- and function-specific features may alternatively be expressed in terms of their corresponding components, such as a suitably programmed processor and associated memory.

[0150] It should also be understood that specific combinations of the various features described and defined in any aspect of the present invention may be implemented and / or provided and / or used independently. [Brief explanation of the drawings]

[0151] Various aspects of the present invention are now described, by way of example only, and with reference to the following drawings, in which:

[0152] [Figure 1]FIG. 1 is a schematic diagram illustrating a first exemplary wireless communication system in which the present invention may be implemented in accordance with one or more embodiments. [Figure 2] FIG. 2 illustrates a block diagram of an exemplary configuration of a UE in which the present invention may be implemented in accordance with one or more embodiments. [Figure 3] FIG. 3 shows a block schematic diagram of an exemplary configuration of a base station in which the present invention may be implemented in accordance with one or more embodiments. [Figure 4] FIG. 4 is a flowchart illustrating RRC connection states and transitions for a UE in a 5G NR system. [Figure 5a] , [Figure 5b] FIG. 5 is a simplified flowchart illustrating the evolution of an MBS session from creation to activation. [Figure 6] FIG. 6 is a flow chart illustrating sending UE pre-configuration after a join request, according to an embodiment. [Figure 7] FIG. 7 is a flowchart illustrating sending UE pre-configuration after handover, according to an embodiment. [Figure 8] FIG. 8 is a flowchart illustrating sending UE pre-configuration as part of an RRC_Release procedure, according to an embodiment. [Figure 9] FIG. 9 is a flowchart illustrating the transmission of UE pre-configuration triggered by a paging message. [Figure 10a] , [Figure 10b] 10a and 10b are flow charts illustrating the transmission of UE pre-configuration as a result of a special cell reselection process, according to an embodiment. [Figure 11] FIG. 11 is a flowchart illustrating the use of pre-configuration by a UE after a session is activated, according to an embodiment. [Figure 12] FIG. 12 is a flowchart illustrating the use of pre-configuration by a UE after a session is activated, according to an embodiment. [Figure 13]FIG. 13 is a flowchart of a method performed by a gNB according to an embodiment. [Figure 14] FIG. 14 is a flowchart of a method performed by a UE according to an embodiment. [Figure 15] FIG. 15 is a flowchart illustrating a process by which pre-configuration information is received at a UE, according to an embodiment. [Figure 16] FIG. 16 is a flowchart illustrating a process for pre-configuration information to be sent by a base station according to an embodiment. [Figure 17] FIG. 17 is a flow chart illustrating a network initiated multicast configuration update for a UE in RRC_INACTIVE state, according to an embodiment. [Figure 18] FIG. 18 is a flow chart illustrating sending a configuration update request by a UE in RRC_INACTIVE state, according to an embodiment. [Figure 19] FIG. 19 is a flowchart illustrating a method for controlling a UE in an RRC_INACTIVE state to update a multicast configuration of the UE, according to an embodiment. [Figure 20] FIG. 20 is a flow chart illustrating a method for controlling a base station to update a multicast configuration of a UE in RRC_INACTIVE state, according to an embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0153] 1 illustrates an exemplary wireless communication system 100, particularly a mobile wireless communication system such as a fifth generation (5G) New Radio (NR) system that supports multicast and broadcast services (MBS). In the following description, embodiments and example embodiments of the present invention are described with respect to a 5G NR system, but it will be understood that the present invention is not limited to 5G NR systems and may be used in any wireless communication system that supports MBS or similar services.

[0154] The system 100 includes a user equipment (UE) 101 (or 151), which may be in or part of a vehicle, for example, and is served by a base station 110 for communication with a core network, such as a 5G core network 102. The UE may be any wireless device capable of wireless communication with one or more core networks via one or more radio access networks, such as a wireless communication device, apparatus, or terminal, an IoT device, a machine-type communication (MTC) device, a device-to-device (D2D) terminal, or a user device (e.g., a smartphone, laptop, mobile phone, tablet, camera, game console, wearable device, etc.). 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) consisting of base stations 110 and 111. In NR, the base station is called a Next Generation Node B (gNB), the RAN is called Next Generation (NG) RAN, and the core network is called 5G. Hereinafter, the terms RAN node, base station, and gNB are used interchangeably. The base stations 110 and 111 are interconnected using an Xn interface (specified in 3GPP document TS 38.423) implemented over a wired or wireless link 130. Each base station is connected to the core network 102 using an NG interface (specified in 3GPP document TS 38.413) implemented over wired or wireless links 140 and 141.

[0155] 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 wireless network defined by the frequencies used in the cell to transmit data. A cell may be uniquely identified by a UE from an identification broadcast over the geographical region. Each base station 110, 111 may 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 UE's serving base station or source base station, and the cell controlled by the serving base station and on which the UE is camped is called the serving cell. The interface between the gNB and the UE is the Uu interface, which 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.

[0156] 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 may be implemented in accordance with one or more embodiments of the present invention. The UE comprises components for transmitting and receiving communications, including a UE communications manager 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.

[0157] Memory 225 may include RAM (random access memory), ROM (read only memory), or a combination of both, or a mass storage device such as a disk or solid state drive, as non-limiting examples. Basic input / output system (BIOS) instructions may be stored in memory 225.

[0158] The 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 relate to, for example, transmission or interaction with peripheral devices such as a keyboard, screen, mouse, etc. (not shown in FIG. 2). The processor may execute an operating system, for example, iOS, Windows, Android, etc. The processor 215 may be a single processor or may include two or more processors that perform processing necessary for the operation of the UE 205. The number of processors and the allocation of processing functions to the processors are a matter of design choice for those skilled in the art.

[0159] The I / O controller 255 enables these interactions with external peripherals by providing the necessary hardware and by managing input and output signals.

[0160] The transceiver 235 is configured to provide two-way wireless communication with other wireless devices, for example, it provides the modem and frequency shifter necessary to connect to one or more wireless networks, such as Wi-Fi, Bluetooth, LTE, 5G NR, etc.

[0161] The wireless communication uses an antenna set 245 adapted to the spectrum of the frequency converted signal issued by the baseband modem. The antenna set 245 may be limited to one antenna, but preferably includes several antennas to provide beamforming capabilities.

[0162] The UE communication manager 220 handles the establishment, control, and release of communication for the UE to the radio access network. The UE periodically receives an indication from the base station of available slots for communication between the UE and the base station. This allows the UE to know where, in time and frequency, to expect incoming data or where to send its outgoing data, whether they belong to the control plane or the data plane. In an exemplary implementation, the UE communication manager 220 implements the Uu interface.

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

[0164] The base station communication manager 320 handles communications with multiple UEs. It is responsible for establishing, controlling, and releasing these communications. In an exemplary implementation, the base station communication manager 320 implements the Uu interface. The base station communication manager 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 involved UEs.

[0165] The core network communication manager 355 manages the base station's communications with the core network. It may provide a standardized NG interface, such as that defined by 3GPP standards, to support these communications.

[0166] The transceiver 335 is configured to provide two-way wireless communication with other wireless devices. These devices may 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 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.

[0167] Memory 325 may include RAM, ROM, or a combination of both, or a mass storage device such as a disk or solid state drive, as non-limiting examples. BIOS instructions may be stored in memory 325 to support an operating system.

[0168] The inter-station communication manager 365 manages communications with other base stations and may provide a standardized Xn interface, such as that defined by the 3GPP standard, to support these communications.

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

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

[0171] On start-up, the UE is in RRC_IDLE state 401, where the UE performs radio link quality measurements and executes a cell selection evaluation process (as defined in 3GPP specification TS 38.304) to identify a target gNB to connect to. The UE state changes to RRC_CONNECTED state 402 upon RRC connection establishment with the target gNB, which becomes the source gNB serving the UE. In the following, 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 UE's RRC state changes back to RRC_IDLE state 401.

[0172] Releasing the RRC connection is attractive for capacity utilization and power savings, but is not ideal from a latency perspective. The overhead of establishing an RRC connection requires extra signaling, which introduces delays. To address this drawback, the RRC_INACTIVE state 403 is introduced in 5G NR. When a 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 store the UE context or configuration. The stored UE context or configuration includes information to facilitate a fast resumption of the connection. This information may include security context (e.g., security parameters such as security keys and UE security capabilities), measurement configuration, radio configuration (e.g., UE radio capabilities), information about bearers, PDU (Protocol Data Unit) session context, etc. Thus, when in RRC_CONNECTED state 402, the RRC connection may be suspended by the source gNB (Release with suspend) and the UE moves to RRC_INACTIVE state 403. From RRC_INACTIVE state 403, the UE may be switched back to RRC_CONNECTED state 402 by the gNB (Resume) and the UE applies any saved UE context or settings. The RRC Resume message is sent by the gNB in response to receiving an RRC Resume Request message from the UE.

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

[0174] 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 the decision to trigger the handover procedure based on measurement reports provided by the UE. In the RRC_INACTIVE and RRC_IDLE states (e.g., non-connected states), the mobility procedure, called cell reselection, is managed by the UE itself.

[0175] In the RRC_INACTIVE state, the UE may be configured with a RAN Notification Area (RNA) 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 to which the UE can move without notifying the network. If 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 allows 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 notify the change in the RNA. As part of the cell reselection process, if 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 options available: keep the UE in the RRC_INACTIVE state, set the UE to the RRC_IDLE state, or set the UE to the RRC_CONNECTED state.

[0176] In RRC_IDLE state, a paging procedure is initiated by the core network to inform the UE that the connection must be resumed. In RRC_INACTIVE state, the paging procedure is initiated by the NG RAN (i.e., the last gNB that placed the UE in RRC_INACTIVE state).

[0177] Returning to FIG. 1, it is assumed that UE 101 is in RRC_INACTIVE state and is receiving multicast data for one or more multicast MBS sessions generated by multicast application server 103. The multicast data is provided to base station 111, the base station controlling 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). The multicast data is then transmitted from base station 111 to UE 101 through MBS radio bearer (MRB) 154. FIG. 1 further shows UE 151 receiving data through MRB 153. In a point-to-multipoint transmission of data from base station 111, MRB 154 is the same as MRB 153. In a point-to-point transmission, MRB 154 is different from MRB 153. A radio bearer is a set of PHY (Layer 1) and MAC (Layer 2) parameters that enable higher layer data connectivity between the UE and the gNB. 5G NR defines several types of radio bearers: SRBs (Signalling Radio Bearers) for the control plane, DRBs (Data Radio Bearers) that enable point-to-point communication (unicast) with one UE in the user plane, and MRBs that enable point-to-point and point-to-multipoint communication (multicast / broadcast) with multiple UEs in the user plane.

[0178] The MBS session join procedure, as specified in 3GPP TS 23.247, is used by a UE to notify the 5GC of its interest in joining a multicast MBS session. The first accepted UE join request triggers multicast MBS session establishment to the NG RAN and the UE. Before sending a join request for a multicast MBS session, the UE must have established a PDU session that can be associated with the multicast session(s) using the procedure specified in TS 23.502. Furthermore, the UE must know at least the MBS session ids of the multicast groups that the UE can join via service announcements broadcast by the network. To join a multicast group, the UE sends a PDU session change request for the associated PDU session, including one or several MBS session ids and a join request. The MBS session id(s) indicate the multicast MBS session(s) that the UE wants to join.

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

[0180] Figures 5a and 5b together show example message flows for an example scenario of MBS session evolution from creation to activation: Figure 5a shows an example message flow for creation and establishment of an MBS session, and Figure 5b shows an example message flow for activation of an MBS session.

[0181] Referring first to Figure 5a, a UE, for example UE 101 (or which could be UE 151), wakes up and enters 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 Figure 1, UE 101 connects to gNB 111). Once connected to the gNB, the UE enters RRC_CONNECTED state 502. The UE then performs a registration process, i.e., procedure 503, which aims to identify the UE in the core network, i.e., 5GC 102, check UE subscriptions, and apply authorizations. The registration procedure is detailed in section 4.2.2.2 of TS 23.502.

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

[0183] The AF (Application Function) 104 creates a multicast session in the 5G Core 102 at the request of the Application Server 103. The MBS Session Creation procedure 505 for creating a multicast session is defined in TS 23.247, clause 7.1.1. The session creation is controlled by the AF 104 (Application Function) and, once complete, an MBS session id (e.g., TMGI for Temporary Mobile Group Identity) is assigned for the multicast session and the session creation.

[0184] Once the multicast session is created, the AF 104 performs service announcement 506 toward the UEs, e.g., the AF 104 sends a service announcement message. The service announcement message includes multicast session information, which includes, among other things, a multicast MBS session ID, a 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 at the time of the service announcement can access the service information by directly querying the AF 104 (Application Function) or MBSF (MBS Service Function) in the core network 102.

[0185] There is no timing dependency between the UE Attach / Registration / PDU Session Establishment procedures (collectively identified by reference numeral 521) and the MBS Session Creation / Announcement procedures (collectively identified by reference numeral 522). Both 521 and 522 are performed independently of each other and may occur at any time.

[0186] Once the UE 101 is registered with the core network 102, a default PDU session is established, and multicast service information is known, the UE may join 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 known by the UE after receiving a service announcement message 506, by pre-configuration, or by querying information from the core network (message flows for pre-configuring or querying session information are not shown in Figures 5a or 5b). To join the multicast session, the UE may reuse the previously created default PDU session (at 504) and send a PDU session change request including the multicast session ID (TMGI). The resulting PDU session change request is considered a join request (507). Another possibility is to establish a dedicated (individual) MBS PDU session including the multicast session ID for the join request 507.

[0187] Upon receiving the join request 507, the core network 102 performs a 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 authorized to access the multicast session (i.e., checks that the UE is in one of the specific multicast groups of UEs that are authorized to receive the multicast session). As part of the session establishment procedure 508, the core network 102 also sets up the necessary resources in the core network to carry multicast data from the application server 103 to the relevant gNBs. The relevant gNBs are 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 clause 7.2.1 of TS 23.247.

[0188] In the example shown in FIG. 5a, an NG-RAN gNB (e.g., gNB 111) decides to switch UE 101 to RRC_INACTIVE state 510 by sending an RRCRelease message 509 (Section 6.2.2 of TS 38.331). The most common reason is load management, where the gNB decides to offload its control plane load by switching some UEs to RRC_INACTIVE. Ongoing discussions on Release 18 also suggest that both the UE and the core network provide additional information to the gNB to help the gNB make the decision to switch some UEs to 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.

[0189] Referring now also to FIG. 5b, when the UE is in RRC_INACTIVE state 510, the UE performs cell reselection process 511 as a background task. This process manages UE mobility and allows it to "reselect" to a new gNB depending on 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 is either gNB 110 or gNB 111, depending on the UE's movement. It should be noted that cell reselection 511 is an optional step in the method shown in FIG. 5b, as indicated by the dashed outline. Furthermore, such optional method steps are indicated by dashed lines in subsequent figures.

[0190] Once the MBS session is created (505), the AF 104 (Application Function) in the core network 102 may 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 already participating in the multicast session. The RAN resource allocation includes MBS Radio Bearer (MRB) configuration. Each gNB uses a specific configuration for its MRB for the multicast session.

[0191] Once the multicast session is activated upon completion of MBS session activation 512, the core network 102 may need to page some UEs to inform them of the availability of multicast data. RRC_INACTIVE UEs need to be paged because, as explained in 510, RRC_INACTIVE UEs are still moving and can enter the cell of another gNB, but neither the new gNB (target gNB) nor the first gNB (source gNB) is aware of the UE's movement at this step (i.e., when the multicast session is activated 512). The core network 102 sends a group paging message to the gNBs with the MBS session id (not shown in Figure 5b), and then each gNB sends a group paging message 513 with the multicast session id.

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

[0193] As part of preparing to resume the RRC connection, the UE 101 performs a random access procedure towards the gNB (PRACH procedure 516, where PRACH stands for Physical Random Access Channel). The PRACH procedure aims to update the UE's system information if the UE has moved to another cell or if the UE's system information has not been updated for some time. The UE 101 then performs and completes a connection resumption procedure in 517, which includes sending an RRCResumeRequest message (not shown in FIG. 5b). The connection resumption procedure 517 follows the RRC connection procedures detailed in TS 38.331.

[0194] Once the RRC connection procedure is complete, the UE is in RRC_CONNECTED state 518.

[0195] Only in a step when the UE 101 is in the RRC_CONNECTED state 518, the gNB 111 may send a multicast configuration (including MRB information) to the UE in step 519. This step includes sending an RRCReconfiguration message (section 6.2.2 of TS 38.331) including the MRB information.

[0196] The UE can receive multicast data at 520 upon applying the received multicast configuration.

[0197] As explained in the introduction, if the UE has to switch from RRC_INACTIVE state to RRC_CONNECTED state to perform configuration for multicast reception, the additional signaling and other resources required to configure the UE in RRC_CONNECTED state will result in load problems at the NG-RAN node (gNB) (i.e., too many UEs in RRC_CONNECTED state), and therefore the benefit of switching the UE to RRC_INACTIVE state to avoid congestion will be lost or at least reduced. For example, as mentioned above, the paging, PRACH, process for resuming to RRC_CONNECTED state and subsequent MBS configuration may cause link congestion and delay issues.

[0198] The following embodiment provides a method for configuring a UE to receive multicast data while in RRC_INACTIVE state that simplifies the procedure of Fig. 5b, since the RRC resumption procedure followed by MBS configuration can be skipped if the UE is pre-configured to receive in such a condition.

[0199] 15 illustrates one embodiment of the present invention, a method 1500 performed in a UE. At 1501, a UE may transmit a request to join a multicast session. In 5G NR, the request is typically transmitted to the core network via a base station such as a gNB 110, 111, although it is contemplated that in alternative implementations the request may be transmitted to or via another network entity (e.g., a UE acting as a relay).

[0200] At 1502, multicast pre-configuration information is received by a UE prior to activation of a multicast session in which the UE requests to join. The session activation may be, for example, an MBS session activation, as described above with respect to 512 in FIG. 5. The pre-configuration information may be received from a base station or from another entity in the network, such as the UE acting as a relay. The UE may then configure itself according to the multicast pre-configuration information to receive multicast data via the multicast session (1503).

[0201] FIG. 16 shows a flowchart 1600 with steps performed at a base station, according to one embodiment. At 1601, a request made by a UE to join a multicast session may be received by the base station. The request is directed to the core network, and therefore, such request may subsequently be forwarded (transmitted) by the base station to the core network 102. At 1602, a multicast session is established. That is, the base station participates in a multicast session establishment process to establish a session between the UE and the core network. This includes receiving information from the core network in response to the join request as part of the establishment process. The multicast session establishment may include MBS session establishment 508, described in connection with FIG. 5, which establishes the MBS session requested by the UE 101 between the UE 101, the gNB 110, 111, and the core network 102. Thereafter, at 1603, multicast pre-configuration information is transmitted to the UE prior to activation of the multicast session.

[0202] In this description, "multicast pre-configuration information" refers to received and stored configuration information that is later applied in appropriate circumstances. According to some embodiments, it is received before multicast (MBS) session activation for the session to which the pre-configuration information relates. In other embodiments, the UE may receive multicast data after multicast (MBS) session activation, and the network provides the pre-configuration data to pre-configure the UE to receive multicast data after cell switching as a result of a cell reselection process. Depending on the implementation, it may be used to configure the UE before and / or after multicast (MBS) session activation. When specifically mentioned in the description of "multicast (MBS) pre-configuration" of a UE, this refers to the act of applying the received multicast pre-configuration information in appropriate circumstances to receive multicast (MBS) session information.

[0203] Sending and receiving pre-configuration information before activation allows the network to reduce the configuration load and signaling overhead when receiving the first multicast data, thereby reducing the risk of overloading the cell (i.e., the radio resources within the cell) and / or the gNB (i.e., the processing resources at the gNB) when configuring all involved UEs with the radio resources required when the session is activated.

[0204] According to an embodiment, the UE may be configured at different stages. In one embodiment, the network may configure the UE after a join request made by the UE and upon arrival of the first multicast data. Thus, when the network is ready to configure the UE, it generates a trigger information element or message that is sent to the UE.

[0205] In the following sections, different scenarios are described, and different possibilities exist for transmitting the multicast pre-configuration information depending on the triggering event(s). For example, the triggering event may be a multicast establishment on the network side, i.e., once a multicast configuration context becomes available on the network side, a multicast pre-configuration message is sent (e.g., by a base station) to one or more (candidate) UEs.

[0206] Other triggering aspects may be evaluated by the network, for example, by determining which UEs are suitable candidates for a multicast session (e.g., based on the UE capabilities). Once a group of candidate UEs is determined, the network may trigger a multicast pre-configuration message to the identified group of UEs.

[0207] For example, a candidate UE may have the capabilities listed below: - Being able or willing to receive multicast data in RRC_INACTIVE state, - Receiving multicast data in RRC_CONNECTED state with low QoS.

[0208] In some scenarios, the UE may request pre-configuration, thus triggering a multicast pre-configuration message to be sent by the network side (i.e., from the base station).

[0209] The multicast preset information may include one or several presets, and each preset may take into account various information elements, including but not limited to: - a dedicated multicast radio bearer "MRB2" configuration for receiving multicast data with low QoS for candidate UEs or a "MRB1" configuration addressed primarily to UEs in RRC_CONNECTED state with high QoS, - RRC_INACTIVE reception indication, in which the gNB indicates to the UE whether it can receive multicast data in the RRC_INACTIVE state (the absence of this indicator means that the UE can receive multicast data in the RRC_INACTIVE state by default); - G-RNTI, which identifies a group of UEs in the same cell that are interested in receiving multicast data; - a multicast preconfiguration ID that refers to the configuration applied to the UE and associated with an MBS session ID (e.g. TMGI); - A discontinuous reception (DRX) configuration used to receive multicast data for the candidate UE; - Neighbor cell multicast configuration to be applied when a candidate UE performs handover or cell reselection; - Cell ID(s) identifying the cell(s) to which the preconfiguration should be applied.

[0210] The multicast configuration or pre-configuration of an MBS session may comprise common information elements that are used for all NG-RAN nodes located within the MBS service area, so that the UE has a common configuration that can be applied anywhere within the MBS service area, making cell (re)selection or handover transparent to the mobile UE.

[0211] The following description describes various embodiments for transmitting multicast pre-configuration information at various stages with various possible trigger events. These include: - MBS session establishment in (or after) RRC_CONNECTED state (Figure 6), - When the UE switches to RRC_INACTIVE state: - If the UE is in RRC_INACTIVE state, - Most of the scenarios cover possible handovers in RRC_CONNECTED state or cell (re)selection in RRC_INACTIVE state.

[0212] In the first scenario, in order to send the MBS multicast configuration to the UE, the NG-RAN node must have performed radio resource reservation corresponding to the MBS session requirements, such as QoS flow information or the receiving RRC state (RRC_CONNECTED, RRC_INACTIVE).

[0213] During the UE Join Request procedure, the gNB has sufficient information to perform radio resource reservation for UE reception in both RRC_INACTIVE and RRC_CONNECTED states. Based on this knowledge, according to one embodiment, pre-configuration information (corresponding to RRC_INACTIVE and RRC_CONNECTED) is sent by the gNB to the core network, which then sends it to the UE. Thus, UE configuration is distributed in time prior to session activation.

[0214] FIG. 6 is a flowchart illustrating the transmission of multicast pre-configuration information after a join request by a UE according to an embodiment based on the first scenario.

[0215] UE 601 belongs to a group of candidate user equipment (UE) capable of receiving multicast data with low QoS, as described above. This UE 601 is in RRC_CONNECTED state 604 and is about to join an MBS session. After a notification message 506 from 5GC 603 informing about the MBS session creation with the associated TMGI (i.e., Temporary Mobile Group Identity used as the valid MBS session ID), UE 601 proceeds to session join step 605 (or alternatively, session update) and then to session establishment in 606. In one embodiment, these steps correspond to step 1300 described below with respect to FIG. 13. UE 601 may inform NG-RAN node 602 and 5GC 603 about its capabilities and / or preferences for receiving multicast (MBS) data with low QoS or for receiving multicast (MBS) data in RRC_INACTIVE state. This information may be sent earlier, during the registration phase or during the join request.

[0216] After accepting the join request, an MBS session establishment procedure is performed between the UE 601, the NG-RAN node 602, and the 5GC 603 at 606. A multicast session context is created and associated with the UE 601 at 606. In Release 17, an MRB context may be established and included in the multicast session context, and radio resources may be reserved as per 1301. At this stage, the MRB context refers to either an MRB1 or MRB2 context for a UE that is authorized to receive multicast data in RRC_CONNECTED state (clause 6.4 of TS 38.401 and clause 7.2.1.3 of TS 23.247), but no MRB context is available for receiving in RRC_INACTIVE state.

[0217] In this embodiment, pre-configuration may be added to the MBS session establishment procedure 606, and radio resources may be reserved as in step 1301. That is, multicast pre-configuration information is sent to the UEs when the multicast session is established. Then, the UEs that are pre-configured at this stage using the received multicast pre-configuration information can receive multicast data in the RRC_INACTIVE state.

[0218] Multicast (pre)configuration may refer in the following description to multicast point-to-multipoint (PTM) configuration, which enables shared over-the-air delivery of multicast data to one or more UEs. Multicast PTM configuration applies to UEs receiving multicast data in RRC_INACTIVE state.

[0219] For example, the multicast pre-configuration information may be added to an already existing multicast session context in the MBS session establishment procedure 606. Another implementation involves creating a new multicast pre-configuration session context separately and then adding it to the procedure in 606. The multicast pre-configuration session context is then added to information elements sent through RRC reconfiguration messages exchanged with the UE during the MBS session establishment phase.

[0220] The multicast pre-configured context should be established by the network earlier than or at the time of MBS session establishment 606, and thus may trigger modification and / or creation of the multicast session context at 606. Further conditions may be added to the triggering event, such as candidate UE portfolio.

[0221] The multicast preconfiguration information includes (one or more) MRB1 / MRB2 configurations and a list of the information elements mentioned above. The network may choose shared delivery of multicast data to multiple UEs through multicast PTM preconfiguration. Otherwise, the UE may be preconfigured for individual delivery, for which a dedicated multicast preconfiguration is specified.

[0222] When an MBS session is activated and UE 601 is in RRC_INACTIVE state, the UE may apply its multicast pre-configuration to receive multicast data without needing to resume RRC_CONNECTED state.

[0223] The multicast pre-configuration context may be established after the MBS session establishment in 606, which triggers different multicast pre-configuration messages to be sent to the UE 601 depending on its RRC state. The following scenarios illustrate other alternatives for configuring / pre-configuring the UE by receiving pre-configuration information under different timing and / or conditions.

[0224] Some UEs are constantly moving and may move after receiving pre-configuration information from a gNB. Therefore, if a gNB hands over a UE in RRC_CONNECTED state to another gNB because the UE has moved, it is important that the new gNB changes the UE pre-configuration information to match its resources. Therefore, in this second scenario, the pre-configuration information is always accurate when the UE moves to another cell.

[0225] FIG. 7 is a flowchart illustrating sending UE pre-configuration after handover according to an embodiment applicable in the second scenario.

[0226] The network may choose to pre-configure the UE 601 independent of the MBS session establishment procedure at 706. Furthermore, a multicast pre-configuration context may be set up by the network after the MBS session establishment 706, which may then trigger a message at 708 to send pre-configuration information to the UE 601, which may be used to pre-configure or configure the UE. The scenario of Figure 7 assumes that after the MBS session establishment 706, a multicast pre-configuration / configuration context is available, but the UE is in an RRC_CONNECTED state. The NG-RAN node 602 may include this context in the multicast pre-configuration message at 708. Other trigger conditions related to the candidate UE portfolio may be required for sending the multicast pre-configuration message at 708.

[0227] The message in 708 corresponds to step 1302 if the UE is in the RRC_CONNECTED state and the pre-configuration message is sent. Message 708 may also be equivalent to step 1306 of Figure 13 (described below) if the handover is performed in the RRC_CONNECTED state.

[0228] In one example, the message in 708 can be sent to the UE 601 in one or more RRC messages, such as an RRCReconfiguration message, an RRCRelease message with SuspendConfig, or a dedicated system information block (SIB), which can include various information elements, primarily MRB2 configuration.

[0229] Before the multicast pre-configuration information is received, handover may occur at 707 and the candidate UE 601 is not yet pre-configured. During the handover procedure, the source NG-RAN node 602 may exchange UE capabilities and preferences (i.e., RRC_INACTIVE / CONNECTED multicast reception with low QoS) with the target NG-RAN node 700. Thus, the target NG-RAN node 700 may choose to pre-configure this UE by sending a multicast pre-configuration message.

[0230] For example, the handover 707, 1304 may occur after the source multicast preconfiguration message at 708, after which the target NG-RAN node 700 should send a target multicast preconfiguration message. Another alternative involves including a list of neighboring cells with corresponding multicast preconfiguration / configuration in the source multicast preconfiguration message 708. In this case, the UE 601 being handed over to the target NG-RAN node 700 can apply the target multicast preconfiguration without having to be preconfigured again.

[0231] In the particular case where the source NG-RAN node 602 and the target NG-RAN node 700 are in the same MBS service area and a common multicast pre-configuration / configuration context is shared within the MBS service area, the UE 601 may be pre-configured / configured once within the MBS service area.

[0232] A third scenario may be considered, in which a UE may indicate its capabilities and preferences regarding the RRC states for reception when performing a join request procedure. As part of the session establishment, the gNB also knows the application capabilities / preferences regarding the RRC states for reception by the UE. At any time, due to load management needs, the gNB may decide to switch some UEs to the RRC_INACTIVE state using the RRC release procedure. As part of the RRC release procedure, the gNB may send or update pre-configuration to the UEs to be switched. This allows updating resource reservations according to load stress at the gNB prior to session activation.

[0233] FIG. 8 is a flow chart illustrating the transmission of UE pre-configuration as part of an RRC_Release procedure, according to an embodiment that is particularly useful in the third scenario described above.

[0234] In particular, Figure 8 illustrates another alternative for pre-configuring one or more UEs capable of and / or willing to receive low QoS multicast data in RRC_INACTIVE or RRC_CONNECTED state. The process illustrated in this figure corresponds to the offloading step at 1307 in Figure 13, which is described in more detail below. After a join request 605 and MBS session establishment 806, the UE 601 can receive multicast data in the RRC_CONNECTED state as in Release 17. The UE 601 is considered a candidate UE by the NG-RAN node 602.

[0235] The NG-RAN node 602 may choose to switch a group of UEs to the RRC_INACTIVE state to control signaling overhead and reduce power consumption. The NG-RAN node 602 may decide to pre-configure candidate UEs of that group to remain in the RRC_INACTIVE state to receive multicast data.

[0236] In one example, the decision of the networks 602, 603 at 809 may trigger the multicast pre-configuration message sent at 807 and referenced at 1309. The trigger event may correlate with the availability of a multicast pre-configuration context in the network and the portfolio of the switched UE.

[0237] For this purpose, the NG-RAN node 602 may use an RRCRelease message with SuspendConfig at 807 and 1309 with modifications to its content. An additional field related to the multicast pre-configuration context may be included so that the candidate UE 601 knows to perform a transition to the RRC_INACTIVE state 808 and then be pre-configured to receive multicast data while in the RRC_INACTIVE state. An RRC_INACTIVE reception indicator may be added to the multicast pre-configuration message to inform the pre-configured UE that it is allowed to receive while in the RRC_INACTIVE state. This field is optional and its absence allows the UE to receive multicast data by default when in the RRC_INACTIVE state once the multicast data arrives at the UE.

[0238] The NG-RAN node 602 may choose to send the multicast preconfiguration information in a separate multicast preconfiguration message before the RRCRelease message. The separate message may be sent in an RRC or dedicated SIB container type, as an example. In this description, the term SIB is used as a shorthand for SIB+MCCH, which means using system information block and / or MBS control channel messages. For example, MCCH scheduling information may be provided via a SIB, or alternatively, the information may be included entirely in the SIB.

[0239] In a fourth scenario, the gNB may handle the release of the UE and its transition to the RRC_INACTIVE state without modifying the RRCRelease procedure. A paging message issued by the gNB may indicate to interested UEs a possible multicast pre-configuration in the RRC_INACTIVE state.

[0240] An embodiment relating to the fourth scenario is shown in FIG. 9, which is a flow chart illustrating the sending of UE pre-configuration triggered by a paging message.

[0241] UE 601 is a candidate UE that can receive multicast data in RRC_INACTIVE state. It sends a join request at 605, and an MBS session is established at 906 between UE 601, NG-RAN node 602, and 5GC 603.

[0242] The NG-RAN node 602 may decide to reduce the signaling load and switch the group of UEs to RRC_INACTIVE state, at 908, by sending an RRCRelease message, at 907.

[0243] The NG-RAN node may send a notification message at 910 to pre-configure the UE 601 in the RRC_INACTIVE state as in step 1303. The notification of the availability of multicast pre-configuration may be any one of a paging message, an RRC message, or a system information block (SIB).

[0244] The notification of the multicast pre-configuration update can be any one of a paging message, an RRC message, or a system information block (SIB).

[0245] In Figure 9, message 910 is shown as a paging message that includes, for example, the TMGI of the MBS session and a paging cause indicating that the paging is for multicast pre-configuration, as in 1405 of Figure 14, described below, which may be triggered by the network after the setup or update of the multicast pre-configuration context.

[0246] The UE 601 in the RRC_INACTIVE state may process the paging message and determine the paging cause at 911. If the UE 601 has subscribed to the MBS multicast session and is interested in receiving multicast data while in the RRC_INACTIVE state, a PRACH exchange procedure at 912 is initiated by the UE 601 with the NG-RAN node 602. At 912, the UE 601 requests uplink radio resources for L2 / L3 messages. The UE 601 then sends a multicast pre-configuration request at 913 to the NG-RAN node 602, including its UE identity (e.g., I-RNTI) in the RRC_INACTIVE state.

[0247] The NG-RAN node may respond with multicast pre-configuration information at 914 (corresponding to 1406 in FIG. 14 described below) if the UE is suitable to receive multicast data. A reject message may be sent to the UE 601 with a reject cause. In one example, the UE 601 may not be suitable for reception in an RRC_INACTIVE state according to the network, so the RRC_INACTIVE reception indicator may be disabled and sent as the reject cause.

[0248] After switching the UE to RRC_INACTIVE state at 908, cell (re)selection may occur at 909. In this case, steps 910 to 914 are subject to message exchange with the new target NG-RAN node 900. At 910, the target NG-RAN node may send a notification message. The notification message may be a paging message, a SIB, or a dedicated RRC message.

[0249] As an example, message 910 may be a group paging message containing the TMGI for the MBS session and a paging cause indicating available multicast pre-configuration at the target NG-RAN node. After cell reselection at 909, UE 601 is not yet identified by the target NG-RAN node 900. After processing the paging by UE 601, a PRACH exchange procedure at 912 is subsequently initiated by UE 601 with the target NG-RAN node (602) to indicate its presence in the target cell and request radio resources for uplink signaling message exchange. If UE 601 is already participating in the MBS session and is interested in receiving multicast data in the RRC_INACTIVE state, it may send a multicast pre-configuration request to the target NG-RAN node at 913. The target NG-RAN node then verifies that the UE has joined the MBS session and is capable and suitable to receive multicast data in the RRC_INACTIVE state. The target NG-RAN node may then send 914 a multicast pre-configuration response to the UE 601. The target NG-RAN node may reject the request with an indication of the cause of the rejection, which may be a disabled RRC_INACTIVE reception indicator, which informs the UE that multicast reception in the RRC_INACTIVE state is not allowed.

[0250] The multicast pre-configuration request at 913 can be sent in various container types. In one example, an RRC message such as an RRC Resume Request with additional fields for pre-configuration purposes can be used. The SIB on Demand can also be used by the UE to request multicast pre-configuration.

[0251] The multicast preconfiguration information at 914 may be sent by the network using various container types. An RRC message such as RRCResume with dedicated multicast preconfiguration, RRCRelease with SuspendConfig, or an RRCReconfiguration message keeps the UE in RRC_INACTIVE state. Otherwise, the on-demand SIB sent by the UE at 913 may trigger a dedicated SIB sent by the network with the required multicast preconfiguration at 914. In the case of a reject message at 914, it may be sent by an RRC message, a dedicated SIB, or another container type.

[0252] In a fifth scenario, the gNB may pre-configure the UE that has switched to the RRC_INACTIVE state by sending a multicast pre-configuration message.

[0253] Figures 10a and 10b are flow charts illustrating an embodiment particularly applicable to the fifth scenario above, showing sending UE pre-configuration to a UE in RRC_INACTIVE state and applying an enhanced cell reselection process.

[0254] 10a shows that UE 601 attempts to join a multicast MBS session at 605 while in RRC_CONNECTED state 604. A multicast MBS session is then established at 1006 between UE 601, NG-RAN node 602, and 5GC 603.

[0255] UE 601 is a candidate UE that may be able and / or willing to receive multicast data with low QoS, whether in RRC_INACTIVE or RRC_CONNECTED state.

[0256] 9 embodiment, the NG-RAN node 602 may choose to switch a group of UEs to the RRC_INACTIVE state to reduce signaling load and reduce power consumption. An RRCRelease message is then sent at 1007, and the UEs switch to the RRC_INACTIVE state at 1008.

[0257] The network may trigger a multicast pre-configuration message at 1010 (corresponding to step 1303 of FIG. 13, referenced later), which includes pre-configuration information elements required for receiving multicast data while in RRC_INACTIVE state. The UE applies a cell reselection process at 1009 that follows an enhanced cell reselection process with an additional reselection request message.

[0258] In the standard cell reselection procedure, the UE performs measurements of signals from all neighboring cells (gNBs). Then, based on the measurements and evaluation criteria, the UE selects the best candidate cell (gNB). If the selected cell (gNB) is not the current cell (the cell on which the UE is camped, i.e., the source cell), the UE changes to a new cell (the target cell).

[0259] In the enhanced cell reselection procedure, if a new cell is selected as the best candidate by the UE, a reselection request message is sent by the UE to the source gNB (old cell) before the cell change. The reselection request message includes target cell identity information. Upon receiving the request message, the source gNB informs the target gNB that the UE will camp on the target cell (new cell) and is participating in an MBS session.

[0260] In an alternative embodiment, the UE sends a reselection request message to the target gNB after the cell change. In this alternative embodiment, the reselection request message includes the MBS session information.

[0261] As a result of the enhanced cell reselection procedure, the gNB knows of RRC_INACTIVE UEs in the cell, and these UEs have up-to-date system information, so that the paging, PRACH, and (pre-)configuration request steps can be skipped. Further details of the above enhanced cell reselection process can be found in UK Patent Application No. GB2205138.7.

[0262] For example, the multicast preconfiguration context may include an MRB2 context, a multicast configuration ID, associated G-RNTIs, DRX configuration, and neighbor cell multicast preconfiguration. The triggering event may depend on the network establishment of the multicast preconfiguration context or the UE (601) portfolio. For example, the network may select a group of UE candidates to receive while in the RRC_INACTIVE state, which triggers the multicast preconfiguration message. The multicast preconfiguration information in 1010 may use various container types. For example, an RRC message may be suitable for carrying the multicast preconfiguration information, and in particular, an RRCReconfiguration message or an RRCRelease message with SuspendConfig may be used with an additional field identifying the multicast preconfiguration context. The network may also adopt other alternatives, for example, the multicast preconfiguration context may be transmitted in a dedicated SIB for preconfiguring the UE 601 or a group of UEs for shared distribution.

[0263] In Figure 10b, where the UE (601) is in RRC_INACTIVE state 1008, an enhanced cell (re)selection is considered. The procedure 1009 is slightly different from that in Figure 9, where a simple cell reselection 909 is applied without notification to the NG-RAN node 602. The UE 601 then has to request multicast pre-configuration at 913 upon receiving notification from the network (paging at 910).

[0264] In an enhanced cell reselection procedure at 1009, the UE 601 notifies the target NG-RAN node 900 of its arrival. Following this, UE context may be exchanged between the source NG-RAN node and the target NG-RAN node 900, including, by way of example, UE capabilities and / or preferences. The UE 601 may simply send its capabilities and / or preferences and the relevant G-RNTI of the target NG-RAN node at 1009. For this reason, the target NG-RAN node may not require a prior exchange of UE context.

[0265] The target NG-RAN node 900 finally sends the multicast pre-configuration to the UE 601. The content and container types are as described earlier in this section.

[0266] Other aspects of enhanced cell reselection may be considered in this embodiment. After cell selection in 1011, the UE 601 may send a reselection notification message to the target gNB in 1012. The reselection notification may indicate the presence of the UE (601) in the target cell and / or may request multicast configuration from the target gNB (900). The notification message in 1012 may include an MBS session ID (e.g., TMGI). The notification message in 1012 may be sent in an RCR Resume Request message.

[0267] Upon receiving the message at 1012, the target gNB 900 may proceed to UE context exchange 1013 with the source gNB 602, as described in UK Patent Application No. GB2205138.7, and then to admission control 1014. Steps at 1013 and 1014 may be skipped if the pre-configured UE provides proof of authorization in the message at 1012. The proof may be the G-RNTI of the target cell corresponding to the group of UEs receiving multicast data for the MBS session ID. The target gNB 900 may then skip steps 1013 and 1014 and may send reselection feedback at step 1015. The G-RNTI information may be associated with the MBS session ID, multicast configuration ID, and / or cell ID in the message at 1012, which may inform the target gNB whether the UE (601) is authorized to receive multicast data. Furthermore, it may indicate whether the UE in RRC_INACTIVE state has permission to receive multicast data for the corresponding MBS session.

[0268] Message 1015 may contain multicast (pre)configuration to the UE, or a simple denial if no permission is available. Message container 1015 may be RRCRelease with Suspendconfig containing the configuration. SIB messages may also be employed.

[0269] In the following, embodiments are described that explain how pre-configuration information received at a UE according to any of the embodiments described herein is used to configure the UE after session activation.

[0270] In one such embodiment, a multicast reception request may be sent by the UE in response to an MBS session active activation, which triggers the gNB to transmit multicast data for the UE in an RRC_INACTIVE state. Further, the UE may send a multicast reception feedback request to the gNB upon receiving first multicast data in RRC_INACTIVE.

[0271] FIG. 11 is a flowchart illustrating the use of pre-configuration by a UE after a session is activated, according to an embodiment.

[0272] UE 601 is in RRC_INACTIVE state 1102. In response to the MBS session activation at 1104 and 1310, first multicast data arrives at NG-RAN node 602 and triggers a notification message at 1105. The notification message at 1106 may be a group paging message, a SIB, or a dedicated RRC message. In this embodiment, in one example, the message at 1106 is a group paging message addressed to UE 601 in RRC_INACTIVE state. The paging message 1106 may include an MBS session ID (e.g., TMGI) and a paging cause indicating MBS session activation for the corresponding MBS session, as at 1408.

[0273] The UE 601 may process the paging message at 1107 (and 1409) and apply the multicast pre-configuration previously sent by the networks 602, 603. A PRACH exchange procedure at 1108 is initiated by the UE 601 with the NG-RAN node 602, allowing it to request uplink radio resources for future signaling message exchanges with that NG-RAN node.

[0274] The steps at 1109 and 1113 depend on the state of the UE 601 at 1107. The UE 601 may have been pre-configured by an NG-RAN node or may request pre-configuration or reception in RRC_INACTIVE state. The following example illustrates possible messages that may be conveyed at steps 1109 and 1113 according to an embodiment.

[0275] In a first example, the UE 601 may send a multicast reception request 1109 to the network, with the purpose of informing the network of its presence and willingness to receive multicast data in the RRC_INACTIVE state. The network 602, 603 processes the request 1109 at 1110 to transmit the multicast data using the MRB2 radio bearer. The request at 1109 may include the MBS session ID, the multicast preconfiguration ID, and the G-RNTI, so that the network can verify whether the UE 601 has permission to receive the multicast data and / or is in the RRC_INACTIVE state. After this, the multicast data sent at 1111 may be sent to the UE (601) or to a group of candidate UEs in the RRC_INACTIVE state.

[0276] In a second example, the NG-RAN node 602 may transmit multicast data using a multicast pre-configuration previously exchanged with the UE 601. The multicast data at 1112 is then received in response to the processing of the paging stage at 1107. A feedback message at 1109 may then be sent to notify the NG-RAN node that it is receiving in the RRC_INACTIVE state, so that the NG-RAN node is informed and may continuously multicast data in the RRC_INACTIVE state. The feedback message at 1109 may allow the gNB 602 to estimate the number of UEs receiving in the RRC_INACTIVE state.

[0277] In a third example, the UE 601 is not yet preconfigured to receive in the RRC_INACTIVE state. Therefore, the paging message at 1106 indicates that the MBS session is now activated. The UE 601 may then process the paging at 1107 and request to be configured to receive multicast data in the RRC_INACTIVE state. To this end, it may interact with the NG-RAN node 602 in a PRACH procedure 1108 and then send a multicast request at 1109. The message at 1109 may request a multicast configuration for receiving in the RRC_INACTIVE state. The request at 1109 may include the MBS session ID, the multicast preconfiguration ID, and the G-RNTI, so that the network can verify whether the UE 601 has permission to receive multicast data and / or is in the RRC_INACTIVE state. The network 602, 603 processes the request at 1110 and responds with a multicast configuration that is sent back to the UE 601 at 1113. If permission is not granted, the network may deny the UE's request.

[0278] At session activation 1104, 1310, the gNB may pre-configure the UE and must notify the UE of the session activation at 1106 and 1315. It may send the configuration to an unconfigured UE in RRC_INACTIVE state, as at 1317 and 1113. The gNB may need to update or build the configuration at 1312. The configuration is then sent to the UE in RRC_INACTIVE state, as at 1113 and 1314.

[0279] The UE 601 may perform a simple cell (re)selection 1103 when in the RRC_INACTIVE state. After multicast MBS session activation 1104 and in response to the arrival of multicast data 1105, the target NG-RAN node 900 may send a paging message 1106 with a corresponding multicast MBS session ID (e.g., TMGI) and a paging cause indicating the multicast MBS session activation status. As a result, the UE 601 is transparent to the target NG-RAN node (900). While processing the paging message at 1107, the UE 601 may apply the multicast preconfiguration of the target NG-RAN node 900, if available; i.e., this information element pertains to the neighbor cell multicast preconfiguration that may be communicated to the UE (601) by the source NG-RAN node 602 at the time of multicast preconfiguration.

[0280] The UE 601 then interacts with the target NG-RAN node 900 in a PRACH procedure at 1108. After the PRACH procedure, various scenarios may be envisioned, including but not limited to the following examples:

[0281] In a first example, the UE 601 is considered to be pre-configured to receive multicast data in the target cell at 1107. Following the PRACH procedure at 1108, the UE 601 may send a multicast reception request at 1109 to activate multicast reception in RRC_INACTIVE state at the target NG-RAN node 900, if not already done so. The request at 1109 may include the MBS Session ID, the Multicast Configuration ID, and the G-RNTI, so that the network may verify whether the UE 601 has permission to receive multicast data and / or is in RRC_INACTIVE state. After processing the request 1109 with the network at 1110, the target NG-RAN node 900 may redirect the multicast data at 1111 for the UE 601 or for a group of candidate UEs capable of receiving multicast data in RRC_INACTIVE state.

[0282] In a second example, it is again assumed that the UE 601 has applied multicast pre-configuration in step 1107, and that the target NG-RAN node 900 is transmitting multicast data 1112 after the paging message 1106 over the MRB2 radio bearer. The UE 601 may interact with the target NG-RAN node 900 (PRACH procedure in 1108) and may send a multicast acknowledgement as feedback to the target NG-RAN node 900 in 1109. The target NG-RAN node processes the acknowledgement in 1110 and recognizes the presence of UEs receiving in RRC_INACTIVE state. The feedback in 1109 may allow the gNB 602 to estimate the number of UEs receiving in RRC_INACTIVE state.

[0283] In a third example, the UE 601 may request a multicast configuration for reception in RRC_INACTIVE state in message 1109. The message in 1109 may include the MBS session ID, multicast configuration ID, and G-RNTI, so that the network may verify whether the UE 601 has permission to receive multicast data and / or is in RRC_INACTIVE state. The target NG-RAN node 900 may process the request in 1110 and then send multicast configuration information 1113 dedicated for RRC_INACTIVE multicast reception, if available. After configuring the UE 601 to receive in RRC_INACTIVE state, the target NG-RAN node transmits the multicast data as in 1111. The target NG-RAN node 900 may send a reject response to the UE 601, so that reception may not occur in RRC_INACTIVE state.

[0284] The messages in 1109 and 1113 may use an RRC container message or a dedicated SIB message. The container type may not be limited to the RRC or SIB type.

[0285] At 1109, the RRC message may be an RRC Resume Request, which includes additional fields depending on the various scenarios detailed above, which may indicate various reasons, such as: - Multicast receive request to activate multicast data transmission in RRC_INACTIVE state, - Multicast feedback reception for confirmation of the presence of UEs receiving multicast data in RRC_INACTIVE state; - A multicast configuration request can be inserted in the additional field.

[0286] On-demand SIB may be employed and may take various forms according to the UE (601) requirements listed herein.

[0287] The message at 1113 is provided by the network 602, 603, It may be sent by an RRC message such as an RRCResume response, an RRCRelease message with SuspendConfig, or an RRCReconfiguration message. A dedicated SIB may be capable of carrying the network response. Other container types not mentioned herein may also be used.

[0288] An additional field carried in the message of 1113 may include multicast configuration information for receiving in the RRC_INACTIVE state in response to the multicast configuration request in 1109. It may include a rejection of the configuration request.

[0289] Various container types, including RRC or SIB messages, may be exchanged in the context of the RRC_INACTIVE state without the necessary transition to the RRC_CONNECTED state. Additional field types may specify the cause of the message, so that it is processed accordingly while remaining in the RRC_INACTIVE state.

[0290] In another implementation, in response to MBS session activation, the first multicast data arriving at the network from the application server may trigger an MBS activation message sent by the network to notify the UE of the session activation. The UE may apply multicast preconfiguration, resulting in the reception of the multicast data.

[0291] FIG. 12 is a flowchart illustrating the use of multicast pre-configuration information by a UE after a session is activated, according to an embodiment.

[0292] The UE 601 is in an RRC_INACTIVE state 1102. In the following, it is assumed that the UE is pre-configured to receive multicast data in the RRC_INACTIVE state. In response to the MBS session activation in 1104, the multicast data in 1105 triggers an MBS activation message 1202, 1408 to be sent to candidate UEs pre-configured to receive multicast data in the RRC_INACTIVE state. The MBS activation message 1202 may use an RRC container, for example, as a paging message with a paging cause indicating session activation or SIB. The message in 1202 may be associated with a multicast configuration update. Thus, the message in 1202 may include updated multicast configuration for the UE 601 to receive in the RRC_INACTIVE state. The multicast configuration update in 1202 is sent via an RRC message.

[0293] The UE 601 receives the message at 1202 and applies its multicast pre-configuration at 1203 and 1409. If a configuration change is sent by the network, the UE 601 may apply the updated configuration. Thus, the UE receives its first multicast data at 1204 while in RRC_INACTIVE state.

[0294] At multicast session activation 1104, 1310, the gNB may need to pre-configure the UEs and notify them of the multicast session activation, as at 1202 and 1315. It may send the configuration to unconfigured UEs in RRC_INACTIVE state, as at 1317 and 1204. The gNB may need to update or build the configuration, as at 1312, which is described in more detail below with respect to Figure 13. The configuration is then sent to the UEs in RRC_INACTIVE state, as at 1204 in Figure 12 and 1314 in Figure 13.

[0295] The UE 601 may perform an enhanced cell (re)selection at 1201, as shown in this scenario. The enhanced cell (re)selection at 1201 may involve the NG-RAN nodes 602, 900 in a UE context exchange. At 1201, the UE 601 informs the target NG-RAN node 900 of its presence. As detailed above, the target NG-RAN node may exchange UE context with the source NG-RAN node, including, for example, UE capabilities and / or preferences for receiving in the RRC_INACTIVE state. In another example, the UE may inform the target NG-RAN node 900 of its presence and its capabilities and / or preferences without a UE context exchange between the NG-RAN nodes.

[0296] Additionally, the UE 601 may transmit additional information related to the multicast configuration ID and / or G-RNTI to the target gNB 900 during the enhanced cell reselection procedure 1201. The network may then verify the UE authorization for receiving multicast data and / or the UE authorization in the RRC_INACTIVE state.

[0297] If the source NG-RAN node has pre-configured the UE 601 to receive multicast data in RRC_INACTIVE for neighboring cells, the target NG-RAN node is aware of the pre-configuration and does not proceed to pre-configure the UE 601.

[0298] If the UE has to be pre-configured in the target cell, the target NG-RAN node 900 sends its appropriate multicast pre-configuration information at 1201 onwards.

[0299] In response to the MBS session activation at 1104, the multicast data at 1105 issued by the application server 1101 arrives at the (target) NG-RAN node 602 or 900 at 1105. The (target) NG-RAN node then sends an MBS activation notification at 1202 to the UE 601 before redirecting the multicast data at 1105. At 1203, the UE 601 may apply the previously received multicast pre-configuration and may start receiving the multicast data 1204 in the RRC_INACTIVE state.

[0300] Reception of multicast data in RRC_INACTIVE state may offload the gNB (in other words, the gNB has less load to process due to the UE being in RRC_INACTIVE state) and may facilitate additional UEs joining the MBS session. For this reason, according to an embodiment, it is beneficial to consider the following for a multicast session: A UE may remain in RRC_INACTIVE state if: - In MBS session activation, the UE may apply its (pre)configuration and receive data while remaining in RRC_INACTIVE state; - In MBS deactivation, the UE may stop receiving multicast data, but the session may be reactivated and multicast data may be received thereafter.

[0301] When the MBS session is released, the multicast data will not be transmitted by the network, so the UE should return to the RRC_CONNECTED state to release the radio resources used for receiving the multicast data.

[0302] Figure 13 is a flowchart illustrating a process performed by a gNB 110 or 111 according to an embodiment. The process of Figure 13 is applicable to each of the embodiments already described above, for example, the embodiments described in relation to Figures 6 to 12. This implementation may be performed, for example, by the CPU 315 of the base station shown in Figure 3.

[0303] In step 1300, the gNB receives a UE join request 507, 605 as described with reference to Figures 5 and 6 above. Multicast session establishment 523, 606 is triggered by the first join request from the UE. The UE provides PDU session information and the core network provides multicast session information including QoS flow information. Subsequent join requests from the UE to the same multicast session do not trigger a new multicast session establishment 523, 606 procedure, but the core network may update the multicast session QoS requirements, e.g., to manage the load in the system globally.

[0304] Thereafter, in step 1301, the gNB may decide to perform radio resource reservation to reserve resources for transmitting multicast data to UEs belonging to its cell. It is not mandatory to perform resource reservation in this step, since the multicast data is not yet available and will become available in a subsequent session activation step 524. Some gNBs may decide to wait to reserve resources until the multicast data is available in order to keep radio resources available for other applications while the multicast session is inactive. As mentioned above, there is a risk of overloading the gNB if all involved UEs need to be configured with simultaneously allocated radio resources. Another risk is that the resource allocation will fail because another application allocates the resources too early.

[0305] Thus, according to an embodiment, the gNB does not wait for session activation 524 to perform radio resource reservation, but performs resource reservation when the number of involved UEs (e.g., the sum of the two lists "unconfigured_connected_ue" plus "unconfigured_inactive_ue") reaches a configurable threshold "max_number_ue_for_simultaneous_configuration," which represents each gNB's capacity to handle simultaneous configurations of a large group of UEs.

[0306] To manage UE configuration, the gNB maintains in its memory 325 the following set of UE identifier lists per multicast session: - "unconfigured_connected_ue": a UE in RRC_CONNECTED state that has performed a join request; - "unconfigured_inactive_ue": a UE in RRC_INACTIVE state that has performed a join request; - "pre-configured_connected_ue": a UE in RRC_CONNECTED state that has received a pre-configuration information element and has performed a join request; - "pre-configured_inactive_ue": UE in RRC_INACTIVE state that has received a pre-configuration information element and has performed a join request; - "configured_connected_ue": UE in RRC_CONNECTED state that has received a configuration information element and performed a join request; - "configured_inactive_ue": UE in RRC_INACTIVE state that has received a configuration information element and performed a join request.

[0307] The identifier of each UE that has performed a join request is stored in the list "unconfigured_connected_ue".

[0308] When the core network sends updated QoS requirements, the gNB will update its UE list, since all previously pre-configured or configured UEs will need updated configuration information: - All UE identifiers in "pre-configured_connected_ue" and "configured_connected_ue" are removed from the list and added to "unconfigured_connected_ue". - All UE identifiers in "pre-configured_inactive_ue" and "configured_inactive_ue" are removed from the list and added to "unconfigured_inactive_ue".

[0309] From the radio resource reservation, the gNB can construct a multicast pre-configuration information element. The multicast (pre-)configuration information element may consider various information elements, including but not limited to: - a dedicated multicast radio bearer "MRB2" configuration for receiving multicast data with low QoS for candidate UEs or a "MRB1" configuration addressed primarily to UEs in RRC_CONNECTED state with high QoS, - RRC_INACTIVE reception indication, which the gNB indicates to the UE if the UE is able to receive multicast data in the RRC_INACTIVE state. The absence of this indicator means that the UE can receive multicast data by default in the RRC_INACTIVE state. - G-RNTI, which identifies a group of UEs in the same cell that are interested in receiving multicast data; - a multicast preconfiguration ID that refers to the configuration applied to the UE and associated with an MBS session ID (e.g. TMGI); - A discontinuous reception (DRX) configuration used to receive multicast data for the candidate UE; - Neighbor cell multicast configuration to be applied when a candidate UE performs handover or cell reselection; - Cell ID(s) identifying the cell(s) to which the preconfiguration should be applied.

[0310] In step 1302, the gNB sequentially transmits pre-configuration information elements to all UEs in the "unconfigured_connected_ue" list. The multicast pre-configuration information elements may be transmitted in an RRC configuration message (e.g., FIG. 6). The UE identifiers are removed from the "unconfigured_connected_ue" list and added to the "pre-configured_connected_ue" list.

[0311] In step 1303, the gNB sends preconfiguration information elements to the UEs in the RRC_INACTIVE state (e.g., FIG. 9). The gNB sends paging messages 910 to all UEs in the "unconfigured_inactive_ue" list and waits for PRACH procedures 912 from UEs from the list that are still in the gNB's cell (some RRC_INACTIVE UEs may have moved to other cells). Once the PRACH procedures are complete, the gNB receives multicast preconfiguration request messages 913 from the UEs that performed the PRACH procedure. To these UEs, the gNB sends multicast preconfiguration response messages 914 with the multicast preconfiguration information element. In an alternative embodiment (e.g., FIG. 10), the UE applies the enhanced cell reselection process as already described, which includes sending a notification to the base station associated with the new cell, which may include information indicating which MBS sessions the UE is participating in, so that the gNB knows about the RRC_INACTIVE UEs in its cell. These UEs have the most up-to-date system information and paging, PRACH and pre-configuration requests can be skipped.

[0312] The UE identifier is removed from the "unconfigured_inactive_ueE" list and added to the "pre-configured_inactive_ue" list.

[0313] In step 1304, the gNB checks for a request from the source gNB to become the target gNB for handover of the UE. In the handover procedure, the source gNB requests to hand over management of the UE to the target gNB. An example of a handover is shown in Figure 7. The target gNB knows whether the UE joined a multicast session earlier; this information is part of the handover information provided by the source gNB.

[0314] In step 1305, the target gNB checks whether it has already reserved radio resources for the multicast session. If not, the multicast preconfiguration information element is not ready and the UE identifier corresponding to the handed over UE is added to the "unconfigured_connected_ue" list.

[0315] If a multicast preconfiguration information element is available, during step 1306, the target gNB sends the multicast preconfiguration information element to the handed over UE in message 708. For example, message 708 may be sent to UE 601 in one or more RRC messages, such as an RRCReconfiguration message or a dedicated system information block (SIB).

[0316] During step 1307, the gNB may decide to switch some UEs from RRC_CONNECTED state to RRC_INACTIVE state, with the purpose of reducing the load on the gNB as described in RP-213568. This is an example implementation for the embodiment described in FIG. 8.

[0317] During step 1308, the gNB checks whether it has already reserved radio resources for the multicast session. If not, the multicast preconfiguration information element is not ready and the UE identifiers corresponding to the UEs that are changing their RRC state and that have participated in the multicast session are removed from the "unconfigured_connected_ue" list and added to "unconfigured_inactive_ue".

[0318] If a multicast preconfiguration information element is available, during step 1309 the gNB sends the multicast preconfiguration information element to the UE in an RRCRelease with SuspendConfig message 807. For this, the NG-RAN node 602 may use the RRCRelease with SuspendConfig message 807 with modifications to its content. An additional field related to the multicast preconfiguration context (information element) may be included so that the candidate UE 601 knows to perform a transition to the RRC_INACTIVE state 808 and then be preconfigured to receive multicast data while in the RRC_INACTIVE state.

[0319] The gNB returns to step 1300 until the multicast session is activated, then proceeds to step 1310.

[0320] During step 1310, the gNB receives multicast session activation information 512.

[0321] Then, during step 1311, the gNB checks whether a multicast preconfiguration information element is ready.

[0322] If a multicast preconfiguration information element is not prepared or if the QoS flow information is updated, the gNB creates or updates a preconfiguration information element in step 1312. The gNB then translates the multicast preconfiguration information element in a multicast configuration information element (as described in TS 38.331).

[0323] Then, during step 1313, the gNB sends a multicast configuration information element to all UEs in the "unconfigured_connected_ue" list, the "pre-configured_connected_ue" list and the "configured_connected_ue" list. Similar to step 1302, the multicast configuration information element is sent in an RRCReconfiguration message. All UE identifiers in "unconfigured_connected_ue" and "pre-configured_connected_ue" are moved to the "configured_connected_ue" list.

[0324] Next, during step 1314 (e.g., FIG. 11), the gNB sends a page message with the paging cause set to "MBS session activation" (as proposed in TR 23.700-47). Subsequently, UEs that are present in the cell, in RRC_INACTIVE state, and that have joined the multicast session update their system information by performing a PRACH procedure, after which the UEs send a multicast MBS configuration request message (MBSConfigurationRequest or MBSConfigurationRequest1). The MBS configuration request message can be a new RRC message, an RRCResumeRequest message, or a System Information Block (SIB) reception request. The multicast MBS configuration request message can 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 whose configuration is being requested. Furthermore, the multicast MBS configuration request message may include UE identification information for identifying the UE 101, such as an IMSI or IMEI, and / or authentication information (ueMAC-I), such as an authentication token for use in authenticating the UE 101. Upon receiving the multicast MBS configuration request message, the gNB sends an MBS configuration message (MBSConfiguration) to the UE, which includes a multicast configuration information element.

[0325] The MBS configuration message is sent to at least one UE by a base station controlling a cell in which the UE is camped (e.g., a source or serving base station) in response to receiving an MBS configuration request message from the at least one UE. The MBS configuration message can be an RRCReconfiguration message, an RRCRelease message with suspend configuration, an RRCResume message, or an SIB message.

[0326] Further details of the Multicast Configuration Request message and the Multicast MBS Configuration message can be found in UK Patent Application No. GB2210307.1 In an alternative embodiment, the UE applies the enhanced cell reselection process as described above, and therefore the gNB knows of RRC_INACTIVE UEs in the cell, these UEs have up-to-date system information, and paging, PRACH, and pre-configuration requests can be skipped.

[0327] Each time the UE sends a Multicast Configuration Request Message, the gNB adds the corresponding UE identifier to the "configured_inactive_ue" list and, if it exists, removes it from the "unconfigured_inactive_ue" and "pre-configured_inactive_ue" lists.

[0328] Returning to step 1311, if a multicast configuration information element is prepared and the QoS flow information has not changed, during step 1315 the gNB sends a paging message with the paging cause set to "apply pre-configuration" to all UE identifiers present in the "pre-configured_connected_ue" and "pre-configured_inactive_ue" lists. Thus, all UEs that previously received the multicast pre-configuration information element apply this configuration and are able to receive multicast data. Afterwards, all UE identifiers are removed from "pre-configured_connected_ue" and added to "configured_connected_ue". Similarly, all UE identifiers are removed from "pre-configured_inactive_ue" and added to "configured_inactive_ue".

[0329] The gNB then configures the UEs that remained unconfigured as reflected in "unconfigured_inactive_ue" and "unconfigured_connected_ue". The gNB converts the multicast pre-configuration information element into a multicast configuration information element.

[0330] During step 1316, the gNB sends a multicast configuration information element to all UEs in "unconfigured_connected_ue". Similar to step 1302, the multicast configuration information element is sent in an RRCReconfiguration message. All UE identifiers in "unconfigured_connected_ue" are moved to the "configured_connected_ue" list.

[0331] Next, during step 1317, the gNB sends a page message with the paging cause set to "MBS session activation" (as proposed in TR 23.700-47). UEs that are in the cell, in RRC_INACTIVE state, joined the multicast session, and do not have a preconfigured information element then update their system information by performing a PRACH procedure, after which the UEs send a multicast configuration request message (MBSConfigurationRequest or MBSConfigurationRequest1) and the gNB sends an MBS configuration message (MBSConfiguration) with the multicast configuration information element. Further details of the multicast configuration request message and the MBS configuration message can be found herein and in UK Patent Application No. GB 2210307.1. In an alternative embodiment, the UE applies a cell reselection process that conforms to the enhanced cell reselection process already described above, and therefore the gNB knows about RRC_INACTIVE UEs in the cell, these UEs have up-to-date system information, and paging, PRACH and pre-configuration requests can be skipped.

[0332] Each time the UE sends a Multicast Configuration Request Message, the gNB adds the corresponding UE identifier to the "configured_inactive_ue" list and removes it from the "unconfigured_inactive_ue" list, if it exists.

[0333] Once the multicast session is activated, the gNB operates as described in TS 23.247.

[0334] Figure 14 is a flowchart illustrating the operation of UE 101 according to one embodiment. As with Figure 13, the process illustrated in the flowchart of Figure 14 is applicable to each of the embodiments already described above, such as the embodiments described in connection with Figures 6 to 12. This operation may be performed by CPU 215, for example.

[0335] First, in step 1400, the UE is in RRC_CONNECTED state and performs a join procedure 523, 605 to join the multicast session.

[0336] Next, during step 1401, the UE waits for a multicast preconfiguration message (containing multicast preconfiguration information) from the gNB. The multicast preconfiguration message can be sent by the gNB as a modified RRCReconfiguration message in step 1302 (e.g., FIG. 6), or after a handover procedure (e.g., FIG. 7), in step 1306, or as part of a modified RRCRelease message with SuspendConfig in step 1309. If a multicast preconfiguration information element is received, the UE stores it in memory 225.

[0337] If the UE is still in RRC_CONNECTED state, test 1402 indicates that there is no offload.

[0338] If the UE is currently in RRC_INACTIVE state after receiving either a standard RRCRelease message or a modified RRCRelease message, test 1402 indicates offload.

[0339] If the UE is in the RRC_INACTIVE state (1402 indicates yes), during step 1403 the UE waits to receive a multicast preconfiguration message from the gNB. The multicast preconfiguration message may be sent by the gNB in step 1303 (e.g., FIG. 9). In step 1303, the gNB sends a paging message 910 with a multicast preconfiguration cause, after which the UE initiates a PRACH procedure and sends a multicast preconfiguration request message 913 to the gNB. The gNB then sends back a multicast preconfiguration response message 914 with a multicast preconfiguration information element. In an alternative embodiment (e.g., FIG. 10), the UE applies a cell reselection process that conforms to the enhanced cell reselection process already described above; therefore, the gNB knows of RRC_INACTIVE UEs in the cell, these UEs have up-to-date system information, and paging, PRACH, and preconfiguration requests may be skipped.

[0340] If the UE is in RRC_INACTIVE state, it returns to step 1403 until a multicast (MBS) session is activated in step 1404. If a multicast session is activated in 1404, the UE may or may not have a multicast session pre-configuration information element stored in memory 225.

[0341] In step 1405, the UE waits for a page message from the gNB with the paging cause "apply pre-configuration" (step 1315). If a page is received during test 1406, the UE checks whether it has obtained a multicast pre-configuration information element stored in memory 225. If yes, during step 1407 the UE applies the relevant configuration from the pre-configuration information and is now able to receive multicast data.

[0342] If the UE does not have a saved pre-configuration, return to step 1405.

[0343] Returning to step 1405, if the received page message does not contain the "apply pre-configuration" paging cause, during test 1408 the UE checks for the "MBS session activation" paging cause.

[0344] If the "MBS session activation" paging cause is not included in the page message, the UE returns to step 1405 and waits for a new page message.

[0345] If the "MBS session activation" paging cause is included, during step 1409 the UE will request a multicast configuration information element from the gNB, even if it already has a stored pre-configuration (the configuration has been updated on the gNB side, making the UE's stored pre-configuration obsolete).

[0346] The gNB sends an "MBS session activation" paging cause in step 1314 or 1317 (corresponding to FIG. 11), where the gNB sends a page message with the paging cause set to "MBS session activation" (as proposed in TR 23.700-47). The UE then updates its system information by performing a PRACH procedure, whereupon the UE sends a multicast configuration request message (MBSConfigurationRequest or MBSConfigurationRequest1), and the gNB sends an MBS configuration message (MBSConfiguration) with a multicast configuration information element. Further details of the multicast configuration request message and the MBS configuration message can be found herein and in UK Patent Application No. GB 2210307.1. In an alternative embodiment, the UE's application of the cell reselection process conforms to the enhanced cell reselection process already described above; therefore, the gNB knows of RRC_INACTIVE UEs in the cell; these UEs have up-to-date system information; and paging, PRACH, and pre-configuration requests can be skipped.

[0347] Upon receiving the MBS configuration message, the UE applies the configuration and is ready to receive multicast data.

[0348] This ends the RRC_INACTIVE portion. When we return to the RRC_CONNECTED portion (the condition tested in 1402 is "no"),

[0349] If the UE is in RRC_CONNECTED state, return to step 1401 until the MBS session is activated in step 1410. If the multicast session is activated in 1410, the UE may or may not have a multicast session pre-configuration information element stored in memory 225.

[0350] In step 1411, the UE waits for a page message from the gNB with the paging cause "apply pre-configuration" (step 1315). If a page is received during test 1412, the UE checks whether it has got a multicast pre-configuration information element stored in memory 225. If yes, during step 1413 the UE applies the relevant configuration from the pre-configuration information and is now able to receive multicast data.

[0351] If the UE does not have a saved pre-configuration, return to 1411.

[0352] If the received page does not contain the "apply pre-configuration" paging cause in 1411, then during test 1414 the UE checks for the reception of a standard RRCReconfiguration message from the gNB.

[0353] If an RRCReconfiguration message is not received, the UE returns to step 1411 and waits for a new paging or RRC message.

[0354] If an RRCReconfiguration message is received, during step 1415 the UE applies the configuration as received, even if it already has a stored pre-configuration (the configuration has been updated on the gNB side, making the UE's stored pre-configuration obsolete).

[0355] In step 1316 or 1313, the gNB sends an RRCReconfiguration message.

[0356] An update configuration procedure according to an embodiment of the present invention will now be described with reference to Figures 17 and 18. Figure 17 is a flow chart illustrating a network initiated configuration update for a UE in RRC_INACTIVE state according to an embodiment.

[0357] FIG. 17 shows a UE 601 that joined a multicast MBS session in 605 while in RRC_CONNECTED state 604 (as shown in FIG. 6) and is switched to RRC_INACTIVE state by the network in step 1701.

[0358] The UE 601 searches for the best cell on which to camp by continuously performing a cell reselection process 1702. Because the UE is in RRC_INACTIVE state, it may be switching cells multiple times while moving. Note that the cell reselection processes 1702, 1802 represent optional steps in the methods shown in Figures 17 and 18, as indicated by the dashed outlines. In each of these methods, the cell reselection step may be replaced by a configuration update of the base station (e.g., NG-RAN node 1700), which may be caused, for example, by resetting the base station following a detected failure.

[0359] At the same time, a multicast MBS session is activated and the NG-RAN node 1700 is transmitting multicast data 1704 in the cell in which the UE 601 is currently camped. It is assumed that the UE 601 has obtained multicast configuration to be able to receive multicast data in this cell, for example, before MBS session activation using the method of Figure 9 or according to any of the other preceding embodiments in which (pre-)configuration information is received before MBS session activation. Alternatively, the initial configuration information obtained by the UE 601 may have been received after MBS session activation (for example, using the method of Figures 5a and 5b). The NG-RAN node 1700 controlling the cell in which the UE 601 is camped may not be aware of the presence of the UE 601 in the cell controlled by the NG-RAN node 1700.

[0360] When the NG-RAN node 1700 detects that a multicast configuration modification is necessary to receive multicast data in the cell(s) it controls in the MBS service area, or when the NG-RAN node 1700 is notified of a multicast configuration modification in the cell(s) controlled by another NG-RAN node, the NG-RAN node 1700 may initiate a multicast configuration update for UEs interested in receiving the corresponding MBS session. For UEs in RRC_CONNECTED state, the NG-RAN 1700 uses an RRCReconfiguration message to provide the update. For UEs in RRC_INACTIVE state, the NG-RAN node 1700 may first send a notification 1705 in the cell(s) it controls in the MBS service area. This notification may be a group paging message indicating the multicast session id and indicating that the purpose is the availability of the multicast configuration(s).

[0361] Upon receiving the notification 1705, the UE 601 processes the provided information in step 1703. If the multicast session ID corresponds to a session in which the UE 601 is interested, the UE 601 performs a PRACH exchange procedure 1706 with the NG-RAN node 1700. In 1706, the UE 601 conveys its UE identification information to the NG-RAN node and requests uplink radio resources for L2 / L3 messages and RRC connection messages. The UE 601 then sends a multicast configuration request message 1707 to the NG-RAN node 1700. The message 1707 may be an RRC Resume Request (as specified in TS 38.331) that includes the multicast session ID and indicates a request for reception of multicast configuration(s). The message further includes the identity of the UE in RRC_INACTIVE state (ie, I-RNTI) and the identity of the NG-RAN node that set the UE 601 to RRC_INACTIVE state and assigned the I-RNTI to the UE 601.

[0362] The NG-RAN node 1700 verifies that the UE has joined the MBS session and is authorized to receive the associated multicast data. For this, the NG-RAN node 1700 retrieves the context of the UE 601 by performing a UE context exchange procedure 1711 with the NG-RAN, which sets the UE 601 to an RRC_INACTIVE state. The NG-RAN node 1700 then verifies that the UE 601 is authorized to receive multicast data according to the received UE context by performing an admission control step 1712. If the UE 601 request is accepted, the NG-RAN node sends the multicast configuration(s) to the UE 601 in message 1708. The target NG-RAN node may reject the request while indicating the cause of the rejection.

[0363] The multicast configuration message 1708 may be an RRC Release message with SuspendConfig (as specified in TS 38.331) and includes one or more multicast configurations to be used in one or more neighboring cells. The multicast configurations may be identified by a multicast configuration ID. A mapping between the multicast configuration ID and the cell identities to which the multicast configurations may apply must be provided to the UE.

[0364] To avoid steps 1711 and 1712, the UE may include the G-RNTI being used to decode the received multicast data in the request message 1707. By providing this G-RNTI, the NG-RAN node 1700 can assess that the UE 601 is an authorized UE and the NG-RAN 1700 can provide the multicast configuration.

[0365] During all the procedures described in FIG. 17, the UE 601 may remain in the RRC_INACTIVE state and may continue to receive multicast data.

[0366] FIG. 18 is a flowchart illustrating transmission of a setting configuration requested by a UE in an RRC_INACTIVE state, according to an embodiment.

[0367] FIG. 18 shows a UE 601 that joined a multicast MBS session in 605 while in RRC_CONNECTED state 604 and is switched to RRC_INACTIVE state by the network in step 1801 .

[0368] The UE 601 searches for the best cell to camp on by continuously performing a cell reselection process 1802. Since the UE is in RRC_INACTIVE state, it may be switching cells multiple times while moving.

[0369] At the same time, a multicast MBS session is activated and the NG-RAN node 1800 is transmitting multicast data 1804 in the cell in which the UE 601 is currently camped. It is assumed that the UE 601 has acquired multicast configuration to be able to receive multicast data in this cell, for example, prior to MBS session activation using the method of Figure 9 or according to any of the other previous embodiments in which (pre-)configuration information is received before MBS session activation. The NG-RAN node 1800 controlling the cell in which the UE 601 is camped may not be aware of the presence of the UE 601 in the cell controlled by the NG-RAN node 1800.

[0370] When performing the cell reselection process 1802, the UE 601 may detect one or more cells within the MBS service area for which the UE 601 does not have a multicast configuration for receiving multicast data in the RRC_INACTIVE state.

[0371] The UE 601 may then request the missing multicast configuration(s) from the NG-RAN node 1800. To this end, the UE 601 performs a PRACH exchange procedure 1806 with the NG-RAN node 1800. In 1806, the UE 601 conveys its UE identity to the NG-RAN node and requests uplink radio resources for L2 / L3 messages and RRC connection messages. The UE 601 then sends a multicast configuration request message 1807 to the NG-RAN node 1800. The message 1807 may be an RRC resume request (as specified in TS 38.331) that includes a multicast session ID, indicates a request for receiving the multicast configuration(s), and indicates the identity of the cell for which the multicast configuration(s) is requested. The message further includes the identity of the UE in RRC_INACTIVE state (ie, I-RNTI) and the identity of the NG-RAN node that set the UE 601 to RRC_INACTIVE state and assigned the I-RNTI to the UE 601.

[0372] The NG-RAN node 1800 verifies that the UE has joined the MBS session and is authorized to receive the associated multicast data. For this, the NG-RAN node 1800 retrieves the context of the UE 601 by performing a UE context exchange procedure 1811 with the NG-RAN, which sets the UE 601 to an RRC_INACTIVE state. The NG-RAN node 1800 then verifies that the UE 601 is authorized to receive multicast data according to the received UE context by performing an admission control step 1812. If the UE 601 request is accepted, the NG-RAN node sends the requested multicast configuration(s) to the UE 601 in message 1808. The target NG-RAN node may reject the request while indicating the cause of the rejection.

[0373] If the NG-RAN node 1800 does not have multicast configuration, it may request multicast configuration from the NG-RAN node(s) controlling the cell for which the UE 601 has requested multicast configuration. Such information may be exchanged through Xn protocol messages.

[0374] The multicast configuration message 1808 may be an RRC release message with SuspendConfig (as specified in TS 38.331) containing the requested multicast configuration(s) for multicast configurations known at least in the NG-RAN node 1800.

[0375] To avoid steps 1811 and 1812, the UE 601 may include the G-RNTI being used to decode the received multicast data in the request message 1807. By providing this G-RNTI, the NG-RAN node 1800 can assess that the UE 601 is an authorized UE and the NG-RAN 1800 can provide the multicast configuration.

[0376] During all the procedures described in FIG. 18, the UE 601 may remain in the RRC_INACTIVE state and may continue to receive multicast data.

[0377] 19 and 20, exemplary methods of controlling a UE (e.g., 601) and / or a base station (e.g., NG-RAN 1700, 1800) of a wireless network (e.g., following the configuration procedure updates shown in FIGS. 17 and 18) are described. FIG. 19 shows a flowchart 1900 performed in a UE, and FIG. 20 shows a flowchart 2000 having steps performed in a base station, in accordance with an embodiment of the present invention. For each of the methods shown in FIGS. 19 and 20, the UE has previously received (initial or old) multicast data corresponding to an activated multicast session, but subsequent changes to the network mean that a modification of the UE's (e.g., initial or previous) multicast configuration (e.g., based on multicast configuration information previously obtained by the UE) is required. The initial multicast configuration may be obtained before session establishment while the UE is in RRC_CONNECTED state (as shown in FIGS. 6 and 7) or while the UE is in RRC_INACTIVE state (as shown in FIGS. 8 and 9). Alternatively, the previous configuration may be obtained after session establishment while the UE is in RRC_INACTIVE (as shown in Figures 10a, 10b and 11).

[0378] In step 1901, the UE is in an unconnected RRC (e.g., RRC_INACTIVE) state and transmits a request for (updated or new) multicast configuration information for an activated multicast session to the base station. In step 2001, the base station receives a request for (updated or new) multicast configuration information from the UE in the unconnected RRC state (e.g., as shown in steps 1707 and 1807 of Figures 17 and 18). In step 2202, the base station transmits the (updated or new) multicast configuration information received by the UE in step 1902 (e.g., as shown in steps 1708 and 1808 of Figures 17 and 18). In step 1903, the UE is configured according to the (updated) multicast configuration information received from the base station. Advantageously, this method provides the UE with updated multicast configuration information (e.g., after a cell reselection procedure), thereby enabling the UE to continue receiving multicast data from the activated multicast session while remaining in the unconnected RRC state.

[0379] The following provides details of an exemplary procedure for configuring a UE for multicast reception, with reference to the sections of TS 38.331 version 17.0.0: MBSPreConfiguration corresponds to the multicast (MBS) preconfiguration information mentioned above.

[0380] The purpose of this procedure is to enable pre-configuration data to be sent to the UE prior to session activation, after which the pre-configuration data can be used to configure the UE to receive multicast data from base stations in the network. In the following, the pre-configuration, multicast reception procedure, and multicast reception request procedure will be described and will have definitive numbering later, as they will be referenced by the number 5.3.X, respectively. The implementation of the MBSConfigurationRequest, MBSConfigurationRequest1, and MBSConfiguration request messages referenced in the above specific embodiments will be described in detail below.

[0381] 5.3.2.3 Reception of Paging Message by UE 1> For each TMGI included in the pagingGroupList included in the paging message: 2> If the UE participates in an MBS session indicated by a TMGI included in the pagingGroupList: 3> Forward TMGI to upper layer; 1> In RRC_INACTIVE, if the UE is participating in one or more MBS sessions indicated by TMGIs included in the pagingGroupList; and 1> When included in a Paging message, if none of the ue-Identities included in any of the PagingRecords matches the UE Identity assigned by higher layers: 2> If MBS session activation (MBS_session activation) is included in the paging cause 3> Initiate an RRC_INACTIVE multicast reception procedure in accordance with 5.3.X (e.g., as described with reference to Figures 6 to 10 and / or as described below in the description of an exemplary procedure for configuring a UE for multicast reception with reference to sections or clauses of TS 38.331 version 17.0.0) 2> Otherwise, initiate the RRC connection resume procedure according to 5.3.13 with resumeCause set as follows: 3> If Access Identity 1 is configured in the UE by higher layers: 4> resumeCause is set to mps-PriorityAccess; 3> Otherwise, if Access Identity 2 is configured in the UE by higher layers: 4> resumeCause is set to mcs-PriorityAccess; 3> Otherwise, if one or more access identities equal to 11 to 15 are configured in the UE by higher layers: 4> resumeCause is set to highPriorityAccess; 3> In other cases: 4> resumeCause is set to mt-Access. 2> If multicast pre-configuration is included in the paging cause 2> Initiate RRC_INACTIVE preconfiguration request 2> Otherwise, initiate the RRC connection resume procedure according to 5.3.13 with resumeCause set as follows: 3> If Access Identity 1 is configured in the UE by higher layers: 4> resumeCause is set to mps-PriorityAccess; 3> Otherwise, if Access Identity 2 is configured in the UE by higher layers: 4> resumeCause is set to mcs-PriorityAccess; 3> Otherwise, if one or more access identities equal to 11 to 15 are configured in the UE by higher layers: 4> resumeCause is set to highPriorityAccess; 3> In other cases: 4> resumeCause is set to mt-Access.

[0382] 5.3.X Multicast Preconfiguration Request Procedure 5.3.X.1 general Figure 5.3.X.1-1 Multicast Preconfiguration Request The purpose of this procedure is to set up multicast reception in RRC_INACTIVE state, including one or more multicast MRBs. 5.3.X.2 start The UE initiates this procedure when higher layers or the AS (in response to RAN paging) request multicast reception in RRC_INNACTIVE state. The UE shall ensure that it has valid and up-to-date essential system information as specified in subclause 5.2.2.2 before initiating this procedure. Upon initiation of this procedure, the UE shall: 1> If the RRC connection resumption is triggered by a response to NG-RAN paging: 2> Select "0" as Access Category; 2> Execute the integrated access control procedure specified in 5.3.14 using the selected access category and one or more access identities provided by the higher layer; 3> If the access attempt is prohibited, the procedure ends; 5.3.X.3 Actions related to sending an MBSPreConfigRequest or MBSPreConfigRequest1 message The UE shall configure the contents of the MBSPreConfigRequest message. 5.3.X.4 Reception of MBSPreConfiguration by the UE The UE shall: 1> If RRCResume contains radioBearerConfig: 2> Perform radio bearer setup according to 5.3.5.6;

[0383] 6.2.2 Message definition - MBSPreConfigRequest The MBSPreConfigRequest message is used to request pre-configuration for multicast reception in the RRC_INACTIVE state. Signaling Radio Bearer: SRB0 RLC-SAP: TM Logical Channel: CCCH Direction: UE to network TIFF2025525299000002.tif117154TIFF2025525299000003.tif73154

[0384] - MBSPreConfiguration The MBSPreConfiguration message is used to set up multicast reception in the RRC_INACTIVE state. Signaling Radio Bearer: SRB1 RLC-SAP: AM Logical channel: DCCH Direction: Network to UE TIFF2025525299000004.tif215149TIFF2025525299000005.tif94154

[0385] TIFF2025525299000006.tif96154TIFF2025525299000007.tif99154

[0386] 5.3.X Multicast Reception Procedures 5.3.X.1 General Figure 5.3.X.1-1 Multicast reception request The purpose of this procedure is to set up multicast reception in RRC_INACTIVE state, including one or more multicast MRBs. 5.3.X.2 Start The UE initiates this procedure when higher layers or the AS (in response to RAN paging) request multicast reception in RRC_INNACTIVE state. The UE shall ensure that it has valid and up-to-date essential system information as specified in subclause 5.2.2.2 before initiating this procedure. Upon initiation of this procedure, the UE shall: 1> If the RRC connection resumption is triggered by a response to NG-RAN paging: 2> Select "0" as Access Category; 2> Execute the integrated access control procedure specified in 5.3.14 using the selected access category and one or more access identities provided by the higher layer; 3> If the access attempt is prohibited, the procedure ends;

[0387] Actions related to sending an MBSConfigRequest or MBSConfigRequest1 message The UE sets 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 stored fullI-RNTI value; 1> In other cases: 2> Select MBSConfigRequest as the message to use; 2> Set ueIdentity to the stored shortI-RNTI value; 1> Reconstruct the PDCP entity for SRB1; 1>Resume SRB1; 1> Present the selected message MBSConfigRequest or MBSConfigRequest1 to the lower layer for transmission.

[0388] Reception of MBSConfiguration by UE The UE shall: 1> If RRCResume contains radioBearerConfig: 2> Perform radio bearer setup according to 5.3.5.6;

[0389] Message definition - MBSConfigRequest The MBSConfigRequest message is used to request configuration for multicast reception in the RRC_INACTIVE state. Signaling Radio Bearer: SRB0 RLC-SAP: TM Logical Channel: CCCH Direction: UE to network TIFF2025525299000008.tif98154TIFF2025525299000009.tif51154

[0390] - MBSConfigurationRequest1 The MBSConfigurationRequest1 message is used to request configuration for multicast reception in the RRC_INACTIVE state. Signaling Radio Bearer: SRB0 RLC-SAP: TM Logical channel: CCCH1 Direction: UE to network TIFF2025525299000010.tif95154TIFF2025525299000011.tif59154

[0391] - 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: Network to UE TIFF2025525299000012.tif133154

[0392] 5.3.X Multicast Reception Request Procedure 5.3.X.1 general Figure 5.3.X.1-1 Multicast reception request The purpose of this procedure is to set up a multicast reception request in the RRC_INACTIVE state, including one or more multicast MRBs. 5.3.X.2 start The UE initiates this procedure when higher layers or the AS (when responding to RAN paging) requests multicast reception in RRC_INNACTIVE state. The UE shall ensure that it has valid and up-to-date essential system information as specified in subclause 5.2.2.2 before initiating this procedure. Upon initiation of this procedure, the UE shall: 1> If the RRC connection resumption is triggered by a response to NG-RAN paging: 2> Select "0" as the access category; 2> Execute the integrated access control procedure specified in 5.3.14 using the selected access category and one or more access identities provided by the higher layer; 3> If the access attempt is prohibited, the procedure ends;

[0393] MBSReceptionRequest The MBSReceptionRequest message is used to request reception of multicast data in the RRC_INACTIVE state. Signaling Radio Bearer: SRB0 RLC-SAP: TM Logical Channel: CCCH Direction: UE to network TIFF2025525299000013.tif159154

[0394] The present invention provides multicast pre-configuration information for a multicast session according to several aspects described below.

[0395] In Release 17, MBS multicast sessions follow the state transitions specified in 3GPP TS 23.247 v17.3.0, Figure 4.3-1. Session management procedures include session creation (TS 23.247, 7.1.1.2 or 7.1.1.3), session activation (TS 23.247, 7.2.5.2), and session establishment and joining (TS 23.247, 7.2.1.3). Only when an MBS session is established does the network configure the UE to receive multicast data.

[0396] Establishment of an MBS session in a UE is performed when the UE is in the RRC_CONNECTED state. The network may then decide to switch the UE to the RRC_INACTIVE state before MBS multicast data becomes available through session activation. When a session is activated, the network must notify the UEs that have joined the session, and the network must switch the UEs in the RRC_INACTIVE state to the RRC_CONNECTED state and configure them.

[0397] First, the Release 17 specification does not provide a procedure for placing a UE in the RRC_INACTIVE state. A UE in the RRC_INACTIVE state will resume to the RRC_CONNECTED state once an MBS session is activated.

[0398] Based on Release 17, in an MBS session activation, all UEs belonging to a multicast group will be configured simultaneously.

[0399] Second, for a large number of UEs, distribution of MBS configurations in MBS multicast session activation may lead to link congestion and delays.

[0400] MBS Pre-settings In order to avoid large-scale MBS configuration in MBS session activation, it is proposed to pre-configure the UE before MBS session activation.

[0401] The MBS configuration can be distributed in different stages: - If the UE is in RRC_CONNECTED state, at (or after) MBS session establishment, - When the UE is switched to the RRC_INACTIVE state to provide PTM configuration for receiving multicast data in the RRC_INACTIVE state, - If the UE is already in RRC_INACTIVE state, e.g. due to a PTM configuration update.

[0402] Then, upon MBS multicast session activation, the UE is notified by the network and can apply the stored MBS configuration to start receiving multicast data.

[0403] The network load may be reduced during MBS session activation by pre-configuring the UE at different times (before session activation).

[0404] Before MBS session activation for a UE capable of receiving MBS multicast data in RRC_INACTIVE state, the network preferably provides MBS multicast configurations to the UEs in the multicast group, and the network may provide PTM configurations for some cells (e.g., neighboring cells) or all cells in the MBS service area. An advantage of a UE in RRC_INACTIVE state receiving MBS multicast data is that it can switch to a new cell without notifying the network to request configurations. After performing a cell reselection process and switching to the new cell, the UE can apply the stored PTM configurations corresponding to the new cell.

[0405] It is proposed that if the UE is able to receive MBS multicast data in RRC_INACTIVE state, the network may provide the UE with (one or more) PTM configurations for some neighboring cells.

[0406] MBS Session Activation Notification In MBS session activation, the network may perform group paging to announce the activation of the MBS multicast session. A UE in a preconfigured RRC_INACTIVE state may directly apply the saved PTM configuration without notifying the network.

[0407] However, the UE may signal to the network to indicate its presence. To this end, the UE may send an RRC Resume Request message, and the network may respond with an RRC Release message with suspendConfig to keep the UE in RRC_INACTIVE state. Additionally, this signaling from the UE allows the gNB to estimate the number of UEs effectively receiving in RRC_INACTIVE state.

[0408] As an alternative to group paging, the network may indicate activation for MBS session activation through a SIB.

[0409] A UE in RRC_INACTIVE state may receive notification of an MBS session activation via group paging or SIB.

[0410] It should be noted that whether a multicast session can be received in RRC_INACTIVE state is implicitly indicated to the UE by receiving from the network the PTM configuration applicable in RRC_INACTIVE state. An explicit indication of whether multicast can be received in RRC_INACTIVE state through paging may not be necessary.

[0411] Distribution of PTM settings in RRC_INACTIVE state Two options are possible for distributing the PTM configuration in the RRC_INACTIVE state: using dedicated signaling or based on SIB and MCCH. However, using the MCCH channel to provide the PTM configuration presents some drawbacks related to security (regarding authorization to receive multicast data). Furthermore, the MCCH content may be transmitted periodically and is therefore not efficient in terms of bandwidth.

[0412] It is proposed that the PTM configuration should be provided to the UE in RRC_INACTIVE state via dedicated RRC signaling.

[0413] When the UE switches to the RRC_INACTIVE state, the network may provide the PTM configuration through an RRC release message with SuspendConfig. Such PTM configuration delivery may be performed before (i.e., pre-configuration) or after MBS session activation. This message may include PTM configuration for one or more cells within the MBS service area.

[0414] The process shown in Figure 8 illustrates the PTM configuration distribution when switching to the RRC_INACTIVE state.

[0415] After the MBS session establishment, the gNB may decide to switch the UE to the RRC_INACTIVE state (which may be determined using assistance information from the core network). At this stage, the gNB may decide to pre-configure the UE to be able to receive multicast data while in the RRC_INACTIVE state by sending an RRCRelease message with a SuspendConfig containing the appropriate PTM configuration. The UE then knows that it will be able to receive multicast data in the RRC_INACTIVE state.

[0416] Similarly, if the network has to configure a UE that is already in RRC_INACTIVE state, an RRC Release message with SuspendConfig can also be used to provide the PTM configuration(s) while keeping the UE in RRC_INACTIVE state. This is relevant for the following cases: 1) When the configuration is triggered by the UE, for example, in cell reselection when the UE is receiving multicast data and does not have a PTM configuration for the target cell, 2) When the configuration is network driven.

[0417] In the first case (UE-triggered configuration), the UE may send an RRC Resume Request to the network (before or after a cell switch) indicating the need for one or more PTM configurations for a given MBS multicast session. The network may then respond with an RRC Release message with SuspendConfig, which includes the requested PTM configuration(s). In the second case (network-initiated), the network may perform group paging to inform the availability of PTM configurations for the MBS multicast session. UEs interested in the MBS session may then notify their presence and interest in the MBS session by sending an RRC Resume Request message. Finally, the network may send an RRC Release message with SuspendConfig, which includes the PTM configuration(s). This procedure may be performed at any time before or after MBS session activation (e.g., for updating). It may also be performed at MBS session activation, which means that the group paging includes both notification of MBS session activation and notification of PTM configurations.

[0418] As a proposal, the PTM configuration(s) may be provided using an RRC release message with SuspendConfig to a UE that is being switched to or is already in RRC_INACTIVE state.

[0419] In both cases, the network may provide PTM configuration for some cells (eg, neighboring cells) or for all cells within the MBS service area.

[0420] Also, in both cases, the UE may remain in RRC_INACTIVE state (without switching to RRC_CONNECTED state).

[0421] It is proposed that a UE in RRC_INACTIVE state may receive PTM configuration(s) without being switched to RRC_CONNECTED state.

[0422] Before sending the PTM configuration(s) to the UE, the network should check that the UE belongs to the multicast group (i.e., it is participating in the MBS session and is authorized to receive multicast data).

[0423] As an alternative to group paging, the network may indicate activation for MBS session activation through a SIB.

[0424] It is proposed that group paging or SIBs may be used to inform UEs in RRC_INACTIVE state about the availability of one or more PTM configurations.

Claims

1. 1. A method in a user equipment (UE) of a wireless communication system, the method comprising: For a multicast session in which the UE has requested to join, receiving multicast pre-configuration information for the multicast session; configuring the UE to receive multicast data via the multicast session according to the multicast pre-configuration information; A method comprising:

2. 10. The method of claim 1, The method further includes sending a request to join the multicast session to a core network via the base station.

3. 3. The method of claim 1 or 2, The method, wherein the multicast pre-configuration information is received from a base station.

4. 4. The method according to any one of claims 1 to 3, The method, wherein the multicast pre-configuration information is included in at least one of a radio resource control (RRC) message, a system information block (SIB), and an MBS control channel (MCCH) message.

5. 5. The method according to any one of claims 1 to 4, The preset information is Radio bearer configuration information associated with low quality of service (QoS) transmissions; Radio bearer configuration information associated with high quality of service (QoS) transmission; an inactive reception indicator that informs the UE whether it is able to receive multicast data in a disconnected RRC state; Information identifying a group of UEs in the same cell that are interested in receiving multicast data; a multicast preconfiguration ID that identifies the configuration applied by the UE and associated with the multicast session ID; Discontinuous reception (DRX) setting information, Neighbor cell multicast configuration information, and cell identification information for identifying one or more cells to which the preconfiguration should be applied; The method includes at least one of:

6. 6. The method according to any one of claims 1 to 5, the multicast pre-configuration information includes an update to existing configuration information for receiving multicast data via the multicast session; The method, wherein the configuring includes updating the configuration of the UE to receive the multicast data over the multicast session using the pre-configuration information.

7. 7. The method according to any one of claims 1 to 6, The method further includes receiving data for the multicast session after performing the configuration according to the multicast pre-configuration information.

8. 8. The method according to any one of claims 1 to 7, The method, wherein the multicast pre-configuration information is received prior to activation of the multicast session.

9. 9. The method of claim 8, The method, wherein the multicast pre-configuration information is received during or after establishment of the multicast session.

10. 10. The method of claim 8 or 9, The method further includes, after receiving the multicast pre-configuration information, receiving a notification of activation of the multicast session.

11. 11. The method of claim 10, The method, wherein the UE is configured according to the multicast pre-configuration information in response to receiving the notification.

12. 12. The method of claim 10 or 11, The method, wherein the notification of activation is one of a paging message, an RRC message, a system information block (SIB), and an MBS control channel (MCCH) message.

13. 13. The method of any one of claims 9 to 12, comprising: The UE is operating in a Disconnected RRC state when it receives notification of activation of the multicast session, and the notification of activation is received after a cell reselection process that causes the UE to camp on a base station.

14. 14. The method of claim 13, The method further comprises transmitting a request for multicast reception and / or multicast feedback information after receiving multicast data, and receiving further multicast configuration data at the UE in response.

15. 14. The method of claim 13, The method, wherein the cell reselection process includes transmitting information from the UE to a base station indicating multicast session identification information for one or more multicast sessions in which the UE has joined.

16. 8. The method according to any one of claims 1 to 7, The method, wherein the multicast pre-configuration information is received after activation of the multicast session.

17. 17. The method of any one of claims 1 to 16, The method, wherein the multicast pre-configuration information is received in a message for placing the UE in an unconnected RRC state.

18. 18. The method of claim 17, The method, wherein the multicast pre-configuration information is received in an RRC release message.

19. 17. The method of any one of claims 1 to 9 and 16, The method, wherein the multicast pre-configuration information is received while the UE is operating in a Disconnected RRC state.

20. 20. The method of claim 19, The method, wherein the multicast pre-configuration information is received after a cell reselection process that causes the UE to camp on a base station.

21. 21. The method of claim 20, receiving, after the cell reselection process, a notification indicating that a multicast pre-configuration is available for the multicast session; and the UE sending a multicast pre-configuration request to the base station; wherein the multicast pre-configuration information is received from the base station in response to the transmitted request.

22. 22. The method of claim 21, The method of claim 1, wherein the multicast preconfiguration request is sent after performing a Physical Random Access Channel (PRACH) procedure with the base station in response to the indication that the multicast preconfiguration information is available.

23. 21. The method of claim 20, The method, wherein the cell reselection process includes transmitting information from the UE to a base station if a new cell is selected as a result of the cell reselection process.

24. 24. The method of claim 23, A method comprising: transmitting a target base station identifier to the base station, the target base station identifier identifying a target base station associated with the new cell.

25. 24. The method of claim 23, transmitting, to a target base station associated with the new cell, multicast session identification information for identifying one or more multicast sessions in which the UE has joined.

26. 26. The method of any one of claims 20 to 25, While the UE is operating in a Disconnected RRC state, receiving, before the cell reselection process, multicast data for an active multicast session according to a configuration for a base station on which the UE is camped before cell reselection; The method, wherein the pre-configuration information is for configuring the UE to receive multicast data from the multicast session from the base station on which the UE is camped after cell reselection.

27. 27. The method of claim 26, The method, wherein the cell reselection process further includes the UE detecting whether the cell is within a multicast service area for which the UE does not have a corresponding multicast configuration.

28. 28. The method of claim 26 or 27, The method, wherein the request for the multicast pre-configuration information includes at least one of G-RNTI information and multicast session identification information, and the G-RNTI information is used by the UE to decode the received multicast data.

29. 1. A method in a base station for controlling a cell serving a user equipment (UE), the method comprising: performing a multicast session establishment requested by the UE; sending multicast pre-configuration information for the multicast session to the UE; A method comprising:

30. 30. The method of claim 29, receiving a request to join the multicast session from the UE; and sending the request to join the multicast session to a core network.

31. 31. The method of claim 29 or 30, The method, wherein the multicast session is established between the UE, the base station, and a core network.

32. 32. The method of any one of claims 29 to 31, comprising: The method, wherein the multicast pre-configuration information is included in at least one of a radio resource control (RRC) message and a system information block (SIB).

33. 33. The method of any one of claims 29 to 32, comprising: The preset information is Radio bearer configuration information dedicated to low quality of service (QoS) transmission; Radio bearer configuration information dedicated to high quality of service (QoS) transmission; an inactive reception indication that informs the UE whether it is able to receive multicast data in a disconnected RRC state; Information identifying a group of UEs in the same cell that are interested in receiving multicast data; a multicast preconfiguration ID that identifies the configuration applied by the UE and associated with the multicast session ID; Discontinuous reception (DRX) setting information, Neighbor cell multicast configuration information, and cell identification information for identifying one or more cells to which the preconfiguration should be applied; The method includes at least one of:

34. 34. The method of any one of claims 29 to 33, comprising: The method, wherein the multicast pre-configuration information includes an update to existing configuration information for receiving multicast data via the multicast session.

35. 35. The method of any one of claims 29 to 34, comprising: The method further includes transmitting data about the multicast session to the UE according to the multicast pre-configuration information.

36. 36. The method of any one of claims 1 to 35, The method, wherein the multicast pre-configuration information is transmitted prior to activation of the multicast session.

37. 37. The method of claim 36, The method, wherein the multicast pre-configuration information is transmitted during or after the establishment of the multicast session.

38. 38. The method of claim 36 or 37, The method further includes sending a notification of the activation of the multicast session to the UE.

39. 39. The method of claim 38, The method, wherein the notification of activation includes at least one of a paging message, an RRC message, and an SIB.

40. 40. The method of claim 38 or 39, The UE is operating in a non-connected RRC state when the notification of activation of the multicast session is sent, and the notification of activation is sent to the UE by the base station after a cell reselection process.

41. 41. The method of claim 40, receiving from the UE a request for multicast reception and / or multicast feedback information after transmission of multicast data to the UE, and in response transmitting further multicast configuration data for the multicast session to the UE.

42. 41. The method of claim 40, The method, wherein the cell reselection process includes transmitting information from the UE to a base station indicating multicast session identification information for one or more multicast sessions in which the UE has joined.

43. 36. The method of any one of claims 29 to 35, comprising: The method, wherein the multicast pre-configuration information is transmitted after the activation of the multicast session.

44. 44. The method of any one of claims 29 to 43, comprising: The method, wherein the multicast pre-configuration information is transmitted to the UE in a message for placing the UE in an unconnected RRC state.

45. 45. The method of claim 44, The method, wherein the multicast pre-configuration information is transmitted in an RRC release message.

46. 44. The method of any one of claims 29 to 35 and 43, comprising: The method, wherein the multicast pre-configuration information is transmitted to the UE when the UE is operating in a Disconnected RRC state.

47. 47. The method of claim 46, The method, wherein the multicast pre-configuration information is transmitted after a cell reselection process that causes the UE to camp on a base station.

48. 48. The method of claim 47, sending a notification after the cell reselection process indicating that the multicast preconfiguration information is available for the multicast session; and receiving a multicast pre-configuration request from the UE, wherein the multicast pre-configuration information is transmitted in response to receiving the request; The method further comprises:

49. 49. The method of claim 48, The method, wherein the multicast pre-configuration request is received after performing a Physical Random Access Channel (PRACH) process with the UE.

50. 48. The method of claim 47, The method, wherein the cell reselection process includes receiving, at a base station, information from the UE if a new cell has been selected as a result of the cell reselection process.

51. 51. The method of claim 50, A method comprising receiving a target base station identifier that identifies a target base station associated with the new cell as a source base station.

52. 52. The method of claim 51 , The method includes receiving multicast session identification information to identify one or more multicast sessions in which the UE has joined as a target base station associated with the new cell.

53. 53. The method of any one of claims 31 to 52, comprising: the UE is in a disconnected RRC state, and the base station controls the cell on which the UE should be camped after a cell reselection process; The method further includes receiving a request from the UE for multicast pre-configuration information corresponding to the base station.

54. 54. The method of claim 53, The method further includes sending a notification to the UE that the multicast pre-configuration information is available.

55. 55. The method of claim 54, The notification is sent when the base station detects that modification of the multicast configuration is necessary for the UE to receive multicast data in the one or more cells controlled by the base station.

56. 55. The method of claim 54, The method of claim 1, wherein the notification is sent when the base station is notified of a modification of the multicast configuration in one or more cells controlled by another base station.

57. 57. The method of any one of claims 53 to 56, comprising: The method further includes checking that the UE has a context that enables reception of multicast data for the multicast session before sending the updated multicast configuration information for the multicast session.

58. 1. A method in a user equipment (UE) of a wireless communication system, the UE being configured to receive multicast data of an activated multicast session, the method comprising: sending a request to a base station for updated multicast configuration information for the activated multicast session; receiving the updated multicast configuration information from the base station; configuring the UE to receive multicast data of the activated multicast session according to the updated multicast configuration information; A method comprising:

59. 59. The method of claim 58, The method includes, in response to determining that a multicast configuration of the UE needs to be modified to receive multicast data for the activated multicast session, sending the request to the base station.

60. 60. The method of claim 58 or 59, The method includes, before sending the request to the base station, the UE determining that updated multicast configuration information is required to receive multicast data of the activated multicast session.

61. 61. The method of any one of claims 58 to 60, comprising: The UE determines that the UE in an unconnected RRC state does not have the updated multicast configuration required to receive multicast data of the activated multicast session.

62. 62. The method of any one of claims 58 to 61, comprising: The method includes sending the request to the base station in response to a configuration update of the base station.

63. 63. The method of any one of claims 58 to 62, comprising: The method includes sending the request to the base station in response to a reselection process to camp the UE on a cell controlled by the base station.

64. 64. The method of any one of claims 58 to 63, comprising: The method further includes receiving, at the UE, a notification that updated multicast configuration information is available, wherein the request for updated multicast configuration information is sent in response to the notification indicating that updated multicast configuration information is available.

65. 65. The method of any one of claims 58 to 64, comprising: The method, wherein the request for updated multicast configuration information is sent by the UE after performing a Physical Random Access Channel (PRACH) procedure with the base station.

66. 66. The method of any one of claims 58 to 65, comprising: and, before sending the request for updated multicast configuration information, the UE obtains multicast configuration information that does not enable the UE to receive multicast data for the activated multicast session.

67. 1. A method in a base station controlling a cell, the base station being configured to serve user equipment (UE) with multicast data of an activated multicast session, the method comprising: receiving a request from the UE for updated multicast configuration information for the activated multicast session; sending updated multicast configuration information for the activated multicast session to the UE; A method comprising:

68. 68. The method of claim 67, The method includes receiving the request from the UE after determining that a multicast configuration of the UE needs to be modified to receive multicast data for the activated multicast session.

69. 69. The method of claim 67 or 68, The method includes, before receiving the request from the UE, the base station determining that the updated multicast configuration information is necessary for the UE to receive multicast data of the activated multicast session.

70. 70. The method of any one of claims 67 to 69, comprising: The base station determines that the UE in a non-connected RRC state does not have the updated multicast configuration required to receive multicast data of the activated multicast session.

71. 71. The method of any one of claims 67 to 70, comprising: The method includes receiving the request from the UE in response to a configuration update of the base station.

72. 72. The method of any one of claims 67 to 71, comprising: The method includes receiving the request from the UE after a reselection process to camp the UE on the cell controlled by the base station.

73. 73. The method of any one of claims 67 to 72, comprising: The method further includes sending a notification to the UE that updated multicast configuration information is available.

74. 74. The method of any one of claims 67 to 73, comprising: The method, wherein the base station performs a Physical Random Access Channel (PRACH) procedure with the UE before receiving the request for updated multicast configuration information from the UE.

75. A device comprising a user equipment configured to perform the method of any one of claims 1 to 28 and 58 to 66.

76. A device comprising a base station configured to perform the method of any one of claims 29 to 57 and 67 to 74.

77. 75. A computer program comprising instructions which, when executed by a computer, cause the computer to carry out the method of any one of claims 1 to 74.

78. 78. A computer readable medium carrying the computer program of claim 77.

Images