MISTERY

Introduction

GPRS Tunneling protocol is an important IP/UDP based protocol used in GSM, UMTS and LTE core networks. It is used to encapsulate user data when passing through core network and also carries bearer specific signalling traffic between various core network entities. This protocol has several advantages which will be discussed later.


GPRS Tunneling Protocol Types



 

Why is GTP used in LTE?

  • It provides mobility. When UE is mobile, the IP address remains same and packets are still forwarded since tunneling is provided between PGW and eNB via SGW 
  • Multiple tunnels (bearers) can be used by same UE to obtain different network QoS
  • Main IP remains hidden so it provides security as well
  • Creation, deletion and modification of tunnels in case of GTP-C

GTP Interfaces in LTE

In LTE, version 2 is used for GTP-C and version 1 is used for GTP-U
In simple LTE network implementation, GTP-v2 is used on S5 and S11 interfaces and GTPv1 is used on S1-U, S5, X2-U interfaces (as shown below). In inter-RAT and inter PLMN connectivity, S3, S4, S8, S10, S12 and S16 interfaces also utilize GTP protocols

How GTP-U Works ?

GTP-U encapsulation of UE user plane traffic can be easily understood by taking any simple example. Lets see what happens when IP packet generated by UE reaches to eNodeB and is then forwarded to SGW.

Consider any application on UE creates an IP/TCP packet. This packet consist of actual data by application, TCP or UDP header and then IP field information which has source address of UE and destination address of application server (e.g. Facebook)

When the eNodeB receives this packet over air interface, it will put the IP packet inside GTP header which has information related to tunnel IDs. Then further, it is encapsulated inside UDP and IP header and forwarded as ethernet frame towards SGW. Here the IP header contains eNodeB IP as a source address and SGW IP as a destination address

GTP-C signalling messages

As GTP-Cv2 in LTE is used for tunnel management, some of the signalling messages are listed below which use GTP-Cv2 protocol 



Please check Table 6.1-1(3GPP TS 29.274) for more detailed list of GTP-C based messages.

 

 

 

 

 

 

 

 

출처 : http://4g-lte-world.blogspot.kr/2013/03/gprs-tunneling-protocol-gtp-in-lte.html

 

 

 

 

 

 

 

 

신고

Comment +0

며칠 전 사회에서 알게된 좋은 후배님과 기술 토론 중에 후배님이 아래와 같은 얘기를 한 적이 있습니다.

"무선 통신망에서 가입자가 이동을 하면 IP 라우팅망이 이를 인지하고 자동으로 가입자의 위치로 패킷을 전달하는거 아닌가요?"

이 후배님은 잘못 생각을 하고 있었던 거죠.


그래서 총 3회의 연재에 걸쳐 무선 통신망에서 사용자의 이동성을 위한 터널링에 대해 설명 드리고자 합니다.

   1편: 이동 서비스를 위해 터널링이 필요한 이유

   2편: LTE, WiBro, Wi-Fi의 Tunneling 기술

   3편: IP 라우팅 관점에서의 LTE 핸드오버


오늘은 이 중에 "1편: 이동 서비스를 위해 터널링이 필요한 이유"입니다.


유선 통신망: IP Network


위 그림은 유선망을 통한 인터넷 통신을 보여 주고 있습니다. 

Router에는 3개의 Interface(ge1, ge2, ge3)가 있고, 각 Interface는 서로 다른 네트워크(10.1.1.0/24, 20.1.1.0/24, 30.1.1.0/24)에 속해 있습니다. (예: ge1에는 10.1.1.254/24, ge2에는 20.1.1.254/24, ge3에는 30.1.1.254/24가 설정됨)

유선 단말(PC)이 사용하는 IP 주소는 그 단말의 위치에 따라 그 네트워크 대역이 결정 됩니다. 위 그림처럼 PC1의 경우 10.1.1.0/24 대역의 네트워크와 연결이 되면 이 PC는 그 대역의 IP 주소 중에 하나인 10.1.1.5/24를 할당 받아(DHCP) 사용하게 됩니다.


