對4G使用者的PGW CDR中ULI欄位的第一個八位元中的錯誤值進行故障排除
簡介
本文說明如何排解PDN-Gateway(PGW)中User Location Information(ULI)欄位第一個八位元中的錯誤值問題。
必要條件
需求
思科建議您瞭解以下主題：
- StarOS
採用元件
本文件所述內容不限於特定軟體和硬體版本。
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。
縮寫
| APN | 接入點名稱 |
| CDR | 通話明細記錄 |
| CGI | 單元格全域性識別符號 |
| ECGI | EUTRAN CGI |
| E-UTRAN | 升級UTRAN |
| LSB | 最低有效位 |
| MSB | 最高有效位 |
| PDN | 資料包資料網路 |
| PGW | PDN閘道 |
| RA | 收入保證 |
| RAI | 路由區域標識 |
| SAI | 服務區域識別符號 |
| TAI | 跟蹤區域標識 |
| 烏利 | 使用者位置資訊 |
| UTRAN | 通用行動通訊系統 |
問題
服務提供商擔心某些4G使用者的PGW CDR處理錯誤，因而提出了此問題。有問題的使用者CDR在其中ULI欄位的第一個二進位制八位數中有錯誤的值。
Non-Problematic ============== userLocationInformation 1804f4790x1x0xfx7x0x2x1x1x Problematic =========== userLocationInformation 8204f4790x2x0xfx7x0x4x2x0x
這裡，在ULI欄位上八位組一的第一個兩位數字中，值顯示為82"而不是18。
由於CDR中的錯誤列印，服務提供商的RA團隊無法識別使用者的Location型別，無論使用者是e-UTRAN(4G)還是GERAN/UTRAN(2G/3G)，都會導致錯誤的計費問題。
疑難排解
服務提供商是任何向呼叫移動使用者的終端使用者提供移動無線服務的移動運營商。
使用者位置資訊
This field contains the User Location Information of the MS as defined in TS 29.060 for GPRS case, and in TS 29.274 for EPC case (e.g. CGI, SAI, RAI TAI and ECGI), if available.
This field is provided by the SGSN/MME and transferred to the S-GW/P-GW during the IP-CAN bearer activation/modification. User Location Information contains the location (e.g. CGI/SAI, ECGI/TAI or RAI) where the UE is located while opening the respective CDR.
The flags ECGI, TAI, RAI, SAI and CGI in octet 5 indicate if the corresponding fields are present in the IE or not. If one of these flags is set to "0", the corresponding field is not present at all.
根據3GPP 29.274v12第8.21節，ULI編碼為：
This IE shall contain only one identity of the same type (for example, more than one CGI cannot be included), but ULI IE may contain more than one identity of a different type (e.g. ECGI and TAI). The flags LAI, ECGI, TAI, RAI, SAI and CGI in octet 5 indicate if the corresponding type shall be present in a respective field or not.
If one of these flags is set to "0", the corresponding field shall not be present at all.
If more than one identity of different type is present, then they shall be sorted in the following order: CGI, SAI, RAI, TAI, ECGI, LAI.
從ULI確定位置型別
根據前面的影象，ULI欄位的第5個二進位制八位數表示位置型別。
每個八位組代表兩個半位元組，具有相同邏輯，第5個八位組有兩個半位元組，即從第8位到第5位的半位元組–1範圍以及從第4位到第1位的半位元組–2範圍。
因此，無論何時在set 1的這些小塊中的相應標誌，都考慮ULI的下一個匹配欄位中存在的位置型別相關資訊。
For example (for octet 5):
When 1st bit of nibble-1 (LSB) is set "1" in 5th Octet, it should reflect ECGI information in respective octet (e to e+6)
When 4th bit of nibble-2 (MSB) is set "1" in 5th Octet, it should reflect TAI information in respective octet (d to d+4)
See the pictorial representation in Figure-2
因此，根據此影象，對於CDR中具有ECGI資訊的4G使用者，應該表示ULI欄位開頭的值18。(但根據您報告的問題，Cisco PGW在PGW CDR中列印82值，根據RA團隊的說法，此值是錯誤的。)
來自PGW（在GTPv2上）的樣本跟蹤確認這些值來自S5介面。
<< ULI seen in CSReq>>
USER LOCATION INFO:
Type: 86 Length: 13 Inst: 0
Value:
Location type: TAI
MCC: 123
MNC: 456
TAC: 0x1
Location type: ECGI
MCC: 123
MNC: 456
ECI: 0x0000001
Hex: 5600 0D00 1821 6354 0001 2163 5400 0000
01
在上例中，以粗綠色(18)標籤的ULI欄位的Hex表示是第5個八位元的前兩個半位元組的值。
在這種情況下，PGW CDR還會在CDR中列印正確的ULI值（在PGW上列印的CDR輸出中）
<< ULI seen in CDR >> - - - Non-Problematic scenario
userLocationInformation
Location Type TAI
MCC 123
MNC 456
TAC 0x1
Location Type ECGI
MCC 123
MNC 456
ECI 0x0000001
解析
在出現問題時，會看到建立會話請求(CSReq)中的類似值，這些值在PGW跟蹤中列印，但ULI的CDR欄位的輸出未正確反映位置。而是輸出如下：
<< ULI seen in CDR >> - - - Problematic scenario userLocationInformation 123-456-1-8547
先前的輸出會造成疑問。
從gtpp組內部為受影響的APN使用者檢查配置後，發現gtpp字典對映為custom33
gtpp group <name-default>
- -
gtpp dictionary custom33 - - - > dictionary mapped to this group
- -
#exit
根據建議，對於4G使用者CDR欄位，服務提供商應使用包含4G所有欄位的相應字典。要求更改從custom33到custom24的字典值。
gtpp group <name-default>
- -
gtpp dictionary custom24 - - - > New dictionary mapped to this group
- -
#exit
在gtpp組中更改之前的字典型別後，您的RA團隊能夠正確解碼ULI欄位，問題得到解決。
意見