Method and apparatus for network switching

Abstract

The present disclosure relates to a pre-5G or 5G communication system to be provided for supporting higher data rates beyond 4G communication systems such as LTE. A method for switching from a first data transmission mode to a second data transmission mode includes an NG-RAN node, a core node, and a content provider, wherein the method includes: the NG-RAN node sends first data from the content provider to the UE in a first session according to the first data transmission mode; the UE or the NG-RAN node or the core node or the content provider decides to switch from the first data transmission mode to the second data transmission mode; the core node initializes a second session for the second data transmission mode; the core node switches from the first data transmission mode to the second data transmission mode; and the NG-RAN node sends second data from the content provider to the UE in the second session according to the second data transmission mode.

Description

Technical Field

[0001] The present invention relates to a network switching. In particular, the present invention relates to switching in a 5G network or a wireless communication network, for example from unicast transmission to multicast transmission or broadcast transmission and / or vice versa. Background Art

[0002] In order to meet the demand for wireless data services that has increased since the deployment of 4G (fourth generation) communication systems, efforts have been made to develop improved 5G (fifth generation) or pre-5G communication systems. Therefore, 5G or pre-5G communication systems are also referred to as "beyond 4G networks" or "post-LTE systems."

[0003] 5G communication systems are considered to be implemented in higher frequency (mmWave) bands such as the 60 GHz band in order to achieve higher data rates. In order to reduce the propagation loss of radio waves and increase the transmission distance, beamforming, massive multiple-input multiple-output (MIMO), full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and massive antenna technology are discussed in 5G communication systems.

[0004] In addition, in the 5G communication system, development for system network improvements is being carried out based on advanced small cells, cloud radio access networks (RAN), ultra-dense networks, device-to-device (D2D) communication, wireless backhaul, mobile networks, collaborative communications, coordinated multi-point (CoMP), receiving-end interference cancellation, etc.

[0005] In 5G systems, hybrid FSK with QAM modulation (FQAM) and sliding window superposition coding (SWSC) have been developed as advanced coded modulation (ACM), and filter bank multi-carrier (FBMC), non-orthogonal multiple access (NOMA) and sparse code multiple access (SCMA) as advanced access technologies. Summary of the invention

[0006] Solution to the problem

[0007] There is a need to provide switching in a 5G network or wireless communication system, for example from unicast transmission to multicast transmission or broadcast transmission and / or vice versa.

[0008] One object of the present invention is, in particular, to provide a process for switching in a 5G network or wireless communication system and a 5G network that at least partially eliminates or mitigates at least some of the disadvantages of the prior art, whether identified herein or elsewhere. For example, an object of an embodiment of the present invention is to provide a process for switching from a first data transmission method (mode) to a second data transmission method (mode) in a 5G network, which improves switching from unicast transmission to multicast transmission or broadcast transmission and / or vice versa. For example, an object of an embodiment of the present invention is to provide a 5G network that improves switching from unicast transmission to multicast transmission or broadcast transmission and / or vice versa.

[0009] In particular, the current invention focuses on the transmission of multicast / broadcast content, and switching the transmission mode from unicast to multicast / broadcast and vice versa on the 5GC of 5GS.

[0010] A first aspect provides a process for switching from a first data transmission method to a second data transmission method in a 5G network, the 5G network comprising a set of user equipment UEs (including a first UE) communicatively coupled to the 5G network, a set of new generation radio access network (NG-RAN) nodes (including a first NG-RAN node), a 5G core, and a set of content providers (including a first content provider), wherein the process comprises: sending, by the first NG-RAN node, first data from the content provider set to the first UE in a first session according to the first data transmission method; deciding, by the first UE or the first NG-RAN node or the 5G core or the content server, to switch from the first data transmission method to the second transmission method; initializing, by the 5G core, a second session for the second transmission method; switching, by the 5G core, from the first data transmission method to the second transmission method; and sending, by the first NG-RAN node, second data from the content provider set to the first UE in a second session according to the second data transmission method.

[0011] A second aspect provides a 5G network for switching from a first data transmission method to a second data transmission, comprising a set of user equipment UEs including a first UE, a set of new generation radio access network (NG-RAN) nodes (including a first NG-RAN node), a 5G core and a set of content providers (including a first content provider) communicatively coupled to the 5G network; wherein the first NG-RAN node is configured to send first data from the content provider set to the first UE according to the first data transmission method in a first session; wherein the first UE or the first NG-RAN node or the 5G core or the content server is configured to decide to switch from the first data transmission method to the second transmission method; wherein the 5G core is configured to initialize a second session for the second transmission method; wherein the 5G core is configured to switch from the first data transmission method to the second transmission method; and wherein the first NG-RAN node is configured to send second data from the content provider set to the first UE according to the second data transmission method in the second session.

[0012] A third aspect provides a method for switching from a first data transmission mode to a second data transmission mode in a communication network including a new generation radio access network (NG-RAN) node, a core node and a content provider, wherein the method comprises: sending, by the NG-RAN node, first data from the content provider to a user equipment (UE) according to the first data transmission mode in a first session, wherein the first data transmission mode is a unicast transmission mode via separate delivery; deciding, by the NG-RAN node or the core node or the content provider, to switch from the first data transmission mode to the second data transmission mode, wherein the second data transmission mode is a multicast transmission mode via shared delivery; initializing, by the core node, a second session for the second data transmission mode; switching, by the core node, from the first data transmission mode to the second data transmission mode; and sending, by the NG-RAN node, second data from the content provider to the UE in the second session according to the second data transmission mode.

[0013] A fourth aspect provides a device for switching from a first data transmission mode to a second data transmission mode in a communication network, the device comprising a new generation radio access network (NG-RAN) node, a core node and a content provider, wherein the NG-RAN node is configured to send first data from the content provider to a user equipment (UE) according to the first data transmission mode in a first session, wherein the first data transmission mode is a unicast transmission mode delivered via a separate method, wherein the NG-RAN node or the core node or the content provider is configured to decide to switch from the first data transmission mode to the second data transmission mode, wherein the core node is configured to initialize a second session for the second data transmission mode, wherein the second data transmission mode is a multicast transmission mode delivered via a shared method, wherein the core node is configured to switch from the first data transmission mode to the second data transmission mode, and wherein the NG-RAN node is configured to send second data from the content provider to the UE according to the second data transmission mode in the second session.

[0014] A fifth aspect provides a method for switching from a first data transmission mode to a second data transmission mode in a communication network including a new generation radio access network (NG-RAN) node, a core node and a content provider, wherein the method includes: sending, by the NG-RAN node, first data from the content provider to a user equipment (UE) according to the first data transmission mode in a first session, wherein the first data transmission mode is a multicast data transmission mode or a broadcast data transmission mode via shared delivery; deciding, by the NG-RAN node or the core node or the content provider, to switch from the first data transmission mode to the second data transmission mode, wherein the second data transmission mode is a unicast transmission mode via separate delivery; initializing, by the core node, a second session for the second data transmission mode; switching, by the core node, from the first data transmission mode to the second data transmission mode; and sending, by the NG-RAN node, second data from the content provider to the UE in the second session according to the second data transmission mode.

[0015] A sixth aspect provides a device for switching from a first data transmission mode to a second data transmission mode in a communication network, the device comprising a new generation radio access network (NG-RAN) node, a core node and a content provider, wherein the NG-RAN node is configured to send first data from the content provider to a user equipment (UE) according to the first data transmission mode in a first session, wherein the first data transmission mode is a multicast data transmission mode or a broadcast data transmission mode via shared delivery, wherein the NG-RAN node or the core node or the content provider is configured to decide to switch from the first data transmission mode to the second data transmission mode, wherein the second data transmission mode is a unicast transmission mode via separate delivery, wherein the core node is configured to initialize a second session for the second data transmission mode, wherein the core node is configured to switch from the first data transmission mode to the second data transmission mode, wherein the NG-RAN node is configured to send second data from the content provider to the UE according to the second data transmission mode in the second session. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] For a better understanding of the invention and to illustrate how exemplary embodiments of the invention may be put into effect, reference is made, by way of example only, to the attached schematic diagram, in which:

[0017] Figure 1 Schematically depict the eMBMS architecture;

[0018] Figure 2 Schematically depict the architecture based on 5GS services;

[0019] Figure 3A schematically depicting a first architecture reference model for supporting multicast / broadcast in 5G; Figure 3B Schematic depiction of a Figure 3A The first architectural reference model for supporting multicast / broadcast in 5G;

[0020] Figure 4 schematically depicting a third architecture reference model for supporting multicast / broadcast in 5G;

[0021] Figure 5 schematically depicts a flow chart according to an exemplary embodiment;

[0022] Figure 6 schematically depicts a process according to an exemplary embodiment;

[0023] Fig. 7A and Figure 7B schematically depicts a process according to an exemplary embodiment;

[0024] Fig. 8A and Figure 8B schematically depicts a process according to an exemplary embodiment;

[0025] Fig. 9A and Fig. 9B schematically depicts a process according to an exemplary embodiment;

[0026] Fig. 10A and Fig. 10B schematically depicts a process according to an exemplary embodiment;

[0027] Fig.11A and Fig. 11B schematically depicts a process according to an exemplary embodiment;

[0028] Fig. 12A and Fig. 12B schematically depicts a process according to an exemplary embodiment;

[0029] Fig.13A and Fig. 13B schematically depicts a process according to an exemplary embodiment;

[0030] Fig.14 schematically depicts a use case of a process according to an exemplary embodiment;

[0031] Fig.15A and Fig. 15B schematically depicts a process according to an exemplary embodiment;

[0032] Fig.16A , Fig. 16B , Fig. 16C and Fig.16D schematically depicts a process according to an exemplary embodiment;

[0033] Fig.17 An example communication device is depicted according to an exemplary embodiment of the present disclosure. DETAILED DESCRIPTION

[0034] According to the present invention, as set forth in the attached claims, there is provided a process for switching from a first data transmission method to a second data transmission method in a 5G network. Also provided is a 5G network for switching from a first data transmission method to a second data transmission method in a 5G network. Other features of the present invention will be apparent from the dependent claims and the following description.

[0035] The present invention focuses on the transmission of multicast / broadcast content and the switching of the delivery method from unicast to multicast / broadcast and vice versa. The present invention is relevant to the next generation 5G cellular networks for which no delivery method switching solution is approved at the time of submission.

[0036] Multicast / Broadcast in 4G Networks

[0037] Multicast / broadcast is a data transmission method that delivers the same content to multiple devices (i.e., a subset of devices or all devices in the network) at the same time. In 4G cellular networks, multicast / broadcast services are provided by enhanced Multimedia Broadcast Multicast Service (eMBMS). There is currently no equivalent standardized solution for 5G systems. To enable eMBMS, the following entities have been introduced in the 4G core network architecture:

[0038] i. Multicast Coordination Entity (MCE): MCE is usually a logical entity that can be co-located with other network elements. It is responsible for admission control, network resource allocation and MBMS session control.

[0039] ii. MBMS Gateway (MBMS-GW): MBMS-GW is generally another logical entity responsible for forwarding MBMS data to the base station sending the service and performing MBMS session control on the Radio Access Network (RAN) via the Mobility Management Entity (MME).

[0040] ⅲ. Broadcast Multicast Service Center (BM-SC): BM-SC includes MBMS bearer services and MBMS user services. It is the entity responsible for scheduling MBMS services, announcing services to users, authorizing users, allocating bearer service identifiers to services, and initiating / terminating MBMS service resources.

[0041] Figure 1 Schematically depict the eMBMS architecture;

[0042] In a 4G network, an eMBMS multicast session includes the following steps:

[0043] i. Subscription, during which a device subscribes to a service by establishing an agreement with a content provider.

[0044] ii. Service announcements inform users about available user services and lists of user service bundles.

[0045] iii. Joining is the process by which a device becomes a member of a multicast group by indicating its willingness to receive data of a multicast service.

[0046] iv. Session start is the time when BM-SC is ready to start sending multicast data. Specifically, at the start of a session, BM-SC allocates the required network resources for the MBMS service.

[0047] v. MBMS notifies devices for receiving MBMS services about upcoming data transmissions.

[0048] ⅵ. Data transfer is the stage where MBMS data is being transferred to the device.

[0049] ⅶ. Session Stop is the point when there is no more MBMS data to transfer and therefore the BM-SC tears down any bearers established during the Session Start procedure.

[0050] VIII. Leave is a process used by a device when it no longer wishes to receive data for an MBMS service to which it had previously subscribed and therefore needs to leave the multicast group.

[0051] In an eMBMS broadcast session, only the steps of service announcement, session start, MBMS notification, data transfer and session stop are included.

[0052] MBMS services in 4G networks can be delivered in either full service or transport-only mode. In the former mode, the MBMS system provides full service layer capabilities. The BM-SC knows what is being sent and it can transform it into a 3GPP compatible stream. In the latter mode, the 4G network provides only data transmission services. Any signaling and data being transferred via the MBMS bearer is transparent to the BM-SC, and the decision on whether to send data in multicast or unicast depends on the content provider.

[0053] Multicast / Broadcast to Unicast Switching in 4G

[0054] When data is being sent in full service mode and depending on the number of devices receiving the same data, it may be desirable to switch the previous unicast transmission to multicast in order to save network resources. To this end, 3GPP has proposed the Multicast on Demand (MooD) service [1]. According to this solution, when the number of devices consuming the same content in unicast mode reaches a certain threshold (usually defined by the mobile network operator (MNO)), the network dynamically switches the transmission method to multicast / broadcast. MooD mainly targets mobile TV, radio broadcasting, live streaming video services and emergency alerts.

[0055] 5G Architecture

[0056] The 5G System (5GS) is designed to provide more flexible deployment than the previous 4G system. In contrast to the 4G architecture where different physical entities are responsible for different functionalities, the 5G network moves towards a service-based architecture (SBA) architecture [2] where different functionalities are provided by a collection of network functions (NFs).

[0057] In the case of NF, 5G network allows the implementation of different network slices, which allows the reuse of virtualized and independent logical functions on the same physical infrastructure. In 5GS, network slices are identified by single network slice selection assistance information (S-NSSAI). As described in [2], [4], S-NSSAI consists of the following:

[0058] - Slice / Service Type (SST), which refers to the expected network slice behavior in terms of characteristics and services;

[0059] - Slice Differentiator (SD), which is optional information that supplements the slice / service type to distinguish among multiple network slices of the same slice / service type.

[0060] Additionally, a related concept is a Network Slice Instance (NSI) ID identified and defined as a collection of network function instances and required resources (e.g., compute, storage, and networking resources) that form a deployed network slice. Crucially, the current specification allows multiple NSI IDs to be associated with the same S-NSSAI, while also allowing multiple S-NSSAIs to be associated with one NSI ID. Therefore, the mapping is twofold.

[0061] This architecture enables flexible and highly adaptable deployment of new services for vertical industries with different requirements. The main concerns and differences compared to the 4G architecture [2] are as follows:

[0062] - Separate control and user plane NFs to allow independent and flexible deployment

[0063] - Modularity of functions to be designed

[0064] -Definition of processes and services (where possible)

[0065] - Possibility for each NF to interact directly with other NFs as needed

[0066] - Minimization of dependencies between the access network (AN) and the core network (CN)

[0067] -Support stateless NF to separate computing resources from storage resources.

[0068] Figure 2 Schematically depict the architecture based on 5GS services;

[0069] SBA defines basic NFs such as Figure 2 Note that the NFs shown are not exhaustive and only include functions relevant to the present invention. The detailed functionality of each NF is described in [2].

[0070] Although eMBMS services exist in 4G networks, eMBMS was not initially included in the specifications for 5G networks. However, it is now considered a fundamental requirement and discussions are currently ongoing on the architectural enhancements required to support multicast / broadcast in 5GS. Current proposals involve different methodologies / procedures to provide dynamic switching between multicast / broadcast and unicast services in 5GS for different architectural models currently being discussed within 3GPP.

[0071] 5MBS Architecture Reference Model

[0072] 3GPP has agreed to include a research (and subsequent) work item on 5G multicast broadcast service (5MBS) in Rel-17. Since 5GS is considered to be a completely new core network (i.e., 5GC) relative to previous versions since Rel-17, three different architecture reference models can be considered in Rel-17 to support multicast / broadcast functionality in 5G networks. It should be understood that the methods and networks described herein are applicable to different architecture reference models as described herein, and the methods and networks described herein do not rely on the adoption of any particular architecture reference model. The difference among the architecture reference models lies in the number of new NFs (if any) introduced, and the functionality assumed by each new and existing NF to support multicast / broadcast transmission and delivery method switching.

[0073] In the context of the present invention, the following definitions apply:

[0074] - Multicast communication service: a communication service in which the same service and the same specific content data are provided simultaneously to a dedicated set of UEs (ie not all UEs within the multicast coverage are authorized to receive the data).

[0075] - Broadcast communication service: a communication service in which the same service and the same specific content data are provided simultaneously to all UEs in a geographical area (ie all UEs in the broadcast coverage area are authorized to receive the data).

[0076] -MBS service: a communication service that is a multicast communication service and / or a broadcast communication service.

[0077] - Multicast service area: An area within which data of one or more multicast sessions is transmitted.

[0078] - Broadcast service area: An area within which data of one or more broadcast sessions is transmitted.

[0079] - MBS service area: an area within which data of one or more multicast sessions and / or broadcast sessions are transmitted.

[0080] -MBS session: a multicast session or a broadcast session.

[0081] - MBS unicast session: a unicast session that can be switched to a multicast session and / or a broadcast session.

[0082] From a 5G CN point of view, two delivery methods are possible:

[0083] -5GC Single MBS Service Delivery: A delivery service in which the 5G CN receives a single copy of MBS data packets via each UE PDU session and delivers a single copy of those MBS data packets to a single UE, also referred to herein as unicast.

[0084] -5GC shared MBS service delivery: A delivery service in which the 5G CN receives a single copy of MBS data packets and delivers a single copy of those MBS data packets to the RAN nodes, also referred to herein as multicast.

[0085] From the RAN point of view, (in the case of shared delivery) two delivery methods can be used to transmit MBS data packet flows over the radio:

[0086] - Point-to-Point (PTP) delivery method: A RAN node delivers a separate copy of an MBS data packet to a single UE over the radio.

[0087] - Point-to-Multipoint (PTM) delivery method: A RAN node delivers a single copy of an MBS data packet to a set of UEs over the radio.

[0088] First Architecture Reference Model

[0089] Figure 3A A first architecture reference model for supporting multicast / broadcast in 5G is schematically depicted.

[0090] In the first architecture reference model ( Figure 3A ), a new NF (i.e., broadcast multicast function (BMF)) is introduced to which the principle of separation of control and user planes is applicable, thus generating Figure 3A The BMF-Control Plane (BMF-C) and BMF-User Plane (BMF-U) entities shown in the figure. They assume the role of BM-SC in the 4G eMBMS framework. The BMF-C function is responsible for controlling multicast / broadcast sessions, such as service announcements and IP multicast / broadcast session control, and can be achieved through the Nbmf interface. BMF-U is responsible for functionality such as data transmission and content synchronization from content providers. It can be achieved through BMF-C using the Nxx interface. BMF-U can also communicate directly with UPF through the N6' interface.

[0091] The functionality of MBMS-GW is incorporated into SMF and UPF NFs. Specifically, multicast / broadcast data to the RAN node of MBMS-GW is now undertaken by UPF, while SMF is now responsible for session control signaling, such as session start and session stop. The functionality of MCE has been split into various NFs of 5GC.

[0092] Figure 3B Schematic depiction of a Figure 3AThe first architectural reference model for supporting multicast / broadcast in 5G. The application is also called content server.

[0093] Relative to the existing 5GS architecture, enhancements to existing entities and new functional components can be as follows:

[0094] - Enhanced UE, NG-RAN and M-AMF to support MBS.

[0095] -MB-SMF (Multicast / Broadcast Session Management Function) and MB-UPF (Multicast / Broadcast User Plane Function) are new functional components in 5GS, previously referred to as SMF and UPF, respectively, in this document. It should be understood that MB-SMF and / or MB-UPF may be new entities or updated versions of the current SMF and UPF entities.

[0096] -MBSF (Multicast / Broadcast Service Function) is a new network function for handling the signaling part to meet service layer capabilities in both transport-only and full-service modes, previously referred to in this article as BMF-C. It also provides an interface to application servers or content providers in transport-only mode.

[0097] - MBSU (Multicast / Broadcast Service User Plane) is a new entity for processing the payload part to meet the service layer capabilities, previously referred to as BMF-U in this document.

[0098] -NEF is an existing NF.

[0099] – PCF can be enhanced to further elaborate FFS.

[0100] Enhancements to existing and new interfaces can be as follows:

[0101] -Uu interface

[0102] -N2 interface

[0103] -N6 interface

[0104] -MB-N11

[0105] -MB-N3

[0106] -Nx

[0107] -Ny: New (optional) interface between the new MBSF and the MBSU

[0108] -N6mb-C: New interface between MBSF and MB-SMF

[0109] -NxMB-C and NxMB-U: New interfaces between the new MBSF / MBSU and NEF

[0110] The difference between the transport-only and full-service modes of operation is that the MBS services are delivered transparently via the 3GPP network.

[0111] Second Architecture Reference Model

[0112] In the second architecture reference model, no new NFs are introduced, and all functionality is undertaken by existing NFs of the 5G network. In particular, the control plane functionality of BM-SC and MBMS-GW is now supported in SMF, while the user plane functionality of BM-SC and MBMS-GW is undertaken by UPF. PCF may also be updated to account for the policy rules of 5MBS. The functionality of MCE is similar to that of the first and third architecture reference models.

