У артыкуле «», Распавядаючы пра архітэктуру пакетнага ядра сеткі NB-IoT, мы згадалі пра з'яўленне новага вузла SCEF. Тлумачым у трэцяй частцы, што ж гэта такое і навошта гэта патрэбна?
Пры стварэнні M2M-сэрвісу распрацоўшчыкі прыкладанняў сутыкаюцца з наступнымі пытаннямі:
- як ідэнтыфікаваць прылады;
- які выкарыстоўваць алгарытм праверкі і пацверджання сапраўднасці;
- які абраць транспартны пратакол для ўзаемадзеяння з прыладамі;
- як гарантавана даставіць дадзеныя на прылады;
- як арганізаваць і ўсталяваць правілы абмену дадзенымі з імі;
- як кантраляваць і ў анлайн рэжыме атрымаць інфармацыю аб іх стане;
- як адначасова даставіць дадзеныя на групу сваіх прылад;
- як адначасова адправіць дадзеныя з адной прылады на некалькі кліентаў;
- як атрымаць уніфікаваны доступ да дадатковых сэрвісаў аператара па кіраванні сваёй прыладай.
Для іх вырашэння даводзіцца ствараць прапрыетарныя тэхнічна "цяжкія" рашэнні, што прыводзіць да павелічэння працавыдаткаў і часу time-to-market сэрвісаў. Вось тут на дапамогу і прыходзіць новы вузел SCEF.
Паводле азначэння 3GPP, SCEF (service capability exposure function) – гэта зусім новы кампанент архітэктуры 3GPP, функцыяй якога з'яўляецца бяспечнае экспанаванне сэрвісаў і магчымасцяў, якія прадстаўляюцца сеткавымі інтэрфейсамі 3GPP пасродкам API.
Простымі словамі SCEF – гэта пасярэднік паміж сеткай і серверам прыкладанняў (application server – AS), адзінае акно доступу да сэрвісаў аператара па кіраванні сваёй M2M-прыладай у сетцы NB-IoT пасродкам інтуітыўна зразумелага стандартызаванага API-інтэрфейсу.
SCEF хавае складанасць сеткі аператара, дазваляючы распрацоўнікам прыкладанняў абстрагавацца ад складаных, спецыфічных механізмаў узаемадзеяння з прыладамі.
За кошт пераўтварэння сеткавых пратаколаў у звыклы для распрацоўшчыкаў прыкладанняў API-інтэрфейс SCEF палягчае стварэнне новых паслуг і памяншае time-to-market. Таксама новы вузел уключае ў сябе функцыі ідэнтыфікацыі/аўтэнтыфікацыі мабільных прылад, азначэнні правіл абмену дадзенымі паміж прыладай і AS, здымаючы з распрацоўнікаў прыкладанняў неабходнасць рэалізацыі гэтых функцый на сваім боку, пераклаўшы дадзеныя функцыі на плечы аператара.
SCEF замыкае на сабе інтэрфейсы, неабходныя для аўтэнтыфікацыі і аўтарызацыі сервераў прыкладанняў, падтрыманні мабільнасці UE, перадачы дадзеных і трыгерынгу прылад, доступу да дадатковых сэрвісаў і магчымасцям сеткі аператара.
У бок AS ідзе адзін адзіны інтэрфейс T8, API-інтэрфейс (HTTP/JSON), стандартызаваны 3GPP. Усе інтэрфейсы, за выключэннем T8, працуюць на базе пратаколу DIAMETER (мал. 1).
T6a - інтэрфейс паміж SCEF і MME. Выкарыстоўваецца для працэдур Mobility / Session management, перадачы non-IP дадзеных, правіжынінгу падзей маніторынгу і атрыманняў справаздач па іх.
S6t - інтэрфейс паміж SCEF і HSS. Неабходны для аўтэнтыфікацыі абанента, аўтарызацыі сервераў дадаткаў, атрымання звязкі external ID і IMSI/MSISDN, правіжынінгу падзей маніторынгу і атрымання справаздач па іх.
S6m/T4 – інтэрфейсы ад SCEF да HSS і SMS-C (у 3GPP вызначаны вузел MTC-IWF, які выкарыстоўваецца для трыгерынгу прылад і перадачы SMS у сетках NB-IoT. Аднак ва ўсіх рэалізацыях функцыянал гэтага вузла інтэграваны ў SCEF, так што для спрашчэння схемы мы не будзем разглядаць яго асобна). Выкарыстоўваюцца для атрымання маршрутнай інфармацыі для адпраўкі SMS і ўзаемадзеяння з SMS-цэнтрам.
T8 - API-інтэрфейс ўзаемадзеяння SCEF з серверамі прыкладанняў. Праз гэты інтэрфейс перадаюцца як кіравальныя каманды, так і трафік.
*у рэчаіснасці інтэрфейсаў больш, тут пералічаны толькі самыя асноўныя. Поўны пералік прыведзены ў 3GPP 23.682 (4.3.2 List of Reference Points).
Ніжэй прыведзены ключавыя функцыі і сэрвісы SCEF:
- прывязка ідэнтыфікатара сім-карты (IMSI) да external ID;
- перадача non-IP трафіку (Non-IP Data Delivery, NIDD);
- групавыя аперацыі, з выкарыстаннем external group ID;
- падтрымка рэжыму перадачы даных з пацвярджэннем;
- буферызацыя MO (Mobile Originated) і MT (Mobile Terminated) дадзеных;
- аўтэнтыфікацыя і аўтарызацыя прылад і сервераў прыкладанняў;
- адначасовае выкарыстанне дадзеных аднаго UE некалькімі AS;
- падтрымка спецыяльных функцый кантролю стану UE (MONTE - Monitoring Events);
- трыгерынг прылад;
- забеспячэнне роўмінгу non-IP дадзеных.
Асноўны прынцып узаемадзеяння AS і SCEF пабудаваны на схеме т.зв. падпісак. Пры неабходнасці атрымання доступу да якога-небудзь сэрвісу SCEF для вызначанага UE, серверу прыкладанняў патрабуецца стварыць падпіску, шляхам адпраўкі каманды на пэўны API запытанага сэрвісу і ў адказ атрымаць унікальны ідэнтыфікатар. Пасля чаго ўсе далейшыя дзеянні і камунікацыі з UE у рамках дадзенага сэрвісу будуць праходзіць з выкарыстаннем дадзенага ідэнтыфікатара.
External ID: універсальны ідэнтыфікатар прылады
Адным з найважных змен у схеме ўзаемадзеяння AS з прыладамі пры працы праз SCEF з'яўляецца з'яўленне ўніверсальнага ідэнтыфікатара. Цяпер замест тэлефоннага нумара (MSISDN) або IP адраса, як гэта было ў класічнай сетцы 2G/3G/LTE, ідэнтыфікатарам прылады для сервера прыкладанняў становіцца "external ID". Ён вызначаны стандартам у звыклым для распрацоўшчыкаў дадаткаў фармаце «@».
Распрацоўнікам больш няма патрэбы рэалізоўваць алгарытмы аўтэнтыфікацыі прылад, сетка цалкам бярэ гэтую функцыю на сябе. External ID прывязваецца да IMSI, і распрацоўшчык можа быць упэўнены, што звяртаючыся да канкрэтнага external ID, ён узаемадзейнічае з канкрэтнай сім-картай. Пры выкарыстанні сім-чыпа атрымліваецца наогул унікальная сітуацыя, калі external ID адназначна ідэнтыфікуе пэўную прыладу!
Больш за тое, да аднаго IMSI можна прывязаць некалькі external ID – атрымліваецца яшчэ цікавейшая сітуацыя, калі external ID адназначна ідэнтыфікуе канкрэтнае прыкладанне, якое адказвае за пэўны сэрвіс на канкрэтнай прыладзе.
Таксама з'яўляецца групавы ідэнтыфікатар - external group ID, які ўключае ў сябе набор асобных external ID. Зараз адным запытам да SCEF AS можа ініцыяваць групавыя аперацыі - адпраўку дадзеных або каманд кіравання мноству прылад, аб'яднаных у адзіную лагічную групу.
Па чынніку таго, што для распрацоўнікаў AS пераход на новы ідэнтыфікатар прылады не можа быць маментальным, SCEF пакінуў магчымасць камунікацыі AS з UE праз стандартны нумар – MSISDN.
Non-IP трафіку (Non-IP Data Delivery, NIDD)
У NB-IoT, у рамках аптымізацыі механізмаў перадачы малых аб'ёмаў дадзеных, у дадатак да ўжо існым тыпам PDN, такім як IPv4, IPv6 і IPv4v6, з'явіўся яшчэ адзін тып – non-IP. У гэтым выпадку прыладзе (UE) не прысвойваецца IP-адрас, і дадзеныя перадаюцца без выкарыстання пратаколу IP. Трафік для такіх падлучэнняў можа маршрутызавацца двума спосабамі: класічным - MME -> SGW -> PGW і далей праз PtP тунэль да AS (мал. 2) або з выкарыстаннем SCEF (мал. 3).
Класічны спосаб не нясе асаблівых пераваг перад IP трафікам, за выключэннем памяншэння памеру перадаюцца пакетаў за кошт адсутнасці загалоўкаў IP. Выкарыстанне ж SCEF адчыняе цэлы шэраг новых магчымасцяў і значна спрашчае працэдуры ўзаемадзеяння з прыладамі.
Пры перадачы дадзеных праз SCEF з'яўляюцца дзве вельмі важныя перавагі перад класічным IP трафікам:
Дастаўка MT трафіку да прылады па external ID
Каб адправіць паведамленне на класічную IP-прыладу - AS павінен ведаць яго IP-адрас. Тут узнікае праблема: бо прылада пры рэгістрацыі звычайна атрымлівае "шэры" IP-адрас, з серверам прыкладанняў, які размешчаны ў інтэрнэце, яно мае зносіны праз вузел NAT, дзе ідзе трансляцыя шэрага адраса ў белы. Звязак шэрага і белага IP-адрасоў трымаецца абмежаваны час, у залежнасці ад налад NAT. У сярэднім для TCP або UDP – не больш за пяць хвілін. Гэта значыць калі на працягу 5 хвілін не было абмену дадзенымі з гэтай прыладай, звязак распадзецца, і прылада перастане быць даступным па тым белым адрасе, з якім была ініцыявана сесія з AS. Ёсць некалькі рашэнняў:
1. Выкарыстоўваць heartbeat. Аднойчы ўсталяваўшы злучэнне, прылада павінна абменьвацца з AS пакетамі кожныя некалькі мінуць, не даючы тым самым зачыніцца трансляцыі на NAT. Але тут не можа быць і гаворкі пра якую-небудзь энергаэфектыўнасць.
2. Кожны раз пры неабходнасці праверыць наяўнасць пакетаў для прылады на AS - адпраўляць паведамленне ў uplink.
3. Зрабіць прыватны APN (VRF), дзе сервер прыкладанняў і прылады будуць знаходзіцца ў адной падсеткі, і прызначыць на прылады статычныя IP-адрасы. Працаваць будзе, але гэта амаль нерэальна, калі гаворка ідзе пра парк з тысяч, дзясяткаў тысяч прылад.
4. Нарэшце, найболей падыходны варыянт: выкарыстоўваць IPv6, для яго не патрэбен NAT, бо IPv6 адрасы даступныя з інтэрнэту напроста. Аднак нават у гэтым выпадку пры перарэгістрацыі прылады, яно атрымае новы IPv6 адрас і ўжо не будзе даступна па папярэднім.
Адпаведна неабходна адпраўляць нейкі які ініцыялізуе пакет з ідэнтыфікатарам прылады на сервер, каб паведаміць новы IP-адрас девайса. Потым чакаць які пацвярджае пакета ад AS, што таксама ўплывае на энергаэфектыўнасць.
Гэтыя спосабы добра працуюць для 2G/3G/LTE дэвайсаў, дзе да прылады не прад'яўляецца цвёрдых патрабаванняў у аўтаномнасці і, як следства, няма абмежаванняў па часе ў эфіры і трафіку. Для NB-IoT гэтыя спосабы не падыходзяць на ўвазе іх вялікай энергазатратнасці.
SCEF вырашае гэтую праблему: бо адзіным ідэнтыфікатарам прылады для AS з'яўляецца external ID, AS досыць адправіць пакет дадзеных на SCEF для пэўнага external ID, пра ўсё астатняе паклапоціцца SCEF. У выпадку, калі прылада знаходзіцца ў рэжыме энергазберажэння PSM або eDRX, дадзеныя будуць буферызаваны і дастаўлены, калі прылада стане даступна. Калі ж прылада даступна для трафіку, дадзеныя будуць дастаўлены неадкладна. Гэта ж справядліва і для каманд кіравання.
У любы момант AS можа адклікаць буфезіраванае паведамленне ў бок UE або замяніць на новае.
Механізм буферызацыі таксама можа прымяняцца і пры перадачы MO-дадзеных ад UE у бок AS. Калі SCEF не змог даставіць дадзеныя да AS адразу, напрыклад, калі вядуцца сэрвісныя працы на серверах AS, гэтыя пакеты будуць буферызаваны і гарантавана дастаўлены, як толькі AS стане даступны.
Як было адзначана вышэй, доступ да вызначанага сэрвісу і UE для AS (а NIDD - гэта сэрвіс), рэгламентуецца правіламі і палітыкамі на баку SCEF, што дазваляе рэалізаваць унікальную магчымасць адначасовага выкарыстання дадзеных аднаго UE некалькімі AS. Г.зн. калі некалькі AS падпісаліся на адно UE, то пасля атрымання дадзеных ад UE, SCEF разашле іх на ўсе якія падпісаліся AS. Гэта добра падыходзіць для кейсаў, калі стваральнік парку спецыялізаваных прылад мацае дадзеныя паміж некалькімі кліентамі. Напрыклад, стварыўшы сетку метэастанцый, якія працуюць на NB-IoT, можна прадаваць дадзеныя з іх шматлікім сэрвісам адначасова.
Механізм гарантаванай дастаўкі паведамленняў
Reliable Data Service – механізм гарантаванай дастаўкі MO і MT паведамленняў без выкарыстання спецыялізаваных алгарытмаў на пратакольным узроўні, такіх, як, напрыклад, handshake у TCP. Працуе за кошт уключэння спецыяльнага флага ў службовую частку паведамлення пры абмене паміж UE і SCEF. Актываваць ці не актываваць дадзены механізм пры перадачы трафіку - вырашае AS.
Калі механізм актываваны, UE пры неабходнасці гарантаванай дастаўкі MO трафіку ўключае спецыяльны сцяг у службовую частку пакета. Пры атрыманні такога пакета SCEF адказвае UE пацверджаннем. Калі UE не атрымала пакет з пацверджаннем, пакет у бок SCEF будзе пераадпраўлены. Тое ж самае адбываецца і для MT трафіку.
Маніторынг прылад (monitoring events-MONTE)
Як гаварылася вышэй, функцыянал SCEF, апроч іншага, уключае ў сябе функцыі кантролю стану UE, т.зв. маніторынг прылад. І калі новыя ідэнтыфікатары і механізмы перадачы дадзеных - гэта аптымізацыі (хай і вельмі сур'ёзныя) ужо існых працэдур, то MONTE - гэта зусім новы функцыянал, недаступны ў сетках 2G/3G/LTE. MONTE дазваляе AS адсочваць такія параметры прылады, як статус падключэння, даступнасць для камунікацыі, месцазнаходжанне, роўмінгавы статус і г.д. Больш падрабязна пра кожнага раскажам крыху пазней.
Пры неабходнасці актываваць якую-небудзь падзею маніторынгу для прылады ці групы прылад AS падпісваецца на які адпавядае сэрвіс шляхам адпраўкі на SCEF каманды які адпавядае API MONTE, у якую ўключаюцца такія параметры, як external Id або external group ID, ідэнтыфікатар AS, тып маніторынгу, колькасць рэпартаў, якія AS хоча атрымаць. Калі AS аўтарызаваны для выканання запыту, SCEF у залежнасці ад тыпу правініць падзею на HSS або MME (мал. 4). Пры надыходзе падзеі MME або HSS генеруюць рэпарт у бок SCEF, які адпраўляе яго на AS.
Правіжынінг усіх падзей, за выключэннем "Number of UEs present in a geographic area", адбываецца праз HSS. Дзве падзеі "Change of IMSI-IMEI Association" і "Roaming Status" – адсочваюцца непасрэдна на HSS, астатнія HSS правініць на MME.
Падзеі могуць быць як разавыя, так і перыядычныя, і абумоўлены іх тыпам.
Адпраўка справаздачы аб падзеі (рэпартынг) праводзіцца вузлом, які адсочвае падзею, непасрэдна на SCEF (мал. 5).
Важны момант: падзеі маніторынгу могуць ужывацца як да non-IP дэвайсам, падлучаным праз SCEF, так і да IP-прылад, якія перадаюць дадзеныя класічным спосабам праз MME-SGW-PGW.
Давайце падрабязней разгледзім кожную з падзей маніторынгу:
Loss of connectivity - Інфармуе AS, што UE больш недаступная ні для data-трафіку, ні для сігнальнага абмену. Падзея надыходзіць, калі на MME заканчваецца "mobile reachability timer" для UE. У запыце на дадзены тып маніторынгу AS можа паказаць сваё значэнне "Maximum Detection Time" – калі на працягу гэтага часу UE не праявіць якую-небудзь актыўнасць, AS будзе праінфармаваны, што UE недаступная, з указаннем прычыны. Таксама падзея надыходзіць, калі UE па якой-небудзь прычыне быў прымусова выдалены сеткай.
* Каб сетка ведала, што прылада па-ранейшаму даступна, яно перыядычна ініцыюе працэдуру актуалізацыі – Tracking Area Update (TAU). Частата гэтай працэдуры задаецца сеткай пры дапамозе таймера T3412 ці (T3412_extended у выпадку PSM), значэнне якога перадаецца прыладзе падчас працэдуры Attach ці чарговага TAU. Mobile reachability timer звычайна на некалькі хвілін больш, чым T3412. Калі UE да заканчэння "Mobile reachability timer" не зрабіла TAU, сетка лічыць яе больш недаступнай.
UE reachability - Паказвае, калі UE становіцца даступная для DL трафіку або SMS. Гэта адбываецца, калі UE становіцца даступнай для пэйджынгу (для UE у рэжыме eDRX) або калі UE пераходзіць у рэжым ECM-CONNECTED (для UE у рэжыме PSM або eDRX), г.зн. робіць TAU ці адпраўляе uplink-пакет.
Паведамленне аб месцазнаходжанні - Дадзены выгляд маніторынгавых падзей дазваляе AS запытаць дадзеныя аб месцазнаходжанні UE. Можа быць запытана альбо бягучае месцазнаходжанне (Current Location), альбо апошняе вядомае (Last Known Location, вызначаецца па cell ID з якога прылада рабіла TAU ці перадавала трафік у апошні раз), што актуальна для прылад, змешчаных у рэжымах энергазберажэння PSM ці eDRX. Для "Current Location" AS можа запытаць паўтаральныя рэпотры, пры гэтым MME будзе інфармаваць AS кожны раз пры змене месцазнаходжання прылады.
Change of IMSI-IMEI Association – Пры актывацыі гэтай падзеі SCEF пачынае адсочваць змену звязка IMSI (ідэнтыфікатара сім-карты) і IMEI (ідэнтыфікатара прылады). Пры наступе падзеі - інфармуе AS. Можа ўжывацца для аўтаматычнай перапрывязкі external ID да прылады падчас планавых прац па замене ці служыць ідэнтыфікатарам крадзяжу прылады.
Статус роўмінгу – дадзены від маніторынгу выкарыстоўваецца AS, каб вызначыць знаходзіцца UE ў хатняй сетцы або ў сетцы роўмінгавага партнёра. Апцыянальна можа быць перададзены PLMN (Public Land Mobile Network) аператара, у якім прылада зарэгістравана.
Збой сувязі - Дадзены тып маніторынгу інфармуе AS аб збоях у камунікацыі з прыладай, грунтуючыся на прычынах абрыву злучэння (release cause code) атрыманых ад сеткі радыёдоступу (пратакол S1-AP). Гэта падзея можа дапамагчы вызначыць, па якім чынніку адбыўся збой камунікацыі – з-за праблем на сеткі, напрыклад, пры перагрузцы eNodeb (Radio resources not available) або па чынніку збою самай прылады (Radio Connection With UE Lost).
Availability after DDN Failure – дадзеная падзея інфармуе AS, што прылада стала даступна пасля збою камунікацыі. Можа выкарыстоўвацца, калі неабходна перадаць дадзеныя на прыладу, але папярэдняя спроба была не паспяховая, бо UE не адказала на натыфікацыю ад сеткі (пэйджынг), і дадзеныя не былі дастаўлены. Калі дадзены тып маніторынгу быў запытаны для UE, то як толькі прылада зробіць уваходную камунікацыю, зробіць TAU або адправіць дадзеныя ў uplink, AS будзе праінфармаваны, што прылада стала даступна. Бо працэдура DDN (downlink data notification) працуе паміж MME і S/P-GW, то дадзены выгляд маніторынгу даступны толькі для IP-дэвайсаў.
PDN Connectivity Status – інфармуе AS пры змена статуту прылады (PDN connectivity status) – падлучэнні (актывацыі PDN) або адключэнні (выдаленне PDN). Гэта можа быць выкарыстана AS для ініцыяцыі камунікацыі з UE, ці наадварот, для разумення, што камунікацыя больш не магчыма. Дадзены тып маніторынгу даступны для IP і для non-IP дэвайсаў.
Колькасць UEs у geographic area - дадзены тып маніторынгу выкарыстоўваецца AS, каб вызначыць колькасць UE у пэўнай геаграфічнай зоне.
Трыгерынг прылад (Device triggering)
У 2G/3G сетках працэдура рэгістрацыі ў сетцы была двухступеністая: спачатку прылада рэгістравалася ў SGSN (працэдура attach), потым пры неабходнасці перадаць дадзеныя актывавала PDP context – злучэнне з пакетным шлюзам (GGSN). У 3G сетках гэтыя дзве працэдуры ішлі паслядоўна, г.зн. прылада не чакала моманту, калі трэба перадаць дадзеныя, а актывавала PDP адразу па завяршэнні працэдуры attach. У LTE гэтыя дзве працэдуры былі аб'яднаны ў адну, гэта значыць пры attach прылада адразу запытвала актывацыю PDN connection (аналаг PDP у 2G/3G) праз eNodeB да MME-SGW-PGW.
У NB-IoT вызначаны такі спосаб падлучэння, як "attach without PDN", гэта значыць UE робіць attach, не ўсталёўваючы PDN-злучэнне. У гэтым выпадку яно недаступнае для перадачы трафіку, і можа толькі прымаць ці дасылаць SMS. Для таго каб перадаць на такую прыладу каманду на актывацыю PDN і падлучэнні да AS – быў распрацаваны функцыянал "Device triggering".
Пры атрыманні каманды на падлучэнне такога UE ад AS, SCEF праз SMS-цэнтр ініцыюе адпраўку кіравальнай SMS на прыладу. Пры атрыманні SMS аксэсуар актывуе PDN і падлучаецца да AS для атрымання наступных інструкцый або перадачы дадзеных.
Магчымы выпадкі, калі на SCEF скончыцца падпіска на прыладу. Так, у падпіскі ёсць свой тэрмін жыцця, усталяваны аператарам або ўзгодненыя з AS. Па яе заканчэнні на MME будзе дэактываваны PDN, і прылада стане недаступна для AS. У гэтым выпадку дапаможа таксама функцыянал "Device triggering". Пры атрыманні новых дадзеных ад AS SCEF высветліць статус падключэння прылады і даставіць даныя па SMS-канале.
Заключэнне
Функцыянал SCEF, вядома ж, не абмяжоўваецца вышэйапісанымі сэрвісам і ўвесь час эвалюцыянуе і пашыраецца. На бягучы момант для SCEF ужо стандартызаваны больш за дзесятак сэрвісаў. Цяпер мы закранулі толькі асноўныя і запатрабаваныя з боку распрацоўшчыкаў функцыі, аб астатніх мы пагаворым у будучых артыкулах.
Адразу ж узнікае пытанне, як атрымаць тэставы доступ да гэтага «цуд»-вузла для папярэдняга тэставання і адладкі магчымых кейсаў? Усё вельмі проста. Любы распрацоўшчык можа адправіць запыт на [электронная пошта абаронена], у якім дастаткова пазначыць мэта падключэння, апісанне магчымага кейса і кантактную інфармацыю для сувязі.
Да новых сустрэч!
аўтары:
- старшы эксперт аддзела канвергентных рашэнняў і мультымедыйных сэрвісаў Сяргей Новікаў ,
- эксперт аддзела канвергентных рашэнняў і мультымедыйных сэрвісаў Аляксей Лапшын
Крыніца: habr.com