轉載於：http://www.52rd.com/bbs/Archive_Thread.asp?SID=54542&TID=2

因為工作的關係，有幸接觸到一種不那麼複雜的2G通訊技術的協議棧（終端）和基帶兩方面的內容，經過一段較長時間的摸索和思考，再加上和終端廠商一線開發人員的的討論深化，到現在總算對協議棧設計和架構方面有了一些比較粗淺的想法。

因為我的工作內容重點在於基帶硬體（也涉及RF模組）和協議棧的（物理層+鏈路層，對於網路層的協議細節則不太熟悉），所以我這不多的想法也是集中在我所從事過的這些方面。
接下去的詳細論述是從協議棧設計和架構方面去著眼的，從軟體工程的角度來說頂多進行到概要設計那個階段:-）
1，從協議規範的學習理解到協議棧的設計架構。
1.1 對於行動通訊終端協議，首先去了解並理解協議規範的具體內容是最最基本的，這是個know what的過程，如果不做協議棧設計和實現的話，一般到這個程度也就差不多了；
1.2 知道並熟悉了協議規範的描述後，接下來就可以去考慮如何設計協議棧框架了，這是個know how的過程。
      協議規範一般會以自然語言和形式化語言兩種方式去描述定義：自然語言有利於理解，但是定義不嚴格，理解起來有時會導致歧義性，於是各種形式化語言就作為必要的成分參與其中了。從協議的整體來看，我覺得“狀態機”是個非常重要的概念和思想，雖然它離實際的協議棧實現還有一點點距離。從狀態機可以衍生出SDL圖和MSC圖等等較嚴格規範化的形式化定義：
〉〉SDL側重於從系統狀態的變化角度去描述和定義單個系統的行為，這裡“系統”的概念比較靈活，一個協議層可視為一個系統，多個系統的集合也可視為一個更大的系統，劃分和界定系統主要是為了將概念域的“系統”對映到設計域的“狀態機”（設計域的“狀態機”接下來將被對映到實現域的“狀態機實現”，具體的實現方式有“狀態—事件表”法、“Switch-Case”法等）；
〉〉MSC圖側重於從多個系統間訊息互動（包含訊息內容和特定訊息的傳遞順序兩方面的內容）的角度去描述和定義系統間的行為，這裡的系統可能是一個物理通訊實體（如終端或基站）內部的某個協議邏輯層系統，也可能是整個物理通訊實體本身，當然準確地說在通訊協議棧的規範和實現中，物理通訊實體一般都會被劃分為多個邏輯通訊實體去分別對待的，而不會像在通常口頭所說的終端和基站通訊這麼簡單、籠統。
關於“狀態機”概念，稍微深入下去討論的話，我個人的理解是：狀態機是狀態和事件以及事件對狀態的驅動規則的集合，前兩個元素基本上可看作是靜態的，而事件對狀態的驅動規則可看作是動態的，這樣的話“狀態機”就可以理解為靜、動結合的一個邏輯實體，當然用面向物件的思想去看待“狀態機”這樣一個邏輯實體的話，很容易地就會把它理解成一個物件，——在協議棧設計和實現的過程中，確實可以借用面向物件的方法（思想層面上）或手段（實現層面上），這樣的話協議棧的結構和邏輯會更清晰。
通常我們所討論和理解的“狀態機”多是單層、扁平的狀態機模型，此外對狀態機概念的一個發展是“層次狀態機”的概念：單層狀態機概念是在將系統劃分為一個個相對孤立的系統的前提下、將系統從概念域對映到設計域後得到的，而客觀上，各個系統間並非都是完全孤立的，有的系統間存在邏輯上的包含與被包含關係，因而考慮到概念域的這種聯絡，在設計域也有必要將狀態機在邏輯上進行層次劃分，這種想法和麵向物件思想中的繼承是非常相像的，甚至多型的概念也可以加入到此中來。關於層次狀態機的詳細論述，可參考《嵌入式系統的微模組化程式設計——實用狀態圖C/C++實現》一書，作者是美國的一個資深工程師，書裡面的內容我個人理解應該是經驗之談，不過我只吸收了其中的“層次狀態機”這個核心思想，至於具體的程式碼實現細節，我沒仔細去看了^&^。
在對協議棧的設計和架構有了總體的認識後，嘗試著慢慢去把這些認識具體化就是件水到渠成的事情了。就個人體驗而言，Visio用在這方面真是很不錯，我嘗試過用WORD畫狀態機圖和SDL圖、用Excel畫MSC圖，但是因為資料格式不統一而導致的內容分散，所以很難把自己的理解和想法在一種單一型別的文件中集中體現出來，而Visio的多頁編輯功能和豐富靈活的編輯方式恰好滿足了我的這種需求（Tips：平時有什麼想法的話也可以在Visio裡塗塗畫畫，想法變了可以再改，Visio給你提供足夠的自由度：-）。
1.3 經過上面的兩步工作，一個基本的協議棧架構和模型差不多就能出來了，不過在具體實現前，為了儘可能的避免一些理解的偏差或提高系統設計的質量，花些心思去理解或猜測協議規範為什麼設計成現在的這個樣子是很有意義的，這是個know why的過程，雖然都是去了解和理解協議，但是能達到know why的高度則非常厲害了，不過這個過程是個周而復始、迴圈上升的過程，需要長期不斷地積累：在具體實現和執行之前，可以依託廣泛的知識背景和高超的個人理解力去理解或猜測協議設計背後的思想或考慮，但是很多這方面的知識和經驗是要等到協議真正實現運行了後，在除錯和實測中發現問題、總結經驗後才能逐步深化的，這些深化了的理解反過來可以指導前期的設計以提高系統設計的質量。所以要自行開發協議棧的話，我覺得在設計—〉實現這條路上不宜堅持一步走到底的“美好”想法，反過來若是以原型化的方法先開發一個簡易的Demo，然後通過除錯和測試不斷地去細化和完善，這樣協議棧開發成功的可能性會增大、總的開發週期也有可能會縮短。形象地說，是先搭骨架，再添器官，最後加肌肉和血管，這樣一個有血有肉、鮮活的生命體就誕生了：-）
2，從協議棧的設計架構到協議棧的實現除錯
這裡的“實現”是指在軟體級的實現，包括RTOS的選擇、系統任務的劃分和通訊機制的選擇安排、以及最後的編碼除錯。