만약 PC1이 그 IP 주소를 그대로 유지한 상태에서 20.1.1.0/24 대역의 네트워크로 위치를 옮긴다면(예를 들어, PC1에 고정 IP 주소 10.1.1.5/24를 설정하고 PC2 자리로 이동) 더 이상 통신은 불가능 합니다. 왜냐면 Router는 Destination IP 주소가 10.1.1.5인 패킷은 무조건 10.1.1.0/24 대역에 속한 Interface인 ge1으로 포워딩하기 때문이죠.


그렇다면 PC의 IP 주소를 20.1.1.0/24 대역 중에 하나로 변경하면 통신이 되지 않겠습니까? 당연히 됩니다.

하지만 단말의 IP 주소가 변경되는 순간, 인터넷과 통신하던 단말내의 모든 응용 프로그램들은 IP 주소 변경으로 인하여  Connection이 끊기게 됩니다.


결론적으로 말씀드리고자 하는 포인트는 "IP 라우팅 망에서 단말의 IP 주소 대역은 곧 단말이 위치하는 곳에 따라 결정되어 지고, IP 라우팅 망은 단말의 이동성은 모른다(관심없다)." 입니다.


무선 통신망: Mobility over IP Network



현재 대표적인 무선 통신망은 LTE, WiBro 그리고 Wi-Fi입니다. 단말의 이동성을 위해 기지국과 코어장비간에 터널링을 해 준다는 개념에서 위 3개의 기술은 모두 동일합니다.


하부에 IP Network이 있고, 그 위에 Mobile Network이 존재하게 됩니다.

그래서 L2 Switch에 가입자 PC가 아닌 기지국(LTE: eNB, WiBro: BS, Wi-Fi: AP)이 연결되고, 각 기지국에는 그 위치에 따라 IP 주소가 설정되게 됩니다. (예: 10.1.1.0/24 네트워크와 연결된 기지국은 10.1.1.5를 설정)

그리고 Router에는 IP Anchor 장비(LTE: P-GW, WiBro: ASN-GW, Wi-Fi: AP Controller)가 연결이 되게 됩니다.


단말(SmartPhone)이 10.1.1.5 기지국에 연결이 되고 IP Anchor 장비로 부터 IP 주소 1.1.1.8을 할당받으면, 10.1.1.5 기지국과 IP Anchor 장비간에는 이 단말을 위한 터널(LTE: GTP tunnel, WiBro: GRE tunnel, Wi-Fi: Vendor specific tunnel(비표준))이 생성되게 됩니다(LTE, WiBro의 경우 단말마다 터널이 생성됨). 위 그림에서는 Tunnel 1이 되겠죠.

이 상황에서 인터넷(YouTube 서버)에서 1.1.1.8 단말로 패킷이 오는 경로는 아래와 같게 되며,

  • Internet(YouTube) -> Router -> IP Anchor -> Router (ge1 port) -> Switch -> 10.1.1.5 기지국 -> 단말

IP Anchor에서 10.1.1.5 기지국까지는 터널이 형성되어 IP Network에서는 가입자의 IP 주소가 아닌 터널의 IP 주소 즉, 기지국의 IP 주소인 10.1.1.5를 보고 패킷 포워딩이 됩니다. (Router는 ge1으로 패킷 포워딩)


그 상황에서 단말이 20.1.1.5 기지국으로 이동을 하게 됩니다. 그러면 단말의 이동되었음을 IP Anchor 장비가 알게 되며 이에 따라 IP Anchor 장비는 10.1.1.5 기지국과의 터널(Tunnel 1)을 해제하고, 20.1.1.5 기지국과 터널(Tunnel 2)을 생성하게 됩니다. 20.1.1.5와 터널을 생성한다는 의미는 앞으로 단말 1.1.1.8로 가는 패킷에 대해 IP Anchor 장비는 20.1.1.5와 연결된 터널로 패킷을 전달한다는 것입니다.

물론 가입자 단말의 IP 주소는 변하지 않습니다.

이렇게 되면 패킷의 흐름은 아래와 같이 되는 것이죠.

  • Internet(YouTube) -> Router -> IP Anchor -> Router (ge2 port) -> Switch -> 20.1.1.5 기지국 -> 단말


