通信人家园

 找回密码
 注册

只需一步,快速开始

搜索

军衔等级:

  四级通信军士

注册时间:
2014-11-11
发表于 2015-6-7 10:52:12 |显示全部楼层
本帖最后由 Helloamy2014 于 2015-6-7 10:53 编辑

我的4G之路-BSR补遗(一

坦白说,如果要深挖的话,问题肯定是有很多的。因为当时标准制定的时候,这么多公司经过长时间讨论,肯定是经过深思熟虑的。
所以要理解321中的来龙去脉,还是得看之前的文章。BSR上报的遗留问题将分成两次来写。今天将解释如下四个简单问题:

1)为啥是BSR的上报是按照逻辑信道组为单位?
当初是这么考虑该问题的:
首先,不管是Buffer的上报还是调度都存在一个业务优先级别排序的问题,越细分肯定越有助于网络进行精确调度。比如,要在信令和用户面数据之间进行区分,实时业务和非实时业务区分。
但还有一个重要考虑因素是,在满足以上调度需求上如何降低信令开销的问题。
最终是权衡在4个逻辑信道组。主要是考虑到本来给用户配置的逻辑信道不多,4个组就足够啦。

2)为啥要考虑周期性的BSR上报?
上次提及的那段英文描述可以认为是事件型的BSR上报。
引入周期性上报是需要解决BSR上报可靠性问题。BSR传输是在PUSCH上,若超过最大重传次数,则eNB无法获知用户有上传数据的需求,因此周期性BSR上报作为事件型的补充。
关于retxBSR-Timer的引入其实也是为了解决BSR上报可靠性问题。下次将重点讲解。

3)区分长短BSR的原因?
在很多情况下,上报全部的4个RBG分组有时是无必要的,譬如说,若就给用户配置了一个逻辑信道,就一个RBG分组,此时显然只需要上报一个RBG的信息,即短BSR。
此时就引入了短BSR和长BSR概念。长BSR就上报全部4个RBG分组的信息。

4)为啥要引入pading BSR?
可以从如下几个角度思考PaddingBSR。
首先:其实当enb收到上行数据包,发现包中包了一些乱七八糟的东西,即pading,enb就知道此时用户为啥可传的了。但此时就不妨包一个BSR上去,反正空间空着也是空着。
其次:Pading BSR有一个问题,就是表达的东西可能不是那么全面,比如Truncated BSR,被被迫截短。这也是协议中,将Truncated BSR和短BSR需要区分开,使用了不同的LCID的原因。
最后:在协议中还特别说明了:start or restart periodicBSR-Timer except when all the generated BSRs are Truncated BSRs;我理解,这里想要说明的是,对于Truncated BSR这种不太靠谱的上报,还是不要记录在periodicBSR-Timer中。
总结:鉴于Pading BSR的局限性,pading BSR优先级要低于常规BSR和周期BSR。

好了,有没有觉得321协议好理解了一点呢?

点评

xjLwxa  看不明白了  发表于 2018-3-2 15:32
已有 1 人评分经验 家园币 收起 理由
家园副管06 + 20 + 20

总评分: 经验 + 20  家园币 + 20   查看全部评分

军衔等级:

  四级通信军士

注册时间:
2014-11-11
发表于 2015-6-7 10:54:42 |显示全部楼层
本帖最后由 Helloamy2014 于 2015-6-7 10:55 编辑

先暂时放这么多.

军衔等级:

  新兵

注册时间:
2015-6-7
发表于 2015-6-7 16:36:36 |显示全部楼层
楼主很猛啊

点评

Helloamy2014  不敢当啊  详情 回复 发表于 2015-6-10 20:17

军衔等级:

  四级通信军士

注册时间:
2014-11-11
发表于 2015-6-10 20:17:16 |显示全部楼层
悠扬的风 发表于 2015-6-7 16:36
楼主很猛啊

不敢当啊

军衔等级:

  四级通信军士

注册时间:
2014-11-11
发表于 2015-6-10 21:30:18 |显示全部楼层
还有一篇BSR的问题补充,请在公共帐号察看!

军衔等级:

  四级通信军士

注册时间:
2014-11-11
发表于 2015-6-10 21:41:52 |显示全部楼层
本帖最后由 Helloamy2014 于 2015-6-10 21:56 编辑

我的4G之路-考考你的数学水平, 论MAC的组包

Baby math.png
熊孩子说,数学是小孩子玩的,太幼稚啦!那大人们呢?

现在我就要考考大家以下问题。
Let's do some baby math!
那如何把一个长为398字节的MAC SDU装进一个400字节的TB块里

于是我马上回归文艺范,托着腮开始想。
该问题简单得如同如何把大象装进冰箱里?答案:
MAC组包的结构是: mac组包.png



容我来理一理:
若干乱七八糟类型的MAC控制单元,和若干MAC SDU,后面还可能有padding。
其中每个单元前头都有一个子头,指明其逻辑信道类型,以及长度。
对于通常数据而言,有两种子头:2字节或者3字节,分别对应只是L长度为7bit和15bit。
之所以定义两种L长度,主要是用于兼容大包和小包两种场景。
mac子头.png

此外在某些情况下,子头中无需L长度指示
The last subheader in the MAC PDU and subheaders for fixed sized MAC control elements consist solely of the four header fields R/R/E/LCID. A MAC PDU subheader corresponding to padding consists of the four header fields R/R/E/LCID.
何以要进行如此精打细算呢?
因为当时在进行Mac包头架构设计的时候,能省就省嘛,这样可以有效减少头开销,这是当时设计的主要目标。于是就出现了上文中提及的L字段被omit的场景。

于是,我就想这么做:
因此先放MACSDU, 但是慢着...如何要是使用正常的Mac子头,需要15bit表示长度,因此是3字节。而我有398字节的数据,只有2字节的余量。咋办呢?
幸好,我的这个包中只有这一个SDU,因此就算是最后一个SDU吧。但是慢着,若是最后一个SDU的话,我只是需要一个字节啊,那还有一个字节放什么呢?我要是放padding的话,就能够放一个padding的一个子头。要是这样的话,那我之前放的SDU的子头就不是最后一个字节了。

瀑布汗啊。那我到底应该如何放子头呢?
亦或,我将原有的SDU进行拆包,但是拆包传输又会带来更大头开销。
妹纸我于心不忍啊!

看来Baby math哪有那么容易!熊孩子乱吐槽...

但是若是余量为1字节和4字节的场景下:
聪明的你一定想好了怎么放,如下图所示:
1byte余量:刚好放子头
4byte余量:放3字节子头,加1字节padding子头。此时padding部分其实是无数据的。
2和3.png
对于余量2字节和3字节场景:
于是当时讨论的时候,就只能想出办法这样解决:

2个字节余量:则无法放下一个3字节的子头,因此只能考虑将指示SDU的子头放在后头,前头再填充上一个padding的子头。
3个字节余量:因为此时仅有一个MAC SDU,因此其子头大小仅占据一个子节,前头填充上2个padding的子头。
2和3.png

和一般的padding不同的是,该类型padding子头放在前头,且E域被置为1,且无真正数据。
注意:以上头中LCID和E、R、R位置和最终协议定出来位置不同,但不影响本文的道理说明。

最后我要大声问一句大家:以上数学你会算了么?
Baby math其实不简单哈!呵呵呵...

不会算没关系,协议中的这句莫名其妙的神来之笔看懂就行:
When single-byte or two-byte padding is required, one or two MAC PDU subheaders corresponding to padding are placed at the beginning of the MAC PDU before any other MAC PDU subheader.
2和3.png

点评

xjLwxa  corresponding 类似的 correspond 相当的,相应的  发表于 2018-3-2 15:39
xjLwxa  微信公众号是多少啊  发表于 2018-3-2 15:38
已有 1 人评分经验 家园币 收起 理由
家园副管06 + 20 + 20

总评分: 经验 + 20  家园币 + 20   查看全部评分

军衔等级:

  四级通信军士

注册时间:
2014-11-11
发表于 2015-6-10 21:57:35 |显示全部楼层
哎,这里编辑太费事了...

更多文章,请见我的公共weixin帐号

军衔等级:

  新兵

注册时间:
2008-10-25
发表于 2015-6-15 16:28:16 |显示全部楼层
Helloamy2014 发表于 2014-11-14 21:53
我的4G之路-谈总体架构   

首先从直观上理解一下整个LTE系统的数据传输架构。先从有线网络说起。当进行 ...

很好

军衔等级:

  新兵

注册时间:
2015-6-15
发表于 2015-6-15 20:52:15 |显示全部楼层
赞,已关注微信

军衔等级:

  四级通信军士

注册时间:
2014-11-11
发表于 2015-6-22 20:38:03 |显示全部楼层
我的4G之路-你和女神之间,论Pcell和Scell的TA超时
TA.jpg

今天先摇身一变为情专,讲讲你和女神之间的一切。

假如你在某场合见到女神,相见恨晚,赶紧加了女神微信,期望从此和女神建立一段稳定的relationship。每天和女神通过微信保持长久的联系。

你主动给女神问寒问暖,如果女神也积极回复,你心头大喜,知道女神心里也是有你的。若是女神半天没回复你,你怅然若失,就知道没戏了。

事实就是那样。还有一堆人也都排在队里,等着女神亲睐呢。女神的时间和精力是很宝贵的,她看你聊天没啥实质性内容,可能真就不回复你了。

假设微信有个限制,当你和女神之间若半天没有通信,则认为你们之间联系实效,如何你依然放不下女神,你需要再次主动发起添加微信的请求。何其之惨啊。

但是,该场景是否在生活中也是常见呢?只不过是,攻城狮换成了我身边的妹纸,妹纸拿和男神之间的问题来问我,要不要继续?
我总是在想,如果你可以成为某人心中的第一,为什么硬是要自己成为男神心中的第N个option呢?

咳咳,赶紧回来!
------------------------华丽分割线------------------------
其实这个就是手机和基站之间定时关系的维持,即TA定时器的工作。一堆手机和基站的关系,就像一堆人围在女神周围。

首先说说,为什么要做TA?
1)用行业话说,手机和基站同步的含义是因为要保证上行传输正交性,要求来自不同用户的信号到达eNB的时间基本对齐,落在CP范围内。因此就要求用户和网络是同步的。

2)基站通过TA命令通知用户发送的时间偏移,比如远离基站的用户得到一个较大的偏移值。即更早提前发送。
网络如何知道用户要提前多少?需要用户给网络发送数据就知道了。通过估计随机接入中前导,以及后续用户上行传输的任何东西如PUSCH、CQI等都可以作为时间的估计。

3)手机启动一个定时器,只要该定时器在运行,则终端认为和网络处于同步状态,就可以进行上行数传。


注意:这里采用的是基站决定是否要维持和一个终端之间的同步。可以理解为当终端没有数据传输需求的时候,基站可以将该用户失步。
这是很合理的!
因为某些业务是不用总是维持上行同步的。如网页浏览,当用户下载完网页在浏览的时候,将其失步是有好处的,首先降低UE的功耗,以及减少维持上行同步的上下行控制命令。
虽然下次业务传输需要再次接入,增加了时延,但对于该类时延不敏感业务来说,问题不大。

TA的原理,用大白话说,就是女神希望你完全按照她的意愿和作息时间表和她联系
要是没啥重要事情,你就不要占用女神时间了,哪里凉快哪里待着...有要紧事情,再联系吧。
如果你要追女神,就必须得按照她的时间规则办事情。女神不高冷,能叫女神吗?

TA如何运作?
1)典型场景
初始的时候,用户发起竞争的随机接入,获取到TA,此时启动TA定时器。此时,UE每收到TA,则将定时器重启。
若TA运行期间,则忽略随机接入的携带的TA(因为认为前导估计出来的TA相比正常数据传输的TA误差要大);

