文档库

最新最全的文档下载
当前位置:文档库 > 中国移动WLAN业务PORTAL协议规范V2.0.0

中国移动WLAN业务PORTAL协议规范V2.0.0

中国移动WLAN业务PORTAL协议规范V2.0.0

中国移动通信企业标准

QB-D-026-2008

中国移动W L A N 业务P O R T A L 协

议规范

版本号:2.0.0

中国移动通信有限公司 发布

2008-4-2发布 2008-4-2实施

C M C C W L A N S e r v i c e P o r t a l S p e c i f i c a t i o n

目录

1. 范围 (1)

2. 规范性引用文件 (1)

3. 术语、定义和缩略语 (2)

4. Portal协议 (2)

4.1. WLAN用户类型及用户标识定义 (2)

4.1.1. WLAN用户类型 (2)

4.1.2. 用户标识定义 (3)

4.2. 功能定义 (3)

4.2.1. 认证功能 (3)

4.2.2. 下线功能 (4)

4.2.3. 自服务功能 (4)

4.3. 系统结构 (4)

5. 流程 (5)

5.1. 用户上线认证流程 (5)

5.2. 用户下线流程 (8)

5.3. 动态密码申请流程 (9)

5.4. 管理员配置个性化页面流程 (9)

5.5. 用户自服务功能流程 (10)

5.5.1. 静态密码修改流程 (10)

5.5.2. 预付费卡用户帐户转帐流程 (12)

5.5.3. 套餐信息查询流程 (13)

5.5.4. 历史使用记录查询流程 (14)

6. 协议 (14)

6.1. 协议栈 (14)

6.2. Portal与AC间的协议 (15)

6.2.1. 报文格式 (15)

6.2.2. 报文字段说明 (15)

6.2.3. 参数 (19)

6.3. Portal与Radius间的协议 (21)

6.3.1. 报文格式 (21)

6.3.2. 报文字段说明及参数 (21)

7. 编制历史 (22)

附录A详细修订历史 (22)

前言

本标准的目的是为了制定中国移动WLAN业务Portal规范和协议。

本标准主要包括以下几方面内容:Portal协议,系统结构,上线/下线/页面配置/自服务功能流程,协议报文字段,参数及自服务功能描述。

本标准的附录A为资料性附录。

本标准由中移有限技〔2008〕49号印发。

本标准由中国移动通信有限公司技术部提出并归口。

本标准由标准归口部门负责解释。

本标准起草单位:中国移动通信有限公司研究院

本标准主要起草人:邵春菊,吕志虎,黄宇红,周文辉

1.范围

本标准规定了中国移动WLAN业务Portal规范和协议。主要包括Portal协议,系统结构,上线/下线/页面配置/自服务功能流程,协议报文字段,参数及自服务功能描述等内容。供中国移动内部和厂家共同使用;适用于中国移动开展WLAN业务采用强制门户网站时需遵循的标准。

2.规范性引用文件

下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件,其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本标准,然而,鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件,其最新版本适用于本标准。

表2-1 规范性引用文件

[1] 《中国移动WLAN业务总体技术要求》中国移动通信

有限公司

[2] 1999

Edition[ISO/

IEC 8802-11:

1999] Standards for Local and Metropolitan Area

Networks-Wireless LAN Medium Access

Control(MAC) and Physical Layer(PHY) Specifications

IEEE

Std.802.11

[3] 1999

Edition[ISO/

IEC 8802-11:

1999] Standards for Local and Metropolitan Area

Networks-Part11:Wireless LAN Medium Access

Control(MAC) and Physical Layer(PHY) Specifications: High-Speed Physical layer

Extension in the 2.4GHz Band

IEEE

Std.802.11b

[4] 2001 Recommended Practices for Multi-Vendor

Access Point Interoperability via

Inter-Access Point Protocol across

Distribution Systems supporting IEEE

P802.11 operation

IEEE 802.11f

[5] 2001 Standards for Local and Metropolitan Area

Networks-Specific requirements-Part 11:

Wireless LAN Medium Access Control (MAC)

and Physical Layer (PHY) specifications:

Medium Access Method (MAC) Security

Enhancements

IEEE 802.11i

[6] RFC 2865 Remote Authentication Dial In User Service

(RADIUS)

IETF

