System and method for UPF selection for 2g3g access in smf

Abstract

Disclosed is a method for execution by a network node implementing an SMF (Session Management Function). The method involves sending an NRF (Network Repository Function) Discovery Request for UPF (User Plane Function), wherein the NRF Discovery Request including a first query parameter for 2G / 3G access and / or a second query parameter for indicated 2G / 3G location. The method also involves receiving a UPF list of one or more UPFs that support 2G / 3G access and / or the indicated 2G / 3G location, in accordance with the NRF Discovery Request, and selecting a UPF from the UPF list. In this way, the SMF can select a UPF that supports 2G&3G access and / or supports the current UE 2G / 3G ULI (User Location Information) location.

Description

[0001] SYSTEM AND METHOD FOR

[0002] UPF SELECTION FOR 2G3G ACCESS IN SMF

[0003] Related Application

[0004] [1] This patent application claims priority from PCT provisional patent application no. PCT / CN2024 / 130369 filed on November 7, 2024, which is incorporated by reference in its entirety.

[0005] Field of the Disclosure

[0006] [2] This disclosure relates to communication systems, and more particularly to discovery and selection of UPF (User Plane Function) for 2G / 3G access.

[0007] Background

[0008] [3] Referring first to Figure 1, shown is a block diagram of communication system implementing a solution for SMF (Session Management Function) support of 2G GERAN (GSM (Global System for Mobile Communications) EDGE (Enhanced Data rates for GSM Evolution) RAN (Radio Access Network)) and 3G UTRAN (UMTS (Universal Mobile Telecommunications System) Terrestrial Radio Access Network).

[0009] [4] According to 3GPP TS 23.501 entitled “System architecture for the 5G System (5GS)” version 19.1.0 uploaded 2024-09-24 (hereinafter “TS 23.501”) and 3GPP TS 23.502 entitled “Procedures for the 5G System (5GS)” version 19.1.0 uploaded 2024-09-24 (hereinafter “TS 23.502”), an SMF+PGW-C 110 (Session Management Function + Packet Data Network Gateway - Control Plane) is enhanced to support a UE 105 (User Equipment) accessing the network via GERAN / UTRAN 101a-b over a Gn / Gp interface.

[0010] [5] For this scenario, the SMF+PGW-C 110 uses an N7 interface to interact with PCF 120 (Policy Control Function) and an N40 interface to interact with CHF 130 (Charging Function). For a PDP (Packet Data Protocol) context create request from 2G / 3G, if an SMF role is determined, the SMF 110 can select a UPF 140 for this PDP context to transfer a user plane payload.

[0011] [6] Some further details are provided below with reference to various sections of TS 23.501 and TS 23.502.

[0012] TS 23.501 Annex L (normative): Support of GERAN / UTRAN access

[0013] [7] This annex applies when the SMF+PGW-C 110 is enhanced to support a UE 105 accessing the network via GERAN / UTRAN 101a-b over the Gn / Gp interface. For this scenario, the SMF+PGW-C 110 uses the N7 interface to interact with the PCF 120 and the N40 interface to interact with the CHF 120.

[0014] [8] For the interface with the serving node of the UE 105, the SMF+PGW-C 110 is assumed to behave as the Control Plane of the PGW (Packet Data Network Gateway) described in Annex D of TS 23.401.

[0015] [9] The selection of the SMF+PGW-C 110 by an SGSN 102a-b (Serving GPRS (General Packet Radio Service) Support Node) is specified in Annex G of TS 23.502.

[0016]

[0010] The SMF+PGW-C 110 interacting with the PCF 120 for GERAN / UTRAN access is specified in Annex G of TS 23.502.

[0017]

[0011] The functional description for the SMF+PGW-C 110 interacting with the PCF 120 to support GERAN / UTRAN access is specified in 3GPP TS 23.503 entitled “Policy and charging control framework for the 5G System (5GS); Stage 2” version 19.1.0 uploaded 2024-09-24 (hereinafter “TS 23.503”).

[0018]

[0012] Support for IP (Internet Protocol) address preservation upon mobility between 5GS (5G System) and GERAN / UTRAN for PDN (Packet Data Network) sessions established in EPC (Evolved Packet Core) is described in clause 5.17.2.4. IP address preservation is not supported for direct mobility between 5GS and GERAN / UTRAN, nor for indirect mobility cases when the PDN session is established in 5GS or in GERAN / UTRAN.

[0013] Charging services on interactions by the SMF+PGW-C 110 with the CHF 130 for GERAN / UTRAN access are specified in 3GPP TS 32.255 entitled “Telecommunication management; Charging management; 5G data connectivity domain charging; Stage 2” version 19.0.0 uploaded 2024-09-26 (hereinafter “TS 32.255”).

[0019] TS 23.501: 5.17.2.4 Mobility between 5GS and GERAN / UTRAN

[0020]

[0014] IP address preservation upon direct mobility between 5GS and GERAN / UTRAN is not supported.

[0021]

[0015] Upon mobility from 5GS to GERAN / UTRAN (e.g. upon leaving NG-RAN (Next Generation Radio Access Network) coverage) the UE 105 shall perform an A / Gb mode GPRS Attach procedure or lu mode GPRS Attach procedure - see 3GPP TS 23.060 entitled “General Packet Radio Service (GPRS); Service description; Stage 2” version 18.0.0 uploaded 2024-04-03 (hereinafter “TS 23.060”).

[0022]

[0016] When the UE 105 accesses the network via GERAN / UTRAN 101 over the Gn / Gp interface, Secondary PDP Context Activation Procedure is not supported and the SMF+PGW-C 110 rejects a Secondary PDP Context Activation request if the UE 105 requested it.

[0023]

[0017] IP address preservation at mobility from EPC to GERAN / UTRAN for PDU sessions established in 5GS is not supported.

[0024] TS 23.502 Annex G (normative): Support of GERAN / UTRAN access by SMF+PGW-C

[0025]

[0018] This annex applies when the SMF+PGW-C 110 is enhanced to support GERAN / UTRAN access via the Gn / Gp interface as specified in Annex L of TS 23.501.

[0026]

[0019] For the interface with the serving node of the UE 105, the SMF+PGW-C 110 is assumed to behave as the Control Plane of the PGW described in Annex D of TS 23.401.

[0027]

[0020] The SMF+PGW-C 110 is selected by the SGSN 102 using an existing mechanism as specified in Annex A of TS 23.060.

[0021] If network deployment involves both the SMF+PGW-C 110 and legacy PGW, selection of the SMF+PGW-C 110 by the SGSN 102a-b can be achieved based on e.g. APN (Access Point Name) and optionally APN-OI (Access Point Name Operator Identifier) Replacement as specified Annex A of TS 23.060.

[0028]

[0022] When the SMF+PGW-C 110 is used for GERAN / UTRAN access, at PDP context activation, the SMF+PGW-C 110 allocates a PDU Session ID (Identifier) in the network range and uses this PDU Session ID over an SBI (Service Based Interface), for example the N7 interface.

[0029]

[0023] The following procedures from TS 23.060 are not supported when the SMF+PGW-C 110 is used for GERAN / UTRAN access:

[0030] • Network requested PDP Context Activation Procedure (clause 9.2.2.2 of TS 23.060).

[0031] • Secondary PDP Context Activation Procedure (clause 9.2.2.1.1 of TS 23.060).

[0032] • Network Requested Secondary PDP Context Activation Procedure using Gn (clause 9.2.2.1.3 of TS 23.060).

