认证疑难问题分析报告
作者：互联网
目录
2.1.1 8.2.2.53/8.3.4.11 问题初步分析... 5
2.2.1 8.2.2.53/8.3.4.11 问题详细分析... 6
2.3.1 8.2.2.53/8.3.4.11 问题原因总结... 8
Table of Contents
实验室认证测试时，以下三个测试case项一直无法测试通过，case项如下：
3GPP TS 34.123-1 8.2.2.53
3GPP TS 34.123-1 8.3.1.47
3GPP TS 34.123-1 8.3.4.11
3GPP TS 34.123-1 8.2.2.53 测试步骤截图1如下图所示：
图1
3GPP TS 34.123-1 8.3.4.11 测试步骤截图如下图2所示：
3GPP TS 34.123-1 8.2.2.53与3GPP TS 34.123-1 8.3.4.11这两个case fail原因一样。8.2.2.53 fail 在step6，8.3.4.11 fail在step7，仪器判断CQI 发送间隔时Verdict fail，判定UE 发送的CQI间隔错误导致测试fail。
3GPP TS 34.123-1 8.3.1.47 测试步骤截图如下：
3GPP TS 34.123-1 8.3.1.47 fail在step6， UE没有收到仪器发送的CELL UPDATE CONFIRM。UE 重发CELL UPDATE后，仪器Verdict fail。
- 问题分析
- 8.2.2.53/8.3.4.11 问题初步分析
这两个问题都是因为仪器判定CQI 发送间隔错误导致测试fail。同样需要分两步确定是UE问题还是仪器问题。
- 用对比机同样的环境测试，排除仪器误判
- 分析UE QXDM log，找出UE的CQI发送间隔看是否是UE问题。
- 8.3.1.47 问题初步分析
8.3.1.47 问题从仪器log可以很明显看到UE收到仪器发送的CELL UPDATE CONFIRM，但是UE一直重发cell update，导致仪器判定fail。
仪器log截图如下：
同样这个问题也要从两个方面入手：
- 检查仪器下发的cell update confirm是否正确
- 检查UE 是否正确处理仪器下发的cell update confirm
- 8.2.2.53/8.3.4.11 问题详细分析
与仪器厂商联调时得知，仪器要求UE必须每隔20 个subframe 发送一次CQI， 但是仪器检测到，UE 不是以这个频率发送CQI，导致仪器判定Fail。
仔细检查测试协议发现，协议要求当UE进入dtx-Cycle2 以后才开始统计CQI发送，而实验室仪器在UE进入dtx-Cycle2之前就开始统计CQI，导致测试fail。
问题Log分析如下：
仪器在UE 进入dtx-Cycle2 之前就检查UE的CFN 148 subframe 1 和subframe 3 的CQI 发送间隔导致测试fail。
相关log如下：
//SS 配置UE DTX UE 进入dtx-Cycle2时间点22:48:47. 351：
22:48:44.885 [03] 0x412F WCDMA Signaling Messages -- DL_DCCH Radio Bearer Setup
22:48:47.346 [F9] 0x412F WCDMA Signaling Messages -- UL_DCCH Radio Bearer Setup Complete
22:48:47.351 [F9] 0x422C CPC DTX State Machine
// CFN 148 subframe 1 和subframe 3 发送CQI 的时间点22:48:46.189
22:48:46.189 [85] 0x421C UL HS DPCCH Information Log Packet Edition 2
| 740| 0| R| 30| | | | D|
| 741| 0| R| | | | | D|
| 742| 0| R| 30| | | | D|
| 743| 0| R| | | | | D|
| 744| 0| R| 30| | | | D|
| 745| 0| R| | | | | D|
// 201/221/241/281 可以看到每隔20 个subframe 发送一次CQI。
22:48:53.762 [25] 0x421C UL HS DPCCH Information Log Packet Edition 2
Version = 3
Num Samples = 100
Secondary Carriers = 0
HS-DPCCH Slot Format = 0
-------------------------------------------------------------------------------------------------------
|Sub | |CQI |Cqi |Cqi |Cqi |Cqi |AckNackDtx|AckNackDtx|AckNackDtx|AckNackDtx|
|Fr# |hsCqiReport|Type|Carrier0|Carrier1|Carrier2|Carrier3|Carrier0 |Carrier1 |Carrier2 |Carrier3 |
--------------------------------------------------------
201| 0| R| 30|
221| 0| R| 30|
241| 0| R| 30| | | | D| |
261| 0| R| 30| |
281| 0| R| 30|
- 8.3.1.47 问题详细分析
8.3.1.47 我们详细分析了UE QXDM log，根据测试协议要求，step4， SS 给UE 发送的cell update confirm，分析物理层log，可以看到UE收到3个pass PDU，UE可以正确解析这个贞，并传给MAC层。根据测试法规，因为这个cell update confirm 中UE-ID unmatched ，所以UE最终会丢弃这条信令。
在step5 UE重发cell update。
step6，SS重发cell update confirm, 但是分析step6 SS发送的cell update confirm ，从物理层log发现，UE 只收到2个pass PDU，所以UE直接在物理层就丢弃了这个贞，导致UE没有收到SS发送的Cell update confirm。
Log如下：
Step4 中收到的cell update confirm log packet， 3个pass PDU。
22:57:44.875 [E2] 0x4222 HS Decode Status Log Packet with Data Edition 3
Carrier 0:
|----|----|----|-----|--|---|---|---|-----|----|
| # |SCCH|DSCH|HS TB|RV|New|Num|Cod| |HARQ|
| |A/V |Stat| size| | Tx|Cod|Off| Mod | Id|
|1151|1 1 |PASS| 272| 0| 1| 1| 1| QPSK| 2|
|1152|1 0 | DTX| | | | | | | |
|1153|1 1 | DUP| 272| 0| 0| 1| 1| QPSK| 2|
22:57:44.925 [E7] 0x4222 HS Decode Status Log Packet with Data Edition 3
Carrier 0:
|----|----|----|-----|--|---|---|---|-----|----|
| # |SCCH|DSCH|HS TB|RV|New|Num|Cod| |HARQ|
| |A/V |Stat| size| | Tx|Cod|Off| Mod | Id|
|----|----|----|-----|--|---|---|---|-----|----|
|1156|1 1 |PASS| 272| 0| 1| 1| 1| QPSK| 3|
|1161|1 1 |PASS| 272| 0| 1| 1| 1| QPSK| 4|
Step6 中收到的cell update confirm log packet， 只有2个pass PDU。
22:57:52.875 [02] 0x4222 HS Decode Status Log Packet with Data Edition 3
Carrier 0:
|----|----|----|-----|--|---|---|---|-----|----|
| # |SCCH|DSCH|HS TB|RV|New|Num|Cod| |HARQ|
| |A/V |Stat| size| | Tx|Cod|Off| Mod | Id|
|----|----|----|-----|--|---|---|---|-----|----|
| 11|1 1 |PASS| 272| 0| 1| 1| 1| QPSK| 0|
| 15|1 1 | DUP| 272| 0| 0| 1| 1| QPSK| 0|
| 16|1 1 |PASS| 272| 0| 1| 1| 1| QPSK| 1|
这个问题的根本原因是因为仪器发送的cell update confirm贞错误，导致UE在物理层直接丢弃。导致UE重发cell update。
- 8.2.2.53/8.3.4.11 问题原因总结
8.2.2.53/8.3.4.11 这两个问题是因为仪器在UE进入dtx-Cycle2 之前，就去统计CQI发送间隔，导致仪器Verdict Fail。
- 8.3.1.47问题原因总结
8.3.1.47 问题原因时因为仪器第二次发送的cell update confirm PDU 格式错误，导致UE 在
物理层丢弃了这贞数据，导致UE认为仪器没有回应cell update confirm，从而重发cell update导致仪器Verdict Fail。
找到问题原因后，跟实验室沟通，更换Anite仪器测试后，这三个case都pass。
以前我们总会碰到一些case 在R&S 上无法测试pass，但是更换Anite后又可以pass。以前因为项目进度紧张，我们也没有仔细分析原因。但是后来更换Anite测试实验室需要付费给仪器厂商后，实验室不再愿意更换仪器测试。这时fail case就会影响我们的认证进度，进而影响整个项目进度。找到问题根本原因以后，跟实验室沟通起来就方便多了，同时也扩宽了我们自己的知识面，对以后分析类似问题非常有帮助，所以分析问题时，不要放过任何一个有疑问的点，这个非常重要。
3GPP TS 34.123-1
标签：...,8.3,报告,疑难问题,update,认证,cell,仪器,UE 来源： https://blog.csdn.net/h721510279812/article/details/89599549