2)TA定时器有小区级别和用户级别
本来协议讨论的时候开始仅考虑到小区级别配置(SIB2通知),考虑到不同用户的速率需求,又增加了UE_specific的配置(专用信令通知)

3)TA的定时是由基站说了算
之前也想用户自己根据各自速度之类的来决定自己的TA,后来想到测速又不准,还是别打岔了。统一网络说了算吧。

说了这么多,其实,俺想要重点强调的还是:
TA超时一般认为用户是没有上下行数据传输需求的时候。因此就很好理解,在Pcell失步的时候会怎么做了:
Pcell上失步
if the timeAlignmentTimer is associated with the Primary Timing Advance Group:
- flush all HARQ buffers for all serving cells;
- notify RRC to release PUCCH/SRS for all serving cells;
- clear any configured downlink assignments and uplink grants;
- consider all running timeAlignmentTimers as expired;

俺来解释一下:
失步的上行传输对网络不利,因此这类传输应该要绝对避免,上下行授权即SPS资源全部清空,HARQ buffer清空。
非同步状态的用户只能先通过RACH过程建立同步,也不可能使用专用SR资源,因此PUCCH/SRS就不必要了,不如分配给其他用户。


对于Scell来说,不存在SPS资源的概念,因此仅将buffer清空。且Scell上也没有PUCCH,因此仅释放SRS即可。

因此协议中对于Pcell和Scell失步的表述就完全清楚了?
看来身为攻城狮的我,深刻明白写代码不易,当情专更加不易啊!
已有 1 人评分经验 家园币 收起 理由
家园副管06 + 20 + 20

总评分: 经验 + 20  家园币 + 20   查看全部评分

军衔等级:

  四级通信军士

注册时间:
2014-11-11
发表于 2015-6-22 20:39:47 |显示全部楼层
最近还写了几篇其他文章,请见公共帐号。

军衔等级:

  四级通信军士

注册时间:
2014-11-11
发表于 2015-6-28 20:47:28 |显示全部楼层
我的4G之路-切换时用户在做什么?
首先问个问题:切换时用户在做什么?
我:太简单了吧?收到切换命令后往目标小区做随机接入啊?
额,额,这个谁都可以讲的吧。你来讲讲用户面怎么处理?
我:貌似要将PDCP、RLC、MAC进行一个重建,协议上都说得好明白的呢~~~~
但具体啥含义呢?

我只好说,你们先聊,我想静静...

以下行方向为例:
手机在短短的时间内发生了什么情况?
假如你坐在高铁上,在好端端在下载一个文件,突然发生了切换,收到了一条切换命令。

如果来一个慢镜头,就相当于用户收到了部分数据包,其中某些包还处于HARQ重传当中。此时eNB也相当于数据发送到了一半,包括发送到一半的进行HARQ重传的数据包,以及从核心网来的新数据包。

那遇到该情况,就好像网络突然断开了,一切停止在当前这个时间点。手机和基站都该各自怎么办?

分业务模式考虑:
UM模式,比方说视频流:
Reset MAC层:即全部参数清空再来。
此时完全可能有些包重传了几次,未达到最大重传次数,因为UE和eNB MAC层清空的原因,传输到一半的包就彻底丢了:

重建RLC层:经过MAC的Reset,因为有些包丢失。
UE也只能认命了,也只能将当前稀稀拉拉的这些当前可以组的包传递到PDCP(这些包之间很有可能存在GAP);从该过程看切换过程中丢几包就算了,不需要这么计较。

在PDCP层面上,将底层乱序的包交给高层,同时SN和HFN全部重置;

因此对于UM模式而言,丢的包就永远丢了。网络也不能做啥补救措施,因为当初在数据前传过程中,原enb仅会前传未发送包以及新从核心网收到的包,他才不会管之前有几包发送出去用户有没有收到呢。

所以在下行方向上,UM模式下是有损的切换。反正是UM模式嘛,丢几包不也很正常么?
UE用户面的处理就如这张图(我要你重点看到图中乱序这两个字!):


