一仆嗦、引入
? ? 4G LTE通信系統(tǒng)由有線和無線兩部分組成，當(dāng)然岸晦，在這個(gè)層面2G欧啤、3G還有5G也是一樣，比如從西安撥打上海的電話启上，手機(jī)信號一定是以電磁波的形式先發(fā)送到本地基站，這部分是無線網(wǎng)絡(luò)店印，然后通過有線網(wǎng)絡(luò)連接到上海的某個(gè)基站冈在，最后再以電磁波的形式發(fā)送到上海的電話上。
? ? User Equipment (UE)
? ? Evolved Packet Core(EPC)
? ? Evolved Universal Terrestrial Radio Access Network (E-UTRAN)
? ? Evolved Packet System(EPS)
? ? 其中eNB即是所謂的基站按摘，它由BBU和RRU兩部分構(gòu)成包券。RRU是Remote Radio Unit 遠(yuǎn)端射頻模塊，BBU是Building Baseband Unit 室內(nèi)基帶處理單元炫贤。
? ? 為什么要引入3GPP通信協(xié)議兰珍？
? ? eNB位于UE和EPC之間侍郭，UE在接入（比如主叫主動(dòng)撥號或者被叫被喚醒）或者切換（開車過程中打電話，從一個(gè)蜂窩小區(qū)進(jìn)入到另外一個(gè)蜂窩小區(qū)）時(shí)掠河，UE發(fā)送給基站的任一條消息（EPC發(fā)送給eNB的消息同此理）都是為了發(fā)送給核心網(wǎng)亮元，只有經(jīng)過核心網(wǎng)才能達(dá)到其實(shí)現(xiàn)通信的目的。手機(jī)可能是蘋果公司生產(chǎn)的唠摹，eNB可能是中興/華為的爆捞，核心網(wǎng)可能是愛立信的，為了正常通信一定得規(guī)范一套協(xié)議勾拉，只要我發(fā)送信令的信元煮甥、發(fā)送的時(shí)機(jī)合乎協(xié)議盗温，就能保證不同廠家的通信設(shè)備組到一起可以正常通信，這就是3GPP通信協(xié)議成肘，也是BBU的職責(zé)卖局。
二、業(yè)務(wù)
? ? 業(yè)務(wù)需要描述的場景是完備而復(fù)雜的艇劫，對于一個(gè)具體的業(yè)務(wù)場景吼驶，F(xiàn)igure 2-1所繪的流程圖是一種有效的表述形式。
? ? UE和MME之間由控制信息也有數(shù)據(jù)信息店煞，F(xiàn)igure 2-1描述了一個(gè)UE接入過程的控制信息交互的片段蟹演。從圖中可以看到，eNB首先會(huì)起一個(gè)定時(shí)器等MME的INITIAL CONTEXT SETUP REQUEST顷蟀，等到之后進(jìn)行內(nèi)部各模塊的處理酒请，UE也相當(dāng)于是eNB的一個(gè)需要處理的模塊，處理完成后給MME回復(fù)INITIAL CONTEXT SETUP RESPONSE鸣个，不能啥都不回羞反，或者回復(fù)的消息不滿足INITIAL CONTEXT SETUP RESPONSE的格式要求。
? ? 從圖中還可以看到囤萤，在接入過程中昼窗，CONTEXT過程完成后進(jìn)行UECapabilityEnquiry過程，并且將查詢上來的UECapabilityInformation進(jìn)行處理涛舍，按MME接收的格式（UE CAPABILITY INFO INDICATION）發(fā)送到MME澄惊，這個(gè)UE Capability過程的時(shí)機(jī)不是隨時(shí)都可以發(fā)的。
? ? 控制信息的傳輸即信令富雅，包括消息號和結(jié)構(gòu)體兩部分掸驱，比如Figure 2-1中INITIAL CONTEXT SETUP REQUEST消息號對應(yīng)的結(jié)構(gòu)體如圖Figure 2-2所示。
? ? Figure 2-2描述了消息體中每個(gè)信元的含義没佑，比如MME UE S1AP ID毕贼、eNB UE S1AP ID分別代表當(dāng)前UE在MME和eNB的ID（Identity），這是任意一條S1口消息必帶的信元蛤奢，因?yàn)槿绻粭l消息沒有發(fā)給確定的UE是沒有意義的鬼癣。其它的每個(gè)信元也都有各自特定的物理意義，比如E-RAB to Be Setup List代表了UE在接入過程中同時(shí)需要建立用于傳輸數(shù)據(jù)的承載列表远剩。
? ? 3GPP不僅提供了接口和流程描述扣溺，還提供了第三方的編解碼庫，各通信設(shè)備商在按照接口的要求填寫情況下瓜晤，直接調(diào)用第三方的編解碼函數(shù)即可轉(zhuǎn)換為協(xié)議要求格式的碼流锥余，也只有協(xié)議確定了才能按協(xié)議編解碼。
? ? 3GPP只是描述了對UE和MME的通信規(guī)范痢掠，各通信設(shè)備商都以此為唯一標(biāo)準(zhǔn)驱犹。同時(shí)嘲恍，基站內(nèi)部內(nèi)部模塊間通信也是通過信令交互完成的，由于模塊間的分工雄驹、依賴關(guān)系和產(chǎn)品需要支持的不同硬件佃牛、不同架構(gòu)等，提出了大量的業(yè)務(wù)需求医舆。
? ? Figure 2-3中為BBU機(jī)框圖俘侠，機(jī)框支持“1~2塊CC板”加上“1~6塊BPL板”。
? ? 數(shù)據(jù)反傳功能會(huì)涉及哪些業(yè)務(wù)場景：
? ? UE切換時(shí)蔬将，可能MME下發(fā)的數(shù)據(jù)包傳輸了一半爷速，在原來位置（BPL）的數(shù)據(jù)傳輸情況不能直接傳到目標(biāo)側(cè)（BPL），由于背板總線的原因需要采用CC板的霞怀、信令傳輸?shù)姆绞竭M(jìn)行傳遞惫东。會(huì)出現(xiàn)多種數(shù)據(jù)反傳場景。如Figure 2-4到Figure 2-6所示毙石。
? ? 業(yè)務(wù)場景多樣而且復(fù)雜廉沮，要保證特性功能運(yùn)行正確、代碼有利于維護(hù)徐矩，是一件非常具有挑戰(zhàn)性的問題滞时。
三、代碼
? ? 第一滤灯、普遍地漂洋，從代碼的邏輯梳理出代碼的業(yè)務(wù)功能是一件很麻煩的事情；但是如果大致知道代碼的業(yè)務(wù)需求力喷，再看代碼的業(yè)務(wù)需求，會(huì)輕松很多演训。所以不論是講解代碼還是開發(fā)代碼弟孟，業(yè)務(wù)是基礎(chǔ)。第二样悟、代碼的目的是給機(jī)器執(zhí)行的拂募，但是，更重要的是代碼是要便于人能夠很好的理解窟她，如果一套代碼功能無誤陈症，但是可讀性差或者根本就沒有可讀性，這套代碼肯定是會(huì)被廢棄的震糖，因?yàn)楹竺娴娜藷o法在此基礎(chǔ)上新增功能或修改故障录肯。
? ? 控制面的代碼量大概是20萬行的規(guī)模，業(yè)務(wù)的正確理解是前提吊说，它還有這些特點(diǎn)：
? ? 代碼分層設(shè)計(jì)：C++面向?qū)ο笤O(shè)計(jì)论咏，類似Figure 2-4优炬、Figure 2-5、Figure 2-6的整個(gè)圖的流程都分別是一個(gè)類Transaction厅贪。既然是流程控制蠢护，肯定是一套完備的、能表述C語言流程圖的控制邏輯养涮，比如SEQUENTIAL葵硕、FORK...JOIN、FINALLY等類贯吓，SEQUENTIAL將傳給本類的所有事物按順序逐條執(zhí)行（Figure 2-4懈凹、Figure 2-5、Figure 2-6都屬于這類情況）宣决，F(xiàn)ORK將傳入本類的所有事務(wù)并發(fā)執(zhí)行蘸劈，在一個(gè)確定的時(shí)機(jī)去等待所有事務(wù)執(zhí)行完成（JOIN）、FINALLY會(huì)在業(yè)務(wù)流程走完后做一些清理或者其它需要的工作尊沸。它們分別被劃分為Infra/Sched/traffic等層威沫。
? ? 模板和模式：業(yè)務(wù)中各種的流程圖就有超過100張，很多地方需要消除重復(fù)洼专，也是形成統(tǒng)一的編碼規(guī)范和風(fēng)格棒掠，需要大量使用模板。如前文看到的E-RAB to Be Setup List這種List屁商，需要使用訪問者模式烟很、對于KPI上報(bào)數(shù)據(jù)搜集需要使用監(jiān)聽者模式，固定的模式利于寫也利于讀蜡镶。Figure 2-6中的發(fā)送EV_X2_SN_STATUS_TRANSFER這個(gè)動(dòng)作在流程圖的每個(gè)步驟都會(huì)用到雾袱，代碼中將其設(shè)計(jì)成一個(gè)Action類，對外提供了和Transaction的接口官还，對內(nèi)提供了builder（數(shù)據(jù)構(gòu)建芹橡、編碼），sender望伦，waiter等邏輯林说，這也相當(dāng)于是一種協(xié)議，也是一種模式屯伞，省時(shí)省力腿箩。
? ? 多繼承：每個(gè)UE實(shí)例在eNB內(nèi)是一塊兒12k左右的數(shù)據(jù)，里邊存儲(chǔ)了大量的UE相關(guān)信息劣摇，12k大小的數(shù)據(jù)怎么管理珠移？代碼中使用了多繼承的數(shù)據(jù)組織形式。多繼承的每一個(gè)父類都能根據(jù)業(yè)務(wù)領(lǐng)域做到高內(nèi)聚低耦合，要找每個(gè)特性的時(shí)候就能方便找到剑梳。
? ? 信令：如果一個(gè)業(yè)務(wù)流程失敗了唆貌，通過信令對照流程圖能迅速的找到是在哪個(gè)步驟異常了，再檢查信令中的信元垢乙，將一個(gè)流程很清晰的呈現(xiàn)出來锨咙，專職的測試人員不用看代碼，通過信令就基本能夠確定開發(fā)人員的特性實(shí)現(xiàn)正確與否追逮。
? ? KPI：為了衡量一個(gè)系統(tǒng)運(yùn)行情況的好壞酪刀，業(yè)務(wù)定義了一系列的KPI指標(biāo)，它相當(dāng)于一把尺子钮孵，對運(yùn)營商呈現(xiàn)出軟件運(yùn)行情況骂倘，當(dāng)然運(yùn)營商也有第三方的監(jiān)測軟件。
? ? 如此龐大的項(xiàng)目巴席，保證通暢有序的工作是一件很大的工程历涝，管理上由很多有益的實(shí)踐：
? ? 多級CI。在每次代碼合入時(shí)都需要經(jīng)過系統(tǒng)CI漾唉，CI的意思是持續(xù)集成荧库，業(yè)務(wù)、平臺(tái)赵刑、基帶各自在自己的二級CI上保證代碼沒有問題分衫，然后合入到一級CI，合入每級CI前需要驗(yàn)證通過般此，合入每級CI后需要回歸測試完成蚪战，CI本身又設(shè)置了很多的校驗(yàn)項(xiàng)保證代碼質(zhì)量。
? ? 商用代碼監(jiān)測軟件铐懊。商用代碼監(jiān)測軟件是二級CI的其中的一個(gè)校驗(yàn)項(xiàng)邀桑，比如我們寫的switch...case語句，按規(guī)范每個(gè)case都需要break科乎，如果待合入代碼違反了就會(huì)攔截不讓合入概漱，再比如代碼為業(yè)務(wù)死代碼，永遠(yuǎn)執(zhí)行不到等等喜喂，各種各樣。
? ? 大規(guī)模FT竿裂。每開發(fā)的一個(gè)業(yè)務(wù)特性時(shí)玉吁，需要新增FT，保證業(yè)務(wù)邏輯腻异，同時(shí)进副，之前別人寫的保證業(yè)務(wù)邏輯的FT已經(jīng)幾千條了，要保證所有FT通過，即既要保證自己的特性軟件仿真通過影斑，又要保證不影響之前的代碼的邏輯给赞。
? ? RF測試部署。FT的通過基本能保證代碼的質(zhì)量矫户，但是由于模塊間的接口片迅、FT不能完全真實(shí)構(gòu)造場景的局限性等，F(xiàn)T不能替代真實(shí)環(huán)境的測試皆辽。RF測試用例通過python自動(dòng)化腳本自動(dòng)化的執(zhí)行一些基本的業(yè)務(wù)流程柑蛇，又叫冒煙測試，保證不會(huì)讓整個(gè)大項(xiàng)目癱瘓驱闷。
? ? wiki耻台。wiki有些相當(dāng)于公共的blog，我們在編碼空另、軟件安裝盆耽、腳本學(xué)習(xí)時(shí)有太多不會(huì)的地方，比如python的類庫如此的多以至于不可能把每個(gè)類庫都接觸到扼菠，我們百度一下就都知道了摄杂。工作內(nèi)容紛繁復(fù)雜，需要記筆記的及時(shí)記筆記娇豫，東西太多不能都記得住匙姜，記住了也不能保證不忘，每個(gè)團(tuán)隊(duì)內(nèi)各成員大家參與冯痢、大家受益氮昧。
? ? 敏捷管理。敏捷管理屬于管理制度的范疇浦楣，每個(gè)公司的管理制度都各不相同袖肥，敏捷管理形成了一套方法論，比如任務(wù)卡墻振劳、7-13人小團(tuán)隊(duì)化椎组、輪值制度、OKR讓自己制定自己的目標(biāo)等历恐，對發(fā)揮個(gè)人能動(dòng)性寸癌，集思廣益，組織有序和民主等都是很好的實(shí)踐弱贼。
