Method for providing optimized notification with clear out-come to application function on traffic influence enforce-ment in mobile network

Abstract

Core architecture has been designed to support a diverse array of services with unique re- quirements and is characterized by a decentralized structure where each network function of- fers a different set of functionalities Exposure is one of the functionalities introduced in 5G. This concept of network exposure is managed by an NF called Network Exposure Function (NEF) which offers numerous services like Event Monitoring, Traffic Influence, AFSession- WithQoS, Chargeable Party etc. According to 3GPP TS 29.522, Traffic Influence API offered by NEF provides a facility for an external Application Function (AF) to influence the user plane traffic of UE(s). Present invention describes methods for improving Traffic Influence Notifi- cation framework by adding attributes in data models of entities like NEF, UDR and SMF to provide optimized notification with clear information in notification that goes to AF regarding the outcome of enforced traffic routing in core network.

Description

METHOD FOR PROVIDING OPTIMIZED NOTIFICATION WITH CLEAR OUTCOME TO APPLICATION FUNCTION ON TRAFFIC INFLUENCE ENFORCEMENT IN MOBILE NETWORKFIELD OF THE INVENTION

[0001] The present invention relates to communication between network functions in a cellular / mobile network, and more particularly to managing communication between network functions for influencing user plane traffic through traffic influence.BACKGROUND OF THE INVENTION

[0002] Network Exposure Function (NEF) within 5G core plays a crucial role in exposing the 5G network to external untrusted Application Functions (AFs). Serving as a gateway, NEF facilitates interactions with 5G Core network functions through standard REST API-based HTTP interfaces. After authentication and authorization by NEF, untrusted AF gains access to services offered by the 5G Core. NEF offers multiple service APIs which broadly come under either Northbound or Southbound APIs where external AFs can invoke the Northbound APIs while 5G Core Network Functions (NF) can invoke the Southbound APIs as shown in Fig. 1 illustrating NEF Interactions with external AF and 5G core Network Functions. On a high- level, NEF services can be categorized into monitoring capability, provisioning capability, policy / charging capability, analytics capability and network-status reporting capability.

[0003] The Application Functions (AFs) are of two types, trusted and untrusted. A trusted AF can interact with core NFs directly and an untrusted AF interacts to the core via a NEF. In certain implementations, the trusted AF interacts directly with a PCF and the untrusted AF interacts with the PCF via the NEF.

[0004] Traffic Influence API is one of the service APIs which comes under NEF’ s provisioning capability. It is used by external untrusted AF for influencing user plane traffic by providing filter and route information for routing of identified traffic flow to the desired destination. AF can also subscribe to notification for user plane path change event. User Plane (UP) Path Change Management Event Subscription allows network entities, such as the AF or NEF, to subscribe to receive notifications whenever the requested traffic routing is implemented in the UP path. The network functions involved to serve the AF traffic influence request apart from NEF in our scope are Policy and Control Function (PCF), Session Management Function(SMF) and User Plane Function (UPF). Each NF performs its own functionality to serve this AF request as follows. NEF acts as the gateway and authorizes the untrusted AF and if the AF is authorized for using this service it translates the request to PCF. PCF forms the corresponding rules and provides the pcc rules to SMF. SMF is the anchor point for serving traffic influence which performs function of discovering the desired UPFs, modifying the user plane data path by installing packet detection rules and forwards action rules in UPF. UPF enforces the rules installed in it and routes the traffic flow as per the AF request.

[0005] When the AF has subscribed for user plane path change event, SMF generates a notification including information about the positive outcome of the requested traffic influence. This notification is sent to NEF directly by SMF. The NEF translates this information and notifies AF about the outcome of the requested traffic influence. SMF also generates reports for negative outcome of the requested traffic influence and the event is notified by SMF to PCF.

[0006] The traffic Influence API offered by NEF provisions untrusted AF to invoke this service for requesting routing of data flow(s) and subscribe for notifications that is to be provided when the user plane path changes. The API has provision to provide request using different attributes, few relevant ones are explained below.

[0007] The information related to routing of data flow(s) is provided by AF in the request payload as following. The “trafficFilters” information provides the information to identify the data flow(s) that must be routed. The “trafficRoutes” information contains the information about the destination where the data flow identified by “trafficFilters” must be routed.

[0008] The information related to subscription for notification of user plane path change is provided as following. The “subscribedEvents” information provides the events for which this subscription is meant for, in this case it will indicate the subscription is for the event of user plane path change. The “dnaiChgType” information provides the data about when the notification must be delivered to AF. It can take three different values currently. First value indicates that the AF must be notified before user plane path of the data flow changes. Second value indicates that the AF must be notified after user plane path changes. The third value indicates that the AF must be notified before and after the user plane path changes. The “notificationDestination” information provides the callback URL using which AF must be notified.

[0009] Fig. 2 illustrates call flow of AF request for traffic influence along with subscription for user plane path change for an ongoing Protocol Data Unit (PDU) session where both success and failure of requested routing has occurred. In step la, the untrusted AF requests a NEF for traffic influence and subscribes for user plane path change for an ongoing PDU session. From step 2a to step 3b, translation of AF request takes place where NEF translates the information provided by the AF to a PCF, and the PCF forms traffic rules and sends it to an SMF. In step 4a, the SMF provides the rules to a UPF. From the response of the UPF, in step 4b, the SMF identifies the success and / or failure of enforcement of the rules by UPF. If a successful enforcement is detected from UPF response in step 4b, SMF notifies NEF directly as indicated in step 5a. In the success notification following information are sent. The “supi” information provides the internal user identity. The “sourceDnai” and “sourceTraRouting” information provides DNAI related data, towards which the traffic flow was heading before switching. The “targetDnai” and “targetTraRouting” information provides the destination DNAI related data, towards which the traffic flow is routed after switching. The “trafficFilters” information provides traffic flow that is routed. The “timeStamp” information provides the time at which the event is observed. The “dnaiChgType” information indicates that the notification is triggered either before or after the routing of traffic flow based on the subscription provided.

[0010] In step 7a NEF translates the information received in notification from SMF and notifies the corresponding AF. In this notification sent to AF following information are sent. The “gpsi” information provides the external user identity. The “sourceDnai” and “sourceTrafficRoute” information provides DNAI related data, towards which the traffic flow was heading before switching. The “targetDnai” and “targetTrafficRoute” information provides the destination DNAI related data, towards which the traffic flow is routed after switching. The “dnaiChgType” information indicates that the notification is triggered either before or after the routing of traffic flow based on the subscription provided.

[0011] When failure of enforcement is detected in UPF response in step 4b, the SMF indicates about the failure to the PCF, in step 6a, using few attributes as follows. The “pccRulelds” information provides the identity of filters whose enforcement got failed. The “ruleStatus” information provides the status of the filters provided in pccRulelds which corresponds to ‘NOT ACTIVE’ state in this failure case. The “failureCode” information provides the reason of failure which corresponds to error in switching traffic. Currently, PCF notifies about thefailure only to trusted AF, if it has requested for traffic influence and subscribed for the failure of user plane path change of the same.