결국 단말의 이동에 따라 터널의 IP 주소가 변경되고, IP 라우팅 망은 가입자의 IP 주소가 아닌 터널의 IP 주소 기반으로 패킷을 포워딩하게 되어 단말은 IP 주소의 변경 없이 IP 망 위에서 자유롭게 이동이 가능하게 됩니다.


다음 시간에는 LTE, WiBro, 그리고 Wi-Fi의 터널링 프로토콜에 대해서 알아 보도록 하겠습니다.



 

 

 

 

 

 

 

 

 

 

 

 

 

출처 : http://www.netmanias.com/ko/?m=view&id=blog&no=5444

 

단언컨데 EPC관련 한국어 자료는 여기가 최고입니다!! 감사합니다. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

신고

Comment +0

GTP-C Interface

Skill/EPC2014.03.20 17:04

3GPP LTE S3 S4 S5 S8 S11 Interface

dsTest® supports the GPRS Tunneling Protocol Version 2 for Control plane (GTPv2-C) message sets over the Evolved Packet Core (EPC) signaling interfaces S3, S4, S5, S8, S11 and S2b.  dsTest also supports GTPv1-C for the GPRS Gn and Gp interfaces.  Test GTP-C initiators (MMEs and SGSNs), and verify responses from gateways (GGSNs, PGWs, and SGWs).  Using our SmartFlow application, you can create simple to complex transaction flows for a specific GTP-C interface, including message definitions and state machine elements.  The SmartFlow can define different paths for success, failure, or other conditions, all defined within the state machine.  The SmartFlow states contains a unique list of states that a GTP-C message flow can traverse.  In addition to the defined messages sets, you can create and customize user-defined message templates to increase the flexibility of test scenarios.  When defining a message template it is only necessary to include and provision the elements whose values will be compared to information in the received message.  Multiple handlers can be used with different templates of the same message type in order to execute various actions or state changes depending on the composition of a received message.

GTP-C node configuration and test scenarios are easily defined and configured with dsClient GUI or  direct XML files that are validated against a published XML Schema to avoid invalid definitions.

A rich set of operational measurements is collected at specified intervals and stored in a SQLite database on the dsTest server.  Real-time measurements may be retrieved through our dsClient CLIinterface or graphed via our dsClient GUI interface.

Implementation

