본 블로그 글은 “LTE와 Wi-Fi간의 병합”이라는 주제의 두 번째 글로, 첫 편인 3GPP 기반 병합에 이어 Non-3GPP 기반 병합에 관해 다루도록 하겠습니다. 

 

Non-3GPP 기반 (단말이 3GPP LTE망과 독립적으로 병합 수행)

 

ePDG나 TWAG, DSMIPv6 HA와 같은 LTE 네트워크의 특정 노드를 활용하지 않고 단말에 의한 독립적인 LTE와 WLAN간의 트래픽을 병합하는 방법은 최근 단말의 LTE / WiFi Dual On 지원이 확대됨에 따라 주목을 받고 있습니다. 그러나 일부 방법들은 공식적으로 구현 방안에 대한 자료가 제공되지 않는 기술이라 간략하게 구현 기술에 대한 추정 내용만을 정리합니다.

• IETF 표준상의 MPTCP (Multi-Path TCP)
• 삼성의 Download Booster 기술 (추정)
• 응용계층 기반의 Proxy를 이용한 기술 (추정)

1. IETF 표준상의 MPTCP를 이용한 LTE/WLAN 병합

그림 1 (a)에 보이는 MPTCP (Multi Path TCP)는 IETF에 의해 2013년 표준화된 기술로 TCP 프로토콜을 확장하여 단말과 TCP 서버간에 다수의 TCP 경로를 구성하고 다수의 경로로 동시에 데이터를 송수신하는 방법입니다. LTE와 WLAN과 같이 이종망을 다중 경로로 구성하는 경우에는 WLAN과 LTE간의 Carrier Aggregation 효과를 얻을 수 있는 구조라고 할 수 있습니다.

 

그림 1. IETF 표준상의 MPTCP (Multi-Path TCP)

 

❶ MPTCP에서 TCP는 Subflow와 MPTCP의 2개의 계층으로 구성됩니다.

❷‚ UE는 통상적인 방법으로 LTE와 WLAN에 동시에 접속하여 각각의 네트워크로부터 IP를 할당 받고, MPTCP의 Subflow를 LTE와 WLAN에서 할당받은 IP 주소를 사용하여 서비스 서버 (MPTCP capable Server) 에 연동하며,

서비스 서버는 MPTCP capable 단말과 연동하여 다수의 Subflow를 이용하여 단말과 하나의 MPTCP 세션을 구성합니다.

„❸ UE와 TCP 서버는 상호 연결된 다수의 MPTCP Subflow를 통해 데이터를 송수신할 수 있으며 MPTCP는 TCP의 확장 헤더를 이용하여 시그널링을 하므로 LTE 및 WLAN 네트워크에서 MPTCP Subflow의 트래픽은 단일 TCP 세션으로 간주되어 정상적으로 중계합니다.

 

MPTCP 구조에서 각각의 Subflow는 하나의 독립적인 TCP 세션으로 동작하여 Subflow 별로 독립적인 TCP 연결 제어 및 폭주제어 기능을 제공하며, TCP의 특징을 그대로 유지하고 있어 NAT 등을 경유하는 경우에도 사용이 가능하고 TCP 가속기나 TCP Proxy 등을 경유하는 경우에도 보편적인 호환성을 유지할 수 있도록 규격적인 고려가 되어 있습니다.

 

또한 상위의 MPTCP 블록은 다수의 Subflow들에 대한 연결 제어 및 Subflow간의 트래픽 분배와 재전송 처리 및 패킷 정렬 기능을 수행하며 다수의 Subflow를 사용한 경우의 폭주 관리 방법 및 데이터 분배 방법과 관련한 부분은 아직 표준화가 진행 중이나 기본적으로는 아래와 같은 방식으로 다수의 경로 운용이 가능합니다.

 

❶ MPTCP Full Mode : 다수의 경로를 모두 사용하여 데이터를 송수신하는 방법으로 LTE/WLAN간 Aggregation을 위해 사용할 수 있는 모드이나, 서로 다른 전달 지연과 대역을 가지는 다중 경로 환경에서의 효율적인 경로간의 트래픽 분배 및 폭주 제어 방안은 아직 표준화된 방법이 없음

