evdoreva空口信令流程分析指导书(v3).doc

evdoreva空口信令流程分析指导书(v3) CDMA网规网优部指导书GL XX.XXXXXXXX代替GL XX.XXXXXXXX EV-DO RevA空口信令流程分析指导书中兴通讯股份有限公司CDMA网规网优部文档历史这个表包含了这个文档的版本历史版本号修订日期变更内容简述作者/修订者1.0xx-1-29xx年所撰写的初稿网优技术项目组1.0xx-10-17改为部门指导书模板格式，纳入部门规范体系中张喜逢2.0xx-10-16将Rls0部门指导书更新成RevA部门指导书陈树春3.0xx-12-5增加虚拟软切换章节陈树春目录前言本文介绍了EV-DO RevA系统中常见业务的空口信令流程，结合实际的测试数据，讲解了其中主要字段的具体含义。 随着EV-DO系统的网络发展，部分流程可能会有改变，在以后的学习和应用中需要注意对比。 在本文中，介绍了3大部分的流程?Session呼叫流程（具体包括了Session建立流程、Session释放、Session的协商流程）；?Connection呼叫流程（包括了Connection建立流程、Conion建立后流应用阶段、Connection释放流程）；?切换控制（只涉及激活状态下的更软切换、软切换、换频切换的流程，DO系统Dormant状态下的切换、DO与1X之间的切换等未涉及）为了帮助读者理解，对于每个业务流程，本文采用了先介绍流程图，然后给出每条信令的具体字段解析，最后是一个具体实例的组织方式，所以篇幅相对较长。 EV-A DO RevA空口信令流程分析指导书1目的与范围本指导书目的是为EV-DO RevA信令分析提供思路和方法。 本指导书适用于CDMA网规仿真部的EV-DORevA优化工作。 2术语和定义3角色和职责4系统模块介绍下面对基站内部常见的软件模块的功能作详细介绍S_CES:信道单元子系统。 主要负责信道板CHM的基带数据的调制与解调,实现空中接口物理层的编解码和调制解调功能。 S_RCP:无线信道管理。 主要负责进行Overhead信道，接入信道，前反向业务信道等无线资源的分配与管理。 S_FSP:帧选择模块。 主要负责反向业务帧的选择，相关协议数据包的封装和解封装，前向业务帧的流量控制等。 S_TP:业务处理模块。 主要负责实现缺省应用和多流分组应用的RLP协议，前向RLP分组的流量控制等。 S_SP:信令处理模块。 主要负责相关协议的信令消息处理，连接层的信令处理流程，完成业务信道上的位置更新流程，session的配置协商，Key交换协议流程，切换的控制等S_BSSAP:基站系统应用部分。 主要负责集中管理所有已登记AT的Session信息,UATI分配，AT的移动性管理功能，快速连接过程等S_PPPSession:PPP协议会话模块。 主要负责LCP协商流程、CHAP协商流程以及PPP状态机的整个处理的流程和机制.S_AAAClient认证、授权、计费客户端模块。 主要负责对AAAServer的反馈报文的解码和处理，对AAAServer的合法性进行验证等5指导书正文5.1Session呼叫流程5.1.1Session建立5.1.1.1流程介绍上图表示的是AT主动发起一次新的会话建立流程，具体每个步骤的操作如下过程过程描述a AT在接入信道上发送接入信道capsule，包含UmaUATIRequest和UmaRouteUpdate消息，每次AT在接入信道上发送，总会包含UmaRouteUpdate消息。 该capsule由S_CES透明传送给S_BSSAP。 在capsule中AT可能使用固定生成的RATI（可能是ESN等硬件ID），或者随机生成的RATI作为自己的标识。 b S_CES对收到的接入信道capsule进行确认，通过控制信道给AT发送UmcACAck，使用AT接入信道capsule中MAC层header中包含的RATI标识c S_BSSAP记录RATI，并请求S_RCP、S_CES通过控制信道发送UmcHardwareIDRequest消息，同时启动定时器THardwareIDRequest等待响应；如果定时器超时，S_BSSAP可请求S_CES重发UmcHardwareIDRequest消息2次。 如果2次后仍未收到UmaHardwareIDResponse消息，则直接结束session建立过程，不发送任何空中接口消息d AT在接入信道上发送接入信道capsule，包含UmaHardwareIDResponse和UmaRouteUpdate消息。 S_CES传送capsule给S_BSSAP，S_BSSAP停止定时器THardwareIDRequest，记录AT的HardwareID到session数据区。 e S_CES对收到的接入信道capsule进行确认，通过控制信道发送UmcACAck，使用AT接入信道capsule中MAC层header中包含的RATI标识。 f对于128比特的UATI，S_BSSAP只负责分配低24位比特，高104位比特由SectorID127:24组成，Sector的128比特SectorID和SubMask在Overhead的SectorParameters消息中通过控制信道周期性广播。 在同一子网中，24比特的UATI是AT的唯一标识。 为避免128比特的UATI在空中传输，Sector的子网地址由8比特的ColorCode标识，这样空中接口只需要传输8比特的ColorCode和24比特的UATI就可以标识AT。 S_BSSAP分配UATI的低24位比特（该24比特数据不能和相同子网中的其它UATI的低24比特相同），和UmaUATIRequest消息收到的Sector对应的8比特ColorCode合成一个32比特的UATI，请求S_CES在控制信道发送UmcUATIAssignment消息，该消息仍然使用RATI作为AT标识，同时启动定时器TUATIComplete等待指配完成。 如果S_BSSAP分配UATI失败，应直接结束session建立过程，不发送任何空中接口消息。 如果TUATIComplete超时，S_BSSAP可请求S_CES重发UmcUATIAssignment消息2次，如果2次后仍未收到UmaUATIComplete消息，应认为session建立失败。 S_BSSAP释放为AT分配的UATI，结束session建立过程，并可通过S_CES发送UmcSessionClose消息，释放可能在AT中已经存储的UATI。 G AT在接入信道上发送接入信道capsule，包含UmaUATIComplete和UmaRouteUpdate消息，capsule中的MAC地址使用新分配的UATI而不是RATI。 S_CES传送capsule给S_BSSAP，S_BSSAP停止定时器TUATIComplete，记录AT的UATI到session数据区。 H S_CES对收到的接入信道capsule进行确认，通过控制信道发送UmcACAck，使用AT接入信道capsule中MAC层header中包含的UATI标识。 下面对上述的流程进行一个简单的介绍 (1)AT在接入信道上向AN发送接入信道capsule，包含UATIRequest和RouteUpdate消息，每次AT在接入信道上发送，总会包含RouteUpdate消息,在capsule中AT可能使用ESN或随机生成的RATI作为自己的标识； (2)AN收到的接入信道capsule进行确认，通过控制信道给AT发送ACAck，使用AT接入信道capsule中MAC层header中包含的RATI标识； (3)AN记录RATI，并通过控制信道发送HardwareIDRequest消息，请求查询AT的HarewareID信息，即查询AT的ESN(我们的设备是这样设计的),作为AN计算AT的UATI的参考； (4)AT在接入信道向AN发送接入信道capsule，包含HardwareIDResponse和RouteUpdate消息，同时AN记录AT的HardwareID到session数据区； (5)AN对收到的接入信道capsule进行确认，通过控制信道发送ACAck，使用AT接入信道capsule中MAC层header中包含的RATI标识； (6)对于128比特的UATI，AN只负责分配低24位比特,高104位比特由SectorID127:24组成,Sector的128比特SectorID和SubMask在Overhead的SectorParameters消息中通过控制信道周期性广播。 在同一子网中，24比特的UATI是AT的唯一标识。 为避免128比特的UATI在空中传输，Sector的子网地址由8比特的ColorCode标识，这样空中接口只需要传输8比特的ColorCode和24比特的UATI就可以标识AT; (7)AN分配UATI的低24位比特,和UATIRequest消息收到的Sector对应的8比特ColorCode合成一个32比特的UATI,并在控制信道向AT发送UATIAssignment消息，该消息仍然使用RATI作为AT标识，同时开始等待AT发送UATIComplete； (8)AT在接入信道上发送接入信道capsule，包含UATIComplete和RouteUpdate消息，capsule中的MAC地址使用新分配的UATI而不是RATI，AN记录AT的UATI到session数据区; (9)AN对收到的接入信道capsule进行确认，通过控制信道发送UmcACAck，使用AT接入信道capsule中MAC层header中包含的UATI标识;5.1.1.2RouteUpdate MeesageIDAT固定设置为0x00；MessageSequence消息的序列号，应该比上一个RouteUpdate消息中的序列号大1，范围为0255；ReferencePilotPN参考导频；ReferencePilotStrength参考导频的强度。 该值是按照210log（PS）向下取整计算；其中PS为参考导频强度ReferenceKeep若基准导频的导频去掉计时器已经超时，则该字段设置为0，指示应去掉参考导频；否则该字段设置为1，指示应保留参考导频；NumPilots除参考导频外的导频数目；PilotPNPhase导频相位，由此可以计算出导频偏置；ChannelIncluded如果此导频偏置的信道与当前的信道不同，则设置该字段为1，否则设置为0；所谓信道指的是频点，所以在信令中看到的该字段绝大部分是0；Channel如果ChannelIncluded字段设置为1，那么设置它为此导频对应的频点，否则将忽略这个字段。 PilotStrength和ReferencePilotStrength类似；Keep和ReferenceKeep类似。 AT向AN发送RouteUpdate消息，主要用于报告AT当前的无线传播环境。 该消息在每次Session呼叫都会有该条消息和UATIRequest一起上报，在切换的时候，也是由AT首先上报RouteUpdate消息开始。 切换上报的RouteUpdate和Session呼叫、Connection呼叫等呼叫流程起始的RouteUpdate有一个区别呼叫最初上报的路由更新消息中只有起呼主导频的信息，而切换最初上报的消息中则含有多个导频的信息。 5.1.1.3UATIRequest AT发送UATIRequest消息请求AN分配一个UATI.MessageID固定设置为0x00；TransactionIDAT每发送一次新的UATIRequest，就将该字段增加1，该字段的范围是0255；5.1.1.4ACACK AN发ACAck消息，以确认接收到接入信道的MAC层包。 MessageIDAN固定设置该字段为0x00；5.1.1.5HardwareIDRequest AN利用这条消息请求获取AT的HarewareID信息。 MessageIDAN固定设置为0x03；TransactionID每发送一个新的HardwareIDRequest，该字段增加1；5.1.1.6HardwareIDResponse AT发送这条消息响应HardwareIDRequest消息，该消息包含AT的HardwareID信息。 MessageIDAT固定设置为0x04；TransactionID应该设置为所对应的HardwareIDRequeset消息的TransactionID字段；HardwareIDTypeAT将根据下面这个表格来填写这个字段HardwareIDLength如果HardwareID不是0xFFFFFF，那么AT设置这个字段为HardwareIDValue的字节长度，否则设置为0；HardwareIDValueAT设置该字段为厂商分配给AT的唯一ID。 5.1.1.7UATIAssignment AN通过该消息为AT分配一个UATI。 MessageID固定设置为0x01；MessageSequence每下发一个UATIAssigment，该字段固定增加1，但是需要注意的是这里说的UATIAssignment是针对同一个AT而言的。 SubInclued:若该消息包含UATI104字段和UATISubMask字段，则该字段置应设为1，否则为0UATISubMask如果AT设置SubInclued为0，则忽略该字段；如果AT设置SubInclued为1,包含该字段，则AN应设置该字段为分配的UATI所属的子网掩码中连续1的个数。 UATI104:如果AT设置SubInclued为0，则忽略该字段；如果AT设置SubInclued为1,包含该字段，则AN应设置该字段为分配给AT的UATI的UATI127:24UATIColorCodeUATI颜色码。 AN应设置该字段为UATI所属子网对应的颜色码。 UATI024:AN设置该字段为分配给AT的UATI的UATI23:0.UpperOldUATILengthAN设置该字段为将在UATIComplete消息中发送OldUATI127:24从最低有效位开始的字节数目。 5.1.1.8UATIComplete AT发送该消息证实收到的UATIAssignment消息。 MessageID固定设置为0x02；MessageSequence设置为所对应的UATIAssignment的MessageSequence字段；UpperOldUATILength:AT设置该字段为UpperOldUATI的字节长度。 UpperOldUATI若此消息所确认的UATIAssignment消息中的UpperOldUATILength非零，并且OldUATI不为NULL，则接入终端设置该字段为OldUATI23+UpperOldUATILength*8:245.1.1.9具体例子上图是一个QXDM记录完整的Session建立流程。 ?RouteUpdate该条信令的具体实例见切换控制流程中的实例?UATIRequest首先AT发起UATIRequest消息，请求AN分配UATI。 从该条消息可以获取以下信息transaction_id=12,说明在该消息之前，已经发送过11条不同的UATI Request消息。 ?ACAck AN发送该消息证实接收到接入信道的MAC层包?HardwareIDRequest AN发送该消息请求获取AT的HardwareID，以便作为AN计算UATI的参考。 从这条信令可以看出，transaction_id=0,说明该消息是第一次发送Hardware IDRequest消息，并且可以推断后面的HardwareID Response的transaction_id也为0。 ?HardwareIDReponse该消息携带HarewareID的信息，从这条信令可以看出，hardware_id_length=4，hardware_id共4个字节；由于所对应的HardwareIDRequest中的TransactionID为0，所以本消息中这个字段也为0。 Hardware_id_type值设置为0x10000，说明hardward_id属于ESN类型。 ?UATIAssignment该消息为AT分配UATI，从信令中看到sub_included设置为0，说明不包含UATI104和SubMask两个字段；UATIColorCode设置为5，说明UATI所属子网的颜色码为5；uati_024=196717(0x3006d),此字段的值为AN所分配的低24位的UATI的值，UpperOldUATILength为0；message_sequence=0，可以推断出后面的UATIComplete的message_sequence也为0。 ?UATIComplete本消息为UATIAssignment消息的应答消息。 由于所对应的UATIAssignment消息中MessageSequence为0，所以本消息中也设置该字段为0；由于上条消息中UpperOldUATILength设置为0，所以本消息中该字段也设置为0。 5.1.2Session释放5.1.2.1AT在接入信道发起Session释放5.1.2.1.1流程介绍过程过程描述a AT在接入信道上发送接入信道capsule，包含UmaSessionClose和UmaRouteUpdate消息。 b S_CES对收到的接入信道capsule进行确认，通过控制信道发送UmcACAck，使用AT接入信道capsule中MAC层header中包含的UATI标识。 S_BSSAP向PCF发送A9UpdateA8消息，请求释放A10连接。 c S_PCF判断是否存在A10连接，如果存在，则向PDSN发送A11RegistrationRequest，请求释放A10连接d PDSN向S_PCF发送A11RegistrationReply，接受A10释放请求。 e PCF向S_BSSAP发送A9UpdateA8Ack，确认释放A10连接。 S_BSSAP清除AT的session数据。 该流程可简化为 (1)AT在接入信道发起Session释放，首先在接入信道上发送SessionClose和RouteUpdate消息的capsule； (2)AN对收到的接入信道capsule进行确认，通过控制信道发送ACAck，使用AT接入信道capsule中MAC层header中包含的UATI标识。 (3)释放A10连接5.1.2.2AT在业务信道发起Session释放5.1.2.2.1流程介绍过程过程描述a AT在反向业务信道发送UmrSessionClose消息（没有UmaRouteUpdate），请求关闭session。 b S_SP发送AvrConnectionRelease消息给S_BSSAP，通知S_BSSAP开始释放相应资源。 同时S_SP向S_RCP发送AbiscfConnectionRelease，请求释放无线资源，并开启定时器Tabisonnectionrelease。 如果Tabisonnectionrelease超时，S_SP清除通道表。 c S_BSSAP发送AvfConnectionReleaseAck给S_SP，确认收到通知，并开启定时器Tconnectionrelease，等待AvrConnectionReleaseComplete。 如果Tconnectionrelease超时，S_BSSAP发起连接终止。 S_RCP发送AmfConnectionRelease给S_CES，释放前反向信道单元。 d S_BSSAP发送A9ReleaseA8给PCF，启动释放A8连接和A10连接。 S_CES发送AmrConnectionReleaseAck给S_RCP，确认释放完成。 e PCF向PDSN发送A11RegistrationRequest请求释放A10连接。 S_RCP发送AbiscrConnectionReleaseAck给S_SP，确认无线资源已经释放。 f S_SP发送AvrConnectionReleaseComplete给S_BSSAP，带有session关闭指示,完成释放，S_BSSAP释放分配的选择器和CallRefId，停止定时器Tconnectionrelease，清除AT的session数据。 g PDSN向PCF发送A11RegistrationReply，确认释放A10连接。 S_SP调用S_FSP的Deactive函数，通知FSP停止帧选择和分发处理。 h PCF向S_BSSAP发送A9ReleaseA8Complete，确认A8连接已经释放。 S_SP调用S_TP的Deactive函数，通知TP停止业务数据处理。 该流程可简化为 (1)AT在业务信道上发起Session释放，首先在反向业务信道上发送SessionClose消息，请求关闭session； (2)AN释放无线资源、A 8、A10连接 (3)AN关闭session，清除AT的session数据区。 5.1.2.3AN发起Session释放-Session配置失败5.1.2.3.1流程介绍过程过程描述a S_SP和AT的session协商失败，启动连接释放，通过控制信道向AT发送UmfSessionClose消息。 由于AT是否回UmrSessionClose不会影响后续流程，所以S_SP不设定时器b S_SP收到AT在接入信道上发送的UmrSessionClose消息。 c S_SP发送AvrConnectionRelease消息给S_BSSAP，通知S_BSSAP开始释放相应资源。 同时S_SP向S_RCP发送AbiscfConnectionRelease，请求释放无线资源，并开启定时器Tabisonnectionrelease。 如果Tabisonnectionrelease超时，S_SP清除通道表。 d S_BSSAP发送AvfConnectionReleaseAck给S_SP，确认收到通知，并开启定时器Tconnectionrelease，等待AvrConnectionReleaseComplete。 如果Tconnectionrelease超时，S_BSSAP发起连接终止。 S_RCP发送AmfConnectionRelease给S_CES，释放前反向信道单元。 e S_BSSAP发送A9ReleaseA8给PCF，启动释放A8连接和A10连接。 S_CES发送AmrConnectionReleaseAck给S_RCP，确认释放完成。 f PCF向PDSN发送A11RegistrationRequest请求释放A10连接。 S_RCP发送AbiscrConnectionReleaseAck给S_SP，确认无线资源已经释放g S_SP发送AvrConnectionReleaseComplete给S_BSSAP，带有session关闭指示,完成释放，S_BSSAP释放分配的选择器和CallRefId，停止定时器Tconnectionrelease，清除AT的session数据h PDSN向PCF发送A11RegistrationReply，确认释放A10连接。 S_SP调用S_FSP的Deactive函数，通知FSP停止帧选择和分发处理i PCF向S_BSSAP发送A9ReleaseA8Complete，确认A8连接已经释放。 S_SP调用S_TP的Deactive函数，通知TP停止业务数据处理该流程可简化为 (1)AN和AT的session协商失败，启动连接释放,通过控制信道向AT发送SessionClose消息,请求session关闭; (2)AN收到AT在接入信道上发送的SessionClose消息,开始释放无线资源、A 8、A10连接 (3)AN关闭session，清除AT的session数据5.1.2.3.2SessionClose发送方发送SessionClose消息来结束Session MessageID固定设置为0x01;CloseReason发送方按下表设置Close的原因MoreInfoLenMoreInfo字段的字节长度；MoreInfo关闭的附加信息，该字段的格式取决于具体的关闭原因5.1.2.3.3具体例子上图是一个QXDM记录完整的AN发起Session释放-Session配置失败流程。 ?Session Close从上面的信令可以看出，close_reason=5(0x5)(Session ConfigurationFailure)，说明session关闭的原因是session配置失败。 ?Session Close从上面的信令来看，close_reason=1(0x1)(Close Reply)，说明Session Close消息中关闭的原因是关闭响应，即响应上一条的由于session配置失败的Session Close消息5.1.3Session协商5.1.3.1流程介绍上面显示的Session进行协商的流程，在此之前是完整的Session建立流程和Conion建立流程，见本文中的4.1.1和4.2.1。 本部分流程中的具体操作如下过程过程描述a AT发起Conion建立b如果在AvfConionSetup消息中指示进行协议协商，S_SP发送UmrConfigurationStart给AT。 c开始协商第一个personnality(也称为main personality，personalityIndexStore=0)。 Main personality是一个Release0personality。 AT发送UmrConfigurationRequest消息，协议类型为SCP，UmrConfigurationRequest中包含AT所支持的所有非缺省Protocol subtypes(HardLink subtype除外，因为所有protocols均支持HardLink subtype)。 协商进入AT启动阶段d S_SP发送UmfConfiguratonResponse消息，协议类型为SCP，确认或提议新的协议参数。 由于main personality是一个Release0personality，S_SP选择缺省物理层、缺省FTCMAC和缺省RTCMAC e-f AT发起Stream Protocol的协商g-j AT发起其它procotol subtype协商k AT完成需要协商的协议参数以后，发送UmrConfigurationComplete，结束协商AT的启动阶段l-m如果AN需要继续进行协商，S_SP发送UmrConfigurationRequest消息，协议类型为SCP，协商进入AN启动阶段。 n-o AN发起Stream Protocol的协商，以协商出绑定在RAN上的缺省分组的应用p-s AN发起其它procotol subtype协商t-w如果在前面协商中指定使用Key交换协议，则进入Key交换过程。 x AN和AT完成main personality协商后，S_SP通过UmfSoftConfigurationComplete中continue=1字段通知AT开始下一个personality的协商，除main personality是唯一的一个Release0personality外，其余的personalities均为Rev Apersonality yAT选择那些在协商main personality时AT曾发起过协商的protocols，向AN推荐HardLink subtype。 采用这样的策略，AT可以避免再对这些protocols进行不必要的协商。 z由于当前协商的是一个Rev Apersonality，所以AN选择物理层ST2，增强型FTCMAC和RTCMAC ST3。 aa-bb AT发起Stream Protocol的协商-hh AT发起其他protocol subtype的协商ii AT完成需要协商的协议参数后，发送UmrConfigurationComplete，结束协商的AT启动阶段jj-kk如果AN需要继续进行协商，S_SP发送UmfConfigurationRequest，协议类型为SCP ll-mm AN发起Stream Protocol的协商nn-uu AN发起其他protocol subtype的协商vv第二个personality协商完闭后，S_SP通过UmfSoftConfigurationComplete中Continue=0通知AT不必进行其他personality的协商。 同时，如果当前活动集中只有CHM6800的导频，S_SP把UmfSoftConfigurationComplete中的SessionConfigurationToken的高4bit置为1（即通知AT使用Rev Apersonality）；否则置为0（即通知AT使用Rev0personality）ww AT发送UmrSLPAck，确认收到UmfSoftConfigurationComplete xxS_SP向S_BSSAP发送AvrSessionConfigurationComplete，把当前协商后的协议配置参数发送给S_BSSAP yyS_SP启动连接关闭，发送UmfConnectionClose消息。 该流程较为复杂，对该流程的梳理，详细见4.1.3.7的介绍。 5.1.3.2ConfigurationStart该条消息用于提示开始session协商的流程，该消息的内容比较简单，只有一个域MessageID，固定设置为0x01，该消息是由AN发送给AT的，一旦AN发出该消息，那么AT和AN的会话配置协议状态都应该跳转到“AT始发”状态。 在会话配置协议中共有四种状态?非激活状态此状态下，等待Activate命令。 ?AT始发状态此状态下，协商由接入终端发起。 ?AN始发状态此状态下，协商由AN发起。 ?开状态此状态下，AT可以在任何时间启动会话配置过程，AN可以在任何时间请求AT始发会话配置。 对于四个状态之间的转换可以结合下面的状态机来看，也可以了解为什么流程图中是AT先进行协商等。 下图为AT侧会话配置协议状态图。 刚开始AT侧是处于Inactive状态，当触发以下条件时，将进行状态转化触发进入Inactive状态的条件AT始发、AN始发、OPEN三种状态，AT收到Deactive命令；触发进入OPEN状态的条件 (1)Inactive状态下，AT收到active命令； （2）AN始发状态下，AT收到ComfigurationComplete消息，结束AN侧的始发协商过程；或者AT收到SoftconfigurationComplete消息携带Continue字段为0，不需要进行下一个Personality的协商。 ；触发进入AT始发状态的条件 （1）OPEN状态下，AT收到ConfigurationStart，开始协商过程；或者AT发送ConfigurationRequest消息；或者AT发送任何InConfiguration消息； (2)AN始发状态下，AT收到SoftConfigurationComplete消息携带Continue字段为1，需要进行下一个Personality的协商。 触发进入AN始发状态的条件 （1）AT始发状态下，AT发送ConfigurationComplete，结束AT侧的始发协商过程；下图为AN侧会话配置协议状态图刚开始AN侧是处于Inactive状态，当触发以下条件时，将进行状态转化触发进入Inactive状态的条件AT始发、AN始发、OPEN三种状态，AN收到Deactive命令。 触发进入OPEN状态的条件 （1）Inactive状态下，AN收到active命令； （2）AN始发状态下，AN发送ComfigurationComplete消息，结束AN侧的始发协商过程；或者AN发送SoftconfigurationComplete消息携带Continue字段为0，不需要进行下一个Personality的协商。 ；触发进入AT始发状态的条件1）OPEN状态下，AN发送ConfigurationStart，开始协商过程；或者AN接收ConfigurationRequest消息；或者AN接收任何InConfiguration消息； (2)AN始发状态下，AN发送SoftConfigurationComplete消息携带Continue字段为1，需要进行下一个Personality的协商。 触发进入AN始发状态的条件 （1）AT始发状态下，AN接收ConfigurationComplete，结束AT侧的始发协商过程；对比上述两个状态图，其实AT侧的状态转化图和AN侧的状态转化图是一一对应的，有两种情况将回到AT的始发状态 (1)每次AN始发状态，AT收到或者AN发送SoftConfigurationComplete携带Continue字段为1，都将回到AT的始发状态； (2)每次AN始发状态，AT接收或AN发送ConfigurationComplete，或者AT接收或AN发送Soft ConfigurationComplete携带Continue字段为0，状态都将转化为OPEN状态；从OPEN状态，AT接收或AN发送ConfigurationStart，或者AT发送或AN接收ConfigurationRequest，或者AT接收或AN发送任何Inconfiguration的消息，状态都将回到AT的始发状态；因此这可以解释为什么流程图中是AT先进行协商等5.1.3.3ConfigurationRequest在这里需要介绍一下属性记录（AttributeRecord）这个概念。 它为给定属性定义一套建议值，属性记录格式被定义，可以使得接收方不能识别此属性，则它也能够丢弃它并分析此记录随后的属性记录。 一个属性可以是以下三类中的一种?简单属性假如属性记录中只包含单个值；?属性列表假如属性记录包含多种单个值，它们被解释为相同属性标志符的不同建议值；（如相同协议类型的可能协议子类型列表）?综合属性如果属性记录中包含多种单个值，这些值一起形成一个特定属性标志符的综合值；单个属性和属性列表的格式如下其中Length是属性记录的长度，单位为字节，但是不包含Length域本身；AttributeID是属性标志符，在正在配置的协议上下文中，属性标志符是唯一不变的；AttributeValue是属性建议值，通常属性建议值长度是字节的整数倍。 Reserved字节的长度是使得属性记录字节对齐的最小值，如果发送方设置该域为0，那么接收方忽略该字段。 综合属性的结构如下所示其中Length同样是属性记录的长度，也不包含Length域本身，但是包含ValueID域的长度。 ValueID是用来标记一套属性值的，每增加一套属性值，ValueID就应该增加1。 其余字段含义和属性记录的字段含义一样。 MessageID发送方设置该字段为Ox50;TransactionID:每发送一个新的ConfigurationRequest消息，该字段增加1；该消息携带一个或多个属性记录，并请求应答方选择一个属性值。 5.1.3.4ConfigurationResponse应答方发送ConfigurationResponse消息从所提供建议值列表中选择一个属性值。 如果ConfigurationRequest中是单个属性或者是属性列表，那么就是直接选择一个属性值，如果Request消息中是一个综合属性，那么Response消息中就回复某一个ValueID。 ConfigurationResponse消息一般要在T umaround定时器内回复给发送方，该定时器定义为2s。 MessageID:固定设置为0x51;TransactionID:应设置为对应的ConfigurationRequest消息的TransactionID字段。 该消息中应答方回复一个属性值或者ValueID给发送方，以协商确认的协议属性5.1.3.5ConfigurationComplete发送方发送ConfigurationComplete消息，以指示它已经完成它始发执行的协商过程。 MessageID固定设置为0x00；TransactionIDAT为每个新发送的ConfigurationComplete消息增加该值，AN设置该字段为从AT接收到的上也ConfigurationComplete消息中的TransactionID值。 SessionConfigurationToken会话配置标志。 接入终端应该忽略该域，AN包含该域，AN可以设置该域为反映协商的协议和协商的参数。 5.1.3.6SoftConfigurationComplete AN发送SoftConfigurationComplete消息，指示它已经完成这个personality的协商过程。 MessageID固定设置为0x02;TransationIDAN应设置该字段为从AT接收到最后一条ConfigurationComplete消息的TransationID PersonalityIndexStoreAN设置该字段为即将保存的personality indexContinue:如果AN需要协商更多的personality，则AN应设置该字段为1，否则AN设置该字段为0；Commit如果Continue字段设置为1，则AN忽略该字段；否则AN应按照下面来设置该字段如果Commit流程需要，AN设置该字段为1，否则AN设置该字段为0；SessionConfigurationToken如果Continue字段设置为1，则AN忽略该字段；否则AN包含该字段。 如果Commit字段设置为1，则该字段4个最高有效比特应设置将要被提交的personality index，否则4个最高有效比特应设置成当前正在使用的personality index；AN可能设置该字段的最低12个最低有效比特的值，以反映协商过程中所选择的协议和协商的参数5.1.3.7具体例子结合上述的Request和Response消息的格式以及最初的流程介绍，可以看一个比较完整的Session配置实例,由于该流程较长，分两部分截屏。 第一部分截屏从Configuration Start消息到出现第一条Soft Configuration Complete，AT和AN完成完成了Release0personality的协商，此协商分AT始发阶段的协商和AN始发阶段的两部分的协商。 第二部分截屏从Configuration Request消息到出现第二条Soft Configuration Complete消息，AT和AN完成了Rev Apersonality的协商，此协商同样也分AT始发阶段的协商和AN始发阶段的两部分的协商。 从实例上看，首先进行的是Release0personality的协商，在这部分先进行的是AT始发阶段协商(即AT在反向业务信道上发送Configuration Request消息，前向业务信道上应答Configuration Response消息)，AT始发阶段分别进行了Stream、Route Update、Stream2Multiflow PacketApplication(即MPA Stream2)等协议的协商，接着由AT发送Configuration Complete消息开始AN始发阶段协商，AN始发阶段分别进行Stream、FTC MAC、RTC MAC、Route Update、Address Management、Default Stream2等协议的协商。 AN发送Soft Configuration Complete开始进入Rev Apersonality的协商，在这部分先进行的也是AT始发阶段协商，AT始发阶段分别进行Stream、Route Update、RTC MAC、MPA Stream2等协议的协商，同样也是由AT发送ConfigurationComplete消息开始AN始发阶段协商，AN始发阶段分别进行了Stream、Control ChannelMAC、Aess ChannelMAC、RTC MAC、MPA Stream2等协议的协商。 ?ConfigurationStart AN发出该条信令以后，即开始session的协商过程。 ?ConfigurationRequest（T AT侧发起协商）首先进行的是Release0的协商，先进行的是AT始发阶段协商，AT在反向上发送Configuration Request消息，分别进行了Stream、Route Update、Stream2Multiflow PacketApplication等协议协商，这里以Stream协议协商为例。 从上图看到这里使用的是综合属性，pro