Support for callback of API prefixes in URI

Abstract

Embodiments of the present disclosure relate to supporting callback of an API prefix in a URI, and provide a first device including at least one processor and at least one memory storing instructions. The at least one memory and the instructions are configured to, with the at least one processor, cause the first device to at least: receive a service request message from the second device, where the service request message includes a first callback uniform resource identifier (URI) having a first application programming interface (API) prefix; in response to determining that the second device is not reachable, sending a discovery request to a third device to discover a further second device instance; receiving a discovery response from the third device; determining a second callback URI based on the discovery response; and sending a callback request message to a further second device instance based on the second callback URI.

Description

Technical Field

[0001] Embodiments of the present disclosure generally relate to the field of communications, and in particular, to devices, methods, apparatuses, and computer-readable storage media for supporting callback of an Application Programming Interface (API) prefix in a Uniform Resource Identifier (URI). Background Art

[0002] In the Service Based Architecture (SBA) of the 3rd Generation Partnership Project (3GPP), a callback URI (e.g., a notification URI) is a URI used by a network function (NF) service producer (NFp) to send a callback request (e.g., a notification request) to a NF service consumer (NFc). The callback URI structure is worth studying and needs to be developed. Summary of the invention

[0003] In general, example embodiments of the present disclosure provide devices, methods, apparatus, and computer-readable storage media for supporting API prefixes in callback URIs.

[0004] In a first aspect, a first device is provided. The first device includes at least one processor and at least one memory storing instructions. The at least one memory and the instructions are configured to, together with the at least one processor, enable the first device to at least: receive a service request message from a second device, wherein the service request message includes a first callback uniform resource identifier (URI) having a first application programming interface (API) prefix; in response to determining that the second device is unreachable, send a discovery request to a third device to discover another second device instance; receive a discovery response from the third device; based on the discovery response, determine a second callback URI; and based on the second callback URI, send a callback request message to another second device instance.

[0005] In a second aspect, a second device is provided. The second device includes at least one processor and at least one memory storing instructions. The at least one memory and the instructions are configured to, together with the at least one processor, cause the second device to at least: send a service request message to a first device, wherein the service request message includes a first callback uniform resource identifier (URI) having a first application programming interface (API) prefix.

[0006] In a third aspect, a third device is provided. The third device includes at least one processor and at least one memory storing instructions. The at least one memory and the instructions are configured to, together with the at least one processor, enable the third device to at least: receive a request from a second device to register a profile of a second device including a default notification subscription, the default notification subscription including a first callback uniform resource identifier URI having a first application programming interface API prefix; receive a first discovery request from a first device to discover a second device; and send a first discovery response to the first device including a default notification subscription, the default notification subscription including a first URI having a first API prefix.

[0007] In a fourth aspect, a fourth device is provided. The fourth device includes at least one processor and at least one memory storing instructions. The at least one memory and the instructions are configured to, together with the at least one processor, enable the fourth device to at least: receive a service request message from a second device, wherein the service request message includes a first callback uniform resource identifier (URI) having a first application programming interface (API) prefix; send a service request message to a first device; receive a callback request message corresponding to the service request message from the first device; in response to determining that the second device is unreachable, send a discovery request to a third device to discover another second device instance; receive a discovery response from the third device; based on the discovery response, determine a second callback URI; and based on the second callback URI, send a callback request message to another second device instance.

[0008] In a fifth aspect, a method is provided. The method includes receiving a service request message from a second device. The service request message includes a first callback uniform resource identifier (URI) having a first application programming interface (API) prefix. The method also includes, in response to determining that the second device is unreachable, sending a discovery request to a third device to discover another second device instance. The method also includes receiving a discovery response from the third device; determining a second callback URI based on the discovery response; and sending a callback request message to the other second device instance based on the second callback URI.

[0009] In a sixth aspect, a method is provided. The method includes sending a service request message to a first device, wherein the service request message includes a first callback uniform resource identifier (URI) having a first application programming interface (API) prefix.

[0010] In a seventh aspect, a method is provided. The method includes receiving a request from a second device to register a profile of the second device including a default notification subscription, the default notification subscription including a first callback uniform resource identifier (URI) having a first application programming interface (API) prefix; receiving a first discovery request from a first device to discover the second device; and sending a first discovery response to the first device including the default notification subscription, the default notification subscription including a first URI having a first API prefix.

[0011] In an eighth aspect, a method is provided. The method includes receiving a service request message from a second device. The service request message includes a first callback uniform resource identifier (URI) having a first application programming interface (API) prefix. The method also includes sending a service request message to the first device, and receiving a callback request message corresponding to the service request message from the first device. The method also includes, in response to determining that the second device is unreachable, sending a discovery request to a third device to discover another second device instance. The method also includes receiving a discovery response from the third device; determining a second callback URI based on the discovery response; and sending a callback request message to another second device instance based on the second callback URI.

[0012] In a ninth aspect, an apparatus is provided, comprising components for performing the method according to the fifth aspect.

[0013] In a tenth aspect, an apparatus is provided, comprising components for performing the method according to the sixth aspect.

[0014] In an eleventh aspect, an apparatus is provided, comprising components for performing the method according to the seventh aspect.

[0015] In a twelfth aspect, an apparatus is provided, comprising components for performing the method according to the eighth aspect.

[0016] In a thirteenth aspect, a computer readable medium having instructions stored thereon is provided. When the instructions are executed on at least one processor of a device, the device performs the method according to the fifth aspect, the sixth aspect, the seventh aspect and the eighth aspect.

[0017] Other features and advantages of the embodiments of the present disclosure will also be apparent from the following description of specific embodiments when read in conjunction with the accompanying drawings, which illustrate, by way of example, the principles of the embodiments of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The embodiments of the present disclosure are presented in an exemplary sense, and their advantages will be explained in more detail below with reference to the accompanying drawings, in which:

[0019] Figure 1illustrates an example communication system in which implementations of the present disclosure may be implemented;

[0020] Figure 2 illustrates an example signaling diagram according to some embodiments of the present disclosure, which shows an example process for supporting API prefixes in callback URIs between NF Service Producers, NF Service Consumers, and Network Repository Functions (NRFs);

[0021] Figure 3 illustrates an example signaling diagram according to some embodiments of the present disclosure, which shows an example process for supporting API prefixes in callback URIs between NF Service Producers, NF Service Consumers, and NRFs and Service Communication Proxy (SCP);

[0022] Figure 4 illustrates a flow chart of an example method according to some embodiments of the present disclosure;

[0023] Figure 5 illustrates a flow chart of another example method according to some embodiments of the present disclosure;

[0024] Figure 6 illustrates a flow chart of another example method according to some embodiments of the present disclosure;

[0025] Figure 7 illustrates a flow chart of another example method according to some embodiments of the present disclosure;

[0026] Figure 8 shows a simplified block diagram of a device suitable for implementing an example embodiment of the present disclosure; and

[0027] Fig. 9 A block diagram of an example computer-readable medium is shown in accordance with some embodiments of the present disclosure.

[0028] Throughout the drawings, the same or similar reference numerals refer to the same or similar elements. DETAILED DESCRIPTION

[0029] The principle of the present disclosure will now be described with reference to some example embodiments. It should be understood that these embodiments are described only for the purpose of illustration and to help those skilled in the art understand and implement the present disclosure, and do not represent any limitation on the scope of the present disclosure. The disclosure described herein can be implemented in various other ways except the way described below.

[0030] In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs.

[0031] In this disclosure, references to "one embodiment," "an embodiment," and "an example embodiment" indicate that the described embodiment may include a particular feature, structure, or characteristic, but not every embodiment must include the particular feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in conjunction with an embodiment, it should be noted that it is within the knowledge of a person skilled in the art to affect such feature, structure, or characteristic in conjunction with other embodiments, whether or not explicitly described.

[0032] It should be understood that although the terms "first" and "second", etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish the functions of the various elements. As used herein, the term "and / or" includes any and all combinations of one or more of the listed terms.

[0033] The terms used herein are only used to describe specific embodiments and are not intended to limit the example embodiments. As used herein, the singular forms "a", "an", and "the" also include the plural forms, unless the context clearly indicates otherwise. It is further understood that the terms "comprises", "comprising", "has", "having", "includes", and / or "including" when used herein specify the presence of the features, elements, and / or components, etc., but do not exclude the presence or addition of one or more other features, elements, components, and / or combinations thereof.

[0034] As used in this application, the term "circuitry" may refer to one, more, or all of the following:

[0035] (a) a pure hardware circuit implementation (such as an implementation using only analog and / or digital circuitry), and

[0036] (b) a combination of hardware circuitry and software such as (where applicable):

[0037] (i) a combination of analog and / or digital hardware circuits and software / firmware, and

