Network protocol for multimode FTTH/FTTB · FTTB Fiber to the Building. FTTH Fiber to the Home. OLT...

Thesis for the degree of Master of Science

Faculty of Electrical Engineering, Mathematics and Computer Science

Design and Analysis of Communication Systems (DACS)

University of Twente, the Netherlands

Network Protocol for multimode FTTx

Matthijs de Haan

November 21, 2007

Supervising committee:

Prof. ir. A.C. van BochoveDr. ir. P.T. de Boer

R.O. Taniman, M.Sc.

Abstract

Currently services such as telephony, television and internet are deliveredon different kinds of media. Telephony is brought to homes using a copperwire, television with coax cable and internet is delivered on one of thesemedia or on a separate optical fiber. The trend is to merge all these ser-vices on to one “Full service access network”. One of such a FSAN is beingdeveloped based on passive optical networks (PON). Normally PONs usesingle-mode fiber, but in this special case multimode fiber is used to reduceinstallation and maintenance costs.

This thesis focusses on the network protocol. Since the network is anovel approach existing designs for network protocols cannot be applieddirectly to the network. But, with the help of these existing designs, so-lutions, ideas and protocols implemented in existing PON architectures, anew network protocol is designed. This design is implemented in OPNETand with the implementation two simulations have been executed. Thefirst simulation investigates the discovery process with a worst case sce-nario. The second simulation tests a priority scheduling mechanism andshows how it behaves with an increasing overall traffic load on the net-work.

The results of the first simulation show that the discovery phase canhandle a worst case scenario with 32 new ONUs. The results of the secondsimulation (with the priority scheduling) show that even with quite a heavyload the different priority queues are still handled according to the QoSrequirements.

i

Contents

1 Introduction 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Research goal . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Arrangement of the next chapters . . . . . . . . . . . . . . . . 2

2 Related systems and technology 32.1 Passive optical network . . . . . . . . . . . . . . . . . . . . . 32.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.1 Fiber . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2.2 Burstmode receiver . . . . . . . . . . . . . . . . . . . . 5

2.3 Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4 Network Protocols for shared media . . . . . . . . . . . . . . 82.5 Two Standards: APON versus EPON . . . . . . . . . . . . . . 92.6 Network protocol: Multipoint Control Protocol . . . . . . . . 10

3 Protocol Design 133.1 Required Service Specification . . . . . . . . . . . . . . . . . . 13

3.1.1 Informal Description . . . . . . . . . . . . . . . . . . . 133.1.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . 143.1.3 Environment . . . . . . . . . . . . . . . . . . . . . . . 143.1.4 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 143.1.5 Lower Level Service . . . . . . . . . . . . . . . . . . . 14

3.2 Protocol Design . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2.1 Design Paradigm . . . . . . . . . . . . . . . . . . . . . 153.2.2 Informal Description . . . . . . . . . . . . . . . . . . . 153.2.3 Internal Structure . . . . . . . . . . . . . . . . . . . . . 163.2.4 Discovery Phase . . . . . . . . . . . . . . . . . . . . . 173.2.5 Assignment Phase . . . . . . . . . . . . . . . . . . . . 203.2.6 Addressing Scheme . . . . . . . . . . . . . . . . . . . 213.2.7 Ranging and timing . . . . . . . . . . . . . . . . . . . 223.2.8 Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2.9 LLID order . . . . . . . . . . . . . . . . . . . . . . . . . 25

iii

iv CONTENTS

3.2.10 Measuring . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.11 Transmission Errors . . . . . . . . . . . . . . . . . . . 283.2.12 Security Issues . . . . . . . . . . . . . . . . . . . . . . 29

3.3 Protocol Specification . . . . . . . . . . . . . . . . . . . . . . . 293.3.1 SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3.2 Message Header . . . . . . . . . . . . . . . . . . . . . 303.3.3 Message Content . . . . . . . . . . . . . . . . . . . . . 313.3.4 Finite State Machine . . . . . . . . . . . . . . . . . . . 33

3.4 Dimensioning and Timing . . . . . . . . . . . . . . . . . . . . 363.4.1 Epoch length . . . . . . . . . . . . . . . . . . . . . . . 36

4 Simulation 414.1 OPNET implementation . . . . . . . . . . . . . . . . . . . . . 41

4.1.1 Traffic Generation . . . . . . . . . . . . . . . . . . . . . 434.2 Mean Values and confidence intervals . . . . . . . . . . . . . 434.3 Discovery Phase . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.3.1 Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.3.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.4 Intra-ONU Priority Scheduling . . . . . . . . . . . . . . . . . 504.4.1 Traffic Generation for the particular ONU . . . . . . . 504.4.2 Traffic load for the other ONUs . . . . . . . . . . . . . 524.4.3 Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.4.4 Requirements . . . . . . . . . . . . . . . . . . . . . . . 524.4.5 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5 Conclusion and Future Work 595.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

A OPNET Implementation 61

B Complete Results 65

List of Figures

2.1 Widely used PON layout . . . . . . . . . . . . . . . . . . . . . 32.2 Near-far problem: received power level from four timeslots 52.3 Frequency response . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1 “black box” view of the protocol . . . . . . . . . . . . . . . . 133.2 Abstract state diagram . . . . . . . . . . . . . . . . . . . . . . 153.3 internal view of the protocol . . . . . . . . . . . . . . . . . . . 163.4 Protocol Entity in detail . . . . . . . . . . . . . . . . . . . . . 183.5 Discovery phase with two ONUs . . . . . . . . . . . . . . . . 183.6 Assignment phase with two ONUs . . . . . . . . . . . . . . . 203.7 upstream TDMA overhead . . . . . . . . . . . . . . . . . . . . 233.8 Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.9 two ONUs and three subcarriers. . . . . . . . . . . . . . . . . 263.10 Message header . . . . . . . . . . . . . . . . . . . . . . . . . . 293.11 Messages types during discovery. . . . . . . . . . . . . . . . . 313.12 SNR request message . . . . . . . . . . . . . . . . . . . . . . . 323.13 SNR response message . . . . . . . . . . . . . . . . . . . . . . 323.14 Two formats for the assignment message . . . . . . . . . . . 343.15 State diagram of the assignment phase of the OLT . . . . . . 353.16 State diagram of an ONU . . . . . . . . . . . . . . . . . . . . 383.17 Minimal Duration of an Epoch . . . . . . . . . . . . . . . . . 39

4.1 Internal Processes with Information and Packet streams . . . 414.2 Design and Simulation implementation . . . . . . . . . . . . 424.3 Overlapping discovery windows . . . . . . . . . . . . . . . . 474.4 Number of discovery windows needed to register 32 ONUs 484.5 Bandwidth and traffic for two ONUs . . . . . . . . . . . . . . 544.6 Queueing Delays . . . . . . . . . . . . . . . . . . . . . . . . . 554.7 Queueing Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . 56

A.1 State diagram for control process in ONU. . . . . . . . . . . . 62A.2 State diagram for control process in OLT. . . . . . . . . . . . 63

B.1 Total bandwidth versus total traffic load . . . . . . . . . . . . 72

v

vi LIST OF FIGURES

List of Tables

2.1 APON vs. EPON . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1 Message type values . . . . . . . . . . . . . . . . . . . . . . . 303.2 control messages, size and duration . . . . . . . . . . . . . . 37

4.1 Bandwidth requirements per video format . . . . . . . . . . 514.2 Heavy traffic model . . . . . . . . . . . . . . . . . . . . . . . . 51

B.1 Complete results of discovery phase measurements . . . . . 65B.2 Confidence intervals of discovery phase . . . . . . . . . . . . 66B.3 Mean values for queueing delay . . . . . . . . . . . . . . . . 67B.4 Jitter for queueing delay . . . . . . . . . . . . . . . . . . . . . 68B.5 Confidence intervals for queueing delay . . . . . . . . . . . . 69B.6 Normalized confidence intervals for queueing delays . . . . 70B.7 Simulation input for background traffic (per ONU) . . . . . 71

vii

viii LIST OF TABLES

Acronyms

EPON Ethernet Passive Optical Network (PON).

P2MP Point-to-MultiPoint.

FTTB Fiber to the Building.

FTTH Fiber to the Home.

OLT Optical Line Termination.

ONU Optical Network Unit.

PON Passive Optical Network.

TDMA Time Division Multiple Access. Technique to allow multiple userson a single interface using time slots.

WDMA Wave Division Multiple Access. Technique to allow multiple userson a single interface using different frequencies.

SCMA Sub carrier Multiple Access. Multiplexing technique somewhatsimilar to Wave Division Multiple Access (WDMA), however the mod-ulation is now done in the electrical domain instead of the opticaldomain.

MPCP Multi point Control Protocol.

CSMA Carrier Sense Multiple Access.

SAP Service Access Point.

LLID Logical Link ID.

RTT Round Trip Time.

QoS Quality of Service.

BER Bit Error Rate.

ix

1

Chapter 1

Introduction

1.1 Motivation

To accelerate the deployment of broadband access networks, several accessnetwork types are being proposed which should provide adequate capacityto handle multiple services for a reasonable number of users while at thesame time have relatively low deployment cost. Among these, one of thepromising solutions is the fiber-to-the-home (FTTH) / fiber-to-the-building(FTTB) solution based on passive optical networks (PON) which utilizemultimode fibers as the transmission medium. The project “Full-serviceAccess Network using Multimode Fiber” [1] investigates these possibili-ties.

Current implementations use singlemode fibers with one channel onthe baseband, all the clients share this channel by some form of Time Di-vision Multiple Access (TDMA). The new approach is to use multimodefiber and to use this fiber beyond the baseband spectrum using electricalsubcarriers. Problems arise as the quality of the channels is variable, onlyfor short periods of time one can assume the channel has a certain quality.This unstable physical layer introduces new problems and requires newtechnologies, new protocols and new solutions to be developed to make itusable for users.

1.2 Research goal

The goal of this assignment is to design a link-layer protocol (as the net-work is single-hop) which uses an earlier developed subcarrier assignmentmethod as its core algorithm. The algorithm may use out of band signalingthrough the baseband channel of the multimode fiber. Also, the networksetup and join/leave procedures should be devised as parts of the protocol.

2 Chapter 1. Introduction

1.3 Approach

• By literature research, study the existing related network protocols.

• Design a suitable network protocol for the above mentioned accessnetwork.

• Get familiarized with OPNET.

• Develop simulation codes for the proposed protocol.

• Perform simulations incorporating the previously develop subcarrierassignment method to assess the network performance.

1.4 Arrangement of the next chapters

Chapter two (Related Systems and Technology) discusses the available net-works and protocols. It outlines the hardware used and standards devel-oped for other hardware. Solutions presented for other networks are con-sidered and/or used in designing the network protocol.

Chapter three (Protocol Design) presents the design of the network pro-tocol. The chapter starts with an informal design and gradually increasesdetails, to end with formal message designs, state diagrams and timing de-tails.

Chapter four (Simulation) starts with a brief description of the imple-mentation in OPNET and details on how the results from the simulationare processed. Then two different types of simulations are done, the first ison the discovery phase, the second on intra-ONU priority scheduling.

Chapter five (Conclusion and Future work) states the conclusions andrecommendations.

3

Chapter 2

Related systems andtechnology

As outlined in the previous chapter this master thesis is a sub goal of alarger project that has a goal to create a Fiber to the Home (FTTH) networkusing passive optical network technology with multimode fibres. This chap-ter will discuss technologies and existing systems, and investigate possibil-ities to use these to design the protocol.

OLT

ONU1

ONU2

ONUn

cou

ple

r

! Figure 2.1: Widely used PON layout

2.1 Passive optical network

A PON is a point-to-multipoint, fiber network architecture. Typically a net-work consists of one Optical Line Termination (OLT) at the service provi-ders central office and a number of Optical Network Unit (ONU) near endusers. To connect the multiple ONUs to one OLT a passive optical splitteris used. The network is a Point-to-MultiPoint (P2MP) network, meaningsignals sent from the OLT are broadcasted to all the ONUs but signals froma specific ONU are sent only to the OLT. Figure 2.1 shows the most popular

4 Chapter 2. Related systems and technology

layout for PON’s, the protocol will be designed for this type of PON. Animportant fact to keep in mind is that the ONU’s cannot directly commu-nicate with each other, due to the way the optic coupler operates. Most ofthe work on PON focuses on TDMA. The IEEE 802.3 standard [2] section 5,clause 64 deals with the mechanism and control protocols required in orderto reconcile the P2MP topology into the Ethernet framework.

2.2 Hardware

2.2.1 Fiber

in optical networks two different types of fiber are used, singlemode fiberand multimode fiber. Multimode fiber has a larger core diameter than themore often used singlemode fiber. This larger core diameter makes it pos-sible to have more modes propagating through it, hence the name multi-mode fiber. The PON presented in this thesis will use multimode fibers,multimode fibers are cheaper, simpler to manufacture and the main ad-vantage: simpler to handle [3] compared to singlemode fibers. Also withmultimode fibers a higher frequency area of the fiber spectrum can be usedfor transmitting signals. Unfortunately these higher lobes have a problem;their frequency response is time and user dependent. The IOP-GenCom [1]project investigates possibilities to use these higher lobes in a FTTx system.

Network Span The downside of using frequencies beyond the basebandis that the attenuation increases drastically in these higher lobes of the spec-trum. This limits the span of the network, for the design of the protocol amaximum distance of five kilometer is taken into account.

Delay The maximum distance between an ONU and the OLT is assumedto be 5 kilometer. With a worst case fiber speedfactor of 1.5 the light speedin the fiber is approximately 200.000 km/s.

t =l

c=

5

200.000= 25µs (2.1)

25µs is the maximum value of the propagation delay between ONU andOLT, this results in a maximum Round Trip Time (RTT) of 50µs.

Because not all ONUs are located at 5 km distance the RTT may vary foreach ONU, theoretically between 0µs and 50µs. This difference in distancerequires the system to adjust the timing for each ONU to avoid collisions,this will be done at the startup time. Determining the RTT for each ONU iscalled ranging and will be discussed in detail in the next chapter.

2.2. Hardware 5

! Figure 2.2: Near-far problem: received power level from four timeslots(from [4]).

2.2.2 Burstmode receiver

Shared bus optical applications employ short burst or packets of digitaldata. AC-coupled fiber-optic receivers, intended for continuous data re-ception, are unusable in such applications. Therefore DC-coupled receiverarchitectures have been designed of handling intermittent, burst mode datatransmission [5].