[7] RFC 2866 RADIUS Accounting IETF

[8] RFC 2869 RADIUS Extension IETF

[9] RFC 2131 Dynamic Host Configuration Protocol IETF

[10] RFC 2132 DHCP Options and BOOTP Vendor Extensions IETF

[11] RFC 1945 Hypertext Transfer Protocol -- HTTP/1.0 IETF

[12] RFC 2616 Hypertext Transfer Protocol -- HTTP/1.1 IETF

[13] RFC 2246 The TLS Protocol Version 1.0 IETF

[14] 中国移动WLAN上网卡业务规范中国移动通信

集团公司

3.术语、定义和缩略语

下列术语、定义和缩略语适用于本标准:

表3-1 缩略语定义

词语解释

AP Access Point

AC Access Controller

DHCP Dynamic Host Configuration Protocol

DNS Domain Name Service

HTTP Hyper Text Transport Protocol

NAI Network Access Identifier

RADIUS Remote Authentication Dial In User Service

WLAN Wireless Local Area Network

AAA Authentication,Authorization,Accounting

SSL Secure Sockets Layer

CHAP Challenge Handshake Authentication Protocol

4.Portal协议

4.1. WLAN用户类型及用户标识定义

4.1.1. 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网络。暂不支持省内预付费用户的漫游功能。

4.1.2. 用户标识定义

(1)“随e行”全国用户的登录名称定义规则为:移动用户的手机号码。例如:13XXXXXXXXX。

(2)映射到公网的奥运专网用户,可以以字符和数字组合作为用户帐号,具体格式由中国移动商奥组委确定。

(3)全国预付费卡用户的登录名称定义规则为:符合上网卡业务规范格式的13位数字。以特殊命名规则构成卡号,作为用户帐号。具体格式见《中国移动WLAN上网卡业务规范》。

(4)省内预付费卡用户的登录名称定义规则为:符合上网卡业务规范格式的13位数字。具体格式见《中国移动WLAN上网卡业务规范》。

4.2. 功能定义

4.2.1. 认证功能

WLAN用户通过Portal Server完成认证功能。Portal为“随e行”手机用户提供静态密码认证和动态密码认证两种选择,并为用户提供通过Portal与Radius的直连通道申请动态密码的功能。

4.2.2. 下线功能

用户上网结束后,可以使用Portal功能通知AC用户下线;当AC侦测到用户下线或者主动切断用户连接时,也能告知Portal。

4.2.3. 自服务功能

登录页面及用户认证成功页面上均需显示“用户自服务”选项,并且PORTAL的认证成功页面在整个用户在线期间都不能关闭。自服务页面由中央Radius提供,各项功能的操作也由后台的服务器完成,Portal只是负责将“用户自服务”请求重定向到中央Radius即可。

目前要求支持的基本自服务功能包括静态密码修改、套餐信息查询(手机及卡用户)、帐户转帐(预付费卡用户)历史使用记录查询等。将来可以根据业务开展的需要,开放更多的自服务功能。

4.3. 系统结构

为满足WLAN业务分省运营、灵活资费的需求,需要在Radius服务器中同时保存全国用户、省内用户的信息。目前建议采用集中建设中央Radius服务器的方式,在不影响现有随e行用户连接的情况下,提供对“随e行”手机用户及全国/本地预付费卡用户的连接、认证、计费功能的支持。

WLAN集中认证系统结构如图4.1所示。全国用户及省内用户的信息均存储在中央Radius服务器中,通过中央Radius完成漫游判断、认证、计费等功能。

图4.1 集中式认证系统结构

全国用户

接入控制器(AC)

接入点(AP)

省内用户

门户网站(Portal)中央认证服务器

(RADIUS)

全国用户/省内用户认证请求

物理连接

逻辑连接

通过Portal协议规定AC与Portal server

之间对用户的上线、下线等请求的

处理

AP:接入点。

AC:接入控制器。实现用户强制Portal、业务控制,接收Portal Server发起的认证请求,完成用户认证功能。

Portal Server:门户网站。推送认证页面,接收WLAN用户的认证信息,向AC发起用户认证请求以及用户下线通知。提供用户自服务选项,链接到中央Radius服务器提供的自服务页面完成相应功能。

