WO2021028435A1 - Mechanism for nef discovery relative to pfd management - Google Patents

Mechanism for nef discovery relative to pfd management Download PDF

Info

Publication number
WO2021028435A1
WO2021028435A1 PCT/EP2020/072510 EP2020072510W WO2021028435A1 WO 2021028435 A1 WO2021028435 A1 WO 2021028435A1 EP 2020072510 W EP2020072510 W EP 2020072510W WO 2021028435 A1 WO2021028435 A1 WO 2021028435A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
nef
pfds
function
identifiers
Prior art date
Application number
PCT/EP2020/072510
Other languages
French (fr)
Inventor
Wenliang Xu
Miguel Angel MUÑOZ DE LA TORRE ALONSO
Antonio CAÑETE MARTINEZ
Jesus-Angel De-Gregorio-Rodriguez
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Priority to EP20754741.5A priority Critical patent/EP3881496A1/en
Publication of WO2021028435A1 publication Critical patent/WO2021028435A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5048—Automatic or semi-automatic definitions, e.g. definition templates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0894—Policy-based network configuration management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/20—Services signaling; Auxiliary data signalling, i.e. transmitting data via a non-traffic channel

Definitions

  • the present disclosure relates to Packet Flow Description (PFD) management in a core network of a wireless communication system (e.g., a Fifth Generation (5G) system).
  • a wireless communication system e.g., a Fifth Generation (5G) system.
  • 5G Fifth Generation
  • PFDs Packet Flow Descriptions
  • the Management of Packet Flow Descriptions enables the UPF to perform accurate application detection when PFD(s) are provided by an ASP and then to apply enforcement actions as instructed in the PCC Rule.
  • the operator is able to configure pre-defined PCC Rules in the SMF or dynamic PCC Rules in the PCF that include at least an application identifier for service data flow detection, charging control information, i.e. charging key and optionally the Sponsor identifier or the ASP identifier or both.
  • charging control information i.e. charging key
  • the ASP may provide individual PFDs or the full set of PFDs for each application identifier maintained by the ASP to the SMF via the PFD Management service in the NEF (PFDF).
  • the PFDs become part of the application detection filters in the SMF/UPF and therefore are used as part of the logic to detect traffic generated by an application.
  • the ASP may remove or modify some or all of the PFDs which have been provided previously for one or more application identifiers.
  • the SMF may report the application stop to the PCF for a application instance identifier as defined in clause 5.8.2.8.4 of TS 23.501 [2] if the removed/modified PFD in SMF/UPF results in that the stop of the application instance is not being able to be detected.
  • the ASP manages (provision, update, delete) the PFDs through the NEF (PFDF).
  • the PFD(s) are transferred to the SMF through the NEF (PFDF).
  • the PFDF is a logical functionality in the NEF which receives PFD(s) from the ASP through the NEF, stores the PFD(s) in the UDR and provides the PFD(s) to the SMF(s) either on the request from ASP PFD management through NEF (PFDF) (push mode) or on the request from SMF (pull mode).
  • the PFDF functionality is a service provided by the NEF.
  • the PFDs may be retrieved by SMF from NEF (PFDF) in "pull” mode or may be provisioned from NEF (PFDF) to the SMF in "push” mode.
  • PFDF NEF
  • the SMF requests all PFDs for that application identifier from the NEF (PFDF), and NEF (PFDF) retrieves them from the UDR.
  • PFDF NEF
  • the PFD(s) retrieved for an application identifier from the NEF (PFDF) are cached in the SMF, and the SMF maintains a caching timer associated to the PFD(s) to control how long the PFD(s) are valid.
  • the SMF reloads the PFD(s) from the NEF (PFDF) and provides it to the UPF over N4; - If there's no active PCC rule that refers to the corresponding application identifier or the SMF removes the last PCC rule that refers to the corresponding application identifier, the SMF removes the PFD(s) identified by the application identifier and informs the UPF to remove the PFD(s) identified by the application identifier over N4.
  • PFDF NEF
  • the UPF When the UPF receives the updated PFD(s) from either the same or different SMF for the same application identifier, the latest received PFD(s) shall overwrite any existing PFD(s) stored in the UPF.
  • the SMF shall manage the pre-configured PFDs and PFDs provided by the NEF (PFDF) at the UPF as defined in clause 5.8.2.8.4 of TS 23.501 [2]
  • the SMF may differentiate the need for PFD retrieval based on operator configuration in the SMF.
  • the SMF may retrieve PFDs for one or more application identifiers in the same Request. All PFDs related to an application identifier are provided in the response from the UDR to NEF (PFDF).
  • PFDF UDR to NEF
  • the SMF shall invoke
  • Nnef_PFDmanagement_Fetch service operation by sending an HTTP GET request message to the resource "Individual application PFD".
  • the SMF In order to retrieve the PFDs of all application identifiers, the SMF shall invoke the Nnef_PFDmanagement_Fetch service operation by sending an HTTP GET request message to the resource "PFD of applications".
  • the SMF In order to retrieve the PFDs of collection of application identifiers, the SMF shall invoke the Nnef_PFDmanagement_Fetch service operation by sending an HTTP GET request message to the resource "PFD of applications" with query parameters indicating the requested application identifiers.
  • Nnef_PFDmanagement_Fetch service operation refers to 3GPP TS 29.551 [25], 2. If the requested PFDs are not available in PFDF, PFDF shall invoke Nudr_DataRepository_Query service operation by sending an FHTTP GET request message to the UDR to the resource "Individual PFD Data" as specified in 3GPP TS 29.519 [12],
  • the SMF in step 1 can include PFD management request for multiple applications, but the UDR service for PFD management only supports one application at a time.
  • the UDR shall send an HTTP GET response message including the requested PFDs to the NEF.
  • the NEF sends the HTTP GET response message "200 OK" including the PFDs for the requested application identifier(s) to the SMF.
  • This procedure enables the SMF to subscribe the notification of events when the PFDs for application identifier change.
  • the PFDF will notify the SMF to update and/or delete the PFDs for application identifier(s) as subscribed previously.
  • the SMF can use Nnef_PFDmanagement_Subscribe service operation by sending an HTTP POST message to the resource "PFD subscriptions".
  • the HTTP POST request includes a notification URI to indicate to the PFDF where to send notifications when events occur. If the subscription is accepted, he PFDF shall send the POST response message a "201 Created" to the SMF.
  • the PFDF shall use Nnef_PFDmanagement_Notify service operation to update and/or delete the PFDs for application identifier(s) in the SMF.
  • the PFDF shall send an HTTP POST request message to the notification URI " ⁇ notifyUri ⁇ /notify”.
  • the SMF replies to the PFDF with an HTTP POST response message "204 No Content” indicating the successful provisioning of all PFDs or "200 OK" containing failed application identifier(s).
  • the SMF may initiate Nnef_PFDmanagement_Unsubscribe service operation to remove the subscription by sending an HTTP DELETE request message to the resource "Individual PFD subscription".
  • the PFDF replies to the SMF with an HTTP DELETE response message "204 No Content”.
  • NEF Network Exposure Function
  • PFDF Packet Flow Description Function
  • 5GC for interaction between Application Function (AF), NEF, and User Data Repository (UDR), see Section 4.18 of 3GPP TS
  • Figure 5 is a combination of the flows in Section 4.18 of 3GPP TS 23.502 V16.1.0.
  • Figure 5 illustrates a procedure for PFD management via NEF (PFDF).
  • Steps 1-5 and 8 in Figure 5 correspond to steps 1-6 in Figure 4.18.2-1 of 3GPP TS 23.502 V16.1.0.
  • the following is an excerpt from 3GPP TS 23.502 V16.1.0 describing steps 1-6 of Figure 4.18.2-1 (which again correspond to steps 1-5 and 8 of Figure 5): 1.
  • the AF invokes the Nnef_PFDManagement_Create/Update/Delete service.
  • the Allowed Delay is an optional parameter.
  • Allowed Delay indicates that the list of PFDs in this request should be provisioned within the time interval indicated by the Allowed Delay to the SMF(s) that have subscribed to the PFD management service using Nnef_PFDManagement_Subscribe service operation.
  • NEF checks whether the Application is authorized to perform this request based on the operator policies.
  • the NEF invokes the Nudr_DM_Create/Update/Delete (Application Identifier, one or more sets of PFDs, Allowed Delay) to the UDR.
  • the UDR updates the list of PFDs for the Application Identifier.
  • the UDR sends a Nudr_DM_Create/Update/Delete Response to the NEF (PFDF).
  • the NEF sends Nnef_PFDManagement_Create/Update/Delete Response to the Application Function.
  • Step 6a The NEF (PFDF) sends an Nnef_PFDManagement_Notify request to the Session Management Function (SMF) including PFD(s).
  • SMF Session Management Function
  • Step 7a The SMF returns an Nnef_PFDManagement_Notify response to the NEF (PFDF).
  • Step 6b.1 The SMF invokes the Nnef_PFDManagement_Fetch (application identifier(s)) to the NEF (PFDF).
  • Step 6b.2 The NEF (PFDF) checks if the PFDs for the application identifier(s) are available in the NEF (PFDF). If available, the NEF (PFDF) skips to step 4. If not, the NEF (PFDF) invokes Nudr_DM_Query (application identifiers)) to retrieve the PFD(s) from the UDR.
  • Nudr_DM_Query application identifiers
  • Step 6b.3 The UDR provides an Nudr_DM_Query response (application identifier(s), PFD(s)) to the NEF (PFDF).
  • Step 7b The NEF (PFDF) replies to the SMF with Nnef_PFDManagement_Fetch (application identifier(s), PFD(s)).
  • NF service consumer in this clause refers to the consumer of the NRF services and should not be confused with the role of the NF (consumer or producer).
  • Figure 4.17.1-1 NF Service Registration procedure 1.
  • NF service consumer i. e. an NF instance sends Nnrf_NFManagement_NFRegister Request message to NRF to inform the NRF of its NF profile when the NF service consumer becomes operative for the first time. See clause 5.2.7.2.2 for relevant NF profile parameters
  • NF service consumer's NF profile is configured by OAM system.
  • the NRF stores the NF profile of NF service consumer and marks the NF service consumer available.
  • the NRF acknowledge NF Registration is accepted via Nnrf_NFManagement_NFRegister response. .4 NF/NF service discovery by NF service consumer in the same PLMN
  • the NF service consumer intends to discover services available in the network based on service name and target NF type.
  • the NF service consumer invokes Nnrf_NFDiscovery_Request (Expected NF service Name, NF Type of the expected NF instance, NF type of the NF consumer) from an appropriate configured NRF in the same PLMN.
  • the parameter may include optionally producer NF Set ID, NF Service Set ID, SUPI, Data Set Identifier(s),
  • the parameters may include AMF Region ID, AMF Set ID, TAI.
  • the NF service consumer may indicate a preference for target NF location in the Nnrf_NFDiscovery_Request. A complete list of parameters is provided in service definition in clause 5.27.3.2.
  • the NF service consumer indicates its NF location for preference for target NF location.
  • the NRF authorizes the Nnrf_NFDiscovery_Request. Based on the profile of the expected NF/NF service and the type of the NF service consumer, the NRF determines whether the NF service consumer is allowed to discover the expected NF instance(s). If the expected NF instance(s) or NF service instance(s) are deployed in a certain network slice, NRF authorizes the discovery request according to the discovery configuration of the Network Slice, e.g. the expected NF instance(s) are only discoverable by the NF in the same network slice.
  • the NRF determines a set of NF instance(s) matching the Nnrf_NFDiscovery_Request and internal policies of the NRF and sends the NF profile(s) of the determined NF instances.
  • Each NF profile containing at least the output required parameters (see clause 5.27.3.2) to the NF service consumer via Nnrf_NFDiscovery_Request Response message
  • the NRF shall provide the corresponding UDR, UDM or AUSF instance(s) that matches the optional input SUPI. Otherwise, if SUPI is not provided in the request, the NRF shall return all applicable UDR instance(s) (e.g. based on the Data Set Id, NF type), UDM instance(s) or AUSF instance(s) (e.g. based on NF type) and if applicable, the information of the range of SUPI(s) and/or Data Set Id each UDR instance is supporting.
  • UDR instance(s) e.g. based on the Data Set Id, NF type
  • UDM instance(s) or AUSF instance(s) e.g. based on NF type
  • the NRF shall provide the corresponding CHF instance(s) that matches the optional input SUPI, GPSI or PLMN ID.
  • the NRF shall provide the primary CHF instance and the secondary CHF instance pair(s) together. Otherwise, if neither SUPI/PLMN ID nor GPSI is provided in the request, the NRF shall return all applicable CHF instance(s) and if applicable, the information of the range of SUPI(s), GPSI(s) or PLMN ID(s).
  • the NRF shall not limit the set of discovered NF instances or NF service instance(s) to the target NF location, e.g. the NRF may provide NF instance(s) or NF service instance(s) for which location is not the preferred target NF location if no NF instance or NF service instance could be found for the preferred target NF location.
  • the Network Exposure Function (NEF) providing the Nnef_PFDManagement service registers itself in the Network Repository Function (NRF), and the current Release 15 function can support the Packet Flow Description (PFD) management function in Fifth Generation Core (5GC) with the prerequisite that all NEFs in a Public Land Mobile Network (PLMN) provide homogenous support for the Nnef_PFDManagement (both southbound and northbound) service.
  • PLMN Public Land Mobile Network
  • SMF Session Management Function
  • the SMF broadcasts the Nnef_PFDManagement service to all of them.
  • FIG. 6 shows the interactions in a "pull mode.”
  • the fetch request / subscribe request is broadcast to all NEFs. Since the provisioning NEF is one of those NEFs, it will provide the PFD to the SMF in the “pull mode” or be aware of the PFD change so to “push” the change to the SMF. Flowever, the consequence is the signaling increase and unnecessary processing in the network (e.g., four NEFs and five User Data Repositories (UDRs) lead to 20 PFD retrievals).
  • UDRs User Data Repositories
  • provisioning NEF multiple NEFs may be deployed in a PLMN and all these NEFs may provide the Nnef_PFDManagement service.
  • the provisioning NEF is the one among these NEFs that is responsible for PFD management of certain application(s). Those applications may be interested by a SMF regarding the PFD management.
  • a provisioning NEF that receives PFDs updates its Network Function (NF) profile with the corresponding PFD application Identifiers (IDs) and/or Application Function (AF) IDs, so the SMF can discover the correct provisioning NEF.
  • NF Network Function
  • IDs PFD application Identifiers
  • AF Application Function
  • a Neflnfo data type including one or more PFD application IDs and/or AF IDs.
  • the Neflnfo data type will be used in an Nnrf_NFDiscovery Application Program Interface (API) and an Nnrf_NFManagement API.
  • API Nnrf_NFDiscovery Application Program Interface
  • Nnrf_NFManagement API Nnrf_NFManagement API
  • NRF services i.e. TS 29.510
  • Nnrf_NFManagement API Support the NEF to update its NEFProfile including a list of PFD application IDs and/or AF IDs.
  • Nnrf_NFDiscovery API Support a consumer (e.g., an SMF) to discover the NEF (relative to the PFD management service) by including, as query parameters, one or more PFD application IDs and/or AF IDs.
  • Embodiments disclosed herein provide a solution to the aforementioned issue to support NEF discovery (relative to PFD management) via an NRF.
  • NEF discovery relative to PFD management
  • application IDs there is no need to provision the AF IDs for the application IDs in the SMF. It is well suited for the pull mode, where the SMF only knows the application IDs from the Policy and Charging Control (PCC) rule.
  • PCC Policy and Charging Control
  • Figure 1 is a reproduction of Figure 5.5.2.2.1-1 of Third Generation Partnership Project (3GPP) Technical Specification (TS) 29.513 V16.0.0, which illustrates a procedure for Packet Flow Description (PFD) retrieval by a Session Management Function (SMF);
  • 3GPP Third Generation Partnership Project
  • TS Technical Specification
  • PFD Packet Flow Description
  • SMF Session Management Function
  • Figure 2 is a reproduction of Figure 5.5.2.2.2-1 of 3GPP TS 29.513 V16.0.0, which illustrates a procedure for PFD Function (PFDF) management in an SMF;
  • PFDF PFD Function
  • Figure 3 is a reproduction of Figure 4.17.1-1 of 3GPP TS 23.502, which illustrates a procedure for Network Function (NF) service registration;
  • NF Network Function
  • FIG 4 is a reproduction of Figure 4.17.4-1 of 3GPP TS 23.502, which illustrates a procedure for NF/NF service discovery in the same Public Land Mobile Network (PLMN);
  • PLMN Public Land Mobile Network
  • FIG. 5 PFD management via Network Exposure Function (NEF) (Packet Flow Description Function (PFDF)) in 5GC (for interaction between Application Function (AF), NEF, and User Data Repository (UDR);
  • NEF Network Exposure Function
  • PFDF Packet Flow Description Function
  • 5GC for interaction between Application Function (AF), NEF, and User Data Repository (UDR);
  • AF Application Function
  • UDR User Data Repository
  • Figure 6 shows interactions in a “pull mode”
  • Figure 7 illustrates one example of a cellular communications network in which embodiments of the present disclosure may be implemented
  • Figure 8 illustrates a wireless communication system represented as a Fifth Generation (5G) network architecture composed of core NFs, where interaction between any two NFs is represented by a point-to-point reference point/interface;
  • 5G Fifth Generation
  • Figure 9 illustrates a 5G network architecture using service-based interfaces between the NFs in the control plane, instead of the point-to-point reference points/interfaces used in the 5G network architecture of Figure 8;
  • FIGS 10A through 10D illustrate a sequence diagram for an example of Application Service Provider (ASP) (Application Function (AF)) provisioning PFDs for a certain set of applications and SMF using the pull procedure to retrieve the PFDs using NEF discovery through a Network Repository Function (NRF) in accordance with some embodiments of the present disclosure;
  • ASP Application Service Provider
  • AF Application Function
  • NEF Network Repository Function
  • Figure 11 is a schematic block diagram of a network node implementing a core network entity (e.g., a core network function) according to some embodiments of the present disclosure
  • Figure 12 is a schematic block diagram that illustrates a virtualized embodiment of the network node of Figure 11 according to some embodiments of the present disclosure.
  • Figure 13 is a schematic block diagram of the network node of Figure 11 according to some other embodiments of the present disclosure.
  • Radio Node As used herein, a “radio node” is either a radio access node or a wireless device.
  • Radio Access Node As used herein, a “radio access node” or “radio network node” is any node in a radio access network of a cellular communications network that operates to wirelessly transmit and/or receive signals.
  • a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a home eNB, or the like), and a relay node.
  • a base station e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a
  • Core Network Node is any type of node in a core network or any node that implements a core network function.
  • Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), a Flome Subscriber Server (HSS), or the like.
  • MME Mobility Management Entity
  • P-GW Packet Data Network Gateway
  • SCEF Service Capability Exposure Function
  • HSS Flome Subscriber Server
  • a core network node examples include a node implementing a Access and Mobility Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Network Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.
  • AMF Access and Mobility Function
  • UPF User Plane Function
  • SMF Session Management Function
  • AUSF Authentication Server Function
  • NSSF Network Slice Selection Function
  • NEF Network Exposure Function
  • NEF Network Exposure Function
  • NF Network Function
  • PCF Policy Control Function
  • UDM Unified Data Management
  • Wireless Device is any type of device that has access to (i.e., is served by) a cellular communications network by wirelessly transmitting and/or receiving signals to a radio access node(s).
  • a wireless device include, but are not limited to, a User Equipment device (UE) in a 3GPP network and a Machine Type Communication (MTC) device.
  • UE User Equipment device
  • MTC Machine Type Communication
  • Network Node As used herein, a “network node” is any node that is either part of the radio access network or the core network of a cellular communications network/system.
  • a provisioning NEF that receives PFDs updates its NF profile with the corresponding PFD application Identifiers (IDs) and/or Application Function (AF) IDs, so the SMF can discover the correct provisioning NEF.
  • IDs PFD application Identifiers
  • AF Application Function
  • TS 3GPP Technical Specification
  • a Neflnfo data type including one or more PFD application IDs and/or AF IDs.
  • the Neflnfo data type will be used in an Nnrf_NFDiscovery Application Program Interface (API) and an Nnrf_NFManagement API.
  • API Nnrf_NFDiscovery Application Program Interface
  • Nnrf_NFManagement API Nnrf_NFManagement API
  • FIG. 7 illustrates one example of a cellular communications system 700 in which embodiments of the present disclosure may be implemented.
  • the cellular communications system 700 is a 5G System (5GS) including a NR Radio Access Network (RAN).
  • the RAN includes base stations 702-1 and 702-2, which in 5G NR are referred to as gNBs, controlling corresponding (macro) cells 704-1 and 704-2.
  • the base stations 702-1 and 702-2 are generally referred to herein collectively as base stations 702 and individually as base station 702.
  • the (macro) cells 704-1 and 704-2 are generally referred to herein collectively as (macro) cells 704 and individually as (macro) cell 704.
  • the RAN may also include a number of low power nodes 706-1 through 706-4 controlling corresponding small cells 708-1 through 708-4.
  • the low power nodes 706-1 through 706-4 can be small base stations (such as pico or femto base stations) or Remote Radio Heads (RRHs), or the like.
  • RRHs Remote Radio Heads
  • one or more of the small cells 708-1 through 708-4 may alternatively be provided by the base stations 702.
  • the low power nodes 706-1 through 706-4 are generally referred to herein collectively as low power nodes 706 and individually as low power node 706.
  • the small cells 708-1 through 708-4 are generally referred to herein collectively as small cells 708 and individually as small cell 708.
  • the cellular communications system 700 also includes a core network 710, which in the 5GS is referred to as the 5G Core (5GC).
  • the base stations 702 (and optionally the low power nodes 706) are connected to the core network 710.
  • the base stations 702 and the low power nodes 706 provide service to wireless devices 712-1 through 712- 5 in the corresponding cells 704 and 708.
  • the wireless devices 712-1 through 712-5 are generally referred to herein collectively as wireless devices 712 and individually as wireless device 712.
  • the wireless devices 712 are also sometimes referred to herein as UEs.
  • Figure 8 illustrates a wireless communication system represented as a 5G network architecture composed of core NFs, where interaction between any two NFs is represented by a point-to-point reference point/interface.
  • Figure 8 can be viewed as one particular implementation of the system 700 of Figure 7.
  • the 5G network architecture shown in Figure 8 comprises a plurality of UEs connected to either a RAN or an Access Network (AN) as well as an AMF.
  • the R(AN) comprises base stations, e.g. such as eNBs or gNBs or similar.
  • the 5GC NFs shown in Figure 8 include a NSSF, an AUSF, a UDM, an AMF, a SMF, a PCF, and an AF.
  • the N1 reference point is defined to carry signaling between the UE and AMF.
  • the reference points for connecting between the AN and AMF and between the AN and UPF are defined as N2 and N3, respectively.
  • N4 is used by the SMF and UPF so that the UPF can be set using the control signal generated by the SMF, and the UPF can report its state to the SMF.
  • N9 is the reference point for the connection between different UPFs
  • N14 is the reference point connecting between different AMFs, respectively.
  • N15 and N7 are defined since the PCF applies policy to the AMF and SMP, respectively.
  • N12 is required for the AMF to perform authentication of the UE.
  • N8 and N10 are defined because the subscription data of the UE is required for the AMF and SMF.
  • the 5GC network aims at separating user plane and control plane.
  • the user plane carries user traffic while the control plane carries signaling in the network.
  • the UPF is in the user plane and all other NFs, i.e., the AMF, SMF, PCF, AF, AUSF, and UDM, are in the control plane. Separating the user and control planes guarantees each plane resource to be scaled independently. It also allows UPFs to be deployed separately from control plane functions in a distributed fashion. In this architecture, UPFs may be deployed very close to UEs to shorten the Round Trip Time (RTT) between UEs and data network for some applications requiring low latency.
  • RTT Round Trip Time
  • the core 5G network architecture is composed of modularized functions.
  • the AMF and SMF are independent functions in the control plane. Separated AMF and SMF allow independent evolution and scaling.
  • Other control plane functions like the PCF and AUSF can be separated as shown in Figure 8.
  • Modularized function design enables the 5GC network to support various services flexibly.
  • Each NF interacts with another NF directly. It is possible to use intermediate functions to route messages from one NF to another NF.
  • a set of interactions between two NFs is defined as service so that its reuse is possible. This service enables support for modularity.
  • the user plane supports interactions such as forwarding operations between different UPFs.
  • Figure 9 illustrates a 5G network architecture using service-based interfaces between the NFs in the control plane, instead of the point-to-point reference points/interfaces used in the 5G network architecture of Figure 8.
  • the NFs described above with reference to Figure 8 correspond to the NFs shown in Figure 9.
  • the service(s) etc. that a NF provides to other authorized NFs can be exposed to the authorized NFs through the service-based interface.
  • the service based interfaces are indicated by the letter “N” followed by the name of the NF, e.g. Namf for the service based interface of the AMF and Nsmf for the service based interface of the SMF etc.
  • the NEF and the NRF in Figure 9 are not shown in Figure 8 discussed above. However, it should be clarified that all NFs depicted in Figure 8 can interact with the NEF and the NRF of Figure 9 as necessary, though not explicitly indicated in Figure 8.
  • the AMF provides UE-based authentication, authorization, mobility management, etc.
  • a UE even using multiple access technologies is basically connected to a single AMF because the AMF is independent of the access technologies.
  • the SMF is responsible for session management and allocates Internet Protocol (IP) addresses to UEs. It also selects and controls the UPF for data transfer. If a UE has multiple sessions, different SMFs may be allocated to each session to manage them individually and possibly provide different functionalities per session.
  • IP Internet Protocol
  • the AF provides information on the packet flow to the PCF responsible for policy control in order to support Quality of Service (QoS).
  • QoS Quality of Service
  • the PCF determines policies about mobility and session management to make the AMF and SMF operate properly.
  • the AUSF supports authentication function for UEs or similar and thus stores data for authentication of UEs or similar while the UDM stores subscription data of the UE.
  • the Data Network (DN) not part of the 5GC network, provides Internet access or operator services and similar.
  • An NF may be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., a cloud infrastructure.
  • the proposed solution allows support for NEF discovery (relative to PFD management) via NRF by defining a Neflnfo data type that will be used in an Nnrf_NFDiscovery API and an Nnrf_NFManagement API.
  • FIGs 10A through 10D illustrate a sequence diagram for an example of Application Service Provider (ASP) (AF) provisioning PFDs for a certain set of applications and SMF using the pull procedure to retrieve the PFDs using NEF discovery through NRF in accordance with some embodiments of the present disclosure.
  • ASP Application Service Provider
  • the steps of Figures 10A through 10D are detailed below: [0049] Steps 1000 and 1002: ASP (AF), e.g. Google Inc., decides to trigger an Nnef procedure towards an NEF (referred to herein as the provisioning NEF) in order to provision PFDs for a certain set of applications (e.g., YouTube and Gmail in this example).
  • ASP Application Service Provider
  • HTTP Hypertext Transfer Protocol
  • Step 1004 The NEF acknowledges the request with, in this example, an Nnef 200 OK message.
  • Steps 1006, 1008, and 1010 The NEF maps the externalApplds to (internal) applds and sends a request to a User Data Repository (UDR) to store the PFDs for the application (s) (the one(s) received in step 1002 above).
  • the UDR stores the PFDs for the application(s).
  • Steps 1012 and 1014 The NEF updates its NFProfile based on the provisioned information.
  • the NEF communicates with the NRF to update its NFProfile to include a list of application IDs (e.g., appIDs) of the provisioned PFDs and/or a list of application function IDs (e.g., aflds) of the provisioned PFDs.
  • the NEF triggers an Nnrf_NFManagement Request towards NRF with the NFprofile including the new Neflnfo as proposed in tables below.
  • the data structures below are only examples. The name of the data structure as well as the contents of the data structure may vary depending on, e.g., the particular implementation. 6.1.6.2.x Type: Neflnfo
  • Table 6.1.6.2.y-1 Definition of type PfdData
  • Steps 1016 and 1018 The NRF stores the NFProfile including the above information and acknowledges the request in 1014 with an Nnrf_NFManagement Response message.
  • Steps 1020 and 1022 At some point, a UE triggers PDU session establishment by means of sending a PDU Session Establishment Request to an AMF.
  • the AMF selects an SMF to manage the PDU session (the SMF selection function in the AMF selects an SMF instance based on the available SMF instances obtained from NRF or based on the configured SMF information in the AMF) and triggers Nsmf PDU Session Create. Note the sequence diagram in Figures 10A through 10D does not include all the signaling messages involved in the PDU Session Establishment procedure.
  • Step 1024 The SMF triggers an Npcf_SMPolicyControl_Create Request message to the PCF in order to retrieve Session Management (SM) policies for the user PDU session.
  • SM Session Management
  • Step 1026 The PCF triggers an Nudr_Query Request message to the UDR in order to retrieve the policy data for this user PDU session.
  • Step 1028 The UDR answers with an Nudr_Query Response message including the Subscriber Policy Data.
  • Step 1030 The PCF generates the corresponding Policy and Charging Control (PCC) rule(s) based on the Subscriber Policy Data.
  • PCC Policy and Charging Control
  • Step 1032 Based on the above, the PCF triggers an Npcf_SMPolicyControl_Create Response message including the PCC rules to be applied for this user PDU session.
  • the PCF triggers an Npcf_SMPolicyControl_Create Response message including the PCC rules to be applied for this user PDU session.
  • the PCC rule for the YouTube application including some enforcement actions (e.g., charging and QoS).
  • the SMF identifies the NEF that manages the PFDs for the YouTube application.
  • the SMF triggers the NEF discovery procedure (through the NRF) by sending an Nnrf_NFDiscovery Request message towards the NRF including the application ID or the application function ID associated with the desired application for the user PDU session, which in this example is the YouTube application or the Google Inc. application function.
  • the SMF preferably includes information that indicates the desired NF type (which in this case is the NEF type) and information that indicates the desired NF service type (which in this case is PFD management).
  • the consumer (SMF) is allowed to filter by appld and/or by afld. In case afld is used, the SMF would be pre-provisioned accordingly as afld is not conveyed in the PCC rule.
  • the Nnrf_NFDiscovery Request towards the NRF triggered by the SMF includes a new query parameter pfd-data as proposed in tables below.
  • the name of the new query parameter as well as the data structures below are only examples and may vary depending on, e.g., the particular implementation. 6.2.3.2.3.1 GET
  • This operation retrieves a list of NF Instances, and their offered services, currently registered in the NRF, satisfying a number of filter criteria, such as those NF Instances offering a certain service name, or those NF Instances of a given NF type (e.g., AMF) Table 6.2.3.2.3.1-1: URI query parameters supported by the GET method on this resource
  • Steps 1036 and 1038 The NRF selects an NEF instance matching the requested information, i.e. an NEF which supports the PFD management service and which manages the PFDs for the requested application (e.g., YouTube in this example) and/or ASP (e.g., Google Inc. in this example).
  • the NRF responds back to the SMF with an Nnrf_NFDiscovery Response message including the selected NEF instance ID.
  • Steps 1044 and 1046 The UDR retrieves the stored PFDs for the selected application and answers with an Nudr_Query Response message including the requested PFDs.
  • Steps 1050 and 1052 The SMF selects a UPF and triggers a Packet Forwarding Control Protocol (PFCP)
  • PFCP Packet Forwarding Control Protocol
  • the UPF answers the SMF with a PFCP PFD Management Response message.
  • Step 1054 The SMF triggers PFCP Session Establishment Request message including the corresponding Packet Detection Rules (PDRs), Forwarding Action Rules (FARs), QoS Enforcement Rules (QERs), and/or Usage Report Rules (URRs).
  • PDRs Packet Detection Rules
  • FARs Forwarding Action Rules
  • QERs QoS Enforcement Rules
  • URRs Usage Report Rules
  • PDRs Packet Detection Rules
  • FARs Forwarding Action Rules
  • QERs QoS Enforcement Rules
  • URRs Usage Report Rules
  • Step 1056 The UPF stores the PDRs, FARs, QERs, and/or URRs and answers back to the SMF with a PFCP Session Establishment Response message.
  • Steps 1058, 1060, 1062, and 1064 At the UE, the user starts an application (e.g., YouTube). The UPF detects YouTube application traffic based on the PDR information indicated above. If there is a match, packets are classified as YouTube and the UPF applies the corresponding enforcement actions (FAR, QER, URR).
  • an application e.g., YouTube
  • the UPF detects YouTube application traffic based on the PDR information indicated above. If there is a match, packets are classified as YouTube and the UPF applies the corresponding enforcement actions (FAR, QER, URR).
  • the process of Figures 10A through 10D are for the pull mode.
  • the Nnef_PFDManagement_Subscribe service operation can be triggered by the SMF based on the result of the NRF query by the appld and/or afld. This service operation can be triggered by the SMF at any time (e.g., at start/restart, or at reception of the PCC rule at step 1032 in Figure 10B).
  • an Nnef_PFDManagement_Notifiy service operation is sent from the NEF to the SMF, and the SMF is responsible to deploy the received PFD data (as depicted in steps 1050 and 1052 in Figure 10D).
  • FIG 11 is a schematic block diagram of a core network node 1100 according to some embodiments of the present disclosure.
  • the core network node 1100 is a network node implementation a core network entity or a core network NF such as, e.g., an AMF, a UPF, an SMF, a PCF, an NRF, a UDR, or an NEF (e.g., such as those shown in Figures 10A through 10D and described above).
  • the core network node 1100 includes one or more processors 1104 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory 1106, and a network interface 1108.
  • processors 1104 e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like
  • memory 1106 e.g., RAM, RAM, RAM,
  • the one or more processors 1104 are also referred to herein as processing circuitry.
  • the one or more processors 1104 operate to provide one or more functions of a core network node 1100 as described herein (e.g., one or more functions of an AMF, a UPF, an SMF, a PCF, an NRF, a UDR, or an NEF as described above, e.g., with respect to Figures 10A through 10D).
  • the function(s) are implemented in software that is stored, e.g., in the memory 1106 and executed by the one or more processors 1104.
  • FIG. 12 is a schematic block diagram that illustrates a virtualized embodiment of the core network node 1100 according to some embodiments of the present disclosure.
  • a “virtualized” core network node is an implementation of the core network node 1100 in which at least a portion of the functionality of the core network node 1100 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)).
  • the core network node 1100 includes one or more processing nodes 1200 coupled to or included as part of a network(s) 1202.
  • Each processing node 1200 includes one or more processors 1204 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 1206, and a network interface 1208.
  • processors 1204 e.g., CPUs, ASICs, FPGAs, and/or the like
  • functions 1210 of the core network node 1100 described herein e.g., one or more functions of an AMF, a UPF, an SMF, a PCF, an NRF, a UDR, or an NEF as described above, e.g., with respect to Figures 10A through 10D
  • functions 1210 of the core network node 1100 described herein are implemented at the one or more processing nodes 1200 or distributed across two or more of the processing nodes 1200 in any desired manner.
  • some or all of the functions 1210 of the core network node 1100 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 1200.
  • a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the core network node 1100 or a node (e.g., a processing node 1200) implementing one or more of the functions 1210 of the core network node 1100 in a virtual environment according to any of the embodiments described herein (e.g., one or more functions of an AMF, a UPF, an SMF, a PCF, an NRF, a UDR, or an NEF as described above, e.g., with respect to Figures 10A through 10D) is provided.
  • a carrier comprising the aforementioned computer program product is provided.
  • the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).
  • FIG. 13 is a schematic block diagram of the core network node 1100 according to some other embodiments of the present disclosure.
  • the core network node 1100 includes one or more modules 1300, each of which is implemented in software.
  • the module(s) 1300 provide the functionality of the core network node 1100 described herein (e.g., one or more functions of an AMF, a UPF, an SMF, a PCF, an NRF, a UDR, or an NEF as described above, e.g., with respect to Figures 10A through 10D).
  • This discussion is equally applicable to the processing node 1200 of Figure 12 where the modules 1300 may be implemented at one of the processing nodes 1200 or distributed across multiple processing nodes 1200.
  • any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses.
  • Each virtual apparatus may comprise a number of these functional units.
  • These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processors (DSPs), special-purpose digital logic, and the like.
  • the processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc.
  • Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein
  • the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.
  • the registering NRF shall set the nfType to "NRF" in the nfProfile; b) the registering NRF shall set the nfService to contain "nnrf-disc” and "nnrf-nfm” in the nfProfile; c) the registering NRF may include nrflnfo which contains the information of udrlnfo, udmlnfo, ausflnfo, amflnfo, smflnfo, upflnfo, pcflnfo, bsflnfo, neflnfo and chflnfo in the nfProfile locally configured in the NRF or the NRF received during registration of other NFs, this means the registering NRF is able to provide service for discovery of NFs subject to that information; d) if the NRF receives an NF
  • Table 6.1.6.1-1 specifies the data types defined for the Nnrf service based interface protocol
  • Table 6.1.6.1-2 specifies data types re-used by the Nnrf service based interface protocol from other specifications, including a reference to their respective specifications and when needed, a short description of their use within the Nnrf service based interface.
  • 6.2.3.2.3.1 retrieves a list of NF Instances, and their offered services, currently registered in the NRF, satisfying a number of filter criteria, such as those NF Instances offering a certain service name, or those NF Instances of a given NF type (e.g., AMF).
  • filter criteria such as those NF Instances offering a certain service name, or those NF Instances of a given NF type (e.g., AMF).
  • Table 6.2.3.2.3.1-1 URI query parameters supported by the GET method on this resource
  • the default logical relationship among the query parameters is logical "AND", i.e. all the provided query parameters shall be matched, with the exception of the "preferred-locality" query (see Table 6.2.3.2.3 1-1).
  • the NRF may support the Complex query expression as defined in 3GPP TS 29.501 [2] for the NF Discovery service. If the "complexQuery" query parameter is included, then the logical relationship among the query parameters contained in "complexQuery” query parameter is as defined in 3GPP TS 29.571 [7],
  • a NRF not supporting Complex query expression shall reject a NF service discovery request including a complexQuery parameter, with a ProblemDetails IE including the cause attribute set to INVALID_QUERY_PARAM and the invalidParams attribute indicating the complexQuery parameter.
  • This method shall support the request data structures specified in table 6.1 .3.2.3.1-2 and the response data structures and response codes specified in table 6.1.3.2.3.1-3.
  • Table 6.2.6.1-2 specifies data types re-used by the Nnrf service based interface protocol from other specifications, including a reference to their respective specifications and when needed, a short description of their use within the Nnrf service based interface.
  • the syntax of the supportedFeatures attribute is defined in clause 5.2.2 of 3GPP TS 29.571 [7], The following features are defined for the Nnrf_NFDiscovery service.
  • a method of operation of a Network Exposure Function, NEF, in a core network of a wireless communication system comprising: receiving (1002), from an application function, one or more Packet Flow Descriptions, PFDs, for one or more applications; causing (1006) the one or more PFDs to be stored in the core network in association with one or more application identifiers associated with the one or more applications, in association with an application function identifier associated with the application function, or both one or more application identifiers associated with the one or more applications and an application function identifier associated with the application function; and providing (1014), to a Network Repository Function, NRF, in the core network, the one or more application identifiers associated with the one or more applications, the application function identifier associated with the application function, or both the one or more application identifiers associated with the one or more applications and the application function identifier associated with the application function.
  • NRF Network Repository Function
  • causing (1006) the one or more PFDs to be stored in the core network comprises: causing the one or more first PFDs to be stored in the core network in association with a first application identifier of the first application, a network identifier of the ASP, or both the first application identifier of the first application and the network identifier of the ASP; and causing the one or more second PFDs to be stored in the core network in association with a second application identifier of the second application, the network identifier of the ASP, or both the second application identifier of the second application and the network identifier of the ASP.
  • any one of embodiments 1 to 4 further comprising: updating (1012) a Network Function, NF, profile of the NEF to include the one or more application identifiers in a list of application identifiers of PFDs managed by the NEF, to include the application function identifier of the application function in a list of application function identifiers of PFDs managed by the NEF, or to include both the one or more application identifiers in the list of application identifiers of PFDs managed by the NEF and the application function identifier of the application function in the list of application function identifiers of PFDs managed by the NEF; wherein causing (1006) the one or more PFDs to be stored in the core network comprises causing (1006) the updated NF profile of the NEF to be stored in the core network.
  • NF Network Function
  • any one of embodiments 1 to 5 further comprising: receiving (1040), from a Session Management Function, SMF, in the core network, a PFD management request comprising one or more requested identifiers, the one or more requested identifiers being one of the one or more application identifiers, the application function identifier, or both the one of the one or more application identifiers and the application function identifier; obtaining (1042, 1046) a set of PFDs associated with the one or more requested identifiers; and providing (1048), to the SMF, a response comprising the set of PFDs associated with the one or more requested identifiers.
  • SMF Session Management Function
  • any one of embodiments 1 to 5 further comprising: receiving, from a Session Management Function, SMF, in the core network, a subscription message comprising one or more subscribed identifiers, the one or more subscribed identifiers comprising one of the one or more application identifiers, the application function identifier, or both the one of the one or more application identifiers and the application function identifier; obtaining a set of PFDs associated with the one or more requested identifiers; and providing, to the SMF, a notification message comprising the set of PFDs associated with the one or more requested identifiers.
  • SMF Session Management Function
  • NEF Network Exposure Function
  • a network node that implements a Network Exposure Function, NEF, for a core network of a wireless communication system, the network node comprising: a network interface (1108, 1208); and processing circuitry (1104, 1204) associated with the network interface (1108, 1208), the processing circuitry (1104, 1204) configured to cause the network node to perform the method of any one of embodiments 1 to 7.
  • NEF Network Exposure Function
  • a method of operation of a Network Repository Function, NRF, in a core network of a wireless communication system comprising: receiving (1014), from a Network Exposure Function, NEF, in the core network, information comprising one or more application identifiers associated with one or more Packet Flow Descriptions, PFDs, managed by the NEF, one or more application function identifiers associated with the one or more PFDs managed by the NEF, or both the one or more application identifiers associated with the one or more PFDs managed by the NEF and the one or more application function identifiers associated with the one or more PFDs managed by the NEF; and storing (1016) the information.
  • NEF Network Exposure Function
  • the method of embodiment 10 further comprising: receiving (1034), from a Session Management Function, SMF, in the core network, a discovery request comprising one or more requested identifiers, the one or more requested identifiers comprising one of the one or more application identifiers associated with the one or more PFDs managed by the NEF, the application function identifier associated with the one or more PFDs managed by the NEF, or both the one of the one or more application identifiers associated with the one or more PFDs managed by the NEF and the application function identifier associated with the one or more PFDs managed by the NEF; selecting (1036) the NEF as one of one or more NEFs that satisfy the discovery request based on the stored information; and sending (1038), to the SMF, a response comprising one or more identifiers of the one or more NEFs that satisfy the discovery request.
  • SMF Session Management Function
  • NRF Network Repository Function
  • a network node that implements a Network Repository Function, NRF, for a core network of a wireless communication system, the network node comprising: a network interface (1108, 1208); and processing circuitry (1104, 1204) associated with the network interface (1108, 1208), the processing circuitry (1104, 1204) configured to cause the network node to perform the method of any one of embodiments 10 to 11 .
  • NRF Network Repository Function
  • a method of operation of a Session Management Function, SMF, in a core network of a wireless communication system comprising: sending (1034), to a Network Repository Function, NRF, in the core network, a discovery request for discovery of a Network Exposure Function, NEF, that manages one or more Packet Flow Descriptions, PFDs, for a particular application, for a particular application function, or for a particular application provided by a particular application function, the discovery request comprising one or more requested identifiers comprising an application identifier of the particular application, an application function identifier of the particular application function, or both the application identifier of the particular application function and the application function identifier of the particular application; and receiving (1038), from the NRF, a response comprising one or more NEF identifiers of one or more NEFs that satisfy the discovery request.
  • NRF Network Repository Function
  • NEF Network Exposure Function
  • the method of embodiment 14 further comprising: sending (1040), to a NEF identified by one of the one or more NEF identifiers, a PFD management request comprising the application identifier of the particular application function, the application function identifier of the particular application, or both the application identifier of the particular application function and the application function identifier of the particular application; and receiving (1048), from the NEF, one or more PFDs that satisfy the PFD management request, wherein the one or more PFDs that satisfy the PFD management request comprise one or more PFDs managed by the NEF for the particular application associated with the application identifier comprised in the PFD management request, one or more PFDs managed by the NEF for the particular application function associated with the application function identifier comprised in the PFD management request, or one or more PFDs managed by the NEF for the particular application provided by the particular application associated with the application identifier and the application function identifier comprised in the PFD management request.
  • the method of embodiment 14 further comprising: sending, to a NEF identified by the one or more NEF identifiers, a subscription message comprising the application identifier of the particular application function, the application function identifier of the particular application, or both the application identifier of the particular application function and the application function identifier of the particular application; and receiving, from the NEF, a notification message comprising one or more PFDs that satisfy the subscription message, wherein the one or more PFDs that satisfy the subscription message comprise one or more PFDs managed by the NEF for the particular application associated with the application identifier comprised in the subscription message, one or more PFDs managed by the NEF for the particular application function associated with the application function identifier comprised in the subscription message, or one or more PFDs managed by the NEF for the particular application provided by the particular application associated with the application identifier and the application function identifier comprised in the subscription message
  • a Session Management Function, SMF for a core network of a wireless communication system, the SMF adapted to perform the method of any one of embodiments 14 to 17.
  • a network node that implements a Session Management Function, SMF, for a core network of a wireless communication system, the network node comprising: a network interface (1108, 1208); and processing circuitry (1104, 1204) associated with the network interface (1108, 1208), the processing circuitry
  • a method in a core network of a wireless communication system comprising:
  • NEF Network Exposure Function
  • o receiving (1002), from an application function, one or more Packet Flow Descriptions, PFDs, for one or more applications; o causing (1006) the one or more PFDs to be stored in the core network in association with one or more application identifiers associated with the one or more applications, in association with an application function identifier associated with the application function, or both one or more application identifiers associated with the one or more applications and an application function identifier associated with the application function; and o providing (1014), to a Network Repository Function, NRF, in the core network, information comprising the one or more application identifiers associated with the one or more applications, the application function identifier associated with the application function, or both the one or more application identifiers associated with the one or more applications and the application function identifier associated with the application function; and
  • a Session Management Function in the core network: o sending (1034), to the NRF, a discovery request comprising one or more requested identifiers, the one or more requested identifiers comprising one of the one or more application identifiers associated with the one or more PFDs managed by the NEF, the application function identifier associated with the one or more PFDs managed by the NEF, or both the one of the one or more application identifiers associated with the one or more PFDs managed by the NEF and the application function identifier associated with the one or more PFDs managed by the NEF;

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Systems and methods are disclosed herein for providing Network Exposure Function (NEF) discovery relative to Packet Flow Description (PFD) management via a Network Repository Function (NRF). In some embodiments, a provisioning NEF that receives PFDs updates its Network Function (NF) profile with the corresponding PFD application Identifiers (IDs) and/or Application Function (AF) IDs, so the Session Management Function (SMF) can discover the correct provisioning NEF.

