Patent ID: 12192878

DETAILED DESCRIPTION

The subject matter described herein relates to methods, systems, and computer readable media for identifying alternate delivery endpoints for MO data and monitoring reports in a communications network. In 5G communications networks, there are defined techniques to enable a network exposure function (NEF) to share context information with peer NEFs via messages that include binding headers. This mechanism is notably valuable to ensure network stability in instance where an original or primary NEF instance fails or otherwise becomes unavailable by enabling a consumer NF (e.g., a service management function (SMF)) to send MO data requires and/or monitoring request to alternate NEF instances associated with a common NF service set or NF set. However, there is currently no way for certain NFs (e.g., application functions) to publish binding information with NEFs or identify their respective peers in a similar manner. Accordingly, the disclosed subject matter describes a method for enabling a network operator to assign priority indicators that can be used to facilitate the alternate selection of such NFs (e.g., application functions) during overload conditions or network failures.

Prior to describing the disclosed subject matter, scenarios of common network flow processing by the NEF are presented herein. For example, inFIG.1, an SMF150, an NEF152, and an application function (AF)154are depicted as communicating messages pertaining to an existing non-IP data delivery (NIDD) network traffic flow under normal conditions. In particular, the NIDD flow traverses NEF152, which attempts to establish a communication session between SMF150and application function154. As shown inFIG.1, application function154is operating as a consumer NF that sends a NIDD configuration request message101to NEF152. In some embodiments, the configuration request message includes parameters identifying a user equipment that is related to the context configuration being requested. After receiving the configuration request message101, NEF152is configured to store the configuration data in a local database (see block102). Notably, the configuration data is stored as NIDD context information. Afterwards, NEF152waits for SMF150or an associated user equipment to initiate a NIDD session. For example, if a user equipment initiates a session, SMF150subsequently initiates a SMContext create request message104(e.g., a setup SMCreate session request message associated with the AF's NIDD request resource) that is directed to NEF152. Upon receiving request message104, NEF152is configured to access a context database and validate the NIDD configuration associated with AF154(see block105). In some examples, the context database contains entries of context data for each AF that includes, but not limited to, a uniform resource identifier (URI), a uniform resource locator (URL), a fully qualified domain name (FQDN), and/or an Internet protocol (IP) network address associated with each AF. Once the configuration is validated, NEF152can create a mapping of the two sessions (e.g., NEF's session with SMF150and NEF's session with AF154) and accept request message104.

Afterwards, NEF152is configured to send an acknowledgment message106(e.g., a201Created message) to SMF150. At this stage, mobile originated data flow (e.g., MO delivery request message107) is directed by SMF150to NEF152. In response to receiving data flow and/or request message107, NEF152is configured to find the relevant NIDD context information stored in the local database (e.g., see block108). In particular, NEF152utilizes the NIDD context data stored in the priority configuration database to identify the appropriate serving AF (i.e., AF154) the mobile originated data should be sent. For example, NEF152can send a notification request109(e.g., MO data notification request) to application function154using the application programming interface (API) provided by the application function during the initial configuration stage. In response, application function154returns a notification response message110(e.g., MO data notification response) to NEF152, which in turn sends a204‘no content’ message111. Message111serves as an indication to SMF150that the MO data notification request109was successfully delivered.

It should be noted that inFIG.1, there is no UPF involved in the communication of the NIDD flow. In particular, these types of traffic flows are non-IP flows originating from an SMF directed directly toward the application function (i.e., there is no direct data path from the user equipment to the application function since the user equipment does not have an assigned IP address).

FIG.2is a message flow diagram illustrating a NEF that monitors network traffic flows under normal conditions. In particular,FIG.2illustrates a consumer network function250(e.g., a unified data management (UDM) function or access and mobility management function (AMF)), an NEF252, and an application function254communicating monitoring flow messages. In some embodiments, application function254can be configured to issue a subscription request for various monitoring events (e.g., tracking the user equipment location, tracking the user equipment service area, and/or tracking the user equipment's reachability). In particular, there are various types of monitoring subscriptions that an application function can subscribe to. Notably, the network traffic flow for the monitoring subscriptions depicted inFIG.2are 3GPP defined and similar to the NIDD traffic flow messaging depicted inFIG.1. For example, after receiving subscription request message201(e.g., a monitoring event (MONTE) subscription request) from application function254, NEF252is configured to store the monitoring request and its associated context information (e.g., MONTE context data) in a local context configuration database (see block202). In some embodiments, the monitoring context information includes information identifying the UE being monitored. NEF252is then further configured to push a configuration request message203(e.g., a MONTE configuration request) that contains the “monitoring events” configuration information towards a producer NF, generally represented as UDM/AMF250. Notably, the configuration information indicates the specific event(s) that NEF252is adapted to monitor with regard to a particular user equipment (UE) for application function254. After receiving a monitoring configuration response message204from UDM/AMF250, NEF252is configured to direct a monitoring subscription response message205to application function254.

When one of the monitored events specified in the provided configuration information occur at a producer NF endpoint (e.g., one or more of the UDM/AMF250), a monitoring report206will be triggered by the relevant endpoint and sent to NEF252. Notably, NEF252extracts the event information and conducts a monitoring configuration check (e.g., see block207). Namely, NEF252can utilize the mapping of events to the context information stored in configuration database to determine the designated destination application function. NEF252then sends a monitoring report notification request208to the designated destination application function254. In response, application function254sends a monitoring report notification response209to the NEF252, which in turn sends a204‘no content’ message210to the consumer NF250(e.g., UDM/AMF) as an indication of successful delivery.

As described above, binding information pertains to the information an NEF uses to notify a producer or consumer NF (e.g., an SMF) of its priority information and/or configuration information (e.g., a monitoring configuration or a NIDD configuration). Notably, the binding information can be placed in the binding header of messages communicated to the SMF. For example, an NEF can inform a SMF of fellow peer NEFs that could be used to maintain session continuity if the original NEF fails or becomes unavailable. For example, the SMF can initiate the creation of a session to be established with an AF via an NEF. During the session creation process, the NEF (e.g., ‘NEF1’) can include binding information in the binding header of the session response message to inform the SMF that if the first NEF becomes unavailable, then the SMF may contact a paired mate (e.g., ‘NEF2’) of the first NEF. In particular, the paired mate can be used for continuity of the session between the SMF and the AF.

In some embodiments, binding information can be used to indicate a suitable target NF instance (e.g., an AF instance) for NF service instance selection, NF service instance reselection, and routing of subsequent requests associated with a specific NF resource and/or service. This allows the NF producer to indicate that the NF consumer, for a particular context, should be bound to an NF service instance, NF instance, NF service set, or NF set depending on local policies and other criteria.

Thus, when an NEF has peers (e.g., other NEFs included in the same NF set or NF service set) configured to share context information, an NEF can also be configured to push its binding information as an NF service set or an NF set (e.g., see NF set300inFIG.3). Such a mechanism allows for an alternate delivery endpoint for sending SMFs. For example, inFIG.3, if a primary NEF instance301is unavailable (e.g., the NEF that handled the SMContext_Create request from an SMF has failed), SMF303can send a MO data request or monitoring data request to a specified alternate NEF instance (e.g., NEF302inFIG.3). More specifically, SMF303is shown to establish a first session with NEF1301(e.g., the solid arrow) in NF set300. Further, NEF2302in NF Set300can function as the alternate NEF instance as indicated in the binding information should NEF301become unavailable.

However, unlike the functionality afforded to the NEF by 3GPP standards, there is currently no way for an AF to publish binding information with the NEF for alternate AF selection (i.e., selection of a peer AF if the first AF fails) during overload conditions, network failures, and/or software failures. For example, in the event of an AF endpoint failure, the NEF does not have any alternate routing flexibility as compared to other NFs in 5G core network. Moreover, an AF (e.g., an AF located outside of an operator's trusted domain) cannot register with an NRF, which could be configured to possibly help the NEF perform alternate routing through NRF discovery procedures.

FIG.4is a block diagram illustrating a NEF conducting 5G routing under a problematic condition. For example, during the NEF's alternate routing process (e.g., NEF1401becomes unavailable), an alternate instance of the NEF (e.g., NEF2402, which is a peer of NEF1401) may send a notification to the AF instance (e.g., AF1404) that has published its endpoint to the original NEF1during the context creation process. Thus, even if there is an alternate AF server instance (e.g., AF2405) that is available and located in close/local proximity to alternate NEF2402, NEF2402is still currently designed to send notification to alternate AF server instance (as opposed to primary AF1server404). As used herein, “proximity” to the NEF can be understood to mean the AF is within the “locality” or “service scope” of the NEF (e.g., the alternate AF is available in local service scope of the NEF). In addition, proximity can also mean that the proximate AF is an AF that has been assigned and/or configured with a higher priority AF by the network operator. In some embodiments, the endpoint can be identified by an FQDN or IP address of the AF server.

FIG.5depicts a priority configuration database table utilized by one or more NEFs (and/or its priority configuration engine as described below) according to an embodiment of the subject matter described herein. In particular, priority configuration database table500can be configured by a network operator to create rules to define and prioritize alternate application function endpoints for different scenarios as shown inFIG.5. Exemplary priority configuration database table500includes an area column501, an additional rule column502, a routing mode column503, a details column504, an NEF instance column505, and an AF and priority column506. It is understood that priority configuration database table500can include additional or fewer columns without departing from the scope of the disclosed subject matter. In some embodiments, a network operator can configure the NEF instances to operate and manage priority configuration database table500in accordance to a shared data model. For example, the sharing of a priority configuration database table500that contains a configuration and is initially provisioned on a single NEF instance. Notably, the priority configuration database can be automatically replicated (“auto-replicated”) on all the other NEF instances. If the priority configuration database is not replicated in this manner, then the network operator may alternatively choose to conduct and manage this configuration on each of the individual NEF instances.

Referring to table500inFIG.5, area column501includes data network name (DNN) identifiers identifying the networks serviced by the listed NEF instances and AF endpoints identified in columns505-506. Additional rule column502includes a list and/or a range of international mobile subscriber identity (IMSI) identifiers serviced in the DNN identified in column501. Routing mode column503identifies the routing mode related to the rule entry. Routing modes can include “normal” or “override” as discussed further below. Details column504provides an entry for including notes or descriptions related to the rule entry. NEF instance column505lists each of the NEF instances included in the particular service area/DNN. In particular, column505contains the instance ID of each NEF for which a given routing rule applies. In some embodiments, the instance ID is a unique identifier for each NF that is published as part of an NFProfile to the NRF. Likewise, column506lists the AF identifiers and corresponding priority as related to each particular NEF instance indicated in column505. In particular, the priority indicators designated the priority order of the AF endpoint in which the particular NEF instance listed in column505attempts to utilize to establish a session.

In some embodiments, a network operator may configure, provision, or modify certain parameters for one or more entries of configuration table500. For example, a network operator can configure the priority indicators (e.g., see column506of table500) associated with a particular DNN and/or IMSI range (e.g., see columns501-502). These entry parameters can generally be used by the NEF instance to assign and prioritize application functions as alternative endpoints for each of a plurality of NEF instances present in a particular DNN (and/or NF service set). More specifically, each entry of configuration table500can establish the binding priorities between each of a plurality of NEF instances and different application function endpoints. To illustrate, the column505entry in row1of configuration table500includes three separate NEF instances (e.g., ‘instance ID1’, instance ID2′, and ‘instance ID3’) that are respectively mapped to three application functions in accordance with specific priority indicators. Notably, this first row of table500identifies a specific data network (e.g., ‘DNN1’) and corresponding IMSI range (e.g., ‘IMSI=range A-B’). Moreover, this first row of configuration table500also indicates NEF instance ID1is bound to AF1(which is further identified by a unique FQDN/IP identifier) with a priority indicator of 1. Notably, “priority=1” indicates the primary binding priority existing between AF1and NEF1. Likewise, the binding priority between NEF1and AF2is indicated by “priority=2” and the binding priority between NEF1and AF3is defined by “priority=3” (e.g., see first entry in column506). Similarly, configuration table500indicates the priority binding existing between NEF2and AF2is the primary binding (e.g., “priority=1”). Likewise, the binding priority between NEF2and AF1is indicated by “priority=2” and the binding priority existing between NEF2and AF3is indicated by “priority=3”. Accordingly, the network operator can utilize configuration table500by adding or modifying table entries in this manner to bind multiple AF endpoints to various NEF instances (e.g., by assigning different priorities in the entries of configuration table500).

In some embodiments, the disclosed methodology associated with the operation of the priority configuration database can be executed by an NEF instance and/or a ‘priority configuration engine’ supported by the NEF instance. For example, the priority configuration engine can be an algorithm, program, or script stored in memory that when executed by a processor performs the following steps and/or logical operations. In some embodiments, priority configuration engine represents a list of steps (or changes in steps) embodied in a state machine (e.g., either via software code programming or via a set of rules) of the NEF instance.

After a network operator creates and establishes rules defining the alternative routing priorities of various application functions in priority configuration database table500, an NEF instance with access to the priority configuration database can specify binding headers in request messages that are sent by the NEF instance to select NFs (e.g., SMF, AMF, UDM, etc.) operating in the core communications network. For example, in the scenario where DNN=DNN1and IMSI range=range A-B (e.g., columns501-502in first row in table500), the NEF instance can publish or set the binding scope (i.e., binding information) for its associated NF Set and/or NF Service Set in response to receiving and accepting the SMContext_Create request message from the SMF. Receiving the binding information via the binding header of the request message allows the SMF instance to perform an alternate routing to other NEF instances located in the same DNN and servicing a particular IMSI range.

When the NEF instance receives mobile originated data, a monitoring report (e.g., a MONTE report), or any other NEF event that requires a notification to be generated towards application function, the NEF instance conducts a check to determine if a configuration from any AF endpoint exists in the shared context databases of the NEF(s) (i.e., that matches the AF identification that is indicated in the message received by the NEF). If a context configuration entry exists in the shared context database, the NEF instance looks for a matching rule in the priority configuration database (e.g., for MO data, a table entry containing the same DNN and within IMSI range as values contained in message received by the NEF instance) previously configured by the network operator.

As indicated above, the priority configuration database can include entries corresponding to “overwrite” and “normal” routing modes. If a matching rule exists in the priority configuration database and the associated routing mode is indicated as “normal”, then the NEF instance is configured to route messages to the application function destination endpoint that was defined and/or established during the corresponding context created for a given AF. In the event that original application function endpoint fails or otherwise becomes unavailable, the NEF can utilize the priority configuration database to reference and apply the priorities indicated (and previously established by the network operator in the priority configuration database) to select the alternate AF endpoint in accordance with the network operator's rule.

The “normal” routing mode can also be utilized in instances when an NEF fails. For example, consider the scenario where the NEF1instance has failed and the NEF2instance has received the monitoring data and/or the mobile originated data. If the routing mode in the priority configuration database is set to “normal”, this is an indication that the alternate NEF2always first attempts to communicate via a session with AF1, which is proximate to failed NEF1. In the event AF1also fails, then the configuration table can indicate that NEF2should continue the session with AF2. Accordingly, “normal” as used herein generally means the NEF instance may continue communicating with the AF, but should the application function endpoint fail, then the NEF instance applies the network operator's rule in the priority configuration database to locate the next available application server for routing.

In contrast, the routing mode “override” means that even if AF1was the application function that has been configured to communicate with NEF1, an alternative application function can be selected by NEF2regardless the availability status of AF1. For example, the priority configuration database may indicate that NEF2has a priority binding with AF2equal to “priority=1”. In this override setting (and if NEF1fails), NEF2will immediately attempt to continue the session with AF2instead of AF1. Override essential means that the initial configuration is being overridden with the priority parameters indicated in the priority configuration table.

Thus, returning the example, if context exists in the context database and a matching rule exists in the priority configuration database but the routing mode is instead set to “override” (as opposed to “normal”), the NEF instance will check if the application function configuration is present for self-instance identification. In some embodiments, each NEF instance can be configured to search for its own instance identifier in table500for a matching area and IMSI (e.g., columns501-502) for purposes of applying the corresponding priority rule (e.g., column506). For example, NEF1will look for priority rules associated to its own instance identifier only. If the self-instance identifier is found to exist, the NEF (and/or the priority configuration engine) is configured to use the AF's endpoint identifier (e.g., FQDN/IP address) that is associated with priority1for its own instance identifier. For example, the notification URL can be adjusted from context data by the NEF (and/or priority configuration engine) and the rest of the procedure may be run as defined by 3GPP standards for notifications between the NEF and AF. If a “priority1” AF endpoint is not able to be reached, then the NEF (and/or priority configuration engine) may use an AF endpoint with a lower priority indicator (e.g., priority=2) as the alternate endpoint. If no AF configuration is present for self-instance identification, then the NEF does not send a notification to the application function and subsequently rejects request messages received from the consumer network functions (e.g., AMF, SMF, UDM, etc.).

Alternatively, if context exists in the context database but no matching rule is found in the priority configuration database by the NEF (and/or the priority configuration engine), then the NEF instance that accepted the configuration (and/or its priority configuration engine) is allowed to generate and send a notification message to the application function that created the original context with the NEF. In alternate embodiments, if a given application function endpoint is not available, the NEF instance can perform DNS based alternate routing if the application function endpoint is identifiable by a FQDN and the DNS server of the network operator has multiple IP addresses assigned to that FQDN.

FIG.6is a message flow diagram illustrating a NEF routing non-IP data delivery network traffic in response to an AF failure according to an embodiment of the subject matter described herein. Referring toFIG.6, NEF1651and NEF2652are configured to share and/or replicate their local context databases (e.g., see link601). NEF1651is depicted as including a priority configuration engine670(e.g., a software and/or state machine element that is responsible for performing the disclosed methodology) and a local priority configuration database660. In some embodiments, NEF1651receives a configuration request message602(e.g., an NIDD configuration request) from AF1653. After receiving configuration request message602, NEF1651stores the NIDD context information contained within configuration request message602in a shared context database. Once the context information is stored in the context database, NEF651sends a configuration response message604(e.g., an NIDD configuration response) to AF1653.

After storing the NIDD context information, NEF651receives a context creation request message605(e.g., SMContext_Create request) from SMF650, which is supporting one or more subscriber user equipment. In response to receiving request message605, NEF1651(and/or its priority configuration engine670) can access the shared context database and validate the previously stored NIDD configuration from AF1653. If the configuration is valid, NEF1651(and/or its priority configuration engine670) may accept and process context creation request message605. At this stage, NEF1651may be configured to send a context creation acknowledgment message607to SMF650. SMF650can subsequently send a MO delivery request message608(e.g., a {resourceURl}/deliver request message) that contains mobile originated data from a sending user equipment (not shown) that is serviced by SMF650. After receiving delivery request message608, NEF1651attempts to send a mobile originated data notification request message609to AF1653. However, at some point after receiving configuration response message604, AF1653failed or otherwise became unavailable in the network (see “X” inFIG.6). As such, NEF1651never receives a mobile originated data notification response message from unavailable AF1653in response to the previously sent MO data notification request message609. As such, NEF1651attempts to find NIDD context information in the local priority configuration database660. Based on the operator configuration, NEF651is able to find the ‘next priority’ AF endpoint details in the priority configuration database660. Once the appropriate application function endpoint (e.g., AF2is associated with priority=2 for NEF1) is determined, NEF1651sends the mobile originated data to the identified application function (e.g., AF2654). In particular, NEF651sends a mobile originated data notification request message611to identified AF2654. After receiving the notification request message611, AF654responds by directing a mobile originated data notification response message612to NEF1651. NEF1651subsequently sends a no content acknowledgment message613to SMF650to indicate the delivery was successful.

FIG.7is a message flow diagram illustrating a network exposure function (NEF) monitoring network traffic in response to an NEF failure according to an embodiment of the subject matter described herein. Referring toFIG.7, NEF1751and NEF2752share and/or replicate their local context databases (see link701). Further, NEF2752is depicted as including a priority configuration engine770(e.g., a software and/or state machine element that is responsible for performing the disclosed methodology) and a local priority configuration database760. In some embodiments, NEF1751receives a configuration request message702(e.g., a NIDD configuration request) from AF1753. After receiving configuration request message702, NEF1751stores the NIDD context information contained in configuration request message702in the context database. Once the information is stored in the context database, NEF1751sends a configuration response message704(e.g., NIDD configuration response) to AF1753.

After storing the NIDD context information, NEF1751receives a context creation request message705(e.g., SMContext_Create request) from SMF750. In response to receiving request message705, NEF1751can be configured to validate the previously stored NIDD configuration related to AF1753. If the NIDD configuration is valid, NEF1751may accept and process context creation request message705. At this stage, NEF1751may also send a context creation acknowledgment message707(e.g., a ‘201Created message’) to SMF750to indicate the successful validation. In the depicted scenario, NEF1751fails or otherwise becomes unavailable after sending acknowledgment message707(as shown by “X” inFIG.7).

In response to receiving acknowledgment message707, SMF750can perform an alternate routing (see block708) based on the binding header information previously received in message707. SMF750may then send to alternate NEF2752a MO delivery request message709(e.g., a {resourceURl}/deliver request message) that contains mobile originated data from a sending user equipment (not shown) serviced by SMF750.

After receiving delivery request message709, NEF2752(and/or priority configuration engine770) attempts to find NIDD context information in its local context database. Based on the operator configuration, NEF2752is able to find the ‘next priority’ AF endpoint information in the priority configuration database760. In this example, NEF2752is primarily bound to AF2754as opposed to application function753(which was primarily bound to NEF1751). Once the appropriate AF endpoint is determined and assuming the priority configuration database entry indicates the “override” setting, NEF2752sends the MO data to the newly identified application function (e.g., AF2754). In particular, NEF2752sends a mobile originated data notification request message711to identified AF2754. After receiving the notification request message711, AF2754responds by directing a mobile originated data notification response message712to NEF2752. NEF2752subsequently sends a no content acknowledgment message713to SMF750indicating the successful delivery.

FIG.8is a flow chart illustrating an example process for identifying alternate delivery endpoints for mobile originated (MO) data and monitoring reports in a communications network a communications network according to an embodiment of the subject matter described herein. In some embodiments, method800depicted inFIG.8is an algorithm, program, or script (e.g., priority configuration engine660and760as shown inFIGS.6and7, respectively) stored in memory that when executed by a processor performs the steps recited in blocks802-808. In some embodiments, priority configuration engine represents a list of steps (or changes in steps) embodied in a state machine (e.g., either via software code programming or via a set of rules) of the NEF.

In block802, priority rules are established in a priority configuration database that define routing priority indicators corresponding to a plurality of applications functions. In some embodiments, the priority rules are established by a NEF in a communications network and/or by a supported priority configuration engine.

In block804, a service request or notification request message directed to one of the plurality of AFs is received by the NEF from a consumer network function (NF) in the communications network. In some embodiments, the service request or notification request message received from the consumer NF can be an SMContext create request message received from a SMF in the communications network. Alternatively, the received service request or notification request message can be from an AMF or UDM function in the communications network.

In block806, a context database is accessed by the NEF to validate context information associated with a destination AF belonging to the plurality of AFs. In some embodiments, the NEF validates the previously established context corresponding to the session existing between the destination AF and the NEF.

In block808, in response to determining that the destination AF is unavailable, an event notification request (e.g., a MONTE report notification request or a MO data notification request) message associated with the service request or notification request message is directed to a prioritized AF specified in the priority configuration database, wherein the prioritized AF is a peer of the destination AF. In some embodiments, the NEF determines that the destination AF has failed or is otherwise unavailable and attempts to utilize the priority configuration database identify a related AF that can support the service request of the consumer NF. For example, the NEF can use DNN and/or IMSI data included in the service request or notification request message can be utilized to identify a related AF (e.g., a peer of the original destination AF) based on specified priority identifier information in the manner described above.

It should be noted that disclosed subject matter provides a practical solution for supporting alternate routing capabilities that permits a network operator to promptly manage AF failures or downtime scenarios by failing over to an alternate AF or routing to a closest proximity application function with “override” routing mode. Notably, the disclosed solution enables high availability between the network operator's NEF and the AF instances hosted by one or more vendor entities. The disclosed solution also does not require any custom features or behavioral changes in the supported AF or any other components. As such, the disclosed methodology provides a technical advancement due to its efficiency in terms of maintainability and serviceability by the network operator. It should also be noted that the solution is fully backward compatible and controlled via network operator configurations, thus there are no violations of 3GPP defined procedures.

It will be understood that various details of the presently disclosed subject matter may be changed without departing from the scope of the presently disclosed subject matter. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation.