⟦65fc49a6d⟧

TextFile

>bl
>a1 OPDELING AF DC I MODULER
De funktioner, som et distriktscenter skal udføre, er beskrevet i AL.RC.8: Distriktscentrets funktioner. I figur 1
vises de moduler, som distriktscentret opdeles i for at udføre de ønskede funktioner.

Moduler i RC8000:

- Operatørmodel OPT
- Utilitymodul UTIL
- Logmodul LOG
- Errorhandler EH
- Databasemodul DB
- Netinterface NI
- Basisprogrammel BASIS
- FPA-driver (Front end Processor Adapter)
- Link-driver
- Disc-driver

Moduler i RC3502:

- Netprogrammel NETP
- FPA-driver
- Net control process NCP
- LAM-driver (Low speed Asynchronous Multiplexer)
- TTY-driver

Moduler i RC8302:

- FPA-driver
- NCP
- MT-driver
- LP-driver
- TTY-driver

>ne 50
>sp 48
>fg Modulopdeling af DC.
De moduler, der ikke er standard, beskrives i de næste to kapitler.

>np

>a1 MODULER I RC8000
I dette kapitel beskrives de moduler, som en RC8000 i et distriktscenter skal indeholde for at
udføre de ønskede funktioner.

Funktionerne er i det væsentlige som beskrevet i AL.RC.8: Distriktscentrets funktioner. Dog er der
opstået enkelte ændringer i forhold til dette skrift, bl.a. ang. klartekster, som er flyttet
fra distrikstscentret ud til de enkelte vagtcentraler.

De moduler i RC8000, som beskrives her, er følgende:

- Operatørmodul OPT
- Utilitymodul UTIL
- Logmodul LOG
- Errorhandler EH
- Databasemodul DB
- Netinterface NI

>a2 Operatørmodul.
Operatørmodulet OPT har til opgave at fortolke og behandle kommandoer fra operatørkonsollen i
distriktscentret.

Operatørerne afgiver kommandoer interaktivt i MML (Man Machine Language). Syntaksen for disse
kommandoer følger CCITTs rekommendationer. For at kunne behandle kommandoerne har OPT
forbindelse til de øvrige moduler i RC8000.

De kommandoer som kan afgives til OPT, kan opdeles i følgende kategorier:

- Utilitykommandoer
- Logkommandoer
- Fejlkommandoer

Utilitykommandoer benyttes ved vagtoverførsel, til- og afmelding af ATer, VCer og netknuder og
desuden ved test af ATer internt og eksternt.

Logkommandoer benyttes til overvågning af logningen, listning af
bestemte delmængder af logfilen, f.eks. alle meddelelser
til/fra en bestemt VC i en bestemt periode, og desuden til statistikker.

Fejlkommandoer omfatter de reaktioner, som operatøren kan give efter at have modtaget
fejlmeddelelser på konsollen.

Kommandoerne beskrives i de følgende afsnit.

>a2 Utilitymodul.
Utilitymodulet aktiveres enten gennem MML-kommandoer fra operatørkonsollen via operatørmodulet
eller fra terminaler på ekspeditionskontorerne.

Modulet udfører følgende funktioner:

- Vagtoverførsler
- Til-/afmelding af abonnenter
- Til-/afmelding af vagtcentraler
- Til-/afmelding af netknuder
- Test af ATer internt og eksternt
- Løbende ændringer

>a3 Vagtoverførsel.
En vagtoverførsel kan initieres enten af den VC, der for tiden har ansvaret for de ATer,
der skal flyttes, eller af operatøren i DC.

Når en vagtoverførsel initieres af en VC, er det denne VCs TS, der styrer overførslen,
ellers er det DC, der styrer overførslen.

En vagtoverførsel initieret fra DC foregår på følgende måde:

Operatøren i DC sender denne MML-kommando til OPT:

Vagtoverførsel: Afsender = "VCa", modtager = "VCm";

Kommandoen fortolkes af OPT og afleveres til utilitymodulet.

I utilitymodulet sker herefter følgende:

Der foretages opslag i databasen under afsender-VCens VC-beskrivelse. Det checkes, at
modtager-VC er indeholdt i denne VC-beskrivelses VCm-kartotek (over lovlige flytninger).

Hvis modtager-VC ikke er med i kartoteket, sender UTIL følgende meddelelse til operatøren i DC:

Ulovlig vagtoverførsel

