Broadband Network Delivery of Interactive Digital Video Using ATM

P1: KCU

Journal of VLSI Signal Processing kl494-11-Mao October 9, 1997 10:56

Journal of VLSI Signal Processing 17, 255–268 (1997)c© 1997 Kluwer Academic Publishers. Manufactured in The Netherlands.

Broadband Network Delivery of Interactive Digital Video Using ATM

WEIDONG MAOGeneral Instrument Corporation, 2200 Byberry Road, Hatboro, PA 19040

Abstract. The integrated digital multimedia video service can be delivered via different network media such asHybrid Fiber Coax (HFC) and Fiber to the Curb (FTTC). Asynchronous Transfer Mode (ATM) can be used asan effective transport mechanism for the digital video services, such as MPEG-2. Both the lower layer physicalnetwork topology/characteristics and network protocols impose special technical constraints on the overall digitalvideo system design.

The system issues on network delivery of digital video discussed in this paper include: (1) Overall network impactand system protocol stack for HFC and FTTC video delivery; (2) Interactivity of digital video and its signaling; (3)Quality of Service (QoS) impact on digital video coding algorithm.

Finally, the future directions on the networked video field are discussed and implementation choice and migrationstrategy are briefly analyzed.

1. Introduction

Asynchronous Transfer Mode (ATM) is an emergingnetwork protocol standard for delivery of integratedservice (video, data, and voice). It has many unique ad-vantages that makes it an ideal candidate for carryinginteractive video services in both Hybrid Fiber Coax(HFC) and full switched Fiber to the Curb (FTTC) net-work environments. ATM also plays a key role in thefuture migration path of HFC and FTTC networks.

Real time MPEG-2 video service delivery over ATMcreates many technical challenges and needs to be stud-ied and experimented from technology standpoint be-fore it can be adapted into various products. Amongthe key technical issues: (1) Jitter handling up to 1msfor MPEG stream; (2) Cell loss recovery and conceal-ment; (3) ATM performance monitoring issues; (4)MPEG DSM-CC session signaling with Q.2931 ATMconnection signaling; (5) Statistical multiplexing andvariable bit rate coding; (6) Integrated service of MPEGvideo/audio with data and possibly telephony.

The ATM Network Interface Module (NIM) pro-vides interface between the Digital Entertainment Ter-minal (DET) and the broadband distribution networks.It is usually regarded as a replaceable module in the Set-Top Terminal located at home. The ATM NIM provides

functional modules that extract signals from the broad-band spectrum, demodulate the signals, perform phys-ical layer transmission convergence function, processATM headers, perform Segmentation and Reassembly(SAR) function at ATM Adaptation Layer (AAL), in-teract with MPEG transport layer, and perform inter-active two way signaling and communication.

This paper describes the overall end to end system ar-chitecture platform for MPEG-2 video service deliveryover ATM to the home. It also describes broadband ac-cess network functional block diagram. Although it isbased on specific network scenarios, the system archi-tecture is designed to be modular and flexible enoughto be adopted into a variety of network environmentsand requirements. In addition, the system and networkissues involving MPEG delivery over ATM are alsodiscussed.

2. Network Architectureand Service Requirements

2.1. Generic Network Architecture

A generic network architecture for delivering inte-grated video services is illustrated in Fig. 1. In this

P1: KCU


256 Mao

block diagram, two classes of network architecture aredescribed: Switched Digital Video (SDV) and Hy-brid Fiber Coax (HFC). The differences of the twomainly appear in the Access Network. SDV architec-ture is sometimes also referred to Fiber to the Curb(FTTC).

The HFC architecture, in conjunction with its broad-cast capability, is compatible with the cable networkand set-top technology existing today. The HFC ar-chitecture has been shown to support the services suchas analog broadcast, digital broadcast, near video-on-demand, and interactive video-on-demand. Regardlessof the usage of the HFC network, its topology providesasymmetric bandwidth, and requires encryption to sup-plement the broadcast medium. The asymmetry is atissue in reference to upstream bandwidth, in that it be-comes the limiting factor to the number of subscribersper home which a node can support.

The current emerging network architecture is FTTC.The FTTC topology enables multimedia to be deliveredvia a switched scheme. In reference to video, which isthe most bandwidth consuming, FTTC makes use ofSwitched Digital Video (SDV) delivery, which requiresdedicated bandwidth from the headend to the set-top. The FTTC architecture also provides a symmet-rical transport mechanism, which will be compatible

Figure 1. Generic network architecture for video services delivery. Legend—VIP: Video Information Provider; VIU: Video InformationUser; L1GW: Level 1 Gateway; ATM: Asynchronous Transfer Mode; SDV: Switched Digital Video; HFC: Hybrid Fiber Coax; HDT: HostDigital Terminal; ONU: Optical Network Unit; GIANT: GI Access Network; NIM: Network Interface Module; DET: Digital EntertainmentTerminal.

