+86-755-89202795

GCF认证

GCF (Global Certification Forum) 1999年成立,是由运营商和终端制造商共同成立的一个组织,目的是通过独立的认证过程来确保终端的全球互操作。

运营商合规

PTCRB认证和GCF认证debug解析

(此文设定的情况是初始认证的情况,意为,设计的产品第一次做PTCRB认证,并且没有使用认证过的模组加进成品里面,不是变形认证,不是re-band,不是ECO等情况,所以debug中涉及到的问题会深层些。此外此处举例只涉及Protocol和SIM测试中出现的问题,其他的RF和OTA类的等问题没有出现,例举如何技术性使用测试log和仪器软件来使用快速定位找出问题实现快速debug。)

PTCRB:PCS Type Certification Review Board ,GCF:Global Certification Forum, PICS:Protocol Implementation Conformance Statement  .

深光标准为客户取得GCF证书

深光标准为客户取得PTCRB证书


一、PTCRB认证介绍

       PTCRB (PCS Type Certification Review Board) 是指个人通信服务型号认证评估委员会,由北美移动运营商于1997年成立。目前的运营商已经不仅限于北美,而是涵括全球范围内的移动运营商成员。其目的是为包括Cellular GERAN(GSM), UTRAN (UMTS)以及E-UTRAN (LTE)在内的终端产品和模板提供型号认证。
 
       PTCRB认证是第三方认证机构执行的准强制型号认证,所有投放北美市场的PCS终端设备都要经过PTCRB认证,并依据报告申请IMEI。这里用的是准强制性,强制性应该是政府监管部门发布的要求,但PTCRB不是政府性的,是论坛形式的,但是非常具有权威性,其原因在于进入北美的经销商必须按照这个要求去测试厂家提供的产品,因此叫做准强制性。PTCRB也是有运营商和一些大的手机厂商组成,还包括一些认可实验室。

   (IMEI可以在做PTCRB认证的同时同步申请,不需要PTCRB报告来申请。IMEI类似产品的身份证,不管做不做PTCRB认证,无线产品都应该要有自己的TAC码,一个TAC码加厂家自己定义的系列号就可以组成IMEI,一个TAC码可以管100万个IMEI。对于没有使用北美大型运营商的无线网络,其实是可以不用做PTCRB认证,但是实际上会出现不使用网络覆盖好的大型运营商的网络,而使用小型运营商的网络,会经常出现无线网络无法连接、频繁断网,甚至被标识非法设备等困扰,造成设备厂家不得不去申请PTCRB认证)
 
二、GCF认证介绍

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

GCF认证作用:厂商的目的是迅速获得进入市场的新模式,运营商的目的是提供有吸引力和可靠的业务。
 
GCF认证如何满足前面的目标:定义了每个终端所必须接受的测试,保证了终端的可靠、一致的行为。确保任何接受过GCF认证的终端都通过了这些测试。保证在将来能引入更多更复杂的技术。
 
GCF 认证基于自愿的原则,终端厂商基于GCF的认证标准(Certification Criteria)来声明其产品是否符合或超出认证标准的要求,GCF标准虽然不是强制性要求,但目前世界大部分的国家和地区都会要求终端生产厂商完成 GCF认证标准的测试,或者参考GCF认证标准。在欧洲及北美市场,终端产品的贩卖都是和网络运营商(Operator)相结合的,而一般网络运营商都会要求终端生产厂商对手机完成GCF的测试(大部分要求取得GCF认证)。
 
GCF与PTCRB测试大类一样也包括RF,Protocol,SIM,Audio等部分的测试。
(GCF认证跟PTCRB认证2个最大的区别:PTCRB认证不用做场测,且GCF会员要过认证需要缴纳年费,PTCRB是每次认证都需要支付列名费) 

三、PTCRB/GCF测试分类

1、RF部分的测试;

2、Protocol部分的测试;

3、SIM部分的测试;

4、Audio部分的测试;

(此外还有OTA测试、AT命令等测试)

5、外场测试 (Field Trail)

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

6、应用测试 (Application Enabler)

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

四、一致性测试协议分类

(1)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

(2)协议一致性测试协议标准

协议一致性标准如下:

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

 
(3)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

(以上信息为2016年的信息,最新测试标准PTCRB认证请参考PTCRB的测试标准NAPRD03,每个季度更新一次)


五、PTCRB/GCF 问题分析定位

s、mms、AGPS、call、SS(补充业务)等等。

