在蜂窝网络中用于软件通信的与配置无关的方法及设备

本发明涉及到用于蜂窝通信业务的网络。更具体地，本发明涉及到 用于在蜂窝网络中实现软件的方法和设备。

图1为一个框图，它描述了一种典型蜂窝网络的组件，其中包括移 动交换中心(MSC)100，基站控制器(BSC)102，基站收发信台 (BTS)104，以及多个蜂窝手机106(a)-106(b)。图1中的 典型蜂窝网络的组件在前面提到过的专利申请中已经被广泛讨论过。

在现有技术中，蜂窝网络的每个组件，即MSC100，BSC102，以 及BTS104都是在一个分离的机架(chassis)上实现并被封装在一个分 离的“箱子(box)”里。这些箱子根据需要在一个地理位置内被分散 开，它们之间通过中继线连接在一起而实现蜂窝网络。

目前每个MSC100，BSC102，以及BTS104的实现一般都包括两 个主要部分：硬件和软件。硬件通常都包括相对固定的物理电路，而软 件，为可编程的，通常比硬件更容易设计、实现和修改。因此，除了某 些硬件是必须的外，蜂窝网络的多数功能一般最好是考虑尽可能用软件 来实现。由于可以利用现代高速处理器和可编程电路，这确实是可以实 现的。

在某个水平上，讨论用软件形式来实现和操作一个典型蜂窝网络的 组件是可能的。作为例子，图2为一个框图，它描述了用于实现现有技 术的蜂窝网络组件的软件功能块的现有技术的实现。现在参照图2，它 有三个方块：200，202及204，它们分别包含用于实现MSC，BSC 及BTS组件所必需的硬件。如图2所示，方块200中还提供用来实现 MSC功能的软件，与方块202中实现BSC的软件进行通信所必需的A 接口、以及通过中继线206与此通信的E1资源。除了必不可少的硬件 外，方块202还包含用于实现BSC功能的软件、与方块200中实现MSC 的软件进行通信的A接口、以及通过中继线206与此通信的E1资源。 为了与方块204中实现BTS的软件进行通信，方块202中还提供实现 Abis接口的软件以及用于通过中继线208进行通信的E1资源。

同样地，方块204包含有用来实现BTS功能、与方块202中实现 BSC的软件进行通信的Abis接口、以及便于与此通信的E1资源的软 件。为了与它的手机(未显示)通信，方块204还包含实现LAPDm设 施212的软件，该软件连同实现TRX资源214的软件，允许在方块204 中实现BTS功能的软件与它的蜂窝手机进行通信。

在现有技术中，实现方块200，202以及204的每个软件都是为特 定蜂窝网络配置进行定做的。正如这里所使用的术语，蜂窝网络配置指 的是蜂窝网络中的MSC，BSC以及BTS，以及它们在一个机架内或 在多个机架中连接的特定方式。在现有技术中，当改变蜂窝网络配置 时，例如对BSC或BTS进行增减以满足地域和容量要求时，那些受影 响的软件必须被重新编程以适应这些变化。

作为例子，当一个BTS被加入到一个BSC的区域内并且需要与该 BSC通信时，实现BSC的现有技术软件一般都是必须重新编程以适应 这个变化。作为另一个例子，如果决定把图2中的BSC和BTS功能压 缩到一个机架，即提供一个较小的封装以减少硬件费用和简化维护和/ 或升级，则在现有技术中就必须对实现BSC的软件和实现BTS的软件 都进行重新编程以适应这两个组件不再利用中继资源进行彼此通信的 事实(因为它们现在放在相同的机架内)。

另外，如果一个蜂窝网络起初被配置成单个机架，其中MSC，BSC 和BTS在一起(如在共同未决的专利申请WAVEP001.P的一个实施方 案中所公开的)，并且在日后为了扩展蜂窝网络的容量而增加额外的远 端BTS到网络中时，则实现它的软件的现有技术方法一般都需要对受影 响组件的软件作大量的重新编程，这些组件可能包括MSC，BSC和 BTS。

还有，实现蜂窝网络中MSC，BSC和BTS软件的现有技术范例 要求部分应用开发者，即那些开发用于实现软件功能块如MSC，BSC 或BTS的软件的人具有关于在一个特定网络结构中数据必须如何被选 路的多方面的知识。现有技术的软件功能块为适应网络配置的修改而必 须改变的事实意味着当为响应在区域和容量需求中的变化而对蜂窝网 络进行升级，或扩大或缩小规模时在时间和费用方面都需要相当大的开 销。    

鉴于以上情况，所需要的是一种改进的方法和设备，该方法和设备 以尽可能独立于蜂窝网络配置的方式来实现蜂窝网络的软件。同时还要 求被改进的方法和设备把MSC，BSC和BTS实现成与蜂窝网络配置 无关并基本上不变的程序块。更重要的是，要求这些实现蜂窝网络中 MSC，BSC和BTS的基本上不变的程序块利用一种接口在它们当中进 行通信，这种接口也是基本上不用改变而不管蜂窝网络的配置是否变 化。

                           发明概述

在一个实施方案中，本发明涉及到一种用于实现蜂窝通信网络的与 配置无关的软件结构，这种网络便于大量手机之间的通信。

这种结构包括一个实现第一功能集的第一软件功能块和一个实现 第二功能集的第二软件功能块。该结构还包括一个与配置无关的连接 块，它有一个对于第一软件功能块和第二软件功能块都呈现为一致的接 口，而不管蜂窝通信网络中在第二软件功能块、第一软件功能块和与配 置无关的连接块之间的相对位置。

与配置无关的连接块便于第一软件功能块和第二软件功能块之间 通过利用与配置无关的连接块的接口进行通信。有利的是，当第一软件 功能块在蜂窝通信网络内改变相对于第二软件功能块的位置时，第一软 件功能块、第二软件功能块和接口基本上保持不变。

在一个特定实施方案中，第一软件功能块为一个基站收发信台软件 功能块并且第一功能集为一个基站收发信台功能集，而第二软件功能块 为一个基站控制器软件功能块并且第二功能集为一个基站控制器功能 集。

在另一个实施方案中，本发明涉及到一种使得在具有多个中央处理 单元的蜂窝通信网络内多个软件功能块之间便于进行通信的方法。该方 法包括提供一个用于实现第一功能集的第一软件功能块的步骤。第一软 件功能块在蜂窝通信网络的第一中央处理单元中被执行。该方法还包括 提供一个用于实现第二功能集的第二软件功能块的步骤。第二软件功能 块表示一个代表第二功能集的程序块的第一实例。

本发明的方法还包括提供用于实现第二功能集的第三软件功能块 的步骤。第三软件功能块表示一个代表第二功能集的程序块的第二实 例。此外，本发明的方法还包括便于在第一软件功能块、第二软件功能 块和第三软件功能块之间利用至少一个与配置无关的连接块进行与配 置无关的通信的步骤。根据本发明的一个方面，与配置无关的连接块有 内部函数，从第一、第二和第三软件功能块方面来看，该函数在第一、 第二和第三软件功能块之间透明地实现配置特定的通信。与配置无关的 通信通过一个接口进行，该接口基本上固定而不管第二和第三软件功能 块是在蜂窝通信网络中的第二中央处理单元还是在不同的中央处理单 元上执行。与此无关，第一、第二和第三软件功能块在整个网络配置中 基本上保持不变。

在又一个实施方案中，第一、第二和第三软件功能块以及接口都保 持基本上不变而不管第二和第三软件功能块是在一个不同于第一中央 处理单元的第二中央处理单元上执行还是在两个不同于第一中央处理 单元的不同的中央处理单元上执行。

                         附图简述

通过阅读下面的详细描述和参照附图，本发明的其它优点是明显 的，其中：

图1为一个框图，描述了一种典型蜂窝网络的组件；

图2为一个框图，描述了实现现有技术的蜂窝网络组件的软件功能 块的现有技术实现；

图3描述在本发明的一个方面，实现蜂窝网络的组件的软件功能块 (SFB)的与配置无关的结构；

图4A描述了一个蜂窝网络配置的例子，其中基站控制器(BSC) 和移动站控制器(MSC)的SFB共同放在单个机架中的单个中央处理 单元(CPU)上，而基站收发信台(BTS)软件功能块则被放在远处 的不同机架的一个不同的CPU上。

图4B描述了一个蜂窝网络配置的例子，其中BTS软件功能块和 BSC软件功能块共同放在单个机架上而MSC的SFB则被放在远处的不 同的机架上；

图5描述了一个BSS实现，其中BSC软件功能块和BTS软件功能 块共同放在同一个CPU/机架上；

图6A为一个描述在一个实施方案中两个SFB如BSC SFB和BTS SFB之间通信协议之间的关系以及在它们之间的与配置无关的连接块 内进行的实际数据交换的图。

在图6B中，BSC SFB和BTS SFB被分布在不同的CPU/机架内。

