装置接口结构及协议的制作方法

专利名称：装置接口结构及协议的制作方法
技术领域：
本发明涉及数字电子装置中的数据处理，且更具体来说涉及一个或多个应用客 户端与一个或多个服务实体之间的消息传送。
背景技术：
例如个人计算机、膝上型计算机和个人数字助理等现代计算装置经常被栓系到 例如使计算装置能够通过接口进行通信的调制解调器等数据通信装置，所述接口包 括(例如)IEEE 802.11、码分多址(CDMA)、通用包无线电服务(GPRS)或通 用移动电信系统(UMTS)。运行于所述计算装置上的操作系统通常支持软件应用 客户端，例如使用由数据通信装置提供的通信能力来发送及接收数据的连接管理器 客户端。数据通信装置本身可向运行于计算装置上的软件应用程序提供大量服务， 例如用于接入网络系统状态的网络接入服务，用于通过无线链路发射及接收数据的 无线数据服务，及用于接入装置识别和功率等级状态的装置管理服务。在物理层中，计算装置与数据通信装置之间的通信可通过物理互连结构(例如 包含USB、 RS-232、 PCI和PCMCIA的串行总线，或包含蓝牙和正EE 802.11的无 线接口)而发生。对于运行于计算装置上的应用程序客户端与运行于数据通信装置 上的服务(即客户端服务接口)之间的上层通信，在现有技术中已利用的协议包含 为W-CDMA 3GPP终端(见"用于用户设备的AT命令集(AT command set for User Equipment)"，版本1999， 3GPP TS 27.007 V3.13.0 (2003))禾卩CDMA 3GPP2 终端(见"展频系统的数据服务选项AT命令处理及Rm接口 (Data Service Options for Spread Specrum Systems: AT Command Processing and the Rm Interface) " ， 3GPP2 C.S0017-003-A)指定的AT命令集、远程网络驱动器接口规范(RNDIS)和通用即 插即用(UPnP)。当前，计算装置支持越来越多的通信应用，同时数据通信装置越来越能够支持 大量通信技术。例如，膝上型计算机可运行例如网络浏览器、电子邮件等通信应用， 及使用支持蓝牙、正EE 802.11和CDMA的调制解调器的日历同步。这类情形已导致对某些在现有技术中不易发现的客户端服务接口特征的不断增长的需要。 发明内容本发明的一个方面提供包括用于产生至少一个服务消息的控制模块和用于产 生多路复用消息的多路复用模块的装置，所述多路复用消息包括所述至少一个服务消息、用于识别至少一个与所述至少一个服务消息相关联的控制点的客户端ID字 段、及用于识别与所述至少一个服务消息相关联的服务实体的服务类型字段。本发明的另一方面提供一种装置，其包括控制装置，其用于产生至少一个服 务消息；及多路复用装置，其用于通过共用信道将由所述多个控制模块产生的所述 服务消息多路复用。本发明的再一方面提供一种用于连接多个装置的方法，所述方法包括提供至 少一个服务消息；产生多路复用消息，所述多路复用消息包括所述至少一个服务消 息、用于识别与所述至少一个服务消息相关联的控制点的客户端ID字段、及用于 识别与所述至少一个服务消息相关联的服务实体的服务类型字段。


