Kyeong Soo Kim, Seminar, Korea Advanced Institute of Science and Technology (KAIST), Daejeon, Korea, Aug. 22, 2011.

1. A Research Framework for
the Clean-Slate Design of
Next-Generation Optical Access
Dr Kyeong Soo (Joseph) Kim
College of Engineering
Swansea University
22 August 2011

3. Outline
I. Introduction
II. New Comparative Analysis Framework
III. Virtual Test Bed for Experiments
IV. Preliminary Results: Elasticity of Hybrid PON
V. Summary
2

4. Overview of Proposed Research Programme
Virtual Test Bed for Next-Generation Optical Access (NGOA)
Comparative Analysis Framework
Generating realistic traffic through a complete protocol stack
based on user behaviour models at application & session levels.
Quality of Experience
(QoE)
• A new comparative analysis framework for the user-
perceived performances (as measures of QoE) of candidate
NGOA systems.
• It is based on equivalent circuit rate (ECR) framework &
multivariate non-inferiority testing procedure and able to
take into account the statistical variability in experimental
data and a tolerance for the measure.
• The virtual test bed is implemented as simulation models for both systems under
test (SUT) &supporting environments (i.e., application server, intermediate
routers, user nodes) and run in a large-scale with the help of cloud computing (i.e.,
Amazon elastic compute cloud (Amazon EC2)*).
• It provides a common reference framework for experiments for researchers in
both Academia and Industry in order to properly benchmark candidate NGOA
systems and exchange their results.
Energy-Efficient and Elastic Components and Architectures
New Research Framework for Clean-Slate Design of NGOA
• Based on the proposed research framework,
we will investigate from scratch the
following major issues in components &
architectures:
• System capacity
• Elasticity
• Cost & energy efficiency
• We expect that the results from our study
will be quite different from conventional
ones and, therefore, have many implications
on traffic engineering as well as
architectural designs for the following
reasons:
• Realistic traffic models
• Measures for user-perceived
performances
User Behaviour-Based Traffic Modelling/Generation
* Supported by Amazon Web Services (AWS) in Education Research Grant.

5. I. Introduction
4

6. Changing Landscape for NGOA
in 10-Plus-Year Time Frame
• Architectural requirements
– Higher line rate (10+ Gbit/s)
and per-user capacity
– Lower power consumption
– Elasticity
– Access/metro integration
• Higher split ratios (1:128~1024)
• Longer reaches (60~100 km)
– Support of hybrid
optical/wireless
• Traffic characteristics
– Higher bandwidth
– Higher burstiness
– Peer-to-peer
• Business aspects
– Revenue model
– New services/applications
• User demands
• Usage behaviour
5

7. Characteristics of Future Traffic:
Higher bandwidth and burstiness!
Slow start
Congestion
avoidance
HTTP (TCP) Traffic
I B B P B B I B … frame
size MPEG-4 Part 2
(I/P/B=6721B/2234B/1186B)
H.264/AVC
(I/P/B=5658B/1634B/348B)
Video Traffic*
Cannot fill the pipe
for most of the time
* G. van der Auwera et al., “Traffic characteristics of H.264/AVC variable bit rate video,”
IEEE Comm. Mag., vol. 46, no. 11, pp. 164-174, Nov. 2009. 6

8. Lessons from Cloud Computing* - 1
– Elasticity
• Ability to add or remove
resources at a fine grain
and with a small lead time
– Transference of risks of
• Overprovisioning
(underutilization)
• Underprovisioning
(saturation)
Max. (=peak)
Min.
Avg.
Time
Demand
* M. Armbrust et al., “Above the clouds: A Berkeley view of cloud computing,”
Dept. of EECS, UC Berkeley, Tech. Rep. UCB/EECS-2009-28, Feb. 2009. 7

9. Lessons from Cloud Computing - 2
– The illusion of infinite computing resources available on
demand
• Through the construction of large-scale, commodity-computer
datacenters at low cost locations, and virtualization technique
– The elimination of an up-front commitment by cloud users
• Companies can start small and increase gradually
– The ability to pay for use of computing resources on a
short-term basis as needed
8

10. Implications on NGOA Architectures - 1
9
Economy of scale through integration*
Network resource as utility
Maximisation of resource sharing
* M. Armbrust et al., “Above the clouds: A Berkeley view of cloud computing,”
Dept. of EECS, UC Berkeley, Tech. Rep. UCB/EECS-2009-28, Feb. 2009.

