| 리포트 | 기술문서 | 테크-블로그 | 글로벌 블로그 | 원샷 갤러리 | 통신 방송 통계  | 한국 ICT 기업 총람 |

제품 검색

| 네트워크/통신 뉴스 | 기술자료실 | 자유게시판 |  
 
 
섹션 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/UHD IoT SDN/NFV Wi-Fi Video Streaming KT SK Telecom LG U+ OTT Network Protocol CDN YouTube Data Center
 
스폰서채널 |

 

  스폰서채널 서비스란?
LTE S1 기반의 핸드오버
LTE S1 based Handover
March 02, 2012 | By 유창모 (cmyoo@netmanias.com)
코멘트 (10)
18

지난 시간에 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로 옮겨가라고 할 건지 결정)을 할 수 있도록 정보를 제공하는 것입니다.
 
2. Handover Preparation
  • 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
 
4. Handover Completion
  • 이제 핸드오버 과정을 마무리할 단계입니다. 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 트래픽 전달용)
 
5. After Handover
  • 핸드오버 과정이 모두 마무리 되었고, 이제 UE는 Target eNB2를 통해 인터넷을 사용합니다.
 
Handover Completion 단계에서 End Marker 패킷
 
위에서 설명한 핸드오버 절차 중 Handover Completion 단계에서 S-GW가 보내는 트래픽의 흐름이 Source eNB1에서 Target eNB2로 변경이 되는데요. 그 과정 중에 패킷의 분실 혹은 패킷의 순서가 뒤바뀌는 것을 방지하기 위해 "End Maker" 패킷을 사용합니다. 그 흐름은 X2 handover와 매우 유사합니다.
 

 

  1. Handover Completion 과정이 시작되기 전에는 다음과 같은 흐름으로 패킷이 UE로 전달됩니다.
    • Internet -> P-GW -> S-GW -> Source eNB1 -> S-GW -> Target eNB2 -> UE
  2. S-GW는 Target eNB2와 S1 Bearer(GTP tunnel)를 생성합니다.
  3. S-GW는 S1 Bearer(GTP tunnel) 생성과 동시에 End Marker 패킷(하나 또는 어러개)을 Source eNB1로 보냅니다. 그리고는 UE로 향하는 패킷을 더 이상 Source eNB1으로 보내지 않고 새로 생성된 S1 Bearer를 통해 Target eNB2로 보냅니다. 여기서 End Marker 패킷은 "더 이상 Indirect Tunnel(Source eNB1 -> S-GW -> Target eNB2)을 통하는 패킷은  없다!"라는 사실을 Target eNB2에게 알려주는 용도입니다.
  4. 이 상황에서 Target eNB2는 2개의 경로로 부터 패킷을 수신하게 됩니다. 하나는 Indirect Tunnel(S-GW -> Source eNB1 -> S-GW -> Target eNB2)을 통해서 이고, 또 하나는 Direct Tunnel(S-GW -> Target eNB2)을 통해서 입니다. 이제부터 Target eNB2는 패킷 순서가 뒤바뀌지 않도록 잘 해야 합니다. Target eNB2는 Indirect Tunnel로 부터 수신되는 패킷들만 UE로 전달하고, Direct Tunnel로 부터 수신되는 패킷은 UE로 전달하지 않고 버퍼링합니다(가지고 있습니다). 언제까지요? 바로 Indirect Tunnel을 통해 End Marker 패킷이 하나라도 수신되기 전까지입니다. 
  5. 그러다가 Indirect Tunnel을 통해 End Marker 패킷이 수신되면, 이제 Target eNB2는 "Indirect Tunnel로 부터 수신할 패킷이 더 이상 없구나!"를 인지하고, 버퍼링해 놓았던 패킷(Direct Tunnel을 통해 S-GW로 부터 받았던 패킷)을 바로 UE에 전달합니다. 그리고 이후부터는 S-GW에서 오는 패킷을 UE로 전달하게 되는 거지요. 아래 흐름과 같이요...
    • Internet -> P-GW -> S-GW -> Target eNB2 -> UE

 

