Docstoc

IEEE Contribution

Document Sample
IEEE Contribution Powered By Docstoc
					2005-5-16                                                                     IEEE C802.20-05/25




Project     IEEE 802.20 Working Group on Mobile Broadband Wireless Access
            <http://grouper.ieee.org/groups/802/20/>

Title       IEEE 802.20 Evaluation Criteria (EC) – Simulation of Common Traffic Types

Date        May-5-2005
Submitted

Source(s)   Dan Gal                                  Voice: 973-428-7734
            67 Whippany Road,                        Fax: 973-386-4555
            Whippany, NJ 07981                       Email: dgal@lucent.com

Re:         MBWA Call for Contributions: Session # 14

Abstract    This contribution proposes a practical approach to the question of Traffic Mix
            simulation and suggests some text changes in section 4 of the Evaluation Criteria
            document (version 15r3).

Purpose     Proposal for section 4 of the 802.20 EC document
            This document has been prepared to assist the IEEE 802.20 Working Group. It is offered as a basis
Notice      for discussion and is not binding on the contributing individual(s) or organization(s). The material in
            this document is subject to change in form and content after further study. The contributor(s)
            reserve(s) the right to add, amend or withdraw material contained herein.
            The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this
Release     contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to
            copyright in the IEEE’s name any IEEE Standards publication even though it may include portions
            of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in
            part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that
            this contribution may be made public by IEEE 802.20.
            The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA
Patent      Standards Board Operations Manual <http://standards.ieee.org/guides/opman/sect6.html#6.3> and in
Policy      Understanding Patent Issues During IEEE Standards Development
            <http://standards.ieee.org/board/pat/guide.html>.




                                                     CP
     2005-5-16                                                              IEEE C802.20-05/25



 1   1.0    Introduction
 2   This contribution builds on the working draft document submitted to the May 3rd, 2005
 3   Evaluation Criteria CG call and includes changes suggested by the participants.

 4   Objectives
 5   The objectives of this proposal are:
 6       Streamline the requirements for the system-level traffic modeling (section 4.3)
 7       Reduce the complexity of the traffic-mix simulations (section 4.4)
 8       Edit some paragraphs to improve clarity
 9
10   Note: All the proposed changes pertain to Section 4 of the Evaluation Criteria Document
11   (Version 15r3.)

12   1


13   2


14   3
15   ======================== Proposed Changes =========================

16   4 Traffic Models for 802.20 System Simulations

17   4.1   Introduction
18
19   The Mobile Broadband Wireless Access (MBWA) systems will be designed to provide a
20   broadband, IP-oriented connection to a wireless user that is comparable to wired broadband
21   connections that are in use today. It is expected that there will be a mix of user applications,
22   not unlike that of such wired systems. Further, the traffic characteristics and system
23   requirements of the various applications can vary widely. The performance of such MBWA
24   systems is thus very much dependant on the details of the applications and their traffic
25   models. This is in contrast to cellular wireless voice systems where the performance studies
26   focused on physical and link layer performance with a relatively simple traffic generation
27   model. The purpose of this section is to provide detailed statistical traffic models that can
28   be used as an input to generate packets in a simulation study of a MBWA system.

29   4.2   Context and Scope

30   4.2.1 User device scenarios
31   [Editor’s Note: It was discussed over the 12/2 conference call if we need to consider all the
32   user scenarios (Laptop, PDA, Smart phone, machine-to-machine) or only a subset of the
33   user scenarios can be considered. In order to capture different user scenarios, parameters
34   values of some traffic models (e.g. web browsing) would be adapted to the user scenario
35   (e.g. heavy, medium or light web browsing application).]



                                                                                                   1
     2005-5-16                                                            IEEE C802.20-05/25

 1   {Leave this section as FYI, based on consensus of CC: April 5, 05}
 2   [Editor’s suggestions: Option 1) Leave the section as FYI; Option 2) Specify a traffic mix
 3   in Table 5 and/or 11 that resembles one or more of these user device scenarios.]
 4   There can be various different user scenarios for MBWA systems, some of which we
 5   cannot foresee at this time. For purposes of illustration, we include some candidate
 6   scenarios to frame the context of our work.
 7   [Editor’s note: These descriptions need to be discussed]
 8   [Needs resolution with regard to whether to drop the issue or to continue /Berlin].
 9
