CN1595860A - 通信系统中的协议版本探测方法 - Google Patents
通信系统中的协议版本探测方法 Download PDFInfo
- Publication number
- CN1595860A CN1595860A CN 03157877 CN03157877A CN1595860A CN 1595860 A CN1595860 A CN 1595860A CN 03157877 CN03157877 CN 03157877 CN 03157877 A CN03157877 A CN 03157877A CN 1595860 A CN1595860 A CN 1595860A
- Authority
- CN
- China
- Prior art keywords
- version
- highest
- message
- protocol version
- gtp
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Communication Control (AREA)
Abstract
本发明涉及通信系统中信令和数据的交换方法，公开了一种通信系统中的协议版本探测方法，使得通过协议版本探测流程获得的接收端GSN设备最高GTP协议支持版本的信息准确性提高，从而防止将支持高版本的GSN设备误判为低版本及由此引发的问题。这种通信系统中的协议版本探测方法包含以下步骤：A发送端向接收端发送低版本消息，消息中携带有表示发送端能够支持的最高协议版本信息；B接收端根据低版本消息，判断该消息版本是否与双方都能够支持的最高协议版本一致，如果是，则继续后续处理；否则接收端通知发送端使用双方都能够支持的最高版本进行通讯。
Description
技术领域
本发明涉及通信系统中信令和数据的交换方法，特别涉及码分多址通信系统中，协议版本的探测方法。
背景技术
近年来，通信技术得到了迅猛发展。比较突出的是宽带码分多址(Wideband Code Division Multiple Access，简称“WCDMA”)通信系统，它具有频率利用率高、抗干扰能力强等特点，因此逐渐成为在模拟制式、全球移动通信系统(Global System for mobile Communication，简称“GSM”)制式之后一种具有更强生命力和应用前景的移动通信制式。在数字移动通信领域中，WCDMA技术也扮演了重要角色。
WCDMA标准网络结构分为接入网和核心网两部分。
核心网由电路域和分组域组成。其中，电路域的主要设备是移动交换中心，用于提供传统的，给予电路交换的语音业务；分组域的主要设备是通用无线分组服务支持节点(GPRS Support Node，简称“GSN”)，用于提供基于IP分组交换的数据业务。这一特点使它与第二代移动通信制式相比的优势在于能够提供强大的高速数据业务支持。另外由于WCDMA标准设计时考虑了向下兼容的问题，因此接入网既可以是码分多址(Code DivisionMultiple Access，简称“CDMA”)制式的通用移动通信系统地面无线接入网(UMTS Terrestrial Radio Access Network，简称“UTRAN”)标准，也可以是第二代GSM标准。
核心网中分组域主要设备是GSN。GSN是通用分组无线业务服务支持节点(Serving GPRS Support Node，简称“SGSN”)和通用分组无线业务网关支持节点(GPRS Gateway Support Node，简称“GGSN”)的统称。其中，SGSN是分组域的中央服务控制节点，GGSN是分组域核心网与外部公共网络之间的网关节点。
在通信过程中，GSN之间，即各SGSN之间，以及SGSN与GGSN之间采用通用无线分组服务隧道协议(GPRS Tunneling Protocal，简称“GTP”)进行信令和数据的交换，GSN之间的接口称为Gn/Gp接口。GTP协议使用UDP/IP协议来承载。
目前已经发展了高低两个GTP协议版本，即低版本GTP version 0和高版本GTP version 1。对应的第三代合作伙伴项目(3rd Generation PartnershipProject，简称“3GPP”)的协议号分别为3GPP TS 09.60和3GPP TS 29.060。
上述两个版本的消息格式不完全相同，并且使用不同的用户数据报协议(User Datagram Protocol，简称“UDP”)端口。低版本GTP version 0使用3386号网间互联协议(Internet Protocol，简称“IP”)端口，而高版本GTP version 1中信令传输使用2123号IP端口，用户数据传输使用2152号IP端口。可见高版本GTP version 1将信令传输和用户数据传输使用的IP端口分离。
对于这两种不同的版本，仅支持低版本GTP version 0的GSN设备不能处理高版本GTP version 1的消息，由于网上还运行着大量的低版本GTPversion 0设备，因此高版本GTP version 1协议中规定：凡是支持高版本GTPversion 1的GSN设备，必须同时实现对低版本GTP version 0的支持，关于这一规定的详细说明，可参见协议3GPP TS 29.060第4节。
由于高版本GTP version 1所能够提供的性能更加优于低版本GTPversion 0，因此一个同时支持高版本GTP version 1和低版本GTP version 0的GSN设备在与其它GSN设备通讯时，需要首先确定接收端支持的GTP最高版本状况，具体步骤是这样的：
第一步：发送端用高版本GTP version 1的消息格式与接收端进行通讯；
第二步：如果发送端没有收到接收端的应答，用低版本GTP version 0的消息格式与接收端进行通讯。
发送端通过现有协议机制在探测接收端支持的最高GTP协议版本时，可能造成误判，将最高支持高版本GTP version 1的GSN设备判断为仅支持低版本GTP version 0的GSN设备，从而使用低版本GTP version 0与接收端进行通讯，导致部分性能的损失。
为说明这一点，下面对目前使用的探测接收端支持的最高GTP协议版本的方法进行描述(可参见协议3GPP TS29.060第11.1.1节)：
当支持高版本GTP version 1的GSN设备向一个只支持低版本GTPversion 0的GSN设备发送一条高版本GTP version 1的消息时，接收端应当向发送端发送一条“Version Not Supported”(版本不支持)的消息，该消息中携带有该发送端能够支持的最高GTP协议版本，即GTP version 0。发送端收到上述消息后，改用低版本GTP version 0与接收端进行通讯。
另外，由于绝大多数仅支持低版本GTP version 0的GSN设备并不监听高版本GTP version 1使用的2123和2152号IP端口，导致无法接收和处理高版本GTP version 1的消息，因此现有GTP协议版本探测机制中还规定了一种自动降低版本的方法，具体地说，就是当GSN设备使用高版本GTPversion 1与接收端进行通讯而接收端没有响应时，发送端就自动降低到低版本GTP version 0与接收端进行通讯。
为了确保上述版本探测方式准确获得对端GSN设备支持的最高GTP协议支持版本，一个非常重要的条件是GSN节点之间的通讯链路在版本探测过程中必须绝对畅通，即避免由于底层物理链路故障、路由故障、数据拥塞等原因导致消息被丢弃。
但是目前尚不能完全保证上述条件。
举例而言，当GSN设备在版本探测过程中向接收端发送的高版本GTPversion 1的消息正好由于底层链路的原因被丢弃，未递交到接收端GSN设备的GTP协议处理层时，发送端将由于未收到接收端的回应而误认为接收方不支持高版本GTP version 1，从而降低到低版本GTP version 0继续试探。
如果此时恰好底层链路恢复，那么收发双方将使用低版本GTP version 0进行通讯，但事实上双方都能支持高版本GTP version 1。
尽管上述情况不会经常发生，但并不能完全排除。可见目前的版本探测存在准确性的问题。
由于诸如上面例举的原因，将能够同时支持高版本GTP version 1和低版本GTP version 0的接收端GSN设备误判为仅支持低版本GTP version 0，会导致一些严重的后果，例如：
第一，在一个分布式设计的GSN设备内，多个GTP接口处理单元对同一个接收端GTP接口探测到的最高GTP支持版本可能会不同，因此，需要在GSN设备内设计比较复杂的同步机制；
第二，同一对GSN之间可能既要处理高版本GTP version 1的消息，又要处理低版本GTP version 0的消息；
第三，跨SGSN的路由区更新流程中，如果新侧SGSN、旧侧SGSN和GGSN支持的最高GTP协议版本均为高版本GTP version 1，而旧侧SGSN将新侧SGSN的最高GTP支持版本误判为低版本GTP version 0，那么旧侧SGSN在向新侧SGSN迁移用户已经激活的PDP上下文时，不得不将PDP上下文中的QoS Profile和TEID等字段从GTP version 1规定的格式转换为低版本GTP version 0的消息格式，这个问题可参见协议3GPP TS23.060第11.1.1节。由此带来复杂性和性能上的问题。
第四，SGSN的路由区更新流程中，如果新侧SGSN、旧侧SGSN和GGSN支持的最高GTP协议版本均为高版本GTP version 1，而旧侧SGSN将新侧SGSN的最高GTP支持版本误判为低版本GTP version 0，那么旧侧SGSN将去活部分低版本GTP version 0无法支持的PDP上下文，给用户业务带来损失，并带来复杂性和性能上的问题。具体看参见协议3GPP TS23.060第11.1.1节。
发明内容
本发明要解决的技术问题是提供一种通信系统中的协议版本探测方法，使得通过协议版本探测流程获得的接收端GSN设备最高GTP协议支持版本的信息准确性提高，从而防止将支持高版本的SGSN设备误判为低版本及由此引发的问题。
为了解决上述技术问题，本发明提供了一种通信系统中的协议版本探测方法，包含以下步骤：
A发送端向接收端发送低版本消息，所述消息中携带有表示发送端能够支持的最高协议版本的信息；
B所述接收端根据所述低版本消息，判断该消息版本是否与双方都能够支持的最高协议版本一致，如果是，则继续后续处理；否则所述接收端通知发送端使用双方都能够支持的最高协议版本进行通讯。
其中，在所述步骤A之前，还包含以下步骤：
D1所述发送端向所述接收端发送高版本消息；
D2所述发送端判断是否在规定时间内未收到所述接收端的响应，如果是则进入步骤D3；
D3所述发送端判断所述高版本消息重新发送的次数是否达到了门限，如果是则进入所述步骤A，否则进入步骤D1。
所述步骤B还包含以下子步骤：
当消息版本与双方都能够支持的最高协议版本不一致时，所述接收端丢弃所述低版本消息。
所述协议是通用无线分组服务隧道协议。
所述低版本消息是无线分组服务隧道协议版本0的消息。
在所述步骤A中，所述发送端在所述低版本消息的头部第一个字节2～4位携带表示其能够支持的最高协议版本的信息。
所述步骤B中，所述接收端通过向发送端发送版本不支持消息，通知发送端使用双方都能够支持的最高协议版本进行通讯，其中，
所述版本不支持消息的头部第一字节2～4位携带表示双方都能够支持的最高通用无线分组服务隧道协议版本信息。
在所述步骤B中，所述接收端通过新增通用无线分组服务隧道协议消息的类型或扩展头，通知发送端使用双方都能够支持的最高版本进行通讯。
还包含以下步骤：
C所述发送端根据接收端的通知，使用高版本与接收端进行通讯。
通过比较可以发现，本发明的技术方案与现有技术的区别在于，首先，在发送端向接收端发送的低版本消息中，携带有发送端能够支持的最高协议版本号；第二，当接收端判定来自发送端的消息版本与双方都能够支持的最高协议版本不一致时，通知发送端使用双方都能够支持的最高版本进行通讯。
这种技术方案上的区别，带来了较为明显的有益效果，即发送端能够更为准确地判断接收端GSN设备的GTP协议版本，避免误判以及由此带来的一系列问题。
另外，本发明不需要对当前网上运行的仅支持低版本，即GTP version 0的GSN设备进行改造，保护了现有投资；并充分利用现有协议，消息格式仅在原来的基础上稍做改动，容易实现；另外，还可以缩短版本探测需要消耗的时间。
附图说明
图1是图1是根据本发明的一个实施例的协议版本探测方法示意图；
图2是根据本发明的另一个实施例的协议版本探测方法示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述。
本发明希望能够保证各GSN间按照双方均支持的最高GTP协议版本进行交互，即使暂时无法在高版本端口上建立通讯，也不在低版本上建立会话。
首先参照表1，说明协议3GPP TS 09.60中对低版本GTP version 0的消息头格式第一个字节规定。
表1
| Bits | |||||||||
| Octets | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | |
| 1 | Version | PT | Spare“111” | SNN | |||||
表1中的第2～4位保留未使用，发送端应该将其设置为全“1”，接收方在处理低版本GTP version 0消息时将忽略这3位，不管其具体填写的什么值。
本发明中，通过低版本GTP version 0消息头第一个字节2～4位的保留字段来携带发送端支持的最高GTP协议版本。
具体地说，对于只支持低版本GTP version 0的GSN系统，不需要变动。而对于支持高版本GTP version 1的GSN系统，在兼容实现低版本GTPversion 0时，需要在3GPP TS 09.60的基础上做一些相应的变化：当发送端向接收端发送GTP version 1版本的消息，而接收端没有响应时，发送端将降低到GTP version 0版本继续进行版本探测。此时，发送端将GTP version0消息头第一个字节2～4位设置为本端支持的最高GTP协议版本“001”。
下面结合图1，详细描述根据本发明的一个实施例的各个步骤。需要说明的是，本发明适用于发送端支持高版本，即GTP version 1的情况。
如图1所示，步骤103：发送端向接收端发送N次高版本，即GTP version1版本的消息。
当接收端未接收到来自发送端的消息，或响应被丢弃时，发送端重发GTP version 1版本的消息，直至重发次数达到预先设定的门限值“N”为止，进入步骤104。
步骤104：发送端向接收端发送低版本，即GTP version 0版本的消息。其中携带有表示发送端能够支持的最高协议版本的信息。
在这一步骤中，由于发送端N次发送了高版本的GTP version 1的消息，而未收到来自接收端的响应，为了能够建立通讯，降低了版本，继续向接收端发送消息。但是在该消息中，虽然使用的是低版本GTP version 0，但是消息中包含了表示发送端能够支持的最高协议版本的信息。
为了实现这个步骤，发送端可以将低版本消息的头部第一个字节2～4位设置为本端支持的最高GTP协议版本“001”。
步骤105：接收端接收到发送端的低版本，即GTP version 0消息，判断该消息版本是否与双方都能够支持的GTP最高协议版本一致。
也就是说，接收端通过低版本消息中所携带的表示发送端能够支持的最高协议版本的信息、低版本消息本身的版本信息，以及自己能够支持的最高协议版本，判断发送端是否使用了双方都能够支持的最高协议版本。
如果一致，即发送端使用了双方都能够支持的最高协议版本，则继续后续处理；否则，也就是未使用双方都能够支持的最高协议版本，则进入步骤106。
在步骤106中，接收端通知发送端使用双方都能够支持的最高版本进行通讯。
为了实现这个步骤，在本实施例中，接收端向发送端发送低版本，即GTP version 0格式的“Version Not Supported”消息，在该消息头部第一字节2～4位的“Version”字段填写表示双方都能够支持的最高GTP协议版本的信息：“001”。
接着进入步骤107，在该步骤中，发送端根据接收到的“Version NotSupported”消息，确定接收端能够支持高版本，即GTP version 1的信息，因此使用高版本，即GTP version 1版本与接收端进行消息交互，由此不再尝试降低GTP协议版本。
另外需要说明的是，当发送端GSN设备已经和接收端GSN设备明确后续使用低版本GTP version 0版本进行消息交互后，在低版本GTP version 0消息头第1个字节2～4位(参见表1)仍然填写保留值全“1”，接收方对第1字节2～4位填写位全“1”的GTP version 0消息，不进行版本校验，正常处理。
为了更好的表述本发明的原理，下面根据上述实施例，举一个具体的例子：假设SGSN和GGSN支持的最高协议版本均为GTP version 1，但由于某些原因导致SGSN在尝试与GGSN通过高版本通讯时失败，由此降为低版本，即GTP version 0重新探测。
根据本发明，SGSN在低版本，即GTP version 0消息头第一个字节2～4位设置为本端支持的最高GTP协议版本“001”。GGSN在3386端口接收到该请求消息后，发现本端和对端都能够支持的最高版本高于目前使用的低版本，就向SGSN的3386端口返回一个版本不支持消息，即“Version NotSupported”消息，该消息头部第一字节2～4位“Version”填写双方都能够支持的最高GTP协议版本信息：“001”，从而通知SGSN两者都能够支持的最高版本为Version 1，SGSN响应来自接收端的消息，直接使用高版本GTP version 1与接收端进行通讯。
下面参照图2，详细描述根据本发明的另一个实施例。本实施例包含以下步骤：
步骤201：发送端向接收端发送低版本，即GTP version 0的消息，该消息中携带发送端本身支持的最高GTP协议版本信息；
接着进入步骤202，接收端接收到发送端的低版本，即GTP version 0消息，判断该消息版本是否与双方都能够支持的GTP最高协议版本一致。
在本实施例中，接收端是通过低版本消息中携带的发送端本身支持的最高GTP协议版本信息、低版本消息的版本信息，以及接收端自身能够支持的最高GTP协议版本信息完成判断的。
如果一致，表示接收端能够支持的最高GTP协议版本为低版本，因此继续后续处理；否则，表示接收端能够支持的最高GTP协议版本为高版本，则进入步骤203。
在步骤203中，由于接收端判定发送端使用的GTP协议版本低于双方都能够支持的版本，因此，接收端通知发送端使用双方都能够支持的最高版本进行通讯。
具体地说，接收端向发送端发送低版本，即GTP version 0格式的“Version Not Supported”消息，该消息头部第一字节2～4位“Version”填写双方都能够支持的最高GTP协议版本信息：“001”。
此后进入步骤204，在该步骤中，发送端根据接收到的上述“VersionNotSupported”消息，确定接收端能够支持高版本，即GTP version 1的信息，因此使用高版本，即GTP version 1版本与接收端进行通讯。
在该实施例中，发送端先使用带有版本探测功能的低版本消息通信，如果接收端发现双方可以用更高版本的协议通信，则通知发送端改用高版本协议通信。这种做法可以省去前一个实施例中由于接收端不支持高版本通信协议而导致的发送端多次重试的时间和资源开销，适用于系统中仅支持低版本的设备较多的情况。
基于对上述背景技术和实施里中本发明的技术，不难发现，在背景技术中的GTP协议版本探测方案中，发送端在接收端没有响应时自动降低版本的做法并没有问题，造成误判的主要因素是接收方在接收到发送方降低版本后发送的GTP version 0消息时，认为发送方支持的GTP最高协议版本与发送的消息的版本一致，从而同意使用较低的GTP version 0版本与发送方进行通讯。
在本发明中，当发送端在降低GTP协议版本向接收端发送低版本的消息时，同时将发送端能够支持的最高GTP协议版本信息设置在消息中带给接收方，因此，接收端在接收到低版本的消息后，能够知道对端实际上支持的最高GTP协议版本为GTP version 1，如果接收方自己的最高GTP协议支持版本也是GTP version 1，那么接收方就能够判断双方能够支持的最高协议版本是GTP version 1，并用消息通知发送方，要求对方使用GTP version 1进行消息交互。
虽然通过参照本发明的某些优选实施例，已经对本发明进行了图示和描述，但本领域的普通技术人员应该明白，可以在形式上和细节上对其作各种各样的改变，而不偏离所附权利要求书所限定的本发明的精神和范围。例如，在GTP version 1以上版本可以引入新的扩展头类型替代本方案中使用GTPversion 0版本消息第1个字节2～4位来标识本端最高支持版本。
Claims (9)
1.一种通信系统中的协议版本探测方法，其特征在于，包含以下步骤：
A发送端向接收端发送低版本消息，所述消息中携带有表示发送端能够支持的最高协议版本的信息；
B所述接收端根据所述低版本消息，判断该消息版本是否与双方都能够支持的最高协议版本一致，如果是，则继续后续处理；否则所述接收端通知发送端使用双方都能够支持的最高协议版本进行通讯。
2.根据权利要求1所述的通信系统中的协议版本探测方法，其特征在于，在所述步骤A之前，还包含以下步骤：
D1所述发送端向所述接收端发送高版本消息；
D2所述发送端判断是否在规定时间内未收到所述接收端的响应，如果是则进入步骤D3；
D3所述发送端判断所述高版本消息重新发送的次数是否达到了门限，如果是则进入所述步骤A，否则进入步骤D1。
3.根据权利要求1所述的通信系统中的协议版本探测方法，其特征在于，所述步骤B还包含以下子步骤：
当消息版本与双方都能够支持的最高协议版本不一致时，所述接收端丢弃所述低版本消息。
4.根据权利要求1所述的通信系统中的协议版本探测方法，其特征在于，所述协议是通用无线分组服务隧道协议。
5.根据权利要求4所述的通信系统中的协议版本探测方法，其特征在于，所述低版本消息是无线分组服务隧道协议版本0的消息。
6.根据权利要求5所述的通信系统中的协议版本探测方法，其特征在于，在所述步骤A中，所述发送端在所述低版本消息的头部第一个字节2～4位携带表示其能够支持的最高协议版本的信息。
7.根据权利要求5所述的通信系统中的协议版本探测方法，其特征在于，所述步骤B中，所述接收端通过向发送端发送版本不支持消息，通知发送端使用双方都能够支持的最高协议版本进行通讯，其中，
所述版本不支持消息的头部第一字节2～4位携带表示双方都能够支持的最高通用无线分组服务隧道协议版本信息。
8.根据权利要求3所述的通信系统中的协议版本探测方法，其特征在于，在所述步骤B中，所述接收端通过新增通用无线分组服务隧道协议消息的类型或扩展头，通知发送端使用双方都能够支持的最高版本进行通讯。
9.根据权利要求1所述的通信系统中的协议版本探测方法，其特征在于，还包含以下步骤：
C所述发送端根据接收端的通知，使用高版本与接收端进行通讯。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB031578772A CN100502270C (zh) | 2003-09-13 | 2003-09-13 | 通信系统中的协议版本探测方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB031578772A CN100502270C (zh) | 2003-09-13 | 2003-09-13 | 通信系统中的协议版本探测方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN1595860A true CN1595860A (zh) | 2005-03-16 |
| CN100502270C CN100502270C (zh) | 2009-06-17 |
Family
ID=34660389
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNB031578772A Expired - Fee Related CN100502270C (zh) | 2003-09-13 | 2003-09-13 | 通信系统中的协议版本探测方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN100502270C (zh) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7685291B2 (en) | 2005-11-08 | 2010-03-23 | Mediatek Inc. | Messaging service interoperability methods and related devices |
| CN101018231B (zh) * | 2007-02-07 | 2010-05-26 | 重庆重邮信科通信技术有限公司 | 一种自适应协议版本的探测方法 |
| WO2010060328A1 (zh) * | 2008-11-27 | 2010-06-03 | 华为技术有限公司 | 一种确认版本信息的方法、装置及系统 |
| CN106933546A (zh) * | 2015-12-29 | 2017-07-07 | 施耐德电器工业公司 | 用于支持至少两个版本的电力系统文件的装置、方法和设备 |
| WO2019037458A1 (zh) * | 2017-08-22 | 2019-02-28 | 深圳市道通智能航空技术有限公司 | 通信方法和装置 |
| CN115038052A (zh) * | 2022-06-02 | 2022-09-09 | 阿波罗智联(北京)科技有限公司 | 一种消息集处理方法、装置、设备及存储介质 |
-
2003
- 2003-09-13 CN CNB031578772A patent/CN100502270C/zh not_active Expired - Fee Related
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7685291B2 (en) | 2005-11-08 | 2010-03-23 | Mediatek Inc. | Messaging service interoperability methods and related devices |
| CN101018231B (zh) * | 2007-02-07 | 2010-05-26 | 重庆重邮信科通信技术有限公司 | 一种自适应协议版本的探测方法 |
| WO2010060328A1 (zh) * | 2008-11-27 | 2010-06-03 | 华为技术有限公司 | 一种确认版本信息的方法、装置及系统 |
| CN106933546A (zh) * | 2015-12-29 | 2017-07-07 | 施耐德电器工业公司 | 用于支持至少两个版本的电力系统文件的装置、方法和设备 |
| WO2019037458A1 (zh) * | 2017-08-22 | 2019-02-28 | 深圳市道通智能航空技术有限公司 | 通信方法和装置 |
| CN115038052A (zh) * | 2022-06-02 | 2022-09-09 | 阿波罗智联(北京)科技有限公司 | 一种消息集处理方法、装置、设备及存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN100502270C (zh) | 2009-06-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN100345396C (zh) | 用于在移动通信系统中执行越区切换的方法 | |
| EP1742413B1 (en) | A method of starting the session of multimedia broadcast multicast service | |
| AU2005204215A1 (en) | Repairing errors in data of MBMS service | |
| CN1910839A (zh) | 用于建立移动终端的无线承载的装置和方法 | |
| CN1910841A (zh) | 在无线通信系统中发射和接收用于点对多点服务的控制信息的通知 | |
| CN1787656A (zh) | 通信系统中的时效处理设备和方法 | |
| WO2007121409A1 (en) | Methods and apparatus for resource management architectures for internet protocol based radio access networks | |
| CN1934824A (zh) | 用于对在移动分组无线电系统中的流式连接计费的方法和系统 | |
| CN1736081A (zh) | 对移动ip的网络支持的早期确定 | |
| CN1666541A (zh) | 用于在无线网络之间漫游的系统和方法 | |
| CN1852596A (zh) | 区分业务级别发送寻呼消息的方法和系统 | |
| CN1960311A (zh) | 一种通用移动通信系统网络与演进网络互连的系统与方法 | |
| CN1595860A (zh) | 通信系统中的协议版本探测方法 | |
| CN1177434C (zh) | 基于通用陆地无线接入网接口的多播业务的实现方法 | |
| CN107018555A (zh) | 网络接入方法、网络接入控制方法、用户终端及基站 | |
| CN1255968C (zh) | 用于无线电信网络的系统 | |
| CN1710967A (zh) | 一种协议数据单元的转发方法 | |
| US20070258416A1 (en) | Assigning An Access Terminal Identifier To A Mobile Node | |
| CN1283055C (zh) | 一种对创建分组数据协议上下文请求的处理方法 | |
| CN1949921A (zh) | 一种演进后网络中用户终端接入核心网的方法 | |
| CN1909728A (zh) | 根据网络资源识别码选择核心网的方法 | |
| CN1738285A (zh) | 错误指示报文处理方法 | |
| CN1671123A (zh) | 一种使用不同版本的ip协议的gsn之间的通讯方法 | |
| CN1585505A (zh) | 服务无线网络控制器查询信道类型的方法 | |
| CN1852542A (zh) | 一种用户呼叫故障检测方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| CF01 | Termination of patent right due to non-payment of annual fee | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20090617 Termination date: 20200913 |