【大话GSM】LLC PDU填充RLC/MAC实例介绍

LLC PDU填充RLC/MAC实例介绍
        本文档的总结是在对GPRS系统的学习做汇报时，楷哥提出的问题当时没有回答上来的总结。LLC PDU填充RLC/MAC包括填充RLC/MAC数据块以及上层控制消息填充RLC/MAC控制块时需要分块的情况。

1. LLC PDU填充RLC/MAC数据块

假设现在有如下五包LLC数据，按照下面四种情况，分别组出RLC/MAC数据包。

注：采用CS-1编码方式，主要是分段字段的填写，其它字段默认为0。

LLC数据包1：0x01 0x02 0x03 0x04 0x05

LLC数据包2：0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d

LLC数据包3：0x0e 0x0f 0x10 0x11

LLC数据包4：0x12 0x13 0x14 0x15 0x16 0x17 0x18

LLC数据包5：0x19 0x1a 0x1b 0x1c 0x1d

LLC 数据包6：0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10 0x11 0x12 0x13 0x14 0x15

情况1：只有LLC数据包1需要下发；

情况2：LLC数据包1、2、3需要同时下发；

情况3：LLC数据包1、2、4需要同时下发；

情况4：LLC数据包1、2、5需要同时下发。

情况5：只有LLC数据包6下发。

GPRS RLC数据块包括：RLC header、RLC data unit以及spare bit，如下所示：

 


RLC data block可采用的编码方式如下所示：

 


由上图可知，当采用CS-1的信道编码方式时，RLC data block块大小为22个字节，此时不包含spare bit。

在进行分析组包前，先给出RLC/MAC下行数据块的帧结构，并对组包时需要用到的帧结构的字段进行分析，然后再给出实际的组包结果，RLC/MAC下行数据块帧结构如下：

 


其中，RLC header包含2个固定字节（PR、TFI、FBI和BSN、E）及若干可选字节（Length indicator、M和E）。其中FBI、LI、M和E字段的含义如下：

a. FBI（Final Block Indicator）：最终块标识，声明了下行RLC数据块是否是下行TBF中的最后一个RLC数据块，即代表了TBF的终止。当FBI = 0时表示当前块不是TBF的最后一个RLC数据块；FBI = 1时表示当前块是TBF的最后一个RLC数据块。

b. LI（Length Indicator）：长度标识，LI用于给RLC数据块中的LLC PDUs定界。第一个LI值标识的是在RLC数据字段中属于第一个LLC PDU的字节数，第二个LI值标识的是在RLC数据字段中属于第二个LLC PDU的字节数，依次类推。

关于LI还有一类特殊情况是，如果上层PDU的结尾此时正好可以填充上RLC数据块，但是由于添加的LI字节导致上层PDU要扩展到下一个RLC数据块，在这种情况下，LI字段应该设置为0。

同时，在这种情况下，在发送端M bit应当设置为0，E bit应当设置为1；在接收端，M bit应当被忽略，E bit应当被解释为1。

c. M（More）：更多，在GPRS的TBF模式中，M bit和E bit以及LI一起用于定界LLC PDUs。当M bit出现后它表示在RLC数据块中是否还有另外一个LLC PDU在当前这个LLC PDU的后面。当M和E同时出现时，其含义如下：

 


00：如果MS收到（在A/Gb模式下），它应当忽略除MAC头部之外的所有RLC/MAC块的字段。

01：表示在当前LLC PDU之后没有LLC数据了，不含有扩展字节；

10：表示在当前LLC PDU之后又有一个新的LLC PDU，还存在一个扩展字节用于为新的LLC PDU定界；

11：表示当前LLC PDU之后又有一个新的LLC PDU，该LLC PDU一直持续到RLC信息字段的结尾，不含有扩展字节。

d. E（Extends）：扩展比特，它用于声明在RLC数据块头是否存在一个可选的字节。当E ==0表示扩展字节紧随；当E == 1表示没有扩展字节。

 

下面开始实际的填充：

1) 情况1：一个LLC PDU填充到RLC/MAC块中，且未填充满。



2) 情况2：多个LLC PDU正好填充完一个RLC/MAC数据块。这种情况下，在RLC data block中共有8个有效字节，其余的14个字节均填充为“0x2B”。



3) 情况3：多个LLC PDU填充一个RLC/MAC数据块，且最后一个LLC PDU跨越两个RLC/MAC数据块。注意：上图中橙色标识的地方，M E要填充为“01”，而不能为“11”，因为这个LLC PDU就只有4字节的数据，正好填充完，后面没有该LLC PDU的数据了。我第一次填充的时候使用的是“11”，这是错误的，使用“11”的情况标识一个LLC PDU跨越了两个RLC/MAC数据块的情况。见3)。



注意：上图橙色填充的地方表示一个LLC PDU跨越了连个RLC/MAC数据块。当接收端接收到该RLC/MAC数据块后，接收端就知道后面还有数据才能组成一个完整的LLC PDU。

 


4) 情况4：最后一个LLC PDU正好填充RLC/MAC块中剩余的数据部分，但是由于添加可选字节LI导致该LLC PDU跨越两个RLC/MAC的情况。



注意：这种情况就是LLC PDU的数据恰好能填充满剩余的RLC/MAC的剩余部分，但是由于扩展字节的添加导致该LLC PDU扩展到下一个RLC/MAC数据块的情况。此时，上图中的LI字段为0，M字段为0，E字段为1，详细解释可以参考前面LI字段的释义部分。



5) 情况5：LLC PDU从一个新的RLC/MAC数据块开始下发，且数据字段大于20个字节。 



注意：如果某LLC PDU重新开始于一个RLC/MAC块，且其长度大于20个字节，则在进行填充时，第一个RLC/MAC块中是没有可选字节的，即E = 1，代表“No extension octet follows”。

2. 控制消息填充RLC/MAC控制块时分块的情况

RLC/MAC控制块使用采用CS-1编码方式。

下行RLC/MAC控制块的帧结构如下所示：

 


关于RTI，协议中的描述有两种功能：

1)  聚合下行RLC/MAC控制块以使其组成一个RLC/MAC控制消息;

2)  标识下行RLC/MAC控制块相关的被分片的控制消息的序号;

RTI对某个控制消息标记，然后RBSN、RBSNe、FS和FSe共同对分片进行控制。

RBSN和RBSNe标识一个RLC/MAC控制消息被分片后的下行RLC/MAC控制块的序号。

 


只有网络端可以对RLC/MAC控制消息进行分片，MS不可以。且最多分片数为：1~9。当RLC/MAC控制消息不能恰好分成一个整数的控制块时，最后一个控制块将会被填充字节填充。RLC/MAC控制块头部的FS bit会根据RLC/MAC控制块是否是最后一个分片的情况来设置，如果使用了RBSNe，则FS始终设置为0。

对于两个独立的RLC/MAC控制消息，网络不能在相同的PDCH上在同一时刻使用相同的RTI。对于不同的PDCHs在同一时刻网络可以使用相同的RTI。网络应当在相同的PDCH上传输一个控制消息的所有分片。