En last but not least wil ik mijn vrouw Ellen bedanken. Zij stimuleerde en motiveerde me gedurende de hele studietijd bij Groep-T

VOIP VIA HET TELENET KABELNETWERK

I

Woord vooraf Dit werk is het resultaat van ons ondernemingsproject dat we het voorbije jaar uitwerkten voor Groep-T. Het project is ontstaan uit interesse voor Voice over IP en uit praktijkervaringen bij mijn werkgever Telenet. Met dit project ronden we onze ACE Telecommunicatie studie te Leuven af. Het resultaat zou nooit hetzelfde geweest zijn zonder de hulp en ondersteuning van een aantal mensen die hun steentje, sommigen een menhir, hebben bijgedragen tot dit werk. Via deze weg wil ik hen dan ook bedanken voor hun inzet. Eerst en vooral wil ik promotor Koen Depovere en co-promotor Bart Provoost bedanken. Dankzij hun begeleiding, coaching en inzichten bleef ik altijd op het goede spoor. Ik wil ook nog alle leraren bij Groep-T bedanken wiens lessen de voorbije drie jaar rechtstreeks en onrechtstreeks hebben bijgedragen tot de verwezelijking van ons ondernemingsproject. Het zijn interessante jaren geweest in Leuven, vaak met veel plezier, soms lastig, maar uiteindelijk altijd wel de moeite waard. En last but not least wil ik mijn vrouw Ellen bedanken. Zij stimuleerde en motiveerde me gedurende de hele studietijd bij Groep-T. Aan allen een woord van dank!

Steven Vlemincx Groep-T Graduaat Telecommunicatietechnieken

Promotor: Koen Depovere Copromotor: Bart Provoost


II

Inhoudstafel Woord vooraf ...................................................................................................................................... I Inhoudstafel........................................................................................................................................II Lijst met gebruikte afkortingen........................................................................................................ VI Lijst met figuren.............................................................................................................................VIII 1.

Inleiding ..................................................................................................................................... 1 1.1.

Telenet ............................................................................................................................................ 1

1.2.

Het hybride fiber coax netwerk (HFC) ........................................................................................... 1

1.3. Onderscheid tussen circuitswitched en packetswitched.................................................................. 3 1.3.1. Circuitswitched .......................................................................................................................... 3 1.3.2. Packetswitched........................................................................................................................... 3 1.4.

Euro-DOCSIS ................................................................................................................................. 4

1.5. Euro-PacketCable ........................................................................................................................... 4 1.5.1. Waarom Euro-PacketCable? ...................................................................................................... 5 1.5.2. Euro-PacketCable componenten ................................................................................................ 5 1.5.3. MTA........................................................................................................................................... 6 1.5.4. CM ............................................................................................................................................. 6 1.5.5. CMTS......................................................................................................................................... 6 1.5.6. CMS ........................................................................................................................................... 7 1.5.7. PVG ........................................................................................................................................... 7 1.5.8. OSS Back Office........................................................................................................................ 7 1.6. Protocols ......................................................................................................................................... 9 1.6.1. DHCP: Dynamic Host Configuration Protocol.......................................................................... 9 1.6.2. TFTP: Trivial File Transport Protocol ..................................................................................... 10 1.6.3. COPS: Common Open Policy Service..................................................................................... 10 1.6.4. RTP: Real Time transportprotocol ........................................................................................... 10 1.6.5. MGCP: Media Gateway Control Protocol ............................................................................... 10 1.6.6. NCS: Network-based Call Signaling ....................................................................................... 10 1.6.7. SIP: Session Initiation Protocol ............................................................................................... 11 1.6.8. SS7: Signaling System 7 .......................................................................................................... 11

2.

Provisioning ............................................................................................................................. 12 2.1. DOCSIS ........................................................................................................................................ 12 2.1.1. Ranging.................................................................................................................................... 12 2.1.2. Registratie ................................................................................................................................ 13 2.2. Euro-PacketCable ......................................................................................................................... 13 2.2.1. Testopstelling........................................................................................................................... 14 2.2.2. DHCP....................................................................................................................................... 14 2.2.3. Aanvragen KDC IP adres......................................................................................................... 17 2.2.4. Verkrijgen van tickets bij de KDC........................................................................................... 18 2.2.5. Opvragen configuratiefile ........................................................................................................ 20 2.2.6. Het afronden van het registratieproces..................................................................................... 22

3.

Configuratiefile ........................................................................................................................ 25 3.1. Algemeen...................................................................................................................................... 25 3.1.1. TLV’s....................................................................................................................................... 25 3.1.2. Maken van een configuratiefile................................................................................................ 26 Steven Vlemincx

Groep-T Graduaat Telecommunicatietechnieken



III

3.2. Modem configuratie...................................................................................................................... 27 3.2.1. Algemeen ................................................................................................................................. 27 3.2.2. De configuratiefile ................................................................................................................... 28 3.3.

4.

MTA configuratie ......................................................................................................................... 28

Het opzetten van een gesprek................................................................................................... 29 4.1. NCS Signalisatie........................................................................................................................... 29 4.1.1. Wat zijn events en hoe worden ze weergegeven...................................................................... 30 4.1.2. Een voorbeeld .......................................................................................................................... 31 4.2.

RTP............................................................................................................................................... 31

4.3. Praktische bespreking ................................................................................................................... 31 4.3.1. Algemeen ................................................................................................................................. 32 4.3.2. Gesprek van MTA naar MTA .................................................................................................. 32 4.3.3. Gesprek van PSTN naar MTA ................................................................................................. 32 4.3.4. Besluit ...................................................................................................................................... 33

5.

Hoe telefoneer ik naar een IP adres?........................................................................................ 34

6.

Quality of Service .................................................................................................................... 36 6.1.

Waarom?....................................................................................................................................... 36

6.2. Service flows ................................................................................................................................ 37 6.2.1. Dynamische service flows : UGS ............................................................................................ 37 6.2.2. QoS in de configuratiefile ........................................................................................................ 38 6.2.3. Opzetten van service flows ...................................................................................................... 39 6.3. Praktisch ....................................................................................................................................... 44 6.3.1. Normaal gesprek ...................................................................................................................... 44 6.3.2. Netwerk overbelast .................................................................................................................. 45 6.3.3. Classifiers zijn omgewisseld.................................................................................................... 47 6.3.4. Verkeerde service flow naam................................................................................................... 47

7.

Capaciteitsplanning.................................................................................................................. 48 7.1. Theoretisch ................................................................................................................................... 49 7.1.1. Downstream ............................................................................................................................. 49 7.1.2. Upstream.................................................................................................................................. 49 7.2. Praktisch ....................................................................................................................................... 50 7.2.1. Test setup ................................................................................................................................. 50 7.2.2. Testen....................................................................................................................................... 52 7.2.3. G729......................................................................................................................................... 56 7.2.4. Besluit ...................................................................................................................................... 58

8.

Echo ......................................................................................................................................... 59 8.1. Theoretisch ................................................................................................................................... 59 8.1.1. Algemeen ................................................................................................................................. 59 8.1.2. Soorten echo ............................................................................................................................ 60 8.1.3. Belangrijke termen................................................................................................................... 60 8.1.4. Overzicht.................................................................................................................................. 63 8.1.5. Invloed op echo........................................................................................................................ 63 8.1.6. Echo cancellers ........................................................................................................................ 64 8.2. Praktisch ....................................................................................................................................... 65 8.2.1. Hoe testen?............................................................................................................................... 65 8.2.2. Opmeten van het loss plan ....................................................................................................... 66 8.2.3. Reconstructie van de RTP stream ............................................................................................ 66 8.2.4. Logs nemen op de MTA .......................................................................................................... 66 Steven Vlemincx




IV

8.3. Echo hoorbaar aan B zijde ............................................................................................................ 68 8.3.1. Probleemanalyse ...................................................................................................................... 68 8.3.2. Conclusie ................................................................................................................................. 71 8.4. Echo hoorbaar aan A zijde............................................................................................................ 71 8.4.1. Gesprek MTA naar MTA......................................................................................................... 71 8.4.2. Gesprek MTA naar PSTN........................................................................................................ 72

9.

Uitwerken van enkele praktisch problemen ............................................................................. 76 9.1. Disconnected from CMS .............................................................................................................. 76 9.1.1. Wat? ......................................................................................................................................... 76 9.1.2. Oorzaken.................................................................................................................................. 76 9.1.3. Oplossingen ............................................................................................................................. 77 9.2. CLIP werkt niet meer na upgrade ................................................................................................. 78 9.2.1. Wat? ......................................................................................................................................... 78 9.2.2. Oorzaak.................................................................................................................................... 79 9.2.3. Oplossing ................................................................................................................................. 79 9.3. Omschakelen Pulse / Toon ........................................................................................................... 81 9.3.1. Wat? ......................................................................................................................................... 81 9.3.2. Oplossing ................................................................................................................................. 81

10.

Vergelijking Skype, SIP en Telenet VoIP............................................................................ 83

10.1. Skype ............................................................................................................................................ 83 10.1.1. het Skype netwerk ............................................................................................................... 83 10.1.2. Skype componenten ............................................................................................................ 84 10.2. SIP ................................................................................................................................................ 85 10.2.1. Wat is SIP precies ............................................................................................................... 86 10.2.2. Hoe SIP werkt? ................................................................................................................... 87 10.2.3. Uitdagingen:........................................................................................................................ 88 10.3.

11.

Skype, SIP en Telenet VoIP ......................................................................................................... 89

Besluit .................................................................................................................................. 90

Literatuurlijst....................................................................................................................................... I Bijlage A: Provisioningsflow Euro-PacketCable...............................................................................II Bijlage B: TLV overzicht..................................................................................................................III Bijlage C : CM configuratie file...................................................................................................... VII Bijlage D: MTA configuratie file.......................................................................................................X Bijlage E : Call-setup van MTA naar MTA..................................................................................... XI Bijlage F: Call-setup van PSTN naar MTA ................................................................................. XXII Bijlage G : Traffic generator ....................................................................................................XXVIII Bijlage H : Call generator ........................................................................................................XXXIV Bijlage I : Gebruik van sniffer tools.........................................................................................XXXVI Bijlage J : Call feature switch ......................................................................................................... LII




V

Bijlage K: Een kort algemeen overzicht van VoIP ........................................................................LIV




VI

Lijst met gebruikte afkortingen AC ANP AP AS ASCII ATM BIPT CA CATV CM CMTS CODEC COPS CP CPE DECT DES DHCP DNS DOCSIS DSA DSC DSD DSP DTMF E-MTA ERL ERLE FEC FTTH FQDN FTP GC GSM GWC HFC HTML HTTP IETF IP IPDC ITSP ITU KDC LAN MAC MAP MGCP MIC MPEG MTA

Announcement Controller Announcement Player Authentication Package Authentication Server American Standard Code for Information Interchange Asynchronous Transfer Mode (Protocol) Belgisch Instituut voor Postdiensten en Telecommunicatie Call Agent Community Antenna Television Cable Modem Cable Modem Termination System COder DECoder of Compressor/Decompressor Common Open Policy Service Convolution Processor Customer Premises Equipment Digital Enhanced Cordless Telecommunication Data Encryption Standard Dynamic Host Configuration Protocol Domain Name Server Data Over Cable Service Interface Specification Standard Dynamic Service Addition Dynamic Service Change Dynamic Service Deletion Digital Signal Processor Dual Tone Multi-Frequency Embedded Multimedia Terminal Adaptor Echo Return Loss Echo Return Loss Enhancement Forward Error Correction Fiber to the Home Full Qualified Domain Name File Transfer Protocol Gate Controller Global System for Mobile Communications Gateway Controler Hybrid Fiber Coax (Netwerk) Hypertext Markup Language Hypertext Transfer Protocol Internet Engineering Task Force Internet Protocol IP Device Control Internet Telephony Service Provider International Telecommunications Union Key Distribution Center Local Area Network Media Access Control Upstream channel allocation MAP Media Gateway Control Protocol Message Integrity Check Moving Picture Experts Group Multimedia Terminal Adaptor Steven Vlemincx




NCS NLP OSS P2P PDP PEP PID PSTN PVG QAM QoS RFC RKS RLR RSIP RTP Rx SFID SGCP SID SIP SLR S-MTA SNMP SNR SS7 TELR TFTP TGS TGT TLV ToD Tx UAC UAS UCD UGS VoIP WWW

VII

Network-based Call Signaling Nonlineair Processor Open System Services Peer to Peer Policy Decision Point Policy Enforcement Point Payload Identifier Public Switched Telephone Network Packet Voice Gateway Quadrature Amplitude Modulation Quality of Service Request For Comment Record Keeping Server Receive Loudness Rating Realm Specific IP Real-time Transport Protocol Receive Service Flow Identifier Simple Gateway Control Protocol Service Identifier Session Initiation Protocol Send Loudness Rating Standalone Multimedia Terminal Adaptor Simple Network Management Protocol Signal to Noise Ratio Signaling System 7 Talker Echo Loudness Rating Trivial File Transfer Protocol Ticket Granting Server Ticket Granting Ticket Type / Length / Value Time Of Day Transmit User Agent Client User agent server Upstream Channel Discriptor Unsolicited Grant Service Voice over Internet Protocol Word Wide Web




VIII

Lijst met figuren Figuur 1: Telenet backbone ............................................................................................................... 2 Figuur 2: Euro-PacketCable: Referentie Architectuur...................................................................... 5 Figuur 3: Euro-PacketCable: gebruikte protocols ............................................................................ 9 Figuur 4: Sniffer testopstelling ........................................................................................................ 14 Figuur 5: HEX editor van HDD software........................................................................................ 25 Figuur 6: voorbeeld DOCSIS editor ................................................................................................ 27 Figuur 7: Service flows .................................................................................................................... 37 Figuur 8: Call setup......................................................................................................................... 40 Figuur 9: Call setup, Dynamic Service Addition ............................................................................. 41 Figuur 10: Call setup, Dynamic Service Change ............................................................................ 43 Figuur 11: Call setup, Dynamic Service Deletion ........................................................................... 44 Figuur 12: Test setup met een call generator en een traffic generator ........................................... 51 Figuur 13: SmartCounters, QPSK, zonder gesprekken .................................................................. 53 Figuur 14: SmartCounters, QPSK, met 6 gesprekken ..................................................................... 54 Figuur 15: SmartCounters, 16 QAM, zonder gesprekken................................................................ 55 Figuur 16: SmartCounters, 16 QAM, met 6 gesprekken.................................................................. 56 Figuur 17: SmartCounters, 16 QAM, met 6 gesprekken met de G729 codec ................................. 58 Figuur 18: Netwerkoverzicht, analoog en digitaal .......................................................................... 59 Figuur 19: Echo, een overzicht........................................................................................................ 63 Figuur 20: Echo, waar mogelijk ...................................................................................................... 64 Figuur 21: Goldwave, signaal in de downstream richting .............................................................. 69 Figuur 22: Upstream signaal in functie van de tijd ......................................................................... 69 Figuur 23: Goldwave, echosignaal................................................................................................. 70 Figuur 24: Testopstelling DOCSIS tracer ....................................................................................... 72 Figuur 25: originele signaal en echosignaal ................................................................................... 73 Figuur 26: Goldwave, piek van het origineel signaal...................................................................... 73 Figuur 27: Goldwave, piek van het echo signaal............................................................................. 74 Figuur 28: PacketACE: boomstructuur MIBs ................................................................................. 82 Figuur 29: Skype netwerk overzicht................................................................................................. 84 Figuur 30: SIP basis architectuur en werking ................................................................................. 86 Figuur 31: SIP call setup ................................................................................................................. 88 Figuur 32: Smartbits traffic generator, startscherm................................................................XXVIII Figuur 33: Smartbits traffic generator, connecteren ..................................................................XXIX Figuur 34: Smartbits traffic generator, transmit setup slot1 ......................................................XXIX Figuur 35: Smartbits traffic generator, overige slots ..................................................................XXX Figuur 36: Smartbits traffic generator, layer 3 setup, port 1 .....................................................XXXI Figuur 37: Smartbits traffic generator, layer 3 setup, port 1 .....................................................XXXI Figuur 38: Smartbits traffic generator, configuratiefile........................................................... XXXII Figuur 39: Smartbits traffic generator, overzicht verzonden en ontvangen data ....................XXXIII Figuur 40: opstelling met DOCSIS-tracers .............................................................................XXXVI Figuur 41: DOCSIS tracer, constellatie diagram.................................................................. XXXVII Figuur 42: DOCSIS tracer, upstream constellatie diagram, QPSK ..................................... XXXVIII Figuur 43: DOCSIS tracer, upstream constellatie diagram, 16QAM .....................................XXXIX Figuur 44: DOCSIS tracer, filterinstellingen ................................................................................. XL Figuur 45: DOCSIS tracer, maken van een trace..........................................................................XLI Figuur 46: ST261Viewer...............................................................................................................XLII Figuur 47: ST261Viewer, PCAP file........................................................................................... XLIII Figuur 48: Ethereal, voorkeuren ................................................................................................ XLIV Figuur 49: Ethereal, Protocols ................................................................................................... XLIV Figuur 50: Ethereal, DOCSIS frames.......................................................................................... XLV Steven Vlemincx Groep-T Graduaat Telecommunicatietechnieken



IX

Figuur 51: Ethereal, filter........................................................................................................... XLVI Figuur 52: Ethereal, analyse menu............................................................................................XLVII Figuur 53: Ethereal, protocol selecteren...................................................................................XLVII Figuur 54: Ethereal, Stream analysis ...................................................................................... XLVIII Figuur 55: Ethereal, Delay en Jitter........................................................................................ XLVIII Figuur 56: Ethereal, Payload ..................................................................................................... XLIX Figuur 57: Goldwave, afspelen up- en downstream .......................................................................... L Figuur 58: Goldwave, Tool menu ...................................................................................................... L Figuur 59: Goldwave, Bars en Spectrum..........................................................................................LI Figuur 60: Call feature switch in de MIB boomstructuur .............................................................. LII




1

Het is eigen aan het gekozen onderwerp PacketCable dat er een typisch Engels jargon wordt gebruikt in onze tekst. De grote hoeveelheid Engelse terminologie wordt alleen vertaald wanneer er een goed gangbaar equivalent Nederlands begrip voor is. In Vlaanderen zijn er drie breedbandige concurrerende infrastructuren. Deze zijn afhankelijk van de drie typen toegangsnetwerken, namelijk de kabel (Coax), Digital Subscriber Line (xDSL) en Fiber to the Home (FTTH). Van alle typen toegangsnetwerken worden deze typen netwerken beschouwd als de belangrijkste kandidaten voor breedband tot in de particuliere woning. Aangezien we beiden bij Telenet werken hebben we het geluk om aan de bron te zitten en een ondernemingsproject te kunnen maken over één van de drie grote toegangsnetwerken. Wij zelf willen graag dieper ingaan op PacketCable. Het is een nieuwe standaard en Telenet is bij de eerste operatoren in Europa om zijn PacketCable platform volledig operationeel te hebben. De doelstelling van dit werk is dan ook om de lezer inzicht te geven in Euro-PacketCable, de Europese variant van PacketCable en de Voice over IP diensten die daarmee samengaan.

1. Inleiding 1.1. Telenet Het ondernemingsproject wordt ondersteund door onze werkgever Telenet. Vooraleer we verder gaan met de rest van onze scriptie, geven we eerst een korte introductie . Telenet, opgericht in 1996, is een kabelnetwerkoperator die telefonie, breedbandinternet en televisiediensten aanbiedt aan particulieren en bedrijven. Het bedrijf is gevestigd te Mechelen. Sinds 1997 bouwde Telenet de Vlaamse kabelnetwerken om van éénwegsdistributie naar tweewegsinteractiviteit. 52.000 kilometer coaxkabel vormt de basis van het telecommunicatienetwerk. De backbone van 1.200 kilometer glasvezelkabel verbindt de omgebouwde kabelnetwerken van Telenet met vijf schakelcentrales en het netwerkoperatiecentrum. De netwerken bevatten zo’n 9000km toegangsglasvezel. Zo kon op 1 augustus 1997 gestart worden met het aanbieden van breedbandinternetdiensten en op 1 januari 1998 – na het vrijmaken van de telecommarkt- met het aanbieden van telefoniediensten. Ondertussen is Telenet reeds uitgegroeid tot een telecomoperator waarmee rekening moet gehouden worden op de Belgische markt. Door de overname, op 19 juli 2002, van de kabelnetwerken van de gemengde intercommunales, werd de basis gelegd voor de uitbouw van een geïntegreerde dienstverlening (Triple Play). In Vlaanderen biedt Telenet gezinnen via de kabel internet, telefonie en analoge kabeltelevisiediensten aan. Tevens is men ervan overtuigd dat Vlaanderen uniek geplaatst is om een leidende rol te spelen, binnen Europa, om het medium televisie interactief te maken door middel van digitale televisie. Dit is dan ook het project voor 2005 binnen het bedrijf. Voor bedrijven richt Telenet zich nu ook naar Brussel, Wallonië en Luxemburg. Om deze markt te bedienen maken ze gebruik van glasvezel en DSL-diensten.

1.2. Het hybride fiber coax netwerk (HFC) Vooraleer Telenet bestond was er in Vlaanderen al transmissie over het kabelnetwerk. Dit was het kabeltelevisienetwerk van de intercommunales. Het doel was enkel het verdelen van Tv-signalen, vanuit een centraal punt naar een groot aantal gebruikers, de gezinnen. De signaaltransmissie was dus zuiver éénrichtingsverkeer van het centrale punt, het kopstation van de kabelmaatschappij, naar de gezinnen. Signaaltransmissie in de andere richting was niet noodzakelijk en werd dus ook niet voorzien. Bij het onstaan van Telenet moesten de netten worden omgebouwd naar 2 richtingen om internet en telefonie mogelijk te maken. Steven Vlemincx Groep-T Graduaat Telecommunicatietechnieken


2


Wat is er nodig om van het distributieve kabeltelevisienetwerk een breedbandig telecommunicatienetwerk te maken? Telecommunicatie, bijvoorbeeld telefonie, is per definitie interactief. De twee gesprekspartners willen tegelijkertijd praten en luisteren. • • • •

Bidirectionele Communicatie: Signalen van het kopstation gaan naar de klant, omgekeerd kunnen nog geen signalen doorgestuurd worden. Er is dus nood aan een terugwegpad dat de signalen van de gebruiker naar het kopstation transporteert. Bandbreedte: Bij het surfen op Internet is een voldoende snelheid gewenst wil de gebruiker niet geërgerd aan zijn PC zitten. De coax heeft uiteraard een grote bandbreedte doch deze moet verdeeld worden over een groot aantal gebruikers vandaar de term "shared". Onderlinge verbinding: Alle aparte kabeltelevisienetwerken moeten aan elkaar verbonden worden tot één groot netwerk. In geval van Telenet gebeurt dit via de ruggengraatring. Dit laat communicatie binnen ons netwerk toe. Transport van de signalen: In het geval van telefonie moet de klant de mogelijkheid hebben om nationale en internationale gesprekken te voeren. De telefoniesignalen moeten dus vanuit het kabeltelevisienet naar andere gebieden en/of operatoren kunnen verstuurd worden.

Het CATV netwerk dat voorhanden was, voldeed niet en moest aldus aangepast worden. Om tweewegcommunicatie toe te laten worden de bestaande versterkers uitgerust met een terugwegmodule. Om de beschikbare bandbreedte te vergroten wordt het netwerk opgesplitst in kleinere delen. Dit werd dan ook gedaan bij Telenet. Elk deel bedient een beperkt aantal klanten. Op deze manier kan in elk apart netwerkgedeelte de beschikbare bandbreedte verdeeld worden over het beperkte aantal gebruikers. Dit wordt ook het hergebruik van bandbreedte of "bandwith reuse" genoemd. Met een glasvezel backbone welke uit een primaire en een aantal secundaire ringen bestaat, worden de verschillende kabeltelevisienetwerken verbonden tot één groot breedbandnetwerk. Voorheen waren de nodes heel groot en waren alle gezinnen via coax verbonden. Die afstand van thuis tot een node was soms heel groot. Om breedbanddiensten te kunnen aanbieden werden alle nodes opgesplitst in verschillende kleine nodes die op hun beurt via glasvezel werden verbonden. Zo werd de maximum afstand tussen de eindgebruiker en het dichtste telenetknooppunt erg verkleind en kwam er genoeg capaciteit om breedband internet en telefonie aan te bieden. Op de backbone zijn er een aantal interconnectiepunten naar andere telecom operatoren zodat nationale en internationale trafiek mogelijk is.

Figuur 1: Telenet backbone Steven Vlemincx Groep-T Graduaat Telecommunicatietechnieken


3


1.3. Onderscheid tussen circuitswitched en packetswitched Iedereen is wel vertrouwd met de klassieke telefoon. We tonen even kort het verschil aan tussen de klassieke telefonie en de packetswitched technologie, waar ook Euro-PacketCable gebruik van maakt.

1.3.1. Circuitswitched Het PSTN-netwerk is een zogenaamd circuitswitched netwerk. Dit houdt in dat voor de duur van een telefoongesprek een vaste verbinding wordt opgezet tussen de beller en de ontvanger, van 64 Kbit/s (het spraaksignaal wordt 8000 keer per seconde met 8 bit gesampled). Gedurende het hele gesprek is deze bandbreedte gereserveerd voor dat ene gesprek en kan de lijn niet voor iets anders worden gebruikt, of er nu wel of niet wordt gesproken. Dit heeft als voordeel dat de zogenaamde 'Quality of Service' gegarandeerd is: het signaal komt (nagenoeg) altijd goed verstaanbaar aan bij de ontvanger. Dat wil zeggen, in de juiste volgorde en zonder (hoorbare) vertraging - mobiele telefonie en telefonie die deels via een satelliet verloopt even buiten beschouwing gelaten. Anders gezegd: de betrouwbaarheid van het telefoonnet is enorm hoog (hoe vaak kreeg u geen kiestoon toen u de hoorn opnam om te gaan bellen?). Dit heeft alles te maken met het feit dat het telefoonnet tientallen jaren lang is geoptimaliseerd rond de 64 Kbit/s standaard. Tegelijkertijd is het daardoor ook bijna onmogelijk geworden om op een ander principe over te stappen: de hele architectuur van het telefoonnet en alle bijbehorende randapparatuur is op deze ene standaard afgestemd.

1.3.2. Packetswitched Het Internet is wat wordt genoemd een Packetswitched netwerk. Het bestaat uit een groot aantal knooppunten, die onderling zijn verbonden. Alle informatie, of het nu spraak, tekst, beeld of muziek is, wordt opgedeeld in zogenaamde IP-pakketten. Van elk pakket is bekend waar het vandaan komt (via het afzenderadres) en waar het naar toe moet (via het bestemmingsadres). Daarnaast heeft elk pakket een volgordenummer dat de juiste plaats van het pakket in de datastroom aangeeft. Ieder pakket kan in principe afzonderlijk via een eigen route door het netwerk worden getransporteerd naar het bestemmingsadres. Op de knooppunten van het netwerk staan routers die per pakket, aan de hand van het bestemmingsadres, bepalen welke route een pakket het beste kan nemen. Een belangrijk voordeel van deze methode is dat IP-pakketten ook op de juiste bestemming aankomen als bepaalde delen van het netwerk uit de lucht zijn: de pakketjes volgen dan gewoon een andere route. Het nadeel is ook evident: pakketten kunnen wel eens niet in de juiste volgorde op het bestemmingsadres aankomen. Via het volgordenummer kan dit weliswaar weer worden rechtgezet, maar niet zonder de introductie van een zekere vertraging ('delay'). Het kost, met andere woorden, tijd om de oorspronkelijke volgorde van de pakketjes te herstellen. Gaat het om tekst of beeld (via e-mail, file transfer en dergelijke), dan is dit geen probleem: de tekst of het plaatje komt gewoon wat later aan. Spraak echter wordt al snel onverstaanbaar als de delay te groot (>250 msec) wordt. Hetzelfde geldt voor real-time video. Bij PacketCable is het belangrijk dat zeer een continu stroom van paketten is. Er bestaan ook een aantal alternatieven voor real-time communicatie over IP, namelijk voice en video over Frame Relay en ATM, beide ook packetswitched.




4

1.4. Euro-DOCSIS De in CableLabs verenigde kabelmodem leveranciers hebben er voor gekozen één standaard op te stellen voor de door hen te ontwikkelen modems. Onderdeel van deze standaard is de interoperabiliteit van de kabelmodems met de verschillende netwerkinfrastructuren. In de standaard zijn een aantal protocollen beschreven die het mogelijk moeten maken dat modems geen merkgebonden hardware meer nodig hebben. Modems die aan de DOCSIS 1.0 standaard voldoen zijn in theorie inzetbaar in elk DOCSIS goedgekeurd netwerk. Euro-DOCSIS staat voor European Data Over Cable Service Interface Specification Standard. DOCSIS heeft nog een aantal andere voordelen ten opzichte van de oude, merkspecifieke protocollen. Doordat er bij het vaststellen van de DOCSIS standaard gebruik is gemaakt van "de beste" onderdelen van alle samenwerkende kabelmodemleveranciers, biedt de DOCSIS standaard een volledig functionaliteitspakket aan, waaraan alle modems moeten voldoen. Een voorbeeld hiervan is de DES encriptie (Data Encryption Standard) die toegepast wordt op het verkeer tussen de modems, de CMTS en de RF-interface, waardoor het Internetverkeer niet meer af te tappen is. Het verschil tussen DOCSIS en Euro-DOCSIS zit hem voornamelijk in het feit dat de Amerikaanse en Europese netwerken verschillend zijn. Daarom is er een verschillende Europese standaard nodig. Euro-Docsis werd ook later ontwikkeld en hierdoor zijn er ook een aantal verbeteringen in de Europese standaard. Zo is bijvoorbeeld bij Euro-DOCSIS de downstream kanaalbreedte 1MHz groter dan bij DOCSIS. Door het complete functionaliteitspakket dat reeds aanwezig is, kunnen leveranciers zich beter concentreren op andere zaken, zoals betrouwbaarheid , snelheid of een lagere prijs. Hiermee hebben de leveranciers nog steeds een reden om te concurreren en de standaard zorgt zelfs voor een extra afzetmarkt. Telenet gebruikt momenteel de Euro-DOCSIS 1.1 standaard.

1.5. Euro-PacketCable PacketCable™ is een project van Cable Television Laboratories, Inc.(CableLabs®). Het PacketCable project is bedoeld om interface specificaties te ontwikkelen die kunnen gebruikt worden door hardware, bedoeld voor packet-based voice, video en andere high-speed multimediaservices over hybrid fiber coax (HFC) cable systems die gebruik maken van het DOCSIS protocol. Euro-PacketCable is de Europese variant, net zoals Euro-DOCSIS de Europese tegenhanger is van DOCSIS. Euro-PacketCable is primair gericht op standaardisatie van telefonie en andere real-time multimedia applicaties als bijvoorbeeld videoconferencing via HFC-netwerken door middel van VoIP binnen de Euro-DOCSIS-standaard, dat wil zeggen standaardisatie op Netwerk niveau richting Backbone. Hierin zijn ook voorzieningen getroffen voor signalering, transport met gegeven QoS1, aanvragen en toekennen van bandbreedte, databeveiliging, facturatie en andere netwerk management aspecten.

1

Quality of Service, zie hoofdstuk 6 Steven Vlemincx




5

1.5.1. Waarom Euro-PacketCable? Sinds het Internet Protocol (IP) het standaard routerringsprotocol voor pakketdatanetwerken is geworden hebben we een enorme evolutie meegemaakt in communicatieservices en -applicaties. Het grootste bewijs van deze evolutie is de exponentiële groei van het World Wide Web, het wijdverspreide gebruik van e-mail, chatgroups, filesharing programma’s, muziek en video. Nieuwe vormen van IP gebaseerde toepassingen duiken meer en meer op in onze samenleving, waaronder IP gebaseerde set top boxen en IP spraak en video telefoons. Door de enorme ontwikkeling van dit IP data netwerk, gekoppeld aan het alsmaar stijgend aantal gezinnen die toegang hebben tot dit netwerk kwam er vraag naar een omgeving die geïntegreerde spraak en data diensten kon aanbieden over een gewoon breedband kabel netwerk met een IP backbone. Waar het initieel bij VoIP de bedoeling was om vooral de hoge gesprekskosten bij internationale telefoongesprekken te kunnen drukken is de technologie nu zo kwalitatief hoogstaand geworden dat ze kan vergeleken worden met de kwaliteit en de diensten die worden aangeboden door telecommunicatiebedrijven over PSTN. Door het succes van de DOCSIS standaard, the QoS verbeteringen in DOCSIS 1.1, en de inspanningen die Telenet gedaan heeft om de capaciteit in 2 richtingen uit te breiden is er ruimte gekomen voor de ontwikkeling van packetized voice en video toepassingen.

1.5.2. Euro-PacketCable componenten

Figuur 2: Euro-PacketCable: Referentie Architectuur



6


1.5.3.

MTA

De MTA ofwel de Multimedia Terminal Adaptor. Dit is abonnee apparatuur die de interface is voor signalering en media transport tussen de telefoon en de netwerkelementen. De standaard voorziet 2 MTA types: • •

E-MTA of Embedded MTA geïntegreerde MTA met DOCSIS Cablemodem (CM) S-MTA of Standalone MTA MTA met een LAN interface voor aansluiting met een kabelmodem

In de praktijk echter wordt de S-MTA nog niet geproduceerd en het ziet er naar uit dat deze nooit in productie zal komen. Wanneer we verder over een MTA spreken bedoelen we steeds een EMTA. Eén MTA kan verschillende fysieke eindpunten (bijvoorbeeld poorten/lijnen) controleren die zelfs verschillende telefoonnummers kunnen hebben. De MTA staat in het untrusted netwerk gedeelte. Hij doet dus alles op commando. De MTA: • • • • • •

1.5.4.

is "slave" voor de CMS (met dus CMS als "master") krijgt bevelen wat het moet monitoren of wat het moet doen rapporteert status (bijvoorbeeld off-hook), maar doet enkel rapportering genereert tonen (ringtoon, kiestoon, bezettoon enz.) wanneer het hiervoor commando's ontvangt zet RTP streams 2 op en breekt ze weer af, wanneer het hier het bevel voor krijgt codeert en decodeert de mediastreams (audiocodec support)

CM

De CM of Cable Modem is de modulator/demodulator bij de klant die zorgt voor de datatransmissie over het kabelnetwerk door gebruik te maken van het Euro-DOCSIS protocol. De CM speelt een sleutelrol in het behandelen van de media stromen. tevens voorziet de CM ook services als bijvoorbeeld het classificeren van verkeer (voice, ftp, http,...) in service flows en doet aan queuing in upstream. Zoals eerder vermeld zit de MTA “embedded” in de CM.

1.5.5.

CMTS

Het Cable Modem Termination System bevindt zich aan de andere kant van het Euro-DOCSIS netwerk, namelijk de head-end. De CMTS is de router die de pakketten over het Euro-DOCSIS netwerk verstuurd. De functies van het CMTS zijn de volgende: • • • •

2

voorziet QoS naar de modem toe classificeert de inkomende pakketten en geeft ieder pakket een bepaald QoS level zorgt voor trafficshaping en policies zoals voorgeschreven in de service flows linken van het Euro-DOCSIS netwerk aan de IP backbone.

Real-time Transport Protocol, zie hoofdstuk 4.2 Steven Vlemincx




1.5.6.

7

CMS

De Call Management Server voorziet gesprekscontrole en signalisatiegerelateerde diensten voor de MTA, het CMTS en de PVG. De CMS bevindt zich niet in het RF netwerk van Telenet maar wel op het IP netwerk. De CMS bevindt zich in de backbone. De CMS kan opgesplitst worden in 2 functionele componenten: • •

de Call Agent of CA die zorgt voor callsignalering de Gateway Controller of GWC die zorgt voor QoS

De Callagent (CA) zorgt voor NCS signalering met de MTA en met de Announcement Controller.

1.5.7.

PVG

De Packet Voice Gateway (PVG) vormt als het ware de poort naar het klassieke telefoonnetwerk. Via de PVG kunnen kabeloperatoren zich connecteren op het Public Switched Telephony (PSTN) netwerk. Het is niet nodig om een trunk naar elke telecomoperator te hebben. Er worden enkele grote verbindingen gelegd naar belangrijke operatoren langs waar het verkeer verloopt. Andere telefonienetwerken (waaronder GSM) kunnen ook via deze poort bereikt worden met de PSTN als carrier.

1.5.8.

OSS Back Office

De OSS backoffice bevat alle diensten die nodig zijn om het proces te sturen. De belangrijkste processen zijn foutmanagement, performantiemanagement, beveiliging, accounting en configuratie. We zullen ze even in het kort bespreken: 1.5.8.1. DHCP Server

De Dynamic Host Configuration Protocol Server is een back office netwerkelement dat gebruikt wordt tijdens het MTA provisioning process. Deze server wijst dynamisch een IP adres en andere client configuratie informatie toe. Er zijn verschillende DHCP servers voor de CM, de MTA of de CPE. Deze grote groepen bevinden zich ook in verschillende IP ranges. 1.5.8.2. DNS

