EFFICIENT HANDLING OF SUBSCRIPTIONS

Abstract

Methods and nodes related to subscription handling and notifications, for instance, with respect to Network Function (NF) management services, are described.

Claims

1-41. (canceled)

42. A method in a second node, comprising: receiving, from a first node, a first message, wherein said first message is a request for a subscription; sending, to said first node, a second message, wherein said second message comprises a subscription ID for the subscription; and receiving, from said first node, a third message, wherein said third message comprises a new subscription validity time for said subscription.

43. The method of claim 42, wherein said second message comprises an initial subscription validity time, further comprising: accepting an extension of the subscription validity time and sending a fourth message in response to said third message, wherein said fourth message indicates an updated subscription validity time for said subscription.

44. The method of claim 43, wherein said updated subscription validity time for said subscription is different than the validity time period indicated by said new validity time.

45. The method of claim 43, wherein said fourth message is one or more of an HTTP 204 No Content message and an HTTP 200 OK message comprising subscription data.

46. The method of claim 45, wherein said subscription data comprises one or more of said updated time period, said subscription ID, and a subscription type.

47. The method of claim 42, further comprising: receiving, from a third node, a fifth message, wherein said fifth message is a registration message; and sending, to said third node, a sixth message, wherein said sixth message indicates a registration status.

48. The method of claim 42, wherein said first message comprises input criteria, wherein said input criteria comprise one or more of an event type, an instance identifier corresponding to said second node, or a set of conditions identifying one or more network functions for said subscription.

49. The method of claim 48, wherein said first message is an HTTP POST message and said input criteria are in the form of a JSON document contained in the body of said HTTP POST message.

50. The method of claim 48, wherein said event type comprises one or more of register, de-register, or profile change, or wherein said set of conditions comprises one or of more network functions, NF, of a given type, all NFs supporting a given service, or all NFs belonging to a common set or group ID.

51. The method of claim 47, wherein said second node is a Network Repository Function, NRF, said first node is a NF Service Consumer, and said third node is a NF Service Producer.

52. The method of claim 43, further comprising: generating said subscription ID; and determining said initial subscription validity time.

53. The method of claim 42, wherein said second message is an HTTP 201 message indicating that said first node has been successfully subscribed in accordance with said request for subscription.

54. The method of claim 42, wherein said third message is an HTTP PATCH message.

55. The method of claim 42, further comprising: sending a fourth message in response to said third message, wherein said fourth message is an HTTP 400/500 message indicating one or more problems with a time extension request, and wherein said subscription is to receive notifications regarding updates to one or more services.

56. A method in a first node, comprising: sending to a second node, a first message, wherein said first message is a request for a subscription; receiving, from said second node, a second message, wherein said second message comprises a subscription ID for the subscription; and sending, to said second node, a third message, wherein said third message comprises a new validity time for said subscription.

57. The method of claim 56, wherein said second message comprises an initial subscription validity time, further comprising: receiving a fourth message, wherein said fourth message indicates an updated validity time period for said subscription, wherein said updated validity time period for said subscription is different than the validity time indicated by said new validity time, or said fourth message is one or more of an HTTP 204 No Content message and an HTTP 200 message comprising subscription data, wherein said subscription data comprises one or more of said updated time period, said subscription ID, and a subscription type.

58. The method of claim 56, wherein said first message comprises input criteria, wherein said input criteria comprise one or more of an event type, an instance identifier corresponding to said second node, and a set of conditions identifying one or more network functions for said subscription, wherein said first message is an HTTP POST message and said input criteria are in the form of a JSON document contained in the body said HTTP POST message, or said event type comprises one or more of register, de-register, and profile change, or said set of conditions comprises one or more of network functions, NF, of a given type, all NFs supporting a given service, or all NFs belonging to a common set or group ID.

59. The method of claim 56, wherein said second node is a Network Repository Function, NRF, said first node an NF Service Consumer, and said subscription relates to services provided by an NF Service Producer.

60. The method of claim 56, further comprising: determining the new subscription validity time.

61. The method of claim 56, wherein said second message is an HTTP 201 message indicating successful subscription in accordance with said request for subscription, or said third message is an HTTP PATCH message, the method further comprising: receiving a fourth message, wherein said fourth message is an HTTP 400/500 message indicating one or more problems with a time extension request, and wherein said subscription is to receive notifications regarding updates to one or more services.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0116] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments.

[0117] FIG. 1 illustrates a system according to some embodiments.

