Patent Description:
Third Generation Partnership Project (3GPP) has developed NetLoc, which is a feature to make the Network Provided Location Information (NPLI) related to the access network that the user equipment (UE) is camped on available to the internet protocol (IP) multimedia system (IMS) nodes whenever the IMS operator needs to record this information (e.g., to fulfil legal obligations such as a regulation requiring logging call information together with UE Location), for charging purposes or because of other application specific requirements.

Clause <NUM> describes an example of an application request of network provided location information (there are other IMS/SDP (session description protocol) interactions where the P-CSCF (proxy-call session control function) requests NPLI). Clause <NUM> describes how the policy control function (PCF) then requests NPLI to the session management function (SMF) (or SMF+PGW (Packet data network (PDN) GateWay). Clauses <NUM> and <NUM> describe how the PCF gets the NPLI from the access network. Relevant text for these procedures is set forth below.

<FIG> illustrates conventional policy and charging control (PCC) Procedures for IMS Session Establishment at an originating P-CSCF and a PCF. In <FIG>, the P-CSCF derives the provisioning of service information to the PCF from the SDP offer/answer exchange. <FIG> illustrates the following steps:
Step <NUM>. The P-CSCF receives the SDP parameters defined by the originator within an SDP offer in session initiation protocol (SIP) signalling.

Step <NUM>. The P-CSCF identifies and defines the (downlink) connection information needed (IP address of the downlink IP flow(s), port numbers to be used, etc.).

Step <NUM>. The P-CSCF forwards the SDP offer in SIP signalling.

Step <NUM>. The P-CSCF gets the negotiated SDP parameters from the terminating side through an SIP signalling interaction within an SDP answer.

Step <NUM>. The P-CSCF identifies the (uplink) connection information needed (IP address of the uplink media IP flow(s), port numbers to be used, etc.).

Step <NUM>. The P-CSCF invokes or requests the Npcf_PolicyAuthorization_Create service operation to forward the derived session information to the PCF by sending an HTTP POST request to the "Application Sessions" resource.

Step <NUM>. (Rx case) The P-CSCF provides session information to the PCF by sending a Diameter authentication and authorization request (AAR) for a new Rx Diameter session.

In these steps (<NUM>, <NUM>), the P-CSCF may also request the report of network provided location information (NPLI).

Step <NUM>. The PCF stores application session information and performs session binding and/or identifies a protocol data unit (PDU) session. For an N5 interface, the PCF creates an "Individual Application Session Context" resource to store the received application session information.

Step <NUM>. The PCF replies to the P-CSCF with an HTTP "<NUM> Created" (e.g., Npcf_PolicyAuthorization_Create) response and includes the uniform resource identifier (URI) of the "Individual Application Session Context" resource in the Location header field.

Step <NUM>. (Rx case) The PCF sends a Diameter authentication, authorization, and accounting (AAA) to the P-CSCF.

Step <NUM>. Upon reception of the acknowledgement from the PCF, the SDP parameters are passed to the UE in SIP signalling.

Step <NUM>. The PCF executes interactions according to <FIG>. This step implies provisioning of PCC rules and is executed in parallel with steps <NUM> and <NUM> (steps <NUM> and <NUM> for Rx case). The provisioning of PCC rules, if requested by the P-CSCF in step <NUM> (step <NUM> for Rx case), shall include the request of reporting network provided location information (NPLI).

Step <NUM>. If the P-CSCF requested access network information in step <NUM>, the PCF invokes the Npcf_PolicyAuthorization_Notify service operation to forward the access network information received in step <NUM> in an HTTP POST request sent to the Notification URI received in step <NUM>.

Step <NUM>. If step <NUM> occurs, the P-CSCF acknowledges the receipt of the notification request with an HTTP "<NUM> No Content" (e.g., Npcf_PolicyAuthorization_Notify) response to the PCF.

Step <NUM>. (Rx case) If the P-CSCF requested access network information in step <NUM>, the PCF forwards the access network information received in step <NUM> in a Diameter re-authorization request (RAR).

Step <NUM>. (Rx case) If step <NUM> occurs, the P-CSCF acknowledges the receipt of the Diameter RAR through a Diameter Re-authorization Acknowledgment (RAA).

Step <NUM>. If step <NUM> occurs (step <NUM> for Rx case), the P-CSCF forwards the access network information as the NPLI when a suitable SIP message is received.

<FIG> illustrates conventional interactions between a PCF and a SMF for PCF-initiated session management (SM) Policy Association Modification procedures. This procedure is performed when the PCF decides to modify the PDU session (updating PCC rules) due to the P-CSCF provisioning of service information.

Step <NUM>. The PCF receives a P-CSCF request to provision service information, as described in <FIG>, step <NUM> (step <NUM> for Rx case), that triggers the re-evaluation of the PCC rule information to install in the SMF (or SMF+PGW).

Step <NUM>. The PCF binds the P-CSCF request with an SM Policy Context (a PDU Session), and determines that a network initiated PDU session modification procedure is required. New PCC rules, requesting the report of access network information (NPLI), are installed in the SMF.

Step <NUM>. The PCF invokes the Npcf_SMPolicyControl_UpdateNotify service operation by sending the HTTP POST request with "{Notification URI}/update" as the resource URI to the SMF that has previously subscribed. The request operation provides the PDU session identification (ID) and the updated PCC rules, as described in subclause <NUM>. <NUM> of 3GPP TS <NUM>.

Step <NUM>. The SMF sends an HTTP "<NUM> OK" (e.g., an Npcf_SMPolicyControl_UpdateNotify Response) to the PCF to acknowledge the installation of the PCC rules. The SMF initiates the PDU session modification procedures towards the access and mobility management function (AMF) (or the S-GW/ePDG in case the UE is connected to a <NUM> Access network). As part of this PDU session modification request, the SMF requests NPLI.

Step <NUM>. When the SMF receives the available NPLI (UE Location and/or UE Time Zone), the SMF reports it to the PCF invoking the Npcf_SMPolicyControl_Update service operation by sending the HTTP POST request with request URI for the Individual SM Policy Context resource URI and an HTTP body including the UE Location and/or UE Time Zone as described in subclause <NUM>. <NUM> of 3GPP TS <NUM>.

Step <NUM>. The PCF sends to the SMF an HTTP "<NUM> OK" (e.g., an Npcf_SMPolicyControl_UpdateResponse) to acknowledge the report and continues with step <NUM> of <FIG>.

To support charging data collection and to fulfill regulatory requirements (e.g., to provide NPLI as defined in TS <NUM> [<NUM>]) related with the set-up, modification, and release of IMS Voice calls or with SMS transfer the following applies for the cases where the UE is accessing via a <NUM> Network:.

The User Location Information, the access type and the UE Time Zone may be further provided by the SMF to the PCF if the PCF has requested so (see clause <NUM> and clause <NUM> above). The PCF may get this information from the SMF to provide NPLI to applications (such as IP multimedia subsystem (IMS)) that have requested it.

3GPP TS <NUM> V16. <NUM> provides the stage <NUM> specification of the Session Management Policy Control Service of <NUM> system.

3GPP TS <NUM> V16. <NUM> defines the stage <NUM> system architecture for the <NUM> system.

3GPP TS <NUM> V15. <NUM> provides the stage <NUM> definition of the Policy Authorization Service of the <NUM> System.

The claimed subject-matter is defined by methods according to claims <NUM> and <NUM>, a Session Management Function according to claim <NUM>, and an Application Function according to claim <NUM>.

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 (PGW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), or the like. Some other examples of a core network node include a node implementing a Access and Mobility Management Function (AMF), a 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) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.