[0033]

[0024] When the SMF+PGW-C 110 is used for GERAN / UTRAN access and interacts with the PCF 120, the SMF+PGW-C 110 uses SM (Session Management) policy association procedures as specified in clause 4.11,0a.2 with the following modification:

[0034] • The SMF+PGW-C 110 performs mapping of QoS parameters as follows:

[0035] o The SMF+PGW-C 110 maps Release 99 QoS (Quality of Service) parameters received from the Gn / Gp interface to EPS QoS parameters as specified in Annex E of TS 23.401, which is then used to derive QoS parameters over the N7 interface as specified in clause 4.11,0a.2.

[0036] o the SMF+PGW-C 110 uses the QoS parameters over the N7 interface to derive the EPS QoS parameters as specified in clause 4.11.0a.2, which is then mapped to the Release 99 QoS parameters for the Gn / Gp interface as specified in Annex E of 3GPP TS 23.401 entitled “General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access” version 19.0.0 uploaded 2024-09-24 (hereinafter “TS 23.401”).

[0037] • For an SM Policy Association Establishment Procedure, the SMF+PGW-C 110 invokes Npcf_SMPolicyControl_Create Service operation taking input from the information elements received in Create PDP Context Request message (specified in TS 23.060), including mapping of the QoS parameters as mentioned above as well as GERAN / UTRAN location management related information.

[0038] • For an SM Policy Association Modification procedure initiated by the SMF+PGW-C, the SMF+PGW-C 110 invokes Npcf_SMPolicyControl_Update Service operation taking input from the information elements received in Update PDP Context Request message (specified in TS 23.060), including mapping of the QoS parameters as mentioned above, as well as GERAN / UTRAN location management related information.

[0039] • For an SM Policy Association Modification procedure initiated by the PCF 120, the SMF+PGW-C 110 may receive PCC (Policy and Charging Control) Rules and PDU Session Policy Information. The SMF+PGW-C 110 performs mapping of the QoS parameters as mentioned above.

[0040] • For an SM Policy Association Termination procedure, the SMF+PGW-C 110 invokes Npcf_SMPolicyControl_Delete service operation (including GERAN / UTRAN location management related information) when receiving Delete PDP Context Request message (specified in TS 23.060).

[0041] • Even though the N7 interface supports Ethernet PDU Session Type, as Ethernet PDN Type is not supported in GERAN / UTRAN, it is assumed that if the UE 105 moves from E-UTRAN 103 to GERAN / UTRAN 101a-b, Ethernet PDN connections are released and thus no information related with Ethernet PDU Session Type shall be exchanged over the N7 interface when the UE 105 is served by GERAN / UTRAN 101a-b.

[0042] • Even though GERAN / UTRAN specifications foresee other alternatives, the Bearer Binding is performed by the SMF+PGW-C 110 acting as a PGW.

[0043] • Access Network Information reporting with a granularity of GERAN / UTRAN cell is supported over the N7 and N5 interfaces.

[0044]

[0025] When the UE 105 moves between E-UTRAN 103 and GERAN / UTRAN 101 a-b, the SMF+PGW-C 110 may invoke SM Policy Association Modification procedure based on the Policy Control Request Triggers as specified in TS 23.503.

[0045]

[0026] Support for IP address preservation upon indirect mobility between 5GS and GERAN / UTRAN for PDN sessions established in EPC is described in clause 5.17.2.4 of TS 23.501. IP address preservation is not supported for direct mobility between 5GS and GERAN / UTRAN, nor for indirect mobility cases when the PDN session is established in 5GS or in GERAN / UTRAN.

[0046]

[0027] Usage of the SMF+PGW-C 110 to serve a PDP context requires no change to SGSN(s) 102a-b (and thus to roaming partners in Home Routed roaming) as it is assumed that DNS records are properly configured to map APN to the SMF+PGW-C 110 acting as PGW.

[0047] Summary of the Disclosure

[0048]

[0028] Previous approaches may result in selecting a UPF that does not support 2G&3G access and / or does not support a current UE 2G / 3G ULI (User Location Information) location. Therefore, the previous approaches can leave much to be desired. It is an object of some embodiments to improve upon the previous approaches in a manner that addresses, solves or mitigates some or all of the deficiencies.

[0029] According to an aspect, there is provided a method for execution by a network node implementing an SMF (Session Management Function). The method involves sending an NRF (Network Repository Function) Discovery Request for UPF (User Plane Function), wherein the NRF Discovery Request includes a first query parameter for 2G / 3G access and / or a second query parameter for indicated 2G / 3G location. The method also involves receiving a UPF list of one or more UPFs that support 2G / 3G access and / or the indicated 2G / 3G location, in accordance with the NRF Discovery Request, and selecting a UPF from the UPF list. In this way, the SMF can select a UPF that supports 2G&3G access and / or supports the current UE 2G / 3G ULI location.

[0049]

[0030] In some implementations, the method also involves receiving a Create PDP (Packet Data Protocol) Context Request, wherein the NRF Discovery Request is sent in response to receiving the Create PDP Context Request, establishing a PDP Context with the UPF that has been selected, and sending a Create PDP Context Response in response to establishing the PDP Context. In this way, for a PDP Context Create Request from 2G / 3G, if SMF role is determined, the SMF can select a UPF that supports 2G&3G access and / or supports the current UE 2G / 3G ULI location.

[0050]

[0031] In some implementations, the NRF Discovery Request includes the first query parameter for 2G / 3G access. In some implementations, the NRF Discovery Request includes the second query parameter for indicated 2G / 3G location. In some implementations, the NRF Discovery Request includes both the first query parameter and the second query parameter.

[0051]

[0032] In some implementations, the UPF list identifies a plurality of UPFs that support 2G / 3G access and / or the indicated 2G / 3G location, in accordance with the NRF Discovery Request. Furthermore, selecting the UPF from the UPF list includes selecting the UPF from the plurality of UPFs based on at least one of: dedicated UPF for 2G / 3G access, security consideration, low bandwidth and less enhanced UPF functions, and UE current location of 2G / 3G.

[0052]

[0033] According to an aspect, there is provided a non-transitory CRM (computer readable medium) having recorded thereon statements and instructions that, when executed by a processor of a network node, configure the network node to implement a method as summarized above.

[0053]

[0034] According to another aspect, there is provided a network node implementing an SMF (Session Management Function). The network node has a network interface configured to communicate with other network nodes, and UPF (User Plane Function) selection circuitry. The UPF selection circuitry is configured to send, over the network interface, an NRF (Network Repository Function) Discovery Request for UPF, wherein the NRF Discovery Request includes a first query parameter for 2G / 3G access and / or a second query parameter for indicated 2G / 3G location. The UPF selection circuitry is also configured to receive, over the network interface, a UPF list of one or more UPFs that support 2G / 3G access and / or the indicated 2G / 3G location, in accordance with the NRF Discovery Request. Finally, the UPF selection circuitry is configured to select a UPF from the UPF list. In some implementations, the UPF selection circuitry is also configured to implement a method as summarized above.

[0054]

[0035] According to another aspect, there is provided a method for execution by a network node implementing an NRF (Network Repository Function). The method involves receiving an NRF Discovery Request for UPF (User Plane Function), wherein the NRF Discovery Request includes a first query parameter for 2G / 3G access and / or a second query parameter for indicated 2G / 3G location. The method also involves sending a UPF list of one or more UPFs that support 2G / 3G access and / or the indicated 2G / 3G location, in accordance with the NRF Discovery Request.

