Method for multicast and broadcast service delivery mode switching in 5g networks

Abstract

An overall architecture to integrate multicast and broadcast services into a common 5G core network. The architecture can provide methods and systems to switch the delivery mode of messages transmitted to user equipment (UE) from unicast mode to multicast mode. The methods include triggering an event at the UE, network function, content provider, or RAN node to initiate a switching procedure; procedures for UE initiated switching from unicast to multicast; procedures for network initiated switching from unicast mode to multicast mode; and procedures for RAN initiated switching from unicast mode to multicast mode. The architecture can also provide methods to switch the delivery mode from multicast mode to unicast mode. The methods can include triggering an event at the UE, network function, content provider, or RAN node to initiate a switching procedure; procedures for UE initiated switching from multicast mode to unicast mode; procedures for network initiated switching from multicast mode to unicast mode; and procedures for RAN initiated switching from multicast mode to unicast mode.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit of U.S. Provisional Patent Application 62 / 975,858, filed February 13, 2020, entitled “METHODS OF DELIVERY MODE SWITCH FOR MULTICAST AND BROADCAST SERVICE IN A 5G NETWORK,” the contents of which are incorporated herein by reference. Background Technology

[0003] Switching between unicast and multicast / broadcast delivery modes is supported in EPS MBMS via MooD and MBMS user service consumption reports. MooD is an application-layer solution; therefore, it exhibits the following inefficiencies.

[0004] Control signaling is transmitted at the application layer to enable handover. Because many different applications will use multicast / broadcast services, transmitting control information at the application layer may not be efficient. This approach may require all applications to support the MooD protocol. This approach also tends to result in slower response times for both adjusting the core network and radio resource usage policies targeting the primary resource usage status within the core network or radio network.

[0005] Making the decision to switch between unicast and multicast based on information that may not be available at the application layer (such as RAN conditions, the number of devices receiving the content, and the location of the devices receiving the content) may be more effective.

[0006] In addition, there is no traditional method that relies on non-access stratum (NAS) signaling between the UE and the network for switching delivery modes between unicast and multicast or between unicast and broadcast. Summary of the Invention

[0007] A system and method for providing a user equipment with handover between at least two unicast message transmissions, multicast message transmissions, and broadcast message transmissions via a 5G network. The procedure can be executed in this manner. It is determined whether a triggering event has occurred at one or more of the user equipment (e.g., UE), network equipment, content provider system, or RAN node. This triggering event indicates a need for handover between the first and second of the unicast message transmissions, multicast message transmissions, and broadcast message transmissions. The following operation is initiated: based on the occurrence of the triggering event, a handover is initiated from the first of the unicast message transmissions, multicast message transmissions, and broadcast message transmissions to the user equipment, to the second of the unicast message transmissions, multicast message transmissions, and broadcast message transmissions.

[0008] The purpose of the summary is to introduce selected concepts of the present disclosure in a simplified form, which are further described in the detailed description below. The summary is neither intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. In addition, the claimed subject matter is not limited to solving any or all of the disadvantages with any part of the disclosure. BRIEF DESCRIPTION OF DRAWINGS

[0009] Figure 1A An exemplary communication system in which methods and apparatuses described and claimed herein can be embodied is illustrated.

[0010] Figure 1B A block diagram of an exemplary apparatus or device configured for wireless communication is illustrated.

[0011] Figure 1C A system diagram illustrating an exemplary radio access network (RAN) and core network is shown.

[0012] Figure 1D A system diagram illustrating another exemplary RAN and core network is shown.

[0013] Figure 1E A system diagram of another exemplary RAN and core network is shown.

[0014] Figure 1F A block diagram of an exemplary computing system is shown.

[0015] Figure 1G A block diagram of another exemplary communication system is shown.

[0016] Figure 2 A 5G system services based architecture is shown.

[0017] Figure 3 A non-roaming 5G system architecture in a reference point representation is shown.

[0018] Figure 4 NAS transport for SM, SMS, UE policy and LCS is shown conceptually.

[0019] Figure 5 A reference architecture for an evolved packet system with E-UTRAN and UTRAN (MBMS broadcast mode only) in TS 23.246 is shown.

[0020] Figure 6 A 5G MBS architecture is shown.

[0021] Figure 7A A procedure for UE initiated switch from unicast to multicast via control plane is shown.

[0022] Figure 7BA procedure for network-initiated switch from multicast to unicast is shown.

[0023] Figure 8 A procedure for network-initiated switch from multicast to unicast is shown.

[0024] Figure 9 A procedure for network-initiated switch from multicast to unicast is shown.

[0025] Figure 10 A procedure for network-initiated switch from multicast to unicast is shown.

[0026] Figure 11 A procedure for network-initiated switch from multicast to unicast is shown.

[0027] Figure 12 A procedure for network-initiated switch from multicast to unicast is shown.

[0028] Figure 13 A user interface presented by a user equipment is shown. DETAILED DESCRIPTION

[0029] The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunications network technologies, including radio access, the core transport network, and service capabilities, including coding / decoding, security, and quality of service. Recent radio access technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), and LTE-Advanced standards. 3GPP has begun work on standardization of the next generation of cellular technology, also referred to as "5G," called New Radio (NR). The development of the 3GPP NR standards is expected to include definition of a new radio access technology (new RAT) that is expected to include a new flexible radio access at sub-6 GHz, as well as a new mobile broadband radio access at above 6 GHz. The flexible radio access is expected to include a new non-backwards compatible radio access in new spectrum at sub-6 GHz, and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a broad set of 3GPP NR use cases with different requirements. The mobile broadband at above 6 GHz is expected to include cmWave and mmWave spectrum that will provide the opportunity for ultra-mobile broadband access, for example, for indoor applications and hotspots. In particular, the mobile broadband at above 6 GHz is expected to share a common design framework as the flexible radio access at sub-6 GHz, with cmWave and mmWave specific design optimizations.

[0030] 3GPP has identified a variety of use cases that NR is expected to support, resulting in diverse user experience requirements for data rates, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (e.g., broadband access in dense areas, ultra-high-bandwidth indoor access, broadband access in crowds, 50+ Mbps everywhere, ultra-low-cost broadband access, vehicular mobile broadband), critical communications, large-scale machine-type communications, network operations (e.g., network slicing, routing, migration and interworking, energy saving), and enhanced vehicle-to-everything (eV2X) communications, which can include any of the following: vehicle-to-vehicle communications (V2V), vehicle-to-infrastructure communications (V2I), vehicle-to-network communications (V2N), vehicle-to-pedestrian communications (V2P), and vehicle-to-other-entities communications. Specific services and applications within these categories include, for example: surveillance and sensor networks, remote device control, two-way remote control, personal cloud computing, video streaming, cloud-based wireless offices, first responder connectivity, automotive electronic calling, disaster alerts, real-time gaming, multi-person video calling, autonomous driving, augmented reality, haptic internet, and virtual reality, among others. This paper considers all of these and other use cases.

[0031] Figure 1A An embodiment of an exemplary communication system 100 is shown, in which methods and apparatuses for switching delivery modes for multicast and broadcast services in a network, such as those shown in Figures 1 to 100, are used. Figure 12 The systems and methods described and claimed herein are illustrated. As shown, an exemplary communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f and / or 102g (which may generally or commonly be referred to as WTRU 102), radio access networks (RANs) 103 / 104 / 105 / 103b / 104b / 105b, core networks 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and a V2X server (or ProSe functionality and server) 113. However, it should be understood that the embodiments disclosed in this invention contemplate any number of WTRUs, base stations, networks and / or network elements. Each of WTRU 102a, 102b, 102c, 102d, 102e, 102f, and 102g can be any type of device or apparatus configured to operate and / or communicate in a wireless environment. While each of WTRU 102a, 102b, 102c, 102d, 102e, 102f, and 102g... Figures 1A-1EWTRUs are depicted as hand-held wireless communication devices; however, it is to be appreciated that the WTRUs can each include or can be embodied as any type of device that is configured to transmit and / or receive wireless signals, including, by way of example, user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a

[0032] The communications system 100 can also include a base station 114a and a base station 114b. Base stations 114a can be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or the other networks 112. Base stations 114b can be any type of device configured to wirelessly interface with at least one of the RRHs (Remote Radio Heads) 118a, 118b, TRPs (Transmit and Receive Points) 119a, 119b, and / or RSUs (Road Side Units) 120a and 120b to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the other networks 112, and / or a V2X server (or ProSe function and server) 113. The RRHs 118a, 118b can be any type of device configured to wirelessly interface with at least one of the WTRUs 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or the other networks 112. The TRPs 119a, 119b can be any type of device configured to wirelessly interface with at least one of the WTRUs 102d to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or the other networks 112. The RSUs 120a and 120b can be any type of device configured to wirelessly interface with at least one of the WTRUs 102e or 102f to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the other networks 112, and / or a V2X server (or ProSe function and server) 113. By way of example, the base stations 114a, 114b can be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and so on. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b can include any number of interconnected base stations and / or network elements.

[0033] The base stations 114a can be part of the RAN 103 / 104 / 105, which can also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114b can be part of the RAN 103b / 104b / 105b, which can also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a can be configured to transmit and / or receive wireless signals within a particular geographic area, which can be referred to as a cell (not shown). The base station 114b can be configured to transmit and / or receive wireless signals in a particular geographic area, which can be referred to as a cell (not shown), that is a method, system, and device for network mode switching for multicast and broadcast services delivery. A cell can further be divided into cell sectors. For example, a cell associated with a base station 114a can be divided into three sectors. Thus, in one embodiment, the base station 114a can include three transceivers, one for each sector of the cell. In one embodiment, the base station 114a can employ multiple-input multiple-output (MIMO) technology and, therefore, can utilize multiple transceivers for each sector of the cell.

[0034] The base stations 114a can communicate with one or more of the WTRUs 102a, 102b, 102c over the air interface 115 / 116 / 117, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared, ultraviolet, visible light, cmWave, mmWave, etc.). The air interface 115 / 116 / 117 can be established using any suitable radio access technology (RAT). The base station 114b can communicate with one or more of the RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a and 120b over a wired or air interface 115b / 116b / 117b, which can be any suitable wired (e.g., cable, optical fiber, etc.) or wireless communication link (e.g., radio frequency (RF), microwave, infrared, ultraviolet, visible light, cmWave, mmWave, etc.). The air interface 115b / 116b / 117b can be established using any suitable radio access technology (RAT).

[0035] The RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a, 120b can communicate with one or more of the WTRUs 102c, 102d, 102e, 102f over an air interface 115c / 116c / 117c, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115c / 116c / 117c can be established using any suitable radio access technology (RAT).

[0036] The WTRUs 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g can communicate with one another over an air interface 115d / 116d / 117d (not shown in the figure), which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115d / 116d / 117d can be established using any suitable radio access technology (RAT).

[0037] More specifically, as noted above, the communications system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, or RRHs 118a, 118b, TRPs 119a, 119b, and RSUs 120a, 120b, and WTRUs 102c, 102d, 102e, 102f in the RAN 103b / 104b / 105b can implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish the air interface 115 / 116 / 117 or 115c / 116c / 117c under an unlicensed radio access (E-UTRA), using wideband CDMA (WCDMA). WCDMA can include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed Downlink Packet Access (HSDPA) and / or High-Speed Uplink Packet Access (HSUPA).

[0038] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c, or RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a, 120b in the RAN 103b / 104b / 105b, and the WTRUs 102c, 102d, 102e, 102f can implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can establish the air interface 115 / 116 / 117 or 115c / 116c / 117c respectively using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A). In the future, the air interface 115 / 116 / 117 can implement 3GPP NR technology. The LTE and LTE-A technology includes LTE D2D and V2X technology and interfaces such as sidelink communication. The 3GPP NR technology includes NR V2X technology and interfaces such as sidelink communication.

[0039] In an embodiment, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, or RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a, 120b in the RAN 103b / 104b / 105b, and the WTRUs 102c, 102d, 102e, 102f can implement a radio technology such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0040] Figure 1ABase station 114c can be, for example, a wireless router, a home node B, a home evolution node B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas (such as commercial areas, homes, vehicles, campuses, etc.) to implement the methods, systems, and apparatuses disclosed herein for switching delivery modes of multicast and broadcast services in a network. In one embodiment, base station 114c and WTRU 102e can implement radio technologies (such as IEEE 802.11) to establish a wireless local area network (WLAN). In one embodiment, base station 114c and WTRU 102d can implement radio technologies (such as IEEE 802.15) to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114c and WTRU 102e can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b may have a direct connection to the Internet 110. Therefore, base station 114c may not need to access the Internet 110 via core networks 106 / 107 / 109.