为满足WLAN分省运营、灵活资费的需要,Portal服务器将提供页面定制及个性化Portal推送的功能。用户输入帐号、密码后,由认证系统判断用户帐号的归属地,为用户提供归属地定制的个性化页面、包含资费在内的个性化信息链接等。

为支持国际漫游业务的需要,要求Portal支持漫游合作伙伴提供的二级Portal页面的推送以及Portal与二级Portal的接口协议及参数传递。

5.流程

用户认证流程包括认证上线流程、下线流程、动态密码申请流程、管理员配置个性化页面流程;包括静态密码修改、套餐信息查询、帐户转帐、历史使用记录查询在内的用户自服务流程。

5.1. 用户上线认证流程

上线流程完成用户帐户的认证,并把认证结果通知Portal Server,Portal server 将会通知WLAN用户并且显示相应的认证结果。用户可使用静态密码或动态密码登录,但Portal不对认证类型进行判断,由中央Radius负责区分。

用户上线认证方式有两种:CHAP 和PAP ,其中CHAP 方式为必选功能,PAP 方式为可选功能。

用户上线Chap 认证流程,如图5.1所示:

图5.1 用户上线Chap 认证流程 WLAN 用户

门户网站

(Portal )

接入控制器(AC )连接请求

请求认证

认证结果

推送归属地定制的页面,通知用户认证结果,并

启动正计时提醒

用户请求,通过AC 强制到Portal server

统一认证页面推送

请求Challenge 分配Challenge 查询用户信息

返回查询结果

及用户连接时长相

关信息

Radius RADIUS 认证流程

如果查询失败,直接给出提示信息,结束认证

判断归属地

(1) 用户访问网站,经过AC 重定向到Portal Server ; (2) Portal server 推送统一的认证页面;

(3) 用户填入用户名、密码,提交页面,向Portal Server 发起连接请求; (4) Portal 向Radius 发出用户信息查询请求,由Radius 验证用户密码、查询用户

信息,并向Portal 返回查询结果及系统配置的单次连接最大时长、手机用户及卡用户的套餐剩余时长信息; (5) 如果查询失败,Portal 结束认证流程,并直接返回提示信息给用户,指导用户

开户及正确使用; (6) 如果查询成功,Portal Server 向AC 请求Challenge ; (7) AC 分配Challenge 给Portal Server ; (8) Portal Server 向AC 发起认证请求;

(9) 而后AC 进行RADIUS 认证,获得RADIUS 认证结果; (10) AC 向Portal Server 送认证结果;

(11) Portal Server 根据编码规则判断帐户的归属地,推送归属地定制的个性化页面,

并将认证结果、系统配置的单次连接最大时长、套餐剩余时长、自服务选项填入页面,和门户网站一起推送给客户,同时启动正计时提醒; (12) Portal Server 回应确认收到认证结果的报文。

用户上线Pap 认证流程,如图5.2所示:

图5.2 用户上线Pap 认证流程

WLAN 用户

门户网站(Portal )

接入控制器(AC )

连接请求

请求认证

认证结果

推送归属地定制的页面,通知用户认证结果;并启动正

计时提醒

用户请求,通过AC 强制到Portal server

统一认证页面推送

判断归属地

Radius

RADIUS 认证流程

如果查询失败,直接给出提示信息,结束认证

查询用户信息

返回查询结果及用户连接时长相

关信息

(1) 用户访问网站,经过AC 重定向到Portal Server ; (2) Portal server 推送统一的认证页面;

(3) 用户填入用户名、密码,提交页面,向Portal Server 发起连接请求; (4) Portal 向Radius 发出用户信息查询请求,由Radius 验证用户密码、查询用户

信息,并向Portal 返回查询结果及系统配置的单次连接最大时长、手机用户及卡用户的套餐剩余时长信息; (5) 如果查询失败,Portal 直接返回提示信息给用户,指导用户开户及正确使用; (6) 如果查询成功,Portal Server 向AC 发起认证请求; (7) 而后AC 进行RADIUS 认证,获得RADIUS 认证结果; (8) AC 向Portal Server 送认证结果;

(9) Portal Server 根据编码规则判断帐户的归属地,推送归属地定制的个性化页面,

并将认证结果、系统配置的单次连接最大时长、套餐剩余时长、自服务选项填入页面,和门户网站一起推送给客户,同时启动正计时提醒; (10) Portal Server 回应确认收到认证结果的报文。