图7为一个描述在一个实施方案中在SFB之间以与配置无关的方式 便于进行通信的消息传递范例的图；

图8描述了多个SFB如何利用子程序库中的子程序以与配置无关的 方式进行通信；

图9A显示了在一个实施方案中用于SFB之间通信的一个多层通信 栈；

图9B显示了藉使用本发明的与配置无关的结构技术在BSC SFB和 MSC SFB之间的通信；

图10描述了对于不同SFB之间通信的消息传递范例；

图11显示了一个与CPU相关的路由表的例子；

图12描述了当一个BSC管理SFB和一个A接口SFB互相离得很 远时，在这两个SFB之间的通信；以及

图13描述了单个BSC管理SFB和在三个分离的蜂窝中央处理单元 (CCPU)卡上实现的三个BTS管理者SFB之间的通信。

                 优选实施方案详述

图3显示了在本发明的一个方面实现蜂窝网络的组件的软件功能块 (SFB)的与配置无关的结构。在图3中，三个SFB MSC220，BSC222 和BTS 224通过与配置无关的连接块(CILB)226和228连接在一 起。根据本发明的一个方面以及如后面将要详细讨论的，CILB226包 含一个接口，该接口不管蜂窝网络的配置如何而对MSC SFB220和BSC SFB222都可呈现为基本上不变。换句话说，MSC SFB220和BSC SFB222与CILB226通信的方式基本上保持不变而不管这两个SFB是否 在相同的中央处理单元(CPU)中被执行、在相同的物理机架(即相 同的机架)上实现但在不同的CPU上执行、还是被放在远处的地理上 分散的通过中继线相互连接的机架上。

为了阐明起见，当两个SFB在这里被认为是在同一个CPU/机架上 实现时，则这两个SFB可能在该机架中相同的CPU上或在该同一个机 架中的多个CPU上运行。当在单个机架中提供多个CPU时，该机架上 能提供更大的处理能力。多个CPU可以被紧密连在一起，即通过共享 存储器资源及其它资源，或者被较松散地连在一起，即通过利用相同的 总线但每个CPU有其自己的存储器和其它资源。相反，当两个SFB相 互远离时，则它们在不同机架中的不同CPU上被执行，并且这些SFB 之间的通信需要远程通信资源，例如E1。

此外，最好是CILB228和BSC SFB222之间(以及CILB 228和 BTS SFB224之间)的接口基本上保持不变而不管蜂窝网络的配置。

根据本发明的另一个方面，实现这些主要的SFB，如MSC SFB 220，BSC SFB222，BTS SFB224，及与无线相关的SFB(如TRX SFB230)的软件程序基本上保持不变而不管蜂窝网络的配置。这样， 每个实现蜂窝网络组件的程序块可以被制成标准组件，因此简化了网络 扩展、升级和维护。

在本发明的一个方面，实现蜂窝网络组件的主要SFB可以在单个 CPU/机架中被灵活组合或被放置在远处的CPU/机架的组合中，因此用 一种廉价方式来提供特制解决方法以满足特定地理或容量要求是可能 的。因为主要的SFB能在不同的CPU/机架间以一种不需要对主要SFB 进行大量重新编程的方式来被重新组合，所以本发明的这个方面，极大 地简化了网络升级和调整规模，即靠分别增加和去掉网络组件以适应蜂 窝网络的改变地域或容量需求来扩展和缩小规模。

在一个新的市场中，本发明的与配置无关的结构允许蜂窝提供者能 通过使用单个机架来实现所有四个主要组件(即MSC，BSC，BTS 和TRX)而提供一种廉价并能拥有比现有技术可能达到的更高的性能 特性的蜂窝网络。作为例子，使用单个机架实现所有这四个主要组件就 硬件和软件而言有利地消除了与实现中继资源有关的花费。当容量和区 域需求增加时，例如为了处理更多的蜂窝手机或为了扩展覆盖区域，本 发明的与配置无关的结构允许用一种模块化和与配置无关的方式来调 节网络软件。由于主要的SFB基本上保持不变，并且它们互相之间的通 信方式不取决于系统配置，故网络升级和扩展被极大地简化。

根据本发明的这个方面，在蜂窝网络配置中的变化仅仅主要影响作 为CILB的基础的软件函数。作为例子，当蜂窝网络配置从BTS/BSC 配置(BTS和BSC共同放在相同的CPU/机架上并且MSC被放在远 处)变到BTS/BSC/MSC配置(所有三个SFB共同放在相同的CPU/机 架上)时，改变的是实现SFB之间的CILB的软件函数，而不是SFB 本身。但是，从实现MSC，BSC和BTS的SFB方面来看，用来为这 些主要的SFB通信的CILB接口最好是基本上保持不变。

BTS SFB 224还通过TRX与配置无关的连接块(CILB)232与 TRX SFB230进行通信，其中连接块(CILB)232有一个对于BTS SFB 224和TRX SFB230都呈现为基本上保持不变而与蜂窝网络配置无 关的接口，也就是说，不管它们是否共同放在相同的CPU/机架中还是 被放在远处的不同的CPU/机架中。正如上面例子中看到的是，术语软 件功能块并不仅仅限于实现MSC，BSC和BTS的程序块。事实上， 它们适用于在蜂窝网络中完成一特定任务的任何可执行程序块并且基 本上不受网络配置的变化的影响。

图4A描述了一个蜂窝网络配置的例子，其中BSC和MSC SFB共 同放在单个机架中的单个CPU上而BTS SFB被放在远处的一个不同机 架上的一个不同CPU中。在图4A中，MSC SFB220通过CILB 226与 BSC SFB222通信而BSC SFB222通过CILB228与BTS SFB224通信。 在图4A的具体例子中，虽然为了举例说明而选择GSM标准，但应当 明白，本发明的与配置无关的结构不限制于任何特定协议。作为例子， 可以考虑用局域网协议，如TCP/IP，或其它蜂窝标准如AMPS(高级 移动电话业务)，TACS，等其它协议来实现本发明的与配置无关的结 构。

由于BSC SFB 222和MSC SFB220共同放在相同的CPU中，CILB 226作为一个本地接口被实现，更具体地，作为实现与GSM相关的A 接口的一个本地接口被实现，其中A接口利用消息传递来通信。在图 4A的网络中实现的A接口，在一个实施方案中，遵守如GSM规范08.06 中所述的信令连接控制部分-消息传送部分1-3(SCCP MTP1- 3)。消息传递将在下面结合图7进行解释。此外，由于BTS SFB224 远离BSC SFB222或MSC SFB220，故CILB 228被作为远端接口来实 现。在图4A的具体例子中，CILB 228被作为一个利用与GSM相关的 Abis接口的远端接口来实现，该Abis接口利用E1中继设施和中继线来 为远端通信提供便利。

更重要的是，MSC SFB220，BSC SFB222和BTS SFB224基本上 保持不变而不管它们是否共同放在相同的CPU/机架中还是被放在远处 的不同的CPU/机架中。此外，与根据这里所公开的技术而实现的所有 CILB一样，CILB226和CILB228的接口对于和它们进行通信的SFB 来说都呈现为基本上不变。例如，CILB 226有一个对于MSC SFB220 和BSC SFB222来说都呈现为基本上不变的接口，而不管CILB 226是 否被作为一个本地接口(如图4(a)的例子中)还是被作为一个便于被放 在远处的不同的CPU/机架中(正如BSC SFB 222被远离MSC SFB220 而放在不同的CPU/机架中这种情况)的SFB之间远程通信的接口来实 现。同样，CILB228有一个对于BSC SFB222和BTS SFB224来说都呈 现为基本上不变的接口而不管CILB 228是否作为一个本地接口还是作 为一个便于远程通信的接口在内部被实现。

为了对比，图4B显示了一种蜂窝网络结构，其中BSC SFB222和 BTS SFB224共同放在单个机架上而MSC SFB220被放在远处的一个不 同的机架上。正如图3和图4A中的情形一样，SFB分别藉利用它们各 自的CILB进行通信，其中这些CILB有一致的接口而不管它们是否共 同在同一个机架上还是被相互远离。还有，在图3的BTS，BSC和 MSC的SFB以及图4A和图4B的各个SFB之间基本上没有差别。 CILB228在图4B中以本地方式和在图4A中用远程方式实现与GSM相 关的Abis接口的事实通过CILB228的与配置无关的接口而从BSC SFB222和BTS SFB224来看被很大地隐藏了。同样，CILB226在图4B 中用远程方式和在图4A中用本地方式实现与GSM相关的A接口的事 实通过CILB226的与配置无关的接口而从BSC SFB222和MSC SFB220 来看也被很大地隐藏了。

