RAN Node Failure / Restart Detection and Restoration for Multicast MBS Sessions

Abstract

The present disclosure relates to a network node, a RAN node, and a method for detecting a failure / restart of a RAN node and for restoring a multicast session. A method in an SMF for detecting a failure and / or restart of a RAN node serving one or more UEs for a multicast session includes receiving a message from a network node indicating the failure and / or restart of the RAN node.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to PCT International Application No. PCT / CN2021 / 143933, filed December 31, 2021, entitled "NETWORK NODES AND METHODS THEREIN FOR FACILITATING MANAGEMENT OF MULTICAST / BROADCAST SERVICE SESSION," and PCT International Application No. PCT / CN2022 / 072074, filed January 14, 2022, entitled "RAN NODE FAILURE / RESTART DETECTION AND RESTORATION FOR MULTICAST MBS SESSION," both of which are incorporated herein by reference in their entireties.

[0002] The present disclosure relates to the field of communications, and in particular to a network node, a Radio Access Network (RAN) node, and a method for RAN node failure / restart detection and restoration for Multicast Broadcast Service (MBS) sessions. [Background technology]

[0003] Broadcast services with scheduled programming represent the premier communication service for today's society. Broadcast is a transport technology for delivering the same content to an unlimited number of devices with a specified quality of service without substantially increasing network capacity requirements, energy consumption, or costs. Cellular systems are typically used for unicast transmission. In this mode, a dedicated channel is established with each UE. In scenarios where a large number of users or devices consume the same data, the use of broadcast or multicast transmission can provide significant capacity gains and ensure a cost-effective and high-quality delivery mechanism.

[0004] In unicast transmission, the required radio resources grow linearly with the number of UEs receiving the same data. Resource allocation efficiency is improved by simultaneous transmission of data to a set of users. Through broadcast services, all users receive the same information within a service area. In multicast services, users must subscribe to a particular service before they can receive the information. While broadcast communication is unidirectional, multicast users can establish a return channel that allows interactivity with the network. This return channel can also be used to subscribe to desired services.

[0005] While existing technologies are mature, current broadcast systems have serious limitations when serving mobile users or users located in areas with complex mountainous terrain and poor signal quality. To overcome these limitations, the 3rd Generation Partnership Project (3GPP) 5G standards included a work item for Release 17 to support 5G multicast / broadcast services. This will bring the greater flexibility and efficiency of 5G networks to broadcast services to significantly improve user experience while reducing operating costs. Furthermore, 5G broadcast / multicast services can complement traditional broadcast technologies, which have severe deficiencies in some scenarios, such as mobility or users in remote areas. Summary of the Invention

[0006] According to a first aspect of the present disclosure, there is provided a method in a Session Management Function (SMF) for restoring a multicast session for one or more UEs served by a RAN node that has experienced a failure and / or re-initiation. The method includes receiving a message from a network node indicating a RAN node failure and / or re-initiation of the RAN node, determining one or more UEs that joined the multicast session and that have been affected by the RAN node failure and / or re-initiation, and, in response to detecting the RAN node failure and / or re-initiation, triggering establishment of associated resources at the RAN node via an Access and Mobility Management Function (AMF) to receive multicast session data from either a UPF for individual delivery or a Multicast-Broadcast User Plane Function (MB-UPF) for shared delivery to restore the multicast session for the affected one or more UEs.

[0007] In some embodiments, the network node comprises at least one of an Access and Mobility Management Function (AMF), a User Plane Function (UPF), and a Multicast / Broadcast Session Management Function (MB-SMF). In some embodiments, the messages include: an Nsmf_PDUSession_UpdateSMContext request message sent from the AMF for a Protocol Data Unit (PDU) session associated with one of the UEs; a first message for one or more UEs and / or one or more PDU sessions, where the first message is a request message sent from the AMF to request for a service operation provided by the SMF that is not specified in any of 3rd Generation Partnership Project (3GPP) Technical Specification (TS) 23.502, V17.3.0 or previous releases; and a second message for a list of one or more UEs and / or a list of one or more PDU sessions, where the second message is a request message sent from the AMF to request for a service operation provided by the SMF that is not specified in any of 3rd Generation Partnership Project (3GPP) Technical Specification (TS) 23.502, V17.3.0 or previous releases. the second message is an event notification message from the AMF for notifying the SMF of a RAN node failure and / or re-start event; a third message for a PDU session, where the third message is a session report message from the UPF for reporting the RAN node failure and / or re-start; a fourth message for a node-level event, where the fourth message is a node report message from the UPF for reporting the RAN node failure and / or re-start; and a fifth message for a multicast session, where the fifth message is sent from an MB-SMF associated with the multicast session.

[0008] In some embodiments, the first message indicates one of a single UE and / or a single PDU session affected by the failure and / or re-initiation of the RAN node, and a list of one or more UEs and / or a list of one or more PDU sessions affected by the failure and / or re-initiation of the RAN node. In some embodiments, the second message indicates one of a Communication-Failure-Report event and an AMF event not specified in any of 3GPP TS 23.502, V17.3.0 or earlier releases, or in any of 3GPP TS 29.518 V17.4.0 or earlier releases. In some embodiments, when the message comprises a second message, the method further includes, before the step of receiving the message, sending to the AMF a message to subscribe to the event. In some embodiments, the message to subscribe to the event comprises at least one of one or more identifiers (IDs) of the UEs or an “Any UE” indication, one or more area identifiers, a Network Function (NF) service consumer service instance ID, and an authority of resource Uniform Resource Identifier (URI). In some embodiments, the event comprises at least one of a RAN / Non-Access Stratum (NAS) release code, one or more UE IDs, one or more PDU session IDs, and an NG-RAN restart or failure indication.

[0009] In some embodiments, the third message is a Packet Forwarding Control Protocol (PFCP) Session Report message comprising a Tunnel Endpoint ID (TEID) and an Internet Protocol (IP) address associated with the failed RAN node. In some embodiments, the fourth message is a PFCP Node Report message comprising an IP address associated with the failed RAN node. In some embodiments, the fifth message is an Nmbsmf_MBSSession_ContextStatusNotify message comprising an indicator indicating the failure and / or re-initiation of the RAN node and / or the ID of the RAN node.

[0010] According to a second aspect of the present disclosure, there is provided a method in an SMF for restoring a multicast session for one or more UEs served by a RAN node that has experienced a failure and / or re-initiation, the method including, in response to detecting the failure and / or re-initiation of the RAN node, triggering establishment of associated resources at the RAN node to receive multicast session data from either a UPF for individual delivery or a Multicast-Broadcast User Plane Function (MB-UPF) for shared delivery to restore the multicast session for at least one of the one or more UEs.

[0011] In some embodiments, the triggering step of establishing associated resources at the RAN node includes sending a sixth message to the RAN node via the AMF, causing the RAN node to initiate establishment of associated resources for the multicast session. In some embodiments, the sixth message comprises an indicator indicating a failure and / or re-initiation of the RAN node and / or an ID of the RAN node. In some embodiments, prior to the triggering step of establishing associated resources at the RAN node, the method further includes determining one or more UEs that have joined the multicast session and that are affected by the failure and / or re-initiation of the RAN node. In some embodiments, the determining step of the one or more UEs includes at least one of determining one or more UEs indicated in a received message from the AMF, where the received message further indicates a failure and / or re-initiation of the RAN node, and retrieving one or more UEs having the same IP address at a tunnel endpoint for a downlink tunnel at the RAN node to receive the multicast session data when the RAN failure or re-initiation is reported by the UPF.

[0012] In some embodiments, the method further includes sending a request message to the AMF to request the AMF to page one or more UEs to place the UEs in a CM-CONNECTED mode, the request message comprising an indicator indicating a failure and / or a restart of the RAN node; and receiving a response message from the AMF to indicate which of the one or more UEs are in the CM-CONNECTED mode. In some embodiments, prior to the step of triggering establishing associated resources at the RAN node, the method further includes receiving a fifth message from the MB-SMF indicating the detected failure and / or re-start of the RAN node and an identity of the RAN node, sending a request message to a Network Repository Function (NRF) to discover a list of AMFs that have association with the RAN node, receiving a response message from the NRF including the list of AMFs, selecting an AMF from the list of AMFs, sending a request message to the AMF to query one or more UEs affected by the failure and / or re-start of the RAN node and / or to request the AMF to page one or more UEs, wherein the request message comprises an indicator indicating the failure and / or re-start of the RAN node and / or an identity of the RAN node, and receiving a response message from the AMF comprising an acceptance of the one or more UEs and / or the paging. In some embodiments, the failure and / or re-start of the RAN node is detected by the SMF by the method of any of the first aspects.

[0013] According to a third aspect of the present disclosure, there is provided a first network node comprising: a processor; and a memory storing instructions that, when executed by the processor, cause the processor to perform a method of either the first or second aspect. In some embodiments, the first network node comprises an SMF.

[0014] According to a fourth aspect of the present disclosure, there is provided a first network node, comprising: a receiving module configured to receive, from the network node, a message indicating a failure and / or re-initiation of a RAN node; and a triggering module configured to, in response to detecting the failure and / or re-initiation of the RAN node, trigger establishment of associated resources at the RAN node to receive multicast session data from either a UPF for individual delivery or a MB-UPF for shared delivery to restore the multicast session for at least one of the one or more UEs.

[0015] According to a fifth aspect of the present disclosure, there is provided a method in an AMF for facilitating a network node detecting a failure and / or re-initiation of a RAN node serving one or more UEs for a multicast session, the method including receiving, from the RAN node, a seventh message reporting the failure and / or re-initiation of the RAN node, and transmitting, to the network node, a message indicating the failure and / or re-initiation of the RAN node in response to the received seventh message.

[0016] In some embodiments, the network node comprises at least one of an SMF and an MB-SMF. In some embodiments, the messages comprise at least one of: an Nmbsmf_MBSSession_ContextUpdate request message sent to the MB-SMF for the multicast session, an Nsmf_PDUSession_UpdateSMContext request message sent to the SMF for a PDU session associated with one of the UEs, a first message for one or more UEs and / or one or more PDU sessions, where the first message is a request message sent to the SMF to request for a service operation provided by the SMF that is not specified in 3GPP TS23.502, V17.3.0 or any of its previous releases, and a second message for a list of one or more UEs and / or a list of one or more PDU sessions, where the second message is an event notification message from the AMF to the SMF to notify the SMF of a RAN node failure and / or re-start event.

[0017] In some embodiments, the Nmbsmf_MBSSession_ContextUpdate request message indicates at least one of an ID of a multicast session and an ID of a RAN node that experienced a re-initiation and / or failure. In some embodiments, the first message indicates one of a single UE and / or a single PDU session affected by the RAN node failure and / or re-initiation and a list of one or more UEs and / or one or more PDU sessions affected by the RAN node failure and / or re-initiation. In some embodiments, the second message indicates one of a communication failure reporting event and an AMF event not specified in 3GPP TS 23.502, V17.3.0 or any of its previous releases, or in 3GPP TS 29.518 V17.4.0 or any of its previous releases. In some embodiments, when the message comprises a second message, the method further includes, before the step of sending the message, receiving a message for subscribing to the event from the SMF, and before the step of sending the message, the method further includes determining the SMF as a destination that should be notified of the event based at least on the received message for subscribing to the event.

[0018] In some embodiments, the message to subscribe to the event comprises at least one of: one or more UE IDs or an “any UE” indication, one or more area identifiers, an NF service consumer service instance Id, and an authority of resource URI. In some embodiments, the event comprises at least one of: a RAN / NAS release code, one or more UE IDs, one or more PDU session IDs, and an NG-RAN restart or failure indication. In some embodiments, the seventh message comprises at least one of an NG Setup Request message and an NG Reset Request message.

[0019] In some embodiments, before the step of receiving the seventh message, the method further comprises receiving an eighth request message from the RAN node requesting to establish a shared distribution towards the RAN node for a multicast session, the eighth request message comprising an N2 container, the N2 container comprising an ID of the RAN node that experienced the failure and / or re-initiation, and further comprising a transport IP address when multicast transport is used, or N3mb tunnel endpoint information when unicast transport is used; and, based at least on the eighth request message, instructing the MB-SMF to The method further includes transmitting a ninth request message requesting establishment of shared distribution towards the RAN node for the multicast session, wherein the ninth request message comprises an ID of the RAN node and an N2 container inserted by the AMF; receiving a ninth response message from the MB-SMF indicating whether the shared distribution has been successfully established and / or indicating information for establishing the shared distribution; and transmitting an eighth response message to the RAN node indicating whether the shared distribution has been successfully established and / or indicating information for establishing the shared distribution based at least on the ninth response message.

[0020] In some embodiments, the eighth request message is an N2 MBS Session Request message, the eighth response message is an N2 MBS Session Response message, the ninth request message is an Nmbsmf_MBSSession_ContextUpdate Request message, and the ninth response message is an Nmbsmf_MBSSession_ContextUpdate Response message.

[0021] According to a sixth aspect of the present disclosure, there is provided a method in an AMF for facilitating an SMF restoring a multicast session for one or more UEs served by a RAN node that has experienced a failure and / or re-initiation, the method including forwarding a sixth message from the SMF to the RAN node to cause the RAN node to establish associated resources for receiving multicast session data from either a UPF for individual delivery or a MB-UPF for shared delivery to restore the multicast session for at least one of the one or more UEs.

[0022] In some embodiments, the sixth message comprises an indicator indicating a failure and / or a re-initiation of the RAN node and / or an ID of the RAN node. In some embodiments, prior to the step of forwarding the sixth message, the method further includes receiving, from the SMF, a request message to request the AMF to page one or more UEs to place these UEs in a CM-CONNECTED mode, the request message comprising an indicator indicating a failure and / or a re-initiation of the RAN node, performing a paging procedure for the one or more UEs, and sending, based at least on a result of the paging procedure, to the SMF a response message to indicate which of the one or more UEs are in the CM-CONNECTED mode. In some embodiments, before the step of forwarding the sixth message, the method further includes receiving, from the SMF, a request message for querying one or more UEs affected by the failure and / or re-initiation of the RAN node and / or for requesting the AMF to page one or more UEs, wherein the request message comprises an indicator indicating the failure and / or re-initiation of the RAN node and / or an ID of the RAN node; determining one or more UEs based at least on the ID of the RAN node; performing a paging procedure for the determined one or more UEs; and sending, to the SMF, a response message comprising one or more UEs and / or an acceptance of the paging based at least on a result of the paging procedure.

[0023] According to a seventh aspect of the present disclosure, there is provided a second network node comprising: a processor; and a memory storing instructions that, when executed by the processor, cause the processor to perform the method of any of the fifth or sixth aspects. In some embodiments, the second network node comprises an AMF.

[0024] According to an eighth aspect of the present disclosure, a second network node is provided. The second network node comprises: a receiving module configured to receive, from the RAN node, a seventh message reporting a failure and / or re-initiation of the RAN node; and a transmitting module configured to transmit, in response to the received seventh message, a message indicating the failure and / or re-initiation of the RAN node to the network node. Additionally or alternatively, the second network node comprises a forwarding module configured to forward a sixth message from the SMF to the RAN node to cause the RAN node to establish associated resources for receiving multicast session data from either a UPF for individual delivery or a MB-UPF for shared delivery to restore the multicast session for at least one of the one or more UEs. In some embodiments,

[0025] According to a ninth aspect of the present disclosure, there is provided a method in an MB-SMF for restoring a multicast session for one or more UEs served by a RAN node that has experienced a failure and / or re-initiation, the method including: receiving, from a network node, a message indicating the failure and / or re-initiation of the RAN node; and, in response to receiving the message indicating the failure and / or re-initiation of the RAN node, triggering establishment of associated resources at the RAN node to receive multicast session data from an MB-UPF for shared distribution to restore the multicast session for at least one of the one or more UEs.

[0026] In some embodiments, the network node comprises at least one of an AMF and an MB-UPF. In some embodiments, the message comprises at least one of: an Nmbsmf_MBSSession_ContextUpdate request message sent from the AMF for a multicast session; a tenth message for the multicast session, the tenth message being a session report message from the MB-UPF for reporting a RAN node failure and / or re-initiation; and an eleventh message for a node-level event, the eleventh message being a node report message from the MB-UPF for reporting a RAN node failure and / or re-initiation. In some embodiments, the Nmbsmf_MBSSession_ContextUpdate request message indicates at least one of an ID of the multicast session and an ID of the RAN node that experienced the re-initiation and / or failure. In some embodiments, the tenth message is a PFCP session report message indicating a TEID and / or an IP address of the RAN node. In some embodiments, the tenth message is a PFCP Node Report message comprising an IP address associated with the failed RAN node.

[0027] In some embodiments, before the step of receiving the message, the method further comprises receiving a ninth request message from the AMF requesting to establish shared distribution towards the RAN node for the multicast session, the ninth request message comprising an ID of the RAN node inserted by the AMF and an N2 container provided by the RAN node, the N2 container comprising the ID of the RAN node and further comprising a transport IP address when multicast transport is used, or N3mb tunnel endpoint information when unicast transport is used; and sending the ninth request message to the MB-UPF. and configuring the N3mb tunnel endpoint information when a unicast transport is used, or when a unicast transport is used, so that the MB-UPF can use the transport IP address, or the IP address in the N3mb tunnel endpoint indicated by the N3mb tunnel endpoint information, to probe the liveness of the RAN node; storing the AMF in the context for the multicast session; and sending a ninth response message to the AMF indicating whether the shared distribution has been successfully established and / or indicating information for establishing the shared distribution based at least on a result of the configuring to the MB-UPF.

[0028] In some embodiments, after receiving the ninth request message, the method further includes establishing a mapping between IDs of the RAN nodes and tunnels to the RAN nodes for the multicast session. In some embodiments, after receiving the message, the method further includes determining tunnels affected by the RAN node failure and / or re-initiation based at least on the mapping between IDs of the RAN nodes and tunnels, and sending a message to the MB-UPF to release the tunnels.

[0029] In some embodiments, the ninth request message is an Nmbsmf_MBSSession_ContextUpdate request message and the ninth response message is an Nmbsmf_MBSSession_ContextUpdate response message.

[0030] According to a tenth aspect of the present disclosure, there is provided a method in a MB-SMF for restoring a multicast session for one or more UEs served by a RAN node that has experienced a failure and / or re-initiation, the method including, in response to detecting the failure and / or re-initiation of the RAN node, triggering establishment of associated resources at the RAN node for receiving multicast session data from an MB-UPF for shared distribution to restore the multicast session for at least one of the one or more UEs.

[0031] In some embodiments, the step of triggering the one or more tunnels to be established includes sending a notification message to an SMF associated with the RAN node for the multicast session to notify the SMF of the failure and / or re-initiation of the RAN node. In some embodiments, the notification message comprises at least one of an ID of the RAN node and an indication of the failure and / or re-initiation of the RAN node. In some embodiments, the failure and / or re-initiation of the RAN node is detected by the MB-SMF by the method of any of the ninth aspects.

[0032] According to an eleventh aspect of the present disclosure, there is provided a third network node comprising: a processor; and a memory storing instructions that, when executed by the processor, cause the processor to perform the method of any of the ninth or tenth aspects. In some embodiments, the third network node comprises a MB-SMF.

[0033] According to a twelfth aspect of the present disclosure, there is provided a third network node, comprising: a receiving module configured to receive, from the network node, a message indicating a failure and / or re-initiation of the RAN node; Additionally or alternatively, the third network node comprises a triggering module configured to, in response to detecting the failure and / or re-initiation of the RAN node, trigger establishment of associated resources at the RAN node to receive multicast session data from the MB-UPF for shared distribution to restore the multicast session for at least one of the one or more UEs.

[0034] According to a thirteenth aspect of the present disclosure, there is provided a method in a RAN node for facilitating the network node detecting a failure and / or re-initiation of a RAN node serving one or more UEs for a multicast session, the method including transmitting, to the network node, a seventh message reporting the failure and / or re-initiation of the RAN node.