而在AM模式下,则可以做到无损的切换。这完完全全是依赖于PDCP的功劳啊。
在MAC和RLC层面上,还是像UM模式一样,该丢的包一样丢。
因为在MAC层面上,由于重置可能会丢包。而在RLC层面而言,UE也只能将当前可以组的包传递到PDCP,之后RLC全部重置。此时丢的数据包放到PDCP解决。

对于AM模式,PDCP如何做到完全无损的传输?
要是网络可以将UE未成功接收的包,在新的基站都原封不动重新发送一遍,无损就是可以做到的。

接收端,即UE侧的PDCP没有那么心急,他会进行排序处理,即将乱序的包排序好之后发送到高层。若发现包丢失,则会发送PDCP状态报告到目标enb,请求丢失包的重传。而后,再耐心等待,等待新eNB的重传后,将后来收到的乱序的包排序好之后往高层传递。如下图(我要你重点看到图中按序\升序这两个词!):


从网络测来说,因为用户是需要包无损的,因此网络侧这次会负责任很多!
原enb在前传的时候向目标eNB按序递交所有SN还没有被UE确认的下行PDCP SDU。源eNB还要向目标eNB前传通过S1口新收到的已经分配PDCP SN未来的及传输的包,和还没有来得及分配PDCP SN的数据。

对于目标enb而言,要优先传输从enb前传过来的包(除非该包得到用户上报的状态报告的肯定确认)。当收到用户PDCP丢包的报告后,要及时传送丢的包。

总结:从下行方向而言,对于AM模式,部分未得到UE确认的包需要在新的enb重传来保证无损而且其数据包的序列号在切换前后都得到了延续。因此在SN status信令中,需要原enb告知新的eNB下行即将分配的PDCP的SN号。

对于上行方向呢?上行方向在网络实现。
其实要做的事情也是和UE差不多的,也就是将PDCP、RLC、MAC进行一个重建。无外乎就是,原enb需要在复位的时候赶紧将收到的能够组的包发到核心网。
而对于AM模式而言,则对于丢失的部分包将由目标enb从UE获取并传递到核心网。因此源eNB在向目标eNB发送SN状态传输消息之前,首先会将成功按序接收的上行PDCP SDU递交到S-GW,再将乱序的包前传到目标enb,并且在SN status中向目标eNB隔空喊话:
这是当前的SN传输状态信息,我还有哪些包没有收到,你都给我记好了!回头等UE切换过来的时候,你要发送状态报告后向UE讨要。

总结:从上行方向而言,对于AM模式,部分未得到原enb确认的包,将把状态报告告知目标enb,由他向UE重新讨要

可见,在切换过程中,对于UM模式而言,也就丢几个包而已,问题不大,没什么大惊小怪的;
对于AM模式而言,经过PDCP层强大处理后,往高层的数据必然是无GAP,且是有序的。这也是建立在系统内切换基础之上的。

在这里,妹纸我要特别提醒你们的是,切换的时候,使用的不是Fullconfigration的切换方式哦!!!
Fullconfigration方式下,即便对于AM模式,丢包也是妥妥的啊!
而啥叫Fullconfigration?可以简单理解为一种粗暴处理方式,那就下次再说咯。



已有 1 人评分经验 家园币 收起 理由
家园副管06 + 20 + 20

总评分: 经验 + 20  家园币 + 20   查看全部评分

军衔等级:

  四级通信军士

注册时间:
2014-11-11
发表于 2015-6-28 20:50:46 |显示全部楼层
上边图片好像放不进去阿,具体见公共帐号吧.

点评

家园副管03  楼主好,外链图片容易丢失,最稳妥的办法就是图片先上传再使用~  详情 回复 发表于 2015-7-30 00:51

军衔等级:

  新兵

注册时间:
2015-7-1
发表于 2015-7-1 20:25:12 |显示全部楼层
你是妹纸啊,真厉害,持续关注

点评

Helloamy2014  是妹纸啊,哈哈,谢谢关注!  详情 回复 发表于 2015-7-1 21:07

军衔等级:

  四级通信军士