There currently exist certain challenge(s) when an application function (AF) requests network information. According to current procedures, whenever the AF needs network provided location information (NPLI) for specific reasons, the AF subscribes to be informed about NPLI: either location information or time zone, or both, depending on the purpose. Additionally, the AF may subscribe to receive information about radio access type (RAT) type/Access Type changes in the policy control function (PCF), if this information is relevant for the AF to request this specific information.

As the functionality is defined today, it is possible that not all the access information is available in the access network.

When the NetLoc feature is not supported by the session management function (SMF) or the PCF, the AF receives information that the Access Report is not supported.

With this state of the art the following limitations exist:.

Certain aspects of the present disclosure and their embodiments may provide solutions to the aforementioned or other challenges. The present disclosure proposes a solution with the following functionality: when the Access Network does not support part of the information required by the AF (e.g., time zone), the SMF will indicate to the PCF that this specific information is not supported and the PCF will indicate so to the AF. As such, the present disclosure provides the following:.

There are, proposed herein, various embodiments which address one or more of the issues disclosed herein. Certain embodiments may provide one or more of the following technical advantage(s):.

Before addressing particular embodiments of the present disclosure, a general overview of a cellular communications system is provided with reference to <FIG>. In this regard, <FIG> illustrates one example of a cellular communications system <NUM> in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communications system <NUM> is a <NUM> system (5GS) including a new radio (NR) radio access node (RAN) (NR RAN) or long term evolution (LTE) RAN (i.e., E-UTRA RAN) or an Evolved Packet System (EPS) including an LTE RAN. In this example, the RAN includes base stations <NUM>-<NUM> and <NUM>-<NUM>, which in LTE are referred to as enhanced node Bs (eNBs) (when connected to an evolved packet core (EPC)) and in <NUM> NR are referred to as gNBs (e.g., LTE RAN nodes connected to 5GC, which are referred to as gn-eNBs), controlling corresponding (macro) cells <NUM>-<NUM> and <NUM>-<NUM>. The base stations <NUM>-<NUM> and <NUM>-<NUM> are generally referred to herein collectively as base stations <NUM> and individually as base station <NUM>. Likewise, the (macro) cells <NUM>-<NUM> and <NUM>-<NUM> are generally referred to herein collectively as (macro) cells <NUM> and individually as (macro) cell <NUM>. The RAN may also include a number of low power nodes <NUM>-<NUM> through <NUM>-<NUM> controlling corresponding small cells <NUM>-<NUM> through <NUM>-<NUM>. The low power nodes <NUM>-<NUM> through <NUM>-<NUM> 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 <NUM>-<NUM> through <NUM>-<NUM> may alternatively be provided by the base stations <NUM>. The low power nodes <NUM>-<NUM> through <NUM>-<NUM> are generally referred to herein collectively as low power nodes <NUM> and individually as low power node <NUM>. Likewise, the small cells <NUM>-<NUM> through <NUM>-<NUM> are generally referred to herein collectively as small cells <NUM> and individually as small cell <NUM>. The cellular communications system <NUM> also includes a core network <NUM>, which in the 5GS is referred to as the <NUM> core (5GC). The base stations <NUM> (and optionally the low power nodes <NUM>) are connected to the core network <NUM>.

