WO2017021081A1

WO2017021081A1 - System and method for enabling ipv6 networks

Info

Publication number: WO2017021081A1
Application number: PCT/EP2016/065761
Authority: WO
Inventors: Jan Backman; Fredrik Garneij; Alberto VILLAESCUSA
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2015-07-31
Filing date: 2016-07-05
Publication date: 2017-02-09

Abstract

A method in a network node (115, 130, 320) is disclosed. The method comprises: receiving (504) a first data packet (310) from a wireless device (110), the first data packet (310) comprising a destination header field including a target IP address as a destination of the received data packet; and obtaining (508) a public IP address and a port allocation associated with the wireless device (110). The method comprises: translating (512) the target IP address into a synthetic IP address, the synthetic IP address comprising the target IP address, the public IP address and the port allocation associated with the wireless device (110); generating (516) a second data packet (340), the second data packet (340) comprising a destination header field including the synthetic IP address as a destination of the second data packet; and transmitting (520) the second data packet (340) to a translation node (335).

Description

SYSTEM AND METHOD FOR ENABLING IPV6 NETWORKS

TECHNICAL FIELD

The present disclosure relates, in general, to wireless communications and, more particularly, to systems and methods for enabling IPv6 networks.

BACKGROUND

With the increasing expansion of the Internet, legacy network IP addresses, such as IPv4 addresses that may be composed of a mere 32 bits, are becoming more scarce. To address this and other issues, an IPv6 protocol employing IP addresses of 128 bits has been proposed. In addition to addressing the problem of scarcity of the IPv4 addresses, the IPv6 protocol provides significant improvements to addresses capacity, security, network management, and mobility and quality of service, among other things. With the increased demand for mobile connectivity, a shortage of both public and private IPv4 addresses in mobile operator networks has forced operators to introduce methods and mechanisms to address this problem. Network Address Translation (NAT) and 464XLAT (IETF RFC 6877) are examples of such methods and mechanisms that are widely deployed in mobile operator networks.

NAT is used to address the shortage of public IPv4 addresses for global connectivity by sharing a public IPv4 address between several endpoints with private IPv4 addresses. A NAT creates and maintains a dynamic stateful mapping table between private and public IPv4 addresses and ports in order to keep track of active mappings.

464XLAT allows clients on IPv6-only networks to access IPv4-only Internet services. 464XLAT provides limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation NAT64/PLAT (IETF RFC 6146) in the core and stateless protocol translation SIIT/CLAT (IETF RFC 6145) at the edge. In addition to addressing the public IPv4 address shortage, 464XLAT also addresses the private IPv4 address shortage. 464XLAT is a scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation.

Before a new protocol can be uniformly used by mobile networks, network components must be able to operate according to both the new protocol and legacy procotols. This is because even after a new protocol such as IPv6 is uniformly adopted, legacy mobile devices that operate using IPv4 may still be used. This can be problematic, as it is generally the case that IPv4 applications are not able to run in an IPv6 environment, and IPv6 applications are not able to run in an IPv4 environment. Furthermore, even if most applications can support both IPv4 and IPv6 protocols, there may still be some applications and services that only support IPv4. As a result, IPv6 resources may be underutilized. Moreover, due to an imbalance of address allocation, some countries or regions may have IPv4 address space available for allocation long after the new IPv6 protocol is implemented.

Because IPv4 and IPv6 networks will likely coexist for a long time, approaches have been created to enable IPv4 and IPv6 networks to coexist. These IPv4 to IPv6 transition technologies may enable existing IPv4 applications to run over the IPv6 network. Thus, while the network may be updated to operate according to the new IPv6 protocol, the network may allow continued use of existing IPv4 application resources.

Existing approaches to addressing the above problems associated with the transition from IPv4 to IPv6 technologies attempt to get network operators to switch from IPv4 to IPv6. For example, in the packet domain, one example approach is an IPv4 to IPv6 Dual Stack Transition Mechanism ("Dual Stack") that connects the dual stack hosts in the pure IPv6 network to the existing IPv4 hosts or applications. The purpose of Dual Stack is to provide both IPv4 and IPv6 connectivity to a network node or wireless device. Specifically, each wireless device may receive both an IPv4 address and an IPv6 address. The wireless device may use IPv6 when IPv6 is supported, but fallback to using IPv4 when IPv6 is not supported. Additionally, Dual Stack may also add a gateway between the networks of different network protocols to transmit IPv4 traffic over the pure IPv6 network using an IPv4 over IPv6 tunnel.

While Dual Stack provides some benefits, this IPv4 to IPv6 transition technology has certain disadvantages. For example, Dual Stack requires that there be both an IPv4 and IPv6 infrastructure at the Guard Interval/Short Guard Interval (Gi/SGi) interface. As a result, the network operator is required to manage IPv4 addresses as well as introduce support for IPv6 in the network. This increases operator costs since the operators must support and manage double IP addresses for all wireless devices in the network. As another example, large network operators continue to risk exhaustion of private IPv4 address space. As still another example, Dual Stack technology requires all transparent value added services (e.g., service charging, traffic/service policies, parental control, firewalling, etc.) on the Gi/SGi network to support both IPv4 and IPv6 if the value added services are to be used for both protocols.

A second example approach for IPv4 to IPv6 transition in the packet core domain is to provide only an IPv6 address to each terminal. According to this approach, all domain name service (DNS) lookup of IPv4 services is handled using an address translation mechanism, such as a server (e.g., a DNS64), that translates the address of the IPv4 packet into a "synthetic" IPv6 address. The synthetic IPv6 address may contain the target IPv4 address. Specifically, translation from IPv6 to IPv4 may be done in an external NAT64 that is addressed by the IPv6 address returned by the DNS64. Alternatively, some applications may use IPv4 addresses natively. For wireless devices that support 464XLAT technology through a CLAT mechanism (such as Android 4.3 and later and some Nokia terminals), the wireless device translates the IPv4 traffic into IPv6 (stateless XLAT) towards the NAT64. Thus, an IPv6 only solution either risks that IPv4 services will not work (e.g., applications that do not support IPv6 at all such as Skype and Spotify) or requires support in the wireless device for the 464XLAT technology (CLAT mechanism). If 464XLAT is not supported, the wireless device cannot be transitioned to IPv6. However, even where 464XLAT is supported, it may only be supported for a subset of the wireless devices in the network.

SUMMARY

To address the foregoing problems with existing approaches, disclosed is a method in a network node. The method comprises receiving a first data packet from a wireless device, the first data packet comprising a destination header field including a target IP address as a destination of the received data packet. The method comprises obtaining a public IP address and a port allocation associated with the wireless device, and translating the target IP address into a synthetic IP address, the synthetic IP address comprising the target IP address, the public IP address and the port allocation associated with the wireless device. The method comprises generating a second data packet, the second data packet comprising a destination header field including the synthetic IP address as a destination of the second data packet, and transmitting the second data packet to a translation node.

In certain embodiments, the network node may comprise a gateway node in a packet core domain. The first data packet may comprise an IPv4 data packet and the second data packet may comprise an IPv6 data packet. The public IP address may be an IPv4 address.

In certain embodiments, the method may comprise identifying that a session is being created, and storing a session mapping state for the first and second data packets for use with a subsequent data packet belonging to the session. In certain embodiments, the method may comprise allocating an IPv6 prefix to the wireless device, wherein the second data packet comprises a source header field including the IPv6 prefix allocated to the wireless device and a source IPv4 address for the wireless device as a source of the second data packet. The method may comprise receiving a third data packet from the translation node, the third data packet comprising an IPv6 packet comprising a destination header field including the IPv6 prefix and the public IP address associated with the wireless device. The method may comprise identifying, based on the IPv6 prefix allocated to the wireless device, a user context associated with the wireless device, translating the third data packet to a fourth data packet, the fourth data packet comprising an IPv4 packet, and transmitting the fourth data packet to the wireless device.

Also disclosed is a network node. The network comprises one or more processors. The one or more processors are configured to receive a first data packet from a wireless device, the first data packet comprising a destination header field including a target IP address as a destination of the received data packet. The one or more processors are configured to obtain a public IP address and a port allocation associated with the wireless device, and translate the target IP address into a synthetic IP address, the synthetic IP address comprising the target IP address, the public IP address and the port allocation associated with the wireless device. The one or more processors are configured to generate a second data packet, the second data packet comprising a destination header field including the synthetic IP address as a destination of the second data packet, and transmit the second data packet to a translation node.