[0035] In some embodiments, the network node is an AMF. In some embodiments, the seventh message comprises at least one of an NG Setup Request message and an NG Reset Request message. In some embodiments, before receiving the seventh message, the method further includes sending an eighth request message to the AMF requesting establishment of shared distribution towards the RAN node for the multicast session, and receiving an eighth response message from the AMF indicating whether the shared distribution was successfully established and / or indicating information for establishing the shared distribution. In some embodiments, the method further includes subscribing to multicast transport distribution for the multicast session by using the received information in the eighth response message. In some embodiments, the eighth request message comprises an ID of the RAN node. In some embodiments, the eighth request message is an N2 MBS Session Request message, and the eighth response message is an N2 MBS Session Response message.

[0036] According to a fourteenth aspect of the present disclosure, there is provided a RAN node, comprising: a processor; and a memory storing instructions that, when executed by the processor, cause the processor to perform any of the methods of the thirteenth aspect.

[0037] According to a fifteenth aspect of the present disclosure, there is provided a RAN node, comprising: a transmitting module configured to transmit a seventh message to a network node, the seventh message reporting a failure and / or a re-initiation of the RAN node.

[0038] According to a sixteenth aspect of the present disclosure, a computer program comprising instructions that, when executed by at least one processor, cause the at least one processor to perform any of the methods of the first, second, fifth, sixth, ninth, tenth, and thirteenth aspects.

[0039] According to a seventeenth aspect of the present disclosure, a carrier comprising the computer program of the sixteenth aspect, in some embodiments the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium.

[0040] According to an eighteenth aspect of the present disclosure, there is provided a communication system for maintaining a multicast session, comprising: a first network node according to the third or fourth aspect; a second network node according to the seventh or eighth aspect; a third network node according to the eleventh or twelfth aspect; and a RAN node according to the fourteenth or fifteenth aspect.

[0041] The above and other features of the present disclosure will become more fully apparent from the following description and appended claims, taken in conjunction with the accompanying drawings, in which: The present disclosure will be described with additional specificity and detail through the use of the accompanying drawings, with the understanding that these drawings illustrate only some embodiments in accordance with the present disclosure and therefore should not be considered limiting of its scope. [Brief explanation of the drawings]

[0042] [Figure 1] FIG. 1 illustrates an example delivery method for an MBS session to which RAN node failure / restart detection and / or restoration according to some embodiments of the present disclosure is applicable. [Figure 2] FIG. 1 illustrates an example communication network in which RAN node failure / restart detection and / or restoration according to some embodiments of the present disclosure are applicable. [Figure 3] FIG. 1 illustrates another example communication network in which RAN node failure / restart detection and / or restoration according to some embodiments of the present disclosure are applicable. [Figure 4] FIG. 1 illustrates an example user plane data transmission to which RAN node failure / restart detection and / or restoration according to some embodiments of the present disclosure is applicable. [Figure 5A]FIG. 10 illustrates an example procedure for a UE joining a multicast session, where RAN node failure / restart detection and / or restoration is applicable, according to some embodiments of the present disclosure. [Figure 5B] FIG. 10 illustrates an example procedure for a UE joining a multicast session, where RAN node failure / restart detection and / or restoration is applicable, according to some embodiments of the present disclosure. [Figure 6] FIG. 10 illustrates an example procedure for establishing share distribution towards an NG-RAN node, where RAN node failure / restart detection and / or restoration is applicable, according to some embodiments of the present disclosure. [Figure 7A] FIG. 1 illustrates an example MBS session activation procedure to which RAN node failure / restart detection and / or restoration according to some embodiments of the present disclosure is applicable. [Figure 7B] FIG. 1 illustrates an example MBS session activation procedure to which RAN node failure / restart detection and / or restoration according to some embodiments of the present disclosure is applicable. [Figure 8] FIG. 10 illustrates an example procedure for GTP-U error indication from a 5G-AN, where RAN node failure / restart detection and / or restoration is applicable, according to some embodiments of the present disclosure. [Figure 9] FIG. 10 illustrates an example NG reset procedure and an example NG setup procedure to which RAN node failure / restart detection and / or restoration according to some embodiments of the present disclosure are applicable. [Figure 10] FIG. 1 illustrates an example procedure for establishing share distribution towards an NG-RAN node, in accordance with some embodiments of the present disclosure. [Figure 11] FIG. 1 illustrates several example methods for detecting a failure and / or re-initiation of a RAN node at a CP, in accordance with some embodiments of the present disclosure. [Figure 12]FIG. 1 illustrates several example methods for detecting failure and / or re-initiation of a RAN node in a UP, in accordance with some embodiments of the present disclosure. [Figure 13] FIG. 1 illustrates an example procedure for SMF-initiated multicast MBS session restoration, according to some embodiments of the present disclosure. [Figure 14] FIG. 1 illustrates an example procedure for MB-SMF initiated multicast MBS session restoration, according to some embodiments of the present disclosure. [Figure 15] 1 is a flowchart of an exemplary method in an SMF for detecting a failure and / or re-initiation of a RAN node according to one embodiment of the present disclosure. [Figure 16] 10 is a flowchart of an example method in an SMF for restoring a multicast session for one or more UEs in accordance with one embodiment of the present disclosure. [Figure 17] 1 is a flowchart of an example method in an AMF for facilitating a network node detecting a failure and / or re-initiation of a RAN node, according to one embodiment of the present disclosure. [Figure 18] 1 is a flowchart of an example method in an AMF for facilitating an SMF restoring a multicast session for one or more UEs according to one embodiment of the present disclosure. [Figure 19] 1 is a flowchart of an exemplary method in an MB-SMF for detecting a failure and / or re-initiation of a RAN node according to one embodiment of the present disclosure. [Figure 20] 1 is a flowchart of an example method in an MB-SMF for restoring a multicast session for one or more UEs, according to one embodiment of the present disclosure. [Figure 21] 1 is a flowchart of an example method in a RAN node for facilitating a network node detecting a failure and / or re-initiation of the RAN node, in accordance with one embodiment of the present disclosure. [Figure 22]FIG. 2 illustrates a schematic diagram of an embodiment of a configuration that may be used in a network node and / or a UE, in accordance with an embodiment of the present disclosure. [Figure 23] FIG. 2 is a block diagram of an exemplary first network node according to one embodiment of the present disclosure. [Figure 24] FIG. 2 is a block diagram of an exemplary second network node, according to one embodiment of the present disclosure. [Figure 25] FIG. 10 is a block diagram of an exemplary third network node according to one embodiment of the present disclosure. [Figure 26] FIG. 1 is a block diagram of an exemplary RAN node, according to one embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0043] The present disclosure will be described below with reference to the embodiments shown in the accompanying drawings. However, it should be understood that these descriptions are provided for illustrative purposes only and not to limit the present disclosure. Furthermore, in the following, descriptions of known structures and techniques are omitted so as not to unnecessarily obscure the concepts of the present disclosure.

[0044] Those skilled in the art will appreciate that the term "exemplary" is used herein to mean "illustrative" or "serving as an example," and does not imply that a particular embodiment is preferred over another, or that a particular feature is essential. Similarly, the terms "first" and "second," and similar terms, are used merely to distinguish one particular instance of an item or feature from another, and do not dictate a particular order or configuration unless the context clearly dictates otherwise. Furthermore, the term "step," as used herein, is intended to be synonymous with "operation" or "action." The description herein of a sequence of steps does not imply that these operations must be performed in a particular order, or even that these operations be performed in any order, unless the context or details of the described operations clearly dictate otherwise.

[0045] Conditional language used herein, such as "can," "might," "may," "for example," and the like, unless expressly stated otherwise or understood otherwise within the context in which it is used, is intended to generally convey that some embodiments include certain features, elements, and / or conditions, but not others. Thus, such conditional language generally does not imply that features, elements, and / or conditions are in any way required for one or more embodiments, or that one or more embodiments necessarily include logic for determining, with or without author input or prompts, whether these features, elements, and / or conditions are included or should be implemented in any particular embodiment. Additionally, the term "or," when used to connect, for example, a list of elements, is used in its inclusive sense (and not its exclusive sense), such that "or" refers to one, some, or all of the elements in the list. Furthermore, the term "each," as used herein, in addition to having its ordinary meaning, can refer to any subset of the set of elements to which the term "each" applies.

[0046] The term "based on" should be read as "based at least in part on." The terms "one embodiment" and "an embodiment" should be read as "at least one embodiment." The term "another embodiment" should be read as "at least one other embodiment." Other provisions, both explicit and implicit, may be included below. Additionally, unless otherwise specified, phrases such as "at least one of X, Y, and Z" should generally be understood with the context in which they are used to convey that the item, term, etc. can be either X, Y, or Z, or a combination thereof.

[0047] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit example embodiments. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms unless the context clearly dictates otherwise. It will be further understood that the terms "comprises," "comprising," "has," "having," "includes," and / or "including," as used herein, specify the presence of stated features, elements, and / or components, etc., but do not exclude the presence or addition of one or more other features, elements, components, and / or combinations thereof. It will also be understood that the terms "connect(s)," "connecting," "connected," and the like, as used herein, only mean that there is an electrical or communication connection between two elements, and that they may be connected either directly or indirectly, unless expressly stated otherwise.

[0048] Of course, the present disclosure may be carried out in other specific ways than those described herein without departing from the scope and essential characteristics of the present disclosure. One or more of the specific processes described below may be carried out in any electronic device including one or more appropriately configured processing circuits, which may, in some embodiments, be incorporated into one or more application-specific integrated circuits (ASICs). In some embodiments, these processing circuits may comprise one or more microprocessors, microcontrollers, and / or digital signal processors, or variations thereof, programmed with appropriate software and / or firmware to perform one or more of the above-described operations. In some embodiments, these processing circuits may comprise customized hardware to perform one or more of the above-described functions. The present embodiments, therefore, are to be considered in all respects as illustrative and not restrictive.

[0049] Although several embodiments of the present disclosure are illustrated in the accompanying drawings and described in the following detailed description, it should be understood that the present disclosure is not limited to the disclosed embodiments, but instead is capable of numerous rearrangements, modifications, and substitutions without departing from the present disclosure as set forth and defined in the claims.

[0050] Furthermore, it should be noted that while the following description of some embodiments of the present disclosure is provided in the context of 5G New Radio (5G NR), the present disclosure is not limited thereto. Indeed, as long as RAN node failure and / or reinitiation detection and / or multicast session restoration are involved, the inventive concepts of the present disclosure may be applicable to any suitable communication architecture, such as Global System for Mobile Communications (GSM) / General Packet Radio Service (GPRS), Enhanced Data Rates for GSM Evolution (EDGE), Code Division Multiple Access (CDMA), Wideband CDMA (WCDMA), Time Division Synchronous CDMA (TD-SCDMA), CDMA2000, Worldwide Interoperability for Microwave Access (WiMAX), Wireless Fidelity (Wi-Fi), Long Term Evolution (LTE), etc. Accordingly, those skilled in the art can readily appreciate that terms used herein may also refer to their equivalents in any other infrastructure. For example, the term "user equipment" or "UE" as used herein may refer to a mobile device, a mobile terminal, a mobile station, a user device, a user terminal, a wireless device, a wireless terminal, an IoT device, a vehicle, or any other equivalent. In another example, the term "network node" as used herein may refer to or comprise a base station, a base transceiver station, an access point, a hotspot, a Node B (NB), an Evolved Node B (eNB), a gNB, a network element, a network function, or any other equivalent.

[0051] Additionally, the following documents are incorporated herein by reference in their entirety: - 3GPP TS23.007 V17.2.0(2021-09), 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminal; Restoration Procedures; (Release 17), - 3GPP TS23.247 V17.1.0(2021-12), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture Extensions for 5G Multicast Broadcast Services; Stage 2 (Release 17); - 3GPP TS23.527 V17.1.0(2021-06), 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminal; 5G System; Restoration Procedures (Release 17), - 3GPP TS38.413 V16.8.0(2021-12), 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NG-RAN; NG Application Protocol (NGAP) (Release 16), and - IETF Request For Comment (RFC) 4960, September 2007, Stream Control Transmission Protocol.

[0052] As specified in 3GPP TS23.247 v17.1.0, the term "multicast MBS session" refers to an MBS session for delivering multicast communication services. A multicast MBS session is characterized by the content to be sent, by a list of UEs that can receive the service, and optionally by a multicast area to which the service should be distributed.

[0053] 3GPP TS23.247 v17.1.0 specifies architectural extensions for 5G systems (5GS) that use NR to support multicast and broadcast communication services. Specifically, 3GPP TS23.247 v17.1.0 specifies the following:

[0054] Overview of Multicast and Broadcast Communications Multicast and Broadcast Service (MBS) is a point-to-multipoint service in which data is transmitted from a single source entity to multiple receivers, either to all users in a broadcast service area or to users in a multicast group as specified in TS 22.146. The corresponding types of MBS sessions are: - Broadcast sessions, - Multicast sessions.

[0055] The MBS architecture specified in clause 5 of 3GPP TS23.247 v17.1.0 follows the 5G system architecture principles specified in 3GPP TS23.501, which enables distribution of MBS data from a 5GS ingress to the NG-RAN node(s) and then to the UE. The MBS architecture provides: - Efficient use of RAN and CN resources, with a focus on air interface efficiency; - Efficient transport for a variety of multicast and broadcast services.

[0056] Multicast broadcast services for roaming are not supported in this release.

[0057] The interaction between multicast / broadcast services and support for deployment topologies with specific SMF service areas is not specified in this resource.

[0058] MBS also provides features such as local MBS service, admission of multicast MBS and QoS differentiation, etc. See clause 6 of 3GPP TS23.247 v17.1.0 for further details.

[0059] MBS traffic is distributed from a single data source (e.g., an application service provider) to multiple UEs. Depending on many factors, there are several distribution methods that can be used to distribute MBS traffic in 5GS.

[0060] NOTE 1: For clarity, the delivery method will not be referred to as unicast / multicast / broadcast, but as described below. The term "unicast delivery" refers to a mechanism in which application data and signaling between the UE and the application server are delivered using PDU sessions within the 3GPP network and using dedicated UE and application server addresses (e.g., IP addresses) between the 3GPP network and the application server. This is not equivalent to the 5GC dedicated MBS traffic delivery method specified in clause 4 of 3GPP TS23.247 v17.1.0.

[0061] Between 5GC and NG-RAN, there are two possible delivery methods for transmitting MBS data. - 5GC Individual MBS Traffic Delivery Method: This method applies only to multicast MBS sessions. 5GC receives a single copy of MBS data packets and delivers separate copies of those MBS data packets to individual UEs via per-UE PDU sessions; therefore, for each such UE, one PDU session is required to be associated with the multicast session. - 5GC shared MBS traffic delivery method: This method applies to both broadcast and multicast MBS sessions. The 5GC receives a single copy of MBS data packets and delivers the single copy of those MBS packets to an NG-RAN node, which then delivers the packets to one or more UEs.

[0062] The 5GC shared MBS traffic delivery method is required in all MBS deployments. The 5GC individual MBS traffic delivery method is required to enable mobility when there is an NG-RAN deployment with non-homogeneous support of MBS.

[0063] In a multicast session, a single copy of an MBS data packet received by the CN may be delivered via the 5GC individual MBS traffic delivery method for some UE(s) and via the 5GC shared MBS traffic delivery method for other UEs.

[0064] Between the NG-RAN and the UE, two delivery methods are available for the transmission of MBS data packets over the air interface. - Point-to-Point (PTP) delivery method: The NG-RAN delivers separate copies of the MBS data packets over the air interface to the individual UE(s). - Point-to-multipoint (PTM) delivery method: The NG-RAN delivers a single copy of the MBS data packet over the air interface to multiple UEs.

[0065] The NG-RAN may use a combination of PTP / PTM to deliver MBS data packets to the UE.

[0066] Note 2: PTP and PTM distribution methods are specified by the RAN WG.

[0067] As shown in the figure below, the 5GC shared MBS traffic distribution method (using PTP or PTM distribution) and the 5GC individual MBS traffic distribution method can be used simultaneously for a multicast MBS session.

[0068] 1 illustrates an example distribution method for an MBS session to which RAN node failure / restart detection and / or restoration according to some embodiments of the present disclosure is applicable. As illustrated in FIG. 1, multiple UEs 100-1, 100-2, 100-3, and 100-4 may join the MBS session using different distribution methods. For example, UE 100-1 and UE 100-2 may be served by shared MBS traffic distribution via a shared tunnel established between NG-RAN node 105 and 5GC 110. In such a case, a single copy of an MBS data packet may be delivered from 5GC 110 to NG-RAN node 105, which then delivers the packet to UE 100-1 and UE 100-2 using the PTP or PTM distribution method. In another example, UE 100-3 and UE 100-4 may be served by individual MBS traffic distribution via two separate PDU sessions established between one or more RAN nodes 105 and 5GC 110. In such a case, separate copies of those MBS data packets may be delivered from the 5GC 110 to the individual UEs 100-3 and 100-4 via per-UE PDU sessions.

[0069] In MBS broadcast communication, only the 5GC shared MBS traffic delivery method using PTM delivery is applicable.

[0070] For MBS multicast communication, if the NG-RAN node supports MBS, the network shall use the 5GC shared MBS traffic delivery method for MBS data transmission.

[0071] NOTE 3: The exception is when the UE moves between an NG-RAN node that does not support MBS (using the 5GC dedicated MBS traffic delivery method) and an NG-RAN node that does support MBS, there is temporary coexistence between the 5GC shared MBS traffic delivery method and the 5GC dedicated MBS traffic delivery method. For details, see 3GPP TS23.247 v17.1.0, clause 6.3.

[0072] In MBS multicast communication, switching between the 5GC shared MBS traffic delivery method and the 5GC individual MBS traffic delivery method is supported. UE mobility is supported between RAN nodes that both support MBS, and between RAN nodes that support MBS and RAN nodes that do not support MBS; see section 6.3 of 3GPP TS23.247 v17.1.0 for details.

[0073] In MBS multicast communication, switching between the PTP and PTM delivery methods for 5GC shared MBS traffic delivery shall be supported. The NG-RAN is the decision point for switching between the PTP and PTM delivery methods.

[0074] FIG. 2 illustrates an example communication network 20 to which RAN node failure / restart detection and / or restoration according to some embodiments of the present disclosure is applicable, showing an MBS reference architecture. A service-based interface is used in the control plane. Support for interworking at reference points xMB and MB2 is described in Annex C of 3GPP TS23.247 v17.1.0. The communication network 20 is a network defined in the context of 5G NR, although the present disclosure is not limited thereto.

[0075] 2, network 20 may comprise one or more UEs 200 and an NG-RAN 205, which may be or comprise one or more of a base station, a Node B, an evolved Node B (eNB), a gNB, or an access network (AN) node that provides UE 200 with access to other portions of network 20. Additionally, network 20 may comprise a core network portion of network 20, including (but not limited to) an AMF 225, an SMF 230, a user plane function (UPF) 210, a policy control function (PCF) 255, a network publication function (NEF) 245, an application function / application server (AF / AS) 250, a unified data management (UDM) 265, and / or a network repository function (NRF) 260. Furthermore, in addition to these network functions, communication network 20 may further comprise network functions to support MBS, including (but not limited to) MB-SMF 235, MB-UPF 215, Multicast / Broadcast Service Function (MBSF) 240, and Multicast / Broadcast Service Transport Function (MBSTF) 220. As shown in Figure 2, these entities may communicate with each other via service-based interfaces, such as Namf, Nsmf, Npcf, and / or reference points, such as N1, N2, N3, N4, and N4mb.

[0076] However, the present disclosure is not limited thereto. In some other embodiments, network 20 may include additional network functions, fewer network functions, or variations of the existing network functions shown in FIG. 2. For example, in a network with a 4G architecture, the entities performing these functions (e.g., mobility management entity (MME)) may be different from those shown in FIG. 2 (e.g., AMF 225). In another example, in a network with a mixed 4G / 5G architecture, some of the entities may be the same as those shown in FIG. 2, and others may be different. Furthermore, the functions shown in FIG. 2 are not essential to embodiments of the present disclosure. In other words, some of them may be omitted from some embodiments of the present disclosure. The functions shown in FIG. 2 are described in detail below.