De Domain Name Server is de server die zorgt voor de associatie tussen FQDN’s en IP adressen. Dit is belangrijk om bijvoorbeeld om de FQDN van de MTA om te zetten in een IP. 1.5.8.3. TFTP/HTTP servers

De File Transfer Protocol Server en de Hypertext Transfer Protocol Server zijn netwerk elementen die de MTA gebruikt tijdens zijn provisioning proces. Van de TFTP server wordt tijdens de provisioning de configuratiefile opgehaald. Van deze server kan de MTA zijn configuratiebestand downloaden. Telenet heeft gekozen om gebruik te maken van TFTP. Steven Vlemincx Groep-T Graduaat Telecommunicatietechnieken



8

1.5.8.4. SYSLOG server

Op deze server wordt de historiek bewaard zoals traps en foutboodschappen van de MTA’s en de modem. Deze events kunnen dan worden geraadpleegd wat belangrijk is voor alarmmonitoring. 1.5.8.5. KDC

Het Key Distribution Center bestaat eigenlijk uit 2 elementen: - de Authorization Server (AS) - de Ticket Granting Server (TGS) - de TGS is eigenlijk een Kerberos server die zorgt voor ticketing naar de MTA. Ieder ticket bevat informatie die gebruikt wordt om: - authenticatie op te zetten - privacy te beschermen door integriteit van de gegevens te checken - access control voor de call signalisatie tussen de MTA en de CMS. 1.5.8.6. RKS

De Record Keeping Server ontvangt “event messages” van andere netwerkelementen zoals CMS, CMTS en GWC. De RKS kan al deze boodschappen samenvoegen in coherente sets of Call Detail records. Deze records kunnen dan nadien gebruikt worden voor facturatie en fraude detectie. 1.5.8.7. ANS

De Announcement Server wordt ook wel audio server genoemd. Deze zorgt voor berichten als antwoord op bepaalde gebeurtenissen die plaatsvinden in het netwerk. Deze server is een logische entiteit die bestaat uit de Announcement Controller (ANC) en de Announcement Player (ANP). Typisch zorgt deze server voor boodschappen als bijvoorbeeld “het netwerk is bezet, probeert u het later opnieuw”.




9

1.6. Protocols In de volgende figuur geven we even een overzicht waar welke protocols worden gebruikt in het netwerk.

Figuur 3: Euro-PacketCable: gebruikte protocols

1.6.1.

DHCP: Dynamic Host Configuration Protocol

Het DCHP protocol is een open industriestandaard, gebaseerd op de standaarden RFC2131 en RFC2132, die wordt toegepast om de administratie van IP adressen in een TCP/IP netwerk te vereenvoudigen. DHCP maakt het mogelijk een groot deel van de adresadministratie te automatiseren. Zo kan DHCP een host die in een TCP/IP netwerk opstart automatisch configureren. Tevens kunnen bepaalde instellingen met betrekking tot de IP-configuratie aangepast worden, terwijl het systeem in bedrijf blijft. DHCP maakt gebruik van UDP als transport protocol. Via de DHCP opties worden nog veel andere gegevens meegegeven zoals bijvoorbeeld het pad waar de configuratiefile zich bevindt, enzovoort. DHCP vindt zijn oorsprong in het BootP-protocol, wat oorspronkelijk ontworpen was om computers hun besturingssysteem vanaf het netwerk te laten laden. De client bekomt aan de hand van zijn MAC-adres de nodige gegevens hiervoor van de BOOTP-server.




1.6.2.

10

TFTP: Trivial File Transport Protocol

Trivial File Transfer Protocol (TFTP) is een eenvoudig protocol ontwikkeld voor datatransfers. TFTP is gedefinieerd door de IETF in RFC 1350. TFTP is ontworpen zodat het klein en makkelijk is om te implementeren. Hierdoor ontbreekt het wel de meeste karakteristieken van gewone FTP. TFTP wordt geïmplementeerd bovenop User Datagram protocol of UDP terwijl FTP gebruik maakt van TCP. Dit heeft als gevolg dat TFTP minder overhead heeft dan FTP maar ook een betrouwbaarder netwerk vereist omdat er geen foutcontrole aanwezig is op laag 4. Verder wordt er ook geen gebruikersnaam en paswoord gevraagd bij TFTP wat het uitermate geschikt maakt voor het verzenden van configuratiebestanden.

1.6.3.

COPS: Common Open Policy Service

Het COPS protocol is een eenvoudig vraag en antwoord protocol in een client/server omgeving, dat gebruikt wordt om informatie over policies uit te wisselen tussen een policy server en haar clients. COPS is beschreven in RFC 2748. Een Policy Decision Point (PDP) fungeert als policy server. Een Policy Enforcement Point (PEP) bevindt zich in het service element en doet autorisatie requests bij een PDP. De PEP voert dan de beslissingen van de PDP uit. Hierbij kan de PEP een statusbericht aan de PDP sturen, met daarin informatie over de uitgevoerde besluiten. Het protocol gebruikt TCP als transportprotocol en voorziet in beveiliging op bericht niveau met Authenticatie, replay protection en integrity protection. COPS wordt gebruikt om dynamisch access bandbreedte aanvragen te versturen tussen CMTS en application managers, zoals de soft switch. Telenet heeft dit nog niet geïmplementeerd omdat niet alle netwerkelementen COPS ondersteunen. Vandaag handelt de CMTS de bandbreedte aanvragen af zonder waterdichte authenticatie (“DqoS light”).

1.6.4.

RTP: Real Time transportprotocol

Het real time transport protocol voorziet in end-to-end bezorging van data met real-time karakteristieken zoals interactieve spraak en video. Het is geschikt voor Unicast en Multicast toepassingen. RTP werkt bovenop UDP om gebruik te kunnen maken van de mutiplexing en checksum services. Beide protocols dragen bij tot de transportprotocol functionaliteiten. RTP kan echter ook met andere netwerk- of transportprotocols gebruikt worden. Toch heeft het weinig zin om RTP bovenop TCP te laten draaien want hertransmissies zijn bij RTP niet nodig. RTP is gedefinieerd in RFC 3550 en 3551.

1.6.5.

MGCP: Media Gateway Control Protocol

MGCP is het standaard protocol voor IP telefonie controle en is beschreven in RFC 2705. Het is het resultaat van de combinatie van 2 andere standaards: het Bellcore Simple Gateway Control Protocol (SGCP) en het IP Device Control (IPDC). MGCP was oorspronkelijk enkel bedoeld voor Gateways maar kan ook worden aangepast voor terminals. MGCP dient als basis voor NCS.

1.6.6.

NCS: Network-based Call Signaling

NCS is een uitgebreide variant van het MGCP call signaling protocol. Het protocol is ontworpen om events die in het netwerk gebeuren, door te geven tussen MTA en CMS en tussen de ANC Steven Vlemincx Groep-T Graduaat Telecommunicatietechnieken



11

(announcement controller) en de ANP (announcement player). NCS is een applicatieprotocol en wordt op laag 4 in UDP pakketten gestopt.

1.6.7.

SIP: Session Initiation Protocol

Een internetstandaard gebruikt bij het opzetten, managen en afbreken van interactieve sessies tussen een of meerdere gebruikers op het internet. We komen hier op terug in hoofdstuk 10.

1.6.8.

SS7: Signaling System 7

De PSTN standaard voor signalisatie die gebruikt wordt om informatie door te sturen naast het eigenlijke telefoongesprek.




12

2. Provisioning Het provisioneren of in dienst komen van een MTA bestaat uit verschillende stappen. In dit deel zullen we de verschillende stappen toelichten en verduidelijken. We leggen hierbij de nadruk op het Euro-PacketCable gedeelte, maar kunnen dit niet doen zonder de stappen te overlopen die een Euro-DOCSIS modem moet doorlopen voor hij in dienst komt. DOCSIS is en blijft de transportmethode van PacketCable.

2.1. DOCSIS 2.1.1.

Ranging

2.1.1.1. DS scanning

Het ranging proces begint met een scannen naar de DOCSIS downstreamfrequentie tussen 112 MHz en 858MHz. De modem herkent de DOCSIS downstreamfrequentie aan volgende eigenschappen: • kanaal wordt gemoduleerd in QAM64 of QAM256 • MPEG-2 pakketisatie • Euro-DOCSIS PID (payload identifier) in de MPEG-2 header • FEC wordt toegepast op de frames Omdat het DS scanning proces erg tijdrovend is, zal de modem de frequentie waarop hij het laatst actief was onthouden. Hierdoor zal hij sneller terug kunnen regsitreren.

2.1.1.2. Initial ranging

De modem zal nu zoeken naar volgende pakketten: • SYNC pakketten: deze zitten in de MPEG header zodat de CM zich kan synchroniseren met de klok van de CMTS. • UCD berichten: deze worden op vaste tijdstippen in het downstreamkanaal verzonden. UCD of Upstream Channel Discriptor geeft de nodige upstream parameters mee aan de CM en dit voor alle beschikbare kanalen. Bijvoorbeeld upstream frequentie , modulatiemethode, enzovoort. • MAP berichten geven aan wanneer en voor hoe lang een modem mag zenden binnen een TDMA omgeving. In deze MAP’s staat gespecifieerd hoe de CMTS de upstream minislots toekent aan de verschillende modems.3 Als al deze stappen doorlopen zijn behoort de modem tot het MAC domein van de CMTS. De modem krijgt een SID toegewezen op MAC niveau en is nu klaar om laag 3 connectiviteit op te zetten. De modem kan voorgaande berichten steeds blijven bekijken zodat hij steeds zijn synchronisatie, powerlevel en frequentie kan bijsturen bij netwerkvariaties.

3

Een deel van de bandbreedte wordt in contention aangeboden (aan alle CMs). Toekenning van bandbreedte aan een bepaalde CM wordt door de CMTS gedirigeerd en is gebaseerd op de momentane vraag naar bandbreedte van US actieve CMs, mits rekening te houden met de door de operator voorafgedefinieerde policies. Naargelang vraag en aanbod worden de minislots verdeelt over de modems. Een minislot is een deel van het upstream kanaal dat 6,25microseconden lang is. Een minislot bevat altijd een geheel van bytes. Steven Vlemincx Groep-T Graduaat Telecommunicatietechnieken


13


2.1.2. Registratie De modem gaat starten met het aanvragen van een IP adres aan de DHCP server.

In de DHCP discover stuurt de modem DHCP opties mee: • de fabrikant • het type modem • de Euro-DOCSIS mogelijkheden (bijvoorbeeld Euro-DOCSIS 1.1) • zijn MAC–adres De modem ontvangt dan in de DHCP offer, gegevens van de DHCP server die hij nodig heeft om zijn registratie verder te zetten zoals: • IP adres van de modem • IP adres van de TFTP en en ToD server • Naam van de configuratiefile die de modem moet ophalen De modem vraagt zijn configuratiefile aan de TFTP server met de gegevens die hij van de DHCP server heeft verkregen. Gebaseerd op het MAC adres, type en merk gaat de TFTP server dynamisch een configuratiefile aanmaken en deze doorsturen naar de CM. Nadien gaat de modem de datum en het uur opvragen bij de ToD server, voor de syslogs in de modem. De modem stuurt daarna een registration request naar de CMTS. De CMTS zet QoS service flows op en antwoord met een registration response. De modem is nu helemaal geregistreerd en klaar voor gebruik. Optioneel kan de encryptiemethode BPI+ nog geïnitialiseerd worden om security op te zetten. BPI+ gaat er namelijk voor zorgen dat al het Euro-DOCSIS verkeer geëncrypteerd wordt. Maar omdat dit gewoon een feature is die je kan aanzetten en eigenlijk niets aan de werking verandert, gaan we hier niet verder op in. De encryptiemethode van BPI+ kan eigenlijk beschouwd worden als een project op zich. Voor alle testen die we hebben uitgevoerd in een labo-omgeving werken we steeds zonder BPI+.

2.2. Euro-PacketCable Ook de MTA zal tijdens zijn registratieproces starten met een DHCP discover. Hij krijgt dan van de DHCP server een IP-adres en zijn FQDN. Met het IP-adres kan de MTA, de KDC server contacteren zodat de MTA een ticket bekomt om te communiceren met de TFTP server. Met dit ticket kan de MTA de configuratiefile over een beveiligde connectie gaan opvragen. Steven Vlemincx Groep-T Graduaat Telecommunicatietechnieken


14


De MTA is nu in staat om de GWC te contacteren en zijn registratieproces af te ronden. Om het registratieproces toe te lichten, maken we gebruik van een trace die we hebben gemaakt met een DOCSIS-sniffer. We zullen stuk voor stuk in het kort uitleggen wat er gebeurt. De hele trace kunnen we uit veiligheidsoverwegingen, niet tonen. Zo een volledige trace neemt trouwens ongeveer 44 bladzijden in beslag en dit is niet echt relevant. In bijlage A vindt u een volledig overzicht van de provisioningflow van het Euro-PacketCable gedeelte.

2.2.1.

Testopstelling

We beschikken bij Telenet over 2 Euro-DOCSIS tracers. Wanneer we onze beveiliging uitschakelen op de modems, kunnen we met deze tracers DOCSIS pakketten gaan sniffen. Na decodering kunnen we de gegevens met het programma Ethereal bekijken en analyseren. Voor sommige testen kan het zelfs nodig zijn om de upstream en de downstream afzonderlijk te bekijken. Deze mogelijkheid bestaat met Ethereal. In bijlage I leggen we uit hoe deze tools gebruikt kunnen worden. .

Figuur 4: Sniffer testopstelling

Het is best om de tracer zo kort mogelijk bij de modem te plaatsen. Zo gaat enkel het upstream verkeer van de modem naar de tracer wat de filtering vergemakkelijkt.

2.2.2.

DHCP

Het telefonie gedeelte of beter gezegd de MTA kan eigenlijk als een CPE gezien worden die op de modem is aangesloten. Daarom is het noodzakelijk dat ook de MTA een IP adres aanvraagt aan een DHCP server. Aan de hand van DHCP opties gaat de MTA nog enkele andere gegevens bekomen zoals: • zijn FQDN (full qualified domain name) • IP adres van de DNS server • FQDN van de SNMP entry • naam van de Kerberos realm



15


Het DHCP proces op zich is niet anders dan een standaard DHCP aanvraag. We zullen ons daarom toespitsen op de DHCP opties.

2.2.2.1. DHCP Discover (1)

In de DHCP discover kunnen we in de optie 55 aflezen welke gegevens de MTA wenst te verkrijgen. Ook de optie 60 is zeer belangrijk, want aan de hand van deze optie kan de provisioning server zien welke PacketCable standaard gebruikt wordt door de MTA. Option 53: DHCP Message Type = DHCP Discover Option 57: Maximum DHCP Message Size = 576 Option60: Vendor class identifier = "pktc1.0:051D0101000201020901010B090305060708090A0B0C0C01000D0101100109" Option 55: Parameter Request List 12 = Host Name 15 = Domain Name 1 = Subnet Mask 3 = Router 2 = Time Offset 6 = Domain Name Server 7 = Log Server 122 = CableLabs Client Configuration Option 61: Client identifier Hardware type: Ethernet Client hardware address: 00:00:ca:b3:a3:01

2.2.2.2. DHCP Offer (2)

In de DHCP offer zien we al heel belangrijke gegevens naar boven komen. Optie 12 vormt samen met optie 15 de FQDN of full qualified domain name van de MTA. Bv : mymta004.emta.telenet.be Verder zien we ook de Kerberos realm staan in optie 122.6 die nodig is om een ticket te bekomen. Natuurlijk worden ook de leasetime, de DNS servers, IP adres van de DHCP server, voorgestelde IP adres voor de client,… meegegeven. Client IP address: 0.0.0.0 (0.0.0.0) Your (client) IP address: 10.128.1.6 (10.128.1.6) Next server IP address: 0.0.0.0 (0.0.0.0) Relay agent IP address: 10.128.0.1 (10.128.0.1) Client hardware address: 00:00:ca:b3:a3:01 Server host name not given Boot file name not given Magic cookie: (OK) Option 53: DHCP Message Type = DHCP Offer Option 54: Server Identifier = 195.130.130.130 Option 51: IP Address Lease Time = 20 hours, 2 minutes, 20 seconds Option 1: Subnet Mask = 255.255.240.0 Steven Vlemincx Groep-T Graduaat Telecommunicatietechnieken


16


Option 58: Renewal Time Value = 10 hours, 1 minute, 10 seconds Option 59: Rebinding Time Value = 10 hours, 1 minute, 11 seconds Option 4: Time Server = 195.130.130.130 Option 15: Domain Name = "emta.telenet.be" Option 2: Time Offset = 1 hour Option 6: Domain Name Server IP Address: 195.130.130.13 IP Address: 195.130.130.141 Option 7: Log Server = 195.130.130.130 Option 12: Host Name = "mymta004" Option 122: CableLabs Client Configuration Suboption 3: TSP's Provisioning Server Address = prov.labg.telenet-ops.be Suboption 6: TSP's Kerberos Realm Name = TCOMLABS.COM Option 3: Router = 10.128.0.1

We merken dat de parameters die werden gevraagd in de DHCP discover, ingevuld werden. DHCP discover Parameter Host Name Domain Name Subnet Mask Router Time Offset Domain Name Server

optie 55.12 55.15 55.1 55.3 55.2 55.6

Log Server CableLabsClient Configuration

55.7 55.122

DHCP offer Parameter Host Name = "mymta004" Domain Name = "emta.telenet.be" Subnet Mask = 255.255.240.0 Router = 10.128.0.1 Time Offset = 1 hour Domain Name Server IP Address: 195.130.130.13 IP Address: 195.130.130.141 Log Server = 195.130.130.130 CableLabs Client Configuration Suboption 3: TSP's Provisioning Server Address = prov.labg.telenet-ops.be Suboption 6: TSP's Kerberos Realm Name = TCOMLABS.COM

optie 12 15 1 3 2 6

7 122

2.2.2.3. DHCP Request (3)

In de DHCP request vraagt de MTA bevestiging voor het IP adres dat hij toegewezen kreeg. Option 53: DHCP Message Type = DHCP Request Option 57: Maximum DHCP Message Size = 576 Option 54: Server Identifier = 195.130.130.130 Option 50: Requested IP Address = 10.128.1.6 Option 51: IP Address Lease Time = 20 hours, 2 minutes, 20 seconds Option 60: Vendor class identifier = "pktc1.0:051D0101000201020901010B090305060708090A0B0C0C01000D0101100109" Option 55: Parameter Request List 12 = Host Name 15 = Domain Name 1 = Subnet Mask 3 = Router 2 = Time Offset 6 = Domain Name Server 7 = Log Server 122 = CableLabs Client Configuration Option 61: Client identifier Hardware type: Ethernet Client hardware address: 00:00:ca:b3:a3:01



17


2.2.2.4. DHCP ACK (4)

Met de DHCP ack krijgt de MTA bevestiging voor zijn IP adres en de andere opties. Option 53: DHCP Message Type = DHCP ACK Option 54: Server Identifier = 195.130.130.130 Option 51: IP Address Lease Time = 20 hours, 2 minutes, 20 seconds Option 1: Subnet Mask = 255.255.240.0 Option 58: Renewal Time Value = 10 hours, 1 minute, 10 seconds Option 59: Rebinding Time Value = 10 hours, 1 minute, 11 seconds Option 4: Time Server = 195.130.130.130 Option 15: Domain Name = "emta.telenet.be" Option 2: Time Offset = 1 hour Option 6: Domain Name Server IP Address: 195.130.130.13 IP Address: 195.130.130.141 Option 7: Log Server = 195.130.130.130 Option 12: Host Name = "mymta004" Option 122: CableLabs Client Configuration Suboption 3: TSP's Provisioning Server Address = prov.labg.telenet-ops.be Suboption 6: TSP's Kerberos Realm Name = TCOMLABS.COM Option 3: Router = 10.128.0.1

Vooraleer het IP adres te gebruiken, gaat de MTA nog even een ARP request doen om zich ervan te vergewissen dat de DHCP server geen duplicated adres heeft uitgedeeld. 52 12.818062 10.128.1.6

2.2.3.

Broadcast

ARP

Who has 10.128.1.6? Gratuitous ARP

Aanvragen KDC IP adres

De MTA gebruikt SNMPv3 in zijn provisioning proces voor de communicatie met de provisioning servers om de configuratiefile te downloaden. Er werd gekozen voor SNMPv3 uit veiligheidsredenen. SNMPv3 maakt namelijk authenticatie mogelijk. Dit is belangrijk zodat niet iedereen een configuratiefile kan sturen. Een MTA en een modem zijn en blijven namelijk een untrusted device in het untrusted netwerkgedeelte. Om deze beveiligde SNMPv3 flow op te zetten tussen de MTA en de verschillende servers is authenticatie noodzakelijk en is encryptie mogelijk als optie. Hiervoor maken we gebruik van Kerberos. Om alles een beetje schaalbaar te houden, maken we gebruik van de PKINIT extensie zodat er certificaten kunnen worden gebruikt voor de communicatie tussen de MTA en het key distribution center of kortweg KDC. Om overbelasting van de KDC te voorkomen, bij bijvoorbeeld een grote netwerkonderbreking of een sterke toename van het aantal klanten, kunnen we ons netwerk opsplitsen in verschillende delen of realms met elk hun eigen KDC. Een MTA weet aan de hand van optie 122 suboptie 6 van de DHCP offer/ack zijn realm naam. Om het IP adres van de KDC voor zijn realm te weten te komen moet de MTA een DNS query uitvoeren. De volgende stappen worden hierbij doorlopen:



18


2.2.3.1. DNS server request (5)

In DHCP optie 122.6 werd de Kerberos realm naam meegegeven. Om de server te bekomen die verantwoordelijk is voor deze realm, gaat de MTA een DNS server request doen en stuurt hiervoor de realm naam mee. Bijvoorbeeld: TCOMLABS.COM

2.2.3.2. DNS server reply (6)

De DNS server antwoordt aan de MTA met de naam van de de KDC , Bijvoorbeeld: kdc.test.telenet.be

2.2.3.3. DNS request (7)

In de DHCP opties De MTA kent nu de FQDN van de KDC server, maar om te kunnen communiceren moet hij het IP-adres van deze server kennen. Daarom gaat de MTA een DNS request doen. 56 17.822962 10.128.1.6

195.130.130.13

DNS

Standard query A kdc.test.telenet.be

2.2.3.4. DNS reply (8)

De DNS server antwoordt met het IP adres van de KDC server. 77129 437.255103 195.130.130.13 195.130.130.130

10.128.1.6

DNS

Standard query response A

In onze testomgeving is dit hetzelfde adres als onze DHCP server. In het netwerk hoeft dit echter niet zo te zijn. Om problemen te voorkomen bij een uitval of om de load op de servers te verdelen is het beter om de KDC server op een aparte machine te draaien. De MTA heeft nu alle nodige gegevens van de KDC die nodig zijn om een connectie op te zetten.

2.2.4.

Verkrijgen van tickets bij de KDC

Om te kunnen communiceren met een SNMPv3 entiteit van een applicatie server, moet de MTA steeds een ticket aanvragen aan de KDC voor die bepaalde applicatie. Dit ticket blijft gedurende een bepaalde tijd geldig. De geldigheidsduur van een ticket wordt meegegeven bij het bekomen van het ticket. Dikwijls is de geldigheidsduur één dag.



19


2.2.4.1. AS request (9)

De MTA moet zich authentificeren bij de de KDC door een AS (authentication server) request uit te voeren. Hiervoor moet hij zijn FQDN en zijn certificaat doorsturen. De MTA staat in het untrusted netwerk en bezit dus een publiek vertificaat. Daarom mag hij dit vertificaat doorsturen. Natuurlijk moet de MTA ook doorgeven welke service hij wenst te bekomen. De MTA stuurt een AS (Authentication Server) request naar de KDC server om een TGT te bekomen. Deze aanvraag werd geïnitialiseerd omdat de optie 122.7 gezet was.

2.2.4.2. AS reply (10)

De KDC gaat nu het MTA MAC adres mappen met de FQDN en gaat dan vervolgens antwoorden met een TGT (ticket granting ticket) in de AS reply. Met de TGT kan de MTA tickets aanvragen aan de KDC om services mogelijk te maken. De authenticatie met de KDC server is nu voltooid. 77183 437.281054 195.130.130.130

10.128.1.6

PKTC

AP Reply (SNMPv3)

Het TGT kan niet worden gelezen door de MTA, laat staan worden aangepast. De andere gegevens wel. Als de MTA wenst te communiceren me de KDC moet hij steeds het TGT meesturen. Zo wordt telkens weer de indentiteit van de MTA bevestigd.

2.2.4.3. TGS request (11)

Nu de MTA geauthenticeerd is met de KDC, kan hij services aanvragen. In ons geval moet hij een service vragen met de provisioning server om zijn configuratie op te halen. Hiervoor moet de MTA een TGS request doen, waarin zoals gezegd het TGT wordt meegegeven. Omdat alleen de MTA deze TGT uit de rest van de AS reply kan halen, wordt de identiteit van de MTA nogmaals bevestigd, en kan de KDC toegang verschaffen tot services. Het TGT zelf kan alleen de applicatie server lezen omdat alleen hij hiervoor de sleutel heeft.

2.2.4.4. TGS reply (12)

De KDC gaat 2 tickets naar de MTA sturen met de TGS reply. Eén ticket voor de MTA en een ander voor de server waarop de service draait die werd aangevraagd. Steven Vlemincx Groep-T Graduaat Telecommunicatietechnieken


20


Omdat hier gebruik wordt gemaakt van asymmetrische keying, kan de MTA het ticket van de server niet lezen. Hij moet dit server ticket gebruiken in zijn communicatie met de betrokken server. In ons geval is dit dus de provisioningserver.

2.2.4.5. AP request (13)

De MTA gaat het server ticket dat hij via de TGS reply had verkregen, samen met andere gegevens doorsturen naar de provisioning server. 58 17.836962 10.128.1.6

195.130.130.130

PKTC

AP Request (SNMPv3)

De provisioningserver kan zeker zijn van de identiteit van de MTA omdat deze laatste een geldig server ticket kan voorleggen.

2.2.4.6. AP reply (14)

De server en de MTA hebben nu een gemeenschappelijke sleutel uitgewisseld, waarmee ze al hun communicatie gaan versleutelen. Deze sleutel is slechts een bepaalde tijd geldig. In onze implementtatie staat ook deze tijd op één dag ingesteld. Het ligt dan ook voor de hand dat een goede tijdsynchronisatie noodzakelijk is. Daarom zal de provisioningserver de tijd doorsturen via de AP reply. 77183 437.281054 195.130.130.130

10.128.1.6

PKTC

AP Reply (SNMPv3)

Er is nu een SNMPv3 security association opgezet die kan gebruikt worden om de configuratiefile door te sturen.

2.2.5.

Opvragen configuratiefile

2.2.5.1. SNMP inform (15)

De MTA gaat een aantal gegevens doorsturen naar de provisioning server, zodat deze alle gegevens heeft die hij nodig heeft om een configuratie te kunnen aanmaken.



21


60 17.862962 10.128.1.6 195.130.130.130 SNMP iso.3.6.1.6.3.1.1.4.1.0 iso.3.6.1.2.1.1.1.0 iso.3.6.1.4.1.4491.2.2.1.1.1.14.0 iso.3.6.1.4.1.4491.2.2.1.1.1.4.0 iso.3.6.1.4.1.4491.2.2.1.1.3.4.0 iso.3.6.1.2.1.1.3.0 : iso.3.6.1.6.3.1.1.4.1.0 : iso.3.6.1.2.1.1.1.0 :

iso.3.6.1.4.1.4491.2.2.1.1.1.14.0 : iso.3.6.1.4.1.4491.2.2.1.1.1.8.0 :

iso.3.6.1.4.1.4491.2.2.1.1.1.4.0 : iso.3.6.1.4.1.4491.2.2.1.1.3.4.0:

INFORM iso.3.6.1.2.1.1.3.0 iso.3.6.1.4.1.4491.2.2.1.1.1.8.0

sysuptime snmpTrapOID sysDescr

A textual description of the entity. This value should include the full name and version identification of the system's hardware type, software operating-system, and networking software. pktcMtaDevSwCurrentVers pktcMtaDevTypeIdentifier This is a copy of the device type identifier used in the DHCP option 60 exchanged between the MTA and the DHCP server pktcMtaDevMacAddress pktcMtaDevCorrelationId Random value generated by the MTA for use in registration authorization. It is for use only in the MTA initialization messages and for MTA configuration file download

2.2.5.2. SNMP get request/reply (optioneel)

De provisioning kan bijkomende informatie vragen en verkrijgen van de MTA. Telenet heeft deze stappen niet geïmplementeerd om de load op de servers te beperken na eventuele grote netwerkstoringen.

2.2.5.3. Configuratiefile (16)

De provisioning server kan nu aan de hand van de gegevens die hij bekomen heeft van de MTA, een query doen op zijn database zodat hij te weten komt welke diensten hij moet leveren. Met al deze gegevens zal hij een configuratiefile aanmaken.

2.2.5.4. SNMP set (17)

Vervolgens geeft de provisioning server aan de MTA door waar hij de configuratiefile kan ophalen. 77238 437.307828 195.130.130.130

10.128.1.6

SNMP

SET iso.3.6.1.4.1.4491.2.2.1.1.2.5.0

Als we deze OID in de MIB’s opzoeken krijgen we volgende gegevens: Name: pktcMtaDevConfigFile Description: The URL of the TFTP/HTTP file for downloading provisioning and configuration parameters to this device. Returns NULL if the server address is unknown. Supports both TFTP and HTTP. We voeren dus een SNMP set uit met daarin het path en de file die op te halen is door de MTA.



22


2.2.5.5. DNS request TFTP server (18) / DNS reply TFTP server (19)

Volgens de standaard wordt er een DNS request/reply uitgevoerd om het IP adres van de TFTP server te bekomen. Telenet stuurt dit echter mee met de SNMP set 4 zodat deze stap overbodig is.

2.2.5.6. TFTP get request (20)

De MTA gaat nu zijn configuratiefile aan de TFTP server vragen. De MTA geeft hiervoor de naam van de configuratiefile mee, samen met het pad waar dit bestand gevonden kan worden. Hoe dit wordt geïmplementeerd hangt af van provider tot provider omdat elk provisioning systeem anders werkt. 64 17.889162 10.128.1.6 195.130.130.130 mta.config/00:00:CA:B3:A3:01, Transfer type: octet

TFTP

Read Request, File:

2.2.5.7. TFTP get response (21)

De MTA krijgt nu zijn configuratiefile toegezonden in 2 blokken via een TFTP sessie. 77314 437.345639 195.130.130.130

10.128.1.6

TFTP

Data Packet, Block: 1

Na blok 1 gaat de MTA dit deel bevestigen. 66 17.921862 10.128.1.6

195.130.130.130

De server zal nu de 2de blok sturen. 77334 437.354613 195.130.130.130 Ook deze blok wordt bevestigd 68 17.931862 10.128.1.6

10.128.1.6

195.130.130.130

TFTP

Acknowledgement, Block: 1

TFTP

TFTP

Data Packet, Block: 2 (last)

Acknowledgement, Block: 2

TFTP is hiermee afgelopen en de configuratiefile is binnengehaald. De MTA weet nu welke GWC hij kan contacteren, welke lijnparameters, enzovoort. In hoofdstuk 3 besteden we meer aandacht aan de opbouw van de configuratiefile.

2.2.6.

4

Het afronden van het registratieproces

SNMP set, zie hoofdstuk 2.2.5.4 Steven Vlemincx



23


2.2.6.1. Contacteren van de CMS (22)

De GWC is een onderdeel van de CMS en vormt het toegangspunt voor de MTA naar de CMS. De MTA kreeg in zijn configuratiefile de naam van zijn Gateway Controler of GWC mee.Vooraleer hij deze kan contacteren, moet de MTA dus een DNS request uitvoeren om het IP adres van de GWC te bekomen. 76 19.287162 10.128.1.6 301.gentbgtn03n.cs2k.telenet.be

195.130.130.13

DNS

Standard query A gwc-

De server antwoordt met het IP adres van de GWC. 79958 438.701414 195.130.130.13

10.128.1.6

DNS

Standard query response A 10.213.8.36

De MTA zal zich nu trachten aan te melden bij de GWC. Hiervoor gaat de MTA berichten uitwisselen met de CMS door gebruik te maken van het NCS protocol5. In dit geval gaat de MTA een RSIP bericht sturen. De MTA is een slaaf van de CMS, met andere woorden hij mag enkel melden wat hem werd gevraagd door de CMS. Daarom stuurt de CMS onmiddellijk een NCS bericht waarin hij doorgeeft aan de MTA welke events (off-hook, hook-flash, enzovoort) de MTA moet rapporteren en wanneer. Op dit alles komen we uitgebreid terug in hoofdstuk 4.

2.2.6.2. Syslog notify (23)

De MTA zendt een bericht naar de Syslog server die hij meekreeg in DHCP optie 7 meegeeft of zijn registratie al dan niet gelukt is. Ook dit adres werd meegegeven in de DHCP opties.

6

waarin hij

77 19.289461 10.128.1.6 195.130.130.130 SNMP TRAP-V2 iso.3.6.1.2.1.1.3.0 iso.3.6.1.6.3.1.1.4.1.0 iso.3.6.1.2.1.2.2.1.1.0 iso.3.6.1.2.1.2.2.1.7.0 iso.3.6.1.2.1.2.2.1.8.0 iso.3.6.1.2.1.1.3.0 : iso.3.6.1.6.3.1.1.4.1.0 : iso.3.6.1.2.1.2.2.1.1.0 : iso.3.6.1.2.1.2.2.1.7.0 : iso.3.6.1.2.1.2.2.1.8.0 :

system uptime system contact adres interface index interface admin status interface operational status

2.2.6.3. SNMP inform (24)

De MTA gaat gegevens: • • •

5 6

ook een SNMP inform sturen naar de provisioning server met daarin de volgende ifPhysAddr = MAC adres pkctMtadevProvisiongsstate = pass pktcMtaDevCorrelationId

Network-based Call Signaling, zie hoofdstuk 4 DHCP optie 7, zie hoofdstuk 2.2.2.4 Steven Vlemincx




24

Indien enkel de syslog notify en de SNMP inform falen, zal de MTA toch nog perfect werken, maar zal je niet de correcte status krijgen wanneer je een modemtest doet. Deze test gaat namelijk een query uitvoeren op de databases. Hiermee is ook het registratieproces van de MTA beëindigd en kan er dus gebruik worden gemaakt van de telefoniediensten.




25

3. Configuratiefile 3.1. Algemeen De configuratiefile van een Euro-DOCSIS modem is TLV encoded. TLV staat hierbij voor Type / Length / Value. Elke configuratie setting wordt gedefinieerd door een bepaald type en eventueel een subtype. Voor elk type wordt de lengte van de bijhorende data meegegeven in het veld L. De data of value moet aan bepaalde normen voldoen die eigen zijn aan het type. De modem gaat deze hexadecimale waardes inlezen en zo tot zijn configuratiefile komen. We hebben een steekkaart gemaakt met daarop alle officiële TLV’s die vermeld staan in de DOCSIS 2.0 RFI specificatie. Deze kaart is terug te vinden in bijlage B. Om een voorbeeld te geven, onder TLV 43 vinden we bijvoorbeeld settings die eigen zijn aan de fabrikant. Deze worden bijvoorbeeld gebruikt wanneer een fabrikant features aanbiedt die niet door de specificatie omschreven zijn. Onder TLV 11 vinden we dan weer de MIB settings. Als we een MIB object wensen toe te voegen aan de configuratiefile, dan kunnen we deze aan de hand van deze TLV toevoegen.

3.1.1.

TLV’s

Een configuratiefile in hexadecimale vorm - zoals steeds naar de modem wordt gestuurd - is natuurlijk niet leesbaar. Bij wijze van oefening gaan we een stukje uit zo een hexadecimale configuratie file bekijken. Hierdoor wordt de werking van de TLV’s een stuk duidelijker. Met het programma HEX editor van HDD software kunnen we makkelijk de hexadecimale vorm van het configuratiebestand bekijken. Hieronder ziet u een beeld van dit programma met hierin een configuratiefile.

Figuur 5: HEX editor van HDD software Steven Vlemincx Groep-T Graduaat Telecommunicatietechnieken


26


Om het systeem van de TLV’s te verduidelijken zullen we de eerste TLV’s van bovenstaande configuratie file bespreken. 03 T

01 L Type Lengte Value

01 V 03 01 01

network access control de volgende Byte data omschrijft de data voor type 03 enabled, CPE’s mogen data verzenden over RF netwerk

09 T

26 2F 73 6f 66 74 77 61 72 65 2f 54 53 30 34 30 ….. L V Type 09 Software upgrade file naam Lengte 26 de volgende 38 (=26HEX) bytes geven de software filenaam weer. Value 2f … geven de file naam en het pad naar deze file weer, namelijk: /software/TS040135_123004_EU.TM402.img 12 01 4 T L V Type 18 Max aantal CPE’s Lengte 01 volgende byte omschrijft de waarde voor de TLV Value 04 4 CPE’s toegelaten. …

3.1.2.

Maken van een configuratiefile

