NGTP車聯(lián)網(wǎng)協(xié)議簡介

1、精選優(yōu)質文檔-傾情為你奉上NGTP簡介1. 概念和縮略語1.1. NGTPNGTP是Next Generation Telematics Protocol的英文縮寫，意思是“下一代Telematics協(xié)議”，它是由BMW公司牽頭，聯(lián)合另外兩家TSPs（Telematics Service Providers)（其中一家為：“Connexis",另外一家為“WirelessCar”）聯(lián)合開發(fā)而成的一個Telematics體系框架（framework)及開放的技術標準協(xié)議（technology-neutral protocol），它為Telematis產(chǎn)業(yè)應用提供了更大的靈活性（flex

2、ibility）及可擴展性（scalability）。NGTP的核心是通過開放、標準化的協(xié)議來提供服務。1.2. TelematicsTelematics是通信和信息科學的合成詞。此系統(tǒng)通過車載通信終端機，分析汽車內發(fā)生的各種狀況和收集駕駛所必需的各種信息，為駕駛員提供方便和安全。為了實現(xiàn)Telematics服務，車內必須安裝GPS(Global Positioning System)和具有移動通信功能的終端機。Telematics技術中，廣為人知的是導航技術。在很多國家，許多車主把導航裝置作為可選配置。只要輸入目的地，此系統(tǒng)就同時用語音告知以最短時間到達目的地的路徑。另外，根據(jù)實時交通狀況，

3、及時提醒駕駛員避開交通堵塞的路段。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-Mail、管理個人信息、播放MP3格式音樂、玩電子游戲等，而且

4、還可以獲取汽車所在地區(qū)的信息。圖1.2 Telematis概念圖1.3. TSP即Telematics Service Providers。Telematics服務提供商。1.4. TU即車載器。1.5. DSPT“調度器”（Dispatcher)1.6. PSAP公共安全應答點1.7. CCCall Center的縮寫1.8. PDP規(guī)范數(shù)據(jù)提供程序1.9. CDP客戶服務提供程序1.10. RCDRemote Car Data。遠程車輛數(shù)據(jù)2. 技術特征2.1. NGTP的技術目標NGTP的開發(fā)者設定了6個目標：1. 為Telematics服務提供開放的協(xié)議及統(tǒng)一的用戶接口方式。2. 降低

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

6、試、并采用NGTP的潛力。2.2. NGTP的基本架構整個協(xié)議包括3個主要部分，其中關鍵的一個中間件叫做“調度器”（Dispatcher)，它主要起到車載器（TU）與TSPs服務器之間的有效連接。圖2.2-1 調度器-NGTP的殺手應用NGTP的調度器給車輛提供了無縫連接TPS的職能：1. 接收來自車輛TU的請求，2. 然后訪問汽車制造商的客戶和配置數(shù)據(jù)庫，以便將請求路由到適當?shù)腡SP；3. 然后將TSP的語音和數(shù)據(jù)轉發(fā)回車輛。圖2.2-2 NGTP促進靈活性的方式NGTP促進靈活性的方式：1. 調度器提供客戶化接口，允許汽車制造商提供新的服務而無需配置到具體的車輛。2. 獨立和開放的接口把T

7、SP和呼叫中心、內容提供商、以及公共安全應答點（PSAPs）連接在一起，允許提供者根據(jù)市場需求進行互換。3. 專有的客戶數(shù)據(jù)駐留在汽車制造商的客戶關系管理系統(tǒng)（CRM）中。圖2.2-3 NGTP遠程信息處理方法及其接口子系統(tǒng) 接口IF#1 - #7這種架構給遠程信息處理業(yè)務伙伴提供了最大的靈活性。NGTP終端到終端的架構基于現(xiàn)有的行業(yè)標準，以提高標準化和減少開發(fā)。這一結構的另一個重要優(yōu)點是，它也可以與傳統(tǒng)的解決方案并存。為了描述上述的域，有必要說明該框架的三個主要部分組成：Telematics單元（TU），Telematics服務供應商（TSP）和調度器（DSPT），所有這些都是通過標準的接口

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