Also disclosed is a method in a network node. The method comprises receiving a first data packet from a gateway node in a packet core domain, the first data packet comprising a destination header field including a synthetic IP address as a destination of the first data packet, the synthetic IP address comprising a target IP address associated with a destination of the first packet, and a public IP address and a port allocation associated with a wireless device. The method comprises extracting from the first data packet the target IP address associated with the destination of the first packet, and generating a second data packet, the second data packet comprising a destination header field including the target IP address and a source header field including the public IP address associated with the wireless device as a source of the second data packet. The method comprises transmitting the second data packet to the destination of the first packet.

In certain embodiments, the first data packet may comprise an IPv6 data packet and the second data packet may comprise an IPv4 data packet. The public IP address may be an IPv4 address. The first data packet may comprise a source header field, the source header field comprising an IPv6 prefix allocated to the wireless device by the gateway node and an IPv4 address for the wireless device.

In certain embodiments, the method may comprise storing a mapping between the first data packet and the second data packet. In certain embodiments, the method may comprise receiving a third data packet from the destination of the first data packet, the third data packet comprising an IPv4 packet comprising a destination header field including the public IP address associated with the wireless device. The method may comprise translating, based on a stored mapping between the first data packet and the second data packet, the third data packet to a fourth data packet, the fourth data packet comprising an IPv6 packet comprising a destination header field including the IPv6 prefix allocated to the wireless device by the gateway node and the IPv4 address for the wireless device, and transmitting the fourth data packet to the wireless device.

Also disclosed is a network node. The network node comprises one or more processors. The one or more processors are configured to receive a first data packet from a gateway node in a packet core domain, the first data packet comprising a destination header field including a synthetic IP address as a destination of the first data packet, the synthetic IP address comprising a target IP address associated with a destination of the first packet, and a public IP address and a port allocation associated with a wireless device. The one or more processors are configured to extract from the first data packet the target IP address associated with the destination of the first packet, and generate a second data packet, the second data packet comprising a destination header field including the target IP address and a source header field including the public IP address associated with the wireless device as a source of the second data packet. The one or more processors are configured to transmit the second data packet to the destination of the first packet. Certain embodiments of the present disclosure may provide one or more technical advantages. For example, certain embodiments may advantageously allow a translation to be generated, known and maintained within the Packet Core domain. Thus, when an external AF triggers a Policy request, the Packet Core has the needed information to identify the right user and flow. As another example, certain embodiments may not require IPv4 address validation, which may advantageously allow the wireless device to use multiple IPv4 addresses without introducing any problem into the network. As still another example, certain embodiments may advantageously increase resilience by removing the dependency on the translation node. As yet another example, in certain embodiments the mapping information may advantageously be known to the core node, and therefore can be stored and logged for any purpose. Thus, tracking a users' activity or sessions may advantageously be simplified. As yet another example, certain embodiments may advantageously allow for introduction of a flow identifier into the IPv6 packet header that can be used for doing Service Chaining for both IPv4 and IPv6 flows. Other advantages may be readily apparent to one having skill in the art. Certain embodiments may have none, some, or all of the recited advantages.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the disclosed embodiments and their features and advantages, reference is now made to the following description, taken in conjunction with the accompanying drawings, in which:

FIGURE 1 illustrates an example embodiment of a wireless communications network, in accordance with certain embodiments;

FIGURE 2 is a block diagram illustrating an embodiment of a network, in accordance with certain embodiments;

FIGURE 3 is a block diagram illustrating an embodiment of a network, in accordance with certain embodiments;

FIGURE 4 is a table illustrating datagram flow, in accordance with certain embodiments;

FIGURE 5 is a flow diagram of a method in a network node, in accordance with certain embodiments;

FIGURE 6 is a flow diagram of a method in a network node, in accordance with certain embodiments;

FIGURE 7 is a block schematic of an exemplary wireless device, in accordance with certain embodiments;

FIGURE 8 is a block schematic of an exemplary network node, in accordance with certain embodiments;

FIGURE 9 is a block schematic of an exemplary radio network controller or core network node, in accordance with certain embodiments;

FIGURE 10 is a block schematic of an exemplary wireless device, in accordance with certain embodiments;

FIGURE 11 is a block schematic of an exemplary network node, in accordance with certain embodiments; and

FIGURE 12 is a block schematic of an exemplary radio network controller or core network node, in accordance with certain embodiments.

DETAILED DESCRIPTION

As described above, the increasing expansion of the Internet has resulted in a shortage of IPv4 addresses. The IPv6 protocol, which employs IP addresses of 128 bits, was developed in part as a means to address this problem. Network operators, however, face a number of challenges as they attempt to transition from the IPv4 protocol to the IPv6 protocol. Legacy wireless devices that operate using IPv4 may still be used, and certain applications designed to run in an IPv4 environment may not be able to run in an IPv6 environment. Existing approaches to facilitating the transition from IPv4 to IPv6, such as Dual Stack or an approach providing only an IPv6 address to each wireless device, suffer from a number of deficiencies. For example, Dual Stack requires that there be both an IPv4 and IPv6 infrastructure at the Gi/SGi interface, which requires network operators to manage IPv4 addresses as well as introduce support for IPv6 in the network. This increases operator costs since the operators must support and manage double IP addresses for all wireless devices in the network. An approach that provides only an IPv6 address to each wireless device, meanwhile, risks that IPv4 services will not work (e.g., applications that do not support IPv6 at all such as Skype and Spotify) or requires support in the wireless device for the 464XLAT technology (CLAT mechanism). The present disclosure contemplates various embodiments that may address these and other deficiencies associated with existing approaches to the transition from IPv4 to IPv6. In certain embodiments, the use of IPv6 networks is enabled by moving the control for this stateful dynamic IPv6-IPv4 address and port mapping/translation (PLAT) into the internal domain of the mobile packet core, and distributing this control state within the IPv6 packets in addition to the already included information of the IPv4 destination address to the translation performing node. The state for the translation may be distributed from the Packet Core to the PLAT node within the IPv6 packets themselves.

According to one example embodiment, a method in a network node is disclosed. The network node may be a gateway node in a packet core domain. The network node receives a first data packet from a wireless device. The first data packet has a destination header field including a target IP address as a destination of the received data packet. The first data packet may be an IPv4 data packet. The network node obtains a public IP address and a port allocation associated with the wireless device. The public IP address may be an IPv4 address. The network node translates the target IP address into a synthetic IP address. The synthetic IP address includes the target IP address, the public IP address and the port allocation associated with the wireless device. The network node generates a second data packet, the second data packet comprising a destination header field including the synthetic IP address as a destination of the second data packet. The second data packet may be an IPv6 data packet. The network node transmits the second data packet to a translation node.

According to another example embodiment, a method in a network node is disclosed. The network node may be a translation node, such as a PLAT. The network node receives a first data packet from a gateway node in a packet core domain. The first data packet has a destination header field including a synthetic IP address as a destination of the first data packet. The synthetic IP address includes a target IP address associated with a destination of the first packet, and a public IP address and a port allocation associated with a wireless device. The first data packet may be an IPv6 data packet. The public IP address may be an IPv4 address. The network node extracts from the first data packet the target IP address associated with the destination of the first packet. The network node generates a second data packet. The second data packet has a destination header field including the target IP address and a source header field including the public IP address associated with the wireless device as a source of the second data packet. The second data packet may be an IPv4 data packet. The network node transmits the second data packet to the destination of the first packet.

The various embodiments described herein may provide certain technical advantages. For example, as outlined in 3GPP IPv6 Migration Technical Report TR 23.975 Annex A: Reference Scenarios for NAT in the EPC, there is no defined way of handling external application function (AF) nodes when there is an external NAT device between the subscriber and the application server in the Gi/SGi domain. The AF will see the IP address used as a result of the Stateful translation, but has no way to correlate or find the user in the Packet Core domain. The Packet Core domain is not capable of performing this correlation either without querying the NAT device. Certain embodiments described herein may advantageously allow the translation to be generated, known and maintained within the Packet Core domain. Thus, when an external AF triggers a Policy request, the Packet Core has the needed information to identify the right user and flow.

As another example, in certain embodiments no IPv4 address validation is needed, as the IPv4 address and NAT state can be carried in the IPv6 headers. This means that the wireless device may use multiple IPv4 addresses without introducing any problem into the network. The IPv6 prefix still identifies the session, and as the Packet Data Network gateway will bind the session state for the NAT, this does not put any new requirements on the PLAT. This also makes the PLAT capable of restoring the original packet headers in uplink, and makes it possible for the PLAT to also act as a remote tunneling gateway for IPv4 without any additional control channel. The PLAT may need to announce IP addresses based on the provisioning, which makes the tunneling approach above possible in addition to pure NAT. This implies that the Packet Data Network gateway may need to be aware of the IP network planning.