with the current upgrade path of the Public SwitchedTelephone Network (PSTN), and ultimate desiresfor point-to-point communications. The point-to-pointtopology of FTTC also enables digital video to be deliv-ered without requiring encryption. The switching ca-pability of the FTTC architecture provides a naturalcompatibility with the Asynchronous Transfer Mode(ATM) technology, specifically the switching/routingcapabilities. The FTTC or SDV network is the main tar-get architecture that most of this work will be based on.

A typical network architecture characteristics can besummarized in Table 1.

2.2. Service Requirements

The video service requirements for a typical integratedVideo Dial Tone (VDT) network and Video Informa-tion Provider (VIP) as well as Video Information User(VIU) include the followings:

2.2.1. Analog Broadcast. The user who subscribesservice will have access to 6 MHz analog broadcastchannels which provide the programming as the onesexist today. In general, analog channels are scrambledand encryption and access control will be required for

P1: KCU


Broadband Network Delivery 257

Table 1. Functionalities and configurations of network architecture.

System module Functionalities Typical configurations

VIP:Video server • Store and playback multiple MPEG-2 transport Disk array architecture with multiple OC-3c outputs.

streams (Constant Bit Rate) One server supports 1–10 GB storage and 10–10000• Use DSM-CC User-Network signaling with L1GW stream playback at the same time with up to

and User-User signaling with VIUs 15 Mbps per stream• ATM Q.2931 signaling for connection setup within

ATM networks

Interactive data server • Store, playback and receive interactive data OC-3c or other physical layer interface.services (Variable Bit Rate) The application protocol is independent of network.

• Control signals can be embedded into DSM-CCUser-User messages.

Internet gateway • Internet gateway for on-line services 1P over ATM

Broadcast encoder • Real time MPEG-2 encoder for single or multiple ATM multiplexor with OC-3c or OC-12 interfaceprogram transport streams Multiple MPEG encoders

• Statistical multiplexing at MPEG level

Cable headend • Analog broadcast/premium channels 6 MHz per channel50 MHz to 450 MHz

L1GW:ATM networks • Remote ATM networks supporting multiple Multiple ATM switches with multiple OC-3 and

input/output OC-12 interfaces, connection manager for Q.2931• Connection manager to setup SVC (Q.2931) and PVC and network management

Session manager • DSM-CC User-Network signaling for configuration, OC-3 or Ethernet interface with ATM network andsession setup/tear down, access control etc. access network

Access networks:HDT • Located in the central office and provide ATM OC-3 and OC-12 interface with ATM network. Sup-

routing/multiplexing function on the per access port up to 64 ONUs each HDTnode basis

ONU • Located at the curb and provide ATM termination OC-3 interface with HDT.and modulation or demodulation for upstream data 51.84 Mbps downstream with CAP-16 or QPSKand downstream data modulation 1.6 to 19 Mbps upstream with QPSK

• Provide analog cable overlay demodulation.Support 8–16 homes per ONU

Element manager • Provide connection and/or session management on Ethernet or OC-3 interface with both Session managerthe per access network node basis and HDT/ONU

• Provide access node OAM functions

HFC access node • ATM demultiplexing Support up to 480 home per HFC access node• Encryption/access control• 64QAM per 6 MHz for downstream• QPSK demod for upstream

VIU:NIM • Demodulation of downstream signal Coaxial input

• Modulation of upstream signal Utopia interface between Physical Layer and SAR• TDMA for upstream time slots 51.84 Mbps downstream with CAP-16 or QPSK• ATM and MPEG SAR functions demodulation• DSM-CC User-Network signaling to L1GW and/or 1.6 to 19 Mbps upstream with QPSK modulation.• access network

DET • MPEG2 transport and A/V decoding Up to 60 Mbps MPEG2 transport input stream.• Graphics capabilities MP@ML• User-User application (DSM-CC) M68331 or PowerPC processor• Closed captioning Graphics processor with 2 MB RAM and PCMCIA

2 MB Flash ROM

Other terminals • Coaxial input to PC with PC NIC for data Support up to 14 devices per homeapplications

• Coaxial/Twisted Pair interface with telephone

P1: KCU


258 Mao

premium channels. In the FTTC architecture, 6 MHzanalog broadcast cable channels are usually combinedwith the modulated and upconverted digital channelsin the frequency spectrum domain at the ONU. Thetechnical details can be found in other CATV relatedspecifications and will not be described in this docu-ment.

2.2.2. Digital Broadcast. The digital broadcast chan-nels are encoded based on the MPEG-2 InternationalStandard. They are broadcasted from VIPs to real timeMPEG encoder or broadcast server at the central officeand fed into the ATM networks using OC-3 or OC-12.Typically, all the digital broadcast programs are trans-mitted to each access network node. However, onlya subset of the total broadcast programs can be de-livered to each home. This is especially the case forFTTC where only a limited digital video bandwidth isavailable for each home (e.g., 51.84 Mbps), comparedwith up to OC-12 (about 620 Mbps) available broadcastbandwidth per access network. Therefore, a channelchange will either be local to each set-top or requireinteraction between set-top and access network.

