| 리포트 | 기술문서 | 테크-블로그 | 글로벌 블로그 | 원샷 갤러리 | 통신 방송 통계  | 한국 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와 Wi-Fi 네트워크 연동 구조 (4편: 모든 Wi-Fi 트래픽은 P-GW를 통해야만 하는가?)
Network Architecture for LTE and Wi-Fi Interworking (Part 4: Traffic Selector)
May 22, 2012 | By 유창모 (cmyoo@netmanias.com)
banner
코멘트 (9)
22

오늘은 LTE와 Wi-Fi 연동 구조 4편 "Wi-Fi에 접속한 UE의 모든 트래픽은 P-GW를 거쳐야 하는가?"에 대한 설명입니다.

다들 잘 아시겠지만 Wi-Fi 기술은 정말 저렴합니다. AP 하나에 2~3만원 정도이고 별도의 Core 장비(LTE의 P-GW 같은)가 필요 없습니다. 하지만 LTE 기술은 정말 정말 비쌉니다. Wi-Fi가 마티즈라면 LTE는 마이바흐(Maybach) 정도 되겠죠. 

그래서 비싼 LTE 망의 성능 유지/자원 보호를 위해 Wi-Fi와 같은 저렴한 기술로 Mobile Data Offloading을 하고 있죠.

 

여기서 잠깐! Mobile Data Offloading이란? 

 

  Mobile data offloading, also called data offloading is the use of complementary network technologies for delivering data originally targeted for cellular networks. The main complementary network technologies used for the mobile data offloading are Wi-Fi, Femtocell.  

출처: http://en.wikipedia.org/wiki/Mobile_data_offloading

 

 

WLAN 3GPP IP Access와 WLAN Direct IP Access

 

그렇다면 이동통신사업자가 비싼 돈 들여 구축한 LTE 망과 Wi-Fi 망을 연동(핸드오버)시키고, 가입자의 모든 Wi-Fi 트래픽을 EPC(S-GW, P-GW)를 통해 다니게 할까요? 물론 아닙니다.

 

아래 그림(KT를 예로... KT가 현재 LTE/Wi-Fi 연동 서비스 하고 있다는 의미는 아님)을 통해 설명드리겠습니다.

KT 관점에서 세상의 모든 서비스는 딱 2가지 타입으로 분류할 수 있습니다.

  1. KT가 직접 가입자에게 제공하는 서비스 (예. olleh TV now)
  2. KT와 전혀 상관없는 서비스 (예. YouTube, 네이버, 다음 등등)
어떤 서비스가 더 중요할까요? 당연히 1번이죠(KT 입장에서).
따라서 1번 서비스(이하 olleh TV now)의 경우, Wi-Fi에 접속한 가입자도 ePDG/P-GW를 거쳐 서비스를 받을 수 있도록 하고 이로 인해 본 서비스에 대해서는 LTE/Wi-Fi 망간에 핸드오버가 됩니다. 즉,
  • 가입자가 LTE 망에 붙어 olleh tv now 서비스 이용시 트래픽 흐름: UE - eNB - S-GW - P-GW - olleh TV now
  • 가입자가 Wi-Fi 망에 붙어 olleh tv now 서비스 이용시 트래픽 흐름: UE - AP - ePDG - P-GW - olleh TV now
2번 서비스(이하 YouTube)의 경우, Wi-Fi에 접속한 가입자는 AP에서 바로 IP network을 타고 YouTube로 갑니다. 즉, ePDG/P-GW를 거치지 않으며 따라서 본 서비스에 대해서는 LTE/Wi-Fi 망간에 핸드오버가 되지 않습니다. 즉,
  • 가입자가 LTE 망에 붙어 YouTube 서비스 이용시 트래픽 흐름: UE - eNB - S-GW - P-GW - YouTube
  • 가입자가 Wi-Fi 망에 붙어 YouTube 서비스 이용시 트래픽 흐름: UE - AP - YouTube

 