10   In all cases, the MBWA modem can either be built-in or supplied through a card or a
11   peripheral device.
12        a) Laptop user: The large and rich display capabilities can be expected to generate
13           graphics-rich and multimedia-rich applications. In general, laptop users will
14           provide the highest data volume demands due to the storage and battery
15           capabilities of laptops. They can provide a full range of applications with perhaps
16           less emphasis on voice and WAP applications. Except for special cases, they tend
17           to be stationary during use.
18        b) PDA user: The display, battery, and storage capabilities are less than that of
19           laptops, and so they are expected to have somewhat less traffic volume. They can
20           be very portable. They are typically used for Web browsing, e-mail,
21           synchronization, video, and voice applications.
22        c) Smartphone user: These devices are very portable and very constrained display
23           and storage capabilities. It is expected that they will be oriented towards voice,
24           WAP, and light video.
25        d) Machine to machine (telematics, remote cameras etc.): These usage scenarios can
26             have a wide range of characteristics. In some remote monitoring/control
27             applications driven by specific events, the traffic is bursty. For remote
28             surveillance using continuous video feeds, the traffic is more like streaming. This
29             can be a potentially significant usage scenario for 802.20 systems, but the relevant
30             traffic characteristics may not have received as much study as a applications with
31             human users.
32   Since the various devices can have very distinct traffic characteristics, we will create
33   multiple traffic models for different usage scenarios of an application.
34   For example, web browsing is likely to have different statistical characteristics for laptop
35   and PDA scenarios. Rather than tie the models specifically to device types such as laptop
36   and PDA, we will adopt multiple versions of a traffic model with generic names, e.g. Web
37   Browsing A & Web Browsing B, or Web Browsing Heavy & Web Browsing Light. These
38   could have different statistical functions, or different parameters for the same function.

39   4.2.2 Basis for Traffic Models
40   Most traffic modeling work is based on measurements of real traffic, which are analyzed to
41   generate usable statistical descriptions. These are typically used in computer simulations
42   and can also be used to generate packet traffic for a real system under test. Since MBWA is


                                                                                                  2
     2005-5-16                                                             IEEE C802.20-05/25

 1   a future service that is similar to some existing wired systems, a lot of the basis of this
 2   section is the traffic modeling work done for wired systems. These provide a reasonable
 3   and realistic description of the potential user. Our approach is to use statistical models that
 4   can be used to generate a stream of packets that need to be transmitted over the system.
 5   We realize that characteristics of user applications keep changing. At best, one can develop
 6   a reasonable consensus model that is useful for bringing some uniformity in comparisons of
 7   systems. In particular, it is known that user traffic patterns change as the network
 8   performance changes. Traffic modeling work has attempted to adjust to this trend. For
 9   example, some of the traffic models such as Web and FTP try to capture the essence of the
10   user applications by describing the amount of data the user is trying to retrieve rather than
11   specifying a packet stream.
12   We specifically do not use the trace-based approach where a real recorded stream of
13   packets is played back for simulation. While traces can capture sophisticated details, such
14   traces have details that are often very dependant on the system from which they were
15   recorded, and do not provide flexibility for computer simulation work.

16   4.2.3 Adaptive applications
17   Certain applications such as audio streaming sense the available bit rate of the channel and
18   then adjust the amount of traffic that is transmitted. Certain multi-media sessions may
19   employ content-adaptation of images or video based on network conditions. This directly
20   changes the amount of data that is transmitted. The adaptive nature of applications can be
21   incorporated into the traffic model. We do not perceive a strong need for the adaptive
22   nature of an application to be incorporated as a dynamic feature of the traffic model. Such
23   adaptive behavior can be addressed by using traffic models with different parameters and
24   switching between them in an appropriate manner. Thus, adaptation of traffic
25   characteristics based on network/device conditions is outside the scope of this modeling.

