scispace - formally typeset
Search or ask a question
Proceedings ArticleDOI

Characterizing user behavior and network performance in a public wireless LAN

TL;DR: The goals of this study are to extend the understanding of wireless user behavior and wireless network performance, and to characterize wireless users in terms of a parameterized model for use with analytic and simulation studies involving wireless LAN traffic.
Abstract: This paper presents and analyzes user behavior and network performance in a public-area wireless network using a workload captured at a well-attended ACM conference. The goals of our study are: (1) to extend our understanding of wireless user behavior and wireless network performance; (2) to characterize wireless users in terms of a parameterized model for use with analytic and simulation studies involving wireless LAN traffic; and (3) to apply our workload analysis results to issues in wireless network deployment, such as capacity planning, and potential network optimizations, such as algorithms for load balancing across multiple access points (APs) in a wireless network.

Summary (8 min read)

1.1 Introduction

  • The Logic Circuit Simulation Language (LCSL) has been built to design logical circuits in a new, intuitive way.
  • The classical approach to building circuits has always been using declarative hardware design languages, mainly because the building blocks used in these declarative programs are how the circuits are actually mapped out in the hardware.
  • But on a conceptual level, human beings think of circuits in a different way; that of a web of functions that have inputs and outputs.
  • With its functional programming philosophy, LCSL allows users to design circuits at a highly conceptual level.
  • LCSL then transforms the code into the code of the popular declarative HDL Verilog so that the circuit can be simulated and synthesized.

1.2 Background

  • The logic circuit is an integral part of the transistors that are in virtually all aspects of computational electronics—from the airbags in a car to the alarm in a watch.
  • The representation of these values varies through different technologies, whether it is a high or low voltage at a very low hardware level or Boolean representations of true and false in a highlevel programming language.
  • Logic circuits act as a physical representation of a mathematical or logical function between a set of inputs and a set of outputs.
  • More and more, software and simulation is becoming an essential part of most fields of experimentation.
  • Designing a digital logic circuit on a computer and simulating it with various inputs allows electrical engineers to tweak and prod at their discretion without the expense of materials or loss of valuable time.

1.4.1 Simplicity

  • The main purpose of designing this language was to make it conceptually easier to design a circuit.
  • LCSL translates its code into comparable Verilog that can be used for simulation and synthesis.
  • By focusing specifically on the conceptual design, the authors made their code less verbose and easier to understand than Verilog.

1.4.2 Portability

  • LCSL is developed through the Java programming language, and implicitly, via the Java Virtual Machine.
  • Because hardware-specific JVMs have been developed for almost all platforms, Java has become famous for being a highly portable language.
  • Because LCSL is based on Java, it inherits the quality of portability.

1.4.3 Modularity

  • Like other hardware design languages, LCSL maintains the notion of being able to define circuits as black boxes.
  • Different modules can be defined encompassing one or more circuits or even one or more other modules.
  • This type of compartmentalization resembles object-oriented programming where a user doesn’t have to know how a module works but what inputs it needs and what outputs it gives.

1.4.4 Flexibility

  • With LCSL, you no longer has to be bound to the limits of programming sequentially.
  • LCSL gives you quite a bit of room to work under since there is no artificial constraint of requiring wires to be connected in a certain order.
  • Wires can also be left unconnected and optionally connected inside the component itself (like input wires).

1.4.5 Error Avoidance

  • With a functional programming interface, many common mistakes that are encountered in imperative programming are completely avoided.
  • One example is the “off by one” bug which, as you could imagine, would be a very important error to avoid when it comes to circuit design.

1.5 Features

  • Components are defined like methods representing a specific function, but they can be instantiated and referenced like Java objects.
  • Also like objects, components allow access to the parameters that are inputted and outputted to the function definition.

1.5.2 Recursion

  • Recursive programming has never been associated with circuit design… until now.
  • With LCSL, you can recursively call components that make your design much easier to understand conceptually.
  • Another example is a component that has within its definition instances of itself forming a tree-like recursive structure.
  • Recursion saves time and space and also is extremely simple.
  • Anyone can look at the code and understand what the main component is supposed to do.

1.5.3 Overloading

  • Another great feature of LCSL is the concept of overloading.
  • All these operations are actually just built-in component definitions, basically making each operation symbol (such as + for adding) the name of the component.
  • If you simply create a new component with the same name, your component overrides the built-in component in whatever scope you’re working under.
  • This can come in very handy when you want to slightly tweak a built-in operation for experimentation or simply don’t need that built-in function and could use the operator for a completely different function that is more important to your project.
  • Note, however, that names cannot be overloaded in the same environments where they already appear, or a duplication error occurs.