이와 같이 Wi-Fi 망에 접속한 단말이 사용 서비스에 따라 ePDG/P-GW를 거칠 수도 아닐 수도 있으며 이를 위해

  • IKEv2 과정에서 ePDG는 UE로 Traffic Selector(TSi, TSr)를 전달하고, 이는 다음과 같은 파라미터로 구성되어 있습니다.
    • TSi = Source IP Address(SIP) range, Protocol range, Source Port Number(SP) range
    • TSr = Destination IP Address(DIP) range, Protocol range(TSi와 동일), Destination Port Number(DP) range
  • 즉, TSi와 TSr을 합치면 5-tuple이 됩니다.
  • 이 5-tuple에 의해서 "어떤 UE가(SIP) 어떤 서버로(DIP) 어떤 프로토콜(Protocol=6이면 TCP)을 이용하여 어떤 서비스(DP=80이면 HTTP)를 요청하는지" 정의될 수 있어 UE는 Wi-Fi 망으로 패킷 송신시 olleh TV now 서비스인지 YouTube 서비스인지 구분할 수 있습니다.

Wi-Fi망에 접속한 UE가 3GPP 엔터티인 ePDG/P-GW를 통해 인터넷과 통신하는 경우를 WLAN 3GPP IP Access라 부르고(olleh TV now 서비스), Wi-Fi AP에서 바로 인터넷으로 가는 경우를 WLAN Direct IP Access라 부릅니다(YouTube 서비스).

 

 

Detail Flow

 

위의 개념 설명을 좀 더 자세한 흐름으로 설명드리겠습니다.

 

아래 그림에서 좌측에 UE가 있고 UE의 프로토콜 스텍(App, TCP/IP, IPSec, Wi-Fi)이 표시되어 있으며 우측에는 무선망(AP, ePDG, P-GW)과 서비스 서버(olleh TV now, YouTube)가 있고 그 하단에 IP network이 자리잡고 있습니다.

 

 

UE는 Wi-Fi에 접속을 하면서 2개의 IP 주소를 받아 왔습니다. (IP 할당 절차가 궁금하시면 여기를 클릭하세요)

  • 첫번째 IP는 Wi-Fi 망의 DHCP 혹은 AP로 부터 받은 10.1.1.1이고 두번째 IP는 P-GW로 부터 받은 1.1.1.1입니다.
  • IP 망 관점에서 목적지 주소가 10.1.1.1인 패킷은 AP로 그 패킷을 포워딩하고 1.1.1.1인 패킷은 P-GW로 포워딩되도록 라우팅이 설정되어 있습니다.
이제 위 그림의 번호 순으로 설명을 드리겠습니다.
 
 Traffic Selector(TSi, TSr) 전달