The premium digital channels have to be autho-rized on per subscriber basis. Since there is onlyone dedicated coaxial cable connection to each homefrom ONU, it is guaranteed that the program dis-tribution can be fully controlled by the access net-work on per home basis. In other word, HDT inthe access network serves as an access control man-ager in distributed fashion (it is necessary that VIPsneed to communicate with the access network on sub-scriber access and billing record at the configurationstage).

2.2.3. Pay Per View (PPV) and Near Video On De-mand (NVOD). VIU can access Pay Per View (PPV)or Near Video on Demand (NVOD) services from VIPsor per VIP’s event schedule and access authorizationbasis. In the case of PPV, the VIP broadcasts the pro-gram event from either real time encoder or broadcastserver to all the access network element nodes in a pre-defined time slot, which is known ahead of time by allthe VIUs that can access the program. In the case ofNVOD, each program is broadcasted on a regular inter-val basis (e.g., every 30 min) over multiple channels.

In the FTTC approach, all the PPV and NVODchannels can be broadcasted to each access networknode. VIU can receive the selected channel by inter-acting with access node using a set of session control

messages. The advantages of using each access net-work node element for distributed PPV and NVODaccess control are fast response time and distributedaccess control and session management. On the otherhand, the session manager can be used for centralizedcontinuous PPV and NVOD session management thatallows the flexibility of multiplexing the channels intoeach access network element dynamically thus usingthe bandwidth more efficiently. The drawback of thisapproach is that the session manager has to handlelarge number of request from all the VIUs simulta-neously.

2.2.4. Interactive Video On Demand (VOD).TheVideo Information Providers (VIPs) can provide anumber of interactive services through the VIP servers(also called Level 2 Gateway). The applications in-clude Interactive Video Services such as Video On De-mand and Interactive Education/Shopping, or Interac-tive Data Services such as Home Banking, On-LineServices, and Games.

The Interactive VOD can be delivered through thenetwork using the “session” concept. A session isthe association between the VIU (Client) and VIP(Server) that can be characterized by identification ofclient and server, program choice, access authoriza-tion, as well as time duration. A session can be setupby the Session Manager (Network), which negotiatesconnection resources with the ATM networks and ac-cess network. ISO MPEG Digital Storage Media—Command and Control (DSM-CC) is specifying thesession signaling protocols. In the DSM-CC language,a session is established through User-Network mes-sages (VIU and Session Manager, VIP and SessionManager signaling). Once the session has been estab-lished, the control message for interactive applicationbetween VIP and VIU will fall into User-User mes-sages.

Therefore, a full interactive video on demand sessioncan be established through DSM-CC User-Networkmessages and the VOD program features such as fastforward, fast reverse, pause, application download, etc.can be facilitated through DSM-CC User-User mes-sages. Upon the purchase of the set-top boxes, the User-Network configuration has to be performed to registerthe VIUs address and set up initial downstream andupstream channel allocation.

The system requirements for delivering variousvideo services through the SDV network architecturecan be summarized in Table 2.

P1: KCU



Table 2. Video service requirements for switched digital video network.

Pay Per View (PPV) InteractiveVideo service type Digital broadcast Near VOD (NVOD) Video On Demand (VOD)

Video compression MPEG-2 MP@ML The same The sameUp to 15 Mbps

Audio compression MPEG-1 Layer I and II The same The same

Transport MPEG-2 transport stream of The same The sameconstant bit rate up to30 Mbps carrying singleor multiple programs

Downstream Up to 52 Mbps The same The sameUp to 256 VCs

Upstream None Up to 19 Mbps Up to 19 MbpsUp to 256 VCs Up to 256 VCs

VIP Channel map setup Channel map setup and session Channel map setup and sessionBroadcast authorization on authorization on the per event authorization on the per session

per access network basis and VIU basis (sub DSM-CC) and VIU basis (DSM-CC)

VIU Ability to access program Ability to establish, manage, and Ability to establish, manage,guide and change channel release sessions (sub DSM-CC) and release sessions (DSM-CC)

Network Ability to setup connection Ability to setup sessions, and Ability to setup sessions andresources on permanent connection resources on per event connection resources on per VIU/basis per VIU basis (sub DSM-CC) VIP session basis (DSM-CC)

Multi-session None None Yes, up to 8 sessions

Channel change <800 ms The same The same

Service response time N/A <2 sec. <5 sec.

Constant bit rate Yes Yes Yes

Variable bit rate Future support The same The same

Access control Pre-authorized Access node Session manager

3. System Issues for Interactive MPEG-2 Videoover ATM

In this section, the system issues and specificationsregarding to ATM delivery of MPEG-2 video servicesare discussed. In general, there are several importantsystem issues regarding to MPEG over ATM:

• Communication Protocol for ATM CarryingMPEG-2• Time Transparency.Cell Delay Variation and Burst

Traffic Impact on MPEG-2• Semantic Transparency. Cell Loss Impact on

MPEG-2• Session and Connection Signaling

The discussion in this section will address the abovesystem issues and provide general analysis and systemrequirements. Further detailed system studies on these

issues have been addressed during the actual imple-mentation of the system.

3.1. Communication Protocol for MPEG over ATM