Another problem arising is the fact that due to unequal distances be-tween OLT and ONU’s optical signal attenuation in the PON is not thesame for each ONU. The power level received at the OLT(gain power) willbe different for each timeslot(called the near—far problem). Figure 2.2 [4]shows the power levels of four timeslots received by the OLT from fourdifferent ONUs in a TDM PON. When the receiver is adjusted for a highpower signal and a low power signal is received it might mistake one’sfor zeros. The other way around is when a stronger signal is transmittedthan the receiver is configured for it might mistake zeros for ones. The re-ceiver should be able to quickly adapt to the power level signal, this can bedone by preceding the data burst with a preamble, a predefined (short) bitsequence for the receiver to adjust to the power of the signal.

An alternative approach is to allow ONU’s to adjust their transmitterpower such that power levels received by the OLT from all ONU’s becomethe same. This method is not particularly favored by transceiver design-


ers as it makes the ONU hardware more complicated [4]. Also, even moreimportant, limiting the powerlevel of near ONU’s will degrade their per-formance.

Since the distance between the OLT and a ONU can vary between zeroand five kilometers, and the fiber has an attenuation of 1 dB/Km the powerspread of our network is 5 dB. So, without adjusting the power of the ONUstransmitters the OLTs receiver should be able to handle signal powerleveldifferences of up to 5 dB.

2.3 Multiplexing

Multiplexing fiber optics can be done in various ways. The first and al-ready implemented technique is that of TDMA, see the next section whichwill discuss the currently used architectures. All the ONUs use the samechannel so protocols are needed to avoid collisions of data from differentONUs.

Another technique is WDMA. Each ONU has its own wavelength as-signed to transmit on. This is a rather expensive solution because eachONU gets its own wavelength and the OLT will need one laser for eachONU. Installation costs are high because ONU’s are not generic, each ONUwill need to be set to specific wavelength, also the large amount of lasers atthe OLT are expensive. The straightforward approach is to build a WDM-PON to employ a separate wavelength channel from the OLT to each ONU,for each of the upstream and downstream directions [6]. This approachcreates a point-to-point link between the OLT and each ONU, which differsfrom the point-to-multipoint topology of regular TDM-PONs. This staticwave division is not very efficient because traffic loads are not considered,e.g. when one ONU has nothing to send and another one a lot they bothhave the same bandwidth. WDM-PONs are still a research subject, hav-ing most of the attention focussed on the devices, the architectures havereceived moderate attention. Various proposals have been done (CPON,LARNET, RITENET, Multi-stage, Super-PON, Success-DWA, etc.) [6] withno clear winner yet.

Sub carrier Multiple Access (SCMA) is conceptually related to WDMA.Instead of modulation being done in the optical domain it is done in theelectrical domain. The multiplexed signal is fed to the (tunable) laser. Thisway a lot of channels can be multiplexed onto one laser, in the case of thisthesis 128 channels.

The network presented in this paper is will use a combination of TDMAand SCMA. For signalling purposes the baseband channel is used. Thischannel has a constant quality, the bandwidth of this channel is 100Mbps.All the ONUs use this channel for their signalling/control information,therefore a TDMA scheme is needed to provide a way to allow all the ONUs

2.3. Multiplexing 7

! Figure 2.3: Frequency response

to access this channel to communicate their control information with theOLT.

The data is transferred on out-of-baseband subcarriers, these subcarri-ers are in the higher-order lobes of the multimode fiber frequency response.The network will use 128 subcarriers. Using this area of the spectrum intro-duces problems new to the research area of PON. Channels in this spectrumare unstable, their quality is user, frequency and time dependent, see fig-ure 2.3. The figure shows one instance of the spectrum and can be differentfor a different moment of time or a different user. So at the same momentof time a certain channel might have a good quality for one ONU and at thesame time being useless for another ONU. Also, when for one ONU a cer-tain channel is assumed to have a good quality, a moment later the qualityof this channel is so low it cannot be used for data transfer. The varying ofthe quality during time can be solved by looking at a small instance, whenthis instance is short enough during that instance the quality is constant.For a period of 100ms it is assumed the quality of a channel is constant.This period is a called an epoch, during this epoch 1000 symbols are sent.A symbol consists of one or more bits, this depends on the quality of thechannel — in other words: the better the quality of the channel the morebits can be transferred on this channel. This varying of the bits per symbolis called multilevel modulation.

These problems are well known in the research concerning radio sys-tems. Systems such as UMTS, Wifi, WiMax but also ADSL do operate in a


time varying channel.The system is bidirectional, so for both the upstream and downstream

the ONUs have 128 channels to divide. As previously mentioned, due tousing these out-of-baseband subcarriers the systems span is limited to 5km.

2.4 Network Protocols for shared media

The previous section outlines the setup of the network, in this setup onechannel (the control channel) is shared by all the users of the network (OLTand ONUs). For such shared media various protocols have been designed.

Aloha The classical Aloha [7] scheme was invented at the University ofHawaii and was used for wireless communication in the ALOHANET forwireless communication of several stations. Aloha neither coordinates me-dium access nor does it resolve contention on the MAC layer. Instead eachstation can access the medium at any time, this is a random access scheme,without centralized control or coordination among the station. The schemeis contention based which mean packets sent from two different stationmight collide, if this happens the two packets are destroyed. The problemis left to higher layers (e.g. retransmission). The simple Aloha works forlight loads and does not require complicated access mechanisms. On theclassical assumption that data packet arrival follows a Poisson distribution,maximum throughput is achieved for an 18 percent load [8]. A first refine-ment of this scheme is providing timeslots for the stations to send in. Inthis case the stations should be synchronized. Still, access is not coordi-nated, however with the slots the throughput is improved to 36 percent [8],twice the throughput of classic Aloha. Aloha works good for light loadsand the principle can be used for the discovery phase of the protocol.

Carrier Sense Multiple Access One improvement to the basic Aloha issensing the carrier before accessing it, this is what carrier sense multiple ac-cess (CSMA) schemes generally do. Unfortunately, because of the way thecoupler in a point-to-multipoint network operates, an ONU cannot senseif another ONU is occupying the media. Several versions of CSMA exists.In non-persistent CSMA, when stations have data to send they wait forthe medium to be idle and start sending immediately. P-persistent CSMAsystems also sense the medium but start sending the next frame with prob-ability p-1. p is defined as the chance a station starts transmitting when thechannel is free. Another improvement on shared media is the use of colli-sion detection. Which is also not possible on PONs, for the same reason ascarrier sensing is not possible.

2.5. Two Standards: APON versus EPON 9

! Table 2.1: APON vs. EPON

APON GPON EPON

Standard body ITU-T/FSAN ITU-T/FSAN IEEEStandard G.983 G.984 802.3ahMaximum bandwidth 622 Mbit/s 2.488 Mbit/s 1 Gbit/sProtocol overhead for IP services Large Large SmallFraming ATM GFP/ATM Ethernet

2.5 Two Standards: APON versus EPON

Two standards for Passive Optical Networks have been developed overthe years, they are both TDM based. They use two wavelengths, one forupstream and one for downstream. APON was the first standard and isbased on the ATM scheme and EPON is the standard based on the Ethernetscheme. Each standard has successors mostly improving the bandwidth,for APON this is GPON. For EPON this is Next Generation EPON, whichis still in development phase, the EPON standard already allows for thedefinition of faster EPONs.

APON/GPON APON has been developed by the FSAN initiative [9], theydesigned a basic set of common requirements. These requirements have be-come the ITU-T Recommendations G.983 series. Key technology in APONis ATM, a well known switching and transfer methodology that can han-dle different types of services like voice, video, and data in the same net-work with guaranteed Quality of Service [10]. The maximum bandwidthof APON is 622 Mbit/s.

APON and BPON are basically the same, however using the term APONled users to believe only ATM is used so FSAN decided to broaden thename to Broadband PON. BPON systems offer numerous broadband ser-vices including Ethernet access and video distribution. However still ATMis used as the underlying transport technology, so IP services will have tobe mapped on the ATM standard, causing lot of overhead.

The APON frame format defines 53 slots of 56 bytes for the upstreamchannel and 56 slots for the downstream channel. At the beginning andmiddle of a downstream frame Physical Layer Operation and Maintenance(PLOAM) cells are inserted, for control purposes. In each upstream slot a3 byte overhead header and a 53 byte ATM cell may be transmitted by oneONU. Which ONU is allowed to transmit is decided by the value in thegrant field in the downstream PLOAM.

GPON is an evolution of the BPON standard with higher bandwidths,


enhanced security and choice of Layer 2 protocol (ATM, GEM, Ethernet),and is standardized in ITU-T G.984 [11]. This higher bandwidth in GPONis 2.488 Mbit/s. To allow for this line rate only 16 bit times (less than 13ns)are allocated for the laser-on and laser-off times. Such short intervals re-quire more expensive, higher speed laser drivers at the ONU. To reducethe range of necessary gain adjustment (discussed in section 2.2.2) BPONand GPON perform a power-leveling operation in which the OLT instructsthe ONU’s to adjust their transmitting power so that the level of the sig-nals arriving at the OLT have approximately an equal power. The GenericFraming Protocol (GFP) [12, 13] protocol used in GPON was designed tomake a more flexible standard, since the use of ATM in BPON creates ahigh overhead, or celltax [14], when using Internet-based services.

EPON The Ethernet based PONs are standardized by the IEEE. The ideawas to make use of the huge base of low-cost Ethernet designs to allow forsimpler, less expensive technology to be used in PONs. The downside isis that Ethernet is designed for bursty data and not for CBR or TDM ser-vices. The maximum rate for EPON is nominally 1.25 Gbit/s, but due to theuse of 8B/10B coding it is effectively 1 Gbit/s. In the EPON standard [2]only the networks physical layer is specified, the protocols used to assignbandwidth to the users, ensuring fairness and QoS, are left open to the im-plementer. Where possible, EPON utilizes the existing 802.3 specification.Several Dynamic bandwidth allocation algorithms have been developed touse in EPON [15].

Compared to the APON/GPON the EPON standard specifies more re-lax parameters: laser-on and laser-off time = 512 ns and a gain adjustmenttime smaller than 400 ns (negotiable).

The next generation of EPON will bring 10 Gb/s bandwidth to accessnetworks [16,17]. It will focus on defining a new point-to-multipoint phys-ical layer, keeping the MAC, MAC Control and all the layers above un-changed to the greatest extent possible.

Differences between APON and EPON are the cost of the equipment,APON requires more complex and expensive equipment than the EPONstandard mainly due to the differences in burst sizes (56 bytes comparedto 1500 bytes). Also the mapping of Internet services onto the networkcan be done more easily with EPON than APON because of the Ethernettechnology.

2.6 Network protocol: Multipoint Control Protocol

Signaling can be done on the data channels (inband) or on a separate chan-nel dedicated to signaling (outband). An example of the use of inband

2.6. Network protocol: Multipoint Control Protocol 11

signaling is Ethernet which uses the same channel for data and control in-formation. Out-of-band signaling is signaling that is done on a channel thatis dedicated for the purpose and is separate from the channels used for thedata. The physical layer in this project has a design which more or lessimplies an out-of-band signaling design, as there is one stable (baseband)channel and 128 channels with user and time variant parameters.

Before these 128 channels can be used, their parameters will have to bemeasured and then communicated by the OLT and the ONUs. Since thenetwork is point-to-multipoint (see section 2.1) there is a different proce-dure for the uplink and downlink measurements. For the downlink, at eachONU all the channels are received, an ONU can simply monitor the incom-ing traffic (not only looking at the channels ment for the ONU but also thechannels for other ONUs) and determine the quality of the channels. Whenthe OLT requests the results they can reply with the measurements of all 128channels. The uplink is a different story, since each channel is used by onlyone ONU. Measuring the data at the OLT will not be sufficient, per chan-nel only the frequency response from one ONU will be known. To solvethis a special measurement block will have to be created so each specificONU can send on all channels in parallel and the OLT can then monitorthe results. These block will be sent sequentially by each individual ONU.

It is logically to communicate this information on the baseband channel.Basically the system uses outband signaling (the baseband channel) and thedata channels are dedicated to data transfer, if the capacity of the basebandchannel is sufficient and the control information only needs a small portionof the bandwidth, data could also be sent on this channel. An “educatedguess” is that a large portion will be available for data transfer.

The datachannels are divided amongst the ONUs, each epoch an ONUwill be given a group of datachannels to use, a set for upstream and a setfor downstream. These channels can be used as a data stream to send andreceive data, so for these channels there is no network layer protocol re-quired. The channels will accept data packets and transport them alongthe channels on the fiber, no further functionality is required. The next partof this section will focus on the baseband and what network protocol canbe used for this. The baseband channel is used by all the ONUs so a TDMAprotocol is required.

The ONUs will have to share the medium because the network is point-to-multipoint(see section 2.1 for details). Several types of techniques exist.Contention techniques such as ALOHA(see section 2.4 on page 8) are tooinefficient because there are a relatively low number of ONUs on a PON,and they will be sending on a regular basis. More important, for the proto-col to function properly it is necessary the frames are transferred withoutthe possibility of collisions. Quite obvious, this requirement is not met byALOHA.

Carrier Sense Multiple Access (CSMA) is not an option because the


ONUs cannot sense each others upstream transmission. For PONs a token(or “grant”) scheme where ONUs are assigned time slots designated by theOLT makes more sense. An existing protocol which is used on TDMA net-works is the Multiple Point Control Protocol, standardized by the IEEE. Itis designed for Ethernet PONs. MPCP is a master/slave protocol with theOLT as master and the ONUs as the slaves. It is described in clause 64 ofthe IEEE 802.3 [2] standard. The idea of the protocol is to present the net-work as an ordinary Ethernet network to the users to easily use Internetand other IP based services on the network.

The protocol operates in two modes, the discovery mode and normalmode, the next sections will briefly discuss each mode.

Discovery The OLT will broadcast a gate message, when an unregisteredONU receives this it will reply with a register-request message. After sometime the OLT will stop listening for these requests—the discovery windowis closed. Now the OLT will process each request message is has received,it will send a register message to the ONU. The ONU will reply with anacknowledgement and the ONU is registered. To reduce slack during thisprocess also ranging is performed. This design will be used for our proto-col, the next chapter will discuss the whole procedure in detail.

GATE/REPORT mechanism After the discovery/registration process, datawill have to be sent. The OLT will grant the ONU a window in which itmay sent, this is done by means of GATE messages, during this windowthe ONU can also send a REPORT message. This report message containslocal information such as queue length. This information can be used toadjust the window size the next time the ONU is allowed to send. Thismechanism will be adapted and used in our protocol, it will be used to re-quest the ONUs for information about their queue length and the qualityof their data channels. When the OLT has all the information it needs, itwill calculate the channel distribution and inform the ONUs which datachannel they can use for the epoch. Again, this process will be thoroughlydiscussed in the next chapter.

