Multicast Broadcast Service for 5G New Radio

Abstract

The present disclosure relates to multicast and broadcast services for 5G New Radio. The present invention discloses embodiments of multicast and broadcast services (MBS) for 5G New Radio (NR). In one aspect, a user equipment (UE) receives first data from a network via unicast; receives first information from the network, the first information indicating the availability of a multicast service; transmits second information to the network; and in response to transmitting the second information to the network, receives second data from the network via multicast. In another aspect, the UE receives first information from the network, the first information indicating the availability of a multicast service; receives first data from the network via a multicast session; and receives second data from the network via a unicast packet data unit (PDU) session.

Description

Background Art

[0001] A 5G New Radio (NR) network can support both unicast services and multicast services. Multicast is a point-to-multipoint communication scheme in which the same data is transmitted from a single source to multiple endpoints simultaneously. In contrast to multicast, unicast is a point-to-point communication scheme in which data is transmitted from a source to a single endpoint. A User Equipment (UE) can be configured to receive data via unicast and / or multicast when connected to a 5G NR network. Summary of the Invention

[0002] Some exemplary embodiments relate to a method performed by a User Equipment (UE). The method includes: receiving first data from a network via unicast; receiving first information from the network, the first information indicating the availability of a multicast service; transmitting second information to the network; and in response to transmitting the second information to the network, receiving second data from the network via multicast.

[0003] Other exemplary embodiments relate to a User Equipment (UE) having a transceiver and a processor. The transceiver is configured to communicate with a network. The processor is configured to perform operations including: receiving first data from a network via unicast; receiving first information from the network, the first information indicating the availability of a multicast service; transmitting second information to the network; and in response to transmitting the second information to the network, receiving second data from the network via multicast.

[0004] Still some other exemplary embodiments relate to a method performed by a User Equipment (UE). The method includes: receiving first information from the network, the first information indicating the availability of a multicast service; receiving first data from the network via a multicast session; and receiving second data from the network via a unicast Packet Data Unit (PDU) session.

[0005] Still some other exemplary embodiments relate to a User Equipment (UE) having a transceiver and a processor. The transceiver is configured to communicate with a network. The processor is configured to perform operations including: receiving first information from the network, the first information indicating the availability of a multicast service; receiving first data from the network via a multicast session; and receiving second data from the network via a unicast Packet Data Unit (PDU) session. Brief Description of the Drawings

[0006] Figure 1 An exemplary network arrangement according to various exemplary embodiments is shown.

[0007] Figure 2 An exemplary UE according to various exemplary embodiments is shown.

[0008] Figure 3Shows a schematic overview of an exemplary arrangement of network functions for multicast broadcast service (MBS) according to various exemplary embodiments.

[0009] Figure 4a Shows a signaling diagram for unicast to multicast handover according to various exemplary embodiments.

[0010] Figure 4b Shows a signaling diagram for unicast to multicast handover according to various exemplary embodiments.

[0011] Figure 5 Shows a signaling diagram for unicast to multicast handover according to various exemplary embodiments.

[0012] Figure 6 Shows a signaling diagram for unicast to multicast handover according to various exemplary embodiments.

[0013] Figure 7 Shows a method for multicast to unicast handover based on quality of service (QoS) according to various exemplary embodiments.

[0014] Figure 8 Shows a signaling diagram for multicast to unicast handover according to various exemplary embodiments.

[0015] Figure 9 Shows a signaling diagram for multicast to unicast handover according to various exemplary embodiments.

[0016] Figure 10 Shows a signaling diagram for facilitating unicast to multicast handover of a UE according to various exemplary embodiments.

[0017] Figure 11 Shows a signaling diagram for collecting and analyzing data for unicast to multicast handover (and vice versa) by a network data analytics function (NWDAF) according to various exemplary embodiments.

[0018] Figure 12 Shows a signaling diagram for UE and network synchronization regarding an MBS session according to various exemplary embodiments. Detailed Description

[0019] The exemplary embodiments can be further understood with reference to the following description and the related drawings, in which like elements are denoted with the same reference numerals. The exemplary embodiments relate to implementing multicast broadcast service (MBS) of 5G new radio (NR).

[0020] MBS generally refers to an aspect of the 5G NR network that can deliver the same content to multiple receivers. Throughout the specification, examples of MBS functions are described with reference to multicast. Multicast is a point-to-multipoint communication scheme in which data is simultaneously delivered from a single source to multiple endpoints. However, the reference to multicast services is provided for illustrative purposes only, and those skilled in the art will understand that the exemplary concepts described herein are also applicable to broadcast services.

[0021] The 5G NR network can also deliver data via unicast. Unicast is a point-to-point communication scheme in which data is transmitted from a source to a single endpoint. Exemplary embodiments are described with reference to a user equipment (UE) configured with a unicast session. Throughout the specification, the term "unicast session" may refer to a communication session configured to deliver data to the UE via unicast. Various examples are described with reference to a unicast session including a packet data unit (PDU) session. Those skilled in the art will understand that a PDU session generally refers to a logical connection between the UE and a data network. However, any reference to a unicast session or a PDU session is provided for illustrative purposes only. Similar concepts may be referred to by different entities by different names.

[0022] Exemplary embodiments are also described with reference to an MBS session. Throughout the specification, the term "MBS session" may refer to a communication session configured to deliver data to the UE via multicast. An MBS session may include an "MBS bearer". Similar to the function of a PDU session, an MBS bearer can deliver data from a source to the UE via the 5G NR network. Any reference to an MBS session or an MBS bearer is provided for illustrative purposes only. Similar concepts may be referred to by different entities by different names.

[0023] Exemplary embodiments include various MBS session management techniques performed at the UE, at the radio access network (RAN) level, and / or at the core network level. In a first aspect, exemplary MBS session management techniques relate to establishing an MBS session for a UE currently configured with a unicast session. In a second aspect, exemplary MBS session management techniques relate to establishing a unicast session for a UE currently configured with a multicast session. These exemplary techniques can be used together with other currently implemented MBS management techniques, future implementations of MBS management techniques, or independently of other MBS management techniques. Specific examples of these exemplary aspects will be described in detail below.

[0024] Figure 1FIG. 0 shows an exemplary network arrangement 100 in accordance with various exemplary embodiments. The exemplary network arrangement 100 includes a UE 110. Those skilled in the art will understand that the UE 110 can be any type of electronic component configured to communicate via a network, such as, for example, a mobile phone, a tablet computer, a desktop computer, a smart phone, a phablet, an embedded device, a wearable device, an Internet of Things (IoT) device, an eMTC device, etc. It should also be understood that an actual network arrangement may include any number of UEs used by any number of users. Thus, for illustrative purposes, only an example with a single UE 110 is provided.

[0025] The UE 110 can be configured to communicate with one or more networks. In the example of the network arrangement 100, the networks with which the UE 110 can communicate wirelessly are 5G New Radio (NR) Radio Access Networks (5G NR-RANs) 120, 122. However, it should be understood that the UE 110 can also communicate with other types of networks (such as, for example, LTE, traditional cellular networks, WLAN, etc.), and the UE 110 can also communicate with a network via a wired connection. The examples provided below will describe scenarios in which the UE 110 establishes a connection with the 5G NR RAN 120 or the 5G NR RAN 122.