As yet another example, certain embodiments may advantageously increase resilience by removing the dependency on the Stateful translation node (PLAT). Since the Packet Core is the entity responsible for generating, distributing and maintaining the translation state, the PLAT nodes become replaceable. This means that if one PLAT node fails completely, another one could be provisioned with the state from the Packet Core domain and take over all the sessions handled by the failing PLAT node.

As still another example, in certain embodiments the mapping information may advantageously be known to the Core node, and therefore can be stored and logged for any purpose. Thus, tracking a users' activity or sessions is simple, since the IPv6 translated addresses will contain information about the IPv4 state and translation, as well as a way to identify the user (e.g., a tunnel endpoint identifier (TEID) or mobile station international subscriber directory number (MSISDN)). For example, in certain embodiments this information could be stored in Packet Core call detail records (CDRs).

As yet another example, certain embodiments may allow for introduction of a flow identifier into the IPv6 packet header that can be used for doing Service Chaining for both IPv4 and IPv6 flows. As yet another example, in certain embodiments the key to correlate what is seen in the different domains (e.g., Packet Core and external), is located in the context of the user in the Packet Core.

FIGURE 1 is a block diagram illustrating an embodiment of a network 100, in accordance with certain embodiments. Network 100 includes one or more UE(s) 110 (which may be interchangeably referred to as wireless devices 110) and one or more network node(s) 115 (which may be interchangeably referred to as eNBs 115). UEs 110 may communicate with network nodes 115 over a wireless interface. For example, a UE 110 may transmit wireless signals to one or more of network nodes 115, and/or receive wireless signals from one or more of network nodes 115. The wireless signals may contain voice traffic, data traffic, control signals, and/or any other suitable information. In some embodiments, an area of wireless signal coverage associated with a network node 115 may be referred to as a cell 125. In some embodiments, UEs 110 may have device-to-device (D2D) capability. Thus, UEs 110 may be able to receive signals from and/or transmit signals directly to another UE.

In certain embodiments, network nodes 115 may interface with a radio network controller. The radio network controller may control network nodes 115 and may provide certain radio resource management functions, mobility management functions, and/or other suitable functions. In certain embodiments, the functions of the radio network controller may be included in network node 115. The radio network controller may interface with a core network node. In certain embodiments, the radio network controller may interface with the core network node via an interconnecting network 120. Interconnecting network 120 may refer to any interconnecting system capable of transmitting audio, video, signals, data, messages, or any combination of the preceding. Interconnecting network 120 may include all or a portion of a public switched telephone network (PSTN), a public or private data network, a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a local, regional, or global communication or computer network such as the Internet, a wireline or wireless network, an enterprise intranet, or any other suitable communication link, including combinations thereof.

In some embodiments, the core network node may manage the establishment of communication sessions and various other functionalities for UEs 110. UEs 110 may exchange certain signals with the core network node using the non-access stratum layer. In non-access stratum signaling, signals between UEs 110 and the core network node may be transparently passed through the radio access network. In certain embodiments, network nodes 115 may interface with one or more network nodes over an internode interface, such as, for example, an X2 interface.

As described above, example embodiments of network 100 may include one or more wireless devices 110, and one or more different types of network nodes capable of communicating (directly or indirectly) with wireless devices 110.

In some embodiments, the non- limiting term UE is used. UEs 110 described herein can be any type of wireless device capable of communicating with network nodes 115 or another UE over radio signals. UE 110 may also be a radio communication device, target device, D2D UE, machine-type-communication UE or UE capable of machine to machine communication (M2M), low-cost and/or low-complexity UE, a sensor equipped with UE, Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), USB dongles, Customer Premises Equipment (CPE), etc. UE 110 may operate under either normal coverage or enhanced coverage with respect to its serving cell. The enhanced coverage may be interchangeably referred to as extended coverage. UE 110 may also operate in a plurality of coverage levels (e.g., normal coverage, enhanced coverage level 1, enhanced coverage level 2, enhanced coverage level 3 and so on). In some cases, UE 110 may also operate in out-of-coverage scenarios.

Also, in some embodiments generic terminology, "radio network node" (or simply "network node") is used. It can be any kind of network node, which may comprise a base station (BS), radio base station, Node B, base station (BS), mult i- standard radio (MSR) radio node such as MSR BS, evolved Node B (eNB), network controller, radio network controller (RNC), base station controller (BSC), relay node, relay donor node controlling relay, base transceiver station (BTS), access point (AP), radio access point, transmission points, transmission nodes, Remote Radio Unit (RRU), Remote Radio Head (RRH), nodes in distributed antenna system (DAS), Multi-cell/multicast Coordination Entity (MCE), core network node (e.g., MSC, MME, etc.), O&M, OSS, SON, positioning node (e.g., E-SMLC), MDT, translation node (e.g., PLAT) or any other suitable network node.

The terminology such as network node and UE should be considered non- limiting and does in particular not imply a certain hierarchical relation between the two; in general "eNodeB" could be considered as device 1 and "UE" device 2, and these two devices communicate with each other over some radio channel.

Example embodiments of UE 110, network nodes 115, and other network nodes (such as radio network controller or core network node) are described in more detail below with respect to FIGURES 7-11.

Although FIGURE 1 illustrates a particular arrangement of network 100, the present disclosure contemplates that the various embodiments described herein may be applied to a variety of networks having any suitable configuration. For example, network 100 may include any suitable number of UEs 110 and network nodes 115, as well as any additional elements suitable to support communication between UEs or between a UE and another communication device (such as a landline telephone). Furthermore, although certain embodiments may be described as implemented in a Long Term Evolution (LTE) network, the embodiments may be implemented in any appropriate type of telecommunication system supporting any suitable communication standards (including 5G standards) and using any suitable components, and are applicable to any radio access technology (RAT) or multi-RAT systems in which a UE receives and/or transmits signals (e.g., data). For example, the various embodiments described herein may be applicable to LTE, LTE-Advanced, 5G, UMTS, HSPA, GSM, cdma2000, WCDMA, WiMax, UMB, WiFi, another suitable radio access technology, or any suitable combination of one or more radio access technologies. Although certain embodiments may be described in the context of wireless transmissions in the downlink, the present disclosure contemplates that the various embodiments are equally applicable in the uplink.

With the increased demand for mobile connectivity, shortage of both public and private IPv4 addresses in mobile operator networks has forced operators to introduce methods and mechanisms to address this problem. NAT and 464XLAT are examples of such methods and mechanisms that are widely deployed in mobile operator networks.

FIGURE 2 a block diagram illustrating an embodiment of a network 200. The network 200 in FIGURE 2 may translate information from an IPv4 space to an IPv6 space and vice versa. For example, wireless device 110 (for example, a mobile phone, computer, laptop, etc.) may be executing an IPv4 application 210 that connects to an IPv4 service 215. However, wireless device 110 may be operating over an IPv6 network. In the network of FIGURE 2, wireless device 110 includes a translator (UE CLAT SIIT) 220 that translates IPv4 to IPv6 so that information can be sent across the network 200. The network 200 includes another translator (PLAT/NAT64) 225 that translates IPv6 back to IPv4 so that the information may be used by the IPv4 service 215. For the return communication from the service 215 to wireless device 110, the PLAT 225 may translate IPv4 information from the service 215 to IPv6, and the CLAT 220 of wireless device 110 may translate IPv6 information from the network 200 to IPv4 information for the application 210. These translations involve mapping the private IPv4 address of wireless device 110 to a public IPv4 address and port.

A first problem arises in a scenario in which private IPv4 addresses of wireless device 110 are mapped to a Public IPv4 address and port using external NAT functionality 225. This external mapping introduces a disruption in what is known by the internal domain. What is seen on the inside of the NAT 225, where policies are enforced, and the outside of the NAT 225, where requests for policies may originate like in an AF for an internet service, such as IPv4 service 215, are different in terms of the source IP address and port that is seen.

A second problem with the external mapping relates to the tracking of usage of IPv4 addresses in a system for purposes of logging access to services or charging of services based on IPv4 address. When logging or Policy requests originate from a service that sees only the Public IPv4 address of the user (as dynamically mapped by NAT 225), the mapping may need to be made known to the internal domain in order to be able to resolve a log entry or a policy request to a specific user at a given time.

While 464XLAT solves the shortage of private IPv4 address space, it sometimes requires the wireless device to be IPv6 capable and also have CLAT functionality. At the same time, Policy, Control, and Charging (PCC) functionality will be difficult to achieve since IPv4/IPv6 mapping is done in wireless device 110 with no means to inform the network on how to distinguish between native IPv6 and translated IPv4 packets. The various embodiments described herein moves the control for this stateful dynamic IPv6-IPv4 address and port mapping/translation (PLAT) into the internal domain of the mobile packet core, and distributes this control state within the IPv6 packets in addition to the already included information of the IPv4 destination address to the translation performing node. The state for the translation may be distributed from Packet Core to the PLAT node within the IPv6 packets themselves.

