Patent Publication Number: US-2023146343-A1

Title: Partial support of access network information

Description:
RELATED APPLICATIONS 
     This application claims the benefit of U.S. provisional patent application Ser. No. 62/977,635, filed Feb. 17, 2020, the disclosure of which is hereby incorporated herein by reference in its entirety. 
    
    
     TECHNICAL FIELD 
     The present disclosure relates to provision of access network information to a requester in a network. 
     BACKGROUND 
     Signalling Flows for IMS, Request of NetLoc Information by the P-CSCF 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 1 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 2 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 2 and 3 describe how the PCF gets the NPLI from the access network. Relevant text for these procedures is set forth below. 
     Clause 1: Provisioning of Service Information at Originating P-CSCF and PCF 
       FIG.  1    illustrates conventional policy and charging control (PCC) Procedures for IMS Session Establishment at an originating P-CSCF and a PCF. In  FIG.  1   , the P-CSCF derives the provisioning of service information to the PCF from the SDP offer/answer exchange.  FIG.  1    illustrates the following steps: 
     Step  100 . The P-CSCF receives the SDP parameters defined by the originator within an SDP offer in session initiation protocol (SIP) signalling. 
     Step  102 . 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  104 . The P-CSCF forwards the SDP offer in SIP signalling. 
     Step  106 . The P-CSCF gets the negotiated SDP parameters from the terminating side through an SIP signalling interaction within an SDP answer. 
     Step  108 . 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  110 . 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  112 . (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 ( 110 ,  112 ), the P-CSCF may also request the report of network provided location information (NPLI). 
     Step  114 . 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  116 . The PCF replies to the P-CSCF with an HTTP “201 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  118 . (Rx case) The PCF sends a Diameter authentication, authorization, and accounting (AAA) to the P-CSCF. 
     Step  120 . Upon reception of the acknowledgement from the PCF, the SDP parameters are passed to the UE in SIP signalling. 
     Step  122 . The PCF executes interactions according to  FIG.  2   . This step implies provisioning of PCC rules and is executed in parallel with steps  124  and  126  (steps  128  and  130  for Rx case). The provisioning of PCC rules, if requested by the P-CSCF in step  110  (step  112  for Rx case), shall include the request of reporting network provided location information (NPLI). 
     Step  124 . If the P-CSCF requested access network information in step  110 , the PCF invokes the Npcf_PolicyAuthorization_Notify service operation to forward the access network information received in step  122  in an HTTP POST request sent to the Notification URI received in step  110 . 
     Step  126 . If step  124  occurs, the P-CSCF acknowledges the receipt of the notification request with an HTTP “204 No Content” (e.g., Npcf_PolicyAuthorization_Notify) response to the PCF. 
     Step  128 . (Rx case) If the P-CSCF requested access network information in step  112 , the PCF forwards the access network information received in step  122  in a Diameter re-authorization request (RAR). 
     Step  130 . (Rx case) If step  128  occurs, the P-CSCF acknowledges the receipt of the Diameter RAR through a Diameter Re-authorization Acknowledgment (RAA). 
     Step  132 . If step  124  occurs (step  128  for Rx case), the P-CSCF forwards the access network information as the NPLI when a suitable SIP message is received. 
     Clause 2: Provisioning of PCC Rules in the SMF (or SMF+PGW) 
       FIG.  2    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  200 . The PCF receives a P-CSCF request to provision service information, as described in  FIG.  1   , step  110  (step  112  for Rx case), that triggers the re-evaluation of the PCC rule information to install in the SMF (or SMF+PGW). 
     Step  202 . 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  204 . 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 4.2.3 of 3GPP TS 29.512. 
     Step  206 . The SMF sends an HTTP “200 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 4G Access network). As part of this PDU session modification request, the SMF requests NPLI. 
     Step  208 . 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 4.2.4.9 of 3GPP TS 29.512. 
     Step  210 . The PCF sends to the SMF an HTTP “200 OK” (e.g., an Npcf_SMPolicyControl_UpdateResponse) to acknowledge the report and continues with step  124  of  FIG.  1   . 
     Clause 3: Access Network Information Reporting in 5G Network 
     To support charging data collection and to fulfill regulatory requirements (e.g., to provide NPLI as defined in TS 23.228 [15]) 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 5G Network: 
     When an AMF forwards uplink (UL) non-access stratum (NAS) or N2 signalling to a peer network function (NF) (e.g., to an SMF or to a short message service function (SMSF)) or during the UP connection activation of a PDU Session, the AMF provides any User Location Information it has received from the 5G-access network (AN) as well as the Access Type (3GPP-Non 3GPP) of the AN over which it has received the UL NAS or N2 signalling. The AMF also provides the corresponding UE Time Zone. In addition, to fulfill regulatory requirements (e.g., providing NPLI, as defined in TS 23.228 [15]) when the access is non-3GPP, the AMF may also provide the last known 3GPP access User Location Information with its age, if the UE is still attached to the same AMF for 3GPP access (i.e., valid User Location Information). 
     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 1 and clause 2 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. 
     SUMMARY 
     Embodiments of a method performed by a Session Management Function (SMF) for providing Access Network (AN) information are disclosed. The method comprises receiving a request for AN information from a Policy Control Function (PCF). The method also comprises determining whether an AN does not support reporting of the requested AN information. The method also comprises, upon determining that the AN does not support reporting of the requested AN information, sending, to the PCF, a notification that the AN does not support reporting of the requested AN information. The method also comprises, upon determining that the AN does support reporting of the requested AN information, acquiring the requested AN information and sending the requested AN information to the PCF. 
     In one embodiment, sending the notification that the AN does not support the reporting of the requested AN information comprises sending a UeCampingRep data structure. In one embodiment, sending the notification that the AN does not support the reporting of the requested AN information comprises sending a UeCampingRep data structure having a netLocAccSupp attribute set to an ANR_NOT_SUPPORTED value. In one embodiment, the requested AN information comprises User Equipment (UE) location information or timezone information, and sending the notification that the AN does not support the reporting of the requested AN information comprises sending a UeCampingRep data structure having a netLocAccSupp attribute set to a TZR_NOT_SUPPORTED value. 
     Embodiments of a method performed by a PCF for providing AN information are also disclosed. The method comprises receiving a request for AN information from an Application Function (AF). The method also comprises forwarding the request to an SMF. The method also comprises receiving, from the SMF, a response to the request. The method also comprises forwarding the response to the AF. 
     In one embodiment, the response from the SMF comprises an indication that an AN does not support reporting the requested AN information. In one embodiment, the response from the SMF comprises a UeCampingRep data structure. In one embodiment, the UeCampingRep data structure comprises a netLocAccSupp attribute set to an ANR_NOT_SUPPORTED value. In one embodiment, the requested AN information comprises UE location information or timezone information and the UeCampingRep data structure comprises a netLocAccSupp attribute set to a TZR_NOT_SUPPORTED value. 
     Embodiments of a method performed by an AF for requesting AN information are disclosed. The method comprises sending a request for AN information to a PCF. The method also comprises receiving, from the PCF, a response to the request for AN information. The response includes the requested AN information or includes an indication that an AN does not support reporting the requested AN information. 
     In one embodiment, the response from the PCF comprises a UeCampingRep data structure. In one embodiment, the UeCampingRep data structure comprises a netLocAccSupp attribute set to an ANR_NOT_SUPPORTED value. In one embodiment, the requested AN information comprises UE location information or timezone information and the UeCampingRep data structure comprises a netLocAccSupp attribute set to a TZR_NOT_SUPPORTED value. 
     Embodiments of an SMF are also disclosed. The SMF is adapted to receive a request for AN information from a PCF. The SMF is also adapted to determine whether an AN does not support reporting of the requested AN information. The SMF is adapted to, upon determining that the AN does not support reporting of the requested AN information, send, to the PCF, a notification that the AN does not support reporting of the requested AN information. The SMF is also adapted to, upon determining that the AN does support reporting of the requested AN information, acquire the requested AN information, and send the requested AN information to the PCF. In one embodiment, the SMF is further adapted to perform any of the embodiments of the method performed by an SMF for providing AN information. 
     Embodiments of a PCF are also disclosed. The PCF is adapted to receive, from an AF, a request for AN information. The PCF is also adapted to forward the request to an SMF. The PCF is also adapted to receive, from the SMF, a response to the request. The PCF is also adapted to forward the response to the AF. In one embodiment, the PCF is further adapted to perform any of the embodiments of the method performed by a PCF for providing AN information. 
     Embodiment of an AF are also disclosed. The AF is adapted to send, to a PCF, a request for AN information. The AF is also adapted to received, from the PCF, a response to the request for AN information. The response includes the requested AN information or includes an indication that an AN does not support reporting of the requested AN information. In one embodiment, the AF is further adapted to perform any of the embodiments of the method performed by an AF for requesting AN information. 
     Embodiments of a network node for implementing an SMF are also disclosed. The network node comprises processing circuitry. The processing circuitry is configured to cause the network node to receive, from a PCF, a request for AN information. The processing circuitry is also configured to cause the network node to determine whether an AN does not support reporting of the requested AN information. The processing circuitry is also configured to cause the network node to, upon determining that the AN does not support reporting of the requested AN information, send, to the PCF, a notification that the AN does not support reporting of the requested AN information. 
     The processing circuitry is also configured to cause the network node to, upon determining that the AN does support reporting of the requested AN information, acquire the requested AN information, and send the requested AN information to the PCF. 
     In one embodiment, the processing circuitry configured to send the notification that the AN does not support the reporting of the requested AN information is further configured to send a UeCampingRep data structure. In one embodiment, the processing circuitry configured to send the notification that the AN does not support the reporting of the requested AN information is further configured to send a UeCampingRep data structure having a netLocAccSupp attribute set to an ANR_NOT_SUPPORTED value. In one embodiment, the requested AN information comprises UE location information or timezone information, and the processing circuitry configured to send the notification that the AN does not support the reporting of the requested AN information is further configured to send a UeCampingRep data structure having a netLocAccSupp attribute set to a TZR_NOT_SUPPORTED value. 
     Embodiments of a network node for implementing a PCF are also disclosed. The PCF comprises processing circuitry. The processing circuitry is configured to cause the network node to receive, from an AF, a request for AN information. The processing circuitry is also configured to cause the network node to forward the request to an SMF. The processing circuitry is also configured to cause the network node to receive, from the SMF, a response to the request. The processing circuitry is also configured to cause the network node to forward the response to the AF. 
     In one embodiment, the response from the SMF comprises an indication that an AN does not support reporting the requested AN information. In one embodiment, the response from the SMF comprises a UeCampingRep data structure. In one embodiment, the UeCampingRep data structure comprises a netLocAccSupp attribute set to an ANR_NOT_SUPPORTED value. In one embodiment, the requested AN information comprises UE location information or timezone information and the UeCampingRep data structure comprises a netLocAccSupp attribute set to a TZR_NOT_SUPPORTED value. 
     Embodiments of a network node for implementing an AF are also disclosed. The AF comprises processing circuitry. The processing circuitry is configured to cause the network node to send, to a PCF, a request for AN information. The processing circuitry is also configured to cause the network node to receive, from the PCF, a response to the request for AN information. The response includes the requested AN information or includes an indication that an AN does not support reporting the requested AN information. 
     In one embodiment, the response from the PCF comprises a UeCampingRep data structure. In one embodiment, the UeCampingRep data structure comprises a netLocAccSupp attribute set to an ANR_NOT_SUPPORTED value. In one embodiment, the requested AN information comprises UE location information or timezone information and the UeCampingRep data structure comprises a netLocAccSupp attribute set to a TZR_NOT_SUPPORTED value. 
     Embodiments of a method performed in a cellular communication system are also disclosed. The method comprises, at an SMF for providing AN information, receiving, from a PCF, a request for AN information. The method also comprises determining whether an AN does not support reporting of the requested AN information. The method also comprises, upon determining that the AN does not support reporting of the requested AN information, sending, to the PCF, a response comprising a notification that the AN does not support reporting of the requested AN information. The method also comprises, upon determining that the AN does support reporting of the requested AN information, acquiring the requested AN information, and sending the requested AN information to the PCF. The method also comprises, at the PCF, receiving, from an AF, the request for AN information. The method also comprises forwarding the request to the SMF. The method also comprises receiving, from the SMF, the response to the request. The method also comprises forwarding the response to the AF. The method also comprises, at the AF, sending, to the PCF, the request for AN information. The method also comprises receiving, from the PCF, the response to the request for AN information. The response includes the requested AN information or includes an indication that an AN does not support reporting the requested AN information. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       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. 
         FIG.  1    illustrates conventional policy and charging control (PCC) Procedures for IMS Session Establishment at an originating P-CSCF and a PCF; 
         FIG.  2    illustrates conventional interactions between a PCF and a SMF for PCF-initiated session management (SM) Policy Association Modification procedures; 
         FIG.  3    illustrates one example of a cellular communication network according to some embodiments of the present disclosure; 
         FIG.  4    illustrates a wireless communication system represented as a 5G network architecture composed of core Network Functions (NFs); 
         FIG.  5    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  FIG.  4   ; 
         FIG.  6    illustrates an exemplary method for partial access of network information according to some embodiments of the present disclosure; 
         FIG.  7    illustrates an exemplary method for partial access of network information according to some embodiments of the present disclosure; 
         FIG.  8    is a schematic block diagram of a network node, and particularly a network node according to some embodiments of the present disclosure; 
         FIG.  9    is a schematic block diagram that illustrates a virtualized embodiment of a network node of  FIG.  8    according to some embodiments of the present disclosure; 
         FIG.  10    is a schematic block diagram of the network node of  FIG.  8    according to some other embodiments of the present disclosure; 
         FIG.  11    is a schematic block diagram of a UE according to some embodiments of the present disclosure; and 
         FIG.  12    is schematic block diagram of the UE of  FIG.  11    according to some embodiments of the present disclosure. 
     
    
    
     DETAILED DESCRIPTION 
     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. 
     Radio Node: As used herein, a “radio node” is either a radio access node or a wireless communication device. 
     Radio Access Node: As used herein, a “radio access node” or “radio network node” or “radio access network node” is any node in a Radio Access Network (RAN) 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), a relay node, a network node that implements part of the functionality of a base station (e.g., a network node that implements a gNB Central Unit (gNB-CU) or a network node that implements a gNB Distributed Unit (gNB-DU)) or a network node that implements part of the functionality of some other type of radio access node. 
     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. 
     Communication Device: As used herein, a “communication device” is any type of device that has access to an access network. Some examples of a communication device include, but are not limited to: mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or Personal Computer (PC). The communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and/or data via a wireless or wireline connection. 
     Wireless Communication Device: One type of communication device is a wireless communication device, which may be any type of wireless device that has access to (i.e., is served by) a wireless network (e.g., a cellular network). Some examples of a wireless communication device include, but are not limited to: a User Equipment device (UE) in a 3GPP network, a Machine Type Communication (MTC) device, and an Internet of Things (IoT) device. Such wireless communication devices may be, or may be integrated into, a mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or PC. The wireless communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and/or data via a wireless connection. 
     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. 
     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. 
     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. 
     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. That is:
         For Untrusted wireless local area networks (WLANs), the time zone is not available   Any access network could not provide the information for privacy reasons, network policies, impossibility of derivation, etc. If the information refers to the location information, according to current procedures, the serving public land mobile network (PLMN) network code and country code will be provided instead. However, nothing is provided when it refers to the time zone.       

     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:
         For access networks where the time zone is not available, the AF will not be notified when the time zone changes or that the access network does not support the reporting. Thus, it can make wrong assumptions and may consider that the time zone has not changed even if it changed.   For access networks where the time zone is not available, it is not specified what the SMF will do when the time zone is not provided by the access network and it was requested by the AF. It means unexpected behavior will occur in the network.   Even if the AF subscribes to access type changes simultaneously with the request of access information (or in advance), the AF will not know if the non-3GPP network is trusted or untrusted or if the network is private. The AF could derive the kind of access network if the AF got the location (whose encoding depends on the kind of 3GPP/non-3GPP trusted/untrusted) but it will mean extra logic in the AF and the mandatory subscription to location information.   The SMF/PCF informs about the lack of support of NetLoc functionality, but the AF will not be informed if the access network can provide the information and if it can be provided only partially.       

     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:
         A mechanism to allow the AF to get clear information about the availability of all or partial requested access information   When the SMF cannot get part of the requested information (time zone), the SMF will notify the PCF that this information is not provided because the network does not support it.   When the PCF gets information that part of the requested information (time zone) is not supported, the PCF will inform the AF about this lack of support       

     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):
         The AF gets clear information on whether all or partial requested information was available or not and the reason why it was not provided.   Whenever the AF subscribes to time zone reporting, the AF will get information of the time zone or, if not supported by the access network or not available, about the lack of support.   The AF will not have to assume that the lack of reporting means that the requested information is not supported, i.e., the SMF will be able to report information about the lack of support of partial information when the AF subscribes to receive only time zone information and the network does not support it.   The AF will not have to interpret that the absence of time zone in the access network reporting means that it was not provided because it was not supported by the access network.   The AF will not have to subscribe to access type changes and to always require the location information in combination with the time zone (even if the location was not needed) to derive that the absence of time zone means that the access network does not support it.       

     Before addressing particular embodiments of the present disclosure, a general overview of a cellular communications system is provided with reference to  FIG.  3   . In this regard,  FIG.  3    illustrates one example of a cellular communications system  300  in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communications system  300  is a 5G 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  302 - 1  and  302 - 2 , which in LTE are referred to as enhanced node Bs (eNBs) (when connected to an evolved packet core (EPC)) and in 5G 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  304 - 1  and  304 - 2 . The base stations  302 - 1  and  302 - 2  are generally referred to herein collectively as base stations  302  and individually as base station  302 . Likewise, the (macro) cells  304 - 1  and  304 - 2  are generally referred to herein collectively as (macro) cells  304  and individually as (macro) cell  304 . The RAN may also include a number of low power nodes  306 - 1  through  306 - 4  controlling corresponding small cells  308 - 1  through  308 - 4 . The low power nodes  306 - 1  through  306 - 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  308 - 1  through  308 - 4  may alternatively be provided by the base stations  302 . The low power nodes  306 - 1  through  306 - 4  are generally referred to herein collectively as low power nodes  306  and individually as low power node  306 . Likewise, the small cells  308 - 1  through  308 - 4  are generally referred to herein collectively as small cells  308  and individually as small cell  308 . The cellular communications system  300  also includes a core network  310 , which in the 5GS is referred to as the 5G core (5GC). The base stations  302  (and optionally the low power nodes  306 ) are connected to the core network  310 . 
     The base stations  302  and the low power nodes  306  provide service to wireless communication devices  312 - 1  through  312 - 5  in the corresponding cells  304  and  308 . The wireless communication devices  312 - 1  through  312 - 5  are generally referred to herein collectively as wireless communication devices  312  and individually as wireless communication device  312 . In the following description, the wireless communication devices  312  are oftentimes UEs, but the present disclosure is not limited thereto. 
       FIG.  4    illustrates a wireless communication system represented as a 5G 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.  4    can be viewed as one particular implementation of the core network  310  of the system  300  of  FIG.  3   . 
     Seen from the access side, the 5G network architecture shown in  FIG.  4    comprises a plurality of UEs  400  connected to either a RAN or an Access Network (AN)  402  as well as an AMF  404 . Typically, the (R)AN  402  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 5G core NFs shown in  FIG.  4    include a Network Slice Selection Function (NSSF)  406 , an Authentication Server Function (AUSF)  408 , a Unified Data Management (UDM)  410 , the AMF  404 , a Session Management Function (SMF)  412 , a Policy Control Function (PCF)  414 , and an Application Function (AF)  416 . 
     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  400  and AMF  404 . The reference points for connecting between the AN  402  and AMF  404  and between the AN  402  and user plane function (UPF)  418  are defined as N2 and N3, respectively. There is a reference point, N11, between the AMF  404  and SMF  412 , which implies that the SMF  412  is at least partly controlled by the AMF  404 . N4 is used by the SMF  412  and UPF  418  so that the UPF  418  can be set using the control signal generated by the SMF  412 , and the UPF  418  can report its state to the SMF  412 . N9 is the reference point for the connection between different UPFs  418 , and N14 is the reference point connecting between different AMFs  404 , respectively. N15 and N7 are defined since the PCF  414  applies policy to the AMF  404  and SMF  412 , respectively. N12 is required for the AMF  404  to perform authentication of the UE  400 . N8 and N10 are defined because the subscription data of the UE  400  is required for the AMF  404  and SMF  412 . N6 is defined between the UPF  418  and a data network (DN)  420 . 
     The 5G 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.  4   , the UPF  418  is in the user plane and all other NFs, i.e., the AMF  404 , SMF  412 , PCF  414 , AF  416 , AUSF  408 , and UDM  410 , are in the control plane. Separating the user and control planes guarantees each plane resource is scaled independently. It also allows UPFs  418  to be deployed separately from control plane functions in a distributed fashion. In this architecture, UPFs  418  may be deployed very close to UEs  400  to shorten the Round Trip Time (RTT) between UEs and the data network for some applications requiring low latency. 
     The core 5G network architecture is composed of modularized functions. For example, the AMF  404  and SMF  412  are independent functions in the control plane. Separated AMF  404  and SMF  412  allow independent evolution and scaling. Other control plane functions like the PCF  414  and AUSF  408  can be separated as shown in  FIG.  4   . Modularized function design enables the 5G core 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. 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  418 . 
       FIG.  5    illustrates a 5G network architecture  500  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  FIG.  4   . However, the NFs described above with reference to  FIG.  4    correspond to the NFs shown in  FIG.  5   . 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.  5    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)  502  and the Network Function (NF) Repository Function (NRF)  504  in  FIG.  5    are not shown in  FIG.  4    discussed above. However, it should be clarified that all NFs depicted in  FIG.  4    can interact with the NEF  502  and the NRF  504  of  FIG.  5    as necessary, though not explicitly indicated in  FIG.  4   . 
     Some properties of the NFs shown in  FIGS.  4  and  5    may be described in the following manner. The AMF  404  provides UE-based authentication, authorization, mobility management, etc. A UE  400  even using multiple access technologies is basically connected to a single AMF  404  because the AMF  404  is independent of the access technologies. The SMF  412  is responsible for session management and allocates Internet Protocol (IP) addresses to UEs  400 . It also selects and controls the UPF  418  for data transfer. If a UE  400  has multiple sessions, different SMFs  412  may be allocated to each session to manage them individually and possibly provide different functionalities per session. The AF  416  provides information on the packet flow to the PCF  414  responsible for policy control to support Quality of Service (QoS). Based on the information, the PCF  414  determines policies about mobility and session management to make the AMF  404  and SMF  412  operate properly. The AUSF  408  supports authentication function for UEs  400  or similar and thus stores data for authentication of UEs  400  or similar while the UDM  410  stores subscription data of the UE  400 . The DN  420 , not part of the 5G core 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. 
       FIG.  6    illustrates an exemplary method for partial access of network information according to some embodiments of the present disclosure. In the embodiment illustrated in  FIG.  6   , an Application Function (AF)  416  seeks Access Network (AN) information that is not supported by the AN  402 , resulting in the following steps: 
     Step  600 . The AF  416  sends a request for AN information to a PCF  414 . In this example, the AF  416  requests timezone information, e.g., for a particular UE  400 . 
     Step  602 . The PCF  414  forwards the request to an SMF  412 . 
     Step  604 . The SMF  412  determines that the AN  402  does not support reporting of timezone information. The SMF  412  may know this deficiency in advance, or it may query the AN  402  or a core network node that maintains this information to determine this deficiency. 
     Step  606 . The SMF  412  notifies the PCF  414  that the AN  402  does not support reporting of timezone information. In some embodiments, the netLocAccSupp attribute is set to “TZR_NOT_SUPPORTED.” 
     Step  608 . The PCF  414  forwards that message to the AF  416 . In this manner, the AF  416  is notified that the AN  402  does not support reporting timezone information. This can prevent the AF  416  from making false assumptions about the UE&#39;s timezone. 
     The same principle can be applied to any type of AN information that the AF  416  may request, as shown by the next sequence of messages: 
     Step  610 . The AF  416  sends another request to the PCF  414 , this time for AN information other than the timezone. This “other AN information” is represented generically as “&lt;AN information&gt;” in  FIG.  6   . 
     Step  612 . The PCF  414  forwards the request for &lt;AN information&gt; to the SMF  412 . 
     Step  614 . The SMF  412  determines that the AN  402  does not support reporting of this specific &lt;AN information&gt;. The SMF  412  may know this deficiency in advance, or it may query the AN  402  or a core network node that maintains this information to determine this deficiency. 
     Step  616 . The SMF  412  notifies the PCF  414  that the AN  402  does not support reporting of &lt;AN information&gt;. 
     Step  618 . The PCF  414  forwards that message to the AF  416 . In this manner, the AF  416  is notified that the AN  402  does not support reporting of &lt;AN information&gt;. 
       FIG.  7    illustrates an exemplary method for partial access of network information according to some embodiments of the present disclosure. In the embodiment illustrated in  FIG.  7   , an AF  416  seeks AN information that is supported by the AN  402 , resulting in the following steps: 
     Step  700 . The AF  416  sends a request for AN information to a PCF  414 . In this example, the AF  416  requests timezone information, e.g., for a particular UE  400 . 
     Step  702 . The PCF  414  forwards the request to an SMF  412 . 
     Step  704 . The SMF  412  determines that the AN  402  supports reporting of timezone information. The SMF  412  may know this functionality in advance, or it may query the AN  402  or a core network node that maintains this information to determine this functionality. 
     Step  706 . The SMF  412  sends a request for timezone information to the AN  402 . 
     Step  708 . The SMF  412  receives the timezone information from the AN  402 . 
     Step  710 . The SMF  412  forwards the timezone information to the PCF  414 , e.g., via the “ueTimeZone” parameter. 
     Step  712 . The PCF  414  forwards the timezone information to the AF  416 . 
     The steps illustrated in  FIGS.  6  and  7    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: 
     PCF Request and Report of Access Network Information in the SMF 
     If the NetLoc functionality is supported by both the SMF  412  and PCF  414 , the PCF  414  may request the SMF  412  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  412 , in an exemplary aspect, shall check if the access network  402  supports the required information:
         If the SMF  412  determines that the access network  402  does not support the access network information reporting based on the feature support, the SMF  412  shall immediately inform the PCF  414  by including the “netLocAccSupp” attribute set to “ANR_NOT_SUPPORTED” value in the “UeCampingRep” data structure returned in the “200 OK” response to the policy update notification request.   Otherwise:
           a) If the “reqData” attribute includes the MS_TIME_ZONE value and the SMF  412  determines that the access network  402  does not support the report of the UE time zone, the SMF  412  shall immediately inform the PCF  414  by including the “netLocAccSupp” attribute set to “TZR_NOT_SUPPORTED” value in the “UeCampingRep” data structure returned in the “200 OK” response to the policy update notification request.   b) If the “reqData” attribute includes:
               1) the USER_LOC_INFO value; and/or   2) the MS_TIME_ZONE value and the SMF  412  determines the access network  402  supports the report of UE time zone,   3) then the SMF  412  shall apply appropriate procedures to the EPC access network to obtain the requested access network information as described below.   
               
               

     It should be appreciated that non-support of access network reporting can occur in the interworking scenarios, when the SMF  412  corresponds to an SMF+PGW-C and the access network  402  does not support the reporting of timezone information (Non-3GPP Untrusted Access). 
     In an exemplary aspect, if access network reporting is supported, the SMF  412  shall apply the Namf_EventExposure service with One-Time Report type as defined in subclause 5.3.1 of 3GPP TS 29.518 [36] if the related information is not available to obtain this information. When the SMF  412  then receives access network information from the AMF  404 , the SMF  412  shall provide the required access network information to the PCF  414  by as defined in subclause 4.2.4.1 and set the corresponding attributes as follows:
         If the user location information was requested by the PCF  414  and was provided to the SMF  412 , the SMF  412  shall provide the user location information within the “userLocationInfo” attribute and the time when it was last known within “userLocationInfoTime” attribute (if available).   If the user location information was requested by the PCF  414  and was not provided to the SMF  412 , the SMF  412  shall provide the serving public land mobile network (PLMN) identifier and for standalone non-public network (SNPN) also the network identifier (NID) within the “servingNetwork” attribute.   If the time zone was requested by the PCF  414  and received by the SMF  412 , it shall provide it within the “ueTimeZone” attribute.       

     In addition, the SMF  412  shall provide the AN_INFO policy control request trigger within the “repPolicyCtrlReqTriggers” attribute. 
     The SMF  412  shall not report any subsequent access network information updates received from the RAN  402  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. 
     PCF Repelling Access Network Information to the AF 
     This procedure is used by the PCF  414  to report the access network information (i.e., user location and/or user timezone information) to the AF  416  when the “NetLoc” feature is supported. 
     When the PCF  414  receives the access network information from the SMF  412 , the PCF shall include the “EventsNotification” data type in the body of the HTTP POST request message sent to the AF  416  as described in subclause 4.2.5.2 of TS 29.514. The PCF  414  shall include in the “EventsNotification” data type: 
     In case of 3GPP access, the user location information in the “eutraLocation” or in the “nrLocation” attribute in the “ueLoc” attribute, if available and required, or in case of untrusted non-3GPP access, the user location information in the “n3gaLocation” attribute in the “ueLoc” attribute, if required, as follows:
         a) the user local IP address in the “ueIpv4Addr” or “ueIpv6Addr” attribute, if available;   b) the user datagram protocol (UDP) source port in the “portNumber” attribute if available; and   c) the transmission control protocol (TCP) source port in the “portNumber” attribute if available;       

     In case of trusted non-3GPP access, the user location information in the “n3gaLocation” attribute in the “ueLoc” attribute, if required, as follows:
         a) the user local IP address in the “ueIpv4Addr” or “ueIpv6Addr” attribute, if available;   b) the UDP source port in the “portNumber” attribute if available;   c) the TCP source port in the “portNumber” attribute if available; and   d) the trusted WLAN access point (TNAP) identifier, that shall consist of:
           i. the service set identifier (SSID) in the “ssId” attribute;   ii. the basic SSID (BSSID) the “bssId” attribute if available; and   iii. the TNAP civic address in the “tnapCivicAddress” attribute if available;   
           the serving PLMN network code and country code in the “plmnId” attribute, if user location information is required but not available in any access;   the UE time zone in the “ueTimeZone” attribute if required and available; and/or   the “netLocAccSupp” attribute set to “TZR_NOT_SUPPORTED” value, if UE timezone information is required but not available in current access.       

     When the PCF  414  receives notification from the SMF  412  that the access network  402  does not support access network information report, the PCF  414  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  416  as described in subclause 4.2.5.2 of TS 29.514. 
     The PCF  414  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  414  receives the access network information from the SMF  412  if it is previously requested by the AF  416  or at PDU session termination or at the termination of all the service data flows of the AF session. 
     The PCF  414  shall not invoke the Npcf_PolicyAuthorization_Notify service operation with the “event” attribute set to the value “ANI_REPORT” to report to the AF  416  any subsequently received access network information, unless the AF  416  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 29.512 V15.6.0. Changes are indicated by underlining, strike-throughs, or by being otherwise noted. 

 
     Example Implementations 
       FIG.  8    is a schematic block diagram of a network node  800  according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. The network node  800  may be, for example, a radio access node such as a base station  302  or  306  or other node that implements all or part of the functionality described herein. As illustrated, the network node  800  includes a control system  802  that includes one or more processors  804  (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory  806 , and a network interface  808 . The one or more processors  804  are also referred to herein as processing circuitry. In addition, the network node  800  may include one or more radio units  810  (if the network node  800  is a radio access node such as a base station  302 ) that each includes one or more transmitters  812  and one or more receivers  814  coupled to one or more antennas  816 . The radio units  810  may be referred to or be part of radio interface circuitry. In some embodiments, the radio unit(s)  810  is external to the control system  802  and connected to the control system  802  via, e.g., a wired connection (e.g., an optical cable). However, in some other embodiments, the radio unit(s)  810  and potentially the antenna(s)  816  are integrated together with the control system  802 . The one or more processors  804  operate to provide one or more functions of a network node  800  as described herein. In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory  806  and executed by the one or more processors  804 . 
       FIG.  9    is a schematic block diagram that illustrates a virtualized embodiment of the network node  800  according to some embodiments of the present disclosure. This discussion is equally applicable to other types of network nodes. Further, other types of network nodes may have similar virtualized architectures. Again, optional features are represented by dashed boxes. 
     As used herein, a “virtualized” radio access node is an implementation of the network node  800  in which at least a portion of the functionality of the network node  800  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  800  may include the control system  802  and/or the one or more radio units  810  (if the node  800  is a radio access node), as described above. The control system  802  may be connected to the radio unit(s)  810  via, for example, an optical cable or the like. The network node  800  includes one or more processing nodes  900  coupled to or included as part of a network(s)  902 . If present, the control system  802  or the radio unit(s) are connected to the processing node(s)  900  via the network  902 . Each processing node  900  includes one or more processors  904  (e.g., CPUs, ASICs, FPGAs, and/or the like), memory  906 , and a network interface  908 . 
     In this example, functions  910  of the network node  800  described herein are implemented at the one or more processing nodes  900  or distributed across the one or more processing nodes  900  and the control system  802  and/or the radio unit(s)  810  in any desired manner. In some particular embodiments, some or all of the functions  910  of the network node  800  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)  900 . As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s)  900  and the control system  802  is used in order to carry out at least some of the desired functions  910 . Notably, in some embodiments, the control system  802  may not be included, in which case the radio unit(s)  810  communicate directly with the processing node(s)  900  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  800  or a node (e.g., a processing node  900 ) implementing one or more of the functions  910  of the network node  800  in a virtual environment according to any of the embodiments described herein 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). 
       FIG.  10    is a schematic block diagram of the network node  800  according to some other embodiments of the present disclosure. The network node  800  includes one or more modules  1000 , each of which is implemented in software. The module(s)  1000  provide the functionality of network node  800  described herein. This discussion is equally applicable to the processing node  900  of  FIG.  9    where the modules  1000  may be implemented at one of the processing nodes  900  or distributed across multiple processing nodes  900  and/or distributed across the processing node(s)  900  and the control system  802 . 
     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 Processor (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. 
     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.). 
     SMF Embodiments 
     Embodiment 1: A method performed by a Session Management Function, SMF, for providing Access Network, AN, information, the method comprising:
         receiving ( 602 , 612 , 702 ), from a Policy Control Function, PCF, a request for AN information;   determining ( 604 ,  614 ,  704 ) whether the AN does not support reporting of the requested AN information;   upon determining that the AN does not support reporting of the requested AN information, sending ( 606 ,  616 ), to the PCF, a notification that the AN does not support reporting of the requested AN information; and   upon determining that the AN does support reporting of the requested AN information:
           acquiring ( 706 , 708 ) the requested AN information; and   sending ( 710 ) the requested AN information to the PCF.   
               

     Embodiment 2: The method of embodiment 1, wherein sending ( 606 , 616 ) the notification that the AN does not support the reporting the requested AN information comprises sending a UeCampingRep data structure. 
     Embodiment 3: The method of embodiment 2, wherein sending the notification that the AN does not support the reporting the requested AN information comprises sending ( 616 ) a UeCampingRep data structure having a netLocAccSupp attribute set to an ANR_NOT_SUPPORTED value. 
     Embodiment 4: The method of embodiment 2, wherein the requested AN information comprises User Equipment, UE, location information or timezone information, and wherein sending the notification that the AN does not support reporting the requested AN information comprises sending ( 606 ) a UeCampingRep data structure having a netLocAccSupp attribute set to an TZR_NOT_SUPPORTED value. 
     PCF Embodiments 
     Embodiment 5: A method performed by a Policy Control Function, PCF, for providing Access Network, AN, information, the method comprising:
         receive ( 600 ,  610 ,  700 ), from an Application Function, AF, a request for AN information;   forwarding ( 602 , 612 , 702 ) the request to a Session Management Function, SMF;   receiving ( 606 , 616 , 710 ), from the SMF, a response to the request; and   forwarding ( 608 , 618 , 712 ) the response to the AF.       

     Embodiment 6: The method of embodiment 5, wherein the response from the SMF comprises an indication that the AN does not support reporting the requested AN information. 
     Embodiment 7: The method of embodiment 6, wherein the response from the SMF comprises a UeCampingRep data structure. 
     Embodiment 8: The method of embodiment 7, wherein the UeCampingRep data structure comprises a netLocAccSupp attribute set to an ANR_NOT_SUPPORTED value. 
     Embodiment 9: The method of embodiment 7, wherein the requested AN information comprises User Equipment, UE, location information or timezone information and wherein the UeCampingRep data structure comprises a netLocAccSupp attribute set to an TZR_NOT_SUPPORTED value. 
     AF Embodiments 
     Embodiment 10: A method performed by an Application Function, AF, for requesting Access Network, AN, information, the method comprising:
         sending ( 600 ,  610 ,  700 ), to a Policy Control Function, PCF, a request for AN information; and   receiving ( 608 ,  618 ,  712 ), from the PCF, a response to the request for AN information, wherein the response includes the requested AN information or includes an indication that AN does not support reporting the requested AN information.       

     Embodiment 11: The method of embodiment 10, wherein the response from the PCF comprises a UeCampingRep data structure. 
     Embodiment 12: The method of embodiment 11, wherein the UeCampingRep data structure comprises a netLocAccSupp attribute set to an ANR_NOT_SUPPORTED value. 
     Embodiment 13: The method of embodiment 10, wherein the requested AN information comprises User Equipment, UE, location information or timezone information and wherein the UeCampingRep data structure comprises a netLocAccSupp attribute set to an TZR_NOT_SUPPORTED value. 
     Apparatus Embodiments 
     Embodiment 14: A Session Management Function, SMF, comprising:
         processing circuitry configured to perform any of the steps of any of the SMF embodiments; and   power supply circuitry.       

     Embodiment 15: A Policy Control Function, PCF, comprising:
         processing circuitry configured to perform any of the steps of any of the PCF embodiments; and   power supply circuitry.       

     Embodiment 16: An Application Function, AF, comprising:
         processing circuitry configured to perform any of the steps of any of the AF embodiments; and   power supply circuitry.       

     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 Management Function   AN Access Network   AP Access Point   ASIC Application Specific Integrated Circuit   AUSF Authentication Server Function   CPU Central Processing Unit   DL Downlink   DN Data Network   DSP Digital Signal Processor   eNB Enhanced or Evolved Node B   EPS Evolved Packet System   E-UTRA Evolved Universal Terrestrial Radio Access   FPGA Field Programmable Gate Array   gNB New Radio Base Station   gNB-DU New Radio Base Station Distributed Unit   HSS Home Subscriber Server   IoT Internet of Things   IP Internet Protocol   LTE Long Term Evolution   MME Mobility Management Entity   MTC Machine Type Communication   NEF Network Exposure Function   NF Network Function   NPLI Network Provided Location Information   NR New Radio   NRF Network Function Repository Function   NSSF Network Slice Selection Function   OTT Over-the-Top   P-CSCF Proxy-Call Session Control Function   PC Personal Computer   PCC Policy and Charging Control   PCF Policy Control Function   PGW Packet Data Network Gateway   QoS Quality of Service   RAM Random Access Memory   RAN Radio Access Network   ROM Read Only Memory   RRH Remote Radio Head   RTT Round Trip Time   SCEF Service Capability Exposure Function   SMF Session Management Function   UDM Unified Data Management   UE User Equipment   UL Uplink   UPF User Plane Function       

     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.