ТЕХНИЧЕСКИ УНИВЕРСИТЕТ - СОФИЯ ФАКУЛТЕТ ПО ТЕЛЕКОМУНИКАЦИИ

КАТЕДРА „КОМУНИКАЦИОННИ МРЕЖИ”

Проф. д-р инж. Ивайло Иванов Атанасов

ИЗСЛЕДВАНЕ НА УСЛУГИ И

ПРИЛОЖЕНИЯ В КОМУНИКАЦИИ ОТ

МАШИНЕН ТИП

Автореферат

на дисертация

за придобиване на научна степен "доктор на науките"

в професионално направление 5.3 Комуникационна и компютърна техника

по научна специалност "Комуникационни мрежи и системи"

София, 2016

Дисертационният труд е обсъден и насочен за защита на заседание на Катедрения съвет на катедра “Комуникационни мрежи” към Факултет по Телекомуникации при Технически университет – София, проведено на 13.06.2016 г. (Протокол № 10). Изследванията, представени в дисертационният труд, са проведени в катедра “Комуникационни мрежи” при Технически университет – София. Данни за дисертационния труд: Брой страници: 336 Брой фигури: 114 Брой таблици: 10 Брой литературни източници: 215 Брой публикации по темата на дисертационния труд: 34 Защитата на дисертационния труд ще се състои на 03-10.2016 г. от 13 часа в БИЦ на Технически университет – София, на открито заседание на Научното жури. Материалите по защитата са на разположение на интересуващите се в канцеларията на Факултета по Телекомуникации, блок 1, стая 1439-Б и на Интернет страницата на Технически университет – София. Автор: проф. д-р инж. Ивайло Иванов Атанасов Заглавие: ИЗСЛЕДВАНЕ НА УСЛУГИ И ПРИЛОЖЕНИЯ В

КОМУНИКАЦИИ ОТ МАШИНЕН ТИП Тираж: 30 бр. Печатна база при ТУ – София

1

I. ОБЩА ХАРАКТЕРИСТИКА НА ДИСЕРТАЦИОННИЯ ТРУД Актуалност на проблема Понятието комуникации от машинен тип (Machine-to-Machine Communications,

M2M) е широко обхватно и се използва за описание на технологии, които разрешават на свързани в мрежа устройства да обменят информация и да изпълняват действия без човешка намеса. Възможностите на този тип комуникации са разнообразни, динамични и бързо нарастващи. Те осигуряват свързаност за огромно разнообразие от различни уст-ройства и машини включително превозни средства, сензори и терминали за продажба, устройства за сигурност, устройства за здравеопазване и много други. Ежедневно обекти стават машини, които могат да бъдат адресирани, разпознавани, локализирани и управлявани през комуникационни мрежи и платформи.

Критичен елемент на бъдещите телекомуникации е използването на мрежата със свързаните към нея М2М устройства по такъв начин, че да се събират данни от тези уст-ройства, да се обработват и анализират в реално време и да се доставят на потребителите на М2М услуги. Независимо от множеството изследвания в тази област, които изнасят обработката на данни в „облака”, все още има много нерешени проблеми, свързани с анализа на данните, т.е. генерирането на информация и знание. Традиционно M2M реше-ния са били замислени и разгърнати като „вертикални” решения с цел подобряване на специфичен процес, но без оглед на това как тези решения може да бъдат интегрирани в по-широк бизнес контекст. В днешно време основният двигател за изследванията в областта на M2M услуги и приложения е осигуряване на възможност за създаване на нови услуги, а не само подобряване на оперативната ефективност и цена.

Съгласно дефиницията на ITU-T платформа на услуги е група от технологии, които се използват като основа, върху която се развиват / предоставят приложения, процеси или други технологии. Създаването на платформа обикновено е сложна и деликатна задача, и трябва да служи за различни цели, но основната цел е да се подпомогне и улесни работата на тези, които ще използват тази платформа. M2M платформите осигуряват достъп до данни от устройства и предлагат добре дефинирани софтуерни интерфейси, които са независими от мрежовата технология и могат да се използват за интегриране на информационни източници и управляващи параметри в различни приложения.

В този дисертационен труд са изследвани проблеми, свързани със създаването и предоставянето на услуги и приложения в комуникации от машинен тип.

Цел и задачи на дисертационния труд Основната цел на дисертационния труд е да се изследват съществуващи

платформи на услуги в комуникации от машинен тип и да се предложат нови модели и методи за предоставяне на общи възможности на услуги и приложения с добавена стойност.

Основната цел е декомпозирана на следните специфични подцели, за всяка от които в дисертацията са формулирани задачи:

1. Изследване на модели и методи за мениджмънт на знанието в комуникации от машинен тип, чрез които от сурови данни се извлича информация, която се преобразува в знание.

2. Изследване на модели на автономно поведение в комуникации от машинен тип, които автоматизират функциите за мениджмънт на М2М устройства.

2

3. Изследване на методи за синтезиране на възможности на услуги в комуникации от машинен тип, които могат да се поделят от различни приложения.

4. Изследване на модели и методи за управление на качеството на обслужване в ко-муникации от машинен тип, които поддържат налична мрежова функционалност за базирано на политики управление на носещи ресурси и наблюдение на използва-нето им, и таксуване.

5. Изследване на архитектури, ориентирани към услуги, в комуникации от машинен тип, които улесняват взаимодействието на приложения.

Методологична основа При изследването на услуги и приложения в комуникации от машинен тип е прило-

жен системен подход, който включва моделиране и синтезиране на абстракции. Модели-рането като формален начин за описание на система или обект, който осигурява съгла-сувано описание с определена цел, е използвано в контекста на мениджмънта на М2М устройства поради неговата сложност. Абстракцията, която скрива ненужните детайли на обект или система, излагайки само необходимите за определена цел детайли, е приложена за извличане на информация от М2М данни и трансформирането и в знание. Анотирането на семантична информация и генерирането на знание от данни, описващи физически системи, се базира на онтология, дефинираща понятия, връзки и ограничения. Абстрак-цията на суровите данни е представена като модел на физическа система, която е съобразена с контекста и трансфорира данните в информация. Моделът на услугите трансформира семантичната информация в знание чрез идентифициране на родови, многократно използваеми функции. Използвана е работна семантика за формално описание на контекстните модели чрез абстрактни крайни автомати и аксиоматична семантика за описание на знанието чрез логически аксиоми. Моделирането на услуги е представено като мениджмънт на знанието, което разрешава извеждане на заключения. Методите за моделиране на приложно знание са свързани с разбиране на контекста (средата) и автоматичното извеждане на обосновани решения на базата на приложна и контекстно обвързана информация. Моделите на автономно поведение включват управление на регистрационния статус на устройство, мениджмънт на свързаността и управление на мощността на елекрически уреди. Управляващият и управляваният обекти са моделирани като крайни автомати, които са описани с математически формализъм и са верифицирани с използване на релация нa биподобие. Приложното знание е моделирано като автономни агенти, които решават специфични за областта проблеми чрез формулиране на цел, формулиране на проблем, търсене на решение и изпълнение. При изследването на методи за синтезиране на възможности на услуги в комуникации от машинен тип е идентифицирана обща функционалност, която трябва да се поддържа, и са дефинирани операции, чрез които се осигурява достъп до общите функции. Моделирани са услуги, използващи общите функции, които са описани формално с темпорална логика. Синтезирани са модели на данни, които определят структурата на данните, обменяни между М2М приложения и други единици в М2М система. Изследвани са аспекти на разгръщането на възможностите на услуги в мрежата, като чрез използване на теорията за масово обслужване е създаден метод за оценка на натоварването на мрежов възел, който осигурява възможности на услуги, и чрез симулация са определени стойности на параметри, които да могат да се използват в споразумение за ниво на

3

обслужване между доставчик на услуги и доставчик на приложения. Анализът на автономните свойства на функциите за базирано на политики управление на носещите ресурси е основа за идентифициране на изискванията към управлението на качеството на обслужване в комуникации от машинен тип. Идентифицирани са основни функции за управление на носещите ресурси, предназначени за М2М сесии, като е оценена поддържаната функционалност на дефинирани услуги и са синтезирани функционални разширения. Моделите на услуги са описани и верифицирани по формален начин. Изследването на архитектури, ориентирани към услуги, в комуникации от машинен тип обхваща методи за дефиниране на уеб услуги, включващи модели на състоянията, приложни програмни интерфейси и модели на данни.

Структура на дисертационния труд Дисертационният труд включва увод, шест глави, заключение, списък на авторски

публикации, терминология, използвана в областта, списък на използваната литература, списък на съкращенията.

Публикуване на резултатите от дисертационното изследване Изследванията в дисертационния труд са публикувани в 34 статии и доклади. От тях

20 са в рецензирани списания, 11 са самостоятелни трудове, като статиите в между-народни списания от клас А са 8 на брой.

II. СЪДЪРЖАНИЕ НА ДИСЕРТАЦИОННИЯ ТРУД

Първа глава Системен подход при предоставяне на услуги и приложения в

комуникации от машинен тип

В първа глава са изследвани особеностите на предоставяне на услуги и приложения в комуникации от машинен тип. Стъпвайки на последните стандарти на водещите стандартизиращи организации за телекомуникационни мрежи, както и на научните изследвания в областта, е използван системно-базиран подход за анализ на информационните и телекомуникационни технологии за М2М услуги. Фокусът е върху М2М платформи на услуги и М2М данни, информация и знание. Анализирани са ключовите аспекти на услугите и приложенията с акцент върху моделирането, осигуря-ването и мениджмънта, налагащи използване на облачни технологии и ориентирани към услуги архитектури, и върху събирането, съхранението и анализа на данни, които изискват извличане на информация и преобразуването й в знание. Прегледът на научните изследвания в областта води до изводи, които очертават насоките на изследванията и позволяват формулиране на основните цели и задачи на дисертационния труд.

Втора глава

Изследване на модели и методи за мениджмънт на знанието в комуникации от машинен тип

2.1 Семантични модели за енергиен мениджмънт Във втора глава е представено изследване на методи за моделиране на семантична

информация и генериране на знание от данни, описващи физически системи. В авторски

4

публикации [A1] и [A2] е представен метод за анотиране на семантика, който разрешава преобразуване на IoT данни в информация и впоследствие в знание. Абстракцията на данните от сензори и въздействащи механизми се представя като модел на физическа система, съставена от „неща”, които могат да бъдат наблюдавани и на които може да се въздейства, като се следва разписание в контекста на специфична област. Контекстно свързаният модел указва начина, по който данните може да се трансформират в информация, която по-нататък се използва за анотиране на абстракция от по-високо ниво, представена като модел на услуги. Моделът на услугите прави трансформация на семантичната информация в знание чрез дефиниране на родови многократно използваеми функции. Тази родова функционалност е достъпна за различни приложения чрез приложни програмни интерфейси (Application Programming Interfaces – APIs). Фиг.2.1 илюстрира идеята на метода за моделиране на семантична информация1.

Service model(generic service capabilities)

Context-aware model(observations, actuations and time-schedules)

Physical system model(components equipped with sensors and actuator)

IoT application

IoT application

IoT application

Abstracting functions

Exposing views

Provisioning information

Фиг.2.1 Метод за синтезиране на семантична информация и знание от IoT данни

Методът е илюстриран за IoT система за енергиен мениджмънт в домашна и офис

среда. Например физическата система може да бъде дом, съставен от помещения с инсталирани уреди и устройства като климатици, бойлери и вентилационна система. Процесите във физическата система са свързани с управление на отоплението или охлаждането. При прилагане на схема за енергоспестяване, механизмът за регулиране на мощността на интелигентни уреди намалява (при зимни дни) или увеличава (в летните дни) предпочитана (еталонна) температура (Tref) от обитаващите къщата с няколко градуса (Δ) за определен период и след това възстановява предпочитаната температура. Спестяването на енергия става за сметка на комфорта през периода на управление на мощността. С използване на онтология за електрически уреди и помещения е моделирана 1 С цел консистентност номерацията на фигурите, таблиците и формулите в автореферата е последователна и се различава от тази в дисертацията.

5

физическа система за енергиен мениджмънт, която добавя понятия, връзки и ограничения за разписания, прилагащи управление на мощността. С приложената онтология моделът на физическата система се състои от неща, представящи подсистеми, които се асоциират с тип, редица атрибути и операции, което позволява да се изрази чрез UML диаграма, показана на фиг.2.2

Фиг.2.2 UML клас диаграма на понятия и връзки за модела на физическа система за

енергиен мениджмънт

6

2.2 Контекстно свързани модели

Математическият формализъм, който се използва за описание на контекстно зависимите модели, е дескриптивна логика. Терминологичната част на базата знания (TBox) съдържа основни понятия, свързани с типове уреди и техни характеристики, и роли, връзки между тях, изразени с твърдения от следния тип: ControllableAppliance⊑AutonomousAppliance⊓Has.PermanentUsage⊓ (∃Has.Unpowered⊔∃Has.On⊔∃Has.Standby) (2.1) което изразява, че управляван уред е автономен уред, с постоянно използване и състояния Unpowered, On и Standby. Heater⊑ControllableAppliance ⊓∃Does.Heating (2.2) което изразява, че уредът за отопление е управляем уред, който преобразува енергията в топлина.

Управляем уред, който се използва за отопление, може да бъде в едно от следните състояния: HeatingToRef (нагряващата система е включена, докато помещението се загрее до еталонна / предпочитана температура); HeatSteadyRef (поддържане на еталонна темпе-ратура при отопление); CoolingToDelta (нагряващата система е изключена, докато помещението не се охлади до по-ниска температура – икономичен режим); HeatSteadyReduced (поддържане на по-ниска температура при охлаждане); ReheatToRef (нагряващата система е включена, докато помещението се загрее отново до еталонната температура).

TBox съдържа и твърдения за състоянията и преходите на автономен електрически уред, използван за отопление. Standby⊑∃heatToRef.HeatingToRef (2.3) HeatingToRef⊑∃refHeatTempReached.HeatSteadyRef (2.4) HeatSteadyRef⊑∃coolDelta.CoolingToDelta (2.5) CoolingToDelta⊑∃lowerTempReached.HeatSteadyReduced (2.6) HeatSteadyReduced⊑∃reheat.ReHeatingToRef (2.7) ReHeatingToRef⊑∃refHeatTempReached.HeatSteadyRef (2.8) HeatingToRef⊑∃switchOff.Standby (2.9) HeatSteadyRef⊑∃switchOff.Standby (2.10) CoolingToDelta⊑∃switchOff.Standby (2.11) HeatSteadyReduced⊑∃switchOff.Standby (2.12) ReHeatingToRef⊑∃switchOff.Standby (2.13)

Използва се означение HSET за множество от всички загряващи уреди и означение HSTATES за състоянията si на загряващ уред. Частта с твърдения съдържа следните твърдения, където s0 означава началното състояние на всеки уред, използван за отопление. s0: ⊓h∈HSET (Unpowered), (2.14) което изразява, че началното състояние на всеки уред е незахранен.

7

За да се изрази фактът, че всеки уред, използван за отопление, е точно в едно състояние в даден момент от време, се въвежда твърдението: ⊤⊑¬(⊔s1,s2∈HSTATES, s1≠s2(s1⊓s2))⊓(⊔s2∈HSTATES s) (2.15)

Състоянията на всеки уред, използван за отопление, се сменят само чрез действия, дефинирани като действия-функции. Едно действие-функция за дадено състояние съответства на преходите в HSTATE. За управление на отоплението се използват следните действия-функции: Func(Unpowered) = {powerOn} (2.16) Func (Standby) = {powerOff}∪{heatToRef} (2.17) Func (HeatingToRef) = {switchOff}∪{refHeatTempReached} (2.18) Func (HeatSteadyRef) = {switchOff}∪{coolDelta} (2.19) Func (CoolingToDelta) = {switchOff}∪{lowerTempReached} (2.20) Func (HeatSteadyReduced) = {switchOff}∪{reheat} (2.21) Func (ReheatingToRef) = {switchOff}∪{refHeatTempReached} (2.22)

Фактът, че всеки уред за отопление може да сменя състоянието си само с прилагане на определени действия, се представя със следното твърдение: ∀s∈HSTATES, ∀R∉Func(s), s⊑∀R.s (2.23) По подобен начин в труда са въведени понятия, роли и твърдения за връзки между тях за помещение с прозорци и врати, в което има управляем уред за отопление. Контекстно свързаните модели на управляеми електрически уреди са представени в авторска публи-кация [A3].

2.3 Модели на услуги за енергиен мениджмънт Услуги се моделират чрез детайлизиране на описанието на поведението. Детайлизи-

рането се формализира като операция δF, за дадено свойство F, която трансформира дадена база знания K в друга база знания δF(K). Новата база знания представлява разширение чрез множество от активиращи функции, които се представят чрез AF ⊆ { Fu | u ∈ HSET } (2.24)

Използва се контекст C[φ], за да се дефинира детайлизирано поведение в базата знания, където φ е формула-аргумент на коя да е формула. В авторска публикация [A4] е представен базиран на знание модел на услуга за управление на отоплението.

