지난 시간에 X2 based Handover에 대해서 알아 보았습니다. 오늘은 사용자 데이터의 경로 변경 위주로 S1 based Handover에 대해서 설명을 드리겠습니다. S1 handover가 X2 handover와 구별되는 가장 큰 차이점은 

• Handover Preparation 과정에 EPC(MME, S-GW)가 관여를 하다는 사실과 (X2 handover는 EPC가 관여하지 않음)
• 핸드오버 과정 중에 UE로 향하는 DL 트래픽이 S-GW -> Source eNB1 -> S-GW -> Target eNB2 -> UE 라는 것입니다 (X2 handover는 S-GW -> Source eNB1 -> Target eNB2 -> UE)

1. Before Handover

• UE는 이동 중에 인터넷을 사용하고 있습니다. 트래픽 흐름은 다음과 같습니다.
  • UL Traffic: UE -> Source eNB1 -> S-GW -> P-GW -> Internet
  • DL Traffic: Internet -> P-GW -> S-GW -> Source eNB1 -> UE
• 그리고 UE는 자신이 붙어 있는 Serving eNB인 eNB1에게 Measurement Report 메시지를 보내어(Event triggered 혹은 Periodic하게 보냄)  "Serving eNB의 Cell로 부터 수신되는 Radio Signal Strength와 Neighbor Cell(쉽게 말해 바로 근처에 있는 eNB 즉, eNB2의 Cell)로 부터 수신되는 Radio Signal Strength"를 보고합니다. 이는 Serving eNB가 Handover Decision(나랑 계속 붙어 있게 할 건지, 아니면 옆집 eNB로 옮겨가라고 할 건지 결정)을 할 수 있도록 정보를 제공하는 것입니다.

• UE가 계속 이동을 하여 eNB2와 더 가까워 졌습니다. 그러면 Serving eNB인 eNB1은 자기보다 eNB2로부터 UE가 더 좋은 Radio Signal을 수신하는것을 확인 후에 Handover Decision(해당 UE를 다른 eNB로 옮겨야 겠구나!)을 하게 됩니다.
• [a] Source eNB1은 MME에게 Handover Required 메시지를 보내어 핸드오버 사실을 알리고(X2 handover는 Target eNB2에게 메세지를 보내 eNB 끼리 핸드오버를 준비하지만 S1 handover는 EPC 즉 MME 관여하에 핸드오버 진행), 이 메세지에는 UE가 어떤 eNB의 Cell에 붙을지(ECGI of Target eNB2) 정보가 포함되어 있습니다. 그러면 MME는 해당 Target eNB2로 Handover Request 메시지를 보냅니다. 이 메시지에는 Target eNB2가 S-GW 방향으로 UL 트래픽을 보낼 수 있는 GTP TEID(Tunnel Endpoint ID)인 S1 S-GW TEID가 포함되어 있으며, 이 TEID는 Source eNB1이 사용하던 값입니다. 이제 Target eNB2에서 S-GW 방향으로의 단방향 Tunnel인 S1 Bearer가 생성 되었습니다.
• [b] Target eNB2는 이에 대한 응답으로 Handover Request Ack 메시지를 MME로 보내고, MME는 다시 S-GW로 Create Indirect Data Forwarding Tunnel Request 메시지를 보내어 S-GW에서 Target eNB2로의 단방향 S1 Bearer for Indirect Forwarding Tunnel을 생성합니다. (Target eNB2에서 S1 Target eNB TEID를 생성하고, 그 TEID가 MME를 거쳐 S-GW로 전달되어 Tunnel 생성)
• [c] S-GW는 Create Indirect Data Forwarding Tunnel Response 메시지를 MME로 보내고, MME는 Handover Command 메시지를 Source eNB1으로 보내어 Source eNB1에서 S-GW로의 단방향 S1 Bearer for Indirect Forwarding Tunnel을 생성합니다. (S-GW에서 S1 S-GW TEID를 생성하고, 그 TEID가 MME를 거쳐 Source eNB1으로 전달되어 Tunnel 생성)
• 핸드오버가 완전히 끝나기 전까지는 위 절차를 통해 생성한 Indirect Tunnel([c] Source eNB1 -> S-GW, [b] S-GW -> Target eNB2)을 통해 UE가 DL 트래픽을 수신하게 될 것입니다. 
• 여전히 UE의 UL/DL 트래픽은 Source eNB1과 S-GW를 통해 지나 다니고 있습니다.

3. Handover Execution

• 이제 Source eNB1은 UE에게 RRC Connection Reconfiguration 메시지를 전송하여 새로운 eNB(Target eNB2)로 붙으라고 합니다. 
• UE는 Source eNB1과의 연결을 끊습니다 (Detach from Source eNB1).
• [d] UE는 Target eNB2와 연결하게 되고(DRB established), 이제부터 트래픽 흐름이 다음과 같이 바뀌게 됩니다.
  • UL Traffic: UE -> Target eNB2 -> S-GW -> P-GW -> Internet
  • DL Traffic: Internet -> P-GW -> S-GW -> Source eNB1 -> S-GW -> Target eNB2 -> UE

• 이제 핸드오버 과정을 마무리할 단계입니다. Target eNB2는  MME에게 Handover Notify 메시지를 보내어 UE가 성공적으로 핸드오버 되었음을 알립니다.
• [e] MME는 S-GW로 Modify Bearer Request를 보내고 이 메시지에는 S-GW에서 Target eNB2로 DL 트래픽이 흐를 수 있는 TEID인 S1 Target eNB TEID가 포함되어 있습니다. [a] 과정에서 Target eNB2 -> S-GW 방향의 터널 생성이 되었고, [e] 과정에서 S-GW -> Target eNB1 방향의 터널이 생성되었으니, 양방향 S1 Bearer가 생성이 된 것입니다. 이 시점에 S-GW는 UE로 향하는 DL 트래픽의 방향을 Source eNB1에서 Target eNB2로 바꿉니다. (Path Switch from Source eNB1 to Target eNB2)
• 이제 트래픽 방향은 다음과 같게 됩니다.
  • UL Traffic: UE -> Target eNB2 -> S-GW -> P-GW -> Internet
  • DL Traffic: Internet -> P-GW -> S-GW -> Target eNB2 -> UE
• 이제 더 이상 필요치 않은 터널들을 해제(Bearer release)하기 위해 MME가 eNB로는 UE Context Release Command를 보내고, S-GW로는 Delete Indirect Data Forwarding Tunnel Request 메시지를 보냅니다. 해제되는 터널은 다음과 같습니다.
  • Source eNB1과 S-GW 사이의 S1 Bearer for Indirect Forwarding (핸드오버 과정 중에 DL 트래픽 전달용)
  • Target eNB2와 S-GW 사이의 S1 Bearer for Indirect Forwarding (핸드오버 과정 중에 DL 트래픽 전달용)
  • Source eNB1과 S-GW 사이의 S1 Bearer (핸드오버 발생 전에 UL/DL 트래픽 전달용)