[0118] FIG. 2 illustrates a flow diagram according to some embodiments.

[0119] FIG. 3 illustrates a flow diagram according to some embodiments.

[0120] FIG. 4 illustrates a flow diagram according to some embodiments.

[0121] FIG. 5 illustrates a flow diagram according to some embodiments.

[0122] FIGS. 6A and 6B are diagrams showing functional modules of nodes according to some embodiments.

[0123] FIG. 7 is a block diagram of a node according to some embodiments.

DETAILED DESCRIPTION

[0124] A 5G System reference architecture 100, for instance as defined in 3GPP TS 23.501, showing service-based interfaces used within the Control Plane, is depicted in FIG. 1. In this example, not all NFs are necessarily depicted.

[0125] The Network Repository Function (NRF) is a key NF within the 5GC SBA Framework that provides support to service providers to register their services so that service consumers can dynamically discover them. The data that an NF provides to the NRF as part of its registration is called an “NF Profile,” and comprises generic data associated to the specific NF instance, and also to the different NF service instances (HTTP services) that can be invoked.

[0126] The service discovery function enabled by an NRF provides the address of the NF instances that exist in a network for providing a service and all necessary information to issue and route requests towards the selected target NF producer (e.g., protocol, port, FQDN and/or IP address of target NF instance amongst other parameters required to create a URI used in the HTTP request).

[0127] The NFs interact with the NRF via two main services: [0128] NF Management: for registration to NRF of the profile of a given NF, deregistration from NRF, and subscription to notifications when other NFs register, deregister, or update their profile. [0129] NF Discovery: to discover which NFs, satisfying certain filter criteria, are available for service invocation.

[0130] Referring now to FIG. 1, FIG. 1 illustrates a 5G network architecture 100 using service-based interfaces between the NFs in the control plane, according to some embodiments. In this example, the service(s) that a NF provides to other authorized NFs can be exposed to the authorized NFs through the service-based interface. In FIG. 1, the service-based interfaces are indicated by the letter “N” followed by the name of the NF, e.g. Namf for the service-based interface of the AMF and Nsmf for the service-based interface of the SMF, etc. FIG. 1 includes the Network Exposure Function (NEF) and the Network Repository Function (NRF).

[0131] As seen from the access side, the 5G network architecture shown in FIG. 1 comprises a plurality of User Equipment (UEs) connected to either a Radio Access Network (RAN) or an Access Network (AN) as well as an Access and Mobility Management Function (AMF).

[0132] Typically, the R(AN) comprises base stations, e.g. such as evolved Node Bs (eNBs) or 5G base stations (gNBs) or similar. Seen from the core network side, the 5G core NFs shown in FIG. 1 include a Network Slice Selection Function (NSSF), an Authentication Server Function (AUSF), a Unified Data Management (UDM), an Access and Mobility Management Function (AMF), a Session Management Function (SMF), a Policy Control Function (PCF), an Application Function (AF).

[0133] Reference point representations of the 5G network architecture are used to develop detailed call flows in the normative standardization. The N1 reference point is defined to carry signaling between UE and AMF. The reference points for connecting between AN and AMF and between AN and UPF are defined as N2 and N3, respectively. N4 is used by SMF and UPF so that the UPF can be set using the control signal generated by the SMF, and the UPF can report its state to the SMF. N9 is the reference point for the connection between different UPFs.

[0134] In many respects, the 5G core network aims at separating user plane and control plane. The user plane typically carries user traffic while the control plane carries signaling in the network. In FIG. 1, the UPF is in the user plane and all other NFs shown, i.e., AMF, SMF, PCF, AF, AUSF, and UDM, are in the control plane. Separating the user and control planes helps each plane resource to be scaled independently. It also allows UPFs to be deployed separately from control plane functions in a distributed fashion. In this architecture, UPFs may be deployed very close to UEs to shorten the Round Trip Time (RTT) between UEs and data network for some applications requiring low latency.

[0135] The 5G core network architecture is composed of modularized functions. For example, the AMF and SMF are independent functions in the control plane. Separated AMF and SMF allow independent evolution and scaling. Other control plane functions like PCF and AUSF can be separated as shown in FIG. 1. Modularized function design enables the 5G core network to support various services flexibly.

[0136] Each NF interacts with another NF directly. It is possible to use intermediate functions to route messages from one NF to another NF. In the control plane, a set of interactions between two NFs is defined as service so that its reuse is possible. This service enables support for modularity. The user plane supports interactions such as forwarding operations between different UPFs.