9、據(jù)提供程序（CDP），見上圖的接口IF#4（TSP- CDP）功能。 CDP是一個OEM中的典型的系統(tǒng)。如果TSP不得不處理特殊的電子請求，要求它連接到一個PSAP（見接口IF#5，IF#6a，IF#6b）管理所有TSP和呼叫中心之間的溝通，而IF#7接口管理TSP和一個或者多個內容提供商的內容發(fā)布。調度器（DSPT）通過引入調度器，TU和后端獲得穩(wěn)定的接口。調度器提供這種穩(wěn)定的接口（IF#1接口）給TU，并作為一個服務開關在TU和各自的TSP之間派發(fā)交通數(shù)據(jù)和語音。調度器通過接口IF#2（調度器-TSP）溝通一個或幾個TSP。調度器關聯(lián)數(shù)據(jù)提供者（PDP）通過接口IF#3（調度器-PDP）以

10、確定目標TSP，并提供所需服務。PDP通常位于OEM系統(tǒng)中。2.3. NGTP的協(xié)議結構圖2.3 NGTP Dispatching Service接口協(xié)議結構接口協(xié)議，可被定義為三個接口協(xié)議層：1. 服務應用層（Application Services Layer)2. 服務調度層（Dispatching Services Layer)3. 服務控制層（Control Services Layer)服務應用層（Application Services Layer)NGTP的應用服務層定義了TU及TSP之間的實施應用服務用例的消息格式。應用服務層包含標準（通用）應用協(xié)議消息定義和NGTP支持的消

11、息定義。NGTP的應用服務層也可以擴展到支持自定義特定于設備的應用以及功能，即便是唯一的對特定的TU和應用服務的使用。應用服務層的定義文件是NGTP應用服務層文件（NGTP Application Services Layer Document）。這個定義文件涵蓋了應用服務層涉及服務分發(fā)的所有接口（從接口IF#1到IF#7）。接口IF#1和IF#2的細節(jié)包含在文件節(jié)“TU應用服務”中。接口IF#3到IF#7有他們自己的文件部分。服務調度層（Dispatching Services Layer)NGTP的服務調度層定義了在DSPT（調度器）啟用服務調度的協(xié)議。服務調度是功能，它設置了TU和不同的

12、依賴服務執(zhí)行或者TU的物理位置的TSP之間的溝通。（服務調度層實質上建立了在DSPT（調度器）和依賴于服務的TSP之間路由聲音/數(shù)據(jù)，TU的位置，客戶的信息）。服務調度層的定義是NGTP服務調度層文檔（NGTP Dispatching Services Layer Document）。這個定義文件涵蓋了調度層的調度相關的接口IF#1，IF#2，IF#3。這些接口和調度服務中可以在其中找到相應的章節(jié)。服務控制層（Control Services Layer)NGTP的服務控制層提供了被期望的、使服務應用層和服務調度層透明的能力。其中，有以下控制功能：交通管制，安全（加密/身份驗證），服務質量（Q

13、os），承載控制和質量可靠性。NGTP的服務控制層定義文件是NGTP服務控制層文件（NGTP Control Services Layer Document）。本定義文件涵蓋了控制功能相關的接口IF#1和IF#2的細節(jié)。這些接口和控制服務中可以在其中找到相應的章節(jié)。3. 協(xié)議細節(jié)3.1. 服務應用層（Application Services Layer)NGTP服務應用層在本文檔中主要描述為遠程信息處理的目的。它可以讓Telematics服務提供商（TSP）提供遠程信息處理應用。此項工作主要通過NGTP的核心架構接口，接口IF#1和IF#2。NGTP的服務應用接口層接口IF#3是供應應用服務的

14、接口。NGTP的應用服務層接口IF#4 IF#7，能夠在各自的小節(jié)被看到，描述了被傳輸數(shù)據(jù)的數(shù)據(jù)類型（應用層API），但沒有規(guī)定應如何做（沒有要求傳輸媒體或網(wǎng)絡的使用）。圖3.1 架構概覽3.1.1. TU應用服務（接口IF#1和IF#2）圖3.1.1 子系統(tǒng)接口視圖3.1.1.1. 功能模型該功能模型描述了接口的操作。包含適當信息域的子系統(tǒng)，通過發(fā)送訊息調用子系統(tǒng)的接口的操作。每一個應用程序的消息在服務數(shù)據(jù)之前包括一個上行或下行的業(yè)務數(shù)據(jù)頭。3.1.1.1.1. 消息頭上行請求消息頭：這個消息頭被添加到從TU發(fā)送到TSP的請求消息。表3.1.1.1.1-1 上行請求消息頭下行請求消息頭：這個

