WO2025037803A1

WO2025037803A1 - Method and apparatus for managing nat policies for peer-to-peer communication in wireless communication system

Info

Publication number: WO2025037803A1
Application number: PCT/KR2024/011260
Authority: WO
Inventors: Naman Gupta; Kisuk Kweon
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2023-08-11
Filing date: 2024-07-31
Publication date: 2025-02-20
Anticipated expiration: 2026-02-11

Abstract

The disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. Specifically, the disclosure provides a method and apparatus for handling NAT policies for P2P communication in wireless communication system.

Description

METHOD AND APPARATUS FOR MANAGING NAT POLICIES FOR PEER-TO-PEER COMMUNICATION IN WIRELESS COMMUNICATION SYSTEM

The disclosure relates to a wireless communication system (or a mobile communication system). Specifically, the disclosure relates to an apparatus, a method and a system for managing NAT (Network Address Translation) policies for peer-to-peer communication in a wireless communication system (or a mobile communication system).

5G mobile communication technologies define broad frequency bands such that high transmission rates and new services are possible, and can be implemented not only in “Sub 6GHz” bands such as 3.5GHz, but also in “Above 6GHz” bands referred to as mmWave including 28GHz and 39GHz. In addition, it has been considered to implement 6G mobile communication technologies (referred to as Beyond 5G systems) in terahertz (THz) bands (for example, 95GHz to 3THz bands) in order to accomplish transmission rates fifty times faster than 5G mobile communication technologies and ultra-low latencies one-tenth of 5G mobile communication technologies.

At the beginning of the development of 5G mobile communication technologies, in order to support services and to satisfy performance requirements in connection with enhanced Mobile BroadBand (eMBB), Ultra Reliable Low Latency Communications (URLLC), and massive Machine-Type Communications (mMTC), there has been ongoing standardization regarding beamforming and massive MIMO for mitigating radio-wave path loss and increasing radio-wave transmission distances in mmWave, supporting numerologies (for example, operating multiple subcarrier spacings) for efficiently utilizing mmWave resources and dynamic operation of slot formats, initial access technologies for supporting multi-beam transmission and broadbands, definition and operation of BWP (BandWidth Part), new channel coding methods such as a LDPC (Low Density Parity Check) code for large amount of data transmission and a polar code for highly reliable transmission of control information, L2 pre-processing, and network slicing for providing a dedicated network specialized to a specific service.

Currently, there are ongoing discussions regarding improvement and performance enhancement of initial 5G mobile communication technologies in view of services to be supported by 5G mobile communication technologies, and there has been physical layer standardization regarding technologies such as V2X (Vehicle-to-everything) for aiding driving determination by autonomous vehicles based on information regarding positions and states of vehicles transmitted by the vehicles and for enhancing user convenience, NR-U (New Radio Unlicensed) aimed at system operations conforming to various regulation-related requirements in unlicensed bands, NR UE Power Saving, Non-Terrestrial Network (NTN) which is UE-satellite direct communication for providing coverage in an area in which communication with terrestrial networks is unavailable, and positioning.

Moreover, there has been ongoing standardization in air interface architecture/protocol regarding technologies such as Industrial Internet of Things (IIoT) for supporting new services through interworking and convergence with other industries, IAB (Integrated Access and Backhaul) for providing a node for network service area expansion by supporting a wireless backhaul link and an access link in an integrated manner, mobility enhancement including conditional handover and DAPS (Dual Active Protocol Stack) handover, and two-step random access for simplifying random access procedures (2-step RACH for NR). There also has been ongoing standardization in system architecture/service regarding a 5G baseline architecture (for example, service based architecture or service based interface) for combining Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) for receiving services based on UE positions.

As 5G mobile communication systems are commercialized, connected devices that have been exponentially increasing will be connected to communication networks, and it is accordingly expected that enhanced functions and performances of 5G mobile communication systems and integrated operations of connected devices will be necessary. To this end, new research is scheduled in connection with eXtended Reality (XR) for efficiently supporting AR (Augmented Reality), VR (Virtual Reality), MR (Mixed Reality) and the like, 5G performance improvement and complexity reduction by utilizing Artificial Intelligence (AI) and Machine Learning (ML), AI service support, metaverse service support, and drone communication.

Furthermore, such development of 5G mobile communication systems will serve as a basis for developing not only new waveforms for providing coverage in terahertz bands of 6G mobile communication technologies, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), array antennas and large-scale antennas, metamaterial-based lenses and antennas for improving coverage of terahertz band signals, high-dimensional space multiplexing technology using OAM (Orbital Angular Momentum), and RIS (Reconfigurable Intelligent Surface), but also full-duplex technology for increasing frequency efficiency of 6G mobile communication technologies and improving system networks, AI-based communication technology for implementing system optimization by utilizing satellites and AI (Artificial Intelligence) from the design stage and internalizing end-to-end AI support functions, and next-generation distributed computing technology for implementing services at levels of complexity exceeding the limit of UE operation capability by utilizing ultra-high-performance communication and computing resources.

Recently, there are needs to enhance NAT policy handling procedure with regard to development of wireless communication system.

Aspects of the disclosure are to address at least the above-mentioned problems and/or disadvantages and to provide at least the advantages described below. Accordingly, an aspect of the disclosure is to provide a communication method and system for converging a fifth generation (5G) communication system for supporting higher data rates beyond a fourth generation (4G).