[0077] 2, the AMF 225, as described above, may provide most of the functions that the MME provides in a 4G network. Below is a brief list of some of its functions: - terminating the RAN control plane (CP) interface (N2); - Non-Access Stratum (NAS) signaling, - NAS encryption and integrity protection, - Mobility Management (MM) layer NAS termination, - Session Management (SM) layer NAS forwarding, - authenticating the UE200; - Manage security contexts, - Registration management, - connection management, - Reachability management, - Mobility management, and / or - Apply mobility-related policies (e.g., mobility restrictions) from PCF255.

[0078] In addition to the functions defined above, the AMF 225 may further perform at least one of the following functions to support MBS: - signaling with NG-RAN205 and MB-SMF235 for MBS session management; - Selection of NG-RAN 205 for notification of multicast session activation towards UE 200 in CM-IDLE state. - Selection of NG-RAN205 for broadcast traffic distribution.

[0079] Additionally, the AMF225 may be aware of NG-RAN 5G MBS capabilities.

[0080] The SMF 230 may provide session management functions handled by the 4G MME, the Secure Gateway - Control Plane (SGW-C), and the PDN Gateway - Control Plane (PGW-C). See below for a brief list of some of its functions. - assigning an IP address to the UE; - NAS signaling for session management (SM), - Sending Quality of Service (QoS) and policy information to the NG-RAN 205 via the AMF 225; - Downlink data notification, - Select and control the UPF210 for traffic routing, - Serve as the interface for all communications related to a given user plane service, and / or - Lawful Intercept - Control Plane.

[0081] In addition to the functions defined above, the SMF 230 may further perform at least one of the following functions to support MBS: - discovering the MB-SMF235 for a multicast session; - allowing multicast session join operations, if necessary; - interacting with the MB-SMF235 to obtain and manage multicast session contexts; and - Interacting with the RAN 205 to establish shared data transmission resources.

[0082] It should be noted that the SMF 230 and the MB-SMF 235 may be co-located or deployed separately.

[0083] Furthermore, the UPF 210 is essentially a fusion of the data plane portions of the SGW and PGW: in the context of the Control-User Plane Separation (CUPS) architecture, Evolved Packet Core (EPC) SGW-U + EPC PGW-U → 5G UPF.

[0084] The UPF 210 may perform at least one of the following functions: - Packet routing and forwarding Packet inspection and QoS handling, and the UPF 210 may optionally incorporate deep packet inspection (DPI) for packet inspection and classification; Connecting to Internet POPs (Points of Presence), the UPF 210 may optionally incorporate firewall and network address translation (NAT) functionality; - Mobility anchor for intra-RAT and inter-RAT handovers, - Lawful Intercept - User Plane, and - Maintain and report traffic statistics.

[0085] In addition to the functions defined above, the UPF 210 may further perform at least one of the following functions to support MBS: - interacting with the SMF 230 to receive multicast data from the MB-UPF 215 for the 5GC individual MBS traffic delivery method; - Delivering multicast data to UE 200 via a PDU session for the 5GC individual MBS traffic delivery method.

[0086] It should be noted that the UPF 210 and the MB-UPF 215 may be co-located or deployed separately.

[0087] In addition to the functions specified in TS 23.501, the PCF 255 may perform at least one of the following functions to support MBS if dynamic PCC for MBS is required: - supporting QoS handling for MBS sessions; - providing policy information about the MBS session to the MB-SMF 235 in order to authorize the relevant QoS profile; - interacting with the UDR to retrieve QoS information; and The PCF 255 may receive MBS information from the AF 250, the NEF 245 or the MBSF 240, for example based on different configuration options.

[0088] The MB-SMF 235 may perform at least one of the following functions to support MBS: - Generic for multicast and broadcast sessions: - Supporting MBS session management (including QoS control); - configuring the MB-UPF 215 for transport of multicast and broadcast flows based on policy rules for multicast and broadcast services from the PCF 255 or local policies; - Allocating and deallocating Temporary Mobile Group Identities (TMGIs); - Specific to broadcast sessions: - interacting with the RAN 205 (via the AMF 225) to control data transport using the 5GC shared MBS traffic delivery method; - Specific to multicast sessions: - interacting with the SMF230 to modify the PDU session associated with the MBS session; - interacting with the RAN 205 (via the AMF 225 and the SMF 230) to establish data transmission resources between the MB-UPF 215 and the RAN nodes for the 5GC shared MBS traffic delivery method; - Controlling multicast data transport using the 5GC individual MBS traffic delivery method.

[0089] The MB-UPF 215 may perform at least one of the following functions to support MBS: - Generic for multicast and broadcast sessions: - Packet filtering of incoming downlink packets for multicast and broadcast flows, - QoS enforcement (Maximum Flow Bit Rate (MFBR)) and counting / reporting based on existing means, - Interacting with MB-SMF235 to receive multicast and broadcast data, - Delivery of multicast and broadcast data to RAN nodes 205 for 5GC shared MBS traffic delivery method; - Specific to multicast sessions: - Delivery of multicast data to UPF 210 for 5GC individual MBS traffic delivery method.

[0090] In addition to the functions specified in TS 23.501, the NG-RAN 205 may perform at least one of the following functions to support MBS: - Managing MBS QoS flows over N2; - delivery of MBS data packets from a 5GC shared for multiple UEs 200 over the air using PTM or PTP; - configuring the UE 200 for MBS QoS flow reception at the AS layer; - Controlling switching between PTM and PTP delivery per UE; - Support for multicast session continuity during Xn and N2 handovers; - Supports over-the-air notification of multicast session activation towards UEs 200 in CM-IDLE state and CM-CONNECTED with RRC inactivity state.

[0091] In addition to the functionality specified in TS23.501, UE200 may perform at least one of the following functions to support MBS: - Receiving multicast data using PTM / PTP, - receiving broadcast data using PTM, - handling of incoming MBS QoS flows; - Support for signaling to join and leave multicast MBS sessions; - MBS resource management support at the AS layer, and - Receiving notifications in CM-IDLE state and CM-CONNECTED state with RRC inactivity for multicast data transmission.

[0092] The AF 250 may perform at least one of the following functions to support MBS: - Requesting multicast or broadcast services from the 5GC by providing service information, including QoS requirements, to the 5GC; - commanding MBS session operation towards 5GC, if necessary; and - Interact with NEF245 for the release of MBS related services.

[0093] In addition to the functions specified in TS23.501, the NEF 245 may further perform at least one of the following functions to support MBS: - providing an interface to the AF 250 for MBS procedures including service provisioning, MBS session and QoS management; - interacting with the AF 250 and NFs in the 5GC, such as the MB-SMF 235, for determining MBS session operation and transport parameters; and - Selection of MB-SMF235 to serve MBS sessions.

[0094] The MBSF 240 may perform at least one of the following functions to support the MBS: - Service level functions to support MBS and interworking with LTE MBMS, - interacting with the AF250 and MB-SMF235 for MBS session operation, transport parameter determination, and session transport; - Selection of MB-SMF235 to serve MBS sessions, - controlling the MBSTF220, if used; and - Determining the source IP multicast address for an MBS session when the IP multicast address is sourced by the MBSTF 220.

[0095] The MBSTF 220, when deployed, may perform at least one of the following functions to support MBS: - Media anchors for MBS data traffic, if required; - IP multicast sourcing, if required, - Generic packet transport features available to any IP multicast-enabled application, such as framing, multiple flows, packet FEC (encoding), and - Multicast / broadcast distribution of input files as objects or object flows.

[0096] In addition to the functions specified in TS23.501, the UDM 265 may further perform at least one of the following functions to support MBS: - Supports management of subscriptions for grants for multicast MBS sessions.

[0097] In addition to the functions specified in TS 23.501, the UDR, when deployed, may perform at least one of the following functions to support MBS: - Supports management of UE authorization information for multicast MBS sessions; and - Supports management of policy information for multicast or broadcast MBS sessions.

[0098] In addition to the functions specified in TS23.501, NRF260 may further perform at least one of the following functions to support 5G MBS: - Support for new NF types MB-SMF and MBSF and their corresponding NF profiles, - Support for MB-SMF discovery based on parameters such as Data Network Name (DNN), Single-Network Slice Selection Assistance Information (S-NSSAI) and MB Service Area during MBS session creation for both multicast and broadcast MBS sessions; and - For multicast MBS sessions, support for MB-SMF discovery based on MBS session ID by the SMF 230 serving the multicast session at UE subscription.

[0099] Note that the MBSF 240 is optional and may be co-located with the NEF 245 or the AF / AS 250, and the MBSTF 220 may be an optional network function. Additionally, the existing service-based interfaces of Nnrf, Nudm, and Nsmf may be extended to support MBS. The existing service-based interfaces of Npcf and Nnef may be extended to support MBS. An MBS-enabled AF may use either Nmbsf or Nnef to interact with the MBSF.

[0100] 3 is a diagram illustrating another exemplary communication network 20' to which RAN node failure / restart detection and / or restoration according to some embodiments of the present disclosure is applicable, and illustrates a 5G system architecture for MBS using reference point representation. The NFs illustrated in FIG. 3 are substantially similar to those illustrated in FIG. 2, and therefore, a detailed description thereof is omitted for brevity.

[0101] Note that the existing reference points N1, N2, N4, N10, N11, N30, and N33 may be extended to support MBS. Furthermore, in terms of their functionality, Nmb13, N29mb, and Nmb1 may be equivalent, Nmb5 and Nmb10 may be equivalent, and Nmb9 and N6mb may be equivalent.

[0102] According to 3GPP TS23.247 v17.1.0, unicast or multicast transport over N3mb between NG-RAN and MB-UPF can be applied. - If unicast transport over N3mb is applied, each NG-RAN allocates tunnel information (including IP addresses and TEIDs) that is provided to the MB-UPF (via the AMF, MB-SMF) so that DL MBS packets can be sent to that tunnel entity. - When multicast transport over N3mb is applied, the NG-RAN does not provide tunnel information; instead, the NG-RAN subscribes to the multicast IP address provided by the MB-UPF.

[0103] The MB-UPF serves as an MBS session anchor for the MBS session, and when an MBSTF is involved in the MBS session, the MBSTF serves as a media anchor for the MBS traffic. The MB-UPF receives only one copy of the MBS data packet from the AF or the MBSTF.

[0104] The user plane between the MBSTF and the MB-UPF, or between the MB-UPF and the AF, may use either multicast transport or a unicast tunnel for the MBS session (depending on the application and the capabilities of the control interface). If the transport network does not support multicast transport, the user plane uses a unicast tunnel for the MBS session. The user plane between the MBSTF and the AF may use a unicast tunnel, multicast transport, or other means (e.g., HTTP download from an external CDN). If unicast is used for the MBS session, after receiving the downlink MBS data, the MB-UPF forwards the downlink MBS data without the outer IP header and tunnel header information.

[0105] The user plane from the MB-UPF to the NG-RAN(s) (for 5GC shared MBS traffic delivery) and the user plane from the MB-UPF to the UPF (for 5GC individual MBS traffic delivery) may use multicast transport via a common GTP-U tunnel per MBS session, or may use unicast transport via a separate GTP-U tunnel in the NG-RAN or in the UPF per MBS session, in the following manner: - In 5GC shared MBS traffic delivery (i.e., the MB-UPF delivers user plane data to NG-RANs supporting MBS), if the transport network supports IP multicast, the NG-RAN nodes use multicast transport via a common GTP-U tunnel per MBS session; otherwise, unicast transport via a separate GTP-U tunnel per MBS session per NG-RAN node is used. - For 5GC individual MBS traffic delivery (i.e., MB-UPF delivers user plane data to UPF), if the transport network supports IP multicast and the UPF supports receiving multicast data over N19mb, the UPF uses multicast transport via a common GTP-U tunnel per MBS session; otherwise, unicast transport via a separate GTP-U tunnel per MBS session per UPF is used.

[0106] When the user plane uses unicast transport, the transport layer destination is the IP address of the NG-RAN or UPF, and each NG-RAN or UPF allocates a separate tunnel, and multiple GTP-U tunnels are used for the MBS session. When the user plane uses multicast transport, a common GTP-U tunnel is used for both the RAN node and the UPF node. The GTP-U tunnel is identified as the transport layer destination by a common tunnel ID and IP multicast address, both allocated by the 5GC.

[0107] The above is illustrated in Figure 4. There may be more than one NG-RAN or UPF involved in MBS traffic delivery. Figure 4 illustrates an example user plane data transmission where RAN node failure / restart detection and / or restoration according to some embodiments of the present disclosure is applicable.

[0108] 1, multiple UEs 200-1, 200-2, 200-3, and 200-4 may join an MBS session using different delivery methods. For example, UE#1 200-1 and UE#2 200-2 may be served by shared MBS traffic delivery via a shared tunnel, while UEs 200-3 and 200-4 may be served by individual MBS traffic delivery via two separate PDU sessions A and B.

[0109] The MB-SMF instructs the MB-UPF to receive packets related to the MBS session.