15、消息頭被添加到從TSP發(fā)送到TU的請求消息。表3.1.1.1.1-2 下行請求消息頭應用返回消息頭：這個消息頭被添加到從TSP到TU的返回消息，反之亦然。表3.1.1.1.1-3 通常程序的返回消息頭3.1.1.1.2. 應用服務EcallRequest：表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ù)（

16、RCD）被用于獲取診斷數(shù)據(jù)或者其他車輛的關鍵信息。請求者可以指定他們感興趣的特定的數(shù)據(jù)。表3.1.1.1.2-4 RcdRequest：Remote Car DataRemote Door Unlock (RduRequest)：表3.1.1.1.2-5 RduRequest：Remote Door Unlock RequestRemote Door Lock (RdlRequest)：Remote Climate Control (RccRequest)：Remote Horn Blow (RhblRequest)：3.1.1.2. 動態(tài)模型3.1.1.2.1. 消息時序在進行請求-應答時，

17、消息被交換。每一個消息被定義了一個會話ID（session-id）和一個請求ID（request-id）。會話ID是由會話的發(fā)起者標識，并由會話發(fā)起者設置計數(shù)器。請求ID是自增的，無論何時新的請求消息發(fā)出后。請求的答復，被標記為與請求相同的會話ID和請求ID。3.1.1.2.2. 消息格式消息格式定義的ASN.1格式在另一份文件。3.1.2. 接口IF#3本文檔介紹了調度器（DSPT）和規(guī)范數(shù)據(jù)提供程序（PDP）之間的接口IF#3。本文件并不試圖描述接口細節(jié)，自配置和路由作為一個運行時組件的服務以及所需要的數(shù)據(jù)類型多種多樣，具體到OEM詳細的接口。3.1.2.1. 功能模型3.1.2.1.1.

18、 消息頭消息頭定義在相關的“TU應用服務”章節(jié)。3.1.2.1.2. 規(guī)范數(shù)據(jù)提供服務接口配置更新請求（ConfigurationUpdateRequest）：答復（Acknowledgement）：3.1.2.1.3. 規(guī)范TU服務（ProvisioningTuServices）配置更新通知（ConfigurationUpdateNotification）：配置更新（ConfigurationUpdate）：3.1.2.2. 動態(tài)模型這里分成通知提供和立即提供兩種方式。3.1.2.3. 消息格式消息格式定義的ASN.1格式在另一份文件。3.1.3. 接口IF#4本文檔介紹了TSP和客戶數(shù)據(jù)提

19、供程序（CDP）之間的接口IF#4 。本文件并不試圖從客戶和合同數(shù)據(jù)的類型描述細節(jié)，因為特定OEM的數(shù)據(jù)類型是非常龐大和多樣化的。3.1.3.1. 功能模型3.1.3.1.1. 客戶數(shù)據(jù)提供（CustomerDataProvider）查找客戶（SearchCustomer）：CDP向TSP提供這個功能用來查找客戶。TSP使用的搜索條件，例如客戶的姓名，車輛種類，車牌號碼等，以獲取例如相關的客戶列表，客戶ID，姓名，車輛數(shù)據(jù)等。獲取客戶數(shù)據(jù)（GetCustomerData）：CDP提供這個功能給TSP，基于一個獨特的標識符，例如客戶ID或VIN的，來獲取客戶的詳細數(shù)據(jù)。返回的數(shù)據(jù)可能包括姓名，地

20、址，相關人士，相關車輛數(shù)據(jù)等。獲取許可服務（GetAllowedService）：CDP向TSP提供這個功能給來獲取每個節(jié)點標識的可用服務（例如 VIN）。獲取認證指令（GetAuthenticationInstruction）：CDP向TSP提供這個功能來獲取客戶的認證信息，例如“問秘密問題”或“詢問密碼”。驗證認證數(shù)據(jù)（VerifyAuthenticationData）：CDP向TSP提供這個功能來驗證客戶，如：遠程服務通過檢查由客戶給出的秘密問題的答案，其結果是確定或否定。3.1.3.2. 動態(tài)模型3.1.3.2.1. 從遠程服務驗證客戶3.1.3.2.2. 獲取客戶3.1.3.3. 消