2.1 Simple Example

  • A component can be though of as similar to a function, where parameters are inputted and a value or values are outputted.
  • The authors define a component with the comp keyword.
  • The authors are defining an instance of Xor (which is a component) and assigning it to the Sys variable.
  • The same is done in the next line, and then VectorOutput is used to define the out port in the Verilog code.
  • The next line also uses an instance of Set, but this time it is used to specify the name of the file that LCSL will output the Verilog code to.

2.2 Compilation/Simulation of Simple Example

  • Once the example has been saved into a file, the authors can begin the compilation process.
  • To compile, the authors did the following (assuming the LCSL package is in the class path and they are in the same directory as the file): $ java –jar LCSL.jar xor.lcsl.
  • In order to run the Verilog code, the authors use the testbench file they specified in the program.
  • Yes, the authors understand that for simulation you do need to know a little Verilog, but trust us, the code needed in test bench is very easy to understand and write, and LCSL saved you time on the really hard stuff which is the creation of the main module that you’re simulating in the first place.
  • Instead of writing tedious Verilog code for it, a few lines in LCSL were all that was needed!.

2.3 A more complex example… with recursion!

  • As mentioned in Chapter 1, LCSL can do recursion which shows how highly abstract this language is.
  • The authors have included an if statement which is necessary for any recursion example as a base case is needed to stop the recursion at some point.
  • The component Xor is called for the least significant bit of the two “in port” vectors (which must be of equal size), and then BusXor is recursively called for the rest of the bits of the vector.
  • The authors then create an instance of this component and assign it to Sys and then use the same built-in components as in the simple example.
  • What is actually happening in both lines is that instances are in fact created and assigned to dummy variables.

3.1.2 Variables

  • Variables consist solely of alphanumeric characters and underscores.
  • The first character must always be an uppercase letter (A-Z) and the last character can never be an underscore (“_”).

3.1.5 Strings and Vectors

  • Strings use Java-like syntax with an ASCII character string surrounded by double quotes (ex. “Hello World”).
  • Both Strings and Vectors will be explained fully in the next section.

3.2 Types

  • LCLS includes common types as integer, Boolean, or string.
  • Since it is a circuit design language, its more specific types are vectors, components, and systems.
  • Components can be passed into other components and instantiated in there.
  • LCSL is not strongly typed in the sense that variables need not be given a type in advance.
  • The types of the entries that variable resolve to are checked for consistency when various primitives are applied to them.

3.2.3 Vectors

  • Vectors are fundamental data types that are similar to bit-vectors in hardware design languages and consist of basic logical bit values (0 and 1).
  • Vectors can be created by writing them directly between < and > and connecting this string to a variable.

3.2.5 Components

  • Components are similar to functions in other languages that can pass into and return from other components.
  • This is a primary feature of LCSL and is a characteristic of its functional programming nature.
  • Components are declared using the comp keyword.
  • The inputs must be listed before any output port.
  • The body of the component, which is a set of statements, follows the port definitions.

3.2.6 Systems

  • Systems represent an actual instance of a component.
  • A variable becomes a Sys type when it is connected to an instance of a component with specific input and output port values given.
  • Because systems are actually environments, they incur some constraints: they cannot be passed in and out of components, and must be available at the time hierarchical names are evaluated.

3.3.3 Vector Operators

  • The following is a table for operations of vectors.
  • Operator Function X ‘ [int] bit selection ~ X bitwise negation ‘width’ X vector width ‘msb’ X most significant bit ‘msbs’.

3.4.1 Expression Syntax

  • Expressions in LSCL are based on the conceptual notion of source expressions and sink expressions.
  • Source expressions produce values whereas sink expressions consume values.

3.4.3 Source Expressions

  • As mentioned above, source expressions produce values.
  • The following are valid source expressions: Variables Constants (integer, Boolean, or Vector) Connections Instantiations Conditionals Component definitions Operational expressions Expression groupings of any combination of above.

3.4.3 Sink Expressions

  • As mentioned above, sink expressions consume values.
  • Only variables may be used as outputs of source expressions.

3.5.2 Instantiations

  • Instantiations can be run on their own without being bounded to a sink variable.
  • This is because the out ports of the system are sinks themselves, so there is at least one thing being outputted to a sink variable anyway.
  • In case the authors want certain ports of the system not to be specified because they’re unimportant, they can bypass certain ports with an underscore like this : {Xor, Input1 _ Input3, Output}.
  • Here the second in port is given no value.
  • There are a few built-in instantiation systems that the authors will mention now.

3.5.3 VectorInput and VectorOutput

  • This system is used to input a vector into port lists of modules created in Verilog.
  • The syntax can be seen in the following example {VectorInput, “Input1” 1 4, X} The string “Input1” represents the name of the vector put in the port list in Verilog.
  • The next parameter is 1 which represents the position within the port list that’s the vector is being assigned to.
  • Finally, the parameter that’s in the output position of the system is the variable X which represents the bit vector in LCSL that will be used as the input vector.
  • This vector will be assigned to the LCSL vector variable A.