Ellers sendes en meddelelse om overførslen fra UTIL til modtager-VC (VCm), der forventes at
kvittere herfor.

Meddelelse om overførsel:

- Modtager: VCm-adresse
- Afsender: DC-adresse
- Operationskode: "Anmodning om vagtoverførsel"
- Datadel: VCa-adresse

Kvittering, hvis modtager-VC accepterer overførslen:

- Modtager: DC-adresse
- Afsender: VCm-adresse
- Operationskode: "Accept af vagtoverførsel"
- Datadel: VCa-adresse

Ved accept gennemføres overførslen, ellers gives besked til operatøren om afslaget:
Vagtoverførsel ikke kvitteret af modtager
Overførslen udføres i to trin som beskrevet i SP.TS.1:

1) VCas egen abonnentgruppe overføres til VCm.

2) De øvrige abonnentgrupper, der for tiden er tilknyttet
VCa, overføres til VCm.

Abonnentgrupperne under punkt 2 kan aflæses i TSa-beskrivelsens VCa-VCm-kartotek over aktuelle flytninger (i DC).
Det drejer sig om de indgange, hvor VCa optræder på højre side, f.eks.

VCe -> VCa

Først overføres VCas egen abonnentgruppe:

UTIL sender meddelelser til VCms TS (TSm) og til de af følgende TSer, der er forbindelse med:
TSa (VCas TS) og alle TSer, der er med i VCas AT-TS-kartotek.

Meddelelserne har dette indhold:

- Modtager: TS-adresse
- Afsender: DC-adresse
- Operationskode: "Udfør vagtoverførsel"
- Datadel: VCa-adresse
VCm-adresse

Det er hensigten, at de enkelte TSer nu skal opdatere deres VCa-VCm-kartotek,
så det indeholder

VCa -> VCm

og ikke andre indgange med VCa på venstre side.

En sådan meddelelse skal også sendes til de pågældende TSers DCer,
hvor den skal resultere i en tilsvarende ændring i VCa-VCm-kartoteket.

For hver af de i punkt 2 omtalte abonnentgrupper f.eks. VCes abonnentgruppe udføres følgende:

Først sendes besked til TSa (hvis forbindelsen er i orden) om at fjerne sin indgang

VCe -> VCa

i VCa-VCm-kartoteket. Samme ændring skal foretages i kopien af VCa-VCm-kartoteket i TSa-beskrivelsen
i DC.

Meddelelsen:

- Modtager: TS-adresse
- Afsender: DC-adresse
- Operationskode: "Udfør vagtoverførsel"
- Datadel: VCe-adresse
VCm-adresse

sendes ud med modtagerne TSe, TSm og TSerne i VCe-beskrivelsens AT-TS-kartotek.
Samme meddelelse skal sendes til involverede DCer.
Det kræves, at i det mindste forbindelsen fra DC til TSm er i orden.

Herefter sender UTIL meddelelse til TSm og TSa om, at vagtoverførslen er foretaget.

UTIL vil nu udskrive på hovedkonsollen:

Vagtoverførsel foretaget fra "VCa-adresse" til "VCm-adresse".

>a3 Til-/afmelding af abonnenter.
Til- og afmelding af abonnenter foretages på ekspeditionskontorer via en formatorienteret skærm.

Tilmelding af en abonnent foregår ikke som tidligere beskrevet i to trin, men udføres på en gang.
Tilmeldingen starter med en tilmeldingskommando:

Tilmeld AT;

hvorefter der svares med et skærmbillede til oprettelse af en abonnent. Dette
skærmbillede indeholder felter til angivelse af abonnentens navn og adresse, netadresse for ATen,
primær vagtcentral og alternative vagtcentraler.

Eksempel:

Tilmelding af AT

Navn: Peter Jensen
Adresse: Østergade 40
Netadresse: 03 17 23 02345
PVC: 01 - 02 17 22 00014
AVC: 02 - 01 04 16 00018
02 - 01 04 16 00017

Oplysningerne afleveres
til utilitymodulet, der bruger dem til ændringer i DCs database.

Der foretages ændringer i TS-beskrivelsen i DC for den TS, som den nye AT tilsluttes, idet
AT-adressen tilføjes i AT-kartoteket over tilknyttede ATer og i routningstabellen for TSen.
Desuden oprettes en AT-beskrivelse for den nye AT. Denne forsynes med
abonnentens navn og adresse, netadressen for ATen,
netadresse og kode for primær VC og aktuel VC og desuden et VC-adressekartotek med netadresse
og kode for primær og alternative VCer. UTIL vælger selv disse koder.