[0041] RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b can communicate with core network 106 / 107 / 109, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU 102a, 102b, 102c, and 102d. For example, core network 106 / 107 / 109 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication.

[0042] although Figure 1A As not shown, but it should be understood that RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b and / or core network 106 / 107 / 109 can communicate directly or indirectly with other RANs that use the same RAT as or a different RAT than RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b. For example, in addition to being connected to RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b, which may be utilizing E-UTRA radio technology, core network 106 / 107 / 109 can also communicate with another RAN (not shown) using GSM radio technology.

[0043] The core network 106 / 107 / 109 can also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d, 102e to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 can include circuit-switched telephone networks that provide infrastructure for the provision of voice telephony. The Internet 110 can include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) suite including TCP / IP in the Internet protocol suite (IP). The networks 112 can include wired or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 can include another core network connected to one or more RANs, which can employ the same RAT as the RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b or a different RAT.

[0044] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 can include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d, and 102e can include multiple transceivers for communicating with different wireless networks over different wireless links to implement methods, systems, and devices for delivery mode switching for multicast and broadcast services in networks. Figure 1A The WTRU 102e shown in Figure 1 A can be configured to communicate as a wireless device with the base stations 114a and 114c, which can employ a cellular-based radio technology, and with the base station 114b, which can employ an IEEE 802 radio technology.

[0045] Figure 1B is a block diagram of an example apparatus or device configured for wireless communication, such as, for example, a WTRU 102, in accordance with the embodiments exemplified herein. As shown in Figure 1B As shown in FIG. 1 IB, the example WTRU 102 can include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicators 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It should be appreciated that the WTRU 102 can include any sub-combination of the foregoing elements while remaining consistent with embodiments. Additionally, the embodiments contemplate that the base stations 114a and 114b, and / or the nodes that base stations 114a and 114b can represent, such as but not limited to transceiver stations (BTS), Node-Bs, site controllers, access points (APs), home nodes-B, evolved home nodes-B (eNode Bs), home evolved home node-B (HeNBs), home evolved home node-B gateways, and proxy nodes, can include any sub-combination of the foregoing elements.Figure 1B Some or all of the elements depicted and described herein.

[0046] The processor 118 can be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 can perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to the transceiver 120, which can be coupled to the transmit / receive element 122. While Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, it is to be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

[0047] The transmit / receive element 122 can be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 115 / 116 / 117. For example, in one embodiment, the transmit / receive element 122 can be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmit / receive element 122 can be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 can be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0048] In addition, although the transmit / receive element 122 is depicted in the Figure 1B WTRU 102 can include any number of transmit / receive elements 122. More specifically, the WTRU 102 can employ MIMO technology. Thus, in one embodiment, the WTRU 102 can include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115 / 116 / 117.

[0049] The transceiver 120 can be configured to modulate information to be transmitted by the transmit / receive element 122 and to demodulate information received by the transmit / receive element 122. As indicated above, the WTRU 102 can be a multi-mode device. Thus, the transceiver 120 can include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

[0050] The processor 118 of the WTRU 102 can be coupled to, and can receive user input data from, the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicators 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 can also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicators 128. In addition, the processor 118 can access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and / or the removable memory 132. The non-removable memory 130 can include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 can include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In one embodiment, the processor 118 can access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0051] The processor 118 can receive power from the power source 134, and can be configured to distribute and / or control the power to the other components in the WTRU 102. The power source 134 can be any suitable device for powering the WTRU 102. For example, the power source 134 can include one or more dry cell batteries, solar cells, fuel cells, and the like.

[0052] The processor 118 can also be coupled to the GPS chipset 136, which can be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or instead of, the information from the GPS chipset 136, the WTRU 102 can receive location information over the air interface 115 / 116 / 117 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 can acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0053] The processor 118 can also be coupled to other peripherals 138 that can include one or more software modules and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 can include various sensors such as an accelerometer, biometrics (e.g., finger print) sensors, an electronic compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port or other interconnect, a vibration device, a television transceiver, a FM radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0054] The WTRU 102 can be embodied in other apparatuses or devices that are part of a larger system, such as a sensor, consumer electronics device, a wearable device (such as a smart watch or smart clothing), a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle (such as a car, truck, train, or airplane), etc. The WTRU 102 can connect to other components, modules, or systems of such apparatuses or devices via one or more interconnects, such as an interconnect that can include one of the peripherals 138.

[0055] Figure 1C is a system diagram of the RAN 103 and the core network 106 according to an embodiment. As Figure 1C described above, the RAN 103 can be in communication with the WTRUs 102a, 102b, 102c over the air interface 115. The RAN 103 can also be in communication with the core network 106. As shown, the RAN 103 can include Node-Bs 140a, 140b, 140c, which can each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115. The Node-Bs 140a, 140b, 140c can each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 can also include RNCs 142a, 142b. It will be appreciated that the RAN 103 can include any number of Node-Bs and RNCs, which can be in communication with the core network 106.

[0056] As Figure 1CAs shown, the Node-Bs 140a, 140b can communicate with the RNC 142a. Additionally, the Node-B 140c can communicate with the RNC 142b. The Node-Bs 140a, 140b, 140c can communicate with the respective RNCs 142a, 142b via an Iub interface. The RNCs 142a, 142b can be in communication with one another via an Iur interface. Each of the RNCs 142a, 142b can be configured to control the respective Node-Bs 140a, 140b, 140c to which it is connected. In addition, each of the RNCs 142a, 142b can be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, etc.

[0057] Figure 1C The core network 106 shown in Figure 1 can include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and / or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements can be owned and / or operated by an entity other than the core network operator.

[0058] The RNC 142a in the RAN 103 can be connected by an IuCS interface to the MSC 146 in the core network 106. The MSC 146 can be connected to the MGW 144. The MSC 146 and the MGW 144 can provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional

[0059] The RNC 142a in the RAN 103 can also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 can be connected to the GGSN 150. The SGSN 148 and the GGSN 150 can provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0060] As noted above, the core network 106 can also be connected to the networks 112, which can include other wired or wireless networks that are owned and / or operated by other service providers.

[0061] Figure 1Dis a system diagram of the RAN 104 and the core network 107 as the methods, systems, and devices that can implement delivery mode switching for multicast and broadcast services in a network as disclosed herein. As described above, the RAN 104 can employ E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 can also be in communication with the core network 107.

[0062] The RAN 104 can include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 can include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c can each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c can implement MIMO technology. Thus, the eNode-B 160a, for example, can use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0063] Each of the eNode-Bs 160a, 160b, and 160c can be associated with a particular cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and / or downlink, and the like. As shown, the eNode-Bs 160a, 160b, 160c can communicate with one another over an X2 interface. Figure 1D

[0064] Figure 1D The core network 107 as illustrated can include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107, it will be appreciated that any one of these elements can be owned and / or operated by an entity other than the operator of the core network

[0065] The MME 162 can be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an SI interface and can serve as a control node. For example, the MME 162 can be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 can also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0066] ​The serving gateway 164 can be connected to each of the eNode Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface. The serving gateway 164 can generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The serving gateway 164 can also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0067] The serving gateway 164 can also be connected to the PDN gateway 166, which can provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0068] The core network 107 can facilitate communications with other networks. For example, the core network 107 can include, or can communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. Further, the core network 107 can provide the WTRUs 102a, 102b, 102c with access to the networks 112, which can include other wired or wireless networks that are owned and / or operated by other service providers.

[0069] Figure 1E is a system diagram of the RAN 105 and the core network 109 according to the methods, systems, and devices for delivery mode switching for multicast and broadcast services in a network as disclosed herein. The RAN 105 can be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 117. As will be further discussed below, different functional entities of the WTRUs 102a, 102b, 102c, communication links between the RAN 105 and the core network 109 can be defined as reference points.

[0070] As Figure 1EAs shown, the RAN 105 can include base stations 180a, 180b, 180c, and an ASN gateway 182, although it will be appreciated that the RAN 105 can include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 180a, 180b, 180c can each be associated with a particular cell in the RAN 105 and can include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In one embodiment, the base stations 180a, 180b, 180c can implement MIMO technology. Thus, the base station 180a, for example, can use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 180a, 180b, 180c can also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, Quality of Service (QoS) policy enforcement, and the like. The ASN gateway 182 can serve as a traffic aggregation point and can be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.

[0071] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 can be defined as an Rl reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, 102c can establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 can be defined as an R2 reference point, which can be used for authentication, authorization, IP host configuration management, and / or mobility management.

[0072] The communication link between each of the base stations 180a, 180b, and 180c can be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 can be defined as an R6 reference point. The R6 reference point can include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[0073] As shown, Figure 1EAs shown, the RAN 105 can be connected to the core network 109. The communication link between the RAN 105 and the core network 109 can be defined as an R3 reference point, which includes protocols for facilitating data transfer and mobility management capabilities, for example. The core network 109 can include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements are depicted as part of the core network 109, it will be appreciated that any one of these elements can be owned and / or operated by an entity other than the core network operator.

[0074] The MIP-HA can be responsible for IP address management, and can enable the WTRUs 102a, 102b, and 102c to roam

[0075] Although not shown in FIG. 1, it will be appreciated that the RAN 105 can be connected to other ASNs, and the core network 109 can be connected to other core networks. The communication link between the RAN 105 and the other ASNs can be defined as an R4 reference point, which can include protocols for coordinating the Figure 1E

[0076] The RAN 105 can be in communication with the core network 109, which can be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c. For example, the core network 109 can be an operator's internal network, or the core network 109 can include one or more Figure 1A Figure 1C Figure 1D Figure 1E ​​​​The core network entities shown in the middle are identified by the names given to these entities in certain existing 3GPP specifications, but it will be appreciated that these entities and functions can in future be identified by other names, and that certain entities or functions can in future be combined in specifications published by 3GPP, including future 3GPP NR specifications. Thus, the particular network entities and functions described and shown in Figure 1A , Figure 1B , Figure 1C , Figure 1D and Figure 1E are provided by way of example only, and it is to be understood that the subject matter disclosed and claimed herein can be embodied in any similarly functioning communication system, whether presently defined or hereafter defined.

[0077] Figure 1F is a block diagram of an example computing system 90 in which one or more devices of the communication networks shown in Figure 1A , Figure 1C , Figure 1D and Figure 1E may be embodied, such as certain nodes or functional entities in the RAN 103 / 104 / 105, the core network 106 / 107 / 109, the PSTN 108, the Internet 110, or the other networks 112. The computing system 90 can comprise a computer or server and can be controlled primarily by computer readable instructions, which can be in the form of software, wherever and by whatever means such software is stored or accessed. Such computer readable instructions can be executed within a processor 91 to cause the computing system 90 to work in a particular manner. The processor 91 can be a general- purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate array (FPGA) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 91 can perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the computing system 90 to operate in a communication network. Coprocessor 81 is an optional processor, distinct from the main processor 91, that can perform additional functions or assist the processor 91. The processor 91 and / or coprocessor 81 can receive, generate, and process data relating to the methods and devices disclosed herein.

[0078] In operation, processor 91 fetches, decodes, and executes instructions, and transfers information to and from other resources via the computer system's main data-transfer path, system bus 80. Such a system bus connects the various components in the computer system 90 and defines the medium for data exchange. System bus 80 typically includes a data bus for sending data, an address bus for sending address information, and a control bus for sending controls. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.

[0079] Memory that is coupled to system bus 80 includes random access memory (RAM) 82, and read only memory (ROM) 93. Such memory stores instructions and data that are needed by processor 91 to implement various embodiments. ROM 93 is typically used to store instructions and / or data that are read during boot-up, while RAM 82 is used for the storage of instructions and / or data that is actively used while the processor 91 is running. Access to both ROM 93 and RAM 82 is typically provided by memory controller 92, which itself can be controlled by a CPU or other device.

[0080] In addition, computing system 90 can contain peripherals controller 83 responsible for communicating instructions from processor 91 to peripherals, such as printer 94, keyboard 84, mouse 95, and disk drive 85.

[0081] Display 86, which is controlled by display controller 96, is used to display visual output generated by computing system 90. Such visual output can include text, graphics, animated graphics, and video. The visual output can be provided in the form of a graphical user interface (GUI). Display 86 can be implemented with a CRT-based video display, an LCD-based flat-panel display, gas plasma-based flat-panel display, or a touch-panel. Display controller 96 includes electronic components required to generate a video signal that is sent to display 86.

