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, entitled "NETWORK NODES AND METHODS THEREIN FOR FACILITATING MANAGEMENT OF MULTICAST / BROADCAST SERVICE SESSION," filed on December 31, 2021, and PCT International Application No. PCT / CN2022 / 072074, entitled "RAN NODE FAILURE / RESTART DETECTION AND RESTORATION FOR MULTICAST MBS SESSION," filed on January 14, 2022, which are incorporated 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 / reinitiation detection and restoration for multicast / broadcast service (MBS) sessions. [Background technology]

[0003] Broadcast services with scheduled programming constitute the premier communication service for today's society. Broadcast is a transport technique for delivering the same content to an unlimited number of devices with a defined quality of service without substantially increasing the network capacity requirements, energy consumption, or costs. Cellular systems are typically used for unicast transmission. In this mode, a separate channel with each UE is established. In scenarios where a large number of users or devices consume the same data, the use of broadcast or multicast transmission can give 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 a desired service.

[0005] Although existing technologies are mature, current broadcast systems have serious limitations when serving users who are on the move or who are located in areas with complex mountainous orography and poor signal quality. To overcome these limitations, the 3rd Generation Partnership Project (3GPP) 5G standard included a work item to support 5G multicast / broadcast services for Release 17. This will bring the wide 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 broadcasting technologies that 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, a method is provided 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 are affected by the RAN node failure and / or re-initiation, and in response to detecting the RAN node failure and / or re-initiation, triggering establishing associated resources in 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 the 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 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 the 3rd Generation Partnership Project (3GPP) Technical Specification (TS) 23.502, V17.3.0 or previous releases. a second message, where 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 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 for reporting a RAN node failure and / or re-start; and a fifth message for a multicast session, where the fifth message is sent from a 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 3GPP TS23.502, V17.3.0 or any of its previous releases, or in 3GPP TS29.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 receiving the message, sending a message to the AMF 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 re-initiation 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 a Nmbsmf_MBSSession_ContextStatusNotify message comprising an indicator indicating the failure and / or re-initiation of the RAN node and / or an ID of the RAN node.

[0010] According to a second aspect of the present disclosure, a method in an SMF is provided 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 triggering, in response to detecting the failure and / or re-initiation of the RAN node, establishing associated resources in the RAN node for receiving 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 step of triggering the establishment of related resources at the RAN node includes sending a sixth message to the RAN node via the AMF to cause the RAN node to initiate establishment of related resources for the multicast session. In some embodiments, the sixth message comprises an indicator indicating the failure and / or re-initiation of the RAN node and / or an ID of the RAN node. In some embodiments, prior to the step of triggering the establishment of related 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 step of determining 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 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 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 put the UEs in a CM-CONNECTED mode, where the request message comprises an indicator indicating a failure and / or a re-initiation 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 in the RAN node, the method further includes receiving a fifth message from the MB-SMF indicating the detected failure and / or re-initiation 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 having 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-initiation 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-initiation 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-initiation of the RAN node is detected by the SMF by any of the methods of the first aspect.

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

[0014] According to a fourth aspect of the present disclosure, a first network node is provided, comprising: a receiving module configured to receive a message indicating a failure and / or re-initiation of a RAN node from the network node; Additionally or alternatively, the first network node comprises a triggering module configured to trigger, in response to detecting the failure and / or re-initiation of the RAN node, establishing associated resources in the RAN node to receive multicast session data from either a UPF for individual delivery or a MB-UPF for shared delivery to restore a 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 to detect 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, in response to the received seventh message, a message indicating the failure and / or re-initiation of the RAN node to the network node.

