PTCRB/GCF 认证测试问题总结

目录

1      PTCRB/GCF 简介... 3

1.1     名词解释... 3

1.2     PTCRB 介绍... 3

1.3     GCF 介绍... 3

1.4     PTCRB/GCF测试分类... 4

2      PTCRB/GCF 测试内容... 4

2.1     一致性测试(Conformance Testing)... 4

2.2     外场测试 (Field Trail)... 4

2.3     应用测试 (Application Enabler)... 4

3      一致性测试协议分类... 5

3.1     RF一致性测试协议标准... 5

3.2     协议一致性测试协议标准... 5

3.3     SIM卡一致性测试协议标准... 5

4      PTCRB/GCF 问题分析定位... 6

4.1     认证测试问题分类... 6

4.2     认证问题基本分析方法... 6

5      仪器log分析... 7

5.1     认证测试仪器介绍... 7

5.2     R&S仪器log分析方法... 7

5.3     Anite 仪器log分析方法... 10

5.4     安立仪器log分析方法... 11

5.5     IT3 platform 仪器log分析方法... 12

6      案例分析举例... 13

6.1     Unexpected Nas PDU导致AGPS测试fail问题... 13

6.2     Sim卡一致性测试Terminal profile问题... 14

6.3     需要更换Anite测试问题... 15

7      总结... 18

8      参考文档... 18

 

 

 

 

 

 

 

 

 

  1. PTCRB/GCF 简介
    1. 名词解释

PTCRB:PCS Type Certification Review Board

GCF:Global Certification Forum

PICS:Protocol Implementation Conformance Statement

    1. PTCRB 介绍

PTCRB (PCS Type Certification Review Board) 是指个人通信服务型号认证评估委员会,由北美移动运营商于1997年成立。目前的运营商已经不仅限于北美,而是涵括全球范围内的移动运营商成员。其目的是为包括Cellular GERAN(GSM), UTRAN (UMTS)以及E-UTRAN (LTE)在内的终端产品和模板提供型号认证。

PTCRB认证是第三方认证机构执行的准强制型号认证,所有投放北美市场的PCS终端设备都要经过PTCRB认证,并依据报告申请IMEI。这里用的是准强制性,强制性应该是政府监管部门发布的要求,但PTCRB不是政府性的,是论坛形式的,但是非常具有权威性,其原因在于进入北美的经销商必须按照这个要求去测试厂家提供的产品,因此叫做准强制性。PTCRB也是有运营商和一些大的手机厂商组成,还包括一些认可实验室。

 

    1. GCF 介绍

Global Certification Forum, 全球认证论坛,GCF是由运营商和终端制造商共同成立的一个组织,目的是通过独立的认证过程来确保终端的全球互操作。它包含了主要的GSM(或未来的UMTS)网络运营商和世界上主流的终端制造商,并邀请测试仪器仪表开发商参加GCF的活动。

GCF作用:厂商的目的是迅速获得进入市场的新模式,运营商的目的是提供有吸引力和可靠的业务。

GCF如何满足前面的目标:

定义了每个终端所必须接受的测试,保证了终端的可靠、一致的行为。确保任何接受过GCF认证的终端都通过了这些测试。保证在将来能引入更多更复杂的技术.

GCF 认证基于自愿的原则,终端厂商基于GCF的认证标准(Certification Criteria)来声明其产品是否符合或超出认证标准的要求,GCF标准虽然不是强制性要求,但目前世界大部分的国家和地区都会要求终端生产厂商完成 GCF标准的测试,或者参考GCF标准。在欧洲及北美市场,终端产品的贩卖都是和网络运营商(Operator)相结合的,而一般网络运营商都会要求终端生产厂商对手机完成GCF的测试。与美国不同,在欧洲,网络运营商一般只要求生产厂商取得完整GCF测试报告即可,个别严格的地区需要提供GCF认证证书。

GCF与PTCRB测试大类一样也包括RF,Protocol,SIM,Audio等部分的测试。

 

    1. PTCRB/GCF测试分类

1、RF部分的测试;

2、Protocol部分的测试;

