Recovery of multicast or broadcast sessions
By detecting the accessibility of RAN nodes at the AMF and reporting to the MB-SMF, an alternative RAN node with failed AMF processing was established, and the recovery problems caused by NG-RAN unreachable and AMF failure in 5G multicast/broadcast services were solved. High availability and cost reduction of services are achieved.
Patent Information
- Application Number
- CN202380038117.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2022-05-04
- Filing Date
- 2023-04-27
- Publication Date
- 2024-12-13
AI Technical Summary
When providing 5G multicast/broadcast services, the lack of management functions makes it impossible to report NG-RAN unreachable during the multicast/broadcast service session startup/release/update/activate/deactivate, resulting in the inability to remediate. Measures, and in the event of AMF failure, the AMF responsible for restoring the broadcast MBS session cannot be determined.
By determining at the AMF whether it is possible to contact the RAN node related to the multicast or broadcast session, and sending an indication message to the MB-SMF, an alternative AMF is established to handle the failed RAN node, avoiding failure caused by local link interruption, and realizing broadcast MBS Recovery of session information.
It effectively avoids failure caused by local link interruption between multicast or broadcast MBS sessions between NG-RAN and AMF, ensures the recovery and service continuity of broadcast MBS sessions, and reduces operating costs.
Smart Images