[0113] Third Architecture Reference Model

[0114] Figure 4 Schematically depicting a third architecture reference model for supporting multicast / broadcast in 5G.

[0115] In the third architecture reference model ( Figure 4 ), two additional NFs are introduced to undertake the functionality of MBMS-GW. After the split between the control plane and the user plane in the 5G network, the two new NFs are MBMS-GW-C and MBMS-GW-U. These NFs are in addition to the BMF-C and BMF-U functions introduced in architecture model #1. The MBMS-GW-C functions can be reached through the newly introduced Nmbgw interface, while the MBMS-GW-U functions can be reached via the MBMS-GW-C through the Nxx interface. MBMS-GW-U can also be reached directly by the BMF-U for transmission data from content providers. In this model, the MBMS-GW-C functions are responsible for the control plane functionality of the MBMS-GW in the 4G network (such as session control signaling), while the MBMS-GW-U is responsible for sending multicast / broadcast data to the NG-RAN node.

[0116] The functionality of the MCE is similar to that of the first architecture reference model.

[0117] Figure 5 A flow chart according to an exemplary embodiment is schematically depicted.

[0118] In one embodiment

[0119] A method for switching from a first data transmission mode to a second data transmission mode in a communication network comprising a Next Generation Radio Access Network (NG-RAN) node, a core node and a content provider, wherein the method comprises:

[0120] Sending, by an NG-RAN node, first data from a content provider to a user equipment (UE) in a first session according to a first data transmission mode, wherein the first data transmission mode is a unicast transmission method via separate delivery (S501);

[0121] A decision is made by an NG-RAN node or a core node or a content provider to switch from a first data transmission mode to a second data transmission mode, wherein the second data transmission mode is a multicast transmission mode via shared delivery (S502);

[0122] Initializing, by the core node, a second session for a second data transmission mode (S503);

[0123] Switching from the first data transmission mode to the second data transmission mode by the core node (S504); and

[0124] The NG-RAN node sends second data from the content provider to the UE according to the second data transmission mode in the second session (S505).

[0125] In another embodiment

[0126] The process is a process of switching from a first data transmission method to a second data transmission method in a 5G network, the 5G network including a set of user equipment UEs (including a first UE) communicatively coupled to the 5G network, a set of new generation radio access network (NG-RAN) nodes (including a first NG-RAN node), a 5G core, and a set of content providers (including a first content provider).

[0127] The process includes:

[0128] Sending, by a first NG-RAN node, first data from a content provider set to a first UE according to a first data transmission method in a first session (S501);

[0129] The first UE or the first NG-RAN node or the 5G core or the content server decides to switch from the first data transmission method to the second data transmission method (S502);

[0130] Initializing, by the 5G core, a second session for a second transmission method (S503);

[0131] Switching, by the 5G core, from the first data transmission method to the second data transmission method (S504); and

[0132] The first NG-RAN node sends second data to the first UE from the content provider set according to the second data transmission method in the second session (S505).

[0133] Figure 6 A process according to an exemplary embodiment is schematically depicted.

[0134] The present invention presents a novel mechanism for performing switching of delivery data transmission methods over 5GS. This means that a detailed mechanism involving multiple 5GC NFs is presented so that the UE can switch the unicast transmission method to multicast or broadcast transmission over 5GC (commonly referred to as 5MBS), as well as the situation when the 5MBS transmission method is switched to unicast transmission. The feature of delivery mode switching in cellular networks (i.e. unicast to multicast / broadcast or vice versa) presents significant benefits, as described below. Therefore, switching over 5GC is a highly desirable functionality that requires a set of novel processes based on the current architecture based on 5GS services.

[0135] As an example, when a UE wishes to receive content from an application server (also known as a content provider), a point-to-point connection can be set up. Depending on the number of devices receiving the same content, their respective locations, and other RAN considerations such as air interface resource usage, the content provider and / or network operator may decide to switch the delivery method from multiple point-to-point connections to a single multicast / broadcast connection. Another example is the case where multiple cars have a one-to-one connection with a gNB in ​​a V2X scenario, where an event notification needs to be sent to all vehicles in a specific area. In this case, the current one-to-one connection of the vehicle needs to be switched to broadcast or multicast to ensure that all vehicles in the affected area receive the important notification, thereby ensuring that service continuity is guaranteed. In addition, it is possible that a UE receiving a multicast session moves across NG-RAN nodes, from a gNB that supports 5MBS to a gNB that does not support 5MBS or currently delivers the multicast / broadcast session via a point-to-point connection. In this case, the UE's multicast session needs to be switched to a unicast point-to-point transmission. Other examples of switching scenarios can be found in services such as Industrial Internet of Things (IIoT) or public safety.

[0136] Thus, the above text shows that there may be different triggers to perform a session switch from unicast to multicast / broadcast or vice versa, including service continuity during UE mobility, transmission efficiency depending on the amount of users accessing certain media content, specific requirements of IIoT or public safety, etc. In addition, the switch may be triggered as one or several network entities make such a decision. As described in Section 3.5, the network entities that can trigger the switch are the UE, the radio access network (i.e. NG-RAN for 5G), the 5GC (i.e. one or several NFs that make it up), or an external content / application server. Depending on the triggering entity, a counting step may be required to determine how much traffic is being consumed in the network in any of the delivery methods mentioned above, i.e. unicast, multicast or broadcast. Those reports can also be shared with different entities within the network before the actual session switching mechanism starts.

[0137] In this invention, we provide a solution to support the switching of delivery methods between unicast and multicast / broadcast in 5G networks. Without loss of generality, Figure 6 An exemplary embodiment is depicted in FIG, where we assume that there is no multicast session and the initial connection is a unicast connection. A content provider in collaboration with 5GS announces the available services. A UE interested in receiving the service must register with it. During registration, the network and the content provider perform the necessary checks to ensure that the UE is authorized to receive the service. Once the UE has passed all the necessary checks, the network establishes a point-to-point connection and thereafter sends data in unicast mode. Once the decision to switch has been made, the network creates and establishes a multicast session and then announces the session everywhere in its 5MBS service area. Thereafter, the network notifies the UE that a session switch is required, thereby providing it with all the necessary information for switching to the new session. When switching from unicast to multicast, the UE needs to join the new session. Subsequently, data transmission begins for both the multicast session and the broadcast session. Finally, if the UE moves within the coverage area of ​​a base station that does not provide a multicast session or if the network in collaboration with the content provider decides to switch the multicast session to a unicast session, a new point-to-point connection must be established. The network then notifies the UE of the switch of the delivery method and establishes a point-to-point connection, and requests the UE to switch from the previous multicast session to the newly established unicast session. Data transmission can then begin.Alternatively, if a delivery method switch occurs within a cell that was previously sending data in multicast mode, the network may decide to delete the session for the multicast transmission and any related information.

[0138] An additional aspect of the switching proposal included in some embodiments is slice and session considerations, i.e., whether a new session and / or network slice is required to perform the delivery method switch.

[0139] -Session considerations: When a unicast transmission is switched to a multicast or broadcast (i.e., 5MBS) transmission, if the set of NFs required to deliver the session is the same, the same session may be able to remain active. Therefore, a reference architecture alternative that requires a specific NF to perform 5MBS transmission will have to establish a new session, whereas an architecture alternative without a specific NF for 5MBS can establish a new session or switch a pre-existing session. Additionally, in some embodiments, an MBS session may be used for unicast transmission and may be updated for multicast delivery, or vice versa. In that case, any MBS-dedicated entity may handle both unicast and multicast sessions.

[0140] - Slice considerations: Similarly, when a delivery method switch is performed, the slice carrying the pre-existing session may or may not change in the process. It is important to note that the change of slices can be performed via various slice parameters, i.e., both / either the network slice (identified by the S-NSSAI) and / or the network slice instance (identified by the NSI ID) can play a role in the switching slicing considerations. If the switch is performed without taking slicing considerations into account, both the S-NSSAI and the NSI ID remain unchanged. If they are taken into account, they can change in many possible ways. As stated in [2], it is possible for many network slice instances to be mapped to the same network slice and for one and the same network slice instance to be mapped to a set of network slices. Therefore, when a switch is performed, it is possible for the S-NSSAI to not change while the NSI ID changes and for the S-NSSAI to not change while the NSI ID changes. If the S-NSSAI changes, then both the SST and SD may change, or only the SD changes while the SST remains unchanged.

[0141] In addition, for some embodiments, the above session and slice considerations will also depend on content continuity, i.e., whether the UE continues to receive content from the same application server before and after the handover, and whether the service itself is the same before and after the handover occurs. As a set of examples, the handover mechanism may be different i) if the handover is performed to distribute the same content via multicast in a more efficient manner, ii) if the handover is performed to ensure service continuity due to UE mobility across different NG-RAN nodes that support 5MBS and those that do not, or iii) if the handover occurs because the UE is forced to switch to a public safety service while it is busy with a different unicast type of service.

[0142] Process (method)

[0143] A first aspect provides a process for switching from a first data transmission method to a second data transmission method in a 5G network, the 5G network comprising a set of user equipment UEs (including a first UE) communicatively coupled to the 5G network, a set of next generation radio access network (NG-RAN) nodes (including a first NG-RAN node), a 5G core, and a set of content providers (including a first content provider), wherein the method comprises:

[0144] sending, by the first NG-RAN node, first data from the set of content providers to the first UE in a first session according to a first data transmission method;

[0145] A decision by the first UE or the first NG-RAN node or the 5G core or the content server to switch from the first data transmission method to the second data transmission method;

[0146] Initializing, by the 5 core, a second session for a second transport method;

[0147] Switching, by the 5G core, from the first data transmission method to the second data transmission method; and

[0148] Second data is sent, by the first NG-RAN node, to the first UE from the set of content providers in a second session according to a second data transmission method.

[0149] In one example, the 5G core may be referred to as a core node, the content provider may be referred to as a content server or an application server, and the transmission method may be referred to as a transmission mode. In one example, the process includes performing a registration process by the first UE, for example according to [3].

[0150] In one example, the process includes establishing a first session by the first UE and / or the 5G Core, for example according to [3].

[0151] In one example, the process includes requesting a second session by the UE, the first NG-RAN node, the 5G core and / or the content server to the 5G core, for example to its broadcast multicast service center control / user plane, BMF-C and / or session management function SMF.

[0152] In one example, the process includes discovering the second session by the 5G Core, for example by its BMF-C and / or SMF.

[0153] In one example, the second session includes and / or is the first session, ie, the same session. In one example, the second session and the first session are different sessions.

[0154] In one example, initializing the second session by the 5G core includes creating the second session by the 5G core, for example by its SMF, wherein the second session is a newly created session.

[0155] In one example, initializing, by the 5G core, the second session includes updating, by the 5G core, e.g., by its SMF, the second session, where the second session is a pre-existing session.

[0156] In one example, the process includes configuring, by the 5G Core, e.g., by its BMF-C and / or SMF, a second session management context for a second session.

[0157] In one example, configuring the second session management context by the 5G core includes creating a second session management context by the 5G core, for example by its SMF, wherein the second session management context is a newly created session management context.

[0158] In one example, configuring, by the 5G core, the second session management context includes updating, by the 5G core, for example, by its SMF, the second session management context, where the second session management context is a pre-existing session management context.

[0159] In one example, the process includes registering, by the 5G Core, e.g., by its SMF, the second session.

[0160] In one example, the process includes announcing, by the 5G core, the second session.

[0161] In one example, the process includes sending a message by the 5G Core, for example by its Access and Mobility Function AMF, to the first NG-RAN node.

[0162] In one example, the process includes requesting by the 5G Core, e.g., by the SMF, to its AMF to transfer a message to the first NG-RAN node.

[0163] In one example, the process includes establishing, by the first NG-RAN node, resources associated with the second session.

[0164] In one example, the process includes joining, by the first NG-RAN node, a second session, for example, where the second data transmission method is a multicast broadcast transmission method.

[0165] In one example, the process includes updating, by the 5G core, the second session management context with information from the first NG-RAN node.

[0166] In one example, the process includes releasing, by the first NG-RAN node, resources associated with the first session.

[0167] In one example, the process includes deregistering, by the 5G core, the first session.

[0168] In one example, the first data transmission method is a unicast data transmission method, and wherein the second data transmission method is a multicast transmission method or a broadcast transmission method.

[0169] In one example, the first data transmission method is a multicast data transmission method or a broadcast data transmission method, and wherein the second data transmission method is a unicast transmission method.

[0170] In one example, sending, by the first NG-RAN node, first data from a set of content providers to a first UE in a first session according to a first data transmission method includes sending, by the first NG-RAN node, first data from a first content provider to the first UE in the first session according to the first data transmission method. In one example, sending, by the first NG-RAN node, second data from a set of content providers to the first UE in a second session according to a second data transmission method includes sending, by the first NG-RAN node, second data from the first content provider to the first UE in the second session according to the second data transmission method. In one example, sending, by the first NG-RAN node, first data from a set of content providers to the first UE in a first session according to a first data transmission method includes sending, by the first NG-RAN node, first data from the first content provider to the first UE in the first session according to the first data transmission method, and sending, by the first NG-RAN node, second data from a set of content providers to the first UE in a second session according to the second data transmission method includes sending, by the first NG-RAN node, second data from the first content provider to the first UE in the second session according to the second data transmission method. In one example, the set of content providers includes a second content provider different from the first content provider, and sending, by the first NG-RAN node, second data from the set of content providers to the first UE in the second session according to the second data transmission method includes sending, by the first NG-RAN node, the second data from the second content provider to the first UE in the second session according to the second data transmission method. In one example, the set of content providers includes a second content provider different from the first content provider, sending, by the first NG-RAN node, first data from the set of content providers to the first UE in the first session according to the first data transmission method includes sending, by the first NG-RAN node, the first data from the first content provider to the first UE in the first session according to the first data transmission method, and sending, by the first NG-RAN node, second data from the set of content providers to the first UE in the second session according to the second data transmission method includes sending, by the first NG-RAN node, the second data from the second content provider to the first UE in the second session according to the second data transmission method.

[0171] In one example, a first aspect provides a process of switching from a first data transmission method to a second data transmission method in a 5G network, the 5G network comprising a set of user equipment UEs (including a first UE) communicatively coupled to the 5G network, a set of new generation radio access network (NG-RAN) nodes (including a first NG-RAN node), a 5G core, and a set of content providers (including a first content provider), wherein the process comprises:

[0172] sending, by the first NG-RAN node, first data from the set of content providers to the first UE in a first session according to a first data transmission method, wherein the first data transmission method is a unicast transmission method via separate delivery;

[0173] A decision by a first NG-RAN node or a 5G core or a first content provider to switch from a first data transmission method to a second data transmission method, wherein the second data transmission method is a multicast transmission method via shared delivery;

[0174] Initializing, by the 5G core, a second session for a second transport method;

[0175] Switching, by the 5G core, from the first data transmission method to the second data transmission method; and

[0176] Second data is sent, by the first NG-RAN node, to the first UE from the set of content providers in a second session according to a second data transmission method.

[0177] In one example, the process includes requesting a second session by the first NG-RAN node, the 5G core and / or the first content provider to the 5G core, for example to its multicast / broadcast service function MBSF.

[0178] In one example, the process includes discovering, by the 5G Core, for example by its MBSF, the second session.

[0179] In one example, initializing, by the 5G core, the second session includes updating, by the 5G core, e.g., by its SMF and / or its MB-SMF, the second session, where the second session is a pre-existing session.

[0180] In one example, the process includes configuring, by the 5G Core, e.g., by its MBSF and / or MB-SMF, a second session management context for the second session.

[0181] In one example, the process includes transferring a message by the 5G Core, for example by its AMF, to the first NG-RAN node.

[0182] In one example, the process includes establishing, by the first NG-RAN node, resources associated with the second session.

[0183] In one example, deciding, by the first NG-RAN node or the 5G core or the first content provider, to switch from the first data transmission method to the second transmission method includes deciding, by the first NG-RAN node, to switch from the first data transmission method to the second transmission method.

[0184] In one example, the process includes requesting by the MBSF to the MB-SMF to update the first session of the UE, thereby providing the second session and / or registering by the MB-SMF to the UDM the update from the first session to the second session, and optionally, by the UDM to confirm to the MB-SMF.

[0185] In one example, the process includes exchanging messages by the MBSF and the MBSU and / or includes sending a message by the MB-SMF to the AMF and requesting by the MB-SMF to the AMF to forward the message to the first NG-RAN node, wherein the message includes parameters of the second session.

[0186] In one example, the first data transmission method is an MBS data transmission method, for example, wherein the first session includes and / or is a separate MBS session; and

[0187] The second data transmission method is an MBS data transmission method, for example, the second session includes and / or shares an MBS session.

[0188] In one example, a first aspect provides a process of switching from a first data transmission method to a second data transmission method in a 5G network, the 5G network comprising a set of user equipment UEs (including a first UE) communicatively coupled to the 5G network, a set of new generation radio access network (NG-RAN) nodes (including a first NG-RAN node), a 5G core, and a set of content providers (including a first content provider), wherein the process comprises:

[0189] sending, by the first NG-RAN node, first data from the set of content providers to the first UE in a first session according to a first data transmission method, wherein the first data transmission method is a multicast data transmission method via shared delivery or a broadcast data transmission method;

[0190] A decision by the first NG-RAN node or the 5G core or the first content provider to switch from a first data transmission method to a second data transmission method, wherein the second data transmission method is a unicast transmission method via separate delivery;

[0191] Initializing, by the 5G core, a second session for a second transport method;

[0192] Switching, by the 5G core, from the first data transmission method to the second data transmission method; and

[0193] Second data is sent, by the first NG-RAN node, to the first UE from the set of content providers in a second session according to a second data transmission method.

[0194] In one example, the process includes requesting a second session by the first NG-RAN node, the 5G core and / or the first content provider to the 5G core, for example to its multicast / broadcast service function MBSF.

[0195] In one example, the process includes discovering, by the 5G Core, for example by its MBSF, the second session.

[0196] In one example, initializing, by the 5G core, the second session includes updating, by the 5G core, for example by its SMF and / or MB-SMF, the second session, where the second session is a pre-existing session.

[0197] In one example, the process includes configuring, by the 5G Core, e.g., by its MBSF and / or MB-SMF, a second session management context for a second session.

[0198] In one example, the process includes transferring a message by the 5G Core, for example by its AMF, to the first NG-RAN node.

[0199] In one example, the process includes establishing, by the first NG-RAN node, resources associated with the second session.

[0200] In one example, deciding, by the first NG-RAN node or the 5G core or the first content provider, to switch from the first data transmission method to the second transmission method includes deciding, by the first NG-RAN node, to switch from the first data transmission method to the second transmission method.

[0201] In one example, the process includes requesting by the MBSF to the MB-SMF to update the first session of the UE, thereby providing the second session and / or registering by the MB-SMF to the UDM the update from the first session to the second session, and optionally, by the UDM to confirm to the MB-SMF.

[0202] In one example, the process includes exchanging messages by the MBSF and the MBSU and / or includes sending a message by the MB-SMF to the AMF and requesting by the MB-SMF to the AMF to forward the message to the first NG-RAN node, wherein the message includes parameters of the second session.

[0203] In one example, the first data transmission method is an MBS data transmission method, for example, wherein the first session includes and / or is a shared MBS session, such as a pre-existing shared MBS session; and wherein the second data transmission method is an MBS data transmission method, for example, wherein the second session includes and / or is a separate MBS session.

[0204] In one example, the process includes suspending and / or releasing the first session, for example by the 5GC, if the number of UEs included in the first session is less than a threshold number, for example, if no UE is included in the first session.

[0205] In one example, the process includes requesting, by the MBSF, to the MB-SMF to suspend the first session.

[0206] In one example, the process includes requesting, by the MB-SMF, to the AMF to release the first session and / or delete related resources.

[0207] The network may be as described with respect to the second aspect.

[0208] 5G network (communication network)

[0209] A second aspect provides a 5G network for switching from a first data transmission method to a second data transmission, comprising a set of user equipment UEs (including a first UE) communicatively coupled to the 5G network, a set of new generation radio access network (NG-RAN) nodes (including a first NG-RAN node), a 5G core, and a set of content providers (including a first content provider);

[0210] wherein the first NG-RAN node is configured to send first data from the set of content providers to the first UE according to the first data transmission method in the first session;

[0211] wherein the first UE or the first NG-RAN node or the 5G core or the content server is configured to decide to switch from the first data transmission method to the second data transmission method;

[0212] wherein the 5G core is configured to initialize a second session for a second transmission method;

[0213] wherein the 5G core is configured to switch from a first data transmission method to a second data transmission method; and

[0214] The first NG-RAN node is configured to send second data from the content provider set to the first UE according to the second data transmission method in the second session.

[0215] It should be understood that the content provider (also referred to as content server or application server) set is communicatively coupled to the 5G network (communication network) and can be considered as a separate or integral part thereof.

[0216] The 5G network may be configured to implement any process according to the first aspect.

[0217] In one example, the 5G network includes M-AMF, MB-SMF, MB-UBF, MBSF, MBSU and / or NEF. In one example, the M-AMF is, for example, bidirectionally communicatively coupled to the NG-RAN and / or MB-SMF. In one example, the MB-SMF is, for example, bidirectionally communicatively coupled to the M-AMF, MB-UPF and / or MBSF. In one example, the MBSF is, for example, bidirectionally communicatively coupled to the MB-SMF, MBSU, NEF and / or a content server. In one example, the MBSU is, for example, bidirectionally communicatively coupled to the MB-UPF, MBSF and / or a content server. In one example, the MB-UPF is, for example, bidirectionally communicatively coupled to the NG-RAN, MB-SMF and / or MBSU.