[0026] The 5G NR-RANs 120, 122 can be part of a cellular network that can be deployed by a cellular provider (such as, for example, Verizon, AT&T, Sprint, T-Mobile, etc.). These networks 120, 122 can include, for example, cells or base stations (NodeB, eNodeB, HeNB, eNBS, gNB, gNodeB, macro cell base stations, micro cell base stations, small cell base stations, femto cell base stations, etc.) configured to send and receive traffic from UEs equipped with appropriate cellular chipsets.

[0027] The 5G NR-RANs 120, 122 can include an architecture capable of providing both 5G NR RAT services and LTE RAT services. For example, a Next Generation Radio Access Network (NG-RAN) (not shown) can include Next Generation Node Bs (gNBs) that provide 5G NR services and Next Generation evolved Node Bs (ng-eNBs) that provide LTE services. The NG RAN can be connected to at least one of an Evolved Packet Core (EPC) or a 5G Core (5GC). Thus, references to the 5G NR-RANs 120, 122 are provided for illustrative purposes only, and the exemplary embodiments can be applied to any suitable type of RAN.

[0028] Returning to the exemplary network arrangement 100, the UE 110 can be connected to the 5G NR RAN 120 via the next-generation node B (gNB) 120A and to the 5G NR RAN 122 via the gNB 122A. Those skilled in the art will understand that any relevant procedures for connecting the UE 110 to the 5G LTE RAN 120 or the 5G NR RAN 122 can be performed. For example, as discussed above, the 5G NR RAN 120 can be associated with a specific cellular provider where the UE 110 and / or its user have protocol and credential information (e.g., stored on the SIM card). When the presence of the 5G NR RAN 120 is detected, the UE 110 can transmit the corresponding credential information to be associated with the 5G NR RAN 120. More specifically, the UE 110 can be associated with a specific cell (e.g., the gNB 120A of the 5G NR-RAN 120). Similarly, to access the 5G NR RAN 122, the UE 110 can be associated with the gNB 122A.

[0029] In addition to the 5G NR-RANs 120, 122, the network arrangement 100 further includes a cellular core network 130, the Internet 140, an IP multimedia subsystem (IMS) 150, and a network service backbone 160. The cellular core network 130 can be regarded as an interconnected collection of components that manage the operations / traffic of the cellular network. The cellular core network 130 also manages the traffic flowing between the cellular network and the Internet 140. A description of the types of network functions within the core network 130 that can be used for MBS will be described below with reference to Figure 3 the schematic overview 300.

[0030] The IMS 150 can generally be described as an architecture for delivering multimedia services to the UE 110 using IP protocols. The IMS 150 can communicate with the cellular core network 130 and the Internet 140 to provide multimedia services to the UE 110. The network service backbone 160 communicates directly or indirectly with the Internet 140 and the cellular core network 130. The network service backbone 160 can generally be described as a set of components (e.g., servers, network storage arrangements, etc.) that implement a set of services that can be used to extend the functions of the UE 110 to communicate with various networks.

[0031] Figure 2 An exemplary UE 110 is shown in accordance with various exemplary embodiments. A reference will be made to Figure 1The UE 110 is described with reference to the network arrangement 100. The UE 110 may represent any electronic device and may include a processor 205, a memory arrangement 210, a display device 215, an input / output (I / O) device 220, a transceiver 225, and other components 230. The other components 230 may include, for example, an audio input device, an audio output device, a battery, a data collection device, a port for electrically connecting the UE 110 to other electronic devices, a sensor for detecting the condition of the UE 110, and the like.

[0032] The processor 205 may be configured to execute multiple engines of the UE 110. For example, the engines may include an MBS session management engine 235. The MBS session management engine 235 may perform various operations related to establishing and maintaining an MBS session.

[0033] The above engines are merely exemplary as applications (e.g., programs) executed by the processor 205. The functions associated with the engines may also be represented as separate combined components of the UE 110 or may be modular components coupled to the UE 110, e.g., integrated circuits with or without firmware. For example, an integrated circuit may include an input circuit for receiving signals and a processing circuit for processing signals and other information. The engines may also be embodied as one application or separate multiple applications. Additionally, in some UEs, the functionality described for the processor 205 is shared between two or more processors such as a baseband processor and an application processor. The exemplary embodiments may be implemented in any of these or other configurations of the UE.

[0034] The memory 210 may be a hardware component configured to store data related to the operations performed by the UE 110. The display device 215 may be a hardware component configured to display data to a user, while the I / O device 220 may be a hardware component that enables a user to make inputs. The display device 215 and the I / O device 220 may be separate components or may be integrated together (such as a touch screen). The transceiver 225 may be a hardware component configured to establish connections with the 5G NR RAN 120, 122, and other types of wireless networks. Thus, the transceiver 225 may operate on various different frequencies or channels (e.g., contiguous frequency bands).

[0035] Figure 3 A schematic overview 300 of an exemplary arrangement of network functions for MBS according to various exemplary embodiments is shown. The schematic overview 300 will be described with reference to Figure 1 the network arrangement 100 and Figure 2 the UE 110.

[0036] The schematic overview 300 includes a UE 110, a 5G NR RAN 120, an Access and Mobility Management Function (AMF) 305, a Session Management Function (SMF) 310, a Policy Control Function (315), a User Plane Function (UPF) 320, and a Multicast Service Function (325). The functions 305 - 325 can be considered functions of the core network 130, such as 5GC. As described above with reference to the network arrangement 100, the UE 110 can camp on the 5G NR RAN 120. Both the UE 110 and the 5G NR RAN 120 can communicate directly with the AMF 305. For example, the UE 110 can communicate with the AMF 305 via the N1 interface, and the 5G NR RAN 120 can communicate with the AMF 305 via the N2 interface. Although only a single RAN 120 is shown in the schematic overview 300, these network functions can support more than one RAN (e.g., 5G NR RAN 122).

[0037] The AMF 305 can perform operations related to mobility management, such as but not limited to paging between the UE 110 and the core network 130, non-access stratum (NAS) management, and registration procedure management. The AMF 305 can be equipped with one or more communication interfaces (e.g., N1, N2, etc.) to communicate directly or indirectly with other network components (e.g., network functions, RANs, UEs, etc.). Exemplary embodiments are not limited to the AMF performing the above operations. Those skilled in the art will understand the various different types of operations that the AMF can perform. In addition, the reference to a single AMF 305 is for illustrative purposes only, and an actual network arrangement can include any suitable number of AMFs.

[0038] The AMF 305 can also communicate directly with the SMF 310. For example, the AMF 305 can communicate with the SMF 310 via the N11 interface.

[0039] The SMF 310 can perform operations related to session management, such as but not limited to session establishment, session release, IP address allocation, policy and Quality of Service (QoS) enforcement, etc. The SMF 310 can be equipped with one or more communication interfaces (e.g., N11, etc.) to communicate directly or indirectly with other network components (e.g., network functions, RANs, UEs, etc.). Exemplary embodiments are not limited to the SMF performing the above operations. Those skilled in the art will understand the various different types of operations that the SMF can perform. In addition, the reference to a single SMF 310 is for illustrative purposes only, and an actual network arrangement can include any suitable number of SMFs.

