概要
このドキュメントでは、PDNゲートウェイ(PGW)のUser Location Information(ULI)フィールドの最初のオクテットの誤った値の問題をトラブルシューティングする方法について説明します。
前提条件
要件
次の項目に関する知識があることが推奨されます。
使用するコンポーネント
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期(デフォルト)設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
省略形
APN |
アクセスポイント名 |
CDR |
コール詳細レコード |
CGI |
セルグローバル識別子 |
ECGI |
EUTRAN CGI |
E-UTRAN |
UTRANの進化 |
LSB |
最下位ビット |
MSB |
最上位ビット |
PDN |
パケットデータネットワーク |
PGW |
PDNゲートウェイ |
RA |
収益保証 |
RAI |
ルーティングエリアID |
佐井 |
サービスエリアID |
TAI |
トラッキングエリアID |
ULI |
ユーザ位置情報 |
UTRAN |
Universal Mobile Telecommunications System |
問題
サービスプロバイダーは、一部の4GサブスクライバのPGW CDRの誤った処理に関して、この問題を提起しました。問題のある加入者のCDRは、ULIフィールドの最初の状態で誤った値を持っていました。
Non-Problematic
==============
userLocationInformation 1804f4790x1x0xfx7x0x2x1x1x
Problematic
===========
userLocationInformation 8204f4790x2x0xfx7x0x4x2x0x
ここでは、ULIフィールドのオクテット1の最初の2桁は、値が18ではなく82"と表示されていますでした。
CDRでこの誤った印刷が行われたため、サービスプロバイダーのRAチームは、ユーザの場所の種類を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番目のオクテットはロケーションタイプを表します。
各オクテットは2つのニブルを表し、同じロジックで、5番目のオクテットは2つのニブルを持ちます。ニブル–1はビット–8からビット–5まで、ニブル–2はビット–4からビット–1までの範囲です。
従って、セット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
上の例では、Bold Green(18)でマークされたULIフィールドの16進表現は、第5オクテットの最初の2つのニブルの値です。
この場合、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
解決方法
問題が発生した場合、Create Session Request(CSReq)の同様の値が表示され、PGWトレースに出力されますが、CRIのCDRフィールドの出力がLocationを正しく反映しません。代わりに、次の出力が表示されます。
<< ULI seen in CDR >> - - - Problematic scenario
userLocationInformation 123-456-1-8547
上記の出力は、疑いを生み出します。
該当するAPNユーザのgtppグループ内から設定を確認すると、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フィールドを正しくデコードでき、問題が解決します。