3、SIM部分的测试;

4、Audio部分的测试;

 

  1. PTCRB/GCF 测试内容
    1. 一致性测试(Conformance Testing)

实验室的一致性测试系统根据3GPP标准的要求,对该终端进行测试,来判断测试反映出的结果是否符合标准要求。按照测试对象与要求的不同,可以分为:

  1. 射频(RF)一致性测试。
  2. 无线资源管理RRM一致性测试。
  3. 协议一致性测试、应用一致性测试。
  4. USIM/USAT一致性测试等。
    1. 外场测试 (Field Trail)

GCF认证不可缺少的一个重要部分,它的实施是确保终端设备能够在实际网络环境下安全使用,它可以从最终用户的角度来验证网络间互通以及一些新的网络业务的性能。

    1. 应用测试 (Application Enabler)

 

GCF认证中的应用测试包括有彩信服务MMS、视频通话Video Telephony等方面的测试。

 

 

 

 

 

  1. 一致性测试协议分类
    1. RF一致性测试协议标准

RF 一致性测试协议标准如下:

GSM:

1、3GPP TS 51.010-1 GSM RF

 

UMTS:

2、3GPP TS 34.121-1 UMTS RF

 

LTE:

3、3GPP TS 36.521-1 LTE RF

4、3GPP TS 37.571-1 LTE A-GNSS RF

    1. 协议一致性测试协议标准

协议一致性标准如下:

GSM:

1、3GPP TS 51.010-1 GSM Protocol

 

WCDMA:

3、3GPP TS 34.123-1 UMTS Protocol

4、3GPP TS 34.124 UMTS RSE

 

LTE:

5、3GPP TS 36.523-1 LTE Protocol

6、3GPP TS 36.124 LTE RES

7、3GPP TS 36.521-3 LTE RRM

8、3GPP TS 37.571-2 LTE A-GNSS Protocol

9、3GPP TS 34.229-1 IMS

 

    1. SIM卡一致性测试协议标准

Sim卡一致性测试协议标准如下:

GSM:

1、3GPP TS 51.010-4 GSM STK

 

 

UMTS:

1、3GPP TS 31.121  UMTS USIM

2、3GPP TS 31.124  UMTS USAT

3、ETSI TS 102 230  UICC

 

LTE:

1、3GPP TS 31.124  LTE LSAT

2、3GPP TS 31.121  LSIM

  1. PTCRB/GCF 问题分析定位
    1. 认证测试问题分类

PTCRB/GCF 测试,实验室报测试fail的问题基本可以分成如下几类:

  1. UE 上报能力信息与PICS 申明不符问题。
  2. Sim卡一致性测试问题,主要是STK问题。
  3. 2G/3G/4G 网络接入问题,例如GSM/WCDMA/LTE随机接入,plmn手动/自动选网。

PDP激活去激活,移动性管理中的网络测量,切换,重选等。

  1. 应用类问题,例如sms、mms、AGPS、call、SS(补充业务)等等。

 

 

    1. 认证问题基本分析方法

我们组主要处理协议测试fail问题。实验室会将测试fail的章节详细列出来,并提供测试fail的UE log和对应的SS仪器log。

 

处理GCF/PTCRB 问题的一般步骤如下:

  1. 找到fail 问题的协议章节,根据协议描述,检查case的测试条件,测试步骤。
  2. 分析仪器log,找到仪器verdict fail的报错点。不同的测试仪器,log分析方法也不同,后面会举例介绍。
  3. 分析UE log,确定UE的行为是否正常。

4、分析对比机log。很多测试case,从仪器log或者UE log中无法找到明显的错误原因时,需要使用对比机log对比分析。通过对比机测试也可以更加准确判断SS仪器问题还是UE问题导致的的测试fail。

 

 

 

 

  1. 仪器log分析

仪器log分析在认证测试中非常重要,如果能很快从仪器log中找到仪器verdict fail点,则对问题的快速准确定位非常重要。所以掌握仪器log分析方法是认证问题分析的基本能力。

 