[0110] In shared distribution (e.g., to UE#1 200-1, UE#2 200-2), if unicast transport over N3mb is applied, the MB-SMF instructs the MB-UPF (e.g., MB-UPF 215) to duplicate received MBS packets and forward them towards multiple RAN nodes via separate GTP tunnels. In shared distribution, if multicast transport over N3mb is applied, the MB-SMF instructs the MB-UPF to duplicate received MBS data and forward the data via a single GTP tunnel.

[0111] In individual delivery (e.g., to UE#3 200-3, UE#4 200-4), the MBS data received by the MB-UPF is replicated to (one or more) UPFs (e.g., UPF 210), and individual delivery is performed in the following manner. - The MB-SMF configures the MB-UPF to receive packets related to MBS sessions, replicate these packets, and forward them towards multiple UPFs via GTP tunnels if unicast transport over N19mb applies, or via a single GTP tunnel if multicast transport over N19mb applies. The SMF(s) instruct the UPF to receive packets related to the multicast session from the MB-UPF on N19mb, to replicate these packets, and to forward them in multiple PDU sessions.

[0112] In MB-SMF and MB-UPF, packet detection, replication and forwarding for MBS sessions is achieved by using one Packet Detection Rule (PDR) for each MBS session, which detects incoming MBS packets and points to one Forwarding Action Rule (FAR) that describes the forwarding of data towards multiple destinations (UPF or RAN nodes). - A PFCP session is created when an MBS session is started, regardless of multicast or unicast transport on N3mb and N19mb. - For multicast transport on N3mb and N19mb, the destination at the FAR contains the MB-UPF IP multicast distribution information. - For unicast transport over N3mb and N19mb, a FAR in a PFCP session may contain multiple destinations represented by NG-RAN N3mb tunnel information and UPF N19mb tunnel information (if applicable).

[0113] In the SMF and UPF (for 5GC individual delivery), packet detection, duplication and forwarding for the MBS session are achieved by the PDR and FAR of the PDU session to which the UE has joined the MBS session. - The SMF instructs the UPF to associate the PFCP session of the PDU session with the MBS session. - A new PDR with source interface "core" is used to detect MBS data from N19mb.

[0114] Note: This PDR also contains the MBS session ID to enable single detection of incoming MBS data for multiple PDU sessions in the UPF.

[0115] - For unicast transport over N19mb, the SMF requests the UPF to allocate N19mb tunnel information if it is not allocated. - For multicast transport over N19mb, the SMF includes low-layer source-specific multicast address information and C-TEID to the UPF. - If the SMF wants to maintain MBS data reception on N19mb but suspends the delivery of data to the UE's PDU session, the FAR action is set to "drop" (for example, when the UE is switching from 5GC individual delivery to 5GC shared delivery by moving from an MBS that does not support NG-RAN to an MBS that does support NG-RAN). In other cases, the SMF deletes the relevant PDR and FAR.

[0116] For details on user plane handling, see 3GPP TS29.244.

[0117] 5A and 5B illustrate example procedures for a UE joining a multicast session, where RAN node failure / restart detection and / or restoration according to some embodiments of the present disclosure is applicable.

[0118] The following steps may be performed before the UE requests to join an MBS session. - An MBS session may have been created in 5GC (see section 7.1.1 of 3GPP TS23.247 v17.1.0 for details). The UE may have registered in a PLMN or SNPN and established a PDU session that may be associated with one or more multicast sessions. - The UE knows at least the MBS session IDs of the multicast groups that the UE can join, for example via a service announcement.

[0119] 5A, in steps S501a and S501b, to join a multicast group, the UE sends a PDU session modification request for the associated PDU session, which further includes one or several MBS session IDs and a join request. The MBS session ID(s) indicate the multicast MBS session(s) that the UE wants to join.

[0120] Alternatively, the UE may join a multicast MBS session by sending a PDU session establishment request for the associated PDU session with one or several MBS session IDs and a join request. In that case, before step S502, the network proceeds with establishing the associated PDU session and performs steps 4 to 10 of the PDU session establishment procedure as specified in TS 23.502 subclause 4.3.2.2.

[0121] In optional step S502, based on the received MBS session ID and join request, the SMF determines that this is an MBS session join request.

[0122] If the SMF does not have information about the MBS session context for the indicated MBS session ID(s), the SMF discovers and selects an MB-SMF for the MBS session via the NRF, as described in clause 7.1.2 of 3GPP TS23.247 v17.1.0. If no MB-SMF is allocated for the MBS session ID (i.e., the NRF provides an empty MB-SMF profile), the SMF may select an MB-SMF and request the MB-SMF to set up a multicast MBS session, or the SMF may reject the join request and respond to the UE with an appropriate cause value.

[0123] NOTE 1: The details of how an SMF selects an MB-SMF and requests the MB-SMF to set up a multicast MBS session are left to the SMF implementation.

[0124] In optional step S503, for each MBS session in step 1, if the SMF did not subscribe to the MBS session context, the SMF invokes a Nmbsmf_MBSSession_ContextStatusSubscribe request (MBS session ID) towards the MB-SMF to subscribe to event notifications related to the multicast MBS session and request information about the MBS session context. The MB-SMF responds with information about the indicated multicast MBS session in the Nmbsmf_MBSSession_ContextStatusSubscribe response (multicast QoS flow information (e.g., QoS profile(s) for the multicast MBS session), [start time], [session status indication (active / inactive)], [any UE indication], [multicast DL tunnel information]).

[0125] If this is the first time that the MB-SMF receives an Nmbsmf_MBSSession_ContextStatusSubscribe request for the indicated MBS session from the SMF, the MB-SMF learns that it is the first UE to join the multicast MBS session. In the multicast transport between the MB-UPF and the content provider, if it is the first UE to join the multicast MBS session and the MB-UPF did not join the multicast tree in the MBS session creation procedure described in clause 7.1.1 of 3GPP TS23.247 v17.1.0, the MB-SMF requests the MB-UPF to join the multicast tree towards the AF / MBSF; otherwise, the MB-SMF does not send a request to the MB-UPF.

[0126] NOTE 2: The MB-SMF can answer the Nmbsmf_MBSSession_ContextStatusSubscribe request either based on the information received in the MBS session creation procedure in clause 7.1.1 of 3GPP TS23.247 v17.1.0 or based on preconfigured information. The preconfiguration also includes information about the MBS session stored in the NRF. If the MB-SMF uses preconfigured information, the preconfiguration also includes the MB-UPF configuration.

[0127] In step S504, the SMF determines whether the user is authorized to join the multicast session, taking into account the MBS subscription data received from the UDM and any UE indication, if received from the MB-SMF. The SMF considers the UE authorized to use the multicast MBS service and if the MBS session ID(s) in the PDU session modification request are included in the MBS subscription data or if any UE indication is received. If the authorization check fails, the SMF rejects the join request with a cause value. If the UE joins before the start time of the multicast MBS session, the SMF may accept the join request and indicate the start time to the UE, or the SMF may reject the join request with an appropriate error cause and, optionally, a back-off timer. If the UE joins while the multicast MBS session is inactive, the SMF accepts the join request.

[0128] In step S505, if the join request is accepted, the SMF responds to the AMF through an Nsmf_PDUSession_UpdateSMContext response (N2 SM information (PDU session ID, MBS session ID, [updated PDU session information], [mapping information between (one or more) unicast QoS flows and (one or more) multicast QoS flows]), N1 SM container (PDU session modification command)) to do the following: - creating an MBS session context for the indicated MBS session in the RAN if the MBS session context does not already exist in the RAN; and - Informing the NG-RAN about the relationship between the multicast MBS session context and the UE's PDU session context by including an MBS session ID and a mapping between the multicast QoS flow(s) and the associated QoS flow(s).

[0129] Based on operator policy, the SMF may prepare for 5GC individual MBS traffic delivery fallback. The SMF maps the received QoS information of the multicast QoS flow to the unicast QoS flow information of the PDU session, and includes the QoS flow information and the mapping information for the QoS flow in the SM information sent to the RAN. The SMF compares the QFI of the multicast QoS flow received from the MB-SMF with the QFI in use for the PDU session, and allocates the unused QFI to the unicast QoS flow of the PDU session corresponding to the multicast QoS flow.

[0130] Note 3: The detailed information contained in the N2 SM information is aligned with RAN WG3.

[0131] NOTE 4: PDU Session UP activation is not triggered by N2 SM information if the N2 SM information contains only information related to the multicast MBS session and the associated QoS flows and is received by an MBS-capable NG RAN node.

[0132] NOTE 5: The SMF uses the same QoS in the received MBS QoS flow QoS information for the associated QoS flow in the unicast PDU session.

[0133] If the MBS session join procedure is triggered by the UE along with the PDU session establishment procedure for the associated PDU session, the SMF provides the N2 SM information and the N1 SM container for the associated PDU session in a Namf_Communication_N1N2MessageTransfer service operation towards the AMF as described in step 11 of clause 4.3.2.2.1 in TS 23.502. The N2 SM information also includes the MBS session ID and, if 5GC individual MBS traffic delivery fallback is supported, mapping information between the unicast QoS flow(s) and the multicast QoS flow(s).

[0134] Editor's note: The implication of not triggering PDU session UP activation in the NG-RAN when the SMF informs the NG-RAN of the UE joining requires RAN collaboration.

[0135] If the subscription request is rejected, the SMF responds to the AMF via an Nsmf_PDUSession_UpdateSMContext response (N1 SM Container (PDU Session Modification Reject)), where the message does not contain the MBS session context or N2 SM information for the associated PDU session. The PDU Session Modification Reject message is forwarded to the UE via the NG-RAN, and the following steps are skipped.

[0136] In step S506, an N2 message including multicast MBS session information and PDU session modification information is sent to the NG-RAN.

[0137] If MBS is not supported by the NG-RAN, 5GC individual MBS traffic distribution may be used. Otherwise, if MBS is supported by the NG-RAN, 5GC shared MBS traffic distribution is adopted.

[0138] If the NG-RAN supports MBS, the NG-RAN uses the MBS session ID to determine that the PDU session identified by the PDU session ID is associated with the indicated multicast MBS session.

[0139] If the NG-RAN supports MBS, the associated unicast QoS flow information is not used to allocate radio and CN resources.

[0140] Note 6: It is up to the NG-RAN to decide whether radio resources are allocated or not, and it is up to the NG-RAN / UPF to decide whether multicast or unicast transport is used between the NG-RAN / UPF and the MB-UPF.

[0141] In optional step S507, if a shared tunnel has not been established for the multicast MBS session towards the NG-RAN node, the procedure described with reference to Figure 6 for establishing a shared distribution towards the NG-RAN node is performed. This step is performed separately for each multicast MBS session.

[0142] In step S508, the NG-RAN node performs an AN-specific signaling exchange with the UE to establish radio resources for the multicast MBS session if not already established. If the NG-RAN does not support MBS, the radio resources are reconfigured for unicast transmission of MBS data on the associated PDU session. As part of the AN-specific signaling exchange, an N1 SM container (PDU Session Modify Command) is provided to the UE.

[0143] In step S509, the NG-RAN node sends a PDU session modification response.

[0144] If MBS is not supported by the NG-RAN, the accepted unicast QoS flow is included in the N2 SM response container. If MBS is supported by the NG-RAN, the N2 SM response container further includes an indication that MBS is supported.

[0145] In step S510, the AMF invokes the Nsmf_PDUSession_UpdateSMContext request([N2 SM Container]) to the SMF.

[0146] According to the indication of whether the NG-RAN supports MBS, the SMF determines the delivery mode, i.e., whether 5GC individual MBS traffic delivery is used for multicast data transmission.

[0147] NOTE 7: If a shared tunnel is used, no interaction with the UPF is required for directed multicast MBS sessions.

[0148] As shown in Figure 5B, steps S511a to S511e are optional and are used for 5GC dedicated MBS traffic delivery if the relevant NG-RAN does not support MBS. Steps S511a to S511d are performed if a shared tunnel between the UPF (PSA) and the MB-UPF for 5GC dedicated MBS traffic delivery has not yet been established by the SMF for the multicast MBS session. Step S511e is performed regardless.

[0149] In step S511a, the SMF contacts the UPF to request the creation of a tunnel and provides the MBS session ID. The UPF instructs the SMF whether a new tunnel for this multicast MBS session should be allocated (as there may be multiple SMFs interacting with the same UPF for the same multicast MBS session).

[0150] If the UPF decides to use unicast transport over N19mb, the UPF allocates a DL N19mb tunnel endpoint for the multicast MBS session if the SMF request is the first request to allocate a DL N19mb tunnel endpoint for the multicast MBS session in the UPF. The UPF includes the DL tunnel information in its response to the SMF. The DL tunnel information includes the downlink tunnel ID and the UPF address.

[0151] If the UPF decides to use multicast transport over N19mb, the UPF joins multicast distribution if the SMF request is the first request for an MBS session in the UPF. Steps S511b to S511d are skipped.

[0152] In step S511b, if the UPF indicates that a DL N19mb tunnel is newly allocated, the SMF invokes an Nmbsmf_MBSsession_ContextUpdate request (MBS session ID, [DL tunnel information]) towards the MB-SMF to establish a multicast MBS session transport between the MB-UPF and the UPF.

[0153] In step S511c, if DL tunnel information of UPF is received, MB-SMF configures MB-UPF to send multicast MBS session data towards UPF using possibly received downlink tunnel ID.

[0154] In step S511d, the MB-SMF responds to the SMF through Nmbsmf_MBSSession_ContextUpdate response(MBS Session ID, [Multicast DL Tunnel Information]). If the UPF DL tunnel information for unicast transport is not received by the MB-SMF, multicast transport between the MB-UPF and UPF should be used, and the MB-SMF includes downlink tunnel information with the lower layer transport multicast address for the multicast MBS session.

[0155] In step S511e, the MB-SMF configures the MB-UPF to forward the received multicast MBS session data in the PDU session (this step may be combined with step S511a).

[0156] In step S512, the SMF responds to the AMF with an Nsmf_PDUSession_UpdateSMContext response message.

[0157] In step S513, the MB-UPF receives the multicast PDU either directly from the content provider or via the MBSTF, which is capable of manipulating the data.

[0158] Steps S514 to S516 are for 5GC shared MBS traffic delivery. In step S514, the MB-UPF sends the multicast PDU to the NG-RAN in the N3mb tunnel associated with the multicast MBS session. There is only one tunnel per multicast MBS session and NG-RAN node, i.e., all UEs that have subscribed to the multicast MBS session via the NG-RAN node share this tunnel for receiving the multicast MBS session data.

[0159] In step S515, the NG-RAN selects a PTM or PTP radio bearer for delivering the multicast PDU to the UE(s) that have joined the multicast MBS session.

[0160] In step S516, the NG-RAN transmits the multicast MBS session data to the UE(s) using the selected PTM or PTP radio bearer(s).

[0161] Steps S517 to S519 are for 5GC individual MBS traffic delivery. In step S517, the MB-UPF sends the multicast PDU to the UPF in the N19mb tunnel associated with the multicast MBS session. There is only one tunnel per multicast MBS session and destination UPF, i.e., all associated PDU sessions served by the destination UPF share this tunnel.

[0162] In step S518, the UPF forwards the multicast data towards the NG-RAN via unicast (i.e., in the N3 tunnel of the associated PDU session).

[0163] In step S519, the NG-RAN forwards the multicast MBS session data to the UE via unicast (i.e., on the radio bearer(s) corresponding to the associated QoS flow(s) of the associated PDU session).

[0164] NOTE 8: Details of DL MBS data transmission are explained in clause 6.7 of 3GPP TS23.247 v17.1.0.

[0165] NOTE 9: When an MBSF participates in a multicast MBS session, the tunnel between the MBSTF and the MB-UPF is established in the MBS session creation procedure.

[0166] FIG. 6 illustrates an example procedure for establishing share distribution towards an NG-RAN node, to which RAN node failure / restart detection and / or restoration according to some embodiments of the present disclosure is applicable.

[0167] A shared tunnel for shared distribution is established between the NG-RAN and the MB-UPF in the following cases: - The first UE is included in the context of an MBS session in the NG-RAN. NOTE 1: When a multicast MBS session is deactivated, if there is at least one UE in the NG-RAN that is in RRC-CONNECTED state and subscribes to the multicast MBS session, the shared distribution is not released. NOTE 2: The Share Distribution Establishment procedure is used when the MBS supporting (one or more) NG-RAN nodes are involved in a multicast MBS session regardless of the state of the multicast MBS session. - Handover to the target NG-RAN when a shared distribution tunnel is not established in the target RAN node for this multicast MBS session.

[0168] 6, in step S601, when the NG-RAN node serves at least one UE in the multicast MBS session, the NG-RAN node determines to establish shared distribution for the multicast MBS session. For location-dependent services, if the NG-RAN node serves at least one UE allocated to the MBS session ID and area session ID, the NG-RAN node needs to establish shared distribution for the location-dependent content of the multicast MBS session.

[0169] In step S602, the NG-RAN sends an N2 MBS session request message (MBS session ID, [area session ID], N2 SM information ([unicast DL tunnel information])) to the AMF.

[0170] If the NG-RAN node is configured to use unicast transport for shared distribution, the NG-RAN node allocates GTP tunnel endpoints and provides unicast DL tunnel information in the request, where the unicast DL tunnel information includes the GTP tunnel endpoints and the NG-RAN node address. For location-dependent MBS services, the NG-RAN node also provides an area session ID.

[0171] In step S603, the AMF selects the MB-SMF to serve the multicast MBS session, for example using the NRF discovery service or locally stored information. The AMF invokes a Nmbsmf_MBSSession_ContextUpdate request (MBS Session ID, [Area Session ID], N2 SM Information) to the MB-SMF in step S603a.

[0172] The AMF stores the NG-RAN node's information (e.g., NG-RAN node ID) for subsequent signaling related to the multicast MBS session at S603b.

[0173] In optional step S604, if the MB-SMF received the unicast DL tunnel information in step S603, the MB-SMF configures the MB-UPF to send multicast data for the multicast MBS session (or location-dependent content of the multicast MBS session if an area session ID was received) towards that GTP tunnel endpoint via unicast transport.

[0174] In step S605, the MB-SMF stores the AMF's information (e.g., AMF ID) in the MBS multicast session context (or in the location-dependent part of the multicast MBS session context if an area session ID is received) to enable subsequent signaling towards that AMF.

[0175] In step S606, the MB-SMF sends an Nmbsmf_MBSSession_ContextUpdate response (MBS Session ID, [Area Session ID], N2 SM Information ([TMGI], Multicast QoS Flow Information, [Multicast DL Tunnel Information], [MBS Service Area])) to the AMF. If the MB-SMF did not receive unicast DL tunnel information in step S603, the MB-SMF provides multicast DL tunnel information including the transport multicast address (e.g., LL SSM) and the GTP tunnel endpoint for multicast transport of shared delivery.

[0176] In step S607, the AMF sends an N2 MBS session response message (MBS session ID, [area session ID], N2 SM information) to the NG-RAN node. If the NG-RAN node receives the multicast DL tunnel information for shared distribution, the NG-RAN node uses the transport multicast address included in the multicast DL tunnel information to join the multicast transport distribution.

[0177] 7A and 7B are diagrams illustrating an example MBS session activation procedure to which RAN node failure / restart detection and / or restoration according to some embodiments of the present disclosure are applicable.

[0178] The following can trigger the MBS session activation procedure: - the AF requests the MB-SMF to activate the MBS session; - MB-UPF receives multicast data and notifies MB-SMF.

[0179] In this procedure, steps S702 to S710 and steps S711 to S714 can be executed in parallel.

[0180] As shown in FIG. 7A, in step S701, the procedure can be triggered by the following events: - When the MB-UPF receives downlink data for a multicast MBS session, based on an instruction from the MB-SMF (as described in clause 7.2.5.3 of 3GPP TS23.247 v17.1.0), the MB-UPF sends an N4mb notification (N4 session ID) to the MB-SMF to indicate the arrival of DL MBS data. - The AF sends an MBS activation request (TMGI) to the MB-SMF directly or via the NEF.

[0181] In step S702, the MB-SMF sends Nmbsmf_MBSSession_ContextStatusNotify(MBS Session ID, activated multicast session) to the SMF(s).

[0182] The SMF sets the relevant multicast MBS session state as "active" and finds the list of UEs that have subscribed to the multicast MBS session identified by the relevant TMGI. If the SMF determines that the user plane of the associated PDU session(s) of the UE(s) for the TMGI is already activated, steps S703 to S708a shall be skipped for those UE(s).

[0183] In step S703, the SMF invokes a Namf_MT_EnableGroupReachability request (list of UEs, [PDU session ID of associated PDU session], TMGI, [UE reachability notification address]) to the AMF(s). When the subsequent UE is reachable, the UE reachability notification address is used by the AMF to identify the involved SMFs and notify them.

[0184] After receiving the request, for each UE in the list, the AMF determines the CM state of the UE, see steps S704 to S707.

[0185] In step S704a, if there are UEs involved in the multicast MBS session and in the CM-CONNECTED state, the AMF indicates those UEs to the SMF using the Namf_MT_EnableGroupReachability response (UE list). Otherwise, the response does not include a UE list.

[0186] In step S704b, for each UE in the UE list included in step S704a, if the QoS profile(s) for the associated QoS flow(s) are not already provided for the PDU session, the SMF invokes Namf_Communication_N1N2MessageTransfer(N2 SM Info(PDU Session ID, MBS Session ID, [QoS profile(s) for the associated QoS flow(s)], [mapping information between unicast QoS flows and multicast QoS flows])) to the AMF for the UE identified in step S704a. The associated QoS profile and the mapping information between unicast QoS flows and multicast QoS flows are included to support 5GC individualized MBS traffic delivery.

[0187] The procedure continues at step S709.

[0188] In optional step S705, if the AMF determines that there are UEs in CM-IDLE state and involved in a multicast MBS session, the AMF resolves a paging area covering all registration areas of those UE(s) that need to be paged. The AMF sends a paging request message to the NG-RAN node(s) belonging to this paging area using TMGI as an identifier to be paged if the involved NG-RAN node(s) support MBS. If the NG-RAN node(s) do not support MBS, the AMF sends a paging message to the NG-RAN node(s) for each UE without using an MBS session ID, as described in step 4b in clause 4.2.3.3 of TS 23.502.

[0189] NOTE 1: Paging details are specified by the RAN WG.

[0190] In step S706, the UE(s) in CM-IDLE state send a service request message to the AMF, see section 4.2.3 of TS23.502.

[0191] In step S707a / S707b, after receiving a service request sent by the UE(s), - Based on the received PDU session ID in step S703, the AMF identifies the involved SMF and invokes the Nsmf_PDUSession_UpdateSMContext request. The procedure continues in step S709, or Based on the received UE reachability notification address in step S703, the AMF identifies the relevant SMFs and notifies them of the currently reachable UE(s) and their location information by using a Namf_MT_UEReachabilityInfoNotify message, which can be a separate notification or can be combined with step S708.

[0192] In step S708a, for the UE(s) that do not respond to the paging, the AMF informs the SMF of the paging failure in Namf_MT_UEReachabilityInfoNotify.

[0193] In step S708b, for the UE(s) indicated as reachable via the Namf_MT_UEReachabilityInfoNotify message, or the user plane of the associated PDU session has already been activated but the QoS profile(s) for the associated QoS flow(s) needs to be provided for the PDU session, the SMF invokes Namf_Communication_N1N2MessageTransfer(N2 SMInfo()) to the AMF, the same as described in step S704b.

[0194] In step S709, the AMF sends an N2 request message (N2 SM information()) to the RAN node.

[0195] As shown in Figure 7B, in step S710a, if a shared tunnel has not been previously established, the shared tunnel is established in this step as described with reference to Figure 6. The NG-RAN configures RRC messages to the UE, if necessary.

[0196] In step S710b, steps S508 to S512 described with reference to Figures 5A and 5B are performed. If 5GC dedicated MBS traffic delivery is used, the SMF configures the UPF for dedicated delivery and, if necessary, requests the MB-SMF to configure the MB-UPF to send multicast data to the UPF.

[0197] In step S711, if the MB-SMF finds that there is an established shared tunnel, steps S711 to S715 are performed. The MB-SMF invokes Namf_MBSCommunication_N2MessageTransferRequest(TMGI, N2 SMInfo(Activate, TMGI)) to the AMF for NG-RAN nodes that have a shared tunnel with the MB-UPF. This step may be performed in parallel with step S702.

[0198] Note 2: The messages in steps S710a, S711 and S712 are MBS-specific, and it is possible that the AMF(s) in steps S710a, S711 and S712 are not associated with any UE involved in the multicast MBS session.

[0199] At S712, the AMF sends an NGAP activation request message (N2 SM Info()) to the NG-RAN node. For UEs that have joined an MBS session and are in RRC-INACTIVE state, the RAN node performs RAN paging as specified in 3GPP TS38.300.

[0200] In step S713, the NG-RAN node responds to the AMF with an NGAP Activation Response message. The NG-RAN node establishes radio resources for transmitting multicast MBS session data to the UE(s). The NG-RAN shall not release the radio connection of UEs that have joined only the multicast session, since no unicast traffic will be received for those UEs.

[0201] In step S714, AMF sends MB-SMF:Namf_MBSCommunication_N2MessageTransfer response().

[0202] In step S715, the MB-SMF sends an N4mb Session Modify Request to the MB-UPF to forward the received packet. The MB-UPF responds to the MB-SMF with an N4mb Session Modify Response that acknowledges the MB-SMF request. For further details, see section 4.4 of TS 23.502.

[0203] 3GPP TS23.527 v17.1.0 specifies restoration procedures in 5G systems. For NG-RAN failures and re-initiations, it includes the following: 1. Upon NG-RAN restart, now that the NG-RAN will lose all session context, the NG-RAN will then send a GTP-U error indication upon receiving a DL packet from the UPF towards an unknown GTP-U tunnel endpoint. The UPF will then report the received GTP-U error indication to the SMF so that the SMF can determine whether to restore the session in the restarted NF-RAN (clause 5.2.1 of TS 23.527).

[0204] 2. Upon NG-RAN (partial) failure without restart, or if there is a user plane path between NG-RAN and UPF, the UP function can detect such failure using the GTP-U echo request / response mechanism, i.e., if the UPF does not receive a corresponding GTP-U echo response for an operator configurable retry time, the UPF shall determine a GTP-U path failure and report the failure to the SMF (clause 5.2.2 of TS 23.527).

[0205] The following content specifies the procedures supported in 5G systems for detecting and handling failures affecting user plane interfaces N3 and N9.

[0206] A GTP-U entity may lose its GTP-U context upon failure or restart.

[0207] When a GTP-U node receives a G-PDU for which no corresponding GTP-U tunnel exists, the GTP-U node shall discard the G-PDU and return a GTP-U error indication to the sending node as specified in clause 7.3.1 of 3GPP TS 29.281.

[0208] Receipt of a GTP-U error indication is an indication to the sending GTP-U entity that the peer GTP-U entity is unable to receive any more user plane traffic on the corresponding GTP-U tunnel.

[0209] A GTP-U entity may detect user plane path failure by using GTP-U Echo Request and GTP-U Echo Reply messages as specified in clause 20.3.1 of 3GPP TS 23.007.

[0210] FIG. 8 illustrates an example procedure for a GTP-U error indication from a 5G-AN, where RAN node failure / restart detection and / or restoration according to some embodiments of the present disclosure is applicable.

[0211] The following content specifies the behavior of different network entities when receiving a GTP-U error indication.

[0212] As shown in Figure 8, the user plane connection of the existing PDU session is activated. A downlink G-PDU is sent towards the 5G-AN in step S801.

[0213] In step S802, the 5G-AN returns a GTP-U error indication if the 5G-AN does not have a corresponding GTP-U context (see section 5.2 of 3GPP TS23.527 v17.1.0).

[0214] In step S803, upon receiving the GTP-U error indication, the UPF shall identify the involved PFCP session and send an error indication report to the SMF as specified in clause 5.10 of 3GPP TS29.244.

[0215] In step S804, for a GTP-U error indication received from the 5G-AN, the SMF shall modify the PFCP session to instruct the UPF to buffer downlink packets.

[0216] In step S805, if the user plane connection of the PDU session is considered to be activated by the SMF, the SMF shall initiate a Namf_Communication_N1N2MessageTransfer service operation to request the 5G-AN to release the resources of the PDU session, as specified in clause 4.3.7 of 3GPP TS23.502.

[0217] In step S806, upon receiving a Namf_Communication_N1N2MessageTransfer request to transfer a PDU session resource release command, the AMF shall do the following: - if the UE is in CM-CONNECTED state for the access network type associated with the PDU session, proceed with the request as specified in clause 5.2.2.3.1 of 3GPP TS 29.518; - Otherwise, reject the request with an error indicating that the UE is in CM-IDLE state for the access network type associated with the PDU session.

[0218] In step S807, when the AMF sends a PDU session resource release command to the 5G-AN, the PDU session resource release is acknowledged by the SMF.

[0219] In step S808, the SMF initiates a network-triggered service request procedure specified in clause 4.2.3.3 of 3GPP TS23.502 to reactivate the user plane connection of the PDU session.

[0220] FIG. 9 illustrates an example NG reset procedure and an example NG setup procedure to which RAN node failure / restart detection and / or restoration according to some embodiments of the present disclosure are applicable.

[0221] As shown in Figure 9(a), an NG reset initiated by the NG-RAN node is provided.

[0222] In the event of a failure in the NG-RAN node resulting in the loss of some or all transaction reference information, an NG reset message shall be sent to the AMF in step S905.

[0223] On receipt of the NG Reset message, the AMF shall release all allocated resources for the NG related to the UE association(s) explicitly or implicitly indicated in the NG Reset message and delete the NGAP ID for the indicated UE association(s).

[0224] After the AMF has released all allocated NG resources and UE NGAP IDs for all indicated UE associations that may be used for new UE-associated logical NG-connections on the NG interface, the AMF shall respond with an NG Reset Acknowledgement message in step S910.

[0225] If the NG Reset message contains a UE-associated Logical NG Connection List IE, - The AMF shall use the AMF UE NGAP ID IE and / or the RAN UE NGAP ID IE to explicitly identify the UE association(s) to be reset. - The AMF shall include in the NG Reset Acknowledge message the UE Associated Logical NG Connection Item IE in the UE Associated Logical NG Connection List IE for each UE association to be reset. The UE Associated Logical NG Connection Item IEs shall be in the same order as received in the NG Reset message and shall also include unknown UE associated logical NG connections. An empty UE Associated Logical NG Connection Item IE received in the NG Reset message may be omitted in the NG Reset Acknowledge message. - If the AMF UE NGAP ID IE is included in the UE-associated Logical NG Connection Item IE for the UE association, the AMF shall include the AMF UE NGAP ID IE in the corresponding UE-associated Logical NG Connection Item IE in the NG Reset Acknowledgement message. - If the RAN UE NGAP ID IE is included in the UE-associated Logical NG Connection Item IE for the UE association, the AMF shall include the RAN UE NGAP ID IE in the corresponding UE-associated Logical NG Connection Item IE in the NG Reset Acknowledgement message.

[0226] Interaction with other procedures: When an NG Reset message is received, any other ongoing procedures (except another NG Reset procedure) on the same NG interface related to the UE association, either explicitly or implicitly indicated in the NG Reset message, shall be aborted.

[0227] As shown in Figure 9(b), an NG setup is provided that is initiated by the NG-RAN node.

[0228] The purpose of the NG setup procedure is to exchange application level data required for the NG-RAN node and the AMF to interoperate correctly over the NG-C interface. This procedure shall be the first NGAP procedure triggered after the TNL association is operational. The procedure uses non-UE related signaling.

[0229] This procedure clears the existing application level configuration data in the two nodes, replaces the application level configuration data with the received one, and clears the AMF overload state information in the NG-RAN node. If the NG-RAN node and the AMF do not agree to retain the UE context, this procedure also reinitializes the NGAP UE related context (if any) and clears all related signaling connections in the two nodes, as does the NG reset procedure.

[0230] In step S915, the NG-RAN node initiates the procedure by sending an NG SETUP REQUEST message containing appropriate data to the AMF, which responds in step S920 with an NG SETUP RESPONSE message containing appropriate data.

[0231] If a Configure TAC Indication IE set to 'true' is included in the NG Setup Request message for a tracking area included in the Supported TA List IE, the AMF may take that Configure TAC Indication IE into account to optimize NG-C signaling towards this NG-RAN node.

[0232] If the UE Retention Information IE set to "ues-retained" is included in the NG Setup Request message, the AMF may accept a proposal to retain the existing UE-related context and signaling connection by including the UE Retention Information IE set to "ues-retained" in the NG Setup Response message.

[0233] If the AMF supports IAB, the AMF shall include the IAB support IE in the NG Setup Response message.

[0234] The AMF shall include the Backup AMF Name IE, if available, in the Served GUAMI List IE in the NG Setup Response message. If supported, the NG-RAN node shall consider the AMF as indicated by the Backup AMF Name IE when performing AMF reselection as specified in TS 23.501.

[0235] If the GUAMI Type IE is included in the NG Setup Response message, the NG-RAN node shall store the received value and use it for further AMF selection as specified in TS 23.501.

[0236] If the RAN Node Name IE is included in the NG Setup Request message, the AMF may use this IE as the human readable name of the NG-RAN node. If the Extended RAN Node Name IE is included in the NG Setup Request message, the AMF may use this IE as the human readable name of the NG-RAN node and shall ignore the RAN Node Name IE if also included.

[0237] If the AMF Node Name IE is included in the NG Setup Response message, the NG-RAN node may use this IE as the human readable name of the AMF. If the Extended AMF Name IE is included in the NG Setup Response message, the NG-RAN node may use this IE as the human readable name of the AMF and shall ignore the AMF Name IE if also included.

[0238] If the NB-IoT Default Paging DRX IE is included in the NG Setup Request message, the AMF shall take the NB-IoT Default Paging DRX IE into account for paging.

[0239] If the RAT Information IE is included in the NG Setup Request message, the AMF shall handle this information as specified in TS 23.502.

[0240] If the NID IE in the NPN Support IE is included in the Broadcast PLMN Item IE in the NG Setup Request message, the AMF shall consider that the NG-RAN node supports the indicated S-NSSAI(s) for the corresponding Tracking Area Code(s) for the SNPN identified by the PLMN Identity IE and the NID IE.

[0241] If the NID IE in the NPN Support IE is included in the PLMN Support Item IE in the NG Setup Response message, the NG-RAN node shall consider that the AMF supports the SNPN identified by the PLMN Identity IE and the NID IE.

[0242] RFC4960 specifies the following regarding SCTP path failures: When its peer endpoint is multi-homed, an endpoint should maintain an error counter for each of the peer endpoint's destination transport addresses.

[0243] Whenever the T3-rtx timer expires for any address, or when a heartbeat sent to an idle address is not acknowledged within the RTO, the error counter for that destination address will be incremented.

[0244] When the value in the error counter exceeds the protocol parameter "Path.Max.Retrans" for that destination address, the endpoint should mark the destination transport address as inactive and a notification should be sent to upper layers.

[0245] When an outstanding TSN is acknowledged, or a heartbeat sent to that address is acknowledged with a Heartbeat ACK, the endpoint SHALL clear the error counter for the destination transport address to which a data chunk was last sent (or to which a heartbeat was sent). When a peer endpoint is multihomed and the last chunk sent to the peer endpoint was a retransmission to an alternate address, there is ambiguity as to whether the acknowledgment should be attributed to the address of the last chunk sent. However, this ambiguity does not appear to have significant consequences for SCTP behavior. If this ambiguity is undesirable, the sender may choose not to clear the error counter if the last chunk sent was a retransmission.

[0246] Note: When configuring an SCTP endpoint, users should avoid having a value for "Association.Max.Retrans" that is greater than the sum of the "Path.Max.Retrans" of all destination addresses for the remote endpoint. Otherwise, all destination addresses may become inactive and the endpoint will still consider the peer endpoint reachable. How SCTP chooses to function when this condition arises is implementation specific.

[0247] When a primary route is marked inactive (e.g., due to excessive retransmissions), the sender may automatically send new packets to an alternate destination address, if one exists and is active. If two or more alternate addresses are active when the primary route is marked inactive, only one transport address should be selected and used as the new destination transport address.

[0248] AMF Events,The following is quoted from TS29.518 for AMF support events. The AMF may offer this service as a service producer to allow NFs to subscribe to event notifications and be notified about events, either by themselves or on behalf of another NF. Known service consumers are the NEF, SMF, UDM, NWDAF, DCCF, LMF, and GMLC. See also clause 5.34.7 of 3GPP TS 23.501 and clauses 4.15.1, 4.15.3.2, 4.15.4.2, and 5.2.2.3.1 of 3GPP TS 23.502, and clause 6.2.2 in 3GPP TS 23.288.

[0249] The following events are provided by the Namf_EventExposure service: Event: Location Report The NF subscribes to this event to receive the last known location or current location of a UE or group of UEs or any UE and the updated location of any of these UEs when the AMF notices a location change of any of these UEs with the requested granularity. This event implements the "Location Report" event in Table 4.15.3.1-1 of 3GPP TS23.502. UE type: single UE, group of UEs, any UE Report type: One-time report, continuous report (see Note 1), periodic report (see Notes 1 and 2) Input: (One or more) UE-ID(s), "ANY_UE", optional filters: TAI, Cell ID, N3IWF, UE-IP, UDP port, TNAP ID, TWAP ID, Global Line Id Notification: UE-ID, filtered updated location (TAI, Cell ID for 3GPP access, nearest N3IWF node, UE local IP address and UDP source port number for non-3GPP access, TNAP ID, TWAP ID, Global Line Id). NOTE 1: Support for continuous or periodic reporting should be controlled by operator policy. NOTE 2: For periodic reporting, if the UE is in CM-IDLE state when the report is generated, the last known location of the UE is reported.

[0250] Event: Presence-In-AOI Report An NF subscribes to this event to receive the current presence status of a UE, a group of UEs, or any UE in a particular Area of ​​Interest (AOI) and notification when a specified UE enters or leaves the specified area. The area may be identified by a TA list, an area ID, or a specific Area of ​​Interest name such as "LADN." UE type: single UE, group of UEs, any UE Report type: One-time report, continuous report Input: (one or more) UE ID(s), "ANY_UE", Area Identifier (TA List, AreaId or "LADN"), S-NSSAI, NSI ID. Notification: UE-ID(s), Area Identifier, Presence Status (IN / OUT / UNKNOWN)

[0251] Event:Time Report The NF subscribes to this event to receive the current time zone of a UE or a group of UEs and the updated time zone of the UE or any UE in its group when the AMF notices a time zone change for the UE. UE type: single UE, group of UEs Report type: One-time report, continuous report Input: UE ID(s) Notification: UE-ID, latest time period

[0252] Event:Access Type Report The NF subscribes to this event to receive the current access type(s) of a UE or a group of UEs or any UE, and the updated access type(s) of any of these UEs when the AMF notices an access type change for any of these UEs. The area may be identified by a TA list, an area ID, or a specific area of ​​interest name such as "LADN". UE type: single UE, group of UEs, any UE Report type: One-time report, continuous report Input: UE ID(s), "ANY_UE", optionally filter: Area Identifier (TA List, Area Id or "LADN") Notification: UE ID, most recent access type (3GPP, non-3GPP)

[0253] Event: Registration status report An NF subscribes to this event to receive the current registration state of a UE or a group of UEs or any UE, and reports on the updated registration state of any of these UEs when the AMF notices a registration state change for any of these UEs. The area may be identified by a TA list, an area ID, or a specific area of ​​interest name such as "LADN". UE type: single UE, group of UEs, any UE Report type: One-time report, continuous report Input: UE ID(s), "ANY_UE", optionally filter: Area Identifier (TA List, Area Id or "LADN") Notification: UE ID, last registration status (REGISTERED / DEREGISTERED) with access type

[0254] Event: Connectivity Status Report The NF subscribes to this event to receive the current connection management state of the UE or group of UEs and reports on the updated connection management state of the UE or any UE in the group when the AMF notices a change in the connection management state of the UE. UE type: single UE, group of UEs Report type: One-time report, continuous report Input: UE ID(s) Notification: UE ID, most recent connection management state with access type (IDLE / CONNECTED)

[0255] Event: Reachability Report The NF subscribes to this event for "UE Reachability Status Change" to receive the current reachability state of a UE or a group of UEs in the AMF and reports on the updated reachability state of the UE or any UE in the group when the AMF notices a reachability state change of the UE between REACHABLE, UNREACHABLE and REGULATORY_ONLY. The following conditions apply: - the AMF shall send a reachability report ("UNREACHABLE") if the mobile reachable timer expires (see 3GPP TS 23.501 clause 5.4.1.1) or if the UE enters CM-IDLE when the UE is only registered on non-3GPP access (see 3GPP TS 23.501 clause 5.5.3); - the AMF shall send a reachability report ("REGULATORY_ONLY") if the UE is only reachable due to restricted priority services (see clause 4.15.4.2 of 3GPP TS 23.502); - The AMF shall send a reachability report ("REACHABLE") when the UE reachability state changes from one of the two above states to REACHABLE. NOTE 3: The AMF does not send reachability reports ("UNREACHABLE"), in particular when the UE enters an extended DRX cycle (see clause 5.31.7.2.2.3 of 3GPP TS 23.501 [2]), when the UE enters a power saving state (see clause 5.31.8 of 3GPP TS 23.501 [2]), when the UE enters CM IDLE in MICO mode (see clause 5.4.1.3 of 3GPP TS 23.501 [2]), or when the UE does not respond to paging requests. The NF subscribes to this event for "UE reachable for DL ​​traffic" to receive a report of a UE or a group of UEs when they become reachable for sending downlink data. In this case, the event is detected when the UE transitions to CM-CONNECTED mode or when the UE becomes reachable for paging, as specified in Table 4.15.3.1-1, clauses 4.2.5 and 4.3.3 of 3GPP TS 23.502. When reporting "UE reachable for DL ​​traffic", the AMF shall also indicate the access type with which the UE is reachable. NOTE 4: The AMF will not send an event report for "UE reachable for DL ​​traffic" immediately after UECM registration in UDM if the AMF was previously instructed that a reachability event will be detected in the UDM. The UDM will detect UE reachability from the UECM registration and send a notification to the NF consumer (unless the UDM is instructed that the UE is not currently reachable as specified in clause 5.3.2.2.2 of 3GPP TS29.503), and therefore the notification report from the AMF is omitted. UE type: single UE, group of UEs Report type: One-time report, continuous report Input: UE ID(s), (optional) reachability filter Notification: UE ID, AMF Id, most recent reachability state (REACHABLE / UNRACHABLE / REGULATORY_ONLY), access type(s) over which the UE is reachable.

[0256] Event: Communication failure report The NF subscribes to this event to receive a communication failure report for a UE, a group of UEs, or any UE when the AMF notices a RAN or NAS failure event. This event implements the "Communication Failure" event in Table 4.15.3.1-1 of 3GPP TS23.502, which is the unexpected termination of communication. UE type: single UE, group of UEs, any UE Report type: One-time report, continuous report Input: UE ID(s), "ANY_UE", optionally filter: Area Identifier (TA List, Area Id or "LADN") Notification: UE ID, RAN / NAS release code.

[0257] Event: UE reported in area The NF subscribes to this event to receive the number of UEs in a particular area. The NF may ask the AMF about UEs in the area based on their last known location, or the NF may request the AMF to actively search for UEs in the area based on their current location. This event implements the "Number of UEs present in a geographical area" event in Table 4.15.3.1-1 of 3GPP TS23.502. UE Type: Any UE Input: "ANY_UE", optionally Ue filter in area: UE aerial indication, indication of PDU sessions established for one or more DNNs that are subject to aerial service Report Type: One-time report (see Note 3), continuous report (see Note 4), periodic report (see Note 4) Input: Areas identified in the TA list Notification: Number of UEs in the area NOTE 5: For immediate reporting, the last known location of the UE is used to count the UEs in the area. NOTE 6: Support for continuous or periodic reporting should be controlled by the operator.

[0258] Event: Loss of connectivity The NF subscribes to this event to receive event reports for a UE or a group of UEs when the AMF detects that the target UE is no longer reachable for either signaling or user plane communication. Such conditions are identified when the mobile reachable timer expires in the AMF (see 3GPP TS23.501 [2]), when the UE disconnects, and when the AMF deregisters from the UDM for an active UE. If the UE is no longer reachable for either signaling or user plane communication when the event is subscribed, the AMF reports the event directly. This event implements the "Loss of Connectivity" event in Table 4.15.3.1-1 of 3GPP TS23.502. UE type: single UE, group of UEs. Report type: One-time report, continuous report Input: UE ID(s) Notification: UE ID.

[0259] Event: 5GS user status report The NF subscribes to this event to receive the 5GS user state of the UE. UE Type: 1 UE Report Type: One-time report Input: UE ID(s) Notification: UE ID, 5GS user status

[0260] Event: Availability after DDN failure The NF subscribes to this event to be informed about the availability of the UE after a DDN failure. UE type: single UE, group of UEs Report type: One-time report, continuous report Input: UE ID(s) Notification: UE ID(s)

[0261] Event: Type assignment code report An NF subscribes to this event to receive the TAC of a UE or a group of UEs or any UE. UE type: single UE, group of UEs, any UE Report type: One-time report, continuous report Input: (one or more) UE ID(s), "ANY_UE", optionally filter: TAI, Area Identifier (TA List, Area Id or "LADN") Notification: UE ID(s), TAC(s)

[0262] Event: Frequent mobility registration reports The NF subscribes to this event to receive the number of mobility registrations during a period for a UE or a group of UEs or any UE. UE type: single UE, group of UEs, any UE Report type: One-time report, continuous report Input: UE ID(s), expiry time, "ANY_UE", optionally filter: Area Identifier (TA List, Area Id or "LADN") Notification: UE ID(s), frequent registration

[0263] Event: SNSAI TA Mapping Report The NF subscribes to this event to receive the relevant access types and the list of supported S-NSSAIs. UE Type: Any UE Report type: One-time report, continuous report Input: Target Area: TA list or "ANY_TAI", optionally filter: (one or more) S-NSSAI Notification: List of supported S-NSSAIs with indication of access type, restriction in AMF

[0264] If a multicast MBS session is lost in an NG-RAN due to an NG-RAN failure or re-initiation, it may not be possible to restore it, and therefore subscribed UEs in the coverage of that NG-RAN may not be able to receive the multicast MBS service.

[0265] When the NG-RAN restarts, the NG-RAN will lose all its session context, including those MBS multicast sessions served by the NG-RAN. As specified in clause 7.2.1 of TS 23.247 (see also section 2.1.1.5), only the SMF knows which UEs have subscribed to an MBS multicast session, i.e., whether a PDU session is associated with the multicast session. Therefore, after an NG-RAN restart, only the SMF can restore the MBS session in the NG-RAN. Therefore, the SMF needs to learn of the NG-RAN failure or restart. In some embodiments of the present disclosure, the NG-RAN failure or restart may be detected via the control plane and / or the user plane.

[0266] In some embodiments, the NG-RAN failure / restart may be detected and recovered via the control plane. After recovering from the restart or (partial) failure, the NG-RAN may notify the AMF of the (partial) failure or restart using an NG Setup Request or NG Reset as specified in 3GPP TS38.413, as described with reference to FIG. 9.

[0267] As specified in clause 8.2 of RFC4960 for SCTP (see section 2.1.4), which is the transport layer protocol for NGAP on the N2 interface, the AMF is also capable of detecting NG-RAN failures with re-initiation. Thus, detection of NG-RAN failures with or without re-initiation can be performed by the AMF without any protocol impact, in accordance with existing specifications.

[0268] The AMF may inform the MB-SMF of the NG-RAN restart / failure, and the MB-SMF may instruct the MB-UPF to clean up N3mb tunnel information, if applicable.

[0269] Scenario 1: AMF informs SMF of NG-RAN restart / failure When an NG-RAN restart / failure is detected in the AMF, in some embodiments, such a failure may be reported by the AMF to the SMF using different options as follows: - Per UE signaling messages: - AMF-SMF Option 1: via per-PDU session signaling, extended with new indications for NG-RAN restart / failure. - AMf-SMF Option 2: One message for one UE using Nsmf_Ng_Reset or another new service behavior mechanism of the SMF. - One message for all UEs camped on the NG-RAN that experience a restart / failure: - AMF-SMF Option 3: One message using Nsmf_Ng_Reset or another new service action mechanism of the SMF contains a list of UEs served by the NG-RAN that have experienced a failure or a re-initiation. - AMF-SMF option 4: The SMF may subscribe to new NG-RAN failure or re-initiation events given by the Namf_EventExposure service, and the AMF may report NG-RAN re-initiation / failure events to the SMF if those PDU sessions (with active user plane RAN resources) are anchored at the SMF. When reporting such an event, the AMF shall also provide the SMF with a list of UEs and their PDU sessions affected by the NG-RAN failure (see below for details on AMF events).

[0270] If a per-UE signaling message is used by the AMF to inform the SMF of the NG-RAN restart, the SMF may instruct the UPF to release the N3 tunnel, if any. If the affected PDU session is associated with an active MBS session, the SMF may initiate a PDU session modification procedure to provide the NG-RAN with UE subscription information.

[0271] If one message for a list of UEs is used by the AMF to inform the SMF of the NG-RAN restart, the SMF may instruct the UPF to release the N3 tunnel for the affected UE / PDU session(s), and the SMF may then initiate a PDU session modification procedure for each UE, or the SMF may initiate an enableGroupReachability request to the AMF with the list of UEs and the PDU session IDs associated with the active MBS sessions, as detailed below.

[0272] In some embodiments, the NG-RAN failure / restart can be detected and restored via the user plane. Both the UPF and MB-UPF can detect the NG-RAN failure / restart.

[0273] Part 1) NG-RAN Restart or Failure Detected by UPF: - UPF receiving a GTP-U error indication The restarted NG-RAN will not recognize the DL F-TEID assigned by the NG-RAN before the restart for a given PDU session (associated with the MBS session), and therefore the NG-RAN will send a GTP-U error indication. The GTP-U error indication will then be reported to the SMF. The SMF will be able to know which PDU sessions are affected by the NG-RAN restart.

[0274] In that case, the SMF then releases the N3 tunnel information.

[0275] If the affected PDU session is associated with an active MBS session, the SMF invokes the Namf_Communication_N1N2MessageTransfer message to provide the NG-RAN with the UE subscription information. A new instruction for NG-RAN restart is also included in the N2 SM container of the N1N2MessageTransfer message. - The UPF performs the path management procedure towards the NG-RAN

[0276] The UPF may periodically send an echo request message to the NG-RAN to detect the activity of the GTP-U path identified by the IP address in the DL F-TEID. Thus, the UPF will be able to detect an NG-RAN restart or a GTP-U path failure towards the NG-RAN. The UPF may report the GTP-U path failure or NG-RAN restart to the SMF. In that case, the SMF may need to resolve the PDU session affected by the NG-RAN restart or failure and request the AMF to perform paging for the affected UE(s) indicating the NG-RAN failure / restart, as described below.

[0277] Part 2) NG-RAN re-initiation or failure of NG-RAN detected by MB-UPF: When unicast transport over N3mb is used, The restarted NG-RAN will not recognize the DL F-TEID assigned by the NG-RAN before the restart, and therefore the NG-RAN will send a GTP-U error indication for the DL MBS session data, which will be further reported to the MB-SMF. - The MB-UPF will periodically send out an echo request message to detect the liveness of the GTP-U path identified by the IP address in the DL F-TEID. Thus, the MB-UPF will be able to detect a GTP-U path failure towards the NG-RAN, and if a failure is detected, the MB-UPF will also report to the MB-SMF.