❷‚ MPTCP Backup Mode : 다수의 경로를 Primary와 Backup으로 구분하여 Primary 경로가 비가용한 상태에만 Backup 경로를 사용하도록 하는 방식으로 애플의 Siri 서비스가 이 방식을 사용하고 있습니다 (Siri의 경우에는 WLAN을 Primary 경로로 LTE/3G를 Backup 경로로 사용)

❸ƒ MPTCP Single Mode : MPTCP Backup mode와 유사하나 MPTCP Backup Mode의 경우는 Backup 경로도 트래픽이 전달되지 않을 뿐 평상시에도 항상 연결을 유지하고 있으나, Single Mode의 경우에는 Primary 경로가 비가용한 경우에 Backup 경로의 연결을 생성한다는 점에서 차이가 있습니다.

 

MPTCP에 대한 OS의 공식적인 지원은 아직 되지 않고 있으나 기존의 TCP 기반 서비스 서버를 이용하여 LTE/WLAN간의 Aggregation 효과를 얻기 위한 방법으로 MPTCP Proxy를 구성하는 방안(그림 1(b))은 시도가 되고 있습니다.

• 윈도우의 MPTCP 지원 : 미지원
• iOS 단말의 MPTCP 지원 : Siri에서 사용 중이나 iOS 기반의 3rd 어플리케이션에 대한 API  공개 여부는 불분명
• 리눅스의 MPTCP 지원 : 공식 배포판에는 포함되어 있지 않으나 MPTCP를 위한 OS 및 소켓 API 패치는 오픈소스 형태로 공개
• 안드로이드의 MPTCP 지원 : 리눅스용 MPTCP 패치를 삼성을 포함한 다수의 안드로이드 기반 단말에 포팅한 사례는 있으나 단말 제조사의 공식적인 지원 여부는 불분명

MPTCP와 유사하게 다중 경로를 사용하는 프로토콜로는 LTE 내부에서도 광범위하게 사용되고 있는 SCTP(Stream Control Transmission Protocol)가 있습니다. SCTP의 경우에도 MPTCP와 유사하게 다중 경로를 구성하여 Aggregation 효과를 볼 수 있고 TCP와 UDP 특성의 트래픽을 모두 수용할 수 있으며 리눅스의 경우에는 기본 프로토콜로 이미 포함되어 있다는 장점이 있습니다.

 

그런데, SCTP의 경우에는 UE가 사용되는 일반적인 네트워크 환경인 NAT 환경하에서 NAT 장비에 의한 NAPT 기능이 범용적으로 제공되지 않기 때문에 MPTCP에서 개별 경로를 구성하는 TCP보다는 네트워크에서의 전달계층 호환성 측면에서는 MPTCP가 SCTP에 비해 상당히 장점을 가진다고 할 수 있습니다.

 

MPTCP를 이용한 LTE/WLAN의 병합 방법은 LTE 또는 WLAN 네트워크의 노드의 지원 없이 단말과 서비스 서버가 직접 다수의 경로를 구성하여 경로간의 Aggregation 효과를 만들 수 있으며 OTT 서비스 제공자가 통신 네트워크의 의존성을 가지지 않고 사용할 수 있다는 장점이 있습니다.

 

그러나, MPTCP는 TCP에 대한 다중 경로만을 제공하고 단말에 대한 IP 유일성을 제공하지 못하므로 VoIP와 같이 IP 주소를 단말/서비스의 식별자로써 사용하는 서비스에는 사용할 수 없고 단말/서비스 식별자를 Layer 4 이상의 계층에서 별도로 관리하는 HTTP와 같은 경우에만 제한적으로만 사용이 가능하다는 단점이 있습니다(물론 이 경우에도 보안 또는 서비스 로직의 구성상의 이유로 IP를 접근 제어 또는 가입자 식별자로 사용하는 경우도 있으며 이 경우에는 사용이 불가능할 수 있습니다).

 