The communication protocol stacks for MPEG overATM follows the OSI model and Broadband ISDNmodel specified in the standards. This can be illus-trated in Figs. 2 and 3.

The following specifies the requirements (indicatedby R) of communication protocol layer for MPEG overATM, in addition to those already specified in the ATMForum or ITU-T standards:

3.1.1. Physical Layer

(1) Physical Medium Dependent (PMD) Sublayer.OC-1c/STS-1c or OC-3c/STS-3c physical mediuminterface through bi-directional fiber or coaxial cable

P1: KCU


260 Mao

Figure 2. Broadband ISDN reference protocol model.

Figure 3. Protocol stacks for MPEG over ATM.

can be used for carrying MPEG-2 services. A line clockof either 51.84 Mbps or 155.52 Mbps can be recovered.

Typically, however, modulation and demodulationschemes for downstream and upstream signals un-der coaxial interface are used, e.g., CAP-16, QAM,or QPSK. The maximum downstream bit rate can be51.84 Mbps and the maximum upstream bit rate can be19.44 Mbps.

(2) Transmission Convergence (TC) Sublayer.An ex-ample of TC sublayer can be 128 microsecond of

Figure 4. SONET STS-1 frame structure.

Figure 5. ATM cell delineation algorithm using header error check(HEC) in ATM header.

SONET frames as defined by Bellcore TR-253 spec-ification. The ATM cells are transmitted using theSONET frames.

The followings are the system level requirements forSONET TC processing:

R1: The SONET framing bytes A1 and A2 shall bedetected through the frame alignment pattern: F628,which is not scrambled.

R2: The section, line, and path shall be checked usingB1, B2, and B3 8-Bit Interleaved Parity bytes.

R3: The SONET frame shall be descrambled accordingto Bellcore specification.

R4: The payload pointer H1, H2, H3 shall be processedto align the SPE.

R5: The ATM cell boundary can be detected by usingthe cell delineation process (Fig. 5).

3.1.2. ATM Layer. The ATM layer is used to performcell multiplexing/demultiplexing, generic flow control,cell priority processing, and OAM functions.

The ATM layer requirements for delivering MPEGservice shall conform the followings:

P1: KCU



R1: Generic flow control field bits are set to zeros andare not used for MPEG delivery.

R2: VPI/VCI filtering shall be done to retrieve MPEG-2 transport stream payload. VCI (0 to 31) are re-served for special ATM cells and cannot be used forMPEG.

R3: The PTI field shall be used to indicate payloadtype.

R4: The CLP bit is not used for priority of MPEG data.R5: Unassigned ATM cells (VPI/VCI= 0) are used

for cell rate decoupling and shall be discarded in thereceiver.

R6: Traffic management for upstream data shall beused.

3.1.3. MPEG-2 ATM Adaptation Layer (AAL). Themapping from MPEG-2 transport packet onto theAAL5 CS-PDU payload can depend on whether the 1stMPEG-2 packet of each pair of consecutive packets(188 byte size per packet) carries the PCR time-stamp(Program Clock Reference), which is sampled based onthe 27 MHz clock in the MPEG-2 transmitter side. Thiswill result two type of Segmentation and Reassemblyprocess, as described in the Fig. 8.

It is important to do so since this will minimize theMPEG timing jitters on the transmitter as well as thereceiver end. Otherwise, the maximum of 1 MPEG-2packet of jitters, (about 200 microsecond under trans-port rate of 7.5 Mbps), will be introduced.

The mapping of MPEG-2 transport packet onto theAAL5 CS-PDU has to conform the following require-ments:

R1: The end of the AAL5 packet can be indicated bythe last bit of the PTI field in the ATM header. If it isset to “1”, the current ATM cell payload contains the

Figure 6. ATM cell structure.

Figure 7. AAL5 ATM adaptation layer structure.

Figure 8. MPEG-2 transport mapping onto AAL5 and ATM.

last cell of the AAL5 packet, otherwise, it indicatesthe beginning or continuation of the AAL5 packet.

R2: The CRC-32 field has to be processed for errordetection.

R3: The length field in the AAL5 trailer shall be con-sistant with the PTI field.

3.2. Cell Loss Detection and Recoveryfor MPEG-2 Services

In ATM delivery of MPEG-2 services, any cell loss orbit error will cause different degree of quality degrada-tion of video and/or audio presentation. Therefore, itis important to define the cell loss or bit error impactsand provide robust algorithms for error recovery.

There are several types of error introduced in a typ-ical ATM network:

• Loss of one or more ATM cells due to switch-ing/multiplexing traffic congestion. Typically, thecell loss rate is in the order of 10−8.• Bit error rate (BER) caused by the physical transmis-

sion medium. Typically, it is in the order of 10−6.• Cell misrouting can happen in the ATM switches.

Although the probability of misrouting to ano-ther valid VPI/VCI is small(10−8), it cannot beignored.

Several layers of cell/error detection/correction algo-rithms can be used for MPEG-2 services over ATM.These can be specified in the following:

(1) Physical Layer Error Detection. For SONETframes, Bit Interleaved Parity (BIP-8) codes are used

