【原创连载】 我的4G之路（9月5日连载：240#更新）

Helloamy2014

我的4G之路-写在最前面

自从走向了通信这条路，已经很多年了:) 在暂时没有下定决心告别之前，简单回顾了一下，这其中虽然有很多时刻，觉得自己做的这行有那么点意思，但更多的是种种心酸和挣扎。最初是作为测试工程师，时间就顺着不同版本的发布飞快溜过去，之后又作为协议研究工程师，时间也是过得飞快。好多年下来，一路走来一路想，我一路学习到了什么？是否足以支撑我今后的5年？经常是身处疑惑当中。

除了工作的重压之外,时间对我的要求越苛刻，记忆力也远远不如以前。因为我们需要更多时间来陪伴家人，做工作之外的事情，对工作的投入时间已经不如刚毕业时。我现在回过头看，在通信行业，对协议的理解是一条必经之路，我真的希望走这条路的时间缩至最短。因此我想到用自己业务的一点时间把我之前理解的东西整理出来，能够抽出其中最重要的部分，在脑子里形象化出来。于是开始写技术blog，最初发表在朋友圈。

因为之前得到的反馈很少，我一直认为这是一件自己和自己玩的事情，可能压根没有人关注。后来遇到一些同行，竟然发现真的有人在看我文章。他们的鼓励让我坚持下去。虽然写作很辛苦，但写作能够让我安安静静坐下来，梳理自己的情绪和思维，而且文字的分享会触发更多分享和交流，触及不同的灵魂。

那就开始吧，不过我的blog将会尽量把这些文字上的东西写得比较简单，好玩。如果有不当的地方，请同行指正！我非常希望听到同行的意见。

【更新连载】： （家园编辑）
我的4G之路-谈总体架构
我的4G之路-谈调度     11月19日更新
我的4G之路-原语，RLC和MAC之间的秘密    11月22日更新
我的4G之路-MAC的组包  
我的4G之路-下行HARQ      11月23日更新
我的4G之路-DRX       11月24日更新
我的4G之路-我为什么要付出120%的努力？    11月25日更新
我的4G之路-DRX PK 都教授     11月26日更新
我的4G之路-如果你想寻呼都教授(一)     11月27日更新
我的4G之路-寻呼时刻(二)     12月1日更新
我的4G之路-你吼也没用，论无线链路的失败    12月4日更新
我的4G之路-王建宙《移动时代生存》新书问答录    12月6日更新
我的4G之路-大妈们教你的随机接入原理        12月9日更新
我的4G之路-非竞争随机接入以及问题补遗       12月14日更新
我的4G之路-上下行HARQ                            12月31日更新
我的4G之路-《精益创业》和个人效率          12月31日更新
我的4G之路- NDI 亦或 RV？                   1月11日更新

[2015-7-12更新连载]

我的4G之路-我的互联网之旅

我的4G之路- 话说LTE的测量(一)

我的4G之路 - LTE的测量（2）

考考你的英文水平- 321中的SR和BSR

我的4G之路-BSR补遗（一）

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

我的4G之路-你和女神之间，论Pcell和Scell的TA超时

我的4G之路-切换时用户在做什么？

我的4G之路-渐行渐远，为什么你就是搞不定331？

我的4G之路-最悲伤的事情莫过于赚过，论RRC连接重建

Helloamy2014

通信技术你问我答 (积分兑奖)

我的4G之路-谈总体架构   

首先从直观上理解一下整个LTE系统的数据传输架构。先从有线网络说起。当进行一个FTP下载业务时，TCP协议可以保证数据包的有序可靠向应用层递交。在有线网络出现丢包时，TCP协议可以有重传机制来解决该问题，并对乱序的数据进行排序。注意这是有线网络,TCP可以工作的很好。而现在若要使用手机进行一个FTP下载呢？TCP协议就得运行在及其不靠谱的物理链路上，在丢包如此高的物理介质上，TCP不停慢启动，早就被整崩溃了！！

一个直观的想法，就是我们让无线链路变得可靠一点，因此又在无线链路上套上一层可靠传输协议，非常类似于TCP，即RLC协议，这样数据包向高层TCP递交的时候，就是可靠和有序的了。