26   4.3 Traffic Models
27   This section describes the traffic models in detail. Sections 4.3.1 and 4.3.2 clarify some
28   aspects of the modeling approach and the remaining sections provide detailed models for
29   traffic types listed in Table 1.
30                          Table 1 Characteristics of 802.20 Traffic Types
31   {D. Gal’s proposed changes: 1. sort the table rows by Traffic-Category 2. reduce the
32   number of simulated applications (a short-list is shown in bold font) }
33
34   {DG: clean new Table 1}
      #     Application           Traffic        Priority   Availability      Testing Variants
                                  Category       for        of
                                                 Evaluation suitable
                                                            traffic
                                                            models
      1     FTP                    Best-effort       High      Medium         Fixed
                                                                              /deterministic
                                                                              Heavy, Light
      2     PDA remote             Best-effort       Low           Low


                                                                                                    3
    2005-5-16                                                      IEEE C802.20-05/25


          synch
     3    File-sharing        Best-effort      Low          Low
     4    Broadcast /         Best-effort      Low          Low        High-rate, low-
          Multicast                                                    rate
     5    Telematics          Best-effort/     Low          Low
                               Real-time
     6    E-mail              Interactive/    Medium        Low        Heavy, Medium,
                              Best-effort                              Light,
                                                                       Non-interactive
                                                                       mode
     7    Web Browsing        Interactive      High         High       Heavy, Medium,
                                                                       Light
     8    WAP                 Interactive      High        High
     9    Multimedia          Interactive     Medium      Medium
          Messaging
     10   Instant             Interactive     Medium      Medium
          Messaging
     11   Gaming              Interactive     Medium        Low
     12   Audio Streaming     Streaming       Medium        Low        High-rate, low-
                                                                       rate
     13   Video Streaming     Streaming       Medium      Medium       High-rate, low-
                                                                       rate
     14   VoIP                Real-time        High         High       High-rate, low-
                                                                       rate
     15   Video Telephony     Real-time       Medium        High       Heavy, Light
1
2
3   {DG: proposed changes to Table 1}
     #    Application         Traffic        Priority   Availability   Testing Variants
                              Category       for        of
                                             Evaluation suitable
                                                        traffic
                                                        models
     1    FTP                 Best-effort        High      Medium      Fixed
                                                                       /deterministic

                                                                       Heavy, Light
     2    PDA remote          Best-effort      Low          Low
          synch
     3    File-sharing        Best-effort      Low          Low
     4    Broadcast /         Best-effort      Low          Low        High-rate, low-
          Multicast                                                    rate
     5    Telematics          Best-effort/     Low          Low
                               Real-time
     6    E-mail              Interactive/    Medium        Low        Heavy, Medium,


                                                                                          4
     2005-5-16                                                            IEEE C802.20-05/25


                                  Best-effort                                Light,
                                                                             Non-interactive
                                                                             mode
      7     Web Browsing          Interactive      High           High       Heavy, Medium,
                                                                             Light
      8     WAP                   Interactive      High          High
      9     Multimedia            Interactive     Medium        Medium
            Messaging
      10    Instant               Interactive     Medium        Medium
            Messaging
      11    Gaming                Interactive     Medium          Low
      12    Audio Streaming       Streaming       Medium          Low        High-rate, low-
                                                                             rate
      13    Video Streaming       Streaming       Medium        Medium       High-rate, low-
                                                                             rate
      14    VoIP                   Real-time       High           High       High-rate, low-
                                                                             rate
      15    Video Telephony        Real-time      Medium          High       Heavy, Light




 1

 2   4.3.1 User/Traffic Modeling Approach
 3   {DG: clean edited text}
 4   One of the objectives of a modeling and simulation exercise is to determine the number of
 5   users a MBWA system can support. The proposed approach here is to model traffic for
 6   active users that maintain a session with transmission activity. Such traffic models can be
 7   used to determine the number of active users that can be supported. The proposed models
 8   do not address the traffic arrival process.
 9   {DG: proposal – open the following statements for discussion. In section 4.4 we attempt to
10   define requirements for the simulation of system-wide traffic mix in conjunction with user
11   distribution - in the cells – and fairness criteria. We also attempt to determine the maximum
12   throughput available from the system under those constrains. Hence, the following
13   paragraph needs to be revised or deleted}
14   Modeling of an aggregated traffic load, generated by a number of active users for
15   background loading purposes, may not be feasible for a wireless network. Such modeling is
16   particularly difficult for systems that employ adaptive antenna technologies and for systems
17   that have complex channel dependencies. Therefore, our traffic models shall apply to a
18   single user terminal.


                                                                                                5
     2005-5-16                                                              IEEE C802.20-05/25

 1
 2   {DG: editorial changes}
 3   One of the objectives of a modeling and simulation exercise is to determine the number of
 4   users a MBWA system can support. The proposed approach here is to model traffic for
 5   active users that maintain a session with transmission activity. Such traffic models can be
 6   used to determine the number of active users that can be supported. The proposed models
 7   do not address the traffic arrival process.
 8   Modeling of an aggregated traffic load, generated by a number of active users for
 9   background loading purposes, may not be feasible for a wireless network. Such modeling is