김기연 2012-04-12 11:10:55
자료 잘보고있습니다. ^^

궁금 한점이 있는데요.
Spec에 보면 Handover Preparation 의 [b] 단계에서 Target eNB2가 Handover Request Ack를 줄때 Forwarding을 위한 DL TEID와 추가적으로 UL TEID도 줄수 있는것으로 보이는데요.
해당 UL TEID는 어떤 경우에 사용하게 되는것인지요?
또 [c] 단계에서 Source eNB1로 Handover Command 를 보내는 경우 Forwarding UL TEID를 보내줄수 있는데,
해당 UL TEID를 사용하는 경우는 어떤 건가요?
넷매니아즈 2012-04-14 00:05:08
안녕하세요? 김기연님.

LTE 기술 담당하시는 분께서 차주부터 LTE 기술문서 작성을 다시 시작하시기로 했는데요.
향후 HO 기술문서에 질문 하신 내용도 함께 담도록 하시겠다고 하네요.

즉답을 못드려서 죄송해요~*
이돈명 2012-04-19 15:56:34
[b]의 단계에서 Target eNB2가 Handover Request Ack을 줄때 UL TEID를 주는 이유는 UL data 포워딩을 받기위해서 입니다. 핸드오버의 경우 DL과 마찬가지로 UL로 forwarding이 가능한 구조입니다.
[c]의 단계에서는 GW가 Source eNB1로 Handover Commmand에 포함하는 UL TEID는 GW가 Sourece eNB1으로 부터 UL Data 포워딩을 수신하기 위한 TEID 입니다.
넷매니아즈 2012-04-20 10:27:53
이돈명님, 답변 감사합니다~ ^^*
박정우 2014-05-26 18:42:37
좋은자료 감사드립니다 ^^ 근데 질문이 하나있는데.. 이미 a,b 과정에서 양방향 터널이 생성된거아닌가요??
e 에서 S-GW -> Target eNB1 로의 터널이 생겨나며 양방향이생겨난다고햇는데 그러면 b 에서생성된 단방향터널은무엇인지..ㅠㅠ 그리고 eNB2 아닌가요 ?? 학생이라 부족한지식을 보충하고자 질문드립니다 !!
Netmanias 2014-05-27 13:10:04
박정우님,

(eNB와 S-GW 간 사용자 트래픽을 전달하는 S1 bearer는 GTP 터널로 구성되고 GTP 터널은 방향성을 갖습니다. 상향(UL)은 사용자에서 발생한 트래픽을 전달하는 방향이고 하향(DL)은 사용자에게 향하는 트래픽을 전달하는 방향입니다.)

"a"와 "b" 과정에서 생기는 터널을 보면,
"a"는 target eNB가 S-GW로 상향 트래픽을 전달하기 위한 터널이고, "b"는 핸드오버 실행동안 S-GW가 source eNB로 전송한 하향 트래픽을 source eNB에서 target eNB로 forwarding하기 위한 터널입니다. Source eNB와 target eNB 간 direct connection이 없으니 source eNB는 S-GW를 거쳐 target eNB로 indirect forwarding을 하게 되지요. 핸드오버 실행 (handover execution) 동안에는 상향 트래픽은 없고 하향 트래픽만 있으므로 “b”는 하향 단방향으로만 동작합니다.

S-GW는 아직 source eNB로만 하향 S1 베어러 (GTP 터널)가 설정되어 있고, target eNB로는 하향 GTP 터널이 없는 상태이지요. S-GW와 target eNB간 하향 터널이 생성되려면 target eNB가 TEID를 할당해야 하는데, target eNB는 UE가 자기에게 성공적으로 무선 접속을 완료해야 이 값을 할당합니다.