[0038] (ii) any portion of hardware processor(s) (including digital signal processor(s)) with software, software and memory(s) that work together to enable a device (such as a mobile phone or server) to perform various functions, and (c) hardware circuit(s) and / or processor(s), such as microprocessor(s) or portion(s) of microprocessor(s), which requires software (e.g., firmware) to operate, but which may be absent when not required for operation.

[0039] This definition of circuitry applies to all uses of the term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of only a hardware circuit or processor (or multiple processors) or a portion of a hardware circuit or processor and its accompanying software and / or firmware. For example, if applicable to a particular claim element, the term circuitry also covers a baseband integrated circuit or processor integrated circuit for a mobile device, or a similar integrated circuit in a server, cellular network device, or other computing or network device.

[0040] As used herein, the term "communication network" refers to a network that complies with any suitable communication standard, such as a fifth generation (5G) system, long term evolution (LTE), advanced LTE (LTE-A), wideband code division multiple access (WCDMA), high speed packet access (HSPA), narrowband Internet of Things (NB-IoT), etc. In addition, the communication between the terminal device and the network device in the communication network can be performed according to any suitable generation of communication protocols, including but not limited to the fourth generation (4G), 4.5G, the future fifth generation (5G) new radio (NR) communication protocol, and / or any other protocol currently known or to be developed in the future. The embodiments of the present disclosure can be applied to various communication systems. In view of the rapid development of communication, there will certainly be future types of communication technologies and systems that can be used to embody the present disclosure. The scope of the present disclosure should not be limited to the above-mentioned systems.

[0041] As used herein, the term "network device" refers to a node in a communication network, via which a terminal device accesses the network and receives services from the network. Depending on the terminology and technology applied, a network device may refer to a base station (BS) or an access point (AP), such as a NodeB (NodeB or NB), an evolved NodeB (eNodeB or eNB), a NR next-generation NodeB (gNB), a remote radio unit (RRU), a radio head (RH), a remote radio head (RRH), a relay, a low-power node (such as a femto, a micro), etc. The RAN split architecture includes a gNB-CU (centralized unit, which hosts RRC, SDAP, and PDCP), which controls multiple gNB-DUs (distributed units, which host RLC, MAC, and PHY). A relay node may correspond to the DU portion of an IAB node.

[0042] The term "terminal device" refers to any terminal device capable of wireless communication. As an example and not limitation, a terminal device may also be referred to as a communication device, a user equipment (UE), a subscriber station (SS), a portable subscriber station, a mobile station (MS), or an access terminal (AT). The terminal device may include, but is not limited to, a mobile phone, a cellular phone, a smart phone, a voice over IP (VoIP) phone, a wireless local loop phone, a tablet computer, a wearable terminal device, a personal digital assistant (PDA), a portable computer, a desktop computer, an image capture terminal device (such as a digital camera), a game terminal device, a music storage and playback device, a vehicle-mounted wireless terminal device, a wireless endpoint, a mobile station, a laptop embedded device (LEE), a laptop vehicle-mounted device (LME), a USB dongle, a smart device, a wireless customer premises equipment (CPE), an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical equipment and applications (e.g., remote surgery), industrial equipment and applications (e.g., robots and / or other wireless devices operating in the context of an industrial and / or automated processing chain), consumer electronic devices, devices operating on commercial and / or industrial wireless networks, etc. The terminal device may also correspond to the mobile terminal (MT) part of an integrated access and backhaul (IAB) node (also known as a relay node). In the following description, the terms "terminal device", "communication device", "terminal", "user equipment" and "UE" may be used interchangeably.

[0043] Although in various example embodiments, the functions described herein may be performed in fixed and / or wireless network nodes, in other example embodiments, the functions may be implemented in a user equipment device (such as a mobile phone or tablet or laptop or desktop computer or mobile IoT device or fixed IoT device). For example, the user equipment device may be equipped with corresponding functions described in combination with (multiple) fixed and / or wireless network nodes as required. The user equipment device may be a user equipment and / or a control device (such as a chipset or processor) that is configured to control the user equipment when installed in the user equipment. Examples of such functions include bootstrapping server functions and / or home subscriber servers, which may be implemented in the user equipment device by providing software to the user equipment device, which is configured to cause the user equipment device to perform from the perspective of these functions / nodes.

[0044] As described above, in the 5G service based architecture (SBA), the callback URI (e.g., notification URI) is a URI used by the NF service producer (NFp) to send a callback request (e.g., notification request) to the NF service consumer (NFc).

[0045] In the latest version of 3GPP TS29.501, the callback URI is defined to have the following structure:

[0046] URI = scheme:"" / / "host[":"port] / path

[0047] Where 'path' is the path to the NF service consumer resource.

[0048] Unlike resource URIs and custom action URIs, the callback URI structure does not support an optional deployment-specific string, also known as an API prefix.

[0049] In addition, in the change request (CR) agreed upon in 3GPP CT4, the NF service consumer is provided with the flexibility to implement different NF service consumer instances that share the same authority information. In the agreed CR, NF service consumer instances that share the same authority can be distinguished from each other by using unique prefix information for each NF service consumer instance. The 3gpp-Sbi-Consumer-Info instance is extended with a new "callback-uri-prefix".

[0050] The above callback URI structure does not explicitly list the deployment specific API prefix, which is usually not a problem. If desired, the NF service consumer (e.g., NF-1) can still deploy a notification endpoint with a specific prefix, and thus the notification URI can implicitly include this deployment specific API prefix (e.g., api-prefix-1) as the leading part of the 'path' field.

[0051] However, when the above NF-1 notification endpoint with api-prefix-1 is not reachable, the situation is different. The NF Service Producer or SCP can use the binding information received from the NF Service Consumer along with the callback URI (e.g., when the subscription to the notification is performed) to reselect a different NF Service Consumer instance, or when the binding process is not supported, utilize the information that the NF Service Consumer is part of a NF (service) set or supports context sharing across its NF Service instances.

[0052] When this happens, using the binding indication (if available) or the NF profile of the NF service consumer in the NRF, the notification sender (which is also the NF service producer for the subscription service) or the SCP issues an NF discovery request to the NRF to reselect the endpoint address of another NF or another NF service instance (e.g., NF-2) to construct a new notification endpoint to send notifications. Specifically, the notification sender or SCP can exchange the authority part of the notification URI (or callback URI) with the new notification endpoint address and use the URI in subsequent notifications.

[0053] If NF-1 deploys a notification endpoint with api-prefix-1, and after the above reselection process is applied, api-prefix-1 of NF-1 will be transferred and sent to the new notification endpoint of NF-2.

[0054] This can be problematic. Since api-prefix-1 is deployment specific, some information that is specific to NF-1 and may only apply to NF-1 is included in api-prefix-1. This can include, but is not limited to, custom software versions, HTTP2 routers, etc. api-prefix-1 will be sent to NF-2. But NF-2 may not have the same custom software version as NF-1, or NF-2 may not even share the same HTTP2 router as NF-1, because it is very reasonable for the backup NF (NF-2 can be considered a backup for NF-1) to be in a different cluster, region, or location, so the HTTP2 router used to reach NF-2 can be different.

[0055] Therefore, the new notification endpoint of NF-2 will not be routed to NF-2 due to route selector mismatch, or NF-2 may not be recognized or processed correctly due to customized software version differences.

[0056] Furthermore, when the SCP is responsible for reselecting the target NF service consumer, the SCP cannot determine whether the callback URI includes a prefix, and therefore cannot determine whether it should also replace the prefix portion of the callback URI with the prefix of the reselected target NF service instance.

[0057] At present, in order to solve the above problems, some methods can be taken. One method may be not to include the API prefix in the notification URI (or callback URI) at all. This means that there is no deployment-specific flexibility when deploying notification endpoints. Therefore, some key information (e.g., customized software version, HTTP2 routing selector) cannot be conveyed in the notification URI (or callback URI) that is inconsistent with the resource URI, and also causes problems in actual business due to the lack of key information.

[0058] Another approach could be to always use the same API prefix in all notification URIs (or callback URIs) generated from NFs with a binding relationship. This means that any specific information conveyed in the API prefix (such as customized software version, HTTP2 route selector) should be the same in these NFs. This seems simple, but it can cause serious problems. If the API prefixes are the same, it means that the key deployment-specific information conveyed in the API prefix is ​​also the same on both sides. For example, two NFs run the same customized software version. If one NF is unreachable due to a software defect, it is likely that the other NF also has the same defect and may also be unreachable. This also means that due to the need to maintain the same customized software version, the two NFs should probably be upgraded together, and canary or phased upgrades, etc., are not possible between NFs with a binding relationship.