3.5.4 Set

  • Another special and very important built-in instantiation system is Set.
  • This allows the user to set necessary environmental variables such as the filename of the output Verilog file and the module name within that file.

4.1 Team Responsibilities

  • Early on, the authors decided on four roles that would help us become specialized in a specific field and help make the project more efficient and organized.
  • Here are all of their roles: Bogdan Caprita Complete Java back end, Verilog output Sachin Nene Documentation ANTLR Grammar/Parser/Walker Julian Maller ANTLR Grammar/Parser/Walker CVS Administrator Chaue Shen Tester, Confluence Tester.

4.2 Programming Style Guide

  • Because all four of us specialized in different fields that were all essential to this project, the authors all added different pieces to the entire code of this language.
  • By using a strict approach to checking out and checking in source files, the authors avoided mix-ups and errors from different people editing the same piece of code.
  • Because the back end was completely done in Java, the authors utilized it’s objectoriented philosophy by creating a good set of APIs.
  • The same could be said for the back end developer.
  • He could be assured that the main object he was being fed from the tree walker would meet his specifications exactly.

4.3 Software Project Environment

  • The entire back end was written in Java, and the lexer and parser was written in ANTLR.
  • The Verilog code produced by the back end was tested on the Icarus Verilog compiler.
  • All code was managed through CVS on a Linux machine.

4.3.3 Icarus

  • To test the Verilog code that the authors created from LCSL, they used the widely popular open source Icarus Verilog compiler.
  • The main reason the authors chose this compiler was probably because it’s free.
  • The compiler was installed on Julian’s Linux machine.

4.3.3 ANTLR

  • The authors workload was drastically reduced by using ANTLR in the process of creating their grammar, parser, and walker.
  • ANTLR syntax is simple to understand, and the language is powerful enough to correctly implement the abstract syntax tree the authors desired.
  • Not only this, ANTLR was also allowed us to easily transform the AST to an object-based LCSL tree which was necessary as input for the back end.

5.1 Block Diagram

  • LEXER PARSER WALKER LCSL source code Tokens ANTLR AST Tree LCSL Tree Exception Handler FORCER MyModule.v TestBench.v Verilog Compiler Verilog Testbench EVALUATOR.
  • Force table and Environment Hierarchy Verilog Module.

5.2.1 The Functional Programming Model

  • LCSL is meant to leverage the functional programming paradigm in designing logical circuits.
  • In some aspects such as evaluation order, or variable binding, LCSL is more pure of a functional language than SCHEME or other dialects of Lisp.
  • Since their language is geared towards hardware design, the authors have called their functions components.
  • LCSL components are declared anonymous, and can optionally be bound to variables or passed as inputs to other components.
  • B is mere syntactic sugar for instantiating the primitive component named ‘+’).

5.2.2 β-reduction

  • The more interesting phase of compilation in LCSL is β-reduction.
  • 1 Harold Abelson, Jay Sussman, and Julie Sussman.
  • This is a natural property of the functional unit that the authors are abstracting (sub-circuit as a black box with wires going in and out), but involves separate steps to bind each of the outputs.
  • Asking the designer to specify and assign values to all of the variables used seems an artificial constraint that can be an unnecessary burden to the electrical engineer unaccustomed to mainstream imperative programming.
  • Therefore, while in SCHEME applying a function is synonymous to setting up a new environment, evaluating its arguments and body and returning a value, the authors have separated the instantiation of a component from the binding of its ports and from the actual evaluation and value-forcing.

5.2.3 Variable binding and name lookup

  • In LCSL, all names are resolved through environments.
  • There is a global environment in which the main body of a program is evaluated, as well as where the built-in primitive components are linked to their names.
  • A vector is similar to a Verilog wire, and any operations involving vectors (either in the form of wires or literal 0/1 bit vectors) are either optimized away by the compiler or converted to corresponding Verilog code that would perform de desired calculations.
  • LCSL strictly respects the unique binding rule: names can be assigned to at most once.
  • This helps the conceptual design of circuits, where wires, once laid out, are there to stay.

5.2.4 Evaluation and forcing

  • The evaluation step passes through the LCSL Expression tree and does a minimal amount of work, the most important of which are setting up environments for systems and creating thunks for names.
  • It is essentially a name/environment pair that specifies the environment where a name needs to be forced in order to retrieve an actual final value.
  • The forcing phase than initiates recursive forcing of thunks that call up a chain of component body evaluations, variable lookups, primitive applications, or other thunk forcing.
  • Some evaluation braches may never be traversed, If, on the other hand, C <- E for some E, the code involving A and B will not be evaluated and the program will output the Verilog code with the correct functionality intended by the designer.

5.3 Authors of Components

  • The entire back end system which is encapsulated in what the authors call the evaluator and forcer was designed and implemented by Bogdan Caprita.
  • The grammar was worked on by all four members of the group, and the parser and walker were designed and implemented by Julian Maller and Sachin Nene.
  • Exception handling in the back end was done by Bogdan while exception handling on the front end was automatically done for us by ANTLR.