With SmartFlow, you can initiate the following events for a GTP node:

    Create, Modify, Delete GTP tunnel;
    Start a transaction using the selected state flow;
    Force the sending of a message;
    Indicate the receipt of a message;
    Trigger a timeout event on the state machine;
    Indicate the receipt of an unsupported message.
      GTP-C Initiator Simulation

    Verify the reaction of your gateway nodes by simulating a MME or SGSN GTP-C Initiator.  Our SmartFlowapplication provides the ability to createS11 Interface, S5 Interface, S8 Interface, SGW Testing, GTP Initiator GTP-Cv1/v2 state machines and use them in combination with PCC interface applications to test gateway elements in the mobile packet core.  You can use our SmartEvents™ feature with other interface applications to trigger network-initiated events from our Emulators and validate the resulting GTP-C signaling.

    For example, with the S11 interface, test your SGW by initiating default bearer activation from the simulated MME with a Create Session Request.  Verify that your SGW sends the appropriate response and retains the bearer information.  On the S5 interface, simulate bearer activation with a Create Session Request, informing the SGW of the bearer’s attributes in a Create Session Response from the simulated PGW.3GPP LTE S5 Interface, 3GPP LTE S5 Interface, HSS Emulator, PCRF Emulator, OCS Emulator, OFCS Emulator

    In a test of your PGW, initiate default bearer activation from the simulated SGW via the S5 interface.  Verify that the PGW sends a correct Create Session Response, and informs the PCRF of a session establishment and generates a credit request to the OCS.

    Read more about network testing.
    Read more about our GTP Emulators.
    Read more about testing Policy Management.

    GTP-C Responder Simulation

    Simulate GTP-C interfaces to your MME or SGSN GTP-C initiator.  Verify that the initiator correctly3GPP LTE S11 Interface; MME Testing, HSS Emulator, GTP Responderinterprets the gateway GTP-C responses.  For example, simulate bearer activation by initiating an Attach and verify that your MME sends a Create Session Request, and correctly processes the Create Session Response from the simulated SGW.  Verify that your MME retains bearer information and attributes, and, upon location changes, sends a Modify Bearer Request and correctly processes a Modify Bearer Response from the simulated SGW.

    Test the capacity and performance of your MME by using SmartEvents  with other interface applications to trigger network-initiated events and validate the resulting GTP-C signaling.

    Supporting Standards

    GTPv2-C – 3GPP TS 29.274
    GTPv1-U – 3GPP TS 29.281

     

     

     

     

     

    See our Specification Map.

    Read more about dsTest.

     

     

     

     

     

     

     

    출처 : http://www.developingsolutions.com/products/gtp-c-interface/

     

     

     

     

     

    신고

    Comment +0

    LTE Network Entity

    Skill/EPC2014.03.20 10:54

    LTE EPC Architecture

      기존 WCDMA에서 LTE로 넘어오면서 코어망의 일반적인 차이점은 4개의 Node에서 3개의 Node로 줄었다는 것이다. WCDMA에서는 NodeB - RNC - SGSN - GGSN의 구조였으나 LTE로 넘어오면서 eNodeB - MME/SGW - PGW로 3단계로 줄어들었다. 노드가 많을 수록 지연시간이 더 걸리게 되는데 LTE에서는 단계를 줄임으로써 지연시간을 줄였다. 또한 기존 3G는 CS와 PS의 처리를 4개의 노드를 모두 거쳤지만 3.7G부터는 DT(Direct Tunnel)이 생기게되면서 PS의 경우 NodeB - RNC - GGSN으로 연결 되게 되었다. 이렇게 Rel. 7 에서 반영된 결과가 3.8G인 LTE에서도 똑같이 적용 되었다.

     

    eNB (evolved Node B) 

    Radio Resource Management (RRM)

    Radio Bearer control : setup, modifications and release of Radio Resources

    Connection management control : UE state Management. MME-UE connection

    Radio Admission control

    eNB measurements collection and evaluation

    Dynamic Resource Allocation (scheduler)

    IP Header compression/de-compression

    Access Layer security : ciphering and integrity

    MME selection at Attach of the UE

    User Data Routing to the S-GW

    Transmission of Paging Message coming from MME

    Transmission of Broadcast (system info, MBMS)

     

    eNB는 기존 3G에서의 NB의 대체로 Evolved Node B란 뜻이다. eNB의 계층으로 RRC, PDCP, RLC, MAC, PHY가 있으며 L3계층은 RRC L2계층은 PDCH, MAC, PHY L1계층은 PHY로 구성된다.

    RRC : 측정과 연결관리 자원 설정 해소 이동성관리 MIB SIB같은 시스템정보 페이징등 처리

    PDCP : 헤더 압축및 복원 보안관리 HO시 데이터를 버퍼하여 손실없는 HO를 지원

    RLC : PDPC로 부터 받은 데이터를 MAC 계층에서 분할과 재조립, 하위 계층에서의 데이터 전송 실패시 ARQ로 재전송 MAC계층에서의 HARQ수행후 RLC Delivery를 통해 재정렬

    MAC : 베어러에 대해 우선 순위와 자원 배분과 논리 채널로 부터 받은 데이터의 멀티플렉싱과 HARQ 수행

    PHY의 경우 다른 계층과 다르게 관리가아닌 전송을 담당

     

    MME (Mobility Management Entity)

    Non-Access-Stratum (NAS) signalin

    Control Plane NE in EPC

    Roaming control (S6a interface to HSS)

    Trigger and distribution of Paging Message to eNB

    Idle state Mobility Handling

    Tracking Area updates

    Subscriber Attach/detach

    Signalling coordination for SAE Bearer Setup/Release & HO

          Security (Authentication, ciphering, integrity protection)

     

     

    Inter-CN Node signalling (S10 interface), allows efficient inter-MME tracking area updates and Handovers

     

    MME는 이동성 관리 엔티티로 3GPP 네트워크간 이동성 시그널링을 하고 Idle 단말에 대한 위치등록과 페이징 처리 SGW, PGW, SGSN같은 네트워크 selection도 제공한다. 또한 NAS 보안인증과 사용자 인증 제공

    기존 3G에서는 위치정보에 대해 Routing Area라고 하였지만 LTE로 넘어오면서 Tracking Area로 변경이 되었다. 또한 Node B를 담당하던 RNC가 절체시 해당 NB또한 절체되는 문제점이 있었다. 이를 개선하여 RNC기능이 추가된 eNB와 MME는 1:1방식이아닌 N:N방식으로 MME Pooling방식이 지원됨으로써 이동성을 담당하는 MME가 절체 되더라도 다른 MME가 처리를 하게된다. eNB와는 SCTP기반의 S1-AP시그널링 메시지를 처리하고 NAS 시그널링 메시지 또한 SCTP로 처리된다. 또한 HSS와 S6a로 연동을하여 가입자의 정보 다운로드 인증을 수행하며 S-GW와 연동을 하여 GTP-C 프로토콜을 이용한 데이터 라우팅 및 포워딩을 위한 Bearer path의 할당 해제 변경을 요청한다.

     

     

    S-GW (Serving GateWay)

     

     

    Local mobility anchor point : switching the user plane to a new eNB in case of Handover

    Mobility anchoring for inter-3GPP mobility.

     

    Packet buffering and notification to MME for User Idle Mode

     

    Packet routing/forwarding between eNB, P-GW, SGSN

     

    Support lawful interception and charging fuctionalities

     

    S-GW는 eNB와 3GPP간의 로컬 이동성 anchor 포인트가 되며, 핸드오버시 새로운 eNB로 UP의 패킷 데이터를 스위칭 하여 라우팅과 포워딩을 수행한다. 또한 사용자가 Idle 모드시 MME로 패킷 버퍼링과 통지를한다. 업/다운링크의 데이터 패킷 전송 계층을 관리하고 과금기능을 제공

     

     

     

    P-GW (Packet Data Network-Gateway)

    Mobility anchor for mobility between 3GPP access systems and non-3GPP

    Access systems.

    Policy & charging enforcement (PCEF)

    Per user based packet filtering

    Charging support

    Lawful interception support

    IP address allocation for UE

    Packet routing/forwarding between Serving GW and external data network

    Packet screening (Firewall functionality)

     

     

    P-GW는 3GPP와 비 3GPP간의 이동성 anchor를 해주며, PCRF와 연동하여 policy에 따라 과금 및 Bearer QCI 정책을 수행하며, 패킷 필터링기능과 사용자에게 IP할당 S-GW로 패킷 라우팅과 포워딩을 하며 방화벽 기능을 수행한다. 

     

    PCRF (Policy and charging rule fuction)

    QoS policy negotiation with PDN

    Charging policy : determines how packet shoule be accounted

    PCRF to provide policy & charging control (PCC) rules every time a new

     

    bearer has to be  setup

     
    PCRF의 주요 기능은 PDN과 EPS 사이의 Quality of Service (QoS) 조정이다. 그렇기에 PCRF는 Rx 인터페이스를 통해 PDN과 연결된다. 기능에서 PDN의 SAE 베어러의 요청 설정의 QoS와 연관된 베어러 설정은 수정과 체크될 수 있다.

     

     

    HSS (Home Subscriber Server)

    Permenent and central subscriber database

    Stores mobility and service data for every suvscriber

    Contains the Autentication Center (AuC) fuctionality

     


    HSS는 이미 UMTS Rel. 5에서 소개 되었었다. UMTS에서는 HLR과 AUC로 구성 되었으며, HSS는 이 둘을 합친것이다. HSS는 일반적으로 가입자에 대한 데이터와 이동성에 대한 처리를 해준다. 또한 LTE에서의 정보 변경은 MME에서 S6a (Diameter) 인터페이스를 통해 HSS에서 변경이 된다.


     

    Reference

    NSN LTE/EPS Network Architecture

    3GPP TS 23.401 version 10.8.0 Release 10

    Motolora_LTE_and_EPC

     

     

     

     

     

     

     

     

     

     

    출처 : http://encyfic.tistory.com/13

     

     

     

     

     

     

     

     

     

     

    신고

    Comment +0

    IUWMS v1 p111~

    * Understanding Implications of Layer 2 and Layer 3 Roaming

    :모바일 단말은 이동성을 제공하며 이동한 단말에 대한 인지를 해야 합니다.

    이장에서는 로밍 가능한 최적 모델 설명합니다.

       

    1.2.1 Mobility Overview (Mobility: Intracontroller Roaming)

    : 1개의 컨트롤러에 join 된 AP들에 연결된 STA이 이동 할 경우, 10ms 이내 로밍 완료(Seamless Roaming)

    : 컨트롤러에 저장되는 정보 "client MAC and IP addresses, security context and associations,

    quality of service (QoS) contexts, wireless LANs (WLANs), and the associated access point"

       

       

    1.2.2 Intercontroller, Intrasubnet Roaming

    : 1개 이상의 컨트롤러 간에 join 된 AP에 연결된 STA의 이동 시(동일한 서브넷에 STA이 위치 시)

    : 컨트롤러간 Mobility 정보 교환, Anchor 와 Foreign 컨트롤러로 구성됨.

       

       

    1.2.3 Intercontroller, Intersubnet (Symmetric) Roaming

    : 1개 이상의 컨트롤러 간에 join 된 AP에 연결된 STA의 이동 시 (다른 서브넷에 STA이 위치 시)

    : STA의 트래픽은 Anchor 컨트롤러를 통해서 대칭형 통신

       

    위 처럼 Asymmetric Tunneling 은 현재 시스코 무선 WLC에서 지원하지 않는다

       

    1.2.4 Mobility Groups

    : 같은 Mobility Group Name 을 같는 컨트롤러간에 STA은 seamless 로밍이 됨, 같은 Virtual Gateway IP addr.

    : 같은 Mobility Group 간에는 client 정보, context 정보를 공유함

    : mobility message 를 컨트롤러간 UDP 16666 을 통해서 교환함. IPsec 암호화 시 UDP 16667로 교환함.

    : 컨트롤러 5.2 이상에서는 1개의 mobility group 에 24개의 컨트롤러 설정 가능.

    : 동일한 mobility list(다른 mobility group names) 에 72개의 컨트롤러 설정 가능.

    : Mobility Group 를 사용하여 로밍 제한도 가능함.

       

    1.2.5 Mobility Groups and Mobility Lists

    : Mobility Group : CCKM, PKC 를 유지

    : Mobility List 같음, Mobility Gruop 다름 : fully authenticated 하지 않지만 IP는 유지

    : List 의 경우 서로간에 다를 수 있음. 즉 C1->C2,C3 이며 C2->C1, C3->C1 이지만 C2<->C3 아닐 수 있음.

    위 경우 C2와 C3간 STA는 seamless 로밍 되지 않음.

       

       

       

    1.2.5.1 추가 : Mobility Domains = 여러 Mobility Group

       

       

       

    1.2.5.2 추가 : Mobility List = 여러 Mobility Group

    => 결론은 여러 Mobility Group 은 하나의 Mobility List(=Mobility List) 에 속하며 로밍이 지원된다.

       

    1.2.6. Mobility Groups and NAT(p119)

    : NAT 환경에서 지원...

       

    1.2.7 Configuring Mobility Groups

    모든 컨트롤러에는 management interface 통신이 되야 합니다.

    모든 컨트롤러는 동일한 virtual IP address 공유 해야 합니다.

    모든 컨트롤러는 동일한 버전의 code를 실행 해야 합니다.

    UDP 포트 16666 및 16667는 이동성 교환을 위해 허용. (test, CLI mping) Mobility ping over UDP

    UDP 포트 5246 5247 CAPWAP 트래픽 (12222 및 LWAPP에 대 한 12223)에 대 한 허용 되어야 합니다.

    IP프로토콜 50(IP 압축) 및 IP프로토콜 97(IP 이더넷)를 허용.(test, eping) Mobility ping over Ethernet over IP(EoIP)

    UDP 포트 500을 허용 해야 합니다 secure mobility groups을 사용 하는 경우.

       

       

    1.2.7.1 Configuring Mobility Groups (Cont.)

    : LMG(training2) 가 setup 에서 설정한 내용이다. 컨트롤러 정보(mac, ip, group name)를 입력한다.

       

       

    1.2.7.2 Intercontroller Messaging

    : 컨트롤러간 Multicast 로 정보를 교환하려면 아래 설정을 해야 한다. 설정 없을 시 유니캐스트로 전달.

    : Local Group MIP 주소 설정을 하며 만약 다른 MG 컨트롤러의 경우에 IP 지정 하지 않을 시 유니캐스트로 전달.

       

    1.2.7.3 Mobility Recommended Practices

    : 권고 내용

    'DHCP Required' option can slow down roaming. <- STA 무선IP폰일 경우 문제 될 수 있음.

    Use Multicast for Mobility whenever possible.

    Use config mobility secure-mode to secure the tunnel.

    <- (config) mobility secure-mode(16667로 통신), 단 2100 WLC, WLCM은 제공하지 않음.

       

    1.2.8 Minimize Intercontroller Roaming

    : 소금과 후추 구성은 층별 컨트롤러에 AP를 차례차례로 join 한 구성

    : HA Full standby 는 WLC1만 사용하다가 장애시 WLC2로 적용

       

    1.2.9 Monitoring Mobility (Monitor > Statistics > Mobility Statistics)

    : CLI commands - show mobility {summary | anchor | statistics }

    Global statistics: Affect all mobility transactions

    Mobility initiator statistics: Generated by the controller initiating a mobility event

    Mobility responder statistics: Generated by the controller responding to a mobility event

       

       

    1.2.10 Debug of Mobility Session Establishment

    : debug mobility {directory | handoff} {enable | disable}

       

    ================================

       

    Cisco.Press.Deploying.and.Troubleshooting.Cisco.Wireless.LAN.Controllers.Nov.2009.pdf

    Chapter 9: Mobility > Mobility Handoff Types(p235)

    : 6개의 로밍 타입

    1. Local to Local

    2. Local to Foreign

    3. Foreign to Local (1)

    4. Foreign to Local (2)

    5. Foreign to Foreign

    6. Auto-Anchor

       

    1. Local to Local

    Local-to-Local Handoff 는 two controllers 간에 Layer 2 roam 일 때 입니다.

    The client roams to an AP on WLC2, WLC2 sends a "Mobile Announce" to the mobility group members.

    WLC1 responds with a "Mobile Handoff", and the client database entry is moved from WLC1 to WLC2.

    WLC1 no longer has the client database entry.

    WLC2 becomes the IP point of presence for the client.

       

    2. Local to Foreign

    A Local-to-Foreign Handoff occurs when the client performs a Layer 3 (inter-controller inter-subnet) roam

    and requires only two packets. Layer3 로밍이며 다른 컨트롤러간에 다른 서브넷 환경에서 발생

    When the client roams from WLC1 to WLC2, WLC2 sends a "Mobile Announce", and WLC1 responds with a "Mobile Handoff".

    The client database entry is copied from WLC1 to WLC2.

    WLC1 marks the client entry as Export Anchor, and WLC2 marks the client entry as Export Foreign.

    The IP point of presence for the client remains WLC1.

       

    3. Foreign to Local (1)

    위 2번 환경에서 무선 단말이 다시 Local WLC로 돌아올 경우

    A Foreign-to-Local (1) Handoff is the opposite of the Local-to-Foreign Handoff and again requires only two packets.

    The client is roaming from the foreign controller back to the anchor controller it came from.

    shows that when the client roams back to WLC1, WLC1 sends out a Mobile Announce,

    and WLC2 responds with a Mobile Handoff.

    WLC1 knows it used to have a Local entry for that client and removes the Export Anchor designation

    from the client entry and once again marks it as Local.

    WLC2 deletes the database entry for the client. WLC1 remains the IP point of presence for the client.

       

    4. Foreign to Local (2)

    Foreign-to-Local (2) Handoff 는 3개의 컨트롤러가 필요하다.

    무선 단말은 Foreign WLC에서 3번째 WLC로 로밍한다.(단, Anchor WLC와 같은 Subnet)

    WLC3은 Mobile Announce 를 Mobility Member(WLC2, WLC1?)에게 보낸다.

    WLC2는 Client DB Entry 를 WLC3에게 전달하고 WLC1에게 Mobility Handoff End 를 전달한다.

    이후 WLC1,2는 client database entry를 삭제한다. same subnet 이기 때문에 client DB를 WLC3이 point of presence 한다

    The client roams from the foreign controller to a third controller whose WLAN is in the same subnet as the anchor controller.

    When the client roams to WLC3, WLC3 sends out a Mobile Announce, and WLC2 responds with a Mobile Handoff.

    The client database information is extracted from WLC2 by WLC3.

    WLC2 sends a Mobility Handoff End, and WLC1 responds with a Mobility Handoff End ACK.

    WLC1 and WLC2 delete the client database entry, and WLC3 marks the client entry as Local because

    its WLAN is in the same subnet as the client IP and becomes the IP point of presence for the client.

       

       

    5. Foreign to Foreign

    Foreign-to-Foreign Handoffs 3개의 컨트롤러간에 발생(다른 서브넷 환경). 가장 복잡한 handoff transaction.

    When the client roams to WLC3, WLC3 sends out a Mobile Announce to the mobility members.

    WLC2 responds with a Mobile Handoff, and all client entry information is extracted from WLC2 and transferred to WLC3.

    After sending the Mobile Handoff, WLC2 sends an Anchor Xfer message to the WLC1, at which time WLC1

    responds with an Anchor Xfer ACK and sets up the new client forwarding path.

    WLC2 then deletes the client session. WLC3 sends an Anchor Req message to WLC1, and WLC1 responds with an Anchor Grant message.

    The IP point of presence for the client remains with WLC1.

       

    6. Auto-Anchor

    auto-anchoring 설정 경우 동작이 조금 다르다.

    로밍 시 WLC2는 "Mobile Announce" messages to the mobility members 보내지만 auto-anchor controller(WLC1)은 응답하지 않는다.

    그러면 WLC는 Local entry 에 Client 정보를 만든다. WLC2는 "Export Anchor Request"를 보내고 WLC1은 "Export Anchor ACK"로 응답.

    Client DB entry 는 anchor WLC에서 copy 된다.

    After WLC2 sends the fourth Mobile Announce and does not receive a Mobile Handoff from any other controllers

    in the mobility group, instead of creating a Local entry for the client, WLC2 sends an Export Anchor Request to WLC1,

    which is configured as the autoanchor for the client WLAN.

    The anchor controller responds with an Export Anchor ACK.

    The client database entry is copied to the anchor controller.

    WLC1 marks the client entry with Export Foreign, and WLC1 marks the entry as Export Anchor.

    WLC1 is the IP point of presence for the client.

    With the auto-anchoring scenario, you have a fixed anchor controller for the client WLAN that will never change.

    The client will have an IP address in the same VLAN as the anchored WLAN interface on WLC1.

       

     

     

     

     

     

     

     

    출처 : http://mongu2.blog.me/140156975013

     

     

     

     

     

     

     

    신고

    'Skill > EPC' 카테고리의 다른 글

    GTP-C Interface  (0) 2014.03.20
    LTE Network Entity  (0) 2014.03.20
    [IUWMS v1 - L2, L3 Roaming 로밍]  (0) 2014.03.20
    LTE와 Wi-Fi 네트워크 연동 구조 (1편: Network Reference Model)  (0) 2014.03.20
    EPS (Evolved Packet System) - 1  (0) 2014.03.20
    LTE의 GTP 터널 소개  (0) 2014.03.11

    Comment +0

    티스토리 툴바