[0059] Another approach introduces the option of having a prefix in the callback URI, but this solution has several drawbacks, for example, the SCP cannot know when receiving the callback request whether the callback prefix includes the prefix (because the 3gpp-Sbi-Consumer-Info header is not signaled in the callback / notification request), and therefore, cannot know whether the SCP should also modify the prefix when reselecting a different NF Service Consumer instance. Furthermore, the support of prefixes in the callback URI is unnecessarily limited to the use case where NF Service Consumer instances share the same authority. The NF Service Consumer reselection process by the SCP does not work.

[0060] Embodiments of the present disclosure propose a method for supporting API prefixes in callback URIs. The proposed solution enhances the structure of notification URIs (or callback URIs) to explicitly show the optional presence of API prefixes.

[0061] The proposed solution also enhances the 3gpp-Sbi-Binding header and the 3gpp-Sbi-Routing-Binding header to let them pass a new parameter to indicate the presence and value of the API prefix in the notification URI (or callback URI), if the notification URI (or callback URI) does have an API prefix.

[0062] When the binding procedure is not supported, the proposed solution also enables explicit signaling of the presence and value of the API prefix in the callback URI, so that the SCP can know that the callback URI contains the prefix part. The explicit indication about the presence of the prefix part in the callback URI can be indicated in the HTTP header, for example in an extension of the 3gpp-Sbi-Request-Info header, or in a new 3gpp-Sbi-callback-uri-prefix header, or in a new 3gpp-Sbi-callback-uri-apiRoot header (and thus in a new prefix or apiRoot IE in DefaultNotificationSubscriptions).

[0063] In addition, the proposed solution also enhances the NF service consumer reselection process by exchanging not only the authority part of the notification URI (or callback URI) but also the API prefix, i.e., replacing the API prefix (if any) with the API prefix (if any) returned from the reselection NF discovery process to form a new notification URI (or callback URL), so that the reselection can be performed by the NF service producer or SCP.

[0064] The following will refer to Figures 1 to 9 The principles and implementations of the present disclosure are described in detail.

[0065] Figure 1 An example communication system 100 is shown in which embodiments of the present disclosure may be implemented. The system 100 includes a NF service producer 101, a NF service consumer 102, an NRF 103, and an optional SCP 104.

[0066] In some embodiments, the NF service consumer 102 may send a service request (e.g., a subscription creation request) to the NF service producer 101, and the NF service producer 101 may send a service response to the NF service consumer 102 to inform whether the request is successfully processed at the NF service producer 101. In addition, the NF service producer 101 may send a notification request to the NF service consumer 102, and the NF service consumer 102 may respond to the notification request with a notification response, which informs whether the notification is successfully processed at the NF service consumer 102. In some embodiments, the NF service producer 101 may also send a discovery request to the NRF 103, and in response to receiving the discovery request, the NRF 103 may send a discovery response to the NF service producer 101.

[0067] In some embodiments, for example, in indirect communication, SCP 103 is provided. In this case, NF service consumer 102 may send a service request (e.g., a subscription creation request) to SCP 103, and SCP 103 forwards the service request to NF service producer 101. In response to the service request, NF service producer 101 may send a service response to SCP 103 to inform whether the request is successfully processed at NF service producer 101, and SCP 103 may forward the service response to NF service consumer 102. In addition, NF service producer 101 may send a notification request to SCP 103, and SCP 103 may forward the notification request to NF service consumer 102. In response to the notification request, NF service consumer 102 may send a notification response to SCP 103 to inform whether the notification is successfully processed at NF service consumer 102, and SCP 103 may forward the notification response to NF service consumer 102. In some embodiments, SCP 103 may also communicate with NRF 103, for example, to perform a discovery process.

[0068] Communications in the communication system 100 may be implemented according to any generation of communication protocols currently known or to be developed in the future. Examples of communication protocols include, but are not limited to, fourth generation (4G), 4.5G, fifth generation (5G) communication protocols, 5.5G, 5G advanced networks, or sixth generation (6G) networks.

[0069] Figure 2 An example signaling diagram is illustrated according to some example embodiments of the present disclosure, which shows an example process 200 for supporting API prefixes in callback URIs. For discussion purposes, reference will be made to Figure 1 Describe process 200. Process 200 may involve Figure 1 The NF service producer 101, NF service consumer 102 and NRF 103 are shown. Figure 1 The process 200 has been described in the communication system 100, but the process can also be applied to other communication scenarios.

[0070] like Figure 2 As shown, the NF service consumer 102 sends 210 a service request message (e.g., a subscription creation request message) to the NF service producer 101. The service request message includes a first URI (e.g., a callback URI) having a first API prefix, which is a URI at which the NF service consumer expects to receive subsequent notification (i.e., callback) requests from the NF service producer. In some embodiments, the first callback URI may have the following structure:

[0071] URI = {apiRoot} / path

[0072] Where apiRoot is the concatenation of:

[0073] - Scheme (i.e., "http" or "https")

[0074] -Fixed string ": / / "

[0075] - Authority (host and optional port), the host should be represented by a carrier-specific fully qualified domain name (FQDN)

[0076] - An optional deployment specific string (ie, API prefix) that starts with a " / " character.

[0077] That is, the URI has an optional API prefix. With this enhancement, any notification URI (or callback URI) sent as part of a subscription creation request message can have the flexibility to include an API prefix.

[0078] Additionally, the 3gpp-Sbi-Binding header (eg, present in a subscription creation request) may include a new optional parameter indicating the presence and actual value of the API prefix in the URI structure defined above.

[0079] There are two options to indicate the presence and value of the API prefix. For example, in some embodiments, the value of the API prefix is ​​presented directly in the new parameter. Alternatively, in the new parameter, the remainder of the 'path' of the URI after stripping the leading API prefix is ​​listed (or just the apiRoot is listed).

[0080] An example of a 3gpp-Sbi-Binding header for the case where the value of the API prefix is ​​directly presented in the new parameter is provided as follows:

[0081] 3gpp-Sbi-Binding="3gpp-Sbi-Binding"":"1#(OWS"bl="blvalue 1*(""OWSparameter)[""OWS recoverytime][""OWS notif-receiver][""OWS callback-uri-prefix][""OWS" group="groupvalue][1*(""OWS groupparameter)])

[0082] callback-uri-prefix="callback-uri-prefix=" An example of deploying a specific string for use in the case of listing the remainder of the 'path' from a URI with the leading API prefix stripped is provided as follows:

[0083] 3gpp-Sbi-Binding="3gpp-Sbi-Binding"":"1#(OWS"bl="blvalue 1*(""OWSparameter)[""OWS recoverytime][""OWS notif-receiver][""OWS uri-path-without-prefix][""OWS" group="groupvalue][1*(""OWS groupparameter)])

[0084] uri-path-without-prefix="uripath="The path portion of the URI with the API prefix stripped

[0085] The names of the new parameters are provided for illustration only and do not represent any limitation. It should be noted that any other naming conventions for the new parameters different from the examples given below are also within the scope of the present disclosure.

[0086] With this enhancement, a binding indication that may be sent as part of a subscription request may indicate the presence and actual value of the API prefix in the notification URI (or callback URI).

[0087] Note that this covers both the "subscription event" and "callback" cases specified by the "scope" parameter in the 3gpp-Sbi-Binding header defined in 3GPP TS 29.500. This approach solves the problem in a simple way when the binding procedure is supported.

[0088] like Figure 2 As shown, when an event to which the NF service consumer has subscribed occurs later, the NF service producer 101 determines 220 that the NF service consumer 102 is unreachable, and in response to the determination, the NF service producer 101 performs a NF service consumer reselection process. For example, the NF service producer 101 sends 230 a discovery request to the NRF 103 to discover an alternative NF service consumer instance for sending a notification request, and receives 240 a discovery response from the NRF 103.

[0089] In some embodiments, the NF service consumer reselection process can be enhanced by requiring not only the endpoint address, i.e., the authority portion of the notification URI (or callback URI), but also the API prefix to be exchanged, i.e., replacing the API prefix (if any) with the API prefix (if any) returned from the reselection NF discovery process to form a new notification URI (or callback URI).

[0090] The service name that may be present in the callback URI or binding indication is used to discover alternative NF Service Consumer instances.

[0091] like Figure 2 As shown, the NF service producer 101 determines 250 a second callback URI based on the discovery response.

[0092] Here, an example is given below. Only the new parameters in the present disclosure are shown in the 3gpp-Sbi-Binding header, and the remaining other parameters are shown as "...". The names of the new parameters are provided for illustration and do not represent any limitation. It should be noted that any other naming conventions for new parameters that differ from this example, as well as different combinations of existing parameters in the 3gpp-Sbi-Binding header (which may or may not appear with the new parameters in the 3gpp-Sbi-Binding header) are within the scope of the present disclosure.

[0093] The first URI (notification URI or callback URI) sent in the subscription creation request can be as follows:

[0094] http: / / a.example.com / api-prefix-1 / path-to-notification-target

[0095] The binding indication sent in the subscribe message can be as follows:

[0096] 3gpp-Sbi-Binding:…;callback-uri-prefix= / api-prefix-1;…

[0097] As a result of NF discovery using the information provided in the bind indication, the new endpoint address (e.g., FQDN) may be as follows:

[0098] b.example.com

[0099] The API prefix resulting from NF discovery using the information provided in the bind indication may be as follows:

[0100] / api-prefix-2

[0101] In the case where the present disclosure is applied, the new notification URI (or callback URI) to which the notification is sent (i.e., the second callback URI) may become:

[0102] http: / / b.example.com / api-prefix-2 / path-to-notification-target

[0103] After NF discovery, there may be no new API prefix, for example, no service name is given in the binding indication, or there is no API prefix in the discovered NF service, etc. In this case, it is safe to only remove the old API prefix (i.e., the first API prefix) without adding any new API prefix; the new notification URI (or callback URI) (i.e., the second callback URI) to which notifications are sent may become like this in the context of this example, i.e., removing the old API prefix and only changing the endpoint address:

[0104] http: / / b.example.com / path-to-notification-target

[0105] The present invention has many advantages. For example, each notification endpoint can have an independent API prefix for specific deployment purposes, which enables independent customized software versions, independent HTTP2 routing rules, independent upgrade stages, etc. between NFs with binding notifications. Therefore, the overall reliability and robustness of the system are improved.

[0106] Different NF Service Consumer instances can share the same permissions but with different prefixes. The NF Service Producer can now reselect an alternative NF Service Consumer instance and replace the permissions and prefix in the callback URI with the permissions and callback URI of the new NF Service Consumer instance, e.g.

[0107] Replace https: / / amf45.operator.com / servinst123 / pdusession / v1 / with

[0108] https: / / amf45.operator.com / servinst65 / pdusession / v1 / where “pdusession” corresponds to the NF Service Consumer service (which can be a custom service or a standard service name in the example).

[0109] like Figure 2 As shown, the NF service producer 101 sends 260 a callback request message (eg, a notification request message) to the alternative NF service consumer instance based on the second callback URI. The alternative NF service consumer instance can be a reachable address of the NF service consumer 102 or a NFc different from the NF service consumer 102.

[0110] Figure 3 An example signaling diagram is illustrated according to some example embodiments of the present disclosure, which shows an example process 300 for supporting API prefixes in callback URIs. For discussion purposes, reference will be made to Figure 1Describe process 300. Process 300 may involve Figure 1 NF service producer 101, NF service consumer 102, NRF 103 and SCP 104 are shown. Figure 1 The process 300 has been described in the communication system 100, but the process can also be applied to other communication scenarios.

[0111] like Figure 3 As shown, the NF service consumer 102 sends 310 a service request message (eg, a subscription creation request message) to the SCP 104. The service request message includes a first URI (eg, a callback URI) having a first API prefix, and the first callback URI may have the same Figure 2 The SCP 104 sends 320 a service request message to the NF service producer 101 .

[0112] If the NF service producer 101 determines 330 that an event that triggers the sending of a callback request message to the NF service consumer 102 occurs, the NF service producer 101 sends a callback request message to the SCP 104, i.e., the SCP 104 receives 340 the callback request message from the NF service producer 101. Then, if the SCP 104 determines 350 that the NF service consumer 102 is unreachable, the SCP 104 performs a NF service consumer reselection process. For example, the SCP 104 sends 360 to the NRF 103 to reselect an alternative NF service consumer instance for the relevant service request message, and receives 370 a discovery response from the NRF 103.

[0113] In addition to the above reference Figure 2 In addition to the described 3gpp-Sbi-Binding header enhancements, the 3gpp-Sbi-Routing-Binding header may also be enhanced to optionally carry a new parameter for indicating the presence and actual value of the API prefix in the callback URI (or notification URI).

[0114] Similar to the 3gpp-Sbi-Binding header enhancement, there are also two options to indicate the presence and actual value of the API prefix in the callback URI (or notification URI). For example, in some embodiments, the value of the API prefix is ​​directly presented in the new parameter. Alternatively, in the new parameter, the remainder of the 'path' from the URI with the leading API prefix stripped is listed (or just the apiRoot is listed).

[0115] In some embodiments, when the binding procedure is not supported, it enables explicit signaling of the presence and value of the API prefix in the callback URI so that the SCP 104 can know that the callback URI contains the prefix part. The explicit indication of the presence of the prefix part in the callback URI can be indicated in the HTTP header, for example in an extension of the 3gpp-Sbi-Request-Info header, or in a new 3gpp-Sbi-callback-uri-prefix header.

[0116] For example, the new 3gpp-Sbi-callback-uri-prefix header is defined as a 3GPP HTTP custom header as follows:

[0117] 3gpp-Sbi-callback-uri-prefix header field = "3gpp-Sbi-callback-uri-prefix"":"OWS prefix

[0118] Prefix = absolute value of path

[0119] For example: 3gpp-Sbi-callback-uri-prefix: / a / b / c

[0120] Alternatively, a new 3gpp-Sbi-callback-apiRoot header may be defined as follows: 3gpp-Sbi-callback-apiRoot header field = "3gpp-Sbi-callback-apiRoot"":"OWS scheme": / / " authority[prefix]

[0121] Scheme = "http" / "https"

[0122] permissions = host[":"port]

[0123] Port = *DIGIT

[0124] Prefix = absolute value of path

[0125] For example: 3gpp-Sbi-callback-apiRoot:https: / / example.com / a / b / c

[0126] When the binding process is not supported, it may be necessary to explicitly indicate the name of the service to the NF Service Consumer in the callback URI, as shown below:

[0127] URI = {apiRoot} / <service name> / path

[0128] This is to allow the NF Service Producer 101 or SCP 104 to reselect an alternative NF Service Consumer instance from the same service. Note that when the binding procedure is supported, the service name of the NF Service Consumer can already be signaled through a different parameter in the binding indication.

[0129] Therefore, when the binding procedure is not supported, the API prefix can be identified in the profile of the NF Service Consumer registered at the NRF for explicit subscriptions (i.e., subscriptions created by the NF Service Consumer through a subscription creation request); for default notification subscriptions (i.e., implicit subscriptions registered by the NF Service Consumer in its NF Profile in the NRF), the API prefix can be identified by the newly introduced IE within DefaultNotificationSubscriptions defined in Table 1 below:

[0130] Table 1

[0131]

[0132] Furthermore, when SCP 104 reselects a consumer service instance, it will add a 3gpp-target-apiRoot header in the notification response sent to NF service producer 101, which notification response will newly include the new API prefix (if any) of the new callback URI in addition to the new authority.

[0133] like Figure 3 As shown, SCP 104 determines 380 a second callback URI based on the discovery response. The determination of the second callback URI has been described above with reference to Figure 2 Described.

[0134] SCP 104 then sends 390 a callback request message based on the second callback URI.

[0135] Figure 4 A flowchart of an example method 400 according to some embodiments of the present disclosure is illustrated. The method 400 may be performed in a Figure 1 The NF service producer 101 or SCP 104 is shown as being implemented. For the purpose of discussion, reference will be made to Figure 1-Figure 3 Method 400 is described.

[0136] At block 410, a first device (eg, NF service producer 101 or SCP 104) receives a service request message from a second device (eg, NF service consumer 102). The service request message includes a first callback URI having a first API prefix.

[0137] In some embodiments, the first callback URI may include an apiRoot portion and a path portion. The apiRoot portion may include at least a first API prefix and a first authority portion.

[0138] In some embodiments, the service request message may also include binding information. Binding information may also be received and indicate the value of the first API prefix in the first parameter. In some embodiments, the binding information may list the first API prefix of the first callback URI in the first parameter. Alternatively or additionally, the binding information may list the apiRoot portion of the first callback URI in the first parameter. Alternatively or additionally, the binding information may list the remainder of the first callback URI in the first parameter, with the apiRoot portion stripped.

[0139] At block 420 , in response to determining that the second device is unreachable, the first device sends a discovery request to a third device (eg, NRF 103 ) to discover additional second device instances to which notifications of related subscriptions will be sent.

[0140] At block 440 , the first device receives a discovery response from the third device.

[0141] At block 450 , the first device determines a second callback URI based on the discovery response.

[0142] In some embodiments, the first device may strip the first API prefix from the first callback URI based on the first parameter of the binding information, and if the second API prefix is ​​indicated in the discovery response, fill the first callback URI with the second API prefix indicated in the discovery response to form the second callback URI. Alternatively or additionally, the first device may strip the first permission portion from the first callback URI based on the first parameter of the binding information, and fill the first callback URI with the second permission portion indicated in the discovery response to form the second callback URI.