[0055]

[0036] In some implementations, the method also involves, for each UPF of a plurality of UPFs, discovering the UPF in terms of 2G / 3G access and / or 2G / 3G location, and determining the UPF list based on the discovering and the NRF Discovery Request. In some implementations, for each UPF, discovering the UPF in terms of 2G / 3G access and / or 2G / 3G location involves receiving an NRF Management Register Request indicating 2G / 3G access and / or 2G / 3G location.

[0056]

[0037] In some implementations, the NRF Discovery Request includes the first query parameter for 2G / 3G access. In some implementations, the NRF Discovery Request includes the second query parameter for indicated 2G / 3G location. In some implementations, the NRF Discovery Request includes both the first query parameter and the second query parameter.

[0057]

[0038] According to another aspect, there is provided a non-transitory CRM (computer readable medium) having recorded thereon statements and instructions that, when executed by a processor of a network node, configure the network node to implement a method as summarized above.

[0058]

[0039] According to another aspect, there is provided a network node implementing an NRF (Network Repository Function). The network node has a network interface configured to communicate with other network nodes, and UPF (User Plane Function) discovery circuitry. The UPF discovery circuitry is configured to receive, over the network interface, an NRF Discovery Request for UPF, wherein the NRF Discovery Request includes a first query parameter for 2G / 3G access and / or a second query parameter for indicated 2G / 3G location. The UPF discovery circuitry is also configured to send, over the network interface, a UPF list of one or more UPFs that support 2G / 3G access and / or the indicated 2G / 3G location, in accordance with the NRF Discovery Request. In some implementations, the UPF discovery circuitry is also configured to implement a method as summarized above.

[0059]

[0040] Other aspects and features of the present disclosure will become apparent, to those ordinarily skilled in the art, upon review of the following description of the various embodiments of the disclosure.

[0060] Brief Description of the Drawings

[0061]

[0041] Embodiments will now be described with reference to the attached drawings in which:

[0062] Figure 1 is a block diagram of a communication system implementing a solution for SMF support of 2G GERAN and 3G UTRAN; Figure 2 is a block diagram of another communication system, in accordance with an embodiment of the disclosure;

[0063] Figure 3 is a sequence drawing of a method of UPF discovery and selection, in accordance with an embodiment of the disclosure;

[0064] Figure 4 (including 4A and 4B on separate pages) is a sequence drawing of a method for an SMF selecting a UPF for 2G / 3G access based on UPF capability and 2G / 3G location;

[0065] Figure 5 is a schematic of an example cellular communications system in which some embodiments of the present disclosure may be implemented;

[0066] Figures 6A and 6B are block diagrams of a wireless communication system represented as a 5G network architecture in which some embodiments of the present disclosure may be implemented;

[0067] Figures 7 and 9 are block diagrams of a radio access node according to some embodiments of the present disclosure;

[0068] Figure 8 is a block diagram that illustrates a virtualized embodiment of a radio access node according to some embodiments of the present disclosure; and

[0069] Figures 10 and 11 are block diagrams of a wireless communication device.

[0070] Detailed Description of Embodiments

[0071]

[0042] It should be understood at the outset that although illustrative implementations of one or more embodiments of the present disclosure are provided below, the disclosed systems and / or methods may be implemented using any number of techniques. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended embodiment along with their full scope of equivalents.

[0072] Introduction

[0073]

[0043] Referring now to Figure 2, shown is a block diagram of another communication system 200, in accordance with an embodiment of the disclosure. The communication system 200 has a UE 205 capable of accessing a network 232 via at least 2G / 3G. The communication system 200 also has a first network node 210 implementing an SMF (Session Management Function), a second network node 220 implementing an NRF (Network Repository Function), and may have several other network nodes such as user plane nodes 233a-c.

[0074]

[0044] The first network node 210 has a network interface 215 configured to communicate with other nodes of the communication system 200, a CRM 219, and UPF selection circuitry 216 coupled to the network interface 215 and the CRM 219. In some implementations, the UPF selection circuitry 216 includes a processor 217 that executes software, which can stem from a memory 218. However, other implementations are possible and are within the scope of this disclosure. The first network node 210 can have additional components, but these are not shown for simplicity. Other implementations are possible.

[0075]

[0045] The second network node 220 has a network interface 225 configured to communicate with other nodes of the communication system 200, a CRM 229, and UPF discovery circuitry 226 coupled to the network interface 225 and the CRM 229. In some implementations, the UPF discovery circuitry 226 includes a processor 227 that executes software, which can stem from a memory 228. However, other implementations are possible and are within the scope of this disclosure. The first network node 220 can have additional components, but these are not shown for simplicity. Other implementations are possible.

[0076]

[0046] The UPF selection circuitry 216 of the first network node 210 and the UPF discovery circuitry 226 of the second network node 220 implement a method of UPF discovery and selection. Such operation will be described below with reference to Figure 3. Although the method of Figure 3 is described below with reference to the communication system 200 shown in Figure 2, it is to be understood that the method of Figure 3 is applicable to other communication systems. In general, the method of Figure 3 is applicable to any appropriately configured communication system.

[0047] At step 301, the SMF 210 receives a Create PDP Context Request. Although Figure 3 shows this signal being received directly from the UE 205, it is noted that it can instead be received from an intermediate node (not shown) such as an SGSN responsive to a UE-initiated request. At step 302, in response to the Create PDP Context Request, the SMF 210 sends an NRF Discovery Request to the NRF 220. The NRF Discovery Request includes a first query parameter for 2G / 3G access and / or a second query parameter for indicated 2G / 3G location. The indicated 2G / 3G location can correspond to a current location or region of the UE 205, or a preferred location or region.

[0077]

[0048] At step 303, for each UPF 233a-c, the NRF 220 discovers the UPF 233a-c in terms of 2G / 3G access and / or 2G / 3G location. In some implementations, for each UPF 233a-c, discovering the UPF 233a-c in terms of 2G / 3G access and / or 2G / 3G location involves receiving an NRF Management Register Request indicating 2G / 3G access and / or 2G / 3G location. Note that step 3-3 could be executed prior to steps 301 and 302. The particular order shown in Figure 3 is not essential. An example in which UPF discovery by the NRF 220 occurs before the signalling shown at steps 301 and 302 is provided later with reference to Figure 4.

[0078]

[0049] At step 304, the NRF 220 determines a UPF list based on the discovering and the NRF Discovery Request. Thus, the UPF list identifies one or more UPFs 233a-c that support 2G / 3G access and / or the indicated 2G / 3G location, in accordance with the NRF Discovery Request. Furthermore, the NRF 220 provides the UPF list to the SMF 210 at step 305.

[0079]

[0050] At step 306, the SMF 210 selects a UPF (e.g. the first UPF 233a) from the UPF list. In this way, the SMF 210 can select a UPF that supports 2G&3G access and / or supports the current UE 2G / 3G ULI location. At step 307, the SMF 210 establishes a PDP context with the UPF that has been selected. Finally, at step 308, the SMF 210 sends a Create PDP Context Response in response to establishing the PDP Context.

[0080]

[0051] In this way, for the PDP context create request from 2G / 3G, if SMF role is determined, the SMF 210 can select the UPF 233a that supports 2G&3G access and / or supports the current UE 2G / 3G ULI location.