[1] IKEv2 과정에서 UE는 다음과 같은 Traffic Selector를 ePDG로 부터 전달받아 저장합니다.
  • TSi: SIP = 0.0.0.0 ~ 255.255.255.255 (Any IP address), Protocol = 6 (TCP), SP = 0 ~ 65535 (Any Port #)
  • TSr: DIP = 20.20.1.1 (olleh TV now 서버 IP address), Protocol = 6 (TCP), DP = 80 (HTTP)
 
■ YouTube 트래픽 흐름
[2] 사용자가 YouTube 앱을 실행하고 동영상을 요청합니다. YouTube 앱에서 구성한 IP 패킷은 다음과 같습니다.
  • DIP = YouTube 서버 IP, Protocol = 6 (TCP), DP = 80 (HTTP)
이 패킷은 Traffic Selector 룰에 매칭되지 않습니다. (YouTube 서버 DIP는 20.20.1.1이 아님)
[3] 따라서 이 패킷은 IPSec 터널링되지 않고 바로 Wi-Fi 망으로 전달되고, 이 경우 SIP는 10.1.1.1, DIP는 YouTube가 됩니다.
[4] 그 패킷은 AP를 지나 IP망을 통해 라우팅 되어 YouTube 서버로 전달됩니다. YouTube 서버가 수신하는 패킷의 SIP는 10.1.1.1입니다. 또한 그 패킷의 응답으로 YouTube 서버가 송신하는 패킷의 DIP는 10.1.1.1이 되고, 이 패킷은 AP로 라우팅 됩니다.
 
■ olleh TV now 트래픽 흐름
[5] 이번엔 사용자가 olleh TV now 앱을 실행하고 동영상을 요청합니다. olleh TV now 앱에서 구성한 IP 패킷은 다음과 같습니다.
  • DIP = 20.20.1.1(olleh TV now 서버 IP), Protocol = 6 (TCP), DP = 80 (HTTP)
이 패킷은 Traffic Selector 룰에 매칭이 됩니다!
[6] 따라서 이 패킷은 IPSec 터널링이 되어(Outer SIP=10.1.1.1, Outer DIP=ePDG, Inner SIP=1.1.1.1, Inner DIP=20.20.1.1) Wi-Fi 망을 통해(AP를 거쳐) ePDG가 수신합니다.
[7] ePDG, P-GW를 거쳐 이 패킷은 olleh TV now 서버로 전달되며, olleh TV now 서버가 수신하는 패킷의 SIP는 1.1.1.1입니다. 그리고 그 패킷의 응답으로 olleh TV now 서버가 송신하는 패킷의 DIP는 1.1.1.1이 되고, 이 패킷은 P-GW로 라우팅되어 P-GW와 ePDG간 GRE 터널, ePDG와 UE간에 IPSec 터널을 통해 단말로 전달됩니다.

 

홍석환 2012-05-23 09:44:35
마지막 그림을 보니 한눈에 이해가 쏙 되네요.

늘 감사드립니다.
정구열 2012-05-23 12:03:07
좋은 정보 감사 드립니다.

궁금한 사항이 있는데, 이 기능이 실제로 상용화 되려면 단말이 IPsec을 지원해야 합니다.
그런데 제가 알기로는 안드로이드나 아이폰에는 IPsec이 지원 안되는 걸로 알고 있는데요,
향후에 이런 기능이 상용화가 가능할까요 ?
넷매니아즈 2012-05-23 13:53:55
애플과 구글의 정책이 어떨지는... 저희 범위 밖이네요 -.-;;

다만 넷매니아즈에서 작년 가을 경에 이와 유사한 컨설팅을 진행한 적이 있는데요.
해외 통신사업자가 WiMAX와 Wi-Fi 간에 핸드오버를 하려 했고, 그 사업자는 대만의 어떤 벤더로 부터 안드로이드 기반의 스마트폰을 제공받기로 했습니다.

망쪽 이슈: WiMAX 표준을 정의하는 WiMAX Forum에서는 아직 Wi-Fi와의 연동 규격을 release하지 못하고 있어 3GPP의 ePDG를 좀 응용하여(비표준적으로) ASN-GW와 ePDG간에 PMIPv4 연동, 그리고 ePDG와 단말간에 IKEv2/IPSec으로 연동을 시키도록 하였습니다.

단말 이슈: 안드로이드폰에 IKEv2/IPSec 스택이 필요하고, 또 하나 아주 중요한 건 WiMAX와 Wi-Fi 수신 신호(RSSI등)를 감지하여 Handover Decision을 해 줄 수 있는 software(Handover Manager)가 단말에 올라가야 합니다.
그리고 이건 엡 형태가 아닌 Kernel driver 형태로 들어가야 하는 것으로 알고 있구요.
그래서 단말 소프트웨어 개발사를 통해 위와 같이 1) IKEv2/IPSec 스택 2) Handover Manager를 외주 개발 시키도록 하려 했습니다.

참고로 위 작업은 설계(Design) 까지는 진행되었으나 이후 테스트(PoC), 구축(Deploy), 서비스 개시(Service Launch)는 되지 못한 것으로 알고 있습니다.

따라서 통신사업자에서 LTE/Wi-Fi 연동(핸드오버) 서비스를 하려 한다면 자체(외주) 개발된 IKEv2/IPSec 및 Handover Manager가 포함된 스마트폰을 가입자들에게 공급할 것으로 생각합니다.