通过在CILB 226和228以及CILB232(图4A和4B中没有显示) 内简单地修改软件程序，根据本发明的与配置无关的结构而创建的蜂窝 网络可以用一种模块化和与配置无关的方式来被灵活地重新配置以得 到不同的网络配置而不用对它主要的SFB的程序作大量的修改。事实 上，对于SFB(如MSC，BSC，BTS或TRX的SFB)的开发者来 说，没有必要了解特定网络配置中关于数据选路的细节。由于从SFB方 面来看CILB接口基本上保持不变，这些SFB可以独立于任何网络配置 知识来被开发。当蜂窝网络需要被升级、维护、调节(增加或减少)以 满足某特定地理位置的容量和区域需求时本发明的这个方面就呈现出 较大的优点。

图5描述了一个BSS实现，其中一个BSC SFB和一个BTS SFB共 同放在同一个CPU/机架中。BSC SFB300通过CILB304与BTS SFB302通信。BSC SFB300还与一个处理BSC SFB300和一个MSC(未 显示)之间通信的CILB 306进行通信。

为了说明起见，显示了在BSC SFB300内的一些用于实现BSC SFB 的功能块。作为例子，显示了BSC管理功能块320、BTS管理者功能 块332、信道管理者功能块324和越区切换管理者功能块326。类似地， 显示了在BTS SFB302中的BTS管理328、专用信道块330和公共信道 块332。功能块320-332中的每一个都可以被看作为一个SFB，即它 们可通过使用本发明的CILB概念被放在远处或在同一个CPU/机架中 实现而不需对它们的内部代码作大量的修改。

为了说明起见，显示两个用于使BTS SFB302和蜂窝手机(为了便 于说明，被从图5中省去)之间通信便利的无线相关的SFB312和314。 应当理解，为了与蜂窝网络中蜂窝手机数量相适应的必要，可以提供更 大或更少数量的无线相关的软件功能块(SFB)。

无线相关的SFB完成TRX相关的功能例如通信功能、LAPDm功 能以及TRX管理功能等等。为了完成上述功能，每个无线相关的SFB 可以包含一个LAPDm SFB，一个TRX管理SFB以及一个数字信号处 理(DSP)管理SFB。BTS SFB302与一个CILB310进行通信，其中 CILB310处理BTS SFB302和多个蜂窝手机之间的通信。与图3的 CILB232类似，图5的CILB310对于BTS SFB302来说呈现为基本上 不变而不管蜂窝网络中无线相关的SFB的数目。

与配置无关的通信可以用任何方式来完成。为了说明起见，这里讨 论两个用于实现CILB的主要通信范例。首先，通过CILB而与一个SFB 的与配置无关的来回通信可以靠消息传递来进行。在消息传递时，发送 的SFB把一个消息发送到一个地址已知的邮箱。如果目的邮箱对于发送 的SFB来说为本地邮箱，即在同一个CPU/机架上实现，则CILB仅仅 把消息转送到该目的邮箱以让监视着邮箱的SFB中的一个SFB检索 到。如果目的邮箱和它的相关的接收的SFB互相远离，即在不同的CPU/ 机架上实现，则CILB将为消息选择合适的路由。从发送的SFB方面来 看，目的邮箱在一种情况中被本地实现及在另一种情况中被远程实现的 事实基本上被隐藏了。实际的关于为数据选路由的细节被留给CILB内 的函数。

另一方面，CILB可以通过调用接口函数而易于与SFB的来回通 信，其中接口函数基本上为子程序库，这些子程序能被需要它的SFB为 通信而进行静态或动态连接。通过利用合适的函数，CILB能在对数据 进行本地选路或选路送到远程CPU/机架的同时还使这些配置特定的细 节与发送的SFB和接收的SFB分离开。    

在图5的BTS SFB302和它的无线相关的SFB之间的通信中可以看 到一个利用接口函数来允许蜂窝网络的两个SFB以一种与配置无关的 方式进行通信的CILB的例子。当BTS 302期望与它的无线相关的SFB 中任何一个进行通信时，它向正巧被一个先进先出堆栈(FIFO)部分 地实现的CILB310发送数据。虽然不是一种必要条件，但CILB 310的 FIFO，在一种实施方案中，是在执行其相关的无线相关的SFB的同一 个CPU上被实现的。

为了向CILB 310的FIFO发送数据，举例来说，BTS SFB302可 以调用一个子程序FifoSend，该子程序的实现细节对BTS SFB302是隐 藏的。FifoSend为一个模块化子程序，它处理指定网络配置中BTS SFB302和CILB 310中FIFO之间数据的路由选择。由于有关数据路由 选择的实现细节被隐藏在子程序FifoSend中，故BTS SFB302可以作为 本地或远端相对于无线相关的SFB被配置，利用这些SFB，仅仅通过 修改子程序中的程序就可以进行通信。这些SFB本身及它们与CILB310 交互作用的方式对于不同的网络配置都基本上保持不变。当网络配置改 变时，这比起如现有技术所要求的修改用来实现(例如)BTS和无线相 关的块的大的多的SFB来说，简单多了。

虽然这里为了易于描述显示了一个FIFO，但应该提醒的是，还存 在有其它用于处理器间通信的方法。这些方法的例子包括使用共享存储 器，邮箱，总线协议(串行，并行，以及其它已知协议)等等。

一个通过消息传递便于与SFB来回通信的CILB的例子可以参照 CILB304来说明。当BTS SFB302想要与BSC SFB300通信时，它向一 个与由CILB304内的程序实现的Abis接口相关的已知邮箱发送消息。 如果消息传递在本地进行，正如BTS SFB302和BSC SFB300使用同一 CPU/机架的情况，则CILB304中的功能被编程以实现本地消息传递。 另一方面，当BTS SFB302远离BSC SFB300时，则CILB304中的功能 函数，其细节对于BTS SFB302和BSC SFB300是隐藏的，利用诸如 LAPD之类的工具，以便确保到预期邮箱的和从预期邮箱来的消息能被 进行远程发送或接收。注意到从BTS SFB 302和BSC SFB300方面来 看，它们与CILB304的相互作用基本上保持不变而不管这两个SFB在 一给定网络内是否被作为远端或本地来配置。还有，CILB304和发送 的SFB以及接收的SFB(例如BTS SFB302或BSC SFB300)之间的 接口基本上保持不变而不管连接到BSC SFB300的BTS SFB302的数 目。

在图5的具体例子中，MSC(未显示)在一个远离于实现BTS/BSC SFB的CPU/机架的CPU/机架上被实现。结果，CILB306必须便利于 进行远程通信。该远程通信在图5中被一个远程通信的SFB实现。在图 5的具体例子中，该远程通信的SFB通过利用包含A接口的(如GSM 标准08.06所述的SCCP  MTP1-3)网络接口控制器(NIC)321 并被NIC321中的E1 SFB来实现。应该牢记的是当BTS SFB远离BSC SFB(通过某物理中继线)时，NIC 321还可能实现Abis协议而起与 每个BSC SFB300和BTS SFB302相关的CILB的作用。

如果MSC在实现图5的BTS/BSC SFB的同一个CPU/机架上被实 现，则NIC 321将没有必要并且将被其它易于在BSC SFB300和其相关 的MSC SFB之间进行本地消息传递的功能所替代。注意到CILB306和 BSC SFB300或其相关的MSC SFB之间的接口基本上保持不变而不管 它们各自通过CILB306的通信是为本地的还是远程的。

应该牢记的是实现BSC SFB300，BTS SFB302及无线相关的 SFB312/314的程序优选地基本上保持不变而与网络配置无关。当网络配 置改变时，在CILB下面的功能函数被修改/替代以便为给定改变的网络 配置的数据正确地选择路由。

还有，实现在CILB下面的功能的程序，例如，那些支持A接口、 Abis接口或实现实时处理器(RTP)的程序可以与它们各自的 BSC/BTS SFB共同放在同一个CPU/机架上或者为适应蜂窝网络的处 理，地理位置，或区域要求所必须的而被放在远处的它们自己的CPU/ 机架。

图6A为一个框图，描述了两个SFB如BSC SFB350和BTS SFB352 之间的通信协议之间的关系，以及发生在它们之间的CILB内的实际数 据交换。注意到虽然BTS和BSC SFB被用于例子中，但本发明的CILB 适用于为任何两个SFB之间的通信提供便利而不管它们在网络中的相 对位置。

在图6A中，BSC SFB350藉使用Abis协议与BTS SFB352通信， 该Abis协议在图6A中被用虚线354概括性显示。由于在图6A的例子 中，BTS SFB352和SBC SFB350共同放在同一个CPU/机架上，故这 两个SFB之间的数据通信通过本地软件功能块(SFB)通信(这里称 “LSC”)，使用由接口线356下的CILB实现的原语来完成。该通信 在图6A中用线370来代表。

正如这里所使用的术语，本地SFB通信(LSC)是指在相同CPU/ 机架中的SFB之间的通信。LSC的基本功能包括，尤其是，在两个SFB 之间传递一个称为消息的信息单元。注意到，这种情况不管SFB是否处 于与同一个CPU内的分开的任务相同的任务中，或者与通过总线的分 开的CPU内的任务相同的任务中，或者与在一个局域网内连接的分开 的CPU上的任务相同的任务中。LSC可以利用操作系统(OS)下的 消息传递工具，其中OS对LSC在其上执行的CPU进行操作。这类OS 的例子为Unix，VxWorks及VTRX。