[0278] When multicast transport over N3mb is used, - The NG-RAN will join the multicast group, i.e., the MBS session data will be retrieved from the lower layer source-specific multicast address assigned by the MB-UPF. The MB-UPF will be unaware of whether there is an NG-RAN restart or failure.

[0279] Here, the MB-UPF may require an additional transport IP address.

[0280] When the MB-SMF is notified by the MB-UPF about the NG-RAN restart / failure, the MB-SMF may instruct the MB-UPF to clean the N3mb DL tunnel information, if available.

[0281] In both the above options (control plane option and user plane option), it is also possible to have the MB-SMF inform the SMF to trigger restoration after the MB-SMF has been informed by the AMF (control plane option) or the MB-UPF (user plane option).

[0282] In this scenario, when the MB-SMF is notified by the MB-UPF about the NG-RAN restart / failure, and if the MB-SMF has the mapping information between the NG-RAN ID and the IP address of the NG-RAN, the following is performed: - The MB-SMF informs the SMF that the NG-RAN has restarted or failed in the following manner: - The SMF finds the AMF using the NG-RAN ID as an input parameter by querying the NRF (implying that the NG-RAN ID must be included in the AMF profile). - The SMF then sends the list of subscribed UEs and the IDs of the PDU sessions associated with the active MBS sessions to the AMF(s). The SMF also includes an indication that there is an NG-RAN restart / failure. The AMF then resolves the list of UEs belonging to the failed / restarted NG-RAN and pages those UEs. After the UEs return, the SMF adds those UEs back to the NG-RAN with an NG-RAN restart / failure indication in the N2 message container.

