1、精選優(yōu)質(zhì)文檔-傾情為你奉上精選優(yōu)質(zhì)文檔-傾情為你奉上專心-專注-專業(yè)專心-專注-專業(yè)精選優(yōu)質(zhì)文檔-傾情為你奉上專心-專注-專業(yè)NGTP簡介概念和縮略語NGTPNGTP是Next Generation Telematics Protocol的英文縮寫，意思是“下一代Telematics協(xié)議”，它是由BMW公司牽頭，聯(lián)合另外兩家TSPs（Telematics Service Providers)（其中一家為：“Connexis,另外一家為“WirelessCar”）聯(lián)合開發(fā)而成的一個Telematics體系框架（framework)及開放的技術(shù)標準協(xié)議（technology-neutral pro

2、tocol），它為Telematis產(chǎn)業(yè)應用提供了更大的靈活性（flexibility）及可擴展性（scalability）。NGTP的核心是通過開放、標準化的協(xié)議來提供服務。TelematicsTelematics是通信和信息科學的合成詞。此系統(tǒng)通過車載通信終端機，分析汽車內(nèi)發(fā)生的各種狀況和收集駕駛所必需的各種信息，為駕駛員提供方便和安全。為了實現(xiàn)Telematics服務，車內(nèi)必須安裝GPS(Global Positioning System)和具有移動通信功能的終端機。Telematics技術(shù)中，廣為人知的是導航技術(shù)。在很多國家，許多車主把導航裝置作為可選配置。只要輸入目的地，此系統(tǒng)就同時

3、用語音告知以最短時間到達目的地的路徑。另外，根據(jù)實時交通狀況，及時提醒駕駛員避開交通堵塞的路段。Telematics的另一個重要的功能是汽車服務中心可以遠程診斷車輛故障。無線互聯(lián)網(wǎng)終端機通過連接汽車控制單元（Electronic Control Unit），收集汽車的信息并發(fā)送到服務中心。服務中心的診斷儀器根據(jù)發(fā)動機溫度、尾氣、輪胎、汽油等狀況，分析和判斷有無故障，并及時告知駕駛員。另外，在出現(xiàn)緊急情況時，服務中心也可以控制車輛。如發(fā)現(xiàn)汽車失竊，就可以指令汽車停止運行或無法啟動。Telematics的終端機不僅是普通的顯示器，而且是可以連接互聯(lián)網(wǎng)的計算機。終端機通過連接互聯(lián)網(wǎng)，不僅可以接收E-

4、Mail、管理個人信息、播放MP3格式音樂、玩電子游戲等，而且還可以獲取汽車所在地區(qū)的信息。圖1.2 Telematis概念圖TSP即Telematics Service Providers。Telematics服務提供商。TU即車載器。DSPT“調(diào)度器”（Dispatcher)PSAP公共安全應答點CCCall Center的縮寫PDP規(guī)范數(shù)據(jù)提供程序CDP客戶服務提供程序RCDRemote Car Data。遠程車輛數(shù)據(jù)技術(shù)特征NGTP的技術(shù)目標NGTP的開發(fā)者設定了6個目標：為Telematics服務提供開放的協(xié)議及統(tǒng)一的用戶接口方式。降低開發(fā)合作與實施的阻力。新的技術(shù)能夠被及時應用。保

5、證運營系統(tǒng)服務能夠貫穿整個車輛的壽命周期。通過開放的手段獲取廣泛的認同與鼓勵。提高汽車廠商、TSP、內(nèi)容提供商以及乘車人的價值定位。NGTP可以使得汽車廠商從眾多具有統(tǒng)一驅(qū)動經(jīng)驗的合作伙伴中獲取最佳的結(jié)果，同時也可以使得TSPs以相同的服務內(nèi)容同時向不同汽車廠商提供服務，而且，NGTP可以支持遺留系統(tǒng)，使得新車輛及老的車輛獲取相同的最新服務。NGTP適應歐盟倡導的eCall協(xié)議，而且協(xié)議的開放式結(jié)構(gòu)將適應未來的行業(yè)趨勢。為了促進合作與創(chuàng)新，構(gòu)成NGTP的規(guī)范將采用公共創(chuàng)作許可。寶馬將和信息通訊社區(qū)的合作伙伴溝通規(guī)范、支持測試、并采用NGTP的潛力。NGTP的基本架構(gòu)整個協(xié)議包括3個主要部分，其