[0052] In some implementations, the NRF Discovery Request includes the first query parameter for 2G / 3G access. In some implementations, the NRF Discovery Request includes the second query parameter for indicated 2G / 3G location. In some implementations, the NRF Discovery Request includes both the first query parameter and the second query parameter.

[0081]

[0053] In some implementations, the UPF list identifies a plurality of UPFs that support 2G / 3G access and / or the indicated 2G / 3G location, in accordance with the NRF Discovery Request. Furthermore, selecting the UPF 233a from the UPF list involves selecting the UPF 233a from the plurality of UPFs 233a-c based on at least one of: dedicated UPF for 2G / 3G access, security consideration, low bandwidth and less enhanced UPF functions, and UE current location of 2G / 3G. Example details of these factors are provided below.

[0082]

[0054] A first factor is “Dedicated UPF for 2G / 3G access”. The operator may want to use some dedicated UPF for Gn / Gp, or Gp roaming traffic, even all the UPFs may support Gn / Gp traffic. Same as the existing IE: IPUPS as defined in 3GPP TS 29.510 entitled “5G System; Network function repository services; Stage 3” version 19.0.0 uploaded 2024-09-19 (hereinafter “TS 29.510”):

[0083] • Any UPF can support the IPUPS functionality. In network deployments where specific UPFs are used to provide IPUPS, UPFs configured for providing IPUPS services shall be selected to provide IPUPS.

[0084]

[0055] A second factor is “Security consideration”. Operators may select certain UPFs for outbound roamers and certain UPFs for inbound roamers of 2G / 3G from security point of view. As well current 5G NR, 4G LTE outbound roamer and inbound roamers.

[0085]

[0056] A third factor is “Low bandwidth and less enhanced UPF functions”. The operator may consider the bandwidth as 3G requires low bandwidth in UPF, certain UPF can be dimensioned to server 2 / 3G low bandwidth purpose and less enhanced UPF functions.

[0057] A fourth factor is “UE current location of 2G / 3G”. The operator may select the UPF by consider the UE current location, e.g. RAI, and / or SAI.

[0086]

[0058] According to another embodiment of the disclosure, there is provided a non-transitory CRM having recorded thereon statements and instructions that, when executed by the processor 217 of the first network node 210, implement a method as described herein. The non-transitory computer readable medium can be the memory 218 and / or the CRM 219 of the first network node 210 shown in Figure 2, or some other non-transitory CRM.

[0087]

[0059] According to another embodiment of the disclosure, there is provided a non-transitory CRM having recorded thereon statements and instructions that, when executed by the processor 227 of the second network node 220, implement a method as described herein. The non-transitory computer readable medium can be the memory 228 and / or the CRM 229 of the second network node 220 shown in Figure 2, or some other non-transitory CRM.

[0088]

[0060] Examples of a non-transitory CRM include memory, an SSD (Solid State Drive), a hard disk drive, a CD (Compact Disc), a DVD (Digital Video Disc), a BD (Blu-ray Disc), a memory stick, etc. Other non-transitory CRMs are also possible.

[0089]

[0061] The illustrated examples described herein focus on software implementations. However, other implementations are possible and are within the scope of this disclosure. Other implementations can include additional or alternative hardware components, such as any appropriately configured FPGA (Field-Programmable Gate Array), ASIC (Application-Specific Integrated Circuit), and / or microcontroller, for example. Thus, the circuitry 216 of first network node 210 and the circuitry 226 of the second network node 220 can instead be implemented with any suitable combination of hardware, software and / or firmware.

[0090]

[0062] There are many possibilities for the network 232. In some implementations, the network 232 includes 2G and 3G networks. In some implementations, the network 232 includes a 4G network. In some implementations, the network 232 includes a 5G network. Example details of a 5G network are provided later. Other implementations are possible beyond 5G, for example 6G.

[0091]

[0063] Further example details are provided in the following sections. It is to be understood that the following sections are very specific and are provided merely for exemplary purposes, such that other implementations are possible and within the scope of the disclosure.

[0092]

[0093]

[0064] Referring now to Figure 4, shown is a sequence drawing of a method for an SMF selecting a UPF for 2G / 3G access based on UPF capability and 2G / 3G location. Figure 4 is split into two parts: Figure 4A (i.e. steps 401 to 406) in which UPF1 233a, UPF2 233b and UPF3 233c register with an NRF 220, and Figure 4B (i.e. steps 407 to 417) in which the SMF 210 discovers and selects one of the UPFs 233a-c for 2G / 3G access.

[0094]

[0065] At step 401, the UPF1 233a sends to the NRF 220 an Nnrf_NFManagement_NFRegister Request (upf1(upfinfo: 2g3glnd, 2g3gLocationList, 2g3gLocationRangeList)). Note that 2g3gLocation means 2G3G location area, e.g. ULI, RAI, SAI, cell ID. At step 402, the NRF 220 sends to the UPF1 233a an Nnrf_NFManagement_NFRegister Response.

[0095]