[0012] Fig. 3 illustrates call flow of AF request for traffic influence along with subscription for user plane path change for future PDU session(s). In step a, PCF subscribes with a UDR for getting notification of traffic influence request. In step la, the untrusted AF requests a NEF for traffic influence and subscribes for user plane path change for future PDU session(s). In step 2.1a, the NEF identifies that the AF request is to be stored in application data base of the UDR by the absence of UE address in the AF request and stores the AF request in the UDR. In step 2.2a, the UDR notifies the subscribed PCF with the AF request and whenever the respective PDU session(s) is / are established, PCF forms traffic rules and sends it to SMF as in step 3 a.

[0013] Remaining steps in handling of traffic influence request for future PDU sessions remain same as that in the call flow of ongoing PDU sessions. Such steps are depicted as step 3a through step 7b in Fig. 2. As mentioned above, the successful enforcement of traffic influence is notified by the SMF to the NEF and the failure of enforcement is indicated by the SMF to the PCF.

[0014] The traffic influence API offered by the NEF is not having the support of subscription of user plane path change failure to be requested by the untrusted AF. Also, the notification data model from the NEF to the AF for the subscribed user plane path change event is not having information about the traffic flows which are successfully implemented or failed to implement, for which the notification corresponds to.

[0015] In one scenario, the AF may request for routing of two traffic flows identified by trafficFilterl and trafficFilter2 to a destination DNAI indicated by trafficRoute in a single request. The problem explained above is seen in particular scenarios when there is a complete failure in implementing the requested traffic routing or partial success in implementing the requested traffic routing. The scenarios are explained successively.

[0016] In a first scenario, a UPF may face complete failure in implementing routing of traffic flows, as shown in call flow diagram of Fig. 4a. An SMF identifies the failure from the Request Rejected message in the aUPF’s response, at step 4b. There is a provision for the SMF to report this failure report to a PCF indicating enforcement of trafficFilters are failed, as indicated in step 6a. The PCF can notify the same to any NF, including a NEF, if it has subscribed for userplane path change failure event. Currently, an AF is not having the provision to subscribe for the user path change failure event. Hence, the NEF also cannot subscribe for user plane path change failure event, as the AF is not asking for it. Hence there is no notification is triggered towards the NEF, thus the AF will not be able to know the outcome of the requested traffic influence.

[0017] In case of future PDU sessions, for the same problem as described above, there is no provision in a UDR for a NEF to subscribe for failure notification, because of which an AF won’t be notified about the outcome of the requested traffic influence.

[0018] In a second scenario, a UPF may find partial success in implementing routing of traffic flows, as shown in call flow diagram of Fig. 4b. As shown, the UPF performs routing enforcement of traffic flow identified by trafficFilterl and fails to enforce routing of traffic flow identified by trafficFilter2. A SMF identifies the failure from the created PDR list and Partial Failure information from UPF’s response, at step 4b. There is a provision for the SMF to report this failure to a PCF indicating the enforcement of trafficFilter2 failed, as indicated in step 6a. The PCF can notify the same to any NF, including a NEF, if it has subscribed for user plane path change failure event. Currently, an AF does not have the provision to subscribe for the user path change failure event. Hence, NEF also cannot subscribe for user plane path change failure event, as the AF is not asking for it.

[0019] The notification for successful user plane path change is triggered in SMF because traffic flow identified by trafficFilterl is successfully routed to the requested destination. For this trigger SMF reports the user plane path change notification to NEF where the affected traffic flow which is trafficFilterl is indicated, as shown in step 5a. NEF can know the result of enforcement of traffic influence only from the notification from SMF.

[0020] But the notification data model that carries information from NEF to untrusted AF is not provisioned to indicate the traffic flow information for which successful user plane path change notification corresponds to. This results in misinformation, and this affects the action taken by AF after receiving this notification since it assumes all the requested traffic flow has been routed to the requested destination.

[0021] In case of future PDU sessions, where the traffic influence request from AF to NEF is stored in UDR, the subscribed events and it’ s related attributes passed over to UDR are not having the user plane path change failure event and corresponding callback URI of NEF. Oncethe UDR notifies to PCF on the traffic influence request, upon successful implementation of traffic filters, the notification of successful user plane path change will be forwarded to NEF by SMF. In case of failure scenario, since there is no subscription for user plane path change failure PCF will not notify NEF.

[0022] In summary, in the existing notification framework for traffic influence feature, AF will not be able to subscribe to user plane path change failure event hence will not get notified in case of failure in implementing the requested traffic influence. Also, in case of partial success in implementing the requested traffic influence, in the existing notification data model from NEF to AF, NEF will not be able to convey the exact information of what flow(s) have been routed and what have not been routed. Thus, AF might assume that all the requested flow(s) have been routed. This will affect the action taken by AF, based on this notification.

[0023] There is therefore a need for solution(s) using which the above described shortcomings could be addressed.OBJECTS OF THE INVENTION

[0024] A general objective of the present invention is to provide a mechanism of allowing an AF to subscribe to user plane path change failure event for being able to get notified during failure in implementing requested traffic influence.

[0025] Another objective of the present invention is to allow a NEF to convey exact information of what flow(s) have been routed and what have not been routed, in scenarios where partial success is found in implementing requested traffic influence.SUMMARY OF THE INVENTION

[0026] The summary is provided to introduce a method of indicating an outcome of traffic routing requested by an application function (AF) in a telecommunication network, and the method is further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.

[0027] In one embodiment, a method of indicating an outcome of traffic routing requested by an application function (AF) in a telecommunication network is described. The method comprises receiving, by a network exposure function (NEF), a traffic influence request froman AF including a plurality of first attributes. The plurality of first attributes comprise a target User Equipment (UE) address and a subscription to, installation outcome of requested traffic routing requirements. The method further comprises determining, by the NEF, the traffic influence request comprises a UE address. The method further comprises sending, by the NEF, a first service request including a plurality of second attributes corresponding to the traffic influence request to a Policy Control Function (PCF). The plurality of second attributes comprise the subscription to a traffic routing requirement installation outcome based on the traffic influence request. The method further comprises sending, by the PCF, a second service request including a plurality of third attributes corresponding to the first service request, to a Session Management Function (SMF). The plurality of third attributes comprise subscription to the traffic routing requirement installation outcome based on the first service request. The method further comprises sending, by the SMF, a request to a User Plane Function (UPF) based on the second service request. The method further comprises receiving, by the SMF, a first response from the UPF. The method further comprises determining, by the SMF, the success and failure of a plurality of traffic routing requirements based on the first response from UPF. The method further comprises sending, by the SMF, a first notification including a plurality of fourth attributes corresponding to the second service request, to NEF. The plurality of fourth attributes comprise traffic route requirement installation outcome based on the determination from the first response of UPF. The method further comprises sending, by the NEF, a second notification including a plurality of fifth attributes corresponding to the first notification, to the AF. The plurality of fifth attributes comprise installation outcome of the requested traffic routing requirements based on the first notification. The method further comprises receiving, by the NEF, a second response including a header from the AF. The header comprises status code to confirm the reception of the second notification

