Star Network

1
CS4554 - Network Perfomance AnalysisSeptember
12, 2000
2
SOF Wireless Network Perfomance Analysis
by

• Paulo Silva LCdr, Portuguese Navy
• Mehmet Sezgin Lt, Turkish Army
• George Stavritis Lt, Hellenic Navy

CS4554 - Network Perfomance AnalysisSeptember
12, 2000
3
Presentation agenda

• Problem description
• Goal statement
• Assumptions
• Building an analytical model of a network
• Using the simulation tool Opnet modeler
• Conclusions
• Lessons learned

4
Problem Description
Two Special Forces Operations Teams (SFOT) will
conduct a direct action (DA) mission against the
enemy air control radar and the air defense unit
(Target B). The two targets are 1800 meters apart
from each other. The assault will be conducted
concurrently, in coordination with Headquarter
(HQ), where the battalion commander is also
located.
5
Problem Statement

• With the given scenario in mind, come up with a
  wireless network model that enables Special
  Forces Operation Teams to communicate throughout
  their mission.

6
Goal Statement
Perform a feasibility analysis of a wireless
network using star topology, suitable for Special
Forces Operations.
7
Assumptions

• Star network topology is chosen to perform the
  analysis.
• Nodes are the network access points.
• Nodes are equally distant from the central hub.
• Special Forces Operation Teams (SFOT) and the
  Headquarter (HQ) use individual nodes to access
  the system.

8
Assumptions
(cont.)

• All links among SFOTs and HQ are continuously
  established.
• The whole network is considered to be free from
  errors.
• We abstract the method used by teams to transit
  their data internally.
• No considerations are made about technical issues
  on using mobile data link equipment.

9
Assumptions
(cont.)

• The mobility problems are solved at the extent
  that they do not affect the QoS of the network.
• No considerations are made about the applications
  that generate the data messages that flow through
  the network.
• The traffic on the network is symmetric.

10
Presentation agenda

• Problem description
• Goal statement
• Assumptions
• Building an analytical model of a network
• Using the simulation tool Opnet modeler
• Conclusions
• Lessons learned

• Problem description
• Goal statement
• Assumptions
• Building an analytical model of a network
• Using the simulation tool Opnet modeler
• Conclusions
• Lessons learned

11
Analytical Model
Network topology

• Considerations choosing the topology
• range of operation
• terrain obstacles
• reliability
• ease of implementation
• node independence
• modeling constraints.

12
Star Topology Network
Case study

• Star topology selected as the case study.
• Provides for wide area coverage.
• Network nodes are individual components which do
  not depend on each other.
• Ease of implementation.

13
Star Network
System definition

• Three main components
• access nodes
• central switching hub
• data links

14
Star Network
Identification of services

• The SFO scenario analysis identified several
  potential types of service to be provided by the
  network
• simple data messages
• command and control and coordination orders
• voice communications
• multimedia support (digital mapping, video, etc)
• remote data access.

15
Star Network
Identification of services

• For the purpose of the present study, we will
  concentrate only on the transfer of single data
  messages.

16
Star Network
Metrics

• Due to time and resource limitations, errors and
  failures are not addressed by this study.
• Traffic delay and throughput of the system are to
  be evaluated against a set of different factors
  that affect the overall system performance.

17
Star Network
Main parameters affecting performance

• Distance between nodes and the central hub.
• Number of nodes.
• System load (message size and arrival rates).
• Level of traffic symmetry.
• Central hub processing power.
• Propagation medium.

18
Star Network
Selected factors

• For the purpose of the current performance
  analysis, different network configurations were
  addressed, based on the following factors
• data link capacity
• distance
• number of nodes
• message arrival rates.
• For each of these factors, different levels were
  then selected.

19
Analytical modeling
The evaluation technique

• The SUT evaluation was performed using an
  analytical model of the star network

20
Analytical modeling
Model assumptions

• Messages arrive to the system at one of the N
  nodes, following the model of Poisson arrivals
