위의 제목처럼 만약 PGW에서 Delete Bearer Request를 보냈는데 만약 이에 대한 Response를 수신하지 못했을 경우 어떻게 처리되나요?
(1) PGW 에서 timer에 의해 Request 재전송?
(2) 만약 재전송 scheme이 존재하여 재전송을 했지만, 그래도 response를 수신하지 못한다면?
혹시 아시는 분들의 답변 부탁드립니다.
Yoo Daeseong2013-10-04 14:00:19
질문의 요지는 PGW에서 Delete Bearer Request를 보내면 해당 Bearer에 대한 자원을 해지하는지? 아니면 Response message를 수신해야 자원을 해지하는지 입니다. 만약 Response를 수신한 후 자원을 해지한다면 위와 같이 Delete Bearer Response를 수신하지 못한 경우 어떻게 처리되는지....
아시는 분들의 많은 조언 부탁드립니다.
Yoo2013-10-06 00:14:56
정확치는 않은데 제가 찾아본 내용을 적어봅니다.
우선 Dedicated Bearer를 삭제하는 정상적인 Call Flow를 아래와 같이 5단계로 나누어 설명해 보면요.
②번에서 MME는 eNB에게 Deactivate EPS Bearer Context Request 메시지를 전송후 T3495 타이머를 동작합니다. T3495의 표준 권고값은 8sec로 되어있으며 총 4번 더 재전송을 시도후에도 응답이 없으면 해당 절차를 중지하고 UE와 따로 ESM 시그널링 송/수신 없이 자체적으로 Deactivate EPS Bearer Context를 진행합니다. 즉 MME 자체적 으로 해당 Bearer Context 정보를 삭제하고, P-GW에게는 정상적으로 Delete Bearer Response로 응답할 것으로 예상됩니다.
그럼 Yoo Daeseong님이 질문하신대로 Delete Bearer Request에 대한 응답을 수신하지 못했을 때 P-GW의 동작방식을 보기위해서 먼저 GTP-C 동작방식에 대해 설명드리면요. (Delete Bearer Requset는 GTP-C 메시지)
GTP-C는 Reliable Delivery를 위해 Initial message (request message)와 Triggered message (response)가 항상 서로 pair로 동작하며, Initial message를 수신하면 해당 헤더의 Sequence Number 값을 그대로 복사해서 Triggered message에 삽입하여 회신주는 방식으로 서로 매칭 시킵니다. GTP-C 또한 T3-RESPONSE 와 N3-REQUEST 라는 파라미터 값을 갖는데요. T3-RESPONSE는 Reqeust에 대한 Response를 기다리는 타이머이며, N3-REQUEST는 Response 메시지를 수신하지 못할 경우 몇번 더 동일한 Request를 재전송 할지 카운트 값입니다. 이 값들은 권고치가 없으며 순전히 제조사의 구현에 맡겨져 있구요.
결국 T3-RESPONSE 타이머와 N3-REQUEST 값이 초과되면 GTP 프로토콜 단에서 Path Failure로 인지하고 상위 레이어에 이를 알리고, 관련된 PDN Connection 정보를 삭제한다고 합니다.
질문하신 내용이 맞는지는 모르겠는데 도움이 되셨으면 좋겠습니다.
Yoo Daeseong2013-10-07 14:02:16
답변 감사합니다. 자세한 답변으로 이해가 잘 되었습니다.
Yoo Daeseong2013-10-07 14:33:41
한가지 더 추가적인 질문을 드려도 될까요? 만약 Delete Bearer Request에 대해서 GTP 단에서 fail response를 보낸다면.... 어떻게 처리가 될까요?
Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
만약 Response를 수신한 후 자원을 해지한다면 위와 같이 Delete Bearer Response를 수신하지 못한 경우 어떻게 처리되는지....
아시는 분들의 많은 조언 부탁드립니다.
우선 Dedicated Bearer를 삭제하는 정상적인 Call Flow를 아래와 같이 5단계로 나누어 설명해 보면요.
① P-GW -> MME : Delete Bearer Request
② MME -> eNB : E-RAB Release Command / Deactivate EPS Bearer Context Request
③ eNB -> MME : E-RAB Release Response
④ eNB -> MME : Deactivate EPS Bearer Bearer Context Accept
⑤ MME -> P-GW : Delete Bearer Response
②번에서 MME는 eNB에게 Deactivate EPS Bearer Context Request 메시지를 전송후 T3495 타이머를 동작합니다.
T3495의 표준 권고값은 8sec로 되어있으며 총 4번 더 재전송을 시도후에도 응답이 없으면 해당 절차를 중지하고
UE와 따로 ESM 시그널링 송/수신 없이 자체적으로 Deactivate EPS Bearer Context를 진행합니다. 즉 MME 자체적
으로 해당 Bearer Context 정보를 삭제하고, P-GW에게는 정상적으로 Delete Bearer Response로 응답할 것으로
예상됩니다.
그럼 Yoo Daeseong님이 질문하신대로 Delete Bearer Request에 대한 응답을 수신하지 못했을 때 P-GW의
동작방식을 보기위해서 먼저 GTP-C 동작방식에 대해 설명드리면요. (Delete Bearer Requset는 GTP-C 메시지)
GTP-C는 Reliable Delivery를 위해 Initial message (request message)와 Triggered message (response)가 항상 서로
pair로 동작하며, Initial message를 수신하면 해당 헤더의 Sequence Number 값을 그대로 복사해서 Triggered
message에 삽입하여 회신주는 방식으로 서로 매칭 시킵니다.
GTP-C 또한 T3-RESPONSE 와 N3-REQUEST 라는 파라미터 값을 갖는데요. T3-RESPONSE는 Reqeust에 대한
Response를 기다리는 타이머이며, N3-REQUEST는 Response 메시지를 수신하지 못할 경우 몇번 더 동일한
Request를 재전송 할지 카운트 값입니다. 이 값들은 권고치가 없으며 순전히 제조사의 구현에 맡겨져 있구요.
결국 T3-RESPONSE 타이머와 N3-REQUEST 값이 초과되면 GTP 프로토콜 단에서 Path Failure로 인지하고
상위 레이어에 이를 알리고, 관련된 PDN Connection 정보를 삭제한다고 합니다.
질문하신 내용이 맞는지는 모르겠는데 도움이 되셨으면 좋겠습니다.
자세한 답변으로 이해가 잘 되었습니다.
만약 Delete Bearer Request에 대해서 GTP 단에서 fail response를 보낸다면.... 어떻게 처리가 될까요?