[0218] In one example, the 5G core includes AMF, SMF and / or BMF-C. In one example, the 5G core includes AMF, SMF and BMF-C.

[0219] In one example, the 5G core includes NSSF, AUSF, NEF, NRF, AMF, PCF, SMF, UPF, DN, UDM, BMF-C, BMF-U and / or AF. In one example, the 5G core includes NSSF, AUSF, NEF, NRF, AMF, PCF, SMF, UPF, DN, UDM, BMF-C, BMF-U and AF.

[0220] In one example, the 5G core includes NSSF, AUSF, NEF, NRF, AMF, PCF, SMF, UPF, DN, UDM, BMF-C, BMF-U, AF, MBMS-GW-C and / or MBMS-GW-U. In one example, the 5G core includes NSSF, AUSF, NEF, NRF, AMF, PCF, SMF, UPF, DN, UDM, BMF-C, BMF-U, AF, MBMS-GW-C and MBMS-GW-U.

[0221] In one example, the set of content providers includes a second content provider, eg, different from the first content provider.

[0222] In one example, a second aspect provides a 5G network for switching from a first data transmission method to a second data transmission, comprising a set of user equipment UEs (including a first UE) communicatively coupled to the 5G network, a set of new generation radio access network (NG-RAN) nodes (including a first NG-RAN node), a 5G core, and a set of content providers (including a first content provider);

[0223] wherein the first NG-RAN node is configured to send first data from the set of content providers to the first UE according to a first data transmission method in a first session, wherein the first data transmission method is a unicast transmission method via separate delivery;

[0224] wherein the first NG-RAN node or the 5G core or the content server is configured to decide to switch from the first data transmission method to the second data transmission method;

[0225] wherein the 5G core is configured to initialize a second session for a second transmission method, wherein the second data transmission method is a multicast transmission method via shared delivery;

[0226] wherein the 5G core is configured to switch from a first data transmission method to a second data transmission method; and

[0227] The first NG-RAN node is configured to send second data from the content provider set to the first UE according to the second data transmission method in the second session.

[0228] In one example, a second aspect provides a 5G network for switching from a first data transmission method to a second data transmission, comprising a set of user equipment UEs (including a first UE) communicatively coupled to the 5G network, a set of new generation radio access network (NG-RAN) nodes (including a first NG-RAN node), a 5G core, and a set of content providers (including a first content provider);

[0229] wherein the first NG-RAN node is configured to send first data from the set of content providers to the first UE according to a first data transmission method in a first session, wherein the first data transmission method is a multicast data transmission method via shared delivery or a broadcast data transmission method;

[0230] wherein the first NG-RAN node or the 5G core or the content server is configured to decide to switch from the first data transmission method to the second data transmission method, wherein the second data transmission method is a unicast transmission method via separate delivery;

[0231] wherein the 5G core is configured to initialize a second session for a second transmission method;

[0232] wherein the 5G core is configured to switch from a first data transmission method to a second data transmission method; and

[0233] The first NG-RAN node is configured to send second data from the content provider set to the first UE according to the second data transmission method in the second session.

[0234] In one example, a third aspect provides a method for switching from a first data transmission mode to a second data transmission mode in a communication network including a new generation radio access network (NG-RAN) node, a core node, and a content provider, wherein the method includes:

[0235] sending, by the NG-RAN node, first data from a content provider to a user equipment (UE) in a first session according to a first data transmission mode, wherein the first data transmission mode is a unicast transmission method via separate delivery;

[0236] A decision by the NG-RAN node or the core node or the content provider to switch from the first data transmission mode to the second data transmission mode, wherein the second data transmission mode is a multicast transmission mode via shared delivery;

[0237] Initializing, by the core node, a second session for a second data transmission mode;

[0238] Switching, by the core node, from the first data transmission mode to the second data transmission mode; and

[0239] The NG-RAN node sends second data from the content provider to the UE in the second session according to the second data transmission mode.

[0240] In one example, the method includes at least one of the following:

[0241] The NG-RAN node, the core node and / or the content provider requests the second session from the core node, for example, from its multicast / broadcast service function (MBSF);

[0242] The core node discovers the second session, for example, through its MBSF;

[0243] configuring, by the core node, for example, by its MBSF and / or multicast / broadcast session management function (MB-SMF), a second session management context for the second session;

[0244] Transfer of messages by a core node, such as its Access and Mobility Function (AMF), to a NG-RAN node; and

[0245] Resources associated with the second session are established by the NG-RAN node.

[0246] In one example, wherein initializing the second session by the core node includes updating the second session by the core node, for example by its SMF and / or MB-SMF, wherein the second session is a pre-existing session.

[0247] In one example, the method includes at least one of the following:

[0248] The MBSF of the core node requests the MB-SMF of the core node to update the first session of the UE, thereby providing the second session and / or the MB-SMF registers the update from the first session to the unified data management (UDM) of the core node, and alternatively, the UDM confirms to the MB-SMF.

[0249] In one example, the method includes at least one of the following:

[0250] Messages exchanged by the MBSF and the Multicast / Broadcast Service User Plane (MBSU) of the core node; and / or

[0251] The MB-SMF of the core node sends a message to the AMF of the core node and the MB-SMF of the core node requests the AMF of the core node to forward the message to the NG-RAN node, wherein the message includes parameters of the second session.

[0252] In one example, wherein the first data transmission mode is an MBS data transmission mode, for example wherein the first session comprises a separate MBS session; and

[0253] The second data transmission mode is an MBS data transmission mode, for example, wherein the second session includes a shared MBS session.

[0254] In one example, a fourth aspect provides an apparatus for switching from a first data transmission mode to a second data transmission mode in a communication network, the apparatus comprising a new generation radio access network (NG-RAN) node, a core node, and a content provider,

[0255] wherein the NG-RAN node is configured to send first data from a content provider to a user equipment (UE) in a first session according to a first data transmission mode, wherein the first data transmission mode is a unicast transmission mode via separate delivery;

[0256] wherein the NG-RAN node or the core node or the content provider is configured to decide to switch from the first data transmission mode to the second data transmission mode;

[0257] wherein the core node is configured to initialize a second session for a second data transmission mode, wherein the second data transmission mode is a multicast transmission mode via shared delivery;

[0258] wherein the core node is configured to switch from a first data transmission mode to a second data transmission mode; and

[0259] The NG-RAN node is configured to send second data from the content provider to the UE according to the second data transmission mode in the second session.

[0260] In one example, a fifth aspect provides a method for switching from a first data transmission mode to a second data transmission mode in a communication network including a new generation radio access network (NG-RAN) node, a core node, and a content provider, wherein the method includes:

[0261] Sending, by the NG-RAN node, first data from a content provider to a user equipment UE in a first session according to a first data transmission mode, wherein the first data transmission mode is a multicast data transmission mode via shared delivery or a broadcast data transmission mode;

[0262] A decision by the NG-RAN node or the core node or the content provider to switch from a first data transmission mode to a second data transmission mode, wherein the second data transmission mode is a unicast transmission mode via separate delivery;

[0263] Initializing, by the core node, a second session for a second data transmission mode;

[0264] Switching, by the core node, from the first data transmission mode to the second data transmission mode; and

[0265] The NG-RAN node sends second data from the content provider to the UE in the second session according to the second data transmission mode.

[0266] In one example, the method includes at least one of the following:

[0267] The NG-RAN node, the core node and / or the content provider requests the second session from the core node, for example, from its multicast / broadcast service function (MBSF);

[0268] The core node discovers the second session, for example, through its MBSF;

[0269] configuring, by the core node, for example, by its MBSF and / or multicast / broadcast session management function (MB-SMF), a second session management context for the second session;

[0270] Transfer of messages by a core node, such as its Access and Mobility Function (AMF), to a NG-RAN node; and

[0271] Resources associated with the second session are established by the NG-RAN node.

[0272] In one example, initializing the second session by the core node includes updating the second session by the core node, for example, by its SMF and / or MB-SMF, wherein the second session is a pre-existing session.

[0273] In one example, the method includes at least one of the following:

[0274] The MBSF of the core node requests the MB-SMF of the core node to update the first session of the UE, thereby providing the second session and / or the MB-SMF registers the update from the first session to the unified data management (UDM) of the core node, and alternatively, the UDM confirms to the MB-SMF.

[0275] In one example, the method includes at least one of the following:

[0276] The MBSF of the core node and the Multicast / Broadcast Service User Plane (MBSU) of the core node exchange messages, and / or

[0277] The MB-SMF of the core node sends a message to the AMF of the core node and the MB-SMF of the core node requests the AMF of the core node to forward the message to the NG-RAN node, wherein the message includes parameters of the second session.

[0278] In one example, wherein the first data transmission mode is an MBS data transmission mode, for example wherein the first session comprises a shared MBS session, such as a pre-existing shared MBS session; and

[0279] The second data transmission mode is an MBS data transmission mode, for example, wherein the second session includes a separate MBS session.

[0280] In one example, the method includes at least one of the following:

[0281] If the number of UEs included in the first session is less than a threshold number, for example, if no UE is included in the first session, suspending and / or releasing the first session by the core node;

[0282] The MBSF of the core node requests the MB-SMF of the core node to suspend the first session; and

[0283] The MB-SMF of the core node requests the AMF of the core node to release the first session and / or delete related resources.

[0284] In one example, a sixth aspect provides an apparatus for switching from a first data transmission mode to a second data transmission mode in a communication network, the apparatus comprising a new generation radio access network (NG-RAN) node, a core node, and a content provider,

[0285] wherein the NG-RAN node is configured to send first data from a content provider to a user equipment (UE) in a first session according to a first data transmission mode, wherein the first data transmission mode is a multicast data transmission mode via shared delivery or a broadcast data transmission mode,

[0286] wherein the NG-RAN node or the core node or the content provider is configured to decide to switch from the first data transmission mode to the second data transmission mode, wherein the second data transmission mode is a unicast transmission mode via separate delivery,

[0287] wherein the core node is configured to initialize a second session for a second data transmission mode,

[0288] wherein the core node is configured to switch from a first data transmission mode to a second data transmission mode, and

[0289] The NG-RAN node is configured to send second data from the content provider to the UE according to the second data transmission mode in the second session.

[0290] Example

[0291] This section presents different solutions for supporting delivery method switching (unicast to multicast / broadcast, multicast / broadcast to unicast) in 5G networks. Since the final architecture model for 5G networks is still not defined, we present solutions for the most prominent architecture reference models. For each model, we present examples for switching the delivery method from unicast to multicast / broadcast and from multicast / broadcast to unicast. In addition, we also consider separately whether the session has a pre-existing delivery method switch.

[0292] Solutions for the First Architecture Reference Model

[0293] This embodiment is related to the first architecture reference model in which BMF-C and BMF-U additional network functions are considered. When switching the delivery method from unicast to multicast or broadcast, two different solutions are presented depending on whether a session pre-exists. When the delivery method is switched from multicast / broadcast to unicast, we present a single solution because a new session has to be established as long as the UE to be switched is not the last UE in the 5MBS group.

[0294] Example 1.1 Unicast to Multicast / Broadcast Delivery Method Switching Without Pre-Existing Sessions

[0295] In this example, there is neither a multicast session nor any session management context for the service, so once the delivery method switch is triggered, a new session (ie, the second session) and session management context must be created.

[0296] In one example, the process includes registering, by a UE (i.e., a first UE) with the 5GS, for example, by performing a registration process according to [3].

[0297] In one example, the process includes establishing a unicast PDU session by the UE and the 5G Core, for example according to [3].

[0298] In one example, the process includes sending a unicast transmission (ie, a first data transmission method) by a content server (ie, a set of content providers). In one example, the process includes starting a unicast transmission by a content server.

[0299] In one example, the process includes sending, by the UE, a consumption report on each unicast PDU session to the network. In one example, the process includes periodically sending, by the UE, a consumption report on each unicast PDU session to the network. These reports may be used later by the network to trigger a delivery method switch. Since this step is optional, a delivery method switch may be triggered based on other criteria.

[0300] In one example, the process includes deciding by the UE or NG-RAN or 5G core or content server to switch the delivery method from, for example, a unicast session and / or multiple unicast sessions (i.e., a first session) to a groupcast / broadcast session (i.e., a second session), such as a single multicast / broadcast session.

[0301] In one example, the process includes requesting a new session (i.e., a second session) from the BMF-C by the UE or NG-RAN or 5G core or content server. In one example, both the step of deciding and the step of requesting are performed by the UE or NG-RAN or 5G core or content server (i.e., by the same entity). In one example, the process includes requesting a new session from the BMF-C by the content server, for example, in the case where it is the content server that decides on the delivery method switching.

[0302] In one example, the process includes discovering by the BMF-C the downlink network functions that will be involved in the new session. The execution of this step depends on different conditions.

[0303] The following non-exhaustive list includes some of the situations where NF discovery is needed:

[0304] a. The UE is the first UE to switch the delivery method from unicast to multicast, i.e. a new session and session management context needs to be created.

[0305] b. The UE moves from a cell delivering content in unicast mode to a cell supporting 5MBS where there is no ongoing multicast session.

[0306] The following non-exhaustive list includes some situations where NF discovery is not needed:

[0307] a. The UE moves from a cell delivering content in unicast mode to a cell supporting 5MBS where there is an ongoing multicast session.

[0308] b. The previous multicast session exists in an inactive state and can be reused

[0309] In one example, the process includes requesting by the BMF-C to create a new session by the SMF. In one example, requesting to create a new session includes providing the parameters required for the new session by the BMF-C. In one example, the process includes responding by the SMF to confirm the creation of the new session. In one example, the response includes providing its multicast IP address and port number by the SMF.

[0310] In one example, the process includes sending a message, such as a Nsmf_PDUSession_CreateSMContext message, to the SMF by the BMF-C to request the creation of a new session management context. In one example, the process includes confirming the successful creation of the new session management context by the SMF, such as by including a Nsmf_PDUSession_CreateSMContext response message by the SMF.

[0311] In one example, the process includes registering, by the SMF, the multicast session with the UDM.

[0312] In one example, the process includes announcing the new session to the network. In one example, the announcement includes providing information such as a multicast IP address and / or a port number.

[0313] In one example, the process includes requesting, by the SMF, to transfer a message to the AMF to the NG-RAN node. In one example, the request includes sending a message by the SMF to the AMF and requesting, by the SMF to the AMF, to transfer the message to the NG-RAN node. In one example, the message includes and / or is a Namf_Communication_N1N2MessageTransfer message.

[0314] In one example, the process includes sending a session creation request by the AMF to the NG-RAN, for example via an N2_PDU Session Request message. In one example, the process includes confirming the session creation by the NG-RAN node, for example with an N2_PDU Session Response message.

[0315] In one example, the process includes establishing, by the NG-RAN, resources, such as required resources, for the new session.

[0316] In one example, for example, the process includes, if the session is switched to multicast, then the NG-RAN node joins the relevant multicast group of the NG-RAN node. Otherwise, if the delivery method is switched to broadcast, such joining may not be required.

[0317] In one example, the process includes sending, by the AMF, to the SMF, a request to update the multicast session context, for example, with information from the NG-RAN, such as an Nsmf_PDUSession_UpdateSMContext request. In one example, the process includes confirming, by the SMF, receipt of the request, for example, with an Nsmf_PDUSession_UpdateSMContext response message.

[0318] In one example, the process includes requesting, by the SMF, to the BMF-C to update the multicast session context with information from the NG-RAN according to a received request, such as an Nbmf_PDUSession_UpdatePDUContext request. In one example, the process includes confirming, by the BMF-C, the context update, such as with an Nbmf_PDUSession_UpdatePDUContext response.

[0319] In one example, the process includes, for example, starting a multicast transmission using a multicast session and bearer. In one example, the process includes initially sending content (i.e., data) to the BMF-U by a content provider in unicast mode and forwarding the content to the UPF by the BMF-U, for example, in the same manner. In one example, the process includes processing the forwarded content (i.e., received data) by the UPF, for example, by applying FEC and / or raptor codes, and sending the processed content to the NG-RAN node, for example, using IP multicast. In one example, the process includes multicasting / broadcasting the processed content by the NG-RAN node using a point-to-multipoint radio bearer.

[0320] Example 1.2 Unicast to Multicast / Broadcast Delivery Method Switching with Pre-Existing Sessions

[0321] In this example, both the multicast session and the session management context for the service exist, so once a delivery method switch is triggered, there is no need to create a new session or session management context.

[0322] In one example, the process includes registering the UE with the 5GS, for example by performing a registration process according to [3].

[0323] In one example, the process includes establishing a unicast PDU session by the UE and the 5G Core, for example according to [3].

[0324] In one example, the process includes sending, by a content server, a unicast transmission. In one example, the process includes initiating, by a content server, a unicast transmission.

[0325] In one example, the process includes sending, by the UE, a consumption report on each unicast PDU session to the network. In one example, the process includes periodically sending, by the UE, a consumption report on each unicast PDU session to the network. These reports may be used later by the network to trigger a delivery method switch. Since this step is optional, a delivery method switch may be triggered based on other criteria.

[0326] In one example, the process includes deciding by the UE or NG-RAN or 5G Core or content server to switch the delivery method from, for example, a unicast session and / or multiple unicast sessions to a groupcast / broadcast session, for example, a single multicast / broadcast session.

[0327] In one example, the process includes requesting a new session from the BMF-C by the UE or NG-RAN or 5G core or content server. In one example, both the step of deciding and the step of requesting are performed by the UE or NG-RAN or 5G core or content server. In one example, the process includes requesting a new session from the BMF-C by the content server, for example, in the case where it is the content server that decides on the delivery method switching.

[0328] In one example, the process includes requesting by the BMF-C to the SMF to update the session, for example, wherein the request includes providing required parameters. In one example, the process includes responding by the SMF to confirm the modification of the session.

[0329] In one example, the process includes requesting, by the BMF-C, to the SMF to update a session management context associated with an existing multicast session.

[0330] In one example, the process includes registering, by the SMF, updates (ie, modifications) of the multicast session with the UDM.

[0331] In one example, the process includes advertising the updated session to the network, including, for example, providing information such as a multicast IP address and port number.

[0332] In one example, the process includes requesting, by the SMF, to transfer a message to the AMF to the NG-RAN node. In one example, the request includes sending a message by the SMF to the AMF and requesting, by the SMF to the AMF, to transfer the message to the NG-RAN node. In one example, the message includes and / or is a Namf_Communication_N1N2MessageTransfer message.

[0333] In one example, the process includes sending a session creation request by the AMF to the NG-RAN, for example via an N2_PDU Session Request message. In one example, the process includes confirming the session creation by the NG-RAN node, for example with an N2_PDU Session Response message.

[0334] In one example, the process includes establishing, by the NG-RAN, resources, such as required resources, for the new session.

[0335] In one example, for example, the process includes joining the relevant multicast session by the NG-RAN node if the session is switched to multicast. Otherwise, if the delivery method is switched to broadcast, such joining may not be required.

[0336] In one example, the process includes sending, by the AMF, to the SMF, a request to update the multicast session context, for example, with information from the NG-RAN, such as an Nsmf_PDUSession_UpdateSMContext request. In one example, the process includes confirming, by the SMF, receipt of the request, for example, with an Nsmf_PDUSession_UpdateSMContext response message.

[0337] In one example, the process includes requesting, by the SMF, to the BMF-C to update the multicast session context with information from the NG-RAN according to a received request, such as an Nbmf_PDUSession_UpdatePDUContext request. In one example, the process includes confirming, by the BMF-C, the context update, such as with an Nbmf_PDUSession_UpdatePDUContext response.

[0338] In one example, the process includes, for example, starting a multicast transmission using a multicast session and bearer. In one example, the process includes initially sending content (i.e., data) to the BMF-U by a content provider in unicast mode and forwarding the content to the UPF by the BMF-U, for example, in the same manner. In one example, the process includes processing the forwarded content (i.e., received data) by the UPF, for example, by applying FEC and / or Athlon codes, and sending the processed content to the NG-RAN node, for example, using IP multicast. In one example, the process includes multicasting / broadcasting the processed content by the NG-RAN node using a point-to-multipoint radio bearer.

[0339] Example 1.3 Multicast / Broadcast to Unicast Delivery Method Switching

[0340] In this example, the UE has already registered with the network and an active multicast session already exists. In addition, the UE for which the session handover is performed is not the last UE in the 5MBS group to receive the multicast context, so a new unicast session must be established.

[0341] A multicast / broadcast session is in progress.

[0342] In one example, the process includes a decision by the UE or NG-RAN or 5G core or content server to switch, for example, a multicast / broadcast session of the UE to a unicast session.

[0343] In one example, the process includes requesting a new session from the BMF-C by the UE or NG-RAN or 5G core or content server. In one example, both the step of deciding and the step of requesting are performed by the UE or NG-RAN or 5G core or content server. In one example, the process includes requesting a new session from the BMF-C by the content server, for example, in the case where it is the content server that decides on the delivery method switching.

[0344] In one example, the process includes performing NF discovery by the network for the new session.

[0345] In one example, the process includes requesting, by the BMF-C, to the SMF to create a new PDU session.

[0346] In one example, the process includes requesting, by the BMF-C, to the SMF to create a new session management context.

[0347] In one example, the process includes requesting, by the SMF, to the UDM to register a new session.

[0348] In one example, the process includes requesting, by the SMF, to transfer a message to the AMF to the NG-RAN node. In one example, the request includes sending a message by the SMF to the AMF and requesting, by the SMF to the AMF, to transfer the message to the NG-RAN node. In one example, the message includes and / or is a Namf_Communication_N1N2MessageTransfer message.