• Message sizes are exponentially distributed with
  the mean size of 1000 bits and header size of 0
  bits.
• Wireless propagation speed is constant and equal
  to the speed of light.
• Transmission request time is negligible.
• Switching time is negligible.

21
Analytical modeling
Model assumptions (cont.)

• System free from errors.
• Traffic is symmetric.
• Every message has N-1 possible destinations with
  equal likelihood.

22
Analytical modeling
Delay analysis

• Overall delay components
• Queuing delay
• Transmission delay
• Signal propagation delay.

23
Analytical modeling
Delay analysis (cont.)

• Queuing delay - E(W)

24
Analytical modeling
Delay analysis (cont.)

• E(W) is a function of
• The utilization
• Number of nodes
• Mean service time E(S)
• Since traffic is symmetric and arrival rates are
  equal to all nodes (
  ), utilization equates to

25
Analytical modeling
Delay analysis (cont.)

• Taking into account
• Stability condition
• Large N
• It can be shown that

26
Analytical modeling
Delay analysis (cont.)

• Transmission time - E(S)
• Is a function of the length of the message and
  link capacity.
• Given by

27
Analytical modeling
Delay analysis (cont.)

• Propagation delay - E(Tp)
• Is a function of the medium and distance that
  separates each node from the hub.
• Each node is considered to be at the same
  distance from the central hub.
• Negligible switching time.

28
Analytical modeling
Calculating results

• Case 1
• Link capacity of 100 Mbps using a EHF frequency
  band.
• Central hub located in a satellite on a
  geostationary orbit
• Satellite altitude is 71360 Km which is the
  distance considered for the calculations
• Typically, link capacity may be as high as 400
  Mbps.
• N10, E(Lm) 1000 bits

29
Analytical modeling
Data results - case 1
30
Analytical modeling
Data results - case 1
31
Analytical modeling
Calculating results

• Case 2
• Link capacity of 40 Mbps using SHF frequency band
• Central hub located in the operations area in the
  vicinity of each node at a distance of 10 Km.
• N10, E(Lm) 1000 bits

32
Analytical modeling
Data results - case 2
33
Analytical modeling
Data results - case 2
34
Analytical modeling
Calculating results

• Case 3
• Link capacity of 1500 bps using an HF frequency
  band.
• Central hub located in the operations area within
  a radius of 100 Km from all nodes.
• HF allows for greater range of operation using a
  surface propagation frequency carrier.
• N10, E(Lm) 1000 bits

35
Analytical modeling
Data results - case 3
36
Analytical modeling
Data results - case 3
37
Analytical modeling
Results

• Case 4 - Sensitivity to the number N of nodes
• Based on the parameters of case 2, varying the
  number of nodes in the system
• N 6, 8, 10, 12, 14 and 20.
• Link capacity of 40 Mbps same message size of
  1000bps.
• Central hub located at the distance of 10 Km

38
Analytical modeling
Data results - case 4
39
Analytical modeling
Data results - case 4
40
Analytical modeling
Data results - case 4
41
Analytical modeling
Data results - case 2 (revisited)
42
Analytical modeling
Analysis of the results

• The total handling capacity of the network
  increases with the number of nodes
• The system response is very sensitive to the
  system load when utilization approaches 0.5
  regardless of the selected configuration.
• The system becomes unstable for an utilization
  gt 0.5. Response time increases dramatically.

43
Analytical modeling
Analysis of the results

• Using a HF link (case 3) is not adequate because
  of the slow response time (1.3 to 3.3 sec).
• Both case 1 and case 2 solutions are considered
  to be acceptable. Both allow for an appreciable
  throughput and good response times, for wireless
  data links.
• Despite the higher response time for the
  satellite link, (case 1) it is still acceptable
  for the type of service considered.

44
Analytical modeling
Validating the model

• The analytical model presented was based on a
  study on Traffic Analysis of a network using
  star topology by, Mehmet Ali and Hayes, 1988
  IEEE.
• The results obtained entirely agree with that
  paper.
• Initial intention was to use Opnet to model this
  same problem for validation, failed due to