Услугата Heating Control Service (HCS) прилага управление на отоплението в помещение с управляем отоплителен уред. Ако в помещението има отворен прозорец или врата, не се прилага управление на отоплението. При отваряне на врата или прозорец отоплителният уред се изключва. Твърденията, с които се детайлизира модела на услугата HCS, са дефинирани с уравнения от (2.25) до (2.46). C1[¬HCSH⊓StandbyH⊓(WOpenH⊔DOpenH)]⊑∃heatToRef.C2[HeatingToRefH], (2.25) което изразява, че ако услугата HCS не е активна, при отворен прозорец или врата отоп-лителният уред в състояние Standby може да бъде инструктиран да отоплява и той започ-ва да отоплява. C1[HCSH⊓StandbyH⊓(WOpenH⊔DOpenH]⊑∃heatToRef. C2[StandbyH], (2.26)

8

което изразява, че ако услугата HCS е активна, при отворен прозорец или врата отопли-телният уред в състояние Standby може да бъде инструктиран да отоплява, но той не започва да отоплява. C3[¬HCSH⊓HeatingToRefH⊓DClosedH]⊑∃openDoor.C4[DOpenH] (2.27) което изразява, че ако услугата HCS не е активна, уредът отоплява и има затворена врата, тя може да се отвори и отоплението продължава. C3[¬HCSH⊓HeatingToRefH⊓WClosedH]⊑∃openWindow.C4[WOpenH] (2.28) което изразява, че ако услугата HCS не е активна, уредът отоплява и има затворен прозорец, той може да се отвори и отоплението продължава. C3[HCSH⊓HeatingToRefH⊓DClosedH]⊑∃openDoor.C4[DOpen H]⊓ ∃switchOff.C4[StandbyH] (2.29) което изразява, че ако услугата HCS е активна, уредът отоплява при затворена врата, тя може да бъде отворена, отоплението спира. C3[HCSH⊓HeatingToRefH⊓WClosedH]⊑∃openWindow.C4[WOpenH] ⊓∃switchOff.C4[StandbyH] (2.30) което изразява, че ако услугата HCS е активна, уредът отоплява и има затворен прозорец, той може да се отвори и отоплението спира. C5[¬HCSH⊓HeatSteadyRefH⊓DClosedH]⊑∃openDoor.C6[DOpenH] (2.31) което изразява, че ако услугата HCS не е активна, уредът поддържа еталонната темпера-тура и има затворена врата и тя се отвори, поддържането на еталонната температура про-дължава. C5[¬HCSH⊓HeatSteadyRefH⊓WClosedH]⊑∃openWindow.C6[WOpenH] (2.32) което изразява, че ако услугата HCS е не активна, уредът поддържа еталонната темпера-тура и има затворен прозорец и той се отвори, поддържането на еталонната температура продължава. C5[HCSH⊓HeatSteadyRefH⊓DClosedH]⊑∃openDoor.C6[DOpenH]⊓ ∃switchOff.C6[StandbyH] (2.33) което изразява, че ако услугата HCS е активна, уредът поддържа еталонната температура и има затворена врата и тя се отвори, уредът се изключва. C5[HCSH⊓HeatSteadyRefH⊓WClosedH]⊑∃openWindow.C6[WOpenH]⊓ ∃switchOff.C6[StandbyH] (2.34) което изразява, че ако услугата HCS е активна, уредът поддържа еталонната температура и има затворен прозорец и той се отвори, уредът се изключва. C7[¬HCSH⊓CoolingToDeltaH⊓DClosedH]⊑∃openDoor.C8[DOpenH] (2.35) което изразява, че ако услугата HCS не е активна и уредът е в състояние CoolingToDelta и вратите и прозорците са затворени, може да се отвори врата. C7[¬HCSH⊓CoolingToDeltaH⊓WClosedH]⊑∃openWindow.C8[WOpenH] (2.36) което изразява, че ако услугата HCS не е активна и уредът е в състояние CoolingToDelta и вратите и прозорците са затворени, може да се отвори прозорец. C7[HCSH⊓CoolingToDeltaH⊓DClosedH]⊑∃openDoor.C8[DOpenH]⊓ ∃switchOff.C8[StandbyH] (2.37)

9

което изразява, че ако услугата HCS е активна и уредът е в състояние CoolingToDelta и вратите и прозорците са затворени, може да се отвори врата, но уредът се изключва. C7[HCSH⊓CoolingToDeltaH⊓WClosedH]⊑∃openWindow.C8[WOpenH]⊓ ∃switchOff.C8[StandbyH] (2.38) което изразява, че ако услугата HCS е активна и уредът е в състояние CoolingToDelta и вратите и прозорците са затворени, може да се отвори прозорец, но уредът се изключва. C9[¬HCSH⊓HeatSteadyReducedH⊓DClosedH]⊑∃openDoor.C10[DOpenH] (2.39) което изразява, че ако услугата HCS не е активна и се поддържа икономичен режим при затворена врата, тя може да се отвори. C9[¬HCSH⊓HeatSteadyReducedH⊓WClosedH]⊑∃openWindow.C10[WOpenH] (2.40) което изразява, че ако услугата HCS не е активна и се поддържа икономичен режим при затворен прозорец, прозорецът може да се отвори. C9[HCSH⊓HeatSteadyReducedH⊓DClosedH]⊑∃openDoor.C10[DOpenH]⊓ ∃switchOff.C10[StandbyH] (2.41) което изразява, че ако услугата HCS е активна и се поддържа икономичен режим при затворена врата, тя може да се отвори, но уредът се изключва. C9[HCSH⊓HeatSteadyReducedH⊓WClosedH]⊑∃openWindow.C10[WOpenH]⊓ ∃switchOff.C10[StandbyH] (2.42) което изразява, че ако услугата HCS е активна и се поддържа икономичен режим при затворен прозорец, прозорецът може да се отвори, но уредът се изключва. C11[¬HCSH⊓ReheatingToRefH⊓DClosed]⊑∃openDoor.C12[DOpenH] (2.43) което изразява, че ако услугата HCS не е активна и уредът загрява отново до еталонната температура при затворена врата, вратата може да се отвори. C11[¬HCSH⊓ReheatingToRefH⊓WClosedH⊓DClosedH]⊑ ∃openWindow.C12[WOpenH] (2.44) което изразява, че ако услугата HCS не е активна и уредът загрява отново до еталонната температура при затворен прозорец, прозорецът може да се отвори. C11[HCSH⊓ReheatingToRefH⊓DClosedH]⊑∃openDoor.C12[DOpenH]⊓ ∃switchOff.C12[StandbyH] (2.45) което изразява, че ако услугата HCS е активна и уредът загрява отново до еталонната температура при затворена врата, вратата може да се отвори, но уредът се изключва C11[HCSH⊓ReheatingToRefH⊓WClosedH]⊑∃openWindow.C12[WOpenH]⊓ ∃switchOff.C12[StandbyH] (2.46) което изразява, че ако услугата HCS е активна и уредът загрява отново до еталонната температура при затворен прозорец, прозорецът може да се отвори, но уредът се изключва.

В авторска публикация [А5] е представен базиран на знание модел на услуга за енергиен мениджмънт при предплатен абонамент. Услугата се базира на обобщен модел за управление на мощността на устройство, използвано за отопление или охлаждане и таксуване с предплащане.

10

Трета глава Изследване на модели на автономно поведение в

комуникации от машинен тип

3.1 Модели на регистриране на свързани устройства В авторска публикация [A6] е представен метод за формална верификация на

модели на поведение на сървър и клиент, свързани с регистриране на М2М устройство. Моделите са синтезирани на базата на OMA стандарта LWM2M. Първо са представени общи модели на регистриране, които са описани формално и проверени за съответствие с използване на релация на слабо биподобие (бисимулация). След това моделите са разширени с инициирана от сървъра дерегистрация, обновяване на версията на фърмуера и временно деактивиране на сървъра.

Регистрацията на М2М устройство позволява на сървъра да поддържа статуса на достижимост М2М устройство. Ако М2М устройството не е регистрирано, то не е достъпно. Когато М2М устройството изпрати заявка за регистриране (regreq), то очаква отговор от сървъра. След получаване на отговор на заявката с потвърждение за регистриране, устройството зарежда таймер за регистрация (Treg), отчитащ периода, през който то се разглежда за регистрирано. Ако устройството е регистрирано, то е с работна версия на фърмуера. Когато таймерът за регистрация изтече, устройството опреснява своята регистрация. Докато е регистрирано, устройството може да получи заявка за изключване, което води до иницииране на процедура по дерегистриране при сървъра. Описанието на моделите за регистриране се формализира с използване на математическия апарат на системи с именувани преходи (LTS – Labeled Transition Systems).

Чрез RS= (SS, АctS, →S, s0S) се означава LTS, представяща виждането на сървъра за

регистрационния статус на устройство, където: SS = { UnregisteredS, OperationalFwS }; ActS = { regreq, deRegreq, }; →S = { (UnregisteredS regreq OperationalFwS),

(OperationalFwS regreq OperationalFwS), (OperationalFwS deRegreq UnregisteredS)};

s0S = { UnregisteredS }. В състояние UnregisteredS устройството не е регистрирано. Устройството е

регистрирано с работна версия на фърмуера в състояние OperationalFwS. Чрез RD= (SD, АctD, →D, s0

D) се означава LTS, представяща виждането на устройството за регистрационния му статус, където:

SD = { UnregisteredD, Registering, OperationalFwD }; ActD = { Treg, regack, softOfflinereq }; →D = { (UnregisteredD Treg Registering),

(Registering regack OperationalFwD), (OperationalFwD Treg Registering), (OperationalFwD softOfflinereq UnregisteredD)};

s0D = { UnregisteredD }.

11

В състояние UnregisteredD устройството не е регистрирано. В състояние Registering устройството е в процес на регистриране. В състояние OperationalFwD устройството е регистрирано с работна версия на фърмуера.

Твърдение 1: Системите RS и RD са в релация на слабо биподобие. Доказателство 1: Идентифицира се следният хомоморфизъм hSD чрез проектиране

на действията в преходите на RS и RD: hSD(Treg)= hSD(regack), hSD(softOfflinereq)= hSD(deRegreq)

Дефинира се релация между състоянията URS={(UnregisteredD, UnregisteredS), (OperationalFwD, OperationalFwS)}. Тогава: 1. За състоянието UnregisteredD ∃ t1=( UnregisteredD Treg Registering), t2=(Registering regack

OperationalFwD) и за състоянието UnregisteredS ∃ t3=(UnregisteredS regreq OperationalFwS);

2. За състоянието OperationalFwD ∃ t4= (OperationalFwD Treg Registering), t5=(Registering regack OperationalFwD) и за състоянието OperationalFwS ∃t6=(OperationalFwS regreq OperationalFwS);

3. За състоянието OperationalFwD ∃ t7= (OperationalFwD softOfflinereq UnregisteredD), и за състоянието OperationalFwS ∃t8=(OperationalFwS deRegreq UnregisteredS). От идентифицирания хомоморфизъм hSD и релацията между преходите {(t1, t2), (t3)},

{(t4, t5), (t6)} {(t7), (t8)} в URS следва, че RS и RD са в релация на слабо биподобие. Когато устройството е регистрирано, сървърът разполага с информация колко време

е валидна неговата регистрация, транспортния режим на обвързване и поддържаните обекти от устройството.

Моделът на регистриране на М2М устройство се разширява с допълнителни процедури по обновяване на фърмуера, временно деактивиране на сървъра и опресняване на регистрацията.

Моделите на регистриране от гледна точна на М2М устройството и на сървъра се разширяват с детайлизиране в регистрационното състояние. Разширените модели се означават с RD’ и RS’.

В модела, представящ виждането на М2М устройството за неговото регистрационно състояние, състоянието, в което устройството е регистрирано с работна версия на фърмуера, се формира по следния начин: Pos(OperationalFwD)={ UpdateRegistration, FirmwareDownloadingD, WaitDereg Ack }.

В състоянието UpdateRegistration е установена асоциация с използвания транспорт и устройството очаква съобщение от сървъра за опресняване на регистрацията. В състояние WaitDeregAck устройството очаква потвърждение за дерегистриране. В състояние FirmwareDownloadingD устройството изтегля нова версия на фърмуера.

Чрез RD’= (SD’, АctD’, →D’, s0D) се означава LTS, представяща виждането на автори-

зирано устройство за неговия регистрационен статус, като: SD’ = { UnregisteredD, Registering, OperationalFwD, UpdateRegistration,

FirmwareDownloadingD, WaitDeregAck }; ActD’ = { online, Tdisable, initialRegack, reRegack, fwVersionreq, removeFwreq, updateNSreq,

TregD, bindreq, updateRegcom, disablereq, rebootreq, writeFwreq, readFwreq, updateFwreq, softOffline, deRegack };

12

→D’ = { D1τ , D

2τ , D3τ , D

4τ , D5τ , D

6τ , D7τ , D

8τ , D9τ , D

10τ , D11τ , D

12τ , D13τ , D

14τ , D15τ , D

16τ , D17τ }

s0D = { UnregisteredD }, където D

1τ = (UnregisteredD online Registering) D2τ = (UnregisteredD Tdisable Registering) D3τ = (Registering initialRegack OperationalFwD) D4τ = (Registering reRegack OperationalFwD) D5τ = (OperationalFwD fwVersionreq OperationalFwD) D6τ = (OperationalFwD removeFwreq OperationalFwD)

D7τ = (OperationalFwD updateNSreq OperationalFwD) D8τ = (OperationalFwD TregD Registering) D9τ = (OperationalFwD bindreq UpdateRegistration) D

10τ = (UpdateRegistration updateRegcom Registering) D

11τ = (OperationalFwD disablereq UnregisteredD) D

12τ = (OperationalFwD rebootreq Registering) D

13τ = (OperationalFwD writeFwreq FirmwareDownloadingD) D

14τ = (FirmwareDownloadingD readFwreq FirmwareDownloadingD) D

15τ = (FirmwareDownloadingD updateFwreq OperationalFwD) D

16τ = (OperationalFwD softOffline WaitDeregAck) D

17τ = (WaitDeregAck deRegack UnregisteredD). В модела, представящ виждането на сървъра за регистрационния статус на М2М

устройство, състоянието, в което устройството е регистрирано с работна версия на фърмуера, се разширява по следния начин: Pos(OperationalFwS)={ NotificationStoring, Disabling, UpdateBinding, WaitUpdateAck, WaitFwVersion, WaitDownloаdAck, WaitFwUpdate, FirmwareDownloadingS, WaitFwAction-Status, RemoveOldFirmware, Rebooting }.

Ако сървърът няма да бъде наличен за определено време, той може да изпрати инструкции към устройството дали да съхранява известявания към сървъра за времено на неналичност или не и в състояние NotificationStoring сървърът очаква отговор от устройството. В състояние Disabling сървърът е известил устройството, че определено време няма да бъде наличен и очаква потвърждение. Ако поради административни причини сървърът изиска от устройството да опресни регистрацията си, в състояние UpdateBinding сървърът очаква потвърждение за изменение на транспортния режим от устройството. В състояние WaitUpdateAck сървърът е изпратил команда към устройството за опресняване на регистрацията и очаква потвърждение. В състояние WaitFwVersion се влиза, когато е налична нова версия на фърмуера и в това състояние сървърът е изпратил инструкции към устройството за адреса на новата версия, очаквайки отговор. В състояние WaitDownloаdAck сървърът е наредил на устройството да започна Извличането на новата версия и очаква потвърждение. В състояние FirmwareDown-loadingS устройството извлича новата версия на фърмуера от указания адрес, като в това състояние сървърът може да изпрати няколко запитвания за статуса на извличането. В

13

състояние WaitFwActionStatus сървърът очаква отговор от устройството за статуса на извличането на новата версия. Когато устройството е извлякло новата версия, сървърът му изпраща инструкции да я активира и в състояние WaitFwUpdate очаква потвърждение. Когато новата версия е активирана, сървърът изпраща инструкции за изтриване на старата версия и в състояние RemoveOldFirmware очаква потвърждение от устройството. В състояние Rebooting сървърът е изпратил заявка към устройството да се инициализира и очаква потвърждение. При приемане на потвърждение от устройството сървърът го счита за нерегистрирано.

Чрез RS’= (SS’, АctS’, →S’, s0S) се означава LTS, представяща виждането на сървъра за

състоянието на регистрационния статус на устройство: SS’ = {UnregisteredS, OperationalFwS, UpdatetBinding, NotificationStoringS, Disabling,

WaitUpdateAck, WaitFwVersion, Rebooting FirmwareDownloadingS, WaitFwActionStatus, WaitFwUpdate, WaitDownloadAck, RemoveOldFirmware};

ActS’ = { initialRegreq, reRegreq, TregS, deRegreq, notifStoring, updateNSack, disable, fwAvailable, updateReg, disableack, bindack, updateRegack, fwVersionres, writeFWres, fwTdl, readFwres, updateFwack, removeFWack, rebootack };

→S’ ={ S1τ , S

2τ , S3τ , S

4τ , S5τ , S

6τ , S7τ , S

8τ , S9τ , S

10τ , S11τ , S

12τ , S13τ , S

14τ , S15τ , S

16τ , S17τ , S

18τ , S19τ , S

20τ , S21τ };

s0S = { UnregisteredS }, където S

1τ = (UnregisteredS initialRegreq OperationalFwS) S2τ = (UnregisteredS reRegreq OperationalFwS) S3τ = (OperationalFwS reRegreq OperationalFwS) S4τ = (OperationalFwS TregS UnregisteredS) S5τ = (OperationalFwS deRegreq UnregisteredS) S6τ = (OperationalFwS notifStoring NotificationStoringS) S7τ = (NotificationStoringS updateNSack OperationalFwS) S8τ = (OperationalFwS disable Disabling) S9τ = (OperationalFwS fwAvailable WaitFwVersion) S10τ = (OperationalFwS updateReg UpdatetBinding) S11τ = (Disabling disableack UnregisteredS) S12τ = (UpdateBinding bindack WaitUpdateAck) S13τ = (WaitUpdateAck updateRegack UnregisteredS) S14τ = (WaitFwVersion fwVersionres WaitDownloadAck) S15τ = (WaitDownloadAck writeFWres FirmwareDownloadingS) S16τ = (FirmwareDownloadingS fwTdl WaitFwActionStatus) S

17τ = (WaitFwActionStatus readFwres FirmwareDownloadingS) S18τ = (WaitFwActionStatus readFwres WaitFwUpdate) S19τ = (WaitFwUpdate updateFwack RemoveOldFirmware) S20τ = (RemoveOldFirmware removeFwack Rebooting) S21τ = (Rebooting rebootack UnregisteredS).

14

Твърдение 2: Системите RS’ и RD’ са в релация на слабо биподобие. Доказателство 2: Тъй като комуникацията между клиента и сървъра е на принципа

изпращане на заявки и команди и изпращане на отговори и потвърждения, може да се идентифицира хомоморфизъм, който обвързва съответните заявки и команди с техните отговори и потвърждения.

Дефинира се следната релация между състоянията на двете системи UR’S’ = {(UnregisteredD, UnregisteredS), (OperationalFwD, OperationalFwS)}. Тогава:

1. При начално регистриране: За UnregisteredD { D1τ , D

3τ } OperationalFwD ∃ UnregisteredS { S

1τ } OperationalFwS; 2. При повторно регистриране след временна неналичност: За UnregisteredD { D

1τ , D4τ }

OperationalFwD ∃ UnregisteredS { S1τ } OperationalFwS;

3. При дерегистриране: За OperationalFwD { D11τ , D

17τ } UnregisteredD ∃ OperationalFwS

{ S5τ }UnregisteredS;

3. При повторно регистриране поради изтичане на времето на валидност на регистрацията: За OperationalFwD { D

8τ , D4τ } OperationalFwD ∃OperationalFwS{ S

3τ , S4τ ,

S2τ }OperationalFwS;

5. При инструктиране за съхранение на известявания по време на неналичност на сървъра: За OperationalFwD { D

7τ } OperationalFwD ∃OperationalFwS { S6τ , S

7τ } OperationalFwS;

6. При изключване на сървъра: За OperationalFwD { D11τ } UnregisteredD ∃ OperationalFwS

{ S8τ , S

10τ } UnregisteredS; 7. При повторна регистрация, когато сървърът се включи: За UnregisteredD { D

2τ , D4τ }

OperationalFwD ∃ UnregisteredS { S2τ } OperationalFwS;

8. При опресняване на регистрацията, инициирано от сървъра: За OperationalFwD

{ D9τ , D

10τ , D4τ } OperationalFwD ∃OperationalFwS { S

10τ , S12τ , S

13τ , S2τ }OperationalFwS;

9. При изменение на версията на фърмуера: За OperationalFwD

{ D5τ , D

13τ , D14τ , D

15τ , D12τ , D

4τ }OperationalFwD ∃ OperationalFwS { S9τ , S

14τ , S15τ , S

16τ , S17τ , S

18τ , S19τ ,

S20τ , S

21τ , S2τ } OperationalFwS.

На базата на определената релация на биподобие между състоянията на двата модела и хомоморфизмът между заявките / командите и отговорите / потвържденията може да се направи заключение, че RS’ и RD’ са в релация на слабо биподобие, което означава, че двата модела са синхронизирани и излагат еквивалентно поведение.

Агентът е софтуерна единица, която възприема от и действа върху М2М устройство, по такъв начин, че да оптимизира работните параметри на устройството. Проблемът при самооптимизирането в М2М система включва цел и средства за постигане на целта. В М2М система една от целите може да бъде използване на най-добрия носещ ресурс от дадено устройство при няколко налични или управление на качеството на обслужване, налично за връзките на регистрирано М2М устройство. Автономен агент за мениджмънт на М2М устройства може да прави заключения и да изпълнява действия, за да постигне своята цел. Автономният агент, базиран на цел, решава даден проблем чрез определяне на

15

последователност от действия, които водят до желано състояние на М2М устройство. Действията на агента водят до изменение на състоянието на устройството.

Моделите на автономно поведение, представени в трета глава, са формално описани с линейна темпорална логика. За да се формализира обменът на съобщения между авто-номния агент (сървър) и управлявано М2М устройство (клиент) и за описание на състоя-нието на устройството от гледна точна на агента, се използват предикати.

Предикатът Authorized(x) има стойност истина, ако по време на регистриране, автен-тикацията на устройство x е успешна. Предикатът Timerreg(x) става истина, когато времето на валидност на регистрацията на устройство x свърши. Предикатът OldFwVersion(x) има стойност истина, когато устройството x използва стара версия на фърмуера. Предикатът fwAvailable става истина, когато е налична нова версия на фърмуера. Предикатът FwDownloaded(x) става истина, когато устройството x е завършило изтеглянето на новата версия на фърмуера.

За описание на действията на агента се използват функции, например функцията set(Timerreg(x)) зарежда регистрационния таймер с времето за валидност на регистрацията. Освен регистрациония таймер се използват и други таймери. Таймерът Timerdisablе отчита времето, през което сървърът няма да бъде наличен, докато таймерът Timerenablе отчита времето, през което сървърът ще бъде наличен. Таймерът maxTimerdl(x) отчита максимал-ното време за свличане на новата версия на фърмуера, докато таймерът fwTimerdl(x) отчита периода, през който сървърът прави запитване за статуса на действието по време на изтегляне на новата версия на фърмуера от устройство x.

Въведено е състояние Registered, в което се влиза след успешна регистрация на устройството и в което се прави запитване за използваната версия на фърмуера от устройството. Ако устройството използва актуална версия, се влиза в състояние OperationalFw, а в противен случай се инициира процедура по изменение на версията.

Престоят в състоянието Disabled е докато изтече времето за неналичност на сървъра: G(Disabled→⊤U (Timerdisable)) (3.1)

Когато сървърът стане наличен, таймерът Timerenable се зарежда с периода на наличност на сървъра и устройството се разглежда като нерегистрирано: G(Disabled∧Timerdisable→set(Timerenable)∧NUnregistered(x)) (3.2)

Устройството е нерегистрирано, докато не се приеме начална заявка за регистриране, повторна заявка за регистриране или изтече времето за наличност на сървъра: G(Unregistered(x)→⊤U (initialRegreq(x)∨reRegreq(x)∨Timerenable)) (3.3)

Ако устройството е нерегистрирано и се приеме начална заявка за регистриране и автентикацията на устройството е успешна, се изпраща потвърждение на началната заявка за регистриране, зарежда се регистрационният таймер, прави се запитване за използваната версия на фърмуера и устройството се счита за регистрирано: G(Unregistered(x)∧initialRegreq(x)∧Authorized(x)→initialRegack(x)∧ readFwVersionreq(x)∧set(Timerreg(x))∧NRegistered(x)) (3.4)

Ако устройството е нерегистрирано и се приеме начална заявка за регистриране и автентикацията на устройството е неуспешна, се отхвърля заявка за регистриране и устройството се счита за нерегистрирано:

16

G(Unregistered(x)∧initialRegreq(x)∧¬Authorized(x) →initialRegrej(x)∧NUnregistered(x)) (3.5) Ако устройството е нерегистрирано и се приеме заявката за регистриране и

автентикацията на устройството е успешна, се изпраща потвърждение на заявката за регистриране, зарежда се регистрационният таймер, прави се запитване за използваната версия на фърмуера и устройството се счита за регистрирано: G(Unregistered(x)∧reRegreq(x)∧Authorized(x)→reRegack(x)∧readFwVersionreq(x)∧ set(Timerreg(x))∧NRegistered(x)) (3.6)

Ако устройството е нерегистрирано и се приеме заявка за регистриране и автентикацията на устройството е неуспешна, заявката за регистриране се отхвърля и устройството се счита за нерегистрирано: G(Unregistered(x)∧reRegreq(x)→reRegrej(x)∧¬Authorized(x)∧NUnregistered(x)) (3.7)

Докато устройството не е регистрирано може да изтече времето за наличност на сървъра и в този случай се зарежда таймерът Timerdisable, отчитащ времето за неналичност на сървъра и сървърът става неналичен: G(Unregistered(x)∧Timerenable(x)→ set(Timerdisable)∧Disabled) (3.8)

Устройството е в състояние Registered докато не дойде отговор с използваната версия на фърмуера: G(Registered(x)→⊤U(readFwVersionres(x)) (3.9)

Ако устройството е регистрирано и не използва стара версия на фърмуера, се влиза в състояние OperationalFw: G(Registered(x)∧readFwVersionres(x)∧¬OldFwVersion(x)→NOperationalFw(x)) (3.10)

Ако устройството е регистрирано и използва стара версия на фърмуера, на него му се изпраща адреса, откъдето да свали новата версия и се очаква потвърждение: G(Registered(x)∧readFwVersionres(x)∧OldFwVersion(x)→fwVersionreq)∧ NWaitFwVersion(x)) (3.11)

Устройството е регистрирано с работен софтуер докато се приеме заявка за регистриране, изтече регистрационният таймер, получи се информация, че сървърър ще стане неналичен, стане налична нова версия на фърмуера, приеме се външна заявка за опресняване на регистрационния статус или изтече времето за наличност на сървъра: G(OperationalFw(x)→⊤U(reRegreq(x)∨Timerreg(x)∨disable∨fwAvailable∨ deregister∨Timerenable) (3.12)

При приемане на заявка за регистриране се прави автентикация на устройството и се връща отговор на заявката за регистриране: G(OperationalFw(x)∧reRegreq(x)∧Authorized(x)→reRegack(x)∧set(Timerreg(x))∧ NOperationalFw(x)) (3.13) G(OperationalFw(x)∧reRegreq(x)∧¬Authorized(x) →reRegrej(x)∧NUnregistered(x)) (3.14)

Ако свърши времето за наличност на сървъра или е приета информация, че сървърът ще стане неналичен, на устройството се изпращат инструкции дали да съхранява известяванията към сървъра или не, както и известяване, че сървърът няма да е наличен, нулира се регистрационният таймер, зарежда се таймерът за неналичност на сървъра и устройството се счита за нерегистрирано: G(OperationalFw(x)∧(Timerenable∨disable)→updateNSreq(x)∧NNotificationStoring(x)) (3.15)

17

G(NotificationStoring(x)→⊤U (updateNSack(x)) (3.16) G(NotificationStoring(x)∧updateNSack(x) →disablereq(x)∧NDisabling(x)) (3.17) G(Disabling(x)→⊤Udisableack(x)) (3.18) G(Disabling(x)∧disableack(x)) →reset(Timerreg(x))∧set(Timerdisable)∧ NUnregistered(x)) (3.19)

Ако устройството е било информирано, че сървърът няма да бъде наличен, в бъдещ момент (когато всички устройства бъдат информирани за неналичност на сървъра), сървърът ще стане неналичен. N-1Disabling(x) →F Disabled (3.20)

Ако докато устройството е регистрирано с работна версия на фърмуера, стане налична нова версия, устройството бива известено за адреса на новата версия: G(OperationalFw(x)∧fwAvailable→fwVersionreq(x)∧NWaitFwVersion(x)) (3.21)

Ако докато устройството е регистрирано с работна версия на фърмуера, се получи външна заявка за дерегистриране, то на устройството се изпраща заявка за изменение на транспортния режим на обвързване и команда за опресняване на регистрацията, след което се нулира регистрационният таймер и устройството се счита за нерегистрирано: G(OperationalFw(x)∨deregister→bindreq(x)∧NUpdateBinding(x)) (3.22) G(UpdateBinding(x)→⊤U(bindack(x)) (3.23) G(UpdateBinding(x)∧bindack(x) → updateRegcom(x)∧NWaitUpdateAck(x)) (3.24) G(WaitUpdateAck(x)→⊤U(updateRegack(x)) (3.25) G(WaitUpdateAck(x)∧updateRegack(x) → reset(Timerreg(x))∧NUnregistered(x)) (3.26)

При налична нова версия на фърмуера, когато дойде потвърждение от устройството за адреса на новата версия, на устройството се изпращат инструкции да започне изтеглянето на новата версия, зарежда се таймер maxTimerdl(x) с максималното време за изтегляне на версията и се извършва запитване за статуса на изтеглянето: G(WaitFwVersion(x)→⊤U(fwVersionres(x)) (3.27) G(WaitFwVersion(x)∧fwVersionres(x) → writeFwreq(x)∧ NWaitDownloadAck(x)) (3.28) G(WaitDownloadAck(x)→⊤U(writeFWres(x)) (3.29) G(WaitDownloadAck(x)∧writeFWres(x)→readDLstatusreq(x))∧ set(maxTimerdl(x))∧ NWaitFwActionStatus(x)) (3.30) G(WaitFwActionStatus(x)→⊤U(readDLstatusres(x)) (3.31)

Ако устройството не е завършило изтеглянето на новата версия на фърмуера от посочения адрес, то се зарежда таймер fwTimerdl(x) с времето за следващото запитване: G(WaitFwActionStatus(x)∧readDLstatusres(x)∧¬FwDownloaded(x)→set(fwTimerdl(x))∧ NFirmwareDownloading(x)) (3.32)

Ако устройството е завършило изтелянето на новата версия на фърмуера от посочения адрес, то се инструктира да активира новата версия, след което да изтрие старата версия и да се инициализира, а впоследствие се нулира регистрационният таймер и устройството се разглежда като нерегистрирано:

18

G(WaitFwActionStatus(x)∧readDLstatusres(x)∧FwDownloaded(x)→updateFwreq(x))∧ NWaitFwUpdate(x)) (3.33) G(WaitFwUpdate(x)→⊤U(updateFwack(x)) (3.34) G(WaitFwUpdate(x)∧updateFwack(x) → removereq(x)∧NRemoveOldFirmware(x)) (3.35) G(RemoveOldFirmware(x)→⊤U(removeack(x)) (3.36) G(RemoveOldFirmware(x)∧removeack(x) → rebootreq(x)∧NRebooting(x)) (3.37) G(Rebooting(x)→⊤U(rebootack(x)) (3.38) G(Rebooting(x)∧rebootack(x) → reset(Timerreg(x))∧NUnregistered(x)) (3.39)

Докато устройството извлича новата версия на фърмуера, може да се случи едно от следните: да се направи запитване за статуса на действието, да изтече максималното време за извличане на версията, да изтече регистрационният таймер, да изтече времето за наличност на сървъра или да се приеме информация, че сървърът ще стане неналичен, или да се приеме външна заявка за дерегистриране на устройството или заявка за регистриране от устройството: G(FirmwareDownloading(x)→⊤U(fwTimerdl(x)∨maxTimerdl(x)∨Timerreg(x)∨ Timerenable∨disable∨deregister∨reRegreq(x)) (3.40)

Ако докато устройството изтегля новата версия на фърмуера, се направи запитване за статуса на действието, устройството връща отговор: G(FirmwareDownloading(x)∧fwTimerdl(x)→readDLstatusreq(x)∧ NWaitFwActionStatus(x)) (3.41)

Ако докато устройството извлича новата версия на фърмуера, изтече регистра-ционният таймер или таймерът с максималното време за изтегляне, устройството се счита за нерегистрирано: G(FirmwareDownloading(x)∧Timerreg(x) →NUnregistered(x)) (3.42) G(FirmwareDownloading(x)∧maxTimerdl(x) →NUnregistered(x)) (3.43)

Ако докато устройството изтегля новата версия на фърмуера, изтече времето за наличност на сървъра или се приеме информация, че сървърът ще стане неналичен, устройството се информира дали да съхранява известяванията си към сървъра, докато той е неналичен: G(FirmwareDownloading(x)∧(Timerenable∨disable)→updateNSreq(x)∧ NNotificationStoring(x)) (3.44)

Ако докато устройството изтегля новата версия на фърмуера се приеме външна заявка за дерегистрирането му, то се информира за изменение на транспортния режим на обвързване: G(FirmwareDownloading(x)∧deregister→bindreq(x)∧NUpdateBinding(x)) (3.45)

Ако докато устройството сваля новата версия на фърмуера се приеме заявка за регистриране, то се прави автентикация на устройството и се връща отговор на заявката за регистриране: G(FirmwareDownloading(x)∧reRegreq(x)∧Authorized(x)→reRegack(x)∧set(Timerreg(x))∧ NFirmwareDownloading(x)) (3.46) G(FirmwareDownloading(x)∧reRegreq(x)∧¬Authorized(x)→reRegrej(x)∧

19

NUnregistered(x)) (3.47) Моделът на автономния агент, който поддържа регситрационния статус на М2М

устройства, е представен в авторска публикация [A6]. 3.2 Модели на автономен мениджмънт на свързаността на устройства Устройствата може да бъдат свързани посредством клетъчни носещи ресурси, без-

жични носители или може да използват фиксирани връзки. Сървърът може да наблюдава напрежението на линията (за фиксирани връзки) и силата на сигнала от страна на устройството. За тази цел сървърът изгражда връзка за наблюдение с устройството, за да се определя политиката на наблюдението. Устройството изпраща периодично или при наличие на определени събития доклади за исканата информация до сървъра, докато връзката за наблюдение не бъде освободена. Сървърът може да прави запитване за множество параметри на мрежата по отношение на свързаността на устройството включително използван мрежов носещ ресурс и наличните мрежови носещи ресурси. Ако например устройството има клетъчна мрежова свързаност, поддържа WLAN свързаност и е налично WLAN покритие, сървърът може да управлява използваните носещи ресурси, като инициира процедура по избор на носещ ресурс с предпочитан WLAN комуникационен ресурс. Сървърът може да създаде и активира нов профил на точка за достъп (Access Point Name – APN).

Контекстно свързаните модели за мениджмънт на свързаността на M2M устройство, са описани в авторска публикация [A7].

При моделиране на поведението на автономен агент за мениджмънт на свързаността се прави допускането, че операторът на устройствата е определил предпочитани носещи ресурси за определени области и извън тях. Във всяко устройство са конфигурирани прагови стойност на параметри, което означава, че устройството може да наблюдава теку-щите стойности на параметри и да изпраща известия при откриване на преминаването на даден праг. Агентът за мениджмънт на свързаността трябва конфигурира политика на наблюдение и да активира наблюдението. В спецификациите на OMA са дефинира стандартизирани филтри (traps), които се активират при преминаване на определени прагове. Филтърът Geographic trap се активира, когато устройството влезе в определена географска област. Всеки път, когато устройството напусне тази географска област, филтърът става неактивен. Събирането на данни от измервания (например мощността на сигнала и качество на връзката) е важно за мениджмънта на свързаността, когато устройството комуникира чрез безжичната мрежа. Филтърът Received power trap може да помогне при оптимизиране на свързаността, когато приетата от устройството мощност на сигнала падне под стойност, определена от агента. Когато мощността на сигнала при устройство падне под определена стойност (TrapActivePower), филтърът става активен. Съответно, когато мощността на сигнала, приет от устройството се увеличи над определена стойност (TrapInactivePower), филтърът става неактивен. Смяната на състоянието на филтъра води до известяване на агента от устройството. Устройството може да има няколко различни филтъра от този вид за различните мрежови носещи ресурси (например за WiFi, WCDMA, LTE и т.н.). По всяко време агентът може да прави запитвания към устройството за неговото местоположение и за параметрите му на свързаност, които включват използван мрежов носещ ресурс, налични мрежови носещи ресурси, мощност на сигнала, както и идентификации на мрежата.

20

Целта на агента за мениджмънт на свързаността е устройството да използва най-добрите мрежови носещи ресурси. Една от политиките за избор на най-добър мрежов носещ ресурс е както следва. Ако устройството е в определена област и мощността на сигнала на предпочитания носещ ресурс в областта е по-висока от определената стойност на TrapActivePower, тогава този носещ ресурс е предпочитан за областта. Когато устройството е извън определената област и мощността на сигнала на предпочитания извън областта носещ ресурс е по-висока от определената стойност на TrapActivePower, най-добрият носещ ресурс е този, който е предпочитан извън областта. Ако силата на мощността на предпочитан носител е по-ниска от определената стойност на TrapActivePower, най-добрият носещ ресурс е този с най-голяма мощност на сигнала.

Логиката на поведението на агента за мениджмънт на свързаността може да бъде описана като времева последователност. След успешна регистрация на устройство агентът конфигурира географски филтри и филтри за приета мощност. Агентът прави запитване към устройството за неговото местоположение и параметрите за свързване. Въз основа на местоположението, мощността на сигнала на използвания мрежов носещ ресурс и наличните носещи ресурси, и следвайки политиката за най-добър мрежов носещ ресурс, агентът инициира процедура за избор на носещ ресурс за устройството. След като се избере най-добрият носещ ресурс, устройството е в работно състояние. По време на това състояние устройството може да изпраща известия за филтри в случай на настъпване на съответното събитие и в резултат агентът инициира процедурата по избор на носещ ресурс.

Отново се използват предикати за изразяване на факти, описание на обмена на съобщения между устройството и агента и за описание на състоянието на устройството от гледна точка на агента. Предикатът Excellent(b, x) става истина, когато приетата мощност на сигнала на носещ ресурс b от устройство x е по-висока от стойността TrapInactivePower. Предикатът Good(b, x) става истина, когато приетата мощност на сигнала на носещ ресурс b от устройство x е между определените стойности TrapActivePower и TrapInactivePower. Ако мощността на приетия от устройството сигнал на носещ ресурс b е под определената стойност на TrapActivePower, тогава предикатът Bad(b,x) става истина. В случай, че устройството x използва носещ ресурс b, предикатът Used(b, x) е истина. Предикатът InArea(a, x) е истина, когато устройството x е в областта a. Предикатите PreferredIn(b, a) и PreferredOut(b, a) са истина, когато носещият ресурс b е предпочитан съответно в областта a и извън нея. За да се изрази факта, че носещ ресурс b е наличен за устройство x, се използва предикатът Available(b, x). Когато няма налични носещи ресурси за устройство x, предикатът AvailableEmpty(x) става истина. Предикатът BadPreferred(x) е истина, когато мощността на сигнала за предпочитания носещ ресурс от устройство x е ниска (т.е. сигналът е слаб). Предикатът Best(b, x) е истина, ако мощността на сигнала на b е най-голяма за устройство x. Предикатът PowerTrapActive(x, b) става истина, когато филтърът Received power trap стане активен и мощността на сигнала на използвания носещ ресурс b от устройство x е ниска. Предикатът PowerTrapInactive(x, b) става истина, когато филтърът Received power trap стане неактивен и мощността на сигнала на използвания носещ ресурс b от устройство x е висока (сигналът е отличен).

Таймерът Tmargin(x) се използва, за да се даде време да се стабилизира мощността на приетия сигнал при задействане на филтъра Received power trap.

21

Поведението на агент за мениджмънт на свързаността се описва с темпорална логика. Агентът следва следните твърдения при изследване на текущото състояние на устройството, формулирането на проблем, търсене на решения и изпълнение на действия.

Агентът счита устройството e x за нерегистрирано, докато се приеме заявка за регистриране. След успешна регистрация агентът конфигурира филтърa Geo trap, с който се дефинира географска област, и филтъра Received power trap за наблюдение на приетата мощност на сигнала на използвания носещ ресурс: G(Unregistered(x)→⊤U regreq(x)) (3.48) G(Unregistered(x)∧regreq(x)→regres(x)∧¬BadPreferred(x)∧configGeoTrapres(x)∧ NWaitGeoAck(x)) (3.49) G(WaitGeoAck(x)→⊤U configGeoTrapres(x)) (3.50) G(WaitGeoAck(x)∧configGeoTrapres(x)→configPowerTrapreq(x)∧NWaitPowerAck(x)) (3.51) G (WaitPowerAck(x)→⊤U configPowerTrapres(x)) (3.52)

След конфигуриране на филтрите Geo trap и Received power trap агентът прави запитване към устройството за неговото географско местоположение и параметри на свързаността: G(WaitPowerAck(x)∧configPowerTrapres(x)→getLocationreq(x)∧NWaitLocation(x)) (3.53) G(WaitLocation(x)→⊤U getLocationres(x)) (3.54) G(WaitLocation(x)∧getLocationres(x)→connParametersreq(x)∧N WaitConnectivity(x)) (3.55) G(WaitConnectivity(x)→⊤UconnParametersres(x)) (3.56)

Когато използваният носещ ресурс от x е b и b е предпочитаният носещ ресурс в областта a, и мощността на сигнала на b е отлична или добра, тогава състоянието на устройството е работно: G(WaitConnectivity(x)∧connParametersres(x)∧ InArea(a, x)∧PreferredIn(b, a)∧ Used(b, x) ∧(Excellent(b, x)∨Good(b, x))→ NOperational(x)) (3.57)

Когато използваният носещ ресурс от x е b и b е предпочитаният носещ ресурс в областта a, и мощността на сигнала на b е ниска, и c е наличен носещ ресурс за устройство x, и c е най-добрият носещ ресурс, тогава агентът инициира процедура по избор на носещ ресурс c: G(WaitConnectivity(x)∧connParametersres(x)∧InArea(a,x)∧PreferredIn(b,a)∧ Used(b,x)∧Bad(b,x)∧ Available(c, x)∧Best(c, a) → selectreq(x,c)∧ BadPreferred(x)∧NWaitBearerAck(x)) (3.58)

Агентът инициира процедура по избор на носещи ресурс c и когато c е наличен и предпочитан за областта и приетата мощност на сигнала на c от устройство x не е ниска: G(WaitConnectivity(x)∧connParametersres(x)∧ InArea(a,x)∧Used(b,x)∧ ¬PreferredIn(b,a)∧ Available(c,x)∧PreferredIn(c, a)∧¬BadPreferred(x)→ selectreq(x, c)∧NWaitBearerAck(x)) (3.59)

Когато използваният носещ ресурс от x не е предпочитаният и носещият ресурс c е наличен и предпочитан за областта a, и приетата мощност на сигнала на c от устройство x е ниска, и носещият ресурс d е най-добрият наличен, тогава агентът инициира процедура по избор на носещ ресурс d:

22

G(WaitConnectivity(x)∧connParametersres(x)∧ InArea(a, x)∧ Used(b,x)∧¬PreferredIn(b,a)∧Available(c,x) ∧PreferredIn(c,a)∧BadPreferred(x)∧ Best(d,a)∧ Available(d,x) → selectreq(x,d)∧NWaitBearerAck(x)) (3.60)

Когато използваният носещ ресурс b от устройство x е предпочитаният извън областта и мощността на приетия сигнал от b е отлична или добра, устройството е в работно състояние: G(WaitConnectivity(x)∧connParametersres(x)∧ ¬InArea(a, x)∧ PreferredOut(b,a)∧Used(b,x)∧(Excellent(b, x)∨Good(b,x))→NOperational(x)) (3.61)

Когато използваният носещ ресурс b от устройство x е предпочитаният извън областта, мощността на приетия сигнал от b е ниска и c е най-добрият наличен носещ ресурс, тогава агентът инициира процедура по избор на носещ ресурс c: G (WaitConnectivity(x)∧connParametersres(x)∧¬InArea(a,x)∧ PreferredOut(b,a)∧Used(b,x)∧Bad(b,x)∧Available(c,x)∧Best(c,a)→selectreq(x,c)∧ BadPreferred(x)∧NWaitBearerAck(x)) (3.62)

В случай, че използваният носещ ресурс b от устройство x не е предпочитаният, c е наличен предпочитан носещ ресурс, и приетата мощност на сигнала на c от устройство x не е ниска, агентът инициира процедура по избор на носещ ресурс c: G(WaitConnectivity(x)∧connParametersres(x)∧ ¬InArea(a,x)∧Used(b,x)∧ ¬PreferredOut(b,a)∧ Available(c, x)∧PreferredIn(c, a)∧¬BadPreferred(x) →selectreq(x,c)∧ NWaitBearerAck(x)) (3.63)

Когато мощността на предпочитания носещ ресурс c е ниска и d е най-добрият нали-чен носещ ресурс, агентът инициира процедура по избор на носещ ресурс d: G(WaitConnectivity(x)∧connParametersres(x) ∧ ¬InArea(a,x)∧Used(b,x)∧ ¬PreferredOut(b,a) ∧ Available(c,x)∧ PreferredIn(c, a)∧ BadPreferred(x) ∧Best(d,a)∧ Available(d,x) →selectreq(x, d)∧NWaitBearerAck(x)) (3.64)

Когато няма налични носещи ресурси за устройство x и приетата мощност на сигнала на използвания носещ ресурс b от устройство x не е ниска, устройството се разглежда като работно: G(WaitConnectivity(x)∧connParametersres(x)∧Used(b,x) ∧(Excellent(b, x)∨Good(b, x))∧ AvailableEmpty(x)→ N Operational(x)) (3.65)

Агентът счита устройството x за нерегистрирано, когато приетата мощност на сигнала на използвания носещ ресурс b е ниска и няма налични други носещи ресурси: G(WaitConnectivity(x)∧connParametersres(x)∧Used(b,x)∧Bad(b,x)∧AvailableEmpty(x) →NUnregistered(x)) (3.66)

След успешно изпълнение на процедурата по избор на носещ ресурс устройството се регистрира отново. G(WaitBearerAck(x)→⊤U selectBearerreq(x, b)) (3.67) G(WaitBearerAck(x)∧selectBearersres(x)→NWaitReregistration(x)) (3.68) G(WaitReregistration(x)→⊤Uregreq(x)) (3.69) G(WaitReregistration(x)∧regreq(x)→regres(x)∧¬BadPreferred(x)∧getLocationreq(x)∧ NWaitLocation(x)) (3.70)

23

Устройство x е в работно състояние, докато агентът приеме известяване, че мощността на сигнала на използвания от устройството носещ ресурс се е променила или известяване, че устройството е променило местоположението си (спрямо област а): G(Operational(x)→⊤U (notifyPowerreq(x)∨notifyGeoreq(x))) (3.71)

В работно състояние, когато се приеме известяване, че устройството x е променило местоположението си, агентът прави запитване за параметрите на свързаността на устройството: G(Operational(x)∧notifyGeoreq(x)→notifyGeores(x)∧connParametersreq(x)∧ NWaitConnectivity(x)) (3.72)

В работно състояние, когато се приеме известяване, че филтърът Received power trap e неактивен, състоянието на устройството остава работно: G(Operational(x)∧notifyPowerreq(x,b)∧ PowerTrapInactive(x)→ notifyPowerres(x,b)∧ NOperational(x)) (3.73)

Активирането на филтъра Received of power trap в работно състояние означава, че мощността на приетия сигнал е станала ниска и агентът зарежда таймер с време, през което очаква мощността на приетия сигнал да се стабилизира. Очаква се или таймерът да изтече, или да дойде известяване за изменение на местоположението или известяване за изменение на мощността на приетия сигнал: G(Operational(x)∧notifyPowerreq(x,b)∧PowerTrapActive(x)→ notifyPowerres(x,b)∧set(Tmargin(x))∧NWaitMargin(x)) (3.74) G(WaitMargin(x)→⊤U (notifyPowerreq(x,b)∨notifyGeoreq(x)∨Tmargin(x))) (3.75)

Ако при задействан филтър Received power trap се получи известяване, че филтърът за приетата мощност на сигнала е станал неактивен, това означава, че мощността на приетия сигнал се е подобрила, таймерът се нулира: G(WaitMargin(x)∧notifyPowerreq(x,b)∧ PowerTrapInactive (x)→notifyPowerres(x,b)∧ resetTmargin(x)∧N Operational(x)) (3.76)

Ако обаче таймерът изтече, това означава, че мощността на приетия сигнал е останала ниска и в този случай агентът прави запитване за параметрите на свързаност на устройството: G(WaitMargin(x)∧Tmargin(x) →connParametersreq(x)∧N WaitConnectivity(x)) (3.77)

Докато се очаква стабилизиране на мощността на приетия сигнал при задействан филтър за мощността, устройството може да измени местоположението си: G(WaitMargin(x)∧notifyGeoreq(x)→notifyGeores(x)∧N WaitMargin (x)) (3.78)

Когато устройството е нерегистрирано поради проблеми със свързаността, след известно време то може да се опитва да се регистрира отново.

3.3 Модели на автономен енергиен мениджмънт В авторска публикация [A8] са представени разширения на модели за управление на

мощността на електрически уреди у дома, които отразяват виждането на управлявано устройство и на сървъра за състоянието на устройството. Моделите са съставени на база контекстно свързаните модели на наблюдение и въздействиe, представени във втора глава. Описанието на моделите е формализирано и верифицирано.

24

В авторска публикация [A9] е дефиниран модел на автономен агент за управление на мощността на устройства, използвани за отопление и охлаждане. Агентът за управление на мощността взаимодейства с агента за управление на помещение, който е отговорен за отваряне и затваряне на вратите и прозорците в помещението, където е инсталирано устройството.

3.4 Разширен модел за мениджмънт на свързани устройства Стандартизиращата организация Open Mobile Alliance (OMA) е разработила

стандарт за мениджмънт на М2М устройства, именуван Lightweight M2M (LWM2M). Стандартът дефинира архитектура за мениджмънт, базирана на REST (Representational State Transfer), дефинира ресурси и модели на данни, които са разширяеми, както и протокол за мениджмънт. В авторски публикации [A10], [A11] и [A12] са представени разширения на информационния модел на М2М устройство на LWM2M с данни за поддържаните от устройството сензори и въздействащи механизми. Разширенията са описани съгласно възприетия стандарт с XML (eXtensible Markup Language).

Фиг.3.1 формализира описанието за тип на сензор. Съществуват различни типове сензорни (напр акселерометри, магнитометри, жироскопи, датчици за налягане, сензори за влага, температурни датчици, околна светлинни сензори, сензори за близост и т.н.).

Чувствителността на сензора се дефинира като наклон на изходната характери-стична крива или по-общо казано като минималното входно въздействие на дадена физическа величина, което ще предизвика промяна на изхода. За някои сензори чувствителността се дефинира като параметрично изменение по вход, което е необходимо, за да се постигне унифицирано изменение на изхода. При други се дефинира като изменение на изходното напрежение за дадено изменение на входната величина.

Фиг.3.1. XML дефиниция на информационен елемент SensorType По аналогичен начин са дефинирани информационни елементи за функцията за

автокалибриране на сензор, точност на сензор и грешка на сензор. Дефинирани са и информационни елементи, описващи въздействащ механизъм, включително тип на въздействащия механизъм, максимална статична сила, текуща статична сила и функция за автокалибриране.

25

Мощността на въздействащия механизъм на управляема врата, прозорец и на устройство за отопление и охлаждане се използват от автономен агент за управление на мощността на устройства при определяне на необходимото време за изпълнение на съответното действие (отваряне / затваряне на врата и прозорец, както и времето, необхо-димо на устройството да отопли / охлади до определена температура). Възможността за автокалибриране може да се използва при откриване на проблем с врата, прозорец или в устройството.

Четвърта глава

Изследване на методи за синтезиране на възможности на услуги в комуникации от машинен тип

4.1 Метод за достъп до информация за достъпност на устройства Анализът на типичните случаи на използване на достъп до информацията за

местоположението и присъствието на M2M устройство дава възможност за дефиниране на основни функции, които може да се предложат на различни приложения като възможност на услуги (табл.4.1 и табл.4.2).

Табл.4.1 Основни функции за достъп до информация на местоположението

Функции за достъп до информация за

местоположението

Операции за достъп до информация за

местоположението

HTTP метод

Извличане на местоположението по заявка

getDeviceLocation GET

Създаване на абонамент за докладване на местоположението при наличие на условие

startTriggeredLocationNotification POST

Докладване на местоположението при наличие на условие

triggeredLocationNotification PUT

Прекратяване на абонамент за докладване на местоположението при наличие на условия

stopTriggeredLocationNotification DELETE

Създаване на абонамент за периодично докладване на местоположението

startPeriodicLocationNotification POST

Периодично докладване на местоположението

periodicLocationNotification PUT

Прекратяване на абонамент за периодично докладване на местоположението

stopPeriodicLocationNotification DELETE

Извличане на информация за разстоянието на устройството от определена точка

getDeviceDistance GET

26

Цялата информация, свързана с достъпа до информация за местоположението и присъствието на устройството, се моделира като ресурси, организирани в дървовидна структура. Моделите на информацията за местоположение са представени в авторски публикации [A13] и [A14].

Дадено приложение може да бъде известено при влизане или излизане на устройст-вото в дадена географска област. За целта приложението трябва да определи целева об-ласт и критерии за известяване, например при влизане в областта, при излизане или при двете. Ресурсът <deviceChangeReporting> е съвкупност от ресурси <deviceLocationChan-ge>, всеки от които регистрира изменение на местоположението. Структурата на ресурса <deviceLocationChange> е показана на фиг.4.1 Фиг.4.2 показва структурата на ресурс <devicePresence>.

Табл.4.2. Основни функции за достъп до информация на присъствие

Функции за достъп до информация за присъствие

Операции за достъп до информация за присъствие

HTTP метод

Извличане на информация за присъствие getDevicePresence GET Създаване на абонамент за известявания, свързани с информация за присъствие

startPresenceNotification POST

Известявания, свързани с информация за присъствие

statusNotified PUT

Прекратяване на абонамент за известявания, свързани с информация за присъствие

stopPresenceNotification DELETE

Известяване, че е завършил броя на известяванията за информация за присъствие

statusEnded PUT

Известяване, че е завършил абонамента за достъп до информация за присъствие

subscriptionEnded PUT

Публикуване на информация за присъствие publish PUT Извличане на атрибути за присъствие getSubscribedAttributes GET Изменение на права за достъп до информация за присъствие

updateAuthorizationRule POST

Изтриване на права за достъп до информация за присъствие

deleteAuthorizationRule DELETE

Създаване на абонамент за известявания за наблюдатели на информация за присъствие

startDeviceWatcherNotification

POST

Прекратяване на абонамент за известяванияза наблюдатели на информация за присъствие

stopDeviceWatcherNotification

DELETE

Известяване за наблюдатели на информация за присъствие

notifyDeviceWatchers PUT

Извличане на наблюдатели на информация за присъствие

getDeviceWatchers GET

В авторска публикация [A15] е описан метод за моделиране на поведението на

Service Capability Server (SCS), който поддържа М2М възможности на услуги, и е оценено неговото натоварване. Моделът прилага управление на достъпа за всеки доставчик на

27

приложения (AP). SCS е с разпределена архитектура и съдържа M на брой обработващи елементи. Управлението на достъпа е изградено от компоненти за филтриране на съобщения (Fi) и компоненти, представящи ведра с жетони (Bi).

Фиг.4.1 Структура на ресурса deviceLocationChange

Фиг.4.2. Структура на ресурса devicePresence

Входящият поток от заявки се генерира от M2M мрежови приложения (U) на

доставчик на приложения и M2M приложения в устройства или шлюзове (V). Допуснатите и отхвърлените HTTP заявки се означават съответно с G и R. Първото ведро с жетони B1 ограничава общия брой на заявките. Заяка се отхвърля поради нарушаване на SLA и се изпраща HTTP отговор 429 Too many requests. Филтър F1 пропуска HTTP заявки DELETE, всички от които се приемат, тъй като освобождават ресурси. Филтър F2 пропуска НТТР заявки GET, които се ограничават от ведро B2. Филтър F3 пропуска НТТР заявки PUT, които се ограничават от ведро B3. И най-накрая филтър F4 пропуска НТТР заявки POST, които се ограничават от ведро B4. Загубите в опашката се формират от

28

всички съобщения в допуснатите потоци, които пристигат при пълна опашка. Чрез балансни уравнения се изразяват зависимостите между потоците от заявки и отговори, които постъпват в системата и биват приети за обслужване или отхвърлени.

В случаи на много заявки от мрежата (т.е. известявания от устройствата) значителен брой известявания ще бъдат отхвърлени, докато в някои от ведрата може да има жетони. Частично решение на този проблем може да се приложи с динамично „вътрешно споразумение за нивото на обслужване (SLA)” между вторичните ведра. Прави се до-пускане, че процесът на постъпване поне за един интервал е стационарен и A означава броя на известявания. Тогава възможна форма на преразпределяне на постъпващите потоци е:

ρρρ Δ+=+)(

1)( )( x

gkx t (4.1)

ρρρ Δ−=+)(

1)( )( y

gky t (4.2)

където gρ е статична гарантирана скорост на заявки от даден клас. Индексът x е индекс на ведро от второ ниво, отговарящ на j

jRx maxarg= (4.3)

а y е индекс на ведрото, такъв, че )()()()( )( yyk

ygk

yy ATttS −−Δ+= ρμ (4.4)

е положителен максимум, като μ e текущ брой жетони, T e максимален брой жетони за ведрото.

Ако такъв положителен максимум съществува, без да се променя общият брой жетони за временните SLA, приносът на донора на жетони става:

k

kyyy

yg t

tATΔ−+

−=Δ)()()()(

)( μρρ (4.5)

и се преоценява във всеки интервал на наблюдение. Управлението на достъпа се прилага за всеки доставчик на приложения j. Нека чрез

C се означи капацитета на SCS, а с N броят на доставчиците на приложения (AP). Тогава използваемостта на SCS може да се формулира като:

)))()(()(().(

1 )10()9(

1

)1(

10ijij

K

iii

N

jk

tRtRtGttC

+−−

= ∑∑==

η (4.6)

където K дефинира общото време, )1(G са постъпващите съобщения в контролер на дос-

тъп, )9(R са отхвърлени съобщения е от контролер на достъп, )10(R от обработващ еле-мент) с опашка с ограничена дължина.

Симулацията на модела на SCS е с четири класа заявки. Капацитетът на SCS е 800 заявки за секунда. Поведението на всеки M2M АР се моделира с Markov Modulated Poisson Process. M2M приложенията генерират заявки съгласно MMPP с четири състояния. Смяната между различните състояния става по случаен закон с равномерно разпределение и се провежда съгласно Poisson Process, като средното време за престой в дадено състояние е 4 секунди. Интервалите от време между постъпващи POST заявки (абонаменти за известявания), между PUT заявки (известявания) и между GET заявки (извличане на стойности на ресурси например местоположение на устройство) са експоненциално разпределени със съответно средно време 200 s, 50 s и 50 s. Скоростта на постъпване на жетони във всяко ведро е равна на гарантирана скорост, а размерът на

29

ведрото се определя от съответната максимална скорост. Първоначално 00 )( Tti =μ . Периодът на наблюдение (tk-1, tk] е равен на 100 ms. Средното време за обработка на заявка е 5 ms.

Целта на симулацията е да се оцени използваемостта на SCS чрез определяне на различни стойности на гарантираните и пиковите скорости за различните класове заявки. Гарантираните скорости за даден M2M АР дефинират следните ограничения: GR1 за предпазване на SCS от претоварване, GR2 за скоростите на заявки POST, GR3 за скорости на заявки PUT и GR4 за скорости на заявки GET. Обработващият капацитет на SCS трябва да бъде разпределен между четирите класа заявки, като максималната скорост на постъпване на заявки (PR1) трябва да бъде разпределена между заявки POST (PR2), заявки PUT (PR3), заявки GET (PR4) и заявки DELETE.

Фиг.4.3 обобщава резултатите от симулацията. Симулационните резултати показват, че използваемостта на SCS в M2M среда зависи както от броя на M2M APs, така и от специфичните стойности в SLA. В случай, че прагът за претоварване на SCS бъде определен като 80%, най-подходящият избор е 22 M2M APs, за които се прилага втори или трети тип SLA.

Фиг.4.3 Използваемост на SCS като функция на броя M2M доставчици на приложения

4.2 Методи за мениджмънт на неизправности и работоспособността на

устройства Мениджмънтът на M2M ресурси поддържа знание за ресурсите (M2M устройства и

M2M мрежи), и е отговорен за управлението на всички ресурси, използвани за предоставяне на услуги на М2М приложения. Освен осигуряване на ресурси (раз-пределение, инсталиране, конфигуриране, активиране на M2M ресурси), мениджмънтът на ресурси включва мениджмънт на неизправности и мениджмънт на работоспособ-

30

ността. Отговорностите мениджмънта на неизправности (FM) на M2M ресурси включват откриване, анализиране, управление и докладване на аларми, свързани с ресурси; иницииране и управление проследяването на неизправности; извършване на анализ на неизправности и локализиране; коригиране и отстраняване на проблеми, свързани с ресурсите; тестване след възстановяване и управление на ситуации на грешки и неизправности. Мениджмънтът на работоспособността (PM) на M2M ресурси е отговорен за управление, проследяване, мониторинг, анализ, контрол и докладване на работоспо-собността на специфични M2M ресурси. Тези функции могат да бъдат предоставени като възможност на услуга. Изследванията върху възможности на услуги за FM и PM са представени в авторска публикация [А15].

Табл.4.3 обобщава основните функции, свързани с FM и PM на М2М устройства, операциите и съответните HTTP заявки, с които се предават.

Табл.4.3. Основни функции за мениджмънт на устройства Функции за мениджмънт на неизправности

и работоспособност на устройства Операции за мениджмънт

на устройства HTTP метод

Извличане на информация за състоянието на устройство

getDeviceState GET

Извличане на информация за натоварването на приложение на устройство

getLoadAppState GET

Извличане на статистика за натоварването на приложение на устройство

getLoadStatState GET

Създаване на абонамент за известявания, свързани със състоянието устройство

startPeriodicDeviceStateReport POST

Известявания, свързани със състоянието устройство

deviceStateReport PUT

Прекратяване на абонамент за известявания, свързани със състоянието устройство

startPeriodicDeviceStateReport DELETE

Създаване на абонамент за периодично известяване за натоварването на приложение

startPeriodicApplLoadReport POST

Периодично известяване за натоварването на приложение

appLoadReport PUT

Прекратяване на абонамент за периодично известяване на натоварването

startPeriodicApplLoadReport DELETE

Създаване на абонамент за известяване за натоварването при определено условие

startTriggeredApplLoadReport POST

Прекратяване на абонамент за известяване на натоварването при определено условие

stopTriggeredApplLoadReport DELETE

Иницииране на самотестване на устройството deviceAutoTest PUT Иницииране на автокалибриране на устройството

deviceAutocalibration PUT

Иницииране на рестарт на устройството deviceReboot PUT Информационната система за интелигентно отчитане (Smart Metering Information

System - SMIS) се дефинира като интегрирана система, която обхваща интелигентни

31

измервателни уреди, комуникационни мрежи и системи за управление на бази данни. SMIS като приложение на интернет на нещата позволява събиране на информация за потреблението на енергия и разпространение сред клиентите и други страни като доставчик на енергия, дистрибутор на енергия и доставчик на услуги. Тя осигурява възможност за клиентите да контролират разходите си за енергия, като предоставя информация, която те изискват. За да се моделират функции за мениджмънт на SMIS, е необходимо да се дефинира модел на данни, който представя абстракция на данните и да структурира информацията в контекста на управлението на енергийните характеристики и интелигентно управление. Информационните модели на SMIS са представени в авторска публикация [A17]. Фиг.4.4 показва структурата на ресурси за управление на енергийните характеристики и мениджмънт на работоспособността на интелигентно измервателно устройство.

Фиг.4.4 Структура на ресурс, представящ интелигентно измервателно устройство

Фиг.4.5 Структура на ресурс, представящ

състоянието на интелигентно измервателно устройство

В интелигентното измервателно устройство има микроконтролер с малка мощност

за обработка на данни и памет за съхранение на данни. Описанието на фърмуера, софтуера, батерията и паметта на устройството не се различава от това на кое да е M2M

32

устройство и може да се намери в ETSI TS 102 690. При описанието на модела на интелигентно измервателно устройство се поставя ударение върху това, което е специфично и не може да се намери в спецификациите.

Фиг.4.5 представя структурата на състоянието на интелигентно измервателно устройство. Атрибутът smartMeterStatus показва работното състояние на интелигентно измервателно устройство. Интелигентното измервателно устройство може да изпълнява самотестове с цел откриване на предварително дефинирани критични и некритични греш-ки, които могат да възникнат. Критичните грешки показват, че е открита критична за работоспособността на устройството грешка. Типовете критични грешки варират за различните производители, но типичните критични грешки може да са причинени от грешка в паметта, грешка в процесорното управление, в данните, метрология, грешка в комуникацията, грешка на файловата система, работната система и т.н. Функционал-ността за възстановяване от грешки цели измервателното устройство да се самовъзстано-ви след появата на грешка с минимална загуба на данни. Атрибутът selfTestStatus показва състоянието на самодиагностиката, а атрибутът fatalErrorRecoveryStatus показва състоя-нието на възстановяване от критична грешки. Ресурсите selfTestAction и fatalErrorReco-veryAction съдържат действията, които трябва да се изпълнят, и имат атрибути за включване/ изключване на самодиагностиката и възстановяването от критична грешка.

Специфичните характеристики на ресурса serviceSwitch, представящ превключвателя на интелигентно измервателно устройство, са атрибут serviceSwitchState със стойности, свързан или отцепен, и подресурси serviceSwitchAction и switchStatusTrapEvent. Инте-лигентните измервателни устройства може дистанционно да се включват/изключват по заявка чрез превключвателя и ресурсът service-SwitchAction ресурс има атрибути, които активират съответното действие. Устройството може да открие и регистрира опити за включването и изключването му, както отдалечено, така и в помещенията на клиента. За тази цел се използва ресурсът switchStatusTrapEvent, който следва дефиницията на ресурса etsiTrapEvent ресурс. Ресурсът timingModule представя вътрешния часовник на измервателното устройство и има атрибути, които показват часа и датата и подресурс synchronizationAction подресурс, който съдържа действията за синхронизиране. Часов-никът на устройството трябва да бъде сверяван с външен източник на време най-малко веднъж на ден. Ресурсът smTrapEvent се използва за дефиниране на събития, свързани с поява на критична грешка. Когато измервателното устройство започне възстановяване от критична грешка, той може да изпълни определен брой пъти съответния тест.

Моделът на поведение при самовъзстановяване може да се опише с уравнения (4.7)-(4.18), като се използват предикати. Предикатът Timerselftest става истина, когато стане време за самотестване на интелигентно измервателно устройство. Предикатът fatalError е истина при наличие на критична грешка. Предикати се използват за описание на комуникацията на устройството и неговите състояния. Използват се функции за зареждане и нулиране на таймер и активиране на тест. Предикати се използват, за да се определи завършването на тест и наличие на резултати от теста.

Интелигентно измервателно устройство е в работно състояние докато не дойде време да изпълни самотестване или не се получи външна заявка за това: G(Operational→⊤U(Timerselftest∨executeSelftestreq) (4.7)

При приемане на заявка за самотестване или настъпване на време за самотестване се активира съответният тест:

33

G(Operational∧executeSelftestreq→ executeSelftestres∧reset(Timerselftest) ∧activateSelftest∧NSelftesting) (4.8) G(Operational∧ Timerselftest→ executeSelftestres∧activateSelftest∧NSelftesting) (4.9) G(Selftesting→⊤U(availableTestResult) (4.10)

Ако резултатите от самотестването показват отсъствие на грешка, се зарежда таймерът с времето за следващото самотестване. Ако резултатите показват наличие на грешка, тя се регистрира. Ако грешката е критична, се активира самовъзстановяващата процедура и ако тя е неуспешна, интелигентното измервателно устройство има критична грешка, чието отстраняване изисква външна намеса: G(Selftesting∧availableTestResult∧testResultOK→set(Timerselftest)∧NOperational) (4.11) G(Selftesting∧availableTestResult∧¬testResultOK∧¬fatalError→errorLog∧ set(Timerselftest)∧NOperational) (4.12) G(Selftesting∧availableTestResult∧¬testResultOK∧fatalError → notifyreq∧errorLog∧ NWaitAck) (4.13) G(WaitAck→⊤U(notifyres)) (4.14) G(WaitAck ∧notifyres→ notifyreq∧activateRecoveryTest∧NRecovering) (4.15) G(Recovering→⊤U(recoveryEnded)) (4.16) G(Recovering∧recoveryEnded∧¬fatalError → set(Timerselftest)∧NOperational) (4.17) G(Recovering∧recoveryEnded∧fatalError → NFatalError) (4.18)

Моделирани са ресурси, които може да се използват за наблюдение на качеството на предоставяната електроенергия.

4.3 Метод за управление на трансакциите в комуникации от машинен тип Управлението на трансакциите е дефинирано като незадължителна възможност на

услуги в стандартите на ETSI. В дисертационния труд е аргументирана необходимостта от такъв тип функционалност.

Елементарните процедури, свързани с манипулиране на състоянието на М2М ресурс, се разглеждат като примитивни стъпки на трансакция, които са неделими. Дефинират се функции за мениджмънт на трансакциите, които също се разглеждат като неделими стъпки. Новите функции, които се изпълняват от трансакции, са:

• startTransaction <M2Mresource> (transaction ID); • commitTransaction <M2Mresource> (transaction ID); • abortTransaction <M2Mresource> (transaction ID). Функцията startTransaction <M2Mresource>(transaction ID) се използва за отваряне на

трансакция от изпращащия заявка към предлагащ, възможност на услуга, за да може да се манипулира състоянието на М2М ресурси. Всички взаимодействия с предлагащия възможност на услуги се третират като част от трансакцията, докато не се извика функция commitTransaction<M2Mresource>(transaction). Ефектът от изпълнението на startTransaction<M2Mresource>(transaction) е „заключване” на М2М ресуса, докато ефектът от commitTransaction<M2Mresource>(transaction) е „отключване” на ресурса. Функцията abortTransaction<M2Mresource>(transaction) прекратява трансакцията и се

34

отхвърлят всички изменения, направени след извикване на startTransaction<M2Mre-source>(transaction).

Традиционният алгоритъм за тестване на сериализацията на разписания, разработен за бази данни, може да се адаптира за М2М комуникации по следния начин, показан на фиг.4.6 и е представен в авторска публикация [A18].

Фиг.4.6. Алгоритъм за тестване на сериализацията на разписания на М2М трансакции Твърдение 3: Алгоритъмът коректно определя дали дадено разписание U има ефект

на последователно. Доказателство 3: Нека G има цикъл: TJ1 → TJ2 → … → TJt → TJ1 Нека съществува последователно разписание Q, еквивалентно на U, и се допусне, че

в Q, TJ1 се явява първа сред трансакциите в цикъла. Нека дъгата TJp-1 → TJp (където индексът Jp-1 да бъде Jt, ако p = 1) да е в G заради М2Мresource. Тогава в Q, тъй като TJp се явява преди TJp-1, крайната формула за М2Мresource прилага функция f, свързана с дадена двойка startTransaction <M2Mresource> (transaction) и commitTransaction<M2M-resource>(transaction) в TJp преди прилагане на функция g, свързана с двойката startTransaction <M2Mresource> (transaction) и commitTransaction <M2Mresource> (transac-tion) в рамките на трансакция TJp-1. В U обаче, ефектът от TJp-1 върху M2Mresource предхожда ефекта от TJp върху M2Mresource, тъй като съществува дъга TJp-1 → TJp, изразяваща факта, че TJp използва стойност на M2Mresource, изчислена от TJp-1. Следователно в разписание U, g се прилага към израз, включващ f за M2Mresource. Крайната стойност на M2Mresource се различава за Q и U, тъй като двете формули не са еднакви за M2Mresource. Може да се заключи, че Q и U не са еквивалентни. Доколкото Q

35

е произволно последователно разписание, следва че U е еквивалентно на непоследователно разписание.

Обратно, допуска се, че G няма цикли. Дефинира се дълбочина на трансакция в ацикличен последователен граф да бъде дължината на най-дългия път към възел, отговарящ на трансакцията. Така че трансакция с дълбочина d може да извлече стойности, записани от трансакции с по-малка дължина от d. Чрез индукция по d може да се докаже, че дадена трансакция T с дълбочина d извлича еднакви стойности за елемент, който заключва, както в даденото разписание U (от което е съставен последователния граф), така и в последователното разписание Q, конструирано от предложения алгоритъм. Причината е, че ако трансакция T извлича стойност на M2Mresource, тогава и в двете разписания една и съща трансакция T′ е била последна по запис на M2Mresource (или и в двете разписания T е първата, която извлича стойността на M2Mresource). Ако се допусне обратното, че в U трансакция T извлича стойност на M2Mresource записана от T′, но в Q стойността е записана от T′′. Нека TI1, TI2, … TIr е последователността от трансакции, които заключват M2Mresource в разписание U. Тогава в графа G съществуват дъги TI1→ TI2 → …→ TIr. В последователността T′ непосредствено предхожда T. Тогава при топологическо сортиране на G не е възможно T′′, която също заключва M2Mresource, и поради това се намира в тази последователност, да се появи между T′ и T. До тук е установено е, че T извлича стойност на M2Mresource, записана от T′, и в двете разписания Q и U. Знае се също, че дълбочината на T′ трябва да е по-малка от тази на T , защото съществува дъга T’→T. По индукция стойността, записана за M2Mresource от T′, е една и съща за двете разписания. Доколкото това важи за кой да е елемент, заключен от T, е ясно, че T извлича една и съща стойност за всеки елемент, който тя е заключила. Ето защо и в двете Q и U, стойностите, записани от трансакция T за всеки от заключените от нея елементи, са еднакви, с което се доказва индукцията.

В авторска публикация [A19] е представен метод за управление на трансакциите на приложно ниво. Логиката на едно М2М приложение може да бъде описана като набор от сравнително независими процеси, които са слабо обвързани. Процесите комуникират чрез обмен на съобщения. Всеки обмен на съобщения е организиран в заявките и отговорите. Заявката с всички нейни отговори образува трансакция. В предложения метод за управление на трансакциите надеждното предаване на съобщения в рамките на трансакция се осигурява чрез механизъм за препредаване.

Фиг.4.7 показва зависимостта на ktrans

P като функция на Ploss. Фиг.4.8 показва зависимостта на вероятността за успешна клиентска трансакция ),( N

lossP

TP като функция на

вероятността за загуба на съобщения. Фамилията от криви, показана на фиг.4.9, представя вероятностната оценка на латентността при успешна трансакция, където възможните предавания на заявка в дадена трансакция са N и стойността на таймер за препредаване на заявка е постоянна. При фиксирано закъснение за предаване на съобщения (d = 50 ms) може да се определи вероятностната оценка на латентността при успешна трансакция като функция на вероятността за загуба на съобщения при различни стойности на таймера за препредаване T. Фамилията от криви, показана на фиг.4.10, представя вероятностната оценка на латентността при успешна трансакция, където възможните предавания на заявка в дадена трансакция са N и началната стойност на таймер за препредаване на заявка Т се удвоява при всяко следващо предаване.

36

Фиг.4.7 Вероятност за успешна трансакци при k на брой изпращания на заявка като функция на вероятността за загуба на

съобщения

Фиг.4.8 Зависимост на общата вероятност за успешна трансакция от вероятността за

загуба на съобщения

Фиг.4.9 Вероятностна оценка на

латентността при успешна трансакция с N възможни предавания на заявка (d = 50 ms,

T = 800 ms)

Фиг.4.10 Вероятностна оценка на

латентността при успешна трансакция с четири възможни предавания на заявка

(N=4, d = 50 ms)

Фиг.4.11 и фиг.4.12 представят сравнение на вероятностната оценка на латентността

при успешна трансакция за случай на постоянна стойност на таймера за препредаване на

37

заявки (a), случай с експоненциално увеличение на стойността на таймера за препредава-не без ограничения на максималната стойност (b) и случай (с) с ограничение на макси-малната стойност на увеличаващия се таймер за препредаване на заявки съответно за L = 1500 ms и L = 3500 ms.

Фиг.4.11 Вероятностна оценка на

латентността при успешна трансакция: при L = 1500 ms

Фиг.4.12 Вероятностна оценка на

латентността при успешна трансакция: при L = 3000 ms

Резултатите показват, че при определяне на праг за максимална стойност на таймера

за препредаване на заявки трябва да се търси компромис между по-малкото време за успешна трансакция със съсредоточаване на препредаванията на заявки през фиксиран период от време и намаляването на броя на препредаванията на заявки чрез експонен-циално увеличение на времето за препредаване.

Пета глава

Изследване на модели и методи за управление на качеството на обслужване в комуникации от машинен тип

5.1 Метод за управление на качеството на обслужване на сесии на устройства Идентификацията на общите функции за управление на качеството на обслужване,

които може да се предлагат като възможност на услуги, се дефинира на базата на анализ на изискванията към управлението на качеството на обслужване (QoS) за М2М устройства и поддържаната функционалност за Policy and Charging Control (PCC), представен в авторска публикация [A20]. Общите функции за управление на качеството

38

на обслужване и поддържането им от дефинирани уеб услуги са изследвани в авторска публикация [A21].

Идентифицираната функционалност може да се използва за разширение на модела за автономен мениджмънт на свързаността на М2М устройства. Използват се предикати за описание на обмена на съобщения и за състоянието носещите ресурси, заделени за М2М сесия. Например предикатът RequestedQoS(x) става истина, когато заявеното QoS от агента за управление на качеството на обслужване може да се приложи, a когато RequestedQoS(x) не е истина се прилага QoS по подразбиране за сесиите на устройство x. Предикатът AllBearersLost(x) става истина, когато всички носещи ресурси за устройство x са загубени, а при загуба на носещ ресурс предикатът BearersLost(x) става истина. Таймерът TimerQoS(x) определя продължителността за прилагане на специфично QoS за М2М сесията на устройство x.

Агентът за управление на QoS се активира при приемане на заявка за изграждане на M2M сесия: G(Null(x)→⊤U sessionreq(x)) (5.1)

При приемане на заявка за изграждане на M2M сесия агентът установява специфични стойности на QoS параметри за M2M сесията: G(Null(x)∧sessionreq(x)→setQoSreq(x)∧NWaitQoSAck(x)) (5.2) G(WaitQoSAck(x)→⊤U setQoSres(x)) (5.3)

Ако желаното QoS е приложимо за M2M сесията, агентът зарежда таймер TimerQoS(x) и регистрира своя интерес за получаване на известия, свързани с QoS: G(WaitQoSAck(x)∧setQoSres(x)∧RequestedQoS(x)→set(TimerQoS(x))∧ startQoSnotificationreq(x)∧NWaitSubscriptionAck(x)) (5.4) G(WaitSubscriptionAck(x)→ ⊤UstartQoSNotificationres(x)) (5.5) G(WaitSubscriptionAck(x)∧startQoSNotificationres(x)→NAppliedQoS(x)) (5.6)

Ако желаното QoS не може да бъде приложено за M2M сесията, агентът изисква информация за използваните и наличните носещи ресурси: G(WaitQoSAck(x)∧setQoSres(x)∧¬RequestedQoS(x)→getBearersreq(x)∧NWaitBearers(x)) (5.7) G(WaitBearers(x)→⊤UgetBearersres(x)) (5.8)

Ако има налични носещи ресурси, агентът взема решение за смяна на носещия ресурс: G(WaitBearers(x)∧getBearersres(x)∧¬usedBearer(x,b)∧availableBearer(x,c)→ changeBearerreq(x,c)∧ NWaitBearerChange(x)) (5.9) G(WaitBearerChange(x)→⊤UchangeBearersres(x)) (5.10)

След смяната на носещия ресурс агентът прави запитване за APN профили и активира нов APN профил: G(WaitBearerChange(x)∧changeBearersres(x)→getAPNsreq(x)∧NWaitAPNs(x)) (5.11) G(WaitAPNs(x)→⊤UgetAPNsres(x)) (5.12) G(WaitAPNs(x)∧getAPNsres(x)→activateAPNreq(x)∧NWaitAPNactivation(x)) (5.13) G(WaitAPNactivation(x)∧activateAPNres(x)→setQoSreq(x)∧ NWaitQoSAck(x)) (5.14)

Ако няма налични носещи ресурси, за М2М сесията не се заделят ресурси:

39

G(WaitBearers(x)∧getBearersres(x)∧noAvailableBearers(x)→NNull(x)) (5.15) По време на активна M2M сесия със заделени ресурси със специфично QoS може да

се получат известия за събития, свързани с QoS, или таймерът TimerQoS(x) изтече: G(AppliedQoS(x)→⊤U(notifyQoSreq(x)∨TimerQoS) (5.16)

Ако се приеме известие, че всички носещи ресурси, заделени за М2М сесията, са загубени, агентът изисква смяна на носещ ресурс: G(AppliedQoS(x)∧notifyreq(x)∧AllBearersLost(x)→notifyres(x)∧ getBearersreq(x)∧NWaitBearers(x)) (5.17)

Ако се приеме известие, че носещ ресурс, заделен за М2М сесията, е загубен, агентът изисква изменение на QoS: G(AppliedQoS(x)∧notifyreq(x)∧BearerLost(x)→notifyres(x)∧modifyQoSsreq(x)∧ NWaitModifyAck(x)) (5.18) G(WaitModifyAck(x)→⊤UmodifyQoSres(x)) (5.19) G(WaitModifyAck(x)∧modifyres(x)∧requestedQoS(x)→ ∧NAppliedQoS(x)) (5.20)

Ако таймерът TimerQoS(x) изтече, агентът премахва установеното QoS и прекратява абонамента си за получаване на известия, свързани с QoS: G(AppliedQoS(x)∧TimerQoS(x)→removeQoSres(x)∧NWaitRemoveAck(x)) (5.21) G(WaitRemoveAck(x)→⊤UremoveQoSres(x)) (5.22) G(WaitRemoveQoS(x)∧removeQoSres(x))→stopQoSNotificationreq(x)∧ NWaitStopAck(x)) (5.23) G(WaitStopAck(x)→⊤U(stopQoSNotificationres(x)) (5.24) G(WaitStopAck(x)∧stopQoSNotificationres(x)→NNull(x)) (5.25)

Разширеният модел на автономен агент за мениджмънт на свързаността с управление на качеството на обслужване е представен в авторска публикация [A22].

5.2 Изследване на дефинирани услуги за управление на качеството на обс-лужване

Услугата, която е дефинирана от Parlay X за управление на QoS, е Application Driven QoS (ADQ). ADQ е уеб услуга, разрешаваща на външни за мрежата приложения динамич-но да изменят QoS, налично за M2M връзки. Измененията на QoS може да се прилагат временно за продължителността на M2M връзката или постоянно т.е. всеки път, когато дадено М2M се свърже към мрежата. Услугата дава възможност на приложение да се абонира за събития, свързани с установеното QoS, и да бъде известяванo при поява на такива събития.

В авторска публикация [A23] е представено изследване на възможностите за разгръщане на услугата в стандартизираната от 3GPP Evolved Packet System (EPS). Изследването включва синтезиране на модели, отразяващи изграждането на М2М сесия с резервиране на ресурси от гледна точка на приложението и от гледна точка на мрежата, формално описание на моделите и верификация. Направен е извод, че уеб услугата не поддържа цялата налична в мрежата функционалност за управление на QoS, която може да се предложи на външни за мрежата приложения.

40

5.3 Метод за базирано на политики управление на качеството на обслужване В авторска публикация [A24] е представен метод за управление QoS от външни за

мрежата приложения. Методът е приложим и за комуникации от машинен тип. Услугата, която осигурява приложни програмни интерфейси за управление на QoS

за външни приложения, е именувана Application-controlled Quality of Service. от страна на мрежата интерфейсите са именувани с префикс Ip, а от страна на приложението интерфейсите са с префикс IpApp.

Фиг.5.1 илюстрира клас диаграмата на интерфейсите и техните връзки. Всеки от интерфейсите поддържа набор от методи, които може да се използват за извикване на функции в мрежата и за приемане на известявания.

Фиг.5.1 UML клас диаграма на интерфейси на услугата Application-controlled Quality of

Service

41

Извикването на методите на интерфейсите на услугата Application-controlled Quality

of Service инициира съответна Diameter сигнализация в мрежата. Протоколът Diameter се използва за оторизиране на мрежови ресурси и за таксуване. Diameter командите Authentication-Authorization-Request / Answer (AAR / AAA) се използват за предаване на информация за сесията и за абониране за известявания, свързани с установеното QoS. Diameter командите Re-Authorization-Request / Answer (RAR / RAA) се използват за извес-тявания, свързани с QoS. Diameter командите Session-Termination-Request / Answer (STR / STA) се използват за освобождаване на ресурсите за сесия. Diameter командите Abort-Session-Request / Answer (ASR / ASA) се използват, за да се изпрати известия, че всички носещи ресурси за сесията са загубени или освободени.

Дефинира се следният хомоморфизъм HQoS между методите на интерфейсите на "Application-controlled Quality of Service" и съответните Diameter команди. HQoS = {fi}, i=1-20, където

f1: createQoSNotification→AARCN, f2: setUsageMonitoringReq→AARUM, f3: enableQoSNotification→AAREN, f4: startUsageMonitoring →AARUM, f5: disableQoSNotification→AARDN, f6: stopUsageMonitoring→ AARUM, f7: changeQoSNotification→ AARCN, f8: reserveSpecificQoSRes→ AAAIP, f9: notifyQoSEvent→ RARSDFD→RARIPCAN→RARSPS, f10: qosApprovalRes→ AAAGC, f11: modifySpecificQoSRes→AAASM, f12: qosApprovalReq→ AARGC, f13: removeSpecificQoSRes→AAASM, f14: modifySpecificQoSReq→AARSM, f15: getQoSInfoRes→AARGI, f16: removeSpecificQoSReq→AARSM, f17: setUsageMonitoringRes→ AAAUM, f18: releaseQoSResources→STR, f19: usageMonitoringReport→RARUM, f20: getQoSInfoReq()→AARGI

В горните означения на Diameter командите са използвани индекси, за да се направи разграничаване на различните двойки атрибут-стойност на протокола.

Моделите, които отразяват виждането на приложение за състоянието на M2M сесия с установено QoS, и Diameter сесията, свързана с резервиране на ресурси за М2М сесия, трябва да бъдат синхронизирани, т.е. да излагат еквивалентно поведение.

За да се опрости описанието с PCCrequest се означава кой да е от методите modifySpecificQoSReq, qosApprovalReq, removeSpecificQoSReq, setUsageMonitoringReq, startUsageMonitoring, или stopUsageMonitoring, докато с PCCreport се означава notifyQoSEvent (с изключение на известието, че всички носещи ресурси са освободени) или usageMonitoringReport. Методът createQoSResources създава копие на обект, представящ сесията. В състояние AppNull няма установено QoS за сесията. В състояние AppQoSAuthorized за сесията за разрешени ресурси с установено QoS. В това състояние външно приложение може да управлява М2М трафика, да изменя или премахва временно установеното QoS и да приема известявания за М2М сесията, свързани с QoS, или наблю-дението на използването на мрежови ресурси от М2М сесията. В състояние ApplicationQoSReleased приложението е премахнало временно установеното QoS за М2М сесията. В това състояние, когато М2М сесията завърши, се преминава в състояние AppNull. В състояние NetworkQoSReleased се преминава, когато приложението бива известено, че М2М сесията в мрежата е завършила или са загубени всички заделени за сесията ресурси.

42

Чрез ТApPCC = (SApPCC, АctApPCC , →ApPCC, s0,) се означава LTS, представяща виждането

на приложение за състоянието на сесия, където: - SApPCC ={ AppNull, AppQoSAuthorized, ApplicationQoSRelease,

NetworkQoSReleased}; - ActApPCC = {reserveSpecificQoSReq (at1), PCCrequest (at2), releaseQoSResources (at3),

connectionTermination(at4), PCCreport (at5), allBearersLost (at6), deassignQoSResources (at7)};

- →ApPCC = {AppNull at1 AppQoSAuthorized, AppQoSAuthorized at2 AppQoSAuthorized, AppQoSAuthorized at5 AppQoSAuthorized, AppQoSAuthorized at6 NetworkQoSReleased, AppQoSAuthorized at3 ApplicationQoSReleased, NetworkQoSReleased at7 AppNull, ApplicationQoSReleased at4 AppNull};

- s0’ = {AppNull}. При описанието на действията в скоби е дадено съкратено означение за съответното

действие. В състояние Null за М2М сесия няма резервирано QoS. Установяването на

специфично QoS от страна на приложението за сесията води до състояние QoSAuthorized, в което за сесията са заделени съответни носещи ресурси. В това състояние приложението може да изиска изменение на QoS, управление на шлюза, както и да бъде известено за събития, свързани с QoS и с наблюдението за използвани ресурси. При разпадане на М2М сесията се изпраща команда ASR, което води до преход в състояние Null. Когато приложението изиска прекратяване на М2М сесията, се изпраща команда STR и се преминава в състояние Null.

Чрез PCCprocedures се означава коя да е от Diameter командите AARIP, AARSM, AARGC или AARSM, а с PCCnotifications се означава коя да е от командите RARSPS, RARIPCAN или RARUM.

Чрез ТProtocol = (SProtocol, АctProtocol,→Protocol, s0), се означава LTS, представяща състоянието на Diameter сесия за резервиране на ресурси за М2М сесия, където:

- SProtocol ={ Null, QoSAuthorized}; - ActProtocol = {AARIP(dt1), PCCprocedures (dt2), PCCnotifications (dt3), ASR (dt4), STR

(dt5)}; - →Protocol = {Null dt1 QoSAuthorized,

QoSAuthorized dt2 QoSAuthorized, QoSAuthorized dt3 QoSAuthorized, QoSAuthorized dt4 Null, QoSAuthorized dt5 Null,

- s0 = {Null}. Твърдение 4: Системите ТAppPCC и ТProtocol са в релация на слабо биподобие. Доказателство 4: Състоянията AppNull, NetworkQoSReleased и

ApplicationQoSReleased може да се абсорбират в едно състояние AppNull, в което няма заделени ресурси за сесията.

Нека U е релация между състоянията на ТAppPCC и ТProtocol където U = {(AppNull, Null), (AppQoSAuthorized, QoSAuthorized)}.

43

Тогава са в сила следните твърдения: За AppNull at1 AppQoSAuthorized ∃ Null dt1 QoSAuthorized; За AppQoSAuthorized at2 AppQoSAuthorized ∃QoSAuthorized dt2QoSAuthorized; За AppQoSAuthorized at5 AppQoSAuthorized ∃QoSAuthorized dt3 QoSAuthorized; За AppQoSAuthorized at6 NetworkQoSReleased ∃ QoSAuthorized dt4 Null; За AppQoSAuthorized at3 ApplicationQoSReleased ∃QoSAuthorized dt5 Null.

От идентифицирания хомоморфизъм HQoS и релацията на биподобие U между ТAppPCC и ТProtocol следва, че двата модела са в релация на слабо биподобие, т.е. излагат еквивалентно поведение.

5.4 Метод за отдалечено конфигуриране на свързани устройства чрез излъчване Изследван е метод за отдалечено конфигуриране на свързани устройства чрез изпол-

зване на услуги за излъчване на мултимедийно съдържание (Multimedia Broadcast Multicast Service – MBMS) и управление на качеството на обслужване. Изследванията са публикувани в авторски публикации [А24] и [А25].

Мултимедийното съдържание, което трябва да се излъчи, се осигурява от приложен сървър (Application Sever - AS). AS може да се разгърне от трета страна или от оператора на мрежата. Broadcast Multicast Service Centre (BM-SC) съхранява мултимедийното съдържание, което трябва да бъде излъчено, управлява и взаимодейства с крайните устройства през Packet Data Network Gateway (PDN GW). BM-SC има интерфейси както за сигнализация, така и за потребителска информация към MBMS GW. MBMS Gateway (GW) разпределя приетата информация от BM-SC към съответните базови станции в мрежата за достъп. Mobility Management Entity (MME) комуникира с мрежата за достъп в съответната географска област, използвайки управляващата информация, осигурена от MBMS GW.

Уеб услугата Parlay X Message Broadcast WS (MBWS) разрешава на външни приложения да изпращат съобщения до крайни устройства в специфична географска (3GPP TS 29.199-15). Тя осигурява приложни програмни интерфейси за изпращане на мултимедийно съобщение, наблюдение за статуса на излъчване и известяване за доставяне на съобщението.

Централно място в изследванията на услугата MBMS заема BM-SC. Той трябва да комуникира с приложенията, като използва уеб услугата MBWS. Към мрежата BM-SC трябва да комуникира със: MBMS GW за поддържане на MBMS сесия; Policy and Charging Rule Function (PCRF) за осигуряване на информация за MBMS сесия и приемане на известия за резервиране на носещи ресурси; Call Detailed Funtion (CDF) за изпращане на данни за таксуване. Следователно поведението на BM-SC трябва да бъде синхрони-зирано с поведението на MBMS GW, PCRF и CDF в контекста на сесията. Освен това BM-SC трябва да синхронизира виждането си за MBMS сесията със виждането на приложението за състоянието на съобщението, което трябва да се излъчи. MBMS GW има отговорност за резервирането на ресурси в мрежата, осигуряваща IP свързаност (IP-CAN). PCRF управлява QoS, което трябва да бъде осигурено за MBMS сесията, а CDF генерира данни за таксуване.

В дисертацията са синтезирани следните модели: модел, отразяващ виждането на приложение за състояниято на излъчване на мултимедийно съобщени; модел на MBMS

44

сесия, поддържан от BM-SC; модел на сесия в мрежата за достъп, осигуряваща IP свързаност (IP-CAN), поддържан от MBMS GW, модел на носещите ресурси за сесия за излъчване, поддържан от PCRF, и модел на сесия за таксуване.

Моделът на IP-CAN сесия, поддържан от MBMS GW, включва следните състояния. В състояние IPCANIdle няма предназначена за излъчване IP-CAN сесия. При приемане на инструкции за стартиране на сесия MBMS GW посочва на PCRF, че е необходимо изменение на IP-CAN сесия и състоянието става WaitForPCCRules. В състояние WaitForPCCRules MBMS GW изчаква разрешение за изменение на IP-CAN сесия. При получаване на такова разрешение MBMS GW инициира изграждане на IP-CAN сесия в мрежата за достъп и състоянието става ResourceReservation. Преходът към състояние SessionActive се случва след приемане на потвърждение, че ресурсите в мрежата за достъп са резервирани. Преходът в състояние ResourceRelease се изпълнява, когато от BM-SC се приемат инструкции за завършване на сесията. В състояние ResourceRelease MBMS GW изчаква освобождаването на ресурсите в мрежата за достъп. В състояние WaitForTermAck MBMS GW очаква потвърждение за завършване на сесията от PCRF и се излълнява преход към състояние IPCANIdle. В състояние ResourceReservation или SessionActive MBMS GW може да се получи известие от PCRF, че изменението на IP-CAN сесията не е разрешено или че са загубени носещите ресурси, заделени за сесия, което води до преход в състояние IPCANIdle.

Чрез ТMBMS = (SMBMS, АctMBMS, →MBMS, s0MBMS) се означава LTS, представяща модела на

IP-CAN сесия, поддържан от MBMS GW, където: - SMBMS = { IPCANIdle, WaitForPCCRules, ResourceReservation, SessionActive,

ResourceRelease, WaitForTermAck}; - Act MBMS = { sessionStart, pccRules, ipCanBearerEstablishment, sessionStop, sessionCancel,

ipCanBearerRelease, ipCanSessionTermAck, ipCanBearerFailed, ipCanBearerLost };

- → MBMS = { IPCANIdle sessionStart WaitForPCCRules ( MBMS1τ ),

WaitForPCCRules pccRules ResourceReservation ( MBMS2τ ),

WaitForPCCRules sessionCancel IPCANIdle ( MBMS3τ ),

ResourceReservation ipCanBearerEstablishment SessionActive ( MBMS4τ ),

ResourceReservation sessionCancel IPCANIdle ( MBMS5τ ),

ResourceReservation ipCanBearerFailed IPCANIdle ( MBMS6τ ),

SessionActive sessionCancel ResourceRelease ( MBMS7τ ),

SessionActive sessionStop ResourceRelease ( MBMS8τ ),

SessionActive ipCanBearerLost IPCANIdle ( MBMS9τ ),

ResourceRelease ipCanBearerRelease WaitForTermAck ( MBMS10τ ),

WaitForTermAck ipCanSessionTermAck IPCANIdle ( MBMS11τ )};

- s0 MBMS = { IPCANIdle }.

Моделът, поддържан от PCRF, който отразява състоянието на носещите ресурси за сесия за излъчване, включва следните състояния. В състояние ResourceNull няма заделени носещи ресурси за MBMS сесия. Когато BM-SC изпрати информация за сесията, PCRF обвързва сесията с параметри в IP-CAN и състоянието става IPCanSession. В състояние

45

IPCanSession PCRF може да приеме заявка за изменение на IP-CAN сесия и да я обвърже с приетата информация за MBMS сесията. В състояние ResourceAuthorizing PCRF взема решение за носещи ресурси, които трябва да се резервират за сесията и изпраща инструкции към MBMS GW. При приемане на потвърждение от PCRF се изпълнява преход в състояние ResourceAuthorized. В това състояние са резервирани ресурси за сесията и предаването на MBMS данни може да започне. Когато MBMS GW открие, че IP-CAN сесията завършва, към PCRF се изпраща известяване. В случай на активен абонамент PCRF може да извести BM-SC за събитието. Ресурсите, заделени за MBMS сесията. се освобождават и се изпълнява преход към състояние ResourceNull state. В състояние ResourceAuthorizing PCRF може да откаже изменението на IP-CAN сесията. Освен това по време на предаване на MBMS данни може да се докладват проблеми с QoS от MBMS GW и това да повличе на таксуването в реално време. В случай, че MBMS GW докладва за загуба на всички носещи ресурси, заделени за MBMS сесия, се изпълнява преход в състояние ResourceNull.

Чрез ТPCRF = (SPCRF, АctPCRF, →PCRF, s0PCRF) се означава LTS, представяща въждането

на PCRF за състоянието на носещите ресурси за сесията: - SPCRF = { ResourceNull, IPCanSession, ResourceAuthorizing, ResourceAuthorized}; - Act PCRF = { sessionInfo, ipCanSessionModification, provisionAck, provisionNonAck,

ipCanSessionTermination, ipCanBearerRemoved, ipCanSessionCancel }; - → PCRF = { ResourceNull sessionInfo IPCanSession ( PCRF

1τ ), IPCanSession ipCanSessionModification ResourceAuthorizing ( PCRF

2τ ), IPCanSession ipCanSessionTermination ResourceNull ( PCRF

3τ ), ResourceAuthorizing provisionAck ResourceAuthorized ( PCRF

4τ ), ResourceAuthorizing ipCanSessionCancel ResourceNull ( PCRF

5τ ), ResourceAuthorizing provisionNonAck ResourceNull ( PCRF

6τ ), ResourceAuthorized ipCanSessionCancel ResourceNull ( PCRF

7τ ), ResourceAuthorized ipCanBearerRemoved ResourceNull ( PCRF

8τ )}; - s0

PCRF = { ResourceNull }. Твърдение 5: Системите ТMBMS и ТPCRF са в релация на слабо поподобие. Доказателство 5: Нека чрез UMP се означи следната релация между състоянията на

ТMBMS и ТPCRF: UMP = {(IpCANIdle, ResourceNull),

(WaitForPCCRules, IpCanSession), (ResourceReservation, ResourceAuthorizing), (SessionActive, ResourceAuthorized)}.

Идентифицира се хомоморфизъм HMP= {fi}, i=7 между действията на ТMBMS и ТPCRF на база функционално проектиране, където

f1: sessionStart→sessionInfo, f2: pccRule→ipCanSessionModification, f3: ipCanBearerEstablishment→provisionAck, f4: sessionStop→ipCanSessionTermination, f5: sessionCancel→ipCanSessionCancel,

46

f6: ipCanBearerFailed→provisionNonAck, f7: ipCanBearerLost→ipCanBearerRemoved.

За състоянията в UMP са в сила следните преходи: При иницииране на MBMS сесия (f1): За MBMS

1τ ∃ PCRF1τ .

При заявка за модифициране на IP-CAN сесия (f2): За MBMS2τ ∃ PCRF

2τ . При разрешение за модифициране на IP-CAN сесия (f3): За MBMS

4τ ∃ PCRF4τ .

При завършване на MBMS сесия (f4): За MBMS7τ , MBMS

10τ , MBMS11τ ∃ PCRF

7τ . При отказ за модифициране на IP-CAN сесия (f6): За MBMS

1τ ∃ PCRF6τ .

При загуба на всички носещи ресурси по време на излъчване (f7): За MBMS8τ ∃ PCRF

6τ . При прекъсване на излъчването от приложение по време на резервиране на ресурси (f5): За MBMS

5τ ∃ PCRF7τ .

При прекъсване на излъчването от приложение по време на оторизиране на ресурси (f5): За MBMS

3τ ∃ PCRFS3τ .

При прекъсване на излъчването от приложение по време на излъчване (f5): За MBMS

7τ , MBMS10τ , MBMS

11τ ∃ PCRFS8τ .

Следователно ТMBMS ~ТPCRF т.е. те излагат еквивалентно поведение. По аналогичен начин чрез формално описание на моделите и използване на релации

на биподобие е доказано, че моделите, отразяващи виждането на приложението, BM-SC, MBMS, PCRF и CDF са синхронизирани и излагат еквивалентно поведение.

Шеста глава Изследване на архитектури, ориентирани към услуги, в

комуникации от машинен тип

6.1 Модели на мобилен мониторинг в комуникации от машинен тип В авторска публикация [A27] е предложена архитектура за мобилен мониторинг,

която може да се приложи в различни функционални области и са идентифицирани ос-новни функции, които включват регистриране, мениджмънт на М2М устройства, доклад-ване на местоположението и на направените измервания, и известявания. Представен е метод за синтезиране на уеб услуги за мобилен мониторинг.

Целта на мениджмънта на неизправности и мениджмънта на работоспособността е да се предприемат коригиращи мерки, за да гарантират непрекъснатост на услугата. Мениджмънтът на неизправности се прилага за откриване на неизправности, отнасящи се до всички софтуерни и хардуерни компоненти на устройството. Мениджмънтът на работоспособността наблюдава показателите на мониторинга.

Интерфейсът за управление на интегритета предоставя функции, които гарантират, че приложенията в мобилен агент (МА) и в управляваща единица (CU) няма да бъдат претоварени от прекомерен брой на заявките. Интерфейсът, поддържан от МА, осигурява операции за стартиране и прекратяване на докладванията за натоварването на неговите приложения, и за запитване за натоварването. Интерфейсът, поддържан от CU, осигурява операции за докладване на натоварването на приложения в устройството.

47

Интерфейсите за мениджмънт на наличността обменят информация, която оказва влияние на интегритета на М2М приложения в мрежата (напр. в CU) и в устройството. Интерфеисите включват операции за стартиране и прекратяване на докладвания за наличност на приложение и за докладване за наличност на М2М приложение.

Интерфейсите за мениджмънт на неизправности обменят информация за работния статус на М2М приложения в мрежата и устройство. Мрежово приложение може да открие, че има грешка в М2М приложение на устройството (напр. с използване на механизма за проверка на наличността) и да го информира за това. Възможно е приложение в М2М устройство да изиска от мрежово приложение да направи тест за активност, тъй като не е получило отговор на предишна заявка.

Фиг.6.1 показва клас диаграмата на интерфейсите, поддържани от приложения в М2М устройство (например от МА).

Фиг.6.1. Интерфейси, поддържани от мобилен агент (М2М устройство)

Фиг.6.2 показва клас диаграмата на

интерфейсите, поддържани мрежово при-ложение (например в CU).

Целта на мениджмънта на неиз-правности и мениджмънта на работо-способността е да се предприемат кориги-ращи мерки, за да се гарантира непре-къснатост на обслужването. Менидж-мънтът на неизправности се прилага за откриване на неизправности, отнасящи се до всички софтуерни и хардуерни компоненти на устройството. Менидж-мънтът на работоспособността наблюдава техническите показатели.

Интерфейсът за управление на инте-гритета предоставя функции, които гаран

Фиг.6.2. Интерфейси, поддържани от управляваща единица (мрежов сървър)

тират,че приложенията в МА и CU няма да бъдат претоварени от прекомерен брой на заявките. Фиг.6.3 моделира комуникацията при абониране, задържане и възстановяване на известяването за МА на базата на локална политика, като резултат от откриване на претоварване.

48

Фиг.6.4 показва модела на състоянията на мениджъра на натоварването в MA. В състояние Active може да бъде получена информация за натоварването. В състояние NotificationSuspended докладванията за натоварването за подтиснати, например поради претоварване на приемащата страна.

Фиг.6.3. Мениджмънт на натоварването: стартиране, задържане и възстановяване на

докладвания за натоварването на М2М устройство

Фиг.6.4. Модел на мениджър на натоварването в МА

Моделът на състоянията на M2M устройство от гледна точка на мениджмънта на

неизправностите е показан на фиг.6.5.

49

Фиг.6.5. Модел на работно състояние на МА

Изследванията върху методи за синтезиране на уеб услуги за менуджмънт на М2М устройства са публикувани в авторски публикации [A28] и [A29].

Достъпът до бази данни (например данни от измерва-ния при мобилен мониторинг), който се осигурява от прило-жен сървър, трябва да бъде защитен. На ниво приложения, основните функции за сигур-ност и мениджмънт на интег-ритета на уеб услугите включ-ват:автентикация, оторизация-та, и защита срещу отричане.

В допълнение към тра-диционните функции за достъп до данни, поддържани от сис-темите за управление на бази данни, отвореният достъп до данни от измервания включва функции за мениджмънт на абонамента за събития, свър-зани с данните и известявания. Фиг.6.6 показва общите функ-ции за достъп до данни от измервания в система за мобилен мониторинг.

Фиг.6.6. Функции за разширен достъп до данни от измервания

На фигурата с дебел контур са означени новите функции. 6.2 Метод за управление на натоварването на шлюз, осигуряващ уеб услуги Предложеният в четвърта глава метод за моделиране на сървър, предлагащ

възможности на услуги, е разширен за уеб услуги. Използваемостта на шлюза на базата данни е оценена като функция на броя на доставчиците на приложения и гарантираните скорости, които може да са част от споразумението за нивото на обслужване (SLA). Гарантираните скорости на брой съобщения за секунда са включени в четири различни

50

споразумения за обслужване. Стойностите на максималните скорости на генериране на съобщения са ограничени от капацитета на шлюза на базата данни.

Резултатите от симулацията са обобщение в Табл.6.1.

Табл.6.1 Използваемост на шлюз за отворен достъп до бази данни

АPs SLA1 {40,18, 6,10}

SLA2 {60, 27, 9,15}

SLA3 {80,36, 12, 20}

SLA4 {90,42,14, 20}

16 0,48117 0,55989 0,64582 0,67225 18 0,56003 0,63892 0,71052 0,75730 20 0,61485 0,71056 0,79056 0,83024 22 0,67582 0,78321 0,87061 0,90745 24 0,73712 0,84809 0,94226 0,99487

6.3 Метод за синтезиране на уеб услуги за енергиен мениджмънт В авторски публикации [A30] , [A31] и [A32] е представен метод за синтезиране на

уеб услуги за енергиен мениджмънт. Методът включва модели на данни и операции на интерфейси. Данните са структурирани като ресурси и са организирани в дървовидни структури. Ресурсите може да се манипулират с четири основни операции: създаване на ресурс, извличане на стойност на атрибут, изменение на стойност на атрибут и изтриване на ресурс.

Дефинирани са ресурси, представящи разписани, съгласно които се прилага управ-ление на мощността, както и ресурси, отразяващи състоянието на управляваното уст-ройство.

Мрежово приложение разглежда устройството като ресурс, чийто състояния може да се манипулират. Фиг.6.7 показва структурата на ресурс, представящ състоянията на устройство. Ресусът airconState е управляван обект, дефиниран за управление на пове-дението на устройство. Този ресурс има атрибут currentState, който представя текущото състояние на устройството, и общи атрибути като accessRightID, creationTime, lastModi-fiedTime. Операциите, които предизвикват преход от едно състояние на устройството в друго са представени като ресурс stateAction, който е подресурс на ресурса airconState. Изпълнението на действие става с UPDATE на съответния ресурс, представящ действие-то.

За да се проследяват абонаментите за изменение на температурата, е дефиниран ресурсът subscriptions, който е подресурс на ресурса temperature. Когато устройството премине в състояние GoingToRef, се създава ресурс абонамент tempRef който представя активен абонамент за изменения в температурата. Ресурсът абонамент съдържа атрибути, необходими за приемане на известяване за достигане на еталонната температура. Когато устройството е в състояние GoingToEcon, съществуващият ресурс абонамент tempRef се изтрива и се създава ресурс абонамент tempEcon за известяване, че е достигната икономичната температура. При преминаване на устройството в състояние ReturningToRef съществуващият ресурс абонамент tempEcon се изтрива и се създава ресурс абонамент tempRef за известяване, че е достигната еталонната температура.

Фиг.6.8 показва модела на данни за конфигуриране на статични и динамични разписания за ползване на електроенергия. Информацията в разписанията може да бъде статична и динамична.

51

Фиг.6.7 Структура на ресурс, представящ състоянието на управляемо устройство

Статичната информация е за до 4 сезона. Всеки ресурс seasonX, където X е от 1 до 4, съдържа подре-сурси, представящи дневни разпи-сания. Всеки ресурс dailyScheduleY, където Y може да е от 1 до 4, съдържа подресурси, представящи интервали от денонощието. Всеки ресурс dailyPeriodZ, където Z може да е от 1 до 4 има атрибути. В допълнение към общите атрибути, дефинирани в стандартите за всички ресурси, ресурсът dailyPeriodZ дефинира и следните специфични атрибути: periodBeginHour, period-EndHour и price, отнасящи се до началото, края на периода и тарифата на енергията. Ресурсът dynamicTier дефинира динамично конфигурирани разписания. Всеки ресурс critical-PeakPeriodX динамично конфигури-рани периоди на върхово натовар-ване.

<sclBase>:http://homeApplianceControl.utilityA.com

scls

airconXXX

mgmtObjs

schedulesConf

seasonX

dailySchedules

dailyScheduleY

dailyPeriods

dailyPeriodZ

NSCL

staticSchedule

seasons

dynamicTier

criticalPeakPeriods

criticalPeakPeriod

Фиг.6.8. Структура, моделираща статични и динамични разписания

Прави се допускането, че ин-формационната система за интели-гентно отчитане поддържа предпла-тено ползване на електроенергия. В този случай дефиницията на ресурса schedulesConf се разширява, както е показано на фиг.6.9(а). Добавен е ресурсът prepaidProfile, като подресурс на ресурса dailyPeriodZ. Ресурсът prepaidProfile се използва за конфигуриране на предварително дефиниран обем електроенергия или за определен период от време. Ресурсът consumption има атрибути consumptionThreshold, който посочва обема електроенергия, който може да се използва за определен период от време. Ресурсът time има атрибут timeThreshold, който посочва максималното време за консумиране на енергия за всеки период от денонощието.

52

По аналогичен начин ресурсът prepaidProfile се дефинира като подресурс на criticalPeakPeriod и дефинира ограниченията за ползване на енергия при върхово натоварване, както е показано на фиг.6.9(б).

Фиг.6.9 Разширение на модела на разписанията за предплатена консумация

За да се наблюдава консумацията на електроенергия в реално време, е необходимо

да се дефинират управлявани обекти, които определят прагове за изпращане на известия при определени условия. Такива условия включват например достигане на прагови стой-ности при консумирането на енергия. Тези условия се дефинират за всеки предварително конфигуриран период от денонощието.

Например ресурсът consumptionDailyPeriodZDailyScheduleYSeasonXTrapEvent се дефинира като ресурс от тип управляван обект, както е показано на фиг.6.10. Ресурсът consumptionDailyPeriodZDailyScheduleYSeasonXTrapEvent дефинира условия за известя-ване при достигане на определен обем консумирана енергия по време на периода от денонощието Z, дефиниран в дневно разписание Y на сезон X. Подресурсът trapInstance съдържа информация за едно условие trapEvent, изискващо за известяване. Атрибутът trapID описва значението на условието. Атрибутът eventOccured посочва наличието на условие. NSCL трябва да бъде известен при появата на такова условие и на свой ред да информира smPaymentMgmt NA с използване на този атрибут. Атрибутите trapEven-tEnable и trapEventDisable съответно разрешават и забраняват режима на известяване, което предпазва мрежата от претоварване с известявания. За да се следят абонаментите за ресурса consumptionDailyPeriodZDailyScheduleYSeasonXTrapEvent, е дефиниран ресурс subscriptions, който е съвкупност от абонаменти. В случай на предплатена консумация, при достигане на определени прагове може да се изключат управляеми устройства и дори да се спре захранването.

Табл.6.2 обобщава интерфейсите и съответните им операции на уеб услугата Appliance Power Control, която прилага управление на мощността на електрически уреди.

53

Фиг.6.10. Дървовидна структура за конфигуриране на събития, свързани с наблюдението

на изразходваната енергия, които изискват известяване Изследванията върху уеб услуги за предплатено използване на енергия са

представени в авторски публикации [A33] и [А34]. Оценен е потенциалът на управлението на мощността, което може да се предложи с

механизма, описан във втора глава, и дефинираните уеб услуги. Методът за оценяване се базира на известна методология, свързана с термалните и мощностните характеристики на определен дом. Направено е сравнение на два случая: a) по-високотемпературни интервали от 21°C (еталонна темепратура) за периода от 6:30-9:00 ч. и 17:30-22:00 ч., докато за останалото време от деня по-ниска температура от 20°C (икономична температура); b) постоянна температура от 22°C. Допуска се, че средностатистическо помещение е с размери 3x4x2.5 m с два прозореца, всеки с размери от 2.3 m2, и е оборудвана с устройство за отопление и охлаждане с мощност 5kW, с ефективност 75% хистерезис на устройството от 1°C. Термалната проводимост на стените от тухли и прозорците е около съответно 1 и 5 W/m2K. Допуска се също, че типичен образец на зимни температури е този, представен на фиг.6.11.

54

Табл.6.2 Интерфейси и операции на уеб услугата Appliance Power Control

Интерфейси Поддържани операции HTTP метод AirconStateMgmt createState POST retrieveState GET modifyState PUT deleteState DELETE StateActionMgmt createStateAction POST executeStateAction PUT deleteStateAction DELETE TemperatureMgmt createTemp POST retrieveTemp GET modifyTemp PUT deleteTemp DELETE TempSubscMgmt getTempSubs GET updateTempSubs PUT RefTempSub createRefTemp POST retrieveRefTemp GET modifyRefTemp PUT deleteRefTemp DELETE RefTempNotification refTemperature PUT tempError PUT EconTempSub createEconTemp POST retrieveEconTemp GET modifyEconTemp PUT deleteEconTemp DELETE EconTempNotification econTemperature PUT tempError PUT

Процесът на охлаждане е съгласно закона на Нютон и общата термална маса CT на

помещението е около 107 J/K. T′(t) = A ΔT + B P(t) (6.1) където ΔT=Tr(t)–Te(t) е разликата между температурата в помещението и външната температура, A = -3.6 x 10-6 s-1, при условие, че термалната проводимост е около 36 W/K и B = 7.5 x 10-8 K/J. На фиг.6.12 и фиг.6.13, е показана температурата във времето и консумацията на енергия, ако се прилага управление на мощността.

Допустимият дискомфорт на обитателите на дома от по-ниската температура води до намаление на консумацията на енергия и отместване във времето. За да се оцени ефектът в по-голям мащаб нека се допусне, че населението е около 600000; процентът на домакинствата с интелигентни уреди е 5%; разумна хипотеза за очаквано прилагане на управлението на мощността е 20%. При оценен ефект за едно домакинство дневната консумация на енергия за дните от понеделник до петък е съответно 25 и125 MWh с прилагане и без прилагане на управлението на мощността. За сравнение може да се вземе кампанията в Деня на замята, която е довела до съхранение на около 56 MWh (CEZ България, 2012).

55

Фиг.6.11. Средна температура, измерена по часове на денонощие (01-Jan-2014; Lon: 42.6795551; Lat: 23.2916345; source: forecast.io)

Фиг.6.12. Температура (a – без управление на мощността, b – с управление на мощността)

Фиг.6.13. Консумирана мощност (a – без управление, b – с управление)

Заключение

Предложените модели и методи са опит за повишаване на гъвкавостта при създаване на М2М платформи, базирани на облачни технологии за свързване и интегриране на устройства и приложения.

Получените резултати с научен принос може да се обобщят по следния начин: • Синтезиран е метод за трансформиране на данни от свързани устройства в

информация, т.е. добавяне на качествен контекст към данни, и последващ анализ на информацията, който подпомага процеса на вземане на решение, т.е.

56

превръщането й в знание. Методът включва контекстно свързани модели на наблюдение и въздействие, които надграждат онтологичния модел на физическа система. Идентифицираните в моделите понятия, роли и връзки се описват по формален начин с дескриптивна логика. Методът за семантично моделиране и структуриране на данни е насочен към повишаване на гъвкавостта при събиране, предаване, съхранение и анализ на данни от свързани в мрежа устройства;

• Създаден е метод за формална верификация на контекстно свързани модели на наблюдение и въздействие на устройства. Методът се базира на: (1) синтезиране на детерминирани крайни автомати в устройството и мрежата; (2) идентифициране на хомоморфизъм между действията на автоматите; и (3) установяване на релация на биподобие между моделите. Прилагането на метода е основа за генериране на тестови ситуации, с цел доказване съответствие или липса на такова между дадена реализация и нейната спецификация.

• Формализиран е метод за трансформиране на контекстно знание в автономно поведение, което включва формулиране на цел, формулиране на проблем, търсене на решение и изпълнение на действия. Формулирането на целта е на базата на изследване на текущата ситуация, формулирането на проблем включва определяне на преходи и състояния, които трябва да доведат до целта, търсенето е в пространство на решенията чрез проверяване на различни последователности от действия и след намиране на решение идентифицираните действия се изпълняват.

• Дефиниран е математически модел на сървър на възможности на услуги, в който чрез набор от уравнения са изразени детайли относно разпределянето на трафичните потоци, генерирани от приложения в мрежата и устройствата. Моделът е използван за оценка на технически параметри, свързани с разгръщането на възможностите на услуги в мрежата, и може да се използва при дефиниране на споразумението за нивото на обслужване с доставчиците на приложения.

• Идентифицирани са изискванията към функции за управление на качеството на обслужване за връзки на устройства и е синтезиран метод за достъп до функции за управление на качеството на обслужване в комуникации от машинен тип, който поддържа цялата налична функционалност за резервиране на ресурси с използване на политики и наблюдение на използването на ресурси. Методът осигурява абстракция чрез модели на състояния на сесии и чрез приложни програмни интерфейси, които са независими от носещата мрежа и осигуряват гъвкавост при програмиране на функции за управление на качеството на обслужване.

Приносите с научноприложен характер може да се обобщят както следва: • Моделирани са услуги за енергиен мениджмънт, представящи целенасоченото

използване на информацията под формата на знание. Описанието на услугите е формализирано чрез детайлизиране и използване на контексти.

• Изследвани са функции за отдалечен мениджмънт на устройства и енергиен мениджмънт, като са дефинирани контексно свързани модели, чието описание е формализирано и верифицирано.

57

• На базата на контесно обвързано знание е моделирано автономно поведение за мениджмънт на регистрационното състояние на устройства, мениджмънт на свързаността и управление на мощността на електрически уреди.

• Анализирани са изискванията на приложения в различни случаи на използване и са идентифицирани общи функции, свързани с достъп до контекстно обвързана информация за свързани устройства, мениджмънт на устройства и управление на трансакциите. Идентифицираната функционалност е основа за повишаване на оперативната съвместимост и дава възможност за многократно използване.

• Синтезирани са модели на данни, които са специфични за приложната област. Данните са моделирани като ресурси, чието състояние може да се манипулира с прости примитиви за създаване, извличане, изменение и изтриване. Ресурсите са организирани в дървовидни структури, като всеки ресурс е уникално адресируем.

• Изследван е метод за отдалечено конфигуриране на свързани устройства чрез излъчване на съдържание и управление на качеството на обслужване. Методът включва моделиране на състоянията на сесия за излъчване, поддържани от различни мрежови функции и от приложение, и формално доказателство за синхронизация между моделите.

• Синтезирана е процедура за изграждане на дървовидни структури от ресурси, моделиращи данни за мениджмънт на ресурси. Процедурата е използвана за моделиране на данни за енергиен мениджмънт и предплатената консумация на енергия.

• Методът за моделиране на сървър, предлагащ възможности на услуги, е разширен за уеб услуги. Като допълнение към управление на достъпа е моделиран и разпределен капацитет с балансиране на натоварването и е приложена стратегия за динамично преразпределяне на неизползван капацитет.

• Идентифицирани са основни функции на система за мобилен мониторинг и отворен достъп до данни от измервания. Синтезирани са методи за дефиниране на уеб услуги за мобилен мониторинг и достъп до данни от измервания.

• Функционалността за мобилен мониторинг е разширена с функции за мениджмънт на приложенията в устройство и в мрежата, като ударението е върху мениджмънт на неизправности и работоспособност, които са необходими за нормалната работа. Функциите за достъп до бази данни са разширени с мениджмънт на абонамента и известяване за събития, свързани с данните.

Приносите с приложен характер може да се обобщят както следва: • Разширен е LWM2M моделът на устройство с данни за сензори и въздействащи

механизми, които може да се използват в контекстно свързани модели за наблюдение и въздействие;

• Дефинирани са интерфейси на уеб услуги за основни възможности на услуги, както и специфични такива. Интерфейсите на уеб услугите осигуряват функции за манипулиране на състоянията на ресурсите само с четири основни операции, а именно създаване, изтриване, извличане и изменение. Дефинирани са операции, с които се реализират функциите и е направено функционално проектиране на операциите върху HTTP методи.

58

• Моделирани са услуги за енергиен мениджмънт и предплатено таксуване за консумирана на електроенергия, които използват дефинираните уеб услуги.

Списък на авторски публикации към дисертационния труд

[А1] Atanasov, I., A. Nikolov, E. Pencheva. “Ontology Based Data Model for Power Control in Smart Homes,” Proc. of Int. Conference on Information, Communication and Energy Systems and Technologies, ICEST’2015, Sofia, Bulgaria, 2015, pp.6-9.

[А2] Atanasov, I., A. Nikolov, E. Pencheva. “An Approach to Transform Internet of Things Data into Knowledge,” Int. Journal of Embedded Systems, Special issue on: “Advanced Mobile Cloud Computing and Internet of Things Systems and Networking,” ISSN 1741-1068, in press (SCOPUS SJR [2015]: 0.252).

[А3] Atanasov, I. “Knowledge Building for Home Energy Saving Domain,” Int. Journal of Computer Science and Mobile Computing, vol. 3, issue 12, 2014, pp. 376-383, ISSN 2320-088X

[А4] Atanasov, I. “Knowledge Based Interaction of Smart Metering Service Capabilities,” Int. Journal of Knowledge Based Computer Systems, vol. 2, issue 2, 2014, pp. 28-36, ISSN 2321-5623

[А5] Atanasov, I., A. Nikolov, E. Pencheva. “Knowledge Management of Innovative Service for Power Control,” Int. Journal on Information Technologies & Security, IJITS, 2015, No 2, pp. 2-16, ISSN 1313-8251.

[A6] Atanasov, I. “Aspects of Autonomous M2M Device Management,” Journal Electrotechnica & Electronica, E+E, 2016, vol.51, No 1-2, pp. 17-24.

[A7] Nikolov, A., I. Atanasov, E. Pencheva. “Formal Verification of Connectivity Management Models in M2M Communications,” Proc. of IEEE Int. Black Sea Conference on Communications and Networking, BlackSeaCom’2016, Varna, Bulgaria, 2016, pp.1-4.

[А8] Atanasov, I., A. Nikolov, E. Pencheva, R. Dimova, M. Ivanov. “An Approach to Data Annotation for Internet of Things,” Int. Journal of Information Technology and Web Engineering, 2015, vol.10, No.4, pp.7-25, ISSN 1554-1045 (SCOPUS SJR [2015]: 0.127).

[A9] Atanasov, I., A. Nikolov, E. Pencheva. “An approach to Transformation of Data into Knowledge for Power Control in Smart Homes,” Int. Journal of Reasoning-based Intelligent Systems, in press, ISSN 1755-0564 (SCOPUS SJR [2015]: 0.142).

[А10] Atanasov, I. “An Extension of OMA M2M Device Management”, Proc. of Int. Scientific Conference Electronica’2014, Sofia, Bulgaria, 2014, pp.187-194.

[А11] Atanasov, I. “Semantic Data for Device Management in M2M Communications,” Proc. of Int. Conference on Information Technologies InfoTech’2014, Varna, Bulgaria, 2014, pp. 107-114.

59

[А12] Atanasov, I., E. Pencheva. “A functional model extension of OMA device management,” Journal of Electrotechnica & Electronica, Е+Е, vol.49, No 3-4, 2014, pp. 34-41, ISSN 0861-4717.

[A13] Atanasov, I., E. Pencheva. “Design of M2M Service Capability for Access to Location Information,” in Proc. of INASE Int. Conference on Recent Advances in Computer Science, Zakynthos, Greece, 2015, pp.394-399.

[A14] Nikolov, A., E. Pencheva, I. Atanasov. “Access to Mobility Information in M2M Communications,” Proc. of Int. Conference on Information, Communication and Energy Systems and Technologies, ICEST’2015, Sofia, Bulgaria, 2015, pp.2-5.

[A15] Atanasov, I., E. Pencheva. “Design of M2M Device Reachability Service Capability,” WSEAS Trans. on Communications, accepted, ISSN 1109-2742. (SCOPUS SJR [2015]: 0.119).

[A16] Atanasov, I., A. Nikolov, E. Pencheva. “Design Aspects of Web Services for M2M Device Fault and Performance Management,” Proc. of IEEE Int. Conf. on Telecommunications in Modern Satellite, Cable and Broadcasting Services, TELSIKS’2015, Nish, Serbia, 2015, pp.289-292. (SCOPUS Code 118712).

[A17] Atanasov, I. “Design Aspects of Autonomous Advanced Metering Infrastructure,” Proc. of INASE Int. Conference Recent Advances in Environmental and Earth Sciences and Economics’2015, Zakynthos, Greece, 2015, pp. 324-328.

[A18] Atanasov, I. “Machine-to-Machine Transaction Management,” Journal on Computer and communications engineering, 2014, vol.8, №1, pp.54-58, ISSN 1314-2291

[A19] Atanasov, I., M. Ivanov, E. Pencheva. “Evaluation of Application Level Mechanism for Reliable Smart Objects Communications,” Proc. of Int. Conference on Information, Communication and Energy Systems and Technologies, ICEST’2014, Nish, Serbia, 2014, vol. 1, pp. 67-70.

[A20] Atanasov, I. “Analysis on Autonomic Characteristics of Quality of Service Management in EPS,” Proc. of Int. Conference on Information, Communication and Energy Systems and Technologies, ICEST’2015, Sofia, Bulgaria, 2015, pp.197-190.

[A21] Atanasov, I., E. Pencheva, A. Nikolov. “Study on Generic Functionality for Quality of Service Control on M2M communications,” Proc. of IEEE Int. Black Sea Conference on Communications and Networking, BlackSeaCom, Varna, Bulgaria, 2016, pp. 1-5.

[A22] Atanasov, I., A. Nikolov, E. Pencheva. “Model Aspects of Quality of Service Management in Machine to Machine Communications,” Journal of Information Technologies and Control, 2016, accepted.

[A23] Pencheva , E., I. Atanasov, R. Dimova. “External Network Control on Quality of Service of M2M Mission-Critical Applications in 4G,” Proc. of IEEE Mediterranean Electrotechnical Conference, MELECON’2016, Intelligent & Efficient Technologies & Services for the Citizen, Limassol, Cyprus, 2016, pp.1-5.

[A24] Atanasov, I., E. Pencheva, R. Dimova. “Toward open service access to policy and charging control in evolved packet system,” Telecommunications Systems, Springer,

60

2015, vol. 59, no. 3, pp. 365-380, ISSN 1018-4864 (Thomson Reuters Journal IF [2015]: 0.822)/ (SCOPUS SJR [2015]: 0.566)

[A25] Atanasov, I., E. Pencheva. “Third Party Control on Multimedia Message Broadcast Services in EPS,” Annual Proceedings of Technical University of Sofia, vol. 65, book 2, 2015, pp.19-28, ISSN 1311-0829

[A26] Atanasov, I., E. Pencheva. “Model Aspects оf Open Access to Multimedia Broadcast Services in the Evolved Packet System, Int. Journal of Digital Multimedia Broadcasting,” 2016, Article ID 3154801, pp. 1-13, ISSN 1687-7578 (Indexed in Thomson Reuters’ Web of Science) / (SCOPUS SJR [2015]: 0.144).

[A27] Pencheva, E., I. Atanasov. “Engineering of Web Services for Internet of Things Applications,” Information Systems Frontiers, Springer, 2016, vol.18, no.2, pp.277-292, DOI 10.1007/s10796-014-9532-3, ISSN 1387-3326 (Thomson Reuters Journal IF [2015]: 1.45) / (SCOPUS SJR [2015]: 0.756)

[A28] Atanasov, I., N. Krastanov, E. Pencheva. “An Approach to Design Web Services for Remote Entity Management”, Proc. of Int. Conference on Information, Communication and Energy Systems and Technologies, ICEST’2014, Nish, Serbia, 2014, vol. 1, pp. 71-74.

[A29] Atanasov, I., A. Nikolov, E. Pencheva. “Design of REST Web Services for Energy Management in Smart Metering Information Systems,” Annual Proceedings of Technical University of Sofia, vol.65, book 2, 2015, pp.9-18, ISSN 1311-0829

[A30] Atanasov, I., M. Ivanov, A. Nikolov, R. Dimova, E. Pencheva. “Towards Web Services for Power Control,” Int. Journal on Information Technologies & Security, IJITS, 2014, no.4, pp. 3-16, ISSN 1313-8251

[A31] Atanasov, I. “Resource structure for smart metering systems supporting prepaid functionality,” Journal of Electrotechnica & Electronica Е+Е, vol. 49, № 9-10, 2014, pp. 18-24, ISSN 0861-4717

[A32] Atanasov, I. “Structure of Semantic Information for Prepaid Smart Metering,” Proc. of IEEE Int. Conf. on Telecommunications in Modern Satellite, Cable and Broadcasting Services, TELSIKS’2015, Nish, Serbia, 2015, pp.293-296. (SCOPUS Code 118712)

[A33] Atanasov, I., “Modeling Aspects of Autonomous Smart Metering Information Systems,” Int. Journal on Information Technologies & Security, IJITS, vol.8, No 1, 2016, pp.3-17, ISSN 1313-8251

[A34] Atanasov, I., A. Nikolov, E. Pencheva. “Reducing Energy Consumption by Using Smart Metering Intelligent Systems,” Cybernetics and Information Technologies, vol.16, No 2, pp. 113-124, DOI: 10.1515/cait-2016-0024, ISSN: 1314-4081, (SCOPUS SJR [2015]: 0.17).

61

Prof. Ivaylo Ivanov Atanasov, PhD.

STUDY ON SERVICES AND APPLICATIONS IN MACHINE TYPE COMMUNICATIONS

Abstract

Machine to Machine (M2M) communications allow connected devices like household

appliances, medical devices and cars to share data. Nowadays, the number of connected devices is growing tremendously and the associated services enabled by devices are growing even more rapidly. Services include all of data applications that may be necessary to connect a device over the network. The research focuses on how data gathered by different devices can be transformed into information and how this information is combined, presented and used to make intelligent decisions based upon it.

First chapter provides a review on M2M standards, solutions, and research, applying system-based approach to analysis of information and telecommunication technology used for M2M service provisioning. The analysis determines the research fields and enables formulation of the research objectives and tasks. The main goal is to study the capabilities to improve the service effectiveness in machine type communications and to develop new models and methods for provisioning of generic service capabilities and customized applications.

Second chapter presents research on modeling of semantic information and knowledge generation from data which describe physical systems. Abstraction of raw data is presented as a physical system model, built of things that can be monitored and controlled by targeted applications. The abstraction is context-aware and makes data transformation into information. The service model transforms information into knowledge by identifying generic, reusable functions. Operational semantics is used for formal description of context-aware models and axiomatic semantics to describe knowledge by logical axioms. Service modeling is presented as knowledge management.

Third chapter is dedicated to methods for modeling of applied knowledge. The methods are related to understanding the context (environment) and automatic decision making based on applied and context-aware information. Patterns of autonomous behavior include device registration management, connectivity management and power control of autonomous electrical appliances. Managing and managed objects are modeled as finite automata, which are mathematically described and formally verified. Application knowledge is modeled as autonomous agents that solve domain-specific problems by formulating a goal and problem, seeking for solutions and carring out identified actions.

Fourth chapter presents study on methods for synthesizing of M2M service capabilities that can be shared by different applications. Common functions for access to device location and presence information, fault and performance management are identified and respective operations are defined. Services that use common functions are modeled and formally described by temporal logic. Data models that determine the structure of the data exchanged between M2M applications and other entities in the M2M system are synthesized. The behavior of Service Capability Server is modeled and its throughput is evaluated.

62

Application level aspects of Quality of service (QoS) available on M2M connections are studied in fifth chapter. The analysis of autonomous features of Policy and Charging Control in the Evolved Packet System is the basis for identification of requirements for third party control on QoS. A method for open access to dynamic control on QoS for M2M connections is developed. QoS control is examined in the context of multimedia broadcast service used for remote M2M device configuration.

The research object in the sixth chapter is M2M web services. Service-oriented architecture for mobile monitoring is proposed and generic functions are identified. A method for definition of web services for mobile monitoring and access to measurement data is presented. The method includes definitions of application programming interfaces and data models. The model of Service Capability Server is extended for web services and its utilization is evaluated.

The conclusion summarizes the author’s contributions and outlines the ideas about future research.