LTE Basics
ROHC:
this is PDCP layer feature and it involves compression of packets. Spec 36.323.
in aVoip application the packet header is bigger than the packet itself, so it makes sense to compress the packet.
You can see the ROHC info in UE Capabilty Information and also in RRC Connection Reconfiguration.
Profile 1 : RTP.
Profile 2 :UDP>
We will have usually 20 bytes of IP, 8 Bytes for UDP and 12 bytes of RTP header.
With ROCH we can compress it to 2-3 bytes, it a lot of saving.
In PDCP-LTE filter in WS , along with User Plane data,
we can see e1 fd or e1 f8 01 ->
the e1 represents the context ID, fd or f8 represents the IR DYN , 1st order or 2nd Order Compression & lastly 01 represents the profile being compressed in this case it RTP packets being compressed. This will be preceded by 2 bytes of RLC header.
The compression is usually done for Ded Bearer eg QCi 1, this is GBR service.
The compression can be checked by WS logs at eNodeb Side.
ROHC:
this is PDCP layer feature and it involves compression of packets. Spec 36.323.
in aVoip application the packet header is bigger than the packet itself, so it makes sense to compress the packet.
You can see the ROHC info in UE Capabilty Information and also in RRC Connection Reconfiguration.
Profile 1 : RTP.
Profile 2 :UDP>
We will have usually 20 bytes of IP, 8 Bytes for UDP and 12 bytes of RTP header.
With ROCH we can compress it to 2-3 bytes, it a lot of saving.
In PDCP-LTE filter in WS , along with User Plane data,
we can see e1 fd or e1 f8 01 ->
the e1 represents the context ID, fd or f8 represents the IR DYN , 1st order or 2nd Order Compression & lastly 01 represents the profile being compressed in this case it RTP packets being compressed. This will be preceded by 2 bytes of RLC header.
The compression is usually done for Ded Bearer eg QCi 1, this is GBR service.
The compression can be checked by WS logs at eNodeb Side.
