Lab 4. Performance Analysis of Optical Access Network

1. Lab 4. Performance Analysis of Optical Access Network Chuan-Ching Sue DCNLAB, CSIE NCKU suecc@mail.ncku.edu.tw

2. Outline • Performance on EPONs • Bandwidth Utilization • Packet Delay • Quality of Service • Collect the simulation result • Analyze the simulation result • Conclusion

3. Performance on EPONs

4. Bandwidth Utilization • An ONU receives load φ traffic • Also called offered load of each ONU • φ can be normalized to the user link capacity RU. • E.g. 50 Mbps is the normalized load 0.5 • The offered network load Φ is the sum of all ONU’s offered loads and scaled based on RU and RN.

5. Bandwidth Utilization (Cont’d) • Because the network capacity could be lower than the sum of bandwidth from all ONUs (RN < NRU) in PON topology, the offered network load could over 1: • The carried load is determined by packets that were transmitted by the ONUs. • The carried load can never over 1. • The carried load multiplied by the link capacity is also called throughput or bandwidth utilization.

6. Bandwidth Utilization (Cont’d) • The bandwidth utilization could not reach 1 because there are some necessary overhead in EPON system. • The upper bound of bandwidth utilization can be compute by N is the number of ONU, Rguard is the bandwidth reserved for guard time, RMPCP is the bandwidth for transmitting MPCP message

7. Packet Delay • Since the network traffic is bursty, some time slots could not carry all packets in the queue completely. Thus, the remaining packets have to wait for later time slots in the queue. • This delay time period is called the burst delay. Burst delay may span many cycles.

8. Packet Delay (Cont’d) • The packet delay is defined as the time between a packet arrived the ONU and the packet be sent to the OLT.

9. Quality of Service • To provide quality of service (QoS), there are two existing service architectures [10] • Integrated Service (IntServ) • For providing per-flow service guarantees • Resource reservation • Differentiated Service (DiffServ) • For providing aggregated-flow service guarantees • Resource provisioning

10. Quality of Service (Cont’d) • One type of the DiffServ methods is to categorize the traffic into three different classes.[3] • EF :delay sensitive andjitter delay sensitive such as network control signal, voice and other delay sensitive applications. • Network control signal maintain and support the network infrastructure[4] • Voice data not exceeds 150ms[5] • Delay sensitive applications like IPTV, channel change time can’t over 0.43s [6] • AF: no delay sensitive traffic but requires bandwidth guaranteed • BE: neither delay sensitive nor requires bandwidth guaranteed

11. Collect the simulation result

12. Simulation Tool • The simulation in lab 4 is based on the lab 3. • Since we only implement the DBA agent without considering simulation result collection in lab 3. We have to modify the code of lab 3 so that it can record the desired information. • First, we will introduce the simulation tools for collecting data in OMNeT++. • Second, we will explain which part in Lab 3 has to be modified with the OMNeT++ tools.

13. Collect the simulation result • In OMNeT++[7], there are many ways to record simulation results. • For time series data • cOutVector class • For scalars • recordScalar function • For statistics and Distribution Estimation • cStdDev class

14. cOutVector • The cOutVector class is responsible for recording time series data to a trace file. • The vector name can be passed in the constructor • E.g. • All cOutVector objects write data into a single *.vec per simulation run.

15. Example: Output Vectors • The following example is a Sink module which records the lifetime of every message that arrives to it. cOutVector Declaration Setting Name Record Data

16. Output Scalars • The output scalars are supposed to record a single value per simulation run. • The output scalars is usually used to record summary data at the end of the simulation run. • E.g.

17. Statistics and Distribution Estimation • There are several statistic and result collection classes: • cStdDev •  it keeps the count, mean, standard deviation, minimum and maximum value etc of the observations. • Example:

18. Warm-up Period • The warmup-period option specifies the length of the initial warm-up period. • The results belonging to the first x seconds of the simulation will not be recorded into output vectors, and will not be counted into the calculation of output scalars. • The default is 0s (no warmup period). • Example: (in omnetpp.ini)

19. Warm-up Period • To speed up and save memory space when a user-defined module need to computes (e.g. via dropcount++) and records scalar results manually (via recordScalar()), we will the following scheme rather than using another cStdDev object. • Example:

20. Record Bandwidth Utilization • Recall that the bandwidth utilization is the carried load multiplied by the link capacity. • To record the bandwidth utilization U, all of the transmitted packet length should be record in P. The bandwidth utilization isW is the transmission rate and T is the simulation time.

