Een ISDN telefoonverbinding

1ECHNISCHE UNIVERSITEIT EINDHOVEN FACULTEIT DER ELEKTROTECHNIEK VAKGROEP DIGITALE INFORMATIES YSTEMEN

Een ISDN telefoonverbinding door M.L.l. Rijnders

Verslag van het afstudeerwerk verricht van maart 1993 tot en met oktober 1993. Hoogleraar:

Prof. ir. M.P.J. Stevens

Begeleider:

ir. M.J.M. van Weert

Eindhoven, Nederland

De Faculteit der Elektrotechniek van de Technische Universiteit Eindhoven aanvaardt geen aansprakelijkheid voor de inhoud van stage- en afstudeerverslagen.

Lijst van afkortingen

Lijst van afkortingen:

CCITT:

Comire Consultatif International de TeIegraphique et Telephonique

CODEC:

COder and DECoder

D-phone:

Digital Telephone

DLC:

Data Link Controller

DNIC:

Digital Network Interface Circuit

DSC:

Digital Subscriber Controller

DSP:

Digital Signal Processor

DTMF:

Dual Tone Multi-Frequency

DX:

Digital Time/Space Crosspoint Switch

EOD:

End Of Dma interrupt

ICE:

In-Circuit-Emulator

ISO:

International Standards Organisation

ITU:

International Teleconununications Union

LAN:

Local Area Network

LIU:

Line Interface Unit

MAP:

Main Audio Processor

MPI:

Microprocessor Intelface

MUX:

Multiplexer

NT:

Network Termination

OSI:

Open Systems Interconnection

PBX:

Private Branch eXchange

PC:

Personal Computer

peM:

Pulse Code Modulation

SNIC:

Subscriber Network Interface Circuit

TA:

Tenninal Adapter

TE:

Tenninal Equipment

Samenvatting

Samenvatting De vakgroep Digitale Infonnatiesystemen van de Faculteit der Elektroteehniek van de Technische Universiteit Eindhoven verricht onderzoek aan het Integrated Services Digital Network (ISDN) dat door het CCITT is gedefmieerd. In verband met dit onderzoek werden twee Mitel ISDN Express Cards gekocht en werd een eigen ISDN terminal ontworpen en gebouwd. Op deze systemen is het mogelijk de ISDN protocollen, enkele zijn al gedeeltelijk in de hardware aanwezig, te implementeren. De Mitel kaarten en het ISDN tenninal board kunnen onderling worden verbonden door een vierdraads Srr interface. Het is echter tot nu toe niet mogelijk geweest dit srr interface te gebruiken voor een telefoonverbinding tussen de Mitel kaarten onderling of tussen een Mitel kaart en het ISDN tenninal board. WeI kunnen we bij de Mitel kaarten het U-interface gebruiken voor het opzetten en verbreken van een telefoonverbinding. Verder ontbreekt bij de ISDN software voor het terminal board de Call Control en Resource Management protocollen die zorgen voor het opzetten en verbreken van een telefoonverbinding en voor de selectie van de kanalen. Tevens ontbreekt de uitgebreide protocol monitor die bij de Mitel kaarten wordt gebruikt ter controle van de protocollen en die het zoeken naar fouten vergemakkelijkt. Dit verslag beschrijft de software ontwikkelingen die voor de MITEL kaarten nodig waren om uiteindelijk gebruik te kunnen maken van het Srr interface voor het opzetten en afbreken van een ISDN telefoonverbinding. Verder wordt er beschreven hoe de ISDN software voor het terminal board is gecontroleerd op fouten en verder is uitgebreid met de Call Control en Resource Management protocollen zodat ook het terminal board nu de mogelijkheid heeft om een telefoonverbinding via het Srr interface op te zetten. Ook is de Monitoring Dispatcher van de MITEL kaarten met behulp van geemuleerde TURBO-C functies op het terminal board geiinplementeerd Het is nu door deze nieuwe verbeteringen en uitbreidingen van de ISDN software op de beide systemen (MITEL kaarten en het ISDN terminal board) weI mogelijk geworden om een ISDN telefoonverbinding te maken tussen de MITEL kaarten onderling of tussen een MITEL kaart (met een nieuwe MITEL chip set voor de D-Phone en het SNIC) en het ISDN terminal board.

n

Inhoudsopgave

Inhondsopgave

1. Inleiding

-

1

2. Integrated Services Digital Network (ISDN) ..••...•.••.•..•.••.••..•.-•• 4 2.1 2.2 2.3

2.4

Standaarden Diensten ISDN architectuur

5 6

2.3.1

User-Network interface

6

2.3.2

Transmissie structuren

8

Samenvatting

4

10

3. ISDN hard· en software··············································.•.••.•.• 11 3.1

3.2

3.3 3.4

De Mitel ISDN Express Card

11

3.1.1

De Digital Telephone (D-Phone)

12

3.1.2

De Digital Time/Space Crosspoint Switch (OX)

14

3.1.3

De Digital Network Interface Circuit (ONIC)

15

3.1.4

De Subscriber Network Interface Circuit (SNIC)

16

Het ISDN terminal board

19

3.2.1

De Programmeble Interrupt Controller (PIC)

20

3.2.2

De Digital Subscriber Controller (DSC)

21

3.2.3

De Integrated Data Protocol Controller (IOPC)

22

Het besturingssysteem Samenvatting

23

26

4. Software ontwikkeling t.b.v. het Mitel SiT interface ··················-27 4.1 4.2

De protocol timers De low-level drivers

28 29

iii

Inhoudsopgave

4.3

4.4

Een telefoonverbinding via de SNIC

33

4.3.1

33

De laag 3 call states

4.3.2 Het opzetten en afbreken van een telefoonverbinding

37

Samenvatting

39

5. Software debugging van het ISDN terminal board ••.••••.••••••••••••• 41 5.1 5.2 5.3 5.4

Verschillen tossen de Intel C en Turbo C++ compiler Conversiefouten Fouten in de low·level device drivers Samenvatting

42 44 49

53

6. Software ontwikkeling Lb. v. het ISDN terminal board •.•..•...•...•.. 54 6.1 6.2 6.3

Call Control en Resource Management De Window·Protocol·Monitor voor een ANSI terminal Samenvatting

54 58

61

7. Conclusies en aanbevelingen •...•..•...•...•••..•..•.•..•.•.••••.••.•..•••.•. 62 Literatuurlijst .•....•.••••••..•••..•••••••..•.•..•.•..••.••.•..••.•.••.••...••.•.•.•• 65 Bijlage 1: Het literatuuronderzoek

68

Bijlage 2: Extra fundies van de Monitoring Dispatcher voor het terminal board ••.•...••.•••..••••...•••.•.•..•••..•.•.•....•...•••..•• 80 Bijlage 3: Het gebruik van Turbo C++, Intel C en ICE ...••••••...•.•.••. 81 Bijlage 4: Programma functies •...•.•.••.••••..••.•.•.•..•..••..••••.••..•.••••• 85

iv

Inleiding

1.

Inleiding

De snelle vooruitgang in de computer en communicatie technologie resulteerde in een vergaande integratie van beide gebieden. Hierdoor worden tegenwoordig voor de transmissie van data, spraak en beeld dezelfde digitale technieken gebruikt. Deze ontwikkeling en de vraag naar een efficienter en krachtiger communicatienetwerk hebben geleid tot de ontwikkeling van een geYntegreerd systeem dat alle soorten data lean verwerken, genaamd Integrated Services Digital Network (ISDN). Het systeem is bedoeld ter

vervanging

van de

bestaande

data-,

telefoon-,

radio-

en

uiteindeJijk

de

televisienetwerken. Voor deze laatste groep zijn de ISDN specificaties echter te behoudend, zodat nu al gewerkt wordt aan de definitie van het Broadband ISDN. Op deze laatste ontwikkeling zullen we echter niet verder ingaan. De defmities van het ISDN, de hardware en de communicatieprotocollen, zijn vastgelegd door het Comite Consultatif International de TeIegraphique et Telephonique (CCITf). In de aanbevelingen van deze instantie zijn ook een groot aantal diensten vastgelegd die via een digitale ISDN aansluiting kunnen worden geleverd. De belangrijkste aansluiting die gedefinieerd is, wordt de 'basic access' genoemd en bestaat

uit twee B-kanalen, beide 64 Kbit/s, en een D-kanaal van 16 Kbit/s. De B-kanalen kunnen worden gebruikt voor digitale data, PCM-gecodeerde digitale spraak, of verscheidene kanalen met een lage snelheid, een fractie van de 64 Kbit/s, data en gecodeerde spraak. Het D-kanaal dient voor de 'Common-Channel-Signaling (CCS)' en 'packet switching' tijdens pauzes in de signalering. We kunnen dus met deze basis aansluiting gebruik maken van alle ISDN diensten waaronder de aansluiting van een ISDN telefoon, de belangrijkste dienst die in dit verslag geb~ gaat worden. [1] De vakgroep Digitale Informatiesystemen van de Faculteit der Elektrotechniek van de Technische Universiteit Eindhoven verricht ook onderzoek aan ISDN. In verband met dit onderzoek zijn twee Mitel ISDN Express Cards gekocht en werd een eigen ISDN terminal ontworpen en gebouwd [3]. Op deze systemen is het mogelijk de ISDN protocollen, enkele zijn al gedeeltelijk in de hardware aanwezig, te implementeren [4] zodat ervaring kon worden opgedaan met enerzijds het ISDN zelf, en anderzijds met de ontwikkeling van grotere software implementaties volgens het 'Open Systems Interconnection (OS I)' model van het International Standards Organisation (ISO).

1

Inleiding

De Mitel kaarten en het ISDN tenninal board kunnen onderling worden verbonden door een vierdraads srr interface. Het is echter tot nu toe niet mogelijk geweest dit srr interface te gebruiken voor een verbinding tussen de Mitel kaarten onderling of tussen een Mitel kaart en het tenninal board. In het eerste geval, dus bij een verbinding tussen de MITEL kaarten, ging door het telkens

weer optredende synchronisatieverlies [8] data verloren. De cornrnunicatieprotocollen moesten daarom vele malen hetzelfde datapakket herhalen totdat uiteindelijk het datapakket foutloos werd ontvangen door de andere MITEL kaart. Een datapakket kwam daardoor pas na minuten op de plaats van bestemming aan. WeI kunnen we bij de Mitel kaarten het V-interface gebruiken voor het opzetten en verbreken

van een

telefoonverbinding zoals door I.R.H. Claessens [10] wordt beschreven. Het gebruikte Vinterface, een tweedraads verbinding, is echter Diet op het tenninal board aanwezig. In het tweede geval bleek dat een spraakverbinding tussen een MITEL kaart en het

tenninal board van een zeer slechte kwaliteit was. Dit werd bij het implementeren en testen van het S-interface en het telefoon-interface van het tenninal board [7] met behulp van speciale testprogramma's ontdekt. Een ander probleem bij het terminal board is het ontbreken van de Call Control en Resource Management software die zorgen voor de selectie van de kanalen en voor het opzetten en verbreken van een telefoonverbinding. Tevens ontbreekt de uitgebreide protocol monitor die bij de Mitel kaarten wordt gebruikt ter controle van de protocollen en het zoeken naar fouten vergemakkelijkt Verder moet de ISDN software nog gecontroleerd worden op fouten. De afstudeeropdracht om het srr interface te gebruiken voor het opzetten en verbreken van een telefoonverbinding tussen de Mitel kaarten onderling, en tussen een Mitel kaart en het ISDN terminal board omvat dus een groot aantal onderwerpen, op hard- en software gebied, die aangepakt moeten worden om de bovengenoemde problemen te kunnen oplossen. Deze onderwerpen zijn in de volgende hoofdstukken terug te vinden. In hoofdstuk 2 worden eerst een aantal basisbegrippen en standaarden voor ISDN

besproken. Hoofdstuk 3 behandelt de twee verschillende ISDN hardware configuraties die aanwezig zijn, de Mitel ISDN Express Card en het ISDN tenninal board. In hoofdstuk 4 komt de software voor het Mitel Srr interface ter sprake waarna in hoofdstuk 5 de software debugging voIgt van het terminal board. De implemematie van de Call Control en Resource Management software, en de verbeterde protocol monitor komen in hoofdstuk 6

2

Inleiding

aan de beurt. Als afsluiting volgen de conc1usies en aanbevelingen. In de bijlagen kunnen nog enkele belangrijke feiten worden teruggevonden.

3

Integrated Services Digital Network (ISDN)

2.


Door het groeiende aantal vonnen van communicatie en de snelle vooruitgang in deze techniek, is de belangrijkste infrastructuur, het telefoonsysteem, minder geschikt geworden. De vraag naar een efficienter en krachtiger communicatienetwerk heeft geleid tot de ontwikkeling van een gei."ntegreerd en volledig digitaal systeem dat alle soorten data kan verwerken, genaamd Integrated Services Digital Network (ISDN). Voor de standaardisatie van ISDN zorgt het Comire Consultatif International de Telegraphique

et

(CCITT),

Telephonique

een

comire

van

de

International

Telecommunications Union (ITU). In de volgende paragraaf voIgt een klein overzicht van deze standaarden. In die standaarden zijn ook een groot aantal diensten vastgelegd die via een digitale ISDN aansluiting kunnen worden geleverd. Een samenvatting van de gedefinieerde diensten voIgt in paragraaf 2.2. In de laatste paragraaf bespreken we het interface tussen een ISDN gebruiker en het ISDN netwerk.

2.1

Standaarden

Bet gebruik van standaarden is'bij de introductie van een complex systeem zoals ISDN van groot belang. De compatibiliteit met het netwerk is gegarandeerd zolang men zich aan deze standaarden houdt. In 1984 worden de eerste aanbevelingen, of standaarden, door de CCITT uitgegeven, de zogenoemde 'I-series of recommendations' in de Red Books [2]. In 1988 voIgt een completere set aanbevelingen in de Blue Books. De aanbevelingen zijn volgens de structuur van figuur 2.1 ingedeeld en vormen samen

met

de

Q-

en

X-series

Figuur 2.1: Structuur I-serie.

Recommendations de basis van ISDN.

4


De protocollen die zorgen voor de communicatie tussen de gebruikers en tussen een gebruiker en bet netwerk, zijn zoveel mogelijk gemodelleerd naar bet OSI referentiemodel, een standaard van bet ISO. De relatie tussen de ISDN protocollen en het OSI-model zijn

in het onderstaande figuur terug te vinden en vonnen bet User-Network interface. Ben uitvoerige beschrijving van het OSI-model is terug te vinden in [1]. We zien dat het Layer 1 protocol zorgt voor het multiplexen van het D-kanaal en de Bkanalen. Voor het gebruik van het B-kanaal zijn bij een circuit-geschakelde verbinding (b. v. een spraakverbinding) verder geen protocollen vastgelegd, ieder gewenst protocol

kan voor de bogere lagen gekozen worden. Voor de signalering over het D-kanaal wordt echter op laag 2 nog het LAPD protocol en op laag 3 het Call Control protocol gebruikt. De lagen 4 tim 7 worden verder gebruikt voor de 'End-to-end user signaling'.

_.

Layer': AH':&atiOD Layer 6:

LayerS: ScaiOB

Layer 4: Tnasport

_erik

Layer 3:

....

Ead-to-cad

msaalillg

-Can- (;Qotrol ----L4S1

Layer 2:

X2S PacJo:tlavd

I

X2S

FUIthtt

PacJo:tlavd

"udy

X2S

L\P-D (l44I)

o..aliat

L\P-B

Layer I: PIlysical

Layer 1 (1.430. L(31)

$g1la1

Packot

I

D-awlI>el

Tclcmeuy

Qn:::uil

swiIolUag

I

Lc...d

CUCW

Packot swircbing

8·Cbanncl

Figuur 2.2: De gelaagde protocol structuur van het ISDN User-Network interface.

2.2

Diensten

ISDN zal een groot aantal nieuwe diensten kunnen leveren maar zal tevens de al bestaande toepassingen van spraak- en datacommunicatie blijven ondersteunen. Door de CelTI zijn drie soorten diensten gedefinieerd, namelijk: •

Bearer Services: deze diensten geven de mogelijkheid om infonnatie (spraak, data, video, enz.) over te dragen zonder verandering van de inhoud of

5


vertraging (real time) van een bericht. Deze diensten corresponderen met de onderste 3 lagen (physical, data link en network layer) van het OSI model. Enkele voorbeelden van bearer services (1.211) zijn: - 64 kbitls, 8 kHz structured, unrestricted (circuit-mode service) - 64 kbitls, 8 kHz structured, speech (circuit-mode service) - virtual call and pennanent virtual circuit (packet-mode service)

•

Teleservices: de teleservices combineren de transport functie met de infonnatie verwerkende functie. De bearer services zorgen voor het transport van de data terwijl een aantal extra functies in de hogere lagen (lagen 4

tim 7) zorgen voor

de infonnatieverwerking. Voorbeelden van teleservices zijn: - telefonie - teletex - videotex •

Supplementary services: supplementary services zijn services die alleen sarnen met een of meer vail de bovenstaande diensten kunnen bestaan. Het zijn uitbreidingen van de bearer of teleservices. Voorbeelden van deze services zijn: - user-to-user signaling - call forwarding unconditional - closed user group

In deze drie categorieen zijn een aantal specifieke diensten, waarvan hierboven enkele zijn

genoemd, door het CCITI gedefinieerd. Deze verschillende diensten onderscheiden zich door hun functies en mogelijkheden. Deze functies en mogelijkheden worden vastgelegd door waarden die aan een aantal vaste attributen (1.130) worden meegegeven.

2.3

ISDN architectuur

2.3.1 User-Network interface In figuur 2.2 hebben we de gelaagde structuur van het User-Network interface al kunnen

zien. Analoog aan deze gelaagde structuur worden door het

ccnT een aantal functionele

groepen en referentiepunten gegeven die de eisen van een gebruikersinterface vastleggen. De functionele groepen bevatten nu de fysische apparatuur, eventueel opgebouwd uit

6


meerdere afzonderlijke apparaten. De referentiepunten worden gebruikt als scheiding tussen de functionele groepen. Voor ieder referentiepunt kan nu een interface standaard worden opgesteld. Voor ISDN worden nu de onderstaande groepen gebruikt: • Network termination I (NTl) : deze groep bevat functies die, analoog aan laag 1 van het OSI model, zorgen voor de fysische en de elektrische afsluiting van ISDN aan de gebruikerszijde en geeft een nieuwe fysieke aansluitmogelijkheid voor gebruikersapparatuur. Tevens geeft de NTl onderhoudsfuncties voor het transmissiemedium. De NTI zorgt verder nog voor het multiplexen van de kanalen (2 x B + D) en laat het aansluiten van meerdere apparaten toe ('multidrop arrangement'). •

•

Network termination 2 (NT2) : deze groep is functioneel analoog aan de lagen 1,2 en 3. De NT2 bezit schakelen concentratie functies. Voorbeelden van een NT2 zijn: een digitale PBX, een terminal controller en een LAN. Terminal equipment type 1 (TEl) : deze groep heeft betrekking op die apparatuur die het standaard ISDN interface ondersteunen, bijvoorbeeld: digitale telefoon, gei"ntegreerde spraak/data tenninals en digitale facsimile apparatuur.

•

Terminal equipment type 2 (TE2) : in tegenstelling tot de bovenstaande groep bevat deze de al bestaande niet-ISDN compatibele apparatuur zoals terminals met RS232 interface en computers met X.25 interface. De TE2 apparatuur heeft de TA groep nodig om op ISDN aangesloten te kunnen worden.

•

Terminal adapter (TA) : de terminal adapter groep verzorgt de omzetting van ISDN naar niet-ISDN en omgekeerd en wordt op een ISDN interface aangesloten.

Tussen deze groepen zijn de volgende referentiepunten gedefinieerd: •

U-referentiepunt: dit interface (het 'user'-referentiepunt) beschrijft het fullduplex data signaal dat door het netwerk of door de gebruiker ffioet worden gebruikt bij een verbinding tussen heide. Verder is dit interface of referentiepunt niet gedefinieerd door het CCITT in de aanbeveling 1.41l.

•

T-referentiepunt : het 'terminal'-referentiepunt komt overeen met een

7


minimale ISDN netwerkafsluiting aan de gebruikerszijde. Het scheidt de netwerkapparatuur van de gebruikersapparatuur.

•

S-referentiepunt: het 'system'-referentiepunt komt overeen met het interface van de individue1e terminals. Dit interface scheidt de terminalapparatuur van de functies die voor de netwerkcommunicatie zorgen.

•

R-referentiepunt: het 'rate'-referentiepunt zorgt voor een niet-ISDN interface tussen de gebruikersapparatuur die niet-ISDN compatibel is en de terminal adapter. Het interface komt veelal overeen met de aanbevelingen uit de X of V series CCnT Recommendations.

De relatie tussen de bovenstaande functionele groepen en de referentiepunten is in figuur 2.3 terug te vinden. Later zien we dat het Sen T referentiepunt kunnen samenvallen zodat het

srr interface ontstaat. (

TEl

H

=

H

(=HTA~

NTI

o

---+---

J---t-

functionele groep referentiepunt

Fig. 2.3 : ISDN referentiepunten en functionele groepen

2.3.2 Transmissie structuren Een digitale aansluiting van ISDN bevat een aantal communicatiekanalen. De capaciteit van de aansluiting, dus het aantal kanalen, kan varieren per gebruiker, maar de structuur van elke aansluiting bestaat uit de volgende soorten kanalen: •

B kanaal: 64 Kbitls

•

D kanaal: 16 of 64 Kbitls

• H kanaal: 384, 1536, of 1920 Kbitls Het B-kanaal is een kanaal voor de gebruiker dat kan worden gebruikt voor de overdracht van digitale data, PCM-gecodeerde digitale spraak, of een combinatie van dataverkeer met

8


een lagere transmissiesnelheid Drie verschillende soorten verbindingen kunnen met dit kanaal worden opgezet, namelijk: circuit-switched, packet-switched, semi-permanent. Het D-kanaal heeft twee functies. De eerste functie van het kanaal is de overdracht van de 'Common-Channel-Signaling' (CCS) infonnatie om de 'circuit-switched' verbindingen van

de B-kanalen mogelijk te maken. Het kanaal kan verder nog worden gebruikt voor packetswitching of voor lage snelheid telemetrie indien geen signaleringsinformatie verzonden moet worden. Het H-kanaal worden gebruikt voor data met een hogere bitsnelheid. De gebruiker kan dit kanaal als een 'high-speed trunk' gebruiken of kan het indelen volgens een eigen TDM systeem. De best gedefinieerde digitale aansluitingen zijn de 'basic access' en 'primary access'. Deze bestaan uit een aantal van de bovenstaande kanalen zoals we ook in figuur 2.4. }

I.

()

BASICSERVI<E Role, 192 kbiI/I

1Dfonnaaon: yoWe, data

)::

Composilioo: B+B+D d 1 _

+ I)"acbroaizatioo aDd framing

2.

()

PRIMARY SERVI<E Rat., 1.5442/2.048 MbWo Composilioa:

2.048 Mbil/I:

30

B ehaaaelJ .. 64 KIDI/I .... 1 De.aallC1 al64 Kbil/I

1.:544 Mbi/JI:

23 B ehaBaelJ" 64 Kbills .... 1 DehaBlIC1a164KI>iI/,

~

:c:} D