"e"는 S-GW가 target eNB가 할당한 TEID를 수신하여 (target eNB한테 직접받지 않고 MME를 통해서 받지요) target eNB로 하향 GTP 터널 (DL S1 bearer)을 생성한 것입니다. 이제 "a"와 "e"를 결합하면 target eNB와 S-GW간 양방향 (상향+하향) S1 bearer가 됩니다.

이해에 도움이 되었나 모르겠네요. 자세한 내용은 "S1 핸드오버" 기술문서 https://www.netmanias.com/ko/?m=view&id=techdocs&no=5567 를 참고해 주세요.
감사합니다.
박정우 2014-06-02 13:11:19

많은도움이됫어요 !! 감사합니다~~~!

Yoo 2014-07-07 10:51:04

위에 김기연님이 질문하신 내용에 대해 이돈명님께서 답변을 해주셨는데 이해가 잘 안갑니다.

규격상 Handover Request Ack 메시지 내에 DL TEID와 UL TEID가 있을수 있는데

DL TEID는 Indirect Tunnel을 위한 TEID라고 한다면 UL TEID는 무슨 용도로 사용되는건가요?

 

실제 패킷을 분석해보면 UL TEID는 있는경우도 있고 없는 경우도 있습니다.

조동현 2016-05-17 19:13:46

위의 박정우님과 같은 질문인데요..

  • [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 생성)

이라고 되어있는데요..

 

"e"는 S-GW가 target eNB가 할당한 TEID를 수신하여 (target eNB한테 직접받지 않고 MME를 통해서 받지요) target eNB로 하향 GTP 터널 (DL S1 bearer)을 생성한 것입니다.

 

라고 말씀해주셨는데 결국에 tunnel을 생성하는 방법이 모두 target eNB2 가 TEID를 만들어 S-GW에게 주었기 때문 아닌가요? 뭐가 다른건지 잘모르겠습니다!

 

 

그리고 Handover Preparation 과정에서 이미 eNB1과 S-GW간에 GTP tunnel (양방향) 이 형성되어 있는데 왜 [c] 과정이 필요한 것인지 이해가 가지않습니다. (왜 또 다른 단방향 GTP tunnel을 만들어야 하는지..)

 

답변 부탁드립니다!

좋은 하루 되세요!

 

버너 2016-05-23 14:19:09

[조동현님]

이동통신망에서의 핸드오버 기본 컨셉은 “패킷 유실 없이, 패킷 역전 없이” 제공하는 것이라고 할 수  있습니다.


단말이 source eNB에서 target eNB로 이동을 완료하는데는 수십 ~ 수백 msec 정도의 시간이 소요되고

DL 방향 패킷을 예를 들어 H/O 과정을 요약한다면

- source eNB는 단말로 전달할 DL 패킷을 버퍼링하여 target eNB로 보내줘고

- SGW는 핸드오버 과정중에도 발생하는 DL 패킷을 버퍼링을 했다가 target eNB로 보내주고

- target eNB는 source eNB에 버퍼링 되었던 패킷을 먼저 단말로 보내준 후 SGW로부터 DL 패킷을 받도록 해서

단말이 이동 과정에서 수신하는 패킷의 역전 및 유실을 최대한 방지하고 핸드오버 실패시의 유실도 억제하도록

되어 있습니다.


이러한 이유로 target eNB는 핸드오버 완료후에 사용할 TEID와 핸드오버 중간에 사용할 TEID (UL, DL) 를

구분하고 각 노드 (PGW, SGW)의 TEID 설정 시점은 시그널링을 통해 조정을 하느라고 조금 복잡하게 된 것이니

“핸드오버 시작 시그널링을 source eNB가 트리거링한 시점에 SGW가 source eNB로 보낸 패킷을 어떻게

유실 및 역전 없이 단말에게 보낼 것인가”를 관점으로 시그널링 및 베어러 흐름을 보시면 이해가 되실 겁니다.