[0082] Further, computing system 90 can contain communication circuitry, such as, for example, a network adapter 97, that can be used to connect computing system 90 to an external communications network, such as a Figure 1A 、 Figure 1B 、 Figure 1C 、 Figure 1D and Figure 1EThe computing system 90 can also include communication circuitry 95 that enables wired or wireless communication with the RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, the Internet 110, or other networks 112, in order to facilitate communication between the computing system 90 and other nodes or functional entities of these networks. The communication circuitry 95, alone or in combination with the processor 91, can be used to perform the transmitting and receiving steps of certain apparatuses, nodes, or functional entities described herein.

[0083] Figure 1G One embodiment of an exemplary communications system 111 in which methods and apparatuses described and claimed herein can be embodied is shown. As illustrated, the exemplary communications system 111 can include wireless transmit / receive units (WTRUs) A, B, C, D, E, F, base stations, a V2X server, and RSUs A and B, although it is understood that the embodiments disclosed herein contemplate any number of WTRUs, base stations, networks, and / or network elements. One or several or all of the WTRUs A, B, C, D, E can be out of range of the network (e.g., outside the cell coverage boundary as shown by the dashed line in the figure). The WTRUs A, B, C form a V2X group, with WTRU A being the group leader and WTRUs B and C being group members. The WTRUs A, B, C, D, E, F can communicate over a Uu interface or a sidelink (PC5) interface.

[0084] It should be understood that any or all of the apparatuses, systems, methods, and processes described herein can be embodied in a computer- executable program of instructions in a computer-readable storage medium (e.g., a non-transitory storage medium) that, when executed, implements the systems, methods, and processes described herein. In particular, any of the steps, operations, or functions described herein can be implemented in a computer program of instructions that, when executed, performs the steps, operations, or functions. The computer-readable storage medium includes volatile and non-volatile, removable and non-removable media implemented in any non-transitory (e.g., tangible or physical) method or technology for storage of information such as computer readable instructions, data structures, or other data. The computer-readable storage medium includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium that can be used to store the desired information and that can be accessed by a computer.

[0085] Figure 2 5G system in a non-roaming reference architecture with service-based interfaces in the control plane is shown.

[0086] Figure 3 A reference point representation diagram depicts the 5G system architecture in a non-roaming case, showing how various network functions interact with each other.

[0087] End-to-end communication between an application in the UE and an application in the external network uses services provided by the 3GPP system, and optionally services provided by a service capability server (SCS) residing in the DN.

[0088] Control plane protocol stack

[0089] Figure 3 Exemplary NAS transport for SM, SMS, UE policy, or LCS is shown. Notably, the mobility management function and the session management function are separated. A single N1 NAS connection is used for both registration management and connection management (RM / CM), and for SM related messages and procedures for the UE. A single N1 termination point is located in the AMF. The AMF forwards SM related NAS information to the SMF. The AMF handles registration management and connection management of the NAS signaling exchanged with the UE, while the SMF handles session management of the NAS signaling exchanged with the UE.

[0090] In addition, the architecture defines several types of control signaling that can be transported on top of the NAS-MM protocol, such as UE policy between the PCF and the UE, location services (LCS) between the gateway mobile location center (GMLC) and the UE.

[0091] eMBMS architecture in LTE

[0092] Multicast / broadcast multimedia subsystem (MBMS) was originally developed for 3G networks for video broadcast and streaming services, and eMBMS (evolved MBMS) was introduced for EPS. In Release 13 and Release 14, the MBMS system was updated to support new services such as public safety, CIoT, and V2X. Figure 4 The MBMS architecture for EPS is shown.

[0093] MBMS is a point-to-multipoint service in which data is transmitted from a single source entity to multiple recipients. Transmitting the same data to multiple recipients allows network resources to be shared. The MBMS bearer service provides two modes: broadcast mode and multicast mode.

[0094] In the EPS, the functional entity MBMS GW exists at the edge between the CN and the BM-SC. In the bearer plane, this service provides delivery of IP multicast datagrams from the Gi and SGi-mb reference points to the UEs with a specified quality of service. An instance of the MBMS bearer service is identified by an IP multicast address and an APN network identifier. A TMGI can also be used to identify one MBMS bearer service within one PLMN.

[0095] Broadcast-Multicast Service Center (BM-SC)

[0096] The MBMS specific functional entity named Broadcast Multicast Service Center (BM-SC) supports various MBMS user service specific services such as provisioning and delivery. Specifically, the BM-SC is a functional entity that includes the following main sub-functions: a membership function, a session and transmission function, a proxy and transport function, a service announcement function, and a security function.

[0097] Membership function: provides authorization for UEs to request activation of MBMS services. The membership function is an MBMS bearer service level function.

[0098] Session and transmission function: manages MBMS sessions, allocates TMGIs and schedules MBMS session transmissions.

[0099] Proxy and transport function: used for proxy delegation signaling between the MBMS GW / GGSN and other BM-SC sub-functions via the SGmb and Gmb reference points; and the proxy and transport function is an MBMS bearer service function.

[0100] Service announcement function: provides service announcement for multicast and broadcast MBMS user services; this function provides the UEs with a media description (e.g., type of video and audio encoding) of the media to be delivered as part of the MBMS user service. And this function is a user service level function.

[0101] Security function: MBMS user services can use the security function for integrity and / or confidentiality protection of MBMS data; and the MBMS security function is used to distribute MBMS keys (key distribution function) to authorized UEs.

[0102] MBMS Gateway (GW)

[0103] In EPS, a functional entity MBMS GW exists at the edge between the CN and the BM-SC. The MBMS GW provides the following functions. It provides the interface of the entity using the MBMS bearer over the SGi-mb (user plane) reference point. It provides the interface of the entity using the MBMS bearer over the SGmb (control plane) reference point. IP multicast distribution of MBMS user plane data to E-UTRAN (Ml reference point). In case of E-UTRAN access, it can allocate IPv4 or IPv6 IP multicast addresses or both. The eNodeB shall join to the IP multicast distribution using one IP multicast address (IPv4 or IPv6) to receive the MBMS data. When a single IP multicast address is allocated by the MBMS-GW, this IP multicast address is provided to the eNodeB via the MME together with the IP address and C-TEID of the Multicast Source (SSM).

[0104] MBMS operation on demand (MooD)

[0105] The on-demand MBMS operation (MooD) allows certain content that is initially delivered via unicast network to be converted into MBMS user service in order to efficiently use network resources when the traffic exceeds a certain threshold. In particular, certain content that is initially delivered via unicast network can be converted into MBMS user service in order to efficiently use network resources when the traffic volume exceeds a certain threshold. Such dynamic conversion from unicast delivery to MBMS delivery is also referred to as "MBMS offload".

[0106] Two types of on-demand MBMS operation are described in TS 26.346: UE-chosen offload and network-chosen offload. In both types, there can be a network proxy / server to detect whether the unicast traffic volume of the same service or content exceeds a certain threshold and to indicate such event to the BM-SC to enable MBMS offload. In both types, there can be a network proxy / server to detect whether the unicast traffic volume of the same service or content exceeds a certain threshold and to indicate such event to the BM-SC to enable MBMS offload. To assist the MooD decision, the network proxy / server can obtain the UE location from the UE according to the operator's policy. Alternatively, the network proxy / server can act as an application function when requesting the location information of the UE from the PCRF via the Rx reference point. To assist the MooD decision, the network proxy / server can obtain the UE location by many possible means, including using the current location field in the MooD header, according to the operator's policy. MooD supports E-UTRAN and UTRAN access.

[0107] R17 study on architecture enhancements for 5G multicast-broadcast services

[0108] Release 17 studies started in SA2 to explore potential enhancements of multicast and broadcast services in 5G networks. Multicast and broadcast related specification work has not yet started for possible enhancements from system perspective in order to fulfil the requirements on 5G networks using the new 5GC architecture. The objectives have been identified as follows.

[0109] First objective, define a framework including a functional split between (R)AN and CN to support multicast / broadcast services, e.g. point-to-point multicast / broadcast streaming, transparent IPv4 / IPv6 multicast delivery, IPTV, software delivery over the air, group communication and broadcast / multicast IoT applications, V2X applications, public safety.

[0110] Second objective, support different levels of services (e.g. transport-only mode and full service mode).

[0111] Third objective, enable flexible (e.g. distributed vs. centralized) network deployment and operation (e.g. CP-UP separation).

[0112] And fourth objective, address whether and how related QoS and PCC rules apply to multicast / broadcast services.

[0113] Key issues for reliable delivery mode switching between unicast and multicast

[0114] In TR 23.757 [3], key issues are identified to provide support for dynamic delivery mode switching in 5GS. Depending on the number of devices receiving a particular content, the location of the devices and RAN considerations, it can be necessary to support reliable and efficient delivery mode switching between unicast and multicast mode, i.e. to be able to dynamically transfer a unicast session to a multicast delivery mode and vice versa. In addition, when a UE receives a multicast session, it can move across NG-RAN nodes and it is possible for the UE to move from a NG-RAN node that supports MBS to a NG-RAN node that does not support MBS or vice versa. The following aspects will be studied: 1) triggers for delivery mode switching in 5GS; and 2) how to perform delivery mode switching between unicast mode and multicast mode in 5GS (including the UE) while supporting service continuity.

[0115] Key issues for reliable delivery mode switching between unicast and broadcast

[0116] In TR 23.757, similar key issues are identified to provide support for dynamic delivery mode switching between unicast and broadcast in 5GS. When a UE receives a session, it can move from an NG-RAN node that supports MBS to an NG-RAN node that does not support MBS, or vice versa. The following aspects will be studied: 1) triggers for switching between unicast delivery method and broadcast delivery method; and 2) how to perform switching between unicast delivery method and broadcast delivery method in 5GS while supporting service continuity.

[0117] First use case: switching between unicast and multicast

[0118] In an example scenario, users use their smart phones (e.g., UEs) to view a live video stream of an event. Initially, only one user is streaming the live video stream, so the content provider or network operator decides to establish a unicast session to transmit the video stream from a server to the smart phone over a mobile core network. Later, more users are interested in the same video stream and initiate the streaming service. When the number of smart phones exceeds a certain threshold, the network operator and content provider decide to start a multicast session to transmit the video stream data through multicast so that all smart phones can stream the video through one multicast session, which more efficiently uses network and radio resources.

[0119] After a certain time, some UEs move to a new area where multicast service is not provided. The network operator or content provider will use a unicast session to stream the video for each of those UEs, and the remaining UEs will still stream the live video via the multicast session if it is reasonable for the network operator or content provider to continue the multicast service. For those affected UEs, they will switch from multicast to unicast delivery method. At some point in time later, the number of UEs served through unicast delivery service or the volume of data delivered to UEs for this service such that it is no longer efficient to serve these UEs using unicast delivery mode. The UEs are then reconfigured to receive in multicast mode.

[0120] Second use case: switching between unicast and broadcast