图1显示根据本发明实施例可用于各装置之间的通信的分层消息传送结构。 图2描述根据本发明实施例用于使数据通信装置向请求使用服务实体的个别控制点指派客户端ID的程序。图3显示根据本发明实施例用于服务消息的优选消息格式。 图4显示根据本发明实施例可用于图1所述分层消息传送结构中的有效负荷格式的实施例。图5显示根据本发明实施例包括多路复用消息的控制信道消息的实施例。图6显示根据本发明实施例包括单独的数据信道和控制信道的本发明实施例。图7显示根据本发明实施例用于连接多个装置的方法。
具体实施方式
现代TE和DCD的特征已导致对在现有技术中不易发现的某些客户端服务接 口特征的不断增长的需要。例如，为便于应用程序客户端软件的实施，将需要具有 一组为独立于由数据通信装置所使用的特定技术的客户端服务接口界定的服务命 令。另外，为灵活控制，将需要在计算装置与数据通信装置之间具有可支持同时的 数据及控制会话的通信信道。此外，将需要具有能够同时支持单个或多个计算装置 上的多个客户端与运行于单个或多个通信装置上的多个服务进行通信的多路复用 协议。图l显示可用于终端设备(TE) 118与运行于数据通信装置(DCD) 119上的 服务实体之间的通信的分层消息传送结构。在实施例中，数据通信服务可以是包括 多个专用集成电路(ASIC)的调制解调器。终端设备可以支持已知为控制点101、 102、 103的软件或硬件应用客户端或装置驱动器，其与运行于DCD 119上的服务 实体114、 115进行通信。应用客户端的实例包含连接管理器、IP语音应用程序或 通信装置驱动器。服务实体的实例包含用于通过无线链路发射及接收数据的无线 数据服务实体，用于接入网络系统状态的网络接入服务实体，及用于接入装置识别 及装置功率等级状态的装置管理服务实体。在这一说明书和权利要求书中，应用客 户端及服务实体还可以统一称为控制模块。如图1中显示，通过服务接口 107、 108、 109在控制点101、 102、 103与服务 实体114、 115之间发送的点对点消息一般可称为服务接口消息或服务消息。每个 服务实体均界定服务消息和服务消息格式的所支持组。在实施例中，可以根据在这 一说明书中稍后描述的通用服务模板来指定服务接口消息的格式。这种模板允许应 用程序客户端使用单个统一接口来控制DCD所支持的各种服务。在实施例中，服务消息可以是控制消息，其通过逻辑控制信道来封装控制点与 服务实体之间的更高层应用程序接口 (API)消息。这些API消息可以是每一应用 客户端专用的。在实施例中，服务接口消息无需封装API消息，且可以针对每一特 定服务实体而单独界定。终端设备118和DCD 119上的客户端或驱动器可针对以下功能来使用专用 CTL控制实体104和CTL服务113:协商客户端ID并获得TE及/或DCD的服务消 息版本。应注意，在终端设备118上，CTL控制装置104可以实施为驱动器的一部 分或单独实体。图2描述用于使DCD向请求使用服务实体的个别控制点指派客户端ID的程 序。首先，在块201处，驱动器向DCD发送对客户端ID的请求。如果在块202处 可获得未使用的客户端ID，则所请求服务实体的处理器可在块203处向控制点指派 客户端ID。控制点可实施于驱动器、核心模块、库或用户应用程序中。在实施例中， 在每一驱动器中均存在控制点，且在每一应用程序中存在一个或多个控制点。应注 意，如果存在多个使用相同类型服务的驱动器，则每一驱动器可通过专用的物理互 连信道(例如专用的USB信道)将其客户端ID指派发送到其自身。如果不存在可 用的客户端ID，则在块204处，处理器可向驱动器发送服务实体的所有客户端ID 均已用尽的消息。应注意，如果驱动器不再需要与服务实体进行通信，则驱动器可 通过发送释放客户端ID请求来释放客户端ID。再次参照图l，通过服务接口107、 108、 109发送的服务消息可进一步经封装 以在MUX层上输送，如TE上的MUX模块105和DCD上的MUX模块116所实 施。MUX层("MUX")允许通过单个物理互连结构(例如通用串行总线(USB)) 对服务接口消息进行多路复用。MUX还可以识别发送特定消息的实体类型(例如服务或控制)。对于每一服务实体，MUX还可以通过识别客户端ID字段从而允许多个客户端利用单个服务实体来支持多个控制点。应注意，同时支持多个客户端的能力使得服务能够为每一控制点指派单独的通 信路径。这允许(例如)控制点与服务实体单独交换验证证书，从而允许服务仅接 入授权客户端，且反之亦然。此外，服务可出于完整性和机密性保护的目的与每一 控制点协商加密密钥。为进行资源管理，服务还可以跟踪及约束同时接入所述服务 的客户端数目。所述服务还可以跟踪每一客户端的客户端专用状态信息，以及仲裁 从多个客户端接收的请求。应注意，前述特征的列举仅旨在图解说明支持多个同步 客户端的本发明实施例的某些益处。所述特征的列举并不旨在将本发明的范围限定 到仅具有这些特征的实施例。MUX消息可进一步经处理以通过由装置层模块106和117实施的装置层进行 输送。装置层可包含以下模块例如，功能驱动器(未显示)、逻辑装置(未显示) 和用于通过物理互连结构(例如USB、 RS-232、 PCI、和PCMCIA)或无线链路(例 如蓝牙和IEEE 802.11)及共享存储器接口来驱动装置接口 112的总线驱动器(未显 示)。在实施例中，每一逻辑装置还可以装备有用于与服务实体进行通信的独立数 据信道(未显示)，所述独立数据信道能够与控制信道同时操作。例如，可为数据 信道和控制信道提供单独的发射及接收路径排队，以及单独的流控制机构和单独的 数据传输调度。在实施例中，通过利用通用串行总线(USB)接口上的额外端点对 来实施单独的数据及控制信道。所述数据信道可使用标准数据链路层协议，例如 IEEE 802.3以太网数据链路层协议。所述数据信道的链路层可实施于物理互连驱动 器(例如USB驱动器)中，其中包的结束由零长度USB帧来划界。在实施例中， 如果物理层(例如USB)可支持这种IP包的成帧和边界检测，则因特网协议(IP) 包可通过数据信道直接发送。确切地说，物理层的帧大小应足够长以含有整个IP 包，而物理层驱动器应能够标记帧边界以恰好含有一个IP包。图6显示通过单独的数据及控制信道与DCD 630进行通信的终端设备600的 实施例。图中显示与应用程序1相关联的控制点601、与应用程序2相关联的控制 点602、与应用程序3相关联的控制点603和与应用程序4相关联的控制点604产 生及接收服务消息612、 613、 614。与逻辑装置618、 619来回传送服务消息612、 613、 614。逻辑装置618提供单独的数据信道621和控制信道624，而逻辑装置619 提供单独的数据信道622和控制信道625。在DCD 630上，可实施对应的功能层级， 例如逻辑装置641、642各自用于驱动单独的数据及控制信道，且服务消息传送650、 651、 652用于与服务实体660、 661、 662进行通信。应注意，终端设备600还可以包含产生并通过定制的API/服务框架来接收服务 消息的应用程序605、 606，以及对应的逻辑装置620、数据信道623和控制信道626。 这种定制的应用程序可以与控制点601、 602、 603、 604共享同一物理互连层，或 所述定制的应用程序可装备有单独的物理互连结构。在DCD630有对应逻辑装置643的定制API/服务框架653，以与服务实体663、 664进行通信。 应注意，尽管在这一实施例中逻辑装置618、 619、 620各自显示为支持单独的数据 信道和控制信道，但在其他实施例中，逻辑装置可支持仅单个用于输送数据及控制 二者的信道。在实施例中，DCD可以是可从San Diego, California的Qualcomm⑧有限公司获 得的移动台调制解调器(MSM)芯片集，且终端设备可以是例如个人计算机(PC)、 笔记本计算机、个人数字助理(PDA)或智能电话等装置。应注意，图1及6中描 绘的实施例仅是例示性，且不旨在限定本发明的范围。例如，通信端点无需是DCD 和终端设备。而是，运行于硬件或软件上的应用程序与服务之间的任何通信可使用 本发明的技术，例如通过USB电缆连接到MP3播放器的个人计算机，或甚至是运 行于同一装置中的不同处理器上、通过任何标准的进程间通信(IPC)机构进行通 信的控制点和服务。此外，可提供在图l及6中除此之外明确显示的其他消息传送 协议层，例如MUX层与装置层之间的其他输送层。现在将描述有利于上文给出的结构的消息传送协议。再次参照图l，代表运行 于终端设备118上的应用程序的控制点101可以使用服务消息通过服务接口 107与 运行于DCD119上的服务实体115进行通信。在一个实施例中，服务消息可以是三 种类型中的一者请求消息、响应消息和指示消息。特定消息的类型可以在与所述 消息一起发送的对应字段中指示。请求消息由控制点发出，且可以设定服务实体处的参数、来自服务实体的查询 参数值、或由服务实体配置指示消息的产生。有效请求一般将引起服务实体的对应 响应。应注意，控制点在发送新请求之前无需等待对先前所发送请求的响应。这允 许客户端与服务之间的异步操作。响应消息由服务实体响应于所接收的请求消息而发出。响应可含有结果代码， 其依据所请求的操作而指示成功或失败或误差状态。其他字段可响应于传送其他与 所述请求相关联的数据来提供。指示消息可以由服务实体响应于控制点的请求或无需控制点的任何请求而发 出。指示可被广播到所有控制点或单播到特定控制点。广播指示可用于(例如)由 服务实体向控制点以及任何相关联用户接口更新其状态。另一方面，单播指示可被 递送到具体指定的控制点。在事件使得服务发出单播指示时，服务可检查消息定义 中的任何与所述指示相关联的请求，且向每一控制点递送单播指示，所述每一控制 点发出相关联的请求。如果单播指示并不具有相关联请求，则所述服务可仍然向适 合的控制点发出单播指示，例如撤回客户端ID的消息。在实施例中，控制点可忽 略其接收的任何不支持指示。根据消息传送协议的一个方面，可以将从单个客户端到单个服务实体的数个服 务消息一起捆扎成一个传输，以有效利用通信链路。所述成束传输可以呈有效负荷 的形式，其还可以承载与所述成束传输相关的其他控制参数。在一个实施例中，如果数个服务消息在逻辑上形成单元(例如实施单个API命令所要求的一组消息，或 一组周期性发出的状态查询请求)，则可将其捆扎在一起。在一个实施例中，有效 负荷可包括指定所述成束服务消息的消息类型的字段，例如所述消息是请求消息、 响应消息还是指示消息。在另一实施例中，有效负荷还可以指定可能与控制点发出 的每一有效负荷唯一相关联的事务ID字段。因此，服务实体可以向与请求消息相关联的响应消息附加同一事务ID。在一个实施例中，控制点在每次发送新的请求消 息时使事务ID递增。在一个实施例中，服务实体处理成束请求消息中的每个请求，并按与在成束请 求中接收所有对应响应的相同次序来返回单个成束响应消息中的所有对应响应。如 果在束中包含未经辨识的请求，则服务实体可在响应于所述请求而传输的束中包含 错误消息。如果成束请求中的请求长度被不正确地接收，则服务实体可在成束响应 中包含对被破坏请求之前的任何经成功处理的请求的所有响应，其中所述被破坏的 请求与指示未经辨识的接收请求的单个错误消息响应捆扎在一起。最后，如果正确 接收服务消息，但所述服务消息中的参数被破坏，则可以返回一般错误消息或所述 服务消息特定的错误消息。在消息传送协议的多路复用方面，通过向每一有效负荷附加相关联的客户端ID字段和服务类型字段以形成多路复用消息，可以通过同一物理互连结构发送来自旨 在用于不同服务实体的不同控制点的有效负荷，且反之亦然。例如，在图1中，通 过服务接口 107在控制点101与服务实体115之间发送的成束服务消息可具有设定 为1的客户端ID和设定为2的服务类型。同样，通过服务接口 108在控制点102 与服务实体114之间发送的有效负荷可以具有设定为1的客户端ID和设定为1的 服务类型，同时，通过服务接口 108在控制点102与服务实体114之间发送的有效 负荷可以具有设定为2的客户端ID和设定为1的服务类型。以此方式，可以通过 同一MUX层来发送所有服务消息。应注意，确切地说，消息传送协议的这一方面 使得能够通过为每一控制点指派唯一的客户端ID而使多个控制点与单个服务实体 进行通信。在一个实施例中，还可以向有效负荷附加控制字段，以指示消息的起源是控制 点还是服务实体。这允许服务及控制点以可互换的方式定位于终端设备与DCD 二 者上。客户端ID、服务类型和控制旗标字段中的任一者或全部可作为前同步码或后 同步码附加到有效负荷中，或者可将其定位于有效负荷中的任一处，只要这一位置 是根据具体消息格式而预定的。针对消息发送协议的发射机实施方案可以在通过物理互连结构进行传输之前向有效负荷附加这些参数。同样， 一旦接收机实施方案接 收消息，则接收机可以从有效负荷中剥离所述字段，且将向指定的控制点或服务实 体分派所述有效负荷。一般来说，多个控制点可使用上述的多路复用方案与单个服务实体介接。为解决共享DCD上的共用资源的多个控制点之间可能出现的争用，服务实体可维持服 务共享状态变量。服务实体可经由轮询向控制点提供关于状态变量的信息(例如请 求及响应消息)，及/或基于事件的指示消息。在替代实施例中，服务实体可以分配多个资源以指派给每一客户端，(例如)以维持服务质量(QoS)流，其中每一控制点可以为每一控制点维持单独的服务状态变量。消息传送协议的另一方面提供用于处理控制点与服务实体之间的服务消息格 式版本差异。在实际的装置互操作中，可能出现其中由控制点支持的服务消息与服 务实体所支持的服务消息是不同(即较早或较晚)版本的情形。确切地说，在服务 发生变化时出现主服务版本差异，以使得特定消息格式变得与前一消息格式不兼 容。将导致主版本递增的变化包含但不限于改变现有消息的含义、从所界定消息的列表中整体移除消息、移除与消息ID相关联的强制参数、改变与消息ID相关联的 任何参数的含义、及向消息格式中添加任何强制语义。相反，当服务规范发生变化但不打破与同一主版本的先前规范的后向兼容性 时，出现次要版本差异。这可能发生在(例如)向服务中添加新特征时。将导致次 要版本递增的变化包含但不限于添加新消息、向现有消息添加新的可选参数、向现 有消息添加新的错误代码、及向现有参数添加新值而不改变现有值的应用。在服务实体通过轮询(请求/响应)消息传送或指示消息传送来指示其版本时，可以确定控制点与服务实体之间的版本差异。为促进具有不同消息格式版本的控制 点与服务实体之间的互操作性，消息传送协议可指定处理这些版本差异的方式。根据一个实施例，控制点将不与利用不同的主版本编号的服务实体进行互操作，且反 之亦然。控制点仍然可以与利用同一主版本但不同的次要版本的服务实体进行互操 作。这些互操作性可以实现如下。对于其中控制点的次要版本比服务实体的次要版本大(即，更新)的情形，控 制点和服务实体可以遵循某些操作规律。首先，控制点可以检测服务的(较旧)次 要版本且仅发出兼容的消息及/或参数。可以停用可能触发不被服务实体支持的功能 的较新控制消息。例如，在一个实施例中，可以停用不被客户端支持的图形用户界 面按钮。第二，控制点可以忽略服务器的次要版本且盲目地发出较新请求。然后， 服务实体将拒绝未经辨识的请求，且忽略未经辨识的参数。如果服务实体辨识出所 述消息及所有包含的参数均有效，其仍然可以执行所述请求。第三，控制点可经配 置以使得缺乏作为响应的可选参数或来自服务实体的指示消息不会破坏控制点的 正确操作。第四，控制点还可以经配置以使得缺乏来自服务的新指示消息不会破坏控制点的正确操作。对于其中控制点的次要版本比服务实体的次要版本小(即，较旧)的情形，控 制点和服务实体可以根据某些其他程序来操作。响应于发出较旧请求的控制点，服 务实体可以用较旧及较新参数二者来响应。在这一情形中，控制点可以仅忽略较新 的未辨识参数，且如同其处于较旧服务版本下一样来处理较旧的参数。控制点还可以忽略任何具有较高服务版本的指示消息。应注意，还可以在所接收的消息含有不可辨识的可选参数或字段时应用上述操 作规律，例如由于物理互连结构引入的破坏，仅通过作为对应于不支持的消息版本 来处理不可辨识的参数或字段。在一个实施例中，为确保利用不同的次要服务版本的装置将仍然可以进行互操 作，可遵循以下规则来界定服务规范。首先，不添加强制参数，或在指定服务版本 之后移除强制参数。第二，不改变可选参数以使得按不同方式来代表原值，或呈现 不同的含义。在一个实施例中，针对消息传送协议界定的服务消息可以提供跨越多个由DCD支持的技术的共用命令集。例如，应用程序可以发出"获得信号强度(get signal strength)"命令，以针对所有支持的技术向DCD同时检索信号强度状态。以此方 式，应用程序无需发出技术专用命令，从而放松了应用程序软件的实施方案。除共 用命令集外，所界定的服务消息还可以包含其他技术专用命令，例如允许每一数据 会谈的技术专用简档的配置。在一个实施例中，DCD可以使用一组所存储的技术专 用简档，或者是仅使用共用命令消息的装置默认简档。所述应用程序或DCD均可 以决定使用哪一简档。在一个实施例中，可以结合根据另一协议指定的命令来使用为消息传送协议界 定的服务消息，例如AT命令协议。这可以通过设定在MUX层上发送的消息的接 口类型字段的值以指示所述整个MUX消息是根据另一协议(例如AT命令协议) 来界定和格式化而实现。在替代实施例中，可保存MUX格式，但可以将服务类型 字段设定为指示对应的有效负荷携载有根据另一协议界定的消息的值，所述另一协 议可以是由标准机构界定的熟知协议，或预定的私有协议。现在将描述可用于服务接口消息和MUX层消息的消息格式的实施例。应注意， 在这一揭示内容中描述的消息传送协议无需使用本文所述的特定MUX格式，且所 揭示MUX格式内的字段的各种重新排序、删除、添加及/或替代位长度也在所涵盖的消息传送结构及协议的范围内。图3显示服务消息n (例如图1中所示的那些通过服务接口 107、 108、 109来 交换的消息)的优选消息格式。在图3中，字段的字节长度由对应字段上的数字来 指示。应注意，所显示的字段长度仅是优选的字段长度，且在特定MUX消息格式 实施方案中，字段长度一般可以是任意长度。在优选实施例中，可以按"小端 (little-endian)"格式(即最小有效位第一)来传输MUX消息中的所有位。在这 一规范中，位编号的惯例是位0是最小有效位。每个服务消息均可具有类型长度值(TLV)结构，包括识别正在发送哪些消息 的消息ID 301,和指定值字段303的长度的长度字段302,所述值字段303紧跟着 长度字段302。 一般来说，类型字段允许区别在TLV结构中正指定哪一参数。在一 个实施例中，类型字段的含义在给定服务消息内的所有TLV参数之间是唯一的，但在服务实体中的所有消息之间或所有服务实体之间不必是唯一的。在一个实施例 中，除非另外指定，否则值字段含有正的二进制值。以此方式，二进制数据可以天 然地由所提供的消息格式支持。应注意，依据特定服务消息，值字段303本身进一步可包括大量TLV参数319 和320，其各自具有相关联的类型、长度和值。值字段的内容可进一步包括更多TLV 参数等。图3中图解说明的第一TLV参数319显示具有其他长度子字段315、 317 以支持第一TLV319的值字段306中的各种长度参数的值字段。应注意，如果值子 字段314是在消息定义中给定的固定长度值，则其可能不需要相关联长度。因此，单个服务消息中可包含多个参数，且可针对每一参数明确指定类型、长 度和值。 一般来说，TLV格式便于服务消息内各参数的随意排序，除非特定服务消 息的定义另外指定，其中参数出现的次序可以指示其类型。每一参数可以是强制的 或可选的。强制参数是经常提供于特定消息ID的消息中的参数，而可选参数是可 能或可能不出现于特定消息ID的消息中的消息。在一个实施例中，在服务消息中 缺乏可选参数不会导致错误或破坏控制点或服务实体的正确操作。只要所有强制参 数都是有效的，服务实体就可以处理消息并执行所有指示的行为。在一个实施例中， 将服务消息内的所有强制参数置于所有可选参数之前。在一个实施例中，可选TLV的供应使得能够支持服务消息的可选加密。例如， CTL服务可以在起始期间协商加密密钥参数，而将要加密的特定服务消息可以含有 可选TLV参数以指示加密服务消息的出现。由于可选TLV参数定义为无需在每一 服务消息中提供，这使得实现了每个消息的可选加密。服务消息可以通过向消息附 加可选TLV参数以验证消息的发送者来选择性地使用类似机构进行验证。选择性完 整性保护也可以通过向消息附加可选TLV参数以检验其尚未被损害来实施，例如通过向消息的各个位附加应用散列函数的结果。应注意，在特定服务消息中传达的任何信息均可以在任何数量的TLV参数之 间划分。在一个实施例中，单个TLV用于数据结构的所有逻辑耦合数据元素。在实施例中，服务消息中的每一 TLV的类型字段均是1字节长。类型字段的 前16个值(即OxOO-OxOf)可能具有跨越同一服务类型的所有消息而共用的保留含 义。每个消息的可选和其他TLV参数可能以大于OxOf的类型字段值开始。例如，类型0x01可用于所有请求消息中，以指示对应的值字段携载有一组强 制参数。在图3中，第一TLV参数319的类型字段304可被设定为0x01，且对应 的值字段306可以进一步包括一系列参数，所述参数各自可以由值字段314、 316、 318和长度字段315、 317来指定。如果不存在为消息界定的强制参数，则其可能忽 略强制TLV。可选参数(如果为消息ID界定)可能遵循强制TLV。在实施例中，响应类型消息可以各自包含已知为结果代码TLV的强制第一 TLV，其中将类型字段设定为0x02。对于所接收的每个请求，服务实体可以返回具 有值字段的结果代码TLV，以指示成功或失败。如果返回失败，则可以返回错误状态值，且随后所述消息可以忽略任何随后的强制TLV参数。响应消息的其他强制字段(如果为所述消息ID界定)可以包含于强制TLV中，其中接续结果代码TLV而 将类型设定为0x01。否则，响应消息可以忽略强制TLV。可选参数可以接续强制 TLV参数作为个别TLV。在实施例中，如果指示类型消息具有强制参数，则将那些参数作为强制TLV 的一部分包含于第一TLV的值字段中，其中将类型字段设定为0x01。如果不存在 强制参数，则指示消息可以忽略所述强制TLV。任何可选参数均可以接续强制TLV 作为个别TLV参数。图4显示可用于图1所述的分层消息传送结构中的有效负荷格式的实施例。 在一个实施例中，可以将数个服务消息404、 405、 406 —起捆扎为单个有效负 荷，如图4所示。有效负荷401可以包括例如控制旗标402、事务ID403等字段， 接续一系列服务消息404、 405、 406。控制旗标402和事务ID 403字段可以一起称 为一般化服务消息标头404。应注意， 一般来说，有效负荷可以经配置以支持任意 数量的服务消息。控制旗标字段402可以指定与有效负荷消息中含有的服务消息相关联的消息类 型，例如请求、响应或指示。事务ID字段403是可用于将所发送的消息编入索引及/或使得响应消息与给定 客户端ID的对应请求消息相关联的数字识别符。现在将描述可用于图1的MUX层105、 116的指定MUX消息格式。如图5中 显示，有效负荷可以嵌入到控制信道消息501中。控制信道消息501可以包括MUX MSG 502和接口类型字段504。控制信道消息501可以具有接口类型字段504，其 指定正使用哪种类型的MUX格式，或是否使用MUX格式。接口类型字段可以被 设定为0x01的16进制值，以指示根据本文所述的优选MUX格式来格式化接续消 息。其可被设定为另一个值，以指示替代格式的使用。以此方式，可以实现与其他 控制协议的互操作性，例如可以通过在接口类型字段504中指定不同的值来将AT 命令封装在控制信道消息501中。MUX消息502本身可以包括例如长度505、控制 旗标506、服务类型507、客户端ID 508和有效负荷509等字段。长度505、控制 旗标506、服务类型507和客户端ID 508字段可以一起称为MUX标头字段503。在实施例中，长度字段505可以指定MUX消息的总字节长度。在替代实施例 中，长度字段505可以指定仅有效负荷字段509的长度。控制旗标字段506可以指定所关注的各种控制参数。在优选实施例中，控制旗 标字段506的位7可以指定消息的发送者是服务(将位7设定为1)还是控制点(将 位7设定为0)。控制旗标字段506中的未使用位可以被设定为0。服务类型字段507可以指定在有效负荷字段中所提供的消息的服务实体类型。 例如，与DCD上的装置管理服务实体之间来回传送的消息可以具有设定为值0x01 的服务类型字段507。客户端ID字段508可以识别消息属于哪一应用程序客户端。在优选实施例中，通过将这一字段设定为值0xff，服务实体可以向所有利用在服务类型字段507中指 定的服务类型的控制点或客户端广播指示消息。有效负荷字段509可以携载实际的服务接口消息107、 108、 109，所述服务接 口消息在图1的控制点101、 102、 103与服务实体114、 115之间进行交换。图7显示用于根据本发明来连接多个装置的方法，其包括以下步骤在块701 提供至少一个服务消息，及在块702产生多路复用消息，所述多路复用消息包括在 块701处产生的至少一个服务消息、用于识别与所述至少一个服务消息相关联的控 制点的客户端ID字段703、及用于识别与所述至少一个服务消息相关联的服务实体 的服务类型字段704。本文所述技术可用于支持各种技术的数据通信装置，例如CDMA和UMTS技 术群、802.11、蓝牙等。这些技术还可以用于其他现有的和将来的无线网络技术。 一般来说，所述技术可用于支持单个无线网络技术的单模式无线装置和支持多个无 线网络技术的多模式无线装置。本文所述技术可以用各种手段来实施。例如，这些技术可以实施于硬件、软件 或其组合中。对于硬件实施方案来说，用于支持系统选择的处理单元可以实施于一 个或多个专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理装置 (DSPD)、可编程逻辑装置(PLD)、场可编程门阵列(FPGA)、处理器、控制 器、微控制器、微处理器、其他设计用于执行本文所述功能的电子单元、或其一组 合中。对于软件实施方案来说，可能用执行本文所述功能的模块(例如程序、功能等) 来实施系统选择技术。所述软件代码可以存储在存储器单元中并由处理器来执行。 所述存储器单元可以实施于处理器内或处理器外部，其中当在处理器外部实施时， 存储器单元可以经由所属技术领域中熟知的各种手段以通信方式耦合到处理器。本文提供所揭示实施例的上述描述以使得所属技术领域中的技术人员均能够 制作或使用本发明。所属技术领域的技术人员将易于了解对这些实施例的各种修 改，且本文界定的一般原则可以在不背离本发明的精神或范围的前提下应用到其他 实施例。因此，本文并非旨在将本发明限定为本文所示实施例，而是将要使最宽广 的范围与本文所揭示的原则与新颖特征相一致。
权利要求
1、一种装置，其包括控制模块，其用于产生至少一个服务消息；多路复用模块，其用于产生多路复用消息，所述多路复用消息包括所述至少一个服务消息；客户端ID字段，其用于识别与所述至少一个服务消息相关联的至少一个控制点；及服务类型字段，其用于识别与所述至少一个服务消息相关联的服务实体。
2、 如权利要求l所述的装置，其中所述客户端ID字段识别与所述至少一个服 务消息相关联的所有控制点。
3、 如权利要求l所述的装置，其中将所述客户端ID字段设定为特定值，以识 别与所述至少一个服务消息相关联的所有控制点。
4、 如权利要求l所述的装置，其中所述控制模块是所述装置上的第一控制点。
5、 如权利要求4所述的装置，其中所述至少一个服务消息包括请求消息，所 述多路复用消息进一步包括用于将所述多路复用消息识别为包括请求消息的消息 类型字段。
6、 如权利要求4所述的装置，其进一步包括所述装置上的多个控制点，每一 控制点可经配置以产生至少一个服务消息。
7、 如权利要求1所述的装置，其中所述控制模块是所述装置上的第一服务实体。
8、 如权利要求7所述的装置，其进一步包括所述装置上的多个服务实体，每一服务实体可经配置以产生至少一个服务消息。
9、 如权利要求7所述的装置，其中所述至少一个服务消息包括响应消息，所 述多路复用消息进一步包括用于将所述多路复用消息识别为包括响应消息的消息 类型字段。
10、 如权利要求7所述的装置，其中所述至少一个服务消息包括指示消息，所 述多路复用消息进一步包括用于将所述多路复用消息识别为包括指示消息的消息 类型字段。
11、 如权利要求l所述的装置，其中所述多路复用模块可进一步配置用于接收包括以下的多路复用消息至少一个所接收的服务消息；客户端ID字段，其存储用于识别与所述至少一个所接收服务消息相关联的控制点的客户端ID;服务类型字段，其存储用于识别与所述至少一个所接收服务消息相关联的服务实体的服务类型；及所述控制模块可进一步配置用于从所述多路复用模块接收所述至少一个所接 收服务消息。
12、 如权利要求ll所述的装置，其中所述控制模块是服务实体。
13、 如权利要求12所述的装置，其中所述服务实体可进一步配置以响应于所述服务实体从所述多路复用模块接收多个所接收服务消息而产生多个服务消息，且 其中所述多路复用模块可进一步配置以产生包括所述产生的多个服务消息的多路 复用消息。
14、 如权利要求13所述的装置，其中响应于所述多个所接收服务消息而产生 的所述多个服务消息是根据所述多个所接收服务消息的序列排序的。
15、 如权利要求14所述的装置，其中所述服务实体可配置以响应于接收未经 辨识的所接收服务消息而产生错误服务消息。
16、 如权利要求12所述的装置，其中所述服务实体可配置以维持用于解决多 个控制点之间的争用的共享状态变量。
17、 如权利要求12所述的装置，其中所述服务实体可经配置以维持用于多个 控制点中的每一者的唯一状态变量。
18、 如权利要求ll所述的装置，其中所述控制模块是控制点。
19、 如权利要求18所述的装置，其中所述装置进一步耦合到可操作以产生第 二装置的多路复用消息的第二装置，所述第二装置包括服务实体，其用于产生至少一个第二装置服务消息；第二装置多路复用模块，其用于产生第二装置多路复用消息，其包括由所述服务实体产生的所述至少一个第二装置服务消息；客户端ID字段，其用于识别与所述服务实体产生的所述至少一个第二装置服务消息相关联的控制点；及服务类型字段，其用于识别与所述服务实体产生的所述至少一个第二装置服务消息相关联的服务实体。
20、 如权利要求19所述的装置，其中所述第二装置是数据通信装置。
21、 如权利要求20所述的装置，其中所述数据通信装置可操作以通过无线空 中接口进行通信。
22、 如权利要求19所述的装置，其中所述服务实体是装置管理服务实体。
23、 如权利要求19所述的装置，其中所述服务实体是无线数据服务实体。
24、 如权利要求19所述的装置，其中所述服务实体是网络接入服务实体。
25、 如权利要求19所述的装置，其中所述服务实体是基于位置的服务实体。
26、 如权利要求ll所述的装置，其中所述控制模块是与所述客户端ID相关联 的控制点。
27、 如权利要求ll所述的装置，其中所述至少一个服务消息中的每一者包括:消息ID字段，其用于识别所述服务消息；消息长度字段，其用于指定所述服务消息的一部分的长度；消息值字段。
28、 如权利要求27所述的装置，其中所述至少一个服务消息的所述至少一者 的所述消息值字段包括第一类型长度值(TLV)字段，所述第一TLV字段包括第一TLV类型字段，其用于识别所述第一TLV的类型； 第一TLV值字段，其用于指定与所述第一TLV类型相关联的值；及 第一TLV长度字段，其用于指定所述第一TLV值字段的长度。
29、 如权利要求28所述的装置，其中所述第一TLV是用于所述至少一个服务 消息的所述至少一者的强制TLV。
30、 如权利要求29所述的装置，其中所述第一TLV值字段包括多个值字段。
31、 如权利要求28所述的装置，其中所述至少一个服务消息的至少一者的所 述消息值字段进一步包括其他TLV。
32、 如权利要求31所述的装置，其中所述其他TLV包括可选TLV。
33、 如权利要求32所述的装置，其中所述可选TLV包括用于对所述至少一个服务消息的所述至少一者进行加密的至少一个加密参数。
34、 如权利要求32所述的装置，其中所述可选TLV包括用于验证所述至少一个服务消息的所述至少一者的至少一个验证参数。
35、 如权利要求32所述的装置，其中所述可选TLV包括用于检验所述至少一个服务消息的所述至少一者的完整性的至少一个完整性保护参数。
36、 如权利要求11所述的装置，其中所述控制模块可配置以响应于接收次要 服务版本高于所述控制模块所支持的次要服务版本的所接收服务消息，而跳过所述 接收的服务消息中未经辨识的可选TLV。
37、 如权利要求11所述的装置，其中所述控制模块可配置以响应于接收次要 服务版本高于所述控制模块所支持的次要服务版本的未经辨识的所接收服务消息， 而忽略所述接收的服务消息。
38、 如权利要求11所述的装置，其中所述控制模块可配置以响应于接收次要 服务版本低于所述控制模块所支持的次要服务版本的所接收服务消息，而仅产生服 务版本与所述接收的服务消息的服务版本相同或比其低的服务消息。
39、 如权利要求11所述的装置，其中所述控制模块可配置以响应于接收未经 辨识的所接收服务消息，而拒绝所述接收的服务消息。
40、 如权利要求11所述的装置，其中所述控制模块可配置以响应于接收未经 辨识的接收服务消息，而忽略所述接收的服务消息。
41、 如权利要求l所述的装置，其中所述多路复用消息进一步包括用于存储与 所述多路复用消息相关联的事务ID的事务ID字段。
42、 如权利要求l所述的装置，其进一步包括用于为所述多路复用消息提供数据信道及控制信道的逻辑装置驱动器，所述控制信道独立于所述数据信道。
43、 如权利要求42所述的装置，其中所述控制模块可进一步配置以产生AT 命令，且所述逻辑装置的所述控制信道可配置以输送由所述控制模块产生的所述AT 命令。
44、 如权利要求42所述的装置，其中所述逻辑装置驱动器可配置以与通用串 行总线(USB) —起操作。
45、 如权利要求4所述的装置，其进一步包括用于为所述第一控制点接收所指 派的客户端ID的CTL模块，所述CTL模块可配置以产生用于所述多路复用模块的 服务消息。
46、 如权利要求45所述的装置，其中所述CTL模块进一步可操作以获得服务 实体的服务消息版本。
47、 如权利要求l所述的装置，其中所述装置是个人计算机。
48、 如权利要求l所述的装置，其中所述多路复用消息进一步包括指示所述控 制模块是控制点还是服务实体的控制旗标字段。
49、 如权利要求l所述的装置，其中所述装置进一步可操作以产生包括所述控 制模块产生的服务消息的非多路复用消息。
50、 如权利要求49所述的装置，其中所述服务消息包括AT命令消息。
51、 一种装置，其包括控制装置，其用于产生至少一个服务消息；多路复用装置，其用于通过共用信道对所述多个控制模块产生的所述服务消息 进行多路复用。
52、 如权利要求51所述的装置，其进一步包括多路分用装置，所述多路分用 装置用于接收多个服务消息及向所述多个控制模块中的相关联一者递送所述接收 的服务消息。
53、 如权利要求52所述的装置，其中所述装置进一步耦合到第二装置，所述 第二装置包括至少一个控制模块、用于对多个控制模块产生的服务消息进行多路复 用的多路复用装置、及用于接收多个服务消息并向所述多个控制模块中的相关联一 者递送所述接收的服务消息的多路分用装置。
54、 如权利要求51所述的装置，其进一步包括用于向所述多个控制模块中的 一者指派客户端ID的CTL装置。
55、 如权利要求52所述的装置，所述控制模块进一步包括服务版本差异处理 装置，其用于响应于从所述多路分用装置接收不同版本的服务消息而产生服务消 息。
56、 如权利要求51所述的装置，其中所述控制模块是控制点。
57、 如权利要求51所述的装置，其中所述控制模块是服务实体。
58、 一种用于介接多个装置的方法，所述方法包括提供至少一个服务消息； 产生多路复用消息，其包括 所述至少一个服务消息；客户端ID字段，其用于识别与所述至少一个服务消息相关联的控制点；及 服务类型字段，其用于识别与所述至少一个服务消息相关联的服务实体。
59、 如权利要求58所述的方法，其中所述多路复用消息进一步包括用于识别 所述至少一个服务消息的消息类型的消息类型字段。
60、 如权利要求59所述的方法，其中所述消息类型是请求消息类型。
61、 如权利要求58所述的方法，其进一步包括对所接收的多路复用消息进行多路分用，所述接收的多路复用消息包括至少一个所接收服务消息；客户端ID字段，其存储用于识别与所述至少一个所接收服务消息相关联的控制点的客户端ID;服务类型字段，其存储用于识别与所述至少一个所接收服务消息相关联的服务 实体的服务类型。
62、 如权利要求61所述的方法，其进一步包括为多个经多路分用的请求服务 消息中的每一者提供相关联的响应服务消息。
63、 如权利要求62所述的方法，其进一步包括以接收对应请求服务消息的次 序对每一响应服务消息进行多路复用。
64、 如权利要求63所述的方法，其进一步包括产生与未经辨识的所接收请求 服务消息相关联的错误响应服务消息。
65、 如权利要求61所述的方法，其中所述多路复用消息进一步包括存储与所 述多路复用消息相关联的事务ID的事务ID字段。
66、 如权利要求65所述的方法，其进一步包括每次产生多路复用消息时均递 增所述事务ID。
67、 如权利要求58所述的方法，其进一步包括为所述多路复用消息提供独立 的控制信道，且提供独立的数据信道。
68、 如权利要求67所述的方法，其进一步包括产生AT命令并通过所述独立 的控制信道来输送所述AT命令。
69、 如权利要求61所述的方法，其进一步包括跳过未经辨识的所接收服务消息。
70、 如权利要求69所述的方法，其中所述跳过是响应于接收到未经辨识的服 务消息。
71、 如权利要求58所述的方法，其进一步包括仅产生服务版本与所述至少一 个所接收服务消息的服务版本相同或比其低的服务消息。
72、如权利要求69所述的方法，其中所述至少一个服务消息中的至少一者包括消息ID字段，其用于识别所述服务消息；消息长度字段，其用于指定所述服务消息的一部分的长度；消息值字段。
全文摘要
本发明提供用于在多个装置之间传递消息的接口结构和协议。所述结构提供以下能力根据单个消息格式产生多个服务消息，及根据有效的多路复用协议在多个控制点(101、102、103)或服务实体(114、115)之间传递所述服务消息。控制点可以是运行于终端设备装置(118)上的软件应用程序或装置驱动器，且服务实体可以是通信服务，例如运行于例如调制解调器或蜂窝式电话等附接数据通信装置(119)上的网络接入服务或装置管理服务。
文档编号H04L29/06GK101283565SQ200680037437
公开日2008年10月8日 申请日期2006年8月8日 优先权日2005年8月8日
发明者凯于尔·C·沙阿, 厄平德·辛格·巴贝尔, 尼古拉·康拉德·内波姆塞诺·里昂, 杰弗里·艾伦·戴克, 詹姆斯·莱昂纳尔·帕尼亚恩 申请人:高通股份有限公司