某些SFB可能需要面向连接的服务。面向连接的服务，在某种意义 上又被称为虚电路服务，它允许通信的SFB建立会话，在会话期间，与 该会话有关的消息可以在通信的SFB之间被传递。为了能使用该特征， LSC尤其支持会话的建立和终止以及与会话相关的消息。为了说明起 见，在附录C中显示了一个用于实现LSC和其各个SFB之间的A接口 的原语的实现。本领域技术人员将会看到，工业界熟知的这些原语，按 照所实现的特定接口(如ISDN等，)而改变。

作为例子，图6A显示了LSC设施353(a)和353(b)，该设 施便于通过线370进行通信。注意到由于图6A的SFB共同放在同一个 CPU/机架中，故不需任何中继资源。接口线356描述了CILB的与配置 无关的部分，即在接口线356以上的用一种与网络配置无关的一致的方 式与SFB进行交互作用的部分，以及在接口线356下面的CILB内的实 现细节。那些实现细节可以被修改以确保在特定网络配置中SFB之间的 正常的数据路由选择。

在图6B中，BSC SFB350和BTS SFB352被分布在不同的CPU/ 机架上。这两个SFB之间的通信依然较好地利用Abis协议(点划线 354)。然而，在CILB线356下的原语变成便于远程通信。为了易于 理解，原语可以被认为是便利于垂直上下堆栈的通信的函数。一种协议 由消息结构(语法)，语义和消息流来定义，并且在图6A和图6B中用 水平线来代表。一个协议栈可以被认为是一个应用层，这样每个应用层 完成一个在全部通信子系统范围内严格定义的功能。它按照定义的协议 通过与远端系统中对应的对等层交换消息(即用户数据和附加控制信 息)来工作。在每层与它紧接着的上下层之间每层都有一个严格定义的 接口。结果，一个特定的协议层的实现与所有其它层无关。在层和它紧 接着的上下层之间的通信是靠原语来实现的。

在图6B中的例子中，在第二层实现Abis栈361(a)和361(b) 的原语采用LAPD协议。正如所显示的，LAPD块364A和364B被作 为第二层实现并且E1设施被作为第一层来实现。相反，消息传递对于 在图6A配置中的本地通信来说是优选的通信范例。注意到在图6A和 图6B中接口线356上的原语360A和360B基本上保持不变。只有接口 线356下面的原语响应于网络配置中的变化而改变以确保适当的数据路 由选择。这样，关于实际数据路由选择的细节对于接收的和发送的SFB 来说是隐藏的。这样的数据隐藏使得SFB成为模块化，因此简化了这些 主要SFB的开发者的工作。

图7为一个框图，它用一个实施方案来具体说明一个便利于在SFB 之间用与配置无关的方式进行通信的消息传递范例。现在参照图7，上 面显示三个SFB400、402和404。SFB400、402和404中的每个SFB 可以根据用于完成某一功能的单个任务来进行具体说明，例如用来实现 BTS的一个程序块。举例来说，当网络中有多个BTS时，则需要多个 BTS任务的实例来实现所有BTS中的软件。虽然对于图7有关的讨论 不特别贴切，但应注意到程序400、402和404的软件功能块还可以表 示不同任务实现的程序块的实例。

在一个实施方案中，每个任务都与一个邮箱相关，其中邮箱的地址 对于所有需要与该任务的实例通信的SFB来说是已知的。正如这里所使 用的术语那样，邮箱表示一段存储器，消息可以被邮寄到该存储器中以 用于向前转发或检索。在该实施方案中，所有从一给定任务来具体说明 的SFB都与一个与该任务相关的邮箱相关。然而在另一个实施方案中， 每个SFB都与它自己的邮箱相关。注意到邮箱对于接收消息是必要的。 如果一个SFB仅仅发送消息，则邮箱就不完全有必要了。

为了在图7的SFB中间进行通信，为了向接收的SFB邮寄一个消 息、一个请求或一般数据，发送的SFB有必要知道接收的SFB用来实 现实例的任务的相关邮箱标识。注意到发送的SFB不必知道接收的SFB 在网络中的名字或特定位置。即使SFB为被执行的实体，并且可能存在 不止一个SFB与邮箱相关时也是如此。

作为例子，图5的一个BTS管理SFB(328)可能通过向与BTS 管理任务相关的邮箱发送消息来向一个特定BTS管理者SFB322(也在 图5中)邮寄消息。一直监视着该邮箱的目的BTS管理者SFB322，可 以从邮箱中拣出被邮寄的消息。根据消息的性质和内容，目的BTS管理 者SFB322可以向另一个邮箱转发该消息或者通过向与BTS管理任务相 关的邮箱邮寄另一个消息来答复。用于消息发送以及消息检索和处理的 伪码如图7所示。

在第一层，CILB还可能通过一个接口函数范例来实现。图8描述 了多个SFB怎样利用子程序库450的子程序来以与配置无关的方式进行 通信。根据接口函数范例，SFB452和454能调用子程序库450来动态 地或在连接时刻连接在子程序库中的那些SFB需要用来互相通信的子 程序。向子程序库450的函数调用例子包括调用用于发送消息、接收消 息、定时器管理、网络管理接口等的子程序。注意到每个子程序可以被 多个SFB使用。举例来说，一个读写文件的子程序可以被每个与盘驱动 器交互作用的SFB调用。

为了便利于与配置无关的通信，这些子程序被调用的方式最好是与 网络配置无关而基本上保持不变。还有，从发送的和接收的SFB来说， 数据如何被选择路由的实现细节最好是被隐藏在子程序中，那样，举例 来说，应用开发者们就能利用子程序而不需要了解它下面的数据路由选 择的细节并且不必考虑网络结构。当网络配置改变时，发送的或接收的 SFB，或它们与子程序的通信方式都基本上不必改变。只有对于发送的 和接收的SFB来说被隐藏在子程序中的数据路由选择细节需要修改以 确保在网络配置改变时进行适当的数据路由选择。很显然，由于主要的 SFB基本上保留不变，故本发明这个方面极大地简化了升级、维护以及 网络扩展。

图9A显示了一个用于SFB间通信的多层通信栈。在接口线500上 面，两个SFB(BSC SFB490和BTS SFB492)藉利用以虚线494代表 性地显示的应用层协议进行通信。协议由消息结构(语法)、语义以及 用于跨越图9A中堆栈进行通信的消息流来定义。注意虚线494不代表 BSC SFB 490和BTS SFB 492之间的实际数据通信路径。而是，这些 SFB访问作为用于沿着堆栈向下通信的函数的原语。原语利用CILB的 接口线500下面的层中的资源使得SFB之间便于通信。

在CILB的接口线500下面的数据路由选择被一个包括LAPD(由 虚线496代表性地显示)的多层堆栈实现，这使得LAPD SFB502(a) 和502(b)之间便于通信。在接口线500上面的原语包括CILB并且 最好基本上保持不变而不管这个接口线500下面的原语在一个特定网络 配置中是如何处理数据路由选择的。

在图9A的特定例子中，LAPD SFB502(a)和502(b)还利用原 语沿着堆栈向下与第一层SFB 504(a)和504(b)进行通信。这实 际上是在一个传输媒介上收发数据。接口线501表示LAPD层和物理层 之间的界线，在图9A的例子中物理层碰巧为E1。在图9A的例子中， 在接口线501下面的数据路由选择包括一个E1层(如线503所示)， 这使得E1 SFB间便于通信。如果使用T1作为物理层，则在接口线501 的SFB之间的通信优选地保持基本上不变。当T1取代E1时，在接口 线501下面仅仅是在接口线501正下方的数据路由选择细节需要改变。 很显然，在一个堆栈内一个较高的层和下一个较低的层之间可能存在严 格定义的接口以提高模块化及简化实现和改动(例如，在BTS SFB492 和LAPD SFB502(b)之间或在LAPD SFB502(b)和第一层SFB 504(b)之 间)。

注意到在原语本身之间的通信可以通过上述的消息传递范例或接 口函数范例来完成。作为例子，图9(a)中LAPD SFB502(a)和 第一层SFB504(a)(以及LAPD SFB502(b)和第一层SFB 504(b)) 之间的通信利用接口函数范例来进行它们的通信。另一方面，BSC SFB490和LAPD SFB502(a)之间(和类似的BTS SFB492和LAPD SFB502(b)之间)的通信利用消息传递来实现。

作为例子，图9B显示利用本发明的与配置无关的结构技术的一个 BSC SFB和一个MSC SFB之间的通信。

图10描述了用于不同SFB间通信的消息传递范例。在图10中，虽 然图5的BSC SFB300被作为一个例子使用，但应该牢记的是消息传递 范例可以被用来为任何能够通过邮寄消息来进行通信的SFB之间的与 配置无关的通信提供便利。作为例子，在BTS SFB，MSC SFB，无线 相关的SFB以及远程通信SFB间的通信还可以靠消息传递来实现。