[0040] The SMF 310 can communicate directly with the PCF 315. For example, the SMF 310 can communicate with the PCF 315 via the N7 interface.

[0041] The PCF 315 can perform operations related to the control plane, such as but not limited to managing policy rules for control plane functions, including network slicing, roaming, and mobility management. The PCF 315 can be equipped with one or more communication interfaces (e.g., N7, etc.) to communicate directly or indirectly with other network components (e.g., network functions, RAN, UE, etc.). Exemplary embodiments are not limited to the PCF performing the above operations. Those skilled in the art will understand the various different types of operations that the PCF can perform. In addition, the reference to a single PCF 315 is for illustrative purposes only, and an actual network arrangement may include any appropriate number of SMFs.

[0042] The SMF 310 and the 5G NR RAN 120 can communicate directly with the UPF 320. For example, the SMF 310 can communicate with the UPF 320 via the N4 interface, and the 5G NR RAN 120 can communicate with the UPF 320 via the N3 interface.

[0043] The UPF 320 performs operations related to packet data unit (PDU) session management and other types of data flow management. For example, the UPF 320 can facilitate the connection between the UE 110 and a data network (e.g., the Internet 140) via the N6 interface. The UPF 320 can be equipped with one or more communication interfaces (e.g., N3, N4, N6, etc.) to communicate directly or indirectly with other network components (e.g., network functions, RAN, UE, etc.). Exemplary embodiments are not limited to the UPF performing the above operations. Those skilled in the art will understand the various different types of operations that the UPF can perform. In addition, the reference to a single UPF 320 is for illustrative purposes only, and an actual network arrangement may include any appropriate number of UPFs.

[0044] The PCF 315 and the UPF 320 can communicate directly with the MSF 325. For example, the UPF 320 can communicate with the MSF 325 via the N6 interface, and the PCF 315 can communicate with the MSF 325 via the Nnef interface.

[0045] The MSF 325 performs operations related to providing multicast services. For example, the MSF 325 can perform operations related to the user plane data stream and control plane information of an MBS session. The MSF 325 can be equipped with one or more communication interfaces (e.g., N6, Nnef, etc.) to communicate directly or indirectly with other network components (e.g., network functions, RAN, UE, etc.). Exemplary embodiments are not limited to the MSF that performs the above operations. Those skilled in the art will understand the various different types of operations that the MSF can perform. Additionally, the reference to a single UPF 320 is for illustrative purposes only. In some embodiments, there may be multiple MSFs and / or the functions of the MSF 325 can be divided between one or more network functions configured for control plane operations and one or more network functions configured for user plane operations. Thus, the actual network arrangement can include any appropriate number of MSFs.

[0046] As indicated above, the UE 110 can receive data via an MBS bearer during an MBS session. The MBS bearer context refers to the information associated with establishing and maintaining an MBS bearer on the network side. The MBS bearer context can be used by one or more components on the data stream path (e.g., 5G NR RAN 120, AMF 305, SMF 310, UPF 320, MSF 325, etc.) for any of a variety of different reasons. Examples of MBS bearer context parameters that can be used for 5G NR MBS will be described below. However, any reference to specific parameters is provided for illustrative purposes only. Different entities may refer to similar concepts by different names.

[0047] The MBS bearer context can include the tunnel endpoint identifier for the MBS gateway in the control plane (MBS TEID-C). This parameter can be used by the AMF 305 and SMF 310 for control plane signaling. The MBS bearer context can also include the Temporary Mobile Group Identifier (TMGI), which uniquely identifies the MBS bearer service and can be used by all components on the data stream path. The MBS bearer context can also include the flow identifier for the location-related subflow of the MBS bearer service. This parameter can be used by various network functions on the data stream path in conjunction with the TMGI to uniquely identify the MBS bearer service.

[0048] The MBS bearer context may also include the MSF IP address of the MSF 325 for the control plane and the MSF IP address of the MSF 325 for the user plane. These parameters can be used by the AMF 305 and the SMF 310. If the MSF 325 supports multiple address types (e.g., IPv4, IPv6, etc.), two IP addresses can be stored. The MBS bearer context may also include the common tunnel endpoint identifier (C-TEID) of the UPF 320 for the user plane. This parameter can be used by the 5G NR RAN 120 and the UPF 320.

[0049] The MBS bearer context may also include quality of service (QoS) parameters. Those skilled in the art will understand that the QoS parameters relate to the quality of service metrics that the MBS bearer service may be required to meet. This parameter can be used by all network components on the data flow path. The MBS bearer context may also include the MBS service area related to the geographical area on which the MBS bearer service can be allocated. This parameter can be used by all network components on the data flow path.

[0050] The MBS bearer context may also include a list of downstream nodes that have requested the MBS bearer service and to which the notification will be forwarded. This parameter can be used by the AMF 305 and the SMF 310 to identify the registered multicast service area. This parameter can also be used by the UPF 320 and may also include the SMF / AMF IP address and TEID of the control plane. The MBS bearer context may also include the allocated IP multicast address and the IP source address. These IP addresses can identify the channels for user plane distribution on the backbone part of the network. The IP addresses can be used by the 5G NR RAN 120, the AMF 305, the SMF 310, and the UPF 320. If these components support multiple address types (e.g., IPv4, IPv6, etc.), two IP addresses can be stored. The MBS context may also include a list of cell IDs to which the MBS service can be allocated. The cell IDs can be used by all network components on the data flow path.

[0051] In addition to the MBS bearer context, the UE context can also be used. The UE context refers to the information associated with identifying and tracking the UE 110 so that the MBS data flow can successfully reach the UE 110. The UE context can be used by one or more components on the data flow path (e.g., the UE 110, the 5G NR RAN 120, the AMF 305, the SMF 310, the UPF 320, the MSF 325, etc.) for any of a variety of different reasons. Examples of UE context parameters that can be used for 5G NR MBS will be described below. However, any reference to a specific parameter is provided for illustrative purposes only. Similar concepts may be referred to by different names by different entities.

[0052] The UE context may include the IP multicast address for identifying the MBS bearers to which the UE 110 has joined. This parameter may be used by the UE 110 and various network functions on the data flow path. The UE context may also include the access point name (APN) on which the IP multicast address is defined (in the case of a separate PDU session for the MBS session). This parameter may be used by the UE 110 and various network functions on the data flow path.

[0053] The UE context may also include the IP address of the currently used UPF (e.g., UPF 320). This parameter may be used by the AMF 305, SMF 310, and 5G NR RAN 120. The UE context may also include the TMGI assigned to the MBS bearer. This parameter may be used by the UE 110, AMF 305, SMF 310, and 5G NR RAN 120.

[0054] The UE context may also include the tracking area identity (TAI) associated with the UE 110. The TAI may be used by the UE 110, AMF 305, SMF 310, and 5G NR RAN 120. The UE context may also include the bearer UD of the PDU context used by the UE 110 to carry Internet Group Management Protocol (IGMP) signaling. This parameter may be used by the UE 110, AMF 05, and SMF 310.

[0055] The UE context may also include the Internet Mobile Subscriber Identity (IMSI) and Subscription Permanent Identifier (SUPI) that identify the UE 110. This parameter may be used across all network components on the data flow path. The UE context may also include the transaction identifier for the PDU session for multicast and unicast services. This parameter may be used by the UE 110, AMF 305, and SMF 310.