如前所述，一個完整的通訊過程中會牽涉到不同邏輯通訊實體間的資訊互動（從終端使用者的角度看，看到的是不同物理通訊實體間的資訊互動），各個不同的邏輯通訊實體在整個的通訊系統中既保持一定的獨立性（這是狀態機賴以存在的基石），又和其他邏輯通訊實體存在一定的聯絡（這是整個系統得以實現通訊功能的所在），因而在實際實現和執行中需要考慮怎樣去協調這些邏輯通訊實體間的行為（廣義地說，邏輯通訊實體間的通訊也是為了協調邏輯通訊實體間的執行順序，如：物理層給鏈路層傳送1個slot的接收資料，鏈路層收到此資料後觸發其下一步的動作，否則鏈路層在接收資料方面的操作會被掛起暫停，因而可以理解功能上的訊息通訊實則影響了時間上的執行狀態）。從邏輯設計到實際實現的過程中，每個邏輯通訊實體所對應的狀態機很自然地會被考慮對映到RTOS的任務上去，這中間不一定是一對一的關係，某些情況下，出於任務粒度劃分的考慮，有可能是一對多的。

由於每個RTOS提供的任務同步和任務間通訊方式差異較大，所以在這裡討論以何種具體的任務同步和任務間通訊方式去實現兩個特定邏輯通訊實體間的同步和通訊意義不大，據我所知道的日本比較流行的iTRON規範中，常見的有訊號量（Mutex、Semphore）、事件標誌、郵箱（適合大資訊量的任務間通訊）、訊息緩衝（適合中、小資訊量的任務間通訊）這幾種，至於會合，有些符合iTRON規範的RTOS中並未實現。
協議棧的除錯是件煩人的事情，有時會因為一個小小的錯誤折騰很多天而不得其解，有時甚至會被逼得考慮重新設計狀態機，這個過程很折磨人，也很鍛鍊人，協議棧實現能力和除錯水平的提高，在這個過程中可以得到深化和昇華，這可能也是TTPCOM這樣的專業協議棧軟體公司的經驗和長處所在了：-）

後記：
寫了這麼多，雖然文字量不太大，但是涉及的內容面挺廣，因而寫完後還是感覺有點累！
我這人比較懶，有想法一般都在腦子裡打轉或在嘴上和人家說，不太習慣用文字的形式把它固化下來（敲字太累！圖表倒是經常用，因為我把那個看作是思維的延伸:-）