참고로 GTP-U 규격을 보시면 알겠지만 TEID 만으로는 발신지 확인이 안되기 때문에

위와 같이 용도별로 3개의 TEID가 사용됩니다


[조동현님/Yoo님]

Indirect DL TEID 는 위의 제 설명으로 이해가 가능하지만 Indirect UL TEID는 저도 설명을 못 드리겠네요

LTE/LTE 핸드오버시에는 필요 없을 것 같은데 Inter-RAT H/O시에는 UL 패킷에 대한

역전이 고려되어야 하는 건 아는가 모르겠습니다. Indirect UL TEID가 사용된 케이스를 좀 더 구체적으로

확인할 필요가 있을 것 같습니다. 

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
Related Contents
02/29/2012
Netmanias Blog
02/28/2012
Netmanias One-Shot Gallery
12/19/2011
Netmanias Blog
12/08/2011
Netmanias Blog
12/02/2011
Netmanias Blog
View All (973)
5G (68) AI (5) ALTO (1) AR (2) ARP (6) AT&T (1) Akamai (5) Authentication (5) BT (1) Backhaul (2) Big Data (2) Bridging (5) C-RAN/Fronthaul (17) CDN (20) CIoT (2) CPRI (6) Carrier Aggregation (5) Charging (2) China Mobile (2) Cisco (6) CoMP (3) Comcast (1) DHCP (6) DNS (15) Data Center (15) EDGE (11) EMM (1) EPS Bearer (7) Ethernet (3) FTTH (8) GSLB (5) Gigabit Internet (17) Google (17) Google Global Cache (8) Google TV (1) HLS (5) HTTP (5) HTTP Adaptive Streaming (7) HTTP Progressive Download (2) Handover (5) Huawei (1) IGMP (3) IP (6) IP Allocation (8) IP Routing (20) IPSec (4) IPTV (25) IoST (2) IoT (45) KT (45) Korea (8) Korea ICT Vendor (1) L3 Switch (5) LG U+ (24) LTE (99) LTE-A (10) LTE-A Pro (1) LTE-M (1) LTE-U (3) LoRa (5) MEC (11) MPLS (3) MWC 2013 (1) MWC 2015 (3) MWC 2016 (2) MWC 2017 (1) Mobile IPTV (1) Multi-Screen (1) Multicast (2) NAT (9) NB-IoT (6) NTT Docomo (1) Netflix (5) Network Protocol (49) Network Slicing (3) OSPF (3) OTT (20) Operator CDN (1) P2P (3) PS-LTE (3) Pooq (2) QoS (5) RCS (1) RRH (1) Request Routing (3) SD-WAN (8) SDN/NFV (34) SK Broadband (1) SK Telecom (38) Samsung (2) Security (8) Self-Driving (3) Shortest Path Tree (2) Small Cell (3) Spectrum Sharing (1) TAU (2) Transparent Caching (9) UHD (7) VLAN (2) VPN (3) VR (3) Video Streaming (22) VoLTE (1) VoWiFi (1) WAN Optimization (1) Wi-Fi (30) WiBro(WiMAX) (2) YouTube (16) eICIC (1) eMBMS (1) ePDG (6) u+ tv G (4) 로컬 5G (1)

 

 

     
         
     

 

     
     

넷매니아즈 회원 가입 하기

2019년 1월 현재 넷매니아즈 회원은 49,000+분입니다.

 

넷매니아즈 회원 가입을 하시면,

► 넷매니아즈 신규 컨텐츠 발행 소식 등의 정보를

   이메일 뉴스레터로 발송해드립니다.

► 넷매니아즈의 모든 컨텐츠를 pdf 파일로 다운로드

   받으실 수 있습니다. 

     
     

 

     
         
     

 

 

비밀번호 확인
코멘트 작성시 등록하신 비밀번호를 입력하여주세요.
비밀번호