<FIG> illustrates a wireless communication system represented as a <NUM> network architecture composed of core Network Functions (NFs), where interaction between any two NFs is represented by a point-to-point reference point/interface. <FIG> can be viewed as one particular implementation of the core network <NUM> of the system <NUM> of <FIG>.

Seen from the access side, the <NUM> network architecture shown in <FIG> comprises a plurality of UEs <NUM> connected to either a RAN or an Access Network (AN) <NUM> as well as an AMF <NUM>. Typically, the (R)AN <NUM> comprises base stations, e.g., such as evolved Node Bs (eNBs) or NR base stations (gNBs) or similar. Seen from the core network side, the <NUM> core NFs shown in <FIG> include a Network Slice Selection Function (NSSF) <NUM>, an Authentication Server Function (AUSF) <NUM>, a Unified Data Management (UDM) <NUM>, the AMF <NUM>, a Session Management Function (SMF) <NUM>, a Policy Control Function (PCF) <NUM>, and an Application Function (AF) <NUM>.

Reference point representations of the <NUM> 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 <NUM> and AMF <NUM>. The reference points for connecting between the AN <NUM> and AMF <NUM> and between the AN <NUM> and user plane function (UPF) <NUM> are defined as N2 and N3, respectively. There is a reference point, N11, between the AMF <NUM> and SMF <NUM>, which implies that the SMF <NUM> is at least partly controlled by the AMF <NUM>. N4 is used by the SMF <NUM> and UPF <NUM> so that the UPF <NUM> can be set using the control signal generated by the SMF <NUM>, and the UPF <NUM> can report its state to the SMF <NUM>. N9 is the reference point for the connection between different UPFs <NUM>, and N14 is the reference point connecting between different AMFs <NUM>, respectively. N15 and N7 are defined since the PCF <NUM> applies policy to the AMF <NUM> and SMF <NUM>, respectively. N12 is required for the AMF <NUM> to perform authentication of the UE <NUM>. N8 and N10 are defined because the subscription data of the UE <NUM> is required for the AMF <NUM> and SMF <NUM>. N6 is defined between the UPF <NUM> and a data network (DN) <NUM>.

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

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

The user plane supports interactions such as forwarding operations between different UPFs <NUM>.