21、息格式該消息格式不在這個文件中指定，但轉換信息的首選方法是使用一些面向服務的集成技術，如Web服務。3.1.4. 接口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ù)據(jù)的能力。這份文件

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

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

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

25、ubscription）：TSP給PSAP提供這個功能來訂閱一個服務數(shù)據(jù)。PSAP按照服務數(shù)據(jù)定義的消息格式提供返回的內容。終止訂閱（EndSubscription）：TSP給PSAP提供這個功能用來終止一個服務數(shù)據(jù)訂閱。聲音呼叫終止（VoiceCallTerminated）：TSP給PSAP給PSAP提供這個功能來通知TSP，聲音呼叫已經(jīng)終止。PSAP返回為什么聲音終止的原因描述，意外的還是非意外的。開始訂閱（StartSubscription）：開始訂閱（StartSubscription）：3.1.4.3.3. 服務訂戶（ServiceSubscribeer）收到服務數(shù)據(jù)（Receive

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

27、這一節(jié)不試圖描述接口細節(jié)，因為呼叫中心是龐大而且多樣化的。3.1.5.1. 功能模型3.1.5.1.1. 呼叫中心數(shù)據(jù)服務（CallCenterDataServices）處理服務數(shù)據(jù)（HandelServiceData）：呼叫中心為TSP提供這個功能來發(fā)布服務數(shù)據(jù)。3.1.5.1.2. 呼叫中心聲音服務（CallCenterVoiceServices）處理聲音呼叫（HandleVoiceCall）：呼叫中心向TSP提供這個功能來請求處理得到的呼叫。呼叫中心返回處理的狀態(tài)。3.1.5.1.3. TSP呼叫中心聲音服務（TSPCallCenterVoiceServices）聲音呼叫終止（Voice

28、CallTerminated）：TSP為呼叫中心提供這個功能來通知TSP，一個聲音呼叫已經(jīng)終止。呼叫中心返回呼叫終止的原因，意外的還是非意外的。3.1.5.1.4. TSP呼叫中心數(shù)據(jù)服務（TSPCallCenterDataService）共享服務（ShareService）：TSP向呼叫中心提供這個功能來包含一個處理運行服務的其他部分，例如PSAP?；诜疹愋秃桶糠值哪芰Γ琓SP將會共享服務數(shù)據(jù)，呼叫語音或者兩者。呼叫中心可以提供數(shù)據(jù)幫助TSP決定那一部分將被包含。執(zhí)行遠程服務（ExecuteRemoteService）：TSP為呼叫中心提供這個功能來開始授權車輛中的遠程服務，例如，車

29、輛查詢或者景點上傳。驗證認證數(shù)據(jù)（VerifyAuthenticationData）：TSP為呼叫中心提供這個功能來驗證客戶要求執(zhí)行遠程服務的認證數(shù)據(jù)。呼叫中心提供客戶提交的認證數(shù)據(jù)，例如，回答客戶定義的問題或者一個密碼。查詢客戶（SearchCustomer）：TSP給呼叫中心提供這個功能來尋找客戶。呼叫中心使用的查詢標準，如客戶的姓名，車輛種類，車牌號碼等，以獲得相關的客戶數(shù)據(jù)，例如，客戶ID，姓名，車輛數(shù)據(jù)等。獲得客戶數(shù)據(jù)（GetCustomerData）：TSP提供這個功能允許呼叫中心讀取必要的客戶信息?？蛻魯?shù)據(jù)返回包含諸如車輛、用戶信息、所有用戶許可的服務、遠程服務驗證認證所需的信息

30、等。重新路由服務（RerouteService）：TSP向呼叫中心提供這個功能來發(fā)起了主動服務轉移到另一個呼叫中心。呼叫中心提供活動的服務和新的服務類型給TSP。任何相關的語音通話也被TSP重新路由。實際重新路由的語音通話和相關數(shù)據(jù)是由DSPT執(zhí)行的。當需要改變服務的時候，DSPT將會發(fā)信號給車輛（例如，當車輛發(fā)出的一個E-Call，被CC作為一個B-Call重新路由）。DSPT將會獲得新的車輛數(shù)據(jù)并重新路由數(shù)據(jù)和已經(jīng)完成的語音調用TSP和一個CC作為一個新的服務。處理服務數(shù)據(jù)更新請求（HandleServiceDataUpdateRequest）：TSP為呼叫中心提供這個功能來請求從一個車輛