[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 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 failure and / or re-initiation of a 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 a RAN node. 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 re-initiation 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 sending the MB-SMF a request to establish a shared distribution towards the RAN node for a multicast session based at least on the eighth request message. The method further includes sending 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 sending 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, a method in an AMF is provided for facilitating an SMF to restore 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 a response message to the SMF to indicate which of the one or more UEs are in the CM-CONNECTED mode based at least on a result of the paging procedure. In some embodiments, prior to the step of forwarding the sixth message, the method further includes receiving a request message from the SMF to query one or more UEs affected by the failure and / or re-initiation of the RAN node and / or to request the AMF to page one or more UEs, where 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 the 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 a response message to the SMF comprising an acceptance of the one or more UEs and / or paging based at least on a result of the paging procedure.

[0023] According to a seventh aspect of the present disclosure, a second network node is provided. The second network node comprises a processor and a memory storing instructions that, when executed by the processor, cause the processor to perform a 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 to the network node a message indicating the failure and / or re-initiation of the RAN node in response to the received seventh message. 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 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,

[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 a message from a network node indicating the failure and / or re-initiation of the RAN node, and triggering, in response to receiving the message indicating the failure and / or re-initiation of the RAN node, establishing associated resources in the RAN node for receiving 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.

[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 a 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 a shared distribution towards the RAN node for a 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 receiving the ninth request message from the MB-UPF requesting to establish a shared distribution towards the RAN node for a 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 configuring an N3mb tunnel endpoint information when a unicast transport is used, so that the MB-UPF is able to use the transport IP address, or an IP address in the N3mb tunnel endpoint indicated by the N3mb tunnel endpoint information, to probe 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 or not and / or indicating information for establishing the shared distribution based at least on a result of the configuring in the MB-UPF.

[0028] In some embodiments, after receiving the ninth request message, the method further includes establishing a mapping between RAN node IDs 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 the RAN node IDs and the tunnels, and sending a message to the MB-UPF to release the tunnels.

[0029] In some embodiments, the ninth request message is a Nmbsmf_MBSSession_ContextUpdate request message and the ninth response message is a 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 triggering, in response to detecting the failure and / or re-initiation of the RAN node, establishing associated resources in the RAN node for receiving multicast session data from a 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 any method of the ninth aspect.

[0032] According to an eleventh aspect of the present disclosure, there is provided a third network node. The third network node comprises 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, a third network node is provided, comprising a receiving module configured to receive a message indicating a failure and / or re-initiation of the RAN node from the network node. Additionally or alternatively, the third network node comprises a triggering module configured to trigger, in response to detecting the failure and / or re-initiation of the RAN node, establishing associated resources in the RAN node to receive multicast session data from the MB-UPF for shared distribution to restore a 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 to detect a failure and / or re-initiation of a RAN node serving one or more UEs for a multicast session, the method including transmitting a seventh message to the network node 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, prior to the step of receiving the seventh message, the method further comprises 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 has been successfully established and / or indicating information for establishing the shared distribution. In some embodiments, the method further comprises subscribing to a 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 transmission module configured to transmit a seventh message reporting a failure and / or a re-initiation of the RAN node to a network 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 of the third or fourth aspect, a second network node of the seventh or eighth aspect, a third network node of the eleventh or twelfth aspect, and a RAN node of 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 are merely illustrative of certain embodiments according to the present disclosure and therefore should not be considered limiting of its scope. [Brief description of the drawings]

[0042] [Figure 1] FIG. 1 illustrates an example delivery method for an MBS session, where RAN node failure / restart detection and / or restoration is applicable, according to some embodiments of the present disclosure. [Diagram 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. [Diagram 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 where RAN node failure / restart detection and / or restoration according to some embodiments of the present disclosure is applicable. [Figure 5A]FIG. 1 illustrates an example procedure for a UE to join a multicast session, where RAN node failure / restart detection and / or restoration according to some embodiments of the present disclosure is applicable. [Figure 5B] FIG. 1 illustrates an example procedure for a UE to join a multicast session, where RAN node failure / restart detection and / or restoration according to some embodiments of the present disclosure is applicable. [Figure 6] FIG. 1 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 / reinitiation 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 / reinitiation detection and / or restoration according to some embodiments of the present disclosure is applicable. [Figure 8] FIG. 13 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. [Figure 9] FIG. 1 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 a 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 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] A diagram illustrating an example procedure for SMF-initiated multicast MBS session restoration according to some embodiments of the present disclosure. [Figure 14] 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 example 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] 1 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 to detect a failure and / or re-initiation of a RAN node, in accordance with one embodiment of the present disclosure. [Figure 18] 1 is a flowchart of an example method in an AMF for facilitating an SMF to restore a multicast session for one or more UEs according to one embodiment of the present disclosure. [Figure 19] 1 is a flowchart of an example method in a 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 a MB-SMF for restoring a multicast session for one or more UEs in accordance with 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 to detect a failure and / or re-initiation of the RAN node, in accordance with an embodiment of the present disclosure. [Figure 22]FIG. 2 illustrates an embodiment of a configuration that may be used in a network node and / or a UE, according to an embodiment of the present disclosure. [Diagram 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. [Diagram 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 example RAN node, in accordance with one embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0043] In the following, the present disclosure will be described with reference to the embodiments shown in the accompanying drawings. However, it should be understood that the description is provided for illustrative purposes only, and not to limit the present disclosure. Moreover, 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 are 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 otherwise specified or understood otherwise within the context in which it is used, is generally intended to convey that some embodiments include certain features, elements, and / or conditions, but not others. Thus, such conditional language does not generally 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 in its exclusive sense) such that the term "or" means one, some, or all of the elements in the list. Additionally, the term "each," as used herein, in addition to having its ordinary meaning, can mean 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 stipulations, 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. may 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 the exemplary embodiments. As used herein, the singular forms "a", "an" and "the" are intended to include the plural 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 preclude 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", etc. as used herein only mean that there is an electrical or communication connection between two elements, and 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 that includes one or more appropriately configured processing circuits, which in some embodiments may be incorporated in one or more application specific integrated circuits (ASICs). In some embodiments, these processing circuits may include 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 operations described above. In some embodiments, these processing circuits may include customized hardware to perform one or more of the functions described above. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive.

[0049] Several embodiments of the present disclosure are illustrated in the accompanying drawings and described in the following detailed description, but it is to be understood that the 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 described and defined in the claims.

[0050] Furthermore, it should be noted that although the following description of some embodiments of the present disclosure is given 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. Thus, those skilled in the art can easily understand that the 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 entireties: - 3GPP TS23.007 V17.2.0(2021-09), 3rd Generation Partnership Project; Technical Specification Group Core Networks and Terminals; 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 Networks and Terminals; 5G Systems; 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 defined 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 architecture extensions for 5G systems (5GS) using 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 where 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 defined in clause 5 of 3GPP TS 23.247 v17.1.0 follows the 5G system architecture principles defined in 3GPP TS 23.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, see clause 6 of 3GPP TS23.247 v17.1.0 for further details.

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

[0060] NOTE 1: For clarity, the delivery method is not called unicast / multicast / broadcast, but as described below. The term "unicast delivery" refers to a mechanism where application data and signaling between the UE and the application server are delivered using PDU sessions in 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] There are two possible delivery methods for transmitting MBS data between 5GC and NG-RAN. - 5GC individual MBS traffic delivery method: This method applies only for 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, and 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 for both broadcast and multicast MBS sessions. The 5GC receives a single copy of MBS data packets and delivers a 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 a separate copy of the MBS data packet over the air interface to an 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 following figure, 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] FIG. 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 are applicable. As illustrated in FIG. 1, multiple UEs 100-1, 100-2, 100-3, and 100-4 may join an MBS session using different distribution methods. For example, UE 100-1 and UE 100-2 may be served by a 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 MBS data packets may be distributed from 5GC 110 to NG-RAN node 105, which then distributes the packets to UE 100-1 and UE 100-2 using a PTP distribution method or a PTM distribution method. In another example, UE 100-3 and UE 100-4 may be served by an 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 that 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 supports 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 TS 23.247 v17.1.0, clause 6.3.

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

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

[0074] FIG. 2 illustrates an example communication network 20 in which RAN node failure / restart detection and / or restoration according to some embodiments of the present disclosure are applicable, and shows 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, the 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 the UE 200 with access to other portions of the network 20. Additionally, the network 20 may comprise a core network portion of the network 20, which comprises (but is 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. 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, N4mb, and the like.

[0076] However, the present disclosure is not so limited. In some other embodiments, the network 20 may include additional network functions, fewer network functions, or some 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 the embodiments of the present disclosure. In other words, some of them may be missing from some embodiments of the present disclosure. The functions shown in FIG. 2 are described in detail below.

[0077] 2, the AMF 225 may provide most of the functions that the MME provides in a 4G network, as described above. Below, see a brief list of some of its functions. - terminating the RAN control plane (CP) interface (N2); - Non-Access Stratum (NAS) signalling; - NAS encryption and integrity protection, - Mobility Management (MM) layer NAS termination, - Session Management (SM) layer NAS forwarding, - authenticating the UE 200; - 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-RAN 205 and MB-SMF 235 for MBS session management; - Selection of the NG-RAN 205 for notification of a multicast session activation towards a 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 signalling 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, 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 an amalgamation of the data plane parts of the SGW and PGW: Evolved Packet Core (EPC) SGW-U + EPC PGW-U → 5G UPF in the context of the Control-User Plane Separation (CUPS) architecture.

[0084] The UPF 210 may perform at least one of the following functions: - Packet Routing and Forwarding Packet inspection and QoS handling: UPF 210 may also optionally incorporate deep packet inspection (DPI) for packet inspection and classification; - Connecting to Internet POPs (Points of Presence), the UPF 210 may also 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 implement at least one of the following functions to support MBS if dynamic PCC for MBS is required. - supporting QoS handling for MBS sessions; - providing the MB-SMF 235 with policy information about the MBS session in order to authorize the relevant QoS profile; - interacting with the UDR to retrieve QoS information; and - The PCF 255 can 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 the 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 de-allocating 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 sessions 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 the 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 the MB-SMF235 to receive multicast and broadcast data; - delivery of multicast and broadcast data to RAN nodes 205 for the 5GC shared MBS traffic delivery method; - Specific to multicast sessions: - Delivery of multicast data to the UPF 210 for the 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; - configuration of the UE 200 for receiving MBS QoS flows at the AS layer; - Control 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 and CM-CONNECTED with RRC inactivity states.

[0091] In addition to the functions specified in TS 23.501, UE 200 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 a multicast MBS session; - MBS resource management support at the AS layer, and - Receiving notifications in CM-IDLE and CM-CONNECTED with RRC inactivity states for multicast data transmission.

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

[0093] In addition to the functions specified in TS 23.501, the NEF 245 may further implement 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, e.g., the MB-SMF 235, for MBS session operation, transport parameter determination; 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 the 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, if 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, and packet FEC (encoding); and - Multicast / broadcast distribution of input files as objects or object flows.

[0096] In addition to the functions specified in TS 23.501, the UDM 265 may further implement 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 implement at least one of the following functions to support MBS: - supporting 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, the NRF260 may further perform at least one of the following functions to support 5G MBS: - Support for the 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 example communication network 20' in 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] It is noted that the existing reference points N1, N2, N4, N10, N11, N30 and N33 may be extended to support MBS. Furthermore, in terms of their functions, 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 may be applied. - If unicast transport over N3mb is applied, each NG-RAN allocates tunnel information (including IP address and TEID) that is provided to the MB-UPF (via AMF, MB-SMF) so that DL MBS packets can be sent to that tunnel entity. - If multicast transport over N3mb is applied, the NG-RAN does not provide tunnel information; instead, the NG-RAN subscribes to a multicast IP address provided by the MB-UPF.

[0103] The MB-UPF serves as an MBS session anchor for the MBS session, and if the 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 unicast tunnel for the MBS session (depending on the application and the capability 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 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 over a common GTP-U tunnel per MBS session, otherwise unicast transport over 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 reception of multicast data on 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] If the user plane uses unicast transport, the transport layer destination is the IP address of the NG-RAN or UPF, each NG-RAN or UPF allocates a tunnel separately, and multiple GTP-U tunnels are used for the MBS session. If the user plane uses multicast transport, a common GTP-U tunnel is used for both the RAN and UPF nodes. The GTP-U tunnel is identified as the transport layer destination by a common tunnel ID and an 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] Similar to that shown in Figure 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, and 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 distribution (e.g., to UE#3 200-3, UE#4 200-4), the MBS data received by the MB-UPF is replicated to the UPF(s) (e.g., UPF 210), and individual distribution 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 is applied, or via a single GTP tunnel if multicast transport over N19mb is applied. - 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, duplication 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 the 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 sessions, the FAR action is set to "drop" (e.g. 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, please refer to 3GPP TS29.244.

[0117] 5A and 5B are diagrams illustrating 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 3GPP TS 23.247 v17.1.0 clause 7.1.1 for details). - The UE may have registered in a PLMN or SNPN and established a PDU session that may be associated to a multicast session(s). - The UE knows at least the MBS Session IDs of the multicast groups that the UE can join, e.g. via a service announcement.

[0119] As shown in Figure 5A, in steps S501a and S501b, to join a multicast group, the UE sends a PDU Session Modify 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] The UE may alternatively join the 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 which case, before step S502, the network proceeds with the establishment of 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 the 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 subscription 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 to 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 it is the first time that the MB-SMF receives the 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 the 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 decides 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 for the multicast session if the UE is 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 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 flow(s) and (one or more) multicast QoS flow(s)]), N1 SM container (PDU Session Modify 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 information of the QoS flow 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 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 together 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 through a 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 the multicast MBS session information and the PDU session modification information is sent to the NG-RAN.

[0137] If MBS is not supported by the NG-RAN, 5GC individual MBS traffic delivery may be used. Otherwise, if MBS is supported by the NG-RAN, 5GC shared MBS traffic delivery 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 the NG-RAN that decides whether radio resources are allocated and it is the NG-RAN / UPF that decides 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 the establishment of 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 flows are included in the N2 SM response container. If MBS is supported by the NG-RAN, the N2 SM response container further includes an indication of supporting MBS.

[0145] In step S510, the AMF calls 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 dedicated 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 the directed multicast MBS session.

[0148] As shown in Figure 5B, steps S511a-S511e are optional and are used for 5GC dedicated MBS traffic delivery if the involved NG-RAN does not support MBS. Steps S511a-S511d are executed 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 executed 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 tunnel for this multicast MBS session should be newly 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 the 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 the 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 a Nmbsmf_MBSsession_ContextUpdate request(MBS session ID, [DL tunnel information]) towards the MB-SMF to establish multicast MBS session transport between the MB-UPF and the UPF.

[0153] In step S511c, if DL tunnel information of UPF is received, the MB-SMF configures the MB-UPF to send multicast MBS session data towards the UPF using the 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 Info]). If the UPF DL tunnel information for unicast transport is not received by the MB-SMF, multicast transport between the MB-UPF and the UPF should be used and the MB-SMF includes downlink tunnel information with the low 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 can manipulate 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 joined 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 in the N19mb tunnel associated with the multicast MBS session to the UPF. 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 TS 23.247 v17.1.0.