5.2. 用户下线流程

用户下线流程包括用户主动发起下线流程,用户的强制下线流程和用户异常下线流程,即AC侦测到用户下线,主动通知Portal server。

用户主动下线流程,如图5.3所示:

图5.3 用户主动下线流程

WLAN用户

门户网站

(Portal)接入控制器

(AC)

下线请求

请求下线

下线回应

告诉用户下线结果

(1)用户发起下线请求到Portal Server;

(2)Portal Server向AC请求下线;

(3)AC回应Portal Server下线请求;

(4)Portal Server推送下线结果页面给用户。

用户强制下线流程,如图5.4所示:

图5.4 用户强制下线流程

WLAN用户

门户网站

(Portal)接入控制器

(AC)

请求下线

下线成功

告诉用户下线结果

AC侦测到用户允

许接入时间结束

(1)AC侦测到用户的本次连接最大允许接入时间结束,向Portal Server请求下线;

(2)Portal Server回应下线成功,并向用户推送下线结果页面。

用户异常下线流程:AC 侦测用户下线流程,主动通知Portal server 。如图5.5所示:

图5.5 AC 侦测用户下线流程

WLAN用户

门户网站(Portal)

接入控制器(AC)请求下线

下线成功

AC侦测到用户

下线

(1)AC 侦测到用户下线,向Portal Server 请求下线; (2)Portal Server 回应下线成功。 5.3. 动态密码申请流程

“随e 行”手机用户可以通过Portal 申请动态密码。如图5.6所示:

图5.6 “随e 行”手机用户申请动态密码

WLAN 用户

门户网站(Portal )

输入用户名,发起动态密码认证请求

创建动态密码并通过短信下发给用户

中央认证服务器(Radius )

动态密码申请请求

(账号)动态密码申请响应

返回结果

(1) 用户输入用户名并点击“申请动态密码”,Portal 通过直连接口向Radius 发

起动态密码申请请求(包含帐户);

(2) Radius 创建动态密码,向Portal 返回申请响应。同时向短信网关或者BOSS 系

统转发动态密码下发请求,通过短信向用户下发动态密码。 5.4. 管理员配置个性化页面流程

图5.7 管理员配置资费、欢迎信息

管理员后台管理系统省内用户

管理员成功登陆后台管理系统

修改资费和欢迎信息

更新用户访问网页

当省内用户认证时,

推送个性化页面

(1)管理员成功登录后台管理系统;

(2)录入,修改用户资费信息和欢迎信息等;

(3)Portal server 更新用户显示页面;

(4)当省内用户下次认证时,推送新的个性化页面。

5.5. 用户自服务功能流程

为满足WLAN分省运营、灵活资费的需要,提供更好的业务体验,本协议通过在Portal 页面提供链接的方式为用户提供自服务功能。目前要求支持的基本自服务功能包括静态密码修改、套餐信息查询、帐户转帐(预付费卡用户)、历史使用记录查询等。将来可以根据业务开展的需要,开放更多的自服务功能。

由于Portal服务器目前采用集中放置的策略,用户的自服务请求将被链接到中央Radius服务器提供的自服务页面上。为保证用户信息的安全性,在使用自服务功能前,需要对用户重新进行认证。

5.5.1. 静态密码修改流程

对于“随e行”手机用户,除可以使用短信方式修改、重置WLAN登录静态密码外,还可以通过自服务页面的方式修改静态密码。

对于其他用户,目前只能通过自服务页面修改用户静态密码,修改请求由中央Radius 服务器统一处理。

5.5.1.1. “随e行”手机用户

图5.8 “随e行”手机用户静态密码修改流程

省BOSS 修改静态密码并同步给中央Radius

WLAN 用户

门户网站(Portal )

认证成功后,点击“用户自服务”

中央认证服务器(Radius )

提示用户输入用户名/密码/随机码

输入用户名/密码/随机码

提示用户静态密码

修改成功

链接到WLAN 自服务页面

展示用户自服务页面,提供静态密码修改选项

输入用户名/旧密码/新密码/随机码

一级BOSS

省BOSS

是否为随e 行

“随e 行”用户通过自服务页面修改静态密码的流程如下:

(1) 用户点击登录页面上的“用户自服务”选项;