[0349] In one example, the process includes sending a session creation request by the AMF to the NG-RAN, for example via an N2_PDU Session Request message. In one example, the process includes confirming the session creation by the NG-RAN node, for example with an N2_PDU Session Response message.

[0350] In one example, the process includes establishing, by the NG-RAN, resources for the new session, e.g., required unicast resources such as point-to-multipoint radio bearers.

[0351] In one example, the process includes sending, by the AMF, to the SMF, a request to update the unicast session context, for example, with information from the NG-RAN, such as an Nsmf_PDUSession_UpdateSMContext request. In one example, the process includes confirming, by the SMF, receipt of the request, for example, with an Nsmf_PDUSession_UpdateSMContext response message.

[0352] In one example, the process includes requesting, by the SMF, to the BMF-C to update the unicast session context with information from the NG-RAN according to a received request, such as an Nbmf_PDUSession_UpdatePDUContext request. In one example, the process includes confirming, by the BMF-C, the context update, such as with an Nbmf_PDUSession_UpdatePDUContext response.

[0353] In one example, the process includes, for example, starting a unicast transmission using a multicast session and bearer. In one example, the process includes initially sending content (i.e., data) by a content provider to the BMF-U and forwarding the content to the UPF by the BMF-U, for example, in the same manner. In one example, the process includes processing the forwarded content (i.e., received data) by the UPF, for example, by applying FEC and / or Athlon codes, and sending the processed content to the NG-RAN node. In one example, the process includes sending the processed content by the NG-RAN node using a point-to-multipoint radio bearer.

[0354] In one example, the process includes releasing the multicast resources by the NG-RAN node if the handed over UE is the last UE in the 5MBS group, as the multicast resources are no longer needed.

[0355] In one example, the process includes deregistering, releasing and / or deleting the multicast session by the network if the handed-off UE is the last UE in the 5MBS group.

[0356] Solutions for the Second Architecture Reference Model

[0357] Example 2 is related to the second architecture reference model in which no additional network functions are considered. Similar to Example 1, when the delivery method is switched from unicast to multicast or broadcast, two different solutions are presented depending on whether a session pre-exists (Examples 2.1 and 2.2). When the delivery method is switched from multicast / broadcast to unicast, a single solution is presented (Example 2.3) because a new session must be established as long as the UE to be switched is not the last UE in the 5MBS group.

[0358] Example 2.1 Unicast to Multicast / Broadcast Delivery Method Switching Without Pre-Existing Session

[0359] In this embodiment, there is neither a multicast session nor any session management context for the service, so once a delivery method switch is triggered, a new session and session management context must be created.

[0360] In one example, the process includes registering the UE with the 5GS, for example by performing a registration process according to [3].

[0361] In one example, the process includes establishing a unicast PDU session by the UE and the 5G Core, for example according to [3].

[0362] In one example, the process includes sending, by a content server, a unicast transmission. In one example, the process includes initiating, by a content server, a unicast transmission.

[0363] In one example, the process includes sending, by the UE, a consumption report on each unicast PDU session to the network. In one example, the process includes periodically sending, by the UE, a consumption report on each unicast PDU session to the network. These reports may be used later by the network to trigger a delivery method switch. Since this step is optional, a delivery method switch may be triggered based on other criteria.

[0364] In one example, the process includes deciding by the UE or NG-RAN or 5G Core or content server to switch the delivery method from, for example, a unicast session and / or multiple unicast sessions to a groupcast / broadcast session, for example, a single multicast / broadcast session.

[0365] In one example, the process includes requesting, by the content server, a new session to the SMF.

[0366] In one example, the process includes discovering by the SMF the downstream network functions that will be involved in the new session. The execution of this step depends on different conditions.

[0367] The following non-exhaustive list includes some of the situations where NF discovery is needed:

[0368] a. The UE is the first UE to switch the delivery method from unicast to multicast, i.e. a new session and session management context needs to be created.

[0369] b. The UE moves from a cell delivering content in unicast mode to a cell supporting 5MBS where there is no ongoing multicast session.

[0370] The following non-exhaustive list includes some situations where NF discovery is not needed:

[0371] a. The UE moves from a cell delivering content in unicast mode to a cell supporting 5MBS where there is an ongoing multicast session.

[0372] b. The previous multicast session exists in an inactive state and can be reused.

[0373] In one example, the process includes creating a new session by SMF based on parameters required for the new session. In one example, creating includes allocating a multicast IP address and / or a port number for the new session by SMF.

[0374] In one example, the process includes creating a new SM context by the SMF. In one example, the process includes updating an existing SM context by the SMF when applicable.

[0375] In one example, the process includes registering, by the SMF, a new multicast session with the UDM.

[0376] In one example, the process includes announcing the new session to the network. In one example, the announcement includes providing information such as a multicast IP address and / or a port number.

[0377] In one example, the process includes requesting, by the SMF, to transfer a message to the AMF to the NG-RAN node. In one example, the request includes sending a message by the SMF to the AMF and requesting, by the SMF to the AMF, to transfer the message to the NG-RAN node. In one example, the message includes and / or is a Namf_Communication_N1N2MessageTransfer message.

[0378] In one example, the process includes sending a session creation request by the AMF to the NG-RAN, for example via an N2_PDU Session Request message. In one example, the process includes confirming the session creation by the NG-RAN node, for example with an N2_PDU Session Response message.

[0379] In one example, the process includes establishing, by the NG-RAN, resources, such as required resources, for the new session.

[0380] In one example, for example, the process includes, if the session is switched to multicast, then the NG-RAN node joins the relevant multicast group of the NG-RAN node. Otherwise, if the delivery method is switched to broadcast, such joining may not be required.

[0381] In one example, the process includes sending, by the AMF, to the SMF, a request to update the multicast session context, for example, with information from the NG-RAN, such as an Nsmf_PDUSession_UpdateSMContext request. In one example, the process includes confirming, by the SMF, receipt of the request, for example, with an Nsmf_PDUSession_UpdateSMContext response message.

[0382] In one example, the process includes updating, by the SMF, the multicast session context with information from the NG-RAN.

[0383] In one example, the process includes starting a multicast transmission using a multicast session and bearer. In one example, the process includes initially sending content (i.e., data) from a content provider to the UPF in unicast mode. In one example, the process includes processing the forwarded content (i.e., received data) by the UPF, for example by applying FEC and / or Athlon codes, and sending the processed content to the NG-RAN node, for example, using IP multicast. In one example, the process includes multicasting / broadcasting the processed content by the NG-RAN node using a point-to-multipoint radio bearer.

[0384] Example 2.2 Unicast to Multicast / Broadcast Delivery Method Switching with Pre-Existing Sessions

[0385] In this embodiment, both the multicast session and the session management context for the service exist, so once a delivery method switch is triggered, there is no need to create a new session or session management context.

[0386] In one example, the process includes registering the UE with the 5GS, for example by performing a registration process according to [3].

[0387] In one example, the process includes establishing a unicast PDU session by the UE and the 5G Core, for example according to [3].

[0388] In one example, the process includes sending, by a content server, a unicast transmission. In one example, the process includes initiating, by a content server, a unicast transmission.

[0389] In one example, the process includes sending, by the UE, a consumption report on each unicast PDU session to the network. In one example, the process includes periodically sending, by the UE, a consumption report on each unicast PDU session to the network. These reports may be used later by the network to trigger a delivery method switch. Since this step is optional, a delivery method switch may be triggered based on other criteria.

[0390] In one example, the process includes deciding by the UE or NG-RAN or 5G Core or content server to switch the delivery method from, for example, a unicast session and / or multiple unicast sessions to a groupcast / broadcast session, for example, a single multicast / broadcast session.

[0391] In one example, the process includes requesting a new session by the content server to the SMF.

[0392] In one example, the process includes updating, by the SMF, a pre-existing session based on the desired parameters.

[0393] In one example, the process includes creating a new SM context by the SMF. In one example, the process includes updating an existing SM context by the SMF when applicable.

[0394] In one example, the process includes registering, by the SMF, the modification of the multicast session with the UDM.

[0395] In one example, the process includes announcing the new session and / or updated session to the network. In one example, the announcement includes providing information such as a multicast IP address and / or a port number.

[0396] In one example, the process includes requesting, by the SMF, to transfer a message to the AMF to the NG-RAN node. In one example, the request includes sending a message by the SMF to the AMF and requesting, by the SMF to the AMF, to transfer the message to the NG-RAN node. In one example, the message includes and / or is a Namf_Communication_N1N2MessageTransfer message.

[0397] In one example, the process includes sending a session creation request by the AMF to the NG-RAN, for example via an N2_PDU Session Request message. In one example, the process includes confirming the session creation by the NG-RAN node, for example with an N2_PDU Session Response message.

[0398] In one example, the process includes establishing, by the NG-RAN, resources, such as required resources, for the new session.

[0399] In one example, for example, the process includes the NG-RAN node joining the relevant multicast group of the NG-RAN node if the session is switched to multicast. Otherwise, if the delivery method is switched to broadcast, such joining may not be required.

[0400] In one example, the process includes sending, by the AMF, to the SMF, a request to update the multicast session context, for example, with information from the NG-RAN, such as an Nsmf_PDUSession_UpdateSMContext request. In one example, the process includes confirming, by the SMF, receipt of the request, for example, with an Nsmf_PDUSession_UpdateSMContext response message.

[0401] In one example, the process includes updating, by the SMF, the multicast session context with information from the NG-RAN.

[0402] In one example, the process includes, for example, starting a multicast transmission using a multicast session and bearer. In one example, the process includes initially sending content (i.e., data) to the UPF by a content provider in unicast mode. In one example, the process includes processing the forwarded content (i.e., received data) by the UPF, for example, by applying FEC and / or Athlon codes, and sending the processed content to the NG-RAN node, for example, using IP multicast. In one example, the process includes multicasting / broadcasting the processed content by the NG-RAN node using a point-to-multipoint radio bearer.

[0403] Example 2.3 Multicast / Broadcast to Unicast Delivery Method Switching

[0404] In this example, the UE has already registered with the network and an active multicast session already exists. In addition, the UE for which the session handover is performed is not the last UE in the 5MBS group to receive the multicast context, so a new unicast session must be established.

[0405] A multicast / broadcast session is in progress.

[0406] In one example, the process includes a decision by the UE or NG-RAN or 5G core or content server to switch, for example, a multicast / broadcast session of the UE to a unicast session.

[0407] In one example, the process includes requesting a new session by the UE or NG-RAN or 5G core or content server to the SMF. In one example, both the step of deciding and the step of requesting are performed by the UE or NG-RAN or 5G core or content server. In one example, the process includes requesting a new session by the content server to the SMF, for example, in the case where it is the content server that decides on the delivery method switch.

[0408] In one example, the process includes performing NF discovery by the network for the new session.

[0409] In one example, the process includes creating a new PDU session by the SMF.

[0410] In one example, the process includes creating a new session management context by the SMF.

[0411] In one example, the process includes requesting, by the SMF, to the UDM to register a new session.

[0412] In one example, the process includes requesting, by the SMF, to transfer a message to the AMF to the NG-RAN node. In one example, the request includes sending a message by the SMF to the AMF and requesting, by the SMF to the AMF, to transfer the message to the NG-RAN node. In one example, the message includes and / or is a Namf_Communication_N1N2MessageTransfer message.

[0413] In one example, the process includes sending a session creation request by the AMF to the NG-RAN, for example via an N2_PDU Session Request message. In one example, the process includes confirming the session creation by the NG-RAN node, for example with an N2_PDU Session Response message.

[0414] In one example, the process includes establishing, by the NG-RAN, resources for the new session, e.g., required unicast resources such as point-to-multipoint radio bearers.

[0415] In one example, the process includes sending, by the AMF, to the SMF, a request to update the unicast session context, for example, with information from the NG-RAN, such as an Nsmf_PDUSession_UpdateSMContext request. In one example, the process includes confirming, by the SMF, receipt of the request, for example, with an Nsmf_PDUSession_UpdateSMContext response message.

[0416] In one example, the process includes updating, by the SMF, the unicast session context with information from the NG-RAN.

[0417] In one example, the process includes, for example, starting a unicast transmission using a multicast session and bearer. In one example, the process includes initially sending by a content provider to a UPF. In one example, the process includes processing the forwarded content (i.e., received data) by the UPF, for example, by applying FEC and / or Athlon codes, and sending the processed content to a NG-RAN node. In one example, the process includes sending the processed content by a NG-RAN node using a point-to-multipoint radio bearer.

[0418] In one example, the process includes releasing the multicast resources by the NG-RAN node if the handed over UE is the last UE in the 5MBS group, as the multicast resources are no longer needed.

[0419] In one example, the process includes deregistering, releasing and / or deleting the multicast session by the network if the handed-off UE is the last UE in the 5MBS group.

[0420] Example 3: Additional and / or Alternative Solutions to the First Architecture Reference Model

[0421] This example is related to the first architecture reference model in which MBSF and MBSU additional network functions are considered.In this example, there is a pre-existing MBS unicast session.

[0422] Fig.14 A use case of a process according to an exemplary embodiment is schematically depicted.

[0423] In more detail, Fig.14 A high-level description of the possible operations for this handover example is shown. It shows the provision of MBS services to one or more UEs from an MBS application / content server. The MBS content / application server sends signaling to the MBSF and data to the MBSU. The UE is shown as being located in an MBS and non-MBS service area. In the handover example, the UE may be located in a non-MBS area and then an MBS unicast PDU session serves the UE. Data is sent from the MBSU to the UPF and can only be sent by the NG-RAN via over-the-air unicast in a non-multicast service area. In this example, the UE may move to an MBS area, which may trigger a handover. The handover may be triggered by a new NG-RAN or by an MBSF / MBSU. Data is then sent from the MBSU to the MB-UPF and the NG-RAN uses over-the-air multicast.

[0424] Example 3.1 Flexible unicast to multicast delivery method switching in case of pre-existing MBS unicast session

[0425] In this example, the process is a process of switching from a first data transmission method to a second data transmission method in a 5G network, the 5G network comprising a set of user equipment UEs (including a first UE) communicatively coupled to the 5G network, a set of new generation radio access network (NG-RAN) nodes (including a first NG-RAN node), a 5G core, and a set of content providers (including a first content provider), wherein the method comprises:

[0426] sending, by the first NG-RAN node, first data from the set of content providers to the first UE in a first session according to a first data transmission method, wherein the first data transmission method is a unicast data transmission method, e.g., wherein the first session comprises and / or is a pre-existing MBS unicast session;

[0427] A decision is made by the first UE or the first NG-RAN node or the 5G core or the first content provider to switch from the first data transmission method to the second data transmission method, wherein the second data transmission method is a multicast transmission method;

[0428] Initializing, by the 5G core, a second session for a second transmission method, wherein the second session includes and / or is the first session, and wherein initializing, by the 5G core, includes updating the first session to the second session;

[0429] Switching, by the 5G core, from the first data transmission method to the second data transmission method; and

[0430] Second data is sent, by the first NG-RAN node, to the first UE from the set of content providers in a second session according to a second data transmission method.

[0431] That is, in this example, the second session includes and / or is the updated first session. In other words, the pre-existing MBS unicast session (ie, the first session) is updated to become a multicast session (ie, the second session).

[0432] In one example, the second session includes and / or is the updated first session.

[0433] In one example, the 5G network includes M-AMF, MB-SMF, MB-UBF, MBSF and MBSU. In one example, the 5G network optionally includes NEF.

[0434] In one example, the process includes registering, by the UE, with the 5G network, for example by performing a registration process according to [3].

[0435] In one example, the process includes announcing, by the content server (i.e., the first content provider), the availability of the multicast transmission (i.e., the second session), for example, via application layer signaling. In one example, announcing, by the content server, the availability of the multicast transmission includes providing information, such as a multicast IP address and / or a port number of the multicast group, so that the UE can join the multicast group.

[0436] In one example, the process includes establishing an MBS unicast PDU session by the UE and the 5G Core, for example according to [3].

[0437] In one example, the process includes initiating a unicast transmission by a content server. In one example, the process includes sending a unicast transmission by a content server. In one example, the process includes exchanging data between a UE and a content server.

[0438] In one example, the process includes sending, by the UE, a consumption report on each MBS unicast PDU session to the network. In one example, the process includes periodically sending, by the UE, a consumption report on each unicast PDU session to the network. These reports may be used later by the network to trigger a delivery method switch, e.g., between unicast and multicast. Since this step is optional, a delivery method switch may be triggered based on other criteria.

[0439] In one example, the process includes deciding by the UE or NG-RAN or 5G core or content server to switch the delivery method from, for example, an MBS unicast session and / or multiple MBS unicast sessions to a groupcast session, such as a single multicast session. It should be understood that decision can be used synonymously with triggering in this article. In other words, in one example, the process includes, for example, being triggered by the UE or NG-RAN or 5G core or content server to switch the delivery method from, for example, an MBS unicast session and / or multiple MBS unicast sessions to a groupcast session, such as a single multicast session. It should be understood that triggering by the UE and triggering by the NG-RAN are essentially equivalent, so references to triggering by the UE can be interchanged with triggering by the NG-RAN in this article. It should be understood that triggering by MBSF can also be referred to as triggering by the 5G core. That is, switching triggered by MBSF is synonymous with switching triggered by the 5G core. It should be understood that the decision by the UE or NG-RAN or 5G Core or content server to switch the delivery method from, for example, an MBS unicast session and / or multiple MBS unicast sessions to a multicast session, for example, a single multicast session, is unitary because the decision is made by the UE or NG-RAN or 5G Core or content server, i.e., these alternatives are mutually exclusive.

[0440] In one example, the decision by the first UE or the first NG-RAN node or the 5G core or the first content provider to switch from the first data transmission method to the second transmission method includes the decision by the first NG-RAN node to switch from the first data transmission method to the second transmission method. In one example, the process includes the decision by the NG-RAN to switch the delivery method from, for example, an MBS unicast session and / or multiple MBS unicast sessions to a multicast session, such as a single multicast session. That is, the trigger for the switch is in the NG-RAN and / or is caused by the NG-RAN. This may be referred to as a NG-RAN or RAN-triggered switch. As described above, this trigger may also include and / or be a trigger originating from the UE. For example, the NG-RAN may trigger the switch due to mobility reasons and / or due to a consumption report sent by the UE. In one example, the decision by the NG-RAN to switch the delivery method from the MBS unicast session to the multicast session is conditional, wherein a request to switch the delivery method from the UE to the NG-RAN is sent only when the UE requests to switch from the MBS unicast session to the multicast session for the MBS service that the UE is already receiving. In one example, the decision by the NG-RAN to switch the delivery method from an MBS unicast session to a multicast session includes modifying an established MBS unicast PDU session. In one example, modifying an established MBS unicast PDU session includes, for example, forwarding a message by the network. In one example, the forwarding message includes sending an N2_Session_ModificationRequest from the NG-RAN to the M-AMF. In one example, the forwarding message includes sending an Nsmf_Session_Modification request from the M-AMF to the MB-SMF in response to the M-AMF receiving the N2_Session_Modification request. In one example, the forwarding message includes sending an N6mb-C session modification request from the MB-SMF to the MBSF in response to the MB-SMF receiving the Nsmf_Session_Modification request. In one example, the forwarding message optionally includes sending an MBS session notification from the MBSF to the content server in response to the MBSF receiving the N6mb-C session modification request, for example, if the content server needs to know the switch from the MBS unicast session to the multicast session.

[0441] In one example, a decision by a first UE or a first NG-RAN node or a 5G core or a first content provider to switch from a first data transmission method to a second transmission method includes a decision by an MBSF to switch from the first data transmission method to a second transmission method. In one example, the process includes a decision by an MBSF to switch a delivery method from, for example, an MBS unicast session and / or multiple MBS unicast sessions to a multicast session, for example, a single multicast session. This may be referred to as an MBSF-triggered handover. As described above, an MBSF-triggered handover is synonymous with a 5G core-triggered handover. That is, the MBSF is an entity that decides to perform a handover from an MBS unicast session to a multicast session once an MBS service has been initiated. In one example, a decision by an MBSF to switch a delivery method from, for example, an MBS unicast session and / or multiple MBS unicast sessions to a multicast session is based at least in part on optimization criteria, such as a consumption report received from a UE.

[0442] In one example, the decision by the first UE or the first NG-RAN node or the 5G core or the first content provider to switch from the first data transmission method to the second transmission method includes the decision by the first content provider to switch from the first data transmission method to the second transmission method. In one example, the process includes the decision by the content server to switch the delivery method from, for example, an MBS unicast session and / or multiple MBS unicast sessions to a multicast session, for example, a single multicast session. That is, the content server decides to switch from the MBS unicast session to the multicast session.

[0443] In one example, the process includes requesting, by the MBSF, to update the first session of the UE to the MB-SMF, thereby providing the second session. In one example, the process includes requesting, by the MBSF, for example using an Nsmf_PDUSession_Update request, to update the MBS unicast session of the UE to a multicast session to the MB-SMF, optionally including providing parameters such as SUPI, S-NSSAI, MBSID / TMGI and / or DNN. In one example, the process includes confirming the session update by the MB-SMF, for example using an Nsmf_PDUSession_Update response, optionally including providing parameters such as its multicast IP address and / or port number for the NG-RAN.

[0444] In one example, the process includes registering, by the MB-SMF, an update from the first session to the second session with the UDM, and optionally, confirming, by the UDM to the MB-SMF. In one example, the process includes registering, by the MB-SMF, an update (i.e., modification) of the multicast session with the UDM, for example, using a Nudm_UECM_Update message, and optionally, confirming, by the UDM.

