<sup id="4s0we"><wbr id="4s0we"></wbr></sup>
<rt id="4s0we"></rt>

通信人家園

 找回密碼
 注冊

只需一步,快速開始

搜索

軍銜等級:

  四級通信軍士

注冊時間:
2014-11-11
161#
發表于 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
162#
發表于 2015-6-7 10:54:42 |只看該作者
本帖最后由 Helloamy2014 于 2015-6-7 10:55 編輯

先暫時放這么多.

軍銜等級:

  新兵

注冊時間:
2015-6-7
163#
發表于 2015-6-7 16:36:36 |只看該作者
樓主很猛啊

點評

Helloamy2014  不敢當啊  詳情 回復 發表于 2015-6-10 20:17

軍銜等級:

  四級通信軍士

注冊時間:
2014-11-11
164#
發表于 2015-6-10 20:17:16 |只看該作者
悠揚的風 發表于 2015-6-7 16:36
樓主很猛啊

不敢當啊

軍銜等級:

  四級通信軍士

注冊時間:
2014-11-11
165#
發表于 2015-6-10 21:30:18 |只看該作者
還有一篇BSR的問題補充,請在公共帳號察看!

軍銜等級:

  四級通信軍士

注冊時間:
2014-11-11
166#
發表于 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 (13.91 KB, 下載次數: 0)

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
167#
發表于 2015-6-10 21:57:35 |只看該作者
哎,這里編輯太費事了...

更多文章,請見我的公共weixin帳號

軍銜等級:

  新兵

注冊時間:
2008-10-25
168#
發表于 2015-6-15 16:28:16 |只看該作者
Helloamy2014 發表于 2014-11-14 21:53
我的4G之路-談總體架構   

首先從直觀上理解一下整個LTE系統的數據傳輸架構。先從有線網絡說起。當進行 ...

很好

軍銜等級:

  新兵

注冊時間:
2015-6-15
169#
發表于 2015-6-15 20:52:15 |只看該作者
贊,已關注微信

軍銜等級:

  四級通信軍士

注冊時間:
2014-11-11
170#
發表于 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
171#
發表于 2015-6-22 20:39:47 |只看該作者
最近還寫了幾篇其他文章,請見公共帳號。

軍銜等級:

  四級通信軍士

注冊時間:
2014-11-11
172#
發表于 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
173#
發表于 2015-6-28 20:50:46 |只看該作者
上邊圖片好像放不進去阿,具體見公共帳號吧.

點評

家園副管03  樓主好,外鏈圖片容易丟失,最穩妥的辦法就是圖片先上傳再使用~  詳情 回復 發表于 2015-7-30 00:51

軍銜等級:

  新兵

注冊時間:
2015-7-1
174#
發表于 2015-7-1 20:25:12 |只看該作者
你是妹紙啊,真厲害,持續關注

點評

Helloamy2014  是妹紙啊,哈哈,謝謝關注!  詳情 回復 發表于 2015-7-1 21:07

軍銜等級:

  四級通信軍士

注冊時間:
2014-11-11
175#
發表于 2015-7-1 21:07:39 |只看該作者
zccjqd 發表于 2015-7-1 20:25
你是妹紙啊,真厲害,持續關注

是妹紙啊,哈哈,謝謝關注!

軍銜等級:

  中士

注冊時間:
2012-11-30
176#
發表于 2015-7-6 15:21:22 |只看該作者
非常棒,謝謝lz分享

軍銜等級:

  四級通信軍士

注冊時間:
2014-11-11
177#
發表于 2015-7-11 16:06:27 |只看該作者
另外更新兩篇切換的文章,請直接在公共帳號察看.

軍銜等級:

  四級通信軍士

注冊時間:
2014-11-11
178#
發表于 2015-7-11 16:06:43 |只看該作者
7月份發起的是RRC系列

軍銜等級:

  四級通信軍士

注冊時間:
2014-11-11
179#
發表于 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
180#
發表于 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-9-18 11:00 , Processed in 0.125000 second(s), 18 queries , Gzip On.

Copyright © 1999-2019 C114 All Rights Reserved

Discuz Licensed

回頂部
影音先锋下载