10   particularly difficult for systems that employ adaptive antenna technologies and for systems
11   that have complex channel dependencies. Therefore, our traffic models shall apply to a
12   single user terminal.
13

14   4.3.2 Packet Generation
15   {DG: clean edited text}
16   In some of the traffic models, there is a statistical description of the workload or the content
17   of the application rather than the actual packet stream. This is consistent with the state of
18   the art of evaluation techniques of multi-service data systems. For example, the Web
19   browsing model describes the Web pages and the timing between the Web pages.
20   Depending on the details of the underlying TCP model (e.g. MTU size, max receive
21   window) and the HTTP protocol version (HTTP v1.0 v. HTTPv1.1), the actual stream of
22   packets will vary. In other applications, such as VoIP, the traffic models may describe the
23   packet stream more specifically.
24
25   {DG: editorial changes}
26   In some of the traffic models, there is a statistical description of the workload or the content
27   of the application rather than the actual packet stream. This is consistent with the state of
28   the art of evaluation techniques of multi-service data systems. For example, the Web
29   browsing model describes the Web pages and the timing between the Web pages.
30   Depending on the details of the underlying TCP model (e.g. MTU size, max receive
31   window) and the HTTP protocol version (HTTP v1.0 v. HTTPv1.1), the actual stream of
32   packets will vary. In other applications, such as VoIP, the traffic models may describe the
33   packet stream more specifically.
34

35   4.3.3 Web Browsing
36   Web browsing is the dominant application for broadband data systems, and has been
37   studied extensively. See references […..]
38   The parameters for web browsing traffic are as follows:
39   SM: Size of the main object in a page
40   SE: Size of an embedded object in a page
41   Nd: Number of embedded objects in a page
42   Dpc: Reading time
43   Tp: Parsing time for the main page
44


                                                                                                   6
    2005-5-16                                                                IEEE C802.20-05/25


1   Table 2 HTTP Traffic Model Parameters

    Component        Distribution     Parameters               PDF


    Main object      Truncated        Mean = 10710 bytes                1   ln x   2 
    size (SM)        Lognormal        Std. dev. = 25032         fx               exp     , x  0
                                                                 2x      2 2
                                                                                          
                                                                                           
                                      bytes
                                      Minimum = 100 bytes   1.37,   8.35
                                      Maximum = 2 Mbytes
    Embedded         Truncated        Mean = 7758 bytes                 1       ln x   2 
    object size      Lognormal        Std. dev. = 126168        fx               exp         , x  0
    (SE)
                                                                      2x     2 2
                                                                                              
                                                                                               
                                      bytes
                                      Minimum = 50 bytes         2.36,   6.17
                                      Maximum = 2 Mbytes
                                                                         
    Number of        Truncated        Mean = 5.64                    k
    embedded         Pareto           Max. = 53                 f x   1 , k  x  m
    objects per                                                       x
                                                                            
    page (Nd)
                                                                        
                                                                        k
                                                                fx         ,x  m
                                                                        
                                                                        m
                                                                  1.1, k  2, m  55


                                                               Note: Subtract k from the
                                                               generated random value to
                                                               obtain Nd
    Reading time     Exponential      Mean = 30 sec                       x
                                                                f x  e      ,x  0
    (Dpc)
                                                                  0.033


    Parsing time     Exponential      Mean = 0.13 sec                       x
                                                                f x  e          ,x  0
    (Tp)
                                                                  7.69

2
3   Note: When generating a random sample from a truncated distribution, discard the random
4   sample when it is outside the valid interval and regenerate another random sample.
5

6   4.3.4 FTP
7   In FTP applications, a session consists of a sequence of file transfers, separated by reading
8   times. The two main parameters of an FTP session are:
9    S : the size of a file to be transferred




                                                                                                     7
     2005-5-16                                                                    IEEE C802.20-05/25


 1   D pc : reading time, i.e., the time interval between end of download of the previous file and
 2   the user request for the next file.
 3   The underlying transport protocol for FTP is TCP. The parameters for the FTP application
 4   session are described in Table 3.
 5                                Table 3 FTP Traffic Model Parameters

     Component        Distribution       Parameters            PDF

     File size (S)    Truncated          Mean = 2Mbytes
                                                                           1    ln x   2 
                      Lognormal          Std. Dev. = 0.722      fx              exp          , x  0
                                                                     2 x     2 2           
                                         Mbytes                                               
                                         Maximum = 5             0.35,   14.45
                                         Mbytes


     Reading time     Exponential        Mean = 180 sec.                   x
                                                                f x  e         ,x  0
     (Dpc)
                                                                 0.006

 6

 7   4.3.5 Voice (VoIP)
 8   {DG: clean edited text}
 9   The voice traffic model will be implemented as voice over IP (VoIP). Voice data traffic