[0445] In one example, the process includes exchanging messages, such as internal messages, by the MBSF and the MBSU.

[0446] In one example, the process includes sending a message by the MB-SMF to the M-AMF and requesting by the MB-SMF to the M-AMF to forward the message to the first NG-RAN node, wherein the message includes parameters of the second session, and optionally, the M-AMF confirms receipt of the message to the MB-SMF. In one example, the process includes sending a message by the MB-SMF to the M-AMF, such as a Namf_Communication_N1N2MessageTransfer message, and requesting by the MB-SMF to the M-AMF to forward the message to the NG-RAN node, wherein the message includes parameters of the multicast MBS session, such as a multicast IP address, a port number, an APN and / or an NSAPI. In one example, the M-AMF confirms receipt of the message.

[0447] In one example, the process includes creating a multicast session (i.e., a second session), for example, in response to receiving a message by the M-AMF. In one example, creating the second session optionally includes sending a session creation request by the M-AMF to the first NG-RAN node and optionally confirming the session creation request by the first NG-RAN node to the M-AMF. In one example, creating the multicast session includes sending a session creation request by the M-AMF to the NG-RAN, for example, using an N2_PDU session request message. In one example, creating the multicast session includes confirming the session creation request by the NG-RAN to the M-AMF, for example, using an N2_PDU session response message that may optionally include downlink tunnel information. In one example, confirming the session creation request by the NG-RAN to the M-AMF is after resources, such as required resources, are established by the NG-RAN for the new session.

[0448] In one example, the process includes establishing, by the first NG-RAN node, resources for the second session, e.g., in response to receiving a session creation request by the first NG-RAN node. In one example, the process includes establishing, by the NG-RAN, resources for the new session, e.g., resources required by the UE, e.g., by setting up relevant bearers.

[0449] In one example, the process includes joining, by a NG-RAN node (ie, the first NG-RAN node), a related multicast session (ie, the second session).

[0450] In one example, the process includes updating a second session management context for a second session, for example, including sending, by the M-AMF, a request to update the second session management context to the MB-SMF. In one example, the process includes updating a multicast session management context, for example, including sending, by the M-AMF, a request to update the multicast session management context to the MB-SMF, for example, using an Nsmf_PDUSession_UpdateSMContext request, for example, with information from the NG-RAN, such as tunnel information, and optionally, confirming receipt of the request to the M-AMF by the MB-SMF, for example, using an Nsmf_PDUSession_UpdateSMContext response message.

[0451] In one example, the process includes updating a second session context of the second session, for example, including requesting, by the MB-SMF, to update the second session context to the MBSF. In one example, the process includes updating a multicast session context, for example, including requesting, by the MB-SMF, for example, via the N6mb-C interface, to update the multicast session context with information from the NG-RAN, and optionally, by the MBSF, for example, via the N6mb-C interface, to confirm the multicast session context update to the MB-SMF.

[0452] In one example, the process includes communicating between the MBSF and the MBSU regarding modifications to session parameters.

[0453] In one example, the process includes modification of the second session, for example, including sending a session modification request by the MB-SMF to the MB-UPF. In one example, the process includes session modification, for example, including sending a session modification request by the MB-SMF to the MB-UPF, for example, an N4 session modification request, and optionally, confirming the session modification request by the MB-UPF to the MB-SMF.

[0454] In one example, the first NG-RAN node sends the second data from the content provider set to the first UE in the second session according to the second data transmission method, including: sending the second data to the MBSU by the first content provider; processing the sent data by the MBSU; forwarding the processed data to the MB-UPF by the MBSU; sending the forwarded data to the first NG-RAN node by the MB-UPF; and multicasting the sent data by the first NG-RAN node. In one example, the process includes, for example, starting the multicast transmission using a multicast session and a bearer. In one example, the process includes initially sending content (i.e., data) to the MBSU by the content provider, for example, in unicast mode. In one example, the process includes processing the sent data by the MBSU, for example, by applying FEC and / or Athlon code. In one example, the process includes forwarding the processed data to the MB-UPF by the MBSU, for example, in unicast mode. In one example, the process includes sending the forwarded data to the NG-RAN node by the MB-UPF, for example, using IP multicast. In one example, the process includes multicasting the sent data by the NG-RAN node, for example, using an air multicast or unicast bearer, whereby the multicast data is received by the UE.

[0455] Example 3.2 Flexible unicast to multicast delivery method switching in case of pre-existing MBS unicast session

[0456] Example 3.2 is generally as described with respect to Example 3.1.

[0457] In this example, the process is a process of switching from a first data transmission method to a second data transmission method in a 5G network, the 5G network comprising a set of user equipment UEs (including a first UE) communicatively coupled to the 5G network, a set of new generation radio access network (NG-RAN) nodes (including a first NG-RAN node), a 5G core, and a set of content providers (including a first content provider), wherein the method comprises:

[0458] sending, by a first NG-RAN node, first data from a set of content providers to a first UE in a first session according to a first data transmission method, wherein the first data transmission method is an MBS data transmission method, e.g. wherein the first session comprises and / or is a unicast MBS session, such as a pre-existing unicast MBS session, with a 5GC separate service delivery method according to [3];

[0459] A decision is made by the first UE or the first NG-RAN node or the 5G core or the first content provider to switch from the first data transmission method to the second data transmission method, wherein the second data transmission method is a multicast transmission method;

[0460] Initializing, by the 5G core, a second session for a second transmission method, wherein the second session includes and / or is the first session, and wherein the initialization by the 5G core includes updating the first session to the second session;

[0461] Switching, by the 5G core, from the first data transmission method to the second data transmission method; and

[0462] Second data is sent, by the first NG-RAN node, to the first UE from the set of content providers in a second session according to a second data transmission method.

[0463] That is, in this example, the second session includes and / or is the updated first session. In other words, the unicast MBS session (ie, the first session) is updated to become a multicast session (ie, the second session).

[0464] In one example, the second session includes and / or is the updated first session.

[0465] In one example, the 5G network includes AMF, MB-SMF, MB-UBF, MBSF and MBSU. In one example, the 5G network optionally includes NEF. In one example, MBSF and NEF are separate physical entities or are located in one place.

[0466] In one example, the process includes registering, by the UE, with the 5G network, for example by performing a registration process according to [3].

[0467] In one example, the process includes announcing, by the content server (i.e., the first content provider), the availability of the multicast transmission (i.e., the second session), for example, via application layer signaling. In one example, announcing, by the content server, the availability of the multicast transmission includes providing information, such as a multicast IP address and / or a port number of the multicast group, so that the UE can join the multicast group.

[0468] In one example, the process includes establishing an MBS session by the UE and the 5G Core, for example according to [3].

[0469] In one example, the process includes starting, by the content server, an MBS transmission. In one example, the process includes sending, by the content server, an MBS transmission. In one example, the process includes exchanging data between the UE and the content server.

[0470] In one example, the process includes sending, by the UE, consumption reports on each MBS standalone session to the network. In one example, the process includes periodically sending, by the UE, consumption reports on each MBS standalone session to the network. These reports may later be used by the network to trigger a delivery method switch, e.g., between unicast delivery and multicast delivery. Since this step is optional, a delivery method switch may be triggered based on other criteria.

[0471] In one example, the process includes deciding by the UE or NG-RAN or 5G core or content server to switch the delivery method from, for example, an MBS unicast session and / or multiple MBS unicast sessions to a multicast session, such as a single multicast session. It should be understood that decision can be used synonymously with triggering in this article. In other words, in one example, the process includes being triggered by the UE or NG-RAN or 5G core or content server to switch the delivery method from, for example, an MBS unicast session and / or multiple MBS unicast sessions to a multicast session, such as a single multicast session. It should be understood that triggering by the UE and triggering by the NG-RAN are essentially equivalent, so references to triggering by the UE can be interchanged with triggering by the NG-RAN in this article. It should be understood that triggering by MBSF can also be referred to as triggering by the 5G core. That is, switching triggered by MBSF is synonymous with switching triggered by the 5G core. It should be understood that the decision by the UE or NG-RAN or 5G Core or content server to switch the delivery method from, for example, an MBS unicast session and / or multiple MBS unicast sessions to a multicast session, for example, a single multicast session, is unitary because the decision is made by the UE or NG-RAN or 5G Core or content server, i.e., these alternatives are mutually exclusive.

[0472] In one example, the decision by the first UE or the first NG-RAN node or the 5G core or the first content provider to switch from the first data transmission method to the second transmission method includes the decision by the first NG-RAN node to switch from the first data transmission method to the second transmission method. In one example, the process includes the decision by the NG-RAN to switch the delivery method from, for example, an MBS unicast session and / or multiple MBS unicast sessions to a multicast session, such as a single multicast session. That is, the trigger for the switch is in the NG-RAN and / or is caused by the NG-RAN. This may be referred to as a NG-RAN or RAN-triggered switch. As described above, this trigger may also include and / or be a trigger originating from the UE. For example, the NG-RAN may trigger the switch due to mobility reasons and / or due to a consumption report sent by the UE. In one example, the decision by the NG-RAN to switch the delivery method from the MBS unicast session to the multicast session is conditional, wherein a request to switch the delivery method from the UE to the NG-RAN is sent only when the UE requests to switch from the MBS unicast session to the multicast session for the MBS service that the UE is already receiving. In one example, a decision by the NG-RAN to switch the delivery method from an MBS unicast session to a multicast session includes, for example, modifying an established MBS session via separate delivery. In one example, modifying an established MBS session includes, for example, forwarding a message by the network. In one example, forwarding the message includes sending an N2_Session_ModificationRequest from the NG-RAN to the AMF. In one example, the forwarding message includes sending an Nsmf_Session_Modification request from the AMF to the MB-SMF in response to the AMF receiving the N2_Session_Modification request. In one example, the forwarding message includes sending an N6mb-C session modification request from the MB-SMF to the MBSF in response to the MB-SMF receiving the Nsmf_Session_Modification request. In one example, the forwarding message optionally includes sending an MBS session notification from the MBSF to the content server in response to the MBSF receiving the N6mb-C session modification request, for example if the content server needs to know about the switch from the MBS unicast session to the multicast session.

[0473] In one example, a decision by a first UE or a first NG-RAN node or a 5G core or a first content provider to switch from a first data transmission method to a second transmission method includes a decision by an MBSF to switch from the first data transmission method to a second transmission method. In one example, the process includes a decision by an MBSF to switch a delivery method from, for example, an MBS unicast session and / or multiple MBS unicast sessions to a multicast session, for example, a single multicast session. This may be referred to as an MBSF-triggered handover. As described above, an MBSF-triggered handover is synonymous with a 5G core-triggered handover. That is, the MBSF is an entity that decides to perform a handover from an MBS unicast session to a multicast session once an MBS service has been initiated. In one example, a decision by an MBSF to switch a delivery method from, for example, an MBS unicast session and / or multiple MBS unicast sessions to a multicast session is based at least in part on optimization criteria, such as a consumption report received from a UE.

[0474] In one example, the decision by the first UE or the first NG-RAN node or the 5G core or the first content provider to switch from the first data transmission method to the second transmission method includes the decision by the first content provider to switch from the first data transmission method to the second transmission method. In one example, the process includes the decision by the content server to switch the delivery method from, for example, an MBS unicast session and / or multiple MBS unicast sessions to a multicast session, for example, a single multicast session. That is, the content server decides to switch from the MBS unicast session to the multicast session.

[0475] In one example, the process includes requesting, by the MBSF, to update the first session of the UE to the MB-SMF, thereby providing the second session. In one example, the process includes requesting, by the MBSF, for example using an Nsmf_PDUSession_Update request, to update the MBS unicast session of the UE to a multicast session to the MB-SMF, optionally including providing parameters such as SUPI, S-NSSAI, MBSID / TMGI and / or DNN. In one example, the process includes confirming the session update by the MB-SMF, for example using an Nsmf_PDUSession_Update response, optionally including providing parameters such as its multicast IP address and / or port number for the NG-RAN.

[0476] In one example, the process includes registering, by the MB-SMF, an update from the first session to the second session with the UDM and optionally confirming, by the UDM, to the MB-SMF. In one example, the process includes registering, by the MB-SMF, an update (i.e., modification) of the multicast session with the UDM, for example, using a Nudm_UECM_Update message, and optionally, confirming, by the UDM.

[0477] In one example, the process includes exchanging messages, such as internal messages, by the MBSF and the MBSU. In one example, the process includes modifying a UPF session, such as sending a session modification request, such as an N4 session modification request, by the MB-SMF to the MB-UPF; and optionally, confirming the session update by the MB-UPF.

[0478] In one example, the process includes sending a message by the MB-SMF to the AMF and requesting by the MB-SMF to the AMF to forward the message to the first NG-RAN node, wherein the message includes parameters of the second session, and optionally, confirming receipt of the message by the AMF to the MB-SMF. In one example, the process includes sending a message by the MB-SMF to the AMF, such as a Namf_Communication_N1N2MessageTransfer message, and requesting by the MB-SMF to the AMF to forward the message to the NG-RAN node, wherein the message includes parameters of the multicast MBS session, such as a multicast IP address, a port number, an APN and / or an NSAPI. In one example, the AMF confirms receipt of the message.

[0479] In one example, the process includes creating a multicast session (i.e., a second session), for example, in response to the AMF receiving the message. In one example, creating the second session optionally includes sending a session creation request by the AMF to the first NG-RAN node and optionally confirming the session creation request by the first NG-RAN node to the AMF. In one example, creating the multicast session includes sending a session creation request, such as an MBS session creation request, by the AMF to the NG-RAN, for example, using an N2 session request message. In one example, creating the multicast session includes confirming the session creation request by the NG-RAN to the AMF, for example, using an N2 session response message that may optionally include downlink tunnel information. In one example, confirming the session creation request by the NG-RAN to the AMF is after resources, such as required resources, for the new session are established by the NG-RAN.

[0480] In one example, the process includes establishing, by the first NG-RAN node, resources for the second session, e.g., in response to receiving a session creation request by the first NG-RAN node. In one example, the process includes establishing, by the NG-RAN, resources for the new session, e.g., resources required by the UE, e.g., by setting up relevant bearers.

[0481] In one example, the process includes a NG-RAN node (ie, the first NG-RAN node) joining a related multicast session (ie, the second session).

[0482] In one example, the process includes updating a second session management context of a second session, for example, including sending, by the AMF, a request to update the second session management context to the MB-SMF. In one example, the process includes updating a multicast session management context, for example, including sending, by the AMF, a request to update the multicast session management context to the MB-SMF, for example, using an Nsmf_PDUSession_UpdateSMContext request, for example, with information from the NG-RAN, such as tunnel information, and optionally, confirming receipt of the request to the AMF by the MB-SMF, for example, using an Nsmf_PDUSession_UpdateSMContext response message.

[0483] In one example, the process includes updating a second session context of the second session, for example, including requesting, by the MB-SMF, to MBSF to update the second session context. In one example, the process includes updating a multicast session context, for example, including requesting, by the MB-SMF, to MBSF to update the multicast session context, for example, with information from, for example, the NG-RAN, and optionally, by the MBSF confirming the multicast session context update to the MB-SMF, for example, via the N6mb-C interface.

[0484] In one example, the process includes exchanging messages, such as internal messages, by the MBSF and the MBSU.

[0485] In one example, the process includes sending an MBS session start message by the MBSF to the AF.

[0486] In one example, the process includes communicating between the MBSF and the MBSU regarding modifications to session parameters.

[0487] In one example, the process includes modification of the second session, for example, including sending a session modification request, such as a UPF session modification request, by the MB-SMF to the MB-UPF. In one example, the process includes session modification, for example, including sending a session modification request, such as an N4 session modification request, by the MB-SMF to the MB-UPF, and optionally, confirming the session modification request by the MB-UPF to the MB-SMF.

[0488] In one example, sending second data from a set of content providers to a first UE in a second session according to a second data transmission method by a first NG-RAN node includes: sending the second data to an MBSU by a first content provider; processing the sent data by the MBSU; forwarding the processed data to an MB-UPF by the MBSU; sending the forwarded data to the first NG-RAN node by the MB-UPF; and sending the sent data by the first NG-RAN node. In one example, the process includes, for example, starting a multicast transmission using a multicast session and / or a bearer such as a PTM bearer. In one example, the process includes initially sending content (i.e., data) to the MBSU by a content provider, for example, in unicast mode. In one example, the process includes processing the sent data by the MBSU, for example, by applying FEC and / or Athlon codes. In one example, the process includes forwarding the processed data to the MB-UPF by the MBSU, for example, in unicast mode. In one example, the process includes sending the forwarded data to the NG-RAN node by the MB-UPF, for example, using IP multicast. In one example, the process includes multicasting, by the NG-RAN node, the transmitted data, for example using an over-the-air multicast or unicast bearer, whereby the multicast data is received by the UE.

[0489] Example 3.3 Multicast to Unicast Delivery Method Switching for the First Architecture Reference Model

[0490] In this example, there is a multicast session and a session management context for the service. This may have been initiated originally as a multicast session or may have been switched to a multicast session from a previous unicast session.

[0491] In particular, this example relates to a shared MBS to separate MBS service delivery method switch for the first architecture reference model, assuming a pre-existing shared MBS service delivery method. Such a pre-existing MBS session may have been directly established as an MBS session with 5GC shared MBS service delivery or it may have been previously switched from 5GC separate MBS service delivery to shared delivery.

[0492] This process illustrates handover for one UE, but by applying the same principle and service set to a group of UEs, multiple UEs can be switched from shared delivery to individual delivery simultaneously.

[0493] In this example, the process is a process of switching from a first data transmission method to a second data transmission method in a 5G network, the 5G network comprising a set of user equipment UEs (including a first UE) communicatively coupled to the 5G network, a set of new generation radio access network (NG-RAN) nodes (including a first NG-RAN node), a 5G core, and a set of content providers (including a first content provider), wherein the method comprises:

[0494] sending, by a first NG-RAN node, first data from a set of content providers to a first UE in a first session according to a first data transmission method, wherein the first data transmission method is an MBS data transmission method, e.g. wherein the first session comprises and / or is a shared MBS session, such as a pre-existing shared MBS session, or a separate MBS session, such as a pre-existing separate MBS session with a 5GC separate service delivery method according to [3];

[0495] A decision is made by the first UE or the first NG-RAN node or the 5G core or the first content provider to switch from the first data transmission method to the second data transmission method, wherein the second data transmission method is a multicast transmission method;

[0496] Initializing, by the 5G core, a second session for a second transmission method, wherein the second session includes and / or is the first session, and wherein the 5G core initialization includes updating the first session to the second session;

[0497] Switching, by the 5G core, from the first data transmission method to the second data transmission method; and

[0498] Second data is sent, by the first NG-RAN node, to the first UE from the set of content providers in a second session according to a second data transmission method.

[0499] That is, in this example, the second session includes and / or is the updated first session. In other words, the shared or individual MBS session (ie, the first session) is updated to become a multicast session (ie, the second session).

[0500] In one example, the second session includes and / or is the updated first session.

[0501] In one example, the 5G network includes AMF, MB-SMF, MB-UBF, MBSF and MBSU. In one example, the 5G network optionally includes NEF. In one example, MBSF and NEF are separate physical entities or are located in one place.

[0502] In one example, the process includes registering, by the UE, with the 5G network, for example by performing a registration process according to [3].

[0503] In one example, the process includes announcing, by the content server (i.e., the first content provider), the availability of the multicast transmission (i.e., the second session), for example, via application layer signaling. In one example, announcing, by the content server, the availability of the multicast transmission includes providing information, such as a multicast IP address and / or a port number of the multicast group, so that the UE can join the multicast group.

[0504] In one example, the process includes establishing an MBS session by the UE and the 5G Core, for example according to [3].

[0505] In one example, the process includes starting, by the content server, an MBS transmission. In one example, the process includes sending, by the content server, an MBS transmission. In one example, the process includes exchanging data between the UE and the content server.

[0506] In one example, the process includes sending, by the UE, consumption reports on each MBS standalone session to the network. In one example, the process includes periodically sending, by the UE, consumption reports on each MBS standalone session to the network. These reports may later be used by the network to trigger a delivery method switch, e.g., between unicast delivery and multicast delivery. Since this step is optional, a delivery method switch may be triggered based on other criteria.

[0507] In one example, the process includes a decision by the UE or NG-RAN or 5G core or content server to switch the delivery method from, for example, a shared or separate MBS session to a multicast session, such as a single multicast session. It should be understood that the decision can be used synonymously with the trigger in this article. In other words, in one example, the process includes being triggered by the UE or NG-RAN or 5G core or content server to switch the delivery method from, for example, a shared or separate MBS session to a multicast session, such as a single multicast session. It should be understood that triggering by the UE and triggering by the NG-RAN are essentially equivalent, so references to triggering by the UE can be interchanged with triggering by the NG-RAN in this article. It should be understood that triggering by MBSF can also be referred to as triggering by the 5G core. That is, the switching triggered by the MBSF is synonymous with the switching triggered by the 5G core. It should be understood that the decision by the UE or NG-RAN or 5G core or content server to switch the delivery method from, for example, a shared or separate MBS session to a multicast session, such as a single multicast session, is unidirectional because the decision is made by the UE or NG-RAN or 5G core or content server, that is, these alternatives are mutually exclusive.

[0508] Alternative 1: RAN-triggered handover