[0283] In some embodiments, to restore a multicast MBS session, the MB-SMF may need to be aware of the NG-RAN ID and maintain a mapping between the NG-RAN and NG-RAN tunnel information or IP addresses. When an NG-RAN failure or re-initiation is detected, the SMF may be notified. The SMF may release the N3 tunnel towards the NG-RAN, if necessary, and then provide the NG-RAN with the subscribed UE information again for the active MBS session.

[0284] In some embodiments of the present disclosure, if a multicast MBS session is lost in an NG-RAN due to an NG-RAN restart or failure, the multicast MBS session may be restored by 5GC. Thus, the multicast MBS service may be restored so that UEs within an area served by the restarted NG-RAN can continue to receive the MBS service.

[0285] FIG. 10 illustrates an example procedure for establishing share distribution towards an NG-RAN node, in accordance with some embodiments of the present disclosure.

[0286] An additional parameter, NG-RAN ID, may be provided either by the NG-RAN or by the AMF, as shown in Figure 10. A shared tunnel for shared distribution may be established between the NG-RAN and the MB-UPF if: - The first UE is included in the context of an MBS session in the NG-RAN. NOTE 1: When an MBS session is deactivated, if there is at least one UE in the NG-RAN that is in connected mode and subscribes to the MBS session, the shared distribution is not released. NOTE 2: When an MBS supporting NG-RAN node(s) is / are involved in an MBS session at MBS session activation, the Share Delivery Establishment procedure may be used. - Handover to the target NG-RAN when a shared distribution tunnel is not established in the target RAN node for this MBS session.

[0287] In step S1001, when the NG-RAN node 205 serves at least one UE in the MBS session, the NG-RAN node 205 may determine to establish shared distribution for the MBS session. For location-dependent services, if the NG-RAN node 205 serves at least one UE allocated to an MBS session ID and an area session ID, the NG-RAN node 205 may need to establish shared distribution for location-dependent content of the MBS session.

[0288] In step S1002, the NG-RAN 205 may send an N2 MBS session request message (MBS Session ID, N2 SM Information (MBS Session ID, [Unicast Tunnel Information], [Area Session ID])) toward the AMF 225.

[0289] If the NG-RAN node 205 is configured to use unicast transport for shared distribution, the NG-RAN node 205 may allocate GTP tunnel endpoints and provide unicast tunnel information in the request, where the unicast tunnel information includes the GTP tunnel endpoints and the NG-RAN node address. For location-dependent MBS services, the NG-RAN node 205 may also provide an area session ID.

[0290] Additionally, the NG-RAN 205 may also include the NG-RAN ID in the message.

[0291] In step S1003, the AMF 225 may use the NRF discovery service to select the MB-SMF 235 that will serve the multicast session. The AMF 225 may invoke a Nmbsmf_MBSSession_ContextUpdate request (MBS Session ID, N2 SM information) to the MB-SMF 235.

[0292] The AMF 225 may store information about the NG-RAN node (e.g., the NG-RAN node ID) for subsequent signaling related to the MBS session.

[0293] Additionally, the AMF 225 may also include the NG-RAN ID in the message.

[0294] In step S1004, if MB-SMF235 received unicast tunnel information in step S1003, MB-SMF235 may configure MB-UPF215 to send multicast data for the multicast session (or location-dependent content for the multicast session if an area session ID was received) towards that GTP tunnel endpoint via unicast transport.

[0295] In step S1005, the MB-SMF 235 may store the AMF 225 in the multicast session context (or in the location-dependent part of the multicast session context if an area session ID is received) to enable subsequent signaling towards that NG-RAN node.

[0296] Additionally, the MB-SMF 235 may maintain a mapping between the NG-RAN ID and DL N3mb tunnel information (i.e., NG-RAN N3mb tunnel information).

[0297] In step S1006, MB-SMF 235 may send an Nmbsmf_MBSSession_ContextUpdate response (MBS Session ID, N2 SM information ([TMGI], Multicast QoS flow information, [Transport Multicast Address], [Multicast Tunnel Information])) to AMF 225. If MB-SMF 235 did not receive unicast tunnel information in step S1003, MB-SMF 235 may provide a transport multicast address (e.g., LL SSM) and a GTP tunnel endpoint for multicast transport of shared delivery.

[0298] In step S1007, the AMF 225 may send an N2 MBS session response (MBS session ID, N2 SM information) to the NG-RAN node 205. If the NG-RAN node 205 receives the transport multicast address and multicast tunnel information for shared distribution, the NG-RAN node 205 may use the transport multicast address to join the multicast transport distribution.

[0299] As an embodiment of the above-mentioned AMF-SMF option 4, new AMF events may be provided or existing AMF events may be reused with extensions.

[0300] The following communication failure reports may be used: (Reused) Event: Communication failure report The NF subscribes to this event to receive a communication failure report for a UE, a group of UEs, or any UE when the AMF notices a RAN or NAS failure event. This event implements the "Communication Failure" event in Table 4.15.3.1-1 of 3GPP TS23.502, which is the unexpected termination of communication. UE type: single UE, group of UEs, any UE Report type: One-time report, continuous report Input: UE ID(s), "ANY_UE", optionally filter: Area Identifier (TA List, Area Id or "LADN") Notification: UE ID, RAN / NAS release code.

[0301] Or, a new event: (New) Event: NG-RAN Failure Report The NF subscribes to this event to receive NG-RAN failure reports for any UEs that have a resource context created at the NF service consumer when the AMF notices an NG-RAN failure or re-initiation. For example, the SMF may subscribe to this event to request the AMF to report such events if those PDU sessions with user plane resources affected by the NG-RAN failure / re-initiation are anchored at that SMF. UE Type: Any UE Report Type: Continuous Report Input: "ANY_UE", NF Service Consumer Service Instance Id, e.g. smfServiceInstanceId, or Resource URI authority. Notification: UE ID(s), NG-RAN re-start or failure indication.

[0302] The NF Service Consumer Service Instance Id, or the authority of the resource URI, is to enable the AMF to determine to which SMFs those affected PDU sessions relate, so that the AMF can send notification reports to those SMFs.

[0303] In some embodiments, some methods for detecting NG-RAN failure / restart via control plane solutions and restoration may be described with reference to Figure 11. In some embodiments, upon NG-RAN failure or after NG-RAN restart, the NG-RAN may send an NG Setup Request or an NG Reset Request to the AMF.

[0304] FIG. 11 illustrates several example methods for detecting a failure and / or re-initiation of a RAN node at a CP, according to some embodiments of the present disclosure.

[0305] As shown in FIG. 11, in step S1101, the NG-RAN 205 may send an NG setup request or an NG reset request to the AMF 225.

[0306] In step S1102, the AMF 225 may respond with an NG setup response or an NG reset response to the NG-RAN 205.

[0307] A first method for detecting NG-RAN failure / restart may involve steps S1103 to S1105.

[0308] In step S1103, the AMF 225 may identify the multicast MBS sessions involving the NG-RAN 205. For each multicast MBS session, the AMF 225 may inform the MB-SMF 235 that a particular NG-RAN 205 has experienced a failure or re-initiation by calling Nmbsmf_MBSSession_ContextUpdate, which includes the MBS session ID and the NG-RAN ID.

[0309] In step S1104, for unicast transport on N3mb, MB-SMF 235 may send an N4mb session modify request to MB-UPF 215 to release the N3mb DL tunnel. MB-UPF 215 may release the N3mb DL tunnel and send an N4mb session modify response to MB-SMF 235.

[0310] In step S1105, MB-SMF235 may send an Nmbsmf_MBSSession_ContextUpdate response to AMF225.

[0311] The second to fifth methods for detecting NG-RAN failure / restart may involve steps S1106a to S1106d.

[0312] In step S1106, the AMF 215 may identify the UEs served by the NG-RAN 205 that experienced the failure or re-initiation.

[0313] In step S1106a, AMF215 may inform SMF230 of the NG-RAN failure / restart by sending an Nsmf_PDUSession_UpdateSMContext request to the associated SMF230 for each PDU session.

[0314] In step S1106b, AMF215 may inform SMF230 of the NG-RAN failure / restart using Nsmf_Ng_Reset or another new SMF service operation for each affected PDU session.

[0315] In step S1106c, AMF215 may inform SMF230 of the NG-RAN failure / restart using Nsmf_Ng_Reset with the affected UE / PDU session list.

[0316] In step S1106d, AMF215 may send an NG-RAN restart event to SMF230 with the affected UE / PDU session list.

[0317] Upon detection of NG-RAN failure / restart, in step S1107, for PDU sessions of UEs that have joined the MBS session, SMF230 may perform multicast MBS session restoration as described with reference to FIG. 13.

[0318] In some embodiments, some methods for detecting NG-RAN failure / restart via user plane solutions and restoration may be described with reference to FIG. 12.

[0319] 12 illustrates several example methods for detecting a failure and / or restart of a RAN node in a UP, according to some embodiments of the present disclosure. As shown in FIG. 12, user plane failure detection can consist of two parts. Part 1: (Steps S1201 to S1204), MB-UPF 215 may detect and report loss of GTP-U context, and MB-UPF 215 may detect / report path failure towards NG-RAN or NG-RAN re-initiation.

[0320] The restarted NG-RAN 205 will not recognize the DL F-TEID in the GTP-U packet received in step S1201, which was assigned by the NG-RAN 205 before its restart, and therefore, the NG-RAN 205 will send a GTP-U error indication for the DL MBS session data in step S1202. The GTP-U error indication may be further reported to the MB-SMF 235 in step S1203.

[0321] In addition to error indication, it is also possible to have user plane path management. The MB-UPF 215 may periodically send an echo request message to detect the liveness of the GTP-U path identified by the IP address in the DL F-TEID. Thus, the MB-UPF 215 may be able to detect a GTP-U path failure towards the NG-RAN, and if a failure is detected, the MB-UPF 215 may also report to the MB-SMF.

[0322] For unicast transport of N3mb, the MB-UPF 215 may obtain a transport IP address from the DL tunnel. For multicast transport of N3mb, the MB-UPF 215 may need an additional transport IP address.

[0323] After reporting the user plane path failure, the MB-SMF 235 may determine the affected PFCP sessions associated with the MBS session.

[0324] Part 2: (Steps S1205 to S1208) UPF 210 may detect and report loss of GTP-U context, and UPF may detect / report path failure towards NG-RAN or NG-RAN re-initiation as specified in TS23.527 Section 5.2.

[0325] The restarted NG-RAN will not recognize the DL F-TEID in the GTP-U packet received in step S1205, which was assigned by NG-RAN 205 for the given PDU session (associated with the MBS session) before its restart, and therefore NG-RAN 205 will send a GTP-U error indication. The GTP-U error indication may be further reported to SMF 230. SMF 230 may be able to know which PDU sessions are affected by the NG-RAN restart.

[0326] In addition to error indication, there may be user plane path management. The UPF 210 may periodically send an echo request message to detect the liveness of the GTP-U path identified by the IP address in the DL F-TEID. Thus, the UPF 210 may be able to detect a GTP-U path failure towards the NG-RAN 205, and if a failure is detected, the UPF 210 may also report to the SMF 230.

[0327] After reporting the user plane path failure, the SMF 230 may determine the affected PFCP session associated with the MBS session.

[0328] In step S1209, SMF230 may restore the multicast MBS session as described with reference to FIG.

[0329] Figure 13 illustrates an example procedure for SMF-initiated multicast MBS session restoration according to some embodiments of the present disclosure. As shown in Figure 13, an SMF 230-triggered restoration procedure is provided without notification from the MB-SMF 235. The restoration procedure is similar to steps S703 to S710b in the MBS session activation procedure shown in Figures 7A and 7B, and therefore, detailed descriptions of the same steps are omitted for brevity. Furthermore, it should be noted that this procedure may be a specific implementation of step S1107 shown in Figure 11 and / or step S1209 shown in Figure 12.

[0330] As shown in Figure 13, if the SMF 230 is informed by the UE list (e.g., steps S1106c, S1106d in Figure 11 and user plane path failure in Figure 12), step S1301 may be triggered and an NG-RAN restart indication may be included in the Namf_MT_EnableGroupReachability request sent from the SMF 230 to the AMF 225. If the UEs are in CM-IDLE mode due to the NG-RAN restart, the AMF 225 may accept the request and perform step S1303 for those IDLE UEs. Otherwise, the AMF 225 may reject the request or postpone the request until an NG-RAN setup or reset is received from the NG-RAN 205.

[0331] If SMF230 is notified in a per-UE manner (e.g., steps S1106a, S1106b in FIG. 11 or an error indication in FIG. 12), SMF230 may skip step S1301 and perform step S1302b directly.

[0332] In steps S1302b, S1305b, S1306b, in the N2 message container, SMF 230 may need to include an NG-RAN restart indication flag in the Namf_Communication_N1N2MessageTransfer request or Nsmf_PDUSession_UpdateSMContext response to AMF 215, so that in step S1307 the NG-RAN restart indication flag can be passed to NG-RAN 205. Based on this flag, NG-RAN 205 can take action to ensure that the UE is added to the multicast MBS session distribution.

[0333] Figure 14 illustrates an example procedure for MB-SMF-initiated multicast MBS session restoration according to some embodiments of the present disclosure. As shown in Figure 14, an SMF-triggered restoration procedure is provided with notification from the MB-SMF 235. The restoration procedure is similar to steps S701 to S710b in the MBS session activation procedure shown in Figures 7A and 7B, and therefore, detailed descriptions of the same steps are omitted for brevity. Furthermore, it should be noted that this procedure can be utilized when the MB-SMF detects an NG-RAN failure / restart, for example, after step S1103 in Figure 11 or after step S1203 in Figure 12.

[0334] 14, after detecting the NG-RAN 205 restart / failure in step S1401, the MB-SMF 235 may notify the SMF 230 about the NG-RAN restart. In this embodiment, the SMF 230 may perform the recovery based on the notification from the MB-SMF 235, rather than from the AMF 215 or the UPF 210.