31、活動的服務上更新數(shù)據(jù)，例如，碰撞數(shù)據(jù)作為一個E-Call更新。呼叫中心提供服務，TSP可以依照服務類型用不同的方式執(zhí)行。結束服務（EndService）：TSP向呼叫中心提供這個功能來結束一個服務。依據(jù)服務類型，TSP可以發(fā)送一個結束服務的請求給車輛。任何相關于服務的語音呼叫不需要被提供。3.1.5.2. 動態(tài)模型3.1.5.3. 消息格式3.1.6. 接口IF#6b本節(jié)描述的TSP和外部內容提供商之間的接口IF#6b。本節(jié)并不試圖描述接口細節(jié)，因為內容提供商的數(shù)量和內容是非常大的和多樣化的。3.1.6.1. 功能模型3.1.6.1.1. 在線內容聯(lián)播（OnlineContentAggrega

32、tor）請求內容（RequestContent）：TSP給呼叫中心提供這個功能來在線請求內容。這個接口為內容提供了無狀態(tài)的請求/應答API。一個對內容的請求總是返回內容，或者錯誤信息。3.1.6.2. 動態(tài)模型3.1.6.3. 消息格式3.1.7. 接口IF#7這一節(jié)描述TSP和外部提供商之間的IF#7接口。這一節(jié)不試圖描述接口細節(jié)，因為內容提供商的數(shù)量和內容的類型是巨大的和多樣的。3.1.7.1. 功能模型3.1.7.1.1. 在線內容提供（OnlineContentProvider）內容提供商提供這個功能給TSP來無需訂閱在線請求內容。這個接口提供了無狀態(tài)的在線請求/應答API給內容。一個

33、對內容的請求總是返回內容或者一個錯誤信息。3.1.7.1.2. 內容訂閱提供（ContentSubscriptionProvider）開始訂閱（StartSubscription）：內容提供商向TSP提供這個功能來開始一個特殊的內容訂閱。TSP支持一個內容為內如服務數(shù)據(jù)定義消息格式。結束訂閱（EndSubscription）：內容提供商提供這個功能允許TSP終止一個內容訂閱。3.1.7.1.3. 內容訂閱者（ContentSubscriber）獲得內容（ReceiveContent）：當TSP運行訂閱時，TSP提供這個功能給內容提供商來發(fā)布內容。內容提供商使用這個功能把更新的內容推給TSP3.

34、1.7.2. 動態(tài)模型3.1.7.3. 消息格式3.2. 服務調度層（Dispatching Services Layer)NGTP的服務調度層在本文檔中描述為telematics目標的主要部分。它能使遠程信息處理應用端點溝通，沒有與數(shù)據(jù)或語音如何到達目的地的細節(jié)處理。這就允許telematics應用運行在車輛的TU環(huán)境里，使用不同的TSP的應用服務而不需要知道哪個TSP處理這個服務。3.2.1. 接口概覽為了完全滿足調度要求，一個調度服務子系統(tǒng)（或協(xié)議層）必須與中心調度節(jié)點一樣，部署于需要服務的節(jié)點（TU，TSP，PDP）。上圖顯示了不同的調度子系統(tǒng)接口的提供和使用。由DSPT提供的接口是調

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

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

37、DataService Interface）這些調度頭總是出現(xiàn)在發(fā)出的下行方向（后端到車輛）消息中。處理調度數(shù)據(jù)請求（HandleDispatchedData Request）：在一個應用的有效載荷里，DSPT發(fā)出處理調度數(shù)據(jù)請求給TU。3.2.3.2. 動態(tài)模型3.2.3.3. 消息格式3.2.4. 接口IF#23.2.4.1. 功能模型功能模型描述了接口的操作。調用子系統(tǒng)接口的操作是通過發(fā)送包含相關信息域的消息給另一個子系統(tǒng)。每一個消息有頭部，由消息穿越的子系統(tǒng)處理。3.2.4.1.1. 調度提供數(shù)據(jù)服務接口（DsptProviderDataService Interface）創(chuàng)建事件ID

