網絡安全綜合報告精選(九篇)
前言：一篇好文章的誕生，需要你不斷地搜集資料、整理思路，本站小編為你收集了豐富的網絡安全綜合報告主題范文，僅供參考，歡迎閱讀并收藏。
第1篇：網絡安全綜合報告范文
關鍵詞：惡意移動代碼；蜜罐技術；監測；數據采集
中圖分類號：TP309.5文獻標識碼：A文章編號：1672-7800（2012）010-0160-02
基金項目：河南省教育科學“十一五”規劃2009年項目（2009-JKGHAG-0321）
作者簡介：王樂樂（1985-），女，中國人民信息工程大學信息工程學院碩士研究生，研究方向為網絡安全；邢穎（1985-），女，中原工學院軟件學院助教，研究方向為網格計算與云計算。
0引言
惡意移動代碼（MaliciousMobileCode-MMC）是指在計算機之間以及網絡之間移動的任何程序代碼，這些代碼未經任何允許和授權，有意對計算機系統內容進行篡改，從而達到破壞計算機數據完整性以及降低網絡運行可用性的目的。惡意移動代碼包括計算機病毒、木馬、蠕蟲、惡意腳本以及流氓軟件等。惡意移動代碼具有自我復制和自我傳播特性，主要表現為：用戶機密信息受到威脅、造成骨干網或局域網阻塞、網絡服務中斷、僵尸網絡（Botnet）等，嚴重威脅著Internet網絡安全。蜜罐技術可通過模擬服務來獲取入侵事件的具體信息，已成為目前網絡安全領域的新興技術，本文提出的基于蜜罐技術的惡意移動代碼掃描監測模型能有效對網絡中惡意移動代碼進行監測，及早、有效地發現面臨的威脅，保護網絡與主機安全。
1常用網絡監測技術
為了減少網絡惡意侵害行為對互聯網基礎設施以及主要應用系統的危害，必須對相關網絡威脅進行監測和追蹤。目前，監測方式主要分為兩類：主機監測和網絡監測。主機監測是指在用戶主機上安裝反病毒軟件和基于主機的入侵檢測軟件，對入侵主機的已知惡意代碼進行檢測和告警。網絡監測方式中，常用技術是在活動（active）網絡中被動監聽網絡流量，利用檢測算法識別網絡入侵行為。雖然監測活動網絡擴大了監測范圍，但是如何區分活動網絡中的“善意”和惡意流量卻變得非常困難，導致檢測結果中存在大量虛警；另一種網絡監測技術是指在未使用的IP地址空間內被動收集數據。但這種集中收集惡意流量的方式割裂了惡意流量與原有活動網絡流量之間的關聯；最后一種網絡監測技術是將未使用地址空間偽裝成活動網絡空間，通過與入侵者的主動交互獲取入侵詳細信息，如蜜罐技術（HoneynetProject，相關軟件有honeyd等）。與以上兩種網絡監測技術相比，蜜罐技術能夠有效地將活動網絡中的惡意流量分離出來，監測到與活動主機相關聯的網絡入侵行為，從而達到保護網絡的目的。
2蜜罐技術
蜜罐（Honeypot）技術作為一種典型的主動防御技術，是近年來的研究熱點。蜜罐技術研究發起人LanceSpitzner給出的定義是：蜜罐是一種安全資源，它的價值體現在被刺探、攻擊或者被摧毀的時候。蜜罐系統主要包括了網絡誘騙、數據控制、數據捕獲、數據報警、數據分析和日志遠程存儲等功能模塊。
蜜罐的工作原理是通過引誘攻擊者的入侵來保護系統本身安全，能通過某種方式監測與跟蹤入侵者的行為，并將其記錄在日志中對攻擊方法進行技術分析，從而學習入侵者的工具、策略和方法。
蜜罐按照交互的級別，可以分為低、中、高三種交互級別：
低交互honeypot沒有真正的操作系統可供攻擊者使用，也不會給系統帶來額外的風險。由于它不可能觀察攻擊者與操作系統的交互過程，因此不能收集到真正有意義的信息。此階段主要提供檢測功能。
中交互honeypot設置了一些信息以供交互，但未提供一個真正的底層操作系統。因為honeypot的交互能力提高了，攻擊者發現安全漏洞的可能性也更大，所以增加了風險。
高交互honeypot有真正的底層操作系統，攻擊者能夠上傳、安裝新文件，可以與操作系統交互，也能夠攻擊各種應用程序，會給系統帶來很大的風險，但捕獲到有用信息的可能性越大。
3基于蜜罐的掃描監測原型系統設計與實現
本文在分析了蜜罐技術在實際部署中必須考慮的相關因素的基礎上，針對惡意移動代碼的特點，構建了基于蜜罐技術的惡意移動代碼掃描監測模型，目標是對校園網內的惡意掃描源進行監測和預警。模型按功能實現可以劃分為兩部分：監測部分和預警處理部分，監測部分是預警處理部分的基礎。
3.1模型構成
整個系統由6個模塊構成，如圖1所示，分別為監測數據采集模塊、數據存儲和預處理模塊、單點檢測預警模塊、檢測結果可視化模塊、多點綜合處理與預警模塊、防火墻訪問規則自動生成模塊。除監測數據采集模塊屬于監測部分外，其余模塊均屬于預警處理部分。
系統框圖如圖1所示。整個系統的數據處理流程描述如下：
監測數據采集模塊負責在監控網絡內采集惡意掃描流量，將流量數據輸送至數據存儲與預處理模塊中的數據服務器，并對存儲格式進行簡單轉換處理，然后單點檢測預警模塊分別對各采集點的流量數據進行統計分析，形成單點掃描檢測預警結果。該結果一方面由可視化模塊進行可視化，另一方面傳輸給多點綜合處理與預警模塊進行綜合處理與預警。綜合檢測與預警結果由可視化模塊進行可視化輸出，同時由防火墻規則自動生成模塊生成防火墻訪問規則，與防火墻聯動對惡意掃描源行為進行控制。
3.2監測數據采集模塊
監測數據采集模塊為模型的基礎模塊，只有監測數據采集準確，才能提供有效的處理信息給后續預警分析。在監測數據采集模塊中，首先應該確定監測點在網絡中的部署位置。因為本文系統提出的設計目標是監測校園網內的惡意掃描源，所以監測重點是出現在校園網內部的掃描連接，根據部署原則，監測點需要部署在校園網防火墻內，并且是由內部路由器連接的網絡中。由于蜜罐技術可以把網絡中路由未使用的IP地址偽裝成“活動主機”，因此在內部網絡中，監測點主要以活動主機的形式存在。
3.3單點檢測預警模塊
單點檢測預警模塊為模型的核心處理模塊之一，其功能是對各個監測采集點數據進行獨立統計，并且進行掃描源與掃描端口的監測、報警、預警。根據蜜罐的工作原理，訪問蜜罐的網絡行為被認為未授權或惡意行為，所以基于蜜罐技術的掃描監測模型捕獲到的流量一定是純的異常流量。本文采用的蜜罐技術可以直接確定訪問源性質，從而將研究重點集中在掃描源行為的研究而不是在掃描源識別上。
3.4可視化模塊
可視化模塊是實現數據檢測結果方便用戶可視的重要模塊，主要由Web網頁相關處理腳本構成，建立了專門的Web網站掃描源檢測處理可視化結果。網站可以自動更新每日掃描源檢測報警、預警結果，提供數據庫查詢接口頁面，并且為用戶提供以日、周、月為單位的掃描源檢測結果。
3.5多點綜合處理與預警模塊
多點綜合處理與預警模塊是模型的核心模塊，其功能是以時間為尺度對各個單點檢測報警的結果進行關聯分析和綜合分類，從而形成來自于不同的監控網段共同掃描行為的綜合報警和預警報告，并且將結果輸入到防火墻訪問規則自動生成模塊，進而對后續相同的掃描源的惡意移動行為進行控制。有關關聯分析處理參閱文獻。
3.6防火墻訪問規則自動生成模塊
當今網絡中普遍采用的網絡安全防御部署系統主要有防火墻、入侵防護系統（IPS）和入侵檢測系統（IDS）等。這幾個系統的基本工作原理是根據一定的訪問控制規則對惡意移動行為進行邏輯判斷，因此如何提取和制定控制規則對于這些網絡安全防御系統的正常運行起著重要作用。因為蜜罐技術具有針對性強、檢測準確的檢測優勢，所以檢測結果可生成相對應的訪問控制規則，并且反饋給其他廣泛應用的網絡安全防御系統使用，以便于發揮更大的檢測效用。
4結語
蜜罐技術是目前網絡安全領域的新興技術，通過模擬服務來獲取入侵事件的具體信息，通過在一臺物理主機上虛擬網絡和不同操作系統的主機來擴大監測地址空間。本文主要工作為：設計了基于蜜罐技術的惡意移動代碼掃描監測模型，并對監測數據采集模塊、數據存儲和預處理模塊、單點檢測預警模塊、檢測結果可視化模塊、多點綜合處理與預警模塊、防火墻訪問規則自動生成模塊等各個模塊進行了詳細介紹，此模型能有效檢測惡意移動代碼威脅。模型的具體實現，以及多矢量傳播監測系統部署問題是下一步研究的主要工作。
參考文獻：
[1]GRIMESRA.MaliciousMobileCode[C].USA：O’Reilly&Associates，2001.
[2]SymantecCorporation[EB/OL].http：//.1995/20075-10-29.
[3]SANS.Sans-InternetStormCenter-CooperativeCyberThreatMonitorandAlertSystem[M].Press，2004.
[4]HoneynetProject[EB/OL].2003-01-01/2007-05-15.http：//.
第2篇：網絡安全綜合報告范文
關鍵詞：城市供水 水質監控信息系統
1. 項目背景與意義
江蘇經濟發達，同時也是全國水污染承載量最大的地區之一，加之地處江淮尾閭，上游客水污染、本地城鎮化工業化快速發展帶來的工業污染、生活污染、農業面源污染交織，全省集中式飲用水源地原水水質不容樂觀。近年來因水源突發污染影響的供水安全事故日增，水源突發性污染已嚴重威脅城市供水安全，直接影響到人民群眾的身體健康和社會穩定。因此，江蘇省住房城鄉建設廳從2008年底開始研究建立水質在線監測平臺，動態監控供水水質情況和變化趨勢，保障城市供水安全。
2. 總體技術架構
江蘇省城市供水安全動態監控系統建設采用分布式應用設計理念，共享省級主管部門和供水企業數據采集與監視控制系統、實驗室信息管理系統、視頻監控系統等已建系統的軟件、硬件和網絡資源，構建省、市、縣（市、區）一體化監控平臺。省級硬件平臺采用虛擬化技術，整合已有硬件和網絡資源，形成可靈活配置擴展的基礎設施虛擬資源池。按照統一數據標準和交換標準，形成水質信息、供水企業基礎信息、GIS信息、視頻信息等數據資源層，在此基礎上，構建省、市、縣一體化應用系統。
3. 功能實現和關鍵技術研究
3.1核心功能
水質監控：實現全省城市供水企業實驗室水質檢測數據和太湖流域城市供水企業在線水質檢測數據從源頭到龍頭的全流程監測監控。包括水源水日報11項、出廠水日報11項、管網水半月報6項、水源水月報29項、出廠水月報42項、管網末梢水月報42項、出廠水半年報106項實驗室水質檢測數據和11項在線水質檢測數據。
水質異常分析：通過應用滑動平均算法和自回歸滑動平均模型，對水質異常情況進行分析，實現自動篩選可疑數據，并提供人工干預，對可疑數據進行處理，排除脈沖噪聲、設備故障等外在因素干擾，提升水質安全預警預報的準確性。
水質預警預報：通過與國家水質標準自動比對和水質異常分析，實現水質指標異常報警和所屬流域下游供水企業的預警預報，并與手機等移動終端聯動報警，基于GIS地圖整合報警供水企業的地理位置、水質指標、取水口視頻、企業基礎信息等圖文和視頻數據，為提高城市供水安全預警和應急處置能力提供技術支撐。
水質趨勢分析：通過同期水質指標比對、上下游水質指標比對、實驗室人工檢測指標和水質檢測設備自動檢測指標比對等綜合水質數據分析，實現對水質變化趨勢的預測預判，為建立污染源擴散、水質變化趨勢等模型提供理論基礎，為水質預警、科學決策等提供技術支撐。
水質報告：基于系統中的數據，實現全省供水能力、全省深度處理規模、全省重點流域水質超標情況、太湖水質報告等各類可定制統計報表和水質報告的自動生成，提升主管部門信息化管理水平和效能。
水質共享：通過建立城市供水水質信息共享平臺，實現重點流域上下游水質信息共享，為有效防范流域性水源污染所引發的供水危機提供技術支撐。同時，與全國城市供水信息系統實現數據對接和共享。
視頻監控：通過在太湖流域重點水源地設立視頻監控點，實現對無錫、蘇州等8個市、區供水企業取水口進行實時視頻監控，并利用移動偵測等視頻識別技術，對過往船舶等異常情況進行預警預報。
3.2關鍵技術研究
3.2.1江蘇省城市供水數據標準編制
由于系統需要整合省級主管部門和供水企業SCADA、LIMS、視頻監控等已有硬件、網絡和系統資源，為解決全省城市供水企業異構系統之間數據采集和交換問題，研究編制《江蘇省城市供水基礎數據與水質數據信息規范》，包括供水企業、水源地、取水口、供水基礎設施、處理工藝、安全保障等基礎數據和實驗室水質檢測數據、在線水質檢測數據信息規范，供水企業、水質指標編碼規則，數據交換接口規范等，為建立水質數據共享平臺奠定基礎。
3.2.2數據模型在水質檢測及預警中的應用
在對實際水質檢測數據分析過程中，發現存在工藝操作、設備故障、脈沖噪聲等較多誤報現象，為實現快速準確預警，需進一步完善水質異常檢測及預警方法。本系統采用基于信息處理的數據分析方法，包括滑動平均算法：
和自回歸滑動平均模型：
結合GIS、Flex（Web應用框架）等技術，對水質監控信息進行多維動態分析，分析研究水質在不同時間序列的數據中所隱含的變化規律，初篩并處理可疑數據，實現對復雜多變的水環境進行較為準確的異常檢測和預報預警。
3.2.3數據采集、傳輸與網絡安全保障
供水企業中控系統部署在內部局域網，涉及到生產、調度、應急等重要信息系統，為實現從企業中控系統中采集在線水質檢測數據，同時確保數據采集過程中企業內網的安全，在供水企業部署前置系統，通過前置服務器、物理隔離設備、防火墻，將企業內網與互聯網物理隔離，在前置服務器與省級服務器之間通過VPN設備建立虛擬專網，實現數據專網加密傳輸。
4. 項目應用和效益
系統投入正式運行以來，應用面已覆蓋全省13個市級主管部門、77家自來水公司、143座水廠，其中實驗室水質檢測數據監控已實現全覆蓋，在線水質檢測數據監控已實現太湖流域全覆蓋。2014年，全省供水企業實驗室水質檢測數據中的水源水日報和出廠水日報年均上報率達98.33%和99.78%，其中太湖流域實驗室水質數據上報率和在線水質數據監控率均達到100%。截至2014年底，系統已形成包括50多萬條實驗室水質檢測數據、240多萬條在線水質檢測數據的水質數據庫，為江蘇省城市供水年度發展報告、太湖水質報告的編制和城市供水安全預警預報、水質模型分析、科學決策提供了強有力的數據支撐。
5. 總結與展望
系統建成以來，對提升城市供水主管部門監管水平，保障城市供水安全發揮了重要作用。下階段，逐步擴大在線水質檢測數據監控的應用范圍，將系統在太湖流域的應用模式在長江、淮河等其他流域推廣應用，實現全省城市供水在線水質監控全覆蓋。積極探索與環保、海事、水利等部門研究建立水源水質監測信息、水源地危化品船舶信息、水文監測信息等數據共享平臺，制定應急處理預案，構建跨部門、跨領域的預警監控和應急處理體系，共同為江蘇省水資源保護，讓百姓喝上優質安全飲用水，提供更科學有效的信息化監管手段。
參考文獻：
[1] 生態文明建設與可持續發展. 人民出版社，2011.
第3篇：網絡安全綜合報告范文
【關鍵詞】LTE基站 自啟動 端到端 故障處理
1 引言
傳統無線網的基站建設和開通模式無論采用TDM（Time Division Multiplexing，時分復用）組網還是IP（Internet Protocol，網間互連協議）組網，都需要在基站開啟環節進行相關的調測及參數配置工作，主要包括設備的軟硬件架構、模塊及板件的聯接模式、小區/扇區與天饋線的映射關系、網絡參數、傳輸參數（包括物理層、鏈路層、網絡層）的配置等。這部分的配置工作對人員的技術水平有較高要求，無法依賴建站的現場施工人員來操作，而只能通過專門的開站技術人員逐一上站并現場完成，工作量大且極易出錯。特別是在IP組網的情況下，網絡結構由點到點的資源獨占變為多點間扁平化的資源共享，網元關系由相互間強耦合變為弱耦合，傳輸資源及傳輸參數的配置由于IP化的引入變得更加靈活、難度更大，對開站人員的素質水平和技能要求也就有了更高的要求。
自配置過程是網絡中新增節點的自動操作環節，它是指通過自動配置的方式完成無線網的eNodeB（Evolved Node B，演進型Node B）加電、網絡連接、射頻發射機開啟乃至可承載業務的全過程，包括自啟動和無線配置兩大環節。其中，自啟動包括IP地址配置與OMC-R（Operations and Maintenance Center for Radio，無線接入網網管）的檢測及鑒權、與核心網建立連接、eNodeB軟件與運行參數下載等；無線配置包括物理小區lD分配、鄰小區列表建立、覆蓋與容量參數配置等。自啟動功能可以在相當大的程度上提升開站效率、降低開站成本、減少人員投入，其已成為無線網建設、維護及優化中不可或缺的手段。
2 基站自啟動關鍵技術及工作原理
2.1 關鍵技術
（1）VLAN
VLAN（Virtual Local Area Network，虛擬局域網）技術使得網絡管理員可以根據不同實際情況，將同一物理LAN（Local Area Network，局域網）網內的不同用戶按照特定邏輯分成若干個獨立的廣播域，與物理上形成的LAN有著相同的屬性。一個VLAN內部的廣播或者單播流量是無法傳播到其他VLAN中的，使流量的控制、網絡的管理、設備的維護、網絡安全保證都得到了有效優化。
（2）DHCP
DHCP（Dynamic Host Configuration Protocol，動態主機配置協議）是一個應用于局域網的網絡協議，基于UDP（User Datagram Protocol，用戶數據報協議）協議工作，用途是給內部網絡或者網絡服務供應商自動分配IP地址并對IP進行管理，其可以顯著提升IP地址的使用率。DHCP協議采用客戶端/服務器模型，主機地址的動態分配任務由網絡主機驅動。當DHCP服務器接收到來自網絡主機申請地址的信息時，才會向網絡主機發送相關的地址配置等信息，以實現網絡主機地址信息的動態配置。
新建基站采用自啟動模式開通時，相應的DHCP消息流程如圖1所示。
具體如下：
由于基站沒有配置，使用“0.0.0.0”為源地址，發送DHCP廣播包（DHCP Discover）。
DHCP Relay Agent收到V播包后，使用單播的方式向DHCP服務器轉發。
DHCP服務器向DHCP Relay Agent下發配置。
DHCP Relay Agent將收到的配置向客戶端轉發。
無論是否存在Relay，都要4條消息完成一個DHCP過程。
2.2 工作原理
基站自啟動技術涉及的網元主要包括eNodeB與OMC-R。在OMC-R側，遠程管理人員將所需開站的基站規劃數據通過批量生成工具導入OMC-R；在eNodeB側，現場施工人員在完成機房、動力配套、天饋線及主設備安裝，并與傳輸專業確認接入層傳輸設備已調通之后，只需要將eNodeB所帶的傳輸功能板卡與接入層傳輸設備通過網線連接并上電，eNodeB經上電自檢后如運行無誤則通過指示燈顯示正常。eNodeB在自檢通過后，根據其設備內自帶的缺省配置信息，自動依據網絡的具體類型獲取相應參數并與相應的OMC-R完成連接。OMC-R提供操作維護（OM）通道，使eNodeB能夠完成配置及版本下載，并進行資產更新和自測試，最終完成啟動。在無需人工干預的條件下，eNodeB能夠自動按配置建立S1連接，小區和公共信道達到可服務的狀態。OMC-R支持相關信息以綜合報告的形式在友好的人機交互界面上進行顯示，同時支持遠程管理人員針對特別關注項進行實時查詢。
3 自啟動問題的端到端分析手段、定位方法與核查問題點
為了提升LTE基站自啟動工作的效率，從端到端網絡結構入手，結合開站實施過程及自啟動流程，總結了基站自啟動的關鍵問題點及處理方法。
3.1 自啟動工作流程及核查問題點
（1）準備工作
基站自啟動前需要在無線側、PTN（Packet Transport Network，分組傳送網）側及OMC-R側做一定的準備，具體準備工作如下：
無線側：完成制作目標站點的開站列表和配置文件。
PTN側：L2/L3設備完成調測。
OMC-R側：完成軟件調測，具備掛接站點能力，與各地市路由打通。
（2）自啟動開站
階段一：上站完成站點硬件安裝、與天饋線及傳輸接入層設備的聯接并上電。
階段二：開站列表、配置文件、網元版本等文件導入OMC-R的即插即用模塊。
階段三：ESN（Electronic Serial Number，電子序列號）上報后在開站列表中綁定ESN號。
階段四：在DHCP消息打印中確認目標站點的4條DHCP握手消息。
階段五：OMC-R開始下發并激活配置、軟件版本、License等文件。
（3）各階段常見問題及核查關鍵點
階段一：
常見問題：主控板與PTN連接光口指示燈異常。
eNodeB核查點：主控板指示燈閃爍是否正常；光模塊是否是1.25 G/10 km；光纖收發是否反接，光路是否正常；基站上電49天未開通不會上報帶VLAN的報文。
PTN核查點：傳輸設備是否存在告警；PTN的物理端口配置是否均是光口千兆全雙工；光模塊是否是1.25 G/10 km。
階段二：
常見問題：無DHCP Discover上報。
eNodeB核查點：PTN端口是否插錯；基站側DHCP開關是否打開。
PTN核查點：檢查PTN盒子和LTE基站直接對接的GE（Gigabit Ethernet，千兆以太網）端口基本配置，要求為TAG模式，檢查PW配置數據，確認VLAN是否正確；執行LB測試，確定L2/L3到基站的L2 PW是否是通的；L2/L3 PTN上是否開啟DHCP Relay功能；L2/L3 PTN配置的DHCP Relay目的IP地址是否跟o線OMC-R網管IP一致，L2/L3 PTN帶網關IP地址是否可以PING通OMC-R服務器IP；傳輸的L2/L3設備是否正確配置數據，包括IP地址、路由等；確認L3 PTN與本地網管網已正常對接，物理上已連通。
網管網核查點：網管網是否做了路由策略的約束；防火墻是否做了安全加固策略，導致DHCP報文無法透傳；防火墻來回路徑不一致檢測功能是否關閉。
OMC-R核查點：網管上是否創建了開站列表并啟動偵測；目標站點是否已在其他網管上開啟。
階段三：
常見問題：ESN號未綁定。
eNodeB核查點：站點ESN號是否正確填寫。
階段四：
常見問題：開站仍停留在OM通道檢測階段。
eNodeB核查點：開站列表中ESN是否綁定了錯誤的站點；開站列表中的IP、VLAN是否正確；維護通道割接失敗場景下，業務正常的站點發起自啟動會失敗。
PTN核查點：是否數據配置與傳輸調單不一致，如IP、VLAN等；是否漏配置虛接口；核查傳輸接入環到核心環的數據制作。
階段五：
常見問題：加載過程中超時。
eNodeB核查點：配置文件中的IP、VLAN是否正確；配置文件的版本與實際網元版本是否一致；網元與PTN的物理端口配置是否均是光口千兆全雙工。
3.2 端到端分析手段與定位方法
LTE的OMC-R一般采用集中建設模式，不同地市的基站通過本地L3 PTN傳輸接入本地市的網管網，再連接至省網管網，最終接入LTE的OMC-R所在地市的網管網。其端到端組成需要經歷以下環節：
（1）本地網傳輸（PTN，主要是華為、中興設備）。
（2）本地網管網（交換機、路由器、防火墻，主要是思科、華為設備）。
（3）省網管網（路由器、防火墻，主要是思科設備）。
（4）OMC-R所在地市的網管網（交換機、路由器、防火墻，主要是華為、思科設備）。
對于基站自啟動問題的定位，分段抓包、逐點定位是比較有效的方法。由于涉及跨地市、跨專業，因此一定要先分析清楚整個網絡端到端的組網結構，找出網絡中的關鍵節點，這樣才能提高抓包的效率，具體如圖2所示：
抓包方法定位思路如下：
（1）在位置①處eNodeB側抓包，確認eNodeB是否成功將DHCP報文發送出來。如果未發，則直接定位為eNodeB問題，否則進入步驟（2）。
（2）在位置②處抓包，確認PTN主用L3設備DHCP報文收況。如果抓包顯示沒有DHCP報文發送，則說明中間PTN網絡問題導致DHCP報文丟失；如果只有DHCP發送而沒有DHCP回應，則進入步驟（3）。
（3）在位置③處抓包，確認OMC-R是否接收和響應DHCP報文。如果只有發送而沒有響應，則定位為OMC-R服務器問題，否則進入步驟（4）。
（4）在位置④處抓包，確認該處是否可以收到OMC-R響應的DHCP報文。如果沒有收到，則說明PTN和OMC-R中間網絡丟棄了DHCP回應報文；如果有收到，則繼續深入檢查PTN L3數據配置是否正確，否則備用L3設備應該將該DHCP回應報文送給主用L2/L3。
4 故障案例分析
案例1：采用中興PTN的基站能正常上報ESN，采用華為PTN的基站無法上報ESN
（1）故障現象
某地市LTE基站開通過程中，采用中興PTN的基站能正常上報ESN，而采用華為PTN的基站無法上報ESN，經核查相關路由均已添加。
（2）問題分析
站點ESN通過本地PTN（故障站點使用華為PTN，而中興PTN站點不存在此問題）及網管網發送到OMC-R，在華為PTN進入路由器的端口鏡像抓包，發現攜帶基站ESN號的DHCP Discover的報文已經PTN送出；在本地網管網連接位于深圳的省網管網端口進行抓包，同時抓到了華為和中興的PTN送往深圳網管的帶有基站ESN號DHCP報文；在抓到的信令中分別選取兩個中興PTN和華為PTN上報的DHCP報文，根據報文中的ESN號與無線OMC-R核對，結果顯示華為PTN下基站的ESN號僅能上報至東莞本地網管，而中興PTN下的基站ESN號可以在東莞和深圳的4套網管上報。
選取兩個典型站點東莞塘邊村F-LH（華為PTN）、東莞嶺廈公園F-LH（中興PTN），拉通整網進行抓包，在本地L3 PTN的出口處、本地網管網出口處、省管到深圳網管網入口處、OMC-R近端交換機這幾個點同時進行抓包比對，看到現象如下：
在深圳網管網入口處、OMC-R近端交換機這2個抓包點只能抓到中興PTN下站點上報的ESN。
在東莞本地網管網出口處可以抓到基站上報的ESN，既有中興PTN下的基站，也有華為PTN下的基站。
從東莞本地網管網出口處抓到的報文分析，華為PTN下基站的中繼報文都是從業務網段送往OMC-R的，即100.65.X.X；而中興PTN下基站的中繼報文都是從維護網段送往OMC-R的。
東莞站點采用雙IP方案：一個業務IP，一個維護IP。正常情況下基站自啟動時，相關報文應該由維護網段送出。經過PTN分析，發現PTN網關在發送DHCP Relay報文時選擇機制上不合理，選擇了通過業務網段VLAN帶上來的信息，因此需要修改選擇機制。
LTE eNodeB與OMC-R之間的路由架構如圖3所示。
（3）故障處理
由于省網管網及深圳網管網只放通了各地市基站的維護網段，而華為PTN下的DHCP報文是由業務網段送出的，無法傳送至OMC-R，因此協調深圳網管網將東莞本地業務網段放通之后，問題得到解決，ESN號正常上報。
案例2：激活數據98%時網元連接超時問題
（1）故障現象
某地市開通LTE站點，多個站點正常綁定ESN，相關流程都正常的情況下，到激活數據98%時出現網元連接超時現象，導致站點無法正常開通，OMC-R顯示基站圖標是打叉的（連接不上），但從另一個相鄰基站通過X2口可以PING通此故障基站的業務IP地址，嘗試在OMC-R重連無作用。
（2）問題分析
由以上操作可知，業務IP地址已在基站側生效，但OM維護通道一直無法建立，通過采集故障基站的主控板的一鍵式日志分析，原因為開站列表中分配的OM IP與配置文件中分配的OM IP不同所致。
（3）故障理
修改配置文件中分配的OM IP，待基站重新進行自啟動后正常完成站點開通。
案例3：PTN業務上下行路徑不一致，導致基站無法正常建立OM通道
（1）故障現象
某地市LTE開站時，部分站點ESN號可以上報，但是配置文件無法正常下發，OMC-R提示基站處于正在檢測OM通道狀態。
（2）問題分析
如圖4所示，在基站側抓取基站MAC報文，根據抓包的內容來看，基站已經生效了OM IP（100.65.193.225），并且已經給PTN回了ARP（Address Resolution Protocol，地址解析協議）響應。但PTN還是一直在發送ARP請求，從現象來看一直沒學到基站的MAC地址。
在PTN側進行抓包，在PTN側進行報文的統計分析時發現：其主傳輸鏈路的L2/L3節點網元7996的V-UNI（User Networks interface，用戶網絡接口）統計只有發送流量而無接收流量，在備傳輸鏈路的L2/L3節點網元7997的V-UNI統計則相反，只有接收流量。這說明業務的上下行流量在L2/L3節點與L3節點之間走的路徑不同，具體如圖5所示。
通過以上分析定位，確定該站點OM通道無法正常建立的原因是上下行流量經過的路徑不一致導致ARP學習異常。
（3）故障處理
由傳輸專業將備L3的VPN FRR（Fast ReRoute，快速重路由）配置倒換到備用路徑，使得流量直接路由轉發到主L2/L3設備，ARP信息可以被正常學習到，基站業務下發配置正常。
對VPN FRR功能的說明：FRR是一種實現網絡局部的、臨時性保護措施的技術。該協議通過為主路由（或路徑）建立備份路由的方式，當主路由出現故障時能夠迅速切換到備份路由上，而當主路由恢復正常時又可以快速切換回來。目前該技術可以支持IP FRR、VPN FRR和TE FRR。VPN FRR主要應用在CE雙歸屬的VPN網絡環境中，其利用網絡中的備份隧道為主用隧道做備份，并結合BFD等快速探測技術來檢測主用隧道的連通性。當主用隧道故障時，部署VPN FRR功能的PE設備在VPN路由收斂完成之前就可以將VPN流量切換到備份路徑上，從而提高了公網數據轉發的可靠性。
5 結束語
作為SON（Self-Organized Network，自組織網絡）在網絡建設與部署中的典型應用模式，基站自啟動功能在現階段大規模的網絡建設及運營期間，已成為LTE無線網快速開通和承載業務的必要手段。有針對性地處理好基站自啟動環節中出現的各種故障，是網絡建設過程中亟需解決的關鍵問題。本文通過分析LTE基站自啟動功能的關鍵技術、工作原理以及常用的端到端故障分析方法和處理手段，總結了在省內既有的網管網及PTN承載網絡架構現狀下，各類LTE基站自啟動問題的存在問題及處理經驗，從而有效提高了相關故障問題的端到端解決效率，切實滿足了LTE無線網大規模建設及開通的進度要求。
隨著LTE/LTE-A時代網絡技術的不斷發展演進、網絡結構的巨大轉變以及用戶對無線通信需求的不斷增加，未來網絡維護和優化的難度及復雜度將越來越大。以基站自啟動為代表的SON技術可顯著減少常規的手工配置和優化工作的人力需要，從而提高了網絡運維人員的工作效率，增強了網絡的可維護性，并間接提升了網絡性能，最終達到改善終端用戶的業務感知質量的目的。因此，深入研究SON技術并大規模應用于現網運營，是解決在未來網絡維護和優化工作量劇增背景下提升網絡服務質量并降低網絡運營成本的一條有效途徑。
參考文獻：
[1] 張威. GSM交換網絡維護與優化[M]. 北京： 人民郵電出版社， 2005.
[2] 張威. GSM網絡優化――原理與工程[M]. 北京： 人民郵電出版社， 2003.
[3] Seppo Hamalainen， Henning Sanneck， Cinzia Sartori. LTE自組織網絡（SON）：網絡管理自動化提升運維效率[M]. 王健全，烏云宵，王波，等譯. 北京： 機械工業出版社， 2013.
[4] Harri Holma， Antti Toskala， Jussi Reunanen. LTE小基站優化：3GPP演進到R13[M]. 堵久輝，洪偉，譯. 北京： 機械工業出版社， 2016.
[5] 張長青. TD-LTE自組織網絡SON技術分析和建議[J]. 移動通信， 2012，36（22）： 54-59.
[6] 朱亞威，馬賽，郝建鋼. 基站自啟動技術的原理與設計[J]. 電子設計工程， 2016（12）： 118-120.
[7] 朱曉光，江華. LTE基站系統的PCI自配置技術研究[J]. 電信科學， 2014（7）： 130-134.
[8] 王映民，孫韶輝. TD-LTE-Advanced移動通信系統設計[M]. 北京： 人民郵電出版社， 2012.