6.1 Early Testing

  • The LCSL syntax is based on the syntax of the Confluence hardware design language which is another HDL that uses a functional programming interface for abstract design.
  • These early Confluence files were not syntactically correct but rather were written to test specific aspects of the language.
  • Eventually, these files would be used for regression testing.
  • The authors first examples were a simple XOR gate and an XOR gate implemented through recursion.
  • While logically simple, their first LCSL programs were very momentous and verified that their compiler actually outputted Verilog code.

6.3 Running Verilog Code

  • In order to test their Verilog the authors had to install Icarus and write test benches for each of their LCSL files.
  • In order to streamline the process the authors added functionality to the compiler that would automatically generate a test bench for the outputted Verilog.
  • To do this, insert the following two lines of code to your LCSL files:.
  • To actually run and test the Verilog enter the following two command prompt commands after compiling the LCSL file.
  • This will output all possible combinations of inputs to the circuit (inputs are all vectors using the VectorInput primitive) and the outputs that the particular sequence of inputs generates.

6.4 Regression Testing

  • After having a suite of test cases and the ability to generate the truth tables for the Verilog their compiler outputted for the test cases the authors could then write a script to use for sequential testing.
  • This script simply compiles the test suite and runs the outputted Verilog.
  • In doing so the authors were able to make changes to the compiler and automatically test to see if their new changes had caused any problems with code that was working previously.
  • Sequential testing was also very useful in testing alternative syntax because altering a LCSL file without altering the logic would not change the resulting truth table.
  • Section A.4. Chapter 7 Lessons Learned.

7.1 Each Member’s Lessons Learned

  • Sachin Nene- Working on LCSL this semester was quite an experience.
  • Lastly, I found it very difficult as tester to keep up to date on how the different aspects of the project were going.
  • Working on a group project over an extended period of time, I have come to value the advantages of team work.
  • I learned that a good project needs good humor to get it moving.
  • The other major lesson was to make an overall plan for executing the project, and stick to it.

Did you find this useful? Give us your feedback

Content maybe subject to copyright    Report

LCSL
Logic Circuit Simulation Language
Bogdan Caprita, Julian Maller, Sachin Nene, Chaue Shen
December 19, 2003

1
Chapter 1......................................................................................................................................... 4
Introduction.................................................................................................................................... 4
1.1 Introduction ......................................................................................................................... 4
1.2 Background .......................................................................................................................... 4
1.3 Related Work....................................................................................................................... 5
1.4 Goals ..................................................................................................................................... 6
1.4.1 Simplicity...................................................................................................................... 6
1.4.2 Portability..................................................................................................................... 6
1.4.3 Modularity.................................................................................................................... 6
1.4.4 Flexibility ...................................................................................................................... 6
1.4.5 Error Avoidance .......................................................................................................... 6
1.5 Features ................................................................................................................................6
1.5.1 Components.................................................................................................................. 6
1.5.2 Recursion ...................................................................................................................... 7
1.5.3 Overloading .................................................................................................................. 7
Chapter 2......................................................................................................................................... 8
Tutorial............................................................................................................................................ 8
2.1 Simple Example ................................................................................................................... 8
2.2 Compilation/Simulation of Simple Example ..................................................................... 9
2.3 A more complex example… with recursion! ................................................................... 10
Chapter 3....................................................................................................................................... 12
Reference Manual ........................................................................................................................ 12
3.1 Lexical Conventions .......................................................................................................... 12
3.1.1 Comments................................................................................................................... 12
3.1.2 Variables..................................................................................................................... 12
3.1.3 Keywords.................................................................................................................... 12
3.1.4 Operators.................................................................................................................... 12
3.1.5 Strings and Vectors.................................................................................................... 12
3.2 Types................................................................................................................................... 12
3.2.1 Integers ....................................................................................................................... 13
3.2.2 Booleans...................................................................................................................... 13
3.2.3 Vectors ........................................................................................................................ 13
3.2.4 Strings ......................................................................................................................... 13
3.2.5 Components................................................................................................................ 13
3.2.6 Systems........................................................................................................................ 13
3.3 Type Operators.................................................................................................................. 13
3.3.1 Integer Operators ...................................................................................................... 14
3.3.2 Boolean Operators ..................................................................................................... 14
3.4 Expressions......................................................................................................................... 15
3.4.1 Expression Syntax...................................................................................................... 15
3.4.2 Basic Expressions....................................................................................................... 15
3.4.3 Source Expressions .................................................................................................... 16
3.4.3 Sink Expressions ........................................................................................................ 16
3.5 Statements .......................................................................................................................... 16
3.5.1 Connections ................................................................................................................ 17
3.5.2 Conditionals................................................................................................................ 17
3.5.2 Instantiations.............................................................................................................. 17
3.5.3 VectorInput and VectorOutput ................................................................................ 17