[0137] Some properties of the NFs shown in FIG. 1 may be described in the following manner The AMF provides UE-based authentication, authorization, mobility management, etc. A UE even using multiple access technologies is basically connected to a single AMF because the AMF is independent of the access technologies. The SMF is responsible for session management and allocates IP addresses to UEs. It also selects and controls the UPF for data transfer. If a UE has multiple sessions, different SMFs may be allocated to each session to manage them individually and possibly provide different functionalities per session. The AF provides information on the packet flow to the PCF responsible for policy control in order to support Quality of Service (QoS). Based on the information, the PCF determines policies about mobility and session management to make AMF and SMF operate properly. The AUSF supports authentication function for UEs or similar and thus stores data for authentication of UEs or similar while UDM stores subscription data of UE. The Data Network (DN), not part of the 5G core network, provides Internet access or operator services and similar.

[0138] According to embodiments, an NF may be implemented either as a network element on dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., a cloud infrastructure.

[0139] According to embodiments, an NF (e.g., a “subscribing NF”) creates a subscription in the NRF by providing a number of input criteria. Such input criteria may comprise: [0140] Type of event that occurs in the subscribed NF (register, de-register, profile change) [0141] The “Instance ID” of the subscribed NF [0142] Conditions to identify a set of subscribed NFs (e.g., all NFs of a given type, all NFs supporting a given service, all NFs belonging to a common set or group ID, etc.)
This information can be sent by the subscribing NF by means of an HTTP POST request to the NRF. For example, all input data can be sent in the HTTP request body, in the form of a JSON document.

[0143] Once the subscription is created, the NRF determines for how long the subscription is valid. After that time elapses, the subscription may be terminated.

[0144] In current systems, after a subscription has been created in the NRF, it is not possible to extend the subscription validity time, and the only way to keep the NF Service Consumer receiving the notifications is to create a new subscription when the former one has expired. This behavior is not optimal, and aspects of this disclosure provide systems and methods by which it is possible to extend an existing subscription for an additional time period.

[0145] Referring now to FIG. 2, a messaging flow diagram according to embodiments is provided. FIG. 2 illustrates, for instance, how an HTTP PATCH message can be used to update an existing subscription in NRF.

[0146] According to embodiments, an extension request message may be sent from a first node (e.g., an NF Service Consumer) to a second node (e.g., an NRF) to extend the validity time of a subscription. The message may be, according to embodiments, an HTTP PATCH message that includes subscription information, such as subscription ID. The data may further include a requested extension of time, for instance, a new validity time corresponding to the subscription. According to embodiments, an NF Service Consumer sends an HTTP PATCH request to the resource URI identifying the individual subscription resource. The payload body of the PATCH request contains a “replace” operation on the “validityTime” attribute of the SubscriptionData structure and contains a new suggested value for it; no other attribute of the resource is updated as part of this operation, according to embodiments.

[0147] According to embodiments, the second node (e.g., the NRF) can respond in at least three ways, including: [0148] (1) a null response, such as a 204 No Content message, which can indicate that the requested extension has been accepted; [0149] (2) a fuller response, such as a 200 OK message, which can indicate one or more of an acceptance of the requested extension or provide a new/different validity time; and [0150] (3) a negative response, such as a 4xx/5xx response indicating one or more problems with the request, which can further indicate the specific problems with said request.
For instance, if the creation of the subscription fails at the NRF due to errors in the request body, the NRF could return “400 Bad Request” status code with the details of the error. If the creation of the subscription fails at the NRF due to NRF internal errors, the NRF could return “500 Internal Server Error” status code with the details of the error. According to embodiments, a full response, such as a 200 OK message may comprise additional data, including subscription ID and event type.

[0151] In one embodiment, responses 2a, 2b, and 2c of FIG. 2 may be defined as follows: [0152] 2a. On success, if the NRF accepts the extension of the validity time of the subscription, and it accepts the requested value for the “validityTime” attribute, a response with status code “204 No Content” may be returned. [0153] 2b. On success, if the NRF accepts the extension of the validity time of the subscription, but it assigns a different validity time than the validity time suggested by the NF Service Consumer, a response with the “200 OK” status code may be returned. The response may contain the new resource representation of the “subscription” resource, which includes the new validity time, as determined by the NRF, after which the subscription becomes invalid. [0154] 2c. If the update of the subscription fails at the NRF due to errors in the JSON Patch object in the request body, the NRF may return a response with a “400 Bad Request” status code with the ProblemDetails Information Element (IE) providing details of the error. If the update of the subscription fails at the NRF due to NRF internal errors, the NRF may return a response with a “500 Internal Server Error” status code with the ProblemDetails IE providing details of the error.
Different specific messaging/content may be provided in other embodiments.