Herefter sender UTIL nogle af oplysningerne til den TS, som den nye AT tilsluttes, og efter oprettelsen
er foretaget her, kvitteres til DCs utilitymodul.

Eksempel på meddelelse til TS:

- Modtager: 03 17 23 00000 ATs TS
- Afsender: 03 00 00 00000 ATs DC
- Operationskode: "Tilmeld AT"
- Datadel: 03 17 23 12345 netadresse AT
01 kode PVC
02 17 22 00014 adresse PVC
02 kode AVC
01 04 16 00018 adresse AVC
03 kode AVC
01 04 16 00017 adresse AVC

Nu sender UTIL i ATs DC oplysninger om oprettelse til UTIL i primær og alternative VCers DCer,
medmindre disse er identiske.

Eksempel:

- Modtager: 02 00 00 00000 PVCs DC
- Afsender: 03 00 00 00000 ATs DC
- Operationskode: "Tilmeld AT til PVC"
- Datadel: 03 17 23 12345 netadresse AT
02 17 22 00014 netadresse PVC

Her benyttes oplysningerne til opdatering af VC-beskrivelsens kartoteker over abonnenter og
abonnent-TSer. Hvis den pågældende VC er af type AT skal dens adressekartotek udvides med
den nye ATs adresse og en kode svarende hertil.

UTIL i VCs DC sender nu oplysninger til VCs TS om oprettelsen, hvorefter TS foretager sig det fornødne,
og sender en kvittering tilbage til UTIL i VCs DC, når oprettelsen er foretaget.

Eksempel:

- Modtager: 02 17 22 00000 VCs TS
- Afsender: 02 00 00 00000 VCs DC
- Operationskode: "Tilmeld AT til PVC"
- Datadel: 03 17 23 12345 AT
02 17 22 00012 PVC
57 evt. kode for AT, hvis
PVC er AT-VC.

UTIL i VCs DC sender herefter en meddelelse til UTIL i ATs DC, der udskriver på
hovedkonsollen, at opgaven er udført.

Afmelding af en abonnent foretages også på ekspeditionskontorerne, men forudsætter en meddelelse fra
abonnentens PVC om afmeldingen.

Meddelelsen fra PVC resulterer i indsættelse af AT-adressen i tabellen "AT-afmelding" i DCs database:

>ne8
>sp8

Fra en terminal på DC indtastes:

Afmeld AT: "AT-adresse";

UTIL-modulet checker, om denne AT-adresse er indeholdt i tabellen AT-afmelding. Hvis dette ikke
er tilfældet, må afmeldingen ikke udføres, og der udskrives på terminalen:

AT-afmelding ikke tilladt

Hvis AT-adressen er indeholdt i tabellen, skal afmeldingen foretages. Først sletter UTIL den pågældende
adresse i tabellen AT-afmelding. Herefter sendes meddelelse om afmeldingen til ATs TS, der kvitterer,
når afmeldingen her er foretaget.

Fra en terminal indtastes:

Afmeld AT: "AT-adresse";

UTIL sender meddelelse om afmeldingen til ATs TS, der kvitterer, når afmeldingen her er
foretaget.

Eksempel:

- Modtager: 03 17 23 00000 ATs TS
- Afsender: 03 00 00 00000 ATs DC
- Operationskode: "Afmeld AT"
- Datadel: 03 17 23 12345 AT

UTIL udfører afmelding i DC ved at fjerne AT fra TS-beskrivelsens kartotek over ATer og VCer.
Desuden slettes ATens AT-beskrivelse fra databasen.

UTIL sender nu meddelelse til de DCer, som ATens primære og alternative VCer er tilsluttede.

Eksempel:

- Modtager: 02 00 00 00000 PVCs DC
- Afsender: 03 00 00 00000 ATs DC
- Operationskode: "Afmeld AT"
- Datadel: 03 17 23 12345 AT
02 17 22 00014 PVC

I hver af disse DCer sendes nu meddelelse til VCernes TSer om afmeldingen. TSerne udfører
deres afmelding og kvitterer herefter til DCerne.