[0028] In one embodiment, a method of indicating an outcome of a traffic routing requested by an AF in a telecommunication network is described. The method comprises receiving, by a NEF, a traffic influence request from an AF including plurality of first attributes. The plurality of first attributes comprises a plurality of target UE identifier(s) and a subscription to, installation outcome of requested traffic routing requirements. The method further comprises determining, by the NEF, that the traffic influence request comprises at least one UE identifier without UE address. The method further comprises sending, by the NEF, a first service request including plurality of second attributes to a Unified Data Repository (UDR) corresponding to the traffic influence request. The plurality of second attributes comprise subscription toinstallation outcome of the requested traffic routing requirements based on the traffic influence request. The method further comprises storing, by the UDR, the plurality of second attributes in an application data repository. The method further comprises notifying, by the UDR, a first notification including plurality of third attributes based on the stored attributes to a PCF subscribed to the application data modification. The plurality of third attributes comprise subscription to installation outcome of the requested traffic routing requirements based on the stored attributes. The method further comprises sending, by the PCF, a second service request including plurality of third attributes corresponding to the first service request, to a SMF. The plurality of third attributes comprise subscription to a traffic routing requirement installation outcome based on the first service request. The method further comprises sending, by the SMF, a request to a User Plane Function (UPF) based on the second service request. The method further comprises receiving, by the SMF, a first response from the UPF. The method further comprises determining, by the SMF, the success and failure of a plurality of traffic routing requirements based on the first response from the UPF. The method further comprises sending, by the SMF, a second notification including a plurality of fourth attributes corresponding to the second service request, to NEF. The plurality of fourth attributes comprise traffic route requirement installation outcome based on the determination from the first response of UPF. The method further comprises sending, by the NEF, a third notification including a plurality of fifth attributes corresponding to the first notification, to the AF. The plurality of fifth attributes comprise installation outcome of the requested traffic routing requirements to the AF based on the second notification. The method further comprises receiving, by the NEF, a second response including a header from the AF. The header comprises a status code to confirm the reception of the second notification.

[0029] In one embodiment, a method of indicating an outcome of traffic routing requested by an AF in a telecommunication network is described. The method comprises receiving, by a NEF, a traffic influence request including plurality of first attributes, from an AF. The plurality of first attributes comprises a subscription to installation outcome of requested traffic routing requirements. The method further comprises determining, by the NEF, whether the traffic influence request comprises one of a UE address and at least one UE identifier without UE address. The method further comprises sending by the NEF, one of a first service request and a second service request. The first service request contains a plurality of second attributes to a PCF, when the traffic influence request comprises the UE address. The plurality of second attributes comprise the subscription to traffic routing requirements installation outcome event.The second service request contains a plurality of third attributes to a UDR, when the traffic influence request comprises at least one UE identifier without UE address. The plurality of attributes comprises the subscription to installation outcome of the requested traffic routing requirements and information for enabling NEF to receive and identify the notification for the subscription. The method further comprises receiving, by the NEF, a first notification including a plurality of fourth attributes from SMF. The plurality of fourth attributes comprise the installation outcome of the requested traffic routing requirements. The method further comprises determining, by the NEF, the AF subscription for this notification. The method further comprises sending, by the NEF, a second notification including a plurality of fifth attributes to the determined AF. The plurality of fifth attributes comprises the installation outcome of the requested traffic routing requirements. The method further comprises receiving, by the NEF, a response including a header from the AF. The header comprises status code to confirm the reception of the second notification.

[0030] In one embodiment, a method to indicate an outcome of traffic routing requested by an AF in a telecommunication network is described. The method comprises receiving, by a UDR, a service request including plurality of attributes from a NEF based on the request from AF. The plurality of attributes comprises a subscription to installation outcome of requested traffic routing requirements, information for enabling NEF to receive the notification and to identify the notification for the subscription. The method further comprises storing, by the UDR, the plurality of attributes in an application data repository. The method further comprises sending, by the UDR, a notification including the plurality of attributes to the subscribed PCF, based on the presence of a PCF subscription for the application data modifications.

[0031] In one embodiment, a method to indicate an outcome of traffic routing requested by an AF in a telecommunication network is described. The method comprises receiving, by a PCF, one of a first service request and a notification. The first service request includes a plurality of first attributes from a network function. The plurality of first attributes comprise a subscription to traffic routing requirement installation outcome event. The notification includes a second plurality of second attributes from UDR. The plurality of second attributes comprise a subscription to installation outcome of the requested traffic routing requirements, information for enabling NEF to receive the notification and to identify the notification for the subscription. The method further comprises obtaining by the PCF, a translated subscription including subscription to traffic routing requirement installation outcome event using one of asubscription to traffic routing requirement installation outcome event from the plurality of first attributes, and a subscription to installation outcome of the requested traffic routing requirements from the plurality of second attributes. The method further comprises provisioning, by the PCF, a second service request to indicate rules comprising a plurality of third attributes to a SMF. The plurality of third attributes comprises the translated subscription.

[0032] In one embodiment, a method to indicate an outcome of traffic routing requested by an AF in a telecommunication network is described. The method comprises receiving, by a SMF, a service request indicating rules comprising a plurality of first attributes from a PCF. The plurality of first attributes comprise a subscription to traffic routing requirement installation outcome event from a subscribed function. The method further comprises sending, by the SMF, a request to a UPF. The method further comprises receiving, by the SMF, a response from UPF. The method further comprises determining, by the SMF, the traffic route requirement installation outcome based on success and failure of installing a plurality of traffic routing requirements using the response. The traffic route requirement installation outcome comprises at least one of the plurality of traffic flows whose routing requirements are successfully installed, and the plurality of traffic flows whose routing requirements are failed to install. The method further comprises sending, by the SMF, a notification including a plurality of second attributes to the subscribed function based on the service request. The plurality of second attributes comprise installation outcome of the requested traffic routing requirements.BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Fig. 1 illustrates NEF Interactions with external AF and 5G core Network Functions.

[0034] Fig. 2 illustrates call flow of AF request for traffic influence along with subscription for user plane path change for an ongoing PDU session where both success and failure of requested routing has occurred.

[0035] Fig. 3 illustrates call flow of AF request for traffic influence along with subscription for user plane path change for future PDU session(s).