• no built-in library models for star networks
• need to create a model from scratch
• limited documentation and tutorial support
• time constraint / tool complexity (guess and
  try?)
• unavailability of the tool due to poor
  configuration.

45
Presentation agenda

• Problem description
• Goal statement
• Assumptions
• Building an analytical model of a network
• Using the simulation tool Opnet modeler
• Conclusions
• Lessons learned

• Problem description
• Goal statement
• Assumptions
• Building an analytical model of a network
• Using the simulation tool Opnet Modeler
• Conclusions
• Lessons learned

46
The goal of the study is to find the necessary
number of buffers to support the workload with an
acceptable loss rate. For that we will

• Use the OPNET modeler to simulate an M/M/1/B
  queue
• and then
• Validate the results with an analytical model
  (M/M/1/B)

47
List system services

• Our system is a server of M/M/1/B queue. It must
  successfully retransmit packets that arrive from
  source to the destination and confine loss rate
  below 0.001( 0,1) and have maximum delay 30 sec.

48

• Our M/M/1/B has a diagram as shown in the graph
  below.

49
Select performance metrics

• The metrics we used for this are
• the average queue delay time,
• the number of overflow packets as loss rate
• The startup period , until the system is stable
  is considered as well as secondary.

50
List system and workload parameters

• The service mean capacity is 9600bps
• The mean packet arrival time is set to 1 pack/sec
  iaw the exponential distribution.
• The service requirements are for 9000 bps.
• The number of buffers is to be determined.

51

• The factors we used were
• The number of buffers ( infinite, 40 and 20 )
• The simulation time (6 hours, 24 h and 72 h)
• The random generators seed was 431, 144 and
  831

52
Design the experiment

• The experiment was conducted as follows
• We created 3 random sequences of arrival based on
  3 seeds (831,431,144)and graphical verified that
  they were different.
• Then we assumed infinite number of buffers and
  run it for 6, 24 and 72 h.
• We change the buffers to 40, and run it for 6,
  24,72h
• After that we lowered the buffer size to 20 and
  run it for 72h
• Finally we used an excel worksheet and validate
  the model

53
buffer infinite / 6 hoursqueue delay (as is //
average)

• fig run1
• The average queue delay is not stable (10-30 sec)
• Seed is 431
• So we decided to change seed and .

54
buffer infinite/6 hoursqueue delay (as is //
average)

• fig run3
• The average queue delay seems stable and now
  (10-13 sec)
• Seed 144

55
buffer infinite/24 hoursqueue delay (as is //
average)

• fig run2
• The average queue delay is more stable around 16
  sec
• Seed 431

56
buffer infinite/24 hoursqueue delay (as is //
average)

• fig run4 The average queue delay is more stable
  around 12 sec!
• Seed 144

57
buffer infinite/72 hoursqueue delay (as is //
average)

• fig run5
• The average queue delay is more stable around 15
  sec!
• Seed 144
• OUR SYSTEM SEEMS NOW STABILIZED after 3 DAYS.

