【资料名称】:南京语音单通分析报告
【资料作者】:Jupiter198343
【资料日期】:2012.8.21
【资料语言】:中文
【资料格式】:DOC
【资料目录和简介】:
大唐移动
2011年7月30日
目录
1.问题现象描述3
2.问题复现场景3
3.问题定位结论3
4.问题解决方案3
5.问题分析过程3
6.附录7
一、问题现象描述
近期,接到南京市公司领导普遍反映,在省公司59号楼、81号楼等地点出现语音单通情况。接到投诉后项目组立刻安排了对投诉区域的测试和后台跟踪分析,当时未复现出语音单通的问题。
二、问题复现场景
我司安排测试人员使用和移动老总同型号的终端三星I9008,在天顺大厦站点复现问题。测试人员在天顺大厦站点小区下,使用两部三星I9008在小区下进行大量测试,测试时主叫占用T网,被叫占用G网,主叫做PS业务的同时做CS语音业务,语音接通时,PS业务保持在线。通过反复拨打,测试过程中出现3次单通情况,均为被叫无法听到主叫声音,即G网用户无法听到T网用户的声音。
三、问题定位结论
通过抓取RNC和基站的LOG分析,最终定位问题原因为:某些终端在组合业务下,偶尔会上发一帧不符合协议规定格式的语音数据,RNC对这类错误格式的数据容错机制考虑不完善,导致单通。目前RNC的处理是直接对这一帧错误格式及其后面的所有数据,均做丢弃处理,导致主叫上行数据全部被丢弃。此问题只影响语音业务,对PS无影响。
四、问题解决方案
RNC修改容错机制,当收到非协议规定格式的语音数据时,只对这一帧数据进行丢弃处理,后面正常的数据均正常上发给核心网,保证业务正常。
五、问题分析过程
由于被叫无法听到主叫,怀疑主叫上行没有正常发送语音数据,导致被叫无法听到声音。从QOS跟踪中上,语音单通时,主叫上行TB块很少甚至为0。
具体分析过程如下:
1、UEID =168052的用户2011-7-26 17:09:44PS业务接入,2011-7-26 17:17:12CS业务接入,2011-7-26 17:19:04看到该用户的CS业务上行的TB个数为0,导致对端被叫用户出现单通(见图1)。
图1 主叫上行QOS跟踪数据
2、从RNC业务面跟踪看,主叫用户上行数据中有大量TFI=010的非法数据(见图2)。由于协议中规定正确的语音数据TFI格式为100和211两种,RNC收到010这种异常格式的数据后做丢弃处理(丢弃掉010后面所有的语音数据),导致主叫终端的语音数据被丢弃,被叫无法听到主叫。RNC再次收到TFI格式为010的语音数据后,将此非法语音数据丢弃后,后面正确格式的数据会恢复上传,此时单通恢复。
NO.64221 TpssSn 0 UeId(169541) OamsTimer:2011:7:26:16:20:34 TimeDis:0 RfnLoopNum:0 Time(ms):040099 Rfn:320796 TpssId:3b7
+---------+--------------------------------------------------+----------+--------------------------------------------------------+
BITMASK | IE名FP_DCH_UP_DATA| 注释(TrueLen = 22,ReportLen = 22)
+---------+--------------------------------------------------+----------+--------------------------------------------------------+
NO.64221TpssSn 0 UeId(169541) OamsTimer:2011:7:26:16:20:34 TimeDis:0 RfnLoopNum:0 Time(ms):040099Rfn:320796 TpssId:3b7
+---------+--------------------------------------------------+----------+--------------------------------------------------------+
BITMASK|IE名 FP_DCH_UP_DATA|注释(TrueLen = 22,ReportLen = 22)
+---------+--------------------------------------------------+----------+--------------------------------------------------------+
|-------- | FP_DATA_FRAME| |
|-------- | FP:Header| |
|-------- | FP: Frame CRC|44|
|-------- | FP:Frame Type | |Data
|-------- | FP:Connection Frame Number|158 |
|-------- | FP:Transport Format Index|0|
|-------- | FP:Transport Format Index|1|
|-------- | FP:Transport Format Index|0|
|-------- | Transport Block Set| |
|-------- | FP:DCH Index|0|
|-------- | FP:Transport Block |0|
|-------- | MAC: Target Channel Type| |DTCH (Dedicated Traffic Channel)
|-------- | MAC: RLC Mode| |Transparent Mode
|-------- | RLC: Data Segment|7b 28 db|
|-------- | FP:DCH Index|1|
|-------- | FP:Transport Block |0|
|-------- | MAC: Target Channel Type| |DTCH (Dedicated Traffic Channel)
|-------- | MAC: RLC Mode| |Transparent Mode
|-------- | RLC: Data Segment|68 ec 0 |
|-------- | FP:DCH Index|2|
|-------- | FP:Transport Block |0|
|-------- | MAC: Target Channel Type| |DTCH (Dedicated Traffic Channel)
|-------- | MAC: RLC Mode| |Transparent Mode
|-------- | RLC: Data Segment|11 9f 4b|
|-------- | FP:Trailer| |
|-------- | FP:Quality Estimate|0 |
|-------- | FP:CRC Indicator (Transport Block) ||CStCrcOk
|-------- | FP:Payload CRC|7666|CStCrcOk
+----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|HEX |0 |1 |2 |3 |4 |5 |6 |7 |8 |9 |A |B |C |D |E |F |
+----+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|0|00 9e 00 01 00 7b 28 db 28 db 7f ae 69 44 76 e2
|16|68 ec 00 00 76 66
NO.64222TpssSn 0 UeId(169541) OamsTimer:2011:7:26:16:20:34 TimeDis:0 RfnLoopNum:0 Time(ms):040099Rfn:320796 TpssId:357
+---------+--------------------------------------------------+----------+--------------------------------------------------------+
BITMASK|IE名 FP_DCH_UP_DATA|注释(TrueL
3、基站跟踪ATP消息看,TFI为010这种非协议规定的错误语音数据为终端发送,基站不存在解析错误的问题,分析如下:
trch_id=7/8/9为主叫用户的3个CS语音12.2K的传输信道,此时基站收到的对应传输信道的TFI为010,基站物理层crci[]={0 0 0 0 0 0 }表示CC模块译码正确,说明此时TFI为010格式的数据由终端上发。
[Resource:0:3:12:28][MessageNumber:23343][Time:2011-07-26 17:21:01]
SFN: 7820TS: 8TraceUsrId: 0
SourceID: 0:3:12:28DestID: 0:3:10:7OPCODE: O_CCFP_DCH_DATALength:204Bytes
{
.sub_sfn=7820
.freq_index=2
.msg_number=5
.trch_id=7
.freq_offset=570
.tbs_length=0
.freq_offset_valid_flag=0
.frame_type=64
.cfn=68
.tfi=0
.ber=0
.crci_length=0
.crci[]={0 0 0 0 0 0 }
变长部分 TBS[0] ={}
.trch_id=8
.freq_offset=570
.tbs_length=13
.freq_offset_valid_flag=0
.frame_type=64
.cfn=68
.tfi=1
.ber=184
.crci_length=1
.crci[]={0 0 0 0 0 0 }
变长部分 TBS[13] ={44 34 95 2 84 36 46 23 189 155 75 148 210 }
.trch_id=9
.freq_offset=570
.tbs_length=0
.freq_offset_valid_flag=0
.frame_type=64
.cfn=68
.tfi=0
.ber=0
.crci_length=0
.crci[]={0 0 0 0 0 0 }
变长部分 TBS[0] ={}
.trch_id=11
.freq_offset=570
.tbs_length=0
.freq_offset_valid_flag=0
.frame_type=64
.cfn=68
.tfi=0
.ber=0
.crci_length=0
.crci[]={0 0 0 0 0 0 }
变长部分 TBS[0] ={}
.trch_id=10
.freq_offset=570
.tbs_length=84
.freq_offset_valid_flag=0
.frame_type=64
.cfn=68
.tfi=2
.ber=203
.crci_length=2
.crci[]={192 0 0 0 0 0 }
变长部分 TBS[84] ={255 227 214 10 190 166 54 58 217 40 23 122 215 148 241 236 79 221 184 242 148 71 20 115 42 175 219 55 101 245 43 146 131 180 214 158 222 158 53 231 67 86 245 219 125 156 168 12 217 51 233 105 98 248 141 209 150 222 0 194 129 223 189 107 106 128 218 63 2 178 243 56 33 243 155 225 204 205 56 40 61 227 243 10 }
}
六、附录
以下为目前协议34.108中支持的语音业务格式,见图2、图3。
6.10.2.4.1.4 Conversational / speech / UL:12.2 DL:12.2 kbps / CS RAB + UL:3.4 DL:3.4 kbps SRBs for DCCH
6.10.2.4.1.4.1 Uplink
6.10.2.4.1.4.1.1 Transport channel parameters
6.10.2.4.1.4.1.1.1Transport channel parameters for Conversational / speech / UL:12.2 kbps / CS RAB
Higher layerRAB/Signalling RBRAB subflow #1RAB subflow #2RAB subflow #3
RLCLogical channel typeDTCH
RLC modeTMTMTM
Payload sizes, bit39, 81
(alt. 0, 39, 81)10360
Max data rate, bps12 200
TrD PDU header, bit0
MACMAC header, bit0
MAC multiplexingN/A
Layer 1TrCH typeDCHDCHDCH
TB sizes, bit39, 81
(alt. 0, 39, 81)10360
TFSTF0, bits0x81(alt. 1x0) (note)0x1030x60
TF1, bits1x391x1031x60
TF2, bits1x81N/AN/A
TTI, ms202020
Coding typeCC 1/3CC 1/3CC 1/2
CRC, bit12N/AN/A
Max number of bits/TTI after channel coding303333136
Uplink: Max number of bits/radio frame before rate matching15216768
RM attribute180 to 220170 to 210215 to 256
NOTE: In case of using this alternative, CRC parity bits are to be attached to RAB subflow#1 any time since number of TrBlks are 1 even if there is no data on RAB subflow#1 (see clause 4.2.1.1 in 3GPP TS 25.212 [14]).
图2 CS12.2K的 传输通道参数配置
6.10.2.4.1.4.1.1.2Transport channel parameters for UL:3.4 kbps SRBs for DCCH
See clause 6.10.2.4.1.2.1.1.
6.10.2.4.1.4.1.1.3TFCS
TFCS size6
TFCS(RAB subflow#1, RAB subflow#2, RAB subflow#3,DCCH)=
(TF0, TF0, TF0, TF0), (TF1, TF0, TF0, TF0), (TF2, TF1, TF1, TF0),
(TF0, TF0, TF0, TF1), (TF1, TF0, TF0, TF1), (TF2, TF1, TF1, TF1)
图3 CS12.2K+3.4K的的 传输格式组合
扫码关注5G通信官方公众号,免费领取以下5G精品资料
1、回复“LTBPS”免费领取《《中国联通5G终端白皮书》》
2、回复“ZGDX”免费领取《中国电信5G NTN技术白皮书》
3、回复“TXSB”免费领取《通信设备安装工程施工工艺图解》
4、回复“YDSL”免费领取《中国移动算力并网白皮书》
5、回复“5GX3”免费领取《 R16 23501-g60 5G的系统架构1》
6、回复“iot6”免费领取《【8月30号登载】物联网创新技术与产业应用蓝皮书——物联网感知技术及系统应用》
7、回复“6G31”免费领取《基于云网融合的6G关键技术白皮书》
8、回复“IM6G”免费领取《6G典型场景和关键能力白皮书》
共获得 1 次点评 我要点评
- mao_mao 专家指数 +1 , 威望 +15 个
· 谢谢分享!
详细..
发表与:2012-8-21 16:16:04
|