[참고] 아래 동영상은 올해 10월에 부산에서 열린 ITU-T 전권회의 때 SK Telecom이 시연한 MPTCP 데모 영상입니다.

 

2. 삼성의 Download Booster를 이용한 LTE/WLAN 병합

삼성의 Download Booster 구조는 삼성이 MWC 2014에서 Galaxy S5 시리즈에 적용하였다고 발표한 기술로, LTE를 지원하는 단말이 LTE와 WLAN에 동시에 접속되어 있는 경우 HTTP를 이용한 파일 전송을 LTE와 WLAN을 사용하여 동시에 다운로드 받을 수 있도록 함으로써 LTE와 WLAN간의 Carrier Aggregation 효과를 얻을 수 있는 구조를 제공합니다.

 

본 방법에 대한 상세한 구현 방안은 공개되어 있지 않으나 관련 기능에 대한 삼성의 소개 등을 기반으로 기술의 구현 방법을 추정해 본다면, 본 기술은 HTTP에서 파일의 분할 전송, 부분 전송등을 위해 사용하는 Range Retrieval Request 기능에 대한 일종의 Transparent 형태의 HTTP Range Retrieval Proxy 기능을 단말의 OS 또는 Framework내에 내장한 것으로 보입니다.

 

또 어플리케이션에서 HTTP Range Request를 이용한 파일 다운로드 요청이 있는 경우 HTTP Range Retrieval Proxy에서 이 요청을 LTE와 WLAN으로 각각 분리된 TCP 세션으로 서로 다른 범위에 영역에 대해 분할 전송을 수행한 후 분할 수신된 내용을 정렬하여 어플리케이션으로 전달하도록 하는 것으로 추정됩니다.

 

그림 2. 삼성 Download Booster

 

이러한 방식의 TCP 경로를 다중화하여 분할 전송을 하는 방법은 MPTCP의 Subflow 구성과 유사하나 본 방법의 경우에는 삼성의 자료에서도 나타나듯이 구글 플레이스토어 및 유투브 비디오, 페이스북과 같은 HTTP Range Retrieval을 이용한 파일 전송 방식을 사용하는 서비스에 대해 기존의 HTTP 기반 단말 어플리케이션이나 HTTP 기반 서버, OS내의 TCP 프로토콜을 수정하지 않고도 Carrier Aggregation의 효과를 볼 수 있다는 장점이 있습니다. 

 

그러나, 음성/영상 스트리밍 서비스와 같이 HTTP를 이용한 실시간 데이터를 전송하거나 HTTP Range Retrieval을 사용하지만 HTTPS를 사용하여 End-to-End 암호화를 사용하는 서비스에서는 적용이 어렵다는 제한이 있고 HTTP Range Retrieval Request 기능에 의존적이므로 보편화하여 사용할 수는 없는 방법입니다.

 

3. 응용계층 기반의 Proxy를 이용한 LTE/WLAN 병합

삼성의 Download Booster 구조가 HTTP Retrieval Request 방식에 특화되어 있고 단말의 OS 또는 프레임워크의 변경이 필요하다는 점에서 응용계층에서 LTE/WELAN을 병합하는 구조는 단말에 어플리케이션 형태로 설치되는 Proxy를 제공함으로써 설치 및 변경의 용이성과 대상 UE의 범용성을 제공하며 HTTP 뿐만 아니라 좀 더 다양한 형태로 LTE와 WLAN간의 Carrier Aggregation 효과를 볼 수 있는 구조를 제공합니다.

 

그림 3. 응용계층 기반의 Proxy를 이용

 

❶ 단말내의 어플리케이션은 응용계층으로 구현된 Proxy 어플리케이션을 통해 간접적으로 서버와 통신합니다.

❷‚ Proxy는 단말 어플리케이션과 서버 사이의 TCP/UDP 접속을 대행하며 단말의 LTE 및 WLAN의 접속 상태에 따른 연결 관리를 수행하고 어플리케이션의 데이터 특성에 따라 맞춤형의 LTE/WLAN 병합 기능 (Primary/Backup 또는 Aggregation 등)을 수행하여 서버와의 다중 경로에 대한 관리를 수행합니다.