2
3.5.4 Set................................................................................................................................18
Chapter 4....................................................................................................................................... 19
Project Plan................................................................................................................................... 19
4.1 Team Responsibilities........................................................................................................ 19
4.2 Programming Style Guide ................................................................................................ 19
4.3 Project Timeline................................................................................................................. 20
4.3 Software Project Environment......................................................................................... 20
4.3.1 Operating Systems ..................................................................................................... 20
4.3.1 Java 1.4.2 .................................................................................................................... 20
4.3.2 CVS ............................................................................................................................. 20
4.3.3 Icarus .......................................................................................................................... 21
4.3.3 ANTLR ....................................................................................................................... 21
4.4 Project Log ......................................................................................................................... 21
Chapter 5....................................................................................................................................... 22
Architecture Design...................................................................................................................... 22
5.1 Block Diagram ................................................................................................................... 22
5.2 Description of Architecture .............................................................................................. 23
5.2.1 The Functional Programming Model....................................................................... 23
5.3 Authors of Components .................................................................................................... 26
Chapter 6....................................................................................................................................... 27
Testing Plan .................................................................................................................................. 27
6.1 Early Testing...................................................................................................................... 27
6.2 Our compiler works! ......................................................................................................... 27
6.3 Running Verilog Code....................................................................................................... 28
6.4 Regression Testing............................................................................................................. 28
Chapter 7....................................................................................................................................... 30
Lessons Learned ........................................................................................................................... 30
7.1 Each Member’s Lessons Learned .................................................................................... 30
Appendix A ................................................................................................................................... 32
Appendix A ................................................................................................................................... 32
Source Code .................................................................................................................................. 32
A.1 Front End .......................................................................................................................... 32
A.1.1 Lexer .......................................................................................................................... 32
A.1.2 Parser ......................................................................................................................... 36
A.1.3 Walker........................................................................................................................ 39
A.2 Back End ........................................................................................................................... 45
A.2.1 Admin.java ................................................................................................................ 45
A.2.2 ApplyFailedException.java ...................................................................................... 56
A.2.3 Assignment.java ........................................................................................................ 56
A.2.4 BadVerilogException.java........................................................................................ 58
A.2.5 BitVector.java............................................................................................................ 58
A.2.6 BitWire.java .............................................................................................................. 58
A.2.7 Bool.java .................................................................................................................... 60
A.2.8 Component.java ........................................................................................................ 60
A.2.9 CompPrim.java ......................................................................................................... 62
A.2.10 DuplicationException.java ..................................................................................... 63
A.2.11 Environment.java.................................................................................................... 63
A.2.12 EvalFailedException.java....................................................................................... 68
A.2.13 Expression.java ....................................................................................................... 68
A.2.14 ForceFailedException.java..................................................................................... 69

3
A.2.15 HierarchicalVariable.java...................................................................................... 69
A.2.16 IfStatement.java...................................................................................................... 71
A.2.17 NameGenerator.java............................................................................................... 72
A.2.18 Number.java............................................................................................................ 73
A.2.19 PrimitiveBinOp.java............................................................................................... 74
A.2.20 Primitive.java .......................................................................................................... 80
A.2.21 PrimitiveSet.java..................................................................................................... 80
A.2.22 PrimitiveUnOp.java................................................................................................ 82
A.2.23 PrimitiveVecBinOp.java......................................................................................... 84
A.2.24 PrimitiveVectorInput.java ..................................................................................... 92
A.2.25 PrimitiveVectorOutput.java .................................................................................. 94
A.2.26 PrimitveVecUnOp.java........................................................................................... 96
A.2.27 STEntry.java ......................................................................................................... 100
A.2.28 Str.java................................................................................................................... 100
A.2.29 Sys.java .................................................................................................................. 101
A.2.30 Thunk.java............................................................................................................. 103
A.2.31 UndefinedException.java ..................................................................................... 104
A.2.32 Variable.java ......................................................................................................... 104
A.2.33 Wire.java ............................................................................................................... 106
A.2.34 Body.java ............................................................................................................... 106
A.3 Driver, build files ............................................................................................................ 107
A.3.1 Main.java ................................................................................................................. 107
A.3.2 build.xml .................................................................................................................. 110
A.4 Testing suite..................................................................................................................... 111
A.4.1 Test Files .................................................................................................................. 111
A.4.2 Regression Testing Script....................................................................................... 127