Voor het maken van DOCSIS configuratiefiles bestaan er DOCSIS editors. Zo een programma geeft een TLV weer aan de hand van de naam zoals deze in de DOCSIS RFI specificatie staat. Hierdoor is de file leesbaar en makkelijker om aan te maken en aan te passen. Het is echter wel belangrijk dat je de werking van de TLV’s begrijpt, want alle communicatie aangaande configuratieproblemen, met de fabrikant, gebeurt aan de hand van de TLV’s. .



27


Figuur 6: voorbeeld DOCSIS editor

Op de achtergrond van bovenstaande figuur zie je een configuratiefile zoals deze in de editor wordt getoond. Wanneer een TLV moet worden toegevoegd of aangepast dan krijgt men bij deze editor een schermpje met daarin een aantal gegevens in verband met de TLV. In de menubalk staat een vakje staan met als naam CMTS MIC. Hier moet de shared key worden ingeven. Indien deze niet correct werd ingevuld zal de modem niet kunnen registreren.

3.2. Modem configuratie 3.2.1.

Algemeen

We kennen nu de opbouw van een configuratiefile en weten hoe hij gemaakt wordt. Laten we dan nu eens een kijkje nemen wat er zoal in een configuratiefile staat. We kunnen een configuratiefile opsplitsen in 2 delen: • de verplichte velden • de optionele velden Laten we even opsommen welke velden er verplicht in de file aanwezig moeten zijn. • TLV 3 network access control Steven Vlemincx Groep-T Graduaat Telecommunicatietechnieken


28


• TLV 24 upstream service flow encodings • TLV 25 downstream service flow encodings • MIC Message Integrity Check • TLV 255 end of data marker Wanneer deze velden niet zijn ingevuld, dan zal de modem de configuratiefile niet aanvaarden. De configuratie die wij bespreken is speciaal afgestemd op de Euro-PacketCable standaard.

3.2.2.

De configuratiefile

In principe is het voldoende om 1 service flow op te zetten. We wensen echter dat events zoals inhaken, uithaken, enzovoort van de telefoon direct worden doorgegeven aan de CMS. Daarom moeten we ons NCS verkeer over een andere service flow sturen dan de andere data zodat we gebruik kunnen maken van prioriteiten. We willen ook niet dat de data ten gevolge van management wordt verrekend in het verbruikte volume van de klant. Het is daarom noodzakelijk om ook de SNMP-data over een aparte service flow te sturen. Het normale internetverkeer sturen we over de best effort service flow. Dit alles heeft tot gevolg dat we zowel voor upstream als voor downstream 3 service flows met hun classifiers moeten definiëren in de configuratiefile. Dit maakt de configuratiefile natuurlijk vrij groot. Ook parameters zoals het aantal toegelaten CPE’s, de software upgrade file, de downstream frequentie, upstream kanaal, enzovoort kunnen in de configuratiefile worden opgenomen. We hebben een configuratiefile aangemaakt waarmee we alle testen hebben uitgevoerd. U vindt deze in bijlage C. Om SNMP beheer mogelijk te maken moeten er ook SNMP community’s in de CM configuratiefile gedefinieerd worden. Natuurlijk hebben we hiervoor een uit de lucht gegrepen community naam genomen.

3.3. MTA configuratie De MTA configuratiefile bevat gegevens die de goede werking van de lijninterface verzekeren. Omdat de meeste van deze gegevens zoals kiestoon, bezettoon, enzovoort, eigen zijn aan het land, groeperen de fabrikanten deze settings in een lijntemplate. Deze lijntemplates worden voor elk land in de software geprogrammeerd. Het is dan voldoende om de juiste template in de configuratie file te definiëren. Hierdoor wordt de configuratiefile natuurlijk een stuk eenvoudiger en korter. Verder gaan we ook nog gegevens als de Kerberos realm naam en de naam van de GWC in de configuratiefile vinden. Indien deze niet correct worden meegegeven, zal de MTA niet in dienst komen, laat staan correct kunnen werken. Ook hier vinden we SNMP parameters voor het beheer van de MTA. In bijlage D vindt u een voorbeeld van een MTA configuratiefile.



29


4. Het opzetten van een gesprek In dit hoofdstuk bekijken we hoe een gesprek wordt opgezet, met andere woorden, we kijken hoe de signalisatie tussen de MTA en de CMS precies in zijn werk gaat. Het protocol dat hierbij wordt gebruikt is NCS. NCS is een afgeleide van MGCP. Omdat op de MTA’s de NCS logging moet worden aangezet met het CLI commando “mgcp” wordt MGCP wel eens gebruikt als we NCS bedoelen. De gespreksstroom zelf wordt over een RTP stream gestuurd en wordt niet via de CMS gestuurd, maar rechtstreeks van de MTA, over de modem, naar de CMTS en zo naar de IP backbone die de pakketten dan gaat routeren naar de juiste bestemming.

4.1. NCS Signalisatie NCS of Network-based Call Signaling is een afgeleide van het MGCP 1.0 protocol (RFC 2705). Het protocol is ontworpen om events die in het netwerk gebeuren, door te geven tussen MTA en CMS en tussen de ANC (announcement controller) en de ANP (announcement player). NCS is een applicatieprotocol en wordt op laag 4 in UDP pakketten gestopt. Daarom moet NCS de berichten bevestigen. Want stel dat er een bericht niet zou toekomen en er wordt hierop geen controle gedaan, dan zou de MTA bijvoorbeeld niet weten dat hij een bepaald event moet melden en kan er geen gesprek worden opgezet. Hieronder ziet u een tabel met de events die voor ons belangrijk zijn in het VoIP gebeuren. RQNT

ReQuest for NoTification Met een RQNT vraagt de CMS aan de MTA om uit te kijken naar de opgegeven events zoals uithaken (hu), inhaken (hd), … .

NTFY

NoTiFY

De MTA meldt de gevraagde events aan de CMS als deze zich hebben voorgedaan.

CRCX

CReate Connection

De CMS stuurt een bericht aan de MTA dat de MTA een RTP connectie moet opzetten volgens de meegegeven parameters.

MDCX

MoDify Connection

MTA moet een RTP connectie aanpassen

DLCX

DeLete Connection

MTA moet een bepaalde connectie afbreken.

AUEP

AUdit EndPoint

CMS vraagt info aan de MTA i.v.m. een bepaald eindpunt (= lijninterface)

AUCX

AUdit Connection

CMS vraagt informatie aan de MTA i.v.m. een bepaalde connectie zoals het aantal verstuurde en ontvangen pakketten.

RSIP

ReStart In Progress

MTA meldt aan de CMS dat een endpoint aan het herstarten is of terug in dienst komt.

Elk bericht dat verzonden werd moet bevestigd worden met een 3 digit response code. Bijvoorbeeld: 200 : bevestiging van het pakket zonder fouten 250 : afbreken van de verbinding 5xx : permanente fouten Als we bijvoorbeeld een pakket krijgen met daarin “200 60 OK” dan wil dit zeggen dat pakket 60 correct werd ontvangen. De zender weet nu dat hij het volgende pakket mag zenden indien hij dit wil.



30


4.1.1. Wat zijn events en hoe worden ze weergegeven Als we over NCS spreken, bedoelen we met events elke verandering op de lijninterface. Wanneer iemand de hoorn van de haak neemt, gaat de MTA dit merken aan de lijnstroom. Het is dan ook logisch dat dit wordt doorgegeven aan de telefooncentrale of CMS zodat het mogelijk wordt om een verbinding op te zetten. We geven hierna ook een overzicht van de verschillende events, anders is het moeilijk te begrijpen hoe een gesprek precies wordt opgezet. Event Off-hook On-hook Hook-flask Ring Busy tone Ring back Message indicator Reorder tone Nummering …