❸ƒƒ 서비스 서버는 기능 제공을 위한 별도의 기능 추가/변경이 없다는 것을 전제로 합니다.

 

이 방법은 또한 MPTCP처럼 OS의 프로토콜 지원 여부에 대한 의존성이 없고 TCP뿐만 아니라 UDP 등의 좀 더 다양한 프로토콜에 대한 지원이 가능할 수 있다는 점에서 장점을 가지고 있으나, 단말의 서비스 어플리케이션이 Proxy와 통신을 해야 하므로 Proxy에 대한 의존성을 가진다는 단점이 있습니다.

 

각 병합 방법 별 비교

 

지금까지 2편의 블로그글 (1편은 3GPP 기반 병합)에 걸쳐 LTE 네트워크 인프라를 이용 (3GPP 기반)하거나 또는 단말이 LTE망과 상관없이 LTE/WLAN의 병합(Non-3GPP 기반)에 대한 간략한 리뷰를 진행했습니다.

 

개별 방법의 내용상에는 자세히 언급이 되어 있지 않지만 LTE 네트워크 인프라를 이용한 LTE/WLAN의 병합 방법은 기본적으로 단말에게 접속 네트워크의 변동에 관계없이 단말 IP 주소의 유일성을 지속적으로 제공하고 IP의 유일성을 제공하기 위해 P-GW 및 DSMIPv6 HA 노드가 단말에 대한 IP 종단점을 제공하면서 안정적인 이동성을 제공하는데 반해,

 

단말 독립적인 병합 방법은 단말의 IP 주소에 대한 유일성을 제공하지 않는다는 점에서 구조적인 큰 차이가 있습니다.

 

또한 단말 기반의 병합 방법에서 단말이 다수의 유동적인 IP 주소를 사용하여 이종 RAN간의 병합의 시도가 가능한 것은 기본적으로 LTE라는 광역적인 이동성을 제공하는 안정적인 무선 인프라가 광역적인 이동성을 제공하는 하나의 고정된 축으로 사용하기 때문에 가능하다고 할 수 있습니다.

 

마지막으로 상기에서 기술한 방법들에 대해 병합이라는 관점으로 다양한 부분의 장단점을 정리하여 요약해보면 아래와 같이 정리할 수 있습니다.

• IP 유일성 : LTE 및 WLAN 등의 접속망 변화에 따른 IP 주소의 연속성 제공 여부
• 적용 대상 : 병합의 대상이 될 수 있는 패킷 형태
• 패킷 연속성: 본 문서에서 검토한 기술들은 기본적으로 "광역적인 이동성"을 제공하는 여러 가지 기술들을 정리하였으나, LTE와 WLAN간의 상호 연동은 근본적으로 LTE 내부에서 이동성을 제공하기 위한 eNB와 S-GW, P-GW간의 유기적인 관계(S1/X2 Handover)를 제공할 수 없으므로 패킷 유실이 발생하지 않는 Seamless Handover를 제공할 수 없습니다만, 망의 전환에 따른 송수신 패킷의 유실 가능성에 대한 주관적인 견해를 정리합니다 (구현 및 최적화에 따라 달라질 수 있습니다)
• 단말 요소: 단말에 필요한 기능 요소를 나타내며 안드로이드 플랫폼을 기준으로 해당 구성 요소의 구현 위치에 따라 App(응용 어플리케이션 형태로 구현 가능) 또는 OS (OS 또는 단말의 프레임워크내에 구현 필요)로 구분합니다

​

1) 서비스 특성 및 Proxy 구현에 의존적일 수 있음

2) WLAN 변경 (AP 및 IP 변경) 후 TCP 단절이 발생할 것으로 추정

3) 3GPP 표준 IFOM인 경우에만 해당하며 독립형 IFOM의 경우 사용하지 않을 수 있음

 

 

기고글을 보내주신 멀티플레이어님께 감사드립니다.