Nu foretages afmelding i DC ved at fjerne AT fra VC-beskrivelsens abonnentkartotek,
opdatere abonnent-TS-kartoteket, og hvis VC er af type AT, så fjernes også ATs kode og netadresse
fra adressekartoteket. Så sendes kvittering for afmelding til ATs DC.

Når ATs DC har modtaget alle kvitteringer, udskriver UTIL på terminalen:

Afmelding foretaget på "AT-adresse"

>a3 Til-/afmelding af vagtcentraler.
Tilmelding af en vagtcentral foretages ligeledes fra ekspeditionskontorerne via en formatorienteret
skærm,
mens afmelding af en vagtcentral skal foretages fra operatørkonsollen.

Tilmelding starter med indtastning af kommandoen:

Tilmeld VC;

der besvares med et skærmbillede til oprettelse af en vagtcentral.
Skærmbilledet indeholder felter til angivelse af vagtcentralens navn og adresse, netadressen
og hvilke vagtcentraler, der kan overføres vagt til og fra.

Eksempel:

Tilmelding af vagtcentral:

Navn: ALARMETTA
Adresse: Nørreport 38
Netadresse: 02 17 22 00014
Type: IT
Vagtoverførsel til: 02 17 22 00013
Vagtoverførsel fra: 01 04 16 00018

Efter indtastningen benytter utilitymodulet oplysningerne til ændringer i DCs TS-beskrivelse
for den TS, som VCen tilsluttes, op til oprettelse af en VC-beskrivelse.

Oplysningerne tilføjes i TS-beskrivelsens kartotek over tilsluttede ATer og VCer. Desuden
oprettes i DC en VC-beskrivelse for den nye VC med oplysninger om VCens netadresse, type,
et VCa- og et VCm-kartotek (over lovlige flytninger)
og et kartotek over lovlige flytninger. Disse kartoteker indeholder
netadressen på VCer, der må overføre vagt fra hhv til den nye VC.

De VCer, som den nye VC må overføre sin vagt til/få overført vagt fra, skal informeres om dette.
Derfor sendes meddelelse herom til disse VCer. Hvis de accepterer (og således tilføjer den nye VC
i deres VCa- eller VCm-kartotek), sendes kvittering tilbage til DC og operatøren,
ellers sendes et afslag.

Herefter sender utilitymodulet besked til den nye VCs TS om oprettelsen, f.eks.:

- Modtager: 02 17 22 00000 ny VCs TS
- Afsender: 02 00 00 00000 ny VCs DC
- Operationskode: "Tilmeld VC"
- Datadel: 02 17 22 0000 4 ny VC
02 17 22 00013 VCm-kartotek

I TS foretages lignende ændringer, og når oprettelsen er foretaget i TS, kvitteres til DC,
der igen kvitterer til operatøren:

Eksempel:

- Modtager: 02 00 00 00000 VCs DC
- Afsender: 02 17 22 00000 VCs TS
- Operationskode: "VC tilmeldt"
- Datadel: 02 17 22 00004 VC

tilmelding foretaget på "VC-adresse".

Afmelding af en vagtcentral sker efter ordre fra hovedkonsollen:

Afmeld VC: "VC-adresse";

Kun personer med speciel tilladelse kan udstede denne ordre.

Det skal sikres, at vagtcentralen ikke indgår i VCa-VCm-kartoteket, d.v.s. at der ikke er
overført vagt fra eller til denne VC.

Utilitymodulet starter med at sende besked om afmeldingen til den pågældende vagtcentral.

Der findes en fortegnelse over VCens abonnenter i VC-beskrivelsens abonnentkartotek. Herudfra
foretages afmelding af alle abonnenter, der har denne VC som PVC. Hos abonnenter, der har
denne VC som AVC, skal VCen og dennes kode og bloklængde fjernes fra deres AT-adressekartotek.
Denne ændring skal foretages både i ATs TS og ATs DC.

Så gives besked om afmeldingen til alle vagtcentraler i VCa- og VCm-kartoteket for denne VC,
hvorefter disse VCers VCa- og VCm-kartoteker opdateres (VCm-kartoteker opdateres både i
VCens DC og TS).

VCen skal nu fjernes fra VC(AT)- eller VC(IT)-kartoteket i DC.

Herefter sendes besked til VCens TS om afmeldingen:

- Modtager: 02 17 22 00000 VCs TS
- Afsender: 02 00 00 00000 VCs DC
- Operationskode: "Afmeld VC"
- Datadel: 02 17 22 00014 VC