Figure CN119137918A_ABST
Abstract
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims priority to PCT International Application No. PCT / CN2022 / 090851, filed on May 4, 2022, entitled “RESTORATION OF MULTICAST ORBROADCAST SESSION,” the entire contents of which are incorporated herein by reference. Technical Field
[0002] The present disclosure relates to the field of telecommunications, and in particular, to a network node and method for resuming a multicast session or a broadcast session. Background Art
[0003] Broadcast services with scheduled programming constitute the most important telecommunication services in today's society. Broadcast is a transmission technology used to deliver the same content to an unlimited number of devices with a defined quality of service (QoS) without significantly increasing network capacity requirements, energy consumption or costs. Cellular systems are usually used for unicast transmission. In this mode, a dedicated channel is established with each UE. In scenarios where a large number of users or devices consume the same data, the use of broadcast or multicast transmission can provide significant capacity gains, ensuring a cost-effective and high-quality transmission 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 sending data to a group of users simultaneously. Via broadcast services, all users receive the same information within the service area. In multicast services, users must subscribe to a specific service before they receive the information. While broadcast communications are one-way, multicast users can establish a return channel that allows interaction with the network. The return channel can also be used to subscribe to the desired service.
[0005] Although the existing technology is mature, the current broadcast system has serious limitations in providing services to users on the move or users located in areas with complex terrain and poor signal quality. To overcome these limitations, the 3rd Generation Partnership Project (3GPP) 5G standard has included a work item to support 5G multicast / broadcast services in Release 17. This will bring the extensive flexibility and efficiency of 5G networks to broadcast services to greatly improve the user experience while reducing operating costs. In addition, 5G broadcast / multicast services can complement conventional broadcast technologies, which have serious shortcomings in some scenarios (such as users in mobility or remote areas). Summary of the invention
[0006] However, there is a lack of a mechanism that enables the Access and Mobility Management Function (AMF) to report to the Multicast / Broadcast Session Management Function (MB-SMF) an "unreachable" failure associated with one or more Next Generation Radio Access Networks (NG-RAN) that are part of the MBS service area during a Multicast / Broadcast Service (MBS) session start / release / update / activation / deactivation procedure, so it is not even possible to take any remedial action to resolve it. In addition, when the AMF that was handling the establishment of a broadcast MBS session or the last update of a broadcast MBS session has failed before the NG-RAN failure, it is unclear which AMF belonging to the same AMF set (as the AMF that previously handled the broadcast MBS session) will be responsible for resuming the broadcast MBS session.
[0007] According to a first aspect of the present disclosure, a method for facilitating an MB-SMF to attempt multicast session signaling for a multicast session or broadcast session signaling for a broadcast session at an AMF is provided. The method comprises: determining whether the AMF is unable to contact one or more radio access network (RAN) nodes for a multicast session or a broadcast session; and in response to determining that the AMF is unable to contact at least one first RAN node among the one or more RAN nodes for the multicast session or the broadcast session, sending a first message indicating the at least one first RAN node to the MB-SMF.
[0008] In some embodiments, before the step of determining whether the AMF is unable to contact one or more RAN nodes for a multicast session or a broadcast session, the method further comprises: sending a second message associated with the multicast session or the broadcast session to each of the one or more RAN nodes, wherein the step of determining that the AMF is unable to contact the at least one first RAN node comprises: determining that the at least one first RAN node does not respond to the second message within a certain period of time. In some embodiments, the step of determining that the AMF is unable to contact the at least one first RAN node comprises: determining that there is a failure in a path towards the at least one first RAN node.
[0009] In some embodiments, the first message indicates at least one of the following: at least one identifier of the at least one first RAN node; an identifier of a multicast session or a broadcast session; and an indication indicating that the at least one first RAN node cannot be contacted. In some embodiments, the indication further indicates at least one of the following: whether the AMF has detected a startup or restart of the corresponding NG-RAN; whether the AMF has detected a failure without the corresponding NG-RAN restarting; whether the AMF has been unable to reach the corresponding NG-RAN when sending the NGAP MBS session setup request message; whether the AMF has been unable to reach the corresponding NG-RAN when sending the NGAP MBS session modification request message; and whether the AMF has been unable to reach the corresponding NG-RAN when sending the NGAP MBS session release request message. In some embodiments, the method further includes: receiving a third message from the MB-SMF in response to the first message. In some embodiments, before the step of determining whether the AMF cannot contact one or more RAN nodes for the multicast session or the broadcast session, the method further includes: receiving a fourth message from the MB-SMF, the fourth message indicating that the AMF will contact the one or more RAN nodes to perform operations associated with the multicast session or the broadcast session. In some embodiments, the fourth message indicates at least one of: an identifier of a multicast session or a broadcast session; a service area associated with the multicast session or the broadcast session; and information associated with the multicast session or the broadcast session to be delivered to the one or more RAN nodes. In some embodiments, the second message is sent in response to receiving the fourth message.
[0010] In some embodiments, the method further comprises: in response to sending the second message, receiving a fifth message from each of at least one of the one or more RAN nodes, the fifth message indicating whether the operation associated with the multicast session or the broadcast session is successfully performed; and based at least on the fifth message, sending a sixth message to the MB-SMF, the sixth message indicating whether the operation is successfully performed. In some embodiments, the method further comprises: receiving a seventh message from the MB-SMF, the seventh message indicating one or more identifiers of one or more third RAN nodes, the one or more third RAN nodes to be contacted by the AMF to perform the operation associated with another multicast session or the broadcast session; based at least on the seventh message, sending an eighth message to each of the one or more third RAN nodes, the eighth message indicating the one or more third RAN nodes to perform the operation associated with the another multicast session or the broadcast session; in response to sending the eighth message, receiving at least one ninth message from at least one of the one or more third RAN nodes, the at least one ninth message indicating whether the corresponding at least one third RAN node is successfully performing the operation associated with the another multicast session or the broadcast session; and based at least on the ninth message, sending a tenth message to the MB-SMF, the tenth message indicating whether the operation associated with the another multicast session or the broadcast session is successfully performed. In some embodiments, the seventh message indicates at least one signaling type associated with at least one of the one or more third RAN nodes, respectively. In some embodiments, the eighth message is a request message of the type indicated by the seventh message, and / or the corresponding ninth message is a response or failure message of the type indicated by the seventh message. In some embodiments, the seventh message further indicates whether to release the multicast session or broadcast session at the AMF and / or the one or more third RAN nodes.
[0011] In some embodiments, at least one of the fifth message, the sixth message, the ninth message, and the tenth message further indicates unicast transport network layer (TNL) information for shared transmission of the multicast session or the broadcast session. In some embodiments, the multicast session or the broadcast session is an MBS session. In some embodiments, when the multicast session or the broadcast session is a broadcast MBS session, at least one of the following situations is true: the first message is a Namf_MBSBroadcast_ContextStatusNotify request message; the second message is one of a broadcast session setup request message, a broadcast session release request message, and a broadcast session modification request message; the third message is a Namf_MBSBroadcast_ContextStatusNotify response message; the fourth message is one of a Namf_MBSBroadcast_ContextCreate request message, a Namf_MBSBroadcast_ContextRelease request message, and a Namf_MBSBroadcast_ContextUpdate request message; the fifth message is one of a broadcast session setup response message, a broadcast session release response message, and a broadcast session modification response message; the sixth message is a Namf_MBSBroadcast_ContextCreate response message, a Namf_MBS The seventh message is one of the Namf_MBSBroadcast_ContextCreate request message, the Namf_MBSBroadcast_ContextRelease request message, and the Namf_MBSBroadcast_ContextUpdate request message; the eighth message is one of the broadcast session establishment request message, the broadcast session release request message, and the broadcast session modification request message; the ninth message is one of the broadcast session establishment response message, the broadcast session release response message, and the broadcast session modification response message; and the tenth message is one of the Namf_MBSBroadcast_ContextCreate response message, the Namf_MBSBroadcast_ContextRelease response message, and the Namf_MBSBroadcast_ContextUpdate response message.
[0012] According to a second aspect of the present disclosure, a first network node is provided. The first network node comprises: a processor; a memory storing instructions, which, when executed by the processor, causes the processor to perform any one of the methods in the first aspect. In some embodiments, an AMF is hosted at the first network node.
[0013] According to a third aspect of the present disclosure, a first network node is provided. The first network node includes: a determination module configured to determine whether the AMF cannot contact one or more RAN nodes for a multicast session or a broadcast session; and a sending module configured to: in response to determining that the AMF cannot contact at least one first RAN node among the one or more RAN nodes for the multicast session or the broadcast session, send a first message indicating the at least one first RAN node to the MB-SMF. In some embodiments, the first network node includes one or more additional modules configured to perform the method of any one of the first aspects.
[0014] According to a fourth aspect of the present disclosure, a method for attempting multicast session signaling for a multicast session or broadcast session signaling for a broadcast session at an MB-SMF is provided. The method comprises: receiving a first message from a first AMF, the first message indicating that the first AMF cannot contact at least one first RAN node for a multicast session or a broadcast session; determining a second AMF belonging to the same AMF set and / or the same AMF service set as the first AMF; and sending a seventh message to the second AMF, the seventh message indicating one or more identifiers of the at least one first RAN node, the at least one first RAN node to be contacted by the second AMF to perform operations associated with the multicast session or the broadcast session.
[0015] In some embodiments, the first message indicates at least one of the following: at least one identifier of the at least one first RAN node; an identifier of a multicast session or a broadcast session; and an indication indicating that the at least one first RAN node cannot be contacted at the first AMF. In some embodiments, the indication further indicates at least one of the following: whether the first AMF has detected a startup or restart of the corresponding NG-RAN; whether the first AMF has detected a failure without the corresponding NG-RAN restarting; whether the first AMF has been unable to reach the corresponding NG-RAN when sending the NGAP MBS session setup request message; whether the first AMF has been unable to reach the corresponding NG-RAN when sending the NGAP MBS session modification request message; and whether the first AMF has been unable to reach the corresponding NG-RAN when sending the NGAP MBS session release request message. In some embodiments, the seventh message is generated based at least on the received indication, so that the seventh message indicates at least one signaling type associated with the at least one first RAN node, respectively. In some embodiments, the seventh message further indicates whether to release the multicast session or the broadcast session at the second AMF and / or the at least one first RAN node.
[0016] In some embodiments, the method further comprises: sending a third message to the first AMF in response to the first message. In some embodiments, before the step of receiving the first message, the method further comprises: sending a fourth message to the first AMF, the fourth message indicating that the first AMF will contact one or more RAN nodes to perform operations associated with the multicast session or the broadcast session, the one or more RAN nodes including the at least one first RAN node. In some embodiments, the fourth message indicates at least one of the following items: an identifier of the multicast session or the broadcast session; a service area associated with the multicast session or the broadcast session; and information associated with the multicast session or the broadcast session to be delivered to the one or more RAN nodes.
[0017] In some embodiments, the method further includes: receiving a sixth message from the first AMF, the sixth message indicating whether the one or more RAN nodes successfully performed an operation associated with the multicast session or the broadcast session. In some embodiments, the method further includes: receiving a tenth message from the second AMF, the tenth message indicating whether the at least one RAN node successfully performed an operation associated with the multicast session or the broadcast session. In some embodiments, at least one of the sixth message and the tenth message also indicates unicast TNL information for shared transmission of the multicast session or the broadcast session. In some embodiments, the method further includes: communicating with a multicast / broadcast user plane function (MB-UPF) to provide unicast TNL information for shared transmission of the multicast session or the broadcast session from the MB-UPF to the one or more RAN nodes or the at least one first RAN node.
[0018] In some embodiments, the multicast session or the broadcast session is an MBS session. In some embodiments, when the multicast session or the broadcast session is a broadcast MBS session, at least one of the following is true: the first message is a Namf_MBSBroadcast_ContextStatusNotify request message; the third message is a Namf_MBSBroadcast_ContextStatusNotify response message; the fourth message is one of a Namf_MBSBroadcast_ContextCreate request message, a Namf_MBSBroadcast_ContextRelease request message, and a Namf_MBSBroadcast_ContextUpdate request message; the sixth message is one of a Namf_MBSBroadcast_ContextCreate response message, a Namf_MBS The seventh message is one of the Broadcast_ContextRelease response message and the Namf_MBSBroadcast_ContextUpdate response message; the seventh message is one of the Namf_MBSBroadcast_ContextCreate request message, the Namf_MBSBroadcast_ContextRelease request message and the Namf_MBSBroadcast_ContextUpdate request message; and the tenth message is one of the Namf_MBSBroadcast_ContextCreate response message, the Namf_MBSBroadcast_ContextRelease response message and the Namf_MBSBroadcast_ContextUpdate response message.
[0019] According to a fifth aspect of the present disclosure, a second network node is provided. The second network node comprises: a processor; a memory storing instructions, which, when executed by the processor, causes the processor to perform any method in the fourth aspect. In some embodiments, the MB-SMF is hosted at the second network node.
[0020] According to the sixth aspect of the present disclosure, a second network node is provided. The second network node includes: a receiving module configured to receive a first message from a first AMF, the first message indicating that the first AMF cannot contact at least one first RAN node for a multicast session or a broadcast session; a determining module configured to determine a second AMF belonging to the same AMF set and / or the same AMF service set as the first AMF; and a sending module configured to send a seventh message to the second AMF, the seventh message indicating one or more identifiers of the at least one first RAN node, the at least one first RAN node to be contacted by the second AMF to perform operations associated with the multicast session or the broadcast session. In some embodiments, the second network node includes one or more additional modules configured to perform the method of any one of the fourth aspects.
[0021] According to a seventh aspect of the present disclosure, there is provided a method at an AMF for facilitating MB-SMF to resume a broadcast session. The method comprises: receiving an eleventh message from the MB-SMF, the eleventh message comprising an indication that the eleventh message will provide information associated with the broadcast session, the information being used for subsequent resumption of the broadcast session only when one or more RAN nodes are restarted.
[0022] In some embodiments, the eleventh message indicates at least one of the following: an identifier of the broadcast session; a service area associated with the broadcast session; information required for subsequent resumption of the broadcast session; and a resumption indication indicating that the AMF will not trigger any NG Application Protocol (NGAP) signaling to the one or more RAN nodes for resuming the broadcast session. In some embodiments, when the resumption indication is set to "true" and the service area is indicated by the eleventh message, the AMF is requested not to trigger any NGAP signaling towards one or more NG-RAN nodes covering the indicated service area. In some embodiments, the AMF and another AMF used for resumption of the broadcast session belong to the same AMF set and / or the same AMF service set. In some embodiments, the method further includes: sending a twelfth message to the MB-SMF, the twelfth message replying to the eleventh message and indicating that the AMF has taken over the broadcast session from the other AMF. In some embodiments, the broadcast session is an MBS session. In some embodiments, at least one of the following is true: the eleventh message is a Namf_MBSBroadcast_ContextUpdate request message; and the twelfth message is a Namf_MBSBroadcast_ContextUpdate response message.
[0023] According to an eighth aspect of the present disclosure, a first network node is provided. The first network node comprises: a processor; a memory storing instructions, which, when executed by the processor, causes the processor to perform any method in the seventh aspect. In some embodiments, the AMF is hosted at the first network node.
[0024] According to a ninth aspect of the present disclosure, there is provided a first network node. The first network node comprises: a receiving module configured to receive an eleventh message from an MB-SMF, the eleventh message comprising an indication that the eleventh message will provide information associated with the broadcast session, the information being used for subsequent resumption of the broadcast session only when one or more RAN nodes are restarted. In some embodiments, the first network node comprises one or more additional modules configured to perform the method of any one of the seventh aspects.
[0025] According to a tenth aspect of the present disclosure, a method for resuming a broadcast session at an MB-SMF is provided. The method comprises: determining whether a first AMF is unable to provide services for the broadcast session; determining that a second AMF takes over the broadcast session from the first AMF; and sending an eleventh message to the second AMF, the eleventh message including an indication that the eleventh message will provide information associated with the broadcast session, the information being used for subsequent resumption of the broadcast session only when one or more RAN nodes are restarted.
[0026] In some embodiments, the eleventh message indicates at least one of the following: an identifier of the broadcast session; a service area associated with the broadcast session; information required for the second AMF to subsequently resume the broadcast session; and a resume indication indicating that the second AMF will not trigger any NGAP signaling to the one or more RAN nodes for resuming the broadcast session. In some embodiments, when the resume indication is set to "true" and the service area is indicated by the eleventh message, the second AMF is requested not to trigger any NGAP signaling towards one or more NG-RAN nodes covering the indicated service area. In some embodiments, the first AMF and the second AMF belong to the same AMF set and / or the same AMF service set. In some embodiments, the method further includes: receiving a twelfth message from the second AMF, the twelfth message replying to the eleventh message and indicating that the second AMF has taken over the broadcast session from the first AMF. In some embodiments, the step of determining whether the first AMF is unable to provide service for the broadcast session includes: detecting whether the first AMF is unable to provide service for the broadcast session by using a Hypertext Transfer Protocol Version 2 (HTTP / 2) Ping frame.
[0027] In some embodiments, before the step of determining whether the first AMF is unable to provide services for the broadcast session, the method further includes: subscribing to a network repository function (NRF) to receive notifications of changes to the configuration file of the first AMF, wherein the step of determining whether the first AMF is unable to provide services for the broadcast session includes: receiving a notification of changes to the configuration file of the first AMF from the NRF, the notification indicating that the first AMF is unable to provide services for the broadcast session. In some embodiments, the broadcast session is an MBS session. In some embodiments, at least one of the following is true: the eleventh message is a Namf_MBSBroadcast_ContextUpdate request message; and the twelfth message is a Namf_MBSBroadcast_ContextUpdate response message.
[0028] According to an eleventh aspect of the present disclosure, a second network node is provided. The second network node comprises: a processor; a memory storing instructions, which, when executed by the processor, causes the processor to perform any one of the methods in the tenth aspect. In some embodiments, the MB-SMF is hosted at the second network node.
[0029] According to the twelfth aspect of the present disclosure, a second network node is provided. The second network node includes: a first determination module configured to determine whether the first AMF is unable to provide services for the broadcast session; a second determination module configured to determine that the second AMF takes over the broadcast session from the first AMF; and a sending module configured to send an eleventh message to the second AMF, the eleventh message including an indication that the eleventh message will provide information associated with the broadcast session, which is used for subsequent recovery of the broadcast session only when one or more RAN nodes are restarted. In some embodiments, the second network node includes one or more additional modules configured to perform any one of the methods in the tenth aspect.
[0030] According to a thirteenth aspect of the present disclosure, a computer program includes instructions, which, when executed by at least one processor, causes the at least one processor to perform the method of any one of the first aspect, the fourth aspect, the seventh aspect and the tenth aspect.
[0031] According to a fourteenth aspect of the present disclosure, a carrier comprises the computer program of the thirteenth aspect. In some embodiments, the carrier is one of an electric signal, an optical signal, a radio signal or a computer-readable storage medium.
[0032] According to a fifteenth aspect of the present disclosure, a telecommunication system for retrying multicast session signaling for a multicast session or broadcast session signaling for a broadcast session is provided. The telecommunication system comprises: a first network node according to any one of the second and third aspects; and a second network node according to any one of the fifth and sixth aspects.
[0033] According to a sixteenth aspect of the present disclosure, a telecommunication system for resuming a broadcast session is provided, wherein the telecommunication system comprises: a first network node according to any one of the eighth and ninth aspects; and a second network node according to any one of the eleventh and twelfth aspects.
[0034] Through some embodiments of the present disclosure, failure of MBS related procedures can be avoided when there is only a local link interruption between one or more NG-RANs and AMFs. Through some embodiments of the present disclosure, the broadcast MBS session information does not need to be stored in the shared memory of the AMF set, so that the AMFs in the same AMF set can directly retrieve the broadcast MBS session information from the MB-SMF, because once the MB-SMF detects that the original AMF has failed, it will provide complete broadcast MBS session information. BRIEF DESCRIPTION OF THE DRAWINGS
[0035] According to the following description in conjunction with the accompanying drawings and the appended claims, the above-mentioned features and other features of the present disclosure will become more fully apparent. It should be understood that these drawings only depict several embodiments according to the present disclosure and therefore should not be considered to limit the scope of the present disclosure, which will be described with additional specificity and detail through the use of the drawings.
[0036] Figure 1 is a diagram illustrating an exemplary transmission method of an MBS session to which resumption of a multicast session or a broadcast session according to some embodiments of the present disclosure is applicable.
[0037] Figure 2 is a diagram illustrating an exemplary telecommunications network in which resumption of a multicast session or a broadcast session according to some embodiments of the present disclosure may be applied.
[0038] Figure 3 is a diagram illustrating another exemplary telecommunication network in which resumption of a multicast session or a broadcast session according to some embodiments of the present disclosure may be applied.
[0039] Figure 4 is a diagram illustrating an exemplary user plane data transmission to which resumption of a multicast session or a broadcast session may be applied according to some embodiments of the present disclosure.
[0040] Figure 5 is a diagram showing an exemplary process for resuming a broadcast session via an alternative AMF according to an embodiment of the present disclosure.
[0041] Fig. 6A and Figure 6B is a diagram illustrating an exemplary process for recovering from a failure associated with a multicast session or a broadcast session via an alternative AMF according to an embodiment of the present disclosure.
[0042] Fig. 7A and Figure 7B is a diagram illustrating another exemplary process for recovering from a failure associated with a multicast session or a broadcast session via an alternative AMF according to another embodiment of the present disclosure.
[0043] Figure 8 is a diagram illustrating another exemplary process for recovering from a failure associated with a broadcast session via an alternative AMF according to another embodiment of the present disclosure.
[0044] Fig. 9 is a flowchart of an exemplary method at an AMF for facilitating an MB-SMF attempt at multicast session signaling for a multicast session or broadcast session signaling for a broadcast session according to an embodiment of the present disclosure.
[0045] Fig.10 is a flowchart of an exemplary method at an MB-SMF for attempting multicast session signaling for a multicast session or broadcast session signaling for a broadcast session according to an embodiment of the present disclosure.
[0046] Fig.11 is a flowchart of an exemplary method at an AMF for facilitating MB-SMF resumption of a broadcast session according to an embodiment of the present disclosure.
[0047] Fig.12 is a flowchart of an exemplary method for resuming a broadcast session at an MB-SMF according to an embodiment of the present disclosure.
[0048] Fig.13 An embodiment of an arrangement which can be used in a network node according to an embodiment of the present disclosure is schematically illustrated.
[0049] Fig.14 is a block diagram of an exemplary first network node according to an embodiment of the present disclosure.
[0050] Fig.15 is a block diagram of an exemplary second network node according to an embodiment of the present disclosure.
[0051] Fig.16 is a block diagram of another exemplary first network node according to another embodiment of the present disclosure.
[0052] Fig.17 is a block diagram of another exemplary second network node according to another embodiment of the present disclosure.
[0053] Figures 18 to 21 is a diagram illustrating an exemplary process applicable to the resumption of a multicast session or a broadcast session according to some embodiments of the present disclosure. DETAILED DESCRIPTION
[0054] The present disclosure is described below with reference to the embodiments shown in the accompanying drawings. However, it should be understood that these descriptions are provided only for illustrative purposes and are not intended to limit the present disclosure. In addition, the description of known structures and technologies is omitted below to avoid unnecessarily obscuring the concept of the present disclosure.
[0055] Those skilled in the art will understand that the term "exemplary" is used herein to mean "illustrative" or "used as an example," and is not intended to imply that a particular embodiment is superior to another embodiment or that a particular feature is essential. Similarly, unless the context clearly indicates otherwise, the terms "first" and "second" and similar terms are used only to distinguish one specific instance of an item or feature from another specific instance, without indicating a specific order or arrangement. In addition, the term "step" as used herein is intended to be synonymous with "operation" or "action." Unless the context or details of the operations being described clearly indicate otherwise, any description of a sequence of steps herein does not mean that the operations must be performed in a specific order, or even that the operations are performed in any order.
[0056] Unless expressly limited herein or understood from the context, conditional language used herein (e.g., "can," "should," "may," "for example," etc.) is generally intended to convey that some embodiments include some features, elements, and / or steps while other embodiments do not include the features, elements, and / or states. Therefore, such conditional language is generally not intended to imply that features, elements, and / or steps are necessary for one or more embodiments in any case, or to imply that one or more embodiments must include logic circuitry to determine whether to include these features, elements, and / or states in any particular embodiment with or without author input or authorization, or to perform the features, elements, and / or states in any particular embodiment. In addition, the term "or" is used as an inclusive meaning (and not an exclusive meaning), so that when used, for example, to connect a list of elements, the term "or" represents one, some, or all of the elements in the list. In addition, in addition to having its ordinary meaning, the term "each" used herein may mean any subset of the set of elements to which the term "each" is applied.
[0057] The term "based on" should be interpreted as "based at least in part on". The terms "one embodiment" and "embodiment" should be interpreted as "at least one embodiment". The term "another embodiment" should be interpreted as "at least one other embodiment". The following may include other definitions, both explicit and implicit. In addition, unless otherwise explicitly limited herein, statements such as phrases "at least one of X, Y, and Z" should be understood in conjunction with the context as generally used to express that an item, term, etc. can be X, Y, or Z, or a combination thereof.
[0058] The terms used herein are only used for the purpose of describing specific embodiments and are not intended to limit the exemplary embodiments. Unless the context clearly indicates otherwise, the singular forms "one", "an" and "said" as used herein are intended to also include plural forms. It will also be understood that when used in this article, the words "comprising", "having", "including" indicate the existence of stated features, elements and / or components, etc., but do not exclude the existence or addition of one or more other features, elements, components and / or combinations thereof. It will also be understood that: unless clearly indicated to the contrary, when used in this article, the terms "connect", "connected to", "connected to", etc. only mean that there is an electrical connection or communication connection between two elements and they can be directly or indirectly connected.
[0059] Of course, without departing from the scope and essential features of the present disclosure, the present disclosure may be implemented in other specific ways different from those described herein. One or more specific processes discussed below may be performed in any electronic device including one or more appropriately configured processing circuits, which in some embodiments may be embodied 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 programmed with appropriate software and / or firmware to implement one or more of the above operations and variations thereof. In some embodiments, these processing circuits may include custom hardware that performs one or more of the above functions. The proposed embodiments are therefore to be considered illustrative rather than restrictive in all respects.
[0060] Although several embodiments of the present disclosure will be shown in the drawings and described in the following detailed description, it will be understood that the disclosure is not limited to the disclosed embodiments, but is also capable of various rearrangements, modifications and substitutions without departing from the present disclosure as will be set forth and defined in the appended claims.
[0061] In addition, please note 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. In fact, as long as it involves the recovery of a multicast session or a broadcast session, the inventive concept of the present disclosure can be applied to any appropriate communication architecture, for example, it can be applied to 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. Therefore, it can be easily understood by those skilled in the art that the terms used herein can also refer to their equivalent terms in any other infrastructure. For example, the term "user equipment" or "UE" used herein can 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. For another example, the term "network node" used in this document may refer to or include 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 (NF) or any other equivalent.
[0062] In addition, the following 3GPP documents are incorporated herein by reference in their entirety:
[0063] -3GPP TS 23.247 V17.2.0 (2022-03), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture Enhancements for 5G Multicast-Broadcast Services; Stage 2 (Release 17); and
[0064] - 3GPP TS 23.527 V17.3.1 (2022-03), 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Recovery Procedures (Release 17).
[0065] Defined in TS 23.247 v17.2.0:
[0066] 3.1 Terminology
[0067] …
[0068] Broadcast MBS Session: An MBS session used to deliver a broadcast communication service. A broadcast MBS session is characterized by the content to be sent and the geographical area in which the broadcast MBS session is distributed.
[0069] 3GPP TS 23.247 v17.2.0 specifies the use of NR to enhance the architecture of the 5G system to support multicast and broadcast communication services. Specifically, 3GPP TS 23.247 v17.2.0 specifies the following contents.
[0070] Overview of Multicast and Broadcast Communications
[0071] Multicast and Broadcast Service (MBS) is a point-to-multipoint service in which data is sent from a single source entity to multiple recipients, either to all users in a broadcast service area, or to users in a multicast group as defined in TS 22.146 v17.0.0. The corresponding types of MBS sessions are:
[0072] - Broadcasting sessions;
[0073] -Multicast sessions.
[0074] The MBS architecture defined in clause 5 of 3GPP TS 23.247 v17.2.0 follows the 5G system architecture principles as defined in 3GPP TS 23.501 v17.4.0, enabling the distribution of MBS data from the 5G system (5GS) ingress to the NG-RAN node and then to the UE. The MBS architecture provides:
[0075] - Efficient utilization of RAN and Core Network (CN) resources, with a focus on radio interface efficiency;
[0076] -Efficient transmission of various multicast and broadcast services.
[0077] This release does not support multicast-broadcast services for roaming.
[0078] The interaction between multicast-broadcast services and the support of deployment topologies with specific SMF service areas is not specified in this release.
[0079] MBS also provides functions such as local MBS service, authorization for multicast MBS, and QoS differentiation. For more details, refer to clause 6 of 3GPP TS 23.247 v17.2.0.
[0080] MBS services are delivered from a single data source (eg, an application service provider) to multiple UEs. Depending on many factors, there are several delivery methods that can be used to deliver MBS services in 5GS.
[0081] Note 1: For clarity, the delivery methods are not referred to as unicast / multicast / broadcast, but as described below. The term "unicast delivery" refers to a mechanism by which application data and signaling between the UE and the application server are delivered using PDU sessions within the 3GPP network and using separate UE and application server addresses (e.g., IP addresses) between the 3GPP network and the application server. It is not equivalent to the 5G Core (5GC) separate MBS service delivery method defined in clause 4 of 3GPP TS 23.247 v17.2.0.
[0082] There are two possible delivery methods between 5GC and NG-RAN to send MBS data:
[0083] -5GC separate MBS service delivery method: This method is only applicable to multicast MBS sessions. 5GC receives a single copy of the MBS data packet and transmits a separate copy of these MBS data packets to each UE via each UE PDU session, so for each such UE, a PDU session needs to be associated with the multicast session.
[0084] -5GC shared MBS service delivery method: This method is applicable to both broadcast sessions and multicast MBS sessions. The 5GC receives a single copy of the MBS data packets and transmits a single copy of these MBS packets to the NG-RAN node, which then transmits these packets to one or more UEs.
[0085] A 5GC shared MBS service delivery method is required in all MBS deployments. When there is an NG-RAN deployment with non-homogeneous support for MBS, a 5GC separate MBS service delivery method is required to achieve mobility.
[0086] For a multicast session, a single copy of an MBS data packet received by the CN may be transmitted via a 5GC individual MBS service delivery method for certain UEs and via a 5GC shared MBS service delivery method for other UEs.
[0087] Between NG-RAN and UE, two delivery methods are available for MBS data packet transmission over the radio interface:
[0088] - Point-to-Point (PTP) delivery method: NG-RAN delivers individual copies of MBS data packets to each UE over the radio interface.
[0089] - Point-to-multipoint (PTM) delivery method: NG-RAN delivers a single copy of MBS data packets to multiple UEs over the radio interface.
[0090] NG-RAN may use a combination of PTP / PTM to deliver MBS data packets to the UE.
[0091] Note 2: PTP and PTM transport methods are defined in the RAN Working Group (WG).
[0092] like Figure 1 As shown, the 5GC shared MBS service transmission method (using PTP or PTM transmission) and the 5GC independent MBS service transmission method can be used for multicast MBS sessions at the same time.
[0093] Figure 1 is a diagram showing an exemplary transmission method of an MBS session to which the resumption of a multicast session or a broadcast session according to some embodiments of the present disclosure may be applied. Figure 1 As shown, multiple UEs 100-1, 100-2, 100-3, and 100-4 may join an MBS session via different delivery methods. For example, UE 100-1 and UE 100-2 may be served by shared MBS service delivery via a shared tunnel established between NG-RAN node 105 and 5GC 110. In this case, a single copy of the MBS data packet may be delivered from 5GC 110 to NG-RAN node 105, which then delivers the packets to UE 100-1 and UE 100-2 via PTP or PTM delivery methods. For another example, UE 100-3 and UE 100-4 may be served by separate MBS service delivery via two separate PDU sessions established between one or more RAN nodes 105 and 5GC 110. In this case, separate copies of these MBS data packets may be transmitted from the 5GC 110 to individual UEs 100-3 and 100-4 via a PDU session for each UE.
[0094] For MBS broadcast communications, only the 5GC shared MBS service transmission method using PTM transmission is applicable.
[0095] For MBS multicast communications, if the NG-RAN node supports MBS, the network should use the 5GC shared MBS service delivery method for MBS data transmission.
[0096] Note 3: The exception is that when the UE moves between an NG-RAN node that does not support MBS (using the 5GC separate MBS service delivery method) and an NG-RAN node that supports MBS, the 5GC shared MBS service delivery method and the 5GC separate MBS service delivery method temporarily coexist. For details, refer to clause 6.3 of 3GPP TS 23.247 v17.2.0.
[0097] For MBS multicast communication, switching between 5GC shared MBS service delivery method and 5GC independent MBS service delivery method is supported. UE mobility between RAN nodes that both support MBS and UE mobility between RAN nodes that support MBS and RAN nodes that do not support MBS are supported. For details, see clause 6.3 of 3GPP TS 23.247 v17.2.0.
[0098] For MBS multicast communication, switching between the PTP transmission method and the PTM transmission method for 5GC shared MBS service transmission should be supported. NG-RAN is the decision point for switching between the PTP transmission method and the PTM transmission method.
[0099] Figure 2 is a diagram illustrating an exemplary telecommunications network 20 in which resumption of a multicast session or a broadcast session according to some embodiments of the present disclosure may be applied, and Figure 2 The MBS reference architecture is depicted. A service-based interface is used within the control plane. Support for interworking at reference points xMB and MB2 is described in Annex C of 3GPP TS 23.247 v17.2.0. Although the telecommunications network 20 is a network defined in the context of 5GS, the present disclosure is not limited thereto.
[0100] like Figure 2 As shown, the network 20 may include an NG-RAN 205 and one or more UEs 200, the NG-RAN 205 may be or may include 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 parts of the network 20. In addition, the network 20 may include its core network portion, which includes (but is not limited to) an AMF 225, a session management function (SMF) 230, a user plane function (UPF) 210, a policy control function (PCF) 255, a network exposure function (NEF) 245, an application function / application server (AF / AS) 250, a unified data management (UDM) 265 and / or an NRF 260. In addition to these network functions, the telecommunication network 20 may also include network functions for supporting MBS, including (but not limited to) MB-SMF 235, MB-UPF 215, multicast / broadcast service function (MBSF) 240, and multicast / broadcast service transmission function (MBSTF) 220. Figure 2 As shown, these entities can communicate with each other via service-based interfaces (e.g., Namf, Nsmf, Npcf, etc.) and / or reference points (e.g., N1, N2, N3, N4, N3mb, N19mb, etc.).
[0101] However, the present disclosure is not limited thereto. In some other embodiments, the network 20 may include additional network functions, fewer network functions, or Figure 2 Some variations of the existing network functions shown. For example, in a network with a 4G architecture, the entity that performs these functions (e.g., the Mobility Management Entity (MME)) may be different from Figure 2 As another example, in a network with a hybrid 4G / 5G architecture, some of these entities may be associated with Figure 1 Some entities shown are identical, while others may be different. Figure 2 The functions shown are not essential to the embodiments of the present disclosure. In other words, some of them may be omitted from some embodiments of the present disclosure. Figure 2 Functions shown.
[0102] refer to Figure 2 As mentioned above, the AMF 225 can provide most of the functions provided by the MME in a 4G network. The following is a brief list of some of its functions:
[0103] -Terminates the RAN control plane (CP) interface (N2);
[0104] - Non-Access Stratum (NAS) signaling;
[0105] -NAS encryption and integrity protection;
[0106] - Mobility Management (MM) layer NAS termination;
[0107] - Session Management (SM) layer NAS forwarding;
[0108] - Authenticating the UE 200;
[0109] - Manage security context;
[0110] -Registration management;
[0111] -Connection management;
[0112] - Accessibility management;
[0113] - mobility management; and / or
[0114] - Apply mobility related policies from PCF 255 (e.g., mobility restrictions).
[0115] In addition to the functions defined above, the AMF 225 may also perform at least one of the following functions to support MBS:
[0116] - Signalling with NG-RAN 205 and MB-SMF 235 for MBS session management;
[0117] - Selecting the NG-RAN 205 to notify the UE 200 in the CM Idle state of the multicast session activation;
[0118] -Select NG-RAN 205 for broadcast service distribution.
[0119] In addition, the AMF 225 may be aware of the NG-RAN 5G MBS capabilities.
[0120] The MB-SMF 235 may perform at least one of the following functions to support MBS:
[0121] - General functionality for multicast and broadcast sessions:
[0122] -Support MBS session management (including QoS control);
[0123] -Configure the MB-UPF 215 for multicast and broadcast streaming based on policy rules for multicast and broadcast services from the PCF 255 or local policies;
[0124] - Allocate and de-allocate Temporary Mobility Group Identity (TMGI);
[0125] - Features specific to broadcast sessions:
[0126] -Interact with the RAN 205 (via the AMF 225) to control data transmission using the 5GC shared MBS service delivery method;
[0127] - Features specific to multicast sessions:
[0128] - interact with the SMF 230 to modify the PDU session associated with the MBS session;
[0129] -Interact with the RAN 205 (via the AMF 225 and SMF 230) to establish data transmission resources between the MB-UPF 215 and the RAN nodes for the 5GC shared MBS service delivery method;
[0130] -Use 5GC's separate MBS service delivery method to control multicast data transmission.
[0131] In addition to the functions defined in TS 23.501 v17.4.0, the NG-RAN 205 may also perform at least one of the following functions to support MBS:
[0132] - Manage MBS QoS flows via N2;
[0133] - Transmitting MBS data packets shared by multiple UEs 200 from 5GC over the radio using PTM or PTP;
[0134] -Configuring the UE 200 for MBS QoS flow reception at the access stratum (AS) layer;
[0135] - Control the switching between PTM transmission and PTP transmission for each UE;
[0136] -Support multicast session continuity during Xn handover and N2 handover;
[0137] -Supporting notification of multicast session activation over the radio to UE 200 in CM-IDLE state and CM-CONNECTED with RRC Inactive state.
[0138] In addition to the functions defined in TS 23.501 v17.4.0, the NRF 260 may also perform at least one of the following functions to support 5G MBS:
[0139] -Support new NF types MB-SMF and MBSF and their corresponding NF profiles;
[0140] - Support MB-SMF discovery based on parameters such as Data Network Name (DNN), Single Network Slice Selection Assistance Information (S-NSSAI) and MB Service Area at MBS session creation for both multicast and broadcast MBS sessions; and
[0141] - For a multicast MBS session, MBS Session ID based MB-SMF discovery is supported by the SMF 230 serving the multicast session when a UE joins.
[0142] Note that MBSF 240 is optional and may be co-located with NEF 245 or AF / AS 250, and MBSTF 220 may be an optional network function. In addition, the existing service-based interfaces of Nnrf, Nudm, and Nsmf may be enhanced to support MBS. The existing service-based interfaces of Npcf and Nnef may be enhanced to support MBS. An AF supporting MBS may use Nmbsf or Nnef to interact with MBSF.
[0143] Figure 3 is a diagram illustrating another exemplary telecommunications network 20' in which resumption of a multicast session or a broadcast session according to some embodiments of the present disclosure may be applied, and Figure 3 The 5G system architecture for MBS is depicted using reference point representation. Figure 3 The NF shown is Figure 2 The NFs shown are substantially similar, so a detailed description thereof is omitted for simplicity.
[0144] In some embodiments, the existing reference points of N1, N2, N4, N10, N11, N30 and N33 may be enhanced to support MBS. In addition, regarding these functions, Nmb13, N29mb and Nmb1 may be the same, Nmb5 and Nmb10 may be the same, and Nmb9 and N6mb may be the same.
[0145] According to 3GPP TS 23.247 v17.2.0, unicast or multicast transmission via N3mb between NG-RAN and MB-UPF can be applied:
[0146] - If unicast transmission over N3mb is applied, each NG-RAN allocates tunnel information (including IP address and Tunnel Endpoint Identifier (TEID)), which is provided to the MB-UPF (via AMF, MB-SMF) so that DL MBS data packets can be sent to this tunnel entity.
[0147] - If the application is delivered via N3mb’s multicast, NG-RAN does not provide tunnel information, instead NG-RAN joins the multicast IP address provided by MB-UPF.
[0148] The MB-UPF acts as an MBS session anchor for the MBS session and, if the MBSTF participates in the MBS session, the MBSTF acts as a media anchor for the MBS service.The MB-UPF receives only one copy of the MBS data packet from the AF or MBSTF.
[0149] The user plane between MBSTF and MB-UPF or between MB-UPF and AF can use multicast transmission or unicast tunnel for MBS session (depending on the capabilities of application and control interface). If the transport network does not support multicast transmission, the user plane uses unicast tunnel for MBS session. The user plane between MBSTF and AF can use unicast tunnel, multicast transmission or other means (for example, HTTP download from external content delivery network (CDN)). Unicast is used for MBS session, and after receiving downlink MBS data, MB-UPF forwards downlink MBS data without external IP header and tunnel header information.
[0150] The user plane from MB-UPF to NG-RAN (for 5GC shared MBS service delivery) and the user plane from MB-UPF to UPF (for 5GC individual MBS service delivery) may use multicast transmission via a common General Packet Radio Service (GPRS) Tunneling Protocol-User Plane (GTP-U) tunnel for each MBS session, or use unicast transmission via a separate GTP-U tunnel at NG-RAN or UPF for each MBS session in the following manner:
[0151] -For 5GC shared MBS service delivery (i.e., MB-UPF delivers user plane data to NG-RAN supporting MBS), if the transport network supports IP multicast, the NG-RAN node uses multicast delivery via a common GTP-U tunnel for each MBS session, otherwise unicast delivery via a separate GTP-U tunnel is used for each MBS session at each NG-RAN node.
[0152] -For 5GC standalone MBS service delivery (i.e., MB-UPF delivers user plane data to UPF), if the transport network supports IP multicast and UPF supports receiving multicast data through N19mb, UPF uses multicast transmission via a common GTP-U tunnel for each MBS session, otherwise unicast transmission via a separate GTP-U tunnel is used at each UPF for each MBS session.
[0153] If the user plane uses unicast transmission, the transport layer destination is the IP address of the NG-RAN or UPF, each NG-RAN or UPF allocates tunnels separately, and the MBS session uses multiple GTP-U tunnels. If the user plane uses multicast transmission, both the RAN and UPF nodes use a common GTP-U tunnel. The GTP-U tunnel is identified as the transport layer destination by a common tunnel ID and an IP multicast address, both of which are assigned by the 5GC.
[0154] Figure 4 The above is described in . There may be more than one NG-RAN or UPF involved in the delivery of MBS services. Figure 4 is a diagram illustrating an exemplary user plane data transmission to which resumption of a multicast session or a broadcast session may be applied according to some embodiments of the present disclosure.
[0155] Similar to Figure 1As shown, multiple UEs 200-1, 200-2, 200-3, and 200-4 may join an MBS session through different delivery methods. For example, UE #1 200-1 and UE #2 200-2 may be served by a shared MBS service delivery via a shared tunnel, while UE 200-3 and UE 200-4 may be served by separate MBS service delivery via two separate PDU sessions A and B, respectively.
[0156] The MB-SMF instructs the MB-UPF to receive data packets related to the MBS session.
[0157] For shared transmission (e.g., to UE#1 200-1, UE#2 200-2), if unicast transmission over N3mb is applicable, the MB-SMF instructs the MB-UPF (e.g., MB-UPF 215) to replicate the received MBS data packets and forward them to multiple RAN nodes via separate GTP tunnels. For shared transmission, if multicast transmission over N3mb is applicable, the MB-SMF instructs the MB-UPF to replicate the received MBS data and forward the data via a single GTP tunnel.
[0158] For individual transmission (eg, to UE#3 200-3, UE#4 200-4), MBS data received by the MB-UPF is copied to the UPF (eg, UPF 210) that performs the individual transmission as follows:
[0159] -MB-SMF configures the MB-UPF to receive data packets related to the MBS session, replicate these data packets and forward them to multiple UPFs via multiple GTP tunnels (if the application is transmitted via unicast of N19mb), or forward them to multiple UPFs via a single GTP tunnel (if the application is transmitted via multicast of N19mb).
[0160] -SMF instructs UPF: receive data packets related to the multicast session from MB-UPF via N19mb, copy these data packets, and forward them in multiple PDU sessions.
[0161] For MB-SMF and MB-UPF, data packet detection, duplication and forwarding of MBS sessions are implemented by using one Packet Detection Rule (PDR) per MBS session, which detects incoming MBS data packets and points to a Forwarding Action Rule (FAR) that describes forwarding the data to multiple destinations (UPF or RAN nodes):
[0162] - A Packet Forwarding Control Protocol (PFCP) session is created when an MBS session is started, regardless of whether the transmission over N3mb and N19mb is multicast or unicast.
[0163] -For multicast transmissions over N3mb and N19mb, the destination in the FAR contains the MB-UPF IP multicast distribution information.
[0164] - For unicast transmission over N3mb and N19mb, the FAR in the PFCP session can contain multiple destinations represented by the NG-RAN N3mb tunnel information and UPF N19mb tunnel information (if applicable).
[0165] For SMF and UPF (for 5GC transmission only), the packet detection, replication and forwarding of the MBS session are implemented through the PDR and FAR of the PDU session, in which the UE has joined the MBS session:
[0166] -SMF instructs UPF to associate the PFCP session of the PDU session with the MBS session.
[0167] - Use new PDR with source interface "core" to detect MBS data from N19mb.
[0168] NOTE: This PDR also contains the MBS Session ID to enable single detection of incoming MBS data for multiple PDU sessions at the UPF.
[0169] -For unicast transmission over N19mb, SMF requests UPF to allocate N19mb tunnel information (if not allocated).
[0170] - For multicast transmission over N19mb, the SMF includes the underlying source specific multicast address information and the Common TEID (C-TEID) to the UPF.
[0171] - The action of FAR is set to "discard" if the SMF wants to maintain MBS data reception over N19mb but suspend data delivery of the PDU session to the UE (e.g. when the UE is switching from 5GC individual delivery to 5GC shared delivery due to the UE moving from NG-RAN without MBS support to NG-RAN with MBS support). Otherwise, the SMF shall remove the related PDR and FAR.
[0172] For details on user plane processing, see 3GPP TS 29.244, v17.4.0.
[0173] 3GPP TS 23.527 v17.3.1 specifies the recovery process in 5G systems. Next, NF service producer instance reselection will be described.
[0174] Overview
[0175] A NF instance of a NF Service Producer may expose several service instances of the same NF service (e.g., a UDM instance may expose several service instances of the “Nudm_SubscriberDataManagement” service).
[0176] Via the NRF Nnrf_NFDiscovery service, NF Service Consumer can discover all available NF Service Instances for a given NF Service and select one of them, while Service Communication Agent (SCP) should be able to discover all available NF Service Instances for a given NF Service and select one of them.
[0177] When (routing) binding indication is available, NF service instance reselection is performed
[0178] When the binding procedure specified in clause 6.12 of 3GPP TS 29.500 v17.6.0 is used, the binding indication and the route binding indication include a binding level and one or more binding entity IDs representing all NF service instances that can provide services for service requests targeting the resource, i.e., NF service instances that share the same resource context.
[0179] NF service instance selection and reselection shall be supported when binding indication or route binding indication is available for target resources as described in clause 6.12 of 3GPP TS 29.500, v17.6.0.
[0180] When the (routing) binding indication is unavailable, NF service instance reselection is performed
[0181] If the previously selected NF service instance becomes unavailable, the NF service consumer can (and the SCP should be able to) select a different instance of the same NF service among:
[0182] - the same NF instance, if the NF instance indicates in its NF configuration file that it supports persisting its resources in a shared storage device internal to that NF instance, and if the new NF service instance provides the same major service version; or
[0183] - The same NF Set or NF Service Set, if a NF (Service) instance indicates in its NF Profile that it belongs to a NF Set or NF Service Set.
[0184] If yes, then the NF Service Consumer can (and the SCP should be able to) invoke the service operation in the newly selected NF Service Instance by replacing the addressing parameters with those of the new service instance, and the new NF Service Instance in the NF Service Producer should produce the same result as if the service request was successfully delivered to the previous NF Service Instance.
[0185] Note 1: In some scenarios, the newly selected NF Service Producer may not produce exactly the same results as the previous NF Service Producer would have produced for a service request, for example, when the previous NF Service Producer fails before updating the changes to the resource context to the Unstructured Data Storage Function (UDSF).
[0186] For indirect communication, if the NF Service Consumer delegates the target NF Service Instance reselection to the SCP (when the target NF Service Instance is unreachable), the NF Service Consumer shall include at least one of the 3gpp-Sbi-Discovery-target-nf-instance-id, 3gpp-Sbi-Discovery-target-nf-set-id, 3gpp-Sbi-Discovery-target-nf-service-set-id, 3gpp-Sbi-Discovery-amf-region-id and 3gpp-Sbi-Discovery-amf-set-id headers and shall also include at least the following information in its request to the SCP:
[0187] - Target NF type, service name, and requested S-NSSAI in the corresponding "3gpp-Sbi-Discovery-*" request header (see clause 6.10.3.2 of 3GPP TS 29.500, v17.6.0).
[0188] NOTE 2: This is to allow the SCP to discover and reselect the target NF service instance from the target NF instance or target NF (service) set for the corresponding service request and supporting the requested S-NSSAI, e.g. when the NF service producer supports different NF service instances serving different network slices. Similarly, other "3gpp-Sbi-Discovery-*" request headers (e.g., target-plmn-list) may also be included for the same purpose.
[0189] NOTE 3: Including 3gpp-Sbi-Discovery-target-nf-instance-id in the HTTP request enables the SCP to discover the profile of the target NF instance and possibly reselect a different target NF service instance from the same NF instance or from a different NF instance in the same set.
[0190] If this is done, the SCP shall perform the NF Service Discovery procedure using the information provided by the NF Service Consumer and reselect the NF (Service) Producer instance as specified in the previous bullet point (if possible and if the target NF Service instance indicated in the "3gpp-Sbi-Target-apiRoot" header or target URI is not reachable).
[0191] Note 4: This reselection mechanism is only applicable to request / response service semantics, but not to notification / callback requests.
[0192] If a NF instance does not indicate in its NF Configuration File that it supports the capability to persist its resources in shared storage between service instances of the same NF service within the NF instance, and if it does not indicate in its NF Configuration File that it belongs to a NF Set or NF Service Set, the NF Service Consumer or SCP may still reselect any of the exposed service instances, but it should not assume that the resources created in the previous service instance are still valid.
[0193] In addition, 3GPP Core and Terminal Working Group 4 (CT4) has agreed on the following Change Request (CR) to include two alternative solutions for NG-RAN restart, and for details, please refer to "3GPP TSG-CT WG4 Meeting#109-e, E-Meeting, 06th – 12th April 2022, C4-222349,'Restoration of aBroadcast MBS session upon NG-RAN failure with or without restart'".
[0194] However, existing mechanisms have several problems to be solved.
[0195] Question 1:
[0196] When performing the Broadcast MBS Session Start / Release / Update procedures for a Broadcast MBS session as specified in clauses 7.3.1, 7.3.2 and 7.3.3, one or several NG-RANs that are part of the MBS service area may be unreachable, i.e. broadcast services will not be available in the areas covered by these NG-RANs.
[0197] There is no mechanism enabling the AMF to report such failure (i.e., one or more NG-RANs are unreachable) to the MB-SMF, so it is not even possible to take any remedial action to resolve it.
[0198] Question 2:
[0199] As stated in the agreed CR C4-222349, for broadcast MBS session resumption by AMF, the AMF handling the broadcast MBS session is responsible for resuming the MBS session in the restarted NG-RAN, which AMF shall store the last N2 MBS SM container received from the MB-SMF during establishment of the broadcast MBS session or during broadcast MBS session update (i.e., MBS Session Information Request Transfer IE defined in 3GPP TS 38.413, v17.0.0).
[0200] When the AMF that is handling the establishment of a broadcast MBS session or the last update of a broadcast MBS session has failed before the NG-RAN failure, it is unclear which AMF belonging to the same AMF set (as the AMF handling the broadcast MBS session) will be responsible for resuming the broadcast MBS session.
[0201] Therefore, some embodiments of the present disclosure propose several mechanisms to handle possible failure scenarios during the initiation / update / release of a multicast or broadcast MBS session in 5GS, as briefly described below.
[0202] When performing the Broadcast MBS Session Start / Release / Update procedures for a Broadcast MBS Session as specified in clauses 7.3.1, 7.3.2 and 7.3.3 in 3GPP TS 23.247, 17.2.0, one or several NG-RANs that are part of the MBS service area may not be reachable for the AMF, i.e., the broadcast service will not be started, released or updated in the areas covered by these NG-RANs.
[0203] In some embodiments, the AMF that is receiving the MBS Broadcast Context Create / Update / Release Request message (e.g., Namf_MBSBroadcast_ContextCreate / Namf_MBSBroadcast_ContextUpdate / Namf_MBSBroadcast_ContextRelease request) from the MB-SMF may report such failure event to the MB-SMF together with the NG-RAN IDs of those NG-RANs (that could not be contacted). The MB-SMF may retransmit the same request (or the same request with potential subsequent updates, depending on whether there were updates during the recovery procedure), i.e., the MBS Broadcast Context Create / Update / Release Request message, to those NG-RANs identified by the NG-RAN IDs via alternative AMFs belonging to the same AMF set as the first AMF to circumvent the potential local link disruption only between the first AMF and the NG-RAN. The MB-SMF may report such failure to Operation, Administration and Maintenance (OAM).
[0204] Please note that the above mechanism can also be used in the multicast MBS session activation and / or deactivation and / or update procedures specified in clauses 7.2.5 and / or 7.2.6, i.e. when the AMF receives a Namf_MBSCommunication_N2MessageTransfer request containing a NGAP IE multicast session activation request transmission / multicast session deactivation request transmission / multicast session update request transmission, but the NG-RAN cannot be contacted, the AMF may report the (uncontactable) NG-RAN ID to the MB-SMF so that the MB-SMF may try an alternative AMF.
[0205] In some embodiments, once MB-SMF detects that AMF1 has failed, MB-SMF may reselect an alternative AMF (e.g., AMF2) that belongs to the same AMF set as AMF1, so that AMF2 becomes the serving AMF for the broadcast MBS session, and then AMF2 is responsible for AMF-based recovery to store the N2 container for MBS session information to be used for potential NG-RAN restart.
[0206] Some embodiments of the present disclosure propose two mechanisms for different failure scenarios during starting / updating / releasing / activating / deactivating a multicast or broadcast MBS session.
[0207] In some embodiments, the AMF may report the NG-RAN ID that could not be contacted to the MB-SMF so that the MB-SMF may at least attempt to deliver those MBS session signaling messages to the failed NG-RAN via an alternative AMF in order to rule out potential failures only between the first AMF and the NG-RAN (this is a benefit of deploying a set of AMFs in the network).
[0208] In some embodiments, when MB-SMF detects that AMF1 has failed, MB-SMF may reselect an alternative AMF (e.g., AMF2) that belongs to the same AMF set as AMF1 by sending an MBS session context update request containing complete MBS session information and an indication to the NG-RAN that the alternative AMF should not further populate the MBS session information, so that AMF2 becomes the serving AMF for the broadcast MBS session and makes the MBS session information available for AMF-based recovery for potential NG-RAN restart.
[0209] Without these methods of some embodiments, the broadcast MBS session may fail to be established / updated / released in one or more NG-RANs due to a local link outage between the NG-RAN and the AMF, which is unreasonable when the AMF set is deployed in the network. In other words, by these methods, such failures can be avoided, for example, when there is only a local link outage between the NG-RAN and the AMF.
[0210] In order to support the AMF-based recovery procedure for NG-RAN restart, it is important to have a solution for determining which AMF should be responsible for storing the MBS session information (which is included in the N2 container). The method of some embodiments is such that the broadcast MBS session information does not need to be stored in a shared memory so that AMFs in the same AMF set can retrieve it; because once the MB-SMF detects that the original AMF has failed, it will provide the complete broadcast MBS session information.
[0211] In some embodiments, when the "AMF Set" feature is deployed in the network, the NG-RAN may be connected to an AMF Set. In this case, if the alternative AMF belongs to the same AMF Set as the old AMF, the NG-RAN may be able to accept subsequent broadcast session modification or release request messages sent via an alternative AMF other than the AMF that sent the broadcast session setup request.
[0212] In some embodiments, when the AMF is unable to contact one or more NG-RANs upon receiving a Namf_MBSBroadcast_ContextCreate or Update or Release request message from the MB-SMF, the AMF may report such NG-RAN failure event to the MB-SMF together with the NG-RAN IDs of those (uncontactable) NG-RANs. The MB-SMF may retry the (same) request to those NG-RANs identified by the NG-RAN IDs via alternative AMFs (belonging to the same AMF set) to circumvent potential local link disruption only between the old AMF and the NG-RAN.
[0213] Fig. 6A and Figure 6B FIG. 1 is a diagram illustrating an exemplary process for recovering from a failure associated with a multicast session or a broadcast session via an alternative AMF according to an embodiment of the present disclosure. Fig. 6A and Figure 6B Only a method in which a broadcast MBS session (or MBS session start for broadcast in subclause 7.3.1 of 3GPP TS 23.247, V17.2.0) is to be started is shown, but the present disclosure is not limited thereto. As described above, the method may also be applicable to other procedures, such as MBS session release for broadcast in subclause 7.3.2 of 3GPP TS 23.247, V17.2.0, MBS session update for broadcast in subclause 7.3.3 of 3GPP TS 23.247, V17.2.0, MBS session activation in subclause 7.2.5.2 of 3GPP TS 23.247, V17.2.0, MBS session deactivation in subclause 7.2.5.3 of 3GPP TS 23.247, V17.2.0, MBS session update in subclause 7.2.6 of 3GPP TS 23.247, V17.2.0, etc.
[0214] like Fig. 6AAs shown, at step S605, a request may be made to establish a broadcast MBS session in the network. In some embodiments, to establish a broadcast MBS session, TMGI allocation (or, in general, MBS session ID allocation) and MBS session creation as specified in clauses 7.1.1.2 or 7.1.1.3 of 3GPP TS 23.247, V17.2.0 may be performed in the same manner as step 1 in Figure 7.3.1 of 3GPP TS 23.247, V17.2.0. The MBS service type may be a broadcast service. The MBS frequency selection area (FSA) ID of the broadcast MBS session may be transmitted to the UE 200 in a service announcement. The UE 200 may compare those MBS FSA IDs with the MBS FSA IDs in the system information block (SIB) for frequency selection.
[0215] At step S610, the MB-SMF 235 may send a Namf_MBSBroadcast_ContextCreate request message to the AMF 225-1 selected to handle the MBS session. In some embodiments, the request may include at least one of the allocated MBS session ID, the MBS service area, and the N2 container "MBS session information request transmission" to be delivered to the NG-RAN 205. In addition, the MB-SMF 235 may include the maximum response time in the request. In addition, please note that for other messages sent in other procedures (e.g., release / update / activation / deactivation), they may include (partially) the same and / or (partially) different IEs.
[0216] At step S615, the AMF 225-1 may use the MBS service area to retrieve a list of NG-RANs to contact (e.g., NG-RAN1 205-1 and NG-RAN2 205-2), and send an N2 Broadcast Session Setup Request message to each NG-RAN to contact (e.g., NG-RAN1 205-1 and NG-RAN2 205-2). The message may contain the N2 SM information in the received Namf_MBSBroadcast_ContextCreate request, to all NG-RANs 205 supporting MBS in the MBS service area. The AMF 225-1 may include the MBS service area in the request.
[0217] like Fig. 6A As shown, some NG-RAN 205 (e.g., NG-RAN1 205-1) did not respond to the request, as shown by "X", for example because NG-RAN1 205-1 did not receive the request or the AMF 225-1 did not receive the response sent by NG-RAN1 205-1. Fig. 6A As shown, at step S620, some NG-RAN 205 (e.g., NG-RAN2 205-2) may respond to the request. For example, NG-RAN 205-2 may report the successful establishment of MBS session resources (which may include multiple MBS QoS flows) by sending an N2 broadcast session setup response message to AMF 225-1. In addition, when point-to-point transmission is applied between MB-UPF215 and NG-RAN 205-2, N3mb DL tunnel information may be provided in the response. For more details, refer to TS 38.413, v17.0.0. For another example, NG-RAN2 205-2 may report the failure of MBS session resource establishment by sending an N2 broadcast session setup failure message to AMF 225-1.
[0218] At step S625, the AMF 225-1 may transmit a Namf_MBSBroadcast_ContextCreate response message to the MB-SMF 235. When the AMF 225-1 receives the first successful response from the NG-RAN, it may respond with success. If all NG-RANs are unreachable, the AMF 225-1 may respond with failure to the Namf_MBSBroadcast_ContextCreate request, and in this case, the MB-SMF 235 may select an alternative AMF in the same AMF set and perform step S650 without including a list of NG-RAN IDs. If all NG-RANs report failure or all reachable NG-RANs report failure, the AMF 225-1 may also respond with failure. The MB-SMF 235 may store the AMF that responded successfully as a downstream node in the MBS session context. If the AMF 225-1 receives NG-RAN responses from all involved NG-RANs 205, the AMF may include an indication that the operation is completed in all NG-RANs 205.
[0219] At step S630, if unicast transmission is used for the N3mb interface, the MB-SMF 235 may trigger a PFCP session modification request message to the MB-UPF 215 as needed to update the DL fully qualified TEID (F-TEID) of the NG-RAN for the MBS session. In other words, if N3mb point-to-point transmission is to be used (i.e., N3mb DL tunnel information is present in the Namf_MBSBroadcast_ContextCreate response message from the AMF 225-1), the MB-SMF 235 may send an N4mb session modification request to the MB-UPF 215 to allocate an N3mb point-to-point transmission tunnel for the duplicate MBS flow of the MBS session. Otherwise, step S630 may be skipped.
[0220] In addition, for those NG-RANs (e.g., NG-RAN1 205-1) that AMF1 225-1 cannot contact, at step S635, AMF1 225-1 may send one or more Namf_MBSBroadcast_ContextStatusNotify request messages to MB-SMF 235 to notify MB-SMF 235 that AMF 225-1 cannot contact the NG-RAN for the MBS session. In some embodiments, the request message may include at least one of the following items: the MBS session ID, the ID of the NG-RAN that AMF225-1 cannot contact (e.g., the ID of NG-RAN1 205-1), and an indication indicating the failure. In some other embodiments, the indication may indicate other reasons for failure besides the contact failure. In response to the notification request message, at step S640, MB-SMF 235 may respond with a Namf_MBSBroadcast_ContextStatusNotify response message that acknowledges the safe receipt of the request message.
[0221] In addition, when receiving the notification message at step S635, the MB-SMF 235 may select an alternative AMF (e.g., AMF2 225-2) that belongs to the same AMF set as the AMF1 225-1 to avoid the local link failure between the AMF1 225-1 and the NG-RAN1 205-1 at step S645. For example, the MB-SMF 235 may select the AMF 225-2 that belongs to the same AMF set using the binding indication provided by the old AMF 225-1 or using the NF profile of the old AMF 225-1.
[0222] refer to Figure 6B, at step S650, the MB-SMF 235 may retransmit the same request, i.e., the Namf_MBSBroadcast_ContextCreate request (or Namf_MBSBroadcast_ContextUpdate request / Namf_MBSBroadcast_ContextRelease request) message (or the same request with potential subsequent updates, depending on whether there is an update during the recovery process (e.g., during the time period between step S615 and step S650)) to the NG-RAN1 205-1 identified by the NG-RAN ID in the notification message via the alternative AMF2 225-2 to exclude the potential local link disruption only between the first AMF1 225-1 and the NG-RAN1 205-1. For example, the MB-SMF 235 may send a Namf_MBSBroadcast_ContextCreate request including the MBS session ID, the corresponding MBS service area, the MBS session information request transmission, and a list of NG-RAN IDs to be contacted.
[0223] Upon receiving the request message including a specific NG-RAN ID (e.g., the ID of NG-RAN1 205-1), even if the request message also indicates a service area, AMF2 225-2 may know that only NG-RAN1 205-1 should be contacted for the intended operation (e.g., MBS session creation / release / update / activation / deactivation), and therefore at step S655, AMF2 225-2 may send an N2 broadcast session setup request to NG-RAN1 205-1 (or each NG-RAN identified by the NG-RAN ID). The message itself may be substantially similar to the message sent at step S615, and thus its description is omitted for simplicity.
[0224] Furthermore, steps S660 , S665 , and S670 are substantially similar to steps S620 , S625 , and S630 , respectively, and thus descriptions thereof are omitted for simplicity.
[0225] pass Fig. 6A and Figure 6B The method shown can avoid the failure of MBS related procedures when there is only a local link interruption between NG-RAN1 205-1 and AMF1 225-1.
[0226] Fig. 7A and Figure 7B is a diagram illustrating another exemplary process for recovering from a failure associated with a multicast session or a broadcast session via an alternative AMF according to another embodiment of the present disclosure. Specifically, Fig. 7A and Figure 7BAn exemplary process for recovering from failures during delivery of a Namf_MBSBroadcast_ContextUpdate or Release request message is shown.
[0227] At step S705 , a broadcast MBS session has been established in the network.
[0228] At step S710, the MB-SMF 235 may send a Namf_MBSBroadcast_ContextUpdate request that may include at least one of an MBS session ID, a corresponding MBS service area, and an MBS session information request transmission to the AMF 225-1 that is processing the MBS session, or send a Namf_MBSBroadcast_ContextRelease request message with an MBS session reference ID.
[0229] At step S715a / S715b / S715c, upon receiving the Namf_MBSBroadcast_ContextUpdate request from the MB-SMF 235, the AMF 225-1 may use the MBS service area to retrieve a list of NG-RANs to contact and do at least one of the following:
[0230] - Sending an N2 Broadcast Session Modification Request to each NG-RAN that is covering the old MBS service area (e.g., to NG-RAN4205-4 at step S715b);
[0231] - Sending an N2 broadcast session setup request to each NG-RAN that is to cover the extended MBS service area (e.g., to NG-RAN 1205-1 at step S715a);
[0232] - Sending an N2 broadcast session release request to each NG-RAN that is covering the shrinking MBS service area (eg, to NG-RAN3 205-3 at step S715b).
[0233] In addition, upon receiving the Namf_MBSBroadcast_ContextRelease request message, the AMF 225-1 may send an N2 broadcast session release request to all NG-RANs used for the MBS session.
[0234] In some embodiments, the AMF 225-1 may detect that some NG-RANs (e.g., NG-RAN1 205-1, NG-RAN3 205-3, and NG-RAN4 205-4) are unreachable for a setup request, a modification request, and / or a release request, such as Fig. 7AIn other words, if the AMF 225-1 fails to contact some NG-RAN, it needs to report an NgranFailureEvent as defined in Annex C to the MB-SMF 235, which will be done at step S730.
[0235] Additionally, some NG-RANs (eg, NG-RAN2 205-2) may respond with a modification or release of the MBS session success.
[0236] In some embodiments, at step S720, the AMF 225-1 may respond successfully to the MB-SMF 235 upon receiving the first successful response from the NG-RAN. If all NG-RANs are unreachable, or all reachable NG-RANs do not respond successfully, the AMF 225-1 may respond with a failure to the Namf_MBSBroadcast_ContextUpdate or Release request. In this case and / or in the event that at least one NG-RAN is unreachable, the MB-SMF 235 may then, for example, select an alternative AMF (e.g., AMF 225-2) in the same AMF set at step S740 and perform step S745 without including a list of NG-RAN IDs.
[0237] At step S725, if unicast transmission is used for the N3mb interface, the MB-SMF 235 may trigger a PFCP session modification request message to the MB-UPF 215 as needed to update the DL F-TEID of the NG-RAN for the MBS session.
[0238] At step S730, the AMF 225-1 may send one or more Namf_MBSBroadcast_ContextStatusNotify requests to report the NG-RAN failure event, as described above.
[0239] At step S735 , the MB-SMF 235 may respond to the Namf_MBSBroadcast_ContextStatusNotify request.
[0240] At step S740, the MB-SMF 235 may select an alternative AMF (e.g., AMF 225-2) belonging to the same AMF set using the binding indication provided by the old AMF 225-1 or using the NF profile of the old AMF 225-1, as described above.
[0241] At step S745, the MB-SMF 235 may send a Namf_MBSBroadcast_ContextUpdate request including an MBS session ID, a corresponding MBS service area, an MBS session information transmission request, and at least one of a ngranForUpdate list including an NG-RAN ID to be contacted and a corresponding NGAP signaling type.
[0242] When the MB-SMF 235 sends the Namf_MBSBroadcast_ContextRelease request in step S710, that is, when the MBS session is to be released, the MB-SMF 235 may set the "relMbsSessionInd" attribute to "true" in the Namf_MBSBroadcast_ContextUpdate request message to request the alternative AMF 225-2 to release the MBS session in the NG-RAN and also in the AMF 225-2.
[0243] At steps S750 to S775, the AMF 225-2 may send an N2 broadcast session setup or modification or release request to each NG-RAN as identified by the NG-RAN ID and according to the NGAP signaling type.
[0244] At step S780, AMF 225-2 may respond successfully to MB-SMF 235.
[0245] At step S785, if unicast transmission is used for the N3mb interface, the MB-SMF 235 may trigger a PFCP session modification request message to the MB-UPF 215 as needed to update the DL F-TEID of the NG-RAN for the MBS session.
[0246] pass Fig. 7A and Figure 7B The method shown can avoid the failure of MBS-related procedures when there is only a local link interruption between NG-RAN1 205-1 / NG-RAN3 205-3 / NG-RAN4205-4 and AMF1 225-1.
[0247] In some embodiments, when the MB-SMF detects that the AMF that is handling the broadcast MBS session has failed, the MB-SMF may reselect an alternative AMF by sending a Namf_MBSBroadcast_ContextUpdate request message, so that the alternative AMF becomes the serving AMF for the broadcast MBS session and is responsible for recovery, wherein the request message has the following indication: the alternative AMF is required not to trigger any NGAP message to transmit the N2 container-MBS session information request transmission, but only to store it for future potential NG-RAN recovery as described in clause 8.x.2.2 of Appendix B. Reference will be made below Figure 8 to describe the process.
[0248] Figure 8 is a diagram illustrating another exemplary process for recovering from a failure associated with a broadcast session via an alternative AMF according to another embodiment of the present disclosure.
[0249] like Figure 8 As shown, at step S805 , a broadcast MBS session may be started, and MBS session data may be sent to UE 200 via NG-RAN 205 .
[0250] At step S810, AMF1 225-1 may fail without restarting, or otherwise stop responding to any communication related to the MBS session. At step S815, MB-SMF 235 may detect that AMF1 225-1 has failed (or at least has stopped responding to any communication related to the MBS session), for example, via an HTTP / 2 Ping frame (when MB-SMF 235 is directly connected to AMF1 225-1) or via a notification of a NF state change to AMF1 225-1 from an NRF (when MB-SMF 235 has subscribed to such an event). Regardless of how MB-SMF 235 detects the failure of AMF1 225-1, at step S820, MB-SMF 235 may reselect an alternative AMF2 225-2 for subsequent operations related to the MBS session. In other words, MB-SMF 235 may select AMF2 225-2 to handle the broadcast MBS session.
[0251] At S825, the MB-SMF 235 may send a Namf_MBSBroadcast_ContextUpdateRequest message with a resume indication (so that AMF2 225-2 can know that it should not trigger any NGAP message to transmit the N2 container-MBS session information request transmission, but just store it for future potential NG-RAN resumption). This is at least in part because: when the NG-RAN 205 does not care which AMF provides service for the MBS session, the NG-RAN 205 does not need to know the change of its serving AMF. In this case, AMF2 225-2 can become the serving AMF for the broadcast MBS session and is responsible for subsequent resumption (if any).
[0252] At step S830, the AMF2 225-2 may respond to the request by sending a Namf_MBSBroadcast_ContextUpdate response message.
[0253] At step S835, if there is any failure associated with the MBS session, such as a NG-RAN 205 restart, the AMF2 225-2 (instead of the AMF1 225-1) may handle the resumption of the MBS session as defined in 3GPP TS 23.528, v18.3.1.
[0254] pass Figure 8 With the method shown, the broadcast MBS session information does not need to be stored in the shared memory of the AMF set, so that the AMFs in the same AMF set can retrieve it directly from the MB-SMF; because once the MB-SMF detects that the original AMF has failed, it will provide the complete broadcast MBS session information.
[0255] Fig. 9 9 is a flow chart of an exemplary method 900 at an AMF for facilitating an MB-SMF to attempt multicast session signaling for a multicast session or broadcast session signaling for a broadcast session according to an embodiment of the present disclosure. The method 900 may be performed at a first network node (e.g., Figure 2 The method 900 may include steps S910 and S920. However, the present disclosure is not limited thereto. In some other embodiments, the method 900 may include more steps, fewer steps, different steps, or any combination thereof. In addition, the steps of the method 900 may be performed in an order different from the order described herein. In addition, in some embodiments, the steps in the method 900 may be split into multiple sub-steps and performed by different entities, and / or multiple steps in the method 900 may be combined into a single step.
[0256] The method 900 may start at step S910, where it may be determined whether the AMF is unable to contact one or more RAN nodes for a multicast session or a broadcast session.
[0257] At step S920, in response to determining that the AMF cannot contact at least one first RAN node among the one or more RAN nodes for the multicast session or the broadcast session, a first message indicating the at least one first RAN node may be sent to the MB-SMF.
[0258] In some embodiments, before the step of determining whether the AMF is unable to contact one or more RAN nodes for a multicast session or a broadcast session, the method 900 may further include: sending a second message associated with the multicast session or the broadcast session to each of the one or more RAN nodes, wherein the step of determining that the AMF is unable to contact the at least one first RAN node may include: determining that the at least one first RAN node does not respond to the second message within a certain period of time. In some embodiments, the step of determining that the AMF is unable to contact the at least one first RAN node may include: determining that there is a failure in a path toward the at least one first RAN node.
[0259] In some embodiments, the first message may indicate at least one of the following: at least one identifier of the at least one first RAN node; an identifier of a multicast session or a broadcast session; and an indication indicating that the at least one first RAN node cannot be contacted. In some embodiments, the indication may also indicate at least one of the following: whether the AMF has detected the startup or restart of the corresponding NG-RAN; whether the AMF has detected a failure without the corresponding NG-RAN restarting; whether the AMF has been unable to reach the corresponding NG-RAN when sending the NGAP MBS session setup request message; whether the AMF has been unable to reach the corresponding NG-RAN when sending the NGAP MBS session modification request message; and whether the AMF has been unable to reach the corresponding NG-RAN when sending the NGAP MBS session release request message. In some embodiments, the method 900 may also include: receiving a third message from the MB-SMF in response to the first message. In some embodiments, before the step of determining whether the AMF cannot contact one or more RAN nodes for the multicast session or the broadcast session, the method 900 may also include: receiving a fourth message from the MB-SMF, the fourth message indicating that the AMF will contact the one or more RAN nodes to perform operations associated with the multicast session or the broadcast session. In some embodiments, the fourth message may indicate at least one of: an identifier of a multicast session or a broadcast session; a service area associated with the multicast session or the broadcast session; and information associated with the multicast session or the broadcast session to be delivered to the one or more RAN nodes. In some embodiments, the second message may be sent in response to receiving the fourth message.
[0260] In some embodiments, method 900 may also include: in response to sending the second message, receiving a fifth message from each second RAN node of at least one second RAN node of the one or more RAN nodes, the fifth message indicating whether an operation associated with the multicast session or the broadcast session is successfully performed; and based at least on the fifth message, sending a sixth message to the MB-SMF, the sixth message indicating whether the operation is successfully performed. In some embodiments, the method 900 may further include: receiving a seventh message from the MB-SMF, the seventh message indicating one or more identifiers of one or more third RAN nodes to be contacted by the AMF to perform operations associated with another multicast session or broadcast session; based at least on the seventh message, sending an eighth message to each of the one or more third RAN nodes, the eighth message indicating the one or more third RAN nodes to perform operations associated with the other multicast session or broadcast session; in response to sending the eighth message, receiving at least one ninth message from at least one of the one or more third RAN nodes, the at least one ninth message indicating whether the corresponding at least one third RAN node successfully performed operations associated with the other multicast session or broadcast session; and based at least on the ninth message, sending a tenth message to the MB-SMF, the tenth message indicating whether the operations associated with the other multicast session or broadcast session were successfully performed. In some embodiments, the seventh message may indicate at least one signaling type respectively associated with at least one of the one or more third RAN nodes. In some embodiments, the eighth message may be a request message of the type indicated by the seventh message, and / or the corresponding ninth message may be a response or failure message of the type indicated by the seventh message. In some embodiments, the seventh message may also indicate whether the multicast session or the broadcast session is to be released at the AMF and / or the one or more third RAN nodes.
[0261] In some embodiments, at least one of the fifth message, the sixth message, the ninth message, and the tenth message may also indicate unicast TNL information for shared transmission of a multicast session or a broadcast session. In some embodiments, the multicast session or the broadcast session may be an MBS session. In some embodiments, when the multicast session or the broadcast session is a broadcast MBS session, at least one of the following situations may be true: the first message is a Namf_MBSBroadcast_ContextStatusNotify request message; the second message is one of a broadcast session setup request message, a broadcast session release request message, and a broadcast session modification request message; the third message is a Namf_MBSBroadcast_ContextStatusNotify response message; the fourth message is one of a Namf_MBSBroadcast_ContextCreate request message, a Namf_MBSBroadcast_ContextRelease request message, and a Namf_MBSBroadcast_ContextUpdate request message; the fifth message is one of a broadcast session setup response message, a broadcast session release response message, and a broadcast session modification response message; the sixth message is a Namf_MBSBroadcast_ContextCreate response message, a Namf_MB The seventh message is one of Namf_MBSBroadcast_ContextRelease response message and Namf_MBSBroadcast_ContextUpdate response message; the eighth message is one of Namf_MBSBroadcast_ContextCreate request message, Namf_MBSBroadcast_ContextRelease request message and Namf_MBSBroadcast_ContextUpdate request message; the eighth message is one of broadcast session setup request message, broadcast session release request message and broadcast session modification request message; the ninth message is one of broadcast session establishment response message, broadcast session release response message and broadcast session modification response message; and the tenth message is one of Namf_MBSBroadcast_ContextCreate response message, Namf_MBSBroadcast_ContextRelease response message and Namf_MBSBroadcast_ContextUpdate response message.
[0262] Fig.10 1 is a flow chart of an exemplary method 1000 for attempting multicast session signaling for a multicast session or broadcast session signaling for a broadcast session at an MB-SMF according to an embodiment of the present disclosure. The method 1000 may be performed at a second network node (eg, Figure 2The method 1000 may include steps S1010, S1020, and S1030. However, the present disclosure is not limited thereto. In some other embodiments, the method 1000 may include more steps, fewer steps, different steps, or any combination thereof. In addition, the steps of the method 1000 may be performed in an order different from the order described herein. In addition, in some embodiments, the steps in the method 1000 may be split into multiple sub-steps and performed by different entities, and / or multiple steps in the method 1000 may be combined into a single step.
[0263] The method 1000 may start at step S1010, where a first message may be received from a first AMF, the first message indicating that the first AMF cannot contact at least one first RAN node for a multicast session or a broadcast session.
[0264] At step S1020, a second AMF belonging to the same AMF set and / or the same AMF service set as the first AMF may be determined.
[0265] At step S1030, a seventh message may be sent to the second AMF, the seventh message indicating one or more identifiers of the at least one first RAN node to be contacted by the second AMF to perform operations associated with the multicast session or the broadcast session.
[0266] In some embodiments, the first message may indicate at least one of the following: at least one identifier of the at least one first RAN node; an identifier of a multicast session or a broadcast session; and an indication indicating that the at least one first RAN node cannot be contacted at the first AMF. In some embodiments, the indication may also indicate at least one of the following: whether the first AMF has detected a startup or restart of the corresponding NG-RAN; whether the first AMF has detected a failure without the corresponding NG-RAN restarting; whether the first AMF has been unable to reach the corresponding NG-RAN when sending the NGAP MBS session setup request message; whether the first AMF has been unable to reach the corresponding NG-RAN when sending the NGAP MBS session modification request message; and whether the first AMF has been unable to reach the corresponding NG-RAN when sending the NGAP MBS session release request message. In some embodiments, the seventh message may be generated based at least on the received indication, so that the seventh message indicates at least one signaling type respectively associated with the at least one first RAN node. In some embodiments, the seventh message may also indicate whether to release the multicast session or the broadcast session at the second AMF and / or the at least one first RAN node.
[0267] In some embodiments, the method 1000 may further include: sending a third message to the first AMF in response to the first message. In some embodiments, before the step of receiving the first message, the method 1000 may further include: sending a fourth message to the first AMF, the fourth message indicating that the first AMF will contact one or more RAN nodes to perform operations associated with the multicast session or the broadcast session, and the one or more RAN nodes may include the at least one first RAN node. In some embodiments, the fourth message may indicate at least one of the following items: an identifier of the multicast session or the broadcast session; a service area associated with the multicast session or the broadcast session; and information associated with the multicast session or the broadcast session to be delivered to the one or more RAN nodes.
[0268] In some embodiments, the method 1000 may further include: receiving a sixth message from the first AMF, the sixth message indicating whether the one or more RAN nodes successfully performed an operation associated with the multicast session or the broadcast session. In some embodiments, the method 1000 may further include: receiving a tenth message from the second AMF, the tenth message indicating whether the at least one RAN node successfully performed an operation associated with the multicast session or the broadcast session. In some embodiments, at least one of the sixth message and the tenth message may also indicate unicast TNL information for shared transmission of the multicast session or the broadcast session. In some embodiments, the method 1000 may further include: communicating with the MB-UPF, and providing unicast TNL information for shared transmission of the multicast session or the broadcast session from the MB-UPF to the one or more RAN nodes or the at least one first RAN node.
[0269] In some embodiments, the multicast session or the broadcast session may be an MBS session. In some embodiments, when the multicast session or the broadcast session is a broadcast MBS session, at least one of the following situations may be true: the first message is a Namf_MBSBroadcast_ContextStatusNotify request message; the third message is a Namf_MBSBroadcast_ContextStatusNotify response message; the fourth message is one of a Namf_MBSBroadcast_ContextCreate request message, a Namf_MBSBroadcast_ContextRelease request message, and a Namf_MBSBroadcast_ContextUpdate request message; the sixth message is one of a Namf_MBSBroadcast_ContextCreate response message, a Namf_MBSBroadcast_ContextRelease request message, and a Namf_MBSBroadcast_ContextUpdate request message. The seventh message is one of Namf_MBSBroadcast_ContextRelease response message and Namf_MBSBroadcast_ContextUpdate response message; the seventh message is one of Namf_MBSBroadcast_ContextCreate request message, Namf_MBSBroadcast_ContextRelease request message and Namf_MBSBroadcast_ContextUpdate request message; and the tenth message is one of Namf_MBSBroadcast_ContextCreate response message, Namf_MBSBroadcast_ContextRelease response message and Namf_MBSBroadcast_ContextUpdate response message.
[0270] Fig.11 1 is a flow chart of an exemplary method 1100 for facilitating MB-SMF resumption of a broadcast session at an AMF according to an embodiment of the present disclosure. The method 1100 may be performed at a first network node (eg, Figure 2 The method 1100 may include step S1110. However, the present disclosure is not limited thereto. In some other embodiments, the method 1100 may include more steps, different steps, or any combination thereof. In addition, the steps of the method 1100 may be performed in an order different from the order described herein. In addition, in some embodiments, the steps in the method 1100 may be split into multiple sub-steps and performed by different entities, and / or multiple steps in the method 1100 may be combined into a single step.
[0271] Method 1100 may begin at step S1110, where an eleventh message may be received from the MB-SMF, the eleventh message including an indication that the eleventh message will provide information associated with the broadcast session for subsequent resumption of the broadcast session only when one or more RAN nodes are restarted.
[0272] In some embodiments, the eleventh message may indicate at least one of the following: an identifier of the broadcast session; a service area associated with the broadcast session; information required for subsequent resumption of the broadcast session; and a resumption indication indicating that the AMF will not trigger any NGAP signaling to the one or more RAN nodes for resuming the broadcast session. In some embodiments, when the resumption indication is set to "true" and the service area is indicated by the eleventh message, the AMF may be requested not to trigger any NGAP signaling toward one or more NG-RAN nodes covering the indicated service area. In some embodiments, the AMF and another AMF for resuming the broadcast session may belong to the same AMF set and / or the same AMF service set. In some embodiments, the method 1100 may further include: sending a twelfth message to the MB-SMF, the twelfth message replying to the eleventh message and indicating that the AMF has taken over the broadcast session from the other AMF. In some embodiments, the broadcast session may be an MBS session. In some embodiments, at least one of the following may be true: the eleventh message is a Namf_MBSBroadcast_ContextUpdate request message; and the twelfth message is a Namf_MBSBroadcast_ContextUpdate response message.
[0273] Fig.12 1 is a flow chart of an exemplary method 1200 for resuming a broadcast session at an MB-SMF according to an embodiment of the present disclosure. The method 1200 may be performed at a second network node (eg, Figure 2 The method 1200 may include steps S1210, S1220, and S1230. However, the present disclosure is not limited thereto. In some other embodiments, the method 1200 may include more steps, fewer steps, different steps, or any combination thereof. In addition, the steps of the method 1200 may be performed in an order different from the order described herein. In addition, in some embodiments, the steps in the method 1200 may be split into multiple sub-steps and performed by different entities, and / or multiple steps in the method 1200 may be combined into a single step.
[0274] Method 1200 may start at step S1210, where it may be determined whether the first AMF is unable to provide service for the broadcast session.
[0275] At step S1220, it may be determined that the second AMF takes over the broadcast session from the first AMF.
[0276] At step S1230, an eleventh message may be sent to the second AMF, the eleventh message including an indication that the eleventh message will provide information associated with the broadcast session, which is used for subsequent resumption of the broadcast session only when one or more RAN nodes are restarted.
[0277] In some embodiments, the eleventh message may indicate at least one of the following: an identifier of the broadcast session; a service area associated with the broadcast session; information required for the second AMF to subsequently resume the broadcast session; and a resume indication indicating that the second AMF will not trigger any NGAP signaling to the one or more RAN nodes for resuming the broadcast session. In some embodiments, when the resume indication is set to "true" and the service area is indicated by the eleventh message, the second AMF may be requested not to trigger any NGAP signaling towards one or more NG-RAN nodes covering the indicated service area. In some embodiments, the first AMF and the second AMF may belong to the same AMF set and / or the same AMF service set. In some embodiments, the method 1200 may further include: receiving a twelfth message from the second AMF, the twelfth message replying to the eleventh message and indicating that the second AMF has taken over the broadcast session from the first AMF. In some embodiments, the step of determining whether the first AMF is unable to provide service for the broadcast session may include: detecting whether the first AMF is unable to provide service for the broadcast session by using an HTTP / 2 Ping frame.
[0278] In some embodiments, before the step of determining whether the first AMF is unable to provide services for the broadcast session, the method 1200 may further include: subscribing to the NRF to receive a notification of a change in the configuration file of the first AMF, wherein the step of determining whether the first AMF is unable to provide services for the broadcast session may include: receiving a notification of a change in the configuration file of the first AMF from the NRF, which notification may indicate that the first AMF is unable to provide services for the broadcast session. In some embodiments, the broadcast session may be an MBS session. In some embodiments, at least one of the following may be true: the eleventh message is a Namf_MBSBroadcast_ContextUpdate request message; and the twelfth message is a Namf_MBSBroadcast_ContextUpdate response message.
[0279] Fig.13An embodiment of an arrangement that can be used in a network node according to an embodiment of the present disclosure is schematically shown. The arrangement 1300 includes a processing unit 1306, for example, having a digital signal processor (DSP) or a central processing unit (CPU). The processing unit 1306 can be a single unit or multiple units for performing different actions of the processes described herein. The arrangement 1300 may also include an input unit 1302 for receiving signals from other entities, and an output unit 1304 for providing signals to other entities. The input unit 1302 and the output unit 1304 may be arranged as an integrated entity or as independent entities.
[0280] Furthermore, the arrangement 1300 may include at least one computer program product 1308 in the form of a non-volatile or volatile memory, such as an electrically erasable programmable read-only memory (EEPROM), a flash memory and / or a hard drive. The computer program product 1308 includes a computer program 1310, which includes code / computer-readable instructions that, when executed by the processing unit 1306 in the arrangement 1300, causes the arrangement 1300 or a network node including the arrangement 1300 to perform, for example, the operations described previously in connection with Figures 5 to 12 or any other variation of the described process.
[0281] The computer program 1310 may be configured as computer program code constructed in computer program modules 1310A and 1310B. Therefore, in an exemplary embodiment when the arrangement 1300 is used in a first network node, the code in the computer program of the arrangement 1300 includes: a module 1310A configured to determine whether the AMF is unable to contact one or more RAN nodes for a multicast session or a broadcast session; and a module 1310B configured to: in response to determining that the AMF is unable to contact at least one first RAN node of the one or more RAN nodes for the multicast session or the broadcast session, send a first message indicating the at least one first RAN node to the MB-SMF.
[0282] Alternatively or additionally, the computer program 1310 may be configured as computer program code constructed in computer program modules 1310C, 1310D and 1310E. Thus, in an exemplary embodiment when the arrangement 1300 is used in a second network node, the code in the computer program of the arrangement 1300 comprises: a module 1310C configured to receive a first message from a first AMF indicating that the first AMF cannot contact at least one first RAN node for a multicast session or a broadcast session; a module 1310D configured to determine a second AMF belonging to the same AMF set and / or the same AMF service set as the first AMF; and a module 1310E configured to send a seventh message to the second AMF indicating one or more identifiers of the at least one first RAN node to be contacted by the second AMF to perform operations associated with the multicast session or the broadcast session.
[0283] Alternatively or additionally, the computer program 1310 may be configured as computer program code constructed in a computer program module 1310F. Thus, in an exemplary embodiment when the arrangement 1300 is used in a first network node, the code in the computer program of the arrangement 1300 comprises: a module 1310F configured to receive an eleventh message from the MB-SMF, the eleventh message comprising an indication that the eleventh message will provide information associated with the broadcast session, the information being used for subsequent resumption of the broadcast session only when one or more RAN nodes are restarted.
[0284] Alternatively or additionally, the computer program 1310 may be configured as computer program code constructed in computer program modules 1310G, 1310H and 1310I. Thus, in an exemplary embodiment when the arrangement 1300 is used in the second network node, the code in the computer program of the arrangement 1300 includes: module 1310G configured to determine whether the first AMF is unable to provide services for the broadcast session; module 1310H configured to determine that the second AMF takes over the broadcast session from the first AMF; and module 1310I configured to send an eleventh message to the second AMF, the eleventh message including an indication that the eleventh message will provide information associated with the broadcast session, which is used for subsequent resumption of the broadcast session only when one or more RAN nodes are restarted.
[0285] A computer program module can basically execute Figures 5 to 12 In other words, when different computer program modules are executed in the processing unit 1306, they may correspond to different modules in the network node.
[0286] Although the above combination Fig.13The code device in the disclosed embodiment is implemented as a computer program module, which, when executed in a processor, enables the device to perform the actions described above in conjunction with the above figures. In an alternative embodiment, at least one code device can be at least partially implemented as a hardware circuit.
[0287] The processor may be a single CPU (central processing unit), but may also include two or more processing units. For example, the processor may include a general-purpose microprocessor; an instruction set processor and / or an associated chipset and / or a dedicated microprocessor, such as an application-specific integrated circuit (ASIC). The processor may also include onboard memory for cache purposes. The computer program may be carried by a computer program product connected to the processor. The computer program product may include 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 above-mentioned computer program modules may be distributed on different computer program products in the form of memory within the network node in an alternative embodiment.
[0288] An exemplary first network node is provided corresponding to the method 900 described above. Fig.14 1 is a block diagram of a first network node 1400 according to an embodiment of the present disclosure. In some embodiments, the first network node 1400 may be, for example, an AMF 225.
[0289] The first network node 1400 may be configured to perform the above Fig. 9 The method 900 is described. Fig.14 As shown, the first network node 1400 may include: a determination module 1410, configured to determine whether the AMF is unable to contact one or more RAN nodes for a multicast session or a broadcast session; and a sending module 1420, configured to: in response to determining that the AMF is unable to contact at least one first RAN node among the one or more RAN nodes for the multicast session or the broadcast session, send a first message indicating the at least one first RAN node to the MB-SMF.
[0290] The modules 1410 and / or 1420 described above may be implemented as a pure hardware solution or a combination of software and hardware, for example, by one or more of the following: a processor or microprocessor and appropriate software and a memory for storing software, a programmable logic device (PLD) or other electronic component or a device configured to execute the above-mentioned and, for example, in Fig. 9 In addition, the first network node 1400 may include one or more additional modules, each of which may perform the actions shown in the reference Fig. 9 Any steps of method 900 described.
[0291] An exemplary second network node is provided corresponding to the method 1000 described above. Fig.15 is a block diagram of a second network node 1500 according to an embodiment of the present disclosure. In some embodiments, the second network node 1500 may be, for example, the MB-SMF 235.
[0292] The second network node 1500 may be configured to perform the above combined Fig.10 The method 1000 is described. Fig.15 As shown, the second network node 1500 may include: a receiving module 1510, configured to receive a first message from a first AMF, the first message indicating that the first AMF cannot contact at least one first RAN node for a multicast session or a broadcast session; a determining module 1520, configured to determine a second AMF belonging to the same AMF set and / or the same AMF service set as the first AMF; and a sending module 1530, configured to send a seventh message to the second AMF, the seventh message indicating one or more identifiers of the at least one first RAN node, and the at least one first RAN node will be contacted by the second AMF to perform operations associated with the multicast session or the broadcast session.
[0293] The modules 1510, 1520 and / or 1530 described above may be implemented as a pure hardware solution or a combination of software and hardware, for example, by one or more of the following: a processor or microprocessor and appropriate software and a memory for storing the software, a PLD or other electronic component or a device configured to execute the above-described and, for example, in Fig.10 In addition, the second network node 1500 may include one or more additional modules, each of which may execute the reference Fig.10 Any step of method 1000 described.
[0294] An exemplary first network node is provided corresponding to the method 1100 described above. Fig.16 1 is a block diagram of a first network node 1600 according to an embodiment of the present disclosure. In some embodiments, the first network node 1600 may be, for example, an AMF 225.
[0295] The first network node 1600 may be configured to perform the above Fig.11 The method 1100 is described. Fig.16 As shown, the first network node 1600 may include a receiving module 1610 configured to receive an eleventh message from the MB-SMF, the eleventh message including an indication that the eleventh message will provide information associated with the broadcast session, which is used for subsequent resumption of the broadcast session only when one or more RAN nodes are restarted.
[0296] The module 1610 described above can be implemented as a pure hardware solution or a combination of software and hardware, for example, by one or more of the following: a processor or microprocessor and appropriate software and a memory for storing software, a PLD or other electronic component or a device configured to execute the above-mentioned and, for example, in Fig.11 In addition, the first network node 1600 may include one or more additional modules, each of which may execute the reference Fig.11 Any steps of method 1100 described.
[0297] An exemplary second network node is provided corresponding to the method 1200 described above. Fig.17 is a block diagram of a second network node 1700 according to an embodiment of the present disclosure. In some embodiments, the second network node 1700 may be, for example, the MB-SMF 235.
[0298] The second network node 1700 may be configured to perform the above combined Fig.12 The method 1200 is described. Fig.17 As shown, the second network node 1700 may include: a first determination module 1710, configured to determine whether the first AMF is unable to provide services for the broadcast session; a second determination module 1720, configured to determine that the second AMF takes over the broadcast session from the first AMF; and a sending module 1730, configured to send an eleventh message to the second AMF, the eleventh message including an indication that the eleventh message will provide information associated with the broadcast session, which is used for subsequent recovery of the broadcast session only when one or more RAN nodes are restarted.
[0299] The modules 1710, 1720 and / or 1730 described above may be implemented as a pure hardware solution or a combination of software and hardware, for example, by one or more of the following: a processor or microprocessor and appropriate software and a memory for storing the software, a PLD or other electronic component or a device configured to execute the above-described and, for example, in Fig.12 In addition, the second network node 1700 may include one or more additional modules, each of which may execute the reference Fig.12 Any steps of method 1200 described.
[0300] The present disclosure has been described above with reference to the embodiments of the present disclosure. However, these embodiments are for illustrative purposes only and are not intended to limit the present disclosure. The scope of the present disclosure is defined by the appended claims and their equivalents. A person skilled in the art may make various modifications and variations without departing from the scope of the present disclosure, wherein these modifications and variations all fall within the scope of the present disclosure.
[0301] Abbreviations
[0302] AMF access and mobility management function
[0303] DL Downlink
[0304] GTP-UGPRS Tunneling Protocol-User Plane
[0305] MBS Multicast / Broadcast Service
[0306] MB-SMF multicast / broadcast session management function
[0307] NG-RAN Next Generation Radio Access Network
[0308] SMF session management function
[0309] TEID tunnel entity identifier.
[0310] Appendix A
[0311] 3GPP TSG-CT WG4 meeting #110-eC4-223abc
[0312] Electronic Conference, May 12-20, 2022
[0313] Source: Ericsson
[0314] Title: Discussion on the failure of broadcast MBS sessions in 5GS
[0315] Version: Version 17
[0316] Agenda item: 6.1.16
[0317] Documents are used for: Decision making
[0318] 1. Introduction
[0319] The specification of the resumption procedure for resuming MBS sessions in 5G is part of the 5MBS work item.
[0320] This paper analyses some failure scenarios and their impact on the recovery process for resuming broadcast MBS sessions in NG-RAN.
[0321] 2. Description
[0322] 2.1 Transmission of broadcast session management messages via alternative AMF
[0323] Since Release 16, network functions in the control plane of 5GC can support NF (service) sets so that their resources / session contexts are shared by multiple NF service instances in the same NF (service) set to achieve redundancy, thereby providing high reliability to 5G services.
[0324] Since version 15, even support for AMF sets was introduced, so that an alternative AMF belonging to the same AMF set as the failed AMF will be chosen to replace the failed AMF.
[0325] As described in 3GPP TS 23.247 clause 7.3.1, in order to start a broadcast MBS session, MB-SMF needs to perform NF service discovery on NRF to select an AMF that is capable of consuming Namf_MBSBroadcast service. In the example below, MB-SMF selects AMF1 to start a broadcast MBS session, and the MBS session data is broadcast in the MBS service area.
[0326] When MB-SMF uses, for example, HTTP / 2 Ping frames or gets notifications about NF status changes from NRF (when it subscribes to such events) AMF1 has failed. hour, And when MB-SMF needs to trigger MBS session update for broadcast For example, when adding a new QoS flow based on AF request, MB-SMF may use the Binding Indication provided by AMF1 or use the NF Profile of AMF1 to find an alternative AMF (e.g. AMF2) that belongs to the same AMF Set as AMF1.
[0327] As specified in 3GPP TS 38.413-17.0.0, broadcast session management messages are sent and received based on the MBS session ID, which is different from identifying the UE context in NGAP, in which the NG-RAN and AMF need to exchange the RAN UE NGAP ID and the AMF UE NGAP ID, which are used to identify the UE context in the NG-RAN or AMF, respectively.
[0328] Therefore, it is assumed that the NG-RAN shall be able to accept subsequent broadcast session modification requests via another AMF (e.g. AMF2 or AMF3) in the same AMF Set.
[0329] NOTE: For multicast sessions, the situation is similar and the NG-RAN may accept subsequent multicast session update requests or multicast session deactivation requests from another AMF in the same AMF Set.
[0330] Recommendation 1: If the alternative AMF (e.g. AMF2 or AMF3) belongs to the same AMF set as the old AMF, the NG-RAN should be able to accept subsequent broadcast session modification / release requests via another AMF other than the one that sent the broadcast session setup request. CT4 may need to send a LS to RAN3 to confirm this.
[0331] (See Figure 5 )
[0332] 2.2 Failure to send broadcast session management message to NG-RAN
[0333] When performing the MBS session start / release / update procedures for a broadcast MBS session as specified in clauses 7.3.1, 7.3.2 and 7.3.3, one or several NG-RANs that are part of the MBS service area may be unreachable, i.e. broadcast services will not be available in the areas covered by these NG-RANs.
[0334] Recommendation 2: When AMF1 fails to contact one or more NG-RANs when it receives an MBS Broadcast Context Create / Update / Release Request message from MB-SMF, AMF1 reports this failure event to MB-SMF together with the NG-RANIDs of those (uncontactable) NG-RANs. MB-SMF may retransmit the same request to those NG-RANs identified by the NG-RAN IDs via the alternative AMF to circumvent potential local link disruption only between the first AMF and the NG-RAN.
[0335] For reference, see also TS 29.518, clause 5.6.2.2.
[0336] On success, a 201 Created response shall be returned. The AMF shall respond successfully when the first successful response from the NG-RAN is received. If additional information needs to be transferred to the MB-SMF (e.g. the MBS Session Information Response Transfer IE or the MBS Session Information Failure Transfer IE in 3GPP TS 38.413
[12] ), the 201 Created response may contain one or more N2 MBS Session Management containers. If the AMF receives NG-RAN responses from all involved NG-RANs (e.g. if the broadcast MBS session involves only one NG-RAN), the AMF shall include in the 201 Created response an indication that the operation is completed in all NG-RANs.
[0337] When a subsequent response is received from another NG-RAN after sending a "201 Created" response , if necessary Additional information (e.g., MBS Session Information Response Transfer IE or MBS Session Information Failure Transfer IE in 3GPP TS 38.413
[12] ) IE) to MB-SMF, the AMF shall send one or more Namf_MBSBroadcast_ ContextStatusNotify request to transmit this information The Namf_MBSBroadcast_ContextStatusNotify request may include a list of N2 MBS Session Management Containers received from different NG-RANs. When the AMF receives responses from all NG-RANs, the AMF shall include an indication of the completion of the operation in the Namf_MBSBroadcast_ContextStatusNotify request.
[0338] If the AMF does not receive a response from all NG-RAN nodes before the maximum response time has elapsed since receipt of the Namf_MBSBroadcast_ContextCreate request, the AMF shall send a Namf_MBSBroadcast_ContextStatusNotify request indicating that the broadcast MBS session establishment is not completed.
[0339] (See Fig. 6A and Figure 6B )
[0340] Processing of Namf_MBSBroadcast_ContextUpdate or Release request:
[0341] When the AMF receives an MBS broadcast context update request from the MB-SMF, and if the context update request is to extend the MBS service area and update the MBS session information at the same time, the AMF needs to:
[0342] - Sending an N2 Broadcast Session Setup Request with updated MBS session information to each new NG-RAN that will cover the expanded MB service area; and
[0343] - Sending an N2 Broadcast Session Modification Request with updated MBS session information to those old NG-RANs (which are covering the "old" MBS service area).
[0344] Therefore, when the AMF reports that it is unable to contact the NG-RAN for an MBS Broadcast Context Update Request, it includes a failure indication describing that the NG-RAN could not be reached when sending an N2 Broadcast Session Setup Request or sending an N2 Broadcast Session Modify Request, where the NG-RAN is identified by the NG-RAN ID. The AMF indicates that sending a Release Request failed.
[0345] Therefore, with the help of the failure indication, the MB-SMF shall send an MBS Broadcast Context Update Request with a list of ngranForUpdate attributes to the alternative AMF2, each ngranForUpdate attribute containing the NG-RAN ID and the type of NGAP signalling to be performed (setup or modification or release request).
[0346] See also Fig. 7A and Figure 7B .
[0347] 2.3 AMF-based resumption of MBS broadcast sessions on NG-RAN restart
[0348] As stated in the agreed CR C4-222349, for broadcast MBS session resumption by AMF, the AMF handling the broadcast MBS session is responsible for resuming the MBS session in the restarted NG-RAN and shall store the last N2 MBS SM container (i.e., the MBS Session Information Request Transfer IE defined in 3GPP TS 38.413
[11] ) received from the MB-SMF during establishment of the broadcast MBS session or during broadcast MBS session update.
[0349] When the AMF that is handling the establishment of a broadcast MBS session or the last update of a broadcast MBS session has failed before the NG-RAN failure, it is unclear which AMF belonging to the same AMF set (as the AMF handling the broadcast MBS session) will be responsible for resuming the broadcast MBS session.
[0350] In this case, the following alternatives may be considered:
[0351] a. Use implementation specific mechanisms to ensure that only one AMF belonging to the same AMF Set as the failed AMF will send an NGAP Broadcast Session Setup Request to the restarted NG-RAN to resume the broadcast MBS session;
[0352] b. All AMFs in the same AMF set When NG-RAN restart is detected, an NGAP Broadcast Session Establishment Request will be sent to try to resume the MBS session;
[0353] Note 1: Alternatives a and b assume Including N2 container MBS session information is shared between AMFs in the same AMF set.
[0354] NOTE 2: Alternative B assumes that the NG-RAN shall be able to accept the first SETUP REQUEST and ignore subsequent SETUP REQUESTS, e.g. if the NG-RAN receives this first SETUP REQUEST from AMF2, it shall ignore the SETUP REQUEST from AMF3.
[0355] c. Once MB-SMF detects that AMF1 has failed, MB-SMF shall reselect AMF2 so that AMF2 becomes the serving AMF for the broadcast MBS session, and then AMF2 is responsible for recovery.
[0356] (See Figure 8 )
[0357] Evaluate:
[0358] Alternative A requires a specific mechanism to ensure that only one AMF performs recovery, which was considered very complex when CT4 discussed supporting SMF sets through the N4 interface; while Alternative B sends redundant NGAP signaling messages to NG-RAN, which causes additional processing in NG-RAN and may cause some errors. In addition, Alternative A and B control the requirement that N2 containers must be stored in shared storage devices.
[0359] Although Alternative C triggers a pair of extra signaling messages between MB-SMF and AMF, it avoids the problems / complexities to be overcome in Alternatives A and B, and even avoids storing the MBS session information in a shared memory.
[0360] Recommendation 3: It is recommended that once MB-SMF detects that AMF1 has failed, MB-SMF should reselect an alternative AMF2 by sending an MBS Broadcast Context Update Request message with a Recovery Indication so that AMF2 becomes the serving AMF for the broadcast MBS session and is responsible for recovery. The Recovery Indication lets AMF2 know that it should not trigger any NGAP message to transmit the N2 Container - MBS Session Information Request transmission, but just store it for future potential NG-RAN recovery.
[0361] 3. Recommendations
[0362] It is recommended that 3GPP CT4 should continue to advance Recommendations 1, 2 and 3 and agree on their accompanying CRs.
[0363] 4. References
[0364] 1. 3GPP TS 23.247-v17.2.0
[0365] 2. 3GPP TS 23.527-v17.2.0
[0366] 3. 3GPP TS 29.532-v17.0.0
[0367] 4. 3GPP TS 38.413-v17.0.0
[0368] 5. Attachments:
[0369] 5.1 Excerpt from TS 38.413:
[0370] 9.2.16 Broadcasting Session Management Messages
[0371] 9.2.16.1 Broadcast Session Setup Request
[0372] AMF sends this message to establish an MBS context.
[0373] Direction: AMF->NG-RAN node
[0374]
[0375] 9.2.16.2 Broadcast Session Setup Response
[0376] The NG-RAN node sends this message to report the successful outcome of the request from the Broadcast Session Start Request message.
[0377] Direction: NG-RAN node -> AMF
[0378]
[0379] 9.2.16.4 Broadcast Session Modification Request
[0380] The AMF sends this message to modify the MBS context.
[0381] Direction: AMF->NG-RAN node
[0382]
[0383] 9.2.16.5 Broadcast Session Modification Response
[0384] The NG-RAN node sends this message to report the successful outcome of the request from the Broadcast Session Modification Request message.
[0385] Direction: NG-RAN node -> AMF
[0386]
[0387] 9.2.16.7 Broadcast Session Release Request
[0388] The AMF sends this message to release the corresponding MBS context and the logical NG connection associated with the MBS service.
[0389] Direction: AMF->NG-RAN node
[0390]
[0391] 9.2.16.8 Broadcast Session Release Response
[0392] The NG-RAN node sends this message in response to the Broadcast Session Release Request message.
[0393] Direction: NG-RAN node -> AMF
[0394]
[0395] 9.2.17.6 Multicast session activation request
[0396] This message is sent by the AMF to the NG-RAN node to request activation of MBS resources.
[0397] Direction: AMF->NG-RAN node
[0398]
[0399] 9.2.17.7 Multicast Session Activation Response
[0400] This message is sent by the NG-RAN node to the AMF to indicate that the MBS resources have been activated.
[0401] Direction: NG-RAN node -> AMF
[0402]
[0403] 9.2.17.9 Multicast session deactivation request
[0404] This message is sent by the AMF to the NG-RAN node to request deactivation of the MBS resources for the MBS session.
[0405] Direction: AMF->NG-RAN node
[0406]
[0407] 9.2.17.10 Multicast session deactivation response
[0408] This message is sent by the NG-RAN node to the AMF to indicate that the MBS resources have been deactivated.
[0409] Direction: NG-RAN node -> AMF
[0410]
[0411] 9.2.17.11 Multicast Session Update Request
[0412] This message is sent by the AMF to the NG-RAN node to update the MBS information.
[0413] Direction: AMF->NG-RAN node
[0414]
[0415] 9.2.17.12 Multicast Session Update Response
[0416] This message is sent by the NG-RAN node to the AMF to confirm the update of MBS information.
[0417] Direction: NG-RAN node -> AMF
[0418]
[0419] Appendix B
[0420] 3GPP TSG-CT WG4 meeting #110-eC4-223abc
[0421] Electronic Conference, May 12-20, 2022
[0422]
[0423]
[0424] ****First Change****
[0425] 8.x.5 Support for broadcast MBS sessions when AMF sets are deployed
[0426] 8.x.5.1 Broadcast MBS Session Signalling via Alternative AMF
[0427] When the AMF Set feature is deployed in the network, the NG-RAN is connected to the AMF Set. In this case, if the alternative AMF belongs to the same AMF set as the old AMF, the NG-RAN will be able to accept the broadcast session setup request sent via the AMF other than the old AMF. Subsequent broadcast session modification or release request messages sent by alternative AMF other than the one sent by the AMF.
[0428] When AMF receives a Namf_MBSBroadcast_ContextCreate or Update or Release request message, one or more NG-RANs cannot be contacted, the AMF shall report this NG-RAN failure event together with those The (unreachable) NG-RAN is reported to the MB-SMF together with the NG-RAN ID of the NG-RAN. The MB-SMF may to those NG-RANs identified by the NG-RAN ID to avoid the need for retrying the (same) request only on the first AMF and Potential local link outage between NG-RANs.
[0429] See also Fig. 6A and Figure 6B to understand the Namf_MBSBroadcast_ContextCreate message sent via the alternative AMF interest.
[0430] 1 ( S605 ). Request to establish a broadcast MBS session in the network.
[0431] 2 (S610). MB-SMF selects AMF to send a Namf_MBSBroadcast_ContextCreate request, which contains The MBS session ID, the corresponding MBS service area, and the MBS session information transmission request are included.
[0432] 3a to 3c (S615 / S620 / S625). The AMF uses the MBS service area to retrieve the list of NG-RANs to contact. And sends an N2 broadcast session establishment request to each NG-RAN to be contacted. The AMF detects that some NG-RANs (e.g. NG- RAN1) is unreachable.
[0433] Some NG-RAN responses indicate that the MBS session establishment is successful.
[0434] AMF responds successfully to MB-SMF upon receiving the first successful response from NG-RAN. If the RAN is unreachable, the AMF will respond to the Namf_MBSBroadcast_ContextCreate request failure and In this case, the MB-SMF may select an alternative AMF in the same AMF Set and perform step 8 without including the list of NG-RAN IDs.
[0435] 4 (S630). If unicast transmission is used for the N3mb interface, the MB-SMF triggers a call to the MB-UPF as needed. PFCP Session Modification Request message to update the DL F-TEID of the NG-RAN for the MBS session.
[0436] 5 (S635). AMF sends one or more Namf_MBSBroadcast_ContextStatusNotify request messages Messages are used to report NG-RAN failure events.
[0437] 6 (S640). MB-SMF responds to the Namf_MBSBroadcast_ContextStatusNotify request message answer.
[0438] 7 (S645). MB-SMF uses the binding indication provided by the old AMF or uses the NF profile of the old AMF to select Select an alternative AMF belonging to the same AMF set.
[0439] 8 (S650). MB-SMF sends a Namf_MBSBroadcast_ContextCreate request, which includes the MBS session ID, the corresponding MBS service area, an MBS session information request transmission, and a list of NG-RAN IDs to contact.
[0440] 9 ( S655 ). The AMF sends an N2 broadcast session establishment request to each NG-RAN identified by the NG-RAN ID.
[0441] 10 (S660). NG-RAN responds that the MBS session is successfully established
[0442] 11 (S665). AMF responds successfully to MB-SMF.
[0443] 12 (S670). If unicast transmission is used for the N3mb interface, the MB-SMF triggers a call to the MB-UPF as needed. PFCP Session Modification Request message to update the DL F-TEID of the NG-RAN for the MBS session.
[0444] See also Fig. 7A and Figure 7B to understand the Namf_MBSBroadcast_ContextUpdate sent via the alternative AMF or Release message.
[0445] 1 (S705). A broadcast MBS session has been established in the network.
[0446] 2 (S710). MB-SMF sends Namf_MBSBroadcast_ to the AMF that is processing the MBS session. ContextUpdate request (including MBS session ID, corresponding MBS service area and MBS session information request transmission) or with The MBS session generates a Namf_MBSBroadcast_ContextRelease request message with a reference ID.
[0447] 3 (abcd) (S715a / S715b / S715c / S720). For Namf_MBSBroadcast_ContextUpdate Request, the AMF uses the MBS service area to retrieve the list of NG-RANs to contact and does the following:
[0448] Sending an N2 Broadcast Session Modification Request to each NG-RAN that is covering the old MBS service area; and / or
[0449] Sending an N2 Broadcast Session Setup Request to each NG-RAN that is to cover the extended MBS service area; and / or
[0450] Send an N2 Broadcast Session Release Request to each NG-RAN that is covering the shrinking MBS service area
[0451] For the Namf_MBSBroadcast_ContextRelease request message, AMF sends a request to all NG-RAN sends N2 broadcast session release request.
[0452] The AMF detects some NG-RAN (e.g. Fig. 7A and Figure 7B NG-RAN1, NG-RAN3 and NG-RAN4 in Unreachable for a setup request, a modify request, and / or a release request.
[0453] Some NG-RAN responses modify or release the MBS session successfully.
[0454] AMF responds successfully to MB-SMF upon receiving the first successful response from NG-RAN. If the RAN is unreachable, the AMF will respond to the failure of the Namf_MBSBroadcast_ContextUpdate or Release request and And in this case, the MB-SMF may select an alternative AMF in the same AMF Set and execute step 8 without including the NG-RAN A list of IDs.
[0455] 4 (S725). If unicast transmission is used for the N3mb interface, the MB-SMF triggers a call to the MB-UPF as needed. PFCP Session Modification Request message to update the DL F-TEID of the NG-RAN for the MBS session.
[0456] 5 (S730). AMF sends one or more Namf_MBSBroadcast_ContextStatusNotify requests to Report NG-RAN failure events.
[0457] 6 (S735). MB-SMF responds to the Namf_MBSBroadcast_ContextStatusNotify request.
[0458] 7 (S740). MB-SMF uses the binding indication provided by the old AMF or uses the NF profile of the old AMF to select Select an alternative AMF belonging to the same AMF set.
[0459] 8 (S745). MB-SMF sends a Namf_MBSBroadcast_ContextUpdate request, which includes MBS Session ID, corresponding MBS service area, MBS session information request transmission, and NG-RAN ID to be contacted and corresponding ngranForUpdate list of NGAP signaling types.
[0460] When MB-SMF sends the Namf_MBSBroadcast_ContextRelease request in step 3, the MBS will When the call is to be released, MB-SMF will send The "relMbsSessionInd" attribute is set to "true" to request the alternative AMF to release the MBS session in the NG-RAN and also in the AMF.
[0461] 9-14 (S750-S775). The AMF sends a signal to each NG-RAN as identified by the NG-RAN ID and according to the NGAP signaling type. The RAN sends an N2 broadcast session establishment, modification or release request.
[0462] 15 (S780). AMF responds successfully to MB-SMF.
[0463] 16 (S785). If unicast transmission is used for the N3mb interface, the MB-SMF triggers a call to the MB-UPF as needed. PFCP Session Modification Request message to update the DL F-TEID of the NG-RAN for the MBS session.
[0464] ****Next Change****
[0465] 8.x.5.2 Selecting an alternative AMF when AMF fails
[0466] When MB-SMF detects that the AMF that is processing the broadcast MBS session has failed, MB-SMF can send Namf_MBSBroadcast_ContextUpdate request message is used to reselect the candidate AMF so that the candidate AMF becomes the The serving AMF of the broadcast MBS session is responsible for recovery, wherein the request message has the following indication: requiring the alternative AMF not to trigger Send any NGAP message to transmit the N2 container-MBS session information request transmission, but just store it for use as in clause Potential future NG-RAN recovery as described in 8.x.2.2.
[0467] See also Figure 8 to learn about selecting an alternative AMF when AMF fails.
[0468] 1 (S805). A broadcast MBS session has been established in the network.
[0469] 2 (S810). AMF1 has failed without restarting.
[0470] 3 (S815). MB-SMF via HTTP / 2 PING frame (in case of direct connection) or via Notifications for NF state changes (when it has subscribed to such events) detect that AMF1 has failed without being restarted.
[0471] 4 (S820). MB-SMF uses the binding indication provided by the old AMF or uses the NF profile of the old AMF to select Select an alternative AMF belonging to the same AMF set.
[0472] 5 (S825). MB-SMF sends a Namf_MBSBroadcast_ContextUpdate request, which includes the MBS session ID, the corresponding MBS service area, and the MBS session information request transmission, and set "noNgapSignallingInd" to "TRUE" to request the alternative AMF not to trigger any NGAP signaling to the NG-RAN covering the MBS service area.
[0473] 6 (S830). AMF responds to the Namf_MBSBroadcast_ContextUpdate request message without triggering Send any NGAP MBS session signaling.
[0474] 7 (S835). The AMF continues with the process specified in clause 8.x.2.2.
[0475] ****END OF CHANGES****
[0476] Appendix C
[0477] 3GPP TSG-CT WG4 meeting #110-eC4-223abc
[0478] Electronic Conference, May 12-20, 2022
[0479]
[0480]
[0481]
[0482] ****First Change****
[0483] 5.6.2.2 ContextCreate
[0484] The NF service consumer (e.g. MB-SMF) shall use the ContextCreate service operation to request the AMF to create a broadcast MBS session context.
[0485] It is used in the following processes:
[0486] - Broadcast MBS session start (see clause 7.3.1 of 3GPP TS 23.247
[55] );
[0487] - Support of local broadcast services (see clause 7.3.4 of 3GPP TS 23.247
[55] ).
[0488] There shall be only one broadcast MBS session context per MBS session, or for MBS sessions with location dependent broadcast services, there shall be only one broadcast MBS session context per MBS session and regional session ID.
[0489] NF service consumer (e.g., MB-SMF) shall create a broadcast MBS session context by using the HTTP POST method as Fig.18 shown.
[0490] Fig.18 : Broadcast MBS session context creation
[0491] 1. The NF service consumer shall send a POST request for the broadcast MBS session context collection resource to the AMF. The payload body of the POST request shall contain the following information:
[0492] -MBS session ID (i.e. TMGI, or TMGI and NID for an MBS session in a SNPN);
[0493] - Regional Session ID, if this is a location dependent broadcast MBS service;
[0494] -MBS service area;
[0495] - N2 MBS session management container (see MBS session information setup request transport IE in 3GPP TS 38.413
[12] ); and
[0496] - Notification URI used to notify the state change of the broadcast MBS session context.
[0497] The NF service consumer may also include a maxResponseTime IE in the request to indicate the maximum response time for receiving information related to completing the broadcast MBS session establishment.
[0498] MB-SMF may include a list of NG-RAN IDs to be included in the original AMF in Namf_MBSBroadcast_ Requesting the alternative AMF to establish a broadcasting service in the NG-RAN when reporting that the NG-RAN cannot be contacted in the ContextStatusNotify request message Play MBS session.
[0499] 2a. On success, a 201 Created response shall be returned. The AMF shall respond successfully when the first successful response from the NG-RAN is received. If additional information needs to be transferred to the MB-SMF (e.g., the MBS Session Information Response Transfer IE or the MBS Session Information Failure Transfer IE in 3GPP TS 38.413
[12] ), the 201 Created response may contain one or more N2 MBS Session Management containers. If the AMF receives NG-RAN responses from all involved NG-RANs (e.g., if the broadcast MBS session involves only one NG-RAN), the AMF shall include in the 201 Created response an indication that the operation is completed in all NG-RANs.
[0500] Upon receiving subsequent responses from other NG-RANs after sending a 201 Created response, if additional information needs to be transferred to the MB-SMF (e.g., the MBS Session Information Response Transfer IE or the MBS Session Information Failure Transfer IE in 3GPP TS 38.413
[12] ), the AMF shall transfer such information by sending one or more Namf_MBSBroadcast_ContextStatusNotify requests to the MB-SMF. The Namf_MBSBroadcast_ContextStatusNotify request may include a list of N2 MBS Session Management Containers received from different NG-RANs. When the AMF receives responses from all NG-RANs, the AMF shall include an indication of the completion of the operation in the Namf_MBSBroadcast_ContextStatusNotify request.
[0501] If the AMF does not receive a response from all NG-RAN nodes before the maximum response time has elapsed since receipt of the Namf_MBSBroadcast_ContextCreate request, the AMF shall send a Namf_MBSBroadcast_ContextStatusNotify request indicating that the broadcast MBS session establishment is not completed.
[0502] The AMF may send one or more Namf_ MBSBroadcast_ContextStatusNotify request to report to the MB-SMF that one or more NG-RANs cannot be reached.
[0503] 2b. On failure or redirection, one of the HTTP status codes listed in Table 6.5.3.2.3.1-3 SHOULD be returned. For 4xx / 5xx responses, the message body SHOULD contain a ProblemDetails structure with the "reason" attribute set to one of the application errors listed in Table 6.5.3.2.3.1-3.
[0504] ****Next Change****
[0505] 5.6.2.3 ContextUpdate
[0506] The NF service consumer (e.g. MB-SMF) shall use the ContextUpdate service operation to request the AMF to update the broadcast MBS session context.
[0507] It is used in the following processes:
[0508] - Broadcast MBS Session Update (see clause 7.3.3 of 3GPP TS 23.247
[55] ).
[0509] - Broadcast MBS session resumption by MB-SMF (see clause 8.x.2.3 of 3GPP TS 23.527
[33] ).
[0510] NF service consumers (e.g., MB-SMF) shall use HTTP POST method to update the broadcast MBS session context, such as Fig.19 shown.
[0511] Fig.19 : Broadcast MBS session context update
[0512] 1. The NF Service Consumer shall send a POST request for a single broadcast MBS Session Context resource to be updated in the AMF. The payload body of the POST request may contain the following information:
[0513] - N2 MBS session management container (see MBS session information modification request transport IE in 3GPP TS 38.413
[12] );
[0514] - Notification URI, if the NF service consumer wishes to modify the notification URI, used to notify the broadcast MBS session context status change;
[0515] -Updated MBS service areas.
[0516] The NF service consumer may also include a maxResponseTime IE in the request to indicate the maximum response time for receiving information related to completing the broadcast MBS session update.
[0517] When the MBS session update is to be performed in the NG-RAN list identified by the NG-RAN ID, the MB-SMF may include a One or more NgranForUpdate attributes, where AMF can be requested to send NGAP MBS session establishment request, MBS session update request, A request for change or MBS session release, for example when the MB-SMF resumes a broadcast MBS session in a restarted NG-RAN (e.g. 3GPP TS 23.527
[33] , clause 8.x.2.3), or when the original AMF has been in Namf_MBSBroadcast_ When the ContextStatusNotify request message reports that the NG-RAN cannot be contacted. If the AMF is requested to send NGAP MBS session release request message, the AMF shall send a successful Namf_MBSBroadcast_ContextUpdate response The MBS session should then be deleted locally.
[0518] If MB-SMF detects that the original AMF has failed, it selects an alternative AMF to take over the MBS session without triggering If no NGAP signaling is present, MB-SMF may set noNgapSignallingIndication to "true".
[0519] 2a. On success, if additional information needs to be returned in this response, a "200 OK" shall be returned. If such information needs to be transferred to the MB-SMF (e.g., the MBS Session Information Response Transfer IE or the MBS Session Information Failure Transfer IE in 3GPP TS 38.413
[12] ), the "201 OK" response may contain one or more N2 MBS Session Management containers. If the AMF receives NG-RAN responses from all involved NG-RANs, the AMF shall include an indication that the operation is completed in all NG-RANs.
[0520] 2b. On success, if no additional information needs to be returned in the response, a 204 No Content should be returned.
[0521] In both cases 2a and 2b, when subsequent responses are received from other NG-RANs after sending a "200 OK" response or a "204 No Content" response, if additional information (e.g., MBS Session Information Response Transport IE or MBS Session Information Failure Transport IE in 3GPP TS 38.413
[12] ) needs to be sent to the MB-SMF, the AMF shall transmit such information by sending one or more Namf_MBSBroadcast_ContextStatusNotify requests to the MB-SMF. The Namf_MBSBroadcast_ContextStatusNotify request may include a list of N2 MBS Session Management Containers received from different NG-RANs. When the AMF receives responses from all NG-RANs, the AMF shall include an indication of the completion of the operation in the Namf_MBSBroadcast_ContextStatusNotify request.
[0522] If the AMF does not receive a response from all NG-RAN nodes before the maximum response time has elapsed since receipt of the Namf_MBSBroadcast_ContextUpdate request, the AMF shall send a Namf_MBSBroadcast_ContextStatusNotify request indicating that the broadcast MBS session update was not completed.
[0523] The AMF may send one or more Namf_ MBSBroadcast_ContextStatusNotify request to report to the MB-SMF that one or more NG-RANs cannot be reached.
[0524] 2c. On failure or redirection, one of the HTTP status codes listed in Table 6.5.3.2.4.2.2-2 SHOULD be returned. For 4xx / 5xx responses, the message body SHOULD contain a ProblemDetails structure with the "reason" attribute set to one of the application errors listed in Table 6.5.3.2.4.2.2-2.
[0525] ****Next Change****
[0526] 5.6.2.4ContextRelease
[0527] The NF service consumer (e.g., MB-SMF) shall use the ContextRelease service operation to request the AMF to release the broadcast MBS session context.
[0528] It is used in the following processes:
[0529] - Broadcast MBS session release (see clause 7.3.2 of 3GPP TS 23.247
[55] ).
[0530] NF service consumers (e.g., MB-SMF) shall use the HTTP DELETE method to release the broadcast MBS session context, such as Fig. 20 shown.
[0531] Fig. 20 : Broadcast MBS session context creation
[0532] 1. The NF Service Consumer shall send a DELETE request for a single Broadcast MBS Session Context resource to be released in the AMF.
[0533] 2a. On success, SHOULD return 204 No Content.
[0534] 2b. On failure or redirection, one of the HTTP status codes listed in Table 6.5.3.3.3.1-3 SHOULD be returned. For 4xx / 5xx responses, the message body SHOULD contain a ProblemDetails structure with the "reason" attribute set to one of the application errors listed in Table 6.5.3.3.3.1-3.
[0535] The AMF may send one or more Namf_ MBSBroadcast_ContextStatusNotify request to report to the MB-SMF that one or more NG-RANs cannot be reached.
[0536] ****Next Change****
[0537] 5.6.2.5ContextStatusNotify
[0538] The AMF shall use the ContextStatusNotify service operation to notify the NF service consumer (e.g., MB-SMF) of the status change of the Broadcast MBS Session Context.
[0539] It is used in the following processes:
[0540] - Broadcast MBS session start (see clause 7.3.1 of 3GPP TS 23.247
[55] );
[0541] - Broadcast MBS Session Update (see clause 7.3.3 of 3GPP TS 23.247
[55] ).
[0542] - Broadcast MBS session resumption by MB-SMF (see clause 8.x.2.3 of 3GPP TS 23.527
[33] ).
[0543] The AMF shall notify the NF service consumer (e.g., MB-SMF) of the state change of the Broadcast MBS Session Context by using the HTTP POST method, as Fig.21 shown.
[0544] Fig.21 : Broadcast MBS session context state change notification
[0545] 1. The AMF shall send a POST request to the Notification URI received from the NF Service Consumer. The payload body of the POST request shall contain the following information:
[0546] -MBS session ID (i.e. TMGI, or TMGI and NID for an MBS session in a SNPN);
[0547] - Regional Session ID, if this is a location dependent broadcast MBS service;
[0548] - one or more N2 MBS Session Management containers (if N2 MBS Session Management information has been received from one or more NG-RANs that needs to be transferred to the NF Service Consumer);
[0549] - If the NF Service Consumer has requested to establish or update a broadcast MBS session context and responses have been received from all NG-RANs, the operationStatus IE indicates completion of the broadcast MBS session establishment or update; and
[0550] - If the NF Service Consumer has requested to establish or update a broadcast MBS session context including a maximum response time, and the AMF has not received responses from all NG-RANs before the maximum response time has elapsed, the operationStatus IE indicates that the broadcast MBS session establishment or update is not completed.
[0551] The AMF may include the ngranFailureEvents attribute in the MBS context status notification request to notify the MB- The SMF reports NG-RAN failure events (e.g. NG-RAN failure with or without restart).
[0552] 2a. On success, the NF Service Consumer SHOULD return a "204 No Content" response.
[0553] 2b. On failure or redirection, one of the HTTP status codes listed in Table 6.5.5.2.3.1-3 should be returned, and appropriate additional error information should be returned.
[0554] ****Next Change****
[0555] 6.5.6.1 Overview
[0556] This clause specifies the application data model supported by the API.
[0557] Table 6.5.6.1-1 specifies the data types defined for the interface protocol based on Namf_MBSBroadcast service.
[0558] Table 6.5.6.1-1: Namf_MBSBroadcast specific data types
[0559]
[0560] Table 6.5.6.1-2 specifies the data types from other specifications that are reused by the NAMF service-based interface protocol, including references to their respective specifications and, where required, a brief description of their use within the NAMF service-based interface.
[0561] Table 6.5.6.1-2: Data types reused by Namf
[0562]
[0563] ****Next Change****
[0564] 6.5.6.2.2 Type: ContextCreateReqData
[0565] Table 6.5.6.2.2-1: Definition of type ContextCreateReqData
[0566]
[0567] ****Next Change****
[0568] 6.5.6.2.5 Type: ContextUpdateReqData
[0569] Table 6.5.6.2.5-1: Definition of ContextUpdateReqData type
[0570]
[0571] ****Next Change****
[0572] 6.5.6.2.4 Type: ContextStatusNotification
[0573] Table 6.5.6.2.4-1: Definition of type ContextStatusNotification
[0574]
[0575] ****Next Change****
[0576] 6.5.6.2.7 Type: N2MbsSmInfo
[0577] Table 6.5.6.2.7-1: Definition of type N2MbsSmInfo
[0578]
[0579] ****Next Change****
[0580] 6.5.6.2.x Type: NgranFailureEvent
[0581] Table 6.5.6.2.x-1: Definition of type NgranFailureEvent
[0582]
[0583] ****Next Change****
[0584] 6.5.6.2.y Type: NgranForUpdate
[0585] Table 6.5.6.2.y-1: Definition of type NgranForUpdate
[0586]
[0587] ****Next Change****
[0588] 6.5.6.3.z Enumeration: NgranFailureIndication
[0589] Enumeration NgranFailureIndication indicates NG-RAN failure events.
[0590] Table 6.5.6.3.z-1: Enumeration NgranFailureIndication
[0591]
[0592] ****Next Change****
[0593] 6.5.6.3.a Enumeration: NgapSignallingTypeForUpdate
[0594] Enumeration NgapMessageTypeForUpdate indicates to AMF when it receives an MBS context update request from MB-SMF Whether to send an MBS Session Setup Request message or an MBS Session Modification Request message to the NG-RAN identified by the NG-RAN ID. Ask for news.
[0595] Table 6.5.6.3.a-1: Enumeration NgapSignallingTypeForUpdate
[0596]
[0597] ****Next Change****
[0598] A.6Namf_MBSBroadcastAPI
[0599] openapi: 3.0.0
[0600] info:
[0601] version: 1.0.0-alpha.2
[0602] title: Namf_MBSBroadcast
[0603] description: |
[0604] AMF MBSBroadcast Service
[0605] © 2022, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI,TSDSI, TTA, TTC).
[0606] All rights reserved.
[0607] externalDocs:
[0608] description: 3GPP TS 29.518 V17.5.0; 5G System; Access and MobilityManagement Services
[0609] url: 'https: / / www.3gpp.org / ftp / Specs / archive / 29_series / 29.518 / '
[0610] servers:
[0611] - url: '{apiRoot} / namf-mbs-bc / v1'
[0612] variables:
[0613] apiRoot:
[0614] default: https: / / example.com
[0615] description: apiRoot as defined in clause clause 4.4 of 3GPPTS 29.501
[0616] security:
[0617] - {}
[0618] - oAuth2ClientCredentials:
[0619] - namf-mbs-bc
[0620] paths:
[0621] / mbs-contexts:
[0622] post:
[0623] summary: Namf_MBSBroadcast ContextCreate service Operation
[0624] tags:
[0625] - Broadcast MBS session contexts collection (Collection)
[0626] operationId: ContextCreate
[0627] requestBody:
[0628] content:
[0629] multipart / related: # message with binary body part(s)
[0630] schema:
[0631] type: object
[0632] properties: # Request parts
[0633] jsonData:
[0634] $ref: '# / components / schemas / ContextCreateReqData'
[0635] binaryDataN2Information:
[0636] type: string
[0637] format: binary
[0638] encoding:
[0639] jsonData:
[0640] contentType: application / json
[0641] binaryDataN2Information:
[0642] contentType: application / vnd.3gpp.ngap
[0643] headers:
[0644] Content-Id:
[0645] schema:
[0646] type: string
[0647] required: true
[0648] callbacks:
[0649] contextStatusNotification:
[0650] '{$request.body# / notifyUri}':
[0651] post:
[0652] requestBody: # notification request without binarybody part
[0653] required: true
[0654] content:
[0655] application / json:
[0656] schema:
[0657] $ref: '# / components / schemas / ContextStatusNotification'
[0658] multipart / related: # notification request withbinary body part(s)
[0659] schema:
[0660] type: object
[0661] properties: # Request parts
[0662] jsonData:
[0663] $ref: '# / components / schemas / ContextStatusNotification'
[0664] binaryDataN2Information1:
[0665] type: string
[0666] format: binary
[0667] binaryDataN2Information2:
[0668] type: string
[0669] format: binary
[0670] binaryDataN2Information3:
[0671] type: string
[0672] format: binary
[0673] binaryDataN2Information4:
[0674] type: string
[0675] format: binary
[0676] binaryDataN2Information5:
[0677] type: string
[0678] format: binary
[0679] binaryDataN2Information6:
[0680] type: string
[0681] format: binary
[0682] binaryDataN2Information7:
[0683] type: string
[0684] format: binary
[0685] binaryDataN2Information8:
[0686] type: string
[0687] format: binary
[0688] binaryDataN2Information9:
[0689] type: string
[0690] format: binary
[0691] binaryDataN2Information10:
[0692] type: string
[0693] format: binary
[0694] encoding:
[0695] jsonData:
[0696] contentType: application / json
[0697] binaryDataN2Information1:
[0698] contentType: application / vnd.3gpp.ngap
[0699] headers:
[0700] Content-Id:
[0701] schema:
[0702] type: string
[0703] binaryDataN2Information2:
[0704] contentType: application / vnd.3gpp.ngap
[0705] headers:
[0706] Content-Id:
[0707] schema:
[0708] type: string
[0709] binaryDataN2Information3:
[0710] contentType: application / vnd.3gpp.ngap
[0711] headers:
[0712] Content-Id:
[0713] schema:
[0714] type: string
[0715] binaryDataN2Information4:
[0716] contentType: application / vnd.3gpp.ngap
[0717] headers:
[0718] Content-Id:
[0719] schema:
[0720] type: string
[0721] binaryDataN2Information5:
[0722] contentType: application / vnd.3gpp.ngap
[0723] headers:
[0724] Content-Id:
[0725] schema:
[0726] type: string
[0727] binaryDataN2Information6:
[0728] contentType: application / vnd.3gpp.ngap
[0729] headers:
[0730] Content-Id:
[0731] schema:
[0732] type: string
[0733] binaryDataN2Information7:
[0734] contentType: application / vnd.3gpp.ngap
[0735] headers:
[0736] Content-Id:
[0737] schema:
[0738] type: string
[0739] binaryDataN2Information8:
[0740] contentType: application / vnd.3gpp.ngap
[0741] headers:
[0742] Content-Id:
[0743] schema:
[0744] type: string
[0745] binaryDataN2Information9:
[0746] contentType: application / vnd.3gpp.ngap
[0747] headers:
[0748] Content-Id:
[0749] schema:
[0750] type: string
[0751] binaryDataN2Information10:
[0752] contentType: application / vnd.3gpp.ngap
[0753] headers:
[0754] Content-Id:
[0755] schema:
[0756] type: string
[0757] responses:
[0758] '204':
[0759] description: successful notification
[0760] '307':
[0761] $ref: 'TS29571_CommonData.yaml# / components / responses / 307'
[0762] '308':
[0763] $ref: 'TS29571_CommonData.yaml# / components / responses / 308'
[0764] '400':
[0765] $ref: 'TS29571_CommonData.yaml# / components / responses / 400'
[0766] '403':
[0767] $ref: 'TS29571_CommonData.yaml# / components / responses / 403'
[0768] '404':
[0769] $ref: 'TS29571_CommonData.yaml# / components / responses / 404'
[0770] '411':
[0771] $ref: 'TS29571_CommonData.yaml# / components / responses / 411'
[0772] '413':
[0773] $ref: 'TS29571_CommonData.yaml# / components / responses / 413'
[0774] '415':
[0775] $ref: 'TS29571_CommonData.yaml# / components / responses / 415'
[0776] '429':
[0777] $ref: 'TS29571_CommonData.yaml# / components / responses / 429'
[0778] '500':
[0779] $ref: 'TS29571_CommonData.yaml# / components / responses / 500'
[0780] '503':
[0781] $ref: 'TS29571_CommonData.yaml# / components / responses / 503'
[0782] responses:
[0783] '201':
[0784] description: MBS Broadcast context created successfully
[0785] headers:
[0786] Location:
[0787] description: 'Contains the URI of the newly createdresource, according to the structure: {apiRoot} / namf-mbs-bc / <apiversion> / mbs-contexts / {mbsContextRef}'
[0788] required: true
[0789] schema:
[0790] type: string
[0791] content:
[0792] application / json: # message without binary body part(s)
[0793] schema:
[0794] $ref: '# / components / schemas / ContextCreateRspData'
[0795] multipart / related: # message with binary body part(s)
[0796] schema:
[0797] type: object
[0798] properties: # Response parts
[0799] jsonData:
[0800] $ref: '# / components / schemas / ContextCreateRspData'
[0801] binaryDataN2Information1:
[0802] type: string
[0803] format: binary
[0804] binaryDataN2Information2:
[0805] type: string
[0806] format: binary
[0807] binaryDataN2Information3:
[0808] type: string
[0809] format: binary
[0810] binaryDataN2Information4:
[0811] type: string
[0812] format: binary
[0813] binaryDataN2Information5:
[0814] type: string
[0815] format: binary
[0816] binaryDataN2Information6:
[0817] type: string
[0818] format: binary
[0819] binaryDataN2Information7:
[0820] type: string
[0821] format: binary
[0822] binaryDataN2Information8:
[0823] type: string
[0824] format: binary
[0825] binaryDataN2Information9:
[0826] type: string
[0827] format: binary
[0828] binaryDataN2Information10:
[0829] type: string
[0830] format: binary
[0831] encoding:
[0832] jsonData:
[0833] contentType: application / json
[0834] binaryDataN2Information1:
[0835] contentType: application / vnd.3gpp.ngap
[0836] headers:
[0837] Content-Id:
[0838] schema:
[0839] type: string
[0840] binaryDataN2Information2:
[0841] contentType: application / vnd.3gpp.ngap
[0842] headers:
[0843] Content-Id:
[0844] schema:
[0845] type: string
[0846] binaryDataN2Information3:
[0847] contentType: application / vnd.3gpp.ngap
[0848] headers:
[0849] Content-Id:
[0850] schema:
[0851] type: string
[0852] binaryDataN2Information4:
[0853] contentType: application / vnd.3gpp.ngap
[0854] headers:
[0855] Content-Id:
[0856] schema:
[0857] type: string
[0858] binaryDataN2Information5:
[0859] contentType: application / vnd.3gpp.ngap
[0860] headers:
[0861] Content-Id:
[0862] schema:
[0863] type: string
[0864] binaryDataN2Information6:
[0865] contentType: application / vnd.3gpp.ngap
[0866] headers:
[0867] Content-Id:
[0868] schema:
[0869] type: string
[0870] binaryDataN2Information7:
[0871] contentType: application / vnd.3gpp.ngap
[0872] headers:
[0873] Content-Id:
[0874] schema:
[0875] type: string
[0876] binaryDataN2Information8:
[0877] contentType: application / vnd.3gpp.ngap
[0878] headers:
[0879] Content-Id:
[0880] schema:
[0881] type: string
[0882] binaryDataN2Information9:
[0883] contentType: application / vnd.3gpp.ngap
[0884] headers:
[0885] Content-Id:
[0886] schema:
[0887] type: string
[0888] binaryDataN2Information10:
[0889] contentType: application / vnd.3gpp.ngap
[0890] headers:
[0891] Content-Id:
[0892] schema:
[0893] type: string
[0894] '307':
[0895] $ref: 'TS29571_CommonData.yaml# / components / responses / 307'
[0896] '308':
[0897] $ref: 'TS29571_CommonData.yaml# / components / responses / 308'
[0898] '400':
[0899] $ref: 'TS29571_CommonData.yaml# / components / responses / 400'
[0900] '401':
[0901] $ref: 'TS29571_CommonData.yaml# / components / responses / 401'
[0902] '403':
[0903] $ref: 'TS29571_CommonData.yaml# / components / responses / 403'
[0904] '404':
[0905] $ref: 'TS29571_CommonData.yaml# / components / responses / 404'
[0906] '411':
[0907] $ref: 'TS29571_CommonData.yaml# / components / responses / 411'
[0908] '413':
[0909] $ref: 'TS29571_CommonData.yaml# / components / responses / 413'
[0910] '415':
[0911] $ref: 'TS29571_CommonData.yaml# / components / responses / 415'
[0912] '429':
[0913] $ref: 'TS29571_CommonData.yaml# / components / responses / 429'
[0914] '500':
[0915] $ref: 'TS29571_CommonData.yaml# / components / responses / 500'
[0916] '502':
[0917] $ref: 'TS29571_CommonData.yaml# / components / responses / 502'
[0918] '503':
[0919] $ref: 'TS29571_CommonData.yaml# / components / responses / 503'
[0920] default:
[0921] $ref: 'TS29571_CommonData.yaml# / components / responses / default'
[0922] / mbs-contexts / {mbsContextRef}:
[0923] delete:
[0924] summary: Namf_MBSBroadcast ContextDelete service Operation
[0925] tags:
[0926] - Individual broadcast MBS session context (Document)
[0927] operationId: ContextDelete
[0928] parameters:
[0929] - name: mbsContextRef
[0930] in: path
[0931] required: true
[0932] description: Unique ID of the broadcast MSB session contextto be deleted
[0933] schema:
[0934] type: string
[0935] responses:
[0936] '204':
[0937] description: successful deletion
[0938] '307':
[0939] $ref: 'TS29571_CommonData.yaml# / components / responses / 307'
[0940] '308':
[0941] $ref: 'TS29571_CommonData.yaml# / components / responses / 308'
[0942] '400':
[0943] $ref: 'TS29571_CommonData.yaml# / components / responses / 400'
[0944] '401':
[0945] $ref: 'TS29571_CommonData.yaml# / components / responses / 401'
[0946] '403':
[0947] $ref: 'TS29571_CommonData.yaml# / components / responses / 403'
[0948] '404':
[0949] $ref: 'TS29571_CommonData.yaml# / components / responses / 404'
[0950] '429':
[0951] $ref: 'TS29571_CommonData.yaml# / components / responses / 429'
[0952] '500':
[0953] $ref: 'TS29571_CommonData.yaml# / components / responses / 500'
[0954] '502':
[0955] $ref: 'TS29571_CommonData.yaml# / components / responses / 502'
[0956] '503':
[0957] $ref: 'TS29571_CommonData.yaml# / components / responses / 503'
[0958] default:
[0959] $ref: 'TS29571_CommonData.yaml# / components / responses / default'
[0960] / mbs-contexts / {mbsContextRef} / update:
[0961] post:
[0962] summary: Namf_MBSBroadcast ContextUpdate service Operation
[0963] tags:
[0964] - Individual broadcast MBS session context (Document)
[0965] operationId: ContextUpdate
[0966] parameters:
[0967] - name: mbsContextRef
[0968] in: path
[0969] description: Unique ID of the broadcast MSB session contextto be updated
[0970] required: true
[0971] schema:
[0972] type: string
[0973] requestBody:
[0974] content:
[0975] multipart / related: # message with binary body part(s)
[0976] schema:
[0977] type: object
[0978] properties: # Request parts
[0979] jsonData:
[0980] $ref: '# / components / schemas / ContextUpdateReqData'
[0981] binaryDataN2Information:
[0982] type: string
[0983] format: binary
[0984] encoding:
[0985] jsonData:
[0986] contentType: application / json
[0987] binaryDataN2Information:
[0988] contentType: application / vnd.3gpp.ngap
[0989] headers:
[0990] Content-Id:
[0991] schema:
[0992] type: string
[0993] required: true
[0994] responses:
[0995] '200':
[0996] description: MBS Broadcast context updated successfully
[0997] content:
[0998] application / json: # message without binary body part(s)
[0999] schema:
[1000] $ref: '# / components / schemas / ContextUpdateRspData'
[1001] multipart / related: # message with binary body part(s)
[1002] schema:
[1003] type: object
[1004] properties: # Response parts
[1005] jsonData:
[1006] $ref: '# / components / schemas / ContextUpdateRspData'
[1007] binaryDataN2Information1:
[1008] type: string
[1009] format: binary
[1010] binaryDataN2Information2:
[1011] type: string
[1012] format: binary
[1013] binaryDataN2Information3:
[1014] type: string
[1015] format: binary
[1016] binaryDataN2Information4:
[1017] type: string
[1018] format: binary
[1019] binaryDataN2Information5:
[1020] type: string
[1021] format: binary
[1022] binaryDataN2Information6:
[1023] type: string
[1024] format: binary
[1025] binaryDataN2Information7:
[1026] type: string
[1027] format: binary
[1028] binaryDataN2Information8:
[1029] type: string
[1030] format: binary
[1031] binaryDataN2Information9:
[1032] type: string
[1033] format: binary
[1034] binaryDataN2Information10:
[1035] type: string
[1036] format: binary
[1037] encoding:
[1038] jsonData:
[1039] contentType: application / json
[1040] binaryDataN2Information1:
[1041] contentType: application / vnd.3gpp.ngap
[1042] headers:
[1043] Content-Id:
[1044] schema:
[1045] type: string
[1046] binaryDataN2Information2:
[1047] contentType: application / vnd.3gpp.ngap
[1048] headers:
[1049] Content-Id:
[1050] schema:
[1051] type: string
[1052] binaryDataN2Information3:
[1053] contentType: application / vnd.3gpp.ngap
[1054] headers:
[1055] Content-Id:
[1056] schema:
[1057] type: string
[1058] binaryDataN2Information4:
[1059] contentType: application / vnd.3gpp.ngap
[1060] headers:
[1061] Content-Id:
[1062] schema:
[1063] type: string
[1064] binaryDataN2Information5:
[1065] contentType: application / vnd.3gpp.ngap
[1066] headers:
[1067] Content-Id:
[1068] schema:
[1069] type: string
[1070] binaryDataN2Information6:
[1071] contentType: application / vnd.3gpp.ngap
[1072] headers:
[1073] Content-Id:
[1074] schema:
[1075] type: string
[1076] binaryDataN2Information7:
[1077] contentType: application / vnd.3gpp.ngap
[1078] headers:
[1079] Content-Id:
[1080] schema:
[1081] type: string
[1082] binaryDataN2Information8:
[1083] contentType: application / vnd.3gpp.ngap
[1084] headers:
[1085] Content-Id:
[1086] schema:
[1087] type: string
[1088] binaryDataN2Information9:
[1089] contentType: application / vnd.3gpp.ngap
[1090] headers:
[1091] Content-Id:
[1092] schema:
[1093] type: string
[1094] binaryDataN2Information10:
[1095] contentType: application / vnd.3gpp.ngap
[1096] headers:
[1097] Content-Id:
[1098] schema:
[1099] type: string
[1100] '307':
[1101] $ref: 'TS29571_CommonData.yaml# / components / responses / 307'
[1102] '308':
[1103] $ref: 'TS29571_CommonData.yaml# / components / responses / 308'
[1104] '400':
[1105] $ref: 'TS29571_CommonData.yaml# / components / responses / 400'
[1106] '401':
[1107] $ref: 'TS29571_CommonData.yaml# / components / responses / 401'
[1108] '403':
[1109] $ref: 'TS29571_CommonData.yaml# / components / responses / 403'
[1110] '404':
[1111] $ref: 'TS29571_CommonData.yaml# / components / responses / 404'
[1112] '411':
[1113] $ref: 'TS29571_CommonData.yaml# / components / responses / 411'
[1114] '413':
[1115] $ref: 'TS29571_CommonData.yaml# / components / responses / 413'
[1116] '415':
[1117] $ref: 'TS29571_CommonData.yaml# / components / responses / 415'
[1118] '429':
[1119] $ref: 'TS29571_CommonData.yaml# / components / responses / 429'
[1120] '500':
[1121] $ref: 'TS29571_CommonData.yaml# / components / responses / 500'
[1122] '502':
[1123] $ref: 'TS29571_CommonData.yaml# / components / responses / 502'
[1124] '503':
[1125] $ref: 'TS29571_CommonData.yaml# / components / responses / 503'
[1126] default:
[1127] $ref: 'TS29571_CommonData.yaml# / components / responses / default'
[1128] components:
[1129] securitySchemes:
[1130] oAuth2ClientCredentials:
[1131] type: oauth2
[1132] flows:
[1133] clientCredentials:
[1134] tokenUrl: '{nrfApiRoot} / oauth2 / token'
[1135] scopes:
[1136] namf-mbs-bc: Access to the Namf_MBSBroadcast API
[1137] schemas:
[1138] #
[1139] # STRUCTURED DATA TYPES
[1140] #
[1141] ContextCreateReqData:
[1142] description: Data within ContextCreate Request
[1143] type: object
[1144] properties:
[1145] mbsSessionId:
[1146] $ref: 'TS29571_CommonData.yaml# / components / schemas / MbsSessionId'
[1147] areaSessionId:
[1148] $ref: 'TS29571_CommonData.yaml# / components / schemas / AreaSessionId'
[1149] mbsServiceArea:
[1150] $ref: 'TS29571_CommonData.yaml# / components / schemas / MbsServiceArea'
[1151] n2MbsSmInfo:
[1152] $ref: '# / components / schemas / N2MbsSmInfo'
[1153] notifyUri:
[1154] $ref: 'TS29571_CommonData.yaml# / components / schemas / Uri'
[1155] maxResponseTime:
[1156] $ref: 'TS29571_CommonData.yaml# / components / schemas / DurationSec'
[1157] ngranIdList:
[1158] type: array
[1159] Items:
[1160] $ref: 'TS29571_CommonData.yaml# / components / schemas / GlobalRanNodeId'
[1161] required:
[1162] - mbsSessionId
[1163] - mbsServiceArea
[1164] - ngapData
[1165] - notifyUri
[1166] ContextCreateRspData:
[1167] description: Data within ContextCreate Response
[1168] type: object
[1169] properties:
[1170] n2MbsSmInfoList:
[1171] type: array
[1172] items:
[1173] $ref: '# / components / schemas / N2MbsSmInfo'
[1174] minItems: 1
[1175] maxItems: 10
[1176] operationStatus:
[1177] $ref: '# / components / schemas / OperationStatus'
[1178] ContextUpdateReqData:
[1179] description: Data within ContextUpdate Request
[1180] type: object
[1181] properties:
[1182] mbsServiceArea:
[1183] $ref: 'TS29571_CommonData.yaml# / components / schemas / MbsServiceArea'
[1184] n2MbsSmInfo:
[1185] $ref: '# / components / schemas / N2MbsSmInfo'
[1186] ngranForUpdateList:
[1187] type: array
[1188] Items:
[1189] $ref: '# / components / schemas / NgranForUpdate'
[1190] noNgapSignallingInd:
[1191] type: boolean
[1192] default: false
[1193] relMbsSessionInd:
[1194] type: boolean
[1195] default: false
[1196] notifyUri:
[1197] $ref: 'TS29571_CommonData.yaml# / components / schemas / Uri'
[1198] maxResponseTime:
[1199] $ref: 'TS29571_CommonData.yaml# / components / schemas / DurationSec'
[1200] ContextStatusNotification:
[1201] description: Data within ContextStatusNotify Request
[1202] type: object
[1203] properties:
[1204] mbsSessionId:
[1205] $ref: 'TS29571_CommonData.yaml# / components / schemas / MbsSessionId'
[1206] areaSessionId:
[1207] $ref: 'TS29571_CommonData.yaml# / components / schemas / AreaSessionId'
[1208] n2MbsSmInfoList:
[1209] type: array
[1210] items:
[1211] $ref: '# / components / schemas / N2MbsSmInfo'
[1212] minItems: 1
[1213] maxItems: 10
[1214] ngranFailureEvents:
[1215] type: array
[1216] items:
[1217] $ref: '# / components / schemas / NgranFailureEvent'
[1218] operationStatus:
[1219] $ref: '# / components / schemas / OperationStatus'
[1220] required:
[1221] - mbsSessionId
[1222] ContextUpdateRspData:
[1223] description: Data within ContextUpdate Response
[1224] type: object
[1225] properties:
[1226] n2MbsSmInfoList:
[1227] type: array
[1228] items:
[1229] $ref: '# / components / schemas / N2MbsSmInfo'
[1230] minItems: 1
[1231] maxItems: 10
[1232] operationStatus:
[1233] $ref: '# / components / schemas / OperationStatus'
[1234] N2MbsSmInfo:
[1235] description: N2 MBS Session Management information
[1236] type: object
[1237] properties:
[1238] ngapIeType:
[1239] $ref: '# / components / schemas / NgapIeType'
[1240] ngranId:
[1241] $ref: 'TS29571_CommonData.yaml# / components / schemas / GlobalRanNodeId'
[1242] ngapData:
[1243] $ref: 'TS29571_CommonData.yaml# / components / schemas / RefToBinaryData'
[1244] NgranFailureEvent:
[1245] description: NG-RAN failure event for a NG-RAN
[1246] type: object
[1247] properties:
[1248] ngranId:
[1249] $ref: 'TS29571_CommonData.yaml# / components / schemas / GlobalRanNodeId'
[1250] ngranFailureIndication:
[1251] $ref: '# / components / schemas / NgranFailureIndication'
[1252] NgranForUpdate:
[1253] description: a list of NG-RANs for a MBS Session Update
[1254] type: object
[1255] properties:
[1256] ngranId:
[1257] $ref: 'TS29571_CommonData.yaml# / components / schemas / GlobalRanNodeId'
[1258] ngapSignallingTypeForUpdate:
[1259] $ref: '# / components / schemas / NgapSignallingTypeForUpdate'
[1260] #
[1261] # SIMPLE DATA TYPES
[1262] #
[1263] #
[1264] # ENUMERATIONS
[1265] #
[1266] OperationStatus:
[1267] description: Status of a Broadcast MBS session start or updateoperation.
[1268] anyOf:
[1269] - type: string
[1270] enum:
[1271] - MBS_SESSION_START_COMPLETE
[1272] - MBS_SESSION_START_INCOMPLETE
[1273] - MBS_SESSION_UPDATE_COMPLETE
[1274] - MBS_SESSION_UPDATE_INCOMPLETE
[1275] - type: string
[1276] NgapIeType:
[1277] description: NGAP Information Element Type
[1278] anyOf:
[1279] - type: string
[1280] enum:
[1281] - MBS_SES_SETUP_REQ
[1282] - MBS_SES_RSP
[1283] - MBS_SES_FAIL
[1284] - MBS_SES_MOD_REQ
[1285] - type: string
[1286] NgranFailureIndication:
[1287] description: Indicates a NG-RAN failure event.
[1288] anyOf:
[1289] - type: string
[1290] enum:
[1291] - NG_RAN_RESTART_OR_START
[1292] - NG_RAN_FAILURE_WITHOUT_RESTART
[1293] - NG_RAN_NOT_REACHABLE_AT_SETUP
[1294] - NG_RAN_NOT_REACHABLE_AT_MODIFICATION
[1295] - NG_RAN_NOT_REACHABLE_AT_RELEASE
[1296] - type: string
[1297] NgapSignallingTypeForUpdate:
[1298] description: instruct the AMF to send a MBS Session Setup or Modification or Release Request.
[1299] anyOf:
[1300] - type: string
[1301] enum:
[1302] - MBS_SESSION_SETUP_REQUEST
[1303] - MBS_SESSION_MODIFICATION_REQUEST
[1304] - MBS_SESSION_RELEASE_REQUEST
[1305] - type: string
[1306] ****END OF CHANGES****.< / apiversion>
Claims
1. A method (1100) at an AMF (225-2) for facilitating an MB-SMF (235) to resume a broadcast session, the method (1100) comprising: An eleventh message is received (S825, S1110) from the MB-SMF (235), the eleventh message comprising an indication that the eleventh message will provide information associated with the broadcast session, the information being used only for subsequent resumption of the broadcast session when one or more RAN nodes (205) are restarted.
2. The method (1100) according to claim 1, wherein: The eleventh message indicates at least one of the following items: - an identifier of the broadcast session; - the service area associated with the broadcast session; - information required for subsequent resumption of the broadcast session; as well as - a resume indication indicating that the AMF (225-2) will not trigger any NG Application Protocol (NGAP) signaling to the one or more RAN nodes (205) for resuming the broadcast session.
3. The method (1100) according to claim 2, wherein: When the recovery indication is set to "true" and the service area is indicated by the eleventh message, the AMF is requested not to trigger any NGAP signaling towards one or more NG-RAN nodes covering the indicated service area.
4. The method (1100) according to any one of claims 1 to 3, wherein: The AMF (225-2) and another AMF (225-1) used for resumption of the broadcast session belong to the same AMF set and / or the same AMF service set.
5. The method (1100) according to any one of claims 1 to 4, further comprising: A twelfth message is sent (S830) to the MB-SMF (235), the twelfth message responding to the eleventh message and indicating that the AMF (225-2) has taken over the broadcast session from the other AMF (225-1).
6. The method (1100) according to any one of claims 1 to 5, wherein: The broadcast session is an MBS session.
7. The method (1100) according to any one of claims 1 to 6, wherein: At least one of the following is true: - The eleventh message is a Namf_MBSBroadcast_ContextUpdate request message; and - The twelfth message is the Namf_MBSBroadcast_ContextUpdate response message.
8. A first network node (225-2, 1300, 1600), comprising: Processor (1306); A memory (1308) storing instructions, which, when executed by the processor (1306), cause the processor (1306) to perform the method (1100) according to any one of claims 1 to 7.
9. The first network node (225-2, 1300, 1600) according to claim 8, wherein: The AMF is hosted at the first network node (225-2, 1300, 1600).
10. A method (1200) at an MB-SMF (235) for resuming a broadcast session, the method (1200) comprising: determining ( S815 , S1210 ) whether the first AMF ( 225 - 1 ) is unable to provide service for the broadcast session; Determining (S820, S1220) that the second AMF (225-2) takes over the broadcast session from the first AMF (225-1); as well as sending (S825, S1230) an eleventh message to the second AMF (225-2), the eleventh message comprising an indication that the eleventh message will provide information associated with the broadcast session, the information being used only for subsequent resumption of the broadcast session when one or more RAN nodes (205) are restarted.
11. The method (1200) of claim 10, wherein: The eleventh message indicates at least one of the following items: - an identifier of the broadcast session; - the service area associated with the broadcast session; - information required by the second AMF (225-2) to subsequently resume the broadcast session; as well as - a resume indication indicating that the second AMF (225-2) shall not trigger any NGAP signaling to the one or more RAN nodes (205) for the resume broadcast session.
12. The method (1200) of claim 11, wherein: When the recovery indication is set to "true" and the service area is indicated by the eleventh message, the second AMF is requested not to trigger any NGAP signaling towards one or more NG-RAN nodes covering the indicated service area.
13. The method (1200) according to any one of claims 10 to 12, wherein: The first AMF (225-1) and the second AMF (225-2) belong to the same AMF set and / or the same AMF service set.
14. The method (1200) according to any one of claims 10 to 13, further comprising: A twelfth message is received (S830) from the second AMF (225-2), the twelfth message replying to the eleventh message and indicating that the AMF (225-2) has taken over the broadcast session from the first AMF (225-1).
15. The method (1200) according to any one of claims 10 to 14, wherein: The step of determining (S815, S1210) whether the first AMF (225-1) is unable to provide service for the broadcast session comprises: It is detected ( S815 ) whether the first AMF ( 225 - 1 ) is unable to provide service for the broadcast session by using a Hypertext Transfer Protocol Version 2 'HTTP / 2' Ping frame.
16. The method (1200) according to any one of claims 10 to 15, wherein: Before the step of determining (S815, S1210) whether the first AMF (225-1) is unable to provide service for the broadcast session, the method (1200) further comprises: subscribing to a Network Repository Function NRF (260) to receive notifications of changes to configuration files of said first AMF (225-1), The step of determining (S815, S1210) whether the first AMF (225-1) is unable to provide services for the broadcast session includes: Receiving a notification of a change of a configuration file of the first AMF (225-1) from the NRF (260), the notification indicating that the first AMF (225-1) cannot provide service for the broadcast session.
17. The method (1200) according to any one of claims 10 to 16, wherein: The broadcast session is an MBS session.
18. The method (1200) according to any one of claims 10 to 17, wherein: At least one of the following is true: - The eleventh message is a Namf_MBSBroadcast_ContextUpdate request message; and - The twelfth message is the Namf_MBSBroadcast_ContextUpdate response message.
19. A second network node (235, 1300, 1700), comprising: Processor (1306); A memory (1308) storing instructions which, when executed by the processor (1306), cause the processor (1306) to perform the method (1200) according to any one of claims 10 to 18.
20. The second network node (235, 1200, 1700) according to claim 19, wherein: The MB-SMF is hosted at the second network node (235, 1200, 1700).
21. A method (900) at an access and mobility management function (AMF) (225) for facilitating a multicast / broadcast session management function (MB-SMF) (235) to attempt multicast session signaling for a multicast session or broadcast session signaling for a broadcast session, the method (900) comprising: determining ( S615 , S910 ) whether the AMF ( 225 - 1 ) is unable to contact one or more radio access network RAN nodes ( 205 ) for the multicast session or the broadcast session; as well as In response to determining that the AMF (225-1) is unable to contact at least one first RAN node (205-1) of the one or more RAN nodes (205) for the multicast session or the broadcast session, a first message indicating the at least one first RAN node (205-1) is sent (S635, S920) to the MB-SMF (235).
22. The method (900) of claim 21, wherein: Prior to the step of determining (S615, S620, S910) whether the AMF (225-1) is unable to contact one or more RAN nodes (205) for the multicast session or the broadcast session, the method (900) further comprises: sending (S615) a second message associated with the multicast session or the broadcast session to each of the one or more RAN nodes (205), The step of determining that the AMF (225-1) is unable to contact the at least one first RAN node (205-1) comprises: It is determined (S615) that the at least one first RAN node has not responded to the second message within a certain period of time.
23. The method (900) according to claim 21 or 22, wherein: The step of determining that the AMF (225-1) is unable to contact the at least one first RAN node (205-1) comprises: It is determined (S615) that there is a failure in a path towards the at least one first RAN node (205-1).
24. The method (900) according to any one of claims 21 to 23, wherein: The first message indicates at least one of the following: - at least one identifier of the at least one first RAN node (205-1); - an identifier of the multicast session or broadcast session; and - an indication indicating that the at least one first RAN node (205-1) cannot be contacted.
25. The method (900) of claim 24, wherein: The indication further indicates at least one of the following: - whether the AMF (225-1) has detected the startup or restart of the corresponding NG-RAN; - whether the AMF (225-1) has detected a failure without the corresponding NG-RAN restarting; - Whether the AMF (225-1) is unable to reach the corresponding NG-RAN when sending the NGAP MBS Session Setup Request message; - Whether the AMF (225-1) is unable to reach the corresponding NG-RAN when sending the NGAP MBS Session Modification Request message; as well as - Whether the AMF (225-1) is unable to reach the corresponding NG-RAN when sending the NGAP MBS session release request message.
26. The method (900) according to any one of claims 21 to 25, further comprising: A third message in response to the first message is received (S640) from the MB-SMF (235).
27. The method (900) according to any one of claims 21 to 26, wherein: Prior to the step of determining (S615, S910) whether the AMF (225-1) is unable to contact one or more RAN nodes (205) for the multicast session or the broadcast session, the method (900) further comprises: A fourth message is received (S610) from the MB-SMF (235), the fourth message indicating that the AMF (225-1) is to contact the one or more RAN nodes (205) to perform operations associated with the multicast session or the broadcast session.
28. The method (900) of claim 27, wherein: The fourth message indicates at least one of the following: - an identifier of the multicast session or broadcast session; - a service area associated with the multicast session or broadcast session; and - Information associated with the multicast session or broadcast session to be delivered to the one or more RAN nodes (205).
29. The method (900) according to claim 27 or 28, wherein: The second message is sent in response to receiving the fourth message.
30. The method (900) according to any one of claims 21 to 29, further comprising: receiving (S620) a fifth message from each of at least one second RAN node (205-2, 205-3, 205-4) of the one or more RAN nodes (205) in response to sending the second message, the fifth message indicating whether an operation associated with the multicast session or the broadcast session is successfully performed; and Based at least on the fifth message, a sixth message is sent (S625) to the MB-SMF (235), the sixth message indicating whether the operation is successfully performed.
31. The method (900) according to any one of claims 21 to 30, further comprising: receiving (S650) a seventh message from the MB-SMF (235), the seventh message indicating one or more identifiers of one or more third RAN nodes (205-1) to be contacted by the AMF (225-2) to perform operations associated with another multicast session or broadcast session; sending (S655) an eighth message to each of the one or more third RAN nodes (205-1) based at least on the seventh message, the eighth message instructing the one or more third RAN nodes (205-1) to perform an operation associated with the other multicast session or broadcast session; in response to sending the eighth message, receiving (S660) at least one ninth message from at least one of the one or more third RAN nodes (205-1), the at least one ninth message indicating whether the corresponding at least one third RAN node (205-1) successfully performed an operation associated with the other multicast session or broadcast session; and Based at least on the ninth message, a tenth message is sent (S665) to the MB-SMF (235), the tenth message indicating whether an operation associated with the another multicast session or broadcast session is successfully performed.
32. The method (900) of claim 31, wherein: The seventh message indicates at least one signaling type respectively associated with at least one third RAN node of the one or more third RAN nodes (205-1).
33. The method (900) according to claim 31 or 32, wherein: The eighth message is a request message of the type indicated by the seventh message, and / or the corresponding ninth message is a response or failure message of the type indicated by the seventh message.
34. The method (900) according to any one of claims 31 to 33, wherein: The seventh message also indicates whether the multicast session or the broadcast session is to be released at the AMF (225-2) and / or the one or more third RAN nodes (205-1).
35. The method (900) according to any one of claims 30 to 34, wherein: At least one of the fifth message, the sixth message, the ninth message, and the tenth message further indicates unicast transport network layer TNL information used for shared delivery of the multicast session or the broadcast session.
36. The method (900) according to any one of claims 21 to 35, wherein: The multicast session or broadcast session is a multicast / broadcast service MBS session.
37. The method (900) according to any one of claims 21 to 36, wherein: When the multicast session or the broadcast session is a broadcast MBS session, at least one of the following conditions is true: - The first message is a Namf_MBSBroadcast_ContextStatusNotify request message; - the second message is one of a broadcast session setup request message, a broadcast session release request message and a broadcast session modification request message; - The third message is a Namf_MBSBroadcast_ContextStatusNotify response message; - The fourth message is one of a Namf_MBSBroadcast_ContextCreate request message, a Namf_MBSBroadcast_ContextRelease request message, and a Namf_MBSBroadcast_ContextUpdate request message; - the fifth message is one of a broadcast session setup response message, a broadcast session release response message and a broadcast session modification response message; - The sixth message is one of a Namf_MBSBroadcast_ContextCreate response message, a Namf_MBSBroadcast_ContextRelease response message, and a Namf_MBSBroadcast_ContextUpdate response message; - The seventh message is one of a Namf_MBSBroadcast_ContextCreate request message, a Namf_MBSBroadcast_ContextRelease request message, and a Namf_MBSBroadcast_ContextUpdate request message; - the eighth message is one of a broadcast session establishment request message, a broadcast session release request message and a broadcast session modification request message; - the ninth message is one of a broadcast session establishment response message, a broadcast session release response message and a broadcast session modification response message; as well as - The tenth message is one of a Namf_MBSBroadcast_ContextCreate response message, a Namf_MBSBroadcast_ContextRelease response message, and a Namf_MBSBroadcast_ContextUpdate response message.
38. A first network node (225, 1300, 1400), comprising: Processor (1306); A memory (1308) storing instructions which, when executed by the processor (1306), cause the processor (1306) to perform the method (900) according to any one of claims 21 to 37.
39. The first network node (225, 1300, 1400) according to claim 38, wherein: The AMF is hosted at a first network node (225, 1300, 1400).
40. A method (1000) at an MB-SMF (235) for attempting multicast session signaling for a multicast session or broadcast session signaling for a broadcast session, the method (1000) comprising: receiving (S635, S1010) a first message from a first AMF (225-1), the first message indicating that the first AMF (225-1) cannot contact at least one first RAN node (205-1) for the multicast session or the broadcast session; Determine (S645, S1020) a second AMF (225-2) that belongs to the same AMF set and / or the same AMF service set as the first AMF (225-1); as well as sending (S650, S1030) a seventh message to the second AMF (225-2), the seventh message indicating one or more identifiers of the at least one first RAN node (205-1), the at least one first RAN node (205-1) to be contacted by the second AMF (225-2) to perform operations associated with the multicast session or the broadcast session.
41. The method (1000) of claim 40, wherein: The first message indicates at least one of the following: - at least one identifier of the at least one first RAN node (205-1); - an identifier of the multicast session or broadcast session; and - an indication indicating that the at least one first RAN node (205-1) cannot be contacted at the first AMF (225-1).
42. The method (1000) of claim 41, wherein: The indication further indicates at least one of the following: - whether the first AMF (225-1) has detected the startup or restart of the corresponding NG-RAN; - whether the first AMF (225-1) has detected a failure without the corresponding NG-RAN being restarted; - Whether the first AMF (225-1) is unable to reach the corresponding NG-RAN when sending the NGAP MBS session establishment request message; - Whether the first AMF (225-1) has failed to reach the corresponding NG-RAN when sending the NGAP MBS session modification request message; as well as - Whether the first AMF (225-1) is unable to reach the corresponding NG-RAN when sending the NGAP MBS session release request message.
43. The method (1000) of claim 42, wherein: The seventh message is generated based at least on the received indication, such that the seventh message indicates at least one signaling type respectively associated with the at least one first RAN node (205-1).
44. The method (1000) according to any one of claims 40 to 43, wherein: The seventh message also indicates whether the multicast session or the broadcast session is to be released at the second AMF (225-2) and / or the at least one first RAN node (205-1).
45. The method (1000) according to any one of claims 40 to 44, further comprising: A third message in response to the first message is sent (S640) to the first AMF (225-1).
46. The method (1000) according to any one of claims 40 to 45, wherein: Before the step of receiving (S635, S1010) the first message, the method (1000) further includes: A fourth message is sent (S610) to the first AMF (225-1), the fourth message indicating that the first AMF (225-1) is to contact one or more RAN nodes (205) to perform operations associated with the multicast session or the broadcast session, the one or more RAN nodes (205) including the at least one first RAN node (205-1).
47. The method (1000) of claim 46, wherein: The fourth message indicates at least one of the following: - an identifier of the multicast session or broadcast session; - a service area associated with the multicast session or broadcast session; and - Information associated with the multicast session or broadcast session to be delivered to the one or more RAN nodes (205).
48. The method (1000) according to any one of claims 40 to 47, further comprising: A sixth message is received (S625) from the first AMF (225-1), the sixth message indicating whether the one or more RAN nodes (205) successfully performed an operation associated with the multicast session or the broadcast session.
49. The method (1000) according to any one of claims 40 to 48, further comprising: A tenth message is received (S665) from the second AMF (225-2), the tenth message indicating whether the at least one RAN node (205-1) successfully performs an operation associated with the multicast session or the broadcast session.
50. The method (1000) of claim 48 or 49, wherein: At least one of the sixth message and the tenth message further indicates unicast TNL information for shared delivery of the multicast session or the broadcast session.
51. The method (1000) of claim 50, further comprising: Communicating (S630, S670) with a multicast / broadcast user plane function MB-UPF (215) to provide unicast TNL information for shared transmission of the multicast session or broadcast session from the MB-UPF (215) to the one or more RAN nodes (205) or the at least one first RAN node (205-1).
52. The method (1000) according to any one of claims 40 to 51, wherein: The multicast session or broadcast session is an MBS session.
53. The method (1000) according to any one of claims 40 to 52, wherein: When the multicast session or the broadcast session is a broadcast MBS session, at least one of the following is true: - The first message is a Namf_MBSBroadcast_ContextStatusNotify request message; - The third message is a Namf_MBSBroadcast_ContextStatusNotify response message; - The fourth message is one of a Namf_MBSBroadcast_ContextCreate request message, a Namf_MBSBroadcast_ContextRelease request message, and a Namf_MBSBroadcast_ContextUpdate request message; - The sixth message is one of a Namf_MBSBroadcast_ContextCreate response message, a Namf_MBSBroadcast_ContextRelease response message, and a Namf_MBSBroadcast_ContextUpdate response message; - the seventh message is one of a Namf_MBSBroadcast_ContextCreate request message, a Namf_MBSBroadcast_ContextRelease request message, and a Namf_MBSBroadcast_ContextUpdate request message; and - The tenth message is one of a Namf_MBSBroadcast_ContextCreate response message, a Namf_MBSBroadcast_ContextRelease response message, and a Namf_MBSBroadcast_ContextUpdate response message.
54. A second network node (235, 1300, 1500), comprising: Processor (1306); A memory (1308) storing instructions which, when executed by the processor (1306), cause the processor (1306) to perform the method (1000) according to any one of claims 40 to 53.
55. The second network node (235, 1300, 1500) of claim 54, wherein: The MB-SMF is hosted at the second network node (235, 1300, 1500).
56. A computer program (1310) comprising instructions which, when executed by at least one processor (1306), cause the at least one processor (1306) to perform the method (900, 1000, 1100, 1200) according to any one of claims 1 to 7, 10 to 18, 21 to 37 and 40 to 53.
57. A carrier (1308) comprising a computer program (1310) according to claim 56, wherein The carrier (1308) is one of an electric signal, an optical signal, a radio signal or a computer-readable storage medium.
58. A telecommunication system (20) for retrying multicast session signaling for a multicast session or broadcast session signaling for a broadcast session, the telecommunication system (20) comprising: The first network node (225, 1300, 1400) according to claim 38 or 39; as well as The second network node (235, 1300, 1500) according to claim 54 or 55.
59. A telecommunication system (20) for resuming a broadcast session, the telecommunication system (20) comprising: The first network node (225-2, 1300, 1600) according to claim 8 or 9; as well as The second network node (235, 1300, 1700) according to claim 19 or 20.
