对接TFO功能测试分析报告

文档名称文档密级2020-1-2华为机密，未经许可不得扩散第1页,共7页德国杜塞NSNR15&HUAWEIGBSS13.0对接TFO功能测试分析总结摘要德国杜塞与NSN进行GIOT测试，涉及TFO功能的对接，我司采用GBSS13.0和NSNR15的核心网平台对接测试TFO功能，本文主要针对测试过程中的问题行总结。BSC版本信息：V900R013C00SPC200BTS版本信息：BTS3900V100R009C00SPC055BTS3012V200R009C00爱立信版本信息：R15组网场景说明：测试过程中为了实现和NSN的核心网实现TFO功能对接，设计组网场景如下：BSC1和核心网以TDM方式连接，BSC2与核心网之间以IP方式连接，这样在两个BSC上使能TFO之后（核心网也需要使能TFO），呼叫时在BSC1和核心网之间协商建立TFO的。文档名称文档密级2020-1-2华为机密，未经许可不得扩散第2页,共7页1对接HAMRTFO功能失败问题现象对接HAMRTFO，查询出TFO状态为时断时续。根因分析根据协议28062中附录H对配置帧属性段的定义如下：TableH.3.2-1DesignoftheCodecTypeConfigurationfortheexampleFRAMRNameTS26.103TS28.062CommentSingle_Codec_Indicator8bits0bitsomittedinTS28.062Length_Indicator8bits3bits1.0.0(4octetsfollowingaftertheOrganisation_Identifier_Indicator)Extension_Indicator-1bits0nofurtherExtensionnecessaryCompatibility_Information_Indicator-1bit0Compatibility_InformationisomittedOrganisation_Identifier_Indicator1bit1bit0Organisation_IdentifierisomittedCompatibility_Information8bits0bitsomitted,whennotindicatedOrganisation_Identifier8bits0bitsomitted,whennotindicatedCodec_Type_Identifier8bits8bitsFR_AMR_CoIDACS8bits8bits0.1.0.0.1.1.0.1(e.g.)SCS8bits8bits1.1.1.1.1.1.1.1(canbeomitted)OM,MACS8bits8bits0.0.0.0.0.0.0.0(canbeomitted)根据协议描述可以看到，如果“Length_Indicator”的值为4（100）则表示在字段“Organisation_Identifier”后面有四个字节，根据NSN发过来的配置帧，该字段长度为四，但是最后一个字段为全零。根据我们产品的实现方式是如果长度为四则认为“Organisation_Identifier”后面有四个字节全部有效，因此在TFO建立成功之后，重新冲配置帧中取出MACS个数为零，根据文档名称文档密级2020-1-2华为机密，未经许可不得扩散第3页,共7页判决算法此时不能建立TFO，因此导致TFO在建立之后断开，断开重新协商的结果还是可以建立，又在建立成功之后收到配置帧导致TFO再次断开，并周而复始重复上述状态。根据这一现象重新分析协议，从表中可以看出字段“SCS”和“OM,MACS”两个字段协议认为可以省略，推测NSN的实现应该是虽然长度是4，但是对后两个字段根据协议上的说明将其省略了，而我们的理解则是如果省略则应该将长度对应更改，显然双方对这段协议的理解是有偏差的。解决方案在解析配置帧时，对于MACS的值通过ACS计算出来，再参与判决。2对接HRTFO功能失败问题现象对接HRTFO功能失败。根因分析从信令跟踪可以看到在TFO协商成功之后对端主动将TFO断开，根据之前出现的和NSN对接EFRTFO功能失败现象类似，因此怀疑在发给NSN的配置帧上出错，对比收到的配置帧和发出的配置帧发现在配置帧中的Message_No填写的和对端发过来的不一致（代码bug导致），根据协议描述“Message_Noisusedtomarkaconfigurationrequestmessageatsendersideinordertobindtheacknowledgementfromthereceiverside”因此在发送Con_Ack的时候，其中的Message_No应该取收到的Con_Req中的Message_No的值。解决方法修正bug，将Con_Ack中的Message_No的值取收到的Con_Req中的Message_No的值。3对接WBAMRTFO功能失败-1问题现象对接WBAMRTFO功能失败。解决方案文档名称文档密级2020-1-2华为机密，未经许可不得扩散第4页,共7页从带内信令跟踪上看到在呼叫两端使用WBAMR的时候对端无法搜到我们发的WBAMR的帧，我们也无法搜到对端发送的WBAMR的帧，将我们发出的WBAMRTFO帧和协议28062中对于WBAMRTFO帧格式定义发现我们发出WBAMRTFO帧的FrameType不符。对比协议48060和28062发现两个协议中对WBAMR的TRAU帧中的FrameType和WAMR_TFO帧的FrameType定义不同，普通WBAMR的TRAU帧对帧格式定义如下（参考协议48060的5.5.1.3.1章节）：而WAMR_TFO帧的FrameType定义如下（参考协议28062的Table5.2.2.3-3:）Table5.2.2.3-3:CodingoftheFrameTypeforAMR_WB_TFO_16kFramesandAMR_WB_TFO_32kFramesControlBitsDescriptionCommentC1-C4(0.0.0.1)(0.0.1.1)(0.1.0.0)(0.1.0.1)(0.1.1.0)1.0.0.11.0.1.0(1.0.1.1)1.1.0.00.0.1.0(1.1.0.1)Frame_Type/CodecType(GSM_FR)(FR_AMR)(HR_AMR)(UMTS_AMR)(UMTS_AMR_2)FR_AMR-WBUMTS_AMR-WB(OHR_AMR)OFR_AMR-WBOHR_AMR-WB(GSM_EFR)ThecodingisdifferentfromthecodinginTFOMessages.ItisalsonotidenticaltothecodingonAbis/Ater.TheTRAUshalltranslatethecodingbetweenTRAUandTFOFrames.Note:CodecTypesin(brackets)arenotsupportedbythisTFOFrameformat.Theyarelistedtoshowtheircodingforconvenience.Note:BydefinitionFR_AMR-WBandOHR_AMR-WBdoonlyusetheAMR_WB_TFO_16kFrame,becausetheyneveruseaCodecModehigherthan12.65kbit/s.UMTS_AMR-WBandOFR_AMR-WBusetheAMR_WB_TFO_32kFramewhenatleastoneCodecModeisabove12.65kbit/s.我们代码的实现是WAMR_TFO帧的FrameType使用的是和普通的WAMR的TRAU帧中的FrameType相同，这样导致我们发出去的WAMRTFO帧非法，收到对端发来的WBAMRTFO帧后也校验非法，导致判决结果为没有搜到对端的TFO帧，且对端也无法搜到我们发出去的TFO帧。解决方案文档名称文档密级2020-1-2华为机密，未经许可不得扩散第5页,共7页修正bug，更正上行在A口发送的WBAMRTFO帧的FrameType符合协议28062定义。同时在下行发送TRAU帧给BTS的时候更正WBAMRTRAU帧的FrameType符合协议48060。4对接WBAMRTFO功能失败-2问题现象BSC2上的小区打开上行DTX的时候对接WBAMRTFO功能失败。根因分析问题3解决之后，在BSC2上的小区上行DTX关闭的时候TFO对接成功，打开的时候TFO对接仍然失败，失败的原因是本端无法搜到对端发送的TFO帧。分析BSC2上MS的录音文件发现，在该呼叫上行发出的SID帧速率填写有误。8071025A4A1300C0351C002CF4E5C77F6CB500000000000000000000000000000000000000000000000000000000000000000000分析D35~D39比特的值（对应0x50中的01010000）非法，参考协议《G722-2NEE_FIN_Framestructure.doc》中对SID静音帧格式定义如下：文档名称文档密级2020-1-2华为机密，未经许可不得扩散第6页,共7页TableE.5/G.722.2–MappingofanAMR-WBSIDframeintothegenericAMR-WBframe,AMR-WBIF1Example:AMR-WBSID_Update,goodframe,ModeIndication=3,ModeRequest=2.MSBMappingofbitsAMR-WBSIDLSBOctetbit8bit7bit6bit5bit4bit3bit2bit11FrameType(=9)FQIspare100010002ModeIndicationModeRequest(=2)MSB…LSBundefined00103CodecCRCCRC(7)CRC(6)CRC(5)CRC(4)CRC(3)CRC(2)CRC(1)CRC(0)4AMR-WBCoreFrame(octet1)d(0)=s(1)d(1)=s(2)d(2)d(3)d(4)d(5)d(6)d(7)5..7AMR-WBCoreFrame(octets2to4)d(8)…………………8AMR-WBCoreFrame(octet5)STIModeIndication(=3)MSB…LSBd(32)d(33)d(34)=s(35)10011theModeIndicationbitsmi(i)={mi(0),mi(1),mi(2),mi(3)}={LSB:::MSB}.forj=0to34;d(j):=s(j+1);d(35):=STI;forj=36to39;d(j):=smi(39j).WAMR的SID帧的速率在D比特的最后四个比特填写，顺序是M比特位高位，L比特位低位，而在代码实现的时候将L比特放在高位，M比特放在低位，导致在静音帧的时候速率错误，而现场的组网场景为呼叫在两个BSC下，一端为ＡTDM，另一端为AIP，因此如果AIP下文档名称文档密级2020-1-2华为机密，未经许可不得扩散第7页,共7页小区上行DTX打开，则在静音帧的时候速率错误，这样发到核心网的帧速率是有问题的，导致此种场景下和NSN对接WBAMRTFO功能失败。解决方案纠正之前对SID帧速率的反顺序填写方式，按照协议中定义的MSB比特在高位LSB比特在低位的方式实现。5WBAMR呼叫杂音问题现象两部索爱C905，一部在WBAMR下，另一部在3G下；打通电话，不说话的时候，会听到2G下的这部C905里传出明显的吱吱声。根因分析分析2G下MS的录音文件发现下行输出的TRAU帧中很多Nodata帧的速率错误根据分析原因同问题4，由于SID帧速率错误导