11. Implications on NGOA Architectures - 2
Backbone/Core
MAN
Access
Access

Residential
Users
Business
Users
Current edge of the OBS/MPLS network
New edge of the OBS/MPLS network (toward ONUs)
New framing &
switching schemes
at UNIs
…
…
Flexible PON
Flexible PON with higher elasticity
 See the next slides for examples.
10

12. Remotely Powered &
Reconfigurable Remote Nodes*
11
JSDU PPC-9LW
Photovoltaic Power Converter
Fiberer 2x2 MEMS
Optical Latching Switch
* J. H. Lee et al., “A remotely reconfigurable remote node for next-generation access networks,”
IEEE Photon. Technol. Lett., vol. 20, pp. 915, Jun. 2008.

13. Scheduler
Downstream
Traffic
Queues
...
1:M
Passive Splitter
Upstream
Traffic
Queues
...
Burst-Mode
Receiver
MAC Downstream
Traffic Queue
Upstream
Traffic Queue
Hybrid TDM/WDM-PON OLT
Hybrid TDM/WDM-PON ONU
1:N
AWG
......
Circulator
Tunable
Transmitter
Tunable
Receiver
Tunable
Receiver
Circulator
......
Tunable
Transmitter
Modulator
(e.g., RSOA)
Hybrid
TDM/WDM-PON
with Tuneable
Transceivers
1:2
Passive Splitter
12

14. Key Observations - 1
• Toward more energy-efficient & elastic NGOA
– Performance has long been a major issue in
traditional network design, but energy efficiency
becomes as important an issue as performance in
design of NGOA.
– The elasticity of network is a key to achieving
higher energy efficiency as well as lower operation
& maintenance cost.
13

15. Key Observations - 2
• Lack of a comprehensive research framework
– Many candidate architectures and protocols have
been proposed, but there is no comprehensive
framework to compare their performances in a
fair and objective way.
– A new research framework should be able to take
into account the energy efficiency and elasticity of
architectures and protocols as well as the
performances perceived by users (i.e., reflecting
QoE).
14

16. Key Observations - 3
• Importance of experiments in the study of
NGOA systems
– Due to the complexity of protocols and the
interaction among multiple traffic flows in the
study of network architectures, researchers now
heavily depend on experiments with simulation
models or test beds implementing proposed
architectures and protocols, rather than
traditional mathematical analyses under
simplifying assumptions.
15

17. Key Observations - 4
• Need of a powerful and flexible test bed for
experiments
– To provide the whole protocol stack up to the application
layer, measurement of user-perceived performances, and
traffic generation based on user behavior.
– To enable researchers and network operators/service
providers to test candidate NGOA systems under a realistic
and long-term operating environment.
• We are aiming to investigate the impact of (at least) daily usage
patterns of residential & business users on network performances.
16

18. What Should We Do Now?
• Because we are at an early stage of research for long-term
NGOA solutions, we need to establish a comprehensive
research framework for comparing candidate network
architectures and protocols and implement a powerful and
flexible test bed for actual experiments under a realistic
operating environment.
• Then, we should carry out the investigation of both new (e.g.,
energy efficiency, elasticity) and old (e.g., performances, cost)
issues for candidate network architectures and protocols based
on the proposed research framework and test bed.
17

19. Clean-Slate Design of NGOA
Virtual
Test Bed
NGOA
Components &
Architectures
18
Comparative
Analysis
Framework
Revenue & User
Behaviour
Modelling
18

20. Need of Clean-Slate Design
• To take into account the fundamental changes of NOGA
in 10-plus-year time frame, we need to revisit from
scratch the following issues:
– Research framework
• Comparative analysis
• Quantification of bandwidth and power consumption
• Traffic generation and performance measures
– Architectures
• WDM-PON, hybrid PON, OFDMA-PON, ODSM-PON*.
– Protocols and algorithms
• Switching/routing, scheduling, flow control, framing, link adaptation.
– Revenue models
• Based on new consumer demands and usage behaviours.
19* Opportunistic and dynamic spectrum management PON

