文档文库

手机版

投诉建议

首页 > NGTP车联网协议简介

NGTP车联网协议简介

发布时间：2014-09-03 11:57:03 来源：文档文库

小中大

字号：

手机查看

NGTP简介

1. 概念和缩略语

1.1. NGTP

NGTP是Next Generation Telematics Protocol的英文缩写，意思是“下一代Telematics协议”，它是由BMW公司牵头，联合另外两家TSPs（Telematics Service Providers)（其中一家为：“Connexis",另外一家为“WirelessCar”）联合开发而成的一个Telematics体系框架（framework)及开放的技术标准协议（technology-neutral protocol），它为Telematis产业应用提供了更大的灵活性（flexibility）及可扩展性（scalability）。

NGTP的核心是通过开放、标准化的协议来提供服务。

1.2. Telematics

Telematics是通信和信息科学的合成词。此系统通过车载通信终端机，分析汽车内发生的各种状况和收集驾驶所必需的各种信息，为驾驶员提供方便和安全。为了实现Telematics服务，车内必须安装GPS(Global Positioning System)和具有移动通信功能的终端机。

Telematics技术中，广为人知的是导航技术。在很多国家，许多车主把导航装置作为可选配置。只要输入目的地，此系统就同时用语音告知以最短时间到达目的地的路径。另外，根据实时交通状况，及时提醒驾驶员避开交通堵塞的路段。

Telematics的另一个重要的功能是汽车服务中心可以远程诊断车辆故障。无线互联网终端机通过连接汽车控制单元（Electronic Control Unit），收集汽车的信息并发送到服务中心。服务中心的诊断仪器根据发动机温度、尾气、轮胎、汽油等状况，分析和判断有无故障，并及时告知驾驶员。另外，在出现紧急情况时，服务中心也可以控制车辆。如发现汽车失窃，就可以指令汽车停止运行或无法启动。

Telematics的终端机不仅是普通的显示器，而且是可以连接互联网的计算机。终端机通过连接互联网，不仅可以接收E-Mail、管理个人信息、播放MP3格式音乐、玩电子游戏等，而且还可以获取汽车所在地区的信息。

图1.2 Telematis概念图

1.3. TSP

即Telematics Service Providers。Telematics服务提供商。

1.4. TU

即车载器。

1.5. DSPT

“调度器”（Dispatcher)

1.6. PSAP

公共安全应答点

1.7. CC

Call Center的缩写

1.8. PDP

规范数据提供程序

1.9. CDP

客户服务提供程序

1.10. RCD

Remote Car Data。远程车辆数据

2. 技术特征

2.1. NGTP的技术目标

NGTP的开发者设定了6个目标：

1. 为Telematics服务提供开放的协议及统一的用户接口方式。

2. 降低开发合作与实施的阻力。

3. 新的技术能够被及时应用。

4. 保证运营系统服务能够贯穿整个车辆的寿命周期。

5. 通过开放的手段获取广泛的认同与鼓励。

6. 提高汽车厂商、TSP、内容提供商以及乘车人的价值定位。

NGTP可以使得汽车厂商从众多具有统一驱动经验的合作伙伴中获取最佳的结果，同时也可以使得TSPs以相同的服务内容同时向不同汽车厂商提供服务，而且，NGTP可以支持遗留系统，使得新车辆及老的车辆获取相同的最新服务。

NGTP适应欧盟倡导的eCall协议，而且协议的开放式结构将适应未来的行业趋势。

为了促进合作与创新，构成NGTP的规范将采用公共创作许可。宝马将和信息通讯社区的合作伙伴沟通规范、支持测试、并采用NGTP的潜力。

2.2. NGTP的基本架构

整个协议包括3个主要部分，其中关键的一个中间件叫做“调度器”（Dispatcher)，它主要起到车载器（TU）与TSPs服务器之间的有效连接。

图2.2-1调度器-NGTP的杀手应用

NGTP的调度器给车辆提供了无缝连接TPS的职能：