因為我也是第一次接觸無線通訊終端協議棧和基帶方面的內容，所以在無線通訊協議上的經驗和理解有限，2G裡面我只碰過這個，不知道將來在3G領域有沒有機會再碰碰。

協議棧的設計和實現與一般的軟體系統開發不太一樣，不過它有一套自身特有的模式，一旦接觸過並掌握了這個模式後，以後再開發其他無線通訊協議棧的話，難度應該會降低很多。而且協議棧開發中某些過程確實是可以模式化且能以CAD的形式實現出來的，如Telelogic的Tao據說就能根據SDL圖自動生成C程式碼，其實這種轉化並不難。

談到CAD這塊，有必要提提ITU在通訊協議規範方面所做的形式化語言定義工作：從ASN.1對PDU（Protocol Data Unit）的定義，到SDL對狀態機的定義，再到MSC對訊息互動流程的定義，直到TTCN等對協議測試的定義等等。對這些形式化語言，我只是很粗略地看了看，有興趣學習研究的朋友可以去ITU的網站上下載。

“話不說不明，理不辯不清”，歡迎其他對協議棧感興趣的朋友積極討論，以加深或糾正各自對這方面的理解。以後如有時間的話，可以再開個話題討論協議棧開發和應用過程中的Troubleshooting，這個不屬於純技術的範疇了，可能很多人對此也沒多大興趣了^&^。

---------------------------------------------------------------------------------------------------------------------------------------------------------------

johnson2037 Post at 2006-11-23 16:50:34 樓主 厲害嘛，有沒有聯絡方式呢？有空交流一下，對此感興趣啊。 tangyoucan Post at 2006-11-24 8:18:19 真是感謝樓主呀,聽君一席話,勝讀十年書呀,我看了快三個月的紅外協議棧,都不知道往那方面下手,今天終於知道該往那方面動手了,謝謝樓主呀 zhiyunli Post at 2006-11-28 8:56:45 對你有點用就好，也不枉我碼了這麼多字：-）

其實我自己也是剛入了門，以後要深入下去的路還很長，有時間的話可以互相交流一下，我的郵箱：[email protected] 。

0011103 Post at 2006-11-28 11:04:55 [em01] 0011103 Post at 2006-11-28 11:05:17 [em14][em14] pigdragon Post at 2006-12-20 20:36:11 good
[em02][em01] zzwy Post at 2006-12-22 12:02:30 寫得很好 yatianliu Post at 2007-1-31 15:20:14 我是新手，來學習哈
jackeychen66 Post at 2007-2-13 22:00:34 ding[em04][em08] spokesmen Post at 2007-3-9 10:55:25 我是搞協議測試的·看了以後對我的幫助很大，，謝謝 hero4422 Post at 2007-3-9 17:36:02 其實說的容易,做起來難呀;本人做了5年才將PHS協議棧全部吃透;其實關鍵是要動手;埋下頭去做!! zhiyunli Post at 2007-3-9 17:47:35 同感！其實在這裡我只是想拋磚引玉地表達一下對協議棧設計、開發方法學上的一些理解，對於協議細節理解、程式碼除錯等具體而微的事情，確實很耗費時間也很折騰人。

拋磚只為引玉，但願hero4422前輩能把自己這麼多年來的一些體會和感悟寫出來和大家分享一下，也為國內的通訊軟體事業發展添磚加瓦，先謝了！（我會時不時跑到罈子上來等的哦）

hero4422 Post at 2007-3-19 19:26:01 做協議棧的一點體會：
   個人覺得做協議棧需要具備一些基本素質:
        1：邏輯思維一定要強；
        2：要熟讀並理解好協議的資料；
        3：根據資料理解掌握協議棧需實現的每一個功能；
        4：將每一個功能按照協議的分層實現原理，做出每個功能的層次流程圖；
        5：根據層次流程圖做出每一層的訊息原語及訊息元素；
        6：將所有功能的流程圖分層整合；做出每層的狀態圖；
        7：做出每層的詳細流程圖；
        8：考慮每層的訊息互動中可能的異常，設定保護定時器，對異常做適當處理：
   定時器的設定原則：
         對於空口中的每一條訊息或幾條訊息設定定時器保護（假想任一條訊息丟失了，看流程中是否有保護，若沒有就得設定時器保護）
       以上僅是個人的一點愚見；歡迎討論！！