21. Our Approaches
• We will design from scratch and investigate the
issues of energy efficiency, elasticity, and cost based
on user-perceived performances under a realistic &
long-term operating condition.
• Our approaches will give us new insights on critical
issues in NGOA architectures and protocols including
– Quantification of network capacity based on user-perceived performances.
– Evaluation of energy efficiency , elasticity, and cost of candidate systems based
on the (statistically) equivalent user-level performances.
– Investigation of merits/demerits of shared & dynamic architectures with
respect to dedicated & static architectures.
20

22. II. New Comparative Analysis
Framework
21

23. Motivation
• Due to the complexity of protocols and the interactive nature
of traffic involved in the study of network architectures,
researchers now heavily depend on experiments with
simulations or test beds.
• Due to the shift toward experiments, comparison procedures
should be able to take into account the statistical variability in
measured data from the experiments.
• Measures for the comparison should be user-oriented (i.e.,
QoE-based) and multiple measures should be compared
together in an integrated way.
22

24. Issues in Comparison - 1
• The comparison between
two delay curves shown in
the figure seems
straightforward at first
glance.
• In fact, it is not
straightforward when we
consider the statistical
variability in measured
data.
– A statistical approach is needed!
23
Load
Delay
System A
System B
x

25. 24

26. Issues in Comparison - 2
• How can we compare
multiple performance
measures of two systems in
an integrated way?
– Can we say that the system A is
at least as good as the system
B?
• If so, on what basis?
• How can we relate network-
level performances to user-
perceived performance (i.e.
QoE)?
25
Measure System A System B
Delay 10 ms 9.5 ms
Throughput 100 MB/s 97.6 MB/s
Packet Loss
Rate
5 % 7 %

27. Existing Works on
Comparison Framework
• Equivalence Testing1
– Frequently used in Medicine and Biology for the
establishment of the equivalence (often called
bioequivalence) between two different clinical trials or
drugs through statistical hypothesis testing.
• Equivalent Circuit Rate (ECR)2
– A measure for shared packet access network, which
specifies the rate of a dedicated connection that is
equivalent to the shared system in terms of user-perceived
performance (i.e., web page delay).
– Currently state-of-the-art in networking research.
26
1. R. L. Berger and J. C. Hsu, “Bioequivalence trails, intersection-union tests, and equivalence confidence sets,”
Statistical Science, vol. 11, no. 4, pp. 283-319, 1996.
2. N. K. Shankaranarayanan et al., “User-perceived performance of web-browsing and interactive data in HFC cable
access networks,” Proc. of ICC’01, vol. 4, Jun. 2001, pp. 1264-1268.

28. App.
Server
App.
Server
RB
RB
Reference Architecture
R = min(RF, RD) (  1.0)
ONU 1
User 1
User n
…
RF
RD
RD
Candidate Architecture
ONU 1
ONU N
…
User 1
User n
…
User 1
User n
…
RU
RU
OLT
OLT
RU
Comparative Analysis Framework
based on ECR
27

29. Original ECR Calculation Procedure
28
Simulation with
reference model
(Point-to-point)
Build a function
f(R)=Dw
given the # of sessions
Simulation with
candidate model
(TDM-PON, Hybrid PON, …)
Find Dw
given the # of sessions
Solve
f(ECR)=Dw
* R: Access line rate
* DW: Web page delay

30. Issues in Original ECR Framework
• Use of a single performance metric
– HTTP traffic alone cannot provide enough load for
the NGOA with 10+ Gbit/s capacity.
– A broad spectrum of applications/services for
future NGOA needs to be covered.
• No systematic comparison procedure
– No procedure is provided for the comparison of
simulation results.
29

31. New Comparative Analysis Framework
• Construct a new framework extending the original
ECR framework as follows:
– What to compare
• Multiple user-perceived performances covering broad spectrum of
applications/services for future NGOA
• Percentile (including average and maximum) of performance
measures
– How to compare
• Comparison of a single performance measure: Based on non-
inferiority testing (at least as good as; one-sided variant of the
equivalence testing).
• Integration of multiple single-performance comparisons: Based on
intersection-union testing (IUT).
30

32. Equivalence or Non-inferiority? - 1
• Equivalence test is based on “acceptable
difference” limits as follows:
– 𝐻0: 𝜇 𝑅 − 𝜇 𝐶 ≤ 𝜃 𝐿 or 𝜇 𝑅 − 𝜇 𝐶 ≥ 𝜃 𝑈
– 𝐻 𝐴: 𝜃 𝐿 ≤ 𝜇 𝑅 − 𝜇 𝐶 ≤ 𝜃 𝑈
31

