LTE SGW/PGW - TUNdevice & S1Link packet size

376 views
Skip to first unread message

Marco Mezzavilla

unread,
Sep 13, 2012, 10:37:51 AM9/13/12
to ns-3-...@googlegroups.com
Dear all,

I am trying to simulate the transmission of a flow composed of jumbopackets (>1500Bytes).

I use udp-client by simply extending the allowed packet size to 10000 Bytes.

On the other hand, concerning the core network, I set
m_tunDevice->SetAttribute("Mtu", UintegerValue(10000))
epcHelper->SetAttribute("S1uLinkMtu", UintegerValue(10000))

This is working properly. 

The problems come when I try to send jumbopackets (9000B) from the UDP-client application, while limiting the S1 and TUN MTU sizes to 2000B.
I expect the Core Network to somehow perform fragmentation, since the transmitted packet is bigger that the MTU (9000 vs. 2000). 
But this does not happen, and it looks like the eNodeB is transmitting packets >2000B, despite of the MTU.

Does anybody have an idea?
I read the LENA-doc, but I didn't find any answer.

Regards,
Marco

Nicola Baldo

unread,
Sep 14, 2012, 9:25:41 AM9/14/12
to ns-3-...@googlegroups.com
Where exactly at the eNB are you seeing these packets >2000?

Marco Mezzavilla

unread,
Sep 14, 2012, 9:47:59 AM9/14/12
to ns-3-...@googlegroups.com
Hi Nicola,

I've just found out that (at RLC level) the transmitted packet >2000B (MTU 1600B) is bigger as compared to the transmitted packet >2000B (MTU 9000B). I think that this shows a correct behavior according to which segmentation brings higher overhead.

Example:
a) MTU 1600, tx packet size (APP level) 7584 Bytes --> tx packet size (RLC level) 7722 Bytes = 138 B header
b) MTU 9000, tx packet size (APP level) 7584 Bytes --> tx packet size (RLC level) 7628 Bytes = 44 B header

I'm now trying to understand the header of the 7722B-packet, which is approximately composed of four-1600B fragments plus the last 1184B-fragment.

Cheers,
Marco

--
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ns-3-users/-/M4vBFq7yfooJ.

To post to this group, send email to ns-3-...@googlegroups.com.
To unsubscribe from this group, send email to ns-3-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ns-3-users?hl=en.



--
Marco Mezzavilla
Ph.D. Student - SIGNET Group
Department of Information Engineering (DEI)
University of Padova - Italy

Marco Mezzavilla

unread,
Sep 14, 2012, 9:59:11 AM9/14/12
to ns-3-...@googlegroups.com
Talking about concatenation, not segmentation sorry.
Not fragments, but SDUs.

M

Nicola Baldo

unread,
Sep 23, 2012, 8:05:36 AM9/23/12
to ns-3-...@googlegroups.com
Hi Marco,

sorry for the late reply. I guess that when you say "138 B header" you obtained it by doing 7722 - 7584, but this is not the correct way to calculate the RLC header size. The fact is that RLC does both SDU concatenation and SDU segmentation in order to fit SDUs (i.e., IP packets) into the RLC PDU size which is determined by the scheduler. Please refer to 3GPP TS 36.322 for details.

Regards,

Nicola
Reply all
Reply to author
Forward
0 new messages