This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NB-IoT Stack and Header size

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

Parents
  • 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.
Reply
  • 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.
Children
No Data
Related