[0121] A UE (e.g. a user's mobile handset) is aligned with a broadcast service that provides streamed audio or visual content related to a local area, such as audio and visual guidance to local attractions, traffic reports, etc. The audio or visual information is distributed to the user's mobile handset through the broadcast service. The user is able to experience the content on the mobile device. The UE is initially able to continuously receive the broadcast service. After a certain time, the UE moves to a new area where the broadcast service is not provided, or the broadcast of the service is no longer justified for the number of UEs interested, for example, or the number of UEs receiving the broadcast service no longer justifies the service to be broadcast, for example from a network (e.g. core network or radio network) resource efficiency perspective. The UE is then reconfigured to receive the service through unicast delivery. At some point in time later, the number of users (e.g. UEs) being served through unicast delivery or the volume of data delivered to the users for this service makes it no longer efficient to serve these users using the unicast delivery mode. The UEs are then reconfigured to receive in broadcast mode.

[0122] Problem

[0123] The switching between unicast delivery mode and multicast / broadcast delivery mode is supported in EPS MBMS via MooD and MBMS user service consumption reporting. MooD is an application layer solution; therefore, it presents the following problems.

[0124] With reference to the first problem, the control signaling is transported at the application layer to enable the switching. Since many different applications will use the multicast / broadcast service, it is necessary for all the applications to support the MooD protocol, and it also tends to make the reaction time slower for both the adjustment of the core network and the radio resource usage policy for the main resource usage status in the core network or radio network, thus it is not efficient to transport the control information at the application layer.

[0125] With reference to the second problem, it can be more efficient to base the decision to switch between unicast and multicast on information that is not necessarily available at the application layer (e.g. RAN conditions, number of devices receiving the content, location of devices receiving the content).

[0126] In addition, with reference to the third problem, there is no conventional method that relies on non-access stratum (NAS) signaling between the UE and the network for delivery mode switching between unicast and multicast or unicast and broadcast.

[0127] In view of the foregoing problems, there is a motivation to design a 5G or similar network such that the decision to switch traffic flows between unicast delivery mode and multicast delivery mode is made in the network below the application layer and triggered by the network, the UE or a RAN node.

[0128] In view of the problems discussed above, disclosed herein are subjects that solve the following problems related to service delivery mode switching between multicast and unicast or between broadcast and unicast in a 5G network. The first problem related to service delivery mode switching between multicast and unicast or between broadcast and unicast in a 5G or similar network is associated with the type of event that will trigger the delivery mode switch between multicast and unicast. The second problem is associated with how to perform the switch between unicast and multicast / broadcast mode in the 5GS while supporting service continuity. The third problem is associated with the type of event that will trigger the delivery mode switch between broadcast and unicast.

[0129] A non-access stratum (NAS) centric solution for delivery mode switching includes a control plane based procedure for delivery mode switching or a user plane based procedure for delivery mode switching.

[0130] Technology

[0131] Dynamic delivery mode switching between unicast and multicast not only improves network and radio resource usage efficiency, but also improves user experience at the application layer (e.g., reduced latency, increased responsiveness, etc.) for users. For example, multicast using group gaming and group-based V2X applications would benefit from guaranteeing certain quality of service such as data rate and error rate. However, as some devices occasionally move in and out of multicast service areas, it can be advantageous for network operators and content providers to deploy some mechanisms to enable dynamic switching between unicast and multicast.

[0132] In anticipation of 5G MBS being widely implemented for a wide range of use cases and integrated into a generic core network architecture, methods and systems for dynamic switching between unicast data transmission and multicast data transmission are disclosed herein.

[0133] First, an overall architecture by integrating multicast and broadcast services into a generic 5G core network, which is used as a baseline architecture for the systems and procedures disclosed herein.

[0134] Second, methods and systems to switch the delivery mode from unicast to multicast. For example, the methods can describe: 1) an event is triggered at the UE, network function, content provider, or RAN node to initiate the switching procedure; 2) a procedure for UE initiated switching from unicast to multicast; 3) a procedure for network initiated switching from unicast to multicast, or 4) a procedure for RAN initiated switching from unicast to multicast.

[0135] Third, methods and systems to switch delivery mode from multicast to unicast. For example, methods can describe: 1) triggering an event at the UE, network function, content provider, or RAN node to initiate a switching procedure; 2) procedures for UE-initiated switching from multicast to unicast; 3) procedures for network-initiated switching from multicast to unicast; or 4) procedures for RAN-initiated switching from multicast to unicast.

[0136] Fourth, methods and systems can describe switching of delivery mode from individual MBS service delivery to shared MBS service delivery using handover.

[0137] Fifth, methods and systems can describe switching of delivery mode from shared MBS service delivery to individual MBS service delivery using handover.

[0138] For the purposes of this discussion, it can be assumed that unicast and multicast / broadcast sessions can or can not be available after switching. In other words, after switching, application data can be transmitted via unicast or MBS sessions that can be determined by the UE or AF.

[0139] MBS architecture for 5G networks

[0140] Figure 6 An exemplary architecture implementing multicast or broadcast services in 5G is shown. Introduced network functions can include: a Multicast and Broadcast Management Function (MBMF), an MB-SMF, an MB-UPF 209, or an MB-AF.

[0141] Multicast and Broadcast Management Function (MBMF): responsible for managing multicast and broadcast services provided to UEs and content providers (e.g., it can implement membership functions by forming multicast groups as well as implement security functions such as authorizing UEs to join multicast groups and use multicast services).

[0142] MB-SMF: responsible for managing MBS sessions for multicast and broadcast data transmission. MB-UPF: acts as a data plane anchor point for MBS sessions for multicast or broadcast. MB-AF: responsible for managing MBS services as an application provider or content provider.

[0143] Note that the above functions are logical functions and can be implemented in other options. For example, the functions of the MBMF can be split and can be implemented at the SMF, PCF, UPF, and / or AF, respectively.

[0144] Note that although the solutions for service delivery mode switching are described in terms of switching between unicast and multicast by way of example, it should be understood that the methods described below are equally applicable to switching between unicast and broadcast.

[0145] Method for switching from unicast delivery to multicast delivery

[0146] Delivery mode switching mentioned throughout refers to 5GC switching the delivery method between 5GC standalone MBS service delivery and 5GC shared MBS service delivery to send multicast / broadcast data to UEs. This section provides procedures to switch from unicast data transmission to multicast. Multiple scenarios will be considered when initiating the switch from unicast to multicast.

[0147] Scenario one is that the multicast session has not been started yet and the UE handover requires the establishment of a multicast session. Scenario two is that the multicast session has been established and one or more UEs are receiving data through the multicast session. In other words, some UEs have joined the multicast group. In this case, the handover UE does not need to establish a multicast session.

[0148] Events that trigger switching from unicast to multicast

[0149] A UE can request to switch a flow between unicast and multicast. The request can be triggered by the following events. In an example, the event can be moving to an area or cell that supports multicast service. In another example, the event can be receiving an application layer or NAS layer message indicating that a multicast service or multicast session is available or preferred (e.g., a V2X application running on the UE joins a group, so the application can request to receive the application data via a multicast session instead of a unicast session). In another example, the event can be a user initiating a point-to-point game session with a friend via a GUI on the UE. In another example, the event can be a UE subscription becoming allowed for the UE to get MBS service.

[0150] The switch from unicast to multicast can be initiated by core network functions, including a request from an AF via a NEF. The decision by the core network function to switch can be triggered by the following events. In an example, the core network function discovers that the number of UEs receiving the same data content via respective unicast sessions exceeds a threshold number and decides to start a multicast data transmission for more efficient network resource usage. In an example, a network function such as a UPF, PCF, SMF / MB-SMF, or NWDAF can also make the decision to switch. The decision can be based on the network function’s monitoring of network status (e.g., the access network to transmit unicast data can be congested, so the network function can decide to switch the application flow to an available multicast session that carries the same application data for a group of UEs). In another example, the network function can detect or be notified that a UE moves into a multicast service area or is predicted to move into a service area.

[0151] The switch from unicast to multicast can also be initiated by the RAN node. For example, when a UE moves into a new area where there exists an existing multicast session setup for ongoing unicast application data (e.g., group gaming or V2X applications), the RAN node can decide to switch the UE to the multicast session for more efficient radio resource utilization. This can happen together with a handover procedure where a different RAN node will provide the multicast data transmission service to the UE.

[0152] UE-initiated procedure

[0153] For the UE initiated switch procedure, various methods are disclosed.

[0154] A first method is that the UE sends a NAS message to the AMF requesting a switch to a multicast transmission mode (e.g., as described in 5GPP TS 23.501, clause 5.31.3.2, “UE Requested PDU Session Modification”). Figures 7A-7BThe control plane method shown in the diagram discloses several options for the content of the NAS message. First, the NAS message can be a PDU session establishment request, where the UE indicates that the session is for multicast, such that the IP multicast address will be assigned later by a core network function (such as MBMF or MB-SMF). Alternatively, the NAS message can be a PDU session modification request, indicating that the UE wants to reuse an existing MBS PDU session to receive multicast data via a shared service delivery method. Second, the NAS message can also be a service request message, where the UE requests activation and switching to an existing multicast session. In the case where the UE wants to switch to an existing active multicast session, the UE can send a NAS-SM message to the AMF / SMF, indicating the TMGI or IP multicast address in the NAS-SM message. Third, the NAS message can also include a service consumption report, such as an MBMS user service consumption report. The service consumption report can include service consumption information. The NAS message can include service consumption information alone or in combination with a service delivery mode switching request. The AMF can forward the service consumption report to a Broadcast Multicast Service Center (BM-SC) or a network node acting as a BM-SC, such as the MBMF. It should be noted that using service consumption reports in the control plane as a means for the UE to trigger a network handover delivery mode from unicast to MBMS service (broadcast or multicast) also applies to handovers from delivery via MBMS user service (broadcast or multicast) to unicast service. Fourth, and in support of On-Demand MBMS Operation (MooD), NAS messages may also include requests for content eligible for conversion to delivery as MBMS service (as described by the request field configured in the UE by the MooD Configuration Management Object (MO)). This newly disclosed MooD request for converting a service received as unicast service to an MBMS service may include information such as that included in similar MooD requests currently exchanged between the UE and the network at the application layer. The AMF may forward the service consumption report to the Broadcast / Multicast Service Center (BM-SC) or a network node acting as a BM-SC, such as the MBMF.

[0155] The second method is for the UE to send a request message to the UPF, or to the MBMS Gateway (MBMS-GW) or a node acting as the MBMS-GW, or to the BM-SC, or to a node acting as the BM-SC, via a user plane path to join an existing multicast group identified by an IP multicast address (e.g., a user plane method). This is used for the case where the UE wants to switch to an existing active multicast session. The content of the user plane message (e.g., sent from the PDU layer within the UE) can also include a service consumption report, such as a MBMS User Service Consumption Report. The service consumption report can include service consumption information. The NAS message can include service consumption information separately or in combination with the service delivery mode switch request. Further, in support of on-demand MBMS operation (MooD), the user plane message can also include a request for content that qualifies for conversion to delivery as a MBMS service (as described by the MooD Configuration Management Object (MO) based on the request domain configured in the UE). This newly disclosed MooD request for conversion of a service received as a unicast service to a MBMS service can include information such as that included in similar MooD requests currently exchanged between the UE and the network at the application layer. Alternatively, the UE can send a Multicast Listener Delivery (MLD) request to join an existing multicast group.

[0156] Figures 7A-7B A procedure is shown for UE initiated switch from unicast to multicast.

[0157] Step 220: As a first step, a unicast session is established and data is transmitted between the UE 201 and the AF 210 over the network via the unicast session. Data is sent from the UPF 205 to the UE 201 via the PDU session.

[0158] Step 221: The UE 201 receives information about available multicast services and determines to switch data transmission from unicast to multicast. This can be triggered by several factors as discussed herein.

[0159] Step 222: The UE 201 sends a NAS message (e.g., PDU session establishment / modification or service request) to the AMF 203 that can include an indication of a delivery mode switch request. The message can include the following information that can have been received in step 221.

[0160] The information can include a UE ID such as a 5G-GUTI and a SUPI.

[0161] The information can include a PDU session ID and a flow descriptor for the current unicast data transmission. The flow descriptor can be an IP 5-tuple.

[0162] The information can include a DNN indicating the data network that initiates and / or terminates the multicast and unicast data.

[0163] The information can include S-NSSAI indicating a network slice that the UE 201 connects to for unicast data transmission.

[0164] The information can include application information, such as an application ID, which indicates which application data can be delivered through multicast / unicast. In addition, this can include an operating system ID (OS Id) and an operating system application ID (OS App Id).

[0165] The information can include a multicast session ID. If there is no existing multicast session, the UE 201 generates this session ID. If the UE 201 wants to join an existing multicast session, the UE 201 provides this information. The UE 201 can obtain such information by seeking existing multicast services within the area during a previous control plane procedure, such as registration, registration update, service request procedure, or the UE 201 stores such information when the UE 201 uses multicast services.

[0166] The information can include QoS information, such as 5QI, QoS flow ID, maximum data rate, error rate, or maximum delay. Depending on whether a multicast session exists or not, the QoS information can be QoS parameters if the multicast session already exists, or can be QoS requirements if there is no existing multicast session.

[0167] The information can include a desired time instant at which the UE 201 wants to start receiving data from the multicast session (e.g., when the handover takes effect).

[0168] The information can include multicast credentials. The UE 201 provides additional credentials required to establish or join a multicast service or group.

[0169] The information can include multicast request context, which can be optional information required by the NF to determine whether the request meets local policies, such as a predicted UE 201 route or location.

[0170] If the UE 201 wants to handover to an existing multicast session, more information can be included. The more information can include a multicast IP address, which is an identifier that identifies the multicast session / group. The more information can include other MBS session context information that the UE 201 has, such as an MB-SMF address, an S-NSSAI identifying a network slice serving the multicast session, a multicast session service area, and a maximum multicast data rate. The more information can include a TMGI identifying a multicast group that the UE 201 wants to join. The more information can include a multicast session ID or a reference ID received in an advertisement of the multicast session.