33. Equivalence or Non-inferiority? - 2
• However, do we really need the two-sided
criterion in comparing network architectures
based on performance measures (i.e., QoE)?
– “At least as good as (i.e., non-inferiority)” would
be more appropriate criterion here.
– So the hypotheses in this case are:
• 𝐻0: 𝜇 𝑅 − 𝜇 𝐶 ≤ 𝜃 (or 𝜇 𝑅 − 𝜇 𝐶 ≥ 𝜃)
• 𝐻 𝐴: 𝜇 𝑅 − 𝜇 𝐶 > 𝜃 (or 𝜇 𝑅 − 𝜇 𝐶 < 𝜃)
– Direction of inequality depends on a measure (e.g., delay,
throughput).
32

34. Extended ECR Calculation
Procedure - 1
• First, obtain measures of the user-perceived
performances for applications/services (i.e.,
𝑀1, ⋯ , 𝑀 𝑁 𝑀
) of the reference architecture for the
line rates of 𝑅1, ⋯ , 𝑅 𝑁 𝑅
where 𝑅1 = 𝑚𝑖𝑛 𝑅 𝐹, 𝑅 𝐷 ,
𝑅 𝑁 𝑅
> 0, and 𝑅𝑖 > 𝑅𝑗 for 𝑖 < 𝑗.
– 𝑁 𝑀 and 𝑁 𝑅 denote the number of performance measures
adopted and the number of values for R (i.e., 𝑅𝑖’s) used for
comparison, respectively.
33

35. Extended ECR Calculation
Procedure - 2
• Second, using the procedures in the next slides, find
a value for the line rate of the reference architecture
for which the measures of the candidate architecture
are statistically non-inferior to those of the reference
architecture.
– The null and the alternative hypotheses of the non-
inferiority testing for measure 𝑀𝑖 are given by
𝐻0: 𝜇𝑖,𝑅 − 𝜇𝑖,𝐶 ≤ 𝛿𝑖
𝐻1: 𝜇𝑖,𝑅 − 𝜇𝑖,𝐶 > 𝛿𝑖
where 𝜇𝑖,𝑅 and 𝜇𝑖,𝐶 denote population means of 𝑀𝑖 for the
reference and the candidate architectures, respectively,
and 𝛿𝑖 represents the tolerance for the measure 𝑀𝑖.
34

36. ECR Calculation Procedure
Based on Multivariate Non-inferiority Testing
Start
i = 0
Multivariate non-
inferiority testing
(of candidate w.r.t.
reference with the line
rate of Ri)
result = pass?
(Non-inferior?)
i < NR?
No
i = i + 1
Yes
Failed
No
ECR = Ri
Yes
End
• NR: Number of values for R (i.e., Ri’s) used
for comparison
35
See the next slide.

37. Multivariate Non-inferiority Testing
Based on Intersection-Union Test (IUT)
Start
i = 0
Non-inferiority testing
for measure i
(of candidate w.r.t. reference)
Reject H0?
(Non-inferior?)
i < NM?
Yes
i = i + 1
Yes
result = pass
No
result = fail
No
End
• NM: Number of performance measures
adopted
36

38. Benefits of a New Comparison
Framework
• We can present the combined performance (i.e.,
ECR) of a system in a more compact way, given the
configuration.
• We can compare non-traditional measures of
systems (e.g., energy efficiency, cost, and the amount
of resources) in a fairer way under the
configurations (of systems) providing the same ECR.
37

39. Challenges of a New Comparison
Framework
• Measurement of user-perceived performances
under a realistic operating environment
requires
– Traffic models based on user behaviours for
applications/services.
– A test bed to carry out experiments under a
realistic operating environment and obtain higher-
level measures for user-perceived performances.
• We need massive computational power to compute a
test statistic of measures for the ECR calculation.
38

40. III. Virtual Test Bed for
Experiments
39