注册时间:
2014-11-11
发表于 2015-7-1 21:07:39 |显示全部楼层
zccjqd 发表于 2015-7-1 20:25
你是妹纸啊,真厉害,持续关注

是妹纸啊,哈哈,谢谢关注!

军衔等级:

  中士

注册时间:
2012-11-30
发表于 2015-7-6 15:21:22 |显示全部楼层
非常棒,谢谢lz分享

军衔等级:

  四级通信军士

注册时间:
2014-11-11
发表于 2015-7-11 16:06:27 |显示全部楼层
另外更新两篇切换的文章,请直接在公共帐号察看.

军衔等级:

  四级通信军士

注册时间:
2014-11-11
发表于 2015-7-11 16:06:43 |显示全部楼层
7月份发起的是RRC系列

军衔等级:

  四级通信军士

注册时间:
2014-11-11
发表于 2015-7-11 16:09:22 |显示全部楼层
本帖最后由 Helloamy2014 于 2015-7-11 16:12 编辑

我的4G之路-渐行渐远,为什么你就是搞不定331?
rrc.jpg

我的4G之路-为什么你就是搞不定331?(一)

你和女神之间,你每天投入大量时间和她在一起,付出了很大的心血来了解她。

有时候,你看她,觉得触手可及的近,然而突然清醒过来,又发现她其实很远。原来你从来就未曾真正了解她。

和女神之间这种又恨又爱的感觉,对于331,又何尝不是如此呢?
我总是问自己:从3G的25.331看到4G的36.331,我觉得好像懂了。但回过头看,才发现其实压根就没有真正懂过。

每当我看到331,我总是想到在我们日常中的各种关系。
当你下定决心要去了解一个人,而且费尽了自己的心思,你总觉得你已经了解对方的一部分,然而不管你怎么努力,你依然无法走进对方心里。Sigh,谁都不要拦着我,写完我要去哭一场...

我的心理学老师说,那是因为你们之间缺少关键对话。我深以为然。

多年之后,我终于明白我被331玩得团团转的原因了,那就是我还是不明白这一个个的流程,其背后的用意是什么。

为什么要分为为SRB1和SRB2?SRB2为什么要和DRB一起建立,而不和SRB1一起建立?
为什么要重建?重建有什么好处?
何为安全性激活?
A1-A5测量事件使用的场景是什么?
...

如果连这些基本问题都没有想明白的话,又何以能搞定331呢?
但是,协议这个东西,也不是一遍遍看,或者从网上搜索一些翻译成中文的版本,就能搞定的吧?因为这些资料网上实在太多了!
所以,我在7月份发起了和RRC的关键对话,一起来参加讨论吧。

最首先的一个关键对话是,RRC连接建立。而且,我打算花费大量篇幅来讲解RRC连接建立。你就知道该流程有多重要了。

1)RRC连接建立内容
RRCConnectionRequest消息从协议结构而言,其承载架构为SRB0/CCCH/RLC-TM/无PDCP;
填充RRCConnectionRequest消息内容:
InitialUE-Identity:填S-TMSI(40bit)或Random Id(40bit)
EstablishmentCause,3bit
Spare,1bit

RRCConnectionSetup消息,其承载架构也是SRB0/CCCH/RLC-TM/无PDCP,其内容是负责SRB1的建立。

当用户收到RRCConnectionSetup消息后,根据其要配置的东西进行了一番配置后,就回复RRCConnectionSetupComplete消息。
我们先暂时不管消息要携带什么,仅仅想想这几条消息发送在什么信道上:
RRC连接建立请求和其实都是在SRB0上传输的。何谓SRB0呢?
SRB0就是不会为该用户建立公共通道的状态。也就是说用户看来,因为只有一条公共大道通向罗马,人又多,因此拥挤得头破血流,发生碰撞也是常有的事情。
因为RRC连接建立请求消息其实就是放在msg3,响应在msg4中。即完全是走随机接入那一套。只有经过了RRC连接建立,才会建立SRB1,用户才具有了自己专用通道。