Description

MECHANISM FOR NEF DISCOVERY RELATIVE TO PFD MANAGEMENT
Technical Field
[0001] The present disclosure relates to Packet Flow Description (PFD) management in a core network of a wireless communication system (e.g., a Fifth Generation (5G) system).
Background
Management of Packet Flow Descriptions (PFDs) (see Section 6.1.2.3 of Third Generation Partnership Project (3GPP)
Technical Specification (TS) 23.503 V16. 1.0)
[0002] The following is an excerpt from Section 6.1.2.3 of 3GPP TS 23.503 V16.1.0:
The Management of Packet Flow Descriptions enables the UPF to perform accurate application detection when PFD(s) are provided by an ASP and then to apply enforcement actions as instructed in the PCC Rule.
The operator is able to configure pre-defined PCC Rules in the SMF or dynamic PCC Rules in the PCF that include at least an application identifier for service data flow detection, charging control information, i.e. charging key and optionally the Sponsor identifier or the ASP identifier or both. Depending on the service level agreements between the operator and the Application Server Provider, it may be possible for the ASP to provide individual PFDs or the full set of PFDs for each application identifier maintained by the ASP to the SMF via the PFD Management service in the NEF (PFDF). The PFDs become part of the application detection filters in the SMF/UPF and therefore are used as part of the logic to detect traffic generated by an application. The ASP may remove or modify some or all of the PFDs which have been provided previously for one or more application identifiers. The SMF may report the application stop to the PCF for a application instance identifier as defined in clause 5.8.2.8.4 of TS 23.501 [2] if the removed/modified PFD in SMF/UPF results in that the stop of the application instance is not being able to be detected.
NOTE 1 : PFD management is optionally supported in the NEF and the SMF.
The ASP manages (provision, update, delete) the PFDs through the NEF (PFDF). The PFD(s) are transferred to the SMF through the NEF (PFDF). The PFDF is a logical functionality in the NEF which receives PFD(s) from the ASP through the NEF, stores the PFD(s) in the UDR and provides the PFD(s) to the SMF(s) either on the request from ASP PFD management through NEF (PFDF) (push mode) or on the request from SMF (pull mode). The PFDF functionality is a service provided by the NEF.
The PFDs may be retrieved by SMF from NEF (PFDF) in "pull" mode or may be provisioned from NEF (PFDF) to the SMF in "push" mode.
When the "pull" mode is used, at the time a PCC Rule with an application identifier for which PFDs are not available is activated or provisioned, the SMF requests all PFDs for that application identifier from the NEF (PFDF), and NEF (PFDF) retrieves them from the UDR. The PFD(s) retrieved for an application identifier from the NEF (PFDF) are cached in the SMF, and the SMF maintains a caching timer associated to the PFD(s) to control how long the PFD(s) are valid. When the caching timer expires:
- If there are still active PCC rules that refer to the corresponding application identifier, the SMF reloads the PFD(s) from the NEF (PFDF) and provides it to the UPF over N4; - If there's no active PCC rule that refers to the corresponding application identifier or the SMF removes the last PCC rule that refers to the corresponding application identifier, the SMF removes the PFD(s) identified by the application identifier and informs the UPF to remove the PFD(s) identified by the application identifier over N4.
NOTE 3: It is assumed that all SMF(s) and PFD (s) in an operator network are configured with the same default caching time value to be applied for all application identifiers.
When the UPF receives the updated PFD(s) from either the same or different SMF for the same application identifier, the latest received PFD(s) shall overwrite any existing PFD(s) stored in the UPF.
If the PFDs are managed by local O&M procedures, PFD retrieval is not used; otherwise, the PFDs retrieved from NEF (PFDF) overrides any PFDs pre-configured in the SMF. The SMF shall manage the pre-configured PFDs and PFDs provided by the NEF (PFDF) at the UPF as defined in clause 5.8.2.8.4 of TS 23.501 [2] The SMF may differentiate the need for PFD retrieval based on operator configuration in the SMF.
Excerpt from 3GPP TS 29.513 V16.0.0
Pull and push mode in Fifth Generation Core (5GC) (see Section 5.5.2.2 of3GPP TS 29.513 V16.0.0) [0003] The following is an excerpt from 3GPP TS 29.513 V16.0.0.
5.5.2.2.1 PFD retrieval
This procedure enables the SMF to retrieve PFDs for application identifier(s) from the PFDF as depicted in figure 5.5.2.2.1-1 when:
- a PCC rule with the application identifier(s) is provided or activated and PFDs for the corresponding application identifier(s) provisioned by the PFDF are not available at the SMF; and
- the caching timer for an application identifier expires and the PCC Rule for this application identifier is still active.
The SMF may retrieve PFDs for one or more application identifiers in the same Request. All PFDs related to an application identifier are provided in the response from the UDR to NEF (PFDF).
[REPRODUCED AS FIGURE 1]
Figure 5.5.2.2.1-1 PFD retrieval by SMF
1. In order to retrieve the PFDs of individual application identifier, the SMF shall invoke
Nnef_PFDmanagement_Fetch service operation by sending an HTTP GET request message to the resource "Individual application PFD".
In order to retrieve the PFDs of all application identifiers, the SMF shall invoke the Nnef_PFDmanagement_Fetch service operation by sending an HTTP GET request message to the resource "PFD of applications".
In order to retrieve the PFDs of collection of application identifiers, the SMF shall invoke the Nnef_PFDmanagement_Fetch service operation by sending an HTTP GET request message to the resource "PFD of applications" with query parameters indicating the requested application identifiers.
NOTE 1 : For details of Nnef_PFDmanagement_Fetch service operation refer to 3GPP TS 29.551 [25], 2. If the requested PFDs are not available in PFDF, PFDF shall invoke Nudr_DataRepository_Query service operation by sending an FHTTP GET request message to the UDR to the resource "Individual PFD Data" as specified in 3GPP TS 29.519 [12],
NOTE 2: The SMF in step 1 can include PFD management request for multiple applications, but the UDR service for PFD management only supports one application at a time.
3. The UDR shall send an HTTP GET response message including the requested PFDs to the NEF.
4. The NEF (PFDF) sends the HTTP GET response message "200 OK" including the PFDs for the requested application identifier(s) to the SMF.
5.5.2.2.2 PFD management
This procedure enables the SMF to subscribe the notification of events when the PFDs for application identifier change.
The PFDF will notify the SMF to update and/or delete the PFDs for application identifier(s) as subscribed previously.
[REPRODUCED AS FIGURE 2]
Figure 5.5.2.2.2-1 PFDF management in the SMF
1-2. In order to subscribe the notification of events when the PFDs for application identifier change, the SMF can use Nnef_PFDmanagement_Subscribe service operation by sending an HTTP POST message to the resource "PFD subscriptions". The HTTP POST request includes a notification URI to indicate to the PFDF where to send notifications when events occur. If the subscription is accepted, he PFDF shall send the POST response message a "201 Created" to the SMF.
3-4. The PFDF shall use Nnef_PFDmanagement_Notify service operation to update and/or delete the PFDs for application identifier(s) in the SMF. The PFDF shall send an HTTP POST request message to the notification URI "{notifyUri}/notify". The SMF replies to the PFDF with an HTTP POST response message "204 No Content" indicating the successful provisioning of all PFDs or "200 OK" containing failed application identifier(s).
5-6. The SMF may initiate Nnef_PFDmanagement_Unsubscribe service operation to remove the subscription by sending an HTTP DELETE request message to the resource "Individual PFD subscription". The PFDF replies to the SMF with an HTTP DELETE response message "204 No Content".
NOTE: For details of Nnef_PFDmanagement_Subscribe/Notify/Unsubscribe service operations refer to 3GPP TS 29.551 [25],
Excerpt from 3GPP TS 23.502 V16.1.Q
PFD management via Network Exposure Function (NEF) (Packet Flow Description Function (PFDF)) in 5GC (for interaction between Application Function (AF), NEF, and User Data Repository (UDR), see Section 4.18 of 3GPP TS
23.502 V16.1.0)
[0004] Figure 5 is a combination of the flows in Section 4.18 of 3GPP TS 23.502 V16.1.0. In particular, Figure 5 illustrates a procedure for PFD management via NEF (PFDF). Steps 1-5 and 8 in Figure 5 correspond to steps 1-6 in Figure 4.18.2-1 of 3GPP TS 23.502 V16.1.0. The following is an excerpt from 3GPP TS 23.502 V16.1.0 describing steps 1-6 of Figure 4.18.2-1 (which again correspond to steps 1-5 and 8 of Figure 5): 1. The AF invokes the Nnef_PFDManagement_Create/Update/Delete service. The Allowed Delay is an optional parameter. If the Allowed Delay is included, it indicates that the list of PFDs in this request should be provisioned within the time interval indicated by the Allowed Delay to the SMF(s) that have subscribed to the PFD management service using Nnef_PFDManagement_Subscribe service operation.
2. NEF checks whether the Application is authorized to perform this request based on the operator policies.
3. The NEF (PFDF) invokes the Nudr_DM_Create/Update/Delete (Application Identifier, one or more sets of PFDs, Allowed Delay) to the UDR.
4. The UDR updates the list of PFDs for the Application Identifier.
5. The UDR sends a Nudr_DM_Create/Update/Delete Response to the NEF (PFDF).
6. The NEF sends Nnef_PFDManagement_Create/Update/Delete Response to the Application Function.
[0005] In the push mode, the following steps are performed:
• Step 6a: The NEF (PFDF) sends an Nnef_PFDManagement_Notify request to the Session Management Function (SMF) including PFD(s).
• Step 7a: The SMF returns an Nnef_PFDManagement_Notify response to the NEF (PFDF).
[0006] In the pull mode, the following steps are performed:
• Step 6b.1 : The SMF invokes the Nnef_PFDManagement_Fetch (application identifier(s)) to the NEF (PFDF).
• Step 6b.2: The NEF (PFDF) checks if the PFDs for the application identifier(s) are available in the NEF (PFDF). If available, the NEF (PFDF) skips to step 4. If not, the NEF (PFDF) invokes Nudr_DM_Query (application identifiers)) to retrieve the PFD(s) from the UDR.
• Step 6b.3: The UDR provides an Nudr_DM_Query response (application identifier(s), PFD(s)) to the NEF (PFDF).
• Step 7b: The NEF (PFDF) replies to the SMF with Nnef_PFDManagement_Fetch (application identifier(s), PFD(s)).
NF Service Registration and Discovery (see Section 4.17.1 and 4.17.4 of3GPP TS 23.502 V16.1.0)
[0007] Some background introduction for NF service registration and discovery can be found in sections 4.17.1 and 4.17.4 of 3GPP TS 23502, which are reproduced below.
4.17.1 NF service Registration
NOTE 1 : The term "NF service consumer” in this clause refers to the consumer of the NRF services and should not be confused with the role of the NF (consumer or producer).
[REPRODUCED AS FIGURE 3]
Figure 4.17.1-1 : NF Service Registration procedure 1. NF service consumer, i. e. an NF instance sends Nnrf_NFManagement_NFRegister Request message to NRF to inform the NRF of its NF profile when the NF service consumer becomes operative for the first time. See clause 5.2.7.2.2 for relevant NF profile parameters
NOTE 2: NF service consumer's NF profile is configured by OAM system.
2. The NRF stores the NF profile of NF service consumer and marks the NF service consumer available.
NOTE 3: Whether the NF profile sent by NF service consumer to NRF needs to be integrity protected by the NF service consumer and verified by the NRF is to be decided by SA3.
3. The NRF acknowledge NF Registration is accepted via Nnrf_NFManagement_NFRegister response. .4 NF/NF service discovery by NF service consumer in the same PLMN
[REPRODUCED AS FIGURE 4]
Figure 4.17.4-1 : NF/NF service discovery in the same PLMN
1. The NF service consumer intends to discover services available in the network based on service name and target NF type. The NF service consumer invokes Nnrf_NFDiscovery_Request (Expected NF service Name, NF Type of the expected NF instance, NF type of the NF consumer) from an appropriate configured NRF in the same PLMN. The parameter may include optionally producer NF Set ID, NF Service Set ID, SUPI, Data Set Identifier(s),
External Group ID (for UDM, UDR discovery), UE's Routing Indicator (for UDM and AUSF discovery), S-NSSAI, NSI ID if available, and other service related parameters. In addition, for AMF discovery, the parameters may include AMF Region ID, AMF Set ID, TAI. The NF service consumer may indicate a preference for target NF location in the Nnrf_NFDiscovery_Request. A complete list of parameters is provided in service definition in clause 5.27.3.2.
NOTE 1 : The NF service consumer indicates its NF location for preference for target NF location.
NOTE 2: The use of NSI ID within a PLMN depends on the network deployment.
NOTE 3: The need for other service related parameters depends on the NF type of the expected NF instance(s) and refer to the clause 6.3 " Principles for Network function and Network Function Service discovery and selection" in TS 23.501 [2], It is up to NF implementation whether one or multiple NF service instances are registered in the NRF.
2. The NRF authorizes the Nnrf_NFDiscovery_Request. Based on the profile of the expected NF/NF service and the type of the NF service consumer, the NRF determines whether the NF service consumer is allowed to discover the expected NF instance(s). If the expected NF instance(s) or NF service instance(s) are deployed in a certain network slice, NRF authorizes the discovery request according to the discovery configuration of the Network Slice, e.g. the expected NF instance(s) are only discoverable by the NF in the same network slice.
3. If allowed, the NRF determines a set of NF instance(s) matching the Nnrf_NFDiscovery_Request and internal policies of the NRF and sends the NF profile(s) of the determined NF instances. Each NF profile containing at least the output required parameters (see clause 5.27.3.2) to the NF service consumer via Nnrf_NFDiscovery_Request Response message
If the target NF is UDR, UDM or AUSF, if SUPI was used as optional input parameter in the request, the NRF shall provide the corresponding UDR, UDM or AUSF instance(s) that matches the optional input SUPI. Otherwise, if SUPI is not provided in the request, the NRF shall return all applicable UDR instance(s) (e.g. based on the Data Set Id, NF type), UDM instance(s) or AUSF instance(s) (e.g. based on NF type) and if applicable, the information of the range of SUPI(s) and/or Data Set Id each UDR instance is supporting.
If the target NF is CHF, if SUPI, GPSI or PLMN ID was used as optional input parameter in the request, the NRF shall provide the corresponding CHF instance(s) that matches the optional input SUPI, GPSI or PLMN ID. The NRF shall provide the primary CHF instance and the secondary CHF instance pair(s) together. Otherwise, if neither SUPI/PLMN ID nor GPSI is provided in the request, the NRF shall return all applicable CHF instance(s) and if applicable, the information of the range of SUPI(s), GPSI(s) or PLMN ID(s).
If the NF service consumer provided a preferred target NF location, the NRF shall not limit the set of discovered NF instances or NF service instance(s) to the target NF location, e.g. the NRF may provide NF instance(s) or NF service instance(s) for which location is not the preferred target NF location if no NF instance or NF service instance could be found for the preferred target NF location.
Summary
[0008] Currently, the Network Exposure Function (NEF) providing the Nnef_PFDManagement service registers itself in the Network Repository Function (NRF), and the current Release 15 function can support the Packet Flow Description (PFD) management function in Fifth Generation Core (5GC) with the prerequisite that all NEFs in a Public Land Mobile Network (PLMN) provide homogenous support for the Nnef_PFDManagement (both southbound and northbound) service. Then the Session Management Function (SMF), after querying the NRF, gets all NEFs in a PLMN because what is retrieved from the NRF is the NEF(s) capable of providing the Nnef_PFDManagement service. And then the SMF broadcasts the Nnef_PFDManagement service to all of them.
[0009] Figure 6 shows the interactions in a "pull mode." The same applies for a “push mode" with the difference that step 4 is replaced by a SUBSCRIBE operation. In both the “pull mode” and the “push mode," the fetch request / subscribe request is broadcast to all NEFs. Since the provisioning NEF is one of those NEFs, it will provide the PFD to the SMF in the “pull mode” or be aware of the PFD change so to “push” the change to the SMF. Flowever, the consequence is the signaling increase and unnecessary processing in the network (e.g., four NEFs and five User Data Repositories (UDRs) lead to 20 PFD retrievals). Regarding the “provisioning NEF”, multiple NEFs may be deployed in a PLMN and all these NEFs may provide the Nnef_PFDManagement service. The provisioning NEF is the one among these NEFs that is responsible for PFD management of certain application(s). Those applications may be interested by a SMF regarding the PFD management.
[0010] Systems and methods are disclosed herein for providing NEF discovery relative to PFD management via an NRF. In some embodiments, a provisioning NEF that receives PFDs updates its Network Function (NF) profile with the corresponding PFD application Identifiers (IDs) and/or Application Function (AF) IDs, so the SMF can discover the correct provisioning NEF. For this, in an example embodiment, it is proposed to define in Third Generation Partnership Project (3GPP) Technical Specification (TS) 29.510 a Neflnfo data type including one or more PFD application IDs and/or AF IDs. The Neflnfo data type will be used in an Nnrf_NFDiscovery Application Program Interface (API) and an Nnrf_NFManagement API. With this mechanism, the SMF can use application IDs and/or AF IDs to discover the provisioning NEF for PFD management purposes.
[OOll] In some embodiments, the following changes for protocol details are proposed:
• NRF services (i.e. TS 29.510):
1. Add a new Neflnfo data type including a list of PFD application IDs and/or AF IDs.
2. Nnrf_NFManagement API. Support the NEF to update its NEFProfile including a list of PFD application IDs and/or AF IDs.
3. Nnrf_NFDiscovery API. Support a consumer (e.g., an SMF) to discover the NEF (relative to the PFD management service) by including, as query parameters, one or more PFD application IDs and/or AF IDs.
[0012] Embodiments disclosed herein provide a solution to the aforementioned issue to support NEF discovery (relative to PFD management) via an NRF. In addition, through application IDs, there is no need to provision the AF IDs for the application IDs in the SMF. It is well suited for the pull mode, where the SMF only knows the application IDs from the Policy and Charging Control (PCC) rule. Through AF IDs, there is less signaling processing and storage needs in the UDR, and the data is more static.
Brief Description of the Drawings
[0013] The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.
[0014] Figure 1 is a reproduction of Figure 5.5.2.2.1-1 of Third Generation Partnership Project (3GPP) Technical Specification (TS) 29.513 V16.0.0, which illustrates a procedure for Packet Flow Description (PFD) retrieval by a Session Management Function (SMF);
[0015] Figure 2 is a reproduction of Figure 5.5.2.2.2-1 of 3GPP TS 29.513 V16.0.0, which illustrates a procedure for PFD Function (PFDF) management in an SMF;
[0016] Figure 3 is a reproduction of Figure 4.17.1-1 of 3GPP TS 23.502, which illustrates a procedure for Network Function (NF) service registration;
[0017] Figure 4 is a reproduction of Figure 4.17.4-1 of 3GPP TS 23.502, which illustrates a procedure for NF/NF service discovery in the same Public Land Mobile Network (PLMN);
[0018] Figure 5 PFD management via Network Exposure Function (NEF) (Packet Flow Description Function (PFDF)) in 5GC (for interaction between Application Function (AF), NEF, and User Data Repository (UDR);
[0019] Figure 6 shows interactions in a “pull mode”;
[0020] Figure 7 illustrates one example of a cellular communications network in which embodiments of the present disclosure may be implemented; [0021] Figure 8 illustrates a wireless communication system represented as a Fifth Generation (5G) network architecture composed of core NFs, where interaction between any two NFs is represented by a point-to-point reference point/interface;
[0022] Figure 9 illustrates a 5G network architecture using service-based interfaces between the NFs in the control plane, instead of the point-to-point reference points/interfaces used in the 5G network architecture of Figure 8;
[0023] Figures 10A through 10D illustrate a sequence diagram for an example of Application Service Provider (ASP) (Application Function (AF)) provisioning PFDs for a certain set of applications and SMF using the pull procedure to retrieve the PFDs using NEF discovery through a Network Repository Function (NRF) in accordance with some embodiments of the present disclosure;
[0024] Figure 11 is a schematic block diagram of a network node implementing a core network entity (e.g., a core network function) according to some embodiments of the present disclosure;
[0025] Figure 12 is a schematic block diagram that illustrates a virtualized embodiment of the network node of Figure 11 according to some embodiments of the present disclosure; and
[0026] Figure 13 is a schematic block diagram of the network node of Figure 11 according to some other embodiments of the present disclosure.
Detailed Description
[0027] The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure.
[0028] Radio Node: As used herein, a “radio node” is either a radio access node or a wireless device.
[0029] Radio Access Node: As used herein, a “radio access node” or “radio network node” is any node in a radio access network of a cellular communications network that operates to wirelessly transmit and/or receive signals. Some examples of a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a home eNB, or the like), and a relay node.
[0030] Core Network Node: As used herein, a “core network node” is any type of node in a core network or any node that implements a core network function. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), a Flome Subscriber Server (HSS), or the like. Some other examples of a core network node include a node implementing a Access and Mobility Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Network Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.
[0031] Wireless Device: As used herein, a “wireless device” is any type of device that has access to (i.e., is served by) a cellular communications network by wirelessly transmitting and/or receiving signals to a radio access node(s). Some examples of a wireless device include, but are not limited to, a User Equipment device (UE) in a 3GPP network and a Machine Type Communication (MTC) device.
[0032] Network Node: As used herein, a “network node” is any node that is either part of the radio access network or the core network of a cellular communications network/system.
[0033] Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system.
[0034] Note that, in the description herein, reference may be made to the term “cell"; however, particularly with respect to 5G NR concepts, beams may be used instead of cells and, as such, it is important to note that the concepts described herein are equally applicable to both cells and beams.
[0035] Systems and methods are disclosed herein for providing NEF discovery relative to Packet Flow Description (PFD) management via a NRF. In some embodiments, a provisioning NEF that receives PFDs updates its NF profile with the corresponding PFD application Identifiers (IDs) and/or Application Function (AF) IDs, so the SMF can discover the correct provisioning NEF. For this, in an example embodiment, it is proposed to define in 3GPP Technical Specification (TS) 29.510 a Neflnfo data type including one or more PFD application IDs and/or AF IDs. The Neflnfo data type will be used in an Nnrf_NFDiscovery Application Program Interface (API) and an Nnrf_NFManagement API. With this mechanism, the SMF can use application IDs and/or AF IDs to discover the provisioning NEF for PFD management purposes.
[0036] Figure 7 illustrates one example of a cellular communications system 700 in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communications system 700 is a 5G System (5GS) including a NR Radio Access Network (RAN). In this example, the RAN includes base stations 702-1 and 702-2, which in 5G NR are referred to as gNBs, controlling corresponding (macro) cells 704-1 and 704-2. The base stations 702-1 and 702-2 are generally referred to herein collectively as base stations 702 and individually as base station 702. Likewise, the (macro) cells 704-1 and 704-2 are generally referred to herein collectively as (macro) cells 704 and individually as (macro) cell 704. The RAN may also include a number of low power nodes 706-1 through 706-4 controlling corresponding small cells 708-1 through 708-4. The low power nodes 706-1 through 706-4 can be small base stations (such as pico or femto base stations) or Remote Radio Heads (RRHs), or the like. Notably, while not illustrated, one or more of the small cells 708-1 through 708-4 may alternatively be provided by the base stations 702. The low power nodes 706-1 through 706-4 are generally referred to herein collectively as low power nodes 706 and individually as low power node 706. Likewise, the small cells 708-1 through 708-4 are generally referred to herein collectively as small cells 708 and individually as small cell 708. The cellular communications system 700 also includes a core network 710, which in the 5GS is referred to as the 5G Core (5GC). The base stations 702 (and optionally the low power nodes 706) are connected to the core network 710.
[0037] The base stations 702 and the low power nodes 706 provide service to wireless devices 712-1 through 712- 5 in the corresponding cells 704 and 708. The wireless devices 712-1 through 712-5 are generally referred to herein collectively as wireless devices 712 and individually as wireless device 712. The wireless devices 712 are also sometimes referred to herein as UEs.
[0038] Figure 8 illustrates a wireless communication system represented as a 5G network architecture composed of core NFs, where interaction between any two NFs is represented by a point-to-point reference point/interface. Figure 8 can be viewed as one particular implementation of the system 700 of Figure 7.
[0039] Seen from the access side the 5G network architecture shown in Figure 8 comprises a plurality of UEs connected to either a RAN or an Access Network (AN) as well as an AMF. Typically, the R(AN) comprises base stations, e.g. such as eNBs or gNBs or similar. Seen from the core network side, the 5GC NFs shown in Figure 8 include a NSSF, an AUSF, a UDM, an AMF, a SMF, a PCF, and an AF.
[0040] Reference point representations of the 5G network architecture are used to develop detailed call flows in the normative standardization. The N1 reference point is defined to carry signaling between the UE and AMF. The reference points for connecting between the AN and AMF and between the AN and UPF are defined as N2 and N3, respectively. There is a reference point, N11, between the AMF and SMF, which implies that the SMF is at least partly controlled by the AMF. N4 is used by the SMF and UPF so that the UPF can be set using the control signal generated by the SMF, and the UPF can report its state to the SMF. N9 is the reference point for the connection between different UPFs, and N14 is the reference point connecting between different AMFs, respectively. N15 and N7 are defined since the PCF applies policy to the AMF and SMP, respectively. N12 is required for the AMF to perform authentication of the UE. N8 and N10 are defined because the subscription data of the UE is required for the AMF and SMF.
[0041] The 5GC network aims at separating user plane and control plane. The user plane carries user traffic while the control plane carries signaling in the network. In Figure 8, the UPF is in the user plane and all other NFs, i.e., the AMF, SMF, PCF, AF, AUSF, and UDM, are in the control plane. Separating the user and control planes guarantees each plane resource to be scaled independently. It also allows UPFs to be deployed separately from control plane functions in a distributed fashion. In this architecture, UPFs may be deployed very close to UEs to shorten the Round Trip Time (RTT) between UEs and data network for some applications requiring low latency.
[0042] The core 5G network architecture is composed of modularized functions. For example, the AMF and SMF are independent functions in the control plane. Separated AMF and SMF allow independent evolution and scaling. Other control plane functions like the PCF and AUSF can be separated as shown in Figure 8. Modularized function design enables the 5GC network to support various services flexibly. [0043] Each NF interacts with another NF directly. It is possible to use intermediate functions to route messages from one NF to another NF. In the control plane, a set of interactions between two NFs is defined as service so that its reuse is possible. This service enables support for modularity. The user plane supports interactions such as forwarding operations between different UPFs.
[0044] Figure 9 illustrates a 5G network architecture using service-based interfaces between the NFs in the control plane, instead of the point-to-point reference points/interfaces used in the 5G network architecture of Figure 8. Flowever, the NFs described above with reference to Figure 8 correspond to the NFs shown in Figure 9. The service(s) etc. that a NF provides to other authorized NFs can be exposed to the authorized NFs through the service-based interface. In Figure 9 the service based interfaces are indicated by the letter “N” followed by the name of the NF, e.g. Namf for the service based interface of the AMF and Nsmf for the service based interface of the SMF etc. The NEF and the NRF in Figure 9 are not shown in Figure 8 discussed above. However, it should be clarified that all NFs depicted in Figure 8 can interact with the NEF and the NRF of Figure 9 as necessary, though not explicitly indicated in Figure 8.
[0045] Some properties of the NFs shown in Figures 8 and 9 may be described in the following manner. The AMF provides UE-based authentication, authorization, mobility management, etc. A UE even using multiple access technologies is basically connected to a single AMF because the AMF is independent of the access technologies. The SMF is responsible for session management and allocates Internet Protocol (IP) addresses to UEs. It also selects and controls the UPF for data transfer. If a UE has multiple sessions, different SMFs may be allocated to each session to manage them individually and possibly provide different functionalities per session. The AF provides information on the packet flow to the PCF responsible for policy control in order to support Quality of Service (QoS). Based on the information, the PCF determines policies about mobility and session management to make the AMF and SMF operate properly. The AUSF supports authentication function for UEs or similar and thus stores data for authentication of UEs or similar while the UDM stores subscription data of the UE. The Data Network (DN), not part of the 5GC network, provides Internet access or operator services and similar.
[0046] An NF may be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., a cloud infrastructure.
[0047] Now a description of some example embodiments of the present disclosure is provided. The proposed solution allows support for NEF discovery (relative to PFD management) via NRF by defining a Neflnfo data type that will be used in an Nnrf_NFDiscovery API and an Nnrf_NFManagement API.
[0048] Figures 10A through 10D illustrate a sequence diagram for an example of Application Service Provider (ASP) (AF) provisioning PFDs for a certain set of applications and SMF using the pull procedure to retrieve the PFDs using NEF discovery through NRF in accordance with some embodiments of the present disclosure. The steps of Figures 10A through 10D are detailed below: [0049] Steps 1000 and 1002: ASP (AF), e.g. Google Inc., decides to trigger an Nnef procedure towards an NEF (referred to herein as the provisioning NEF) in order to provision PFDs for a certain set of applications (e.g., YouTube and Gmail in this example). Specifically, in some embodiments, the ASP (AF) triggers a Hypertext Transfer Protocol (HTTP) POST message including afld=Google Inc, externalAppld=YouTube and the corresponding PFDs, and externalAppld=Gmail and the corresponding PFDs.
[0050] Step 1004: The NEF acknowledges the request with, in this example, an Nnef 200 OK message.
[0051] Steps 1006, 1008, and 1010: The NEF maps the externalApplds to (internal) applds and sends a request to a User Data Repository (UDR) to store the PFDs for the application (s) (the one(s) received in step 1002 above). The UDR stores the PFDs for the application(s). In this example, the UDR stores, as application data, the following parameters: afld=Google Inc., appld=YouTube and its PFDs, appld=Google Inc. and its PFDs. Here the mapped
(internal) applds have the same values as externalApplds. The UDR acknowledges the request (indicating successful operation).
[0052] Steps 1012 and 1014: The NEF updates its NFProfile based on the provisioned information. In some embodiments, the NEF communicates with the NRF to update its NFProfile to include a list of application IDs (e.g., appIDs) of the provisioned PFDs and/or a list of application function IDs (e.g., aflds) of the provisioned PFDs. In some embodiments, in order to do this, the NEF triggers an Nnrf_NFManagement Request towards NRF with the NFprofile including the new Neflnfo as proposed in tables below. Note that the data structures below are only examples. The name of the data structure as well as the contents of the data structure may vary depending on, e.g., the particular implementation. 6.1.6.2.x Type: Neflnfo
Table 6.1.6.2.X-1 : Definition of type Neflnfo
Figure imgf000014_0001
6. 1.6.2.yType: PfdData
Table 6.1.6.2.y-1 : Definition of type PfdData
Figure imgf000014_0002
In the example, the Neflnfo structure will include pfdData with applds=YouTube, Gmail and aflds=Google Inc.
[0053] Steps 1016 and 1018: The NRF stores the NFProfile including the above information and acknowledges the request in 1014 with an Nnrf_NFManagement Response message. [0054] Steps 1020 and 1022: At some point, a UE triggers PDU session establishment by means of sending a PDU Session Establishment Request to an AMF. The AMF selects an SMF to manage the PDU session (the SMF selection function in the AMF selects an SMF instance based on the available SMF instances obtained from NRF or based on the configured SMF information in the AMF) and triggers Nsmf PDU Session Create. Note the sequence diagram in Figures 10A through 10D does not include all the signaling messages involved in the PDU Session Establishment procedure. The relevant signaling messages for the present disclosure are described in subsequent steps. [0055] Step 1024: The SMF triggers an Npcf_SMPolicyControl_Create Request message to the PCF in order to retrieve Session Management (SM) policies for the user PDU session.
[0056] Step 1026: The PCF triggers an Nudr_Query Request message to the UDR in order to retrieve the policy data for this user PDU session.
[0057] Step 1028: The UDR answers with an Nudr_Query Response message including the Subscriber Policy Data.
[0058] Step 1030: The PCF generates the corresponding Policy and Charging Control (PCC) rule(s) based on the Subscriber Policy Data.
[0059] Step 1032: Based on the above, the PCF triggers an Npcf_SMPolicyControl_Create Response message including the PCC rules to be applied for this user PDU session. In this example, there is a PCC rule for the YouTube application including some enforcement actions (e.g., charging and QoS).
[0060] Step 1034: Based on the PCC rule(s) received in step 1032 above, in this example a PCC rule with appld=YouTube, the SMF triggers a PFD management pull procedure to retrieve the PFDs for the YouTube application. First, the SMF identifies the NEF that manages the PFDs for the YouTube application. In order to do this, the SMF triggers the NEF discovery procedure (through the NRF) by sending an Nnrf_NFDiscovery Request message towards the NRF including the application ID or the application function ID associated with the desired application for the user PDU session, which in this example is the YouTube application or the Google Inc. application function. In addition, the SMF preferably includes information that indicates the desired NF type (which in this case is the NEF type) and information that indicates the desired NF service type (which in this case is PFD management). In this example, the Nnrf_NFDiscovery Request message includes the following information: nfType=NEF, nfService=PFDManagement, and Neflnfo(appld=YouTube and/or afld=Google Inc.}. In some embodiments, the consumer (SMF) is allowed to filter by appld and/or by afld. In case afld is used, the SMF would be pre-provisioned accordingly as afld is not conveyed in the PCC rule.
[0061] In some embodiments, the Nnrf_NFDiscovery Request towards the NRF triggered by the SMF includes a new query parameter pfd-data as proposed in tables below. Note that the name of the new query parameter as well as the data structures below are only examples and may vary depending on, e.g., the particular implementation. 6.2.3.2.3.1 GET
This operation retrieves a list of NF Instances, and their offered services, currently registered in the NRF, satisfying a number of filter criteria, such as those NF Instances offering a certain service name, or those NF Instances of a given NF type (e.g., AMF) Table 6.2.3.2.3.1-1: URI query parameters supported by the GET method on this resource
Figure imgf000016_0001
[0062] Steps 1036 and 1038: The NRF selects an NEF instance matching the requested information, i.e. an NEF which supports the PFD management service and which manages the PFDs for the requested application (e.g., YouTube in this example) and/or ASP (e.g., Google Inc. in this example). The NRF responds back to the SMF with an Nnrf_NFDiscovery Response message including the selected NEF instance ID.
[0063] Step 1040: The SMF triggers a Nnef_PFDManagement_Fetch Request message to the selected NEF (NEF instance ID) in order to retrieve the PFDs for the desired application, which again is appld=YouTube in this example.
[0064] Step 1042: The NEF triggers an Nudr_Query Request message to retrieve the PFDs for, in this example, appld=YouTube
[0065] Steps 1044 and 1046: The UDR retrieves the stored PFDs for the selected application and answers with an Nudr_Query Response message including the requested PFDs.
[0066] Step 1048: The NEF answers the message in step 1040 with an Nnef_PFDManagement_Fetch Response including the requested PFDs for, in this example, appld=YouTube. [0067] Steps 1050 and 1052: The SMF selects a UPF and triggers a Packet Forwarding Control Protocol (PFCP)
PFD Management Request message including the PFDs for, in this example, appld=YouTube. The UPF answers the SMF with a PFCP PFD Management Response message.
[0068] Step 1054: The SMF triggers PFCP Session Establishment Request message including the corresponding Packet Detection Rules (PDRs), Forwarding Action Rules (FARs), QoS Enforcement Rules (QERs), and/or Usage Report Rules (URRs). In this example, there will be a PDR with a Packet Detection Information (PDI) of type application with appld=YouTube, and a corresponding FAR, QER, and URR. The contents of the FAR, QER, and URR are not relevant for this disclosure.
[0069] Step 1056: The UPF stores the PDRs, FARs, QERs, and/or URRs and answers back to the SMF with a PFCP Session Establishment Response message. [0070] Steps 1058, 1060, 1062, and 1064: At the UE, the user starts an application (e.g., YouTube). The UPF detects YouTube application traffic based on the PDR information indicated above. If there is a match, packets are classified as YouTube and the UPF applies the corresponding enforcement actions (FAR, QER, URR).
[0071] Note that the process of Figures 10A through 10D are for the pull mode. Similarly, for the push mode, the Nnef_PFDManagement_Subscribe service operation can be triggered by the SMF based on the result of the NRF query by the appld and/or afld. This service operation can be triggered by the SMF at any time (e.g., at start/restart, or at reception of the PCC rule at step 1032 in Figure 10B). If there is any change (including initial PFD provisioning at subscription) in the PFD data, an Nnef_PFDManagement_Notifiy service operation is sent from the NEF to the SMF, and the SMF is responsible to deploy the received PFD data (as depicted in steps 1050 and 1052 in Figure 10D).
[0072] Figure 11 is a schematic block diagram of a core network node 1100 according to some embodiments of the present disclosure. The core network node 1100 is a network node implementation a core network entity or a core network NF such as, e.g., an AMF, a UPF, an SMF, a PCF, an NRF, a UDR, or an NEF (e.g., such as those shown in Figures 10A through 10D and described above). As illustrated, the core network node 1100 includes one or more processors 1104 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory 1106, and a network interface 1108. The one or more processors 1104 are also referred to herein as processing circuitry. The one or more processors 1104 operate to provide one or more functions of a core network node 1100 as described herein (e.g., one or more functions of an AMF, a UPF, an SMF, a PCF, an NRF, a UDR, or an NEF as described above, e.g., with respect to Figures 10A through 10D). In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory 1106 and executed by the one or more processors 1104.
[0073] Figure 12 is a schematic block diagram that illustrates a virtualized embodiment of the core network node 1100 according to some embodiments of the present disclosure. As used herein, a “virtualized” core network node is an implementation of the core network node 1100 in which at least a portion of the functionality of the core network node 1100 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, the core network node 1100 includes one or more processing nodes 1200 coupled to or included as part of a network(s) 1202. Each processing node 1200 includes one or more processors 1204 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 1206, and a network interface 1208.
[0074] In this example, functions 1210 of the core network node 1100 described herein (e.g., one or more functions of an AMF, a UPF, an SMF, a PCF, an NRF, a UDR, or an NEF as described above, e.g., with respect to Figures 10A through 10D) are implemented at the one or more processing nodes 1200 or distributed across two or more of the processing nodes 1200 in any desired manner. In some particular embodiments, some or all of the functions 1210 of the core network node 1100 described herein (e.g., one or more functions of an AMF, a UPF, an SMF, a PCF, an NRF, a UDR, or an NEF as described above, e.g., with respect to Figures 10A through 10D) are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 1200. [0075] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the core network node 1100 or a node (e.g., a processing node 1200) implementing one or more of the functions 1210 of the core network node 1100 in a virtual environment according to any of the embodiments described herein (e.g., one or more functions of an AMF, a UPF, an SMF, a PCF, an NRF, a UDR, or an NEF as described above, e.g., with respect to Figures 10A through 10D) is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).
[0076] Figure 13 is a schematic block diagram of the core network node 1100 according to some other embodiments of the present disclosure. The core network node 1100 includes one or more modules 1300, each of which is implemented in software. The module(s) 1300 provide the functionality of the core network node 1100 described herein (e.g., one or more functions of an AMF, a UPF, an SMF, a PCF, an NRF, a UDR, or an NEF as described above, e.g., with respect to Figures 10A through 10D). This discussion is equally applicable to the processing node 1200 of Figure 12 where the modules 1300 may be implemented at one of the processing nodes 1200 or distributed across multiple processing nodes 1200.
[0077] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.
[0078] While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).
[0079] One example implementation of some embodiments of the present disclosure are shown in a Change Request for 3GPP TS 29.510 V16.0.0 as follows:
Figure imgf000018_0001
5.2.2.2.3NRF registration to another NRF
The procedure specified in subclause 5.2.2.2.2 applies. Additionally: a) the registering NRF shall set the nfType to "NRF" in the nfProfile; b) the registering NRF shall set the nfService to contain "nnrf-disc" and "nnrf-nfm" in the nfProfile; c) the registering NRF may include nrflnfo which contains the information of udrlnfo, udmlnfo, ausflnfo, amflnfo, smflnfo, upflnfo, pcflnfo, bsflnfo, neflnfo and chflnfo in the nfProfile locally configured in the NRF or the NRF received during registration of other NFs, this means the registering NRF is able to provide service for discovery of NFs subject to that information; d) if the NRF receives an NF registration with the nfType set to "NRF", the NRF shall use the information contained in the nfProfile to target the registering NRF when forwarding or redirecting NF service discovery request.
Figure imgf000019_0001
6. 6.i General
This clause specifies the application data model supported by the API. Table 6.1.6.1-1 specifies the data types defined for the Nnrf service based interface protocol
Table 6.1.6.1-1: Nnrf_NFManagement specific Data Types
Figure imgf000020_0001
Figure imgf000021_0001
Table 6.1.6.1-2 specifies data types re-used by the Nnrf service based interface protocol from other specifications, including a reference to their respective specifications and when needed, a short description of their use within the Nnrf service based interface.
Table 6.1.6.1-2: Nnrf_NFManagement re-used Data Types
Figure imgf000021_0002
Figure imgf000021_0003
6.1.6.2.2 Type: NF Profile
Table 6.1.6.2.2-1 : Definition of type NFProfile
Figure imgf000022_0001
Figure imgf000023_0001
Figure imgf000024_0001
Figure imgf000025_0001
Figure imgf000026_0001
6.1.6.2.31 Type: Nrflnfo
Table 6.1.6.2.31-1 : Definition of type Nrflnfo
Figure imgf000027_0001
Figure imgf000027_0002
6.1.6.2.x Type: Neflnfo
Table 6.1.6.2.X-1 : Definition of type Neflnfo
Figure imgf000028_0001
Figure imgf000028_0003
6.1.6.2.y Type: PfdData
Table 6.1.6.2.y-1 : Definition of type PfdData
Figure imgf000028_0002
Figure imgf000028_0004
6.2.3.2.3.1 GET This operation retrieves a list of NF Instances, and their offered services, currently registered in the NRF, satisfying a number of filter criteria, such as those NF Instances offering a certain service name, or those NF Instances of a given NF type (e.g., AMF).
Table 6.2.3.2.3.1-1: URI query parameters supported by the GET method on this resource
Figure imgf000029_0001
Figure imgf000030_0001
Figure imgf000031_0001
Figure imgf000032_0001
The default logical relationship among the query parameters is logical "AND", i.e. all the provided query parameters shall be matched, with the exception of the "preferred-locality" query (see Table 6.2.3.2.3 1-1).
The NRF may support the Complex query expression as defined in 3GPP TS 29.501 [2] for the NF Discovery service. If the "complexQuery" query parameter is included, then the logical relationship among the query parameters contained in "complexQuery" query parameter is as defined in 3GPP TS 29.571 [7],
A NRF not supporting Complex query expression shall reject a NF service discovery request including a complexQuery parameter, with a ProblemDetails IE including the cause attribute set to INVALID_QUERY_PARAM and the invalidParams attribute indicating the complexQuery parameter.
This method shall support the request data structures specified in table 6.1 .3.2.3.1-2 and the response data structures and response codes specified in table 6.1.3.2.3.1-3.
Table 6.2.3.2.3.1-2: Data structures supported by the GET Request Body on this resource
Figure imgf000033_0001
Table 6.2.3.2.3.1-3: Data structures supported by the GET Response Body on this resource
Figure imgf000033_0002
Figure imgf000033_0003
6.2.6.1 General This clause specifies the application data model supported by the API. Table 6.2.6.1-1 specifies the data types defined for the Nnrf service based interface protocol
Table 6.2.6.1-1 : Nnrf_NFDiscovery specific Data Types
Figure imgf000034_0001
Table 6.2.6.1-2 specifies data types re-used by the Nnrf service based interface protocol from other specifications, including a reference to their respective specifications and when needed, a short description of their use within the Nnrf service based interface.
Table 6.2.6.1-2: Nnrf_NFDiscovery re-used Data Types
Figure imgf000035_0001
Figure imgf000035_0002
6.2.6.2.3 Type: NF Profile
Table 6.2.6.2.3-1 : Definition of type NFProfile
Figure imgf000036_0001
Figure imgf000037_0001
Figure imgf000038_0002
_ _
Figure imgf000038_0003
6.2.9 Features supported by the NFDiscovery service
The syntax of the supportedFeatures attribute is defined in clause 5.2.2 of 3GPP TS 29.571 [7], The following features are defined for the Nnrf_NFDiscovery service.
Table 6.2.9-1 : Features of supportedFeatures attribute used by NnrLNFDiscovery service
Figure imgf000038_0001
Some embodiments that are described above may be summarized in the following manner: 1. A method of operation of a Network Exposure Function, NEF, in a core network of a wireless communication system, the method comprising: receiving (1002), from an application function, one or more Packet Flow Descriptions, PFDs, for one or more applications; causing (1006) the one or more PFDs to be stored in the core network in association with one or more application identifiers associated with the one or more applications, in association with an application function identifier associated with the application function, or both one or more application identifiers associated with the one or more applications and an application function identifier associated with the application function; and providing (1014), to a Network Repository Function, NRF, in the core network, the one or more application identifiers associated with the one or more applications, the application function identifier associated with the application function, or both the one or more application identifiers associated with the one or more applications and the application function identifier associated with the application function.
2. The method of embodiment 1 wherein the application function is an Application Service Provider, ASP, and the one or more applications are one or more applications provided by the ASP.
3. The method of embodiment 2 wherein the one or more applications comprise a first application and a second application, and the one or more PFDs comprise one or more first PFDs for the first application and one or more second PFDs for the second application.
4. The method of embodiment 3 wherein causing (1006) the one or more PFDs to be stored in the core network comprises: causing the one or more first PFDs to be stored in the core network in association with a first application identifier of the first application, a network identifier of the ASP, or both the first application identifier of the first application and the network identifier of the ASP; and causing the one or more second PFDs to be stored in the core network in association with a second application identifier of the second application, the network identifier of the ASP, or both the second application identifier of the second application and the network identifier of the ASP.
5. The method of any one of embodiments 1 to 4 further comprising: updating (1012) a Network Function, NF, profile of the NEF to include the one or more application identifiers in a list of application identifiers of PFDs managed by the NEF, to include the application function identifier of the application function in a list of application function identifiers of PFDs managed by the NEF, or to include both the one or more application identifiers in the list of application identifiers of PFDs managed by the NEF and the application function identifier of the application function in the list of application function identifiers of PFDs managed by the NEF; wherein causing (1006) the one or more PFDs to be stored in the core network comprises causing (1006) the updated NF profile of the NEF to be stored in the core network.
6. The method of any one of embodiments 1 to 5 further comprising: receiving (1040), from a Session Management Function, SMF, in the core network, a PFD management request comprising one or more requested identifiers, the one or more requested identifiers being one of the one or more application identifiers, the application function identifier, or both the one of the one or more application identifiers and the application function identifier; obtaining (1042, 1046) a set of PFDs associated with the one or more requested identifiers; and providing (1048), to the SMF, a response comprising the set of PFDs associated with the one or more requested identifiers.
7. The method of any one of embodiments 1 to 5 further comprising: receiving, from a Session Management Function, SMF, in the core network, a subscription message comprising one or more subscribed identifiers, the one or more subscribed identifiers comprising one of the one or more application identifiers, the application function identifier, or both the one of the one or more application identifiers and the application function identifier; obtaining a set of PFDs associated with the one or more requested identifiers; and providing, to the SMF, a notification message comprising the set of PFDs associated with the one or more requested identifiers.
8. A Network Exposure Function, NEF, for a core network of a wireless communication system, the NEF adapted to perform the method of any one of embodiments 1 to 7.
9. A network node that implements a Network Exposure Function, NEF, for a core network of a wireless communication system, the network node comprising: a network interface (1108, 1208); and processing circuitry (1104, 1204) associated with the network interface (1108, 1208), the processing circuitry (1104, 1204) configured to cause the network node to perform the method of any one of embodiments 1 to 7.
10. A method of operation of a Network Repository Function, NRF, in a core network of a wireless communication system, the method comprising: receiving (1014), from a Network Exposure Function, NEF, in the core network, information comprising one or more application identifiers associated with one or more Packet Flow Descriptions, PFDs, managed by the NEF, one or more application function identifiers associated with the one or more PFDs managed by the NEF, or both the one or more application identifiers associated with the one or more PFDs managed by the NEF and the one or more application function identifiers associated with the one or more PFDs managed by the NEF; and storing (1016) the information.
11 . The method of embodiment 10 further comprising: receiving (1034), from a Session Management Function, SMF, in the core network, a discovery request comprising one or more requested identifiers, the one or more requested identifiers comprising one of the one or more application identifiers associated with the one or more PFDs managed by the NEF, the application function identifier associated with the one or more PFDs managed by the NEF, or both the one of the one or more application identifiers associated with the one or more PFDs managed by the NEF and the application function identifier associated with the one or more PFDs managed by the NEF; selecting (1036) the NEF as one of one or more NEFs that satisfy the discovery request based on the stored information; and sending (1038), to the SMF, a response comprising one or more identifiers of the one or more NEFs that satisfy the discovery request.
12. A Network Repository Function, NRF, for a core network of a wireless communication system, the NRF adapted to perform the method of any one of embodiments 10 to 11.
13. A network node that implements a Network Repository Function, NRF, for a core network of a wireless communication system, the network node comprising: a network interface (1108, 1208); and processing circuitry (1104, 1204) associated with the network interface (1108, 1208), the processing circuitry (1104, 1204) configured to cause the network node to perform the method of any one of embodiments 10 to 11 .
14. A method of operation of a Session Management Function, SMF, in a core network of a wireless communication system, the method comprising: sending (1034), to a Network Repository Function, NRF, in the core network, a discovery request for discovery of a Network Exposure Function, NEF, that manages one or more Packet Flow Descriptions, PFDs, for a particular application, for a particular application function, or for a particular application provided by a particular application function, the discovery request comprising one or more requested identifiers comprising an application identifier of the particular application, an application function identifier of the particular application function, or both the application identifier of the particular application function and the application function identifier of the particular application; and receiving (1038), from the NRF, a response comprising one or more NEF identifiers of one or more NEFs that satisfy the discovery request. 15. The method of embodiment 14 further comprising: sending (1040), to a NEF identified by one of the one or more NEF identifiers, a PFD management request comprising the application identifier of the particular application function, the application function identifier of the particular application, or both the application identifier of the particular application function and the application function identifier of the particular application; and receiving (1048), from the NEF, one or more PFDs that satisfy the PFD management request, wherein the one or more PFDs that satisfy the PFD management request comprise one or more PFDs managed by the NEF for the particular application associated with the application identifier comprised in the PFD management request, one or more PFDs managed by the NEF for the particular application function associated with the application function identifier comprised in the PFD management request, or one or more PFDs managed by the NEF for the particular application provided by the particular application associated with the application identifier and the application function identifier comprised in the PFD management request.
16. The method of embodiment 14 further comprising: sending, to a NEF identified by the one or more NEF identifiers, a subscription message comprising the application identifier of the particular application function, the application function identifier of the particular application, or both the application identifier of the particular application function and the application function identifier of the particular application; and receiving, from the NEF, a notification message comprising one or more PFDs that satisfy the subscription message, wherein the one or more PFDs that satisfy the subscription message comprise one or more PFDs managed by the NEF for the particular application associated with the application identifier comprised in the subscription message, one or more PFDs managed by the NEF for the particular application function associated with the application function identifier comprised in the subscription message, or one or more PFDs managed by the NEF for the particular application provided by the particular application associated with the application identifier and the application function identifier comprised in the subscription message
17. The method of embodiment 15 or 16 further comprising: providing (1050, 1054) the one or more received PFDs to one or more other core network functions.
18. A Session Management Function, SMF, for a core network of a wireless communication system, the SMF adapted to perform the method of any one of embodiments 14 to 17.
19. A network node that implements a Session Management Function, SMF, for a core network of a wireless communication system, the network node comprising: a network interface (1108, 1208); and processing circuitry (1104, 1204) associated with the network interface (1108, 1208), the processing circuitry
(1104, 1204) configured to cause the network node to perform the method of any one of embodiments 14 to 17.
20. A method in a core network of a wireless communication system, the method comprising:
• at a Network Exposure Function, NEF, in the core network: o receiving (1002), from an application function, one or more Packet Flow Descriptions, PFDs, for one or more applications; o causing (1006) the one or more PFDs to be stored in the core network in association with one or more application identifiers associated with the one or more applications, in association with an application function identifier associated with the application function, or both one or more application identifiers associated with the one or more applications and an application function identifier associated with the application function; and o providing (1014), to a Network Repository Function, NRF, in the core network, information comprising the one or more application identifiers associated with the one or more applications, the application function identifier associated with the application function, or both the one or more application identifiers associated with the one or more applications and the application function identifier associated with the application function; and
• at the NRF: o receiving (1014) the information from the NEF; and o storing (1016) the information.
21 . The method of embodiment 20 further comprising:
• at a Session Management Function, SMF, in the core network: o sending (1034), to the NRF, a discovery request comprising one or more requested identifiers, the one or more requested identifiers comprising one of the one or more application identifiers associated with the one or more PFDs managed by the NEF, the application function identifier associated with the one or more PFDs managed by the NEF, or both the one of the one or more application identifiers associated with the one or more PFDs managed by the NEF and the application function identifier associated with the one or more PFDs managed by the NEF;
• at the NRF: o receiving (1034) the discovery request from the SMF; o selecting (1036) the NEF as one of one or more NEFs that satisfy the discovery request based on the stored information; and o sending (1038), to the SMF, a response comprising one or more identifiers of the one or more NEFs that satisfy the discovery request; and • at the SMF: o receiving (1038) the response comprising the one or more identifiers of the one or more NEFs that satisfy the discovery request.
Abbreviations
[0080] At least some of the following abbreviations may be used in this disclosure. If there is an inconsistency between abbreviations, preference should be given to how it is used above. If listed multiple times below, the first listing should be preferred over any subsequent listing(s).
3GPP Third Generation Partnership Project
5G Fifth Generation
5GC Fifth Generation Core
5GS Fifth Generation System
AF Application Function
AMF Access and Mobility Function
AN Access Network
ASP Application Service Provider
AUSF Authentication Server Function
DN Data Network eNB Enhanced or Evolved Node B
FAR Forwarding Action Rule gNB New Radio Base Station
HSS Home Subscriber Server
HTTP Hypertext Transfer Protocol
ID Identifier
IP Internet Protocol
LTE Long Term Evolution
MME Mobility Management Entity
MTC Machine Type Communication
NEF Network Exposure Function
NF Network Function
NR New Radio
NRF Network Repository Function
NSSF Network Slice Selection Function
PCC Policy and Charging Control
PCF Policy Control Function
PDI Packet Detection Information
PDR Packet Detection Rule PFCP Packet Forwarding Control Protocol
PFD Packet Flow Description
PFDF Packet Flow Description Function
P-GW Packet Data Network Gateway
PLMN Public Land Mobile Network
QER Quality of Service Enforcement Rule
QoS Quality of Service
RAN Radio Access Network
SCEF Service Capability Exposure Function
SM Session Management
SMF Session Management Function
TS Technical Specification
UDM Unified Data Management
UDR User Data Repository
UE User Equipment
UPF User Plane Function
URR Usage Report Rule
[0081] Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein.

