We saw in a previous video the importance of the TEID, the ID of the endpoint of a tunnel. How do we establish a tunnel and ensure that both endpoints are aware of both TEIDs? How are packets processed once the tunnel has been established? These are the questions we’re going to answer in this video. If we look at initializing a tunnel, the Serving Gateway, for example, will choose a new, unique TEID value: 102. It will send a request to establish a tunnel, saying: “New tunnel with the TEID 102”. The P-Gateway will choose a new TEID value that will be unique for it, in this example: 16,538. The P-Gateway stores the address of the sender, here, the address of the Serving Gateway and also stores the value of the TEID it received. And it creates a link between 16,538 and 102. The P Gateway sends an acknowledgement message with both TEIDs. This way, the Serving Gateway knows the correspondence between its tunnel ID and the tunnel ID allocated by the P-Gateway. At the end of this exchange, a tunnel has been established wit, at one end, a TEID of 102, 102 and, at the other end, 16,538. Note that, at the end of this exchange, each end knows the TEID allocated by the opposite node. Let’s go a little further to see what processing is done in the Serving Gateway. We’ll see that the processing is relatively simple, once a table has been set up. The following explanation is valid to illustrate the principle. I’m not saying that the real implementation in the Serving Gateway is exactly like this, but it helps to really understand how the TEIDs are managed and how two tunnels are appended. We have, in the Serving Gateway table, the TEID values, the actions to be carried out, perhaps details about these actions and we’ll indicate which is the tunnel of the peer node. An example: when the Serving Gateway establishes the tunnel, it indicates TEID 102, so we’ll create an entry in row 102 of the table of the Serving Gateway. The S-Gateway knows the IP address of the P-Gateway. Once the P Gateway has responded, the S-Gateway knows that the P-Gateway has allocated 16,538 for the tunnel and for the TEID of that tunnel. This TEID is stored in row 102. The tunnel has been established. Now we can have a tunnel between the Serving Gateway and the eNodeB. This tunnel, for example, is established using 103 as the TEID: the corresponding address will be be the address of the eNodeB, eNodeB 2 in our example, and the TEID is 101. This is the TEID that was chosen by eNodeB 2. Every packet arriving on tunnel 103 must be re-sent to tunnel 102. The action of retransmission is called “Forwarding”. In the table, column Detail indicates that we forward packets from tunnel 103 to tunnel 102. If we look at the processing, that means that a packet arriving from, for example, eNodeB 2 will contain TEID 103. The Serving Gateway looks at 103, it sees, “I have to forward the packet, I forward it to tunnel 102", and what does tunnel 102 correspond to? It corresponds to tunnel 16,538 for this Packet Gateway. So, every packet that I receive with TEID 103, I resend it to the Packet Gateway with the TEID 16,538. The principles governing tunnels and their use for uplink packets are also valid for downlink packets. Packets from tunnel 102 are forwarded to tunnel 103. We have seen how packets in the user plane are processed by the nodes of a 4G network: each packet received by a node through a tunnel includes the local TEID of that tunnel. As the TEID is unique, it is possible to define a lookup table in the node where the TEID is the entry and to indicate how to process the packet. Processing a packet is very simple. It is thus possible to manage a huge number of tunnels. Furthermore, a level of quality of services can be associated to a tunnel. The association of a data tunnel and a quality of service level is called a data bearer.