(2) Portal 服务器将请求链接到中央Radius 服务器提供的自服务URL ; (3) 提示用户输入用户名、密码、随机码以验证用户身份;

(4) 用户输入信息,中央Radius 判断用户是否为“随e 行”手机用户; (5) 对用户展示WLAN 用户自服务页面,提供静态密码修改等菜单项; (6) 用户输入用户名、旧密码、新密码、随机码;

(7) 中央Radius 将“随e 行”手机用户的静态密码修改请求转给一级BOSS

系统处理; (8) 一级BOSS 将请求转给省BOSS 。省BOSS 验证用户旧密码并执行密码修改

操作后,将新静态密码及修改结果同步回中央RADIUS ; (9) 返回静态密码修改成功提示。

5.5.1.2. 预付费卡用户

预付费卡用户的密码修改操作主要由中央Radius 完成。如图5.9所示。

图5.9 预付费卡用户静态密码修改流程

密码修改

WLAN 用户

门户网站(Portal )

点击“用户自服务”

是否为预付费卡用户

中央认证服务器(Radius )

提示用户输入用户名/密码/随机码

输入用户名/密码/随机码

提示用户密码修改成功

链接到WLAN 自服务页面

展示用户自服务页面,提供密码修改选项

输入用户名/旧密码/新密码/随机码

流程描述如下:

(1) 用户点击登录页面上的“用户自服务”选项;

(2) Portal 服务器将请求链接到中央Radius 服务器提供的自服务URL ; (3) 提示用户输入用户名、密码、随机码以验证用户身份; (4) 用户输入信息,中央Radius 判断用户是否为预付费卡用户; (5) 对用户展示用户自服务页面,提供密码修改等菜单项; (6) 用户输入用户名、旧密码、新密码、随机码; (7) 中央Radius 处理预付费卡用户的密码修改请求; (8) 返回密码修改成功提示。

5.5.2. 预付费卡用户帐户转帐流程

图5.10 预付费卡用户帐户转帐

完成转帐

WLAN 用户

门户网站(Portal )

点击“用户自服务”

是否为预付费卡用户

中央认证服务器(Radius )

提示用户输入用户名/密码/随机码

输入用户名/密码/随机码转帐响应

(帐号、时长、结果)

链接到WLAN 自服务页面

展示预付费卡用户自服务页面,

提供帐号转帐菜单项点击“帐户转帐”提示用户输入转出卡的用户名及密码

输入转出卡的用户名及密码

转入卡与转出卡是否都为包时用户,转出卡是

否正在使用

预付费卡用户通过自服务页面给WLAN 帐户转帐的流程如下:

(1) 用户点击登录页面上的“用户自服务”选项;

(2) Portal 服务器将请求链接到中央Radius 服务器提供的自服务URL ; (3) 提示用户输入用户名、密码、随机码以验证用户身份; (4) 用户输入信息,中央Radius 判断用户是否为预付费卡用户; (5) 向用户展示预付费卡用户自服务页面,提供帐户转帐等菜单项; (6) 用户选择帐户转帐;

(7) 中央Radius 提示用户输入转出卡的用户名及密码; (8) 用户输入信息;

(9) 中央Radius 判断转出卡与转入卡(即用户当前登录的预付费卡)的类型,

如果两者都为包时卡,并且转出卡没有处于使用中,中央Radius 将转出卡的剩余时长叠加到转入卡的剩余时长上,并删除转出卡的帐户信息; (10) 中央Radius 向用户返回转帐响应;如转帐成功,Radius 返回当前剩余连

接时长的信息,并提醒用户重新认证后才能将转入的可用时长信息发送给接入系统;如转帐失败,Radius 需返回失败原因。

5.5.3. 套餐信息查询流程

图5.11 套餐信息查询流程

查询套餐信息

WLAN 用户

门户网站(Portal )

点击“用户自服务”

中央认证服务器(Radius )

提示用户输入用户名/密码/随机码

输入用户名/密码/随机码显示用户套餐信息

链接到WLAN 自服务页面

展示用户自服务页面

点击套餐信息查询菜单项

手机用户通过自服务页面查询套餐信息的流程如下:

(1) 用户点击登录页面上的“用户自服务”选项;