1. 接收来自车辆TU的请求，

2. 然后访问汽车制造商的客户和配置数据库，以便将请求路由到适当的TSP；

3. 然后将TSP的语音和数据转发回车辆。

图2.2-2 NGTP促进灵活性的方式

NGTP促进灵活性的方式：

1. 调度器提供客户化接口，允许汽车制造商提供新的服务而无需配置到具体的车辆。

2. 独立和开放的接口把TSP和呼叫中心、内容提供商、以及公共安全应答点（PSAPs）连接在一起，允许提供者根据市场需求进行互换。

3. 专有的客户数据驻留在汽车制造商的客户关系管理系统（CRM）中。

图2.2-3 NGTP远程信息处理方法及其接口子系统接口IF#1 - #7

这种架构给远程信息处理业务伙伴提供了最大的灵活性。NGTP终端到终端的架构基于现有的行业标准，以提高标准化和减少开发。这一结构的另一个重要优点是，它也可以与传统的解决方案并存。

为了描述上述的域，有必要说明该框架的三个主要部分组成：Telematics单元（TU），Telematics服务供应商（TSP）和调度器（DSPT），所有这些都是通过标准的接口进行连接。

Telematics单元

Telematics单元（TU）一般是集成在汽车上，但也可以是个人导航设备（PND）的一部分或移动电话。TU通过无线网络与专用调度器进行通讯。见上图的接口IF#1（TU- Dispatcher）。

Telematics服务供应商（TSP）

TSP提供实际的服务，并作为对所有的需要执行服务发布的系统的集成点。TSP的作用主要有两个：第一是要发布语音和数据服务给TU；第二是发布内容，诸如地图数据和景点（POIs）内容给Call Center。一个TSP能够连接多个内容提供商和呼叫中心。

更多的客户、合同、车辆数据，可能需要TSP的更多的服务。这种数据交换是通过客户数据提供程序（CDP），见上图的接口IF#4（TSP- CDP）功能。 CDP是一个OEM中的典型的系统。如果TSP不得不处理特殊的电子请求，要求它连接到一个PSAP（见接口IF#5，IF#6a，IF#6b）管理所有TSP和呼叫中心之间的沟通，而IF#7接口管理TSP和一个或者多个内容提供商的内容发布。

调度器（DSPT）

通过引入调度器，TU和后端获得稳定的接口。调度器提供这种稳定的接口（IF#1接口）给TU，并作为一个服务开关在TU和各自的TSP之间派发交通数据和语音。

调度器通过接口IF#2（调度器-TSP）沟通一个或几个TSP。调度器关联数据提供者（PDP）通过接口IF#3（调度器-PDP）以确定目标TSP，并提供所需服务。PDP通常位于OEM系统中。

2.3. NGTP的协议结构

图2.3 NGTP Dispatching Service接口协议结构

接口协议，可被定义为三个接口协议层：

1. 服务应用层（Application Services Layer)

2. 服务调度层（Dispatching Services Layer)

3. 服务控制层（Control Services Layer)

服务应用层（Application Services Layer)

NGTP的应用服务层定义了TU及TSP之间的实施应用服务用例的消息格式。应用服务层包含标准（通用）应用协议消息定义和NGTP支持的消息定义。NGTP的应用服务层也可以扩展到支持自定义特定于设备的应用以及功能，即便是唯一的对特定的TU和应用服务的使用。

应用服务层的定义文件是NGTP应用服务层文件（NGTP Application Services Layer Document）。这个定义文件涵盖了应用服务层涉及服务分发的所有接口（从接口IF#1到IF#7）。接口IF#1和IF#2的细节包含在文件节“TU应用服务”中。接口IF#3到IF#7有他们自己的文件部分。

服务调度层（Dispatching Services Layer)

NGTP的服务调度层定义了在DSPT（调度器）启用服务调度的协议。服务调度是功能，它设置了TU和不同的依赖服务执行或者TU的物理位置的TSP之间的沟通。（服务调度层实质上建立了在DSPT（调度器）和依赖于服务的TSP之间路由声音/数据，TU的位置，客户的信息）。

