소개
이 문서에서는 PGW(PDN-Gateway)의 ULI(User Location Information) 필드의 첫 번째 8진수에서 잘못된 값의 문제를 해결하는 방법에 대해 설명합니다.
사전 요구 사항
요구 사항
다음 주제에 대한 지식을 보유하고 있으면 유용합니다.
사용되는 구성 요소
이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다.이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다.네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 이해해야 합니다.
약어
APN |
액세스 포인트 이름 |
CDR |
통화 세부 정보 레코드 |
CGI |
셀 전역 식별자 |
ECGI |
유트란 CGI |
E-UTRAN |
UTRAN 진화 |
LSB |
가장 중요도가 낮은 비트 |
MSB |
가장 중요한 비트 |
PDN |
패킷 데이터 네트워크 |
PGW |
PDN 게이트웨이 |
RA |
수익 보증 |
RAID |
라우팅 영역 ID |
사이 |
서비스 영역 식별자 |
타이 |
추적 영역 ID |
울리 |
사용자 위치 정보 |
우트란 |
범용 모바일 통신 시스템 |
문제
일부 4G 가입자에 대한 PGW CDR의 잘못된 처리에 대해 서비스 공급자가 이 문제를 제기했습니다.문제가 있는 구독자 CDR에 ULI 필드의 첫 번째 위치에서 잘못된 값이 있습니다.
Non-Problematic
==============
userLocationInformation 1804f4790x1x0xfx7x0x2x1x1x
Problematic
===========
userLocationInformation 8204f4790x2x0xfx7x0x4x2x0x
여기서 ULI 필드의 8진수 1자리의 첫 번째 두 자리 값은 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번째 8진수는 위치 유형을 나타냅니다.
각 8진수는 두 개의 nibble을 나타냅니다. 동일한 논리를 사용하는 5번째 8진수는 두 개의 nibble을 가지며, 이는 nbble-1의 범위는 비트 8에서 비트 5까지, 니블-2는 비트 4에서 비트 1까지입니다.
이에 따라, 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는 귀사에서 보고한 문제에 따라 RA 팀의 주장대로 잘못된 PGW CDR에 82 값을 인쇄합니다.)
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 필드의 16진수 표시는 5번째 8진수 처음 두 니블의 값입니다.
그리고 이 경우 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
해결
문제가 발생하면 PGW 추적에 인쇄되는 CSReq(Create Session Request)의 비슷한 값이 표시되지만 CDR for ULI 필드의 출력은 위치를 제대로 반영하지 않습니다.대신 다음과 같은 출력이 표시됩니다.
<< ULI seen in CDR >> - - - Problematic scenario
userLocationInformation 123-456-1-8547
앞의 출력에는 의문이 생깁니다.
영향받는 APN 사용자에 대해 gtp 그룹 내부에서 구성을 확인한 후 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
gtp 그룹의 이전 사전 유형이 변경되면 RA 팀에서 ULI 필드를 제대로 디코딩하고 문제가 해결됩니다.