[0056] The UE context may also include the TEID of the control plane between the SMF 310 and the UF 320. The UE context may also include the MSF bearer ID representing the network layer service access point identifier that identifies the MSF UE context. This parameter may be used by the UE 110, AMF 305, and SMF 310.

[0057] The above examples of the MBS bearer context and the UE context are not intended to limit the exemplary embodiments in any way. These examples are provided only as an overview of the types of information that may be used to facilitate the data flow of the MBS. In an actual MBS scenario, any appropriate type of context information may be used. Additionally, any reference to a specific parameter is for illustrative purposes, and different entities may refer to similar concepts by different names.

[0058] As described above, in a first aspect, exemplary MBS session management techniques relate to establishing an MBS session for a UE that is currently configured with a unicast session. The signaling diagrams 400-600 provided below illustrate examples of MBS techniques that can be used in this type of scenario. In a second aspect, exemplary MBS session management techniques relate to establishing a unicast session for a UE that is currently configured with a multicast session. The method 700 and signaling diagrams 800-900 provided below illustrate examples of MBS techniques that can be used in this type of scenario.

[0059] Figure 4a The signaling diagram 400 for unicast-to-multicast handover according to various exemplary embodiments is shown. Refer to Figure 1 network device 100 of Figure 2 UE 110 of Figure 3 and the schematic overview 300 of

[0060] The signaling diagram 400 relates to a scenario in which the UE 110 is currently configured with a unicast session. For example, the UE 110 may preoccupy the 5G RAN 120 and receive multimedia data for network services via a PDU session. The signaling diagram 400 includes the UE 110, the 5G NR RAN 120, the 5G NR RAN 122, and the MSF 325.

[0061] In 402, the unicast session is in progress. In 404, the MSF 325 transmits MBS availability information to the UE 110. The MBS availability information may include an indication of ongoing MBS sessions and MBS bearer contexts, such as a list of TMGIs, a list of service areas, and other session information of the ongoing MBS sessions. The MBS availability information may travel from the MSF 325 to the UE 110 via the application layer and the user plane. Additionally, the MBS availability information may be provided to the UE 110 for any suitable reason, such as but not limited to an indication of the UE 110's mobility, the presence of ongoing and relevant MBS sessions near the UE 110, the initiation of an MBS session, etc.

[0062] In 406, the UE 110 identifies the RAN with an ongoing MBS session. For example, the UE 110 may currently preoccupy the 5G NR RAN 120. The UE 110 may receive an indication that the 5G NR RAN 122 has an ongoing MBS session at least partially based on the MBS availability information received in 404. When the UE 110 is in the radio resource control (RRC) idle or inactive mode, the UE 110 may target the 5G NR RAN 122 during a frequency scan and detect a suitable cell (e.g., gNB 122A) of the 5G NR RAN 122 within the service area list of the ongoing MBS session.

[0063] At 408, the UE 110 may perform a RAN notification area (RNA) update procedure. Those skilled in the art will understand the operations associated with performing an RNA update, which are outside the scope of the exemplary embodiments.

[0064] At 410, the UE 110 joins an MBS session from the 5G NR RAN 122. Thus, the UE 110 can now continue to receive the data stream of the MBS session via multicast. In some embodiments, the unicast PDU session may be released. In other embodiments, the unicast PDU session may be modified. To ensure service continuity, the network may implement a protection timer or QoS threshold condition before releasing or modifying the unicast PDU session.

[0065] Figure 4b A signaling diagram 450 for unicast to multicast handover according to various exemplary embodiments is shown. Refer to Figure 1 the network arrangement 100 of Figure 2 the UE 110 of Figure 3 and the schematic overview 300 of

[0066] The signaling diagram 450 includes the UE 110, 5G NR RAN 120, 5G NR RAN 122, AMF 305, SMF 310, UPF 320, and MSF 325. The signaling diagram 450 relates to the same type of scenario as the signaling diagram 400. However, the signaling diagram 450 relates to initiating a new MBS session rather than an ongoing MBS session.

[0067] At 452, a unicast session is in progress. At 454, the MSF 325 transmits MBS availability information to the UE 110. In this example, an indication of the ongoing MBS session may not be included in the MBS availability. Instead, the MBS context of the possible MBS session may be provided.

[0068] At 456, the UE 110 identifies the RAN that supports MBS. For example, the UE 110 may receive an indication that the 5G NR RAN 122 supports MBS at least partially based on the MBS availability information received at 404. When the UE 110 is in the RRC idle or inactive mode, the UE 110 may target the 5G NR RAN 122 during a frequency scan and detect a suitable cell of the 5G NR RAN 122. The UE 110 can now pre - em the 5G NR RAN 122 while the unicast session continues.

[0069] In 458, the UE 110 may transmit an indication to the 5G NR RAN 122 that the UE 110 is interested in an MBS session. The MBS interest indication may include UE context such as, but not limited to, SUPI, PDU session ID, application ID, etc. The UE 110 may be triggered to transmit the request for any suitable reason. In 460, the 5G NR RAN 122 may forward the request to the AMF 305. The 5GNR RAN 122 may include additional information such as UE ID or UE group ID.

[0070] In 462, the AMF 305 may transmit an MBS registration request to the SMF 310 that requests a new multicast session. The MBS registration request may include information such as, but not limited to, SUPI associated with the requesting UE (or UE group), tracking area information, RAN service availability information, etc. In 464, the request, along with authentication and authorization information, is processed among various network functions (e.g., SMF 310, UPF 320, MSF 325, and other suitable network functions) for user plane and control plane activation of the new MBS session.

[0071] Depending on the number of devices requesting MBS and other RAN considerations, the network may decide whether to initiate a new MBS session in response to the MBS registration request. Thus, the UE 110 may implement a timer (or any other suitable mechanism) and periodically send MBS registration requests.

[0072] In 466, the MBS service response travels through various network components (e.g., SMF 310, UPF 320, MSF 325, other suitable network functions, and 5G NR RAN 120) to the 5G NR RAN 120. The MBS session response may include information such as, but not limited to, session start request, TMGI, service area identification, etc.

[0073] In 468, the UE 110 receives data via the new MBS session through the 5G NR RAN 122. Thus, the UE 110 can now continue to receive the data stream of the MBS session via multicast. In some embodiments, the unicast PDU session may be released. In other embodiments, the unicast PDU session may be modified. To ensure service continuity, the network may implement a protection timer or QoS threshold condition before releasing or modifying the unicast PDU session.

[0074] Figure 5 A signaling diagram 500 for unicast to multicast handover according to various exemplary embodiments is shown. Referring to Figure 1 the network device 100, Figure 2 the UE 110, and Figure 3The signaling diagram 500 is described by the schematic overview 300.

[0075] Similar to the signaling diagrams 400 - 450, the signaling diagram 500 pertains to a scenario where the UE 110 is currently configured with a unicast session. For example, the UE 110 may preempt the 5G RAN 120 and receive multimedia data for network services via a PDU session. Compared with the signaling diagrams 400 - 450, the signaling diagram 500 does not involve a handover initiated by UE 110 mobility. Instead, the signaling diagram 500 involves a handover initiated based on a predefined condition identified on the network side corresponding to the user plane. The signaling diagram 500 includes the UE 110, 5G NR RAN 120, AMF 305, SMF 310, UPF 320, and MSF 325.