[0335] In step S1402, MB-SMF 235 may inform all subscribed SMFs about the NG-RAN restart via Nmbsmf_MBSSession_ContextStatusNotify. In a request, MB-SMF 235 may need to inform SMF 230 to restore the MBS session due to the NG-RAN restart and include the NG-RAN ID in the message.

[0336] In step S1403, the SMF 230 may discover the AMFs connected to the restarted NG-RAN 205 by querying the NRF using the NG-RAN ID. The SMF 230 may then send a Namf_MT_EnableGroupReachability request to those AMFs to join the MBS session and provide a list of UEs served by the AMF 215. The SMF 230 may need to include an NG-RAN restart indication flag and the restarted NG-RAN ID.

[0337] In step S1404, the AMF 215 may determine the UEs affected by the NG-RAN 205 based on the NG-RAN ID and trigger step S1405 for those UEs.

[0338] In steps S1404b, S1407b, S1408b, in the N2 message container, the SMF may need to include an NG-RAN restart indication flag in the Namf_Communication_N1N2MessageTransfer request or Nsmf_PDUSession_UpdateSMContext response to the AMF 215, so that in step S1409 the NG-RAN restart indication flag can be passed to the NG-RAN 205. Based on this flag, the NG-RAN 205 can take action to ensure that the UE is added to the multicast MBS session distribution.

[0339] In some of the embodiments described above, if a multicast MBS session is lost in the NG-RAN due to an NG-RAN restart or failure, the multicast MBS session may be restored by the 5GC. Thus, the multicast MBS service may be restored so that UEs located in an area served by the restarted NG-RAN can continue to receive the MBS service.

[0340] FIG. 15 is a flowchart of an example method 1500 in an SMF for detecting a failure and / or re-initiation of a RAN node serving one or more UEs for a multicast session, provided in accordance with one embodiment of the present disclosure. Method 1500 may be implemented in a first network node (e.g., SMF 230 shown in FIG. 2). Method 1500 may include step S1510. However, the present disclosure is not limited thereto. In some other embodiments, method 1500 may include more steps, different steps, or any combination thereof. Furthermore, the steps of method 1500 may be implemented in a different order than described herein. Furthermore, in some embodiments, steps in method 1500 may be split into multiple sub-steps and implemented by different entities, and / or multiple steps in method 1500 may be combined into a single step.

[0341] The method 1500 may begin at step S1510, where a message may be received from a network node indicating a failure and / or restart of a RAN node.

[0342] In some embodiments, the network node comprises at least one of an AMF, a UPF, and a MB-SMF. In some embodiments, the messages include an Nsmf_PDUSession_UpdateSMContext request message sent from the AMF for a PDU session associated with one of the UEs, and a first message for one or more UEs and / or one or more PDU sessions, the first message being in accordance with 3GPP the message comprises at least one of: a first message which is a request message sent from the AMF to request for a service operation provided by the SMF not specified in TS23.502, V17.3.0 or any of its previous releases; a second message for a list of one or more UEs and / or a list of one or more PDU sessions, where the second message is an event notification message from the AMF to notify the SMF of a RAN node failure and / or re-start event; a third message for a PDU session, where the third message is a session report message from the UPF to report a RAN node failure and / or re-start; a fourth message for a node-level event, where the fourth message is a node report message from the UPF to report a RAN node failure and / or re-start; and a fifth message for a multicast session, where the fifth message is sent from the MB-SMF associated with the multicast session.

[0343] In some embodiments, the first message indicates one of a single UE and / or a single PDU session affected by the RAN node failure and / or re-initiation, and a list of one or more UEs and / or a list of one or more PDU sessions affected by the RAN node failure and / or re-initiation. In some embodiments, the second message indicates one of a communication failure reporting event and an AMF event not specified in any of 3GPP TS 23.502, V17.3.0 or earlier releases, or in any of 3GPP TS 29.518 V17.4.0 or earlier releases. In some embodiments, when the message comprises the second message, the method further includes, before receiving the message, sending to the AMF a message to subscribe to the event. In some embodiments, the message to subscribe to the event comprises at least one of: one or more IDs of the UEs or an “any UE” indication, one or more area identifiers, an NF service consumer service instance ID, and an authority of the resource URI. In some embodiments, the event comprises at least one of a RAN / NAS release code, one or more UE IDs, one or more PDU session IDs, and an NG-RAN restart or failure indication.

[0344] In some embodiments, the third message is a PFCP Session Report message comprising the TEID and an IP address associated with the failed RAN node. In some embodiments, the fourth message is a PFCP Node Report message comprising an IP address associated with the failed RAN node. In some embodiments, the fifth message is a Nmbsmf_MBSSession_ContextStatusNotify message comprising an indicator indicating the failure and / or re-initiation of the RAN node and / or the ID of the RAN node.

[0345] 16 is a flowchart of an example method 1600 in an SMF for restoring a multicast session for one or more UEs served by a RAN node that has experienced a failure and / or reinitiation, provided in accordance with one embodiment of the present disclosure. Method 1600 may be implemented in a first network node (e.g., SMF 230 shown in FIG. 2). Method 1600 may include step S1610. However, the present disclosure is not limited thereto. In some other embodiments, method 1600 may include more steps, different steps, or any combination thereof. Furthermore, the steps of method 1600 may be implemented in a different order than described herein. Furthermore, in some embodiments, steps in method 1600 may be split into multiple substeps and implemented by different entities, and / or multiple steps in method 1600 may be combined into a single step.

[0346] The method 1600 may begin at step S1610, where in response to detecting a failure and / or re-initiation of the RAN node, establishing associated resources at the RAN node may be triggered to receive multicast session data from either the UPF for individual delivery or the MB-UPF for shared delivery to restore the multicast session for at least one of the one or more UEs.

[0347] In some embodiments, the triggering step of establishing associated resources at the RAN node includes sending a sixth message to the RAN node via the AMF, causing the RAN node to initiate establishment of associated resources for the multicast session. In some embodiments, the sixth message comprises an indicator indicating a failure and / or re-initiation of the RAN node and / or an ID of the RAN node. In some embodiments, prior to the triggering step of establishing associated resources at the RAN node, the method further includes determining one or more UEs that have joined the multicast session and that are affected by the failure and / or re-initiation of the RAN node. In some embodiments, the determining step of the one or more UEs includes at least one of determining one or more UEs indicated in a received message from the AMF, where the received message further indicates a failure and / or re-initiation of the RAN node, and retrieving one or more UEs having the same IP address at a tunnel endpoint for a downlink tunnel at the RAN node to receive the multicast session data when the RAN failure or re-initiation is reported by the UPF.

[0348] In some embodiments, the method further includes sending a request message to the AMF to request the AMF to page one or more UEs to place the UEs in a CM-CONNECTED mode, the request message comprising an indicator indicating a failure and / or a restart of the RAN node; and receiving a response message from the AMF to indicate which of the one or more UEs are in the CM-CONNECTED mode. In some embodiments, prior to the step of triggering establishing associated resources at the RAN node, the method further includes receiving a fifth message from the MB-SMF indicating the detected failure and / or re-start of the RAN node and an identity of the RAN node, sending a request message to a Network Repository Function (NRF) to discover a list of AMFs that have association with the RAN node, receiving a response message from the NRF including the list of AMFs, selecting an AMF from the list of AMFs, sending a request message to the AMF to query one or more UEs affected by the failure and / or re-start of the RAN node and / or to request the AMF to page one or more UEs, wherein the request message comprises an indicator indicating the failure and / or re-start of the RAN node and / or an identity of the RAN node, and receiving a response message from the AMF comprising an acceptance of the one or more UEs and / or the paging. In some embodiments, the failure and / or re-start of the RAN node is detected by the SMF by the method described with reference to FIG. 15.

[0349] 17 is a flowchart of an example method 1700 in an AMF for facilitating a network node detecting a failure and / or re-initiation of a RAN node serving one or more UEs for a multicast session, provided in accordance with one embodiment of the present disclosure. Method 1700 may be implemented in a second network node (e.g., AMF 225 shown in FIG. 2). Method 1700 may include steps S1710 and S1720. However, the present disclosure is not limited thereto. In some other embodiments, method 1700 may include more steps, fewer steps, different steps, or any combination thereof. Furthermore, the steps of method 1700 may be implemented in a different order than described herein. Furthermore, in some embodiments, steps in method 1700 may be split into multiple sub-steps and implemented by different entities, and / or multiple steps in method 1700 may be combined into a single step.

[0350] The method 1700 may begin at step S1710, where a seventh message may be received from the RAN node reporting a failure and / or re-initiation of the RAN node.

[0351] In step S1720, in response to the received seventh message, a message may be sent to the network node indicating failure and / or restart of the RAN node.

[0352] In some embodiments, the network node comprises at least one of an SMF and an MB-SMF. In some embodiments, the messages comprise at least one of: an Nmbsmf_MBSSession_ContextUpdate request message sent to the MB-SMF for the multicast session, an Nsmf_PDUSession_UpdateSMContext request message sent to the SMF for a PDU session associated with one of the UEs, a first message for one or more UEs and / or one or more PDU sessions, where the first message is a request message sent to the SMF to request for a service operation provided by the SMF that is not specified in 3GPP TS23.502, V17.3.0 or any of its previous releases, and a second message for a list of one or more UEs and / or a list of one or more PDU sessions, where the second message is an event notification message from the AMF to the SMF to notify the SMF of a RAN node failure and / or re-start event.

[0353] In some embodiments, the Nmbsmf_MBSSession_ContextUpdate request message indicates at least one of an ID of a multicast session and an ID of a RAN node that experienced a re-initiation and / or failure. In some embodiments, the first message indicates one of a single UE and / or a single PDU session affected by the RAN node failure and / or re-initiation and a list of one or more UEs and / or one or more PDU sessions affected by the RAN node failure and / or re-initiation. In some embodiments, the second message indicates one of a communication failure reporting event and an AMF event not specified in 3GPP TS 23.502, V17.3.0 or any of its previous releases, or in 3GPP TS 29.518 V17.4.0 or any of its previous releases. In some embodiments, when the message comprises a second message, the method further includes, before the step of sending the message, receiving a message for subscribing to the event from the SMF, and before the step of sending the message, the method further includes determining the SMF as a destination that should be notified of the event based at least on the received message for subscribing to the event.

[0354] In some embodiments, the message to subscribe to the event comprises at least one of: one or more UE IDs or an “any UE” indication, one or more area identifiers, an NF service consumer service instance Id, and an authority of resource URI. In some embodiments, the event comprises at least one of: a RAN / NAS release code, one or more UE IDs, one or more PDU session IDs, and an NG-RAN restart or failure indication. In some embodiments, the seventh message comprises at least one of an NG Setup Request message and an NG Reset Request message.

[0355] In some embodiments, before the step of receiving the seventh message, the method further comprises receiving an eighth request message from the RAN node requesting to establish a shared distribution towards the RAN node for a multicast session, the eighth request message comprising an N2 container, the N2 container comprising an ID of the RAN node that experienced the failure and / or re-initiation, and further comprising a transport IP address when multicast transport is used, or N3mb tunnel endpoint information when unicast transport is used; and, based at least on the eighth request message, instructing the MB-SMF to The method further includes transmitting a ninth request message requesting establishment of shared distribution towards the RAN node for the multicast session, wherein the ninth request message comprises an ID of the RAN node and an N2 container inserted by the AMF; receiving a ninth response message from the MB-SMF indicating whether the shared distribution has been successfully established and / or indicating information for establishing the shared distribution; and transmitting an eighth response message to the RAN node indicating whether the shared distribution has been successfully established and / or indicating information for establishing the shared distribution based at least on the ninth response message.

[0356] In some embodiments, the eighth request message is an N2 MBS Session Request message, the eighth response message is an N2 MBS Session Response message, the ninth request message is an Nmbsmf_MBSSession_ContextUpdate Request message, and the ninth response message is an Nmbsmf_MBSSession_ContextUpdate Response message.

[0357] 18 is a flowchart of an example method 1800 in an AMF for facilitating an SMF restoring a multicast session for one or more UEs served by a RAN node that has experienced a failure and / or reinitiation, provided in accordance with one embodiment of the present disclosure. Method 1800 may be performed in a second network node (e.g., the AMF 225 shown in FIG. 2). Method 1800 may include step S1810. However, the present disclosure is not limited thereto. In some other embodiments, method 1800 may include more steps, different steps, or any combination thereof. Furthermore, the steps of method 1800 may be performed in a different order than described herein. Furthermore, in some embodiments, steps in method 1800 may be split into multiple sub-steps and performed by different entities, and / or multiple steps in method 1800 may be combined into a single step.

[0358] The method 1800 may begin at step S1810, where a sixth message may be forwarded from the SMF to the RAN node to cause the RAN node to establish associated resources for receiving multicast session data from either the UPF for individual delivery or the MB-UPF for shared delivery to restore the multicast session for at least one of the one or more UEs.

[0359] In some embodiments, the sixth message comprises an indicator indicating a failure and / or a re-initiation of the RAN node and / or an ID of the RAN node. In some embodiments, prior to the step of forwarding the sixth message, the method further includes receiving, from the SMF, a request message to request the AMF to page one or more UEs to place these UEs in a CM-CONNECTED mode, the request message comprising an indicator indicating a failure and / or a re-initiation of the RAN node, performing a paging procedure for the one or more UEs, and sending, based at least on a result of the paging procedure, to the SMF a response message to indicate which of the one or more UEs are in the CM-CONNECTED mode. In some embodiments, before the step of forwarding the sixth message, the method further includes receiving, from the SMF, a request message for querying one or more UEs affected by the failure and / or re-initiation of the RAN node and / or for requesting the AMF to page one or more UEs, wherein the request message comprises an indicator indicating the failure and / or re-initiation of the RAN node and / or an ID of the RAN node; determining one or more UEs based at least on the ID of the RAN node; performing a paging procedure for the determined one or more UEs; and sending, to the SMF, a response message comprising one or more UEs and / or an acceptance of the paging based at least on a result of the paging procedure.

[0360] 19 is a flowchart of an example method 1900 in an MB-SMF for detecting a failure and / or re-initiation of a RAN node serving one or more UEs for a multicast session, provided in accordance with one embodiment of the present disclosure. Method 1900 may be implemented in a third network node (e.g., MB-SMF 235 shown in FIG. 2). Method 1900 may include step S1910. However, the present disclosure is not limited thereto. In some other embodiments, method 1900 may include more steps, different steps, or any combination thereof. Furthermore, the steps of method 1900 may be implemented in a different order than described herein. Furthermore, in some embodiments, steps in method 1900 may be split into multiple sub-steps and implemented by different entities, and / or multiple steps in method 1900 may be combined into a single step.

[0361] The method 1900 may begin at step S1910, where a message may be received from a network node indicating a failure and / or restart of a RAN node.

[0362] In some embodiments, the network node comprises at least one of an AMF and an MB-UPF. In some embodiments, the message comprises at least one of: an Nmbsmf_MBSSession_ContextUpdate request message sent from the AMF for a multicast session; a tenth message for the multicast session, the tenth message being a session report message from the MB-UPF for reporting a RAN node failure and / or re-initiation; and an eleventh message for a node-level event, the eleventh message being a node report message from the MB-UPF for reporting a RAN node failure and / or re-initiation. In some embodiments, the Nmbsmf_MBSSession_ContextUpdate request message indicates at least one of an ID of the multicast session and an ID of the RAN node that experienced the re-initiation and / or failure. In some embodiments, the tenth message is a PFCP session report message indicating a TEID and / or an IP address of the RAN node. In some embodiments, the tenth message is a PFCP Node Report message comprising an IP address associated with the failed RAN node.

[0363] In some embodiments, before the step of receiving the message, the method further comprises receiving a ninth request message from the AMF requesting to establish shared distribution towards the RAN node for the multicast session, the ninth request message comprising an ID of the RAN node inserted by the AMF and an N2 container provided by the RAN node, the N2 container comprising the ID of the RAN node and further comprising a transport IP address when multicast transport is used or N3mb tunnel endpoint information when unicast transport is used; and sending the ninth request message to the MB-UPF to request the establishment of shared distribution towards the RAN node for the multicast session, the ninth request message comprising an ID of the RAN node inserted by the AMF and an N2 container provided by the RAN node, the N2 container comprising the ID of the RAN node and further comprising a transport IP address when multicast transport is used or N3mb tunnel endpoint information when unicast transport is used. and further including configuring an IP address, or N3mb tunnel endpoint information when unicast transport is used, in the MB-UPF, such that the MB-UPF can use the transport IP address, or the IP address within the N3mb tunnel endpoint indicated by the N3mb tunnel endpoint information, to probe the liveness of the RAN node; storing the AMF in the context for the multicast session; and sending a ninth response message to the AMF, based at least on a result of the configuring in the MB-UPF, indicating whether the shared distribution has been successfully established and / or indicating information for establishing the shared distribution.

[0364] In some embodiments, after receiving the ninth request message, the method further includes establishing a mapping between IDs of the RAN nodes and tunnels to the RAN nodes for the multicast session. In some embodiments, after receiving the message, the method further includes determining tunnels affected by the RAN node failure and / or re-initiation based at least on the mapping between IDs of the RAN nodes and tunnels, and sending a message to the MB-UPF to release the tunnels.

[0365] In some embodiments, the ninth request message is an Nmbsmf_MBSSession_ContextUpdate request message and the ninth response message is an Nmbsmf_MBSSession_ContextUpdate response message.

[0366] FIG. 20 is a flowchart of an example method 2000 in an MB-SMF for restoring a multicast session for one or more UEs served by a RAN node that has experienced a failure and / or reinitiation, provided in accordance with one embodiment of the present disclosure. Method 2000 may be performed in a third network node (e.g., MB-SMF 235 shown in FIG. 2). Method 2000 may include step S2010. However, the present disclosure is not limited thereto. In some other embodiments, method 2000 may include more steps, different steps, or any combination thereof. Furthermore, the steps of method 2000 may be performed in a different order than described herein. Furthermore, in some embodiments, steps in method 2000 may be split into multiple substeps and performed by different entities, and / or multiple steps in method 2000 may be combined into a single step.

[0367] Method 2000 may begin at step S2010, where in response to detecting a failure and / or re-initiation of the RAN node, establishing associated resources at the RAN node for receiving multicast session data from the MB-UPF for shared distribution may be triggered to restore the multicast session for at least one of the one or more UEs.

[0368] In some embodiments, the step of triggering the one or more tunnels to be established includes sending a notification message to an SMF associated with the RAN node for the multicast session to notify the SMF of the RAN node failure and / or re-initiation. In some embodiments, the notification message comprises at least one of an ID of the RAN node and an indication of the RAN node failure and / or re-initiation. In some embodiments, the RAN node failure and / or re-initiation is detected by the MB-SMF by the method described with reference to FIG. 19.

[0369] FIG. 21 is a flowchart of an example method 2100 in a RAN node for facilitating a network node detecting a failure and / or re-initiation of a RAN node serving one or more UEs for a multicast session, provided in accordance with one embodiment of the present disclosure. Method 2100 may be implemented in a RAN node (e.g., NG-RAN 205 shown in FIG. 2). Method 2100 may include step S2110. However, the present disclosure is not limited thereto. In some other embodiments, method 2100 may include more steps, different steps, or any combination thereof. Furthermore, the steps of method 2100 may be implemented in a different order than described herein. Furthermore, in some embodiments, steps in method 2100 may be split into multiple sub-steps and implemented by different entities, and / or multiple steps in method 2100 may be combined into a single step.

[0370] The method 2100 may begin at step S2110 with sending a seventh message to a network node reporting a failure and / or restart of the RAN node.

[0371] In some embodiments, the network node is an AMF. In some embodiments, the seventh message comprises at least one of an NG Setup Request message and an NG Reset Request message. In some embodiments, before receiving the seventh message, the method further includes sending an eighth request message to the AMF requesting establishment of shared distribution towards the RAN node for the multicast session, and receiving an eighth response message from the AMF indicating whether the shared distribution was successfully established and / or indicating information for establishing the shared distribution. In some embodiments, the method further includes subscribing to multicast transport distribution for the multicast session by using the received information in the eighth response message. In some embodiments, the eighth request message comprises an ID of the RAN node. In some embodiments, the eighth request message is an N2 MBS Session Request message, and the eighth response message is an N2 MBS Session Response message.

