中国移动WLAN业务PORTAL协议详情要求规范V200.docx
《中国移动WLAN业务PORTAL协议详情要求规范V200.docx》由会员分享，可在线阅读，更多相关《中国移动WLAN业务PORTAL协议详情要求规范V200.docx（32页珍藏版）》请在冰豆网上搜索。
中国移动WLAN业务PORTAL协议详情要求规范V200
QB-D-026-2008
中国移动通信企业标准
中国移动WLAN业务PORTAL协议规范
CMCCWLANServicePortalSpecification
版本号：
2.0.0
前言
本标准的目的是为了制定中国移动WLAN业务Portal规和协议。
本标准主要包括以下几方面容：
Portal协议，系统结构，上线/下线/页面配置/自服务功能流程，协议报文字段，参数及自服务功能描述。
本标准的附录A为资料性附录。
本标准由中移有限技〔2008〕49号印发。
本标准由中国移动通信技术部提出并归口。
本标准由标准归口部门负责解释。
本标准起草单位：
中国移动通信研究院
本标准主要起草人：
邵春菊，吕志虎，黄宇红，周文辉
围
本标准规定了中国移动WLAN业务Portal规和协议。
主要包括Portal协议，系统结构，上线/下线/页面配置/自服务功能流程，协议报文字段，参数及自服务功能描述等容。
供中国移动部和厂家共同使用；适用于中国移动开展WLAN业务采用强制门户时需遵循的标准。
规性引用文件
下列文件中的条款通过本标准的引用而成为本标准的条款。
凡是注日期的引用文件，其随后所有的修改单（不包括勘误的容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。
凡是不注日期的引用文件，其最新版本适用于本标准。
表1-1规性引用文件
[1]
《中国移动WLAN业务总体技术要求》
中国移动通信
[2]
1999Edition[ISO/IEC8802-11:
1999]
StandardsforLocalandMetropolitanAreaNetworks-WirelessLANMediumAccessControl（MAC）andPhysicalLayer（PHY）Specifications
IEEEStd.802.11
[3]
1999Edition[ISO/IEC8802-11:
1999]
StandardsforLocalandMetropolitanAreaNetworks-Part11:
WirelessLANMediumAccessControl（MAC）andPhysicalLayer（PHY）Specifications:
High-SpeedPhysicallayerExtensioninthe2.4GHzBand
IEEEStd.802.11b
[4]
2001
RecommendedPracticesforMulti-VendorAccessPointInteroperabilityviaInter-AccessPointProtocolacrossDistributionSystemssupportingIEEEP802.11operation
IEEE802.11f
[5]
2001
StandardsforLocalandMetropolitanAreaNetworks-Specificrequirements-Part11:
WirelessLANMediumAccessControl（MAC）andPhysicalLayer（PHY）specifications:
MediumAccessMethod（MAC）SecurityEnhancements
IEEE802.11i
[6]
RFC2865
RemoteAuthenticationDialInUserService（RADIUS）
IETF
[7]
RFC2866
RADIUSAccounting
IETF
[8]
RFC2869
RADIUSExtension
IETF
[9]
RFC2131
DynamicHostConfigurationProtocol
IETF
[10]
RFC2132
DHCPOptionsandBOOTPVendorExtensions
IETF
[11]
RFC1945
HypertextTransferProtocol--HTTP/1.0
IETF
[12]
RFC2616
HypertextTransferProtocol--HTTP/1.1
IETF
[13]
RFC2246
TheTLSProtocolVersion1.0
IETF
[14]
中国移动WLAN上网卡业务规
中国移动通信集团公司
术语、定义和缩略语
下列术语、定义和缩略语适用于本标准：
表1-2缩略语定义
词语
解释
AP
AccessPoint
AC
AccessController
DHCP
DynamicHostConfigurationProtocol
DNS
DomainNameService
HTTP
HyperTextTransportProtocol
NAI
NetworkAccessIdentifier
RADIUS
RemoteAuthenticationDialInUserService
WLAN
WirelessLocalAreaNetwork
AAA
Authentication，Authorization，Accounting
SSL
SecureSocketsLayer
CHAP
ChallengeHandshakeAuthenticationProtocol
Portal协议
1.2.WLAN用户类型及用户标识定义
WLAN用户类型
（1）“随e行”手机用户。
Ø全国用户，面向公众手机用户，覆盖中国移动“全球通”、“神州行”、“动感地带”品牌的所有用户。
用户鉴权数据信息分别存储在中央Radius（/密码认证方式）及HLR（SIM认证方式）中，按照用户管理归属地的不同，分为省BOSS/一级BOSS管理的手机用户及智能网SCP管理的手机用户两类。
通过“手机号+密码方式”或SIM认证方式认证后，使用GPRS/WLAN双模网卡、WLAN单模网卡上网的用户。
可以在全国围漫游。
BOSS管理的“随e行”手机用户可以采用两种计费方式。
一是按时长扣费计费方式，即用户按实际使用时长按时长扣费，“先使用、后扣费”；二是套餐计费方式，由用户选择套餐类型，按套餐金额预先扣费，“先订购、后使用”。
智能网管理的“随e行”手机用户可以采用按时长扣费计费方式，将来可以通过计费系统的改造支持对智能网手机用户的套餐计费方式。
（2）预付费卡用户：
包括全国预付费卡用户、映射到公网的奥运专网用户及省预付费卡用户。
Ø全国预付费卡用户，面向奥运期间的非持证记者及其他有漫游需求的预付费用户。
用户信息存储在中央Radius中，由中央Radius统一管理、计费。
可以在全国围漫游。
Ø映射到公网的奥运专网用户，面向奥运期间购买了专网的持证记者。
采用特殊全国预付费卡的方式解决，用户信息存储在中央Radius中，且与专网一一对应，由中央Radius统一管理。
不对此类用户计费和结算，使用有效期与奥运专网相同。
可以在全国围漫游。
Ø省预付费用户：
通过购买省预付费卡获得中国移动预付费。
用户信息存储在中央Radius中，由中央Radius统一管理、计费。
省预付费卡的使用围仅限于发卡省份，由中央Radius根据用户接入地标识及归属地标识进行漫游判决并控制用户的接入权限。
用户通过预付费名、密码认证后，访问WLAN网络。
暂不支持省预付费用户的漫游功能。
用户标识定义
（1）“随e行”全国用户的登录名称定义规则为：
移动用户的手机。
例如：
13XXXXXXXXX。
（2）映射到公网的奥运专网用户，可以以字符和数字组合作为用户，具体格式由中国移动商奥组委确定。
（3）全国预付费卡用户的登录名称定义规则为：
符合上网卡业务规格式的13位数字。
以特殊命名规则构成卡号，作为用户。
具体格式见《中国移动WLAN上网卡业务规》。
（4）省预付费卡用户的登录名称定义规则为：
符合上网卡业务规格式的13位数字。
具体格式见《中国移动WLAN上网卡业务规》。
1.3.功能定义
认证功能
WLAN用户通过PortalServer完成认证功能。
Portal为“随e行”手机用户提供静态密码认证和动态密码认证两种选择，并为用户提供通过Portal与Radius的直连通道申请动态密码的功能。
下线功能
用户上网结束后，可以使用Portal功能通知AC用户下线；当AC侦测到用户下线或者主动切断用户连接时，也能告知Portal。
自服务功能
登录页面及用户认证成功页面上均需显示“用户自服务”选项，并且PORTAL的认证成功页面在整个用户在线期间都不能关闭。
自服务页面由中央Radius提供，各项功能的操作也由后台的服务器完成，Portal只是负责将“用户自服务”请求重定向到中央Radius即可。
目前要求支持的基本自服务功能包括静态密码修改、套餐信息查询（手机及卡用户）、转帐（预付费卡用户）历史使用记录查询等。
将来可以根据业务开展的需要，开放更多的自服务功能。
1.4.系统结构
为满足WLAN业务分省运营、灵活资费的需求，需要在Radius服务器中同时保存全国用户、省用户的信息。
目前建议采用集中建设中央Radius服务器的方式，在不影响现有随e行用户连接的情况下，提供对“随e行”手机用户及全国/本地预付费卡用户的连接、认证、计费功能的支持。
WLAN集中认证系统结构如图4.1所示。
全国用户及省用户的信息均存储在中央Radius服务器中，通过中央Radius完成漫游判断、认证、计费等功能。
图1.1集中式认证系统结构
AP：
接入点。
AC：
接入控制器。
实现用户强制Portal、业务控制，接收PortalServer发起的认证请求，完成用户认证功能。
PortalServer：
门户。
推送认证页面，接收WLAN用户的认证信息，向AC发起用户认证请求以及用户下线通知。
提供用户自服务选项，到中央Radius服务器提供的自服务页面完成相应功能。
为满足WLAN分省运营、灵活资费的需要，Portal服务器将提供页面定制及个性化Portal推送的功能。
用户输入、密码后，由认证系统判断用户的归属地，为用户提供归属地定制的个性化页面、包含资费在的个性化信息等。
为支持国际漫游业务的需要，要求Portal支持漫游合作伙伴提供的二级Portal页面的推送以及Portal与二级Portal的接口协议及参数传递。
流程
用户认证流程包括认证上线流程、下线流程、动态密码申请流程、管理员配置个性化页面流程；包括静态密码修改、套餐信息查询、转帐、历史使用记录查询在的用户自服务流程。
1.5.用户上线认证流程
上线流程完成用户的认证，并把认证结果通知PortalServer，Portalserver将会通知WLAN用户并且显示相应的认证结果。
用户可使用静态密码或动态密码登录，但Portal不对认证类型进行判断，由中央Radius负责区分。
用户上线认证方式有两种：
CHAP和PAP，其中CHAP方式为必选功能，PAP方式为可选功能。
用户上线Chap认证流程，如图5.1所示：
图1.1用户上线Chap认证流程
（1）用户访问，经过AC重定向到PortalServer；
（2）Portalserver推送统一的认证页面；
（3）用户填入用户名、密码，提交页面，向PortalServer发起连接请求；
（4）Portal向Radius发出用户信息查询请求，由Radius验证用户密码、查询用户信息，并向Portal返回查询结果及系统配置的单次连接最大时长、手机用户及卡用户的套餐剩余时长信息；
（5）如果查询失败，Portal结束认证流程，并直接返回提示信息给用户，指导用户开户及正确使用；
（6）如果查询成功，PortalServer向AC请求Challenge；
（7）AC分配Challenge给PortalServer；
（8）PortalServer向AC发起认证请求；
（9）而后AC进行RADIUS认证，获得RADIUS认证结果；
（10）AC向PortalServer送认证结果；
（11）PortalServer根据编码规则判断的归属地，推送归属地定制的个性化页面，并将认证结果、系统配置的单次连接最大时长、套餐剩余时长、自服务选项填入页面，和门户一起推送给客户,同时启动正计时提醒；
（12）PortalServer回应确认收到认证结果的报文。
用户上线Pap认证流程，如图5.2所示：
图1.2用户上线Pap认证流程
（1）用户访问，经过AC重定向到PortalServer；
（2）Portalserver推送统一的认证页面；
（3）用户填入用户名、密码，提交页面，向PortalServer发起连接请求；
（4）Portal向Radius发出用户信息查询请求，由Radius验证用户密码、查询用户信息，并向Portal返回查询结果及系统配置的单次连接最大时长、手机用户及卡用户的套餐剩余时长信息；
（5）如果查询失败，Portal直接返回提示信息给用户，指导用户开户及正确使用；
（6）如果查询成功，PortalServer向AC发起认证请求；
（7）而后AC进行RADIUS认证，获得RADIUS认证结果；
（8）AC向PortalServer送认证结果；
（9）PortalServer根据编码规则判断的归属地，推送归属地定制的个性化页面，并将认证结果、系统配置的单次连接最大时长、套餐剩余时长、自服务选项填入页面，和门户一起推送给客户,同时启动正计时提醒；
（10）PortalServer回应确认收到认证结果的报文。
1.6.用户下线流程
用户下线流程包括用户主动发起下线流程，用户的强制下线流程和用户异常下线流程，即AC侦测到用户下线，主动通知Portalserver。
用户主动下线流程，如图5.3所示：
图1.1用户主动下线流程
（1）用户发起下线请求到PortalServer；
（2）PortalServer向AC请求下线；
（3）AC回应PortalServer下线请求；
（4）PortalServer推送下线结果页面给用户。
用户强制下线流程，如图5.4所示：
图1.2用户强制下线流程
（1）AC侦测到用户的本次连接最大允许接入时间结束，向PortalServer请求下线；
（2）PortalServer回应下线成功，并向用户推送下线结果页面。
用户异常下线流程:
AC侦测用户下线流程，主动通知Portalserver。
如图5.5所示：
图1.3AC侦测用户下线流程
（1）AC侦测到用户下线，向PortalServer请求下线；
（2）PortalServer回应下线成功。
1.7.动态密码申请流程
“随e行”手机用户可以通过Portal申请动态密码。
如图5.6所示：
图1.1“随e行”手机用户申请动态密码
（1）用户输入用户名并点击“申请动态密码”，Portal通过直连接口向Radius发起动态密码申请请求（包含）；
（2）Radius创建动态密码，向Portal返回申请响应。
同时向短信网关或者BOSS系统转发动态密码下发请求，通过短信向用户下发动态密码。
1.8.管理员配置个性化页面流程
图1.1管理员配置资费、欢迎信息
（1）管理员成功登录后台管理系统；
（2）录入，修改用户资费信息和欢迎信息等；
（3）Portalserver更新用户显示页面；
（4）当省用户下次认证时，推送新的个性化页面。
1.9.用户自服务功能流程
为满足WLAN分省运营、灵活资费的需要，提供更好的业务体验，本协议通过在Portal页面提供的方式为用户提供自服务功能。
目前要求支持的基本自服务功能包括静态密码修改、套餐信息查询、转帐（预付费卡用户）、历史使用记录查询等。
将来可以根据业务开展的需要，开放更多的自服务功能。
由于Portal服务器目前采用集中放置的策略，用户的自服务请求将被到中央Radius服务器提供的自服务页面上。
为保证用户信息的安全性，在使用自服务功能前，需要对用户重新进行认证。
静态密码修改流程
对于“随e行”手机用户，除可以使用短信方式修改、重置WLAN登录静态密码外，还可以通过自服务页面的方式修改静态密码。
对于其他用户，目前只能通过自服务页面修改用户静态密码，修改请求由中央Radius服务器统一处理。
“随e行”手机用户
图1.1“随e行”手机用户静态密码修改流程
“随e行”用户通过自服务页面修改静态密码的流程如下：
（1）用户点击登录页面上的“用户自服务”选项；
（2）Portal服务器将请求到中央Radius服务器提供的自服务URL；
（3）提示用户输入用户名、密码、随机码以验证用户身份；
（4）用户输入信息，中央Radius判断用户是否为“随e行”手机用户；
（5）对用户展示WLAN用户自服务页面，提供静态密码修改等菜单项；
（6）用户输入用户名、旧密码、新密码、随机码；
（7）中央Radius将“随e行”手机用户的静态密码修改请求转给一级BOSS系统处理；
（8）一级BOSS将请求转给省BOSS。
省BOSS验证用户旧密码并执行密码修改操作后，将新静态密码及修改结果同步回中央RADIUS；
（9）返回静态密码修改成功提示。
预付费卡用户
预付费卡用户的密码修改操作主要由中央Radius完成。
如图5.9所示。
图1.2预付费卡用户静态密码修改流程
流程描述如下：
（1）用户点击登录页面上的“用户自服务”选项；
（2）Portal服务器将请求到中央Radius服务器提供的自服务URL；
（3）提示用户输入用户名、密码、随机码以验证用户身份；
（4）用户输入信息，中央Radius判断用户是否为预付费卡用户；
（5）对用户展示用户自服务页面，提供密码修改等菜单项；
（6）用户输入用户名、旧密码、新密码、随机码；
（7）中央Radius处理预付费卡用户的密码修改请求；
（8）返回密码修改成功提示。
预付费卡用户转帐流程
图1.3预付费卡用户转帐
预付费卡用户通过自服务页面给WLAN转帐的流程如下：
（1）用户点击登录页面上的“用户自服务”选项；
（2）Portal服务器将请求到中央Radius服务器提供的自服务URL；
（3）提示用户输入用户名、密码、随机码以验证用户身份；
（4）用户输入信息，中央Radius判断用户是否为预付费卡用户；
（5）向用户展示预付费卡用户自服务页面，提供转帐等菜单项；
（6）用户选择转帐；
（7）中央Radius提示用户输入转出卡的用户名及密码；
（8）用户输入信息；
（9）中央Radius判断转出卡与转入卡（即用户当前登录的预付费卡）的类型，如果两者都为包时卡，并且转出卡没有处于使用中，中央Radius将转出卡的剩余时长叠加到转入卡的剩余时长上，并删除转出卡的信息；
（10）中央Radius向用户返回转帐响应；如转帐成功，Radius返回当前剩余连接时长的信息，并提醒用户重新认证后才能将转入的可用时长信息发送给接入系统；如转帐失败，Radius需返回失败原因。
套餐信息查询流程
图1.4套餐信息查询流程
手机用户通过自服务页面查询套餐信息的流程如下：
（1）用户点击登录页面上的“用户自服务”选项；
（2）Portal服务器将请求到中央Radius服务器提供的自服务URL；
（3）提示用户输入用户名、密码、随机码以验证用户身份；
（4）用户输入信息，中央Radius根据用户类型展示相应的自服务页面；提供“套餐信息查询”等菜单项；
（5）用户点击“套餐信息查询”菜单项；
（6）中央Radius查询套餐信息并显示给用户。
历史使用记录查询流程
除上述功能外，自服务系统还应提供用户历史使用记录查询功能。
流程与上述过程相似，此处不再赘述。
协议
在AC和PortalServer之间通过Portal协议交互。
1.10.协议栈
Portal协议栈如图6.1所示：
图1.1Portal协议栈
1.11.Portal与AC间的协议
报文格式
协议包采用固定长度头加可变长度的属性字段组成，属性字段采用TLV格式，具体如图6.2所示。
图1.1Web认证报文格式
报文字段说明
Ver
Ver字段是协议的版本号，长度为1字节，目前定义的值为0x01。
Type
Type字段定义报文的类型，长度为1字节，目前其值的定义如表6-1。
表1-1报文类型
Type
值
方向
含义
REQ_CHALLENGE
0x01
Client----->Server
PortalServer向AC设备发送的请求Challenge报文
ACK_CHALLENGE
0x02
Client<-----Server
AC设备对PortalServer请求Challenge报文的响应报文
REQ_AUTH
0x03
Client----->Server
PortalServer向AC设备发送的请求认证报文
ACK_AUTH
0x04
Client<-----Server
AC设备对PortalServer请求认证报文的响应报文
REQ_LOGOUT
0x05
Client----->Server
若ErrCode字段值为0x00，表示此报文是PortalServer向AC设备发送的请求用户下线报文；若ErrCode字段值为0x01，表示该报文是PortalServer发送的超时报文，其原因是PortalServer发出的各种请求在规定时间没有收到响应报文。
ACK_LOGOUT
0x06
Client<-----Server
AC设备对PortalServer请求下线报文的响应报文
AFF_ACK_AUTH
0x07
Client----->Server
PortalServer对收到的认证成功响应报文的确认报文；
NTF_LOGOUT
0x08
Server-->Client
用户被强制下线通知报文
REQ_INFO
0x09
Client-->Server
信息询问报文
ACK_INFO
0x0a
Server-->Client
信息询问的应答报文
Pap/Chap
Pap/Chap字段定义此用户的认证方式，长度为1字节，只对Type值为0x03的认证请求报文有意义：
Chap方式认证－－－值为0x00；
Pap方式认证－－－值为0x01；
Rsv
Rsv目前为保留字段，长度为1字节，在所有报文中值为0；
SerialNo
（1）SerialNo字段为报文的序列号，长度为2字节，由PortalServer随机生成，PortalServer必须尽量保证不同认证流程的SerialNo在一定时间不得重复，在同一个认证流程中所有报文的SerialN
升级会员 