[0076] The signaling diagram 500 depicts three counters and corresponding thresholds. One counter may be implemented at the MSF 325, another counter may be implemented at the UPF 320, and another counter may be implemented at the SMF 310. The ways in which these counters and / or thresholds can be utilized will be described below. However, the use of all three counters and thresholds is merely exemplary. Each counter and corresponding threshold can be independent or can be used in combination with other counters and corresponding thresholds.

[0077] In 502, the unicast session is in progress. In 504, the MSF 325 and / or UPF 320 identify that the number of UEs subscribing to receive the same content meets a predefined threshold. For example, the network may implement a counter that tracks the number of UEs subscribing to receive the same content. This threshold may indicate to the network that an MBS session can be used to improve resource efficiency.

[0078] In 506, the MSF 325 sends an MBS session start request to the SMF 310. The MBS session start request may include information associated with the new MBS session, such as but not limited to TMGI, duration, service area, TEID, MBS IP address, UPF IP address, and tracking area information.

[0079] In 508, the SMF 310 sends an MBS session start response to the MSF 325. In 510, the MSF 325 may send MSB availability information to the UE 110 via the ongoing unicast session. The MSB availability information may include information such as but not limited to an indication of the ongoing MBS session, a list of TMGIs, the associated service area, etc.

[0080] At 512, the UE 110 transmits a multicast join request for an ongoing MBS session to the UPF 320 using the MBS availability information. At 514, the UPF 320 uses a counter to track the number of requests for the MBS session ID. In this example, the counter can be used for MBS session management to ensure that an ongoing MBS session does not have too many or too few users.

[0081] At 516, the UPF 320 may send MBS session information to the SMF 310, such as but not limited to the status and threshold of the counter implemented at the UPF 320, the TMGI list, multicast requests, etc.

[0082] At 518, the SMF 310 uses a counter to track the number of served UEs. The counter can be associated with a specific tracking area and / or RAN and can be used for MBS session management to ensure that an ongoing MBS session does not have too many or too few users.

[0083] At 520, the SMF 310 transmits an MBS session request to the AMF 305. At 522, the AMF 305 transmits an MBS session start request to the 5G NR RAN 120. At 524, the UE 110 connects to the MBS session via the UPF 320. In some embodiments, the unicast PDU session may be released. In other embodiments, the unicast PDU session may be modified. To ensure service continuity, the network may implement a protection timer or QoS threshold condition before releasing or modifying the unicast PDU session.

[0084] Figure 6 A signaling diagram 600 for unicast to multicast handover according to various exemplary embodiments is shown. With reference to Figure 1 the network device 100, Figure 2 the UE 110, and Figure 3 the schematic overview 300, the signaling diagram 600 is described.

[0085] Similar to the signaling diagrams 400 - 500, the signaling diagram 500 relates to a scenario where the UE 110 is currently configured with a unicast session. For example, the UE 110 may pre - em the 5G RAN 120 and receive multimedia data for network services via a PDU session. Compared with the signaling diagrams 400 - 450, the signaling diagram 600 does not involve a handover initiated by UE 110 mobility. Additionally, compared with the signaling diagram 500, the signaling diagram 600 does not involve conditions corresponding to the user plane. Instead, the signaling diagram 600 involves a handover initiated based on a predetermined condition identified on the network side corresponding to the control plane. The signaling diagram 600 includes the UE 110, 5GNR RAN 120, AMF305, SMF 310, UPF 320, and MSF 325.

[0086] Similar to signaling diagram 500, signaling diagram 600 depicts three counters and corresponding thresholds. One counter can be implemented at MSF 325, another counter can be implemented at UPF 320, and yet another counter can be implemented at SMF 310. The ways in which these counters and / or thresholds can be utilized will be described below. However, the use of all three counters and thresholds is merely exemplary. Each counter and corresponding threshold can be independent or can be used in combination with other counters and corresponding thresholds.

[0087] 602 - 610 are substantially similar to 502 - 510 of signaling diagram 500. For example, in 602, an ongoing unicast session is shown. In 604, MSF 325 and / or UPF 320 identify that the number of UEs subscribing to receive the same content meets a predetermined threshold. In 606, MSF 325 sends an MBS session start request to SMF 310. In 608, SMF 310 sends an MBS session start response to MSF 325. In 610, MSF 325 can send MSB availability information to UE 110 via the ongoing unicast session.

[0088] In 612, UE 110 transmits an MBS interest indication to the currently preempted 5G NR RAN 120. This MBS interest indication can include UE context such as, but not limited to, SUPI, PDU session ID, etc. For any suitable reason, UE 110 can be triggered to transmit this request.

[0089] In 614, 5G NR RAN 120 transmits an MBS registration request to AMF 305. In 616, AMF 305 forwards the MBS registration request to SMF 310 via the TMGI requested by one or more UEs.

[0090] In 618, SMF 310 uses a counter. If the counter at SMF 310 is greater than a predetermined threshold for MBS session users within the tracking area / RAN, then SMF 310 can forward the request to UPF 320. If the counter does not meet the threshold, the MBS session may not be started. This counter can be used for MBS session management to ensure that a sufficient number of UEs will participate in the MBS session.

[0091] In 620, a session modification message is transmitted from SMF 310 to UPF 320. In response to this message, UPF 320 prepares resources for the MBS session.

[0092] At 622, the UPF 320 uses a counter. If the counter at the UPF 320 is greater than a predetermined threshold of the MBS session users required for the multicast service, the UPF 320 may transmit the MBS session information to the SMF 310. If the counter does not meet the threshold, the MBS session will not start. This counter can be used for MBS session management to ensure that sufficient UEs will participate in the MBS session.

[0093] At 624, the UPF 320 transmits the MBS session information to the SMF 310. In some embodiments, the counter and corresponding threshold described above with reference to 616 may alternatively be implemented at this time.

[0094] At 626, the SMF 310 transmits an MBS session start request to the AMF 305. At 628, the AMF 305 transmits the session start request to the 5G NR RAN 120. At 630, the UE 110 connects to the MBS session via the UPF 320 for user plane data for the multicast service. In some embodiments, the unicast PDU session may be released. In other embodiments, the unicast PDU session may be modified. To ensure service continuity, the network may implement a protection timer or QoS threshold condition before releasing or modifying the unicast PDU session.

[0095] Figure 7 A method 700 for QoS-based multicast to unicast handover according to various exemplary embodiments is shown. Method 700 will be described with reference to Figure 1 the network arrangement 100 and Figure 2 the UE 110. Method 700 involves operations performed on the UE 110 side.

[0096] At 705, the UE 110 is currently configured with an ongoing MBS session. At 710, the UE 110 determines whether the network function has provided a QoS threshold corresponding to the MBS session. For example, the UPF 320 and / or the MSF 325 may provide the QoS threshold before the MBS session is established, during the MBS session establishment, or after the MBS session has been established.