[br]<p align=right><font color=red>+1 RD幣</font></p> zhiyunli Post at 2007-3-20 20:19:53 >> 1：邏輯思維一定要強；
>> 2：要熟讀並理解好協議的資料；
>> 3：根據資料理解掌握協議棧需實現的每一個功能；

這應該屬於“Know What”的過程，基本功確實省不得。

>> 4：將每一個功能按照協議的分層實現原理，做出每個功能的層次流程圖；
>> 5：根據層次流程圖做出每一層的訊息原語及訊息元素；
>> 6：將所有功能的流程圖分層整合；做出每層的狀態圖；
>> 7：做出每層的詳細流程圖；

對以上4條的理解，是否遵循如下的流程：具體功能==>層次流程圖==>層內訊息原語/元素==>層內狀態圖==>層內詳細流程圖 ？
如果是的話，我感覺這種實施的流程有Use Case導向的跡象（“具體功能”是否指打電話、接電話這樣的Use Case？），當然這從需求分析的角度來看確實可以這樣操作的，不過除“具體功能”這個階段的需求分析外，餘下的系統攝接和實現過程似乎屬於由繁至簡的概括性思維方式，——個人愚見：在對協議內容和協議棧設計等關鍵知識點尚無經驗的前提下，這種由繁至簡的概括能總結出協議規範那樣高度精煉的內容融概要（文字描述或State Chart / SDL圖或MSC圖等）嗎？我覺得由巨集觀至微觀、由簡至繁的發散性思維方式可能更符合實際的思考過程，不過Hero前輩也是這個意思，只是沒明確指出來。

>> 8：考慮每層的訊息互動中可能的異常，設定保護定時器，對異常做適當處理：

對於異常情況的處理，可能比正常情況的處理更為複雜。定時器確實是一種防止異常情況的有效手段，不過我認為定時器針對的異常應該主要是物理層的收發狀況/結果不確定造成的異常（任何無線甚至有線通訊本質上都是不可靠的，都存在出錯的可能性，因而需加以事先考慮），至於純軟體過純協議邏輯造成的異常，用定時器的方法雖然也可以監視並處理（如堅實整個軟體系統執行狀況正常與否的看門狗，本質上還是一個定時器，只是這種定時器一旦溢位超時的話，就直接reset了），但是更根本的，可能還需要從協議邏輯本身（如狀態機設計紊亂或有缺陷）和軟體本身（如記憶體不足、堆疊溢位）分別預防並控制：前者的檢驗屬於離散數學的範疇了，後者的檢驗則屬於軟體功底和修養的範疇了。

總的說來，實現同樣的東西，各人的具體方法和流程可能是不完全相同的，求同存異、互相交流，相信能達到開拓思路、集思廣益的目的。在此，謝過Hero前輩的熱心指教了！[br]<p align=right><font color=red>+1 RD幣</font></p>

hero4422 Post at 2007-3-20 22:14:38 說實在話；本人雖然做了5年協議棧；但很少寫下一些心得體會；以上僅是我臨時的一點想法；可能很多不是很確當；希望 zhiyunli 能夠在理論及實際中給予我更大的幫助！！ zhiyunli Post at 2007-3-22 21:22:57 Hero前輩過謙了！
說實話我一直很佩服能潛心埋頭苦幹的人，因為我自己不容易做到。
我很羨慕前輩能有這麼豐富的開發經歷，要是能夠予以適時地總結、提煉、昇華的話，對後來人真是功莫大焉啊！期待ing。。。 gundon Post at 2007-4-19 15:58:27 [em01]多謝分享 tellenyu Post at 2007-5-17 11:05:06 都是高手！學習ing gateway51 Post at 2007-6-6 18:24:33 謝謝兩位了：） willhunting Post at 2007-6-16 21:58:01 樓主顯然沒有做過協議棧。也不懂協議。

從這句話可以看出：
如：物理層給鏈路層傳送1個slot的接收資料，鏈路層收到此資料後觸發其下一步的動作，否則鏈路層在接收資料方面的操作會被掛起暫停，因而可以理解功能上的訊息通訊實則影響了時間上的執行狀態）。從邏輯設計到實際實現的過程中，每個邏輯通訊實體所對應的狀態機很自然地會被考慮對映到RTOS的任務上去，這中間不一定是一對一的關係，某些情況下，出於任務粒度劃分的考慮，有可能是一對多的。