In accordance with an aspect of the disclosure, a method performed by a user plane function (UPF) entity in a wireless communication system, the method comprising: receiving, from a control plane network entity, a request for a network address translation (NAT) policy, wherein the request includes information on at least one parameter associated with the NAT policy; and updating the NAT policy based on the at least one parameter, wherein at least one internal address is translated to a same external address irrespective of a destination, according to the updated NAT policy.

In accordance with an aspect of the disclosure, a user plane function (UPF) entity comprises: a transceiver; and a controller coupled with the transceiver and configured to: receive, from a control plane network entity, a request for a network address translation (NAT) policy, wherein the request includes information on at least one parameter associated with the NAT policy, and update the NAT policy based on the at least one parameter, wherein at least one internal address is translated to a same external address irrespective of a destination, according to the updated NAT policy.

According to various embodiments of the disclosure, NAT policy handling procedures can be efficiently enhanced.

The above and other aspects, features, and advantages of certain embodiments of the disclosure will be more apparent from the following description taken in conjunction with the accompanying drawings, in which:

Figure 1 illustrates an example of different types of NAT and related behaviour in accordance with an embodiment of the disclosure;

Figure 2 illustrates an example procedure of creating direct media channel path using session traversal utilities for NAT (STUN) server in accordance with an embodiment of the disclosure;

Figure 3 illustrates an example procedure of creating media channel via intermediate relay using traversal using relay around NAT (TURN) server in accordance with an embodiment of the disclosure;

Figure 4 illustrates an example procedure of establishing data channel in accordance with an embodiment of the disclosure;

Figure 5 illustrates another example procedure of establishing data channel in accordance with another embodiment of the disclosure;

Figure 6 illustrates another example procedure of establishing data channel in accordance with another embodiment of the disclosure;

Figure 7 illustrates another example procedure of establishing data channel in accordance with another embodiment of the disclosure;

Figure 8 illustrates a block diagram of a user equipment (UE) according to an embodiment of the disclosure.

Figure 9 illustrates a block diagram of a network entity according to an embodiment of the disclosure.

Throughout the drawings, like reference numerals will be understood to refer to like parts, components, and structures.

The following description with reference to the accompanying drawings is provided to assist in a comprehensive understanding of various embodiments of the disclosure as defined by the claims and their equivalents. It includes various specific details to assist in that understanding but these are to be regarded as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the various embodiments described herein can be made without departing from the scope and spirit of the disclosure. In addition, descriptions of well-known functions and constructions may be omitted for clarity and conciseness.

The terms and words used in the following description and claims are not limited to the bibliographical meanings, but, are merely used by the inventor to enable a clear and consistent understanding of the disclosure. Accordingly, it should be apparent to those skilled in the art that the following description of various embodiments of the disclosure is provided for illustration purpose only and not for the purpose of limiting the disclosure as defined by the appended claims and their equivalents.

It is to be understood that the singular forms “a,” “an,” and “the” include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to “a component surface” includes reference to one or more of such surfaces.

By the term “substantially” it is meant that the recited characteristic, parameter, or value need not be achieved exactly, but that deviations or variations, including for example, tolerances, measurement error, measurement accuracy limitations and other factors known to those of skill in the art, may occur in amounts that do not preclude the effect the characteristic was intended to provide.

It is known to those skilled in the art that blocks of a flowchart (or sequence diagram) and a combination of flowcharts may be represented and executed by computer program instructions. These computer program instructions may be loaded on a processor of a general purpose computer, special purpose computer, or programmable data processing equipment. When the loaded program instructions are executed by the processor, they create a means for carrying out functions described in the flowchart. Because the computer program instructions may be stored in a computer readable memory that is usable in a specialized computer or a programmable data processing equipment, it is also possible to create articles of manufacture that carry out functions described in the flowchart. Because the computer program instructions may be loaded on a computer or a programmable data processing equipment, when executed as processes, they may carry out operations of functions described in the flowchart.

A block of a flowchart may correspond to a module, a segment, or a code containing one or more executable instructions implementing one or more logical functions, or may correspond to a part thereof. In some cases, functions described by blocks may be executed in an order different from the listed order. For example, two blocks listed in sequence may be executed at the same time or executed in reverse order.

In this description, the words “unit”, “module” or the like may refer to a software component or hardware component, such as, for example, a field-programmable gate array (FPGA) or an application-specific integrated circuit (ASIC) capable of carrying out a function or an operation. However, a “unit”, or the like, is not limited to hardware or software. A unit, or the like, may be configured so as to reside in an addressable storage medium or to drive one or more processors. Units, or the like, may refer to software components, object-oriented software components, class components, task components, processes, functions, attributes, procedures, subroutines, program code segments, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays or variables. A function provided by a component and unit may be a combination of smaller components and units, and may be combined with others to compose larger components and units. Components and units may be configured to drive a device or one or more processors in a secure multimedia card.

Prior to the detailed description, terms or definitions necessary to understand the disclosure are described. However, these terms should be construed in a non-limiting way.

The "base station (BS)" is an entity communicating with a user equipment (UE) and may be referred to as BS, base transceiver station (BTS), node B (NB), evolved NB (eNB), access point (AP), 5G NB (5GNB), or gNB.

The "UE" is an entity communicating with a BS and may be referred to as UE, device, mobile station (MS), mobile equipment (ME), or terminal.