<FIG> illustrates a <NUM> network architecture <NUM> using service-based interfaces between the NFs in the control plane, instead of the point-to-point reference points/interfaces used in the <NUM> network architecture of <FIG>. However, the NFs described above with reference to <FIG> correspond to the NFs shown in <FIG>. 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 <FIG> 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, Nsmf for the service based interface of the SMF, etc. The Network Exposure Function (NEF) <NUM> and the Network Function (NF) Repository Function (NRF) <NUM> in <FIG> are not shown in <FIG> discussed above. However, it should be clarified that all NFs depicted in <FIG> can interact with the NEF <NUM> and the NRF <NUM> of <FIG> as necessary, though not explicitly indicated in <FIG>.

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

<FIG> illustrates an exemplary method for partial access of network information according to some embodiments of the present disclosure. In the embodiment illustrated in <FIG>, an Application Function (AF) <NUM> seeks Access Network (AN) information that is not supported by the AN <NUM>, resulting in the following steps:
Step <NUM>. The AF <NUM> sends a request for AN information to a PCF <NUM>. In this example, the AF <NUM> requests timezone information, e.g., for a particular UE <NUM>.

Step <NUM>. The PCF <NUM> forwards the request to an SMF <NUM>.

Step <NUM>. The SMF <NUM> determines that the AN <NUM> does not support reporting of timezone information. The SMF <NUM> may know this deficiency in advance, or it may query the AN <NUM> or a core network node that maintains this information to determine this deficiency.

Step <NUM>. The SMF <NUM> notifies the PCF <NUM> that the AN <NUM> does not support reporting of timezone information. In some embodiments, the netLocAccSupp attribute is set to "TZR_NOT_SUPPORTED.

Step <NUM>. The PCF <NUM> forwards that message to the AF <NUM>. In this manner, the AF <NUM> is notified that the AN <NUM> does not support reporting timezone information. This can prevent the AF <NUM> from making false assumptions about the UE's timezone.

The same principle can be applied to any type of AN information that the AF <NUM> may request, as shown by the next sequence of messages:
Step <NUM>. The AF <NUM> sends another request to the PCF <NUM>, this time for AN information other than the timezone. This "other AN information" is represented generically as "<AN information>" in <FIG>.

Step <NUM>. The PCF <NUM> forwards the request for <AN information> to the SMF <NUM>.

Step <NUM>. The SMF <NUM> determines that the AN <NUM> does not support reporting of this specific <AN information>. The SMF <NUM> may know this deficiency in advance, or it may query the AN <NUM> or a core network node that maintains this information to determine this deficiency.

Step <NUM>. The SMF <NUM> notifies the PCF <NUM> that the AN <NUM> does not support reporting of <AN information>.

Step <NUM>. The PCF <NUM> forwards that message to the AF <NUM>. In this manner, the AF <NUM> is notified that the AN <NUM> does not support reporting of <AN information>.

<FIG> illustrates an exemplary method for partial access of network information according to some embodiments of the present disclosure. In the embodiment illustrated in <FIG>, an AF <NUM> seeks AN information that is supported by the AN <NUM>, resulting in the following steps:
Step <NUM>. The AF <NUM> sends a request for AN information to a PCF <NUM>. In this example, the AF <NUM> requests timezone information, e.g., for a particular UE <NUM>.

Step <NUM>. The SMF <NUM> determines that the AN <NUM> supports reporting of timezone information. The SMF <NUM> may know this functionality in advance, or it may query the AN <NUM> or a core network node that maintains this information to determine this functionality.

Step <NUM>. The SMF <NUM> sends a request for timezone information to the AN <NUM>.

Step <NUM>. The SMF <NUM> receives the timezone information from the AN <NUM>.

Step <NUM>. The SMF <NUM> forwards the timezone information to the PCF <NUM>, e.g., via the "ueTimeZone" parameter.

Step <NUM>. The PCF <NUM> forwards the timezone information to the AF <NUM>.

The steps illustrated in <FIG> and <FIG> are not currently described in existing 3GPP standards. Thus improvements with regards to the current functionality in the interface between the PCF and the SMF that could be made to the existing standards are possible and set forth below:.

If the NetLoc functionality is supported by both the SMF <NUM> and PCF <NUM>, the PCF <NUM> may request the SMF <NUM> to report the access network information. If the AN_INFO policy control request trigger is set, upon receiving the "lastReqRuleData" attribute with the "reqData" attribute with the value(s) MS_TIME_ZONE and/or USER_LOC_INFO and the "refPccRuleIds" attribute containing the PCC rule identifier(s) corresponding to the PCC rule(s) which is being installed, modified, or removed together, the SMF <NUM>, in an exemplary aspect, shall check if the access network <NUM> supports the required information:.