[0372] 22 schematically illustrates an embodiment of a configuration that may be used in a network node and / or a RAN node, according to an embodiment of the present disclosure. A processing unit 2206 is provided in the configuration 2200, e.g., with a digital signal processor (DSP) or a central processing unit (CPU). The processing unit 2206 may be a single unit or multiple units for performing different actions of the procedures described herein. The configuration 2200 may also include an input unit 2202 for receiving signals from other entities and an output unit 2204 for providing signal(s) to other entities. The input unit 2202 and the output unit 2204 may be configured as an integrated entity or as separate entities.

[0373] Additionally, configuration 2200 may comprise at least one computer program product 2208 in the form of non-volatile or volatile memory, e.g., Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory, and / or a hard drive. Computer program product 2208 comprises a computer program 2210 comprising code / computer readable instructions that, when executed by processing unit 2206 in configuration 2200, cause configuration 2200 and / or a network node and / or RAN node in which configuration 2200 is comprised to perform actions, e.g., of the procedures previously described in conjunction with Figures 4-21 or any other variations.

[0374] The computer program 2210 may be configured as computer program code structured in a computer program module 2210A. Thus, in the illustrated embodiment when the configuration 2200 is used in a first network node, the code in the computer program of the configuration 2200 includes a module 2210A configured to receive a message from the network node indicating a failure and / or restart of the RAN node.

[0375] The computer program 2210 may be further configured as computer program code structured in a computer program module 2210B. Thus, in an example embodiment when the configuration 2200 is used in a first network node, the code in the computer program of the configuration 2200 includes a module 2210B configured to: trigger, in response to detecting a failure and / or re-initiation of the RAN node, establishing associated resources at the RAN node to receive multicast session data from either a UPF for individual delivery or a Multicast Broadcast User Plane Function (MB-UPF) for shared delivery to restore the multicast session for at least one of the one or more UEs.

[0376] Computer program 2210 may be further configured as computer program code structured in computer program modules 2210C and 2210D. Thus, in the illustrated embodiment when configuration 2200 is used in a second network node, the code in the computer program of configuration 2200 includes a module 2210C configured to receive, from the RAN node, a seventh message reporting a failure and / or re-initiation of the RAN node, and a module 2210D configured to send, in response to the received seventh message, a message to the network node indicating the failure and / or re-initiation of the RAN node.

[0377] Computer program 2210 may be further configured as computer program code structured in computer program module 2210E. Thus, in an example embodiment, when configuration 2200 is used in a second network node, the code in the computer program of configuration 2200 includes module 2210E configured to forward a sixth message from the SMF to the RAN node to cause the RAN node to establish associated resources for receiving multicast session data from either the UPF for individual delivery or the MB-UPF for shared delivery to restore the multicast session for at least one of the one or more UEs.

[0378] The computer program 2210 may be further configured as computer program code structured in a computer program module 2210F. Thus, in an example embodiment when the configuration 2200 is used in a third network node, the code in the computer program of the configuration 2200 includes a module 2210F configured to receive a message from the network node indicating a failure and / or restart of the RAN node.

[0379] Computer program 2210 may be further configured as computer program code structured in computer program module 2210G. Thus, in an example embodiment when configuration 2200 is used in a third network node, code in the computer program of configuration 2200 includes module 2210G configured to: trigger, in response to detecting a failure and / or re-initiation of the RAN node, establishing associated resources at the RAN node to receive multicast session data from the MB-UPF for shared distribution to restore the multicast session for at least one of the one or more UEs.

[0380] The computer program 2210 may be further configured as computer program code structured in a computer program module 2210H. Thus, in an example embodiment when the configuration 2200 is used in a RAN node, the code in the computer program of the configuration 2200 includes a module 2210H configured to send a seventh message to a network node reporting a failure and / or restart of the RAN node.

[0381] The computer program modules may essentially perform the actions of the flows shown in Figures 4-21 to emulate a network node and / or a RAN node. In other words, when different computer program modules are executed in the processing unit 2206, they may correspond to different modules in a network node and / or a RAN node.

[0382] Although the code means in the embodiment disclosed above in conjunction with FIG. 22 are implemented as computer program modules that, when executed on a processing unit, cause the configuration to perform the actions described above in conjunction with the aforementioned figures, at least one of the code means may, in alternative embodiments, be implemented at least in part as a hardware circuit.

[0383] The processor may be a single CPU (Central Processing Unit), but may also comprise two or more processing units. For example, the processor may include a general-purpose microprocessor, an instruction set processor, and / or related chipsets, and / or a special-purpose microprocessor such as an application-specific integrated circuit (ASIC). The processor may also comprise on-board memory for caching purposes. The computer program may be carried by a computer program product connected to the processor. The computer program product may comprise a computer-readable medium on which the computer program is stored. For example, the computer program product may be a flash memory, a random access memory (RAM), a read-only memory (ROM), or an EEPROM, and the computer program modules described above may, in alternative embodiments, be distributed on different computer program products in the form of memories within the network node and / or the RAN node.

[0384] An exemplary first network node is provided corresponding to the above-described method 1500 and / or method 1600. Figure 23 is a block diagram of a first network node 2300 according to one embodiment of the present disclosure. The first network node 2300 may be, for example, the SMF 230 in some embodiments.

[0385] The first network node 2300 may be configured to perform the method 1500 described above with respect to Figure 15. As shown in Figure 23, the first network node 2300 may comprise a receiving module 2310 configured to receive a message from a network node indicating a failure and / or re-initiation of a RAN node. Additionally or alternatively, the first network node 2300 may be configured to perform the method 1600 described above with respect to Figure 16. As also shown in Figure 23, the first network node 2300 may comprise a triggering module 2320 configured to trigger, in response to detecting a failure and / or re-initiation of the RAN node, establishing associated resources at the RAN node to receive multicast session data from either the UPF for dedicated delivery or the MB-UPF for shared delivery to restore the multicast session for at least one of the one or more UEs.

[0386] The above modules 2310 and / or 2320 may be implemented as a pure hardware solution or as a combination of software and hardware, for example by a processor or microprocessor and sufficient software, as well as memory for storage of the software, a programmable logic device (PLD), or one or more other electronic components or processing circuits configured to perform the actions described above and shown, for example, in Figures 15 and / or 16. Furthermore, the first network node 2300 may comprise one or more further modules, each of which may perform any of the steps of method 1500 and / or method 1600 described with reference to Figures 15 and / or 16.

[0387] An exemplary second network node is provided corresponding to the above-described method 1700 and / or method 1800. Figure 24 is a block diagram of a second network node 2400 according to one embodiment of the present disclosure. The second network node 2400 may be, for example, the AMF 225 in some embodiments.

[0388] The second network node 2400 may be configured to perform the method 1700 described above with respect to FIG. 17. As shown in FIG. 24, the second network node 2400 may comprise a receiving module 2410 configured to receive, from the RAN node, a seventh message reporting a failure and / or re-initiation of the RAN node, and a transmitting module 2420 configured to transmit, in response to the received seventh message, a message indicating the failure and / or re-initiation of the RAN node to the network node. Additionally or alternatively, the second network node 2400 may be configured to perform the method 1800 described above with respect to FIG. 18. As also shown in FIG. 24, the second network node 2400 may comprise a forwarding module 2430 configured to forward a sixth message from the SMF to the RAN node to cause the RAN node to establish associated resources for receiving multicast session data from either the UPF for individual delivery or the MB-UPF for shared delivery to restore the multicast session for at least one of the one or more UEs. In some embodiments,

[0389] The above modules 2410, 2420, and / or 2430 may be implemented as a pure hardware solution or as a combination of software and hardware, for example by a processor or microprocessor and sufficient software, as well as memory for storage of the software, a programmable logic device (PLD), or one or more other electronic components or processing circuits configured to perform the actions described above and shown, for example, in Figures 17 and / or 18. Furthermore, the second network node 2400 may comprise one or more further modules, each of which may perform any of the steps of method 1700 and / or method 1800 described with reference to Figures 17 and / or 18.

[0390] Corresponding to the above-described method 1900 and / or method 2000, an exemplary third network node is provided. Figure 25 is a block diagram of a third network node 2500 according to one embodiment of the present disclosure. The third network node 2500 may be, for example, the MB-SMF 235 in some embodiments.

[0391] The third network node 2500 may be configured to perform the method 1900 described above with respect to Figure 19. As shown in Figure 25, the third network node 2500 may comprise a receiving module 2510 configured to receive a message from a network node indicating a failure and / or re-initiation of the RAN node. Additionally or alternatively, the third network node 2500 may be configured to perform the method 2000 described above with respect to Figure 20. As also shown in Figure 25, the third network node 2500 may comprise a triggering module 2520 configured to trigger, in response to detecting the failure and / or re-initiation of the RAN node, establishing associated resources at the RAN node to receive multicast session data from the MB-UPF for shared distribution to restore the multicast session for at least one of the one or more UEs.

[0392] The above modules 2510 and / or 2520 may be implemented as a pure hardware solution or as a combination of software and hardware, for example by a processor or microprocessor and sufficient software, as well as memory for storage of the software, a programmable logic device (PLD), or one or more other electronic components or processing circuits configured to perform the actions described above and shown, for example, in Figures 19 and / or 20. Furthermore, the first network node 2500 may comprise one or more further modules, each of which may perform any of the steps of method 1900 and / or method 2000 described with reference to Figures 19 and / or 20.

[0393] An exemplary RAN node is provided corresponding to the above-described method 2100. Figure 26 is a block diagram of a RAN node 2600 according to one embodiment of the present disclosure. The RAN node 2600 may be, for example, an NG-RAN 205 in some embodiments.

[0394] The RAN node 2600 may be configured to perform the method 2100 described above with respect to Figure 21. As shown in Figure 26, the RAN node 2600 may comprise a transmitting module 2610 configured to transmit a seventh message reporting a failure and / or re-initiation of the RAN node to a network node.

[0395] The above module 2610 may be implemented as a pure hardware solution or as a combination of software and hardware, for example by a processor or microprocessor and sufficient software and memory for storage of the software, a programmable logic device (PLD), or one or more other electronic component(s) or processing circuitry configured to perform the actions described above and shown, for example, in Figure 21. Furthermore, the RAN node 2600 may comprise one or more further modules, each of which may perform any of the steps of the method 2100 described with reference to Figure 21.

[0396] The present disclosure has been described above with reference to embodiments of the present disclosure. However, these embodiments are provided for illustrative purposes only, rather than limiting the present disclosure. The scope of the present disclosure is defined by the appended claims and their equivalents. Those skilled in the art can make various alterations and modifications without departing from the scope of the present disclosure, all of which fall within the scope of the present disclosure.

[0397] Abbreviation Description AMF Access and Mobility Management Functions DL Downlink GTP-U GPRS Tunnel Protocol - User Plane MBS Multicast / Broadcast Service MB-SMF Multicast / Broadcast Session Management Function NG-RAN Next Generation Radio Access Network SMF Session Management Facility TEID Tunnel Entity Identifier

Claims

1. 1. A method (1500, 1600) in a Session Management Function (SMF) (230) for restoring a multicast session for one or more UEs (200) served by a RAN node (205) that has experienced a failure and / or reinitiation, the method (1500, 1600) comprising: receiving (S1510) a message from a network node (225, 210, 235) indicating a RAN node failure and / or re-initiation of the RAN node (205); determining the one or more UEs (200) that have joined a multicast session and that have been affected by the failure and / or re-initiation of the RAN node (205); In response to detecting the failure and / or re-initiation of the RAN node (205), triggering (S1610) the establishment of associated resources in the RAN node (205) via an Access and Mobility Management Function (AMF) (225) to receive multicast session data from either a UPF (210) for individual delivery or a Multicast Broadcast User Plane Function (MB-UPF) (235) for shared delivery in order to restore the multicast session for the affected one or more UEs (200); A method (1500, 1600) comprising:

2. The message may include: An Nsmf_PDUSession_UpdateSMContext request message sent from the AMF for a Protocol Data Unit (PDU) session associated with one of the UEs; a second message for a list of one or more UEs and / or a list of one or more PDU sessions, the second message being an event notification message from an AMF for notifying the SMF of a failure and / or re-start event of the RAN node; a third message for a PDU session, the third message being a session report message from a UPF for reporting the failure and / or re-initiation of the RAN node; and a fourth message for a node level event, said fourth message being a node report message from a UPF to report the failure and / or re-initiation of the RAN node; and a fifth message for the multicast session, the fifth message being sent from a MB-SMF associated with the multicast session; and and 10. The method (1500, 1600) of claim 1, wherein optionally, the second message indicates a communication failure reporting event.

3. When the message includes the second message, the method (1500, 1600) may further comprise, before the step of receiving the message, Sending a message to the AMF to subscribe to the event. and optionally further comprising: The message for subscribing to the event comprises: - Identifiers (IDs) of one or more of said UEs or an "any UE" indication; one or more area identifiers; - Network Function (NF) Service Consumer Service Instance ID; - Resource Uniform Resource Identifier (URI) authority and and At will, The event is RAN / Non-Access Stratum (NAS) release code; one or more UE IDs; and one or more PDU Session IDs; and - NG-RAN restart or failure indication The method (1500, 1600) of claim 2, comprising at least one of:

4. and / or wherein the step of determining the one or more UEs includes at least one of: determining the one or more UEs indicated in a received message from the AMF, where the received message further indicates the failure and / or re-initiation of the RAN node; and retrieving one or more UEs having the same IP address at a tunnel endpoint for a downlink tunnel in the RAN node to receive multicast session data when the RAN failure or re-initiation is reported by the UPF; and / or Prior to the step of triggering the establishment of the associated resources in the RAN node, the method (1500, 1600) may further comprise: receiving a fifth message from an MB-SMF indicating a detected failure and / or re-initiation of the RAN node and an ID of the RAN node; Sending a request message to a Network Repository Function (NRF) to discover a list of AMFs that have associations with the RAN node; receiving a response message from the NRF including a list of AMFs; selecting an AMF from the list of AMFs; sending, to the AMF, a request message to query the one or more UEs affected by the failure and / or re-initiation of the RAN node and / or to request the AMF to page the one or more UEs, the request message including an indicator indicating the failure and / or re-initiation of the RAN node and / or an ID of the RAN node; receiving a response message from the AMF, the response message including an acceptance of the one or more UEs and / or paging; The method (1500, 1600) of claim 1 further comprising:

5. SMF (230, 2200, 2300), a processor (2206); a memory (2208) storing instructions that, when executed by the processor (2206), cause the processor (2206) to perform a method (1500, 1600) according to any one of claims 1 to 4; SMF (230, 2200, 2300) comprising:

6. 1. A method (1700, 1800) in an AMF (225) for facilitating a network node (230, 235) to detect a failure and / or re-initiation of a RAN node (205) serving one or more UEs (200) for a multicast session, the method (1700, 1800) comprising: receiving a seventh message from the RAN node (205) reporting a failure and / or restart of the RAN node (205) (S1710); In response to the received seventh message, sending a message to the network node (230, 235) indicating the failure and / or re-initiation of the RAN node (205) (S1720); A method (1700, 1800) comprising:

7. The message may include: an Nmbsmf_MBSSession_ContextUpdate request message sent to the MB-SMF for said multicast session; an Nsmf_PDUSession_UpdateSMContext request message sent to the SMF for a PDU session associated with one of the UEs; a second message for a list of one or more UEs and / or a list of one or more PDU sessions, the second message being an event notification message from the AMF to the SMF for notifying the SMF of a failure and / or re-start event of the RAN node; and At will, The Nmbsmf_MBSSession_ContextUpdate request message: the ID of said multicast session; - the ID of the RAN node that experienced the restart and / or failure; Indicating at least one of 7. The method (1700, 1800) of claim 6, wherein optionally, the second message indicates a communication failure reporting event.

8. When the message includes the second message, the method (1700, 1800) may further comprise, before the step of transmitting the message: receiving a message from the SMF to subscribe to the event; further comprising Prior to the step of sending the message, the method (1700, 1800) determining the SMF as a destination to be notified of the event based at least on the received message for subscribing to the event; and optionally further comprising: The message for subscribing to the event comprises: - the identity of said one or more UEs or an "any UE" indication; one or more area identifiers; NF Service Consumer Service Instance Id, and - The authority of the resource URI The method (1700, 1800) of claim 7, comprising at least one of:

9. The event is - RAN / NAS release code; one or more UE IDs; and one or more PDU Session IDs; and - NG-RAN restart or failure indication The method (1700, 1800) of claim 7, comprising at least one of:

10. AMF (225, 2200, 2400), a processor (2206); a memory (2208) storing instructions that, when executed by the processor (2206), cause the processor (2206) to perform a method (1700, 1800) according to any one of claims 6 to 9; AMF (225, 2200, 2400) equipped with.

11. 1. A method (1900, 2000) in a MB-SMF (235) for restoring a multicast session for one or more UEs (200) served by a RAN node (205) that has experienced a failure and / or reinitiation, the method (1900, 2000) comprising: receiving (S1910) a message from a network node (200) indicating a failure and / or restart of the RAN node (205); In response to receiving the message indicating the failure and / or re-initiation of the RAN node (205), triggering (S2010) the establishment of associated resources in the RAN node (205) for receiving multicast session data from a MB-UPF (210) for shared distribution in order to restore the multicast session for at least one of the one or more UEs (200); A method (1900, 2000) comprising:

12. The message may include: - An Nmbsmf_MBSSession_ContextUpdate request message sent from the AMF for the multicast session; a tenth message for the multicast session, the tenth message being a session report message from an MB-UPF for reporting the failure and / or re-initiation of the RAN node; and an eleventh message for a node level event, the eleventh message being a node report message from an MB-UPF to report the failure and / or re-initiation of the RAN node; and and At will, The Nmbsmf_MBSSession_ContextUpdate request message: the ID of said multicast session; - the ID of the RAN node that experienced the restart and / or failure; The method (1900, 2000) of claim 11, further comprising:

13. Prior to the step of receiving the message, the method further comprises: receiving a ninth request message from an AMF requesting establishment of shared distribution towards the RAN node for the multicast session, the ninth request message including an ID of the RAN node inserted by the AMF and an N2 container provided by the RAN node, the N2 container including the ID of the RAN node and further including a transport IP address when multicast transport is used or N3mb tunnel endpoint information when unicast transport is used; configuring the MB-UPF with the transport IP address when multicast transport is used, or the N3mb tunnel endpoint information when unicast transport is used, so that the MB-UPF can use the transport IP address or an IP address within an N3mb tunnel endpoint indicated by the N3mb tunnel endpoint information to probe the liveness of the RAN node; Storing the AMF in a context for the multicast session; and sending a ninth response message to the AMF, indicating whether the shared distribution has been successfully established and / or indicating information for establishing the shared distribution, based at least on a result of the configuring the MB-UPF; further comprising At will, After receiving the ninth request message, the method (1900, 2000) further comprises: establishing a mapping between the ID of the RAN node and a tunnel to the RAN node for the multicast session; further comprising At will, After the step of receiving the message, the method further comprises: determining the tunnels affected by the failure and / or re-initiation of the RAN node based at least on the mapping between the ID of the RAN node and the tunnels; sending a message to the MB-UPF to release the tunnel; 12. The method (1900, 2000) of claim 11, further comprising:

14. MB-SMF (235, 2200, 2500), a processor (2206); a memory (2208) storing instructions that, when executed by the processor (2206), cause the processor (2206) to perform a method (1900, 2000) according to any one of claims 11 to 13; MB-SMF (235, 2200, 2500) equipped with.

15. A communication system (20, 20') for maintaining a multicast session, said communication system (20, 20') comprising: The SMF (230) of claim 5; An AMF (225) according to claim 10; The MB-SMF (235) according to claim 14; A communication system (20, 20') comprising:

Images