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上传输一个控制消息的所有分片。