[0097] If the network function has not provided the QoS parameters, method 700 proceeds to 715. At 715, the UE 110 sets the QoS threshold. The UE 110 may determine the QoS threshold based on any suitable factors, such as but not limited to information related to similar sessions locally stored at the UE 110, UE 110 capabilities, QoS of other similar sessions, the presence of concurrent data streams, serving public land mobile network (PLMN), type of cell, etc.

[0098] Regardless of whether the QoS parameters are provided by the network function or set by the UE 110, method 700 proceeds to 720. At 720, the UE 110 monitors one or more QoS parameters. For example, during an MBS session, the UE 110 may collect measurement data corresponding to the MBS session and / or performance data corresponding to the MBS session via the air interface. This data may provide a basis for determining the QoS parameters.

[0099] At 725, the UE 110 determines whether the QoS parameters meet the QoS threshold. If the QoS parameters do not fall below the QoS threshold, method 700 returns to 720, where the UE 110 continues to monitor the QoS parameters. If the QoS parameters fall below the QoS threshold, method 700 proceeds to 730.

[0100] At 730, the UE 110 switches to a unicast PDU session. If there is an ongoing unicast PDU session in parallel with the multicast session, the UE 110 may switch to the ongoing unicast PDU session. If there is no ongoing unicast PDU session, the UE 110 may initiate a PDU session establishment procedure and switch to that PDU session after establishing the PDU session. Subsequently, method 700 ends.

[0101] In some embodiments, after the UE 110 switches to a unicast PDU session, the UE 110 may transmit an MBS session release request to terminate the MBS session and release the MBS bearer context. In other embodiments, the UE 110 may wait for a predetermined amount of time and then check whether the MBS session QoS has returned to an acceptable level.

[0102] Figure 8 A signaling diagram 800 for multicast to unicast handover according to various exemplary embodiments is shown. With reference to Figure 1 the network device 100, Figure 2 the UE 110, and Figure 3 the schematic overview 300, the signaling diagram 800 is described.

[0103] The signaling diagram 800 pertains to a scenario in which the UE 110 is currently configured with a multicast session. For example, the UE 110 may pre - empt the 5G RAN 120 and receive multimedia data for network services via the MBS session. The signaling diagram 800 includes the UE 110, 5G NR RAN 120, AMF 305, SMF 310, UPF 320, and MSF 325.

[0104] In 802, the MBS session is in progress. At this time, UE 110 may also be configured with an active unicast session for other network services. Similar to signaling diagrams 500 - 600, signaling diagram 800 depicts three counters and corresponding thresholds. One counter may be implemented at MSF 325, another counter may be implemented at UPF 320, and another counter may be implemented at SMF 310. The ways in which these counters and / or thresholds can be utilized will be described below. However, the use of all three counters and thresholds is merely exemplary. Each counter and corresponding threshold can be independent or can be used in combination with other counters and corresponding thresholds.

[0105] In 804, MSF 325 and / or UPF 320 identify that the number of UEs subscribed to receive the same content has dropped below a predetermined threshold. For example, the network may implement a counter that tracks the number of UEs subscribed to receive the same content. This threshold may indicate to the network that it is not necessary to utilize the MBS session for that number of UEs.

[0106] In 806, MSF 325 transmits an MBS session stop request to SMF 310. For example, the MBS session stop request may travel to SMF 310 via UPF 320. In 808, SMF 310 transmits an MBS session stop response to SMF 310. As will be described below, the counter implemented at UPF 320 and / or the counter implemented at SMF 310 may provide a basis for the MBS session stop.

[0107] In 810, UE 110 sends a multicast stop request to UPF 320. The multicast stop request may include the PDU session ID, TMGI, and SUPI of UE 110. For any suitable reason, UE 110 may be triggered to send this message.

[0108] In 812, UPF 320 uses the counter. As described above with reference to signaling diagrams 500 - 600, the counter can be used for MBS session management to ensure that the MBS session does not have too many or too few users. In this example, it is assumed that the counter has dropped below a predetermined threshold.

[0109] In 814, UPF 320 sends an indication that a limited number of UEs are accessing the MBS session to SMF 310. In 816, SMF 310 uses the counter. As described above with reference to signaling diagrams 500 - 600, the counter can be used for MBS session management to determine whether UEs in different TMGIs, service areas, RNAs, etc. are accessing the multicast session. The counter can be incremented based on the indication in 814 and / or any other suitable factors.

[0110] In 818, the SMF 310 sends a session modification request to the UPF 320 via the TMGI and the MBS session stop request. The MBS session stop request can be used for a variety of different purposes. For example, due to the multicast stop request transmitted in 810, the MBS session stop request can be specific to the UE 110. Alternatively, the request can be specific to the TMGI, i.e., the service area of the entire MBS session based on any one or more of the above counters.

[0111] In 820, the SMF 310 can transmit the MBS session stop request to the AMF 305. In 822, the AMF 305 can forward the MBS session stop request to the 5G NR RAN 120.

[0112] In 824, the UE 110 connects to an existing MBS session using an ongoing PDU session via unicast or by establishing a new PDU session.

[0113] Figure 9 A signaling diagram 900 for multicast to unicast handover according to various exemplary embodiments is shown. Refer to Figure 1 the network arrangement 100, Figure 2 the UE 110, and Figure 3 the schematic overview 300 to describe the signaling diagram 900.

[0114] The signaling diagram 900 relates to a scenario in which the UE 110 is currently configured with a multicast session and moves to a RAN that does not support MBS. The signaling diagram 900 includes the UE 110, the 5G NR RAN 120, the 5GNR RAN 122, the AMF 305, the SMF 310, the UPF 320, and the MSF 325.

[0115] In 902, the MBS session is in progress. In 904, the MSF 325 transmits MBS availability information to the UE 110. The MBS availability information can include an indication of the ongoing MBS session and the MBS bearer context, such as a list of TMGIs of the ongoing MBS session, a list of service areas, and other session information. The MBS availability information can travel from the MSF 325 to the UE 110 via the application layer and the user plane. Additionally, the MBS availability information can be provided to the UE 110 for any suitable reason, such as but not limited to an active MBS session, an indication of the UE 110 mobility, the presence of an ongoing and relevant MBS session near the UE 110, the initiation of an MBS session, etc.

[0116] At 906, UE 110 moves to a different RAN. For example, UE 110 may camp on 5G NR RAN 120 and then move to 5G NR RAN 122. In this example, 5G NR RAN 122 does not support MBS. At 908, UE 110 performs an RNA update for 5G NR RAN 122.

[0117] At 910, MSF 325 and / or UPF 320 may buffer the content of UE 110. For example, in anticipation that UE 110 may attempt to resume the session using a unicast PDU session, MSF 325 and / or UPF 320 may buffer the content data. If MSF 325 and / or UPF 320 recognize a unicast request that includes information associated with UE 110, MSF 325 and / or UPF 320 may resume the session and include the buffered data so that the user of UE 110 does not miss any content.

[0118] At 912, UE 110 transmits a PDU setup request to UPF 320. The request may include an indication of the previous MBS session. For example, the request may include the TMGI and the session ID. This allows the network to determine that the buffered content data is intended for UE 110.

[0119] At 914, authentication and authorization are performed among various network functions (e.g., SMF 310, UPF 320, MSF 325, and other appropriate network functions) for the activation of the user plane and control plane of the unicast session.

