Prot 2010 vizsga 2

A VIK Wikiből
A lap korábbi változatát látod, amilyen (vitalap) 2012. október 21., 20:44-kor történt szerkesztése után volt. (Új oldal, tartalma: „{{GlobalTemplate|Infoszak|Prot_2010_vizsga_2}} ==Protokoll Technológia 2010 első vizsga== ====1.- Ismertesse milyen lépésekben történik a jelzéshálózat átko…”)
(eltér) ← Régebbi változat | Aktuális változat (eltér) | Újabb változat→ (eltér)
Ugrás a navigációhoz Ugrás a kereséshez

Ez az oldal a korábbi SCH wiki-ről lett áthozva. Az eredeti változata itt érhető el.

Ha úgy érzed, hogy bármilyen formázási vagy tartalmi probléma van vele, akkor kérlek javíts rajta egy rövid szerkesztéssel.

Ha nem tudod, hogyan indulj el, olvasd el a migrálási útmutatót


Protokoll Technológia 2010 első vizsga

1.- Ismertesse milyen lépésekben történik a jelzéshálózat átkonfigurálása, ha ezek a linkek meghibásodnak típusú feladat: (2. feladat)

Ez idén (2011 tavasz) nem volt órán.

2.- Hívás felépítős feladat sok központon keresztül (3. feladat)

3.- Hogyan zajlik egy tesztlaborban egy protokoll megvalósítás tesztelése (hogyan választjuk ki a futtatandó teszteket, milyen dokumentumok használatosak)?

Input: PICS és PIXIT. Ezek alapján meghatározzák, hogy:

  • Mely teszteseteket
  • Milyen paraméterekkel
  • Milyen elrendezésben

kell tesztelni. Az Abstract Test Suite-ból Executable TS-ot készítenek. A futtatás során minden lényeges esemény naplózásra kerül.

Output:

PCTR:

  • Milyen megvalósításon
  • Mely vizsgálatokat
  • Milyen opciók mellett
  • Milyen elrendezésben
  • Milyen eredménnyel

hajtottak végre

SCTR: A teljes vizsgált rendszert jellemzi

4.- Ismertesse egy SMS útját a feladó központjától a címzett központjáig

Tk. 138. oldal 88.,89. ábra összefűzve:

Ezen a helyen volt linkelve a 88.abra_sms_kuldes.jpg nevű kép a régi wiki ezen oldaláról. (Kérlek hozd át ezt a képet ide, különben idővel el fog tűnni a régi wikivel együtt)


Ezen a helyen volt linkelve a 89.abra_sikeres_sms_fogadas.jpg nevű kép a régi wiki ezen oldaláról. (Kérlek hozd át ezt a képet ide, különben idővel el fog tűnni a régi wikivel együtt)


5.- GSM Location Update NSS-ben

Tk. 137. o, 87. ábra:

Ezen a helyen volt linkelve a 87.abra_helyzetfrissites.jpg nevű kép a régi wiki ezen oldaláról. (Kérlek hozd át ezt a képet ide, különben idővel el fog tűnni a régi wikivel együtt)


6.- GPRS-ben miért kell csökkenteni a paginget, és hogyan oldják meg?

Az adatforgalom börsztös, tehát kis-kis adagokban megy egymás után. Ennek következtében két adatbörszt közötti cellavándorlás kikerülése végett, paging-et kell küldeni, hogy hol van a fogadó fél, hogy oda menjen az adat. Viszont ez rentgeteg paginget jelentene, ezért felosztották a location area-kat routing area-kra amik sokkal kisebbek, és elég csak egy ilyen kisebb környezetben jelezni, ami nem egy egész nagy location area-t terhel.

  • IDLE állapot: a mobil állomás (MS) nem kapcsolódik a GPRS hálózathoz, ilyenkor sem adatforgalmazás, sem a felhasználó kiértesítése (paging) nem lehetséges, a felhasználó elérhetetlen; a PDP környezet létrehozásához az MS-nek el kell végeznie a GPRS bejelentkezés folyamatát.
  • STANDBY állapot: a mobil állomás (MS) már kapcsolódott a GPRS hálózathoz, így kiértesítése lehetséges, adatforgalmazás azonban ilyenkor sem. MS helyzetét routing area szinten ismerjük.
  • READY állapot: a mobil állomás (MS) képes PDP PDU-k (Packet Data Unit) küldésére és fogadására; az SGSN folyamatosan frissíti az útvonal- és cellaválasztási információkat. MS helyzetét cella szinten ismerjük.

Idle állapotból Ready állapotba úgy kerülhetünk ha bejelentkezünk a GPRS hálózatba. Ha kijelentkezünk akkor visszakerülünk Idle-ba. Ha Ready állapotban vagyunk és egy darabig nem küldünk adatot vagyis lejár a timer átkerülünk Standby állapotba. Standby állapotból Ready állapotba egy keret küldéssel léphetünk. Ha Standby állapotba vagyunk és itt is lejár a timer vagy kijelentkezünk a gprs hálózatból akkor visszakerülünk Idle állapotba.

Ide még kell folyamatábra is.

7.- SDL diagramm rajzolás

Tk. 12. oldal, 5. ábra.
SDL órai példa

8.- ASN1:

a.) kódolja ezt konkrét értékekre, ahol lehet használjon indefinit hosszkódolást:
 send1 OPERATION
	ARGUMENT
		routingInforSM-AG [15] SEQUENCE {
			 
			  msisdn [1] OCTET STRING (SIZE(1..9))),
			  sm-RP-PRO [31] BOOLEAN,
			  serviceCentreAddress [22] IPMLICIT OCTET STRING (SIZE(1..20)),
			  teleservice [5] IMPLICIT OCTET STRING (SIZE(1)) OPTIONAL
		}

Megoldás ITT

b.) milyen típusú TCAP komponensben küldhetjük ezt az üzenet?

Pontos válasz TK/116.o utolsó bekezdésében:

  • ARGUMENT kulcsszó után specifikált üzenetszerkezet használható Invoke komponensekben (ennél a feladatnál most ez van)
  • RESULT kulcsszó után specifikált üzenetszerkezet használható Return Result komponensekben
  • ERROR kulcsszó után specifikált üzenetszerkezet használható Return Error komponensekben


9.- Ismertesse két digitális ISDN készülék közötti hívás felépülését, ha a két készülék különböző központban van!

104. oldal, 72. ábra:

Ezen a helyen volt linkelve a 72.abra_dss1-isup-dss1.jpg nevű kép a régi wiki ezen oldaláról. (Kérlek hozd át ezt a képet ide, különben idővel el fog tűnni a régi wikivel együtt)


10.- Ismertesse egy mobil készüléken végződő hívás (MT call) felépülését az A interfészen!

133. oldal, 84. ábra:

Ezen a helyen volt linkelve a 84.abra_hivasfogadas_az_a_interfeszen.jpg nevű kép a régi wiki ezen oldaláról. (Kérlek hozd át ezt a képet ide, különben idővel el fog tűnni a régi wikivel együtt)


-- Sopi - 2011.06.15.

-- Liba - 2010.06.07.