Claims

Claims
1. A method of operation of a Network Exposure Function, NEF, in a core network of a wireless communication system, the method comprising: receiving (1002), from an application function, one or more Packet Flow Descriptions, PFDs, for one or more applications; causing (1006) the one or more PFDs to be stored in the core network in association with one or more application identifiers associated with the one or more applications, in association with an application function identifier associated with the application function, or both one or more application identifiers associated with the one or more applications and an application function identifier associated with the application function; and providing (1014), to a Network Repository Function, NRF, in the core network, the one or more application identifiers associated with the one or more applications, the application function identifier associated with the application function, or both the one or more application identifiers associated with the one or more applications and the application function identifier associated with the application function.
2. The method of claim 1 wherein the application function is an Application Service Provider, ASP, and the one or more applications are one or more applications provided by the ASP.
3. The method of claim 2 wherein the one or more applications comprise a first application and a second application, and the one or more PFDs comprise one or more first PFDs for the first application and one or more second PFDs for the second application.
4. The method of claim 3 wherein causing (1006) the one or more PFDs to be stored in the core network comprises: causing the one or more first PFDs to be stored in the core network in association with a first application identifier of the first application, a network identifier of the ASP, or both the first application identifier of the first application and the network identifier of the ASP; and causing the one or more second PFDs to be stored in the core network in association with a second application identifier of the second application, the network identifier of the ASP, or both the second application identifier of the second application and the network identifier of the ASP.
5. The method of any one of claims 1 to 4 further comprising: updating (1012) a Network Function, NF, profile of the NEF to include the one or more application identifiers in a list of application identifiers of PFDs managed by the NEF, to include the application function identifier of the application function in a list of application function identifiers of PFDs managed by the NEF, or to include both the one or more application identifiers in the list of application identifiers of PFDs managed by the NEF and the application function identifier of the application function in the list of application function identifiers of PFDs managed by the NEF; wherein causing (1006) the one or more PFDs to be stored in the core network comprises causing (1006) the updated NF profile of the NEF to be stored in the core network.
6. The method of any one of claims 1 to 5 further comprising: receiving (1040), from a Session Management Function, SMF, in the core network, a PFD management request comprising one or more requested identifiers, the one or more requested identifiers being one of the one or more application identifiers, the application function identifier, or both the one of the one or more application identifiers and the application function identifier; obtaining (1042, 1046) a set of PFDs associated with the one or more requested identifiers; and providing (1048), to the SMF, a response comprising the set of PFDs associated with the one or more requested identifiers.
7. The method of any one of claims 1 to 5 further comprising: receiving, from a Session Management Function, SMF, in the core network, a subscription message comprising one or more subscribed identifiers, the one or more subscribed identifiers comprising one of the one or more application identifiers, the application function identifier, or both the one of the one or more application identifiers and the application function identifier; obtaining a set of PFDs associated with the one or more requested identifiers; and providing, to the SMF, a notification message comprising the set of PFDs associated with the one or more requested identifiers.
8. A Network Exposure Function, NEF, for a core network of a wireless communication system, the NEF adapted to perform the method of any one of claims 1 to 7.
9. A network node that implements a Network Exposure Function, NEF, for a core network of a wireless communication system, the network node comprising: a network interface (1108, 1208); and processing circuitry (1104, 1204) associated with the network interface (1108, 1208), the processing circuitry (1104, 1204) configured to cause the network node to perform the method of any one of claims 1 to 7.
10. A method of operation of a Network Repository Function, NRF, in a core network of a wireless communication system, the method comprising: receiving (1014), from a Network Exposure Function, NEF, in the core network, information comprising one or more application identifiers associated with one or more Packet Flow Descriptions, PFDs, managed by the NEF, one or more application function identifiers associated with the one or more PFDs managed by the NEF, or both the one or more application identifiers associated with the one or more PFDs managed by the NEF and the one or more application function identifiers associated with the one or more PFDs managed by the NEF; and storing (1016) the information.
11 . The method of claim 10 further comprising: receiving (1034), from a Session Management Function, SMF, in the core network, a discovery request comprising one or more requested identifiers, the one or more requested identifiers comprising one of the one or more application identifiers associated with the one or more PFDs managed by the NEF, the application function identifier associated with the one or more PFDs managed by the NEF, or both the one of the one or more application identifiers associated with the one or more PFDs managed by the NEF and the application function identifier associated with the one or more PFDs managed by the NEF; selecting (1036) the NEF as one of one or more NEFs that satisfy the discovery request based on the stored information; and sending (1038), to the SMF, a response comprising one or more identifiers of the one or more NEFs that satisfy the discovery request.
12. A Network Repository Function, NRF, for a core network of a wireless communication system, the NRF adapted to perform the method of any one of claims 10 to 11.
13. A network node that implements a Network Repository Function, NRF, for a core network of a wireless communication system, the network node comprising: a network interface (1108, 1208); and processing circuitry (1104, 1204) associated with the network interface (1108, 1208), the processing circuitry (1104, 1204) configured to cause the network node to perform the method of any one of claims 10 to 11 .
14. A method of operation of a Session Management Function, SMF, in a core network of a wireless communication system, the method comprising: sending (1034), to a Network Repository Function, NRF, in the core network, a discovery request for discovery of a Network Exposure Function, NEF, that manages one or more Packet Flow Descriptions, PFDs, for a particular application, for a particular application function, or for a particular application provided by a particular application function, the discovery request comprising one or more requested identifiers comprising an application identifier of the particular application, an application function identifier of the particular application function, or both the application identifier of the particular application function and the application function identifier of the particular application; and receiving (1038), from the NRF, a response comprising one or more NEF identifiers of one or more NEFs that satisfy the discovery request.
15. The method of claim 14 further comprising: sending (1040), to a NEF identified by one of the one or more NEF identifiers, a PFD management request comprising the application identifier of the particular application function, the application function identifier of the particular application, or both the application identifier of the particular application function and the application function identifier of the particular application; and receiving (1048), from the NEF, one or more PFDs that satisfy the PFD management request, wherein the one or more PFDs that satisfy the PFD management request comprise one or more PFDs managed by the NEF for the particular application associated with the application identifier comprised in the PFD management request, one or more PFDs managed by the NEF for the particular application function associated with the application function identifier comprised in the PFD management request, or one or more PFDs managed by the NEF for the particular application provided by the particular application associated with the application identifier and the application function identifier comprised in the PFD management request.
16. The method of claim 14 further comprising: sending, to a NEF identified by the one or more NEF identifiers, a subscription message comprising the application identifier of the particular application function, the application function identifier of the particular application, or both the application identifier of the particular application function and the application function identifier of the particular application; and receiving, from the NEF, a notification message comprising one or more PFDs that satisfy the subscription message, wherein the one or more PFDs that satisfy the subscription message comprise one or more PFDs managed by the NEF for the particular application associated with the application identifier comprised in the subscription message, one or more PFDs managed by the NEF for the particular application function associated with the application function identifier comprised in the subscription message, or one or more PFDs managed by the NEF for the particular application provided by the particular application associated with the application identifier and the application function identifier comprised in the subscription message.
17. The method of claim 15 or 16 further comprising: providing (1050, 1054) the one or more received PFDs to one or more other core network functions.
18. A Session Management Function, SMF, for a core network of a wireless communication system, the SMF adapted to perform the method of any one of claims 14 to 17.
19. A network node that implements a Session Management Function, SMF, for a core network of a wireless communication system, the network node comprising: a network interface (1108, 1208); and processing circuitry (1104, 1204) associated with the network interface (1108, 1208), the processing circuitry (1104, 1204) configured to cause the network node to perform the method of any one of claims 14 to 17.
20. A method in a core network of a wireless communication system, the method comprising:
• at a Network Exposure Function, NEF, in the core network: o receiving (1002), from an application function, one or more Packet Flow Descriptions, PFDs, for one or more applications; o causing (1006) the one or more PFDs to be stored in the core network in association with one or more application identifiers associated with the one or more applications, in association with an application function identifier associated with the application function, or both one or more application identifiers associated with the one or more applications and an application function identifier associated with the application function; and o providing (1014), to a Network Repository Function, NRF, in the core network, information comprising the one or more application identifiers associated with the one or more applications, the application function identifier associated with the application function, or both the one or more application identifiers associated with the one or more applications and the application function identifier associated with the application function; and
• at the NRF: o receiving (1014) the information from the NEF; and o storing (1016) the information.
21 . The method of claim 20 further comprising:
• at a Session Management Function, SMF, in the core network: o sending (1034), to the NRF, a discovery request comprising one or more requested identifiers, the one or more requested identifiers comprising one of the one or more application identifiers associated with the one or more PFDs managed by the NEF, the application function identifier associated with the one or more PFDs managed by the NEF, or both the one of the one or more application identifiers associated with the one or more PFDs managed by the NEF and the application function identifier associated with the one or more PFDs managed by the NEF; • at the NRF: o receiving (1034) the discovery request from the SMF; o selecting (1036) the NEF as one of one or more NEFs that satisfy the discovery request based on the stored information; and o sending (1038), to the SMF, a response comprising one or more identifiers of the one or more NEFs that satisfy the discovery request; and
• at the SMF: o receiving (1038) the response comprising the one or more identifiers of the one or more NEFs that satisfy the discovery request.
PCT/EP2020/072510 2019-08-13 2020-08-11 Mechanism for nef discovery relative to pfd management WO2021028435A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP20754741.5A EP3881496A1 (en) 2019-08-13 2020-08-11 Mechanism for nef discovery relative to pfd management

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CNPCT/CN2019/100440 2019-08-13
CN2019100440 2019-08-13