[0120] At 916, UE 110 establishes a unicast session to continue the data stream. In some embodiments, this may be a new PDU session. In other embodiments, the PDU session may be ongoing in parallel with the MBS service.

[0121] Exemplary embodiments are not limited to unicast to multicast handover and vice versa. As will be described below, there may be other reasons for UE 110 to switch between unicast and multicast.

[0122] Figure 10 A signaling diagram 1000 for facilitating unicast to multicast handover of UE 110 according to various exemplary embodiments is shown. Signaling diagram 1000 includes UE 110, 5G NR RAN 120, UPF 320, MSF 325, PCF 315A Unified Data Management (UDM) 1001, and content provider 1002.

[0123] In 1010, a unicast session of UE 110a is in progress. In 1012, UPF 320 and / or MSF 325 identify that multiple UEs within a tracking area are accessing the same content. This may indicate to the network that an MBS session may be beneficial for network resource efficiency.

[0124] In 1014, MSF 325 may send an Nnef session request to PCF 315. The Nnef session request may include a data network name (DNN), an identification of MSF 325, an indication of the type of traffic requested (e.g., MBS), and an indication of the content to be accessed.

[0125] In 1016, UDM 1001 sends subscriber management data to PCF 315. Those skilled in the art should understand that UDM 1001 generally refers to a centralized network component that manages network user data. The subscriber management data may include, but is not limited to, SUPI, TMGI, the type of service requested (e.g., MBS), and whether access to the requested content is permitted.

[0126] In 1018, authentication is performed between various network functions (e.g., MSF 325, UDM 1001, and PCF 315) and content provider 10002. In this example, MBS for specific content is permitted.

[0127] In 1020, an MBS session start request is transmitted from content provider 1002 to 5G NR RAN 120 via MSF 325. Although not shown in signaling diagram 1000, this request may be received and forwarded by various network components. In 1022, an MBS session start response is transmitted from 5G NR RAN 120 to the content provider via MSF 325. In 1024, UE 110 connects to the MBS session and receives a multicast service from content provider 1002.

[0128] Compared with signaling diagram 1000, if UE 110 wants to switch from an MBS session to a unicast session, UE 110 may utilize a PDU session modification or a request to create and join an already ongoing PDU session. However, if there is no already ongoing PDU session, additional signaling may be performed on the network side to perform the switch and establish a unicast PDU session. For example, MSF325 may send an Nnef create or modify request to PCF 315 for content delivery via the requested PDU session. This may also indicate that MSF 325 should add the multicast session content to the unicast delivery content. PCF 315 may also check with UDM 1001 to ensure that UE 110 has a subscription to receive the requested content. Once the authentication is complete, UE 110 may have direct content delivery from content provider 1002 via the unicast PDU session.

[0129] Figure 11 Signaling diagram 1100 is shown for collecting and analyzing data for unicast to multicast handover (and vice versa) by a Network Data Analytics Function (NWDAF) 1102 according to various exemplary embodiments. Those skilled in the art will understand that the NWDAF 1102 is a network function that performs operations for network automation, such as receiving inputs from other network components (e.g., network functions, UEs, cells, etc.), performing analysis on the inputs, and generating outputs based on the analysis. However, the reference to NWDAF is provided for illustrative purposes only, and different entities may refer to similar concepts by different names. Thus, the NWDAF as described herein may represent any mechanism for performing analysis for network automation.

[0130] During operation, various network nodes may provide inputs and receive outputs from the NWDAF 1102 to perform various aspects of network automation. At 1110, the AMF 305 may send a request to subscribe to the services of the NWDAF 1102. Similarly, at 1112 and 1114, the MSF 325 and the content provider 1002 respectively request to subscribe to the services of the NWDAF 1102. Note that in this example, there is no corresponding subscription request from the SMF 310 because the SMF 310 cannot receive services from the NWDAF 1102. For example, the SMF 310 only reports data to the NWDAF 1102 and does not receive any outputs, as will be described in more detail below. On the other hand, the AMF 305 and / or the MSF 325 are requesting the services of the NWDAF 1102 and thus are requesting to subscribe to these services.

[0131] At 1116, 1120, and 1124, the NWDAF 1102 respectively requests to subscribe to events of the AMF 305, the SMF 310, and the MSF 325 to receive information from these nodes. Then, various network nodes may start reporting information to the NWDAF 1102 via event notifications. For example, at 1118, the AMF 305 may provide an input to the NWDAF 1102 that includes UE mobility information, the count of UEs in different RNAs, TMGI-related information, etc. At 1122, the SMF 310 may provide an input that includes the count of PDU sessions supporting different MBS sessions. In another example, at 1126, the MSF 325 may provide an input that includes the count of UEs in the corresponding service area, the active content types in different TMGIs, the different available content types, etc.

[0132] In 1128, the NWDAF 1102 can process information received from various network nodes and generate outputs based on any suitable type of information. The outputs can be delivered to the respective nodes (e.g., AMF 305, MSF 325, and content provider 1002) subscribed to the NWDAF service via MBS session information notifications. For example, in 1134, the NWDAF 1102 can provide an analysis to the AMF 305 that provides a basis for automatic MBS session activation and deactivation in different RNAs. In another example, in 1130, the NWDAF 1102 can provide an analysis to the MSF 325 that provides a basis for automatic MBS session activation and deactivation for each content delivery. In yet another example, in 1130, the NWDAF 1102 can provide an analysis to the MSF 325 that provides a basis for automatic session activation and deactivation for different service area IDs. In 1132, the NWDAF 1102 can provide an output to the content provider 1002 such that the content provider understands the type of data delivery for its content. Thus, the NWDAF 1102 can provide outputs that are used to ensure the efficient use of resources based on the expected network load.

[0133] Figure 12 A signaling diagram 1200 for UE 110 and network synchronization regarding MBS sessions according to various exemplary embodiments is shown. It should be understood that the signaling diagram 1200 includes three different signaling scenarios related to synchronization. These different scenarios can relate to various situations that occur during an MBS session. The first exemplary scenario 1220 involves the UE 110 directly requesting the UPF 320 to perform actions related to the MBS session. The second exemplary scenario 1240 involves the UPF 320 requesting data related to the MBS session from the 5G NR RAN 120. The third exemplary scenario 1260 involves the SMF 310 of the content provider 1002 maintaining the active UE count of the MBS session. It should be understood that the signaling related to these exemplary scenarios can be implemented individually or in combination with signaling from other scenarios.

[0134] In 1210, there can be considered an ongoing active MBS session for the UE 110. This active MBS session can be a precursor to each of scenarios 1120, 1140, and 1160.

[0135] In scenario 1220, the UE 110 may signal to the UPF 320 that the UE 110 is no longer interested in a particular MBS session. For example, when the UE 110 closes an application or content channel, it would be a waste of network resources to continue providing the MBS service as if the UE 110 were still interested in watching the provided content. Therefore, in response to an event at the UE 110, such as exiting an application or switching content channels, at 1222, the UE 110 may be triggered to send a multicast stop request to the UPF 320. The multicast session stop request may include information such as, but not limited to, TMGI, SUPI, session ID, etc. In response, at 1224, the network may provide a multicast stop response to the UE 110.