10   will, in general, follow a Markov source model with different encoding rates (full rate, half
11   rate, etc) and corresponding rate-transition probabilities.
12
13   {DG: proposed editorial changes}
14   The voice traffic model will be implemented as voice over IP (VoIP). Voice data traffic
15   will, in general, follow a Markov source model with different encoding rates (full rate, half
16   rate, etc) and corresponding rate-transition probabilities.

17   4.3.6 Video (Video telephony / Video conferencing)
18   [Needs contribution/Berlin]

19   4.3.7 Audio streaming
20   This can be an important class of traffic. It has received relatively less attention in the
21   modeling community. (See [Error! Reference source not found.Error! Reference
22   source not found.])
23   [Further contribution on Audio Streaming is needed/Berlin]

24   4.3.8 Video streaming
25   The following section describes a model for streaming video traffic on the forward link.
26   Figure 1 describes the steady state of video streaming traffic from the network as seen by
27   the base station. Latency of starting up the call is not considered in this steady state model.



                                                                                                          8
     2005-5-16                                                                      IEEE C802.20-05/25


                                      Video Streaming Session (= simulation time)




                                                                                                                    time

          0                            T                            2T     (K-1)T                          KT
              TB (Buffering Window)

                                                 DC (Packet                         Packet Size
                                                Coding Delay)
 1
 2
 3                            Figure 1 Near Real-Time Video Traffic Model
 4   A video streaming session is defined as the entire video and associated audio streaming call
 5   time, which is equal to the simulation time for this model.
 6   Each frame of video data arrives at a regular interval T determined by the number of
 7   frames per second (fps). Each frame is decomposed into a fixed number of slices, each
 8   transmitted as a single packet. The size of these packets/slices is distributed as a truncated
 9   Pareto. Encoding delay, Dc, at the video encoder introduces delay intervals between the
10   packets of a frame. These intervals are modeled by a truncated Pareto distribution. The
11   parameter TB is the length (in seconds) of the de-jitter buffer window in the mobile station
12   used to guarantee a continuous display of video streaming data. This parameter is not
13   relevant for generating the traffic distribution but is useful for identifying periods when the
14   real-time constraint of this service is not met. At the beginning of the simulation, it is
15   assumed that the mobile station de-jitter buffer is full with (TB x source video data rate) bits
16   of data. Over the simulation time, data is “leaked” out of this buffer at the source video
17   data rate and “filled” as forward link traffic reaches the mobile station. As a performance
18   criterion, the simulation shall record the length of time, if any, during which the de-jitter
19   buffer runs dry. Option 1: The de-jitter buffer window for the video streaming service is 5
20   seconds.
21   Option 2:
22   The de-jitter buffer window for the video streaming service is a maximum of 5 seconds.
23    [need to confirm if the de-jitter buffer window size of 5 seconds needs to be changed for
24   the higher data rate]
25   Using a source rate of 64 kbps, the video traffic model parameters are defined Table 4.
26
27                      Table 4 Near Real-Time Video Traffic Model Parameters

        Information      Inter-arrival Number of       Packet (slice)                Inter-arrival time
        types            time between packets (slices) size                          between packets
                         the beginning in a frame                                    (slices) in a frame
                         of each frame



                                                                                                                9
     2005-5-16                                                                     IEEE C802.20-05/25


        Distribution       Deterministic Deterministic        Truncated             Truncated Pareto
                           (Based on                          Pareto                (Mean= 6ms,
                           10fps)                             (Mean=                Max= 12.5ms)
                                                              50bytes, Max=
                                                              125bytes)
        Distribution       100ms             8                K = 20bytes           K = 2.5ms
        Parameters                                             = 1.2                = 1.2
 1

 2   4.3.9 Wireless Multi-Party Gaming Traffic
 3   [Note: It was noted over the 12/2 conference call that wireless gaming is an important
 4   application that needs to be considered in 802.20 system evaluation. Input required on
 5   mobile wireless gaming models.]
 6   [Note 1: Options from contribution C802.20-04/86 and C802.20-05/06 are included
 7   below:]
 8   Some types of multi-player games may have demanding requirements on response times.
 9   Option 1: Modify 3GPP2 model, to include DL characteristics as in Faber [2002]:
10   This section describes a model for mobile network gaming traffic on the forward link and
11   reverse link. This model is a combination of a standardized reverse link model (see
12   cdma2000 Evaluation Methodology, C.P1002, Version 0.3, July 2004) and a forward link
13   model developed from the research literature.

14   4.3.9.1 Reverse Link Model
15   Table 5 describes the parameters for the mobile network gaming traffic on the reverse link.
16               Table 5 Mobile Reverse Link network gaming traffic model parameters
             Component        Distribution       PDF and generation method



             Initial          Uniform (a=0,                  1
                                                 f ( x)           a xb
             packet           b=40ms)                       ba
             arrival
             Packet           Deterministic
             arrival          (40ms)
             Packet size      Extreme                              xa       xa
                                                               1  b e  b
                              (a=45 bytes, b     f ( x)  e                e        ,b  0
                              = 5.7)                           b
                                                 X  a  b ln  ln Y  , Y  U (0,1)
                                                 Because packet size has to be integer
                                                 number of bytes, the largest integer less
                                                 than or equal to X is used as the actual
                                                 packet size.
             UDP header       Deterministic
                              (2bytes)



                                                                                                       10
     2005-5-16                                                                           IEEE C802.20-05/25

 1   This model uses Largest Extreme Value distribution for the packet size. For cellular system
 2   simulation, 2-byte UDP header (after header compression) should be added to the packet
 3   size X . Because the packet size has to be an integer number of bytes, the largest integer
 4   less than or equal to X is used as the actual packet size. To simulate the random timing
 5   relationship between client traffic packet arrival and reverse link frame boundary, the
 6   starting time of a network gaming mobile is uniformly distributed within [0, 40ms].
 7   A maximum delay of 160ms is applied to all reverse link packets, i.e., a packet is dropped
 8   by the mobile station if any part of the packet have not started physical layer transmission,
 9   including HARQ operation, 160ms after entering the mobile station buffer.. A packet can
10   start physical layer transmission at the 160ms time instant. Packet dropping should be the
11   last operation of mobile station buffer management, if any, at any time instant. The packet
12   delay of a dropped packet is counted as 180ms.
13   A mobile network gaming user is in outage if the average packet delay is greater than
14   60ms. The average delay is the average of the delay of all packets, including the delay of
15   packets delivered and the delay of packets dropped.

16   4.3.9.2 Forward Link Model
17   Table 6 describes the parameters for the mobile network gaming traffic on the forward
18   link.
19                  Table 6 Forward Link network gaming traffic model parameters
             Component      Distribution      PDF and generation method



             Initial        Uniform (a=0,                 1
                                              f ( x)          a xb
             packet         b=40ms)                      ba
             arrival
             Packet         Extreme
             arrival        (a=55, b=6)
             Packet size    Extreme                            xa            
                                                                                  xa
                                                       1                e
                                               f ( x)  e                               ,b  0
                                                                                   b
                            (a=120 bytes,                       b
                                                                     e
                            b = 36)                    b
                                               X  a  b ln  ln Y  , Y  U (0,1)
                                              Because packet size has to be integer
                                              number of bytes, the largest integer less
                                              than or equal to X is used as the actual
                                              packet size.
             UDP header     Deterministic
                            (2bytes)
20
21   This model uses Largest Extreme Value distribution for the packet size. For cellular system
22   simulation, a 2-byte UDP header (after header compression) should be added to the packet
23   size X . Because the packet size has to be an integer number of bytes, the largest integer
24   less than or equal to X is used as the actual packet size. To simulate the random timing
25   relationship between client traffic packet arrival and reverse link frame boundary, the
26   starting time of a network gaming mobile is uniformly distributed within [0, 40ms].


                                                                                                          11
     2005-5-16                                                             IEEE C802.20-05/25

 1   A maximum delay of 160ms is applied to all reverse link packets, i.e., a packet is dropped
 2   by the mobile station if any part of the packet have not started physical layer transmission,
 3   including HARQ operation, 160ms after entering the mobile station buffer.. A packet can
 4   start physical layer transmission at the 160ms time instant. Packet dropping should be the
 5   last operation of base station buffer management, if any, at any time instant. The packet
 6   delay of a dropped packet is counted as 180ms.
 7   A mobile network gaming user is in outage if the average packet delay is greater than
 8   60ms. The average delay is the average of the delay of all packets, including the delay of
 9   packets delivered and the delay of packets dropped.
