郑圣 姚勇
中国联合网络通信有限公司江苏省分公司
联通和电信5G无线网络共建共享,双方前期都采用非独立组网NSA网络架构。5G NSA Option3x组网是通过升级EPC核心网设备并在LTE无线网络叠加部署NR(New Radio)gNB的方式,向5G SA网络架构平滑演进的组网解决方案。5G NR gNB的控制面锚定于4G LTE eNB,通过将用户面数据分流到gNB的方式,充分利用gNB的高带宽处理能力,为用户提供高速宽带无线业务。
由于5G NR的控制面是通过锚定于4G LTE接入EPC核心网,而联通和电信的核心网是各自独立的,因此会涉及到QOS策略一致性的问题。但是之前双方的QOS策略并不完全一致,如联通普通用户的QCI是6,VIP用户的QCI是8,而电信的普通用户QCI是9,VIP用户的QCI是6。
为了满足双方对等互利、用户感知一致的大原则,根据电信联通共建共享对接工作组的协商结果,双方将采用一致的QOS策略,详细的QOS策略规划如表1所示。
表1 电联统一后的QOS策略
江苏联通4G和5G普通用户、行业应用类用户的公众数据业务APN和行业应用APN基本都是QCI6,按要求将APN的QCI签约值统一修改为9。但是修改完成后,电信无线统计发现联通QCI6、QCI7的用户还有一定的比例,引起电信的质疑。
首先怀疑HSS签约问题或者修改签约后HSS和MME的数据同步问题。
我们通过信令监测系统统计出现QCI6和QCI7的用户,先检查其HSS中的签约数据,用户签约APN的QCI都已经改成9了。再检查MME中用户当前的承载上下文,QCI也是9,这说明QCI6、QCI7并非由于签约或者MME的数据同步问题导致。
统计并检查出现QCI=6或者7的用户消息流程,发现这种情况都是发生在用户在3G建立PDP上下文后再TAU到4G的场景,如图1所示。
图1 QCI 6、 QCI7是由3G QOS映射到4G的
在3G建立PDP上下文后,从3G返回4G的TAU的流程中,create session request消息中QOS是由3G的PDP上下文的QOS映射过来的,因此是3G的QOS导致了4G出现的QCI=6或者7的情况。3GPP协议定义的映射关系如表2所示。
表2 3G、4G的QOS映射关系
目前我们3G APN的QOS的 Traffic Class 都是签的interactive,而traffic Handling Priority比较多的是2和1,因此3G QOS是interactive&2的用户TAU到4G时映射成QCI7,而interactive&1的会映射成QCI6。
从3G返回4G的同时MME会紧接着去HSS位置更新,HSS返回用户4G签约的APN QCI=9,MME发现用户签约的QCI和当前的承载不一致,因此会发起承载修改流程,将QCI从6或者7修改成签约的9。
因此用户在QCI 6或者QCI 7的承载上时间很短,几乎不会产生流量。
用户在4G建立承载后RAU到3G时,网络会将4G的QOS映射成3G的QOS,当4G的QCI是9时,映射成3G的Traffic Class是background。
在3G时HSS也会插入用户签约数据,如果HSS签约的3G APN的Traffic Class是interactive,但 是SGSN不 会 将background更改成interactive,从而再TAU返回4G时也不会出现QCI6或者QCI7。
在3G UMTS的情况下,interacticve 类型和background类型适用的业务类型虽然有差别,但是如果QOS的其他参数不变时,只修改Traffic Class的话对用户的感知影响不大。如表3、表4所示。
表3 FTP业务在不同Traffic Class上的速率对比
表4 Streaming业务在不同Traffic Class上的速率对比
为了实现和电信的互信需求,根据QOS的映射关系,3G QOS的Traffic Class是background的映射成4G的QCI9,我们在HSS中将用户签约的3G APN的Traffic Class由interactive改为background,这样在3G建立PDP上下文后再TAU到4G,QCI直接转换成9,归避了出现QCI6或者QCI7的情况。
某地市HSS测试修改本市的用户3G APN的QOS的
Traffic Class为background后,在信令监测系统中查询出现QCI6或者QCI7的归属本市的用户数,已经由修改前的一天23万多用户降到零。