[0136] In scenario 1240, the UPF 320 and / or MSF 325 may maintain a count of the active UEs 110 with respect to an MBS session. For example, at 1242, the UPF 320 may transmit a multicast data request to the 5G NR RAN 120. The request may include a request for the count of UEs accessing the content per TMGI. At 1244, the 5G NR RAN 120 may broadcast an MBS count request to the connected UEs 110 and then may receive responses from one or more of the connected UEs 110. At 1246, the 5G NR RAN 120 provides a multicast response to the UPF 320 with the active count of UEs per multicast session. At 1248, the UPF 320 and / or MSF 325 may maintain a count of the active UEs via the respective multicast sessions and may thus use this information for efficient resource utilization.

[0137] In scenario 1260, the SMF 310 may maintain a count of the active UEs 110 with respect to an MBS session. For example, at 1262, the SMF 310 may transmit a request to the AMF 305. The request may include a Namf communication N2 information subscription request for the active UEs to access the respective multicast sessions with session ID and TMGI. At 1264, the AMF 305 may forward the request to the 5G NR RAN 120 via an N2 session information request. At 1266, the 5G NR RAN 120 may maintain a count of the active UEs per multicast session. At 1268, the 5G NR RAN 120 may then provide the count to the AMF 305 in an N2 session information response. At 1270, the AMF 305 may then forward the count to the SMF 310 in an Nammf communication N2 information notification. At 1272, the SMF 310 may then maintain a count of the active UEs within different sessions on the multicast and thus synchronize with the service function control plane for session activation and suspension.

[0138] Those skilled in the art will understand that the above-described exemplary embodiments can be implemented with any suitable software configuration or hardware configuration or a combination thereof. Exemplary hardware platforms for implementing the exemplary embodiments can include, for example, Intel x86-based platforms with compatible operating systems, Windows OS, Mac platforms and MAC OS, mobile devices with operating systems such as iOS, Android, etc. In other examples, the exemplary embodiments of the above methods can be embodied as programs including lines of code stored on a non-transitory computer-readable storage medium, which, when compiled, can be executed on a processor or microprocessor.

[0139] Although this patent application describes various combinations of various embodiments each having different features, those skilled in the art will understand that any feature of one embodiment can be combined with the features of other embodiments in any manner not negated by the disclosure or features that are not functionally or logically inconsistent with the operation of the devices of the disclosed embodiments of the present invention or the functions thereof.

[0140] It is well known that the use of personally identifiable information should follow privacy policies and practices that are recognized as meeting or exceeding industry or government requirements for maintaining user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of inadvertent or unauthorized access or use, and the nature of the authorized use should be clearly explained to users.

[0141] It will be apparent to those skilled in the art that various modifications can be made to the present disclosure without departing from the essence or scope of the present disclosure. Therefore, the present disclosure is intended to cover modifications and variations of the present disclosure, provided that these modifications and variations are within the scope of the appended claims and their equivalents.

Claims

1. A method configured to be performed by a User Equipment (UE), comprising: receiving first data via a session from a first Radio Access Network (RAN) node, wherein the first RAN node does not support Multicast Broadcast Service (MBS); receiving first information from the network, the first information indicating the availability of the MBS on a second RAN node; transmitting second information to the network; performing a handover from the first RAN node to the second RAN node; and receiving second data via a multicast session from the second RAN node, wherein the handover from the session to the multicast session is triggered by a Session Management Function (SMF) using a session modification operation.

2. The method according to claim 1, wherein the session modification operation comprises the SMF transmitting a session modification request to a User Plane Function (UPF).

3. The method according to claim 1, wherein the first information identifies the second RAN node, and wherein the second information indicates to the second RAN node that the UE is interested in the multicast session, the second information comprising an identifier of the UE and a PDU identifier of a Packet Data Unit (PDU) session for receiving the first data.

4. The method according to claim 3, wherein the multicast session is triggered by the SMF based on information received from the UE and a plurality of other UEs.

5. The method according to claim 1, wherein the second information is a multicast join request transmitted to a User Plane Function (UPF) of the network, the multicast join request comprising at least one of a group identifier, a UE identifier, a Tracking Area Identifier, or a PDU identifier of a session for receiving the first data.

6. The method according to claim 1, wherein the second information is a multicast interest indication transmitted to the RAN, the multicast interest indication comprising at least one of a UE identifier, a PDU identifier of a session for receiving the first data.

7. A non-transitory computer-readable storage medium storing a program, which when executed by a processor of a User Equipment (UE) causes the processor to perform the method according to any one of claims 1-6.

8. A User Equipment (UE), comprising: a transceiver configured to communicate with a network; and a processor communicatively coupled to the transceiver and configured to perform operations, the operations comprising: receiving first data via a session from a first Radio Access Network (RAN) node, wherein the first RAN node does not support Multicast Broadcast Service (MBS); receiving first information from the network, the first information indicating the availability of the MBS on a second RAN node; transmitting second information to the network; and performing a handover from the first RAN node to the second RAN node; and receiving second data via a multicast session from the second RAN node, wherein the handover from the session to the multicast session is triggered by a Session Management Function (SMF) using a session modification operation.

9. The UE according to claim 8, wherein the first information identifies the second RAN node, and wherein the second information indicates to the second RAN node that the UE is interested in the multicast session, the second information including an identifier of the UE and a PDU identifier of a packet data unit (PDU) session for receiving the first data.

10. The UE according to claim 8, wherein the session modification operation includes the SMF transmitting a session modification request to a user plane function (UPF).

11. A method configured to be performed by a session management function (SMF) of a cellular network, comprising: determining that a user equipment (UE) is configured to receive data via a first session from a first radio access network (RAN) node, wherein the first RAN node does not support multicast broadcast service (MBS); identifying a handover of the UE between the first RAN node and a second RAN node that supports MBS; triggering a handover from the first session to a multicast session, wherein the UE is configured to receive data from the second RAN node via the multicast session; and transmitting a session modification request to a user plane function (UPF) to switch from the first session to the multicast session.

12. The method according to claim 11, wherein the session modification request is transmitted via an N4 interface.

13. The method according to claim 11, further comprising: receiving an MBS context including a common tunnel endpoint identifier (C-TEID).

14. The method according to claim 13, wherein the MBS context further includes quality of service (QoS) information.

15. A non-transitory computer-readable storage medium storing a program, which when executed by a processor causes the processor to perform operations including the following: determining that a user equipment (UE) is configured to receive data via a first session from a first radio access network (RAN) node, wherein the first RAN node does not support multicast broadcast service (MBS); identifying a handover of the UE between the first RAN node and a second RAN node that supports MBS; triggering a handover from the first session to a multicast session, wherein the UE is configured to receive data from the second RAN node via the multicast session; and transmitting a session modification request to a user plane function (UPF) to switch from the first session to the multicast session.

16. The non-transitory computer-readable storage medium according to claim 15, wherein the session modification request is transmitted via an N4 interface.

17. The non-transitory computer-readable storage medium according to claim 15, wherein the operations further comprising: receiving an MBS context including a common tunnel endpoint identifier (C-TEID).

18. The non-transitory computer-readable storage medium according to claim 17, wherein the MBS context further includes quality of service (QoS) information.

Images