Snoop, however, has its own limitations. First, it requires a snoop proxy in the base station. Also, if the TCP sender is the mobile, the TCP code must be modified to respond to Explicit Loss Notification (ELN) packets from the base station.

Saverio Mascolo, Politecnico Di Bari, Claudio Casetti, Politecnico Di Torino, Mario Gerla, M. Y. Sanadidi, and Ren Wang
"TCP Westwood: Bandwidth Estimation for Enhanced Transport over Wireless Links"


TCP Westwood+, in contradiction to the initial version of Westwood, computes one sample of available bandwidth every RTT using all data acknowledged in the specific RTT, therefore obtaining more accurate estimates (Fig. 6a). However, from the perspective of real-time delivery, Westwood+’s efficiency is not evident, since it delivers a considerable amount of delayed packets (Fig. 6d). Inline with our analytical approach, reaching the downlink capacity (i.e. flows 30–50) maximizes transmission time T(n) and results in variable transmission periods which impact video delivery. The protocol responds inappropriately to the variation in the rate of arriving ACKs, since the disturbed inter-ACK spacing reflects the fluctuations in the receiving rate, due to congestion incidents.

Vassilis Tsaoussidis, Panagiotis Papadimitriou
"On TCP performance over asymmetric satellite links with real-time constraints"


TCPW나 TCPW+의 단점은 명확하지가 않네...
Posted by 배트
,

ns-2 Full-TCP and Wireless

This is a hack to allow the use of Full-TCP in wireless simulations using DSDV routing. The basic problem is that the IP header is added at the wireless network layer and also accounted for at the Full-TCP transport layer. This code just checks a flag to see if the IP header should be added at the network layer.

To use this, just add Agent/DSDV set fulltcp_ 1 to your TCL script (before you do node-config) once you've made the following changes to the ns source and re-compiled.