图10显示了BSC SFB300，CILB306(它实现A接口)，以及 CILB 304(它实现Abis接口)。在BSC SFB300内部还显示了一个BSC 管理SFB，一个BTS管理者SFB，一个信道管理者SFB，以及一个越 区切换管理者SFB。BSC管理SFB实现操作，管理和执行(OA&M) 功能而BTS管理者SFB处理在BSC内与BTS有关的功能，如对各个 BTS进行配置。信道管理者SFB除了其它功能之外，处理在BTS内的 无线信道的分配。越区切换管理者SFB为越区切换准备和执行的目的而 保存BTS中单个无线频率和时隙的性能统计。每个上述的SFB与一个 有熟知地址的邮箱相关，其中可以从其它SFB向该邮箱邮寄消息。

显示了在CILB304内部的一个Abis接口SFB600，该接口利用Abis 协议实现对数据路由选择所必要的细节。Abis SFB600与一个地址也是 熟知的邮箱MBX4相关。类似地，CILB块306包括一个A接口 SFB602，它利用A接口实现对数据路由选择所必要的细节。A接口 SFB602与一个熟知地址的邮箱MBX1相关，其中可以从其它的SFB， 如BSC SFB 300内部的SFB向该邮箱邮寄消息。正如前面提到过的， 与一个SFB相关的邮箱可以特别与SFB本身相关或者与该SFB下的任 务相关，并且从该任务产生实例的所有SFB都与同一个邮箱相关。

在一个实施方案中，提供有与每个CPU有关的路由选择表。路由 选择表装有便于在特定网络配置中进行数据路由选择的信息。接着数据 路由选择信息可以被特定配置的CILB程序用来对从发送软件功能块接 收到的消息进行正确转发。在一个实施方案中，如果一个消息需要被邮 寄到与一个SFB相关的邮箱中，其中该SFB远离发送的SFB或远离多 个SFB，则发送的SFB发送其消息的方式在不同的网络配置中最好基 本上保持不变。特别是，发送的SFB对其消息标记地址的方式最好基本 上保持不变。

然而，当消息被从发送的SFB进行发送时，CILB中的程序使CPU 首先去查阅路由表，以决定是否有必要为消息选择路由送到与一个中间 处理程序相关的邮箱上。中间处理程序被编程以适合一个特定网络配置 并且它的数据路由选择细节对发送的和接收的SFB都是隐藏的，接着负 责把消息转发到网络中合适的目的邮箱上。

为了描述，图11显示了一个与一个CPU相关的路由选择表630的 例子，表中有两列，650和652。列650显示发送的SFB想要往其邮寄 消息的邮箱的身份标识。列652显示消息必须被首先邮寄到的与一个中 间处理程序有关的相应邮箱的身份标识。

作为例子，如果一个发送的SFB希望发送一个消息到邮箱MBX1， 则CILB中的程序使处理邮寄该消息的CPU首先查询路由选择表630 以决定该消息是否首先被发送到与一个中间处理程序相关的一个邮 箱。根据表630，到邮箱MBX1的消息应该首先被路由选择送到邮箱 MBY1。与邮箱MBY1相关的中间处理程序接着将根据它对特定网络配 置的了解来对消息进行路由选择。中间处理程序的使用在图12和图13 中被非常详细地分析。

注意到路由表和中间处理程序的使用对发送的和接收的SFB都有 益地隐藏了特定配置的数据路由选择细节。从发送的SFB的方面来看， 所需要做的是邮寄一个消息到目的邮箱，例如邮箱MBX1。关于与邮箱 MBX1相关的SFB相对于发送的SFB是否为远端或本地的知识以及该 消息在一给定网络配置中如何被路由选择的知识通过使用路由表630和 与邮箱MBY1相关的中间处理程序而被隐藏起来。

在一个实施方案中，如果发送的SFB和接收的SFB共同放在同一 个CPU/机架上，则在路由表中最好没有表项。如果对于接收的邮箱的 表项不在路由表中，则认为消息路由选择应该在本地而不需要调用中间 处理功能。在另一个实施方案中，为了一致，所有的邮箱都被列在路由 表630中。举例来说，那些远离发送的SFB的邮箱可以有相应的中间处 理邮箱而那些相对于发送的SFB来说为本地的邮箱，作为相应的邮箱， 有它们自己邮箱ID(身份标识)。还可以利用其它的路由方法来代替 路由表630。例如，基于生成树或利用Dykstra算法的路由选择一直被 考虑为合适的替代者。

图12描述了当BSC管理SFB700和A接口SFB602相互远离时， 在这两个SFB之间的通信，如图12所示，A接口SFB602被在与CCPU 卡704分开的E1卡702上实现。对于与CCPU卡有关的进一步信息， 可以参考前面提到过的共同未决的专利申请WAVEP001.P， 08/434,554,08/434,598，和08/434,597。CCPU卡704和E1卡702之间 的联系，通过一个先进先出(FIFO)块706可很方便地被提供。虽然 并不是完全需要，但FIFO块706最好是在E1卡702本身上实现。

在图12的实施方案中，显示有用于通过FIFO706进行远程通信的 中间处理功能块708和710。中间处理功能块708处理与CCPU卡704 的通信而中间处理功能块710为与E1卡702的通信提供便利。当A接 口SFB602希望向BSC管理软件功能块700邮寄消息时，它发送一个消 息到与BSC管理软件功能块700相关的邮箱，即邮箱MBX2。在消息 被路由选择到邮箱MBX2之前，E1卡702上的CPU首先查询路由表 714以决定是否首先把消息邮寄到与一个中间处理功能相关的邮箱去 (正如目的SFB在远端或如果同样的任务有多个实例的情况)。

路由表714典型地被存储在机架上的永久存储器中，例如硬盘，快 闪存储器等(如图12中用元件712表示)。一个路由表的实例如图12 中表714所示。路由表714表明被邮寄到邮箱MBX2的消息应首先被邮 寄到邮箱MBX21，如图12中所示，该邮箱MBX21与中间处理功能块 708相关。因此，消息将首先被选择路由送到邮箱MBX21。发送到邮 箱MBX21的消息最好包括关于消息的最后目的地的信息，即邮箱 MBX2的身份标识。

中间处理功能块708，它监测着与邮箱MBX21有关的地址，接着 检索来自邮箱MBX21的消息并把它转发到FIFO706以便由中间处理功 能块710接着进行检索。利用在被检索的消息中的目的邮箱MBX2，中 间处理功能块710接着查询路由表718以决定如何对它刚刚从FIFO块 706检索到的消息进行最佳路由选择。路由表718最好被保存在CCPU 卡704上的永久存储器中(如元件717所示)。

由于邮箱MBX2驻留在CCPU卡704上，故在路由表718中不需 要任何表项。结果是，由中间处理功能块710对路由表718的查询将不 显示从FIFO块706检索到的消息应被转发到的相应的邮箱。中间处理 功能块710利用由BSC管理SFB700检索的本地数据路由选择把从 FIFO块706检索到的消息直接转发到在同一CPU/机架中的邮箱MBX2 上。

在相反方向上，BSC管理SFB700可以通过首先查询路由表718向 与A接口SFB602相关的邮箱MBX1发送消息，路由表718引导消息被 路由选择到邮箱MBX20。那个消息接着被中间处理功能块710拣出并 被转发到由中间处理功能块708检索的FIFO706。利用检索到的消息中 的目的邮箱MBX1，中间处理功能块708接着查询路由表714，它显示 被邮寄到邮箱MBX1的消息从中间处理功能块708的方面来看为本地消 息，导致该消息在本地靠消息传递被转发到邮箱MBX1。  

A接口SFB602，它监测着邮箱MBX1的地址，接着把消息拣出。 注意到就A接口SFB602和BSC管理SFB700而言，被发送消息的格式 及目的邮箱的地址不必为适应网络配置中的变化而改变。关于用特定配 置方式进行数据路由选择的内部细节由中间处理功能块708和710藉利 用它们相关的路由表714和718以及由FIFO706来处理。

在图12中，虽然BSC管理SFB和A接口SFB被用来描述本发明 的与配置无关的结构，但应该注意到任何能通过消息传递进行通信的 SFB都可以被那样实现。

图13描述了一单个BSC管理SFB800和在三个分离的CCPU卡上 实现的三个BTS管理者SFB804,  806和808之间的通信。BTS管理 者任务的多个实例可以存在于不同的CPU中以处理不同的BTS子集， 从而增加单个BSC能管理的BTS总数。作为例子，BTS管理者SFB804 可以对BTS1到6进行处理，BTS管理者SFB806可以对BTS7到12 进行处理，BTS管理者SFB808可以对BTS 13到18进行处理。注意到 BTS管理者任务的每个实例一般能处理有限数量的BTS。随着容量增 加，BTS被增加而且额外的BTS管理者SFB也必须被增加以便于调节 规模。虽然图13中只显示三个BTS管理者SFB，但根据网络区域和容 量要求当然可以提供更多或更少数目的SFB。