58
buffer40 / 6 hoursqueue delay (as is // average)

• fig run6
• The average queue delay is around 11 sec
• Seed 144
• We experienced some packet drops.

Overflows (as is // average)
59
buffer40 / 6 hoursqueue delay (as is // average)

• fig run7
• The average queue delay is around 11 sec
• Seed 144
• We merged the previous diagrams (packet drops).

Overflows (as is )
60
Average queue delay based on number of buffers

• Less is better but
• Bufferinfinite
• Buffer40
• Buffer 20

61
.. Average loss rate based on number of buffers

• Consider loss Rate
• Less is better
• Bufferinfinite
• Buffer40
• Buffer 20

Create new graph
62
The analytical model

• (traffic intensity) ? ?
  / µ
• 
  ? (B1)??
• (mean of jobs) E(n) ----- -
  -----------
• 
  (1-?) 1-?(?1)
• (mean response time) E(
  r)E(n)/?-P(b)

63
(No Transcript)
64
The analytical model (queue delay)

• 
  buffer / queue delay
• ? (B1)?? (b100)
  14.78 sec
• E(n) ----- - ----------- (b40)
  11.89 sec
• (1-?) 1-?(?1) (b20)
  7.874 sec
• E( r)E(n)/?-P(b)
• ? ? / µ

65
Compare queue delay

• (b100) 14.78 sec
• (b40) 11.89 sec
• (b20) 7.874 sec

66
The analytical model (loss rate)

• ?? ? (1-p(b) ) Pack loss
  rate ?-??

67
The analytical model (loss rate and queue delay)
68
As a result, we found that , the minimum number
of buffers that assures packets loss rate below
1/1000 is equal or bigger than 65. The mean
queue delay is below the limit of maximum 30 sec
and is equal to 15 sec.
Simulation results
69
Presentation agenda

• Problem description
• Goal statement
• Assumptions
• Building an analytical model of a network
• Using the simulation tool Opnet modeler
• Conclusions
• Lessons learned

• Problem description
• Goal statement
• Assumptions
• Building an analytical model of a network
• Using the simulation tool Opnet Modeler
• Conclusions
• Lessons learned

70
Conclusions

• The initial problem was strongly bound so that
  analytical modeling of the proposed network could
  be performed with available tools.
• Analytical modeling produced acceptable solutions
  (sat link and 40 Mbps SHF link network) for the
  given problem and considering stated assumptions.

71
Conclusions

• Opnet Modeler is a very powerful simulation tool.
  It also requires extensive training to be able to
  produce correct and useful models.

72
Presentation agenda

• Problem description
• Goal statement
• Assumptions
• Building an analytical model of a network
• Using the simulation tool Opnet modeler
• Conclusions
• Lessons learned

• Problem description
• Goal statement
• Assumptions
• Building an analytical model of a network
• Using the simulation tool Opnet Modeler
• Conclusions
• Lessons learned

73
Lessons Learned

• Find out exactly what tools you have before you
  attempt to solve a problem.
• Learn the simulation tool before you start the
  project, or hire an expert on that tool.
• Be ready for surprises. Bugs in the simulation
  tool are likely to make you waste your precious
  study time.
• It is not that hard to do the common mistake of
  Well define our goals as we proceed.

74
Lessons Learned

• Once you know exactly what tools you have, make
  assumptions and bound the problem to make sure
  you can solve the re-stated problem.
• Clearly write the problem statement.

75
References
1. Jain, Raj,The Art of Computer Systems
Performance Analysis, John Wiley
Sons,1991. 2. Sadiku O N Mathew and Ilyas
Mohammad, Simulation of Local Area Networks, CRC
Press, 1995. 3. Ogut Cetin , An Ad Hoc Wireless
Routing Protocol Design for Special Forces Teams
MSc CS Thesis, Naval Postgraduate School ,
September 2000. 4. IEEE Standard 802.11a, Local
and Metropolitan Area Networks,Wireless LAN MAC
and PHY layer, 1999. 5. IEEE Standard 802.11b
supplement, Local and Metropolitan Area Networks,
Wireless LAN MAC and PHY layer. 6. LaMaire O
Richard and Bhagwat Pravin et.al, Wireless LANs
and Mobile Networking Standards and Future
Directions, IEEE Communications Magazine, August
1996. 7. Zyren Jim and Petrick Al , IEEE 802.11
Tutorial, IEEE Publications ,1999. 8. Quinn Liam
and Hanzlik Frank, Wireless Technologies, Dell
Communication Co.White Paper Series August
2000. 9. Tabbane Sami, Handbook of Mobile Radio
Networks, Artech House, February 2000. 10.
MustafaK.Mehmet-Ali et.all, Traffic Analysis of
a Local Area Network with a Star Topology, IEEE
Communications,1988 11. Smith Munro
Byron,Farhangian Keyvan, The Performance
Evaluation Of Wireless LAN Systems, IEEE
Communications,1995
76
The end
77
?
78
(No Transcript)
79
Opnet saga