The MPCP protocol will be the basic principle and starting point for thenew network protocol which is presented in the next chapter.

13

Chapter 3

Protocol Design

3.1 Required Service Specification

The first step in designing a protocol is clearly defining what services itshould offer to the users and what lower level service is provided to theprotocol. After these “external” factors are determined the internal behav-ior of the protocol can be designed.

This service specification defines the observable behavior of a systemas it can be experienced by the service users at the Service Access Point(SAP). A service corresponds to the shared boundary between system andits environment.

3.1.1 Informal Description

OLT ONU1 ONUn

Protocol Service

! Figure 3.1: “black box” view of the protocol

The purpose of this protocol is to create a connection between an OLTand a number (up to 32) of ONU’s. The network architecture is point-to-multipoint, meaning the OLT broadcasts to all the ONU’s and an ONUonly sends to the OLT. Figure 3.1 shows the global view of the service. Theservice is presented as a black box, it provides a service to the users. The

14 Chapter 3. Protocol Design

service is provided to the users through the SAP’s, these are presented asellipses in the figure.

Complexity location The protocol can have an impact on the locationwhere the most calculations are done, the complexity can be placed in theOLT or at the ONU’s. Because there are more ONU’s than OLT’s the goalis to let the OLT do all the calculation so the ONU’s can be as simple (andcheap) as possible.

3.1.2 Requirements

The logical design of the protocol should be support up to 32 ONU’s. Themaximum distance between an ONU and the OLT is 5000 m.

When the quality of a channel is determined the next step is to calculatehow many bits per symbol this channel can handle. The better quality ofthe channel the more bits per symbol can be used, and the more bits persymbol the more bandwidth the channel has. However, there is a maxi-mum number of bits, this is 8. There is no limit on the amount of channelsper ONU.

3.1.3 Environment

Connections to the “environment” to the upper layer are done via a MACinterface, the service will accept Ethernet frames and transmit these fromthe OLT to the designated ONU or from an ONU to the OLT. The inter-face to the layer below consists of 128 offband data channels and one base-band control channel. It is a point-to-multipoint topology, meaning theOLT broadcasts to all the ONU’s and the ONU’s have to determine if thedata is meant for them, the ONUs can only send to the OLT.

3.1.4 Assumptions

The service does not guarantee that the data is transferred error-free or thatthe frames arrives at all. It does guarantee the data order is not shuffled.

The OLT and all the ONU’s have a unique MAC address.

3.1.5 Lower Level Service

The lower level service consists of 129 channels. These channels have avarying capacity or even no capacity at all, except for the first channel. Thischannel is used for signaling and is defined as a 100 MBit/s channel. Alsoerrorless transfer is not guaranteed.

3.2. Protocol Design 15

The data channels are of varying quality, however during a time pe-riod of 100ms the quality is constant. During that time, called an epoch, thecapacity is constant.

3.2 Protocol Design

3.2.1 Design Paradigm

Applying the master/slave paradigm has several advantages over othertechniques such as carrier sensing algorithms in for example an Ethernet.The OLT is the master and ONUs only send messages in response to to OLTmessages.

As stated before in section 2.6 the network layout is point to multi-point. This makes using a carrier sensing protocol such as CSMA/CD (seeIEE802.3 [2]) unusable since ONU’s cannot communicate directly with eachother.

d i s c o v e r y p h a s e a s s i g n m e n t p h a s e

! Figure 3.2: Abstract state diagram

3.2.2 Informal Description

The protocol can be divided into two parts, one part for handling the chan-nel assignments and one part for handling tasks such as network setup andjoin/leave procedures. The relationship between the OLT and the ONU’sis master/slave, the OLT is the master and the ONU’s act as slaves.

The control channel will be used to transfer information between theONU’s and the OLT about the quality of each data channel at each ONU.This information will be received by the OLT from each ONU and performsome form of calculation to assign each channel to an ONU. When this isdone these channel assignments will be broadcasted to the ONU’s and canbe used to transfer data, after the epoch ends the whole procedure repeatsitself.

Network setup is done by the OLT, it will broadcast a discovery win-dow for the ONU’s to send a request to register. When the window closes


the OLT will process each request and register the ONU’s who respondedin the discovery window.

Figure 3.2 shows an abstract state diagram, the protocol starts in thediscovery phase and then continues to the assignment phase. When theassignment phase ends a choice has to be made, the protocol can con-tinue the assign phase or enter the discovery phase to look for new ONUs.For instance a new discovery phase could be started every ten assignmentphases.

Identification The ONU’s are uniquely identified by their MAC addresses,these are 6 bytes long. Because there is a maximum of 32 ONU’s in the net-work 6 bytes is overkill for addressing purposes, therefore the OLT assignsa 1 byte long Logical Link Identification to a registered ONU. The use of aLLID is presented in the IEEE MPCP standard [2].

Authentication During the registration process the OLT checks if the MACaddress is allowed to use the network. If this is not the case the ONU willnot receive a LLID but will be notified it cannot be registered. The LogicalLink Identification (LLID) is outlined in section 3.2.6 on page 21.

3.2.3 Internal Structure

ONU1

ONU1

ONUn

ONUn

OLT

OLT

protocolprotocolprotocolentityentityentity

Lower Level Service

! Figure 3.3: internal view of the protocol

Figure 3.1 on page 13 shows the service as a “black box”. Internallythe protocol operates on top of the Lower Level Service Provider (based


on the optical fiber). The connection between two services is called a SAP,represented in the figure as an ellipse. Obviously, for two services to interoperate correctly these SAP’s will have to be clearly defined. Two differenttypes of Protocol Entities can be identified, one for the ONU’s and one forthe OLT, figure 3.3 shows how they operate within the service operatingbetween the environment and the LLS. Both entity types consist of twoprocesses which are run parallel.

One for processing the user data and one for sending/receiving controlinformation. The process for the user data is a rather simple one, it acceptsdata from the upper layer and puts this data on designated channels, oraccepts data from the channels and sends this to the upper layer.

The other process handles procedures such as the discovery, register,leave procedure and for each epoch communicate which channels are usedby the OLT and ONU’s.

Figure 3.4 shows how both the processes communicate with each otherand with the SAP’s. The two rounded boxes represent the two processesrun in parallel. The control channel communicates with the lower layerthrough one channel (the 100 MBit/s control channel) and notifies the in-terface process which channels must be used for data traffic. The interfacechannel communicates with the upper layer through one channel, usingit to send and receive data packets from the upper layer. With the lowerlayer the interface process has 128 channels to use, the information aboutwhich channels it can use is fed to the interface process by the control pro-cess. Since the protocol is not symmetrical but a master/slave paradigmthe processes in the OLT and the ONU’s are not similar, but the way theycommunicate with each other is the same. So, figure 3.4 is the same for boththe entities however the processes operate differently, this is elaborated insection 3.3.4 on page 33.

3.2.4 Discovery Phase

This section will informally outline the messages sent by the OLT and theONU’s for the discovery phase. Figure 3.5 shows the message sequencewhen two ONU’s want to register, this section will explain this picturestep by step. The OLT will send a DISCOVERY GATE message to informthe ONU’s they can send their REGISTER RESPONSE. After a random delaynew ONUs will send their REGISTER RESPONSE.

This is done randomly to avoid collisions, however when a large num-ber of ONUs try to register collisions are inevitable. The distribution of therandom delays is uniform, this way the spread of the REGISTER RESPONSE

messages is even along the total length of the discovery window. If, forinstance, an Poisson distribution is used, a large amount of responses willoccur near the average causing collisions, the uniform distribution is themost applicable for this particular operation.


C o n t r o l I n t e r f a c e

! Figure 3.4: Protocol Entity in detail

D G

R R 1

R R 1

R R 2

R R 2

D G

D G

d i s c o v e r y w i n d o w T 1 T 2

R 1

txr x

t xr x

t xr x R 1

A 1

A 1R 2

R 2

A 2

A 2

DG d i scove ry ga teR R 1 , R R 2 r e g i s t e r r e s p o n s eR1 ,R2 r eg i s te rA 1 , A 2 r e g i s t e r a c k n o w l e d g e m e n tT1 , T2 de lays

O L T

O N U 1

O N U 2

! Figure 3.5: Discovery phase with two ONUs


Since the discovery window is contention-based responses from theONU’s may collide. After some time a timeout will occur at the OLT andthe discovery gate will close, the OLT will no longer accept register re-sponses. The ONUs cannot sense it if their response arrives at the OLT,they have to wait for a REGISTER message from the OLT. An ONU will waitfor this message a certain time, after a certain timeout the ONU assumessomething has gone wrong and starts the discovery phase from the the be-ginning, it will wait for the next discovery window.

Backoff The ONU can also choose to wait for a certain amount of dis-covery windows before it replies again, the parameter associated with thisbehaviour is called the backoff parameter. If, for instance, the backoff param-eter is set to two, the ONU will reply either the next discovery window,the window after that or the window after that. To which discovery win-dow the ONU reply is decided by a uniformly distributed random numberbetween zero and the backoff parameter. Again, an uniform distributionis used to spread the REGISTER RESPONSE messages evenly over the nextdiscovery windows. If the backoff parameter is set to zero the ONU willalways respond to a discovery window.

This backoff works different than the backoff procedure in Ethernet.Ethernet is a collision sensing medium so it immidiately stops sendingwhen a collision occurs. After that it waits for a certain random time periodand tries to send the data again. The PON does not provide any collisiondetection, the ONUs will have to wait after the discovery window is closedand wait for a response to know if its response was succesful. Ergo, theONU can only send one REGISTER RESPONSE each discovery window.

Basically a REGISTER RESPONSE from a ONU is subject to two randomvalues, the first being the time in the discovery window it is sent, the sec-ond one being the discovery window in which it is sent (if the first attemptwas unsuccesful). The two factors of randomness should provide adequatemeans for spreading the response messages from the ONUs on the discov-ery windows. Concrete values are tested and compared in the next chapterof this thesis.

When the OLT closes its discovery window it will have a list of ONU’swho want to register. Each entry will be processed by the OLT, it will send aREGISTER message to the corresponding ONU. On its turn the ONU will re-ply with an REGISTER ACK message. When the OLT receives this acknowl-edgment the ONU is registered and the OLT proceeds with the next ONUor, if there are no more ONU’s continues with the next phase of the proto-col. Figure 3.5 shows the process with two ONUs. Each ONU is processedindividually, schemes exists which interleave the registering process, theseare for when inband signalling is used. The PON presented here has itsown control channel, with offband signalling, therefore these optimizations


hardly affect performance but do increase the complexity of the operationand are not used in the design.The messages used during the discovery phase are:

discovery gate This message does not contain any information, it is a markerbroadcasted by the OLT so the unregistered ONU know they can reg-ister.

register response This is the response from an unregistered ONU, it con-tains its own MAC address.

register After the OLT received a response from a ONU and the discov-ery window is closed the OLT will send this message to a ONU whowants to register, it contains its MAC address and the newly assignedLLID(see section 3.2.6). It also contains a timestamp used for rangingpurposes(see section 3.2.7).

register ack This is the reply to the register from the OLT, the ONU copiesthe content and sends it back to the OLT. The ONU is registered andthe OLT knows it is been done correctly.

S R

R 1

R 1

R 2

R 2

S R

S Rtxr x

t xr x

t xr x

W T T 1 T 2

A

A

A

O L T

O N U 1

O N U 2

S R S N R r e q u e s tR 1 , R 2 S N R r e s p o n s eA a s s i g n m e n tC T p r o c e s s t i m eG T g u a r d t i m e

C TG T

! Figure 3.6: Assignment phase with two ONUs

3.2.5 Assignment Phase

This section will informally outline the messages sent by the OLT and theONU’s for the assignment phase. The OLT will broadcast a SNR REQUEST


to the ONU’s, this message informs the ONU’s when they can reply sono collisions occur. In its designated time slot the ONU will reply witha RESPONSE containing information about the quality of the 128 channels.When the OLT has received all the responses it calculates which channelsare assigned to which ONU’s. When these calculation are done it broad-casts an ASSIGNMENT message to the ONU’s so they know on which chan-nels they can receive and broadcast. This message (with the assignmentdata for all the ONUs) is a broadcast message to all the registered ONUs.Each ONU will have to look for its individual assignment data.

After 100ms the epoch ends and the whole procedure starts again. Fig-ure 3.5 shows the process with two ONUs for one epoch. Between the twoSNR responses a guard time is needed, for details on guardtime see sec-tion 3.2.7 on page 22. When all the SNR responses are received, the OLTwill have to perform calculations to determine the assignment, the timethis takes is related the computing power of the OLT.

The messages used during the assignment phase are:

snr request This is a broadcast messages to all the ONU’s from the OLT. Itcontains information about which ONU’s should reply, in what orderand at what time.

snr response this is a reply from a registered ONU to the request messagefrom the OLT. It contain snr values for all the channels for both theup and downlink.

assignment After the OLT received all the responses it calculates whichONU’s can use which channels and broadcasts this information inone message.

3.2.6 Addressing Scheme

To make sure the OLT and ONU’s can identify themselves and deliver mes-sages to the place they want to an addressing scheme is needed. Two dif-ferent approaches are possible, the first one is to use the MAC addresses ofthe ONU’s, the second one is to let the OLT distribute addresses to the OLT.Using a six byte MAC address is somehow a overkill since the protocol onlyneeds to support 32 ONU’s. Instead of a MAC address an identifier onlyused locally can be used, this address is only used between the OLT andthe ONU’s, at the so called link layer. The address is called a Logical LinkID (LLID) and is one byte large, it is part of the multipoint control protocolin the IEEE standard [2]. Assigning a LLID to an ONU adds complexityto protocol, but this added complexity is quite small. At the OLT a list ofLLIDs will have to be maintained and each ONU will have to save its LLID.During registry process no extra message are needed, in the REGISTER mes-sage an extra LLID-field can be added and in the REGISTER ACKNOWLEDG-


MENT message this field can also be added to inform the OLT that the ONUis using the correct LLID.

The added complexity to reduce the information which needs to betransferred is not very much, but reduces the address field which is usedin every message header on the control channel by six times. Also, thereduced address size might positively speed up processing times at theONU’s and OLT.

special LLID values In the header the address field stores the LLID ofthe ONU for whom the message is ment(for a detailed description of theheader see section 3.3.2). However, in some occasions the OLT sends amessage which is ment for all the ONU’s, for instance the assignment mes-sage which informs the ONUs about the channels they have to use for thenext epoch, is a broadcast. The value used for this is 255.