Publications (1)

Publication Number Publication Date
WO2021028435A1 true WO2021028435A1 (en) 2021-02-18

Family

ID=72050877

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2020/072510 WO2021028435A1 (en) 2019-08-13 2020-08-11 Mechanism for nef discovery relative to pfd management

Country Status (2)

Country Link
EP (1) EP3881496A1 (en)
WO (1) WO2021028435A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022174921A1 (en) * 2021-02-19 2022-08-25 Lenovo (Singapore) Pte. Ltd. Updating an application data set with n6-lan steering information
WO2023094009A1 (en) * 2021-11-29 2023-06-01 Nokia Technologies Oy Method, apparatus and computer program

Non-Patent Citations (19)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3 (Release 15)", 20 May 2019 (2019-05-20), XP051726068, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/Email%5FDiscussions/CT4/CT84/Draft/draft%2D29510%2Dg00%2Ezip> [retrieved on 20190520] *
"3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Packet Flow Description Management Service; Stage 3 (Release 16)", 3GPP STANDARD; TECHNICAL SPECIFICATION; 3GPP TS 29.551, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. CT WG3, no. V16.1.0, 18 June 2019 (2019-06-18), pages 1 - 30, XP051754254 *
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Policy and Charging Control Framework for the 5G System; Stage 2 (Release 16)", 3GPP STANDARD; TECHNICAL SPECIFICATION; 3GPP TS 23.503, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG2, no. V16.1.0, 11 June 2019 (2019-06-11), pages 1 - 99, XP051753961 *
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System Architecture for the 5G System; Stage 2 (Release 16)", vol. SA WG2, 11 July 2019 (2019-07-11), XP051756434, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/Latest_SA2_Specs/DRAFT_INTERIM/DRAFT_23501-g20_CRs_Implemented.zip> [retrieved on 20190711] *
3GPP TECHNICAL SPECIFICATION (TS) 29.510
3GPP TS 23.502
3GPP TS 23.502 V16.1.0
3GPP TS 23.503 V16.1.0
3GPP TS 29.501
3GPP TS 29.510 V16.0.0
3GPP TS 29.513 V16.0.0
3GPP TS 29.519
3GPP TS 29.551
3GPP TS 29.571
3GPP) TECHNICAL SPECIFICATION (TS) 29.510
3GPP) TECHNICAL SPECIFICATION (TS) 29.513 V16.0.0
ERICSSON: "NEF discovery information for PFD", vol. CT WG3, no. Wroclaw, Poland; 20190826 - 20190830, 16 August 2019 (2019-08-16), XP051764211, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_93_Wroclaw/Docs/C4-193404.zip> [retrieved on 20190816] *
TS 23.501
TS 29.510

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022174921A1 (en) * 2021-02-19 2022-08-25 Lenovo (Singapore) Pte. Ltd. Updating an application data set with n6-lan steering information
WO2023094009A1 (en) * 2021-11-29 2023-06-01 Nokia Technologies Oy Method, apparatus and computer program