P1: KCU


262 Mao

for section error detection (B1), line error detection(B2), and path error detection (B3). They are basedon the even parity and are calculated over the previ-ous frame. Thus the BIP-8 value of the previous frameis calculated and stored and compared with the corre-sponding field in the current frame.

If there is any detection of error at the SONET level,this is not going to be communicated to the higher lay-ers (including MPEG-2 layer). In other word, the com-plete ATM cells in the frame will be passed into thehigher layers for further processing. The reason is thatthere are total of (84)*9 bytes of SPE payload per frame,i.e., 14 cells for STS-1. They can account for about 4MPEG-2 transport packets. Dropping of these manypackets may cause severe MPEG-2 decoding problem.

(2) ATM Layer Header Error Check.The Header Er-ror Check (HEC) field for each ATM cell is used forerror detection and correction for the 5 bytes of ATMcell header only. Typically, single error correction andmultiple error detection algorithm is used to achievethe maximum efficiency as shown in Fig. 9.

• In the receiver, single error correction mode is usedat the beginning. If there is no error, it stays in thecorrection mode.• In the correction mode, if there is single error de-

tected, it will correct it and go to detection mode. Ifthere are multiple error bits detected, it will discardthe whole cell and go to detection mode.• In the detection mode, if there is no error detected,

it will go back to correction mode, if there is anyerror detected, it will discard the whole cell since it

Figure 9. ATM header error check algorithm.

Sync Transport Payload Unit Transport Transport Adaptation ContinuityByte Error Indication Start Indicator Priority PID Scrambling Field Control Counter

8 1 1 1 13 2 2 4

is most likely that a burst of cell errors happened thatcan not be corrected.

The impact on the MPEG-2 layer should be consid-ered when one or more ATM cells are discarded due tothe errors in the header. It should be noticed that anydiscarding of the ATM cells will cause AAL5 packetlength field inconsistency and/or CRC error. Thus, thiscan be considered in the AAL error recovery algorithmdescribed in the next section.

(3) AAL Layer Error Handling. In MPEG over ATM,the possible number of ATM cells per AAL5 CS-PDUis 5 cells or 8 cells. For signaling messages and data,we restrict the maximum number of cells per AAL5CS-PDU to be 22 (about 1 Kbyte).

Assume the total number of ATM cells used in thecurrent AAL5 CS-PDU isN,Assume the size of the CS-PDU payload (as indi-cated in the trailer field) isL,

Then, the AAL5 layer shall perform the following typesof error detection steps:

(1) The ATM cell payload (48 byte) is received and thetotal number of ATM cells in the AAL5 CS-PDUis counted by checking the last bit of PTI field.That isN.

(2) The AAL5 trailer is processed and CRC32 errordetection is performed on the whole AAL5 packet.If there is any error, CRCerror will be indicated(Type 1).

(3) The length field L in the trailer is extracted.

— Cell loss if N ∗ 48− L − 8< 0 (Type 2a)— Cell insertion ifN ∗ 48− L − 8> 47 (Type 2b)

(4) For MPEG-2 services, ifN is not equal to 5 or 8,then error is indicated (Type 3). For data services,if N is greater than the maximum number, thenerror is indicated (Type 4).

MPEG-2 transport packet header (4 bytes total) canbe used for error indication to the MPEG-2 transportlayer:

P1: KCU



Figure 10. Cell loss/insertion detection and handling algorithm.

Error can be signaled to MPEG layer by setting theTransport Error Indication bit to “1”, or by simply drop-ping the entire packet (replaced by null packet). In thelatter case, the error in each PID stream can be detectedby examining the Continuity Counter.

In order to maintain the timing integrity, it is im-portant to detect right number of MPEG-2 transportpackets in case of ATM cell loss/insertion. Otherwise,any increase or decrease of total number of MPEG-2packets will cause timing jitters.

The algorithm (shown in Fig. 10) is the most effectiveif the following assumptions are true:

(1) The probability of two lost cells is smaller than theprobability of one misdelivered cell (e.g.,N = 6,is more likely caused by one inserted cell).

(2) The probability of two misdelivered cell is smallerthan the probability of one lost cell (e.g.,N = 7,is more likely caused by one lost cell).

(3) The probability of misdelivery is smaller than theprobability of cell loss.

3.3. Cell Delay Variation and Burst Rate Handlingfor MPEG-2 Services

A typical ATM network will introduce certain amountof time variation of the arrival time of each cell. This

Cell Delay Variation (CDV) is defined as the absolutedifference between the maximum and minimum end toend cell delay.

TCDV = |MaximumTdelay− Minimum Tdelay|

The Cell Delay Variation, or Jitters, are usually causedby the following factors:

(1) ATM Switch Queuing Delay.Queuing buffers areused in a typical ATM switch for statistical mul-tiplexing and switching based on the incomingATM traffic. Based on the service requirement andbit rate characteristics (burstness) of each stream,Cell Delay Variation may be introduced. A typicalswitch will have less than 100 microsecond of jit-ters, and will never exceed the maximum of 250microsecond.