10
11   Option 2: Adopt or modify 3GPP model
12   Option 3: Combine the best of the two models
13   Option 4: Develop an 802.20 model based on more recent literature

14   4.3.10 Full buffers (Infinite backlog) model
15   In the full buffers (Infinite backlog) user traffic model, all the users in the system always
16   have data to send or receive. In other words, there is always a constant amount of data that
17   needs to be transferred, in contrast to bursts of data that follow an arrival process. This
18   model allows the assessment of the spectral efficiency of the system independent of actual
19   user traffic distribution type.

20   4.4 Traffic Mix
21   {DG: clean edited text}
22   A MBWA system is expected to support a mix of simultaneous traffic types. There can be
23   different types of usage scenarios (multi-service v. single-type), different types of devices
24   (laptops v. PDAs), different usage levels (intense v. light) and different delay/latency
25   requirements (real-time v. best-effort).
26   The previous sections are primarily concerned with the traffic models for each of the
27   potential traffic types. As discussed in the previous section, these models are based on
28   statistical analysis of measured traffic that yielded some invariant patterns that are not
29   very dependant on the specific system. It is more difficult to describe a similar invariant
30   mix of traffic types since these tend to depend more heavily on the type of system and the
31   actual deployment mix of user device types.
32   In the context of system performance evaluation, using traffic models, the specific traffic-
33   mix should emphasize different aspects of the system performance, e.g. sustained
34   throughput for file downloads v. faster response times for interactive applications.
35
36   {DG: proposed NEW text}
37   A short list of representative applications and their corresponding percentage in a simulated
38   system-wide traffic mix is shown in Table 7.
39
40   {DG: revised Table 7 with proposed traffic mix percentages}
41
42                     Table 7 Traffic mix: percentage of different Traffic Types
             Traffic Category       Application                       Percentage ( % )



                                                                                                 12
     2005-5-16                                                              IEEE C802.20-05/25


             Best Effort            FTP                                        10
                                    E-mail                                     10
             Interactive            Web browsing                               20
                                    Instant Messaging                           5
                                    Gaming                                      5
             Streaming              Video streaming                            10
             Real-time              VoIP                                       25
                                    Video Telephony                            15
 1
 2
 3   {DG: proposed changes}
 4   A MBWA system is expected to support a mix of simultaneous traffic types. There can be
 5   different types of usage scenarios (multi-service v. single-type), different types of devices
 6   (laptops v. PDAs), different usage levels (intense v. light) and different delay/latency
 7   requirements (real-time v. best-effort).
 8
 9   The previous sections are primarily concerned with the traffic models for each of the
10   potential traffic types. As discussed in the previous section, these models are based on
11   statistical analysis of measured traffic that yielded some invariant patterns that are not very
12   dependant on the specific system. It is more difficult to describe a similar invariant mix of
13   traffic types since these tend to depend more heavily on the type of system and the actual
14   deployment mix of user device types.
15
16   In the context of system performance evaluation, using traffic models, the specific traffic-
17   mix should emphasize different aspects of the system performance, e.g. sustained
18   throughput for file downloads v. faster response times for interactive applications. [Editor’s
19   note: This needs to be discussed] [Note from CC on April 19: Dan Gal has agreed to
20   submit a contribution to clarify this section]
21
22                     Table 8 Traffic mix: percentage of different Traffic Types

             Traffic Category               Application               Percentage ( % )
             Best Effort            FTP                                     10
                                    E-mail                                  10
             Interactive            Web browsing                            20
                                    Instant Messaging                        5
                                    Gaming                                   5
             Streaming              Video streaming                         10
             Real-time              VoIP                                    25
                                    Video Telephony                         15



                                    telephony/



                                                                                                  13
    2005-5-16                                                       IEEE C802.20-05/25




1
2   [Editor’s note: Table 7 needs to be filled with table/Berlin]




                                                                                     14

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:10
posted:3/22/2011
language:English
pages:15