当将载有发往目标通信装置的信息的网际协议(IP)数据报从分 组数据服务节点(PDSN)发送到基站控制器/分组控制功能(BSC/PCF)， 而分组会话处于休眠状态时，BSC/PCF需要确定是否以短数据突发 (SDB)的形式发送信息。一种算法是用接收到的信息包的大小作为 过滤标准。即，例如当发现接收到的信息包小于预定的大小时，可以 通过前向公共信道将该信息包作为SDB发送到目标移动台，而不用等 待激活业务信道。否则，需要在发送信息包之前重建业务信道。这种 算法并不适用于群呼业务，例如当数据会话处于休眠状态时，客户端 和服务器发送在大小上不同的消息。然而，并不是所有的这些消息都 是对时间要求严格的，因而并不需要作为SDB发送。一些大的消息可 以需要以SDB发送，而一些小的消息可以需要在重建业务信道之后来 传递。利用大的包的大小作为过滤标准可以触发很多小的消息以SDB 来发送，并且因而使得公共信道上的负载过大。另一方面，如果利用 小的包的大小作为标准，那些对时间要求严格的更大的信息不能立即 以SDB发送。
因而需要机制来确定什么样的消息需要以SDB来传送，使得没有 对时间敏感的消息被延迟。

公开的实施例提供了新颖的和改进的方法和设备，用于确定是否 将发送往目标移动站的信息标识为以短数据突发的形式发送。该方法 包括接收发往目标移动台的信息包、解析接收到的信息包、并且确定 接收到的信息包是否被标识为以短数据突发的形式发送。
公开的实施例进一步提供了新颖的和改进的方法和设备，用于标 识在无线通信网络中以短数据突发(SDB)的形式传送的信息。该方 法包括在数据报中封装信息，其中数据报包括报头部分，以及标识该 数据报的报头部分使得无线通信基础设施向目的地以SDB消息的形式 传送封装在数据报中的信息。
在另一方面，用于传递发往目标移动台的信息的设备包括存储单 元、接收机、发射机以及处理器，该处理器与存储单元、接收机和发 射机通信连接。该处理器可以执行实现上述方法的指令。
附图说明
结合附图，通过以下公开的实施例的详细描述，本发明的特点和 优点将会更加显而易见，其中：
图1描述的是用于传递移动终端短数据突发的呼叫流程图；
图2描述的是被分帧(framed)和封装的IP数据报；
图3描述的是基站和移动台的实施例；
图4描述的是图2所示的IP数据报的报头部分；
图5描述的是依照一个实施例，用于图4中所示的报头部分的服 务类型字段；
图6描述的是依照另一个实施例，图4中所示的报头部分的服务 类型字段；
图7描述的是依照再一个实施例，图4中所示的报头部分的服务 类型字段；
图8描述的是图2中所示的IP数据报的可选的报头部分；
图9描述的是图2中所示的PPP帧的帧结构；
图10描述的是图2中所示的PPP帧的解析算法；
图11描述的是图4和图8所示的IP数据报的报头部分的解析算法；
图12描述的是简化了的解析算法。