41. Why Not Real Test Bed?
• A real test bed is good for the R&D of systems already
standardised, but not cost-efficient and flexible enough for
the clean-slate design of NGOA with the following features:
– Multiple candidate systems are tested and compared.
– A whole protocol stack (up to application layer), together with user
behavior models, is used for the investigation of interaction among
traffic flows as well as realistic traffic generation.
• We want a common reference framework for experiments to
be available for researchers in both Academia and Industry
(not physically confined to a certain lab/institution) in order to
properly benchmark candidate systems and exchange their
results.
– Like ns in early days of the study of TCP protocols1,2.
40
1. K. Fall and S. Floyd, “Simulation-based comparisons of Tahoe, Reno and SACK TCP,”
SIGCOMM Comput. Commun. Rev., vol. 26, pp. 5–21, Jul. 1996.
2. L. Breslau et al., “Advanced in network simulation,” IEEE Computer, vol. 33, no. 5, pp. 59-67, May 2000.

42. Our Solution
• A virtual test bed which will be implemented as
simulation models for both systems under test (SUT)
and supporting environments (e.g., application
server, user nodes) and run in a large-scale with the
help of cloud computing.
• Features:
– Simulation models based on OMNeT++/INET framework1.
– Message passing interface (MPI)2 for parallel extension of
large-scale simulation.
– Hybrid cloud based on local private cloud and remote
public cloud for scalable & cost-efficient computing.
41
1. http://www.omnetpp.org
2. http://www.mpi-forum.org

43. App.
Server
RB RF
RD
RD
ONU 1
ONU N
…
RTT
User 1
User n
…
User 1
User n
…
RU
OLT ODN
RU
RouterRouter
RB
SNI UNI
System Under Test
ODN: Optical Distribution Network
SNI: Service Node Interface
UNI: User Node Interface
RTT: Round-Trip Time
Overview of Virtual NGOA Test Bed
42

44. Traffic Generation in Existing Work
• Traffic is usually generated at
the data link/network layer
based on a frame/packet-
level traffic models.
– Due to the computational
complexity involved with
implementation of higher layers
and protocols.
– This approach, however, cannot
capture the interactive nature of
real traffic in actual networks.
43
Application/
Session
Transport
Network
Data Link
Physical
or

45. Traffic Generation in Our Work
• Traffic will be controlled and
initiated by the user (via its
behaviour model) and generated
through the whole protocol layers
(including application/session and
transport).
– In this way, we can capture the
interactive nature of real traffic in
actual networks in the virtual test
bed.
– Also, we can take into account traffic
patterns for different types of users.
• e.g., business vs. residential users
44
Application/
Session
Transport
Network
Data Link
Physical
User

46. Overview of User (Host) Node
TCP
UDP
Network
and Lower
Layers
…
…
…
UNI
HTTP 1
FTP 1
HTTP nh
FTP nf
Video nv
Video 1
User
Behaviour
Model

47. User Behaviour-Based
Traffic Modelling and Generation
User Behaviour
Model
Session-Level
Traffic Model
Packet/Frame-
Level Traffic
Generation
X1 X2 Xn
Y1 Y2 Ym


46

48. Measurement of User-Perceived
Performances
• Capturing user-perceived performances as objective
measures of QoE
• Use of session- or video-frame-level metric
– Session delay; web page delay for HTTP and file downloading delay for
FTP.
– Decodable frame rate (DFR) for video stream.
• Measurement of percentiles
– Mean and maximum as special cases.
47

49. Session-Level HTTP Traffic Model
• A behavioural model for user(s) web browsing* with the
following simplification:
– No caching and pipelining
– Adapted for traffic generation at the client side
48
* J. J. Lee and M. Gupta, “A new traffic model for current user web browsing behavior,”
Research@Intel, 2007.
Server
Client
Request for
HTTP object
Request
for embedded
object 1
Response
Parsing Time Reading Time
…
Request
for embedded
object 2
Response to the last
embedded object
Request
for HTTP
object
Web page delay (= session delay)

50. Session-Level FTP Traffic Model
• A simple model for user(s) file downloading*:
– Could be considered as HTTP sessions just downloading files.
– The model is for a data transfer connection only.
• A connection for control information is ignored.
– Adapted for traffic generation at the client side
49
Server
Client
Request for
a file to download
Reading Time
Response to the
file
Request for
a file to download
File download delay (= session delay)
* cdma2000 Evaluation Methodology, 3GPP2 C.R1002-B, 3GPP2 Std., Rev. B, Dec. 2009 .

51. Streaming Video Traffic Model
• Interface with OMNeT++/INET framework
– Through “UDPVideoStream{Svr,Cli}WithTrace”
modules:
• UDP server can handle multiple client requests
simultaneously
• Random starting phase for each request
• Wrap around to generate infinite streams
• UDP client records the following performance metrics:
– Packet end-to-end delay (vector)
– Packet loss rate
– Frame loss rate
– Decodable frame rate (perceived quality metric)
50

