Patent Application
20230291818
The present disclosure is related to wireless communication systems and more particularly to network function service instance reselection enhancement in a 5th Generation core network with indirect communication.
According to some embodiments, a method of operating a first network node in a communications network configured to operate with indirect communication is provided. The method can include transmitting a request message addressing a first context in a first receiver to a second network node operating in the communications network. The request message can include information associated with the first context. The method can further include, responsive to transmitting the request message, receiving a response message from the second network node including an identification of a second receiver associated with a second context.
According to other embodiments, a method of operating a second network node in a communications network configured to operate with indirect communication is provided. The method can include receiving a first request message addressing a first context in a first receiver from a first network node operating in the communications network. The first request message can include first information associated with the first receiver. The method can further include determining a failure event has occurred in association with the first receiver. The method can further include, responsive to determining that the failure event has occurred, transmitting a discovery request message to a network repository function, NRF. The discovery request message can request an indication of a receiver capable of serving a second context as the first receiver serves the first context and the discovery request message including second information based on the first information. The method can further include, responsive to transmitting the discovery request message, receiving a discovery response message from the NRF, the discovery response message including a list of receivers. The method can further include selecting a second receiver from the list of receivers. The method can further include, responsive to selecting the second receiver, transmitting a second request message to the second receiver, the second request message based on the first request message. The method can further include, responsive to transmitting the second request message, receiving a first response message from the second receiver. The method can further include, responsive to receiving the first response message, transmitting a second response message to the first network node, the second response message including an identification of the second receiver.
According to other embodiments, a first network node, a second network node, computer program, and/or computer program product is provided for performing one or more of the above methods.
In various embodiments described herein, enable a service community proxy (“SCP”) to perform a reselection of the receiver (either a service producer or a service consumer) in 5GC when indirect communication is deployed
The accompanying drawings, which are included to provide a further understanding of the disclosure and are incorporated in and constitute a part of this application, illustrate certain non-limiting embodiments of inventive concepts. In the drawings:
Inventive concepts will now be described more fully hereinafter with reference to the accompanying drawings, in which examples of embodiments of inventive concepts are shown. Inventive concepts may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of present inventive concepts to those skilled in the art. It should also be noted that these embodiments are not mutually exclusive. Components from one embodiment may be tacitly assumed to be present/used in another embodiment.
The 3rd Generation Partnership Project (“3GPP”) has expanded the use of the Network Function Set concept to be applicable for all type of Network Functions in 5G Core. A NF instance can be deployed such that several network function instances are present within a NF set to provide distribution, redundancy, and scalability together as a set of NF instances. Therefore, a NF can be replaced by an alternative NF within the same NF set in case of scenarios such as failure, load balancing, and/or load re-balancing.
In case of failure of a NF (service) instance, or failure to perform load re-balancing, the peer NF can use a “Binding Indication” to select an alternative NF (service) instance.
A binding can be used to indicate suitable target NF producer instance(s) for NF service instance selection, reselection, and routing of subsequent requests associated with a specific NF producer resource (context) and NF service. This allows the NF producer to indicate that the NF consumer, for a particular context, should be bound to an NF service instance, NF instance, NF service set or NF set depending on local policies and other criteria (e.g. at what point it is in the middle of a certain procedure, considering performance aspects etc).
Binding can also be used by the NF consumer to indicate suitable NF consumer instance(s) for notification target instance reselection and routing of subsequent notification requests associated with a specific notification subscription and for providing Binding Indication for service(s) that the NF consumer produces for the same data context and the NF service producer is subsequently likely to invoke.
The binding indication can be information included by a NF service producer to a NF service consumer in request responses or notifications to convey the scope within which selection/reselection of target NF/NF services may be performed, or information included by the NF service consumer in requests or subscriptions to convey the scope within which selection/reselection of notification targets or the selection of other service(s) that the NF consumer produces for the same data context may be performed.
The Binding Indication can be defined as a 3GPP custom http header as described in TS 29.500.
“Indirect Communication” is described below.
NF services may communicate directly between NF Service consumers and NF Service Producers, or indirectly via an SCP.
In
In
A routing binding indication may be included in a request, subscribe or notification messages. It can be used in the case of indirect communication by the SCP to route the message. The Routing Binding Indication can be a copy of the information in the Binding Indication.
During NF service discovery and (re)selection aspects relevant with indirect communication, the SCP can perform the following functionalities regarding NF and NF service discovery and selection. If the request includes a routing binding indication, the SCP can route the service request to the requested target. If the routing binding indication does not exist, the SCP may get the NF Set ID from the NRF or local configuration (if available). If the request recipient had previously provided a binding indication, then the request sender can include a routing Binding indication with the same contents in subsequent related requests.
The table in
For indirect communication without delegated discovery, the NF service consumer can perform the discovery procedure by querying the NRF and the selection of a NF (service) set or a specific NF (service) instance. The selection of the target NF service instance may be done either by the NF service consumer or the SCP (e.g. based on NF (service) set information received from the NF service consumer).
In some examples, the NF service consumer can transmit its request to the SCP including: the 3gpp-Sbi-Target-apiRoot header set to the apiRoot of the selected NF service instance, if the SCP is known to the NF Service Consumer and if the NF Service Consumer has selected a specific NF service instance; and the identity of the selected NF (Service) Set in the associated “3gpp-Sbi-Discovery-*” request header(s) (see clause 6.10.3.2), if the NF Service Consumer has selected a target NF (Service) Set ID.
If the request does not include the apiRoot of a selected NF service instance, or if the SCP needs to reselect a different NF service instance, the SCP can select an NF service instance using the NF (service) set ID received in the corresponding “3gpp-Sbi-Discovery-*” request header(s), if available.
The SCP can then route the request to the selected NF service instance of the target NF service producer.
When the NF service consumer is configured to use delegated service discovery (as in
When receiving from the NF service consumer a service request containing “3gpp-Sbi-Discovery-*” request headers, and the SCP is to invoke NF service discovery towards the NRF to fulfil this task, then it can take into account all the NF service discovery factors contained in the “3gpp-Sbi-Discovery-*” request headers. It is also possible for the SCP to be internally configured to fulfil these service discovery tasks without interacting with the NRF.
If the service request includes a “3gpp-Sbi-Discovery-*” request header that is not supported by the SCP, the latter can include the corresponding query parameters in the discovery request to the NRF. Based on operator policy, the SCP may alternatively reject the request and return a response with the status code “400 Bad Request” to the NF service consumer with an “INVALID_DISCOVERY_PARAM” error.
An NF may register default notification subscriptions in its NF profile or NF services in the NRF for notifications the NF is prepared to consume, including for each type of notification the corresponding notification endpoint (i.e. callback URI). This can be used, for example, by an AMF to discover the notification endpoint of other AMFs to forward N1 or N2 messages, or by an AMF to notify location information to a GMLC, or by an UDR to notify data change or removal to an UDM.
The following procedures may be used to support notifications corresponding to default notification subscriptions. In some examples, an NF producer may perform a discovery request towards the NRF (possibly through an SCP) to discover default notification subscriptions of an NF consumer, and if so, send notifications to the corresponding notification endpoints, using routing mechanisms. In other examples, an NF producer may be configured with the types of notifications corresponding to default notification subscriptions it needs to generate, and send such notifications using delegated discovery, i.e with an SCP discovering and selecting an NF service consumer with a corresponding default notification subscription. To enable the latter, the NF producer can include in the notification request: the 3gpp-Sbi-Callback header including the name of the notify or callback service operation and the API major version if higher than 1; the 3gpp-Sbi-Discovery-notification-type header set to the type of notification being set; the 3gpp-Sbi-Discovery-target-nf-type header indicating the type of the consumer NF; and/or an additional NF service discovery factors header to be used by the SCP to discover and select the consumer NF.
When using delegated discovery, if and only if the NF Service Producer does not return a client binding indication in a service response creating a resource, the SCP can include the 3gpp-Sbi-Producer-Id header in the HTTP response it forwards to the NF Service Consumer, containing the NF Instance ID of the NF Service Producer selected by the SCP. This can allow support for deployments where not all NF Service Producers have been upgraded to support the binding procedures. In examples where the same NF Service Producer needs to be selected when creating new resources, e.g. when the AMF needs to establish a new PDU session towards the same SMF as the one selected for a previous PDU session, the NF Service Consumer can include the 3gpp-Sbi-Discovery-target-nf-instance-id header set to the NF Instance ID of the NF Service Producer in the request creating the new resource.
However, for communication models C and D, it is not clear, in the subsequent request message addressing an existing resource context in the service producer or an existing session context in the Service consumer (to receive Notification Request message), what parameters the SCP can use to perform a reselection of an alternative endpoint, if the binding indication is not supported/provided by the receiver earlier (e.g., the service producer or service consumer). For example, the binding indication of the receiver may not be available if it is the first communication towards the receiver of if the receiver doesn’t support the binding indication at all.
When the binding indication provided by the receiver (regardless of if the receiver is a service producer or a service consumer) is available, the sender of a request message (either a service request (e.g. update) to send the service producer or a notification request sent to a service consumer), can include a routing binding indication, which is a copy of the binding indication sent earlier by the receiver. The SCP can use the routing binding indication to (re)select an alternative receiver if the original receiver is not reachable.
During an initiate establishment of resource context, 3gpp-Sbi-Discovery-target* can be used, for both Model C and Model D.
For indirect communication without delegation (Model C), for initial establishment of a resource context in the service provider, if the service consumer has selected a specific service instance (e.g., instead of selecting a NF (service) set), there may be no way for the SCP to perform a reselection if the NF service instance selected by the Service Consumer is not reachable.
Therefore, there are problems for reselection (performed by the SCP) when binding indication is not available, during either: initial resource context establishment towards a NF consumer selected service producer while the service producer is not reachable, in communication model C; or an communication towards an existing resource/session context in the service producer/consumer, this is regardless if it is communication mode C or D.
Various embodiments herein enable the SCP to perform a reselection of the receiver (either a service producer or a service consumer) in 5GC when indirect communication is deployed.
In some embodiments, when sending subsequent messages addressing an existing resource context in the service producer or an existing session context in the service consumer (to receive Notification Request message) but the receiver didn’t provide any binding indication(3gpp-sbi-binding) the sender (either a service consumer (to send an update request) or a service producer (to send a notification request)), provide the following parameters as http custom header in the request message, to enable SCP to perform a reselection of an alternative endpoint, if the intended receiver has failed. In some examples, the sender generates a “3gpp-sbi-routing-binding” (for the receiver) with the binding level set to NF service set or NF set, and include NF service set id if available or NF set id if available ON ITS OWN. In additional or alternative examples, the sender generates “3gpp-sbi-discovery-target-nf-instance-id″ + ““3gpp-sbi-discovery-service-names” for the receiver.
In some embodiments, the sender can only copy the binding indication received from the receiver earlier into routing binding indication, to be used by the SCP(s).
In additional or alternative embodiments, when binding indication of the receiver is not available, the sender can make the following assumptions. If the NF (service) instance is pertaining to a NF (service) set, when another NF (service) instance in the same NF (service) set can serve the same resource context. The SCP, at receiving “3gpp-sbi-routing-binding” or “3gpp-sbi-discovery-target-nf-instance-id”, can retrieve the NF service set or NF set via initiating Service Discovery procedure towards NRF using the target NF instance Id and service name. The SCP can consider first to select an alternative service instance in the same service set if available/as defined in the NF profile (identified by the target-nf-instance-id). If not, it selects another NF in the same NF set.
In some examples, target NF instance Id and NF service name are included in either “3gpp-sbi-routing-binding” or provisioned using both “3gpp-sbi-discovery-target-nf-instance-id”, “3gpp-sbi-discovery-service-names”.
In some embodiments, for communication model C (service discovery without delegation) when the service consumer has selected an exact service instance for an initial establishment of a resource context in the service producer, in such case, the service consumer includes: “3gpp-sbi-discovery-target-nf-instance-id″ + ““3gpp-sbi-discovery-service-names” in order to let SCP to select an alternative if the one selected by the consumer is not reachable; or “3gpp-sbi-routing-indication” in order to let SCP to select an alternative.
For communication mode C, without delegation, it may be more reasonable to use “3gpp-sbi-routing-binding”; while for communication mode D with service discovery delegation, it may be more reasonable to use “3gpp-sbi-discovery-target-nf-id” + “3gpp-sbi-discovery-service-names”.
In
In
At operation 1310, AMF 1302 transmits a service discovery request to NRF 1309. In some embodiments, the service discovery request includes a request to find a service provider (e.g., a SMF) to provide a service (e.g., consume a Nsmf_PDUSession service). In additional or alternative embodiments, the service discovery request includes a list of discovery parameters indicating characteristics of the service provider.
At operation 1320, NRF 1309 transmits a service discovery response to AMF 1302. In some embodiments, the service discovery response includes a list of service providers (e.g., SMF NF profiles) that can perform the service for a communication device associated with the AMF 1302. In additional or alternative embodiments, the list of service providers can include NF service set IDs and NF set IDs associated with each service provider.
At operation 1330, the AMF 1302 selects the SMF 1306. In some embodiments, the AMF 1302 selects the SMF 1306 from the list of service providers.
At operation 1340, the AMF 1302 transmits the service request to the SCP 1304. In some embodiments, the service request includes a request for creating a resource in SMF 1306′s service instance. In additional or alternative embodiments, the service request includes 3gpp-sbi-discvoery-target-nf-id and 3gpp-sbi-discovery-service-name (which can be used by the SCP 1304 if reselection is needed).
At operation 1350, the SCP 1304 transmits a service request to the SMF 1306. At operation 1360, the SMF 1306 transmits a service response to the SCP 1304. In some embodiments, the service response includes a location header of the created resource. In additional or alternative embodiments, the service request may not include a binding indication. At operation 1370, the SCP 1304 transmits a service response to the AMF 1302. In some embodiments, the service request is based on the service request received from the SMF 1306 and includes an identifier of the SMF 1304 (e.g., a 3gpp-producer-id).
At operation 1410, the AMF 1302 transmits a service request to the SCP 1304. In some embodiments, the service request includes a request for creating a resource. In additional or alternative embodiments, the service request includes 3gpp-sbi-discovery-target-nf-type, 3gpp-sbi-discovery-service-name, and 3gpp-sbi-discvoery-dnn.
At operation 1420, the SCP 1304 transmits a service discovery request to the NRF 1309. In some embodiments, the SCP discovery request can be based on the information in the service request.
At operation 1430, the NRF 1309 transmits a service discovery response to the SCP 1304. In some embodiments, the service discovery response includes a list of service providers (e.g., SMF NF profiles) that can perform the service for a communication device associated with the AMF 1302. In additional or alternative embodiments, the list of service providers can include NF service set IDs and NF set IDs associated with each service provider.
At operation 1440, the SCP 1304 selects the SMF 1306. In some embodiments, the SCP 1304 selects the SMF 1306 from the list of service providers.
At operation 1450, the SCP 1304 transmits a service request to the SMF 1306. At operation 1460, the SMF 1306 transmits a service response to the SCP 1304. In some embodiments, the service response includes a location header of the created resource. In additional or alternative embodiments, the service request may not include a binding indication. At operation 1470, the SCP 1304 transmits a service response to the AMF 1302. In some embodiments, the service request is based on the service request received from the SMF 1306 and includes an identifier of the SMF 1304 (e.g., a 3gpp-producer-id).
At operation 1510, AMF 1302 transmits a service request to SCP 1304. In some embodiments, the service request includes a request to create a resource. In additional or alternative embodiments, the service request includes information associated with the service provider (e.g., SMF 1304), for example, 3gpp-sbi-discovery-target-nf-id, 3gpp-sbi-discovery-service-name, and 3gpp-sbi-discovery-dnn.
In additional or alternative embodiments, the service request includes a request to update the resource. In additional or alternative embodiments, the service request includes information associated with the service provider (e.g., SMF 1304), for example, 3gpp-sbi-discovery-target-nf-id and 3gpp-sbi-discovery-service-name.
At operation 1520, SCP 1304 fails to communicate with the SMF 1306. In some embodiments, failing to communicate with the SMF includes determining that a failure event associated with the SMF 1306 has occurred.
At operation 1530, SCP 1304 transmits a service discovery request to NRF 1309. In some embodiments, the service discovery request includes information from the service request to find an alternate SMF from the same NF set as the SMF 1306.
At operation 1540, NRF 1309 transmits a service discovery response to SCP 1304. In some embodiments, the service discovery response include a candidate list of potential service providers including SMF 1308.
At operation 1550, SCP 1304 transmits a service request to the SMF 1308. In some embodiments, the service request is based on the service request received from the AMF 1302 and includes an indication for the SMF 1308 to create a resource for providing the service previously provided by SMF 1306.
At operation 1560, SMF 1308 transmits a service response to the SCP 1304. In some embodiments, the service response includes a location header of the created resource. In additional or alternative embodiments, the service response may not include a binding indication.
At operation 1570, SCP 1304 transmits a service response to the AMF 1302. In some embodiments, the service response includes the information received in the service response by the SMF 1308. In additional or alternative embodiments, the service response also includes a identification of SMF 1308 (e.g., 3gpp-producer-id).
Although
As discussed herein, operations of communication device 1600 may be performed by processing circuitry 1603 and/or transceiver circuitry 1601. For example, processing circuitry 1603 may control transceiver circuitry 1601 to transmit communications through transceiver circuitry 1601 over a radio interface to a radio access network node (also referred to as a base station) and/or to receive communications through transceiver circuitry 1601 from a RAN node over a radio interface. Moreover, modules may be stored in memory circuitry 1605, and these modules may provide instructions so that when instructions of a module are executed by processing circuitry 1603, processing circuitry 1603 performs respective operations.
As discussed herein, operations of the RAN node 1700 may be performed by processing circuitry 1703, network interface 1707, and/or transceiver 1701. For example, processing circuitry 1703 may control transceiver 1701 to transmit downlink communications through transceiver 1701 over a radio interface to one or more mobile terminals UEs and/or to receive uplink communications through transceiver 1701 from one or more mobile terminals UEs over a radio interface. Similarly, processing circuitry 1703 may control network interface 1707 to transmit communications through network interface 1707 to one or more other network nodes and/or to receive communications through network interface from one or more other network nodes. Moreover, modules may be stored in memory 1705, and these modules may provide instructions so that when instructions of a module are executed by processing circuitry 1703, processing circuitry 1703 performs respective operations.
According to some other embodiments, a network node may be implemented as a core network CN node without a transceiver. In such embodiments, transmission to a wireless communication device UE may be initiated by the network node so that transmission to the wireless communication device UE is provided through a network node including a transceiver (e.g., through a base station or RAN node). According to embodiments where the network node is a RAN node including a transceiver, initiating transmission may include transmitting through the transceiver.
As discussed herein, operations of the CN node 1800 may be performed by processing circuitry 1803 and/or network interface circuitry 1807. For example, processing circuitry 1803 may control network interface circuitry 1807 to transmit communications through network interface circuitry 1807 to one or more other network nodes and/or to receive communications through network interface circuitry from one or more other network nodes. Moreover, modules may be stored in memory 1805, and these modules may provide instructions so that when instructions of a module are executed by processing circuitry 1803, processing circuitry 1803 performs respective operations.
Operations of a first network node will now be discussed with reference to the flow charts of
At block 1910, processing circuitry 1803 transmits, via network interface 1807, a first request message that requests initialization of a first context. In some embodiments, the first request message indicates that a second network node select a receiver capable of serving the first context. In additional or alternative embodiments, the first request message includes a 3gpp-sbi-routing-indication.
In some embodiments, the existing context is a new context and the first request message indicates a first receiver for serving the new context.
Returning to
At block 1930, processing circuitry 1803 generates information associated with the first receiver based on the identifier of the first receiver. In some embodiments, the information includes an indication of a binding level associated with the first receiver. In additional or alternative embodiments, the information includes a 3gpp-sbi-discovery-target-nf-instance-id and a 3gpp-sbi-discovery-service-names.
At block 1940, processing circuitry 1803 transmits, via network interface 1807, a request message addressing the existing context to a second network node including the information associated with the first receiver. In some embodiments, the request message requests an operation be performed in association with the first context. In additional or alternative embodiments, the operation includes creating the first context or updating the first context.
At block 1950, processing circuitry 1803 receives, via network interface 1807, a response message from the second network node including an identification of a second receiver. In some embodiments, the second receiver has a binding level within a predetermined threshold of the binding level associated with the first receiver. In additional or alternative embodiments, the response message further includes an indication of a location header of a second context.
In some embodiments, the first network node includes an AMF. In additional or alternative embodiments, the second network node includes a SCP. In additional or alternative embodiments, the first receiver is a first SMF and the second receiver is a second SMF. In additional or alternative embodiments, the communications network is a 5G network.
Various operations of
Operations of a second network node will now be discussed with reference to the flow charts of
At block 2110, processing circuitry 1803 receives, via network interface 1807, a first request message addressing a first context in a first receiver from a first network node including first information associated with the first context in the first receiver. In some embodiments, the request message requests an operation be performed in association with a first context. In additional or alternative embodiments, the operation includes at least one of creating the first context and updating the first context.
At block 2120, processing circuitry 1803 determines a failure event has occurred in association with the first receiver. In some embodiments, the failure event includes the first receiver being unresponsive.
At block 2130, processing circuitry 1803 transmits, via network interface 1807, a discovery request message to a NRF requesting an indication of a receiver capable of creating a second context and including second information based on the first information. In some embodiments, the first information and the second information each include an indication of a binding level associated with the first receiver. In additional or alternative embodiments, the first information includes a 3gpp-sbi-discovery-target-nf-instance-id and a 3gpp-sbi-discovery-service-names.
At block 2140, processing circuitry 1803 receives, via network interface 1807, a discovery response message from the NRF including a list of receivers.
At block 2150, processing circuitry 1803 selects a second receiver from the list of receivers. In some embodiments, selecting the second receiver includes selecting the second receiver based on the second receiver having a binding level within a predetermined threshold of the binding level associated with the first receiver.
At block 2160, processing circuitry 1803 transmits, via network interface 1807, a second request message to the second receiver.
At block 2170, processing circuitry 1803 receives, via network interface 1807, a first response message from the second receiver.
At block 2180, processing circuitry 1803 transmits, via network interface 1807, a second response message to the first network node based on the first response message.
At block 2240, processing circuitry 1803 transmits, via network interface 1807, a fourth response message to the first network node including a location header of the first context and an indication of a binding level associated with the first provider. In some embodiments, transmitting the fourth request message based on the third request message to the first receiver includes transmitting a first discovery request message to the NRF. The first discovery request message can request message an indication of a receiver capable of creating the first context to provide the same service to the consumer/producer associated with the first network node and the first discovery request message including the 3gpp-sbi-discovery-dnn. T the fourth request message based on the third request message to the first receiver can further include, responsive to transmitting the first discovery request message, receiving a first discovery response message from the NRF, the first discovery response message including a first list of receivers. Transmitting the fourth request message based on the third request message to the first receiver can include selecting the first receiver from the first list of receivers.
In some embodiments, the first network node includes an AMF. In additional or alternative embodiments, the second network node includes a SCP. In additional or alternative embodiments, the first receiver is a first SMF and the second provider is a second SMF. In additional or alternative embodiments, the communications network is a 5G network.
Various operations of
Example Embodiments are included below.
Embodiment 1. A method of operating a first network node in a communications network configured to operate with indirect communication, the method comprising:
Embodiment 2. The method of Embodiment 1, wherein the first context is an existing context in the first receiver, and
Embodiment 3. The method of any of Embodiments 1-2, wherein the information associated with the first context in the first receiver comprises a routing binding indication associated with the first context in the first receiver.
Embodiment 4. The method of any of Embodiments 1-2, wherein the information associated with the first context in the first receiver comprises 3gpp-sbi-discovery* HTTP headers.
Embodiment 5. The method of Embodiment 4, wherein the 3gpp-sbi-discovery* comprises a discovery-target-nf-instance-id and a 3gpp-sbi-discovery-service-names.
Embodiment 6. The method of any of Embodiments 1-5, wherein the first context is an existing context,
Embodiment 7. The method of Embodiment 6, further comprising:
Embodiment 8. The method of Embodiment 6, wherein the first request indicates that the second network node select a receiver capable of serving the existing context.
Embodiment 9. The method of Embodiment 8, wherein the first request message comprises a 3gpp-sbi-routing-indication.
Embodiment 10. The method of Embodiment 1, wherein the first context is a new context,
Embodiment 11. The method of any of Embodiments 1-10, wherein the communications network is a 5th Generation, 5G, network,
Embodiment 12. The method of Embodiment 11, wherein the first network node is associated with a consumer,
Embodiment 13. The method of Embodiment 12, wherein the first network node comprises an access and mobility management function, AMF,
Embodiment 14. The method of Embodiment 11, wherein the first network node is associated with a producer,
Embodiment 15. The method of Embodiment 14, wherein the first network node comprises a session management function, SMF,
Embodiment 16. A method of operating a second network node in a communications network configured to operate with indirect communication, the method comprising:
Embodiment 17. The method of Embodiment 16, wherein the first information and the second information each comprise information to select a list of receivers capable of serving a context as the first receiver served the first context.
Embodiment 18. The method of Embodiment 17, wherein selecting the second receiver comprises selecting the second receiver based on the routing binding indication received from the first network node.
Embodiment 19. The method of any of Embodiments 16-17, wherein the information associated with the first receiver comprises HTTP 3gpp-sbi-discovery* headers.
Embodiment 20. The method of Embodiment 19, wherein 3gpp-sbi-discovery* comprises a 3gpp-sbi-discovery-target-nf-instance-id and a 3gpp-sbi-discovery-service-names.
Embodiment 21. The method of any of Embodiments 16-20, wherein the first context is an existing context,
Embodiment 22. The method of Embodiment 21, wherein the third response message from the first receiver includes a binding indication of a binding level of the first receiver, and
Embodiment 23. The method of Embodiment 22, wherein the third response message from the first receiver fails to include a binding indication of the binding level of the first receiver, and
Embodiment 24. The method of any of Embodiments 21-23, wherein the discovery request message is a second discovery request message,
Embodiment 25. The method of any of Embodiments 16-24, wherein the first response message from the second receiver fails to include a binding indication indicating a binding level of the second receiver, and
Embodiment 26. The method of any of Embodiments 16-25, wherein the communications network is a 5th Generation, 5G, network,
Embodiment 27. The method of Embodiment 26, wherein the first network node is associated with a consumer,
Embodiment 28. The method of Embodiment 27, wherein the first network node comprises an access and mobility management function, AMF,
Embodiment 29. The method of Embodiment 26, wherein the first network node is associated with a producer,
Embodiment 30. The method of Embodiment 29, wherein the first network node comprises a session management function, SMF,
Embodiment 31. A first network node (1800) operating in a communications network configured to operate with indirect communication, the network node comprising:
Embodiment 32. The first network node of Embodiment 31, wherein the first context is an existing context in the first receiver,
Embodiment 33. The first network node of Embodiment 32, wherein the information associated with the first context in the first receiver comprises a routing binding indication associated with the first context in the first receiver.
Embodiment 34. The first network node of any of Embodiments 31-33, wherein the information associated with the first context in the first receiver comprises 3gpp-sbi-discovery* HTTP headers.
Embodiment 35. The first network node of Embodiment 34, wherein the 3gpp-sbi-discovery* comprises a discovery-target-nf-instance-id and a 3gpp-sbi-discovery-service-names.
Embodiment 36. The first network node of any of Embodiments 31-35, wherein the first context is an existing context,
Embodiment 37. The first network node of Embodiment 36, operations further comprising:
Embodiment 38. The first network node of Embodiment 36, wherein the first request indicates that the second network node select a receiver capable of serving the existing context.
Embodiment 39. The first network node of Embodiment 38, wherein the first request message comprises a 3gpp-sbi-routing-indication.
Embodiment 40. The first network node of Embodiment 31, wherein the first context is a new context,
Embodiment 41. The first network node of any of Embodiments 31-40, wherein the communications network is a 5th Generation, 5G, network,
Embodiment 42. The first network node of Embodiment 41, wherein the first network node is associated with a consumer,
Embodiment 43. The first network node of Embodiment 42, wherein the first network node comprises an access and mobility management function, AMF,
Embodiment 44. The first network node of Embodiment 43, wherein the first network node is associated with a producer,
Embodiment 45. The first network node of Embodiment 44, wherein the first network node comprises a session management function, SMF,
Embodiment 46. A first network node (1800) operating in a communications network configured to operate with indirect communication and adapted to perform operations, the operations comprising:
Embodiment 47. The first network node of Embodiment 46, further adapted to perform any of the operations of Embodiments 2-15.
Embodiment 48. A computer program comprising program code to be executed by processing circuitry (1803) of a first network node (1800) operating in a communications network configured to operate with indirect communication, whereby execution of the program code causes the first network node to perform operations, the operations comprising:
Embodiment 49. The computer program of Embodiment 48, whereby execution of the program code further causes the first network node to perform any of the operations of Embodiments 2-15.
Embodiment 50. A computer program product comprising a non-transitory storage medium including program code to be executed by processing circuitry (1803) of a first network node (1800) operating in a communications network configured to operate with indirect communication, whereby execution of the program code causes the first network node to perform operations, the operations comprising:
Embodiment 51. The computer program product of Embodiment 50, whereby execution of the program code further causes the first network node to perform any of the operations of Embodiments 2-15.
Embodiment 52. A second network node (1800) operating in a communications network configured to operate with indirect communication, the network node comprising:
Embodiment 53. The second network node of Embodiment 52, wherein the first information and the second information each comprise information to select a list of receivers capable of serving a context as the first receiver served the first context.
Embodiment 54. The second network node of Embodiment 53, wherein selecting the second receiver comprises selecting the second receiver based on the routing binding indication received from the first network node.
Embodiment 55. The second network node of any of Embodiments 52-54, wherein the information associated with the first receiver comprises HTTP 3gpp-sbi-discovery* headers.
Embodiment 56. The second network node of Embodiment 55, wherein 3gpp-sbi-discovery* comprises a 3gpp-sbi-discovery-target-nf-instance-id and a 3gpp-sbi-discovery-service-names.
Embodiment 57. The second network node of any of Embodiments 52-55, wherein the first context is an existing context,
Embodiment 58. The second network node of Embodiment 57, wherein the third response message from the first receiver includes a binding indication of a binding level of the first receiver, and
Embodiment 59. The second network node of Embodiment 58, wherein the third response message from the first receiver fails to include a binding indication of the binding level of the first receiver, and
Embodiment 60. The second network node of any of Embodiments 57-59, wherein the discovery request message is a second discovery request message,
Embodiment 61. The second network node of any of Embodiments 52-60, wherein the first response message from the second receiver fails to include a binding indication indicating a binding level of the second receiver, and
Embodiment 62. The second network node of any of Embodiments 52-61, wherein the communications network is a 5th Generation, 5G, network,
Embodiment 63. The second network node of Embodiment 62, wherein the first network node is associated with a consumer,
Embodiment 64. The second network node of Embodiment 63, wherein the first network node comprises an access and mobility management function, AMF,
Embodiment 65. The second network node of Embodiment 62, wherein the first network node is associated with a producer,
Embodiment 66. The second network node of Embodiment 65, wherein the first network node comprises a session management function, SMF,
Embodiment 67. A second network node (1800) operating in a communications network configured to operate with indirect communication and adapted to perform operations, the operations comprising:
Embodiment 68. The second network node of Embodiment 67, further adapted to perform any of the operations of Embodiments 17-30.
Embodiment 69. A computer program comprising program code to be executed by processing circuitry (1803) of a second network node (1800) operating in a communications network configured to operate with indirect communication, whereby execution of the program code causes the second network node to perform operations, the operations comprising:
Embodiment 70. The computer program of Embodiment 69, whereby execution of the program code further causes the second network node to perform any of the operations of Embodiments 16-30.
Embodiment 71. A computer program product comprising a non-transitory storage medium including program code to be executed by processing circuitry (1803) of a second network node (1800) operating in a communications network configured to operate with indirect communication, whereby execution of the program code causes the second network node to perform operations, the operations comprising:
Embodiment 72. The computer program product of Embodiment 71, whereby execution of the program code further causes the second network node to perform any of the operations of Embodiments 16-30.
Some abbreviations used above are described below.
Further definitions and embodiments are discussed below.
In the above-description of various embodiments of present inventive concepts, it is to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of present inventive concepts. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which present inventive concepts belong. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.
When an element is referred to as being “connected”, “coupled”, “responsive”, or variants thereof to another element, it can be directly connected, coupled, or responsive to the other element or intervening elements may be present. In contrast, when an element is referred to as being “directly connected”, “directly coupled”, “directly responsive”, or variants thereof to another element, there are no intervening elements present. Like numbers refer to like elements throughout. Furthermore, “coupled”, “connected”, “responsive”, or variants thereof as used herein may include wirelessly coupled, connected, or responsive. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. Well-known functions or constructions may not be described in detail for brevity and/or clarity. The term “and/or” (abbreviated “/”) includes any and all combinations of one or more of the associated listed items.
It will be understood that although the terms first, second, third, etc. may be used herein to describe various elements/operations, these elements/operations should not be limited by these terms. These terms are only used to distinguish one element/operation from another element/operation. Thus a first element/operation in some embodiments could be termed a second element/operation in other embodiments without departing from the teachings of present inventive concepts. The same reference numerals or the same reference designators denote the same or similar elements throughout the specification.
As used herein, the terms “comprise”, “comprising”, “comprises”, “include”, “including”, “includes”, “have”, “has”, “having”, or variants thereof are open-ended, and include one or more stated features, integers, elements, steps, components or functions but does not preclude the presence or addition of one or more other features, integers, elements, steps, components, functions or groups thereof. Furthermore, as used herein, the common abbreviation “e.g.”, which derives from the Latin phrase “exempli gratia,” may be used to introduce or specify a general example or examples of a previously mentioned item, and is not intended to be limiting of such item. The common abbreviation “i.e.”, which derives from the Latin phrase “id est,” may be used to specify a particular item from a more general recitation.
Example embodiments are described herein with reference to block diagrams and/or flowchart illustrations of computer-implemented methods, apparatus (systems and/or devices) and/or computer program products. It is understood that a block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by computer program instructions that are performed by one or more computer circuits. These computer program instructions may be provided to a processor circuit of a general purpose computer circuit, special purpose computer circuit, and/or other programmable data processing circuit to produce a machine, such that the instructions, which execute via the processor of the computer and/or other programmable data processing apparatus, transform and control transistors, values stored in memory locations, and other hardware components within such circuitry to implement the functions/acts specified in the block diagrams and/or flowchart block or blocks, and thereby create means (functionality) and/or structure for implementing the functions/acts specified in the block diagrams and/or flowchart block(s).
These computer program instructions may also be stored in a tangible computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instructions which implement the functions/acts specified in the block diagrams and/or flowchart block or blocks. Accordingly, embodiments of present inventive concepts may be embodied in hardware and/or in software (including firmware, resident software, micro-code, etc.) that runs on a processor such as a digital signal processor, which may collectively be referred to as “circuitry,” “a module” or variants thereof.
It should also be noted that in some alternate implementations, the functions/acts noted in the blocks may occur out of the order noted in the flowcharts. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality/acts involved. Moreover, the functionality of a given block of the flowcharts and/or block diagrams may be separated into multiple blocks and/or the functionality of two or more blocks of the flowcharts and/or block diagrams may be at least partially integrated. Finally, other blocks may be added/inserted between the blocks that are illustrated, and/or blocks/operations may be omitted without departing from the scope of inventive concepts. Moreover, although some of the diagrams include arrows on communication paths to show a primary direction of communication, it is to be understood that communication may occur in the opposite direction to the depicted arrows.
Many variations and modifications can be made to the embodiments without substantially departing from the principles of the present inventive concepts. All such variations and modifications are intended to be included herein within the scope of present inventive concepts. Accordingly, the above disclosed subject matter is to be considered illustrative, and not restrictive, and the examples of embodiments are intended to cover all such modifications, enhancements, and other embodiments, which fall within the spirit and scope of present inventive concepts. Thus, to the maximum extent allowed by law, the scope of present inventive concepts are to be determined by the broadest permissible interpretation of the present disclosure including the examples of embodiments and their equivalents, and shall not be restricted or limited by the foregoing detailed description.
Details of the embodiments described above are further specified below:
Reason for change: When reselecting of a NF Service Instance by the SCP while the Routing Binding Indication is not available, it is not clear which parameters that the SCP can use to make the reselection.
It should be documented how reselection of a NF service consumer to receive Notification or Callback request.
Summary of change: When reselecting of a NF Service Instance by the SCP while the Routing Binding Indication is not available, the SCP may use use NF service discovery factors which are conveyed by the″3gpp-Sbi-Discovery-*” request headers if the NF Service Consumer includes in the request message;
Proposed a set of requirements similar to the reselection of NF service producer for the reselection of NF service consumer.
Consequences if not approved: The SCP is unable to perform a reselection of NF Service Instance when the Routing Binding Indication is not available. Reselection of a NF Service Consumer may not work.
Clauses affected: 6.5.3, 6.×.1, 6.×.2, 6.×.3
6.5.3 NF Service Instance Reselection when a (Routing) Binding Indication is not available
If a formerly selected NF Service Instance becomes unavailable, the NF Service Consumer or SCP may select a different instance of a same NF Service in:
If so, the NF Service Consumer or SCP may invoke service operations in the newly selected NF Service Instance by means of replacing the addressing parameters with those of the new service instance, and the new NF Service Instance in the NF Service Producer shall produce the same result as if the service operation request would have been successfully delivered to the former NF Service Instance.
For indirect communication, the SCP may use NF service discovery factors which are conveyed by the″3gpp-Sbi-Discovery-*” request headers (if the NF Service Consumer includes in the request message) to perform NF service discovery procedures and reselect a NF (service) instance, if the target NF Service Instance, as indicated in the “3gpp-Sbi-Target-apiRoot” header or in the target URI, is not reachable.
NOTE: This reselection mechanism is applicable only for the request/response service semantics, but not for notify/callback requests.
If the NF instance does not indicate in its NF Profile the support of the capability to persist their resources in shared storage across service instances of the same NF Service, inside the NF Instance, and if it does not indicate in its NF Profile that it belongs to an NF Set or an NF Service Set, the NF Service Consumer or SCP may still reselect any of the exposed service instances, but it shall not assume that the resources created in the former service instance are still valid.
When NF (Service) Set is deployed in the network as specified in clause 5.21.3 and 6.3.1.0 of 3GPP TS 23.501[9], an NF Service Consumer in an NF (Service) Set may create a session context for callback (corresponding to the resource context in the NF Service Producer) when invoking a NF Service and the session context data is shared by all NF (Service) instances pertaining to the same NF (Service) set, i.e. the context is bound to the NF (Service) Set.
An NF Service Producer or SCP may discover, via NRF Nnrf_NFDiscovery service, all available NF (Service) Instances within the NF (service) set is able to receive notifications or callback request from the NF Service Producer and select one of them.
6.×.2 NF Service Consumer Reselection when a (Routing) Binding Indication is available
When using the Binding procedures specified in clause 6.12 of 3GPP TS 29.500 [10], Binding Indications and Routing Binding Indications include the Binding level and one or more Binding entity IDs representing all NF service consumer instances that are capable to serve notifications or callback requests targeting the session context for callback (corresponding to the resource context in the NF Service Producer).
When a Binding Indication or a Routing Binding Indication is available for a target context, NF Service Consumer selection and re-selection shall be supported as specified in clause 6.12 of 3GPP TS 29.500 [10].
6.×.3 NF Service Consumer Reselection when a (Routing) Binding Indication is not available
When the target NF Service Consumer becomes unavailable, the NF Service Producer or SCP may select a different instance of the Service Consumer which is capable to serve notifications or callback requests targeting the session context for callback (corresponding to the resource context in the NF Service Producer) in:
NOTE 1: The NF Service Consumer can provide the name of the NF service to which these notifications are to be sent (this service can be one of the service produced by the NF (if this NF Service Consumer can also serve as a NF Service Producer) and registered in the NRF or a custom service registered in the NRF for the purpose of receiving these notifications). See clause 6.5.2.2 of 3GPP TS 29.500 [10].
NOTE 2: When the AMF serves as a NF Service Consumer, it can indicate to the NF Service Producer its backup AMF. See clause 5.21.2 of 3GPP TS 23.501[9].
If so, the NF Service Producer or SCP may send notification or callback request to the newly selected NF Service Consumer Instance by means of replacing the addressing parameters with the newly selected.
For indirect communication, the SCP may use NF service discovery factors which are conveyed by the″3gpp-Sbi-Discovery-*” request headers (if the NF Service Producer includes in the request message) to perform NF service discovery procedures and reselect a NF (service) instance, if the target NF Service Consumer Instance, as indicated in the “3gpp-Sbi-Target-apiRoot” header or in the target URI is not reachable.
Reason for change: As specified in TS 23.527, clause 6.5, the reselection of the service instance needs consider both when the (Routing) Binding Indication is available or not available.
There are a few issues when come to reselection of a target NF if indirect communication is deployed in a PLMN:
Considering that the SCP is assumed to either use ““ (e.g. for addressing existing context), or use “3gpp-Sbi-Discovery-*” (e.g. when the service consumer has just selected the target NF (service) Set for Model C, and for Mode D with discovery delegation), for above two cases, it is proposed, the sender may include a routing binding indication which is built on its own, or a “3gpp-Sbi-Discovery-*” (e.g. 3gpp-sbi-discovery-target-nf-instance-id, 3gpp-sbi-discovery-service-names, 3gpp-sbi-discovery-target-nf-set-id, 3gpp-sbi-discovery-target-service-set-id″, based on the information e.g. to which NF (service) set the intended receiver pertain.
Summary of change: When sending a request message to address an existing context while the binding indication (in corresponding to the context) is not received earlier from the target NF, to enable SCP perform a reselection of the target NF, it is proposed that:
5.2.3.2.5 3gpp-Sbi-Routing-Binding
This header contains a Routing Binding Indication which is used by the SCP to direct a service request to an HTTP NF service producer server which has the targeted NF service resource context, or a notification or a callback request to a NF service consumer (see clause 6.12). The Routing Binding Indication is a copy of the information in the Binding Indication (see clause 5.2.3.2.6 and clause 6.3.1.0 of 3GPP TS 23.501 [3]) if it is available; otherwise the sender may create a Routing Binding Indication based on the NF Profile of the target NF (service) Instance to enable the SCP perform a reselection, e.g. when the NF Service resource owner instance is part of an NF set (or AMF set) or an NF service set, or its NF profile indicates that its supports NF service persistence within the NF instance (see clause 6.5 of 3GPP TS 23.527 [38]).
The encoding of the header follows the ABNF as defined in IETF RFC 7230 [12].
See clause 3.2.6 of IETF RFC 7230 [12] for the “token” type definition. A token’s value is a string, which contains a binding entity ID or a service name.
3gpp-Sbi-Routing-Binding: bl=nf-set; nfset=set1.smfset.5gc.mnc012.mcc345
3gpp-Sbi-Routing-Binding: bl=nf-instance; nfinst=54804518-4191-46b3-955c-ac631f953ed8; nfset=set1.smfset.5gc.mnc012.mcc345
3gpp-Sbi-Routing-Binding: bl=nfservice-set; nfservset=setxyz.snnsmfpdusession.nfi54804518-4191-46b3-955c-ac631f953ed8.5gc.mnc012.mcc345; nfset=set1.smfset.5gc.mnc012.mcc345
3gpp-Sbi-Routing-Binding: bl=nf-set; nfset=set1.region48.amfset.5gc.mnc012.mcc345
3gpp-Sbi-Routing-Binding: bl=nf-set; nfset= set1.region48.amfset.5gc.mnc012.mcc345; servname=namf-comm
5.2.3.2.7 3gpp-Sbi-Discovery
These headers shall be used to convey NF service discovery factors to the SCP in indirect communication models. They contain discovery parameters to be conveyed by the a NF service consumer or a NF service producer to the SCP(s) and shall be used by the SCP to select or reselect for finding a suitable NF service producer instance to create or update a (existing) resource context, or a suitable NF service consumer to receive a notification or callback request, e.g. the SCP may by performing the NF service discovery procedure with the NRF on behalf of the NF consumer in case of indirect communication with delegated discovery model.
The name of each NF service discovery factors header shall be constructed by concatenating the string “3gpp-Sbi-Discovery-” with the name of the conveyed discovery parameter, i.e. “3gpp-Sbi-Discovery-<discovery parameter>”.
The discovery headers shall be used to include any of the discovery query parameters listed in 3GPP TS 29.510 [8], Table 6.2.3.2.3.1-1. The value of each NF service discovery header shall be encoded in the same way as the corresponding discovery parameter (i.e. with the same data type and cardinality). Thus, the values of these headers may be validated with the same data model as that of the corresponding discovery parameters. The discovery headers shall comply with the condition of presence of the discovery parameters defined in Table 6.2.3.2.3.1-1 of 3GPP TS 29.510 [8], e.g. discovery headers shall be included for discovery parameters defined as mandatory in this table. Table 5.2.3.2.7-1 lists examples of NF service discovery headers.
6.10.3.2 Conveyance of NF Discovery Factors
When the NF service consumer is configured to use delegated service discovery, it shall include in the HTTP/2 request message the necessary NF service discovery factors to be used by the SCP to perform NF service discovery procedures on behalf of the NF service consumer. The latter shall convey these NF service discovery factors using the″3gpp-Sbi-Discovery-*” request headers. How to set the values of these “3gpp-Sbi-Discovery-*” request headers is detailed in clause 5.2.3.2.7.
If the “3gpp-Sbi-Routing-Binding” header is not included in the HTTP/2 request message, the NF service consumer may include the “3gpp-Sbi-Discovery-*” headers in the HTTP/2 request message (which is addressing an existing resource context in the NF service producer) to enable the SCP to perform a reselection of the NF service producer, e.g. when the NF service producer which is already indicated in “3gpp-Sbi-Target-apiRoot” header is not reachable.
Based on SCP configuration, an SCP deciding to address a next-hop SCP for a service request may delegate the NF instance and/or service instance discovery and selection to subsequent SCPs, in which case it shall forward the “3gpp-Sbi-Discovery-*” request headers to the next-hop SCP.
When receiving from the NF service consumer a service request containing “3gpp-Sbi-Discovery-*” request headers and when the selection/reselection of the receiving NF is required, and the SCP is to invoke NF service discovery towards the NRF to fulfil this task, then it shall take into account all the NF service discovery factors contained in the “3gpp-Sbi-Discovery-*” request headers. It is also possible for the SCP to be internally configured to fulfil these service discovery tasks without interacting with the NRF.
NOTE: The SCP can determine “3gpp-Sbi-Discovery-*” headers are only used for reselection e.g. based on the presence of “3gpp-Sbi-Target-apiRoot” header.
If the service request contains “3gpp-Sbi-Discovery-*” request header(s) that are not supported by the SCP, the latter should include the corresponding query parameters in the discovery request to the NRF. Based on operator policy, the SCP may alternatively reject the request and return a response with the status code “400 Bad Request” to the NF service consumer with an “lNVALlD_DlSCOVERY_ PARAM” error.
6.10.3.4 Returning the NF Service Producer ID to the NF Service Consumer
When using delegated discovery, if and only if the NF Service Producer does not return a Binding Indication in a service response creating a resource, the SCP that (re)selected the target NF service instance shall include the 3gpp-Sbi-Producer-ld header in the HTTP response it forwards towards the NF Service Consumer, containing the NF Instance ID of the NF Service Producer selected by the SCP (see clause 6.10.3.2). The NF Service Consumer may include “3gpp-Sbi-Discovery-*” request headers, e.g. the 3gpp-Sbi-Discovery-target-nf-instance-id header set to the NF Instance ID of the NF Service Producer as received in 3gpp-Sbi-Producer-ld header and the 3gpp-Sbi-Discovery-service-names, in the subsequent request addressing the same resource context, to enable the SCP perform a reselection if needs.
6.10.5.1 General
For Indirect Communication without Delegated Discovery, the NF Service Consumer performs the discovery procedure by querying the NRF and the selection of a NF (Service) Set or a specific NF (service) instance . The selection of the target NF service instance may hence be done either by the NF Service Consumer or the SCP (e.g. based on NF (Service) Set information received from the NF Service Consumer).
The NF Service Consumer shall send its request to the SCP containing:
If the request does not include the apiRoot of a selected NF service instance, or if the SCP needs to reselect a different NF service instance, the SCP shall select an NF service instance using the NF (Service) Set ID received in the corresponding “3gpp-Sbi-Discovery-*” request header(s), if available.
The SCP shall then route the request to the selected NF service instance of the target NF service producer.
If the NF Service Producer does not return a Binding Indication in a service response, the SCP that reselected the target NF service instance shall include the 3gpp-Sbi-Producer-Id header in the HTTP response it forwards towards the NF Service Consumer, containing the NF Instance ID of the NF Service Producer selected by the SCP.
6.12.1 General
A Binding Indication for an NF Service Resource may be provided to an NF Service Consumer of the resource as part of the Direct or Indirect Communication procedures, to be used in subsequent related service requests. This allows the NF Service Resource owner to indicate that the NF Service Consumer, for a particular resource, should be bound to an NF service instance, NF instance, NF service set or NF set. See clause 6.3.1.0 of 3GPP TS 23.501 [3] and clause 4.17.12 of 3GPP TS 23.502 [4].
A binding may be established or updated as part of a:
Two types of binding information are defined to manage the binding between an NF Service Consumer and an NF Service Resource:
A same service request may convey more than one Binding Indication, e.g.:
The scope parameter in a Binding Indication in a service request identifies the applicability of (i.e. scenario associated with) the binding information.
A service request may convey one or more Binding Indications as described above using a 3gpp-Sbi-Binding header and/or include a Binding Routing Indication to influence routing of the request e.g. to an appropriate set of NF Service Producers or to an appropriate service set of the NF Service Producer using a 3gpp-Sbi-Routing-Binding header. A service response may convey a Binding Indication for a resource using a 3gpp-Sbi-Binding header.
NOTE 1: An HTTP request can contain for instance one 3gpp-Sbi-Binding header containing two Binding Indications for other services and for callbacks, and one 3gpp-Sbi-Routing-Binding header conveying a Routing Binding Indication.
If an SCP receives a Routing Binding Indication within a service or notification request and decides to forward that request to a next-hop SCP, it shall include the Routing Binding Indication in the forwarded request.
Binding Indications and Routing Binding Indications shall include the Binding level and one or more Binding entity IDs representing all NF service instances that are capable to serve service requests targeting the resource, i.e. that share the same resource contexts.
The Binding Level indicates a preferred binding to either a NF Instance, a NF set, a NF Service Instance or a NF Service Set. When sending a request targeting the resource, the binding entity corresponding to the binding level shall be selected whenever possible. If this is not possible, e.g. because the preferred binding entity is not reachable, the request should be sent to any other Binding entity signalled in the Binding Indication or Routing Binding Indication, in the following decreasing order of priority:
NOTE 2: NF service instances from different NF instances are equivalent NF service instances if they share the same MCC, MNC, NID (for SNPN), ServiceName, API version, and, if applicable, NF Service Set ID (see clause 28.13 of 3GPP TS 23.003 [15]).
Binding Indications shall not be used if a particular resource can only be served by a specific NF service instance of an NF instance, i.e. if NF service instances of a same NF service are not capable to share resource inside the NF Instance. A resource for which no Binding Indication or Routing Binding Indication is signalled shall be considered to be bound exclusively to one NF service instance, unless the NF Service resource owner instance is part of an NF set (or AMF set) or an NF service set, or unless its NF profile in the NRF indicates that its supports NF service persistence within the NF instance (see clause 6.5 of 3GPP TS 23.527 [38]).
| Number | Date | Country | Kind |
|---|---|---|---|
| PCT/CN2020/106743 | Aug 2020 | WO | international |
| PCT/CN2020/108188 | Aug 2020 | WO | international |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2021/071170 | 7/28/2021 | WO |