[0066] At step 403, the UPF2 233b sends to the NRF 220 an Nnrf_NFManagement_NFRegister Request (upf2(upfinfo:iwkepslnd). At step 404, the NRF 220 sends to the UPF2 233b an Nnrf_NFRegistration Response.

[0096]

[0067] At step 405, the UPF3 233c sends to the NRF 220 an Nnrf_NFManagement_NFRegister Request (upf1(upfinfo: 2g3glnd, 2g3gLocationList, 2g3gLocationRangeList)). At step 406, the NRF 220 sends to the UPF3 233c an Nnrf_NFManagement_NFRegister Response.

[0097]

[0068] In this way, each UPF 233a-c performs NRF Registration with upflnfo that is including the following new lEs:

[0098] • 2G3Glnd”, that indicates that the UPF supports 2G / 3G access; • 2g3g Location List, 2g3gLocationRangeList”, that indicates that the UPF supports the 2G / 3G ULI Range List.

[0099] Note: 2g3gLocation means 2G3G location area, e.g ULI, RAI, SAI, cell ID.

[0100] • interfaceType (Gn / Gp-U), that indicates the UPF Gn / Gp-U IP address information.

[0101]

[0069] Example details of upflnfo are provided in Table 6.1.6.2.13-1 below.

[0102] Table 6.1.6.2.13-1: Definition of type UpfInfo

[0103]

[0104]

[0070] Following the registration by the UPFs 233a-c with the NRF 220 (Figure 4A), there is a UE Initiated PDP Context Activation for GERAN / UTRAN Access (Figure 4B). The steps are described below.

[0071] At step 407, a UE 205 sends an Activate PDP Context Request to an SGSN. At step 408, the SGSN sends a Create PDP Context Request (IMSI, RAT: GERAN / UTRAN, ULI, RAI) to the SMF 210.

[0105]

[0072] At step 409, the SMF 210 sends to the NRF 220 an Nnrf_NFDiscovery_Request (discover UPF, query parameter: 2g3glnd, preferred-2g3gLocation). At step 410, the NRF 220 sends to the SMF 210 an Nnrf_NFDiscovery Response (upf1 / n-info(2g3glnd, 2g3gLocationList, 2g3gLocationRangeList).

[0106]

[0073] Next, at step 410a, the SMF 210 selects the UPF1 233a based on UE Location and / or "2g3glnd". Note that the selection can depend on many factors. According to an embodiment, those factors can include UE location and / or "2g3glnd". For example, preference can be given to a UPF that supports 2G&3G access and / or supports the current UE 2G / 3G ULI location. Other example factors that may be taken into consideration can include dedicated UPF for 2G / 3G access, security considerations, low bandwidth and less enhanced UPF functions, and UE current location of 2G / 3G, as already described above.

[0107]

[0074] At step 411, the SMF 210 and the NRF 220 have NRF Discovery for PCF. At step 412, the SMF 210 sends to the PCF an Npcf_SMPolicyControl_Create Request (PDU Session ID, RAT: GERAN / UTRAN, serving node: SGSN, ULI). At step 413, the PCF sends to the SMF 210 an Npcf_SMPolicyControl_Create Response (NR QoS-1).

[0108]

[0075] At step 414, the SMF 210 sends to the UPF1 233a a PFCP Session Establishment Request. At step 415, the UPF1 233a sends to the SMF 210 a PFCP Session Establishment Response. At step 416, the SMF 210 sends to the SGSN a Create PDP Context Response. At step 417, the SGSN sends to the UE 205 an Activate PDP Context Response.

[0109]

[0076] In this way, when the SMF 210 receives the Create PDP Context Request from 2G / 3G access, the SMF 210 sends the NRF discovery request for UPF with the query parameters including one or all of the following new lEs:

[0110] • 2g3glnd

[0111] • preferred-2g3gLocation The NRF 220 will return the UPF list that support 2g3glnd and preferred-2g3gLocation, and the SMF 210 selects the UPF that supports 2G&3G access and supports the current UE 2G / 3G ULI location. In some implementations, a GET method is used for the discovery.

[0112] Table 6.2.3.2.3.1-1: URI query parameters supported by the GET method on this resource

[0113]

[0114] Example Implementation with Standard

[0115]

[0077] Example details are provided below as to how some embodiments can be implemented with appropriate changes to TS 29.510. It is to be understood that these example details are very specific for exemplary purposes only.

[0078] Reason for change:

[0116] • 3GPP has clarified that the PGW-C+SMF was enhanced to support GERAN / UTRAN access via Gn / Gp interface, e.g.

[0117] o TS 23.501 Annex L (normative): Support of GERAN / UTRAN access:

[0118] ■ This annex applies when the SMF+PGW-C is enhanced to support UE accessing the network via GERAN / UTRAN over Gn / Gp interface. For this scenario, the SMF+PGW-C uses N7 interface to interact with PCF and the N40 interface to interact with CHF.

[0119] ■ NOTE 1: For the interface with the serving node of the UE, the SMF+PGW-C is assumed to behave as the Control Plane of the PGW described in Annex D of TS 23.401.

[0120] • Also TS 23.502 Annex G (normative): Support of GERAN / UTRAN access by SMF+PGW-C:

[0121] o This annex applies when the SMF+PGW-C is enhanced to support GERAN / UTRAN access via Gn / Gp interface as specified in Annex L of TS 23.501.

[0122] • Accordingly, the SMF+PGW-C supporting 2G / 3G access may need to select UPF with corresponding 2G / 3G information.

[0123] • This CR propose to add the corresponding 2G / 3G information for UPF selection to fulfil the stage 2 requirement.

[0124]

[0079] Summary of change:

[0125] • 1 / Extend Upflnfo data type to include the information related to 2G / 3G access (interworking indication, serving 2G / 3G location area).

[0126] • 2 / Add new enumeration value in UPlnterfaceType for GnU and GpU.

[0127] • 3 / Add new query parameters for discovery UPF with 2G / 3G access interworking with feature control

[0128] • 4 / Update OpenAPI accordingly.

[0129]

[0080] Consequences if not approved:

[0130] • When SMF+PGW-C is configured to support 2G / 3G access, it is not possible to discover the UPF serving specific 2G / 3G location area via NRF.

[0131]

[0132] 6.1.6.1 General

[0133] This clause specifies the application data model supported by the API.

[0134] Table 6.1.6.1-1 specifies the data types defined for the Nnrf_NF Managem ent service-based interface protocol. Table 6.1.6.1-1: Nnrf_NFManagement specific Data Types

[0135]

[0136] Table 6.1.6.1-2 specifies data types re-used by the Nnrf_NFManagement service-based interface protocol from other specifications, including a reference to their respective specifications and when needed, a short description of their use within the Nnrf_NFManagement service-based interface.

[0137] Table 6.1.6.1-2: Nnrf_NFManagement re-used Data Types

[0138]

[0139]

[0140] 6.1.6.2.13 Type: UpfInfo

[0141] Table 6.1.6.2.13-1: Definition of type UpfInfo

[0142]

[0143]

[0144] * * * Next Changes

[0145]

[0146] .1.6.2. xx Type: 2G3GLocationArea

[0147] Table 6.1.6.2.xx-1: Definition of type 2G3GLocationArea

[0148]

[0149] * * * Next Changes * * * *

[0150]

[0151] .1.6.2.yy Type: 2G3GLocationAreaRange

[0152] Table 6.1.6.2.yy-1: Definition of type 2G3GLocationAreaRange

[0153]

[0154] * * * Next Changes

[0155]

[0156] 1.6.2.zz Type: CellGlobalIdRange

[0157] Table 6.1.6.2.zz-1: Definition of type CellGlobalIdRange

[0158]

[0159] * * * Next Changes * * * *

[0160]

[0161] 1.6.2.aa Type: ServiceAreaIdRange

[0162] Table 6.1.6.2.aa-1: Definition of type ServiceAreaIdRange

[0163]

[0164]

[0165] 6.1.6.2.mm Type: LocationAreaIdRange

[0166] Table 6.1.6.2.mm-1: Definition of type LocationAreaIdRange

[0167]

[0168]

[0169] 6.1.6.2.nn Type: RoutingAreaIdRange

[0170] Table 6.1.6.2.nn-1: Definition of type RoutingAreaIdRange

[0171]

[0172]

[0173] 6.1.6.3.9 Enumeration: UPInterfaceType

[0174] Table 6.1.6.3.9-1: Enumeration UPInterfaceType

[0175]

[0176]

[0177] 6.2.3.2.3.1 GET

[0178] This operation retrieves a list of NF Instances, and their offered services, currently registered in the NRF, satisfying a number of filter criteria, such as those NF Instances offering a certain service name, or those NF Instances of a given NF type (e.g., AMF).

[0179] Table 6.2.3.2.3.1-1: URI query parameters supported by the GET method on this resource

[0180]

[0181] When certain query parameters in the discovery request are not supported by the NRF, the NRF shall ignore the unsupported query parameters and continue processing the request with the supported query parameters. The default logical relationship among the supported query parameters is logical "AND", i.e. all the provided query parameters shall be matched, with the exception of the "preferred-locality", "ext-preferred-locality", "preferred-nf-instances", "preferred-tai", "preferred-api-versions", "preferred-full-plmn", "preferred-collocated-nf-types", "preferred-pgw-ind", "preferred-analytics-delays", "preferred-features", "mbs-session-id", "ind-com-with-del-disc" and "ind-com-wo-del-disc" query parameters (see Table 6.2.3.2.3.1-1).

[0182] The NRF may support the Complex query expression as defined in 3GPP TS 29.501 [5] for the NF Discovery service. If the "complexQuery" query parameter is included, then the logical relationship among the query parameters contained in "complexQuery" query parameter is as defined in 3GPP TS 29.571 [7],

[0183] A NRF not supporting Complex query expression shall reject a NF service discovery request including a complexQuery parameter, with a ProblemDetails IE including the cause attribute set to INVALID_QUERY_PARAM and the invalidParams attribute indicating the complexQuery parameter.

[0184] This method shall support the request data structures specified in table 6.1.3.2.3.1-2 and the response data structures and response codes specified in table 6.1.3.2.3.1-3.

[0185] Table 6.2.3.2.3.1-2: Data structures supported by the GET Request Body on this resource

[0186]

[0187] Table 6.2.3.2.3.1-3: Data structures supported by the GET Response Body on this resource

[0188]

[0189]

[0190]

[0191] Table 6.2.3.2.3.1-4: Headers supported by the GET method on this endpoint

[0192]

[0193] Table 6.2.3.2.3.1-5: Headers supported by the 200 Response Code on this endpoint

[0194]

[0195] Table 6.2.3.2.3.1-6: Headers supported by the 307 Response Code on this endpoint

[0196]

[0197] Table 6.2.3.2.3.1-7: Links supported by the 200 Response Code on this endpoint

[0198]

[0199]

[0200] 6.2.9 Features supported by the NFDiscovery service

[0201] The syntax of the supportedFeatures attribute is defined in clause 5.2.2 of 3GPP TS 29.571 [7],

[0202] The following features are defined for the Nnrf_NFDiscovery service.

[0203] Table 6.2.9-1: Features of supportedFeatures attribute used by Nnrf_NFDiscovery service

[0204]

[0205]

[0206] A.2 Nnrf_NFManagement API

[0207] *********** Text skipped for Clarity ************

[0208] Upflnfo:

[0209] description: Information of an UPF NF Instance

[0210] type: object

[0211] required:

[0212] - sNssaiUpfInfoList

[0213] properties:

[0214] sNssaiUpfInfoList:

[0215] type: array items:

[0216] $ref: '# / components / schemas / SnssaiUpfInfoItem'

[0217] minltems: 1

[0218] smfServingArea:

[0219] type: array

[0220] items:

[0221] type: string

[0222] minltems: 1

[0223] interfaceUpfInfoList:

[0224] type: array

[0225] items:

[0226] $ref: '# / components / schemas / InterfaceUpfInfoItem'

[0227] minltems: 1

[0228] n6TunnelInfoList:

[0229] description: >

[0230] A map of InterfaceUpfInfoItems containing the N6 tunnelling information for establishing a N6 tunnel between the V-UPF and the V-EASDF, where a valid JSON string serves as key. type: object

[0231] additionalProperties:

[0232] $ref: '# / components / schemas / InterfaceUpfInfoItem'

[0233] minProperties: 1

[0234] iwkEpsInd:

[0235] type: boolean

[0236] default: false

[0237] sxalnd:

[0238] type: boolean

[0239] pduSessionTypes:

[0240] type: array

[0241] items:

[0242] $ref: 'TS29571_CommonData.yaml# / components / schemas / PduSessionType' minltems: 1

[0243] atsssCapability:

[0244] $ref: 'TS29571_CommonData.yaml# / components / schemas / AtsssCapability' ueIpAddrInd:

[0245] type: boolean

[0246] default: false

[0247] taiList:

[0248] type: array

[0249] items:

[0250] $ref: 'TS29571_CommonData.yaml# / components / schemas / Tai'

[0251] minltems: 1

[0252] taiRangeList:

[0253] type: array

[0254] items:

[0255] $ref: '# / components / schemas / TaiRange'

[0256] minltems: 1

[0257] wAgfInfo:

[0258] $ref: '# / components / schemas / WAgfInfo'

[0259] tngfInfo:

[0260] $ref: '# / components / schemas / TngfInfo'

[0261] twifInfo: $ref: '# / components / schemas / Twiflnfo'

[0262] preferredEpdglnfoList:

[0263] type: array

[0264] items:

[0265] $ref: '# / components / schemas / EpdgInfo'

[0266] minltems: 1

[0267] preferredWAgflnfoList:

[0268] type: array

[0269] items:

[0270] $r ef: '# / com pon en ts / sch em as / WAgf I nf o’

[0271] minltems: 1

[0272] preferredTngflnfoList:

[0273] type: array

[0274] items:

[0275] $ref: '# / components / schemas / TngfInfo'

[0276] minltems: 1

[0277] preferredTwiflnfoList:

[0278] type: array

[0279] items:

[0280] $ref: '# / components / schemas / TwifInfo'

[0281] minltems: 1

[0282] priority:

[0283] type: integer

[0284] minimum: 0

[0285] maximum: 65535

[0286] redundantGtpu:

[0287] type: boolean

[0288] default: false

[0289] ipups:

[0290] type: boolean

[0291] default: false

[0292] dataForwarding:

[0293] type: boolean

[0294] default: false

[0295] supportedPfcpFeatures:

[0296] type: string

[0297] upfEvents:

[0298] type: array

[0299] items:

[0300] $ref: 'TS29564_Nupf_EventExposure.yaml# / components / schemas / EventType' minltems: 1

[0301]

[0302] minltems: 1

[0303] 2g3gLocationAreaRangeList:

[0304] type: array

[0305] items:

[0306] $ref: '# / components / schemas / 2G3GLocationAreaRange'

[0307] minltems: 1 *********** Text skipped for Clarity ************ UPlnterfaceType:

[0308] description: Types of User-Plane interfaces of the UPF anyOf:

[0309] - type: string

[0310] enum:

[0311] - N3

[0312] - N6

[0313] - N9

[0314] - DATA_FORWARDING

[0315] - N3MB

[0316] - N6MB

[0317] - N19MB

[0318] - NMB9

[0319] - S1U

[0320] - S5U

[0321] - S8U

[0322] - S11U

[0323] - S12

[0324] - S2AU

[0325] - S2BU

[0326] - N3TRUSTEDN3GPP - N3UNTRUSTEDN3GPP

[0327] - N9ROAMING

[0328] - SGI

[0329] - N19

[0330] - SXAU

[0331] - SXBU

[0332] - N4U

[0333] - GnU

[0334] - GpU

[0335] - type: string

[0336] *********** Text Skipped for Clarity ************

[0337] DnsSecurityProtocol:

[0338] description: DNS security protocol

[0339] anyOf:

[0340] - type: string

[0341] enum:

[0342] - TLS

[0343] - DTLS

[0344] - type: string

[0345] 2G3GLocationArea:

[0346] description: 2G / 3G Location Area,

[0347] type: object

[0348] properties:

[0349]

[0350]

[0351] type: string

[0352] pattern: 'A[A-Fa-fO-9]{4}$'

[0353] endLac:

[0354] type: string

[0355] pattern: 'A[A-Fa-fO-9]{4}$'

[0356] startRac:

[0357] type: string

[0358] pattern: 'A[A-Fa-fO-9]{2}$'

[0359] endRac:

[0360] type: string

[0361] pattern: 'A[A-Fa-fO-9]{2}$'

[0362] * * * Next Changes

[0363]

[0364] >

[0365] A.3 Nnrf_NFDiscovery API

[0366] *********** Text skipped for Clarity ************

[0367] - name: ind-com-wo-del-disc

[0368] in: query

[0369] description: >

[0370] Indicates that indirect communication without delegated discovery

[0371] with NF selection at target domain feature is supported.

[0372] schema:

[0373] type: boolean

[0374] enum:

[0375] - true

[0376] - name: upf-iwk-2g3g-ind

[0377] in: guery

[0378] description: >

[0379] > Indicates that the candidate UPF supporting 2G / 3G Access interwork is to be discovered.

[0380] schema:

[0381] > type: boolean

[0382] > enum:

[0383] > - true

[0384] - name: 2g3g-location-area

[0385] in: query

[0386] description: >

[0387] > Indicates the 2G / 3G location area that can be served by the candidate UPF.

[0388] schema:

[0389] > $ref: 'TS29510_Nnrf_NFManagement.yaml# / components / schemas / 2G3GLocationArea'

[0390] responses:

[0391] '200':

[0392] *********** Text Skipped for Clarity ************

[0393]

[0394] Additional Details

[0395]

[0081] Additional details are provided below with reference to Figures 5 through 11. It is to be understood that these details are very specific for exemplary purposes only.

[0396]

[0082] Figure 5 illustrates one example of a cellular communications system 500 in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communications system 500 is a 5GS 330 including a NG-RAN (Next Generation RAN) and a 5GC (5G Core). In this example, the RAN includes base stations 502-1 and 502-2, which in the 5GS 330 include NR base stations (gNBs) and optionally next generation eNBs (ng-eNBs) (e.g., LTE RAN nodes connected to the 5GC), controlling corresponding (macro) cells 504-1 and 504-2. The base stations 502-1 and 502-2 are generally referred to herein collectively as base stations 502 and individually as base station 502. Likewise, the (macro) cells 504-1 and 504-2 are generally referred to herein collectively as (macro) cells 504 and individually as (macro) cell 504. The RAN may also include a number of low power nodes 506-1 through 506-4 controlling corresponding small cells 508-1 through 508-4. The low power nodes 506-1 through 506-4 can be small base stations (such as pico or femto base stations) or RRHs (Remote Radio Heads), or the like. Notably, while not illustrated, one or more of the small cells 508-1 through 508-4 may alternatively be provided by the base stations 502. The low power nodes 506-1 through 506-4 are generally referred to herein collectively as low power nodes 506 and individually as low power node 506. Likewise, the small cells 508-1 through 508-4 are generally referred to herein collectively as small cells 508 and individually as small cell 508. The cellular communications system 500 also includes a core network 510, which in the 5GS 330 is referred to as the 5GC. The base stations 502 (and optionally the low power nodes 506) are connected to the core network 510.

[0397]

[0083] The base stations 502 and the low power nodes 506 provide service to wireless communication devices 512-1 through 512-5 in the corresponding cells 504 and 508. The wireless communication devices 512-1 through 512-5 are generally referred to herein collectively as wireless communication devices 512 and individually as wireless communication device 512. In the following description, the wireless communication devices 512 are oftentimes UEs, but the present disclosure is not limited thereto.

[0398]

[0084] Referring now to Figure 6A, shown is a block diagram of a wireless communication system represented as a 5G network architecture composed of core NFs (Network Functions), where interaction between any two NFs is represented by a point-to-point reference point / interface. Figure 6A can be viewed as one particular implementation of the system 500 of Figure 5.

[0399]

[0085] Seen from the access side the 5G network architecture shown in Figure 6A includes a plurality of UEs 613 connected to either a RAN 607 or an (Access Network) as well as an AMF 600. Typically, the R(AN) 607 includes base stations, e.g. such as eNBs or gNBs or similar. Seen from the core network side, the 5GC NFs shown in Figure 6A include a NSSF 602, an AUSF 604, a UDM 606, the AMF 600, a SMF 608, a PCF 610, and an AF (Application Function) 612.

[0400]

[0086] 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 613 and AMF 600. The reference points for connecting between the AN 607 and AMF 600 and between the AN 607 and UPF 614 are defined as N2 and N3, respectively. There is a reference point, N11, between the AMF 600 and SMF 608, which implies that the SMF 608 is at least partly controlled by the AMF 600. N4 is used by the SMF 608 and UPF 614 so that the UPF 614 can be set using the control signal generated by the SMF 608, and the UPF 614 can report its state to the SMF 608. N9 is the reference point for the connection between different UPFs 614, and N14 is the reference point connecting between different AMFs 600, respectively. N15 and N7 are defined since the PCF 610 applies policy to the AMF 600 and SMF 608, respectively. N12 is utilized for the AMF 600 to perform authentication of the UE 613. N8 and N10 are defined because the subscription data of the UE 613 is utilized for the AMF 600 and SMF 608.

[0401]

[0087] The 5GC network aims at separating UP and CP. The UP carries user traffic while the CP carries signaling in the network. In Figure 6A, the UPF 614 is in the UP and all other NFs, i.e., the AMF 600, SMF 608, PCF 610, AF 612, NSSF 602, AUSF 604, and UDM 606, are in the CP. Separating the UP and CP guarantees each plane resource to be scaled independently. It also allows UPFs to be deployed separately from CP functions in a distributed fashion. In this architecture, UPFs may be deployed very close to UEs to shorten the RTT (Round Trip Time) between UEs and data network for some applications involving low latency.

[0402]

[0088] The core 5G network architecture is composed of modularized functions. For example, the AMF 600 and SMF 608 are independent functions in the CP. Separated AMF 600 and SMF 608 allow independent evolution and scaling. Other CP functions like the PCF 610 and AUSF 604 can be separated as shown in Figure 6A. Modularized function design enables the 5GC network to support various services flexibly.

[0403]

[0089] 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 CP, a set of interactions between two NFs is defined as service so that its reuse is possible. This service enables support for modularity. The UP supports interactions such as forwarding operations between different UPFs.

[0404]

[0090] Referring now to Figure 6B, shown is a block diagram of a 5G network architecture using service-based interfaces between the NFs in the CP, instead of the point-to-point reference points / interfaces used in the 5G network architecture of Figure 6A. However, the NFs described above with reference to Figure 6B correspond to the NFs shown in Figure 6A. The service(s) etc. that a NF provides to other authorized NFs can be exposed to the authorized NFs through the service-based interface. In Figure 6B, 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 600 and Nsmf for the service based interface of the SMF 608, etc. The NEF 603 and the NRF 601 in Figure 6B are not shown in Figure 6A discussed above. However, it should be clarified that all NFs depicted in Figure 7A can interact with the NEF 603 and the NRF 601 of Figure 6B as necessary, though not explicitly indicated in Figure 6A.

[0405]

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

[0406]

[0092] 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.

[0407]

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

[0408]

[0094] Figure 8 is a schematic block diagram that illustrates a virtualized embodiment of the radio access node 700 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.

[0409]

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

[0410]

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

[0411]

[0097] 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 radio access node 700 or a node (e.g., a processing node 800) implementing one or more of the functions 810 of the radio access node 700 in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier having 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).

[0412]

[0098] Figure 9 is a schematic block diagram of the radio access node 700 according to some other embodiments of the present disclosure. The radio access node 700 includes one or more modules 800, each of which is implemented in software. The module(s) 800 provide the functionality of the radio access node 700 described herein. This discussion is equally applicable to the processing node 800 of Figure 8 where the modules 800 may be implemented at one of the processing nodes 800 or distributed across multiple processing nodes 800 and / or distributed across the processing node(s) 800 and the control system 702.

[0413]

[0099] Figure 10 is a schematic block diagram of a wireless communication device 900 according to some embodiments of the present disclosure. As illustrated, the wireless communication device 900 includes one or more processors 902 (e.g., CPUs, ASICs, FPGAs, and / or the like), memory 904, and one or more transceivers 906 each including one or more transmitters 908 and one or more receivers 910 coupled to one or more antennas 912. The transceiver(s) 906 includes radio-front end circuitry connected to the antenna(s) 912 that is configured to condition signals communicated between the antenna(s) 912 and the processor(s) 902, as will be appreciated by on of ordinary skill in the art. The processors 902 are also referred to herein as processing circuitry. The transceivers 906 are also referred to herein as radio circuitry. In some embodiments, the functionality of the wireless communication device 900 described above may be fully or partially implemented in software that is, e.g., stored in the memory 904 and executed by the processor(s) 902. Note that the wireless communication device 900 may include additional components not illustrated in Figure 10 such as, e.g., one or more user interface components (e.g., an input / output interface including a display, buttons, a touch screen, a microphone, a speaker(s), and / or the like and / or any other components for allowing input of information into the wireless communication device 900 and / or allowing output of information from the wireless communication device 900), a power supply (e.g., a battery and associated power circuitry), etc.

[0414]

[0100] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the wireless communication device 900 according to any of the embodiments described herein is provided. In some embodiments, a carrier having 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).