The second special value is needed during the discovery process – moreprecisely, during the registering process. When a ONU wants to register itsends it MAC address to the OLT, the OLT assigns a LLID to this particularONU. Only, when the MAC address is not authenticated the OLT will notassign a LLID to the ONU but it will reply with an LLID value of 254. Nowthe ONU knows the OLT will not register the ONU and inform the userabout this(see section 3.2.2).

One LLID vs. multiple LLID’s per ONU More than one LLID per ONUcan be used when multiple users are connected to one ONU or for Qualityof Service (QoS) purposes. Having multiple llids per ONU greatly affectsthe stable matching algorithm, and is not a part of this thesis.

3.2.7 Ranging and timing

Since the distance between an ONU and the OLT is different for every ONUa TDMA scheme will cause collisions because of varying propagation de-lays. To neutralize this effect ranging is necessary. This is a process offinding the delay of each ONU and adjust their transmission slot timing sono collisions will occur at the OLT [18].

In the protocol this can be implemented during the discovery process ofan ONU. When the OLT sends a REGISTER message to a ONU it includes atimestamp. The ONU copies this timestamp and returns it to the OLT witha REGISTER ACKNOWLEDGEMENT. The result of subtracting the currenttime with the timestamp is the Round Trip Time (RTT). Also calculationtime has to be taken into account. The most convenient way is if this calcu-lation time is a constant, this is most likely if it is done at hardware level.When the calculation is done in software the calculation time is most likelyto be unpredictable. This variable time can be included in the calculation,


g u a r d t i m e p r e a m b l e d e l i m i t e r

t i m e

u p s t r e a m T D M A o v e r h e a db u r s t t r a n s m i s s i o n f r o m O N U

! Figure 3.7: upstream TDMA overhead

a simpler solution is to set it to a constant (for instance the maximum timethe calculation could take). This simplifies the calculation and makes it lesssystem-dependent, so the calculation time will be set to a constant. Whenthe calculation is done faster than the constant the system waits until theconstant calculation time is reached.

Fine tuning Due to some random processes in electronic equipment, tem-perature variances and due to the distributed nature of PON, packets arriv-ing wto the OLT will always have a relative jitter. To avoid collisions twothings will be done, between the packets a space the size of a couple of bitsshould be placed. This space is called guard time and is typically from 16 to64 bits long [18]. Also systematic shifts may occur, for example by temper-ature change of the environment. In this case the OLT should dynamicallyadjust the ONU’s delay. So when a ONUs delay is changing and its packetarrives too early or too late, the next time it request a snr response from thisONU the OLT will change the delay a little bit.

TDMA overhead In addition to the previously mentioned guard bandtwo other parts are placed between the messages. This is necessary be-cause the receiver is a burst mode receiver and it is required to adapt to theamplitude and timing differences of sequential bursts [19]. Section 2.2.2 onpage 5 outlines the burst mode receiver in more detail. This is also doneduring discovery. See figure 3.7 for the placement of the three parts.

• The guardtime is not only used to compensate for the jitter but it alsoallows the BMR to be reset for the next burst.

• The preamble which is a fixed bit pattern prepending to each bursttransmitted by the ONU. The OLT can use this to adapt to the powerof the signal and the bit phasing of the burst.


T 2

T 1

W T 2

T 1

T 2

O L T t i m e

O N U 1 t i m e

O N U 2 t i m e

S R

R 1

R 1

R 2

R 2

S R

S R

txr x

t xr x

t xr x

w a i t i n g t i m e t i m e s l o t 1 t i m e s l o t 2

W T 1

S R S N R r e q u e s tR 1 , R 2 S N R r e s p o n s e

G T

! Figure 3.8: Timing

• The delimiter which is a unique bit pattern that identifies the begin-ning of the burst payload.

3.2.8 Timing

When the OLT sends the SNR REQUEST to the ONU’s the message will ar-rive at each ONU at a different time because of the propagation delay. Tocompensate for this delay the ONU should substract its RTT from the timeof the moment it wants to reply to the request. see figure 3.8 for the syn-chronization for one OLT and two ONU’s. The waiting time is the timethe OLT is waiting for a response, the lower bound of the waiting time isthe RTT of the first ONU. However, there is no need to time the requestmessage and the first response as tightly as possible. The design allowsto send the requests in advance, this eliminates concerns about RTT dif-ferences between the ONUs. For instance, when two ONUs have to replyafter each other, there could be a problem when the first ONU is very closeand the second ONU is very far. The first ONU could reply before thesecond ONU received the request, this way gaps will occur between SNRresponses. Sending the request sufficiently in advance will avoid this prob-lem.


3.2.9 LLID order

At the beginning of an epoch when the OLT wants to assign the channels tothe ONU’s it will broadcast a request to the ONU’s. If the ONU’s all imme-diately reply to this request many replies will collide and get corrupted. Toavoid this happening the replies will have to be scheduled in some kind oforder. The OLT will put this order in the request so the ONU’s know whenthey have to reply. Because the ONU’s are at different distances from theOLT the order in which they have to reply affects the duration of the wholeprocedure. Only when all the ONU’s have replied the OLT can make thecalculation and send a message to the ONU’s with the channels they areassigned for the epoch.

The list can be of a fixed size or of a dynamic size. With a fixed size,the duration of the assignment phase will be the same for all epoch, inde-pendent of the amount of ONU’s registered and their distance to the OLT.The advantage is the design can be simpler but this is at the cost of somecapacity. With a dynamic size the goal is to do it as quickly as possible sothe increased complexity is worth the effort over the fixed approach.

The timeslots should have no gaps between them, except for the guard-time. When the request is broadcasted in advance (longer than the maxi-mum RTT) no problems will occur because the message arrives too late atthe most distant ONU’s.

3.2.10 Measuring

For the distribution of the subcarriers among the ONUs, in the assignmentphase, the quality of the subcarrier will have to be measured, this is doneby analysing the signal data on the subcarriers at the reception. So, at theOLT all the 128 channels for each ONU will have to be measured (uplink)and at the ONU all the 128 channels from the OLT will have to be measured(downlink).

downlink By design all the subcarriers are used, and the network is point-to-multipoint so at each ONU all the subcarriers are received, even the sub-carriers which are meant for other ONUs. The ONU will simple have to domeasurements of the data it receives on each subcarrier, not only the sub-carriers assigned to it but all the 128 subcarriers, to calculate the SNR valuefor each particular subcarrier. If the ONU is the first ONU to register andthere is no actual data being sent, the ONU cannot do measurements on thedata, in this case the OLT should send dummy data so the ONUs can dotheir measurements.

uplink At the OLT the procedure is a little bit more complicated, sinceeach subcarrier is only used by one ONU it cannot determine the SNR value

26C

hap

ter3.

Pro

toco

lDesig

n

O L T t i m e c o n t r o l

O N U 1 t i m e c o n t r o l c h a n n e l

O N U 2 t i m e c o n t r o l c h a n n e l

S R

R 1

R 1

R 2

R 2

S R

S Rtxr x

t xr x

t xr x

W T T 1 T 2

A

A

A

s u b c a r r i e r 1

s u b c a r r i e r 2s u b c a r r i e r 3




e p o c h n






e p o c h n + 1

M

M O N U 1 u p l i n k s u b c a r r i e r s

O N U 2 u p l i n k s u b c a r r i e r s

O L T u p l i n k s u b c a r r i e r sM M

W 1

M P n + 1

M

M

M

M

e p o c h n - 1 M e a s u r e m e n t P h a s e n

M 1

M 2

O L T d o w n l i n k s u b c a r r i e r s

O N U 1 d o w n l i n k s u b c a r r i e r s

O N U 2 d o w n l i n k s u b c a r r i e r s



e p o c h n



e p o c h n + 1

s u b c a r r i e r 1 s u b c a r r i e r 1




e p o c h n - 1

G T

!F

igu

re3.9:

two

ON

Us

and

three

sub

carriers.


for a subcarrier assigned to another ONU. Measuring the data as with thedownlink would only provide measurements for one particular ONU andnot for all the ONUs. To cope with this an additional measurement phaseis necessary, between the epochs each ONU will have a very short periodto send on all subcarriers, solely for the purpose of measuring. When allONUs sequentially have broadcasted on all subcarriers the OLT knows theSNR value for each subcarrier for each ONU.

Figure 3.9 at page 26 shows how two ONUs use three subcarriers. Theepoch starts when the OLT sends a snr request (SR), each ONU replies witha response with the SNR values of their downlink (R1 and R2), at the sametime they broadcast on all the subcarriers. The OLT receives these broad-casts and calculates the SNR value of each uplink subcarrier for each ONU.At the same time it receives the SNR responses of the downlink from theONUs. With the uplink values the uplink channel distribution is deter-mined and the downlink values are used for the downlink distribution.The ONUs are informed and the next epoch starts.

Since each ONU sends on all the subcarriers a TDMA scheme is usedto avoid collisions. The uplink measurements are done each ONU afteranother ONU, the predetermined delay is used to pack the measurementsas closely together as possible (see figure 3.9). This is done because thetime between the measurement and the time the next epoch starts shouldbe as short as possible. It is undesirable that the delay is so long the datafrom the measurement is already to old to be used (since the characteristicschange very quickly). The duration of a measurement block is the sameas the SNR response message (21 microsecond). With the symbol durationof 100 nanosecond a total of 210 symbols can be sent in this block. Thedetails of these measurement blocks are more of an hardware issue and notcovered in this thesis.

There is a standard delay between the measurements and the start of thenext epoch, this is because of the assignment message which has to be sentfrom the OLT to the ONUs. Also the calculation time should be taken intoaccount. Depending on the order of the ONU in the TDMA scheme the totaldelay is the standard delay plus the extra delay because of the location inthe sequence of measurements. In figure 3.9 ONU1 is the first to measure,the total delay(M1 in the figure) between this measurement and the nextepoch is the standard delay plus the delay of one measurement. ONU2 hasa shorter delay between the measurement and the next epoch because it thelast to measure. The maximum time between a measurement of an ONUand the next epoch is the standard delay plus 31 times the duration of ameasurement.

The consequence of doing the uplink measurements is that for a shorttime the subcarriers cannot be used for data. This has an impact for totalthroughput and delay. The total duration of the measuring cycle is themessage length of an SNR response times the total amount of ONUs plus


the length of the assignment message plus the RTT of the farthest ONU.This can be explained reasoning backward from the start of the next epoch.

• Epochs are synchronized at the OLT so the farthest ONU will have tostart the next epoch first.

• The length of the assignment message.

• The propagation delay of the assignment message to the farthest ONU.

• The length of the measurement blocks multiplied by the amount ofONUs.

This results in the following formula for the duration of the measure-ment phase:

duration = RTTfarthestONU + lengthassignmentmessage

+lengthmeasurementblock ! ONUamount

Table 3.2 shows the values corresponding to the variables mentioned in theformula. The length of the assignment message is 42 microseconds and thelength of one measurementblock is equal to one SNR response whos lengthis 23 microseconds. The minimal outcome, with one ONU very close to theOLT, is 0 + 42 + 23 ! 1 = 65µs. The RTT of the farthest ONU is 50 mi-croseconds, see 2.2.1 on page 4. The maximum outcome, with thirty-twoONUs and very far from the OLT, is 50 + 42 + 23 ! 32 = 828µs. So thelower/upperbound of the measurement phase is 65µs/828µs. The conse-quence to the total throughput, with a 100 ms epoch, is a decrease of min-imally 0.065 percent and maximally 0.828 percent, incurring no significantdecrease of capacity.

3.2.11 Transmission Errors

When there is an error at the data channel the protocol does not notice this,the upperlayers will cope with the error. At the control channel this is anissue for the protocol.

During the discovery phase when a message is corrupted the ONU willnot be registered, it will have to wait for the next discovery window. It canwait for this because the discovery window appears frequently. Startuptime for these kinds of network take quite long, for instance an ADSL mo-dem takes minutes before it is connected to the Internet.

During the assignment phase whenever the OLT does not receive theresponse from the ONU that it expects, the ONU will not participate inthe next epoch. When this happens too often the ONU is considered to beoffline and will be required to re-register.

3.3. Protocol Specification 29

3.2.12 Security Issues

EPON serves non-cooperative, private users, but on the other hand, has abroadcasting downstream channel, potentially available to any interestedparty capable of operating an end station in promiscuous mode [4]. Ourmultimode network is also aimed at non-cooperative private users but alsoat professional users. The openness of the system creates vulnerabilitiessuch as eavesdropping, theft-of-service and other abuse. These issues areconsidered out of scope for the moment, but of course these problems willhave to be addressed in the future. Encryption and authentication schemeswill have to be developed/implemented.

3.3 Protocol Specification

The previous section described what the protocol should do, how it com-municates with the lower protocol layer and what the upper protocol layercan expect. However this is still very ambiguous and open for interpreta-tion. This section will form the design into a more formal one.

3.3.1 SAP

Upper Layer For the downlink it it accepts packets from the upper layertransfer these to the desired MAC address. In the uplink the protocol en-tity will provide the upper layer with packets send to its MAC address.The SAP is designed to operate as a simple packet throughput point, likea regular ethernet interface, it does not guarantee that the packet will bedelivered or that it is free of errors, is does guarantee the packets arrive inorder.

Lower Layer For each entity the lower level appears as one basebandchannel and 128 offband subcarrier channels. The control channel has aconstant bit rate of 100MBit/s. All the channels are full duplex, includingthe baseband channel, and do not guarantee that the packet will be deliv-ered or is error free, it does guarantee the packets arrive in order.

! Figure 3.10: Message headeraddress (8 bits) type (8 bits)

length (16 bits)content

FCS (8 bits)


! Table 3.1: Message type values

message type value

discovery gate 0register response 1

register 2register acknowledgement 3

SNR request 4SNR response 5

assignment 6

3.3.2 Message Header

The messages mentioned in section 3.2.4 on page 17 and section 3.2.5 onpage 20 will all have a similar header with a address, the message type, thelength of the message and a CRC field, see figure 3.10.

Address The point-to-multipoint architecture does not require the con-ventional two fields for source and destination, for addressing purposesonly one field is needed. Because of the point-to-multipoint network lay-out the ONU’s can only receive messages from the OLT and the ONU’s canonly send to the OLT. So, in both directions one address is always known,for messages from the ONU’s the destination is always known and for mes-sages from the OLT the source is always known. In other words, the mes-sage header only contains the address of the ONU.

Type To distinguish between the different types of messages a field is re-quired. When assigning a unique number for each type this field can bevery small since only a couple different types are used. Table 3.1 shows allthe message types and the corresponding values.

Length The length of the content in bytes. With a 16 bit integer the max-imum size of the content can be 65536 bytes which is sufficient. At maxi-mum size all the content messages stay below this number.