[0171] Step 223: If the AMF 203 is not aware of the MBMF 207 information or the UE 201 does not provide such information, the AMF 203 can use a default MBMF or communicate with the NSSF / UDM to receive assistance for determining and selecting the MBMF 207.

[0172] In case of AMF 203 change, the new AMF 203 is responsible for handling the control signaling shown in Figure 2B. Figure 7A

[0173] Step 224: The AMF 203 sends a request to the MBMF 207 to check if the requesting UE is authorized to use multicast services or multicast / broadcast services (MBS).

[0174] Step 225: In case the AF 210 requires secondary authentication and authorization for specific application data transfer over multicast, the MBMF 207 is responsible for communicating with the AF 210. In addition, the UDM 206 or PCF 206 can also be involved in this procedure. This can be specific to the UE 201, application, multicast / broadcast services (MBS), or a combination of these. The AMF 203 can contact the AUSF to determine if secondary authentication and authorization is required for the multicast service for the application data flow. The MBS service is a service provided by the 5G core network.

[0175] Step 226: The MBMF 207 sends an authorization response to the AMF 203 to indicate the result. In addition, the MBMF allocates a TMGI to identify the multicast group (if it does not already exist) and sends it to the AMF 203 together with the MB-SMF information such as the MB-SMF address or ID. In addition, the MBMF 207 can allocate a multicast IP address to the group. The multicast group includes a group of UEs that will join the group and receive data via multicast. The multicast session (e.g., multicast PDU session) is a PDU session established for multicast.

[0176] Step 227: If the multicast session does not already exist, the AMF 203 can select an appropriate MB-SMF 208 to establish and manage the multicast PDU session. If the MBMF 207 has provided the MB-SMF address or ID, the AMF 203 selects the indicated MB-SMF 208.

[0177] ​Step 228: Based on whether the MBS session exists or not, the AMF 203 sends a MBS session setup message or an update request message to the selected MB-SMF 208. If the session does not exist, the request can include the following information: UE ID, session ID, QoS flow ID and corresponding QoS information (e.g., 5G QoS Indicator (5QI), QoS requirement such as maximum data rate, maximum delay or error rate per QoS flow or per MBS session), traffic description (e.g., application ID, OS Id or OS App Id), TMGI or DNN. Note that there can be multiple QoS flows in a MBS session and each QoS flow can be used to transmit different multicast application data. If the session already exists and the UE 201 wants to join the group, the multicast IP address and MBS session service area can also be included. In addition, the time when the handover can take effect can be sent to the MB-SMF 208, e.g., when the UE 201 can start receiving data via multicast and stop receiving via unicast session. Another option is to have the MB-SMF 208 / SMF 204 selected by the MBSF and then the AMF 203 forwards the session setup / modification message from the UE 201 to the MBSF. The MBSF then sends the message to the selected MB-SMF 208 / SMF 204 to perform the requested session management procedure.

[0178] Step 229: The MB-SMF 208 selects the MB-UPF 209 in case a new MBS session is to be established. In addition, the MB-SMF 208 can allocate a multicast IP address to identify the new MBS session for multicast transmission. If the MB-SMF 208 is co-located with the SMF 204, the SMF 204 can allocate the multicast IP address.

[0179] Step 230: The MB-SMF 208 sends a session setup or update request to the MB-UPF 209 using the information mentioned in step 222 and step 228. Some information (e.g., DNN, application information / traffic description, source IP address or multicast IP address / TMGI) can be used by the MB-UPF 209 as packet filter rules associated with the MBS session. In addition, the MB-SMF 208 can indicate to the MB-UPF 209 whether the new MBS session is for multicast or broadcast.

[0180] Step 231: The MB-UPF 209 returns a session setup or update response message to the MB-SMF 208 to indicate that the MBS session is ready for the UE 201. If the MB-SMF 208 does not allocate a multicast address, the MB-UPF 209 returns the allocated multicast IP address for the session.

[0181] Step 232: The MB-SMF 208 sends an MBS session setup or update response to the AMF 203 using the MB-UPF information. The MB-UPF information can be used by the RAN node 202 to setup N3 tunnel to transport data.

[0182] Step 233: The AMF 203 sends an N2 message to the RAN node 202 to inform of the upcoming handover. In the N2 message, the AMF 203 can include the following information to help the RAN node 202 prepare for the handover.

[0183] The information can include MB-UPF information such as an ID or address so that the RAN node 202 can setup an N3 tunnel with the MB-UPF 209 if not already setup.

[0184] The information can include a UE ID such as 5G_GUTI or SUPI.

[0185] The information can include an MBS service area indicating the area where the MBS session serves multicast transmissions.

[0186] The information can include a unicast PDU session ID and an MBS session ID identifying the sessions affected by the handover so that the RAN node 202 can adjust its radio resources accordingly.

[0187] The information can include a multicast IP address as well as a TMGI to identify the multicast group.

[0188] The information can include a NAS message that also includes content that can be forwarded to the UE 201 as a response to the handover request in step 221 (the content of this NAS message is detailed in step 236).

[0189] The information can include QoS mapping information. In addition, the QoS mapping information can be provided to the RAN node 202 to indicate the QoS mapping between the QoS of the MBS session and the QoS of the unicast PDU session. This mapping information can come from the MB-SMF 208 / SMF 204 or the PCF 206 and is forwarded by the AMF 203. Using the mapping information, the RAN node 202 is able to configure the radio resources within the access network for transmitting data to the UE 201 to meet the QoS requirements.

[0190] Step 234: Once the RAN node 202 receives the N2 message from the AMF 203, the AMF 203 can contact the MB-UPF 209 to establish or update the N3 tunnel for the multicast session. The AMF 203 can provide the RAN node information, a tunnel ID to identify the N3 tunnel, and an indication whether the N3 tunnel is shared or group-based for multicast transmission. It is possible that the RAN node 202 needs to establish the N3 tunnel whether the MBS session exists or not, which implies that the RAN node 202 can join the multicast group for sending data to the UE 201. It is also possible that the RAN node 202 has already joined the shared N3 tunnel but not for the requesting UE. In other words, the RAN node 202 is transmitting multicast data to other UEs. In this case, the RAN node 202 does not need to contact the MB-UPF 209.

[0191] Step 235: The RAN node 202 also adjusts its radio resources in preparation for the handover.

[0192] Step 236: The RAN node 202 sends an RRC message to the UE 201 including a NAS message carrying the delivery mode switch response from the AMF 203. The response can include the following information: TMGI, multicast IP address, multicast session ID, or context information. The context information can be the multicast service area, QoS information (e.g., 5QI, QoS flow ID, maximum data rate), application information (e.g., application ID, OS Id, and OS App Id), or a starting time point. Note that from the UE 201 perspective, the MBS session is the same as a unicast session but is associated with an IP multicast address and TMGI. However, the MB-UPF 209 can send the multicast data stream to one or more RAN nodes via a shared N3 tunnel, and each RAN node 202 can use radio resources to send the multicast data to one or more UEs within its cell.

[0193] Step 237: An application layer signal comes from the UE 201 to inform the content provider (e.g., AF 210) about when the upcoming handover can start for which application while the unicast data transmission continues. Here, there is application layer signaling between the UE and the AF 210.

[0194] Step 238: After the UE 201 starts receiving data over the multicast session, the AMF 203 informs the SMF 204, which further instructs the UPF 205 to block / suspend mapping of traffic to the unicast PDU session, even though the unicast PDU session remains active. The traffic can be identified by the application information provided by the UE 201 in step 222. In addition, the block / suspension can be associated with a validity time period. Alternatively, the UE 201 can send a new NAS message (e.g. PDU Session Update - Flow Suspend) that indicates to the network the details of the flow it no longer wants to receive via unicast, as it is receiving equivalent data via multicast, etc. The flow can be described as a combination of IP 5-tuple, Application ID, OS Id or OS App Id. The network can use this information to block any DL traffic that matches the description. Later, when the UE 201 wants to receive the unicast flow, the UE 201 can send a new NAS message (e.g. PDU Session Update - Flow Resume) that indicates to the network (e.g. core network entity such as a server or network function) that the flow or data should no longer be blocked at the UPF 205. The information in the NAS message from the UE 201 has some indication of what the network is to do.

[0195] Note that for the handover scenario from unicast to broadcast, the MBS session can have an indication to the network function and the UE that the session is for broadcast, and can not have a multicast IP address associated with the session. However, the TMGI is still used to identify the broadcast group. The shared N3 tunnel is identified by the TMGI and the tunnel ID.

[0196] Additional logic can be implemented in the core network functions involved in the procedure to determine whether the handover should occur, e.g. based on NF local policies. For example, the handover can only be performed if it is determined that the UE 201 is expected to stay in a certain geographical area for a certain amount of time, or only if explicit user consent is provided. In that case, the response in step 236 can include a corresponding cause and a request for additional information, and the UE 201 can re-initiate the procedure to provide the necessary information in the multicast request context.

[0197] Alternatively, the UE 201 can also initiate the handover procedure by sending a request via a user plane path (e.g. a unicast PDU session). Note that this user plane solution is mainly applicable to the case where a multicast session is already established. Figure 8 A user plane approach is shown:

[0198] Step 240: As a first step, a unicast session is established and data is transmitted between the UE 201 and the AF 210 via the unicast session over the network.

[0199] Step 241: The UE 201 decides to switch data transmission from unicast to multicast. This can be triggered by several factors such as information or events (e.g., an event that triggers the switch from unicast to multicast) as disclosed herein.

[0200] Step 242: Assuming the multicast group exists, the UE 201 encapsulates a request to join the multicast group into a data packet and sends the request to the UPF 205 via the unicast PDU session. The UE 201 can provide the UE ID, TMGI, multicast IP address (if it knows it), and application information (e.g., application ID, OS Id, and OSAppId) that indicates which application data can be switched to multicast. Alternatively, the UE 201 can send an MLD report to the UPF 205 to join the multicast group. The UE 201 can provide the multicast IP address in the report or have the MBMF 207 / MB-SMF 208 provide the multicast IP address.

[0201] Step 243: Upon receiving the data packet, the UPF 205 sends an N4 notification to the SMF 204. The notification includes the join request from the UE 201.

[0202] Step 244: The SMF 204 sends the join request to the MBMF 207. If the SMF 204 does not know the MBMF information, it can communicate with the UDM (e.g., UDM / PCF 206) or NSSF for assistance. Alternatively, the SMF 204 can forward the join request to the MB-SMF 208 and then the MB-SMF 208 contacts the MBMF 207 to initiate an MBS session management procedure (e.g., establishment or update) for the UE request.

[0203] Step 245: The MBMF 207 initiates authorization for the UE 201 to obtain the MBS service and, optionally, initiates secondary authentication and authorization using the AF 210 if needed for specific secondary authentication and authorization for the UE 201, application, MBS service, or a combination of these.

[0204] Steps 246-247: Because an MBS session for multicast has been created, the MB-SMF 208 sends an MBS session update request to the MB-UPF 209. The update operation can include adding additional RAN nodes and shared N3 tunnels to enable multicast data transmission to newly joined UEs 201.

[0205] Step 248: MB-SMF 208 sends a handover notification to AMF, indicating that the MBS session is ready to transmit data to UE 201 via multicast. This notification includes the UE ID, handover initiation time, MB-UPF address or ID, MBS session ID, and QoS information. This information can be passed to RAN node 202, enabling RAN node 202 to adjust radio resources used for handover. For example, RAN node 202 can suspend or remove radio resources allocated to unicast transmissions and allocate radio resources for upcoming multicast transmissions.

[0206] Steps 249 to 250: AMF 203 and SMF 204 request / respond to session update request / response of session exchange PDU currently used by UE 201 for unicast data transmission.

[0207] Steps 251 to 252: SMF 204 then communicates with UPF 205 via N4 to update the unicast session context. The update may include changing the packet detection rules at UPF 205 to allow UE201 to switch to a multicast session after a set time period by blocking or suspending application data (identified by application ID, OSId, and OSAppId) via the unicast PDU session identified by the session ID.

[0208] The following steps and such Figures 7A-7B Steps 233 to 238 shown are the same, in order to notify RAN node 202 and UE 201 to prepare for the upcoming handover.

[0209] Network-initiated procedure