[0415]

[0101] Figure 11 is a schematic block diagram of the wireless communication device 900 according to some other embodiments of the present disclosure. The wireless communication device 900 includes one or more modules 1000, each of which is implemented in software. The module(s) 1000 provide the functionality of the wireless communication device 900 described herein.

[0416]

[0102] Each station 1106A, 1106B, 1106C is connectable to the core network 1104 over a wired or wireless connection 1110. A first UE 1112 located in coverage area 1108C is configured to wirelessly connect to, or be paged by, the corresponding base station 1106C. A second UE 1114 in coverage area 1108A is wirelessly connectable to the corresponding base station 1106A. While a plurality of UEs 1112, 1114 are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station 1106.

[0417]

[0103] The telecommunication network 1100 is itself connected to a host computer 1116, which may be embodied in the hardware and / or software of a standalone server, a cloud-implemented server, a distributed server, or as processing resources in a server farm. The host computer 1116 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. Connections 1118 and 1120 between the telecommunication network 1100 and the host computer 1116 may extend directly from the core network 1104 to the host computer 1116 or may go via an optional intermediate network 1122. The intermediate network 1122 may be one of, or a combination of more than one of, a public, private, or hosted network; the intermediate network 1122, if any, may be a backbone network or the Internet; in particular, the intermediate network 1122 may have two or more sub-networks (not shown).