[0036] Fig. 4a illustrates a call flow diagram showing a UPF facing complete failure in implementing routing of traffic flows.

[0037] Fig. 4b illustrates a call flow diagram showing a UPF finding partial success in implementing routing of traffic flows.

[0038] Fig. 5 illustrates a call flow diagram of a method of enabling a NEF to provide information regarding negative outcome to a AF in case of traffic influence for an ongoing PDU session.

[0039] Fig. 6 illustrates a call flow diagram of a method of enabling a NEF to provide clear information regarding positive outcome to AF in case of traffic influence for an ongoing PDU session.

[0040] Fig. 7 illustrates a call flow diagram of a method of enabling a NEF to obtain success and / or failure notification directly from SMF in implementing routing of traffic flows.

[0041] Fig. 8 illustrates a call flow diagram showing notification of result in enforcement of requested traffic routing requirement in case of ongoing PDU.

[0042] Fig. 9 illustrates a call flow diagram showing notification of result in enforcement of requested traffic routing requirement in case of future PDU(s).DETAILED DESCRIPTION OF THE INVENTION

[0043] As used in the description herein and throughout the claims that follow, the meaning of “a,” “an,” and “the” includes plural reference unless the context clearly dictates otherwise. Also, as used in the description herein, the meaning of “in” includes “in” and “on” unless the context clearly dictates otherwise.

[0044] Exemplary embodiments will now be described more fully hereinafter with reference to the accompanying drawings, in which exemplary embodiments are shown. This disclosure may however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. These embodiments are provided so that this disclosure will be thorough and complete and will fully convey the scope of the disclosure to those of ordinary skill in the art. Moreover, all statements herein reciting embodiments of the disclosure, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future (i.e., any elements developed that perform the same function, regardless of structure).

[0045] The 5G Core architecture has been designed to support a diverse array of services with unique requirements and is characterized by a decentralized structure where each network function offers a different set of functionalities. Exposure is one of the functionalities introduced in 5G. This concept of network exposure is managed by an NF called Network Exposure Function (NEF) which offers numerous services like Event Monitoring, Traffic Influence, AFSessionWithQoS, Chargeable Party etc. According to 3GPP TS 29.522, Traffic Influence API offered by NEF provides a facility for an external Application Function (AF) to influence the user plane traffic of UE(s). This document's scope covers workable solutions that shall provide enhancements in Traffic Influence Notification framework by adding attributes in data models of entities like NEF, UDR and SMF to provide optimized notification with clear information in notification that goes to AF regarding the outcome of enforced traffic routing in core network.

[0046] Present invention provides mechanisms to convey clear notification to AF about the outcome of the requested traffic routing. Specifically, two solutions are proposed, and both the solutions resolve the issues independently. A first solution achieves this by sending two separate notifications to NEF from two entities i.e., success outcome notification from SMF directly and failure outcome notification from SMF via PCF. A second solution achieves this by enabling SMF to send a single notification which can comprise both success and failure outcome to NEF. The AF can be a trusted AF or an untrusted AF (uAF). The trusted AF interacts directly with a PCF and the untrusted AF (uAF) interacts with the PCF via the NEF.Enabling NEF for AF to subscribe for failure outcome:

[0047] Provisioning in NEF for the AF to subscribe and receive notification for failure user plane path change. This is done by addition of user plane path change failure event in the events of NEF.Solution 1: Two notification support

[0048] This is achieved:• Based on a common part of the solution explained above, NEF can indeed subscribe for the corresponding user plane path change failure event in PCF, in the case of ongoing PDU session.• By addition of user plane path change failure in the events of UDR and its notification URI in UDR makes it possible for NEF to subscribe for corresponding user plane path change failure event in PCF, in the case of future PDU session(s).• By providing the filters information which are successfully routed or failed to be routed in the user plane path change event notification to AF. Addition of new attributes in NEF’s notification data model would provision NEF to provide clear notification to AF.

[0049] The new attributes are mentioned below in Table 1, the two attributes target to provide clarity to AF by indicating the trafficFilter or ethTrafficFilter information along with other information, which provides the AF, the traffic flows that have been successfully routed or failed to be routed. These attributes can be defined in the existing notification data model ref Table 5.4.3.3.4-1 of 3GPP TS 29.522 V18.6.0 as follows:Table 1: New attributes added to notification to provide clear outcome of traffic enforcement

[0050] In Table 1, the internal data type Flowinfo and EthFlowDescription are already existing. Addition of trafficFilter information or trafficFilter identifiers in notification model from PCF to NEF will provision PCF to convey the traffic filters which are failed to be routed in the case of traffic influence for future PDU session(s).

[0051] In scenario 1, as depicted in Fig. 5, at step 8a, NEF will be able to provide information regarding negative outcome to AF in the case of traffic influence for an ongoing PDU session. Similarly, in the case of traffic influence for future PDU session(s) failure notification fromPCF carries trafficFilters at step 7a, with this solution, instead of medCompN and fNum which identifies the filter which got failed to be routed will be understandable to NEF only during traffic influence ongoing PDU session will be replaced by trafficFilters or flowld which can be understood by NEF in this case.

[0052] In scenario 2, as depicted in Fig. 6, at step 7a, with this solution, NEF will be able to provide clear information regarding positive outcome to AF in the case of traffic influence for an ongoing PDU session. At step 9a with this solution, NEF will be able to provide information regarding negative outcome to AF in the case of traffic influence for an ongoing PDU session.Similarly, in the case of traffic influence for future PDU session(s) failure notification from PCF carries trafficFilters at step 8a, with this solution, instead of medCompN and fNum, which identifies the filter which got failed to be routed. MedCompN and fNum, attributes will be understandable to NEF only during traffic influence ongoing PDU session and is replaced by trafficFilters or flowld which can be understood by NEF in the case of future pdu session.Solution 2: Single Notification support

[0053] With the solution 1, the notification framework of traffic influence feature has two notifications sent to NEF by different NFs, SMF and PCF. The order of receiving success or failure notification cannot be assumed in NEF as it is coming from two different entities. Even though the notifications correspond to single AF request, NEF cannot consolidate the success and failure together and send to AF as a single notification. Since SMF is the NF that provides the success notification to NEF and failure to PCF, there is no provision in SMF to indicate both success and failure flows to NEF directly, without depending on PCF.

[0054] This can be further optimized by provisioning the user plane path change failure event in SMF. With this, whenever AF request for subscription of user plane path change and failure event of NEF, the NEF subsequently subscribes for the same events in SMF via PCF and get the success and / or failure notification directly from SMF, as depicted in Fig. 7. Fig. 7 depicts the scenario 1, where the success and failure outcome are notified directly to the NEF by the SMF, at step 5a, and subsequent notification from NEF to AF at step 7a. Similarly, in scenario 2, failure outcome will be notified directly to the NEF by the SMF, at step 5a, and subsequent notification from the NEF to the AF, at step 7a.