[0210] Besides UE-initiated scenarios, the network can also initiate handover procedures from unicast to multicast for application data streams, including situations where AF 210 initiates handover by sending a request to NF. Possible triggers have been discussed above. Figure 9 This illustrates the procedure for a network-initiated switch from unicast to multicast transmission.

[0211] Step 260: As a first step, establish a unicast session and transmit data between UE 201 and AF 210 via the unicast session over the network.

[0212] Step 261a: If the AF 210 decides to trigger the switch, the AF 210 sends a delivery mode switch request to the MBMF 207 or AMF 203. If the AF 210 knows which NF will be contacted, it can send the request message directly to the AMF 203 or MBMF 207. If necessary, the AF 210 can reach the MBMF 207 or AMF 203 via the NEF 211. In this case, the NEF 211 can determine which AMF 203 or MBMF 207 will be contacted on behalf of the AF 210. For example, the NEF 211 communicates with the UDM (e.g., UDM / PCF 206) to retrieve subscription information or the NSSF for selecting the appropriate NF. The AF 210 can provide the following information in the request.

[0213] If a group has been formed, the information can include the TMGI. If the TMGI is not provided, the TMGI can be allocated during the rest of the procedure (e.g., the MBMF 207 allocates the TMGI).

[0214] If the UEs 201 involved have formed a group at the application layer, the information can include an external group ID.

[0215] If multicast has been used, the information can include the multicast IP address. The information can include the unicast session ID currently used for data transmission. The information can include the source IP address of the application data flow.

[0216] The information can include a list of UEs that can be switched to multicast transmission: It is possible that the AF 210 wants to switch more than one UE to a common multicast session to improve resource efficiency. In this case, the AF 210 can provide a unicast session ID for each of those UEs.

[0217] The information can include application information such as application ID, OS Id, and OS App Id to identify which application data can be switched to multicast.

[0218] The information can include a desired time instant indicating when the AF 210 wants to make the switch.

[0219] Step 261b: Alternatively, the NF can want to start the switch due to reasons / triggers disclosed herein, such as information or events (e.g., an event that triggers switching from unicast to multicast).

[0220] Step 262: The AMF 203 sends a NAS message to the UE to inform the UE 201 about the handover decision. The NAS message can be a UE configuration update message which can include the following information: unicast session ID, QoS parameters (e.g. data rate, delay and error rate), application information which can be switched to multicast, TMGI, multicast IP address, source IP address, MBS session ID and context information such as MBS service area or the start time of the handover. In addition, the AMF 203 can indicate to the UE 201 so that the UE 201 can initiate the handover procedure as shown in Figures 7A-7B Step 263 if there are multiple UEs which can be switched, the AMF 203 can perform.

[0221] Step 263: The AMF 203 follows steps 223-236 as shown in Figures 7A-7B

[0222] Step 264: The AMF 203 informs the AF 210 that the handover configuration has been done and it is ready to start the handover at the expected time.

[0223] RAN-initiated procedure

[0224] As discussed above, in some scenarios, the RAN node 202 can also initiate the handover procedure from unicast transmission to multicast transmission. Disclosed herein are topics on how the RAN node 202 can start this procedure to achieve the handover from unicast transmission to multicast transmission (including Option 1 or Option 2).

[0225] Option 1: The RAN node 202 sends an RRC message to inform the UE 201 that it decides to initiate the handover and then the UE 201 follows the procedure presented above to initiate the handover.

[0226] Option 2: The RAN node 202 sends an N2 message to the AMF 203 to request the network to initiate the handover and then the network follows the procedure presented herein, such as Figure 8 ​On network initiated procedure. The RAN node 202 can also indicate the cause of the handover, such as a unicast radio resource entering the multicast service area or the UE 201 being restricted. This option can be applicable to scenarios where multiple UEs served by the RAN node 202 are handover to the same application’s multicast. The RAN node 202 can provide the UE ID to the network for each of the involved UEs and request the network to allocate a TMGI to form a group in case a multicast group is not formed.

[0227] Method for switching from multicast delivery to unicast delivery

[0228] This section provides the procedure to switch data transmission from multicast to unicast.

[0229] Events that trigger switching procedure from multicast to unicast

[0230] The UE 201 can request to switch from multicast to unicast for an application for one of the following five reasons, among others.

[0231] First, it can be triggered when the UE’s own measurements of data transmission via the multicast session fall below the requirements, such as data rate, error rate and latency, and decides to switch to a unicast session for the same application data. The measurements can be from the application layer or at the transport layer.

[0232] Second, the UE 201 can be triggered when it moves out of the MBS service area of the MBS session, so it has to switch to unicast.

[0233] Third, the UE 201 can be triggered when the user on the UE wants to continue receiving data traffic after the point-to-point multicast group has been dissolved and after an indication via the GUI on the UE 201. For example, a game application prompts the user to continue the game session after all other members have left the multicast session.

[0234] Fourth, the user can intentionally / manually opt out of the broadcast or multicast group (e.g. based on a GUI request).

[0235] Fifth, the UE subscription profile is changed to not allow the UE 201 to use MBS services.

[0236] The switch from multicast to unicast can be initiated by the core network entity, including a request from the AF 210 or an external SCS / AS via the NEF 211. This request can be initiated for the following three reasons, among others.

[0237] First, the content provider finds that the number of users receiving data on the multicast session is decreasing and it becomes less efficient to continue the multicast from a resource management perspective.

[0238] Second, the content provider finds that the data transmission performance is reduced and cannot meet the requirements at the application layer, and the content provider can decide to unicast data with more performance guarantees.

[0239] Third, a network function such as the MB-SMF 208, the MB-UPF 209, the AMF 203, or the NWDAF finds that the data transmission performance within the core network cannot meet the requirements or that the UE 201 moves out of the MBS session service area. In addition, if there is only one remaining UE receiving the multicast traffic, the network can handover the UE 201 to use a unicast session for better mobility handling of the traffic in case the UE 201 moves.

[0240] The switch from multicast to unicast can also be initiated by the RAN node 202. For example, the RAN node 202 measures some parameters of the ongoing multicast session (e.g., data rate, error rate, or latency) and finds that the performance is below or can reduce below a threshold. The RAN node 202 can determine that the application data transmission needs to be switched to a unicast session that can guarantee the performance requirements.

[0241] Triggerers to switch a flow from unicast to multicast, and triggerers to switch a flow from multicast to unicast are disclosed herein. It should be understood that although a particular triggerer can be discussed in the context of switching a flow from unicast to multicast / broadcast, the triggerer can also apply to switching a flow from multicast / broadcast to unicast. It should also be understood that although a particular triggerer can be discussed in the context of switching a flow from multicast / broadcast to unicast, the triggerer can also apply to switching a flow from unicast to multicast / broadcast.

[0242] UE-initiated procedure

[0243] When the UE 201 wants to switch the data transmission from a multicast session to a unicast session, different methods can be used, such as a control plane method or a user plane method.

[0244] Figure 10 A procedure is shown in which the UE 201 sends a switch request via a control plane path.

[0245] Step 270, as a first step, establishes a multicast session, and the UE 201 is receiving data from a content provider via the multicast session.

[0246] Step 271: At some point in time, the UE 201 decides to switch the data transmission to unicast.

[0247] Step 272: The UE 201 sends a NAS message (e.g., service request or session establishment request / update) to the AMF 203 indicating its intention to switch to unicast. In the NAS message, the UE 201 can provide the following information.

[0248] The information can include a UE ID such as 5G-GUTI, SUPI, or S-NSSAI.

[0249] The information can include a unicast session ID and session context such as QoS profile, session type, session continuity mode, or service continuity mode.

[0250] The information can include a DNN that can indicate the data network that initiates or terminates the multicast and unicast data.

[0251] The information can include application information such as an application ID that indicates which application data can be delivered through multicast / unicast. In addition, this information can include an OS Id or an OS App Id.

[0252] The information can include a desired (e.g., threshold) time instant at which the UE 201 wants to start receiving data from the multicast session (e.g., when the switch takes effect). This can be associated with a certain time period indicating that the UE 201 can receive data via multicast during that time period.

[0253] The information can include an external group ID that can be an application layer ID that can be translated by the network to an internal group to identify the multicast group of the UE 201.

[0254] The information can include the UE 201 also provides TMGI, multicast IP address, or MBS session ID information if an MBS session for multicast has been established.

[0255] The information can include an S-NSSAI that can indicate the network slice that the UE 201 connects to for multicast data transfer.

[0256] The information can include a desired time instant at which the UE 201 wants to start receiving data from the multicast session (e.g., when the switch takes effect).

[0257] The information can include unicast credentials. The UE 201 provides additional credentials required to establish or join the multicast service or group.

[0258] Reasons that trigger the requested switch

[0259] Step 273: The AMF 203 forwards the switch request to the MBMF 207. If the AMF 203 is not aware of the MBMF information, it can resort to the UDM / NSSF to obtain the MBMF information.

[0260] Step 274: The MBMF 207 requests the MB-SMF 208 to update the MBS session context to reflect that the UE 201 can not receive data via the multicast session.

[0261] Steps 275-276: The MB-SMF 208 contacts the MB-UPF 209 to update the MBS session context, taking into account that the UE 201 can switch to a unicast session. If the requesting UE is the only UE 201 active under the RAN node on the MBS session, the MB-UPF 209 can decide to terminate the N3 tunnel to the RAN node 202 by removing the RAN node 202 address.

[0262] Step 277: The MB-SMF 208 returns a response to the MBMF 207 indicating that the MBS session update has been completed.

[0263] Step 278: The MBMF 207 sends a handover response to the AMF 203 indicating that the MBS session is ready to complete the multicast data transmission to the requesting UE.

[0264] Step 279: If a new unicast PDU session needs to be established, the AMF 203 selects the SMF 208.

[0265] Step 280: The AMF 203 initiates a PDU session establishment or update procedure using the selected SMF 204 and UPF 205.

[0266] Step 281: The AMF 203 sends a notification about the upcoming handover to the AF 210 so that the AF 210 is aware of when to send specific application data to the unicast session anchor at the UPF 205.

[0267] Step 282: The AMF 203 also sends an N2 message to the RAN node 202, which includes a NAS message (Handover Response) that can be forwarded by the RAN node 202 to the UE 201. The N2 message includes the UE ID, the unicast session ID and corresponding session context information, QoS profile, UPF address / ID, MBS session ID with TMGI or multicast IP address, the time instance of handover initiation. Optionally, the NAS message can be a PDU session modification from the network indicating that a unicast flow is established and rules or policies are provided for the unicast flow. In addition, QoS mapping information can be provided to the RAN node 202 to indicate the QoS mapping between the QoS of the MBS session or the QoS of the PDU session of the unicast. This mapping information can come from the MB-SMF 208 / SMF 204 or the PCF 206 and is forwarded by the AMF 203. Using the mapping information, the RAN node 202 is able to configure the radio resources within the access network for the transmission of data to the UE 201 to meet the QoS requirements.

[0268] Step 283: Given the information received in step 282, the RAN node 202 adjusts the radio resources to prepare for the handover. In the case that the UE 201 is the only UE under the RAN node 202 using the MBS session, the N3 tunnel can be terminated.

[0269] Step 284: The RAN node 202 forwards the handover response from the AMF 203 to the UE 201, which includes the unicast session ID and context information as described in step 282.

[0270] Step 285: After the UE 201 starts receiving data via the unicast data session, the MBS session can be deactivated or released at the RAN node 202 and the MB-SMF 208 / MB-UPF 209. The MB-UPF 209 can keep a record showing that the multicast data flow for a particular application can not be sent to the RAN node 202. Note that the MBS session can remain active at other MB-UPFs and RAN nodes for different UEs that remain receiving application data from the multicast session.

[0271] Alternatively, the procedures can be implemented such that the PDU establishment / update procedure in step 280 can be initiated before the MBS update steps 273-278.

[0272] Figure 11 A procedure is shown in which the UE 201 sends a handover request via a user plane path.

[0273] Step 290: As a first step, a multicast session is established and the UE 201 is receiving data from the content provider via the multicast session.

[0274] Step 291 : At some point in time, the UE 201 decides to switch data transmission to unicast.

[0275] Step 292: The UE 201 encapsulates a leave request message in a PDU data packet to indicate its intention to leave the multicast group. The UE 201 also provides the source IP address, TMGI and multicast IP address.

[0276] Step 293: Once the MB-UPF 209 identifies the request to leave the multicast group, the MB-UPF sends a N4 notification to the MB-SMF 208 with the MBS session ID, UE ID, source IP address, TMGI and / or multicast IP address.

