MME에서는 UE의 Purge 타이머를 관리하고 있습니다.

가입자가 Detach시 MME는 해당 타이머만큼 UE Context 정보를 저장하는데요.

만약 해당 타이머가 만료되지 않은 UE의 Attach Request가 들어오면 해당 가입자에 대한 GUTI/IMSI 정보를

알고있기 때문에 Identity Request/Response 과정을 생략하고, 바로 NAS Security Setup 과정을 시작합니다.

반대로 타이머가 만료된 UE의 Attach Request가 들어오면 MME는 UE에게 Identity Request를 전송합니다.

즉, Attach Request를 수정할 것이 아니라 MME에서 Purge 타이머를 0으로 변경한다면 

무조건 모든 UE의 Attach Request에 대해 Identity Request/Response가 발생합니다.

답변에 감사드립니다!!

제가 감히 하나더 질문드리자면

EMM Procedure: 1. Initial Attach for Unknown UE (1편) 참조하시면 case1번에 대한 내용 입니다.

purge타이머라는 구문이 생소해서 무엇을 말하는 의미 인지 잘 모르겠습니다 .

넷매니아즈 문서에는 Purge 타이머에 관련해서는 언급되어 있지 않은데요.

사실 Purge 타이머가 스펙에 정의되어 있는지는 잘 모르겠습니다만

Purge 타이머란 MME가 특정 가입자가 Detach 되더라도 일정한 시간동안 해당 가입자의 정보들을

(GUTI, IMSI, Security Context 등등)버리지 않고, 내부적으로 보유하고 있는 시간이라고 보시면 됩니다.

그러므로 Purge 타이머가 만료된 가입자가 Attach 할경우에는 MME 입장에서 가입자 정보가 없으므로

당연히 UE에게 IMSI 정보를 요청하는 Identity Request를 보내야 하며,

Purge 타이머가 만료되지 않은 가입자가 Attach 할경우에는 UE의 IMSI 정보를 보유하고 있으므로

Identity Request를 보낼 필요가 없습니다.

실제 모 통신사에서는 초기에 MME의 Purge 타이머를 0으로 운영하여 Attach시 항상

Identity Request/Response가 발생했으며, 최근에는 적당한 타이머로 (1~2시간) 운영중입니다.

각각 장/단점이 있는데요. 타이머를 0으로 운영하면 아무래도 MME 부하(용량)는 줄일수 있으며,

타이머를 늘리면 UE Attach 시에 Identity Request/Response 및 EPS-AKA 과정을 생략할수 있기에

Setup 시간을 줄일수 있겠지만 MME의 부하는 부하(용량)이 올라갑니다.

이 purge타이머라는 것이 attach accept 또는 mme구조에 있는 t3412 (GPRS Timer) 와 같은 구조인지 물어보고 싶습니다.

소스 코딩시에 purge타이머를 어떻게 제어해주어야 하는지 여쭤보고 싶습니다

T3412은 TAU 타이머라서 그것과는 상관이 없구요.

Purge 타이머는 일반적으로 규격에 정의되어 있는 Txxxx 라고 이름붙어있지 않습니다.

Purge 타이머는 UE나 eNB에서는 인지할수 없는 MME 고유의 값이므로 MME 소스를 코딩하셔야 

제어가 가능합니다.

혹시 purge timer에 대한 자료같은것은 어디서 참조할 수 있는지 말해주시면 안되겠습니까??

MME 자체의 Purge 타이머에 대한 자료는 못찾았는데요. 

MME 에서 특정 가입자의 정보를 Purge 시키면 HSS로 Purge Request / Answer 라는 Diameter 메시지를

주고 받습니다. 

3GPP TS 29.272 문서에서 Purge UE 부분을 참고하시면 되구요. 

이러한 절차를 위해서는 당연히 MME에서는 자체적으로 Purge 타이머를 관리해야 하는게 맞는것 같습니다.

좋은 답변 감사합니다

도움이 정말 많이 되었습니다

감사합니다.