Når afmeldingen er foretaget her, sendes kvittering til DC, der kvitterer til operatøren:

Afmelding foretaget på "VC-adresse".

>a3 Til-/afmelding af netknuder.
Det er muligt at til- og afmelde TSer, NCer og DCer. Disse operationer initieres
af operatøren i DC gennem en MML-kommando på operatørkonsollen.

Eksempel:

TS-tilmelding: NC = "NC-adresse";

Ved tilmelding af en TS (TSn) under en bestemt NC (NCn) som angivet i MML-kommandoen,
vælger utilitymodulet en passende netadresse for TSn. De første to led i denne netadresse
skal være identisk med de tilsvarende led i NCns netadresse, det sidste led skal
være 0, mens tredje led vælges, så det er forskelligt fra tredje led i netadresserne på de
øvrige TSer under samme NC og forskelligt fra 0. Herved bliver netadressen også forskellig
fra alle andre netknuders adresse.

Herefter skal der oprettes en TSn-beskrivelse i den DC, hvorunder TSn tilsluttes (DCn).
Desuden foretages en ændring i NCn-beskrivelsen i DCn. Denne ændring består i at tilføje TSn
i routningstabellen.

Så sendes meddelelse til NCn om oprettelsen med den nye netadresse:

- Modtager: NCn-adresse
- Afsender: DCn-adresse
- Operationskode: "Tilmeld TS"
- Datadel: TSn-adresse

I NCn tilkobles den fysiske forbindelse til TSn og den logiske forbindelse etableres bl.a.
ved ændring i routningstabellen i NCn. Netadressen på TSn sendes til TSn.

Så kvitteres til DC og operatøren, at tilmeldingen er foretaget.

Tilmelding af en ny NC under en DC foregår på lignende måde. Operatøren sender kommandoen:

Tilmeld NC;

hvilket resulterer i, at der bliver tilmeldt en NC under den DC, hvor kommandoen afgives.
Utilitymodulet i denne DC vælger en passende netadresse for den nye NC. Første led i netadressen
skal være lig med første led i DCs adresse, de sidste to led skal være 0, mens andet led
vælges forskelligt fra 0 og forskelligt fra andet led i netadresserne for de øvrige
NCer under denne DC. DC forsynes med en NC-beskrivelse for denne NC, og NCen tilføjes
i DCs routningstabel. Netadressen sendes ud til NCen og der kvitteres til operatøren.

Tilmelding af en ny DC foregår fra en af de eksisterende DCer og kræver ændringer i routningstabellerne
i de eksisterende DCer.

Afmelding af en netknude foregår også gennem utilitymodulet. En afmelding initieres
fra den DC, hvor netknuden er tilmeldt og forudsætter, at alle underliggende knuder
er afmeldt.

Eksempel MML-kommando til afmelding af TS:

Afmeld TS: "TS-adresse";

En sådan kommando resulterer i fjernelse af TS-beskrivelsen i DC og ændringer i DCs
NC-beskrivelse for den tilsluttede NC. Desuden ændres routningstabellen i NC.

Afmelding af en NC foregår på lignende måde, mens afmelding af en DC kræver ændringer
i de øvrige DCers routningstabeller.

>a3 Test af ATer internt og eksternt.
Test af en AT kan foretages af operatøren i DC gennem en MML-kommando, eks.:

Test int: adresse = "AT-adr";

MML-kommandoen fortolkes af operatørmodulet og afleveres til UTIL.

UTIL opretter en meddelelse:

- Modtager: "ATs TS"
- Afsender: "DC-adresse"
- Operationskode: "AT-test int"
- Datadel: "AT-adresse"

Meddelelsen sendes således til TS, der skal udføre testen. Når testen er udført, sendes resultatet
heraf til DC, hvorefter det udskrives på konsollen.

Ekstern test kan udføres ved en analog kommando. Desuden kan ekstern test udføres på et enkelt
sæt data.

Eksempel:

Test ext: adresse = "AT-adr", data = 01010101;

Den resulterende meddelelse fra DC til ATs TS indeholder i datadelen både AT-adresse og det
valgte datasæt. Som svar på denne test fås datosættet som det ser ud, efter testen er
udført.

>a2 Logmodul.
>a3 Logmodulets opgaver.
Logmodulet har følgende opgaver:

- Udskrivning af logmeddelelser til logfil.
- Printerudskrifter af udvalgte dele af logfilen.
- Dump af logfilen til magnetbånd.

I de næste afsnit vil vi beskrive hvorledes disse opgaver udføres.

>a3 Logmeddelelser.
Logmodulet vedligeholder logfilen. Logfilen er den fil, hvor alle logmeddelelser
skrives ud.

>a4 Logmeddelelsens indhold.
En logmeddelelse skives på fil som
en
record indeholdende følgende information:

- Afsenderadresse
- Modtageradresse
- Tidspunkt for generering af logmeddelelsen
- Den oprindelige meddelelse (incl. operationskode)

Bemærk, at afsender- og modtageradr. er de oprindelige adresser. Ved modtagelsen i DC
var disse adresser en del af pakkens dataindhold.

>a4 Logmeddelelsers oprindelse.
En logmeddelelse genereres af TSer, NCer eller DCer i nettet hver gang der indtræffer
"en begivenhed". Det sker f.eks. ved afsendelse af en alarm fra en TS, når alarmen er skrevet ud i VCens TS, o.s.v.

Endvidere genereres logmeddelelser i DCen selv, når:

- Operatøren taster en kommando
- Utilitymodulet udfører en kommando
- Databasemodulet udfører en kommando
- Logmodulet udfører en kommando (bortset fra
logning af en meddelelse)

>a4 Logfilens udseende.
Logfilen indeholder logmeddelelser i form af records: en record pr. meddelelse.

Disse records er af variabel længde (og indeholder alle deres længde i første ord).

Selve filen er opdelt i blokke a N segmenter.

Først på hver blok står hvilket tidsrum denne blok rummer logmeddelelser fra.

>a3 Printerudskrifter fra logfilen.
På anfordring (fra operatørmodulet) skal logmodulet kunne udskrive nærmere angivne logmeddelelser
i læseligt format, både ud fra den del af logfilen, der befinder sig på discen, og ud fra
magnetbånd.

Operatøren kan f.eks. bede om en liste over alle hændelser omkring en given AT i et givet tidsrum.

Eksempel:

Udskriv log: tid = 020280-040280,
adresse = 03 17 23 12345;

>a3 Dump af logfilen.
Med passende mellemrum skal logfilen dumpes til magnetbånd.

Logmodulet giver operatøren besked i god tid før logfilen er fuld:

Advarsel: dump logfilen

Operatøren kan derefter initiere dump af logfilen ved at indtaste på hovedkonsollen:

Dumplog;

>a2 Errorhandler.
Errorhandler indeholder programmel til behandling af fejlmeddelelser og skal desuden være
i stand til at reloade underliggende netknuder efter break-down.

Ved reload af underliggende netknuder hentes den nødvendige information hertil fra databasen, hvorefter den sendes
til den pågældende netknude i form af almindelige netpakker.

Fejlmeldinger til DC afleveres i errorhandler (EH), der så sørger for den nødvendige behandling.

Fejl kan opdeles i følgende kategorier:

1) Fejl mellem AT og TS
2) Fejl mellem VC og TS
3) Fejl på nettet

>a3 Fejl mellem en AT og TS.
Fejl mellem en AT og en TS opdages i DCs EH ved, at der kommer en liniealarm eller en
transmissionsalarm.

En liniealarm optræder, når der har været to transmissionsfejl i træk. Transmissionsalarmer
optræder, når antallet af transmissionsfejl overstiger en bestemt grænse.
Ved AU-status sendes ikke alarm til DC, kun til primær VC.

EH reagerer på en alarm ved at udskrive alarmen på en skærm i DC, hvorved en del af behandlingen overlades til en operatør.

Eksempel på skærmudskrift:

Liniealarm: "AT12-adresse"

Ved transmissionsalarm sender EH ordre tilbage til ATs TS om at nulstille transmissionsfejltælleren.

>a3 Fejl mellem VC og TS.
Fejl mellem en VC og en TS opdages i DCs EH på en af tre måder, enten ved at der kommer en
liniealarm (p.g.a. to transmissionsfejl i træk), eller en transmissionsalarm (når grænsen for
antal transmissionsfejl er overskredet), eller hvis VC er af type AT, kan der komme statusalarm
(efter en STATUS-meddelelse fra AT til TS).

EH sørger for udskrivning af disse alarmer på en dataskærm i DC, hvor operatøren så skal sørge for den
videre behandling af fejlen.