我们现实生活中的通过快递来形象说明TCP和RLC的关系。比方说你老板要发送快递（包括了5个包裹）给在上海的对方公司的一个老板，作为你老板的小助理，你的任务是要对方老板按序接收到5个包裹。显然，你需要收到从对方来确认消息，告知每个包的发送情况。对这种事情，显然不需要你直接去麻烦对方老板啦，你就直接和对方的小助理打交道就行了。

你会怎么做呢？你首先联系一个北京快递调度总站，由他来帮你负责这几个包裹帮你发送到对方小助理。快递调度总站会怎么做呢？快递的生意也是很忙的，一天发货量也就这么大，有些用户可能都懒得搭理。我们假定你是VIP用户，申请到了他的调度服务，他拿到了这5个包后，显然得查一下，有没有快递公司可以服务。现在的快递公司，比方说，顺丰在周一发货，圆通在周二可以发货，申通在周三发货(各种通一一排列下去)...

于是包1通过顺丰在周一发送，包2通过申通在周二发送。。。。当然快递不是绝对可靠，但他会将无法成功传输的数据包重复发送多次，若还是丢失，那就没辙了（但他已经尽力啦，你也不能怪他呀）。我们假设包2选了个不太靠谱的快递被弄丢了，因此上海的快递调度总站只能将剩下的1，3，4，5给对方小助理。于是对方小助理一看，包少了一个，会给你打电话，让你重发包2。于是包2在最后一个到达，小助理将数据包排序再给她老板。

此时双方老板的角色就是TCP，只管正常收包就行了。
你和对方小助理的角色就是RLC，需要不时确认数据包，丢了就得重传。
北京地的递调度总站和上海地的递调度总站，负责资源的管理，充当的是MAC的角色，即负责发送谁的包，以及将包分配给合适的快递公司去传。也就是本次的专题。
快递公司：各种通什么的，就意味着传输数据包的HARQ进程，可以认为对应了资源，但资源的使用需要遵循一定的时序关系。


从总体上看，在TCP下面已经有两层重发机制了，这样TCP运行的链路就可靠多了。弄明白了这个，整个架子就搭建起来了，框架很简单。但里面的细节可大大不简单啊。以后再一一细说。
To be continued：
MAC的调度

laolu999

占楼，欢迎楼主继续~

阿炳0513

持续关注，正在做这方面课题

lph_2000

赞，早已关注LZ微信

landai

搬个板凳关注

landai

lph_2000 发表于 2014-11-17 12:57
赞，早已关注LZ微信

LZ的微信ID是什么啊？偶也关注学习一下

hualong95

持续关注中

goon2005

  通俗易懂

milo4sun

一直很喜欢看这种通过具体例子来讲述通信协议的文章，觉得通熟易懂

lph_2000

landai 发表于 2014-11-17 13:02
LZ的微信ID是什么啊？偶也关注学习一下

就是我的4G之路

佳恒工程师

好文

landai

lph_2000 发表于 2014-11-18 14:37
就是我的4G之路

这个搜索不到啊

平凡中落魄

MARK一下:)

lph_2000

landai 发表于 2014-11-18 15:38
这个搜索不到啊

那你问问楼主

AAlexx

好东西，写得很直白。

胡胡10086

怎么没有下文了！

Helloamy2014

大家好,因为最近比较忙,所以有点慢.
楼上有同学问如何关注，在微信公共帐号中搜索“我的4G之路”就可以了。可能楼上同学没有搜索微信公共帐号吧。
我在微信上是分了两个板块，技术版和非技术版。非技术版主要是自己的感悟，就不会放在该处发表了。有兴趣的同学可以查看。
或者有建议，请直接加我私人微信帐号319137103。注明“我的4G之路”即可，我可以更快看到大家反馈

Helloamy2014

我的4G之路-谈调度

上回提及到MAC的主要功能是负责调度，即负责进行资源的分配。可以直观上将用户分为两类，一类网路未建立连接的用户，即网络压根不认识的用户。一类是已经和网络建立连接的用户。前者必然要和网络先建立连接才能成为后者。

对于前者而言，对网络是完全陌生的，而网络的资源是有限的，哪些用户被挑中呢？人品决定。因为该过程是一个随机决定过程，即需要进行随机接入的过程。随机接入的过程随便找本书，几乎都讲烂了，。本处略去两百字。用户有可能有时运气不太好或人品不太好，偶尔出现网络特别忙的时候无法接入，等待几秒钟再重新尝试就好了。