服务调度层的定义是NGTP服务调度层文档（NGTP Dispatching Services Layer Document）。这个定义文件涵盖了调度层的调度相关的接口IF#1，IF#2，IF#3。

这些接口和调度服务中可以在其中找到相应的章节。

服务控制层（Control Services Layer)

NGTP的服务控制层提供了被期望的、使服务应用层和服务调度层透明的能力。其中，有以下控制功能：交通管制，安全（加密/身份验证），服务质量（Qos），承载控制和质量可靠性。

NGTP的服务控制层定义文件是NGTP服务控制层文件（NGTP Control Services Layer Document）。本定义文件涵盖了控制功能相关的接口IF#1和IF#2的细节。

这些接口和控制服务中可以在其中找到相应的章节。

3. 协议细节

3.1. 服务应用层（Application Services Layer)

NGTP服务应用层在本文档中主要描述为远程信息处理的目的。它可以让Telematics服务提供商（TSP）提供远程信息处理应用。此项工作主要通过NGTP的核心架构接口，接口IF#1和IF#2。

NGTP的服务应用接口层接口IF#3是供应应用服务的接口。

NGTP的应用服务层接口IF#4 –IF#7，能够在各自的小节被看到，描述了被传输数据的数据类型（应用层API），但没有规定应如何做（没有要求传输媒体或网络的使用）。

图3.1 架构概览

3.1.1. TU应用服务（接口IF#1和IF#2）

图3.1.1 子系统接口视图

3.1.1.1. 功能模型

该功能模型描述了接口的操作。包含适当信息域的子系统，通过发送讯息调用子系统的接口的操作。

每一个应用程序的消息在服务数据之前包括一个上行或下行的业务数据头。

3.1.1.1.1. 消息头

上行请求消息头：这个消息头被添加到从TU发送到TSP的请求消息。

表3.1.1.1.1-1 上行请求消息头

下行请求消息头：这个消息头被添加到从TSP发送到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-1E-callRequest

EcallUpdateRequest：

表3.1.1.1.2-2E-callUpdateRequest

IcallRequest：

表3.1.1.1.2-3IcallRequest

远程服务（Remote Services）

Remote Car Data (RcdRequest)：远程车辆数据（RCD）被用于获取诊断数据或者其他车辆的关键信息。请求者可以指定他们感兴趣的特定的数据。

表3.1.1.1.2-4RcdRequest：Remote Car Data

Remote Door Unlock (RduRequest)：

表3.1.1.1.2-5RduRequest：Remote Door Unlock Request

Remote Door Lock (RdlRequest)：

Remote Climate Control (RccRequest)：

Remote Horn Blow (RhblRequest)：

3.1.1.2. 动态模型

3.1.1.2.1. 消息时序

在进行请求-应答时，消息被交换。每一个消息被定义了一个会话ID（session-id）和一个请求ID（request-id）。会话ID是由会话的发起者标识，并由会话发起者设置计数器。请求ID是自增的，无论何时新的请求消息发出后。

请求的答复，被标记为与请求相同的会话ID和请求ID。

3.1.1.2.2. 消息格式

消息格式定义的ASN.1格式在另一份文件。

3.1.2. 接口IF#3

本文档介绍了调度器（DSPT）和规范数据提供程序（PDP）之间的接口IF#3。本文件并不试图描述接口细节，自配置和路由作为一个运行时组件的服务以及所需要的数据类型多种多样，具体到OEM详细的接口。

3.1.2.1. 功能模型

3.1.2.1.1. 消息头

消息头定义在相关的“TU应用服务”章节。

3.1.2.1.2. 规范数据提供服务接口

配置更新请求（ConfigurationUpdateRequest）：

答复（Acknowledgement）：

3.1.2.1.3. 规范TU服务（ProvisioningTuServices）

配置更新通知（ConfigurationUpdateNotification）：