It should be appreciated that non-support of access network reporting can occur in the interworking scenarios, when the SMF <NUM> corresponds to an SMF+PGW-C and the access network <NUM> does not support the reporting of timezone information (Non-3GPP Untrusted Access).

In an exemplary aspect, if access network reporting is supported, the SMF <NUM> shall apply the Namf_EventExposure service with One-Time Report type as defined in subclause <NUM>. <NUM> of 3GPP TS <NUM> [<NUM>] if the related information is not available to obtain this information. When the SMF <NUM> then receives access network information from the AMF <NUM>, the SMF <NUM> shall provide the required access network information to the PCF <NUM> by as defined in subclause <NUM>. <NUM> and set the corresponding attributes as follows:.

In addition, the SMF <NUM> shall provide the AN_INFO policy control request trigger within the "repPolicyCtrlReqTriggers" attribute.

The SMF <NUM> shall not report any subsequent access network information updates received from the RAN <NUM> without any further provisioning or removal of related PCC rules requesting the access network information unless the associated QoS flow or protocol data unit (PDU) session has been released.

This procedure is used by the PCF <NUM> to report the access network information (i.e., user location and/or user timezone information) to the AF <NUM> when the "NetLoc" feature is supported.

When the PCF <NUM> receives the access network information from the SMF <NUM>, the PCF shall include the "EventsNotification" data type in the body of the HTTP POST request message sent to the AF <NUM> as described in subclause <NUM>. <NUM> of TS <NUM>. The PCF <NUM> shall include in the "EventsNotification" data type:.

When the PCF <NUM> receives notification from the SMF <NUM> that the access network <NUM> does not support access network information report, the PCF <NUM> shall include the "netLocAccSupp" attribute set to "ANR_NOT_SUPPORTED" value in the "EventsNotification" data type in the body of the HTTP POST request message sent to the AF <NUM> as described in subclause <NUM>. <NUM> of TS <NUM>.

The PCF <NUM> shall also include an event of the "AfEventNotification" data type in the "evNotifs" attribute with the "event" attribute set to the value "ANI_REPORT. " Note that the PCF <NUM> receives the access network information from the SMF <NUM> if it is previously requested by the AF <NUM> or at PDU session termination or at the termination of all the service data flows of the AF session.

The PCF <NUM> shall not invoke the Npcf_PolicyAuthorization_Notify service operation with the "event" attribute set to the value "ANI_REPORT" to report to the AF <NUM> any subsequently received access network information, unless the AF <NUM> sends a new request for access network information.

Example embodiments of at least some aspects of the present disclosure are described below as changes to 3GPP TS <NUM> V15. Changes are indicated by underlining, strike-throughs, or by being otherwise noted.

This subclause specifies the application data model supported by the API. The Npcf_SMPolicyControl API allows the SMF to retrieve the session management related policy from the PCF as defined in 3GPP TS <NUM> [<NUM>]. Table <NUM>. <NUM>-<NUM> specifies the data types defined for the Npcf_SMPolicyControl service based interface protocol.

Table <NUM>. <NUM>-<NUM> specifies data types re-used by the Npcf_SMPolicyControl 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 Npcf_SMPolicyControl service based interface.

When the UE establishes the PDN connection through the EPC network and the SMF+PGW-C receives the Create Session Request message as defined in 3GPP TS <NUM> [<NUM>], the SMF+PGW-C shall behave as defined in subclause <NUM>. <NUM> with the differences that the SMF+PGW-C shall include (if available) in SmPolicyContextData data structure:.

If the NetLoc feature as defined in subclause <NUM> is supported, the PCF may request the SMF+PGW-C to report the access network information as defined in subclause <NUM>.

If the AN_INFO policy control request trigger is set, upon receiving the "lastReqRuleData" attribute with the "reqData" attribute with the value(s) MS_TIME_ZONE and/or USER_LOC_INFO and the "refPccRulelds" attribute containing the PCC rule identifier(s) corresponding to the PCC rule(s) being installed, modified or removed:.

Example embodiments of at least some aspects of the present disclosure are described below as changes to 3GPP TS <NUM> V16. Changes are indicated by underlining, strike-throughs, or by being otherwise noted.

