Embed Size (px)
Citation preview
Eindhoven University of Technology
MASTER
Implementatie van protocollen voor het ISDN D-kanaal
Oorschot, L.A.J.
Award date:1992
Link to publication
DisclaimerThis document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Studenttheses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the documentas presented in the repository. The required complexity or quality of research of student theses may vary by program, and the requiredminimum study period may vary in duration.
General rightsCopyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright ownersand it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.
• Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain
IMPLEMENTATIE VANPROTOCOLLEN VOORHET ISDN D-KANAAL
L.A.J. Oorschot
Technische Universiteit Eindhoven
Faculteit der Elektrotechniek
Vakgroep Digitale Informatiesystemen
Eindhoven, augustus 1992
Begeleider: ir. M.J.M. van Weert
Hoogleraar: prof. ir. M.P.J. Stevens
De faculteit der Elektrotechniek van de Technische Universiteit Eindhoven aanvaardt
geen aansprakelijkheid omtrent de inhoud van stage- en afstudeerverslagen.
Samenvatting
Aan de Technische Universiteit Eindhoven wordt een stand-alone terminal-board
ontwikkeld dat aangesloten kan worden op het ISDN. De protocollen die de CCITT
daarvoor gedefinieerd heeft worden geimplementeerd en getest op twee PC's met
ieder een MITEL ISDN Expres Card aan boord. De onderste drie lagen (volgens het
OSI-referentiemodell van de protocollen zijn geimplementeerd met behulp van het
Oudelaar message-passing operating system.
Dit verslag beschrijft deze implementatie, de problemen bij de communicatie met de
hardware, de fouten in software voor laag 2 en laag 3 en de gevonden oplossingen.
Om de software te kunnen testen is het hart van het operating system, de
dispatcher, uitgebreid tot een monitoring dispatcher. Met deze uitbreiding is het
mogelijk om de protocollen en diverse datastructuren te bestuderen tijdens "run-time"
van de software.
Het is gebleken dat het uitvoerig testen van aile componenten een zeer belangrijke rol
speelt bij de implementatie van een groot stuk software. Het uitgebreid testen van de
diverse onderdelen van de software heeft ertoe geleid dat de problemen die er waren
opgelost zijn. De huidige software meet zonder veel problemen gebruikt kunnen
worden voor de implementatie van een laag 4 protocol. Met andere hardware-drivers
moet de software ook zonder meer over gezet kunnen worden naar het uiteindelijke
ISDN terminal board.
Inhoudsopgave
1. Inleiding
2. De implementatie
2.1. De opstelling
2.2. Het operating system
3. De communicatie met de hardware
3.1. De SNIC
3.2. De interrupthandlers
3.3. De problemen
4-. De datalinklayer
4-.1. Het protocol
4-.2. De implementatie
4-.3. De software
4-.4-. Het testen van de software
5. De networklayer
5.1. Het protocol
5.2. De implementatie
5.3. De software
5.4-. Het testen van de laag 3 software
6. Condusies & aanbevelingen
Literatuurlijst
BIJLAGE 1: Literatuuronderzoek naar geschikte operating systems
BIJLAGE 2: Handleiding van de monitoring dispatcher
BIJLAGE 3: Belangrijke datastructuren
BIJLAGE 4-: De functies
Inhoudsopgave
2
4
4
7
12
12
14
17
23
23
2627
30
32
32
32
34
36
38
39
4-0
4-9
57
63
Inleiding
1. Inleiding
De hoeveelheid communicatie heeft sinds de uitvinding van de telegraaf en de telefoon
een gestage groei doorgemaakt. De laatste 15 jaar verschijnen ook steeds meer
vormen van communicatie. Denk daarbij aan bijvoorbeeld de fax, communicerende
computers enzovoort.
Het aanleggen en onderhouden van aparte netten voor de verschillende vormen van
communicatie brengt hoge kosten met zich mee en veroorzaakt een inefficient gebruik
van de aanwezige transportmedia. Door de toenemende digitalisatie vervagen echter de
verschillen tussen de diverse communicatievormen waarmee ook de noodzaak van
aparte netten verdwijnt.
De CCITT (Comite Consultatif International Telegraphique et Telephonique) heeft
daarom het ISDN <Integrated Services Digital Network) gedefinieerd. Binnen het ISDN
kunnen een groot aantal diensten gebruikt worden via €len digitale netwerk-aansluiting.
In het ISDN is de verbinding van abonnee naar abonnee dus volledig digitaal.
Het ISDN kent een beperkt aantal aansluitmogelijkheden voor de gebruikers. De
standaard huis-tuin-en-keuken aansluiting voor bijvoorbeeld een telefoontoestel is de
zogenaamde basic-access-aansluiting. Een dergelUke aansluiting biedt twee B-kanalen
voor overdracht van informatie (bijv. een gedigitaliseerd spraaksignaall en een
D-kanaal voor de signalering (het opzetten, onderhouden en afbreken van
verbindingen) .
De CCIIT heeft de functies die apparatuur voor het gebruik van een dergelijke
aansluiting moet vervullen verdeeld in lagen volgens het OSI-referentiemodel. Voor de
lagen 1, 2 en 3 van dit model heeft de CCITT protocol len gedefinieerd. Deze hebben
hoofdzakelijk betrekking op het D-kanaal. Voor de B-kanalen is aileen vastgelegd hoe
ze op laag 1 met het D-kanaal de transmissielijn delen.
Binnen de vakgroep Digitale Informatiesystemen van de faculteit der Elektrotechniek
van de Technische Universiteit Eindhoven wordt een terminal-board ontwikkeld dat
direct aan een basic-access-aansluiting gekoppeld kan worden (op het zogenaamde
SIT-referentiepuntL De hardware van dit terminal-board werkt nog niet voldoende
betrouwbaar. Om de CCIIT-protocollen toch te kunnen implementeren en testen
beschikt de vakgroep over twee PC's met ieder een insteekkaart van de firma MITEL
die een basic-access-aansluiting simuleren.
Toen ik aan mijn afstudeerwerk began was de software voor de implementatie van de
protocollen reeds grotendeels geschreven. Het versturen van berichten over het
user-network interface leverde echter nog de nodige problemen op waardoor de
geimplementeerde protocollen voor de datalinklaag (Iaag 2) en met name de
netwerklaag Oaag 3) nog niet of niet voldoende getest konden worden. Tijdens mijn
afstudeerperiode heb ik de software aangepast en getest om een werkende basis te
krijgen voor de implementatie van bijvoorbeeld een ISDN-telefoon.
2
Inleiding
In hoofdstuk 2 worden de verschillende aspecten van de implementatie van de
CCITT-protocollen op de beide PC's behandeld. Hoofdstuk 3 beschrijft de problemen
die optraden bij de communicatie tussen de software en de hardware (de
ISDN-insteekkaarten) en de oplossingen die gevonden zijn. Hoofdstuk 4 en 5
behandelen de protocollen, de software en het testen van laag 2 en 3. In hoofdstuk 6
volgen de conclusies en enkele aanbevelingen.
In bijlage 1 staat het verslag van het bibliotheekpracticum waarbinnen ik een
Iiteratuurstudie heb verricht naar bestaande operating systems die voor het
implementeren van de ISDN-protocollen gebruikt zouden kunnen worden. Bijlage 2
bevat een handleiding van de monitoring dispatcher. De monitoring dispatcher vormt
het hart van de huidige versie van het Oudelaar operating system waarop de
protocollen afgebeeld zijn. Bijlage 3 bespreekt een aantal belangrijke datastructuren en
de functies die daarop werken. Bijlage 4 tenslotte geeft en overzicht van de gebruikte
functies, de files waar ze in te vinden zijn en een korte beschrijving van hun taak.
3
De implementatie
2. De implementatie
2.1. De opstellTng
De apparatuur voor het ISDN is verdeeld in een aantal functionele blokken die met
elkaar verbonden zijn op de zogenaamde referentiepunten. In figuur 2.1 zijn de
verschillende functionele blokken voor de gebruikerszijde van een netwerkaansluiting
weergegeven. Het T-referentiepunt markeert de fysische aansluiting van de
gebruikersapparatuur op het netwerk. Het S-referentiepunt markeert het punt waar
een gebruiker z'n ISDN-telefoon, -fax of -computer (TE1) aansluit op een lokale
centrale (NT2L Ais er geen lokale centrale aanwezig is, dan vallen het S- en het
T-referentiepunt samen. Apparatuur die niet over een ISDN-aansluiting beschikt (TE2)
wordt op het R-referentiepunt gekoppeld aan een speciale adaptor (TA) die wei op het
S-referentiepunt aangesloten mag worden.
De ISDN-terminal die binnen de vakgroep ontwikkeld wordt moet gekoppeld kunnen
worden aan een basic-access-aansluiting op het SIT -referentiepunt en behoort dus
tot de TE1-groep.
I TE1~ NT2 ~,--N_T_1_1~~~i"i.
ITE2~ TA~
TE1:
TE2:
TA:
NT1:
NT2:
R,S,T:
Terminal Equipment met een voor ISDN geschikt interface.
Terminal die niet direct aan het ISDN gekoppeld kan worden.
Terminal Adaptor om een TE2 aan het ISDN te koppelen.
Network Termination die zorgt voor een goede
elektromagnetische netwerkafsluiting en timing en voeding levert
aan de terminal.
Dit kan een leeg blok zijn (bijv. bij een normale telefoon
aansluiting) of het kan bijvoorbeeld een PABX of een LAN
bevatten.
Referentiepunten.
Figuur 2.1: De ISDN referentie conftguratie (gebruikerszijdeL
4
De implementatie
De basic-access-aansluiting biedt de gebruiker in beide richtingen twee B-kanalen en
een D-kanaal. De twee B-kanalen van ieder 64 kbps worden gebruikt voor de te
transporteren gegevens. Er kunnen dus bijvoorbeeld twee telefoongesprekken (8kHz
samplefrequentie, 8 bit! samplel tegelijk gevoerd worden over een aansluiting. Het
D-kanaal dient voor signalering Onformatie voor het opzetten, onderhouden en
afbreken van verbindingenl en in beperkte mate voor het versturen van packet-data.
Het D-kanaal heeft een capaciteit van 16 kbps.
De twee B-kanalen en het D-kanaal worden, samen met nog 48 kbps aan vlaggen en
balancing-bits, conform het laag 1 protocol gemultiplext tot een seriele bitstroom die
over een aderpaar verstuurd wordt. Laag 2 zorgt voor een foutloze communicatie
over de user-network-interface. Laag 3 gebruikt laag 2 voor leggen van verbindingen
door het netwerk.
De huidige opstelling voor het implementeren en testen van de protocollen bestaat uit
twee PC's. Iedere PC bevat een ISDN Expres Card van de firma MITEL. Deze kaarten
implementeren het genoemde laag 1 protocol. Door de kaarten met elkaar te verbinden
kan een ISDN-verbinding (user-network-interfacel gesimuleerd worden. De protocollen
voor de lagen 2 en 3 worden softwarematig geimplementeerd in de beide PC's.
De ISDN Expres Card heeft zes interfaces (zie figuur 2.2), De CEPT- en de T1-trunk
zijn aansluitingen waarover 30 respectievelijk 23 B-kanalen getransporteerd worden.
Deze aansluitingen worden niet gebruikt bij een basic-access-aansluiting. Op het
digital-phone-interface kan een telefoonhoorn aangesloten worden. De digital phone
verzorgt de ADI DA-conversie zodat over een B-kanaal een telefoongesprek gevoerd
kan worden. De SNIC (Subscriber Network Interface Circuitl en de DNIC (Digital
Network Interface Circuit) irnplementeren een basic-access-aansluiting. De
PC-interface tenslotte verzorgt de communicatie tussen de computer en de diverse
componenten op de kaart.
De Digital Crosspoint Switch maakt het mogelijk om de componenten via het interne
bussysteem van de kaart, de ST-bus, met elkaar te verbinden. Voor de benodigde
kloksignalen beschikt de kaart over een eigen klokgenerator en een PLL waarmee de
klok gesynchroniseerd kan worden met signalen van de interfaces. Tenslotte bevat de
kaart neg twee onafhankelijke HDLC-controllers.
Voor een basic-access-aansluiting wordt de SNIC gebruikt. De SNIC verstuurt en
ont.vangt op twee aderparen een 192 kpbs signaal dat voldoet aan de protocollen die
de ccrn voar signalen op het SI T-referentiepunt heeft beschreven. De timing van de
SNIC kan afgeleid worden van het binnenkomende signaal of van een op de kaart
aanwezige klokgenerator. De SI\lIC zorgt automatisch voor het correct samenstellen
en splitsen van de signalen in B- en D-kanalen. De B-kanalen kunnen via de Digital
Crosspoint Switch verbonden worden met bijvoorbeeld de Digital Phone om een
telefoonverbinding tot stand te brengen. Het D-kanaal is verbonden met een zend- en
een ontvangst-buffer (beiden first-in-first-outl aan boord van de SNIC.
5
De implementatie
DNICU-inl.
PC Inlerface
DigilalCrosspoint
Swnch
Cloc~ Generalorand DPLL
28+0
igit.oPhone
CEPTTrunk
308+0
Figuur 2.2: Blokdiagram van een ISDN Expres Card
Via de PC-interface kunnen status- en control-registers van de verschillende
componenten van de kaart bekeken en gewijzigd worden. Daarmee is het mogelijk de
werking van de kaart op de wensen van de gebruiker af te stemmen.
Verder dient deze interface voor de uitwisseling van gegevens tussen de PC en de
D-kanaal-buffers van de SNIC. Op die manier is het mogelijk om de PC over het
D-kanaal van de ISDN-verbinding te laten communiceren met het ISDN of, zoals in de
hUidige opstelling het geval is, met een andere PC die de netwerkzijde van de
S-interface emuleert.
Tenslotte levert de SNIC via deze interface een interrupt aan de PC als het
zend-buffer van de SNIC bijna leeg is of het ontvangst-buffer van de SI\lIC bijna vol.
Met behulp van deze interrupt kan de PC snel reageren op deze situaties zonder
constant de SNIC in de gaten te houden.
6
De implementatie
2.2. Het operatIng system
In dit verslag komen aileen de lagen 1, 2 en 3 van het OSI-referentiemodel aan de
orde. Op deze lagen zijn voor de informatie die over de beide B-kanalen verstuurd
wordt geen protocol len vastgesteld. Iedere bron die maximaal 64 kbps produceert mag
op een B-kanaal aangesloten worden. De CCITI-protocol len hebben dan ook verder
a1lemaal betrekking op het D-kanaal.
Voor iedere laag definieert de CCITI een aantal zogenaamde entiteiten. Een entiteit is
een min of meer autonome toestand-machine. Entiteiten bezitten een aantal interne
parameters en kunnen andere entiteiten (ook die aan de andere kant van de
user-network-interface c.q. de netwerk-verbinding) communiceren door middel van het
uitwisselen van primitieven. Afhankelijk van de toestand, de parameters en de
binnenkomende primitieve worden nieuwe primitieven verstuurd, parameters aangepast
en/ of de toestand gewijzigd.
Om een relatief groot aantal entiteiten te kunnen beheren op een enkele processor is
een aangepast operating system nodig. In bijlage 1 staat het verslag van een
Iiteratuurstudie naar bestaande operating systems die voor deze toepassing in
aanmerking kunnen komen. Bij het begin van het ISDN-project is er echter voor
gekozen om zelf een op deze toepassing toegespitst operating system te schrijven. Dit
operating system werd geschreven door H. Oudelaar [1]. Figuur 2.3 toont het principe
van dit operating system.
123
MESSAGES
:INTERRUPTHANDLERS
RgUlr 2.3: Hat principe van hat Oudelaar operating system.
7
De implementatie
In het Oudelaar operating system worden de entiteiten voorgesteld door processen.
Primitieven worden voorgesteld door berichten (messages). De berichten staan in een
aantal message-queues. De dispatcher selecteert berichten uit de message-queues en
bepaalt welke functie er, op grond van het bericht en de toestand van het
bestemmingsproces, uitgevoerd moet worden.
De hardware genereert interrupts. Deze interrupts worden door speciale
interrupthandlers verwerkt. Ais het nodig is plaatsen de interrupthandlers een bericht
in de message-queues. De dispatcher zorgt dan voor de verdere afhandeling van dat
bericht.
Processen
Het operating system is geschreven in C. Een proces is als voigt gedefinieerd:
struct process
{
byte
byte
struct state far
byte
byte
l:!yte}
Pub/Stat;
Priorid;
.-State;
Substate;
Data 1;
DataB;
Hierin is het type byte gedefinieerd als unsigned char.
Het Pub/Stat-veld geeft aan of het process "running" of "blocked" is. De meeste
processen zijn permanent "running". Een "blocked" proces moet eerst door een ander
proces "running" gemaakt worden voor het berichten kan ontvangen.
Het Priorid-veld bepaalt de prioriteit van een proces. De CCITI heeft in de protocol len
een aantal tijdslimieten ingebouwd. Daardoor moeten sommige processen sneller op
berichten reageren dan andere processen. am deze tijd-kritische processen voorrang
te geven krijgt ieder proces een bepaalde prioriteit. Berichten worden verwerkt in
volgorde van afnemende prioriteit van hun bestemmingsproces.
Het State-veld is een pointer die naar de state-table wijst die bij de huidige toestand
van het proces behoort. Daarmee wordt dus indirect de toestand van het proces
bepaald.
Het Substate-veld dient voor een verdere onderscheiding van de toestand van het
proces. Dit veld heeft aileen betekenis voor bepaalde toestanden van laag 2
processen.
De velden Data1...DataB dienen voor het opslaan van proces-parameters. Deze kunnen
bij ieder proces een andere betekenis hebben.
8
De implementatie
De totale verzameling processen staat in een globaal array van het type process:
struct process ProcessfMAXPROCJ;
De processen worden van elkaar onderscheden door hun rangnummer in het array. De
met een define-statement vastgelegde constante MAXPROC bepaalt het aantal
processen (rangnummers 0 . . MAXPROC-1). Na het compileren kunnen dus geen
processen gecreeerd of vernietigd worden.
State-tables
Het State-veld van een proces wijst naar een state-table, beter gezegd naar het
eerste element van die state-table. Een element van een state-table wordt als voigt
gedefinieerd:
struct state{
word nue/eo;
void (~transiJ(void);
}
Hierin is het type word gedefinieerd als unsigned int.
Het nue/eo-veld geeft een bericht aan door middel van het nummer van het bericht.
Het transi-veld is een pointer naar de functie die uitgevoerd moet worden bij
ontvangst van dit bericht.
Een state-table is een array van het type state, bijvoorbeeld:
struct state TELASSIGNEDf J =
{
{ DL_ESTABLISH_REQUEST,
{ DL_RELEASE_REQUEST,
{ ULFRAME_IN_QUEUE,
dlestreq_4 },
dlrelreq_4 },
uiframe_4 },
{ DEF,
};dummy }
De naam van het array is de naam van de toestand On dit geval TELASSIGNED).
DL_ESTABLISH_REQUEST, DL_RELEASE_REQUEST, enzovoort zijn met een
define-statement vastgelegde namen van de berichten. De bijbehorende procedures zijn
dies treq_ 4, dlrelreq_ 4, enzovoort.
Het element { DEF, dummy} wordt gebruikt om het einde van een state-table aan te
geven. Dit om makkelijk met state-tables van verschillende lengte te kunnen werken.
9
De implementatie
Messages
De berichten worden in C a1s voigt gedefinieerd:
struct message{
word nucleo;
byte dest;
byte orig;
byte param_1;
byte param_5;}
Het nucleo-veld geeft aan om welk bericht het gaat. Deze waarde kan later opgezocht
worden in een state-table om de gewenste functie te vinden.
In het dest-veld staat (het rangnummer van) het proces waarvoor het bericht
bestemd is (destination). Dit veld wordt door de dispatcher gebruikt om het bericht
naar het juiste proces te leiden.
In het orig-veld staat (het rangnummer van) het proces dat het bericht gestuurd
heeft (origin). Dit kan gebruikt worden om te bepalen waar een eventuele terugmelding
naar toe moet.
De velden pararrL 1 . .
bericht mee te geven
sliding-window-protocol) .
param_5 worden gebruikt om extra parameters aan het
(bijvoorbeeld het volgnummer van een frame in een
De berichten worden in een aantal message-queue's gezet, een queue voor elk
prioriteitsniveau. Een bericht wordt door het operating system geplaatst in de queue
die hoort bij de prioriteit van het proces waar het bericht voor bestemd is.
DIspatcher
De dispatcher vormt het hart van het Oudelaar operating system. In figuur 2.4 staat
de basis structuur van de dispatcher in pseudo-C. De dispatcher kijkt continu of er
berichten in de queue's staan (eeuwige while-Ius). Daarbij worden de queue's in
volgorde van afnemende prioriteit afgewerkt (0 is de hoogste prioriteiO.
Als er een bericht gevonden wordt (de functie "getmsg" levert dan de waarde
"Present") , dan wordt eerst gekeken of het bestemmingsproces "running" of
"blocked" is. Een "blocked" proces kan geen berichten ontvangen en in dat geval
wordt het bericht zonder meer verwijderd. Anders zoekt de dispatcher het bericht (de
"nucleo") op in de huidige state-table van het proces waar het bericht naar toe moet.
10
De implementatie
dispatcher0
{
byte Pri = 0;
while (1)
{
if (getmsg(PriJ == Present)
{
if (destination_proces 1= Blocked)
{
look_up_nucleo_in_s tate_ table0 ;
execute_function_found_in_state_tableO;
updatequeue(PriJ ;
Pri = 0;}
else{
updatequeue(PriJ;}
}
else
{
Pri = ++Pri % MAXPRJO,'}
}
}
Rguur 2.4: De basis structuur van de dispatcher.
Het State-veld van het proces wijst naar het begin van die state-table. Vervolgens
voert de dispatcher de bijbehorende functie uit en wist het bericht uit de queue.
Tenslotte wordt "Pri" weer op nul gezet zodat opnieuw vanaf de queue voor de
hoogste prioriteit gezocht wordt (de zojuist uitgevoerde functie kan immers berichten
in een queue van hogere prioriteit geplaatst hebbenL
Ais aile queue's ieeg blijken te zijn. dan begint de dispatcher opnieuw bij de queue
voor de hoogste prioriteit.
Om aile processen soepel te laten verlopen dient de programmeur ervoor te zorgen
dat de functies die in de state-tables staan in aile gevallen eindigen en een zo kort
mogelijke executietijd hebben. Er is geen watchdog-timer die dit in de gaten houdt!
11
De communicatie met de hardware
3. De communicatie met de hardware
3.1. De SNICZoals gezegd wordt het samenstellen en splitsen van de over de S/ T-interface
uitgaande en binnenkomende informatiestromen volledig verzorgd door de SNIC. De
software ziet een functionele eenheid die interrupts levert en waarmee
gecommuniceerd kan worden door middel van een aantal registers.
In de SNIC bevinden zich twee first-in/first-out buffers, de ontvangst-fifo en de
zend-fifo. Deze buffers bevatten de bytes die via het D-kanaal ontvangen zijn
respectievelijk de bytes die over het D-kanaal verstuurd moeten worden. Seide buffers
kunnen maximaal 19 bytes bevatten.
De belangrijkste registers voor het gebruiken van de SNIC zijn HDLC control register
1 en 2, het HDLC interrupt register en de buffer-registers HDLC Rx FIFO en HDLC
Tx FIFO. Deze registers bevinden zich in de SNIC en hebben niets te maken met de
twee HDLC-controllers die naast de SNIC op de ISDN-kaart aanwezig zijn.
Met HDLC control register 1 kunnen de zender en de ontvanger van de SNIC
onafhankelijk van elkaar enabled/ disabled worden. Verder bepaalt de inhoud van dit
register onder andere de richting van de informatie van/ naar het D-kanaal. De te
zenden bytes, in dit geval afkomstig van de PC die de CCITI protocollen
implementeert. kunnen naar keuze naar buiten gestuurd worden via de S-interface of
via de interne ST-bus naar een andere component op de ISDN Expres Card geleid
worden. Onafhankelijk daarvan kan men kiezen tussen ontvangst vanaf de S-interface
of vanaf de ST-bus.
HDLC control register 2 bevat twee resetvlaggen waarmee de zend-fifo en de
ontvangst-fifo leeg gemaakt kunnen worden (de fifo's hoeven dan niet leeg gelezen te
worden). Verder kan met dit register aangegeven worden welke labels (tags) aan het
volgende byte dat in de zend-fifo geplaatst wordt gehangen meeten worden. Met deze
tags kan men aangeven dat een byte het laatste in een pakket is (eop; end-of-packet)
of dat het frame afgebroken moet worden (fa; frame-abort).
HDCL control register 2 kan niet gelezen worden. Lezen levert de inhoud van het
zogenaamde HDLC status register op. Het HDLC status register geeft informatie over
de toestand van de zend-fifo. de ontvangst-fifo en over de betekenis van het eerste
byte in de ontvangst-fifo. Voor de zend-fifo worden de toestanden "vol". "nog
minstens 5 bytes over". "maximaal 4 bytes over" en "Ieeg" onderscheiden. Voor de
ontvangst-fifo worden de toestanden "Ieeg". "maximaal 14 bytes binnen", "minimaal 15
bytes binnen" en "overloop" onderscheiden. Het eerste byte van de ontvangst-fifo kan
de volgende betekenissen hebben: "dit is het eerste byte van een pakket". "dit is een
byte ergens midden in een pakket", "dit is het laatste byte en het pakket is geed over
gekomen" en "dit is het laatste byte maar er is iets fout gegaan tijdens de
transmissie". De SNIC bepaalt deze betekenis aan de hand van de openings- en
sluit-vlaggen en de frame-cheek-sequence van de ontvangen frames.
12
De communicatie met de hardware
Het HDLC interrupt register bestaat, net als HDLC control register 2, uit twee delen.
Als het register gelezen wordt, dan levert dat de waarde van het HDLC interrupt
status register op. In dit register staat aangegeven welke interrupts er opgetreden
zijn sinds de laatste keer dat het gelezen werd. Uit de interrupt die de SNIC
genereert kan niet worden opgemaakt welke gebeurtenis de interrupt veroorzaakt
heeft. Om te bepalen wat de oorzaak was moet het HDLC interrupt status register
gelezen worden. De volgende gebeurtenissen veroorzaken een SNIC-interrupt:
GA Go Ahead. Er is een go-ahead-sequence ontvangen via het D-kanaaJ. Deze
interrupt wordt niet gebruikt.
EOPD End Of Packet Detected. Het laag 2 protocol (LAPD, zie hoofdstuk 4)
verstuurt informatie over het D-kanaal in de vorm van pakketten. Voor het
versturen van deze pakketten worden frames gebruikt. Een frame bestaat uit
een openingsvlag, het te versturen pakket, een frame-cheek-sequence (FCS)
en een eindvlag. De vlaggen worden gevormd door de bitrij 01111110 en dienen
om het begin/ eind van een frame te kunnen detecteren. De FCS wordt
gebruikt om na te gaan of een ontvangen frame goed overgekomen is of niet.
Met EOPD geeft de ontvanger van de Sj\JIC aan dat de eindvlag van een frame
gedetecteerd is. Het pakket kan goed of fout overgekomen zijn.
TEOP Transmitted End Of Packet. De zender heeft het laatste byte van een pakket
verstuurd. De tags, die met behulp van HDLC control register 2 aan ieder byte
in de zend-fifo gehangen kunnen worden, geven aan of een byte het laatste is
van een pakket. Na het laatste byte van een pakket moeten nog de FCS en de
eindvlag verstuurd worden. Op het moment dat TEOP optreedt is het frame
dus nog niet helemaal verzonden.
FA Frame Aborted. Er is een frame-abort-sequence ontvangen. De zender heeft
voor het einde van de transmissie het frame afgebroken.
TxFL Transmit Fifo Low. Dit treedt op als er nog maar 4 bytes over zijn in de
zend-fifo. Deze gebeurtenis treedt aileen op als de zend-fifo van 5 naar 4
bytes gaat. TxFL geeft aan dat het tijd wordt om de zend-fifo bij te vullen om
te voorkomen dat deze helemaal leeg loopt wat het afbreken van het frame
(FA) tot gevolg zou hebben.
TxFU Transmit Fifo Underrun. Aile bytes uit de zend-fifo zijn verzonden, maar het
laatste byte had niet het "dit is het laatste byte"-Iabel. De zender verstuurt nu
automatisch een frame-abort-sequence zodat de ontvanger aan de andere kant
van de lijn weet dat er iets fout gegaan is.
RxFF Receive Fifo Full. De ontvangst-fifo heeft zojuist het 15e byte ontvangen. Het
wordt tijd dat de bytes uit de fifo gelezen worden.
RxFO Receive Fifo Overflow. Er wordt geprobeerd om een byte in een volle
ontvangst-fifo te schrijven. Dit byte en de rest van het frame gaan verloren en
er wordt niets meer ontvangen totdat volgende openingsvlag gedetecteerd
wordt.
13
De communicatie met de hardware
Als er naar het HDLC interrupt register geschreven wordt. dan belandt de geschreven
waarde in het HDLC interrupt mask register. Dit register bepaalt welke van de
hierboven genoemde gebeurtenissen een SNIC-interrupt zullen genereren. Met behulp
van dit register is bijvoorbeeld de genoemde GA buiten werking gesteld.
Tenslotte zijn er de registers HDLC Tx FIFO en HDLC Rx FIFO. Ook deze registers
zijn verenigd in een fysisch register. Bij schrijven wordt het Tx register gebruikt, bij
lezen het Rx register. De registers worden gebruikt om een byte naar de zend-fifo te
schrijven c.q. een byte uit de ontvangst-fifo te lezen.
De SNIC bevat meer dan de hier genoemde registers (totaal 16 stuksL Om deze
registers en de andere componenten van de ISDN Expres Card op de juiste manier in
te stellen wordt gebruik gemaakt van het bij de kaart meegeleverde programma IES
(Isdn Evaluation SoftwareL De instelling van aile componenten is nodig om te
voorkomen dat deze de werking van de SNIC verstoren. Het was niet mogelijk om de
sources van de IES in de ISDN-software in te bouwen. Aangezien de software
uiteindelijk op een zelfstandig terminal board moet draaien (zonder de ISDN-kaarten)
is geen eigen initialisatie-routine geschreven.
Naast de initialisatie van de componenten van de ISDN-kaarten kunnen met de IES in
een menugestuurde omgeving aile registers van aile componenten bekenen en
eventueel gewijzigd worden (zie hiervoor de handleiding van de ISDN-kaart [2] en het
MITEL databoek [3]).
3.2. De interrupthandlers
Het is in principe mogelijk om de SNIC te besturen zonder gebruik te maken van de
geleverde interrupt. In de software moet dan echter zeer frequent naar de registers
van de SNIC gekeken worden. Immers. als de ontvangst-fifo meldt dat er 15 bytes
verzameld zijn. dan is er nog maar 4 bytes tijd om te beginnen met het lezen van die
fifo, oftewel 2 msec (32 bit met een snelheid van 16 kbpsH Om deze overhead te
voorkomen wordt gebruik gemaakt van de interrupt die de SNIC levert.
Een SNIC-interrupt bereikt de PC als hardware interrupt 7. Deze veroorzaakt op z'n
beurt software interrupt 15. Met de C-constuctie
oldvecOF = getvect(15);
setvect(15. Sisr) ..
wordt ervoor gezorgd dat bij het optreden van deze interrupt de C-functie "SisrO"
(Snic Interrupt Service Routine) aangeroepen wordt. Deze functie dient als
interrupt-handler gedefinieerd te worden (void interrupt SisrO L In de variabele
oldvecOF wordt het adres van de oorspronkelijk met interrupt 15 verbonden routine
bewaard. Bij beEHndiging van de dispatcher kan daarmee de oorspronkelijke situatie
hersteld worden om te voorkomen dat de PC vastloopt.
14
De communicatie met de hardware
De op die manier door de SNIC aangeroepen functie leest het HDLC interrupt status
register van de SI\lIC en handelt al naar gelang de oorzaak van de interrupt.
Informatie wordt in pakketten (frames) verstuurd over het D-kanaal. Een pakket
wordt zonder pauzes verzonden. Het is dus van belang dat de interrupthandler direct
een byte beschikbaar heeft als de zend-fifo leeg dreigt te lopen en dat bytes die uit
de ontvangst-fifo gelezen worden ergens opgeslagen kunnen worden. Daarom wordt
gebruik gemaakt van buffers. Een buffer wordt als voigt gedefinieerd:
struct buffer{
\NOrd length;
byte infofMAXPKTSZJ;}
Het length-veld geeft aan hoeveel bytes er in de buffer staan. De informatie wordt
opgeslagen in het info-array. De waarde van MAXPKTSZ (Maximum Packet Size)
bepaalt hoeveel bytes er in een buffer kunnen. De waarde van MAXPKTSZ wordt
bepaald door de maximale lengte van een laag 2 pakket (264 bytes).
Een aantal buffers vormt samen de structure ram:
struct ram{
byte
struct buffer}
UsedfNUMBUFJ;
Buffe,.fNUMBUFJ;
Het Used-veld geeft aan welke buffers in gebruik zijn. De waarde van NUMBUF
bepaalt het aantal beschikbare buffers.
Als er iets verzonden moet worden, dan vraagt de software die de protocol len
implementeert een buffer aan bij het operating system. In die buffer wordt een
volledig pakket samengesteld. Vervolgens wordt de lengte van de buffer en het adres
van de informatie in die buffer doorgegeven aan een aantal globale variabelen zodat
aile functies die iets met het verzenden van informatie te maken hebben er gebruik
kunnen maken. Nadat het eerste gedeelte van de informatie in de zend-fifo
geschreven is wordt de zender enabled. Via de genoemde globale variabelen kan de
interrupthandler de rest van het pakket naar de zend-fifo schrijven als dat nodig is.
Als alles verzonden is wordt de buffer door de interrupthandler vrij gegeven.
Ook voor de ontvangst van informatie wordt een buffer gereserveerd. De
interrupthandler schrijft dit buffer vol tot het einde van het pakket ontvangen wordt.
15
De communicatie met de hardware
Daarna wordt het buffernummer doorgegeven aan een functie die de betekenis van het
frame in die buffer uitzoekt en afhankelijk daarvan een bericht stuurt naar een
proces. De interrupthandler vraagt een nieuwe buffer en kan meteen weer een pakket
ontvangen.
De door de CCITT gedefinieerde protocollen maken veelvuldig gebruik van timers om
vastlopen van het protocol te voorkomen. Er kunnen meerdere timers lopen. De PC
heeft echter maar een timer beschikbaar voor de gebruiker. Om toch meerdere
timers te kunnen gebruiken wordt de volgende structure gebruikt:
struct tim{
byte Used;
word MainTimer;
byte dest;
byte subdest;
word nuc/eo;}
Het Used-veld geeft aan of de timer in gebruik is. Het MainTirner-veld geeft aan hoe
lang de timer nog meet lopen. Het dest-veld geeft aan welk proces bericht krijgt als
de timer afloopt (subdest heeft aileen betekenis voor het laag 3 protocol), Het
nuc/eo-veld tenslotte bevat het bericht dat bij het aflopen van de timer verstuurd zal
worden. Een verzarneling timers staat in het array
struct tim TimerfMAXTIMERJ;
De waarde van MAXTIMER bepaalt het aantal beschikbare timers.
Een proces dat een timer nodig heeft zoekt een vrije timer en bezet die. Vervolgens
worden aJle velden ingevuld. De timer in de PC geeft op gezette tijden een interrupt.
Deze wordt net zoals de SNIC-interrupt omgeleid naar een eigen interrupthandler.
Steeds als deze interrupthandler aangeroepen wordt, worden aile timers bekeken. Van
de timers die in gebruik zijn wordt het MainTimer-veld met een verlaagd. Ais het
daarmee op nul komt, dan stuurt de interrupthandler het in de timer vastgestelde
bericht naar het vastgestelde proces en geeft de timer weer vrij.
16
De communicatie met de hardware
3.3. De problernenUit het verslag van mijn voorganger D. van Egmond [4] wist ik dat er nog problemen
waren met het oversturen van frames. Met name langere frames kwamen verkeerd of
helemaal niet aan. am de protocol len te kunnen testen was de dispatcher uitgebreid
zodat de toostanden van de processen en de verstuurde berichten, zo nodig "single
step", bekeken konden worden. am ook de verzonden frames, de optredende
interrupts en belangrijke variabelen te kunnen analyseren heb ik een nieuwe
"monitoring dispatcher" gemaakt. Een beschrijving van deze dispatcher is te vinden in
bijlage 2.
De spontaan vollopende ontvangst-fifo
Het eerste probleem deed zich voor bij het initialiseren van de ISDN Expres Cards
met de meegeleverde software. In verband met de synchronisatie moot een van de
kaarten als "terminal equipment (TE)" ge¥nitialiseerd worden en de andere als
"network terminal (NT)". De als NT gedefinieerde kaart genereert het kloksignaal. De
andere kaart synchroniseert zich op het binnenkomende signaal.
Het bleek dat aan een kant (de PC met de harddisk) de ontvangst-fifo spontaan vol
liep hoewel er aan de andere kant niets in de zend-fifo stond. Het verwisselen van de
NT- en de TE-functie bleek de enige remedie tegen dit probleem. Het verwisselen van
de kaarten had geen effect. Blijkbaar verloopt de samenwerking tussen de PC's en de
kaarten niet helemaal zoals het hoort.
Omdat de kaarten slechts een hulpmiddel zijn bij de ontwikkeling van de software (het
uiteindelijke doeI is een stand-alone terminal-board zonder die kaarten), is besloten dit
probleem te omzeilen door steeds de juiste plaats te kiezen voor de NT-en de
TE-functie. Voor een correcte werking moet PC met de harddisk als NT gedefinieerd
worden en de andere PC als TE.
Een gemlste RxFF-interrupt
Af en toe trad er aan de ontvangstkant een RxFO-interrupt op. Dit ondanks het feit
dat de interrupthandler ongehinderd z'n werk kon doon. Blijkbaar werd ergens een
RxFF-interrupt gemist.
De interrupthandler voor de SNIC-interrupt disablet de interrupts met de C-functie
disableO om te voorkomen dat interrupts elkaar onderbreken in een kritieke sectie.
De SNIC-interrupt wordt niet gebufferd. Het kan dus zijn dat de RxFF-interrupt
opgetreden is tijdens het uitvoeren van de interrupthandler en daardoor verloren is
gegaan. am dit te testen is in de interrupthandler een Ius ingebouwd. Nadat de
opgetreden interrupts behandeld zijn wordt daarmee steeds opnieuw het HOLC
interrupt status register bekeken totdat er geen enkele vlag meer gezet blijkt te zijn.
Aile tijdens de interrupthandler opgetreden interrupts worden daardoor opgevangen.
17
De communicatie met de hardware
Met de monitoring dispatcher is het mogelijk de opgetreden interrupts (de gelezen
waarden van het HDLC interrupt status register) te bestuderen. Daaruit bleek het
volgende. Tijdens het legen van de ontvangst-fifo na het optreden van een
RxFF-interrupt (als de fifo 15 bytes bevaO bevat de fifo op een gegeven moment 14
bytes. Het kan gebeuren dat er een nieuw ontvangen byte in de fifo geplaatst wordt
voordat de interrupthandler het volgende byte uit de fifo leest. Daardoor komt de fifo
weer op 15 bytes. Dit veroorzaakt opnieuw een RxFF-interrupt. Omdat de interrupts
disabled zijn wordt deze niet gedetecteerd. De betreffende vlag in het HDLC interrupt
status register wordt echter wei gezet. Als na het legen van de ontvangst -fifo niet
opnieuw naar het HDLC interrupt status register gekeken wordt, dan is de RxFF-vlag
na afloop van de interrupthandler dus gezet. De volgende keer dat de ontvangst-fifo
de 15 byte grens bereikt wordt er dan geen interrupt meer gegeven! De SNIC denkt
dat de interrupt al gegeven is omdat de vlag aI gezet is. Even later loopt de fifo over.
Dan wordt er wei een interrupt gegeven omdat de RxFO-vlag nog niet gezet was.
Het inbouwen van de Ius in de interrupthandler voorkomt het op deze manier missen
van een RxFF-interrupt.
Het dubbel ontvangen van een byte
Bij het versturen van een frame van een bepaalde lengte bleek steeds het laatste byte
dubbel ontvangen te worden. De laatste interrupt zorgde ervoor dat er 2 bytes uit de
ontvangst-fifo gelezen werden. Als het als gevolg van de laatste interrupt gelezen
aantal bytes niet 2 was, dan kwam het frame goed over.
De interrupthandler roept als er een RxFF- of EOPD-interrupt opgetreden is de
functie "receive_packetO" aan. Deze moet bytes uit de ontvangst-fifo lezen totdat de
fifo leeg is of het laatste byte van het frame bereikt is. Deze functie begint met het
lezen van een byte uit de fifo. Pas daarna wordt naar het HDLC status register
gekeken. Met behulp van dit register wordt onderscheid gemaakt tussen drie gevallen:
"niet het laatste byte", "Iaatste byte; goed frame" en "Iaatste byte; foutief frame". In
aile gevallen wordt nog een byte uit de ontvangst-fifo gelezen.
Fouten ontstaan als bij het optreden van de laatste interrupt nag slechts een byte in
de ontvangst-fifo staat. De functie "receive_packetO" leest dit byte. Daarna wordt
het HDLC status register gelezen. Na het lezen van het laatste byte uit de fifo wordt
de "betekenis van het eerste byte van de fifo" niet meer aangepast door de SNIC. De
functie "receive_packetO" vindt dus bijvoorbeeld de betekenis "Iaatste byte; geed
frame" en leest vervolgens nag een byte. Bij het lezen uit een lege fifo wordt het
laatste byte dat er in stond herhaald. Het laatste byte van het frame komt daardoor
dubbel aan.
Als gevolg van het eerder geschetste "15-14-15-probleem" kan de functie
"receive_packetO" ook midden in een frame aangeroepen worden bij een
ontvangst-fifo met lengte een of zelfs nul. Dit komt overeen met het probleem dat D.
van Egmond [4J bij het testen tegen kwam.
18
De communicatie met de hardware
De oplossing van het probleem is vrij eenvoudig. De functie "receive_packetO" moet
eerst kijken of er wei iets in de ontvangst-fifo staat (ook dit staat in het HDLC
status register). Zo ja, dan mag er gelezen worden. Daarbij moet steeds het HDLC
status register bekeken worden v66r er iets uit de fifo gelezen wordt.
Functies die beter niet onderbroken kumen worden
Bij het testen van de software bleek af en toe een interrupt verloren te gaan. Tevens
verliep de uitvoer naar het beeldscherm niet altijd even perfect. Het blijkt dat het
onderbreken van C-functies zoals "cprintfO" en "windowO" door een interrupt niet
altijd goed gaat. Vaak zullen deze functies de interrupts maskeren. Bovendien kan de
output die deze functies genereren bij onderbreking vervormd worden (bijv. een string
die in twee stukken over het scherm verdeeld wordO.
De functie "ShowActivityO" maakt intensief gebruik van deze functies.
"ShowActivity0 " wordt iedere dispatcher-slag aangeroepen om op het scherm aan te
geven dat de dispatcher bezig is. Door "ShowActivityO" aileen aan te roepen als er
niets verzonden of ontvangen wordt (dit kan afgeleid worden uit de globale variabelen
die de zend- en ontvangst-buffers beschrijven), werden de genoemde effecten
verholpen.
Kritieke secties
De interrupthandler voor SNIC-interrupts maakt gebruik van buffers. Verder worden
door deze interrupthandler en die voor timer-interrupts messages gegenereerd. De
interrupts kunnen op ieder moment optreden, dus ook als een andere routine bezig is
een buffer aan te vragen of vrij te geven of als de message-queue's gemanipuleerd
worden. Als er geen beveiliging ingebouwd was zou de administratie van de buffers en
de message-queue's daardoor behoorlijk in de war gestuurd kunnen worden. Om dat
te voorkomen worden de stukken code die met deze administraties werken als
kritieke secties behandeld. Dat wil zeggen dat tijdens deze stukken code de interrupts
disabled worden met de C-functie disableO. Aan het einde van een kritieke sectie
worden de interrupts weer enabled met de C-functie enableO.
Als er tijdens zo'n kritieke sectie een interrupt optreedt, dan wordt die niet
waargenomen en gaat verloren (interrupts worden niet gebufferdL De meeste kritieke
secties zijn kort. Het percentage van de tijd dat de processor met een kritieke sectie
bezig is is klein. Het daardoor optredende verlies van een enkele timer-interrupt heeft
dan ook geen significante gevolgen. Iedere seconde kent ongeveer 18 timer-interrupts,
dus een timer die een seconde moet lopen (de kortste timer in de CCITI-protocollen)
zal hooguit zo'n 5% langer lopen (het verlies van meerdere timer-interrupts binnen een
seconde is zeer onwaarschijnlijk).
19
De communicatie met de hardware
Het missen van een SI\JIC-interrupt heeft grotere gevolgen. Ais bijvoorbeeld de eerder
genoemde RxFF-interrupt verloren gaat. dan is de kans groot dat de ontvangst-fifo
overloopt. De ontvangst wordt dan afgebroken en de protocollen zullen voor
hertransmissie moeten zorgen. In de code was daarmee geen rekening gehouden.
Door na iedere kritieke sectie naar het HDLC interrupt status register te kijken en
indien nodig de interrupthandler aan te roepen, kunnen eventueel gemiste interrupts
a1snog behandeld worden.
Het blokkeren van ontvangst-interrupts bij hat vullen van de zend-fifoDe functie "xmtbuffO" heeft tot taak het starten van de transmissie van het frame
dat in een bepaalde buffer staat. Daarvoor worden de benodigde parameters
(geheugenadres van de informatie, lengte van het frame) doorgegeven aan de globale
variabelen van de SNIC-interrupthandler. Verder wordt het eerste gedeelte van het te
versturen frame in de zend-fifo geplaatst.
In de code werden veer het vullen van de zend-fifo de interrupts disabled. Daardoor
worden naast de zend-interrupts ook de ontvangst-interrupts van de SNIC en de
timerinterrupts geblokkeerd. Ais tijdens het vullen van de zend-fifo een ander frame
ontvangen wordt, dan zal dat hoogst waarschijnlijk fout gaan doordat bijvoorbeeld de
RxFF-interrupts niet behandeld worden.
Verder werd bij het vullen van de zend-fifo de zender niet disabled. Tijdens het vullen
van de zend-fifo werden dus al bytes verstuurd. Daardoor kunnen onnodige TxFL- en
fatale TxFU-interrupts ontstaan.
Om deze problemen op te lossen heb ik in de functie die de zend-fifo vult de
instructie "disableO" (disable interrupts) vervangen door de functie "disable_TENO"
(TEN staat voor Transmitter ENable, het bit in HDLC control register 1 waarmee de
zender enabled! disabled kan worden) die aileen de zender disabled. De functie
"zendenO" die gebruikt wordt om de zend-fifo te vullen zorgt er voor dat de zender
na het vullen van de zend-fifo weer enabled wordt.
Synchronisatieproblemen tussen de ISDN Expres Cards
Bij het versturen van lange frames bleek soms een schijnbaar compleet ander frame
aan te komen dan er verzonden was. Figuur 3.1 geeft het begin van het verzonden en
het ontvangen frame weer in hexadecimale vorm. Verder wordt de verzonden en de
ontvangen bitstroom weergegeven in de volgorde waarin de bits over de interface
ve,rstuurd worden.
20
De communicatie met de hardware
Verzonden:
00 05 03 01 02 03
00000000 10100000 11000000 1000000001000000 11000000
Ontvangen:
OF AO
1111000000000101
60 20 40 60
00000110 00000100 00000010 00000110
Rguur 3.1: Het resultaat van synchronisatJeprobiernen tussen de kaarten.
Ais we de verzonden en ontvangen bitstromen met elkaar vergelijken. dan blijkt dat
het verschil bestaat uit een verschuiving over 5 bits! De ontvanger begint 5 bits te
vroog. De "11110" aan het begin van het eerste ontvangen byte zijn de laatste vijf
bits van de openingsvlag waarmee ieder frame begint. Deze vlag heeft aileen betekenis
voor het laag 1 protocol. De SNIC moot dit protocol afhandelen en de gebruiker mag
van de gebruikte vlaggen en de frame-cheek-sequence eigenlijk niets merken.
Aangezien in de software steeds met gehele bytes gewerkt wordt, kan dit verschijnsel
niet aan een softwareprobleem te wijten zijn. De beide kaarten werken niet good
samen.
Naast de SNIC bevatten de kaarten onder andere nag een DNIC. Ook deze bouwsteen
dient voor het versturen en ontvangen van 192 kbps 2B+D-signalen. De DNIC maakt
echter gebruik van slechts een aderpaar. Met behulp van echo-canceling-technieken
wordt over dit ene aderpaar toch tegelijkertijd in twee richtingen informatie
getransporteerd.
Met behulp van HDLC control register 1 kan ingesteld worden of het D-kanaal via het
S-interface loopt of via de interne ST-bus op de kaart. Door te kiezen voor de
ST-bus en via de Digital Crosspoint Switch een verbinding tussen de SNIC en de
DNIC te maken. kan het D-kanaal via de DNIC verzonden/ontvangen worden.
Ais de kaarten op deze manier via de DNIC's i.p.v. via de SNIC's met elkaar
verbonden werden bleek het verschuivingsprobleem verdwenen te zijn.
Het tegelijk zenden en ontvangen van frames
Het kan voorkomen dat er tegelijkertijd een frame verzonden en een frame ontvangen
wordt. In dat geval zullen zend- en ontvangst-interrupts elkaar afwisselen. De
interrupthandler ontvangt een ongedifferentieerde interrupt van de SNIC. Vervolgens
worden de vlaggen in het HDLC interrupt status register een voor een bekeken. Ais
bijvoorbeeld de RxFF-vlag gezet is, dan leest de interrupthandler bytes uit de
ontvangst-fifo tot de fifo leeg is of het laatste byte van het frame bereikt is. Ais
gedurende die tijd de zend-fifo leeg dreigt te lopen genereert de SNIC een
TxFL-interrupt en zet de betreffende vlag in het HDLC interrupt status register.
21
De communicatie met de hardware
Deze interrupt wordt niet waargenomen omdat de interrupthandler de interrupts
disabled heeft. De eerder genoemde Ius in de interrupthandler zorgt ervoor dat de
gezette vlag alsnog opgemerkt en verwerkt wordt. Dat gebeurt echter pas nadat het
legen van de ontvangst-fifo voltooid is. Het legen van de ontvangst-fifo kan vrij veeI
tijd kosten waardoor de zend-fifo leeg kan lopen voor de verwerking van de
TxFL-interrupt begint.
Om dit probleem op te lossen heb ik een nieuwe interrupthandler geschreven voor de
SNIC-interrupts. De Ius voor het verwerken van interrupts die gedurende de uitvoering
van de interrupthandler optreden is gebleven. Binnen de Ius worden de vlaggen uit het
HDLC interrupt status register bekeken. Bij de afhandeling van TxFL- en RxFF-vlaggen
wordt echter slechts een byte geschreven c.q. gelezen. Het kan daardoor voorkomen
dat in het HDLC interrupt status register geen vlaggen meer gezet zijn terwijl er toch
nog bytes uit de ontvangst-fifo gelezen of naar de zend-fifo geschreven kunnen
worden. Daarom houden de variabelen "xmLready" en "rcv_ready" bij of er m.b.t. de
zender respectievelijk de ontvanger nog iets te doen valt.
Om de interrupthandler te bei:Hndigen moeten nu niet aileen aile vlaggen gestreken zijn.
ook moeten de genoemde variabelen aangeven dat er niets meer te doen valt.
Door de beschreven aanpak wordt de "aandacht" van de interrupthandler zo gelijk
mogelijk verdeeld over de zender en de ontvanger. De Ius in de interrupthandler is
kort genoeg om te voorkomen dat interrupts te laat in behandeling genomen worden.
Sarnenvatting
In dit hoofdstuk zijn de functie en de gebruiksmogelijkheden van de diverse registers
van de SNIC besproken. Ook kwamen de interrupts die de SNIC genereert en de
interrupthandlers die deze interrupts verwerken aan de orde. Tot slot zijn de
problemen die er waren bij de communicatie met de hardware en de gevonden
oplossingen toegelicht.
In het volgende hoofdstuk worden het laag 2 protocol (LAPD) besproken. De
implementatie kan nu gebruik maken van een werkende interface met de hardware die
het laag 1 protocol en een deel van de taken van laag 2 implementeert.
22
De datalinklayer
4. De datalinklayer
4-.1. Hat protocolLaag 2 is de datalink-Iaag. De datalink-Iaag zorgt voor het opzetten. onderhouden en
afbreken van foutloze verbindingen over het kanaal. Het door de CCITT gedefinieerde
laag-2-protocol voor het D-kanaal heet LAPD (Link Access Procedures on the
D-channel).
LAPD draait om zogenaamde "datalinks" (zie figuur 4.1), Een datalink is een logische
verbinding over het D-kanaal tussen twee "Data Link Connection Endpoints" (DLCE's),
Een DLCE bevindt zich in een "Service Access Point" (SAP). Een entiteit op laag 3
kan via zo'n SAP een bepaalde dienst bereiken van laag 2. Een SAP wordt aangeduid
met een "Service Access Point Identifier" (SAPI). De waarde van de SAPI geeft aan
welke dienst het SAP levert. Een SAP kan bijvoorbeeld dienen voor het versturen van
pakket-data (SAPI-waarde 16) of voor signaleringsdoeleinden (SAPI-waarde 0), Ieder
bericht dat over het D-kanaal verstuurd wordt bevat een SAPI-waarde om aan te
geven voor welk SAP het bericht bestemd is.
USER-SIDE NETWORK-SIDE
Nelwor~
TEI=8
!e-t---TE1= 12,
Network'
III
TEl =12, lE'1'f-f-
IIIIII
IIIIIIIIII..... - --
Network'
D-channel SAP]=16
Figuur 4.1: De conceptuele voorstelling van de dataiinks.
Er kunnen meerdere logische terminals gedefinieerd worden. Een logische terminal kan
bijvoorbeeld een telefoontoestel of een fax zijn. maar oak een proces in een
multitasking computersysteem. Logische terminals hoeven dus niet noodzakelijk
overeen te komen met fysieke apparaten.
23
De datalinklayer
Een logische terminal kan gebruik maken van meerdere SAP's. Omgekeerd kan een
SAP ook door meerdere terminal gebruikt worden. Daarom bevat ieder bericht naast
een SAPI-waarde ook een TEI-waarde (Terminal Endpoint Identifier) om aan te geven
voor welke logische terminal het bericht bestemd is. Er kunnen meerdere
TEI-waarden aan een terminal toegekend worden. Een SAPI en een TEl vormen samen
een "Data Link Connection Identifier" COLCn. Een datalink wordt eenduidig bepaald
door z'n DLCI.
De waarden van een TEl lopen van 0 tI m 127. De waarde 127, de group-TEl, is
gereserveerd voor broadcast-datalinks. Een broadcast-datalink is verbonden met aile
logische terminals die aan het gegeven SAP zijn aangesloten. De overige TEI-waarden
zijn verdeeld in twee groepen. De waarden 0 ..63 mogen door de gebruiker toegekend
worden. De waarden 64..126 worden via daarvoor gedefinieerde procedures bij het
netwerk aangevraagd.
De DLCE's zijn de entiteiten van laag 2. De entiteiten van laag 2 communiceren met
entiteiten van laag 1 en laag 3 en met het laag 2 management door middel van het
versturen van zogenaamde primitieven. Een laag 2 entiteit COLCE) kan in verschillende
toestanden verkeren. Een entiteit kan overgaan naar een andere toestand als gevolg
van het ontvangen van een primitieve of door een interne gebeurtenis (het aflopen van
een timer), De primitieven die de CCITT gebruikt bij de definitie van de protocollen
voor laag 2 hebben een uit drie delen opgebouwde naam. Het eerste deel geeft aan
over welk interface de primitieven uitgewisseld worden: DL voor primitieven tussen
laag 3 en laag 2 COataLink layer), PH voor primitieven tussen laag 2 en laag 1
(PHysical layer) en MDL voor primitieven tussen laag 2 en het laag 2 management
(Management DataLinkl. Het tweede deel is de eigenlijke naam die aangeeft wat de
betekenis van de primitieve is. Het derde deel geeft aan of het om een vraag gaat
(REQUEST), om een melding Ot\IDICATION), om een reactie (RESPONSE) op een
melding of om een bevestiging (CONFIRM) van een vraag. De gebruikte primitieven zijn
weergegeven in figuur 4.2.
De CCIn definieert 8 toestanden waarin een datalink kan verkeren. Figuur 4.3 geeft
een globale weergave van de toestanden en de mogelijke toestandsovergangen van een
datalink. Een datalink begint in de "TELunassigned"-toestand. De datalink beschikt
dan nog niet over een TEI-waarde en er kan dus geen informatie uitgewisseld worden.
Via de TEI-assignment-procedures kan de datalink over gaan naar de
"TELassigned"-toestand. Nu kan informatie uitgewisseld worden, maar er vindt geen
terugmelding en hertransmissie van foutief over gekomen frames plaats
(unacknowledged information transfer). Op initiatief van een van de beide zijden kan
een datalink overgaan naar de "Multiple_frame_established"-toestand. Dan kan
informatie uitgewisseld worden met terugmelding en hertransmissie (acknowledged
information transferl. Ais er een in het protocol opgenomen timer afloopt, dan gaat
de datal ink over naar de "Timer _recovery"-toestand.
24
De datalinklayer
De andere vier toestanden zijn overgangstoestanden waarin de datal ink wacht op een
antwoord van het management of de andere zijde van de dataJink.
De dataJinks hebben aJleen betekenis voor de lokale user-netwerk-interface. Laag 3,
de netwerk-Iaag, maakt gebruik van datalinks om informatie voor het opzetten,
onderhouden en afbreken van een verbinding door het ISDN naar het netwerk te
sturen. Daarbij gebruikt laag 3 aileen dataJinks die in de "Multiple_frame_established"
toestand verkeren. LAPD geeft dan aan aile frames een volgnummer. De ontvanger
van laag 2 frames meldt aan de afzender welke frames goed overgekomen zijn. Het
protocol zorgt ervoor dat frames bewaard worden tot ze bevestigd zijn. Frames die
fout overkomen worden opnieuw verstuurd. Bovendien houdt LAPD de verbinding in de
gaten. Ais gedurende langere tijd niets meer van de andere kant ontvangen wordt, dan
controleert LAPD of de datalink verbroken is en probeert die zo nodig te herstellen.
LAPD zorgt er dus voor dat laag 3 via een foutloze verbinding met het netwerk kan
communiceren zonder zich met de details van de lokale user-netwerk interface te
hoeven bezighouden.
naam
laag 3 ....---.... laag 2
DL_ESTABLISH
DL_RELEASE
DL_DATA
DL_UNIT-DATA
laag 2 ....---.... laag 1
PH_DATA
PH_ACTIVATE
PH_DEACTIVATE
laag 2 ....---.... management
MDL_ASSIGN
MDL_REMOVE
MDL_..ERROR
MDL_UNIT-DATA
MDL_XID
betekenis
opzetten van een verbinding voor laag 3
afbreken van een laag 3 verbinding
datatransport met hertransmissie
datatransport zonder hertransmissie
datatransport
kanaal aktiveren
kanaal is inactief
TEI-waarde aanvragen
TEI-waarde is niet meer geldig
foutmelding
communicatie met andere management-entiteit
identificatie
Aguur 4.2: De laag 2 primitJeven.
25
De datalinklayer
ESTABLISHAWAITING
TEl
TIMERRECOVERY
Rguur 4.3: Het toestandovergangsdiagram van een datalink.
4.2. De trnplernentatie
De datalinks worden ge'lmplementeerd als processen. In de proces-parameters worden
SAPI- en TEI-waarden van de data/inks bewaard. In de huidige implementatie wordt
aileen non-automatic-TEl-assignment toegepast. Dat wil zeggen dat de TEI-waarden
van de gebruikte datal inks door de gebruiker (de programmeur) gekozen worden. Dit
is gedaan omdat bij automatic-TEl-assignment een verbinding met een netwerk
noodzakelijk is voor het aanvragen van een TEI-waarde. Op de vakgroep is echter
geen netwerk voorhanden.
De primitieven door middel waarvan de datalinks communiceren worden
ge'implementeerd als messages. Een message kan slechts een beperkt aantal kleine
parameters mee krijgen. Een primitieve kan echter een grote hoeveelheid informatie
bevatten. Denk bijvoorbeeld aan de DL_DATA_REQUEST-primitieve dat wordt gebrulkt
om een compleet laag 3 frame aan laag 2 door te geven voor verzending over het
D-kanaal. Zo'n frame kan meer dan 200 bytes lang zijn. In het geval dat een dergelijk
grote hoeveelheid informatie meegegeven moet worden, wordt gebruik gemaakt van de
al eerder genoemde buffers. In plaats van de informatie zelf wordt het nummer van
de buffer die de informatie bevat meegegeven.
26
De datalinklayer
Voor de implementatie van het LAPD-protocol zijn de volgende processen gedefinieerd:
De processen LAPD_S1 en LAPD_S2 implementeren twee datalinks voor de
signalering voor de beide B-kanalen (SAPI-waarde 0).
Het LAPD_P-proces implementeert een datalink voor het versturen van pakket-data
over het D-kanaal (SAPI-waarde 16l.
Het MANAGEMENT-proces implementeert het laag 2 management. Dit proces beheert
de TEI-waarden en ontvangt en reageert op foutmeldingen en identiteitsvragen.
Het TRANSMISSION-proces tenslotte vormt de verbinding met laag 1 (de hardware).
Wanneer een proces een bericht over het D-kanaal wH versturen, dan wordt de
functie "txO" aangeroepen. Deze functie stelt het bij dat bericht behorende laag 2
frame samen en geeft dat frame via een PH_DATA_REQUEST-message door aan het
TRANSMISSION-proces. Het TRANSMISSION-proces buffert die frames en geeft ze
een voor een door aan de SNIC-interrupthandler om verzonden te worden.
4.3. De softvvare
De software voor de implementatie van de laag 2 protocollen was bij het begin van
mijn afstudeerperiode al geschreven. Doordat de communicatie met de hardware niet
vlekkeloos verliep was het nog niet (voldoende) mogelijk geweest de software te
testen.
Bij het controleren van de software ben ik uit gegaan van de tabellen D-lI Q.921 tI m
D-3/ Q.921 uit CCIn aanbeveling Q.921 [5]. In deze tabellen staan aile toestanden
van een datalink en aile mogelijke gebeurtenissen (binnenkomende primitieven, aflopen
van timers) opgesomd. Voor iedere combinatie van toestand en gebeurtenis staat
weergegeven wat er gedaan moet worden. Ik heb voor het gebruik van deze tabellen
gekozen omdat deze meer aansluiten bij de implementatie dan de tekst van Q.921. De
tekst is verdeeld in onderdelen zoals het opzetten van een verbinding of het versturen
van een frame. Uit de tabellen kan directer afgelezen worden wat de C-functies
moeten doen.
Verkeerde dimensionering
Bij het bestuderen van de datastructuren viel op dat de array's waarin de
message-queue's bijgehouden worden fout gedimensioneerd waren. De array's waren
gedeclareerd als
byte
byte
byte
struct mesage
InLecMenfMAXPRIOJ;
InEscMenfMAXPRlOJ;
LargoFifofMAXPRlOJ;
FifoMesagefMAXPRIOJfMAXMSGJ.
27
De datalinklayer
De constante MAXPRIO geeft het hoogste prioriteitsnummer (Iaagste prioriteiO aan
dat een proces kan hebben. Het laagste prioriteitsnummer is 0 en niet 1. Met deze
definitie wordt dus een message-queue te weinig gedeclareerd, namelijk die met
prioriteitsnummer MAXPRIO.
Het gevolg hiervan is dat de array's InLecMen, InEscMen en LargoFifo die het begin,
het eind en de lengte van de message-queue's bevatten, elkaar gaan overschrijven.
Bovendien kunnen berichten over andere globale variabelen, die direct na de array
FifoMesage in het geheugen staan, heen geschreven worden.
Het probleem is opgelost door in de declaraties MAXPRIO te vervangen door
MAXPRIO+1. De waarde van MAXPRIO zelf is niet veranderd omdat die in de rest van
de software nag verschillende malen (correct) gebruikt wordt.
De discard-functie
Berichten van laag 3 en van het laag 2 management worden verstuurd in zogenaamde
Information-frames (I-frames; acknowledged information transfer) en
Unnumbered-Information-frames (UI-frames; unacknowledged information transfer),
Ais er zo'n frame verzonden moet worden (bijvoorbeeld als gevolg van een
DL_DATA_REQUEST van laag 3) dan wordt het frame in een speciale UI- of I-queue
geplaatst. Tevens wordt een ULFRAME _I1'LQUEUE - of een
LFRAME_IN_QUEUE-bericht gegenereerd.
Soms gaat een datalink, bijvoorbeeld als gevolg van een timeout, terug naar een
toestand waarin geen UI- of I-frames verstuurd kunnen worden. In zo'n geval wordt
de functie "discardO" gebruikt om de nog uitstaande UI- en/ of I-frames te wissen.
Deze functie wiste echter aileen de frames uit de UI- en/ of I-queue's. De
bijbehorende ULFRAME_IN_QUEUE- en LFRAME_IN_QUEUE-berichten werden niet
gewist. Het gevolg is dat er frames verstuurd worden naar processen die niets met
die frames kunnen doen. Verder wordt op een gegeven moment gelezen uit een lege
UI- of I-queue.
De functie is daarom aangepast zodat tevens de betreffende berichten uit de
message-queue's gewist worden. Daardoor maakt de functie "discardO" nu niet meer
op de normale manier (via de daarvoor beschikbare f uncties) gebruik van de
message-queue's. Er is dan ook speciaal op gelet dat de berichten in de
message-queue's in de juiste volgorde blijven staan.
Keuzes
In de tabellen D-1 t/ m D-3 van Q.921 zijn op een aantal plaatsen keuzes ingebouwd.
Bij de implementatie moet gekozen worden voor een van de mogelijkheden.
Bij het ontvangen van een bepaald I-frame in de "multiple frame established"-toestand
moet een RR-respons of, indien voorhanden, een I-frame terug gezonden worden.
28
De datalinklayer
De I-frame-optie maakt het protocol iets sneller, maar bij het versturen van een
I-frame moet ook een LFRAME_IN_QUEUE-bericht uit de message-queue's
verwijderd worden en dat kost ook moeite en tijd. Ik heb ervoor gekozen om steeds
te antwoorden met een RR-respons alsof er geen I-frames aanwezig zijn. Dezelfde
keuze is gemaakt in de "timer recovery"-toestand.
Ais het laag 2 management een error-indication ontvangt, dan kan bij bepaalde
foutmeldingen gekozen worden tussen het controleren van een bepaalde TEI-waarde of
het verwijderen ervan. Het voordeel van het verwijderen van een TEI-waarde is dat dit
ook kan als in de opstelling geen netwerk aanwezig is. Voor het controleren van een
TEI-waarde moet aan de netwerkkant een TEI-adrninistratie aanwezig zijn. Deze
administratie en de voor het controleren benodigde procedures kunnen op een van de
beide PC's geimplementeerd worden. Voorlopig is echter gekozen voor het verwijderen
van de TEI-waarde zodat op beide PC's dezelfde implementatie van LAPD gebruikt kan
worden.
KJeinigheden
Verder zaten er nog een aantal kleinere foutjes in de laag 2 software.
Onder andere werd het LAPD_P-proces ge'initialiseerd in de "TELassigned"-toestand
met TEI-waarde 200, een illegale TEI-waarde.
Op een aantal plaatsen waren zaken als het stoppen van een bepaalde timer of het
discarden van UI- of I-frames overbodig. Soms ontbraken er acties zoals het
starten/ stoppen van timers, het discarden van frames of een toestandsovergang.
Het zetten van Substate-veld van een proces is aileen nodig als het proces overgaat
naar de "multiple frame established"- of de "timer recovery"-toestand. De andere
toestanden gebruiken geen substates. Het zetten van het Substate-veld kon daarom
op verschillende plaatsen weggelaten worden.
Proces-parameter nummer 8, genaamd "acknowledge pending", werd wei op 0 en 1
gezet. De parameter werd echter nergens gebruikt. Aile toekenningen aan deze
parameter zijn daarom verwijderd.
Bij acknowledged information transfer krijgen de verzonden I-frames een oplopend
volgnummer. Bij deze volgnummers wordt modulo 128 gerekend. Om te bepalen of
volgnummer "NR" "tussen" de grenzen "VA" en "VS" Iigt is de constructie "if
«VA<=NR) && (NR<=VS))" daarom niet voldoende. Voignurnmer 125 ligt bijvoorbeeld
wei tussen 120 en 3, maar wordt door het genoemde if-statement buiten beschouwing
gelaten. De conditie in het if-statement is daarom overal vervangen door de functie
"betweenO" die wei het gewenste resultaat oplevert.
29
De datalinklayer
4-.4-. Het. t.est.en van de soft.V\fare
Het testen van de software valt uiteen in twee delen. Ais eerste moet getest worden
of de software zich gedraagt zoals het protocol voorschrijft (statisch gedragL Ten
tweede meet gekeken worden of de software snel genoeg is om aan de in het \
protocol beschreven tijdslimieten te voldoen (dynamisch gedrag).
Statisch gedrag
Met de eerder genoemde uitbreiding van de dispatcher naar een monitoring dispatcher
is het mogelijk het gedrag van het protocol stap voor stap te volgen. Het is mogelijk
de timers te bevriezen zodat het stap-voor-stap bekijken van het protocol geen
onverwachte timeout-messages veroorzaakt. Zolang er geen berichten verloren gaan
en de software het protocol correct afhandeld hebben de timers geen invleed op het
verloop van het protocol en mogen dus bevroren worden.
Verder biedt de monitoring dispatcher de mogelijkheid om message-queue's,
frame-queue's en processen te bekijken en eventueel te manipuleren. Door processen
eigenhandig in een bepaalde toestand te brengen en vervolgens berichten in de
message-queue's te plaatsen kan de afhandeling van een specifiek bericht in een
specifieke toestand bestudeerd worden.
Met behulp van de monitoring dispatcher is een deel van het protocol getest. De
processen kennen 8 toestanden waarvan een aantal in verschillende sub-toestanden
verdeeld zijn. Voor iedere toestand zou de invloed van zo'n 4-0 berichten (met een
aantal parameters) bekeken moeten worden. Het kost dan ook te veel tijd om aile
combinaties uit te proberen. Wei is, met succes, geprobeerd een aantal datalinks op
te zetten en af te breken. Het versturen van informatie over de datalinks bleek geed
te werken, ook als over meerdere datal inks tegelijk gewerkt wordt.
Het statisch gedrag van de software is verder op source-code-niveau helemaal
getest. Daarbij is voor ieder combinatie van toestand en binnenkomend bericht
nagegaan of de functie, die bij het optreden van die combinatie aangeroepen wordt, de
acties implementeert die volgens de tabellen en de tekst van CCITI aanbeveling Q.921
uitgevoerd zouden moeten worden.
Dynamisch gedrag
De CCITI heeft bij de definitie van de laag 2 protocollen een aantal tijdslimieten
vastgesteld. Om overschreiding van deze iimieten vast te stellen en de daarvoor
bestemde procedures uit te kunnen voeren zijn een aantal timers in het leven
geroepen.
Met de monitoring dispatcher is het mogelijk om de afgelopen c.q. gestopte timers
naderhand rustig te bekijken. Van deze mogelijkheid is gebruik gemaakt bij het testen
van het dynamisch gedrag van het laag 2 protocol.
30
De datalinklayer
De kortste timer in het laag 2 protocol is de T200-timer. Deze timer loopt slechts 1
seconde. Na het aflopen van deze timer mag een nieuw frame verzonden worden c.q.
hertransmissie van een frame piaatsvinden. Het protocol moet dus snel genoeg
afgehandeld worden om ervoor te zorgen dat het antwoord op een ontvangen frame
binnen 1 seconde na het versturen van dat frame bij de zender aankomt. am de
software te testen heb ik daarom vanaf beide kanten 3 frames van maximale lengte
(I-frame met een informatieveld van 260 bytes) tegelijk verstuurd. Er zijn 3 laag 2
processen die dit zouden kunnen doen: LAPD_S1, LAPD_S2 en LAPD_P. Overigens
zijn de frames die de signaleringsprocessen te versturen hebben meestal veel korter.
Aile frames kwamen goed aan waarbij het frame dat het langst moest wachten in
0.72 a 0.78 seconden antwoord kreeg. De andere frames kregen na 0.61 a 0.68
respectievelijk 0.38 a 0.41 seconden antwoord. Zelfs in deze wat irreele worst-case
situatie blijkt het protocol dus onder de limiet te blijven.
De andere tijdslimieten in het laag 2 protocol zijn beduidend langer. Daar wordt dan
ook gemakkelijk aan voldaan.
Sat"l'"lenvatting
In dit hoofdstuk is een beschrijving gegeven van het laag 2 protocol voor het
D-kanaal. De toestanden van de datalinks en de primitieven die de CCIn in de
protocolbeschrijving gebruikt zijn besproken samen met de relatie tussen LAPD en
laag 3.
Na een beschrijving van de afbeelding van LAPD op het Oudelaar operating system zijn
een aantal fouten in de software besproken. Tenslotte kwam het testen van het
statische en het dynamische gedrag van de software aan de orde.
De uiteindelijke versie van de laag 2 software vormt een correct functionerende
implementatie van LAPD. De software biedt een betrouwbare basis voor de
implementatie van het laag 3 protocol. Deze implementatie wordt in het volgende
hoofdstuk beschreven.
31
De networklayer
5. De networklayer
Laag 3 is de netwerk laag. In eerste instantie is het de bedoeling dat de
ISDN-terminal die binnen de vagroep ontwikkeld wordt een telefoon-functie kan
vervullen. Daarvoor is het verzenden van pakket-data niet belangrijk. De implementatie
van laag 3 beperkt zich dan ook (voorlopig) tot het laag 3 signaleringsprotocol. Het
laag 3 signaleringsprotocol maakt gebruik van de diensten van laag 2. Verder
communiceert het laag 3 protocol met laag 4 en met het laag 3 management. Het
laag 3 protocol staat beschreven in de CCITT aanbevelingen Q.930 - Q.932 [6].
5.1. Het protocol
Het laag 3 protocol is, net zoals het laag 2 protocol, opgebouwd rond een aantal
entiteiten. Voor het opzetten van een telefoon-verbinding zijn de signaleringsentiteiten
het belangrijkst. Signaleringsentiteiten regelen het opzetten en afbreken van
verbindingen door het netwerk. Een signaleringsentiteit kan meerdere
netwerkverbindingen (zogenaamde calls) beheren.
Een call kan, net zoals een datalink, gezien worden als een toestand-machine. Een call
bevindt zich in een bepaalde toestand en kan, afhankelijk van binnenkomende
primitieven en het aflopen van timers, overgaan naar een andere toestand. Een call
wordt geidentificeerd door z'n call-reference-waarde. De call-reference-waarde van
een call is uniek binnen een datalink connectie (bepaalde DLCI) en heeft aileen
betekenis voor het lokale user-network-interface. Een speciale waarde van de
call-reference is de zogenaamde global-call-reference. Met deze waarde kunnen aile
calls binnen een datalink connectie tegelijk aangesproken worden.
De berichten die de calls over het interface versturen bevatten onder andere enkele
zogenaamde informatie-elementen. Er zijn verschillende typen informatie-elementen
voor het aangeven van de voortgang van een proces, de reden van een bepaalde actie,
het nummer van de aansluiting die men wi! bereiken, enzovoort.
Laag 2 communiceert niet met de afzonderlijke calls. Voor laag 2 bestaat aileen de
gehele laag 3 signaleringsentiteit. De laag 3 signaleringsentiteit moet berichten van
laag 2 zelf naar de juiste call(s) verder sturen.
5.2. De lrnplernentatle
De laag 3 entiteiten worden geimplementeerd als processen. Ze communiceren met
laag 2 entiteiten en met laag 4 via messages. De laag 3 management-functies zijn
niet in een apart proces ondergebracht. Voor de diensten van het management, die
hoofdzakelijk bestaan uit het beheren van call-references, zijn speciale functies
geschreven.
32
De networklayer
De belangrijkste processen van laag 3 zijn LAYER3_S1, LAYER3_S2 en LAYER3_P. De
eerst twee zijn signaleringsentiteiten. LAYER3_P is eigenlijk een pakket-data-entiteit.
Omdat de pakket-data-protocollen (nog) niet geimplementeerd zijn is dit proces
voorlopig ook als signaleringsentiteit gedefinieerd.
De signaleringsprocessen bevinden zich altijd in dezelfde toestand, de zogenaamde
LAYER3_INTERPRETER-toestand. De calls zijn niet als zelfstandige processen
geimplementeerd. Hun gedrag wordt echter wei, net zoals bij processen.
ge'implementeerd met state-tables en messages. Een call worden gedefinieerd met de
structure callentity:
struct cal/entity{
byte
byte
struct state}
cal/ref;
crflag;
far "State;
Het cal/ref-veld bevat de call-reference-waarde van de call. Het crflag-veld geeft aan
aan welke kant van het user-network-interface de call ge'initieerd is. Het State-veld
bevat een pointer naar het eerste element van de state-table van de huidige toestand
van de call. De calls staan samen in het array Call:
struct cal/entity Cal/fMAXCEJJfMAXCALLJ;
Hierin bepaalt MAXCEI hoeveel processen er zijn die in calls verdeeld zijn (CEI staat
voor Connection Endpoint Identifier; de laag 3 tegenhanger van de TElL MAXCALL
bepaalt het maximale aantal calls per proces.
Een laag 3 proces roept als gevolg van een binnengekomen bericht een functie aan.
Deze functie bepaalt aan de hand van het binnengekomen bericht welke call(s) bericht
krijgtl krijgen. Vervolgens zoek de functie, net zoals de dispatcher dat doet voor de
processen, in de huidige state-table van die call(s) naar het juiste bericht en voert de
bijbehorende functie uit. De functies in de state-tables van een laag 3 proces
gedragen zich dus als een soort mini-dispatchers.
R. Lemmens [7], die de laag 3 software geschreven heeft, had de calls ook in de
vorm van gewone dispatcher-processen kunnen implementeren. Het enige verschll met
de gekozen implementatie is dat de verwerking van een bericht voor een laag 3
proces dan onderbroken kan worden. De berichten voor de individuele calls worden
immers achteraan in een van de message-queue's geplaatst. Dit had, mocht het al
een probleem zijn. gemakkelijk verholpen kunnen worden door de message-queue met
de hoogste prioriteit voor deze call-berichten te reserveren. Aangezien de gekozen
implementatie geen problemen veroorzaakte, heb ik de implementatie niet veranderd.
33
De networklayer
Om veel administratie te voorkomen zUn de laag 3 processen gerelateerd aan een
vast laag 2 proces. LAYER3_S1 communiceert bijvoorbeeld met LAPD_S1 en niet met
LAPD_S2 en LAPD_P.
De laag 3 processen communiceren met de laag 2 processen via de reeds genoemde
DL_DATA-, DL_ESTABLISH- en DL_RELEASE-primitieven. Laag 4 bestaat voorlopig
uit slechts een proces, het CALL_CONTROL-proces. Dit proces heeft, ook voorlopig,
slechts een toestand, de CCOOO-toestand.
Bij communicatie met laag 4 wordt het nummer van de call (de index in het array
Call, dus niet de call reference) als parameter bij het bericht mee gegeven. De
call reference had ook gebruikt kunnen worden. Het interne nummer van de call heeft
echter a1s voordeel dat het bericht direct naar de betreffende call gestuurd kan
worden zonder dat eerst moet worden opgezocht welke call bij een bepaalde
call reference hoort.
5.3. De softVY'are
R. Lemmens [7] heeft de software voor de implementatie van het laag 3
signaleringsprotocol geschreven. Omdat tijdens de afstudeerperiode van R. Lemmens
nog geen werkende versie van het laag 2 protocol en de onderliggende hardware
beschikbaar was heeft hij de software niet in de praktijk kunnen testen.
Het aangeven van de aktieve call
De globale variabele CALLACT wordt gebruikt om aan te geven voor welke call op het
ogenblik berichten verwerkt worden. De functie "CaIlCtrltoLayer30" behandelt
berichten van laag 4 die bij een laag 3 proces binnenkomen. In het commentaar in
deze functie staat dat laag 4 de waarde van CALLACT niet verandert. Laag 4
communiceert met aparte calls en moet dus kunnen aangeven voor welke call een
bericht bestemd is. Daarom heb ik de software zo aangepast dat het nummer van de
bedoelde call in parameter 1 van het bericht wordt mee gegeven. In de functie
"CaIlCtrltoLayer30" wordt deze parameter naar CALLACT gecopieerd. Bij de aanvraag
van een nieuwe call wordt uiteraard geen call-nummer meegegeven. In dat geval kiest
de laag 3 een vrije call.
Deze call-nummer-doorgave is ook in de rest van de laag 3 software toegepast.
Informatie van! naar laag 4
Informatie die door/ aan laag 4 geleverd moet worden werd in de source-code van de
laag 3 software aileen in de vorm van commentaar beschreven. Om deze informatie
daadwerkelijk uit te kunnen wisselen heb ik de parameters van de messages gebruikt.
34
De networklayer
Parameter 1 geeft zoals gezegd aan voor welke call het bericht bestemd is. Andersom
wordt daarin aangegeven van welke call een bericht voor laag 4 afkomstig is.
Parameter 2 dient om gekozen B-kanalen aan te geven. De inhoud van parameter 2 is
gelijk aan de inhoud van het "channel-identification"-informatie-element. Deze
parameter wordt niet in aile berichten gebruikt.
Parameter 3 wordt gebruikt om redenen voor bepaalde gebeurtenissen door te geven,
voortgangsmeldingen te maken en om aan te geven welke timer er afgelopen is. Het
hangt van de situatie af of en zo ja waarvoor deze parameter gebruikt wordt.
Parameter 4 wordt gebruikt om foutmeldingen door te geven.
Met parameter 5 tenslotte kan de huidige calHoestand doorgegeven worden.
Nag niet geimplementeerd
Op de vakgroep ontbreekt de aansluiting op een echt netwerk. Bij het opzetten van
een verbinding moet de aanvrager het "called party address" opgeven en meesturen
met de verbindingsaanvraag. Door het ontbreken van een netwerk ontbreekt ook het
nummerschema dat gehanteerd zou moeten worden. Het "called party address" is dan
ook niet geimplementeerd.
Bij een binnenkomende call moet gecontroleerd worden of de gevraagde service
geleverd kan worden. Voorlopig wordt er van uit gegaan dat aile verbindingen
telefoongesprekken zijn. De controle wordt daarom niet uitgevoerd.
Ais een call verwezenlijkt is moeten op een gegeven moment de B-kanalen verbonden
worden met de informatiebron. Omdat de software uiteindelijk op een zelfstandig
terminal board moet lopen, waarop andere hardware beschikbaar is dan op de ISDN
Expres Cards, heb ik geen tijd gestoken in het uitzoeken van procedure die daarvoor
nodig is.
Keuzes
Net als bij het laag 2 protocol kunnen bij de implementatie van het laag 3 protocol
keuzes gemaakt worden.
Op een aantal plaatsen kan in de protocoldefinitie (Q.931 [6J) gekozen worden voor
het al dan niet versturen van een terugmelding (bijvoorbeeld RELEASE_COMPLETE of
COI\INECT_ACKNOWLEDGE) Deze terugmeldingen worden verstuurd.
Bij het afbreken van een verbinding kan op een aantal plaatsen gekozen worden voor
het direct versturen van een RELEASE_COMPLETE -bericht of voor het gebruik van de
normale procedure via de "release request"-toestand. Er is gekozen voor de normale
procedure.
Ais gevolg van een DL_RELEASE_INDICATION-bericht van laag 2 kan gekozen worden
voor het vrijgeven van de call-reference of voor het opnieuw proberen op te zetten
van de verbinding. Er is gekozen voor het vrijgeven van de call-reference.
35
De networklayer
De herstart-procedure
R. Lemmens heeft een "restart request" gedefinieerd van laag 4- naar een call op laag
3. Volgens figuur A-3 uit aanbeveling 0.931 komt een "restart request"-bericht
echter van "global call reference control" oftewel van de call met
callreference-waarde 0, de global callreference. De "restart confirm"-berichten, die
de calls na een geslaagde herstart versturen, moeten naar "global call reference
control" in plaats van naar laag 4-. De volgende oplossing is bedacht:
Zowel call-control Haag 4-} als "global call reference control" (Iaag 3; CaIlC ...J[o])
sturen hun "restart request"-berichten naar het betreffende laag 3 proces. Het laag
3 proces geeft, met behulp van de functie "CaIlCtrltoLayer30" de berichten door aan
de betreffende call (het nummer van de call staat in parameter 1 van het berichO.
De calls sturen hun "restart confirm"-berichten naar het proces waar het "restart
request"-bericht vandaan kwam (het call-control-proces of een laag 3 procesL
Daarbij wordt parameter 1 van het bericht op 0 gezet zodat berichten voor een laag 3
proces bij "global call reference contro'" aankomen. Op laag 4 wordt deze parameter
buiten beschouwing gelaten.
Op deze manier kunnen zowel laag 4 als "global call reference control" op laag 3 een
herstart uitvoeren. Laag 4 hoeft dit eigenlijk niet eens te kunnen. Hel enige
herstart-verzoek dat van buiten laag 3 komt is een "management restart request" en
dat komt van het systeem management. Een eventueel nog te implementeren
systeem-management-proces kan op de zelfde manier als een laag 4 proces een
herstart aanvragen.
NT versus TE
Op laag 3 is voor de netwerkkant (NT) een iets ander protocol gedefinieerd dan voor
de gebruikerskant (TEL R. Lemmens had het protocol voor de gebruikerskant
ge'implementeerd. Om de protocols te kunnen testen heb ik het netwerkkant-protocol
geschreven. De netwerkkant kent dezelfde toestanden als de gebruikerskant plus een
extra toestand. Aan de gebruikerskant worden de toestanden aangeduid met Uxx
waarbij xx staat voor het nummer van de toestand. Aan de netwerkkant worden ze
aangeduid met Nxx. Dit veroorzaakt een hoop extra declaraties in de software.
Daarom heb ik zowel de netwerk- als de gebruiker-toestanden hernoemd tot Sxx.
5.4-. Het testen van de laag 3 softVV'are
In de aanbevelingen voor het laag 3 protocol is geen tabel opgenomen waarin, zoals
voor laag 2. voor aile combinaties van toestanden en gebeurtenissen beschreven staat
wat er gedaan moet worden. Wei bevat aanbeveling 0.931 een weergave van het
protocol in de vorm van SDL-diagrammen.
36
De networklayer
Statisch gedragHet statische gedrag van de software is op source-code-niveau getest door aan de
hand van deze SDL-diagrammen na te gaan of de functies de juiste acties
implementeerden. Verder is de software getest door met behulp van de monitoring
dispatcher berichten te genereren en de reactie daarop van de software met de
SDL-diagrammen c.q. de tekst van aanbeveling 0.931 te vergelijken. De nu
geimplementeerde laag 3 software voldoet aan het protocol.
Dynamlsch gedragOm het dynamisch gedrag van de software te kunnen testen is voor laag 4 een
simpele functie geschreven die op bepaalde berichten een vast antwoord geeft. Met
deze functie is het opzetten en afbreken van een verbinding vanaf beide zijden van het
interface gesimuleerd. Het opzetten zowel aJs het afbreken van een verbinding is
binnen een halve seconde gebeurd. Daarbij is de tijd tussen "het overgaan van de be'"
en "het opnemen van de hoorn" niet meegerekend. Dit telt normaal ook niet mee,
tenminste niet voor de korte tijdslimieten.
De kleinste tijdslimiet die de CCln voor laag 3 gedefinieerd heeft bedraagt 4
seconden. Zelfs als aan beide zijden van het interface aile entiteiten tegelijk een
verbinding zouden willen opzetten en een entiteit zou moeten wachten op aile anderen,
dan nog zou het protocol ruim binnen de tijdslimieten blijven. De overige tijdslimieten
varieren van 10 seconden tot enkele minuten en zullen zullen zeker niet als gevolg van
trage software overschreden worden.
Sarnenvatting
In dit hoofdstuk is een beschrijving gegeven van het laag 3 protocol voor het ISDN
D-kanaal en het conceptuele model dat de CCln gebruikt bij het definieren van dat
protocol. Ook is besproken hoe dit protocol gei'mplementeerd is met behulp van het
Oudelaar operating system en enkele aanvullende datastructuren. Verder zijn de
problemen/ fouten die in de software zaten en de gevonden oplossingen en
aangebrachte wijzigingen aan de orde geweest. Tenslotte is het testen van de
software besproken.
De huidige implementatie van het laag 3 protocol werkt en kan gebruikt worden om
verbindingen op te zetten, en af te breken. De implementatie is echter nog niet
volledig zodat bijvoorbeeld het daadwerkelijk voeren van een telefoongesprek nog niet
mogelijk is.
37
Conclusies & aanbevelingen
6. Conclusies & aanbevelingen
Tijdens mijn afstudeerwerk is gebleken dat het uitvoerig testen van de gehele
software een van de belangrijkste onderdelen is van het ontwikkelen van een relatief
groot programma. Naarmate men dichter bij de basisfuncties van de software komt
blijken stellingen als "alles wat fout kan gaan zal vroeger of later ook fout gaan" en
"verbeter een fout en je zult meerdere nieuwe fouten vinden" steeds meer de
werkelijkheid te benaderen.
Moderne ontwikkel-omgevingen bevatten vaak zeer krachtige debuggers. Met name bij
de basisfuncties bleek echter dat een dosis gezond verstand en enige fantasie voor
het bedenken van zeldzame uitzonderingssituaties ook goed werken bij het opsporen
van fouten in de source-code.
Ais de basisfuncties goed werken blijkt het Oudelaar operating system een
betrouwbare en overzichtelijke basis te vormen voor de implementatie van de
ISDN-protocol len. De literatuurstudie (zie bijlage 1) heeft dan ook geen operating
systems opgeleverd die aanleiding geven tot het vervangen van het Oudelaar operating
system. Uit de verwerkingssnelheden die op een relatief trage IBM XT (4.77Mhz)
gehaald worden mag men afleiden dat dit operating system ook geschikt zal zijn voor
de implementatie van andere protocollen.
Op het ogenblik werkt de implementatie van de lagen 1, 2 en 3 van het ISDN protocol
goed. Ik verwacht dan ook dat protocol len voor laag 4 en hoger er zonder veel
problemen bijgemaakt kunnen worden. Het verdient wei aanbeveling om de, door
afwezigheid van een netwerkaansluiting, niet volledig geimplementeerde laag 3 eerst af
te maken.
Om de software overzichtelijk te houden verdient het aanbeveling toekomstige
protocollen zoveel mogelijk op het Oudelaar operating system af te beelden.
Subprocessen, zoals de calls op laag 3, die in aparte datastructuren ondergebracht
worden, veroorzaken een onoverzichtelijk geheel en kosten een hoop extra tijd en
moeite bij het implementeren. Er zijn geen dwingende redenen voor de gekozen
implementatie van de calls zodat het omschrijven ervan bij een optimalisatie van de
software zeker het overwegen waard is.
Ais de software op het terminal board geinstalleerd wordt, dan zullen met name de
interrupthandlers opnieuw geschreven moeten worden. Dit moot niet onderschat
worden. Maak zo min mogelijk aannames over het gedrag van hard- en software.
Houd rekening met de vele uitzonderingssituaties die op onvoorspelbare momenten op
kunnen treden doordat de externe hardware relatief onafhankelijk parallel aan de
software z'n werk doot.
38
Literatuurlijst
Literatuurl ijst
[1] Oudelaar H., IMPLEMENTATION OF A CCITT PROTOCOL ON AN ISDN
TERMINAL BOARD, afstudeerverslag EB222, vakgroep Digitale Systemen,
faculteit der elektrotechniek, Technische Universiteit Eindhoven, december
1989.
[2] Mitel Semiconductor, ISDN Expres Card User Manual, Canada, 1988.
[3] Mitel Semiconductor, MICROELECTRONICS DATA BOOK, issue 6, Canada,
1988.
[4] Egmond D.F. van, IMPLEMENTATION OF THE LINK ACCESS PROCEDURE ON
THE ISDN D-CHANNEL, afstudeerverslag EB348, vakgroep Digitale Systemen,
faculteit der elektrotechniek, Technische Universiteit Eindhoven, december 1991.
[5] CCITT, Recommendation Q.921, document of the 9th plenary assembly,
Melbourne, 14-25 november 1988, Blue Book, Fascicle VI.10 Geneve, 1989.
[6] CCITT, Recommendations Q.930-Q.932, document of the 8th plenary
assembly, Malaga-Torremolinos, 8-19 oktober 1984, Red Book, Fascicle VI.9,
Geneve, 1988.
[7] Lemmens R.J.M., IMPLEMENTATIE VAN HET ISDN LAAG 3
SIGNALERINGS-PROTOCOL VOOR HET D-KANAAL, afstudeerverslag EB308,
vakgroep Digitale Systemen, faculteit der elektrotechniek, Technische
Universiteit Eindhoven, april 1991.
39
BI.JLAGE 1: Literatuuronderzoek naar geschikte operating systems
BIJLAGE 1: Literatuuronderzoek naargeschikte operating systems(verslag van het bibliotheek-practicum)
1. De opdracht
1.1. De afstudeeropdracht
In moderne telecommunicatienetten vindt steeds meer digitale transmissie plaats. De
CCITT (Commite Consultatif International de Telegraphique et Telephonique)heeft een
geintegreerd netwerk (ISDN, Integrated Services Digital Network) gedefinieerd voor
volledig digitale transmissie van gebruiker tot gebruiker. Binnen de vakgroep Digitale
Informatiesystemen van de fakulteit Elektrotechniek aan de Technische Universiteit
Eindhoven is men bezig met de ontwikkeling van een gebruiker-terminal voor dit ISDN.
De functies van deze terminal zijn opgesplitst in lagen volgens het OSI-model (Open
Systems Interconnection). Voor de onderste drie lagen uit dit model zijn door de
CCITT protocol len gedefinieert. Binnen de vakgroep zijn deze protocol len reeds
gedeeltelijk gei'mplementeerd op twee PC's die voor dit doel van de benodigde
hardware voorzien zijn. Mijn afstudeeropdracht bestaat uit het afronden van deze
implementatie en het testen ervan.
1.2. De Iiteratuurstudie
De gedefinieerde protocol len zijn opgebouwd rond een aantal "entiteiten". Voor de
implementatie kunnen deze entiteiten gezien worden als processen op een computer.
Er moet een relatief groot aantal ("'15) met elkaar communicerende processen op een
processor gei'mplementeerd worden. Daarvoor is een speciaal operating system nodig.
Dat operating systeem moet:
- relatief veel processen kunnen beheren,
- de processen in staat stellen berichten uit te wisselen,
- de implementatie van timer en timeout-berichten ondersteunen,
- prioriteiten kunnen toekennen aan tijdkritische processen en
- snel kunnen reageren op hardware-interrupts.
Binnen de vakgroep is speciaal voor dit doel een operating systeem ontwikkeld. Dit
systeem vormt een geheel met de software voor de implementatie van de protocollen.
Dat is niet bevorderlijk voor de overzichtelijkheid en flexibiliteit van de gehele
implementatie.
In het kader van mijn afstudeeropdracht heb ik een literatuurstudie verricht naar
geschikte bestaande operating systems.
40
BIJLAGE 1: Literatuuronderzoek naar geschikte operating systems
2. Concept inhoudsopgave
De concept inhoudsopgave van het afstudeerverslag ziet er als voigt uit:
1) Inleiding
2) De opdracht
2.1) De uitgangssituatie
2.2) Het doel3) De fysische laag
4) De datalink-Iaag
4.1) Statisch gedrag: actie -+ reactie
4.2) Dynamisch gedrag: responstijden/ time-out's5) De netwerk-Iaag
6) Conclusies en aanbevelingen
Omdat het literatuuronderzoek meer een aanvulling dan een noodzakelijke
voorbereiding voor mijn afstudeeropdracht is, komen de Iiteratuurverwijzingen aileen
voor in de hoofdstukken 1 en 6 van mijn afstudeerverslag. Zij vormen een algemeen
overzicht van mogelijk te gebruiken operating systems en een aanbeveling voor keuzes
die bij de uiteindelijke implementatie in een stand-alone-terminal gemaakt kunnen
worden. Omdat de verwijzingen aileen in deze twee hoofdstukken voorkomen heb ik in
dit verslag geen aparte relatie-matrix opgenomen.
41
BIJLAGE 1: Literatuuronderzoek naar geschikte operating systems
3. Lijst van zoektermen
Voor de implementatie van de ISDN-protocol len is binnen de vakgroep een speciaal
operating system ontwikkeld. De tot nu toe geschreven software is opgebouwd rond
dit operating system. Bovendien worden er vrij zware eisen aan het operating system
gesteld. Het heeft dan ook weinig zin om te zoeken naar algemene principes en
grondslagen van operating systems. Daarom ben ik doelgericht gaan zoeken naar
bestaande operating systems die geschikt zijn voor de implementatie van de
protocollen.
Uit de opdracht komen de trefwoorden isdn, terminal, protocol, implementatie,
process, operating system, interrupt, priority, message-passing, real-time, scheduling
en multitasking naar voren.
Gebruik van de Thesaurus leverde in totaal de volgende lijst van trefwoorden op: isdn,
terminal, (multitasking) workstation, microcomputer, protocols, tokenpassing,
concurrency control, multiprocessing programs/systems, transaction processing,
pipeline processing, multiprogramming, computer software, multitasking, supervisory
programs, timesharing programs/systems, systems software, firmware, operating
systems, mainframes, interrupt, program processors, utility programs, job control
languages, unix, resource allocation, minicomputers, computer architecture,
programming environments, implementation, process, priority, message-passing,
real-time, online operation, scheduling en operations research.
Uit deze lijst heb ik de zoektermen operating systems, multiprocessing,
multiprogramming, multitasking, scheduling en supervisory gekozen.
De term operating systems is een vrij ruim begrip. Waarschijnlijk hebben veel
publicaties die iets met operating systems te maken hebben deze term in de titel
staan. De kans is dan ook groot dat deze term interessante publicaties oplevert.
De termen multiprocessing, multiprogramming, multitasking en scheduling zijn
specifieker. Zij zullen naar verwachting minder publicaties opleveren. Zij vangen echter
wei die publicaties die specifieker ingaan op deze aspecten van een operating system
en daardoor niet onder de algemene term operating systems verschijnen.
De term supervisory, vaak gebruikt in samenhang met control en software, bestrijkt
die publicaties die niet zo zeer over een volledig operating system gaan, maar meer
over systeemprogrammatuur die gebruikt kan worden voor de implementatie van een
aantal communicerende processen op een processor.
42
BIJLAGE 1: Literatuuronderzoek naar geschikte operating systems
4. Geraadpleegde bronnen
4.1. De Science Citation Index
Als eerste heb ik de Science Citation Index geraadpleegd. Het gaat om operating
systems die op een microcomputer werken. Daarom heb ik me beperkt tot de
afgelopen tien jaar. Daarvoor was de microcomputermarkt zeer beperkt en operating
systems voor mini's en mainframes zijn vaak erg machine-specifiek en niet geschikt
voor de huidige microprocessors.
De term operating system (al dan niet aan elkaar, met een verbindingsstreepje en/ of
in meervoudl leverde in eerste instantie via de Permuterm Subject Index 365
referenties op. Na gebruik van de Source Index bleven er daarvan 85 over. De rest
had met chirurgie te maken, was getiteld ..... system ... operating in/ at! under ..:' of
was duidelijk niet interessant (ms-dos e.d.l.
De termen multl~)rocessing, multJ~)rogramming en multitasking leverden in eerste
instantie 103 referenties op waarvan er na raadpleging van de Source Index nog 22
van overbleven.
De termen scheduling en supervisory leverden niets op.
4.2. VUBIS
Ook hier heb lk me beperkt tot werken vanaf ongeveer 1980.
De term operating systems leverde in eerste instantie 173 titels op. Daarvan bleven er
bij het bekijken van de individuele titels 25 over.
De termen multiprocessing, multiprogramming en multitasking leverden in eerste
instantie 55 titels op waarvan er bij het bekijken van de Utels slechts 4 overbleven.
Vele werken behandelen de verwerking van een aantal onafhankelijke processen.
De term supervisory leverde 47 titels op waarvan er 2 overbleven.
De term sc:hedule(jngJ tenslotte leverde maar liefst 233 titels op, waarvan er echter
maar 3 enigszins interessant waren. De rest had niets met computers te maken,
behandelde een starre time-sharing scheduling, was van toepassing op
multiprocessor-systemen of maakte veronderstellingen over verdelingen van aankomst
en/ of verwerkingstijden van de te verwerken jobs.
4.3. Computer & Control Abstracts
De Computer & Control Abstracts heeft geen aparte rubriek over multiprocessing,
multitasking, multitasking en scheduling. De term supervisory wordt expliciet in de
rubriek operating systems ondergebracht.
Het doornemen van de rubriek operating systems leverde slechts 11 artikelen op die
interessant zouden kunnen zijn. Daarvan bleek slechts een artikel ook werkelijk
interessant te zijn. De andere artikelen waren te algemeen/ abstract of de beschreven
operating systems waren te machine-specifiek of voldeden niet aan de gestelde eisen.
43
BIJLAGE 1: Literatuuronderzoek naar g'eschikte operating systems
5. Selectiecriteria
Bij het selecteren van publicaties voor de definitieve literatuurlijst heb ik de volgende
regels gehanteerd:
-- Aangezien er reeds een werkend operating system bestaat heeft het geen zin
meer om naar allerlei abstracte principes en methoden te zoeken voor het
implementeren van een operating system. De gevonden publicaties moeten dus een
concreet operating system beschrijven.
-- Het uiteindelijke doel van het project binnen de vakgroep is het maken van een
zelfstandige ISDN-terminal. Daarom hoeft het gebruikte operating system geen
uitgebreide input! output mogelijkheden te hebben voor disk en beeldscherm. Een
operating system dat slechts bestaat uit een kleine schil rond de hardware kan dus
ook interessant zijn.
-- Uiteraard moet het beschreven operating system voldoen aan de in de opdracht
gestelde eisen: veel processen, goede onderlinge communicatiemogelijkheden,
prioriteitstoekenning, timers/ events en snelle interrupt-handling.
-- Het operating system moet op een gangbare processor geimplementeerd zijn of
kunnen worden.
-- Operating systems die slechts bestaan uit een set basisfuncties moeten in een
gangbare taal, zoals C of Pascal, geprogrammeerd zijn. In ieder geval moeten ze
makkelijk vanuit zo'n taal gebruikt kunnen worden.
6. Sneeuwbal/ citatie
6.1. De sneeuwbalmethocle
Onder de in eerste instantie geselecteerde publicaties bevinden zich veel artikelen die
een bepaald operating system behandelen aan de hand van eigen tests en ervaringen
van de auteur van het artikel. Deze artikelen geven een goede indruk van de
mogelijkheden van het beschreven operating system, maar bevatten in de regel geen
of weinig referenties. Verder wordt vaak verwezen naar boeken over de principes van
operating systems of naar publicaties over de gebruikte hardware of
programmeeromgeving. De sneeuwbalmethode leverde dan ook weinig op. Het resultaat
staat in figuur 1.
6.2. De citatiemethode
De gevonden publicaties beschrijven een operating system. Publicaties die daarnaar
verwijzen gaan meestal over toepassingen waarbij dat operating system gebruikt
wordt. Zij voegen dus meestal niets toe aan de beschrijving van het operating system.
Ook de citatiemethode leverde dan ook weinig op. Het resultaat staat in figuur 2.
44
BJ~ILAGE 1: Literatuuronderzoek naar geschikte operating systems
IBM Syst. J. IBM Syst. J.no. 4, p. 326-345 no. 4, p. 361-382
RT PC Tech.-) RT PC Tech.-p. 119-125 p. 142-148
Computer Designno. 7, p. 65-70
TUE, Dig. Sys.ARL86ELE(504B)
Byte. no. 2p. 279-334
Byte, no. 10p. 295-298
Byte. no. 7p. 259-270
Byte. no. 8p. 281-283
19911990 Byte, no. 9
p. 423-42619891988
1987 Byte. no. 3,p. 228-232
1986
1985 AT&T Tech. J.no. 1, p. 251-268
1984
1983
1982Figuur 1. Het resultaat van de sneewbalmethode.
19911990 rsY"te, no. 9
IE.:.. 423-426Byte, no. 8p. 281-283
Byte, no. 10p. 295-298
Byte, no. 2p. 279-334
Byte, no. 7p. 259-270
19891988
1987 Byte, no. 3,p. 228-232
TUE, M&RARL87ELE(5209)
/
IBM Syst. J. IBM Syst. J.no. 4, p. 326-345 no. 4, p. 361-382
1986 IEEE Microno. 4, p. 8-17
TUE, Dig. Sys.ARL86ELE(5048)
1985 AT&T Tech. J.no. 1, p. 251-268
RT PC Tech.-) RT PC Tech.-) Computer Designp. 119-125 p. 142-148 no. 7, p. 65-70
1984
1983 Electronicsno. 6, p. 105-111
1982Figuur 2. Het resultaat van de citatiemethode.
• ) ongedateerde werken van 1987 of eerder
45
BIJLAGE 1: Literatuuronderzoek naar geschikte operating systems
7. Conclusies
Vanwege de vrij zware eisen, die aan het operating system gesteld worden,
verwachtte ik niet veel geschikte operating systems te vinden. Toch bleek er een
redelijk aantal operating systems te bestaan dat zonder veel problemen gebruikt zou
kunnen worden. In totaal heb ik 10 bruikbare operating systems gevonden en 3 sets
van basisroutines die eveneens gebruikt kunnen worden voor de implementatie van de
ISDN-protocollen.
Het verschil tussen verwachting en resultaat komt waarschijnlijk door de erg
specifieke eisen die aan het operating system gesteld worden. De geschikte operating
systems worden niet op grote schaal gebruikt en er wordt relatief weinig over
gepubliceerd. Daardoor komt het bestaan ervan pas aan het Iicht als je er gericht
naar zoekL
Door het specifieke karakter van het literatuuronderzoek waren de zoektermen die
gebruikt konden worden vrij ruim voor het beoogde doe!. Daardoor is het aantal
publicaties in de definitieve Iiteratuurlijst relatief klein Lo.v. het aantal in eerste
instantie gevonden referenties.
Het grootste deel van de gevonden publicaties zijn artikelen die een bepaald operating
system introduceren. Dergelijke artikelen verwijzen in de regel niet naar elkaar en ze
worden ook zelden aangehaald door anderen. Daardoor hadden de sneeuwbal- en de
citatie-methode weinig resultaaL
AI met al heeft het literatuuronderzoek toch succes gehad. Er zijn een aantal
operating systems gevonden die, voor zover dat uit de publicaties te beoordelen valt,
als alternatief voor het huidige operating system gebruikt kunnen worden.
Voor eventueel verder onderzoek verdient het aanbeveling te kijken naar proefschriften
(het ontwikkelen van een operating system past redelijk binnen het tijdsbestek van een
promotieonderzoekL Verder zou de COMPENDEX database, die veel rapporten van
wetenschappelijke instituten bevat, gebruikt kunnen worden.
46
BIJLAGE 1: Literatuuronderzoek naar geschikte operating systems
8. Literatuurl ijst
1) Evanczuk, S.
Real-time operating systems: A special report.
Electronics, Vol. 56(1983), No.6, p. 105-111
2) Little, J.
A module approach to microcomputer operating systems.
Computer Design, Vol. 23(1984), No.8, p. 217, 218, 220-222. 224
3) Sager, G.R. et al.
The Oryxl Pecos operating system.
AT&T Technical Journal. Vol. 64(1985). No.1, p. 251-268
4) Ready, J.F.
VRTX: A real-time operating system for embedded microprocessor applications.
IEEE Micro, Vol. 6(1986), No.4, p. 8-17
5) Levitt, J.
Wendin's operating system toolbox.
Byte, Vol. 12(1987), No.3, p. 228-230, 232
6) Loucks, L.K. et al.
Advanced Interactive Executive (AIX) operating system review.
IBM Systems Journal. Vol. 26(1987), No.4, p. 326-345
7) Smith, B.
From a tiny kernel. .. : getting from OS-9 to OS-9000 involves more than
adding three zeros.
Byte, Vol. 15(1990), No.9, p. 423, 424, 426
8) Yager, T.
The QNX operating system: A real-time Unix-like operating system for the
low-end PC.
Byte, Vol. 15(1990), No.8, p. 281-283
9) Yager. T.
Theos: serious business: A multiuser operating system with a database engine.
Byte. Vol. 15(1990), No. 10, p. 295, 296. 298
47
BlJLAGE 1: Literatuuronderzoek naar geschikte operating systems
10) Parker, M.B.
First come, first served : Mailbox is a portable multitasking environment written
in C.
Byte, Vol. 13(1988), No.7, p. 259, 260, 262, 264, 265, 268-270
11) Grehan, R.
Multitasking for the masses.
Byte, Vol. 15(1990), No.2, p. 279, 280, 282, 284, 286, 288, 334
12) Duijkers, L.J.M.H.H.
Implementatie van een multitasking operating system (de LEX).
Technische Universiteit Eindhoven, fakulteit Elektrotechniek, vakgroep Digitale
Systemen, 1986
13) Ven, van de P.H.J.
PSOS voor het practicum proces computer systemen : een real-time OS voor
de 68000-familie.
Technische Universiteit Eindhoven, fakulteit Elektrotechniek, vakgroep Meten &Regelen, 1987
14) Cordell, R.Q. et al.
Advanced Interactive Executive program development environment.
IBM Systems Journal, Vol. 26(1987), No.4, p. 361-382
15) Lang, T.G. et al.
The virtual resource manager.
RT Personal Computer Technology, pp. 119-125
SA23-1057, IBM corporation, available through IBM branch offices
16) Loucks, L.K.
IBM PT PC AIX kernel - modifications and extensions.
RT Personal Computer Technology, pp. 142-148
SA23-1057, IBM corporation, available through IBM branch offices
17) Suydam, W.E.
Off-the-shelf software tackles realtime tasks.
Computer Design, Vol. 24(1985), No.7, p. 65, 66, 68, 70
48
BIJLAGE 2: Handleiding van de monitoring dispatcher
BIJLAGE2:Handleiding van de monitoring dispatcher
1. Inleiding
De monitoring dispatcher is een uitbreiding van de functie "dispatcherO" uit figuur
2.4. De monitoring dispatcher kent twee toestanden: "running" en "halted".
In de "running"-toestand is de dispatcher aktief en worden er berichten verwerkt.
Afhankelijk van de instellingen van de gebruiker worden daarbij berichten, processen
en! of frames zichtbaar gemaakt.
In de "halted"-toestand ligt de dispatcher stil. Er worden geen berichten verwerkt dus
geen van de processen maakt voortgang. Ook worden aile timers stilgezet. De
interrupthandlers blijven echter gewoon hun werk doen. In de "halted"-toestand kan de
gebruiker de processen, berichten, enzovoort bestuderen c.q. manipuleren.
De monitoring dispatcher kan op twee manieren overgaan van de "running" -toestand
naar de "halted"-toestand:
al als het door de gebruiker opgegeven aantal dispatcher-slagen (gedurende een
dispatcher-slag verwerkt de dispatcher een bericht mits er berichten aanwezig zijnl
uitgevoerd is en
bl als de gebruiker een toets indrukt.
Deze overgang vindt steeds plaats tussen twee dispatcher-slagen in. Een
dispatcher-slag kan niet door de gebruiker onderbroken worden.
De overgang van de "halted"-toestand naar de "running"-toestand gebeurt op
commando van de gebruiker.
2. De indeling van het scherrn
Het scherm is verdeeld in vijf vensters (zie figuur B2.1)' Onderaan het scherm
bevinden zich van links naar rechts het status-venster. het commando-venster en het
activity-venster. Daarboven staat links het message-venster en rechts het
frame-venster.
In het status-venster worden een aantal instellingen van de dispatcher weergegeven.
De aanduiding "Ti" geeft weer of de timers enabled zijn (El, disabled zijn (ol of in
stapjes aflopen (5l.
De aanduiding "Me" geeft weer of de berichten (messagesl getoond worden met de
resulterende toestandsovergangen (5tatechangesl, zonder de resulterende
toestandsovergangen (No statechangesl of helemaal niet Onvisablel. Het cijfer geeft
een grens aan. Berichten worden aileen getoond als de oorsprong of de bestemming
ervan een prioriteitsnummer heeft dat groter of gelijk is aan deze grens.
49
BI..JLAGE 2: Handleiding van de monitoring dispatcher
De aanduiding "Fr" tenslotte geeeft aan of frames getoond worden in volledige vorm
(Visable), in beknopte vorm (Short) of helemaal niet Onvisable).
DL DATA F~EQUEST
LA7ER3 ~1 --) LAPD 51(MULTIPLE FRAME ESTABLISHED --> MULTIPLE FRAME ESTABLISHED) OutoQina laver2 frame:
Leiiath:..r 18 :
Rguur 82.1: De indeling van het scherm van de monitoring dispatcher
Het commando-venster wordt gebruikt om mogelijke commando's te laten zien,
mededelingen te doen of informatie in te voeren.
Het activity-venster geeft aan of de dispatcher actief is. Bij iedere dispatcherslag
verspringt de asterisk in dit venster.
In het message-venster worden de te verwerken berichten getoond.
Het frame-venster toont de inkomende en uitgaande laag 2 frames. De grens tussen
het message-venster en het frame-venster is niet speciaal aangegeven.
3. Het hoofdrnenu
Ais de dispatcher vanuit de "running"-toestand in de "halted"-toestand komt, dan
geeft het commando-venster het hoofdmenu weer: "Quit View Go Manipulate Set
Buffer Reset <space> <return>".
De opties "<space>" en "<return>" staan voor de spatiebalk respectievelijk de
return-toets. Beiden zorgen ervoor dat de dispatcher overgaat naar de
"running"-toestand. De return-toets geeft aan dat de dispatcher na een slag terug
moet keren in de "halted"-state. De spatiebalk geeft de dispatcher de vrije loop (het
gewenste aantal dispatcher-slagen wordt op oneindig gezetl. Om terug te keren naar
de "halted"-toestand moet dan een toets ingedrukt worden. De andere opties kunnen
gekozen worden door het intoetsen van de eerste letter ervan (zonder return). Dit
geldt trouwens voor aile keuze-menu's.
De "Quit"-optie beeindigd de dispatcher. De ingestelde interruptvectors worden op hun
oude waarde teruggezet en de PC keert terug naar DOS (of de TurboC-omgevingL
De "Go"-optie biedt de mogelijkheid om in te geven hoeveel slagen de dispatcher moet
uitvoeren. Na de ingave gaat de dispatcher over naar de "running"-toestand, voert het
opgegeven aantal slagen uit en keert dan terug in de "halted"-toestand.
so
BI"ILAGE 2: Handleiding van de monitoring dispatcher
De "Reset"-optie wist aile buffers, message-queue's en frame-queue's en plaatst de
processen weer in hun initiele toestand.
4. Het bekiJken van
Met de "View"-optie uit het hoofdmenu kunnen enkele datastructuren, de toestand van
de SNIC, de al dan niet afgelopen timers en de opgetreden interrupts bekeken
worden. Het view-menu ziet er als voigt uit: "view: Proces, Message, Frame, Timer,
Snic, DscRam or Int?".
Processen
De "Proces"-optie vraagt eerst naar het bedoolde proces. Rechts op het scherm
verschijnt een keuze-venster met daarin de namen van aile processen. Kies een
proces door met de pijltjes de keuze-balk (diapositief weergegeven procesnaam) naar
het gewenste proces te verplaatsen en vervolgens op de return-toets te drukken.
Ais het gekozen proces een laag 3 proces is, dan moet een specifieke call gekozen
worden. Toets "0", ''1'' of "2" om de gewenste call aan te geven. De naam, de
toestand en de parameters van het gekozen proces (call) worden vervolgens in een
apart venster weergegeven. Druk op een toots om terug te keren naar het
hoofdmenu.
Messages
De "Message"-optie uit het view-menu geeft in een apart venster weer hoeveel
berichten er in iedere message-queue zitten. Met "0", ''1'' en "2" kan een
message-queue geselecteerd worden. Ais de queue niet leeg is, dan wordt daarop het
eerste bericht in die queue (het bericht dat het eerst verwerkt zal worden)
weergegeven. Met "+" en "-" kan door de queue gebladerd worden. Met de spatiebalk
keert men terug naar het hoofdmenu.
Frames
De "Frame"-optie uit het view-menu geeft in een apart venster aan hoeveel 1- en
UI-frames er in de queue's van ieder laag 2 proces staan. Van links naar rechts zijn
dat de queue's van LAPD_P, LAPD_S1, LAPD_S2, MANAGEMENT en TRANSMISSION.
Druk een toets om terug te gaan naar het hoofdmenu.
Timer
De "Timer"-optie uit het view-menu dient voor het bekijken van lopende en gestopte
timers. Ais eerste kan men kiezen voor de lopende (running) of de gestopte (stopped)
timers.
51
BIJLAGE 2: Handleiding van de monitoring dispatcher
Bij keuze voor de lopende timers wordt in een apart venster de eerste lopende timer
zichtbaar gemaakt (als er een lopende timer is). Met "+" en "-" kunnen ook de
andere lopende timers bekeken worden.
Bij keuze voor de gestopte (en afgelopen) timers verschijnt in een apart venster een
Iijst van (maximaal) de laatste 12 gestopte/ afgelopen timers. Van die timers worden
de timeout-melding, het bestemmingsproces van die melding en de nog resterende tijd
On kloktikken: 18.2 per seconde) weergegeven. Met deze resterende tijd kan bepaald
worden hoe lang de timer gelopen heeft. Bij het terugkeren naar het hoofdmenu kan
de Iijst van gestopte timers gewist worden met "C". ledere andere toets laat de lijst
intact.
Snlc
De "Snic"-optie uit het view-menu toont de inhoud van een aantal status- en
control-registers van de SNIC. Het "C-channel status register" is een synchroon
register dat eigenlijk aileen gelezen mag worden als het NDA-signaal van de SNIC laag
is (zie het Mitel databoek [3]). De aangegeven waarde voor dit register is dan ook
niet gegarandeerd.
DscRarn
De "DscRam"-optie uit het view-menu geeft aan welke buffers voor het zenden en
ontvangen van frames gebruikt worden en hoeveel er al gelezen/verzonden is. Toon
deze datastructuur voor het eerste gebruikt werd, maakte men gebruik van het ISDN
Terminal Board. Daarop vormde een "Digital Subscriber Controller" de hardware-link
met het ISDN. Vandaar de "Dsc" in "DscRam".
Int
De "Int"-optie uit het view-menu geeft informatie over de SNIC-interrupts die
opgetreden zijn. Iedere keer dat de SI\IIC-interrupthandler aangeroepen wordt, wordt
een nieuwe regel aan de tabel toegevoogd. Een regel bestaat van links naar rechts uit
de volgende onderdelen. Helemaal links staat de waarde die uit het HDLC interrupt
status register gelezen is. Daarnaast staat het een waarde die aangeeft wat er
binnen de while-Ius van de interrupthandler gedaan is. De waarde is de som van
enkele van de volgende (hexadecimale) componenten:
01: Het eerste byte van een frame is ontvangen.
02: Er is een ander byte ontvangen,
04: Een byte (niet het eerste van een frame) is ontvangen terwijl de ontvanger
niet bezig was,
10: Laatste byte ontvangen; foute frame-check-sequence,
20: Laatste byte ontvangen; goode frame-check-sequence en
40: De ontvangst-fifo is leeggelezen.
52
BIJLAGE 2: Handleiding van de monitoring dispatcher
Daarnaast staan de aantaJlen bytes die aan het eind van de interrupthandler ontvangen
zijn respectievelijk nog verzonden moeten worden. De rest van de regel geeft de
vlaggen weer die aan stonden in het HDLC interrupt status register.
Met de pijltjes kan door de tabel heen gescrolld worden. Bij het terugkeren naar het
hoofdmenu kan met "C" de tabel gewist worden. Iedere andere toets laat de tabel
intact.
s. Het rr1anTpuleren van
Met de "Manipulate"-optie uit het hoofdmenu kan de gebruiker berichten versturen,
sleutelen aan processen, interrupthandling forceren en timers aanzetten. Het menu
ziet er als voigt uit: "Message, Proces, Interrupt or Timer?".
Message
Met behulp van de "Message"-optie uit het manipulate-menu kan de gebruiker een
bericht versturen. Ais eerste wordt gevraagt naar het proces waar het bericht naar
toe moet. Dit proces wordt op dezelfde manier gekozen als bij "view-proces". Ais een
laag 3 proces gekozen wordt, dan wordt tevens naar de gewenste call gevraagd.
Het gekozen bestemmingsproces (eventueel samen met de gekozen call) verschijnt in
het commando-venster.
Nu moet het te versturen bericht gekozen worden. Dit gebeurt op een soortgelijke
manier als het kiezen van een proces. Vervolgens kan men al dan niet aangeven waar
het bericht zogenaamd vandaan komt. Ais de oorsprong van het proces niet gekozen
wordt, dan wordt aangenomen dat het bericht van het TEST-proces komt.
Tenslotte kan men al dan niet de parameters van het bericht instellen (niet ingestelde
parameters worden op 0 gezetL Om een parameter in te stellen moet eerst het
nummer van de gewenste parameter ingegeven worden (zonder return). Vervolgens
kan de waarde ingevoerd worden (met returnL Het instellen van een parameter kan
willekeurig vaak herhaald worden. Het instellen van de parameters wordt bei:Hndigd
door bij het parameternummer een return te geven Lp.v. een cijfer.
Het bericht wordt daarna automatisch in de juiste message-queue geplaatst en men
keert terug naar het hoofdmenu.
Proces
De "Proces"-optie uit het manipulate-menu dient om de toestand en/ of de parameters
van een proces te wijzigen. Ais eerste wordt op de bekende manier gevraagd naar het
bedoelde proces. Vervolgens kan men kiezen tussen het wijzigen van de toestand (5),
de sub-toestand (U) en de parameters CDL Iedere andere keuze beeindigd het
manipuleren van het proces.
53
BIJLAGE 2: Handleiding van de monitoring dispatcher
Bij het wlJzlgen van de toestand moot op de bekende manier de nieuwe toestand
gekozen worden. Als het een laag 3 proces betreft, dan wordt de toestand van een
door de gebruiker te kiezen call gewijzigd.
Bij het wijzigen van de sub-toestand kan gekozen worden uit de waarden 0 ..7.
Bij het wijzigen van een parameter (datafield) moet eerst het nummer van de
parameter (1..8) gekozen worden. Vervolgens kan de nieuwe waarde ingevoerd
worden.
Daarna keert men niet automatisch terug naar het hoofdmenu. Deze "Proces"-optie
herhaalt zichzelf.
InterruptDe "Interrupt "-optie uit het manipulate-menu kan gebruikt worden om een aanroep
van de SNIC-interrupthandler te forceren. Bij gebru'ik van deze optie wordt de functie
"SisrO" aangeroepen, net zoals bij het optreden van een echte interrupt. Dit kan
bijvoorbeeld gebruikt worden als men vermoedt dat er een SNIC-interrupt verloren
gegaan is.
TImerDe "Timer"-optie uit het manipulate-menu biedt de mogelijkheid om zelf een timer te
starten (mits er nog een timer vrij is). Als eerste wordt gevraagt naar de looptijd van
de timer in timertikken (18.2 per seconde).
Vervolgens moet een proces gekozen worden waar de timer bij het aflopen een
bericht naar toe stuurt. Als voor een laag 3 proces gekozen wordt, dan moet ook nog
de gewenste call opgegeven worden. Tenslotte moet nog een timeout-bericht gekozen
worden. Daarna wordt de timer gestart en keert men terug naar het hoofdmenu.
6. De dispatcher-parameters
Met de "Set"-optie uit het hoofdmenu kunnen een aantal parameters van de
dispatcher gewijzigd worden. Deze parameters bepalen wat de dispatcher laat zien en
hoe de timers zich gedragen. Het set-menu ziet er als voigt uit: "Timer, Messages,
Frames, Level or Stop?".
TImer
Met de "Timer"-optie uit het set-menu kan de gebruiker kiezen uit drie gedragingen
van de timers. De timers kunnen normaal real-time aflopen (E), helemaal stil staan
(D) of in stapjes aflopen (S). In dat laatste geval wordt bij iedere dispatcherslag een
timertik gegenereerd.
54
BI"ILAGE 2: Handleiding van de monitoring dispatcher
MessageDe "Message"-optie uit het set-menu bepaalt of de te verwerken berichten met de
resulterende toestandsovergangen (S), zonder de resulterende toestandsovergangen
(N) of helemaal niet (]) getoond worden.
Frames
De "Frames"-optie uit het set-menu bepaalt of de verzonden en ontvangen frames
volledig (V), beknopt (S) of helemaal niet (I) weergegeven worden. Volledig wi! zeggen
dat de gehele inhoud van het frame in hexadecimale vorm op het scherm verschijnt.
Beknopte weergave laat aileen de lengte van het frame zien, niet de inhoud.
Level
De "Level"-optie uit het set-menu bepaalt het "visability-Ievel". Een bericht verschijnt
aileen als het prioriteitsnummer van de oorsprong of de bestemming van het bericht
minstens gelijk is aan het ingestelde "visability-Ievel". Processen in de onderste lagen
hebben, vanwege strengere tijdslimieten, een hogere prioriteit (lager
prioriteitsnummer) dan processen op hogere lagen. De conditie voorkomt dus dat bij
het bestuderen van de protocol len van hogere lagen ook aile berichten voor de lagere
lagen op het scherm verschijnen.
StopMet de "Stop"-optie uit het set-menu kan een stop-conditie aangegeven worden. De
gebruiker kan een bepaald bericht en een aantal kiezen. Wanneer het gekozen bericht
het gekozen aantal maal ontvangen wordt, dan worden aile timers stil gezet.
Door bij het begin van een bepaalde protocol-procedure zelf een timer te starten en
de timers met de genoemde conditie te stoppen bij de ontvangst van het laatste
bericht van die procedure, kan de voor die procedure benodigde tijd bepaald worden.
7. Buffer-rnanipulatTes
Voor het doorgeven van frames en informatiepakketten worden buffers gebruikt. Met
de "Buffer" -optie uit het hoofdmenu kan de gebruiker buffers aanvragen en vrijgeven,
de inhoud ervan wijzigen en buffers (met bijvoorbeeld een zelf samengesteld frame
erin) versturen. Het buffer-menu ziet er als voigt uit: "New, Edit, Free or Transmit?".
New
Met de "New"-optie uit het buffer-menu kan een nieuwe buffer aangevraagd worden.
Ais er nog een vrije buffer is, dan wordt een speciaal edit-venster geopend. Het
edit-venster bestaat uit twee regels. De bovenste regel geeft (een gedeelte van) de
inhoud van de buffer weer in hexadecimale vorm.
55
BIJLAGE 2: Handleiding van de monitoring dispatcher
De onderste regel geeft (waar mogelijk) hetzelfde weer. maar dan in de vorm van
normale karakters.
De pijltjes verplaatsen de cursor door de buffer en van de ene regel naar de andere.
Delete en backspace hebben de normale uitwerking.
Met "F1" wordt de buffer gevuld met een testpatroon van een door de gebruiker te
bepalen lengte. Met "F2" kan getest worden of de buffer zo'n testpatroon bevat.
Return bei:Hndigd de invoer.
Edit
Met de "Edit" -optie uit het buffer-menu kan de inhoud van een buffer bekeken en
eventueel gewijzigd worden. De betreffende buffer hoeft niet in gebruik te zijn. In het
commando-venster wordt aangegeven of de buffer in gebruik is (USED) of niet
(FREEL
Free
Met de "Free"-optie uit het buffer-menu kan een in gebruik zijnde buffer vrijgegeven
worden. Dit kan bijvoorbeeld gebruikt worden als door een fout in de implementatie
van het protocol een buffer niet automatisch vrijgegeven wordt a/s de inhoud ervan
niet meer gebruikt hoeft te worden.
Transmit
Met de "Transmit"-optie uit het buffer-menu kan de inhoud van een buffer verzonden
worden. De buffer moet dan wei een frame bevatten dat door de software herkent
wordt als een correct laag 2 frame. In het commando-venster wordt aangegeven of
de transmissie met succes gestart is of niet.
56
BIJLAGE 3: Belangrijke data-structuren
BIJLAGE 3: Belangrijke data-structuren
PROCESSENDe processen worden bijgehouden in het array struct process Process[MAXPROCJ dat
gedeclareerd wordt in "DEFINE.C". De constante MAXPROC en de structure process
worden gedefinieerd in "DECLARE.r. In deze file worden ook de namen van de
processen en de macro's LAYER2 en LAYER3 gedefinieerd. LAYER2 geeft het bij een
bepaald laag 3 proces behorende laag 2 proces. LAYER3 doet het omgekeerde. De
gegeven toekenning van nummers aan de processen wordt op verschillende plaatsen in
de software expliciet gebruikt en kan dus beter niet gewijzigd worden.
De functie "initprocessO" uit "INITPROC.C" zorgt voor het initialiseren van de
processen. Het aktieve proces wordt aangeduid met de pointer dp. De variabele
ProcAct bevat het nummer van het aktieve proces. Beiden zijn gedeclareerd in
"DEFINE.C". In "DECLARE.!" zijn verder nog een aantal macro's gedefinieerd waarmee
het aanspreken van de parameters van het aktieve proces een stuk overzichtelijker
wordt. De macro's I\JEWSTATE, PUBSTATE, SUBSTATE en DATA1 tim DATA7 dienen
voor het aanspreken van respectievelijk de State, de Pub/Stat, de Substate en de
Data parameters van het aktieve proces. De constanten RUNNING en BLOCKED,
gedefinieerd in "DECLARE.!", worden gebruikt om de "public state" van een proces
aan te geven.
MESSAGESProcessen communiceren door het uitwisselen van berichten. Berichten worden
gedefinieerd door de structure mesage die gedefinieerd is in "DECLARE.!" (de
ontbrekende "5" in "mesage" is een fout die gemaakt is bij de implementatie van het
operating system). Een bericht bestaat uit een "nucleo" die de naam van het bericht
aangeeft, de nummers van de afzender en de ontvanger van het bericht (twee
processen) en een aantal parameters. De namen van de verschillende nucleo's zijn
gedefinieerd in "STATE.H" en "L3DECLAR.I".
De verstuurde berichten worden opgeslagen in message-queue's. Het tweedimensionale
array FifoMesage bevat de berichten. De eerste index geeft de queue aan (MAXPRIO
bepaalt het aantal queue's). De tweede index onderscheidt de verschillende berichten
in die queue (MAXMSG bepaalt het maximale aantal berichten in een queue). De
constanten MAXPRIO en MAXMSG zijn gedefinieerd in "DECLARE.!".
De message-queue's zijn fifo's. Het is niet efficient om bij het verwijderen van een
bericht uit een queue aile andere berichten in het array op te schuiven. Daarom
worden drie extra array's gebruikt: InLecMen, InEscMen en LargoFifo (aile drie
gedefinieerd in "DEFINE.C"L InLecMen geeft voor iedere queue de index aan van het
bericht dat als eerstvolgende gelezen moet worden. InEscMen geeft voor iedere queue
de index aan van de eerste vrije plaats voor een nieuw bericht.
57
BIJLAGE 3: Belangrijke data-structuren
LargoFifo tenslotte geeft de lengten van de fifo's aan. Met deze drie extra array's
worden de message-queue's geimplementeerd als cyclisch array.
Voor het gebruik van de message-queue's zijn in "MSG.C" een aantal functies
gedefinieerd. Om een bericht in een queue te plaatsen wordt de functie "messageO"
gebruikt. Ais parameters krijgt "messageO" achtereenvolgens het gewenste bericht,
het bestemmingsproces, het afzender-proces en de message-parameters mee. Ais er
nog plaats is, dan wordt het bericht in de queue geplaatst die behoort bij de prioriteit
van het bestemmingsproces.
Om een bericht uit een queue te lezen wordt de functie "getmsgO" gebruikt. De enige
parameter van deze functie is het nummer van de queue waaruit gelezen moet
worden. Ais de betreffende queue niet leeg is, dan wordt het eerste bericht uit die
queue gecopieerd naar de globale variabelen Nucleo, OrigMsg, ProcAct en Param_1
tI m Param_5. Nucleo bevat de naam van het bericht. OrigMsg en ProcAct bevatten
respectievelijk het afzender-proces en het bestemmingsproces. Param_1 tI m
Param_5 bevatten de message-parameters. De waarde die de functie "getmsgO"
teruggeeft geeft aan of er een bericht gelezen is (de waarde PRESENn of niet (de
waarde NOTPRESENn. Deze waarden zijn gedefinieerd in "DECLARE.I". Door de
toekenning aan ProcAct wordt het bestemmingsproces automatisch aktief gemaakt.
Om een verwerkt bericht uit een queue te verwijderen wordt de functie
"updatequeueO" gebruikt. Ook deze functie krijgt als enige parameter het nummer van
de gewenste queue mee. Ais die queue niet leeg is, dan wordt het eerste bericht uit
de queue gewist.
De functies werken tevens de array's InLecMen, InEscMen en LargoFifo bij.
STATE-TABLESEen state-table is een array. De elementen van zo'n array zijn van het type struct
state. De naam van zo'n array wordt gebruikt om de toestand van een proces aan te
duiden en mag gebruikt worden als waarde voor het State-veld van een proces.
Een element van een state-table bestaat uit een mogelijk bericht en een pointer naar
een functie. Het bericht kan door de naam van de nucleo weergegeven worden en de
pointer door de naam van de aangewezen functie. De diverse state-tables van de
verschillende processen zijn gedefinieerd in "TABLLAPD.C", "TABL_MAN.C",
"TABL_MSG.C", "TABLLAY2.C", "L3_GC_ST", "L3_NT_ST.C" , "L3_TE_ST.C" en
"L4_ST.C" .
Iedere state-table eindigd met een element met nucleo DEF. Bij het zoeken naar een
bepaalde nucleo in een state-table kan daarmee bepaald worden wanneer het eind van
de state-table bereikt is. Zoekfuncties kunnen daardoor state-tables van verschillende
lengte aan.
58
BIJLAGE 3: Belangrijke data-structuren
BUFFERSBij de implementatie van de ISDN protocollen moeten regelmatig frames samengesteld
en aan andere processen doorgegeven worden. Daarvoor worden buffers gebruikt. Een
buffer wordt gedefinieerd door de structure buffer in "DECLARE.I". In deze structure
wordt de lengte en de inhoud van een buffer bewaard. De maximale lengte van een
buffer wordt bepaald door de constante MAXPKTSZ (MAXimum PacKeT SiZe) die
eveneens in "DECLARE.I" gedefinieerd wordt. Een verzameling buffers wordt
bijgehouden in een structure ram. De structure ram bestaat uit twee array's. Een
array houdt van aile buffers bij of ze in gebruik zijn (USED) of niet (FREEL Het
andere array bevat de buffers. Het aantal buffers wordt bepaald door de constante
NUMBUF. De constantes USED. FREE en NUMBUF worden ook in "DECLARE.I"
gedefinieerd.
Er zijn twee macro's gedefinieerd voor buffers: L2_BUFF en L3_BUFF. Hiermee
worden twee buffers uit de variabele Ram (met een hoofdletter) van het type ramaangeduid. De nummers van de bedoelde buffers staan in de variabelen L2_Buffref
respectievelijk L3_Buffref.
Op de variabele Ram zijn in "SYST.C" drie functies gedefinieerd: "freebuffO".
"getbuffO" en "newbufferO". De functie "freebuffO" geeft een buffer vrij door het
betreffende element in het Used-veld van de variabele Ram op FREE te zetten. Deze
functie krijgt als parameter het nummer van de vrij te geven buffer mee.
De functie "getbuffO" zoekt naar een vrije buffer. Als er een vrije buffer is, dan
wordt deze bezet en de functie levert als resultaat het nummer van die buffer. Als
geen vrije buffer beschikbaar is, dan levert de functie de waarde NUMBUF. Aile
buffernummers zijn kleiner dan NUMBUF dus de aanroepende functie kan altijd
controleren of er een buffer gevonden is of niet. De functie "getbuffO" heeft geen
parameters.
De functie "newbufferO" doet ongeveer hetzelfde als de functie "getbuffO". Nu wordt
de gevonden buffer echter direct klaargezet om er gegevens uit de ontvangst-fifo in
te schrijven.
FRAME-QUEUFSDe verschillende laag 2 processen genereren frames die over het interface verzonden
moeten worden. Om te voorkomen dat er frames verloren gaan doordat de zender
bezig is met het verzenden van een ander frame, zijn er frame-queue's in het leven
geroepen. Ieder laag 2 proces heeft twee eigen frame-queues, een I-queue en een
UI-queue.
Voor het implementeren van de queue's worden in "DEFINE.C" de array's Queue,
PutQue, GetQue, AckQue en LengthQue gedefinieerd. Het driedimensionale array
Queue bevat de frames. De frames worden gerepresenteerd door hun buffernummer
in de variabele Ram. De eerste index van Queue (de entry) geeft het proces aan
waartoe de queue behoort. De tweede index bepaalt het type van de queue.
59
BIJLAGE 3: Belangrijke data-structuren
Deze index kan de twee in "DECLAREr gedefinieerde waarden UIQUEUE en IQUEUE
aannemen. De laatste index maakt onderscheid tussen de opgeslagen frames.
De frame-queue's zijn net aJs de message-queue's gedefinieerd als cyclische array's.
De tweedimensionale array's GetQue, PutQue en LengthQue geven respectievelijk het
begin, het einde en de lengte van de queue aan. De eerste index geeft weer het
proces aan en de tweede de specifieke queue.
Het array AckQue geeft aan welke frames al bevestigd zijn. Aangezien aileen I-frames
bevestigd worden heeft dit array aileen een index om het juiste proces aan te geven.
Het aantal processen dat queue's heeft wordt bepaald door de constante MAXENTRY.
MAXQUE geeft aan hoeveel queue's ieder proces heeft. MAXQUEUELENGTH tenslotte
geeft aan hoeveel frames er maximaaJ in een queue gaan.
Op deze queue's zijn in "QUEUE.C" vijf functies gedefinieerd: putqueueO, discardO,
getmessO. backtrack_iqueueO en acknowledge_framesO.
De functie "putqueueO" dient om een frame in een queue te plaatsen. De functie
heeft als parameters achtereenvolgens de gewenste entry, het gewenste queue-type
en het nummer van de buffer die het bedoelde frame bevat.
De functie "discardO" wordt gebruikt om een bepaalde queue van en bepaald proces
te wissen. De functie geeft de bijbehorende buffers vrij en wist de bijbehorende
frame-in-queue-meldingen uit de message-queue·s. Ais parameters krijgt de functie
de gewenste entry en de gewenste queue mee.
De functie "getmessO" leest het eerste buffernummer uit een queue. Het
buffernummer wordt niet gewist maar de array GetQue wordt wei bijgewerkt. Ais
parameters krijgt de functie weer de gewenste entry en de gewenste queue mee.
Verwar deze functie niet met de functie "getmsgO" die een bericht uit een
message-queue leest.
De functie "backtrack_iqueueO" maakt de met "getmessO" gemaakte verandering in
GetQue ongedaan. Een frame dat niet bevestigd was kan daarmee weer vooraan in de
frame-queue geplaatst worden. Aangezien aileen I-frames bevestigd worden, krijgt
deze functie aileen de gewenste entry als parameter mee.
De functie "acknowledge_framesO" tenslotte geeft de buffers van bevestigde I-frames
vrij en werkt het array AckQue bij. Ais parameter krijgt deze functie het aantal
frames dat bevestigd is mee. De gewenste entry wordt bepaald door het aktieve
proces.
TIMERS
Een timer wordt gedefinieerd door de structure tim. Deze structure is gedefinieerd in
"DECLARE.I". Een aantal timers staan samen in het array Timer. gedefinieerd in
"TIMER.C". De in "DECLARE.!" gedefinieerde constante MAXTIMER bepaalt h~~ aantal
timers.
60
Bl..lLAGE 3: Belangrijke data-structuren
Van iedere timer wordt bijgehouden of de timer al in gebruik is. Zo ja. dan bevat de
timer het aantal timertikken (18.2 per seconde) dat de timer nog moet lopen. het
bericht dat bij een timeout verstuurd moet worden, het bestemmingsproces van dat
bericht en (als het om een laag 3 proces gaaU de specifieke call waar het bericht
naar toe moot.
Op de variabele Timer zijn acht functies gedefinieerd: timedecO, timecheckO.
runtimerO, stoptmrO, restarttimerO. timermsgO, timer _staHl en remove_tmr _msgO.
De functie "timedecO" verlaagt het aantal kloktikken van een timer met 1. Ais het
aantal daarmee op nul komt wordt de functie "timermsgO" aangeroepen met als
parameters achtereenvolgens het te versturen bericht, het bestemmingsproces en de
specifieke call. De functie "timedecO" krijgt als parameter het nummer van de te
verlagen timer mee.
De functie "timecheckO" wordt bij iedere timertik aangeroepen. Deze functie verlaagt
aile lopende timers met behulp van "timedecO". De functie heeft geen parameters.
De functie "runtimerO" wordt gebruikt om een timer te starten. De functie zookt een
vrije timer. bezet die en vult de nodige gegevens in. Als parameters krijgt deze functie
het timeout -bericht, het bestemmingsproces en de te lopen tijd in timertikken mee.
Voor het bepalen van de gewenste call wordt de aktieve call gebruikt.
De functie "stoptmrO" wordt gebruikt om een timer te stoppen. De functie krijgt als
parameters het timeout-bericht en het bestemmingsproces van de te stoppen timer.
Ais een timer gevonden wordt met dat bericht en bestemmingsproces, dan wordt deze
timer vrijgegeven. Ais de timer niet gevonden wordt, dan kan het zijn dat hij al
afgelopen is. Het gegenereerde bericht wordt dan uit de message-queue's verwijderd
met behulp van de functie "remove_tmr_msgO" die als parameters het bericht en het
bestemmingsproces meekrijgt.
De functie "restarttimerO" wordt gebruikt om een timer te herstarten. De bedoelde
timer wordt gedefinieerd door het tirneout-bericht en het besternmingsproces. Verder
krijgt de functie de nieuwe looptijd mee als parameter. Ais de timer niet gevonden
wordt, dan wordt een eventueel door het aflopen gegenereerd bericht uit de queue's
verwijderd met "remove_tmr _msgO" en de timer wordt met "runtimerO" gestart.
De functie "timer _staH)" dient om de status van een timer te bepalen. Ais parameter
krijgt de functie het timeout-bericht van de bedoelde timer mee. Voor het
bestemmingsproces wordt gekeken naar de variabele ProcAct die het aktieve proces
aangeeft. Ais de bedoelde timer loopt, dan geeft de functie als resultaat de waarde 1.
Anders wordt de waarde 0 terug gegeven.
61
BIJLAGE 3: Belangrijke data-structuren
CALLS
De laag 3 processen zijn verdeeld in calls. Een call wordt gedefinieerd met de
structure callentity die gedefinieerd is in "L3DECLARJ" Een call heeft een
call-reference-waarde waarmee hij van andere calls onderscheden wordt, een
call-reference-vlag die aangeeft aan welke kant van het interface de call geinitieerd is
en een pointer naar de state-table van de huidige call-state.
De verzameling calls staat in het tweedimensionale array Call (gedefinieerd in
"L3GLOBAL.C") van het type struct callentity. De eerste index bepaalt het laag 3
proces waar de call bij hoort. De tweede index onderscheidt de individuele calls binnen
een laag 3 proces. De in "L3DECLARJ" gedefinieerde constanten MAXCEI en
MAXCALL bepalen respectievelijk het aantal processen dat in calls verdeeld is en het
maximale aantal calls per proces.
De aktieve call wordt aagegeven door pointer cp en de globale variabele CALLACT. De
call-reference-waarde en de call-reference-flag van de aktieve call worden aagegeven
door de globale variabelen CALLREF respectievelijk CRFLAG. Deze vier variabelen zijn
gedefinieerd in "L3GLOBAL.C"
De functie "Initlayer30", gedefinieerd in "L3_INIT.C", initialiseert de calls.
62
BIJLAGE 4: De functies
BIJLAGE 4: De functies
Deze bijlage geeft een overzicht van de gebruikte functies in alfabetische volgorde. Bij
iedere functie staat de file waarin de source-code van de functie staat en een korte
omschrijving van de taak van die functie. De functies uit 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 die bij een
bepaald bericht en een bepaalde toestand horen. Bovendien zouden ze de tabel erg
lang en onoverzichtelijk maken. Deze functies staan in de files LAPD.C, MANAGE.C,
L3_TE_TR.C, L3_I\JT_TR.C, L4_TE_TR.C en L4_NT_TR.C.
Functie File
acknowledge_f r ames 0 QUEUE.C
backtrack _ iqueue() QUEUE.C
CallCtrltoLayer30 L3_INTER.C
CheckState() L3_AUXIL.C
CursorO LOWIN.C
discardO QUEUE.C
Dispatcher 0 MONDISP.C
DSCRaminitO DSCRAMIN.C
dummyO DEFINE.C
EditBuffer 0 LOWIN.C
enable_intO SETINTER.C
endhwO SETINTER.C
FirstTOO L3_AUXIL.C
freebuffO SYST.C
getbuffO SYST.C
getmessO QUEUE.C
getmsgO MESSAGE.C
GetNucleoNameO LOWIN.C
GetProcessNameO LOWIN.C
getrandom () MANAGE.C
GetStatel\JameO LOWIN.C
hdtoiO LOWIN.C
Omschrijving
Geeft de buffers van bevestigde frames vrij.
Herstelt de situatie van voor het lezen
van een frame uit een I-queue.
Ontvangt berichten van laag 4 voor laag 3.
Test of state "compatible" is.
Zet cursor aan/ uit.
Wist een bepaalde 1- of UI-queue.
De monitoring dispatcher.
Initialiseerd zend- en ontvangstbuffers.
Lege functie. Wordt gebruikt aan het eind
van de state-tables.
Bewerk een buffer in een speciaal venster.
Demaskeert de SNIC-interrupts behalve GA.
Herstelt de oorspronkelijke hardware
instellingen.
Test of dit de eerste keer is dat de timer
afloopt.
Geeft een bepaalde buffer vrij.
Aanvragen van een nieuwe buffer.
Leest een frame uit een 1- of UI-queue.
Leest een bericht en copieert het naar
globale variabelen.
Geeft de naam van een nucleo.
Geeft de naam van een proces.
Genereert random nummer tussen 0 en
65535 (incl J .Geeft de naam van een toestand.
Zet een hexadecimaal digit om in een
integer.
63
Layer2toLayer30 L3_INTER.C
mainO MAIN.C
messageO MESSAGE.C
mysnicisr 0 I1\JT_DSC.C
nexLtimeout_will_be_
the_firstO L3_AUXIL.C
newbuffO SYST.C
putqueueO QUEUE.C
queue_packet 0 LAYER2.C
rcv_broadcastO LAYER2.C
rcv_channelO LAYER2.C
rcv_messageO INT_DSC.C
rcv_packetO LAYER2.C
readstatO HARDREG.C
Receive_L3msgO L3_INTER.C
receive_packetO INT_DSC.C
Receive_UnitDataO L3_INTER.C
Release_CRO L3_MANAG.C
remove_tmr _msgO TIMER.C
ResetAlllnfoO L3_AUXIL.C
resetRFIFOO HARDREG.C
resetTFIFO HARDREG.C
restarttimerO TIMER.C
runtimerO TIMER.C
SaveRestoreO MONDISP.C
SelectNucleoO LOWII\J.C
SelectProcess0 LOWIN.C
Functie
inithardwO
Initlayer30
initprocessO
File
SETINTER.C
L3_INIT.C
INITPROC.C
BI,.JLAGE 4: De functies
Omschriiving
Initialiseert de hardware (SNIC en PC).
Initialiseert pointers, calls, call references ,
first -timeout -condities en informatie
elementen.
Initialiseert de processen, timers, buffers,
message- en frame-queue's en de
TEI-administratie.
Verwerkt berichten van laag 2 voor laag 3.
Initialiseert de PC en start de dispatcher.
Plaatst een bericht in de message-queue's.
Nieuwe SNIC-interrupthandler.
Herstelt de first -timeout -conditie.
Aanvragen nieuwe buffer voor de ontvangst
van laag 2 frames.
Plaatst een frame in een 1- of UI-queue.
Houdt een frame in de queue als de zender
niet vrij is.
Stuurt ontvangen laag 2 bericht naar aile
processen met dezelfde SAPI-waarde.
Stuurt een laag 2 bericht naar een proces.
Genereert PH_DATA_INDICATION-bericht.
Interpreteert laag 2 frame.
Leest het HDLC status register.
Ontvangt laag 3 frames van laag 2.
Verwerkt bytes uit de ontvangst-fifo.
Wordt niet meer gebruikt.
Ontvangt DL_UNIT-DATA-berichten.
Geeft een call-reference-waarde vrij.
Stuurt een timeout-bericht naar het
SINK-proces.
Herstelt aile informatie-elementen.
Leegt de ontvangst-fifo.
Leegt de zend-fifo.
Het herstarten van een timer.
Het starten van een nieuwe timer.
Leest en herstelt een venster op het
beeldscherm.
Laat de gebruiker een nucleo kiezen.
Laat de gebruiker een proces kiezen.
64
BIJLAGE 4: De functies
Functie File Omschriiving
SelectStateO LOWIN.C Laat de gebruiker een toestand kiezen.
SelecLCRO L3_MANAG.C Selecteert een vrije call-reference-waarde.
SendO MANAGE.C Samenstellen en versturen van een laag 2
frame door het laag 2 management.
Send_L3msgO L3_AUXIL.C Samenstellen van een laag 3 frame en
doorgeven aan laag 2.
SetDefaultInfoO L3_AUXIL.C Zet aile informatie-elementen op hun
standaard-waarde.
ShowActivityO MONDISP.C Laat zien dat de dispatcher bezig is.
ShowBufferO LOWIN.C Dump de inhoud van een buffer.
ShowMessageO MONDISP.C Toont het te verwerken bericht.
SisrO SETINTER.C Wordt aangeroepen bij een SNIC-interrupt.
snicisrO INT_DSC.C Oude SNIC-interrupthandler. Wordt niet
meer gebruikt.
StateCodeO L3_AUXIL.C Geeft het nummer van de huidige callstate.
StopAllTimersO L3_AUXIL.C Stopt aile timers van de huidige call.
stoptmrO TIMER.C Het stoppen van een timer.
TELremove() MANAGE.C Verwijdert een specifieke TEl -waarde.
TELremove_allO MANAGE.C Verwijdert aile toegekende TEI-waarden.
timecheck () TIMER.C Verlagen van aile lopende timers.
timedE'cO TIMER.C Verlagen van een timer en eventueel een
bericht versturen.
Timeout toLayer30 L3_INTER.C Ontvangt laag 3 timeout-berichten.
timermsgO TIMER.C Het genereren van het timeouibericht.
timer _statO TIMER.C Kijkt of een bepaalde timer loopt.
timisrO SETINTER.C Wordt aangeroepen bij een timer-interrupt.
txO TX.C Een laag 2 frame samenstellen en versturen
naar TRANSMISSION.
tx_packetO LAYER2.C Verstuurt een laag 2 frame.
unnumbered_infoO LAYER2.C Decodeert UI-frame.
updatequeueO MESSAGE.C Wist een bericht uit een queue.
vectset() SETINTER.C Zet de interrupt-vectors naar de functies
timisrO en SisrO.
vectunset() SETINTER.C Herstelt de oorspronkelijke interruptvectors.
winselO LOWIN.C Selecteer/ open een van de dispatcher-
vensters.
xmtbuffO XMTBUFF.C Het versturen van een laag 2 frame.
zendenO XMTBUFF.C Het vullen van de zend-fifo.
65
