MBS multicast configuration

Abstract

The present invention relates to 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, where the multicast pre-configuration information may be received before and / or after activation of the multicast session. The UE is configured to receive multicast data via a multicast session according to multicast (pre) configuration information. Establishment of a multicast session requested by a user equipment (UE) is made at a base station controlling a cell serving the UE.

Description

Technical Field

[0001] The present invention generally relates to providing MBS multicast data reception configuration parameters to a UE (User Equipment), and particularly, but not exclusively, to configuring the UE to receive MBS multicast data when the UE is in any one of RRC_CONNECTED and RRC_INACTIVE states. Background Art

[0002] Wireless communication systems are widely deployed to address a wide range of applications from mobile broadband, massive machine type communications to ultra-reliable low latency communications (URLLC). Such systems allow multiple user equipments (UEs) or mobile terminals to share the wireless medium to exchange 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-RTM) standards (such as the 4th-Generation (4G) Long Term Evolution (LTE) or the more recent 5th-Generation (5G) New Radio (NR) systems), or systems based on the IEEE 802.11 standards (such as Wi-Fi).

[0004] Among the requirements for 5G NR, there are service requirements related to multicast and broadcast services (abbreviated as MBS).

[0005] For broadcast communication services, the same service and the same specific content data are provided to all UEs in a geographic area at the same time (i.e., all UEs in the broadcast service area are authorized to receive data). Broadcast communication services are delivered to UEs using broadcast sessions. For multicast communication services, the same service and the same specific content data are provided to a dedicated set of UEs at the same time (i.e., not all UEs in the multicast service area are authorized to receive data). Multicast communication services are delivered to UEs using multicast sessions.

[0006] Support for multicast / broadcast technology enables the network to operate in a more efficient manner than unicast. Use cases identified that can benefit from this MBS feature include public safety and mission-critical, V2X applications, IPTV, real-time video, software delivery over wireless, and IoT applications. 3GPP began building functional support for MBS in 5G NR from Release 17.

[0007] In 5G NR, the Radio Resource Control (RRC) protocol operates in the control plane between the UE and the base station (gNB), and provides 3 different states for the UE as defined in the 3GPP specification TS 38.331: RRC_CONNECTED, RRC_INACTIVE, and RRC_IDLE states. At power-on, the UE is in the RRC_IDLE state, and the UE changes to the RRC_CONNECTED state when the RRC connection with the gNB is established. If the RRC connection is released, the UE changes back to the RRC_IDLE state. When in the RRC_CONNECTED state, the RRC connection can be suspended by the gNB, and the UE moves to the RRC_INACTIVE state. When the UE is in the RRC_INACTIVE state, the UE cannot communicate with the 5G system, but both the gNB and the UE keep track of the RRC connection context. Therefore, the transition from the RRC_INACTIVE state back to the RRC_CONNECTED state is faster than the RRC connection establishment from the RRC_IDLE to the RRC_CONNECTED state.