FIGURE 3 is a block diagram illustrating an embodiment of a network 300, in accordance with certain embodiments. In the example of FIGURE 3, network 300 is an IPv6 network. A wireless device 110 has established a public data network (PDN) connection and received an IPv4 address. Wireless device 110 includes an application 305 that is used for accessing IPv4 service 315. Network 300 may include other wireless devices beyond wireless device 110. The wireless devices in network 300 may have different capabilities, and may operate according to different IP protocols than network 300. For example, not all wireless devices seeking access to IPv4 and IPv6 services may be equipped with CLAT technology. As such, some legacy wireless devices may not be equipped to perform local translation of an IPv4 address to an IPv6 address as is needed for traversal through network 300.

In the example of FIGURE 3, wireless devices 110 does not include CLAT technology and, thus, is not able to perform local IP address translation. Accordingly, any request for IPv4 service 315 should be translated into an IPv6 request before the request can be transmitted across the IPv6 network. In certain embodiments, to enable wireless device 110 to access desired IPv4 services 315, the CLAT portion of the 464XLAT technology may be placed in supporting gateway node 320. Thus, CLAT address translation may be provided on the network side for enabling wireless devices that do not include CLAT technology, such as wireless device 110 in FIGURE 3, to access IPv4 service 315 via IPv6 network 300. In this manner, the entire Gi/SGi network can become IPv6 for wireless devices 110 communicating via supporting gateway node 320 having the CLAT functionality 325.

In some cases, wireless device 110 may additionally or alternatively seek access to IPv6 services. For example, wireless device 110 may generate a request for an IPv6 service. The request may have a target IPv6 address. As such, the request may be transmitted directly to the IPv6 service via the IPv6 network 300 without any translation by CLAT 325 or another component. FIGURE 4 is a table illustrating datagram flow, in accordance with certain embodiments. More particularly, FIGURE 4 illustrates three data packets: Datagram 1 , Datagram 2, and Datagram 3. Datagrams 1, 2, and 3 shown in FIGURE 4 correspond to Datagram 1 310, Datagram 2 340, and Datagram 3 345 of FIGURE 3, respectively. For each of Datagrams 1-3, FIGURE 4 illustrates a number of header fields, and for each header field a header field example is provided. Datagram 1 includes an IPv4 destination header field (IPv4 Dst), an IPv4 source header field (IPv4 Src), a TCP destination port field (TCP Port Dst), and a TCP source port header field (TCP Port Src). Datagram 2 includes an IPv6 destination header field (IPv6 Dst), an IPv6 source header field (IPv6 Src), a TCP destination port header field (TCP Port Dst), and a TCP source port header field (TCP Port Src). Datagram 3 includes an IPv4 destination header field (IPv4 Dst), an IPv4 source header field (IPv4 Src), a TCP destination port header field (TCP Port Dst), and a TCP source port header field (TCP Port Src). For ease of understanding, the various header fields and the header field examples illustrated in FIGURE 4 will be described in conjunction with the continued description of FIGURE 3 below.

Returning to FIGURE 3, there is shown an IPv4 application 305 in wireless device 110 that desires to connect to an IPv4 service 315. IPv4 application 305 in wireless device 110 sends an IPv4 data packet 310 (also referred to as Datagram 1 in FIGURES 3 and 4) with the destination address of the IPv4 application server and/or service 315. First IPv4 data packet 310 arrives to supporting gateway node 320 of network 300 (an IPv6 network). Supporting gateway node 320 provides network side translation services for accessing IPv4 service 315. As described in more detail below, for example, gateway node 320 may translate IPv4 data packet 310 into an IPv6 data packet (also referred to as Datagram 2 340 in FIGURES 3 and 4) so that it can traverse the IPv6 network 300.

In certain embodiments, gateway node 320 may include components for storing logic and/or instructions for implementing CLAT processing, according to certain embodiments. Examples of gateway node 320 include, but are not limited to, a mobile switching center (MSC), a serving GPRS support node (SGSN), a mobility management entity (MME), a radio network controller (RNC), a base station controller (BSC), and any other suitable network node. The present disclosure contemplates that gateway node 320 may include any hardware, software, or combination thereof configured to translate IPv4 addresses into IPv6 addresses. In certain embodiments, gateway node 320 includes CLAT functionality 325 and PLAT Control 330, and may include any other suitable functionality. For example, gateway node 320 may include hardware and software for performing address translation services such that requests received from wireless devices operating according to a variety of different protocols, such as wireless device 110, may traverse an IPv6 network.

Upon receiving IPv4 data packet 310, gateway node 320 perfoms the translation of IPv4 data packet 310 into IPv6 data packet 340 (also referred to as Datagram 2 in FIGURES 3 and 4). In certain embodiments, CLAT functionality 325 of gateway node 320 translates the IPv4 datagram into IPv6. CLAT 325 is the portion of the 464XLAT technology described above that provides stateless address translation for the deployment of IPv4 services in an IPv6 network. More specifically, CLAT 325 may include daemon for the local performance of IP translation with regard to a request for IPv4 service 315. For example, when wireless device 110 seeks access to IPv4 service 315, CLAT 325 may translate the target IPv4 address associated with IPv4 service 315 into a synthetic IPv6 address.

In certain embodiments, gateway node 320 identifies that a session is being created, and stores a session mapping for IPv4 data packet 310 and IPv6 data packet 340. In certain embodiments, gateway node 320 allocates and retains the information about the Stateful PLAT translation in a different node than the node that actually performs the translation. Also, this information may be distributed from the gateway node 320 to the PLAT node 335, for example by embedding it into the IPv6 packets. Gateway node 320 can use the stored session mapping state for use with future packets belonging to the same session, and also for session lifetime keeping. For example, in certain embodiments storing the session mapping state may enable policy mapping for devices behind the NAT, and logging and troubleshooting challenges associated with combining information from multiple sources.

In certain embodiments, CLAT 325 functionality in gateway node 320 identifies the new communication session being created and contacts PLAT Control functionality 330 to obtain a public IPv4 address (shown as C284:C6A5 in the IPv6 Dst header field of Datagram 2 of FIGURE 4) and a port allocation (shown as ODAD in the IPv6 Dst header field of Datagram 2 of FIGURE 4) for this session, which it will include in the IPv6 Dst header field of IPv6 data packet 340 in order to distribute that information to PLAT node 335 located at the provider edge. In other words, PLAT control 330 may acquire a public IPv4 address and port allocation associated with the IPv4 address of IPv4 data packet 310. The public IPv4 address and port allocation are included in the IPv6 data packet 340. In this manner, different components of the IPv6 network, such as gateway node 320 and PLAT 335, may be informed as to the public IPv4 address assigned to wireless device 110. With that knowledge, it may be possible for the components of the network to translate IPv6 packets intended for wireless device 110 back to IPv4.

This step differs from other implementations where only a unique CLAT IPv6 prefix (allocated by gateway node 320 for wireless device 110, shown as 2001 :db8:cla7:1234 in the IPv6 Src header field of Datagram 2 of FIGURE 4) was included as source IPv6 address in the IPv6 packet header. In the example of FIGURES 3 and 4, the UE IPv4 address (shown as 10.10.204.1 in the IPv6 Src header field of Datagram 2 of FIGURE 4) is added as a suffix to the IPv6 source address in the IPv6 Src header field of Datagram 2. This is not needed for the translation state but can be included for logging purposes, and/or if wireless device 1 10 is allowed to use multiple IPv4 addresses. Then this suffix may be used to separate state between sessions from the same wireless device 110 but with separate IPv4 source addresses.

After performing the translation of IPv4 data packet 310 to IPv6 data packet 340, gateway node 320 transmits IPv6 data packet 340 to a selected translation node. In the example of FIGURE 3, the selected translation node is PLAT 335 of a provider edge. PLAT 335 may translate the IPv6 information in IPv6 data packet 340 into an IPv4 data packet (also referred to as Datagram 3 345 in FIGURES 3 and 4). In certain embodiments, a provider edge may include PLAT 335 for translating the synthetic IPv6 address included in IPv6 data packet 340 (i.e., Datagram 2) into the target IPv4 address suitable for accessing IPv4 service 315. This translation from IPv6 data packet 340 to IPv4 packet 345 may be performed in any suitable manner.

