LENA Modify GTP-U Headers

40 views
Skip to first unread message

Bruno Cordero Rangel

unread,
Feb 6, 2019, 6:56:23 AM2/6/19
to ns-3-users
Hi everyone,

we're currently working with the LENA module on a test bed where we have two TCP Accelerators deployed (since they're GTP capable, we can optimize the TCP packets inside the tunnel). The problem is that, for some reason, those accelerators (Xiplink vendor) are changing the following GTP-U headers (also shown in the image):
- Reserved (from 1 to 0)
- Is Sequence Number Present? (from Yes to No)
- Is N-PDU number present? (from Yes to No)

Because we cannot force the TCP Accelerator to modify these values, we're trying to make these changes from the NS3 side. Checking the code, we've been able to modify Boolean values of Sequence Number and N-PDU from src/lte/model/epc-gtpu-header.cc:

GtpuHeader::GtpuHeader ()
  : m_version (1),
    m_protocolType (true),
    m_extensionHeaderFlag (false),
    m_sequenceNumberFlag (true),
    m_nPduNumberFlag (true),

    m_messageType (255),
    m_length (0),
    m_teid (0),
    m_sequenceNumber (0),
    m_nPduNumber (0),
    m_nextExtensionType (0)
{

However, we cannot locate where to change (or even if it's possible ) the "Reserved" field. Without this field and only changing Sequence Number and NPDU to False, the tunnel is identified as a PPP Unknown protocol.

Please note the attached image, showing a screenshot from Wireshark showing the value differences.

Thanks a lot in advance,

Bruno
gtpu-headers.png

Bruno Cordero Rangel

unread,
Jun 6, 2019, 1:06:14 PM6/6/19
to ns-3-users
Hi,

we have finally fixed it by modifying GtpuHeader::Serialize, GtpuHeader::Deserialize and GtpuHeader::GetSerializedSize functions in src/lte/model/epc-gtpu-header.cc.

Besides setting the m_sequenceNumberFlag and m_nPduNumberFlag to False in GtpuHeader::GtpuHeader, the Serialize function was still writting zeros to them, creating a reading confusion at the Deserialize process (where no bits were expected on these fields). In order to avoid that in our scenario, m_sequenceNumber and m_nPduNumber have been removed from the Writing and Reading processes, while decreasing from 12 to 8 the returned value in GetSerializedSize.

Now Wireshark and the TCP Optimizers can handle the traffic properly.

Thanks a lot,

B.
Reply all
Reply to author
Forward
0 new messages