4
Chapter 1
Introduction
1.1 Introduction
The Logic Circuit Simulation Language (LCSL) has been built to design logical
circuits in a new, intuitive way. The classical approach to building circuits has
always been using declarative hardware design languages, mainly because the
building blocks used in these declarative programs are how the circuits are
actually mapped out in the hardware. But on a conceptual level, human beings
think of circuits in a different way; that of a web of functions that have inputs and
outputs.
This is where LCSL comes in. With its functional programming philosophy,
LCSL allows users to design circuits at a highly conceptual level. LCSL then
transforms the code into the code of the popular declarative HDL Verilog so that
the circuit can be simulated and synthesized. By producing an extra layer of
abstraction, LCSL frees the user from worrying about the nitty-gritty of long,
convoluted code of Verilog that is necessary for the actual production of the
circuit.
1.2 Background
The logic circuit is an integral part of the transistors that are in virtually all
aspects of computational electronics—from the airbags in a car to the alarm in a
watch. The fundamental aspect of a logic circuit is that it operates on a digital
signal that always carries one of only two values. The representation of these
values varies through different technologies, whether it is a high or low voltage at
a very low hardware level or Boolean representations of true and false in a high-
level programming language.
Logic circuits act as a physical representation of a mathematical or logical
function between a set of inputs and a set of outputs. Inputs are usual carried in by
bit wires that carry a high or low voltage (which, again, can be translated to
true/false values on a very high level). The physical medium that is a circuit
transforms these signals in such a way as to produce a specific set of outputs that
are sent out by bit wires as well. Combining several of these “function” circuits
results in a useful tool for data, whether it be simple mathematical functions such

Citations
More filters
Journal ArticleDOI
01 Apr 2003
TL;DR: This paper presents an empirical study of this handoff process at the link layer, with a detailed breakup of the latency into various components, showing that a MAC layer function - probe is the primary contributor to the overall handoff latency.
Abstract: IEEE 802.11 based wireless networks have seen rapid growth and deployment in the recent years. Critical to the 802.11 MAC operation, is the handoff function which occurs when a mobile node moves its association from one access point to another. In this paper, we present an empirical study of this handoff process at the link layer, with a detailed breakup of the latency into various components. In particular, we show that a MAC layer function - probe is the primary contributor to the overall handoff latency. In our study, we observe that the latency is significant enough to affect the quality of service for many applications (or network connections). Further we find variations in the latency from one hand-off to another as well as with APs and STAs used from different vendors. Finally, we discuss optimizations on the probe phase which can potentially reduce the probe latency by as much as 98% (and a minimum of 12% in our experiments). Based on the study, we draw some guidelines for future handoff schemes.

954 citations


Cites background from "Characterizing user behavior and ne..."

  • ...…mode, two or more wireless stations (STAs) recognize each other and establish a peer­to-peer communication without any existing infrastructure, whereas in infrastructure mode there is a .xed entity called an access point (AP) that bridges all data between the mo­bile stations associated to it....

    [...]

Proceedings ArticleDOI
26 Sep 2004
TL;DR: This paper analyzes an extensive network trace from a mature 802.11 WLAN, including more than 550 access points and 7000 users over seventeen weeks, and defines a new metric for mobility, the "session diameter," to show that embedded devices have different mobility characteristics than laptops, and travel further and roam to more access points.
Abstract: Wireless Local Area Networks (WLANs) are now commonplace on many academic and corporate campuses. As "Wi-Fi" technology becomes ubiquitous, it is increasingly important to understand trends in the usage of these networks.This paper analyzes an extensive network trace from a mature 802.11 WLAN, including more than 550 access points and 7000 users over seventeen weeks. We employ several measurement techniques, including syslogs, telephone records, SNMP polling and tcpdump packet sniffing. This is the largest WLAN study to date, and the first to look at a large, mature WLAN and consider geographic mobility. We compare this trace to a trace taken after the network's initial deployment two years ago.We found that the applications used on the WLAN changed dramatically. Initial WLAN usage was dominated by Web traffic; our new trace shows significant increases in peer-to-peer, streaming multimedia, and voice over IP (VoIP) traffic. On-campus traffic now exceeds off-campus traffic, a reversal of the situation at the WLAN's initial deployment. Our study indicates that VoIP has been used little on the wireless network thus far, and most VoIP calls are made on the wired network. Most calls last less than a minute.We saw greater heterogeneity in the types of clients used, with more embedded wireless devices such as PDAs and mobile VoIP clients. We define a new metric for mobility, the "session diameter." We use this metric to show that embedded devices have different mobility characteristics than laptops, and travel further and roam to more access points. Overall, users were surprisingly non-mobile, with half remaining close to home about 98% of the time.

566 citations

