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

2008-4-2实施2008-4-2发布中国移动通信有限公司 发布QB-D-026-2008中国移动通信企业标准中国移动WLAN业务PORTAL协议规范CMCC WLAN Service Portal Specification版本号：2.0.0QB-D-026-2008目 录1.范围12.规范性引用文件13.术语、定义和缩略语24.Portal协议24.1.WLAN用户类型及用户标识定义24.1.1.WLAN用户类型24.1.2.用户标识定义34.2.功能定义34.2.1.认证功能34.2.2.下线功能44.2.3.自服务功能44.3.系统结构45.流程55.1.用户上线认证流程55.2.用户下线流程85.3.动态密码申请流程95.4.管理员配置个性化页面流程95.5.用户自服务功能流程105.5.1.静态密码修改流程105.5.2.预付费卡用户帐户转帐流程125.5.3.套餐信息查询流程135.5.4.历史使用记录查询流程146.协议146.1.协议栈146.2.Portal与AC间的协议156.2.1.报文格式156.2.2.报文字段说明156.2.3.参数196.3.Portal与Radius间的协议216.3.1.报文格式216.3.2.报文字段说明及参数217.编制历史22附录A详细修订历史22前言本标准的目的是为了制定中国移动WLAN业务Portal规范和协议。本标准主要包括以下几方面内容：Portal协议，系统结构，上线/下线/页面配置/自服务功能流程，协议报文字段，参数及自服务功能描述。本标准的附录A为资料性附录。本标准由中移有限技200849号印发。本标准由中国移动通信有限公司技术部提出并归口。本标准由标准归口部门负责解释。本标准起草单位：中国移动通信有限公司研究院本标准主要起草人：邵春菊，吕志虎，黄宇红，周文辉I1. 范围本标准规定了中国移动WLAN业务Portal规范和协议。主要包括Portal协议，系统结构，上线/下线/页面配置/自服务功能流程，协议报文字段，参数及自服务功能描述等内容。供中国移动内部和厂家共同使用；适用于中国移动开展WLAN业务采用强制门户网站时需遵循的标准。2. 规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。表2-1 规范性引用文件1中国移动WLAN业务总体技术要求中国移动通信有限公司21999 EditionISO/IEC 8802-11: 1999Standards for Local and Metropolitan Area Networks-Wireless LAN Medium Access Control(MAC) and Physical Layer(PHY) SpecificationsIEEE Std.802.1131999 EditionISO/IEC 8802-11: 1999Standards 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 BandIEEE Std.802.11b42001Recommended Practices for Multi-Vendor Access Point Interoperability via Inter-Access Point Protocol across Distribution Systems supporting IEEE P802.11 operationIEEE 802.11f52001Standards 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 EnhancementsIEEE 802.11i6RFC 2865Remote Authentication Dial In User Service (RADIUS)IETF7RFC 2866RADIUS AccountingIETF8RFC 2869RADIUS ExtensionIETF9RFC 2131Dynamic Host Configuration ProtocolIETF10RFC 2132DHCP Options and BOOTP Vendor ExtensionsIETF11RFC 1945Hypertext Transfer Protocol - HTTP/1.0IETF12RFC 2616Hypertext Transfer Protocol - HTTP/1.1IETF13RFC 2246The TLS Protocol Version 1.0IETF14中国移动WLAN上网卡业务规范中国移动通信集团公司3. 术语、定义和缩略语下列术语、定义和缩略语适用于本标准：表3-1 缩略语定义词语解释APAccess PointACAccess ControllerDHCPDynamic Host Configuration ProtocolDNSDomain Name ServiceHTTPHyper Text Transport ProtocolNAINetwork Access IdentifierRADIUSRemote Authentication Dial In User ServiceWLANWireless Local Area NetworkAAAAuthentication，Authorization，AccountingSSLSecure Sockets LayerCHAPChallenge Handshake Authentication Protocol4. 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 集中式认证系统结构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认证流程(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认证流程(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 用户主动下线流程(1) 用户发起下线请求到Portal Server；(2) Portal Server向AC请求下线；(3) AC回应Portal Server下线请求；(4) Portal Server推送下线结果页面给用户。用户强制下线流程，如图5.4所示：图5.4 用户强制下线流程(1) AC侦测到用户的本次连接最大允许接入时间结束，向Portal Server请求下线；(2) Portal Server回应下线成功，并向用户推送下线结果页面。用户异常下线流程:AC侦测用户下线流程，主动通知Portal server。如图5.5所示：图5.5 AC侦测用户下线流程 （1）AC侦测到用户下线，向Portal Server请求下线；（2）Portal Server回应下线成功。5.3. 动态密码申请流程“随e行”手机用户可以通过Portal申请动态密码。如图5.6所示：图5.6 “随e行”手机用户申请动态密码（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行”手机用户静态密码修改流程“随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 预付费卡用户静态密码修改流程流程描述如下：（1） 用户点击登录页面上的“用户自服务”选项；（2） Portal服务器将请求链接到中央Radius服务器提供的自服务URL；（3） 提示用户输入用户名、密码、随机码以验证用户身份；（4） 用户输入信息，中央Radius判断用户是否为预付费卡用户；（5） 对用户展示用户自服务页面，提供密码修改等菜单项；（6） 用户输入用户名、旧密码、新密码、随机码；（7） 中央Radius处理预付费卡用户的密码修改请求；（8） 返回密码修改成功提示。5.5.2. 预付费卡用户帐户转帐流程图5.10 预付费卡用户帐户转帐预付费卡用户通过自服务页面给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 套餐信息查询流程手机用户通过自服务页面查询套餐信息的流程如下：（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协议栈6.2. Portal与AC间的协议6.2.1. 报文格式协议包采用固定长度头加可变长度的属性字段组成，属性字段采用TLV格式，具体如图6.2所示。图6.2 Web认证报文格式6.2.2. 报文字段说明VerVer字段是协议的版本号，长度为 1 字节，目前定义的值为 0x01。TypeType字段定义报文的类型，长度为 1 字节，目前其值的定义如表6-1。表6-1 报文类型Type值方向含义REQ_CHALLENGE0x01Client-ServerPortal Server 向AC设备发送的请求Challenge报文ACK_CHALLENGE0x02ClientServerPortal Server向AC设备发送的请求认证报文ACK_AUTH0x04ClientServer若ErrCode字段值为0x00，表示此报文是Portal Server向AC设备发送的请求用户下线报文；若ErrCode字段值为0x01，表示该报文是Portal Server发送的超时报文，其原因是Portal Server发出的各种请求在规定时间内没有收到响应报文。ACK_LOGOUT0x06ClientServerPortal Server对收到的认证成功响应报文的确认报文；NTF_LOGOUT0x08Client Server信息询问报文ACK_INFO0x0aClient - Server信息询问的应答报文Pap/ChapPap/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 Server发送的相应请求报文的SerialNo一样，否则Portal Server会丢掉从AC设备发来的响应报文； 比如Type值为2的报文其SerialNo值必须和Type值为1的报文相同，Type值为4的报文其SerialNo值必须和Type值为3的报文相同，Type值为6的报文其SerialNo值必须和Type值为5的报文相同。ReqID(1) ReqID字段长度为 2 个字节，由AC设备随机生成，尽量使得在一定时间内ReqID不重复。(2) 在Chap认证方式中：a、 AC设备在Type为2 (ACK-CHALLENGE) 的请求Challenge响应报文中把该ReqID的值告诉Portal Server；b、 在Type值为3、4、7 ( REQ-AUTH, ACK-AUTH, AFF-ACK-AUTH ) 的报文中ReqID字段的值都和Type值为2的报文中此字段的值相同；c、 在Type值为 5 (REQ-LOGOUT) 的报文中，若报文表示请求Challenge 超时则此字段值为0 ；若报文表示请求认证超时则此字段值和Type值为2 (ACK-CHALLENGE)的报文中此字段的值相同；(3) 在Pap认证方式中，此字段无意义，其值为0；(4) 在Type值为 5 (REQ-LOGOUT) 的报文中，若报文表示请求下线时则此字段值为0 ；(5) 在Type值为1、6 (REQ-CHALLENGE , ACK-LOGOUT) 的报文中，该字段均无意义，值都为 0；UserIPUserIP字段为Portal用户的IP地址，长度为 4 字节，其值由Portal Server根据其获得的IP地址填写，在所有的报文中此字段都要有具体的值；UserPortUserPort字段目前没有用到，长度为 2 字节，在所有报文中其值为0；ErrCodeErrCode字段和Type字段一起表示一定的意义，长度为 1字节，具体如下：(1) 对于Type值为1、3、7的报文，ErrCode字段无意义，其值为0；(2) 当Type值为 2 时：ErrCode0，表示AC设备告诉Portal Server请求Challenge成功；ErrCode1，表示AC设备告诉Portal Server请求Challenge被拒绝； ErrCode2，表示AC设备告诉Portal Server此链接已建立；ErrCode3，表示AC设备告诉Portal Server有一个用户正在认证过程中，请稍后再试；ErrCode4，则表示AC设备告诉Portal Server此用户请求Challenge失败（发生错误）；(3) 当Type值为 4 时：ErrCode0，表示AC设备告诉Portal Server此用户认证成功；ErrCode1，表示AC设备告诉Portal Server此用户认证请求被拒绝；ErrCode2，表示AC设备告诉Portal Server此链接已建立； ErrCode3，表示AC设备告诉Portal Server有一个用户正在认证过程中，请稍后再试；ErrCode4 ，表示AC设备告诉Portal Server此用户认证失败（发生错误）；(4) 当Type值为 5 时：ErrCode0，表示此报文是Portal Server发给AC设备的请求下线报文；ErrCode1，表示此报文是在Portal Server没有收到AC设备发来的对各种请求的响应报文，而定时器时间到（即超时）时由Portal Server发给AC设备的报文；(5) 当Type值为 6 时：ErrCode0，表示AC设备告诉Portal Server此用户下线成功；ErrCode1，表示AC设备告诉Portal Server此用户下线被拒绝；ErrCode2, 表示AC设备告诉Portal Server此用户下线失败（发生错误）；(6) 对Type为REQ_INFO时，ErrCode无意义，其值为0；(7) 对Type为NTF_LOGOUT时，ErrCode含义如下：ErrCode含义0下线(8) 对Type为ACK_INFO时，ErrCode含义如下：ErrCode含义0处理成功，但不表示全部消息都被获取了，有多少信息被获得应通过属性来判断，详见下文1功能不支持，表示设备不支持这一功能2消息处理失败，由于某种不可知原因，使处理失败，例如询问消息格式错误等。AttrNumAttrNum字段表示其后边可变长度的属性字段属性的个数，长度为 1 字节（表示属性字段最多可有255个属性），其值在所有的报文中都要根据具体情况赋值；报文属性字段（Attr）的格式Attr字段（属性字段）是一个可变长字段，由多个属性依次链接而成，每个属性的格式为TLV格式，具体如图6.4。图6.4 属性字段的格式报文属性字段说明如下：(1) 属性类型(AttrType)表6-2 属性字段的定义Attr(属性字段)AttrType属性值长度属性含义UserName0x01=253 （可变）随e行用户名，具体为：“用户手机号码”；全国/省内预付费卡用户名称：13位数字；为满足国际漫游的需要，支持253字节的长用户名。PassWord0x02=16（可变）用户提交的明文密码Challenge0x0316（固定） Chap方式加密的魔术字ChapPassWord0x0416（固定）经过Chap方式加密后的密码(2) 属性长度(AttrLen)AttrLen字段表示属性的长度，长度为1字节，其值是整个属性三个字段AttrType、AttrLen、AttrValue的长度之和。(3) 属性值(AttrValue)AttrValue的值为具体的属性值，比如用户名、口令等，长度有些可变，有些固定（具体见表6-2），但最长不能超过253(255-2)字节。6.2.3. 参数1、 此协议规定承载报文的是UDP协议，也即报文为UDP报文，AC设备在固定端口2000（参照BNAS宽带接入服务器技术规范YD1148修订）上等待接收Portal Server发来的各种请求报文和确认报文；2、 PORTAL强制相关参数当AC实现强制PORTAL功能时，要求在强制PORTAL URL中包含以下参数：参数名称参数取值参数说明认证模式作用阶段举例Wlanuserip十进制的字符串格式网段在前，主机在后WLAN用户的私网地址，是认证Portal与AC之间判别WLAN用户的身份识别码WEB重定向认证页面请求时wlanuserip=10.1.2.34wlanusernameIMSISIM格式的字符串格式WLAN用户的用户名SIM重定向门户网站页面请求时wlanusername=IMSISIMWlanacname十进制的字符串格式wlanacname=ACN.CTY.PRO.OPE，属性名为严格小写，属性值为按照下列规定的AC名称。统一规定全国AC的编码，其编码规则为ACN.CTY.PRO.OPE，其中：ACN表示AC的名字，由4位数字组成，各省自己规划和分配。CTY表示WLAN位于的城市，由4位数字组成，由各个地市的长途区号表示, 右对齐左填零。PRO表示WLAN位于的省份，由3位数字组成，PRO的代码分配参见附表。OPE表示WLAN所属的运营商，由2位数字组成，中国移动为00。WEB重定向认证页面请求时wlanacip= ACN.CTY.PRO.OPE具体参数格式示例如下：http:/www.portal.com?wlanuserip=10.1.2.34&wlanacname= ACN.CTY.PRO.OPEhttp:/www.portal.com?wlanusername=IMSISIM允许在”?”后面有其他的参数，但是名称不能以wlan作为起始。3、 Chap认证的相关说明：(1) challenge的生成(AC生成) ：challenge由AC设备在收到请求Challenge报文的时候随机生成，长度为16个字节，跟随Challenge应答报文下发到Portal Server。(2) Chap_Password(Chap密码)的生成：Chap_Password的生成遵循标准的Radius协议中的Chap_Password 生成方法（参见RFC2865）。密码加密使用MD5算法，MD5函数的输入为ChapID Password Challenge (ReqID有AC生成, ChapID是ReqID的低8位)其中，ChapID取ReqID的低 8 位，Password的长度不够协议规定的最大长度，其后不需要补零。Chap_Password = MD5 (ChapID+ Password + Challenge )4、 无论采用Chap认证还是Pap认证，都允许用户口令为空；5、 当用户向Portal Server提交的连接请求里用户名为空时，Portal Server在向AC设备发送认证请求时应用一个缺省的用户名代替（比如*）；6、 认证流程中各种报文所带属性的个数（建议）：(1) 请求Challenge 报文：0个属性；(2) 对请求Challenge响应的报文：若请求Challenge成功则为1个属性Challenge属性，若请求Challenge失败则属性个数为0个；(3) 请求认证报文：2个属性，分别为用户名、PassWord 或ChapPassWord ；(4) 对请求认证的响应报文：0个属性；(5) 请求下线报文或表示超时的报文：0个属性；(6) 对请求下线的响应报文：0个属性；(7) Portal Server对收到从AC设备发来的认证成功报文的确认：0个属性；(8) 强制下线请求：0个属性；(9) 查询请求和回应：待定；7、报文的长度限制是最小16字节，最大1024（1K）字节；8、从支持多国语言的角度出发，认证结果信息进行统一编码，由Portal Server根据用户语言上下文推送对应信息的页面。6.3. Portal与Radius间的协议6.3.1. 报文格式Portal与radius间的通信协议采用TCP/IP标准协议，请求和应答报文采用不定长报文格式。请求报文格式：命令名 流水号 参数1 参数2 参数n0x0A应答报文格式：流水号 返回码 返回信息0x0A应答报文的流水号等于请求报文的流水号，用于匹配请求与应答数据包6.3.2. 报文字段说明及参数1. 用户信息查询命令名：Wlan_UserInfo_Request参数：名称说明数据类型最大长度（字节）SerialNo流水号, 用于匹配输入与输出包String15Account用户登录帐号String253Password用户登录密码String16命令名：Wlan_UserInfo_Response参数：名称说明数据类型最大长度（字节）SerialNo同请求的流水号，用于匹配输入与输出包String15ReturnCode返回结果码0密码验证成功1用户未开户2 用户状态非正常3 密码不正确10包数据格式不正确20其他原因Int2ErrorDescription返回结果码非0时，对错误/异常的详细描述信息。String255SessionTimeout系统配置的单次连接最大时长(秒)int8AvailableTime用户可用连接时长（秒）int82. 用户动态密码申请命令名：Wlan_DynamicPwd_Request参数：名称说明数据类型最大长度（字节）SerialNo流水号, 用于匹配输入与输出包String15Account用户登录帐号String253命令名：Wlan_DynamicPwd_Response参数：名称说明数据类型最大长度（字节）SerialNo同请求的流水号，用于匹配输入与输出包String15ReturnCode返回结果码0动态密码生成成功1用户未开户2 用户状态非正常10包数据格式不正确20其他原因Int2ErrorDescription返回结果码非0时，对错误/异常的详细描述信息。String255DynamicPwd新生成的用户动态密码String167. 编制历史版本号更新时间主要内容或重大修改1.0.02002/7/31完成送审稿2.0.02008/2/26完成报批稿，满足分省运营、全品牌业务开放的需求。附录A 详细修订历史1、2002年7月31日，完成WLAN业务Portal协议规范送审稿v1.0.0，通过相关部门评审；2、2007年9月26日，引入对分省运营、个性化Portal的支持，完成送审稿v1.1.0；3、2008年1月13日，增加对全品牌、动态密码认证的支持，完成送审稿v1.2.0；4、2008年2月1日，增加对手机用户两种计费模式的支持，完成送审稿v1.3.0；5、2008年2月20日，根据业务部门反馈意见，将推送的个性化页面由“拜访地”改为“归属地”，完成修订稿v1.3.1；6、2008年2月25日，根据相关部门意见，修改动态密码下发方式。明确智能网手机用户暂不开通套餐业务。完成修订稿v1.4.0；7、2008年2月26日，完成满足分省运营、全品牌业务开放的规范，通过相关部门评审，完成报批稿v2.0.0。22