[0418]

[0104] 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 have 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 DSPs (Digital Signal Processor), 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 ROM (Read Only Memory), RAM (Random Access Memory), 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.

[0105] 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.).

[0419]

[0106] Numerous modifications and variations of the present disclosure are possible in light of the above teachings. It is therefore to be understood that within the scope of the appended embodiments, the disclosure may be practised otherwise than as specifically described herein.

Claims

Claims:

1. A method for execution by a network node implementing an SMF (Session Management Function), comprising:sending an NRF (Network Repository Function) Discovery Request for UPF (User Plane Function), wherein the NRF Discovery Request comprises a first query parameter for 2G / 3G access and / or a second query parameter for indicated 2G / 3G location;receiving a UPF list of one or more UPFs that support 2G / 3G access and / or the indicated 2G / 3G location, in accordance with the NRF Discovery Request; andselecting a UPF from the UPF list.

2. The method of claim 1, further comprising:receiving a Create PDP (Packet Data Protocol) Context Request, wherein the NRF Discovery Request is sent in response to receiving the Create PDP Context Request;establishing a PDP Context with the UPF that has been selected; andsending a Create PDP Context Response in response to establishing the PDP Context.

3. The method of claim 1 or claim 2, wherein the NRF Discovery Request comprises the first query parameter for 2G / 3G access.