I

Fig. 2.4 : ISDN kanaal structuren De 'basic access', bedoeld voor kleine gebruikers, bestaat dus uit twee full-duplex 64 Kbit/s B-kanalen en een full-duplex 16 Kbit/s D-kanaal, zodat de totale bitrate 144 Kbit/s bedraagt. Door het gebruik van framing, synchronisatie en andere extra bits wordt de uiteindelijk bitrate 192 Kbit/s. Met deze basiskanalen, is het mogelijk om gelijktijdig een spraak- en meerdere data-applicaties te gebruiken zoals een 'packet-switched' verbinding, facsimile, teletex, enz.. Toegang tot deze diensten kunnen we verkrijgen door een multifunctionele terminal of door verschillende terminals. Beide mogelijkheden maken gebruik van maar een fysische connector. De 'primary access', bedoeld voor gebruikers die een grotere capaciteit nodig hebben (b.v. een bedrijf met een digitale PBX of een LAN), geeft twee mogelijke bitrates, nameljjk:

9


•

1.544 Mbit/s: deze bitrate komt overeen met de T1 transmissiesysteem van AT&T en bevat 23 B-kanalen en 1 D-kanaal, alle 64 Kbit/s. Dit systeem wordt in de Verenigde Staten, Canada en Japan gebruikt

•

2.048 Mbit/s: deze bitrate komt overeen met het CEPT systeem en bevat 30 B-kanalen en 1 D-kanaal, al1e 64 Kbit/s. Het systeem wordt in Europa gebruikt

Als een gebruiker meerdere 'primary' aans1uitingen heeft dan kan worden vo1daan met een D-kanaal op een van de aansluitingen. Ook ondersteunt deze aansluiting de H-kanalen zodat de volgende kanaalstructuren mogelijk zijn:

• Primary rate interface HO channel structures: deze heeft de structuur 3 HO + D of 4 HO bij 1.544 Kbit/s en 5 HO + D bij 2.048 Kbit/s. • Primary rate interface HI channel structures: geeft 1 H11 kanaal van 1536 Kbit/s of 1 H12 kanaal van 1920 Kbit/s en 1 D-kanaal.

• Primary rate interface structures for mixtures of Band HO channels: deze structuur bestaat uit een eventueel D-kanaal plus iedere mogelijke combinatie van B- en HO-kanalen tot de capaciteit van het fysische interface bereikt wordt

2.4

Samenvatting

In dit hoofdstuk is een overzicht gegeven van de standaarden die bij het ISDN gebruikt worden. Verder worden de ISDN communicatieprotocollen en hun onderlinge relatie in het User-Network interface met behulp van het OSI-model verduidelijkt. Tevens is een korte uitleg gegeven van de drie soorten diensten, bearer services, teleservices en supplementary services, die door het CCIrr voor het ISDN zijn gedefinieerd. De telefoonfunctie behoort tot de zogenaarnde teleservices. Verder worden de best gedefinieerde kanaalstructuren die aan een gebruiker kunnen worden aangeboden, de 'basic access' en de 'primary access', besproken. Ook het daarbij gebruikte model van het CelIT voor het User-Network interface komt ter sprake. Bij de implementatie van de telefoonfunctie gaan we gebruik maken van de al genoemde 'basic access' aansluiting op het Sf[ referentiepunt. Deze digitale aansluiting geeft bij een bitrate van 192 Kbit/s toegang tot twee B-kanalen en een D-kanaal.

10

ISDN hard- en software

3.


De vakgroep Digitale Informatiesystemen van de Faculteit der Elektrotechniek van de Technische Universiteit Eindhoven heeft voor het onderzoek aan ISDN twee Mitel ISDN Express Cards gekocht. Ook werd een eigen ISDN tenninal ontworpen en gebouwd [3] die gebruik maakt van de AMD ISDN IC set. Op beide systemen is het mogelijk de ISDN protocollen te implementeren. Enkele protocollen, vooral van de OSI lagen 1 en 2, zijn al geheel of gedeeltelijk in de hardware aanwezig. In de volgende paragrafen voIgt eerst een beschrijving van de MITEL kaarten, waarna de beschrijving van het terminal board voIgt. Als laatste wordt de beschikbare software voor deze systemen behandeld

3.1

De Mite) ISDN Express Card

De MITEL ISDN Express Card [19] bestaat uit een aantal gespecialiseerde ISDN IC's van MITEL [20] die onderling zijn verbonden door een seriele Time Division Multiplexed (TDM) bus, de MITEL ST-bus™. De MITEL kaart beschikt over twee 'basic access' interfaces, een voor het

srr-

referentiepunt het zogenaamde 'Subscriber Network Interface Circuit' (SNIC), en een voor het U-referentiepunt het zogenaamde 'Digital Network Interface Circuit' (DNIC).

De twee aanwezige 'primary access' interfaces ondersteunen de twee toegestane bitrates van deze aansluiting, een 'Tl digital trunk interface' (1.544 Kbit/s) en een 'CEPT trunk interface' (2.048 Kbit/s). Verder is er nog een telefoon interface voor de aansluiting van een telefoonhoom. Over het PC interface kuooen alle componenten van de MITEL kaart bestuurd en gecontroleerd worden. De componenten kuooen door de 'Digital Time/Space Crosspoint Switch' (DX) aan elkaar gekoppeld worden via het ST-bussysteem. Met behulp van de HDLC-controllers is het mogelijk de datastroom tussen de DX en de SNIC volgens het HDLC-protocol te laten verlopen. Tevens bevat de kaart een klokgenerator en DPLL die het kloksignaal voor de gehele kaart verzorgt. Als de MITEL kaart als NT (Master Mode) dienst doet dan wordt de

11


klokgenerator als bronsignaal voor de verschillende interfaces gebruikt voor het opwekken van de framesynchronisatie. De klok wordt bij de TE mode (Slave Mode) met behulp van een PLL uit een van de binnenkomende signalen afgeleid De modes die voor de SNIC en DNIC mogelijk zijn definieren de uitgaande en inkomende bitstroom die weI dezelfde bitrate hebben maar niet geheel dezelfde informatie-inhoud De bovenstaande kaart structuur is in figuur 3.1 als blokschema getekend.

~ ~

3

CEPr

T1

1IUDk

trunk

2.048 Mbit/s 30B+D

Digital Q-osspoint

1.544 Mbit/s 23B+D

Switch

DNIC

SNIC

U-interface

S-interface

2B+D

Digital

Phone

Clock Generator

andDPlL

Fig. 3.1 : Blokschema van de MITEL ISDN Express Card In de volgende paragrafen behandelen we de achtereenvolgens de digitale telefoon, de

crosspoint switch, het DNIC en het SNIC. De andere componenten zijn in dit verslag van ondergeschikt belang.

3.1.1 De Digital Telephone (D.Phone) Het digitale telefoon interface wordt op de MITEL kaart met behulp van de MT8994/5B

12