[0277] Step 294: The MB-SMF 208 forwards the leave request of the UE to the MBMF 207.

[0278] Step 295: The MB-SMF 208 requests the MB-UPF 209 to update the MBS session by potentially changing the MBS session context information, e.g. remove / deactivate N3 tunnel information connected to the RAN node 202, at the same time.

[0279] Step 296: The MB-UPF 209 returns a session update response to the MB-SMF 208.

[0280] Step 297: The MB-SMF 208 sends a MBS session update notification to the AMF 203 and MBMF 207 respectively to indicate the MBS session update is completed for switching.

[0281] The next several steps are the same as discussed herein with reference to Figure 10 Steps 279-285.

[0282] Network-initiated procedure

[0283] Figure 12 A procedure showing network initiated switching from multicast to unicast is shown, including a scenario where the AF 210 initiates the procedure by sending a request to the NFs.

[0284] Step 300: As a first step, a multicast session is established and the UE 201 is receiving data from the content provider via the multicast session.

[0285] Step 301a: The AF 210 as content provider sends a delivery mode switch request to the MBMF 207 or AMF 203 to indicate its intention to switch certain application data transmission from multicast to unicast. If necessary, the AF 210 can reach the NF via the NEF 211. The AF 210 can provide the following information.

[0286] The information can include TMGI and multicast IP address to identify the multicast group.

[0287] The information can include MBS session ID and context information for multicast.

[0288] The information can include information of unicast session currently used for data transmission, such as session ID, N6 tunnel ID or QoS parameters.

[0289] The information can include source IP address of the application data flow.

[0290] The information can include a list of UEs that can be switched to unicast transmission. It is possible that the AF 210 determines that more than one UE needs to be switched from a common multicast session to a separate unicast session. In this case, the AF 210 can provide a unicast session ID for each of those UEs. If a unicast session has not been established for a certain UE, the network can establish a new unicast session for the UE 201.

[0291] The information can include application information such as application ID, OS Id or OS App Id to identify which application data can be switched to unicast.

[0292] The information can include a desired time instant indicating when the unicast transmission is to be started.

[0293] Step 301b: In addition to the trigger of the AF 210, the NF can also decide to switch from multicast to unicast.

[0294] Step 302: The network performs steps 273 to 283 as shown in Figure 10 to enable the switch from multicast to unicast.

[0295] Step 303: The AMF 203 sends a delivery mode switch notification to the UE 201 so that the UE 201 can prepare for the switch. In the notification, the AMF 203 provides the following information to the UE 201: unicast session ID, context information, QoS parameters, application information that can be switched to unicast, TMGI, multicast IP address, source IP address, MBS session ID or time instant of the start of the switch.

[0296] Step 304: Finally, the network returns a response to the requesting AF 210.

[0297] RAN-initiated procedure

[0298] In case the RAN node 202 wants to initiate a switch from multicast to unicast transmission of the application data flow, there are two options similar to the methods presented above, e.g. the RAN node 202 can send a notification message to the individual UEs to initiate the switch or send an N2 message to the AMF 203 to initiate the switch.

[0299] QoS parameter notification control has been specified in 5G systems to indicate whether a notification is requested from the NG-RAN when the GFBR can no longer (or can again) be guaranteed for the lifetime of the QoS flow. If the application traffic is able to adapt to changes in QoS (e.g. in case the AF 210 is able to trigger rate adaptation), the notification control can be used for GBR QoS flows. Upon reception of the notification from the NG-RAN, the AMF 203 / SMF 204 can forward the notification to the PCF (e.g. UDM / PCF 206). Unless the PCF 206 indicates differently, the AMF 203 / SMF 204 uses NAS signaling (transmitted transparently through the RAN) to inform the UE 201 about a change in the QoS parameters (e.g. 5QI, GFBR or MFBR) currently fulfilled by the NG-RAN for the QoS flow. The use of the evolved QoS parameter notification control is disclosed, or a new QoS parameter for service delivery mode control is defined. This new QoS parameter can be named e.g. “delivery mode control” or “delivery notification control”. The evolved notification control parameter or the new delivery mode control parameter can be used by the core network (e.g. network server or other entity) to indicate whether a notification is requested from the NG-RAN when the QoS requirements are no longer met using the currently configured delivery mode, or to request a delivery mode switch from a MBMS user service (multicast / broadcast) to a unicast service, or to request a delivery mode switch from a unicast service to a MBMS user service (multicast / broadcast). Upon reception of the notification from the NG-RAN, the AMF 203 / SMF 204 can forward the notification to the PCF 206 or BM-SC / MBMF 207. Unless the PCF indicates differently, the BM-SC or the BM-SC cooperating with the SMF 204 reconfigures the UE 201 using NAS signaling with the new delivery mode. The core network can also reconfigure the RAN accordingly to align with the new delivery mode configured into the UE 201.

[0300] Additionally, the RAN node 202 can send a notification message to the MB-UPF 209 over the N3 tunnel, the notification message indicating to the MB-UPF 209 that there are no UEs 201 under the RAN node 202 that are still in the multicast group (e.g., receiving application data via the multicast session), so that the MB-UPF 209 can stop sending multicast application data to this RAN node 202 in the future via the N3 tunnel.

[0301] Handover from shared MBS service delivery to individual MBS service delivery

[0302] The previous sections disclose methods of switching that are not due to mobility (e.g., no handover is needed). In this section, methods of switching between individual MBS service delivery and shared MBS service delivery that involve a handover procedure are discussed. With reference to the handover procedure, the “source” is the RAN node that is currently connected with the UE and providing the UE with access to the network, and the “target” is the RAN node that is intended or needed for connecting with the UE to provide the UE with access to the network.

[0303] When a UE 201 receiving multicast data moves from a source RAN node to a target RAN node, the UE 201 or the source RAN node can trigger a delivery mode switching procedure as well as a handover procedure. This trigger can be because the target RAN node does not support the MBS service, or the UE 201 is outside the MBS service area. Additionally, an NF such as the AMF 203, MBMF, or MB-SMF 208 / SMF 204 can also trigger the switch after the source RAN node is notified about the handover. For example, when initiating a PDU session establishment or modification procedure, the SMF 204 can discover that the target RAN node is outside the MBS service area. In the case that the MBSF is managing the MB-SMF 208 or SMF 204 with respect to the MBS service, the MBSF can trigger the switch.

[0304] With the shared service delivery method, the UE 201 receives multicast data via the MBS PDU session through the source RAN node. After switching to the individual service delivery method, the UE 201 can receive data via the PDU session through the target RAN node. Significant issues can include the following. A first issue regarding how to link the MBS PDU session for the shared delivery method with the PDU session for the individual delivery method to ensure that the QoS requirements are met. Or a second issue regarding how to prevent potential data loss during the handover / switching process.

[0305] For the first issue, it can be assumed that different SMFs 204 manage the MBS PDU session and the PDU session, respectively. During handover, when the UE 201 / SMF 204 establishes a new PDU session or updates an existing PDU session for the separate delivery method, the SMF 204 can use N2 SM messages to send the QoS mapping information between the MBS session and the PDU session and the PDU session information to the source RAN node, so that the source RAN node can be able to map the QoS of the MBS session to the QoS of the PDU session. This can be used by the source RAN node during handover, especially when the target RAN node does not support the MBS service, e.g. it is not aware of any MBS QoS. Specifically, based on the MBS QoS, the source RAN node can inform the target RAN node about the QoS requirements for one or more QoS flows in the PDU session for the separate delivery method. Subsequently, the target RAN node can adjust the RAN resources for data transmission to the UE 201 based on the QoS of the PDU session for separate delivery. The source RAN node can transmit such information directly to the target RAN node via the Xn interface, or to the AMF 203 via the N2 interface, which forwards the information to the target RAN node. The PDU session information can include the PDU session ID, the QFI, the QoS parameters of the QFI such as 5QI, the maximum data rate, the maximum aggregate flow rate, or QoS characteristics such as error rate or delay.

[0306] Further, the UE 201 can also be equipped with such QoS mapping, so it can provide the QoS requirements of the PDU session established for separate traffic delivery based on the mapping to the target RAN node. The benefit is that the UE 201 can provide the mapping to the target RAN node at the beginning of the handover procedure, so that the handover procedure can be completed faster. The MB-SMF 208 / SMF 204 managing the MBS session or the source RAN node can provide the QoS mapping to the UE 201. The QoS mapping information can include the QFI of the MBS PDU session and the QFI of the PDU session for separate traffic delivery with the same QoS requirements; the 5QI of the MBS PDU session and the 5QI of the PDU session for separate traffic delivery.

[0307] With respect to the second issue, the handover is typically completed before the delivery mode switch procedure. During the time period between the handover completion and the switch completion, the UE 201 can not be able to receive data, regardless of whether the target RAN node supports the MBS service, because the handover is done before the switch is completed, e.g., the PDU session for the individual traffic delivery has not been established or activated. One possible approach is to have the source RAN node continue to receive and store MBS data during this time period, and forward the data to the target RAN node. When the PDU session is ready for individual traffic delivery to the UE 201 (e.g., the switch has been completed), the target RAN node informs the source RAN node, and the source RAN node stops the MBS data storage and forwarding. The source RAN node and the target RAN node can exchange data of the storage and forwarding information during the handover procedure. The information can include the following: at what frequency the source RAN node should forward the data; the maximum amount of data that the source RAN node can store for the UE 201 after the handover; how long the source RAN node can keep the data if it does not hear anything from the target RAN node; what forwarding mechanism to use for the data forwarding. Possible forwarding mechanisms can be either directly to the target RAN node or the UPF 205, which then sends the data to the target RAN node via N3 tunnel, the source RAN node pushes the stored data, or the target RAN node retrieves the data from the source RAN node. In addition, the 2 RAN nodes can need to establish a data forwarding channel that is transparent to the 5GC.

[0308] An alternative approach is to have the PDU session ready for individual delivery during the handover. In other words, the 5GC needs to establish or modify the PDU session for individual delivery during the handover. When the handover is completed, the target RAN node can be able to deliver data to the UE 201 using the individual delivery method via the associated PDU session. In this sense, the session management procedure can be integrated into the handover procedure.

[0309] Switching from individual MBS service delivery to shared MBS service delivery using handover

[0310] When the switch from the individual delivery method to the shared delivery method is coupled with the handover, the same issues need to be addressed, such as 1) how to link the MBS PDU session for the shared delivery method with the PDU session for the individual delivery method to ensure that the QoS requirements are met; or 2) how to prevent potential data loss during the handover / switch procedure.

[0311] For the first issue, the same approach disclosed in the previous paragraph can be applied if the source RAN node supports the MBS service, e.g., the source RAN node is equipped with the QoS mapping between the PDU session and the MBS session and the MBS session information, enabling the source RAN node to inform the target RAN node how to set the RAN resources to deliver the multicast data to the UE 201 to meet the QoS requirements. If the source RAN node does not support the MBS service, the source RAN node is not able to map the QoS of the individual delivery method to the QoS of the shared delivery. In this case, the UE 201 can be equipped with the QoS mapping information, and thus the UE 201 can use the necessary QoS information to provision the target RAN node to configure the RAN resources to send the multicast broadcast. An alternative approach is to handover the PDU session associated with the source RAN node for the individual delivery method to the target RAN node. In other words, the target RAN node can have two N3 tunnels: 1) one N3 tunnel can be used for the individual delivery before the handover, and 2) another N3 tunnel can be used for the shared delivery after the handover. Different UPFs are possible to terminate the N3 tunnels. In addition, the application server or the AF 210 can be aware of these changes with the notification from the 5GC, and accordingly send the data to the appropriate UPF 205.

[0312] For the 2nd issue, the same approach can be applied compared to the approach discussed in the previous paragraph.

[0313] User interface

[0314] The parameters used in the delivery mode switching procedure can be provisioned by the end user (UE), the network operator, or the application content provider through a user interface. In addition, the switching UE, the content provider, or the network operator can retrieve the statistics and display the statistics through the user interface. The user interface can be implemented to configure or program those parameters with default values, and to enable or disable the switching procedure. Figure 13 An exemplary user interface is shown in FIG.

[0315] Definitions and abbreviations

[0316] Table 1 below shows a list of acronyms that can appear in the above description. Unless otherwise specified, the acronyms used herein refer to the corresponding terms listed below:

[0317] Table 1

[0318]

[0319]

[0320]