在详细描述几个实施例之前，要理解的是本发明的范围并不局限 于以下的说明书中所述的或附图中所描述的部件的结构和排列的细 节。还应当理解的是这里使用的措词和术语是为了描述，并不应当视 为限定。
图1描述的是在休眠的包数据会话过程中移动终端短数据突发信 息传递的呼叫流程图。在休眠状态中，维持点对点(PPP)协议会话，但 使业务信道不起作用。到达PDSN 102的信息诸如IP数据报在步骤(b) 被发送到BSC/PCF 104。然后BSC/PCF 104在步骤(c)中作出决定以 如何发送信息。在步骤(c)，BSC/PCF 104解析接收到的信息。如果 接收到的IP数据报的报头部分中的服务类型(TOS)字段标识为SDB 传送，则BSC/PCF 104利用步骤(d)到步骤(g)以SDB形式递送该 信息。如果BSC/PCF 104决定接收到的信息应当以SDB来发送， BSC/PCF 104首先在步骤(d)执行一般寻呼，以定位目标移动台。随 后，通过公共信道将该信息以SDB的形式在步骤(f)向移动台(MS) 106发送。可以在步骤(e)中接收到的移动一般寻呼响应信息中识别 目标移动台。否则，如果BSC/PCF 104决定接收到的信息不应当以SDB 发送，BSC/PCF 104依赖移动台控制器(MSC)108来定位目标移动台， 例如通过一般寻呼程序，重建业务信道，并然后发送该信息。该程序 在图中没有示出。
在一个实施例中，网络实体诸如群呼服务器110可以提供发往目 标MS 106的信息作为IP数据报。在将接收到的IP数据报发送到 BSC/PCF 104之前，PDSN 102将其封装。图2描述的是依照一个实施 例的IP数据报分帧过程。IP数据报202可以包括报头部分和信息部分。 如果PDSN 102是移动台(MS)106的PPP对等体，PDSN 102可以将 接收到的IP数据报202封装在PPP报头204和PPP报尾206，形成PPP 帧208。
依照一个实施例，如在TIA/EIA/IS-2001中“CDMA2000的接入网 接口的通用性规范(IOS)”2001年8月(IOS v4.1)所述，将信息发送 到BSC/PCF 104之前，PDSN 102将通用路由封装(GRE)报头210 和IP报头212添加到接收的PPP帧208，形成通用路由封装(GRE) 包214。例如，通用路由封装(GRE)包214被视作IP净荷，并将其 寻址到A10连接上的BSC/PCF 104。
接收到通用路由封装(GRE)包214之后，BSC/PCF 104从接收 到的GRE包214中移除GRE报头210和IP报头212，并且在将信息 通过空中接口发送到目标MS 106之前，可以添加合适的报头。如上所 述，当包数据会话休眠时，BSC/PCF 104需要检查接收到的PPP帧208 以决定在开始解析IP数据报202之前，IP数据报202的报头部分是从 哪里开始的，随后本文将对其进行讨论。
单一的GRE包214可以包括不完全的PPP帧或多个PPP帧，如 2001年12月6日的TIA/EIA/IS-835，“无线IP网络标准”所规定的。 在这些情况下，该标准规定包括在GRE报头210中的序列号字段可以 用来确保包的连续传递。如果GRE报头210的序列号启用，在解析PPP 帧之前，BSC/PCF 104对接收到的GRE包重新排序。
图3描述的是BSC/PCF 304和移动台306的实施例的简化的框图， 其可以实施不同的公开的实施例。对于特定的通信，语音数据、包数 据和/或消息可以通过空中接口308在BSC/PCF 304和移动台306之间 交换。可以传输不同类型的消息，诸如用于在BSC/PCF 304和移动台 306之间建立通信会话的消息、注册和寻呼消息以及用于控制数据传输 的消息(例如功率控制、数据率信息、确认等)。以下将对这些类型消 息中的一些进行进一步详细描述。
对于反向链路，在BSC/PCF 306处，将语音和/或包数据(例如来 自数据源310)和消息(例如来自控制器330)提供到发送(TX)数据处 理器312，发送数据处理器312利用一个或多个编码方案来格式化并编 码数据和信息，以生成编码的数据。每个编码方案可以包括循环冗余 码校验(CRC)、卷积、turbo、块和其它编码的任意组合，或根本没有 编码。可以利用不同的方案来对语音数据、包数据和消息进行编码， 不同类型的消息可以不同地进行编码。
然后将编码的数据提供到调制器(MOD)314并对其做进一步的 处理(例如用短PN序列加载波、扩频，以及用分配给用户端的长PN 序列来扰频)。然后将调制过的数据提供给发射机单元(TMTR)316 并对其进行调节(例如，被转变成一个或者多个模拟信号、被放大、 被滤波、被正交调制)以生成反向链路信号。通过双工机(D)318路 由该反向链路信号，并通过天线320将其传输到BSC/PCF 304。
在BSC/PCF 304，由天线350接收该反向链路信号，通过双工机 352将其路由，并将其提供到接收机单元(RCVR)354。BSC/PCF 304 可以接收来自于移动台306的注册信息和状态信息，例如移动台位置 信息。接收机单元354调节(例如滤波、放大、下变频以及数字化) 接收到的信号并提供采样。解调器(DEMOD)356接收并处理(例如 解扩、去载波(decovers)以及导频解调)该采样以提供恢复的符号。解 调器356可以实现RAKE接收机，所述RAKE接收机处理多个实例的 接收到的信号并生成和合并的符号。接收(RX)数据处理器358解码 该符号以恢复在反向链路上传输的数据和消息。将恢复的语音/包数据 提供到数据信宿(sink)360，并且可以将恢复的消息提供到控制器370。 控制器370可以包括寻呼一组移动台的指令，其可以是基于移动台的 移动性。由解调器356和RX数据处理器358执行的处理与基站306 上执行的处理互补。可以进一步操作解调器356和RX数据处理器358 以处理通过多个信道诸如反向基本信道(R-FCH)和反向补充信道 (R-SCH)接收到的多个传输。传输也可以是同时来自于多个移动台， 每个传输可以是在反向基本信道、反向补充信道或二者上进行传送。
在前向链路上，在BSC/PCF 304，通过发送(TX)数据处理器364 对语音和/或包数据(例如来自于数据源362)和消息(例如来自于控 制器370)进行处理，并且由调制器(MOD)366对其做进一步的处理 (例如加载波和扩频)，以及由发射机单元(TMTR)368对其进行调 节(例如被转换到模拟信号、被放大、被滤波以及正交调制)以生成 前向链路信号。通过双工机352路由前向链路信号，并将其通过天线 350向BSC/PCF306传输。前向链路信号包括寻呼信号。
在BSC/PCF306，前向链路信号由天线220接收，通过双工机318 路由，并提供到接收机单元322。接收机单元322调节(例如下变频、 滤波、放大、正交调制以及数字化)接收到的信号并提供采样。解调 器324处理(例如解扩、去载波以及导频解调)该采样以提供符号， 接收数据处理器326进一步处理(例如解码和校验)该符号以恢复在 反向链路上的数据和消息传输。将恢复的数据提供到数据信宿328，恢 复的消息可以提供到控制器330。控制器330可以包括注册BSC/PCF 306的指令，其可以是基于移动台的移动性。
IP服务类型(TOS)位
图4描述的是依照一个实施例，例如IP版本4(IPv4)的图2所 示的IP数据报202的报头部分。该IP服务类型(TOS)字段402是IP 数据报202的报头部分的第二个字节。存在三种广泛接受的向IPv4的 服务定义的TOS位的映射。第一个映射定义在1981年9月的RFC 791， “网际协议”。在该RFC中，TOS字段有5个子字段，如图5所示。 三个“优先次序”位规定IP数据报的优先次序，其值从0(正常优先 次序)到7(网络控制)，允许发送器指示每个IP数据报的重要性。接 下来的三位是“D”、“T”和“R”。这些位可以用于规定传输IP数据 报的类型。最后两位是保留位。在一个实施例中，群呼服务器110使 用IP数据报的TOS字段中的一个或两个保留位来指明无线通信基本设 施，如图3所示，例如将向目标站以SDM消息的形式发送IP数据报。
图6描述的是服务定义的TOS位的另一个映射，如1999年7月的 RFC 1439，“Internet协议集中的服务类型”中所定义的。尽管该RFC 更新了RFC 791中的定义，许多著作和实施例依然引用RFC 791中的 原始定义。在RFC 1439中，优先级的子字段与RFC 791中定义的相同。 将接下来的4位当作是服务类型(TOS)位并且最后一位必须为0 (MBZ)位。RFC 1439重新将D、T、R位定义为4位TOS字段。RFC 1439指定数据报的始发者将最后一位设置为0，除非参与了使用最后 位的网际协议试验。因此，这只留下了最后的位作为未使用的位。在 一个实施例中，群呼服务器110使用TOS字段中的保留位来指明无线 通信基本设施，如图3所示，例如将向目标移动台以SDM消息的形式 发送IP数据报。
图7描述的是由Internet工程任务组(IETF)区分服务框架定义的 第三个服务定义，如1998年12月在RFC 2474，“在IPv4和IPv6的报 头中的区分业务字段(DS字段)的定义”中所述。该定义利用区分服 务代码点(DSCP)的6位来指示IP数据报的每一跳行为(PHB)的处 理。最后两位是保留位。在一个实施例中，群呼服务器110使用IP数 据报的TOS字段中的一个或两个保留位来指示无线通信基本设施，如 图3所示，例如将向目标移动台以SDM消息的形式发送IP数据报。
图8描述的是依照RFC 2460中“网际协议，版本6(IPv6)规定”， 1998年12月，IPv6的IP数据报202(附图2)的报头部分。业务类别 802是一个字节字段，其紧跟4位版本的字段804，如图8所示。RFC  2460没有规定如何使用业务类别802的8个位。然而，Internet工程任 务组(IETF)仍在努力采用与IPv4的服务定义类似的IPv6的服务定 义。
回到附图6，假定IPv4报头部分的前7位可以用于服务定义映射， 最后一位可以用于指示在BSC/PCF 104接收到的信息应以SDB消息的 形式将被发送到目标移动台106。RFC 1812，“对IPv4路由器的要求”， 1995年6月，增加了对IPv4路由器的如果非0的值用在保留位中则不 丢弃数据报的要求。现有的RFC没有指明其它的新的协议可以如何用 在保留位中。因此，在休眠的包数据会话过程中，BSC/PCF 104可以 接收IP数据报，所述的数据报具有标识为不同于0的保留位。此外， 没有RFC要求指示IPv6路由器应该如何处理报头中8位业务类别字段 的最后一个位。
对于本文件的剩余部分，根据所考虑的寻址方案，术语“IP TOS 字段”用于表示IPv4 TOS字段402以及IPv6业务类别字段802。依照 一个实施例，群呼服务器利用TOS字段的未使用的位作为指示SDB传 递的机制。例如，对于需要以SDB发送的消息，群呼服务器可以将IP TOS字段的最后一位设置成值0x01。
点对点协议
如上所述，通用路由封装(GRE)包214(图2)可以包含多个PPP 帧或未完成的PPP帧。BSC/PCF 104从接收到的GRE包214中提取 GRE报头210和IP报头212，将该信息重新包装为无线链路协议(RLP) 帧，并将该RLP帧通过空中接口传输到目标MS 106。对于用于解析IP TOS字段的BSC/PCF 104，BSC/PCF 104检测PPP帧208的开始和结 束。在该部分，我们检查PPP帧的结构并识别在链路控制阶段可以商 议的字段，如2001年12月6日TIA/EIA/IS-835“无线IP网络标准” 所限定的。关于PPP更多的细节可以在1994年7月，RFC 1661，“点 对点协议(PPP)”中找到。
图9是依照1994年7月，RFC 1662，“类高级数据链路控制(HDLC) 帧中的PPP”中描述的PPP帧208的高级数据链路控制(HDLC)帧结 构。字段902至908涉及PPP帧208的PPP报头204，字段910指的 是PPP帧208的IP数据报202，字段912指的是PPP帧208的PPP报 尾。第一个字段902是“7E”标记，以表示PPP帧208的开始和/或结 束。该标记后面有HDLC帧904、906、908。
依照RFC 1662，地址字段904可以设置为八位位组0xFF，控制字 段906可以设置为八位位组0x03。HDLC信息字段包含协议字段908 和IP数据报910(PPP有效净荷)。对于IP服务，协议字段908包括 其值为0x0021的两个八位位组，其后面有IP数据报910。HDLC包中 的最后一个字段是帧检验序列(FCS)912，其可以包括两个或四个八 位位组。每个PPP帧以标记序列开始和结束，并且一个标记序列可以 用在两个帧之间。两个连续的标记序列组成空闲的帧。结束标记序列 在图9中没有示出。
依照一个实施例，链路控制协议(LCP)处理对标准类高级数据链 路控制(HDLC)帧的结构的修改，以上已经做了描述。PPP对等体可 以商议压缩地址字段904和控制字段906。如果能够压缩，就除去两个 八位位组。此外，PPP对等体可以商议将协议字段908压缩为一个字 节，例如0x21。另一个可商议的参数是FCS字段912中的循环冗余校 验(CRC)的位的数量。PPP对等体可以商议16位CRC或32位CRC。
在传输信息之前，PPP可以执行位填充，以获取控制字符的透明 度。控制转义八位位组可以选择为0x7D。作为最小值，RFC 1662需要 执行转义标记序列，例如0x7E，以及控制转义八位位组，0x7D。在 FCS计算后，发射机检查两个标记序列之间的完整的帧，并执行标记 序列转义。0x00与0x1F之间的值加上值0x7D以及0x7E可以在发送 PPP帧时由发射机将其转义。
异步控制字符映射(ACCM)是具有4个八位位组位映射的LCP 选项，其使得在0x00和0x1F范围中的32 ASCII控制字符的字符转义 能够(位设置)或不能(位清除)。例如，ACCM值的第一个八位位组 具有控制字符0x19至0x1F的位，MSB表示0x1F，LSB表示0x18。 第二个八位位组具有0x10至0x17等的字符。值0xFFFFFFFF表示转 义了所有的控制字符，依照Carlson，James，Addision-Wesley，2002 的“PPP设计、实现和调试，”。0x00000000的ACCM的值表示没有值 为0x00至0x1F之间的ASCII字符被转义。每个标记序列、控制转义 八位位组以及任何在发送ACCM中被做标记的八位位组由其后面跟有 与八位位组0x20异或(XOR)的原始八位位组的控制转义八位位组诸 如0x7D来代替。
对于简单IP和移动IP操作，2001年12月6日，TIA/EIA/IS-835， “无线IP网络标准，”指定了移动的和PDSN的控制转义。对于PDSN， 该标准需要PDSN通过建议0x00000000值的ACCM来商议具有最小 数量的转义字符的控制字符映射。另一方面，该标准建议如果MS商 议控制字符映射，应当通过商议0x00000000的ACCM来尝试最小数 量的转义。因此，BSC/PCF 104可以从PDSN 102接收PPP帧，其中 在PDSN 102，不仅标记序列而且从0x00至0x1F的字符都被转义。
当BSC/PCF 104不是PDSN的PPP对等体时，BSC/PCF 104可以 不知道哪个LCP参数诸如地址字段904、控制字段906以及协议字段 908，在MS 106和PDSN 102之间被商议。因此，除了决定PPP帧以 外，为了解析IP TOS位，BSC/PCF 104还决定哪个字段被压缩以及是 否任何字符被转义以合适地识别IP数据报202的报头部分的开始。在 下一部分，将描述BSC/PCF 104所使用的解析PPP帧的算法。
PPP帧解析算法
如上所述，到达BSC/PCF 104的GRE包214可以包含多个PPP 帧或未完成的帧，这需要BSC/PCF 104在休眠状态过程中解析该包数 据流，以决定PPP帧的标记序列。BSC/PCF 104使用解析信息流以决 定IP数据报202的报头部分的开始的算法如图10所示。
如果该算法检测到未识别的字符序列，由于其不知道PPP帧204 从哪里开始，该算法就跳到下面的PPP帧的开始部分。作为不合适的 PPP实施的结果或者当在数据流中存在一个或多个错误时发生这样的 事情。该算法连续检验“0x7E”标记序列的存在直到它发现了非空的 PPP帧。特别地，在步骤1002，在发现第一个0x7E标记后，在步骤 1004，检查下一字节是否为0x7E标记。如果下一字节包括另一个0x7E 标记，意味着调查下的PPP帧是空的，该进程在步骤1006继续检查随 后的字节。然而，如果在包含有第一个0x7E标记的字节的后面的字节 不包含0x7E标记，意味着检验到了非空的PPP帧，该进程在步骤1008 检查地址字段904。
在一个实施例中，地址字段904和控制字段906可以被压缩，并 因此消失。此外，协议字段908也可以被压缩，使得只有它的第二个 字节可以出现，所述的第二个字节具有0xFF的值。在这样的情况下， 依照RFC 1662，两个八位位组协议字段908的第二个字节不应该被设 为0xFF，以避免其被错误地被当作具有值0xFF的地址字段904。
在步骤1008的检验之后以及找到对应地址字段904的0xFF， BSC/PCF 104在步骤1010检验下一个字节是否包含与控制字段906相 对应的0x03。如果在步骤1010中，确定下一个字节不包含0x03， BSC/PCF 104检验商议是否导致了控制字段值0x03的ACCM的商议。 在ACCM商议下，BSC/PCF 104首先发送控制转义字节例如0x7D，然 后发送包含原始信息的字节的异或(XOR)的结果的字节，诸如0x03与 0x20。
在步骤1012，BSC/PCF 104首先检验0x7D字节的存在，如果找 到，然后在步骤1014检验0x23的存在，0x23是0x03与0x20异或的 结果。如果0x7D或0x23都没找到，意味着没有检验到控制字段906， 该进程在步骤1016和1018检验新的PPP帧的开始部分，与上述的步 骤1002和1004相似。应当注意的是，如果步骤1008中的结果是“否”， 则地址字段904被压缩并因此不出现。
如果在步骤1010或步骤1014中，结果是“是”，意味着与控制字 段906相对应的0x03的值被直接或通过ACCM商议检验到，该进程 检验下一个字节，以检验与协议字段908的第一个字节相对应的0x00 的存在。BSC/PCF 104可以首先检验商议的结果是否已经通过ACCM 发送到了协议字段908。在步骤1020，如果0x7D字节没有找到，意味 着将不通过ACCM商议发送协议字段908，BSC/PCF 104然后在步骤 1022检验下一个字节是否包含有与协议字段908的第一个字节相对应 的0x00。
在步骤1022，BSC/PCF 104找到与协议字段908的第一个字节相 对应的0x00之后，BSC/PCF 104检验商议的结果是否已经通过ACCM 发送到了协议字段908的第二个字节。在步骤1024，如果0x7D字节 没有被找到意味着将不通过ACCM商议发送协议字段908，BSC/PCF 104然后在步骤1026检验下一个字节是否包含与协议字段908的第二 个字节相对应的0x21。如果0x00在步骤1022被找到之后，0x21在步 骤1026被找到，该进程在步骤1028结束，以解析IP数据报910的报 头部分，这将会在后面进行描述。
在步骤1024，如果找到0x7D字节，意味着将通过ACCM商议发 送协议字段908，BSC/PCF 104然后在步骤1030检验随后的字节是否 包含0x01，0x01是协议字段908的第二个字节，例如依照ACCM商 议0x21与0x20的异或。如果0x00在步骤1022被找到之后，在步骤 1030找到0x01字节，该进程在步骤1028结束，以解析IP数据报910 的报头部分。
回到步骤1020，搜索协议字段908的第一个字节，例如0x00，如 果BSC/PCF 104找到0x7D，就在步骤1032中检验下一个字节是否是 0x20，0x20是协议字段908的第一个字节，例如0x00，与0x20的异 或。如果步骤1032中的结果是“是”，意味着在协议字段908的第一 个字节中找到了0x00，该进程在步骤1024继续，搜索协议字段908的 第二个字节的存在，例如如上所述的0x21。
在步骤1032，如果包含有0x7D的字节后面的字节不包含有与协 议字段908的第一个字节相对应的值，例如0x00，BSC/PCF 102在步 骤1034确定该字节是否包含有0x00，0x00是协议字段908的第二个 字节，例如0x21，与0x20的异或。如果结果是“是”，该进程在步骤 1028结束。如果没有找到协议字段908的第二个字节例如0x21，检验 协议字段908的结果结束，该进程在步骤1016结束，寻找下一个PPP 帧。
应当注意的是，如果步骤1022中的结果是“否”，意味着协议字 段908的第一个字节没有找到，该字段被压缩。因此，只在步骤1036 检验第二个字节例如0x21的存在。
IP数据报解析算法
一旦PPP帧解析算法已经达到“解析IP数据包”状态1028，表明 该算法已经成功地检验到IP数据报910的开始，依照图11所示的一个 实施例，BSC/PCF 104则利用算法解析IP数据报910的报头部分400 (图4)或800(图8)来检验SDB标识是否出现。在一个实施例中， 解析算法假定32位报头部分400和800的4个字节以下列的顺序传输： 位0-7首先，位8-15、位16-23以及位24-31最后传输。这样的顺序叫 做big-endian字节顺序，它是当TCP/IP报头穿过网络时，用在TCP/IP 报头中的所有二进制整数中的字节顺序。这种顺序也被称为网络字节 顺序。如果BSC/PCF 104以其它格式诸如以little-endian字节顺序存储 二进制整数，在运行该算法之前，BSC/PCF 104将该报头值转换为网 络字节顺序，或者进行合适的映射使得该算法正确地执行。
IPv4TOS字段402(图4)以及IPv6业务类别802(图8)以4位 版本字段开始。该4位版本字段包含IP版本号。对于IPv4和IPv6版 本，版本号分别是0x04和0x06。为确定版本号，图11中所示的算法 检验是否依照ACCM商议或更直接地传输IP数据报910的报头部分的 第一个字节。如果在步骤1102发现报头部分的第一个字节包含0x7D， 意味着依照ACCM对报头部分的第一个字节进行了商议，该算法然后 在步骤1104将下一个的字节与0x20进行异或，以用0x20不适当的进 行异或功能，然后回复原始值。
在步骤1106，从步骤1102接收的IP报头的第一个字节的原始内 容或者从步骤1104接收的结果是与0xF0的位与运算，以读取报头部 分的第一个4位。在步骤1108，对照0x60检验步骤1106的结果，以 确定报头部分的第一个4位是否表示版本号是IPv6。
如果步骤1108的结果表示该版本是IPv6，进程在步骤1110、1112、 1114和1116继续，以确定是否设置了业务类别802(图8)的第5位 以表示SDB标识。如果步骤1116的结果表示已经设置了SDB位，该 进程在步骤1118结束。
继续步骤1120，如果该结果表示报头部分的版本号是IPv4，进程 在步骤1122、1124、1126和1128继续，以确定是否设置了TOS字段 402(图4)的8位以表示SDB标识。如果步骤1128的结果表示设置 了SDB位，该进程在步骤1118结束。
一旦找到了SDB标识，BSC/PCF 104检测下一个标记序列，以寻 找检查的PPP帧的结尾。多于两个的IP数据报可以封装在到达 BSC/PCF 104的单个PPP帧内，其中第一个IP数据报包含SDB标识。 此外，带有SDB标识的IP数据报可以超过预期的大小。当上述两个事 件的其中之一发生时，预期到接收到的消息是大的。为了防止大的SDB 消息在休眠包数据会话过程中通过公共信道传输，可以执行附加的检 验。在步骤1130，检验到了考虑中的PPP帧的结尾，并且如果PPP帧 中的字节数量低于如步骤1132中所决定的允许的数量，在步骤1134 中以SDB的形式发送PPP帧。否则，如果PPP帧中的字节数量超过允 许的数量，重建业务信道以在步骤1136中发送PPP帧，而不管SDB 标识。
依照一个实施例，BSC/PCF 104所使用的通过空中接口传输SDB 的程序如图1所示。在休眠包数据会话过程中，可能是只有一个PPP 帧从PDSN 102发送到MS 106。为了避免过多的处理，对于BSC/PCF 104来讲可行的是只处理几个在包数据休眠期间同时到达的PPP帧。
简化的解析算法
在一个实施例中，LCP商议参数、ACCM商议以及IP寻址方案为 BSC/PCF 104所知，可以简化上述的解析算法。在这种情况下，下面 的配置可以为BSC/PCF 104所知：
能够对地址字段904和控制字段906进行压缩
能够对协议字段908进行压缩
ACCM具有值0x00000000
使用了IPv4寻址方案
依照一个实施例，如图12所示，可以共同对分别如图10和11所 示的PPP帧和IP数据报解析算法进行简化。在步骤1202，一旦检验到 非空的PPP帧，在步骤1204进程检验协议字段908的第二个字节例如 0x21的存在，注意协议字段的第一个字节在字段压缩商议过程中被移 除。如果找到，在步骤1206，该进程跳过如图4所示的报头部分的第 一个字节，以到达TOS字段402。在步骤1208和1210，该进程检验是 否设置了如图6中所示的TOS字段402的LSB，如果是，在步骤1212 中该进程就指示SDB标识。与图11中的步骤1130至1136相似，该进 程继续步骤1214至1220以检验SDB消息的大小。如果符合大小标准， 以SDB形式发送PPP帧。否则，在发送PPP帧之前，在步骤1220中 重建业务信道。
因而，公开的实施例提供了一种有效和可靠的系统与方法，用以 确定发往处于休眠模式的目标移动台的信息是否应当以SDB消息的形 式发送，而不用等待重建业务信道。
本领域的技术人员将理解信息和信号可以利用多种不同的技术和 协议中的任意一种来表示。例如，数据、指令、命令、信息、信号、 位、符号以及芯片这些上文描述可以参照的内容，可以由电压、电流、 电磁波、磁场或磁性粒子、光域或光粒子或其任意组合来表示。
技术人员可以进一步理解，不同的说明性的结合这里公开的实施 例所描述的框图、模块、电路以及算法步骤可以以电子硬件、计算机 软件或二者组合来实现。为了清楚地描述硬件和软件的可交换性，以 上依照功能对不同的说明性的组件、框图、模块、电路以及步骤进行 了描述。这样的功能是以硬件或软件来实现取决于施加于整个系统的 特定的应用和设计约束条件。熟练技术人员可以以不同的方法来实现 每个特定应用的所述的功能，但是这样的应用决定不应被理解为是对 本发明的范围偏离。
可以用通用处理器、数字信号处理器(DSP)、应用专用集成电路 (ASIC)、现场可编程门阵列(FPGA)或者其它可编程的逻辑设备、 分立门或晶体管逻辑电路、分立的硬件组件或其设计用来执行这里所 述功能的组合来实现或执行结合公开的实施例所述的不同的描述性的 逻辑框、模块以及电路。通用的处理器可以是微处理器，但可选地， 该处理器可以是常规的处理器、控制器、微控制器或状态机。处理器 也可以由计算设备的组合来实现，诸如DSP和微处理器的组合、多个 微处理器的组合、一个或多个结合DSP核心的微处理器组合或其它这 样的配置的组合。
结合所公开的实施例描述的方法或算法的步骤可以直接包含在硬 件中、由处理器执行的软件模块中或者二者的组合中。软件模块可以 驻留在RAM存储器中、闪存中、ROM存储器中、EPROM存储器中、 EEPROM存储器中、寄存器中、硬盘中、可移动盘中、CD-ROM中 或本领域已知的其它任何形式的存储介质中。可以将存储介质连接到 处理器，使得处理器可以从存储介质读取信息以及向存储介质写入信 息。可选地，该存储介质可以与处理器是一体的。处理器和存储介质 可以驻留在ASIC中。ASIC可以驻留在用户终端中。可选地，处理器 和存储介质可以作为分立元件驻留在用户终端中。
公开的实施例的以上的描述用于使本领域的任何技术员实现或使 用本发明。对这些实施例的不同的修改对本领域的技术人员来讲是显 而易见的，在不背离本发明的精神或范围的情况下，这里所限定的一 般原则可以用到其他的实施例，例如在即时消息服务或任何一般的无 线数据通信应用中。因此本发明并不是限于这里所示的实施例，而是 要被授予与这里所公开的原则和新颖性特点相一致的最宽的范围。专 门应用的术语“示例性的”意思是“用作例子、实例或例证”。