NAT will be described in detail. Network Address Translation (NAT) is a technique of mapping private addresses inside a local network to a public internet protocol (IP) address before transferring the information to the internet.

An internal (private) address (e.g., IP address and optionally port) is mapped to an external (public) address (e.g., IP address and optionally port) and that mapping is stored by the NAT.

For a packet going from internal network to outside, its source address (e.g., IP address and optionally port), which is private address, is modified according to the stored mapping.

For a packet going from external network to inside, its destination address (e.g., IP address and optionally port) which is a public address, is modified according to the stored mapping.

Hereinafter, types of NAT will be described in detail.

1. Cone NAT: All request from the Same IP address and port are mapped to the same external IP address and port.

1-a. Full-cone: In addition to CONE NAT functionality, any external host can send a packet to the internal host.

1-b. Restricted Cone: In addition to CONE NAT functionality, an external host can send a packet to the internal host only if the internal host previously sent the packet to the same IP address.

1-c. Port restricted cone: In addition to CONE NAT functionality, an external host can send a packet to internal host only if the internal host had previously sent a packet to same IP address and port of the external host.

2. Symmetric NAT: in this type of NAT, destination IP address and port are also used in the mapping, that is combination of internal IP+port and destination IP+port is mapped to a single unique external source IP+port. If the same host sends a packet with same source address and port but to a different destination, a different mapping is used.

Figure 1 illustrates an example of different types of NAT and related behaviour in accordance with an embodiment of the disclosure. Table in Figure 1 shows different types of NAT and their behavior.

ICE (Interactive Connectivity Establishment): It is a protocol or a technique that allows peers to establish media connectivity between them. The purpose is to let the two peers communicate as directly as possible, but existence of NATs and/or firewalls make it difficult.

ICE candidates: They are potential address/port to receive media packets. Each peer finds its own ICE candidates and communicate it to the peer to which it wants to establish a media channel to). ICE candidates may be the peer’s local IP address/port combination, its public address/port or an address/port located at some relay-server (that relays the media packets to the peer).

ICE protocol involves two peers that want to create a media channel between them (media channel may be created for a particular application e.g. video call etc.). They exchange any signaling via an intermediate signaling server (basically owned by the application entity for which the peers want to create a media channel).

Figure 2 illustrates an example procedure of creating direct media channel path using session traversal utilities for NAT (STUN) server in accordance with an embodiment of the disclosure.

The above-described ICE involves two basic protocols; namely STUN and TURN.

STUN stands for Session Traversal Utility for NAT, and STUN allows a client to know about its Public address. Since mostly clients are behind a NAT, so the local IP address which is known to them and provided via DHCP is different from the one that is visible to the public internet.

A procedure of establishing of Media channel when STUN server is deployed can be described as follows, with respect to the Figure 2.

1. Both Client (UE) and remote peer contacts STUN server (they each might contact different STUN servers) to obtain their public address information (IP address + port).

