NB-IoT: як він працює? Частина 3: SCEF – єдине вікно доступу до послуг оператора

У статті "NB-IoT: як він працює? Частина 2», Розповідаючи про архітектуру пакетного ядра мережі 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 девайсів.

Number of UEs present in a 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 вже стандартизовано понад десяток сервісів. Зараз ми торкнулися лише основних і затребувані з боку розробників функції, про решту ми поговоримо у майбутніх статтях.

Відразу виникає питання, як отримати тестовий доступ до цього «чудо»-вузла для попереднього тестування та налагодження можливих кейсів? Все дуже просто. Будь-який розробник може надіслати запит на [захищено електронною поштою], в якому достатньо вказати мету підключення, опис можливого кейсу та контактну інформацію для зв'язку.

До нових зустрічей!

Автори:

• старший експерт відділу конвергентних рішень та мультимедійних сервісів Сергій Новіков sanov,
• експерт відділу конвергентних рішень та мультимедійних сервісів Олексій Лапшин aslapsh

Джерело: habr.com