CN1700787A - Gs接口的消息处理方法 - Google Patents
Gs接口的消息处理方法 Download PDFInfo
- Publication number
- CN1700787A CN1700787A CN 200410044305 CN200410044305A CN1700787A CN 1700787 A CN1700787 A CN 1700787A CN 200410044305 CN200410044305 CN 200410044305 CN 200410044305 A CN200410044305 A CN 200410044305A CN 1700787 A CN1700787 A CN 1700787A
- Authority
- CN
- China
- Prior art keywords
- message
- request
- location
- update
- support node
- 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
- Mobile Radio Communication Systems (AREA)
Abstract
本发明涉及通信领域，公开了一种Gs接口的消息处理方法，能够保证SGSN在Gs接口更新冲突流程中能够根据实际情况进行正确处理。这种Gs接口的消息处理方法包含以下步骤：当移动交换中心/拜访位置寄存器拒绝来自通用分组无线业务服务支持节点的一条用户位置更新请求时，移动交换中心/拜访位置寄存器向通用分组无线业务服务支持节点发送拒绝消息，并且，拒绝消息中包含用户位置更新请求消息中该用户当时的位置信息；通用分组无线业务服务支持节点根据位置信息，确定该拒绝消息所对应的那条用户位置更新请求。
Description
技术领域
本发明涉及通信领域，特别涉及码分多址通信系统中的Gs接口的消息处理技术。
背景技术
在码分多址(Code Division Multiple Access，简称″CDMA″)系统中，一个合法签约用户可以在分组域和电路域同时附着，由此能够同时进行分组域和电路域的通信业务。举例而言，在打电话的同时可以上网。对于配置了Gs接口，即通用分组无线业务服务支持节点(Serving GPRS Support Node，简称″SGSN″)与移动交换中心(Mobile Switching Center，简称″MSC″)/拜访位置寄存器(Visitor Location Register，简称″VLR″)之间的接口的情况，移动台(Mobile Station，简称″MS″)可以通过向分组域实体SGSN发送联合附着等方式，实现同时在分组域实体SGSN、以及电路域实体MSC/VLR附着。具体的说，当合法签约用户要求上述联合附着时，分组域实体SGSN通过向电路域体MSC/VLR发送一条″BSSAP+-LOCATION-UPDATE-REQUEST″消息，完成用户在电路域的附着。
图1示出现有技术中，典型的联合附着过程。如图所示，
在步骤110，MS向SGSN发送″attach request″消息，要求联合附着。此后，在步骤120，SGSN向MSC/VLR发送″BSSAP+-LOCATION-UPDATE-REQUEST″消息，要求位置更新。
接着，在步骤130，如果MSC/VLR接受位置更新请求，则向SGSN反馈″BSSAP+-LOCATION-UPDATE-ACCET″消息；另一方面，如果MSC/VLR不接受位置更新请求，则在步骤135中，向SGSN发送″BSSAP+-LOCATION-UPDATE-REJECT″消息。
此后，进入步骤140，SGSN向用户发送附着″attach accept″消息，通知MS联合附着结果是否成功，或仅仅在分组域附着成功，而在电路域附着失败。
其中，步骤120中的″BSSAP+-LOCATION-UPDATE-REQUEST″消息结构如表1所示，表1中各个信元具体结构可参见第三代合作伙伴项目(3rdGeneration Partnership Project，简称″3GPP″)29018协议相关章节。
表1：″BSSAP+-LOCATION-UPDATE-REQUEST″消息内容
| Information Element | Presence | Format | Length |
| Message type | M | V | 1 |
| IMSI | M | TLV | 6-10 |
| SGSN number | M | TLV | 5-11 |
| Update type | M | TLV | 3 |
| New Cell global identity | M | TLV | 10 |
| Mobile station classmark | M | TLV | 3 |
| Old location area identifier | O | TLV | 7 |
| TMSI status | O | TLV | 3 |
| New service areaidentification | O | TLV | 9 |
需要说明的是，表1中的″New Cell global identity″信元包含该合法签约用户当前所在的位置区(LA)。
在步骤130中的″BSSAP+-LOCATION-UPDATE-ACCEPT″消息结构如表2所示。其中，各信元具体结构参见3GPP 29018协议相关章节。
表2：BSSAP+-LOCATION-UPDATE-ACCEPT消息内容
| Information Element | Presence | Format | Length |
| Message type | M | V | 1 |
| IMSI | M | TLV | 6-10 |
| Location area identifier | M | TLV | 7 |
| New TMSI，or IMSI | O | TLV | 6-10 |
需要说明的是，表2中的″Location area identity″信元指示来自SGSN的″BSSAP+-LOCATION-UPDATE-REQUEST″消息中，″New Cell globalidentity″信元包含的MS当前所在的位置区信息。这就说明，SGSN接收到″BSSAP+-LOCATION-UPDATE-ACCEPT″消息后，可以通过将该消息中的″Location Area Identity″信元和自身发送的″BSSAP+-LOCATION-UPDATE-REQUEST″消息中的″New Cell globalidentity″信元包含的位置区对比，根据对比的结果，能够判定该″BSSAP+-LOCATION-UPDATE-ACCEPT″消息是否是本身发送的″BSSAP+-LOCATION-UPDATE-REQUEST″消息的响应。步骤135中的″BSSAP+-LOCATION-UPDATE-REJECT″消息结构如表3所示。其中，各信元具体结构参见3GPP 29018协议相关章节。
表3：BSSAP+-LOCATION-UPDATE-REJECT消息内容
| Information Element | Presence | Format | Length |
| Message type | M | V | 1 |
| IMSI | M | TLV | 6-10 |
| Reject cause | M | TLV | 3 |
如表3所示，MSC/VLR发送给SGSN的″BSSAP+-LOCATION-UPDATE-REJECT″消息中，不包含该用户的位置信息。
在实际应用中，上述方案存在以下问题：在实际环境中由于用户是处在不停的移动过程中，而从SGSN通知MSC/VLR进行位置更新到MSC/VLR更新完成给SGSN回响应间需要一定的时间，因此在这个时间段内，如果由于用户移动，MS又发起了联合附着过程，则SGSN将又要向MSC/VLR发起位置更新过程，这就引发了Gs接口上的位置更新流程冲突。
具体而言，在3GPP 29018-440协议中的相关描述如下：
1：如果用户新的LA和原来的相同，SGSN应该不向VLR发送″BSSAP+-LOCATION-UPDATE-REQUEST″消息，而是继续处理上一次的更新流程；
2：如果用户新的LA和原来的不同，则SGSN应该忽略VLR发送的第一个位置更新请求的任何响应(包括接收和拒绝)，并且向Gs接口发送一个新的″BSSAP+-LOCATION-UPDATE-REQUEST″消息，重新启动Gs接口上的位置更新流程。
上述描述可能有两种情况：第一种是VLR接受了SGSN第一次位置更新请求；另一种是VLR拒绝了SGSN第一次位置更新请求。
如果是第一种情况，从前面可以看出，SGSN能够区分出VLR发送到SGSN的″BSSAP+-LOCATION-UPDATE-ACCEPT″消息是SGSN发送的第一条位置更新请求消息的响应还是第二条的响应。如果SGSN发现是第一条的响应，那么根据协议描述，SGSN应该忽略之，SGSN可以做到按照协议描述正确处理。
如果是第二种情况，也就是VLR不接受SGSN的第一条位置更新请求，向SGSN发送了″BSSAP+-LOCATION-UPDATE-REJECT″消息，由于其中没有任何信息让SGSN判断该拒绝消息是第一条请求消息的响应还是第二条请求消息的响应，因此SGSN将无法准确处理。
由此可见，现有协议无法保证SGSN在Gs接口冲突流程中做到正确处理。
发明内容
有鉴于此，本发明的主要目的在于提供一种Gs接口的消息处理方法，使得保证SGSN在Gs接口更新冲突流程中能够根据实际情况进行正确处理。
为实现上述目的，本发明提供了一种Gs接口的消息处理方法，包含以下步骤：
D当移动交换中心/拜访位置寄存器拒绝来自通用分组无线业务服务支持节点的一条用户位置更新请求时，所述移动交换中心/拜访位置寄存器向通用分组无线业务服务支持节点发送拒绝消息，并且，所述拒绝消息中包含所述用户位置更新请求中该用户当时的位置信息；
E所述通用分组无线业务服务支持节点根据所述位置信息，确定该拒绝消息所对应的那条用户位置更新请求。
其中，所述方法还包含以下步骤：
F所述通用分组无线业务服务支持节点向用户转发该位置更新请求的拒绝消息。
所述方法还包含以下步骤：
A用户向通用分组无线业务服务支持节点发送附着请求；
B所述通用分组无线业务服务支持节点向移动交换中心/拜访位置寄存器发送位置更新请求。
所述步骤D还包含以下步骤：
当移动交换中心/拜访位置寄存器接受来自通用分组无线业务服务支持节点的一条位置更新请求时，向该通用分组无线业务服务支持节点发送接受消息，其中，所述接受消息中包含所述用户位置更新请求中该用户当时的位置信息。。
通过比较可以发现，本发明的技术方案与现有技术的区别在于，当移动交换中心/拜访位置寄存器拒绝来自通用分组无线业务服务支持节点的一条用户位置更新请求时，在反馈的拒绝消息中包含该用户位置更新请求消息中该用户当时的位置信息。
这种技术方案上的区别，带来了较为明显的有益效果，不但避免了SGSN直接将接收到的拒绝消息当作第二条请求消息的响应，并进行处理；也避免了SGSN认为该拒绝消息是第一条请求消息的响应，从而丢弃。由此确保了SGSN在Gs接口更新流冲突流程中根据实际情况进行正确处理。
另外，虽然在先行协议版本中，″BSSAP+-LOCATION-UPDATE-REJECT″消息中并没有″location area identity″信元，但是采纳本技术方案后不会导致采用本方案和没有采用本方案的设备间的互联互通问题。根据3GPP 29018的描述，SGSN和VLR都应该忽略接收到的Gs消息中的未知信元和非预期信元(见29018-440协议16.5节描述)。对于未采用本方案的SGSN而言，如果″BSSAP+-LOCATION-UPDATE-REQUEST″消息中出现了″location areaidentity″信元，那么SGSN将认为是未知信元，并忽略之，继续按照其自身处理方案处理，不会导致其他异常。。
附图说明
图1是现有技术中典型的联合附着过程示意图；
图2是根据本发明的一个实施例的联合附着过程示意图；
图3是根据本发明的一个实施例的更具体的联合附着过程示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述。
根据本发明的原理，要解决在WCDMA移动通信系统中移动用户在电路域和分组域联合附着过程中出现的Gs接口上的位置更新流程冲突问题。通过对移动交换中心(Mobile Switching Center，简称″MSC″)/拜访位置寄存器(Visitor Location Register，简称″VLR″)向通用分组无线业务服务支持节点(Serving GPRS Support Node，简称″SGSN″)返回拒绝联合附着的消息中增加一个″Location area identifier″信元，使得系统能正确处理更新流程，而不至于产生异常情况。图2示出了根据本发明的一个联合附着过程。这个联合附着过程主要由MS20、SGSN21和MSC/VLR22来完成的。
其中，MS20是用户的移动设备。熟悉本领域的人员应该知道，MS20可以是手机、个人掌上电脑、笔记本、等终端移动设备。
SGSN21主要是负责传输移动网络内的数据分组，以及完成对终端的移动性管理和数据传输相关的会话管理等功能。
MSC/VLR22是交换中心和一个数据库，它们在MS20的当前位置为其提供电路交换业务。
下面根据本发明的原理，具体描述联合附着过程。
如图2所示，首先在步骤210中，MS20向SGSN21发送″attach request″消息，要求联合附着，并进入步骤220。
在步骤220，SGSN21向MSC/VLR22发送″BSSAP+-LOCATION-PDATE-REQUEST″消息，要求位置更新，该消息结构如下表4所示：
表4
| Information Element | Presence | Format | Length |
| Message type | M | V | 1 |
| IMSI | M | TLV | 6-10 |
| SGSN number | M | TLV | 5-11 |
| Update type | M | TLV | 3 |
| New Cell global identity | M | TLV | 10 |
| Mobile station classmark | M | TLV | 3 |
| Old location area identifier | O | TLV | 7 |
| TMSI status | O | TLV | 3 |
| New service areaidentification | O | TLV | 9 |
需要说明的是，在上述表1中″Message type″信元表示消息类型，″IMSI″信元表示国际移动用户识别码，″SGSN number″信元表示服务GPRS支持节点数目，″Update type″信元表示更新类型，″New Cell globalidentity″信元表示新小取新小区全球识别码，它包含该合法签约用户当前所在的位置区(LA)信息，″Mobile station classmark″信元表示基站种类标记，″Old location areaidentifier″信元表示原位置区识别号，″TMSI status″信元表示临时移动用户识别号，″New service area identification″信元表示新服务区识别码。
随后，在步骤230中，如果MSC/VLR22接受位置更新请求，则向SGSN21返回一个″BSSAP+-LOCATION-UPDATE-ACCET″消息；而另一方面，如果MSC/VLR22不接受该位置更新请求，则在步骤235中，向SGSN21发送″BSSAP+-LOCATION-UPDATE-REJECT″消息。
其中，″BSSAP+-LOCATION-UPDATE-ACCET″消息结构如下表5所示。
表5
| Information Element | Presence | Format | Length |
| Message type | M | V | 1 |
| IMSI | M | TLV | 6-10 |
| Location area identifier | M | TLV | 7 |
| New TMSI，or IMSI | O | TLV | 6-10 |
需要说明的是，表5中的″New TMSI，or IMSI″信元表示新的临时移动用户识别号或者国际移动用户识别码，″Location area identifier″信元则指示来自SGSN21的″BSSAP+-LOCATION-UPDATE-REQUEST″消息中的″New CellGlobal Identity″信元包含的MS20当前所在的位置区LA1信息。
这样，SGSN21接收到″BSSAP+-LOCATION-UPDATE-ACCEPT″消息后，可以通过将该消息中的″Location area identifier″信元和自身发送的″BSSAP+-LOCATION-UpDATE-REQUEST″消息中的″New Cell GlobalIdentity″信元包含的位置区对比，根据对比的结果，能够判定该″BSSAP+-LOCATION-UPDATE-ACCEPT″消息是否是本身发送的″BSSAP+-LOCATION-UPDATE-REQUEST″消息的响应。
而在步骤135中，如果MSC/VLR22决定拒绝SGSN21发过来的″BSSAP+-LOCATION-UPDATE-REQUEST″请求，则MSC/VLR22应该从″BSSAP+-LOCATION-UPDATE-REQU-EST″消息中取出MS20所在的位置区LA1信息，并将该LA1信息填写到″BSSAP+-LOCATION-UPDATE-REJECT″消息中去。因此MSC/VLR22向SGSN21发送的拒绝联合附着消息″BSSAP+-LOCATION-UPDATE-REJECT″消息结构如下表6所示。
表6
| Information Element | Presence | Format | Length |
| Message type | M | V | 1 |
| IMSI | M | TLV | 6-10 |
| Reject cause | M | TLV | 3 |
| Location area identifier | M | TLV | 7 |
表6中的″Location area identifier″信元指示出了MSC/VLR22从″BSSAP+-LOCATION-UPDATE-REQUEST″消息中取出的MS20所在的位置区LA1信息，而″Reject cause″信元则表明了拒绝原因。SGSN21接受到这个″BSSAP+-LOCATION-UPDATE-REJECT″消息，就可以根据其中的″Locationarea identity″信元了解到MSC/VLR22拒绝了MSC20在步骤210中发出的″attach request″请求。
最后，在步骤240，SGSN21向MS20发送联合附着″attach accept″消息，通知MS20联合附着结果是成功，还是仅仅在分组域附着成功，而在电路域附着失败。
下面参照图3，进一步描述本发明的一个联合附着的具体过程。
如图所示，在步骤310中，MS30向SGSN31发送″attach request″消息1，请求联合附着，
随后，进入步骤320。
在步骤320，SGSN31向MSC/VLR32发送″BSSAP+-LOCATION-PDATE-REQUEST″消息，要求位置更新，该消息结构如表4所示，此时，表4中的″New Cell Global Identity″信元包含MS30当前所在的位置区LA2信息。
在实际环境里，由于MS30是在不间断的移动过程中的，而从SGSN31通知MSC/VLR32进行位置更新到MSC/VLR32更新完成给SGSN31回响应间需要一定的时间，因此在这个时间
段内，由于用户移动，MS30又发起了联合附着过程。即在步骤330，MS30向SGSN31又发送了一个″attach request″消息2。
需要说明的是，这个″attach request″消息2可能是MS30在原来的位置区LA2发过来的附着请求消息，也可能是MS30移动到了新的位置区LA3后发过来的附着请求消息。
在随后的步骤340，SGSN31接收到了由MSC/VLR32发过来的″BSSAP+-LOCATION-UPDATE-REJECT″消息，该消息结构正如前面的表6所示。″BSSAP+-LOCATION-UPDATE-
REJECT″消息中的″Location area identifier″信元指示出了位置区LA1信息。
如果在步骤330中，MS30向SGSN31发送的″attach request″消息2是MS30在原来的位置区
LA2发过来的附着请求消息，则在接下来的步骤350中，SGSN31通过分析″BSSAP+-LOCATION-UPDATE-REJECT″消息中的″Location areaidentifier″信元了解到MSC/VLR32拒绝的是MS30在位置区LA2发过来的附着请求，按照3GPP 29018-440协议中的规定，SGSN31应该不向MSC/VLR32发送″BSSAP+-LOCATION-UPDATE-REQUEST″消息，而是继续处理上一次的更新流程，从而进入步骤360。在步骤360，SGSN31向MS30发送
一个″attach reject″消息，表明MSC/VLR32拒绝附着请求。于是联合附着过程处理完毕。
另一方面，如果在步骤330中，MS30向SGSN31发送的″attach request″消息2是MS30在移
动到了新的位置区LA3后发过来的附着请求消息，则在接下来的步骤350中，SGSN31通过分析″BSSAP+-LOCATION-UPDATE-REJECT″消息中的″Location area identifier″信元了解到MSC/VLR32拒绝的是MS30在步骤310中由原先的位置区LA2发过来的附着请求，则SGSN31应该忽略MSC/VLR32发送的第一个位置更新请求的任何响应，并进入步骤365。在步骤365，SGSN31向MSC/VLR32发送一个新的″BSSAP+-LOCATION-UPDATE-REQUEST″消息，重新启动Gs接口上的位置更新流程，为了文章的简明，对接下去的重新启动的位置更新流程就不在重复叙述了。
从上面的说明，可以看出，本发明保证了SGSN在Gs接口更新冲突流程中能够根据实际情况进行正确处理。既避免了SGSN直接将接收到的拒绝消息当作第二条请求消息的响应，并进行处理；也避免了SGSN认为该拒绝消息是第一条请求消息的响应，从而丢弃。由此确保了SGSN在Gs接口更新流冲突流程中根据实际情况进行正确处理。另外，虽然在先行协议版本中，″BSSAP+-LOCATION-UPDATE-REJECT″消息中并没有″Location areaidentifier″信元，但是采纳本发明方案后不会导致采用本发明方案和没有采用本发明方案的设备间的互联互通问题。根据3GPP 29018的描述，SGSN和VLR都应该忽略接收到的Gs消息中的未知信元和非预期信元。对于未采用本发明方案的SGSN而言，如果″BSSAP+-LOCATION-UPDATE-REQUEST″消息中出现了″Location area identifier″信元，那么SGSN将认为是未知信元，并忽略之，继续按照其自身处理方案处理，不会导致其他异常。
虽然通过参照本发明的某些优选实施例，已经对本发明进行了图示和描述，但本领域的普通技术人员应该明白，可以在形式上和细节上对其作各种各样的改变，而不偏离所附权利要求书所限定的本发明的精神和范围。
Claims (4)
1.一种Gs接口的消息处理方法，其特征在于，包含以下步骤：
D当移动交换中心/拜访位置寄存器拒绝来自通用分组无线业务服务支持节点的一条用户位置更新请求时，所述移动交换中心/拜访位置寄存器向通用分组无线业务服务支持节点发送拒绝消息，并且，所述拒绝消息中包含所述用户位置更新请求中该用户当时的位置信息；
E所述通用分组无线业务服务支持节点根据所述用户当时的位置信息，确定该拒绝消息所对应的那条用户位置更新请求。
2.根据权利要求1所述的Gs接口的消息处理方法，其特征在于，所述方法还包含以下步骤：
F所述通用分组无线业务服务支持节点向用户转发该位置更新请求的拒绝消息。
3.根据权利要求1所述的Gs接口的消息处理方法，其特征在于，所述方法还包含以下步骤：
A用户向通用分组无线业务服务支持节点发送附着请求；
B所述通用分组无线业务服务支持节点向移动交换中心/拜访位置寄存器发送位置更新请求。
4.根据权利要求1所述的Gs接口的消息处理方法，其特征在于，所述步骤D还包含以下步骤：
当移动交换中心/拜访位置寄存器接受来自通用分组无线业务服务支持节点的一条用户位置更新请求时，向该通用分组无线业务服务支持节点发送接受消息，其中，所述接受消息中包含所述用户位置更新请求中该用户当时的位置信息。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB2004100443059A CN100359964C (zh) | 2004-05-21 | 2004-05-21 | Gs接口的消息处理方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB2004100443059A CN100359964C (zh) | 2004-05-21 | 2004-05-21 | Gs接口的消息处理方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN1700787A true CN1700787A (zh) | 2005-11-23 |
| CN100359964C CN100359964C (zh) | 2008-01-02 |
Family
ID=35476610
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNB2004100443059A Expired - Fee Related CN100359964C (zh) | 2004-05-21 | 2004-05-21 | Gs接口的消息处理方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN100359964C (zh) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2007076648A1 (fr) * | 2005-12-31 | 2007-07-12 | Zte Corporation | Procede de determination de criteres communs de gestion de la mobilite |
| CN100411470C (zh) * | 2006-07-31 | 2008-08-13 | 华为技术有限公司 | 处理联合位置业务Gs接口故障的方法及系统 |
| CN102548008A (zh) * | 2010-10-28 | 2012-07-04 | 宏达国际电子股份有限公司 | 处理低优先次序装置及机器型态装置的方法及其通讯装置 |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6438370B1 (en) * | 1998-06-16 | 2002-08-20 | Nokia Telecommunications, Oy | Location update method and inter core network entity handover method |
| FI20001512A (fi) * | 2000-06-26 | 2001-12-27 | Nokia Corp | Salaamattoman käyttäjäliikenteen kontrollointi |
| CN100349494C (zh) * | 2002-08-08 | 2007-11-14 | 中兴通讯股份有限公司 | 移动用户跨域漫游的方法 |
-
2004
- 2004-05-21 CN CNB2004100443059A patent/CN100359964C/zh not_active Expired - Fee Related
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2007076648A1 (fr) * | 2005-12-31 | 2007-07-12 | Zte Corporation | Procede de determination de criteres communs de gestion de la mobilite |
| CN1992968B (zh) * | 2005-12-31 | 2010-05-05 | 中兴通讯股份有限公司 | 一种移动性管理联合条件判定的方法 |
| CN100411470C (zh) * | 2006-07-31 | 2008-08-13 | 华为技术有限公司 | 处理联合位置业务Gs接口故障的方法及系统 |
| CN102548008A (zh) * | 2010-10-28 | 2012-07-04 | 宏达国际电子股份有限公司 | 处理低优先次序装置及机器型态装置的方法及其通讯装置 |
| US8773988B2 (en) | 2010-10-28 | 2014-07-08 | Htc Corporation | Method of handling communications of low priority device and MTC device in a wireless communication system and related communication device |
| TWI448124B (zh) * | 2010-10-28 | 2014-08-01 | Htc Corp | 處理無線通訊系統中低優先次序裝置及機器型態通訊裝置的方法及其通訊裝置 |
| CN102548008B (zh) * | 2010-10-28 | 2016-02-17 | 宏达国际电子股份有限公司 | 处理低优先次序装置及机器型态装置的方法及其通讯装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN100359964C (zh) | 2008-01-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN103907317A (zh) | 全异通信网络中的消息转发 | |
| CN101052200A (zh) | 一种移动通信系统中的路由更新方法 | |
| CN1567894A (zh) | 无线局域网和移动网互通情况下查询路由的方法 | |
| CN1523798A (zh) | 在ggsn、sgsn及rnc中有效更新mbms业务服务参数的方法 | |
| CN1917697A (zh) | 一种在核心网节点池内转移用户的方法与节点 | |
| CN1801959A (zh) | 移动通信系统和控制其操作的方法以及用于该系统的节点 | |
| CN101039523A (zh) | 联合用户迁移方法及通讯系统以及服务gprs支持节点 | |
| CN1859777A (zh) | 一种业务接入中实现pdp地址分配的方法 | |
| CN101064928A (zh) | 一种实现位置注册更新的方法 | |
| CN1893724A (zh) | 移动交换中心及其被叫处理方法 | |
| CN1852593A (zh) | 获取移动台签约区域信息的方法及移动台接入的判决方法 | |
| CN1700787A (zh) | Gs接口的消息处理方法 | |
| CN101064935A (zh) | 一种移动终端同时注册两种网络时的位置取消的方法 | |
| CN1243456C (zh) | 一种避免漫游用户被叫话路迂回的通信方法及其网络 | |
| CN1604555A (zh) | 实现无线局域网与gsm/gprs系统互通的方法 | |
| CN1829193A (zh) | 一种sgsn间路由区更新的方法 | |
| CN1585505A (zh) | 服务无线网络控制器查询信道类型的方法 | |
| CN1867187A (zh) | 基于iu flex技术实现用户呼叫接续的方法 | |
| CN1697551A (zh) | 用于在分组模式移动通信系统中改进移动性管理的方法 | |
| CN1374782A (zh) | 信息提供方法和移动通信系统以及通信装置 | |
| CN101051968A (zh) | 保持终端永远在线的方法及装置 | |
| CN1893723A (zh) | 移动通信系统中的漫游限制方法及其装置 | |
| CN101064937A (zh) | 一种漫游用户的归属地的接入方法及系统 | |
| CN1889748A (zh) | 处理联合位置业务Gs接口故障的方法及系统 | |
| CN1708144A (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 | ||
| C17 | Cessation of patent right | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20080102 Termination date: 20100521 |