由于BTS管理者SFB804，806，808为独立配置，相互不了解， 故它们本身都同一个邮箱MBX6相关。在图13中，BSC管理SFB 800 与可能被分布在多个CPU/机架上的所有BTS管理者SFB进行通信。然 而，重要的是，从BSC管理SFB800来的消息被转发到正确的实例而与 网络配置无关。在上面例子的情况中，重要的是，用于BTS5的消息被 转发到BTS管理者SFB804(在CCPU2上实现)而不管这个BTS管理 者SFB是在网络中何处被实现的。

举例来说，考虑BSC管理SFB800和控制BTS 8的BTS管理者 SFB806之间的通信。由于BTS管理者SFB806相对于实现BSC管理块 800的卡CCPU1是在远端，故中间处理功能被用来处理特定配置的数 据路由选择细节。为了说明，卡CCPU1提供一个BTS管理者中间处理 功能块810。BTS管理者中间处理功能块810与一个地址在路由表820 中已知的邮箱MBX22相关。

当BSC管理SFB800希望发送一个消息到BTS管理者SFB806时， 它仅仅把一个消息邮寄到一个与对BTS管理者SFB806具体实现的任务 相关的邮箱，即邮箱MBX6上。注意到BSC管理SFB800不必为了邮 寄消息到已知地址的邮箱MBX6而了解特定网络配置的数据路由选择 细节。

与卡CCPU1相关的CPU接着查询路由表820，该表显示邮寄到邮 箱MBX6的消息应被路由选择而送到与BTS管理者中间处理功能块810 相关的邮箱MBX22。结果，想要给邮箱MBX6的消息被转发到邮箱 MBX22。

BTS管理者中间处理功能块810，它监视着与邮箱MBX22有关的 地址，接着拣出消息并查询另外的路由表830，该表显示处理BTS 8的 BTS管理者SFB仍留在CCPU3上。BTS管理者中间处理功能块810 接着把消息转发给卡CCPU3，或者更具体地，转发到在CCPU3上的 CCPU中间处理功能块832。

CCPU3上的CPU接着查询路由表840，该表显示邮箱MBX6在与 中间处理功能832一样的同一CCPU上实现。因此CCPU中间处理功 能832到邮箱MBX6的通信是本地的，这在一个实施方案中可以用消息 传递来实现。BTS管理者SFB 806，它监视着与邮箱MBX6有关的地 址，接着把消息拣出。

在另一个方向上，当BTS管理者SFB804希望向BSC管理SFB800 发送消息时，它向邮箱MBX2发送该消息，MBX2与BSC管理任务相 关并且有已知地址。运行BTS管理者SFB804的CPU首先查询路由表 850，该表显示送往邮箱MBX2的消息应该首先被路由选择到与CCPU 中间处理功能852相关的邮箱MBX23。在一个实施方案中，路由表840 和850基本上类似。

CCPU中间处理功能块852，它监视着邮箱MBX23的地址，接着 拣出消息并把它转发给BTS管理者中间处理功能块810。CCPU1卡上 的CPU接着查询它的相关路由表830，该表显示邮箱MBX2(从消息 的内容知道消息将被送往邮箱MBX2)对于CCPU1卡为本地的。因此， 消息以本地方式被转发到CCPU卡上的邮箱MBX2，这种方式在一种 实施方案中可以是消息传递以便由BSC管理SFB800检索。

注意到图10的结构模型依然坚持不变而不管BTS管理者是否如图 13所示被放在远处的不同的CCPU上、它们都被在一个相对于BSC管 理SFB800的远端CCPU卡上实现、或者它们都与BSC管理SFB800共 同放在同一个CPU/机架上。为了向一特定BTS管理者SFB发送消息， BSC管理SFB800所需要做的是把那些消息邮寄到一个已知的BTS管理 者邮箱，即MBX6。在一个特定网络配置中如何在CCPU卡之间对数 据进行路由选择的相关内部细节由中间处理功能来处理。

当系统配置改变时，只是中间处理功能程序被改变。无论是构成 BSC管理SFB800、BTS管理者SFB804、806和808的程序还是这些 SFB对它们消息的地址标识方式都没有必要改变。还有，从SFB方面来 看BSC管理SFB800和BTS管理者SFB之间的通信是一致的而与网络 配置无关。

虽然为了理解清楚，上述发明被详细介绍，但很显然在附属的权利 要求范围内可以进行某些改变和修改。作为例子，虽然这里主要针对 GSM系统来讨论本发明，但应该注意到本发明并不限于此。特别期待 的是，这里所公布的本发明的与配置无关的结构在系统中可以用其它特 定协议来实现。结果，本发明的范围并不限于在这里给定的特定例子而 是在附属的权利要求中被陈述。

                    附录A

术语和缩略语汇编

Abis：        BTS和BSC之间的协议堆栈

API：         应用程序接口

BCF：         基站控制功能

BSC：         基站控制器

BSS：         基站子系统

BTS：         基站收发信台

CC：          呼叫控制管理

CCPU：        蜂窝CPU

cPBX：        蜂窝专用小交换机

CILB：        与配置无关的连接块

DSP：         数字信号处理

GMSC：        MSC网关    

GSM：         全球移动通信系统

HLR：         归属位置寄存器

ISDN：        综合业务数字网

LAPD-M：      Dm(控制)信道的链路访问协议

LSC：         本地软件功能块通信

MM：          移动管理

MS：          移动站

MSC：         移动业务交换中心

PSTN：        公共交换电话网

PBX：        专用小交换机

RF：         射频模块

RL：         无线链路

RR：         无线资源管理

SCCP：       信令连接控制部分

SFB：        软件功能块

SMS：        短消息业务

SS：         补充业务

TDM data：   时分复用数据

TRAU：       码型转换和速率适配单元

TRX：        收发信机

VLR：        访问者位置寄存器

VME：        一种用于元件互连的工业标准总线

wPBX：       有线PBX

                         附录B

为了本领域技术人员易于理解，叙述了本公布的内容。对于其它， 下列文献，在此引用，供所有目的作参考，可以被用来回顾附加的信息。

Mouly，Michel & Pautet，Marie-Bernadette，“用于移动通信的GSM 系统”“Mouly，Michel & Pautet，Marie-Bernadette，1992。

欧洲电信标准协会，“欧洲数字蜂窝电信系统(第二阶段)：移动 无线接口信令第3层概况(GSM 04.07)”1994，Valbonne-法国。

欧洲电信标准协会，“欧洲数字电信系统(第二阶段)：移动无线 接口第3层规范(GSM04.08)”1994，Valbonne-法国。

欧洲电信标准协会，“欧洲数字蜂窝电信系统(第二阶段)：移动 业务交换中心-基站系统(MSC-BBS)接口第3层规范(GSM 08.08)”1994，Valbonne-法国。

欧洲电信标准协会，“欧洲数字蜂窝电信系统(第二阶段)：基站 系统-移动业务交换中心(BBS-MSC)接口的信令传输机制规范 (GSM 08.06)”1994，Valbonne-法国。

欧洲电信标准协会，“欧洲数字蜂窝电信系统(第二阶段)：基站 控制器-基站收发信台(BSC-BTS)接口第3层规范(GSM 08.05)”1994，Valbonne-法国。

欧洲电信标准协会，“欧洲数字蜂窝电信系统(第二阶段)：移动 应用部分(MAP)规范(GSM 09.02)”1994，Valbonne-法国。

欧洲电信标准协会，“欧洲数字蜂窝电信系统(第二阶段)：在综 合业务数字网(ISDN)或公共交换电话网(PSTN)与公用陆地移动 网(PLMN)之间的互连网络上的信令要求(GSM 09.03)” 1994，Valbonne-法国。

                          附录C