(2) Packetization and Depacketization Delay.Pack-etization and depacketization of AAL5 CS-PDU,and ATM may cause jitters as well since there willbe buffering and processing steps in these mod-ules. If using the MPEG-2 over AAL5 mappingin the way that is described before, the CDV shallbe in the order of one ATM cells, i.e., about 50microsecond for 7.5 Mbps virtual channel.

(3) Physical Layer Delay.The line jitters of the Phys-ical Medium Dependent (PMD) layer is usuallyvery small (refer to Bellcore specification), forSONET transmission convergence sublayer, celldelay variation can be introduced through the fram-ing process. For STS-1 with 3 column of overhead,CDV in the order of 0.46 microsecond may exist,which is very small and can be neglected.

Some of the specific requirements for MPEG-2 overATM include:

R1: The total amount of CDV that the receiver shallhandle is 1 minisecond.

R2: The clock recovery of MPEG-2 PCRs shall achieve27 MHz with+3 ppm to−3 ppm accuracy.

R3: The maximum time that the local clock locks intotimestamp shall be less than 1 second.

Another factor that may impact the CDV is the burstdata rate. Typically, this is caused by the multiplex-ing of the CBR (Constant Bit Rate) MPEG service bitstreams with other bursty data streams in the switchsystem. The burstness can be specified as the maxi-mum and minimum bit rate during certain time interval,

P1: KCU


264 Mao

Figure 11. Cell delay variation handling for MPEG-2 services.

Rmax and Rmin. The burst rate characteristics mainlydetermine the FIFO size in the receiver.

R4: The receiver shall handle the burst cell rate of withmaximum of 8 back to back cells. i.e., from 0 to 8times the normal cell rate.

A cell delay variation (CDV) process can be illus-trated in Fig. 11.

Its functions can be explained in the following:

(1) The FIFO can be used to buffer any number ofATM cells, depending on the burstness of the data.The ATM cells come at burst rate ofRmax and willbe stored in minimum of 8 cells.

(2) The FIFO status is monitored, once it reaches cer-tain level, the data will be read out at constant rateRout to the MPEG decoder.

(3) If the FIFO is empty at any time, the Data Validwill be controlled such that MPEG decoder doesnot receive any data.

(4) The specific design of FIFO and buffer manage-ment algorithm will be derived based on the as-sumption on the ATM cell traffic and CDV as wellas the burstness of data (Rmin, Rmax).

3.4. ATM and MPEG-2 DSM-CC Signaling

For delivering interactive MPEG-2 video services overATM network, control signaling flows are needed to es-tablish or delete end-to-end interactive sessions as well

Figure 12. Signaling relationship diagram for a typical SDV archi-tecture.

as the required network resources (bandwidth, CDV re-quirement etc.) to support those sessions. The sessionand resource management protocol are being standard-ized in the ISO MPEG-2 Digital Storage Media—Command and Control (DSM-CC) group.

An end-to-end session/connection signaling archi-tecture for ATM based Switched Digital Video net-work are shown in Fig. 12. The session manager is incompliance with DSM-CC standard to handle the ses-sion signaling messages from/to the VIU and VIP. Italso interfaces with connection managers for managingthe corresponding connection resources in both ATMbackbone network and ATM access network. More de-tailed signaling flow for User-Network signaling can befound in Fig. 13.

By using ATM all the way to the home, it usu-ally does not eliminate the need for Video Dial Tone(VDT) session management. ATM Q.2931 signalingonly deals with connection set-up which can be used forATM transport connection between server and VDT ac-cess network. Additional session management of VDTaccess network (from headend to home) can use DSM-CC (Digital Storage Media—Command and Control)of MPEG as shown in Fig. 13.

4. Interactive Video Network Architectures

In this section, two types of access network architec-tures and the design of interactive video applicationsover such networks are discussed:

— Fiber to the Curb (FTTC) access network;— Hybrid Fiber Coax (HFC) access network.

It is important to notice that the focus of this dis-cussion is on the system requirements from access net-work aspect for the overall MPEG service delivery overATM. It is not the intention of this paper to design the

P1: KCU



Figure 13. An example of session/connection signaling flow for session set-up.

access network, rather our focus will be on the end toend system architecture.

4.1. Fiber To The Curb (FTTC) Access Network

The FTTC access network solution shown in Fig. 14 in-cludes the Host Digital Terminal (HDT) and the OpticalNetwork Unit (ONU) that have the following features:

1. Support SONET OC-3c and OC-12c interface withthe broadband ATM switches.

2. Support up to 64 OC-3 single fiber 8 or 16 homeONUs.

3. SONET OC-12c interface for broadcast and payper view services.

4. Provide 10BaseT LAN interface for ATM/AAL5termination for control signaling messages from/tosession manager.

Figure 14. A typical FTTC access network architecture.

5. Provide element manager for access node networkmanagement.

6. ATM downstream routing and upstream multiplex-ing between HDTs and ONUs.

7. Support 8 or 16 home per ONU.8. ONU has 155 Mbps OC-3 bi-directional optical