[0143] In some embodiments, if the second device does not support the binding process (e.g., the service request message does not include binding information), the service request message may indicate the value of the first API prefix in the second parameter. The second parameter may include an HTTP header or a new header. In some embodiments, the service request message may list the first API prefix of the first callback URI in the second parameter. Alternatively or additionally, the service request message may list the apiRoot portion of the first callback URI in the second parameter. Alternatively or additionally, the service request message may list the remainder of the first callback URI in the second parameter, with the apiRoot portion stripped.

[0144] In some embodiments, the first device may strip the first API prefix from the first callback URI based on the second parameter of the callback request message, and if the second API prefix is ​​indicated in the discovery response, fill the first callback URI with the second API prefix indicated in the discovery response to form the second callback URI. Alternatively or additionally, the first device may strip the first permission portion from the first callback URI based on the second parameter of the binding information, and fill the first callback URI with the second permission portion indicated in the discovery response to form the second callback URI.

[0145] At block 460 , the first device sends a callback request message to the additional second device instance based on the second callback URI.

[0146] In some embodiments, the service request message may be a subscription creation request message, and the callback request message may be a notification request message.

[0147] In some embodiments, the additional second device instance may be a NF service consumer different from the second device, or the additional second device instance may be a reachable address of the second device.

[0148] Figure 5 A flowchart of an example method 500 according to some embodiments of the present disclosure is illustrated. The method 500 may be performed in Figure 1 The NF service consumer 102 is shown as being implemented. For the purpose of discussion, reference will be made to Figure 1-Figure 3 Method 500 is described.

[0149] At block 510, the second device (eg, NF service consumer 102) sends a service request message to the first device (eg, NF service producer 101 or SCP 104). The service request message includes a first callback URI having a first API prefix.

[0150] In some embodiments, the first callback URI may include an apiRoot portion and a path portion. The apiRoot portion may include at least a first API prefix and a first authority portion.

[0151] In some embodiments, the service request message may further include binding information. The binding information may indicate the value of the first API prefix in the first parameter. In some embodiments, the binding information may list the first API prefix of the first callback URI in the first parameter. Alternatively or additionally, the binding information may list the apiRoot portion of the first callback URI in the first parameter. Alternatively or additionally, the binding information may list the remainder of the first callback URI in the first parameter, with the apiRoot portion stripped.

[0152] In some embodiments, if the second device does not support the binding process (e.g., the service request message does not include binding information), the service request message may indicate the value of the first API prefix in the second parameter. The second parameter may include an HTTP header or a new header. In some embodiments, the service request message may list the first API prefix of the first callback URI in the second parameter. Alternatively or additionally, the service request message may list the apiRoot portion of the first callback URI in the second parameter. Alternatively or additionally, the service request message may list the remainder of the first callback URI in the second parameter, with the apiRoot portion stripped.

[0153] In some embodiments, the second device may receive a callback request message having a second callback URI from the first device. The first API prefix of the second callback URI may be stripped based on the first parameter of the binding information. Alternatively, the first API prefix of the second callback URI may be stripped based on the second parameter of the service request message.

[0154] In some embodiments, the second callback URI may include a second API prefix replacing the first API prefix.Alternatively or additionally, the second callback URI may include a second permissions portion replacing the first second permissions portion.

[0155] In some embodiments, the service request message is a subscription creation request message and the callback request message is a notification request.

[0156] Figure 6 A flowchart of an example method 600 according to some embodiments of the present disclosure is illustrated. The method 600 may be performed in Figure 1 The NRF 103 shown is implemented. For the purpose of discussion, reference will be made to Figure 1-Figure 3 Method 600 is described.

[0157] At block 610, a third device (eg, NRF 103) receives a request from a second device (eg, NF service consumer 102) to register a profile of the second device including a default notification subscription. The default notification subscription includes a first URI having a first API prefix.

[0158] At block 620, the third device receives a first discovery request for discovering a second device from a first device (e.g., NF service producer 101 or SCP 104). Then, at block 630, the third device sends a first discovery response including a default notification subscription to the first device, the default notification subscription including a first URI having a first API prefix.

[0159] If the first device determines that the second device is not reachable via the first URI, for example, after an event occurs that triggers the first device to send a callback request message to the second device, the first device can perform a rediscovery process. In this case, the third device can receive a second discovery request from the first device to discover additional instances of the second device.

[0160] In some embodiments, the third device may determine the content of the second discovery response based on the default notification subscription and the second discovery request.

[0161] In some embodiments, the third device may send a second discovery response to the first device, the second discovery response including a second callback URI having a second API prefix of the additional second device instance.

[0162] In some embodiments, the additional second device instance may be a NF service consumer different from the second device, or the additional second device instance may be a reachable address of the second device.

[0163] Figure 7 A flowchart of an example method 700 according to some embodiments of the present disclosure is illustrated. The method 700 may be performed in a manner such as Figure 1 For the purpose of discussion, reference will be made to SCP 104. Figure 1-Figure 3 Method 700 is described.

[0164] At block 710, the fourth device (eg, SCP 104) receives a service request message from the second device (eg, NF service consumer 102). The service request message includes a first callback URI having a first API prefix.

[0165] In some embodiments, the first callback URI may include an apiRoot portion and a path portion. The apiRoot portion may include at least a first API prefix and a first authority portion.

[0166] In some embodiments, the service request message may further include binding information. The binding information may indicate the value of the first API prefix in the first parameter. In some embodiments, the binding information may list the first API prefix of the first callback URI in the first parameter. Alternatively or additionally, the binding information may list the apiRoot portion of the first callback URI in the first parameter. Alternatively or additionally, the binding information may list the remainder of the first callback URI in the first parameter, with the apiRoot portion stripped.

[0167] At box 720, the fourth device sends a service request message to the first device (e.g., the NF service producer 102).

[0168] At block 730 , the fourth device receives a callback request message corresponding to the service request message from the first device.

[0169] In some embodiments, the callback request message may include route binding information indicating the value of the first API prefix in the second parameter. In some embodiments, the callback request message may include route binding information for the first API prefix of the first callback URI listed in the second parameter. Alternatively or additionally, the callback request message may include route binding information for the apiRoot portion of the first callback URI listed in the second parameter. Alternatively or additionally, the callback request message may include route binding information for the remainder of the first callback URI listed in the second parameter, with the apiRoot portion stripped.

[0170] In some embodiments, the callback request message may indicate the value of the first API prefix in the third parameter. The third parameter may include an HTTP header or a new header. In some embodiments, the callback request message may list the first API prefix of the first callback URI in the second parameter. Alternatively or additionally, the service request message may list the apiRoot portion of the first callback URI in the second parameter. Alternatively or additionally, the callback request message may list the remainder of the first callback URI in the second parameter, with the apiRoot portion stripped.

[0171] At block 740 , in response to determining that the second device is unreachable, the fourth device sends a discovery request for service request message to the third device (eg, NRF 103 ).

[0172] At block 750 , the fourth device receives a discovery response from the third device to discover additional second device instances.

[0173] At block 760 , the fourth device determines a second callback URI based on the discovery response.

[0174] In some embodiments, to determine the second callback URI, the fourth device may strip the first API prefix from the first callback URI based on the second parameter of the binding information, and if the second API prefix is ​​indicated in the discovery response, fill the first callback URI with the second API prefix indicated in the discovery response to form the second callback URI. Alternatively or additionally, the fourth device may strip the first permission portion from the first callback URI based on the second parameter of the binding information, and fill the first callback URI with the second permission portion indicated in the discovery response to form the second callback URI.

[0175] In some embodiments, to determine the second callback URI, the fourth device may strip the first API prefix from the first callback URI based on the third parameter of the callback request message, and if the second API prefix is ​​indicated in the discovery response, fill the first callback URI with the second API prefix indicated in the discovery response to form the second callback URI. Alternatively or additionally, the fourth device may strip the first permission portion from the first callback URI based on the third parameter of the callback request message, and fill the first callback URI with the second permission portion indicated in the discovery response to form the second callback URI.

[0176] At block 770 , the fourth device sends a callback request message to the additional second device instance based on the second callback URI.

[0177] In some embodiments, the service request message is a subscription creation request message and the callback request message is a notification request message.

[0178] In some embodiments, the additional second device instance may be a NF service consumer different from the second device, or the additional second device instance may be a reachable address of the second device.

[0179] Figure 8 800 is a simplified block diagram of a device 800 suitable for implementing an embodiment of the present disclosure. The device 800 may be provided to implement a communication device, such as Figure 1 The NF service producer 101, NF service consumer 102, NRF 103 and SCP 104 are shown. As shown in the figure, the device 800 includes one or more processors 810, one or more memories 840 coupled to the processor 810, and one or more communication modules (TX / RX) 840 coupled to the processor 810.

