Message Flow

• The id (16 bits) field stores the ID used to identify the specific NAT Controller. This field is the primary key of the table.

• The ip_address (64 bits) field stores the destination IP address used in the secure connection between NAT Controller and MME.

• The tcp_src_port (16 bits) field stores the source TCP port used in the secure connection be-tween NAT Controller and MME.

• The tcp_dest_port (16 bits) field stores the destination TCP port used in the secure connection between NAT Controller and MME.

• The state (4 bits) field stores the current state of life of the NAT Controller. Current valid values for this field are Active and Inactive. Inactive is used when the NAT Controller is current unused due to failure or maintenance.

The protocols and procedures to add and remove entries from the NAT Controller’s Ingress and Egress NAT Infotables are not in the scope of this document.

3.1.4 Message Flow

Having already introduced the signaling messages required to deploy IP address continuity and traffic redirection in the operator’s transport network, Figure 3.2 shows the message flows needed to setup a new downlink path towards the UE’s current S-/P-GW (target S-/P-GW) in the operator’s transport network.

Figure 3.2: Message flow to establish a new downlink path upon reception of a Modify Bearer Response message during handover with S-/P-GW relocation procedure

0. This step is the same as step 5 in Section 2.2.1 and step 17 in Section 2.2.2.

1. The MME creates a Make Path message (flag field sets to either 01, 10 or 11 value) setting as the current_address field the IP address extracted from the Modify Bearer Response message received from the target S-/P-GW. By looking in the UE Context of the UE in object, the MME can retrieve the IP address belonging to flow(s) kept active by the UE after handover. This address is set as the previous_address field in the Make Path message. If more than one active IP addresses are found in the UE Context, the MME duplicates the Make Path message created so far and set the previous_address field accordingly. Each message is then encapsulated in a TCP/IP packet using the information retrieved from the NAT Controller Info table and then forwarded to the NAT Controller.

2. When a message is received from the MME the NAT Controller looks at the flag field to discover whether is a Make Path or a Tear Down Path message. In this case a Rule Update message is created by the NAT Controller setting the flag field to either 01, 10 or 11. The previous_address (10.0.0.1) and current_address (10.30.0.1) fields of the Make Path message are copied respec-tively into the identifier_address and locator_address field of the Rule Update message. The current date and wall-clock value are translated into ISO8061 format and set as the timestamp field of the Rule Update message.

For every entry marked as Active in the Ingress NAT Info table, the NAT Controller duplicates the Rule Update message and uses the values of the entry in object to encapsulate the duplicated Rule Updatemessage in a TCP/IP packet. The identifier_address of the message and the id of the active entry in the Ingress NAT Info table composes a tuple which is then inserted in the Signaled Routerstable.

If a longest prefix match is found between the locator_address and the egress_subnet entries of the Egress NAT Info table, the entry where the matching egress_subnet value belong is used to encapsulate the original Rule Update message in a TCP/IP packet. If no match has been found by the longest prefix match calculation: for every entry marked as Active in the Egress NAT

Info table, the NAT Controller duplicates the Rule Update message and uses the values of the entry in object to encapsulate the duplicated Rule Update message in a TCP/IP packet. The identifier_addressof the message and the id of the matching entry (or active entries if no match is found) in the Egress NAT Info table composes a tuple which is then inserted in the Signaled Routerstable. All the packets are then forwarded to the entitled entities.

The case when Rule Update messages are received with a substantial advance at the Ingress DMM routers than at the Egress DMM routers can cause the unfortunate situation where Egress NAT tables have not been updated while downlink data packets of IP flows belonging to the moving UE(s) are being already NATted at the Ingress NAT routers. These downlink data packets will be then delivered to the target S-/P-GW carrying the wrong IP address and they will therefore be dropped.

To avoid the above, Rule Update messages directed to the Ingress NAT routers can be transmitted with a safety delay than the one directed to Egress NAT routers. The value of this safety delay is dependent on the network topology deployment.

Upon reception of a Rule Update the Ingress NAT router will look up its NAT table for an entry whose local_ipmatches the identifier_address contained in the packet payload. If an entry is found and the timestampvalue of the Rule Update packet is higher than the last_edit value of the entry, the entry is withdrawn and the new rule is added to the table setting timestamp as its last_edit value. If an entry is not found than the new rule is added directly setting timestamp as its last_edit value. If an entry is found but its last_edit is higher than timestamp, then no changes will occur to the NAT table.

