The TCP is used to transfer a continuous stream of octets in each direction between users by packaging some number of octets into segments for transmission through the internet system[RFC793]. In SIP realm, the TCP is one of the most commonly used protocol along with UDP to transfer user data.
The above diagram shows an example of the protocol map for LTE user plane. The backhaul is placed between eNB and the EPC in the operator's network in general. The IPv4 packet sent by the UE over the air is wrapped by the eNB using GTP and IPv6 headers. The eNB sends the IPv6 packet through the GTP tunnel and the PGW at the end of GTP tunnel unwraps the IPv6 and GTP headers. The retrieved IPv4 packet at PGW is forwarded to the P-CSCF over SGi interface.
I. TCP header
The following shows the TCP headers and parameter descriptions as specified in RFC793
- Sequence Number(32bits): The sequence number of the first data octet in this segment(except when SYN is present). If SYN is present, the sequence number is the initial sequence number(ISN) and the first data octet is ISN+1.
- Acknowledgment Number(32bits): If the ACK controls bit is set this field contains the value of the next sequence number the sender of the segment is expecting to receive. Once a connection is established this is always sent.
- Control bits(6bits)
- URG: Urgent Pointer field significant
- ACK: Acknowledgement field significant
- PSH: Push Function
- RST: Reset the connection
- SYN: Synchronize sequence number
- FIN: No more data from sender
- Checksum(16bits): The 16bit one's complement of the one's complement sum of all 16 bit words in the header and text. This is used to detect the corruption of data over TCP
II. Usage of TCP headers in packet analysis
After successful initial attachment to the LTE network, the VoLTE UE(i.e., IMS UE) establishes a TCP connection with the P-CSCF in order to process the IMS registration. Once the TCP connection is established, the UE starts sending SIP messages(i.e., SIP REGISTER).
TCP parameters can be useful when they are used to identify the identical packets between sending and the receiving node respectively. It is true in particular when the network(e.g., backhaul) is unstable where there can be a lot of packet delay, packet loss and packet re-transmissions, as it becomes far more difficult to analyze the packet flows.
NOTE In the following snapshot, the yellow box depicts a UE side ip address and the green box a Core side ip address. All the detailed ip address is hidden for security purpose.
The following snapshot shows the UE side trace log that was captured at UE. This example shows the normal SIP procedure that can occur when the call is requested by the user.
The following snapshot shows the Core side trace log that was captured between backhaul and the Serving GW. The procedure in this example is correlated with the above figure.
In order to find the matched transaction between the two nodes, the TCP checksum data can be used to identify the same packet. In this example, the same TCP packet for SIP INVITE can be found with its checksum value = 0x8bef. Note that it would be more usual to find the matched SIP transaction based on Call-Id in normal situation. However, when there are many packet re-transmissions and delays, the Call-Id wouldn't be enough to pinpoint the matched ones.
On the other hand, taking a look at the SIP PRACK, the UE has sent two packets. As they are re-transmitted by the SIP layer, they will have different checksum value. (i.e., ox28e2, 0x2781)
In the meantime, there are three SIP PRACKs appears in the core side and all of them has the same checksum value(0x2781). This checksum value indicates that they are matched only with second SIP PRACK sent by the UE. Therefore it can be reasoned that the first SIP PRACK sent by the UE has been lost somewhere between UE and the Serving GW.
In the following core trace, it is observed that the TCP Ack for the SIP PRACK(TCP Syn) is sent only after 40 ms from the received SIP PRACK. The corresponding TCP Ack can be identified by mapping the TCP Acknowledge Seqnum of the TCP Syn with the Seqnum of the TCP Ack.
The same TCP Ack can also be found based on the checksum value. In this example, the UE received the TCP Ack for the SIP PRACK after 700 ms.
Given the relative time gap between the SIP PRACK(TCP Syn) and the corresponding TCP Ack at both ends, it can be reasoned that there has been a packet delay somewhere in a downlink between Serving GW and the UE.
***
The TCP packet analysis can be used to correlate the packets between sending node and the receiving node. Measuring the relative time gap of sending and receiving packets also makes it easier to identify the problematic NEs or interfaces. As such, the TCP headers give useful information to engineers in analyzing the technical problems in VoLTE service. As the TCP packet delays and losses can more often than not lead to the IMS registration delay, IMS registration failure, call setup delay and call setup failure, it is directly related to the quality of user experiences. The TCP packet analysis becomes very useful way to realize the quality of VoLTE Service as it might also be in other services.
Red Mouse
No comments:
Post a Comment