[0509] This alternative assumes that the trigger for handover is in the NG-RAN, so the NG-RAN can effectively make handover decisions based on UE consumption reports, handover requirements, resource availability, etc. In addition, when the RAN delivery method needs to be changed from PTM to PTP, the NG-RAN may need to be involved in the handover process itself.

[0510] In one example, the decision by the first UE or the first NG-RAN node or the 5G core or the first content provider to switch from the first data transmission method to the second transmission method includes the decision by the first NG-RAN node to switch from the first data transmission method to the second transmission method. In one example, the process includes the decision by the NG-RAN to switch the delivery method from, for example, a shared or separate MBS session to a multicast session, such as a single multicast session. That is, the trigger for the switch is in the NG-RAN and / or is caused by the NG-RAN. This may be referred to as a NG-RAN or RAN-triggered switch. As described above, this trigger may also include and / or be a trigger from the UE. For example, the NG-RAN may trigger the switch due to mobility reasons and / or due to a consumption report sent by the UE, a switching requirement and / or resource availability. In one example, the decision by the NG-RAN to switch the delivery method from a shared or separate MBS session to a multicast session is conditional, wherein a request to switch the delivery method from the UE to the NG-RAN is sent only when the UE requests to switch from a shared or separate MBS session to a multicast session for an MBS service that the UE is already receiving. In one example, the decision by the NG-RAN to switch the delivery method from a shared or individual MBS session to a multicast session includes, for example, modifying an established MBS session via individual delivery. In one example, modifying an established MBS session includes, for example, forwarding a message by the network. In one example, the forwarding message includes sending an N2_Session_Modification request from the NG-RAN to the AMF. In one example, the forwarding message includes sending an Nsmf_Session_Modification request from the AMF to the MB-SMF in response to the AMF receiving the N2_Session_Modification request. In one example, the forwarding message includes sending an Nmbs session modification request from the MB-SMF to the MBSF in response to the MB-SMF receiving the Nsmf_Session_Modification request. In one example, the forwarding message optionally includes sending an MBS session notification from the MBSF to the content server via the NEF in response to the MBSF receiving the N6mb-C session modification request, for example if the content server needs to know about the switch from a shared or individual MBS session to the multicast session.

[0511] Alternative 2: MBSF-triggered handover

[0512] This alternative assumes that the MBSF is the entity that decides to perform a switch from shared MBS service delivery to separate MBS service delivery. The decision may be based on different optimization criteria (eg consumption reports, UE population in a certain area, etc.).

[0513] In one example, the decision by the first UE or the first NG-RAN node or the 5G core or the first content provider to switch from the first data transmission method to the second transmission method includes the decision by the MBSF to switch from the first data transmission method to the second transmission method. In one example, the process includes the decision by the MBSF to switch the delivery method from, for example, a shared or individual MBS session to a multicast session, such as a single multicast session. This may be referred to as an MBSF-triggered handover. As described above, the MBSF-triggered handover is synonymous with the 5G core-triggered handover. That is, the MBSF is the entity that decides to perform a handover from a shared or individual MBS session to a multicast session once the MBS service has been initiated. In one example, the decision by the MBSF to switch the delivery method from, for example, a shared or individual MBS session to a multicast session is based at least in part on optimization criteria, such as consumption reports received from the UE, a group of UEs in a certain area, and the like.

[0514] Alternative 3: Content / application server triggered switching

[0515] This alternative illustrates the possibility that the content / application server decides to switch from shared MBS service delivery to individual MBS service delivery.

[0516] In one example, the decision by the first UE or the first NG-RAN node or the 5G core or the first content provider to switch from the first data transmission method to the second transmission method includes the decision by the first content provider to switch from the first data transmission method to the second transmission method. In one example, the process includes the decision by the content server to switch the delivery method from, for example, a shared or separate MBS session to a multicast session, for example, a single multicast session. That is, the content server decides to switch from a shared or separate MBS session to a multicast session.

[0517] In one example, the process includes requesting, by the MBSF, to update the first session of the UE to the MB-SMF, thereby providing the second session. In one example, the process includes requesting, by the MBSF, to update the MBS unicast session of the UE to a multicast session to the MB-SMF, for example using an Nsmf_Session_Update request, optionally including providing parameters, such as SUPI, S-NSSAI, MBSID / TMGI and / or DNN. In one example, the process includes confirming the session update by the MB-SMF, for example using an Nsmf_Session_Update response, optionally including providing parameters, such as its multicast IP address and / or port number for the NG-RAN.

[0518] In one example, the process includes registering, by the MB-SMF, an update from the first session to the second session with the UDM, and optionally, confirming, by the UDM to the MB-SMF. In one example, the process includes registering, by the MB-SMF, an update (i.e., modification) of the multicast session with the UDM, for example, using a Nudm_UECM_Update message, and optionally, confirming, by the UDM.

[0519] In one example, the process includes modification of a UPF session, such as sending a session modification request, such as an N4 session modification request, by the MB-SMF to the MB-UPF; and optionally, confirming the session update by the MB-UPF.

[0520] In one example, the process includes sending a message by the MB-SMF to the AMF, and requesting by the MB-SMF to the AMF to forward the message to the first NG-RAN node, wherein the message includes parameters of the second session, and optionally, confirming receipt of the message by the AMF to the MB-SMF. In one example, the process includes sending a message by the MB-SMF to the AMF, such as a Namf_Communication_N1N2MessageTransfer message, and requesting by the MB-SMF to the AMF to forward the message to the NG-RAN node, wherein the message includes parameters of the multicast MBS session, such as a multicast IP address, a port number, an APN and / or an NSAPI. In one example, the AMF confirms receipt of the message.

[0521] In one example, the process includes creating a multicast session (i.e., a second session), for example, in response to receiving a message by the AMF. In one example, creating the second session optionally includes sending a session creation request by the AMF to the first NG-RAN node and optionally confirming the session creation request by the first NG-RAN node to the AMF. In one example, creating the multicast session includes sending a session creation request, such as an MBS session creation request, by the AMF to the NG-RAN, for example, using an N2 session request message. In one example, creating the multicast session includes confirming the session creation request by the NG-RAN to the AMF, for example, using an N2 session response message that may optionally include downlink tunnel information. In one example, confirming the session creation request by the NG-RAN to the AMF is after resources for the new session, such as required resources and / or adjusting resources (such as switching PTM delivery to PTP) are established by the NG-RAN.

[0522] In one example, the process includes establishing, by the first NG-RAN node, resources for the second session, e.g., in response to receiving a session creation request by the first NG-RAN node. In one example, the process includes establishing, by the NG-RAN, resources for the new session, e.g., resources required by the UE, e.g., by setting up relevant bearers and / or adjusting resources, such as, e.g., switching PTM delivery to PTP when the delivery switch involves a switch from PTM to PTP in the RAN.

[0523] In one example, the process includes a NG-RAN node (ie, the first NG-RAN node) joining a related multicast session (ie, the second session).

[0524] In one example, the process includes updating a second session management context of a second session, for example, including sending, by the AMF, a request to update the second session management context to the MB-SMF. In one example, the process includes updating a multicast session management context, for example, including sending, by the AMF, a request to update the multicast session management context to the MB-SMF, for example, using an Nsmf_Session_UpdateSMContext request, for example, with information from the NG-RAN, such as tunnel information, and optionally, confirming receipt of the request to the AMF by the MB-SMF, for example, using an Nsmf_Session_UpdateSMContext response message.

[0525] In one example, the process includes updating a second session context of the second session, for example, including requesting, by the MB-SMF, to update the second session context to the MBSF, such as by an Nmbs session update SM context request message to update a separate MBS session context with information from the NG-RAN. In one example, the process includes confirming, by the MBSF, the content update to the MB-SMF, for example, with an Nmbs session update SM context response.

[0526] In one example, the process includes exchanging messages, such as internal messages, by the MBSF and the MBSU.

[0527] In one example, the process includes sending an MBS session start message by the MBSF to the AF.

[0528] In one example, the process includes modification of the second session, for example including sending a session modification request, such as an N4 session modification request, optionally including new tunnel information, by the MB-SMF to the MB-UPF. In one example, the process includes session modification, for example including sending a session modification request, such as an N4 session modification request, optionally including new tunnel information, by the MB-SMF to the MB-UPF, and optionally, confirming the session modification request by the MB-UPF to the MB-SMF.

[0529] In one example, sending second data from a set of content providers to a first UE in a second session according to a second data transmission method by a first NG-RAN node includes: sending the second data to an MBSU by a first content provider; processing the sent data by the MBSU; forwarding the processed data to an MB-UPF by the MBSU; sending the forwarded data to the first NG-RAN node by the MB-UPF; and sending the sent data by the first NG-RAN node. In one example, the process includes, for example, starting a multicast transmission using a multicast session and / or a bearer such as a PTM bearer. In one example, the process includes initially sending content (i.e., data) to the MBSU by a content provider, for example, in unicast mode. In one example, the process includes processing the sent data by the MBSU, for example, by applying FEC and / or Athlon codes. In one example, the process includes forwarding the processed data to the MB-UPF by the MBSU, for example, in unicast mode. In one example, the process includes sending the forwarded data to the NG-RAN node by the MB-UPF, for example, using IP multicast. In one example, the process includes multicasting, by the NG-RAN node, the transmitted data, for example using a wireless multicast or unicast bearer, whereby the multicast data is received by the UE.

[0530] In one example, the process includes sending IP multicast data by a first content provider to an MBSU; processing the received data by the MBU, for example, by applying FEC, Athlon code, etc.; forwarding the processed data (i.e., MBS data) to the MB-UPF by the MBSU via 5GC separate service delivery; sending the forwarded data to the NG-RAN by the MB-UPF via separate delivery; sending the sent data by the NG-RAN over the air, for example, using a PTP bearer; and receiving the sent data by the UE.

[0531] In one example, the process includes suspending and / or releasing the second session (i.e., MBS session), for example, by the 5GC, if the number of UEs included in the second session is less than a threshold number, for example, if no UE is included in the second session. If there are no additional UEs left in the MBS session with shared delivery, the 5GC may decide to suspend or release the MBS session. Suspending the MBS session does not involve deleting the MBS session context in the 5GC NF to facilitate UEs joining the MBS session or switching to shared delivery with reduced signaling in the future; releasing the MBS session does delete the MBS session context from all entities in the 5GC. In one example, the process includes releasing resources if the second session (i.e., MBS session) is suspended and / or released. Unfinished NG-RAN resources for PTM delivery of the shared MBS session are released in both cases.

[0532] Alternative A: Suspension of shared MBS sessions

[0533] In one example, the process includes requesting the MBSF to suspend the second session (ie, the shared MBS session) to the MB-SMF. In one example, the process includes sending an Nsmf session suspension request to the MB-SMF by the MBSF, the request being used to request suspension of the MBS session for shared delivery.

[0534] In one example, the process includes forwarding a request to suspend the second session by the MB-SMF to the AMF. In one example, the process includes sending a Namf session suspension request by the MB-SMF to the AMF to forward the suspension request of the MBS session for shared delivery.

[0535] In one example, the process includes requesting, by the AMF, to release resources, such as outstanding PTM resources, from the NG-RAN. In one example, the process includes sending, by the AMF, an N2 session suspend request to the NG-RAN to release any outstanding PTM resources.

[0536] In one example, the process includes confirming, by the NG-RAN, to the AMF, the suspension of the second session (i.e., the shared MBS session). In one example, the process includes sending, by the NG-RAN to the AMF, an N2 session suspension response message to confirm the suspension of the shared MBS session.

[0537] In one example, the process includes releasing resources, such as any outstanding allocated resources by the NG-RAN to the shared MBS session for PTM delivery.

[0538] In one example, the process includes confirming the suspension of the second session (i.e., the shared MBS session) by the AMF to the MB-SMF. In one example, the process includes sending a Namf session suspension response message by the AMF to the MB-SMF, the message being used to confirm the suspension of the shared MBS session.

[0539] In one example, the process includes confirming, by the MB-SMF, to the MBSF, the suspension of the second session (ie, the shared MBS session). In one example, the process includes sending, by the MB-SMF, to the MBSF, an Nsmf session suspension response message to confirm the suspension of the shared MBS session.

[0540] Alternative B: Release of shared MBS session

[0541] In one example, the process includes requesting the MB-SMF to release the second session (i.e., the shared MBS session) and / or delete the associated resources to the AMF. In one example, the process includes sending a Namf session release request from the MB-SMF to the AMF, the request being used to request the release of the shared MBS session and / or delete the associated resources. In one example, the process includes confirming the release of the second session and / or the deletion of the associated resources by the AMF to the MB-SMF.

[0542] In one example, the process includes requesting, by the AMF, to the NG-RAN to release resources allocated to the second session (i.e., the shared MBS session). In one example, the process includes sending, by the AMF, an N2 session release request to the NG-RAN, the request being used to request the release of resources allocated to the shared MBS session. In one example, the process includes confirming, by the NG-RAN, the release of resources to the AMF. In one example, the process includes sending, by the NG-RAN, an N2 session release response message to the AMF to confirm the release of resources associated with the shared MBS session.

[0543] In one example, the process includes releasing resources, e.g., outstanding allocated resources, such as resources allocated to a shared MBS session for PTM delivery, by the NG-RAN.

[0544] In one example, the process includes requesting by the AMF to the MB-SMF to release a session management context for a second session (i.e., for a shared MBS session), such as an MBS session management context. In one example, the process includes sending by the AMF to the MB-SMF an Nsmf Release SMContext request message, which is used to request the release of the MBS session management context for the shared MBS session. In one example, the process includes confirming by the MB-SMF to the AMF the release of the session management context. In one example, the process includes sending by the MB-SMF to the AMF an Nsmf Release SMContext response message, which is used to confirm the release of the MBS session management context for the shared MBS session.

[0545] In one example, the process includes requesting, by the MB-SMF, to release a session management context for a second session (i.e., for a shared MBS session), such as an MBSF session management context. In one example, the process includes sending, by the MB-SMF, an Nmbs Release SMContext request to the MBSF, the request being used to request the release of the MBS session management context for the shared MBS session. In one example, the process includes confirming, by the MBSF, the release of the second session to the MB-SMF. In one example, the process includes sending, by the MBSF, an Nsmf Release SMContext response message to the MB-SMF, the message being used to confirm the release of the MBS session management context for the shared MBS session.

[0546] In one example, the process includes requesting, by the MB-SMF, to release the second session (i.e., the shared MBS session) from the MB-UPF, and optionally, confirmation by the MB-UPF. In one example, the process includes sending, by the MB-SMF, an N4 session release request to the MB-UPF, the request being used to request the release of the shared MBS session, and the release of the shared MBS session is then confirmed by the MB-UPF.

[0547] In one example, the process includes exchanging messages, such as internal messages, by the MBSF and the MBSU.

[0548] In one example, the process includes sending an MBS Session End message by the MBSF, for example, to the content / application server, which may optionally be first forwarded by the NEF before reaching the content / application server.

[0549] definition

[0550] Throughout this specification, the term "comprising" or "including" means including the specified components without excluding the presence of other components. The term "consisting essentially of" or "consisting essentially of" means including the specified components but excluding other components except for materials present as impurities, unavoidable materials present as a result of a process for providing a component, and components added for purposes other than achieving the technical effects of the present invention (such as colorants), etc.

[0551] The term "consisting of" or "composed of is intended to include the specified components but exclude other components.

[0552] Where appropriate, depending on the context, the use of the terms "comprising" or "including" may also be considered to include the meaning of "consisting essentially of" or "consisting essentially of", and likewise may also be considered to include the meaning of "consisting of" or "consisting of."

[0553] The optional features set out herein may be used individually or in combination with each other as appropriate and in particular in the combination set out in the appended claims. The optional features of each aspect or exemplary embodiment of the invention as set out herein are also applicable to all other aspects or exemplary embodiments of the invention as appropriate. In other words, the technician reading this specification should consider the optional features of each aspect or exemplary embodiment of the invention to be interchangeable and combinable between different aspects and exemplary embodiments.

[0554] Example

[0555] This section presents different solutions for supporting delivery method switching (unicast to multicast / broadcast, multicast / broadcast to unicast) in 5G networks. Since the final architecture model for 5G networks is still not defined, we present solutions for the most prominent architecture reference models. For each model, we present examples for switching the delivery method from unicast to multicast / broadcast and from multicast / broadcast to unicast. In addition, we also consider separately whether the session has a pre-existing delivery method switch.

[0556] Example 1: Solution for the first architectural reference model

[0557] This example is related to the first architecture reference model in which the BMF-C and BMF-U additional network functions are considered. When switching the delivery method from unicast to multicast or broadcast, we propose two different solutions depending on whether a session pre-exists. When the delivery method is switched from multicast / broadcast to unicast, we present a single solution because a new session will have to be established as long as the UE to be switched is not the last UE in the 5MBS group.

[0558] Example 1.1 Unicast to Multicast / Broadcast Delivery Method Switching Without Pre-Existing Sessions

[0559] In this example, there is neither a multicast session nor any session management context for the service, so once a delivery method switch is triggered, a new session and session management context must be created.

[0560] Fig. 7A and Figure 7B A process according to an exemplary embodiment is schematically depicted. In particular, Fig. 7A and Figure 7B Unicast to multicast / broadcast delivery method switching without a pre-existing session is shown for a first architecture reference model.

[0561] The switching process is as follows:

[0562] 1. The UE performs the registration procedure according to [3].

[0563] 2. The UE and 5G core establish a unicast PDU session according to [3].

[0564] 3. Unicast transmission starts.

[0565] 4. Optionally, the UE periodically sends consumption reports about their unicast PDU sessions to the network. These reports can be used later by the network to trigger a delivery method switch. Since this step is optional, a delivery method switch can be triggered based on other criteria.

[0566] 5. At some point, the UE or NG-RAN or 5G Core or content server decides to switch the delivery method from multiple unicast sessions to a single multicast / broadcast session.

[0567] 6. Optionally, the content server requests a session from the BMF-C (eg in case it is the content server that decides on the delivery method switch).

[0568] 7. Optionally, the BMF-C discovers the downstream network functions that will be involved in the new session. The execution of this step depends on different conditions. The following non-exhaustive list includes some situations where NF discovery is required:

[0569] a. The UE is the first UE to switch the delivery method from unicast to multicast, i.e. a new session and session management context needs to be created.

[0570] b. The UE moves from a cell delivering content in unicast mode to a cell supporting 5MBS where there is no ongoing multicast session.

[0571] The following non-exhaustive list includes some situations where NF discovery is not needed:

[0572] a. The UE moves from a cell delivering content in unicast mode to a cell supporting 5MBS where there is an ongoing multicast session.

[0573] b. The previous multicast session exists in an inactive state and can be reused.

[0574] 8. BMF-C requests the creation of a new session by SMF, thereby providing the parameters required for the session. SMF responds to confirm the creation of the session and provide its multicast IP address and port number.

[0575] 9. BMF-C sends a Nsmf_PDUSession_CreateSMContext message to SMF, which is used to request the creation of a new session management context. If the context is successfully created, SMF confirms it with a Nsmf_PDUSession_CreateSMContext response message.

[0576] 10. Optionally, the SMF can register the multicast session with the UDM.

[0577] 11. The new session is announced to the network providing information such as the multicast IP address and port number.

[0578] 12.SMF sends a Namf_Communication_N1N2MessageTransfer message to AMF to request the message to be transferred to the NG-RAN node.

[0579] 13.AMF sends a Session Creation Request to the NG-RAN via the N2_PDU Session Request message. The session creation is later confirmed with the N2_PDU Session Response message.

[0580] 14.NG-RAN establishes the required resources.

[0581] 15. If the session is switched to multicast, the NG-RAN node joins the relevant multicast. Otherwise, if the delivery method is switched to broadcast, no such joining is required.

[0582] 16. The AMF now sends a Nsmf_PDUSession_UpdateSMContext request to the SMF to update the multicast session context with the information from the NG-RAN, and the SMF confirms receipt with a Nsmf_PDUSession_UpdateSMContext response message.

[0583] 17.SMF requests BMF-C to update the multicast session context with the information from NG-RAN as per the newly introduced Nbmf_PDUSession_UpdatePDUContext request, and BMF-C confirms the context update with Nbmf_PDUSession_UpdatePDUContext response.

[0584] 18. Multicast transmission starts using multicast session and bearer. Initially, content is sent from content provider to BMF-U in unicast mode, and BMF-U forwards data to UPF in the same way. UPF processes the received data (e.g., applying FEC, Athlon code) and sends them to NG-RAN node using IP multicast. Finally, NG-RAN node multicasts / broadcasts data in the air using over-the-air multicast or unicast bearer.

[0585] Example 1.2 Unicast to Multicast / Broadcast Delivery Method Switching with Pre-Existing Sessions

[0586] In this example, both the multicast session and the session management context for the service exist, so once a delivery method switch is triggered, there is no need to create a new session or session management context.

[0587] Fig. 8A and Figure 8B A process according to an exemplary embodiment is schematically depicted. In particular, Fig. 8A and Figure 8B Unicast to multicast / broadcast delivery method switching in case of a pre-existing session is shown for the first architecture reference model.

[0588] The switching process is as follows:

[0589] 1. The UE performs the registration procedure according to [3].

[0590] 2. The UE and 5G core establish a unicast PDU session according to [3].

[0591] 3. Unicast transmission starts.

[0592] 4. Optionally, the UE periodically sends consumption reports about their unicast PDU sessions to the network. These reports can be used later by the network to trigger a delivery method switch. Since this step is optional, a delivery method switch can be triggered based on other criteria.

[0593] 5. At some point, the UE or NG-RAN or 5G Core or content server decides to switch the delivery method from multiple unicast sessions to a single multicast / broadcast session.