[0055] With the solution 1, the AF will receive only failure notification in case complete failure in implementing the requested traffic influence and, both success and failure information is notified as separate notification in case of partial success in implementing the requested traffic influence.

[0056] With the solution 2, the event notification is optimized by enhancing NEF to provision AF for subscription for user plane path change failure event in SMF. So that, SMF can directly notify NEF regarding the positive and negative outcome of requested traffic influence in a single notification. Subsequently NEF can notify the same to AF in a single notification.

[0057] By addition of information in notification framework of traffic influence feature to provide clear outcome of traffic influence implementation in 5G core, AF gets clear information of outcome of the requested traffic influence, thus it can take appropriate action based on the notification.

[0058] Fig. 8 illustrates a call flow diagram showing notification of result in enforcement of requested traffic routing requirement in case of ongoing PDU. In step 1, AF provides traffic influence request to NEF. In the JSON payload, there is an attribute named “subscribedEvents” which is defined as an array of datatype enumeration(enum) named as SubscribedEvent. In the enum SubscribedEvent, a new value TRAFF_ROUTE_REQ_OUTCOME is defined to provision subscription to get notification on enforcement outcome. This value is optional.

[0059] Before step 2.1, NEF decides that the request is for PDU identified by UE address, based on the presence of one of the attributes “ipv4Addr”, “ipv6Addr” and “macAddr”. These attributes can be addressed as target UE address. Based on the presence of target UE address, in step 2.1, NEF translates the request to PCF. In the JSON payload of request to PCF, a new attribute “outcomeSub” of a new datatype TraffRouteReqOutcomeEvent is defined. This new attribute should be present if the AF has provided the value TRAFF_ROUTE_REQ_OUTCOME in the request to NEF. The new datatype TraffRouteReqOutcomeEvent has two attributes “notificationUri” and “notifCorreld”. The attribute “notificationUri” is of Uri datatype and “notifCorreld” is of string datatype.

[0060] In step 3, PCF provides corresponding rules in the request to SMF. In the JSON payload of request to SMF, a new attribute “outcomeEvent” of newly defined datatype TraffRouteReqOutcomeEvent (same as previous step 2.1) is defined. This attribute should be present if NEF has provided the attribute “outcomeSub”. After receiving the response fromUPF, for SMF’s request for enforcement via Packet Forwarding Control Protocol (PFCP) Modification Request, step 4 will be triggered.

[0061] In step 4, SMF initiates the notification request to NEF corresponding to the event TRAFF_ROUTE_REQ_OUTCOME. In the JSON payload, there is an attribute named “event” which is defined as an array of datatype enum named as SmfEvent. In the enum SmfEvent a new value TRAFF_ROUTE_REQ_OUTCOME is defined. This value should be present if PCF has provided the attribute “outcomeEvenf Further, in the same payload, a new attribute named “traffRouteReqOutcome” of a new datatype TraffRouteReqOutcome is added. The new datatype TraffRouteReqOutcome has four attributes “succTrafficFlows”, “succEthTrafficFlows”, “failedTrafficFlows” and “failedEthTrafficFlows”. These four attributes are of array datatype. The attribute should be present if the attribute “event” is set to the value TRAFF ROUTE REQ OUTCOME. The attributes “succTrafficFlows” and “failedTrafficFlows” are arrays of datatype FlowDescription and the attribute “succEthTrafficFlows” and “failedEthTrafficFlows” are arrays of datatype EthFlowDescription.

[0062] In step 5, NEF provides the translated notification to AF. In the JSON pay load, there is an attribute named “subscribedEvenf ’ which is defined as an array of datatype enum named as SubscribedEvent. In the enum SubscribedEvent the newly defined value TRAFF_ROUTE_REQ_OUTCOME (same as previous step 1) should be present if the corresponding AF’ s subscription has the value TRAFF ROUTE REQ OUTCOME and SMF has provided the value TRAFF_ROUTE_REQ_OUTCOME in the notification to NEF. Further, in the same payload, a new attribute named “traffRouteReqOutcome” of the newly defined datatype TraffRouteReqOutcome (same as previous step 4) should be present if the attribute “SubscribedEvent” is set to the value TRAFF ROUTE REQ OUTCOME.

[0063] Fig. 9 illustrates a call flow diagram showing notification of result in enforcement of requested traffic routing requirement in case of future PDU(s). In step 1, an AF provides traffic influence request to NEF. In the JSON payload, there is an attribute named “subscribedEvents” which is defined as an array of datatype enumeration (enum) named as SubscribedEvent. In the enum SubscribedEvent a new value TRAFF_ROUTE_REQ_OUTCOME is defined to provision subscription to enforcement outcome. This value is optional.

[0064] Before step 2.2, NEF decides that the request is for PDU(s) not identified by UE address based on the presence of one of the attributes “gpsi”, “externalGroupfd”, “extemalGroupfds” and “anyUelnd”. These attributes can be addressed as target UE identifiers.

[0065] In step 2.2, NEF stores the AF’s request in UDR. In the JSON payload, there is an attribute named “subscribedEvents” which is defined as an array of datatype enum named as SubscribedEvent. In the enum SubscribedEvent, the new value TRAFF_ROUTE_REQ_OUTCOME is defined to provision subscription to get notification on enforcement outcome. This value should be present if the AF has provided the value TRAFF_ROUTE_REQ_OUTCOME. In the same payload, two new attributes “notifUri” and “notifCorreld” are defined. These should be present if the value of SubscribedEvent is set to TRAFF ROUTE REQ OUTCOME. The attribute “notifUri” is of Uri datatype and the attribute “notifCorreld” is of string datatype.

[0066] In step 2.3, UDR notifies the corresponding subscribed PCF or whenever PCF subscribes, with the stored AF’s request. In the JSON payload, there is an attribute named “subscribedEvents” which is defined as an array of datatype enum named as SubscribedEvent. In the enum SubscribedEvent, the newly defined value TRAFF_ROUTE_REQ_OUTCOME is defined. This value should be present if the AF has provided the value TRAFF_ROUTE_REQ_OUTCOME in the request to NEF. In the same payload, two new attributes “notifUri” and “notifCorreld” are defined. These should be present if the value of SubscribedEvent is set to TRAFF_ROUTE_REQ_OUTCOME. The attribute “notificationUri” is of URI datatype and “notifCorreld” is of string datatype.

[0067] In step 3, PCF provides corresponding rules in the request to SMF. In the JSON payload, a new attribute “outcomeEvent” of newly defined datatype TraffRouteReqOutcomeEvent (same as previous step 2.1) is defined. The only difference here is the attribute should be present if the UDR has provided the value TRAFF_ROUTE_REQ_OUTCOME in the request to PCF.