#ifndef_SS7_IF_H #define_SS7_IF_H /* *Copyright(c)1994，1995 * interWAVE Communications Inc，Redwood City，CA USA.All rights reserved. * * @(#)$Header：/cvs/iw/include/ss7_if.h，v 1.5 1995/09/14 21：01：03 phc Exp $ * *DESCRIPTION：Structure definitions that define the messages that go * between NMI & trillium stack. */ extern int ss7_msc_mbx； #define SS7_SENDMSG(msg)(ss7_msc_mbx＝＝MBX_SS7_IF)？\ E1MsgSend(ss7_slot，MBX_SS7_IF，\ MEDIUM_PRIORITY，(tIwMsgHdr*)msg)：\ IwMsgSend(ss7_msc_mbx，MEDIUM_PRIORITY，\ 　　 (tIwMsgHdr*)msg) #define SS7_NULL_SPID (0xffff) #define SS7_NULL_SUID (0xffff) #define SS7_NULL_SSN (0xffff) #define SS7_NULL_PC (0xffffffff) #define SS7_SP_CFG_REQ(1) #define SS7_SN_CFG_REQ(2) #define SS7_SD CFG_REQ(3) #define SS7_QI_CFG_REQ(4) #define SS7_PWR_UP (6) /*Following messages go from SS7 stack to the IWP*/ #define SS7_SP_UDAT_IND (7) #define SS7_SP_UI_STA_IND (8) #define SS7_SP_CORD_IND (9) #define SS7_SP_CORD_CFM (10) #define SS7_SP_STE_IND(11) #define SS7_SP_PC_STE_IND(12) #define SS7_SP_CON_IND(13) #define SS7_SP_CON_CFM(14) #define SS7_SP_DAT_IND(15) #define SS7_SP_EDAT_IND (16) #define SS7_SP_DAT_ACK_IND(17) #define SS7_SP RST_IND(18) #define SS7_SP RST_CFM(19) #define SS7_SP_DIS_IND(20) #define SS7_SP_INF_IND(21) /*Following message go from IWP to the SS7 stack*/ #define SS7_SP_BND_REQ(22) #define SS7_SP_UBND_REQ (23) #define SS7_SP_UDAT_REQ (24) #define SS7_SP_CORD_REQ (25) #define SS7_SP_CORD_RSP (26) #define SS7_SP_STE_REQ(27) #define SS7_SP_CON_REQ(28) #define SS7_SP_CON_RSP(29) #define SS7_SP_DAT_REQ(30) #define SS7_SP_DAT_ACK_REQ(31) #define SS7_SP_EDAT_REQ (32) #define SS7_SP_RST_REQ(33) #define SS7_SP_RST_RSP(34) #define SS7_SP_DIS_REQ(35) #define SS7_SP_INF_REQ(36) #define SS7_SP_STA_REQ(37) #define SS7_SP_STA_IND(38) #define SS7_SP_STA_CFM(39) #define SS7_SP_STS_REQ(40) #define SS7_SP_STS_CFM(41) #define SS7_SN_STA_REQ(41) #define SS7_SN_STA_IND(42) #define SS7_SN_STA_CFM(43) #define SS7_SN_STS_REQ(44) #define SS7_SN_STS_CFM(45) #define SS7_SD_STA_REQ(45) #define SS7_SD_STA_IND(46) #define SS7_SD_STA_CFM(47) #define SS7_SD_STS_REQ(48) #define SS7_SD_STS_CFM(49) #define SS7_QI_STA_REQ(50) #define SS7_QI_STA_IND(51) #define SS7_QI_STA_CFM(52) #define SS7_QI_STS_REQ(53) #define SS7_QI_STS_CFM(54) #define CP_TRIL_CONID(ss7_con，tril_con)\ 　　 {(ss7_con)-＞suId＝(tril_con)-＞suId；\ 　　 (ss7_con)-＞spId＝(tril_con)-＞spId；\ 　　 (ss7_con)-＞suInstId＝(tril_con)-＞suInstId；\ 　　 (ss7_con)-＞spInstId＝(tril_con)-＞spInstId；} #define CP_SS7_CONID(tril_con，ss7_con)\ 　　 {(tril_con)-＞suId＝(ss7_con)-＞suId；\ 　　 (tril_con)-＞spId＝(ss7_con)-＞spId；\ 　　 (tril_con)-＞suInstId＝(ss7_con)-＞suInstId；\- 　　 (tril_con)-＞spInstId＝(ss7_con)-＞spInstId；} *define CP_SS7_ADDR(tril_adr，ss7_addr)\ 　　 {(tril_adr)-＞ssn＝(ss7_addr)-＞ssn；\ 　　 (tril_adr)-＞pc＝(ss7_addr)-＞pc；\ 　　 (tril_adr)-＞pres＝(ss7_addr)-＞valid；\ 　　 (tril_adr)-＞sw＝SW_CCITT；\ 　　 (tril_adr)-＞niInd＝INAT_IND；\ 　　 (tril_adr)-＞rtgInd＝RTE_SSN；\ 　　 (tril_adr)-＞ssnInd＝(ss7_addr)-＞valid；\ 　　 (tril_adr)-＞pcInd＝(ss7_addr)-＞valid；\ 　　 (tril_adr)-＞gt.format＝GTFRMT_0；} #define CP_TRIL_ADDR(ss7_adr，tril_addr)\ #define SIZE_SS7_SN_STS_CFM(sizeof(tss7_sn_sts_cfm))
#endif #ifdefSD typedef struct{ 　　 tIwMsgHdr Hdr； 　　 SdMngmt mgmt； }tss7_sd_cfg； #define SIZE_SS7_SD_CFG(sizeof(tss7_sd_cfg)) typedef struct{ 　 tIwMsgHdr Hdr； 　　 SdMngmt sta； }tss7_sd_sta_req； #define SIZE_SS7_SD_STA_REQ(sizeof(tss7_sd_sta_req)) typedef struct{ 　　 tIwMsgHdr Hdr； 　　 SdMngmt sta； }tss7_sd_sta_ind； #define SIZE_SS7_SD_STA_IND (sizeof(tss7_sd_sta_ind)) typedef struct{ 　　 tIwMsgHdr Hdr； 　　 SdMngmt sta； }tss7_sd_sta_cfm； #define SIZE_SS7_SD_STA_CFM(sizeof(tss7_sd_sta_cfm)) typedef struct{ 　　 tIwMsgHdr Hdr； 　　 SdMngmt sts； }tss7_sd_sts_req； #define SIZE_SS7_SD_STS_REQ (sizeof(tss7_sd_sts_req)) typedef struct { 　　 tIwMsgHdr Hdr； 　　 SdMngmt sts； }tss7_sd_sts_cfm； #define SIZE_SS7_SD_STS_CFM(sizeof(tss7_sd_sts_cfm)) #endif #ifdef QI typedef struct{ 　　 tIwMsgHdr Hdr； 　　 QiMngmt mgmt； }tss7_qi_cfg； #define SIZE_SS7_QI_CFG(sizeof(tss7_qi_cfg)) typedef struct{ 　　 tIwMsgHdr Hdr； 　　 QiMngmt sta； }tss7_qi_sta_req； #define SIZE_SS7_QI_STA_REQ(sizeof(tss7_qi_sta_req)) typedef struct{ 　　 tIwMsgHdr Hdr； 　　 QiMngmt sta； }tss7_qi_sta_ind； #define SIZE_SS7_QI_STA_IND(sizeof(tss7_qi_sta_ind)) typedef struct { 　　 tIwMsgHdr Hdr； 　　 QiMngmt sta； }tss7_qi_sta_cfm； #define SIZE_SS7_QI_STA_CFM(sizeof(tss7_qi_sta_cfm)) typedef struct { 　　 tIwMsgHdr Hdr； 　　 QiMngmt sts； }tss7_qi_sts_req； #define SIZE_SS7_QI_STS_REQ(sizeof(tss7_qi_sts_req)) typedef struct{ 　　 tIwMsgHdr Hdr； 　　 QiMngmt sts； }tss7_qi_sts_cfm； #define SIZE_SS7_QI_STS_CFM(sizeof(tss7_qi_sts_cfm)) #endif 　　 {(ss7_adr)-＞valid＝(tril_addr)-＞pres &(tril_addr)-＞ssnInd & \ 　　 (tril_addr)-＞pcInd；\ 　　 (ss7_adr)-＞ssn＝(tril_addr)-＞ssn；\ 　　 (ss7_adr)-＞pc＝(tril_addr)-＞pc；} #ifdef SP typedef struct{ 　　 tIwMsgHdr Hdr； 　　 SpMngmt mgmt； }tss7_sp_cfg； #define SIZE_SS7_SP_CFG(sizeof(tss7_sp_cfg)) typedef struct{ 　　 tIwMsgHdr Hdr； 　　 SpMngmt sta； }tss7_sp_sta_req； #define SIZE_SS7_SP_STA_REQ(sizeof(tss7_sp_sta_req)) typedef struct{ 　　 tIwMsgHdr Hdr； 　　 SpMngmt sta； }tss7_sp_sta_ind； #define SIZE_SS7_SP_STA_IND(sizeof(tss7_sp_sta_ind)) typedef struct{ 　　 tIwMsgHdr Hdr； 　　 SpMngmt sta； }tss7_sp_sta_cfm； #define SIZE_SS7_SP_STA_CFM(sizeof(tss7_sp_sta_cfm)) typedef struct{ 　　 tIwMsgHdr Hdr； 　　 SpMngmt sts； }tsss7_sp_sts_req； #define SIZE_SS7_SP_STS_REQ(sizeof(tss7_sp_sts_req)) typedef struct{ 　　 tIwMsgHdr Hdr； 　　 SpMngmt sts； }tss7_sp_sts_cfm； #define SIZE_SS7_SP_STS_CFM(sizeof(tss7_sp_sts_cfm)) #endif #ifdef SN typedef struct{ 　　 tIwMsgHdr Hdr； 　　 SnMngmt mgmt； }tss7_sn_cfg； #define SIZE_SS7_SN_CFG(sizeof(tss7_sn_cfg)) typedef struct { 　　 tIwMsgHdr Hdr； 　　 SnMngmt sta； }tss7_sn_sta_req； #define SIZE_SS7_SN_STA_REQ(sizeof(tss7_sn_sta_req)) typedef struct{ 　　 tIwMsgHdr Hdr； 　　 SnMngmt sta； }tss7_sn_sta_ind； #define SIZE_SS7_SN_STA_IND(sizeof(tss7_sn_sta_ind)) typedef struct{ 　　 tIwMsgHdr Hdr； 　　 SnMngmt sta； }tss7_sn_sta_cfm； #define SIZE_SS7_SN_STA_CFM(sizeof(tss7_sn_sta_cfm)) typedef struct{ 　　 tIwMsgHdr Hdr； 　　 SnMngmt sts； }tss7_sn_sts_req； #define SIZE_SS7_SN_STS_REQ(sizeof(tss7_sn_sts_req)) typedef struct{ 　　 tIwMsgHdr Hdr； 　　 SnMngmt sts； }tss7_sn_sts_cfm； typedef struct { 　　 tIwMsgHdr Hdr； 　　 u16 suId； 　　 u16 spId； 　　 u16 ssn； 　　 u8 type； }tss7_sp_bnd_req； #define SIZE_SS7_SP_BND_REQ(sizeof(tss7_sp_bnd_req)) typedef struct{ 　　 tIwMsgHdr Hdr； 　　 u16 spId； 　　 u16 reason； }tss7_sp_ubnd_req； #define SIZE_SS7_SP_UBND_REQ(sizeof(tss7_sp_ubnd_req)) typedef struct{ 　　 tIwMsgHdr Hdr； 　　 u16 status； }tss7_pwr_up； #define SIZE_SS7_PWR_UP(sizeof(tss7_pwr_up)) typedef struct{ 　　 u16 valid； 　　 u16 ssn； 　　 u32 pc； }tss7_sp_addr； #define SIZE SS7_SP_ADDR(sizeof(tss7_sp_addr)) typedef struct{ 　　 tIwMsgHdr Hdr； 　　 u16 SpId； 　　 tss7_sp_addr Cd； /*Called Address*/ 　　 tss7_sp_addr Cg； /*Calling Address*/ 　　 u16 Len； /*Length of Data Field*/ 　　 u8 Data[0]； }tss7_sp_udat_req； #define SIZE_SS7_SP_UDAT_REQ(len)(sizeof(tss7_sp_udat_req)+len) typedef struct{ 　　 tIwMsgHdr Hdr； 　　 u16 SuId； 　　 u32 OPc； /*Originating Point Code*/ 　　 tss7_sp_addr Cd； /*Called Address*/ 　　 tss7_sp_addr Cg； /*Calling Addrress*/ 　　 u16 Len； /*Length of Data Field*/ 　　 u8 Data[O]； }tss7_sp_udat_ind； #define SIZE_SS7_SP_UDAT_IND(len)(sizeof(tss7_sp_udat_ind)+len) typedef struct{ 　　 u16 suId； 　　 u16 spId； 　　 u32 suInstId； 　　 u32 spInstId； }tss7_sp_conid； #define SIZE_SS7_CONID(sizeof(tss7_conid)) typedef struct{ 　　 tIwMsgHdr Hdr； 　　 tss7_sp_conid ConId； 　　 tss7_sp_addr Cd； /*Called Address*/ 　　 tss7_sp_addr Cg； /*Calling Addrress*/ 　　 u16 Len； 　　 u8 Data[O]； }tss7_sp_con_req； #define SIZE_SS7_SP_CON_REQ(len) (sizeof(tss7_sp_con_req)+len) typedef struct{ 　　 tIwMsgHdr Hdr； 　　 tss7_sp_conid ConId； 　　 tss7_sp_addr Cd； 　　 tss7_sp_addr Cg； 　　 u16 Len； 　　 u8 Data[O]； }tss7_sp_con_ind； #define SIZE_SS7_SP_CON_IND(len) (sizeof(tss7_sp_con_ind)+len) typedef struct { 　　 tIwMsgHdr Hdr； 　　 tss7_sp_conid ConId； 　　 tss7_sp_addr RspAdr； 　　 u16 Len； 　　 u8 Data[O]； }tss7_sp_con_rsp； #define SIZE_SS7_SP_CON_RSP(len) (sizeof(tss7_sp_con_rsp)+len) typedef struct{ 　　 tIwMsgHdr Hdr； 　　 tss7_sp_conid ConId； 　　 tss7_sp_addr RspAdr； 　　 u16 Len； 　　 u8 Data[O]； }tss7_sp_con_cfm； #define SIZE_SS7_SP_CON_CFM(len) (sizeof(tss7_sp_con_cfm)+len) typedef struct{ 　　 tIwMsgHdr Hdr； 　　 tss7_sp_conid ConId； 　　 tss7_sp_addr RspAdr； 　　 u8 Reason； 　　 u8 Orig； 　　 u16 Len； 　　 u8 Data[O]； }tss7_sp_dis_req； #define SIZE_SS7_SP_DIS_REQ(len) (sizeof(tss7_sp_dis_req)+len) typedef struct { 　　 tIwMsgHdr Hdr； 　　 tss7_sp_conid ConId； 　　 tss7_sp_addr RspAdr； 　　 u8 Reason； 　　 u8 Orig； 　　 u16 Len； 　　 u8 Data[O]； }tss7_sp_dis_ind； #define SIZE_SS7_SP_DIS_IND(len) (sizeof(tss7_sp_dis_ind)+len)
typedef struct { 　　 tIwMsgHdr Hdr； 　　 tss7_sp_conid ConId； 　　 u16 Len； 　　 u8 Data[O]； }tss7_sp_dat_req； #define SIZE_SS7_SP_DAT_REQ(len) (sizeof(tss7_sp_dat_req)+len) typedef struct{ 　　 tIwMsgHdr Hdr； 　　 tss7_sp_conid ConId； 　　 u16 Len； 　　 u8 Data[O]； }tss7_sp_dat_ind； #define SIZE_SS7_SP_DAT_IND(len) (sizeof(tss7_sp_dat_ind)+len) extern u32 ss7_slot； /*Slot of the E1 card that holds the ss7 stack*/ extern u16 bssap_spid； extern u16 bssap_suid； extern u16 bssap_ssn； extern u32 them_pc； extern u32 us_pc； extern int ss7_sp_bnd_req(u16 suId，u16 spId，u16 ssn，u8 type)； extern int ss7_sp_ubnd_req(u16 spId，u8 reason)； extern int ss7_sp_udat_req(u16 spId，tss7_sp_addr*cd，tss7_sp_addr*cg， 　　 u16 len，u8*data)； extern int ss7_sp_con_req(tss7_sp_conid*conid，tss7_sp_addr*cd， 　　 tss7_sp_addr*cg，u16 len，u8*data)； extern int ss7_sp_con_rsp(tss7_sp_conid*conid，tss7_sp addr*rsp，u16 len， 　　 u8*data)； extern int ss7_sp_dat_req(tss7_sp_conid*conid，u16 len，u8*data)； extern int ss7_sp_dis_req(tss7_sp_conid*conid，tss7_sp_addr*rsp，u8 reason， 　　 u8 originator，u16 len，u8*data)； #endif/*_SS7_IF_H*/