52. Implementation of Virtual Test Bed
GPON Test Bed
Private Cloud
Cloud Computing
51

53. Hybrid Cloud for Seamless Development
and Running of Programs
• We will build a hybrid cloud
integrating a small-scale, private
cloud and a large-scale public
cloud (Amazon EC21)
– An identical environment for
both the development of
programs at a local private
cloud and the run of them at a
remote public cloud without
change of code
– Based on open-source
solutions
• OpenNebula (distributed VM
management)
• StarCluster (clustering and
load balancing)
1. Currently supported by Amazon Web Services (AWS) in Education Research Grant.
2. R. S. Montero, “Scaling out computing cluster with Amazon EC2: Hands on!,”
ESAC Grid Workshop, Madrid, Spain, Dec. 2008.
2
52

54. IV. Preliminary Results:
Elasticity of Hybrid PON
53

55. System Model – Dedicated Reference
• Number of ONUs (N): 1
• Number of hosts per ONU (n): 1, 2, …
• Access rate (RD = RF): 1, 10 Gbit/s
• UNI rate (RU): 10 Gbit/s
• Backbone rate (RB): 1 Tbit/s (future standard or MUX of 100-
Gbit/s links)
• Round-trip time (RTT): 10 ms (including 600 µs RTT in 60-km
PON)
54
App.
Server
ONU 1
RD = RF
Host 1
Host n
… Backbone
RTT
RB
RU

56. System Model – Hybrid PON
• Number of ONUs (N): 16
• Number of Hosts per ONU (n): 1, 2, …
• Distribution/Feeder Rates (RD, RF): 10 Gbit/s
• UNI Rate (RU): 10 Gbit/s
• Number of Transceivers (NTX, NRX): 1, 2, …
• Backbone Rate (RB): 1 Tbit/s
• Round-Trip Time (RTT): 10 ms
55
RF App.
Server
ONU 1
ONU N
…
RD
RD
Host 1
Host n
…
Host 1
Host n
…
RTT
RB
OLT
RU
TX, RX

57. Number of Sessions per Each Traffic
• nh = nv = 1
– Assume that a user can watch and interact with at most one
video channel and one web session simultaneously at any
given time.
• As far as user perceived (interactive) performance is concerned.
• nf should be kept large to load the high-speed access
link
– FTP is usually background process.
• This could be HTTP sessions just downloading files!
– Suggest 10 as a starting point.
• Cannot find FTP model for 10 Gbit/s link at this time!
56

58. HTTP Traffic Model -1
Parameters / Measurements Best Fit (Parameters)
HTML Object Size [Byte] /
Mean=11872, SD=38036, Max=2 M
Truncated lognormal (=7.90272,
=1.7643, max=2 M)
Mean=12538.25, SD=45232.98*
Embedded Object Size [Byte] /
Mean =12460, SD=116050, Max=6 M
Truncated lognormal (=7.51384,
=2.17454, max=6 M)
Mean=18364.43, SD=105251.3
Number of Embedded Objects /
Mean=5.07, Max=300
Gamma (=0.141385, =40.3257)
Mean=5.70, SD=15.16
Parsing Time [sec] /
Mean=3.12, SD=14.21, Max=300
Truncated lognormal (=-1.24892,
=2.08427, max=300)
Mean=2.252969, SD=9.68527
Reading Time [sec] /
Mean=39.70, SD=324.92, Max=10000
Lognormal (=-0.495204, =2.7731)
Mean=28.50, SD=1332.285
Request Size [Byte] /
Mean=318.59, SD=179.46
Uniform (a=0, b=700)
Mean=350, SD=202.07
57* Assuming MB = MiB (Mebibyte; 230)