21. Record Packet Delay • The packet delay is the time period between the packet get in and out of an ONU. • Thus, the packet delay can be computed by

22. Collecting Place and Modify • Modifying • Add priority field to DataPacket class • Add CBR source and modify user network description • Add queues for each priority in ONU • Collecting data • The OLT is responsible for recording bandwidth utilization and cycle time • The ONU is responsible for recording packet delay for each priority queue.

23. Add DataPacket class • To identify each packet’s priority, we add an new msg to the simulation. • We use an int “priority” to recognize its priority. • 0 => EF • 1 => AF • 2 => BE

24. Add CBR source • Add a simple module “CbrSource” in device.ned • Create the corresponding C++ header and source code of the CbrSource

25. The Header of CbrSource • Since CBR source is a constant bit rate source, it requires the interval length and the packet size.

26. The Implementation of CbrSource • We use a frequency of 8000 pkt/sec and 70 bytes / pkt to simulate the CBR voice call. • The CBR source send a fixed size packet in a constant frequency.

27. Add Priority Field to Pareto Source • Since the instance of source module may have the AF or BE priority, it’s required to add a field to source module to identify its priority.

28. Modify the User network Description • Reconfigure the intra-user connection. • EF: a CBR source • AF: pareto sources • BE: pareto sources

29. Collecting Data at OLT • To record the utilization and cycle time at OLT, we add 3 data member to the OLT module • Cycle_start_time • The last cycle start time • recordCycleLength • recordTotalSize • Record the total received packet size for each priority

30. Record Cycle Length • Since the OLT knows the transmission time of each ONU, the OLT can record the cycle time by record the time period between the start time of 1st ONU’s transmissions.

31. Record Cycle Length (Cont’d)

32. Record Cycle Length (Cont’d) • When the simulation is finish, the simulator will call the finish() function. • Therefore, we can record the desired data (i.e. cycle time) in the finish() function.

33. Cache the Received Packet Size • To record the bandwidth utilization, we first record each received packet size to the recordTotalSize class when the OLT receives a packet.

34. Compute Bandwidth Utilization • According to the simulation time, warm-up time, EPON data rate and the collected packet size, we compute the bandwidth utilization for each priority and the total bandwidth utilization in the finish() function.

35. Record Packet Delay • To record the packet delay for each priority, its required to use 3 cStdDev objects the collect the delay information, respectively.

36. Record Packet Delay (Cont’d) • When the ONU receives a packet from user, the ONU set the timestamp of the packet to the received time.

37. Record Packet Delay (Cont’d) • While the ONU is going to sent a packet to the OLT, the ONU take out the receive time of the packet by using getTimestamp() function. • The packet delay is computed by the sent-out time minus received time

38. Record Packet Delay (Cont’d) • The ONU will write the average delay to the trace file when the simulation is going to finish. • The maximum packet delay or minimum packet delay can be show by using getMax() and getMin().

39. Analyze the simulation result

40. Running the Simulation • Running the Simulation and observing the packet behavior under different DBA agents.

41. Simulation Configuration

42. Average Packet Delay

43. Average Cycle Time

44. Bandwidth Utilization

45. Simulation Configuration

46. Limited/Priority: Average Packet Delay • As the load decreases from moderate (~0.25) to very light (~0.05), the average delay for the lower-priority classes AF and BE increases significantly. • We refer to this phenomenon as the light-load penalty.

47. Limited/Tandem: Average Packet Delay • The light-load penalty has been eliminated. • The drawback of this scheme, however, is the increased delay for the highest-priority class (EF). The average delay for EF has increased 3 times than Limited/Priority.

48. Conclusion and Reference

49. Conclusion • In lab4, we implement the different DBA agents and collect their simulation results. • The IPACT-Fixed performs worst case at light load • The IPACT-Gated has the lowest delay and highest utilization but the cycle time is too long. • The IPACT-Limited has good performance and a limited cycle time.

50. Reference • [1] C. C. Sue, et al., “Active Scheduling Algorithm for Intra-ONU Dynamic Bandwidth Allocation in Ethernet Passive Optical Networks,” First International Conference on Ubiquitous and Future Networks, pp. 240-245, 2009. • [2] X. Bai, A. Shami, and C. Assi, “On the fairness of dynamic bandwidth allocation schemes in Ethernet passive optical networks,” Computer Communications, vol. 29, no. 11, pp. 212 –21 5, Jul. 2006. • [3] G. Kramer, et al., "Supporting differentiated classes of service in Ethernet passive optical networks," J. Opt. Netw., vol. 1, pp. 280-298, 2002.