[0068] After receiving the response from UPF, for SMF’s request for enforcement via PFCP Modification Request, step 4 will be triggered. In step 4, SMF initiates the notification request to NEF corresponding to the event TRAFF_ROUTE_REQ_OUTCOME. In the JSON payload, there is an attribute named “event” which is defined as an array of datatype enum named as SmfEvent. In the enum SmfEvent, a new value TRAFF_ROUTE_REQ_OUTCOME isdefined. This value should be present if PCF has provided the attribute “outcom eEvent” in the request from PCF. Further, in the same payload, a new attribute named “traffRouteReqOutcome” of a new datatype TraffRouteReqOutcome is added. The new datatype TraffRouteReqOutcome has four attributes “succTrafficFlows”, “succEthTrafficFlows”, “failedTrafficFlows” and “failedEthTrafficFlows”. These four attributes are of array datatype. The attribute should be present if the attribute “event” is set to the value TRAFF_ROUTE_REQ_OUTCOME. The attributes “succTrafficFlows” and “failedTrafficFlows” are arrays of datatype FlowDescription and the attribute “succEthTrafficFlows” and “failedEthTrafficFlows” are arrays of datatype EthFlowDescription.

[0069] In step 5, NEF provides the translated notification to AF. In the JSON pay load, there is an attribute named “subscribedEvenf ’ which is defined as an array of datatype enum named as SubscribedEvent. In the enum SubscribedEvent, the newly defined value TRAFF_ROUTE_REQ_OUTCOME should be present if the corresponding AF’ s subscription has the value TRAFF_ROUTE_REQ_OUTCOME and SMF has provided the value TRAFF_ROUTE_REQ_OUTCOME in the notification to NEF. In the same payload, a new attribute named “traffRouteReqOutcome” of the newly defined datatype TraffRouteReqOutcome (same as previous step 4) should be present if the attribute “SubscribedEvent” is set to the value TRAFF ROUTE REQ OUTCOME.

[0070] In the above detailed description, reference is made to the accompanying drawings that form a part thereof, and illustrate the best mode presently contemplated for carrying out the invention. However, such description should not be considered as any limitation of scope of the present invention. The structure thus conceived in the present description is susceptible of numerous modifications and variations, all the details may furthermore be replaced with elements having technical equivalence.

Claims

WE CLAIM:

1. A method to indicate an outcome of traffic routing requested by an application function (AF) in a telecommunication network, comprising: receiving, by a network exposure function (NEF), a traffic influence request from an Application Function (AF) including a plurality of first attributes, wherein the plurality of first attributes comprise a target User Equipment (UE) address and a subscription to, installation outcome of requested traffic routing requirements; determining, by the NEF, the traffic influence request comprises a UE address; sending, by the NEF, a first service request including a plurality of second attributes corresponding to the traffic influence request to a Policy Control Function (PCF), wherein the plurality of second attributes comprise the subscription to a traffic routing requirement installation outcome based on the traffic influence request; sending, by the PCF, a second service request including a plurality of third attributes corresponding to the first service request, to a Session Management Function (SMF), wherein the plurality of third attributes comprise subscription to the traffic routing requirement installation outcome based on the first service request; sending, by the SMF, a request to a User Plane Function (UPF) based on the second service request; receiving, by the SMF, a first response from the UPF; determining, by the SMF, the success and failure of a plurality of traffic routing requirements based on the first response from UPF; sending, by the SMF, a first notification including a plurality of fourth attributes corresponding to the second service request, to NEF, wherein the plurality of fourth attributes comprise traffic route requirement installation outcome based on the determination from the first response of UPF; sending, by the NEF, a second notification including a plurality of fifth attributes corresponding to the first notification, to the AF, wherein the plurality of fifth attributescomprise installation outcome of the requested traffic routing requirements based on the first notification; and receiving, by the NEF, a second response including a header from the AF, wherein the header comprises status code to confirm the reception of the second notification.

2. A method to indicate an outcome of traffic routing requested by an AF in a telecommunication network, comprising: receiving, by a NEF, a traffic influence request from an AF including a plurality of first attributes, wherein the plurality of first attributes comprise a plurality of target UE identifier(s) and a subscription to, installation outcome of requested traffic routing requirements; determining, by the NEF, that the traffic influence request comprises at least one UE identifier without UE address; sending, by the NEF, a first service request including plurality of second attributes to a Unified Data Repository (UDR) corresponding to the traffic influence request, wherein the plurality of second attributes comprise subscription to installation outcome of the requested traffic routing requirements based on the traffic influence request; storing, by the UDR, the plurality of second attributes in an application data repository; notifying, by the UDR, a first notification including a plurality of second attributes based on the stored attributes to a PCF subscribed to the application data modification, wherein the plurality of third attributes comprise subscription to installation outcome of the requested traffic routing requirements based on the stored attributes; sending, by the PCF, a second service request including the plurality of third attributes corresponding to the first service request, to a SMF, wherein the plurality of third attributes comprise subscription to a traffic routing requirement installation outcome based on the first service request; sending, by the SMF, a request to a User Plane Function (UPF) based on the second service request; receiving, by the SMF, a first response from the UPF;determining, by the SMF, the success and failure of a plurality of traffic routing requirements based on the first response from the UPF; sending, by the SMF, a second notification including a plurality of fourth attributes corresponding to the second service request, to NEF, wherein the plurality of fourth attributes comprise traffic route requirement installation outcome based on the determination from the first response of UPF; sending, by the NEF, a third notification including a plurality of fifth attributes corresponding to the first notification, to the AF, wherein the plurality of fifth attributes comprise installation outcome of the requested traffic routing requirements to the AF based on the second notification; and receiving, by the NEF, a second response including a header from the AF, wherein the header comprises a status code to confirm the reception of the second notification.

3. A method to indicate an outcome of traffic routing requested by an AF in a telecommunication network, comprising: receiving, by a NEF, a traffic influence request including plurality of first attributes, from an AF, wherein the plurality of first attributes comprise a subscription to installation outcome of requested traffic routing requirements; determining, by the NEF, whether the traffic influence request comprises one of: a UE address and at least one UE identifier without UE address; sending by the NEF, one of: a first service request including a plurality of second attributes to a PCF, when the traffic influence request comprises the UE address, wherein the plurality of second attributes comprise the subscription to traffic routing requirements installation outcome event; and a second service request including a plurality of third attributes to a UDR, when the traffic influence request comprises at least one UE identifier without UE address, wherein the plurality of third attributes comprise the subscription to installation outcomeof the requested traffic routing requirements and information for enabling NEF to receive and identify the notification for the subscription, receiving, by the NEF, a first notification including a plurality of fourth attributes from SMF, wherein the plurality of fourth attributes comprise the installation outcome of the requested traffic routing requirements; determining, by the NEF, the AF subscription for this notification; sending, by the NEF, a second notification including a plurality of fifth attributes to the determined AF, wherein the plurality of fifth attributes comprises the installation outcome of the requested traffic routing requirements; and receiving, by the NEF, a response including a header from the AF, wherein the header comprises status code to confirm the reception of the second notification.