6、中關(guān)鍵的一個中間件叫做“調(diào)度器”（Dispatcher)，它主要起到車載器（TU）與TSPs服務器之間的有效連接。圖2.2-1 調(diào)度器-NGTP的殺手應用NGTP的調(diào)度器給車輛提供了無縫連接TPS的職能：接收來自車輛TU的請求，然后訪問汽車制造商的客戶和配置數(shù)據(jù)庫，以便將請求路由到適當?shù)腡SP；然后將TSP的語音和數(shù)據(jù)轉(zhuǎn)發(fā)回車輛。圖2.2-2 NGTP促進靈活性的方式NGTP促進靈活性的方式：調(diào)度器提供客戶化接口，允許汽車制造商提供新的服務而無需配置到具體的車輛。獨立和開放的接口把TSP和呼叫中心、內(nèi)容提供商、以及公共安全應答點（PSAPs）連接在一起，允許提供者根據(jù)市場需求進行互換。專有的客

7、戶數(shù)據(jù)駐留在汽車制造商的客戶關(guān)系管理系統(tǒng)（CRM）中。圖2.2-3 NGTP遠程信息處理方法及其接口子系統(tǒng) 接口IF#1 - #7這種架構(gòu)給遠程信息處理業(yè)務伙伴提供了最大的靈活性。NGTP終端到終端的架構(gòu)基于現(xiàn)有的行業(yè)標準，以提高標準化和減少開發(fā)。這一結(jié)構(gòu)的另一個重要優(yōu)點是，它也可以與傳統(tǒng)的解決方案并存。為了描述上述的域，有必要說明該框架的三個主要部分組成：Telematics單元（TU），Telematics服務供應商（TSP）和調(diào)度器（DSPT），所有這些都是通過標準的接口進行連接。Telematics單元Telematics單元（TU）一般是集成在汽車上，但也可以是個人導航設備（PND）

8、的一部分或移動電話。TU通過無線網(wǎng)絡與專用調(diào)度器進行通訊。見上圖的接口IF#1（TU- Dispatcher）。 Telematics服務供應商（TSP）TSP提供實際的服務，并作為對所有的需要執(zhí)行服務發(fā)布的系統(tǒng)的集成點。TSP的作用主要有兩個：第一是要發(fā)布語音和數(shù)據(jù)服務給TU；第二是發(fā)布內(nèi)容，諸如地圖數(shù)據(jù)和景點（POIs）內(nèi)容給Call Center。一個TSP能夠連接多個內(nèi)容提供商和呼叫中心。 更多的客戶、合同、車輛數(shù)據(jù)，可能需要TSP的更多的服務。這種數(shù)據(jù)交換是通過客戶數(shù)據(jù)提供程序（CDP），見上圖的接口IF#4（TSP- CDP）功能。 CDP是一個OEM中的典型的系統(tǒng)。如果TSP不得

9、不處理特殊的電子請求，要求它連接到一個PSAP（見接口IF#5，IF#6a，IF#6b）管理所有TSP和呼叫中心之間的溝通，而IF#7接口管理TSP和一個或者多個內(nèi)容提供商的內(nèi)容發(fā)布。調(diào)度器（DSPT）通過引入調(diào)度器，TU和后端獲得穩(wěn)定的接口。調(diào)度器提供這種穩(wěn)定的接口（IF#1接口）給TU，并作為一個服務開關(guān)在TU和各自的TSP之間派發(fā)交通數(shù)據(jù)和語音。調(diào)度器通過接口IF#2（調(diào)度器-TSP）溝通一個或幾個TSP。調(diào)度器關(guān)聯(lián)數(shù)據(jù)提供者（PDP）通過接口IF#3（調(diào)度器-PDP）以確定目標TSP，并提供所需服務。PDP通常位于OEM系統(tǒng)中。NGTP的協(xié)議結(jié)構(gòu)圖2.3 NGTP Dispatchin

10、g Service接口協(xié)議結(jié)構(gòu)接口協(xié)議，可被定義為三個接口協(xié)議層：服務應用層（Application Services Layer)服務調(diào)度層（Dispatching Services Layer)服務控制層（Control Services Layer)服務應用層（Application Services Layer)NGTP的應用服務層定義了TU及TSP之間的實施應用服務用例的消息格式。應用服務層包含標準（通用）應用協(xié)議消息定義和NGTP支持的消息定義。NGTP的應用服務層也可以擴展到支持自定義特定于設備的應用以及功能，即便是唯一的對特定的TU和應用服務的使用。應用服務層的定義文件是NGT