配置更新（ConfigurationUpdate）：

3.1.2.2. 动态模型

这里分成通知提供和立即提供两种方式。

3.1.2.3. 消息格式

消息格式定义的ASN.1格式在另一份文件。

3.1.3. 接口IF#4

本文档介绍了TSP和客户数据提供程序（CDP）之间的接口IF#4 。本文件并不试图从客户和合同数据的类型描述细节，因为特定OEM的数据类型是非常庞大和多样化的。

3.1.3.1. 功能模型

3.1.3.1.1. 客户数据提供（CustomerDataProvider）

查找客户（SearchCustomer）：CDP向TSP提供这个功能用来查找客户。TSP使用的搜索条件，例如客户的姓名，车辆种类，车牌号码等，以获取例如相关的客户列表，客户ID，姓名，车辆数据等。

获取客户数据（GetCustomerData）：CDP提供这个功能给TSP，基于一个独特的标识符，例如客户ID或VIN的，来获取客户的详细数据。返回的数据可能包括姓名，地址，相关人士，相关车辆数据等。

获取许可服务（GetAllowedService）：CDP向TSP提供这个功能给来获取每个节点标识的可用服务（例如 VIN）。

获取认证指令（GetAuthenticationInstruction）：CDP向TSP提供这个功能来获取客户的认证信息，例如“问秘密问题”或“询问密码”。

验证认证数据（VerifyAuthenticationData）：CDP向TSP提供这个功能来验证客户，如：远程服务通过检查由客户给出的秘密问题的答案，其结果是确定或否定。

3.1.3.2. 动态模型

3.1.3.2.1. 从远程服务验证客户

3.1.3.2.2. 获取客户

3.1.3.3. 消息格式

该消息格式不在这个文件中指定，但转换信息的首选方法是使用一些面向服务的集成技术，如Web服务。

3.1.4. 接口IF#5

接口IF#5的目的是描述信息如何与TSP和PSAP（公共安全应答点）进行交流。这个接口是为了提供信息给PSAP，使他们能够有效地执行E –call救援服务。

从TSP通过接口IF#5的资料是有效的，不会被欧洲E-all方式混淆，因为它试图建立一个数据的最小集合（MSD）来直接从车辆发送到PSAP。通过接口IF#5的数据，将是一个更为丰富的数据集合，包括车辆数据，客户信息和定位服务组成数据，有效的提供给PSAP。 PSAPs必须有从TSP直接访问这些碰撞数据的能力。这份文件没有定义或承担任何计划来提供这种基础设施给PSAPs。

有一个欧洲的倡议规范该接口。欧盟委员会曾建议欧盟应为自己确定了到2010年减少一半的道路死亡人数的目标。一个关于如何实现这一目标的建议是要求为所有新车的标准选择电子呼叫。欧盟2010年9月1日起批准了该建议。这项工作是由eSafety支持论坛的一部分，eCall驱动组织推动的。

eCall驱动组织定义了一个被PSAP要求的数据的最小集合（MSD），以确保正确的应急资源调配。（MSD是数据的建议将从上述的PSAP直接发送到车辆）。eCall驱动组织还承认，电子呼叫效果可以通过发送额外的车辆和个人相关信息从TSP通过接口IF#5提供的相关资料进一步改善。这些额外数据的建议，目前正在由欧洲工作的PSAP和TSP的代表小组确定。

本文档考虑了TSP和PSAP的上述建议。

有两个E-call的替代流程：

1．从车辆通过TSP和呼叫中心到PSAP，通过接口IF#5（“NGTPE-call”）

2．从车辆通过无线网络直接到PSAP（无接口定义）（“Non-NGTPE-call”）。

3.1.4.1. NGTP E-call

NGTP E-Call是指E-Call从车辆通过DSPT和TSP到达一个呼叫中心，并进一步到达PSAP。这个E –Call服务包括所有TU提供的数据（位置，碰撞数据等）。

3.1.4.2. Non-NGTP E-call