For example, in certain embodiments PLAT 335 receives IPv6 packet 340 and extracts from the IPv6 header information a target IP address associated with a destination of IPv6 data packet 340 in order to do the translation from IPv6 data packet 340 to IPv4 data packet 345, which includes the IPv4 destination address (shown as 198.51.100.1 in the IPv4 Dst header field of Datagram 3 of FIGURE 4), public IPv4 source address (shown as 194.132.198.165 in the IPv4 Src header field of Datagram 3 in FIGURE 4) and port (shown as 0DAD in the TCP Port Src field of Datagram 3 in FIGURE 4). PLAT 335 also retains the knowledge about this mapping in memory. Thus, PLAT 335 at the provider edge may replace the synthetic IPv6 address with the target IPv4 address. In particular embodiments, PLAT 335 may include in IPv4 data packet 345 the public IPv4 address acquired by PLAT control 330.

The translated IPv4 packet 345 is forwarded (i.e., transmitted) to the IPv4 application server and/or service 315. In certain embodiments, PLAT 335 may communicate the IPv4 data packet 345 to AF server 350. AF server 350 may then communicate the IPv4 data packet 345 to IPv4 server and/or service 315.

In certain embodiments, IPv4 server and/or service 315 may communicate information back to wireless device 110 using the public IPv4 address acquired by PLAT control 330. For example, the server and/or service 315 may allocate resources for the application session and reply back with an IPv4 packet (destinated to the public IPv4 address/port used). The IPv4 packet reaches PLAT 335. Upon receiving the IPv4 Packet from server and/or service 315, PLAT 335 performs a look-up in its internal memory and determines how to do the reverse mapping (IPv4 to IPv6). PLAT 335 translates the IPv4 data packet to an IPv6 data packet and sends it to gateway node 320. Based on the IPv6 address, gateway node 320 finds the user context so it can translate the IPv6 packet to an IPv4 packet, encapsulate it in the corresponding General Packet Radio Service Tunneling Protocol (GTP) tunnel, and send it to the IPv4 Application 305 (residing in wireless device 110). In certain embodiments, gateway node 320 replaces the public IPv4 address for wireless device 110 with the private IPv4 address of wireless device 110.

FIGURE 5 is a flow chart of a method 500 in a network node, in accordance with certain embodiments. The method begins at step 504, where the network node receives a first data packet from a wireless device, the first data packet comprising a destination header field including a target IP address as a destination of the received data packet. In certain embodiments, the network node may comprise a gateway node in a packet core domain. The first data packet may comprise an IPv4 data packet. In certain embodiments, the method may comprise identifying that a session is being created, and storing a session mapping state for the first and second data packets for use with a subsequent data packet belonging to the session.

At step 508, the network node obtains a public IP address and a port allocation associated with the wireless device. In certain embodiments, the public IP address may be an IPv4 address.

At step 12, the network node translates the target IP address into a synthetic IP address, the synthetic IP address comprising the target IP address, the public IP address and the port allocation associated with the wireless device.

At step 516, the network node generates a second data packet, the second data packet comprising a destination header field including the synthetic IP address as a destination of the second data packet. In certain embodiments, the second data packet may comprise an IPv6 data packet. In certain embodiments, the method may comprise allocating an IPv6 prefix to the wireless device. The second data packet may comprise a source header field including the IPv6 prefix allocated to the wireless device and a source IPv4 address for the wireless device as a source of the second data packet.

At step 520, the network node transmits the second data packet to a translation node. In certain embodiments, the method may comprise receiving a third data packet from the translation node. The third data packet may be an IPv6 packet comprising a destination header field including the IPv6 prefix and the public IP address associated with the wireless device. The method may comprise: identifying, based on the IPv6 prefix allocated to the wireless device, a user context associated with the wireless device; translating the third data packet to a fourth data packet, the fourth data packet comprising an IPv4 packet; and transmitting the fourth data packet to the wireless device.

FIGURE 6 is a flow chart of a method 600 in a network node, in accordance with certain embodiments. The method begins at step 604, where the network node receives a first data packet from a gateway node in a packet core domain, the first data packet comprising a destination header field including a synthetic IP address as a destination of the first data packet, the synthetic IP address comprising a target IP address associated with a destination of the first packet, and a public IP address and a port allocation associated with a wireless device. In certain embodiments, the public IP address may be an IPv4 address. In certain embodiments, the first data packet may comprise an IPv6 data packet. In certain embodiments, the first data packet may comprise a source header field. The source header field may comprise an IPv6 prefix allocated to the wireless device by the gateway node and an IPv4 address for the wireless device.

At step 608, the network node extracts from the first data packet the target IP address associated with the destination of the first packet. At step 612, the network node generates a second data packet, the second data packet comprising a destination header field including the target IP address and a source header field including the public IP address associated with the wireless device as a source of the second data packet. In certain embodiments, the method may comprise storing a mapping between the first data packet and the second data packet. In certain embodiments, the second data packet may comprise an IPv4 data packet.

At step 616, the network node transmits the second data packet to the destination of the first packet.

FIGURE 7 is a block schematic of an exemplary wireless device, in accordance with certain embodiments. Wireless device 110 may refer to any type of wireless device communicating with a node and/or with another wireless device in a cellular or mobile communication system. Examples of wireless device 110 include a mobile phone, a smart phone, a PDA (Personal Digital Assistant), a portable computer (e.g., laptop, tablet), a sensor, a modem, a machine-type-communication (MTC) device / machine-to-machine (M2M) device, laptop embedded equipment (LEE), laptop mounted equipment (LME), USB dongles, a D2D capable device, or another device that can provide wireless communication. A wireless device 110 may also be referred to as UE, a station (STA), a device, or a terminal in some embodiments. Wireless device 110 includes transceiver 710, processor 720, and memory 730. In some embodiments, transceiver 710 facilitates transmitting wireless signals to and receiving wireless signals from network node 115 (e.g., via antenna 740), processor 720 executes instructions to provide some or all of the functionality described above as being provided by wireless device 110, and memory 730 stores the instructions executed by processor 720.

Processor 720 may include any suitable combination of hardware and software implemented in one or more modules to execute instructions and manipulate data to perform some or all of the described functions of wireless device 110, such as the functions of wireless device 110 described above in relation to FIGURES 1-6. In some embodiments, processor 720 may include, for example, one or more computers, one or more central processing units (CPUs), one or more microprocessors, one or more applications, one or more application specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs) and/or other logic.