(2) Portal 服务器将请求链接到中央Radius 服务器提供的自服务URL ; (3) 提示用户输入用户名、密码、随机码以验证用户身份;

(4) 用户输入信息,中央Radius 根据用户类型展示相应的自服务页面;提供

“套餐信息查询”等菜单项; (5) 用户点击“套餐信息查询”菜单项; (6) 中央Radius 查询套餐信息并显示给用户。

5.5.4. 历史使用记录查询流程

除上述功能外,自服务系统还应提供用户历史使用记录查询功能。流程与上述过程相似,此处不再赘述。

6. 协议

在AC 和Portal Server 之间通过Portal 协议交互。 6.1. 协议栈

Portal 协议栈如图6.1所示:

图6.1 Portal 协议栈

接入控制器(AC )

门户网站(Portal )IP

UDP Portal 协议IP

UDP Portal 协议Radius

IP

TCP 私有协议

6.2. Portal 与AC 间的协议

6.2.1. 报文格式

协议包采用固定长度头加可变长度的属性字段组成,属性字段采用TLV 格式,具体如图6.2所示。

图6.2 Web 认证报文格式

Ver Type

Pap/Chap

Rsv SerialNo ReqID

1

2

3

4

6

8

UserIP UserPort

ErrCode

AttrNum

5

7

Attr ......

6.2.2. 报文字段说明

Ver

Ver 字段是协议的版本号,长度为 1 字节,目前定义的值为 0x01。 Type

Type 字段定义报文的类型,长度为 1 字节,目前其值的定义如表6-1。

表6-1 报文类型

Type

值 方向

含义

REQ_CHALLENGE 0x01 Client----->Server Portal Server 向AC 设备发送的请求

Challenge 报文 ACK_CHALLENGE

0x02

Client<-----Server AC 设备对Portal Server 请求

Challenge 报文的响应报文

REQ_AUTH 0x03 Client----->Server Portal Server向AC设备发送的请求

认证报文

ACK_AUTH 0x04 Client<-----Server AC设备对Portal Server请求认证报

文的响应报文

REQ_LOGOUT 0x05 Client----->Server 若ErrCode字段值为0x00,表示此报文

是Portal Server向AC设备发送的请

求用户下线报文;若ErrCode字段值为

0x01,表示该报文是Portal Server

发送的超时报文,其原因是Portal

Server发出的各种请求在规定时间内

没有收到响应报文。

ACK_LOGOUT 0x06 Client<-----Server AC设备对Portal Server请求下线报

文的响应报文

AFF_ACK_AUTH 0x07 Client----->Server Portal Server对收到的认证成功响

应报文的确认报文;

NTF_LOGOUT 0x08 Client <-- Server 用户被强制下线通知报文

REQ_INFO 0x09 Client --> Server 信息询问报文

ACK_INFO 0x0a Client <-- Server 信息询问的应答报文Pap/Chap

Pap/Chap字段定义此用户的认证方式,长度为 1 字节,只对Type值为 0x03 的认证

请求报文有意义:

Chap方式认证---值为0x00;

Pap 方式认证---值为0x01;

Rsv

Rsv目前为保留字段,长度为 1 字节,在所有报文中值为 0;

SerialNo

(1)SerialNo字段为报文的序列号,长度为 2 字节,由Portal Server随机生成,

Portal Server必须尽量保证不同认证流程的SerialNo在一定时间内不得重复,

在同一个认证流程中所有报文的SerialNo相同;

(2)Portal Server发给AC设备的报文

a、由Portal Server发出的Type值为1、3的请求报文其SerialNo都是随机生

成数;

b、由Portal Server向AC设备发出的Type值为5的(REQ_LOGOUT)报文其

SerialNo值分两种情况:当ErrCode为0 时(请求用户下线报文),SerialNo

值为一个随机生成数;当ErrCode为1时,SerialNo值可能和Type值为1

或3的报文 (请求Challenge超时, 或请求认证超时) 相同,具体要看是请

求Challenge超时还是请求认证超时;

c、由Portal Server向AC设备发出的认证成功确认报文(Type值为7的报文)

SerialNo和其发出的相应请求报文的SerialNo相同;比如对于Type值为7

的报文其SerialNo值和Type值为3的请求认证报文相同;

(3)每一个由AC设备发给Portal Server的响应报文的SerialNo必须和Portal