具有修改设施的协议栈的制作方法

专利名称：具有修改设施的协议栈的制作方法
技术领域：
本发明涉及特别是但非排他性地用于通信终端如移动电话、膝上型计算机和基站的协议栈以及协议栈内的协议层。
背景技术：
诸如移动电话、膝上型计算机和基站的通信设备日益需要支持具有不同配置的多个协议栈，以允许(有可能同时)支持有可能支持不同可选特性的多个无线接入网络标准。例如，膝上型计算机可能需要支持无线局域网、GSM或UMTS、以及蓝牙上的安全和不安全的因特网接入。除了链路层的加密之外，作为IP协议栈内的VPN特性的一部分提供的安全性也作为协议栈内的不同选项而提供。然而，重要的是，未被加密的分组不被转发到其它不安全的(或较不安全的)栈。因此，支持这些不同通信标准的协议栈需要在安全的框架内提供。理想地，这些协议栈应当是可重新配置的，以便允许通过下载新的协议软件模块来支持新的通信标准或选项以及对现有标准的扩展。另外，通信设备日益需要能够高效地使用稀有的电池和射频资源。
因此，需要能够安装通信软件以允许新的空中接口技术和可选特性以及对这些技术的扩展，包括诸如增强的安全性、性能或功耗优化的附加功能性。
典型地，协议栈的重新配置要求以层间接口不能动态改变并且被明确定义(well-defined)的方式执行协议栈软件的模块化。协议栈和网络接口驱动程序软件框架存在于很多操作系统上，以检查协议(或驱动程序)模块遵循这些接口定义的正确版本，然后利用执行环境(操作系统)特定机制将这些模块安装到系统中。还可采取措施来证实软件并且对可由协议软件执行的功能施加限制。然而，这些限制通常没有考虑如前所述的协议栈布置的上下文，其根据正被支持的服务的类型而可具有不同的对安全性(执行环境)、保护措施和性能的要求。另外，这些现有方案没有考虑使用多个执行环境来实现协议栈布置。
通常，用于移动通信设备的协议栈由单个厂商提供。将来，终端设备将需要更灵活的协议栈来支持不同的通信技术，并且多个厂商可能涉及协议栈解决方案。对于可能需要支持具有很多可选特性的若干标准的无线终端，这尤其重要。因此，允许协议栈的增量更新是非常有吸引力的。
协议栈包括一组层，其中每层可被视作对所接收的分组或消息执行(对应于协议的)一系列预定步骤并且与特定的协议实现相关联的软件处理。在给定系统中可以例如使用多个线程来实例化多个逻辑协议栈，以同时支持多个具有相同基本类型的业务(traffic)类或网络接口。相同协议栈的多个逻辑实例传统地通过对所有这些逻辑协议栈实例使用单一的软件(协议栈配置)布置来实现。然而，这限制了为不同的逻辑实例提供不同的安全性和执行环境优化的灵活性。
只有所有模块以所需的时间性并按照正被使用的协议定义成功地交互，才实现协议栈的预期行为。由于大多数协议依赖于不同设备上的协议栈之间的交互以设置和维持通信连接，因此这还将取决于多个设备上的协议栈实现。灵活的允许软件层的动态插入替换或修改的协议栈总是易于受到恶劣软件(其可能是恶意的，或者只是行为恶劣)的攻击，其中该恶劣软件通过不遵从协议定义、向错误的接收者发送分组、破坏分组、形成不正确或无效的分组、或者截取和转发分组以故意窃听或获得对安全连接的访问或者简单地停止(中止)而可影响协议栈的总体操作或安全性。
WO 02/28052公开了一种无线网络接口，其具有可适配的协议，该协议使用参数来定义可编程协议栈行为。这允许通过使用不同的参数来进行有限数量的重新配置。然而，它不允许动态地插入新的协议软件模块或层。使用参数来定义可编程协议栈行为的可适配协议具有较为可预测的行为，因为可进行的重新配置的数量只是有限的。它们还没有提供与允许新协议软件模块的动态插入的协议栈同等的灵活性。
US 5751972公开了在运行时期间动态配置计算机以使用不同的协议在网络上建立数据传输路径。协议栈的组成通过使用操作系统特定链接机制来实现。这具有有限的灵活性，因为每个协议栈模块必须遵循特定操作系统相关接口定义。另外，只有有限范围的协议模块可用来确保层间交互是明确定义的，以便使该栈成功地操作。
WO 01/88707公开了一种灵活的协议栈架构，其在协议栈的每层之间采用活动的编程接口层，其提供上下协议层之间的灵活链接，使得可以在运行时可对此进行改变。然而，如果需要混合执行环境实现，则这些附加的中间层增加了栈的复杂性，并且会严重地降低其性能。另外，软件模块的链接是以执行环境和编程语言特定的方式(Java虚拟机)执行的，并且被优化以便采用Java中的动态类装载概念以允许协议栈的动态重新配置。
传统地，协议栈中的层将被设计成存在于多个预定状态之一中。特定状态中的层将被配置成可用来接收并响应特定消息或信号，将层变换到另一预定状态中或者保持该层的状态不变的消息。
这些预定状态之间层的有条件转变取决于由层接收到消息。通过允许与所利用的计算机编程语言无关地处理消息即促进语言无关性，并且还允许在不同执行环境中执行状态功能性，增强了使层具有灵活的行为的有效性。
为了使得能够进行有效且一致的层设计以及通过适合软件的设计的实现，设计者可以首先确定层的状态，以及描述响应于所接收的消息的层的期望行为的状态之间的转变。这样，层的每个状态可采用最适合的语言由对应的功能模块实现，并且可在最适合的执行环境中执行。
在这种情况下，状态模块定义其可实例化的层的一个特定状态的自包含功能性，从而捕获直接向其施加的消息，同时丢弃不是直接向其施加的消息，以便由在该层处于另一状态时处理该层的行为的另一模块进行处理。
在其中定义了协议栈的设备的生存期内，可能有必要改变该栈的一层或多层中的一个或多个模块的功能性。例如，如果需要扩展协议栈的功能性以例如适应新的通信技术，或者如果需要对协议栈的一层或多层进行微小的改进，则可能需要此。通过利用层装载功能来替换整个层将是有可能的。现在将参照附图描述使得能够将新层装载到协议栈中的典型设施。先前在较早申请的专利申请GB0322985.3中对此进行了描述，这里将该专利申请的副本包括在本申请中，并且将其引作参考。
图1示出本领域的技术人员所熟悉的通信协议栈。协议栈包括多个软件或协议层L1-L7，其中通过这些层处理信号或协议消息。例如，应用(L7)可以是万维网浏览器或用于GSM语音呼叫的控制器，由应用(L7)生成的信号和消息向下通过较低层L1-L6而被处理，以便通过某物理链路例如无线电波、铜线或光缆与另一个应用通信。
图2示出通信栈层之一的简化例子。每层如何工作的实际细节将取决于所使用的特定协议。该层接收诸如语音呼叫或网页的一部分的分组。该层是对所接收的分组执行一系列预定步骤(协议)的软件过程。第一步骤执行校验和计算，并且必要时拒绝分组，然后去除分组首标，并且另一步骤对其数据有效载荷进行解密。在另外的步骤中，该层然后可以在将经过修改的较大分组传出到较高层之前累积多个所接收的分组的数据内容。该累积可以(并且经常地)在共享缓冲器(或队列)中执行以便避免不必要的存储器复制。典型地，通信层还将在从高层到低层的相反方向上处理分组。原则上，两个相邻的层无需“知道”另一层正在做什么或者它如何做；但是实际上层间接口需要按照数据(分组)内容的准确格式、所通过的缓冲器存储布置以及如何实现此来定义，例如，知道将该数据传给哪一层，并且如何启动该层处理所传递的数据。这限制了如上面关于公知布置所述的栈的灵活性。
典型地，在制造的时候设置移动电话等中的传统、不可重新配置的通信协议栈，在工作存储器中实例化各个软件层所需的软件代码有可能作为电话内的固件来固定和存储。这意味着如果这些层之一需要升级，则需要关闭协议栈，并且将全部代码或者至少是升级的层代码重写到通信设备，然后重启该终端，并且重新实例化升级的协议栈。这要求终止通信设备上的所有活动通话，并且使该设备对于呼叫是离线的。该方案的另一个问题是不同的层典型地以非常特定的方式相互接口以使协议栈如上面参考文献中的一些所述工作。这意味着新的或升级的软件的提供者需要预先准确地知道如何针对特定实现和平台与上下层交互。同样，这限制了栈的灵活性。
其它所提出的在运行时支持协议栈的重新配置的方案允许下载协议软件并且动态地将协议软件插入到现有协议栈中，这是通过使用执行环境和编程语言特定机制来临时挂起栈执行并且将新的软件链接到现有的栈中。同样，这要求临时挂起活动的通信会话、以及新软件的提供者知道与什么其它栈软件接口、特定于当前所考虑的层的共享分组缓冲器布置，以及按照提供语言和操作系统特定命令和数据格式如何做此。这些方案还存在这样的风险，即如果软件的行为恶劣，则它可破坏很多活动的通信会话，直到检测到问题并且删除了恶劣软件为止。另外，允许插入新模块的层间接口不能被容易地升级或者单独地配置，从而限制了协议软件的不同逻辑实例之间的交互，这是因为逻辑实例不可见于一般性接口层。
此外，很有可能将来需要采用与其它层不同的软件语言来编写层。例如，接近于物理层的层需要快速的处理，从而可被预先编译成高度优化的硬件特定机器语言以便快速执行，而该栈的较高层可以是平台无关的，因此在虚拟机环境或解释器上操作，从而慢但灵活得多，以便允许平台无关性，因此鼓励第三方开发新应用。然而，使用不同语言的两层在语言特定数据结构、命名约定(名称处理约定)和函数调用(参数传递)约定这些方面不能采用公知的共同语言。
当前方案的另一个问题是，由于每层受到经常是语言和操作系统(执行环境)特定的支持上层和下层之间的交互的接口定义(包括共享缓冲器布置)的严重约束，因此当前方案限制了升级栈的能力。该情形在这样有可能的情况下加剧，即在将来，协议栈的不同层将由不同的厂商提供，因而，这些厂商将必须为它们需要与之接口的层提供使用相同语言(甚至在一些情形下，相同的编译器)的接口以及接口函数和共享缓冲器格式。
提供动态灵活的Java协议栈的一种公知方案如图3所示，并且其利用每个协议栈层(L1-L4)之间的接口层。这对应于WO 01/88707中的公开。采用接口或中间层的上下层所“知道”的接口格式在两个协议栈层之间实例化接口或中间层。接口层查询一表来确定它应当与哪个较高协议层接口，然后使用已知的(Java)接口。因此，在所示例子中，实例化升级协议层L2’，并且接口层I1从查询表确定它现在应当将来自层L1的分组定向到层L2’而非层L2。然后，层L2’将分组定向到接口层I2，其将这些分组重定向到协议栈层L3。这样，通过使用每个协议栈层(L1-L4)之间的这些接口层(I1-I3)和查询表，可以动态地重新配置协议栈。然而，仍然要求明确定义接口和协议层之间的链接(这些层全都在JVM中，或者并且使用Java语言的特性例如类装载、继承性、类创建和析构、以及方法标识和调用约定)以及必要时为了提供正确接口而执行的转换(包装器函数)。另外，由于接口层同步地支持相邻层之间的交互，因此它不支持用于存储分组的共享缓冲器布置，这可导致在不同层之间传递消息时过量的分组数据复制和存储器要求。另外，虽然该方案对于单语言协议栈是足够的，但是在使用不同语言的层的情况下，由于必须在语言特定格式和命名约定之间转换各种函数调用和格式化的数据，这是处理器和存储器密集的，因此该方法将变得笨重。
图4示出根据一个实施例的协议栈。该栈包括多个协议层(L1-L4)，其在它们之间传递诸如信号分组的协议消息(图7)。虽然从低层到高层示出了这些层，但是应当理解，相同的原理同样地应用于通过栈向下的信号传递。每个层接收绑定消息(图5)，并且包括绑定处理程序(handler)，其从绑定消息确定将输出定向到哪个其它层。
将输出定向到其的下一层由唯一标识符(绑定引用)表示。在层间传递消息的优选方法使用持久性消息队列，但是执行此的方式以及如何将执行从一层传递到另一层的方式的特定细节从如下面更详细描述的协议层软件中被抽象出来。
参照图5，绑定消息包括唯一LLI名称或标识符(instance.ref)，例如L2。在并行使用相同层的多个逻辑层实例(LLI)(例如，在处理不同呼叫的另一个栈实例中)的情况下，相比于软件层的其它实例，LLI名称唯一地标识那个层实例；例如L21和L22。下面更详细地描述层的多个实例化。
绑定消息还可包括语言特定函数表，其表示可以动态地封装到Java或C++“协议栈操作系统”类中或者包含在用来在层软件内访问它们的C结构和一组包装器函数中的操作系统应用编程人员接口(API)。该函数表包括预定一组基本操作系统函数例如新LLI实例创建(create_new_LLI)和LLI消息传递(send_message.receive_message)。所提供的表将取决于层(或者甚至是层的多个LLI之一)将在其上运行的执行环境。换句话说，函数本身是操作系统或虚拟机(例如，JVM)环境特定的，然而，由于它们在绑定时被传给层(实例)，因此这意味着层(实例)本身是操作系统和执行环境无关的，并且使用函数表以适当的方式与其栈中的其它层交互。
在可选布置中，绑定消息包含指向所需操作系统特定函数的指针(function.pointer)，其可被存储在例如共享存储器的表中。
在图6的图示中，由这些层使用的预定一般性函数(Func#1-Func#n)被映射到操作系统特定函数(op.sys.func1-op.sys.funcn)。一些典型的示例函数被示出，例如操作系统代表层执行的create_new_LLI。
这样，每层将包括一般性函数调用(Func#1-Func#n)，这些一般性函数调用允许其与其它层互操作，但由于在绑定的时候将操作系统特定函数传给它而不知道将在哪个操作系统环境中执行它。这也可从作为代码模块实现的软件层中将用来支持LLI之间的交互的特定类型的进程间通信(消息传递)和安全性机制抽象出来，唯一的要求是层的厂商必须使用适当的预定一般性函数调用-例如，启动新LLI的Func#1、发送消息到另一个LLI的Func#2、从另一个LLI接收消息的Func#3等等。类似地，由于两个LLI将被传递相同的特定操作系统函数，则它们将能够通过使用相同的消息传递函数来相互接口。
进一步地说，两个LLI可被传递不同的操作系统特定函数，从而使用如下面更详细描述的虚拟操作系统函数表在不同的执行环境中操作。这样，这些层是操作系统和语言无关的。在绑定/再绑定的时候向它们传递与栈的其余部分互操作所需的必要操作系统特定函数。
相同层的不同实例可通过在其绑定消息中被传递具有不同操作系统特定函数的不同函数表而在不同的环境中执行。因此，纯粹地通过在每个LLI中使不同类型的操作系统特定函数映射到一般性send_message和receive_message函数，单个代码片断(模块)可以不同地与其它代码位(模块)交互。这是因为逐LLI地执行用来将一般性send_message函数映射到对应的操作系统特定函数的表。然而，为了使LLI成功地与另一个LLI通信，则这两个LLI需要使用相同的从一般性send_message和receive_message函数到操作系统函数的映射，否则，当LLI执行send_message时，接收LLI将根本接收不到任何东西。
绑定消息还可包含层实例配置信息(config_1到config_n)，以将层的实例适当地配置成层的该逻辑实例，从而例如启用或禁用不同的可选协议特性。
通过使用该一般性和非层特定绑定机制，每个逻辑层实例可以通过将另一个绑定消息发送到该实例而动态地(在运行时)被定向到新的逻辑层实例以与之交互。可以看到，这可包括新层的动态插入，并且附加地允许语言无关的层间交互。
参照图7，在层之间传递协议消息以沿着协议栈上下传送信号或分组信息。每个协议消息将根据与发送层相关联并在其绑定消息中提供给该发送层(参见图5)的bind.ref标识符从发送层(例如，层1)被定向到目的层(例如，层2)。协议消息还将包括信号数据或者指向共享存储器中的信号数据的信号指针。同样地，信号数据(或指针)和标识符(send.inst.ref和dest.inst.ref)采用公共一般性共享数据格式。
协议和绑定消息是在协议栈实体(各个LLI)之间传递的消息，并且该信号传递可使用不同的机制例如函数调用或线程消息传递机制来执行。通常，线程消息传递在不同的操作系统线程之间，并且消息被置于队列中，然后操作系统唤醒(调度)接收线程来从队列读取消息。
一般性函数(如send_message和receive_message)用来允许采用适于目标平台的任何方法进行消息传递以便进行特定的交互。代码本身不需要知道使用什么方法。然而，调用send_message函数要求正被发送的消息采用一般性格式并且以预定方式被传递到send_message函数。消息可通过使用一般性create_message函数(也在操作系统特定函数表内提供)来动态创建和标识，该一般性create_message函数生成可在send_message函数内使用的消息句柄(或引用)。将消息传递到send_message函数的优选方法是通过引用传递它(在函数调用中传递指向消息的指针)。这最小化了否则由于将消息数据从堆(或共享)存储器复制到栈存储器中然后复制回到堆或共享存储器而必须发生的数据复制量。该优选方案是高效的，并且不涉及消息数据的过量复制。实际上，如果消息数据总是保存在堆或共享存储器中，则根本不需要复制。
因此，由于层软件(模块)只需知道可用于其的send_message和create_message函数的调用约定，因此层软件(模块)不要求在该层软件(模块)向其发送消息的软件层(模块)内使用的什么语言或者甚至是调用约定的任何知识。同样地，接收软件层(模块)仅需要知道receive_message函数。然后，必须与语言特定的访问函数一起访问实际的消息内容并且使用公共一般性共享数据存储方法来访问该数据。以相同的方式，绑定消息或协议消息(分组)可以以一般性方式被每层访问，而不管编程语言和执行环境。
用来访问数据的函数可以作为绑定消息内的操作系统特定函数的一部分被传给软件层(代码模块)。为了使得能够用不同的编程语言高效地访问消息(或信号)、配置和共享数据并且还允许升级，则该格式必须是可扩展的。例如，可扩展标记语言(XML)或其它(例如抽象语法表示法ASN.1)模板定义可用来定义数据格式以及通过使用标识数据元素的唯一标识符及其对应数据类型来在运行时访问共享数据存储结构。然后，语言特定数据访问函数可以高效地检索所需元素。这允许相同的数据被协议软件的不同版本使用。较旧版本将无需访问新数据成员，并且将不试图访问它们。在较新软件版本中，去除过时数据成员的知识也是可能的，但是数据模板定义将仍然具有过时数据成员的占位符以支持较旧软件模块版本。唯一标识数据成员(包括所有过时数据成员)的标识符在软件模块内用来访问这些数据成员。然而，由于由语言特定的数据访问函数提供的间接性，因此实际的数据全都可被存储在公共共享存储器区域中，并且采取适当的安全性措施(例如，使用读和写锁定机制的数据类型或元素级授权)以防止单独LLI非授权地访问数据。
这些函数可被封装在更复杂的接口定义语言(IDL)方案内，以允许利用现有或新的组件技术的特性。语言特定IDL定义还可允许利用不能容易地在不同语言之间映射的复杂数据类型(例如，用于Java层的一组Java类和组件接口与用于C++层的一组C++接口类等)。向和从XML或ASN.1模板映射特定IDL将需要由该附加组件接口软件处理。为了提高对使用公共存储结构的大量共享数据的访问速度，这些标识符可以分层地被安排在链接表中，或者顺序地被安排在数据数组内，以最小化定位期望元素所需的查询时间。
编程语言无关数据模板定义的例子分别是可扩展标记语言(XML)大纲或抽象语法表示法(ASN)标记或数据序列定义。数据元素(或属性)访问函数可利用间接机制(存储器指针)来访问数据元素序列内的实际元素，以提高访问性能，如下表所示。以这种方式，数据元素的解析变成查询操作和将结果强制转换或转换成如在模板中定义的所需数据格式。

其中示例ASN-1定义为Message∷＝SEQUENCE(Message_Number INTEGER OPTINAL，Message_Name STRING}用来访问消息数据的一般性函数还可包含在与绑定消息一起传递的一般性操作系统函数表内，以允许针对平台优化数据访问函数的实际实现。例如，对于具有唯一标识符“1243”的数据元素，软件层调用一般性层函数get_attribute(“1243”)。层软件需要知道采用XML或ASN.1模板格式定义的元素的数据类型。与由层软件使用的配置数据和消息对应的模板需要被一般性get_attribute和set_attribute函数知道，以便适当时允许类型转换。因此，get_attribute和set_attribute函数以模板定义的句柄(引用)作为参数。该句柄(或引用)由一般性load_template函数生成。一般性函数get_attribute和set_attribute还将获得配置数据或消息句柄(或引用)，并且保存查询表以便能够存储特定数据元素的存储器指针引用，并且记录其唯一标识符引用。
另一个选项是具有指向相同的实际数据元素的两个属性标识符。当不同的标识符实际上对应于相同的数据元素但是具有不同的转换类型时，这对于避免数据重复可能是有吸引力的。例如，如果数据元素标识符“1243”对应于在模板内被指定为“消息名称”并且是以空符号(null)结尾的Unicode字符串的数据元素。属性标识符“1244”可能也对应于相同的“消息名称”但是不同的格式，例如255字节ASCII字符串。类型转换可通过get_attribute函数隐藏于软件层。因此，如果Java软件模块调用get_attribute，则它将使用标识符“1243”并且获得Unicode字符串，而如果C++模板想要访问该数据元素，则它可对“1244”元素调用get_attribute，并且获得255字节ASCII字符串。
在优选实施例中，相同的模板用于所有消息数据，而不管发送和接收消息的LLI。这提供了对LLI的所谓的一般性服务访问点，其与LLI内的协议功能性无关。下面示出了GSAP的可能示例一般性模板定义。
--枚举和类型定义GPI_PRIMITIVETYPE∷＝ENUMERATED{GPI_BIND(1)，GPI_REBIND(2)，GPI_SUSPEND(3)，GPI_RESUME(4)，GPI_UNBIND(5)，GPI_TERMINATE(6)，GPI_UPGRADE(7)，GPI_OPTIMISE(8)，GPI_OK(9)，GPI_ERR(10)}；--用于一般性MAC层
GPI_MACTYPE∷＝ENUMERATED{GPI_CSMACA(0)，GPI_CSMACD(1)，GPI_TPB(2)，GPI_TPR(3)，GPI_TDMA(4)}；GPI_CRCTYPE∷＝ENUMERATED{GPI_CRC32(0)，GPI_CRC16(1)，GPI_CRC24(2)}；GPI_ARQTYPE∷＝ENUMERATED{GPI_SAW(0)，GPI_GBN(1)，GPI_SEL(2)，GPI_NONE(3)}；GPI_HARQTYPE∷＝ENUMERATED{GPI_TYPE1(0)，GPI_TYPE2(1)，GPI_NONE(2)}；GPI_HARQCODETYPE∷＝ENUMERATED{GPI_GOLAY(0)，GPI_RS(1)，GPI_NONE(2)}；GPI_CRYPTOTYPE∷＝ENUMERATED{GPI_RSA(0)，GPI_DES(1)，GPI_3DES(2)，GPI_GEA3(3)，GPI_NONE(4)}；--用于绑定原语(primitive)GPI_QOSTYPE∷＝ENUMERATED{GPI_CO(0)，GPI_CL(1)}；--面向连接和无连接GPI_SECURITYLEVEL∷＝ENUMERATED{GPI_HIGH(0)，GPI_MEDIUM(1)，GPI_LOW(2)}；--用于一般性数据分组原语GPI_PACKETTYPE∷＝ENUMERATED{GPI_IP(0)，GPI_ETHER(1)，GPI_PPP(2)}；GPI_DIRECTION∷＝ENUMERATED{GPI_UP(0)，GPI_DOWN(1)}；GPI_TFTYPE∷＝SEQUENCE{--一般性传输格式类型定义GPI_MOD GPI_MODTYPE[调制类型]，GPI_CODING GPI_CODINGTYPE[信道编码类型]，
GPI_BLOCKSIZE INTEGER[以字节为单位的传输块大小]，GPI_ANTENNA INTEGER OPTIONAL[表示要使用哪个天线]}--原语定义GPI_MANPRIMITIVE∷＝SEQUENCE{--一般性GPI管理原语GPI_PRIMITIVE GPI_PRIMITIVETYPE[这是特定协议消息原语类型]，--协议模块无关部分GPI_REQUESTOR GPI_LL_IDENT[这是请求LLI]，--取决于原语类型的可选部分-绑定包含附加信息GPI_BIND GPI_BINDPRIMITIVE OPTIONAL[用于绑定、重新绑定、优化]}GPI_BINDPRIMITIVE∷＝SEQUENCE{GPI_UPPER_SAP STRING[这是LLI之上的服务访问点名称]，GPI_UPPER_USER GPI_LL_IDENT[这是使用SAP并对其接收和发送分组的LLI的唯一标识符]，GPI_LOWER_SAP STRING[这是LLI之下的服务访问点名称]，GPI_LOWER_USER GPI_LL_IDENT[这是使用SAP并对其接收和发送分组的LLI的唯一标识符]，GPI_GSAP GPI_GSAP_TABLE[这是为LLI设置环境以便允许语言无关性、性能优化和以安全方式跨越GSAP边界的交互的(虚拟)操作系统表]，--以一般性方式配置LLI的QoS属性GPI_QOS GPI_QOSTYPE[与LLI相关联的QoS]GPI_RCV_THROUGH_TARGET INTEGER[每秒k位的目标接收吞吐量]，GPI_RCV_THROUGH_ACCEPT INTEGER[每秒k位的可接受接收吞吐量]，GPI_RCV_TRANSDELAY_TARGET INTEGER[以毫秒为单位的目标接收延迟]，GPI_RCV_TRANSDELAY_ACCEPT INTEGER[以毫秒为单位的可接受接收延迟]，GPI_XMT_THROUGH_TARGET INTEGER[每秒k位的目标传送吞吐量]，GPI_XMT_THROUGH_ACCEPT INTEGER[每秒k位的可接受传送吞吐量]，GPI_XMT_TRANSDELAY_TARGET INTEGER[以毫秒为单位的目标传送延迟]，GPI_XMT_TRANSDELAY_ACCEPT INTEGER[以毫秒为单位的可接受传送延迟]，GPI_PRIORITY_MIN INTEGER(0..100)[业务类/连接的最小优先级]，GPI_PROTECTION_MIN[GPI_NONE，CPI_MONITOR，GPI_MAXIMUM]，GPI_PRIORITY_MAX INTEGER(0..100)[业务类/连接的最大优先级]GPI_PROTECTION_MAX INTEGER[GPI_NONE，CPI_MONITOR，GPI_MAXIMUM]，GPI_RESILIENCE_DISC_PROB INTEGER(0..10000)[断连的弹性]，GPI_RESILIENCE_RESET_PROB INTEGER(0..10000)[连接复位的弹性]，GPI_RESIDUAL_SUCCESS INTEGER(0..10000000)[与错误率成倒数的剩余成功率]，--可选成本和功耗、资源利用和安全性要求
GPI_RCV_COST_TARGET INTEGER OPTIONAL[以货币为单位的目标吞吐量的每分钟目标接收成本]，GPI_RCV_COST_ACCEPT INTEGER OPTIONAL[可接受的每分钟接收成本]，GPI_XML_COST_TARGET INTEGER OPTIONAL[以货币为单位的目标吞吐量的每分钟目标传送成本]，GPI_XML_COST_ACCEPT INTEGER OPTIONAL[可接受的每分钟传送成本]，GPI_POWER_CONSUMPTION_TARGET INTEGEROPTIONAL(0..100)[允许实现可接受的电池寿命的作为最大功耗％的目标最大功耗]，GPI_SECURITY GPI_SECURITYLEVEL OPTIONAL[所需安全级别]，GPI_MEMORY_TARGET INTEGER(0..100)OPTIONAL[目标最大内存使用％总量]，GPI_PROCESSOR_TARGET INTEGER(0..100)OPTIONAL[目标最大处理器使用％总量]，--LLI特定部分-在此使用的属性主要取决于LLI类型GPI_MAC GPI_MACTYPE OPTIONAL[这表示MAC的类型]，GPI_MAC_AIFS INTEGER OPTIONAL[以时隙为单位的仲裁帧间分隔]，GPI_MAC_SLOTTIME INTEGER OPTIONAL[以毫秒为单位的基于CSMA和TDMA的MAC的时隙]，GPI_MAC_FRAMESIZE INTEGER OPTIONAL[以时隙为单位的帧大小]，GPI_MAC_BACKOFFWINDOW INTEGER OPTIONAL[以时隙为单位的初始补偿(backoff)窗口大小]，GPI_HEADER_CRC GPI_CRCTYPE OPTIONAL[用于一般性首标CRC的设置]，
GPI_PAYLOAD_CRC GPI_CRCTYPE OPTIONAL[用于一般性有效荷载CRC的设置]，GPI_HEADER_CRC_GEN INTEGER OPTIONAL[用于首标CRC的生成多项式]，GPI_PAYLOAD_CRC_GEN INTEGER OPTIONAL[用于有效载荷CRC的生成多项式]，GPI_ARQ GPI_ARQ_TYPE OPTIONAL[用于ARQ的设置]，GPI_ARQ_BLOCKSIZE INTEGER OPTIONAL[以字节为单位的重新传送块的大小]，GPI_ARQ_WINDOWSIZE INTEGER OPTIONAL[用于GBN和选择(Selective)的重新传送窗口尺寸]，GPI_HARQ GPI_HARQTYPE OPTIONAL[用于混合ARQ的设置]，GPI_HARQ_CODE GPI_HARQCODETYPE OPTIONAL[用于混合ARQ编码的设置]，--加密/解密设置-用于一般性加密LLIGPI_CRYPTO GPI_CRYPTOTYPE OPTIONAL[用于加密/解密的设置]，GPI_CRYPTO_IV GPI_IV OPTIONAL[用于密码术的初始化向量]，GPI_CRYPTO_KEY GPI_KEY OPTIONAL[用于加密/解密的会话密钥]}GPI_PACKET∷＝SEQUENCE{--一般性数据分组(或帧)的定义--强制性分组信息GPI_PACKET GPI_PACKETTYPE[这是分组类型]，GPI_PACKET_HEADER_PTR GPI_PACKET_HEADER[采用协议特定格式的实际分组首标]，
GPI_PACKET_PAYLOAD_PTR GPI_PACKET_PAYLOAD[采用协议特定格式的实际分组有效荷载]，GPI_PACKET_HEADER_LEN INTEGER[以字节为单位的首标长度]，GPI_PACKET_PAYLOAD_LEN INTEGER[以字节为单位的有效荷载长度]，--可选分组信息GPI_TRCH GPI_TRCH_IDENT OPTIONAL[传输信道标识符]，GPI_TF GPI_TFTYPE OPTIONAL[传输格式]，GPI_DEST_MAC GPI_MAC_ADDRESS OPTIONAL[目的MAC地址]，GPI_SRC_MAC GPI_MAC_ADDRESS OPTIONAL[源MAC地址]，GPI_DEST_IP GPI_IP_ADDRESS OPTIONAL[目的IP地址]，GPI_SRC_IP GPI_IP_ADDRESS OPTIONAL[源IP地址]，GPI_DEST_PORT INTEGER OPTIONAL[目的端口号]，GPI_SRC_PORT INTEGER OPTIONAL[源端口号]，GPI_SN INTEGER OPTIONAL[序号]，GPI_IP_HEADER_CHKSUM GPI_IP_HEADER_CHECK_SUMOPTIONAL[IP校验和]，GPI_TRAFFICCLASS INTEGER OPTIONAL[用于业务类型的标识符]，GPI_PACKETDIRECTION GPI_DIRECTION OPTIONAL[协议栈中的分组方向]}层中的一般性函数与由LLI在其执行环境中调用的操作系统特定函数之间的映射可以以多种方式执行。参照图8，每个软件层(例如，L2)包括多个预定一般性函数。假定L2层的厂商使用预定的一般性函数，则该层将与协议栈内的其它层互操作。支持协议栈的层的执行环境与操作系统表(OS1)或其它对象相关联，这有效地将与层相关联的一般性函数映射到在该特定执行环境中将执行这些一般性函数的操作系统特定函数。在所示例子中，L2中的一般性函数1例如receive_message被转换成用于基于UNIX POSIX的执行环境的等效函数。操作系统表(OS)或映射对象可由例如协议栈的操作者或者诸如执行环境提供者的某其它实体提供。
图9示出一种可选布置，其中软件层L2包括特定于该层的函数，这些函数然后可由操作系统表(OS2)或其它映射对象从其L2格式直接映射到本地操作系统格式。因此，例如，L2函数1(同样地对应于send_message)由操作系统表OS2映射成用于receive_message函数的一个或多个基于本地UNIX POSIX的执行环境函数。在该特定布置中，很有可能L2软件层的厂商还将为UNIX操作系统环境提供对应的操作系统表OS2或映射对象。L2厂商可以能够为不同类型的操作系统提供多个操作系统表，以便解释厂商提供的L2软件层。
图10示意性地示出虚拟操作系统(VOS)的使用，在所示例子中，其可用来将一般性函数调用指向适当的操作系统-UNIX(OS1)或MicrosoftWindows(RTM)(OS2)。因此，例如，在使用多于一个操作系统或执行环境选项来例如驱动诸如基站或终端的装置或设备上的通常协议层的情况下，VOS可将例如来自软件层L2的一般性函数定向到UNIX或Microsoft Windows(RTM)操作系统表(分别地，OS1或OS2)或映射对象。在不同操作环境中执行相同软件层的两个实例的情况下，VOS可将相同的一般性函数(例如，一般性函数1)对于第一LLI映射到比方说UNIX操作系统表(OS1)，而对于第二LLI映射到MicrosoftWindows(RTM)操作系统表(OS3)，其中相同的一般性函数分别对应于op.sys函数x和op.sys.function.a。由于软件层L2使用一般性函数，因此L2的厂商只需提供实际的层软件(模块)，而无需卷入VOS或操作系统表软件。下面更详细地描述VOS的操作。
现在参照图11，厂商提供的L2软件层包括层特定函数，其然后由也可由L2厂商提供的虚拟操作系统(VOS)映射，其中虚拟操作系统(VOS)可同样地使用也可由L2厂商提供的操作系统特定表(OS2、OS4、OS5)或映射对象在不同的操作系统之间映射L2特定函数，以便将L2特定函数映射到相应的操作系统函数例如UNIX和MicrosoftWindows(RTM)。因此，可实现各个实施例来实现协议层软件的语言和/或操作系统无关性。
图11还示出例如各自对应于不同LLI的两个线程如何可被映射到不同的操作系统表以便在不同的执行环境中执行。线程1被指向VOS表中的特定条目，或者由L2特定函数(L2函数1)映射，并且又被指向与可在UNIX环境中执行的函数(op.sys.function.x)对应的UNIX操作系统表OS2中的特定条目。然后，线程1返回到层L2模块中的下一个函数指针(L2函数2)。在不同实施例中，线程1可能由VOS指向Window的操作系统表OS4，以便在Window环境中执行与层L2模块中的L2特定函数指针(L2函数1)对应的Windows特定函数(op.sys.function.a)。
线程2可对应于在不同Linux执行环境中执行的相同层L2的不同LLI。在该场景中，L2特定函数指针(例如，L2函数3)被映射到所执行的Linux特定函数(op.sys.function.m)，然后线程2返回到层L2模块中的其下一个函数指针(L2函数4)。
图12示出多个协议栈中的层的多个实例化。UMTS视频呼叫和两个WLAN因特网浏览协议栈被示出为同时是活动的。因特网栈之一支持不受限制的因特网浏览，同时另一个支持浏览内联网，并且同样地必须支持加密(例如，基于虚拟专用网络化VPN协议)。这两个浏览器栈各自具有耦接到WLAN的四个协议层实例(分别地，L41-L11，以及L42-L12)，然而层2实例(L21和L22)各自不同地被配置。这由因特网栈中的L22(sec)和因特网栈中的L21(non-sec)示出，其中L22表示支持加密的层2的第二实例，而L21表示不支持加密的层2的第一实例。这些配置将由发送到该层的每个实例(L21和L22)的原始绑定消息确定。层1、3和4对于这两个浏览器栈是相同的，并且包含单独(分别地，L11、L31、L41、以及L12、L32、L42)但相同配置的各层实例。
用来执行安全栈层实例的执行环境可被配置成防止从不安全实例访问消息或配置数据的任何可能性。例如，这可通过使用执行所有存储器访问和消息传递操作的授权以使它们与安全的栈实例隔离的操作系统函数表来实现。send_message函数的底层实现例如由VOS和/或操作系统映射对象供应者想要该函数做什么来确定。因此，如果例如软件层是不可信的，则在send_message和receive_message函数中执行的函数将显著地更加具有安全意识(security conscious)。这可包括例如耦接到基本检索数据函数的授权函数。在另外的例子中，create_LLI函数创建具有其自己的存储器区域的单独进程，以确保不存在层可访问由可信软件模块使用的存储器的可能性。如果认为操作系统本身不足够可信，则它甚至可在单独的操作系统环境中执行。
每层还可通过不同的性能优化来实现，例如向执行处理密集加密操作的栈实例给予优先级。
层2的第二LLI(L22)使用与第一LLI(L21)相同的代码模块(层2)，但是它是新的逻辑实体(在本例中，操作系统执行线程或进程)而非装载到工作存储器中的代码模块的另一副本。例如，第二LLI(L22)可以是该代码模块内的第二执行线程，其由操作系统控制，并且具有其自己的唯一标识符和与其相关联的配置。该配置信息仅可被逻辑层的该LLI(例如，线程)和设置每个实例的配置的控制实体(在下面更详细描述的CM)访问。LLI之间的交互也由CM配置，并且可防止无需交互的LLI交互(通过执行环境配置措施)。
此外，虽然层2的两个LLI(L21和L22)支持公共功能性，但是可以不同地配置它们。在本例中，L22支持加密/解密，而L21不支持。这些配置设置由绑定消息设置，并且可被存储在与每个实例(LLI)相关联的工作存储器内的栈或表中的适当位置。
层2软件的第二LLI将具有不同的LLI标识符[instance.ref]以及将其链接到不同输出层的不同绑定引用[bind.ref]。由[function.ref]标识的操作系统函数表(或操作系统类)可以是由层2的第一LLI使用的相同操作系统表，除非它在不同的操作环境中执行，在这种情况下，它将需要不同的操作系统表来将一般性函数映射到在其相应的执行环境内执行这些函数所需的操作系统特定函数。第二LLI还可具有其自己的执行栈(L22栈)和堆存储器。每个LLI将具有相同的可用配置选项，但是可以不同地启用/禁用这些配置选项。这些配置选项可作为参数而存储在其相应的LLI配置中。
每层将利用预定的一般性函数调用，其将包括线程管理以及存储器管理函数。然后，将这些函数调用在运行时映射到目标设备上的操作系统特定函数集上。由多于一个LLI访问的数据(例如，操作系统函数表和信号分组)以预定的格式被提供，这使得每个LLI能够使用预定函数调用集访问该信息。
绑定信号[bind.para]可由LLI随时接收，包括原始绑定信号之后，因此允许改变LLI的配置选项，另外允许通过改变bind.ref参数来将LLI绑定到另一个LLI，由此允许协议栈的动态重新绑定。
协议层的LLI可通过实例化操作系统线程来生成，其中操作系统线程具有其自己的执行堆栈，以提供一定程度的控制和与其它执行线程的隔离(例如，能够终止和提供基于优先级的不同线程之间的多任务化)。可选地，不同的LLI可作为不同的操作系统进程而实例化，以通过向每个进程提供其自己的存储堆并且防止被其它LLI访问来提供更大程度的隔离和控制。然而，这导致了执行基于优先级的多任务化(即相对于线程，进程之间的上下文切换)中的增大开销的惩罚。最后，LLI可以在相同的操作系统线程内被实例化。这具有设置和控制LLI的开销最小的益处，但是没有单独的堆栈或堆，因此如果依赖于操作系统安全性措施的话，则对数据(例如，LLI配置)的访问和对其执行的控制(例如，确定优先级等)可能严重地取决于父线程。在后一情况下，如果由LLI使用的编程语言和执行环境与其父线程相同，这是优选的，但是这不是强制性的。
除了上述操作系统执行环境之外，还有可能在诸如FPGA或DSP的外部可编程装置中实例化LLI。这些执行环境大大不同于相同操作系统的控制之下单个(或多个)处理器布置内的环境。然而，虚拟操作系统函数表(VOS)可允许从在不同装置上实现LLI的软件模块中将装置间通信复杂性抽象出来。
以上面方式，可以使用不同的执行线程或进程在不同的执行环境中创建多个逻辑层实例。除此之外，可采用不同的协议特性(配置选项)配置每个LLI，但是每个LLI可使用公共数据访问机制访问信号消息数据和其它共享数据。当如上所述在相同线程内创建多于一个LLI时，出现一种特殊的情况。
如上所述，有可能在不同的执行环境中执行(相同或不同)协议栈层的不同LLI，以提供不同级别的安全性以及性能。例如，蓝牙栈可以支持安全、高速的连接以及不安全、低速的连接。处理安全、高速连接的LLI的执行环境可以针对安全性和性能来优化，并且支持低速连接的LLI可以在较不安全且较不优化的执行环境中被支持。
该方案限制了LLI之间的交互，并且必要时(采用适当的安全性措施)针对每个LLI使用不同的执行环境适当地隔离它们。这样，高度可信的软件可被允许更多的自由度，并且可以在更优化的执行环境中执行而不执行严格的运行时安全性检查或者没有功能性限制，而使用较不可信的软件的LLI在更安全的环境中执行，其中对与其它LLI的容许交互具有更多的限制。这些措施还将不仅取决于软件内的信任级别，而且取决于与由LLI支持的服务的类型相关联的完整性和其它安全性要求(例如，隐私性和保密性)。
图13示出了用于例如在蜂窝电话中实例化层和将一个软件层绑定到另一个软件层的设置和升级场景。电话存储或下载直接地(本地地)或者使用虚拟机环境机制(例如，Java类装载原理)和所标识的入口点装载到工作存储器中的多个软件代码模块。在所示例子中，这包括层1-3和配置管理器(CM)，其中配置管理器(CM)通过将对应于软件层的代码模块装载到工作存储器中，调用入口点，并且发送适当的绑定消息以配置和重新配置各层来控制协议栈的布置。例如，发送到层1的绑定消息指示它“绑定”到第二层。
在以层2’替换层2的升级场景中，层2’软件层文件或代码模块被装载到工作存储器(L2’)中，并且配置管理器(CM)调用到新层的层入口点。然后，它将绑定消息发布到层2’，以将其输出定向到层3，并且设置适当的协议选项。配置管理器还将绑定消息定向到层1，以将其输出从层2重定向到层2’。该升级重新配置在运行时期间发生，并且还只要求实现相对简单的绑定消息。它还允许继续处理通过(旧)层2(L2)的任何分组并且将其传递到层3(L3)以便关联的会话不被动态重新配置终止。这样，倘若新实例可访问旧实例的配置(包括状态)数据，则在栈的重新配置期间无需终止会话。
参照图14，例如，为了实例化层2的第一实例(L21)，配置管理器(CM)将层2代码模块装载到工作存储器(或虚拟机环境)的程序代码区域中。然后，配置管理器通过在本地软件模块的情况下直接调用工作存储器中的代码入口点(层入口点)或者在虚拟机环境中调用层入口点成员函数(运行方法)来启动LLI。
CM调用装载过程，从而对于Java，这意味着装载类文件，而对于本地层，则意味着以适于执行环境的方式将代码部分装载到存储器中。由于CM知道执行环境，因此它知道装载模块的方式，并且传递缺省的适当VOS和/或操作系统表(OS)。下面将更详细地描述其例子。在本地代码层中，这可能要求通过定位和执行入口点函数来调用入口点。入口点函数需要具有使得能够接收绑定消息的缺省行为。例如，在Java类中，这可调用将缺省VOS和/或操作系统特定类装载到JVM中以便能够然后调用receive_message函数。在本地层中，入口点可包含作为指向缺省VOS和/或操作系统特定(OS)表的指针的参数。一旦模块入口点被初始化(例如，它可涉及复制VOS或OS表并且分配一些工作或堆存储器)，则它调用VOS(操作系统函数表)中的receive_message函数，然后，它不做其它事情直到接收到绑定消息为止。
如上所述的初始化函数简单地是获得缺省VOS(或操作系统)表、必要时复制它(或者指向其在共享存储器中的位置)并且调用receive_message函数的引导方法。
receive_message函数位于VOS或操作系统表(OS)中，从而是VOS或OS确定如何发送消息(通过函数调用或者操作系统线程消息传递等)。绑定消息是特定消息类型(所有消息都具有唯一标识符以允许确定消息类型)。因此，当等待绑定消息时忽略其它消息(将正常地迫使干净退出的终止消息除外)。
绑定处理程序简单地调用同样地是VOS或OS函数的create_new_LLI，其中create_new_LLI可调用新线程或进程实例或者实际上可以不这样做而是仅修改LLI表。然而，来自绑定消息的配置信息被传给create_new_LLI函数，以便允许为该LLI设置配置。这包括对要由LLI使用的特定VOS和/或OS表的引用。例如，如果层需要将协议消息传给不同执行环境中的层，这可不同于由初始化函数复制或使用的VOS和/或OS表。新线程调用特定VOS(或操作系统表)内的receive_message函数，以等待消息以便对其进行处理。
如上所述，绑定消息包含交互或接口信息以便将层的输出定向到下一层。绑定消息还可包括必要的函数调用来做此(函数表)。例如，函数或函数指针的初始化模板可被传给模块入口点，同时例如根据为关联的LLI选择的配置选项和/或其执行环境，处理函数的更特定模板可通过绑定消息被传给该模块。然后，CM可指示执行环境特定安全性机制允许从新LLI到容许的其它LLI的交互，并且可以可选地设置对共享配置数据的访问控制机制，以允许仅访问新LLI所容许的配置数据的各部分。
绑定消息重新配置选项可通过使用针对安全性、性能和功耗的一般性配置首选项来确定在层内要启用的特性，例如是否启用加密。在多个协议栈实例同时正在使用的情况下，每层可能存在多个LLI，并且它们采用唯一实例标识符(instance.ref)标识。相同层的不同LLI可具有不同的配置，例如，一些支持加密，而一些不支持。
以一般性方式支持入口点调用和参数传递，而不管特定的实现细节。优选地，ANSI标准C(否则称作Cdec1)约定用来将本地软件模块的参数，例如(function.pointer)或(start.pointer)传给提供执行环境相关函数如线程创建和消息传递相关函数(包括配置数据访问函数)的入口点。然而，对于Java层，软件层的Java类扩展Thread Java类，并且当将层装载到JVM中时自动调用运行方法。如果调用本地层入口点以实例化新线程，则在新执行线程中创建新实例，并且入口点返回。
可选地，(特别是当层在虚拟机环境中执行，但不限于仅仅这些层)，可以在伴随层软件模块的清单(元)信息文件中表示入口点类(或位置)。当处理绑定消息时，使用create_new_LLI创建新实例线程，并且现在它使用receive_message函数等待协议消息。
每个层实例配置数据将包含关于下一层实例的信息，以便发送分组或协议消息如[signal.pointer]。这样，当层需要发送分组(包含在协议消息内)到下一层时，使用绑定引用(bind.ref)的get_attribute函数从LLI配置数据获得要向其发送消息的下一个层实例。
当实例化相同层的多个LLI时，绑定处理程序将为新的层实例(在L22栈中)形成配置数据的新实例。如前所述的配置数据将包含该实例的唯一标识符，并且一旦创建了新的线程实例，则将确认返回给CM，然后CM可设置适当的执行环境安全性措施。绑定消息可由CM直接发送到LLI以改变实例的配置。
如上所述，进入绑定消息包括实例号[instance.ref]。绑定引用[bind.ref]标识输出协议消息应当被定向到其的本LLI之上的层的LLI。函数指针[function.pointers]标识适于特定LLI的操作系统函数表(OS以及可能的VOS)，使得当层调用预定数目的函数之一(例如，“create_new_LLI”)时，函数指针指向适当的位置和存储器，其包含针对LLI正在其中操作的特定执行环境或操作系统而正确格式化的该函数的函数调用。换句话说，操作系统函数表将LLI内的“一般性”函数调用映射到由操作系统使用的语言和操作系统相关函数，以执行这些函数。函数表将典型地包括存储器访问和管理函数，其包括访问在层之间传递的信号分组或其它消息。这样，例如，层1可使用操作系统函数send_message将信号分组(用于signal_packet_2)指针[signal.pointer]传递到层2内的LLI。这允许层2LLI访问该特定信号分组，并且使用由操作系统函数表提供的函数并且利用其自己的LLI执行堆栈(L21堆栈)、根据其内部协议函数进一步处理它。
如上所述，公共平台无关虚拟操作系统(VOS)函数表可用来提供对执行环境函数和LLI配置信息的访问。这改善了执行环境(操作系统和虚拟机)无关性，并且在图15中示出。图中示出了五层(L1-L4)，其包括“旧”层3(L3)以及升级的层3(L3’)。这些层中的两层(L3’和L4)被示出为在Java虚拟机(JVM)内操作。JVM要求解释器或虚拟机环境实时地解释对应于这些层的软件模块代码，并且还提供用于与非Java软件接口的本地接口(NI)。其它层(L1-L3)被预编译成目标代码，并且在运行时由操作系统本地执行。
它还允许如图所示提供多个执行环境，其中操作系统1和操作系统2各自执行不同的层，但是这些层仍然可以相互通信。
这些层中的一般性函数调用使用操作系统函数表(OS)被转换成实际的操作系统特定函数。在VOS的情况下，需要进一步的转换或映射。到每个LLI的绑定消息提供指向VOS函数表的函数指针，其中VOS函数表本身指向OS中的操作系统特定函数以使得能够执行这些层。由于VOS函数表可以被重新指向不同的操作系统特定函数，这提供了操作系统无关性。例如，CM可以(通过绑定消息)指示LLI在运行时动态地将与由LLI使用的一般性函数对应的操作系统特定函数的其VOS表从比方说基于UNIX的POSIX函数(OSx)改变成基于UNIX的system V操作系统函数(OSy)。然而，由于特定的操作特定函数包含或改变系统状态相关信息(特别是信号灯和其它系统资源处理函数如存储器分配)，因此动态改变确实需要关心(need care)，从而VOS概念可允许必要时通过在这些间接机制内提供智能和操作系统抽象而无缝地在OS环境之间切换的能力。它还允许以有可能支持不同执行环境的最一般性方式编写软件代码模块。
在协议软件中，不经常执行字符串操纵，然而，可包括诸如“calculate_crc”或“convert_ip_address_2_string”的任何频繁操作作为操作系统表(OS)或VOS表中具有对应操作特定函数的一般性函数。在可选布置中，可以在可被配置成执行不同的加密和解密操作的一般性加密/解密层中实现诸如加密和解密的特定信号数据操纵函数。这是包含大部分数学函数并且可使用(必要时)具有数学扩展的VOS或操作系统表(OS)的层，因为它可以在具有用于这些复杂数学函数的性能加速器的执行环境(如协处理器)中操作。然后，其它或一般协议层将使用不带这些扩展的通用VOS或操作系统表(OS)。
图16和17示出了以执行环境和语言无关的方式将函数指针传给模块的方法。具体地，这示出了本地代码例子如C，图16示出了公知的动态链接方法，而图17示出了根据一个实施例的传递函数表指针的方法。
参照图16，软件模块的厂商开发了源代码程序(在本例中，采用C编程语言)，其包括一系列API函数(x和y)和变量以便与存储在目标平台(硬件、函数库集、以及诸如输入/输出的操作系统函数)的存储器中的数据交互，以及有可能地包括在该平台上运行的其它API库模块。源代码通过公知的编译器被编译成目标代码，而公知的编译器将函数系列翻译成特定于目标平台的二进制机器(或目标)代码。二进制代码包括一系列占位符或符号(符号X和符号Y)，其各自对应于API库模块中的函数系列(x和y)之一。
当目标代码被装载到目标平台上的存储器中以便执行时，动态链接器检查代码，并以与库源代码中的函数(分别是x和y)对应的先前装载的API库模块中的API库函数(mem.loc(X)和mem.loc(Y))的存储器位置替换符号系列(符号X和符号Y)。如果尚未装载库模块，则可以通过动态链接器(在基于Java的实现中为类装载器)动态地装载它。然后，平台可根据软件模块的要求通过使程序计数器经历(step through)包含程序指令的存储器位置系列并且跳转(转移)至与API库函数调用(mem.loc(x)、mem.loc(y))对应的存储器位置来执行代码。
参照图17，要装载在目标上的软件模块的厂商(C编程人员)开发了包括与在图16的方案中使用实际的API函数调用(函数x和函数y)的位置对应的一系列API函数调用(redirect.f(x)和redirect.f(y))的源代码程序。重定向函数简单地将函数调用重定向到指定VOS或OS函数指针表内特定条目的存储器位置(保存在堆或共享存储器中的数组内的某位置-在编译的时候是未知的)。C源代码由编译器编译成同样地包括二进制机器代码的目标代码，然而，不存在与源代码中的函数对应的符号(X和Y)。相反，重定向函数简单地被编译成到保存在存储器驻留函数表内的条目(每个条目对应于一个API函数)中的存储器位置的跳转(或转移)指令，其中存储器驻留函数表在运行时被装载在目标平台上。
以这种方式，多个执行线程可使用不同的API实现代码来运行软件模块代码，而无需动态地重新链接软件模块。
编译器将重定向函数翻译成在运行时相对于OS或VOS表的开头的相对存储器指针，因此指向由目标代码表示的适当的执行环境特定函数。在这种情况下，源代码需要使用重定向函数而非图16的API类型函数来编写。
在可选布置中，现有技术的源代码程序由改进的编译器翻译成相同的目标代码，从而编译器将C特定函数(例如，函数x)翻译成重定向函数调用redirect.f(x)以允许使用(在运行时动态装载的)函数表。
当将该软件模块目标代码装载到存储器中时，向它传递对平台特定映射表的引用(例如，存储器中的起始地址)，其对应于堆或共享存储器中的一个位置。对于软件模块不包含入口点函数或要在表引用指针中传递的其它装置的情况，也有可能的是，函数指针的缺省表可被装载在关于目标代码的预定相对存储器位置。
然后，平台可以通过运行(running through)从redirect.f(x)编译的指令序列来执行该目标代码，其中redirect.f(x)将程序计数器重定向(跳转或转移)到平台上的实际OS或VOS库函数的存储器位置(mem.loc(x))位于其中的对应表条目(redirect.f(x))的存储器值。执行该函数，并且程序计数器返回到软件模块目标代码中发生跳转(或转移)的地方。
可以看出，在平台(操作系统、动态链接器或Java虚拟机)不需要具有特定语言和软件模块代码的语义以及它如何与其它模块交互的知识的意义上，这允许被编译成位置无关代码(即可从任何存储器位置执行的代码)的可装载软件模块是平台无关的。还可以看出，源代码可以与语言无关，这是因为编译后的目标代码包含相同的指向映射表的指针，而非动态装载器将需要解释且以平台特定函数的存储器位置替换的预定符号。例如，采用C、Visual Basic或Pascal编写的程序将各自被编译成相对函数指针的相同目标代码，其被传递执行环境特定函数所在的存储器内的起始点，相对指针表示从该起始点开始的对应函数的相对位置。这允许厂商提供可采用任何语言编写以及与平台无关的软件模块(目标代码)。
最后，执行软件模块代码的每个线程或进程可以通过不同的库函数表映射来做此，以允许相同的代码片断的行为在实现库函数的方式上完全不同。因此，一个执行线程(在存储器驻留二进制或字节码模块上)可调用实现轻量级库函数集的库函数，以针对性能进行优化，并且(相同存储器驻留代码的)另一个执行线程可使用重量级库函数实现，以例如针对安全性进行优化。
参照图18和19，针对基于Java语言的层程序，分别示出了动态链接(类装载器)和函数指针传递方法。本地和Java软件模块之间的主要区别在于采用Java引入了额外的间接层以跨越在Java和本地软件模块之间。Java软件模块具有分别对应于本地库函数Java_class_redirect.f(x)和Java_class_redirect.f(y)的Java本地接口方法redirect.m(x)和redirect.m(y)。Java本地接口方法由类装载器映射到本地函数。通常，当使用标准JVM类装载器时，必须使用System.LoadLibrary方法来装载本地库模块。然而，还有可能创建定制Java类装载器，其可使用其它方法来装载类和库。
然后，在本例中，类装载器将解析在Java本地接口类中使用的本地符号(mem.loc(redirect.f(x))和(mem.loc(redirect.f(y)))。然后，这些重定向函数将以与本地重定向函数相同的方式操作，并且使用映射表将该函数调用重定向到真实的函数mem.loc(x)和mem.loc(y)。
有可能定制Java类装载器，以消除装载本地接口库的这一中间步骤，因为这显然是以平台特定的方式执行的，并且要求每个平台具有对应的接口库集以使得能够访问实际的本地API库。
图20示出了协议栈实现的每消息一线程(thread per message)方案。在此方案中，线程与穿过协议栈的每个分组或信号相关联。在所示例子中，线程_信号1(thread_signal1)与协议消息信号1相关联，其中协议消息信号1由栈实例内的层1处理，然后继续到层2上，其中该消息由所示的各个函数或子模块(图14中的代码块或模块的分组或协议消息处理部分)处理，并且执行继续到层3，其中进一步处理该消息。类似地，线程_信号2(thread_signal2)与协议消息信号2相关联，其中协议消息信号2通过层1至层2，在层2，在所示的特定时间点，它到达了层2的“校验和”子函数。该方案类似于现有提出的框架，然而，它具有这样的缺点，即由大多数多任务操作系统提供的具有不同安全性和性能配置的不同执行环境不能容易地用于区分不同的LLI，而是需要实现定制的调度器，其基于LLI必要时优先于线程。
累积函数以虚框示出，并且为了便于说明起见在上面未被描述。在每消息一线程的方案中实现累积函数的情况下，存在两种实现可能性。一种是简单地终止线程，然而这依赖于另一个线程监视缓冲器以便提供(serve)经过缓冲的分组。另一种是返回到调用函数，然后可以使用执行线程来处理另一个消息。与终止线程相比，这更有吸引力，因为除非实现非常轻量级的线程模型，否则操作系统上的线程创建延迟和开销可能非常高。
这在图21中示意性地示出，其中两个代码块2被示出为与通过这些代码块的各个执行线程相关联的执行堆栈以及堆和其它共享存储器对象一起位于工作存储器中。各个执行堆栈将存储各种参数例如微处理器寄存器的当前状态、函数和代码模块内且用于函数调用参数传递的静态数据。调度器和线程管理器以公知的方式管理各个线程的操作，向微处理器寄存器装载当前或活动线程的各自堆栈的适当内容，并且将寄存器的内容存储在刚被切换(称作上下文切换)的线程的适当堆栈中。可以看出，例如，L2代码块中的线程_信号1的执行点(TS1)比线程_信号2(TS2)执行了更多的代码-其中(TS1)和(TS2)表示每个线程的程序计数器值，因此表示对于该线程接下来要执行代码模块中的哪个点。各个其它执行堆栈将与经过协议栈的各个代码块L1-L5的其它信号相关联。可以看出，每个线程与单个信号相关联，并且以同步的方式“跟随它”通过协议栈。
相反，另一实施例使用每LLI一线程，如图22所示。线程_层2_LLI#1(Thread_layer2_LLI#1)对应于层2层或代码模块内的一个线程，其从低层接收了信号或分组(协议消息)。线程通过该层的各个子函数处理它，并且将经过处理的输出(信号、分组或消息)传递到高层(例如，层3)。然后，它返回到其关联层2的接收消息或输入函数，以便准备处理下一个协议消息。类似地，线程_层2_LLI2与相同于第一线程的层(层2)中的单独分组或协议消息相关联，但是位于不同的实例或LLI中。在所示的时间点，该第二线程或执行点到达了层2的解密子函数。一旦每个线程通过其LLI处理了协议消息，则它返回到空闲状态，并且调用receive_message操作系统函数以等待来自低层的新分组。当执行LLI的执行环境驻留在单独的物理处理器上时，有可能使用所涉及的LLI的任一个的不同操作系统线程或进程(例如，thread_send_message(x))，由执行环境处理LLI之间的消息传递。receive_message函数简单地等待并检索预定消息队列中的消息。类似地，send_message函数将消息放置在预定的消息队列中。
该每LLI一线程的方案相比于前面方案的优点在于每个LLI都可被配置成适当地以不同的优先级(适当时)和不同的安全性措施在不同的执行环境中(必要时)操作，以防止任何行为恶劣的软件模块影响其它LLI的操作。
同样地，累积函数以虚线框示出以简化初始说明，然而，由于对协议栈的该方案在性质上内在地是异步的(即，具有消息的累积)，因而它对于使用异步消息传递是有吸引力的，从而以可被发送者和接收者访问的公共且持久的方式缓冲消息(分组)。如果在层代码内自然地执行累积(如同每消息一线程的方案中的情况)，则可将消息数据从发送者发送到累积缓冲器，然后再次将其从缓冲器复制至下一层。
具有持久性共享存储器队列允许将消息投递到队列中而无需任何数据复制。协议栈实现中的复制应当被最少化以获得良好的性能。因此，如果send_message函数简单地将指向消息的指针放置在接收者消息队列中，则根本上没有数据复制，并且接收者仍然可以以相同的方式访问数据。另一个优点是当以另一个LLI重新配置(替换)一个层实例LLI时，则该队列仍然存在，并且消息数据仍然存取，从而不丢失任何东西，并且处理可以如同没有发生任何事情一样地继续。
另一个优点是在升级或替换栈中的LLI的期间，由未被升级的LLI处理的协议消息(信号)不受影响。另外，如果必要的预执行切换可通过将发往旧实例的分组重定向到将由新实例使用的队列或者通过挂起旧实例(由此防止由旧版本进一步处理而不丢弃分组)来实现。例如，如果通过持久性共享存储器排队实现send_message和receive_message函数，然后可以通过CM在实例化新LLI之前将绑定消息发送到新LLI版本实例之下和之上的LLI实例来重新关联队列，这是可能的，因为分组将开始被排队，以便为新的LLI实例准备妥当。该方案是有吸引力的，因为新LLI的实例化可能是耗时的，并且如果例如切换是从不安全的LLI到安全的LLI，则以不安全的方式继续处理分组可能露出了系统的脆弱性。
图23示出了与每消息一线程的方案的图21类似的示意图，但是示出了与每实例一线程的方案对应的执行堆栈。例如，两个线程被示出为与层2代码模块相关联，然而与L2内的不同协议消息相对，各自与L2的不同实例(LLI)相关联。(TL21)、(TL22)和(TL11)示出了每个LLI线程的代码模块中的程序计数器值或位置。
图24和25示出了用于获得代码模块以便应用于实施例中的不同路线。在图24中，厂商开发了C++源代码程序，其由“源到指针”编译器编译，以便将源代码翻译成包括与函数模板中的一般性函数对应的一系列指针的一般性执行代码模块格式。这些指针采用如前所述的公共数据格式，并且是指向OS表或对象中的对应操作系统特定函数的相对存储器指针。例如，第一一般性函数(例如，作为create_new_LLI的Func#1)对应于OS中的第一操作系统特定函数。知道对应的OS在存储器中的何处之后，执行环境在执行模块时被指向适当格式化的OS中的执行环境特定函数。
在图25所示的可选布置中，厂商开发了相同的C++源代码程序，其然后由标准C++编译器编译成平台特定C++代码模块。然后，需要另外的编译器来将该模块转换成如上所述且适于与OS(并且在一些实施例为VOS)一起执行一般性函数指针代码模块。
图26示出使用上述一些实施例的示例实现。具有蓝牙能力的终端设备在本地语言软件层(软件层#1和#2)内运行标准蓝牙协议栈。蓝牙栈使用使得能够将平台操作系统和语言无关协议层动态地链接在一起的上述绑定功能性。所示出的两个协议栈实例(实例#1和实例#2)可被配置成提供不同的蓝牙服务。例如，LAN接入协议子集(profile)实例和IP上的语音或者蓝牙网络封装协议子集实例。然后，使用LAN接入协议子集来执行使用专用蓝牙接入点的万维网浏览，并且同时使用IP上的语音协议子集来通过相同的接入点进行电话呼叫。
然后，如图27所示，可通过使用所下载的Java层(层#3)添加对新协议子集的支持来定制蓝牙栈。该层提供了(例如)增强的安全性或性能或者新的服务功能性。根据所采用的实施例，Java层被动态地装载，并且新的层实例(LLI#1和LLI#2)被绑定到现有的本地语言蓝牙栈，而无需重新启动蓝牙栈。因此，现有的蓝牙连接会话不被破坏。然后，可使用新层来实例化增强的安全性协议子集，其用来对终端与接入点之间的数据进行加密和解密。
为了支持操作系统无关性，使用在模块内用来与协议栈内的其它模块交互所必需的平台特定函数的操作系统函数表(例如，允许共享存储器分配和线程消息传递等的函数)。绑定消息还将确定允许哪些其它模块与它交互，并且将存在执行环境机制来验证这些源的真实性。绑定消息必须还包含协议层所需的所有必要初始配置数据。
该蓝牙栈内的层使用不同的执行线程来实例化，并且每层分别利用VOS或OS receive_message和send_message作为协议消息入口和输出点，以允许VOS或OS实现适于LLI的所选执行环境的交互机制。线程或进程可由唯一的LLI名称标识，其中LLI名称包括唯一层名称(在本例中为“蓝牙栈层#3”)和层实例标识符(在本例中为“LLI#1”和“LLI#2”)。以这种方式，使用线程名称来唯一标识层实例。VOS和OS可采用操作系统特定机制以支持LLI之间的交互以及LLI线程和进程的调度，或者还可采用私有且高度优化的机制。这可按照安全性、性能或者甚至按照资源利用例如存储器和功耗来优化。
该方案使得能够采用不同的配置生成LLI。每个LLI在绑定过程期间以绑定信号配置，其中绑定信号不仅标识LLI将与其通信的其它LLI而且标识要用于特定实例的配置数据。
VOS支持的LLI消息队列可被保存在持久性共享存储器中，以使得能够在协议栈仍然活动的同时进行软件的动态升级。LLI的重新绑定也是可能的，从而允许将层插入到活动的协议栈中。
将新层(蓝牙栈层#3)配置到协议栈中的过程如下1.第一步骤是通过调用关联的模块入口点来启动“蓝牙栈层#3”的执行。在Java模块的情况下，类文件被装载到由CM选择的JVM环境中。如果尚未装载的话，该模块装载缺省的VOS或OS API。然后，由JVM自动调用运行方法，并且层软件(模块)调用load_template函数以便随后能够访问配置和消息数据，并且调用receive_message函数以等待绑定消息。
2.与必要的配置信息一起将绑定消息传递到“蓝牙栈层#3”线程。然后，线程通过调用VOS或OS create_new_LLI函数来创建新的LLI实例。在新LLI内，必要时装载LLI特定VOS和/或OS表。创建线程“蓝牙栈层#3实例#1”，并且回送OK响应。新的LLI执行一般性load_template函数(如果需要不同的模板)以允许访问消息和配置数据，然后调用receive_message以便等待下一个消息。
3.现在将与“蓝牙栈层#2实例#1”的重新绑定请求消息以及所有随后的原始目的地为“主机因特网栈”的分组发送到“蓝牙栈层#2LLI#1”，其中“蓝牙栈层#2实例#1”以OK消息响应以便确认重新绑定。
4.更新与“主机因特网栈”的重新绑定消息和路由选择表，并且接收OK响应。
5.LLI#1现在是活动的，并且对于层#3LLI#2重复相同的过程。
为了使Java蓝牙栈层#3可以容易地与本地语言蓝牙栈层#2和主机因特网栈互操作，使用上述用于交互以及线程和进程调度的公共VOS和/或OS支持机制。用于以平台无关的方式访问此公共功能性的方法通过可动态装载的VOS和/或OS函数库。
当在JVM环境内实例化“蓝牙栈层#3”时，进行装载缺省VOS和/或OS库的Java调用。VOS和/或OS库包含一组系统资源相关处理函数。这些函数最少包括·信号和存储器分配函数·线程创建(和析构)函数·消息发送和接收函数·配置和信号数据访问函数随后，使用VOS和/或OS函数库与其它LLI通信和访问配置数据(使用适当的所装载的模板)。一般性LLI和VOS函数可以在多个不同的操作系统上支持，并可从很多不同的语言和虚拟机环境访问。函数库还提供对消息队列、信号和配置数据的受控访问。例如，函数库可基于LLI标识符来限制对配置数据的访问，并且还控制对适当授权的源和目的地使用消息发送和接收。以这种方式，创建了安全的语言和操作系统无关协议栈执行环境。
以这种方式，例如可以以特定一组加密功能性设置创建例如“蓝牙栈层#3 LLI#1”。这些设置在“蓝牙栈层#3 LLI#2”中可以不同，并且在用于绑定过程的绑定消息中定义。因而，不可能让LLI#2访问LLI#1的参数，并且反之亦然，并且也不可能让LLI#1解释打算发往(intended for)LLI#2的分组，并且反之亦然。
然而，将全新层的功能性(如计算机可执行指令所定义)装载到协议栈中在某些情形下可能是困难的，这是因为它在其中定义协议栈的计算机中会消耗大量的存储器资源。
如果存储器是计算机中的稀有资源，则动态装载附加层是不良的，因为它需要为定义附加层的机器代码指令保留另外的存储器资源。这可导致计算机的较差性能或故障。
此外，在实践中，除了附加层功能性的特定部分之外，附加层实际上可能由与它打算替换的协议栈的层基本上相同的机器代码指令定义。因此，在使用时，包括附加层的协议栈的实例将需要存储与未通过附加层的引入而增强的被替换层的功能性有关的很多指令的两个副本，虽然在具有大量存储器资源的计算机中，这不是实际问题，但是找到在计算机中减小存储器消耗的方式总是期望的，因为这可使得能够与协议栈并行地运行另外的功能性。
传统地，协议栈中的层将被设计成存在于多个预定状态之一中。特定状态中的层将被配置成可用来接收和响应特定消息，将层变换到另一预定状态或者保持层状态不变的消息。
这些预定状态之间的层的有条件转变取决于由层接收到协议消息。通过允许与所利用的计算机编程语言无关地处理消息，即促进语言无关性，增强了使层具有灵活的行为的有效性。
为了使得能够进行有效且一致的层设计以及通过适合软件的设计的实现，设计者可以首先确定层的状态，以及描述响应于所接收的消息的层的期望行为的状态之间的转变。这样，层的每个状态由功能模块实现。
模块定义在其上实例化层的计算机的自包含功能性，捕获直接施加到其的消息，同时丢弃不直接施加到其的消息，以便由在该层处于另一状态时处理该层的行为的另一模块进行处理。
因此，在作为定义状态的多个功能模块的层的上下文中，并且响应于所接收的消息而进行状态之间的预定转变，有可能将另外的功能性引入到层中的期望引入只需改变状态定义模块之一。
在上面例子中，将有必要替换整个层，而不管与替换层有关的对应机器代码指令的相当大的部分是否相同于原始层的指令。这将首先不必要地消耗存储器，但是还将意味着无论通过什么手段将新机器代码装载到计算机中的行为都将涉及装载已经存在于计算机中的指令。
因此，理想的是，能够仅装载定义状态机内需要改变的状态的机器代码指令而非定义层的整个状态机。这将是有利的，因为在一方面，它将导致存储较不昂贵并且可采用有限的传输资源在传输链路上传输较少的机器代码指令来实现的解决方案。
应当理解，减小传送到计算机的数据量的设施代表了操作的改进。因此，进一步理想的是，向执行基于状态的分层协议栈的计算机提供一种设施，以使得能够通过引入层的替换功能性实现对层的改进，同时层的其它未变功能性保持由先前装载的机器代码指令实现。

发明内容
本发明的一方面是提供一种修改通信协议以便处理在具有处理器和存储器的处理设备中提供的信号的方法，该协议由多个协议层定义、正在使用中的至少一层能够占据多个预定状态之一，其中每个状态与其关联了包括到其它状态之一中的层的消息相关转变的预定功能性；该方法包括将软件更新模块装载到存储器中，该模块被安排成接收和处理与这些层之一的这些状态之一对应的一个或多个消息，该模块包括至少一个消息相关转变单元，其可用来导致将层转变到另一个状态中。
优选地，该模块可用来截取打算发往实现对应状态的预定功能性的消息，并且将与消息相关转变单元无关的消息传递到预定功能性。
在本发明的优选实施例中，更新模块可用来接收和处理消息，并且导致将层转变到另一个状态中，该消息不可用来在装载模块之前导致层中的转变。
更新模块可被安排成与其它模块交换对应于信号的协议消息，其它模块被安排成根据对应于其它层的一般性函数集来处理信号。
该方法还可包括将其它软件模块装载到存储器中，其它模块包括与函数映射对象中的一般性函数对应的一般性函数指针；对于将函数映射对象装载到存储器中的每个其它模块，该对象包括与一般性函数对应的设备特定函数指针，以便将一般性函数映射到一个或多个设备特定函数；根据所映射的设备特定函数执行其它模块，以便根据协议层处理所接收的信号。
优选地，该方法还包括这一或每个所装载的软件模块接收包括另一个模块的标识符的绑定消息，第一模块被安排成与由绑定消息标识的其它模块交换协议消息。
该模块可具有用于处理协议消息的不同配置选项。
绑定消息可包括用于确定在模块的执行中实现哪些配置选项的标识符。
协议消息、绑定消息和一般性函数指针可以采用公共一般性格式。
优选地，该方法还包括将第二软件模块装载到存储器中，第二模块被安排成根据与这些层中的第二层对应的一般性函数集接收并处理信号，第二模块包括与第二函数映射对象中的一般性函数对应的一般性函数指针，将第二函数映射对象装载到存储器中，该对象包括与这些一般性函数对应的第二设备特定函数指针，以便将一般性函数映射到一个或多个第二设备特定函数，并且根据所映射的第二设备特定函数执行第二模块，以便根据协议层处理所接收的信号；从而，在不同的执行或设备特定环境中执行第一和第二模块。
更新模块可以是语言无关的。
可提供高级软件语言代码，其用于根据对应于层的一般性函数集处理信号；并且将该代码编译成语言无关的软件模块。
本发明的第二方面包括一种用于控制处理设备以任何优选的形式执行本发明第一方面的方法的程序。
可提供一种存储介质，其承载这样的数据，其中当装载到可配置设备中时，该数据使得能够执行程序以使可配置设备以任何优选的形式执行本发明第一方面的方法。
可提供一种信号，其承载这样的数据，其中当装载到可配置设备中时，该数据使得能够执行程序以使可配置设备以任何优选的形式执行本发明第一方面的方法。
根据本发明的第三方面，提供了一种用于修改通信协议以便处理在具有处理器和存储器的处理设备中提供的信号的设备，该协议由多个协议层定义、正在使用中的至少一层能够占据多个预定状态之一，其中每个状态与其关联了包括到其它状态之一中的层的消息相关转变的预定功能性；该设备包括用于将软件更新模块装载到存储器中的装置，更新模块被安排成接收和处理与这些层之一的这些状态之一对应的一个或多个消息，该模块包括至少一个消息相关转变单元，其可用来导致将层转变到另一个状态中。
本发明的第四方面提供了一种被配置为如本发明第三方面所述的设备的可配置设备。


现在参照附图仅作为示例描述本发明的特定实施例，其中图1示出如上所述的说明性背景例子的通信协议栈；图2示出如上所述的图1的通信栈的概念(notional)层；图3示出如上所述的用于实现动态可重新配置的通信协议栈的公知架构；图4示出如上所述的根据说明性背景例子的用于动态可重新配置的协议栈的架构；图5示出如上所述的绑定消息；图6示出如上所述的函数指针表；图7示出如上所述的协议消息；图8、9、10、11示出如上所述的层软件和操作系统特定映射对象的多个说明性例子；图12示出如上所述的根据说明性例子的层的多个实例化；图13示出如上所述的根据说明性例子的协议栈中的软件层的实例化和绑定；图14示出如上所述的说明性例子的块代码表示；图15示出如上所述的根据说明性例子的虚拟操作系统；图16和17分别示出如上所述的用于C代码的公知动态链接方法和操作系统函数表传递方法；
图18和19分别示出如上所述的用于Java代码的公知动态链接方法和操作系统函数表传递方法；图20示出如上所述的公知的每消息一线程的协议栈架构；图21示出如上所述的用于图10的例子的示意性存储器架构；图22示出如上所述的根据说明性例子的每层一线程的架构；图23示出如上所述的用于图20的例子的示意性存储器架构；图24和25示出如上所述的将高级源代码编译成模块以便在例子中使用的两个方法；图26示出蓝牙TM复杂协议栈的说明性示例实现；图27示出如上所述的说明性例子的升级蓝牙TM协议栈；图28示出基于状态的功能性的上面描述的上下文中前述协议栈的层；图29示出图28所示的层的函数查询表；图30是由包括图28所示的层的基于层的协议栈配置的通信设备的示意图；图31是包括图30的通信设备的系统的示意图，其中协议栈的更新可用于下载；图32是图30所示的通信设备的另一图示，其中包括协议栈层的第一升级；图33示出配置图32所示的通信设备的协议栈层的第一升级状态模块；图34示出图30所示的通信设备，其包括配置通信设备的协议栈层的第二升级；图35示出包括到图34所示的通信设备中的第二升级模块增强；以及图36示出图28所示的层的增强状态转变图，其包括图35所示的模块增强。
具体实施例方式
如图28所示，(在适当时将描述的图30所示的)通信协议栈的层10具有三个可能的状态，并且在这些状态之间定义转变。在本例子中，三个状态包括断连(disconnected)状态12、连接未决(connect pending)状态14以及已连接(connected)状态16。
断连状态12包括状态消息处理函数指针FUNC#1。连接未决状态14包括两个消息处理函数指针FUNC#2和FUNC#3，并且已连接状态16还包括两个消息处理函数指针FUNC#4和FUNC#5。
这些函数指针可用来检测由该层接收的协议消息，并且当该层处于对应的状态12、14、16时，通过访问对应的操作系统函数来响应接收到适当的消息。这些函数导致生成另外的协议消息以便沿着协议栈进一步传输。
图29示出消息处理函数指针FUNC#1到FUNC#5与操作系统函数之间的关系。这些消息处理函数指针将对应于操作系统函数或者其序列，以便以预期的方式访问系统或执行环境资源。
为了简明起见，这些消息处理函数指针与可标识的动作相对应，其中这些动作与标注connect_req(连接请求函数)、connect_conf(确认连接函数)、connect_res(响应连接请求函数)、disconnect和change_QoS(改变服务质量函数)相关联。
如图30所示，通信设备29包括处理器22，其能够执行机器代码可执行指令，通过总线24连接到通信硬件单元以便通过无线通信链路经由天线28与另一个设备建立物理连接；用户输出单元30，用于与用户建立数据输出(通过音频或视频装置)；以及用户输入管理单元32，用于检测适当输入设备上的用户输入动作。
应当理解，用户输入管理单元32可接受用户输入动作，例如键盘、屏幕上的定点设备、输入板和书写工具的驱动、屏幕上的直接指示笔驱动、语音输入及其适当解释、以及高级输入技术如视线等等。处理器22还能够参考存储装置34，其可包括内部存储器和/或可移动存储器例如订户识别模块(SIM)。
处理器22还与工作存储器36通信，在本例中，在工作存储器36中存储了包括三层即层1、层2和层3的协议栈以及协议层实例配置数据(每个实例可以以不同的方式配置)。
在使用时，如图31所示，移动通信设备能够与无线因特网接入单元40建立无线通信，从而它能够与因特网42并且由此与服务器44建立连接，其中服务器44通过适当的装置被布置了包括增强第二状态(连接未决状态14)的第一升级单元46和包括对若干状态的模块增强的第二升级单元48。
如图32所示，所示的通信设备29通过任何适合的装置接收到包括第二状态的增强功能性的模块46的副本。通过将此模块46存储在工作存储器36中，增强了层2的操作。现在将参照图33描述用来实现此的装置。如图33所示，connect_pending#2状态模块包括与原始函数指针FUNC#2相对应的重定向函数50以及与原始connect_pending状态14中的函数指针FUNC#3相对应的更新函数指针52。考虑到其更新性质，该函数指针52被命名为FUNC#3_1。
在使用如图28所示的层10中，当层10处于由此状态14活动的条件时，可以期待(expect)与处理函数指针FUNC#2或FUNC#3对应的协议消息。在图28所示的情况下，使函数FUNC#2执行的协议消息的接收不导致任何状态转变。相反，函数FUNC#3的调用导致从connect_pending 14到connected状态16的状态转变。在更新模块46定义connect_pending#2状态扩展的情况下，当层10处于connect_pending状态14内时，扩展46取代原始状态消息处理函数，并且可用来接收协议消息。在使用时，由与connect_pending状态14中的原始函数指针FUNC#2对应的重定向函数指针50捕获与处理函数FUNC#2相对应的协议消息。
另一方面，如果接收到与消息处理函数FUNC#3相对应的协议消息，则更新函数单元FUNC#3_1(图33中的标号52)捕获该消息，并且导致执行模块46内的新消息处理代码。这样，可以对在原始提供的状态中定义的功能性进行增强。然后，通过函数指针FUNC#3_1的更新代码执行导致从connect_pending状态14到connected状态16的状态转变。
状态转变通过上述公共共享配置数据来实现。配置数据保存(除了定义可选协议层特性的配置的参数之外)函数指针表，该函数指针表具有与协议层状态机实例的每个状态的消息处理函数对应的条目。当创建新的层实例时，必须在绑定消息中将配置数据发送到该层实例。因此，如果发送到模块(例如，模块46)的配置数据基于现有层2实例的配置数据，则该模块(在绑定处理程序函数中)可覆盖和添加(必要时)条目到与由该新模块处理的消息对应的函数处理指针信息。在这种情况下，FUNC#1_1和FUNC#3_1分别覆盖现有的FUNC#1和FUNC#3。然而，不删除任何条目。下表阐述了这样的函数指针表的说明性例子。

配置数据还保存用来确定该表中要执行的哪些信号处理函数的CurrentState(当前状态)指针。实现信号处理函数本身的代码由于使用分别如前所述的操作系统和虚拟操作系统而与编程语言和操作系统无关。
存在两个主要方法来实现使用操作系统(或虚拟操作系统)表概念的可重新配置的状态机实施。第一方法，即每层实例一线程的方案假定每个逻辑层实例存在一个执行线程，其处理所有进入消息。然后，线程调用与消息类型(例如通过VOS函数调用get_message_type获得)相对应的对应消息处理函数。然后，可以使用对应于层实例的表来执行当前状态(从CurrentState属性获得)的对应函数。改变状态简单地通过这样的方式来实现，即调用适当的函数以将CurrentState属性改变为从与下一个状态名称(即，在改变属性之后将变成当前的状态)相对应的配置数据表获得的指针引用。
第二方案是每个消息处理函数具有一个逻辑线程。这不一定对应于真实的操作系统线程，而可以是VOS线程(如果采用VOS实施)。每次启动状态转变时，通过调用VOS函数change_state(new_state_name)，change_state函数为对应于逻辑层实例的配置数据表中的消息处理函数启动新的VOS线程。该消息处理函数调用的第一操作是针对特定消息类型的VOS receive_message函数。以这种方式，VOS然后仅将所需消息转发到该消息处理函数。该方案还要求终止或挂起不再对应于当前状态的消息处理线程。
图34示出通信单元20，其在工作存储器36中检索(retrieve)了模块增强单元48，以便结合协议栈的层2执行操作。现在将参照图35描述包括模块增强单元48的协议栈的操作。
图35示出模块增强单元48，其包括更新断连状态disconnected#254、更新连接未决状态connect_pending#2 56、新subs_connect_pending状态58、以及connected#2状态模块59，其中subs_connect_pending状态58用来同时使用两个模式(或网络)建立混合网络系统的第二连接，并且connected#2状态模块59用来考虑到引入由subs_connect_pending状态58提供的附加系统功能性而增强现有connected状态16的功能性。
disconnected#2状态包括指向增强connect_REQ函数的函数指针FUNC#1_1，connect_pending#2状态扩展56包括重定向函数指针62，其对应于原始实现的connect_pending状态的原始函数指针FUNC#2，并且包括指向增强函数FUNC#3_1的指针(图35中的标号64)，其代替原始实现的connect_pending状态中的原始函数指针FUNC#3捕获消息。
此外，描述subs_connect_pending条件的新状态模块58包括指向函数FUNC#6的指针66，其在使用时将使得能够激活与第二网络的随后连接，该连接如在connected#2状态增强中现在定义的那样结合第一连接来使用，以实现包含在新函数FUNC#7中的负载分担(load sharing)功能性。
新connected#2状态模块59包括指向现有函数FUNC#4和FUNC#5的消息处理指针67、68，以及指向新负载分担函数FUNC#7的消息处理指针69。
新引入的函数指针60、64、66和69包括修改的向层内的其它状态的转变。函数FUNC#1_1提供了当定义connect_pending#2时从更新状态54 disconnected#2到升级状态56的状态转变。新函数指针FUNC#3_1接管向connected状态16的状态转变，该状态转变先前由connect_pending状态14中的FUNC#3支配。此外，新状态subs_connect_pending 58具有函数指针FUNC#6，其也提供向connected状态16的状态转变，并且FUNC#7处理data_transfer消息，并包括允许两个网络连接之间的动态负载分担的功能性。这些状态转变在图36中示出。
通过使用支持一般性函数指针表(映射对象)的VOS概念，可以从原始功能性在不同的执行环境(例如，不同的JVM或操作系统环境)中执行在模块48中提供的增强功能性。另外，同样地，在增强模块中使用的编程语言可以不同于原始代码。
本领域的技术人员应当认识到，上述设备和方法可被实施为例如载体介质如盘、CD-或DVD-ROM、程序化存储器如只读存储器(固件)上或者数据载波如光或电信号载波上的处理器控制代码。对于本发明的很多应用实施例，将在DSP(数字信号处理器)、ASIC(专用集成电路)或FPGA(场可编程门阵列)上实现。因此，该代码可包括传统的程序代码或微代码，或者例如用于设置或控制ASIC或FPGA的代码。该代码还可包括用于动态配置可重新配置设备如可重新编程逻辑门阵列的代码。类似地，该代码可包括硬件描述语言如VerilogTM或VHDL(极高速集成电路硬件描述语言)的代码。本领域的技术人员应当理解，该代码可以分布在相互通信的多个耦接的组件之间。适当时，这些实施例还可使用在场可编程(可重新编程)模拟阵列或类似装置上运行以便配置模拟硬件的代码来实现。
本领域的技术人员还应当理解，根据上述教导，各个实施例以及关于其描述的特定特性一般地可以自由地与其它实施例或者其特定描述的特性相组合。本领域的技术人员还应当认识到，在不脱离所附权利要求的范围的情况下，可以对特定所述例子进行各种变更和修改。
权利要求
1.一种修改通信协议以便处理在具有处理器和存储器的处理设备中提供的信号的方法，该协议由多个协议层定义、正在使用中的至少一层能够占据多个预定状态之一，其中每个状态与其关联了包括到其它状态之一中的层的消息相关转变的预定功能性；该方法包括将软件更新模块装载到存储器中，该模块被安排成接收和处理与所述层之一的所述状态之一对应的一个或多个消息，该模块包括至少一个消息相关转变单元，其可用来导致将所述层转变到另一个状态中。
2.根据权利要求1所述的方法，其中该模块可用来截取打算发往实现所述对应状态的预定功能性的消息，并且将与所述消息相关转变单元无关的消息传递到所述预定功能性。
3.根据权利要求1或权利要求2所述的方法，其中更新模块可用来接收和处理消息，并且导致将所述层转变到另一个状态中，所述消息不可用来在装载所述模块之前导致所述层中的转变。
4.根据权利要求1至3中的任一项所述的方法，包括将更新模块安排成与其它模块交换对应于所述信号的协议消息，其它模块被安排成根据对应于其它所述层的一般性函数集来处理所述信号。
5.根据权利要求1至4中的任一项所述的方法，还包括将所述其它软件模块装载到存储器中，其它模块包括与函数映射对象中的所述一般性函数对应的一般性函数指针；对于将所述函数映射对象装载到存储器中的每个其它模块，该对象包括与一般性函数对应的设备特定函数指针，以便将所述一般性函数映射到一个或多个设备特定函数；根据所述映射的设备特定函数执行其它模块，以便根据所述协议层处理所接收的信号。
6.根据权利要求1至5中的任一项所述的方法，还包括将第二软件模块装载到存储器中，第二模块被安排成根据与所述层中的第二层对应的一般性函数集接收并处理所述信号，第二模块包括与第二函数映射对象中的所述一般性函数对应的一般性函数指针，将所述第二函数映射对象装载到存储器中，该对象包括与一般性函数对应的第二设备特定函数指针，以便将所述一般性函数映射到一个或多个第二设备特定函数，并且根据所述映射的第二设备特定函数执行第二模块，以便根据所述协议层处理所接收的信号；从而，在不同的执行或设备特定环境中执行第一和第二模块。
7.根据权利要求1至6中的任一项所述的方法，其中更新模块是语言无关的。
8.根据权利要求1至7中的任一项所述的方法，包括提供高级软件语言代码，其用于根据对应于所述层的所述一般性函数集处理所述信号；以及将所述代码编译成所述语言无关软件模块。
9.一种程序，用于控制处理设备执行如权利要求1至8中的任一项所述的方法。
10.一种存储介质，其承载这样的数据，其中当装载到可配置设备中时，该数据使得能够执行程序以使可配置设备执行如权利要求1至9中的任一项所述的方法。
11.一种信号，其承载这样的数据，其中当装载到可配置设备中时，该数据使得能够执行程序以使可配置设备执行如权利要求1至10中的任一项所述的方法。
12.一种用于修改通信协议以便处理在具有处理器和存储器的处理设备中提供的信号的设备，该协议由多个协议层定义、正在使用中的至少一层能够占据多个预定状态之一，其中每个状态与其关联了包括到其它状态之一中的层的消息相关转变的预定功能性；该设备包括用于将软件更新模块装载到存储器中的装置，更新模块被安排成接收和处理与所述层之一的所述状态之一对应的一个或多个消息，该模块包括至少一个消息相关转变单元，其可用来导致将所述层转变到另一个状态中。
13.根据权利要求12所述的设备，其中所述更新模块可用来以在语言上与该模块向其提供更新功能性的状态的预定功能性无关的方式工作。
14.根据权利要求12或权利要求13所述的设备，其中更新模块可用来将设备配置成使装载在其上的层能够占据至少一个附加状态，并且还可用来将该设备配置成将预定功能性与所述至少一个附加状态相关联，所述至少一个附加状态包括到所述至少一个附加状态中和从其中的消息相关转变。
15.一种可配置设备，被配置为根据权利要求12所述的设备。
16.一种用于修改具有处理器和存储器的信号处理设备中的通信协议的更新模块，该协议由多个协议层定义、正在使用中的至少一层能够占据多个预定状态之一，其中每个状态与其关联了包括到其它状态之一中的层的消息相关转变的预定功能性；该更新模块可被装载到所述设备的存储器中，以接收和处理与所述层之一的所述状态之一对应的一个或多个消息，该更新模块包括至少一个消息相关转变单元，其可用来导致将所述层转变到另一个状态中。
17.根据权利要求16所述的更新模块，其中所述更新模块可用来以在语言上与该模块向其提供更新功能性的状态的预定功能性无关的方式工作。
18.根据权利要求16或权利要求17所述的更新模块，其中更新模块可用来将设备配置成使装载在其上的层能够占据至少一个附加状态，并且还可用来将该设备配置成将预定功能性与所述至少一个附加状态相关联，所述至少一个附加状态包括到所述至少一个附加状态中和从其中的消息相关转变。
19.一种存储介质，存储处理器可读指令，以使根据权利要求16到18中的任一项所述的更新模块被装载到包括处理器装置和存储器的处理设备的存储器中。
20.一种信号，承载处理器可读指令，以使根据权利要求16到18中的任一项所述的更新模块被装载到包括处理器装置和存储器的处理设备的存储器中。
全文摘要
本发明涉及特别是但非排他性地用于通信终端如移动电话、膝上型计算机和基站的协议栈以及协议栈内的协议层。本发明提供了一种修改通信协议以便处理在具有处理器和存储器的处理设备中提供的信号的方法，该协议由多个协议层定义、正在使用中的至少一层能够占据多个预定状态之一，其中每个状态与其关联了包括到其它状态之一中的层的消息相关转变的预定功能性，该方法包括将软件更新模块装载到存储器中，该模块被安排成接收和处理与这些层之一的这些状态之一对应的一个或多个消息，该模块包括至少一个消息相关转变单元，其可用来导致将层转变到另一个状态中。还描述了被配置为执行该方法的设备、以及用来使设备以这种方式被配置的计算机可读存储介质和可下载信号。
文档编号H04L29/08GK1765105SQ20058000001
公开日2006年4月26日 申请日期2005年2月25日 优先权日2004年2月27日
发明者蒂莫西·D.·法纳姆 申请人:株式会社东芝