verwezenlijkt (zie figuur 3.2). De belangrijkste functies van de digitale telefoon (D-Phone zijn: •

Jl-Iaw codec (MT8994B) of A-law codec (MT8995B)

• •

programmeerbare ontvangstversterker DTMF- en toongenerator

•

speakerphone mogelijkheden

• •

interface voor standaard telefoon transducers sense/drive poorten voor een toetsenbord of display VDO

vss

Nt::

M1C

<XlDllCn

Vref

, ----------

VSSSPKR M+

DSTo Iligi"" Signal P'roceI80r

om

M. HSPKR+ HSPKRSPKR+ SPKR-

funsducer

In",uec..

SIlO SOl

SID

C-<:hannel

SOl

Serial-I<>Parallel

SDI S~

Cnoverrer

Oli

FOi

SD6

ADOl234S67

Ie

WD

Fig. 3.2 : Blokschema van het digitale telefooncircuit De D-Phone kan door een microprocessor met een Intel of Motorola compatibel busstructuur worden bestuurd via het microprocessor interface. Er zijn voor de besturing een ll-tal registers beschikbaar. Bet gei'ntegreerd telefooncircuit converteert de analoge signalen naar digitale PCM en omgekeerd door gebmik van een codec. De codec in deze chip versie zou moeten voldoen aan de gestelde eisen in G.?11 voor een Jl-Iaw codering aangezien op de MITEL kaart de MT 8994B is geYnstalleerd. Bet signaal dat van de hoom binnenkomt op de pinnen M+ en M- wordt eerst gefilterd en op 8 kHz gesampeld, waarna het signaal door een AID converter en de codec in een digitale PCM-code wordt omgezet die weer naar de DSP wordt gestuurd. Door de DSP

13


(digital signal processor) kan het signaal verder geoptimaliseerd worden. Vervolgens kan het digitale signaal op de seriele ST-bus worden gezet, zodat de andere componenten op de MITEL kaart de data kunnen verwerken. In het ontvangstpad wordt de seriele data van de ST-bus in omgekeerde richting verwerkt

en via enkele extra versterkers en een D/A-converter met uitgangsfilter op de HSPKR+/HSPKR- gezet. De DSP heeft drie mogelijk algoritrnen: het speakerphone algoritrne, een tone-ringer algoritme en een DTMF/tone generator algoritrne. Het speakerphone algoritme geeft de mogelijkheid om handsfree te telefoneren. De zend en ontvangstversterkers werken complementair en half-duplex. De versterkers worden dus afwisselend aan en uit geschakeld en weI zodanig dat er hooguit een actief is. Het algoritme bepaalt welke versterker wordt aangeschakeld door het vergelijken van de inkomende en uitgaande signaalniveaus. Met het tone-ringer algoritme kan er een tweetonig belsignaal worden opgewekt, dat met behulp van een besturingsbit aan of uit kan worden geschakeld. De DTMF/tone generator kan worden gebruikt voor 'in-band' signaleringen. De DTMF generator kan bijvoorbeeld gebruikt worden bij een gesproken informatiedienst waar door het intoetsen van een nummer een keuze moet worden gemaakt. De verschillende nummers kunnen dan met behulp van de DTMF generator in specifieke tonen worden omgezet waarop de informatiedienst dan kan reageren.

3.1.2 De Digital Time/Space Crosspoint Switch (DX) De Digital Time/Space Crosspoint Switch (DX) , de MT8980D (zie figuur 3.3), wordt gebruikt voor het schakelen van de seriele data afkomstig van de andere componenten via de MITEL ST-bus. Ook dit Ie kan via een microprocessor interface worden bestuurd. Deze bouwsteen voorziet in 256 gelijktijdige verbindingen van iedere 64 kbitls. Elk van de acht seriele ingangen en uitgangen bestaat uit 32 kanalen van ieder 64 kbitls die samen een 2048 kbitls ST-bitstroom vormen. De aangesloten microprocessor ziet de DX als een stuk geheugen. Er kan worden naar de DX worden geschreven om verbindingen op te zetten tussen een willekeurig gekozen inen uitgangskanaal of om rechtstreeks data over een kanaal te sturen. Door het lezen van

14


een geheugenlocatie kunnen de verbindingen worden gecontroleerd of data worden ontvangen. C4i

VDD

FOi

ODE

VSS

Output

SliO

sm STI2

Sli3 STI4 STI5

MUX

Serial to

Data

Parallel

Memory

STaO STal STa2 STo3 STa4

Converter

STo5

STI6

ST06

STi7

STo7

DS

cs R/W A> orA 07AO

CSTo

DO

Fig. 3.3 : Blokschema van de DX Het DATA-geheugen wordt gevonnd door de 8 streams * 32 kanalen = 256 8-bits woorden die het aantal mogelijk te schakelen kanalen omvat. Naast dit DATA-geheugen is er een CONNECI10N-geheugen, opgesplitst in een HIGH en LOW gedeelte. Met HIGHconnection geheugen kan een specifiek kanaal worden gecontroleerd. In het LOW gedeelte wordt de connectie vastgelegd door een adres van het datageheugen op deze plaats te schrijven. Het DATA-geheugen geeft dus het ingangskanaal terwijl de plaats in het LOWconnection geheugen het uitgangskanaal aangeeft.

3.1.3 De Digital Network Interface Circuit (DNIC) Het Digital Network Interface Circuit (DNIC) geeft een aansluiting voor het Ureferentiepunt (zie figuur 3.4). Omdat het CCITT geen aanbevelingen voor dit referentiepunt geeft, heeft MITEL zelf een transmissiesysteem opgezet dat gebruik rnaakt van echo-cancellation technieken am een full-duplex signaal over twee draden te kunnen verzenden. De belangrijkste kenmerken van de DNIC, de MT8972, zijn:

15


•

full-duplex digitale transmissie over een enkel twisted aderpaar

•

twee bitrates : 80 kbit/s (B + D) of 160 kbit/s (2 B + D)

•

tot 5 KIn op 80 kbit/s en 4 KIn op 160 kbit/s

• MITEL ST-bus compatibel We zien dat het IC alleen de 'basic access' aansluiting kan ondersteunen indien een bitrate van 160 kbit/s wordt gekozen zodat beide B-kanalen en het D-kanaal kan worden verzonden. De DNIC heeft drie seriele poorten: de DV (Data/Voice) poort, de CD (Control/Data) poort (wordt door MITEL Diet gebruikt) en de Lijn poort (Lin, LouV' De informatie van de DV poort (ST-bus) wordt nu door het IC op de Lijn poort (twisted-pair) gezet en omgekeerd.

DSliIDi

CDSTIICDi

!'WaD

Cirrcx roo/RCK MW MSI

MS2

\l<sC

oso

DSToIDo

OOfc=tWly Eo<:ode
CDSTo/CDo

VDD

VSS

Vbi..

OSCI

Vrd

Fig. 3.4 : Blokschema van het Digital Network Interface Circuit

3.1.4

De Subscriber Network Interface Circuit (SNIC)

Het Subscriber Network Interface Circuit (SNIC) geeft een aansluiting voor het

Srr-

referentiepunt (zie figuur 3.5). De belangrijkste kenmerken van de SNIC, de MT8930, zijn:

16

. ISDN hard- en software

srr interface

•

CCnT 1.430

•

full-duplex 2 B + D, 192 kbit/s bitrate

•

D-channel contention resolution

•

link activation/deactivation

•

point-to-point, point-to-multipoint and star configuration

•

NT of TE mode

•

On-chip HOLC D-kanaal protocoller

•

MITEL ST-bus compatibel

•

test mogelijkheden

De S-bus die door het IC wordt ondersteund is een vierdraads, full-duplex, time-division gemultiplexed transmissiesysteem dat data uitwisselt met 192 kbit/s. Bet frame bestaat uit 2 B-kanalen (64 kbit/s), een D-kanaal (16 kbit/s) en 48 kbit/s voor synchronisatie en overhead.

DSTi

LTx

S-Bus

DSTo

Vbia.

ST-Bus

Link

Interface

Interrace

LRx

Rlod C4b

VDD

FOb

VSS

STAP.j RsIO

NI'/ TE

Rsti

Cmode

HALF

ADll-1

R/W/ WR AFI'/PRl

DS/RD

AS/AlB

CS

IRQ,

DinB

PSC

DCR

DCack

NDA

Fig. 3.5 : Blokschema van de Subscriber Network Interface Circuit De S-bus wordt met behulp van het 'link activation' protocol, een Layer 1 protocol, (zie figuur 3.6) in gebruik genomen. Er vindt dan een uitwisseling van zogenaamde INFO berichten plaats tussen de NT en TE. [2] [20] De beide B-kanalen en het D-kanaal kunnen pas gebruikt worden als de S-bus is geactiveerd. Het state-diagram dat bij de 'link activation' protocol hoort, is in figuur 3.7 te Zlen.

17


Signals from NT to 1E InfoO

Signals from TE to NT

NoSigna1

InfoO

No Signal

Info!

Conlinuous Signal of + '0', :rr

andsix'l's I I

I

I

I

I I

I

Valid fram. 8lIII
Info2

IOIW'Ct

Info3

Valid fume wi... data in B &: D

bils Valid frame with data in B,

Inf04

D, D-ec:b.o channels. Bil A ill 101

wI.

Fig. 3.6 : Ret 'Link Activation' protocol

1E State Actiyation DiallJ$UD

NT State Activation Diawun

Met:

BA = Bus Activity DR = Deactivation Requcsl AR

=Activation Request =Pramt: Sync Signal

Sync

A = Activation bil

TIDlO oul = 32mB Timet Sigoal

Fig. 3.7 : State-diagram van het 'link activation' protocol

18


De data die via de geactiveerde S-bus binnenkomt kan natuurlijk weer via de ST-bus verder worden gestuurd en omgekeerd van de ST-bus naar de S-bus. Het gehele IC wordt bestuurd door de registers die toegankelijk zijn via het microprocessor interface. De aanwezig HOLC protocoller zorgt voor de protocol structuur van het D-kanaal zoals die in de laag 2 recommendations van het CCITT is vastgelegd.

3.2

Het ISDN terminal board

Het ISDN tenninal board dat werd ontworpen door P.I.G. Wetennan [3] kan worden aangesloten op een Sff-referentiepunt. Het is dus compatibel met de S-bus van het Subscriber Network Interface Circuit. De belangrijkste bouwstenen zijn : •

80186 microprocessor

•

82258 Advanced DMA co-processor ( for extra DMA channels)

•

8288 bus controller en 8207 dynamic RAM controller

•

512 Kbytes dynamisch RAM, 128K ROM

•

8259A-2 programmable interrupt controller (PIC)

•

82C55A-2 programmable peripheral device (parallel I/O port)

•

AM79C30A Digital Subscriber Controller l'DSC) (ISDN Sff interface)

•

2 * AM79C401 Integrated Data Protocoller (lDPC) (ISDN protocoller)

We zien dat het terminal board geen MITEL ISDN IC's gebruikt maar IC's van Advanced Micro Devices (AMD), maar beide voldoen aan de ISDN standaarden. WeI dienen de IC's op verschillende manieren te worden geprogrammeerd, de IC functies komen overeen

maar de besturingsregisters niet. De DSC zorgt voor het Sff-interface en voor een digitale telefoonaansluiting, het is een gecombineerde D-Phone en SNIC als we dit vergelijken met het MITEL ontwerp. De IOPC omvat o.a. een Dual-Port Memory Controller (DPMC), een protocol-controller (LAPB, LAPD, DM!) en een Universal Synchronous/ASynchronous Receiverffransmitter (USART). Alleen het laatste onderdeel za1 voorlopig worden gebruikt om berichten en commando's van/voor de Monitor Dispatcher (zie ook latere hoofdstukken) over te brengen. Een tweede PC met RS232 interface en een tenninalprogramma (b.v. TELIX) wordt hiervoor gebruikt.

19


De processor en ROM is op het tenninal board vervangen door de Intel 80186/80188 InCircuit-Emulator (ICE) [14] zodat het installeren van nieuwe software en het testen veel gemakkelijker kan worden gedaan (zie bijlage 3) met behulp van een PC en C-compiler. Ook kan de parallelle poort worden gebruikt om de interne status van het board weer te geven, maar deze functie wordt overbodig door de verdere ontwikkeling van de Monitoring Dispatcher zoals uit latere hoofdstukken zal blijken. De parallelle poorten bevinden zich op de I/O adressen 1000H en 2000H. De I/O adressen van de interne 80186 functies (timers, DMA en interrupt controller) zijn in het Intel data boek [15] terug te vinden. De drie belangrijkste bouwstenen de PIC, de DSC en de IDPC bespreken we in de volgende paragrafen. De geheugenindeling van het tenninal board is als voIgt:

Adres

ComDonenten

COOOOH-FFFFFH

ROM

84000H

PIC

83000H

DSC

82000H

IDPC-2

81000H

IDPC-l

80000H

Advanced DMA

00000H-7FFFFH

RAM

Tabe13.8 : Geheugenindeling van het terminal board

3.2.1

De Programmeble Interrupt Controller (PIC)

De interne interrupt controller van de 80186 wordt in cascade mode geprogrammeerd zodat de INTl/INT3lijnen van de microprocessor als interrupt request/acknowledge paar werken. De externe interrupt controller kan op deze lijnen worden aangesloten. Deze interrupt controller heeft acht extra lijnen waarop de volgende interrupts zijn aangesloten:

20


PIN

BRON

IRQO

DLC van IDPC-1

IRQ1

USART van IDPC-1

IRQ2

DLC van IDPC-2

IRQ3

DSC

IRQ4

EOD3 (exteme DMA)

IRQ5

EOD2 (exteme DMA)

IRQ6

EOD1 (exteme DMA)

IRQ?

EODO (exteme DMA) Tabe13.8 : De exteme interrupt bronnen

De PIC wordt geprogrammeerd met behulp van Initialization Command Words (lCW) en

Operation Command Words die in de databoeken van Intel terug zijn te vinden [16].

3.2.2 De Digital Subscriber Controller (DSC) De DSC zorgt voor het Sff-interface en voor een digitale telefoonaansluiting, het is een gecombineerde D-Phone en SNIC als we dit vergelijken met het MITEL ontwerp. De DSC bestaat uit 6 aparte blokken die ieder een specifieke taak verrichten: het MicroProcessor Interface (MPn, het OSCillator- en timingcircuit (OSC), de Data Link Controller (OLC), de MUltipleXer (MUX), de Main Audio Processor (MAP) en Line Interface Unit (LID). De digitale data die van de S-bus binnenkomt wordt door de LIU omgezet in een handelbaar digitaal formaat. De S-bus is pas actief als er een activation request heeft plaats gevonden en is geaccepteerd. De digitale data kan dan door de MUX naar de verschillende blokken worden doorgeschakeld. Dit geldt natuurlijk ook in omgekeerde richting. Data die in een van de blokken wordt gegenereerd kan via de MUX naar het LIU worden

verzonden. Met de MUX kuooen maximaal drie bidirectionele verbindingen worden gelegd tussen de

21


blokken. Het D-kanaal van de LID (Sff-interface) wordt rechtstreeks naar de DLC doorgeschakeld. Deze zorgt ervoor dat de infonnatie-uitwisseling over het D-kanaal volgens het LAPD protocol verloopt. De DLC is op zijn beurt via de MPI toegankelijk. CAPI

CAn

SBIN

SBOUT

SQ..K

SFS

HSW

AINA

AREF A1NB

EARl

LOUTl LOUTI

Seriallnterfac:e

LIN1

MUX

LIN2

EAR2 LSI LS2

DLC

XTALI XTAL2 MQ..K

cs WR

RESET

MPI

RD

001234567

INT

A012

Fig. 3.10 : Blokschema van de Digital Subscriber Circuit De MAP is het digitale interface voor de aansluiting van een telefoonhooro. Dit onderdeel heeft de mogelijkheid DTMF signalen en aparte signaleringstonen te genereren. Verder is er voor het conditioneren van de ontvangen en verzonden data verschillende versterkers en programmeerbare fIlters aanwezig. Ben uitgebreide functie en register beschrijving kunnen we vinden in het AMD databoek [17]. De registers voor de verschillende componenten kunnen weer via een microprocessor interface gelezen en geschreven worden.

3.2.3 De Integrated Data Protocol Controller (IDPC) De Integrated Data Protocol Controller (IDPC) bestaat uit de volgende onderdelen (zie figuur 3.11): de Data Link Controller (DLC), de Universal Synchronous/Asynchronous Receiverffransmitter (USART), de Dual-Port Memory Controller (DPMC) (deze wordt

22


niet gebruikt op het tenninal board en het MicroProcessor Interface (MPn. Het enigste onderdeel van de IDPC dat gebruikt wordt, is de USART en het MPI. Over deze seriele verbinding (RS232) kunnen we de Monitoring Dispatcher bekijken en besturen. Op deze aansluiting wordt voor dit doel een PC aangesloten met RS232 interface waarop we een tenninalprogramma laten draaien (b.v. TELIX) dat ANSI-codes kan verwerken. De gekozen bitrate van dit interface is in ons geval afhankelijk van de gebruikte PC, maximaal2400 baud voor een XT-PC en 9600 baud voor een AT-PC op 12

MHz. De DPMC wordt in zijn geheel niet gebruikt omdat voor een ander geheugen ontwerp is gekozen. De DLC kan later nog gebruikt worden bij het implementeren van eventuele data verbindingen over de B-kanalen met HDLC, LAPB, LAPD of DMI protocollen. [18]

r I

:

ff-

....

....

~

I".. .

f- -4 .......

10-

-{ " ....

I- -1-...

I--

.... RIO

""" Cd

Jt.ilRfQ

co.

.... ... ....

I,P

I

f-

e.-.~

I

.....

:DATA. UNE CON'I'lOU..&R (t)I..C)

II---

I ... RIO

-~

I

r--

r---1-

I

a.d..-a...-.-

I

~ ~ i-

1-

c:...-_

x.,,,,,,

I

_....

tlSA&T

I,P

I--

uw:r

:::::

::

=:

::.~:: =: t;

I-

~

~ ::; ~ :;

i-

UWl11Nr

uwm::u: hQJ[ Ild)

"" m

Cii iiii iii

lItCLI:our

Du.ll.p~

.....ayCcnrolllr

"'''''J

I.

,. ,. - -

J.

J.

,.

T

Fig. 3.11 : De Integrated Data Protocol Controller

3.3

Het besturingssysteem

Op beide ISDN systemen wordt het protocol van de fysische laag door de hardware uitgevoerd zodat we voor de B-kanalen verder geen protocollen nodig hebben om de

23


digitale telefoon (zie figuur 2.2, B-channel, circuit-switched) te implementeren. We moeten aIleen de protocollen voor het D-kanaaI realiseren die door de CCITI gedefinieerd zijn. De protocollen die door het CCITI worden voorgesteld, kunnen weergegeven worden door toestandmachines. Op iedere laag bevindt zich verder een aantal processen die allemaal een specifieke functie hebben. Deze zijn ook door toestandmachines weer te geven. Ieder proces bezit een aantal parameters en kan met andere processen communiceren door het gebruik van primitieven. De toestand van een proces verandert afhankelijk van de interne parameters en de binnenkomende primitieven. Deze toestandsverandering kan tot gevolg hebben dat dit proces zijn interne parameters verandert of zelf primitieven gaat verzenden en op deze manier weer andere processen beYnvloedt. Voor het beheer van deze processen, parameters en primitieven is een besturingssysteem nodig dat de volgende eigenschappen bezit: •

een snelle interrupt afhandeling

•

een klein aantaI hardware interrupts

•

beheren van een groot aantal processen

• prioriteiten per proces Deze eigenschappen zijn door H. Oudelaar [4] in een besturingssysteem geiinplementeerd. Het besturingssysteem heeft een structuur zoals in figuur 3.12 is getekend.

MSG

MSG

Fig. 3.12 : Structuur van het besturingssysteem De berichten ('messages') die de onderlinge communicatie verzorgen, komen in wachtrijen

24


te staan met verschillende prioriteiten (0, 1 of 2). De 'dispatcher' vormt het hart van het besturingssysteem en verwerkt de berichten uit die wachtrijen waarbij de wachtrij met de hoogste prioriteit als eerste wordt verwerkt (laagste nummer en de laagste laag (1». Daama komt pas de volgende wachtrij aan de beurt. Komt er een bericht binnen met een hogere prioriteit dan wordt deze meteen bij de volgende verwerkingsslag van de dispatcher verwerkt. De dispatcher kan uit de berichten het bestemmingsproces bepalen en het naar dit proces

doorstur~n mits

de toestand van het bestemmingsproces het toelaat.

De communicatie met de hardware geschiedt met interrupts die bij de MITEL kaarten door een timer en de SNIC, en bij het terminal board door een timer, de DMA, de IOPC's, en de DSC worden gegenereerd. Iedere interruptbron heeft een interrupt-service-routine waarin de precieze reden van het interrupt wordt onderzocht en verder wordt verwerkt door het evt. versturen van berichten naar de wachtende processen. De processen hebben elk een datastructuur waarin de volgende parameters zijn opgenomen: •

de toegang tot het proces (BLOCKED of RUNNING)

• •

de prioriteit de huidige toestand ('state') van het proces en evt. een subtoestand

•

procesparameters (max. 8 bytes)

AIle mogelijke toestanden waarin de verschillende processen kunnen komen zijn opgenomen in de toestandtabellen (state-tables). In deze tabellen worden aIle mogelijke berichten, die in een bepaalde toestand toegestaan zijn, gekoppeld aan verwerkingsroutines van het proces die deze berichten verder moeten afhandelen. De berichten maken van een andere datastructuur gebruik: •

het type bericht

•

proces waarvoor het bericht bestemd is

•

proces waarvan het bericht atkomstig is

•

bericht parameters (max. 5 bytes)

In de vele protocollen zijn ook tijdslimieten gebruikt. De timers die voor deze protocollen zijn gedefinieerd worden bij MITEL/pC combinaties door een DOS interrupt steeds weer bijgewerkt. Op het terminal board wordt een interne 80186 timer gebruikt. De timers hebben de beschikking over de onderstaande velden: •

toestand van de timer (USED, FREE)

•

de te verstrijken tijd

25


•

het bericht dat verstuurd moet worden bij het verstrijken van de tijd

•

proces dat de timer gebruikt, waarheen het bericht moet worden verstuurd

• laag 3: de huidige call De bovenstaande berichten, processen en timers worden allen vanuit de dispatcher bestuurd. Om de protocollen te kunnen testen moeten we de dispatcher kunnen beYnvloeden. Daarom zijn er monitor routines geschreven waarmee direct processen, berichten, registers, interrupts, etc. bekeken, bestuurd en gecontroleerd worden. De meeste opties waren echter voorafgaand aan dit afstudeerprojekt nog met mogelijk op het terminal board

3.4

Sarnenvatting

In dit hoofdstuk hebben we de twee ISDN systemen beschreven die op de vakgroep

Digitale Infonnatiesystemen aanwezig zijn. Beide systemen zullen worden gebruikt om een ISDN telefoonverbinding op te zetten via het

srr interface.

Bij de MITEL kaarten moet de software voor het DNIC worden omgezet naar het SNIC, zodat voor een ISDN telefoonverbinding uiteindelijk het SNIC, de DX en de D-Phone worden gebruikt. De aanpassing van de ISDN software wordt beschreven in het volgende hoofdstuk. Op het ISDN terminal board zijn voor deze telefoonverbinding een DSC en een IDPC

aanwezig. De interrupts die door de verschillende tenninal-bouwstenen worden gegenereerd, komen binnen bij de besproken interrupt-controller (PIC).

Op beide ISDN systemen is het besturingssysteem geiinplementeerd dat door H. Oudelaar [4] is geschreven. Een aantal van de ISDN protocollen zijn met behulp van dit besturingssysteem al gerealiseerd, maar op het terminal board waren de Call Control I Resource Management protocollen en de uitgebreide Monitoring Dispatcher nog niet ge'implementeerd. Een beschrijving van deze implementatie voIgt in hoofdstuk 5 en 6.

26

Software ontwikkeling t.b.v. het Mitel SIT inteiface

4.

Software ontwikkeling t.b.v. het Mitel SiT interface

De Mitel kaarten kunnen onderling worden verbonden door een vierdraads srr interface met behulp van de SNIC. Het is echter tot nu toe niet mogelijk geweest het Srr interface te gebruiken voor een verbinding tussen de Mitel kaarten door het telkens weer optredend synchronisatieverlies [8]. Door dit synchronisatieverlies gaat telkens weer data verloren en loopt het communicatieprotocol vast. Volgens 1.R.H. Claessens [10] zouden de data-recovery procedures, die het juiste protocolverloop zouden verzekeren, nog niet zijn germplementeerd, maar bij nader onderzoek bleek dit niet juist te zijn. De timers die voor deze procedures noodzakelijk zijn, waren in de software uitgeschakeld, een standaard instelling van de protocol monitor. Dit werd gedaan om de protocol monitor de tijd te geven de berichten, frames en andere statusberichten op het beeld weer te geven zonder dat het protocol in de time-out procedures terecht zou komen waarbij een bericht opnieuw verzonden zou moeten worden omdat dit niet op tijd werd bevestigd. We kunnen dus weI gebruik maken van de errorcorrectie procedures maar we moeten dan weI de protocol monitor geheel uitschakelen. Dit is alleen een oplossing als vaststaat dat er geen fouten meer in de protocollen voorkomen. De protocollen zijn dus eerst geiinplementeerd en getest door gebruik te maken van het V-interface waar vrijwel nooit een fout optreedt. Hierna is met behulp de veranderde lowlevel driver (van DNIC naar SNIC aansluiting) en de uitgeschakelde monitor nogmaals geprobeerd een telefoonverbinding te maken, wat uiteindelijk ook lukte. Het duurde echter vele minuten voordat de protocollen waren afgewerkt. Omdat we toch graag willen weten hoe het protocol zich gedraagt, moeten we de timers beter kunnen controleren met de protocol monitor. De inhoud van de huidige timers kunnen weI in stapjes worden verlaagt, de zogenaamde 'Stepped Timers'. Dit wi! zeggen dat bij iedere dispatcher cyclus de inhoud van de timers met een verlaagd worden. De timers zijn dus athankelijk van de snelheid waarmee de verschillende subroutines van de protocollen worden doorlopen en daarvoor is geen vaste tijdsspanne aan te geven. In de volgende paragrafen behandelen we de veranderingen aan de timers, de low-level

drivers en de telefoonverbinding over de SNIC. Bij het testen van de telefoonverbinding tussen de MITEL kaart en het ISDN terminal

27

Software ontwikkeling t.b.v. het Mitel SIT interface

board kwam later naar voren dat het D-Phone IC een interne fout bevatte. Het maakte gebruik van een gemverteerde Jl-Iaw codec die dus niet voldeed aan de CCITT aanbevelingen. Verder bleek nog dat ook het SNIC niet in orde was. Beide IC's moesten vervangen worden. De problemen met o.a. de synchronisatie op het S/f-interface en enkele verschillen, die tijdens de ontwikkeling van de software waren gevonden, met de aanwezige datasheets werden door deze vervanging opgelost. Ret is dan echter niet meer mogelijk een telefoonverbinding te leggen omdat er maar een IC set beschikbaar was. Zo zijn er twee verschillende codecs bij de MITEL kaarten in gebruik. WeI kan nog een data link verbinding worden gemaakt.

4.1

De protocol timers

Voor de timers van de protocollen bestaan drie mogelijke modes: Enabled, Disabled en Stepped. Met behulp van de Protocol Monitor kan een van die modes gekozen worden, de gekozen mode geldt voor alle timers. Als de timers worden 'enabled' zuBen deze door een interruptroutine worden bijgehouden. De timers worden alleen gestopt als de protocol monitor de dispatcher tegenhoudt. In de 'disabled' mode worden alle timers gestopt en zullen niet meer door de protocollen gebruikt worden. De 'Stepped' mode gaf de mogelijkheid om de inhoud van de timers bij iedere dispatcher cyclus met een te verlagen. Deze methode geeft echter geen enkele garantie voor een minimale tijdsspanne omdat de timers afhankelijk zijn van de snelheid waannee de verschillende subroutines van de protocollen worden doorlopen. Door de opzet van de bestaande 'Stepped' mode kon deze mode alleen gebruikt worden als men van tevoren wist hoeveel cycli nodig waren voor een protocol stap. De timers werden alleen bijgehouden als het 'GO' commando van de protocol monitor werd gebruikt Door nu de bestaande 'if Flag[Oj

== 's' {..}'

structuren die betrekking hebben op de

'Stepped' timers te verwijderen uit de monitoring dispatcher (DispateherO, MONDISP.C, zie bijlage 4) en de volgende nieuwe structuur vlak voor de dispatchercyclus in te voeren, krijgen we al een meer bruikbare 'Stepped' timer mode: i/(Flag[Oj=='S') ( timecheck();

1* #MR new, delayed-timing *1 1* let time pass in controlled steps *1

28


delay(500);

1* Allow other XT to print messages *1

}

De timers worden door deze opzet voor ieder dispatcher cyclus verlaagd zodat de gebruiker / PC aan de andere kant van de verbinding de gelegenheid krijgt, in dit geval een veelvoud van 500 milliseconden afhankelijk van het nonnale aantal toegestane tijdstikken van ± 0.06 seconden (DOS-timer), om de messages, frames en andere toestandsgegevens op het beeldscherm weer te geven.

4.2

De low-level drivers

De low-level drivers zijn nodig voor de besturing van de hardware die aanwezig is op de MITEL kaarten. De bestaande software maakt gebruik van de DNIC om met beide Bkanalen en het D-kanaal een verbinding op te zetten. Ret D-kanaal wordt echter nog altijd via de ST-bus doorgezonden naar de interne RDLC-transceiver van de SNIC. Dit heeft tot gevolg dat alle interrupts van de SNIC afkomstig zijn. We hoeven de interrupt-services routines niet aan te passen als we de SNIC als ISDN interface gaan gebruiken, de interrupts blijven hetzelfde. Als we de SNIC willen gebruiken moet de bron van het Dkanaal de S-bus worden en de D-phone, die voor het digitale telefooninterface zorgt, moet worden doorverbonden met de SNIC in plaats van de DNIC B-kanalen. Dit kunnen we doen met een initialisatieroutine. Er moot weI rekening worden gehouden met het activeren van het Sff-interface voordat data over deze bus kan worden verzonden. Ret V-interface van MITEL is daarintegen altijd actief. Ook het doorlopen van het 'link: activation' protocol wordt in de initialisatieroutine verzorgd. De oude initialisatieroutine van de DNIC en SNIC bestond uit twee losse gedeelten: de verbinding tussen de DNIC en SNIC voor het D-kanaal werd voor het opstarten van de ISDN software eerst met behulp van het IES-programma van MITEL [19] of door een speciaal geschreven initialisatieprogramma [9] opgezet, daarna volgde in de ISDN software de onderstaande initialisatie voor de SNIC. De bestaande initialisatie van de SNIC is nu op de volgende manier aangepast waarbij men nog weI vooraf met de IES-software de TE of NT mode moet selecteren (toogevoegde of

29


veranderde programmastructuren zijn vet gedrukt):

voidfar inithardw(void)

1* Program hardware *1

(

disable(); vectset();

#ifDNIC outportb(OxbOO,Ox04);

1* Set interrupt vectors *1 1* Program SNIC to generate IRQ signal *1 1*

use IRQINDA pin as IRQ. Note that selection with B2 ofMaster Control Register is as follows: B2

=0 selects NDAfunction

B2 = I selects IRQfunction. (MITEL Databook p 4-67 has been proven wrong on this, with the use ofa logic analyzer) *1

#elijSNIC outportb(OxbOO,OxOl);

1* #MR new *1 1* use IRQ/NDA pin as IRQ.

#MR comment, New chipset!!!!!!, so IRQ on = 0 */ #endij unmask_OF(); rd_ireg();

1* Clear HDLC Interrupt Status register *1

enable_intO;

1* enable SNIC chip interrupts *1

#ifDNIC outportb(Oxb02,Ox40);

1* direction ofD-channel port *1 1* #LOcomment# disable transmitter, enable receiver, no address recognition, transmit to ST-bus, receive from ST-bus, interframe-time-fill=ones and no HDLC-loopback *1

#elijSNIC

30


outportb(Oxb02, 0x58);

/* #MR new, D-channel on S-bus port */

#endif resetRFIFO(); resetTFIFO();

#ijSNIC outportb(Oxb08, 0x42);

/* #MR new, setup S-bus */ /* deactivate S-bus and clear diagn. reg.

TE/NT-mode */ outportb(Oxb08,Ox01);

/* , set multiframe seq. NT-mode */

winsel(2);

/* Print message on screen */ /* 'S-bus still active... '*/ /* and waitfor deactivation */

/* or key to escape */ clrscr();cprintj(" S-bus still active, waiting for INFO O. "); clreol();

while «!kbhit()) && «inportb(Oxb09) & Ox80) == Ox80)); while (kbhit()) getch(); gotoxy(l,1);

/* S-bus deactivated */ /* Activated bus by pressing a key */ /* or waitforactivation signal (INFO)*/

cprintf(" Press any key to activate S-bus or waitfor INFO-signals. "); clreol(); while «(!kbhit()) && «inportb(Oxb09) & Ox80) != OXSO)); while (kbhitO) getch(); /* S-bus is synchronizing */ /* wait for Activation State */ gotoxy(l,1); cprintf(" Synchronizing! ...or any key to tenninate. "); clreol(); /* DeactivationRequest = 0 */ outportb(Oxb08,Ox02); outportb(Oxb08, OxS2); /* ActivationRequest =1 */

while «!kbhit()) && «inportb(Oxb09) & Ox60)!= Ox60)); while (kbhitO) getch(); #endif enable();

/* S-bus activated! !*/

}

31

Software ontwikke/ing t.b.v. het Mitel SIT interface

Door het gebruik van de zogenaamde compiler-directives '#if ', '#elif ' en 'Dendi! kunnen we tijdens het compileren van het programma het SNIC of

DNIC interface kiezen en hoeven er geen twee los van elkaar staande versies van de ISDN software te worden gemaakt. De instellingen die voor het juiste resultaat zorgen, staan in bijlage 3. We zien dat in de bovenstaande routine eerst de S-bus interrupts worden geselecteerd. Vervolgens wordt de HDLC-protocoller geInstrueerd het D-kanaal van de S-bus te gebruiken in plaats van de ST-bus, door het SNIC Master Control Register te programmeren. Bij de implementatie van het 'Link activation' protocol maken we eerst de S-bus inactief. We wachten vervolgens tot alle andere terminal(s) de bus hebben vrij gegeven door in het SNIC NTffE mode register de bits ISO en IS 1 te bekijken. Zodra de bus gedeactiveerd is, kunnen we door het indrukken van een toets de bus weer activeren of wachten op INFO berichten van een andere tenninal. De S-bus is pas bruikbaar als de frames van de S-bus zijn gesynchroniseerd (NTffE mode register, Sync/BA bit). Pas na de synchronisatie kan de ISDN software verder gaan. De low-level driver van de D-Phone die zorgt voor het leggen van de juiste verbinding op de MITEL kaart, kunnen we snel aanpassen door het toepassen van de volgende datastructuur : struct mitel {int stream,channel;}

#ifDNIC 1* DNIC channel and stream parameters *1

dnic_d = {7,D}, dnic_c = {7,l}, dnic_bl = {7,2}, dnic_b2 = {7,3},

#eli/SNIC /* #MR new, SNIC channel and stream parameters */ snic_d ={6,O}, snic_c ={6,1}, snic_bl ={6,2}, snic_b2 ={6,3}, #endif /* DPHONE channel and stream parameters */

dp_c

= {7,5}, dp_bl = {7,6}, dp_b2 = {7,7}, dp_b3 = {7,B};

Verder moeten een aantal aanroepen van subroutines worden veranderd die gebruik maken van deze data-structuren. Deze bevinden zich in L4_PHONE.C:

32

Software ontwikke/ing t.b.v. het Mite/ sIr interface

#ifDNIC make- B - connection(dpbx, dnic -bx); #eli/SNIC make_B_connection(dp_bx, snic_bx); #endif en

#ifDNIC make_B_disconnection(dp_bx, dnic_bx);

#eli/SNIC make_B_disconnection(dp_bx, dnic_bx); #endif waarbij ..bx = bi, b2

4.3

Een telefoonverbinding via de SNIC

Als alle bovenstaande veranderingen zijn aangebracht kunnen we een telefoonverbinding leggen tussen beide MITEL kaarten met behulp van Call Control en het Resource Management die zich op laag 4 bevinden. Het opzetten en verbreken van een circuit-geschakelde verbindig of 'call' verloopt via een aantal toestanden, de 'call states', waarvan een compleet overzicht in de volgende subparagraaf voIgt. Deze lijst is in tweeen verdeeld omdat de gebruikers- en de netwerkzijde niet dezelfde toestanden gebruiken [2].

4.3.1

De laag 3 call states

De gebruikerszijde van het User-Network interface heeft de volgende call states: •

Null state (VO) : Geen calls aanwezig.

•

Call Initiated (VI) : een uitgaande call bevindt zich in deze toestand als de gebruiker het netwerk vraagt een call te realiseren.

•

Overlap sending (V2) : een uitgaande call bevindt zich in deze toestand als de

33


gebruiker een bevestiging heeft ontvangen op de aanvraag om een call te realiseren. Het stelt de gebruiker in staat om aanvuUende informatie omtrent de call naar het netwerk te sturen in overlap mode.

•

Outgoing call proceeding (V3) : een uitgaande call bevindt zich in deze toestand als de gebruiker een bevestiging heeft ontvangen dat het netwerk over alle noodzakelijk informatie beschikt om de call te kunnen realiseren.

•

Call delivered (V4) : een uitgaande call bevindt zich in deze toestand als de gebruiker een indicatie heeft ontvangen dat de alarmering bij de andere gebruiker is gestart.

•

Call present (V6) : een binnenkomende call bevindt zich in deze toestand als de gebruiker een aanvraag voor het realiseren van een call heeft ontvangen. maar hier nog niet op heeft gereageerd.

•

Call received (V7) : een binnenkomende call bevindt zich in deze toestand als de alarmering geactiveerd is maar de gebruiker nog niet gereageerd heeft

•

Connect request (V8) : een binnenkomende call bevindt zich in deze toestand als de gebruiker gereageerd heeft op de call en wacht op bevestiging van de connectie.

•

Incoming call proceeding (V9) : een binnenkomende call bevindt zich in deze toestand als de gebruiker heeft bevestigd dat alle noodzakelijke informatie om een call te realiseren is ontvangen.

•

Active (VIO) : een binnenkomende call bevindt zich in deze toestand als de gebruiker de bevestiging van het netwerk heeft ontvangen dat de call aan de gebruiker is toegekend. Een uitgaande call bevindt zich in deze toestand als de gebruiker een indicatie heeft ontvangen dat de andere gebruiker op de call heeft gereageerd.

•

Disconnect request (VII) : een call bevindt zich in deze toestand als de gebruiker het netwerk heeft gevraagd om de end-to-end verbinding op te heffen en wacht op een bevestiging.

•

Disconnect indication (VI2) : een call bevindt zich in deze toestand als de gebruiker een verzoek heeft ontvangen waarin gevraagd wordt de UserNetwork verbinding af te breken omdat het netwerk de end-to-end verbinding heeft verbroken.

•

Suspend request (VIS) : een call bevindt zich in deze toestand als de

34


gebruiker het netwerk heeft gevraagd om de call, evt. tijdelijk te onderbreken en wacht op een bevestiging. •

•

Resume request (UI7) : een call bevindt zich in deze toestand als de gebruiker het netwerk heeft gevraagd om een eerder afgebroken call te hervatten en op een bevestiging wacht Release request (UI9) : een call bevindt zich in deze toestand als de gebruiker het netwerk heeft gevraagd om de lokale User-Network verbinding vrij te geven em wacht op een bevestiging.

•

Overlap receiving (U25) : een binnenkomende call bevindt zich in deze toestand als de gebruiker de aanvraag, voor het realiseren van een call, van het netwerk heeft bevestigd en is voorbereid om aanvullende informatie in overlap mode te ontvangen.

De netwerkzijde van het User-Network interface heeft de volgende call states: •

Null state (NO) : Geen calls aanwezig.

•

Call initiated (NI) : een uitgaande call bevindt zich in deze toestand als het netwerk van de gebruiker een aanvraag om een cal te realiseren heeft

•

ontvangen, maar nog Diet heeft gereageerd. Overlap sending (N2) : een uitgaande call bevindt zich in deze toestand als het netwerk de aanvraag voor het realiseren van een call heeft bevestigd en bereid is om aanvullende infonnatie in overlap mode te ontvangen.

•

Outgoing call proceeding (N3) : een uitgaande call bevindt zich in deze toestand als het netwerk een bevestiging naar de gebruiker heeft verzonden dat het netwerk alle noodzakelijke informatie om een call te realiseren heeft ontvangen.

•

Call delivered (N4) : een uitgaande call bevindt zich in deze toestand als het netwerk heeft aangegeven dat de alarmering bij de andere gebruiker gestart is.

•

Call present (N6) : een binnenkomende call bevindt zich in deze toestand als het netwerk een aanvraag voor het realiseren van een call naar de gebruiker heeft verstuurd maar nog geen bevestiging heeft gekregen.

•

Call received (N7) : een binnekomende call bevindt zich in deze toestand als het netwerk een bevestiging heeft ontvangen datde gebruiker de alarmering heeft geactiveerd maar nog geen bevestigin van de gebruiker heeft ontvangen.

35


•

Connect request (NS) : een binnenkomende call bevindt zich in deze toestand als het netwerk een reactie van de gebruiker heeft ontvangen maar dat het netwerk de call nog niet heeft toegekend.

•

Incoming call proceeding (N9) : een binnenkomende call bevindt zich in deze toestand als het netwerk een bevestiging heeft ontvangen dat de gebruiker beschikt over alle noodzakelijke informatie om een call te realiseren.

•

Active (NIO) : een binnenkomende call bevindt zich in deze toestand als het netwerk de call heeft toegekend aan de lokale gebruiker. Een uitgaande call bevindt zich in deze toestand als het netwerk heeft aangegeven dat de andere gebruiker de call heeft beantwoord.

•

Disconnect request (NIl) : een call bevindt zich in deze toestand als het netwerk van de gebruiker een aanvraag heeft ontvangen om de end-to-end verbinding op te heffen.

•

Disconnect indication (NI2) : een call bevindt zich in deze toestand als het netwerk de end-to-end verbinding heeft verbroken en de gebruiker heeft verzocht de User-Network verbinding te verbreken.

•

Suspend request (NI5) : een call bevindt zich in deze toestand als het netwerk een aanvraag om de call te onderbreken heeft ontvangen maar nog niet heeft gereageerd.

•

Resume request (NI7) :een call bevindt zich in deze toestand als het netwerk een aanvraag, om een eerder onderbroken, call te herstellen heeft ontvangen, maar nog niet heeft gereageerd.

•

Release request (NI9) : een call bevindt zich in deze toestand als het netwerk de gebruiker heeft gevraagd om de lokale User-Network verbinding vrij te geven en wacht op een response.

•

Call abort (N22) : een binnenkomende call, in een point-to-point configuratie, bevindt zich in deze toestand als de call is opgeheven voordat een gebruiker aan de call is toegekend.

•

Overlap receiving (N25) : een binnenkomende call bevindst zich in deze toestnad als het netwerk een bevestiging, op de aanvraag voor het realiseren van een call, van de gebruiker heeft ontvangen, waardoor het netwerk in staat wordt gesteld om aanvullende infonnatie over de call in overlap mode te verzenden.

36


4.3.2 Het opzetten en atbreken van een telefoonverbinding Voordat het laag 3 protocol 'Call control'-berichten kan verzenden over het User-Network interface moet er een betrouwbare point-to-point datalink gerealiseerd zijn tussen de gebruiker (TE) en het netwerk (En. Het laag 3 proces zal daarom laag 2 vragen om ren DL_ESTABLISH_REQUEST primitieve zodat uiteindelijk een Set Asynchronous Balanced Mode Extend (SABME) frame wordt verstuurd, waarna een Unnumbered Acknowledge (UA) frame moet worden ontvangen. Laag 2 komt dan uiteindelijk in de 'Multiple3rame_established' toestand. De infonnatie van laag 3 kan met behulp van de laag 3 DL_DATA primitieven worden verzonden en ontvangen. Met behulp van figuur 4.1 zal nu het opzetten en afbreken worden besproken. Voor speciale gevallen, b.v. het Diet accepteren van een call of het verbreken van een verbinding door het netwerk, wordt verwezen naar 1.R.B. Claessens [10]. User-A

ET

1E _.~

IJO

SetUp

-

U/

--..

Call-no

...-

RinRS,,*

OJ

_lIIim

U7

~

CmnccI

RingS"'"

u/o

'_Sl~

"-

ET

--- .

- . NON6 - - - - - N7. ...N4 - . . - - - - N8- rr NJ

-

-.

Set '"

"'"'"""

A

IJ()

116

U7

CmnccI ConncclAd:

N/O

Ad: ~

User-B

TE

NO

..

........

1"J8 u/o

N/O

1\ V

DaiaFlow

\J !!MIll..,

Dis<:CIlIlOCI

UII CalliIlgTennirl.II

uo

hango..,fint

f- f- -

--

--

CaIkd Tcnninal

Ianp..,fint

--

RdeMo ...-

--

UI2 ~

~

Ni/ N/p

-.

. --.---

Dis<:omcct po

N/2

Release

roo- _Release Ccmrldoo

NO

NO -- -- -- -- -- -- IIDi8ccmect - - - - . - - Nil- ...-

--

Release ~Ccml-

U/P UO

ReleaseC_

-.

N/2

-.

N/p NO

.

PXl
NO

-

--

..

UI2 U/P

-- -- ~---_.UD - - --

Dis<:omcct Release

ReleaseC

-.

UII /J(J

roo-

Fig. 4.1 : Procedures voor een circuit-geschakelde verbinding Het proces van laag 3 begint in de UO-toestand. We gaan uit van gebruiker A. Deze

37


gebruiker neemt eerst de hoom van de haak, selecteert de gewenste instantie/persoon uit de opgeslagen gegevens in de tenninal of toetst een nummer in, en kiest evt. een B-kanaal. 'Call control' op laag 4 verstuurt vervolgens een SETUP-REQUEST bericht naar laag 3.

Het proces van laag 3 verstuurt hierop een SETUP-bericht en komt in de Ul-toestand. Het toegekende B-kanaal wordt in het eerst volgende bericht van het netwerk, CALL_PROCEEDING doorgegeven. Het netwerk gaat naar de N3-state. Laag 3 verzendt dan een PROCEEDING_INDICAnON bericht naar Call Control komt in de U3-state.

Het netwerk zoekt vervolgens met behulp van de nummerinfonnatie een route naar de gewenste gebruiker B. Ook op bij gebruiker B moet eerst een betrouwbare verbinding worden opgezet tussen de gebruiker en het netwerk. Hierbij zal het netwerk een SETUPbericht naar de gebruiker versturen. Is de gebruiker B compatibel, d. W.z. kan gebruiker B het gevraagde verbindingstype aan, dan wordt een SEWP_INDICAnON-bericht aan Call control doorgegeven. Laag 3 van gebruiker B gaat dan naar state U6. Als de

gewenste service kan worden geleverd zal Call control het alarmsignaal bij gebruiker B starten en een ALERTING_REQUEST naar laag 3 versturen die vervolgens een ALERTING-bericht verstuurt en in toestand U7 komt. Door

de

ontvangst

van

het

ALERTING-bericht

zendt

laag

3

een

ALERTING_INDICATION bericht naar Call Control en komt ook in de U7 toestand terecht. Call control start nu ook de alannering bij gebruiker A. Zodra gebruiker B de hoom van de haak neemt zal de alannering gestopt worden en een SETUP_RESPONSE-bericht naar het laag 3 proces sturen en vervolgens een CONNECTbericht naar het netwerk. De state die bereikt wordt, is U8. Het netwerk bevestigt dit bericht met een overgang naar state NlO en met een CONNECT_ACKNOWLEDGE aan laag 3 waarop laag 3 een SETUP_COMPLETE_INDICAnON bericht naar Call control stuurt die de verbinding met het betreffende B-kanaal en gebruiker B maakt. De state UlO is nu bereikt Bij het ontvangen van het CONNECT-bericht zal het netwerk ook aan de kant van gebruiker A zorgen voor eenzelfde bericht, zodat gebruiker A ook in de UlO toestand terecht komt. Laag 3 van gebruiker A stuurt hierop een SETUP_CONFIRM naar Call Control zodat deze de alarmering kan stoppen en de connectie met het gekregen B-kanaal kan worden gemaakt. Laag 3 verstuurt nog een CONNECT_ACKNOWLEDGE bericht naar het netwerk zodat ook deze in state N 10 komt. De PCM-gecodeerde spraaksignalen kunnen nu over de verbinding worden verzonden.

38


Deze telefoonverbinding kan nu door gebruiker A of B worden verbroken. We nemen weer aan dat gebruiker A elit doet. De call die zich in UlO bevindt zal door het DISCONNECT_REQUEST-bericht van Call Control in toestand U11 terecht komen waarbij elit laag 3 proces een DISCONNECT-bericht naar het netwerk sturen. Het netwerk zal de call op het gegeven B-kanaal verbreken en een DISCONNECT-bericht naar

gebruiker B versturen. Het netwerk bevindt zich dan in de state NIL Het netwerk stuurt vervolgens een RELEASE-bericht naar gebruiker A en komt in state Nl? Het laag 3 proces van gebruiker A zal door dit RELEASE-bericht, een RELEASE_INDICATIONbericht naar Call Control sturen die dan het B-kanaal vrijgeeft. Ook wordt een RELEASE_COMPLETE-bericht naar het netwerk verstuurd en komt de laag 3 enititeit in de UO toestand. Het netwerk geeft bij ontvangst van elit bericht het B-kanaal vrij en uiteindelijk in de NO toestand terecht komen. Ondertussen is bij gebruiker B het DISCONNECT-bericht binnengekomen. Hierop verstuurt het laag 3 proces een DISCONNECT_INDICATION naar Call Control en in toestand U12 komen, waarop Call Control het betreffende B-kanaal verbreekt en een RELEASE_REQUEST-bericht terugstuurt. Laag 3 verstuurt vervolgens een RELEASEbericht naar het netwerk en komt in toestand U19. Het netwerk zal nu het B-kanaal vrij geven en een RELEASE_COMPLETE naar gebruiker B terugsturen. Het netwerk gaat naar de UO toestand. Het laag 3 proces stuurt Call Control een RELEASE_CONFIRM die op zijn beurt het kanaal vrijgeeft. Het proces gaat naar de UO toestand. De verbinding is nu verbroken. Wordt door gebruiker B de telefoonverbinding als eerste opgeheven dan wordt hetzelfde protocol doorlopen maar moet gebruiker A door gebruiker B vervangen worden en omgekeerd.

4.4

Samenvatting

In elit hoofdstuk hebben we de software ontwikkeling voor het MITEL

srr

interface

besproken. De bestaande ISDN software voor het U-interface (DNIC) van de MITEL kaart is nu zo aangepast dat we tussen beide MITEL kaarten een telefoonverbinding kunnen opzetten via het

srr interface (SNIC). Ook is het nu dus mogelijk hetzelfde srr

interface te gebruiken voor een verbinding met het ISDN terminal board. De aanpassing en

39


verbetering van de benodigde software voor het tenninal board komt pas in het volgende hoofdstuk ter sprake. Na deze aanpassing is pas een telefoonverbinding met het ISDN tenninal board te realiseren. De aanpassing voor de MITEL kaarten bestond uit de verbetering van de protocol timers, het opnieuw initialiseren van het SNIC, de implementatie van het 'Link Activation' protocol en het veranderen van de coooecties in de DX (D-Phone verbinding van het DNIC naar het SNIC). Met behulp van Call Control en het Resource Management kuooen we dan een verbinding opzetten door het versturen van een SETUP_REQUEST naar laag 3. Het verbreken van de verbinding gebeurt met een DISCONNECT_REQUEST. Het opzetten van een telefoonverbinding vergde echter voor de vervanging van het SNIC en het D-Phone IC's enkele minuten. Na de vervanging van de Ie's op een van de MITEL kaarten, omdat er maar een chip set beschikbaar is, kan echter geen telefoonverbinding meer worden gemaakt omdat de filter-codec's van de MITEL kaarten nu verschillen. Het opzetten van een data link verbinding is weI mogelijk, het synchronisatieverlies is verdwenen. Een telefoonverbinding tussen de MITEL kaart met de nieuwe IC's en het tenninal board blijft weI mogelijk omdat beide codec's hier weI gelijk zijn.

40

Software debugging van het ISDN terminal board

5.


De ISDN software voor het tenninal board is grotendeels gelijk aan de ISDN software van de MITEL kaarten voor de PC. Door de vier onderstaande redenen zijn echter in beide versies, bedoeld dan weI onbedoeld een aantal verschillen ontstaan: •

twee verschillende C compilers met hun eigen mogelijkheden

•

het gebruik van de voor MS-DOS geschreven C functies uit de STDIO.H, CONIo.H (b.v. de functies windowO, cprintfO, cscanf())

•

het tegelijk ontwikkelen en vooral het zoeken naar fouten vanfm de software op beide sYStemen

•

verschillen in de hardware

Omdat in het begin het temrinal board nog niet klaar was, werd toen gekozen voor de ontwikkeling van de ISDN software op twee PC's met de MITEL ISDN Express kaarten. Voor het schrijven van de software werd de TURBO C-compiler gebruikt die prima voldeed. Later werd deze vervangen door een nieuwere versie TURBO-C++ compiler waarbij de extra en nieuwe C++ functies en structuren werden venneden om toch zoveel mogelijk compatibel te blijven met de ANSI-C definities. Toen het tenninal board klaar was en met behulp van de INTEL In-Circuit-Emulator in gebruik werd genomen, moest vanwege deze emulator ook de INTEL C-compiler [12][13] worden gebruikt. Het is dan mogelijk om van de 'object' files van de C-compiler en linker een absolute en niet'relocatable' 80186-code te creeren waarbij nog altijd voor het debuggen de gebruikte variabelen-namen aanwezig zijn. We kunnen deze code vervolgens in de In-CircuitEmulator laden en de nieuwe software zeer gemakkelijk testen en debuggen door het gebruik van deze namen. Omdat de WRBO C-compiler een ander fonnaat voor de 'object' files gebruikt kunnen we deze code niet gebruiken voor de ICE. De problemen die door het gebruik van twee compilers ontstonden, zullen in de volgende twee paragrafen besproken worden. Ook zijn door verschillen in de ISDN chip sets programmeer fouten ontstaan, die nog niet waren verwijderd. Deze fouten worden in de laatste paragraaf behandeld.

41


5.1

Verschillen tussen de Intel C en Turbo C++ compiler

Zoals in de inleiding van dit hoofdstuk al werd gezegd, zijn door omstandigheden uiteindelijk twee compilers in gebruik: een voor het PC gebaseerd ISDN systeem en ren voor het ISDN terminal board. Het grootste verschil tussen de TURBO C++ compiler en de INTEL compiler is dat de TURBO C++ een geYntegreerde editor, compiler, linker en debugger is terwijl bij het INTEL systeem de editor, compiler, linker en debugger los van elkaar vanuit MS-DOS moet worden gebruikt. Het mag duidelijk zijn dat met een compleet geintegreerd systeem gemakkelijker en sneller kan worden gewerkt. Het grootste nadeel van de TURBO C compiler is het ontbreken van speciale C startup en exit-codes voor een 'embedded system'. Het is dan zeker niet aan te raden om de normale gegenereerde C code voor de PC te gebruiken voor zo'n non-MS-DOS omgeving of 'embedded system' zoals het ISDN terminal board. Door het ontbreken van de PC ROM routines en door het ontbreken van de Operating System routines die voor de juiste communicatie met de randapparatuur zorgen, zal de software vastlopen zodra een van die functies wordt aangeroepen. De C-functies die uiteindelijk voor deze systeem afhankelijke codes zorgen zijn niet allemaal bekend. Voor enkele functie is dit weI duidelijk. Deze zijn namelijk speciaal voor de PC randapparatuur geschreven en bevinden zich vooral in de bijgeleverde standaard C files STDIO.H (STanDard Input/Output) en CONIO.H (CONsole Input/Output). Deze functies moeten we dus bij de PC-versie van de ISDN software, dus bij de software voor de MITEL kaarten zo weinig mogelijk gebruiken om later geen conversieproblemen te creeren bij het ISDN terminal board Helaas is dit niet in acht genomen, de op de PC ontwikkelde ISDN software maakt gebruik van de standaard afdruk- en toetsenbordroutines die bij alle C compilers als bibliotheek, geoptimaliseerd en aangepast voor het specifieke systeem waarop de software draait, wordt meegeleverd. Vooral de Monitoring Dispatcher en het Call Control systeem maken gebruik van het speciale door Borland, leverancier van TURBO C, ontwikkelde 'window' systeem voor tekst. Bij de conversie van de ISDN software naar het ISDN terminal moesten nu eerst alle afdruk- en toetsenbordfuncties vervangen worden door zelf geschreven routines die via het RS232 interface van de IDPC met behulp van ANSI-codes het beeld van een terminal kunnen aansturen en het toetsenbord van de terminal kunnen aflezen. Het window-systeem

42


waarop de Monitoring Dispatcher bij de MITEL kaarten is gebaseerd moest geheel herschreven worden tot een systeem zonder windows. Dit is uiteindelijk door E.J.E.T. Boonnans [11] gedeeltelijk gedaan. Echter werken enkele van de al omgezette functies niet goed omdat deze niet afdoende getest konden worden door het ontbreken van een werkende S-bus.

Om deze conversieproblemen in de toekomst te vennijden is er nu een window systeem voor het terminal board ontwikkeld (zie hoofdstuk 6) dat alleen gebruik maakt van een 'standaard' afdrukroutine en een toetsenbordroutine. Een ander probleem dat zich voordoet zijn de beschikbare compiler opties. De TURBO Ccompiler kan 'case-sensitive' compileren en linken. En deze mogelijk is dus ook vele malen gebruikt bij het verzinnen van variabelen en type definities. Een goed voorbeeld hiervan is in het onderstaande stukje programma te zien. struct process

*dp;

struct process

DP;

struct process

Process[MAXPROCJ;

struct state struct state

*PointParser; POINTPARSER;


*PointPc; POINTPC;

struct Dscstruc

*DscRam;

struct Dscstruc

DSCRAM;

struct ram

Ram;

struct ram

RAM;

/* #MR comment, never used */

Deze manier van benoemen leidt tot fouten en onduidelijkheden. Vooral als er voor de data structuur van de variabele 'state' ook nog eens de onderstaande type definitie wordt gebruikt. typedefstruct state state;

De TURBO C-compiler compileert en linkt dit soort programma structuren zonder moeite ook als aIle fout-herkenningsroutines aan worden gezet. De INTEL C-compiler heeft

43


echter geen 'case-sensitive' optie. AIle namen, op welke manier ze ook geschreven zijn, zijn hetzelfde, dus: isdn = Isdn

= ISDN,

enz.. Indien dan bij de INTEL C-compiler het

foutendetectieniveau op standaard blijft staan (diagnostic(1)) worden enkele fouten die op deze manier ontstaan niet opgemerkt, daarintegen ziet de optie 'diagnostic(O)' weI de nieuwe, vreemde variabelen toekenningen en vooral de dubbele variabele defmities. Beide compilers Iaten weI toe dat voor een variabele en een type definitie eenzelfde naam wordt gebruikt, dus: struct ram

ram;

is weI toegestaan maar Ievert een slecht te volgen en te debuggen programma op. Het Ieidt tot fouten en overbodige declaraties. Een oplossing voor het dubbele variabelen probleem wordt in de volgende paragraaf gegeven. Ben tweede compiler optie die voor conversieproblemen zorgt is de ROM optie van de INTEL compiler. Deze optie hebben we nodig omdat we uiteindelijk willen dat de software in een (EP)ROM wordt gezet. Door de ROM optie zijn C constructies die automatisch de variabelen initialiseren niet toegestaan [12]. AIleen constanten mogen tijdens de declaratie worden gei"nitialiseerd. Dit moet dan extra worden aangegeven. Ook dit wordt in het volgende hoofdstuk belicht.

5.2

Conversiefouten

In de voorgaande paragraaf hebben we al opgemerkt dat de INTEL C-compiler niet 'casesensitive' kan compileren en daardoor o.a. dubbele variabele declaraties ontstaan. De heer E.J.E.T. Boormans [11] heeft deze dubbele declaraties opgelost door een van de declaraties te verwijderen. Hij was van mening dat een dubbele verwijzing voor de structures overbodig was, dus : struct bearercap *AudioCap; struct bearercap AUDIOCAP; AudioCap

= &AUDIOCAP;

44


werd omgezet in: struct bearercap

*AudioCap,.

AudioCap->injo[Oj

=...

De dubbele verwijzing naar een structure is inderdaad niet nodig, maar de gebruikte oplossing is helemaal fout. De C-compilers kunnen het juiste gebruik van pointers ook niet opsporen of controleren zodat dit soort fouten dan ook moeilijk te vinden zijn.

Op de bovenstaande manier worden aile pointers die op deze manier zijn behandeld, dus alle dubbele pointer variabelen, niet geYnitialiseerd en kunnen dus overal naartoe verwijzen. Een toekenning aan een variabele uit deze structuur, zoals het info[O] veld, kan dus overal in het geheugen terecht komen en zo het programma op onverklaarbare wijze plotseling laten vastlopen. Tevens wordt op deze manier nergens een stukje geheugen gereserveerd voor de data-structuur. Als we al van een enkele verwijzing gebruik willen maken, moet dit op de volgende rnanier gebeuren: struct bearercap AUDIOCAP; &AUDIOCAP->injo[Oj

=...

of: AUDIOCAP.injo[Oj

=...

We moeten dan iedere pointer in het programma gaan veranderen. We kunnen dus beter een andere oplossing zoeken. Een standaard of vaste manier voor de constructie van een variabele-naam biedt in dit geval een mogelijke oplossing. We kunnen bijvoorbeeld namen voor pointers laten eindigen op '..Ptr' of de namen voor structures laten eindigen op '...struct'. Bij de eerste methode moeten we echter weer in het gehele programma de pointers gaan veranderen. Omdat de naam van de structure slechts tweemaal in het programma voorkomt, bij het definieren van het datagebied voor de structure en bij de initialisatie van de bijbehorende pointers, veranderen we de namen van de structures. De desbetreffende programmadelen

45


die hieronder staan venneld zijn op die rnanier aangepast •

•

GLOBAL.C (zie bijlage 4):

struct process

*dp;

struct process

DPstruct;

struct state

*PointParser;


POINTPARSERstruct;

struct state

POINTPCstruct;

struct Dscstruc

*DscRam;

/* Pointer to structure

struct Dscstruc

DSCRAMstruct;

/* Create structure space */

*PointPc; */

L3GLOBAL.C:

struct callentity

*cp;

struct callentity

CPstruct;

struct infooctet

*sendcomp;

struct infooctet

SENDCOMPstruct;

struct infosmall

*cause, *callid, *caltstate,*chanid, *progind;

struct infosmall CAUSEstruct, CALLIDstruct, CAUSTATEstruct; struct infosmall CHANIDstruct, PROGINDstruct; struct addrsinfo *cldparnr, *cldparsa, *clgparnr, *clgparsa; struct addrsinfo

CWPARNRstruct, CWPARSAstruct;

struct addrsinfo CLGPARNRstruct,CLGPARSAstruct; struct bearercap *NotPresent; struct bearercap NOT_PRESENTstruct; struct bearercap *SpeechCap; /* Bearer capability for speech coding */ struct bearercap SPEECHCAPstruct; struct bearercap *AudioCap; /* Bearer capability for 3.1 kHz audio */ struct bearercap AUDIOCAPstruct; struct bearercap *Urdat1Cap; /* Bearer capability for unrestricted digital info type 1 */ struct bearercap URDATI CAPstruct;

46


struct bearercap *Urdat2Cap; /* Bearer capability for unrestricted digital info type 2 */

struct bearercap URDAT2CAPslruct; struct bearercap *bearcap; struct bearercap BEARCAPstnu:t; De initialisaties van de betreffende pointers worden dan weer in de initialisatieroutines teruggezet: •

INITPROC.C:

PointParser = &POINTPARSERstruct; /* #MR comment, Initialize pointers to declared data structures in memory */ dp =&DPstruct; PointPc =&POINTPCstruct; DscRam =&DSCRAMstruct; •

L3_INIT.C: cp

sendcomp cause callid call_state chanid progind cldparnr cldparsa clgparnr clgparsa bearcap NotPresent SpeechCap AudWCap UrdatlCap Urdat2Cap

=&CPstruct; =&SENDCOMPstruct; =&CAUSEstruct;

=&CALLIDstruct; = &CALLSTATEstruct; =&CHANIDstruct; =&PROGINDstruct; = &CWPARNRstruct; =&CWPARSAstruct; =&CLGPARNRstruct; =&CLGPARSAstruct; = &BEARCAPstruct; =&NOT_PRESENTstruct; =&SPEECHCAPstruct; = &AUDIOCAPstruct; =&URDATICAPstruct; =&URDAT2CAPstruct;

47


Een iets ander probleem treedt bij de IDPC subroutines op. Dit is in het onderstaande stukje te zien (lNITIDPC.C): extern struct idpc (far *IDPC); void/ar idpc_init(byte idpc) (

i/(idpc==O) IDPC=IDPC_BASE1; }

We zien dat drie maal dezelfde naam voor een andere soort variabele wordt gebruikt. De 'IDPC' pointer naar de 'idpc' structure kan worden gehandhaafd, maar de procedureparameter moet worden verandetd. We maken van de parameter 'idpc' 'idpcnr' en passen dit toe op de volgende subroutines: • • •

idpc_initO in INITIDPC.C idpc_controlO in INmDPC.C idpc_ram_initO in INITRAM.C

• idpcintO in INT_IDPC.C Een andere melding die door de INTEL C-compiler in diagnostic mode 0 wordt gegeven, is de 'Suspicious pointer conversion'. Deze melding hoeft geen problemen te geven bij de software maar het oplossen van deze foutmelding is toch verstandiger. Hij wordt veroorzaakt door de onderstaande constructie waarbij een vet gedrukte 'const' wordt vergeten: const struct test const struct test

ABeD ...; *TestPtr;

TestPtr = &ABCD;

We kunnen dan door het gebruik van de fout-gedefinieerde pointer 'TestPtr' toch nog de constante structure veranderen. Omdat de INTEL C-compiler door de ROM optie alle

48


constanten in het ROM plaatst, zal in ons geval geprobeerd worden naar het ROM te schrijven. We veranderen dus voor de zekerheid alle voorkomende gevallen:

• • • •

const struct statecodefar *Search in L3_AUXn...C const struct state far *CallState in L3_INIT.C en L3_INTER.C const struct state *TableState in TERMDISP.C const struct state *Auxstate in TERMFUNC.C

Om verdere conversiefouten te voorkomen, is de prototyping van functies en variabelen nit de vele 'include/header'-files gehaald. Ieder programmaonderdeel of file begint dan nu ook op de volgende manier: •

Omschrijving van het betreffende software-onderdeel

•

Include en header files, waarbij de eigen ISDN files nooit verdere files inladen en gebruiken

5.3

•

Prototyping van de functie(s) in dit programmagedeelte

•

Declaratie van de global variabelen

•

Prototyping van de externe functies die in dit gedeelte gebruikt worden

•

Declaratie van de exteme variabelen die in dit gedeelte gebruikt worden

•

De functie(s) van dit programma onderdeel

Fouten in de low-level device drivers

Door de verschillen in de hardware met enerzijds de PC met de MITEL kaarten (zie hoofdstuk 3.1) en anderzijds het tenninal board met zijn speciale componenten (zie hoofdstuk 3.2), moesten er voor het tenninal board andere low-level drivers geschreven worden. Deze konden nog niet goed getest worden door het ontbreken van een S-bus verbinding. Tijdens het testen van de eerste verbinding over de S-bus tussen de MITEL kaart (in de NT-mode) en de tenninal board kwamen de eerste fouten in de low-level drivers naar voren. Een van de fouten was de (random) weigering om de S-bus te activeren. Bij de bestudering van de initialisatie-routine en de datasheets [17] bleek dat er niet werd gewacht (minirnaal 250 Jls) na het aanzetten van de ontvanger van de DSC en niet werd gekeken naar de toestand van de LIU als een 'activation request' werd gegeven. Het aanzetten van de ontvanger en het 'activation request' werd door een schrijfoperatie tijdens

49


het opstarten in het LID Mode Register [17] geschreven. Verder werd er meteen een interrupt door de DSC gegenereerd na het opstarten van de software omdat na verwijderen van alle interrupts door het lezen van de interrupt registers, nogmaals in een andere initialisatieroutine een gedeelte van de DSC weer werd gei"nitialiseerd. De interrupts werden vervolgens niet verwijderd. Door het optreden van dit interrupt werd random data in de D-kanaal FIFO werd geschreven. In totaal werden er drie losse initialisatieroutines voor de DSC gebruikt, een voor de DSC

in het algemeen, een voor het DLC-gedeelte en een voor het LIU-gedeelte. In deze routines werden verschillende registers tweemaal gei"nitialiseerd. Er is daarom een nieuwe routine geschreven die de onderstaande initialisatie procedure doorloopt: •

Reset van de registers door de DSC idle mode

•

Activeren van de ontvanger

•

Wacht minimaal250 J.ls

•

Bekijk de toestand van de LIU en wacht totdat deze goed is. (State F3, F6 of F7, zie 1.430 [2])

•

Geef 'Activation Request'

•

Initialiseer de overige DSC registers

•

Verwijder alle mogelijk status en interrupt bronnen door het lezen van de interrupt en statusregisters: DSR1, DSR2, DER, LSR. [17]

De eerste problemen werden hierdoor opgelost maar tijdens het debuggen kwam een ander interrupt probleem aan het licht. In de speciale startup-code CSTART.ASM) geschreven in assembler door H. Oudelaar [4]/IBeijnsberger [6] werd een andere interrupt-tabel opgezet dan de interrupt-tabel die bij de vele testprograrnma's [5] gebruikt werd. De startup-code zette een interrupt-tabel op die gebruik maakte van door INTEL gereserveerde interrupt-nummers en niet van de voor de gebruiker gereserveerde interrupt-nummers (32 en hoger). Tevens werd in de startupcode de segment-registers DS, ES en SS gelijk aan 0 gesteld, zodat parameters voor de segment-indeling die aan de locater-utility werden meegeven niet werkten. Het kan dan voorkomen dat het programma vastloopt zodra de stack door het datagebied begint te lopen of als er data in de stack wordt geschreven. Ook werden de libraries van de Ccompiler niet geinitialiseerd zodat functies uit deze C-libraries fout konden gaan. Om dit probleem op te lossen, is besloten de standaard 'embedded' startup-code te

gebruiken van de INTEL C-compiler. Hierdoor zal in ieder geval geen probleem ontstaan

50


met eventuele C-functies, standaard input/output functies blijven natuurlijk verboden. Het opzetten van de interrupt-tabel kuooen we doen met een speciale INTEL compiler functie en zogenaamde 'pragma' functies: setinterrupt( interruptnr, interrupt_routine_abcd) : deze functie koppelt de

•

'interrupt-routine_abcd',

met

behulp

van

de

onderstaande

'pragma'

gedeclareerd, aan interrupt-nummer 'interruptnr'. #pragma interrupt( int_routine_l, int_routine_2, •..) : door het vennelden

•

van de naam van de interruptroutine in deze pragma-functie, weet de compiler dat de genoemde functie speciaal moet worden voorbereid voor dat doel ( uitschakelen en inschakelen van de interrupts, beveiligen van de registers, enz.) We kunnen deze functies vergelijken met resp. de TURBO C functies: setvect(interruptnr, interrupt_routine_abcd) het interrupt keyword dat bij de defmitie van een interrupt functie gebruikt

• •

moet worden De nieuwe interrupt instellingen staan in de file INTSETUP.C. Zodra de verbinding goed kon worden opgezet ontstond er een probleem met het verzenden van het tweede protocol frame. Deze bevatte random-data die vervolgens niet door de NT herkend kon worden als een toegestaan protocol frame. Een simpele toevoeging die ervoor zorgt dat er niet teveel bytes in de FIFO wordt geschreven, moet in zendO-routine worden toegevoegd (XMTBUFF.C). Deze routine vult als eerste de 8-bytes FIFO buffer van het D-kanaal in de DSC, waarna de interrupt routine het eventueel ovemeemt om de aanvullende bytes naar de FIFO te sturen. void zenden(void) { while ((DSC->DSR2 & TBE) && (DscRam->xmtcnt!= 0)) { /* #MR changed, counter added */

DSC->DCTB_DCRB

= *(DscRam->xmtnext++);

DscRam->xmtcnt--; }

DSC->CRJR

=DTCR;

= (byte)(DscRam->xmtpktsz & OxfJ); DSC->DR = (byte)((DscRam->xmtpktsz » 8) & Oxjf);

DSC->DR

51


/* transmission started */ }

Tijdens het testen van de data link verbinding op laag 2 kwam het een enkele keer voor, dat de protocol monitor maar een gedeelte van een bericht of frame naar de ANSI-terminal doorstuurde. Tijdens het onderzoeken van de IDPC en USART routines kwamen we de volgende problemen tegen: •

verkeerd index gebruik voor de terminalbuffer voor het lezen en schrijven van data in de interrupt-routine. Een zelfde soort fout is ook in de afdruk en toetsenbordroutines geslopen, die echter geheel vervangen zijn door het window-systeem. De interruptroutine wordt als voIgt hersteld: - usart_int() in USART.C: case Ox04: /* Receive FIFO threshold reached */ while ((IDPC->usartLSR & OxOl)

== OxOl) (

outbyte(Ox2000,Oxfj); /* Terminal[Termcount++ % MAXTERM] */

Tenninal[Tenncount] =IDPC->usartfifo; Tenncount = (Tenncount++) % MAXTERM; Lengthterm++; i/((IDPC->usartLSR & OxOe) /= 0) ( outbyte(0x2002,Oxfj); haZt(); } }

break;

•

niet gemtialiseerde en gedeclareerde structures die in de onderstaande files werden toegevoegd: -GLOBAL.C: struct idpcdf *IDPCDEF[2];

struct idpcdf IDPCDEFO, IDPCDEFI; /* #MR added */ - INITPROC.C:

52


IDPCDEF[Oj = &IDPCDEFO; /* #MR added */ IDPCDEF[lj =&IDPCDEF1; Verder zijn nog tijdens het debuggen van de bovenstaande problemen de volgende fouten gevonden en verbeterd: •

INITPROC.C, pointer initialisatie:

DMAram[Oj = &DMAramO; /* #MR added, pointers in DMAram were never initialised (not used yet!) */ DMAram[IJ = &DMAram 1; •

INITPROC.C: Het process MONITOR dat werd geiilitialiseerd is verwijderd omdat het niet wordt gebruikt maar vooral omdat de array dimensie wordt overschreden.

•

DSCRAMIN.C:

1* DscRam->rcvfree =DscRam->rcvbuff= &RamBuffer[DscRam>rcvrefnoJ.info[OJ,o */ DscRam->rcvfree =DscRam->rcvbuff= &RamBuffer[DscRam>rcvrefnoJ.info[1 J,o

5.4

Samenvatting

In dit hoofdstuk is beschreven hoe de ISDN software is gedebugged. De fouten in de

ISDN software voor het terminal board maakten het onmogelijk om een laag 2 verbinding te maken met de MITEL kaart via het Srr interface. De fouten waren vooral ontstaan door het gebruik van twee verschillende C compilers en door de twee verschillende ISDN systemen. Nu deze fouten verbeterd zijn, is het mogelijk om een laag 2 verbinding te maken tussen een MITEL kaart en het ISDN terminal board. Om een telefoonverbinding te kunnen opzetten hebben we echter nog de Call Control en het Resource Management nodig. Deze functies worden in het volgende hoofdstuk gerealiseerd. Ook zullen we een betere protocol monitor implementeren.

53

Software ontwikkeling t.b.v. het ISDN terminal board

6.


Het is nu mogelijk om een verbinding op te zetten over het S/T-interface vanaf laag 2 van het OSI-model tussen het MITEL systeem en het ISDN terminal board. Om nu een telefoonverbinding te kunnen maken, moeten we de Call Control en het Resource Management voor het terminal board omzetten en aanpassen voor de AMD ISDN IC's. Dit wordt in de volgende paragraaf uitgelegd. Daarnaast ontbreekt de uitgebreide protocol monitor die bij de Mitel kaarten wordt gebruikt ter controle van de protocollen en die het zoeken naar fouten vergemakkelijkt. Omdat beiden, Call Contro]JResource Management en de Protocol Monitor, op de PC veel gebruik maken van de standaard PC input/output bibliotheken en gespecialiseerde window functies van TURBO C voor het weergeven en controleren van de processen, berichten, frames, IC registers, enz., leek het gemakkelijker om een TURBO C-compatibel window systeem te ontwerpen voor het tenninal board zodat de Protocol Monitor van de PC vrijwel zonder moeite kan draaien op dat board. Dit ontwerp komt in de laatste paragraaf aan de orde.

6.1

Call Control en Resource Management

De implementatie van de Call Control protocollen voor het opzetten en verbreken van een telefoonverbinding is door J.R.H. Claessens [10] op de MITEL kaarten gerealiseerd via het U-interface. Als we de laag 4 software bekijken dan bevinden zich alle hardware afhankelijke Call Contro]JResource Management programma onderdelen in de file L4_PHONE.C. De andere vier fIles, L4_ST.C, L4_TE_TR.C, L4DEFINE.C en L4GLOBAL.C, moeten alleen aan de INTEL C-compiler worden aangepast. De belangrijkste verandering in deze laatste files zijn: •

een extra header fIle met de laag 4 constanten en defmities: L4DEFINE.H

•

L4_ST.C: de automatische initialisatie van de ISDN nummers moet worden omgezet naar een initialisatie in INITPROC.C vanwege de ROM optie van de Intel C compiler:

54


1* Initialize TEINI' numbers *1 TEnumber[Ol=1;TEnumber[11=1;TEnumber[21=2; TEnumber[31=2;TEnumber[41=3;TEnumber[51=3; TEnumber[61 =99; 1* #RCneW# number ofTE (99=Ox63 marks end of number) *1 NI'number[Ol=4; NI'number[ 11=4; NI'number[21=5; NI'numbe~31=5;NTnumber[41=6;NTnumber[51=6;

NI'number[61=99; 1*#RCneW# number ofNT (99=Ox63 marks end ofnumber) *1 TESAnumber[Ol=l,. TESAnumber[11=99; 1* #RCneW# subaddress number ofTE (99=Ox63 marks end of number) *1 NI'SAnumber[O1=1; NI'SAnumber[11=99; 1* #RCneW# subaddress number ofNT (99=Ox63 marks end of number) *1

De aanpassing van functies uit de L4_PHONE.C file bestaat uit twee gedeelten: het belsignaal (de alannering), het schakelen van de B-kanalen. Met de DSP van het MITEL D-Phone interlace is het mogelijk om een tweetonig belsignaal te genereren, de DSC van AMD kan alleen maar een enkel toon voortbrengen.

De volgende aanvullingen op het programma zijn voor dit belsignaal: •

Initialisatie van de toongenerator door de functie SecAlertingO voidfar Set Alerting(void) (

disable();

/* #MR comment, protect command register */

DSC->CR_IR = INIT;

/* turn on MAP */

DSC->DR =((DSC->DR & Oxic) I ACTIVE_MD); /* set Tone Ringer Frequentie to 800 Hz */ DSC->CR_IR = FTGR; DSC->DR =Ox34; DSC->DR = 0x34;

/* Not used by Tone Ringer */

DSC->CR_IR = ATGR;

/* Set amplitude Tone Ringer (OdB) */

DSC->DR =OxlO;

/* Not used by Tone Ringer */

DSC->DR =OxlO;

55


enable(); Start_Alerting(),o }

•

Het starten van het belsignaal door de functie Start_AlertingO

void far Start_Alerting(void) (

start_alerting =1; /* #MR comment, protect command register */ disable(); /* enable tone ringer */ DSC->CR_IR =MMR2; DSC->DR =(DSC->DR I EN_RING); enable(); if (horn_timer_running ==0) ( runtimer(Timeout_indication,CAUCTRL,Tring); horn_timer_running = 1; }

}

•

Het stoppen van het belsignaal door de functie Stop_AlertingO

voidfar Stop_Alerting(void) (

start_alerting =0; /* #MR comment, protect command register */ disable(); /* disable tone ringer */ DSC->CR_IR =MMR2; DSC->DR =(DSC->DR & OxEF); enable(); if (horn_timer_running = = 0) ( runtimer(Timeout_indication,CAUCTRL,Tring); horn_timer_running = 1; } }

•

Het beeindigen van het belsignaal door de functie End_AlertingO

voidfar End_Alerting(void) {

start_alerting = 0;

56


stoptmr(Timeout_indication,CALLCTRL); horn_timer_running = 0;

disable(); /* #MR comment, protect command register */ DSC->CR_IR = MMR2; /* disable tone ringer */ DSC->DR = (DSC->DR & OxEF); enable(); }

Het schakelen van de B-kanalen gebeurde bij de MITEL kaarten door de functies Make_B_connectionO en Make_B_disconnectionO die de DX programmeerden. Bij de DSC van AMD zijn maar maximaal drie circuit-geschakelde verbindingen mogelijk met 8 bidirectionele 64 kbit/s kanalen. Het interface kan dus veel gemakkelijker geprogrammeerd worden. De eerder genoemde functies vervallen dan ook zodat we voor het schakelen van de B-kanalen de onderstaande functies overhouden: •

Het maken van de verbinding tussen het MAP interface en het juiste B-kanaal op de Sbus met de functie SecConnectedO

voidfar Set_Connected(byte channel) (

hornpickedup

=0;

End_Alerting();

if (channel == 1) ( disable(); DSC->CRjR

/* #MR comment, protect command register */

= MCR1;

=Ox13; /* Conne.ct UU B1 (Ox1) with MAP (Ox3) */ DSC->CRjR =LMR1; DSC->DR = (DSC->DR / B1_ENABL); DSC->DR

enable(); }

else ( disable(); /* #MR comment, protect command register */ DSC->CRjR

= MCR2;

= Ox23; /* Connect LIU B2 (Ox2) with MAP (Ox3) */ DSC->CRjR =LMR1; DSC->DR = (DSC->DR / B2_ENABL); DSC->DR

57


enable(); } }

•

Bet verbreken van het opgegeven B-kanaal en het MAP interface door SecDisconnectedO byte far Set_Disconnected(void) ( if(Param_6 == 1) ( disable();

/* nMR comment, protect command register */

DSC->CRjR DSC->DR

= MCR1;

= OxOO;

/* Disconnect MAP and LIU B1 */

DSC->CRjR =LMR1; DSC->DR = (DSC->DR & OxFE);

/* Disable llU B1 */

enable(); }

else ( disable();

/* nMR comment, protect command register */

DSC->CRjR DSC->DR

= MCR2;

= OxOO;

/* Disconnect MAP and llU B2 */

DSC->CRjR =LMR1; DSC->DR

= (DSC->DR & OxFD);

/* Disable llU B2 */

enable(); } }

6.2

De Window-Protocol-Monitor voor een ANSI terminal

De Protocol Monitor van de MITEL kaarten en Call Control maken beide gebruik van zogenaamde tekst windows. Voor deze tekst windows zijn in TURBO C verschillende functies beschikbaar die echter niet door INTEL C worden ondersteund. Deze zijn dan

58


ook helemaal niet beschikbaar voor het terminal board Voor een window systeem moeten we directe toegang hebben tot het videogeheugen zodat characters die naar het beeldscherm zijn geschreven ook weer terug kuooen worden gelezen. Deze optie hebben we nodig, als we willen voorkomen dat een nieuw window de op het beeldschenn aanwezige tekens zal uitvegen. De tekens die door dit nieuwe window zijn uitgeveegd zijn dus verloren gegaan. Door nu voor de creatie van het nieuwe window de characters terug te lezen en in een ander datagebied te bewaren kuooen we later het oude beeldschenn weer herstellen. Deze directe toegang tot het beeldschenn wordt door het gebruik van een RS232 verbinding en terminal programma onmogelijk gemaakt. We kuooen dit echter omzeilen door in het geheugen van het terminal board een copy van het schenn te bewaren. Het wordt dan weI mogelijk een window systeem te bouwen voor het ISDN terminal board als we dan ook gebruik maken van het ANSI-code systeem. Dit systeem maakt gebruik van zogenaamde 'ESCAPE sequences' om speciale functies voor het schenn/cursor te realiseren, b.v.: •

ESC [K

: Veeg regel uit vanaf de cursor

: Plaats de cursor op x,y positie 1,1 (links-boven) Alle functie die in de MITEL software worden gebruikt bij de Protocol Monitor en Call Control en zorgen voor het 'opbouwen' van het schenn en het uitlezen van het toetsenbord zijn uiteindelijk gerealiseerd. Er zijn echter een aantal verschillen met de TURBO C functies (zie ook de help functie van de TURBO-C++ compiler) die in acht moeten worden gehouden: •

ESC [l;lH

•

de onderstaande functies zijn gerealiseerd: •

void cursor(int status) : schakel de cursor aan of uit.

•

void clreol(void) : Veeg de huidige regel vanaf de cursor tot aan het einde van een tekstwindow uit.

•

void clrscr(void) : Veeg een tekstwindow uit.

•

void gotoxy(int x, int y): Ga naar de positie x,y in een tekstwindow. (l,lligt links-boven)

•

void gettextinfo(struct text info *current) : Haal de infonnatie over het tekstwindow op.

•

void textattr(int newattrib) : Zet de kleur-attributen van een tekstwindow.

•

void textbackground(int color) : Zet de achtergrondkleur op 'color'.

59


•

void textcolor(int color) : Zet de tekstkleur op 'color'

•

int getch(void) : Haal een karakter op van het toetsenbord.

•

int ungetch(int ch) : Stop een karakter terug in de toetsenbordbuffer.

•

int getche(void) : Haal een karakter op van het toetsenbord en laat dit karakter op het schenn zien.

• •

int kbhit(void) : Wacht totdat een toets wordt ingedrukt. void window(int left, int top, int right, int bottom) : Defmieer een tekstwindow m.b.v. de linkerboven hoek en de rechteronder hoek.

•

int wherex(void) : Vraag de x coordinaat van de cursor op.

• • •

int wherey(void) : Vraag de y coordinaat van de cursor op. void insline(void) : Voeg een regel toe op de plaats van de cursor. int gettext(int left, int top, int right, int bottom, void *dest) : Sla alle tekst op, in het door de pointer aangewezen gebied, die zich bevindt in de rechthoek met de linkerboven hoek left,top (xl, yl) en rechteronder hoek right,bottom (x2, y2).

•

int puttext(int left, int top, int right, int bottom, void *src) : Plaats de opgeslagen tekst (met gettextO) weer op het schenn.

•

int movetext(int left, int top, int right, int bottom, int destleft, int desttop) : Verplaats de tekst in de rechthoek met de hoeken left, top (xl, yl) en right, bottom (x2, y2) naar een rechthoek van gelijke grote met een linkerboven hoek op destleft, desttop (x3, x4)

•

• void delay(unsigned Msec) : Wacht Msec milliseconden. alle gerealiseerde functies hebben dezelfde parameters nodig als de TURBO C functies

•

sommige van de bovengenoemde functies zijn echter beperkt in hun mogelijkheden t.O.v. de TURBO C functies, maar alle mogelijke aanroepen die in de MITEL software worden gedaan, kunnen door de functies goed afgehandeld worden.

•

de gebruikte cprintfO, printfO, vsprintfO, putsO, enz. zijn sarnengevoegd tot een functie primO. AIle print-comrnando's moeten door 'print(...)' worden vervangen. De declaratie is als voIgt: void

•

print(const char *Msg, .••);

de gebruikte cscanfO, scanfO, enz. zijn samengevoegd tot een functie scanO.

60


AIle scan-commando's moeten door scan(..) worden vervangen. De declaratie is als voIgt:

•

int scan(char *Msg, ...) : Haal een string op uit de toetsenbord buffer (de software buffer en niet de FIFO buffer van de IOPC).

•

alleen voor het gebruik in nieuw te creeren functies voor het window systeem zijn de volgende functies die rechtstreeks naar de terminal buffer (de software buffer en niet de FIFO van de IDPC) schrijven:

•

int strput(const char *MsgString) : Schrijf een complete string naar de buffer

•

int charput(int ch) : Schrijf een enkel karakter naar de buffer.

Met behulp van de bovenstaande functie is nu de MITEL monitoring dispatcher omgezet naar het terminal board. door alleen de print- en scan aanroepen te vervangen. Omdat niet ieder optie van de MlTEL monitor geschikt is voor het terminal board zoals o.a. het bekijken van de MITEL hardware registers of de 'Quit' mogelijkheid, zijn enkele van deze opties aangepast aan het ISDN tenninal board. De nieuwe functies staan in bijlage 2.

6.3

Samenvatting

In dit hoofdstuk is de implementatie van de Call Control en Resource Management protocollen voor het ISDN terminal board besproken. Deze moesten worden aangepast aan de AMD hardware. Dit gebeurde in de functies: SeLAlertingO, Start_AlertingO, Stop_AlertingO, End_AlertingO voor het belsignaal en in de functies: SeCConnectedO en SeLDisconnectedO voor het doorschakelen van het telefoonkanaal. Verder is voor een betere controle en aansturing van de protocollen en hardware, de MITEL protocol monitor geconverteerd naar het ISDN terminal board met behulp van geemuleerde TURBO-C functies. Het is nu mogelijk om over het Sff-interface een telefoonverbinding op te bouwen tussen een MITEL kaart en het ISDN terminal board. We moeten dan weI op de MITEL kaart het D-Phone IC vervangen door een nieuwe versie. De oude versie bevatte namelijk een filter codec dat gebruik maakte van een Il-law code die ten opzichte van de standaard code van het CCITT gemverteerd was.

61

Conclusies en aanbevelingen

7.


Voordat mijn afstudeerwerk begon was het niet mogelijk om met de bestaande ISDN software voor de MlTEL ISDN Express kaarten, een telefoonverbinding op te zetten over het Sff interface. De bestaande implementatie via het U-interface is niet ISDN compatibel doordat voor dit referentiepunt geen CCITI Recommendations zijn uitgegeven. Dit vanwege de implementatie verschillen bij de NT! functie van het User-Network-interface in de Verenigde Staten en in Europa. Omdat de ISDN software van het ISDN tenninal board niet compleet was, Call Control/Resource Manager en Protocol Monitor waren niet of slechts gedeeltelijk gei"mplementeerd, kon men ook hier niet met het Sff-interface experimenteren. We zijn begonnen met de MlTEL kaarten. De ISDN software is hier volledig aangepast aan het Sff-interface door het veranderen van de hardware initialisatieroutines en het omleggen van de datastromen in de Call Control en Resource Manager. Het is nu mogelijk om een telefoonverbinding te maken tussen beide MITEL kaarten over het SNIC interface (het MITEL Sff-interface) in plaats van de DNIC (het MITEL Uinterface). Door het meegeven van de constanten 'SNIC' of 'DNIC' tijdens het compileren kan een keuze tussen beide interfaces worden gemaakt We moeten hierbij weI van de error correctie mogelijkheden van laag 2 gebruik maken om een foutvrije verbinding over de Sff-bus te krijgen. Hiertoe moeten de timers van de software in de 'Stepped' of 'Enabled' mode staan. Omdat het opzetten en verbreken door de toen nog aanwezige synchronisatieproblemen langer dan een minuut duurde, was de Sbus natuurlijk geen bruikbare verbinding hoewel de spraakverbinding zonder problemen werkte. Het gaf weI de mogelijkheid om de error correctie van de gei"mplementeerde lagen uitvoerig te testen. Hierbij werden geen nieuwe fouten gevonden. Tevens waren we benieuwd of dezelfde synchronisatieproblemen zich bij een verbinding tussen een MITEL kaart (NT) en het ISDN tenninal board voordeden. De software van het terminal board is daarom volledig en tot eenzelfde niveau als de MITEL software bijgewerkt. Om dit te verwezenlijken is er een nieuw window systeem gemaakt voor een ANSI-terminal. Met dit systeem kunnen we vrijwel dezelfde schenn- en toetsenfuncties gebruiken als op de PC bij de TURBO C compiler aanwezig zijn. Eventuele volgende

62


uitbreidingen van het ISDN User-Network interface kuooen dan veel gemakkelijker gebruikt worden op beide systemen. Dit systeem heeft echter een nadeel, het wordt emstig vertraagd door de RS232 verbinding bij het gebruik van 'langzame' computers. De snelheid die door het ANSI-terminalprogramma op een 8 MHz AT gehaald wordt, bedraagt

maximaal 9600 baud. Dat wil zeggen dat het uitvegen of verplaatsen van een window ter grootte van een half schenn ongeveer 1 seconde duurt. Ben snellere computer zou hier de oplossing zijn. Natuurlijk is het ook bij het terminal board niet mogelijk om zowel de timers in de 'Enabled' mode te zetten en tegelijkertijd de frames en andere statusberichten te bekijken. Tijdens het bijwerken van de terminal board software kwamen we vele fouten tegen, die natuurlijk allemaal zijn verbeterd. Dit wil niet zeggen dat de software nu geen fouten meer bevat, de fouten die nog in de ISDN software zitten veroorzaken echter geen zichtbare problemen. Na het debuggen en vemieuwen van de software was uiteindelijk een telefoonverbinding tussen de MITEL kaart en het terminal board mogelijk. De synchronisatieproblemen waren bij deze verbinding Diet aanwezig, alleen kon een goede spraakverbinding in eerste instantie niet worden opgezet. Bij nader onderzoek bleek dat de codec van het D-Phone interface van MITEL gernverteerde PCM-data (J.!-law) gebruikte in tegenspraak met de CCITf aanbevelingen. Het IC bevatte blijkbaar een interne fout. Omdat het SNIC ook nog afwijkingen met het databoek vertoonde bij de controle registers, zijn beide IC, het SNIC en de D-Phone, vervangen door nieuwe versies. Beide IC's werken nu volledig volgens de datasheets en zijn op een van de MITEL kaarten vervangen. waarna de telefoonverbinding tussen de MITEL kaart en het ISDN terminal board perfect werkte. Omdat er maar een IC setje beschikbaar was, is het nu niet meer mogelijk een goed werkende telefoonverbinding tussen de MITEL kaarten te realiseren, vooral omdat de codec's uit de D-Phone niet meer gelijk zijn. Het bestellen van een tweede IC setje wordt daarom aanbevolen. Verder wil ik nog opmerken dat veel van de gevonden fouten door een betere programma structuur kuooen worden voorkomen. Niet iedereen heeft evenveel commentaar bij de geschreven routines en gebruikte variabelen geleverd. Als vanaf het begin een vaste structuur of opzet voor het programma of ieder gedeelte hiervan was gekozen, was de implementatie van de software veel gemakkelijker geweest. Vooral het leveren van

63

Conc/usies en aanbevelingen

cornmentaar bij iedere gebruikte en gedefinieerde functie of variabele zou voorop moeten worden gesteld. Ook zou er nog een vriendelijker gebruikersinterface kunnen worden geimplementeerd dat automatisch bij het oppakken van de hoom een verbinding op laag 2, de data link laag, realiseert en daarna een SETIJP_REQUEST geeft. Dit moet nu nog altijd met de protocol monitor gebeuren door het versturen van een DL_ESTABLISH_REQUEST bericht vanaf laag 2 waarbij als oorsprong laag 3 wordt meegegeven. Daarna kan pas een SETIJP_REQUEST bericht vanaf laag 3 moet worden gegeven zodat de uiteindelijke telefoonverbinding tot stand kan komen.

64

Literatuurlijst

Literatuurlijst

[lJ

Stallings, W. ISDN AN INTRODUCTION New York: MacMillan. 1990.

[2]

CCITT RECOMMENDATIONS OF THE SERIES I, INTEGRAlED SERVICES DIGITAL NETWORK (ISDN) Red Book, Vol. ill, Fascicle III.5. Geneva: ITU, 1985.

[3]

Wetennan, P.l.G. DESIGNING AND BUll..DING OF AN ISDN TERMINAL BOARD Vakgroep Digitate Informatiesystemen, faculteit Elektrotechniek, Technische Universiteit Eindhoven, 1989. Mstudeerverslag.

[4]

Oudelaar, H. IMPLEMENTATION OF A CCITI PROTOCOL ON AN ISDN lERMINAL BOARD Vakgroep Digitate Informatiesystemen. faculteit Elektrotechniek, Technische Universiteit Eindhoven, 1989. Mstudeerverslag.

[5]

Maastricht, C. INITIALISATIE EN TESlEN VAN RET ISDN TERMINAL BOARD Vakgroep Digitate Informatiesystemen, faculteit Elektrotechniek, Technische Universiteit Eindhoven, 1990. Stageverslag.

[6]

Beijnsberger, JJ.P.H. HARDWARE EN SOFIWARE DEBUGGING VAN RET ISDN 1ERMINAL BOARD Vakgroep Digitate Informatiesystemen, faculteit Elektrotechniek, Technische Universiteit Eindhoven, 1990. Mstudeerverslag.

65

Literatuurlijst

[7]

Jookers, H.G. REALISATIE VAN EEN S-INTERFACE EN TELEFOON-INTERFACE VOOR HET ISDN TERMINAL BOARD Vakgroep Digitale Informatiesystemen, faculteit Elektrotechniek, Technische Universiteit Eindhoven, 1991. Stageverslag.

[8]

Oorschot, L.A.J. IMPLEMENTATIE VAN PROTOCOLLEN VOOR HET ISDN D-KANAAL Vakgroep Digitale Informatiesystemen, faculteit Elektrotechniek, Technische Universiteit Eindhoven, 1992. Afstudeerverslag.

[9]

Leijten, J. Vakgroep Digitale Informatiesystemen, faculteit Elektrotechniek, Technische Universiteit Eindhoven, 1993. Te verschijnen.

[10]

Claessens, J.R.H. IMPLEMENTATIE VAN DE CALL CONTROL PROTOCOLLEN VOOR HET OPZETTEN EN VERBREKEN VAN EEN ISDN TELEFOONVERBINDING Vakgroep Digitale Informatiesystemen, faculteit Elektrotechniek, Technische Universiteit Eindhoven, 1993.

[11]

Boormans, E.J.E.T. HARDWARE DEBUGGING VAN HET ISDN TERMINAL BOARD EN SOFIWARE ONTWIKKELING T.B.V. DE FYSIEKE LAAG EN PROTOCOL MONITORING Vakgroep Digitale Informatiesystemen, faculteit Elektrotechniek, Technische Universiteit Eindhoven, 1993.

[12]

Intel Corporation IC-86/286 COMPILER USER'S GUIDE FOR DOS SYSTEMS California: Santa Clara, 1989.

66

Literatuurlijst

[13]

Intel Corporation IAPX 86, 88 FAMILY UTILITIES USER'S GUIDE FOR IRMX 286 SYSTEMS California: Santa Clara, 1985.

[14]

Intel Corporation lCE-186/188 IN-eIRCUIT-EMULATOR USER'S GUIDE California: Santa Clara, 1989.

[15]

Intel Corporation IAPX 86/88, 186/188 USER'S MANUAL, HARDWARE REFERENCE California: Santa Oara, 1985.

[16]

Intel Corporation MICROPROCESSOR AND PERIPHERAL HANDBOOK, VOLUME I & II California: Santa Oara, 1988.

[17]

Advanced Micro Devices

AM79C30N32A DIGITAL SUBSCRIBER CONTROLLER (DSC), ISDN DATA CONTROLLER (JDC) Sunnyvale USA, juni 1989.

[18]

Advanced Micro Devices AM79C401 INTEGRATED DATA PROrocOLLER, TECHNICAL MANUAL Sunnyvale USA, juni 1989.

[19]

MITEL Semiconductor ISDN EXPRESS CARD USER MANUAL Canada, 1988.

[20]

MITEL Semiconductor MICROELECTRONICS DATA BOOK, ISSUE 6 Canada, 1988.

67

Bijlage 1

Bijlage 1: Ret literatuuronderzoek (Verslag van het bibliotheek-prakticum)

Hoofdstuk

1

Inleiding

De snelle ontwikkelingen in de computer en communicatie technologieen hebben gezorgd voor een steeds venier gaande integratie van beide gebieden. Zodoende heeft het CCIlT (Commit6 Consultatif International de T616graphique et Tel6phonique) het ISDN (Integrated Services Digital Network) gedefmieerd, een volledig digitale transmissie methode van gebruiker tot gebruiker. Het ISDN za1 uitgroeien tot een wereldwijd openbaar telecommunicatie netwerk met een breed scala van mogelijke services. Binnen de vakgroep Digitale Infonnatiesystemen van de Faculteit Elektrotechniek aan de Technische Universiteit Eindhoven is men bezig met de ontwikkeling van een ISDN tenninal. De software voor deze terminal wordt volgens de aanbevelingen van het CCITT ontwikkeld. Deze aanbevelingen verdelen de functies van de terminal in een aantal lagen volgens het OSI model (Open System Interconnection) van het ISO (International Standards Organization) maar alleen de onderste drie lagen zijn hier gedefmieerd. De protocollen zijn gedeeltelijk geimplementeerd op twee PC's die voorzien zijn van twee Mitel ISDN kaarten. Mijn afstudeeropdracht richt zich nu op de verdere ontwikkeling van deze ISDN terminal en de software: verbetering van de hardware, het verder aanpassen van de software zodat deze op de PC en op het tenninalboard draait. Met dit literatuuronderzoek probeer ik nu meer infonnatie te verkrijgen over het ISDN in het algemeen en de al ontwikkelde tenninals. We kunnen ons hierbij afvragen op welke manier deze terminals zijn gerealiseerd (hard- en software), welke problemen hierbij zijn opgetreden en hoe de hogere lagen van het OSI model zijn geimplementeerd.

68

Bijlage 1

Hoofdstuk

2

Concept inhoudsopgave

De concept inhoudsopgave van het afstudeerverslag ziet er als voIgt uit: Hoofdstuk

1

Inleiding

Hoofdstuk

2 2.1 2.2 3 3.1 3.2

ISDN

Hoofdstuk

Hoofdstuk

Hoofdstuk

Hoofdstuk

Standaarden Diensten De ISDN Mitel kaart Hardware Software

4 4.1 4.2

Het ISDN tenninal board

5 5.1 5.2

ISDN verbindeningen

6


Hardware Software

Mitel <--> Mitel ISDN tenninal board <--> Mitel

69

Bijlage 1

Hoofdstuk 3.1

3

Het Literatuuronderzoek

VUBIS

Omdat vooral enkele algemene werken over ISDN gezocht mooten worden, proberen we de optie 'het zoeken naar een woord in de titels' als eerste mogelijke zoek methode. Hierbij nemen we de afkorting ISDN (Integrated Services Digital Network) als trefwoord. Een eventuele nederlandse afkorting wordt nooit gebru.ikt, zodat we alleen de engelse term toepassen. Door VUBIS worden 5 mogelijke notaties van ISDN gegeven: - ISDN, - (ISDN), - B-ISDN, -LAN/ISDN, - I.S.D.N.-Circuit. De resultaten met deze trefwoorden staan in de onderstaande tabeL Tabel I : Resultaten van VUBIS.

Trefwoord

Gevonden

Geselecteerde

Geselecteerd op

titels

titels

inhoud

ISDN

62

27

16

(ISDN)

7

6

3

B-ISDN

1

0

LAN/ISDN

1

I.S.D.N.-circuit

1

0 0

0 0 0

Met behulp van de gevonden werken kunnen we nog meer trefwoorden vinden waarmee we nog andere werken zouden kunnen lokaliseren. De trefwoorden die bij de

70

Bijlage 1

bovenstaande geselecteerde werken behoren zijn: - Datacommunicatie; Computernetwerken; Protocollen, - Datatransmissie; Telegrafie, - Geintegreerde telecommunicatie, - Geintegreerde telecommunicatie netwerken, - Telefoonnetwerken. Met deze trefwoorden vinden we respectievelijk 92, 89, 5, 35 en 26 titels. We passen vervolgens de onderstaande regels toe om uit deze titels de bruikbare werken te halen:

- taa1 (Nederlands, Engels, Duits, of Frans), - stage of afstudeerverslagen over ISDN, - algemene informatie over ISDN of broadband-ISDN, - ISDN terrminals, - ISDN IC's, - ISDN protocollen, hogere OSI lagen. Uiteindelijk blijft slechts een werk over dat nieuw en interessant is.

3.2 INSPEC Computer and Control Abstracts (CCA) Vervolgens proberen we in de Computer and Control Abstracts meer artikelen te vinden over ISDN. We gebruiken hierbij de onderstaande zoektennen: - ISDN, - Integrated Services Digital Network, - Protocols, - Tenninals, - Telephone equipment. We beginnen te zoeken bij het jaar 1992 en gaan maximaal terug tot 1984 (het jaar waarin de eerste specifieke aanbevelingen van de CCITT uitkwamen). We moeten weI in gedachte

71

Bijlage 1

houden dat in 1988 een completere versie verscheen. Tabel II : Resultaten van de CCA.

Geselecteerd op

titels

Geselecteerd op samenvatting;

1992

41

14

0

1991

31

20

0

1990

27

14

0

1989

22

12

2

1988-1985

10

2

0

Jaar

Geselecteerde

inhoud

Voor het selecteren van deze artikelen gebruiken we dezelfde criteria als bij VUBIS.

3.3 INSPEC op CD-ROM Ben andere bron om artikelen uit te halen, is INSPEC op CD-ROM. We bekijken hier de jaren 1989 tim begin 1993. De twee onderstaande zoektermen passen we op de bestanden toe: -79C30 - isdn and equipment and (telephone or terminal). We selecteren de artikelen weer met behulp van de regels in hoofdstuk 3.1, zodat we tot het onderstaande resultaat komen.

72

Bij/age 1

Tabel ill : Resultaten van INSPEC op CD-ROM.

Jaar

1993 1992 1991 1990 1989

Geselecteerde

Geselecteerd op

Geselecteerd op

titels

samenvattin~

inhoud

6 7 8 10

3 2 2 2

8

4

0 0 0 3 2

3.4 Science Citation Index We gebruiken de Science Citation Index (SCI) eerst als autonome bron om andere artikelen te vinden van de schrijvers die uit de voorgaande bronnen naar voren zijn gekomen. Ook gebruiken we de SCI om nieuwe artikelen te vinden over het onderwerp ISDN waarbij de trefwoorden van de CCA gebruikt worden. De resultaten staan in de tabel IV. Tabel IV : Resultaten van de SCI.

Jaar

1992 1991 1990 1989 1988 1987 1986

Geselecteerde

Geselecteerd op

titels

inhoud

4

0 0 1 2 1 1 3

1 2 2 4 4

8

73

Bijlage 1

3.3 De sneeuwbalmethode Uitgaande van de belangrijkste artikelen die gevonden zijn, proberen we nu oudere publicaties te vinden door gebruik te maken van de literatuurlijsten. We hopen uiteindelijk een artikel (evt. meerdere) terug te vinden dat als basis diende voor de meeste andere publicaties over het onderwerp ISDN. De resultaten van deze studie staan in figuur 1. 1990 1989

II!EB I.Sol 7:29S-302

1988

T....,om.

Blecttonica

22(4)'.80-91

22:21-37

1987 1986

ll!EBJ.Sol 4:124\.12S0

1985

IEEBI.SeL 4:119~1201

ICCIlS 34.6, 20.6, 34_1

1984 1983 1982 1980

Piguur 1 : De sneeuwbalmethode.

3.4 De citatiemethode Omdat de bovenstaande methode alleen de iets oudere werken opgelevert en we toch nieuwere teksten zoeken, nemen we het meest actuele artikel (1990). Van dit artikel gebruiken we de literatuurlijst. De hierin opgenomen artikelen en het artikel zelf gebruiken we als uitgangsartikel voor de citatiemethode, zie figuur 2.

74

Bijlage 1

IEEEJ.Sel.

1991 1990

9:1383-1394

IEEEJ.Sel.

IEEEJ.Sel.

8:360-367

8:348-350

IEEEJ.Sel.

1989

7:1034-1041

1988 1987 1986

IEEE Commun. 35:659-663

IEEEJ.Sel.

IEEEJ.Sel.

IEEEJ.Sel.

4:1241-1250

4:1222-1229

4:1193-1201

Figuur 2 : De citatiemethode.

75

Bij/age 1

Hoofdstuk

4 De relatie tussen de geselecteerde artikelen en de concept inhoudsopgave

In de onderstaande tabel staan nu de geselecteerde artikelen en hun relatie tot de concept inhoudsopgave. Tabel V : Relatie tussen de gekozen artikelen en de concept inhoudsopgave.

Hoofdstuk~

Artikel

1

2

3

5

6

X

X

X

J.

[l] [2]

X

[3]

X

[4]

X

[5]

X X

X

X

[61

[7] [8] [9]

4

X

X

X

X

X

X X X

[10]

X

X

X

[11]

X

X

[12]

X

X

X

X

X

[13] [14]

X

X

[15]

X

X

76

Bijlage 1

Hoofdstuk

5

Conclusie

Zoals we in tabellen uit de voorgaande hoofdstukken kunnen zien, vinden we de meeste boeken met VUBIS. Tevens is VUBIS de snelste methode om boeken over een bepaald onderwerp te vinden. Het is echter met mogelijk om losse artikelen op te zoeken. Om deze laatste te vinden, kunnen we gebruik maken van de INSPEC abstracts (gedrukt

en op CD-ROM) en de Science Citation Index waarin de belangrijkste tijdschriften / congresverslagen zijn opgenomen. Het opzoeken van artikelen in de gedrukte versie van INSPEC en de SCI vergde echter veel tijd en leverde maar een gering aantal relevante artikelen op. Bij INSPEC op CDROM is het zoeken naar artikelen over een bepaald onderwerp veel gemakkelijker door het gebruik van de computer, de trefwoorden kunnen worden gezocht in alle opgeslagen gegevens van een artikel (in de titel, de samenvatting, trefwoordenlijsten, enz.). Door het specifieke karakter, op het gebied van de hard- en software, van het ISDN-board vielen de meeste artikelen af. Deze waren te gespecialiseerd, door een ander ontwerp (vooral de keuze van de ISDN-Ies) en software, of ze waren te algemeen (de zoveelste beschrijving/uitleg van de uitgebrachte CCIIT Recommendations). Uiteindelijk kunnen 7 artikelen in de literatuurlijst worden geplaatst Bij het zoeken in de SCI met behulp van de sneeuwbal- en de citatiemethode komen we hetzelfde probleem tegen. We vinden hierbij weI vier nieuwe artikelen. Ook kunnen we bij de sneeuwbalmethode duidelijk het 'basis artikel' zien, de CCIrr Recommendations van 1984. Deze serle boeken waren al bij VUBIS naar voren gekomen.

77

Bijlage 1

Literatuurlijst [1]

Wetennan, P.J.G. DESIGNING AND BUll..DING OF AN ISDN TERMINAL BOARD Vakgroep Digitale Infonnatiesystemen, faculteit Elektrotechniek. Technische Universiteit Eindhoven, 1989. Afstudeerverslag.

[2]

Oudelaar, H. IMPLEMENTATION OF A CCnT PROTOCOL ON AN ISDN TERMINAL BOARD Vakgroep Digitale Infonnatiesystemen, faculteit Elektrotechniek. Technische Universiteit Eindhoven, 1989. Afstudeerverslag.

[3]

van de Kuilen, S. SOFTWARE ONTWIKKELING ROND DE MITEL ISDN EXPRESS CARD Vakgroep Digitale Infonnatiesystemen, faculteit Elektrotechniek. Technische Universiteit Eindhoven, 1990. Afstudeerverslag.

[4]

Jonkers, H.G. REALISATIE VAN EEN S-INTERFACE EN TELEFOON-INTERFACE VOOR HET ISDN TERMINAL BOARD Vakgroep Digitale Infonnatiesystemen, faculteit Elektrotechniek, Technische Universiteit Eindhoven, 1991. Stageverslag.

[5]

Beijnsberger, J.J.P.H. HARDWARE EN SOFIWARE DEBUGGING VAN HET ISDN TERMINAL BOARD Vakgroep Digitale Infonnatiesystemen, faculteit Elektrotechniek, Technische Universiteit Eindhoven, 1990. Afstudeerverslag.

[6]

Oorschot, L.A.J. IMPLEMENTATIE VAN PROTOCOLLEN VOOR HET ISDN D-KANAAL Vakgroep Digitale Infonnatiesystemen, faculteit Elektrotechniek. Technische Universiteit Eindhoven, 1992. Afstudeerverslag.

[7]

Willems, Mark H.G. DESIGN OF A PC INTERFACE CARD FOR OFFICE COMMUNICATrONS USING THE ISDN BASIC ACCESS IEEE Journal on selected areas in communications, vol. 7 (1989), p. 295-302.

78

Bijlage 1

[8]

Gullick, D. and C. Crowe ISDN PROTOCOL IN HARDWARE Electronica, vol. 22 (1988), p. 21-37.

[9]

CCITT RECOMMENDATIONS OF THE SERIES I, Integrated Services Digital Network (ISDN) Red Book, Vol. TIl, Fascicle TIL5. Geneva: ITU, 1985.

[10]

Due, Q. and E.K. Chew ISDN PROTOCOL ARCHITECTURE IEEE Commun. Mag., Vol. 23 (1985), p. 15-22.

[IIJ

Liu, H-S. and E.P. Thomas A WORKING PROTOTYPE OF AN ISDN CENTRAL OFFICE IEEE Journal on selected areas in communications, vol. 4 (1986), p. 1241-1250.

[I2J

Ohkoshi, S. et al. DIGITAL TELEPHONE SET FOR ISDN IEEE Journal on selected areas in communications, vol. 4 (1986), p.1193-1201.

[13J

Nakano, S. et al. INTERFACE DESIGN FOR ISDN MULTIMEDIA TERMINAL IEEE Journal on selected areas in communications, vol. 8 (1990), p.1193-1201.

[14J

Stallings, W. ISDN AN INTRODUCTION New York: MacMillan, 1990.

[15J

O'Toole, T. CONSTRUCTING AN ISDN TERMINAL Elektronik, vol. 38 (1989), p60-66

79

Bijlage 2

Bijlage 2: Extra functies van de Monitoring Dispatcher voor het terminal board

Omdat de Protocol Monitor moest worden aangepast aan de hardware van het ISDN tenninal board, zijn er enkele functies bijgekomen maar er zijn ook enkele functies afgevallen. Voor een volledige handleiding van de Monitoring Dispatcher wordt verwezen naar I.R.H. Claessens [10]. Deze bevat natuurlijk weI de speciale MITEL functies voor de aansturing van de hardware. De opbouw en het gebruik van de Monitoring Dispatcher blijft verder gelijk. We beginnen bij het hoofdmenu. In dit menu is de optie 'Quit' komen te vervallen. Bij het kiezen van deze optie op het ISDN terminal board zal verder niets gebeuren. Men blijft in het hoofdmenu. Bij de optie 'View' is de 'Snic' optie vervangen door de 'Regdsc' optie. Met deze optie kunnen we nu een aantal registers van de DSC [17] bekijken, te weten: •

INIT

: Initialization register

•

LSR

: LID Status register

•

LMR1

: LID Mode register 1

• LMR2 : LID Mode register 2 De laatste verandering van de opties heeft plaats gevonden bij de optie 'Set'. In het eerste submenu is de nieuwe optie 'Baud' toegevoegd. Met deze functie kunnen we de baudrate van de IDPC instellen. Natuurlijk moet dan ook de baudrate het tenninal programma opnieuw worden ingesteld. Met behulp van de 'Reset' optie kunnen we dan opnieuw het schenn activeren. PAS OP: Door het veranderen van de baudrate kan de opbouw van het schenn verstoord worden Verder is in het submenu de optie 'Phone' uitgebreid. Ret is bij de DSC namelijk mogelijk om de microfoonversterker en de luidsprekerversterker aan te sturen. Het submenu van deze optie bestaat dan uit: 'Mic gain', 'Loudspeaker gain' en 'stop Ringer'. De versterking kan dan met de '+' en de '-' worden ingesteld bij het selecteren van een van de 'gain' opties.

80

Bij/age 3

Bijlage 3: Het gebruik van Turbo C++, Intel C en ICE

De gebruikte instellingen van Borland Turbo C++ versie 3.1 zijn: Options menu:

•

Compiler: Code generation: Model

Medium

Options

Treat enums as ints

SS equals DS

Default for memory model

Defmes Advanced code generation: Floating point

None

Instruction set

8088/8086

Options

Generate underbars Line numbers debug info Debug info in OBIs

Far data threshold

32767

Entry/Exit code: Prolog/Epilog code generation

DOS standard

Calling convention

C

Stack options

Standard stack frame

C++ options: Use C++ compiler

CPP extension

Template generation -

Smart

Options

Out-of-time inline functions

C++ virtual tables

Smart

Advanced C++ options: C++ member pointers -

Support all cases

Virtual base pointers -

Always near

Options

None

Optimizations:

81

Bijlage 3

Optimizations

Standard stack frames

Register variables

None

Common subexpressions

No optimization

Optimize for

Speed

Source options: Keywords

Borland C++

Comments

Nested comments

Identifier Length

32

Messages:

•

Display

All

Errors: Stop After

25

Errors: Stop After

100

Linker: Settings: Map file

Detailed

Output

Standard DOS EXE

Options

Warn duplicate symbols Case sensitive link

Code pack size Segment Alignment

8192 -

512

Libraries: Libraries

None

Container class library

None

ObjectWindows library

None

Standard Run-Time libraries -

Static

Voor de MITEL kaarten kunnen de volgende vier .EXE-files worden gegenereerd: •

SNICU.EXE met het projekt SNICU.PRJ voor een TE versie met de SNIC

•

SNICN.EXE met het projekt SNICN.PRJ voor een NT versie met de SNIC

•

DNICU.EXE met het projekt DNICU.PRJ voor een TE versie met de DNIC

•

DNICN.EXE met het projekt DNICN.PRJ voor een NT versie met de DNIC

Voor het bepalen van het interface (DNIC / SNIC) worden bij de files SETINTER.C en LA_PHONE.C de volgende constanten gedefinieerd met behulp van de 'Local options' van

82

Bijlage 3

het projekt menu: •

Command Line Options voor een SNIC versie:

-DSNIC=l -DDNIC=O •

Command Line Options voor een DNIC versie:

-DSNIC=O -DDNIC=l De onderstaande fIles worden in deze projekten gebruikt:

main.c lowin.c mondisp.c define.c tabllapd.c tabl man.c tabllay2.c tabl msg.c msg.c initproc.c queue.c error.c layer2.c tx.C

dscramin.c timer.c syst.c hardreg.c setinter.c

int dsc.c xmtbuffc manage.c lapd.c 13 global.c 13 init.c 13 table.c 13 inter.c 13_manag.c 13 auxil.c 13_nt_st.c (NT versie) / 13_te_st.c (TE versie) 13_nt_tr.c (NT versie) / 13_te_tr.c (TE versie) 13_gc_st.c 13_gc_tr.c 14 st.C 14_nt_tr.c (NT versie) / 14_te_tr.C (TE versie) 14_global.c 14yhone.c ztimer.c

Voor de INTEL compiler gebruiken we de onderstaande 'batch'-files: •

TOTAL.BAT: Compile en link aIle ISDN files

•

COMPILKBAT : Compile de fIle

•

LINK.BAT: Link alle bestaande OBJ-fIles en genereer een absolute programmacode voorde ICE

•

RUN.BAT: Start de In-Circuit-Emulator en laadt de ISDN software

83

Bijlage 3

De INTEL C compiler [12] wordt in de 'bateh'-fIle met de volgende opties [12] aangeroepen:

ic86 %1 db mod186 la rom ex dn(O) si(include\,d:\ic86\include\) df(AMD=l, MITEL=O) De INTEL Linker [13] maakt gebruikt van de onderstaande door INTEL meegeleverde startup- en library-files:

cstart.obj, & d:\ic86\/ib\c/ibl./ib, & d:\ic86\/ib\cnofltl.obj, & d:\ic86\/ib\87null./ib, & d:\ic86\/ib\laembed./ib & to term.lnk De INTEL Locater [13] wordt als voIgt aangeroepen:

loc86 term.lnk addresses( classes( coder OeOOOOH ), data( 020000H ), stack(010000H))) ic bs De software voor het ISDN tenninal board bestaat uit de volgende files: dscramin.c display.c error.c fillbuff.c global.c

initdsc.c

inithard.c

initidpc.c

initpic.c

initproc.c

initram.c

intsetup.c

int dma.c

int dsc.c

int idpc.c

13global.c

13 auxil.c

13_gc_tr.c

13 init.c 14 st.C

/3 inter.c

13_manag.c

13 table.c

/3 te st.C

/3 te tr.C

14global.c

14 te tr.c

14yhone.c

lapd.c

layer2.c

main.c syst.c

manage.c tabllapd.c

msg.c

termjun2.c

nametbls.c tabl mon.c usart.c

queue.c

termdis2.c

mask.c tabllay2.c timer.c

tabl man.c tx.C

tabCmsg.c xmtbuffc

Zodra de In-Circuit-Emulator is opgestart kan de software worden gestart met: go from :startup.start De ISDN software kan opnieuw worden ingeladen met: load term

84

Bij/age4

Bijlage 4: Programma functies In deze bijlage voIgt een overzicht van de gebruikte functies in alfabetische volgorde voor het ISDN tenninal board. Bij iedere functie is de filenaam venneld waarin de source-code van de functie staat, gevolgd door een korte taakomschrijving van de functie. De functies nit de state-tables van de processen (behalve het TRANSMISSION-proces) zijn niet weergegeven omdat deze in principe allemaal dezelfde taak hebben, namelijk het uitvoeren van de acties behorende bij een bepaald bericht. Bovendien zou de tabel dan erg lang en onoverzichtelijk worden. De state-table functies zijn terug te vinden in de files: LAPD.C, MANAGE.C, L3_TE_TR.C en LA_TE_TR.C. (zie [10] voor de MITEL functies en files)

Functie:

Filenaarn:

Ornschrijving:

GLOBAL.C L3GLOBAL.C lAGLOBAL.C

Declaraties van de globale vanabelen.

acknowledge_framesO

QUEUE.C

Geeft de buffers van bevestigde frames vrij.

backtrack_iqueueO

QUEUE.C

Herstelt de situatie van voor het lezen van een frame uit een I-queue.

BselectO CallControlLayer40

lAGLOBAL.C lA_TE_TR.C

Vult de B-kanaal structure. Behandelt alle binnenkomende Call Control berichten.

CallCtritoLayer30

L3_INTER.C

Ontvangt berichten van laag 4 voor laag 3.

charputO

DISPLAY.C

Schrijft een enkel karakter naar de terminalbuffer.

Checkstate()

L3_AUXIL.C

Test of state 'compatible' is.

clreolO

DISPLAY.C

Veegt de huidige regel vanaf de cursor uit

clrscrO

DISPLAY.C

Veegt een tekstwindow uit.

cursorO

DISPLAY.C

Schakelt de cursor aan of uit.

Dec_to_IA50

LAGLOBAL.C

Vertaalt decimale waarden naar IA5karakters.

delayO

DISPLAY.C

Wacht een aantal milliseconden.

discardO

QUEUE.C

Wisteen bepaalde 1- ofUI-queue.

85

Bij/age4

Functie:

Filenaam:

Omschrijving:

DispatcherO

TERMDIS2.C

De monitoring dispatcher.

dmaintO

INT_DMA.C

Interrupt-routine van de DMA.

DSCRaminitO

DSCRAMIN.C

Initialiseert zenden ontvangstbuffers.

dscintO dsc_initO

INT_DSC.C

Interruptroutine van de DSC.

INITDSC.C

Initialiseert de DSC.

durnmyO

GLOBAL.C

Lege functie om het einde van een statetabel te markeren.

End_AlertingO

IA_PHONE.C

Stopt het belsignaal en de bijbehorende timer.

FirstTOO

L3_AUXIL.C

Test of dit de eerste keer is dat de timer afloopt.

freebuffO

SYST.C

Geeft een bepaalde buffer vrij.

getbuffO

SYST.C

Aanvragen van een nieuwe buffer.

getchO

DISPLAY.C

Haalt een karakter op van het toetsenbord.

getcheO

DISPLAY.C

Haalt een karakter op van het toetsenbord en laat dit karakter op het schenn zien.

getmessO

QUEUE.C

Leest een frame uit een 1- ofUI-queue.

getmsgO

MESSAGE.C

Leest en copieert een bericht naar globale variabelen.

GetNuc1eoNameO

TERMFUN2.C

Geeft de naam van een nuc1eo.

GetProcessNameO

TERMFUN2.C

Geeft de naam van een proces.

getrandomO

MANAGE.C

Genereert een random nummer tussen 0 en 65535 (incl.).

GetStateNameO

TERMFUN2.C

Geeft de naam van een toestand.

gettextO

DISPLAY.C

Bewaart een tekstwindow.

gettextinfoO

DISPLAY.C

Haalt de infonnatie over het tekstwindow op.

gotoxyO

DISPLAY.C

Ga naar positie x,y op het schenn.

GeCCldparnrO

IAGLOBAL.C

Het Called party nummer wordt bepaald.

GecCldparsaO

IAGLOBAL.C

Het Called party subadres wordt bepaald.

GeCCIgparnrO

IAGLOBAL.C

Het Calling party nummer wordt bepaald.

GeCCIgparsaO

IAGLOBAL.C

Het Calling party subadres wordt bepaald.

GeCNumbersO

IA_TE_TR.C

Haalt de nummer- en andere infonnatie van Call Control.

86

Bijlage4

Functie:

Filenaam:

Omschrijving:

Horn_PickupO

LA_PHONE.C

Zet een 'setup_response' bericht in de queue.

IA5_to_DecO

LAGLOBAL.C

Vertaalt IA5-karakters naar decimale waarden.

idpcintO

INT_IDPC.C

Interruptroutine van de IOPC.

idpc_initO

INTIIDPC.C

Initialiseert de IDPC.

idpc_ram_initO

INITRAM.C

Initialiseert de IDPC structures.

inithardwO

INITHARD.C

Initialiseert de hardware.

Initlayer30

L3_INIT.C

Initialiseert pointers, calls, callreferences, first-timeout-condities en infonnatieelementen.

initpicO

INITPIC.C

Initialiseert de PIC.

initprocessO

INITPROC.C

Initialiseert de processen, timers, buffers, message- en frame-queue's en de TEIadministratie.

inicusartO

USART.C

Initialiseert de USART van de IOPC.

inslineO

DISPLAY.C

Voegt een tekstregel in bij de cursor.

kbhitO

DISPLAY.C

Wacht totdat een toets wordt ingedrukt.

Layer2toLayer30

L3_INTER.C

Verwerkt berichten van laag 2 voor laag 3.

IdmaskO

MASK.C

Maskeert interrupts van de PIC.

mainO

MAIN.C

Initialiseert de PC en start de dispatcher.

maskO

MASK.C

Maskeert de interrupts van de PIC.

messageO

MSG.C

Plaatst een bericht in de message-queue's.

movetextO

DISPLAY.C

Verplaatst een tekstwindow.

the_fIrstO

L3_AUXIL.C

Herstelt de fIrst-timeout conditie.

newbuffO

SYST.C

Aanvragen nieuwe buffer voor de ontvangst

nexLtimeouLwill_be_

van laag 2 frames. occupyBchannelO

LAGLOBAL.C

Selecteer een aangegeven B-kanaal.

PresenLwindowO

LA_PHONE.C

Bewaar/herstel het huidige dispatehetvenster.

printO

DISPLAY.C

Plaatst strings op het schenn (als 'cprintfO').

LA_PHONE.C

Print 'alerting' in Call Control venster.

PrinLAlertin~

MessageO

87

Bij/age4

Functie:

Filenaam:

Omschrijving:

lA_PHONE.C

Print 'both B-channels busy' in Call Control

PIint_BotnBchanbusy_ MessageO

venster. PIint_Call_Processed_ MessageO

lA_PHONE.C

Print 'call processed' in Call Control venster.

lA_PHONE.C

Print 'connected B? in Call Control venster.

lA_PHONE.C

Print 'B? disconnected' in Call Control

PrinCConnected_ MessageO PrincDisconnected_ MessageO

venster. PrinCHompickup_ MessageO

lA_PHONE.C

Print 'Horn pickup' in Call Control venster.

MessageO

IA_PHONE.C

Print 'B? released' in Call Control venster.

putqueue()

QUEUE.C

Plaatst een frame in een 1- of VI-queue.

puttext()

DISPLAY.C

Plaatst een opgeslagen tekstwindow.

queue_packet()

LAYER2.C

Houdt een frame in de queue als de zender

PrinCReleased_

niet vrij is. rcv_broadcastO

LAYER2.C

Stuurt ontvangen laag 2 bericht naar alle processen met dezelfde SAPI-waarde.

rev_channelO

LAYER2.C

Stuurt een laag 2 bericht naar een proces.

rev_messageO

INT_DSC.C

Genereert PH_DATA_INDICATIONbericht

rev_packetO

LAYER2.C

InterPreteert laag 2 frame.

Receive_L3msgO

L3_INTER.C

Ontvangt laag 3 frames van laag 2.

Receive_UnitDataO

L3_INTER.C

Ontvangt DL_UNIT_DATA berichten.

Release_CRO

L3_MANAG.C

Geeft een callreference-waarde vrij.

remove_trnr_msgO

TIMER.C

Stuurt een timeout-bericht naar het SINKproces.

ResetAllInfoO

L3_AUXIL.C

Herstelt alle infonnatie-elementen.

ResecDispatcherO

lA_PHONE.C

Opheffen aile verbindingen, resetten hoom volume en belsignaal.

88

Bijlage4

Functie:

Filenaam:

Omschrijving:

restarttimerO

TIMER.C

Het herstarten van een timer.

runtimerO

TIMER.C

Het starten van een timer.

SaveRestoreO

TERMDIS2.C

Leest en herstelt een venster op het

DISPLAY.C

beeldscherrn. Haalt strings op van het toetsenbord (als

scanO

'cscanfO'). SelectNueleoO

TERMFUN2.C

Laat de gebruiker een nueleo kiezen.

SelectProcessO

TERMFUN2.C

Laat de gebruiker een proces kiezen.

SelectStateO

TERMFUN2.C

Laat de gebruiker een toestand kiezen.

L4GLOBAL.C

Selecteert het B-kanaal en de status.

SeleccCldpar_NumberO L4GLOBAL.C

Selecteert het Called party nummer.

SeleccChanneCTo_ UseO SeleccCldpar_ SubaddressO

L4GLOBAL.C

Selecteert het called party subadres.

SeleccCRO

L3_MANAG.C

Selecteert een vrije call reference waarde.

SelecCMenu_OptionO

L4GLOBAL.C

Selecteer een menu optie.

SeleccNumberO

L4GLOBAL.C

De telefoonnummers worden bepaald.

SendO

MANAGE.C

Samenstellen en versturen van een laag 2 frame door het laag 2 management Samenstellen van een laag3 frame en doorgeven aan laag 2.

SetDefaultInfoO

Zet alle informatie elementen op hun standaard-waarde.

SeCAlertingO

L4_PHONE.C

Initialiseert het belsignaal.

SecClearO

L4_PHONE.C

Verwijder het Call Control venster.

SecConnectedO

L4_PHONE.C

Maakt een verbinding tussen de MAP en LID van de DSC.

SeCDisconnectO

L4_PHONE.C

Heft de verbinding tussen MAP en LID op.

SecReleasedO

L4_PHONE.C

Geeft een B-kanaal vrij.

ShowbufferO

TERMFUN2.C

Dumpt de inhoud van een buffer.

Start_AlertingO

L4_PHONE.C

Start het belsignaal en de bijbehorende timer.

StateCodeFO

L3_AUXIL.C

Geeft het nummer van de huidige call-state.

89

Bijlage4

Functie:

Filenaam:

Omschrijving:

StopAllTimersO

L3_AUXIL.C

Stopt alle timers van de huidige call.

stoptmrO

TIMER.C

Het stoppen van een timer.

Stop_AlertingO

IA_PHONE.C

Stopt het belsignaal en start de bijbehorende timer.

strputO

DISPLAY.C

Schrijft een string naar de terminalbuffer.

TECremoveO

MANAGE.C

Verwijdert een specifiek:e TEI-waarde.

TECremove_allO

MANAGE.C

Verwijdert alle toegekende TEI-waarden.

textattrO

DISPLAY.C

Zet de kleur attributen van een tekstwindow.

textbackgroundO

DISPLAY.C

Zet de achtergrondkleur op 'color'.

textcolorO

DISPLAY.C

Zet de tekstkleur op 'color'.

timecheckO

TIMER.C

Verlagen van alle lopende timers.

timedecO

TIMER.C

Verlagen van een timer en eventueel een bericht versturen.

TimeouttoLayer30

L3_INTER.C

Ontvangt laag 3 timeout-berichten.

timeouChornO

IA_PHONE.C

Behandelt de timeouCindication van Call Control.

timermsgO

TIMER.C

Het genereren van het timeout-bericht.

timecstatO

TIMER.C

Kijkt of een bepaalde timer loopt

txO

TX.C

Een laag 2 frame samenstellen en versturen naar TRANSMISSION.

tx_packetO

LAYER2.C

Verstuurt een laag 2 frame.

ungetehO

DISPLAY.C

Stop karakter terug in de toetsenbordbuffer.

unmaskO

MASK.C

Maakt interrupts weer mogelijk (PIC).

unnumbered_infoO

LAYER2.C

Decodeert een VI-frame.

updatequeueO

MESSAGE.C

Wist een bericht uit een queue.

usart_intO

USART.C

Interruptroutine van de USART.

wherexO

DISPLAY.C

Vraagt de x coordinaat van de cursor op.

whereyO

DISPLAY.C

Vraagt de y coorsinaat van de cursor op.

windowO

DISPLAY.C

Definieert een tekstwindow.

winselO

TERMFUN2.C

Selecteer/open een dispatcher venster.

xmtbuffO

XMTBUFF.C

Het versturen van een laag 2 frame.

zendenO

XMTBUFF.C

Het vullen van de zend-FIFO.

90

Een ISDN telefoonverbinding

Recommend Documents