38、（CreateEventID）：創(chuàng)建事件ID允許TSP從DSPT獲得一個事件ID，這個事件是從TSP側開始的。例如，從呼叫中心開始一個遠程服務。調度提供數(shù)據(jù)（DispatchProviderData）：通過發(fā)送一個調度提供數(shù)據(jù)請求，TSP要求DSPT發(fā)布應用服務數(shù)據(jù)給特定的TU。Re調度服務（ReDispatchService）：ReDispatchService給TSP提供了調用另一個TSP服務的辦法。一個例子是TSP認識到，客戶需要的是一個不同于調用請求的另一個服務。TSP創(chuàng)建一個通用的TSP到TSP的服務請求消息，包含了客戶的需求，并請調度重新調度它。這個功能葉被TSP用來拒絕一個服務。

39、結束服務（EndService）：TSP使用結束服務請求，給DSPT發(fā)信號，服務結束了。DSPT可以釋放所有相關服務的資源。3.2.4.1.2. 調度提供聲音服務接口（DsptProviderVoiceService Interface）處理聲音呼叫終止（HandleVoiceCallTermination）：當一個聲音呼叫終止的時候，這個服務可以使TSP通知DSPT。3.2.4.1.3. 提供數(shù)據(jù)服務接口（ProviderDataService Interface）處理調度數(shù)據(jù)（HandleDispatchedData）：TSP使用本服務請求包含應用服務數(shù)據(jù)的有效載荷和其他信息的處理所需要的

40、應用程序提供的數(shù)據(jù)DSPT本身。3.3. 服務控制層（Control Services Layer)這個文檔的目的是說明服務控制層（CSL）的在接口IF#1和IF#2的接口。這個文檔定義了這些接口的語法和語義。CSL內部的架構不在本文范圍，因此，外部的視角是只顯示子系統(tǒng)，但內部并非如此。3.3.1. 接口IF#13.3.1.1. 概覽控制服務層接口IF#1的建立是為了隱藏有關TU和DSPT之間溝通的復雜性。它必須能夠處理，例如，不同類型的承擔者（為語音和數(shù)據(jù)），安全和傳輸機制。復雜性在于，通過接口IF#1傳遞的介質的有效性可能隨時間而改變。此外，應用服務可能有不同的通信需求。這也是控制服務層的

41、責任，始終通過調度器DSPT通訊，實現(xiàn)中央調度的概念。這一節(jié)的其余部分將僅僅關注NGTP接口IF#1的服務控制層。接下來的圖形展示了CSL和它的環(huán)境，以及可以要求該系統(tǒng)的操作執(zhí)行的角色。3.3.1.2. 子系統(tǒng)接口-外部查看作為一個子系統(tǒng)分析和設計的結果，服務執(zhí)行（ServiceExecution）子系統(tǒng)是CSL用戶和邏輯上CSL同級的接口。應用-CSL接口代表以ISessionHandler和IServiceExecution接口在ServiceExecution子系統(tǒng)外部的看法。CSL-CSL接口是代表上上圖中processControlData操作和上圖的IcontrolToContro

42、l和IserviceToService接口。因為這些行為涉及不同類型的遠程通訊（SMS，GPRS，等等）需要有效的消息，所以超越了接口操作定義和消息協(xié)議語法定義3.3.2. 功能模型3.3.2.1. CSL到CSL的接口本節(jié)描述了兩個CSL實例之間的接口。換言之，這些都是CSL本身的接口。這些接口的實現(xiàn)被認作為消息，即調用的操作是通過發(fā)送相應的消息進行。一個控制消息有兩種類型：1. 控制到控制：處理應用程序負載的時候用于接口服務通訊。這種類型的控制消息不包含應用有效載荷。2. 應用到應用：包含一個處理應用的有效載荷。每一個控制消息有三個主要部分：序言，控制頭和控制體?？丶^的結構是很常見的所有類型的消息。該控制塊結構取決于消息類型（控制到控制或應用到應用）。表：NGTP控制消息表：序言表：NGTP控制頭表：服務塊表：服務描述者表：控制服務類別CRQM是為一個會話生命期預分配的電話號碼。這意味著，當收到一個被許可的號碼的語音通話時，對應的TU和所屬的數(shù)據(jù)會話也已知.換言之，一個打算建立一個語音通話回叫