接下来,我要重点分析一下SRB0状态和SRB1状态的各自特点。假设你有一个手机,你闭上眼睛就能想到你的手机的处境:
SRB0态可以认为是一个最初始状态:
用户没有专有的东西。所有的CCCH消息都在这条大道上传输,都存在碰撞的可能性。msg3消息是用的PUSCH,那些物理层配置,就是用默认的那一套,见331中9.2章节的一些默认配置说明。

SRB1态,给用户分配了专用逻辑信道:
此时还给配置了MAC和物理层参数。层1参数每个用户只有一套,主要配置的是PDSCH、PUSCH参数以及CQI/SRS/SR等上报参数。
这些参数以后是可以重配的。

在SRB1建立起来后,后续,用户要发送的信息,就不用再去挤公共信道了。
如紧接着的UE能力查询,还负责大量NAS消息的传送,如NAS层的鉴权。这些消息都是在RRC连接起来后马上进行的。

注意,这些流程都还是不需要空口的安全模式激活的。只有在后续,当从核心网发送过来初始上下文建立请求消息(initial context)后,其中携带的AS层的安全模式控制参数后,此时,才进行AS层的安全激活。

何为AS层的安全模式控制?即接入层的安全模式,即对于信令数据的完整性保护和用户面数据的加密。具体内容后续会专门一个章节讲解。这些接入层的安全模式需要一些参数,这些参数原本是从核心网的用户上下文提取的,之后才是通过在SRB1上通知用户的。

因此RRC连接建立过程以及之后的部分交互消息,如UE能力查询,这些消息本身发送都是没有安全模式控制的。只有在其后的用户获得了安全模式控制参数这个时间点之后,在SRB1,SRB2,DRB上传输的参数才都是经过安全保护的。即在SRB1和SRB2上运行完整性保护算法,而在SRB1,SRB2和DRB上运行加密算法。

总结一下,其实SRB0和SRB1,实现的就是一个从无到有的过程。这个过程对于终端而言,才是一个巨大飞跃。在SRB1建立完成之后才进行安全模式控制。
之后的SRB2和DRB建立过程就非常简单。

SRB2和DRB
之后才是RRC连接重建消息,用于建立SRB2和默认承载:此时需要建立:
SRB2用于传输低优先级信令,相当于又开了一个通道;
DRB用户传输数据,打开了一个更大的通道。

看到这里,有人问,那为啥SRB2不和SRB1一起配置,而要和后续DRB一起配置呢?
主要考虑是SRB2消息早发一点, 本来就是用于传输低优先级消息,time benefit不大,且还会增加RRC连接建立消息的大小,因为AM模式配置的那一堆参数也不少。因此就不这么干了。

下篇:消息具体内容讲解。

点评

xjLwxa  学点英语  发表于 2018-3-2 16:05
已有 1 人评分经验 家园币 收起 理由
家园副管06 + 20 + 20

总评分: 经验 + 20  家园币 + 20   查看全部评分

军衔等级:

  副版主

注册时间:
2010-12-20
发表于 2015-7-12 09:59:26 |显示全部楼层
帖子写的都很好,估计lz是搞L2/L3开发的吧,感谢分享!
编辑帖子的确有些恼火,一种方法是先用word编辑好,再截屏成图片放到论坛上。有其他建议或需求可以直接联系副管或本人。
另一个建议是,各个topic之间的跨度太大,能否列个大致提纲之类的?
Thanks again!

点评

Helloamy2014  非常感谢建议。 其实各个文章之间是有一定连贯性的,在微信账号上基本上是连续的。 但是由于在这里编辑比较麻烦,连载就缺失了很多。。。  详情 回复 发表于 2015-7-16 09:57

您需要登录后才可以回帖 登录 | 注册 |

Archiver|手机版|C114 ( 沪ICP备12002292号 )|联系我们 |网站地图  

GMT+8, 2019-12-10 14:49 , Processed in 0.093750 second(s), 17 queries , Gzip On.

Copyright © 1999-2019 C114 All Rights Reserved

Discuz Licensed

回顶部