下列共同未决的P.C.T.及U.S.专利申请在此引用作为参考：

“蜂窝专用小交换机”(代理人的文档(Attorney’s Docket) No.WAVEP001.P.P)一项在1996年5月3日在美国受理局PCT(专 利合作条约)下提交的国际专利申请(在下文称WAVEP001.P)

“用于智能交换的方法和设备”(代理人的文档号为 WAVEP004.P.P)一项在1996年5月3日在美国受理局PCT下提交的 国际专利申请(在下文称WAVEP004.P)

“混合蜂窝通信设备和方法”(代理人的文档号为WAVEP003 +.P)一项在1996年5月3日在美国受理局PCT下提交的国际专利申 请(在下文称WAVEP003+.P)

“扩频通信网络信号处理器”作为美国专利申请在1995年5月4 日在U.S.PTO提交的U.S.S/N 08/434,554，代理人的文档号为A-60910 (在下文称U.S.S/N08/434,554)

“采用智能呼叫选路的蜂窝基站”作为美国专利申请在1995年5 月4日在U.S.PTO提交的S/N 08/434,598，代理人的文档号为A-61115 (在下文称U.S.S/N08/434,598)

“具有自适应的频率灵活性的扩频通信网络”作为美国专利申请在 1995年5月4日在U.S.PTO提交的，S/N 08/434,597，代理人的文档号 为A-60820(在下文称U.S.S/N 08/434,597)    

为了便于参考，附录A提供了术语和缩略语的汇编。

                      发明背景