A cikkben "", az NB-IoT hálózat csomagmagjának architektúrájáról szólva megemlítettük egy új SCEF csomópont megjelenését. A harmadik részben elmagyarázzuk, mi ez és miért van szükség rá?
Az M2M szolgáltatás létrehozásakor az alkalmazásfejlesztők a következő kérdésekkel szembesülnek:
- hogyan lehet azonosítani az eszközöket;
- milyen ellenőrzési és hitelesítési algoritmust kell használni;
- melyik szállítási protokollt kell választani az eszközökkel való interakcióhoz;
- hogyan lehet megbízhatóan eljuttatni az adatokat az eszközökhöz;
- hogyan kell megszervezni és kialakítani a velük való adatcserére vonatkozó szabályokat;
- hogyan lehet online nyomon követni és információt szerezni állapotukról;
- hogyan lehet egyidejűleg adatokat eljuttatni eszközei egy csoportjához;
- hogyan lehet egyszerre adatokat küldeni egy eszközről több kliensnek;
- hogyan érhet el egységes hozzáférést a készülék kezeléséhez szükséges további szolgáltatói szolgáltatásokhoz.
Megoldásukhoz saját fejlesztésű, műszakilag „nehéz” megoldások megalkotása szükséges, ami megnövekedett munkaerő-költségekhez és a szolgáltatások piacra kerülésének idejéhez vezet. Itt jön a segítség az új SCEF csomópont.
A 3GPP definíciója szerint az SCEF (service capability expozíciós funkció) a 3GPP architektúra egy teljesen új komponense, amelynek funkciója a 3GPP hálózati interfészek által nyújtott szolgáltatások és képességek biztonságos megjelenítése API-kon keresztül.
Egyszerűen fogalmazva, az SCEF egy közvetítő a hálózat és az alkalmazásszerver (AS) között, egyetlen hozzáférési ablak az üzemeltetői szolgáltatásokhoz az M2M eszköz kezeléséhez az NB-IoT hálózatban egy intuitív, szabványos API interfészen keresztül.
Az SCEF elrejti az üzemeltetők hálózatának összetettségét, lehetővé téve az alkalmazásfejlesztők számára, hogy elvonatkoztassák az eszközökkel való interakcióhoz szükséges összetett, eszközspecifikus mechanizmusokat.
Azáltal, hogy a hálózati protokollokat az alkalmazásfejlesztők számára ismert API-kká alakítja, az SCEF API megkönnyíti az új szolgáltatások létrehozását és csökkenti a piacra kerülési időt. Az új csomópont a mobileszközök azonosítására/hitelesítésére szolgáló funkciókat is tartalmaz, meghatározza az eszköz és az AS közötti adatcsere szabályait, nem kell az alkalmazásfejlesztőknek ezeket a funkciókat saját oldalukon implementálnia, és ezeket a funkciókat a kezelő vállára hárítja.
Az SCEF lefedi az alkalmazásszerverek hitelesítéséhez és engedélyezéséhez, az UE mobilitás fenntartásához, adatátvitelhez és eszközkioldáshoz, további szolgáltatásokhoz való hozzáféréshez és üzemeltetői hálózati képességekhez szükséges interfészeket.
Az AS felé egyetlen T8 interfész van, egy API (HTTP/JSON), amelyet a 3GPP szabványosít. A T8 kivételével minden interfész a DIAMETER protokoll alapján működik (1. ábra).
T6a – interfész az SCEF és az MME között. Mobilitás/munkamenet-kezelési eljárásokhoz, nem IP adatok továbbításához, megfigyelési események biztosításához és az azokról szóló jelentések fogadásához használható.
S6t – interfész az SCEF és a HSS között. Szükséges az előfizetői hitelesítéshez, az alkalmazáskiszolgálók engedélyezéséhez, a külső azonosító és az IMSI/MSISDN kombinációjának megszerzéséhez, a megfigyelési események biztosításához és az azokról szóló jelentések fogadásához.
S6m/T4 – interfészek az SCEF-től a HSS-hez és az SMS-C-hez (3GPP definiálja az MTC-IWF csomópontot, amely eszköztriggerelésre és SMS továbbításra szolgál NB-IoT hálózatokban. Ennek a csomópontnak a funkcionalitása azonban minden megvalósításban integrálva van SCEF, ezért az áramkör egyszerűsítése érdekében nem fogjuk külön megvizsgálni). SMS-küldéshez és az SMS-központtal való interakcióhoz szükséges útválasztási információk lekérésére szolgál.
T8 – API interfész SCEF interakcióhoz alkalmazásszerverekkel. Mind a vezérlőparancsok, mind a forgalom továbbítása ezen az interfészen keresztül történik.
*a valóságban több interfész létezik, itt csak a legalapvetőbbek vannak felsorolva. A teljes listát a 3GPP 23.682 (4.3.2 Referenciapontok listája) tartalmazza.
Az alábbiakban az SCEF legfontosabb funkciói és szolgáltatásai találhatók:
- a SIM-kártya azonosítójának (IMSI) összekapcsolása külső azonosítóval;
- nem IP forgalom továbbítása (Non-IP Data Delivery, NIDD);
- csoportműveletek külső csoportazonosító használatával;
- adatátviteli mód támogatása megerősítéssel;
- MO (Mobile Originated) és MT (Mobile Terminated) adatok pufferelése;
- Eszközök és alkalmazásszerverek hitelesítése és engedélyezése;
- egy UE-ból származó adatok egyidejű használata több AS által;
- speciális UE állapotfigyelő funkciók támogatása (MONTE – Monitoring Events);
- készülék kioldása;
- nem IP adatbarangolást biztosít.
Az AS és az SCEF közötti interakció alapelve az úgynevezett sémán alapul. előfizetések. Ha egy adott UE-hez hozzá kell férni bármely SCEF-szolgáltatáshoz, az alkalmazásszervernek létre kell hoznia egy előfizetést úgy, hogy parancsot küld a kért szolgáltatás adott API-jához, és válaszként egyedi azonosítót kell kapnia. Ezt követően minden további művelet és kommunikáció az UE-vel a szolgáltatás keretében ezen azonosító használatával történik.
Külső azonosító: Univerzális eszközazonosító
Az egyik legfontosabb változás az AS és az eszközök közötti interakciós sémában az SCEF-en keresztüli munka során az univerzális azonosító megjelenése. Mostantól telefonszám (MSISDN) vagy IP-cím helyett – ahogy az a klasszikus 2G/3G/LTE hálózatban volt – az alkalmazásszerver eszközazonosítója „külső azonosító” lesz. A szabvány határozza meg az alkalmazásfejlesztők számára ismert formátumban. @ "
A fejlesztőknek már nem kell eszközhitelesítési algoritmusokat alkalmazniuk, a hálózat teljes mértékben átveszi ezt a funkciót. A külső azonosító az IMSI-hez van kötve, és a fejlesztő biztos lehet benne, hogy egy adott külső azonosító elérésekor az adott SIM-kártyával lép kapcsolatba. SIM chip használatakor teljesen egyedi helyzetbe kerül, amikor a külső azonosító egyedileg azonosít egy adott eszközt!
Sőt, egy IMSI-hez több külső azonosító is kapcsolható – még érdekesebb helyzet adódik, ha a külső azonosító egyedileg azonosít egy adott eszközön egy adott szolgáltatásért felelős alkalmazást.
Megjelenik egy csoportazonosító is – külső csoportazonosító, amely egyedi külső azonosítók halmazát tartalmazza. Mostantól egyetlen kéréssel az SCEF-hez az AS csoportműveleteket kezdeményezhet – adatokat vagy vezérlőparancsokat küldhet több, egyetlen logikai csoportba egyesített eszköznek.
Tekintettel arra, hogy az AS fejlesztők számára az új eszközazonosítóra való áttérés nem lehet azonnali, az SCEF meghagyta az AS kommunikáció lehetőségét az UE-vel egy szabványos számon - MSISDN - keresztül.
Nem IP forgalom továbbítása (Non-IP Data Delivery, NIDD)
Az NB-IoT-ben a kis mennyiségű adat továbbítására szolgáló mechanizmusok optimalizálásának részeként a már meglévő PDN-típusok, mint például az IPv4, IPv6 és IPv4v6 mellett egy másik típus is megjelent - a nem IP. Ebben az esetben az eszköz (UE) nem kap IP-címet, és az adatok továbbítása az IP-protokoll használata nélkül történik. Az ilyen kapcsolatok forgalmát kétféleképpen lehet irányítani: klasszikus - MME -> SGW -> PGW, majd a PtP alagúton keresztül az AS-hez (2. ábra) vagy az SCEF használatával (3. ábra).
A klasszikus módszer nem kínál különösebb előnyt az IP-forgalomhoz képest, kivéve az átvitt csomagok méretének csökkentését az IP-fejlécek hiánya miatt. Az SCEF használata számos új lehetőséget nyit meg, és jelentősen leegyszerűsíti az eszközökkel való interakciós eljárásokat.
Az SCEF-en keresztüli adatátvitel során két nagyon fontos előny jelenik meg a klasszikus IP-forgalommal szemben:
MT forgalom eljuttatása a készülékre külső azonosítón keresztül
Ha üzenetet szeretne küldeni egy klasszikus IP-eszközre, az AS-nek ismernie kell az IP-címét. Itt egy probléma adódik: mivel a készülék a regisztrációkor általában „szürke” IP-címet kap, így egy NAT csomóponton keresztül kommunikál az interneten található alkalmazásszerverrel, ahol a szürke címet fehérre fordítják. A szürke és fehér IP-címek kombinációja a NAT-beállításoktól függően korlátozott ideig tart. Átlagosan TCP vagy UDP esetén - legfeljebb öt perc. Vagyis ha 5 percen belül nem történik adatcsere ezzel az eszközzel, akkor a kapcsolat megszakad, és a készülék már nem lesz elérhető azon a fehér címen, amellyel az AS-sel történő munkamenetet kezdeményezték. Számos megoldás létezik:
1. Használja a szívverést. A kapcsolat létrejötte után az eszköznek néhány percenként csomagokat kell cserélnie az AS-vel, megakadályozva ezzel a NAT-fordítások bezárását. De itt szó sem lehet energiahatékonyságról.
2. Minden alkalommal, ha szükséges, ellenőrizze a csomagok elérhetőségét az eszközhöz az AS-en - küldjön üzenetet a felfelé irányuló linkre.
3. Hozzon létre egy privát APN-t (VRF), ahol az alkalmazásszerver és az eszközök ugyanazon az alhálózaton lesznek, és rendeljen statikus IP-címeket az eszközökhöz. Működni fog, de szinte lehetetlen, ha több ezres, tízezres eszközparkról beszélünk.
4. Végül a legmegfelelőbb lehetőség: IPv6 használata, nem igényel NAT-ot, mivel az IPv6-címek közvetlenül elérhetők az Internetről. Azonban ebben az esetben is az eszköz újraregisztrálásakor új IPv6-címet kap, és már nem lesz elérhető a korábbi használatával.
Ennek megfelelően valamilyen eszközazonosítóval ellátott inicializálási csomagot kell küldeni a szervernek, hogy jelentsük az eszköz új IP-címét. Ezután várjon egy megerősítő csomagot az AS-től, ami szintén befolyásolja az energiahatékonyságot.
Ezek a módszerek jól működnek a 2G/3G/LTE eszközökön, ahol az eszköz nem támaszt szigorú autonómiai követelményeket, és ebből kifolyólag nincs korlátozás a műsoridővel és a forgalommal kapcsolatban. Ezek a módszerek magas energiafogyasztásuk miatt nem alkalmasak NB-IoT-re.
Az SCEF megoldja ezt a problémát: mivel az AS egyetlen eszközazonosítója egy külső azonosító, az AS-nek csak egy adatcsomagot kell küldenie az SCEF-nek egy adott külső azonosítóhoz, és az SCEF gondoskodik a többiről. Abban az esetben, ha az eszköz PSM vagy eDRX energiatakarékos módban van, az adatok pufferelésre kerülnek és kézbesítik, amikor az eszköz elérhetővé válik. Ha az eszköz elérhető a forgalom számára, az adatok azonnali kézbesítése megtörténik. Ugyanez igaz a vezetői csapatokra is.
Az AS bármikor előhívhatja a pufferelt üzenetet az UE-nek, vagy lecserélheti egy újra.
A puffermechanizmus akkor is használható, amikor MO-adatokat továbbítanak az UE-től az AS-hez. Ha az SCEF nem tudott azonnal adatokat eljuttatni az AS-hez, például ha karbantartási munka folyik az AS-kiszolgálókon, akkor ezek a csomagok pufferelve lesznek, és garantáltan kézbesítik, amint az AS elérhetővé válik.
Ahogy fentebb megjegyeztük, egy adott szolgáltatáshoz és UE-hez való hozzáférést egy AS-hez (és a NIDD egy szolgáltatás) az SCEF-oldali szabályok és szabályzatok szabályozzák, ami lehetővé teszi az egy UE-ból származó adatok több AS általi egyidejű felhasználásának egyedülálló lehetőségét. Azok. ha több AS előfizetett egy UE-ra, akkor az UE-tól kapott adatok fogadása után az SCEF elküldi azt az összes előfizetett AS-nek. Ez jól alkalmazható olyan esetekben, amikor egy speciális eszközpark készítője több kliens között oszt meg adatokat. Például az NB-IoT-n futó meteorológiai állomások hálózatának létrehozásával egyidejűleg sok szolgáltatásnak értékesítheti az azokból származó adatokat.
Garantált üzenetküldési mechanizmus
A megbízható adatszolgáltatás az MO és MT üzenetek garantált kézbesítésének mechanizmusa speciális protokollszintű algoritmusok használata nélkül, mint például a kézfogás a TCP-ben. Úgy működik, hogy az UE és az SCEF közötti csere során az üzenet szolgáltatási részében egy speciális jelzőt tartalmaz. Az AS dönt arról, hogy aktiválja-e ezt a mechanizmust a forgalom továbbításakor.
Ha a mechanizmus aktiválva van, az UE egy speciális jelzőt tartalmaz a csomag felső részében, amikor az MO forgalom garantált kézbesítését igényli. Egy ilyen csomag vételekor az SCEF nyugtával válaszol az UE-nek. Ha az UE nem kapja meg a nyugtázó csomagot, akkor az SCEF felé irányuló csomagot újra elküldi. Ugyanez történik az MT forgalommal is.
Eszközfigyelés (események figyelése – MONTE)
Mint fentebb említettük, az SCEF funkcionalitása többek között az UE állapotának figyelésére szolgáló funkciókat, az ún. eszközfigyelés. És ha az új azonosítók és adatátviteli mechanizmusok a meglévő eljárások optimalizálásai (bár nagyon komolyak), akkor a MONTE egy teljesen új funkció, amely nem érhető el a 2G/3G/LTE hálózatokban. A MONTE lehetővé teszi az AS számára, hogy figyelje az eszköz paramétereit, például a kapcsolat állapotát, a kommunikáció elérhetőségét, a helyet, a roaming állapotát stb. Mindegyikről egy kicsit később részletesebben fogunk beszélni.
Ha egy eszközhöz vagy eszközcsoporthoz bármilyen megfigyelési eseményt aktiválni kell, az AS előfizet a megfelelő szolgáltatásra úgy, hogy elküldi a megfelelő API MONTE parancsot az SCEF-nek, amely olyan paramétereket tartalmaz, mint a külső azonosító vagy külső csoportazonosító, AS azonosító, felügyelet. típus, jelentések száma, amelyeket AS szeretne kapni. Ha az AS jogosult a kérés végrehajtására, az SCEF a típustól függően biztosítja az eseményt a HSS-nek vagy az MME-nek (4. ábra). Amikor egy esemény bekövetkezik, az MME vagy a HSS jelentést generál az SCEF-nek, amely elküldi azt az AS-nek.
A „Földrajzi területen jelen lévő UE-k száma” kivételével minden esemény biztosítása HSS-n keresztül történik. Két esemény „Az IMSI-IMEI társítás változása” és a „Roaming állapot” közvetlenül követhető a HSS-en, a többit a HSS biztosítja az MME-n.
Az események lehetnek egyszeriek vagy időszakosak, és típusuk határozza meg őket.
Egy eseményről jelentést küld (jelentés) az eseményt közvetlenül követő csomópont az SCEF-hez (5. ábra).
Fontos pont: A megfigyelési események mind az SCEF-en keresztül csatlakoztatott nem IP-eszközökre, mind az MME-SGW-PGW-n keresztül klasszikus módon adatot továbbító IP-eszközökre egyaránt alkalmazhatók.
Nézzük meg közelebbről az egyes megfigyelési eseményeket:
Kapcsolat elvesztése — tájékoztatja az AS-t, hogy az UE már nem elérhető sem adatforgalom, sem jelzés céljára. Az esemény akkor következik be, amikor az UE „mobilelérési időzítője” lejár az MME-n. Az ilyen típusú megfigyelésre vonatkozó kérésben az AS jelezheti a „Maximális észlelési idő” értékét – ha ezalatt az UE nem mutat semmilyen tevékenységet, az AS értesítést kap arról, hogy az UE nem elérhető, megjelölve az okot. Az esemény akkor is bekövetkezik, ha az UE-t a hálózat bármilyen okból erőszakkal eltávolította.
* Annak érdekében, hogy a hálózat tudja, hogy az eszköz továbbra is elérhető, rendszeres időközönként elindít egy frissítési eljárást - Tracking Area Update (TAU). Ennek az eljárásnak a gyakoriságát a hálózat a T3412 vagy (PSM esetén T3412_extended) időzítő segítségével állítja be, melynek értéke az Attach eljárás vagy a következő TAU során kerül továbbításra az eszközre. A mobil elérhetőség időzítője általában néhány perccel hosszabb, mint a T3412. Ha az UE nem tett TAU-t a „Mobil elérhetőség időzítője” lejárta előtt, a hálózat úgy tekinti, hogy az már nem elérhető.
UE elérhetősége – Jelzi, ha az UE elérhetővé válik DL-forgalom vagy SMS-forgalom számára. Ez akkor fordul elő, amikor az UE elérhetővé válik a személyhíváshoz (az UE esetében eDRX módban), vagy amikor az UE ECM-CONNECTED módba lép (PSM vagy eDRX módban lévő UE esetén), pl. TAU-t készít vagy uplink csomagot küld.
Helyjelentés – Az ilyen típusú megfigyelési események lehetővé teszik az AS számára, hogy lekérdezze az UE helyét. Akár az aktuális hely (Current Location), akár az utolsó ismert hely (Az a cellaazonosító határozza meg, amelyről az eszköz utoljára TAU-t intézett vagy forgalmat továbbított) kérhető, ami a PSM vagy eDRX energiatakarékos módban lévő eszközökre vonatkozik. A „Jelenlegi hely” esetén az AS kérhet ismételt választ, és az MME tájékoztatja az AS-t minden alkalommal, amikor az eszköz helye megváltozik.
Az IMSI-IMEI társulás megváltozása – Amikor ez az esemény aktiválva van, az SCEF elkezdi figyelni az IMSI (SIM-kártya azonosítója) és az IMEI (eszközazonosító) kombinációjában bekövetkezett változásokat. Ha esemény történik, értesíti az AS-t. Használható külső azonosító automatikus újrakötésére az eszközhöz ütemezett cseremunka során, vagy azonosítóként szolgálhat egy eszköz ellopása esetén.
Barangolás állapota – ezt a fajta megfigyelést az AS használja annak meghatározására, hogy az UE az otthoni hálózatban vagy egy roamingpartner hálózatában van-e. Opcionálisan továbbítható annak a szolgáltatónak a PLMN-je (Public Land Mobile Network), amelyben az eszköz regisztrálva van.
Kommunikációs hiba — Ez a fajta megfigyelés tájékoztatja az AS-t az eszközzel való kommunikáció meghibásodásáról, a rádió-hozzáférési hálózattól kapott kapcsolatkimaradás okai (kioldási okkód) alapján (S1-AP protokoll). Ez az esemény segíthet annak meghatározásában, hogy miért nem sikerült a kommunikáció – a hálózaton fellépő problémák miatt, például ha az eNodeb túlterhelt (nem állnak rendelkezésre rádióerőforrások), vagy magának az eszköznek a meghibásodása (megszakadt a rádiókapcsolat az UE-vel).
Elérhetőség DDN hiba után – ez az esemény tájékoztatja az AS-t, hogy az eszköz kommunikációs hiba után elérhetővé vált. Akkor használható, ha adatátvitelre van szükség egy eszközre, de az előző próbálkozás nem volt sikeres, mert az UE nem válaszolt a hálózatról érkező értesítésre (lapozás), és az adatok nem kerültek kézbesítésre. Ha ilyen típusú megfigyelést kértek az UE-hez, akkor amint az eszköz bejövő kommunikációt kezdeményez, TAU-t hoz létre vagy adatokat küld a felfelé irányuló kapcsolatra, az AS értesítést kap arról, hogy az eszköz elérhetővé vált. Mivel a DDN (downlink data notification) eljárás az MME és az S/P-GW között működik, ez a fajta figyelés csak IP-eszközökön érhető el.
PDN kapcsolat állapota – értesíti az AS-t, ha az eszköz állapota megváltozik (PDN csatlakozási állapot) - csatlakozás (PDN aktiválás) vagy leválasztás (PDN törlés). Ezt felhasználhatja az AS arra, hogy kommunikációt kezdeményezzen az UE-vel, vagy fordítva, hogy megértse, hogy a kommunikáció már nem lehetséges. Ez a fajta megfigyelés elérhető IP és nem IP-eszközökhöz.
Egy földrajzi területen jelen lévő UE-k száma – Ezt a fajta megfigyelést az AS az UE-k számának meghatározására használja egy adott földrajzi területen.
Eszköz kioldása)
A 2G/3G hálózatokban a regisztrációs eljárás a hálózatban kétlépcsős volt: először az SGSN-hez regisztrált eszköz (csatolási eljárás), majd szükség esetén aktiválta a PDP kontextust - kapcsolatot a csomagátjáróval (GGSN) adatok továbbítására. A 3G hálózatokban ez a két eljárás egymás után következett be, azaz. az eszköz nem várta meg azt a pillanatot, amikor adatátvitelre van szüksége, hanem a csatolási eljárás befejezése után azonnal aktiválta a PDP-t. Az LTE-ben ezt a két eljárást egyesítették, vagyis csatlakoztatáskor az eszköz azonnal kérte a PDN kapcsolat aktiválását (a PDP-vel analóg 2G/3G-ben) az eNodeB-n keresztül az MME-SGW-PGW-hez.
Az NB-IoT a csatlakozási módot „PDN nélküli csatolásként” határozza meg, vagyis az UE PDN-kapcsolat létrehozása nélkül csatlakozik. Ebben az esetben nem áll rendelkezésre forgalom továbbítására, és csak SMS-t tud fogadni vagy küldeni. Annak érdekében, hogy parancsot küldjön egy ilyen eszköznek a PDN aktiválására és az AS-hez való csatlakozásra, az „Eszköz triggerelése” funkciót fejlesztették ki.
Amikor egy ilyen UE csatlakoztatására vonatkozó parancsot kap az AS-től, az SCEF vezérlő SMS küldését kezdeményezi az eszköznek az SMS-központon keresztül. SMS fogadásakor a készülék aktiválja a PDN-t, és csatlakozik az AS-hez további utasítások fogadása vagy adatátvitel céljából.
Előfordulhat, hogy eszköze előfizetése lejár az SCEF-en. Igen, az előfizetés saját élettartammal rendelkezik, amelyet az üzemeltető állít be, vagy az AS-vel egyeztetett. A lejárat után a PDN deaktiválódik az MME-n, és az eszköz elérhetetlenné válik az AS számára. Ebben az esetben a „Device triggering” funkció is segít. Amikor új adatokat kap az AS-től, az SCEF megtudja az eszköz csatlakozási állapotát, és SMS-csatornán keresztül továbbítja az adatokat.
Következtetés
Az SCEF funkcionalitása természetesen nem korlátozódik a fent leírt szolgáltatásokra, folyamatosan fejlődik és bővül. Jelenleg már több mint egy tucat szolgáltatást szabványosítottak az SCEF számára. Most csak a fejlesztők által igényelt fő funkciókat érintettük, a többiről a jövőbeni cikkekben fogunk beszélni.
Azonnal felmerül a kérdés: hogyan lehet teszt-hozzáférést kapni ehhez a „csoda” csomóponthoz az előzetes teszteléshez és a lehetséges esetek hibakereséséhez? Minden nagyon egyszerű. Bármely fejlesztő benyújthat kérelmet [e-mail védett], amelyben elegendő a kapcsolat céljának feltüntetése, egy esetleges eset leírása és elérhetőségei a kommunikációhoz.
A következő alkalomig!
Szerzők:
- Szergej Novikov a konvergens megoldások és multimédiás szolgáltatások osztályának vezető szakértője ,
- Alexey Lapshin a konvergens megoldások és multimédiás szolgáltatások osztályának szakértője
Forrás: will.com