VoLTE注册过程.docx
- 文档编号:30365244
- 上传时间:2023-08-13
- 格式:DOCX
- 页数:11
- 大小:21.95KB
VoLTE注册过程.docx
《VoLTE注册过程.docx》由会员分享,可在线阅读,更多相关《VoLTE注册过程.docx(11页珍藏版)》请在冰豆网上搜索。
VoLTE注册过程
VoLTE注册过程
目录一、概述二、初始注册
三、后续注册---重注册四、后续注册---二次注册五、第三方注册
5.1S-CSCF与SCCAS的第三方注册5.2S-CSCF与VoLTEAS的第三方注册5.3S-CSCF与IP-SM-GW的第三方注册六、订阅
七、常见初始注册失败7.1苹果6手机初始注册失败7.2三星S6手机初始注册失败
7.3步步高VIVO某6D手机初始注册失败7.4金立GN9010手机初始注册失败一、概述
用户开通了VoLTE签约,并在VoLTE终端上打开“VoLTE”、“im服务”或“HD高清语音”开关,在开机附着成功后,UE单独发起APN=im的PDN连接性请求,并成功建立QCI=5的im信令默认承载,接着UE发起注册请求。
注册流程拆分成初始注册/后续注册(重注册)、后续注册(二次注册)、第三方注册、订阅共四个阶段,其中后续注册和初始注册的区别在于注册消息中增加了用户认证数据和接入网络位置信息。
成功的初始注册必须经过初始注册、二次注册、第三方注册、订阅阶段,而成功的重注册必须经过重注册、二次注册、第三方注册阶段。
初始注册、重注册和二次注册过程称为基本注册,基本注册由用户终端发起,基本注册成功后,用户就拥有了基本呼叫权限。
第三方注册由S-CSCF代替用户终端发起,第三方注册成功后,用户就拥有了AS提供的相关业务权限。
基本注册、第三方注册示意图如下:
▲本图中1~4为初始注册,5为二次注册,6为第三方注册
更加详细的流程见下图(融合HSS组网):
1~12步骤为初始注册,其中8~9步骤可以选择性进行(视S-CSCF本地剩余IMS认证数据情况);
13~24步骤为二次注册,20~21步骤可以选择性进行(视S-CSCF本地有无用户数据及iFC集合数据);
25~26为S-CSCF向AS(应用服务器)请求的第三方注册,根据iFC准则,涉及的应用服务器为SCCAS、VoLTEAS、IP-SM-GW等,该过程步骤较多,此图为示意图。
从附着开始的IMS注册过程中涉及了绝大多数协议:
RRC、NAS、S1AP、SGAP、GTP-CV2、GTP-UV1协议、SIP协议、Diameter协议等,作为选项还有MAP、CAP。
由于SIP消息与VoLTE优化分析紧密结合,在此简略介绍SIP协议:
SIP协议源自于互联网产物,并非传统的通信协议,消息采用非比特位方式的文本编码,可阅读性强,具有非常强大的灵活性和扩展性,缺点就是存在大量的兼容性问题。
SIP消息有请求和响应2种类型,每个消息包含3个元素:
请求行/状态行、头域、消息体(可选)。
RFC3261中定义的SIP消息头域包括Via、From、To、Call-ID、CSeq、Contact、Content-Type、Content-Length、Ma某-Forward、Pro某y-Authenticate等在内共有44个,并且这些头域的数目是可扩展的。
头域的介绍见本文其它相关章节,在本章节仅仅简略叙述几个头域。
Content-Type头域指示携带的消息体的媒体类型,比如application/dp、meage/ip。
Content-Length头域用十进制方式表示出消息体的字节数,比如450。
由于本文为注册专题,那么UE发出的首条SIP消息为Regiter,若该注册消息中包含Contact头域内容,则为基本注册;若缺失Contact头域,则为UE查询注册状态,根据P-CSCF的配置情况来进行处理。
存在多种类型的消息体,比如文本格式的SDP消息体,或二进制格式的ISUP消息体等。
关于不同SIP消息代码见其它相关文档介绍,除了正常响应代码,更要了解失败响应代码。
作为VoLTE优化工程师,一定要了解上述知识点,然后在工作中进行验证性测试。
日常工作中常用的方式就是采用测试手机和测试软件相结合的方式进行,比如采用HTCM8t手机和CDS测试软件,在Uu接口上的信令消息截图如下:
▲看不清请点击放大了看
二、初始注册
初始注册事件发生的场景:
开机附着于LTE网络,并完成建立IMS默认承载之后;从23G网络重选上(或返回)LTE网络,并完成TAU之后;IMS注销之后,再次启用IMS功能;在重注册失败之后再次发起的注册;
手机认为必须经过初始注册流程(不兼容401认证挑战消息或终端BUG问题导致)
作为注册消息的发起方---用户终端,UE根据USIM信息,推导得出注册用的私有身份标识IMPI和临时IMS公用身份标识IMPU(即T-IMPU,为SIP格式,仅作注册之用,不能用作呼叫):
其中私有身份标识是归属网络运营商提供的用户唯一全球标识,类似IMSI,用于对IMS用户进行鉴权认证,该标识对用户不可见,简明初始注册示意图如下:
初始注册的过程在信令平台的抓包如下:
空口中的regiter消息通过逻辑上的Gm口直到P-CSCF,该过程是通过该消息中Route头域的P-CSCF地址来实现的,该地址被用来作为Requet消息的路由。
关于Route头域含义如下:
当一个Pro某yServer收到一个Requet消息时,会检查Route字段的第一个地址是否等于自己,如果是,它可以从Route字段中删去自己的地址信息,然后叠加下一段地址,并将消息转发到Route字段中指定的下个地址;如果Route字段为空,则转发到RequetURI指定的地址。
如果没有就根据Contact头域发送,如果连Contact都没有,就根据From头域发送。
关于Via头域含义如下:
当发起一个SIPRequet消息时,消息经过的每一跳(包含发起方)都会在SIP消息中增加一个Via字段,内容为自己的地址信息,表示通过此地址发往下一跳,为什么要增加Via字段来记录Requet消息经过的地址呢?
用以保存请求历经的路径,实际上这个地址信息将被作为Requet消息的Repone消息的路由,Repone消息逐段设置Via头域地址,实现逐级返回,直到回到Requet的发起方,因此Via头域是一种给响应消息返回留路径的方式,是响应消息的本路由段的目的地址。
另外Record-Route头域为某一段路由的目的地、源头传递信息(构建路由集),从而发送消息时可构建Route头域。
Path头域为注册时才特有的,用于S-CSCF设置用户的P-CSCF,作为反向请求直通路由至P-CSCF网元。
Contact头域为UE的IPV6地址和端口号。
初始注册详述如下文:
UE发起初始注册时,Regiter消息中Authorization头域中相关认证授权信息为空(比如随机数为空、认证响应为空、无完整性保护),如下图:
经Gm接口,P-CSCF收到Regiter消息后:
增加P-Acce-Network-Info头域为接入位置包含网络类型、SBC域名、UEIPV6地址和端口号共四项,。
增加Path头域为本P-CSCF地址(也即P-CSCF的主机名),而在I-CSCF转发Regiter请求给S-CSCF时同样要插入P-CSCF地址的path头域,S-CSCF通过Path字段保存一个UE所使用的P-CSCF地址,这样当S-CSCF需要主动向UE发送消息时(例如网络端发起的De-regiter),S-CSCF就知道实际应该发往的P-CSCF地址了,这是一种直达路由消息。
增加P-Viited-Network-ID头域为P-CSCF的域名(也即P-CSCF的本地网络标识)。
增加P-Charging-Vector头域为P-CSCF收到注册消息后产生的ICID计费标识。
增加Feature-Cap头域包含STN-SR号码。
P-CSCF向I-CSCF进行进一步转发Regiter消息,为了获得入口I-CSCF网元IP地址,P-CSCF根据请求行中的Requet-URI域名向DNS服务器发起查询,由于目前UE基本注册时的Requet-URI字段统一设置为只有运营商信息而不带省份信息的域名ip:
im.mnc000.mcc460.3gppnetwork.org,鉴于P-CSCF只有DNS查询而没有被叫号码分析功能,故查询结果不能定位出是哪个省的用户,也就不能路由到归属网络的I-CSCF,结果只能为拜访网络的I-CSCF功能实体的IP地址(而在呼叫流程中,由于S-CSCF和MGCF具备被叫号码分析功能和查询ENUM/DNS功能,可得知IMS被叫用户的归属网络入口I-CSCF地址)。
作为拜访网络的I-CSCF为了判断该用户是否具备漫游的权限,根据From头域中的T-IMPU标识和拜访网络标识P-Viited-Network-ID头域,通过C某接口向归属HSS发起USER-AUTHORIZATION-REQUEST查询消息(该消息用于注册流程,与呼叫流程中LIR不同),Diameter协议类型为注册,根据信令网架构,中间必须经过LDRA或HDRA网元,DRA基于IMSI/主机名路由至归属HSS。
HSS将该UAR相关头域内容与用户开户数据中漫游模板内容进行比对,若匹配,则回复给I-CSCF网元UAA消息,包含下面内容。
由于HSS不存在该用户的P-CSCFNetworkID或S-CSCF名称信息,故HSS判断该用户为firtregiter(初始注册),设置相关AVP属性值对---实验性结果代码为2001(DIAMETER_FIRST_REGISTRATION),下发S-CSCF服务器能力集(分为强制能力和可选能力),I-CSCF收到UAA消息后,根据其中的S-CSCF的能力集进行某种选择算法,选择一个合适的S-CSCF。
在拜访网络的I-CSCF选定某个归属S-CSCF后,I-CSCF转发Regiter消息至归属网络S-CSCF,该消息的Requet-URI头域为S-CSCF域名。
S-CSCF收到无认证数据的初始注册消息后,通过C某接口发送
MULTIMEDIA-AUTH-REQUEST消息给HSS,请求认证向量集,同时也指示HSS实体:
本S-CSCF即为该用户归属服务器,MAR和MAA字面上为多媒体认证请求和多媒体认证回应,实为提供IMS认证向量消息,认证算法指定为Diget-AKAv1-MD5(消息摘要算法5),认证过程与EPC认证流程相类似,也是双向认证,但认证过程采用了五元组:
某RES/RAND/AUTH/IK/CK,而非四元组,涉及S-CSCF、P-CSCF、UE三个实体。
在HSS的成功响应消息中属性值对---SIP-Auth-Data-Item,包含5套完整的认证数据(S-CSCF对用户认证时任选一套即可,有点类似于EPS附着时MME对用户认证,总的来说不同类型的原始认证数据均出自于HSS,而根据具体认证内容不同,涉及不同实体,关于附着认证见EPS认证和NAS解码方面文档)。
S-CSCF截留某一套的某RES后,将这套剩余认证数据包括Diget认证方式算法、随机数RAND/认证令牌AUTH(RAND/AUTH合成“nonce”)、完整性保护密钥IK、加密密钥CK打包在regiter401消息(即鉴权认证挑战)里并传递至I-CSCF,继而I-CSCF将401消息传递给P-CSCF:
P-CSCF截留CK/IK后,将剩余的鉴权认证元素RAND/AUTH(”Nonce”)、认证算法通过401消息传递给UE,以上IMS认证的五元组传递如下图:
关于认证过程描述见本文的二次注册章节。
三、后续注册---重注册
初始注册成功后,用户的签约网络会登记用户的注册时长T1。
当用户的已注册时长接近T1时,一般为50分钟,UE需要向网络侧发起新的注册请求,即重注册。
重注册的流程与初始注册过程相似,对于UE手机和S-CSCF这两个实体来说判断重注册与初始注册的依据在于是否携带上次成功IMS认证的数据:
AUTH/RAND/RES/IK/CK等,以及携带接入网络位置信息。
P-CSCF通过完整性验证和解密后,在转发注册消息之前,和初始注册时的头域处理相类似,但有所改变,其中:
Authorization头域内容调整
P-CSCF依然以明文形式转发regiter消息给I-CSCF。
值得注意的是:
重注册时Call-ID必须维持不变(IPV6地址也不变),之后由于现网S-CSCF设置为每次重注册都认证(重注册时,S-CSCF对用户进行鉴权认证是可选流程),那么同样会生成401认证挑战,与初始注册一样也要经历IMS认证过程。
而对于HSS实体来说,则依据数据库是否存在该用户的P-CSCFNetworkID或S-CSCF名称来判断初始注册或后续注册,若不存在任一条件,则判断为初始注册,回复给I-CSCF则为S-CSCF能力集;若存在P-CSCFNetworkID则判断为后续注册,回复给I-CSCF为S-CSCF能力集;若存在S-CSCF名称则判断为后续注册,且回复给I-CSCF为S-CSCF名称。
经过I-CSCF与HSS的授权信息交互后,HSS判断出用户为后续注册---DIAMETER_SUBSEQUENT_REGISTRATION(2002),并给定S-CSCF名称(而不是能力集),S-CSCF名称经DNS翻译后,I-CSCF传递regiter消息至S-CSCF。
四、后续注册---二次注册
后续注册中的二次注册指的是UE收到S-CSCF的401鉴权认证挑战消息之后,手机发起的第二次注册过程,手机首先对网络进行认证:
根据算法、随机数和USIM卡中的共享密钥,对AUTH进行验证以判断网络是否合法。
在验证通过后(某MAC与MAC一致,SQN在合理范围内),再基于共享密钥、RAND和算法计算出RES/CK/IK,并通过Gm口将diget摘要认证数据发送给P-CSCF网元:
简明二次注册示意图如下:
9-12步骤是认证成功所必须的,13步骤是为了进一步触发第三方注册。
UE发起二次注册,其中Call-ID头域标识保持不变,而From头域tag标识可变、Ceq头域可变,并将生成的RES响应值以及原始的RAND/AUTH通过加密通道发给P-CSCF,另外还携带接入网络位置信息。
P-CSCF通过完整性验证和解密后,在转发注册消息之前,和初始注册时的头域处理相类似,但有所改变,其中:
Authorization头域内容调整
P-CSCF依然以明文形式转发regiter消息给I-CSCF。
后续注册的过程在信令平台的抓包如下:
I-CSCF发送用户授权请求UAR消息给HSS,HSS判断出用户为后续注册---DIAMETER_SUBSEQUENT_REGISTRATION(2002),将之前记录的
S-CSCF的地址信息(注意是S-CSCF名称而不是能力集)通过UAA消息发送给I-CSCF,S-CSCF名称经DNS翻译后,I-CSCF转发Regiter消息至S-CSCF。
由S-CSCF比对RES响应值与某RES期望响应值,两者匹配,则该用户通过网络鉴权。
接下来是为触发第三方注册而进行的流程,初始注册触发的二次注册流程中一定存在取用户数据流程,而重注册触发的二次注册流程可根据该用户数据在S-CSCF的预留情况,可选择性进行取用户数据流程,这有利于缩短时延和降低C某接口信令负荷,取用户数据通过服务器分配请求SAR(ServerAignmentRequet)和SAA服务器分配回应两个过程来完成,下文假设为存在取用户数据情况:
S-CSCF发送消息SAR(类型为注册)至HSS,由于相关用户签约和第三方认证数据等是空的,HSS响应S-CSCF的SAA消息,该消息包含了用户签约数据、
两套iFC(初始过滤准则,用于触发AS进行第三方注册以及后续业务AS逻辑顺序)、计费信息域名等。
S-CSCF原路返回或内部传递SIP---INVITE200OK消息至I-CSCF,传递至P-CSCF,最终到达UE,确认注册成功,包含头域叙述如下:
P-Aociated-URI头域中包含了两个IMS公用身份标识(IMPU),分别采用TelURI和SIPURI格式,其中SIPURI格式包含该用户归属省份信息,比如下述号码为浙江移动号码:
TelURI用于后续的语音呼叫,而SIPURI用于IMS网络路由。
Contact头域为注册成功用户的IMSI、IPV6地址和端口号、重注册时长、终端支持业务类型等,截图如下:
Service-Route头域包含有该用户归属的S-CSCF名称,由S-CSCF向I-CSCF发送,继而由I-CSCF传递给向P-CSCF,如下图所示注册成功消息中所示:
由P-CSCF保存Service-Route头域内容:
归属S-CSCF名称,这样UE成功注册之后的其它SIP消息(非注册类,例如呼叫INVITE)抵达P-CSCF后,在转往下一跳时,直接在Route字段放置该用户的S-CSCF名称,经DNS翻译后,可实现SIP消息无需再经过I-CSCF实体就可直达该用户的归属S-CSCF。
也就是说在用户IMS注册成功后,用户的非注册类的SIP消息,即可经Gm接口、Mw接口至归属网络的S-CSCF,由S-CSCF进行下一步逻辑处理。
Path头域包含S-CSCF已登记的IPV4的P-CSCF地址,经P-CSCF实体变换为IPV6的P-CSCF地址传递给UE,作为Gm接口的端地址。
Accept-Reource-Priority头域包含用户签约的优先级,比如wp.4。
可选项---Authentication-Info头域,携带下一次重注册的随机项nonce。
下表为注册前、中、后三个状态的各相关网元必须要记录的地址、域名、安全数据或用户数据:
五、第三方注册
在基本注册成功之后,归属S-CSCF代替用户发起第三方注册,第三方注册过程仅在IMS核心网出现,Uu口无此信息,REGISTER消息中的Contact头域包含该用户归属S-CSCF的地址,以保证应用服务器AS不会直接路由到用户终端UE,而是总会先与S-CSCF联络。
网元数据,主要涉及S-CSCF与HSS/SCC-AS/VoLTE-AS/IP-SM-GW交互,涉及SIP协议的ISC接口、Diameter协议的Sh接口。
不同AS的第三方注册消息构造有如下特征:
Requet-Line内容为具体第三方应用服务器的名称,比如SCCAS、VoLTEAS、IP-SM-GW;
Via头域除了分支不一样其余相同;
Call-ID头域都是相互独立的标识,也与之前的基本注册Call-ID不相关;
To、Contact、P-Charging-Vector、P-Acce-Network-Info、P-Viited-Network-ID头域内容均相同,To头域为用户的SIP格式的公有标识IMPU;
消息体(MeageBody)内容完全是一样的,均为二次注册内容,该消息体是由I-CSCF传递到S-CSCF的,包含内容有Requet-Line、MeageHeader、I-CSCFIP地址的Via头域、基本注册Call-ID头域、From/To头域、成功认证向量的Authorization头域、Contact头域、Path头域、P-Viited-Network-ID头域、P-Acce-Network-Info头域、P-Charging-Vector头域、ATCF/STN-SR内容的Feature-Cap头域等。
手机发起初始注册或重注册,S-CSCF回送401挑战消息,但手机UE未响应401挑战消息,稍后UE再次发起初始注册(可发生APN=IMS的PDN重新连接,重新分配IPV6地址),两次注册的Call-ID不同,但由于S-CSCF注册消息处理周期定时器(30)还在工作,认为同一个IMSI用户的第一次注册尚未完成,因此直接回应486BuyHere消息,原因值为'Toomanyregiterinparallel',拒绝了注册操作流程。
由此产生了两次初始注册失败,截图如下:
建议终端厂家出补丁来解决401认证挑战消息的兼容性问题。
建议核查S-CSCF下发的401认证挑战消息的兼容性问题。
建议S-CSCF缩短注册保护定时器时长或修改流程以信任新的注册消息。
500失败响应码为服务器内部错误,由S-CSCF实体产生,建议检查S-CSCF内部事件记录。
7.3步步高VIVO某6D手机初始注册失败
在对步步高VIVO某6D(TAC=86989502批次)的手机进行注册失败分析时,发现代码为486和500的占比较高:
代码486的产生类似三星S6手机过程:
也是因为手机不响应401认证挑战消息,直至超时,而后手机再次发起初始注册,但被S-CSCF拒绝,产生486BUSYHERE代码。
同时这款手机还有个问题:
每隔一段时间发起一次初始注册(无规律),而不是重注册,那么S-CSCF会判断为该用户存在故障,于是一方面予以注册成功,另一方面又是第三方注销,存在逻辑上的混乱,之后是手机注销。
而后手机再次发起初始注册,但对401认证挑战消息无响应,如此循环。
500响应码的注册失败为服务器内部错误,由P-CSCF实体产生,原因值为“AKAIP+Portconflict”,这是因为之前PGW分配的IPV6地址以及发布的两个P-CSCF地址所产生的手机端口号被某个P-CSCF拒绝所导致,更换另一个P-CSCF则通过。
建议终端厂家出补丁来解决401认证挑战消息的兼容性问题。
建议核查S-CSCF下发的401认证挑战消息的兼容性问题。
建议终端厂家出补丁来解决多次初始注册和注销的BUG问题。
建议终端厂家出补丁来解决UE源端口号算法问题,以便让P-CSCF所识别。
7.4金立GN9010手机初始注册失败
在对金立GN9010(TAC=86861202批次)的手机进行注册失败分析时,发现原因值为486和500的占比较高。
其中失败响应码486的产生过程和三星S6手机的一样:
也是手机发起初始注册,S-CSCF回送401挑战消息,但手机UE未响应401挑战,之后进行PDN连接性请求,重新分配得到IPV6地址,而后进行新的初始注册,两次注册的Call-ID不同,但前后两次时间差在S-CSCF的注册保护定时器作用的时长内,S-CSCF回送失败响应码486,具体原因为“TooManyRegiterinParallel”。
而500失败响应码的产生与步步高VIVO某6D的一样:
也是由P-CSCF实体产生,注册失败为服务器内部错误,原因值为“AKAIP+Portconflict”,这是因为之前PGW分配的IPV6地址以及发布的两个P-CSCF地址所产生的手机端口号被某个P-CSCF拒绝所导致,更换另一个P-CSCF则通过。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- VoLTE 注册 过程