4. The method as claimed in claim 3, wherein the traffic influence request is invoked by the AF, using service API as Nnef_TrafficInfluence_Create.

5. The method as claimed in claim 3, wherein the plurality of first attributes is defined using the data structure TrafficInfluSub.

6. The method as claimed in claim 5, wherein the data structure TrafficInfluSub comprises the attribute subscribedEvents to indicate the events for which the AF subscribes for notification.

7. The method as claimed in claim 3, wherein the UE address is indicated using one of the attributes ipv4Addr, ipv6Addr, and macAddr.

8. The method as claimed in claim 3, wherein the at least one UE identifier without UE addresses is indicated using one of the attributes, extemalGroupId, extemalGroupIds, anyUe- Ind and gpsi.

9. The method as claimed in claim 3, wherein the first service request is invoked using service API Npcf_PolicyAuthorization_Create by one of AF, NEF and Time Sensitive Communication and Time Synchronization Function (TSCTSF).

10. The method as claimed in claim 3, wherein the plurality of second attributes is defined using the data structure AppSessionContext.

11. The method as claimed in claim 10, wherein the data structure AppSessionContext comprises an attribute to indicate the subscription to traffic routing requirements installation outcome event.

12. The method as claimed in claim 11, wherein the attribute to indicate the subscription to traffic routing requirements installation outcome event is outcomeSub of data type TraffRout- eReqOutcomeEvent.

13. The method as claimed in claim 12, wherein the data type TraffRouteReqOutcomeEvent comprise attributes for notification correlation identification (ID) and notification uniform resource identifier (URI), wherein notification URI indicates the method for receiving event notification desired by AF.

14. The method as claimed in claim 3, wherein the second service request for Application Data is invoked by NEF, using a service API as Nudr_DataRepository_Create.

15. The method as claimed in claim 3, wherein the plurality of third attributes is defined using the data structure TrafficInfluData.

16. The method as claimed in claim 15, wherein the data structure TrafficInfluData comprise attributes for notification correlation ID and notification URI, wherein notification URI indicates the method for receiving event notification desired by NEF.

17. The method as claimed in claim 15, wherein the TrafficInfluData comprises the attribute subscribedEvents to indicate the events for which the NEF subscribes for notification.

18. The method as claimed in claim 3, wherein the first notification is invoked by SMF using the service API Nsmf_EventExposure_Notify.

19. The method as claimed in claim 3, wherein the plurality of fourth attributes is defined using the data structure NsmfEventExposureNotification.

20. The method as claimed in claim 19, wherein the data structure NsmfEventExposureNotification comprises the attribute traffRouteReqOutcome to indicate the installation outcome of the requested traffic routing requirements.

21. The method as claimed in claim 20, wherein the attribute traffRouteReqOutcome is of data type TraffRouteReqOutcome.

22. The method as claimed in claim 21, wherein the data type TraffRouteReqOutcome comprises at least one of: plurality of traffic flows which are successfully installed and plurality of traffic flows which are failed to be installed.

23. The method as claimed in claim 19, wherein the data structure NsmfEventExposureNotification comprises an attribute event to indicate the events for which the NEF subscribes for notification.

24. The method as claimed in claim 23, wherein the attribute event is of data type SmfEvent.

25. The method as claimed in claim 24, wherein the SmfEvent is of data type enumeration.

26. The method as claimed in claim 25, wherein the SmfEvent TRAFF_ROUTE_REQ_OUTCOME indicates the subscription installation outcome of the requested traffic routing requirements.

27. The method as claimed in claim 3, wherein the second notification is invoked by NEF using the service API Nnef_TrafficInfluence_Notify.

28. The method as claimed in claim 3, wherein the plurality of fourth attributes is defined using the data structure EventNotification.

29. The method as claimed in claim 27, wherein the data structure EventNotification comprises the attribute traffRouteReqOutcome to indicate the installation outcome of the requested traffic routing requirements.

30. The method as claimed in claim 29, wherein the attribute traffRouteReqOutcome is of data type TraffRouteReqOutcome.

31. The method as claimed in claim 30, wherein the data type TraffRouteReqOutcome comprises at least one of: plurality of traffic flows which are successfully installed and plurality of traffic flows which are failed to be installed.

32. The method as claimed in claim 28, wherein the data structure EventNotification comprises the attribute event to indicate the events for which the AF subscribes for notification.

33. The method as claimed in claim 32, wherein the attribute event is of data type sub- scribedEvent.

34. The method as claimed in claim 3, wherein the status code to confirm the reception of second notification is 204 No Content.

35. A method to indicate an outcome of traffic routing requested by an AF in a telecommunication network, comprising: receiving, by a UDR, a service request including a plurality of attributes from a NEF based on the request from AF, wherein the plurality of attributes comprise a subscription to installation outcome of requested traffic routing requirements, information for enabling NEF to receive the notification and to identify the notification for the subscription; storing, by the UDR, the plurality of attributes in an application data repository; and sending, by the UDR, a notification including the plurality of attributes to the subscribed PCF, based on the presence of a PCF subscription for the application data modifications.

36. The method as claimed in claim 35, wherein the service request for Application Data is invoked by NEF, using a service API as Nudr_DataRepository_Create.

37. The method as claimed in claim 35, wherein the plurality of attributes is defined using the data structure TrafficInfluData.

38. The method as claimed in claim 37, wherein the data structure TrafficInfluData comprise attributes for notification correlation ID and notification URI, wherein notification URI indicates the method for receiving event notification desired by NEF.

39. The method as claimed in claim 37, wherein the data structure TrafficInfluData comprises the attribute subscribedEvents to indicate the events for which the NEF subscribes for notification.

40. The method as claimed in claim 35, wherein the notification for Application Data is invoked by UDR using an API as Nudr_DataRepository_Notify.

41. A method to indicate an outcome of traffic routing requested by an AF in a telecommunication network, comprising: receiving, by a PCF, one of: a first service request including a plurality of first attributes from a network function, wherein the plurality of first attributes comprise a subscription to traffic routing requirement installation outcome event; and a notification including a plurality of second attributes from UDR, wherein the plurality of the second attributes comprise a subscription to installation outcome of the requested traffic routing requirements, information for enabling NEF to receive the notification and to identify the notification for the subscription, obtaining by the PCF, a translated subscription including subscription to traffic routing requirement installation outcome event using one of: subscription to traffic routing requirement installation outcome event from the plurality of first attributes; andsubscription to installation outcome of the requested traffic routing requirements from the plurality of second attributes, and provisioning, by the PCF, a second service request to indicate rules comprising a plurality of third attributes to a SMF, wherein the plurality of third attributes comprise the translated subscription.

