NB-IoT Stack and Header size

[Jackhead]

Hello,

I´m searching some information about the NB-IoT protocol stack and the overhead which is send with every message.

I nearly searched the whole net but didn't find anything. Is there any document from nordic or some information which tell me how many headers are transmitted with
every message and how big each header is and how many user data I can send with one data package? 

It would be great if there is a document where I can see that the physical layer has a header with size ... and the mac layer has a header which is ... big. 

Do you guys have some information for me regarding this topic?

Best regards

[Martin Lesund]

Hi Jackhead,

We do not have a specific documentation about the LTE-M or NB-IoT technology.
Here is however an extensive list of information that should answer most of your questions.

Also I found this site helpful

[Jackhead]

Hello Martin,

thank you very much for your sources.
Even though they are very informative and detailed, the information I was looking for wasn't contained.
I'm looking for real numbers of headersizes. In the first source there were many information about how everything work but no specific size of headers were mentioned. For IPv6 you can say that the header is 40 bytes but sadly these type of information are missing for NB-IoT to date. 

[Martin Lesund]

Hi Jackhead,

First need to understand is what does NB-IOT protocol stack mean. There is no single defined stack but many. 
Next is the LTE radio protocols that has multiple layers and each has their own header. Next issue is that the message will be split in LTE radio interface and the segment size depends on quality of the link.

These are the 3GPP specs 

• PDCP: 36.323
• RLC: 36.322
• MAC: 36.321
• R13 versions of above.

The data from TCP/IP or NON-IP protocols goes though these protocol layers.

https://www.3gpp.org/DynaReport/36-series.htm 

---

In case of NB-IOT no PDCP used for CP data transport.
Exact size depends on many factors like what else the UE has to report e.g. at the MAC layer etc.
Below does exclude BSRs etc. There can be errors in below numbers but the "ballpark" is correct.

Assumptions:

• Rel-13
• UE was in RRC-IDLE before doing the service request. RACH & RRC connection establishment related overhead is excluded i.e. we only check the (RRC) message containing the User Data payload.
• 1000 bits TBS size, no repetitions, perfect SNR
• User Data <128 octets at MAC SDU level
• RLC-AM SN = 10 bits, PDCP SN = 5 bits
• mo-data i.e. data is included into the EMM CP Service Request

Overhead consists of:

• MAC sub-headers + padding
• UL-DCCH-Message encapsulation
• RLC-AM encapsulation (because DCCH uses SBR1bis and RLC-SAP AM)
• No PDCP + MAC-I encapsulation (because RRCConnectionSetupComplete-NB over UL-DCCH uses SBR1bis)
• NAS encapsulation
• Alignment
• IP + transport overhead

Note: 1000 bits TBS = 125 octets i.e., every encoding at MAC, NAS etc stays below 128.

The example rough calculation produces:

• MAC(optimistic 1 )+RLC(2)+PDCP(0)+RRC(4)+NAS(16) -> 23 octets of headers
• If 8*(23+payload) < 1000 we need to pad to full TBS:
  Maximum user payload with presented header overhead is 102 octets.