11、P應用服務層文件（NGTP Application Services Layer Document）。這個定義文件涵蓋了應用服務層涉及服務分發(fā)的所有接口（從接口IF#1到IF#7）。接口IF#1和IF#2的細節(jié)包含在文件節(jié)“TU應用服務”中。接口IF#3到IF#7有他們自己的文件部分。服務調(diào)度層（Dispatching Services Layer)NGTP的服務調(diào)度層定義了在DSPT（調(diào)度器）啟用服務調(diào)度的協(xié)議。服務調(diào)度是功能，它設置了TU和不同的依賴服務執(zhí)行或者TU的物理位置的TSP之間的溝通。（服務調(diào)度層實質(zhì)上建立了在DSPT（調(diào)度器）和依賴于服務的TSP之間路由聲音/數(shù)據(jù)，TU的位置，

12、客戶的信息）。服務調(diào)度層的定義是NGTP服務調(diào)度層文檔（NGTP Dispatching Services Layer Document）。這個定義文件涵蓋了調(diào)度層的調(diào)度相關(guān)的接口IF#1，IF#2，IF#3。這些接口和調(diào)度服務中可以在其中找到相應的章節(jié)。服務控制層（Control Services Layer)NGTP的服務控制層提供了被期望的、使服務應用層和服務調(diào)度層透明的能力。其中，有以下控制功能：交通管制，安全（加密/身份驗證），服務質(zhì)量（Qos），承載控制和質(zhì)量可靠性。NGTP的服務控制層定義文件是NGTP服務控制層文件（NGTP Control Services Layer Doc

13、ument）。本定義文件涵蓋了控制功能相關(guān)的接口IF#1和IF#2的細節(jié)。這些接口和控制服務中可以在其中找到相應的章節(jié)。協(xié)議細節(jié)服務應用層（Application Services Layer)NGTP服務應用層在本文檔中主要描述為遠程信息處理的目的。它可以讓Telematics服務提供商（TSP）提供遠程信息處理應用。此項工作主要通過NGTP的核心架構(gòu)接口，接口IF#1和IF#2。NGTP的服務應用接口層接口IF#3是供應應用服務的接口。NGTP的應用服務層接口IF#4 IF#7，能夠在各自的小節(jié)被看到，描述了被傳輸數(shù)據(jù)的數(shù)據(jù)類型（應用層API），但沒有規(guī)定應如何做（沒有要求傳輸媒體或網(wǎng)絡的

14、使用）。圖3.1 架構(gòu)概覽TU應用服務（接口IF#1和IF#2）圖3.1.1 子系統(tǒng)接口視圖功能模型該功能模型描述了接口的操作。包含適當信息域的子系統(tǒng)，通過發(fā)送訊息調(diào)用子系統(tǒng)的接口的操作。每一個應用程序的消息在服務數(shù)據(jù)之前包括一個上行或下行的業(yè)務數(shù)據(jù)頭。消息頭上行請求消息頭：這個消息頭被添加到從TU發(fā)送到TSP的請求消息。表3.1.1.1.1-1 上行請求消息頭下行請求消息頭：這個消息頭被添加到從TSP發(fā)送到TU的請求消息。表3.1.1.1.1-2 下行請求消息頭應用返回消息頭：這個消息頭被添加到從TSP到TU的返回消息，反之亦然。表3.1.1.1.1-3 通常程序的返回消息頭應用服務Ecal

15、lRequest：表3.1.1.1.2-1 E-callRequestEcallUpdateRequest：表3.1.1.1.2-2 E-callUpdateRequestIcallRequest：表3.1.1.1.2-3 IcallRequest遠程服務（Remote Services）Remote Car Data (RcdRequest)：遠程車輛數(shù)據(jù)（RCD）被用于獲取診斷數(shù)據(jù)或者其他車輛的關(guān)鍵信息。請求者可以指定他們感興趣的特定的數(shù)據(jù)。表3.1.1.1.2-4 RcdRequest：Remote Car DataRemote Door Unlock (RduRequest)：表3.1