Weergave hu hd hf rg bz rt mwi ro [0-9*#T]

Beschrijving Uithaken van de telefoon Inhaken van de telefoon Korte onderbreking van het haakcontact Belsigaal sturen bezettoon ring back toon Aangeven dat er een bericht is in de voice mail Netwerk overbelast toon Eender welke digit van het telefoontoestel

Meerdere events kunnen ook aan elkaar worden gekoppeld in 1 NTFY of RQNT. Dit nemen we piggybacking. De CMS geeft in zijn RQNT mee wanneer bepaalde events moeten worden doorgestuurd. Dit wordt gedaan door acties toe te voegen aan het gevraagde event. (N) (A) (D) (I) (K) (E) (C)

notify immediately accumulate accumulate according to digitmap ignore keep alive signals embedded RQNT embedded MDCX

bv.: R: hd(N) bv.: R: [0-9*#T](D



31


4.1.2.

MTA 1

Een voorbeeld

CMS

MTA2

RQNT (1)

Off-hook Digits

1. RQNT: de CMS geeft aan MTA1 door dat deze moet uitkijken wanneer de telefoon wordt uitgehaakt en wanneer er wordt genummerd. 2 NTFY: De telefoon wordt uitgehaakt en er wordt genummerd. De MTA stuurt deze informatie door naar de CMS.

NTFY (2)

3 CRCX: CMS vraagt aan MTA1 om een niet actieve RTP connectie te openen (sendonly). 4 CRCX: Hetzelfde voor MTA2 maar hier worden nog parameters meegestuurd van de oproeper.

CRCX (3) CRCX (4)

RQNT (7)

5 MDCX: CMS vraagt aan MTA1 om de connectie aan te passen rekening houdend met de parameters van MTA2 die met dit bericht worden doorgestuurd.

NTFY (8)

6 RQNT: CMS vraagt om ringback toon te zenden als er genoeg resources beschikbaar zijn in het netwerk. 7 RQNT: CMS vraagt om een belsignaal te genereren en door te geven wanneer de telefoon wordt uitgehaakt.

MDCX (5) RQNT (6)

Off-hook

MDCX (9)

MDCX (10)

8 NTFY: MTA2 geeft door de hoorn werd opgenomen. 9-10 MDCX : connectie wordt in full duplex (sendreceive) gezet.

4.2. RTP De eigenlijke gespreksstroom loopt over een RTP (real-time transport protocol) stream. Deze stream gaat van de MTA, over de CM, via de CMTS rechtstreeks op de backbone om daar gerouteerd te worden naar de bestemming. Indien dit een niet-VoIP lijn is, wordt de RTP stroom naar de PVG gerouteerd. De RTP stream kan gecodeerd worden met verschillende codecs. De meest gebruikte is op dit moment de G711. Indien we zouden opteren om een andere codec te gebruiken, moeten het steeds mogelijk zijn om terug te vallen op de G711 codec om fax en modemverkeer mogelijk te maken. De reden waarom Telenet een andere codec gebruikt dan de G711, waarop we terugvallen voor voor fax en modem verkeer is de bandbreedte. Door bijvoorbeeld de G729 codec te gebruiken zullen we zien dat de bandbreedte die een gesprek nodig heeft aanzienlijk vermindert. Zie hiervoor het hoofdstuk 7 dat handelt over capaciteitsplanning. De codec waarmee een gesprek moet worden gecodeerd, vinden we terug in de NCS berichten onder de index L. Zeker wanneer er 2 verschillende codecs worden gebruikt in het netwerk is het belangrijk dat je hieraan aandacht besteedt bij het troubleshooten van problemen.

4.3. Praktische bespreking We scheppen een beeld van de call setup aan de hand van elke log die we hebben genomen op de MTA. In een Telenet sessie naar de MTA kunnen we namelijk debugging aanzetten op de MTA, zodat de NCS berichten worden weergegeven. Steven Vlemincx Groep-T Graduaat Telecommunicatietechnieken


32


4.3.1.

Algemeen

We bespreken hier een RQNT zodat we een duidelijker inzicht krijgen in de werking van NCS. Wanneer men dit pakket kan interpreteren wordt het ook mogelijk om de andere pakketten te lezen. Het packet werd gestuurd door 10.213.8.44 via poort 2427 (=MGCP) en heeft een totale lengte van 165 bytes RQNT 1211 aaln/[email protected] Het gaat om een RQNT met het volgnummer 1211. MGCP 1.0 NCS 1.0 Het pakket is bestemd voor de 2de analoge lijn van FQDN m22322.emta.telenet.be en het 0000:05:37.015 (len=165)

10.213.8.44:2427

=>

PP

gaat om een MGCP/NCS pakket van versie 1.0 . X: 33410

X : Requested identifier

D: (1XX|2X|3X|4X|5X|6X|7X|8X|9X|0XXXXXXX|*X X|#XX|A|D)

D : digit map Definitie van de digit map. Dit duidt aan welke nummers er moeten gevormd worden alvorens deze te mogen doorsturen. S: requested signals De MTA moet kiestoon (dl) uitsturen R : Requested events hf (I,K) : hook flash negeren hu(N) : uithaken direct doorgeven oc : bezet of :

S: dl R: hf(I,K), hu(N), oc, of, [0-9*#T](D)

[0-9*#T](D): nummers volgens digit mpa doorgeven.

Alle NCS berichten zijn gelijkaardig opgebouwd. Het is dan ook niet nodig om de verschillende berichten te bespreken. Hou bij een analyse van de NCS signalisatie, steeds rekening met de sequentie. Als de CMS niet naar een bepaald event vraagt, dan mag de MTA dit ook niet doorgeven en kunnen we in de problemen komen.

4.3.2.

Gesprek van MTA naar MTA

Om een mooi overzicht te maken van welke berichten er op welk moment van een gesprek worden verzonden, hebben we een gesprek opgezet tussen 2 MTA’s. Op beide MTA’s hebben we de NCS logging aangezet door middel van het CLI commando “mgcp 1”. Deze berichten hebben we samengebracht in het document dat u vindt in bijlage E. Tevens hebben we bij elk bericht een woordtje uitleg gegeven zodat duidelijk wordt wat er gebeurt.

4.3.3.

Gesprek van PSTN naar MTA

Hetzelfde hebben we ook gedaan voor een gesprek van een PSTN-lijn naar een MTA. Hier konden we alleen loggen aan de MTA zijde. Daarom is dit verloop ook een stukje korter maar ook niet zo volledig. U kan dit document vinden in bijlage F.




33

4.3.4. Besluit Als we in staat zouden geweest zijn om de NCS berichten steeds langs beide zijdes te bekijken, dan zouden we merken dat deze steeds gelijkaardig verlopen tussen MTA en MTA of MTA en PVG. Het grote verschil kunnen we vinden in het MDCX bericht. We zien dat hier het IP-adres van de MTA die ons opbelt wordt meegegeven en de user en sessionid waarmee deze lijn is gekend in de CMS. 0001:44:49.225 10.213.8.44:2427 => PP (len=309) MDCX 81967 aaln/[email protected] MGCP 1.0 NCS 1.0 C: D3205CCA20C6CFC8FFFFB585 I: 5 M: inactive v=0 o=- 4099373 4099373 IN IP4 10.130.98.32 s=c=IN IP4 10.130.98.32

Als we dit bekijken voor een gesprek van PSTN naar een MTA, dan zien we dat hier het adres van de PVG wordt meegegeven. 0000:52:41.685 10.213.8.44:2427 => PP (len=233) MDCX 53916 aaln/[email protected] MGCP 1.0 NCS 1.0 C: D3205BBE101E28F7FFFFF084 I: 3 M: inactive v=0 o=PVG 0 0 IN IP4 10.213.16.15



34


5. Hoe telefoneer ik naar een IP adres? In het hoofdstuk provisioning zagen we onder andere hoe de MTA zijn FQDN bekomt. Hierna zullen we verduidelijken hoe deze FQDN gelinkt wordt aan een telefoonnummer. Deze link wordt gelegd in de CMS. De CMS bevat verschillende Gateway Controllers of GWC’s. Eén Telenet GWC heeft 6400 kleine gateways en kan dus 6400 verschillende MTA’s controleren. De MTA en de CMS praten met elkaar via NCS. Via een management tool wordt de FQDN van de MTA geassocieerd met een GWC. Name

IP Address

Profile

Protocol

Prot Port

Node Name + nbr

MTAGNT089.labg.emta.telenet.be 0.0.0.0 ARRIS_TOUCHSTONE_NN01_4 4 1 ncsprotocol 1.0 2427 NOT_SET GC03 00 0 198 MTAGNT090.labg.emta.telenet.be 0.0.0.0 ARRIS_TOUCHSTONE_NN01_4 4 1 ncsprotocol 1.0 2427 NOT_SET GC03 00 0 198 MTAGNT090.labg.emta.telenet.be 0.0.0.0 ARRIS_TOUCHSTONE_NN01_4 4 2 ncsprotocol 1.0 2427 NOT_SET GC03 00 0 198 MTAGNT091.labg.emta.telenet.be 0.0.0.0 ARRIS_TOUCHSTONE_NN01_4 4 1 ncsprotocol 1.0 2427 NOT_SET GC03 00 0 198 MTAGNT092.labg.emta.telenet.be 0.0.0.0 ARRIS_TOUCHSTONE_NN01_4 4 1 ncsprotocol 1.0 2427 NOT_SET GC03 00 0 198

In bovenstaand voorbeeld wordt de MTA met FQDN MTAGNT089.labg.emta.telenet.be geassocieerd met de GWC met de naam GC3 en het nummer 198. Op de GWC wordt voor iedere MTA een poort gereserveerd. Hieronder zie je dat de FQDN MTAGNT089.labg.emta.telenet.be wordt gelinkt aan poort 193. Name Aaln/1 Aaln/1 Aaln/1 Aaln/1

Gateway MTAGNT089.labg.emta.telenet.be MTAGNT090.labg.emta.telenet.be MTAGNT091.labg.emta.telenet.be 198 MTAGNT092.labg.emta.telenet.be

Node Number 198 198 39 198

Terminal Number 193 4 214

In de switch en de CMS zit een database waar de FQDN gelinkt wordt aan het PSTN abonneenummer. Via het commando QLEN FQDN aaln/1 doen we een query van de gerelateerde data van het line equipment number (LEN). > qlen MTAGNT089.labg.emta.telenet.be aaln/1 --------------------------------------------------------------------LEN: GC03 00 0 01 92 END POINT: MTAGNT089.labg.emta.telenet.be aaln/1 TYPE: SINGLE PARTY LINE SNPA: 001 DIRECTORY NUMBER: 5379500 LINE CLASS CODE: IBN IBN TYPE: STATION CUSTGRP: ZONE151IP SUBGRP:0 NCOS:0 SIGNALLING TYPE: DIGITONE CARCODE: GWLPOT GND: N PADGRP: PKNIL BNV: NL MNO: N PM NODE NUMBER : 198 PM TERMINAL NUMBER : 193

De SNPA of Subscriber Numbering Plan Area en het Directory Number vormen samen het telefoonnummer. Ook hier zien we opnieuw de naam en nummer van de GWC. Omgekeerd kunnen we natuurlijk ook een query op het telefoonnummer doen. De switch moet immers weten welke MTA er moet gecontacteerd worden wanneer er een vraag binnenkomt om een bepaald telefoonnummer te contacteren.



35


> qdn 0015379500 --------------------------------------------------------------------DN: 5379500 TYPE: SINGLE PARTY LINE SNPA: 001 SIG: DT LNATTIDX: N/A LINE EQUIPMENT NUMBER: GC03 00 0 01 92 END POINT: MTAGNT089.labg.emta.telenet.be aaln/1 LINE CLASS CODE: IBN IBN TYPE: STATION CUSTGRP: ZONE151IP SUBGRP:0 NCOS:0 CARCODE: GWLPOT GND: N PADGRP: PKNIL BNV: NL MNO: N PM NODE NUMBER : 198 PM TERMINAL NUMBER : 193 DNGRPS OPTIONS NETNAME/ PUBLIC1 ADDRESS: DDNNNNNNNN NETNAME: VOICEMAIL ADDRESS: NNNNNNNNNN OPTIONS:

In het geval iemand dus het telefoonnummer 015-37.95.00 vormt weet de Telenet switch dat dit nummer kan bereikt worden door de MTA met FDN MTAGNT089.labg.emta.telenet.be te contacteren. Uit de gegevens zien we dat dit kan via de GWC GC3 met nummer 198. De MTA kan op deze GWC bereikt worden via poort 193. Op een server die gebruikt wordt voor management en provisioning vinden we volgende gegevens terug over de MTA met FQDN MTAGNT089.labg.emta.telenet.be: bash-2.03$ dig MTAGNT089.labg.emta.telenet.be ; <<>> DiG 9.2.2 <<>> MTAGNT089.labg.emta.telenet.be ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54589 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;MTAGNT089.labg.emta.telenet.be.

IN

A

;; ANSWER SECTION: MTAGNT089.labg.emta.telenet.be. 300 IN A

10.213.247.50

;; AUTHORITY SECTION: labg.emta.telenet.be. 300

IN

NS

metis.telenet-ops.be.

IN

A

195.130.132.88

;; ADDITIONAL SECTION: metis.telenet-ops.be. 2688 ;; Query time: 2 msec ;; SERVER: 195.130.131.145#53(195.130.131.145) ;; WHEN: Tue Apr 5 14:04:48 2005 ;; MSG SIZE rcvd: 112

Hier zien we ook dat de MTA ook gekend is via IP adres 10.213.247.50. Het eigenlijke gesprek via de RTP stroom zal naar dit IP gaan wanneer het nummer 015-37.95.00 gebeld wordt. Steven Vlemincx Groep-T Graduaat Telecommunicatietechnieken



36

6. Quality of Service 6.1. Waarom? Omdat we er voor willen zorgen dat alle VoIP pakketten bij de bestemmeling raken met een beperkte en ongeveer konstante delay en we wensen dat de pakketten in de juiste volgorde toekomen, moeten we QoS of Quality of Service, invoeren. Voor voice services is het onbelangrijk om een verloren gegaan pakket nogmaals te verzenden, omdat dit dan toch te laat aankomt. Wel belangrijk is dat alle pakketten op regelmatige basis verzonden worden. Daarom is het nodig om toegewezen bandbreedte te garanderen voor een gesprek. In downstream geven we aan ons gesprek een hoge prioriteit door gebruik te maken van de TOS bit. Omdat we in downstream over voldoende BB beschikken in het access netwerk, is dit voldoende. In upstream ligt het wel even anders. Daarom maken we gebruik van service flows op het EuroDOCSIS niveau. Om dit te realiseren moest DOCSIS 1.1 geïmplementeerd worden, want 1.0 heeft deze mogelijkheid niet. De CMTS en de CM gaan aan de hand van classifiers, een bepaald type verkeer in een bepaalde service flow plaatsen die al dan niet gegarandeerde BB heeft. We hebben onze classifiers zo ingesteld dat onze gespreksdata over een service flow met gagarandeerde bandbreedte wordt gestuurd. Natuurlijk blijft een verstandig beheer van de bandbreedte aangewezen. Ook de prioriteiten zijn in deze context van belang. We zullen aantonen dat voice voorrang krijgt op best effort services.



37


6.2. Service flows Het garanderen van bandbreedte is een aangelegenheid van het Euro-DOCSIS protocol omdat dit protocol zorgt voor het transport over het acces netwerk. Aan de hand van onderstaande figuur zullen we uitleggen hoe dit alles in zijn werk gaat. Hoger gelegen applicaties SNMP

RTP

NCS

FTP

HTTP

Hoger gelegen applicaties Mail

SFID Best Effort DefBEDown

Mail

NCS

RTP

SNMP

SFID Best Effort

DefCSDown

SFID Voice

FTP

Downstream

SFID Call signaling Downstream classifiers

HTTP

RF

DefBEUp

SFID Call signaling

Dynamische svc flow

DefCSUp

SFID SNMP

Upstream classifiers

SFID Voice

DefSNMPDown

Dynamische svc folw

Upstream

SFID SNMP DefSNMPUp

CMTS

CM Figuur 7: Service flows

Elk protocol heeft zoals we weten een specifiek poortnummer. Aan de hand van deze poortnummers wordt de data aan de juiste classifier toegewezen. Elke classifier stuurt een service flow aan, waarover data kan verzonden worden. Indien meer dan 1 classifier van toepassing is voor een bepaald poortnummer, dan wordt degene gebruikt met de hoogste prioriteit. In ons geval heeft voice steeds de hoogste prioriteit. Dit is logisch want indien de delay tussen twee pakketten teveel zou schommelen, dan zou het kunnen gebeuren dat onze pakketten te laat komen en je een rare effecten verkrijgt bij de bestemmeling (robotic voice, one way speech, enzovoort).

6.2.1.

Dynamische service flows : UGS

Het Euro-DOCSIS protocol verdeelt zijn upstream-bandbreedte over de modems die data wensen te verzenden in minislots. Dit zijn allemaal kleine tijdsloten waarin een modem mag zenden. Door gebruik te maken van UGS (=Unsolicited Grant Service) kunnen we een vast aantal minislots gedurende een bepaalde tijd toewijzen aan een modem zodat deze over een vaste bandbreedte beschikt. Hierdoor wordt een constante bitstroom verzonden, wat aangewezen is voor de meeste codecs. Steven Vlemincx Groep-T Graduaat Telecommunicatietechnieken



38

Het ‘grant interval’ is de tijd tussen de periodes wanneer een modem mag zenden. Het grant interval moet gelijk zijn aan de ‘packetisation time’ die wordt ingesteld op de CMS. Door het gebruik van UGS in het upstream kanaal beperk je de schommelingen qua delay voor het upstream verkeer doorheen het netwerk. Dit is heel belangrijk voor het transporteren van RTP data. Deze schommelingen noemen we ook jitter. Normaal moet er elke 20msec een pakket toekomen op de CMTS.Als dit constant schommelt dan hebben we jitter op ons netwerk en kan dit storingen in de spraak veroorzaken.

6.2.2.

QoS in de configuratiefile

In dit onderdeel bespreken we welke parameters er in de configuratiefile moeten staan om service flows te kunnen opzetten. De upstream parameters kunnen we vinden onder TLV 24 en de downstream parameters onder TLV 25. Alle parameters in verband met QoS, worden opgesplitst in 2 delen: • service flow encoding: omschrijven van de service flow • packet classifier encoding: omschrijven van de classifiers In hoofdstuk 3 vindt u een algemene configuratiefile. Het is handig wanneer u deze erbij neemt als referentie bij het bespreken van de QoS parameters.

6.2.2.1. QoS parameters

Als je een configuratiefile aanmaakt, merk je dat er andere parameters kunnen ingesteld worden in upstream tov DS. Omdat ons netwerk voldoet aan de eisen die onze services nodig hebben, kunnen een aantal parameters die in de standaard worden beschreven, weggelaten worden zodat onze configuratiefile veel overzichtelijker blijft. Hieronder zullen we de parameters bespreken zoals deze bij Telenet in de configuratiefile voorkomen.

6.2.2.1.1 Service flows encoding

• •

•

•

Service flow reference Om de packet classifier encoding aan de service flow encoding te linken. Service class name Geeft de naam van de service weer, bijvoorbeeld defCSup. Deze naam moet overeenstemmen met de configuratie op de CMTS zodat de CMTS weet welke service hij moet bieden. (bijvoorbeeld: DefCSup voor Call signaling upstream) QoS parameter set type Hiermee wordt aangegeven of de service behoort tot de provisioned, admitted of de active set. Indien deze op 7 staat spreken van een primary set wat betekent dat hij zowel van toepassing is in de provisioned, admitted of de active set. De CM gaat deze primary sets gebruiken tijdens registratie, zodat de registratie niet slaagt indien er hier een fout werd gemaakt. maximum sustained traffic rate




39

Hiermee kunnen we de snelheid van een modem beperken voor een bepaalde service flow. Dit doen wij bijvoorbeeld om de verschillende Internet producten te beheren en te kunnen factureren.

6.2.2.1.2 Packet classifier encoding

•

Classifier reference Uniek getal dat een bepaalde classifier aanduidt. • Service flow reference Linkt naar de service flow encoding. • Rule priority Hiermee geef je de prioriteit van de classifier mee. Hoe hoger dit getal is, hoe hoger de prioriteit is. Het spreekt voor zich dat we voice de hoogste prioriteit van al onze services geven. • Classifier activation state Hiermee geven we aan of we de classifier al dan niet actief wensen te zetten. 1 betekent actief en 0 betekent niet actief. In de DSX berichten zal je zien dat de classifier actief wordt, nadat de service flow werd opgezet. • IP parameters o IP protocol o IP source address: Het subnet waarvoor de classifier mag gelden. Aangezien de MTA’s een IP adres krijgen uit een andere range dan de CPE’s, is de voice service flow dus al niet te gebruiken om te surfen. o IP source mask Subnetmask voor het source address o IP source poort Poortnummer van het protocol dat over deze classifier mag getransporteerd worden. Voor VoIP is dit 2427, namelijk NCS. o IP destination port Poortnummer van de bestemming.

6.2.3.

Opzetten van service flows

Een service flow kan worden opgezet door de CMTS of door de CM door een 3 way handshake, gekend als dynamic service addition of DSA. Deze handshake bestaat uit de volgende stappen: • DSA request • DSA response • DSA acknowledge Met deze stappen wordt service flows in beide richtingen opgezet. Voor het beheer van service flows zijn er 3 belangrijke DSX berichten, namelijk: • DSA of dynamic Service Addition • DSC of Dynamic Service Change • DSD of Dynamic Service Deletion Omdat deze service flows dynamisch worden beheerd, spreken we van DQOS of Dynamische Quality Of Service. De Packetcable specificatie laat de operator vrij in de keuze hoe de kwaliteit op het backbone level te garanderen. Op Telenet stelt zich hier niet meteen een QoS probleem, gezien de ruim bemeten capaciteit op backbone level. Opdat VoIP pakketten bij routering onder alle denkbare en



40


ondenkbare scenario’s toch prioritair behandeld zouden worden, wordt op de backbone de Tos bit gebruikt. Op access level specifieert PacketCable het gebruik van DQoS. Zoals reed eerder vermeld, past Telenet hier een variant van toe, DQoS light genoemd. Later dit jaar plant Telenet over te gaan op geauthoriseerde DQoS, met gebruik van het COPS protocol, ook wel full DQoS genoemd. De full DQoS gaat gates openen en sluiten tussen de CMS en de CMTS door gebruik te maken van het COPS protocol. Wij beperken ons hier tot het bespreken van de DSX mode. Aan de hand van onderstaande figuur krijgt u een beeld waar deze handelingen plaatsvinden in het proces van de call setup. Indien de call setup zelf niet duidelijk is, verwijzen we graag naar hoofdstuk 4.

Figuur 8: Call setup Steven Vlemincx Groep-T Graduaat Telecommunicatietechnieken



41

Tijdens het opzetten van het gesprek moet er eerst worden nagegaan aan de hand van DSA berichten of er wel bandbreedte beschikbaar is tussen de CMTS en de CM. Indien dit niet zo zou zijn (door bijvoorbeeld een technische storing), dan krijg je een netwerk overbelasttoon te horen. Zie hiervoor de praktische uitwerking in hoofdstuk 6.3. Gelukkig doet dit zich zelden voor. Nadat er werd gecontroleerd of er voldoende bandbreedte voorhanden is, kan de B-zijde worden opgeroepen. Als de B-zijde uithaakt, worden er DSC berichten gestuurd om de gereserveerde bandbreedte naar actief te zetten. De bandbreedte kan dus gebruikt worden en het gesprek kan starten. Bij het inhaken moet de bandbreedte natuurlijk worden vrijgegeven. Dit gebeurt met het DSD bericht. We zullen hier even verder op ingaan.

6.2.3.1. Dynamic Service Addition

Figuur 9: Call setup, Dynamic Service Addition

Nadat het telefoontoestel aan MTA1 werd uitgehaakt, en dit werd doorgegeven aan de CMS, wordt er een connectie opgezet met het CRCX commando. Bij het ontvangen van een CRCX doet de CM een DSA request aan de CMTS om een service flow op te zetten. Hiervoor worden volgende gegevens meegestuurd die de CM uit zijn configuratiefile haalt: • service flow parameters: dit zijn parameters zoals de prioriteit • classifier: de classifier die overeenstemt met het poortnummer 2427 in het geval van voice over IP. • payload header De CMTS antwoordt met de SFID of Service Flow Identifier en de SID of Service Identifier. De CM kan zichzelf nu configureren zodat hij de toegewezen service flow kan gebruiken. Daarna stuurt hij een bevestiging. Als deze stappen doorlopen zijn is de bandbreedte gereserveerd, maar wordt ze nog niet gebruikt! Steven Vlemincx Groep-T Graduaat Telecommunicatietechnieken


42


6.2.3.1.1 DSA bericht in detail

Ook hier is het mogelijk om logging op te zetten op de MTA zodat de DSX berichten worden getoond in een telnet-sessie. Hierna volgt de bespreking van de request. Log Upstream_Service_Flow_Encoding : Service_Flow_Reference = 1

Bespreking

QoS_Parameters_Set_Type = 02

“2” betekent dat de CM vraagt om een service flow te bekomen in de status admitted (toegekend).

Referentie die overeenstemt met de upstream classifier.

Service_Flow_Scheduling_Type = 6 Request_Transmission_Policy = 00 00 01 7f Unsolicited_Grant_Size = 227 Nominal_Grant_Interval = 20000 Tolerated_Grant_Jitter = 800 Grants_Per_Interval =

1

Hoeveel minislots er worden samengenomen per grant. Dit moet overeenstemmen met de packetisationtime in µsec. Hier is dit dus 20msec. Hoeveel µsec er mag worden afgeweken van de grant time. Hoeveel grants de CM krijgt per interval.

Downstream_Service_Flow_Encoding :

Service_Flow_Reference =

2

QoS_Parameters_Set_Type = 02 Traffic_Priority = 5 Downstream_Maximum_Traffic_Rate = 10000000 Max_Traffic_Burst = 1522 Min_Reserved_Traffic_Rate = 87200 Min_Reserved_Rate_Packet_Size = 218

Referentie die overeenstemt de downstreamclassifier. “2” betekent dat de CM vraagt om een service flow te bekomen in de status admitted (toegekend). De prioriteit die wordt toegewezen aan de SF. Maximum downstreamsnelheid voor de SF. Maximum packet grootte Minimum gereserveerde downstreamsnelheid. Minimum gereserveerde pakket grootte.

Upstream_Classification_Encoding :

Classifier_Reference = 1 Service_Flow_Reference = 1 Rule_Priority = 128 Classifier_Activation_State = IP_Classification_Encoding : IP_Protocol = 17 IP_Source_Address = [10.213.247.54] Source_Port_Start = 53064 Source_Port_End = 53064

0

Referentie van de Classifier. Referentie die overeenstemt met de service flow encoding. Deze waarde geeft de volgorde waarmee de classifiers moeten bekeken worden. Zolang de service flow nog niet is opgezet, is ook de classifier nog niet actief. Omschrijft het bovenliggende protocol. 17 betekent UDP IP adres van de MTA.



43


Downstream_Classification_Encoding :

Referentie van de Classifier. Referentie die overeenstemt met de service flow encoding. Deze waarde geeft de volgorde waarmee de classifiers moeten bekeken worden.

Classifier_Reference = 2 Service_Flow_Reference = 2 Rule_Priority = 128 Classifier_Activation_State = IP_Classification_Encoding : IP_Protocol = 17

0

IP_Destination_Address = [10.213.247.54] Destination_Port_Start = 53064 Destination_Port_End = 53064

Omschrijft het bovenliggende protocol. 17 betekent UDP. IP adres van de MTA.

6.2.3.2. Dynamic Service Change

Figuur 10: Call setup, Dynamic Service Change

Nadat de CMS het bericht dat de telefoon werd uitgehaakt (NTFY) van de MTA2 heeft gekregen stuurt deze een MDCX naar de MTA om van ‘inactive’ naar ‘sendrecv’ over te gaan. De CM gaat nu een DSC sturen om de bandbreedte die gereserveerd werd, in gebruik te nemen. Hij zal daarom nog eens alle parameters terug doorsturen zoals bij de DSA. De CMTS bevestigt nog eens alle gegevens en de CM herbevestigt nog eens. De bandbreedte wordt nu opengezet voor communicatie en een gesprek is mogelijk.



44


6.2.3.3. Dynamic Service Deletion

Nadat er wordt ingehaakt, stuurt de CMS een MDCX connection om de verbinding naar ‘send only’ te zetten. De CM stuurt nu een DSD om de service flows af te breken tussen de CMTS en de CM.

MTA 1

CM1

CMTS1

CMS

CMTS2

CM2

MTA2

Gesprek

ON-hook

NTFY ACK MDCX DSD-req

MDCX DSD-req

DSD-rsp

DSD-rsp

DSD-ack

DSD-ack

Bandbreedte is vrijgegeven ACK DLCX ACK RQNT ACK

ACK DLCX ACK NTFY ACK RQNT ACK

ON-hook

Figuur 11: Call setup, Dynamic Service Deletion

6.3. Praktisch We hebben in ons labo geprobeerd om het opzetten van service flows te laten falen. Hieronder worden enkele van deze testen besproken.

6.3.1.

Normaal gesprek

Voor een geregistreerde modem kunnen we de service flows die actief zijn opvragen op de CMTS zoals we hieronder zien. BSR58PROP01:7A #show cable modem 0000.cab3.efe4 svc-flow-id Service flow id Interface Flow Direction Flow Max Rate 845 cable 0/1 Upstream 192000 846 cable 0/1 Upstream 30000 847 cable 0/1 Upstream 30000 848 cable 0/1 Downstream 6000000 849 cable 0/1 Downstream 10000 850 cable 0/1 Downstream 10000 861 cable 0/1 Upstream no restriction 862 cable 0/1 Downstream 10000000



45


We hebben ervoor gezorgd dat alle mogelijke service flows actief waren. Service flow ID’s 861 en 862 staan hier in voor de gespreksdata. Voor elke service flow ID kunnen we meer gegevens opvragen. Niet alle gegevens zijn hierbij belangrijk, maar zo kunnen we wel snel zien in geval van twijfel welke service flow instaat voor welke service. BSR58PROP01:7A #show cable qos svc-flow param-set 0/1 861 Interface index: Qos service flow id: Qos parameter set type: Qos parameter set bit map: Qos active timeout: Qos admitted timeout: Qos scheduling type: Qos unsolicited grant size: Qos nominal grant interval: Qos tolerated grant jitter: Qos grants per interval: Qos min reserved pkt size: Qos tos AND mask: Qos tos OR mask: Qos req/trans policy:

32514 861 Active 0xcf0000 0 200 UGS 227 20000 800 1 128 0xff 0x0 0x17f

Interface index: Qos service flow id: Qos parameter set type: Qos parameter set bit map: Qos active timeout: Qos admitted timeout: Qos scheduling type: Qos unsolicited grant size: Qos nominal grant interval: Qos tolerated grant jitter: Qos grants per interval: Qos min reserved pkt size: Qos tos AND mask: Qos tos OR mask: Qos req/trans policy:

32514 861 Admitted 0xcf0000 0 200 UGS 227 20000 800 1 128 0xff 0x0 0x17f

6.3.2.

Netwerk overbelast

Op de CMTS kunnen we het aantal gelijktijdige gesprekken beperken per upstream groep door een setting in de CMTS configuratie. Voor deze test hebben we dit aantal teruggebracht tot 2. Als we vervolgens 2 MTA’s op de upstream groep aansluiten, en we bellen van de ene naar de andere, dan zijn onze resources opgebruikt en mag een derde oproep niet meer lukken. Om de setting op de CMTS aan te passen, loggen we in op de interface waarvoor de setting wensen aan te passen en voeren het volgende uit: cable upstream 4 max-calls 2



46


We activeren de DSX logging op onze MTA’s met het commando “replevel 15” en we zetten een gesprek op tussen de 2 MTA’s. Vervolgens haken we een derde telefoon uit. Deze laatste is op 1 van de MTA’s aangesloten. We zien de volgende logs verschijnen. De service flow parameters hebben we weggelaten, zodat de log kort en overzichtelijk blijft. 0002:08:32.590 10.213.2.32:2427 => PP (len=151) CRCX 37531 aaln/[email protected] MGCP 1.0 NCS 1.0 C: 4D002D42003E77D0FFFFC715 M: inactive L: p:20, a:PCMA, sc-rtp:60/50, sc-rtcp:80/70 DSX: Got CM DSA Mngmnt msg DSX: New TA index 0 allocated for CM TA ID 34. DSX-REQ Parameters: ------------------. . DSX: CM Sends DSX-REQ with TA ID 34. DSX: Got CMTS DSA Mngmnt msg DSX: Valid TA index 0 found for CMTS TA ID 34. Service Add Response rejected - Unspecified reason DSX: CMTS DSX-RSP error code 3 - response ignored. DSX-REQ Parameters: ------------------. . . DSX-RSP Parameters: ------------------Upstream_Service_Flow_Encoding : Service_Flow_Reference = 1 SF_Error_Encoding : Errored_Parameter = 15 Error_Code = 3 DSX: CM Sends DSX-NAK with TA ID 34, error code 3. DSX-ACK Parameters: ------------------DSX: Indicate - Transaction Type 0 held/finished with Code 3 DSX: Indicate - sfHandle 8 DSX: Indicate - sfHandle 9 13:21:21 RT 53 DSXT send_result_callp: conNum:3 Line:2 Result:2 0002:08:32.610 PP => 10.213.2.32:2427 (size=23) 526 37531 No Bandwidth 0002:08:32.670 10.213.2.32:2427 => PP (len=66) DLCX 37532 aaln/[email protected] MGCP 1.0 NCS 1.0 0002:08:32.675 PP => 10.213.2.32:2427 (size=30) 250 37532 Connections Deleted 0002:08:32.685 10.213.2.32:2427 => PP (len=105) RQNT 37533 aaln/[email protected] MGCP 1.0 NCS 1.0 X: 29899 S: ro Q: loop R: hu(N), hf(N)



47


Nadat de MTA heeft doorgegeven dat de telefoon werd uitgehaakt, gaat de CMS vragen om een connectie op te zetten met een CRCX. De CM stuurt vervolgens een DSA request naar de CMTS sturen. DE CM krijgt echter de melding “Service Add Response rejected”. Daarom gaat hij nog een 2de maal proberen en stuurt opnieuw een DSA-request. De CMTS antwoordt hierop met error code 3, waarop de MTA het NCS bericht “no bandwith” naar de CMS stuurt. De verbinding wordt nu verbroken door de DLCX. Daarna stuurt de CMS een RQNT met S : ro wat wil zeggen dat de MTA de recorder toon moet afspelen wat “netwerk overbelast” betekent.

6.3.3.

Classifiers zijn omgewisseld

Van twee bestaande Service flows werden de classifiers omgewisseld. Hierdoor wordt de data over een verkeerde service flow gezonden. Dit kan tot gevolg hebben dat er bijvoorbeeld jitter en delay’s ontstaan omdat de prioriteiten niet meer van toepassing zijn. Wij hebben bij deze test de classifier van de SNMP service flow omgewisseld met deze van de voice service flow. Zolang er geen grote belasting is op het netwerk, is er geen probleem. We merken wel op de CMTS dat er geen service flow werd opgezet voor voice. BSR58PROP01:7A#show cable modem 0000.cab3.efe4 svc-flow-id Service flow id Interface Flow Direction Flow Max Rate 845 cable 0/1 Upstream 192000 846 cable 0/1 Upstream 30000 847 cable 0/1 Upstream 30000 848 cable 0/1 Downstream 6000000 849 cable 0/1 Downstream 10000 850 cable 0/1 Downstream 10000

Wanneer we in ons geval geen SNMP request uitvoeren dan wordt de service flow, die normaal gebruikt wordt voor voice, niet gebruikt en wordt hij dus ook niet weergegeven op de router.

6.3.4.

Verkeerde service flow naam

Stel dat we de configuratie van onze MTA’s wensen aan te passen en we vullen per ongeluk een verkeerde service flow naam in de CM configuratiefile. Wij gaven in onze configuratie file de naam CALLup ipv DefCSup. Dit wil zeggen dat we een andere naam geven aan een bepaalde SF in de configuratiefile tegenover de configuratie van de CMTS. Wat gaat er dan gebeuren? In ons geval maken we van onze service flows primaire service flows in de configuratiefile. Dit betekent dat de service flows worden gebruikt en gecontroleerd tijdens het registratieproces. Als de service flow namen niet overeenstemmen, dan kan deze service flow niet worden opgezet en zal de modem niet in dienst komen.




48

7. Capaciteitsplanning Het is uitermate belangrijk om een goede capaciteitsplanning op te stellen wanneer men een goed product wenst aan te bieden. Daarom moet je weten wat er op het netwerk gebeurt. • Wanneer wordt er het meest gesurft? • Hoeveel bedraagt het upload en download verkeer? • Hoeveel klanten zijn er in een bepaald gebied aangesloten op een node? • Welk product hebben deze klanten? Hoeveel procent hebben het product Comfortnet? Hoeveel een Expressnet Plus? … • Zijn er veel “gamers” aangesloten op een bepaalde node? Dit alles komt men te weten wanneer de data van de probes in de backbone wordt samengelegd met de gegegens uit de klantendatabase. Deze gegevens worden dan verwerkt met computerprogramma’s zodat men continu kan opvolgen op welke nodes de limiet bijna wordt bereikt. Door de breedte frequentieband en de modulatie methode is het meestal in upstream dat capacitetisproblemen zich voordoen. We ondernemen dan één van de volgende acties: • Upstream Frequentieband van Euro-DOCSIS vergroten: Als men van een band van bijvoorbeeld 800kHz naar 1600kHz gaat, is het duidelijk dat de capaciteit verdubbeld. In de praktijk is dit echter niet zo voor de hand liggend want een frequentieband aanpassen is heel arbeidsintensief. In het upstream kanaal is er ook niet veel plaats in de band om het Euro-DOCSIS kanaal te verbreden. Bovendien daalt de upstream RF signaal-ruis verhouding (die belangrijk is voor foutvrije communicatie) bij elke verdubbeling van de kanaalbreedte met 3 dB. • Loadbalance: Door een poort meer in dienst te nemen, vergroot men de capaciteit. Dit is misschien wel de eenvoudigste manier maar ook een zeer dure omdat het aantal RF- poort om de CMTS hierdoor gevoelig toeneemt. • Modulatie methode aanpassen: Als de signaal/ruis verhouding het toelaat, kan men kiezen voor een andere modulatiemethode. Als men van QPSK overstapt naar 16QAM verdubbelt men de capaciteit. Nog beter is het om te kunnen overschakelen van QPSK naar 64 QAM. In dit geval verviervoudigd men de capaciteit. In de praktijk kan dit ook niet altijd worden toegepast omdat het een heel zuiver netwerk vereist. • Opsplitsen van de node: Bij nodes waar heel veel klanten op zijn aangesloten, kan er ook worden gekozen om de node op te splitsen. Hiervoor zijn er echter infrastructuur werken in de field nodig, wat deze oplossing zeer duuur maakt. • Aanpassen codec: Voor een VoIP gesprek kan men de bitstroom beperken door een andere codec te gebruiken. Standaard wordt de G711 standaard gebruikt, maar stel dat men overschakeld naar de G729 standaard, dan betekent dit reeds een aanzienlijke winst aan capaciteit. Wanneer we nieuwe diensten gaan aanbieden is het natuurlijk van groot belang dat we weten hoeveel bandbreedte deze dienst vereist en wat de eventuele gevolgen zijn voor het ander dataverkeer. Daarom hebben we getest hoeveel bandbreedte een gesprek vereist en wat er gebeurt met het internetverkeer of Best Effort services. Het is echter niet de bedoeling dat we hier de troughput van het Telenetkanaal en het beheer hiervan uit de doeken doen want dit is vertrouwelijke informatie. Steven Vlemincx Groep-T Graduaat Telecommunicatietechnieken


49


7.1. Theoretisch 7.1.1.

Downstream

In downstream is de DOCSIS modulatie methode 64 QAM.128 QAM is hier ook mogelijk maar vereist wel een zeer goede SNR. Bij 64QAM worden 8 bits per Hz gemoduleerd. Om een vergelijking te maken met de kanaalbreedte in upstream, maken we de capaciteitsberekening met dezelfde kanaalbreedte als in upstream. Capaciteit

= Kanaalbreedte x aantal bits/hz = 800 kHz x 8 bits/hz = 6,4Mbps

Als we rekenig houden met de roll off van het kanaal, dan bekomen we het volgende: Effectieve capaciteit = Capaciteit x 8/10 = 6,4Mbps x 8/10 = 5,12Mbps Het werkelijk downstream kanaal van Euro-DOCSIS bedraagt 8MHz. Dit wil dan ook zeggen dat de werkelijk capaciteit 10 maal groter is dan de berekende capaciteit.De DS capaciteit bedraagt dus ongeveer 51,2Mbps.

7.1.2.

Upstream

In upstream is de capaciteit een stuk beperkter. In upstream is de regel om 16 QAM te gebruiken, maar de upstream band bevindt zich onderaan in het frequentiespectrum en is dus gevoeliger voor ruis dan down. Daarom is het soms noodzakelijk om van 16QAM terug te vallen naar QPSK. Op dat moment verliezen we ongeveer 50 % van onze capaciteit. We verduidelijken dit aan de hand van volgende berekening: Omdat we onze testen met een 800 kHz kanaal uitvoeren zodat we de maximum capaciteit vrij makkelijk kunnen bereiken, gebruiken we bij de berekening ook deze kanaalbreedte.

7.1.2.1. QPSK

Kanaal breedte: 800 kHz QPSK moduleert 2 bits / Hz want geeft enkel het quadrant aan. Er zijn dus 4 verschillende punten. Capaciteit


Rekening houdens met de roll off van het kanaal, bekomen we de volgende capaciteit. Effectieve capaciteit = Capaciteit x 8/10 = 1,6 Mbps x 8/10 = 1,28Mbps



50


7.1.2.2. 16QAM

Kanaal breedte: 800 kHz 16 QAM moduleert 4 bits / Hz want 16 QAM moduleert zowel in amplitude als in fase zodat er 16 verschillende punten ontstaan. Capaciteit


Als we rekenig houden met de roll off van het kanaal, dan bekomen we het volgende: Effectieve capaciteit = Capaciteit x 8/10 = 3,2Mbps x 8/10 = 2,56Mbps

7.1.2.3. Besluit

De berekende capaciteit is natuurlijk de capaciteit van het DOCSIS kanaal inclusief de headers en foutcontrole van de bovenliggende lagen. Onze netto capaciteit ligt dus nog een beetje lager. We weten dat een telefoongesprek ongeveer 100kbit in beslag neemt. Dit neemt een aanzienlijk stuk van de capaciteit in beslag bij QPSK. Het ligt voor de hand dat we ervoor moeten zorgen dat we niet in QPSK werken en ook een grotere kanaalbreedte moeten gebruiken in het netwerk.

7.2. Praktisch Aan de hand van een aantal testen, tonen we wat de invloed is van VoIP op de capaciteit van BEservices is. We beperken ons hier tot de testen in upstream omdat dit kanaal het makkelijkste in congestie gaat door de kleinere capaciteit. Tevens is er hier soms sprake van capaciteitsverlies door omschakeling 16QAM naar QPSK. Tijdens onze testen beperken we ook de kanaalbreedte van het DOCSIS kanaal beperkt tot 800kHz.

7.2.1.

Test setup

Om de testen uit te voeren maken we gebruik van: • een call generator • een traffic generator • 5 MTA’s



51


MTA 1

RF

CMTS

MTA 2

IP Call generator

MTA 3

MTA 4

Traffic generator

MTA 5

Figuur 12: Test setup met een call generator en een traffic generator

We sluiten 5 MTA’s aan op een RF net dat is geconnecteerd met de CMTS (grijze stippellijn). We laten deze MTA’s registreren met een configuratiefile waarin rate limiting wordt aangezet in upstream op 512Kbps. We sluiten de ethernet poort van de MTA’s aan op de poorten 2 tot en met 6 van de traffic generator (rode lijnen). Een traffic generator is in staat om pakketten uit te sturen aan het ritme dat er is ingesteld. In ons geval zijn dit ethernet pakketten zodat we de best effort services kunnen simuleren. Interface 1 van de traffic generator verbinden we met de 100BaseT interface van de CMTS (groen lijn). Hiermee simuleren we als het ware de backbone en kunnen we pakketten naar de MTA’s sturen (= downstream) en kijken hoeveel pakketten er werkelijk van de MTA’s de backbone bereiken (= upstream). De setup om de capaciteit voor Best effort services te testen is nu klaar. Natuurlijk willen we ook VoIP gesprekken toevoegen. We maken hier gebruik van de G711 codec omdat deze wordt gebruikt in ons netwerk. Om de gesprekken op te zetten maken we gebruik van een call generator. Dit toestel simuleert een aantal telefoontoestellen. We verbinden telkens beide lijninterfaces van de 4 MTA’s met onze call generator. Daarna kunnen we het call programma aanmaken in de call generator. Hiermee stellen we in welke interface van de call generator naar welk telefoonnummer moet bellen. We kiezen voor volgend programma: A -> B ; B -> A Hiervoor stellen we steeds per call programma 2 nummers in, namelijk A en B. De ingestelde interface van de call generator gaat eerst van lijn A naar lijn B bellen door het telefoonnummer van B te vormen. De call generator ziet een oproep toekomen op de interface waarop B is geprogrammeerd. Hij haakt deze lijn uit en de conversatie kan beginnen. Tijdens de Steven Vlemincx Groep-T Graduaat Telecommunicatietechnieken


52


conversatie wordt er een controle van de lijn gedaan door een signaal uit te sturen dat verschillende frequenties bevat. Na het beëindigen van het gesprek contacteert B A op dezelfde manier. Om metingen mogelijk te maken, kan je best voor een gespreksduur van enkele minuten kiezen.

7.2.1.1. Programmatie traffic generator

Indien u graag verneemt hoe men te werk gaat om de simulatie op te zetten op de traffic generator, dan verwijzen we u graag door naar bijlage G.

7.2.1.2. Programmatie call generator

In bijlage H geven we graag een overzicht van welke parameters ingesteld moeten worden op de call generator.

7.2.2.

Testen

Het spreekt voor zich dat er een groot verschil is in capaciteit wanneer we overschakelen van QPSK naar 16QAM. Daarom zullen we hier praktisch het vergelijk maken zoals we dit ook deden in de theorie.

7.2.2.1. QPSK

We hebben berekend dat QPSK in onze setup een capaciteit heeft 1.6Mbps. Dit is echter niet de effectieve througput, want we moeten ook rekening houden met headers en foutcontroles waarvoor bits worden toegevoegd. Daarom gaan we controleren hoeveel data er werkelijk door het kanaal kan in QPSK. We gebruiken hiervoor de traffic generator, zonder dat er gesprekken werden opgezet. We moeten natuurlijk wel even de CMTS in QPSK zetten. Bij slechte netwerkomstandigheden gebeurt dit automatisch omdat QPSK staat ingesteld als een hop actie. Hiervoor zijn volgende settings in de configuratiefile noodzakelijk. hop hop hop hop

period action action action

30 frequency 23800000 priority 128 frequency 24600000 priority 128 modulation-profile 2 priority 129

Als het upstreamkanaal vervuild is, gaat de CMTS de twee hop kanalen bekijken en indien deze bruikbaar zijn, dan gaat 1 van deze kanalen gebruikt worden. Indien er echter een verhoogde ruisvloer is, dan hebben de hop kanalen evenveel last van de ruis als het oorspronkelijke kanaal, zodat hoppen niet veel zin heeft. Op dat moment gaat de CMTS modulatie profiel 2 gaan gebruiken wat overeenstemt met QPSK. QPSK heeft een lagere SNR nodig, zodat de werking verzekerd blijft. We kunnen QPSK als vast modulatie profiel definiëren door volgend commando in te geven: cable upstream 0 modulation-profile 2




53

Nu onze CMTS, de modems en de traffic generator klaar zijn, kunnen we de smartcounters bekijken.

Figuur 13: SmartCounters, QPSK, zonder gesprekken

We concentreren ons op de upstreamcapaciteit van het DOCSIS kanaal. Dit wil zeggen dat we de RX gegevens van kanaal 1 moeten bekijken. • • •

139872Bps 8 x 139872Bps = 1119kbps 1119kbps / 1280kbps = 87%

We zien dus dat er maar 87% van het kanaal effectief gebruikt is voor data. De overige 13 % is overhead. Als we aandachtig kijken, dan zien we dat er meer bits verzonden worden door de modems dan dat er werkelijk ontvangen worden. Dit heeft 2 redenen: • de rate limitting die werd toegevoegd aan de modem config. • Het Euro-DOCSIS kanaal dat volledig in gebruik is. Nu gaan we gesprekken opzetten vanop de call generator en we kijken wat de invloed hiervan is op de capaciteit van best effort services. Zoals we gezien hebben in het hoofdstuk van de service flows, krijgt een gesprek steeds de capaciteit die het nodig heeft ten koste van best effort services.We zetten 3 gesprekken op binnen dezelfde upstreamgroep.Er zijn dus 6 RTP-streams. Aan de hand van de statistieken op de CMTS kunnen we berekenen hoeveel capaciteit er wordt gebruikt voor een RTP-stream op IP niveau. BSR58PROP01:7A(config)#show cable mode 0000.caB3.c010 svc-flow-id Service flow id Interface Flow Direction Flow Max Rate 1221 cable 0/0 Upstream 1200000 1222 cable 0/0 Upstream 30000 1223 cable 0/0 Upstream 30000 1224 cable 0/0 Downstream 10240000 1225 cable 0/0 Downstream 10000 1226 cable 0/0 Downstream 10000 1527 cable 0/0 Upstream no restriction 1528 cable 0/0 Downstream 10000000 BSR58PROP01:7A(config)#show cable qos svc-flow statistics 0/0 1527 Interface index: 32513 Qos service flow id: 1527 Qos service flow packets: 11203 Steven Vlemincx Groep-T Graduaat Telecommunicatietechnieken


54


Qos service flow octets: Qos service flow time created: Qos service flow time active: Qos service flow PHS unknowns: Qos service flow policed drop packets: Qos service flow policed delay packets: Qos service flow class: Qos service flow admit status: Qos service flow admit restrict time:

2442254 25984965 224 0 0 0 DefUGS Success 0

Als we deze gegevens even interpreteren: • 2442254 Bytes / 224 seconden = 10902Bps = 87 kbps We kunnen deze berekening ook nog controleren aan de hand van de gegevens die we krijgen van de Smartbits.

Figuur 14: SmartCounters, QPSK, met 6 gesprekken

Door het opzetten van 6 gesprekken is onze capaciteit die beschikbaar was voor best effort gedaald van 139872 Bps naar 58656 Bps. • 58656 Bps • 58656 x 8 = 469 kbps Zonder gesprekken was onze capaciteit gelijk aan 1,092 Mbps • 1,119 Mbps – 469 kbps = 650 kbps We hadden dus 6 RTP streams binnen eenzelfde upstream groep: • 650 kbps / 6 streams = 108 kbps / stream Zoals we zien is er een afwijking van ongeveer 20 kbps tussen de gegevens uit de statistieken van de CMTS en de gegevens van de Smartbits. Dit komt omdat de CMTS de bandbreedte weergeeft die gebruikt wordt op laag 3 zijnde het IPverkeer. De Smartbits geeft een beeld van de werkelijke troughput van het kanaal. Hier wordt de Docsis overhead dus mee in rekening gebracht. Het is dan ook deze bandbreedte waarmee we rekening moeten houden bij onze capaciteitsplanning.

7.2.2.2. 16QAM

In normale omstandigheden is de modulatie methode van een upstreamkanaal op een CMTS ingesteld op 16QAM. Dit wordt als volgt ingesteld: cable upstream 0 modulation-profile 1 Steven Vlemincx Groep-T Graduaat Telecommunicatietechnieken



55

Om de effectieve throughput van een 16QAM gemoduleerd kanaal op te meten maken we weer gebruik van de traffic generator zonder dat er gesprekken aan de gang zijn.

Figuur 15: SmartCounters, 16 QAM, zonder gesprekken

Ook nu gaan we weer proberen te achterhalen hoe groot de effectieve throughput van het kanaal is. • 267,712 kBps • 8 x 267712 Bps = 2,142 Mbps • 2,142 Mbps / 2,56 Mbps = 84% Nu kunnen we nogmaals 4 gesprekken opzetten, zodat er 6 gespreksstromen ontstaan binnen onze upstream groep. BSR58PROP01:7A(config)#show cable mode 0000.caB3.c010 svc-flow-id Service flow id Interface Flow Direction Flow Max Rate 1221 cable 0/0 Upstream 1200000 1222 cable 0/0 Upstream 30000 1223 cable 0/0 Upstream 30000 1224 cable 0/0 Downstream 10240000 1225 cable 0/0 Downstream 10000 1226 cable 0/0 Downstream 10000 1509 cable 0/0 Upstream no restriction 1510 cable 0/0 Downstream 10000000 BSR58PROP01:7A(config)#show cable qos svc-flow statistics 0/0 1509 Interface index: 32513 Qos service flow id: 1509 Qos service flow packets: 18508 Qos service flow octets: 4034744 Qos service flow time created: 25916926 Qos service flow time active: 370 Qos service flow PHS unknowns: 0 Qos service flow policed drop packets: 0 Qos service flow policed delay packets: 0 Qos service flow class: DefUGS Qos service flow admit status: Success Qos service flow admit restrict time: 0

We herhalen onze berekening: • 4034744 Bytes / 370 seconden = 10904Bps = 87,2 kbps



56


Figuur 16: SmartCounters, 16 QAM, met 6 gesprekken

Door het opzetten van onze gesprekken is de capaciteit voor BE gedaald naar 186496 Bps. • 186496 Bps • 8 X 186496 Bps = 1,492 Mbps Zonder gesprekken hadden we een capaciteit van 2,142 Mbps. • 2,142 Mbps – 1,492 Mbps = 650 kbps We hadden 8 gespreksstromen: • 650 kbps / 6 streams = 108 kbps/stream

7.2.2.3. Vergelijking QPSK <-> 16QAM

QPSK Theoretisch throughput 1,6Mbps Gemeten throughput 1,092 Mbps Rendement 87% Bandbreedte van een gesprek 87 kbps op laag 3 Bandbreedte van een gesprek 108 kbps/stream voor Euro-DOCSIS

16QAM 2,56Mbps 2,142 Mbps 84% 87,2 kbps 108 kbps/stream

Zoals je ziet bekomen we een veel grotere capaciteit met QPSK dan met 16QAM. QPSK is echter wel een hop actie. Daarom moeten we hiermee zeker rekening houden bij het dimentioneren van het netwerk. Want de services mogen immers niet veel last ondervinden van deze hop actie.

7.2.3.

G729

De G711 codec maakt gebruik van de normale PCM codering. Dit wil zeggen dat we een stream van 64Kbps bekomen. Hierdoor moeten we ongeveer 100Kbps aan data transporteren op DOCSIS niveau. Door de G729 codec te gebruiken, beperken we de bandbreedte die een gesprek nodig heeft.Dit zullen we aan de hand van de volgende testen bewijzen.De G729 standaard wordt bijvoorbeeld gebruikt bij GSM-telefonie.



57


De kwaliteit van spraak die met de G729 wordt verstuurt, verliest wel aan kwaliteit ten opzichte van de G711. Hierdoor blijft het noodzakelijk om faxen en modems over te schakelen naar de G729. Deze omschakeling moet de CMS automatisch bevelen wanneer de CMS ontdekt dat het gesprek wordt opgezet door een fax of een modem. Hoe gaan we te werk? • we schakelen de CMS over naar de G729 standaard • we telnetten naar de MTA om de NCS berichten te loggen.Je ziet hier dat het gesprek wordt opgezet en dat gebruik maakt van de G729. CRCX 568 aaln/[email protected] MGCP 1.0 NCS 1.0 C: 4D002B570002359A6531 M: inactive L: p:20, a:G729;PCMA, sc-rtp:60/50, sc-rtcp:80/70 Ook nu zullen we de metingen aan da hand van de service flow statistieken op de CMTS en de Smartbits uitvoeren.Een verlijking QPSK ten opzichte van 16QAM hebben we reeds gedaan voor de G711 standaard.We konden hier zien dat de RTP stream in beide gevallen evenveel bandbreedte gebruikte.We gaan ons dan hier beperken tot de meting bij 16QAM. We beginnen met de CMTS statistieken: BSR58PROP01:7A(config-if)#show cable mode 0000.cab3.C010 svc-flow-id Service flow id Interface Flow Direction Flow Max Rate 573 cable 0/0 Upstream 1200000 574 cable 0/0 Upstream 30000 575 cable 0/0 Upstream 30000 576 cable 0/0 Downstream 10240000 577 cable 0/0 Downstream 10000 578 cable 0/0 Downstream 10000 599 cable 0/0 Upstream no restriction 600 cable 0/0 Downstream 10000000 BSR58PROP01:7A(config-if)#show cable qos svc-flow statistics 0/0 599 Interface index: Qos service flow id: Qos service flow packets: Qos service flow octets: Qos service flow time created: Qos service flow time active: Qos service flow PHS unknowns: Qos service flow policed drop packets: Qos service flow policed delay packets: Qos service flow class: Qos service flow admit status: Qos service flow admit restrict time:

32513 599 20644 1609992 1159498 413 0 0 0 DefUGS Success 0

Laten we deze gegevens interpreteren. • 1609992 Bytes / 413 seconden = 3898Bps = 31,2 kbps Dit is dus de bandbreedte die door 1 gesprek wordt opgesoepeerd op laag 3. Aan de hand de Smartbits kunnen we berekenen hoeveel bandbreedte dit in beslag neemt in het Euro-DOCSIS kanaal.



58


Figuur 17: SmartCounters, 16 QAM, met 6 gesprekken met de G729 codec

Door het opzetten van onze gesprekken is de capaciteit voor BE gedaald naar 215072 Bps. • 215072 Bps • 8 X 215072 Bps = 1,72 Mbps Zonder gesprekken hadden we een capaciteit van 2,142 Mbps • 2,142 Mbps – 1,72 Mbps = 422 kbps We hadden 6 gespreksstromen: • 422 kbps / 6 streams = 70 kbps/stream Zoals men kan zien biedt deze standaard een aanzienlijke reductie van de bandbreedte van een gesprek, maar resulteert tevens in een kwaliteitsvermindering van het gesprek. Dit schrikt de operatoren natuurlijk af.

7.2.4. Besluit Door gebruik te maken van de G729 codec in plaats van de G711 verminderen we de bandbreedte van een gesprek met ongeveer 40kbps in het DOCSIS kanaal.Dit is natuurlijk meer dan welkom om de beschikbare bandbreedte van het upstream kanaal op peil te houden. Overschakelen naar de G729 codec houdt echter risico’s in.De kwaliteit van de gesprekken neemt af en ook neemt de kans op fax/modem-problemen toe omdat deze moeten overschakelen naar de G711.Daarom zijn operatoren een beetje terughoudend om de G729 te gebruiken. Bij capaciteitsplanning moeten we steeds rekening houden met de bandbreedte die een service in beslag neemt op DOCSIS niveau.Het is echter wel handig om te weten hoeveel bandbreedte en wordt gebruik op laag 3.Zo heb je een beeld van de Euro-DOCSIS overhead die bij de data komt.



59


8. Echo Echo is een veel voorkomend probleem bij het implementeren van VoIP. Bij traditionele telefonie is de echo minstens evenveel aanwezig, maar is hij niet storend omdat de vertraging heel miniem is. Bij VoIP is de vertraging tussen spreken en ontvangen groot genoeg om de echo van het gesproken signaal te onderscheiden. In dit hoofdstuk zullen we aandacht besteden aan de oorzaak van echo en de mogelijke oplossing om echo te voorkomen.

8.1. Theoretisch 8.1.1.

Algemeen

Echo is een lek van de Tx naar de Rx.Echo kan enkel in analoge netwerkgedeeltes ontstaat, want bits lekken niet. Dit wil echter niet zeggen dat het digitale netwerkgedeelte geen invloed heeft op de echo. Integendeel, het digitale gedeelte van ons netwerk zorgt voor vertragingen, waardoor de echo hoorbaar wordt.

Figuur 18: Netwerkoverzicht, analoog en digitaal

Zoals we zien zijn het de eindcircuits waar de signalen analoog zijn. Langs de zijde van de VoIP installatie is het analoge netwerkgedeelte beperkt tot het telefoontoestel, enkele meter bekabeling en de lijninterface van de MTA. Bij traditionele telefonie ligt dit iets anders. Hier vertrekken we analoog of digitaal vanuit de centrale naar de straatcabinetten. Vanaf hier is het dan steeds analoog over verschillende verdelers en 2 tot 3 km bekabeling tot aan het telefoontoestel van de klant. Een kabel in de straat kan gemakkelijk 100 paren bevatten. Welke technologie we ook gebruiken, we moeten ervoor proberen te zorgen dat de echo niet hoorbaar is.



60


8.1.2.

Soorten echo

We kunnen 2 verschillende types van echo onderscheiden. • akoestische echo • echo door slechte balancering van de eindcircuits

8.1.2.1. Akoestische echo

Akoestische echo is de terugkoppeling van een deel van het signaal door overspraak van de luidspreker op de microfoon. De echo canceller kan deze echo moeilijk compenseren omdat het signaal dikwijls een heel andere vorm heeft dan de verwachte echo. Deze echo is makkelijk te voorkomen door het luidspreker volume van de telefoon aan te passen. Wanneer de A-zijde akoestische echo hoort, dan moet de B-zijde het luidspreker niveau aanpassen. Je kan de vraag stellen, waarom deze echo niet hoorbaar is tussen 2 klanten met traditionele telefonie. Wel ook hier is de echo even sterk aanwezig, maar omdat de vertraging of de delay hier heel klein is, is de echo niet hoorbaar vanwege het mask-effect. Dit betekent dat de echo niet hoorbaar is door de luidere klank van het gesprek zelf.

8.1.2.2. Echo door slecht balancering

Dit type van echo ontstaat door een slechte balancering van de lijninterface. In het ideale geval wordt de lijninterface afgesloten met een impedantie van 600Ω. De impedantie van een telefoontoestel wordt eigenlijk bepaald door de kwaliteit van de hybrid in het telefoontoestel. De hybrid zorgt voor de omzetting van 2-draads naar 4-draads bekabeling. Bij het ontwerpen van een telefoontoestel houdt de fabrikant rekening met de impedantie van lange lijnen. De fabrikant verwacht namelijk dat het toestel wordt aangesloten op een lijn van 2km of meer, zoals dit het geval is bij traditionele telefonie. Daarom hebben de meeste telefoontoestellen een impedantie van slechts 400Ω. De bijkomende impedantie van 200Ω, wordt verwacht van de bekabeling. Bij een VoIP installatie is de lijn heel kort. We gaan namelijk digitaal tot bij de klant over het HFC netwerk. Eens bij de klant thuis wordt er in de MTA overgegaan naar analoog waar er meestal slechts enkele meters bekabeling is aangesloten. De impedantie van de lijn is dus verwaarloosbaar. We mogen dus stellen dat de impedantie waarmee de lijninterface wordt afgesloten, dezelfde impedantie van het telefoontoestel of de hybrid is. Hebben we een toestel met een lage impedantie dan zal er bij de omzetting van 2 naar 4 draadsbekabeling in de hybrid, ook een gedeelte van het signaal worden gereflecteerd. Dit signaal ervaren we als echo aan de andere zijde. Dit type echo kan geannuleerd worden door een echo canceller omdat het patroon dat terug wordt gezonden kan voorspeld worden.Een echo canceller7 gaat trachten om het patroon van het ontvangen signaal terug te vinden in het te versturen signaal.Indien eenzelfde patroon wordt gevonden, wordt dit verwijdert. Er zit dan ook een echo canceller ingebouwd in de MTA.

8.1.3.

Belangrijke termen

We beginnen met het toelichten van enkele belangrijke termen die hier van toepassing zijn.

7

Echo cancellers, zie hoofdstuk 8.1.6 Steven Vlemincx




61

8.1.3.1. Echo Return loss : ERL

Echo return loss of ERL geeft het verschil weer tussen het aangeboden signaal en het gereflecteerd signaal. Dit is dus de verzwakking van het gereflecteerd signaal of echo. Volgens de G168 aanbeveling van ITU moet de ERL van het ganse netwerk minstens 55dB bedragen. Zoniet is de echo hoorbaar. Uit testen die we hebben gedaan blijkt echter dat zelf een echo van 60dB nog hoorbaar is. De ERL van een telefoon zou ongeveer 12dB moeten bedragen, maar indien de telefoon slecht gebalanceerd is kan dit soms maar 5 dB bedragen. In dit geval is de kans dat onze echo hoorbaar is zeer groot.

8.1.3.2. Echo Return Loss Enhancement : ERLE

We kunnen onze echo extra verzwakken door het gebruik van echo cancellers, zodat onze echo niet meer hoorbaar is. Echo return loss enhancement of ERLE geeft aan hoeveel decibel de echo canceller het echosignaal onderdrukt. Een typische waarde is hier 35dB.

8.1.3.3. Send Loudness Rating : SLR

Send loudness rating geeft de geluidssterkte in dB weer tussen de mond van de spreker en de elektrische interface.

8.1.3.4. Receive Loudness Rating : RLR

Receive loudness rating of RLR geeft de geluidssterkte in dB weer tussen de elektrische interface en het oor van de ontvanger.

8.1.3.5. Talker Echo Loudness Rating : TELR

Talker echo loudness rating of TELR geeft de verzwakking aan van de signaalsterkte tussen de spreker zijn mond en de spreker zijn oor. Hoe groter deze waarde is, hoe minder echo de spreker kan waarnemen.

8.1.3.6. Combined echo return loss through system : ACOM

Combined echo return loss through system of ACOM geeft de verzwakking in dB van een systeem op echo. Dit kan makkelijk berekend worden door de geluidssterkte van het echo signaal te vergelijken met het oorspronkelijk aangelegde signaal. ACOM = Rin - Sout



62


8.1.3.6.1 Roundtrip delay

De roundtrip delay is de tijd tussen het verzenden van het signaal langs de Tx zijde, en het terug ontvangen van de echo van dit signaal langs de Rx zijde. De roundtrip delay heeft geen invloed op de grootte van de echo, maar maakt de echo wel hoorbaar als de roundtrip delay groter wordt dan 25 msec. Spijtig genoeg is dit steeds zo in het geval van VoIP. Als we weten dat in ons geval de packetisationtime al 20msec bedraagd en we weten dat er steeds 2 pakketten in de de-jitterbuffer zitten, dan hebben we al een delay van 40msec.

8.1.3.6.2 Loss plan

Met het loss plan definieer je waar je analoog signaal verzwakt wordt en hoeveel het verzwakt mag worden. Telenet heeft hetzelfde loss plan aangevraagd aan het BIPT als zijn concurrenten en heeft dit ook bekomen. Dit is ook belangrijk want anders krijg je een zeer ingewikkelde situatie. Je moet er namelijk voor zorgen dat je ongeveer 12 dB verzwakt tussen zender en ontvanger. Traditionele telefonie gebruikt een lossplan van -3/-9 wat erop wijst dat een signaal aan zender zijde met 3dB wordt verzwakt en aan ontvanger zijde nog eens 9 dB. Wanneer we zouden opteren om een -6/-6 loss plan in te voeren voor VoIP, dan gaat het lijken alsof we soms luide gesprekken en soms stille gesprekken hebben. We zullen dit even verduidelijken: MTA

Ù

MTA

BGC

Ù

MTA

Tx Rx

-6dB + -6dB = -12 dB

OK

-3dB + -6dB = -9 dB -9dB + -6 dB = -15dB

NOK NOK

Je merkt het al. Dit zou hilarische toestanden met zich meebrengen. De Belgacom klant zou mogen fluisteren en de MTA klant zou deze nog kunnen verstaan. Maar de MTA klant zou bijna moeten roepen wil de andere hem nog goed kunnen verstaan. Daarom werd er dus gekozen om het traditionele loss plan te behouden. Dit zijn parameters waarmee de fabrikant van een MTA rekening moet houden en in de lijntemplate stopt (zie MTAconfiguratie hoofdstuk 3.3).

8.1.3.6.3 Echo tail

De echo tail is de tijd dat een echo canceller een signaal opslaat in zijn buffer zodat hij de terugkerende echo kan cancellen. Deze tijden zijn als volgt: - 32 msec in de MTA - 128 msec in de PVG Tijdens een gesprek heeft de MTA dus steeds de laatste 32msec van een gesprek in zijn buffer opgeslagen. Als er dan signalen op het Tx pad van de lijninterface komen, dan zal de echo canceller in de MTA gedurende deze 32 msec kijken of er een overeenkomst is tussen het signaal in de buffer en dat op de lijninterface. Bij de rollout van PacketCable was de echotail slechts 8msec. Dit bleek echter onvoldoende te zijn wanneer er een DECT telefoon op de MTA werd aangesloten. ( zie 8.3)



63


8.1.4.

Overzicht

TELR(A) = SLR(A) + verzwakking van lossplan Tx path + ERL(B) + verzwakking in loss plan Rx path + RLR(A)

Figuur 19: Echo, een overzicht

8.1.5.

Invloed op echo

8.1.5.1. Hybrids

Zoals reeds eerder werd aangehaald, is de hybrid oorzaak nummer 1 van echo. Omdat een hybrid een niet-ideaal device is, zal een bepaald stuk van het vierdraads inkomend signaal terugvloeien naar het vierdraads uitgaand signaal. Er wordt verwacht dat een hybrid ongeveer een ERL van 15 tot 20 dB heeft, maar als de uitgangsimpedantie niet overeenstemt met de ingangsimpedantie van de telefoon, dan zal de ERL verkleinen en zal de crosstalk vergroten. Het gevolg hiervan is dat de echo luider waarneembaar is.

8.1.5.2. Loudness

Het spreekt voor zich dat als we een luid signaal aanleggen, we hiervan sneller een echo zullen horen dan een minder luid ingangssignaal. De verzwakkingen in het netwerk zijn gelijk voor alle signaalsterktes.

8.1.5.3. Routers

Als we routers toevoegen aan ons netwerk, of beter gezegd het aantal hops verhogen, dan gaat dit niet direct een invloed hebben op de echo. De signaalsterkte verandert namelijk niet, want een router werkt in het digitale netwerkgedeelte. Het toevoegen van routers heeft wel een invloed hebben op de delay. Hierdoor wordt de echo natuurlijk beter hoorbaar. Hoe groter de delay is, hoe meer de echo als storend ervaren wordt.



64


8.1.5.4. DQOS

Dynamische quality of service heeft ook niet direct een invloed op de echo, maar doordat we een voorbehouden service flow opzetten voor ons gesprek en dit met de hoogste prioriteit, kunnen we de delay beperken. Dit heeft natuurlijk een positieve invloed op ons gesprek.

8.1.6.

Echo cancellers

Een Echo canceller of EC heeft als doel om het echo signaal te onderdrukken. Het is belangrijk dat we de cancellers zo kort mogelijk bij de oorzaak van de echo plaatsen zodat de echo tail zo klein mogelijk kan gehouden worden, want hoe groter de buffer genomen moet worden hoe meer processing er nodig is. Maar de delay mag niet oplopen, dus wil dit zeggen dat er krachtiger processoren nodig zijn. In de MTA werd daarom een EC geplaatst in de DSP met een echo tail van 32 msec om de echo die ontstaat langs MTA zijde te cancellen en in de PVG werd een EC geplaatst om de echo die komt van het PSTN netwerk te cancellen. Hier werd geopteerd voor een dynamische echo tail. De echo tail past zich namelijk aan gedurende het gesprek. Hierdoor blijft de processing toch nog redelijk beperkt. De maximum echo tail is hier 128msec. Hieronder ziet u een schema waar er echo kan veroorzaakt worden.

Figuur 20: Echo, waar mogelijk

De echo die wordt veroorzaakt aan MTA zijde wordt gehoord door de B zijde indien de EC die in de MTA zit ingebouwd zijn werk niet naar behoren doet. Bij een gesprek naar de traditionele telefonie, moet de EC in de PVG de echo cancellen die van het PSTN netwerk komt, anders gaat de klant langs de A kant deze echo horen. De accoustische echo is normaal gezien heel klein in amplitude en wordt dus reeds voldoende geannuleerd door het loss plan om niet hoorbaar meer te zijn voor de andere zijde. De echo vanwege een slechte balancering van de hybrid van de MTA of de PABX, is veel belangrijker. Het is deze echo die de echo canceller moet onderdrukken.

8.1.6.1. Werking van de EC

De werking van een EC is een heel ingewikkeld proces. We gaan dit dan ook niet tot in detail uitzoeken, maar we vonden het wel nodig om de basistechnieken aan te halen. Om de echo te onderdrukken, maakt de EC gebruik van 2 functies, namelijk: • convolution processor (CP) Steven Vlemincx Groep-T Graduaat Telecommunicatietechnieken



•

65

nonlineair processor (NLP)

Convolution processor: De convolution processor slaat het TX signaal op in zijn buffer. Hij houdt deze signalen bij gedurende de tijd van zijn echo tail. In de PVG is dit dus 128ms en aan de MTA zijde 32ms. Aan Rx zijde gaat de processor dan zoeken naar het patroon van het Tx signaal dat passeerde. Als er echo is, dan gaat hij dit patroon zien terug komen en gaat hij dit typisch met ongeveer 18 dB verzwakken. Natuurlijk heeft dit proces een convergentietijd om zijn verwacht echo signaal te kunnen berekenen. Nonlineair processor: De NLP vervangt de echo aan de uitgang van de EC door comfort noise. Hierdoor ontstaat een bijkomende verzwakking van 25dB van het echo signaal in het RX path. Dit proces kan dan ook enkel worden gebruikt bij een éénrichtingsspraak want anders zou ook het signaal van de 2de partij mee worden verzwakt met 25 dB en ga je deze niet meer kunnen horen (1 way speech). Bij een tweerichtingsgesprek werkt alleen de convulution processor. Het is enkel tijdens stiltes in een gesprek dat de NLP in werking schiet.

8.2. Praktisch 8.2.1.

Hoe testen?

Er zijn een aantal dingen waarmee we rekening moeten houden als we testen doen in verband met echo. • We moeten er zeker van zijn dat de echo die we hebben geen akoestische echo is, want dit type echo is de verantwoordelijkheid van de klant. Als de klant de speaker van zijn telefoontoestel te luid zet, dan kunnen wij als operator hier niets aan verhelpen. De enige oplossing die voor zo’n dingen kan gevonden worden is een aanpassing van het loss plan, maar dit is geen optie omdat dit algemeen is voor alle klanten. Daarom is het belangrijk om de hoorn uit te schakelen aan de zijde waar de echo wordt veroorzaakt. • We moeten ons loss plan nameten. Omdat we perfect moeten weten hoeveel verzwakking het gebruikte pad geeft, is het belangrijk dat we het loss plan nameten. Hierdoor kunnen we de grootte van het signaal controleren als we gaan sniffen. • Reconstrueren van de RTP stream. Als we gegevens moeten verzamelen voor de fabrikanten waaruit blijkt dat er echo in het netwerk zit, die niet wordt gecancelled, kan je best een trace nemen van de RTP stream. Deze stream kan je dan nadien terug gaan analyseren, zodat je hem terug kan afspelen. Wanneer men hiervoor het programma Goldwave gebruikt, kan men PCM waardes van het signaal aflezen en controleren met de verwachte waardes van het loss plan. • Logs nemen op de MTA. Het is al belangrijk dat je controleert op welke software versie de MTA werkt. Normaal gezien is dit steeds de laatste, maar het zou natuurlijk kunnen dat er op de betrokken MTA een statische configuratiefile staat die naar een oudere software versie verwijst. Verder is het ook belangrijk dat je gedurende het gesprek de status van de EC opvraagt (aan/uit). Men kan bijvoorbeeld ook de EC een keer uitzetten gedurende een gesprek zodat men de goede werking van de EC kan controleren. Steven Vlemincx Groep-T Graduaat Telecommunicatietechnieken


66


8.2.2.

Opmeten van het loss plan

Een operator moet zijn loss plan kennen. Het is van kapitaal belang dat dit loss plan wordt gecontroleerd volgens alle mogelijke scenario’s • MTA naar Telenet PSTN • Telenet PSTN naar MTA • MTA naar GSM • GSM naar MTA • MTA naar MTA • enzovoort Om het loss plan op te meten maken we gebruik van twee signaal generatoren waarin een telefoontoestel zit ingebouwd. We kunnen dus dit toestel gebruiken om een communicatie op te zetten en vervolgens een geijkt signaal over het netwerk te sturen. Bij onze test stuurden wij een signaal in van 0dBm uit. Aan het ontvangende toestel konden we een signaal van -12dBm meten. Deze test hebben we voor alle types vaste lijn gedaan. De totale verzwakking was dus steeds 12dB.

8.2.3. Reconstructie van de RTP stream Bij sommige problemen waaronder bijvoorbeeld echo is het noodzakelijk om de RTP stream op te vangen in het netwerk en deze terug te reconstrueren. Hiermee kan men: • signaalsterktes achterhalen in het netwerk • mogelijk de oorzaak van het probleem achterhalen • gegevens aan de fabrikanten bezorgen In bijlage I leggen we graag uit hoe we hiervoor te werk gaan.

8.2.4. Logs nemen op de MTA Als we naar de fabrikant willen stappen om te melden dat er een probleem is met hun product, moeten we dit natuurlijk staven aan de hand van gegevens. Daarbij is een DOCSIS trace bijvoorbeeld een goed hulpmiddel. Maar zonder logs te nemen op de MTA, kan de fabrikant het probleem niet achterhalen. Het hoeft dan ook niet gezegd te worden dat het verzamelen van allerlei gegevens die betrekking hebben op het probleem van groot belang is. Ook voor het echo probleem is dit zo. Hier is het bijvoorbeeld heel belangrijk om de DSP (Digital Signal Processor) gegevens van de MTA op te vragen. Volgende commando’s geven relevante info voor de fabrikant voor de meeste problemen. • err_stat 1 : overzicht van de transmissiefouten op PacketCable-niveau • level_stat 1 : overzicht levels • echo_stat 1 : ACOM en ERL • rxtx_stat 1 : hoeveel pakketten worden er verzonden en ontvangen • vp_stat 1 : statistieken in verband met gespreksgegevens (jitter, …) In het geval van echo kan je ook een keer de echo canceller uitschakelen om een vergelijking te kunnen maken. Dit kan je bijvoorbeeld doen met het commando “echo 0 1”.



67


echo Usage: echo <1-based channel> <setting> <setting> : 0 disable : 1 enable : 2 tx_mute DSP>err_stat

1 Return Status: 0 [ 23] DSP> 09:54:42 RT 13 tDSP Error Stats for 1 09:54:42 RT 13 tDSP invalid_header_count: 09:54:42 RT 13 tDSP to_micro_overflow_count: 09:54:42 RT 13 tDSP lost_enh_packet_count: 09:54:42 RT 13 tDSP no_core_packet_count: 09:54:42 RT 13 tDSP pkt_lost_by_network: 09:54:42 RT 13 tDSP invalid_mac_header_count: 09:54:42 RT 13 tDSP invalid ssrc count: 09:54:42 RT 13 tDSP invalid payload count: 09:54:42 RT 13 tDSP rx routing dropped: 09:54:42 RT 13 tDSP p2p invalid pkt count: 09:54:42 RT 13 tDSP rx seq num discont events: 09:54:42 RT 13 tDSP rx aal2 crc10 err count: DSP>level 1 Return Status: 0

0 0 0 0 0 0 0 0 0 0 0 0

[ 24] DSP> 09:54:45 RT 13 tDSP Tele levels for 1 09:54:45 RT 13 tDSP rx_level: -570 09:54:45 RT 13 tDSP tx_level: -340 09:54:45 RT 13 tDSP rx_mean: -2 09:54:45 RT 13 tDSP tx_mean: 0 09:54:45 RT 13 tDSP frame_underrun_count: 1383 DSP>echo_stat 1 Return Status: 0 [ 26] DSP> 09:54:54 RT 13 09:54:54 RT 13 tDSP 09:54:54 RT 13 tDSP 09:54:54 RT 13 tDSP 09:54:54 RT 13 tDSP DSP>rxtx_stat 1 Return Status: 0 09:55:06 RT 09:55:06 RT 09:55:06 RT 09:55:06 RT 09:55:06 RT 09:55:06 RT 09:55:06 RT 09:55:06 RT 09:55:06 RT 09:55:06 RT 09:55:06 RT 09:55:06 RT 09:55:06 RT 09:55:06 RT 09:55:06 RT 09:55:06 RT 09:55:06 RT 09:55:06 RT 09:55:06 RT 09:55:06 RT 09:55:06 RT 09:55:06 RT 09:55:06 RT 09:55:06 RT 09:55:06 RT 09:55:06 RT 09:55:06 RT 09:55:06 RT 09:55:06 RT 09:55:06 RT vp_stat 1

13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13

tDSP tDSP tDSP tDSP tDSP tDSP tDSP tDSP tDSP tDSP tDSP tDSP tDSP tDSP tDSP tDSP tDSP tDSP tDSP tDSP tDSP tDSP tDSP tDSP tDSP tDSP tDSP tDSP tDSP tDSP

tDSP Px Level: Py Level: -56.1250 Pe Level: -65.3750 Estimated ERL: 30.0625 Acom Estimate: 43.9375

Rx/Tx Stats for 1 Rx Voice Packets Tx Voice Packets Tx Silence Suppressed Frames Rx Min Jitter Rx Max Jitter Rx RTP Avg Jitter Tx Grant Sync Dropped Frames Tx Octets Rx Octets DTMF Tx Packets DTMF Rx Packets SID Rx Packets SID Tx Packets Tx Last Timestamp Tx Extended Seq Number Tx Last Seq Number Tx Last Pkt Type Rx Last Timestamp Rx Last Ssrc Rx Extended Seq Number Rx Last Seq Number Rx Last Pkt Type Pkt Lost by Network Rx P2P Packets to Hosts Rx P2P Filtered Packets P2P Squelched Voice Packets Rx Net Packets Tx Net Packets Rx Last Voice Prof Idx

-32.6250

= = = = = = = = = = = = = = = = = = = = = = = = = = = = =

3135 3157 0 10 (ms) 28 (ms) 6 (pcm samples) 0 505120 501600 0 0 0 0 504960 0 3156 0 -1081491528 2086678529 0 11710 0 0 0 0 0 3135 3157 0



68


Return Status: 0 [ 27] DSP> 09:54:58 RT 13 tDSP Voice Playout Delay Stats for 1 09:54:58 RT 13 tDSP Avg Playout Delay: 36 09:54:58 RT 13 tDSP Lost Segments: 0 09:54:58 RT 13 tDSP Replayed Segments: 0 09:54:58 RT 13 tDSP Idle Segments: 101 09:54:58 RT 13 tDSP FIFO Dropped Segments: 2 09:54:58 RT 13 tDSP Rx Segments: 10928 09:54:58 RT 13 tDSP Rx Avg Pkt Jitter: 7 (pcm samples) 09:54:58 RT 13 tDSP Adpt PO Buf Delay Inc: 0 09:54:58 RT 13 tDSP Adpt PO Buf Delay Dec: 5 09:54:58 RT 13 tDSP Cell Starve Evt Cnt: 0 09:54:58 RT 13 tDSP PO Buf Underflow Cnt: 0

8.3. Echo hoorbaar aan B zijde Echo wordt steeds veroorzaakt aan de andere zijde van waar ze hoorbaar is. Op die plaats moet de echo ook gecancelled worden. Oorspronkelijk was de echo tail van de MTA slechts 8 msec. Deze test zal uitwijzen dat dit onvoldoende is. Daarom heeft de constructuur de echo tail vergroot naar 32 msec.

8.3.1.

Probleemanalyse

Een aantal klanten maakten melding van echo op de lijn die hoorbaar was aan de andere zijde. Omdat wij het probleem eerst niet konden reproduceren zijn we op zoek gegaan naar gemeenschappelijke punten bij de verschillende klanten. We hebben dan ook een aantal testen gedaan bij deze klanten door bijvoorbeeld het telefoontoestel te vervangen. Zo kwamen we tot het besluit dat oude of goedkope types van DECT telefoontoestellen mee aan de basis van het probleem lagen. Tijdens de testen zal duidelijk worden waarom.

8.3.1.1. Testen

Nadat we te weten waren gekomen hoe de echo ontstond, konden we ook het probleem reconstrueren in het labo. Dit maakt metingen en testen veel makkelijker. Het eerste doel was om traces te nemen die aan de fabrikant konden bewijzen dat de echo door de MTA niet naar behoren werd gecancelled. Met andere woorden, de echo canceller van de MTA voldoet niet. Op spraak kan je echter moeilijk metingen uitvoeren omdat spraak teveel verschillende frequenties bevat. Daarom hebben we geopteerd om een sweep van 350Hz tot 3500Kz te gebruiken. De generator werkt met een vaste amplitude zodat je metingen kan doen. Verder lieten we de frequentie elke 5 seconden veranderen met stappen van 100Hz. Zo kregen we ook een beeld wat er gebeurt bij frequentieveranderingen zoals dit het geval is bij spraak. Deze signalen hebben we dan gesnift, terug gereconstrueert tot een WAV-file en deze file hebben we dan geanalyseerd met Goldwave. Hieronder ziet u een beeld van ons signaal in de downstream richting.




69

Figuur 21: Goldwave, signaal in de downstream richting

We zien dat ons spraaksignaal een vermogen heeft van -18 dBm. Deze waarde hebben we nodig om te controleren hoeveel de MTA de echo van dit signaal verzwakt. Wanneer we het upstream signaal bekijken in functie van de tijd, dan merken we dan er bij elke frequentieverandering echo aanwezig is gedurende 20 msec. Daarna wordt het signaal wel gecancelled.

Figuur 22: Upstream signaal in functie van de tijd

Het DECT protocol (Digital Enhanced Cordless Telecommunication) geeft ongeveer een vertraging van om en bij de 20msec (2 x 8 msec). Als de hybrid van het DECT toestel niet voldoet, onstaat er echo. Door de vertraging van het DECT toestel, vallen de eerste 20 msec buiten de echo tail van 8msec. Bij een gesprek wil dit dus zeggen dat de vertraging van de echo steeds groter is dan de echo zodat de echo niet gecancelled wordt.



70


We kunnen dit ook nog staven aan de hand van volgend diagram van het echosignaal dat Goldwave toont.

Figuur 23: Goldwave, echosignaal

We kunnen hierin aflezen dat het echo signaal nog een vermogen heeft van -51dBm. We weten dat ons oorspronkelijke signaal -18dBm bedroeg. Dit wil dus zeggen dat de verzwakking langs de MTA zijde 33 dB bedraagt. Deze 33 dB kunnen we als volgt verklaren: • 9dB loss plan Rx • 3dB loss plan Tx • 21dB ERL van het telefoonstoestel De echo canceller kan in geen geval gewerkt hebben, want de EC zou al een verzwakking van ongeveer 30dB moeten hebben. Toch bleek uit de logs op de MTA dat de echo canceller aanstond. [ 22] DSP> channel 1 channel 1 DSP channel vars for 1 -----------------------------channel_status channel_state channel_reset packet_rate nom_delay codec_type echo_cancellation dtmf_relay pcm_loopback rx_loopback tx_loopback tone_active tone_direction tone_type modem_detected tone_time_remaining

: 2: DSP_CHANNEL_OPENED : 3: DSP_voice_state :0 : 20 : 40 :8 : 1: Enabled :3 :0 :0 :0 :0 :0 :0 :0 :0



71


channel_error rx_timeslot tx_timeslot destination RFC2833 Payload Type Rx Payload Type Tx Payload Type tx_ssrc codecChangeSent sd_enable sd_coding sd_payload tx_gain rx_gain vad_enable

:0 :0 :0 : 255 :0 :8 :8 : 819834 :0 : FALSE :0 :0 :0 :0 : FALSE

Return Status: 0 [ 25] DSP> echo_stat 1 echo_stat 1 Return Status: 0 [ 26] DSP> 11:49:32 RT 13 tDSP Px Level: -50.0625 11:49:32 RT 13 tDSP Py Level: -49.0625 11:49:32 RT 13 tDSP Pe Level: -49.0625 11:49:32 RT 13 tDSP Estimated ERL: 34.5625 11:49:32 RT 13 tDSP Acom Estimate: 34.5625 11:49:32 RT 13 tDSP P[06,13] 0x0000 0x06be 0x0000 0x0000 0x0000 0x0000 0x0000 0x00de 11:49:32 RT 13 tDSP P[14,21] 0x0000 0x02e4 0x0001 0x68a7 0x0000 0x0000 0x0010 0x0001 11:49:32 RT 13 tDSP P[22,29] 0x0000 0x0000 0x0000 0xf26c 0x0038 0x000a 0x0015 0x0006 11:49:32 RT 13 tDSP P[30,37] 0x0020

Zo konden we definitief besluiten dat de echo tail te kort was en moest worden aangepast.

8.3.2.

Conclusie

Oorspronkelijk was de echo tail van de MTA slechts 8 msec. Uit onze testen bleek dat dit echter onvoldoende was wanneer we gebruik maken van DECT telefoontoestellen. Daarom werd de echo tail bij de volgende software release vergroot naar 32 msec zodat de vertraging die te wijten is aan het DECT protocol, mee in rekening wordt gebracht. Toch bleken niet alle problemen opgelost. Dus zijn we verder op onderzoek gegaan. Slechte impedantie aanpassingen kunnen reflecties veroorzaken. Een slechte binnenhuisbekabeling of telefoontoestel kunnen deze impedantie fouten veroorzaken. De echo canceller kan deze echo onmogelijk voldoende kan cancellen zodat deze hoorbaar blijft, weliswaar heel stil, maar toch storend. Bij traditionele telefonie werd al eens een condensator en weerstand op de lijn gezet om lijntesten mogelijk te maken. Deze schakeling is bijvoorbeeld één van de mogelijke oorzaken van echo. Daarom hebben we de procedures voor de installatie en hersteltechnici laten aanpassen, zodat deze hier meer aandacht aan besteden. Zo werd dit probleem eindelijk opgelost na veel testen en onderzoek.

8.4. Echo hoorbaar aan A zijde 8.4.1.

Gesprek MTA naar MTA

Het is logisch dat we hier terug kunnen verwijzen naar hooftstuk 8.3. De MTA moet namelijk altijd de echo cancellen in dit geval want aan beide zijden wordt een MTA gebruikt.




8.4.2.

72

Gesprek MTA naar PSTN

Als de VoIP klant de echo waarneemt, dan mogen we besluiten dat de echo veroorzaakt werd in het PSTN netwerk. Bij het binnenkomen van het VoIP netwerk, moet de PVG of packet voice gateway, deze echo cancellen. De PVG verbindt het VoIP netwerk met het PSTN netwerk. In het PSTN netwerk kunnen grotere vertragingen ontstaan dan in een binnenhuisinstallatie. Daarom werd hier geopteerd voor een echo tail van 128msec. Dit zou ruimschoots voldoende moeten zijn. Het is dan ook heel verwonderlijk wanneer we toch de eerste klantenklachten krijgen in verband met echo van dit type. Toch bleken de klachten gegrond.

8.4.2.1. Testen

De PVG moet de echo cancellen per trunk. Omdat een gesprek in principe dynamisch wordt gerouteerd over het netwerk, weet je nooit op welke trunk een gesprek zal terechtkomen. Dit heeft natuurlijk zijn consequenties bij het testen in verband met dit probleem. Daarom hebben we een aantal trunken geviseerd en hebben we onze testgesprekken statisch gerouteerd over deze trunken. Zo kwamen we tot het besluit dat bij sommige trunken het probleem zich altijd steldt en bij andere trunken dan weer nooit. Dit is heel verwonderlijk want de echo cancellers staan hetzelfde ingesteld voor alle trunken. Daarom zijn we ook hiervoor op pad getrokken met de DOCSIS tracer.

Figuur 24: Testopstelling DOCSIS tracer

Voor deze test hebben we geopteerd voor een gesprek. Je kan dan makkelijk zien waar het echo signaal zit. Omdat de echo die komt van het PSTN netwerk, luider is dan die aan de MTA zijde is het ook perfect mogelijk om de amplitudes te meten van het gesprek. Hieronder hebben we beide streams bij elkaar gezet. Wij gaan ons even focussen op de echo die zich in het blauwe veld bevindt.




73

Figuur 25: originele signaal en echosignaal

In de bovenste figuur zie je het originele signaal. Onderaan zie je de echo ervan. Zoals je ziet is deze toch nog vrij groot in amplitude. Laat ons dit even verduidelijken. Het originele signaal wordt via het upstream kanaal van de MTA verzonden. In de MTA werd dit signaal reeds met 3 dB verzwakt vanwege het loss plan. Daarna wordt dit signaal op RF gezet en opgepikt door de sniffer.

Figuur 26: Goldwave, piek van het origineel signaal

Zoals we zien ligt het piekniveau van dit gesprek op ongeveer 31 dBm. Wanneer we nu de echo van dit signaal bekijken krijgen we het volgende: Steven Vlemincx Groep-T Graduaat Telecommunicatietechnieken



74

Figuur 27: Goldwave, piek van het echo signaal

Ons origineel signaal bedroeg ongeveer -31 dBm. Als we de echo van dit signaal bekijken, dan zien we dat deze ongeveer -47 dBm bedraagt. In het PSTN netwerk werd ons signaal dus slechts 16 dB verzwakt. Van deze 16 dB kan er al 12 dB worden toegeschreven aan het loss plan, de overige 4 dB aan de hybrid van het telefoontoestel. Zoals we zien veroorzaakt deze telefoon dus een grote crosstalk. We mogen dus besluiten dat de echo canceller in de PVG zeker niet heeft gewerkt. Maar waarom doet hij dit niet? In de signalisatie tussen telefooncentrales is er een bit die aangeeft of er reeds aan echo cancelling werd gedaan of niet. Na lang zoeken en testen merkten we op dat deze bit door een vorige centrale in de keten reeds werd opgezet, waardoor onze centrale dacht dat hij niet meer aan echo cancelling moest doen. Daarom werden alle centrales in de keten bekeken en was het probleem opgelost. De oplossing voor een groot probleem schuilt dikwijls in een klein hoekje.

8.4.2.2. Conclusie

Aangezien de echo tail van de PVG 128 msec bedraagt, konden we al uitsluiten dat de echo tail onvoldoende groot zou zijn. Toch bleek er soms sprake te zijn van een sterke echo. Het probleem is dat de gesprekken in normale omstandigheden worden geloadbalanced over de verschillende trunken. Je weet dus niet op voorhand welke trunk gebruikt gaat worden voor een gesprek. Daarom zijn we aan de hand van gegevens die we van klanten hadden gekregen, op zoek gegaan naar een trunk waarop het probleem zich zeer uitgesproken manifesteert. Vervolgens hebben we alle verkeer van onze test MTA over deze trunk naar het PSTN netwerk gerouteerd zodat we een referentie hadden. Steven Vlemincx Groep-T Graduaat Telecommunicatietechnieken



75

Uit onze testen bleek dat de EC wel geactiveerd stond, maar niet in werking treedt bij een gesprek. Dit leek ons heel bizar want alle PVG’s hebben dezelfde configuratie. Dit werd doorgegeven aan de fabrikant die hiervoor dan een bugfix heeft gemaakt. Toch bleek er nog steeds echo voor te komen. Toen bleek dat een voorgaande centrale aan de PVG doorgaf dat hij reeds de echo gecancelled had. Heel de keten van telefooncentrales moest dus bekeken worden om dit probleem op te lossen.



76


9. Uitwerken van enkele praktisch problemen 9.1. Disconnected from CMS 9.1.1.

Wat? • • • •

Communicatie tussen MTA en CMS of call magagement server faalt zodat ook de registratie van de MTA faalt. De kabelmodem of CM is wel in dienst en biedt een volledige service. Op de MTA, knipperen beide LEDs met de naam “Telephone”. In de modemtest staat de lijn in de status “disconnected”.

Het pingresultaat voor MTA MacId 00:00:CA:B4:79:31 :: MODEM gegevens MTA HW type

N/A

MTA SW type

4.1.20

FQDN

m19993.emta.telenet.be

MTA Serial Number

47BBGBB3A900293

End Point Count

2

MTA Admin Status

1

Provisioning State

Pass

MTA PROVSTATE

Operational

End Point 1 Status

Disconnected

End Point 2 Status

Disconnected

End Point 1 Config Operational Status

End Point 2 Config Operational Status

Als we inloggen op de CM door gebruik te maken van CLI, zien we het volgende: [ 10] system> reg reg CM State: DOCSIS-AC Power Iso OFF Data Reg Complete Complete Complete Complete Complete Complete Complete Complete Complete In Progress ---

| | | | | | | | | |

Docsis-Downstream Scanning Docsis-Downstream Ranging Docsis-Upstream Ranging Docsis-DHCP Docsis-TFTP Docsis-Data Reg Complete Telephony-DHCP Telephony-TFTP Telephony-Reg with Call Server Telephony-Reg Complete

Hiermee worden bovenstaande meldingen bevestigd. We zien hier heel duidelijk dat de CM registratie in orde is maar de registratie van de MTA niet volledig doorlopen werd.

9.1.2.

Oorzaken

Hiervoor zijn verschillende oorzaken mogelijk. • Bug in de MTA, waardoor de MTA soms gebruik maakt van de IP stack van de CM om een IP adres aan te vragen. • MTA werd verkeerd geprovisioneerd



77


9.1.3.

Oplossingen

9.1.3.1. Verkeerde IP stack

We zetten een telnet sessie met de MTA op en voeren het commando “ipsec_db” uit. We krijgen dan volgende output: [ 8] PacketCable Security> ipsec_db ipsec_db Security Policy DB (incoming): handle=1009 lvl=0 src=195.130.130.130:0-65535 dest=10.130.53.128:24272427 proto=17 act=pass handle=1006 lvl=100 src=0.0.0.0:1-65535 dest=0.0.0.0:2427-2427 proto=17 act=drop handle=1000 lvl=121 src=0.0.0.0:0-65535 dest=0.0.0.0:0-65535 proto=17 act=pass Security Policy DB (outgoing): handle=1008 lvl=0 src=10.130.53.128:2427-2427 dest=195.130.130.130:065535 proto=17 act=pass handle=1007 lvl=100 src=0.0.0.0:2427-2427 dest=0.0.0.0:1-65535 proto=17 act=drop handle=1001 lvl=121 src=0.0.0.0:0-65535 dest=0.0.0.0:0-65535 proto=17 act=pass No entries in incoming security association DB No entries in outgoing security association DB Return Status: 1

195.130.130.130 is het IP-adres van onze provisioningserver. Zoals we zien wordt alleen naar dit IP-adres NCS verkeer door gelaten. NCS traffic van en naar andere adressen wordt geblokt. Zoals we weten moet onze MTA met de GWC NCS berichten kunnen uitwisselen en niet met de provisioningserver. Het gevolg is dat de registratie faalt. Maar waar ligt de oorzaak? Omdat de MTA de verkeerde IP-stack gebruikt bij het bekomen van het IP-adres van de GWC via DNS, komt de MTA terecht op de DNS server voor kabelmodems. Deze geeft een vals antwoord, namelijk dat van de provisioningsserver. De MTA neemt deze gegevens op in zijn security database met het gekende gevolg. Bij een reset van de modem wordt de database leeggemaakt en komt alles gewoon in dienst. [ 19] PacketCable Security> ipsec_db ipsec_db Security Policy DB (incoming): handle=1005 lvl=0 src=10.213.8.48:0-65535 dest=10.130.53.128:2427-2427 proto=17 act=pass handle=1002 lvl=100 src=0.0.0.0:1-65535 dest=0.0.0.0:2427-2427 proto=17 act=drop handle=1000 lvl=121 src=0.0.0.0:0-65535 dest=0.0.0.0:0-65535 proto=17 act=pass Security Policy DB (outgoing): Steven Vlemincx Groep-T Graduaat Telecommunicatietechnieken


78


handle=1004 lvl=0 src=10.130.53.128:2427-2427 dest=10.213.8.48:0-65535 proto=17 act=pass handle=1003 lvl=100 src=0.0.0.0:2427-2427 dest=0.0.0.0:1-65535 proto=17 act=drop handle=1001 lvl=121 src=0.0.0.0:0-65535 dest=0.0.0.0:0-65535 proto=17 act=pass No entries in incoming security association DB No entries in outgoing security association DB

Return Status: 1

Deze bug werd doorgegeven aan de fabrikant. Bij de volgende software release was het probleem dan ook van de baan.

9.1.3.2. Verkeerde provisioning

Ons provisioning systeem maakt, aan de hand van een LDAP database, de configuratiefile voor de CM en de MTA aan wanneer deze wordt gevraagd. In de gateway controller of GWC is een bepaalde gebruiker wel statisch geprovisioneerd aan de hand van zijn FQDN. Als de GWC die wordt meegegeven in de MTA config, niet overeenstemt met de GWC waarop de FQDN gekend is, dan gaat de MTA de verkeerde GWC contacteren maar antwoord de GWC niet. We kunnen dit controleren door te kijken op welke GWC de FQDN gekend is. We vergelijken dan de FQDN met deze die de MTA kent. We kunnen dus eigenlijk stellen dat het probleem vergelijkbaar is met het probleem van de verkeerde IP stack. In beide gevallen wordt een verkeerd IP adres gebruikt voor de GWC. Hier kan het probleem echter niet opgelost worden door een reset, maar moet de data in de LDAP server worden aangepast.

9.2. CLIP werkt niet meer na upgrade 9.2.1.

Wat?

Tijdens het testen van een nieuwe software load voor de MTA bleek CLIP niet meer te werken. CLIP is de feature die ervoor zorgt dat het nummer en eventueel de naam van de originator worden weergegeven. Bij controle van de NCS berichten wordt de informatie correct meegegeven. RQNT 27306 aaln/[email protected] MGCP 1.0 NCS 1.0 X: 82 S: ci(04/07/09/34, 015370289, "LABOTEST"), rg Q: loop R: hd(N), oc, of




9.2.2.

79

Oorzaak

Bij het nalezen van de release notes, zagen we dat er een aantal lijnparameters verplaatst waren vanuit de propriëtaire MIBs van de MTA-fabrikant, naar de publieke Euro-PacketCable MIBS. Dit werd gedaan om zo uniform mogelijk te kunnen werken met andere fabrikanten. Dit is vooral belangrijk om het provisioningssysteem overzichtelijk te houden en bij het runnen van scriptjes die allerlei testen uitvoeren via SNMP. CLIP is één van de parameters die verplaatst werd naar de Euro-PacketCable MIB’s. Voortaan moeten we CLIP aanzetten door MIB object pktcSigDevCIDMode de waarde duringRingingETS te geven.

This object is required only for Euro-PacketCable. For on-hook Caller ID, pktcSigDevCIDMode selects the method of Caller ID. For the duringRingingETS method, the Frequency Shift Keying (FSK) containing the Caller ID information is sent between the first and second ring pattern. For the dtAsETS,rpAsETS, and lrAsETS methods, the FSK containing the Caller ID information is sent before the first ring pattern. For the dtAsETS method, the FSK is sent after the Dual Tone Alert Signal. For the rpAsETS method, the FSK is sent after a Ring Pulse. For the lrAsETS method, the Line Reversal occurs first, then the Dual Tone Alert Signal, and finally the FSK is sent.

Voorheen werd deze feature geactiveerd via de private MIB van de fabrikant aan de hand van de CallPFeatureSwitch in de MTA configuratiefile. Daarom vermoedden we dat we de oorzaak hier moeten gaan zoeken.

9.2.3.

Oplossing

Op de MTA kunnen we via telnet de waarde van de Featureswitch opvragen. [ 10] Call Processing> ftrsw Ftrsw 0x00000001: Allow piggybacked tranmissions of NCS messages: ENABLED 0x00000002: Allow endpoint to enter the Lockstep quarantine mode: ENABLED 0x00000004: Allow endpoint to send MGCP (RFC-3435) error code messages: DISABLED 0x00000008: WARNING: unused CPFS bit set! 0x00000010: SDP compliancy: ENABLED 0x00000020: DQOS SF (Max Traffic Rate) PacketCable compliant: DISABLED 0x00000040: WARNING: unused CPFS bit set! 0x00000080: Omit mptime parameter in returned SDP: DISABLED 0x00000200: Allow transmission of wildcarded RSIP: DISABLED 0x00000400: Allow NCS flexibility: ENABLED 0x00001000: NUERA RFC-2833 messaging without request using payload 127: DISABLED 0x00002000: WARNING: unused CPFS bit set! 0x00004000: DSX (access only) DQoS: ENABLED 0x00008000: Allow endpoint to send provisional responses: DISABLED 0x00010000: Payload Header Suppression: DISABLED 0x00020000: Allow multiple connections per line (bit = 0): ENABLED 0x00040000: DQoS Tolerated Grant Jitter (bit = 0): PacketCable compliant 0x00080000: LUCENT RFC-2833 messaging without request using payload 94: DISABLED 0x00100000: Allow AES encryption for RTP/RTCP (bit = 0): ENABLED 0x00200000: Rsv. for RECVONLY/SENDONLY/REPLCATE modes (bit = 0): PacketCable compliant 0x00400000: Allow NCS Redirect without IPsec: DISABLED 0x01000000: Send dtmf digits via RFC2833 with payload 101 without request: DISABLED Steven Vlemincx Groep-T Graduaat Telecommunicatietechnieken


80


0x02000000: 0x04000000: 0x08000000: 0x10000000: 0x20000000: 0x40000000:

Allow use of provisioned ring cadences (for non NA countries): DISABLED Use hard-coded values for Flash timing (90 - 800 ms): DISABLED Use alternate (non sequential) Caller ID delivery order: ENABLED Delay DLCX against connection on onhook only line (for VMWI): DISABLED Use Cisco Proprietary T38 mode w/ NSE signaling: DISABLED Voice Activity Detection: DISABLED

CallpFeatureSwitch is currently 0x800645b Elke feature krijgt een bepaald HEX waarde mee. Door deze waardes al dan niet mee in rekening te brengen bij de berekening van de Featureswitch, zetten we de features aan of uit. Door het verplaatsen van sommige parameters naar de Euro-PacketCable MIBs, werden sommige van de features die vroeger in rekening moesten worden gebracht bij het berekenen van de Featureswitch, nu niet meer ondersteund. Als we deze dan toch mee opnemen bij het berekenen van onze HEX waarde, dan krijgen we de melding “WARNING: unused CPFS bit set!”. Dit is nu precies de oorzaak van het niet werken van de CLIP informatie en andere features. Doordat er enkele ongekende waardes in de configuratiefile staan, geraakt de MTA in de knoop want hij kent deze waardes niet en weet dus ook niet wat er mee te doen. Het gevolg is dat er enkele features waaronder de CLIP niet werken. Daarom werd de Featureswitch herberekend. De correcte waarde is 0x8004413. Met deze Featureswitch waarde werkt CLIP terug perfect. Call Processing> ftrs 0x8004413 ftrs 0x8004413 CallpFeatureSwitch being set to 0x8004413 0x00000001: Allow piggybacked tranmissions of NCS messages: ENABLED 0x00000002: Allow endpoint to enter the Lockstep quarantine mode: ENABLED 0x00000004: Allow endpoint to send MGCP (RFC-3435) error code messages: DISABLED 0x00000010: SDP compliancy: ENABLED 0x00000020: DQOS SF (Max Traffic Rate) PacketCable compliant: DISABLED 0x00000080: Omit mptime parameter in returned SDP: DISABLED 0x00000200: Allow transmission of wildcarded RSIP: DISABLED 0x00000400: Allow NCS flexibility: ENABLED 0x00001000: NUERA RFC-2833 messaging without request using payload 127: DISABLED 0x00004000: DSX (access only) DQoS: ENABLED 0x00008000: Allow endpoint to send provisional responses: DISABLED 0x00010000: Payload Header Suppression: DISABLED 0x00020000: Allow multiple connections per line (bit = 0): ENABLED 0x00040000: DQoS Tolerated Grant Jitter (bit = 0): PacketCable compliant 0x00080000: LUCENT RFC-2833 messaging without request using payload 94: DISABLED 0x00100000: Allow AES encryption for RTP/RTCP (bit = 0): ENABLED 0x00200000: Rsv. for RECVONLY/SENDONLY/REPLCATE modes (bit = 0): PacketCable compliant 0x00400000: Allow NCS Redirect without IPsec: DISABLED 0x01000000: Send dtmf digits via RFC2833 with payload 101 without request: DISABLED 0x02000000: Allow use of provisioned ring cadences (for non NA countries): DISABLED 0x04000000: Use hard-coded values for Flash timing (90 - 800 ms): DISABLED 0x08000000: Use alternate (non sequential) Caller ID delivery order: ENABLED 0x10000000: Delay DLCX against connection on onhook only line (for VMWI): DISABLED 0x20000000: Use Cisco Proprietary T38 mode w/ NSE signaling: DISABLED 0x40000000: Voice Activity Detection: DISABLED




81

In bijlage J geven we een beetje meer informatie aangaande de feature switch. Welke waardes zijn mogelijk en wat betekenen ze?

9.3. Omschakelen Pulse / Toon 9.3.1.

Wat?

Een aantal nieuwe faxtoestellen voldoen niet aan de specificaties wat betreft DTMF (Dual Tone Multi-Frequency) tonen. DTMF tonen bestaat uit de som van 2 frequenties die beide een bepaalde signaalsterkte moeten hebben. Sommige faxtoestellen voldoen niet aan de norm wat betreft de signaalsterkte. Daardoor kan de MTA de DTMF tonen niet correct interpreteren. Nummer “3” is het nummer waarmee het meeste problemen zijn.

9.3.2.

Oplossing

Enkele mogelijke oplossingen zijn: - Design van de MTA overdoen : geen optie en wat doe je trouwens met de bestaande klanten? - Klant andere fax laten kopen is zeker ook niet haalbaar. Daarom moesten we op zoek gaan naar een work around die het probleem niet oplost, maar wel kan omzeilen. Zo kwamen we op het idee om de faxtoestellen over te schakelen op pulse dialing. Maar toen stelden we vast dat pulse dialing niet ondersteund werd door de MTA. Daarom hebben we gevraagd aan de fabrikant om deze optie bij de volgende Software release in te bouwen. In tussentijd hebben we dan gebruik gemaakt van een extra adapter bij de klant die de pulsen die afkomstig zijn van de fax, omzet in DTMF tonen die wel binnen de specificaties vallen. Ondertussen ondersteunt de MTA nu ook pulse dialing. Om pulse dialing toe te staan moeten we het MIB object “arrisMtaDevEndPntDialingMethode” de waarde 3 geven. 3 stemt overeen met toon en pulse dialing. Een CPE mag dan zowel DTMF tonen als pulsen sturen bij het nummeren. Hieronder ziet u een overzicht waar het MIB object gevonden kan worden in de MIB tree en ook een beetje uitleg aangaande het MIB object.



82


Figuur 28: PacketACE: boomstructuur MIBs

Indicates the method used to dial the digits for this telephonyendpoint. If tone(1), tone dialing (DTMF) is used. If pulse(2), dial-pulse signaling is used to dial the digits, Tone dialing(DTMF) is disabled. If Tone AND Pulse(3), tone dialing(DTMF) and dial-pulse signaling is used to dial the digits. If Pulse with DTMF relay(4), Tone dialing(DTMF) is disabled, and pulse dialed digits will be relayed in-band to the media gateway. If Tone AND Pulse with DTMF relay(5), Tone dialing (DTMF) is enable, and pulse dialed digits will be relayed in-band to the media gateway. NOTE: (4) AND (5) will require IPDT sulution as well as DTMF support by the Media gateway. The default value for this object is tone(1).




83

10. Vergelijking Skype, SIP en Telenet VoIP Aangezien er zoals hierboven vermeld zoveel verschillende implementaties van VoIP bestaan vergelijken we hierna 2 heel populaire VoIP toepassingen – namelijk Skype en SIP - met de Telenet VoIP.

10.1. Skype Skype is een peer-to-peer VoIP client ontwikkeld door Niklas Zennstrom en Janus Friis, die KaZaA oprichtte. Het laat gebruikers toe om gesprekken of tekstboodschappen door te sturen naar andere gebruikers.

10.1.1. het Skype netwerk Zoals zijn file-sharing voorganger KaZaa gebruikt Skype een peer to peer (P2P) netwerk. Er zijn 2 soorten nodes in dit netwerk, gewone nodes of hosts en supernodes (SN). Een gewone node is een Skype applicatie die kan gebruikt worden om gesprekken op te zetten. Een supernode is het eindpunt van een gewone node in het Skype netwerk. Iedere node met een publiek IP, voldoende CPU, geheugen en bandbreedte is een kandidaat supernode. Een gewone node moet zich connecteren met een supernode en met de Skype loginserver om zich correct aan te loggen. Hoewel de Skype login server geen echte node is, is deze server toch een heel belangrijk netwerkelement in het Skype netwerk. In deze server worden namelijk de gebruikersnamen en paswoorden opgeslagen. Naast de loginserver is er geen enkel ander centraal netwerkelement in het Skype netwerk. In het Skype netwerk heeft iedere client een tabel met de voor hem bereikbare nodes. Deze tabel is de Host Cache. Ze bevat de de IP adressen en de poort nummers van de super nodes. De tabel zelf wordt bewaard in de Windows registry. Skype heeft een "3G P2P" of "Global index" technologie geïmplementeerd die er voor zorgt dat alle gebruikers die de laatste 72 uur zijn ingelogd teruggevonden kunnen worden.



84


Figuur 29: Skype netwerk overzicht

10.1.2. Skype componenten Skype gebruikt breedband codecs die voor een redelijke gesprekskwaliteit zorgen met een beschikbare bandbreedte van 32 kbps. De Codecs laten frequenties toe tussen 50 en 8000 Hz toe. Skype gebruikt TCP voor signalisatie en UDP of TCP voor transport. Signalisatie en data worden op verschillende poorten verzonden. Via de functie SkypeOut is het ook mogelijk om via een Prepaid krediet naar PSTN nummers te bellen. Zoals de oprichter van Skype het zo mooi uitdrukt: "Even a Skype user... calls his mother once in a while”. Skype heeft overeenkomsten met 4 grote carriers om wereldwijd lokaal calls af te leveren. De akkoorden werden afgesloten met COLT Telecom, Teleglobe International, iBasis en Level 3 Communication. De lijst met bestemmingen die tegen lokaal tarief kunnen gebeld worden wordt steeds groter en is te consulteren op http://www.skype.com/products/skypeout/rates/. Verschillende factoren onderscheiden Skype van andere VoIP toepassingen: • Skype is ongemeen populair. De client bestaat nu reeds voor Windows, MacOS, PocketPC en Linux. Skype heeft reeds meer dan 2 miljoen gebruikers. • De Skype software en het gebruik van het Skype network zijn gratis. Je hoeft niet te betalen voor een Skype gesprek tussen 2 Skype clients. Er moet wel betaald worden oor oproepen wanneer je gebruikt maakt van “Skype Out” of "Skype In". Deze functies verbinden Skype met het PSTN netwerk. • Skype is veel makkelijker te gebruiken dan veel VoIP systemen. De Skype client is snel te installeren. Behalve een gebruikersnaam kiezen hoeft er niets geconfigureerd te worden. In tegenstelling tot SIP applicaties werkt Skype goed wanneer het gebruikt wordt achter een firewall of wanneer het te maken krijgt met Network Address Translation (NAT) systemen.



85


• • • •

Skype gebruikt hiervoor een variant van de STUN en TURN protocollen (Simple Traversal of UDP through NAT en Traversal Using Relay NAT). Naast gewoon telefonie heeft Skype nog andere functies: instant messaging, zoekfuncties, file transfer capaciteiten, enzovoort. Skype is geëncrypteerd. Skype beweerd dat het alle communicatie met een 128-bit sleutel encrypteerd. Skype heeft een Single Point Of Failure. Wanneer de loginserver(s) niet bereikbaar zijn is het onmogelijk om van het systeem gebruik te maken. Skype bevindt zich nog steeds in de grijze zone. Veel van wat ze zeggen kan immers niet gecontroleerd worden aangezien hun broncode geheim is.

Skype doet zijn best om opener te worden. De API is vrijgegeven en ontwikkelaars worden uitgenodigd om nieuwe toepassingen te ontwerpen: Skype voicemail, Skype doorverbinden, Skype babyfoon. Maar ook andere dingen waar onder bijvoorbeeld spelletjes op basis van Skype. Het grote probleem bij Skype tegenover andere VoIP toepassingen is dat de eigenlijke gespreksstroom over de gewone internetverbinding gaat. Het verkeer is dus steeds een best effort service zonder QoS en dit heeft tot gevolg dat de kwaliteit van het gesprek varieert van goed tot onverstaanbaar. Alles hangt af van de soort internetverbinding die de 2 gesprekspartners hebben en de weg die het verkeer volgt tussen beiden. Een tweede probleem is de aard van het Skype netwerk. Wanneer de applicatie openstaat kan er toch bandbreedte gebruikt worden, ook wanneer men zelf niet in gesprek is. Men kan immers als tussennode voor andere fungeren in het Skype netwerk. Net als bij andere peer to peer programma’s gebruikt Skype dus jou resources voor andere gebruikers. We kunnen stellen dat Skype een interessante gratis toepassing is om gratis met andere Skype gebruikers te communiceren. De kwaliteit is echter van die aard dat ze nooit toereikend zal zijn voor de bedrijfswereld of voor bellers die steeds een betrouwbaar communicatiemiddel met goede kwaliteit verwachten.

10.2. SIP SIP, Session Initiation Protocol8 is gedefinieerd door de Internet Engineering Task Force (IETF). De standaard heeft veel weg van HTML, waardoor het programmeren van SIP-functies en applicaties relatief makkelijk is. SIP is niet beperkt tot VoIP-applicaties, maar kan ook worden gebruikt om elk type communicatiesessie tussen IP gebruikers te managen, inclusief instant messaging, video, interactieve spelletjes en tekstchatten. Een probleem met SIP is echter dat de standaard nog in ontwikkeling is. Hoewel de interoperabiliteit van de basisfuncties van VoIP (opzetten en beëindigen van gesprekken) goed is, leveren meer geavanceerde functies zoals doorverbinden, teleconferenties en follow-me compatibiliteitsproblemen op tussen verschillende aanbieders van SIP-apparatuur. Het SIP forum, bestaande uit 49 producenten van VoIP-apparatuur, werkt momenteel aan certificatie. Tot dat de certificatie gereed is, wordt gewerkt met SIP plugfests, waarin zo’n twee keer per jaar alle producenten van SIP hun apparatuur aan elkaar koppelen om vast te stellen of deze zonder problemen met elkaar samenwerkt.

8

Gedetailleerde informatie is terug te vinden in RFC 2543, SIP: Session Initiation Protocol. Steven Vlemincx




86

10.2.1. Wat is SIP precies Behalve dat SIP een op tekst gebaseerd protocol is, is het tevens een 'Packet Switched Protocol’. SIP werkt ook tussen data netwerken en traditionele telefonie netwerken. Het kan een sessie tot stand brengen tussen een analoge telefoon bij meneer A en een SIP softphone van meneer B. Als meneer B in gesprek is, kan het meneer A wijzen op een andere weg om meneer B te bereiken, bijvoorbeeld via een instant message, waarbij spraak wordt omgezet in een eenvoudige tekstboodschap, die als instant message wordt verzonden naar de PC van meneer B. Het enige dat meneer A hoeft te onthouden is het telefoonnummer van meneer B. SIP gebruikt eenvoudige boodschappen om een sessie op te zetten, aan te passen of te beëindigen: • Invite - oproep • Ack - bevestiging • Cancel - onderbreek • Register - registreer locatie van de gebruiker • Bye - einde sessie SIP werkt samen met o.a. Simple Mail Transport Protocol (SMTP), Domain Name Service (DNS) en Lightweight Directory Access Protocol (LDAP). Zowel connectieloze sessies met UDP (telefonie) als connectiegeoriënteerde sessies met TCP (bv. chat) zijn mogelijk. SIP is een peer to peer protocol. De peers in een sessie worden User Agents (UAs) genoemd. De user agent kan een van de volgende rollen hebben: • User agent client (UAC): een client applicatie die een SIP request start • User agent server (UAS): een server applicatie die de gebruiker contacteert wanneer een SIP request wordt ontvangen Een SIP eindpunt kan zowel als UAC of als UAS functioneren. Of het eindpunt functioneert als UAC of UAS hangt gewoon af van wie het request komt.

Figuur 30: SIP basis architectuur en werking Steven Vlemincx Groep-T Graduaat Telecommunicatietechnieken



10.2.1.1.

87

SIP Clients

SIP clients zijn: • SoftPhones: PC’s met SIP software die kunnen gebruikt worden als UAS of UAC. • IP telefoons: vast IP telefoontoestel dat een SIP request kan doen of antwoorden op requests • Gateways: zorgen voor gesprekscontrole en veel andere functionaliteiten waaronder de belangrijkste: Translatiefunctie voor call setup en call clearing tussen LAN zijde en PSTN network.

10.2.1.2.

SIP Servers

SIP servers zijn: • Proxy server: de proxy server is een netwerkcomponent die SIP requests ontvangt van een client en deze dan forward in naam van de client. Proxy servers voorzien in functies als authenticatie, authorisatie, netwerk toegangscontrole, routing en beveiliging. • Redirect server: voorziet de client met informatie over de volgende hop die een boodschap moet nemen. Daarna contacteert de client zelf rechtstreeks de volgende hop of rechtstreeks de UAS. • Registration server: deze verwerkt de registratieaanvragen van de UAC wanneer zij zich registreren in het netwerk.

10.2.2.

Hoe SIP werkt?

SIP is een op tekst gebaseerd protocol waardoor de headers makkelijk te beschrijven zijn en de kosten voor bandbreedte (het aantal bits) geminimaliseerd kunnen worden. SIP kent overeenkomsten met het Hypertext Transfer Protocol (HTTP) wat eveneens op tekst is gebaseerd. Het reageert op een Universal Resource Locator (URL), waarmee het lijkt op een email adres, soms zelfs op een telefoonnummer. Uw email adres zou trouwens een heel goede manier kunnen zijn waarop SIP u kan bereiken. Enkele voorbeelden van URLs: Sip:[email protected] Sip:[email protected] Tel: +32015335528 SIP is een signaleringsprotocol en zorgt dus voor connectiviteit en toegang. Het maakt communicatie tussen twee SIP apparaten op een peer to peer basis mogelijk. SIP verstuurt een oproep, en deze wordt bevestigd of afgebroken. Zodra de set-up is gelukt neemt het Real Time Protocol (RTP) de communicatie over. Aan het einde van het gesprek hangt de gebruiker op, en de SIP boodschap "bye" wordt verzonden naar het andere einde.



88


Figuur 31: SIP call setup

Er is echter meer mogelijk dan alleen het opzetten van een telefoongesprek. De SIP proxy houdt precies bij waar een gebruiker zich bevindt in het netwerk en of hij aanwezig is. De SIP registration server registreert de mogelijkheden en de voorkeuren van de gebruiker. Stel dat iemand in gesprek is terwijl een telefoongesprek van een belangrijke klant binnenkomt. Door herkenning van het nummer van de klant zou het eerste gesprek natuurlijk in de wacht geplaatst kunnen worden. Dankzij de vastgelegde voorkeuren (uitwijken naar alternatief medium) en mogelijkheden (gebruiker beschikt over chat mogelijkheden) kan de gebruiker - na enkele vragen of het contact ook via een chat-sessie mag plaatsvinden - zijn klant via een chat-sessie te woord staan en afspreken om even later terug te bellen.

10.2.3.

Uitdagingen:

Behalve interessante nieuwe mogelijkheden zijn er natuurlijk ook uitdagingen. • • • • •

De netwerk infrastructuur moet werkelijk real-time communicatie ondersteunen. Dat vereist snelheid en Quality of Service. Dat is technisch mogelijk, maar niet overal haalbaar, want het heeft zijn prijs. Kosten van een SIP terminal (van SIP telefoontoestel tot PC) kunnen een obstakel vormen. Er bestaat (nog) geen uniforme koppeling met de bestaande openbare (telefonie)netwerken. Zowel de structuur (hoe gebruik ik een PSTN gateway) als tarifering (hoe worden kosten doorberekend) zijn nog niet uitgekristalliseerd. Tegenover het feit dat SIP allerlei nieuwe mogelijkheden biedt, staat dat juist traditionele PABX features grotendeels ontbreken. In een bedrijfsomgeving is dit essentieel. Noodzaak van langdurig naast elkaar bestaan van SIP en ‘legacy’.

De openheid is tegelijk een gevaar: beveiliging tegen spam, virussen, aanvallen, bescherming van de privacy zijn alle belangrijk. Een van de bekende instrumenten daartegen is de firewall. Het selectief doorlaten van SIP en internet telefonie stelt hoge eisen aan een firewall, zowel voor wat de betreft protocolafhandeling als QoS aspecten.




89

10.3. Skype, SIP en Telenet VoIP Over Skype kunnen we kort zijn. Ze hebben een eigen protocol waarmee Skype telefoons met elkaar kunnen communiceren. Ze laten daarmee officiële signaleringsprotocols links liggen. Op zich een begrijpelijk keuze: voor bijvoorbeeld SIP moet immers een behoorlijke infrastructuur ingericht worden terwijl het Skype protocol niet vereist dat een gebruiker servers inricht, zich aanmeldt, etcetera. Skype werkt met een rendevous netwerk: Skype installeren, username kiezen, even een mailtje naar je vrienden en bellen maar. Skype is dus laagdrempelig maar helaas ook (soms) van lage kwaliteit. Hoe Telenet VoIP precies werkt hebben we reeds uitvoerig gezien. Wat is nu het belangrijkste verschil tussen Skype of SIP en de Telenet VoIP dat gebruikt maakt van MGCP als signaleringsprotocol. De eerste twee opereren immers tussen peer clients en bij Telenet gaat het om een master slave relatie. Een master/slave model is eigenlijk een implementatie die heel dicht aanleunt bij traditionele telefonie. De Gateway zorgt voor alle instructies aan de “domme” MTA. Dit zorgt voor een makkelijke implementatie die zorgt voor lage kosten eindapparatuur. Bijkomend voordeel is dat door de centralisatie van alle diensten het veel makkelijker is om het netwerk te beheren. Dit is vooral een groot voordeel voor telecomoperatoren omdat zij heel veel eindgebruikers hebben. De intellegentie zit eigenlijk in de CMS en op de Gateways en niet in het protocol. Hierdoor zijn de terminals veel goedkoper dan SIP end devices Ook zijn veel MGCP features als business conferencing uitvoerig getest en goed bevonden. Bij SIP zijn er nog steeds interoperabiliteitsproblemen. SIP wordt momenteel vooral gebruikt binnen een bedrijfsnetwerk. Het telefoonverkeer gaat binnen de organisatie over de LAN. Aangezien veel bedrijven vandaag beschikken over een LAN infrastructuur met voldoende bandbreedte en redundantie is zo een infrastructuur perfect geschikt om voor een SIP implementatie. De verschillende vestigingen zijn vaak verbonden via glasvezel, leased lines of SDSL lijnen en hierdoor wordt het mogelijk om gratis te telefoneren tussen verschillende vestigingen, men blijft immers op het eigen SIP netwerk. SIP kan perfect op kleine schaal worden toegepast en het kan meegroeien met een netwerk of een bedrijf en is daarom een beter schaalbare oplossing. De allergrootste stap zal in de toekomst worden gemaakt door de providers zoals bijvoorbeeld Telenet. Telenet kan immers SIP gateways implementeren met het bestaande telefoonnet. [email protected] maakt je normale telefoon dan bereikbaar vanuit het SIP netwerk en met een 0505792757 nummer wordt je SIP-telefoon bereikbaar vanuit het normale telefoonnetwerk.




90

11. Besluit In het bedrijfsleven en ook in ons dagelijks leven is telefonie een even vanzelfsprekend als onvervangbaar communicatiemiddel geworden. Velen onder ons kunnen zich geen leven zonder telefoonverbinding meer voorstellen. Dat had Alexander Graham Bell toen hij in 1876 zijn 'elektrische spreekmachine' uitvond, zeker niet kunnen voorzien. Velen onder ons staan er niet bij stil wat er precies allemaal gebeurt vooraleer we de persoon aan de andere kant van de telefoonlijn horen. We zijn ervan overtuigd dat na het doornemen van dit werk de lezer een beter inzicht heeft gekregen in een uitloper van Graham Bell's uitvinding, namelijk VoIP zoals ze bij Telenet geïmplementeerd is. Wijzelf hebben het voorbije jaar kunnen leren en ontdekken hoe dit alles in de praktijk in zijn werk gaat. Van de netwerkopbouw en Euro-PacketCable theorie tot en met de uitvoering, de problemen en hun oplossingen die daarmee samengaan. De telefoon zal vanaf nu nooit meer hetzelfde rinkelen.



I


Literatuurlijst “Data-Over-Cable Service Interface Specifications DOCSIS 2.0”, “CM-SP-RFIv2.0-I07-041210”, http://www.cablelabs.com/ “tComLabs - Certification testing Euro-DOCSIS & Euro-PacketCable”, http://www.tcomlabs.com/ “PacketCable”, http://www.PacketCable.com/ “Cablelabs”, http://www.cablelabs.com/ “Cisco Systems, Inc”, http://www.cisco.com/ “Nortel”, http://www.nortelnetworks.com/ “Alcatel Builds Next Generation Networks”, http://www.alcatel.com/ “Arris”, http://www.arrisi.com/ “Adaptive Digital”, http://www.adaptivedigital.com International Telecommunication Union, “ITU-T G.168: Digital network echo cancellers”, http://www.itu.int/home/ “Network Protocols Guide, Network Monitoring & Analysis Tools” , http://www.javvin.com/ “Skype is free Internet telephony that just works”, http://www.skype.com/ Salman A. Baset and Henning Schulzrinne, “An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol”, http://arxiv.org/ftp/cs/papers/0412/0412017.pdf “sipforum”, http://www.sipforum.org/ “Internet RFC/STD/FYI/BCP Archives”, http://www.faqs.org/rfcs/ “Ethereal”, http://www.ethereal.com “Superb Internet”, http://www.superb.net/ “Everyones Internet”, http://www.ev1.net/ "International Multimedia Teleconferencing Consortium", http://www.imtc.org/ "Voice On The Net (VON) Coalition", http://www.von.org/ "MIT Internet Telephony Consortium", http://itel.mit.edu/ "MultiService Switching Forum", http://msforum.org/ "The Parlay Group", http://www.parlay.org/ "IP Telephony (iptel)", http://www.ietf.org/html.charters/iptel-charter.html Steven Vlemincx Groep-T Graduaat Telecommunicatietechnieken



II

Bijlage A: Provisioningsflow Euro-PacketCable



III


Bijlage B: TLV overzicht Type 1 2 3 4 4 4 4 4 4 4 6 7 12 13 14 16 17 18 19 1A 1C 1D 2B 23 24 25 27 28 29 29 29 29 29 29 29 29 29 29 0 9 A B E 15 22 22 22 20 21 26 26 26

Subtype

1 2 4 5 6 7

1 1.1 1.2 2 2.1 2.2 2.3 2.4 3

1 2

1 2

Lenght 4 1 1 n 1 4 1 4 2 1 16 16 1 4 4 n n

n 2 1 n 3 N 8 1 1 n 6 of 10 2 4 18 of 22 2 4 4 4 2 n n n 6 4 n 2 -> 16 n n n n 4 2

Value Rx freq kanaal ID 1 of 0

d1, … d16 aantal seconden sinds 1 jan 1900 IP adres

nummer 0 of 1

IP-adres 0 of 1 0 of 1 Rx frequenties timeout DS freq

DS freq start DS freq stop step size timeout filenaam

ethernet MAC adres van de CPE ip-adres compasite

manufacturer CVC co-signer CVC compasite IP UDP poort

Downstream frequentie config setting Upstream kanaal ID config setting Netwerk access control object Docsis 1.0 class of service config setting class ID Maximum downstream Rate config setting Upstream kanaal prioriteit Gagarandeerde minimum upstream kanaal data rate Maximum upstream kanaal TX burst Class-of-service Privaty enabled CM message integrity check (MIC) CMTS MIC Maximum aantal CPE's TFTP server timestamp TFTP server provisioned modemadres Upstream classifiers downstream classifiers upstream service flow encodings downstream service flow encodings payload header suppression maximum aantal classifiers Privacy enabled Verdor specific information Subscriber management control subscriber management CPE IP table subscriber management filter groups enable 2,0 mode enable test modes downstream kanalen 1 downstream kanaal 1 downstream kanaal timeout 1 downstream kaaal frequentie Downstream frequentie range Downstream frequentie range timeout Downstream frequentie range start Downstream frequentie range stop downstream frequentie range step size default scanning pad config software upgrade filenaam SNMP write access control SNMP MIB object CPE ethernet MAC adres Software upgrade TFTP server SNMP v3 kickstart waarde SNMP v3 security naam SNMP v3 manager public nummer SNMP v3 manufacturer code verification certificate SNMP v3 co-signer CVC SNMP v3 notifacatie ontvanger SNMP v3 notification Receiver IP address SNMP v3 notification Receiver UDP poortnummer



IV


26 26 FF 26 26 26 2A 5 5 5 5 5 5 5 5 5 5 5 5 5 8 C D 2C 1B 1E 1F 16 17 16 17 16 17 16 17 16 17 16 17 16 17 16 17 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16

3 4

2 2

trap type tijd in millisec

5 6 7

2 n n 6

aantal pogingen filter OID security name MAC adres

1 2 3 4 5 6 7 8 9 10 11 12

1 1 1 1 1 1 1 1 1 1 1 1 3 4 3 n 20 n 1 1 1 2 2 2 2 4 4 1 1 1 1 1 1 n n n n 12 6 n 1 n 3 2 4 4 4 4 2 2

1 of 0

1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 10 10.1 10.2 8.1 8.2 8.3 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8

1 of 0 1 of 0 1 of 0 privacy support aantal DS SAIDs van de CM aantal US SID's van de CM 1, 2 of 4 8 tot 64 v1,v2,v3 IP calssID,Type,conf code 160-bit key sequence of n blocks auth key sequence 1 - 255 1 - 255 1 - 65535 1 - 65535 1 - 65535 1 - 65535

0 of 1 0 of 1 0 , 1 of 2 0 , 1 of 2

confirmation code string of ASCII characters tos-low, tos-high, tos-mask protocol source source mask destination destination mask source port low source port high

SNMP v3 notification Receiver trap type SNMP v3 notification receiver timeout einde van de config file SNMP v3 notification receiver retries SNMP v3 notification receiver filtering parameters SNMP v3 notification receiver security name Multicast MAC adres Modem capabilities encoding concatenation support docsis version fragmentation support payload header suppression support IGMP support downstream SAID support Upstream SID support optional filtering support transmit equalizer taps per modulation interval aantal tranmit equaliser taps DCC support verdor ID encodings Modem IP adres services not available response vendor specifec capabilities HMAC digest authorisation blocks key sequence number upstream classifier reference downstream classifier reference upstream classifier identifier downstream classifier identifier upstream service flow reference downstream service flow reference upstream service flow identifier downstream service flow identifier upstream rule priority downstream rule priority upstream classifeir activation state downstream classifier activation state upstream dynamic service change action downstream dynamic service change action upstream classifier eror encodings downstream classifier eror encodings upstream packet classification encodings upstream ethernet LLC packet classification upstream ethernet destination MAC address upstream ethernet source Mac address upstream classifier errored parameter upstream classifier error code upstream classifier error message upstream IP type of service range and mask upstream IP protocol upstream IP source address upstream IP source mask upstream IP destination address upstream IP destination mask upstream TCP/UDP source port start upstream TCP/UDP source port end




16 16 16 16 16 16 16 16 16 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 19 19 19 19 19 19 19 19 19 19

9.9 9.10 10 10.1 10.2 10.3 11.1 11.2 43 9 10 10.1 10.2 8.1 8.2 8.3 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9 9.10 10 10.1 10.2 10.3 11.1 11.2 43 1 2 3 4 5.1 5.2 5.3 7 8 9 10 11 12 13 43 1 2 3 4 5.1 5.2 5.3 7 8 9

2 2 n 12 6 3 2 2 n n n 12 6 n 1 n 3 2 4 4 4 4 2 2 2 2 n 12 6 3 2 2 n 2 4 2 2 to 16 1 1 n 1 4 4 4 2 2 2 n 2 4 2 2 to 16 1 1 n 1 4 4

destination port low destination port high destination + mask source type pri-low, pri-high vlan ID

confirmation code

protocol source source mask destination destination mask source port low source port high destination port low destination port high destination + mask source type pri-low, pri-high vlan ID 1-65535 1-4,294,967,295 SID string of ASCII characters encoding subtype in error confirmation code string of ASCII characters 0 to 7 R (in bits per second) B (in bytes)

seconds seconds

SID string of ASCII characters encoding subtype in error confirmation code string of ASCII characters 0 to 7 R (in bits per second) B (in bytes)

V

upstream TCP/UDP destination port start upstream TCP/UDP destination port end upstream LLC packet classification encodings upstream destination MAC address upstream source MAC address upstream ethertype/DSAP/Mac type upstream IEEE 802.1 IP User_Priority upstream IEEE 802.1 IQ VLAN_ID upstream vendor specific classifier parameters downstream packet classification encodings downstream ethernet LLC packet classification downstream ethernet destination MAC address downstream ethernet source Mac address downstream classifier errored parameter downstream classifier error code downstream classifier error message downstream IP type of service range and mask downstream IP protocol downstream IP source address downstream IP source mask downstream IP destination address downstream IP destination mask downstream TCP/UDP source port start downstream TCP/UDP source port end downstream TCP/UDP destination port start downstream TCP/UDP destination port end downstream LLC packet classification encodings downstream destination MAC address downstream source MAC address downstream ethertype/DSAP/Mac type downstream IEEE 802.1 IP User_Priority downstream IEEE 802.1 IQ VLAN_ID downstream vendor specific classifier parameters upstream service flow reference upstream service flow identifier upstream service identifier upstream service class name upstream service flow - errored parameter upstream service flow - error code upstream service flow - error message upstream traffic priority upstream maximum sustained traffic rate upstream maximum traffic burst upstream minimum reserved traffic rate upstream assumed minimum reserved rate packet size upstream timeout for active QOS parameters upstream timeout for admitted QOS parameters upstream vendor specific QOS parameters downstream service flow reference downstream service flow identifier downstream service identifier downstream service class name downstream service flow - errored parameter downstream service flow - error code downstream service flow - error message downstream traffic priority downstream maximum sustained traffic rate downstream maximum traffic burst



VI


19

10

4

19 19 19 19 18 18 18 18 18 18 18 18 18 18 18 19 1A 1A 1A 1A

11 12 13 43 14 15 16 17 18 19 20 21 22 23 24 14 1 2 3 4

2 2 2 n 2 1 4 4 4 2 4 4 1 2 4 4

1A 1A 1A 1A 1A 1A 1A

5 6.1 6.2 6.3 6.7 6.8 6.9

1 1 1 n n 1 n

1A 1A 1A F 11

6.10 6.11 6.43

1 1 n n n

2 2 4

seconds seconds

µsec µsec µsec µsec # of grants tos-and-mask, tos-or-mask CMTS timestamp µsec 1-255 1-65535 1-65535 1-4,294,967,295 0,1,2,3 encoding subtype in error confirmation code string of ASCII characters string of bytes suppressed index value numbers of bytes in suppressionstring 0, 1

downstream minimum reserved traffic rate downstream assumed minimum reserved rate packet size downstream timeout for active QOS parameters downstream timeout for admitted QOS parameters downstream vendor specific QOS parameters upstream maximum concatenated burst upstream service flow scheduling type upstream request transmission policy upstream nominal polling interval upstream tolerated poll jitter upstream unsolicited grant size upstream nominal grant interval upstream tolerated grant jitter upstream grants per interval upstream IP type of service overwrite upstream unsolicited grant time reference maximum downstream latency Payload header suppression - classifier reference Payload header suppression - classifier identifier Payload header suppression - service flow reference Payload header suppression - service flow identifier Payload header suppression - dynamic service change action Payload header suppression - errored parameter Payload header suppression - error code Payload header suppression - error message Payload header suppression field (PHSF) Payload header suppression index (PHSI) Payload header suppression mask (PHSM) Payload header suppression size (PHSS) Payload header suppression verification (PHSV) Vendor specific PHS parameters Telephone setting options Baseline privacy configuration option



VII


Bijlage C : CM configuratie file Main { NetworkAccess 1; SwUpgradeFilename "/software/TS040428_032905_EU.TM402.EURO.img"; SwUpgradeServer 195.150.150.101; SnmpMibObject docsDevFilterIpStatus.10 Integer 4; /* createAndGo */

SnmpMibObject docsDevFilterIpControl.10 Integer 1; /* discard */ SnmpMibObject docsDevFilterIpDirection.10 Integer 3; /* both */ SnmpMibObject docsDevFilterIpDaddr.10 IPAddress 10.0.0.0 ; SnmpMibObject docsDevFilterIpDmask.10 IPAddress 255.0.0.0 ; MaxCPE 4; UsPacketClass { ClassifierRef 31; ServiceFlowRef 3; RulePriority 31; ActivationState 1; IpPacketClassifier { IpProto 17; IpSrcAddr 10.130.0.0; IpSrcMask 255.248.0.0; SrcPortStart 2427; SrcPortEnd 2427; DstPortStart 2427; DstPortEnd 2427; } } UsPacketClass { ClassifierRef 22; ServiceFlowRef 2; RulePriority 22; ActivationState 1; IpPacketClassifier { IpProto 17; IpSrcAddr 10.0.0.0; IpSrcMask 255.0.0.0; SrcPortStart 161; SrcPortEnd 161; } } UsPacketClass { ClassifierRef 23; ServiceFlowRef 2; RulePriority 23; ActivationState 1; IpPacketClassifier { IpProto 17; IpSrcAddr 10.0.0.0; IpSrcMask 255.0.0.0; DstPortStart 162; DstPortEnd 162; } } DsPacketClass { ClassifierRef 131; ServiceFlowRef 13; RulePriority 131; ActivationState 1; IpPacketClassifier { IpProto 17; IpDstAddr 10.130.0.0; IpDstMask 255.248.0.0;

Filtering: Met deze filter geen verkeer naar het 10.0.0.0-netwerk doorgelaten.




VIII

SrcPortStart 2427; SrcPortEnd 2427; DstPortStart 2427; DstPortEnd 2427; } } DsPacketClass { ClassifierRef 122; ServiceFlowRef 12; RulePriority 122; ActivationState 1; IpPacketClassifier { IpProto 17; IpDstAddr 10.0.0.0; IpDstMask 255.0.0.0; DstPortStart 161; DstPortEnd 161; } } DsPacketClass { ClassifierRef 123; ServiceFlowRef 12; RulePriority 123; ActivationState 1; IpPacketClassifier { IpProto 17; IpDstAddr 10.0.0.0; IpDstMask 255.0.0.0; SrcPortStart 162; SrcPortEnd 162; } } UsServiceFlow { UsServiceFlowRef 1; ServiceClassName "DefBEUp"; QosParamSetType 7; MaxRateSustained 512000; } UsServiceFlow { UsServiceFlowRef 3; ServiceClassName "DefCSUp"; QosParamSetType 7; } UsServiceFlow { UsServiceFlowRef 2; ServiceClassName "DefSNMPUp"; QosParamSetType 7; } DsServiceFlow { DsServiceFlowRef 11; ServiceClassName "DefBEDown"; QosParamSetType 7; MaxRateSustained 100000; } DsServiceFlow { DsServiceFlowRef 13; ServiceClassName "DefCSDown"; QosParamSetType 7; } DsServiceFlow { DsServiceFlowRef 12; ServiceClassName "DefSNMPDown"; QosParamSetType 7; }



IX


MaxClassifiers 20; GlobalPrivacyEnable 0; /* CmMic ; */ /* CmtsMic a; */ /*EndOfDataMkr*/

BPI staat uit

}



X


Bijlage D: MTA configuratie file TelephonyConfigFileBeginEnd = 1 SnmpMib = pktcMtaDevEnabled.0 true SnmpMib = pktcMtaDevCmsFqdn.1 "GWC-1501.GENTBGTN03N.CS2K.TELENET.BE" SnmpMib = pktcMtaDevCmsKerbRealmName. "TCOMLABS.COM" SnmpMib = pktcMtaDevRealmName.1 "TCOMLABS.COM" SnmpMib = pktcMtaDevRealmOrgName. "TELENET OPERATIES N.V." SnmpMib = pktcNcsEndPntConfigCallAgentId.9 "[email protected]" SnmpMib = pktcNcsEndPntConfigCallAgentId.10 "[email protected]" SnmpMib = pktcMtaDevCmsIpsecCtrl. false SnmpMib = pktcNcsEndPntConfigCallAgentUdpPort.9 2427 SnmpMib = pktcNcsEndPntConfigMWD.9 10 SnmpMib = pktcNcsEndPntConfigCallWaitingDelay.9 3 SnmpMib = pktcNcsEndPntConfigCallWaitingMaxRep.9 4 SnmpMib = pktcNcsEndPntConfigCallAgentUdpPort.10 2427 SnmpMib = pktcNcsEndPntConfigMWD.10 10 SnmpMib = pktcNcsEndPntConfigCallWaitingDelay.10 3 SnmpMib = pktcNcsEndPntConfigCallWaitingMaxRep.10 4 SnmpMib = ppCfgMtaCountryTemplate.0 belgium SnmpMib = pktcSigDevCIDMode.0 duringRingingETS SnmpMib = ppCfgMtaCallpFeatureSwitch.0 hexstr: 08.00.44.13 SnmpMib = ppCfgPortLoopCurrent.1 high SnmpMib = ppCfgPortLoopCurrent.2 high SnmpMib = arrisMtaDevLoopVoltagePolicy.0 always_voltage_present SnmpMib = arrisMtaDevLoopVoltageKey.0 "16E30847A2FACE47" SnmpMib = pktcSigDefCallSigDscp.0 24 SnmpMib = pktcSigDefMediaStreamDscp.0 40 TelephonyConfigFileBeginEnd = 255



XI


Bijlage E : Call-setup van MTA naar MTA MTA 1 : zender

Uitleg van de actie

MTA 2 : ontvanger

0001:44:44.450 10.213.8.44:2427 => PP (len=99) RQNT 81718 aaln/[email protected] MGCP 1.0 NCS 1.0 X: 43439 S: x-XL/rev(-) Q: loop R: hd(N)

CMS beveelt aan de MTA om het uithaken (hd) direct te melden.

0005:41:36.835 10.213.8.48:2427 => PP (len=89) RQNT 21199 aaln/[email protected] MGCP 1.0 NCS 1.0 X: 19313 S: Q: loop R: hd(N)

0001:44:44.450 (size=13) 200 81718 OK

Bevestiging van de RQNT.

0005:41:36.835 (size=13) 200 21199 OK

PP

=>

10.213.8.44:2427

0001:44:44.795 PP => 10.213.8.44:2427 (size=70) NTFY 12 aaln/[email protected] MGCP 1.0 NCS 1.0 X: 43439 O: hd

Aan de zijde van MTA 1 wordt de hoorn opgenomen. De MTA meld dit aan de CMS.

0001:44:44.840 (len=10) 200 12 OK

NTFY 12 wordt bevestigd.

10.213.8.44:2427

=>

PP

0001:44:44.855 10.213.8.44:2427 => PP (len=91) RQNT 81774 aaln/[email protected] MGCP 1.0 NCS 1.0 X: 43446

PP

=>

10.213.8.48:2427

Dez e event smoest gemeld worden volgends RQNT met X:43439 .

De CMS beveelt aan MTA 1 om een hookflash (hf) te negeren, maar inhaken (hd) direct door te geven. Hij moet dit ook blijven chechen. Steven Vlemincx & Bert Dauwe



XII


Q: loop R: hf(I), hu(N) 0001:44:44.860 (size=13) 200 81774 OK

PP

=>

10.213.8.44:2427

Bevestiging van pakketnr 81774 (RQNT)

0001:44:44.910 10.213.8.44:2427 => PP (len=166) RQNT 81777 aaln/[email protected] MGCP 1.0 NCS 1.0 X: 43448 D: (1XX|2X|3X|4X|5X|6X|7X|8X|9X|0XXXXXXX|*XX|#X X|A|D) S: dl R: hf(I,K), hu(N), oc, of, [0-9*#T](D)

CMS geeft volgende instructies aan MTA 1: - D: definitie van de Digit map, maw waaraan moet de digit map voldoen om geldig te zijn. - S: dl : MTA 1 moet kiestoon afspelen. - R : wat doen met welk event. Hookflash negeren Uithaken direct doorgeven Oc operation complete Of operation failed [0-9*#T](D) Digits volgens digit map.

0001:44:44.915 (size=13) 200 81777 OK

RQNT wordt bevestigd.

PP

=>

10.213.8.44:2427

0001:44:48.745 PP => 10.213.8.44:2427 (size=83) NTFY 13 aaln/[email protected] MGCP 1.0 NCS 1.0 X: 43448 O: 0,1,5,7,5,2,1,2 0001:44:48.760 10.213.8.44:2427 => PP (len=10) 200 13 OK

MTA 1 geeft de eerste nummers door volgens de digit map.

0001:44:48.840 10.213.8.44:2427 => PP (len=108) RQNT 81961 aaln/[email protected] MGCP 1.0 NCS 1.0

CMS beveelt aan MTA1 om nog verder te kijken naar events en dit ook te blijven doen.

Bevestiging van pakketnr 13 (NTFY)

Steven Vlemincx & Bert Dauwe Groep-T Graduaat Telecommunicatietechnieken


XIII


X: 43481 S: Q: loop R: hf(I), hu(N), [0-9*#](N) 0001:44:48.840 (size=13) 200 81961 OK

PP

=>

10.213.8.44:2427


0001:44:49.035 PP => 10.213.8.44:2427 (size=69) NTFY 14 aaln/[email protected] MGCP 1.0 NCS 1.0 X: 43481 O: 4

MTA 1 geeft het laatste nummer door (O:4)

0001:44:49.045 10.213.8.44:2427 => PP (len=10) 200 14 OK 0001:44:49.085 10.213.8.44:2427 => PP (len=96) RQNT 81964 aaln/[email protected] MGCP 1.0 NCS 1.0 X: 43483 S: Q: loop R: hu(N), hf(N)


0001:44:49.090 (size=13) 200 81964 OK

PP

=>

10.213.8.44:2427

0001:44:49.150 10.213.8.44:2427 => PP (len=143) 81966 CRCX aaln/[email protected] MGCP 1.0 NCS 1.0

CMS beveelt MTA 1 op inhaken (hu) en een hookflash (hf) direct door te geven. De MTA moet ook blijven controleren op deze events. De hookflash is nu belangrijk doorschakeling mogelijk te maken.

om

bv


CMS beveelt MTA1 om een verbinding op te zetten en geeft de nodige parameters mee. C : connection identifier M : connection mode. Steven Vlemincx & Bert Dauwe



XIV


C: D3205CCA20C6CFC8FFFFB585 M: inactive L: p:20, a:PCMA, sc-rtp:60/50, sc-rtcp:80/70

L / lijn parameters zoals de codec, de packetisation time, …

CMS geeft ook aan MTA 2 het bevelom een verbinding op te zetten. Ook hier geeft hij de parameters aan mee. Merk op dat we hier werken met dezelfde connection identifier. Is dit niet zo, dan zal er geen verbindig ussen beide MTA’s worden opgezet.

0005:41:36.860 10.213.8.48:2427 => PP (len=351) CRCX 21200 aaln/[email protected] MGCP 1.0 NCS 1.0 C: D3205CCA20C6CFC8FFFFB585 M: inactive L: p:20, a:PCMA, sc-rtp:60/50, scrtcp:80/70 v=0 o=- 1257830 1257830 IN IP4 10.130.96.228 s=c=IN IP4 10.130.96.228 t=0 0 m=audio 56558 RTP/AVP 8 b=AS:80 a=mptime:20 a=ptime:20 a=rtpmap:8 PCMA/8000/1 a=X-pc-csuites-rtp:60/50 a=X-pc-csuites-rtcp:80/70

0001:44:49.165 PP => 10.213.8.44:2427 (size=226) 200 81966 OK I: 5 v=0 o=- 1257830 1257830 IN IP4 10.130.96.228 s=c=IN IP4 10.130.96.228 t=0 0 m=audio 56558 RTP/AVP 8

Beide MTA’s bevestigen aan de CMS dat ze een verbinding hebben opgezet. Ze geven ook door welke codec ed ze kunnen gebruiken. Parameter C geeft het IP adres van hun MTA gedeelte mee.

0005:41:36.880 PP => 10.213.8.48:2427 (size=225) 200 21200 OK I: 12 v=0 o=- 4099373 4099373 IN IP4 10.130.98.32 s=c=IN IP4 10.130.98.32 t=0 0 m=audio 51254 RTP/AVP 8 Steven Vlemincx & Bert Dauwe



XV


b=AS:80 a=mptime:20 a=ptime:20 a=rtpmap:8 PCMA/8000/1 a=X-pc-csuites-rtp:60/50 a=X-pc-csuites-rtcp:80/70

b=AS:80 a=mptime:20 a=ptime:20 a=rtpmap:8 PCMA/8000/1 a=X-pc-csuites-rtp:60/50 a=X-pc-csuites-rtcp:80/70

0001:44:49.225 10.213.8.44:2427 => PP (len=309) MDCX 81967 aaln/[email protected] MGCP 1.0 NCS 1.0 C: D3205CCA20C6CFC8FFFFB585 I: 5 M: inactive

CMS stuurt een modify connection (MDCX) naar MTA1 met daarin de parameters van de ontvangende MTA (MTA2) zodat ze tijdens de communicatie met dezelfde codec werken.

v=0 o=- 4099373 4099373 IN IP4 10.130.98.32 s=c=IN IP4 10.130.98.32 t=0 0 m=audio 51254 RTP/AVP 8 b=AS:80 a=mptime:20 a=ptime:20 a=rtpmap:8 PCMA/8000/1 a=X-pc-csuites-rtp:60/50 a=X-pc-csuites-rtcp:80/70 0001:44:49.240 (size=13) 200 81967 OK

PP

=>

10.213.8.44:2427

0001:44:49.260 10.213.8.44:2427 => PP (len=97) RQNT 81968 aaln/[email protected]

Bevestiging van pakketnr 81967 (MDCX)

Als er resources vrij zijn inhet netwerk om het gesprek op te zetten, gaat de CMS bevelen aan MTA1 om ringback tone(S:rt) af te spelen.

0005:41:36.905 10.213.8.48:2427 => PP (len=136) RQNT 21201 aaln/[email protected] Steven Vlemincx & Bert Dauwe



XVI


MGCP 1.0 NCS 1.0 X: 43487 S: rt Q: loop R: hu(N), hf(N)

0001:44:49.260 (size=13) 200 81968 OK

PP

=>

10.213.8.44:2427

MTA2 moet een belstroom(S:rg) sturen naar het telefoontoestel. S:ci geeft de CLIP informatie weer of de weergave oproeper. MTA2 moet ook direct melden als de telefoon wordt opgenomen. Bevestiging door beide MTA’s van voorgaande RQNT

MGCP 1.0 NCS 1.0 X: 19316 S: ci(01/22/13/39, 015330898, "NOCSOC"), rg Q: loop R: hd(N), oc, of 0005:41:36.905 (size=13) 200 21201 OK

PP

=>

10.213.8.48:2427

MTA 2 meldt aan de CMS dat de telefoon wordt opgenomen.



0005:41:43.575 (len=10) 200 65 OK

0001:44:55.955 10.213.8.44:2427 => PP (len=141) MDCX 82310 aaln/[email protected] MGCP 1.0 NCS 1.0 C: D3205CCA20C6CFC8FFFFB585 I: 5 M: sendrecv X: 43521 Q: loop S: R: hu(N), hf(N)

Beide MTA’s krijgen ze de opdracht van de CMS om de verbinding open te zetten voor zowel zenden als ontvangen zodat een gesprek mogelijk wordt.

0005:41:43.580 10.213.8.48:2427 => PP (len=142) MDCX 21529 aaln/[email protected] MGCP 1.0 NCS 1.0 C: D3205CCA20C6CFC8FFFFB585 I: 12 M: sendrecv X: 19363 Q: loop S: R: hu(N), hf(N)

RTP stream

Gesprek

Tijdens het gesprek moeten ze ook blijven nakijken of de telefoon wordt ingehaakt of een hookflash wordt gegeven.

10.213.8.48:2427 => PP

RTP stream Steven Vlemincx & Bert Dauwe



XVII


0001:44:55.975 (size=13) 200 82310 OK

PP

=>

10.213.8.44:2427

Bevestiging van voorgaande MDCX

0005:41:43.595 (size=13) 200 21529 OK

De telefoon van MTA2 wordt ingehaakt omdat de klant van telefoon toestel wil veranderen. MTA2 geeft dit onmiddellijk door. De verbinding wordt nog net afgebroken maar op de CMS wordt een timer gestart.

0005:42:05.845 PP => 10.213.8.48:2427 (size=70) NTFY 66 aaln/[email protected] MGCP 1.0 NCS 1.0 X: 19363 O: hu 0005:42:05.855 10.213.8.48:2427 => PP (len=10) 200 66 OK


PP

=>

10.213.8.48:2427

De CMS beveelt MTA2 om direct te melden als de telefoon terug wordt opgenomen.

0005:42:05.860 10.213.8.48:2427 => PP (len=89) RQNT 22636 aaln/[email protected] MGCP 1.0 NCS 1.0 X: 19519 S: Q: loop R: hd(N)


0005:42:05.860 (size=13) 200 22636 OK

Er wordt terug een telefoontoestel uitgehaakt op lijninterface 1 van MTA2. De MTA geeft dit onmiddellijk door aan de CMS zoals hem was gevraagd in RQNT met X:19519 .

0005:42:11.010 PP => 10.213.8.48:2427 (size=70) NTFY 67 aaln/[email protected] MGCP 1.0 NCS 1.0 X: 19519 O: hd 0005:42:11.025 10.213.8.48:2427 => PP (len=10)


PP

=>

10.213.8.48:2427



XVIII


200 67 OK De CMS beveelt MTA2 terug om een hookflask en inhaken direct te melden.

0005:42:11.025 10.213.8.48:2427 => PP (len=96) RQNT 22888 aaln/[email protected] MGCP 1.0 NCS 1.0 X: 19568 S: Q: loop R: hu(N), hf(N)


0005:42:11.030 (size=13) 200 22888 OK

0001:45:15.880 10.213.8.44:2427 => PP (len=53) AUEP 83318 *@m22322.emta.telenet.be MGCP 1.0 NCS 1.0

Af en toe polst de CMS naar de status van de lijnen van een MTA via een AUEP. Dit zien we hier, maar dit maakt niet echt deel uit van de call setup.

0005:42:03.265 10.213.8.48:2427 => PP (len=53) AUEP 22471 *@m24053.emta.telenet.be MGCP 1.0 NCS 1.0

0001:45:15.885 PP => 10.213.8.44:2427 (size=79) 200 83318 OK Z: aaln/[email protected] Z: aaln/[email protected]

Bevestiging AUEP.

0005:42:03.270 PP => 10.213.8.48:2427 (size=79) 200 22471 OK Z: aaln/[email protected] Z: aaln/[email protected]

0001:45:29.735 PP => 10.213.8.44:2427 (size=70) NTFY 15 aaln/[email protected] MGCP 1.0 NCS 1.0 X: 43521 O: hu

De telefoon aan lijninterface 1 van MTA1 wordt ingehaakt. MTA1 geeft dit ogenblikkelijk door aan de CMS. Omdat dit de originator, wordt er geen timer gestart.

van

het

voorgaande

pakket

PP

=>

10.213.8.48:2427



XIX


0001:45:29.745 (len=10) 200 15 OK

10.213.8.44:2427

=>

PP


0001:45:29.750 10.213.8.44:2427 => PP (len=134) MDCX 83966 aaln/[email protected] MGCP 1.0 NCS 1.0 C: D3205CCA20C6CFC8FFFFB585 I: 5 M: sendonly X: 43763 Q: loop S: R: hd(N)

De CMS beveelt MTA1 om enkel nog pakketten te versturen bv: de pakketten die nog in de jitterbuffer zitten. Deze buffer bevat in normale omstandigheden steeds de laatste 2 pakketten. Met een pakketisation time van 20 ms betekent dit dus 40ms.

0005:42:17.430 10.213.8.48:2427 => PP (len=104) MDCX 23237 aaln/[email protected] MGCP 1.0 NCS 1.0 C: D3205CCA20C6CFC8FFFFB585 I: 12 M: sendonly

0001:45:29.765 (size=13) 200 83966 OK

10.213.8.44:2427

Bevestiging van pakketnr 83966 & 23237 (MDCX)

0005:42:17.445 (size=13) 200 23237 OK

0001:45:29.795 10.213.8.44:2427 => PP (len=91) DLCX 83967 aaln/[email protected] MGCP 1.0 NCS 1.0 C: D3205CCA20C6CFC8FFFFB585 I: 5

De CMS geeft aan beide MTA’s het bevel om de verbinding C: D3205CCA20C6CFC8FFFFB585 te verbreken.

0005:42:17.470 10.213.8.48:2427 => PP (len=92) DLCX 23238 aaln/[email protected] MGCP 1.0 NCS 1.0 C: D3205CCA20C6CFC8FFFFB585 I: 12

0001:45:29.825 PP => 10.213.8.44:2427 (size=138) 250 83967 Connection Deleted P: PS=1691, OS=270560, PR=1690, OR=270400, PL=0, JI=0, LA=10, PC/RPS=1125, PC/ROS=180000, PC/RPL=0, PC/RJI=0

De MTA’s bevestigen dat ze verbinding hebben verbroken. Ze geven hierbij gegevens mee die de kwaliteit van het afgelopen gesprek aanduiden. PS: packets send OS: octets(bytes) send PR : packets received OR: octest received PL: packets lost

0005:42:17.495 PP => 10.213.8.48:2427 (size=138) 250 23238 Connection Deleted P: PS=1693, OS=270880, PR=1688, OR=270080, PL=0, JI=1, LA=10, PC/RPS=1285, PC/ROS=205600, PC/RPL=0, PC/RJI=0

PP

=>

PP

=>

10.213.8.48:2427



XX


JI: jitter LA:latency 0001:45:29.865 10.213.8.44:2427 => PP (len=99) RQNT 83968 aaln/[email protected] MGCP 1.0 NCS 1.0 X: 43765 S: x-XL/rev(-) Q: loop R: hd(N)

MTA1 krijgt terug het bevel om door te geven als er wordt uitgehaakt. Ondertussen moet er geen toon worden afgespeeld (S: x-XL/rev(-))

0001:45:29.870 (size=13) 200 83968 OK


PP

=>

10.213.8.44:2427

De telefoon op lijninterface 1 van MTA2 wordt nu ook ingehaakt. De MTA geeft dit onmiddellijk door aan de CMS.



0005:42:19.945 (len=10) 200 68 OK

MTA2 krijgt terug het bevel om door te geven als er wordt uitgehaakt. Ondertussen moet er geen toon worden afgespeeld (S: x-XL/rev(-) )


10.213.8.48:2427 => PP



XXI



0005:42:19.990 (size=13) 200 23337 OK

PP

=>

10.213.8.48:2427

MTA’s zijn terug klaar om een volgend gesprek op te zetten.



XXII


Bijlage F: Call-setup van PSTN naar MTA MTA

Uitleg bij de actie


Mta meldt met pakketnummer 7 dat lijn 2 (aaln/2) wordt uitgehaakt (hu)

0000:52:37.515 200 7 OK

Bevestiging van pakket nr 7 (=NTFY)

10.213.8.44:2427 => PP (len=9)

0000:52:37.530 10.213.8.44:2427 => PP (len=91) RQNT 53717 aaln/[email protected] MGCP 1.0 NCS 1.0 X: 29728 Q: loop R: hf(I), hu(N)

CMS beveelt aan de MTA met om een hookflash te negeren (I) en inhaken direct door te geven b(N) Requested identifier X is uniek. Hiermee geeft de MTA aan op welke RQNT hij antwoordt.

0000:52:37.530 PP => 10.213.8.44:2427 (size=13) 200 53717 OK

Bevestiging van pakket nr. 53717 (=RQNT)

0000:52:37.570 10.213.8.44:2427 => PP (len=166) RQNT 53718 aaln/[email protected] MGCP 1.0 NCS 1.0 X: 29729 D: (1XX|2X|3X|4X|5X|6X|7X|8X|9X|0XXXXXXX|*XX|#XX|A|D) S: dl R: hf(I,K), hu(N), oc, of, [0-9*#T](D)

CMS beveelt aan de MTA: - X: 29729 :identifier die een volg nr geeft aan de RQNT’s - D: (1XX|2X|3X|4X|5X|6X|7X|8X|9X|0XXXXXXX|*XX|#XX|A|D) Dit geeft de digit map weer of beter gezegd waaraan de nummering moet voldoen om doorgegeven mogen te worden aan de CMS. De A en de D zeggen dat de MTA de digits moet verzamelen volgens de digit map. - S : dl kiestoon af te spelen. - R: hf(I,K), hu(N), oc, of, [0-9*#T](D) Hookflash moet worden genegeerd Uithaken moet direct worden doorgegeven. Steven Vlemincx & Bert Dauwe



XXIII


operation complete(oc), operation fail(of) Eender welke digit moet worden doorgegeven indien het voldoet aan de digit map. 0000:52:37.575 PP => 10.213.8.44:2427 (size=13) 200 53718 OK

Bevestiging van pakket nr 53718 (=RQNT)

0000:52:41.060 PP => 10.213.8.44:2427 (size=82) NTFY 8 aaln/[email protected] MGCP 1.0 NCS 1.0 X: 29729 O: 0,1,5,3,3,5,5,7

MTA meldt aan de CMS de eerste nummers volgens de ontvangen digitmap. Deze melding werd bevolen in RQNT met X=29729.

0000:52:41.095 200 8 OK

Bevestiging van packet nr 8 (=NTFY)

10.213.8.44:2427 => PP (len=9)

0000:52:41.100 10.213.8.44:2427 => PP (len=108) RQNT 53911 aaln/[email protected] MGCP 1.0 NCS 1.0 X: 29759 S: Q: loop R: hf(I), hu(N), [0-9*#](N)

Digits die werden gevormd vooraleer NTFY bevestigd wordt, worden in de quarantaine buffer geplaatst zodat ze later kunnen verzonden worden. Vandaar de parameter Q :loop . Hiermee geeft de CMS aan dat de MTA zijn quarantaine buffer moet blijven checken, op zoek naar events ed.

0000:52:41.100 PP => 10.213.8.44:2427 (size=13) 200 53911 OK


0000:52:41.530 PP => 10.213.8.44:2427 (size=68) NTFY 9 aaln/[email protected] MGCP 1.0 NCS 1.0 X: 29759 O: 2

MTA geeft aan de CMS het laatste cijfer door namelijk “ 2” wat hem gevraagd werd volgens RQNT met X: 29759.

0000:52:41.540 200 9 OK

Bevestiging van pakket nr 9 (=NTFY)

10.213.8.44:2427 => PP (len=9)

0000:52:41.585 10.213.8.44:2427 => PP (len=96) RQNT 53914 aaln/[email protected] MGCP 1.0 NCS 1.0

CMS beveelt aan de MTA om het inhaken (hu) van de telefoon direct door te geven alsook een hookflash direct te melden. De MTA moet ook zijn quarantaine buffer blijven checken Steven Vlemincx & Bert Dauwe



XXIV


X: 29761 S: Q: loop R: hu(N), hf(N) 0000:52:41.590 PP => 10.213.8.44:2427 (size=13) 200 53914 OK


0000:52:41.635 10.213.8.44:2427 => PP (len=143) CRCX 53915 aaln/[email protected] MGCP 1.0 NCS 1.0 C: D3205BBE101E28F7FFFFF084 M: inactive L: p:20, a:PCMA, sc-rtp:60/50, sc-rtcp:80/70

CMS geeft aan de MTA door dat er een RTP connectie mag worden opgezet en geeft hiervoor ook de nodige parameters mee. - C: D3205BBE101E28F7FFFFF084 is de call identifier . Deze parameter is identiek voor 1 gesprek. - Connection mode M: inactieve betekent dat de connectie moet worden opgezet, maar dat er nog geen data mag worden over gezonden. - L: p:20, a:PCMA, sc-rtp:60/50, sc-rtcp:80/70 geeft de parameters aangaande de codering weer. We vinden hier oa de packetisation time, PCMA of G711 en encryptie methodes voor RTP en RTPC.

CALLP: TOD: 0016:52:05 tickTime: 0000:52:41.640 0000:52:41.655 PP => 10.213.8.44:2427 (size=222) 200 53915 OK I: 3 v=0 o=- 632328 632328 IN IP4 10.128.0.247 s=c=IN IP4 10.128.0.247 t=0 0 m=audio 59672 RTP/AVP 8 b=AS:80 a=mptime:20 a=ptime:20 a=rtpmap:8 PCMA/8000/1 a=X-pc-csuites-rtp:60/50 a=X-pc-csuites-rtcp:80/70 0000:52:41.685 10.213.8.44:2427 => PP (len=233) MDCX 53916 aaln/[email protected] MGCP 1.0

De MTA bevestigt de CRCX en geeft een connection identifier mee met de parameter I. De MTA geeft ook mee welke algoritmes hij aankan en in welke volgorde hij ze verkiest.

De CMS beveelt de MTA om een aanpassing te doen van de connectie met Steven Vlemincx & Bert Dauwe



XXV


NCS 1.0 C: D3205BBE101E28F7FFFFF084 I: 3 M: inactive v=0 o=PVG 0 0 IN IP4 10.213.16.15 s=p=+1 6135555555 c=IN IP4 10.213.16.15 t=0 0 m=audio 55582 RTP/AVP 8 13 19 a=ptime:20

C: D3205BBE101E28F7FFFFF084. Hij geeft hier in mee welke algoritmes gebruikt moeten worden. c=IN IP4 10.213.16.15 geeft aan met wie de MTA moet communiceren. In dit geval is dit de PVG omdat we van een Voip naar een PSTN connectie wensen over te gaan.

0000:52:41.695 PP => 10.213.8.44:2427 (size=13) 200 53916 OK

Bevestiging van pakket nr 53916 (=MDCX)

0000:52:41.715 10.213.8.44:2427 => PP (len=103) MDCX 53917 aaln/[email protected] MGCP 1.0 NCS 1.0 C: D3205BBE101E28F7FFFFF084 I: 3 M: sendrecv

Tot hier was de verbinding opgezet, maar was ze nog niet actief gezet. Daarom stuurt de CMS naar de MTA een bericht dat deze de connectie moet activeren (sendrecv)

0000:52:41.725 PP => 10.213.8.44:2427 (size=13) 200 53917 OK

Bevestiging van pakket nr. 53917 (=MDCX)

0000:52:55.740 10.213.8.44:2427 => PP (len=91) DLCX 54690 aaln/[email protected] MGCP 1.0 NCS 1.0 C: D3205BBE101E28F7FFFFF084 I: 3

De B zijde (PSTN) haakt in. De CMS beveelt aan de MTA om de RTP connectie met C: D3205BBE101E28F7FFFFF084, te verbreken zodat de resources terug worden vrij gegeven.

CALLP: TOD: 0016:52:19 tickTime: 0000:52:55.745 0000:52:55.770 PP => 10.213.8.44:2427 (size=134) 250 54690 Connection Deleted P: PS=698, OS=111680, PR=674, OR=107840, PL=0, JI=0, LA=5, PC/RPS=656, PC/ROS=104960, PC/RPL=1, PC/RJI=0

De MTA bevestigd met een 250 dat de connectie werd verbroken. Hij geeft ook direct een aantal parameters mee die de kwaliteit van het gesprek weergeven. PS: Packets send Steven Vlemincx & Bert Dauwe



XXVI


0000:52:55.785 10.213.8.44:2427 => PP (len=96) RQNT 54691 aaln/[email protected] MGCP 1.0 NCS 1.0 X: 29926 S: Q: loop R: hu(N), hf(I)

OS geeft het aantal verzonden bytes weer PR packets received OR geeft het aantal ontvangen bytes weer PL packets lost JI jitter … De CMS beveelt aan de MTA om direct te melden date r wordt ingehaakt. Indien er een hookflash wordt gegeven, mag dit worden genegeerd. De MTA moet ook blijven kijken naar zijn quarantaine buffer.

0000:52:55.790 PP => 10.213.8.44:2427 (size=13) 200 54691 OK


0000:52:55.880 10.213.8.44:2427 => PP (len=97) RQNT 54695 aaln/[email protected] MGCP 1.0 NCS 1.0 X: 29931 S: bz Q: loop R: hu(N), hf(N)

De CMS zegt aan de MTA dat hij bezettoon (bz) moet afspelen.

0000:52:55.885 PP => 10.213.8.44:2427 (size=13) 200 54695 OK



De MTA meldt aan de CMS dat er wordt ingehaakt zoals werd gevraagd in RQNT met X: 29931

0000:52:59.180 200 10 OK

Bevestiging van pakket nr. 10 (=NTFY)

10.213.8.44:2427 => PP (len=10)

0000:52:59.185 10.213.8.44:2427 => PP (len=89) RQNT 54907 aaln/[email protected] MGCP 1.0

Hij beveelt ook om inhaken (hu) en een hookflash (hf) direct te melden.

De CMS beveelt aan de MTA om direct (N )door te geven als er wordt uitgehaakt (hd) Steven Vlemincx & Bert Dauwe



XXVII


NCS 1.0 X: 29966 S: Q: loop R: hd(N) 0000:52:59.185 PP => 10.213.8.44:2427 (size=13) 200 54907 OK

Bevestiging van packetnr 54907 (=RQNT)


CMS beveelt de MTA om geen sigaal meer te sturen: S: x-XL/rev(-) : eender welk signal, uitschakelen (rev(-))

0000:52:59.225 PP => 10.213.8.44:2427 (size=13) 200 54909 OK


Verder wordt er terug gevraagd om uithaken te melden.



XXVIII


Bijlage G : Traffic generator 1. Wat is een traffic generator We gebruiken een traffic generator van het type Smartbits SMB-2000. Onze traffic generator heeft 8 ethernetpoorten die data kunnen uitsturen. We kunnen bij de configuratie allerlei parameters instellen zoals bijvoorbeeld de packetgrootte. De traffic generator simuleert als het ware een aantal CPE’s die ethernetpakketten uitsturen.

2. Configuratie van de traffic generator 2.1 Connecteren Bij de Smartbits traffic generator wordt het software pakket Smartwindow geleverd. Start dit pakket op vanop een PC. Je krijgt dan onderstaand scherm.

Figuur 32: Smartbits traffic generator, startscherm

Kies de SMB-2000 want dit is het type dat wij gebruiken. Nu moeten we nog connecteren met onze machine. Dit doen we als volgt: Klik op -> actions -> connect Je krijgt dan volgend scherm waarin je de setup van de Smartbits ziet:



XXIX


Figuur 33: Smartbits traffic generator, connecteren

2.2 Transmit setup Nu moeten we ervoor zorgen dat er connectiviteit is op laag 2. We moeten dus voor de verschillende poorten een MAC adres geven. In de transmit setup configureer je een MAC adres voor elke poort. Voor poort 1:

Figuur 34: Smartbits traffic generator, transmit setup slot1

De MAC destination is hier het MAC adres van de gigabit ethernetkaart van de CMTS. Het source adres is het MAC adres dat je instelt voor poort 1. Tevens geven we ook mee met welke IP adressen poort 1 moet communiceren. Voor de andere poorten:



XXX


Figuur 35: Smartbits traffic generator, overige slots

Het MAC destination adres is hier steeds het MAC adres van de CMTS. Voor het MAC adres van onze poort op de generator kiezen we een adres en tellen steeds “1” bij voor de andere poorten. Het netwerk source adres is het adres dat we aan onze poort geven. Ook hier geldt weer dat we 1 optellen voor de volgende poorten. Het netwerk destination adres is het adres dat we gaven aan poort 1 in ons geval. De gateway is onze default gateway dus onze CMTS.

2.3 Layer 3 setup Je geeft hier een IP adres aan de poort van de Smartbits. Je geeft dus een vast IP adres aan de CPE’s, en moet er dan ook voor zorgen dat de host authorisation uit staat op de CMTS. Natuurlijk moeten we ervoor zorgen dat onze IP adressen die we hier geven overeenstemmen met deze die we in de transmit setup hebben ingesteld. Voor poort 1:




XXXI

Figuur 36: Smartbits traffic generator, layer 3 setup, port 1

Voor poort 2:

Figuur 37: Smartbits traffic generator, layer 3 setup, port 1

Ook hier geldt dat we steeds 1 optellen voor de andere poorten.



XXXII


Vervolgens kunnen we ook nog door op de kaart te klikken, overschakelen van 10Mb half duplex naar 100Mb Full duplex. Tenslotte moeten we nog een -> action -> Layer3 ARP doen. Hierna is onze configuratiefile klaar.

Figuur 38: Smartbits traffic generator, configuratiefile

2.4 Configuratiefile opslaan We slaan ze nu op zodat we de volgende keer snel terug aan de slag kunnen. We doen dit zowel per kaart als voor de ganse config. Voor de kaart: Klik op de kaart -> SmartCard Save en geef een naam waarin het poortnummer voorkomt. Voor de algemene config: File -> save Om de opgeslagen configuratiefileterug te laden begin je met de algemene configuratiefile File -> open Vervolgens ga de je configuratiefileper kaart laden: Klik op de kaart -> SmartCard open Na het laden steeds een layer 3 ARP doen.

2.6 Test Controleer op de CMTS of alle ingegeven adressen ook werkelijk in de arp table staan. BSR58PROP01:7A#show arp | in 246 Internet 10.213.246.2 0 0000.2040.0002 Internet 10.213.246.3 0 0000.2040.0003 Internet 10.213.246.4 0 0000.2040.0004

ARPA ARPA ARPA

cable 0/0 cable 0/0 cable 0/0 Steven Vlemincx & Bert Dauwe



XXXIII


Internet 10.213.246.5 0 0000.2040.0005 ARPA cable 0/0 BSR58PROP01:7A#show arp | in 249 Internet 10.213.249.1 0030.b809.7ef1 ARPA ethernet 15/1 Internet 10.213.249.2 0 0000.2040.0001 ARPA ethernet 15/1 Internet 10.213.249.5 0030.b809.7ef2 ARPA ethernet 15/2 Als dat allemaal OK is, dan kunne we onze test starten. Klik hiervoor beneden op de kaart. Je zal zien dat de startknop dan verandert in een stop knop. Open nu de smartcounters via actions of F9. Selecteer de gebruikte interfaces en vink in het submenu view “rates only aan”. Men krijgt nu een overzicht van de verzonden/ ontvangen data.

Figuur 39: Smartbits traffic generator, overzicht verzonden en ontvangen data

3. Bij problemen -

Controleer filtering van de modems. De kabelmmodems mogen niet filteren op 10.0.0.0. Doe nogmaals een layer 3 arp en controleer op de CMTS. Reset modems. Controleer de setup van de trafficgenerator.



XXXIV


Bijlage H : Call generator We geven even een overzicht hoe het testscript er moet uitzien op de call-generator. Volgende settings moeten worden ingevoerd: Name: A->B;B->A st Uses script #2 Parameter: a_channel = 019 Parameter: b_channel = 020 Parameter: dial_type = 2 Parameter: a_digits_1 = 011749587 Parameter: a_digits_2 = Parameter: b_digits_1 = 011749586 Parameter: b_digits_2 = Parameter: timed_start = 1.8 s Parameter: st_sig_dly = 3 s Parameter: st_sig_fail = 15 Parameter: dial_delay = 2 s Parameter: rings =2 Parameter: timeout = 10 s Parameter: ring_cycle = 8 s Parameter: answer_delay = 0 Parameter: answer_y-1 = 0 Parameter: cut_thru =2 s Parameter: id = 123 Parameter: conversation = 50 Parameter: intercall = 3 s Parameter: call_call<s> = 0 s Parameter: level_l = -9 Parameter: level_h = -9 Parameter: offset_l = 0.0 Parameter: offset_h = 0.0 Parameter: ontime = 60 Parameter: offtime = 60 Parameter: confirm_time = 5

Eerst wordt een oproep van lijn a naar b gelanceerd, daarna van lijn b naar a, enz.. Aansluiting lijn a op de Ameritec Aansluiting lijn b op de Ameritec DTMF nummeren Nr dat lijn a oproept Nr dat lijn b oproept Wachttijd vooralleer uit te haken , verschilt 0,2sec per c programm Wachttijd op kiestoon na uithaken Wachttijd voor nummeren Aantal belsignalen vooralleer de oproep te aanvaarden Time-out tussen laatste nummer en eerste beltoon Belcyclus (tijd tussen 2 cycli) Tijd vooralleer een antwoord bericht te sturen Tijd tussen uithaken en het starten van de spraakkanaaltesten. Sequentie om spraakkanaal te testen (1-2-3) Gespreksduur in 1/10 sec Tijd tussen inhaken en terug uithaken. Tijd tussen het starten van een eerste oproep en een tweede Nummeringsparameters. Nummeringsparameters. Nummeringsparameters. Nummeringsparameters. Nummeringsparameters. Nummeringsparameters. Nummeringsparameters.

Als we deze gegevens voor alle lijnen hebben ingevuld dan kunnen we onze test starten.



XXXV


Wij hebben de test gedurende een half uurtje laten lopen met een conversatietijd van telkens enkele minuten. Na de test kregen we volgend rapport. ORIG CHAN ATTMPT

ORIG TERM COMPL ATTMPT

TERM COMPL

NO START

NO NO CALLED TERM ALERT CONFRM BUSY ATTMPT

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

4 3 3 2 4 3 0 0 7 7 0 0 0 0 0 0

3 3 3 2 3 3 0 0 7 7 0 0 0 0 0 0

3 4 2 3 3 4 0 0 7 7 0 0 0 0 0 0

3 3 2 3 3 3 0 0 7 7 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

3 4 2 3 3 4 0 0 7 7 0 0 0 0 0 0

TOTL

33

31

66

31

0

0

1

0

66

Dit wil zeggen dat alle gesprekken correct zijn afgehandeld, met uitzondering van 1 gesprek. Dit was in ons geval vrij goed, want tijdens onze test waren we continue aan het wisselene tussen QPSK en 16QAM in het upstream kanaal.




XXXVI

Bijlage I : Gebruik van sniffer tools Onlangs werd er twee DOCSIS-tracers aangekocht. Met deze toestellen kunnen we sniffen op het RF netwerk. De trace die werd genomen kunnen we vervolgens analyseren met bijvoorbeeld Ethereal. Zo kunnen we dikwijls de oorzaak van een probleem achterhalen en tot een oplossing komen. Zo’n traces zijn natuurlijk ook zeer handig om een probleemanalyse te staven. In deze bijlage zal u vernemen hoe we te werk gingen om deze gegevens te interpreteren en te analyseren.

1. Aansluiten Om te analyseren moet de downstream en de upstream afzonderlijk worden aangesloten. In het labo of in het kopstation is dit geen probleem omdat beide paden daar gescheiden zijn. Bij nieuwe problemen is het echter dikwijls noodzakelijk om naar de klant te trekken met de tracer om er een grondige analyse te doen van het probleem. Met deze gegevens kan men nadien trachten om het probleem te reproduceren in het labo. Bij de klant komt er slechts 1 coax kabel toe, waarover zowel up- als downstream worden gestuurd. We moeten dan ook gebruik maken van splitters om up- en downstream van elkaar te scheiden alvorens we het signaal aanbieden aan de tracer. Volgende tekening zal duidelijk maken hoe de analyser moet worden aangesloten in dit geval.

Figuur 40: opstelling met DOCSIS-tracers




XXXVII

2. Maken van een trace 2.1 Syncen van de tracer

De tracer moet kunnen locken op de kanalen die worden gebruikt door de modem waarvan je gegevens wil sniffen. Locken op de downstream gaat behoorlijk snel. Je configureert de juiste downstream frequentie en je zal zien dat de tracer enkele seconden later op dit kanaal locked. Is dit niet zo dan wil dit meestal zeggen dat de signaal levels die de tracer ontvangt niet in orde zijn. De tracer is in staat om zich te locken op signalen met een amplitude van -5dBmV tot +10dBmV. Meestal zijn we dan ook genoodzaakt om verzwakking te gebruiken in het pad naar de tracer, maar alles hangt hierbij af van de plaats in het netwerk. Als de tracer gelocked is op het downstream kanaal wordt het constellatie diagram weergegeven. Hierin krijg je ook een beeld van de signaal/ruis verhouding. Als de punten te dicht bij elkaar liggen zitten we met een ernstig netwerk probleem.

Figuur 41: DOCSIS tracer, constellatie diagram

Vervolgens moeten we trachten ons upstream kanaal te locken. Omdat het upstream kanaal uit minislots bestaat die verdeelt worden onder de modems is het een pak moeilijker om op de upstream te locken. Hoe gaan we te werk? We beginnen met het configureren van het upstream kanaal. Het upstream kanaal stemt overeen met het poortnummer op de CMTS. Let op: de poortnummering van de CMTS loopt van 0 tot en met 7. Op de tracer stemmen deze overeen met kanaalnummers van 1 tot en met 8. Steven Vlemincx & Bert Dauwe Groep-T Graduaat Telecommunicatietechnieken


XXXVIII


Daarna moeten we zien dat de automatic gain control correct wordt ingesteld. De tracer zal de verschillende AGC’s uitproberen tot hij een geschikte bekomt. De snelste manier is een gesprek op te zetten of een file transfer te starten . Wanneer de tracer dan wordt ingesteld op de optie “AGC high traffic” dan ziet hij veel pakketten passeren en kan hij snel locken. Wanneer de beste AGC waarde bekomen is, zal de melding “Tracking” in het groen verschijnen. Je kan nu best overschakelen naar AGC Manual zodat de AGC waarde wordt vastgehouden en de tracer gelocked kan blijven. Vervolgens klik je op “Start”. De tracer gaat zich nu kalibreren. Als ook deze stap correct doorlopen werd, zal ook hier de melding “Locked” verschijnen en ben je in principe klaar om een trace te starten.

Figuur 42: DOCSIS tracer, upstream constellatie diagram, QPSK

We zien nu dat nu ook het upstream constellatie diagram wordt getoond. Wanneer er geen data wordt verstuurd, dan zien we dat de modem in QPSK zijn ranging behoudt. Maar van zou gauw er data wordt verstuurd, schakelt de modem over naar 16QAM.



XXXIX


Figuur 43: DOCSIS tracer, upstream constellatie diagram, 16QAM




XL

2.2 Instellen van filters Onze tracer kan live filteren. Zoals we in het hoofdstuk capaciteitsplanning hebben gelezen is dit ook nodig. Anders zouden we de data van alle modems op de node capturen. Weliswaar kunnen we deze data niet lezen omdat we alleen op onze testmodem BPI hebben uitgeschakeld. Van de andere modems is de data versleuteld en dus onleesbaar. Maar dit neemt niet weg dat deze gegevens onze capture file ongelooflijk groot maken en dus moeilijk te verwerken maken. Hieronder zien u bijvoorbeeld een filter waarbij alleen de payload van de MTA met CM MAC adres 0000.cab3.b52c en het MTA MAC adres 0000.cab3.b52d wordt opgeslagen in onze file.

Figuur 44: DOCSIS tracer, filterinstellingen

In upstream hoeven we in ons geval enkel te filteren op pakkettype omdat we door de manier van aansluiten enkel upstream verkeer van onze modem zien passeren. Indien nodig kunnen we voor upstream, op dezelfde manier als in downstream, een filter zetten op onze MAC adressen. Als we van plan zijn om het gesprek terug te reconstrueren, dan hebben we enkel de payload nodig. We stellen in dit geval dan ook best onze filters in zoals hierboven getoond. Enkel de payload van onze modem wordt dan gecaptured.



XLI


2.3 Maken van een trace Waneer onze sniffer gelocked is op het downstream en upstream kanaal en we hebben de filters gezet zoals we dit wensen, dan zijn we klaar om een trace te starten. Vooraleer op start te drukken moet je een filenaam kiezen waar de tracer de gegevens mag wegschrijven. Let op: we hebben reeds gemerkt dat de tracer de gegevens niet correct wegschrijft als de file reeds bestaat. Je kan ook een maximum tijd of maximum filegrootte instellen, maar dit is optioneel. Nadat we op “Start” hebben gedrukt zullen we zien dat de teller rechts in het scherm beginnen op te lopen.

Figuur 45: DOCSIS tracer, maken van een trace

Om onze trace te stoppen drukken we op de STOP knop. Nu is onze capture file klaar om te verwerken. Zoals reeds werd aangehaald, is het raadzaam om onze capture file die een DAT formaat heeft om te vormen naar een .pcap formaat. Hoe we hiervoor te werk gaan, leest u verder.



XLII


2.4 Omvormen van de trace naar pcap-file Tijdens het sniffen, slaat de DOCSIS tracer alle gegevens op in de DAT-file die je hebt ingesteld. Dit bestandsformaat is niet leesbaar voor Ethereal. Daarom moeten we de DAT-file omvormen naar een PCAP-file die wel leesbaar is voor Ethereal. Hiervoor starten we programma ST261Viewer op. Dit programma werd samen met de tracer geleverd en kan worden geïnstalleerd op eender welke PC.

Het volgende scherm wordt nu geopend:

Figuur 46: ST261Viewer

We openen nu de DAT-file via File -> open We zien dat er dan een scherm wordt getoond waarin de vooruitgang van dit proces wordt weergegeven. Bij grote fileformaten kan dit makkelijk een uur in beslag nemen. Daarom is het dus nodig om filters te definiëren op de tracer



XLIII


We krijgen nu een overzicht van de pakketten die we hebben gesnift. We kunnen de pakketten in het parsed data scherm bekijken, maar dit is niet zo handig. Daarom bewaren we de file als PCAP-file (save -> libpcap file).

Figuur 47: ST261Viewer, PCAP file

De file is nu klaar voor analyse in Ethereal.

3. Ethereal Ethereal is freeware met veel mogelijkheden. Je hebt versies voor verschillende platformen. Daarom maken we gebruik van Ethereal. Want elke fabrikant, medewerker, enzovoort, in staat om het programma te installeren en te gebruiken.

3.1 Instellen Standaard staat Ethereal ingesteld om ethernet frames te analyseren. De pakketten van de DOCSIS tracer zijn DOCSIS pakketten. Om deze te analyseren moeten we dan ook Ethereal naar DOCSIS frames overschakelen. We doen dit als volgt: In het menu EDIT, selecteren we preferences.



XLIV


Figuur 48: Ethereal, voorkeuren

Onderstaand scherm opent zich dan. Hierin selecteren we “Protocols”.

Figuur 49: Ethereal, Protocols

Je kan nu de eigenschappen per protocol instellen. We scrollen naar beneden en klikken op “Frame”. Je zal dan zien dat je het onderstaande bekomt. Nadat je DOCSIS hebt aangevinkt, worden de frames geanalyseerd als DOCSIS frames.



XLV


Figuur 50: Ethereal, DOCSIS frames

Nu zijn we klaar om een analyse te doen van onze trace.

3.2 Analyse Nu onze frames correct worden getoond kunnen we beginnen met de analyse. Deze analyse is natuurlijk afhankelijk van het probleem waarnaar je zoekt. - Is er sprake van jitter? - Worden er continu pakketten gestuurd in beide richtingen? - Is de call-setup correct? - Is er sprake van pakket loss Bij het analyseren van de data is het makkelijk om filters in te stellen in Ethereal zodat je enkel de data krijgt die je nodig hebt. Zo bekom je een duidelijker beeld. Je kan makkelijk een filter opstellen via de knop “EXPRESSION”.



XLVI


Figuur 51: Ethereal, filter

Als de opgestelde filter geldig is, wordt het vak groen gekleurd, anders is het vak rood gekleurd. We kunnen ook verschillende filters koppelen, door gebruik te maken van AND en OR functies. Een snelle manier om een filter te maken is een pakket te selecteren en via de rechtermuisknop “apply as filter” te selecteren. In geval van VoIP problemen kan het handig zijn om het gesprek terug te reconstrueren zodat het mogelijk is dit terug af te spelen. Daarna kan men makkelijk horen of het probleem al dan niet in de trace aanwezig is. Door enkele van deze testen te doen volgens verschillende call-scenario’s (MTA-MTA , MTAPSTN, …) kunnen we trachten te achterhalen waar het probleem wordt veroorzaakt. Behalve in geval van pakket loss kunnen we stellen, dat er in het netwerk niets aan het gesprek kan worden veranderd. Ons gesprek wordt namelijk digitaal getransporteerd over DOCSIS. De meeste problemen worden dus aan de endpoints veroorzaakt. Als dus het probleem reeds in onze trace aanwezig is, dan mogen we stellen dat de oorzaak bij de zender zit. Hoe we onze DOCSIS pakketten terug omvormen naar een gesprek leest u hieronder.

3.3 Reconstrueren van de RTP-stream Zorg ervoor via filtering op de DOCSIS tracer of in Ethereal dat je enkel de payload pakketten ziet. Je ziet dat alle pakketten dan worden getoond als UDP pakketten. We moeten aan Ethereal aangeven dat hij deze pakketten moet decoderen als RTP pakketten. Dit doen we als volgt: In het analyse menu klikken we op “decode as”.



XLVII


Figuur 52: Ethereal, analyse menu

Volgend scherm wordt dan geopend. Hier selecteren we dan het protocol waaruit onze payload bestaat. In ons geval is dit dus RTP.

Figuur 53: Ethereal, protocol selecteren

Nu worden onze pakketten getoond als RTP pakketten en wordt ook de codec weergegeven. We selecteren 1 pakket en letten hierbij op de IP-adressen zodat we weten of we de upstream of de downstream aan het bewerken zijn. Vervolgens gaan we via “statistics” naar RTP en selecteren hier “stream analysis”.



XLVIII


Figuur 54: Ethereal, Stream analysis

Na enige processing wordt dan onderstaand scherm getoond. We controleren nog eens snel de delay en de jitter hier. Ideaal zou de delay tussen 2 pakketten steeds moeten gelijk zijn aan de packetisation time, in ons geval dus 20msec.

Figuur 55: Ethereal, Delay en Jitter

Je kan nu kiezen tussen 2 handige opties: Steven Vlemincx & Bert Dauwe Groep-T Graduaat Telecommunicatietechnieken


XLIX


- Save payload: om het gesprek terug te beluisteren - Save as CSV: om bijvoorbeeld een uitgebreide analyse te doen met een script of in Excel Als we de optie save payload kiezen, wordt onderstaand scherm getoond.

Figuur 56: Ethereal, Payload

We selecteren “forward” en geven de directory in waar we onze gedecodeerde file wensen te plaatsen. Vervolgens geven kiezen we de filenaam en geven best de richting mee (Upstream of Downstream). Wanneer we als extensie .wav geven, dan kunnen we de file afspelen in mediaplayer en dergelijke. Wij kiezen echter voor Goldwave omdat we hier een beeld krijgen van de amplitudes en frequenties.

4. Goldwave In Goldwave hebben we een aantal mogelijkheden die heel interessant zijn bij onze foutanalyse. We kunnen hiermee namelijk amplitudes meten en het frequentiespectrum bekijken. In Ethereal hebben we upstream en downstream van elkaar gescheiden. Het is handig om deze twee files samen te openen in Goldwave. Je zal zien dat ze dan boven elkaar komen te staan. Je ziet dan dikwijls reeds het signaalverloop, waar een bepaald probleem zich heeft voorgedaan.



L


Figuur 57: Goldwave, afspelen up- en downstream

Je kan nu up– of downstream één voor één afspelen. Zo kan je het probleem misschien wel horen, maar bekom je nog geen extra informatie. Via het tools-menu kan je een extra venster openen, namelijk Control. In dit venster kan je mooi het signaalverloop en het frequentiespectrum bekijken.

Figuur 58: Goldwave, Tool menu

Selecteer nu één van de twee files die je hebt geopend met Goldwave en start de weergave in het Control venster. Je kan nu de signalen meten en bekijken. Handig is om zowel de bars als het spectrum weer te geven. Met de bars kan je makkelijker een amplitude aflezen dan in het spectrum, maar in het spectrum heb je dan weer een correct beeld van de frequenties. Via de rechtermuisknop in het control venster, kan je deze functies aanpassen.




LI

Figuur 59: Goldwave, Bars en Spectrum

Je zal merken dat het niet altijd even makkelijk is om het verschil in amplitude tussen 2 stromen te meten. Daarom is het handig dat een frequentiegenerator wordt gebruikt in plaats van spraak. Dit kan je natuurlijk niet voor elk probleem doen, want sommige problemen doen zich enkel voor bij spraak.



LII


Bijlage J : Call feature switch Hieronder krijgt u een beeld van de MIB boomstructuur waarin de feature switch zich bevindt.

Figuur 60: Call feature switch in de MIB boomstructuur

Meer info aangaande de feature switch kan je ook vinden in volgend uittreksel uit de software guide van de fabrikant. Callp Feature Switch activates certain functionalityand compliancies in callp. WARNING: Changes can result into loss of communication to the Callagent or loss of the voicepath. Please read documentation before changing! The Callp Feature Switch is a bitmap which enables/disables NCS/Callp functionality as follows: (Octet String) Feature Switch Value Description -----------------------------00.00.00.01 enable the transmission of piggy-backed NCS messages 00.00.00.02 enable lockstep mode 00.00.00.04 only return line package in AUEP response 00.00.00.08 toggle MGCP version (0=0.1 / 1=1.0) 00.00.00.10 enforce usage of mandatory SDP parameters 00.00.00.20 DQOS parameters set to (0) Customer friendly (1) PacketCable compliant 00.00.00.40 incl commentary text in response messages 00.00.00.80 disable FQDN validation in received MGCP msg 00.00.01.00 do not put linecard in standby mode during ringing 00.00.02.00 enable trans of wildcarded NCS message 00.00.04.00 allow known invalid NCS messages 00.00.08.00 use hard-coded digit map 00.00.10.00 use Nuera RFC-2833 Messages 00.00.20.00 1 = DQoS On 00.00.40.00 0 = Full PacketCable DQOS 1 = DSX DQOS 00.00.80.00 Allow MTA to send provisional responses Steven Vlemincx & Bert Dauwe Groep-T Graduaat Telecommunicatietechnieken


LIII


00.01.00.00 00.02.00.00 00.04.00.00

1 0 1 0 1

= = = = =

Payload Header Suppression (PHS) ON CA supports multiple connections CA only supports single connection 800usec tolerated grant jitter for DQOS 2msec (needed for Cisco CMTS 8/2002)

Default values are as follows: GW/ Call Server *************** AudioCodes Cedar Point Commatch Gallery General Bandwidth PacketCable SN04 SN06 Syndeo

CALLP Feature SWITCH ******************** 12.75.49 00.24.7B 12.65.48 00.65.59 12.65.59 00.A2.7B 12.64.69 10.66.79 00.66.79

Comments ******** DSX DQOS Full DQOS DSX DQOS Full DQOS DSX DQOS Full DQOS DSX DQOS DSX DQOS DSX DQOS



LIV


Bijlage K: Een kort algemeen overzicht van VoIP De VoIP oplossing waar wij het al de hele tijd over hebben is een oplossing die enkel implementeerbaar is op een backbone van kabelnetwerken. Het gaat hier namelijk over een typische implementatie voor EuroDOCSIS en Euro-PacketCable. De term VoIP wordt vandaag de dag echter zo vaak gebruikt dat een korte bijlage over de verschillende, vaak meer schaalbare, vormen van VoIP hier op zijn plaats is.

1. Verschillende vormen van VoIP 1.1 Computer to Computer VoIP

Deze is beter bekend als Peer to Peer (P2P) VoIP. Hierbij wordt gebruik gemaakt van software (een softphone), computer, luidsprekerboxjes en microfoon. De onderlinge connectiviteit van softphones is beperkt. Voorbeelden zijn Earthlink, Free World Dialup en MSN Messenger. Dit zijn momenteel de belangrijkste aanbieders van softphones.De meest bekendste is echter Skype, en deze is momenteel ook de populairste. P2P VoIP wordt echter meer gezien als een geavanceerde vorm van webchatten in plaats van een functionele vervanging van traditionele telefoondiensten, omdat vaak geen verbinding kan worden gemaakt met het PSTN-netwerk. Een uitzondering hierop is Skype, dat Skype Out aanbiedt, waarbij tegen een kleine Prepaid vergoeding naar het PSTN-netwerk gebeld kan worden

1.2 Internet Telephony Service Provider (ITSP) Deze vorm heeft als kenmerk dat de aanbieders geen eigen netwerk hebben zoals Telenet, maar gebruik maken van de breedbandverbindingen die hun klanten reeds bij een netwerkprovider hebben aangeschaft. Wil VoIP voor de gemiddelde gebruiker echt functioneel zijn, dan dient VoIP ook in staat te zijn om een verbinding te maken tussen de IP- en PSTN-netwerken. De ITSP’s hebben zich dit gerealiseerd en bieden allemaal de mogelijkheid aan om naar het PSTN-netwerk te bellen, en om van het PSTN netwerk gebeld te worden. De lijst met bedrijven die deze dienst aanbieden verandert iedere dag. De grootste is Vonage. Een volledige lijst met aanbieders vindt je op http://www.iptelephony.org/GIP/providers/ . Prijzen van een abonnement beginnen bij circa $ 14,95 per maand, vaak met onbeperkte belminuten. TU

UT

1.2.1 VoIP die wordt aangeboden door de telecombedrijven Deze bedrijven, waaronder Telenet, beschikken over de netwerkinfrastructuur tot bij consumenten en bedrijven (last mile access). De precieze implemetatie en gebruikte technologie is afhankelijk van de manier waarop de klant verbonden is met de telecomoperator. Enkele voorbeelden van verschillende last mile media zijn kabel, koper, radio of glasvezel. Overigens, ook zonder een VoIP-product te kopen maken consumenten en bedrijven gebruik van VoIP: veel telecombedrijven laten inmiddels vanwege kostenoverwegingen een belangrijk deel van het traditionele PSTN-verkeer tussen de grote telefooncentrales over VoIP-backbones lopen. De consument merkt hier niets van omdat de route van telefooncentrale naar huisaansluiting een traditioneel PSTN-netwerk is.




LV

Ook wat het gebruiksgemak betreft doen VoIP-aanbieders hun uiterste best om de overstap naar VoIP voor de consument zo gemakkelijk mogelijk te maken. Zo hebben Cisco en Netgear wireless routers en modems op de markt gebracht waarmee een standaard-PSTN-telefoon gebruikt kan worden voor VoIP, en die met een abonnement op Vonage of een andere ITSP worden verkocht. Ook bieden telecombedrijven en kabelbedrijven vaak VoIP aan zonder expliciet naar de technologie te verwijzen. De consument ervaart deze diensten als normale telefonie, met veel extra functies en lage gesprekskosten.

1.2.2 VoIP in de bedrijvenmarkt Een belangrijke bron van de groei van VoIP komt voor rekening van de grote bedrijven. Doordat deze vaak vestigingen hebben op meerdere locaties die via private datalijnen met elkaar zijn verbonden, speelden alle technische problemen die verbonden zijn aan VoIP via het open internet geen enkele rol in een bedrijfsomgeving. Een IP/PSTN-Gateway volstaat daarbij voor een verbinding met het PSTN-netwerk. Inmiddels lijkt VoIP helemaal doorgebroken te zijn in de bedrijfsomgeving van grote bedrijven. Ook reductie in de kosten van de infrastructuur speelt een rol bij investeringsbeslissingen. Bijna ieder kantoor heeft twee fysieke netwerken: een IP-datanetwerk een telefoonnetwerk, ieder met hun eigen technologie, connectoren, poorten et cetera. Door ook spraak via het datanetwerk te laten lopen, kunnen bedrijven de infrastructuurkosten sterk beperken. Tenslotte is WAN VoIP een aantrekkelijke optie voor thuiswerkers. Doordat breedband-internet inmiddels in vele huishoudens is doorgedrongen kan een bedrijf met een VPN (Virtual Private Network) de computer van de thuiswerker direct op het bedrijfsnetwerk aansluiten, inclusief een VoIP-toepassing, zodat telefoontjes naar het kantoor direct naar de thuiswerker worden geleid.

1.2.3 VoIP over WiFi Sinds kort zijn dual mode mobiele telefoons op de markt, die zowel gebruik kunnen maken van VoIP via 802.11b/g wireless (WiFi) als het normale mobiele telefoonnetwerk. Hiermee wordt Voice over WiFi (ook wel ViFi genoemd) mogelijk. Het mobiele telefoonnetwerk en WiFi vullen elkaar dan aan. Op locaties waar WiFi aanwezig is (in huis, in een kantooromgeving) maakt de telefoon gebruik van het snellere WiFi netwerk voor zowel spraak- als datatoepassingen. Waar geen WiFi-netwerk aanwezig is, wordt gebruik gemaakt van het mobiele telefonienetwerk. Op de lange termijn zouden Wireless Internet Service Providers (WISP’s), maar ook de mobiele telecomoperators, met behulp van WiMax en Ultra Wide Band een Triple Play-speler kunnen worden. Eind juni 2004 ging in Vlaanderen de vzw I-City van start met een kapitaal van 3,6 miljoen euro. 1,8 miljoen euro komt van de Vlaamse overheid, de rest van zes privé-partners: Concentra Media, Fujitsu Siemens Computers, Microsoft, Siemens en Telenet. Het multimediaplatform waarop de toepassingen geënt worden, kost zelf 3,6 miljoen euro en voor het onderhoud is jaarlijks nog 2 miljoen euro nodig. Per stad die zich aansluit, wordt nog eens 300.000 euro aangerekend. Hasselt, Leuven en Kortrijk stapten reeds in het project en op 15 april 2005 werden in Hasselt de eerste 100 alfa test gebruikers aan de pers voorgesteld.




LVI

De technologische uitdaging is echter om te zorgen voor een goede roaming tussen WiFiaccesspunten onderling en tussen de WiFi en mobiele telefonienetwerken, zodat voor een mobiele gebruiker de verbinding behouden blijft wanneer op een ander netwerk wordt overgeschakeld. Ook het grotere energieverbruik van WiFi telefonie vergeleken met mobiele telefonie (WiFi vereist een always on verbinding) blijft een punt van zorg.

1.3 VoIP-technologie Bij VoIP wordt de informatie in digitale vorm in discrete IP-pakketten over een IP-netwerk getransporteerd, dat ook voor andere toepassingen geschikt is, dit in tegenstelling tot een specifiek voor spraak ingericht netwerk zoals het PSTN netwerk.

1.3.1 VoIP telefoon De VoIP-telefoon kan een softphone, een speciale IP-telefoon of een normale PSTN-telefoon zijn. Een IP-telefoon heeft het uiterlijk van een normale telefoon, maar beschikt over een ethernetaansluiting en maakt direct verbinding met een router of breedbandmodem. In het geval van een PSTN-telefoon wordt een ATA (Analog Terminal Adapter) gebruikt. Zowel de IP-telefoon als de ATA, end points in VoIP-jargon, beschikken over de hardware en software die nodig zijn om een VoIP-gesprek te voeren, zoals de geluidscodec, het compressie-algoritme en een packetizer, die de data omzet in IP-pakketjes. Deze bestaan uit een header met daarin transportinformatie (afzender, bestemming, volgorde, foutcorrectie) en de payload, oftewel een gedeelte van de informatie die getransporteerd moet worden. Wanneer gebeld wordt van een IP-netwerk naar het PSTN-netwerk of vice versa, wordt de verbinding gemaakt via IP/PSTN gateways respectievelijk softswitches.

1.3.2 De Codec Voordat het spraaksignaal verzonden kan worden via IP-netwerken dient het door de zender te worden gedigitaliseerd en gecomprimeerd. Bij aankomst bij de ontvanger moet de digitale informatie weer worden omgezet in een geluidssignaal. Er zijn verschillende standaarden, ofwel codecs, voor het coderen (en decoderen) van VoIP-audio. De ITU (International Telecommunications Union), heeft de belangrijkste hiervan gedefinieerd: G711, G723.1, G726 en G729. Variabelen hierbij zijn de bitrate (variërend van 5,3 tot 40 Kbps), de sampling rate (bemonsteringsfrequentie, over het algemeen 8 kHz) en de lengte van de pakketjes (packet duration, variërend van 10 tot 30 milliseconden). De packet duration (gerelateerd aan de packetgrootte) is een compromis tussen de bandbreedte en de geluidskwaliteit. Kortere pakketjes vereisen meer bandbreedte, maar langere pakketjes leiden tot meer vertragingen en verlies van informatie (packet loss). ATA’s en IP telefoons kunnen met verschillende codecs overweg.

1.3.3 Quality of Service (QoS) De grootste uitdaging voor VoIP-technologie zal liggen in het behalen van dezelfde betrouwbaarheid (QoS, Quality of Service) als het traditionele PSTN-netwerk. In de PSTN-wereld geldt een betrouwbaarheid van 99,999 procent (five nines) als regel, het geen inhoudt dat het netwerk per jaar slechts 5 minuten en 15 seconden niet functioneert. VoIP is momenteel nog niet in staat om dit betrouwbaarheidsniveau te halen, al was het maar omdat breedbandverbindingen in het algemeen geen five nines betrouwbaarheid hebben. Bovendien werkt het PSTN-netwerk in geval van een stroomstoring, en ook het stroomnetwerk Steven Vlemincx & Bert Dauwe Groep-T Graduaat Telecommunicatietechnieken



LVII

haalt geen five nines betrouwbaarheid. De vraag is echter of een verminderde betrouwbaarheid (bijvoorbeeld 99.99 procent) voor ten minste een deel van de consumenten een reëel probleem is wanneer de service aanmerkelijk goedkoper kan worden aangeboden. Een ander aspect van QoS is de kwaliteit van het gesprek. Dit hangt af van: • De duidelijkheid van het signaal, ofwel de mate waarin het oorspronkelijke signaal wordt gereproduceerd bij de ontvanger. Het verlies van IP packets is de oorzaak van vervormingen. • De mate waarin echo optreedt (een reflectie van het signaal aan het eindpunt). • Vertraging van het signaal: latency. Wanneer deze variabel is, treedt bovendien jitter op, hetgeen ook de geluidskwaliteit niet ten goede komt.

1.4 Veiligheidsaspecten van VoIP VoIP is, als IP-applicatie, kwetsbaar voor een grote hoeveelheid veiligheidsproblemen die ook andere IP-applicaties zoals e-mail, websurfing en Instant Messaging treffen. Een eerste voorbeeld is de netwerkveiligheid. IP-netwerken (en dus alle IP-applicaties) kunnen worden afgeluisterd of bekeken door packet sniffers. Gesprekken over een privaat IP-netwerk, zoals dat van Telenet eigenlijk is, zijn beter te beveiligen dan gesprekken die via het publieke internet lopen omdat niet vast te stellen is via welke route de pakketten op de plaats van bestemming komen en wat er tussentijds mee gebeurd is. VoIP is in ieder geval niet meer of minder veilig dan andere IP-applicaties, en ook gesprekken via het PSTNnetwerk kunnen worden afgeluisterd. Gesprekken zijn te beperken tot interne IP-netwerken maar dan gaat uiteraard veel functionaliteit, zoals bellen naar PSTN, verloren. Ook zijn SIP-servers, die een belangrijke rol op zich nemen bij het tot stand brengen en coördineren van VoIP gesprekken, evenals alle internetservers kwetsbaar voor virussen, trojans en Denial of Service (DoS)-aanvallen, waarbij de server uitvalt door een enorme hoeveelheid gelijktijdige verzoeken om informatie.

1.5 VoIP-Spam Vanwege de lage kosten van VoIP communicatie bestaat een groot risico dat gebruikers worden lastiggevallen door ongewenste VoIP-telefoongesprekken, Instant Messaging-berichten en ongewenste (en onjuiste) presence. Bovendien vraagt deze soort van spam meer interactie met de gebruiker: e-mailspam is eenvoudig te deleten. Continue lastig gevallen worden met telefoontjes is veel irritanter. Dit aspect krijgt de laatste tijd zoveel aandacht, dat er inmiddels een term voor is bedacht: SPIT (Spam over Internet Telephony).

1.6 De (nabije) toekomst van VoIP: EoIP Waarschijnlijk zullen hardwareleveranciers de komende jaren een enorme groeimarkt kunnen bedienen omdat de VoIP-infrastructuur aangelegd moet gaan worden. Voor de ITSP’s wordt het mogelijk een heel ander verhaal. Op basis van een vergelijking met andere internetapplicaties zoals e-mail en websurfen zou kunnen worden geconcludeerd dat de winst komt van het transport van de data, van het aanbieden van connectiviteit, en niet zozeer door het aanbieden van de applicatie zelf, zoals dat ook bij webbrowsing of e-mail het geval is.




LVIII

VoIP lijkt daarnaast deel uit te maken van een bredere beweging waarin zowel applicaties (spraak, video, muziek, data) als content (informatie) gebruik gaan maken van generieke IP-netwerken: Everything over IP (EoIP). Deze ontwikkeling zal doorgaan, met naar verwachting verregaande implicaties voor radio, televisie en (met de opkomst van WiFi en WiMax) mobiele telefonienetwerken. Video over IP zal, na VoIP, naar verwachting de volgende grote ontwikkeling zijn in IP-land. Belangrijkste drivers voor deze ontwikkeling zijn een betere compressietechnologie voor videobestanden, toenemende breedbandpenetratie, hogere breedbandsnelheden en lagere kosten voor settopboxen om de TV met breedband te verbinden. Een andere trend is de opkomst van dual-mode handsets en de enorme groei van het aantal hotspots. Telenet bijvoorbeeld heeft momenteel reeds hotspots in NMBS stations, in de voetbalstadions, bij Carestel, bij Q8, bij Lunchgarden,… Deze ontwikkeling zal een belangrijke steun in de rug zijn voor de marktacceptatie van VoIP.



En last but not least wil ik mijn vrouw Ellen bedanken. Zij stimuleerde en motiveerde me gedurende de hele studietijd bij Groep-T

Recommend Documents