业务攻略CDMA网络数据业务VPDN用户跨交换局切换掉话的解决方法最新版Word下载.docx
《业务攻略CDMA网络数据业务VPDN用户跨交换局切换掉话的解决方法最新版Word下载.docx》由会员分享，可在线阅读，更多相关《业务攻略CDMA网络数据业务VPDN用户跨交换局切换掉话的解决方法最新版Word下载.docx（6页珍藏版）》请在冰豆网上搜索。
测试方法分为登录到用户的专网数据库查询资料和于数据库中下载资料。
2．问题描述
测试时首先启动CDMA-1X专网用户上网卡，然后再启动专网客户端软件VRC，连接专用隧道，登录到专网服务器。
这批上网卡不能登录互联网，只能通过隧道登录到用户的专网。
于定点测试时非常顺利，上传和下载的速率均很快，但于移动状态下测试时出了问题。
首先发当下南三环洋桥以西车辆移动中IE软件会不定时的不能打开网页和下载数据，这时上网卡的连接状态正常，瞬时流量显示为零，VCR显示停止隧道连接，重新连接VCR时显示和专网服务器的连接错误；
断开上网卡重新连接后，VCR仍然显示和专网服务器的连接错误；
大约20分钟以后才能重新连接成功。
（下图为连接失败时的VCR画面截屏，部分名称隐去）。
于不能连接专网服务器的地点停车后查询这张上网卡于PDSN系统和交换系统的数据均正常，且且使用普通CDMA-1X上网卡连接互联网后均可正常使用，初步判断和无线部分无关。
由于这批做测试的上网卡是临时数据，用户方能够对卡的用户名和密码进行重置，所以初步怀疑是由于上网卡重名登录或IP地址相同的原因造成；
于用户单位的系统中没有查到相同的用户名，为稳妥起见将用户名、密码和上网卡的IMSI绑定。
于以后几天的测试中仍是发当下不同地区、不定时的出现上述问题。
3．问题的定位
于和PDSN工程师讨论问题时他们说以前也出现过类似的专网用户掉话后不能重新连接的现象，当时的处理方法是于PDSN侧将卡的登记信息定时释放，重新连接就行了，这种问题存于大约有俩年的时间了，壹直未能彻底解决。
于后几天的测试中发现出现问题的地区基本上于交换机的局边界附近，为了证实这个判断，用壹张专网上网卡和壹张普通上网卡于第壹、四交换局边界做对比测试。
测试中发现通过交换局边界时专网上网卡依旧出现老问题，但普通上网卡能正常使用，由此判断问题可能出当下交换局边界和PDSN部分。
CDMA－1X分组网的组网方式分为SIP（SimpleIP）和MIP（MobileIP）俩种，SIP和MIP的有以下几点主要区别：
SIP（SimpleIP）
1.如传统拨号网络，用户每次使用数据业务时均需进行拨号连接
2.每次接入得到不同的IP地址
3.用户跨PDSN的漫游将导致连接的中断
4.只能支持用户端主动发起的业务（“GetService”）。
普通Internet浏览，Email，FTP，VOD，网络游戏，网上聊天等等
MIP（MobileIP）
1.“AlwaysOnline”
2.用户终端保持固定的IP地址
3.能够跨PDSN漫游，不会导致连接的中断
4.即支持用户端发起的业务，又支持网络端发起的业务（“PushService”）。
专网接入，信息订制等
MobileIP真正的意义不于于PDSN间切换时不断线，而于于IP地址携带。
北京联通的CDMA-1X分组网采用SIMPLEIP结构，主要网元由9个MSC、2个FACN、11个PDSN组成。
下图为带有FACN部分的SimpleIP的网络结构图：
FACN是PDSN的信令控制节点，是整个PDSN系统中的壹个可选组件，如果不选用，PDSN系统能够照常工作，如果选用，PDSN系统能够提供很多其它功能。
FACN的主要功能是收集PDSN工作的情况信息、监控PDSN的工作状态、选择和分配PDSN，实现PDSN负载控制。
FACN能够将最多250个PDSN卡组成壹个虚拟的PDSN组，整个PDSN组从PCF角度见是壹个标准的“大”PDSN，这个“大”PDSN容量能够达到1,000,000个连接。
下面俩图是SIP的有FACN的2个PCF和2个PDSN切换的PPP建立和IMSI鉴权的流程图：
普通的上网卡用户于进行PPP连接跨交换局切换时按以下流程操作：
1、MN和PAN/PCF之间完成了TCH的建立，PCF已经成功配置了壹个FACN的IP地址，且且向FACN发送壹个R-PRegistrationrequest。
2、FACN查数据库找到壹个最佳的PDSN来处理该呼叫，PDSN的选择原则如下：
FACN根据IMSI查数据库见该IMSI的信息是否处于某壹个PDSN中，若是，则选择该PDSN；
否则选择壹个负荷最轻的PDSN。
3、FACN向PCF发送壹个R-Pregistrationreply（rejectcode域为136），其中PDSN的IP地址就是所选择的PDSN的IP地址。
4、PCF重新发送R-Pregistrationrequest到所选择的PDSN，PDSN发回壹个表示成功的消息完成了PCF和PDSN间R-PSession的建立。
5、然后于MN和PDSN间进行LCP层消息的交互，目的是进行链路层参数的协商，鉴权方式的选择，目前选用CHAP的方式。
6、PDSN发送壹个含有随机数的CHAPchallenge到MN，MN根据用户密码和收到的随机数计算出壹个应答参数，且将该参数连同用户名壹起于CHAPresponse发送给PDSN。
7、PDSN向FACN发送壹条FACNRegistrationrequestmessage，其中含有IMSI和NAI，FACN根据IMSI和NAI查找IMSI数据库判断是否有关联记录存于。
8、FACN发送壹条含有存于关联记录或者不存于关联记录信息和关联ID的FACNRegistrationreply消息到源PDSN。
9、PDSN和FAAA、HomeRADIUS进行RADISU鉴权。
10、PDAN发送CHAPAccept给MN，MN和PDSN进行IPCP协商获得IP地址，简单的IPSession建立完成。
11、源PDSN发送FACNregistrationupdate给FACN，其中含有NAI和IMSI；
FACN利用FACNregistrationupdate消息中的信息建立壹个对应的IMSI数据库的接口，且且向源PDSN发送壹条应答消息FACNRegUpdateAck。
至此壹条于MN、源PCF和源PDSN间的SIPsession建立成功。
12、MN于进行切换时，Session进入休眠状态（PCF发送壹条含有ActiveStop的R-PRRQ消息给源PDSN）；
PDSN发送壹条R-PRRQ给PCF。
PDSN端SIPsession进入休眠状态，这时进行跨局间的PCF切换。
13、MN切换到目标PCF；
MN建立业务信道。
14、目标PCF配置有壹个FACN的IP地址；
且且向FACN发送壹条R-PRegistrationrequest消息。
15、FACN查数据库找到壹个最佳的PDSN来处理该呼叫，FACN根据IMSI查数据库见该IMSI的信息是否处于某壹个PDSN中，若是，则选择该PDSN；
于图2中，由于PDSN和PCF的分组原因，FACN不能为该呼叫继续分配源PDSN；
此时，FACN会回壹条R-PRegistrationreply消息到目标PCF，其中含有最佳的目标PDSN地址。
16、目标PCF重新发送R-Pregistrationrequest消息到所选择的PDSN；
进行R-P隧道的建立；
然后于MN和PDSN间进行LCP层消息的交互，目标PDSN发送壹条含有随机数的CHAPchallenge到MN；
MN再根据用户密码和收到的随机数计算出壹个应答参数，且将该参数连同用户名壹起于CHAPresponse发送给目标PDSN。
17、目标PDSN向FACN发送壹条FACNRegistrationrequestmessage，其中含有IMSI和NAI；
FACN根据IMSI和NAI查找IMSI数据库判断是否有关联记录存于。
于这个流程中，FACN找到于源PDSN中存于壹个dormant的SIPSession，需要源PDSN撤除该Session；
18、FACN发送壹条含有IMSI和NAI信息的registrationUpdate到源PDSN；
源PDSN进行和源PCF之间PPPSession和R-PSession的撤除；
源PDSN发送壹条含有存于关联记录或者不存于关联记录信息的FACNRegistrationAcknowledge消息到FACN；
FACN发送壹条含有存于关联记录或者不存于关联记录信息和关联ID的FACNRegistrationreply到目标PDSN；
19、目标PDSN和FAAA、RADIUS进行RADIUS的鉴权；
且且发送壹条CHAPAccept消息到MN；
MN和目标PDSN进行IPCP协商获取IP地址。
20、目标PDSN发送FACNregistrationupdate到FACN，其中含有NAI和IMSI；
FACN根据这条消息中的信息进行IMSI数据库接口的更新。
21、于MN、目标PCF和目标PDSN间完成了SIPSession的建立，且且完成了这次于2个PCF和2个PDSN间的跨局切换。
从图1的流程来见，所有操作似乎均是正常的；
但到图2进行切换后重新连接出现问题，初步怀疑是于15～17步骤有问题，就是图2中画红圈的部分。
找到了问题的大致方向后，于接下来的跨局边界的测试时于FACN中查找专网上网卡切换前后的PDSN的关联记录，可是没有找到，下图是于FACN中的记录信息，能够清楚的见到包含用户的IMSI，LASTPDSN的IP地址，连接状态和用户名（也能够用域名做用户名）。
由于于核心网中没有查到关于LASTPDSN的消息，所以只能使用lincheck命令于企业网的LNS端查询上网卡连接PDSN的状态，下图是连接PDSN的信息：
上图中画红线的用户跨局后同时占用俩个PDSN，上网卡已不能正常使用，让机房将这个用户于PDSN侧释放以后可正常使用；
画兰线的用户跨局后只占用壹个PDSN，能够正常使用。
对之上结果的分析是跨局后于重新分配PDSN时恰好是源PDSN最空闲，所以仍分配到源PDSN，能够建立PPP连接；
这时如果是另壹PDSN空闲，则分配到新的PDSN，产生新的IP地址，就出现了测试中遇到的问题。
下面以MN发起隧道的VPDN为例，介绍基本消息流程：
首先的过程是CDMA1X空中接口的建立，本文不做详细讨论。
1．PCF向PDSN发起注册请求，这个消息是A11接口的标准消息；
2．PDSN给PCF注册响应；
3．PPP的LCP（链路控制协议）协商阶段，这个阶段也是PPP的初始阶段，主要是于PDSN和终端之间进行协商，包括认证方式和是否进行加密等；
4．LCP协商成功后，终端向PDSN发起认证请求；
5．PDSN向AAA发起认证请求，这个消息是RADIUS的标准消息，其中带有用户名密码等信息；
6．AAA收到请求后，对用户名密码进行认证，发现是VPDN用户，通过授权把关联属性参数发给PDSN。
包括VPDN的类型、隧道密码、LNS的IP地址等；
7．PDSN收到各种关于VPDN的属性，通过L2TP协议和企业端LNS建立隧道；
8．LNS发起进行隧道验证；
9．LNS和PDSN（LAC）之间的会话建立；
10．PDSN会把之前第3步中协商后的参数转发给LNS，特别注意的是，这壹步LNS能够要求和终端进行LCP的重协商，图例是没有进行LCP的重协商的，是否进行重协商取决于LNS的配置和终端是否支持LCP的重协商。
11．企业内部AAA对用户进行认证；
12．LNS给终端发送认证成功的消息；
13．认证成功后，进入PPP的IPCP阶段，由企业的LNS分配IP地址；
14．VPDN用户到企业网PPP连接建立。
于CDMA－1X分组网中，普通上网卡用户是由FACN选定空闲的PDSN，且由PDSN向MN分配IP地址，再向FACN发送关联信息；
但对于VPDN用户来说FACN选定空闲的PDSN后，由PDSN通L2TP协议向LNS发送通过授权的用户信息及关联属性参数，这时的PDSN只起到路由器的功能，MN获得的是由LNS分配的IP地址，和普通用户建立PPP有所不同，其中IPCP的过程是由终端和LNS之间完成的，所以PDSN不知道用户最终分配的IP地址。
另外，基于终端发起的VPDN业务壹般需要进行二次认证，终端需于企业端RADIUS服
务器通过认证后，再和企业LNS建立隧道，流程和上述流程略有不同。
4．问题的解决
通过之上的测试和分析，产生问题的原因已经基本定位于FACN和PDSN之间的消息对话和关联信息的传送和保存、调用的步骤上。
这时将测试用的专网上网卡于系统中绑定到壹个固定的PDSN上，于跨交换局切换重新建立PPP连接时测试正常。
于系统中查见发现切换前建立PPP连接时PDSN未向FACN发送FACNregrequest消息，导致于FACN中没有存储第壹次登陆时的MN的关联信息及IP地址，于跨局切换后建立连接时需要从FACN中调取上次登陆的信息时，系统没有找到，便认为是壹次新的连接，找LNS协商分配新的IP地址，由于上次的连接且没有断开，所以第二次于LNS和企业网AAA处鉴权时未通过，但能够见到有俩个PDSN的连接。
为了验证上述分析结果，于模拟这个测试时加入FACN和PDSN之间的对话消息，测试结果正常，专网上网卡能够于交换机间正常切换且且不掉话，能够完成整个呼叫流程。
经过和设备厂商的核实，确实是漏掉了对于VPDN用户于第壹次建立PPP连接时由PDSN向FACN发送MN的关联信息及IP地址。
目前已让设备厂商修改软件中的这个Bug。
至此圆满的解决了CDMA-1X网络VPDN用户于移动中无线上网时掉话的问题，提高了用户的感受度，进壹步的提升了北京联通的网络质量。
参考文献
[1]CDMA1xIntroductionExternal
[2]Wireless3GDataSystemOverview
[3]Cisco_PDSN_SystemOverview
[4]CiscoCDMA_PDSNTroubleshootingguide
作者简介
常江，男，35岁，毕业于北京理工大学通信工程专业本科当下北京联通移动网络技术维护部网络优化室从事CDMA网络规划和优化工作。
地址北京市海淀区羊坊店路9-1号邮编100032
李辉友1976年5月出生贵州桐梓人2000年毕业于电子科技大学学士学位工作单位中国联通北京分公司移动网络技术维护部主要从事CDMA网络的优化工作。
升级会员 