[0155] In certain aspects, the interaction between the subscribing NF and the NRF is more efficient, since the creation of a subscription may be a computationally intensive process (depending on the conditions for subscribing to sets/groups of NFs), and it can be more efficient to extend the lifetime of a subscription by updating the subscription validity time rather than having to re-create a new subscription.

[0156] Although FIG. 2 uses an NF Service Consumer and an NRF for the example, the messaging may be applied between different nodes and/or functions having a subscribe/notify pattern, including, for instance: any NF (e.g., AMF and SMF) that subscribes to UDM for the Subscribe Data Management service; any NF (e.g., NEF) that subscribes to UDM for the Event Exposure service; any NF (e.g., AMF) that subscribes to PCF for the AM Policy Control service; any NF (e.g., AF and NEF) that subscribes to PCF for the Policy Authorization service; any NF (e.g., SFM) that subscribes to NEF for the PFD Management service; any NF (e.g., AMF or SMF) that subscribes to SMF for the PDU Session service.

[0157] Similarly, FIG. 3 may be implemented with respect to such additional network functions and relationships. Additional examples are provided in 3GPP TS 23.502 V15.3.0, for instance in the service descriptions (e.g., 5.2.3-1, Table 5.2.5.1-1, and Table 5.2.6.1-1). Aspects of the disclosure may be applied with respect to services listed by 3GPP TS 23.502 V15.3.0 in Table 5.2.7.1-1 (Services of the NRF).

[0158] Referring now to FIG. 3, a messaging flow diagram according to embodiments is provided. Such messaging 300 may be implemented, for instance, by one or more nodes 301, 302, and 303 as described with respect to FIGS. 6 and 7.

[0159] In certain aspects, subscription to notifications on NF Instances can be updated. Such updates can include an update to refresh the validity time when the time is about to expire. For example, an NF Service Consumer 301 may request a new validity time to the NRF 302, and the NRF 302 may answer with the new assigned validity time, if the operation is successful. In some embodiments, this operation is executed by updating the resource identified by “subscriptionID,” and is invoked by issuing an HTTP PATCH request on the URI representing the individual resource. The messaging illustrated with respect to FIG. 3 can provide for management of notifications for a first node 301. For instance, second node 302 (e.g., an NRF) may handle subscription information and updates for one or more subscribing nodes 301 (e.g., an NF Service Consumer) that subscribe to notifications, including updates relating to a set of services or functions, which may correspond to a third node 303 (e.g., NF Service Producer).

[0160] According to some embodiments, the process may begin with a first node 301, such as an NF Service Consumer, sending a message 310. This message can be a subscription message, for example, to register and obtain updates to services. Such services could include those provided by node 303, such as an NF Service Producer. In certain aspects, the message 310 is an HTTP POST message, which can include an Instance ID for the network function. With message 320, the second node 302, such as an NRF, can respond. Such a response can indicate a successful subscription. This can be a 201 Created response, in some instances, and may include one or more of a subscription ID and subscription validity time. As part of this process, the node 302 may determine an appropriate set of functions, such as from NF Service Producers, that meet the subscription request indicated by message 310. Node 302 may also generate a token for the subscription, which may be the Subscription ID.

[0161] Subsequently, for instance when the subscription validity time is about to expire, node 301 may send another message 330 to update the subscription. According to embodiments, the message 330 is an HTTP PATCH. This message can include, for example, both the Subscription ID and a requested extension to the corresponding subscription validity time. The second node 302 (e.g., the NRF) can respond with message 340. According to embodiments, the message 340 indicates a status of the request provided in message 330. The message may comprise: [0162] (1) a null response, such as a 204 No Content message, which can indicate that the requested extension has been accepted; [0163] (2) a response, such as a 200 OK message, which can indicate one or more of an acceptance of the requested extension or provide a new/different validity time; and [0164] (3) a negative response, such as a 4xx/5xx response indicating one or more problems with the request, which can further indicate the specific problems with said request.

[0165] An example of messages 330 and 340 is provided below:

TABLE-US-00002 Request PATCH .../subscriptions/2a58bf47 Content-Type: application/json-patch+json [ { “op”: “REPLACE”, “path”: “/validityTime”, “value”: ”2018-12- 30T23:20:50Z” }, ] Response HTTP/2 200 OK Content-Location: .../subscriptions/2a58bf47

[0166] Although illustrated as an HTTP 200 message in this example, according to embodiments, the message 340 can be an HTTP 204 message: [0167] Response [0168] HTTP/2 204 No Content

[0169] According to some embodiments, node 302 responds in message 340 with a different validity time than requested by node 301.

[0170] The node 302 may also perform one or more determinations to evaluate the validity of the requested extension, including determining availability of one or more resources or any applicable restrictions/authorization requirements. The message 340 may be based on such a determination.

[0171] The messaging 300 may conclude, according to embodiments, with the expiration of the subscription.

[0172] In some embodiments, messaging 300 may also include messages 350 and 360. These messages may come before messages 310-340, and register one or more services with the node 302. Message 350 may be, for instance an HTTP PUT, and message 360 may indicate a successful registration with respect to such services.

[0173] Referring now to FIG. 4, a process 400 is provided according to embodiments. Process 400 may be implemented, for instance, by one or more nodes 301, 302, and 303 as described with respect to FIGS. 6 and 7. For example, process 400 may be performed by an NRF.

[0174] Process 400 may begin, for example, at step 410 in which a first message is received. The message may be a request for a subscription, and may be an HTTP POST message such as message 310 described with respect to FIG. 3. In step 420, a second message is sent. This message may comprise a subscription ID for the subscription, and may correspond to message 320 described with respect to FIG. 3. In step 430, a third message is received, which comprises a time extension request (i.e., a request to extend the subscription validity time) corresponding to the subscription. This message may correspond to message 330 described with respect to FIG. 3. According to some embodiments, the process 400 may optionally include step 440, in which a fourth message is sent that indicates an updated validity time for the subscription, such as message 340 of FIG. 3. In some instances, a fourth message may be sent that indicates a problem with the request.

[0175] Referring now to FIG. 5, a process 500 is provided according to embodiments. Process 500 may be implemented, for instance, by one or more nodes 301, 302, and 303 as described with respect to FIGS. 6 and 7. For example, process 500 may be performed by an NF Service Consumer.

[0176] Process 500 may begin, for example, at step 510 in which a first message is sent. The message may be a request for a subscription, and may be an HTTP POST message such as message 310 described with respect to FIG. 3. In step 520, a second message is received. This message may comprise a subscription ID for the requested subscription, and may correspond to message 320 described with respect to FIG. 3. In step 530, a third message is sent, which comprises a time extension request (i.e., a request to extend the subscription validity time) corresponding to the subscription. This message may correspond to message 330 described with respect to FIG. 3. According to some embodiments, the process 500 may optionally include step 540, in which a fourth message is received that indicates an updated validity time for the subscription, such as message 340 of FIG. 3. In some instances, a fourth message may be received that indicates a problem with the request.

[0177] FIG. 6A is a diagram showing functional modules of a first node, such as node 301 (e.g., an NF Service Consumer), according to some embodiments. As shown in FIG. 6A, the first node comprises one or more of a sending unit 602 and a receiving unit 604. According to embodiments, sending unit 602 is arranged to send messages, such as messages 310 and 330 and as described with respect to steps 510 and 530 of FIG. 5. According to embodiments, receiving unit 604 is arranged to received messages, such as messages 320 and 340 and as described with respect to step 520, and in some cases, step 540. Similarly, the first node may be adapted to send and/or receive the messages set forth in FIG. 2.

[0178] FIG. 6B is a diagram showing functional modules of a second node, such as node 302 (e.g., an NRF), according to some embodiments. As shown in FIG. 6B, the second node comprises one or more of a sending unit 606 and a receiving unit 608. According to embodiments, sending unit 606 is arranged to send messages, such as messages 320 and 340 and as described with respect to steps 420 and optionally 440 of FIG. 4. According to embodiments, receiving unit 608 is arranged to receive messages, such as messages 310 and 330 and as described with respect to steps 410 and 430. Similarly, the second node may be adapted to send and/or receive the messages set forth in FIG. 2.