59. HTTP Traffic Model - 2
• With RTT=10ms & synthetic traffic statistics:
– Avg. web page (session) delay: 2.3s
• = RTT*(1+E[Nembedded_object])+E[TParsing]
• Ignoring transmission delay
– Avg. session period (including reading time): 30.8s
– Avg. load (# of bits/session period): 30.4 kbit/s
• = 3803.2 B/sec
• 328670+ sessions needed to fully load 10 Gbit/s line!
(328+ for 10 Mbit/s line)
58

60. Streaming Video Traffic Model
• HDTV quality, realistic, high bit-rate video traffic models
are needed for NGOA
– Use H.264/AVC video traces
– “Terminator 2” VBR clip from ASU Video Trace Library
• Duration: ~10 min
• Encoder: H.264 FRExt
• Frame Size: HD 1280x720p
• GoP Size: 12
• No. B Frames: 2
• Quantizer: 10
• Mean frame bit rate: 28.6 Mbit/s
– ~334 streams needed to fill 10 Gbit/s line with the following assumption:
» Total overhead: 66 Bytes
• RTP(12), UDP(8), IP(20), and Ethernet (26)
» RTP payload: 1460 Bytes
• In case of 1500-byte MTU
59

61. FTP Traffic Model - 1
Parameters Probability Distribution Function (PDF)
File Size [Byte] /
Mean=2 M, SD=0.722 M, Max=5 M
Truncated lognormal (=14.45, =0.35,
max=5 M)
Mean=1995616(~2 M), SD=700089.8(~
0.70M)
Reading Time [sec] /
Mean=180
Exponential (l=0.006)
Mean=166.667, SD=166.667
Request Size [Byte] /
Mean=318.59, SD=179.46
Uniform (a=0, b=700)
Mean=350, SD=202.07
60

62. FTP Traffic Model - 2
• With RTT=10ms & synthetic traffic statistics:
– Avg. session delay: 10 ms
• = RTT
• Ignoring transmission delay
– Avg. session period (including reading time): 166. 68
s
– Avg. load (# of bits/session period): 95.8 kbit/s
• = 11972.7 B/sec
• 104384+ sessions needed to fully load 10 Gbit/s line!
(104+ for 10 Mbit/s line)
61

63. TCP Parameters
• Protocol: Reno
– New Reno, SACK?
• MSS: 1460
– Default: 536
– Optimized for Ethernet interface
• 1452 for PPP
• Advertised window:
– Default: 14*MSS
62

64. Network Parameters
• Queueing policy: Drop Tail
• Ethernet NIC frame buffer size: 10k frames
– Based on RTT(10ms) * BW(10Gbit/s)
•  (10ms * 10 Gbit/s) / 1518*8 bits/frame
• OLT VoQ and ONU FIFO queue sizes:
121,440,000 bits
– Corresponding to 10k maximum size (1518 bytes)
Ethernet frames
63

65. Simulation Runs
• 30 hours with 20-min warmup-period
• 10 replications
– Corresponding to about 3000+ HTTP/500+ FTP
sessions
• Rule of thumb (e.g., SMPL text book) recommends at
lest 2500 samples with 5 replications.
– 20+ replications for normal distribution
assumption in t-test in the future
64

66. Post-Processing
• Statistical analysis: R
• General scripting: Perl, Python, Shell (bash)
• Plotting: SciPy with matplotlib
65

67. Initial Results: Elasticity of Hybrid
TDM/WDM-PON
• The figure shows the min.
number of tuneable
transceivers (min(Ntx)) of
hybrid PON to achieve the
ECR of Rtarget Gbit/s.
– For the reference architecture,
the number of transceivers is
fixed to the number of ONUs
(subscribers), independent of
the network load.
– The hybrid PON, on the other
hand, can adjust the number of
transceivers depending on the
network load.
66

68. V. Summary
67

69. Summary
• We have been investigating the issues of quality of experience (QoE), elasticity*, and
energy efficiency in NGOA with a focus on the solutions beyond 10G-EPON/XG-PON
(i.e., NG-PON2 by ITU-T) and found out that the progress in the clean-slate design of
NGOA has been impeded by the absence of a comprehensive research framework for
a comparative analysis of candidate network architectures and protocols.
• We propose, therefore, a research programme for the clean-slate design of NGOA
with the following major objectives:
– A new comparative analysis framework based on statistical hypothesis testing and user-
perceived performances;
– User behaviour modelling for future services and applications;
– Virtual test bed for experiments under a realistic operating environment;
– Energy-efficient and elastic components and architectures.
• The results of the proposed research programme will not only enable researchers to
carry out a fair and objective comparison of various candidate architectures and
protocols, but also allow network operators & service providers to dimension their
future NGOA under a realistic environment through the virtual test bed.
68
* The elasticity in the context of networking means the ability to manage overall
performances by fast provisioning of network resources based on user demands.