16、.1.1.2-5 RduRequest：Remote Door Unlock RequestRemote Door Lock (RdlRequest)：Remote Climate Control (RccRequest)：Remote Horn Blow (RhblRequest)：動態(tài)模型消息時序在進行請求-應答時，消息被交換。每一個消息被定義了一個會話ID（session-id）和一個請求ID（request-id）。會話ID是由會話的發(fā)起者標識，并由會話發(fā)起者設置計數(shù)器。請求ID是自增的，無論何時新的請求消息發(fā)出后。請求的答復，被標記為與請求相同的會話ID和請求ID。消息格式消息格式定

17、義的ASN.1格式在另一份文件。接口IF#3本文檔介紹了調(diào)度器（DSPT）和規(guī)范數(shù)據(jù)提供程序（PDP）之間的接口IF#3。本文件并不試圖描述接口細節(jié)，自配置和路由作為一個運行時組件的服務以及所需要的數(shù)據(jù)類型多種多樣，具體到OEM詳細的接口。功能模型消息頭消息頭定義在相關(guān)的“TU應用服務”章節(jié)。規(guī)范數(shù)據(jù)提供服務接口配置更新請求（ConfigurationUpdateRequest）：答復（Acknowledgement）：規(guī)范TU服務（ProvisioningTuServices）配置更新通知（ConfigurationUpdateNotification）：配置更新（Configuration

18、Update）：動態(tài)模型這里分成通知提供和立即提供兩種方式。消息格式消息格式定義的ASN.1格式在另一份文件。接口IF#4本文檔介紹了TSP和客戶數(shù)據(jù)提供程序（CDP）之間的接口IF#4 。本文件并不試圖從客戶和合同數(shù)據(jù)的類型描述細節(jié)，因為特定OEM的數(shù)據(jù)類型是非常龐大和多樣化的。功能模型客戶數(shù)據(jù)提供（CustomerDataProvider）查找客戶（SearchCustomer）：CDP向TSP提供這個功能用來查找客戶。TSP使用的搜索條件，例如客戶的姓名，車輛種類，車牌號碼等，以獲取例如相關(guān)的客戶列表，客戶ID，姓名，車輛數(shù)據(jù)等。獲取客戶數(shù)據(jù)（GetCustomerData）：CDP提供

19、這個功能給TSP，基于一個獨特的標識符，例如客戶ID或VIN的，來獲取客戶的詳細數(shù)據(jù)。返回的數(shù)據(jù)可能包括姓名，地址，相關(guān)人士，相關(guān)車輛數(shù)據(jù)等。獲取許可服務（GetAllowedService）：CDP向TSP提供這個功能給來獲取每個節(jié)點標識的可用服務（例如 VIN）。獲取認證指令（GetAuthenticationInstruction）：CDP向TSP提供這個功能來獲取客戶的認證信息，例如“問秘密問題”或“詢問密碼”。驗證認證數(shù)據(jù)（VerifyAuthenticationData）：CDP向TSP提供這個功能來驗證客戶，如：遠程服務通過檢查由客戶給出的秘密問題的答案，其結(jié)果是確定或否定。動態(tài)

20、模型從遠程服務驗證客戶獲取客戶消息格式該消息格式不在這個文件中指定，但轉(zhuǎn)換信息的首選方法是使用一些面向服務的集成技術(shù)，如Web服務。接口IF#5接口IF#5的目的是描述信息如何與TSP和PSAP（公共安全應答點）進行交流。這個接口是為了提供信息給PSAP，使他們能夠有效地執(zhí)行E call救援服務。從TSP通過接口IF#5的資料是有效的， 不會被歐洲E-all方式混淆，因為它試圖建立一個數(shù)據(jù)的最小集合（MSD）來直接從車輛發(fā)送到PSAP。通過接口IF#5的數(shù)據(jù)，將是一個更為豐富的數(shù)據(jù)集合，包括車輛數(shù)據(jù)，客戶信息和定位服務組成數(shù)據(jù)，有效的提供給PSAP。 PSAPs必須有從TSP直接訪問這些碰撞數(shù)

