• 通信人家園

    標題: 【原創連載】 我的4G之路(9月5日連載:240#更新)  [查看完整版帖子] [打印本頁]

    時間:  2014-11-14 21:50
    作者: Helloamy2014     標題: 【原創連載】 我的4G之路(9月5日連載:240#更新)

    我的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中的SRBSR
    我的4G之路-BSR補遺(一)
    我的4G之路-考考你的數學水平, MAC的組包
    我的4G之路-你和女神之間,論PcellScellTA超時
    我的4G之路-切換時用戶在做什么?
    我的4G之路-漸行漸遠,為什么你就是搞不定331?
    我的4G之路-最悲傷的事情莫過于賺過,論RRC連接重建

    時間:  2014-11-14 21:53
    作者: 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的調度
    時間:  2014-11-15 21:47
    作者: 家園副管09

    占樓,歡迎樓主繼續~
    時間:  2014-11-17 11:55
    作者: 阿炳0513

    持續關注,正在做這方面課題
    時間:  2014-11-17 12:57
    作者: lph_2000

    贊,早已關注LZ微信
    時間:  2014-11-17 13:01
    作者: landai

    搬個板凳關注
    時間:  2014-11-17 13:02
    作者: landai

    lph_2000 發表于 2014-11-17 12:57
    贊,早已關注LZ微信

    LZ的微信ID是什么啊?偶也關注學習一下
    時間:  2014-11-17 17:32
    作者: hualong95

    持續關注中
    時間:  2014-11-17 17:53
    作者: goon2005

      通俗易懂
    時間:  2014-11-18 09:31
    作者: milo4sun

    一直很喜歡看這種通過具體例子來講述通信協議的文章,覺得通熟易懂
    時間:  2014-11-18 14:37
    作者: lph_2000

    landai 發表于 2014-11-17 13:02
    LZ的微信ID是什么啊?偶也關注學習一下

    就是我的4G之路
    時間:  2014-11-18 14:58
    作者: 佳恒工程師

    好文
    時間:  2014-11-18 15:38
    作者: landai

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

    這個搜索不到啊
    時間:  2014-11-18 22:45
    作者: 平凡中落魄

    MARK一下:)
    時間:  2014-11-19 12:31
    作者: lph_2000

    landai 發表于 2014-11-18 15:38
    這個搜索不到啊

    那你問問樓主
    時間:  2014-11-19 15:15
    作者: AAlexx

    好東西,寫得很直白。
    時間:  2014-11-19 18:30
    作者: 胡胡10086

    怎么沒有下文了!
    時間:  2014-11-19 21:24
    作者: Helloamy2014

    本帖最后由 Helloamy2014 于 2014-11-19 21:36 編輯

    大家好,因為最近比較忙,所以有點慢.
    樓上有同學問如何關注,在微信公共帳號中搜索“我的4G之路”就可以了。可能樓上同學沒有搜索微信公共帳號吧。
    我在微信上是分了兩個板塊,技術版和非技術版。非技術版主要是自己的感悟,就不會放在該處發表了。有興趣的同學可以查看。
    或者有建議,請直接加我私人微信帳號319137103。注明“我的4G之路”即可,我可以更快看到大家反饋
    時間:  2014-11-19 21:31
    作者: Helloamy2014

    我的4G之路-談調度

    上回提及到MAC的主要功能是負責調度,即負責進行資源的分配。可以直觀上將用戶分為兩類,一類網路未建立連接的用戶,即網絡壓根不認識的用戶。一類是已經和網絡建立連接的用戶。前者必然要和網絡先建立連接才能成為后者。

    對于前者而言,對網絡是完全陌生的,而網絡的資源是有限的,哪些用戶被挑中呢?人品決定。因為該過程是一個隨機決定過程,即需要進行隨機接入的過程。隨機接入的過程隨便找本書,幾乎都講爛了,。本處略去兩百字。用戶有可能有時運氣不太好或人品不太好,偶爾出現網絡特別忙的時候無法接入,等待幾秒鐘再重新嘗試就好了。

    如何為網絡中已經建立連接的用戶分配資源?這么多用戶都需要資源,網絡必然也不是瞎分,有一些基本原則是可以遵循的,通常理解上可以有:用戶的待傳數據量(BO),用戶的數據的優先級別(QCI衡量),用戶的信號質量(CQI上報以及網絡對上行導頻的測量)。以上因素將作為調度的一些關鍵衡量因素。
    比如說,QCI的GBR業務,必然會優先保證資源。
    可以想象,網絡是在某個調度時刻,在網絡中吼一聲,誰要傳輸數據?想要傳輸數據的用戶趕緊舉手。網絡將需要進行調度的用戶進行優先級別排序,具有較高的QCI的用戶通常被排在前面。若倆用戶都是QCI較高的用戶,那是否信道質量好的一定排前面呢?那就看采用什么策略了,這個時候就出來各種算法,經典的3種有輪詢算法,最大載干比算法,正比公平算法等。給用戶排好序后,網絡就大體估計一下每個用戶想要的資源:根據用戶的緩沖區大小,以及GBR速率要求等。假設用戶的某個業務GBR要求是64kbps。網絡就大體就是算一下距離上次調度的時間,比方經過了1秒鐘,那網絡認為此時要給用戶發送64kbit的數據才行。即所謂的令牌桶機制。若用戶只想下個小文件,大約32kbit,則網絡以這個最小值為準。
    網絡對用戶一一走這么一圈,心里就有數了,開始給用戶一一分配資源,直到系統的全部資源被分配完畢。輪不到的用戶只能下一次調度機會來臨。
    該具體的分配過程,應該說每個每個公司的產品實現都不一樣,而且極其復雜,不再一一細說。此處略去大約十萬字。

    還有一些通用的東西,即該流程外的這些邊邊角角的東西,都是為調度來服務的,我認為是每個公司的產品都用得著的東西,需要總結一下,即協議的東東。協議這個東西很特殊,雖然融入在產品當中,但又是凌駕在產品之上。因此把協議弄明白,基本在哪個公司做研發都不用愁。以后再慢慢講解吧。
    時間:  2014-11-22 10:01
    作者: 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的層間交互,即原語。原語可不像協議一樣寫的那么清楚,都各家內部實現,就猜摸著做就行了。看來這看不到的秘密通道,其實還是挺復雜的吧?哈哈

    時間:  2014-11-22 10:26
    作者: Helloamy2014

    我的4G之路-MAC的組包

    上回說到:MAC已經明確告知了RLC該如何發送數據了。假設此時這個640bit數據塊上可以想要放置RLC的兩個信道的兩個包,分別是320比特,則RLC收到該信息之后將按照自己當前的待發送數據,塞入這個數據塊中(因為RLC打包的過程還挺復雜的,因此后頭會細講)。必然塞的數據是不能超過總的這個640大小的包的,而此時RLC還需要謹慎預留MAC的頭大小。假設RLC把這個事情做完了,他將告訴一下MAC層說over了。

    對于MAC層而言,相當于他之前往高層扔了一個空籃子,這會得到籃子里是滿滿的禮物了。但這些禮物都還是未包裝的。MAC還得自己包裝呢。MAC此時需要包裝兩個禮物包,對第一、二個禮物打包(包裝上寫明是信道1、2,長度多長)。注意:此時對于第二個包而言,是無需指明長度了(總大小減去第一個包大小)。我們可以考慮一下包裝紙上該怎么填(MAC子頭),包裝紙也是需要占用空間的。包裝紙上要寫的信息是:要用5個bit來表明哪個信道,而用7或者15個bit來表明長度。因此在MAC中存在3種包裝紙( MAC子頭 ):
    1)2個字節的MAC子頭:大體是5bit信道指示+7bit長度指示
    2)3個字節的MAC子頭:大體是5bit信道指示+15bit長度指示
    3)1個字節的MAC子頭:大體是5bit信道+無需長度指示(比方最后一個包以及用于指明各種特定用途的包,即MAC控制PDU)

    因此在上文的例子中,是有兩個禮物包被包裝后串接起來,就看到這個樣子了:
                MAC包=  子頭1(2字節,假設禮物不是太大,7bit足以指示長度)+MAC數據包1+子頭2(1字節)+MAC數據包2
    當然若高層發來的禮物過小,塞不滿籃子,就只能打一些padding了。
    經過以上過程MAC已經準備好這個待傳遞的包了,此時他也知道該包裹即將在哪些資源上發送。看來只欠東風了。還記得我們之前說到的,數據其實是在HARQ進程上發送,類似于不同的快遞公司嗎?接下來就是尋找不同的快遞公司即HARQ進程了。

    To be continued, MAC對上下行HARQ進程管理
    時間:  2014-11-22 10:29
    作者: Helloamy2014

    公共帳號更新更快,以往的歷史文章,感興趣的同學可在公共帳號中輸入help,然后再根據題目一一回復察看
    時間:  2014-11-23 09:34
    作者: Helloamy2014

    我的4G之路-下行HARQ

    之前,我們提及到HARQ就類似于一個快遞公司,但是它比現實中的快遞公司可要靠譜多了。
    現實中,你的包裹交給快遞后,若快遞給弄丟了,最多賠點錢,再給點精神安慰。但在我們4G系統里,這個快遞提供的是更人性的服務。

    想像你所處的位置是RLC層,你有一個包,交給快遞公司讓他幫你從北京發送到上海的RLC層,即你的收件人。

    北京快遞公司在拿到你的包后,先不著急傳。他會首先將包在傳送之前進行多次拷貝,形成不同的版本(RV版本)。

    我們可以簡單理解對方收到每個版本都可以解析得到該包。假設北京快遞分公司傳送一個包到上海分公司,若對方一看,該包裹完好無損,則皆大歡喜,快遞公司提交給你的收件人,同時給北京的快遞分公司一個反饋,整個過程就完了。

    但是若上海快遞一看,該包有損害了,可能路途遙遠,這個包已經慘不忍睹,有幾個角給刮去了一大塊,他也不會急著將該受損的包的丟棄。他會先告訴北京的快遞公司進行一次重傳,于是北京的快遞公司將發送一個新的版本過來,上海的快遞公司會將兩次的傳輸結果進行合并,看能否拼接成完整的數據包,即HARQ中的Chase combing原理。

    通常情況下,若信道確實比較差,多次合并,也無法讓對方收到完整的包,快遞公司也無能為力了。也只能是你的收件人打電話過來,讓你親自出馬再重新去進行快遞了。也就是說,若HARQ層無能為力,丟包只能由更高層即RLC層出馬了。

    我們假設一個周期為10天,分為周天即周0,周1、周2、…周9,下一個周期以此進行。

    接下來,我們僅考慮從北京到上海這一個方向上。
    假設一個很有趣的事情是:北京快遞公司比較迷信,他找個大仙,掐指一算,周2、周3、周7、周8不宜發快遞,只適合收(包括快遞和反饋信息)。
    他在周0發送了一個快遞到上海,路上經歷了一天,上海的快遞公司辦事效率也很成問題,解析包就解析了2天,一看已經周4了,也要等到周7北京可以收的時候,再給一個反饋過去。北京的快遞公司在周7收到后,又用了一天弄明白對方的反饋要重傳數據,于是花了兩天組了一個重傳包,打算在下一個周期的周1或者更晚再發送。

    于是乎,假設北京快遞公司就做著這一單生意,這11天里面,除了周0發送,周7得到反饋,再下一周期的周1再發重傳包,至少我們可以看到,其實這11天里,大部分時間都啥都不做,不餓死才怪呢。
    于是,他要找點活干,在周0發送了一個包后,他會在周1,周4,周5,周6,周9,以及下一周期的周0,全都忙活起來,每天打一個下行包發送。

    以上例子中:
    周0到周9即TDD系統中的典型DSUUDDSUUD的配置;
    周2,周3,周7,周8為上行時隙,而其他為下行時隙;
    周0發送一包,周7收到反饋,再到下一次包發送,即發送和反饋一個來回時間,即為RTT;
    一共可以連續發送7包,即下行方向上7個HARQ進程。

    可能有同學已經注意到了,快遞公司是有苦衷的,他連續排這么多進程,其實原因在于他從第一包發出到第一個包,中間時間拖得太長了,整整11天呢,一方面是因為處理不力有時延,但一方面也和這個時隙有關。比方說,上海要發送反饋到北京的時候,已經周4了,他也必須等到周7,北京方面可以接收的時候才反饋。因此和上下行時隙配比有有很大關系的。

    唉,誰讓TDD系統就這么設計呢,將馬路進行了限號,因為資源本身就窄,就一個單行道,不像FDD系統,財大氣粗,倆馬路,一個上行,一個下行,想什么時候發就什么時候發,必然其RTT時間就要短的多了(固定8ms)。
    TDD系統因為比較窮,只能這么精打細算了。關于TDD和FDD系統的孰優孰劣問題,就不再此討論了,至少出租車的司機就更愿意接入聯通網絡,而非移動網絡,可以更快搶單!
    時間:  2014-11-24 20:23
    作者: DAAI6

    你好,我是燕大計算機專業研二學生,畢業打算去聯通或電信(移動進不去)工作,想用在校的半年到一年的時間做些準備。我對這個行業不是很了解,能否指點一下我可以去那些部門工作,我需要準備什么,謝謝。
    時間:  2014-11-24 21:11
    作者: Helloamy2014

    回復樓上:
    首先非常感謝樓上小同學的關注!
    我也不是非常肯定你是否能夠讀懂我的文章!哈哈,希望我寫的足夠簡單!
    如果你想要在通信行業的話,我覺得首先你可以做的事情是,找到一些師兄師姐在這個行業的,問問他們一些情況。在知識積累方面,我不建議你閱讀一些LTE原理的書,你可以讀一些通俗易懂的。比方說我最近在讀的王建宙的《移動時代生存》,里面講了移動和聯通的發展史,也講了一點點技術方面。你要是可以等等的話,我可以讀完,快遞給你。
    其他的貌似有本入門技術類的,叫《大話無線通信》,寫得還不錯。
    時間:  2014-11-24 21:11
    作者: Helloamy2014

    回復樓上:
    首先非常感謝樓上小同學的關注!
    我也不是非常肯定你是否能夠讀懂我的文章!哈哈,希望我寫的足夠簡單!
    如果你想要在通信行業的話,我覺得首先你可以做的事情是,找到一些師兄師姐在這個行業的,問問他們一些情況。在知識積累方面,我不建議你閱讀一些LTE原理的書,你可以讀一些通俗易懂的。比方說我最近在讀的王建宙的《移動時代生存》,里面講了移動和聯通的發展史,也講了一點點技術方面。你要是可以等等的話,我可以讀完,快遞給你。
    其他的貌似有本入門技術類的,叫《大話無線通信》,寫得還不錯。
    時間:  2014-11-24 21:17
    作者: Helloamy2014

    我的4G之路-DRX

    上回以快遞的例子對下行方向進行了描述。在一個周期為10天里,上海的快遞何以知道哪天會有從北京過來的快遞呢?很簡單,他非常了解北京快遞的發送時間,即在除去周2\3\7\8的這四天會發送,就在這些天里,每天都搬把椅子去馬路邊等著就行了。但是,如果北京方向要發送包正好是生日禮物呢?對于這種頻度,一年一次的包,用湖南話說,上海快遞每天都去這么放肆等,那豈不是脖子都望斷了?


    在我們的4G網絡中也是同樣道理:若高層要發送包是我們的QQ或者微信業務呢?使用即時通信軟件的都知道,聊QQ或者wechat,其實就是無聊的時候有一搭沒一搭問問話,尤其地鐵上沒事干的時候。我的心理學老師說,男生給女生發微信聊天,很大程度上不是感情的表示,而是表示:他很無聊,因為地鐵沒到站!(男生們別拍我!)。無聊的對話,可能地鐵門一開就結束。其他的時間就是為了對QQ信道的檢測,騰訊公司在發送的一種周期性檢測信令,看用戶是否還在線。對于有線網絡而言必然沒有問題,因為電腦后面都有插線板,但要搬移到空口,對于應用層之下的無線網絡可慘了,因為他幾乎都是以每下行子幀的頻率,即每毫秒的頻率去檢測空口信道,手機其實還是蠻耗電的。


    為了用戶的省電,我想說,其實運營商還是很下功夫的。最初的DRX(非連續接收)的引入。DRX在協議上定義就是一連串的定時器,剛開始看還挺復雜。以下一個人和人之間交往的例子可以形象說明該問題。假設你和你的好友,基本也不咋不聯系(想想你和你大學同學多久沒聯系了?),估計也就100天中打一天電話,其余時間基本歇菜,但是比如你在打完這一天電話到三更半夜,剛掛,你朋友又給你打電話了,表示發生了啥郁悶事情,求安慰,于是你們連續講了兩天,把電話打爆。后來,如果你人品比較好,為表示關心,你又每隔20天,又打電話跟進,問問對方情況。跟進3次之后,又回復到之前的很少聯系狀態。和DRX對應上:
    100天:長周期,
    每周期里面的固定一天聯系:onDuration定時器;
    臨時加上的這個把電話打爆的2天:非激活定時器
    發生急事之后每隔20天:短周期
    后續跟進次數3次:drxShortCycleTimer

    看到這里就明白了吧?長短周期就是反應當下鏈路的活動狀態。長周期意味這低活動態,短周期意味這高活動態。長周期是一個baseline的設置,而短周期則是和人品有關,可配可不配。君子之交淡如水,也許這才是人生常態吧!若連續收到數據,即進入短周期(若配置了的話)。一段時間不進行數傳,即短周期幾次后超時后進入長周期。一切又恢復平靜。
    其他還有重傳定時器以及HARQ回程時間定時器因為比較簡單就不介紹了。
    時間:  2014-11-25 19:57
    作者: supgz

    怒贊!!
    如果我剛開始入門LTE時有這么一篇文章學起來肯定會快很多
    協議通常都是講要怎么做
    但是入門的時候通常最想先弄清楚要做什么
    所以開始學協議尤其是沒有通信行業經驗的人看協議那叫一個折磨
    時間:  2014-11-25 21:44
    作者: Helloamy2014

    回復樓上:
    有興趣的話,歡迎一起寫!我一個人忙不過來啊

    時間:  2014-11-25 21:57
    作者: Helloamy2014

    今天發表一篇非技術文章.本來是放在我的公共帳號的非技術版,但今天放過來,也許會改變有些人的想法.

    我的4G之路-我為什么要付出120%的努力?

    記得之前和別人聊過天,聊及加班很多,工作很辛苦。總是會有人說,你加那么多班干什么?加班只能說明你辦事效率太低。Wait,我覺得可能辦事效率乃至整個團隊的效率是一方面需要提升,但一方面加班這件事情對于我們這個行業來說,可能也是迫不得已,如果你想要做好的好。

    通常進入我們這個行業的,大家都拿著名校光鮮的文憑,大家都很聰明。完成一個工作,其實一天只需要付出6小時,但是你要讓老板滿意,就得花費10個小時,若是要讓超出領導預期,就得付出12小時。這多余的時間的付出,曾經讓我也無法理解。

    去年,我們小團隊負責一個小項目,初看,現有技術比較成熟了,感覺就是上上網搜搜資料,拷貝+剪切就可以完成一個報告交差。但是我總覺得不對勁。那時,我正好在讀杰克.韋爾奇的《贏》,書中談及這樣一個例子,就是作者最初工作的時候,只是一個普通員工,有一次,公司大領導到訪,要求提供一份材料描述一下公司的產品,于是他在原有工作的基礎上,又去做了很多研究,還研究了競爭對手的產品,最后還分析了公司戰略布局,該文檔最后讓領導們大為吃驚。
    受這一啟發,我也開始采用更寬的思路,嘗試從國內和國際的專利入手。該轉變讓我發現了新的東西,因為baidu上找到的東西,人人都能找到,幾乎無價值。而且,我還嘗試聯系該項目相關的互聯網公司,給他們發送郵件,詢問他們的項目進展。讓我吃驚的是,只是在網絡上隨便搜索到的聯系方式,他們竟然給我詳細的郵件回復,并介紹了業界遇到的問題。可以說,為了這個報告,我們小隊加班完成自己額外增加的任務,真的付出了120%的努力。

    到這個報告成型評審的時候,領導說,從來沒有團隊像你們這么積極,沒有想到你們把這個報告寫的這么全面,以后有新項目會優先考慮你們。可以想像,我們當時好開心啊。突然覺得付出的加班很值得。其實,更多的付出意味著你reputation,以及更多機會。

    而這樣有強烈責任心,主動付出的人有很多很多。上周我們的Toastmaster 海淀大講堂,Steve作為演講嘉賓。我對他的演講內容反倒不是那么有興趣,我感興趣的反而是他的職場道路。我親眼看到他從公司的測試人員到高級測試,到現在的一個國際IT公司經理,我問他如何成為一個好的測試人員。他說,讓領導滿意,付出120%的精力。這句話讓我印象深刻!

    從這一件事情上,我體會到,我們是否應該盡量變得更加主動?不要再問自己為什么加班?而去問問自己有沒有付出120%的努力,在公司得到收獲的時候最重要的是自己有沒有得到收獲?

    我的心理學老師說,我們習慣了為他人做事,卻不懂得為自己而努力,所以個人魅力都膚淺,因為個人魅力需要沉淀和積累。我覺得這句話深刻體現了主動和被動的區別所在。

    所以對你的工作,你應該會像我一樣,有不一樣的看法了。
    時間:  2014-11-25 22:07
    作者: Helloamy2014

    TO:家園副管:能否教我每次把標題更新一下?
    還有,我給你留言了,請看一下,謝謝哦
    時間:  2014-11-26 09:01
    作者: cyberblog

    好家伙,學得比較細啊!
    時間:  2014-11-26 17:00
    作者: airluck

    to be continued
    時間:  2014-11-26 17:57
    作者: 蒙對@gu

    學習。
    時間:  2014-11-26 21:31
    作者: Helloamy2014

    我的4G之路-DRX PK 都教授


    男神鎮樓,不解釋!

    DRX這個東西看著這么好,如何在現網中應用的呢?DRX是否就是萬全之策呢? 運營商算盤打得可精了。DRX雖然省電,但可能導致用戶投訴。假設用戶正處于高鐵上,在兩個小區的邊緣,信號原本就差,本來來指望這趕緊收到網絡下發的切換命令,趕緊進行切換,但因為DRX的設置,無法收到切換命令,導致掉線。再說,DRX的用戶雖然大部分時間都在休眠,平時不占用系統的資源,但一旦切換發生,就立刻醒過來,切換也得進行,切換一個來回,信令開銷也大。運營商都是很摳門的,盤算了一下,要不干脆包發送完了,就釋放用戶,有了包再建立新的鏈路,這樣對于高速用戶豈不是更好?盤算來盤算去,到底好多少?

    于是乎全球最大運營商中移動當然很在意這個事情。因為中國人不喜歡當面喝咖啡,而喜歡聊QQ啊。于是CMCC在3GPP啟動新的立項,大家都需要提供仿真數據說話。話說,當時的這個仿真項目,做的可是干勁朝天。
    首先是業務源。要知道QQ類業務可是不同于經典的業務模型,那就是包的到來和結束不靠譜。我的心理學老師說,聊天工具其實是一種非對等的通話模式,任何一方都可以說,我有事先下了,來單方終止談話。那該咋整呢?辦法總是有的,就是中移動在某個現網中抓取一段QQ聊天記錄,大家按照該記錄來產生業務源。接下來,就是仿真仿真,再仿真。唉,想當初,這是俺在新公司的第一個項目,加班都加到吐啊,簡直是苦不堪言的日子啊。其它公司,估計也都差不多,大家都是用繩命在為運營商和用戶的體驗努力啊!

    但是,但是,用戶是怎么看待省電這個事情呢?用戶才不care呢。
    俺記得,春節來后幾周,某有名韓劇更新了,在公交車站,俺旁邊一大媽,拿著個寬屏手機,聲音外放的那種,就聽見女主在歇斯底里喊男主來救她,瞄了一眼,就是女主開著車,剎車失靈,奔向懸崖(接下來發生啥大家都知道啦)。等我到中關園倒地鐵去西土城,在地鐵里,旁邊倆妹紙,都是寬頻手機,開著極大音量,瞄了一眼,一個屏幕出現的又是該男主360度無死角的顏,一個屏幕出現的是該男主又細又長的腿,讓美腿控的我心服口服。依這個花癡的程度,可能手機的電量幾個小時就全耗光了,在QQ類業務為用戶省下的一點點電,比起都教授的魅力,又算什么呢?

    DRX 要和都教授PK,顯然用戶更Care后者,后者完勝!所以,運營商和設備商也只能自我安慰說,此業務和彼業務不同嘛,如果對于QQ類業務,能夠省一點就省一點咯,視頻類業務就管不著那么多,讓用戶花癡去吧。
    時間:  2014-11-26 21:33
    作者: Helloamy2014

    難道圖片不能直接插入嗎?
    時間:  2014-11-26 21:43
    作者: Helloamy2014

    怎么回事?無法更新了....
    時間:  2014-11-27 11:22
    作者: DAAI6

    Helloamy2014 發表于 2014-11-24 21:11
    回復樓上:
    首先非常感謝樓上小同學的關注!
    我也不是非常肯定你是否能夠讀懂我的文章!哈哈,希望我寫的足 ...

    謝謝樓主回復,您的文章我每篇都認真讀過了,多數都讀懂了;同時謝謝樓主推薦的書,我會認真看看的。期待樓主多發點文章,指點迷經。
    時間:  2014-11-27 21:19
    作者: esgx001

    感覺樓主的例子很通俗!!支持一下
    時間:  2014-11-27 21:26
    作者: 蒙對@gu

    Helloamy2014 發表于 2014-11-24 21:11
    回復樓上:
    首先非常感謝樓上小同學的關注!
    我也不是非常肯定你是否能夠讀懂我的文章!哈哈,希望我寫的足 ...

    每天都看
    時間:  2014-11-27 21:36
    作者: Helloamy2014

    感謝樓上,對我也是巨大的鼓勵!
    時間:  2014-11-27 21:42
    作者: Helloamy2014

    本帖最后由 Helloamy2014 于 2014-12-15 21:56 編輯

    54-14012F91936.jpg
    我的4G之路-如果你想尋呼都教授(一)


    在提筆的時候,又想到某韓劇。在現在智能手機爛大街的情況下,男主依然使用的是一個BB機,隨叫隨到。俺當時一直很好奇,這種尋呼系統應該是屬于1G,2G or 3G?在斯密達電信行業如此之發達,用上4G的情況下,為了表現男主的復古風,就得給他單獨設立一個復古的通信系統。后來,男主終于用上了智能手機,so far so good,只是遇到開機手勢密碼的時候遇到點困難(話說,我一直認為開機手勢密碼真的是很有創新的一項專利)。

    但不管屬于哪種通信系統,都會面臨尋呼的問題。因為手機也不會是時時刻刻都在聽尋呼信道,為了省電,手機采用的是上次說的DRX,即非連續接收的方法,也就是說,我們的手機大部分情況下是處于睡眠態,而只有在特定的時間點才去聽尋呼消息。設想,網絡有這么多手機,只有當他們按照一定的規則在不同的時間點去聽尋呼消息,這樣大家才不至于都一窩蜂撞在一起。

    問題來了:假設一個月有32天(0~31),每隔一天發送一次尋呼消息,一天又有10(0~9)小時,僅在第一個小時發送尋呼消息。男主的手機號碼是0000030,請問如果你在遇到危險情況,想打電話讓他來拯救你,那他會在那一天具體什么時間點收到你的尋呼?兩種截然不同的答案:

    通信妹紙:首先,將全網用戶按照其電話號碼均分在一個月有尋呼的16天里。假設我們網絡中有32個用戶,其電話號碼分別為000000-000031,那用戶0和用戶16被安排在第0天尋呼,而男主則和000014在同一天被尋呼,即安排在第28天。再看具體是哪個小時,因為這里只有一個小時,所以答案就是將在第30天的第一個小時,他將收到你的尋呼消息。
    若他手機信號不好,沒有收到你的尋呼消息,那他將在下個月的月末再收到你的尋呼。。。。

    文藝的美女們聽不下去,這么長的時間,黃花菜都涼了,你難道不知道他會預感未來,并且會瞬間移動嗎?

    所幸的是,我們的4G系統中,一天是以10ms來算,一共有10個1ms。以上其實就是以一個具體的例子來說明尋呼時刻如何計算。其實是在304有詳細規定。但當時俺還是看到很崩潰的,因為他給出來就是一堆公式,而我需要在幾個小時內將問題看明白。所以說,尋呼的時刻也是讓我崩潰的時刻。

    文中寫的是:
    根據下面公式求得PF(尋呼幀):
    尋呼幀位置 PF = SFN mod T= (T div N)*(UE_ID mod N)
    其中 SFN:系統幀號,當前UE所在幀號;
    T為尋呼周期,N:N=min(T,nB),nB從SIB2中讀取,為尋呼密度;
    UE_ID: 包含在S1的尋呼消息中,通過IMSI模1024計算得到。
    根據下面公式求得PO(即尋呼幀中具體哪個子幀):通過NS與I_s對應關系獲取:

    Ns
    PO when i_s=0
    PO when i_s=1
    PO when i_s=2
    PO when i_s=3
    1
    0
    N/A
    N/A
    N/A
    2
    0
    5
    N/A
    N/A
    4
    0
    1
    5
    6

    其中:Ns:Ns =max(1,nB/T),其中nB為尋呼密度;
            i_s :i_s = floor(UE_ID/N) mod Ns。

    初看一頭霧水,俺都冒冷汗了。。。
    幸好有個對教授的尋呼例子,其實和公式是這么對應的:32即對應了T,nB=1/2T,即尋呼密度為1/2,即意味著每隔一個無線幀有一次尋呼機會,即只會在偶數幀發送尋呼消息。N=min(T,nB)=16,即意味著對于一個尋呼周期中,共有16次傳輸機會,用戶則按照UE_ID mod N的原則分散到不同的無線幀。再尋找對應的子幀:Ns =max(1,nB/T)=1,意味著總共有幾個尋呼時刻,然后再將用戶取模,分散到不同的尋呼時刻。在該例子中,在該無線幀中僅有一個無線子幀被配置為下行,即在subframe=0的位置。用戶只能在該0子幀進行尋呼消息監聽。

    其實要說明就是這么回事。突然覺得迷霧撥開,一切又像北京的藍天一樣清晰起來。

    總結一下,其關鍵點就是要把用戶分散在不同的無線幀,再分散在不同的子幀。這樣,用戶和網絡都按照同樣的規則來解讀,就不會有問題了。同時假設在一個尋呼消息里,可以放16個用戶,那可以算出來,對于T=32,尋呼密度為1/2,最大也就可以支持16*16個用戶。因此網絡規劃需要考慮到尋呼容量。

    至于N=min(T,nB),以及Ns =max(1,nB/T),這些取大取小,看得很頭痛,其實代表了一定物理含義。
    要睡覺了,沒時間了,答案下期再揭曉吧。


    附件: 54-14012F91936.jpg (2014-11-27 21:41, 171.6 KB) / 下載次數 10
    http://www.ga336.com/forum.php?mod=attachment&aid=MjUwMzUzfDhhZGU3ODMwfDE1Njg2MDIyMDB8MHww
    時間:  2014-11-28 13:55
    作者: coffeeincafe

    樓主語文學的不錯,描述的簡單易懂。
    時間:  2014-11-28 17:07
    作者: 120097730

    Helloamy2014 發表于 2014-11-25 21:57
    今天發表一篇非技術文章.本來是放在我的公共帳號的非技術版,但今天放過來,也許會改變有些人的想法.

    我的 ...

    很好的心得。很久之前看的贏了,真的受益匪淺,從工作態度上到一些管理學知識,都很實用。
    mark了你的文章,抽時間拜讀。
    時間:  2014-11-29 11:24
    作者: 水上的風箏

    樓主V5,這個是好東西啊!!期待樓主持續更新
    時間:  2014-11-30 19:34
    作者: goon2005

      真是的經歷!
    時間:  2014-12-1 21:06
    作者: Helloamy2014

    tt (1).png
    我的4G之路-尋呼時刻(2)

    上回賣了一個關子,就是N=min(T,nB),以及Ns =max(1,nB/T)的物理含義。
    話說,當我看到這些公式的時刻,那種痛苦的心情無以形容。在內心里,我狠狠罵了罵自己,沒事選啥通信專業啊,搞得這么這么無聊!

    所以說,尋呼時刻,也是讓我崩潰的時刻。

    但終歸得冷靜下來,分析問題:
    一切都得從尋呼密度說起:
    nB: 4T, 2T, T, T/2, T/4, T/8, T/16, T/32.
    假設T還是取為32個無線幀,則:
    4T:意味著其尋呼密度為4,即每個無線幀都有尋呼,尋呼消息在0、1、5、6發送;
    2T:意味著其尋呼密度為2,即每個無線幀都有尋呼,尋呼消息在0、5發送;
    T:意味著其尋呼密度為1,即每個無線幀都有尋呼,尋呼消息僅在0發送;
    1/2T:意味著其尋呼密度為1/2,即每間隔無線幀都有尋呼,尋呼消息僅在0發送;
    1/4T:意味著其尋呼密度為1/4,即每隔4個無線幀都有尋呼,尋呼消息僅在0發送;
    1/8T:意味著其尋呼密度為1/8,即每隔8個無線幀都有尋呼,尋呼消息僅在0發送;
    T/16, T/32也是基于同樣原理。

    從以上幾乎已經能夠看出端倪:
    既然N=min(T,nB)意味著尋呼幀,那自然不管對于多大尋呼密度,也只能是每個無線幀都有尋呼,即為T=32,意味著每個無線幀都是尋呼幀,而對于nB密度小于1的,尋呼無線幀就更加稀疏。
    對于Ns =max(1,nB/T)則意味著在一個尋呼幀中有幾個尋呼時刻,不管對于多小的尋呼密度,都至少存在一個尋呼時刻。譬如,對于nB=4的,尋呼時刻可以有4個,而對于nB小于1的,尋呼時刻也至少為1個。

    因此為什么取大取小,其實是完全是以上場景推倒出來的啊,并沒有特別的來源。拿筆算一下就知道啦!

    所以,各位通信妹紙們,不管工作讓你多抓狂,一定要學習封面圖片中男神在收到女主尋呼消息時的淡定。。。場面一定要hold住!


    附件: tt (1).png (2014-12-1 21:05, 253.97 KB) / 下載次數 0
    http://www.ga336.com/forum.php?mod=attachment&aid=MjUwNTc0fDRlNTU4NGNjfDE1Njg2MDIyMDB8MHww
    時間:  2014-12-1 23:45
    作者: hl44112000

    學習了
    時間:  2014-12-2 10:23
    作者: relight

    Helloamy2014 發表于 2014-11-22 10:26
    我的4G之路-MAC的組包

    上回說到:MAC已經明確告知了RLC該如何發送數據了。假設此時這個640bit數據塊上可 ...

    寫的真好。贊~~
    mac對于超過大小的包還需要拆分嗎?
    時間:  2014-12-2 11:14
    作者: etl

    樓主能否介紹一下LTE核心網應該看哪些資料,具體的協議應該為哪些?
    時間:  2014-12-3 09:39
    作者: 小花開

    贊~\(≧▽≦)/~
    時間:  2014-12-3 09:40
    作者: 小花開

    期待樓主持續更新
    時間:  2014-12-4 20:16
    作者: Helloamy2014

    etl 發表于 2014-12-2 11:14
    樓主能否介紹一下LTE核心網應該看哪些資料,具體的協議應該為哪些?

    ...俺對核心網不了解阿....
    時間:  2014-12-4 20:25
    作者: Helloamy2014

    relight 發表于 2014-12-2 10:23
    寫的真好。贊~~
    mac對于超過大小的包還需要拆分嗎?

    我理解,高層應該不會組包超出授權的TB大小.
    但不是很確定,我再確認一下
    時間:  2014-12-4 20:27
    作者: Helloamy2014

    我的4G之路-你吼也沒用,論無線鏈路的失敗
    對著電話吼.jpg

    經常發現某些人貓著腰在某個角落里對著電話狂吼:
    ”什么??“
    ”紫薇你大聲點說,我聽不見!“
    ”哎呀,電話怎么又斷了!!"

    我都會在旁邊碎碎念,大哥,你的臉熱不熱啊?這是第幾次斷了啊?能否換個地方打啊?

    唉,對于我這種唐僧似的職業反應其實是有原因的。瀑布汗!
    首先要說明的是 ,要維持一定的鏈路質量,是有功率控制機制的。在上行方向上,網絡一旦檢測到手機的信號差,將會給手機發送要求其增大發射功率的指令。給用戶的直接影響是,手機打一會兒電話就熱得發燙,這個時候手機也會費電很嚴重。
    所以在手機信號不好的時候,還是盡量要長話短說。否則手機的輻射可是直接對著你的腦袋的,你就想象一下你的大腦此時在成倍吸收無線信號,臉發燙和頭疼是正常的,尤其是現在靠臉吃飯的年代更加桑不起啊。

    在無線信號不好的地方,即便手機非常發燙,但通話還是會隨時斷開,該過程是怎么解釋呢?且聽細細道來。
    因為除了功率控制,網絡還通過無線鏈路監控來實時監控鏈路狀態。36.213和133中有個說的很清楚:
    手機周期對信道進行平滑評估,也即是說每個無線幀中選擇一個下行子幀進行參考信號質量評估(RSRP或者RSRQ或者其他),為一個采樣點。需要至少獲取20個采樣點進行平均。

    可以設想,在200ms后,即20個無線幀,已經有了20個采樣點。將其結果平均后進行通信質量判決。若比較差,則上報失步指示,否則上報同步指示。在200ms后的10ms內,再采集一個點,此時該點和前面的19點再進行平均,再進行通信質量判決。

    若連續采集到比方說4次失步,則網絡等待一段時長,看情況有沒有好轉。若此后收到同步指示,則意味這鏈路可以繼續維持。否則則判定無線鏈路失敗。于是整個通話就死翹翹了。
    見下圖:
    可以看看,從開始檢測到斷開鏈路,該過程總的耗時時間:200+10*(N310-1)+T310 ms。T310最大也就是2s,N310配置最大也就是20次,因此最長即2.39s的時間。

    有同學可能已經看出來了,若你不想要通話斷開,就需要在T310超時后,盡快讓通信質量好轉。但是,通常用戶都是站著不動打電話,偶爾踱兩步。因此,也不可能在2秒鐘的時間像某教授瞬間轉移到另外一個信號好的地方(若移動車輛上,很快可以切換到信號好的小區),因此通常打著打著就掉話了。
    所以我們通常看到的場景是,在某個地方,信號非常弱,用戶拿著電話吼,但是通話很快就斷開了。繼續吼,繼續斷開。臉紅脖子粗再正常不過了。

    我想說的是,吼也解決不了問題滴。如果不想向運營商投訴(后續3GPP的立項MDT,就是手機會紀錄掉話信息,可以自動上報,以方便運營商優化),那可行的辦法是趕緊走到信號較好的地方重新發起呼叫吧,順便也自己冷靜一下啊。





    附件: 對著電話吼.jpg (2014-12-4 20:26, 102.66 KB) / 下載次數 0
    http://www.ga336.com/forum.php?mod=attachment&aid=MjUwNzc3fDIzY2VjZjI0fDE1Njg2MDIyMDB8MHww
    時間:  2014-12-4 21:04
    作者: Helloamy2014

    etl 發表于 2014-12-2 11:14
    樓主能否介紹一下LTE核心網應該看哪些資料,具體的協議應該為哪些?

    可能是401,301那些,這里有做核心網的同行嗎?請詳細說明一下吧
    時間:  2014-12-5 09:00
    作者: etl

    Helloamy2014 發表于 2014-12-4 21:04
    可能是401,301那些,這里有做核心網的同行嗎?請詳細說明一下吧

    恩,應該是這些了,但是這些里面都涉及到了很多2G,3G的東西,看后需要自己整理一下,謝謝啊
    時間:  2014-12-5 14:23
    作者: syq8723

    relight 發表于 2014-12-2 10:23
    寫的真好。贊~~
    mac對于超過大小的包還需要拆分嗎?

    RLC不會遞交給MAC超過大小的包,RLC PDU的大小是由MAC控制的
    時間:  2014-12-5 15:21
    作者: lph_2000


    時間:  2014-12-5 15:39
    作者: bestfly

    來個女的,不管寫得怎么樣,都行。
    時間:  2014-12-5 16:17
    作者: Bill-G

    bestfly 發表于 2014-12-5 15:39
    來個女的,不管寫得怎么樣,都行。

    話雖這么說,不過看下來,確實寫的不錯唉
    時間:  2014-12-5 16:20
    作者: shine2012

    關注中,感謝樓主~~~~~~
    時間:  2014-12-5 18:43
    作者: 700u

    關注
    時間:  2014-12-6 03:00
    作者: 電信愛好者168

    請問樓主,電信4G漫游使用延遲比本地卡高非常多,體驗很差,是什么原因?電信4G對比看了一下,漫游的IP還是歸屬地的而不是漫游地的.和電信3G不一樣,電信3GIP是漫游地的,對比測試本地卡和外地卡在網速,延遲上無任何差別
    時間:  2014-12-6 10:33
    作者: 小花開

    大贊:)
    時間:  2014-12-6 11:21
    作者: 彥峰

    學習了
    時間:  2014-12-6 13:05
    作者: chengmang

    學習了 贊一個
    時間:  2014-12-6 16:52
    作者: Helloamy2014

    本帖最后由 Helloamy2014 于 2014-12-6 17:03 編輯

    移動.png
    我的4G之路-王建宙《移動時代生存》新書問答錄

    在上月,臨時拉前同事一起去參加了王總在北大的新書發布會(感謝前同事的一如既往的支持以及圖片提供,那天真的很冷!)。當時還有baidu負責技術的副總裁到場。王總先做了大約半小時演講,之后在場觀眾以及北大的老師提了一些問題。這本書我已經在地鐵上讀完了,北京的同學可以直接聯系我,我將送出這本書。本文原文放在公共帳號的非技術版,考慮到很多人可能會感興趣,就貼上來。
    本文忠實于原書以及現場回答對重要問題進行記錄,不代表我的觀點。因此,以下有些回答,你懂的。

    Q1:您之前曾經作為移動和聯通兩大公司的高管,請評價一下這兩大企業。
    A:No comments。不議論我以前工作過的公司,這是最起碼的職業操守。

    Q2.:如何看待中移動和TD-SCDMA?
    A:在剛拿到TD牌照的時候,我們對TD基于如下判斷:這是一項光榮的使命,中移動一定不負重托。但當時TD的成熟度明顯落后,在3G時代,中移動的技術領先地位將受到巨大挑戰。
    首先遇到的是產業鏈磨合問題,要推出盡量多的TD終端開發。2009年,中移動和終端、芯片廠商聯合研發投入,有效加快了TD終端的開發,一批新的終端進入市場。其次,要千方百計確保網絡質量,進行全網質量測試,在通話過程中出現的問題,既有覆蓋,也有網絡設備原因和手機原因。再次,應用新的技術,在3G網絡建設過程中,退出了CRAN,即利用云計算技術,建立集中式基帶處理池。
    對于中移動自身來說,這次實踐,提升核心競爭力,同時為4G的發展打下基礎。和國際運營商相比,我們3G的建設確實晚了很多年,但我們建設3G網絡的時候,4G的主要特性已經出現,中移動在招標的時候,明確要求,到4G的平滑過渡。3G的研發為4G打下基礎。
    評價:這是個標準回答!其實也只能這么答!

    Q3:如何看待微信微博對短信的替代?
    A:社交網絡迎合了大眾在快節奏下擴大社交的需求。確實,有了微信朋友圈,短信較少,微信語音聊天,通話也減少。微信和微博取代一部分話音和短信,是技術的必然。但同時,他們也給手機帶來了巨大的數據流量。所以及時通信方式和傳統的電信業務不矛盾,將起到推動轉型的作用。

    Q4:移動運營商淪為管道的看法
    A:目前大多數的手機App都是第三方開發的,電信運營商僅提供基礎網絡。
    今后的網絡主要受益將來自于應用,運營商如果不直接參與應用的開發和運營,就將變成啞管道。長此以往,電信運營商將被邊緣化。我們一方面是缺乏開發應用的人才,一方面需要探索應用服務的經營模式。所有運營商都在想這個問題,VDF推出了收費的地圖服務,但很快被免費地圖取代。AT&T推出了自己APPstore,但效果不好。我也很期望在電信行業看到killer Application的出現。

    Q5:電信運營商的轉型
    A:當數據時代到來時,移動運營商感覺到來新的挑戰。數據爆炸增長讓網絡不堪重負,增加了擴容成本,另一方面,消費者又希望降低流量經營。對電信行業來說,變化巨大。
    之前從電報到固定電話和移動電話,運營商始終處于電信行業價值鏈的中心,演進都是在電信行業內部。而在數據時代,電信運營商只是作為一個連接的節點存在,移動互聯網并非是電信行業的演進結果,而是IT行業多年的演進結果。
    移動互聯網已經形成了一個新的生態系統,其中有三個環節:1)網絡連接2)移動設備3)應用服務。電信運營商僅在第一個環節發生決定作用。無論移動互聯網如何發展,都需要無線網絡作為基礎。移動互聯網應用越多,對無線網絡的依賴越強。
    移動互聯網這三個環節密切相關,但又自成體系。新的生態系統給所有參與者都帶來機會,但也給傳統運營商帶來挑戰。
    之前,中移動邀請馬云來做演講。會前馬云問我講什么好,我說放開講。馬云果然放開講:“互聯網大軍正在大舉進軍電信市場,阿里巴巴組織了一支很大的團隊開發自己的手機操作系統。我喜歡在別人的地盤打架。至于你們想搞互聯網,恐怕你們的機制不行,你們的年齡也不行了”。臺下同事面面相覷。
    同時,移動互聯網也給互聯網企業帶來挑戰。我遇到李彥宏,他說,之前搜索引擎是通過廣告業務為主要收入,而現在大多數人使用手機搜索,而在手機上做廣告難度就很大。所以互聯網企業也在調整自己,發現新的機會。
    生態系統對于每一個參與者都是公平的,物競天擇,適者生存。在移動互聯時代,從數據流量增長角度看,運營商和服務提供商可以共贏。同時,運營商也要珍惜自己離用戶最近,最接近用戶的機會,提供各種開發的平臺,以及提供一些有特色的應用。相信電信運營商會在應用服務方面找到新的機會。

    評價:同意關于生態系統的分析。后續有現場提問,為什么中移動有這么龐大的客戶群,就是搞不出來流行的應用,王總也坦言,電信行業在創新DNA上確實要差一些。馬總確實說到痛處了。

    Q.6 免費or 收費?經營方式大探討
    A:互聯網企業不向用戶直接收費,而是通過別的渠道獲取收入,比方下載游戲免費,但買道具要收費;在購物網站瀏覽免費,但購物收費。在《免費》這本書中談及,林林總總的免費歸根到底變為統一本質,即讓錢在不同的產產品,現在和未來,無現金支付的市場和無現金支付的市場之間轉移,經濟學上稱為“交叉補貼”。
    電信運營商也適用,比方說“預付話費送手機”。但互聯網的免費方式則是給電信運營商更大的挑戰。因為互聯網的免費產品完全可以替代電信的收費產品。比如微信就比短信更加吸引人。而且在桌面互聯網中行之有效的經營模式,在今天移動互聯網時代依然有效,而且還可能出現新的贏利模式
    再回到“預付話費送手機”的問題,之前被國內外運營商廣泛使用。后來,運營商不這么做了,一方面是因為現在補貼的智能手機價格不菲;另一方面,用戶更換手機速度較快了,用戶對手機的多樣化需求提升了。因此該方法不再奏效了。
    互聯網企業最關心的是用戶數目,只要有足夠的用戶,今后就可以給用戶提供更多的服務來創造價值。因此即便現在不贏利,也會存在很大發展空間。比如******,當用戶數多的時候,就可以提供金融服務,包括金融存款和移動支付。同樣騰訊業可以向微信用戶提供游戲和移動支付。
    電信運營商也可以從中受到啟發,電信運營商也擁有龐大的用戶群。移動互聯網時代,電信運營商應該要向互聯網企業學習,如何為用戶帶來更多服務。

    評價:若是短信完全免費,估計運營商舍不得吧?

    Q.7 關于手機制造業的討論
    A: iPhone手機大都在中國組裝。以iPhone的組裝為例,基帶處理,應用處理器,內存,閃存,相機,觸屏等,和這些元器件的成本相比,組裝費用只是占據很小部分。而組裝需要大量勞動力。而品牌的擁有者和產品研發設計者將獲取主要利潤,其次是芯片和關鍵零部件的生產者。
    手機制造業如果長期依靠組裝,將難以為繼。要想使制造行業獲得更大的產品附加值,就必須提高制造業的創新能力,提升品牌價值。關于手機制造業的討論還在繼續。智能手機是一個規模龐大的制造領域,集中反映了半導體,材料,軟件等各種新技術。
    可喜的是,越來越多的中國手機自有品牌出現。以中興、華為、聯想和酷派為代表的國產手機開始掌握國內市場的主導權。

    評價:華為的榮耀3C確實不錯,我老爸超級贊的。

    Q.8 未來的智能手機
    A:今天的智能手機,從操作系統到芯片,到元器件都越來越成熟,但各種手機之間也越來越雷同。市場期待新的劃時代的手機。
    我常說,4G時代應該擁有和3G時代不同的手機。可以設想一個場景,有人在眾目睽睽下拿出一部手機,突然把折疊的顯示屏展開,這個顯示屏可以折幾折,打開就像平板。旁邊的人都異口同聲,這就是一個4G手機。
    智能手機也可連接可穿戴設備,或者智能手機直接變成可穿戴設備,如手表或者衣服。當然智能手機的創新不容易,我認為要考慮如下幾個關鍵問題:首先是芯片,其次是元器件。要想使屏幕做大,需要可折疊的顯示屏,同時在大顯示屏和視頻業務下,手機的電池是大問題,必須研究新的電池材料。
    再次是操作系統,目前供選擇的操作系統太少,只有安卓和WindowsPhone, 蘋果是專門的封閉系統。操作系統集中可以使應用開發者精力更加集中,但過分集中將出現和操作系統有關的專利訴訟。
    我鼓勵開發新的操作系統,操作系統的演進將帶動手機的創新,并鼓勵推進開放式的操作系統。

    評價:關于手機的省電,俺之前寫過一篇文章。關于手機代替手表?至少對我而言,我可能不會,除非設計很好,但我覺得手表的設計感不是通信行業可以handle的。我的兩個手表,一個大的,一個小的,就是可以搭配不同的衣服。我想大部分尤其是男生,都是很喜歡那些名表的吧。



    附件: 移動生存之道1.jpg (2014-12-6 16:57, 9.74 KB) / 下載次數 0
    http://www.ga336.com/forum.php?mod=attachment&aid=MjUwODU4fDMyZTA1MmY2fDE1Njg2MDIyMDB8MHww

    附件: 移動.png (2014-12-6 16:57, 600 KB) / 下載次數 0
    http://www.ga336.com/forum.php?mod=attachment&aid=MjUwODU5fDhkYTdkYmFmfDE1Njg2MDIyMDB8MHww
    時間:  2014-12-6 17:30
    作者: fantaiqing

    這本書我買了,哎,脫離不了中國紀錄片式的歌功頌德啊
    時間:  2014-12-6 17:38
    作者: Helloamy2014

    fantaiqing 發表于 2014-12-6 17:30
    這本書我買了,哎,脫離不了中國紀錄片式的歌功頌德啊

    他只能這么寫啊
    時間:  2014-12-6 20:10
    作者: cattpon.chen

    很不錯~繼續~
    時間:  2014-12-7 13:18
    作者: 風雅小強


    時間:  2014-12-7 13:37
    作者: liuchao1105

    支持~~~~~~
    時間:  2014-12-7 14:54
    作者: elliot1106

    怒贊一個
    時間:  2014-12-7 15:19
    作者: 珍惜眼前人

    不錯
    時間:  2014-12-7 15:46
    作者: yinjin

    通信小碩膜拜
    時間:  2014-12-7 17:29
    作者: Somnr

    寫的超好,學習了,感謝!
    時間:  2014-12-7 19:09
    作者: dream_xiu

    很好,很詳細
    時間:  2014-12-7 19:17
    作者: xiaokanglan

    很形象啊樓主。
    時間:  2014-12-7 21:04
    作者: wclvzz

    真是一篇很好的論文呢!
    時間:  2014-12-7 21:14
    作者: wsq5000

    好文
    時間:  2014-12-7 21:34
    作者: 中國人8007

    很好很有用
    時間:  2014-12-7 22:11
    作者: 陶胡蔣

    贊一個
    時間:  2014-12-7 23:18
    作者: 陳錦培


    時間:  2014-12-8 03:54
    作者: Ricky_X_F

    支持!
    時間:  2014-12-8 09:10
    作者: PowerG

    菜鳥持續關注ing...
    時間:  2014-12-8 10:03
    作者: lmy1052

    Helloamy2014 發表于 2014-11-14 21:53
    我的4G之路-談總體架構   

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

       關注!..但是今天次注冊不能加好友!
    時間:  2014-12-8 11:18
    作者: sunas3

    好貼!
    時間:  2014-12-8 13:24
    作者: 49679711

    mark
    時間:  2014-12-8 13:30
    作者: nghe

    詳述得相當精彩和給力,很易懂
    時間:  2014-12-8 16:17
    作者: 小墨和小白

    MARK,后面學習
    時間:  2014-12-8 17:19
    作者: qqqq77722

    不錯呦~~
    時間:  2014-12-8 17:31
    作者: 四色定理

    在細細的閱讀中,還需百度來查閱。方好搞懂。
    時間:  2014-12-8 20:57
    作者: Helloamy2014

    Ricky_X_F 發表于 2014-12-8 03:54
    支持!

    這個書是你自己寫的嗎?
    時間:  2014-12-8 20:58
    作者: Helloamy2014

    北京的同學,沒有人想要我的這本書嗎?

    因為要搬家,很多書都要送出去了
    時間:  2014-12-8 21:52
    作者: 梧桐下的夢

    mark 樓主加油
    時間:  2014-12-8 23:09
    作者: 風停幻滅

    持續關注中。。。
    時間:  2014-12-9 10:54
    作者: sunas3

    樓主加油!等不及啊。。。
    時間:  2014-12-9 13:05
    作者: 麥芽餅

    樓主大好人!好人好文!
    時間:  2014-12-9 14:14
    作者: Limons

    看了,寫的很好啊:)




    通信人家園 (http://www.ga336.com/) Powered by C114
    嫩妹妹