非NGTPE-call是指E-call将直接通过网络从该车辆到PSAP。这个E –call服务可能不包括一个TU可以提供的所有的数据，但包括至少最低限度的数据集，例如：位置应该被提供。

可选的数据可以被发送到并行的TSP，使TSP提供这些数据给PSAP。

3.1.4.3. 功能模型

3.1.4.3.1. 在线服务数据提供（OnlineServiceDataProvider）

请求服务数据（RequestServiceData）：TSP给PSAP提供这个功能来在线请求服务数据。对服务请求的数据总是返回数据或错误消息。

3.1.4.3.2. 服务订阅提供（ServiceSubscriptionProvider）

开始订阅（StartSubscription）：TSP给PSAP提供这个功能来订阅一个服务数据。PSAP按照服务数据定义的消息格式提供返回的内容。

终止订阅（EndSubscription）：TSP给PSAP提供这个功能用来终止一个服务数据订阅。

声音呼叫终止（VoiceCallTerminated）：TSP给PSAP给PSAP提供这个功能来通知TSP，声音呼叫已经终止。PSAP返回为什么声音终止的原因描述，意外的还是非意外的。

开始订阅（StartSubscription）：

3.1.4.3.3. 服务订户（ServiceSubscribeer）

收到服务数据（ReceiveServiceData）：PSAP运行订阅时，PSAP为TSP必须实现这个功能来发布服务数据。

处理声音呼叫（HandleVoiceCall）：PSAP为TSP提供这个功能来请求处理一个得到的呼叫。PSAP将会返回呼叫处理的状态。

3.1.4.4. 动态模型

3.1.4.5. 消息元素

互换消息的首选方法是使用一些现有的标准技术，例如：数据和语音通话的VoIP网络服务。

下表描述了通过接口IF#5对PSAP有效的业务数据。

但是，上述数据元素的一些要视TU的能力而定。TU可以支持的任何其他的相关数据需求由欧盟，而不是在这里指定。

3.1.5. 接口IF#6a

这一节描述了TSP和呼叫中心之间的接口IF#6a。这一节不试图描述接口细节，因为呼叫中心是庞大而且多样化的。

3.1.5.1. 功能模型

3.1.5.1.1. 呼叫中心数据服务（CallCenterDataServices）

处理服务数据（HandelServiceData）：呼叫中心为TSP提供这个功能来发布服务数据。

3.1.5.1.2. 呼叫中心声音服务（CallCenterVoiceServices）

处理声音呼叫（HandleVoiceCall）：呼叫中心向TSP提供这个功能来请求处理得到的呼叫。呼叫中心返回处理的状态。

3.1.5.1.3. TSP呼叫中心声音服务（TSPCallCenterVoiceServices）

声音呼叫终止（VoiceCallTerminated）：TSP为呼叫中心提供这个功能来通知TSP，一个声音呼叫已经终止。呼叫中心返回呼叫终止的原因，意外的还是非意外的。

3.1.5.1.4. TSP呼叫中心数据服务（TSPCallCenterDataService）

共享服务（ShareService）：TSP向呼叫中心提供这个功能来包含一个处理运行服务的其他部分，例如PSAP。基于服务类型和包含部分的能力，TSP将会共享服务数据，呼叫语音或者两者。

呼叫中心可以提供数据帮助TSP决定那一部分将被包含。

执行远程服务（ExecuteRemoteService）：TSP为呼叫中心提供这个功能来开始授权车辆中的远程服务，例如，车辆查询或者景点上传。

验证认证数据（VerifyAuthenticationData）：TSP为呼叫中心提供这个功能来验证客户要求执行远程服务的认证数据。呼叫中心提供客户提交的认证数据，例如，回答客户定义的问题或者一个密码。

查询客户（SearchCustomer）：TSP给呼叫中心提供这个功能来寻找客户。呼叫中心使用的查询标准，如客户的姓名，车辆种类，车牌号码等，以获得相关的客户数据，例如，客户ID，姓名，车辆数据等。

