| 리포트 | 기술문서 | 테크-블로그 | 글로벌 블로그 | 원샷 갤러리 | 통신 방송 통계  | 한국 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간의 연동 및 병합 기술(2): Non-3GPP기반
Integration of LTE and Wi-Fi Networks (2): Non-3GPP based
November 08, 2014 | By 멀티플레이어
코멘트 (6)
11
 

  [기고] LTE와 Wi-Fi간의 연동 및 병합 기술

 

    1편. 3GPP 기반 (LTE 네트워크 인프라를 이용한 LTE와 와이파이간 병합)

3GPP 표준상의 ePDG (Evolved PDN Gateway) 

3GPP 표준상의 TWAG (Trusted WLAN Access Gateway) 

3GPP 표준상의 IFOM (IP Flow Mobility) 

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

IETF 표준상의 MPTCP (Multi-Path TCP)

삼성의 Download Booster 기술 (추정)

응용계층 기반의 Proxy를 이용한 기술 (추정)

 

본 블로그 글은 “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의 경우 사용하지 않을 수 있음

 

 

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

 

진보람 2014-11-08 16:45:21

깔끔한 정리 감사합니다. 헌데, 여러군데 오타가 많아서 좀 더 수정해 주시면 감사할 것 같습니다. 특히, 패킷 연속성 부분은 알수가 없습니다. "여러 가지 기술들을 정리하였으나와간의 상호 연동은 근본적으로 내부에서 이동성을 제공하기 위한와간의 유기적인 관계를 "

Netmanias 2014-11-10 11:51:59

진보람님,

 

코멘트 감사드립니다. 오류를 수정하였습니다.

앞으로도 많은 관심을 부탁드립니다.

Yoo 2015-07-26 19:20:59

MP-TCP와 SCTP 비교글을 보면 SCTP는 NAT 환경에서 문제가 있다는 내용이 항상 나오는데요.

잘 아시는분께서 이부분에 대해 자세히 설명 부탁드립니다.

버너 2015-07-29 18:55:41

프로토콜 내부를 봐야 하는 부분이라 설명이 길어질 것 같아

상세 내용이 빠진 상당히 간략한 컨셉 차원에서만 대표적인 문제만 예를 들어 설명을 드립니다.

 

단말을 MPTCP 클라이언트 (TCP 클라이언트가 되겠죠) 또는 SCTP 클라이언트라고 하고

IP는 C1, C2를 가졌다고 가정을 하고

서버는 MPTCP 서버 (TCP 서버가 되겠죠)또는 SCTP 클라이언트라고 가정하고

IP는 S1, S2를 가지면서 5000 번 포트로 수신 대기를 하고 있다고 한다면

 

1. 다중 경로를 식별하는 방식의 차이점

- MPTCP에서 다중 경로를 구성할 때 서버의 Port 번호만 동일하면 단말은 임의의 IP&Port의 조합을 사용해도

  됩니다.

  (단말은 S1 또는 S2의 5000번 포트로만 접속을 하면 C1, C2의 포트를 어떻게 써도 상관 없음)

  C1:1000 ~ S1:5000 + C2:1000 ~ S1:5000 : 가능

  C1:1000 ~ S1:5000 + C1:1001 ~ S1:5000 : 가능

  C1:1000 ~ S1:5000 + C2:1234 ~ S2:5000 : 가능

  Cx:xxxx ~ Sx:5000 + Cy:yyyy ~ Sy:5000 : 가능

- SCTP에서 다중 경로를 구성할 때는 서버의 Port 번호와 단말의 Port 번호가 모두 같아야 합니다.

  즉 S1, S2의 포트가 MPTCP처럼 동일해야 할 뿐만 아니라 C1, C2의 포트도 동일해야만 합니다.

  C1:1000 ~ S1:5000 + C2:1000 ~ S1:5000 : 가능 (단말과 서버의 포트가 IP에 관계없이 고정적)

  C1:1000 ~ S1:5000 + C1:1001 ~ S1:5000 : 불가능

  C1:1000 ~ S1:5000 + C2:1234 ~ S2:5000 : 불가능

  Cx:xxxx ~ Sx:5000 + Cy:yyyy ~ Sy:5000 : 불가능

 

- SCTP는 상대방을 “서로 다른 IP + 하나의 Port”로 식별하며, 경로를 추가할 때 기본적으로는 추가할 IP를

  상대방에게 전달합니다.

- MPTCP에서는 상대방을 고유한 KEY를 이용해서 식별하고, 경로를 추가할 때 IP가 아닌 첫번째 경로 생성시

  상호간에 주고받은 KEY를 이용합니다. (KEY 정보는 TCP의 확장헤더를 사용해서 전달합니다)

 

결국은

- NAT 장치가 SCTP에 대한 NAPT를 수행한다면 단말이 추가적으로 사용하고자 하는 다른 경로에 있을지

  없을지 모르는 NAT 장비와 Port 변환 정보를 교환할 수도 없는 상황이 발생합니다.

- NAT 장치가 NAPT를 하지 않고 Port 번호를 그대로 전달한다면 NAT 1대당 1개의 단말만 SCTP를 사용할

  수 밖에 없을 가능성이 높습니다.

 

2. 공유기의 지원 문제

상용 유무선 공유기는 모두 UDP/TCP에 대한 NAPT를 CPU가 아닌 HW에서 처리합니다.  

포트 변환 및 체크섬 재계산, 패킷 중계등의 제반 프로세싱을 모두 HW가 합니다.

SCTP에 대한 NAPT를 HW로 제공하는 공유기 칩셋은 못 본 것 같네요.

SCTP에 대한 NAT를 하려면 CPU에서 해야 하는데 일반인들이 가진 공유기의 CPU 파워로는

TCP/UDP에 대한 NAPT 만큼 SCTP NAT 성능이 나오질 않습니다

 

결론은.. 어떻게 해도 사용하기가 불편할 수 밖에 없는 게 SCTP고,  

SCTP가 만들어질 때는 NAT는 고려되지 않았다가 나중에 NAT 관련한 규격을 추가적으로 만들고 있는 게 현실이고

(아직 Draft입니다) 

MPTCP는 처음부터 NAT 환경에서 쓸 목적으로 NAT 장치들을 벤치마킹 해가면서 만든 프로토콜입니다. 

Yoo 2015-08-04 09:25:15

버너님~ 상세한 답변 감사합니다.

김한수 2016-01-06 13:57:44

항상 좋은 글 감사드립니다. 오래전에 올리신 글인데 이제야 보게되었네요.

WiFi + LTE간 병합을 위한 여러가지 기술들에 대해서 설명을 해주셨는데요. 우리나라에서는 통신 3사가 다양한 이름으로 MPTCP을 서비스한다는 것은 뉴스로 접한 것같습니다.

혹시 다른 기술에 대해서도 사용하고 있는 사례가 있는지 알려주실 수 있는지요?

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
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 파일로 다운로드

   받으실 수 있습니다. 

     
     

 

     
         
     

 

 

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