Eksempel:

Statusalarm: "VC8-adresse"

Desuden modtager EH de alarmer, som den pågældende VC ikke selv er i stand til at modtage.
EH udskriver også disse alarmer på dataskærm.

Eksempel:

Alarm fra "AT78-adresse" til "VC8-adresse": 11

Operatøren på DC kan nu vælge gennem en kommando til OPT enten at overføre den pågældende VCs
vagt til en anden VC, eller at VCs abonnenter ikke længere skal POLLes.

I første tilfælde giver OPT utilitymodulet ordre til at udføre en vagtoverførsel.
I andet tilfølde giver OPT besked til EH om ophør af POLL.

Ved standsning af POLL, skal EH sende en meddelelse herom til alle TSer
med abonnenter, der har denne VC som PVC. Meddelelsen kan have følgende format:

- Modtager: En af de pågældende TSer
- Afsender: DCs adresse
- Operationskode: Poll ophør
- Datadel: VC-adresse

Herefter sørger TSerne selv for at ophøre med at polle de pågældende ATer.

>a3 Fejl på nettet.
Ved fejl på nettet (TS, linien mellem TS og NC, NC eller linien mellem NC og DC) skal nederste
fungerende knude (d.v.s. NC eller DC) sende meddelelse herom til EH.

Eksempel på meddelelse:

- Modtager: "DC-adresse"
- Afsender: "NC1-adresse"
- Operationskode: netfejl
- Datadel: "TS1-adresse"

EH udskriver fejlen på hovedkonsollen i DC.

Eksempel:

Netfejl: "TS-adresse" - "NC-adresse"

TSerne under bruddet sørger for at underrette de underliggende VCer om fejlen, og holder op
med at polle de ATer, hvis PVC ligger på den anden side af bruddet. EH skal underrette
alle fungerende NCer, der så underretter deres underliggende TSer om fejlen.

Eksempel:

- Modtager: "NC2-adresse"
- Afsender: "DC-adresse"
- Operationskode: Netfejl
- Datadel: "TS1-adresse"

- Modtager: "TS2-adresse"
- Afsender: "NC2-adresse"
- Operationskode: Netfejl
- Datadel: "TS1-adresse"

Operatøren i DC kan vælge mellem følgende muligheder:

1) EH modtager alarmer fra ATer uden for bruddet
til VCer under bruddet.

2) EH overfører involverede VCers vagt til VCer
uden for bruddet.

3) Poll af ATer, hvis PVC er involveret i bruddet,
standses.

Indtil operatøren har meddelt andet, sendes alarmer fra ATer uden for bruddet med adresse på VC
under bruddet til EH, der udskriver dem på konsollen. Operatøren kan omadressere disse alarmer.

Alarmer fra ATer under bruddet til PVCer uden for burddet kan ikke komme frem, hverken til PVC eller DC.
Vagten på PVC kan heller ikke overføres til en VC under bruddet, da kun
PVC og DC har myndighed til dette, og ingen af disse har forbindelse til den anden side af bruddet.

Det er altså nødvendigt at ophøre med at polle de ATer under bruddet, hvis PVC ligger over bruddet.
Det har den bivirkning, at alarmer til AVCer under bruddet heller ikke kan komme frem.

Eksempel:

>ne14
>sp14

TS1 ophører med at polle AT, da alarmer til PVC ikke kan komme igennem hverken til PVC eller DC.
Som bivirkning ses, at alarmer fra AT til AVC ikke kommer igennem, selv om forbindelsen her
er i orden.

Operatøren kan via en kommando til OPT overføre vagten på VCer under bruddet til VCer uden for bruddet.
Denne vagtoverførsel vil p.g.a. bruddet kun blive gennemført uden for bruddet og gælder
således kun for de af VCernes abonnenter, der ligger uden for bruddet. Abonnenter under bruddet, som stadig har forbindelse
til VCerne her, berøres ikke af vagtoverførslen.

Eksempel:

>ne14
>sp14

AT1 og AT2 har VC1 som PVC. Efter bruddet mellem NC1 og TS1, sender operatøren ved DC
kommandoen:

Overfør vagt: afsender = "VC1", modtager = "VC2";

til OPT, hvor den fortolkes og afleveres til UTIL.