[0180] The TX / RX 840 is used for bidirectional communication. The TX / RX 840 has at least one antenna to facilitate communication. The communication interface may represent any interface required to communicate with other network elements.

[0181] Processor 810 may be of any type suitable for the local technology network, and may include, as non-limiting examples, one or more of a general purpose computer, a special purpose computer, a microprocessor, a digital signal processor (DSP), and a processor based on a multi-core processor architecture. Device 800 may have multiple processors, such as application specific integrated circuit chips that are time slaved to a clock synchronized with a main processor.

[0182] The memory 820 may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memories include, but are not limited to, read-only memory (ROM) 824, electrically programmable read-only memory (EPROM), flash memory, hard disk, compact disk (CD), digital video disk (DVD), and other magnetic storage and / or optical storage. Examples of volatile memories include, but are not limited to, random access memory (RAM) 822 and other volatile memories that do not persist during power outages.

[0183] Computer program 830 includes computer executable instructions executed by associated processor 810. Program 830 may be stored in ROM 820. Processor 810 may perform any suitable actions and processes by loading program 830 into RAM 820.

[0184] The embodiments of the present disclosure may be implemented by a program 830, so that the device 800 may execute the reference Figures 2 to 7 Any process of the present disclosure discussed. The embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.

[0185] In some embodiments, the program 830 may be tangibly contained in a computer-readable medium, which may be included in the device 800 (such as in the memory 820) or in other storage devices accessible to the device 800. The device 800 may load the program 830 from the computer-readable medium to the RAM 822 for execution. The computer-readable medium may include any type of tangible non-volatile memory, such as ROM, EPROM, flash memory, hard disk, CD, DVD, etc. Fig. 9 An example of a computer readable medium 900 in the form of a CD or DVD is shown. The computer readable medium has a program 830 stored thereon.

[0186] Generally, various embodiments of the present disclosure may be implemented using hardware or dedicated circuits, software, logic, or any combination thereof. Some aspects may be implemented using hardware, while other aspects may be implemented using firmware or software that may be executed by a controller, microprocessor, or other computing device. Although various aspects of the embodiments of the present disclosure are illustrated and described as block diagrams, flow charts, or using some other graphical representations, it should be understood that, as non-limiting examples, the blocks, devices, systems, techniques, or methods described herein may be implemented using hardware, software, firmware, dedicated circuits or logic, general-purpose hardware or controllers or other computing devices, or some combination thereof.

[0187] The present disclosure also provides at least one computer program product tangibly stored on a transient or non-transitory computer-readable storage medium. The computer program product includes computer executable instructions, such as instructions included in a program module, which are executed in a device on a target real or virtual processor to perform the above referenced Figures 4 to 7 Methods 400-700 are described. Typically, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform specific tasks or implement specific abstract data types. In various embodiments, the functions of program modules can be combined or split between program modules as needed. The machine executable instructions of program modules can be executed in local or distributed devices. In distributed devices, program modules can be located in both local and remote storage media.

[0188] The program code for executing the method of the present disclosure can be written in any combination of one or more programming languages. These program codes can be provided to a processor or controller of a general-purpose computer, a special-purpose computer or other programmable data processing device so that the program code is implemented when executed by the processor or controller in the flow chart and / or the block diagram. The program code can be executed completely on the machine, partially on the machine, as an independent software package, partially on the machine and partially on a remote machine, or completely on a remote machine or server.

[0189] In the context of the present disclosure, instructions or related data may be carried by any suitable carrier to enable a device, apparatus or processor to perform various processes and operations as described above. Examples of carriers include signals, computer-readable media, etc.

[0190] The computer readable medium can be a computer readable signal medium or a computer readable storage medium. The computer readable medium can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared or semiconductor systems, devices or equipment, or any suitable combination of the foregoing. A more specific example of a computer readable storage medium will include an electrical connection with one or more wires, a portable computer floppy disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0191] In addition, although the operations are described in a particular order, this should not be understood as requiring such operations to be performed in the particular order shown or in order or performing all the operations shown to obtain the desired result. In some cases, multitasking and parallel processing may be advantageous. Similarly, although several specific implementation details are included in the above discussion, these should not be interpreted as limitations on the scope of the present disclosure, but rather descriptions of features that may be specific to a particular embodiment. Certain features described in the context of a separate embodiment may also be implemented in combination in a single embodiment. On the contrary, the various features described in the context of a single embodiment may also be implemented in multiple embodiments individually or in any suitable sub-combination.

[0192] Although the disclosure has been described in language specific to structural features and / or methodological acts, it should be understood that the disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features or acts described above are disclosed as example forms of implementing the claims.

[0193] The expression “at least one of A or B” in this document refers to A, or B, or both A and B.

Claims

1. A first device, comprising: at least one processor; as well as at least one memory storing instructions that, when executed by the at least one processor, cause the first device to at least: receiving a service request message from a second device, wherein the service request message includes: a first callback uniform resource identifier URI having a first application programming interface API prefix; In response to determining that the second device is unreachable, sending a discovery request to a third device to discover additional second device instances; receiving a discovery response from the third device; Based on the discovery response, determining a second callback URI; and Based on the second callback URI, a callback request message is sent to the additional second device instance. 2 . The first device according to claim 1 , wherein the first callback URI comprises an apiRoot portion and a path portion, and the apiRoot portion comprises at least the first API prefix and a first authority portion. 3 . The first device according to claim 2 , wherein the service request message further includes binding information, and the binding information indicates a value of the first API prefix in a first parameter.

4. The first device according to claim 3, wherein the binding information lists at least one of the following in the first parameter: the first API prefix of the first callback URI, the apiRoot portion of the first callback URI, or The remainder of the first callback URI with the apiRoot portion stripped off.

5. The first device of claim 4, wherein the at least one memory and the instructions are further configured to, together with the at least one processor, cause the first device to determine the second callback URI by: Based on the first parameter of the binding information, stripping the first API prefix from the first callback URI; and If a second API prefix is ​​indicated in the discovery response, populating the first callback URI with the second API prefix indicated in the discovery response to form the second callback URI.

6. The first device of claim 4, wherein the at least one memory and the instructions are further configured to, together with the at least one processor, cause the first device to determine the second callback URI by: Based on the first parameter of the binding information, stripping the first permission part from the first callback URI; and The first callback URI is populated with the second authority portion indicated in the discovery response to form the second callback URI.

7. The first device of claim 2, wherein the service request message indicates a value of the first API prefix in a second parameter, the second parameter comprising an HTTP header or a new header, and wherein the service request message lists at least one of the following in the second parameter: the first API prefix of the first callback URI, the apiRoot portion of the first callback URI, or The remainder of the first callback URI with the apiRoot portion stripped off.

8. The first device of claim 7, wherein the at least one memory and the instructions are further configured to, together with the at least one processor, cause the first device to determine the second callback URI by: Based on the second parameter of the callback request message, stripping the first API prefix from the first callback URI; and If a second API prefix is ​​indicated in the discovery response, populating the first callback URI with the second API prefix indicated in the discovery response to form the second callback URI.

9. The first device of claim 7, wherein the at least one memory and the instructions are further configured to, together with the at least one processor, cause the first device to determine the second callback URI by: Based on the second parameter of the binding information, stripping the first authority part from the first callback URI; and The first callback URI is populated with the second authority portion indicated in the discovery response to form the second callback URI.

10. The first device according to any one of the preceding claims, wherein the service request message is a subscription creation request message, and the callback request message is a notification request message.

11. The first device according to any one of the preceding claims, wherein the first device comprises a network function service provider NFp, or a service communication proxy SCP, the second device comprises a network function service consumer NFc, and the third device comprises a network repository function NRF, and wherein the further second device instance is a NFc different from the second device, or the further second device instance is a reachable address of the second device.

12. A second device, comprising: at least one processor; as well as at least one memory storing instructions that, when executed by the at least one processor, cause the second device to at least: A service request message is sent to the first device, wherein the service request message includes: a first callback uniform resource identifier (URI) having a first application programming interface (API) prefix. 13 . The second device according to claim 12 , wherein the first callback URI comprises an apiRoot portion and a path portion, and the apiRoot portion comprises at least the first API prefix and a first authority portion. 14 . The second device according to claim 12 , wherein the service request message further comprises binding information, and the binding information indicates a value of the first API prefix in a first parameter.

15. The second device according to claim 14, wherein the binding information lists at least one of the following in the first parameter: the first API prefix of the first callback URI, the apiRoot portion of the first callback URI, or The remainder of the first callback URI with the apiRoot portion stripped off.