[0165] NOTE 9: When an MBSF is involved in a multicast MBS session, a 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, where RAN node failure / restart detection and / or restoration is applicable according to some embodiments of the present disclosure.

[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] As shown in Figure 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 the 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 a MB-SMF to serve the multicast MBS session, for example using an 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, at S603b, stores the NG-RAN node's information (e.g., NG-RAN node ID) for subsequent signaling related to the multicast MBS session.

[0173] In optional step S604, if the MB-SMF received 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 a 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 a transport multicast address (e.g., LL SSM) and a GTP tunnel endpoint for multicast transport of shared distribution.

[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 of the 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 / reinitiation detection and / or restoration according to some embodiments of the present disclosure is 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 may 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, either 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" state 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 latter UE is reachable, the UE Reachability Notification Address is used by the AMF to identify the involved SMFs and notify the involved SMFs.

[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 Information(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 as well as 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) that belong to this paging area with 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 the 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 sends a service request message to the AMF, see clause 4.2.3 of TS 23.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 SMF and informs the relevant SMF of the currently reachable UE(s) and their location information by using a Namf_MT_UEReachabilityInfoNotify message, which in this case may be a separate notification or 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 SM Info()) 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 a UPF for dedicated delivery and requests the MB-SMF to configure the MB-UPF to send multicast data to the UPF, if necessary.

[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 SM Information(Activated, 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 Information()) to the NG-RAN node. For UEs that join 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 a UE that has joined only the multicast session, since no unicast traffic is received for that UE.

[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 TS 23.502 clause 4.4.

[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, where the NG-RAN will now lose all session context, the NG-RAN will 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 decide 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 re-initiation or if there is a user plane path between the NG-RAN and the 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 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 for 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 TS 29.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 to 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 resource release of the PDU session 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 TS 23.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 FIG. 9(a), a NG reset initiated by the NG-RAN node is provided.

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

[0223] Upon 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.

[0224] After the AMF releases all allocated NG resources and UE NGAP IDs for all indicated UE associations that may be used for a new UE-associated logical NG-connection 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) that should be reset. - The AMF shall include in the NG Reset Acknowledge message the UE associated logical NG connection item IEs 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 FIG. 9(b), a 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 and replaces it 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 preserve 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 the NG reset procedure does.

[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 the Configure TAC Indication IE into account to optimize NG-C signaling towards this NG-RAN node.

[0232] If the UE Retained 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 a UE Retained 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 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 assume 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 of "Association.Max.Retrans" 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 the primary route is marked inactive (e.g., due to excessive retransmissions), the sender may automatically send new packets to the 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 about AMF support events. The AMF may provide this service as a service producer to enable an NF to subscribe to event notifications and be notified about events, either by itself 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, 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 a 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 TS 23.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: 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, the last known location of the UE is reported if the UE is in CM-IDLE state when the report is generated.

[0250] Event: Presence-In-AOI Report An NF subscribes to this event to receive the current presence state of a UE or group of UEs or any UE in a particular Area of ​​Interest (AOI) and notification when a specified UE enters or leaves a 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 IDs, "ANY_UE", Area Identifier (TA List, Area Id 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 the UE or 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 reported 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 of 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 access type (3GPP, non-3GPP)

[0253] Event: Registration status report The 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 of 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 state (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 connection management state change of the UE. UE type: single UE, group of UEs Report type: One-time report, continuous report Input: UE ID(s) Notification: UE ID, last 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 UE reachability state change 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 accesses (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 any of the two above states to REACHABLE. NOTE 3: The AMF shall 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 a paging request. The NF subscribes to this event for "UE reachable for DL ​​traffic" to receive reports of a UE or a group of UEs when the UE becomes 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 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 3GPP TS 29.503 clause 5.3.2.2.2), 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, current reachability state (REACHABLE / UNRACHABLE / REGULATORY_ONLY), access type(s) through which the UE is reachable.

[0256] Event: Communication failure report The NF subscribes to this event to receive communication failure reports for a UE or 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 TS 23.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 last known location-based area, or the NF may request the AMF to actively search for UEs in the current location-based area. This event implements the "Number of UEs present in a geographic area" event in Table 4.15.3.1-1 of 3GPP TS 23.502. UE Type: Any UE Input: "ANY_UE", optionally Ue in area filter: UE aerial indication, indication of PDU sessions established for DNN(s) covered by the 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 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 TS 23.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 TS 23.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 status 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 allocation code report An NF subscribes to this event to receive the TAC 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: (one or more) UE ID(s), "ANY_UE", optional filters: 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", optional filter: Area Identifier (TA List, Area Id or "LADN") Notification: UE ID(s), frequent registration

[0263] Event: Snssai 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", optional 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 the 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 contexts, including those MBS multicast sessions served by the NG-RAN. As specified in clause 7.2.1 (see also section 2.1.1.5) of TS23.247, only the SMF knows which UEs have joined the 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 restored via the control plane. After recovering from a restart or (partial) failure, the NG-RAN may notify the AMF of the (partial) failure or restart using a NG Setup Request or NG Reset as specified in 3GPP TS 38.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 failure with re-initiation. Thus, detection of NG-RAN failure with or without re-initiation can be done by the AMF without any protocol impact, according to existing specifications.

[0268] The AMF may inform the MB-SMF of the NG-RAN re-initiation / 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 re-initiation / 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 signalling messages: - AMF-SMF Option 1: via per-PDU session signalling, extended with new indications for NG-RAN re-initiation / failure. - AMf-SMF Option 2: One message for one UE using Nsmf_Ng_Reset or another new service action mechanism of the SMF. - One message for all UEs camped on the NG-RAN that experience a re-start / 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-start events given by the Namf_EventExposure service and the AMF may report NG-RAN re-start / failure events to the SMF if those PDU sessions (with active user plane RAN resources) are anchored in the SMF. When reporting such an event, the AMF shall also provide the SMF with a list of UEs and their PDU sessions that are affected by the NG-RAN failure (for details on AMF events, see the description below for more information).

[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 re-initiation, 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 may be detected and restored via the user plane. Both the UPF and the MB-UPF may detect the NG-RAN failure / restart.

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

[0274] If so, 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 UE subscription information to the NG-RAN. A new indication of NG-RAN re-initiation 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 liveness 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 re-initiation or a GTP-U path failure towards the NG-RAN. The UPF may report the GTP-U path failure or NG-RAN re-initiation to the SMF. In that case, the SMF may need to resolve the PDU session affected by the NG-RAN re-initiation or failure and request the AMF to perform paging for the affected UE(s) indicating the NG-RAN failure / re-initiation, 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 that was 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 the 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 not be aware if there is a NG-RAN re-start 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 re-initiation / 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 for the MB-SMF to 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 re-start / failure, and when 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 indication of the NG-RAN restart / failure in the N2 message container.

[0283] In some embodiments, to restore the 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 informed. 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 the 5GC. Thus, the multicast MBS service may be restored such 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 involved in an MBS session upon MBS session activation, the share distribution 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 the MBS session ID and 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 the 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 a MB-SMF 235 to 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 of 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 the location-dependent part of the multicast session context if an area session ID was 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 distribution.

[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 the 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 one 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 communication failure reports for a UE or 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 TS 23.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 having 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 the AMF 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 Inputs: "ANY_UE", an NF service consumer service instance Id, e.g. smfServiceInstanceId, or a 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 which SMFs the affected PDU sessions relate to 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 re-start, the NG-RAN may send a NG setup request or an NG reset request to the AMF.

[0304] FIG. 11 illustrates several example methods for detecting failure and / or re-initiation of a RAN node at a CP in accordance with 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 have experienced a failure or re-initiation.

[0313] In step S1106a, AMF215 may inform SMF230 of the NG-RAN failure / re-initiation 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, several methods for detecting NG-RAN failure / restart via user plane solutions and restoration may be described with reference to FIG. 12.

[0319] 12 illustrates a number of example methods for detecting failure and / or re-initiation 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] Besides error indication, it is also possible to have user plane path management. The MB-UPF 215 may 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 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 TS 23.527 subclause 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 the NG-RAN 205 for the given PDU session (associated with the MBS session) before its restart, and therefore the NG-RAN 205 will send a GTP-U error indication. The GTP-U error indication may be further reported to the SMF 230. The SMF 230 may be able to know which PDU sessions are affected by the NG-RAN restart.

[0326] Besides error indication, there may be user plane path management. The UPF 210 may 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 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 sessions associated with the MBS session.

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

[0329] FIG. 13 illustrates an example procedure for SMF-initiated multicast MBS session restoration according to some embodiments of the present disclosure. As shown in FIG. 13, an SMF 230-triggered restoration procedure is provided without notification from the MB-SMF 235. The restoration procedure is similar to steps S703-S710b in the MBS session activation procedure illustrated in FIG. 7A and FIG. 7B, and thus detailed descriptions of the same steps are omitted for simplicity. Furthermore, it is noted that this procedure may be a specific implementation of step S1107 illustrated in FIG. 11 and / or step S1209 illustrated in FIG. 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 re-initiation 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 NG-RAN re-initiation, 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 on a per-UE basis (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, the SMF 230 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 S1307 the NG-RAN restart indication flag may be passed to the NG-RAN 205. Based on this flag, the NG-RAN 205 may take action to ensure that the UE is added to the multicast MBS session distribution.

[0333] FIG. 14 illustrates an example procedure for MB-SMF initiated multicast MBS session restoration according to some embodiments of the present disclosure. As shown in FIG. 14, an SMF triggered restoration procedure is provided with notification from the MB-SMF 235. The restoration procedure is similar to steps S701-S710b in the MBS session activation procedure illustrated in FIG. 7A and FIG. 7B, and thus detailed description of the same steps is omitted for simplicity. Furthermore, it is noted that this procedure can be utilized when the MB-SMF detects NG-RAN failure / restart, e.g., after step S1103 in FIG. 11 or after step S1203 in FIG. 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 restoration based on the notification from the MB-SMF 235, not 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 the 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 the UE list served by the AMF 215. The SMF 230 may need to include the 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 a NG-RAN restart or failure, the multicast MBS session may be restored by the 5GC. Thus, the multicast MBS service may be restored such that UEs 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 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. The method 1500 may be implemented in a first network node (e.g., the SMF 230 shown in FIG. 2). The method 1500 may include step S1510. However, the present disclosure is not limited thereto. In some other embodiments, the method 1500 may include more steps, different steps, or any combination thereof. Furthermore, the steps of the method 1500 may be implemented in a different order than described herein. Furthermore, in some embodiments, the steps in the method 1500 may be split into multiple sub-steps and implemented by different entities, and / or multiple steps in the 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 re-initiation of the 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 a 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 and a fifth message for a multicast session, the fifth message being a request message sent from the AMF to request for a service operation provided by the SMF not specified in TS 23.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, the second message being 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, the third message being 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, the fourth message being 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, the fifth message being 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 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 the second message, the method further includes, prior to the step of receiving the message, sending to the AMF a message for subscribing to the event. In some embodiments, the message for subscribing to the event comprises at least one of an ID or IDs of one or more 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 re-initiation or failure indication.

[0344] In some embodiments, the third message is a PFCP Session Report message comprising a 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 a RAN node failure and / or re-initiation and / or an ID of the RAN node.

[0345] FIG. 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 re-initiation, provided in accordance with one embodiment of the present disclosure. The method 1600 may be implemented in a first network node (e.g., the SMF 230 shown in FIG. 2). The method 1600 may include step S1610. However, the present disclosure is not limited thereto. In some other embodiments, the method 1600 may include more steps, different steps, or any combination thereof. Furthermore, the steps of the method 1600 may be implemented in a different order than described herein. Furthermore, in some embodiments, the steps in the method 1600 may be split into multiple sub-steps and implemented by different entities, and / or multiple steps in the 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 step of triggering the establishment of related resources at the RAN node includes sending a sixth message to the RAN node via the AMF to cause the RAN node to initiate establishment of related resources for the multicast session. In some embodiments, the sixth message comprises an indicator indicating the failure and / or re-initiation of the RAN node and / or an ID of the RAN node. In some embodiments, prior to the step of triggering the establishment of related 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 step of determining 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 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 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 put the UEs in a CM-CONNECTED mode, where the request message comprises an indicator indicating a failure and / or a re-initiation 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 in the RAN node, the method further includes receiving a fifth message from the MB-SMF indicating the detected failure and / or re-initiation 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 having 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-initiation 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-initiation 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-initiation of the RAN node is detected by the SMF by the method described with reference to FIG. 15.

[0349] FIG. 17 is a flowchart of an example method 1700 in an AMF for facilitating a network node to detect 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. The method 1700 may be implemented in a second network node (e.g., the AMF 225 shown in FIG. 2). The method 1700 may include steps S1710 and S1720. However, the present disclosure is not limited thereto. In some other embodiments, the method 1700 may include more steps, fewer steps, different steps, or any combination thereof. Furthermore, the steps of the method 1700 may be implemented in a different order than described herein. Furthermore, in some embodiments, the steps in the method 1700 may be split into multiple sub-steps and implemented by different entities, and / or multiple steps in the 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 transmitted to the network node indicating a failure and / or re-initiation 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 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 failure and / or re-initiation of a 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 a RAN node. 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 re-initiation 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 sending the MB-SMF a request to establish a shared distribution towards the RAN node for a multicast session based at least on the eighth request message. The method further includes sending 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 sending 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] FIG. 18 is a flowchart of an example method 1800 in an AMF for facilitating an SMF to restore a multicast session for one or more UEs served by a RAN node that has experienced a failure and / or re-initiation, provided in accordance with one embodiment of the present disclosure. The method 1800 may be implemented in a second network node (e.g., the AMF 225 shown in FIG. 2). The method 1800 may include step S1810. However, the present disclosure is not limited thereto. In some other embodiments, the method 1800 may include more steps, different steps, or any combination thereof. Furthermore, the steps of the method 1800 may be implemented in a different order than described herein. Furthermore, in some embodiments, the steps in the method 1800 may be split into multiple sub-steps and implemented by different entities, and / or multiple steps in the 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 a response message to the SMF to indicate which of the one or more UEs are in the CM-CONNECTED mode based at least on a result of the paging procedure. In some embodiments, prior to the step of forwarding the sixth message, the method further includes receiving a request message from the SMF to query one or more UEs affected by the failure and / or re-initiation of the RAN node and / or to request the AMF to page one or more UEs, where 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 the 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 a response message to the SMF comprising an acceptance of the one or more UEs and / or paging based at least on a result of the paging procedure.

[0360] FIG. 19 is a flowchart of an example method 1900 in an MB-SMF for detecting 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. The method 1900 may be implemented in a third network node (e.g., the MB-SMF 235 shown in FIG. 2). The method 1900 may include step S1910. However, the present disclosure is not limited thereto. In some other embodiments, the method 1900 may include more steps, different steps, or any combination thereof. Furthermore, the steps of the method 1900 may be implemented in a different order than described herein. Furthermore, in some embodiments, the steps in the method 1900 may be split into multiple sub-steps and implemented by different entities, and / or multiple steps in the 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 re-initiation of the 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 a 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 a shared distribution towards the RAN node for a 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 receiving the ninth request message from the AMF requesting to establish a shared distribution towards the RAN node for a 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 setting, in the MB-UPF, an IP address, or N3mb tunnel endpoint information when unicast transport is used, such that the MB-UPF is able to use the transport IP address, or the IP address in the N3mb tunnel endpoint indicated by the N3mb tunnel endpoint information, to probe 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 or not and / or indicating information for establishing the shared distribution based at least on a result of the setting in the MB-UPF.

[0364] In some embodiments, after receiving the ninth request message, the method further includes establishing a mapping between RAN node IDs 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 the RAN node IDs and the tunnels, and sending a message to the MB-UPF to release the tunnels.

[0365] In some embodiments, the ninth request message is a Nmbsmf_MBSSession_ContextUpdate request message and the ninth response message is a 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 re-initiation, provided in accordance with one embodiment of the present disclosure. The method 2000 may be implemented in a third network node (e.g., the MB-SMF 235 shown in FIG. 2). The method 2000 may include step S2010. However, the present disclosure is not limited thereto. In some other embodiments, the method 2000 may include more steps, different steps, or any combination thereof. Furthermore, the steps of the method 2000 may be implemented in a different order than described herein. Furthermore, in some embodiments, the steps in the method 2000 may be split into multiple sub-steps and implemented by different entities, and / or multiple steps in the method 2000 may be combined into a single step.

[0367] The method 2000 may begin in step S2010, where in response to detecting a failure and / or re-initiation of the RAN node, establishing associated resources in 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 to detect 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. The method 2100 may be implemented in a RAN node (e.g., NG-RAN 205 shown in FIG. 2). The method 2100 may include step S2110. However, the present disclosure is not limited thereto. In some other embodiments, the method 2100 may include more steps, different steps, or any combination thereof. Furthermore, the steps of the method 2100 may be implemented in a different order than described herein. Furthermore, in some embodiments, the steps in the method 2100 may be split into multiple sub-steps and implemented by different entities, and / or multiple steps in the 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 re-initiation 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, prior to the step of receiving the seventh message, the method further comprises 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 has been successfully established and / or indicating information for establishing the shared distribution. In some embodiments, the method further comprises subscribing to a 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] FIG. 22 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. In the configuration 2200, a processing unit 2206 is provided, for example 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 a non-volatile or volatile memory, e.g., an Electrically Erasable Programmable Read Only Memory (EEPROM), a flash memory, and / or a hard drive. Computer program product 2208 comprises a computer program 2210 comprising code / computer readable instructions which, 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 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 2210A configured to receive a message from the network node indicating a failure and / or a 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 in 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] The computer program 2210 may be further configured as computer program code structured in computer program modules 2210C and 2210D. Thus, in an example embodiment when the configuration 2200 is used in a second network node, the code in the computer program of the configuration 2200 includes a module 2210C configured to receive a seventh message from the RAN node reporting a failure and / or re-initiation of the RAN node, and a module 2210D configured to send a message to the network node in response to the received seventh message indicating the failure and / or re-initiation of the RAN node.

[0377] The computer program 2210 may be further configured as a computer program code structured in a computer program module 2210E. Thus, in an example embodiment when the configuration 2200 is used in a second network node, the code in the computer program of the configuration 2200 includes a 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 a re-initiation of the RAN node.

[0379] The computer program 2210 may be further configured as computer program code structured in a computer program module 2210G. 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 2210G configured to trigger, in response to detecting a failure and / or re-initiation of the RAN node, establishing associated resources in 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 further be 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 the network node reporting a failure and / or a restart of the RAN node.

[0381] The computer program modules may essentially implement the actions of the flows illustrated 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 a related chipset, and / or a dedicated microprocessor such as an application specific integrated circuit (ASIC). The processor may also comprise an 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 be distributed on different computer program products in the form of memories in the network node and / or the RAN node in alternative embodiments.

[0384] Corresponding to the above-described method 1500 and / or method 1600, an exemplary first network node is provided. 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 indicating a failure and / or re-initiation of a RAN node from a network 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 individual delivery or the MB-UPF for shared delivery to restore a 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 a memory for storage of the software, a programmable logic device (PLD), or one or more of the other electronic components or processing circuits configured to perform the actions described above and shown, for example, in Figure 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 the method 1500 and / or method 1600 described with reference to Figure 15 and / or 16.

[0387] Corresponding to the above-described method 1700 and / or method 1800, an exemplary second network node is provided. 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 implement 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 a message indicating the failure and / or re-initiation of the RAN node to the network node in response to the received seventh message. Additionally or alternatively, the second network node 2400 may be configured to implement 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 a memory for storage of the software, a programmable logic device (PLD), or one or more of the other electronic components or processing circuits configured to perform the actions described above and shown, for example, in Figure 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 the method 1700 and / or method 1800 described with reference to Figure 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 FIG. 19. As shown in FIG. 25, the third network node 2500 may comprise a receiving module 2510 configured to receive a message indicating a failure and / or re-initiation of a RAN node from a network node. Additionally or alternatively, the third network node 2500 may be configured to perform the method 2000 described above with respect to FIG. 20. As also shown in FIG. 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 a memory for storage of the software, a programmable logic device (PLD), or one or more of the other electronic components or processing circuits configured to perform the actions described above and shown, for example, in Figure 19 and / or Figure 20. Furthermore, the first network node 2500 may comprise one or more further modules, each of which may perform any of the steps of the method 1900 and / or method 2000 described with reference to Figure 19 and / or Figure 20.

[0393] Corresponding to the method 2100 described above, an exemplary RAN node is provided. 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 of the other electronic components or processing circuits 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 the embodiments of the present disclosure. However, these embodiments are provided only for illustrative purposes, 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 Features 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. 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 re-initiation, the method (1500, 1600) comprising: receiving (S1510) a message indicating a RAN node failure and / or re-initiation of the RAN node (205) from a network node (225, 210, 235); 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) establishing relevant resources in the RAN node (205) via an Access and Mobility Management Function (AMF) (225) for receiving multicast session data from either a UPF (210) for individual distribution or a Multicast Broadcast User Plane Function (MB-UPF) (235) for shared distribution in order to restore the multicast session for the affected one or more UEs (200); A method (1500, 1600) comprising:

2. The network node, An Access and Mobility Management Function (AMF); - A User Plane Function (UPF), - Multicast / Broadcast Session Management Function (MB-SMF) The method of claim 1 , comprising at least one of:

3. 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 first message for one or more UEs and / or one or more PDU sessions, the first message being a request message sent from an AMF to request for a service operation provided by the SMF, the request message being not specified in any of 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, the second message being an event notification message from an AMF to notify the SMF of a failure and / or re-initiation 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 The method (1500, 1600) of claim 1 or 2, comprising at least one of:

4. The first message comprises: a single UE and / or a single PDU session affected by the failure and / or re-initiation of the RAN node; 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; The method of claim 3, further comprising: indicating one of:

5. The second message is - a communication failure report event; - an AMF event not specified in said 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; The method of claim 3 or 4, further comprising: indicating one of:

6. When the message includes the second message, the method (1500, 1600) further comprises, before the step of receiving the message, Sending a message to the AMF to subscribe to the event. The method (1500, 1600) of any one of claims 3 to 5, further comprising:

7. The message for subscribing to the event comprises: - an identifier (ID) or identifiers of said UEs or an "any UE" indication; one or more area identifiers; - A Network Function (NF) Service Consumer Service Instance ID; and - The authority of the resource Uniform Resource Identifier (URI) The method of claim 6, comprising at least one of:

8. The event is - RAN / Non-Access Stratum (NAS) release code; - one or more UE IDs; one or more PDU Session IDs; and - NG-RAN restart or failure indication The method (1500, 1600) of any one of claims 3 to 7, comprising at least one of:

9. The step of determining the one or more UEs further comprises: determining the one or more UEs indicated in a received message from the AMF, the received message further indicating the failure and / or re-initiation of the RAN node; and When the RAN failure or re-initiation is reported by the UPF, 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. The method of claim 1 , comprising at least one of:

10. Prior to the step of triggering the establishment of the associated resources in the RAN node, the method (1500, 1600) further comprises: receiving a fifth message from a MB-SMF indicating a detected failure and / or re-initiation 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 an association with the RAN node; receiving a response message from the NRF, the response message 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 of claim 1 further comprising:

11. 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 10; SMF (230, 2200, 2300) comprising:

12. 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 re-initiation of the RAN node (205) (S1710); sending (S1720) a message to the network node (230, 235) in response to the received seventh message indicating the failure and / or re-initiation of the RAN node (205); A method (1700, 1800) comprising:

13. The network node, - SMF and - MB-SMF and 13. The method of claim 12, comprising at least one of:

14. The message may include: - a Nmbsmf_MBSSession_ContextUpdate request message sent to the MB-SMF for said multicast session; - an Nsmf_PDUSession_UpdateSMContext request message sent to an 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, the first message being a request message sent to an SMF to request for a service operation provided by the SMF, the request message being not specified in 3GPP TS 23.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, 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; 14. The method of claim 12 or 13, comprising at least one of:

15. The Nmbsmf_MBSSession_ContextUpdate request message: the ID of said multicast session, - the ID of the RAN node that experienced the re-initiation and / or failure; The method of claim 14, further comprising indicating at least one of:

16. The first message comprises: a single UE and / or a single PDU session affected by the failure and / or re-initiation of the RAN node; 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; The method (1700, 1800) of claim 14 or 15, further comprising indicating one of:

17. The second message is - a communication failure report event; - an AMF event not specified in said 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; The method (1700, 1800) of any one of claims 14 to 16, further comprising indicating one of:

18. When the message includes the second message, the method (1700, 1800) further comprises, 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 transmitting the message, the method (1700, 1800) further comprises: 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; 18. The method (1700, 1800) of any one of claims 14 to 17, further comprising:

19. The message for subscribing to the event comprises: - the identity of said UE(s) or an "any UE" indication; and one or more area identifiers; NF Service Consumer Service Instance Id, and - The authority of the resource URI 20. The method of claim 18, comprising at least one of:

20. The event is - RAN / NAS release code; - one or more UE IDs; one or more PDU Session IDs; and - NG-RAN restart or failure indication 20. The method (1700, 1800) of any one of claims 14 to 19, comprising at least one of:

21. 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 12 to 20; AMF (225, 2200, 2400) equipped with

22. 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 re-initiation, the method (1900, 2000) comprising: receiving (S1910) a message from a network node (200) indicating a failure and / or re-initiation of the RAN node (205); triggering (S2010) in response to receiving the message indicating the failure and / or re-initiation of the RAN node (205) to establish related 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:

23. The network node, - AMF and - MB-UPF and 23. The method of claim 22, comprising at least one of:

24. 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 a 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 a MB-UPF for reporting the failure and / or re-initiation of the RAN node; and 24. The method of claim 22 or 23, comprising at least one of:

25. The Nmbsmf_MBSSession_ContextUpdate request message: the ID of said multicast session, - the ID of the RAN node that experienced the re-initiation and / or failure; The method of claim 24, further comprising indicating at least one of:

26. Prior to the step of receiving the message, the method further comprises: receiving a ninth request message from an AMF requesting to establish a 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 in the MB-UPF 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 in an N3mb tunnel endpoint indicated by the N3mb tunnel endpoint information, to probe liveness of the RAN node; storing the AMF in a context for the multicast session; 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; 26. The method (1900, 2000) of any one of claims 22 to 25, further comprising:

27. 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.

27. The method of claim 26, further comprising:

28. 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 IDs of the RAN nodes and the tunnels; sending a message to the MB-UPF to release the tunnel; 28. The method of claim 27, further comprising:

29. Triggering one or more tunnels to be established, 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; 29. The method (1900, 2000) of any one of claims 22 to 28, comprising:

30. The notification message is the ID of said RAN node; and - an indication of said failure and / or re-initiation of said RAN node; 31. The method of claim 30, comprising at least one of:

31. 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 22 to 30; Equipped with MB-SMF (235, 2200, 2500).

32. A computer program (2210) comprising instructions that, when executed by at least one processor (2206), cause the at least one processor (2206) to perform a method (1500, 1600, 1700, 1800, 1900, 2000, 2100) according to any one of claims 1 to 10, 12 to 20, and 22 to 30.

33. 33. A carrier (2208) containing the computer program (2210) of claim 32, said carrier (2208) being one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

34. A communication system (20, 20') for maintaining a multicast session, said communication system (20, 20') comprising: The SMF (230) of claim 11; An AMF (225) according to claim 21; The MB-SMF (235) according to claim 31; A communication system (20, 20').

Images