实施例的详细描述
在图1中，表示了一个ATM信元，包括字头2和有效负荷3。一
般有效负荷包括与单个连接有关的用户数据。在前述的
PCT/SE95/00575专利文件中揭示了一种ATM信元，在其有效负荷中
携带一个或多个微信元。在图1所示的例子中，表示了不同大小的三
个微信元4、5及6。ATM字头2包括5个八比特组(1八比特组=8
比特=1字节)，其有效负荷3包括48个八比特组。每个微信元4、5、
6包括字头7和用户数据。
在图2中，表示了微信元字头7的一个例子，包括2个八比特组
8、9。其它大小的微信元字头根据ATM系统的设计也是可能的。3个
八比特组或更多的微信元字头大小也是可能的。微信元字头7包括线
路标识符CID--标识已建立的连接/线路，有效负荷类型选择器PTS
--标识不同的有效负荷类型，例如用户数据、控制数据、维护数据、
长度标识符LEN，以及字头完整性检验域/比特HIC--检查字头的完
整性。长度标识符LEN定义单个微信元有效负荷的大小。
需要区分不同类型的微信元。下面是表示PTS域所需的：
固定长度的用户信息：字头中的长度标识符是不必要的，而是将
用户信息长度配置到系统和业务中。例如“GSM全速率”，用户信息
长度是35个八比特组，PDC全速率，是20个八比特组，而“D-AMPS
全速率”是23个八比特组。
不同长度的用户信息，即，变长的用户信息：这是优选的实施例，
将在下面描述。为了表示变长的用户信息而使用PTS域是将来要验证
的方案。
扩展长度的不同长度用户信息。每线路/连接的OAM信息。
同步信息：为此目的使用PTS域是可选的。
在图3中，表示信元字头7包括固定大小的长度域10，称为LEN
域，用于表示字头所属的微信元的用户数据大小。微信元大小在该域
10中用线性编码来表示。线性编码意味着该码对应于微信元的实际
大小。例如，如果信元长度是5个八比特组，就将二进制5(000101)
写入LEN域。微信元长度较短时，固定长度域10将占据大部分带宽，
所有被占据的带宽并非用于传输有用的信息，例如所给出的两个例子
中的前导0。应该注意的是，LEN域10由单个连接的每个微信元所携
带。与固定大小LEN域10有关的另一个缺陷是，用线性编码表示的
信元大小范围是受限的。对于由6比特组成的固定大小LEN域10，
可以表示从1到64个八比特组的信元大小。一旦一个单个连接使用
了较大的信元大小，固定大小长度域10的长度就必须扩大，又导致
带宽更多的浪费。
在图4中表示了固定大小长度域11。使用非线性编码表示很宽范
围的不同信元大小。在例子中，给出的3个比特用于微信元字头的一
个八比特组，例如八比特组9中。同一八比特组中的其余比特是空闲
的，并且可以用于上面所列的任何目的。这样就减少了字头的整个大
小，进而增加了所使用带宽的效率。
在移动电话系统中，微信元由语音编码器产生。现在，当前的IS
95语音编码器使用2、5、10或22个八比特组。使用根据所述ANSI
文件的固定大小长度域10，在微信元的字头中需要7比特，以便表
示22个八比特组的信元大小。使用根据图4的非线性编码，固定大
小长度域11为3比特。这样一个工作在2kbps(每20ms 5个八比特
组)的IS 95语音编码器就节省了10％的带宽。
在图5中表示了一个映射表12，与固定大小长度域11一起使用。
从表中可见，编码值不对应于微信元大小，而是分配给各个编码值的
预定信元大小，因此只需要三个编码比特。在映射列表的大小一栏中
给出了微信元大小的例子。大小从4个变化到60个八比特组。显然，
范围扩大了，但是大小的最大个数是由所使用的编码比特数给出的。
为了扩大与非线性编码一起使用的大小的数目，可以按需要扩展
固定LEN域11。将描述两种方法。一种是固定大小LEN域11中的扩
展比特用作LEN域11扩展的限定，该方法称为扩展比特方法，另一
种是一个长度域码用作LEN域11扩展的限定，在这种情况下该方法
称为扩展码方法。
在图6中，比特13，也标为E，在LEN域11之后留做扩展比特
13。当扩展比特13设置为1时，表示微信元字头包括与固定大小LEN
域同样大小的扩展LEN域14。当扩展比特为0时，信元字头只包括
固定LEN域11。
在所示例子中，扩展的长度域14包括3比特。
当扩展比特13设置时，映射表12可用的比特数从3增加到6比
特，得到图7所示的映射表15。由于扩展比特13是为此目的保留的，
它不能用于码大小映射的目的。
扩展比特方法的变化是对扩展的LEN域14添加扩展比特11B。添
加的扩展域用于表示微信元字头中是否还有扩展的LEN域。如果添加
的扩展比特11B设为1，表示第二扩展长度域14A将添加到字头中，
因此表15中的码比特数从6增加到9。如果添加的扩展域包括设为0
的一个比特，就不使用这样的第二域。
在图8中，说明了扩展码方法。根据这个方法，图4中固定长度
域11中的一个码被保留，用作扩展码。例如，假设映射表12中的二
进制码111用作扩展码。当这个码111出现在固定长度域11中时，
意味着扩展长度域14将包括在微信元字头中。因此，另外3比特用
于大小映射。在图8中说明了这些。这个方法使映射表12中大小的
个数减1，添加了另外7个信元大小，可以在扩展长度域14的附加8
个码值上映射。
从节省带宽的角度来看，扩展码方法比扩展比特方法好，因为它
需要3比特，而扩展比特方法需要4比特。从值的范围来看，扩展比
特方法优于扩展码方法，因为它提供16种不同的信元大小，相比之
下扩展码方法提供了14种。
在图9中，扩展比特方法与扩展码方法以一定方式结合，使得信
元字头中提供的比特得到高效率的使用，同时覆盖了较宽范围的信元
大小，带宽的使用率提高。
使用这种合成编码方法的微信元基本格式示于图9。微信元包括
2个八比特组的字头21，以及有效负荷部分22，可能包括从1到48
个八比特组。微信元长度的四个最低有效比特在字头中LEN域的小固
定大小长度域23中表示。LEN域23包括4比特。该字头也包括CID
域24，占用8比特，标识微信元所属的线路。在字头中也有长度扩
展限定符域25、LEQ域、以及字头完整性域26、HIC域，均为2比特
长。
长度扩展标识符LEQ25定义为有效负荷的长度扩展以及字头扩
展。当LEQ取二进制码00、01以及10时，微信元具有图9表示的基
本格式，LEQ的编码比特构成添加到LEN域23的比特。在这种情况
下，LEQ域用作LEN域23的扩展。
特别地，在LEN域23中有24种不同的值与LEQ域25中存在的二
进制00码相关联，LEN域23中有24种不同的值与LEQ域25中存在
的二进制01码相关联，以及LEN域23中有24种不同的值与LEQ域
25中存在的二进制码10相关联。这在图10中说明。根据如下一般
表达式给出了总共48种不同的长度值：
[2lenth of LEQ in bits-m]×[2lenth of LEN in bits]
这里m是用于表示微信元扩展格式的码数目。
因此，有效负荷大小可以从48个长度值中选择。在例子中给出
的长度值编码为1到48。
当LEQ域25取二进制码11时，表示基本信元格式被扩展。扩展
的格式在图11中表示。LEQ域25具有双重含义。LEQ的双重含义是
(ⅰ)它用作长度表示中的最高两位有效比特，即LEQ×24+LEN，如图
9所示，以及(ⅱ)用作扩展字头格式的标识，如图11和12所示，
即，LEN域23译做扩展限定符域27、EXQ域27。EXQ域27包括4比
特。在EXQ域27的四个比特中，二进制值0000和0001保留与另外
的长度域29、LENE域一起使用，以图12和13中所示的方式。特别
地，EXQ域27中的最低有效比特添加到另一个LENE域29的7个比
特中，以图13中虚线方框31中所示的方式。这类似于图10中所示。
对于EXQ的二进制值0给出128种不同的长度值，对于EXQ的二进制
值1给出另外128种不同的长度值。
用于这种方法的不同长度值的数目由如下一般表达式给出：
[2number of EXQ bits used]×[2number of bits in LEN 29]
在发明优选实施例种，EXQ值0用于表示从1变化到128个八比
特组的微信元长度，EXQ值1用于表示从129变化到256个八比特组
的微信元长度。
应该注意到图9和12中所示的微信元长度用线性编码来表示。
EXQ值2(二进制0010)用于表示微信元是操作及维护信元、OAM
信元，包括字头32、以及OAM信息域33，如图14所示。字头32类
似于图12中的字头21。在LEQ域25中，二进制码11出现，在EXQ
域27中二进制码0010出现。
EXQ码3(二进制0011)用于表示固定长度微信元，例如用于DAMPS
系统标准。其它EXQ值可用于其它系统标准或业务。
EXQ码值1xxx用于同步信元，这里xxx是定时信息。
在优选实施例中，主要要求是微信元字头最大长度为2个八比特
组。即使使用这个限制，用有效方式使用可用的比特，可覆盖全部范
围的值。
在图9、11、12、14中，在各个域下标出了优选的大小。所标的
大小只是示例，仍可使用很多其它大小的不同域。所标示以外的其它
LEQ和EXQ码可以用作添加到LEN域23和LENE域29的比特。
在图15中，表示了信元字头读取设备的框图。包括移位寄存器
19、第一计数器20、闩锁寄存器30、ROM存储器40、第二计数器50
以及复接器60。包括微信元用户数据的比特流在移位寄存器19的一
个输入端移入。时钟信号控制数据比特移入移位寄存器19的频率。
时钟信号由第一计数器20产生，用于提取微信元的固定大小长度域
11，并将它的数据写入寄存器30。固定长度域或者说是其中的信息
用于寻址ROM存储器40，该存储器根据图5中所示的映射表配置。
因此，一个单个码，下面称为长度码，对应于用户数据的一个特定长
度。从ROM存储器40中读取用户数据的大小(微信元大小减去字头
大小)，并发送到控制复接器60的第二计数器50，使其输出61上
出现用户数据。假设第一计数器20从用户数据信道读取二进制码
011。这个码用于寻址ROM存储器，而且在这个地址存储信元大小20。
因此，用户数据的长度应该是20个八比特组。然后，第二计数器50
通过计数相应数目的时钟脉冲，而逐比特地计数此后的20个八比特
组比特。复接器60被示为具有一个分支62，在所示的两个位置之间
可移动。最初，计数器50将分支62设置到用虚线表示的较低位置，
输出61上没有输出数据出现。当第二计数器50从ROM存储器40中
接收了信元大小时，将分支62移到较高的位置。在较高位置，分支
62连接到线路63，后者再连接到输入用户数据信道。当第二计数器
50计数到20个八比特组时，将分支62移回最初位置，这样在输出
61上就得到了正确数目的八比特组。
在图16中，表示在时刻t0从用户数据信道提取固定大小长度域
11。在时刻t0，计数器20开始逐比特地计数20个八比特组并在时刻
t1，计数器20已经计数了20个八比特组。因此，在时刻t0和t1之
间，图15中分支62处于较高位置。
在图15所示的信元字头读取设备中，预定数目的长度码以及信
元大小存储在ROM40中。在图17所示的信元字头读取设备中，RAM
存储器70用于从控制系统80写入哪个长度码和信元大小。用这种方
式，可以对单个移动电话系统配置不同的特定微信元大小。
存储在ROM40中的微信元大小是全局的，意即单个长度码，例
如101，关联于使用这个长度码的微信元的所有连接。
但是，可以通过使用控制系统80和RAM存储器70，针对特定连
接或特定的物理链路具有特定的微信元大小，正如结合图18-27所描
述的。
图18是用于实现扩展码方法的信元字头读取设备的框图。在图
18中，相对图15和17中同样功能的模块具有同样的参考标识。该
电路区别于图15和17中所示，其中有一比较器90，用于检测扩展
码。如果匹配，比较器就触发减法器100，将第一计数器20的计数
减去3个计数值。当完成之后，扩展长度域、或特别是其中的数据，
再次写入寄存器30。与扩展域14有关的各种大小必须添加到RAM存
储器70。这意味着RAM存储器中信元大小的数目会加倍。实际上，
这意味着RAM存储器70中将使用新的存储器阵列。单元110是D闩
锁，锁存比较器90的输出值并用它寻址RAM存储器70中新的存储器
阵列。
比较器90和减法器100是处理扩展长度域14的单元，当检测到
扩展码时可以移动字头中的位置。三个额外的比特添加到长度域11，
这是用于表示信元长度的三个额外比特。因此，固定大小长度域11
被插入到数据流中的扩展长度域14所代替。
与一个域被写入存储器的图15或17中的电路操作相比较，在图
18中另一个域被写入存储器70。
图18中所示的信元字头读取装置也可用于实现扩展比特方法。
在图19中表示。从包含固定大小长度域11的寄存器30中，提取扩
展比特13并用于增加寻址范围。扩展比特使第一计数器20减少3个
比特的计数，由减法器100所示。这意味着三个新比特将写入寄存器
30，而且这三个新比特加上三个旧比特，即共6个比特，用于寻址由
六个箭头所表示的RAM存储器70。用这种方式，信元大小的数目可
以增加。
ROM存储器40可以有几个图5所示不同类型的映射表。可以响应
微信元字头中提供的预定长度码，从一个映射表改为另一个。用这种
方式，可以从第一组微信元长度，例如4、8、16、20切换到第二组
长度，例如3、6、9、12。不使用以图5所示映射表配置的ROM存储
器40，使用RAM存储器用于相同的目的。这会使控制系统80在RAM
存储器中写入一组新的微信元长度。整个表也可以在控制消息中传
递。
不给每个信元提供用于表示微信元大小的固定大小长度域，可以
使用隐含的方式表示微信元大小，该方法在微信元字头中不使用任何
长度域。根据表示微信元大小的隐含方法，与大小有关的信息驻留在
系统网络内部。不使用专用域表示信元大小，使用微信元字头中已有
的域。在发明优选实施例中，微信元大小映射到所建立连接的标识
上。因此大小不是全局的，而是面向连接的。
连接的标识由连接的CID域给出。在图20中，微信元字头7被
示为包括CID域71。CID域71的实际大小依赖于系统，但是一般两
个八比特组就足够了。通过使用与图6和7结合而描述的同样映射方
法，产生一个映射表72。
因此，已经抛弃了固定长度域11。这会增加带宽的效率。CID值
用于寻址图17中的RAM存储器70并由控制系统80来提供。因此，
不在寄存器30中锁存长度域11，而是将CID值锁存在寄存器30中
并用于寻址RAM存储器70。用这种方式，在所建连接的标识与连接
中使用的微信元长度之间存在一种关系。因此，不需要额外的存储器
位置存储CID和与所述CID关联的微信元大小之间的关系。
在连接建立时，控制系统80将接收一条消息，请求(a)在所标
识的端点之间建立一条连接，并且(b)这条连接将使用具有X个八
比特组大小的微信元。假设X是在可用信元大小中选择的一个整数。
然后，控制电路选择ATM网络所提供的逻辑地址中的一个空闲CID。
对于本例，选择CID=7。控制系统80现在将使用7作为RAM存储器
70的地址并在这个地址写入微信元大小X。图17中所示的信元字头
读取设备将用所描述的同样方式操作。应该注意到映射是在连接建立
时进行的。
应该注意到一个而且是同一个CID可以关联于几个不同的微信元
大小，根据具有相同CID的信元可以在不同虚连接VS:s上传输这个
事实。这将示于图22中，其中标识了ATM网络中使用的典型地址结
构。对于ATM网络中的每一物理链路，称为物理路由，都有一张具有
多个项目的物理链路表140，例如所示的项目0-23。每一物理链路都
关联各自的VPI/VCI(虚通路/虚标识符)表150。例如，每一物理链
路有256条虚通路VP0-255。在每一VC连接中，以VCI-/VPI值来
标识，例如256个微信元每个都具有自己独立的CID。
某些应用需要基于毫秒改变微信元的大小。其它满足这种要求的
改变大小的方法使用用户数据信道上传输的信元大小改变微信元。这
将结合图24-27描述。所使用的改变大小方法不需要控制系统80的
处理，也不需要同步机制。
特别地，根据结合图24-27描述的方法使用一个特殊微信元表示
新的大小。新微信元大小在有效负荷94中给出。使用四种类型：
1)特殊EXQ值定义大小指示器微信元，如图26所示，
2)使用图25中所示的规定的EXQ值2，即OAM信元，
3)大小改变指示微信元由特殊CID值表示，例如CID=0，
而且该连接由有效负荷中CID域93来标识，如图24所示，
4)下面第五种方法所描述的类型。
用于连接中随后微信元的新微信元大小在长度域94中表示。在
数据流中微信元91、95、97之后并且具有相同CID的所有微信元将
具有新的信元大小并将它们的大小指示器设为0，如此表示该微信元
用于用户数据。
根据电信系统的实现，包括表示微信元大小改变信息的微信元可
以接续、即链接用户数据流中具有新长度的第一微信元，也可以不这
样。这样会产生或不产生同步的问题。包括微信元大小改变信息的微
信元将在下面称为控制微信元。应该注意到控制微信元可以包括，除
微信元大小改变信息以外，其它诸如用户数据、控制数据、OAM数据
等这样的其它信息。
将描述改变正在进行的--即操作中的--连接的微信元大小
的五种方法。
方法1--概述
如果微信元大小不会频繁改变，即比每秒改变一次更少一些，根
据本发明建议，用基站和控制节点--例如移动交换中心MSC--之
间接入协议上发送的控制消息来改变大小。控制节点将处理和控制微
信元连接建立过程中使用的所有设备，特别是图17、18和19中的控
制系统80。控制消息在与微信元传输的不同信道上发送。因此必须
在微信元的发送端和同一微信元的接收端之间提供同步。根据发明，
这种同步用在微信元字头中一个比特内设置标志来提供，如图23所
示，其中的标志比特标为82。
图29表示信元大小改变方法的实施例，下面称为控制平面信令。
类似于图15所示的信元字头读取设备83接收从用符号表示的发送设
备85发送的用户数据比特流84。当需要改变微信元大小时，发送设
备85发送一条在控制信道上传输的控制消息86，表示具有CID=N的
连接将其信元大小从长度L1改变到新长度L2，其中L是组成该微信
元的八比特组的数目。
控制消息86在控制信道比特流87中发送。比特流87与比特流
84不同步。信令消息88的协议处理器接收控制消息并将其传递到控
制系统80。控制系统80现在将新信元长度L1在所标识连接CID=N
的地址处写入信元字头读取设备83。
在足够时间过去之后，ATM网络的控制系统80已经处理了该控制
消息之后，通过使用新大小L2在第一微信元89中设置标志82，发
送设备85将信元大小从L1改变到L2。这将通知接收一侧这个信元
以及随后的信元都具有新大小L2。
最后，当携带标志82的第一微信元89被信元字头读取设备83
接收，而且微信元89的CID被寄存器30接收时，将从与这个CID
关联的映射表中读出新长度L2。第二计数器50用这种方式控制复接
器60：将新信元大小提供给移位寄存器10中的微信元89以及属于
这条连接的所有其它信元。用这种方式，当改变信元大小时不会丢失
信息。
控制平面信令可以逐秒触发信元大小改变。因为控制系统80处
理控制信号一般需要大约1/2秒。因此，控制平面信令较慢并且需要
同步。
应该注意到图29在某种程度上是简化的，以便清楚地讲述该同
步方法。实际中，在任意时间比特流87会在比特流84中交织。
方法1--详细描述
结合图29描述的一般方法现在将参考图30所示的GSM系统做更
详细的描述。在图30中，控制节点100是GSM网络中的MSC(移动
业务交换中心)。控制节点100包括控制传输设备101的控制系统
80。传输设备包括微信元打包设备102，由图15、17、18和19中所
示类型的信元字头读取设备103组成。GSM网络中的基站104具有类
似的传输设备105，带有由信元字头读取设备107组成的信元拆包设
备106。传输设备101具有未表示出来的微信元拆包设备，传输设备
105具有未表示出来的微信元打包设备。传输设备101和105在链路
108上交换分组。几个连接可以同时存在，但是为了举例，只考虑一
个特定连接109。用110和111符号表示的、用于连接109中分组的
微信元，假设每个长15个八比特组。假设业务是按需要连续进行的。
在某个时刻，依据外部事件，例如从一种业务切换到另一种、从语音
业务切换到数据业务或从半速率到全速率，控制80通过向传输设备
101和105中的每一个发送各个控制消息112、113，启动微信元大小
的改变。每个控制消息表示对于连接109，微信元大小将改变到23
个八比特组的新大小。直到传输设备105有信息要发送时，它才起作
用。将要进行的操作顺序将参考图31描述。
图31是表示传输设备101和传输设备105之间通知分组的信令
图。分组由箭头表示，箭头上面表示分组所使用的微信元大小。按照
箭头，以时间顺序从顶到底依次出现：最初的分组，用两个最上面的
信号箭头表示，在传输设备101、105之间交换。信元长度最初为15
个八比特组。然后控制消息112发送到传输设备105。在控制消息113
发送到传输设备101之前，也可能出现一个或更多其它的分组114
从传输设备101发送到传输设备105。如上所示，直到接收传输设备
105有东西发送时，它才对收到控制消息112产生反应。下次传输设
备105有信息发送时，它将在分组115中发送，其中使用具有23个
八比特组新信元长度的信元。在第一个新长度信元中设置第一个标
志。这个第一标志是图29中的标志82。第一标志表示这个微信元115
以及随后的信元具有新长度。在现在作为接收单元的传输设备101
中，标志由没有表示出来的拆包设备的信元字头读取设备检测，并用
于触发一种机制，提醒此后从这个传输设备101发送的微信元长度变
为新长度。这种机制驻留在微信元拆包设备102中。然后，当传输设
备101有信息要发送时，它将在带有新长度微信元的分组中发送。在
这些分组的第一个中，用信号箭头116表示，设置第二标志。此后在
传输设备101和105之间交换的分组都将具有新长度，如分组117
和118所示，而且都不再设置第二标志。
从上面看来，显然第一微信元115中的第一标志作为同步标志。
微信元116中的第二标志作为确认标志，向传输设备101确认传输设
备105已经收到同步标志。在两个标志交换之后，连接109处于同步
状态，其中两个传输设备101和105都用新长度发送和接收分组。用
这种方式，用于特定连接的微信元长度在连接保持建立的同时改变
了。
新长度在控制消息112、113中发送。控制消息一般是独立的信
元，例如OAM信元。OAM微信元在独立的连接上或在连接109中发送。
控制消息的使用对提供给连接109的带宽没有影响。当微信元长度将
要改变时，只花费微信元的一个二进制数字，即标志比特。换句话说，
在移动无线系统的任何两个用户之间交换信息的协议中只需使用一
个比特。从带宽利用的观点来看，控制平面信令方法是很有效的。
应该可以想起可用的微信元长度是配置到移动无线系统中的。
根据上述方法的一个修正，第一标志在具有15个八比特组的旧
长度微信元中发送。使传输设备101有足够时间指示它的微信元字头
读取设备改变其设置，接收新长度信元。
控制消息112、113通知特定连接的发送和接收方的方法不是方
法1所特有的。总结方法1：需要独立的控制微信元以便改变连接的
微信元大小，需要同步机制以便在正确时刻使新微信元大小生效。
方法2
这个方法是方法1的一个例子并说明控制消息是如何通知传输设
备101、105的。在这种方法中，使用具有上面类型2)的控制微信
元。控制微信元具有图24中所示的类型并包括包含新微信元大小的
域94。控制微信元的CID值不同于其信元大小将要改变的连接109
的CID。因此，控制消息在不同于用户数据所发送的连接上发送。
参考图32，存在一个同步问题，因为控制微信元没有链接到其大
小将要改变的微信元序列中。因此，存在两个彼此独立的连接1，一
个125，用于控制微信元，另一个109，用于用户数据微信元。例如，
标为127的控制微信元具有CID值为0，而用户数据微信元具有
CID=7。连接109主动向传输设备105发送分组，都用长度为15个八
比特组的微信元128填充。在某个时刻，控制系统要将连接109中分
组的微信元大小从15改变到23个八比特组。控制系统命令发送控制
微信元127。控制微信元在连接125中发送。控制微信元具有CID=0，
并在它的有效负荷中包括：(a)CID域93以及长度域94。CID域93
指出将要改变微信元大小的连接；在这种情况下所表示的是CID=7。
在长度域94中，表示了新长度23。
发送传输设备101和接收传输设备105都接收控制微信元127，
参看图33中所示的信令图，它们都知道23个八比特组的新长度。两
个单元中任一个现在都可以在下一个同步时刻开始使用新长度。为了
产生同步时刻，接收传输设备105在它于连接109中所发送的具有新
长度的第一微信元130中设置标志129。该标志包括一个二进制数
字，向接收单元表示此后的微信元，以设置标志比特的微信元开始，
都具有新长度L=23。此后从传输设备105发送的所有微信元将具有
新长度。当传输设备101收到微信元130时，信元标志表示该微信元
以新长度配置。传输设备101使用23个八比特组的新长度对信元130
和所有随后的微信元拆包。当传输设备101有东西要向传输设备105
发送时，它将使用新长度，如箭头131所示。
上面提到的下一个同步时刻可以在控制系统激活一个新业务时
或在控制系统为其它原因要改变特定连接的信元大小时产生。
因此，一旦连接109的发送单元以及接收单元都收到控制微信元
127，就可以发送标志比特。标志比特作为从旧微信元大小向新微信
元大小切换的同步手段。同步由发送和接收单元自己完成，不需要来
自控制系统的帮助。当改变所发送的微信元长度时，首先发送的传输
设备设置同步标志。接收单元，当收到该标志时，开始使用新长度格
式。
在所说明的例子中，接收到控制信元127后首先发送的传输设备
是设备105。它也可以是传输设备101。
这种方法的操作比方法1快，因为控制微信元包含新大小，因此
传输设备101、105不必等待控制系统与之联系以便得到新信元大
小。方法2具有诱人的带宽利用率，因为每次大小改变时，有效负荷
中的开销只有1比特。
OAM微信元由通信系统的操作及维护系统处理。根据方法2的修
正，表示连接109的大小改变的OAM微信元由端接传输设备105处
理。
参考图34和35。控制微信元具有图24所示的类型。存在一个与
信元大小改变有关的问题，因为在连接109的信元大小改变之前，系
统中发生了很多其它事情。图34说明一个属于三个不同连接的分组
序列，具有CID=1、CID=2及CID=7的各自ID:s。所有三个连接都发
送信息。恰在分组序列的中间，需要改变CID值为CID=7、使用15
个八比特组信元大小的连接中的信元大小。
在该分组序列中首先到来的是属于CID=1和长度L=10的连接的
分组140。随后到来的是属于CID=2和长度L=8的连接的分组141。
然后到来的是属于CID=7和L=23个八比特组的连接的分组142。然
后是属于CID=1的分组143，然后是属于CID=2的分组144。为了某
种原因，控制系统80决定将CID=7的连接中的信元大小从当前的
L=5改变到L=23。因此控制系统80将控制微信元145插入正在进行
的数据流。CID=0的CID值表示OAM微信元。在控制微信元145的有
效负荷中，指出信元大小将改变的连接，即CID=7的连接，以及新信
元长度L=23的表示。当控制微信元由传输设备105在接收一侧接收
时，拆包设备106存储控制微信元145中给出的信息，即存储如下信
息：在CID=7的连接中信元大小将改变为23个八比特组。该信息存
储到下次这条连接上的微信元到达。在这段时间，即从收到微信元
145到CID=7的下一个微信元到达之间的时间，很多其它的属于其它
两个连接的微信元到达打包设备106。这分别通过属于连接CID=1和
CID=2的微信元146和147来说明。当连接CID=7中的下一个信元终
于到达时，即当微信元148到达时，传输设备105读到它，信元拆包
设备将其分成均为23个八比特组长的段。所有上述方法步骤都在图
25中表示。
传输设备105只是简单提供了使控制系统80一次进行一个连接
的信元改变。如果几个连接同时改变信元大小，传输设备105的实现
将会更复杂。
方法3
从系统观点来看，根据方法3改变微信元大小是通过操作及维护
系统处理的，而且用来改变大小的控制消息在业务流--即用户数据
微信元所传输的流--中传输。
在方法3中，控制微信元具有上述类型3)。控制微信元是EXQ
值为2(二进制11)的OAM微信元。图25中所示的OAM信元的CID
值等于信元大小将改变的连接的CID值。换句话说，OAM信元在信元
大小将改变的同一连接中传输。这将保证控制微信元处于大小将改变
的连接的微信元流中的正确位置。正确位置意味着控制微信元处于属
于微信元大小将改变的连接的两个不同大小微信元之间。因此原则上
不需要同步机制。但是，由于OAM微信元不是按照业务微信元相同的
方式端接，可能会出现同步问题。有效负荷类型选择器PTS=控制微
信元的OAM，表示该微信元是OAM信元。传输设备在业务平面处理用
户数据微信元，不处理OAM微信元。OAM微信元由控制平面的操作及
维护系统处理。
图30和32中描述的类似硬件设备在方法3中使用，后面将不再
描述。按照图30和32的例子，也假设连接109将改变其微信元大小。
连接109的CID=7。这个连接109的微信元大小将从15个八比特组
改变到23个八比特组。现在，参考图36。在这个连接上，插入OAM
控制微信元134。OAM控制微信元在其长度域94A(图25)中包括23
个八比特组的新长度。
图36中所示的控制系统80包括OAM微信元处理器133并在带有
信元字头读取设备103的信元打包设备102上操作。
输入信元打包设备102的分组从图36的左边到达，输出分组在
右边离开。只要输入微信元的EXQ值不同于2(二进制11)，传输设
备105中未表示的信元打包单元就将其按分组打包，沿着箭头136
发送到它们的目的地。
对连接109端接的传输设备105将控制微信元识别为OAM微信
元，因为它的PTS=OAM。传输设备105将从数据流中提取OAM控制微
信元并发送它，如箭头137所示，到控制系统80，在那里由OAM信
元处理器133来处理。驻留在OAM微信元处理器中的逻辑解释OAM
微信元。在这种情况下，该逻辑将发现OAM信元指示CID=7并且要进
行微信元长度的改变。作为对该解释的响应，OAM处理器向信元打包
单元返回大小指示消息SI，表示连接109上的微信元将具有新长度
SI=23。这条消息由箭头138表示。当收到这条消息时，打包设备102
开始读取使用新长度L=23的输入微信元。为了做到这点，打包设备
102命令它的RAM存储器70设置新长度。
OAM信元可以有很多类型。一个OAM信元包括向OAM处理器133
表示控制系统响应收到的OAM信元应该进行何种动作的消息。例如它
可以是命令控制系统80测量误码率的消息。另一种OAM信元可以包
括向控制系统80报告硬件故障的消息。另一种OAM微信元消息是命
令控制去测量某方面的微信元数量，例如针对校验和。打包设备102
将向控制系统80中的OAM处理器发送PTS=OAM的所有微信元。
尽管OAM微信元134与信元大小改变的时刻有关，而且尽管它属
于将要改变微信元大小的连接109，但是它看起来好象不需要同步。
但是这不总是对的。系统设计可能也会影响方法3的行为。因此，可
能必须提供一些同步机制。下面将描述为什么会这样。
控制系统80需要一些时间解释OAM微信元134。SI返回传输到
打包设备102也需要时间。在这段时间内可能有新信元到达连接
109。在这段时间中，信元拆包单元不知道将哪个微信元大小提供给
输入微信元。这就是为什么需要一些同步机制。
根据方法3的修正，建议端接连接109的传输设备105自己读取
OAM微信元以便得到它的类型。如果OAM微信元是信元大小改变微信
元，接收传输设备本身将处理该OAM信元并开始用新长度接收和发送
微信元。这样将去掉上面提到的与解释和SI返回传输时间间隔有关
的时延。方法3将保证微信元大小被改变的时刻处于正确的顺序。用
这种方式，传输设备将保证微信元大小改变信元与具有新信元大小的
第一微信元链接。根据方法3的修正，OAM信元在业务平面上处理。
从带宽利用的观点来看，只要微信元大小被改变的频率适中，方
法3就没有带宽的损失。
方法4
根据这个方法，控制微信元在业务流中传输并自动由打包拆包设
备102、106处理。控制微信元在业务平面内端接。去掉了图36所示
的环137。
在方法4中，控制微信元具有上述类型1)，信元为图26所示类
型，其中控制信元的CID值与该连接的CID值相同。参考图37和38
描述该方法。在图37中，所有单元都与结合图30和32所描述的那
些相同。假设传输设备101正在向传输设备105发送分组，而且分组
用15个八比特组长的微信元110来填充。
在某个时刻，控制系统80命令改变信元的长度。新长度为23个
八比特组。信元大小改变命令发送到传输设备101，例如在OAM信元
中传输。传输设备101通过向传输设备105发送图26所示类型的控
制微信元119来响应这条命令。所有控制微信元119都用于携带信元
大小改变信息。因此接收传输设备105必须将分组大小改变为23个
八比特组。问题是何时改变。
假设在15个八比特组长的最后一个信元110之后传输设备101
发送了控制信元119，那么此后从传输设备101发送的所有信元都具
有23个八比特组的新长度。不需要另外同步。
这是因为在ATM网络中，保证ATM信元按照正确时间顺序到达它
们的目的地。换句话说，ATM信元被发送的时间顺序在接收一侧不会
逆转。因此控制系统80可以在任何时间命令发送传输设备101改变
到新微信元大小。
图38所示的信令图说明了该方法。图38类似于图31，因此不再
详细描述。在图38中，改变微信元大小的命令由箭头121表示。控
制微信元由箭头122表示，长度为15个八比特组。它不可能有新长
度。下一个由传输设备101发送的微信元123以及此后所有的微信元
都以新大小发送。当传输设备105收到控制微信元122时，驻留在打
包设备107和未表示的拆包设备中的一个机制，将设置微信元122
之后的微信元长度为23个八比特组的新长度。这样当从传输设备101
发送的微信元123到达传输设备105时，将用新长度对其解码。类似
地，当传输设备105发送下一个微信元124时，将用新长度发送。
与方法4有关的带宽损失与信元大小被改变的经常程度，即速率
或频率成比例。仅与微信元大小改变有关的开销以控制微信元的形式
出现。微信元110和120不包括任何信元大小指示域。因此，它们没
有与信元大小指示有关的开销。这与结合图4、6、9、11、12所描述
的微信元相反，它们都包含微信元大小指示。
方法4使传输设备101、105的实现复杂，因为它们必须能够同
时并在很短时间内处理大量的连接。
应该牢记的是ATM是定义点到点连接的面向连接的技术。这与无
连接性质的分组交换网络相反。在分组交换网络中，相同目的地的分
组可以采取通过网络的不同路由，因此可能以逆时间顺序到达。
方法5
方法5是方法4的改进。不使用一个完整的微信元改变正在进行
的连接的微信元大小，而是向携带用户数据的微信元插入一个可选
域。当可选域出现时，表示新大小用于该连接的微信元。在方法5中，
改变微信元大小的信息在业务流中传输。根据方法5，使用稍微不同
的消息格式。原则上使用一个显式的、即独立的、长度域。将参考图
39-41描述该方法。
在方法5中，使用图27所示类型的信元大小修改微信元170。可
选域171用于表示这个信元170之后并且属于相同连接的微信元使用
新长度。该连接由微信元字头中的CID表示。在字头中，也有一个扩
展比特13(图27)，当设置时表示信元包含可选长度域171。如果
扩展比特设置为0，信元170中就不出现域171。
方法5将结合图39-41描述。图39类似于图30，所示的是相同
的设备。当信元大小改变时，控制系统80只向发送传输设备101发
送信元大小改变命令149。当收到改变微信元大小的命令时，发送传
输设备101设置标志150，将可选长度域171添加到微信元170中，
在添加的长度域中表明新信元大小，例如23，以23个八比特组的新
长度格式将微信元发送并继续用新长度发送所有随后的微信元。当收
到控制微信元170时，传输设备105检测到该标志。响应对标志的检
测，传输设备105将微信元大小从当前大小改变到附加可选长度域
171中指示的新大小。接收传输设备105开始使用23个八比特组的
新长度，从该控制信元开始并继续到这个连接上所有随后的信元。
在图41中，表示了方法5的自解释图解说明。
方法5会节省带宽，因为长度域不象方法4中那样一直出现，而
是只当信元大小改变发生时才出现。
方法5的修正是从包含可选长度域171的微信元之后的微信元开
始使用新长度格式。在这种情况下，包含可选长度域的微信元使用旧
长度格式。
方法2-5的比较
下表1是方法2-4的一些特征特性的比较。表中给出的所有数字
是估计的。
表1
方法
No。#
相对分组速率
的速率改变
实现复杂性
相对显式的长
度表示方法的
健壮性
2
＜1/100
因子1
0.1
3
1/20
因子3
0.2
4
1/10
因子7
0.2
5
1
因子8
0.1
方法2和3相比方法4和5更健壮一些，因为它们需要同步。如
果因为某些原因丢失了控制微信元，就不能实现同步，也不能进行长
度修改。信息就以旧信元长度发送和接收，不丢失信息。同步通过发
送两个微信元来实现，每个连接方向一个，包括同步信息。健壮性增
强了但是改变速率降低了因子2。在方法4和5中，不需要同步。如
果控制信元丢失，接收一侧就不会收到。发射一侧改变到新信元大小
并开始在新长度信元中发送信息。接收一侧继续接收它认为是旧大小
的信息。因此接收信息将会破坏。
使用方法5，原则上可以改变单个连接的连续微信元中每个微信
元长度(每个微信元具有新长度；改变速率=信元速率)。如果出现
这种情况，方法5就退化了，变成与添加标志150的显式长度方法相
同的方法了。
如果使用方法5逐个微信元改变大小，那么方法5比显式长度方
法稍差。但是，如果改变速率为每两个信元一次，那么方法5就比显
式长度方法好。如果改变速率是每百信元一次，那么方法5就比显式
长度方法优越。当改变速率是每十个信元一次长度修改的量级，方法
5就是优选的。
不使用扩展比特13，也可以使用特殊有效负荷类型的选择器码、
PTS码、类似于结合图28描述的扩展码方法，表示该微信元用于相
同连接中随后微信元的大小改变。在图28中表示。不在微信元字头
中使用独立的扩展比特13，该比特用于表示该微信元是也包括表示
微信元大小将改变信息的用户数据信元，而是在有效负荷类型选择器
PTS中使用一个码点用于此目的。特别地，PTS具有表示这个的特殊
码PTSI。
在图42中，表示了一个包括ATM网络200的移动电话系统，发
送单元201和接收单元202通过各自的链路205和206与网络连接。
用户数据源203通过用线209象征性表示的各个连接与发送单元连
接。用户数据接收器204通过各个连接210与接收单元202连接。由
微信元组成的连接209在发送单元201中用未表示的复接器复接在一
起。类似地，接收单元202中没有表示的解复接器将属于用户数据接
收器204所端接的连接的微信元解复接。在发送单元201中，有图
12所示类型的微信元字头读取设备207，在接收单元中有图12所示
类型的类似微信元字头读取设备208。
在图38中，表示了包括ATM网络200的移动电话系统，发送单
元201和接收单元202通过各自的链路205和206与网络连接。用户
数据源203通过用线209象征性表示的各个连接与发送单元连接。用
户数据接收器204通过各个连接210与接收单元202连接。由微信元
组成的连接209在发送单元201中用未表示的复接器复接在一起。类
似地，接收单元202中没有表示的解复接器将属于用户数据接收器
204所端接的连接的微信元解复接。在发送单元201中，有图11所
示类型的微信元字头读取设备207，在接收单元中有图11所示类型
的类似微信元字头读取设备208。