16. The second device of claim 13, wherein the service request message indicates a value of the first API prefix in a second parameter, the second parameter comprising an HTTP header or a new header, and wherein the service request message lists at least one of the following in the second parameter: the first API prefix of the first callback URI, the apiRoot portion of the first callback URI, or The remainder of the first callback URI with the apiRoot portion stripped off.

17. The second device according to claim 15 or 16, wherein the at least one memory and the instructions are further configured to, together with the at least one processor, cause the second device to at least: A callback request message having a second callback URI is received from the first device, wherein the first API prefix of the second callback URI is stripped based on the first parameter or the second parameter.

18. The second device of claim 17, wherein the second callback URI comprises at least one of the following: a second API prefix replacing the first API prefix; and A second rights portion that replaces the first rights portion.

19. The second device according to claim 17 or 18, wherein the service request message is a subscription creation request message, and the callback request message is a notification request message.

20. The second device according to any one of claims 12 to 19, wherein the first device comprises a network function service provider NFp or a service communication proxy SCP, and the second device comprises a network function service consumer NFc.

21. A third device, comprising: at least one processor; as well as at least one memory storing instructions that, when executed by the at least one processor, cause the third device to at least: receiving, from a second device, a request to register a profile of the second device including a default notification subscription, the default notification subscription including: a first callback uniform resource identifier (URI) having a first application programming interface (API) prefix; receiving, from a first device, a first discovery request to discover the second device; and A first discovery response including a default notification subscription is sent to the first device, the default notification subscription including the first URI having the first API prefix.

22. The third device according to claim 21, wherein the at least one memory and the instructions are further configured to, together with the at least one processor, cause the third device to: receiving, from the first device, a second discovery request to discover additional second device instances; and Sending a second discovery response to the first device, where the second discovery response includes: A second callback URI having a second API prefix of the additional second device instance.

23. The third device according to claim 22, wherein the at least one memory and the instructions are further configured to, together with the at least one processor, enable the third device to: determine content of the second discovery response based on the default notification subscription and the second discovery request.

24. The third device according to any one of claims 21 to 23, wherein the first device comprises a network function service provider NFp, or a service communication proxy SCP, the second device comprises a network function service consumer NFc, and the third device comprises a network repository function NRF, and wherein the additional second device instance is a NFc different from the second device, or the additional second device instance is a reachable address of the second device.

25. A fourth device, comprising: at least one processor; as well as at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: receiving a service request message from a second device, wherein the service request message includes: a first callback uniform resource identifier URI having a first application programming interface API prefix; Sending the service request message to the first device; receiving, from the first device, a callback request message corresponding to the service request message; In response to determining that the second device is unreachable, sending a discovery request to a third device to discover additional second device instances; receiving a discovery response from the third device; Based on the discovery response, determining a second callback URI; and Based on the second callback URI, the callback request message is sent to the additional second device instance. 26 . The fourth device according to claim 25 , wherein the first callback URI comprises an apiRoot portion and a path portion, and the apiRoot portion comprises at least the first API prefix and a first authority portion. 27 . The fourth device according to claim 26 , wherein the service request message further includes binding information, and the binding information indicates a value of the first API prefix in a first parameter.

28. The fourth device according to claim 27, wherein the binding information lists at least one of the following in the first parameter: the first API prefix of the first callback URI, the apiRoot portion of the first callback URI, or The remainder of the first callback URI with the apiRoot portion stripped off. 29 . The fourth device according to claim 27 , wherein the callback request message comprises route binding information, and the route binding information indicates a value of the first API prefix in a second parameter.

30. The fourth device according to claim 29, wherein the callback request message includes route binding information listing at least one of the following in the second parameter: the first API prefix of the first callback URI, the apiRoot portion of the first callback URI, or The remainder of the first callback URI with the apiRoot portion stripped off.

31. The fourth device of claim 27, wherein the at least one memory and the instructions are further configured to, together with the at least one processor, cause the fourth device to determine the second callback URI by: Based on the second parameter of the route binding information, stripping the first API prefix from the first callback URI; and If a second API prefix is ​​indicated in the discovery response, populating the first callback URI with the second API prefix indicated in the discovery response to form the second callback URI.

32. The fourth device of claim 27, wherein the at least one memory and the instructions are further configured to, together with the at least one processor, cause the fourth device to determine the second callback URI by: Based on the second parameter of the binding information, stripping the first authority part from the first callback URI; and The first callback URI is populated with the second authority portion indicated in the discovery response to form the second callback URI.

33. The fourth device of claim 25, wherein the callback request message indicates a value of the first API prefix in a third parameter, the third parameter comprising an HTTP header or a new header, and wherein the service request message lists at least one of the following in the second parameter: the first API prefix of the first callback URI, the apiRoot portion of the first callback URI, or The remainder of the first callback URI with the apiRoot portion stripped off.

34. The fourth device of claim 33, wherein the at least one memory and the instructions are further configured to, together with the at least one processor, cause the fourth device to determine the second callback URI by: Based on the third parameter of the callback request message, stripping the first API prefix from the first callback URI; and If a second API prefix is ​​indicated in the discovery response, populating the first callback URI with the second API prefix indicated in the discovery response to form the second callback URI.

35. The fourth device of claim 33, wherein the at least one memory and the instructions are further configured to, together with the at least one processor, cause the fourth device to determine the second callback URI by: Based on the third parameter of the callback request message, stripping the first authority part from the first callback URI; and The first callback URI is populated with the second authority portion indicated in the discovery response to form the second callback URI.

36. The fourth device according to any one of claims 25 to 35, wherein the service request message is a subscription creation request message, and the callback request message is a notification request message.

37. The fourth device according to any one of claims 25 to 36, wherein the first device includes a network function service provider NFp, the second device includes a network function service consumer NFc, the third device includes a network repository function NRF, and the fourth device includes a service communication proxy SCP, and wherein the additional second device instance is a NFc different from the second device, or the additional second device instance is a reachable address of the second device.

38. A method implemented at a first device, comprising: receiving a service request message from a second device, wherein the service request message includes: a first callback uniform resource identifier URI having a first application programming interface API prefix; In response to determining that the second device is unreachable, sending a discovery request to a third device to discover additional second device instances; receiving a discovery response from the third device; Based on the discovery response, determining a second callback URI; and Based on the second callback URI, a callback request message is sent to the additional second device instance.

39. The method of claim 38, wherein the first callback URI comprises an apiRoot portion and a path portion, and the apiRoot portion comprises at least the first API prefix.

40. The method of claim 39, wherein the service request message further comprises binding information, and the binding information indicates a value of the first API prefix in a first parameter.

41. The method of claim 40, wherein the binding information lists at least one of the following in the first parameter: the first API prefix of the first callback URI, the apiRoot portion of the first callback URI, or The remainder of the first callback URI with the apiRoot portion stripped off.

42. The method of claim 41 , wherein determining the second callback URI comprises: Based on the first parameter of the binding information, stripping the first API prefix from the first callback URI; as well as If a second API prefix is ​​indicated in the discovery response, populating the first callback URI with the second API prefix indicated in the discovery response to form the second callback URI.

43. The method of claim 41 , wherein determining the second callback URI comprises: Based on the first parameter of the binding information, stripping the first permission part from the first callback URI; as well as The first callback URI is populated with the second authority portion indicated in the discovery response to form the second callback URI.

44. The method of claim 39, wherein the service request message indicates a value of the first API prefix in a second parameter, the second parameter comprising an HTTP header or a new header, and wherein the service request message lists at least one of the following in the second parameter: the first API prefix of the first callback URI, the apiRoot portion of the first callback URI, or The remainder of the first callback URI with the apiRoot portion stripped off.

45. The method of claim 44, wherein determining the second callback URI comprises: Based on the second parameter of the callback request message, stripping the first API prefix from the first callback URI; as well as If a second API prefix is ​​indicated in the discovery response, populating the first callback URI with the second API prefix indicated in the discovery response to form the second callback URI.

46. ​​The method of claim 44, wherein determining the second callback URI comprises: Based on the second parameter of the binding information, stripping the first permission part from the first callback URI; as well as The first callback URI is populated with the second authority portion indicated in the discovery response to form the second callback URI.

47. The method according to any one of claims 38 to 46, wherein the service request message is a subscription creation request message, and the callback request message is a notification request message.

48. A method according to any one of claims 38 to 47, wherein the first device comprises a network function service provider NFp, or a service communication proxy SCP, the second device comprises a network function service consumer NFc, and the third device comprises a network repository function NRF, and wherein the additional second device instance is a NFc different from the second device, or the additional second device instance is a reachable address of the second device.

49. A method implemented at a second device, comprising: A service request message is sent to the first device, wherein the service request message includes: a first callback uniform resource identifier (URI) having a first application programming interface (API) prefix.