获得客户数据（GetCustomerData）：TSP提供这个功能允许呼叫中心读取必要的客户信息。客户数据返回包含诸如车辆、用户信息、所有用户许可的服务、远程服务验证认证所需的信息等。

重新路由服务（RerouteService）：TSP向呼叫中心提供这个功能来发起了主动服务转移到另一个呼叫中心。呼叫中心提供活动的服务和新的服务类型给TSP。任何相关的语音通话也被TSP重新路由。

实际重新路由的语音通话和相关数据是由DSPT执行的。当需要改变服务的时候，DSPT将会发信号给车辆（例如，当车辆发出的一个E-Call，被CC作为一个B-Call重新路由）。DSPT将会获得新的车辆数据并重新路由数据和已经完成的语音调用TSP和一个CC作为一个新的服务。

处理服务数据更新请求（HandleServiceDataUpdateRequest）：TSP为呼叫中心提供这个功能来请求从一个车辆活动的服务上更新数据，例如，碰撞数据作为一个E-Call更新。呼叫中心提供服务，TSP可以依照服务类型用不同的方式执行。

结束服务（EndService）：TSP向呼叫中心提供这个功能来结束一个服务。依据服务类型，TSP可以发送一个结束服务的请求给车辆。任何相关于服务的语音呼叫不需要被提供。

3.1.5.2. 动态模型

3.1.5.3. 消息格式

3.1.6. 接口IF#6b

本节描述的TSP和外部内容提供商之间的接口IF#6b。本节并不试图描述接口细节，因为内容提供商的数量和内容是非常大的和多样化的。

3.1.6.1. 功能模型

3.1.6.1.1. 在线内容联播（OnlineContentAggregator）

请求内容（RequestContent）：TSP给呼叫中心提供这个功能来在线请求内容。这个接口为内容提供了无状态的请求/应答API。一个对内容的请求总是返回内容，或者错误信息。

3.1.6.2. 动态模型

3.1.6.3. 消息格式

3.1.7. 接口IF#7

这一节描述TSP和外部提供商之间的IF#7接口。这一节不试图描述接口细节，因为内容提供商的数量和内容的类型是巨大的和多样的。

3.1.7.1. 功能模型

3.1.7.1.1. 在线内容提供（OnlineContentProvider）

内容提供商提供这个功能给TSP来无需订阅在线请求内容。这个接口提供了无状态的在线请求/应答API给内容。一个对内容的请求总是返回内容或者一个错误信息。

3.1.7.1.2. 内容订阅提供（ContentSubscriptionProvider）

开始订阅（StartSubscription）：内容提供商向TSP提供这个功能来开始一个特殊的内容订阅。TSP支持一个内容为内如服务数据定义消息格式。

结束订阅（EndSubscription）：内容提供商提供这个功能允许TSP终止一个内容订阅。

3.1.7.1.3. 内容订阅者（ContentSubscriber）

获得内容（ReceiveContent）：当TSP运行订阅时，TSP提供这个功能给内容提供商来发布内容。内容提供商使用这个功能把更新的内容推给TSP

3.1.7.2. 动态模型

3.1.7.3. 消息格式

3.2. 服务调度层（Dispatching Services Layer)

NGTP的服务调度层在本文档中描述为telematics目标的主要部分。它能使远程信息处理应用端点沟通，没有与数据或语音如何到达目的地的细节处理。这就允许telematics应用运行在车辆的TU环境里，使用不同的TSP的应用服务而不需要知道哪个TSP处理这个服务。

3.2.1. 接口概览

为了完全满足调度要求，一个调度服务子系统（或协议层）必须与中心调度节点一样，部署于需要服务的节点（TU，TSP，PDP）。

上图显示了不同的调度子系统接口的提供和使用。由DSPT提供的接口是调度数据和语音，同时把子系统（TU，TSP，PDP）的连接到DSPT提供的接口用于接收和发送数据/或声音。

3.2.2. 功能和动态模型