[0008] In the case of 3GPP Release 17, the reception of MBS broadcast by the UE is allowed when the UE is in RRC_IDLE, RRC_INACTIVE or RRC_CONNECTED state, and the reception of MBS multicast is allowed only when the UE is in RRC_CONNECTED state. For Release 18, the plan is to allow MBS multicast reception also when the UE is in RRC_INACTIVE state. For example, see 3GPP RP-213568 entitled "New WID: Enhancements of NR Multicast and Broadcast Services" submitted by CATT (title: 3GPP TSG RAN Meeting #94-e, source CATT) (Section 3). The purpose is to enable a large number of UEs to receive multicast data from one cell. In fact, putting the UE in the RRC_INACTIVE state reduces the control plane footprint of the entire UE, thereby allowing the gNB to handle more UEs. In addition, it is not energy-efficient to always keep the UE in the RRC_CONNECTED state. Therefore, the advantages of also supporting multicast for UEs in the RRC_INACTIVE state have been recognized.

[0009] In Release 17, MBS multicast sessions follow 3GPP TS23.247v17.3.0 ( Figure 4.3-1). The 5G nodes involved in MBS session management are described in clause 5.1 “General architecture” of TS 23.247 v17.3.0. In this document, “session” always refers to “MBS session”.

[0010] The session management process includes session creation (7.1.1.2 or 7.1.1.3 of TS23.247), session activation (7.2.5.2 of TS23.247), session establishment and joining (7.2.1.3 of TS23.247).

[0011] At the beginning, the session does not exist. The session is created at the request of the AF (Application Function). As part of the creation process, an MBS session identifier is allocated, a multicast service area is defined, and the session is announced to the UEs in the service area. The multicast service area is defined in 3GPP TS22.146 version 17.0.0, clause 3 "Definitions". A multicast service area is defined for each multicast service. One multicast service can start multiple multicast sessions. The multicast service area can be as large or smaller than the PLMN (Public Land Mobile Network) coverage area.

[0012] Once a session is created, the first UE that sends a join request to that session will trigger session establishment towards the NG-RAN (comprising (one or more than one) gNBs in the multicast service area). Subsequent join requests from other UEs will not trigger session establishment. The session establishment process includes the UE's PDU (Protocol Data Unit) session establishment, the UE's session join request (associating the PDU session to the MBS session), and resource reservation from the core to the NG-RAN for the delivery of MBS data for the first join request.

[0013] In addition, once the session is created, the MB-SMF (MBS Session Management Function) can be triggered to activate the session. The triggering condition reflects the availability of multicast data from the application. The session activation process includes NG-RAN resource reservation.

[0014] The NG-RAN configures the UE to receive multicast data only when both the session is activated and the MBS session is established.

[0015] The initiation of the process of session activation and session establishment answers to different triggers: for session activation the trigger is the availability of multicast data from the application and for session establishment the trigger is the presence of at least one UE in the service area sending a join request to the multicast session.

[0016] The establishment of an MBS session in the UE is performed while the UE is in RRC_CONNECTED state. Possibly, the gNB may then decide to switch the UE to RRC_INACTIVE state before MBS multicast data is available through session activation. As a result, the NG-RAN (at least one gNB) will have to inform and configure UEs that have joined the session but are in RRC_INACTIVE state when the session is activated.

[0017] The current version of the specification does not provide a procedure for notifying or configuring a UE in RRC_INACTIVE state.A UE in RRC_INNACTIVE state should not receive any data from applications and has limited access to the control plane.

[0018] In Release 17, some mechanisms are proposed to handle the case of broadcast reception in RRC_INACTIVE state. Document TS 38.300 Version 17.0.0 states in clause 16.10.6.2 that the gNB uses MCCH (MBS Control Channel) to provide configuration to UEs in any RRC state including the RRC_INACTIVE state. In fact, the MCCH channel is accessible to UEs in the RRC_INACTIVE state and is well suited for sending notifications and configuration parameters. However, the fact that the MCCH is in fact accessible to all UEs without restriction represents a security violation for MBS multicast services, since access to multicast data is subject to prior authorization of each UE during the joining process. Multicast configuration should only be available to UEs that have obtained appropriate authorization during the joining process. In addition, the MCCH content may need to be transmitted periodically and is therefore not efficient in terms of bandwidth.

[0019] As part of the ongoing discussion for Release 18, document S2-2200599 proposes switching the UE back to RRC_CONNECTED state, configuring and switching the UE to RRC_INACTIVE state again. While this solution appears to work, the purpose of offloading the gNB by keeping the UE in RRC_INACTIVE state may not be achieved in cases where the density of UEs is high due to the additional signaling and other resources required to switch to RRC_CONNECTED state to configure the UE and then switch back to RRC_INACTIVE state again.

[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 the multicast session is activated while staying in the RRC_INACTIVE state. Summary of the invention

[0021] According to an aspect of the present invention, multicast pre-configuration information for a multicast session is provided, wherein the multicast pre-configuration information is received before activating the multicast session, and the UE is configured 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 items:

[0023] - radio bearer configuration information associated with low quality of service (QoS) transmission,

[0024] - radio bearer configuration information associated with high Quality of Service (QoS) transmission,

[0025] - Discontinuous reception (DRX) configuration information, and

[0026] -Neighbor cell multicast configuration information.

[0027] Pre-configuration information including radio bearer configuration information associated with low quality of service (QoS) transmission may be used to configure the UE when the UE is operating in a non-connected (RRC) state. Pre-configuration information including radio bearer configuration information associated with high quality of service (QoS) transmission may be used to configure the UE when the UE is in a connected RRC state.

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

[0029] The method may also include receiving data for the multicast session after configuring according to the multicast pre-configuration information.

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

[0031] The multicast preconfiguration information may be received in a message for placing the UE in a non-connected RRC state. The non-connected RRC state may be an RRC_INACTIVE state.

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

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

[0034] The multicast preconfiguration information may be received after a cell reselection process that causes the UE to camp in the base station.

[0035] The method may include:

[0036] After the cell reselection process, receiving a notification indicating that the multicast preconfiguration is available for the multicast session; and

[0037] A multicast pre-configuration request is sent by the UE to the base station, wherein multicast pre-configuration information is received from the base station in response to the sent request.

[0038] The multicast preconfiguration request may be sent after performing a physical random access channel (PRACH) procedure with the base station in response to a notification indicating that multicast preconfiguration information is available.

[0039] The cell reselection process includes sending information from the UE to the base station if a new cell has been 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 being used to identify 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 for identifying one or more multicast sessions joined by the UE.

[0040] The method may also include receiving a notification of activation of the multicast session after receiving the multicast pre-configuration information.

[0041] The UE may be configured according to the multicast pre-configuration information in response to receiving the notification.

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

[0043] When receiving the notification of activation of the multicast session, the UE may operate in a non-connected RRC state, and receive the notification of activation after a cell reselection process that causes the UE to camp in the base station.

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

[0045] The cell reselection process may include: sending information indicating multicast session identification information of a multicast session joined by the UE to the base station.

[0046] According to another aspect of the present invention, a method at a base station that controls a cell serving a user equipment (UE) is provided, the method comprising: establishing a multicast session requested by the UE, and sending multicast pre-configuration information for the multicast session to the UE before activating the multicast session.

[0047] The base station may receive a request from the UE to join the multicast session, and send the request to join the multicast session to the core network. The base station may receive information for establishing the multicast session from the core network. The establishment of the multicast session may be between the UE, the base station, and the core network.

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

[0049] The pre-configuration information may include one or more of the following:

[0050] - Radio bearer configuration information dedicated to low Quality of Service (QoS) transmissions,

[0051] - Radio bearer configuration information dedicated to high Quality of Service (QoS) transmission,

[0052] - Discontinuous Reception (DRX) configuration information, and

[0053] -Neighborhood multicast configuration information.

[0054] Pre-configuration information including radio bearer configuration information associated with low quality of service (QoS) transmission may be used to configure the UE when the UE is operating in a non-connected RRC state. Pre-configuration information including radio bearer configuration information associated with high quality of service (QoS) transmission may be used to configure the UE when the UE is in a connected RRC state.

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

[0056] The method may include sending data for the multicast session to the UE according to the multicast pre-configuration information.

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

[0058] The multicast pre-configuration information may be sent to the UE in a message used to place the UE in a non-connected RRC state.

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

[0060] The multicast pre-configuration information may be sent to the UE when the UE is operating in a non-connected RRC state.

[0061] The multicast preconfiguration information may be sent after a cell reselection process that causes the UE to camp in the base station.

[0062] After the cell reselection process, a notification indicating the multicast preconfiguration may be sent; and a multicast preconfiguration request may be received from the UE, wherein the multicast preconfiguration data is sent in response to receiving the request.

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

[0064] The cell reselection process may include sending information from the UE to the base station if a new cell has been selected as a result of the cell reselection process.

[0065] The method may include: receiving, as a source base station, a target base station identifier that identifies a target base station associated with the new cell. The method may alternatively or additionally include: receiving, as a target base station associated with the new cell, multicast session identification information for identifying one or more multicast sessions to which the UE joins, indicating the multicast session identification information of the multicast session to which the UE joins.

[0066] A notification of the activation of the multicast session may be sent to the UE.

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

[0068] Optionally, when the notification of activation of the multicast session is sent and the notification of activation is sent by the base station to the UE after a cell reselection process causing the UE to camp in the base station, the UE is operating in a non-connected RRC state.

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

[0070] The cell reselection process may include sending information from the UE to the base station indicating multicast session identification information of one or more multicast sessions joined by the UE.

[0071] According to another aspect of the present invention, a method at a user equipment (UE) of a wireless communication system is provided, the method comprising: receiving multicast preconfiguration information for a multicast session for which the UE has requested to join; and configuring the UE to receive multicast data via the multicast session according to the multicast preconfiguration information.

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

[0073] The method may include sending, via the base station, a request to join the multicast session to a core network.

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

[0075] The multicast preconfiguration 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.

[0076] According to one or more embodiments, the pre-configuration information includes at least one of the following items:

[0077] - 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),

[0078] - Radio bearer configuration information associated with high Quality of Service (QoS) transmission (e.g. multicast radio bearer "MRB1" configuration primarily for UEs in RRC_CONNECTED state with high QoS),

[0079] - an inactive reception indicator, which indicates to the UE whether the UE is enabled to receive multicast data in a non-connected RRC state (e.g., an RRC_INACTIVE reception indication, where the gNB indicates to the UE whether the UE is enabled to receive multicast data in an RRC_INACTIVE state),

[0080] - information identifying a group of UEs in the same cell that are interested in receiving the multicast data (e.g., a G-RNTI identifying a group of UEs in the same cell that are interested in receiving the multicast data),

[0081] - a Multicast Pre-Configuration ID that identifies the configuration applied by the UE and is associated with a Multicast (MBS) Session ID (e.g. a Temporary Mobile Group Identity (TMGI)),

[0082] - Discontinuous Reception (DRX) configuration information,

[0083] - Neighborhood multicast configuration information (e.g., applied when a candidate UE performs handover or cell reselection), and

[0084] - Cell identification information (eg, cell ID(s)) for identifying one or more cells to which preconfiguration should be applied.

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

[0086] The method may also include receiving data for the multicast session after configuring according to the multicast pre-configuration information.

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

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

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

[0090] The UE may be configured according to the multicast pre-configuration information in response to receiving the notification.

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

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

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

[0094] The cell reselection process may include sending information from the UE to the base station indicating multicast session identification information of one or more multicast sessions joined by the UE.

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

[0096] The multicast pre-configuration information may be received in a message for placing the UE in a non-connected RRC state (eg, RRC_INACTIVE state).

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

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

[0099] The multicast pre-configuration information may be received after a determination is made that a modification of the multicast configuration is required. For example, after a cell reselection process that caused the UE to camp on a base station (e.g., a base station different from the base station in which the UE had previously established its configuration using a multicast session). Additionally or alternatively, the base station may be controlling a cell in which the UE was already camped, but a configuration update of the base station may have resulted in a modification of the multicast configuration.

[0100] The method may further include:

[0101] - after a cell reselection process, receiving a notification indicating that multicast pre-configuration is available for the multicast session; and

[0102] - Sending a multicast pre-configuration request by the UE to the base station, wherein multicast pre-configuration information is received from the base station in response to the sent request.

[0103] The multicast preconfiguration request may be sent after a physical random access channel (PRACH) procedure with the base station in response to a notification indicating that the multicast preconfiguration information is available.

[0104] The cell reselection process may include sending information from the UE to the base station if a new cell has been selected as a result of the cell reselection process.

[0105] The method may include sending a target base station identifier to a base station, the target base station identifier being used to identify a target base station associated with the new cell.

[0106] The method may include sending, to a target base station associated with the new cell, multicast session identification information identifying one or more multicast sessions joined by the UE.

[0107] The method may further include: while the UE is operating in a non-connected RRC state:

[0108] - before the cell reselection process, receiving multicast data for the active multicast session according to the configuration of the base station on which the UE camped before the cell reselection, and

[0109] - wherein the pre-configuration information is used to configure the UE to receive multicast data for the multicast session from a base station where the UE is to camp after cell reselection.

[0110] The cell reselection process may include detecting, by the UE, whether the cell is in a multicast service area for which the UE does not have a corresponding multicast configuration.

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

[0112] According to another aspect of the present invention, a method at a base station (e.g., a gNB or NG-RAN node) that controls a cell serving a user equipment (UE) is provided, the method comprising: establishing a multicast session requested by the UE; and sending multicast pre-configuration information for the multicast session to the UE.

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

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

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

[0116] The pre-configuration information may include one or more of the following:

[0117] - Radio bearer configuration information dedicated to low Quality of Service (QoS) transmission (e.g., a multicast radio bearer "MRB2" configuration dedicated to receiving multicast data with low QoS for a candidate UE),

[0118] - Radio bearer configuration information dedicated to high Quality of Service (QoS) transmission (e.g. multicast radio bearer "MRB1" configuration mainly for UEs in RRC_CONNECTED state with high QoS),

[0119] - Inactive Reception Indication, which indicates to the UE(s) whether to receive multicast data in the non-connected RRC state (e.g., RRC_INACTIVE Reception Indication, where the gNB indicates to the UEs whether to enable them to receive multicast data in the RRC_INACTIVE state),

[0120] - information identifying the group of UEs within the same cell that are interested in receiving multicast data (e.g., RRC_INACTIVE reception indication, where the gNB indicates to the UEs whether to enable them to receive multicast data in RRC_INACTIVE state),

[0121] - a multicast pre-configuration ID identifying the configuration applied by the UE and associated with a multicast (MBS) session ID (e.g. a Temporary Mobile Group Identity (TMGI)),

[0122] -Discontinuous Reception (DRX) configuration information,

[0123] - Neighborhood multicast configuration information (e.g., applied when a candidate UE performs handover or cell reselection), and

[0124] - Cell identification information (eg, cell ID(s)) for identifying one or more cells to which preconfiguration should be applied.

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

[0126] The method may also include sending data for the multicast session to the UE according to the multicast pre-configuration information.

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

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

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

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

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

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

[0133] The cell reselection process may include sending information from the UE to the base station indicating multicast session identification information of one or more multicast sessions joined by the UE.

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

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

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

[0137] The multicast pre-configuration information may be sent to the UE when the UE is operating in a non-connected RRC state.

[0138] The multicast preconfiguration information may be sent after a cell reselection process that causes the UE to camp in the base station.

[0139] The method may further include:

[0140] After the cell reselection process, sending a notification indicating that the multicast pre-configuration information is available for the multicast session; and

[0141] A multicast pre-configuration request is received from the UE, wherein the multicast pre-configuration information is sent in response to receiving the request.

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

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

[0144] The method may include receiving, as a source base station, a target base station identifier identifying a target base station associated with the new cell.

[0145] The method may include receiving, as a target base station associated with the new cell, multicast session identification information identifying one or more multicast sessions joined by the UE.

[0146] The UE may be configured in a non-connected RRC state (e.g., RRC_INACTIVE state). The base station may control a cell determined to require modification of the multicast configuration. For example, the base station may control a cell in which the UE is to reside following a cell reselection process (e.g., a base station different from the base station in which the UE has previously established its configuration using a multicast session). Alternatively, the base station may be controlling a cell in which the UE is already residing, but a configuration update of the base station may have caused a modification of the multicast configuration. The method may also include receiving, from the UE, a request for multicast pre-configuration information corresponding to the base station.

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

[0148] According to one or more embodiments, a base station sends a notification if it detects that a multicast configuration modification is necessary for a UE to receive multicast data in one or more cells controlled by the base station.

[0149] According to one or more embodiments, the notification is sent if the base station has been informed of a modification of the multicast configuration in one or more cells controlled by another base station.

[0150] The method may further include, before sending the updated multicast configuration information for the multicast session, checking whether the UE has a context allowing it to receive the multicast data for the multicast session.

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

[0152] The method may include: in response to determining that modification of the multicast configuration for the UE is necessary for receiving (e.g., continuing to receive) multicast data for the activated multicast session, sending a request to a base station. Prior to determining the requirement for the multicast configuration modification, the UE may have received multicast configuration information corresponding to the activated multicast session. In the event that the previously received multicast configuration information is no longer valid for receiving data for the session, the method according to the present aspect advantageously reconfigures the UE using the updated multicast configuration information so that the UE can continue to receive multicast data for the activated multicast session.

[0153] For example, according to the method described in the related aspects described herein, the previous (e.g., initial) multicast configuration information of the UE may be obtained before or after the MBS session is activated (established). Alternatively, the previous multicast configuration information may be obtained before the MBS session is activated when the UE is in a non-connected RRC (e.g., RRC_INACTIVE) state or when the UE is in an RRC_CONNECTED state.

[0154] Alternatively, the previous multicast configuration information of the UE may be obtained after the MBS session is activated when the UE is in a non-connected RRC (eg, RRC_INACTIVE) state.

[0155] The method may include determining, by the UE, that updated multicast configuration information is necessary for receiving multicast data for the activated multicast session. Advantageously, the UE may determine the requirement for updated multicast configuration information prior to sending a request to the base station.

[0156] The UE may determine that a modification to the multicast configuration is necessary (eg, the method may include detecting, by the UE, a requirement to modify the multicast configuration).

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

[0158] The method may include sending a request to the base station in response to a reselection process. The reselection process may include the UE camping in a cell controlled by the base station (e.g., as described herein). For example, the UE may have initiated a handover or reselection to the base station when configured in a non-connected RRC state.

[0159] The method may include sending a request to the base station in response to a configuration update of the base station (eg, a modification of the multicast configuration may be caused by the base station configuration update). The configuration update may include, for example, a reset of the base station due to an error in the network and / or the base station.

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

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

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

[0163] Throughout the method of the present invention, the UE may remain in a non-connected state while continuing to receive multicast data from an activated multicast session.

[0164] According to yet another aspect of the present invention, a method at a user equipment (UE) (e.g., at least one UE) of a wireless communication system is provided. The UE is configured to receive multicast data of an activated multicast session (i.e., a multicast session that has already been activated), wherein modification of the multicast configuration of the UE is necessary (e.g., because the multicast configuration information previously obtained by the UE for receiving multicast data for the activated multicast session is not (e.g., 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 the base station; receiving multicast configuration information corresponding to the base station; and configuring the UE to receive multicast data for the activated multicast session according to the multicast configuration information. Other optional statements of the aforementioned aspects also apply to this aspect.

[0165] According to another aspect of the present invention, a method at a base station controlling a cell is provided. The base station is configured to serve a user equipment (UE) (e.g., at least one UE) using an activated multicast session (i.e., a multicast session that has been activated). The method includes: receiving a request for updated multicast configuration information of the activated multicast session from the UE (i.e., the updated multicast configuration information can be configured to replace any existing (e.g., initial or old) multicast configuration information that the UE may have previously obtained); and sending the updated multicast configuration information of the activated multicast session to the UE.

[0166] For example, according to the method described in any one of the related aspects described herein, the previous (e.g., initial) multicast configuration information of the UE may have been obtained before or after the MBS session is activated. Optionally, the previous multicast configuration information may have been obtained before the MBS session is activated when the UE is in a non-connected RRC (e.g., RRC_INACTIVE) state or when the UE is in an RRC_CONNECTED state. Alternatively, the previous multicast configuration information may have been obtained after the MBS session is activated when the UE is in a non-connected RRC (e.g., RRC_INACTIVE) state.

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

[0168] Optionally, the method includes: before receiving a request for updated multicast configuration information from the UE, determining by the base station that the updated multicast configuration information is necessary for the UE to receive multicast data for the activated multicast session. In this way, the base station can detect that a modification to the multicast configuration is required (for example, the method can include detecting the necessity of modifying (e.g., updating) the multicast configuration at the base station).

[0169] The UE may be configured in the non-connected RRC state (eg, when the base station receives a request). The method may include the base station determining that the UE in the non-connected RRC state does not have an updated multicast configuration necessary to receive multicast data for the activated multicast session.

[0170] Optionally, the method includes receiving a request from the UE after the reselection process. This causes the UE to reside in a cell controlled by the base station. The reselection process may include the UE residing in a cell controlled by the base station (e.g., as described herein). For example, the UE may have initiated a handover or reselection to the base station when configured in a non-connected RRC state. Any multicast configuration information that has been previously transmitted by the base station may not have been received by the UE that is now residing in a cell controlled by the base station.

[0171] The method may include receiving a request from the UE after a configuration update of the base station. In this way, a modification of the multicast configuration may have been caused by the configuration update of the base station. For example, before the configuration update, the base station may have transmitted multicast configuration information to the UE to enable the UE to receive multicast data for the multicast session. However, due to the modification of the multicast configuration of the UE, the previously transmitted multicast configuration information no longer allows the UE to receive multicast data for the activated session.

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

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

[0174] Throughout the method of the present invention, the UE may remain in a non-connected state while continuing to receive multicast data from the activated multicast session.

[0175] According to another aspect of the present invention, a method is provided at a base station controlling a cell serving a user equipment (UE) (e.g., at least one UE). The base station is arranged to serve the UE using multicast data of an activated multicast session (i.e., a multicast session that has already been activated), wherein the multicast configuration obtained by the UE needs to be modified (e.g., the multicast configuration previously obtained by the UE for receiving multicast data of the activated multicast session is no longer valid). The method comprises: receiving a request for (updated) multicast configuration information for the activated multicast session from the UE; and sending (updated) multicast configuration information corresponding to the base station to the UE. Other optional statements of the aforementioned aspects also apply to this aspect.

[0176] In a further aspect according to the invention there is provided an apparatus comprising a user equipment configured to perform a method according to any of the method aspects outlined above in relation to a method performed by a UE.

[0177] In a further aspect according to the invention, there is provided an apparatus comprising a base station configured to perform a method according to any method aspect stated above in relation to a method performed by the base station.

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

[0179] The program may be provided as such, or may be carried on, by or in a (computer-readable) carrier medium. The carrier medium may be non-transitory, such as a storage medium, in particular a computer-readable storage medium. The carrier medium may also be transient, such as a signal or other transmission medium. The signal may be transmitted via any suitable network, including the Internet. Other features of the invention are characterized by the independent and dependent claims.

[0180] In any of the above aspects, a multicast session may include a session that sends data from a network to one or more UEs, the participating UEs having specified attributes or specific profiles / configurations that qualify them to receive data via the multicast session. The multicast session may be a multicast and broadcast MBS session in accordance with a fifth generation (5G) new radio (NR) (e.g., as defined in Release 17 of 5G NR).

[0181] Any features in one aspect of the invention may be applied to other aspects of the invention in any appropriate combination. In particular, method aspects may be applied to apparatus aspects, and vice versa.

[0182] Furthermore, features implemented in hardware may be implemented in software and vice versa.Any references herein to software and hardware features should be interpreted accordingly.

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

[0184] It should also be understood that specific combinations of the various features described and defined in any aspect of the invention may be implemented and / or provided and / or used independently. BRIEF DESCRIPTION OF THE DRAWINGS

[0185] Various aspects of the invention will now be described, by way of example only, and with reference to the following drawings, in which:

[0186] Figure 1 is a schematic diagram illustrating a first example wireless communication system in which the present invention may be implemented according to one or more embodiments;

[0187] Figure 2 A schematic block diagram illustrating an example configuration of a UE in which the present invention may be implemented according to one or more embodiments;

[0188] Figure 3 A schematic block diagram illustrating an example configuration of a base station in which the present invention may be implemented according to one or more embodiments;

[0189] Figure 4 is a flow chart showing RRC connection states and transitions of a UE in a 5G NR system;

[0190] Figure 5a and Figure 5b is a simplified flow chart illustrating the evolution of an MBS session from creation to activation;

[0191] Figure 6 is a flow chart illustrating sending UE pre-configuration after a join request according to an embodiment;

[0192] Figure 7 is a flow chart illustrating sending UE pre-configuration after handover according to an embodiment;

[0193] Figure 8 is a flow chart illustrating sending UE pre-configuration as part of the RRC_Release procedure according to an embodiment;

[0194] Fig. 9 is a flow chart illustrating sending UE pre-configuration triggered by a paging message;

[0195] Fig.10a and Fig.10b is a flow chart illustrating sending a UE pre-configuration as a result of a specific cell reselection process according to an embodiment;

[0196] Fig.11 is a flow chart illustrating use of pre-configuration by a UE after a session is activated according to an embodiment;

[0197] Fig.12 is a flow chart illustrating use of pre-configuration by a UE after a session is activated according to an embodiment;

[0198] Fig.13 is a flow chart of a method performed by a gNB according to an embodiment;

[0199] Fig.14 is a flow chart of a method performed by a UE according to an embodiment;

[0200] Fig.15 is a flow chart illustrating a process of receiving pre-configuration information at a UE according to an embodiment; and

[0201] Fig.16 is a flowchart illustrating a process of transmitting pre-configuration information by a base station according to an embodiment.

[0202] Fig.17 is a flow chart illustrating an update of a multicast configuration initiated by a network for a UE in an RRC_INACTIVE state according to an embodiment;

[0203] Fig.18 is a flow chart illustrating sending a configuration update request by a UE in RRC_INACTIVE state according to an embodiment;

[0204] Fig.19 is a flowchart illustrating a method of controlling a UE in an RRC_INACTIVE state to update a multicast configuration of the UE according to an embodiment; and

[0205] Fig. 20 is a flowchart illustrating a method of controlling a base station to update a multicast configuration of a UE in an RRC_INACTIVE state according to an embodiment. DETAILED DESCRIPTION

[0206] Figure 1An example wireless communication system 100 is illustrated, in particular a mobile radio communication system such as a fifth generation (5G) new radio (NR) system supporting multicast and broadcast services (MBS). Although in the following description, embodiments and examples of embodiments of the present invention will be described with respect to a 5G NR system, it should be understood that the present invention is not intended to be limited to a 5G NR system, and the present invention may be used in any wireless communication system supporting MBS or similar services.

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

[0208] Each of these base stations controls one or more cells. For example, base station 110 controls cell 120, and base station 111 controls cell 121. A cell is a geographical area of ​​a radio network defined by the frequencies used in the cell for transmitting data. A UE can uniquely identify a cell based on an identification broadcast over the geographical area. Each base station 110, 111 can serve several UEs such as UE 101 or UE 151. (as discussed below) Once a UE has established an RRC connection with a base station, the base station to which the UE is connected is referred to as the serving base station or source base station of the UE, and the cell controlled by the serving base station and in which the UE resides is referred to as a serving cell. The interface between gNB and UE is the Uu interface, which uses: protocol sublayers SDAP (Service Data Application Protocol), PDCP (Packet Data Convergence Protocol), RLC (Radio Link Control), MAC (Medium Access Control), PHY (Physical) in the user plane; and protocol sublayers RRC (Radio Resource Control), PDCP, RLC, MAC, PHY in the control plane.

[0209] Figure 2 Example UE device 205 (eg Figure 1 1 or 151 in the block diagram of the UE 101 or UE 151, wherein the present invention can be implemented according to one or more embodiments of the present invention. The UE includes components for transmitting and receiving communications, including a UE communication 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 these components communicate with each other.

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

[0211] The processor 215 is configured to execute machine-readable instructions. The execution of these machine-readable instructions causes the UE to perform various functions. These functions may involve transmission or communication with peripheral devices (such as keyboard, screen, mouse, etc.) Figure 2The processor may run an operating system such as iOS, Windows, Android, etc. The processor 215 may be a single processor, or may include two or more processors that perform the processing required 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 the skilled person.

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

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

[0214] The radio communication uses an antenna set 245 adapted to the frequency spectrum of the frequency transposed signal sent from the baseband modem. The antenna set 245 may be limited to one antenna, but preferably contains several antennas to provide beamforming capabilities.

[0215] The UE communication manager 220 handles the establishment of the UE's communication to the radio access network, its control and its release. The UE regularly receives from the base station an indication of the time slots available for communication between the UE and the base station. The UE then knows when and how often it expects incoming data or must send its outgoing data, whether the data belongs to the control plane or the data plane. In an example implementation, the UE communication manager 220 implements the Uu interface.

[0216] Figure 3 The base station device 305 (eg, Figure 1 1 and 111). The base station device 305 includes components for transmitting and receiving communications, including a base station communication manager 320, a core network communication manager 355, a transceiver 335, an antenna set 345, a memory 325, a processor (CPU) 315, and an inter-station communication manager 365. All of these components communicate with each other.

[0217] The base station communication manager 320 handles communications with multiple UEs. The base station communication manager 320 is responsible for the establishment, control and release of these communications. In an example 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 to different UE communications. Information about the scheduling of these time slots is regularly sent to the UEs involved.

[0218] The core network communication manager 355 manages the communication between the base station and the core network. The core network communication manager 355 may provide a standardized NG interface defined by the 3GPP standard to support these communications.

[0219] The transceiver 335 is configured to provide two-way wireless communication with other wireless devices. These devices can be UEs or even other base stations. The transceiver 335 provides the necessary modems and frequency shifters to connect to a large number of UEs simultaneously 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 can be limited to one antenna, but preferably includes several antennas to provide beamforming capabilities.

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

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

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

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

[0224] At power-up, the UE is in RRC_IDLE state 401, the UE makes radio link quality measurements and performs a cell selection evaluation process (as defined in 3GPP specification TS 38.304) to identify a target gNB to connect to. When an RRC connection is established with the target gNB that becomes the source gNB serving the UE, the UE state changes to RRC_CONNECTED state 402. In the following, the source base station (or source gNB) may also be referred to as a serving base station or serving gNB. If there is no radio activity for a period of time, the RRC connection may be released by the source gNB and the UE's RRC state then changes back to RRC_IDLE state 401.

[0225] While releasing the RRC connection is interesting for capacity utilization and energy saving, it is not ideal from a latency perspective. The overhead of establishing an RRC connection requires additional signaling that introduces latency. To address this drawback, the RRC_INACTIVE state 403 has been introduced for 5G NR. When the UE is in the RRC_INNACTIVE state 403, the UE cannot communicate with the 5G system, but both the source gNB (e.g., the last serving gNB) and the UE store the UE context or configuration. The stored UE context or configuration includes information that facilitates fast recovery of the connection. The information may include security context (e.g., security parameters such as security keys, UE security capabilities), measurement configuration, radio configuration (e.g., UE radio capabilities), information about bearers, PDU (Protocol Data Unit) session context, etc. Therefore, when in the RRC_CONNECTED state 402, the RRC connection may be suspended by the source gNB (with a pending release) and the UE moves to the RRC_INACTIVE state 403. From the RRC_INACTIVE state 403, the UE may be switched back to the RRC_CONNECTED state 402 (Resume) by the gNB and the UE applies the stored UE context or configuration. Upon receiving the RRC Resume Request message from the UE, the gNB sends the RRC Resume message.

[0226] From the RRC_CONNECTED state or the RRC_INNACTIVE state, the UE may transition to the RRC_IDLE state upon receiving an RRC release command from the gNB.

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

[0228] 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 contains information indicating the RNA. The RNA is an area in which the UE can move without notifying the network. When a UE in the RRC_INACTIVE state moves to a cell that is not part of its currently assigned RNA, the UE performs a location update procedure that enables the RAN (e.g., serving gNB) to update the RNA assigned to the UE. In other words, the UE has the possibility to request an RNA update to be informed of modifications to the RNA. When, as part of the cell reselection process, the UE selects a cell managed by a target gNB from the RNA, the UE sends a recovery request to the target gNB with three available options: keeping the UE in the RRC_INACTIVE state, setting the UE in the RRC_IDLE state, or setting the UE in the RRC_CONNECTED state.

[0229] In the RRC_IDLE state, the paging procedure is initiated by the core network to inform the UE that it must resume the connection. In the RRC_INACTIVE state, the paging procedure is initiated by the NG RAN (i.e., the last gNB that has set the UE in the RRC_INACTIVE state).

[0230] Return to Figure 1 , assuming that UE 101 is in RRC_INACTIVE state and it 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, which is the base station for controlling cell 121 in which UE 101 is camping, via core network 102 and transport bearer (also known as GTP-U tunnel) 106 on link 141. The multicast data is then transmitted by base station 111 to UE 111 via MBS radio bearer (MRB) 154. Figure 1Also shown is UE 151 receiving data via MRB 153. In point-to-multipoint transmission of data from base station 111, MRB 154 is the same MRB as MRB 153. In point-to-point transmission, MRBs 154 and 153 are different. A radio bearer is a collection of PHY (layer 1) and MAC (layer 2) parameters that allow a higher layer data connection between a UE and a gNB. In 5G NR, multiple types of radio bearers are defined: SRBs (Signalling Radio Bearers) for the control plane, DRBs (Data Radio Bearers) that allow point-to-point communication with one UE in the user plane (unicast), and MRBs that allow point-to-point and point-to-multipoint communication with multiple UEs also in the user plane (multicast / broadcast).

[0231] The MBS Session Join procedure as specified in 3GPP TS23.247 is used by the UE to inform the 5GC of its interest in joining a multicast MBS session. The first accepted UE Join Request triggers the establishment of a multicast MBS session to the NG RAN and the UE. Before sending a Join Request for a multicast MBS session, the UE should have established a PDU session that can be associated with (one or more) multicast sessions using the procedure as specified in TS23.502. In addition, the UE should know at least the MBS Session ID of the multicast group that the UE can join via the service announcement broadcast by the network. In order to join the multicast group, the UE sends a PDU Session Modification Request for the associated PDU session, which contains one or several MBS Session IDs and a Join Request. The (one or more) MBS Session IDs indicate the (one or more) multicast MBS session that the UE wants to join.

[0232] In order to join an MBS session, the UE must be in RRC_CONNECTED state.

[0233] Figure 5a and Figure 5b Together, example message flows for an example scenario of MBS session evolution from creation to activation are illustrated. Figure 5a illustrates an example message flow for MBS session creation and establishment, and Figure 5b An example message flow for MBS session activation is illustrated.

[0234] First reference Figure 5a , a UE (e.g., UE 101 (or it may be UE 151)) is powered on and enters RRC_IDLE state 500. During step 501, as a result of the cell selection process defined in TS 38.304 clause 5.2.3, the UE connects to the nearest gNB (e.g., at Figure 1 111). Once connected to the gNB, the UE enters the RRC_CONNECTED state 502. The UE then performs a registration process or procedure 503, which aims to identify the UE in the core network or 5GC 102, check the UE subscription and perform authorization. The registration process is detailed in TS 23.502 clause 4.2.2.2.

[0235] After registration, the UE creates a first PDU session via a PDU session establishment process 504. The first PDU session is a default PDU session that allows access to 5G core services. This PDU session can then be associated with an MBS session. The PDU session establishment process is defined in TS23.502 clause 4.3.2.

[0236] The AF (Application Function) 104 in the 5G Core 102 creates a multicast session based on the requirements 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 driven by the AF 104 (Application Function) and when completed, the result is the allocation of an MBS Session ID (e.g., TMGI for a Temporary Mobile Group Identity) for the multicast session and session creation.

[0237] Once the multicast session is created, the AF 104 performs a service announcement 506 to the UE, for example, the AF 104 sends a service announcement message. The service announcement message includes multicast session information, which includes multicast MBS session ID, service area description (or information) and session description information, etc. Service announcements are described in TS23.247 clause 6.11. Some UEs may not need to receive service announcement messages: for example, the service information provided in the service announcement may be pre-configured at some UEs. In addition, UEs that are not connected at the time of the service announcement can access the service information by directly soliciting the AF 104 (application function) or MBSF (MBS service function) in the core network 102.

[0238] There is no timing dependency between the UE connection / registration / PDU session establishment process (collectively identified by reference numeral 521) and the MBS session creation / notification process (collectively identified by reference numeral 522). Both 521 and 522 are performed independently of each other and can occur at any time.

[0239] Once the UE 101 is registered in the core network 102 and a default PDU session is established and the multicast service information is known, the UE may send or make a join request 507 to the core network 102 to log in to the multicast session. The UE may request the service announcement message 506, or by pre-configuration, or by soliciting information from the core network. Figure 5a or Figure 5b The UE may also use a PDU session modification request to modify the multicast session information (e.g., the message flow for pre-configuring or requesting session information is not shown in the figure), know the multicast session information (such as the multicast MBS session ID as described above, etc.). In order to join the multicast session, the UE may reuse the default PDU session created earlier (at 504) and send a PDU session modification request including the multicast session ID (TMGI). The PDU session modification request is then considered a join request (507). Another possibility is to establish a dedicated MBS PDU session including the multicast session ID for the join request 507.

[0240] When the core network 102 receives the join request 507, the core network 102 performs a multicast session establishment process 508. During the session establishment process 508, the core network 102 verifies the subscription and authorization level of the UE to check whether the UE is allowed to access the multicast session (i.e., check whether the UE is one of the UEs of the specific multicast group authorized to receive the multicast session). In addition, as part of the session establishment process 508, the core network 102 will set up the necessary resources in the core network to transmit the multicast data from the application server 103 to the relevant gNB. The relevant gNB is defined by the multicast service area information established in the session creation step 505. The join process 507 and the multicast session establishment process 508 are defined in TS 23.247 clause 7.2.1.

[0241] exist Figure 5a In the example shown, the gNB of the NG-RAN (e.g., gNB 111) decides to switch UE 101 to the RRC_INACTIVE state 510 by sending an RRCRelease message 509 (TS 38.331 clause 6.2.2). The most common reason is load management, and the gNB may decide to offload its control plane load by switching some UEs to RRC_INACTIVE. In addition, ongoing discussions for Release 18 suggest that both the UE and the core network provide additional information to the gNB to assist the gNB in ​​making the decision to switch some UEs to the RRC_INACTIVE state. The additional information may include capability information from both the UE and the core network indicating the ability to send 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.

[0242] Now also refer to Figure 5b, in the case where the UE is in RRC_INACTIVE state 510, the UE should perform a cell reselection process 511 as a background task. This process manages the UE mobility which allows "reselecting" a new gNB based on the new UE location. Cell reselection is described in detail in TS 38.304 clause 5.2.4. In this example, it is assumed that the NG-RAN node is gNB 110 or gNB 111 based on the UE mobility. Note that cell reselection 511 is Figure 5b Optional steps (as shown in dashed outline) in the method shown. Further such optional method steps are indicated by dashed lines in subsequent figures.

[0243] Once the MBS session is created (505), the AF 104 (Application Function) in the core network 102 can be triggered to activate the multicast session (i.e., MBS session activation 512). The trigger for activating the multicast session is independent of the join and session establishment process (identified collectively by reference numeral 523). One possible trigger is the availability of data from the application server 103. Multicast session activation is described in TS23.247 clause 7.2.5.2. The main result of this process is the reservation of RAN (Radio Access Network) resources for the gNB. These resources allow the communication of multicast data to UEs that have joined the multicast session. The RAN resource allocation includes the MRB (MBS Radio Bearer) configuration. Each gNB will use a specific configuration for the MRB for the multicast session.

[0244] 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. The RRC_INACTIVE UEs need to be paged because, as illustrated in 510, the RRC_INACTIVE UEs are still moving and may enter the cell of another gNB, but neither the new gNB (target gNB) nor the first gNB (source gNB) is aware of the UE movement at this step (i.e., upon activation of the multicast session 512). The core network 102 sends a group paging message with the MBS session ID ( Figure 5b The multicast session ID is sent to the gNB together with the multicast session ID (not shown in the figure), and then each gNB sends a group paging message 513 with the multicast session ID. This sequence is described as step 5 in TS23.247 clause 7.2.5.2.

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

[0246] As part of the RRC connection recovery preparation, UE 101 performs a random access procedure to the gNB (PRACH procedure 516, PRACH stands for Physical Random Access Channel). The PRACH procedure is intended to update the UE's system information in the event that the UE has moved to another cell or if the system information has not been updated for a period of time. UE 101 then performs and completes the connection recovery procedure in 517, which includes sending an RRCResumeRequest message ( Figure 5b The connection recovery process 517 follows the RRC connection process defined in detail in TS 38.331.

[0247] Once the RRC connection procedure is completed, the UE is in RRC_CONNECTED state 518.

[0248] Only in this step, when UE 101 is in RRC_CONNECTED state 518, gNB 111 can send multicast configuration (including MRB information) to the UE (step 519), which includes sending an RRCReconfiguration message including MRB information (TS38.331 clause 6.2.2).

[0249] Once the UE applies the received multicast configuration, the UE may receive the multicast data in 520 .

[0250] As discussed in the introduction, in the case where the UE must switch from the RRC_INACTIVE state to the RRC_CONNECTED state to be configured for multicast reception, the additional signaling and other resources required to configure the UE in the RRC_CONNECTED state increases the load problem at the NG-RAN node (gNB) (i.e., too many UEs are in the RRC_CONNECTED state), and thus the benefit of switching the UE to the RRC_INACTIVE state to avoid congestion is lost or at least reduced. For example, as discussed above, the processing of paging, PRACH, recovery to the RRC_CONNECTED state and then MBS configuration may lead to link congestion and latency issues.

[0251] The following embodiments provide a method for configuring a UE to receive multicast data while in the RRC_INACTIVE state, which simplifies Figure 5b This is because if the UE is pre-configured to receive under such conditions, the RRC recovery procedure immediately preceding the MBS configuration can be skipped.

[0252] Fig.15 An embodiment of the present invention is shown in FIG. Fig.15The method 1500 is performed at a UE. At 1501, the UE may send a request to join a multicast session. In 5G NR, the request is typically sent to the core network via a base station such as gNB 110, 111, etc., but it is contemplated that in alternative implementations, the request may be sent to or via another network entity (e.g., a UE acting as a relay).

[0253] Prior to activation of a multicast session that the UE has requested to join, multicast pre-configuration information is received by the UE at 1502. Session activation may be, for example, as described above with respect to Figure 5b The MBS session described in 512 is activated. Pre-configuration information may be received from a base station or another entity in the network (such as a UE acting as a relay). The UE may then be configured according to the multicast pre-configuration information to receive multicast data via the multicast session (1503).

[0254] Fig.16 A flow chart 1600 with steps performed at a base station according to an embodiment is shown. At 1601, the base station may receive a request made by a UE to join a multicast session. The request is for the core network, so such a request may then be forwarded (sent) by the base station to the core network 102. At 1602, the multicast session is established. In other words, the base station participates in a multicast session establishment process to establish a session between the UE and the core network. This will include receiving information from the core network in response to the join request as part of the establishment process. The multicast session establishment may include combining Figure 5a The MBS session establishment 508 described establishes the MBS session requested by the UE 101 between the UE 101, the gNBs 110, 111 and the core network 102. Subsequently, at 1603, and prior to activation of the multicast session, multicast pre-configuration information is sent to the UE.

[0255] In this description, "multicast preconfiguration information" means configuration information (data) received and stored to be applied later in appropriate circumstances. According to some embodiments, the information is received before the multicast (MBS) session of the session to which the preconfiguration information relates is activated. In other embodiments, the UE can receive multicast data after the multicast (MBS) session is activated, and the network provides preconfiguration data to preconfigure the UE to receive multicast data after cell switching as a result of cell reselection processing. Depending on the implementation, it can be used to configure the UE before and / or after the multicast (MBS) session is activated. When we specifically mention the "multicast (MBS) preconfiguration" of the UE in the description, this refers to the action of applying the received multicast preconfiguration information to receive multicast (MBS) session information in appropriate circumstances.

[0256] Sending and receiving pre-configuration information prior to activation enables the network to reduce configuration load and signaling overhead when the first multicast data is received. This mitigates the risk of overloading the cell (i.e., radio resources in the cell) and / or the gNB (i.e., processing resources at the gNB) when configuring all involved UEs with the radio resources required when the session becomes active.

[0257] According to the embodiment, the UE may be configured at different stages. In an embodiment, the network may configure the UE after the UE makes a join request and when the first multicast data arrives. Thus, when the network is ready to configure the UE, the network generates a trigger information element or message that is sent to the UE.

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

[0259] Other triggering aspects may be evaluated by the network, such as deciding which UEs are suitable candidates for the multicast session (eg, based on the capabilities of the UEs).Once the candidate UE group is determined, the network may then trigger a multicast preconfiguration message to the identified UE group.

[0260] For example, the candidate UE may be a UE having the capabilities listed below:

[0261] - capable of or preferably receiving multicast data in RRC_INACTIVE state,

[0262] - Receiving multicast data in RRC_CONNECTED state with low QoS.

[0263] In some scenarios, the UE may request pre-configuration and thus trigger a multicast pre-configuration message sent by the network side (ie, from the base station).

[0264] The multicast preconfiguration information may include one or more preconfigurations, each of which may consider different information elements, including but not limited to:

[0265] - a multicast radio bearer "MRB2" configuration dedicated to receiving multicast data with low QoS for candidate UEs, or a "MRB1" configuration primarily for UEs in RRC_CONNECTED state with high QoS,

[0266] -RRC_INACTIVE reception indication, where the gNB indicates to the UE whether to enable the UE to 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),

[0267] - A G-RNTI identifying a group of UEs in the same cell that are interested in receiving multicast data,

[0268] - a multicast pre-configuration ID related to the configuration applied for the UE and associated with the MBS session ID (e.g. TMGI),

[0269] - a discontinuous reception (DRX) configuration for receiving multicast data for the candidate UE,

[0270] - Neighborhood multicast configuration applied when a candidate UE performs handover or cell reselection,

[0271] - Cell ID(s) identifying the cell(s) to which the preconfiguration should apply.

[0272] The multicast configuration or pre-configuration of the MBS session can have common information elements used by all NG-RAN nodes located in the MBS service area, so the UE has a common configuration that can be applied anywhere in the MBS service area. Thus, cell selection (reselection) or handover becomes transparent to mobile UEs.

[0273] The following description sets forth different embodiments for sending multicast pre-configuration information at different stages with different possible triggering events. These include:

[0274] -When (or after) an MBS session is established in the RRC_CONNECTED state ( Figure 6 ),

[0275] -When the UE switches to the RRC_INACTIVE state,

[0276] -When the UE is in RRC_INACTIVE state,

[0277] - Covers most scenarios of possible handover in RRC_CONNECTED state or cell selection (reselection) in RRC_INACTIVE state.

[0278] In the first scenario, in order to send the MBS multicast configuration to the UE, the NG-RAN node must have made radio resource reservations corresponding to the MBS session requirements (such as QoS flow information or RRC reception status (RRC_CONNECTED, RRC_INACTIVE).

[0279] During the UE join request procedure, the gNB has sufficient information to make radio resource reservations for UE reception in both RRC_INACTIVE and RRC_CONNECTED states. According to an embodiment, based on this knowledge, the gNB sends pre-configuration information (corresponding to RRC_INACTIVE and RRC_CONNECTED) to the core network, which then sends the pre-configuration information to the UE. Thus, the UE configuration is distributed in time before session activation.

[0280] Figure 6 is a flowchart illustrating sending multicast pre-configuration information after a UE requests to join according to an embodiment based on the first scenario.

[0281] UE 601 belongs to a group of candidate user equipments (UEs) that are capable of receiving multicast data with low QoS as described above. The UE 601 is in RRC_CONNECTED state 604 and attempts to join an MBS session. After the notification message 506 from 5GC 603 informs of the creation of an MBS session with an associated TMGI (i.e., a temporary mobile group identifier used as a valid MBS session ID), UE 601 will proceed to a session join step 605 (or alternatively, a session update) and then proceed to a session establishment in 606. In an embodiment, these steps correspond to the following regarding Fig.13 Step 1300 of the description. UE 601 may inform NG-RAN node 602 and 5GC 603 of its capability and / or preference to receive multicast (MBS) data with low QoS or in RRC_INACTIVE state. This information may be sent in advance during the registration phase or join request.

[0282] After receiving the join request, an MBS session establishment process is performed between the UE 601, the NG-RAN node 602 and the 5GC 603 in 606. In 606, a multicast session context is created and associated with the UE 601. In Release 17, an MRB context is configurable and included in the multicast session context, and radio resources can be reserved as in 1301. At this stage, an MRB context refers to an MRB1 or MRB2 context that allows the UE to receive multicast data in the RRC_CONNECTED state (TS38.401 clause 6.4 and TS23.247 clause 7.2.1.3), while no MRB context is available for reception in the RRC_INACTIVE state.

[0283] In this embodiment, pre-configuration can be added to the MBS session establishment process 606, and radio resources can be reserved as in step 1301. In other words, the multicast pre-configuration information is sent to the UE when the multicast session is established. Thereafter, the UE pre-configured using the received multicast pre-configuration information at this stage can receive multicast data in the RRC_INACTIVE state.

[0284] Multicast (pre) configuration may refer to multicast point-to-multipoint (PTM) configuration in the following description, which allows shared delivery of multicast data to one or more than one UE over the radio. Multicast PTM configuration is applied to UEs receiving multicast data in RRC_INACTIVE state.

[0285] For example, the multicast pre-configuration information may be added to the already existing multicast session context in the MBS session establishment process 606. Another implementation is to create a new multicast pre-configuration session context separately and then add it to the process in 606. The multicast pre-configuration session context is then added to the information element to be exchanged with the UE during the MBS session establishment phase and sent via the RRC reconfiguration message.

[0286] The multicast preconfiguration context should be established by the network before or at the time of MBS session establishment 606, and thus the multicast preconfiguration context may trigger multicast session context modification and / or creation in 606. Another condition may be added to the triggering event, such as a candidate UE portfolio.

[0287] The multicast preconfiguration information includes (one or more than one) MRB1 / MRB2 configuration and a list of the above information elements. The network may choose to share the delivery of multicast data to multiple UEs via multicast PTM preconfiguration. Otherwise, the UE may be preconfigured for individual delivery, therefore specifying a dedicated multicast preconfiguration.

[0288] When the MBS session is activated and the UE 601 is in the RRC_INACTIVE state, then the UE can apply its multicast pre-configuration to receive multicast data. There is no need to restore the RRC_CONNECTED state.

[0289] The multicast preconfiguration context may be established after the MBS session is established in 606, and thus triggers various multicast preconfiguration messages sent to the UE 601 according to the RRC state of the UE 601. The following scenarios depict other alternatives for configuring / preconfiguring the UE by receiving preconfiguration information under different timings and / or conditions.

[0290] Some UEs are always moving, and it may happen that the UE moves after receiving the preconfiguration information from the gNB. Therefore, when the 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 preconfiguration information to match its resources. Therefore, in this second scenario, the preconfiguration information is always accurate in the event that the UE moves to a different cell.

[0291] Figure 7 is a flow chart illustrating sending UE pre-configuration after handover according to an embodiment applicable in the second scenario.

[0292] The network may choose to configure UE 601 independently of the MBS session establishment process in 706. In addition, the multicast pre-configuration context may be set by the network after the MBS session establishment 706, which may then trigger the message in 708 to send pre-configuration information to UE 601, which may be used to pre-configure or configure the UE. Figure 7 The scenario in considers that a multicast pre-configuration / configuration context is available after the MBS session establishment 706 while the UE is in RRC_CONNECTED state. The NG-RAN node 602 may include this context in the multicast pre-configuration message in 708. Other triggering conditions related to the candidate UE set may be required to send the multicast pre-configuration message in 708.

[0293] If the UE is in the RRC_CONNECTED state for sending the pre-configuration message, the message in 708 corresponds to step 1302. If the handover is performed in the RRC_CONNECTED state, the message in 708 may also be equivalent to (described below) Fig.13 Step 1306.

[0294] In an example, the message in 708 may be sent to UE 601 in one or more RRC messages such as an RRCReconfiguration message, an RRCRelease message with, for example, SuspendConfig-, or a dedicated System Information Block (SIB). The message may include various information elements, and primarily include MRB2 configuration.

[0295] Before receiving the multicast preconfiguration information, a handover may occur in 707, the candidate UE 601 has not been preconfigured. During the handover process, 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. Therefore, the target NG-RAN node 700 may choose to preconfigure the UE by sending a multicast preconfiguration message.

[0296] For example, the handover 707, 1304 may take place after the source multicast preconfiguration message in 708, the target NG-RAN node 700 should then send a target multicast preconfiguration message. Another alternative is to include a list of neighbor cells with corresponding multicast preconfiguration / configuration in the source multicast preconfiguration message in 708. In this case, the UE 601 handed over to the target NG-RAN node 700 will be able to apply the target multicast preconfiguration without having to be preconfigured again.

[0297] In the specific case where the source 602 and target NG-RAN 700 nodes are within the same MBS service area and share a common multicast pre-configuration / configuration context within the MBS service area, the UE 601 may be pre-configured / configured once within the MBS service area.

[0298] We can consider a third scenario where the UE may indicate its capabilities and preferences with respect to the received RRC state when it makes the Join Request procedure. As part of the session establishment, the gNB is also aware of the capabilities / preferences applied by the UE with respect to the received RRC state. At any time, for load management purposes, 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 a pre-configuration or update pre-configuration to the UE to be switched. Thus, resource reservations may be updated before session activation as a response to load pressure in the gNB.

[0299] Figure 8 is a flow chart illustrating sending UE pre-configuration as part of the RRC_Release procedure according to an embodiment which is particularly useful in the third scenario described above.

[0300] In particular, Figure 8 Another alternative for pre-configuring one or more UEs capable of and / or preferably receiving multicast data with low QoS in RRC_INACTIVE or RRC_CONNECTED state is shown. The process shown in this figure corresponds to Fig.13 806 ) after the join request 605 and the 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 as a candidate UE for the NG-RAN node 602 .

[0301] The NG-RAN node 602 may choose to switch the UE group to the RRC_INACTIVE state to control signaling overhead and reduce power consumption. The NG-RAN node (602) may decide to preconfigure the candidate UEs of the group to remain in the RRC_INACTIVE state and receive multicast data.

[0302] In the example, the network 602, 603 decides in 809 that the multicast preconfiguration message sent in 807 and referenced in 1309 may be triggered. The triggering event may be related to the availability of the multicast preconfiguration context at the network and the portfolio of UEs being handed over.

[0303] To this end, the NG-RAN node 602 may use the RRCRelease message with SuspendConfig in 807 and 1309 with modified content. Additional fields related to the multicast preconfiguration context may be included so that the candidate UE 601 makes its transition to the RRC_INACTIVE state 808 and knows that by then the candidate UE is preconfigured to receive multicast data while remaining in the RRC_INACTIVE state. An RRC_INACTIVE reception indicator may be added to the multicast preconfiguration message to inform the preconfigured UE that it is allowed to receive while in the RRC_INACTIVE state. This field is optional and its absence enables the UE to receive multicast data by default when the multicast data arrives at the UE in the RRC_INACTIVE state.

[0304] The NG-RAN node 602 may choose to send the multicast preconfiguration information in a separate multicast preconfiguration message before the RRC Release message. By way of example, the separate message may be sent in an RRC or dedicated SIB container type. In this description, we use the term SIB as a simplification of SIB+MCCH, thereby meaning the use of system information blocks and / or MBS control channel messages. For example, MCCH scheduling information may be provided via a SIB, or alternatively, the entire information may be contained in the SIB.

[0305] In the fourth scenario, the gNB may handle the release of the UE and its transition to the RRC_INACTIVE state without modifying the RRCRelease procedure. The paging message issued by the gNB may indicate the possible multicast preconfiguration in the RRC_INACTIVE state to interested UEs.

[0306] The embodiment related to the fourth scenario is Fig. 9 is shown in Fig. 9 is a flow chart illustrating sending UE pre-configuration triggered by a paging message.

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

[0308] The NG-RAN node 602 may decide to reduce the signaling load by sending an RRCRelease message in 907 and switching the UE group to the RRC_INACTIVE state in 908 .

[0309] In order to preconfigure UE 601 to be in RRC_INACTIVE state as in step 1303, the NG-RAN node may send a notification message in 910. The notification of multicast preconfiguration availability may be any one of a paging message, an RRC message, and a system information block (SIB).

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

[0311] exist Fig. 9 In the example, message 910 is illustrated as a paging message (eg, including the TMGI and indication of the MBS session (as described below). Fig.14 (a) Paging in 1405 is used for paging cause of multicast preconfiguration). Paging can be triggered by the network after setting or updating the multicast preconfiguration context.

[0312] The UE 601 in the RRC_INACTIVE state may process the paging message and identify the paging cause in 911. If the UE 601 is subscribed to the MBS multicast session and is interested in retaining the reception of multicast data while in the RRC_INACTIVE state, the PRACH exchange procedure in 912 is initiated by the UE 601 and the NG-RAN node 602. In 912, the UE 601 requests uplink radio resources for L2 / L3 messages. Next, the UE 601 sends a multicast preconfiguration request to the NG-RAN node 602 in 913, which includes the UE identity (e.g., I-RNTI) of the UE 601 in the RRC_INACTIVE state.

[0313] If the UE is suitable for receiving multicast data, the NG-RAN node may (corresponding to the following description) Fig.14The multicast preconfiguration information is sent as a response in 914 of 1406. A rejection message with a rejection cause may be sent to UE 601. In the example, according to the network, UE 601 may not be suitable for receiving in the RRC_INACTIVE state, and therefore, the RRC_INACTIVE reception indicator may be disabled and sent as a rejection cause.

[0314] The cell selection (reselection) in 909 may occur after the UE switches to the RRC_INACTIVE state in 908. In this case, steps 910-914 will be the subject of a message exchange with the new target NG-RAN node 900. The target NG-RAN node may send a notification message in 910. The notification message may be a paging message, a SIB or a dedicated RRC message.

[0315] By way of example, the 910 message may be a group paging message including the TMGI of the MBS session and a paging cause indicating the available multicast preconfiguration at the target NG-RAN node. The UE 601 after the cell reselection in 909 has not yet been identified by the target NG-RAN node 900. After the paging is processed by the UE 601, the PRACH exchange procedure in 912 is then initiated by the UE 601 with the target NG-RAN node (602) to indicate the presence of the UE 601 in the target cell and request radio resources for uplink signaling message exchange. If the UE 601 has joined the MBS session and is interested in receiving multicast data in the RRC_INACTIVE state, the UE 601 may send a multicast preconfiguration request to the target NG-RAN node in 913. The target NG-RAN node then verifies that the UE has joined the MBS session and is able and suitable to receive multicast data in the RRC_INACTIVE state. Next, the target NG-RAN node may send a multicast preconfiguration response to the UE 601 in 914. The target NG-RAN node may reject the request and indicate the reason for the rejection. The rejection reason may be a disabled RRC_INACTIVE reception indicator, which informs the UE that multicast reception is not allowed in the RRC_INACTIVE state.

[0316] The multicast preconfiguration request in 913 may be sent in different container types. In an example, an RRC message with additional fields for preconfiguration purposes (such as an RRCResume request, etc.) may be used. The UE may also request multicast preconfiguration using an on-demand SIB.

[0317] The multicast preconfiguration information in 914 may be sent by the network using different container types. RRC messages such as RRCResume with dedicated multicast preconfiguration, RRCRelease with SuspendConfig, or RRCReconfiguration messages, and the UE then remains in the RRC_INACTIVE state. Otherwise, the on-demand SIB sent by the UE in 913 may trigger a dedicated SIB with the required multicast preconfiguration sent by the network in 914. In the case of a rejection message in 914, the message may be sent via an RRC message, a dedicated SIB, or other container types.

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

[0319] Fig.10a and Fig.10b are flow charts illustrating embodiments particularly applicable to the fifth scenario described above, which illustrate sending UE pre-configuration to a UE in RRC_INACTIVE state and applying enhanced cell reselection processing.

[0320] Fig.10a It is shown that the UE 601 attempts to join a multicast MBS session in 605 while being in the RRC_CONNECTED state 604. Next, in 1006, a multicast MBS session is established between the UE 601, the NG-RAN node 602 and the 5GC 603.

[0321] UE 601 is a candidate UE that may be capable of and / or prefer to receive multicast data with low QoS regardless of being in RRC_INACTIVE or RRC_CONNECTED state.

[0322] like Fig. 9 As in the embodiment of the present invention, the NG-RAN node 602 may choose to switch the UE group to the RRC_INACTIVE state to ease the signaling load and reduce power consumption. Then, an RRCRelease message is sent in 1007, and the UE switches to the RRC_INACTIVE state in 1008.

[0323] The network can be found in (corresponding to the later reference Fig.13 The UE triggers a multicast pre-configuration message in step 1303 of step 1010, wherein the message includes pre-configuration information elements required for receiving multicast data while in RRC_INACTIVE state. The UE applies a cell reselection process in step 1009, which complies with an enhanced cell reselection process with an additional reselection request message.

[0324] In the standard cell reselection process, 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 where the UE is camping, i.e., the source cell), the UE changes to a new cell (the target cell).

[0325] In the enhanced cell reselection procedure, when the UE selects the new cell as the best candidate, the UE sends a reselection request message to the source gNB (old cell) before changing cells. The reselection request message includes the target cell identity. 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.

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

[0327] As a result of the enhanced cell reselection process, the gNB is aware of the RRC_INACTIVE UEs in the cell, which have the latest system information and can therefore skip the paging, PRACH and (pre)configuration request steps. Further details of the enhanced cell reselection process can be found in UK patent application GB2205138.7.

[0328] For example, the multicast preconfiguration context may include an MRB2 context, a multicast configuration ID, an associated G-RNTI, a DRX configuration, and a neighboring multicast preconfiguration. The triggering event may depend on the network establishment of the multicast preconfiguration context or a set of UEs (601). By way of example, the network may select a UE candidate group to receive while in an RRC_INACTIVE state, and thus the selection triggers a multicast preconfiguration message. The multicast preconfiguration information in 1010 may use different container types. For example, an RRC message may be suitable for carrying multicast preconfiguration information, in particular, an RRCReconfiguration or an RRCRelease message with SuspendConfig may be adopted together with an additional field for locating the multicast preconfiguration context. The network may adopt other alternatives, and by way of example, a multicast preconfiguration context may be sent in a dedicated SIB to preconfigure UE 601 or a UE group for shared delivery.

[0329] exist Fig.10b Enhanced cell selection (reselection) is considered in the process where the UE (601) is in RRC_INACTIVE state 1008. Process 1009 is similar to Fig. 9 Slightly different, in Fig. 9Simple cell reselection 909 is applied without informing the NG-RAN node 602. Subsequently, once the UE 601 receives a notification (paging in 910) from the network, the UE 601 must request multicast preconfiguration in 913.

[0330] In the enhanced cell reselection process in 1009, the UE 601 informs the target NG-RAN node 900 of its arrival. After this, as an example, UE contexts including UE capabilities and / or preferences may be exchanged between the source NG-RAN node and the target NG-RAN node 900. In 1009, the UE 601 may simply send its capabilities and / or preferences and the relevant G-RNTI to the target NG-RAN node. Therefore, the target NG-RAN node may not require a previous exchange of UE contexts.

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

[0332] 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 request a 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 a RRCResume request message.

[0333] The target gNB in ​​900 that receives the message in 1012 may proceed to a UE context exchange 1013 with the source gNB 602 and then to admission control 1014 as described in UK patent application GB2205138.7. If the preconfigured UE provides an authorization certificate in the 1012 message, the steps in 1013 and 1014 may be skipped. The certificate 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 in ​​900 may then skip steps 1013 and 1014 and may send reselection feedback in step 1015. The G-RNTI information may be associated with the MBS session ID, multicast configuration ID and / or cell ID in the 1012 message. The message may inform the target gNB whether the UE (601) is allowed to receive multicast data. In addition, the message may indicate whether the UE has authorization to receive multicast data for the corresponding MBS session in the RRC_INACTIVE state.

[0334] The message 1015 may include a multicast (pre)configuration for the UE or a simple rejection in the absence of an available grant. The message container 1015 may be a RRCRelease with Suspendconfig including the configuration. A SIB message may also be used.

[0335] Embodiments are now described which describe how pre-configuration information received at a UE according to any of the embodiments described herein may be used to configure the UE after session activation.

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

[0337] Fig.11 is a flow chart illustrating the use of pre-configuration by a UE after a session is activated according to an embodiment.

[0338] UE 601 is in RRC_INACTIVE state 1102. Upon MBS session activation in 1104 and 1310, the first multicast data arrives at NG-RAN node 602 in 1105 and triggers a notification message. The notification message in 1106 may be a group paging message, a SIB, or a dedicated RRC message. In this embodiment, and by way of example, the message in 1106 is a group paging message destined for 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 of the corresponding MBS session as in 1408.

[0339] The UE 601 processes the paging message in 1107 (and 1409) and the UE 601 may apply the multicast preconfiguration that has been previously sent by the network 602, 603. The PRACH exchange procedure in 1108 is initiated by the UE 601 with the NG-RAN node 602, which allows requesting uplink radio resources for future signaling message exchanges with the NG-RAN node.

[0340] The steps in 1109 and 1113 depend on the state of UE 601 in 1107. UE 601 may have been previously preconfigured by the NG-RAN node, or may request preconfiguration or receive in RRC_INACTIVE state. The following example sets out possible messages to be carried in steps 1109 and 1113 according to an embodiment.

[0341] In a first example, UE 601 may send a multicast reception request 1109 to the network. This is intended to inform the network of the presence of UE 601 and that UE 601 is willing to receive multicast data in the RRC_INACTIVE state. The network 602, 603 processes the request 1109 in 1110 to send the multicast data using the MRB2 radio bearer. The request in 1109 may include the MBS session ID, the multicast preconfiguration ID, and the G-RNTI, and the network may then verify whether UE 601 has authorization to receive multicast data and / or is in the RRC_INACTIVE state. Thereafter, the multicast data sent in 1111 may be sent to the UE (601) or a candidate UE group in the RRC_INACTIVE state.

[0342] In a second example, the NG-RAN node 602 may send multicast data using the multicast preconfiguration previously exchanged with the UE 601. The multicast data in 1112 is then received while processing the paging phase in 1107. Later, a feedback message in 1109 may be sent to inform the NG-RAN node that reception is taking place in the RRC_INACTIVE state, so the NG-RAN node is informed and may continue to multicast data in the RRC_INACTIVE state. The feedback message in 1109 may allow the gNB in ​​602 to estimate the number of UEs receiving in the RRC_INACTIVE state.

[0343] In the third example, the UE 601 has not been preconfigured to receive in the RRC_INACTIVE state. Therefore, the paging message in 1106 indicates that the MBS session is activated so far. Next, the UE 601 processes the paging in 1107 and may require to be configured to receive multicast data in the RRC_INACTIVE state. Therefore, the UE 601 sends a multicast request in 1109 after interacting with the NG-RAN node 602 in the PRACH procedure 1108. The message in 1109 may request a multicast configuration to receive in the RRC_INACTIVE state. The request in 1109 may include the MBS session ID, the multicast preconfiguration ID and the G-RNTI, and the network may then verify whether the UE 601 has authorization to receive multicast data and / or is in the RRC_INACTIVE state. The network 602, 603 processes the request in 1110 and responds with a multicast configuration in 1113 sent back to the UE 601. If authorization is not provided, the network may reject the UE's request.

[0344] At session activation 1104, 1310, the gNB may have pre-configured its UEs and needs to notify the UEs of the session activation in 1106 and 1315. The gNB may send the configuration to the unconfigured UE in RRC_INACTIVE state as in 1317 and 1113. The gNB may need to update or build the configuration in 1312. The configuration is then sent to the UE in RRC_INACTIVE state as in 1113 and 1314.

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

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

[0347] In a first example, consider that UE 601 has been preconfigured in 1107 to receive multicast data in the target cell. After the PRACH procedure in 1108, UE 601 may send a multicast reception request in 1109 to activate multicast reception in RRC_INACTIVE state at the target NG-RAN node 900 (if not already done). The request in 1109 may include the MBS session ID, the multicast configuration ID and the G-RNTI, and the network may then verify whether UE 601 has authorization to receive multicast data and / or is in RRC_INACTIVE state. After processing the request 1109 in the network in 1110, the target NG-RAN node 900 may redirect the multicast data for UE 601 or a candidate UE group capable of receiving multicast data in RRC_INACTIVE state in 1111.

[0348] In a second example, consider again that UE 601 has applied multicast preconfiguration in step 1107 and the target NG-RAN node 900 is sending multicast data 1112 over the MRB2 radio bearer and earlier after the paging message 1106. UE 601 may interact with the target NG-RAN node 900 (PRACH procedure in 1108) and may send a multicast reception confirmation to the target NG-RAN node 900 as feedback in 1109. The target NG-RAN node processes the confirmation in 1110 and is aware of the presence of UEs receiving in RRC_INACTIVE state. The feedback in 1109 may allow the gNB in ​​602 to estimate the number of UEs receiving in RRC_INACTIVE state.

[0349] In a third example, the UE 601 may request a multicast configuration for reception in the RRC_INACTIVE state in a message 1109. The message in 1109 may include an MBS session ID, a multicast configuration ID, and a G-RNTI, and the network may then verify whether the UE 601 has authorization to receive multicast data and / or is in the RRC_INACTIVE state. The target NG-RAN node 900 may process the request in 1110, and the target NG-RAN node 900 may then send multicast configuration information 1113 dedicated to RRC_INACTIVE multicast reception (if available). After configuring the UE 601 for reception in the RRC_INACTIVE state, the target NG-RAN node sends the multicast data as in 1111. The target NG-RAN node 900 may send a rejection response to the UE 601, so that no possible reception occurs in the RRC_INACTIVE state.

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

[0351] In 1109, the RRC message may be a RRC Resume Request, wherein the message includes additional fields depending on the different scenarios detailed above. The additional fields may indicate different causes as follows:

[0352] - Multicast reception request to activate multicast data transmission in RRC_INACTIVE state,

[0353] -Multicast feedback reception, to confirm the presence of UEs receiving multicast data reception in RRC_INACTIVE state,

[0354] - A multicast configuration request may be inserted in additional fields.

[0355] On-demand SIB may also be employed and may take different aspects depending on the UE (601) request listed here.

[0356] The message in 1113 is provided by the network 602, 603 and may be sent via an RRC message such as an RRCResume response or an RRCRelease or RRCReconfiguration message with SuspendConfig. A dedicated SIB may carry the network response. Other container types not referenced here may be used.

[0357] The additional fields carried in the 1113 message may include multicast configuration information received in the RRC_INACTIVE state as a response to the multicast configuration request in 1109. A rejection of the configuration request may be included.

[0358] Different container types including RRC or SIB messages are exchanged in the context of the RRC_INACTIVE state without transitioning to the RRC_CONNECTED state. An additional field type may identify the cause of the message, which is then processed accordingly while remaining in the RRC_INACTIVE state.

[0359] In another implementation, when the MBS session is activated, the first multicast data arriving at the network from the application server may trigger an MBS activation message sent by the network to inform the UE of the session activation. The UE may apply the multicast pre-configuration and then receive the multicast data.

[0360] Fig.12 is a flow chart illustrating use of multicast pre-configuration information by a UE after a session is activated according to an embodiment.

[0361] UE 601 is in RRC_INACTIVE state 1102. It is assumed that the UE is preconfigured to receive multicast data in the RRC_INACTIVE state thereafter. After the MBS session activation in 1104, the multicast data in 1105 triggers MBS activation messages 1202, 1408, which are sent to candidate UEs that are capable and preconfigured to receive multicast data in the RRC_INACTIVE state. The MBS activation message 1202 can use an RRC container, such as a paging message or SIB with a paging cause indicating session activation. The message in 1202 can be associated with a multicast configuration update. Therefore, the 1202 message can include an updated multicast configuration for UE 601 to receive in the RRC_INACTIVE state. The multicast configuration update in 1202 is sent via an RRC message.

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

[0363] At multicast session activation 1104, 1310, the gNB may have pre-configured its UEs and needs to notify the UEs of the multicast session activation as in 1202 and 1315. As in 1317 and 1204, the gNB may send the configuration to the unconfigured UEs in RRC_INACTIVE state. As in 1312, the gNB may need to update or build the configuration, which will be discussed below with respect to Fig.13 Then, as in Fig.12 1204 and Fig.13 As in 1314 of , the configuration is sent to the UE in RRC_INACTIVE state.

[0364] As shown in this scenario, the UE 601 may perform enhanced cell selection (reselection) in 1201. In 1201, the enhanced cell selection (reselection) may involve the NG-RAN nodes 602, 900 in a UE context exchange. In 1201, the UE 601 informs the target NG-RAN node 900 of its presence. As previously described, as an example, the target NG-RAN node may exchange a UE context with the source NG-RAN node, the UE context including UE capabilities and / or preferences for receiving in 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 NG-RAN nodes.

[0365] In addition, UE 601 may send additional information related to the multicast configuration ID and / or G-RNTI to the target gNB in ​​900 during the enhanced cell reselection procedure 1201. The network may then verify the UE authorization regarding the reception of the multicast data and / or being in RRC_INACTIVE state.

[0366] In case the source NG-RAN node has already preconfigured UE 601 for a neighbor cell to receive multicast data in RRC_INACTIVE, the target NG-RAN node is aware of the preconfiguration and will not continue to preconfigure UE 601.

[0367] In the case that the UE has to be pre-configured in the target cell, the target NG-RAN node 900 sends its appropriate multicast pre-configuration information in 1201 or thereafter.

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

[0369] Receiving multicast data in RRC_INACTIVE state can offload the gNB (in other words, the gNB will have less load to handle since the UE is in RRC_INACTIVE state) and can facilitate additional UEs to join the MBS session. Therefore, according to an embodiment, it is beneficial to consider the following for a multicast session. The UE can stay in RRC_INACTIVE state in the following cases:

[0370] - upon MBS session activation, the UE may apply its (pre-)configuration to receive data while staying in the RRC_INACTIVE state,

[0371] - Upon MBS deactivation, the UE may stop receiving multicast data, however, the session may be reactivated and may receive multicast data later.

[0372] When the MBS session is released, the network will not send multicast data, so the UE should return to the RRC_CONNECTED state to release the radio resources used to receive multicast data.

[0373] Fig.13 is a flowchart illustrating processing performed by gNB 110 or 111 according to an embodiment. Fig.13 The processing can be applied to each embodiment described above. For example, Figures 6 to 12 For example, the execution may be performed by Figure 3 The CPU 315 of the base station shown in FIG.

[0374] At step 1300, the gNB receives a UE join request 507, 605, such as described previously. Figure 5a and Figure 6UE join request described. 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 for the same multicast session will not trigger a new multicast session establishment 523, 606 process, however the core network may update the multicast session QoS requirements, for example to globally manage the load in the system.

[0375] Then in step 1301 the gNB may decide to make a radio resource reservation to reserve resources for sending multicast data to the UEs belonging to its cell. Since the multicast data is not yet available, resource reservation is not mandatory at this step, which becomes available later at the session activation step 524. Some gNBs may decide to wait for resource reservation until the multicast data is available, to make the radio resources available for other applications when the multicast session is inactive. As mentioned before, there is a risk that the gNB may be overloaded when all involved UEs need to be configured with simultaneously allocated radio resources. Another risk is the failure of resource allocation, because another application may acquire these resources earlier.

[0376] Therefore, according to an embodiment, the gNB will not wait for session activation 524 to make radio resource reservations, the gNB will make resource reservations when the number of UEs involved (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". The threshold represents the individual gNB capabilities of handling large groups of UEs configured simultaneously.

[0377] To manage UE configuration, the gNB maintains in its memory 325 a set of UE identifier lists for each multicast session:

[0378] - "unconfigured_connected_ue": a UE in RRC_CONNECTED state making a join request,

[0379] - "unconfigured_inactive_ue": a UE in RRC_INACTIVE state making a join request,

[0380] - "pre-configured_connected_ue": a UE in RRC_CONNECTED state that has received a pre-configuration information element and made a join request,

[0381] - "pre-configured_inactive_ue": a UE in RRC_INACTIVE state that has received a pre-configuration information element and made a join request,

[0382] - "configured_connected_ue": a UE in RRC_CONNECTED state that has received a configuration information element and made a join request,

[0383] - "configured_inactive_ue": a UE in RRC_INACTIVE state making a join request that received a configuration information element.

[0384] The identifier of each UE making a join request is stored in the list "unconfigured_connected_ue".

[0385] If the core network sends updated QoS requirements, the gNB will update the UE list, since all previously provisioned or configured UEs require updated configuration information:

[0386] - All UE identifiers in "pre-configured_connected_ue" and "configured_connected_ue" are removed from the list and added to "unconfigured_connected_ue".

[0387] - All UE identifiers in "pre-configured_inactive_ue" and "configured_inactive_ue" are removed from the list and added to "unconfigured_inactive_ue".

[0388] Based on the radio resource reservation, the gNB can construct a multicast pre-configuration information element. The multicast (pre)configuration information element can consider different information elements, including but not limited to:

[0389] - a multicast radio bearer "MRB2" configuration dedicated to receiving multicast data with low QoS for candidate UEs, or a "MRB1" configuration primarily for UEs in RRC_CONNECTED state with high QoS,

[0390] -RRC_INACTIVE reception indication, where the gNB indicates to the UE whether to enable the UE to 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,

[0391] - A G-RNTI identifying a group of UEs in the same cell that are interested in receiving multicast data,

[0392] - a multicast pre-configuration ID related to the configuration applied for the UE and associated with the MBS session ID (e.g. TMGI),

[0393] - a discontinuous reception (DRX) configuration for receiving multicast data for the candidate UE,

[0394] - Neighborhood multicast configuration applied when a candidate UE performs handover or cell reselection,

[0395] - Cell ID(s) identifying the cell(s) to which the preconfiguration should apply.

[0396] At step 1302, the gNB sequentially sends the pre-configuration information element to all UEs in the "unconfigured_connected_ue" list. The multicast pre-configuration information element may be sent in an RRC configuration message (e.g., Figure 6 ). The UE identifier is removed from the “unconfigured_connected_ue” list and added to the “pre-configured_connected_ue” list.

[0397] At step 1303, the gNB sends a pre-configuration information element (e.g., Fig. 9 ). The gNB sends a paging message 910 to all UEs in the "unconfigured_innactive_ue" and waits for a PRACH procedure 912 from the UEs in the list that are still in the gNB's cell (some RRC_IACTIVE UEs may have moved to another cell). Once the PRACH procedure is in progress, the gNB receives a Multicast Preconfiguration Request message 913 from the UEs that are in progress. The gNB sends a Multicast Preconfiguration Response message 914 with a Multicast Preconfiguration Information element to these UEs. In an alternative embodiment (e.g., Fig.10a and Fig.10b ), the UE applies enhanced cell reselection processing, similar to what has been described previously, 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 the gNB is aware of the RRC_INACTIVE UEs in the cell. These UEs have the latest system information and can skip paging, PRACH and pre-configuration requests.

[0398] The UE identifier is removed from the “unconfigured_inactive_ue” list and added to the “pre-configured_inactive_ue” list.

[0399] At step 1304, the gNB checks its request to become a target gNB for handover of the UE with respect to the source gNB. In the handover process, the source gNB requests to transfer the management of the UE to the target gNB. Figure 7 An example of handover is described in . The target gNB knows whether the UE joined the multicast session earlier, which information is part of the handover information provided by the source gNB.

[0400] In step 1305, the target gNB checks whether it has 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.

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

[0402] During step 1307, the gNB may decide to switch some UEs from RRC_CONNECTED state to RRC_INACTIVE state. The goal is to reduce the load on the gNB as described in RP-213568. This is Figure 8 Example implementations of the embodiments described in .

[0403] During step 1308, the gNB checks if it has reserved radio resources for the multicast session. If not, the multicast preconfiguration information element is not ready and the UE identifier corresponding to the UE that is to change the RRC state and has joined the multicast session is removed from the "unconfigured_connected_ue" list and added to the "unconfigured_inactive_ue".

[0404] If a multicast preconfiguration information element is available, the gNB sends a multicast preconfiguration information element to the UE in a RRCRelease message with SuspendConfig 807 during step 1309. To this end, the NG-RAN node 602 may use the RRCRelease message with SuspendConfig in 807 with modified content. Additional fields related to the multicast preconfiguration context (information element) may be included, so that the candidate UE 601 makes its transition to the RRC_INACTIVE state 808 and knows that by then, it is preconfigured to receive multicast data while remaining in the RRC_INACTIVE state.

[0405] The gNB loops back to step 1300 until the multicast session is activated and then moves to step 1310.

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

[0407] Then, during step 1311, the gNB checks if the multicast preconfiguration information element is ready.

[0408] If the multicast preconfiguration element is not ready or if the QoS flow information is updated, the gNB updates or makes radio resource reservation and the gNB creates or updates the preconfiguration information element at step 1312. The gNB then converts the multicast preconfiguration information element to a multicast configuration information element (as described in TS 38.331).

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

[0410] Then, during step 1314 (e.g., Fig.11), the gNB sends a paging message with the paging cause set to "MBS session activation" (as recommended in TR23.700-47). Then, the UE present in the cell, in RRC_INACTIVE state and having joined the multicast session will perform a PRACH procedure to update its system information, and then the UE will send a multicast MBS configuration request message (MBSConfigurationRequest or MBSConfigurationRequest1). The MBS configuration request message can be a new RRC message or an RRCResumeRequest message or a system information block (SIB) reception request. The multicast MBS configuration request message may include an identifier (e.g., MBS session ID and / or temporary mobile group identity (TMGI)) for identifying the activated multicast session. In other words, an identifier for indicating the MBS session for which the configuration is requested. In addition, the multicast MBS configuration request message may include UE identity information (such as IMSI, IMEI) for identifying UE 101 and / or authentication information (ueMAC-I) (such as an authentication token) for authenticating UE 101. Upon receiving the multicast MBS configuration request message, the gNB will send an MBS configuration message (MBSConfiguration) with a multicast configuration information element to the UE. The MBS configuration request message may include collecting or obtaining necessary information to construct a UE configuration for at least one UE so that the at least one UE can receive multicast data for the activated multicast session. Once the UE configuration is known (including the step of radio access network (RAN) resource reservation), the base station or gNB 111 sends a multicast MBS configuration message to the at least one UE. The multicast MBS configuration message includes configuration information for configuring the at least one UE to receive multicast data in a non-connected RRC state (such as RRC_INACTIVE state) for the activated multicast session. In an example, the configuration information includes configuration information of at least one multicast radio bearer (MRB) (e.g., configuration of at least one MRB to be used by the gNB 111 and the at least one UE 101 to communicate multicast data for the activated multicast session). Note that one or more MRBs can be associated with one MBS session. The MRB configuration information may include Packet Data Convergence Protocol (PDCP) and Service Data Adaptation Protocol (SDAP) setting information.

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

[0412] Further details of the multicast configuration request message and the multicast MBS configuration message can be found in UK patent application GB2210307.1. In an alternative embodiment, the UE applies the enhanced cell reselection process as described above, so the gNB is aware of the RRC_INACTIVE UEs in the cell, which have the latest system information and can skip paging, PRACH and pre-configuration requests.

[0413] Each time a 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” and “pre-configured_inactive_ue” lists (if present).

[0414] Returning to step 1311, if the multicast configuration information element is ready and the QoS flow information has not changed, during step 1315, the gNB sends a paging message with the paging cause set to "apply preconfiguration" to all UE identifiers present in the "pre-configured_connected_ue" and "pre-configured_inactive_ue" lists. Thus, all UEs that have previously received the multicast preconfiguration information element will be able to apply the configuration and receive multicast data. All UE identifiers are then 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".

[0415] The gNB shall then configure the UEs to remain unconfigured as reflected in “unconfigured_inactive_ue” and “unconfigured_connected_ue”. The gNB converts the multicast preconfiguration information element into a multicast configuration information element.

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

[0417] The gNB then sends a paging message with the paging cause set to "MBS session activation" during step 1317 (as recommended in TR 23.700-47). UEs present in the cell that are in RRC_INACTIVE state and have joined the multicast session and do not have a pre-configuration information element will then undergo a PRACH procedure to update their system information, the UE will then send a multicast configuration request message (MBSConfigurationRequest or MBSConfigurationRequest1) and the gNB will send 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 as previously described herein and in UK patent application GB2210307.1. In an alternative embodiment, the UE applies a cell reselection process that complies with the enhanced cell reselection process already described above, so that the gNB is aware of the RRC_INACTIVE UEs in the cell that have the latest system information and can skip paging, PRACH and pre-configuration requests.

[0418] Each time a 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.

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

[0420] Fig.14 is a flow chart showing the processing performed by UE 101 according to an embodiment. Fig.13 , Fig.14 The processing shown in the flowchart of can be applied to each embodiment described above. Figures 6 to 12 For example, the execution may be performed by the CPU 215.

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

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

[0423] If the UE is still in the RRC_CONNECTED state, test 1402 indicates no offloading.

[0424] If the UE is now in the RRC_INACTIVE state after receiving the standard RRCRelease message or the modified RRCRelease message, test 1402 indicates uninstallation.

[0425] If the UE is in the RRC_INACTIVE state (1402 indicates yes), then during step 1403, the UE waits to receive a multicast pre-configuration message from the gNB. At step 1303 (e.g., Fig. 9 ), the gNB may send a multicast preconfiguration message. At step 1303, the gNB sends a paging message 910 with a multicast preconfiguration cause, and then 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.10a and Fig.10b ), the UE applies the cell reselection process consistent with the enhanced cell reselection process already described above, so the gNB is aware of the RRC_INACTIVE UEs in the cell, which have the latest system information and can skip paging, PRACH and pre-configuration requests.

[0426] When the UE is in the RRC_INACTIVE state, the UE loops back to step 1403 until the multicast (MBS) session is activated at step 1404. When the multicast session is activated in 1404, the UE may or may not have the multicast session pre-configuration information element stored in the memory 225.

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

[0428] If the UE does not have a stored pre-configuration, the UE loops back to step 1405 .

[0429] Returning to step 1405, if the received paging message does not include an "application pre-configuration" paging cause, then during a test 1408 the UE checks for an "MBS session activation" paging cause.

[0430] If the "MBS session activation" paging cause is not included in the paging message, the UE loops back to step 1405, thereby waiting for a new paging message.

[0431] If the "MBS session activation" paging cause is included, the UE shall request a multicast configuration information element from the gNB during step 1409, even if the UE has already obtained the stored pre-configuration (the configuration has been updated on the gNB side and the pre-configuration stored by the UE is outdated).

[0432] gNB in ​​(with Fig.11 Correspondingly) the "MBS Session Activation" paging cause is sent at step 1314 or 1317, and the gNB sends a paging message with the paging cause set to "MBS Session Activation" (as recommended in TR23.700-47). The UE then performs a PRACH procedure to update its system information, and the UE will then send a multicast configuration request message (MBSConfigurationRequest or MBSConfigurationRequest1), and the gNB will send 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 as previously described herein and in UK patent application GB2210307.1. In an alternative embodiment, the UE applies a cell reselection process that conforms to the enhanced cell reselection process already described above, so that the gNB is aware of the RRC_INACTIVE UEs in the cell, which have the latest system information and can skip paging, PRACH and pre-configuration requests.

[0433] Once the UE receives the MBS configuration message, the UE applies the configuration and is ready to receive multicast data.

[0434] The RRC_INACTIVE section ends here. Return to the RRC_CONNECTED section (for the condition tested in 1402 is "No").

[0435] When the UE is in the RRC_CONNECTED state, the UE loops back to step 1401 until the MBS session is activated at step 1410. When the multicast session is activated in 1410, the UE may or may not have the multicast session pre-configuration information element stored in the memory 225.

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

[0437] If the UE does not have the stored pre-configuration, the UE loops back to 1411.

[0438] At 1411, if the received paging does not include an "apply preconfiguration" paging cause, then during test 1414, the UE checks for receipt of a standard RRCReconfiguration message from the gNB.

[0439] If the RRCReconfiguration message is not received, the UE loops back to step 1411 to wait for a new paging or RRC message.

[0440] If an RRCReconfiguration message is received, during step 1415 the UE shall apply the received configuration even if the UE has already obtained the stored preconfiguration (the configuration has been updated on the gNB side and the preconfiguration stored by the UE is outdated).

[0441] The gNB sends an RRCReconfiguration message at step 1316 or 1313.

[0442] Now refer to Fig.17 and Fig.18 An update of the configuration process according to an embodiment of the present invention is described. Fig.17 is a flow chart illustrating a configuration update initiated by the network for a UE in RRC_INACTIVE state according to an embodiment.

[0443] Fig.17UE 601 is shown joining a multicast MBS session in 605 while in RRC_CONNECTED state 604 (eg Figure 6 As shown), and the UE has been switched to RRC_INACTIVE state by the network at step 1701.

[0444] UE 601 continuously performs a cell reselection process 1702 to search for the best cell to camp on. While moving, the UE may have switched cells several times because it is in the RRC_INACTIVE state. Note that the cell reselection processes 1702, 1802 represent Fig.17 and Fig.18 Optional steps in the illustrated methods (as indicated by 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.

[0445] At the same time, a multicast MBS session has been activated and the NG-RAN node 1700 is transmitting multicast data 1704 in the cell where the UE 601 is now camping. Fig. 9 According to the method of receiving (pre) configuration information before MBS session activation, or any other aforementioned embodiment of receiving (pre) configuration information before MBS session activation, the multicast configuration capable of receiving multicast data in the cell has been obtained before the MBS session is activated. Alternatively, the initial configuration information obtained by the UE 601 may have been received after the MBS session is activated (for example, using Figure 5a and Figure 5b The NG-RAN node 1700 controlling the cell in which the UE 601 is camping may not be aware of the presence of the UE 601 in the cell controlled by the NG-RAN node 1700.

[0446] In the case where the NG-RAN node 1700 has detected that the multicast configuration needs to be modified to receive multicast data in the cell(s) it controls in the MBS service area, or if the NG-RAN node 1700 has been notified of the modification of the multicast configuration in the cell(s) controlled by another NG-RAN node, the NG-RAN node 1700 may initiate an update of the multicast configuration for UEs interested in receiving the corresponding MBS session. For UEs in the RRC_CONNECTED state, the NG-RAN 1700 will use the RRCReconfiguration message to provide the update. For UEs in the 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. The 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).

[0447] UE 601, having received notification 1705, will process the provided information at step 1703. If the multicast session ID corresponds to a session in which UE 601 is interested, UE 601 performs a PRACH exchange procedure 1706 with NG-RAN node 1700. In 1706, UE 601 communicates its UE identity with the NG-RAN node and requests uplink radio resources for L2 / L3 messages and RRC connection messages. Next, UE 601 sends a multicast configuration request message 1707 to NG-RAN node 1700. Message 1707 may be an RRC resume request (specified in TS 38.331), which includes the multicast session ID and indicates a request for receiving (one or more) multicast configurations. The message also includes the identity of the UE in RRC_INACTIVE state (i.e., I-RNTI) and the identity of the NG-RAN node that sets UE 601 in RRC_INACTIVE state and allocates the I-RNTI to UE 601.

[0448] The NG-RAN node 1700 verifies that the UE has joined the MBS session and that it is authorized to receive the associated multicast data. To this end, the NG-RAN node 1700 will perform a UE context exchange procedure 1711 with the NG-RAN that sets the UE 601 to the RRC_INACTIVE state to retrieve the context of the UE 601. The NG-RAN node 1700 then performs an admission control step 1712 based on the received UE context to verify that the UE 601 is allowed to receive the multicast data. If the request of the UE 601 is accepted, the NG-RAN node sends (one or more) multicast configurations to the UE 601 in a message 1708. The target NG-RAN node may reject the request, indicating the reason for the rejection.

[0449] The multicast configuration message 1708 may be an RRC release message with SuspendConfig (as specified in TS 38.331) and contain one or more multicast configurations to be used in one or more cells in the neighborhood. The multicast configuration may be identified by a multicast configuration ID. The mapping between the multicast configuration ID and the cell identities to which the multicast configuration may be applied should be provided to the UE.

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

[0451] exist Fig.17 During all the processes depicted above, UE 601 may remain in the RRC_INACTIVE state and may continue to receive multicast data.

[0452] Fig.18 is a flow chart illustrating sending a configuration requested by a UE in RRC_INACTIVE state according to an embodiment.

[0453] Fig.18 It is shown that UE 601 joins the multicast MBS session in 605 while in RRC_CONNECTED state 604 , and the UE has been switched to RRC_INACTIVE state by the network at step 1801 .

[0454] The UE 601 continuously performs a cell reselection process 1802 to search for the best cell to camp on. While moving, the UE may have switched cells several times because it is in the RRC_INACTIVE state.

[0455] At the same time, a multicast MBS session has been activated and the NG-RAN node 1800 is transmitting multicast data 1804 in the cell where the UE 601 now resides. Fig. 9 According to the method of receiving (pre) configuration information before MBS session activation, or any other aforementioned embodiment of receiving (pre) configuration information before MBS session activation, a multicast configuration capable of receiving multicast data in the cell has been obtained before MBS session activation. The NG-RAN node 1800 controlling the cell in which the UE 601 is camping may not be aware of the presence of the UE 601 in the cell controlled by the NG-RAN node 1800.

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

[0457] 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 communicates its UE identity with the NG-RAN node and requests uplink radio resources for L2 / L3 messages and RRC connection messages. Next, the UE 601 sends a multicast configuration request message 1807 to the NG-RAN node 1800. The message 1807 may be an RRC resume request (specified in TS 38.331) that includes the multicast session ID and indicates a request to receive the multicast configuration(s), and indicates the identity of the cell(s) for which the multicast configuration(s) are requested. The message also includes the identity of the UE in the RRC_INACTIVE state (ie, the I-RNTI) and the identity of the NG-RAN node that sets the UE 601 in the RRC_INACTIVE state and allocates the I-RNTI to the UE 601.

[0458] The NG-RAN node 1800 verifies that the UE has joined the MBS session and that it is authorized to receive the associated multicast data. To this end, the NG-RAN node 1800 will perform a UE context exchange procedure 1811 with the NG-RAN that sets the UE 601 in the RRC_INACTIVE state to retrieve the context of the UE 601. The NG-RAN node 1800 then performs an admission control step 1812 based on the received UE context to verify that the UE 601 is allowed to receive the multicast data. If the request of the UE 601 is accepted, the NG-RAN node sends the requested (one or more) multicast configurations to the UE 601 in a message 1808. The target NG-RAN node may reject the request, indicating the reason for the rejection.

[0459] If the NG-RAN node 1800 does not have the multicast configuration, the NG-RAN node 1800 may request the multicast configuration from the NG-RAN node(s) controlling the cell(s) for which the UE 601 requests the multicast configuration. Such information may be provided by exchanging Xn protocol messages.

[0460] The multicast configuration message 1808 may be an RRC Release message with SuspendConfig (specified in TS 38.331) and contain the requested (one or more) multicast configurations (at least for the multicast configurations known at the NG-RAN node 1800).

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

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

[0463] Now refer to Fig.19 and Fig. 20 Description (e.g., according to Fig.17 and Fig.18 An example method of controlling a UE (e.g., 601) and / or a base station (e.g., NG-RAN 1700, 1800) of a wireless network is provided. Fig.19 1900 is a flowchart performed at a UE according to an embodiment of the present invention. Fig. 20A flow chart 2000 is shown with steps performed at a base station. Fig.19 and Fig. 20 In the various methods shown in , the UE has previously received (initial or old) multicast data corresponding to the activated multicast session, but subsequent changes to the network mean that the UE's (e.g., initial or previous) multicast configuration needs to be modified (e.g., based on multicast configuration information that the UE has previously obtained). The initial multicast configuration may be when the UE is in the RRC_CONNECTED state (e.g., Figure 6 and Figure 7 ) or when the UE is in the RRC_INACTIVE state (as shown Figure 8 and Fig. 9 Alternatively, the previous configuration may be obtained while the UE is in RRC_INACTIVE (as shown). Fig.10a , Fig.10b and Fig.11 ) and is obtained after the session is established.

[0464] At step 1901, the UE is in a non-connected RRC state (e.g., RRC_INACTIVE) and sends a request for (updated or new) multicast configuration information of an activated multicast session to a base station. At step 2001, the base station receives a request for (updated or new) multicast configuration information from a UE in a non-connected RRC state (e.g., Fig.17 and Fig.18 At step 2202, the base station sends the (updated or new) multicast configuration information received by the UE at step 1902 (e.g., as shown in steps 1707 and 1807 of FIG. 1707 ). Fig.17 and Fig.18 In step 1903, the UE is configured according to the (updated) multicast configuration information received from the base station. Advantageously, the method provides the UE with updated multicast configuration information (e.g., after a cell reselection process), which enables the UE to continue receiving multicast data from the activated multicast session while always remaining in a non-connected RRC state.

[0465] The following sections and clauses with reference to TS 38.331 Version 17.0.0 provide details of an example procedure for configuring a UE for multicast reception.MBPreConfiguration corresponds to the multicast (MBS) pre-configuration information discussed above.

[0466] The purpose of this procedure is to allow pre-configuration data to be sent to the UE before session activation, which pre-configuration data can be used to subsequently configure the UE to receive multicast data from base stations in the network. The pre-configuration, multicast reception procedures and multicast reception request procedures are described below and should have certain numbers later, when they are each referred to by the number 5.3.X. The implementation of the MBSConfigurationRequest, MBSConfigurationRequest1 and MBSConfiguration request messages mentioned in some of the above embodiments is described in detail below.

[0467] 5.3.2.3 UE Reception of Paging Message

[0468] 1> For each TMGI included in the pagingGroupList (if any) included in the paging message:

[0469] 2> If the UE has joined the MBS session indicated by the TMGI included in the pagingGroupList:

[0470] 3>Forward TMGI to the upper layer;

[0471] 1> if in RRC_INACTIVE and the UE has joined one or more MBS sessions indicated by the TMGI included in pagingGroupList; and

[0472] 1> If none of the ue-Identities included in any PagingRecord (if included in the paging message) matches the UE identity assigned by the upper layer:

[0473] 2> If MBS_session activation is included in the paging cause

[0474] 3> Initiate RRC_INACTIVE multicast reception process according to 5.3.X (for example, as referenced Figures 6 to 10b and / or discussed below in the discussion of example procedures for configuring a UE for multicast reception with reference to sections and clauses of TS 38.331 Version 17.0.0)

[0475] 2> Otherwise, initiate the RRC connection recovery process according to 5.3.13, where resumeCause is set as follows:

[0476] 3> If the UE is configured with access identification 1 by the upper layer:

[0477] 4>resumeCause is set to mps-PriorityAccess;

[0478] 3> Otherwise, if the UE is configured with access identifier 2 by upper layers:

[0479] 4>resumeCause is set to mcs-PriorityAccess;

[0480] 3> Otherwise, if the UE is configured by upper layers with one or more access identifiers equal to 11-15:

[0481] resumeCause is set to highPriorityAccess;

[0482] 3> Otherwise:

[0483] 4>resumeCause is set to mt-Access.

[0484] 2> If multicast provisioning is included in the paging reason

[0485] 2>Initiate RRC_INACTIVE pre-configuration request

[0486] 2> Otherwise, initiate the RRC connection recovery process according to 5.3.13, where resumeCause is set as follows:

[0487] 3> If the UE is configured with access identification 1 by the upper layer:

[0488] 4>resumeCause is set to mps-PriorityAccess;

[0489] 3> Otherwise, if the UE is configured with access identifier 2 by upper layers:

[0490] 4>resumeCause is set to mcs-PriorityAccess;

[0491] 3> Otherwise, if the UE is configured by upper layers with one or more access identifiers equal to 11-15:

[0492] resumeCause is set to highPriorityAccess;

[0493] 3> Otherwise:

[0494] 4>resumeCause is set to mt-Access.

[0495] 5.3.X Multicast Pre-configuration Request Process

[0496] 5.3.X.1 Overview

[0497] Figure 5.3. X.1-1 Multicast Preconfiguration Request

[0498] The purpose of this procedure is to set up multicast reception in RRC_INACTIVE state, including (one or more than one) multicast MRBs.

[0499] 5.3.X.2 Initiation

[0500] The UE initiates this procedure when upper layers or the AS (when responding to RAN paging) request to receive multicast in the RRC_INNACTIVE state.

[0501] Before initiating this procedure, the UE shall ensure that it has valid and up-to-date basic system information as specified in clause 5.2.2.2.

[0502] When initiating this procedure, the UE shall:

[0503] 1> If the resumption of the RRC connection is triggered by responding to NG-RAN paging:

[0504] 2> Select "0" as the access category;

[0505] 2> Use the selected access category and one or more access identifiers provided by the upper layer to perform the unified access control process as specified in 5.3.14;

[0506] 3> If the access attempt is prohibited, the process ends;

[0507] 5.3.X.3 Actions related to MBSPreConfigRequest or MBSPreConfigRequest1 message transmission

[0508] The UE shall set the content of the MBSPreConfigRequest message.

[0509] 5.3.X.4UE Reception of MBPreConfiguration

[0510] UEs should:

[0511] 1> If RRCResume includes radioBearerConfig:

[0512] 2> Perform radio bearer configuration according to 5.3.5.6;

[0513] 6.2.2 Message Definition

[0514] -MBSPreConfigRequest

[0515] The MBSPreConfigRequest message is used to request pre-configuration for receiving multicast in the RRC_INACTIVE state.

[0516] Signaling radio bearer: SRB0

[0517] RLC-SAP:TM

[0518] Logical channel: CCCH

[0519] Direction: UE to network

[0520] MBPREconfigurationRequest message

[0521] --ASN1START

[0522] --TAG-MBSPreCONFIGURATIONREQUEST-START

[0523] MBSPreConfigurationRequest::=SEQUENCE

[0524] {mbsPreConfigurationRequest MBSPreCconfigurationRequest-IEs}

[0525] MBSPreConfigurationRequest-IEs::=SEQUENCE

[0526] {ueIdentity ShortI-RNTI-Value,

[0527] ueMAC-I BIT STRING(SIZE(16)),

[0528] multicastSessionId MulticastSessionId,

[0529] G-RNTI-r17 RNTI-value OPTIONAL

[0530] spare BIT STRING(SIZE(1))}

[0531] --TAG-MBSPreCONFIGURATIONREQUEST-STOP

[0532] --ASN1STOP

[0533]

[0534] -MBSPreConfiguration

[0535] The MBPREconfiguration message is used to set up multicast reception in the RRC_INACTIVE state.

[0536] Signaling Radio Bearer: SRB1

[0537] RLC-SAP:AM

[0538] Logical channel: DCCH

[0539] Direction: Network to UE

[0540] MBSPreConfiguration message

[0541] --ASN1START

[0542] --TAG-MBSPreCONFIGURE-START

[0543] MBSPreConfigure::= SEQUENCE

[0544] {rrc-TransactionIdentifier RRC-TransactionIdentifier,

[0545] criticalExtensions CHOICE

[0546] {MBSPreConfigure MBSPreConfigure-IEs,

[0547] criticalExtensionsFuture SEQUENCE{}}}

[0548] MBSPreConfigure-IEs::= SEQUENCE

[0549] {radioBearerConfig RadioBearerConfig OPTIONAL,--Need M

[0550] MBS-DRX-PreConfig MBS-DRX-Config

[0551] OPTIONAL,

[0552] Multicast pre-configuration identity Multicast pre-configurationidentity

[0553] OPTIONAL

[0554] G-RNTI-r17 RNTI-value OPTIONAL

[0555] RRC_INACTIVE-reception-Indicator Boolean OPTIONAL}

[0556] MBSPreConfigure1-IEs:: = SEQUENCE

[0557] {CellIndentity Cell Indentity,

[0558] radioBearerConfig RadioBearerConfig OPTIONAL, -- Need M

[0559] MBS-DRX-PreConfig MBS-DRX-Config

[0560] OPTIONAL,

[0561] Multicast pre-configuration identity Multicast pre-configurationidentity

[0562] OPTIONAL

[0563] G-RNTI-r17 RNTI-value OPTIONAL

[0564] RRC_INACTIVE-reception-Indicator Boolean OPTIONAL}

[0565] --TAG-MBSPreConfigure-STOP

[0566] --ASN1STOP

[0567]

[0568] MBSPreConfiguration message

[0569] RRCRelease-v1650-IEs:: = SEQUENCE

[0570] {mpsPriorityIndication-r16 ENUMERATED{true} OPTIONAL, -- CondRedirection2

[0571] radioBearerConfig RadioBearerConfig OPTIONAL, -- Need M

[0572] MBS-DRX-PreConfig MBS-DRX-Config

[0573] OPTIONAL,

[0574] MBSPreConfigure1-IEs ::= SEQUENCE

[0575] {CellIndentity Cell Indentity,

[0576] radioBearerConfig RadioBearerConfig OPTIONAL, -- Need M

[0577] MBS-DRX-PreConfig MBS-DRX-Config

[0578] OPTIONAL,

[0579] Multicast pre-configuration identity Multicast pre-configurationidentity

[0580] OPTIONAL

[0581] G-RNTI-r17 RNTI-value OPTIONAL

[0582] RRC_INACTIVE-reception-Indicator Boolean OPTIONAL}}

[0583]

[0584] 5.3.X Multicast reception procedure

[0585] 5.3.X.1 Overview

[0586] Figure 5.3.X.1-1 Multicast reception request

[0587] The purpose of this procedure is to set up multicast reception in RRC_INACTIVE state, including (one or more than one) multicast MRBs.

[0588] 5.3.X.2 Initiation

[0589] The UE initiates this procedure when upper layers or the AS (when responding to RAN paging) request to receive multicast in the RRC_INACTIVE state.

[0590] The UE shall ensure that it has valid and up-to-date basic system information as specified in clause 5.2.2.2 before initiating this procedure.

[0591] When initiating this procedure, the UE shall:

[0592] 1> If the resumption of the RRC connection is triggered by responding to NG-RAN paging:

[0593] 2> Select "0" as the access category;

[0594] 2> Use the selected access category and one or more access identifiers provided by the upper layer to perform the unified access control process as specified in 5.3.14;

[0595] 3> If the access attempt is prohibited, the process ends;

[0596] Actions related to the transmission of MBSConfigRequest or MBSConfigRequest1 messages

[0597] The UE shall set the content of the MBSConfigRequest or MBSConfigRequest1 message as follows:

[0598] 1> If the field useFullResumeID is signaled in SIB1:

[0599] 2> Select MBSConfigRequest1 as the message to use;

[0600] 2> Set ueIdentity to the stored fullI-RNTI value;

[0601] 1> Otherwise:

[0602] 2> Select MBSConfigRequest as the message to use;

[0603] 2> Set ueIdentity to the stored shortI-RNTI value;

[0604] 1> Re-establish the PDCP entity for SRB1;

[0605] 1>Restore SRB1;

[0606] 1> Submit the selected message MBSConfigRequest or MBSConfigRequest1 for transmission to the lower layer.

[0607] UE receives MBSConfiguration

[0608] UEs should:

[0609] 1> If RRCResume includes radioBearerConfig:

[0610] 2> Perform radio bearer configuration according to 5.3.5.6;

[0611] Message Definition

[0612] -MBSConfigRequest

[0613] The MBSConfigRequest message is used to request configuration for receiving multicast in the RRC_INACTIVE state.

[0614] Signaling radio bearer: SRB0

[0615] RLC-SAP:TM

[0616] Logical channel: CCCH

[0617] Direction: UE to network

[0618] MBSConfigurationRequest message

[0619] --ASN1START

[0620] --TAG-MBSCONFIGURATIONREQUEST-START

[0621] MBSConfigurationRequest::= SEQUENCE

[0622] {mbsRConfigurationRequest MBSCconfigurationRequest-IEs}

[0623] MBSConfigurationRequest-IEs::=SEQUENCE

[0624] {ueIdentity ShortI-RNTI-Value,

[0625] ueMAC-I BIT STRING(SIZE(16)),

[0626] multicastSessionId MulticastSessionId,

[0627] spare BIT STRING(SIZE(1))}

[0628] --TAG-MBSCONFIGURATIONREQUEST-STOP

[0629] --ASN1STOP

[0630]

[0631] -MBSConfigurationRequest1

[0632] The MBSConfigurationRequest1 message is used to request configuration for receiving multicast in the RRC_INACTIVE state.

[0633] Signaling radio bearer: SRB0

[0634] RLC-SAP:TM

[0635] Logical channel: CCCH1

[0636] Direction: UE to network

[0637] MBSConfigurationRequest1 message

[0638] --ASN1START

[0639] --TAG-MBSCONFIGURATIONREQUEST1-START

[0640] MBSConfigrationRequest1::= SEQUENCE

[0641] {mbsConfigurationRequest1 MBSConfigurationRequest1-IEs}

[0642] MBSConfigurationRequest1-IEs::=SEQUENCE

[0643] {ueIdentity I-RNTI-Value,

[0644] ueMAC-I BIT STRING(SIZE(16)),

[0645] multicastSessionId TMGI-R17,

[0646] spare BIT STRING(SIZE(1))}

[0647] --TAG-MBSCONFIGURATIONREQUEST1-STOP

[0648] --ASN1STOP

[0649]

[0650] -MBSConfiguration

[0651] The MBSConfiguration message is used to set up multicast reception in the RRC_INACTIVE state.

[0652] Signalling radio bearer: SRB1

[0653] RLC-SAP:AM

[0654] Logical channel: DCCH

[0655] Direction: Network to UEMBSConfiguration message

[0656] --ASN1START

[0657] --TAG-MBSCONFIGURE-START

[0658] MBSConfigure::=SEQUENCE

[0659] {rrc-TransactionIdentifier RRC-TransactionIdentifier,

[0660] criticalExtensions CHOICE

[0661] {MBSConfigure MBSConfigure-IEs,

[0662] criticalExtensionsFuture SEQUENCE{}}}

[0663] MBSConfigure-IEs::= SEQUENCE

[0664] {radioBearerConfig RadioBearerConfig

[0665] OPTIONAL, --Need M}

[0666] --TAG-MBSConfigure-STOP

[0667] --ASN1STOP

[0668]

[0669] 5.3.X Multicast Receiving Request Process

[0670] 5.3.X.1 Overview

[0671] Figure 5.3.X.1-1 Multicast Receive Request

[0672] The purpose of this procedure is to set up a multicast reception request in the RRC_INACTIVE state, including (one or more than one) multicast MRBs.

[0673] 5.3.X.2 Initiation

[0674] The UE initiates this procedure when upper layers or the AS (when responding to RAN paging) request to receive multicast in the RRC_INNACTIVE state.

[0675] The UE shall ensure that it has valid and up-to-date basic system information as specified in clause 5.2.2.2 before initiating this procedure.

[0676] When initiating this procedure, the UE shall:

[0677] 1> If the resumption of the RRC connection is triggered by responding to NG-RAN paging:

[0678] 2> Select "0" as the access category;

[0679] 2> Use the selected access category and one or more access identifiers provided by the upper layer to perform the unified access control process as specified in 5.3.14;

[0680] 3> If the access attempt is prohibited, the process ends;

[0681] MBSReceptionRequest

[0682] The MBSReceptionRequest message is used to request reception of multicast data in the RRC_INACTIVE state.

[0683] Signaling radio bearer: SRB0

[0684] RLC-SAP:TM

[0685] Logical channel: CCCH

[0686] Direction: UE to network

[0687] MBSReceptionRequest message

[0688] --ASN1START

[0689] --TAG-MBSRECEPTIONREQUEST-START

[0690] MBSReceptionRequest::= SEQUENCE

[0691] {mbsReceptionRequest MBSReceptionRequest-IEs}

[0692] MBSReceptionRequest-IEs::= SEQUENCE

[0693] {ueIdentity ShortI-RNTI-Value,

[0694] ueMAC-I BIT STRING(SIZE(16)),

[0695] multicastSessionId MulticastSessionId,

[0696] spare BIT STRING(SIZE(1))}

[0697] --TAG-MBSRECEPTIONREQUEST-STOP

[0698] --ASN1STOP

[0699]

[0700] Although the present invention has been described with reference to the embodiments, it should be understood that the present invention is not limited to the disclosed embodiments. It will be appreciated by those skilled in the art that various changes and modifications may be made without departing from the scope of the present invention as defined in the appended claims. All features disclosed in this specification (including any appended claims, abstracts and drawings) and / or all steps of any method or process disclosed in this specification may be combined in any combination, except for at least some mutually exclusive combinations of such features and / or steps. Unless expressly stated otherwise, each feature disclosed in this specification (including any appended claims, abstracts and drawings) may be replaced by alternative features for the same, equivalent or similar purposes. Therefore, unless expressly stated otherwise, each feature disclosed is only an example of a series of general equivalent or similar features.

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

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

[0703] Computer-readable media may include computer-readable storage media (which corresponds to tangible media such as data storage media) or communication media containing any medium that facilitates, for example, transferring a computer program from one place to another according to a communication protocol. In this manner, computer-readable media may generally correspond to (1) a non-transitory tangible computer-readable storage medium, or (2) a communication medium such as a signal or carrier wave. Data storage media may be any available medium that can be accessed by one or more computers or one or more processors to retrieve instructions, codes, and / or data structures for implementing the techniques described in the present disclosure. A computer program product may include computer-readable media.

[0704] As an example and not limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, disk storage, or other magnetic storage devices, flash memory, or any other medium that can be used to store the desired program code in the form of instructions or data structures and can be accessed by a computer. In addition, any connection is appropriately referred to as a computer-readable medium. For example, if a coaxial cable, optical fiber cable, twisted pair, digital subscriber line (DSL) or wireless technologies such as infrared, radio and microwave are used to transmit instructions from a website, server or other remote source, then coaxial cable, optical fiber cable, twisted pair, DSL or wireless technologies such as infrared, radio and microwave are included in the definition of the medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals or other transient media, but are intended for replacement of non-transient tangible storage media. As used herein, disks and discs include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy disks and blue-ray discs, wherein the discs usually reproduce data magnetically, and the discs reproduce data optically with lasers. The above combination should also be included in the scope of computer-readable media.

[0705] According to some aspects described below, the present invention provides multicast pre-configuration information for a multicast session.

[0706] In Release 17, MBS multicast sessions follow 3GPP TS 23.247 v17.3.0 ( Figure 4 .3-1). The session management process includes session creation (7.1.1.2 or 7.1.1.3 of TS23.247), session activation (7.2.5.2 of TS23.247), session establishment and joining (7.2.1.3 of TS23.247). Only when the MBS session is established, the network configures the UE for reception of multicast data.

[0707] When the UE is in RRC_CONNECTED state, an MBS session is established in the UE. The network may then decide to switch the UE to RRC_INACTIVE state before MBS multicast data is available through session activation. When the session is activated, the network will have to inform the UEs that have joined the session, and the network will have to switch the UE in RRC_INACTIVE state to RRC_CONNECTED state to configure the UE.

[0708] As a first observation, the Release 17 specification does not provide a procedure to configure a UE in RRC_INACTIVE state. When an MBS session is activated, a UE in RRC_INACTIVE state should revert to RRC_CONNECTED state.

[0709] Based on Release 17, when an MBS session is activated, all UEs belonging to the multicast group should be configured simultaneously.

[0710] As a second observation, for a large number of UEs, the delivery of MBS configuration while an MBS multicast session is active may cause link congestion and delays.

[0711] MBS Pre-configuration

[0712] In order to avoid large-scale MBS configuration when an MBS session is activated, it is proposed to pre-configure the UE before the MBS session is activated.

[0713] MBS configuration can be delivered at different stages:

[0714] - at (or after) MBS session establishment when the UE is in RRC_CONNECTED state,

[0715] - when the UE switches to the RRC_INACTIVE state to provide a PTM configuration for receiving multicast data in the RRC_INACTIVE state,

[0716] - When the UE is already in RRC_INACTIVE state (e.g. for PTM configuration update).

[0717] Then, when the MBS multicast session is activated, the network notifies the UE, and the UE can apply the stored MBS configuration to start receiving multicast data.

[0718] Pre-configuring the UE at different times (before session activation) can reduce the network load when the MBS session is activated.

[0719] Preferably, the network provides the MBS multicast configuration to the UE in the multicast group before the MBS session is activated. For the UE that can receive MBS multicast data in the RRC_INACTIVE state, the network can provide (one or more than one) PTM configuration for some cells (e.g., neighboring cells) or all cells in the MBS service area. The advantage of receiving MBS multicast data for the UE in the RRC_INACTIVE state is that it can switch to the new cell without notifying the network to request configuration. After performing the cell reselection process and switching to the new cell, the UE can apply the stored PTM configuration corresponding to the new cell.

[0720] It is proposed that when the UE can receive MBS multicast data in RRC_INACTIVE state, the network can provide the UE with (one or more than one) PTM configurations for several cells in the neighborhood.

[0721] MBS session activation notification

[0722] When the MBS session is activated, the network may perform group paging indicating the activation of the MBS multicast session. A UE in the RRC_INACTIVE state that has been pre-configured may directly apply the stored PTM configuration without notifying the network.

[0723] However, the UE may inform 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 maintain the UE in the RRC_INACTIVE state. Furthermore, this notification from the UE enables the gNB to estimate the number of UEs that are actively receiving in the RRC_INACTIVE state.

[0724] As an alternative to group paging, the network may indicate the activation of MBS session activation through SIB.

[0725] It is proposed that a UE in the RRC_INACTIVE state may receive a notification of MBS session activation via group paging or SIB.

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

[0727] PTM configuration transfer in RRC_INACTIVE state

[0728] For PTM configuration delivery in RRC_INACTIVE state, two options are considered: using dedicated signaling or based on SIB plus MCCH. However, using MCCH channel to provide PTM configuration has some disadvantages related to security (regarding the authorization to receive multicast data). In addition, MCCH content may be transmitted periodically and is therefore not efficient in terms of bandwidth.

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

[0730] When the UE switches to the RRC_INACTIVE state, the network may provide the PTM configuration via an RRCRelease message with SuspendConfig. This PTM configuration transfer may be performed before the MBS session is activated (i.e., pre-configuration) or after the MBS session is activated. The message may include the PTM configuration for one or several cells in the MBS service area.

[0731] Figure 8 The process shown in exemplifies the PTM configuration transfer when switching to the RRC_INACTIVE state.

[0732] After the MBS session is established, the gNB may decide to switch the UE to the RRC_INACTIVE state (which may be decided 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 a RRCRelease message with SuspendConfig including the appropriate PTM configuration. The UE then knows that it is enabled to receive multicast data in the RRC_INACTIVE state.

[0733] In the same way, when the network has to configure a UE that is already in RRC_INACTIVE state, the RRC Release message with SuspendConfig may also be used to provide (one or more than one) PTM configurations while maintaining the UE in RRC_INACTIVE state. This may involve the following situations:

[0734] 1) In the case where the configuration is triggered by the UE at cell reselection, e.g. when the UE is receiving multicast data and does not have a PTM configuration for the target cell,

[0735] 2) In case the configuration is initiated in the network.

[0736] In the first case (configuration triggered by the UE), the UE may send an RRC Resume Request to the network (before or after cell switching) indicating that one or several PTM configurations are required for a given MBS multicast session. The network may then respond with an RRC Release message with SuspendConfig including the requested PTM configuration(s). In the second case (initiated by the network), the network may perform group paging to announce the availability of (one or more) PTM configurations for the MBS multicast session. The UEs interested in the MBS session may then send an RRC Resume Request message to notify its presence and its interest in the MBS session. Finally, the network may send an RRC Release message with SuspendConfig including (one or more) PTM configurations. This process may be performed at any time before or after the MBS session is activated (e.g., for updates). This process may also be performed at the time of MBS session activation, which means that the group paging will contain both the notification of the MBS session activation and the notification of the PTM configurations.

[0737] As proposed, the RRC Release message with SuspendConfig may be used to provide PTM configuration(s) to a UE that is switching to or already in the RRC_INACTIVE state.

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

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

[0740] It is proposed that a UE in RRC_INACTIVE state may receive (one or more than one) PTM configurations without switching to RRC_CONNECTED state.

[0741] Before sending PTM configuration(s) to the UE, the network shall check whether the UE belongs to the multicast group (ie, the UE has joined an MBS session and is authorized to receive multicast data).

[0742] As an alternative to group paging, the network may indicate the activation of MBS session activation through SIB.

[0743] It is proposed that group paging or SIB may be used to inform UEs in RRC_INACTIVE state about the availability of (one or more than one) PTM configurations.

Claims

1. A method at a user equipment (UE) of a wireless communication system, the method comprising: For a multicast session that the UE has requested to join, receiving multicast pre-configuration information for the multicast session; as well as The UE is configured according to the multicast preconfiguration information to receive multicast data via the multicast session.

2. The method according to claim 1, further comprising: A request to join the multicast session is sent to the core network via the base station.

3. A method according to any one of the preceding claims, wherein: The multicast pre-configuration information is received from a base station.

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

5. A method according to any one of the preceding claims, wherein: The pre-configuration information includes at least one of the following items: radio bearer configuration information associated with a low quality of service transmission, i.e. a low QoS transmission, Radio bearer configuration information associated with high quality of service transmission, i.e. high QoS transmission, an inactive reception indicator for indicating to a UE whether to enable the UE to receive multicast data in a non-connected RRC state, Information used to identify the group of UEs in the same cell that are interested in receiving multicast data. a multicast preconfiguration ID associated with the multicast session ID for identifying the configuration applied by the UE, Discontinuous reception configuration information, i.e., DRX configuration information, Neighborhood multicast configuration information, and Cell identification information used to identify one or more than one cell to which preconfiguration should be applied.

6. The method according to any one of the preceding claims, in, The multicast pre-configuration information comprises an update to existing configuration information for receiving multicast data via the multicast session, and The configuring step includes using the pre-configuration information to update the configuration of the UE to receive the multicast data via the multicast session.

7. The method according to any one of the preceding claims, further comprising: Data for the multicast session is received after configuration according to the multicast pre-configuration information.

8. A method according to any one of the preceding claims, wherein: The multicast pre-configuration information is received prior to activating the multicast session.

9. The method according to claim 8, wherein: The multicast pre-configuration information is received when the multicast session is established or after the multicast session is established.

10. The method according to claim 8 or 9, further comprising: A notification of activation of the multicast session is received after receiving the multicast pre-configuration information.

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

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

13. The method according to any one of claims 9 to 12, wherein: The UE is operating in a non-connected RRC state when receiving the notification of activation of the multicast session, and the notification of activation is received after a cell reselection process for causing the UE to camp on a base station.

14. The method according to claim 13, further comprising: A request for multicast reception and / or multicast feedback information is sent after receiving the multicast data, and in response, further multicast configuration data is received at the UE.

15. The method according to claim 13, wherein: The cell reselection process includes sending information indicating multicast session identification information of one or more multicast sessions joined by the UE to a base station from the UE.

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

17. A method according to any one of the preceding claims, wherein: The multicast pre-configuration information is received in a message for placing the UE in a non-connected RRC state.

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

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

20. The method according to claim 19, wherein: The multicast preconfiguration information is received after a cell reselection process for causing the UE to camp in a base station.

21. The method according to claim 20, further comprising: After the cell reselection process, receiving a notification indicating that multicast pre-configuration information can be used for the multicast session; as well as A multicast pre-configuration request is sent by the UE to the base station, wherein the multicast pre-configuration information is received from the base station in response to the sent request.

22. The method according to claim 21, wherein: The multicast preconfiguration request is sent after performing a physical random access channel procedure (PRACH) procedure with the base station in response to a notification indicating that the multicast preconfiguration information can be used for the multicast session.

23. The method according to claim 20, wherein: The cell reselection process includes sending information from the UE to a base station if a new cell has been selected as a result of the cell reselection process.

24. The method according to claim 23, comprising: A target base station identifier is sent to the base station, where the target base station identifier is used to identify a target base station associated with the new cell.

25. The method according to claim 23, comprising: Multicast session identification information for identifying one or more multicast sessions joined by the UE is sent to a target base station associated with the new cell.

26. The method according to any one of claims 20 to 25, further comprising: When the UE is operating in a non-connected RRC state, Prior to the cell reselection process, receiving multicast data for an active multicast session according to a configuration for a base station on which the UE camped prior to the cell reselection, and The pre-configuration information is used to configure the UE to receive multicast data from the multicast session from a base station where the UE is to camp after cell reselection.

27. The method according to claim 26, wherein: The cell reselection process includes: detecting, by the UE, whether the cell is in a multicast service area for which the UE does not have a corresponding multicast configuration.

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

29. A method at a base station for controlling a cell, the cell serving a user equipment (UE), the method comprising: Establishing a multicast session requested by the UE; as well as Multicast pre-configuration information for the multicast session is sent to the UE.

30. The method according to claim 29, comprising: A request to join the multicast session is received from the UE, and a request to join the multicast session is sent to a core network.

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

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

33. The method according to any one of claims 29 to 32, wherein: The pre-configuration information includes one or more of the following items: Radio bearer configuration information dedicated to low quality of service transmission, i.e. low QoS transmission, Radio bearer configuration information dedicated to high quality of service transmission, i.e. high QoS transmission, an inactive reception indicator for indicating to one or more UEs whether to enable the UE to receive multicast data in a non-connected RRC state, Information used to identify the group of UEs in the same cell that are interested in receiving multicast data. a multicast preconfiguration ID associated with the multicast session ID for identifying the configuration applied by the UE, Discontinuous reception configuration information, i.e., DRX configuration information, Neighborhood multicast configuration information, and Cell identification information used to identify one or more than one cell to which preconfiguration should be applied.

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

35. The method according to any one of claims 29 to 34, further comprising: Data for the multicast session is sent to the UE according to the multicast preconfiguration information.

36. A method according to any one of the preceding claims, wherein: The multicast pre-configuration information is sent before activating the multicast session.

37. The method of claim 36, wherein: The multicast pre-configuration information is sent when the multicast session is established or after the multicast session is established.

38. The method according to claim 36 or 37, further comprising: Sending a notification of activation of the multicast session to the UE.

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

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

41. The method of claim 40, further comprising: A request for multicast reception and / or multicast feedback information is received from the UE after sending multicast data to the UE, and in response, further multicast configuration data for the multicast session is sent to the UE.

42. The method of claim 40, wherein: The cell reselection process includes sending information indicating multicast session identification information of one or more multicast sessions joined by the UE to a base station from the UE.

43. The method according to any one of claims 29 to 35, wherein: The multicast pre-configuration information is sent after activating the multicast session.

44. A method according to any one of claims 29 to 43, wherein: The multicast pre-configuration information is sent to the UE in a message for placing the UE in a non-connected RRC state.

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

46. ​​A method according to any one of claims 29 to 35 and claim 43, wherein: The multicast pre-configuration information is sent to the UE when the UE is operating in a non-connected RRC state.

47. The method of claim 46, wherein: The multicast preconfiguration information is sent after a cell reselection process for causing the UE to camp in a base station.

48. The method of claim 47, further comprising: After the cell reselection process, sending a notification indicating that the multicast pre-configuration information can be used for the multicast session; as well as A multicast pre-configuration request is received from the UE, wherein the multicast pre-configuration information is sent in response to receiving the request.

49. The method of claim 48, wherein: After performing a physical random access channel process (PRACH process) with the UE, the multicast pre-configuration request is received.

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

51. The method of claim 50, comprising: A target base station identifier identifying a target base station associated with the new cell is received as a source base station.

52. The method of claim 51, comprising: Multicast session identification information for identifying one or more multicast sessions joined by the UE is received as a target base station associated with the new cell.

53. The method according to any one of claims 31 to 52, wherein: The UE is in a non-connected RRC state, and the base station is controlling a cell in which the UE is to camp after a cell reselection process, and the method further includes: A request is received from the UE for multicast pre-configuration information corresponding to the base station.

54. The method of claim 53, further comprising: A notification is sent to the UE that the multicast pre-configuration information can be used.

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

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

57. The method according to any one of claims 53 to 56, further comprising: Before sending updated multicast configuration information for the multicast session, checking that the UE has a context that allows the UE to receive multicast data for the multicast session.

58. A method at a user equipment (UE) of a wireless communication system, wherein the UE is configured to receive multicast data of an activated multicast session, the method comprising: sending a request for updated multicast configuration information for the activated multicast session to a base station; receiving the updated multicast configuration information from the base station; as well as The UE is configured according to the updated multicast configuration information to receive the multicast data of the activated multicast session.

59. The method of claim 58, wherein: The method includes sending the request to the base station in response to determining that modification of the multicast configuration for the UE is necessary to receive multicast data for the activated multicast session.

60. The method of claim 58 or 59, wherein: The method includes: before sending the request to the base station, determining, by the UE, that updated multicast configuration information is necessary for receiving multicast data of the activated multicast session.

61. The method according to any one of claims 58 to 60, wherein: The UE determines that the UE in the non-connected RRC state does not have the updated multicast configuration necessary to receive multicast data for the activated multicast session.

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

63. The method according to any one of claims 58 to 62, wherein: The method comprises sending the request to the base station in response to a reselection process for causing the UE to camp in a cell controlled by the base station.

64. The method according to any one of claims 58 to 63, further comprising: A notification is received at the UE that updated multicast configuration information can be used, wherein a request for the updated multicast configuration information is sent in response to the notification indicating that the updated multicast configuration information can be used.

65. The method according to any one of claims 58 to 64, wherein: The UE sends a request for updated multicast configuration information after performing a physical random access channel procedure (PRACH procedure) with the base station.

66. The method of any one of claims 58 to 65, wherein: Before sending the request for updated multicast configuration information, the UE obtains multicast configuration information for not enabling the UE to receive multicast data for the activated multicast session.

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

68. The method of claim 67, wherein: The method comprises receiving the request from the UE after determining that modification of the multicast configuration for the UE is necessary to receive multicast data for the activated multicast session.

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

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

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

72. The method of any one of claims 67 to 71, wherein: The method comprises receiving the request from the UE subsequent to a reselection process for causing the UE to camp in a cell controlled by the base station.

73. The method of any one of claims 67 to 72, further comprising: A notification is sent to the UE that the updated multicast configuration information can be used.

74. The method of any one of claims 67 to 73, wherein: Before receiving a request for updated multicast configuration information from the UE, the base station performs a physical random access channel procedure, namely, a PRACH procedure, with the UE.

75. An apparatus comprising a user equipment configured to perform a method according to any one of claims 1 to 28 and 58 to 66.

76. An apparatus comprising a base station configured to perform a method according to any one of claims 29 to 57 and 67 to 74.

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

78. A computer readable medium carrying a computer program according to claim 77.

Images