2. Client and Remote peer exchanges this address via a Signaling server (which is basically controlled by the application server for which the peers need to create a media connection (e.g. video call application etc.).

3. NAT hole punching: We assume that the two clients are behind different NATs. Let’s call First client is behind NAT-1, and second client is behind NAT-2. We assume that both the NATs are port restricted Cone NATs. That is same internal address is translated to same external address even when the destination is different.

3-a. Firstly, Client 1 sends a request to the public address of client 2. NAT-1 changes the source address of the packet (to the same public address that client 1 received from the STUN server) and NAT-1 will make an entry to allow incoming packets from Client 2 (with the destination being that of Client 1). Since, client 2 hasn’t sent a packet to Client 1, NAT-2 won’t allow the packet to reach to Client 2.

3-b. Now assume Client 2 sends message to Client 1. NAT-2 changes the source address of the packet (to the same public address that Client 2 received from the STUN server) and NAT-2 will make an entry to allow incoming packets from Client 1 (with the destination being that of Client 2). Now since the NAT-1 receives this packet with source being Client-2’s public address, and destination being Client-1’s public address, NAT-1 allows this packet and it finally reaches to Client-1.

3-c. Eventually. Client-1’s packet will also be allowed by NAT-2 and both peers will be able to communicate directly with each other.

Figure 3 illustrates an example procedure of creating media channel via intermediate relay using traversal using relay around NAT (TURN) server in accordance with an embodiment of the disclosure.

For the case of symmetric NAT, the external address is changed if the destination is changed. So the STUN protocol does not work in case Symmetric NATs are used.

Let’s consider the previous procedure again and assume that NAT-1 is a symmetric NAT. Detailed procedure establishing of Media channel for this case is described as follows, with respect to the Figure 3.

1. Both Client (UE) and remote peer contacts STUN server (they each might contact different STUN servers) to obtain their public address information (IP address + port). For Client-1 Assume this information to be (IP-C1-a;Port-C1-a).

3. NAT hole punching:

3-a. Firstly, Client 1 sends a request to the public address of client 2. NAT-1 changes the source address of the packet, but now since the destination is different (In step 1, it was STUN server, and in this step destination is Client-2), NAT will map it to a new public address, say (IP-C1-b,Port-C1-b) and NAT-1 will make an entry to allow incoming packets from Client 2 (with the destination being (IP-C1-b,Port-C1-b) ). Since, client 2 hasn’t sent a packet to Client 1, NAT-2 won’t allow the packet to reach to Client 2.

3-b. Now Client 2 sends message to Client 1 (IP-C1-a,Port-C1-a). NAT-2 changes the source address of the packet (to the same public address that Client 2 received from the STUN server) and NAT-2 will make an entry to allow incoming packets from Client 1(IP-C1-a,Port-C1-a) (with the destination being that of Client 2).

3-c. Now since NAT-1 will only allow the packet from client-2 if the destination is (IP-C1-b,Port-C1-b), and NAT-2 will only allow the packets to Client-2 if the Source is (IP-C1-a,Port-C1-a), the 2-NATs will block the packets sent from each client and the clients won’t able to establish direct communication between them.

Since direct media connection cannot be established when Symmetric NATs are deployed, TURN is used to mitigate this problem.

TURN stands for Traversal Using Relays around NAT, and TURN allows a client to sends and receive data through an intermediate server which is located in the public.

As shown in figure 2, the client-1 uses a TURN server which is located in the public Internet, and Client-2 established media channel via the TURN server, which relays the packets to the Client-1.

However, following disadvantages of using TURN server should be considered.

1. It is required throughout the whole timespan of the session, unlike STUN, which is needed only during the initial connection establishment.

2. Since the entire communication relays through the server, far more server bandwidth s required for TURN as compared to TURN. This leads to higher infrastructure cost for the application server entity.

3. Relayed path is longer than the direct communication path as established in the STUN, which leads to more latency when TURN is used.

According to the above descriptions, embodiments to enhance NAT policies with respect to the disclosure will be described in detail.

As discussed before, the TURN server increases cost and complexity of the architecture. On the other hand, Symmetric NAT has its advantages in its own way (e.g. security/easier implementation etc.).

So, we need a way to selectively relax the Symmetric NAT conditions for the IP addresses which are used to create media channel for ICE.

For the purpose of descriptions, following assumptions are taken:

a. Client UE (which is served by the operator) is behind a Symmetric NAT.

b. Remote peer is behind a cone-NAT.

c. Client UE and remote UE are not behind the same NAT (that is their local candidates can’t be used to establish media channel).

d. Assume that the STUN and TURN functionality are implemented on the same server (now on only referred to as TURN server).

d-a. Assume that address (2-tuple) of TURN server is (ST server IP : ST server port).

Figure 4 illustrates an example procedure of establishing data channel in accordance with an embodiment of the disclosure.

This is a legacy procedure which happens, without the use of solution as described later in this embodiment.

1. Client (UE) starts gathering ICE candidates.

In detail, client (UE) connects to the TURN server to obtain its ICE candidates. Remote peer also does this on its own end. They contact their respective STUN/TURN servers to obtain server reflexive address and the relay address.

Once they have received their candidates, they are ready to exchange these candidates (which are basically potential target addresses (and ports) for media exchange).

Note that while connecting to the TURN server, client uses a particular IP/port combination.

When that packet passes through the NAT, the source address gets translated and the mapping gets stored in the NAT table.

As for example case, assume in Table 1, the second entry gets added after the UE sends packet to the TURN server. The meaning of the second entry is when the private source is (UE-IP-internal-1: port-internal-1) and destination is (ST-server-IP: ST-server-port), the source will be translated to (UE-IP-external-1: port-external-1).

2. UE and the remote peer starts exchanging the ICE candidates.

In detail, after gathering its ICE candidates, UE contacts the remote peer via the signaling server and exchanges its ICE candidates.

In an example, UE sends its server-reflexive address (UE-IP-external-1: port-external-1) to the remote peer while the remote peer sends (Remote-peer-IP: Remote-peer-port) as it's server reflexive address to the UE.

3. Media channel establishment between UE and the remote peer.

In detail, client and remote peer starts checking suitable candidates for the peer-to-peer connection.

ICE connection establishment:

a. Now while performing media channel checks, UE will send packets to remote peer (using the same internal IP address/port which it used to connect to the TURN server).

b. While performing port translation for it, NAT will perform translation taking into account the destination address/port as well (since it is a Symmetric NAT).

c. Hence the external address to which the source address is translated will be different, and the NAT mapping table would look something like in the table 1. With the third entry in the table added as result of the UE sending packets to remote peer.

Now since the external address/port combination used when trying to establish the media channel is different from the one which was notified to the remote peer, direct media channel won't be able to establish between the two peers and would require the intermediate relay-server (namely TURN) to relay the media data between the peers.

[Embodiment 1]

Figure 5 illustrates another example procedure of establishing data channel in accordance with another embodiment of the disclosure.

According to the embodiment 1, signaling server requests the NAT services by informing the address of the remote peer ICE candidate to the user.

Embodiment 1 relies on the signaling server to request the 5GC for modification of NAT policy for the UE's address, so that the same internal address is not translated to different public address when UE tries to connect to the remote peer. That is, NAT will modify its behavior for the address (as requested by the signaling server) so as the translated public address visible to the TURN server and to the Remote peer remains same. Thus, both the peers will be able to establish direct channel for media.

Steps of detailed procedure for the embodiment 1 is described in Figure 5.

1. UE connect to the TURN server to obtain its ICE candidates.

Client (UE) connects to the TURN server to obtain its ICE candidates. Remote peer also does this on its own end. They contact their respective STUN/TURN servers to obtain server reflexive address and the relay address.

Once they have received their candidates they are ready to exchange these candidates (which are basically potential target addresses (and ports) for media exchange).

When that packet passes through the NAT, the source address gets translated and the mapping gets stored in the NAT table. The TURN server then provides this public address (namely the server-reflexive address) back to the client (UE).

As for an example case, assume in Table 3, the second entry gets added after the UE sends packet to the TURN server. The meaning of the second entry is when the private source is (UE-IP-internal-1: port-internal-1) and destination is (ST-server-IP: ST-server-port), the source will be translated to (UE-IP-external-1: port-external-1).

2. UE and the remote peer starts exchanging the ICE candidates.

After gathering its ICE candidates UE contacts the remote peer via the signaling server and exchanges it's ICE candidates.

In an example, UE sends its server-reflexive address (UE-IP-external-1 : port-external-1) to the remote peer while the remote peer sends (Remote-peer-IP : Remote-peer-port) as it's server reflexive address to the UE.

3. Nnef_NATUpdateService request

3-a. The signaling server (or more particularly the application function (AF) managed by the Signaling server) requests for user plane function (UPF) services to modify the NAT behavior according to the provided parameters.

3-b. The parameters may include:

3-b-i. UE external address information

3-b-i-1. UE external IP address

3-b-i-2. UE external port

3-b-ii. Protocol type

3-b-iii. Remote peer address information

3-b-iii-1. Remote peer IP address

3-b-iii-2. Remote peer port

3-b-iv. Type of NAT behavior requested (one of):

3-b-iv-1. Add new entry to NAT table

3-b-iv-2. Make mapping FULL-CONE

3-b-iv-3. Make mapping Restricted Cone

The protocol type (e.g., Layer-4 protocol used, i.e. either user datagram protocol (UDP)/transmission control protocol(TCP)/some other) is essential to be specified since most NATs have separate mappings according to the protocol used.

Type of NAT behavior requested is essential to control what type of NAT behavior is requested for the UE internal IP address. For example, using FULL-CONE behavior will enable to create a direct media channel even when the remote peer is also behind a Symmetric NAT, but may be less secure.

4. Finding the corresponding UPF

Network exposure Function (NEF) uses the UE external IP address and port provided to find the UPF which is serving the particular UE.

5. Nupf_NATPolicyUpdate request

After discovering the UPF which is serving the particular UE session, NEF sends the request to the particular UPF, requesting service from the UPF to modify the NAT behavior according to the parameters provided in the request.

The parameters in the request may include:

5-a. UE external address information

5-a-i. UE external IP address

5-a-ii. UE external port

5-b. Protocol type

5-c. Remote peer address information

5-c-i. Remote peer IP address

5-c-ii. Remote peer port

5-d. Type of NAT behavior requested (one of):

5-d-i. Add new entry to NAT table

5-d-ii. Make mapping FULL-CONE

5-d-iii. Make mapping Restricted Cone

6. UPF modifies the NAT behavior

UPF is provided with Remote peer address, remote peer port, UE external address, UE external port.

UPF first finds (with the help of its NAT functionality) the corresponding internal address for the provided UE external address, UE external port information.

Then NAT mapping table is updated by adding an additional mapping corresponding to (UE internal IP, UE internal port, Remote peer address, Remote peer port) to UE external IP, UE external port.

As in an example, UPF is provided, via Nupf_ NATPolicyUpdate, the target UE's external address info: (UE-IP-external-1: port-external-1) and the remote peer address info: (Remote-peer-IP: Remote-peer-port).

NAT then checks its NAT table to find the internal (private) address corresponding to the public address (UE-IP-external-1: port-external-1) to be (UE-IP-internal-1: port-internal-1).

Based on the request received via Nupf_ NATPolicyUpdate, UPF modifies the NAT policy to include additional an additional mapping namely "If source is <UE-IP-internal-1: port-internal-1>, and the destination is <Remote-peer-IP: Remote-peer-port>, then the source would be translated to <UE-IP-external-1: port-external-1>".

This is depicted via 3rd entry of NAT table in Table 4.

For the same UE internal IP, port, even though the external destinations are different (row 2 and row 3 of the above table), the source is translated to same external address (which is not the general Symmetric NAT behavior as was in Table 2)

7. Media channel establishment between UE and the remote peer

When UE tries to create peer-to-peer connection with the remote peer using the exchanged ICE candidates, UE will use the same IP address, port pair to establish media connectivity with the remote-peer, the one it used to connect to the TURN server (that is the one it also exchanged with the remote peer during signaling information exchange in Step. 2).

Now as the NAT behavior was modified in the Step 6, the translated external address by the NAT will be same as for the one as seen by the TURN server (destination address while exchanging packets for establishing media channels is that of remote peer, while initially for the stored mapping it was of the TURN server, since UE contacted TURN server to obtain ICE candidates).

Since the UE external address is no longer different as in the case of normal Symmetric NAT, the UE and the remote peer will be able to establish a direct media channel without the use of intermediate relay.

Since the external address is the same one as was used for connecting the TURN server (and that was also conveyed to the remote peer during signaling exchange in Step.6), the direct peer-to-peer media connection can be established between the UE and the remote peer, without the need of intermediate relay.

[Embodiment 2]

Figure 6 illustrates another example procedure of establishing data channel in accordance with another embodiment of the disclosure.

According to an embodiment 2, TURN server request UPF services only when the UE connects to the TURN server.

It is assumed that the TURN server and STUN server are collocated /deployed together.

This is an alternate to embodiment 1, where the TURN server itself, request the 5GC for modification of NAT policies for the UE address. Basically, when the UE client, connects to TURN server for knowing it's ICE candidates, the TURN server request NAT policy modification for the UE's address, so that NAT does not use different public-address mappings for the same internal address of that particular UE.

Steps of the procedure of the embodiment 2 is depicted in Figure 6.

1. UE connects to the TURN server and obtains it's ICE candidates

Client (UE) connects to the TURN server to obtain it's ICE candidates. Remote peer also does this on its own end. They contact their respective STUN/TURN servers to obtain server reflexive address and the relay address.

As for an example case, assume in table 5, the second entry gets added after the UE sends packet to the TURN server. The meaning of the second entry is when the private source is (UE-IP-internal-1: port-internal-1) and destination (i.e. TURN server) is (ST-server-IP: ST-server-port), the source will be translated to (UE-IP-external-1: port-external-1).

2. Nnef_NATService_request

It is assumed that the TURN server has service relationship with the Network operator. The TURN server (or more specifically an AF managed by the TURN server, decides to use operator NAT services for the UE that requested service from the TURN server) intends that the media traffic for the requesting UE is established via direct peer-to-peer connection instead of being relayed via the TURN server.

TURN server requests for UPF services via the NEF, it provides parameters including:

2-a. Target: UE external address information

2-a-i. UE external IP address

2-a-ii. UE external port

2-b. Protocol type

2-c. Server address information (address of the TURN server)

2-c-i. server IP address

2-c-ii. server port

2-d. Type of NAT behavior requested (one of):

2-d-i. Make mapping FULL-CONE

2-d-ii. Make mapping Restricted Cone

3. Finding/discovering the corresponding UPF

Based on the external IP address and port pair provided by the AF (in step 2), NEF finds the UPF serving the particular session, i.e. the UPF serving the PDU Session for which public IP address/port is the one provided in the AF request.

4. Nupf_NATPolicyUpdate_request

NEF sends the request to the discovered UPF, so as to update it's NAT policy and corresponding rules for the requested parameters.

The parameters provided include one or more of:

4-a. UE external address information

4-a-i. UE external IP address

4-a-ii. UE external port

4-b. Protocol type

4-c. Server address information (address of the TURN server)

4-c-i. server IP address

4-c-ii. server port

4-d. Type of NAT behavior requested (one of):

4-d-i. Make mapping FULL-CONE

4-d-ii. Make mapping Restricted Cone

5. UPF modifies its NAT behavior

After receiving the Nupf_NATPolicyUpdate_request, UPF first checks the NAT table to find the internal (private) address/port information corresponding to the provided external address information.

It finds the corresponding entry in its table for the external address/port pair and determine the corresponding internal (private) address/port.

Based on the request received in Step.4, UPF will modify its NAT policy so that this determined internal (private) address/port is translated to the same external (private) address/port irrespective of the destination; i.e. Symmetric NAT conditions are lifted for this particular internal address and it behaves as if it were a cone-NAT.

As per an example, the UPF modifies NAT rule to be "If source is <UE-IP-internal-1: port-internal-1> and destination is <any>, translate source to <UE-IP-external-1: port-external-1>".

This means that any packet with the source (determined based on the external address provided in the Step.4) NAT will translate it to the same external (public) address irrespective of what the destination may be.

Before modifying the NAT policy, NAT would have translated the same source address differently if the destination address was different.

6. ICE candidates exchange through signaling server

After gathering it's ICE candidates UE informs it's ICE candidates to the remote peer via the signaling server.

According to the above example, UE will send the candidate (UE-IP-external-1: port-external-1) to the remote peer as a possible candidate to establish media channel. Remote peer will further send it's own server-reflexive address (Remote-peer-IP: Remote-peer-port).

7. Media channel establishment between UE and the remote peer

When UE tries to create peer-to-peer connection with the remote peer using the exchanged ICE candidates, UE will use the same IP address, port pair to establish media connectivity with the remote-peer, the one it used to connect to the TURN server.

As the NAT behavior was modified for the UE' IP address in the Step 5, NAT will use the same external IP address/port for translating the source even though the destination address is different in this case (i.e. destination address while exchanging packets for establishing media channels is that of remote peer, while initially before Step 4, for the stored NAT mapping it was of the TURN server, since UE contacted TURN server to obtain ICE candidates).

Since the UE external address is no longer different as was in the case of normal Symmetric NAT, the UE and the remote peer will be able to establish a direct media channel without the use of intermediate relay (like a TURN server).

Differences of embodiment 2 from embodiment 1 can be described as following:

1. Intermediate Signaling server need not scoop into any signaling information exchanged between the peers.

1-a. In the embodiment 1, the intermediate signaling server need to know the ICE candidates that are exchanged between the peers in order to send the address information to the network operator (or the NEF), hence the signaling between the 2 peers can't be end-to-end encrypted.

2. In the embodiment 1, the NAT mapping is duplicated only for two 4-tuples, while in the embodiment 2, the NAT mapping is duplicated for any outgoing address for the given UE internal address.

2-a. Increased NAT complexity: in the embodiment 1, NAT can still act as a normal Symmetric NAT, with just an additional mapping provided to its NAT mapping table, here the NAT would further have to use different behavior for the particular requested address (cone-behavior), and Symmetric NAT behavior for all other 4-tuples.

[Embodiment 3]

Figure 7 illustrates another example procedure of establishing data channel in accordance with another embodiment of the disclosure.

TURN server address is provided to the UPF beforehand (that is configured in the UPF during service relationship).

Basically, UPF is configured with a new policy to change its NAT behavior if the destination is that of the TURN server.

If a UE tries to connect to the TURN server for getting the ICE candidates; UPF will treat this mapping as non-symmetric for the internal IP + port combination used. That is, whenever the UE uses the same internal address/port combination to send packet to some other destination, NAT will use the same mapping, and will translate the source to the same public address that it translated to when UE connected to the TURN server.

Parameters TURN server (AF controlled by the TURN server) sends to the UPF (via NEF) are:

a. Target: UE ID(s), IP address range of UEs, All

b. Protocol type

c. Server address information (address of the TURN server)

c-i. server IP address

c-ii. server port

d. Type of NAT behavior requested (one of):

d-i. Make mapping FULL-CONE

d-ii. Make mapping Restricted Cone

Step procedures (as depicted in Figure 7) are as follows:

1. Nnef_NATUpdateService request

An AF controlled by the 3rd party (Organization managing TURN server here), request the NEF for UPF's NAT Update service, so that the corresponding UPF's change or modify their NAT behavior.

It includes but not limited to the following parameters in the request:

2-a. Target: UE ID(s), IP address range of UEs, All

2-b. Protocol type

2-c. Server address information (address of the TURN server)

2-c-i. server IP address

2-c-ii. server port

2-d. Type of NAT behavior requested (one of):

2-d-i. Make mapping FULL-CONE

2-d-ii. Make mapping Restricted Cone

2. NEF discovers the UPF(s) to update the configuration

Upon receiving the request in Step 1, NEF finds the particular UPF(s), based on the criteria's such as UPF's serving NAT functionality (i.e. type of NAT functionality UPF supports, or if it supports).

This may involve either all (implying all UPFs to be configured with this information) or only few particular UPFs to be configured.

3. Nupf_NATPolicyUpdate_request

After discovering the suitable UPFs. NEF (or a network control entity) sends the corresponding request to the UPF.

The parameters in the request may include:

3-a. Target: UE ID(s), IP address range of UEs, All

3-b. Protocol type

3-c. Server address information (address of the TURN server)

3-c-i. server IP address

3-c-ii. server port

3-d. Type of NAT behavior requested (one of):

3-d-i. Make mapping FULL-CONE

3-d-ii. Make mapping Restricted Cone

4. UPF updates it's NAT policies

UPF modifies it's NAT policy as per the received service request. It basically checks for any incoming packets that are destined towards the provided server address, if they are NAT will apply the rules of FULL-CONE NAT for those internal addresses. That is even for different destination addresses, those internal addresses (the addresses which sent packets to the TURN server) will be sent

For the target UEs, NAT will check for any incoming packets that have destination as the (Server IP address, Server port). It will translate the source according to its NAT policy and will mark this particular mapping to be destination independent. That the source having the particular internal address is always translated to the same public address regardless of what the destination is (as opposed to the normal Symmetric behavior).

An example policy update is:

If the source X (private) sends a packet to destination A(which is the server address configured), translate X to B and add the following NAT rule: For source X, and destination <any>, translate source to B.

5. UE connects to the TURN server and obtains it's ICE candidates

When sending a packet to the TURN server at the destination, the destination address passes through NAT, to perform port translation from private IP/port to public IP/port for the UE.

Let's assume the UE's internal IP/port be IP X : port: x, and the packet sent by the UE, using this IP/port combination has the destination A (of the TURN server which was provided to the UPF in Step 3).

As the NAT policies were modified in Step 3/Step 4, NAT checks that the destination of the packet is that of the TURN server (the one that was provided to UPF by NEF in Step 2). NAT makes a new policy or rule, so that any incoming packet from this particular internal address/port combination (i.e. IP X: port x) will always be translated to the same public address.

6. UPF checks that the destination IP address used for connecting to the TURN server and modifies it's NAT behaviour for the current UE mapping used.7. ICE candidates exchange with remote peer through signaling channel

UE and the remote peers start performing ICE candidate exchange. They are exchanged through the intermediate signaling server.

8. Media channel establishment between UE and the remote peer

The 2 peers performs check to find the suitable ICE candidates for media exchange

To perform the check, client server sends a packet to peer's reflective address using the same address/port through which it connected to the TURN server.

When the packet reaches the NAT, it checks that the source is same as the one in Step. 4, so the source will be translated to the same public address it was translated in Step. 4.

Now since the external address is the same one as was used for connecting to the TURN server (that was conveyed to the remote peer during signaling exchange in Step. 6), the direct peer-to-peer media connection can be established between the UE and the remote peer, without the need of intermediate relay.

Advantage of this method compared to embodiment 1 and embodiment 2 is, since the UPF is provided parameters to update its configuration beforehand, there would be comparatively lesser load on the external AF (controlled by the signaling server or the TURN server), which would have to request UPF to update NAT polices each time a UE requested the services of the server.

Figure 8 is a block diagram of a UE (or a terminal) according to an embodiment of the disclosure.

Referring to figure 8, a terminal includes a transceiver 810, a controller 820 and a memory 830. The controller 820 may refer to a circuitry, an application-specific integrated circuit (ASIC), or at least one processor. The transceiver 810, the controller 820 and the memory 830 are configured to perform the operations of the UE illustrated in the figures, e.g. figures 1 to 7, or described above. Although the transceiver 810, the controller 820 and the memory 830 are shown as separate entities, they may be realized as a single entity like a single chip. Or, the transceiver 810, the controller 820 and the memory 830 may be electrically connected to or coupled with each other.

The transceiver 810 may transmit and receive signals to and from other network entities, e.g., a base station, a network entity, a network function, or a server. The controller 820 may control the UE to perform functions according to one of the embodiments described above. In an embodiment, the operations of the terminal may be implemented using the memory 830 storing corresponding program codes. Specifically, the terminal may be equipped with the memory 830 to store program codes implementing desired operations. To perform the desired operations, the controller 820 may read and execute the program codes stored in the memory 830 by using a processor or a central processing unit (CPU).

Figure 9 is a block diagram of a network entity according to an embodiment of the disclosure. The network entity described in figure 9 may comprise at least one of a network entity, a network function, a server, or a base station described before in the disclosure.

Referring to figure 9, a base station includes a transceiver 910, a controller 920 and a memory 930. The transceiver 910, the controller 920 and the memory 930 are configured to perform the operations of the network entity (or the network function, the server, the base station) illustrated in the figures, e.g. figures 1 to 7, or described above. Although the transceiver 910, the controller 920 and the memory shown as separate entities, they may be realized as a single entity like a single chip. The transceiver 910, the controller 920 and the memory 930 may be electrically connected to or coupled with each other.

The transceiver 910 may transmit and receive signals to and from other network entities, e.g., a terminal, a UE, a base station, a network function, or a server. The controller 920 may control the base station to perform functions according to one of the embodiments described above. The controller 920 may refer to a circuitry, an ASIC, or at least one processor. In an embodiment, the operations of the base station may be implemented using the memory 930 storing corresponding program codes. Specifically, the base station may be equipped with the memory 930 to store program codes implementing desired operations. To perform the desired operations, the controller 920 may read and execute the program codes stored in the memory 930 by using a processor or a CPU.

While the disclosure has been shown and described with reference to various embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the disclosure as defined by the appended claims and their equivalents.

As described above, embodiments disclosed in the specification and drawings are merely used to present specific examples to easily explain the contents of the disclosure and to help understanding, but are not intended to limit the scope of the disclosure. Accordingly, the scope of the disclosure should be analyzed to include all changes or modifications derived based on the technical concept of the disclosure in addition to the embodiments disclosed herein.

Claims

A method performed by a user plane function (UPF) entity in a wireless communication system, the method comprising:

receiving, from a control plane network entity, a request for a network address translation (NAT) policy, wherein the request includes information on at least one parameter associated with the NAT policy; and

updating the NAT policy based on the at least one parameter,

wherein at least one internal address is translated to a same external address irrespective of a destination, according to the updated NAT policy.
The method of claim 1, wherein the at least one parameter includes a user equipment (UE) external internet protocol (IP) address, a UE external port, a protocol type, a server IP address, a server port, a full cone type NAT behaviour, or a restricted cone type NAT behaviour.
The method of claim 1, wherein the updating comprises modifying a corresponding entry in a NAT table which is stored in the UPF entity, and

wherein a NAT behaviour according to the NAT policy is updated to become a cone NAT.
The method of claim 1, wherein the request includes an Nupf_NATPolicyUpdate_request.
The method of claim 1, wherein the request is received from an application server via a network exposure function (NEF) entity.
The method of claim 1, wherein an interactive connectivity establishment (ICE) candidate of a first UE is delivered to a signaling server,

wherein a media channel is established between the first UE and a second UE which is a remote peer for the first UE, and

wherein the request for the NAT policy is based on a connection from the first UE to the TURN server for obtaining the ICE candidate.
The method of claim 5, wherein the UPF entity is discovered by the NEF entity based on the at least one parameter included in the request or based on a serving NAT functionality of UPF entity.
A user plane function (UPF) entity in a wireless communication system, the UPF entity comprising:

a transceiver; and

a controller coupled with the transceiver and configured to:

receive, from a control plane network entity, a request for a network address translation (NAT) policy, wherein the request includes information on at least one parameter associated with the NAT policy, and

update the NAT policy based on the at least one parameter,

wherein at least one internal address is translated to a same external address irrespective of a destination, according to the updated NAT policy.
The UPF entity of claim 8, wherein the at least one parameter includes a user equipment (UE) external internet protocol (IP) address, a UE external port, a protocol type, a server IP address, a server port, a full cone type NAT behaviour, or a restricted cone type NAT behaviour.
The UPF entity of claim 8, wherein the controller is further configured to update the NAT policy by modifying a corresponding entry in a NAT table which is stored in the UPF entity.
The UPF entity of claim 8, wherein a NAT behaviour according to the NAT policy is updated to become a cone NAT.
The UPF entity of claim 8, wherein the request includes an Nupf_NATPolicyUpdate_request.
The UPF entity of claim 8, wherein the request is received from an application server via a network exposure function (NEF) entity.
The UPF entity of claim 13, wherein an interactive connectivity establishment (ICE) candidate of a first UE is delivered to a signaling server,

wherein a media channel is established between the first UE and a second UE which is a remote peer for the first UE, and

wherein the request for the NAT policy is based on a connection from the first UE to the TURN server for obtaining the ICE candidate.
The UPF entity of claim 13, wherein the UPF entity is discovered by the NEF entity based on the at least one parameter included in the request or based on a serving NAT functionality of UPF entity.