오늘은 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가지 타입으로 분류할 수 있습니다.
- KT가 직접 가입자에게 제공하는 서비스 (예. olleh TV now)
- KT와 전혀 상관없는 서비스 (예. YouTube, 네이버, 다음 등등)
어떤 서비스가 더 중요할까요? 당연히 1번이죠(KT 입장에서).
따라서 1번 서비스(이하 olleh TV now)의 경우, Wi-Fi에 접속한 가입자도 ePDG/P-GW를 거쳐 서비스를 받을 수 있도록 하고 이로 인해 본 서비스에 대해서는 LTE/Wi-Fi 망간에 핸드오버가 됩니다. 즉,
2번 서비스(이하 YouTube)의 경우, Wi-Fi에 접속한 가입자는 AP에서 바로 IP network을 타고 YouTube로 갑니다. 즉, ePDG/P-GW를 거치지 않으며 따라서 본 서비스에 대해서는 LTE/Wi-Fi 망간에 핸드오버가 되지 않습니다. 즉,
이와 같이 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 패킷은 다음과 같습니다.
이 패킷은 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 패킷은 다음과 같습니다.
이 패킷은 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 터널을 통해 단말로 전달됩니다.
늘 감사드립니다.
궁금한 사항이 있는데, 이 기능이 실제로 상용화 되려면 단말이 IPsec을 지원해야 합니다.
그런데 제가 알기로는 안드로이드나 아이폰에는 IPsec이 지원 안되는 걸로 알고 있는데요,
향후에 이런 기능이 상용화가 가능할까요 ?
다만 넷매니아즈에서 작년 가을 경에 이와 유사한 컨설팅을 진행한 적이 있는데요.
해외 통신사업자가 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가 오픈 소스가 아니라서 애플이 해 주지 않는 한 불가능 할 듯 하네요.
좋은 정보 감사드립니다.
LTE에서 3G Offload 기능에 대해 자세한 설명좀 부탁드립니다.
저희는 Data offload를 ePDG나 IPSEc을 이용하지 않고 구현했습니다. 내년1월에는 외국이통사에서
Wimax <-> TD-LTE 간 Data offload와 seamless handover 를 테스트할 예정입니다.
가장큰문제는 chip 제조사와 일해야하는 문제였구요...이통사는 가능한 폰의존성을 없애야만 독자적으로
수행할 수 있어서....2년동안 엄청삽질...
다행이 메이져 chip 제조사는 아니지만 기술력좋은 회사와 협력하게되어 ..그나마..기술을 입증할 수 있었습니다.
퀄컴같은데가 붙으면 가장좋지만....ㅎㅎ ...
안녕하세요~ 자료 잘 봤습니다. 저같은 초보자도 이해하기 쉽도록 잘 작성하셨네요~
한가지 궁금한게 있어서 댓글을 남기는데요.
혹시 ePDG를 통한 Offloading을 위해서는, 망(사업자 Network)에서 물리적인 ePDG를 설치해야하는건 알겠는데요,
UE에서는 지원해야하는 기술이 있나요? CP쪽 Offloading을 위한 SW라던가, 아니면 HW적으로 필요한 장치가 있는거 해서요~
혹시 그렇다면 어떤 CP에서 지원하는지도 알 수 있을까요.
감사합니다.
안녕하세요. 궁금한게 있는데 답변이 달릴지 모르겠네요. 일단 WiFi가 ePDG를 이용해 패킷을 전송받을 때 Remote Host 쪽에서 DIP가 1.1.1.1 이라고 하셨는데 PGW쪽에서는 어떤 기준으로 GTP를 이용할지 GRE를 이용할지 판단을 하나요 ? 똑같은 1.1.1.1일텐데 PGW가 eNB로 GTP를 이용해서 패킷을 전송해도 UE쪽으로 전송되지 않는건지
1) 단말이 eNB에 연결되어 있다가 ePDG쪽으로 연결을 전환하면 LTE에서는 이를 SGW~SGW간의 H/O와
유사한 형태의 SGW~ePDG 간의 Handover 처리를 하게 되고 H/O 시그널링 과정에 PGW가 직접적으로
개입을 하기 때문에 PGW에서 ePDG/eNB(SGW)중 어느쪽에 단말이 연결되어 있는지 알 수밖에 없습니다.
2) 참고로 PGW~ePDG간 인터페이스는 초기 양 노드 구성 시 프로토콜을 GTP/GRE중 하나만을 선택하여
구성합니다.
안녕하세요
WiFi 망을 5G 또는 LTE 망으로 전환 하는 방법에 대해서 공부하고 있는데,
1. Wifi 망을 사용하다가 무선 신호가 특정 세기 이하로 떨어지는 경우에 LTE 망으로 전환
2. 최소 대기 시간에 망 전환을 하며, 유료 공중망인 LTE망 사용을 최소화 할 수 있는 기술
3. 망 전환에 따른 패킷 손실 시에 재전송 효율을 높일 수 있는 기술
이 조건들을 갖고 망 전환을 하기 위해선 필요지식이 무엇이고, 관련 논문이 있을까요?