FCS The Frame Checksum Sequence (FCS) is necessary to insure the in-tegrity of the whole message. For this a Cyclic Redundancy Check is used.This is only used on the control channel.

Content The content field is of variable size and has a different format foreach message type. The next section explains the details of the content ofeach message type.


3.3.3 Message Content

This section specifies the content of the different messages.

header

empty(a) Dis-coveryGate

header

MAC address 6 bytes(b) Register Request

header

MAC address 6 bytesLLID 1 byte

timestamp 4 bytes(c) Register

header

MAC address 6 bytesLLID 1 byte

timestamp 4 bytes(d) Register acknowledgment

! Figure 3.11: Messages types during discovery.

Discovery gate The discovery gate does not need any extra information,it is a signal for unregistered ONU’s to reply with a REGISTER REQUEST,therefore the content is empty. The duration of the discovery gate is a sys-tem parameter and is not part of this message. For completeness the graph-ical representation is shown in figure 3.11(a).

Register Request This message is sent by the ONU to the OLT when itwant to register. It contains a field with it’s MAC address. It is assumed thatthis address is unique. A MAC address is 6 bytes long. See figure 3.11(b).

Register The message is sent by the OLT to a ONU in response to thepreviously mention REGISTER REQUEST message. It contains the MAC ofthe ONU and the newly assigned LLID. For ranging purposes a timestampis also added. See figure 3.11(c).

Register Acknowledgment This is a reply of the ONU to the REGISTER

message from the OLT. It contains both the MAC and LLID to confirm tothe OLT a connection is made and the ONU will use this LLID. See fig-ure 3.11(d).

SNR request This is the message sent by the OLT to the ONU before anepoch starts. It contains a list of LLID’s and their delay. Their position inthe list determines their time slot, this insures the return messages do notcollide. Because the ONU’s have different distances to the OLT a delay fieldis added(the value is calculated during the discovery process). The size of


header

ONU count 8 bits

1LLID 8 bitsdelay 16 bits

2LLID 8 bitsdelay 16 bits

...n

LLID 8 bitsdelay 16 bits

! Figure 3.12: SNR request message

header

queue size 4 bytes

SNR value (channel 1) 2 bytes

SNR value (channel 2) 2 bytes...

SNR value (channel 128) 2 bytes

! Figure 3.13: SNR response message

the field is two bytes, the unit is microsecond, the longest RTT is 50µs. Thelast timeslot is the 32 and the duration of one timeslot is 22µs. The biggestvalue in this field would be 50 + 22 ! 32 = 754, so 2 bytes are needed forthis value.

See figure 3.12 for a graphical representation. With these two values theONUs know exactly at what time they have to reply with a SNR RESPONSE

to make the replies arrive at the OLT at the correct time.

SNR response In reply to the previously mentioned SNR REQUEST theONU replies with a SNR response, this message is list of SNR values mea-sured at the ONU. The queue size at the ONU is also included in the mes-sage, the OLT uses this information to assign more bandwidth to ONUswith more traffic.

After the OLT receives all the SNR responses from the registered ONU’sit sends the ASSIGNMENT message. See figure 3.13.

Assignment This message needs to carry information about which chan-nel is assigned to which ONU. There are two ways of constructing this list,one from the perspective of the channels and one from the perspective ofthe ONU’s.


format one The starting point for this message format is a list of channels.Each channel will have the LLID of an ONU and the numbers of bitsloaded on this channel. This is done for both the uplink and down-link, see figure 3.14(b). With 32 ONU’s 5 bits are sufficient to identifythe ONU, the smallest value which can be used is a byte. The max-imum number of bits per channel is 8 so a byte is used to store this.For both up and down link there are 128 channels. We will use 8 bitsfor ONU LLID and 8 bits to store the number of bits per channel. Themessage will be a list with the size of 512 bytes(2 " 128 " 2).

format two This format can basically been seen as a list of ONU’s and foreach ONU a list of channels is given. The message will start with avalue to store the count of ONU entries (1 byte). Each ONU entry willneed a count for the number of channels is has been assigned (for bothuplink and downlink). Since there are 128 channels 7 bits are neededto identify the channel, for simpler implementation 8 bits are used soit is possible to use standard byte fields. Theoretically all the channelscan be used by one ONU so the channel count field should be able tohold up to a number of 128 (7 bits) but again for implementation ease8 bits are used. Thus, each channel needs 1 byte and per ONU 1 byteis needed to identify the ONU plus two bytes for the channel countfor up and down link of each ONU. See figure 3.14(a) With 1 ONU themessage will have a size of 516 bytes(1+ 1! 3 + 128! 2! 2). With 32ONU the message will have a size of 609 bytes(1+32!3+128!2!2).Depending on the amount of ONU’s active the total size will varybetween 516 bytes (one ONU) and 609 bytes (32 ONU’s).

The first format is always smaller than the second format, dependingon the amount of ONUs, however at 100Mbits a couple of bytes are not anissue. The message size is constant, which relaxes timing issues (since theduration of the message is constant). Format two is a more complex formatwith no actual benefits so format one will be used.

3.3.4 Finite State Machine

The two Protocol Entity types both have two processes, see figure 3.4 onpage 18. The processes labeled “interface” in the two processes communi-cate with each, the same applies to the processes labeled “control”.

The state machine for the interface processes is quite simple, it acceptsdata from the upper or lower layer and transmits this. It receives controlinformation from the control-process so it knows which channels to use.With the knowledge of which channels to use it can inverse multiplex andinverse demultiplex between the lower and upper layer.


headerONU count 8 bits

ON

U1

LLID 8 bits

up

channel count 8 bitschannel 8 bits * n

bits loaded 8 bits * n

dow

n channel count 8 bitschannel 8 bits * n


ON

U2

LLID 8 bits

up



dow


bits loaded 8 bits * n...

ON

Un

LLID 8 bits

up



dow


bits loaded 8 bits * n(a) Assignment message (format 1)

header

upl

ink

1onu llid 8 bits

bits loaded 8 bits

2onu llid 8 bits

bits loaded 8 bits...

128onu llid 8 bits

bits loaded 8 bits

dow

nli

nk

1onu llid 8 bits

bits loaded 8 bits

2onu llid 8 bits

bits loaded 8 bits...

128onu llid 8 bits

bits loaded 8 bits(b) Assignment message (format 2)

! Figure 3.14: Two formats for the assignment message


! Figure 3.15: State diagram of the assignment phase of the OLT

OLT The OLT starts with the assignment phase. The control process at theOLT starts with a broadcast to all the ONU’s and then wait for an timeoutto close the window. After this window it has a list of ONU’s who wantto register. The OLT then starts processing each ONU, it sends a REGISTER

message to the ONU and then waits for an acknowledgment or timeout. Ifa timeout occurs the register process fails so the ONU is not registered andthe OLT continues with the next ONU.

When the OLT is done with this phase it broadcasts a request to all theONU’s. This message also contains information for the ONU about theirtime slot. When it has received all the responses from the ONU it calcu-lates the channel assignments and broadcast a table to the ONU’s. Afterthis transmission the OLT will start with the discovery process again tocheck if there are new ONU’s in the system. This can easily be done duringtransmission since an epoch is 100ms. See figure 3.15 for the diagram.

ONU When the ONU is powered on it starts waiting for a discovery win-dow message. After receiving this it replies with a register request. The


OLT replies with a register message. This message is acknowledged by theONU, at this point the ONU is registered and starts waiting for a request tosend its SNR values to the OLT. When the reply is sent, the ONU waits forthe assignment message from the OLT and sends a control message to the“interface” process. It will start listening for the next SNR request from theOLT and so on. See figure 3.16 for the diagram.

3.4 Dimensioning and Timing

3.4.1 Epoch length

Until now the length of the epoch was fixed at 100 ms, however there arereasons to change this value, a shorter epoch will adapt quicker to changingloads from ONU because the bandwidth is reassigned more frequently.

The upper bound is limited by the physical layer, when the epoch istoo long, the frequency response of the subcarriers will have changed toomuch resulting in bad performance, so the length of the epoch is set at 100ms.

