排除4G用户PGW CDR中ULI字段第一个二进制八位数中的错误值
简介
本文档介绍如何对PDN网关(PGW)中用户位置信息(ULI)字段的第一个二进制八位数的值错误问题进行故障排除。
先决条件
要求
Cisco 建议您了解以下主题：
- StarOS
使用的组件
本文档不限于特定的软件和硬件版本。
本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。
缩写
| APN | 接入点名称 |
| CDR | 呼叫详细记录 |
| CGI | 单元格全局标识符 |
| ECGI | EUTRAN CGI |
| E-UTRAN | 升级UTRAN |
| LSB | 最低有效位 |
| MSB | 最高有效位 |
| PDN | 数据包数据网络 |
| PGW | PDN网关 |
| RA | 收入保证 |
| RAI | 路由区域标识 |
| SAI | 服务区标识符 |
| 泰 | 跟踪区域标识 |
| 乌利 | 用户位置信息 |
| UTRAN | 通用移动电信系统 |
问题
服务提供商出于对某些4G用户PGW CDR处理错误的顾虑而提出此问题。有问题的用户CDR在其ULI字段的第一个八位中的值错误。
Non-Problematic ============== userLocationInformation 1804f4790x1x0xfx7x0x2x1x1x Problematic =========== userLocationInformation 8204f4790x2x0xfx7x0x4x2x0x
在ULI字段中，二进制八位数的第1位两位，值显示为82”，而不是18。
由于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个二进制八位数表示位置类型。
每个二进制八位数代表两个二进制八位数，逻辑相同，第5个二进制八位数有两个二进制八位数，即半字节–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
在上例中，标有粗体绿色(18)的ULI字段的十六进制表示是第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所有字段的适当字典。请求更改的自定义33到自定义24的字典值。
gtpp group <name-default>
- -
gtpp dictionary custom24 - - - > New dictionary mapped to this group
- -
#exit
在gtpp组中的前一个字典类型更改后，您的RA团队能够正确解码ULI字段，并且问题已解决。
反馈