Proceedings ArticleDOI
05 May 2003
TL;DR: This paper studies user mobility patterns and introduces new metrics to model user mobility and finds that average user transfer-rates follow a power law, and models user mobility with persistence and prevalence find that the probability distributions of both measures follow power laws.
Abstract: Wireless local-area networks are becoming increasingly popular. They are commonplace on university campuses and inside corporations, and they have started to appear in public areas [17]. It is thus becoming increasingly important to understand user mobility patterns and network usage characteristics on wireless networks. Such an understanding would guide the design of applications geared toward mobile environments (e.g., pervasive computing applications), would help improve simulation tools by providing a more representative workload and better user mobility models, and could result in a more effective deployment of wireless network components.Several studies have recently been performed on wire-less university campus networks and public networks. In this paper, we complement previous research by presenting results from a four week trace collected in a large corporate environment. We study user mobility patterns and introduce new metrics to model user mobility. We also analyze user and load distribution across access points. We compare our results with those from previous studies to extract and explain several network usage and mobility characteristics.We find that average user transfer-rates follow a power law. Load is unevenly distributed across access points and is influenced more by which users are present than by the number of users. We model user mobility with persistence and prevalence. Persistence reflects session durations whereas prevalence reflects the frequency with which users visit various locations. We find that the probability distributions of both measures follow power laws.

541 citations


Cites background from "Characterizing user behavior and ne..."

  • ...Figure 6 shows the fraction of idle time for cumulative fractions of access points in each of the three buildings....

    [...]

  • ...They are commonplace on university campuses and inside corporations, and they have started to appear in public areas [17]....

    [...]

  • ...However, access points are also idle some fraction of the time during normal working hours....

    [...]

Proceedings ArticleDOI
26 Sep 2004
TL;DR: This paper presents an efficient solution to determine the user-AP associations for max-min fair bandwidth allocation, and shows the strong correlation between fairness and load balancing, which enables them to use load balancing techniques for obtaining optimal maximum-minFair bandwidth allocation.
Abstract: Recent studies on operational wireless LANs (WLANs) have shown that user load is often unevenly distributed among wireless access points (APs). This unbalanced load results in unfair bandwidth allocation among users. We observe that the unbalanced load and unfair bandwidth allocation can be greatly alleviated by intelligently associating users to APs, termed association control, rather than having users greedily associate APs of best received signal strength.In this study, we present an efficient algorithmic solution to determine the user-AP associations that ensure max-min fair bandwidth allocation. We provide a rigorous formulation of the association control problem that considers bandwidth constraints of both the wireless and backhaul links. Our formulation indicates the strong correlation between fairness and load balancing, which enables us to use load balancing techniques for obtaining near optimal max-min fair bandwidth allocation. Since this problem is NP-hard, we present algorithms that achieve a constant-factor approximate max-min fair bandwidth allocation. First, we calculate a fractional load balancing solution, where users can be associated with multiple APs simultaneously. This solution guarantees the fairest bandwidth allocation in terms of max-min fairness. Then, by utilizing a rounding method we obtain an efficient integral association. In particular, we provide a 2-approximation algorithm for unweighted greedy users and a 3-approximation algorithm for weighted and bounded-demand users. In addition to bandwidth fairness, we also consider time fairness and we show it can be solved optimally. We further extend our schemes for the on-line case where users may join and leave. Our simulations demonstrate that the proposed algorithms achieve close to optimal load balancing and max-min fairness and they outperform commonly used heuristic approaches.

537 citations

References
More filters
Proceedings Article
01 Jan 1990
TL;DR: The authors' goal is always to offer you an assortment of cost-free ebooks too as aid resolve your troubles.

2,593 citations


Additional excerpts

  • ...The PDF of the session time (not shown) closely follows a General Pareto Distribution [9] with a shape parameter of 0....

    [...]

  • ...The PDF of the session time (not shown) closely follows a General Pareto Distri­bution [9] with a shape parameter of 0.78 and a scale parameter of 30.76....

    [...]

  • ...The session time distribution can be approximated to a Gen­eral Pareto Distribution with a shape parameter of 0.78 and a scale parameter of 30.76....

    [...]

Book
01 Jan 1991
TL;DR: The art of computer systems performance analysis by is one of the most effective vendor publications worldwide as discussed by the authors. But have you had it? Not at all? Ridiculous of you.
Abstract: the art of computer systems performance analysis by is one of the most effective vendor publications worldwide? Have you had it? Not at all? Ridiculous of you. Currently, you can get this impressive book simply here. Locate them is layout of ppt, kindle, pdf, word, txt, rar, as well as zip. Just how? Merely download and even read online in this site. Now, never ever late to read this the art of computer systems performance analysis. Whatever our proffesion, the art of computer systems performance analysis can be good source for reading. Find the existing reports of word, txt, kindle, ppt, zip, pdf, and also rar in this website. You can absolutely read online or download this book by right here. Currently, never miss it. Our goal is always to offer you an assortment of cost-free ebooks too as aid resolve your troubles. We have got a considerable collection of totally free of expense Book for people from every single stroll of life. We have got tried our finest to gather a sizable library of preferred cost-free as well as paid files. GO TO THE TECHNICAL WRITING FOR AN EXPANDED TYPE OF THIS THE ART OF COMPUTER SYSTEMS PERFORMANCE ANALYSIS, ALONG WITH A CORRECTLY FORMATTED VERSION OF THE INSTANCE MANUAL PAGE ABOVE.