The minimum duration of the time epoch is incurred by the controlprotocol. There are two scenarios, one with a discovery phase during theepoch and one without. When trying to make an epoch as short as possiblethe SNR request message will have to be send directly after the assignmentmessage. Then it will have to wait for the first SNR response (the minimumduration of the is the RTT of the first ONU in sequence. The duration ofthe amount of SNR responses(and the guard times between) is the nextwhich adds time to the epoch. The OLT calculates the next assignment andsends this to the ONUs. At the moment the assignment is sent when thenext epoch starts. The results in figure 3.17 on page 39 and the followingformula:

MIN(durationepoch) = lengthassignment + lengthsnrrequest + RTTfirstONU

+lengthsnrresponse ! ONUamount

+guardtime ! (ONUamount # 1)

+calculationtime

During this period the whole downlink can be used (see figure 3.9 on page 26).The uplink is somewhat different, because the uplink cannot be used fordata when the measurement block are being sent, therefore the uplink epochstops after the RTT of the first ONU. So, when the duration of the epoch isset to the minumum, all uplink bandwidth is used for measurements andno uplink data traffic is possible. The actual values of some variables area result of the hardware used so actual numbers cannot be inserted in theformula.

3.4. Dimensioning and Timing 37

! Table 3.2: control messages, size and duration

size (byte) duration (µs)

discovery gate 5 0.4register response 11 0.88register 16 1.28register acknowledgment 16 1.28snr request (min) 9 0.72

(max) 102 8.16snr response 265 21.20assignment 517 41.36

Discovery gate The discovery gate is the time between the moment theOLT sends the DISCOVERY GATE and the moment the OLT stops listeningfor REGISTER REQUEST messages from the ONU’s and starts processing thereceived REGISTER REQUESTS. The discovery procedure is only used by anONU when it is not connected to the OLT. And with a logical maximum of32 ONU’s it is very unlikely that a lot of ONU’s want to register during thesame discovery phase. Therefore the discovery gate can be quite small. Inthe next chapter simulations are performed concerning the duration of thediscovery window.

Message lengths Sections 3.3.2 and 3.3.3 outline the sizes of the messagesin bytes. The DISCOVERY GATE, REGISTER REQUEST, REGISTER, REGISTER

ACKNOWLEDGMENT, SNR RESPONSE messages have a constant size. TheSNR REQUEST and ASSIGNMENT messages have a variable size, dependingon the amount of ONU’s registered. In table 3.2 the (min) and (max) entrycorrespond to 1 respectively 32 ONU’s. 1 is the minimum amount of activeONU’s, a PON without an active ONU is quite useless. 32 is the logicalmaximum of ONU’s in the protocol design.


! Figure 3.16: State diagram of an ONU

3.4. Dimensioning and Timing 39

R 1

R 1

R 2

R 2

W T G T

A

A

A

A

A

AS R

S R

S R

C T

e p o c h n

! Figure 3.17: Minimal Duration of an Epoch

41

Chapter 4

Simulation

I N T E R F A C E

C O N T R O L

T X

R X

u s e r f i be r

! Figure 4.1: Internal Processes with Information and Packet streams

4.1 OPNET implementation

The model has been implemented in the OPNET [www.opnet.com] envi-ronment. OPNET is a discrete event simulator and provides an environ-ment for a broad range of network R&D fields. Modeling in OPNET isdone in an layered way.

The top layer contains nodes and links, the OLT, coupler and ONUsare nodes and are connected to each other by the links. The next level is thenode level, this zooms in on the internals of the OLT, coupler and ONUs. Inthe nodes there are transmitters and receivers, which are the entry and exitpoints for the links at the top layer. Streams are used to connect these mod-ules to other modules such as processes or queues. The previous chapteron design stated that there are two processes in the nodes, figure 4.1 showsthese processes and how the operate with the environment. The controlprocess handles the discovery and assignment process using the sharedcontrol channel. Every epoch it informs the interface process of how manybandwidth it may use for transmission (and reception) for the data. Theuser provides the interface with data. Data which is received from the

42 Chapter 4. Simulation

link is sent to the user. In the simulation the user will be modeled by atraffic generator for transmission, and a sink for the reception. The thirdlayer is that of the processes, OPNET expresses these process models in alanguage called Proto-C, which is specifically designed to support devel-opment of protocols and algorithms. It is based on the general facilitiesof the C or C++ programming language. The process models are definedas a set of states and conditions to move to another state, called transitions.Figure A.1(page 62) in Appendix A shows the state model for the controlprocess in an ONU, this corresponds to the design presented in the previ-ous chapter. The state diagram for the OLTs control process is shown infigure A.2 on page 63. These states are solely for the communication be-tween the OLT and the ONUs on the control channel. Operations such asthe measuring process at the uplink and downlink side are not a part of thestate diagram, they are done parallel to the states and do not affect transi-tions between states.

O L T

O N U 1

O N U 2

c h a n n e l 1

c h a n n e l 1

c h a n n e l 1

c h a n n e l 1 2 9

c h a n n e l 1 2 9

c h a n n e l 1 2 9

(a) 128+1 shared channels

O L T

O N U 1

O N U 2

d a t a c h a n n e l o n u 1

c o n t r o l c h a n n e l



d a t a c h a n n e l o n u 2

(b) 1 shared control channel and 1 individual data stream

! Figure 4.2: Design and Simulation implementation

The implementation is based on the design presented in the previouschapter, however one aspect had to be implemented different from the de-sign. The design states that the ONU gets an amount of data channels as-signed to it (two sets of channels, one for uplink and one for downlink).This is something which is not modeled in the implementation. In themodel each ONU has its own data stream, instead of the shared 128 + 1

4.2. Mean Values and confidence intervals 43

channels the ONU has only one stream for data and one for the control.The total amount of bandwidth from the channels assigned to the ONU issummed and the data stream is set to this bandwidth. The reason why thisis done is because in the protocol design the datastream meant for a certainONU has to be inverse multiplexed to the subcarriers. Probably some sortof serial to parallel converter (and visa-versa) will be used for this. How-ever this operation is performed at a lower layer — in the hardware. Sincethe protocol simulation does not require this much detail (and OPNET isnot well suited for this), this process is abstracted or actually bypassed. In-stead of the 128 shared subcarriers each ONU has only one stream to theOLT. In effect, the OLT has 32 streams, one to every ONU. Figure 4.2 il-lustrates the difference between the design and the implementation. Theresults from the simulation are not affected by this abstraction.

4.1.1 Traffic Generation

Two different types of traffic generation are used. The first one is a simplepacket generator, this source generates traffic at a constant rate. The secondone is OPNET’s Raw Packet Generator, this source generates traffic usingself-similar models based on fractal calculations [20].

4.2 Mean Values and confidence intervals

As mentioned in the previous chapter, the moment in which an ONU re-sponds in a discovery window is random, but also which discovery win-dow an ONU responds to (backoff). This kind of randomness is part of theprotocol and is different from random factors introduced by traffic gener-ation and the frequency response of the subcarriers. To substitute for thereal situation, models for traffic generation and a model for the frequencyresponse are used in the simulation. It is possible that the outcome of a sim-ulation does not comply with the expected outcome, this can be the resultof a particular set of random numbers. To overcome this problem, a set ofsimulations is run and the mean value of these simulations is used insteadof just one simulation result.

The simulations are executed to estimate the mean of variable X with(unknown) E[X] = a. Therefore a series of simulations is performed togenerate n samples xi, i = 1, · · · , n. Each of these can be seen as a realisa-tion of a stochastic variable Xi. To estimate E[X], a new stochastic variableX, which is called an estimator of X. Whenever E[X ] = a, the estimatorX is called unbiased. In this context unbiased means there is no systematicerror in the estimator.

Clearly it is very important that both unbiasedness and consistency aredesirable properties for the obtained estimate. For consistency the xi values


should be independent, which is not as straightforward as it seems. Thereare numerous ways to obtain almost independent observations from simu-lations, the method used in this thesis is the method of independent replicas.See [21] for other methods and more details on the theory of statistical eval-uation of simulation results. The simulation execution is replicated n times,each time with a different seed for the random number generator (RNG).A disadvantage is that the simulation will have to be started from startseveral times, which requires more computation time. The advantage ofthis method lies in the fact that the used samples are really independent,providing the RNGs deliver independent streams.

When the observations from the different simulations X1, · · · ,Xn areindependent then

X =1

n

n!

i=1

Xi

Confidence intervals Instead of estimating a parameter by one value (themean), a confidence interval provides a certain probability for that X liesin an certain interval. The more likely it is for the interval to contain theparameter, the wider the interval will be. Confidence intervals are used toindicate the reliability on an estimate.

Since the random variables Xi are assumed to be independent and iden-tically distributed, the estimator X as defined in the previous paragraphwill, according to the central limit theorem, approximately have a Normaldistribution with mean a and variance !2/n, this implies that the randomvariable

Z =X # a

!/$

n

is N(0, 1)-distributed [21]. By using a standard table for it (this table isprovided by [21]) a value z > 0 can be found such that Pr{|Z| % z} = ".

The mean a and sample variance !2 need to be calculated for N samplesof xi. The mean is given as:

a =1

N

N!

i=1

xi,

and the sample variance as:

!2 =1

N # 1

N!

i=1

(xi # a)2

Combining the formulas results in the following:

Pr{|Z| % z} = Pr" |X # a|

!/$

n% z

#

= Pr{|X # a| % z!$

n} = "

4.2. Mean Values and confidence intervals 45

Which states that probability that X lies in the so-called confidence interval[a#z!/

$n, a+z!/

$n] is ". Using the table from [21], with probability " = 0.95

and N = 15, z = 2.133 is obtained. When the simulations are performed,not only are the mean values calculated but also the confidence intervalsare calculated using these formulas.

Initial Transient Removal With most simulations the goal is to observe asteady state situation. However, when starting the simulation the modeledstate will generally be very non-typical, e.g. in queueing networks all thequeues may start empty. This is not a problem for the first simulation (in thenext chapter), since this simulation is designed to test the startup situationof the network.

With the second simulation this is an issue. In this particular network,in the initial state the ONUs are unregistered and need to register with theOLT before traffic can be sent, also the queues are not in a steady state. Thefirst guideline is to simulate so long that the effect of the initial transientperiod becomes negligible. Of course, this is not an efficient method, nordoes it provide any evidence that the simulation is run long enough.

A better but still simple guideline is the following, based on an estima-tion of the variance. Consider a sequence of n samples. The sample meanm is computed as (

$ni=1 xi)/n. Then, we split the n observations into k

groups or batches, such that k = [n/l]. We start with batch size l = 2 andincrease it stepwisely, thereby computing k accordingly, until the samplevariance starts to decrease, as follows. We compute the batch means as

mi =1

l

l!

j=1

x(i!1)l+j , i = 1, · · · , k,

and the sample variance as:

!2 =1

k # 1

k!

i=1

(mi # m)2.

By increasing the batch size l, more and more samples of the initial transientperiod will become part of the first batch. If l is small, many batches willcontain samples from the initial transient period, thus making !2 larger,also for increasing l. However, if l becomes so large that the first batch con-tains almost exclusively the samples that can be considered part of the ini-tial transient period, only m1 will significantly differ from m, thus making!2 smaller. The batch size l for which !2 starts to decrease monotonouslyequals the number of samples that should not be considered any further(paragraph from [21]).


4.3 Discovery Phase

An important matter to investigate is the functioning of the discovery phase.A worst case scenario will be presented to the discovery part of the proto-col. The logical maximum of 32 ONUs will try to register all at once, if theprotocol can handle this scenario a more standard scenario will not be aproblem.

4.3.1 Input

ONU distances Since the goal of this simulation is to create a worst casefor the startup situation all the ONUs will be located at the same distanceof 2000 meters. This creates a worst case because of the way the discoverywindow is designed. When an ONU receives a discovery message it willreply within a certain discovery window. The OLT waits for ONUs to replyafter it has sent the discovery message. It stops listening when the dis-covery window closes, this has the same duration as the ONUs discoverywindow plus the maximum round trip time. The latter is added to compensatefor the fact that there is a propagation delay before the discovery windowreaches an ONU. When the maximum RTT is added to the window, theOLT makes sure even in the extreme case (when an ONU far away decidesto reply in the end of the window) the replies are still accepted.

If the ONUs are at the same location their discovery windows at theOLT will overlap, when their distance to the OLT is different, their dis-covery windows do not (entirely) overlap and the chance of a collision issmaller, see figure 4.3. So, having al the ONUs at the same distance willresult in the highest chance of collisions, which is why this setup is used inthis worst case scenario.

Discovery window size Discovery window sizes of 1µs till 32µs are sim-ulated.

Backoff parameter Five different inputs for the backoff parameter aresimulated. The first is with no backoff, meaning an ONU with a failedregister attempt responds immediately when the next discovery windowoccurs. An backoff parameter of one means the ONU will respond eitherto the next discovery window or to the second next discovery window, thisis also done for a value of two, three and four.

Seed As mentioned in section 4.2 the seed values should be chosen insuch way that they are the resulting RNG streams do not overlap. Oursimulations are run with fifteen seeds, starting at 1001 with interval 1000(1001, 2001, . . . , 15001).

4.3. Discovery Phase 47

D G

D G

d i s c o v e r y w i n d o w

txr x

t xr x

t xr x

DG d i scove ry ga te

O L T

O N U 1

O N U 2


D G

o v e r l a p

(a) Small overlap / ONUs far apart

D G

D G


txr x

t xr x

t xr x

DG d i scove ry ga te

O L T

O N U 1

O N U 2


D G

o v e r l a p

(b) Large overlap / ONUs almost at same distance

! Figure 4.3: Overlapping discovery windows

4.3.2 Results

Figure 4.4 on page 48 shows the time an ONU has to wait before it is reg-istered when the system is turned on. The measurements have been donefor different discovery windows length and different values for the back-off parameters. The X-axis presents the discovery window length and theY-axis the amount of discovery windows one ONU needs before it is reg-istered. Different graphs are drawn for each backoff parameter, creatinga total of five graphs in the figure. The graph with backoff parameter setto “no” starts after an discovery window length of 5 microsecond, all theother graphs start at a discovery window length of 1 microsecond. The rea-son for this is that either the waiting time could not be computed (becauseevery register response collided) or the resulting value for the waiting timeis so excessively large that it would make the graph unreadable. For com-pleteness the values on which the graph is based are presented in table B.1on page 65.

The confidence intervals have also been calculated, for each mean pre-sented in table B.1 the confidence interval is shown in table B.2 on page 66.The mean of all the normalized confidence intervals is 0.1716, whichs mean


0

5

10

15

20

25

30

35

40

0 5 10 15 20 25 30 35

waitin

g tim

e pe

r ONU

[num

ber o

f disc

over

y wi

ndow

s]

discovery window length [microseconds]

backoff parameterno1234

! Figure 4.4: Number of discovery windows needed to register 32 ONUsfor different windows lengths per backoff parameter

that on average 95% of the values are between +17% and #17% for eachmean in table B.1.

Two observations can be made from the graph, the first will investigateand compare the different discovery window lengths, the second will lookinto the different backoff parameter settings and compare these.

With a very small length for the discovery window a lot of collisionoccur resulting in a high number of discovery windows needed for an ONUto register. The number of discovery windows needed drops quite steepuntil about a discovery window length of 10 microsecond. After that theincrease in discovery window does not have a big impact on the windowsneeded to register. This flattening of the slope is because of the relationbetween the duration of the discovery windows and the duration of therequest message. The relation between the length of the window and thelength of the discovery messages are a factor for the delay.

Consider the following example, for simplicity a slotted approach isused (see section 2.4 on page 8). If the duration of the window is 100µs andthe duration of a request is 10µs the chance of two messages colliding is 10percent. When the duration of the window is doubled to 200µs the chanceof the two messages collide is halved to 5 percents. If this is done againthe chance of a collision is 2.5 percent, and if continued to infinity there is 0

4.3. Discovery Phase 49

percent chance of collision. The bigger the difference between the durationof the discovery window and the request message the lesser impact is haswhen the discovery window duration is increased.

The size of a discovery request from an ONU is 0.88µs, see table 3.2 onpage 37 of the previous chapter. All the graphs approach the number ofone window required to register all ONUs, theoretically, if the window isinfinitely large, the requests from the ONU will never collide resulting inthe fact that all the registration attempts are successful in the first window.

Since there is no hard requirement for the time the system should beup and running the value for the discovery window can be chosen arbi-trarily. A discovery window length of ten microseconds results in an av-erage number of discovery windows needed to register value of about fivewindows. If the system does a discovery phase every epoch this wouldmean an startup time of roughly 0.5 seconds, if it is done every 10 epochs,a startup time of 5 seconds. Values which seem quite reasonable for a last-mile network.

Five graphs are drawn, one for each backoff parameter. When the dis-covery window is quite small (shorter than 10 microsecond), having a largerbackoff values results in a lower number of windows needed to register.This can quite easily be explained, when the window is small and thereare a lot of collisions, a large backoff parameter results in a spreading ofall the collided ONUs next attempt to register. If for instance, there is nobackoff and all the failed register attemps respond to the next window ahigh number of collisions will also occur in the following discovery win-dow and thus resulting in a low level of successful attempt. Because of themany collisions it will take a long time before all the ONUs are registeredsuccessfully. The longer the discovery window gets, the less improvementthe backoff brings. As the discovery window gets larger the amount of col-lisions drops, resulting in a low amount of collisions in the next window.The necessity for spreading the registration attempts becomes smaller thelarger the window get. When the window gets long enough having a back-off scheme causes the performance to drop. If there are very few collisionsspreading the next attempts over more windows is unnecessary, when allthe next attempts are done in the consecutive window, the change is failureis so small this becomes more efficient. For example, there is no need towait for five windows when there is only ONU left to register after the firstattempt. In this example, with no backoff after two windows all the ONUscan be registered instead of five windows when the backoff parameter isfive. The turning point for when having backoff becomes a drawback isaround a discovery window length of ten microsecond.

As previously mentioned, there is no requirement for the performanceof the discovery phase. If it is required the discovery window should bevery small, a large backoff parameter increases the performance. If the dis-covery window is quite lengthy (longer than ten microsecond) backoff is


not required and even decreases performance.

4.4 Intra-ONU Priority Scheduling

This simulation will investigate the performance of one ONU which is quiteheavily used (heavily used according to current standards). In our setupthree different services are defined; interactive voice and video, streamingvideo and normal internet traffic. An intra-ONU priority scheduling mech-anism is presented. The operation is quite simple, it will serve the queuewith the highest priority till exhaustion, if this queue is empty the nextqueue in line will be served till exhaustion, and so on. . . The simulation willbe executed with different traffic loads to the other ONUs, in other words,simulations will be done with increasing background load whilst the loadto the investigated ONU stays the same.

The prediction is that the high priority queue will maintain a high levelof service — the queueing delay will stay low, even as the overall loadis getting quite high. The low priority queue will lose quality of servicesooner as the overall network load increases.

4.4.1 Traffic Generation for the particular ONU

There are three different traffic classes used in this scheduling scheme; in-teractive voice and video, streaming video and normal internet traffic.

Interactive Voice Voice over Internet Protocol (VOIP) is the routing ofvoice conversations over the Internet or through any other IP-based net-work. Being based on the packet switched network of IP it is fundamen-tally different from the circuit switched PSTN telephone system. Graduallyreplacing old PSTN systems with VOIP seems to be the trend, so for thesimulations in this these the characteristics of VOIP will be used.

An underlying codec used for VOIP is G.729 [22], this standard operatesat 8 Kbit/s. Unfortunately, bandwidth is wasted due to packet headers inunderlying protocols. This is primarily due to the IP, UDP and RTP headerscontributing to a 40-byte overhead to each packet [23].

The algorithm compresses the voice into chunks of 10 milliseconds,which means every second 100 packets of 80 bits are sent. Adding thepacket headers results in packets of 400 bits, resulting in a total data rate of40 Kbit/s.

Streaming Video With video, two codes are being used, the first beingthe standard and the most popular at the moment and the second is anewer more efficient standard which eventually should replace the first

4.4. Intra-ONU Priority Scheduling 51

! Table 4.1: Bandwidth requirements per video format

MPEG-2 H.264, MPEG-4

SDTV 3 - 4 Mbit/s 2 Mbits/sHDTV 14 - 19 Mbit/s 8 - 16 Mbit/s

! Table 4.2: Heavy traffic model

Traffic Load (Mbit/s) Traffic Type Priority

VOIP (2!) 0.080 CBR HighestSDTV (2!) 4 Self-Similar HighHDTV (1!) 16 Self-Similar HighInternet 50 Self-Similar Normal

one. MPEG-2 [24] is the codec most commonly used for HDTV, but al-ready are broadcasters planning to use MPEG-4 AVC [25, 26]. This newH.264/AVC standard, proposed by the ITU-T Video Coding Expert Group(VCEG) and ISO/IEC Moving Pictures Expert Group (MPEG), is expectedto dominate in upcoming multimedia services, due to the fact that it canachieve considerably higher coding efficiency compared to the already widelyused standards [27].

High Definition Television has better quality over the standard (mostlyanalog) television signal most viewers receive now. It is expected that usersof home networks will use a mix of HDTV and SDTV (standard definitiontelevision. SDTV operates in a 576 format. Non-cinematic HDTV videorecordings are recorded in either 720p or 1080i format. The actual bitratewhich is required depends on the amount of compression which is applied.Table 4.1 shows the bandwidth required for the two codecs with the differ-ent formats.

According to [28] VBR video traffic can be modelled using self-similarprocesses. Packet switched networks are better suited for VBR than forConstant Bit Rate (CBR) streams, which on its turn are better suited forcircuit-switched networks.

Normal traffic Typical usage of a FSAN would also include Internet traf-fic Various studies show that internet traffic can be characterized by self-similar traffic [29, 30, 20, 31].

The three different traffic types will be used to model a “typical heavy”traffic usage of a ONU. The duration of the simulation will be one minute,


during this minute two VOIP calls will be active, one HDTV channel willbe viewed, together with two SDTV channels. Also a heavy internet trafficload of 50 Mbit/s will be simulated. Table 4.2 summarizes the completetraffic model.

4.4.2 Traffic load for the other ONUs

The other ONUs will be loaded with self-similar traffic. Different simula-tions with an increasing load will be performed.

4.4.3 Input

Seed To generate a good estimate this simulation is also done fifteen times.Fifteen independent simulations, each with a different seed are run. Asmentioned in section 4.2 the seed values should be chosen in such way thatthey are the resulting RNG streams do not overlap. Our simulations are runwith fifteen seeds, starting at 1001 with interval 1000 (1001, 2001, . . . , 15001).

Traffic Load The traffic to the ONU which is being measured stays con-stant, this is done according to section 4.4.1 (see table 4.2). The traffic tothe other ONUs increases every simulation, each simulation is run with adifferent load on the ONUs, the first simulation is done with 12.36 Mbit/sper ONU and the last one with 188.82 Mbit/s per ONU. See table B.7 onpage 71 for the complete list of loads per ONU.

Frequency Response The frequency response of each subcarrier is dif-ferent for each ONU. The values are used to determine which ONU useswhich subcarrier. Determining how many bits are loaded on the subcarri-ers is also done using the frequency responses. These values are taken frompre-calculated files, details on the frequency responses are in [32].

Timeslot Duration During all the simulation the timeslot or epoch lengthstays constant. It is set at 100ms.

4.4.4 Requirements

The three traffic types introduced in this section all have different Qualityof Service requirements.

Streaming Video Streaming video is a one-way datastream, so the mini-mal delay is not a technical issue. It is more relevant for the viewer of themedia, when someone switches to a channel he or she does not want to


wait for a long time before the video starts. Also, when watching live tele-vision a long delay is not very desirable. It is assumed a maximum delayof 1 second is good enough.

Also jitter is not so much of an issue because it can be compensated witha buffer, resulting in extra delay. It is limited to the users expectation of thetime it should take when he or she switches to a channel and the capacity ofthe memory. Memory is cheap enough nowadays so the memory capacityis not an issue.

Interactive Voice Interactive voice is a two way data stream, and theusers interact with each other, so unlike the streaming video the delay isvery important for the Qos. Which limits the maximal tolerable round-tripdelay to 200-300 ms; that is, oneway delay must be in the range of 100-150ms for adequate performance [33].

Normal Traffic As it is unknown what this traffic type is besides beingnormal Internet traffic it is very difficult to state QoS aspects.

The parameters mentioned in this section are all End-to-End, but the val-ues being measured in the simulation are all related to the queues in theOLT. So, these queueing delays are related to the last hop (from the OLTto the ONU). When comparing these values with the End-to-End values inthis section, it should be taken into account that the results here are onlybetween the OLT and ONU. Queueing delays can easily be read from themeasured data, unfortunately this is not so straightforward for the jitter.The jitter can be calculated as the standard deviation of the observations.The calculation of the standard deviation (!) is repeated here and explainedin section 4.2 on page 44. N is the total number of observations, xi is theith observation, x is the mean.

! =

%

&

&

'

1

N

N!

i=1

(xi # x)2

4.4.5 Results

Figure 4.5 on page 54 shows the bandwidth and traffic received for twoONUs. The X-axis shows the overall network load, the Y-axis representsthe bandwidth allocation and the traffic load.

ONU0 is the ONU which has a constant load based on the traffic modelpresented in section 4.4.1. ONU1 represents one of the other ONUs, theseONUs have an increasing load for every simulation, this is shows in fig-ure 4.5(b). The increase in traffic is a linear line, the exact values are in ta-ble B.7 on page 71. The assigned bandwidth remains quite constant, there is


0

100

200

300

400

500

600

700

0 500 1000 1500 2000 2500 3000 3500

band

widt

h [M

egab

its p

er s

econ

d]

total amount of traffic on the network [Megabits per second]

traffic receivedbandwidth allocated

(a) Bandwidth and Traffic for ONU0

0

20

40

60

80

100

120

140

160

180

200

0 500 1000 1500 2000 2500 3000 3500

band

widt

h [M

egab

its p

er s

econ

d]



(b) Bandwidth and Traffic for ONU1

! Figure 4.5: Bandwidth and traffic for two ONUs


a slight increase as the traffic load increases, which is logical since the moretraffic a ONU has the more bandwidth is gets allocated. The limit is thetotal amount of bandwidth available and since this figure represents all theONUs except one the bandwidth increasement due to the extra demand isneglectable since almost the entire network is requiring more bandwidth.

Figure 4.5(a) illustrates the greediness of the bandwidth allocation al-gorithm, the algorithm always assigned all the subcarriers to the ONUs,even if the load is so light this is not necessary. The figure shows that whenthe entire network load is very light, the only ONU with a decent load getsway too many bandwith assigned to. This changes quickly as the overallnetwork load increases, the graph approaches the actual traffic load.

0

0.02

0.04

0.06

0.08

0.1

0.12

0.14

0.16

0.18

0.2

0 500 1000 1500 2000 2500 3000 3500

queu

eing

del

ay [s

econ

ds]


high prioritymedium priority

low priority

! Figure 4.6: Queueing delays for different priorities with an increasingtraffic load

Figure 4.6 shows the queueing delays for the different queues for ONU0.The epoch duration is set to 100ms (as stated in section 4.4.3). As concludedin the previous paragraph the bandwidth allocation to ONU0 decreasesas the overall load increases. The result of this is an increased queueingdelay. Especially the lowest priority queue suffers when the traffic load in-creases, the other queues stay quite unaffected. This is a direct result of thestrict exhaustive priority queueing. Since there is lack of any fairness in thisqueueing strategy the highest priority queues will be served till exhaustionbefore lower priority queues are served. So, if the allocated bandwidth is


0

1

2

3

4

5

6

7

8

9

10

0 500 1000 1500 2000 2500 3000 3500

jitter

del

ay [m

illise

cond

s]


high prioritymedium priority

low priority

! Figure 4.7: Queueing jitter for different priorities with an increasing traf-fic load

100 Megabit and the high, medium and low priority traffic are respectively20, 50 and 50 Megabit the high and medium priority queues are servedtotally and the low priority queue is only served for 20 Megabit.

Only when the high and medium traffic both exceed the bandwidththe medium priority traffic will show a large increase in delay. If the highpriority on its own already exceeds the allocated bandwidth the high pri-ority traffic will have an increase in delay. Drastic increase of delay in thehigh and medium priority traffic will most probably only occur when thesystem is overloading, if this is the case the traffic should be decreased ormore bandwidth should become available, this is not so much an issue ofthe network protocol layer.

When comparing the results from figure 4.6 with the requirements fromsection 4.4.4 on page 52 the following observations can be made. The re-quirements for the interactive voice are 100ms for the delay and 50ms forthe jitter. Even when the system is overloading these requirements are met,the highest values measured are 12.75ms for the delay and 0.34ms for jitterwhen the system is loaded with a total of 3396Mbit/s of data traffic. Therequirements for the streaming video are 1000ms for the delay plus jitter.The highest value measured for the delay is 68ms and way within limits.The highest value measured for the jitter is 8ms and also way within limits.


So, even when the system is being overloaded (when there is more trafficthan there is capacity), which can be seen in figure 4.5 on page 54, the twohigher priority traffic classes are still being served with the delay and jitterrequirements within limits.

59

Chapter 5

Conclusion and Future Work

5.1 Conclusion

The research goal of this thesis has been formulated the first chapter, hereit is repeated.

The goal of this assignment is to design a link-layer protocol (as thenetwork is single-hop) which uses an earlier developed subcarrier as-signment method as its core algorithm. The algorithm may use out ofband signaling through the baseband channel of the multimode fiber.Also, the network setup and join/leave procedures should be devisedas parts of the protocol.

The starting point of the design was to investigate other network de-signs and use the ideas to develop a new protocol. The protocol has beendesigned and is documented in this thesis. Basically it consists of twophases, the discovery phase and the assignment phase. The discoveryphase is contention based and also includes ranging as being part of theregistration process. The assignment phase requests the SNR data fromthe ONUs and also assigns blocks in which the ONUs can broadcast onall channels for the uplink SNR data. This is all done on the control chan-nel, therefore it is TDMA. The durations of messages and phases have beendetermined and is in the chapter three on the design. An important con-clusion is that the additional signaling needed for this particular networkdoes not generate a lot of overhead, the occupation of the control channelis less than one percent.

In addition two types of simulations have been executed. The first in-vestigated the discovery phase, in which ONUs are registered on the net-work. A conclusion of these simulations is that registering new ONUs canbe done very quickly and does not have an impact on the overall perfor-mance. The ONUs are registered in matters of tenths of seconds and theprocess does not interfere with the normal operation of data transmission.

60 Chapter 5. Conclusion and Future Work

Also, intra-ONU priority scheduling has been introduced. With a rea-sonable overall traffic load the VOIP and IPTV is served within limits andInternet access performs well. When the network reaches it maximum ca-pacity the performance drops quickly, which is expected behaviour. Thetraffic load introduced in chapter four was considered a heavy load, butduring the simulation it was noticed that this load is relatively light forthe network. When the other nodes received much more traffic than this“heavy” load the network overloaded.

5.2 Future Work

This section exists because there is never enough time, a thesis cannot beexhaustive and has to be finished at some point. In fact, along the processof writing a thesis new questions may arise.

The network was tested with a residential usage model, it should alsobe considered that the network will be used in companies. For instance,when the network will be used as a Storage Area Network, it is likely thatQoS aspects should be guaranteed. For this it should be possible to treatONUs differently due to different SLAs. This thesis introduced intra-ONUpriority scheduling to improve the protocol with QoS functionality; in ad-dition to this other scheduling mechanisms, such as Inter-ONU priorityscheduling are good solutions and should be considered, and comparedto intra-ONU scheduling. Inter-ONU priority will also be required whenONUs should be treated differently.

Also the traffic model in the simulations remains quite ambigious. Itis very difficult to tell how the network will be used eventually when it isdeployed and when models are used it is difficult to determine if the mod-els used represent real life traffic correctly. And, because the simulation ofthe network is a very demanding task only short periods (60 seconds) canbe simulated, real life traffic does not stay constant but fluctuates over pe-riods like days, for instance when people switch on the television or startdownloading a movie. The control channel has been dedicated to the sig-nalling, it was concluded that the signalling uses the channel very lightly.This leaves quite a lot of bandwidth unused, which could be utilized fordata traffic.

61

Appendix A

OPNET Implementation

62 Appendix A. OPNET Implementation

D I S C O V E R Y

R E G I S T E R

R E G I S T E R E D A S S I G N M E N T

R E C E I V E D I S C O V E R Y W I N D O W /S E N D R E G I S T E R R E Q U E S T

R E C E I V E R E G I S T E RS E N DA C K N O W L E D G M E N T R E C E I V E

S N R R E Q U E S TS E N D ( d e l a y e d )S N R R E S P O N S E

R E C E I V EA S S I G N M E N TS E N D ( t o i n t e r f a c e )C O N T R O L M E S S A G E

! Figure A.1: State diagram for control process in ONU.

63

I D L E

D I S C O V E R Y

R E G I S T E R I N G S N R

S E N D D I S C O V E R Y W I N D O W /

D I S C O V E R Y W I N D O W C L O S E D S E N D R E G I S T E R T O O N U xR E C E I V EA C K N O W L E D G M E N T F R O M O N U x

R E G I S T E R R E Q U E S T L I S T E M P T YS E N D S N R R E Q U E S T

R E C E I V E R E G I S T E R R E Q U E S T

R E C E I V ES N R R E S P O N S E

A L L S N R R E S P O N S E R E C E I V E DS E N DA S S I G N M E N TS E N D ( t o i n t e r f a c e )C O N T R O L

! Figure A.2: State diagram for control process in OLT.

64 Appendix A. OPNET Implementation

65

Appendix B

Complete Results

! Table B.1: Complete results of discovery phase measurements

backoff parameter

length (µs) no 1 2 3 4

1 — 35.185417 34.691667 32.981250 32.9041672 — 34.160417 33.495833 29.810417 29.9312503 — 28.829167 23.685417 19.470833 17.8895834 108.029167 19.077083 16.070833 13.664583 13.0645835 24.991667 13.143750 11.252083 9.975000 9.7770836 14.400000 9.847917 8.633333 8.304167 8.5062507 9.370833 7.595833 7.372917 6.966667 7.5770838 7.308333 6.618750 6.383333 6.595833 6.85625010 5.379167 5.237500 5.131250 5.602083 5.70833312 3.908333 4.216667 4.241667 4.577083 5.06458314 3.404167 3.725000 3.770833 4.202083 4.64375016 3.050000 3.206250 3.462500 3.847917 4.12708320 2.500000 2.670833 2.977083 3.370833 3.75208324 2.195833 2.414583 2.656250 2.952083 3.32708328 2.033333 2.243750 2.552083 2.877083 3.17708332 1.841667 2.041667 2.354167 2.604167 2.875000

66 Appendix B. Complete Results

! Table B.2: Confidence intervals with 95% probability of discovery phasemeasurements

backoff parameter

length (µs) no 1 2 3 4

1 — 6.226416 5.615383 5.603130 5.4317232 — 6.123271 5.414929 4.922394 4.9800213 — 5.451067 4.359023 3.392388 3.2323814 36.866180 3.800952 3.341749 2.302181 2.2840775 5.825467 2.256864 2.019538 1.691578 1.5878116 2.969035 1.632354 1.464288 1.461518 1.3559527 1.840783 1.257906 1.225680 1.160280 1.2087018 1.194452 1.118627 1.096816 1.049281 1.12033110 0.891368 0.880547 0.830043 0.915673 0.93142212 0.634037 0.685002 0.698074 0.780764 0.85268114 0.528335 0.617169 0.587969 0.669398 0.70891716 0.505705 0.494258 0.547985 0.645561 0.65594820 0.412028 0.424479 0.477899 0.522285 0.59307724 0.387698 0.392113 0.425791 0.475836 0.55887828 0.346436 0.366180 0.406621 0.475558 0.52176832 0.300079 0.333591 0.392473 0.437234 0.469487

67

! Table B.3: Mean values for queueing delay in priority scheduling simu-lation

delays (second)

total traffic (bits/second) queuehi queue med queuelow

258493910 0.001436 0.002665 0.007208442686661 0.002218 0.003433 0.008617627067214 0.002599 0.003848 0.009779811722075 0.002851 0.004288 0.011325996040442 0.003089 0.004474 0.013296

1180514608 0.003315 0.004886 0.0158431365188014 0.003478 0.005275 0.0189241549601866 0.003618 0.005523 0.0234931733991609 0.003974 0.005925 0.0297611918556434 0.004259 0.006481 0.0379942102901307 0.004657 0.007610 0.0498962288306881 0.004957 0.009102 0.0676582473017312 0.005607 0.011150 0.0944402657245940 0.006114 0.013927 0.1871952842585685 0.008489 0.022510 0.3897663026383993 0.011551 0.042310 4.6147333210795875 0.012377 0.056078 8.9193223396566663 0.012746 0.067610 12.397952


! Table B.4: Jitter for queueing delay in priority scheduling simulation

delays (second)


258493910 0.000190 0.000258 0.000213442686661 0.000241 0.000362 0.000513627067214 0.000285 0.000363 0.000434811722075 0.000374 0.000409 0.000718996040442 0.000272 0.000381 0.000741

1180514608 0.000337 0.000416 0.0007411365188014 0.000383 0.000698 0.0007611549601866 0.000323 0.000573 0.0013131733991609 0.000340 0.000488 0.0015291918556434 0.000407 0.000519 0.0017302102901307 0.000361 0.000661 0.0024492288306881 0.000363 0.000686 0.0037242473017312 0.000303 0.000909 0.0060472657245940 0.000869 0.002290 0.1797662842585685 0.000485 0.002485 0.0863143026383993 0.000539 0.006157 0.2943343210795875 0.000595 0.009112 0.5660963396566663 0.000608 0.007932 0.706600

69

! Table B.5: Confidence intervals with 95% probability for queueing delayin priority scheduling simulation

delays (second)


258493910 0.000105 0.000142 0.000117442686661 0.000133 0.000199 0.000282627067214 0.000157 0.000200 0.000239811722075 0.000206 0.000225 0.000395996040442 0.000150 0.000210 0.000408

1180514608 0.000186 0.000229 0.0004081365188014 0.000211 0.000384 0.0004191549601866 0.000178 0.000316 0.0007231733991609 0.000187 0.000269 0.0008421918556434 0.000224 0.000286 0.0009532102901307 0.000199 0.000364 0.0013492288306881 0.000200 0.000378 0.0020512473017312 0.000167 0.000500 0.0033312657245940 0.000478 0.001261 0.0990042842585685 0.000267 0.001369 0.0475363026383993 0.000297 0.003391 0.1621013210795875 0.000328 0.005019 0.3117713396566663 0.000335 0.004368 0.389152


! Table B.6: Normalized confidence intervals with 95% probability forqueueing delay in priority scheduling simulation

delays (second)


258493910 0.072773 0.053248 0.016296442686661 0.059900 0.058049 0.032762627067214 0.060429 0.051973 0.024444811722075 0.072240 0.052545 0.034917996040442 0.048417 0.046856 0.030709

1180514608 0.056041 0.046912 0.0257581365188014 0.060622 0.072860 0.0221331549601866 0.049108 0.057154 0.0307831733991609 0.047125 0.045324 0.0283001918556434 0.052587 0.044089 0.0250802102901307 0.042704 0.047817 0.0270362288306881 0.040302 0.041491 0.0303122473017312 0.029718 0.044876 0.0352662657245940 0.078238 0.090556 0.5288842842585685 0.031475 0.060800 0.1219613026383993 0.025703 0.080141 0.0351273210795875 0.026494 0.089491 0.0349553396566663 0.026270 0.064611 0.031388

71

! Table B.7: Simulation input for background traffic (per ONU)

mean (bit/second) 95 % confidence interval

12355090.24 90057.84417524640003.20 160323.08170936864635.26 139338.57606349205069.68 206882.24637961604783.87 249398.00291173778226.81 342669.38940086128558.00 318506.72805298456453.32 382313.158746

110694806.14 262443.606913122889912.79 365608.453749135167817.87 373053.159257147584108.08 442728.721614159773094.30 336921.838676172015286.29 575623.233291183941156.96 517725.951667187027989.63 554636.892048187793095.09 476951.888548188824008.47 537809.355180


0

500

1000

1500

2000

2500

3000

0 500 1000 1500 2000 2500 3000 3500

band

widt

h [M

egab

its p

er s

econ

d]



! Figure B.1: Total bandwidth versus total traffic load

Bibliography 73

Bibliography

[1] “Full-service access network using multimode fibre.” [Online].Available: http://www.ctit.utwente.nl/research/projects/national/iop/iop-gencom/fsan.doc/

[2] “Part 3: Carrier sense multiple access with collission detection(csma/cd) access method and physical layer specification,” IEEE,Institute of Electrical and Electronics Engineers, Inc. [Online]. Available:http://standards.ieee.org/getieee802/802.3.html

[3] W. Tomasi, Electronic Communications Systems: Fundamentals throughAdvanced. Upper Saddle River, NJ, USA: Prentice Hall PTR, 2000.

[4] G. Kramer, B. Mukherjee, and A. Maislos, “Ethernet passive opticalnetworks,” pp. 229–275, 2003.

[5] Y. Ota, R. Swartz, I. Archer, V.D., S. Korotky, M. Banu, andA. Dunlop, “High-speed, burst-mode, packet-capable optical receiverand instantaneous clock recovery for optical bus operation,”Lightwave Technology, Journal of, Vol.12, Iss.2, Feb 1994 Pages:325-331.[Online]. Available: http://ieeexplore.ieee.org/xpls/abs all.jsp?tp=&arnumber=350582b

[6] A. Banerjee, Y. Park, F. Clarke, H. Song, S. Yang, G. Kramer,K. Kim, and B. Mukherjee, “Wavelength-division-multiplexed passiveoptical network (wdm-pon) technologies for broadband access: areview [invited].” [Online]. Available: http://www.opticsinfobase.org/abstract.cfm?URI=JON-4-11-737

[7] L. G. Roberts, “Aloha packet system with and without slots and cap-ture,” SIGCOMM Comput. Commun. Rev., vol. 5, no. 2, pp. 28–42, 1975.

[8] N. Abramson, “The throughput of packet broadcasting channels,”IEEE Transactions on Communications, vol. 25, pp. 117–128, Jan. 1977.

[9] “Full services access network.” [Online]. Available: http://www.fsanweb.org/

http://www.fsanweb.org/

http://www.ctit.utwente.nl/research/projects/national/iop/iop-gencom/fsan.doc/

http://www.ctit.utwente.nl/research/projects/national/iop/iop-gencom/fsan.doc/

http://standards.ieee.org/getieee802/802.3.html

http://ieeexplore.ieee.org/xpls/abs_all.jsp?tp=&arnumber=350582b

http://ieeexplore.ieee.org/xpls/abs_all.jsp?tp=&arnumber=350582b

http://www.opticsinfobase.org/abstract.cfm?URI=JON-4-11-737

http://www.opticsinfobase.org/abstract.cfm?URI=JON-4-11-737

http://www.fsanweb.org/

74 Bibliography

[10] K. S. Kim, “On the evolution of pon-based ftth solutions,” InformationSciences, Volume 149, Issues 1-3, January 2003, Pages 21-30., Januari2003. [Online]. Available: http://www.sciencedirect.com/science/article/B6V0C-477FTF0-7/2/bea44c493e681eca74363aa05cc2038a

[11] “Recommendation g.984.1,” ITU-T, International TelecommunicationUnion, Mar. 2003. [Online]. Available: http://www.itu.int/rec/T-REC-G.984.1/en

[12] S. Gorshe and T. Wilson, “Transparent generic framing procedure(gfp): a protocol for efficient transport of block-coded data throughsonet/sdh networks.”

[13] “Recommendation g.7041,” ITU-T, International TelecommunicationUnion, Aug. 2005. [Online]. Available: http://www.itu.int/rec/T-REC-G.7041/en

[14] D. Gutierrez, K. Kim, S. Rotolo, F. An, and L. Kazovsky,“Ftth standards, deployments and research issues,” 2005. [Online].Available: citeseer.ist.psu.edu/article/gutierrez05ftth.html

[15] G. Kramer, B. Mukherjee, and G. Pesavento, “Ipact a dynamic protocolfor an ethernet pon (epon),” Feb. 2002.

[16] G. Kramer, “What is next for ethernet pon?” 2006.

[17] E. Lynskey, G. Kramer, and B. Grow, “10g epon call for interest.”[Online]. Available: http://www.ieee802.org/3/cfi/0306 1/cfi 03061.pdf

[18] G. Kramer, “The problem of upstream traffic synchronization inpassive optical networks.” [Online]. Available: http://wwwcsif.cs.ucdavis.edu/&kramer/papers/ranging.pdf

[19] P. H. v. H. Edward Harstead, fixme.

[20] P. Leys, J. Potemans, B. V. den Broeck, J. Theunis, E. van Lil,and A. van de Capelle, “Use of the raw packet generator inopnet.” [Online]. Available: http://www.esat.kuleuven.be/telemic/networking/opnetwork02 pieter.pdf

[21] B. R. Haverkort, Performance of Computer Communication Systems: AModel-Based Approach. New York, NY, USA: John Wiley & Sons, Inc.,1998.

[22] “Recommendation g.729,” ITU-T, International TelecommunicationUnion, Jan. 2007. [Online]. Available: http://www.itu.int/rec/T-REC-G.729-200701-P/en

http://www.itu.int/rec/T-REC-G.729-200701-P/en

http://www.sciencedirect.com/science/article/B6V0C-477FTF0-7/2/bea44c493e681eca74363aa05cc2038a

http://www.sciencedirect.com/science/article/B6V0C-477FTF0-7/2/bea44c493e681eca74363aa05cc2038a

http://www.itu.int/rec/T-REC-G.984.1/en

http://www.itu.int/rec/T-REC-G.984.1/en

http://www.itu.int/rec/T-REC-G.7041/en

http://www.itu.int/rec/T-REC-G.7041/en

http://www.ieee802.org/3/cfi/0306_1/cfi_0306_1.pdf

http://www.ieee802.org/3/cfi/0306_1/cfi_0306_1.pdf

http://wwwcsif.cs.ucdavis.edu/~kramer/papers/ranging.pdf

http://wwwcsif.cs.ucdavis.edu/~kramer/papers/ranging.pdf

http://www.esat.kuleuven.be/telemic/networking/opnetwork02_pieter.pdf

http://www.esat.kuleuven.be/telemic/networking/opnetwork02_pieter.pdf

http://www.itu.int/rec/T-REC-G.729-200701-P/en

Bibliography 75

[23] R. J. B. Reynolds and A. W. Rix, “Quality voip an engineering chal-lenge,” BT Technology Journal, vol. 19, no. 2, pp. 23–32, 2001.

[24] “Iso/iec 130818-1:2000, information technology – generic cod-ing of moving pictures and associated audio information: Sys-tems,” International Organization for Standarization, Jan. 2000. [On-line]. Available: http://www.iso.org/iso/iso catalogue/cataloguetc/catalogue detail.htm?csnumber=31537

[25] “Recommendation h.264,” ITU-T, International TelecommunicationUnion, Mar. 2005. [Online]. Available: http://www.itu.int/rec/T-REC-H.264

[26] “Iso/iec 14496-10:2005, information technology – coding ofaudio-visual objects – part 10: Advanced video coding,”International Organization for Standarization, Oct. 2005. [On-line]. Available: http://www.iso.org/iso/iso catalogue/cataloguetc/catalogue detail.htm?csnumber=43058

[27] H. Koumaras, C. Skianis, G. Gardikis, and A. Kourtis, “Analysis ofh.264 video encoded traffic,” Proc. INC 2005 Fifth International NetworkConference, Jul. 2005.

[28] M. W. Garrett and W. Willinger, “Analysis, modeling and generationof self-similar vbr video traffic,” SIGCOMM Comput. Commun. Rev.,vol. 24, no. 4, pp. 269–280, 1994.

[29] W. E. Leland, M. S. Taqq, W. Willinger, and D. V. Wilson, “On theself-similar nature of Ethernet traffic,” in ACM SIGCOMM, D. P.Sidhu, Ed., San Francisco, California, 1993, pp. 183–193. [Online].Available: citeseer.ist.psu.edu/article/leland93selfsimilar.html

[30] V. Paxson and S. Floyd, “Wide area traffic: the failure of Poissonmodeling,” IEEE/ACM Transactions on Networking, vol. 3, no. 3,pp. 226–244, 1995. [Online]. Available: citeseer.ist.psu.edu/article/paxson94widearea.html

[31] P. K. C.-H. Chang and J. Senior, “Gpon service level agreement baseddynamic bandwidth assignment protocol,” Electronic Letters, Volume42, Issue: 20, on page 1173-1174, 2006. [Online]. Available: http://ieeexplore.ieee.org/xpls/abs all.jsp?arnumber=1706042

[32] B. Sikkes, “A stable matching based adaptive subcarrier assignmentmethod for multimodal fibre access networks,” 2006. [Online]. Avail-able: http://dacs.ewi.utwente.nl/assignments/completed/master/reports/Thesis bart sikkes.pdf

http://dacs.ewi.utwente.nl/assignments/completed/master/reports/Thesis_bart_sikkes.pdf

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=31537


http://www.itu.int/rec/T-REC-H.264

http://www.itu.int/rec/T-REC-H.264



http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1706042

http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1706042

http://dacs.ewi.utwente.nl/assignments/completed/master/reports/Thesis_bart_sikkes.pdf

76 Bibliography

[33] M. Karam and F. A. Tobagi, “Analysis of the delay and jitter of voicetraffic over the internet,” in INFOCOM, 2001, pp. 824–833. [Online].Available: citeseer.ist.psu.edu/karam01analysis.html

Network protocol for multimode FTTH/FTTB · FTTB Fiber to the Building. FTTH Fiber to the Home. OLT...

Documents

Transcript of Network protocol for multimode FTTH/FTTB · FTTB Fiber to the Building. FTTH Fiber to the Home. OLT...