功能和动态模型描述了接口的操作。这些接口的细节在本文的分开的调度服务接口章节，并为每个概念接口分开描述，IF#1，IF#2， IF#3

3.2.3. 接口IF#1

这一节描述NGTP的调度子系统提供的接口IF#1。

3.2.3.1. 功能模型

功能模型描述了接口的操作。调用子系统接口的操作是通过发送包含相关信息域的消息给另一个子系统。每一个消息有头部，由消息穿越的子系统处理。

3.2.3.1.1. 调度车辆数据服务接口（DsptVehicleDataService Interface）

当发送到上行方向（车辆到后端）时，这些调度头在消息中出现。

调度车辆数据请求（DispatchVehicleData Request）：车辆TU的每一个应用消息需要发送作为一个DispatchVehicleData消息有效负载进行。通过发送DispatchVehicleData请求，TU调度服务层要求DSPT发布应用服务的有效载荷给适当的TSP。

3.2.3.1.2. 调度声音服务接口（DsptVoiceService Interface）

调度声音呼叫（DispatchVoiceCall）：调度声音呼叫用于TU使用一个声音呼叫到DSPT时。

3.2.3.1.3. TU数据服务接口（TUDataService Interface）

这些调度头总是出现在发出的下行方向（后端到车辆）消息中。

处理调度数据请求（HandleDispatchedData Request）：在一个应用的有效载荷里，DSPT发出处理调度数据请求给TU。

3.2.3.2. 动态模型

3.2.3.3. 消息格式

3.2.4. 接口IF#2

3.2.4.1. 功能模型

功能模型描述了接口的操作。调用子系统接口的操作是通过发送包含相关信息域的消息给另一个子系统。每一个消息有头部，由消息穿越的子系统处理。

3.2.4.1.1. 调度提供数据服务接口（DsptProviderDataService Interface）

创建事件ID（CreateEventID）：创建事件ID允许TSP从DSPT获得一个事件ID，这个事件是从TSP侧开始的。例如，从呼叫中心开始一个远程服务。

调度提供数据（DispatchProviderData）：通过发送一个调度提供数据请求，TSP要求DSPT发布应用服务数据给特定的TU。

Re调度服务（ReDispatchService）：ReDispatchService给TSP提供了调用另一个TSP服务的办法。

一个例子是TSP认识到，客户需要的是一个不同于调用请求的另一个服务。TSP创建一个通用的TSP到TSP的服务请求消息，包含了客户的需求，并请调度重新调度它。

这个功能叶被TSP用来拒绝一个服务。

结束服务（EndService）：TSP使用结束服务请求，给DSPT发信号，服务结束了。DSPT可以释放所有相关服务的资源。

3.2.4.1.2. 调度提供声音服务接口（DsptProviderVoiceService Interface）

处理声音呼叫终止（HandleVoiceCallTermination）：当一个声音呼叫终止的时候，这个服务可以使TSP通知DSPT。

3.2.4.1.3. 提供数据服务接口（ProviderDataService Interface）

处理调度数据（HandleDispatchedData）：TSP使用本服务请求包含应用服务数据的有效载荷和其他信息的处理所需要的应用程序提供的数据DSPT本身。

3.3. 服务控制层（Control Services Layer)

这个文档的目的是说明服务控制层（CSL）的在接口IF#1和IF#2的接口。这个文档定义了这些接口的语法和语义。CSL内部的架构不在本文范围，因此，外部的视角是只显示子系统，但内部并非如此。

3.3.1. 接口IF#1

3.3.1.1. 概览

控制服务层接口IF#1的建立是为了隐藏有关TU和DSPT之间沟通的复杂性。它必须能够处理，例如，不同类型的承担者（为语音和数据），安全和传输机制。复杂性在于，通过接口IF#1传递的介质的有效性可能随时间而改变。此外，应用服务可能有不同的通信需求。这也是控制服务层的责任，始终通过调度器DSPT通讯，实现中央调度的概念。