50. The method of claim 49, wherein the first callback URI comprises an apiRoot portion and a path portion, and the apiRoot portion comprises at least the first API prefix and a first authority portion.

51. The method of claim 50, wherein the service request message further comprises binding information, and the binding information indicates a value of the first API prefix in a first parameter.

52. The method of claim 51, wherein the binding information lists at least one of the following in the first parameter: the first API prefix of the first callback URI, the apiRoot portion of the first callback URI, or The remainder of the first callback URI with the apiRoot portion stripped off.

53. The method of claim 51, wherein the service request message indicates a value of the first API prefix in a second parameter, the second parameter comprising an HTTP header or a new header, and wherein the service request message lists at least one of the following in the second parameter: the first API prefix of the first callback URI, the apiRoot portion of the first callback URI, or The remainder of the first callback URI with the apiRoot portion stripped off.

54. The method of claim 51, wherein the method further comprises: A callback request message having a second callback URI is received from the first device, wherein the first API prefix of the second callback URI is stripped based on the first parameter or the second parameter.

55. The method of claim 54, wherein the second callback URI comprises at least one of: a second API prefix replacing the first API prefix; and A second rights portion that replaces the first rights portion.

56. The method of claim 54 or 55, wherein the service request message is a subscription creation request message, and the callback request message is a notification request message.

57. The method according to any one of claims 49 to 56, wherein the first device comprises a network function service provider NFp, or a service communication proxy SCP, and the second device comprises a network function service consumer NFc.

58. A method implemented at a third device, comprising: receiving, from a second device, a request to register a profile of the second device including a default notification subscription, the default notification subscription including: a first callback uniform resource identifier (URI) having a first application programming interface (API) prefix; receiving, from a first device, a first discovery request to discover the second device; and A first discovery response including a default notification subscription is sent to the first device, wherein the default notification subscription includes: the first URI having the first API prefix.

59. The method of claim 58, wherein the method further comprises: receiving, from the first device, a second discovery request to discover additional second device instances; as well as A second discovery response is sent to the first device, wherein the second discovery response includes: a second callback URI having a second API prefix of the additional second device instance.

60. The method of claim 59, wherein the method further comprises: Based on the default notification subscription and the second discovery request, content of the second discovery response is determined.

61. A method according to any one of claims 58 to 60, wherein the first device comprises a network function service provider NFp, or a service communication proxy SCP, the second device comprises a network function service consumer NFc, and the third device comprises a network repository function NRF, and wherein the additional second device instance is a NFc different from the second device, or the additional second device instance is a reachable address of the second device.

62. A method implemented at a fourth device, comprising: receiving a service request message from a second device, wherein the service request message includes: a first callback uniform resource identifier URI having a first application programming interface API prefix; Sending the service request message to the first device; receiving, from the first device, a callback request message corresponding to the service request message; In response to determining that the second device is unreachable, sending a discovery request to a third device to discover additional second device instances; receiving a discovery response from the third device; Based on the discovery response, determining a second callback URI; and Based on the second callback URI, the callback request message is sent to the additional second device instance.

63. The method of claim 62, wherein the first callback URI comprises an apiRoot portion and a path portion, and the apiRoot portion comprises at least the first API prefix and a first authority portion.

64. The method of claim 63, wherein the service request message further comprises binding information, and the binding information indicates a value of the first API prefix in a first parameter.

65. The method of claim 64, wherein the binding information lists at least one of the following in the first parameter: the first API prefix of the first callback URI, the apiRoot portion of the first callback URI, or The remainder of the first callback URI with the apiRoot portion stripped off.

66. The method of claim 65, wherein the callback request message includes route binding information indicating a value of the first API prefix in a second parameter.

67. The method of claim 66, wherein the callback request message includes route binding information listing at least one of the following in the second parameter: the first API prefix of the first callback URI, the apiRoot portion of the first callback URI, or The remainder of the first callback URI with the apiRoot portion stripped off.

68. The method of claim 67, wherein determining the second callback URI comprises: Based on the second parameter of the binding information, stripping the first API prefix from the first callback URI; as well as If a second API prefix is ​​indicated in the discovery response, populating the first callback URI with the second API prefix indicated in the discovery response to form the second callback URI.

69. The method of claim 67, wherein determining the second callback URI comprises: Based on the second parameter of the binding information, stripping the first permission part from the first callback URI; as well as The first callback URI is populated with the second authority portion indicated in the discovery response to form the second callback URI.

70. The method of claim 63, wherein the callback request indicates a value of the first API prefix in a third parameter, the third parameter comprising an HTTP header or a new header, and wherein the service request message lists at least one of the following in the second parameter: the first API prefix of the first callback URI, the apiRoot portion of the first callback URI, or The remainder of the first callback URI with the apiRoot portion stripped off.

71. The method of claim 70, wherein determining the second callback URI comprises: Based on the third parameter of the callback request, stripping the first API prefix from the first callback URI; as well as If a second API prefix is ​​indicated in the discovery response, populating the first callback URI with the second API prefix indicated in the discovery response to form the second callback URI.

72. The method of claim 70, wherein determining the second callback URI comprises: Based on the third parameter of the binding information, stripping the first permission part from the first callback URI; as well as The first callback URI is populated with the second authority portion indicated in the discovery response to form the second callback URI.

73. The method according to any one of claims 62 to 72, wherein the service request message is a subscription creation request message, and the callback request message is a notification request message.

74. The method according to any one of claims 62 to 73, wherein the first device comprises a network function service provider NFp, the second device comprises a network function service consumer NFc, the third device comprises a network repository function NRF, and the fourth device comprises a service communication proxy SCP, and wherein the additional second device instance is a NFc different from the second device, or the additional second device instance is a reachable address of the second device.

75. An apparatus comprising means for performing: A service request message is received from a second device, wherein the service request message includes: A first callback uniform resource identifier URI having a first application programming interface API prefix; In response to determining that the second device is unreachable, sending a discovery request to a third device to discover additional second device instances; receiving a discovery response from the third device; Based on the discovery response, determining a second callback URI; and Based on the second callback URI, a callback request message is sent to the additional second device instance.

76. An apparatus comprising means for performing: Sending a service request message to the first device, wherein the service request message includes: A first callback uniform resource identifier URI having a first application programming interface API prefix.

77. An apparatus comprising means for performing: Receiving, from a second device, a request to register a profile of the second device including a default notification subscription, the default notification subscription including: A first callback uniform resource identifier URI having a first application programming interface API prefix; receiving, from the first device, a first discovery request to discover the second device; as well as A first discovery response including a default notification subscription is sent to the first device, wherein the default notification subscription includes: the first URI having the first API prefix.

78. An apparatus comprising means for performing: A service request message is received from a second device, wherein the service request message includes: A first callback uniform resource identifier URI having a first application programming interface API prefix; Sending the service request message to the first device; receiving, from the first device, a callback request message corresponding to the service request message; In response to determining that the second device is unreachable, sending a discovery request to a third device to discover additional second device instances; receiving a discovery response from the third device; Based on the discovery response, determining a second callback URI; and Based on the second callback URI, the callback request message is sent to the additional second device instance.

79. A computer-readable medium comprising program instructions for causing an apparatus to perform the method according to at least one of claims 38 to 74.

80. A computer readable medium comprising program instructions for causing an apparatus to perform at least the following: A service request message is received from a second device, wherein the service request message includes: A first callback uniform resource identifier URI having a first application programming interface API prefix; In response to determining that the second device is unreachable, sending a discovery request to a third device to discover additional second device instances; receiving a discovery response from the third device; Based on the discovery response, determining a second callback URI; and Based on the second callback URI, a callback request message is sent to the additional second device instance.

81. A computer readable medium comprising program instructions for causing an apparatus to perform at least the following: Sending a service request message to the first device, wherein the service request message includes: A first callback uniform resource identifier URI having a first application programming interface API prefix.

82. A computer readable medium comprising program instructions for causing an apparatus to perform at least the following: Receiving, from a second device, a request to register a profile of the second device including a default notification subscription, the default notification subscription including: A first callback uniform resource identifier URI having a first application programming interface API prefix; receiving, from the first device, a first discovery request to discover the second device; as well as A first discovery response including a default notification subscription is sent to the first device, wherein the default notification subscription includes: the first URI having the first API prefix.

83. A computer readable medium comprising program instructions for causing an apparatus to perform at least the following: A service request message is received from a second device, wherein the service request message includes: A first callback uniform resource identifier URI having a first application programming interface API prefix; Sending the service request message to the first device; receiving, from the first device, a callback request message corresponding to the service request message; In response to determining that the second device is unreachable, sending a discovery request to a third device to discover additional second device instances; receiving a discovery response from the third device; Based on the discovery response, determining a second callback URI; and Based on the second callback URI, the callback request message is sent to the additional second device instance.

Images