하지만 이건 안드로이드 계열에서나 가능할 것이고, 아이폰의 경우 iOS가 오픈 소스가 아니라서 애플이 해 주지 않는 한 불가능 할 듯 하네요.
호릴라 2012-05-23 14:45:14
위의 정확한 답변에 첨언하자면, 아이폰은 안될것 같구요, 안드로이드폰은 가능할 것 같습니다. 물론, 안드로이드폰이라고 하더라도 제조사가 해당폰에 위에서 언급한 단말의 기능을 탑재하느냐 마느냐에 대한 결정이 있어야 할 것 같구요, 결론적으로는 안드로이드폰에서 기술적으로는 가능하다는 말입니다. 단말 제조사의 경우 해당 기능을 단말에 탑재할 경우 해당폰은 글로벌하게 범용폰이 안되고 특정 사업자에 종속되는 특정폰이 되므로, 단말 라인을 별도로 하나를 잡아야하는 부담이 생길겁니다. 따라서, 반가워 할 일은 아니지요.
한영선 2013-10-08 18:47:09
안녕하세요. 반갑습니다.
좋은 정보 감사드립니다.
LTE에서 3G Offload 기능에 대해 자세한 설명좀 부탁드립니다.
Eric Y. Kim 2013-11-27 16:51:29
정말 엄선되고, 명쾌한 자료입니다. 감사드립니다. 저희팀도 덕분에 많은 도움이 되었습니다.

저희는 Data offload를 ePDG나 IPSEc을 이용하지 않고 구현했습니다. 내년1월에는 외국이통사에서
Wimax <-> TD-LTE 간 Data offload와 seamless handover 를 테스트할 예정입니다.

가장큰문제는 chip 제조사와 일해야하는 문제였구요...이통사는 가능한 폰의존성을 없애야만 독자적으로
수행할 수 있어서....2년동안 엄청삽질...

다행이 메이져 chip 제조사는 아니지만 기술력좋은 회사와 협력하게되어 ..그나마..기술을 입증할 수 있었습니다.
퀄컴같은데가 붙으면 가장좋지만....ㅎㅎ ...
Hyo-Geun Ahn 2014-07-17 15:28:07

안녕하세요~ 자료 잘 봤습니다. 저같은 초보자도 이해하기 쉽도록 잘 작성하셨네요~

한가지 궁금한게 있어서 댓글을 남기는데요.

혹시 ePDG를 통한 Offloading을 위해서는, 망(사업자 Network)에서 물리적인 ePDG를 설치해야하는건 알겠는데요,

UE에서는 지원해야하는 기술이 있나요? CP쪽 Offloading을 위한 SW라던가, 아니면 HW적으로 필요한 장치가 있는거 해서요~

혹시 그렇다면 어떤 CP에서 지원하는지도 알 수 있을까요.

감사합니다.

Junhyuck Park 2015-07-13 16:05:43

안녕하세요. 궁금한게 있는데 답변이 달릴지 모르겠네요. 일단 WiFi가 ePDG를 이용해 패킷을 전송받을 때 Remote Host 쪽에서 DIP가 1.1.1.1 이라고 하셨는데 PGW쪽에서는 어떤 기준으로 GTP를 이용할지 GRE를 이용할지 판단을 하나요 ? 똑같은 1.1.1.1일텐데 PGW가 eNB로 GTP를 이용해서 패킷을 전송해도 UE쪽으로 전송되지 않는건지 

버너 2015-07-15 12:33:45

1) 단말이 eNB에 연결되어 있다가 ePDG쪽으로 연결을 전환하면 LTE에서는 이를 SGW~SGW간의 H/O와

  유사한 형태의 SGW~ePDG 간의 Handover 처리를 하게 되고 H/O 시그널링 과정에 PGW가 직접적으로

  개입을 하기 때문에  PGW에서 ePDG/eNB(SGW)중 어느쪽에 단말이 연결되어 있는지 알 수밖에 없습니다.  

2) 참고로 PGW~ePDG간 인터페이스는 초기 양 노드 구성 시 프로토콜을 GTP/GRE중 하나만을 선택하여

  구성합니다.

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
View All (969)
5G (67) 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 (10) 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 (44) 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 (10) 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 파일로 다운로드

   받으실 수 있습니다. 

     
     

 

     
         
     

 

 

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