When an Egress NAT router receives a Rule Update message from the NAT Controller, it will look up its table for an entry whose local_ip matches the locator_address. If an entry is found and the times-tampvalue of the received packet is higher than the entry’s last_edit value, that entry is withdrawn and the new rule is added to the table setting timestamp as its last_edit value. If an entry is not found then the new rule is added directly setting timestamp as its last_edit value. If an entry is found but its last_editis higher than timestamp, the new rule is then dropped. When a new rule is to be added to the NAT table, a longest prefix match calculation is run on the locator_address. The resulting interface will be set as the entry’s output_iface. This can be achieved due to the fact that locator addresses are topologically anchored to the S-/P-GW that allocate them.

Using the example described previously and depicted in Figure 3.1 the Make Path and Rule Update messages respectively are as follows:

Make Path:

10.0.0.1 10.30.0.1 10 Rule Update:

11 10.0.0.1 10.30.0.1 20130821T145429

After receiving and processing the Rule Update messages the Ingress and Egress NAT routers table respectively looks as Table 3.1 and Table 3.2 (defined above).

Figure 3.3 shows the message flows needed to remove the previously established downlink path.

Figure 3.3: Message flow to remove a downlink path upon reception of PDN Disconnection Request from the UE

0. This step is the same as step 1a in Section 2.2.3.

1. The MME creates a Tear Down Path message (flag field sets to 00). Current_address and Previ-ous_address messages are extracted from the default bearer indicated by the PDN Disconnection Request (LBI) message received from the UE and from its UE Context. The Tear Down Path message is then encapsulated in a TCP/IP packet using the information retrieved from the NAT Controller Infotable and then forwarded to the NAT Controller.

2. When a message is received from the MME the NAT Controller looks at the flag field to discover whether is a Make Path or a Tear Down Path message. In this case a Rule Withdraw message is created by the NAT Controller setting the flag field to 00. The previous_address and cur-rent_addressfields of the Make Path message are copied respectively into the identifier_address and locator_address field of the Rule Update message. The current date and wall-clock value are translated into ISO8061 format and set as the timestamp field of the Rule Withdraw message.

A lookup is performed in the Signaled Routers table. For every entry whose identifier_address is equal to the identifier_address set in the Rule Withdraw message, its peer ID value is used to retrieve TCP/IP info from the Ingress NAT Info table. If a match is found and the entry is marked as Active, the NAT Controller duplicates the Rule Withdraw message and uses the values of the entry in object to encapsulate the duplicated Rule Withdraw message in a TCP/IP packet.

If no match has been found in the Ingress NAT Info table the same procedure is repeated for the Egress NAT Infotable. If a match is found and the entry is marked as Active, the NAT Controller duplicates the Rule Withdraw message and uses the values of the entry in object to encapsulate the duplicated Rule Withdraw message in a TCP/IP packet.

Whenever a match is found in the Ingress NAT Info or in the Egress NAT Info table, then the

tuple is removed from the Signaled Routers table. All the packets are then forwarded to the entitled entities.

When receiving a Rule Withdraw the Ingress NAT routers will look up their table for an entry whose local_ipmatches the identifier_address. If an entry is found and timestamp is higher than the entry’s last_edit, that entry is withdrawn from the table. If an entry is not found or timestamp contained in the receive packet is lower than the entry’s last_edit, then no changes will occur to the NAT table.

Upon reception of a Rule Withdraw the Egress NAT router will look up his table for an entry whose local_ipmatches the locator_address. If an entry is found and the timestamp contained in the packet’s payload is higher that the entry’s last_edit value, the rule is withdrawn from the table. If an entry is not found or timestamp is lower than the entry’s last_edit value, then no changes will occur to the NAT table.

Using the example described previously and depicted in Figure 3.1, the Tear Down Path and Rule Withdrawmessages respectively are as follows:

Tear Down Path:

10.0.0.1 10.30.0.1 00 Rule Withdraw:

00 10.0.0.1 10.30.0.1 20130822T160100

After receiving and processing the Rule Withdraw messages the entry previously added in both Ingress and Egress NAT router’s table will be removed.