This procedure is used by an AF to request the PCF to report the access network information (i.e., user location and/or user timezone information) at the creation of the "Individual Application Session Context" resource, when the "NetLoc" feature is supported.

The AF shall include in the HTTP POST request message described in subclause <NUM>.

When the PCF determines that the access network does not support the access network information reporting because the SMF does not support the NetLoc feature, the PCF shall respond to the AF including in the "EventsNotification" data type the "netLocAccSupp" attribute set to "ANR_NOT_SUPPORTED" value. Otherwise, the PCF shall immediately configure the SMF to provide such access information, as specified in 3GPP TS <NUM> [<NUM>].

The PCF shall reply to the AF with an HTTP response message as described in subclause <NUM>.

This procedure is used by an AF to request access network information for an existing "Individual Application Session Context" resource at service information modification when the "NetLoc" feature is supported. NOTE <NUM>: Subclause <NUM>. <NUM> describes the AF request of access network information without providing service information.

The AF shall create event subscription information by including in the "AppSessionContextUpdateData" data type the "evSubsc" attribute of "EventsSubscReqData" data type with the corresponding list of events to subscribe to. The AF shall include in the HTTP PATCH request message described in subclause <NUM>.

The PCF shall reply to the AF with an HTTP response message as described in subclause <NUM>. NOTE <NUM>: The AF does not invoke the Npcf_PolicyAuthorization_Update service operation to remove subscription to access network information report since the "Access Network Information Notification" is the one-time reported event. Once the access network information is reported to the AF the subscription to the access network information report is automatically terminated in the PCF and the related information is removed.

This procedure is used by an AF to request the PCF to report the access network information (i.e., user location and/or user timezone information) at the deletion of the "Individual Application Session Context" resource when the "NetLoc" feature is supported.

When the PCF receives the access network information from the SMF, the PCF shall provide the corresponding access network information to the AF by including the "EventsNotification" data type in the "<NUM> OK" response to the HTTP POST request. The PCF shall include:.

When the PCF receives from the SMF that the access network does not support access network information report, the PCF shall include the "netLocAccSupp" attribute set to "ANR_NOT_SUPPORTED" value in the "EventsNotification" data type in the "<NUM> OK" response to the HTTP POST request.

The PCF shall also include an event of the "AfEventNotification" data type in the "evNotifs" attribute with the "event" attribute set to the value "ANI_REPORT".

This procedure is used by the PCF to report the access network information (i.e., user location and/or user timezone information) to the AF when the "NetLoc" feature is supported.

When the PCF receives the access network information from the SMF, the PCF shall include the "EventsNotification" data type in the body of the HTTP POST request message sent to the AF as described in subclause <NUM>. The PCF shall include in the "EventsNotification" data type:.

When the PCF receives from the SMF that the access network does not support access network information report, the PCF shall include the "netLocAccSupp" attribute set to "ANR_NOT_SUPPORTED" value in the "EventsNotification" data type in the body of the HTTP POST request message sent to the AF as described in subclause <NUM>.

The PCF shall also include an event of the "AfEventNotification" data type in the "evNotifs" attribute with the "event" attribute set to the value "ANI_REPORT". NOTE: The PCF receives the access network information from the SMF if it is previously requested by the AF or at PDU session termination or at the termination of all the service data flows of the AF session.

The PCF shall not invoke the Npcf_PolicyAuthorization_Notify service operation with the "event" attribute set to the value "ANI_REPORT" to report to the AF any subsequently received access network information, unless the AF sends a new request for access network information.

This procedure is used by an AF to request the PCF to report the access network information (i.e., user location and/or user timezone information) without providing service information when the "NetLoc" feature is supported.

The AF can request access network information without providing service information:.

The AF shall include in the HTTP request message:.

The PCF shall reply to the AF with the HTTP POST response as described in subclause <NUM>. <NUM> and with the HTTP PUT response as described in subclause <NUM>.

This subclause specifies the application data model supported by the API.

Table <NUM>. <NUM>-<NUM> specifies the data types defined for the Npcf_PolicyAuthorization service based interface protocol.

Table <NUM>. <NUM>-<NUM> specifies data types re-used by the Npcf_PolicyAuthorization 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 Npcf_PolicyAuthorization service based interface.