(1)认证测试问题分类

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

UE 上报能力信息与PICS 申明不符问题。

Sim卡一致性测试问题,主要是STK问题。

2G/3G/4G 网络接入问题,例如GSM/WCDMA/LTE随机接入,plmn手动/自动选网。

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

应用类问题,例如sm

(2)认证问题基本分析方法

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

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

找到fail 问题的协议章节,根据协议描述,检查case的测试条件,测试步骤。

分析仪器log,找到仪器verdict fail的报错点。不同的测试仪器,log分析方法也不同,后面会举例介绍。

分析UE log,确定UE的行为是否正常。

分析对比机log,很多测试case,从仪器log或者UE log中无法找到明显的错误原因时,需要使用对比机log对比分析。

通过对比机测试也可以更加准确判断SS仪器问题还是UE问题导致的的测试fail。

(3)仪器log分析

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

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

认证测试仪器介绍

主要的仪器厂家:

日本安立(ANRITSU)

德国R&S

英国ANITE

美国AEROFLEX

美国SPRIENT

IT3 platform

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

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

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

R&S仪器log分析方法

R&S 仪器log分析需要安装CMWmarsViewer.exe 工具,这个工具是实验室提供给我们的,路径如下:

CMWmarsViewer.exe 界面截图如下图:

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


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

可以通过ctrl + F 搜索进行关键字过滤想要的信息。举例:过滤RRC 消息,ctrl + F 在搜索框中输入rrc,查询结果如下图:

可以通过message Tree查看信令的具体内容。使用简单方便,跟高通的QXDM 分析工具QCAT非常类似。过滤NAS 消息,在ctrl + F 搜索框中输入nas,查询结果如下图,得到所有的nas 消息:

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


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

Anite 仪器log分析方法,提供的Anite log截图如下:

这些文件中1359190407_SeqDbgLog.txt 文件可以查出仪器verdict fail点。如下图,这个测试fail点:
Verdict fail:UnexpectedULMessage SMS,从仪器verfict fail点,我们可以直接去查UE发送的sms消息,找出fail真正原因。

安立仪器log,需要转换成html格式,log截图如下图所示:

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

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


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不符问题,分析这种问题,方法稍微复杂一些,后面会详细介绍。

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

问题描述: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,所以拒绝更换仪器测试。

问题转给我们后,根据问题分析步骤,首先分析仪器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。

分析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分析的方法,掌握对比分析方法,对分析问题事半功倍。

(5)Sim卡一致性测试Terminal profile问题
问题描述:测试31.124 27.22.2 仪器报Terminal profile 与Pics不符。

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

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

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

问题分析步骤如下:首先要找到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。

找到PICS项后,根据需求和产品特性决定修改UE软件还是修改PICS。另外item42,item68分析方法一样。

(6)需要更换Anite仪器测试问题

问题描述: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。

问题分析: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|

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

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

      本文原创资料来源于CSDN的作者“二十八亩田2014”,因文章内容详实专业,故分享出来,深光实验室对一些过时的,缺失的信息给于补充说明,欢迎阅览。

      深光标准常年进行PTCRB认证和GCF认证,我们拥有处理这类PTCRB认证、GCF认证项目超过十几年工作经验的项目经理和工程师团队,多年来已经帮助多家上市企业取得PTCRB认证和GCF认证。希望对想要申请PTCRB 认证和GCF认证的客户有帮助,欢迎咨询我们对前期项目的评估沟通。  GCF认证/PTCRB 认证问题分析,除了掌握正确的分析方法外,还需要丰富的知识积累,厚积薄发,分析问题才能快速高效准确。因为认证问题涉及的范围广泛,涉及的模块较多。所以平时在解决问题的过程中,应该多发散,除了问题本身外,问题涉及的模块也可以仔细研究了解,这样对知识的积累很有帮助。

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

      本文原创资料来源于CSDN的作者“二十八亩田2014”,因文章内容详实专业,故分享出来,深光实验室对一些过时的,缺失的信息给于补充说明,欢迎阅览。

      深光标准常年进行PTCRB认证和GCF认证,我们拥有处理这类PTCRB认证、GCF认证项目超过十几年工作经验的项目经理和工程师团队,多年来已经帮助多家上市企业取得PTCRB认证和GCF认证。希望对想要申请PTCRB 认证和GCF认证的客户有帮助,欢迎咨询我们对前期项目的评估沟通。

推荐项目