interface with HDT.9. ONU support downstream QPSK modulation

(51.84 Mbps) and upstream QPSK demodulation(19.44 Mbps).

10. Support CATV overlay.

4.2. Hybrid Fiber Coax (HFC) Access Network

Overall system requirements and architecture on ATMdelivery of interactive video services over HFC are dis-cussed in this section.

4.2.1. System Architecture.The physical distributionnetwork for ATM to the home can be based on ei-ther HFC or FTTC architecture. The main advantageof introducing ATM into HFC is that it can provide acommon and integrated transport protocol for voice,data, and video and deliver them all the way to thehome. While voice over ATM is still in its early stage,it’s structure is a more convenient way to carry tele-phony than by MPEG. An example of this is in thetransfer of telephony signaling and data information,such as with ATM’s data networking capability. MPEGdoes not conveniently support this feature. In addition,

P1: KCU


266 Mao

ATM provides a common protocol for LAN and WANapplications. Perhaps one of the most important pointis that ATM over HFC will provide a network migra-tion path towards integrated service to the home in thefuture.

In most of the current HFC networks, ATM isonly used for transporting information from Video In-formation Provider (VIP) to the Integrated TransportEncrypted Multiplexer (ITEM) in the headend. EachITEM receives one 155 Mbps OC-3c stream via aSONET interface. The ATM protocol is used to encap-sulate the MPEG transport stream via the AAL5 adap-tation layer. Each ITEM reassembles the AAL5-PDUsbased on a set of VC values determined from the ac-cess subnetwork element manager (ASEM). The result-ing information is multiple MPEG-2 transport streamswhich are re-multiplexed into a single MPEG-2 trans-port stream and then encrypted. In this scenario, all theservices (e.g., video, data) are carried on the MPEG-2transport and transmitted all the way to the home. Ef-fectively, the ATM layer is processed and stripped bythe ITEM at the headend. Because the service is pro-vided on a shared medium it needs to be delivered se-curely (encrypted) to prevent loss of revenue.

Transmission of end to end ATM over HFC wouldenable ATM cells to be originated from the VIP sourceand transmitted all the way to the home through theHFC access network as shown in Fig. 15. This conceptwould impact the current HFC headend and set-topterminals in the following way:

• In the headend, the ISEM (Integrated Service En-cryption Modulator) is used instead of the ITEM.The ATM structure will be kept during the re-multiplexing stage. Several ATM streams with dif-ferent VCs would be multiplexed into one ATMstream. The ATM AAL5 reassembly function willno longer be needed (but the cost of performingthis function is shifted to the set-top, as we will see

Figure 15. An end to end ATM based two way HFC system archi-tecture.

later). Each output of the ISEM would be one ATMstream with multiple VCs and each VC carries asingle MPEG-2 transport stream. Adjustment of theMPEG-2 Program Association Table (PAT) and Pro-gram Map Table (PMT) is no longer necessary.• The encryption process in the headend would be

modified to process the ATM streams rather thanMPEG streams. The 64-QAM modulation in theheadend should also be modified to handle ATM cellsrather than MPEG-2 packets.• In the set-top terminal, a new Network Interface

Module (NIM) would be designed to include an ATMSAR (Segmentation and Reassembly) functionalblock that will reassemble the MPEG-2 transportpackets from the ATM/AAL5 streams coming fromthe output of the demodulation/decryption module.Since the MPEG-2 program map information is perVC basis, channel acquisition would be performedby VC selection in the ATM SAR in conjunctionwith PAT and PMT processing in the MPEG trans-port layer. In addition, the 64-QAM demodulatorand the decryption unit in the NIM should handleprogrammable block size since the modulation andencryption have been done on ATM streams ratherthan MPEG-2 transport streams directly.

One important key module of the ATM over HFCto the home architecture is ISEM (Integrated ServiceEncryption Multiplexer). The functional requirementsof the ISEM are described in the following section.

4.2.2. Headend Module Functional Requirements.The ISEM (Integrated Service Encryption Multiplexer)in the HFC headend module should perform the follow-ing functions:

— Receive one OC-3 input with single MPEG pro-gram stream per VPI/VCI;

— One to five ports ATM remultiplexing supportingup to 16000 Virtual Channels;

— Bandwidth management and null cell multiplexing;— Minimum jitters introduction (<50 ns is desired);— Five TAXI output each with 27 Mbps.

The system design issues should be considered for theISEM. Among them, several key aspects are discussedin the following:

(1) Virtual Channel Mapping and Multiplexing.Thevirtual channel (VPI and VCI) mapping into one of the

P1: KCU



five outlets is determined by the Header/Link transla-tion table configured by the Network Controller. EachVC carries a specific MPEG transport stream with con-stant bit rate. The Network Controller needs to commu-nicate with the video session manager regarding to thisresource such that the total bit rate of the streams go-ing into each output link will not exceed 27 Mbps. TheISEM is unaware of the bit rate of each VC although itcan estimate it through PCRs in MPEG stream. This isnot desired since parsing into the MPEG level increasesthe complexity significantly. A multiplexing schemethat requires no PCR parsing and provides minimumaverage cell delay variation is proposed:

• Step 1.ATM cells from 155 Mbps input stream withVPI/VCIs specified in the header/link translation ta-ble is routed into appropriate FIFO of the output linkwith minimum delay.• Step 2. Each output link will output ATM cells at

the bit rate of 27 Mbps. It will check its FIFO at thebeginning of each output ATM cell slot.• Step 3.If the FIFO contains more than 53 bytes (cell

size), it will be output into the link. Otherwise, anidle ATM cell will be inserted.

(2) Cell Loss/Insertion. In the ISEM, it is possiblethat temporarily too many cells are destined for thesame link. The queue can not store all of them, there-fore cells may be lost. Typical cell loss probability canrange from 10−8 to 10−10. This is expected to haveonly limited impact on the MPEG video delivery.

It is also possible that ATM cells are internally mis-routed in the ISEM so that they arrive erroneously toanother output link. The probability of cell insertion isusually kept at 1000 times better than the cell loss rate.

(3) Cell Delay Variation (Jitters). ISEM basicallyperforms ATM re-multiplexing, cell delay variation (orjitters) can be introduced in the process. Typical delay(latency) can be 10 to 1000 microsecond, with a jittersof a few 100 microsecond or less. It should be a strictrequirement that the jitters in the ISEM be as small aspossible.

The ISEM, on the other hand, does not correct thejitters introduced by the ATM transport network in thebackbone. (ITEM in the regular HFC does perform tim-ing recovery and correct the network jitters). There-fore, ISEM passes the jitters to the set-top terminal.Up to 1 minisecond of total jitters can be expected bythe set-top terminal. The set-top terminal should be

able to handle this much larger jitter value comparedwith regular HFC environment.

(4) Encryption. ISEM should perform encryption onATM cells (53 bytes) instead of MPEG transport pack-ets (188 bytes). The conditional access informationsuch as ECM and EMM will not be carried over MPEGProgram Specific Information (PSI). It is still understudy on how the conditional access scheme be modi-fied to fit into the ATM cells.

(5) Forward Error Correction (FEC) for Modulation.The current HFC network has QAM Mod/Mux that hasForward Error Correction (FEC) which is based on theblock size of 188 bytes (MPEG-2 transport packet).In the ATM over HFC architecture, the FEC size hasto be changed to 53 bytes of cell size. It may also bepossible to keep the 188 bytes of block size but de-couple the synchronization requirement of FEC to theMPEG transport packets.

5. Conclusions

In this paper, the system architecture and related designissues involving broadband network delivery of ATMbased interactive video are discussed. The integrateddigital multimedia video service can be delivered viadifferent network media such as Hybrid Fiber Coax(HFC) and Fiber to the Curb (FTTC). AsynchronousTransfer Mode (ATM) can be used as an effective trans-port mechanism for the digital video services, suchas MPEG-2. Both the lower layer physical networktopology/characteristics and network protocols imposespecial technical constraints on the overall digital videosystem design. Key MPEG over ATM issues are ana-lyzed. The system issues on network delivery of digitalvideo discussed in this paper include: (1) Overall net-work impact and system protocol stack for HFC andFTTC video delivery (2) Interactivity of digital videoand its signaling (3) Quality of Service (QoS) impacton digital video coding algorithm. Future research canbe expanded on those topics.

References

1. Bellcore Generic Requirements GR-253-CORE, “Synchronousoptical network: SONET transport systems: Common genericcriteria,” Issue 1, Dec. 1994.

2. M. De Prycker,Asynchronous Transfer Mode, Solution for Broad-band ISDN, 2nd edition, Ellis Horwood, 1993.

P1: KCU


268 Mao

3. ATM Forum Specification, “ATM user-network interface specifi-cation,” Version 3.0.

4. ISO/IEC, JTC1/SC29/WG11 13818-1, “Information technol-ogy— generic coding of moving pictures and associated audio:System,” Nov. 1994.

5. ISO/IEC, JTC1/SC29/WG11 13818-6, “MPEG-2 digital storagemedia command and control 2nd working draft,” March 1995.

Weidong Mao is currently Director of Video Service Platform ofNext Level Communication, a subsidiary of General Instrument

Corporation, the leading telecommunication and cable/satellite com-pany for delivery digital video, data, and voice. He has been work-ing in the areas of digital video compression, digital video broadcastand interactive applications, broadband network architecture usingFiber to the Curb (FTTC) or Hybrid Fiber Coax (HFC) technologies,and ATM. Before joining General Instrument in 1994, he worked asSenior Member Research Staff at Philips Labs of Philips Electron-ics U.S. for four years on the topics of MPEG2, digital compres-sion, HDTV, and video communications. He is an active memberof MPEG, ANSI, DAVIC, and ATM Forum. Dr. Mao received hisM.A. and Ph.D. in Electrical Engineering from Princeton Universityin 1990 and B.S. from Beijing University, Beijing, China in 1986.He has numerous technical publications and serveral patents.

Documents

Broadband Network Delivery of Interactive Digital Video Using ATM