Memory 730 is generally operable to store instructions, such as a computer program, software, an application including one or more of logic, rules, algorithms, code, tables, etc. and/or other instructions capable of being executed by a processor. Examples of memory 730 include computer memory (for example, Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (for example, a hard disk), removable storage media (for example, a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or or any other volatile or non-volatile, non-transitory computer-readable and/or computer-executable memory devices that store information, data, and/or instructions that may be used by processor 1020.

Other embodiments of wireless device 110 may include additional components beyond those shown in FIGURE 7 that may be responsible for providing certain aspects of the wireless device's functionality, including any of the functionality described above and/or any additional functionality (including any functionality necessary to support the solution described above). As just one example, wireless device 110 may include input devices and circuits, output devices, and one or more synchronization units or circuits, which may be part of the processor 720. Input devices include mechanisms for entry of data into wireless device 110. For example, input devices may include input mechanisms, such as a microphone, input elements, a display, etc. Output devices may include mechanisms for outputting data in audio, video and/or hard copy format. For example, output devices may include a speaker, a display, etc.

FIGURE 8 is a block schematic of an exemplary network node, in accordance with certain embodiments. Network node 115 may be any type of radio network node or any network node that communicates with a UE and/or with another network node. Examples of network node 115 include an eNodeB, a node B, a base station, a wireless access point (e.g., a Wi-Fi access point), a low power node, a base transceiver station (BTS), relay, donor node controlling relay, transmission points, transmission nodes, remote RF unit (RRU), remote radio head (RRH), mult i- standard radio (MSR) radio node such as MSR BS, nodes in distributed antenna system (DAS), O&M, OSS, SON, positioning node (e.g., E-SMLC), MDT, or any other suitable network node. Network nodes 115 may be deployed throughout network 100 as a homogenous deployment, heterogeneous deployment, or mixed deployment. A homogeneous deployment may generally describe a deployment made up of the same (or similar) type of network nodes 115 and/or similar coverage and cell sizes and inter-site distances. A heterogeneous deployment may generally describe deployments using a variety of types of network nodes 115 having different cell sizes, transmit powers, capacities, and inter-site distances. For example, a heterogeneous deployment may include a plurality of low-power nodes placed throughout a macro-cell layout. Mixed deployments may include a mix of homogenous portions and heterogeneous portions.

Network node 115 may include one or more of transceiver 810, processor 820, memory 830, and network interface 840. In some embodiments, transceiver 810 facilitates transmitting wireless signals to and receiving wireless signals from wireless device 110 (e.g., via antenna 850), processor 820 executes instructions to provide some or all of the functionality described above as being provided by a network node 115, memory 830 stores the instructions executed by processor 820, and network interface 840 communicates signals to backend network components, such as a gateway, switch, router, Internet, Public Switched Telephone Network (PSTN), core network nodes or radio network controllers 130, etc.

Processor 820 may include any suitable combination of hardware and software implemented in one or more modules to execute instructions and manipulate data to perform some or all of the described functions of network node 115, such as those described above in relation to FIGURES 1-6 above. In some embodiments, processor 820 may include, for example, one or more computers, one or more central processing units (CPUs), one or more microprocessors, one or more applications, and/or other logic.

Memory 830 is generally operable to store instructions, such as a computer program, software, an application including one or more of logic, rules, algorithms, code, tables, etc. and/or other instructions capable of being executed by a processor. Examples of memory 830 include computer memory (for example, Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (for example, a hard disk), removable storage media (for example, a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or or any other volatile or non-volatile, non-transitory computer-readable and/or computer-executable memory devices that store information.

In some embodiments, network interface 840 is communicatively coupled to processor 820 and may refer to any suitable device operable to receive input for network node 115, send output from network node 115, perform suitable processing of the input or output or both, communicate to other devices, or any combination of the preceding. Network interface 840 may include appropriate hardware (e.g., port, modem, network interface card, etc.) and software, including protocol conversion and data processing capabilities, to communicate through a network.

Other embodiments of network node 115 may include additional components beyond those shown in FIGURE 8 that may be responsible for providing certain aspects of the radio network node's functionality, including any of the functionality described above and/or any additional functionality (including any functionality necessary to support the solutions described above). The various different types of network nodes may include components having the same physical hardware but configured (e.g., via programming) to support different radio access technologies, or may represent partly or entirely different physical components.

FIGURE 9 is a block schematic of an exemplary radio network controller or core network node 130, in accordance with certain embodiments. Examples of network nodes can include a mobile switching center (MSC), a serving GPRS support node (SGSN), a mobility management entity (MME), a radio network controller (RNC), a base station controller (BSC), and so on. In certain embodiments, the radio controller or core network node may perform the functions of the supporting gateway node 320 described above in relation to FIGURES 3 and 4. The radio network controller or core network node 130 includes processor 920, memory 930, and network interface 940. In some embodiments, processor 920 executes instructions to provide some or all of the functionality described above as being provided by the network node, memory 930 stores the instructions executed by processor 920, and network interface 940 communicates signals to any suitable node, such as a gateway, switch, router, Internet, Public Switched Telephone Network (PSTN), network nodes 115, radio network controllers or core network nodes 130, etc.

Processor 920 may include any suitable combination of hardware and software implemented in one or more modules to execute instructions and manipulate data to perform some or all of the described functions of the radio network controller or core network node 130. In some embodiments, processor 920 may include, for example, one or more computers, one or more central processing units (CPUs), one or more microprocessors, one or more applications, and/or other logic.

Memory 930 is generally operable to store instructions, such as a computer program, software, an application including one or more of logic, rules, algorithms, code, tables, etc. and/or other instructions capable of being executed by a processor. Examples of memory 930 include computer memory (for example, Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (for example, a hard disk), removable storage media (for example, a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or or any other volatile or non-volatile, non-transitory computer-readable and/or computer-executable memory devices that store information.

In some embodiments, network interface 940 is communicatively coupled to processor 920 and may refer to any suitable device operable to receive input for the network node, send output from the network node, perform suitable processing of the input or output or both, communicate to other devices, or any combination of the preceding. Network interface 940 may include appropriate hardware (e.g., port, modem, network interface card, etc.) and software, including protocol conversion and data processing capabilities, to communicate through a network.

Other embodiments of the network node may include additional components beyond those shown in FIGURE 9 that may be responsible for providing certain aspects of the network node's functionality, including any of the functionality described above and/or any additional functionality (including any functionality necessary to support the solution described above).

FIGURE 10 is a block schematic of an exemplary wireless device, in accordance with certain embodiments. Wireless device 110 may include one or more modules. For example, wireless device 110 may include a determining module 1010, a communication module 1020, a receiving module 1030, an input module 1040, a display module 1050, and any other suitable modules. Wireless device 110 may perform the methods for enabling IPv6 networks described above with respect to FIGURES 1-6.

Determining module 1010 may perform the processing functions of wireless device 110. Determining module 1010 may include or be included in one or more processors, such as processor 720 described above in relation to FIGURE 7. Determining module 1010 may include analog and/or digital circuitry configured to perform any of the functions of determining module 1010 and/or processor 720 described above. The functions of determining module 1010 described above may, in certain embodiments, be performed in one or more distinct modules.

Communication module 1020 may perform the transmission functions of wireless device 110. Communication module 1020 may transmit messages to one or more of network nodes 115 of network 100. Communication module 1020 may include a transmitter and/or a transceiver, such as transceiver 710 described above in relation to FIGURE 7. Communication module 1020 may include circuitry configured to wirelessly transmit messages and/or signals. In particular embodiments, communication module 1020 may receive messages and/or signals for transmission from determining module 1010. In certain embodiments, the functions of communication module 1020 described above may be performed in one or more distinct modules.

Receiving module 1030 may perform the receiving functions of wireless device 110. Receiving module 1030 may include a receiver and/or a transceiver, such as transceiver 710 described above in relation to FIGURE 7. Receiving module 1030 may include circuitry configured to wirelessly receive messages and/or signals. In particular embodiments, receiving module 1030 may communicate received messages and/or signals to determining module 1010.

Input module 1040 may receive user input intended for wireless device 110. For example, the input module may receive key presses, button presses, touches, swipes, audio signals, video signals, and/or any other appropriate signals. The input module may include one or more keys, buttons, levers, switches, touchscreens, microphones, and/or cameras. The input module may communicate received signals to determining module 1010.

Display module 1050 may present signals on a display of wireless device 110. Display module 1050 may include the display and/or any appropriate circuitry and hardware configured to present signals on the display. Display module 1050 may receive signals to present on the display from determining module 1010.

Determining module 1010, communication module 1020, receiving module 1030, input module 1040, and display module 1050 may include any suitable configuration of hardware and/or software. Wireless device 110 may include additional modules beyond those shown in FIGURE 10 that may be responsible for providing any suitable functionality, including any of the functionality described above and/or any additional functionality (including any functionality necessary to support the various solutions described herein).

FIGURE 11 is a block schematic of an exemplary network node 115, in accordance with certain embodiments. Network node 115 may include one or more modules. For example, network node 115 may include determining module 1110, communication module 1120, receiving module 1130, and any other suitable modules. In some embodiments, one or more of determining module 1110, communication module 1120, receiving module 1130, or any other suitable module may be implemented using one or more processors, such as processor 820 described above in relation to FIGURE 8. In certain embodiments, the functions of two or more of the various modules may be combined into a single module. Network node 115 may perform the methods for enabling IPv6 networks described above with respect to FIGURES 1-6.

Determining module 1110 may perform the processing functions of network node 115. For example, in certain embodiments network node 115 may perform the functions of the supporting gateway node 320 described above in relation to FIGURES 3 and 4. In such a case, determining module 1110 may obtain a public IP address and a port allocation associated with the wireless device. As another example, determining module 1110 may translate the target IP address into a synthetic IP address, the synthetic IP address comprising the target IP address, the public IP address and the port allocation associated with the wireless device. As another example, determining module 1110 may generate a second data packet, the second data packet comprising a destination header field including the synthetic IP address as a destination of the second data packet. As still another example, determining module 1110 may identify that a session is being created and store a session mapping state for the first and second data packets for use with a subsequent data packet belonging to the session. As yet another example, determining module 1110 may allocate an IPv6 prefix to the wireless device, wherein the second data packet comprises a source header field including the IPv6 prefix allocated to the wireless device and a source IPv4 address for the wireless device as a source of the second data packet. As yet another example, determining module 1110 may identify, based on the IPv6 prefix allocated to the wireless device, a user context associated with the wireless device, and translate the third data packet to a fourth data packet, the fourth data packet comprising an IPv4 packet.

As another example, in certain embodiments network node 115 may perform the functions of a translation node, such as PLAT 335 described above with respect to FIGURES 3 and 4. In such a case, determining module 1110 may extract from the first data packet the target IP address associated with the destination of the first packet. As another example, determining module 1110 may generate a second data packet, the second data packet comprising a destination header field including the target IP address and a source header field including the public IP address associated with the wireless device as a source of the second data packet. As another example, determining module 1110 may store a mapping between the first data packet and the second data packet. As another example, determining module 1110 may translate, based on a stored mapping between the first data packet and the second data packet, the third data packet to a fourth data packet, the fourth data packet comprising an IPv6 packet comprising a destination header field including the IPv6 prefix allocated to the wireless device by the gateway node and the IPv4 address for the wireless device.

Determining module 11 10 may include or be included in one or more processors, such as processor 820 described above in relation to FIGURE 8. Determining module 1110 may include analog and/or digital circuitry configured to perform any of the functions of determining module 1110 and/or processor 820 described above. The functions of determining module 1110 may, in certain embodiments, be performed in one or more distinct modules. For example, in certain embodiments some of the functionality of determining module 1110 may be performed by an allocation module.

Communication module 1120 may perform the transmission functions of network node 115. For example, in certain embodiments, network node 115 may perform the functions of the supporting gateway node 320 described above in relation to FIGURES 3 and 4. In such a case, communication module 1120 may transmit the second data packet to a translation node.

As another example, in certain embodiments network node 115 may perform the functions of a translation node, such as PLAT 335 described above in relation to FIGURES 3 and 4. In such a case, communication module 1120 may transmit the second data packet to the destination of the first packet. As another example, communication module 1120 may transmit the fourth data packet to the wireless device.

Communication module 1120 may transmit messages to one or more of wireless devices 110. Communication module 1120 may include a transmitter and/or a transceiver, such as transceiver 810 described above in relation to FIGURE 8. Communication module 1120 may include circuitry configured to wirelessly transmit messages and/or signals. In particular embodiments, communication module 1120 may receive messages and/or signals for transmission from determining module 1110 or any other module.

Receiving module 1130 may perform the receiving functions of network node 115. For example, in certain embodiments, network node 115 may perform the functions of the supporting gateway node 320 described above in relation to FIGURES 3 and 4. In such a case, receiving module 1130 may, for example, receive a first data packet from a wireless device, the first data packet comprising a destination header field including a target IP address as a destination of the received data packet. As another example, receiving module 1130 may obtain a public IP address and a port allocation associated with the wireless device.

As another example, in certain embodiments network node 115 may perform the functions of a translation node, such as PLAT 335 described above in relation to FIGURES 3 and 4. In such a case, receiving module 1130 may receive a first data packet from a gateway node in a packet core domain, the first data packet comprising a destination header field including a synthetic IP address as a destination of the first data packet, the synthetic IP address comprising a target IP address associated with a destination of the first packet, and a public IP address and a port allocation associated with a wireless device. As another example, receiving module 1130 receiving a third data packet from the destination of the first data packet, the third data packet comprising an IPv4 packet comprising a destination header field including the public IP address associated with the wireless device.

Receiving module 1130 may receive any suitable information from a wireless device. Receiving module 1130 may include a receiver and/or a transceiver, such as transceiver 810 described above in relation to FIGURE 8. Receiving module 1130 may include circuitry configured to wirelessly receive messages and/or signals. In particular embodiments, receiving module 1130 may communicate received messages and/or signals to determining module 1110 or any other suitable module.

Determining module 1110, communication module 1120, and receiving module 1130 may include any suitable configuration of hardware and/or software. Network node 115 may include additional modules beyond those shown in FIGURE 11 that may be responsible for providing any suitable functionality, including any of the functionality described above and/or any additional functionality (including any functionality necessary to support the various solutions described herein).

FIGURE 12 is a block schematic of an exemplary radio network controller or core network node 130, in accordance with certain embodiments. As described above, examples of radio network controller or core network node 130 can include a mobile switching center (MSC), a serving GPRS support node (SGSN), a mobility management entity (MME), a radio network controller (RNC), a base station controller (BSC), and any other suitable network nodes. In certain embodiments, the radio controller or core network node 130 may perform the functions of the supporting gateway node described above in relation to FIGURES 3 and 4. Radio network controller or core network node 130 may include one or more modules. In the example of FIGURE 12, radio network controller or core network node 130 includes at least one determining module 1210, at least one communication module 1220, and at least one receiving module 1230. Radio network controller or core network node 130 may perform the methods for enabling IPv6 networks described above with respect to FIGURES 1-6.

Determining module 1210 may perform the processing functions of radio network controller 120. For example, in certain embodiments radio network controller or core network node 130 may perform the functions of supporting gateway node 320 described above in relation to FIGURES 3 and 4. In such a case, determining module 1210 may, for example, obtain a public IP address and a port allocation associated with the wireless device. As another example, determining module 1210 may translate the target IP address into a synthetic IP address, the synthetic IP address comprising the target IP address, the public IP address and the port allocation associated with the wireless device. As still another example, determining module 1210 may generate a second data packet, the second data packet comprising a destination header field including the synthetic IP address as a destination of the second data packet. As yet another example, determining module 1210 may identify that a session is being created and store a session mapping state for the first and second data packets for use with a subsequent data packet belonging to the session. As another example, determining module 1210 may allocate an IPv6 prefix to the wireless device, wherein the second data packet comprises a source header field including the IPv6 prefix allocated to the wireless device and a source IPv4 address for the wireless device as a source of the second data packet. As another example, determining module 1210 may identify, based on the IPv6 prefix allocated to the wireless device, a user context associated with the wireless device, and translate the third data packet to a fourth data packet, the fourth data packet comprising an IPv4 packet.

Determining module 1210 may include or be included in one or more processors, such as processor 1620 described above with respect to FIGURE 16. Determining module 1210 may include analog and/or digital circuitry configured to perform any of the functions of determining module 1210. The functions of determining module 1210 described above may, in certain embodiments, be performed in one or more distinct modules.

Communication module 1220 may perform the transmission functions of radio network controller 120. For example, in certain embodiments radio network controller or core network node 130 may perform the functions of supporting gateway node 320 described above in relation to FIGURES 3 and 4. In such a case, communication module 1220 may transmit the second data packet to a translation node. As another example, communication module 1220 may transmit the fourth data packet to the wireless device. Communication module 1220 may transmit messages to one or more of network nodes 115 and wireless devices 110 of network 100. Communication module 1220 may include a transmitter and/or a transceiver, and/or a network interface, such as network interface 940 described above with respect to FIGURE 9. Communication module 1220 may include circuitry configured to wirelessly transmit messages and/or signals. In particular embodiments, communication module 1220 may receive messages and/or signals for transmission from determining module 1210. In certain embodiments, the functions of communication module 1220 described above may be performed in one or more distinct modules.

Receiving module 1230 may perform the receiving functions of radio network controller or core network node 130. For example, in certain embodiments radio network controller or core network node 130 may perform the functions of supporting gateway node 320 described above in relation to FIGURES 3 and 4. In such a case, receiving module 1230 may, for example, receive a first data packet from a wireless device, the first data packet comprising a destination header field including a target IP address as a destination of the received data packet. As another example, receiving module 1230 may obtain a public IP address and a port allocation associated with the wireless device. As still another example, receiving module 1230 may receive a third data packet from the translation node, the third data packet comprising an IPv6 packet comprising a destination header field including the IPv6 prefix and the public IP address associated with the wireless device. Receiving module 1230 may include a transmitter and/or a transceiver, and/or a network interface, such as network interface 940 described above with respect to FIGURE 9. Receiving module 1230 may include circuitry configured to wirelessly receive messages and/or signals. In particular embodiments, receiving module 1230 may communicate received messages and/or signals to determining module 1210.

Modifications, additions, or omissions may be made to the systems and apparatuses described herein without departing from the scope of the disclosure. The components of the systems and apparatuses may be integrated or separated. Moreover, the operations of the systems and apparatuses may be performed by more, fewer, or other components. Additionally, operations of the systems and apparatuses may be performed using any suitable logic comprising software, hardware, and/or other logic. As used in this document, "each" refers to each member of a set or each member of a subset of a set.

Modifications, additions, or omissions may be made to the methods described herein without departing from the scope of the disclosure. The methods may include more, fewer, or other steps. Additionally, steps may be performed in any suitable order.

Although this disclosure has been described in terms of certain embodiments, alterations and permutations of the embodiments will be apparent to those skilled in the art. Accordingly, the above description of the embodiments does not constrain this disclosure. Other changes, substitutions, and alterations are possible without departing from the spirit and scope of this disclosure, as defined by the following claims.

Abbreviations used in the preceding description include:

AF Application Function

AP Access Point

BS Base Station

BSC Base Station Controller

BTS Base Transceiver Station

CDM Code Division Multiplexing

CPE Customer Premises Equipment

D2D Device-to-device

DAS Distributed Antenna System

DL Downlink

DNS Domain Name Service

eNB evolved Node B

EPDCCH Enhanced Physical Downlink Control Channel

FDD Frequency Division Duplex

Gi/SGi Guard Interval/Short Guard Interval

LAN Local Area Network

LEE Laptop Embedded Equipment LME Laptop Mounted Equipment

LTE Long Term Evolution

M2M Machine-to-Machine

MAN Metropolitan Area Network

MCE Multi-cell/multicast Coordination Entity

MSISDN Mobile Station International Subscriber Directory Number

MSR Multi-standard Radio

NAS Non-Access Stratum

NAT Network Address Translation

PCC Policy, Control, and Charging

PDCCH Physical Downlink Control Channel

PDSCH Physical Downlink Shared Channel

PSTN Public Switched Telephone Network

PUSCH Physical Uplink Shared Channel

PUCCH Physical Uplink Control Channel

RB Resource Block

RNC Radio Network Controller

RRC Radio Resource Control

RRH Remote Radio Head

RRU Remote Radio Unit

TDD Time Division Duplex

TEID Tunnel Endpoint Identifier

UE User Equipment

UL Uplink

WAN Wide Area Network

Claims

CLAIMS:

1. A method in a network node (115, 130, 320), comprising:

receiving (504) a first data packet (310) from a wireless device (110), the first data packet (310) comprising a destination header field including a target IP address as a destination of the received data packet;

obtaining (508) a public IP address and a port allocation associated with the wireless device (110);

translating ( 12) the target IP address into a synthetic IP address, the synthetic IP address comprising the target IP address, the public IP address and the port allocation associated with the wireless device (110);

generating (516) a second data packet (340), the second data packet (340) comprising a destination header field including the synthetic IP address as a destination of the second data packet; and

transmitting (520) the second data packet (340) to a translation node (335).

2. The method of Claim 1, comprising:

identifying that a session is being created; and

storing a session mapping state for the first and second data packets (310, 335) for use with a subsequent data packet belonging to the session.

3. The method of Claim 1, wherein the network node comprises a gateway node (320) in a packet core domain.

4. The method of Claim 1, wherein the first data packet (310) comprises an IPv4 data packet and the second data packet (340) comprises an IPv6 data packet.

5. The method of Claim 4, wherein the public IP address is an IPv4 address.

6. The method of Claim 4, further comprising:

allocating an IPv6 prefix to the wireless device (110), wherein the second data packet (340) comprises a source header field including the IPv6 prefix allocated to the wireless device (110) and a source IPv4 address for the wireless device (110) as a source of the second data packet (340).

7. The method of Claim 6, further comprising:

receiving a third data packet from the translation node (335), the third data packet comprising an IPv6 packet comprising a destination header field including the IPv6 prefix and the public IP address associated with the wireless device (110);

identifying, based on the IPv6 prefix allocated to the wireless device (110), a user context associated with the wireless device (110);

translating the third data packet to a fourth data packet, the fourth data packet comprising an IPv4 packet; and

transmitting the fourth data packet to the wireless device (110).

8. A method in a network node (110, 335), comprising:

receiving (604) a first data packet (340) from a gateway node (320) in a packet core domain, the first data packet (340) comprising a destination header field including a synthetic IP address as a destination of the first data packet (340), the synthetic IP address comprising a target IP address associated with a destination of the first packet, and a public IP address and a port allocation associated with a wireless device (110); and

extracting (608) from the first data packet (340) the target IP address associated with the destination of the first packet (340);

generating (612) a second data packet (345), the second data packet (345) comprising a destination header field including the target IP address and a source header field including the public IP address associated with the wireless device (110) as a source of the second data packet (345); and

transmitting (616) the second data packet (345) to the destination of the first packet

(340).

9. The method of Claim 8, comprising:

storing a mapping between the first data packet (340) and the second data packet (345).

10. The method of Claim 8, wherein the first data packet (340) comprises an IPv6 data packet and the second data packet (345) comprises an IPv4 data packet.

11. The method of Claim 10, wherein the public IP address is an IPv4 address.

12. The method of Claim 11 , wherein the first data packet (340) comprises a source header field, the source header field comprising an IPv6 prefix allocated to the wireless device (110) by the gateway node (320) and an IPv4 address for the wireless device (110).

13. The method of Claim 12, further comprising:

receiving a third data packet from the destination of the first data packet, the third data packet comprising an IPv4 packet comprising a destination header field including the public IP address associated with the wireless device (110);

translating, based on a stored mapping between the first data packet (340) and the second data packet (345), the third data packet to a fourth data packet, the fourth data packet comprising an IPv6 packet comprising a destination header field including the IPv6 prefix allocated to the wireless device (110) by the gateway node (320) and the IPv4 address for the wireless device (110); and

transmitting the fourth data packet to the wireless device (110).

14. A network node (115, 130, 320), comprising:

one or more processors (820, 920), the one or more processors (820, 920) configured to:

receive (504) a first data packet (310) from a wireless device (110), the first data packet (310) comprising a destination header field including a target IP address as a destination of the received data packet;

obtain (508) a public IP address and a port allocation associated with the wireless device

(110);

translate ( 12) the target IP address into a synthetic IP address, the synthetic IP address comprising the target IP address, the public IP address and the port allocation associated with the wireless device (110);

generate ( 16) a second data packet (340), the second data packet (340) comprising a destination header field including the synthetic IP address as a destination of the second data packet; and

transmit (520) the second data packet (340) to a translation node (335).

15. The network node (115, 130, 320) of Claim 14, wherein the one or more processors (820, 920) are configured to:

identify that a session is being created; and

store a session mapping state for the first and second data packets (310, 335) for use with a subsequent data packet belonging to the session.

16. The network node (115, 130, 320) of Claim 14, wherein the network node comprises a gateway node (320) in a packet core domain.

17. The network node (115, 130, 320) of Claim 14, wherein the first data packet (310) comprises an IPv4 data packet and the second data packet (340) comprises an IPv6 data packet.

18. The network node (115, 130, 320) of Claim 17, wherein the public IP address is an IPv4 address.

19. The network node (115, 130, 320) of Claim 17, wherein the one or more processors (820, 920) are configured to:

allocate an IPv6 prefix to the wireless device (110), wherein the second data packet (340) comprises a source header field including the IPv6 prefix allocated to the wireless device (110) and a source IPv4 address for the wireless device (110) as a source of the second data packet (340).

20. The network node (115, 130, 320) of Claim 19, wherein the one or more processors (820, 920) are configured to:

receive a third data packet from the translation node (335), the third data packet comprising an IPv6 packet comprising a destination header field including the IPv6 prefix and the public IP address associated with the wireless device (110);

identify, based on the IPv6 prefix allocated to the wireless device (110), a user context associated with the wireless device (110);

translate the third data packet to a fourth data packet, the fourth data packet comprising an IPv4 packet; and

transmit the fourth data packet to the wireless device (110).

21. A network node (115, 335), comprising:

one or more processors (820), the one or more processors (820) configured to:

receive (604) a first data packet (340) from a gateway node (320) in a packet core domain, the first data packet (340) comprising a destination header field including a synthetic IP address as a destination of the first data packet (340), the synthetic IP address comprising a target IP address associated with a destination of the first packet, and a public IP address and a port allocation associated with a wireless device (110); and

extract (608) from the first data packet (340) the target IP address associated with the destination of the first packet (340);

generate (612) a second data packet (345), the second data packet (345) comprising a destination header field including the target IP address and a source header field including the public IP address associated with the wireless device ( 110) as a source of the second data packet (345); and

transmit (616) the second data packet (345) to the destination of the first packet (340).

22. The network node (115, 335) of Claim 21, wherein the one or more processors (820) are configured to:

store a mapping between the first data packet (340) and the second data packet (345).

23. The network node (115, 335) of Claim 21, wherein the first data packet (340) comprises an IPv6 data packet and the second data packet (345) comprises an IPv4 data packet.

24. The network node (115, 335) of Claim 23, wherein the public IP address is an IPv4 address.

25. The network node (115, 335) of Claim 23, wherein the first data packet (340) comprises a source header field, the source header field comprising an IPv6 prefix allocated to the wireless device (110) by the gateway node (320) and an IPv4 address for the wireless device (110).

26. The network node (115, 335) of Claim 25, wherein the one or more processors (820) are configured to:

receive a third data packet from the destination of the first data packet, the third data packet comprising an IPv4 packet comprising a destination header field including the public IP address associated with the wireless device (110);

translate, based on a stored mapping between the first data packet (340) and the second data packet (345), the third data packet to a fourth data packet, the fourth data packet comprising an IPv6 packet comprising a destination header field including the IPv6 prefix allocated to the wireless device (110) by the gateway node (320) and the IPv4 address for the wireless device (110); and

transmit the fourth data packet to the wireless device (110).