21、據(jù)的能力。這份文件沒有定義或承擔任何計劃來提供這種基礎設施給PSAPs。有一個歐洲的倡議規(guī)范該接口。歐盟委員會曾建議歐盟應為自己確定了到2010年減少一半的道路死亡人數(shù)的目標。一個關(guān)于如何實現(xiàn)這一目標的建議是要求為所有新車的標準選擇電子呼叫。歐盟2010年9月1日起批準了該建議。這項工作是由eSafety支持論壇的一部分，eCall驅(qū)動組織推動的。eCall驅(qū)動組織定義了一個被PSAP要求的數(shù)據(jù)的最小集合（MSD），以確保正確的應急資源調(diào)配。（MSD是數(shù)據(jù)的建議將從上述的PSAP直接發(fā)送到車輛）。eCall驅(qū)動組織還承認，電子呼叫效果可以通過發(fā)送額外的車輛和個人相關(guān)信息從TSP通過接口IF#5

22、提供的相關(guān)資料進一步改善。這些額外數(shù)據(jù)的建議，目前正在由歐洲工作的PSAP和TSP的代表小組確定。本文檔考慮了TSP和PSAP的上述建議。有兩個E-call的替代流程：1從車輛通過TSP和呼叫中心到PSAP，通過接口IF#5（“NGTPE-call”）2從車輛通過無線網(wǎng)絡直接到PSAP（無接口定義）（“Non-NGTPE-call”）。NGTP E-callNGTP E-Call是指E-Call從車輛通過DSPT和TSP到達一個呼叫中心，并進一步到達PSAP。這個E Call服務包括所有TU提供的數(shù)據(jù)（位置，碰撞數(shù)據(jù)等）。Non-NGTP E-call非NGTPE-call是指E-call將直

23、接通過網(wǎng)絡從該車輛到PSAP。這個E call服務可能不包括一個TU可以提供的所有的數(shù)據(jù)，但包括至少最低限度的數(shù)據(jù)集，例如：位置應該被提供?？蛇x的數(shù)據(jù)可以被發(fā)送到并行的TSP，使TSP提供這些數(shù)據(jù)給PSAP。功能模型在線服務數(shù)據(jù)提供（OnlineServiceDataProvider）請求服務數(shù)據(jù)（RequestServiceData）：TSP給PSAP提供這個功能來在線請求服務數(shù)據(jù)。對服務請求的數(shù)據(jù)總是返回數(shù)據(jù)或錯誤消息。服務訂閱提供（ServiceSubscriptionProvider）開始訂閱（StartSubscription）：TSP給PSAP提供這個功能來訂閱一個服務數(shù)據(jù)。PSA

24、P按照服務數(shù)據(jù)定義的消息格式提供返回的內(nèi)容。終止訂閱（EndSubscription）：TSP給PSAP提供這個功能用來終止一個服務數(shù)據(jù)訂閱。聲音呼叫終止（VoiceCallTerminated）：TSP給PSAP給PSAP提供這個功能來通知TSP，聲音呼叫已經(jīng)終止。PSAP返回為什么聲音終止的原因描述，意外的還是非意外的。開始訂閱（StartSubscription）：開始訂閱（StartSubscription）：服務訂戶（ServiceSubscribeer）收到服務數(shù)據(jù)（ReceiveServiceData）：PSAP運行訂閱時，PSAP為TSP必須實現(xiàn)這個功能來發(fā)布服務數(shù)據(jù)。處理聲音

25、呼叫（HandleVoiceCall）：PSAP為TSP提供這個功能來請求處理一個得到的呼叫。PSAP將會返回呼叫處理的狀態(tài)。動態(tài)模型消息元素互換消息的首選方法是使用一些現(xiàn)有的標準技術(shù)，例如：數(shù)據(jù)和語音通話的VoIP網(wǎng)絡服務。下表描述了通過接口IF#5對PSAP有效的業(yè)務數(shù)據(jù)。但是，上述數(shù)據(jù)元素的一些要視TU的能力而定。TU可以支持的任何其他的相關(guān)數(shù)據(jù)需求由歐盟，而不是在這里指定。接口IF#6a這一節(jié)描述了TSP和呼叫中心之間的接口IF#6a。這一節(jié)不試圖描述接口細節(jié)，因為呼叫中心是龐大而且多樣化的。功能模型呼叫中心數(shù)據(jù)服務（CallCenterDataServices）處理服務數(shù)據(jù)（Hand