2,424 citations

Journal ArticleDOI
TL;DR: The capacity C of the model channel exceeds the capacity C(sym. bin.) of a memoryless symmetric binary channel with the same error probability; however, the difference is slight for some values of h, p, P; then, time-division encoding schemes may be fairly efficient.
Abstract: A model of a burst-noise binary channel uses a Markov chain with two states G and B. In state G, transmission is error-free. In state B, the channel has only probability h of transmitting a digit correctly. For suitably small values of the probabilities, p, P of the B $rA G and G $rA B transitions, the model simulates burst-noise channels. Probability formulas relate the parameters p, P, h to easily measured statistics and provide run distributions for comparison with experimental measurements. The capacity C of the model channel exceeds the capacity C(sym. bin.) of a memoryless symmetric binary channel with the same error probability. However, the difference is slight for some values of h, p, P; then, time-division encoding schemes may be fairly efficient.

2,406 citations


"Characterizing user behavior and ne..." refers methods in this paper

  • ...To model error rates as a function of time, we characterize the channel behavior in two states, good and bad, as has been done previously [6, 20, 22]....

    [...]

Journal ArticleDOI
TL;DR: By partitioning the range of the received signal-to-noise ratio into a finite number of intervals, FSMC models can be constructed for Rayleigh fading channels and the validity and accuracy of the model are confirmed by the state equilibrium equations and computer simulation.
Abstract: The authors first study the behavior of a finite-state channel where a binary symmetric channel is associated with each state and Markov transitions between states are assumed. Such a channel is referred to as a finite-state Markov channel (FSMC). By partitioning the range of the received signal-to-noise ratio into a finite number of intervals, FSMC models can be constructed for Rayleigh fading channels. A theoretical approach is conducted to show the usefulness of FSMCs compared to that of two-state Gilbert-Elliott channels. The crossover probabilities of the binary symmetric channels associated with its states are calculated. The authors use the second-order statistics of the received SNR to approximate the Markov transition probabilities. The validity and accuracy of the model are confirmed by the state equilibrium equations and computer simulation. >

1,742 citations

Journal ArticleDOI
TL;DR: The results show that a reliable link-layer protocol that is TCP-aware provides very good performance and it is possible to achieve good performance without splitting the end-to-end connection at the base station.
Abstract: Reliable transport protocols such as TCP are tuned to perform well in traditional networks where packet losses occur mostly because of congestion. However, networks with wireless and other lossy links also suffer from significant losses due to bit errors and handoffs. TCP responds to all losses by invoking congestion control and avoidance algorithms, resulting in degraded end-to end performance in wireless and lossy systems. We compare several schemes designed to improve the performance of TCP in such networks. We classify these schemes into three broad categories: end-to-end protocols, where loss recovery is performed by the sender; link-layer protocols that provide local reliability; and split-connection protocols that break the end-to-end connection into two parts at the base station. We present the results of several experiments performed in both LAN and WAN environments, using throughput and goodput as the metrics for comparison. Our results show that a reliable link-layer protocol that is TCP-aware provides very good performance. Furthermore, it is possible to achieve good performance without splitting the end-to-end connection at the base station. We also demonstrate that selective acknowledgments and explicit loss notifications result in significant performance improvements.

1,325 citations

Frequently Asked Questions (10)
Q1. What contributions have the authors mentioned in the paper "Logic circuit simulation language" ?

The Logic Circuit Simulation Language ( LCSL ) this paper allows users to design logical circuits at a highly conceptual level. 

The following are valid source expressions:• Variables • Constants (integer, Boolean, or Vector) • Connections • Instantiations • Conditionals • Component definitions • Operational expressions • Expression groupings of any combination of aboveAs mentioned above, sink expressions consume values. 

LCSL variablesare simply entries in symbol tables, and table entries can be roughly divided into two categories: vectors and scalars. 

The two hardware design languages that have ruled the circuit design landscape for the past twenty years have been Verilog and VHDL. 

The evaluation step passes through the LCSL Expression tree and does a minimal amount of work, the most important of which are setting up environments for systems and creating thunks for names. 

Logic circuits act as a physical representation of a mathematical or logical function between a set of inputs and a set of outputs. 

designed by Launchbird Design Systems, Inc., was the first to introduce the functional language programming interface to hardware design languages. 

The operators accepted by the lexer include: . ‘ ! ~ ** * % + - << >> @ < > <= >= ++ & ^ | <-Strings use Java-like syntax with an ASCII character string surrounded by double quotes (ex. “Hello World”). 

In order to streamline the process the authors added functionality to the compiler that would automatically generate a test bench for the outputted Verilog. 

LCSL stays clear of this simple paradigm for two main reasons: the fan-out of components, and the extreme-lazy evaluation technique the authors found to be well-suited for their purposes.