RF/protocol/sim/audio,不同的测试部分,测试仪器也不同,不同的实验室测试仪器也可能不一样。在认证问题分析过程中需要跟实验室多沟通,多总结,多积累才能逐步提升问题分析能力。下面介绍一下基本的测试仪器,对测试仪器有个大致了解。

    1. 认证测试仪器介绍

主要的仪器厂家:

  1. 日本安立(ANRITSU)
  2. 德国R&S
  3. 英国ANITE
  4. 美国AEROFLEX
  5. 美国SPRIENT

6、IT3 platform

与我们公司合作的sporton 实验室,主要使用的仪器是 R&S,有些LTE的测试项,R&S 测试会报错,只有Anite才能测过。这些case以后要重点关注。

 

我们主要接触的测试仪器是R&S,Anite还有 安立ANRITSU, IT3 platform。其他仪器,还需要以后认证问题处理过程中慢慢积累。

下面主要介绍这以下几种仪器log分析的基本方法。

    1. R&S仪器log分析方法

R&S 仪器log分析需要安装CMWmarsViewer.exe 工具,这个工具是sporton 实验室提供给我们的,我已经上传到108服务器上,路径如下:

\\10.128.161.108\Share\2_SW_Archive\1_Team\5_Telecom\Protocol\01_工具

 

CMWmarsViewer.exe 界面截图如下图:

 

实验室提供的仪器log截图如下:

 

通过file –〉open-〉messagelog.msglog 可以打开仪器log。工具打开后的仪器log截图如下:

 

 

 

 

可以通过ctrl + F 搜索进行关键字过滤想要的信息。

举例:

  1. 过滤RRC 消息,ctrl + F 在搜索框中输入rrc,查询结果如下图:

可以通过message Tree查看信令的具体内容。

使用简单方便,跟高通的QXDM 分析工具QCAT非常类似。

 

  1. 过滤NAS 消息,在ctrl + F 搜索框中输入nas,查询结果如下图,得到所有的nas 消息:

 

 

 

 

 

 

 

 

 

 

 

  1. 通过verdict 关键字获取仪器报错点

 

这个关键字非常重要,搜索这个关键字,我们可以对仪器报错点一目了然。上述例子中我们就可以很明显看到仪器fail点为:unexpected NAS PDU at port SRB. 根据这个线索我们可以去查看UE上报的NAS信令上报内容是否与测试要求符合,大大缩小问题分析范围。

 

 

    1. Anite 仪器log分析方法

实验室提供的Anite log截图如下:

 

这些文件中1359190407_SeqDbgLog.txt 文件可以查出仪器verdict fail点。

 

 

 

 

 

如下图,这个测试fail点:

Verdict fail:UnexpectedULMessage SMS

从仪器verfict fail点,我们可以直接去查UE发送的sms消息,找出fail真正原因。

Anite其他文件目前我还不是特别了解,需要在以后的工作中继续补充。

 

 

    1. 安立仪器log分析方法

安立仪器log,实验室提供给我们时,需要转换成html格式。

log截图如下图所示:

 

  1. 通过 index.html可以查询仪器SS与UE之间交互的详细信令流程。也可以查看任意一条信令PDU内容。

截图如下所示:

 

  1. 通过TestStepDetails.html 可以查询仪器verdict fail点

截图如下所示:

 

    1. IT3 platform 仪器log分析方法

IT3 platform主要测试sim卡一致性case,例如stk,usat等。仪器log需要实验室转换成word文档形式,转换成word文档后,仪器log查看非常容易。

实验室提供的IT3 log截图如下:

 

 

 

从仪器log一下就可以看到测试fail 点,截图如下:

错误点:MMI 显示异常,unexpected TERMINAL RESPONSE performed.

根据这个错误点,我们可以去分析UE log找出为何UE会发送错误的TERMINAL RESPONSE。

 

IT3 测试27.22.2 时可能会报PICS不符问题,分析这种问题,方法稍微复杂一些,后面会详细介绍。

 

 

  1. 案例分析举例
    1. Unexpected Nas PDU导致AGPS测试fail问题

1,问题描述:

37.571-2 AGPS三个case 7.3.4.2-5S/ 7.3.4.4-5S/ 7.3.5.1-5S 测试fail,实验室反馈仪器Verdict fail 的原因是因为收到错误的NAS PDU导致。AGPS问题是连接组负责处理,他们最开始怀疑是仪器问题,要求实验室更换Anite 测试,但是实验室用对比机可以测pass,所以拒绝更换仪器测试。

 

  1. 问题分析

问题转给我们后,根据问题分析步骤,首先分析仪器log,找到仪器Verdict fail点:

仪器verdict fail点为

Mismatch on port SRB: Difference: SRB_COMMON_IND.Signalling.Nas[0].Pdu.Msg。错误的nas信令消息为:ETC Test Loop Mode C MBMS Packet Counter Response。

2,分析UE QXDM log。

分析对比机pass log和UE fail log发现,UE在收到SS的reset UE positioning Stored Info Msg

后,给SS回了一条ULInformationTransfer,对比机无此NAS 消息。高通解析出这条ULInformationTransfer 后就是ETC Test Loop Mode C MBMS Packet Counter Response 消息。

由此可以判断,是UE 发送了这个消息导致仪器verdict fail。

Log 如下图:

 

进一步分析对比机pass log和UE fail log,fail log中有如下图红色框打印,当收到SS的Reset UE Positioning Stored Info。

 

因为这部分代码高通没有对我们开放,提case问高通,高通后来答复,确实是UE的问题,UE的MAC 处理有bug,申请patch解决这个问题。

 

总结:

这个问题其实分析起来并不复杂,分析对比机log很快就可以找出问题出错点。重要的是要掌握仪器log分析的方法,掌握对比分析方法,对分析问题事半功倍。

 

    1. Sim卡一致性测试Terminal profile问题
  1. 问题描述:

测试31.124 27.22.2 仪器报Terminal profile 与Pics不符。

这种问题属于认证问题分类中的第一类问题,UE上报能力与PICS申明不符。

 

2,问题分析

首先分析IT3 仪器log,仪器log报错点如下图:

从仪器log发现,item38 expected value 为1,receive value为0。UE上报的值与PICS不符。

问题分析步骤如下:

1,首先要找到item38对应的PICS项。

从仪器log发现item38 为1的PICS为C268

C268 - IF 'Option 85' THEN Mandatory ELSE Bit value="0" or bit not present

打开3Gpp TS 31.124 ,查找C268,发现对应的PICS如下图:

 

从上图可以看到如果要item38 为1,需要A.1/85 O_No_Type_NK 申明为yes。

查找pics发现对应的PICS项为:31124_A.1/85      Terminal supports keypad PICS中这项确实是申明为yes。

 

  1. 找到PICS项后,根据需求和产品特性决定修改UE软件还是修改PICS。

另外item42,item68分析方法一样。

 

    1. 需要更换Anite仪器测试问题

1,问题描述:

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

这三个case 实验室测试fail,以前的认证都是更换Anite 才复测pass。

 

 

 

  1. 问题分析

8.2.2.53 与8.3.4.11 是同样的问题,R&S仪器判断CQI间隔错误导致仪器误判。

 

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 我们详细分析了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|

 

  1. 总结

GCF/PTCRB 认证问题分析,除了掌握正确的分析方法外,还需要丰富的知识积累,厚积薄发,分析问题才能快速高效准确。因为认证问题涉及的范围广泛,涉及的模块较多。所以平时在解决问题的过程中,应该多发散,除了问题本身外,问题涉及的模块也可以仔细研究了解,这样对知识的积累很有帮助。

平时的积累,建议多看3GPP 协议,理解协议的实现细节,可以一边阅读协议章节,一边查找相应代码,这样对理解协议很有帮助。对理解代码实现逻辑也很有好处。

 

  1. 参考文档

3GPP协议文档

 

后记:这篇文章是很久之前写的一份经验总结文档,分享给大家,希望对大家希望对大家有帮助,如果有错误的地方,请指正。

如果有更好的思路和想法也可以分享出来,共同提升!

猜你喜欢

转载自blog.csdn.net/h721510279812/article/details/89599270