Files Changed

  • dsdv/dsdv.cc
  • dsdv/dsdv.h
  • tcl/mobility/dsdv.tcl

    Note: These diffs are based on the ns-2.29 release.

    dsdv/dsdv.cc

    Index: dsdv.cc
    *** dsdv.cc     13 Jul 2005 03:51:24 -0000      1.25
    --- dsdv.cc     7 Mar 2006 15:26:16 -0000
    ***************
    *** 1009,1015 ****
          /*
           * Add the IP Header
           */
    !     cmh->size() += IP_HDR_LEN;    
          iph->ttl_ = IP_DEF_TTL;
        }
        /*
    --- 1009,1017 ----
          /*
           * Add the IP Header
           */
    !         if (!fulltcp_) {
    !                 cmh->size() += IP_HDR_LEN;    
    !         }
          iph->ttl_ = IP_DEF_TTL;
        }
        /*
    ***************
    *** 1080,1086 ****
        periodic_callback_ (0), be_random_ (1), 
        use_mac_ (0), verbose_ (1), trace_wst_ (0), lasttup_ (-10), 
        alpha_ (0.875),  wst0_ (6), perup_ (15), 
    !   min_update_periods_ (3)     // constants
       {
        table_ = new RoutingTable ();
        helper_ = new DSDV_Helper (this);
    --- 1082,1088 ----
        periodic_callback_ (0), be_random_ (1), 
        use_mac_ (0), verbose_ (1), trace_wst_ (0), lasttup_ (-10), 
        alpha_ (0.875),  wst0_ (6), perup_ (15), 
    !   min_update_periods_ (3), fulltcp_(0)        // constants
       {
        table_ = new RoutingTable ();
        helper_ = new DSDV_Helper (this);
    ***************
    *** 1095,1100 ****
    --- 1097,1104 ----
        bind ("min_update_periods_", &min_update_periods_);
        bind ("verbose_", &verbose_);
        bind ("trace_wst_", &trace_wst_);
    +   // MCW  2006Feb02
    +   bind ("fulltcp_", &fulltcp_);
        //DEBUG
        address = 0;
    
    dsdv/dsdv.h
    Index: dsdv.h
    *** dsdv.h      20 Aug 1999 18:03:16 -0000      1.6
    --- dsdv.h      7 Mar 2006 15:16:21 -0000
    ***************
    *** 137,142 ****
    --- 137,145 ----
        int    min_update_periods_;    // 3 we must hear an update from a neighbor
        // every min_update_periods or we declare
        // them unreachable
    + 
    +       // MCW 2006Feb02
    +       int fulltcp_;
        
        void output_rte(const char *prefix, rtable_ent *prte, DSDV_Agent *a);
    
    tcl/mobility/dsdv.tcl
    Index: dsdv.tcl
    *** dsdv.tcl    23 Dec 2003 17:36:35 -0000      1.14
    --- dsdv.tcl    7 Mar 2006 15:18:37 -0000
    *** 49,54 ****
    --- 49,57 ----
      Agent/DSDV set verbose_      0        ;# 
      Agent/DSDV set trace_wst_    0        ;# 
      
    + # MCW  2006Feb02
    + Agent/DSDV set fulltcp_ 0
    + 
      set opt(ragent)               Agent/DSDV
      set opt(pos)          NONE                    ;# Box or NONE
    

    Michele C. Weigle
    Last modified: Wed Sep 13 02:31:03 UTC+0900 2006

  • 출처 : http://www.cs.odu.edu/~mweigle/research/netsim/fulltcp-wlan.html
    Posted by 배트
    ,

    네트워크 시뮬레이션을 위해 트래픽 모델과 시뮬레이션들을 찾던 와중에 좋은 자료를 발견했습니다.
    대부분 기존 시뮬레이터에 네트워크 트래픽 모듈을 붙이기만 하면 돌아가는 것들입니다.
    특히 PackMIME은 ns-2 ver2.2x 부터 정식 포함되어있는 모듈이기도 하죠.
    네트워크 시뮬레이션을 하기에 유용한 자료들입니다.

    출처 : The ICSI 홈페이지, http://www.icir.org/models/trafficgenerators.html

    Traffic Generators for Internet Traffic

    • Henning's web page on traffic generators.

    • D-ITG's web page on traffic generators.

    • Polly Huang's traffic generator in NS:
      Anja Feldmann, Anna C. Gilbert, Polly Huang and Walter Willinger. Dynamics of IP Traffic: A Study of the Role of Variability and the Impact of Control, SIGCOMM'99, Boston, MA, Sep 1999.
      "During a Web session, a user usually requests several Web pages and each page may contain several web objects. To capture this hierarchical structure and its inherent variability, we allow for different probability distributions for the following user/session attributes: inter-session time, pages per session, inter-page time, objects per page, inter-object time, and object size... We base our choice of distributions on the work surrounding SURGE... and upon [Feldman99, Mogel97]."

    • The NSWEB traffic generator for NS-2.29.

    • The PackMime-HTTP traffic generator in NS:
      J. Cao, W.S. Cleveland, Y. Gao, K. Jeffay, F.D. Smith, and M.C. Weigle, Stochastic Models for Generating Synthetic HTTP Source Traffic, IEEE INFOCOM, March 2004.
      ``New source-level models for aggregated HTTP traffic ... are built and validated using two large-scale collections of TCP/IP packet header traces." The TCP connections are modeled ``in terms of connection establishment rates and the sizes and timing of exchanges of request and response data."
      The PackMime-HTTP traffic generator requires the use of Full-TCP in NS.

    • The tmix traffic generator.
      M. Weigle, P. Adurthi, F. Hernandez-Campos, K. Jeffay and F. D. Smith, Tmix: A Tool for Generating Realistic TCP Application Workloads in ns-2, CCR, July 2006.
      "The system takes as input a packet header trace taken from a network link of interest. The trace is reverse compiled into a source-level characterization of each TCP connection present in the trace."

    • NETI@home:
      NETI@home collects network performance statistics from end-systems. The related work includes models of user behavior.

    • The Swing traffic generator:
      K. Viashwanath and A. Vahdat, Realistic and Responsive Network Traffic Generation, SIGCOMM 2006.
      "Starting from observed traffic at a single point in the network, Swing automatically extracts distributions for user, application, and network behavior."

    • D-ITG, Distributed Internet Traffic Generator for testbeds:
      D-ITG produces traffic "accurately replicating appropriate stochastic processes for both IDT (Inter Departure Time) and PS (Packet Size)", and is capable of generating traffic at the network, transport, and application layers. Includes DCCP support. Updated 2006.

    • The Harpoon traffic generator for testbeds:
      J. Sommers and P. Barford, Self-Configuring Network Traffic Generation, IMC 2004.
      Harpoon is an application-independent tool for generating representative packet traffic at the IP flow level. Harpoon can also self-configure from Netflow logs. December 2005.

    • The Surge traffic generator for testbeds:
      Paul Barford and Mark Crovella. Generating Representative Web Workloads for Network and Server Performance Evaluation. In Proceedings of the ACM SIGMETRICS, pages 151-160, Madison WI, November 1998. ACM.

    • RAMP:
      Kun-chan Lan and John Heidemann, Rapid Model Parameterization from Traffic Measurements, ISI-RF-561, August 2002.
      "We describe approaches and tools that support rapid parameterization of traffic models from live network measurements."

    • IPB:
      B. Mah, P. Sholander, L. Martinez, and L. Tolendino. IPB; an Internet Protocol Benchmark using Simulated Traffic. Proceedings of MASCOTS '98, Montreal, Canada, August 1998. IEEE.
      "We have developed an IP Benchmark (IPB), which uses synthetic, simulated traffic to measure the peformance across an IP network or internetwork."

    • The trafgen traffic generator:
      Rigoberto Chinchilla, John Hoag, David Koonce, Hans Kruse, Shawn Ostermann, and Yufei Wang, Characterization of Internet Traffic and User Classification: Foundations for the Next Generation of Network Emulation, Proceedings of the 10th International Conference on Telecommunication Systems, Modeling and Analysis (ICTSM10), 2002.
      "Currently, we model traffic based on applications, such as a web browser or a file transfer application. In the present upgrade, we are modeling the way users utilize multiple applications."

    • Web servers:
      Benchmarking of Web-Server Systems:
      Michele Colajanni, Mauro Andreolini, and Valeria Cardellini, Benchmarking of Locally and Geographically Distributed Web-Server Systems, Half-day tutorial at 12th International World Wide Web Conference (WWW2003), Budapest, Hungary, May 20th, 2003.

    • GenSyn is a Java-based, traffic generator generating TCP connections and UDP streams. From 2000.

    • httperf "provides a flexible facility for generating various HTTP workloads and for measuring server performance." From 1998.

    • Modeling Peer-to-Peer Traffic.

    • Modeling Traffic from Online Games.

    • Modeling DDoS Attacks.

    • Methodologies:
      • M. Yuksel, B. Sikdar, K. S. Vastola, and B. Szymanski. Workload Generation for NS Simulations of Wide Area Networks and the Internet. Proceedings of Communication Networks and Distributed Systems Modeling and Simulation Conference (CNDS) part of Western Multi-Conference (WMC), pages 93-98, San Diego, CA, 2000.
        "We introduce methodologies for implementing realistic workload generators for wide area networks which (1) maintain the proper composition of the aggregate traffic resulting from the mix of various applications supported by the network and (2) are capable of generating long range dependent or self-similar traffic."

      • F. Hernandez Campos, K. Jeffay, F.D. Smith, S. Marron, and A. Nobel, Methodology For Developing Empirical Models of TCP-Based Applications, 2001.
        "We report on a large-scale empirical study to create application-level models for TCP traffic generation in simulations and network test-beds."

      • F. Hernandez-Campos, K. Jeffay, and F. Donelson Smith, Tracking the Evolution of Web Traffic: 1995-2003, MASCOTS 2003.
        "These results demonstrate that usage of the web by both consumers and content providers has evolved significantly and make a compelling case for continual monitoring of web traffic and updating of models of web traffic."

    • Why Traffic Models Matter:
      Y. Joo, V. Ribeiro, A. Feldmann, A. C. Gilbert, and W. Willinger, TCP/IP Traffic Dynamics and Network Performance: A Lesson in Workload Modeling, Flow Control, and Trace-driven Simulations. CCR, April 2001.
      "The main objective of this paper is to demonstrate in the context of a simple TCP/IP-based network that depending on the underlying assumptions about the inherent nature of the dynamics of network traffic, very different conclusions can be derived for a number of well-studied and apparently well-understood problems in the area of performance evaluation. For example, a traffic workload can either completely ignore the empirically observed high variability at the TCP connection level (i.e., assume "infinite sources") or explicitly account for it with the help of heavy-tailed distributions for TCP connection sizes or durations."

    • Usage Patterns in Wireless Networks:

    • Packet replay engines include TCPivo and tcpreplay.

    • Commercial traffic generators:

    • Trace libraries:
      • Crawdad, an archive for wireless data.

    Thanks to Senthilkumar Ayyasamy for contributions to this page. Proposed additions to this page can be sent to Sally Floyd.
    This material is based upon work supported by the National Science Foundation under Grant No. 0230921. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.
    Last modified: February 2008
    Posted by 배트
    ,
    13.4 Commands at a glance

    The following is a list of error-model related commands commonly used in simulation scripts:
    set em [new ErrorModel]
    $em unit pkt
    $em set rate_ 0.02
    $em ranvar [new RandomVariable/Uniform]
    $em drop-target [new Agent/Null]

    This is a simple example of how to create and configure an error model. The commands to place the error-model in a simple link will be shown next.

    $simplelink errormodule <args>
    This commands inserts the error-model before the queue object in simple link. However in this case the error-model’s drop-target points to the link’s drophead_ element.

    $ns_ lossmodel <em> <src> <dst>
    This command places the error-model before the queue in a simplelink defined by the <src> and <dst> nodes. This is basically a wrapper for the above method.

    $simplelink insert-linkloss <args>
    This inserts a loss-module after the queue, but right before the delay link_ element in the simple link. This is because nam can visualize a packet drop only if the packet is on the link or in the queue. The error-module’s drop-target points to the link’s drophead_ element.

    $ns_ link-lossmodel <em> <src> <dst>
    This too is a wrapper method for insert-linkloss method described above. That is this inserts the error-module right after the queue element in a simple link (src-dst).

    출처 : The ns Manual 129~130p
    Posted by 배트
    ,
    간접출처
    http://overegoz.tistory.com/669

    References

    [1] http://4ellene.net/tt/1075


    This revised trace support is backwards compatible with the old trace formatting and can be enabled by the following command:


    $ns use-newtrace


    This command should be called before the universal trace command $ns trace-all trace-fd. Primitive use-newtrace sets up new format for wireless tracing by setting a simulator variable called newTraceFormat. Currently this new trace support is available for wireless simulations only and shall be extended to rest of in the near future.




    Event type : 이벤트

    In the traces above, the first field (as in the older trace format) describes the type of event taking place at the node and can be one of the four types:

    S : send / r : receive / d : drop / f : forward


    General tag

    The second field starting with "-t" may stand for time or global setting

    -t : time / -t : * (global setting)


    Node property tags

    This field denotes the node properties like node-id, the level at which tracing is being done like agent, router or MAC. The tags start with a leading "-N" and are listed as below:

    -Ni: node id

    -Nx: node's x-coordinate

    -Ny: node's y-coordinate

    -Nz: node's z-coordinate

    -Ne: node energy level

    -Nl: trace level, such as AGT, RTR, MAC

    -Nw: reason for the event. The different reasons for dropping a packet are given below:

    "END" DROP_END_OF_SIMULATION

    "COL" DROP_MAC_COLLISION

    "DUP" DROP_MAC_DUPLICATE

    "ERR" DROP_MAC_PACKET_ERROR

    "RET" DROP_MAC_RETRY_COUNT_EXCEEDED

    "STA" DROP_MAC_INVALID_STATE

    "BSY" DROP_MAC_BUSY

    "NRTE" DROP_RTR_NO_ROUTE i.e no route is available.

    "LOOP" DROP_RTR_ROUTE_LOOP i.e there is a routing loop

    "TTL" DROP_RTR_TTL i.e TTL has reached zero.

    "TOUT" DROP_RTR_QTIMEOUT i.e packet has expired.

    "CBK" DROP_RTR_MAC_CALLBACK

    "IFQ" DROP_IFQ_QFULL i.e no buffer space in IFQ.

    "ARP" DROP_IFQ_ARP_FULL i.e dropped by ARP

    "OUT" DROP_OUTSIDE_SUBNET i.e dropped by base stations on receiving routing updates from nodes outside its domain.

    Packet information at IP level

    The tags for this field start with a leading "-I" and are listed along with their explanations as following:

    -Is: source address.source port number

    -Id: dest address.dest port number

    -It: packet type

    -Il: packet size

    -If: flow id

    -Ii: unique id

    -Iv: ttl value

    Next hop info

    This field provides next hop info and the tag starts with a leading "-H".

    -Hs: id for this node

    -Hd: id for next hop towards the destination.

    Packet info at MAC level

    This field gives MAC layer information and starts with a leading "-M" as shown below:

    -Ma: duration

    -Md: dst's ethernet address

    -Ms: src's ethernet address

    -Mt: ethernet type

    Packet info at "Application level"

    The packet information at application level consists of the type of application like ARP, TCP, the type of adhoc routing protocol like DSDV, DSR, AODV etc being traced. This field consists of a leading "-P" and list of tags for different application is listed as below:

    -P arp

    Address Resolution Protocol. Details for ARP is given by the following tags:

    -Po: ARP Request/Reply

    -Pm: src mac address

    -Ps: src address

    -Pa: dst mac address

    -Pd: dst address

    -P dsr

    This denotes the adhoc routing protocol called Dynamic source routing. Information on DSR is represented by the following tags:

    -Pn: how many nodes traversed

    -Pq: routing request flag

    -Pi: route request sequence number

    -Pp: routing reply flag

    -Pl: reply length

    -Pe: src of srcrouting->dst of the source routing

    -Pw: error report flag ?

    -Pm: number of errors

    -Pc: report to whom

    -Pb: link error from linka->linkb

    -P cbr

    Constant bit rate. Information about the CBR application is represented by the following tags:

    -Pi: sequence number

    -Pf: how many times this pkt was forwarded

    -Po: optimal number of forwards

    -P tcp

    Information about TCP flow is given by the following subtags:

    -Ps: seq number

    -Pa: ack number

    -Pf: how many times this pkt was forwarded

    -Po: optimal number of forwards

    This field is still under development and new tags shall be added for other applications as they get included along the way.


    s -t 0.267662078 -Hs 0 -Hd -1 -Ni 0 -Nx 5.00 -Ny 2.00 -Nz 0.00 –Ne -1.000000 -Nl RTR -Nw --- -Ma 0 -Md 0 -Ms 0 -Mt 0 –Ii 20 -Is 0.255 -Id -1.255 –It


    -S : 이벤트 ex) sent

    -t 0.267662078 : 시간

    -Hs 0 : 소스 노드(Hs) 0 에서

    -Hd -1 : 목적지 노드(Hd) 1

    -Ni 0 : 소스 노드 ID 는 0

    -Nx 5.00 : x-co-ordinate는 5.00

    -Ny 2.00 : s y-co-ordinate 은 2.00

    -Nz 0.00 : z-co-ordinate은 0.00

    –Ne -1.000000 : 에너지 레벨은 1.000000

    -Nl RTR : 트레이스 레벨은 RTR

    -Nw --- : 노드 이벤트는 없음

    -Ma 0 : The MAC level information is given by duration (Ma) 0

    -Md 0 : 목적지 이더넷 주소 (Md)0

    -Ms 0 : 발신지 이더넷 주소(Ms)0

    -Mt 0 : 이더넷 종류 0

    –Ii 20 : The IP packet level information like packet id (Ii)

    -Is 0.255 : 발신자 주소.발신자 포트번호

    -Id -1.255 : 목적지 주소.목적지 포트번호

    –It

    Here, we see that a packet was sent (s) at time (t) 0.267662078 sec, 
    from source node (Hs) 0 to destination node (Hd) 1.
    The source node id (Ni) is 0, it's x-co-ordinate (Nx) is 5.00,
    it's y-co-ordinate (Ny) is 2.00, it's z-co-ordinate (Nz) is 0.00,
    it's energy level (Ne) is 1.000000, the trace level (Nl) is
    RTR and the node event (Nw) is blank. The MAC level information is
    given by duration (Ma) 0, destination Ethernet address (Md) 0,
    the source Ethernet address (Ms) is 0 and Ethernet type (Mt) is 0.
    The  IP packet level information like packet id (Ii), 
    source address.source port number is given by (Is) while the destination address.
    destination port number is (Id).
    Posted by 배트
    ,
    1. WinInet을 사용하는 경우
        InternetOpen에서 설정한다.
        OS(즉, Internet Explorer)에 설정된 프록시 설정을 그대로 사용할 수 있고.
        프로그램에서 독자적으로 프록시 설정을 할 수도 있다.

    2. WinHTTP를 사용하는 경우
        SetProxy 메소드를 통해서 프록시 설정을 할 수 있다.
        WinInet과 마찬가지로 시스템 설정, 사용자 설정 둘 다 가능하다.

    3. Internet Explorer 컨트롤을 사용하는 경우
        Proxy 설정을 별도로 하는 메소드나 방법을 찾지 못했다.
        시스템 설정만을 따르는 것 같다.

    ※ 시스템의 프록시 설정을 변경하는 방법
        1. Internet Explorer의 옵션에서 변경
        2. 레지스트리의 키를 수정 직접 수정
           Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer
           Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyEnable
           실행 중인 어플리케이션에 적용하기 위해선 아래 함수 콜이 필요하다.
           InternetSetOption(NULL, INTERNET_OPTION_SETTINGS_CHANGED, NULL, 0);
           InternetSetOption(NULL, INTERNET_OPTION_REFRESH, NULL, 0);
        3. WMI의 SetProxySetting API를 이용
           아마 레지스트리의 키를 직접 변경하는 것과 다를 바가 없을 듯

    결론
    Internet Explorer ActiveX를 사용하는 어플리케이션은
    동시에 여러 어플리케이션을 실행하면서
    각각 다른 프록시 설정을 하는 것이 어렵다.
    다른 편법을 동원해야 할 듯 하다.

    ps. 특정 어플리케이션에 강제로 프록시 세팅을 해주는 유틸리티를 본 것 같다.
         하지만 지금은 찾을 수도, 어떻게 동작하는 지도 모르겠다.
         프록시 서버 리스트, 자동으로 구성 같은 내용도 알아봐야 한다.


    프록시 설정 자세히


    [ 레지스트리 경로 ]
    HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings

    [ 프록시 서버 사용(X) ]
        종류 : REG_DWORD
        ProxyEnable => 0x00000000(0) => 사용안할때
        ProxyEnable => 0x00000001(1) => 사용할때

    [ 로컬 주소에 프록시 서버 사용 안함(B) ]
        종류 : REG_SZ
        ProxyOverride => <local> => 체크시 레지스트리에 생성됨
        비체크시에는 레지스트리에서 이름과 값이없어짐.
       
    [ 프록시 서버명과 포트번호 ]
        종류 : REG_SZ
        ProxyServer => http=localhost:8000

    인터넷 옵션에서 고급탭 설정 방법.
    [ HTTP 1.1 설정 ]
             종류 : REG_DWORD
        프록시 연결을 통해 HTTP 1.1 사용
        ProxyHttp1.1 => 0x00000001(1) => 사용할때
        ProxyHttp1.1 => 0x00000000(0) => 사용안할때

        HTTP 1.1 사용
        EnableHttp1_1 => 0x00000001(1) => 사용할때
        EnableHttp1_1 => 0x00000000(0) => 사용안할때

    출처 : 데비피아 C++ Q&A
    Posted by 배트
    ,
    사용자 삽입 이미지
    Hidden node(terminal) problem
    Wireless networking에서, AP와 통신이 가능한 다른 두 노드가 서로 통신이 불가능한 경우 발생한다.











    Exposed node(terminal) problem

    Wireless networking에서, 두 개의 이웃한 송신 노드가 서로 다른 수신 노드에게 전송을 시도할 때 서로 방해받는 현상. 이웃한 송신 노드 송신 노드 A가 다른 수신 노드 B에게 전송을 시도를 할 때, 이웃한 송신 노드 C가 A의 권외(out of range)인 수신 노드 D에게 이미 전송을 하고 있다면, A와 D는 권외임에도 불구하고 A의 전송은 방해를 받는다.
    사용자 삽입 이미지












    RTS/
    CTS
    Request to Send / Celar to Send
    802.11에서, 송신을 원하는 노드는 RTS를 보내고, 수신 노드는 CTS로 회답하여 연결을 초기화한다.
    RTS/CTS로 초기화가 되면 두 노드는 통신 가능으로 간주하여 전송을 시작하고(AP의 정보에 의존하지 않음, Hidden node problem 해결), RTS/CTS를 모두 수신한 이웃 노드는 전송을 방해 받지만, RTS/CTS 중 하나만 수신한 노드는 다른 노드와 전송이 가능하다.(Exposed node problem 해결)


    이미지 출처 : 위키피디아
    Posted by 배트
    ,