欧美亚洲天堂网_女人与拘掹交高清播放免费_中文无码素人_粉色APP在线观看_污版91香蕉视频_美国毛片aaa在线播放_国产福利姬g奶紧身包臀裙_免费亚洲一区_91自产国偷拍在线_欧美成电影综合网站色www

+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認證的客戶有幫助，歡迎咨詢我們對前期項目的評估溝通。

推薦項目