[0594] 6. Optionally, the content server requests a session from the BMF-C (eg in case it is the content server that decides on the delivery method switch).

[0595] 7. BMF-C requests that the session be updated by SMF, providing the required parameters. SMF responds to confirm the modification.

[0596] 8. Optionally, the BMF-C may request to update the session management context associated with the existing multicast session.

[0597] 9. Optionally, the SMF may register modifications of the multicast session to the UDM.

[0598] 10. The updated session is announced to the network, providing information such as the multicast IP address and port number.

[0599] 11.SMF sends a Namf_Communication_N1N2MessageTransfer message to AMF to request the message to be transferred to the NG-RAN node.

[0600] 12.AMF sends a Session Creation Request to the NG-RAN via the N2_PDU Session Request message. The session creation is later confirmed with the N2_PDU Session Response message.

[0601] 13.NG-RAN establishes the required resources.

[0602] 14. If the session is switched to multicast, the NG-RAN node joins the relevant multicast. Otherwise, if the delivery method is switched to broadcast, no such joining is required.

[0603] 15.AMF now sends a Nsmf_PDUSession_UpdateSMContext request to SMF, which is used to request to update the multicast session context with information from NG-RAN, and SMF confirms receipt with a Nsmf_PDUSession_UpdateSMContext response message.

[0604] 16.SMF requests BMF-C to update the multicast session context with the information from NG-RAN as per the newly introduced Nbmf_PDUSession_UpdatePDUContext request, and BMF-C confirms the context update with Nbmf_PDUSession_UpdatePDUContext response.

[0605] 17. Multicast transmission starts using multicast session and bearer. Initially, content is sent from content provider to BMF-U in unicast mode, and BMF-U forwards data to UPF in the same way. UPF processes the received data (e.g., applying FEC, Athlon code) and sends them to NG-RAN node using IP multicast. Finally, NG-RAN node multicasts / broadcasts data in the air using over-the-air multicast or unicast bearer.

[0606] Example 1.3 Multicast / Broadcast to Unicast Delivery Method Switching

[0607] In this example, the UE has already registered with the network and an active multicast session already exists. In addition, the UE for which the session handover is performed is not the last UE in the 5MBS group to receive the multicast context, so a new unicast session must be established.

[0608] Fig. 9A and Fig. 9B A process according to an exemplary embodiment is schematically depicted. In particular, Fig. 9A and Fig. 9B A multicast / broadcast to unicast delivery method switch is shown for the first architecture reference model.

[0609] The switching process is as follows:

[0610] 1. A multicast / broadcast session is in progress.

[0611] 2. At some point, the UE or NG-RAN or 5G core or content server decides to switch the UE’s multicast / broadcast session to unicast.

[0612] 3. Optionally, the content server requests a session from the BMF-C (eg in case it is the content server that decides on the delivery method switch).

[0613] 4. Optionally, the network performs NF discovery for the new session.

[0614] 5. BMF-C requests SMF to create a new PDU session.

[0615] 6. BMF-C requests SMF to create a new session management context.

[0616] 7. Optionally, SMF requests that the new session be registered with the UDM.

[0617] 8.SMF sends a Namf_Communication_N1N2MessageTransfer message to AMF, which is used to request the transfer of the message to the NG-RAN node.

[0618] 9.AMF sends a Session Creation Request to NG-RAN via N2_PDU Session Request message. The Session Creation is later confirmed with N2_PDU Session Response message.

[0619] 10.NG-RAN establishes the required unicast resources.

[0620] 11.AMF now sends a Nsmf_PDUSession_UpdateSMContext request to SMF requesting to update the new unicast session context with information from NG-RAN and SMF confirms receipt with a Nsmf_PDUSession_UpdateSMContext response message.

[0621] 12. Optionally, the SMF requests the BMF-C to update the unicast session context with the information from the NG-RAN as per the newly introduced Nbmf_PDUSession_UpdatePDUContext request, and the BMF-C confirms the context update with the Nbmf_PDUSession_UpdatePDUContext response.

[0622] 13. Unicast transmission starts using multicast session and bearer. Initially, content is sent from content provider to BMF-U and BMF-U forwards data to UPF in the same way. UPF processes received data (e.g., applies FEC, Athlon code) and sends them to NG-RAN node. Finally, NG-RAN node sends data over the air using air unicast bearer established in step 10.

[0623] 14. Optionally, if the handed over UE is the last UE in the 5MBS group, the NG-RAN node releases the multicast resources as they are no longer needed.

[0624] 15. Optionally, if the switched UE is the last UE in the 5MBS group, the network optionally deregisters, releases and deletes the multicast session.

[0625] Example 2: Solution for the Second Architecture Reference Model

[0626] Example 2 is related to the second architecture reference model in which no additional network functions are considered. Similar to Example 1, when the delivery method is switched from unicast to multicast or broadcast, two different solutions are presented depending on whether a session pre-exists (Examples 2.1 and 2.2). When the delivery method is switched from multicast / broadcast to unicast, a single solution is presented (Example 2.3) because a new session has to be established as long as the UE to be switched is not the last UE in the 5MBS group.

[0627] Example 2.1 Unicast to Multicast / Broadcast Delivery Method Switching Without Pre-Existing Session

[0628] In this example, there is neither a multicast session nor any session management context for the service, so once a delivery method switch is triggered, a new session and session management context must be created.

[0629] Fig. 10A and Fig. 10B A process according to an exemplary embodiment is schematically depicted. In particular, Fig. 10A and Fig. 10B Unicast to multicast / broadcast delivery method switching without a pre-existing session is shown for the second architecture reference model.

[0630] The switching process is as follows:

[0631] 1. The UE performs the registration procedure according to [3].

[0632] 2. The UE and 5G core establish a unicast PDU session according to [3].

[0633] 3. Unicast transmission starts.

[0634] 4. Optionally, the UE periodically sends consumption reports about their unicast PDU sessions to the network. These reports can be used later by the network to trigger a delivery method switch. Since this step is optional, a delivery method switch can be triggered based on other criteria.

[0635] 5. At some point, the UE or NG-RAN or 5G Core or content server decides to switch the delivery method from multiple unicast sessions to a single multicast / broadcast session.

[0636] 6. The content server requests a session from the SMF.

[0637] 7. Optionally, the SMF discovers the downstream network functions that will be involved in the new session. The execution of this step depends on different conditions. The following non-exhaustive list includes some situations where NF discovery is required:

[0638] a. The UE is the first UE to switch the delivery method from unicast to multicast, i.e. a new session and session management context needs to be created.

[0639] b. The UE moves from a cell delivering content in unicast mode to a cell supporting 5MBS where there is no ongoing multicast session.

[0640] The following non-exhaustive list includes some situations where NF discovery is not needed:

[0641] a. The UE moves from a cell delivering content in unicast mode to a cell supporting 5MBS where there is an ongoing multicast session.

[0642] b. The previous multicast session exists in an inactive state and can be reused.

[0643] 8. SMF creates a new session based on the parameters required by the session. SMF also allocates a multicast IP address and port number for the new session.

[0644] 9. The SMF creates a new SM context or updates the existing SM context (if applicable).

[0645] 10. Optionally, SMF registers the new multicast session with UDM.

[0646] 11. The new session is announced to the network providing information such as the multicast IP address and port number.

[0647] 12.SMF sends a Namf_Communication_N1N2MessageTransfer message to AMF to request the message to be transferred to the NG-RAN node.

[0648] 13.AMF sends a Session Creation Request to the NG-RAN via the N2_PDU Session Request message. The session creation is later confirmed with the N2_PDU Session Response message.

[0649] 14.NG-RAN establishes the required resources.

[0650] 15. If the session is switched to multicast, the NG-RAN node joins the relevant multicast. Otherwise, if the delivery method is switched to broadcast, no such joining is required.

[0651] 16.AMF now sends a Nsmf_PDUSession_UpdateSMContext request to SMF, which is used to request to update the multicast session context with information from NG-RAN, and SMF confirms receipt with a Nsmf_PDUSession_UpdateSMContext response message.

[0652] 17.SMF updates the multicast session context with the information from NG-RAN.

[0653] 18. Multicast transmission starts using multicast session and bearer. Initially, content is sent from content provider to UPF in unicast mode. UPF processes the received data (e.g., applies FEC, Athlon code) and sends them to NG-RAN node using IP multicast. Finally, NG-RAN node multicasts / broadcasts data using over-the-air multicast or unicast bearer.

[0654] Example 2.2 Unicast to Multicast / Broadcast Delivery Method Switching with Pre-Existing Sessions

[0655] In this example, both the multicast session and the session management context for the service exist, so once a delivery method switch is triggered, there is no need to create a new session or session management context.

[0656] Fig.11A and Fig. 11B A process according to an exemplary embodiment is schematically depicted. In particular, Fig.11A and Fig. 11B Unicast to multicast / broadcast delivery method switching in case of a pre-existing session is shown for the second architecture reference model.

[0657] The switching process is as follows:

[0658] 1. The UE performs the registration procedure according to [3].

[0659] 2. The UE and 5G core establish a unicast PDU session according to [3].

[0660] 3. Unicast transmission starts.

[0661] 4. Optionally, the UE periodically sends consumption reports about their unicast PDU sessions to the network. These reports can be used later by the network to trigger a delivery method switch. Since this step is optional, a delivery method switch can be triggered based on other criteria.

[0662] 5. At some point, the UE or NG-RAN or 5G Core or content server decides to switch the delivery method from multiple unicast sessions to a single multicast / broadcast session.

[0663] 6. Optionally, the content server requests a session from the SMF.

[0664] 7.SMF updates the pre-existing session based on the required parameters.

[0665] 8. Optionally, the SMF creates a new SM context or updates an existing SM context (if applicable).

[0666] 9. Optionally, the SMF may register modifications of the multicast session to the UDM.

[0667] 10. The updated session is announced to the network providing information such as the multicast IP address and port number.

[0668] 11.SMF sends a Namf_Communication_N1N2MessageTransfer message to AMF to request the message to be transferred to the NG-RAN node.

[0669] 12.AMF sends a Session Creation Request to the NG-RAN via the N2_PDU Session Request message. The session creation is later confirmed with the N2_PDU Session Response message.

[0670] 13.NG-RAN establishes the required resources.

[0671] 14. If the session is switched to multicast, the NG-RAN node joins the relevant multicast. Otherwise, if the delivery method is switched to broadcast, no such joining is required.

[0672] 15.AMF now sends a Nsmf_PDUSession_UpdateSMContext request to SMF, which is used to request to update the multicast session context with information from NG-RAN, and SMF confirms receipt with a Nsmf_PDUSession_UpdateSMContext response message.

[0673] 16.SMF updates the multicast session context with the information from NG-RAN.

[0674] 17. Multicast transmission starts using multicast session and bearer. Initially, content is sent from content provider to UPF in unicast mode. UPF processes the received data (e.g., applies FEC, Athlon code) and sends them to NG-RAN node using IP multicast. Finally, NG-RAN node multicasts / broadcasts data over the air using over-the-air multicast or unicast bearer.

[0675] Example 2.3 Multicast / Broadcast to Unicast Delivery Method Switching

[0676] In this example, the UE has already registered with the network and an active multicast session already exists. In addition, the UE for which the session handover is performed is not the last UE in the 5MBS group to receive the multicast context, so a new unicast session must be established.

[0677] Fig. 12A and Fig. 12B A process according to an exemplary embodiment is schematically depicted. In particular, Fig. 12A and Fig. 12B A multicast / broadcast to unicast delivery method switch is shown for the third architecture reference model.

[0678] The switching process is as follows:

[0679] 1. A multicast / broadcast session is in progress.

[0680] 2. At some point, the UE or NG-RAN or 5G core or content server decides to switch the UE’s multicast / broadcast session to unicast.

[0681] 3. Optionally, the content server requests a session from the SMF (for example if it is the content server that decides on the delivery method switch).

[0682] 4. Optionally, the network performs NF discovery for the new session.

[0683] 5.SMF creates a new PDU session.

[0684] 6.SMF creates a new session management context.

[0685] 7. Optionally, SMF requests that the new session be registered with UDM.

[0686] 8.SMF sends a Namf_Communication_N1N2MessageTransfer message to AMF to request the message to be transferred to the NG-RAN node.

[0687] 9.AMF sends a Session Creation Request to NG-RAN via N2_PDU Session Request message. The Session Creation is later confirmed with N2_PDU Session Response message.

[0688] 10.NG-RAN establishes the required unicast resources.

[0689] 11.AMF now sends a Nsmf_PDUSession_UpdateSMContext request to SMF requesting to update the new unicast session context with information from NG-RAN and SMF confirms receipt with a Nsmf_PDUSession_UpdateSMContext response message.

[0690] 12. Optionally, the SMF updates the unicast session context with information from the NG-RAN.

[0691] 13. Unicast transmission starts using multicast session and bearer. Content is sent from content provider to UPF. UPF processes received data (e.g. applies FEC, Athlon code) and sends them to NG-RAN node. Finally, NG-RAN node sends data over the air using air unicast bearer established in step 10.

[0692] 14. Optionally, if the handed over UE is the last UE in the 5MBS group, the NG-RAN node releases the multicast resources as they are no longer needed.

[0693] 15. Optionally, if the switched UE is the last UE in the 5MBS group, the network optionally deregisters, releases and deletes the multicast session.

[0694] Example 3: Additional and / or Alternative Solutions to the First Architecture Reference Model

[0695] This example is particularly similar to the reference in which MBSF and MBSU additional network functions are considered Figure 3B The first architecture reference model described is related.

[0696] Example 3.1 Flexible unicast to multicast delivery method switching in case of pre-existing MBS unicast session.

[0697] Fig.13A and Fig. 13B A process according to an exemplary embodiment is schematically depicted. In particular, Fig.13A and Fig. 13B A unicast to multicast delivery method switch in case of a pre-existing MBS unicast session is shown for the first architecture reference model. Dashed arrows are generally used to indicate optional steps.

[0698] The switching process is as follows:

[0699] 0. The availability of the multicast service is announced by the content server, for example, via application layer signaling. The announcement may provide information such as the multicast IP address and port number of the multicast group that the UE can join.

[0700] 1. The UE and 5GC establish an MBS unicast PDU session according to [3]. Unicast data transmission can begin and data can be exchanged between the content / application server and the UE. Optionally, the UE can periodically send consumption reports about their MBS unicast PDU sessions to the network. These reports may be used to trigger switching between unicast and multicast.

[0701] Step 2 shows three potential alternatives for triggering a switch from unicast to multicast in 5GS. Only one of them can trigger each switch, and the subsequent steps of the solution are shared. Step 2 of Example 3.1 generally corresponds to step 5 of Example 1.2, such as Fig. 8A and Figure 8B shown.

[0702] Alternative 1: RAN-triggered handover

[0703] This alternative assumes that the trigger for the handover is in the NG-RAN. This means that the unicast MBS session is delivered via over-the-air unicast and the NG-RAN decides to switch to over-the-air multicast. This may optionally also include a UE-originated trigger sent to the NG-RAN.

[0704] 2.1.a. to 2.1.c. show the set of request messages initiated by the NG-RAN that need to be forwarded by the network to modify an already established MBS Unicast PDU Session. Since the NG-RAN triggered the handover, it may have done so, for example due to mobility reasons, due to a consumption report sent by the UE in step 1, etc.

[0705] 2.1.a. Send N2_Session_Modification request from NG-RAN to M-AMF.

[0706] 2.1.b. Sending Nsmf_Session_ModificationRequest from M-AMF to MB-SMF in response to M-AMF receiving N2_Session_Modification request.

[0707] 2.1.c. Sending an N6mb-C session modification request from the MB-SMF to the MBSF in response to the MB-SMF receiving the Nsmf_Session_Modification request.

[0708] 2.1.d. Optional sending of MBS session notification from MBSF to content / application server - only required if the content server needs to be aware of the switch from unicast to multicast.

[0709] Alternative 2: MBSF-triggered handover

[0710] 2.2 This alternative assumes that the MBSF is the entity that decides to perform the switch from unicast to multicast once the MBS service has been initiated. The decision may be based on different optimization criteria (eg consumption reports, etc.).

[0711] Alternative 3: Content / application server triggered switching

[0712] 2.3 This alternative describes the possibility that the content / application server decides to switch from unicast to multicast.

[0713] 3MBSF updates include:

[0714] 3.a.MBSF uses Nsmf_PDUSession_Update request to request MB-SMF to update the UE session. MBSF can provide several parameters, such as SUPI, S-NSSAI, MBSID / TMGI, DNN, etc.

[0715] 3.b.MB-SMF responds with a Nsmf_PDUSession_Update response to confirm the update of the session and may provide its multicast IP address and port number for NG-RAN and other parameters.

[0716] 4. Optionally, MB-SMF may register the multicast session with UDM using the Nudm_UECM_Update message which may be acknowledged.

[0717] 5. MBSF and MBSU can exchange internal messages.

[0718] 6.MB-SMF sends a Namf_Communication_N1N2MessageTransfer message to M-AMF to request the message to be transferred to the NG-RAN node. The message may contain parameters such as the multicast IP address, port number, APN, NSAPI, etc. of the multicast MBS session. M-AMF may confirm this transfer.

[0719] 7: Session creation includes:

[0720] 7.a The M-AMF sends a session creation request to the NG-RAN via the N2_PDU Session Request message.

[0721] 7.b. The session creation is later confirmed by the NG-RAN to the M-AMF (after step 8) with an N2_PDU Session Response message which may include downlink tunnel information.

[0722] 8. The NG-RAN establishes the resources required by the UE by, for example, setting up the relevant bearers.

[0723] 9.NG-RAN nodes can join relevant multicast groups.

[0724] 10: Multicast session management context update includes:

[0725] 10.aM-AMF sends a Nsmf_PDUSession_UpdateSMContext request to MB-SMF, which is used to request to update the multicast session management context with information from NG-RAN (such as tunnel information).

[0726] 10.b.MB-SMF confirms receipt with the Nsmf_PDUSession_UpdateSMContext response message.

[0727] 11: Multicast session context update includes:

[0728] 11.a.MB-SMF may request MBSF via the N6mb-C interface to update the multicast session context with information from NG-RAN.

[0729] 11.b MBSF may confirm context updates via the same interface.

[0730] 12. Optionally, the MBSF may need to communicate internally with the MBSU regarding the modification of session parameters.

[0731] 13. Session modifications include:

[0732] 13.a.MB-SMF sends N4 session modification request to MB-UPF.

[0733] 13.b.MB-UPF then confirms the session update.

[0734] 14. Carry out data transfer, including:

[0735] 14.a. Initially, content is sent from the content provider to the MBSU.

[0736] 14.b. The MBSU processes the received data (eg, applies FEC, Athlon code, etc.).

[0737] 14.c. The MBSU forwards the multicast data (ie, the processed data) to the MB-UPF.

[0738] 14.d. The MB-UPF sends the forwarded data to the NG-RAN node using IP multicast.

[0739] 14.e. Finally, the NG-RAN node multicasts the data over the air using the over-the-air multicast bearer received by the UE.

[0740] Example 3.2 Flexible unicast to multicast delivery method switching in case of pre-existing MBS unicast session.

[0741] Fig.15A and Fig. 15B A process according to an exemplary embodiment is schematically depicted. In particular, Fig.15A and Fig. 15B A unicast to multicast delivery method switch in case of a pre-existing MBS unicast session is shown for the first architecture reference model. Dashed arrows are generally used to indicate optional steps.

[0742] In this example, the MBSF and NEF may be separate physical entities or may be located in one place.

[0743] The process described with respect to FIG. 15 is generally as described with respect to FIG. 13 , revised to, inter alia, update terminology.

[0744] The switching process is as follows:

[0745] 0. The availability of the multicast service is announced by the content server, for example via application layer signaling. The announcement may provide information such as the multicast IP address and port number of the multicast group that the UE can join. The UE and 5GC establish an MBS session using the 5GC separate service delivery method according to [3].

[0746] 1. MBS data transmission can start and data can be exchanged between the content / application server and the UE. Optionally, the UE can periodically send consumption reports about their MBS individual sessions to the network. These reports can be used to trigger switching between unicast and multicast delivery.

[0747] 2. Step 2 shows three potential alternatives for triggering a switch from unicast to multicast in 5GS. Only one of them can trigger each switch, and the subsequent steps of the solution are shared. Step 2 of Example 3.1 generally corresponds to step 5 of Example 1.2, such as Fig. 8A and Figure 8B shown.

[0748] Alternative 1: RAN-triggered handover

[0749] This alternative assumes that the trigger for the handover is in the NG-RAN. This means that the individual MBS session is delivered via PTP and the NG-RAN decides to switch to PTM. This may optionally also include a trigger originating from the UE sent to the NG-RAN.

[0750] 2.1.a. to 2.1.c. show the set of request messages initiated by the NG-RAN that need to be forwarded by the network to modify the MBS session via an already established separate delivery. Since the NG-RAN triggered the handover, it might have done so, for example due to mobility reasons like handover, due to the consumption report sent by the UE in step 1, etc.

[0751] 2.1.a. Send N2_Session_Modification request from NG-RAN to AMF.

[0752] 2.1.b. Sending a Nsmf_Session_Modification request from the AMF to the MB-SMF in response to the AMF receiving the N2_Session_Modification request.

[0753] 2.1.c. Sending an N6mb-C session modification request from the MB-SMF to the MBSF in response to the MB-SMF receiving the Nsmf_Session_Modification request.

[0754] 2.1.d. Optional sending of MBS session notification from MBSF to content / application server - only required if the content server needs to be aware of the switch from unicast to multicast.