26、elServiceData）：呼叫中心為TSP提供這個功能來發(fā)布服務數(shù)據(jù)。呼叫中心聲音服務（CallCenterVoiceServices）處理聲音呼叫（HandleVoiceCall）：呼叫中心向TSP提供這個功能來請求處理得到的呼叫。呼叫中心返回處理的狀態(tài)。TSP呼叫中心聲音服務（TSPCallCenterVoiceServices）聲音呼叫終止（VoiceCallTerminated）：TSP為呼叫中心提供這個功能來通知TSP，一個聲音呼叫已經(jīng)終止。呼叫中心返回呼叫終止的原因，意外的還是非意外的。TSP呼叫中心數(shù)據(jù)服務（TSPCallCenterDataService）共享服務（Shar

27、eService）：TSP向呼叫中心提供這個功能來包含一個處理運行服務的其他部分，例如PSAP?；诜疹愋秃桶糠值哪芰?，TSP將會共享服務數(shù)據(jù)，呼叫語音或者兩者。呼叫中心可以提供數(shù)據(jù)幫助TSP決定那一部分將被包含。執(zhí)行遠程服務（ExecuteRemoteService）：TSP為呼叫中心提供這個功能來開始授權(quán)車輛中的遠程服務，例如，車輛查詢或者景點上傳。驗證認證數(shù)據(jù)（VerifyAuthenticationData）：TSP為呼叫中心提供這個功能來驗證客戶要求執(zhí)行遠程服務的認證數(shù)據(jù)。呼叫中心提供客戶提交的認證數(shù)據(jù)，例如，回答客戶定義的問題或者一個密碼。查詢客戶（SearchCustome

28、r）：TSP給呼叫中心提供這個功能來尋找客戶。呼叫中心使用的查詢標準，如客戶的姓名，車輛種類，車牌號碼等，以獲得相關(guān)的客戶數(shù)據(jù)，例如，客戶ID，姓名，車輛數(shù)據(jù)等。獲得客戶數(shù)據(jù)（GetCustomerData）：TSP提供這個功能允許呼叫中心讀取必要的客戶信息。客戶數(shù)據(jù)返回包含諸如車輛、用戶信息、所有用戶許可的服務、遠程服務驗證認證所需的信息等。重新路由服務（RerouteService）：TSP向呼叫中心提供這個功能來發(fā)起了主動服務轉(zhuǎn)移到另一個呼叫中心。呼叫中心提供活動的服務和新的服務類型給TSP。任何相關(guān)的語音通話也被TSP重新路由。實際重新路由的語音通話和相關(guān)數(shù)據(jù)是由DSPT執(zhí)行的。當需要

29、改變服務的時候，DSPT將會發(fā)信號給車輛（例如，當車輛發(fā)出的一個E-Call，被CC作為一個B-Call重新路由）。DSPT將會獲得新的車輛數(shù)據(jù)并重新路由數(shù)據(jù)和已經(jīng)完成的語音調(diào)用TSP和一個CC作為一個新的服務。處理服務數(shù)據(jù)更新請求（HandleServiceDataUpdateRequest）：TSP為呼叫中心提供這個功能來請求從一個車輛活動的服務上更新數(shù)據(jù)，例如，碰撞數(shù)據(jù)作為一個E-Call更新。呼叫中心提供服務，TSP可以依照服務類型用不同的方式執(zhí)行。結(jié)束服務（EndService）：TSP向呼叫中心提供這個功能來結(jié)束一個服務。依據(jù)服務類型，TSP可以發(fā)送一個結(jié)束服務的請求給車輛。任何相

30、關(guān)于服務的語音呼叫不需要被提供。動態(tài)模型消息格式接口IF#6b本節(jié)描述的TSP和外部內(nèi)容提供商之間的接口IF#6b。本節(jié)并不試圖描述接口細節(jié)，因為內(nèi)容提供商的數(shù)量和內(nèi)容是非常大的和多樣化的。功能模型在線內(nèi)容聯(lián)播（OnlineContentAggregator）請求內(nèi)容（RequestContent）：TSP給呼叫中心提供這個功能來在線請求內(nèi)容。這個接口為內(nèi)容提供了無狀態(tài)的請求/應答API。一個對內(nèi)容的請求總是返回內(nèi)容，或者錯誤信息。動態(tài)模型消息格式接口IF#7這一節(jié)描述TSP和外部提供商之間的IF#7接口。這一節(jié)不試圖描述接口細節(jié)，因為內(nèi)容提供商的數(shù)量和內(nèi)容的類型是巨大的和多樣的。功能模型在線

