【正文】 性能要求。2 規(guī)范性引用文件下列文件中的條款通過本標準的引用而成為本標準的條款。凡是不注日期的引用文件，其最新版本適用于本標準。主站：即監(jiān)控主站，主站的作用是為監(jiān)控中心與監(jiān)控從站提供數(shù)據(jù)和信息的中繼和轉(zhuǎn)發(fā)，用來直接和監(jiān)控中心通信的設備。是指在一個由多個設備組成的本地直放站監(jiān)控子網(wǎng)絡中，不能和監(jiān)控中心直接通信的設備，從站所有與監(jiān)控中心的通信包必須經(jīng)過監(jiān)控主站的轉(zhuǎn)發(fā)。MODEM（data） 使用MODEM提供的數(shù)傳方式建立通信MODEM（SMS） 使用MODEM提供的SMS（Short Message Service）方式建立通信MODEM（GPRS） 使用GSM MODEM提供的GPRS（General Packet Radio Service）方式建立通信PDU 協(xié)議數(shù)據(jù)單元（Protocol Data Unit）PSTN 公用電話交換網(wǎng)（Public Switched Telephone Network）CRC 循環(huán)冗余校驗（Cyclical Redundancy Check）IP 網(wǎng)間互聯(lián)協(xié)議（Internet Protocol）TCP 傳輸控制協(xié)議（Transfer Control Protocol）UDP 用戶數(shù)據(jù)報協(xié)議（User Datagram Protocol）OMC 監(jiān)控中心（Operate Maintenance Center）5 直放站設備接入上級網(wǎng)管系統(tǒng)或監(jiān)控系統(tǒng)方案直放站設備需提供網(wǎng)管接口，使設備可通過短信、數(shù)傳、GPRS（GPRS暫不作強制要求）等多種其中一種或多種承載方式接入上級網(wǎng)管系統(tǒng)或監(jiān)控系統(tǒng)。本規(guī)范不僅適用于“單機式”直放站系統(tǒng)，也適用于“分布式”直放站系統(tǒng)，一個由直放站系統(tǒng)、通信信道和監(jiān)控中心組成的監(jiān)控系統(tǒng)的網(wǎng)絡拓撲結(jié)構(gòu)如下圖：圖 51 監(jiān)控系統(tǒng)組成結(jié)構(gòu)圖6 直放站設備網(wǎng)管接口要求直放站設備網(wǎng)管接口要求包括接口功能要求、數(shù)據(jù)需求和性能要求等部分。網(wǎng)管接口在滿足功能要求的同時須滿足穩(wěn)定性、及時性、完整性、準確性及安全性等相關(guān)技術(shù)要求。1. 配置信息的采集和修改功能直放站網(wǎng)管接口應支持上級網(wǎng)管系統(tǒng)或監(jiān)控系統(tǒng)通過短信、數(shù)傳或GPRS方式采集或修改設備的配置信息。監(jiān)控中心應能根據(jù)設備的配置修改情況對監(jiān)控中心配置信息進行相應的同步更新以反映設備的真實情況3. 巡檢上報功能設備維護人員在現(xiàn)場進行設備巡檢時，可觸發(fā)直放站設備通過網(wǎng)管接口發(fā)送一條巡檢上報信息以通知監(jiān)控中心該站點已進行巡檢維護工作。故障修復上報功能應能生成故障修復上報報表，故障修復上報需要具有下表中的內(nèi)容：故障修復報表參數(shù)參數(shù)說明序號故障修復上報信息的序列編號站點名稱故障修復的直放站名稱站點編號站點編號設備編號設備編號設備類別直放站設備類別設備廠家直放站的生產(chǎn)設備廠家設備狀態(tài)直放站設備的工作狀態(tài)，分正常和不正常兩種狀態(tài)故障修復上報時間維護人員修復故障的時間 實時采樣數(shù)據(jù)功能要求直放站監(jiān)控設備網(wǎng)管接口應具有實時采樣數(shù)據(jù)管理功能，直放站網(wǎng)管接口可向上級網(wǎng)管系統(tǒng)或監(jiān)控系統(tǒng)提供各種反映直放站設備運行質(zhì)量和業(yè)務情況所需的實時采樣數(shù)據(jù)，實現(xiàn)對直放站設備的實時采樣數(shù)據(jù)管理。 故障告警功能要求直放站監(jiān)控設備網(wǎng)管接口應提供告警上報功能，直放站網(wǎng)管接口可以準實時向上級網(wǎng)管系統(tǒng)或監(jiān)控系統(tǒng)發(fā)送直放站設備的各種故障告警信息，滿足直放站設備的故障告警功能要求。告警上報接口上報的告警信息至少應該包括以下內(nèi)容：站點編號、設備編號和告警內(nèi)容。1. 告警實時上報功能接口應支持通過短信、數(shù)傳或GPRS方式向上級網(wǎng)管系統(tǒng)或監(jiān)控系統(tǒng)實時上報告警和事件通知的功能，提供故障告警及故障定位等相關(guān)信息。 數(shù)據(jù)需求各類直放站設備對應數(shù)據(jù)需求詳見《中國移動上級網(wǎng)管系統(tǒng)或監(jiān)控系統(tǒng)數(shù)據(jù)需求規(guī)范（）》。1． 告警傳遞時延在網(wǎng)絡連接正常的情況下，告警傳遞時延（即從設備發(fā)生告警至告警信息到達直放站監(jiān)控中心的延遲）：短信應小于20秒，數(shù)傳應小于40秒（包含撥號建立數(shù)傳鏈路的時間），GPRS暫不做要求。數(shù)傳、GPRS暫不做要求。2． 操作維護的實時性在網(wǎng)絡連接正常的情況下，在直放站監(jiān)控中心與網(wǎng)元進行命令行交互時，從直放站監(jiān)控中心發(fā)出命令到設備對命令做出響應的時間：短信不應超過30秒。對于主從結(jié)構(gòu)的設備，從設備的時延相應增加10秒。 容錯要求網(wǎng)管接口應支持一定的容錯能力，不會因為輸入非法數(shù)據(jù)導致接口故障。網(wǎng)管接口應具足夠的可靠性保障機制，保證信息傳遞不被丟失。 接口數(shù)據(jù)傳遞能力接口應支持足夠的數(shù)據(jù)傳輸速率，應適當考慮承載管理信息的各種通信方式的帶寬。為了提高通信協(xié)議的可擴展行，本通信協(xié)議采用了分層的思路，各個層之間的功能盡可能獨立。各層的功能和用途如下：承載層：通信的實際鏈路，此層可以向接入層提供面向字節(jié)的數(shù)據(jù)包。該層協(xié)議簡稱為TP（Transport Protocol）。接入層承載并保證網(wǎng)絡層協(xié)議數(shù)據(jù)的可靠傳輸，在本監(jiān)控協(xié)議中支持了多種接入層。網(wǎng)絡層：承載監(jiān)控應用層協(xié)議包，實現(xiàn)監(jiān)控應用層與通信鏈路、與網(wǎng)絡結(jié)構(gòu)的隔離。該層協(xié)議簡稱為NP（Network Protocol）。該層協(xié)議簡稱為MAP（Monitoring Application Protocol）。 RS232接口波特率：9600Bps起始位：1bit結(jié)束位：1bit數(shù)據(jù)位：8bits校驗位：無 RS422接口波特率：9600Bps起始位：1bit結(jié)束位：1bit數(shù)據(jù)位：8bits校驗位：無 RS485接口波特率：9600Bps起始位：1bit結(jié)束位：1bit數(shù)據(jù)位：8bits校驗位：無 MODEM（data）方式波特率：9600Bps起始位：1bit結(jié)束位：1bit數(shù)據(jù)位：8bits校驗位：無 MODEM（SMS）方式使用文本格式的短信（不能用PDU格式）。 Ethernet方式使用IP+UDP協(xié)議來承載協(xié)議包。接入層協(xié)議有三種，分別是：AP：A，AP：B和AP：C。以數(shù)據(jù)包的形式進行交互，一個完整的接入層協(xié)議包由起始標志、協(xié)議類型、承載協(xié)議類型、數(shù)據(jù)單元、校驗單元、結(jié)束標志6部分組成。表 71 AP：A協(xié)議包組成起始標志協(xié)議類型承載協(xié)議類型數(shù)據(jù)單元（PDU）校驗單元結(jié)束標志表 71各單元詳細說明如下：l 起始標志：表示一個完整數(shù)據(jù)包（分組）起始的標志；l 協(xié)議類型：標識AP層協(xié)議的類型；l 承載協(xié)議類型：標識所承載的上層協(xié)議的類型；l 數(shù)據(jù)單元：是接入層協(xié)議的有效載荷（PDU）；l 校驗單元：對協(xié)議中從“協(xié)議類型”到“數(shù)據(jù)單元”的內(nèi)容進行校驗；l 結(jié)束標志：表示一個完整數(shù)據(jù)包（分組）結(jié)束的標志。結(jié)束標志的內(nèi)容與起始標志相同。 承載協(xié)議類型長度為1字節(jié)。校驗單元采用CRC校驗，生成多項式為CCITT推薦的16位的x16+x12+x5+1（0x11021）。如果所計算出的CRC值和收到的校驗值相同則表明該數(shù)據(jù)包有效，否則認為該包在傳輸?shù)倪^程中產(chǎn)生了差錯。 轉(zhuǎn)義處理由于使用16進制方式傳輸數(shù)據(jù)，為防止數(shù)據(jù)中出現(xiàn)與通信包起始標志、結(jié)束標志相同的數(shù)據(jù)而影響這兩個標志的判斷。范圍：在本層協(xié)議中，對除起始標志和結(jié)束標志外的所有數(shù)據(jù)。對于需要進行轉(zhuǎn)義后發(fā)送的情況，要按照如下的順序進行操作：發(fā)送數(shù)據(jù)包之前，先生成CRC校驗值，再進行轉(zhuǎn)義處理；接收到數(shù)據(jù)包后，先進行轉(zhuǎn)義處理，再進行CRC校驗。 傳輸要求協(xié)議包的最大長度：256 Bytes（指從“協(xié)議類型”到“校驗單元”最后一個字節(jié)，在發(fā)送過程轉(zhuǎn)義處理之前的字節(jié)數(shù)）。以數(shù)據(jù)包的形式進行交互，一個完整的接入層協(xié)議包由起始標志、協(xié)議類型、承載協(xié)議類型、數(shù)據(jù)單元、校驗單元、結(jié)束標志6部分組成。表 73 AP：A協(xié)議包組成起始標志協(xié)議類型承載協(xié)議類型數(shù)據(jù)單元（PDU）校驗單元結(jié)束標志 起始、結(jié)束標志長度為1字節(jié)，固定為ASCII字符‘！’（0x21）。 協(xié)議類型長度為1字節(jié)，對AP：B型協(xié)議，此值為0x02。定義與AP：A相同。 轉(zhuǎn)義處理不需要進行轉(zhuǎn)義。對于高4bits和低4bits，若其數(shù)值為0x000x09，則加上0x30傳輸，若其數(shù)值為0x0A0x0F，則加上0x37傳輸，這樣得到的結(jié)果就轉(zhuǎn)換為ASCII碼。采用“ASCII碼拆分處理”后，協(xié)議中定義的數(shù)據(jù)，如1字節(jié)的16進制數(shù)0x2B，在實際傳輸中為ASCII碼字符串：“2B”?！癆SCII碼拆分處理”適用于協(xié)議中除起始標志、結(jié)束標志外的所有字符，包括校驗單元。 傳輸要求此處的協(xié)議包最大長度是指從“起始標志”到“結(jié)束標志”，在發(fā)送過程ASCII碼拆分處理之后的字節(jié)數(shù)（與AP：A不同）。使用其它方式通信時，協(xié)議包的最大長度：256 Bytes。以數(shù)據(jù)包的形式進行交互，一個完整的接入層協(xié)議包由承載協(xié)議類型和數(shù)據(jù)單元組成。表 74 AP：C協(xié)議包組成協(xié)議類型承載協(xié)議類型數(shù)據(jù)單元（PDU）表 74各單元詳細說明如下：l 協(xié)議類型：標識AP層協(xié)議的類型，長度為1字節(jié)，對AP：C型協(xié)議，此值為0x03；l 承載協(xié)議類型：標識所承載的上層協(xié)議的類型；l 數(shù)據(jù)單元：是接入層協(xié)議的有效載荷（PDU）；承載協(xié)議類型部分的長度為1字節(jié)，其定義與AP：A相同。協(xié)議包的最大長度：256 Bytes（指從“協(xié)議類型”到“數(shù)據(jù)單元”最后一個字節(jié)的字節(jié)數(shù)）。 網(wǎng)絡層協(xié)議以數(shù)據(jù)包的形式進行交互，一個完整的網(wǎng)絡層協(xié)議包由地址單元、通信包標識號、控制協(xié)議標識和數(shù)據(jù)單元組成。協(xié)議包的最大長度，僅受底層協(xié)議的長度限制，在本層不作另外的約束。協(xié)議內(nèi)容詳見表 105。NP：A中地址單元的組成詳見表 106：表 76 NP：A協(xié)議的地址單元組成序號內(nèi) 容開始位置長度備 注1站點編號142設備編號51表 76有關(guān)字段說明如下：站點編號：由用戶自己根據(jù)需要進行編號。設備的唯一標識。設備編號：在一個本地直放站監(jiān)控網(wǎng)絡中，主站的子編號規(guī)定為0x00，從站的子編號可以在0x01～0xFE之間。對于只有單臺直放站的情況，其子編號規(guī)定為0xFF。接收端在接收到之后不處理，而是在返回時將此值原封不動地發(fā)回給發(fā)起端，以便于發(fā)起端分辨通信包。為便于使用，將通信包標識號分為三段，其中0x0000～0x7FFF用于監(jiān)控中心發(fā)起的通信，而0x8000～0x8FFF則用于由設備發(fā)起的通信，余下的0x9000～0xFFFF則為保留。發(fā)起通信的一端用此標志來通知接收端的NP層如何處理通信包（即NP層的命令），接收端則用此標志通知發(fā)起端對剛才通信包的執(zhí)行結(jié)果（即NP層的應答）。此命令使NP層的功能更為完善。具體的數(shù)值所代表的含義見下表。0x01通信請求的執(zhí)行結(jié)果，表示設備忙，無法處理命令請求。0x81～0xBF保留0xC0～0xFF廠家自定義 應用協(xié)議標識（APID）的規(guī)定指示MAP層協(xié)議的協(xié)議類型，長度為1個字節(jié)，以支持不同的系統(tǒng)和MAP層協(xié)議。 監(jiān)控應用層協(xié)議以數(shù)據(jù)包的形式進行交互，一個完整的監(jiān)控應用層協(xié)議包由命令單元和數(shù)據(jù)單元組成。協(xié)議包的最大長度，僅受底層協(xié)議的長度限制，在本層不作另外的約束。詳見表 118。表 78 MAP：A協(xié)議包組成命令單元數(shù)據(jù)單元表 78各單元詳細說明如下：l 命令單元：命令單元的組成格式見表 119；l 數(shù)據(jù)單元：是網(wǎng)絡層監(jiān)控應用層協(xié)議的有效載荷（PDU），此部分可以沒有（即0個字節(jié)）； 命令單元命令單元的組成詳見下表 119：表 79 MAP協(xié)議的命令單元組成序號內(nèi) 容開始位置長度備 注1命令標識112應答標志21表 79有關(guān)字段說明如下：命令標識：命令的唯一標識。表 710 監(jiān)控通信命令列表命令編碼含 義備 注0x00——禁止使用0x01設備主動告警（上報）0x02查詢0x03設置0x04～0x7F系統(tǒng)保留0x80～0xFF廠家自定義用來留給各個廠家擴充功能使用，此部分的用途由各廠家自己確定應答標志：作為命令的主動發(fā)起方，該字段填0xFF，表示此包為命令，當接收到的命令包該字段中不為0xFF時，則被動接收方不應答。在應答包中，當應答標志不是0x00時，應將接收到的數(shù)據(jù)單元返回給發(fā)起方。表 711 應答標志編碼定義編碼含 義備 注0x00成功0x01命令被有條件執(zhí)行具體錯誤內(nèi)容要在數(shù)據(jù)單元中（用監(jiān)控對象標號）明確指出，僅在設備返回給監(jiān)控中心時使用0x02命令編號錯無效的命令0x03長度錯接收到的實際長度與數(shù)據(jù)包中描述的不相符（有不完整的參數(shù)）0x04CRC校驗錯僅在調(diào)試時使用，正式產(chǎn)品中不返回此信息0x05～0xBF——系統(tǒng)保留（廠家不能占用）0xC0～0xFD——廠家自定義（監(jiān)控中心不用處理）0xFE其它錯誤此表中未定義到的其它錯誤0xFF命令表示此包為發(fā)出的命令，而非命令的應答包注：出錯返回時，除應答標志為0x01外，數(shù)據(jù)單元的內(nèi)容與接收的相同，接收方對數(shù)據(jù)單元的內(nèi)容不解析。 數(shù)據(jù)單元數(shù)據(jù)單元用于承載監(jiān)控對象。為提高監(jiān)控信息的傳輸效率，在一次通信過程中，應盡可能采用一次帶多個監(jiān)控對象的方式。合法的數(shù)據(jù)單元往往有包含多個字節(jié)的數(shù)值，為了保證對這些數(shù)值的正確解析，現(xiàn)對它們傳輸時的字節(jié)流順序作如下規(guī)定：低字節(jié)在前，高字節(jié)在后。無論多字節(jié)數(shù)據(jù)類型還式單字節(jié)數(shù)據(jù)類型，有符號數(shù)的格式統(tǒng)一采用補碼。采用保護定時器的目的是在時序上保證消息或命令的可靠到達。定時器超時之前收到的應答為有效應答，否則為無效應答。當保護定時器計時超過預先的設置