[0755] Alternative 2: MBSF-triggered handover

[0756] 2.2 This alternative assumes that the MBSF is the entity that decides to perform the switch from unicast to multicast once the MBS service has been initiated. The decision may be based on different optimization criteria (eg consumption reports, etc.).

[0757] Alternative 3: Content / application server triggered switching

[0758] 2.3 This alternative describes the possibility that the content / application server decides to switch from unicast to multicast.

[0759] 3MBSF updates include:

[0760] 3.a.MBSF uses Nsmf_PDUSession_Update request to request MB-SMF to update the UE session. MBSF can provide several parameters, such as SUPI, S-NSSAI, MBSID / TMGI, DNN, etc.

[0761] 3.b.MB-SMF responds with a Nsmf_PDUSession_Update response to confirm the update of the session and may provide its multicast IP address and port number for NG-RAN and other parameters.

[0762] 4. Optionally, MB-SMF may register the multicast session with UDM using the Nudm_UECM_Update message which may be acknowledged.

[0763] 5.UPF session modifications include:

[0764] 5.a.MB-SMF sends N4 session modification request to MB-UPF.

[0765] 5.b.MB-UPF then confirms the session update.

[0766] 6.MB-SMF sends a Namf_Communication_N1N2MessageTransfer message to AMF to request the message to be transferred to the NG-RAN node. The message may contain parameters such as the multicast IP address, port number, APN, NSAPI, etc. of the multicast MBS session. AMF may confirm this transfer.

[0767] 7: Session creation includes:

[0768] 7.a.AMF sends an MBS Session Creation Request to NG-RAN via the N2 Session Request message.

[0769] 7.b. The MBS session creation is later confirmed by the NG-RAN to the AMF with an N2 Session Response message which may include downlink tunnel information (after step 8).

[0770] 8. The NG-RAN establishes the resources required by the UE by, for example, setting up the relevant bearers.

[0771] 9.NG-RAN nodes can join relevant multicast groups.

[0772] 10: Multicast session management context update includes:

[0773] 10.a.AMF sends a Nsmf_PDUSession_UpdateSMContext request to MB-SMF, which is used to request to update the multicast session management context with information from NG-RAN (e.g. tunnel information).

[0774] 10.b.MB-SMF confirms receipt with the Nsmf_PDUSession_UpdateSMContext response message.

[0775] 11: Multicast session context update includes:

[0776] 11.a. [Optional] MB-SMF may request MBSF to update the multicast session context (e.g. downlink tunnel information) with information from NG-RAN.

[0777] 11.b [Optional] MBSF may confirm the context update.

[0778] 12. Optionally, the MBSF may need to communicate internally with the MBSU regarding the modification of session parameters.

[0779] 13. The MBSF sends an MBS session start message to the AF.

[0780] 14. Carry out data transfer, including:

[0781] 14.a. Initially, content is sent from the content provider to the MBSU.

[0782] 14.b. The MBSU processes the received data (eg, applies FEC, Athlon code, etc.).

[0783] 14.c. The MBSU forwards the multicast data (ie, the processed data) to the MB-UPF.

[0784] 14.d. The MB-UPF sends the forwarded data to the NG-RAN node using the relevant tunnel.

[0785] 14.e. Finally, the NG-RAN node sends data over the air and can use the PTM bearer which is received by the UE.

[0786] Example 3.3 Multicast to Unicast Delivery Method Switching for the First Architecture Reference Model

[0787] In this example, there is a multicast session and a session management context for the service. This may have been initiated originally as a multicast session or may have been switched to a multicast session from a previous unicast session.

[0788] In this example, the MBSF and NEF may be separate physical entities or may be located in one place.

[0789] Fig.16A , Fig. 16B , Fig. 16C and Fig.16D A process according to an exemplary embodiment is schematically depicted. In particular, Fig.16A , Fig. 16B , Fig. 16C and Fig.16DThe shared MBS to separate MBS service delivery method switching for the first architecture reference model is shown, assuming a pre-existing shared MBS service delivery method. This pre-existing MBS session may have been directly established as an MBS session with 5GC shared MBS service delivery, or it may have been previously switched from 5GC separate MBS service delivery to shared delivery.

[0790] Fig.16A , Fig. 16B , Fig. 16C and Fig.16D The method in exemplifies switching for one UE, but multiple UEs can be switched from shared delivery to individual delivery simultaneously by applying the same principle and service set to a group of UEs.

[0791] The switching process is as follows:

[0792] 0. We assume that there is a shared MBS service delivery method.

[0793] 1. Step 2 shows three potential alternatives for triggering a switch from unicast to multicast in 5GS. Only one of them triggers each switch, and the subsequent steps of the solution are shared. Step 2 of Example 3.1 generally corresponds to step 5 of Example 1.2, such as Fig. 8A and Figure 8B shown.

[0794] Alternative 1: RAN-triggered handover

[0795] This alternative assumes that the trigger for handover is in the NG-RAN, so the NG-RAN can effectively make handover decisions based on UE consumption reports, handover requirements, resource availability, etc. In addition, when the RAN delivery method needs to be changed from PTM to PTP, the NG-RAN may need to be involved in the handover process itself.

[0796] 1.1.a. to 1.1.d. show the set of request messages initiated by NG-RAN that need to be forwarded by the network to modify the MBS session via an already established shared delivery. The forwarded messages may include SUPI, TMGI, MBS session ID, etc.

[0797] 1.1.a. Send N2_Session_Modification request from NG-RAN to AMF.

[0798] 1.1.b. Sending an Nsmf_Session_Modification request from the AMF to the MB-SMF in response to the AMF receiving the N2_Session_Modification request.

[0799] 1.1.c. Sending an Nmbs Session Modification Request from the MB-SMF to the MBSF in response to the MB-SMF receiving the Nsmf_Session_Modification Request.

[0800] 1.1.d. Optionally send an MBS session notification from the MBSF to the NEF, which then forwards it to the content / application server - this is only needed if the content server needs to be aware of the switch from a shared MBS session to a separate MBS session.

[0801] Alternative 2: MBSF-triggered handover

[0802] 1.2 This alternative assumes that the MBSF is the entity that decides to perform the switch from shared MBS service delivery to separate MBS service delivery. The decision may be based on different optimization criteria (eg consumption reports, UE population in a specific area, etc.).

[0803] Alternative 3: Content / application server triggered switching

[0804] 1.3 Alternative Solution Description The possibility that the content / application server decides to switch from shared MBS service delivery to separate MBS service delivery.

[0805] 2.a.MBSF sends an NsmfSessionUpdateRequest message to MB-SMF, which is used to request the UE to switch from shared delivery to separate delivery. MBSF can provide several parameters for updating MB-SMF, such as SUPI, S-NSSAI, MBSID / TMGI, DNN, etc.

[0806] 2.b. Once updated, MB-SMF responds with a NsmfSessionUpdateResponse.

[0807] 3. [Optional] MB-SMF may update the UE context registration in UDM using the Nudm_UECM_Update message which may be acknowledged by UDM.

[0808] 4. Session modifications include:

[0809] 4.a. MB-SMF sends an N4 session modification request including new tunnel information to MB-UPF.

[0810] 4.b.MB-UPF then confirms the session update.

[0811] 5.MB-SMF sends a Namf_Communication_N1N2MessageTransfer message to AMF to update AMF when transferring the message to the NG-RAN node.

[0812] 6.(6a) The AMF sends an N2 Session Request message to the NG-RAN to inform the RAN of the delivery method switch. The switch may also require the NG-RAN to adjust its resources by, for example, switching PTM delivery to PTP. (6b) After the NG-RAN resources can be set up, the message is later acknowledged by the NG-RAN with an N2 Session Response message.

[0813] 7. [Optional] When delivery switching involves a switch from PTM to PTP in the RAN, the NG-RAN may need to set up the required resources.

[0814] 8.(8a) AMF sends an NsmfSessionUpdateSMContext request to MB-SMF, which is used to request to update the MBS session context with information from NG-RAN, thereby updating the tunnel information used for separate delivery; (8b) MB-SMF confirms receipt with an NsmfSessionUpdateSMContextResponse message.

[0815] 9. [Optional] MB-SMF requests MBSF to update the individual MBS session context with the information from NG-RAN by Nmbs Session Update SM Context Request message, and MBSF confirms the context update with Nmbs Session Update SM Context Response.

[0816] 10. [Optional] MBSF and MBSU can exchange internal messages.

[0817] 11. The MBSF sends an MBS session start message to the AF.

[0818] 12. Carry out data transfer, including:

[0819] 12.a. Send IP multicast data from the content provider to the MBSU.

[0820] 12.b. The MBSU processes the received data (eg, applies FEC, Athlon code, etc.).

[0821] 12.c. The MBSU forwards the MBS data (i.e., processed data) to the MB-UPF via 5GC separate service delivery.

[0822] 12.d.MB-UPF sends the forwarded data to the NG-RAN node via separate delivery.

[0823] 12.e. Finally, the NG-RAN node sends the MBS data over the air using the PTP bearer received by the UE.

[0824] If there are no additional UEs left in an MBS session with shared delivery, the 5GC may decide to suspend or release the MBS session. Suspending an MBS session does not involve deleting the MBS session context in the 5GC NF to facilitate UEs joining the MBS session or switching to shared delivery in the future with reduced signaling; releasing an MBS session does delete the MBS session context from all entities in the 5GC. Outstanding NG-RAN resources for PTM delivery of the shared MBS session are released in both cases.

[0825] Alternative A: Suspension of shared MBS sessions

[0826] 13.a.MBSF sends an Nsmf session suspend request to MB-SMF, which is used to request to suspend the MBS session for shared delivery.

[0827] 14.a.MB-SMF sends a Namf session suspension request to AMF, which is used to request forwarding of the suspension request of the MBS session for shared delivery.

[0828] 15.a.1.AMF sends an N2 Session Suspend Request to the NG-RAN requesting the release of any outstanding PTM resources.

[0829] 15.a.2.The NG-RAN node sends an N2 Session Suspension Response message to the AMF, which is used to confirm the suspension of the shared MBS session.

[0830] 16.a. [Optional] The NG-RAN node may release any outstanding allocated resources to the shared MBS session for PTM delivery.

[0831] 17.a.AMF sends a Namf session suspension response message to MB-SMF, which is used to confirm the suspension of the shared MBS session.

[0832] 18.a.MB-SMF sends an Nsmf session suspension response message to MBSF, which is used to confirm the suspension of the shared MBS session.

[0833] Alternative B: Release of shared MBS session

[0834] 13.b. MBSF sends an Nsmf session release request to MB-SMF, which is used to request the release of the shared MBS session and deletion of related resources, which is then confirmed by MB-SMF.

[0835] 14.b.MB-SMF sends a Namf session release request to AMF, which is used to request the release of the shared MBS session and deletion of related resources, which is then confirmed by AMF.

[0836] 15.b.1.AMF sends an N2 session release request to NG-RAN, which is used to request the release of resources allocated to the shared MBS session.

[0837] 15.b.2.The NG-RAN node sends an N2 Session Release Response message to the AMF, which confirms the release of resources associated with the shared MBS session.

[0838] 16.b. [Optional] The NG-RAN may release outstanding allocated resources to the shared MBS session for PTM delivery.

[0839] 17.b.1.AMF sends an Nsmf Release SMContext request message to MB-SMF, which is used to request the release of the MBS session management context used for the shared MBS session.

[0840] 17.b.2.MB-SMF sends an Nsmf Release SMContext response message to AMF, which is used to confirm the release of the MBS session management context used for the shared MBS session.

[0841] 18.b.1.[Optional] MB-SMF sends an Nmbs Release SMContext request to MBSF, which is used to request the release of the MBS session management context used for the shared MBS session.

[0842] 18.b.2.MBSF may send an Nsmf Release SMContext response message to MB-SMF, which is used to confirm the release of the MBS session management context used for the shared MBS session.

[0843] 19.b.MB-SMF sends an N4 session release request to MB-UPF, which is used to request the release of the shared MBS session, which is confirmed by MB-UPF.

[0844] 20. [Optional] MBSF and MBSU may exchange internal messages.

[0845] 21. [Optional] MBSF may send an MBS Session End message to the content / application server, which may be forwarded by the NEF first before reaching the content / application server.

[0846] Fig.17 An example communication device is depicted according to an exemplary embodiment of the present disclosure.

[0847] The communication device (1700) may be at least one of a device for switching from a first data transmission mode to a second data transmission mode in a communication network, a NG-RAN node, a core node (or 5G core), a content provider, or a 5G network device.

[0848] like Fig.17 As shown in the non-limiting example of, the communication device (1700) may include at least one processor (1710) and a transceiver (1720). The transceiver (1720) may be configured to be controlled by at least one processor (1710) to run the method (or process) of the embodiment of the present disclosure. At least one processor (1710) may be configured to run the method (or process) of the embodiment of the present disclosure. At least one processor (1710) may be configured to control the transceiver (1720) to run the method (or process) of the embodiment of the present disclosure.

[0849] Acronyms

[0850] 3GPP Third Generation Partnership Project

[0851] 5GC 5G Core

[0852] 5GS 5G System

[0853] 5MBS 5G Multicast Broadcast Service

[0854] AF Application Function

[0855] AMF Access and Mobility Function (also known as M-AMF)

[0856] AN Access Network

[0857] AUSF authentication server function

[0858] BM-SC Broadcast Multicast Service Center

[0859] BMF broadcast and multicast function

[0860] BM-SC-C / U BM-SC control / user plane

[0861] CN Core Network

[0862] DN Data Network

[0863] eMBMS Enhanced MBMS

[0864] eNB Enhanced Node B

[0865] FEC Forward Error Correction

[0866] gNB Next Generation Node B

[0867] IIoT Industrial Internet of Things

[0868] IP Internet Protocol

[0869] MBMS Multimedia Broadcast Multicast Service

[0870] MBMS-GW MBMS Gateway

[0871] MBS Multicast / Broadcast Service

[0872] MBSF Multicast / Broadcast Service Function

[0873] MBSU Multicast / Broadcast Service User Plane

[0874] M-AMF Multicast Access and Mobility Function (also known as AMF)

[0875] MB-UPF Multicast / Broadcast User Plane Function

[0876] MB-SMF Multicast / Broadcast Session Management Function

[0877] MCE Multi-Cell / Multicast Coordination Entity

[0878] MME Mobility Management Entity

[0879] MNO Mobile Network Operator

[0880] MooD Multicast on Demand Operation

[0881] NEF Network Exposure Function

[0882] NG-RAN Next Generation RAN

[0883] NF Network Function

[0884] NFV Network Function Virtualization

[0885] NRFNF Repository Function

[0886] NSI Network Slicing Example

[0887] NSSF network slice selection function

[0888] PCF Policy Control Function

[0889] PDU Packet Data Unit

[0890] RAN Radio Access Network

[0891] S-NSSAI Single Network Slice Selection Auxiliary Information

[0892] SBA Service-Based Architecture

[0893] SD Slice Differentiator

[0894] SMF session management functions

[0895] SST Slice / Service Type

[0896] UDM Unified Data Management

[0897] UE User Equipment

[0898] UPF User Plane Function

[0899] V2X Vehicle to Everything

[0900] References

[0901] [1]3GPP TS 26.346, Multimedia Broadcast / Multicast Service (MBMS); Protocols and codecs; Release 12.

[0902] [2]3GPP TS 23.501,5G; System Architecture for the 5G System; Release16.

[0903] [3]3GPP TS 23.502, 5G; Procedures for the 5G System; Release 16.

[0904] [4]3GPP TS 29.531, 5G; 5G System; Network Slice Selection Services; Release 15.

[0905] The subject matter of [1]-[4] is incorporated herein by reference.

[0906] While preferred embodiments have been shown and described, it will be appreciated by those skilled in the art that various changes and modifications may be made without departing from the scope of the invention as defined in the appended claims and described above.

[0907] Attention is paid to all papers and documents which are filed concurrently with this application or filed prior to this specification in conjunction with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference.

[0908] All features disclosed in this specification (including any accompanying claims and drawings) and / or all steps of any method or process so disclosed may be combined in any combination except combinations of at least some of such features and / or steps that are mutually exclusive.

[0909] Unless expressly stated otherwise, each feature disclosed in this specification (including any accompanying claims and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose. Therefore, unless expressly stated otherwise, each feature disclosed is only an example of a generic series of equivalent or similar features.

[0910] The invention is not limited to the details of the foregoing embodiments. The invention extends to any novel feature or any novel combination of features disclosed in this specification (including any attached claims and drawings), or to any novel step or any novel combination of steps in any method or process disclosed in this manner.

Claims

1. A method performed by a next generation radio access network (NG-RAN) in a wireless communication network, the method comprising: receiving information from a content server regarding availability of a multicast service; In a first session, sending first data from the content server to a user equipment UE according to a first data transmission mode, wherein the first data transmission mode is a unicast transmission mode associated with separate delivery; Sending a session modification request message to an access and mobility management function, AMF, the session modification request message indicating switching from the first data transmission mode to a second data transmission mode, wherein the second data transmission mode is a multicast transmission mode associated with shared delivery; receiving a session request message from the AMF, where the session request message is used to create a second session in the second data transmission mode; establishing, for the UE, resources associated with a second session of the second data transmission mode; as well as In the second session, multicast data is sent to the UE.

2. The method according to claim 1, wherein: The information on the availability of the multicast service includes at least one of a multicast Internet Protocol (IP) address and a port number of the multicast group.

3. The method according to claim 1, further comprising: After establishing resources associated with the second session, sending a session response message to the AMF, the session response message including information about the downlink tunnel.

4. The method according to claim 3, further comprising: Based on the information about the downlink tunnel, the multicast data is received from a multicast broadcast user plane function MB-UPF.

5. A method performed by an access and mobility management function (AMF) in a wireless communication network, the method comprising: receiving information from a content server regarding availability of a multicast service; receiving a first session modification request message from a new generation radio access network NG-RAN, the first session modification request message indicating switching from a first data transmission mode to a second data transmission mode in a first session, wherein the first data transmission mode is a unicast transmission mode associated with individual delivery, and wherein the second data transmission mode is a multicast transmission mode associated with shared delivery; sending a second session modification request message to a multicast broadcast session management function MB-SMF in response to receiving the first session modification request message, wherein the second session modification request message indicates switching from the first data transmission mode to the second data transmission mode; as well as Send a session request message to the NG-RAN, where the session request message is used to establish a second session in the second data transmission mode.

6. The method according to claim 5, wherein: The information on the availability of the multicast service includes at least one of a multicast IP address and a port number of the multicast group.

7. The method according to claim 5, further comprising: A communication message transfer message is received from the MB-SMF, the communication message transfer message including at least one of a multicast IP address, a port number, an access point name APN, and a network service access point identifier NSAPI of the second session.

8. The method according to claim 5, further comprising: A session response message is received from the NG-RAN, the session response message including information about a downlink tunnel.

9. The method according to claim 8, further comprising: A session update request message is sent to the MB-SMF, where the session update request message includes the information about the downlink tunnel.

10. A new generation radio access network NG-RAN in a wireless communication network, the NG-RAN comprising: Transceiver; as well as at least one processor coupled to the transceiver, Wherein, the at least one processor is configured to: receiving information from a content server regarding the availability of a multicast service, In a first session, sending first data from the content server to a user equipment UE according to a first data transmission mode, wherein the first data transmission mode is a unicast transmission mode associated with separate delivery; sending a session modification request message to an access and mobility management function AMF, wherein the session modification request message indicates switching from the first data transmission mode to a second data transmission mode, wherein the second data transmission mode is a multicast transmission mode associated with shared delivery, receiving a session request message from the AMF, where the session request message is used to establish a second session in the second data transmission mode, establishing, for the UE, resources associated with a second session of the second data transmission mode, and In the second session, multicast data is sent to the UE.

11. The NG-RAN according to claim 10, wherein: The information on the availability of the multicast service includes at least one of a multicast Internet Protocol (IP) address and a port number of the multicast group.

12. The NG-RAN according to claim 10, wherein: The processor is further configured to: After establishing the resources associated with the second session, sending a session response message to the AMF, the session response message including information about the downlink tunnel; as well as Based on the information about the downlink tunnel, the multicast data is received from a multicast broadcast user plane function MB-UPF.

13. An access and mobility management function AMF in a wireless communication network, the AMF comprising: Transceiver; as well as at least one processor coupled to the transceiver, Wherein, the at least one processor is configured to: receiving information from a content server regarding availability of a multicast service; receiving a first session modification request message from a new generation radio access network NG-RAN, the first session modification request message indicating switching from a first data transmission mode to a second data transmission mode in a first session, wherein the first data transmission mode is a unicast transmission mode associated with individual delivery, and wherein the second data transmission mode is a multicast transmission mode associated with shared delivery; sending a second session modification request message to a multicast broadcast session management function MB-SMF in response to receiving the first session modification request message, wherein the second session modification request message indicates switching from the first data transmission mode to the second data transmission mode; and Send a session request message to the NG-RAN, where the session request message is used to establish a second session in the second data transmission mode.

14. The AMF according to claim 13, wherein: The information on the availability of the multicast service includes at least one of a multicast IP address and a port number of the multicast group.

15. The AMF according to claim 13, wherein: The processor is further configured to: receiving a communication message transfer message from the MB-SMF, the communication message transfer message including at least one of a multicast IP address, a port number, an access point name APN, and a network service access point identifier NSAPI of the second session; receiving a session response message from the NG-RAN, the session response message including information about a downlink tunnel; as well as A session update request message is sent to the MB-SMF, where the session update request message includes the information about the downlink tunnel.

Images