The present disclosure relates to Network Address translation (NAT) in communications networks.
Network Address Translation (NAT) is a method of remapping one Internet Protocol (IP) address space into another IP address space by modifying network address information in the IP header of packets while they are in transit across a traffic routing device. Network Address and Port Translation (NAPT) also includes modifying the source port in the transport header. The NAT and the NAPT operate in a similar or corresponding manner.
NAT provides a translation technology which allows multiple end customers to use common and overlapping private IP address ranges internally. Any number of end customers can use the same private IP address ranges. To route to external Internet IP addresses, NAT translates the private IP addresses to public IP addresses, e.g. NAT44 which translates from private to public IPv4 address needed to cope with IPv4 address depletion.
With the advent of enterprise and home solutions and migration to IPv6, service providers have deployed Carrier Grade NAT (CGNAT) which provides additional NAT schemes such as NAT64 or NAT444.
Since NAT can break some upper application protocols which include the IP address value in their signaling (e.g. File Transfer Protocol (FTP), Session Initiation Protocol (SIP)), CGNAT needs to support Application Level Gateway (ALG) which modifies those protocols. CGNAT servers are usually deployed in the service provider service Local Area Network (LAN). Improved systems and methods for providing network address translation are needed.
Systems and methods for providing Network Address Translation (NAT) are provided. In some embodiments, a method of operating a function entity configured to support NAT includes enabling a Control Plane (CP) function to instruct a User Plane (UP) function to apply a NAT function for at least one specific service data flow. In this way, one or more benefits result such as: introducing a mechanism to allow CP function to instruct UP function to perform NAT function for one or more service data flow(s), when CP and UP function are separated; using NAT function can protect a private network from potential unlawful incursion; and delaying NAT Internet Protocol (IP) address and port allocation and withdraw at the service initiation and termination can save the public IP address space.
Also, embodiments of the current disclosure might result in one or more improvements such as allowing the network operator to support NAT policies in the context of 4G/5G networks supporting Control and User Plane Separation of EPC nodes (CUPS). This is of value, e.g., for Access Traffic Steering, Switching and Splitting (ATSSS) functionality where Session Management Functions (SMFs) can program the translation from a link specific address to the public IP address assigned to the Multi-access Packet Data Unit (PDU) session.
In some embodiments, the at least one specific service data flow belongs to a given Packet Flow Control Protocol (PFCP) session. In some embodiments, enabling the CP function to instruct the UP function comprises using a new UP function feature, which in some embodiments is called “Support of Network Address Translation in UP function”, NATU.
In some embodiments, enabling the CP function to instruct the UP function comprises using a new feature bit can be defined in a “UP function features” Information Element (IE). In some embodiments, enabling the CP function to instruct the UP function comprises using a new NAT IE in the Forwarding Parameters IE in the Forwarding Action Rule (FAR). In some embodiments, enabling the CP function to instruct the UP function involves enhancements in at least one of: the 3GPP N4 interface, the Npcf interface, and the Nudr interface (service-based interfaces).
In some embodiments, enabling the CP function to instruct the UP function comprises delaying NAT IP address and port allocation at the service initiation. In some embodiments, enabling the CP function to instruct the UP function comprises delaying NAT IP address and port withdrawal at the service termination.
In some embodiments, enabling the CP function to instruct the UP function comprises enabling NAT granularity of at least one of: on a per global basis; on a per subscriber basis; on a per Data Network Name (DNN) basis; per PDU session basis; per data flow basis and on a per application basis.
In some embodiments, the method also includes providing subscriber awareness and upper application protocol inspection to provide subscriber aware NAT logs or application aware NATing.
In some embodiments, the function entity operates in a Fifth Generation Core (5GC) network. In some embodiments, the function entity is one or more of: a User Plane Function (UPF); a Session Management Function (SMF); a Policy Control Function (PCF); and a combination of any of these.
In some embodiments, the function entity operates in an Evolved Packet Core (EPC) network. In some embodiments, the function entity is one or more of: a Packet Data Network (PDN) Gateway (PGW) CP function (PGW-C) node; a PGW UP function (PGW-U) node; and a Policy Control Rules Function (PCRF) node.
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.
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 device.
Radio Access Node: As used herein, a “radio access node” or “radio network node” is any node in a radio access network of a cellular communications network that operates to wirelessly transmit and/or receive signals. Some examples of a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a home eNB, or the like), and a relay node.
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 Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.
Wireless Device: As used herein, a “wireless device” is any type of device that has access to (i.e., is served by) a cellular communications network by wirelessly transmitting and/or receiving signals to a radio access node(s). Some examples of a wireless device include, but are not limited to, a User Equipment device (UE) in a 3GPP network and a Machine Type Communication (MTC) device.
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.
The base stations 102 and the low power nodes 106 provide service to wireless devices 112-1 through 112-5 in the corresponding cells 104 and 108. The wireless devices 112-1 through 112-5 are generally referred to herein collectively as wireless devices 112 and individually as wireless device 112. The wireless devices 112 are also sometimes referred to herein as UEs.
Seen from the access side the 5G network architecture shown in
The PCF supports unified policy framework to govern the network behavior. Specifically, in some embodiments, PCF provides Policy and Charging Control (PCC) rules to the Policy and Charging Enforcement Function (PCEF) (SMF/UPF that enforces policy and charging decisions according to provisioned PCC rules). The SMF supports different functionality, specifically, in some embodiments, SMF receives PCC rules from PCF and configures UPF accordingly. The UPF supports handling of user plane traffic based on the rules received from SMF, specifically, in some embodiments, packet inspection and different enforcement actions (Quality of Service (QoS), Charging, etc.).
Reference point representations of the 5G network architecture are used to develop detailed call flows in the normative standardization. The N1 reference point is defined to carry signaling between the UE and AMF. The reference points for connecting between the AN and AMF and between the AN and UPF are defined as N2 and N3, respectively. There is a reference point, N11, between the AMF and SMF, which implies that the SMF is at least partly controlled by the AMF. N4 is used by the SMF and UPF so that the UPF can be set using the control signal generated by the SMF, and the UPF can report its state to the SMF. N9 is the reference point for the connection between different UPFs, and N14 is the reference point connecting between different AMFs, respectively. N15 and N7 are defined since the PCF applies policy to the AMF and SMP, respectively. N12 is required for the AMF to perform authentication of the UE. N8 and N10 are defined because the subscription data of the UE is required for the AMF and SMF.
The 5G core network aims at separating user plane and control plane. The user plane carries user traffic while the control plane carries signaling in the network. In
The core 5G network architecture is composed of modularized functions. For example, the AMF and SMF are independent functions in the control plane. Separated AMF and SMF allow independent evolution and scaling. Other control plane functions like the PCF and AUSF can be separated as shown in
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.
Some properties of the NFs shown in
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.
Network Address Translation (NAT) is a method of remapping one Internet Protocol (IP) address space into another IP address space by modifying network address information in the IP header of packets while they are in transit across a traffic routing device. Network Address and Port Translation (NAPT) also includes modifying the source port in the transport header. The NAT and the NAPT operate in a similar or corresponding manner.
NAT provides a translation technology which allows multiple end customers to use common and overlapping private IP address ranges internally. Any number of end customers can use the same private IP address ranges. To route to external Internet IP addresses, NAT translates the private IP addresses to public IP addresses, e.g. NAT44 which translates from private to public IPv4 address needed to cope with IPv4 address depletion.
With the advent of enterprise and home solutions and migration to IPv6, Service providers have deployed Carrier Grade NAT (CGNAT) which provides additional NAT schemes such as NAT64 or NAT444.
Since NAT can break some upper application protocols which include the IP address value in their signaling (e.g. File Transfer Protocol (FTP), Session Initiation Protocol (SIP)), CGNAT needs to support Application Level Gateway (ALG) which modifies those protocols. CGNAT servers are usually deployed in the service provider service LAN. Improved systems and methods for providing network address translation are needed.
Recently, 3GPP Rel16 has standardized the support of Multipath Transmission Control Protocol (MPTCP) proxy in UPF as a method for UE and UPF steering the traffic on 3GPP or non 3GPP access. With such a solution, when a UE sets a Multi-access session with 5GC, the SMF, in addition to the public PDU session IP address, assigns two link specific addresses (not routable over N6) to the UE to be used only for the MPTCP sub-flow in each access. 3GPP has defined N4 MAR rule extensions to enable such proxy.
However, there may be problems on different NAT applicability areas. Existing CGNAT uses case deployments and the new multi-access solution (ATSSS) defined in 3GPP Re116. Refer to 3GPP TS 23.502 for details.
CGNAT deployments face some challenges:
Since CGNAT is considered an N6 LAN service, 3GPP does not currently support NAT policies in the existing policy framework. Additionally, the UPF does not support NAT enforcement (based on the above NAT policies).
In the case of the 3GPP Rel16 ATSSS solution with MPTCP method, the use of private IPs for MPTCP traffic between UE and UPF forces UPF to NAT uplink traffic (from MPTCP proxy function to N6), and downlink traffic (from N6 to MPTCP proxy function). Such NATing is not addressed by current N4 ATSSS extensions.
Also, when Control Plane and User Plane Separate (CUPS) is applied, it might be unclear how the UP function should handle those user plane IP packets requiring NAT function, including allocation/deallocation of one or more of the NAT IP address(es) and/or Port. At user session activation, NAT IP addresses are allocated to the UE by the PGW even if some service is seldom used, such as a Wireless Application Protocol (WAP), or some service isn't used until session is activated for a long time. NAT IP resource allocated since session establishment is a waste of resources in these scenarios.
Systems and methods for supporting NAT are provided. In some embodiments, there is a mechanism to enable a Control Plane (CP) function to instruct a User Plane (UP) function to apply NAT function for at least one specific service data flow for a given Packet Flow Control Protocol (PFCP) session, in 5GC and/or EPC, when the CP function and UP function is separated. In some embodiments, this is accomplished by a new UP function feature, which in some embodiments is called “Support of Network Address Translation in UP function” (NATU). In some embodiments, a new feature bit can be defined in the IE “UP function features” as specified in 8.2.25 of 3GPP TS 29.244. In some embodiments, the PFCP protocol is extended by creating a new NAT IE in the Forwarding Parameters IE in the Forwarding Action Rule (FAR). Some embodiments involve enhancements in the 3GPP N4 interface, but also in Npcf and Nudr interfaces.
The embodiments of the current disclosure might result in one or more improvements such as: introducing a mechanism to allow CP function to instruct UP function to perform NAT function for one or more service data flow(s), when CP and UP function are separated; using NAT function can protect a private network from potential unlawful incursion; and delaying NAT IP address and port allocation and withdraw at the service initiation and termination can save the public IP address space.
Also, embodiments of the current disclosure might result in one or more improvements such as allowing the network operator to support NAT policies in the context of 4G/5G networks supporting CUPS. This is of value, e.g., for ATSSS functionality where SMF can program the translation from link specific address to the public IP address assigned to the Multi-access PDU session.
Some embodiments allow the network operator to support NAT policies with different granularity: on a per global basis, on a per subscriber basis, on a per Data Network Name (DNN) basis, per PDU session basis; per data flow basis and/or on a per application basis. In addition, existing UPF subscriber awareness and upper application protocol inspection can be leveraged to provide subscriber aware NAT logs or Application aware NATing which are difficult to achieve with standalone CGNAT solutions. Some embodiments allow the network operator to support NAT enforcement in the UPF. This avoids the need of any external NAT SF or at least allows offloading external CGNAT of certain NATing use cases.
When traffic related to a single UE device and one APN is divided and routed to several VPNs, such as Internet, WAP, or other enterprise VPN, routing can present ambiguity if UE uses only one IP address. As a result, multiple return paths exist for responding packets, and payload can be returned to a different VPN from the one where it originated.
In order to remove such ambiguities, NAT can be enabled for service VPNs by the configuration of one or more IP address ranges containing addresses that substitute the original source IP address.
At user session activation, the Evolved Packet Gateway (EPG) allocates a unique IP address to the UE on each service VPN allowed on the base APN for which NAT is enabled. The addresses are allocated from either the shared address pool locally or RADIUS. After deactivation of the UE session, the IP addresses are withdrawing and available for allocation to another UE.
When the EPG receives an uplink packet that is detected according to the traffic class of the data packet and should be routed to a service VPN for which NAT is enabled, it replaces the original source IP address in the IP header of the packet with the NAT IP address allocated to the UE. On return of the payload, the NAT IP address in the destination field of the packet is replaced with the original UE IP address.
In a first embodiment, it is expected that the UP function is self-conducted to handle user plane packets applicable for NAT, with a little less instruction from the CP function. In some embodiments, this includes one or more of:
In some embodiments, this approach requires UP function to replace Source or Destination IP address with NAT Address or real UE IP address based on Uplink or Downlink traffic smartly.
In a second embodiment, it is expected that the UP function is fully instructed by the CP function to perform IP header modifications, e.g. replace/change source/destination IP address and/or Port. In some embodiments, this includes one or more of:
Similarly, for UL traffic:
In some embodiments, feature support of NATU can be negotiated between the CP and the UP function. This might involve the NAT function (e.g., “NATU” in Octet/Bit as 6/8) in the UP Function Features IE to describe whether the NAT function can be applied or not in the UP function. For example, the UP function may indicate that it supports NAT by setting a flag or a bit mask e.g. in the form of one or more Bit(s) (c.f. the “NATU”) in an IE e.g. in the UP Function Features IE and send the IE towards the CP function in a suitable message. For example, when the CP function requires “NATU” via PFCP Association Setup or Update Request, the UP function may indicate support of NAT function by setting the “NATU” flag in the UP Function Features IE via PFCP Association Setup or Update Response.
If “NATU” is supported in the UP function, the CP function may include the NAT IP address and/or port information in PDR associated to the PDU session and provide the PDR to the UP Function. The NAT address and/or port information may e.g., be obtained by the CP function via SGi/Radius or may be preconfigured in the CP function or in the UP function. In some embodiments, the NAT address and/or port information provided by the CP function shall prevail over NAT address and/or port information preconfigured in the UP function.
If “NATU” is not supported in the UP function, the flag is set as 0 via UP Function Features IE and CP Function will not apply NAT for this UP Function.
The Table below illustrates how the NATU feature could be added to the UP Function Features IE. However, the current disclosure is not limited to this implementation:
In some embodiments, instead of all NAT IP addresses and ports for relevant Service VPNs being allocated at session creation, the PGW allocates NAT IP address and ports for service VPNs only when the packets are detected, and the associated PCC rule is activated. The associated PCC rule can be activated by PCRF or local policy without PCRF.
For the CUPS case, a Usage Reporting Rule (URR) with reporting trigger START is sent to the UP Function when session creation/modification for Usage Report informing specific application detected with Application ID. Once an application is detected, the UP function sends the Usage Report with START trigger to inform CP function. The payload is buffered by default or dropped depending on its configuration in the UP function until the NAT IP address and Port is allocated. If no service is detected, the original Network Instance is used for payload routing.
When the PGW-C receives the Usage Report with trigger START, the PGW-C will associate the PCC rule. If the PCC rule is activated, the PGW-C will allocate the NAT IP address and Port, which come from the local shared IP pool or Radius. The PGW-C will package the NAT IP address and Port into PDR/FAR for the UP function to deliver the payload. After receiving the NAT IP address and port, the UP function can deliver the payload based on NAT IP address and port. NAT IP allocation on service access is of higher priority if provided.
In some embodiments, the PGW-C is responsible for maintenance of NAT IP mapping between UE IP Addresses and NAT IP Addresses. The PGW-C informs the UP Function for replacement of the UE IP Address by the given NAT IP Address by PDR/FAR associated to the PDU session. In addition, the packets buffered before NAT IP allocation will be delivered to the Service VPN.
In some embodiments, the NAT IP address and port are in the PDR. The NAT IP address and port can be delivered to the UP function using several options. In a first option, a new IE, preferably called “NAT IP Address Port” or “Additional UE IP Address Port” is introduced in the Packet Detection Information (PDI) or Create Traffic Endpoint IE for a downlink (DL) PDR. An example of this new IE which contains a source or destination IP address is included below:
The following flags are coded within Octet 5:
An example of a new IP header Modification IE which contains a source or destination IP address is included below:
The following flags are coded within Octet 5:
An example of a reuse of the existing IE Create Outer Header which contains the instructions to create an Outer Header is included below:
The Outer Header Creation Description field, when present, shall be encoded as specified in Table 8.2.56-1. It takes the form of a bitmask where each bit indicates the outer header to be created in the outgoing packet. Spare bits shall be ignored by the receiver.
The Outer Header Creation Description is included below:
Additionally,
While the previous discussion focused on the EPC core network, the principles are also applicable to the 5G core network, which was discussed above in relation to
In some embodiments, a combined SMF/PGW-C is assumed, i.e., in connection with interworking between 4G and 5G networks. In this case, the UPF needs to also support Sxb (to communicate with PGW-C).
In some embodiments, the solutions consist of an extension of 3GPP PFCP protocol by creating a new NAT IE in the Forwarding Parameters IE in the FAR. This allows the SMF to instruct the UPF to enforce NAT policies. In some embodiments, additional extensions are required in Npcf and Nudr interfaces to carry the NAT policies to the UPF, which will use it to apply (source) NAT enforcement for a user's traffic. In some embodiments, the NAT IP address pool is handled in SMF. In some embodiments, the NAT IP address pool is handled in UPF.
Steps 3 and 4 illustrate: the UE triggers a PDU session establishment, by means of sending a PDU Session Establishment Request to the AMF. The AMF selects an SMF to manage the PDU session (the SMF selection function in the AMF selects an SMF instance based on the available SMF instances obtained from NRF or on the configured SMF information in the AMF) and triggers an Nsmf PDU Session Create. Note that the sequence diagram in
Step 5 illustrates: The SMF triggers an Npcf_SMPolicyControl_Create Request message to retrieve SM policies for the user PDU session. Step 6 illustrates: The PCF triggers an Nudr_Query Request message to retrieve the Subscriber policy data associated with the UE for this PDU session.
Step 7 illustrates: The UDR answers with an Nudr_Query Response message including the Subscriber Policy Data, which includes a NAT policy. This NAT policy might include the need to additionally run ALG functionality. Step 8 illustrates: The PCF generates the corresponding PCC rule/s based on Subscriber Policy Data.
Step 9 illustrates: Based on the above, The PCF triggers an Npcf_SMPolicyControl_Create Response message including the PCC rules to be applied for this user PDU session. In this case, as an example, there will be a PCC rule for YouTube application including some enforcement actions (NAT, Charging and QoS).
Step 10 illustrates: Based on the PCC rule/s received from PCF (which include or at least indicate NAT policies), SMF selects a UPF supporting enforcement of NAT policies. Step 11 illustrates: The SMF triggers a PFCP Session Establishment Request message including the corresponding PCC rule(s) (PDRs/FARs/QERs/URRs). In this example, there will be a PDR with PDI of type application with appld=YouTube, and a corresponding FAR, QER and URR. It is proposed to extend the FAR by creating a new Network Address Translation IE in the Forwarding Parameters IE as shown below:
As an example, the “Network Address Translation” IE is proposed to have the following contents (information related to Dort translation may be present but is not included for simplicity):
“Address Type” indicates the type of Address. It is proposed to be encoded as follows:
“Address Length” indicates the length of the Address. “Address” is encoded in UTF8String format and contains the source address that will replace the original source address at the IP header.
The following flags are coded within Octet 5:
In this example sequence diagram, it is assumed that the NAT IP address pool is handled in SMF. As mentioned above, SMF has a locally configured NAT IP address pool, which is a pool of IP addresses for (source) NAT purposes. In case the PDU session is:
a. IPv4 session: SMF will select one IPv4 address from the pool and include it in the “Address” field. SMF will set “Address Type” to 0 (IPv4) and set to 0 the Bit 5 in Octet 5.
In case the NAT policy indicates to additionally run ALG functionality (see Step 7 above), one of the Spare bits in Octet 5 can be used to indicate UPF to run ALG functionality. As mentioned above, there are some application protocols which include the IP address value in their signaling (e.g. FTP, SIP), and in this case, the UPF needs to support Application Level Gateway (ALG) which modifies those protocols (e.g., by replacing the private IP address with the public one).
It is not shown in the sequence diagram in
Step 12 of
In case of dual stack PDU sessions (IPv4v6):
Additionally, in some embodiments, if the NAT policy indicates so, it is also possible to replace the original source port (e.g., port X) at the transport header (e.g., TCP or UDP) by the port indicated in the NAT policy (e.g., port Y).
The example use case in
While the above discussion focuses on a 5G network architecture, the same mechanisms can be applied to 4G. In some embodiments, this could be accomplished by replacing one or more of the following:
As used herein, a “virtualized” radio access node is an implementation of the radio access node 1300 in which at least a portion of the functionality of the radio access node 1300 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 1300 includes the control system 1302 that includes the one or more processors 1304 (e.g., CPUs, ASICs, FPGAs, and/or the like), the memory 1306, and the network interface 1308 and the one or more radio units 1310 that each includes the one or more transmitters 1312 and the one or more receivers 1314 coupled to the one or more antennas 1316, as described above. The control system 1302 is connected to the radio unit(s) 1310 via, for example, an optical cable or the like. The control system 1302 is connected to one or more processing nodes 1400 coupled to or included as part of a network(s) 1402 via the network interface 1308. Each processing node 1400 includes one or more processors 1404 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 1406, and a network interface 1408.
In this example, functions 1410 of the radio access node 1300 described herein are implemented at the one or more processing nodes 1400 or distributed across the control system 1302 and the one or more processing nodes 1400 in any desired manner. In some particular embodiments, some or all of the functions 1410 of the radio access node 1300 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) 1400. As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s) 1400 and the control system 1302 is used in order to carry out at least some of the desired functions 1410. Notably, in some embodiments, the control system 1302 may not be included, in which case the radio unit(s) 1310 communicate directly with the processing node(s) 1400 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 radio access node 1300 or a node (e.g., a processing node 1400) implementing one or more of the functions 1410 of the radio access node 1300 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).
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 UE 1600 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).
Some of the embodiments that have been described above may be summarized in the following itemized manner: 1. A method of operating a Control Plane, CP, entity configured to support Network Address Translation, NAT, the method comprising at least one of:
obtaining NAT information where the NAT information indicates a NAT policy to be applied for User Plane, UP, Internet Protocol, IP, data packets for a wireless device; and
providing the NAT information to a UP entity that is capable of handling UP IP data packets for the wireless device.
2. The method of item 1 wherein obtaining the NAT information further comprises at least one of:
the NAT information is preconfigured in the CP entity; and
obtaining the NAT information from a Policy and Charging entity such as a Policy Control Function, PCF, or a Policy Control Rules Function, PCRF, node or similar.
3. The method of any one of item 1 to 2 wherein the NAT information may be provided in at least one of:
a Policy and Charging Control, PCC, rule; and/or
4a. The method of any one of the preceding items wherein:
4b. The method of any one of the preceding items wherein:
the NAT information and the NAT policy represent corresponding information and may be the same.
4c. The method of any one of the preceding items wherein:
the NAT information may indicate an IP address, e.g. comprised by an “Additional UE IP address IE”, that can be used to identify or match the UP data packets to which the NAT policy shall be applied.
4d. The method of any one of the preceding items wherein:
4e. The method of any one of the preceding items wherein:
the NAT information may be generated by the Policy and Charging entity such as the PCF or the PCRF based on the subscription information for the wireless device, where the Policy and Charging entity may obtain the subscription information from a repository entity such as a Unified Data Repository, UDR, or a Authentication, Authorization, and Accounting, AAA,/Radius function.
5. The method of any one of the proceeding items further comprising:
obtaining support information for at least one UP entity, which support information indicates that the UP entity supports NAT.
6. The method of item 5 wherein obtaining support information further comprises at least one of: the support information is preconfigured in the CP entity;
obtaining the support information when the CP entity associates with the UP entity;
obtaining the support information from the UP entity; and
obtaining the support information from a repository function entity, e.g. such as a Network Repository Function (NRF) or similar.
7. The method of any one of item 5 to 6 further comprising:
selecting, based on the obtained support information, a UP entity that is capable of handling UP IP data packets for the wireless device.
8. The method of any one of item 1 to 7 wherein the at least one of the UP IP data packets belongs to a given Packet Flow Control Protocol, PFCP, session.
9. The method of any one of item 1 to 8, wherein the NAT information indicates that the NAT policy is to be applied for the UP IP data packets:
10. The method of any one of the above items wherein the CP entity operates in a Fifth Generation Core, 5GC, network.
11. The method of item 10 wherein the CP entity is one or more of: a User Plane Function, UPF; a Session Management Function, SMF; a Policy Control Function, PCF; and a combination of any of these.
12. The method of any one of the above items wherein the CP entity operates in an Evolved Packet Core, EPC, network.
13. The method of item 12 wherein the CP entity is one or more of: a Packet Data Network, PDN, Gateway, PGW, CP function, PGW-C, node; a PGW UP function, PGW-U, node; a Policy Control Rules Function, PCRF, node.
14. A Control Plane, CP, entity configured to support Network Address Translation, NAT, the CP entity comprising at least one processor and memory comprising instructions executable by the at least one processor whereby the function entity is operable to:
obtain NAT information where the NAT information indicates a NAT policy to be applied for User Plane, UP, Internet Protocol, IP, data packets for a wireless device; and
provide the NAT information to a UP entity that is capable of handling UP IP data packets for the wireless device.
15. The CP entity of item 14 wherein being operable to obtain the NAT information further comprises being operable to at least one of:
the NAT information is preconfigured in the CP entity; and
obtain the NAT information from a Policy and Charging entity such as a Policy Control Function, PCF, or a Policy Control Rules Function, PCRF, node.
16. The CP entity of any one of item 14-15 wherein the NAT information may be included in at least one of:
a Policy and Charging Control, PCC, rule;
a Packet Detection Rule, PDR, preferably comprised by a PCC rule; and
a Fowarding Action Rule, FAR, preferably comprised by a PDR.
17a. The CP entity of any one of item 14-16 wherein:
the NAT information indicates a NAT policy that is based on the subscription information for the wireless device.
17b. The CP entity of any one of item 14-17a wherein:
the NAT information and the NAT policy represent corresponding information and may be the same.
17c. The CP entity of any one of item 14-17b wherein:
the NAT information may indicate an IP address, e.g. comprised by an, “Additional UE IP address IE”, that can be used to identify or match the UP data packets to which the NAT policy shall be applied.
17d. The CP entity of any one of item 14-17c wherein:
the NAT information indicates replacement information, e.g. comprised by an “IP Header Modification IE”, that contains an IPv4/IPv6 address and/or a Port number that can be used to replace the Source/Destination IPv4/IPv6 address respectively and the Source/Destination Port respectively in the IP data packets;
17e. The CP entity of any one of item 14-17d wherein:
the NAT information may be generated by the Policy and Charging entity such as the PCF or the PCRF based on the subscription information for the wireless device, where the Policy and Charging entity may obtain the subscription information from a repository entity such as a Unified Data Repository, UDR, or a Authentication, Authorization, and Accounting, AAA,/Radius function.
18. The CP entity of any one of item 14-17e further operable to:
obtain support information for at least one UP entity, which support information indicates that the UP entity supports NAT.
19. The CP entity of item 18 wherein being operable to obtain support information further comprises being operable to at least one of:
the support information is preconfigured in the CP entity; and
obtain the support information when the CP entity associates with the UP entity
obtain the support information from the UP entity; and
obtain the support information from a repository function entity, e.g. such as a Network Repository Function (NRF) or similar.
20. The CP entity of any one of item 14-19 further operable to:
select, based on the obtained support information, a UP entity that is capable of handling UP IP data packets for the wireless device.
21. The CP entity of any one of item 14-20 wherein at least one of the UP IP data packets belongs to a given Packet Flow Control Protocol, PFCP, session.
22. The CP entity of any one of item 14-21 wherein the NAT information indicates that the NAT policy is to be applied for the UP IP data packets:
on a per global basis (e.g. for all UP IP data packets associated with the wireless); or
on a per subscriber basis (e.g. as defined by the subscription associated with the wireless device); or
on a per Data Network Name, DNN, basis (e.g. for all UP IP data packets associated with the wireless device and a particular DNN); or
per PDU session basis (e.g. for all UP IP data packets associated with a particular PDU session for the wireless device); or
per data flow basis (e.g. for all UP IP data packets associated with a particular data flow for the wireless device); or
on a per application basis (e.g. for all UP IP data packets associated with the wireless device and a particular application).
23. The CP entity of any one of item 14-22 wherein the CP entity operates in a Fifth Generation Core, 5GC, network.
24. The CP entity of item 23 wherein the CP entity is one or more of: a User Plane Function, UPF; a Session Management Function, SMF; a Policy Control Function, PCF; and a combination of any of these.
24. The CP entity of any one of item 14-23 wherein the CP entity operates in an Evolved Packet Core, EPC, network.
25. The CP entity of item 24 wherein the CP entity is one or more of: a Packet Data Network, PDN, Gateway, PGW, CP function, PGW-C, node; a PGW UP function, PGW-U, node; a Policy Control Rules Function, PCRF, node.
26. A CP entity configured to support Network Address Translation, NAT, adapted to operate according to the method of any one of item 1 through 13.
27. A CP entity configured to support Network Address Translation, NAT, comprising:
a NAT information obtaining module operable to obtain NAT information where the NAT information indicates a NAT policy to be applied for User Plane, UP, Internet Protocol, IP, data packets for a wireless device; and
a NAT information providing module operable to provide the NAT information to a UP entity that is capable of handling UP IP data packets for the wireless device.
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 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 ROM, 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.).
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).
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.
Number | Date | Country | Kind |
---|---|---|---|
PCT/CN2019/096161 | Jul 2019 | CN | national |
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/EP2020/069874 | 7/14/2020 | WO |