<FIG> is a schematic block diagram of a network node <NUM> according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. The network node <NUM> may be, for example, a radio access node such as a base station <NUM> or <NUM> or other node that implements all or part of the functionality described herein. As illustrated, the network node <NUM> includes a control system <NUM> that includes one or more processors <NUM> (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory <NUM>, and a network interface <NUM>. The one or more processors <NUM> are also referred to herein as processing circuitry. In addition, the network node <NUM> may include one or more radio units <NUM> (if the network node <NUM> is a radio access node such as a base station <NUM>) that each includes one or more transmitters <NUM> and one or more receivers <NUM> coupled to one or more antennas <NUM>. The radio units <NUM> may be referred to or be part of radio interface circuitry. In some embodiments, the radio unit(s) <NUM> is external to the control system <NUM> and connected to the control system <NUM> via, e.g., a wired connection (e.g., an optical cable). However, in some other embodiments, the radio unit(s) <NUM> and potentially the antenna(s) <NUM> are integrated together with the control system <NUM>. The one or more processors <NUM> operate to provide one or more functions of a network node <NUM> as described herein. In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory <NUM> and executed by the one or more processors <NUM>.

<FIG> is a schematic block diagram that illustrates a virtualized embodiment of the network node <NUM> according to some embodiments of the present disclosure.

As used herein, a "virtualized" radio access node is an implementation of the network node <NUM> in which at least a portion of the functionality of the network node <NUM> 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 network node <NUM> may include the control system <NUM> and/or the one or more radio units <NUM> (if the node <NUM> is a radio access node), as described above. The control system <NUM> may be connected to the radio unit(s) <NUM> via, for example, an optical cable or the like. The network node <NUM> includes one or more processing nodes <NUM> coupled to or included as part of a network(s) <NUM>. If present, the control system <NUM> or the radio unit(s) are connected to the processing node(s) <NUM> via the network <NUM>. Each processing node <NUM> includes one or more processors <NUM> (e.g., CPUs, ASICs, FPGAs, and/or the like), memory <NUM>, and a network interface <NUM>.

In this example, functions <NUM> of the network node <NUM> described herein are implemented at the one or more processing nodes <NUM> or distributed across the one or more processing nodes <NUM> and the control system <NUM> and/or the radio unit(s) <NUM> in any desired manner. In some particular embodiments, some or all of the functions <NUM> of the network node <NUM> 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) <NUM>. As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s) <NUM> and the control system <NUM> is used in order to carry out at least some of the desired functions <NUM>. Notably, in some embodiments, the control system <NUM> may not be included, in which case the radio unit(s) <NUM> communicate directly with the processing node(s) <NUM> via an appropriate network interface(s).

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 network node <NUM> or a node (e.g., a processing node <NUM>) implementing one or more of the functions <NUM> of the network node <NUM> in a virtual environment according to any of the embodiments described herein is provided.

<FIG> is a schematic block diagram of the network node <NUM> according to some other embodiments of the present disclosure. The network node <NUM> includes one or more modules <NUM>, each of which is implemented in software. The module(s) <NUM> provide the functionality of network node <NUM> described herein.

Claim 1:
A method performed by a Session Management Function, SMF, (<NUM>) for providing Access Network, AN (<NUM>), information, the method comprising:
receiving (<NUM>) a request for AN information from a Policy Control Function, PCF, (<NUM>);
determining ( <NUM>) whether an AN (<NUM>) does not support reporting of AN information;
upon determining (<NUM>) that the AN (<NUM>) does not support reporting of AN information, sending (<NUM>), to the PCF (<NUM>), a first notification that the AN (<NUM>) does not support reporting of AN information, wherein the first notification comprises a UeCampingRep data structure having a netLocAccSupp attribute set to a first value, ANR_NOT_SUPPORTED, which indicates that the AN (<NUM>) does not support the report of AN information; upon determining that the AN (<NUM>) does support reporting of AN information:
if the requested AN information comprises User Equipment, UE, (<NUM>) timezone information, and if the SMF (<NUM>) determines (<NUM>) that the AN (<NUM>) does not support the report of the UE time zone, sending (<NUM>), to the PCF (<NUM>), a second notification, wherein the second notification comprises a UeCampingRep data structure having a netLocAccSupp attribute set to a second value, TZR_NOT_SUPPORTED, which indicates that the AN (<NUM>) does not support the report of UE time zone;
otherwise:
acquiring (<NUM>, <NUM>) the requested AN information; and
sending (<NUM>) the requested AN information to the PCF (<NUM>).