UTIL sørger for at overføre vagten fra VC1 til VC2. Dette registreres i flyttekartoteket i TS2,
men ikke i TS1 p.g.a bruddet. Herefter vil alarmer fra AT1 til PVC blive sendt til VC1,
mens alarmer fra AT2 til PVC bliver sendt til VC2.

Når fejlen er repareret, sendes meddelelse til DCs EH herom.

Eksempel:

- Modtager: "DC-adresse"
- Afsender: "NC1-adresse"
- Operationskode: Netfejl rettet
- Datadel: "TS1-adresse"

Meddelelsen udskrives på konsollen, f.eks.

NC1 - TS1 repareret

Herefter skal flyttekartotekerne i TSerne gøres konsistente, idet vagtoverførsler der er
foretaget, mens der var brud kun gælder enten uden for eller under bruddet.

Situationen under det tidligere brud skal nu gælde overalt i nettet.

Derfor skal EH for hver eneste VC under det tidligere brud have besked (fra TSer under bruddet) om VCens status,
d.v.s. om den har overført vagten og i bekræftende fald til hvem.

Eksempel:

- Modtager: "DC-adresse"
- Afsender: "TS1-adresse"
- Operationskode: opdatering
- Datadel: "VC-adresse" (*VC1 har overført*)
"VC3-adresse" (*sin vagt til VC3*)

Herefter skal EH rundsende disse oplysninger til alle TSer (uden for det tidligere brud),
der så skal opdatere deres flyttekartoteker i overensstemmelse hermed.

>a2 Databasemodul.
Databasemodulet indeholder programmel til kommunikation med databasen. Dette programmel er ikke
fastlagt endnu og bliver derfor først beskrevet på et senere tidspunkt.

Databasen skal bl.a. indeholde følgende beskrivelser af de underliggende knuder:

Beskrivelse af DCs RC3502
NC-beskrivelser
TS-beskrivelser
AT-beskrivelser
VC-beskrivelser

Beskrivelsen af DCs RC3502 og NC-beskrivelserne indeholder rutningstabeller.

En TS-beskrivelse indeholder et VCa-VCm-kartotek over aktuelle vagtoverførsler, et AT-kartotek over
tilsluttede ATer, et VC(AT)- og et VC(IT)-kartotek over tilsluttede VCer.

En AT-beskrivelse indeholder et AT-adressekartotek med adresse, kode og bloklængde på alle VCer,
der kan modtage alarmer herfra.

En VC-beskrivelse indeholder et abonnentkartotek og et AT-TS-kartotek. Desuden er der et
VCa- og et VCm-kartotek til angivelse af lovlige vagtoverførsler hhv. til og fra denne VC.
Hvis VC-beskrivelsen dækker en VC af type AT findes der også et VC-adressekartotek
med netadresse og adressekode på alle ATer, der er tilsluttet denne VC.

herudover indeholder databasen programmel til reload af netknuderne.

>a2 Netinterface.
Dette modul udgør interfacet mellem RC8000 og nettet.

Meddelelser fra RC8000 til nettet pakkes her til det krævede format med modtageradresse,
afsenderadresse (= DCs netadresse), operationskode og datadel.

Modulet udpakker meddelelser til RC8000 fra nettet. Det checkes, at modtageradressen er lig med
DCs netadresse. Desuden aflæses operationskoden for at afgøre hvilket modul, der skal behandle meddelelsen.

>a2 Øvrige moduler.
BASIS-modulet skal indeholde det nødvendige basisprogrammel, der ligesom de øvrige viste moduler
består af standardprogrammer, der ikke vil blive beskrevet her.

>a1 MODULER I RC3502.
>a2 NETPROGRAMMEL
Netprogrammellet i RC3502 sørger for modtagelse, afsendelse og videresendelse af pakker.

Når der kommer en pakke fra nettet, afgør en rutningsalgoritme ud fra pakkens netadresse,
om pakken skal afleveres til RC8000, om den skal videresendes til et af de øvrige distriktscentres
RC3502 via en X.75 gateway, eller om den skal sendes nedad i nettet, og i så fald til hvilken NC.

Det er også op til netprogrammellet at kunne foretage nødvendige retransmissioner.

Netprogrammellet har desuden til opgave at overvåge RC8000, de underliggende NCer og de øvrige DCers
RC3502. Ved fejl i en netknude sendes meddelelse herom til DC.

▶EOF◀

DataMuseum.dk

RC4000/8000/9000

⟦65fc49a6d⟧ TextFile

Derivation

TextFile