[0321] It is to be understood that the entities performing the steps illustrated herein, such as in Figures 6-12 ) can be logical entities. The steps can be stored in a memory of, and executed on a processor of, a device, server or computer system as illustrated in Figure 1F or Figure 1G It is contemplated that steps can be skipped, combined or added between the example methods disclosed herein, for example Figures 6-12 .

[0322] It is to be understood that any or all of the apparatuses, systems, methods and processes described herein can be embodied in the form of computer executable instructions embodied in a computer readable storage medium such as a memory (e.g., a first memory 118 or a second memory 91) of a mobile device or a computing system, and executed by a processor (e.g., a processor 118 or 91) of a computing system or mobile device. Specifically, any of the steps, operations or functions described herein can be implemented in the form of such computer executable instructions arranged to execute on the processor of a device or computing system configured for wireless or wired network communication. Computer readable storage media include volatile and nonvolatile, removable and non-removable media implemented in any non-transitory (e.g., tangible or physical) method or technology for storage of information such as computer readable instructions, data structures, program code or the like, but such computer readable storage media do not include signals. Computer readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible or physical medium for storage of desired information and which can be accessed by a computing system.

[0323] For the sake of clarity, specific terminology is employed throughout the description of the preferred methods, systems or apparatuses of the subject matter of the present disclosure, delivery mode switching for multicast and broadcast services in networks such as 5G, as illustrated in the accompanying drawings. However, the claimed subject matter is not intended to be limited to the specific terminology so selected.

[0324] The various techniques described herein can be implemented in connection with hardware, firmware or software such as is made of computer readable program code embodied or stored in a computer readable storage medium such as a memory (e.g., a first memory 118 or a second memory 91) of a mobile device or a computing system, and executed by a processor (e.g., a processor 118 or 91) of a computing system or mobile device. As used herein, the terms “apparatus,” “network apparatus,” “node,” “device,” “network node,” or the like can be used interchangeably. Furthermore, the word “or” is generally employed in its sense including at least one of the items from which it is selected.

[0325] This written description uses examples to disclose the disclosed subject matter, including the best mode(s), and also to enable any person skilled in the art to practice the disclosed subject matter, including making and using any devices or systems and performing any incorporated methods. The disclosed subject matter can include, but is not limited to, examples as described herein, and / or in the appended claims.

[0326] Methods, systems, and apparatus, among other things, as described herein can provide for delivery mode switching for multicast or broadcast services in a network, such as 5G. A method, system, computer-readable storage medium, or apparatus provides for determining that a triggering event has occurred at one or more of a user equipment (e.g., UE), a network equipment (e.g., core network equipment), a content provider system, or a RAN node, where the triggering event indicates a need to switch between a first one of a unicast mode, a multicast mode, and a broadcast mode and a second one of the unicast mode, the multicast mode, and the broadcast mode; and initiating a switch from the first one of the unicast mode, the multicast mode, and the broadcast mode to the second one of the unicast mode, the multicast mode, and the broadcast mode for transmitting data to the user equipment based on the occurrence of the triggering event. A system, computer-readable storage medium, or apparatus provides for switching between at least two of a unicast mode, a multicast mode, and a broadcast mode for transmitting data to a user equipment via a 5G network. Also included is transmitting a request from the user equipment and to a network entity to switch from a unicast mode to a multicast mode; performing MBS service authorization and MBS session management configuration using the network entity; notifying an application server and a RAN node of a mode change from a unicast mode to a multicast mode from the user equipment; or receiving information from the network by the user equipment for joining a multicast group. The request can include one or more of a data type including: an identifier of the user equipment; a session identifier and a stream descriptor for a current unicast data transmission; an indication of a data network initiating and / or terminating data for multicast and unicast; an indication of a network slice that the user equipment is using for unicast data transmission; an application identifier indicating that application data is to be delivered through multicast / unicast; a multicast session identifier; quality of service information; a transition time identifier; a multicast credential: the UE provides additional credentials needed to establish or join a multicast service or group; a multicast request context; a multicast IP address: an identification of a multicast session / group; other MBS session context information; a TMGI identifying a multicast group that the UE wants to join; or a multicast session identifier or reference identifier. A response message including an indication of authorization for the requesting UE to use MBS also includes a temporary mobile group identity (TMGI) or an Internet Protocol multicast address to identify a multicast group. The received information can include QoS mapping information between a MBS session and a PDU session and other session information. Delivery mode switching information can be received from a source RAN node via a N2 interface. After handover completion but before the switch is complete, the source RAN node can temporarily store multicast data and forward the data to a target RAN node after the switch is complete. The request can be a NAS request message. A system, computer-readable storage medium, or apparatus provides for determining that a triggering event has occurred at a user equipment; or initiating a switch from a unicast mode to a multicast mode by the user equipment based on the occurrence of the triggering event.A system, computer-readable storage medium, or apparatus provides transmitting, from a user equipment and to a network entity, a request to switch from a unicast mode to a multicast mode; performing, using the network entity, MBS service authorization and MBS session management configuration; notifying an application server and a RAN node about the mode change from unicast mode to multicast mode from the user equipment; or receiving, by the user equipment from the network, information for joining a multicast group. As disclosed herein, in addition to unicast to multicast switching, there can be any type of switching between unicast, multicast, or broadcast. In a manner consistent with other portions of the DETAILED DESCRIPTION, all combinations of this paragraph and the following paragraphs (including deletion or addition of steps) are contemplated.

[0327] A method, system, computer-readable storage medium, or apparatus provides receiving, by a network function, a non-access stratum (NAS) message from a requesting user equipment (UE); sending, by the network function, a request to a multicast and broadcast management function (MBMF) to determine whether the requesting UE is authorized to use a multicast service or a multicast / broadcast service (MBS); receiving, in response to sending the request to the MBMF, a response message including an authorization indication for the requesting UE to use the multicast service or the multicast / broadcast service (MBS); determining that a MBS session is not available; sending, based on the MBS session not being available and the authorization indication, a MBS session establishment message or a modification message; receiving, in response to sending the MBS session establishment message or the modification message, a response with multicast / broadcast user plane function (MB-UPF) information; or sending, based on the MB-UPF information, a message (e.g., a N2 message) to a radio access node to inform the radio access node of an upcoming switch from unicast mode to multicast mode for data transmission to the requesting UE. Unicast means that the 5GC sends 1 copy of a packet to a single UE. Multicast, therefore, refers to the 5GC sending 1 copy of a packet to multiple UEs that join a group. From the RAN’s perspective, multicast from the 5GC to the UEs can be done through unicast between the RAN and the UEs or multicast between the RAN and the UEs. The method, system, apparatus, or computer-readable storage medium can provide detecting a trigger event; and initiating, based on the trigger event, a switch from unicast mode to multicast mode including sending a request to a multicast and broadcast management function (MBMF) to determine whether the requesting UE is authorized to use a multicast service or a multicast / broadcast service (MBS). The trigger can occur at one or more of the requesting UE or a RAN node. The trigger event can be any number of events disclosed herein, which can include a threshold number of disclosed information, which can be a type of information (e.g., error rate) or a combination of information (e.g., error rate and bandwidth). The method, system, apparatus, or computer-readable storage medium can provide receiving information from a source RAN node via a N2 interface; and forwarding, in response to receiving the information via the N2 interface, the information to a target RAN node. In a manner consistent with other portions of the DETAILED DESCRIPTION, all combinations of the present paragraph and the following paragraphs (including deletion or addition of steps) are contemplated.

[0328] A method, system, computer-readable storage medium, or apparatus provides receiving data from a radio access node on a unicast packet data unit session; determining that data transmission is to be conducted using multicast; in response to the determination that data transmission is to be conducted using multicast, sending a message to request a delivery mode switch from unicast to multicast; receiving, based on the message to request the delivery mode switch from unicast to multicast, a NAS message carrying a delivery mode switch response; and sending an application layer signal to notify a network device of an upcoming switch from unicast to a multicast session. The application layer signal to notify the network device indicates when the multicast session will start and is for which application, while unicast data transmission continues. In response to sending the application layer signal, data is received via the multicast session.

Claims

1. A method for switching to a multicast or broadcast service (MBS) in a network, the method comprising: Receive data from the first radio access node in the first unicast session; The first information about the MBS is received by the wireless transmit / receive unit (WTRU), and the first information about the MBS includes a session identifier; The WTRU determines to join the MBS based on the first information about the MBS; Based on the determination to join the MBS, a first non-access stratum NAS message is sent to request a switch in delivery mode from the first unicast session to the multicast session; Based on the first NAS message used to switch the delivery mode from a first unicast session to a multicast session, a second NAS message is received, wherein the second NAS message is a response including a Temporary Mobile Group Identifier (TMGI) associated with the MBS. In the multicast session, data associated with the MBS is received from the first radio access node; When the WTRU moves from the first radio access node to a second radio access node that does not support MBS, it switches from the multicast session to the second unicast session. as well as The second unicast session is used to receive data for the MBS from the second radio access node.

2. The method according to claim 1, wherein the first NAS message is a Packet Data Unit (PDU) session establishment or a Packet Data Unit (PDU) session modification.

3. The method of claim 1, wherein the first information includes application information indicating an application identifier associated with the MBS.

4. The method of claim 1, wherein the first NAS message is sent to the access and mobility management function.

5. The method of claim 1, wherein the multicast session is established before joining the MBS.

6. The method of claim 1, wherein the WTRU receives the second NAS message from the Access and Mobility Management function via Radio Resource Control (RRC) messages.

7. The method according to claim 1, wherein the first information includes service quality information.

8. The method of claim 1, wherein the first information includes a Temporary Mobile Group Identifier (TMGI).

9. A wireless transmit / receive unit (WTRU) for switching to multicast or unicast service (MBS) in a network, the WTRU comprising: processor; and A memory coupled to the processor, the memory storing executable instructions that, when executed by the processor, cause the processor to perform operations including: Receive data from the first radio access node in the first unicast session; Receive first information about the MBS, the first information about the MBS including a session identifier; The WTRU determines to join the MBS based on the first information about the MBS; Based on the determination to join the MBS, a first non-access stratum NAS message is sent to request a switch in delivery mode from the first unicast session to the multicast session; Based on the first NAS message used to request a switch in delivery mode from a first unicast session to a multicast session, a second NAS message is received, wherein the second NAS message is a response including a Temporary Mobile Group Identifier (TMGI) associated with the MBS. In the multicast session, data associated with the MBS is received from the first radio access node; When the WTRU moves from the first radio access node to a second radio access node that does not support MBS, it switches from the multicast session to the second unicast session. as well as The second unicast session is used to receive data for the MBS from the second radio access node.

10. The WTRU of claim 9, wherein the first NAS message is a Packet Data Unit (PDU) session establishment or a Packet Data Unit (PDU) session modification.

11. The WTRU of claim 9, wherein the first information includes application information indicating an application identifier associated with the MBS.

12. The WTRU of claim 9, wherein the first NAS message is sent to the Access and Mobility Management function.

13. The WTRU of claim 9, wherein the multicast session is established prior to joining the MBS.

14. The WTRU of claim 9, wherein the WTRU receives the second NAS message from the Access and Mobility Management function via Radio Resource Control (RRC) messages.

15. The WTRU of claim 9, wherein the first information includes quality of service information.

16. The WTRU of claim 9, wherein the first information includes a Temporary Mobile Group Identifier (TMGI).

17. A computer-readable storage medium storing computer-executable instructions, which, when executed by a computing device, cause the computing device to perform operations including: Receive data from the first radio access node in the first unicast session; The first information about the MBS is received by the wireless transmit / receive unit (WTRU), and the first information about the MBS includes a session identifier; The WTRU determines to join the MBS based on the first information about the MBS; Based on the determination to join the MBS, a first non-access stratum NAS message is sent to request a switch in delivery mode from the first unicast session to the multicast session; Based on the first NAS message used to request a switch in delivery mode from a first unicast session to a multicast session, a second NAS message is received, wherein the second NAS message is a response including a Temporary Mobile Group Identifier (TMGI) associated with the MBS. In the multicast session, data associated with the MBS is received from the first radio access node; When the WTRU moves from the first radio access node to a second radio access node that does not support MBS, it switches from the multicast session to the second unicast session. as well as The second unicast session is used to receive data for the MBS from the second radio access node.

18. The computer-readable storage medium of claim 17, wherein the first information includes a Temporary Mobile Group Identifier (TMGI).

19. The computer-readable storage medium of claim 17, wherein the WTRU receives the second NAS message from the access and mobility management function via a Radio Resource Control (RRC) message.

Images