slot  用的就是不懂裝懂的典型。
是TIME SLOT嗎？2G裡面一個TIME SLOT的資料物理層實現時是不會單獨傳給鏈路層的，GSM是需要一幀的資料才有意義，構成FACCH或SACCH或DCCH的資料。GRPS需要4個連續幀的同一時隙號才組成一個無線塊，物理層還需要均衡，通道解碼，解交織，才能還原成鏈路層能識別的一個數據塊。所以一個所謂SLOT物理層就給鏈路層一個數據，這種系統是無效的。樓主要裝高階可以說FRAME或者RADIO BLOCK。
同篇沒有什麼技術含量，說了很多跟協議棧不粘邊的。
鄙視一下，不要介意，做技術講的就是實事求是，不談虛的。

willhunting Post at 2007-6-16 22:01:46 另外，面向物件的手段（如C++ JAVA），是沒有用到過協議棧上的。至少我見過的TI的程式碼，高通的程式碼，華為的程式碼，ADI的，中興的，大唐的展訊的協議棧都是C寫的。 zhiyunli Post at 2007-6-17 1:02:10 首先廓清2點：
1，“做技術講的就是實事求是”，這話放在哪裡都適用，不過你可能自己都忘了一個事實，你所說的GSM/GPRS和我所暗指的PHS並非一碼事，所以你要實事求是的話，就在共同的PHS基礎上再討論，如果你不熟悉這個的話，可以請教一下hero4422前輩，他是這方面的元老了。不要告訴我說2G只有GSM啊，PHS就不屬於2G技術了^&^；
2，“面向物件的手段（如C++ JAVA），是沒有用到過協議棧上的”，看你這麼武斷地把“面向物件的手段”就等同於C++、Java語言了，我真是有點擔心。你不會不知道用C語言可以實現絕大部分的C++語言特性吧，最簡單的如封裝！你看過這麼多家公司的協議棧程式碼確實很好，但是希望你不要只看到協議棧是用哪種語言寫的，更要看清其設計思想和實現手段。將面向物件的思想和手段融入進協議棧設計實現的肯定是有的，因此希望你對系統設計的理解不要僅僅停留在程式語言的層面上；
我寫這篇小文的目的只是為了把自己的一點點體會寫出來，好讓後來者能少走點彎路。我從來都知道在這方面比我經驗豐富、比我修養高的人多的是，所以我也是抱著討論、學習的態度來到52RD的。一個人樂於貢獻的態度應該比他/她所貢獻出來東西的質量高低更重要。輕率地妄下結論於事無補，於己也無利。
[align=right][color=#000066][此貼子已經被作者於2007-6-17 10:45:55編輯過][/color][/align] shaolin19831 Post at 2007-8-1 18:51:20 很不錯的東西 jiangmiao53 Post at 2007-8-11 10:20:44 首先說下我沒做過協議,是OS技術的愛好者,我真的很不贊同 willhunting的說話方式.還高談做技術講的就是實事求是，不談虛的。又說樓主顯然沒有做過協議棧。也不懂協議。
這樣說就讓人覺得藐視一切哦.即使別人有一點沒說到位也可以用好的語氣吧 卡妙 Post at 2007-8-11 12:10:09 樓主能否留下MSN聯絡方式啊？ syxf80 Post at 2007-9-22 0:24:19 大家做技術的爭吵無所謂,只是別偏離了討論技術的目的就可以了 dingshipeng Post at 2007-10-12 15:27:21 謝謝樓主指教，
學習了。[em01] Alex_lpa Post at 2007-12-6 10:52:39
我認為下面這位才是真正開發過協議棧的，或至少看過協議棧實現原始碼的。

本人做過5年協議棧開發，期間開發過多個協議棧（BT、WiMax、UWB）。不過主要集中在資料鏈路層和MAC層。

樓主說了點基本的道理，但我認為實際動手做的經驗不多，可能看spec比較多而已。
===================================================＝＝＝
樓主顯然沒有做過協議棧。也不懂協議。

從這句話可以看出：
如：物理層給鏈路層傳送1個slot的接收資料，鏈路層收到此資料後觸發其下一步的動作，否則鏈路層在接收資料方面的操作會被掛起暫停，因而可以理解功能上的訊息通訊實則影響了時間上的執行狀態）。從邏輯設計到實際實現的過程中，每個邏輯通訊實體所對應的狀態機很自然地會被考慮對映到RTOS的任務上去，這中間不一定是一對一的關係，某些情況下，出於任務粒度劃分的考慮，有可能是一對多的。

slot  用的就是不懂裝懂的典型。
是TIME SLOT嗎？2G裡面一個TIME SLOT的資料物理層實現時是不會單獨傳給鏈路層的，GSM是需要一幀的資料才有意義，構成FACCH或SACCH或DCCH的資料。GRPS需要4個連續幀的同一時隙號才組成一個無線塊，物理層還需要均衡，通道解碼，解交織，才能還原成鏈路層能識別的一個數據塊。所以一個所謂SLOT物理層就給鏈路層一個數據，這種系統是無效的。樓主要裝高階可以說FRAME或者RADIO BLOCK。
同篇沒有什麼技術含量，說了很多跟協議棧不粘邊的。
鄙視一下，不要介意，做技術講的就是實事求是，不談虛的。

zhiyunli Post at 2007-12-6 21:47:52 呵呵，你說的有幾分對，不過也有很多臆想的成分！

“本人做過5年協議棧開發，期間開發過多個協議棧（BT、WiMax、UWB）。不過主要集中在資料鏈路層和MAC層。”，他曾經是我們的一個主要客戶，我們提供基帶晶片和協議棧，但絕對不是你假想的GSM，你是第二個先入為主、這般臆想的了，再來第三個我再也不會感到驚訝了!

只有協議棧的網路層我確實只看過沒寫過（太繁瑣複雜），不過我最熟悉的是物理層和基帶晶片本身，當然也不是GSM的！每個協議棧實現的方式不盡相同，以某個人的理解去推測其他人的情況不客觀，抑彼未必能揚此，更何況我當初寫小文的目的並非藉此想顯示什麼，只是感嘆國內比較核心的技術的交流比較少，所以斗膽寫一下個人孔見，如能拋磚引玉，引來高人施手，眾R&Der們幸莫大焉！期待你能根據曾經從事過的BT或WiMAX或UEB等把你的理解和體會比較完整的寫出來，隻言片語或一鱗半爪不足以解我輩之渴啊！

我現在已經不在通訊行業了，事實上也基本脫離了純技術的範疇。自古文人相輕，現今工程師相輕也頗烈，悲乎。。。人生大好時光，豈在爭技術之一時之長短？！

everlasting Post at 2008-5-5 17:57:04 學習一個！ alsung Post at 2008-6-9 16:33:45 雖然做了五年手機相關的東西，但是由於不太上心，至今對系統理解依然沒有清晰細膩的框架。
時間有的時候能說明問題，但不見得都在一個點上。

回頭學習學習這個帖子裡討論的內容。

感謝分享見解。

jenmars Post at 2008-6-21 22:40:22 支援樓主~~.
文人相輕的惡習我始終不能理解.
咱工程師討論點技術問題為什麼就不能以謙虛的態度來切磋呢~~
難道搞技術搞多了真的會目空一切.持才傲物?
有樓主這種胸懷的工程師就不能多點？
祝福樓主職業道路越走越好。。 sibulini Post at 2008-6-27 11:22:36 今天沒時間看,留個腳印 dennis_hd Post at 2008-7-8 11:00:38 潛力貼，怎麼沒了下文？ wensean Post at 2008-8-12 16:49:42 是啊，怎麼不見下文，期待PK! sherrycancer Post at 2008-9-3 10:10:16 大家海是討論技術吧，不論樓主做沒做過協議棧，但是他確實把他的一些經驗想法感受都寫了出來，給我們這些想入門卻不知道怎麼入的門外漢啟發。多謝樓主！ gift001 Post at 2008-9-8 11:07:39 樓主出國了？[em01] heliking Post at 2008-9-12 0:45:56 路過[em01] NeilWong Post at 2008-11-4 14:41:56
 對上面的問題提提自己粗淺的認識,實際上DataLink層每次發給物理層或者從物理層接收的都是一個資訊單元,以GSM的NB為例,大部分是23個Octets的一個訊息包,該訊息包是從某個物理通道的一個塊得到的.當然SB只需要一個Frame, 而大部分的塊都是佔用連續的四個Frame的.(其中的某個物理通道), 而物理通道則對應相應的TimeSlot, 例如SI都是從TS0得到的等等.

[em01]

EverestDH Post at 2009-6-24 19:01:54 mark!!
And then, to update!! eddy Post at 2009-9-27 20:09:56 支援樓主的分享哈 學習不少
第一次到這個版塊，近來剛剛接觸協議棧方面開發東西～