4. The method of claim 1 or claim 2, wherein the NRF Discovery Request comprises the second query parameter for indicated 2G / 3G location.

5. The method of claim 1 or claim 2, wherein the NRF Discovery Request comprises both the first query parameter and the second query parameter.

6. The method of any one of claims 1 to 5, wherein:the UPF list identifies a plurality of UPFs that support 2G / 3G access and / or the indicated 2G / 3G location, in accordance with the NRF Discovery Request; andselecting the UPF from the UPF list comprises selecting the UPF from the plurality of UPFs based on at least one of: dedicated UPF for 2G / 3G access, security consideration, low bandwidth and less enhanced UPF functions, and UE current location of 2G / 3G.

7. A non-transitory CRM (computer readable medium) having recorded thereon statements and instructions that, when executed by a processor of a network node, configure the network node to implement a method according to any one of claims 1 to 6.

8. A network node implementing an SMF (Session Management Function), comprising:a network interface configured to communicate with other network nodes;UPF (User Plane Function) selection circuitry configured to:send, over the network interface, an NRF (Network Repository Function) Discovery Request for UPF, wherein the NRF Discovery Request comprises a first query parameter for 2G / 3G access and / or a second query parameter for indicated 2G / 3G location;receive, over the network interface, a UPF list of one or more UPFs that support 2G / 3G access and / or the indicated 2G / 3G location, in accordance with the NRF Discovery Request; andselect a UPF from the UPF list.

9. The network node device of claim 8, wherein the UPF selection circuitry is further configured to implement a method according to any one of claims 2 to 6.

10. A method for execution by a network node implementing an NRF (Network Repository Function), comprising:receiving an NRF Discovery Request for UPF (User Plane Function), wherein the NRF Discovery Request comprises a first query parameter for 2G / 3G access and / or a second query parameter for indicated 2G / 3G location; andsending a UPF list of one or more UPFs that support 2G / 3G access and / or the indicated 2G / 3G location, in accordance with the NRF Discovery Request.

11. The method of claim 10, further comprising:for each UPF of a plurality of UPFs, discovering the UPF in terms of 2G / 3G access and / or 2G / 3G location; anddetermining the UPF list based on the discovering and the NRF Discovery Request.

12. The method of claim 11, wherein for each UPF, discovering the UPF in terms of 2G / 3G access and / or 2G / 3G location comprises:receiving an NRF Management Register Request indicating 2G / 3G access and / or 2G / 3G location.

13. The method of any one of claims 10 to 12, wherein the NRF Discovery Request comprises the first query parameter for 2G / 3G access.

14. The method of any one of claims 10 to 12, wherein the NRF Discovery Request comprises the second query parameter for indicated 2G / 3G location.

15. The method of any one of claims 10 to 12, wherein the NRF Discovery Request comprises both the first query parameter and the second query parameter.

16. A non-transitory CRM (computer readable medium) having recorded thereon statements and instructions that, when executed by a processor of a network node, configure the network node to implement a method according to any one of claims 10 to 15.

17. A network node implementing an NRF (Network Repository Function), comprising:a network interface configured to communicate with other network nodes;UPF (User Plane Function) discovery circuitry configured to:receive, over the network interface, an NRF Discovery Request for UPF, wherein the NRF Discovery Request comprises a first query parameter for 2G / 3G access and / or a second query parameter for indicated 2G / 3G location; andsend, over the network interface, a UPF list of one or more UPFs that support 2G / 3G access and / or the indicated 2G / 3G location, in accordance with the NRF Discovery Request.

18. The network node of claim 17, wherein the UPF discovery circuitry is further configured to implement a method according to any one of claims 11 to 15.

Images