Also Published As

Publication number Publication date
EP3881496A1 (en) 2021-09-22

Similar Documents

Publication Publication Date Title
US11797359B2 (en) Report application programming interface (API) capability change based on API filter
US11683384B2 (en) Notifications for a subscription to network function (service) profile change
EP4101188A1 (en) Extension of npcf_eventexposure with usage monitoring event
US20210274472A1 (en) Dynamic rsfp
US11902838B2 (en) Transferring monitoring event information during a mobility procedure
WO2021094236A1 (en) Service based interface (sbi) policy control function (pcf) initiated application session context for time sensitive networking (tsn) networks
WO2021234639A1 (en) Dynamic tsc service provision
WO2022097098A1 (en) Core network becoming aware of plmns with disaster conditions
EP3881496A1 (en) Mechanism for nef discovery relative to pfd management
WO2022151967A1 (en) Methods, network nodes, and computer readable media for dynamically discovering serving network node in core network
US20230104162A1 (en) Using dnai to identify a smf supporting connection to a local dn
US20220286953A1 (en) Slice selection subscription data enhancement
WO2022069989A1 (en) Ensuring network control of simultaneous access to network slices with application awareness
WO2021064211A1 (en) Enhanced pfcp association procedure for session restoration
WO2024095244A1 (en) Enforcing the af requested coverage area within ue&#39;s registration area for time sensitive communication and time synchronization services
WO2023135572A1 (en) Dynamic retrieval of nsac information
WO2023180960A1 (en) Enabling time synchronization and time resiliency service via subscription
WO2023175445A1 (en) Centralized counting in multi service areas
WO2023062548A1 (en) Network slice admission control function (nsacf) triggered ue deregistration
WO2022214395A1 (en) Enhancement on upf selection via nrf

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20754741

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2020754741

Country of ref document: EP

Effective date: 20210614

NENP Non-entry into the national phase

Ref country code: DE