如何为网络中已经建立连接的用户分配资源？这么多用户都需要资源，网络必然也不是瞎分，有一些基本原则是可以遵循的，通常理解上可以有：用户的待传数据量（BO），用户的数据的优先级别（QCI衡量），用户的信号质量（CQI上报以及网络对上行导频的测量）。以上因素将作为调度的一些关键衡量因素。
比如说，QCI的GBR业务，必然会优先保证资源。
可以想象，网络是在某个调度时刻，在网络中吼一声，谁要传输数据？想要传输数据的用户赶紧举手。网络将需要进行调度的用户进行优先级别排序，具有较高的QCI的用户通常被排在前面。若俩用户都是QCI较高的用户，那是否信道质量好的一定排前面呢？那就看采用什么策略了，这个时候就出来各种算法，经典的3种有轮询算法，最大载干比算法，正比公平算法等。给用户排好序后，网络就大体估计一下每个用户想要的资源：根据用户的缓冲区大小，以及GBR速率要求等。假设用户的某个业务GBR要求是64kbps。网络就大体就是算一下距离上次调度的时间，比方经过了1秒钟，那网络认为此时要给用户发送64kbit的数据才行。即所谓的令牌桶机制。若用户只想下个小文件，大约32kbit，则网络以这个最小值为准。
网络对用户一一走这么一圈，心里就有数了，开始给用户一一分配资源，直到系统的全部资源被分配完毕。轮不到的用户只能下一次调度机会来临。
该具体的分配过程，应该说每个每个公司的产品实现都不一样，而且极其复杂，不再一一细说。此处略去大约十万字。

还有一些通用的东西，即该流程外的这些边边角角的东西，都是为调度来服务的，我认为是每个公司的产品都用得着的东西，需要总结一下，即协议的东东。协议这个东西很特殊，虽然融入在产品当中，但又是凌驾在产品之上。因此把协议弄明白，基本在哪个公司做研发都不用愁。以后再慢慢讲解吧。

Helloamy2014

我的4G之路-原语，RLC和MAC之间的秘密

上回说到，在MAC进行资源调度后，给用户分配的就是一个传输块大小，并通知给用户。但用户拿到这个分配之后，他只知道在当前这个时间点，总共可以传输这么多数据，比方说给你一个64kbit的一个大篮子，但用户有多个业务在等着传呢，该如何决定该篮子装哪个数据呢？协议中写了一堆分配原则，何其之复杂。。。反正我每次看过，看了都必然会忘记。。。

但是如果将问题简化，其实就两步，最小化原则和最大化原则。假设高层有两个业务，一个FTP业务，一个视频业务，对应俩信道，假设视频优先级高。
第一步：最小化原则，即依次为俩信道分配资源；假设对于视频而言，此时有一个发包速率，即PBR(比特速率)决定的可以传输32kbit，则根据其待传送数据量和PBR取得最小值为其分配资源。此时篮子的容量将被一些视频占去，再塞一些FTP的数据。可见，采用该原则基本还是公平的，每个信道都至少被分配了一部分资源，没有谁被饿死。第二步，若分完后，还有资源，则按照最大化原则传输。按照优先级别，但此时做事有点极端，用湖南话说，就是以做死的节奏，首先放肆给视频分，直到其数据都被传输完或者篮子整个装满，分完再给第二个FTP分，也是直到其数据都被传输完或者篮子整个装满。

MAC做了这么一堆事情之后，假设64kbit的大篮子，算下来可以给信道1和信道2各装32kbit，此时他才会通知他的高层（RLC），即给他一个列表，信道1和信道2，各装32kbit的视频数据和FTP数据。RLC够懒的，他就照着做就可以了。因此就有了RLC协议中的这句话，RLC期望从底层MAC得到的服务是：notification of a transmission opportunity, together with the total size of the RLC PDU(s) to be transmitted in the transmission opportunity.（我要知道我何时传输数据，并告诉我传输多少）是不是一切都很明白了？

看来，标准中仅仅只有这么一句话，一带而过，为啥捏？因为这是MAC和RLC的层间交互，即原语。原语可不像协议一样写的那么清楚，都各家内部实现，就猜摸着做就行了。看来这看不到的秘密通道，其实还是挺复杂的吧？哈哈