31、內(nèi)容提供（OnlineContentProvider）內(nèi)容提供商提供這個功能給TSP來無需訂閱在線請求內(nèi)容。這個接口提供了無狀態(tài)的在線請求/應答API給內(nèi)容。一個對內(nèi)容的請求總是返回內(nèi)容或者一個錯誤信息。內(nèi)容訂閱提供（ContentSubscriptionProvider）開始訂閱（StartSubscription）：內(nèi)容提供商向TSP提供這個功能來開始一個特殊的內(nèi)容訂閱。TSP支持一個內(nèi)容為內(nèi)如服務數(shù)據(jù)定義消息格式。結(jié)束訂閱（EndSubscription）：內(nèi)容提供商提供這個功能允許TSP終止一個內(nèi)容訂閱。內(nèi)容訂閱者（ContentSubscriber）獲得內(nèi)容（ReceiveConte

32、nt）：當TSP運行訂閱時，TSP提供這個功能給內(nèi)容提供商來發(fā)布內(nèi)容。內(nèi)容提供商使用這個功能把更新的內(nèi)容推給TSP動態(tài)模型消息格式服務調(diào)度層（Dispatching Services Layer)NGTP的服務調(diào)度層在本文檔中描述為telematics目標的主要部分。它能使遠程信息處理應用端點溝通，沒有與數(shù)據(jù)或語音如何到達目的地的細節(jié)處理。這就允許telematics應用運行在車輛的TU環(huán)境里，使用不同的TSP的應用服務而不需要知道哪個TSP處理這個服務。接口概覽為了完全滿足調(diào)度要求，一個調(diào)度服務子系統(tǒng)（或協(xié)議層）必須與中心調(diào)度節(jié)點一樣，部署于需要服務的節(jié)點（TU，TSP，PDP）。上圖顯示了

33、不同的調(diào)度子系統(tǒng)接口的提供和使用。由DSPT提供的接口是調(diào)度數(shù)據(jù)和語音，同時把子系統(tǒng)（TU，TSP，PDP）的連接到DSPT提供的接口用于接收和發(fā)送數(shù)據(jù)/或聲音。功能和動態(tài)模型功能和動態(tài)模型描述了接口的操作。這些接口的細節(jié)在本文的分開的調(diào)度服務接口章節(jié)，并為每個概念接口分開描述，IF#1，IF#2， IF#3接口IF#1這一節(jié)描述NGTP的調(diào)度子系統(tǒng) 提供的接口IF#1。功能模型功能模型描述了接口的操作。調(diào)用子系統(tǒng)接口的操作是通過發(fā)送包含相關(guān)信息域的消息給另一個子系統(tǒng)。每一個消息有頭部，由消息穿越的子系統(tǒng)處理。調(diào)度車輛數(shù)據(jù)服務接口（DsptVehicleDataService Interfac

34、e）當發(fā)送到上行方向（車輛到后端）時，這些調(diào)度頭在消息中出現(xiàn)。調(diào)度車輛數(shù)據(jù)請求（DispatchVehicleData Request）：車輛TU的每一個應用消息需要發(fā)送作為一個DispatchVehicleData消息有效負載進行。通過發(fā)送DispatchVehicleData請求，TU調(diào)度服務層要求DSPT發(fā)布應用服務的有效載荷給適當?shù)腡SP。調(diào)度聲音服務接口（DsptVoiceService Interface）調(diào)度聲音呼叫（DispatchVoiceCall）：調(diào)度聲音呼叫用于TU使用一個聲音呼叫到DSPT時。TU數(shù)據(jù)服務接口（TUDataService Interface）這些調(diào)度頭

35、總是出現(xiàn)在發(fā)出的下行方向（后端到車輛）消息中。處理調(diào)度數(shù)據(jù)請求（HandleDispatchedData Request）：在一個應用的有效載荷里，DSPT發(fā)出處理調(diào)度數(shù)據(jù)請求給TU。動態(tài)模型消息格式接口IF#2功能模型功能模型描述了接口的操作。調(diào)用子系統(tǒng)接口的操作是通過發(fā)送包含相關(guān)信息域的消息給另一個子系統(tǒng)。每一個消息有頭部，由消息穿越的子系統(tǒng)處理。調(diào)度提供數(shù)據(jù)服務接口（DsptProviderDataService Interface）創(chuàng)建事件ID（CreateEventID）：創(chuàng)建事件ID允許TSP從DSPT獲得一個事件ID，這個事件是從TSP側(cè)開始的。例如，從呼叫中心開始一個遠程服務。