42. The method as claimed in claim 41, wherein the first service request is invoked using service API Npcf_PolicyAuthorization_Create by one of AF, NEF, and TSCTSF.

43. The method as claimed in claim 41, wherein the plurality of first attributes is defined using the data structure AppSessionContext.

44. The method as claimed in claim 43, wherein the data structure AppSessionContext comprises the attribute to indicate the subscription to traffic routing requirements installation outcome event.

45. The method as claimed in claim 44, wherein the attribute to indicate the subscription to traffic routing requirements installation outcome event is outcomeSub of data type TraffRout- eReqOutcomeEvent.

46. The method as claimed in claim 45, wherein the data type TraffRouteReqOutcomeEvent comprises attributes for notification correlation ID and notification URI, wherein notification URI indicates the method for receiving event notification desired by one of AF and NEF.

47. The method as claimed in claim 41 , wherein the notification is invoked using service API Nudr_DataRepository_Notify by UDR.

48. The method as claimed in claim 41, wherein the plurality of second attributes is defined using the data structure TrafficInfluData.

49. The method as claimed in claim 48, wherein the data structure TrafficInfluData comprise attributes for notification correlation ID and notification URI, wherein notification URI indicates the method for receiving event notification desired by NEF.

50. The method as claimed in claim 48, wherein the data structure TrafficInfluData comprises the attribute subscribedEvents to indicate the events for which the NEF subscribes for notification.

51. The method as claimed in claim 6, 17, 39 and 50, wherein the attribute subscribedEvents is of data type array of SubscribedEvent.

52. The method as claimed in claim 33 and 51, wherein the SubscribedEvent is of data type enumeration.

53. The method as claimed in claim 51, wherein the SubscribedEvent TRAFF_ROUTE_REQ_OUTCOME indicates the subscription of installation outcome of the requested traffic routing requirements.

54. The method as claimed in claim 41, wherein the second service request is invoked by the PCF, using service API as Npcf_SMPolicyControl_UpdateNotify.

55. The method as claimed in claim 41, wherein the plurality of third attributes is defined using the data structure SmPolicyNotification.

56. The method as claimed in claim 55, wherein the data structure SmPolicyNotification comprises the attribute outcomeEvent to indicate the subscription to traffic routing requirements installation outcome event.

57. The method as claimed in claim 56, wherein the attribute outcomeEvent is of data type TraffRouteReqOutcomeEvent.

58. The method as claimed in claim 57, wherein the data type TraffRouteReqOutcomeEvent comprise attributes for notification correlation ID and notification URI, wherein the notification URI indicates the method for receiving event notification desired by one of: AF and NEF.

59. A method to indicate an outcome of traffic routing requested by an AF in a telecommunication network, comprising: receiving, by a SMF, a service request indicating rules comprising a plurality of first attributes from a PCF, wherein the plurality of first attributes comprise a subscription to traffic routing requirement installation outcome event from a subscribed function; sending, by the SMF, a request to a UPF; receiving, by the SMF, a response from UPF; determining, by the SMF, the traffic route requirement installation outcome based on success and failure of installing a plurality of traffic routing requirements using the response, wherein the traffic route requirement installation outcome comprises at least one of: the plurality of traffic flows whose routing requirements are successfully installed; and the plurality of traffic flows whose routing requirements are failed to install, and sending, by the SMF, a notification including a plurality of second attributes to the subscribed function based on the service request, wherein the plurality of second attributes comprise installation outcome of the requested traffic routing requirements.

60. The method as claimed in claim 59, wherein the service request is invoked by the PCF, using the service API as Npcf_SMPolicyControl_UpdateNotify.

61. The method as claimed in claim 59, wherein the plurality of first attributes is defined using the data structure SmPolicyNotification.

62. The method as claimed in claim 61, wherein the data structure SmPolicyNotification comprises the attribute outcomeEvent to indicate the subscription to traffic routing requirements installation outcome event.

63. The method as claimed in claim 62, wherein the attribute outcomeEvent is of data type TraffRouteReqOutcomeEvent.

64. The method as claimed in claim 63, wherein the data type TraffRouteReqOutcomeEvent comprise attributes for notification correlation ID and notification URI, wherein the notification URI indicates the method for receiving event notification desired by one of: AF and NEF.

65. The method as claimed in claims 13, 16, 38, 46, 49, 58 and 64, wherein the attribute to indicate notification URI is notificationUri of data type Uri.

66. The method as claimed in claims 13, 16, 38, 46, 49, 58 and 64, wherein the attribute to indicate notification correlation ID is notifCorreld of data type string.

67. The method as claimed in claim 59, wherein receiving by the SMF, further comprises, processing the subscription and storing the processed subscription by SMF.

68. The method as claimed in claim 59, wherein the notification is invoked by SMF using service API Nsmf_EventExposure_Notify.

69. The method as claimed in claim 59, wherein the plurality of second attributes is defined using data structure NsmfEventExposureNotification.

70. The method as claimed in claim 69, wherein the data structure NsmfEventExposureNotification comprises the attribute traffRouteReqOutcome to indicate the installation outcome of the requested traffic routing requirements.

71. The method as claimed in claim 70, wherein the attribute traffRouteReqOutcome is of data type TraffRouteReqOutcome.

72. The method as claimed in claim 71, wherein the data type TraffRouteReqOutcome comprises at least one of: plurality of traffic flows which are successfully installed and plurality of traffic flows which are failed to be installed.

73. The method as claimed in claim 22, 31 and 72, wherein the plurality of traffic flows whose routing requirements are successfully installed is indicated by one of: an attribute suc- cTrafficFlows for IP traffic and an attribute succEthTrafficFlows for ethemet traffic.

74. The method as claimed in claims 22, 31 and 72, wherein the plurality of traffic flows whose routing requirements are failed to be installed is indicated by one of: an attribute failedTrafficFlows for IP traffic and an attribute failedEthTraffic Flows for ethemet traffic.

75. The method as claimed in claim 73 and claim 74, wherein the attributes succTrafficFlows and failedTrafficFlows are of data type array of FlowDescription.

76. The method as claimed in claim 73 and claim 74, wherein the attributes succEthTrafficFlows and failedEthTrafficFlows are array of data type EthFlowDescription.

77. The method as claimed in claim 69, wherein the data structure NsmfEventExposureNo- tification comprises the attribute event to indicate the events for which the NEF subscribes for notification.

78. The method as claimed in claim 77, wherein the attribute event is of data type SmfEvent.

79. The method as claimed in claim 78, wherein the SmfEvent is of data type enumeration.

80. The method as claimed in claim 79, wherein the SmfEvent TRAFF_ROUTE_REQ_OUTCOME indicates the subscription installation outcome of the requested traffic routing requirements.

Images