[0179] FIG. 7 is a block diagram of a node, such as the first node 301 (e.g. NF Service Consumer), second node 302 (e.g. NRF), or third node 303 (NF Service Producer) according to some embodiments. As shown in FIG. 7, the node may comprise: a data processing apparatus (DPA) 702, which may include one or more processors (P) 755 (e.g., a general purpose microprocessor and/or one or more other processors, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), and the like); a transmitter 705 and a receiver 704 coupled to an antenna 722 for enabling the node to transmit data to and receive data from an AN node (e.g., base station); and local storage unit (a.k.a., “data storage system”) 708, which may include one or more non-volatile storage devices and/or one or more volatile storage devices (e.g., random access memory (RAM)). In embodiments where the node includes a general purpose microprocessor, a computer program product (CPP) 741 may be provided. CPP 741 includes a computer readable medium (CRM) 742 storing a computer program (CP) 743 comprising computer readable instructions (CRI) 744. CRM 742 may be a non-transitory computer readable medium, such as, but not limited, to magnetic media (e.g., a hard disk), optical media, memory devices (e.g., random access memory), and the like. In some embodiments, the CRI 744 of computer program 743 is configured such that when executed by data processing apparatus 702, the CRI causes the node to perform steps described above (e.g., steps described above with reference to the flow charts). In other embodiments, the node may be configured to perform steps described herein without the need for code. That is, for example, data processing apparatus 702 may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and/or software.

[0180] According to embodiments, aspects of an API are provided, for instance, with respect to network function management, such as an Nnrf_NFManagement API. An example comprises the following:

TABLE-US-00003 /subscriptions/{subscriptionID}: patch: summary: Updates a subscription operationid: UpdateSubscription tags: - Subscription ID (Document) parameters: - name: subscriptionID in: path required: true description: Unique ID of the subscription to update schema: type: string pattern: ‘{circumflex over ( )}([0-9]{5,6}-)?[{circumflex over ( )}-]+$’ requestBody: content: application/json-patch+json: schema: type: array items: $ref: ‘TS29571_CommonData.yaml#/components/schemas/PatchItem’ required: true responses: ‘200’: description: Expected response to a valid request content: application/json: schema: $ref: ‘#/components/schemas/SubscriptionData’ ‘400’: $ref: ‘TS29571_CommonData.yaml#/components/responses/400’ ‘403’: $ref: ‘TS29571_CommonData.yaml#/components/responses/403’ ‘404’: $ref: ‘TS29571_CommonData.yaml#/components/responses/404’ ‘411’ : $ref: ‘TS29571_CommonData.yaml#/components/responses/411’ ‘413’: $ref: ‘TS29571_CommonData.yaml#/components/responses/413’ ‘415’: $ref: ‘TS29571_CommonData.yaml#/components/responses/415’ ‘500’: $ref: ‘TS29571_CommonData.yaml#/components/responses/500’ ‘501’: $ref: ‘TS29571_CommonData.yaml#/components/responses/501’ ‘503’: $ref: ‘TS29571_CommonData.yaml#/components/responses/503’ default: $ref: ‘TS29571_CommonData.yaml#/components/responses/default’ delete: summary: Deletes a subscription operationId: RemoveSubscription tags : - Subscription ID (Document) parameters: - name: subscriptionID in: path required: true description: Unique ID of the subscription to remove schema: type: string pattern: ‘{circumflex over ( )}([0-9]{5,6}-)?[{circumflex over ( )}-]+$’

[0181] Abbreviations:

TABLE-US-00004 Term Abbreviation Network Function NF Network Repository Function NRF User Equipment UE Radio (Access Network) R(AN) Data Network DN JavaScript Object Notation JSON Service Based Architecture SBA Control Plane CP Service Based Interface SBI Public Land Mobil Network PLMN Access and Mobility Management Function AMF Session Management Function SMF Unified Data Management UDM Authentication Server Function ASF/AuSF Unified Data Management UDM Application Function AF Network Exposure Function NEF Policy Control Function PCF Short Message Service Function SMSF Network Slice Selection Function NSSF User Plane Function UPF Bootstrapping Server Function BSF Charging Function CHF

[0182] While various embodiments of the present disclosure are described herein, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the disclosure unless otherwise indicated herein or otherwise clearly contradicted by context.

[0183] Additionally, while the processes described above and illustrated in the drawings are shown as a sequence of steps, this was done solely for the sake of illustration. Accordingly, it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be re-arranged, and some steps may be performed in parallel. Although the present disclosure and its advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of the disclosure as defined by the appended claims.