36、調(diào)度提供數(shù)據(jù)（DispatchProviderData）：通過發(fā)送一個調(diào)度提供數(shù)據(jù)請求，TSP要求DSPT發(fā)布應用服務數(shù)據(jù)給特定的TU。Re調(diào)度服務（ReDispatchService）：ReDispatchService給TSP提供了調(diào)用另一個TSP服務的辦法。一個例子是TSP認識到，客戶需要的是一個不同于調(diào)用請求的另一個服務。TSP創(chuàng)建一個通用的TSP到TSP的服務請求消息，包含了客戶的需求，并請調(diào)度重新調(diào)度它。這個功能葉被TSP用來拒絕一個服務。結(jié)束服務（EndService）：TSP使用結(jié)束服務請求，給DSPT發(fā)信號，服務結(jié)束了。DSPT可以釋放所有相關(guān)服務的資源。調(diào)度提供聲音服務接口

37、（DsptProviderVoiceService Interface）處理聲音呼叫終止（HandleVoiceCallTermination）：當一個聲音呼叫終止的時候，這個服務可以使TSP通知DSPT。提供數(shù)據(jù)服務接口（ProviderDataService Interface）處理調(diào)度數(shù)據(jù)（HandleDispatchedData）：TSP使用本服務請求包含應用服務數(shù)據(jù)的有效載荷和其他信息的處理所需要的應用程序提供的數(shù)據(jù)DSPT本身。服務控制層（Control Services Layer)這個文檔的目的是說明服務控制層（CSL）的在接口IF#1和IF#2的接口。這個文檔定義了這些接口的

38、語法和語義。CSL內(nèi)部的架構(gòu)不在本文范圍，因此，外部的視角是只顯示子系統(tǒng)，但內(nèi)部并非如此。接口IF#1概覽控制服務層接口IF#1的建立是為了隱藏有關(guān)TU和DSPT之間溝通的復雜性。它必須能夠處理，例如，不同類型的承擔者（為語音和數(shù)據(jù)），安全和傳輸機制。復雜性在于，通過接口IF#1傳遞的介質(zhì)的有效性可能隨時間而改變。此外，應用服務可能有不同的通信需求。這也是控制服務層的責任，始終通過調(diào)度器DSPT通訊，實現(xiàn)中央調(diào)度的概念。這一節(jié)的其余部分將僅僅關(guān)注NGTP接口IF#1的服務控制層。接下來的圖形展示了CSL和它的環(huán)境，以及可以要求該系統(tǒng)的操作執(zhí)行的角色。子系統(tǒng)接口-外部查看作為一個子系統(tǒng)分析和設計

39、的結(jié)果，服務執(zhí)行（ServiceExecution）子系統(tǒng)是CSL用戶和邏輯上CSL同級的接口。應用-CSL接口代表以ISessionHandler和IServiceExecution接口在ServiceExecution子系統(tǒng)外部的看法。CSL-CSL接口是代表上上圖中processControlData操作和上圖的IcontrolToControl和IserviceToService接口。因為這些行為涉及不同類型的遠程通訊（SMS，GPRS，等等）需要有效的消息，所以超越了接口操作定義和消息協(xié)議語法定義功能模型CSL到CSL的接口本節(jié)描述了兩個CSL實例之間的接口。換言之，這些都是CSL本

40、身的接口。這些接口的實現(xiàn)被認作為消息，即調(diào)用的操作是通過發(fā)送相應的消息進行。一個控制消息有兩種類型：控制到控制：處理應用程序負載的時候用于接口服務通訊。這種類型的控制消息不包含應用有效載荷。應用到應用：包含一個處理應用的有效載荷。每一個控制消息有三個主要部分：序言，控制頭和控制體。控件頭的結(jié)構(gòu)是很常見的所有類型的消息。該控制塊結(jié)構(gòu)取決于消息類型（控制到控制或應用到應用）。表：NGTP控制消息表：序言表：NGTP控制頭表：服務塊表：服務描述者表：控制服務類別CRQM是為一個會話生命期預分配的電話號碼。這意味著，當收到一個被許可的號碼的語音通話時，對應的TU和所屬的數(shù)據(jù)會話也已知.換言之，一個打算建立一個語音通話回叫號碼被部