【原創連載】 我的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個包裹。顯然，你需要收到從對方來確認消息，告知每個包的發送情況。對這種事情，顯然不需要你直接去麻煩對方老板啦，你就直接和對方的小助理打交道就行了。

你會怎么做呢？你首先聯系一個北京快遞調度總站，由他來幫你負責這幾個包裹幫你發送到對方小助理�？爝f調度總站會怎么做呢？快遞的生意也是很忙的，一天發貨量也就這么大，有些用戶可能都懶得搭理。我們假定你是VIP用戶，申請到了他的調度服務，他拿到了這5個包后，顯然得查一下，有沒有快遞公司可以服務�，F在的快遞公司，比方說，順豐在周一發貨，圓通在周二可以發貨，申通在周三發貨(各種通一一排列下去)...

于是包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之路”就可以了�？赡軜巧贤瑢W沒有搜索微信公共帳號吧。
我在微信上是分了兩個板塊，技術版和非技術版。非技術版主要是自己的感悟，就不會放在該處發表了。有興趣的同學可以查看。
或者有建議，請直接加我私人微信帳號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的層間交互，即原語。原語可不像協議一樣寫的那么清楚，都各家內部實現，就猜摸著做就行了�？磥磉@看不到的秘密通道，其實還是挺復雜的吧？哈哈