Статья коап 5: КоАП РФ Статья 5.1. Нарушение права гражданина на ознакомление со списком избирателей, участников референдума

Содержание

Конституционный Суд РФ проверил конституционность положений части 5 статьи 28.1 КоАП РФ и части 3 статьи 201 АПК РФ

     Конституционный Суд РФ постановлением от 30.03.2021 N 9-П признал часть 5 статьи 28.1 КоАП Российской Федерации не противоречащей Конституции Российской Федерации, поскольку по своему конституционно-правовому смыслу в системе действующего правового регулирования она означает, что по обращению физического или юридического лица, содержащему данные, указывающие на наличие события административного правонарушения (за исключением отдельных правонарушений, перечисленных в этом Кодексе), уполномоченное должностное лицо независимо от того, в каком порядке осуществлялась проверка изложенных в обращении фактов, по итогам которой сделан вывод о недостаточности данных для возбуждения дела об административном правонарушении, выносит мотивированное определение об отказе в возбуждении дела об административном правонарушении.

     Также данным постановлением часть 3 статьи 201 АПК Российской Федерации признана не противоречащей Конституции Российской Федерации, поскольку по своему конституционно-правовому смыслу в системе действующего правового регулирования она не исключает права физического или юридического лица оспаривать (обжаловать) по правилам главы 25 АПК Российской Федерации, действующим во взаимосвязи с положениями Кодекса Российской Федерации об административных правонарушениях, отказ в возбуждении дела об административном правонарушении, вынесенный уполномоченным должностным лицом по обращению этого физического или юридического лица, содержащему указывающие на наличие события административного правонарушения данные, не в виде определения об отказе в возбуждении дела об административном правонарушении, а в иной форме, и в то же время позволяет оспорить такой отказ в порядке главы 24 АПК Российской Федерации в связи с несоответствием его формы требованию части 5 статьи 28.1 КоАП Российской Федерации и предполагает удовлетворение заявления о признании его незаконным в случае, если будет установлено несоблюдение формы отказа.

     Постановление вступает в силу со дня официального опубликования.

8,5 тысячи нарушителей и один труп. Комтранс Петербурга отчитался о работе с нарушителями правил парковки — Авто — Новости Санкт-Петербурга

Как рассказали 19 июля в комитете по транспорту, из 451 случая, до которых инспекторы «дошли ногами», по 78 был составлен протокол об административном правонарушении (ст. 12.16 КоАП РФ), по 373 — о задержании транспортного средства. Постановлений по делам вынесено 364. Если говорить об автоматической фотофиксации, то при 4 тысячах удачных кадров вышло 420 постановлений.

Общие итоги первых трех недель, в которые комитет исполнял новые для него полномочия, выглядят так: 8 579 выявленных нарушений, 1 238 вынесенных постановлений, 0 отмененных протоколов и 76 заявок в дирекцию по организации дорожного движения об устранении замечаний. Цифры растут от недели к неделе: к примеру, с 29 июня по 5 июля было всего выявлено 1 379 нарушений, неделей позже — 2 773, а затем — 4 457.

При этом инспекторы перед эвакуацией проверяют, нет ли в салоне домашних животных или детей. По данным «Фонтанки», ровно неделю назад на Купчинской улице в припаркованной не по правилам иномарке обнаружили тело водителя. «Фонтанка» запросила подробности у пресс-службы МВД.

Комтранс с 29 июня перенял от МВД полномочия по составлению протоколов и рассмотрению административных дел за нарушение правил остановки и стоянки, а также по эвакуации автомобилей. Речь идет об административных правонарушениях, предусмотренных частью 5 статьи 12.16 КоАП, работает комитет в зонах действия дорожных знаков 3.27 «Остановка запрещена» и 3.28 «Стоянка запрещена» с установленной дополнительной табличкой 8.24 «Работает эвакуатор».

Постановление об административном правонарушении выносится в автоматическом и ручном режиме. В первом случае автомобили с автоматической фотофиксацией курсируют по заранее утвержденным маршрутам, интервал — 15–20 минут. Стационарные камеры фиксируют ситуацию раз в минуту. Затем материалы поступают в государственную информационную систему, где автоматически формируется постановление, затем оно направляется адресату по почте.

Кроме того, курсируют пешие инспекторы. Если они видят нарушение, то оформляют протокол задержания транспортного средства и вызывают через диспетчерскую службу эвакуатор. Сотрудник службы эвакуации принимает по акту задержанное авто и увозит на штрафстоянку, которая закреплена за районом.

Подробнее о том, что изменится для автомобилистов и как теперь нарушителям придется вызволять свои машины, читайте в материале «Фонтанки».

Активист из Воронежа пожаловался на преследование полицией из-за надписей «Путин, уходи» и «ПТН ПНХ»

Воронежский активист Никита Головизин рассказал «Открытым медиа» о преследовании со стороны полиции из-за акции «кормления голубей», в ходе которой он выложил на тротуаре зёрнами надписи «Путин, уходи» и «ПТН ПНХ».

Акция состоялась 26 июня, а 19 июля Головизина вызвали в отделение полиции № 6 и составили на него протокол по 5-й части статьи 20.2 КоАП (нарушение порядка проведения митинга — наказывается штрафом или обязательными работами), рассказал ОМ активист. В протоколе, который есть в распоряжении редакции, говорилось, что своими действиями он создал угрозу распространения коронавируса.Фото: скриншот / Свободные люди Воронежа / «ВКонтакте»Уже на следующий день, 20 июля, как утверждает Головизин, одна из сотрудниц полиции попыталась вновь забрать его в отделение, чтобы «поставить всего одну подпись». «Есина София Михайловна отказалась предъявлять удостоверение, ломилась в дверь, использовала моего товарища, чтобы вломиться в квартиру. После безуспешных попыток войти ко мне или выманить меня, она отключила свет на всём этаже. Соседи выходили на неё ругаться. После этого она ждала меня в засаде ещё около двух часов», — рассказал активист. В итоге он вызвал 112 и участкового и написал заявление «по фактам нарушений в ходе её работы и превышения полномочий в виде отключения света».

Так как Головизин уже был оштрафован и дважды отправлен под арест, он предполагает, что полиция должна была составить на него протокол не по пятой, а по восьмой части той же статьи 20.2 КоАП (повторное нарушение правил организации митинга, предусматривающее до 30 суток ареста). «Видимо, сотрудница просто ошиблась [в номере части статьи] и теперь хочет всё переделать, чтобы не получить разворот протокола от суда и нагоняй от начальства», — заключает собеседник ОМ.

За что преследовали Никиту Головизина22 апреля воронежский суд арестовал Головизина на семь суток за повторное нарушение правил организации митинга (ч. 8 ст. 20.2 КоАП) из-за того, что активист расклеивал листовки с текстом «Ну и куда мы пришли с Путиным?» и «Путин вор», на которых были указаны дата и место проведения митинга в поддержку политика Алексея Навального.

Активист объявлял сухую голодовку и требовал его немедленно освободить. Накануне ареста он решил пожаловаться в СК на угрозы со стороны сотрудников полиции и порчу имущества, так как полиция угрожала его матери уголовным преследованием, а также повредила ему дверь и распределительный щиток в подъезде (в тот раз ему тоже отключали свет).

23 января Головизин выходил на акцию в поддержку политика Алексея Навального с флагом Евросоюза, за что был арестован на 5 суток.

Ранее преподаватель Воронежского государственного университета Ирина Каширская подала заявление в прокуратуру после конфликта с Головизиным. Накануне январских митингов она грубо отозвалась о протестующих на своей личной странице в соцсетях и заявила, что если её студенты пойдут на митинг, экзамены у них она будет принимать «без поблажек и снисхождения». В ответ студент написал в комментариях, что Каширская не достойна носить звание преподавателя. После этого она пожаловалась в прокуратуру на оскорбление чести и достоинства. Студенту объявили выговор.

В Пскове полиция изъяла листовки в офисе КПРФ

В Пскове полиция изымает листовки с информацией о кандидатах в областное собрание депутатов Александре Баеве и Дмитрии Михайлове. Свои действия сотрудники полиции называют досмотром. Об этом корреспонденту Север.Реалии сообщил секретарь Псковского городского комитета КПРФ Сергей Богданов.

Он рассказал, что полиция пришла в офис партии после заседания избирательной комиссии области, куда поступило заявление о том, что коммунисты раздают жителям Пскова листовки с незаконной агитацией.

Нарушением закона избирком назвал то, что в буклетах не указано, что они оплачены из средств избирательного счета кандидата. В КПРФ настаивают, что листовки были напечатаны и раздавались задолго до официального старта выборной кампании и, следовательно, на них правила агитации не распространяются.

«Полиция все говорит, что это досмотр, но они изъяли уже все, что нашли. В мае, еще до начала избирательной кампании, мы печатали не агитационные, а информационные листовки. У нас тогда, по весне, стояли палатки по городу, и какая-то часть листовок осталась – штук 50, может. Они были напечатаны вне избирательного периода – тогда не было этого избирательного счета даже», — сказал коммунист Богданов.

Он подчеркнул, что полицейских интересуют только листовки, в которых есть информация про кандидатов Александра Баева и Дмитрия Михайлова. Именно за эти материалы коммунистов и обвиняют в распространении агитационных материалов с нарушением требований законодательства о выборах – статья 5.13 КоАП.

Север.Реалии не удалось получить оперативный комментарий в МВД.

Псковское «Яблоко» 11 июля подало в региональный избирком жалобу на газету «Комсомольская правда»: по мнению партии, в издании с советами «как заниматься жарким сексом в +30» были признаки незаконной агитации во вкладке, которая шла вместе с газетой. Во вкладке была отдельная нумерация страниц и признаки агитации за «Единую Россию». Областной избирком 16 июля отказал «Яблоку» в жалобе: чиновники не нашли нарушений в газете.

Сайт заблокирован?

Обойдите блокировку! читать >

КоАП РФ последняя редакция на 2021 с изменениями. Кодекс об административных правонарушениях с комментариями (ФЗ №195)

В целях реализации конституционных положений в Российской Федерации принят ряд кодифицированных федеральных актов. Одним из них, нормами которого регламентируются определение административной ответственности за то или иное противоправное деяние является КоАП РФ.

Статус КоАП как документа федерального уровня

Данный акт кодификации норм, регулирующих меры ответственности за правонарушения в сфере гражданского и административного законодательства является приемником и продолжателем ранее действующего на территории РСФСР Кодекса 1984 г. Принятый в качестве федерального закона 195-ФЗ, КоАП РФ действует на всей территории страны с 2002 г. с последними внесенными поправками в редакции

от 27.12.2018 г.

Согласно иерархической структуре законодательных актов страны, по статусу выше Кодекса стоят только Конституционные нормы и положения принятых РФ международных договоров в той части, в которой их компетенция пересекается с установлениями КоАП.

Важно. Еще одной особенностью в рассматриваемой иерархии являются правовые коллизии, связанные с положениями Гражданского Кодекса: именно этот акт является по статусу вторым после Конституции в структуре законодательства регулирующего гражданско-правовую сферу общественных отношений – это означает, что нормы ГК будут превалировать над КоАП.

Вместе с тем, будучи актом общефедерального значения, судебные и законодательные органы в отдельных субъектах должны ориентироваться на нормы рассматриваемого Кодекса при разрешении конкретных дел, связанных с правонарушениями в регламентируемой сфере общественных отношений и при принятии собственных законов в данной отрасли.

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

Функция Кодекса об административных правонарушениях

В качестве основополагающего кодифицирующего законодательного акта в сферах административной и административно-процессуальной юрисдикции в Российской Федерации, функцией Кодекса является формирование структуры законотворческой базы и ее иерархии в области административного и частично гражданского права.

Нормами КоАП определяются те акты, которые могут быть приняты федеральными и региональными (а также иногда и местными) органами исполнительной и судебной власти для их дальнейшего исполнения и разъяснения.

Это необходимое условие, чтобы в России эффективно защищались права граждан, предприятий и организаций, а также лиц, состоящих на государственной службе (должностные лица – как отдельная подлежащая ответственности категория) в части, относящейся к решениям и действиям федеральных и местных органов власти.

Для этого в Кодексе об Административных Правонарушениях:

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

Справка. В отличии, например, от Гражданского Кодекса РФ, КоАП является комбинированным актом, совмещающим как нормы материального, так и процессуального права: им регулируется не только не только субъективная ответственность (материальная сторона) виновных в противоправном деянии, но и процесс судебного или административного производства (процессуальная сторона) по такого вида делам.

Специальные административные дела

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

Классифицировать субъектный состав данной категории сложно, так как отдельные лица, в различных ситуациях могут подпадать или не подпадать под определения, указанные в статьях исходя из действия или бездействия – это позволяет индивидуализировать и конкретизировать соответствующую степень вины и более справедливо применить административную санкцию. С определенной условностью к субъектам специальной административной ответственности относятся:

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

Проживающие временно или постоянно на территории России иностранные граждане. Наказания за нарушаемые ими положения законодательства в той мере, в какой оно регулируется данной сферой законодательства, основывается на нормах КоАП и иных законов РФ, если это не противоречит Конституции и принятым на себя страной обязательствам по международным договорам – данное правило закреплено в самом Кодексе, в ст. 2.6. Например, по Конвенциям ООН о праве внешних сношений (Вена 1961 и 1963 гг.) – посольские и консульские работники иностранного государства не подпадают под гражданскую и административную юрисдикцию стран на их территории.
Лица, находящиеся на срочной или контрактной службе в структурах вооруженных сил, МЧС, органов ФСИН и ГУВД, таможенной и пожарной служб.
Отдельные статьи регулируют административную ответственность водителей (собственников транспортных средств), сотрудников торговой сферы и общественного питания, а также лиц, чья деятельность связана с обеспечением здравоохранения, воспитания, развития и образования несовершеннолетних граждан страны.

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

Нарушения в сфере управления и охраны общественного порядка

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

Общественный порядок – нормативно урегулированное взаимодействие отдельных граждан их групп и сообществ в местах общественного скопления, характеризующиеся спокойствием, нормальным функционированием публичных и частных организаций, общественных служб и учреждений (обеспечивающих связь, транспорт и т.д.), нравственным поведением и уважением достоинства и чести личности.

В данном контексте составы неправомерного поведения, нарушающего общественный порядок и способы дисциплинарного и иного административного воздействия на нарушителей, содержатся в части двадцатой главы КоАП.

К таковым относятся нормы, закрепленные в статьях:

20.1 – неуважение к общественному порядку в форме мелкого хулиганства;
20.2 – намеренное и противоправное несоблюдение правил организации массовых публичных мероприятий, так их как демонстрации, митинги или марши;
20.3 – публичное демонстрирование и пропаганда идей, символов и лозунгов организаций экстремистской направленности или иных, запрещенных в стране организаций, а также символов и атрибутов нацистских и террористических формирований
20.4 – действия или бездействия, связанные с невыполнением требований противопожарных мероприятий на рабочем месте или в общественных местах, особенно если это привело к травмам или смертям;
20.18 – блокирование и создание помех в работе транспорта и систем общественных коммуникаций;
20.20 – употребление в общественных местах, запрещенных законом алкоголя или психо-наркотических веществ – перечень мест регулируется ФЗ и включает улицы, транспорт, стадион, образовательные, культурные и детские учреждения, парковые комплексы и иные места общественного пользования;
20.21 – связанное с предыдущим умышленное появление и аморальное поведение лиц в нетрезвом состоянии в общественных местах;
20.22 – расширение применения двух предыдущих связанных статей на несовершеннолетних граждан через наложение взысканий на их родителей;
20.25 – норма предусматривающая ужесточение санкций за неисполнение ранее наложенных предписаний по административному законодательству: невыплата штрафов, невыполнение принудительных работ и т.д.;
20.26 – ответственность, предусмотренная за неосуществление трудовой деятельности работниками (например, в трудовых спорах), деятельность которых обеспечивает ту или иную сферу жизнедеятельности граждан или общественного порядка;
20.31 и 20.32 – регламентирует наказание за несоблюдение общественного порядка зрителями или допущение его нарушений со стороны организаторов открытых спортивных мероприятий и состязаний.

В последнем случае отдельно выделяется категория ответственных должностных лиц, а также организующих мероприятия юридических лиц.

Справка. Иные статьи, формирующие данную главу, относятся к еще одной сфере общественной жизнедеятельности – поддержанию общественной безопасности. Нарушение положений, содержащихся в статьях, имеют более серьезные последствия, и в связи с этим обеспечиваются более строгими взысканиями и штрафными санкциями и наказаниями.

Кто несёт ответственность по нормам КоАП

Как и любой кодифицирующий акт, ФЗ №195 в своей общей части указывает и классифицирует субъекты, подлежащие административным санкциям, подпадающие под действие данной сферы российского законодательства. Этому посвящен ряд статей.

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

Сами же субъекты или лица, обладающие правоспособностью и дееспособностью, а также их административная ответственность, представлены во второй главе – статьи 2.3 – 2.6.2 и 2.10.

К таковым относятся:

Физические лица – вступившие в правоспособный и дееспособный возраст граждане, иностранцы и лица, не имеющие гражданства, проживающие на территории России – также в статьях выделяются их отдельные подкатегории исходя из наличия у них определенного предмета собственности (земля, автомобиль, недвижимость).
Должностные лица – об их подкатегориях и специальной ответственности было рассказано выше.
Юридические лица – подпадают под нормы Кодекса, если они, в представлении их уставного руководства или ответственных, были способны, но не приняли надлежащих мер для того, чтобы не нарушать положения административного законодательства (федерального или регионального).

Внимание Из этой нормы не следует, что при вынесении постановления о виновности юрлица, от наказания освобождается руководящее им и, вследствие этого, рассматриваемое в качестве должностного, физическое лицо. Также справедливо и обратное правило, по которому присуждение санкционной меры (уголовной или административной) руководящему физическому лице не влечет к освобождению от ответственности организации.

Как и за что наказывают

Отличительной особенностью настоящего Кодекса является его комбинированный характер. Представленные в 3-5 разделах процессуальные нормы документы призваны регламентировать осуществление мер по рассмотрению состава и обеспечению дисциплинарных и штрафных санкций по отношению к приговоренным к наказанию лицам. Это относится к процедурам изъятия и досмотра веще и помещений, протоколированию и штрафованию, задержанию, конвоированию и т.д.

Сам документ также определяет состав органов и должностных лиц, которые заводят и дела по административному законодательству, их рассмотрению, вступлению в силу решений по ним и обжалованию их в судебном порядке.

Отдельно рассматриваются вопросы: доказывание фактов при рассмотрении дел; роли, обязанности и права участников судопроизводства; а также порядок осуществления правовой помощи под делам данной категории.

Таким образом, КоАП РФ одновременно и собрание норм материального права, предусматривающего прямое действие в сфере его кодификации, и процессуальный перечень субъектов и процедур, обеспечивающих их реализацию и соблюдение.

Полезное видео

Консультация юриста о административных правонарушениях на видео ниже:

Оскорбление медицинского работника статья 5 61 коап

Бесплатная консультация с юристом! Оскорбление чести и достоинства медицинских работников — самое частое правонарушение со стороны пациентов. Многие врачи привыкли к хамству больных и стараются не обращать на это внимания. Медицинский юрист Иван Печерей рассказывает, как защитить свои права и привлечь хама к административной ответственности. Хамское отношение пациентов к медикам часто выражается в оскорблениях и клевете — распространении сведений, не соответствующих действительности. Между тем клевета — уголовно наказуемое деяние.

ВИДЕО ПО ТЕМЕ: Разъяснения Пленума ВС по 238 УК РФ применимы к медицинской деятельности?

Дорогие читатели! Наши статьи рассказывают о типовых способах решения юридических вопросов, но каждый случай носит уникальный характер.

Если вы хотите узнать, как решить именно Вашу проблему — обращайтесь в форму онлайн-консультанта справа или звоните по телефонам, представленным на сайте. Это быстро и бесплатно!

Какая статья за оскорбление личности?

Материалы, предоставленные на сайте, собраны из открытых источников и носят ознакомительный характер. Все права на данные материалы принадлежат их законным правообладателям. В случае обнаружения нарушения авторских прав — просьба сообщить через обратную связь.

Вся информация и материалы, размещенные на данном сайте, представлены без гарантии того, что они не могут содержать ошибок. Есть противопоказания, необходимо проконсультироваться со специалистом!

Сибирское здоровье Диагностика дисплазии — 15 мин! Неотложная помощь Клинические рекомендации Порядки и стандарты Турмалиновая продукция. Как быть если пациент оскорбил врача. Популярная информация. Оскорбление, унижение чести и достоинства медицинского работника, как быть если пациент оскорбил врача.

Понравилась статья? Подпишитесь на новости doclvs, Ваш Email:. Главная OrthoTalks. Контакты Партнеры Спасибо.

Оскорбление на рабочем месте или что делать, если оскорбили на работе?

В наше время принято считать, что современного ребенка сложно обидеть, потому что он сам может обидеть кого угодно, и такие ситуации не редкость. Но все же практика показывает, что малолетние дети достаточно часто подвергаются оскорблениям, а в виду своей умственной незрелости по сравнению со взрослыми, они просто не в состоянии дать отпор. Сразу хотелось бы сказать, что специальной статьи, касающейся нанесения оскорблений ребенка, в законодательстве России не существует, однако некоторые действия со стороны взрослых оцениваются как квалификационный признак.

Нужны доказательства факта оскорбления. Квитанции об оплате услуг дорогого психоаналитика. И можно подавать в суд требовать материальной компенсации. Можете пойти к адвокату и он решит.

Какая статья оскорбление детей со стороны родителей

Последнее особенно важно. В ходе проверки опрашивают лингвиста, является ли данное выражение оскорбительным. Тогда можно писать иск о моральном вреде, сумма определяется самостоятельно. Все материалы размещенные на странице не являются рекламой, а есть не что иное как мнение самого автора, которое может не совпадать с мнением других людей и юридических лиц! Материалы, предоставленные на сайте, собраны из открытых источников и носят ознакомительный характер. Все права на данные материалы принадлежат их законным правообладателям. В случае обнаружения нарушения авторских прав — просьба сообщить через обратную связь. Вся информация и материалы, размещенные на данном сайте, представлены без гарантии того, что они не могут содержать ошибок. Есть противопоказания, необходимо проконсультироваться со специалистом!

Оскорбление медицинских работников пациентами

Сейчас довольно много претензий выдвигает общество к уровню бесплатного медицинского образования, врачам в том числе. Оскорбления медицинского персонала поликлиник стали практически нормой, и их число не перестает увеличиваться. Но часто мы забываем, а может, просто не знаем, что каждый гражданин России имеет право защищать свои честь и достоинства, а оскорбители, клеветники и те, кто унижает вас, несут административную ответственность и должны быть наказаны. Весной года пациент Ш.

Интернет — площадка, где многие чувствуют свою безнаказанность, забывают о морали и нравственности, пытаются самому себе доказать свою значимость и радуются, когда удается сделать это за счет других. Оскорбление — повсеместно встречающийся проступок на просторах сети, который совсем не отличается от стандартного — происходящего на улице или в помещении.

Оскорбление, то есть унижение чести и достоинства другого лица, выраженное в неприличной форме, -. Оскорбление, содержащееся в публичном выступлении, публично демонстрирующемся произведении или средствах массовой информации, -. Непринятие мер к недопущению оскорбления в публично демонстрирующемся произведении или средствах массовой информации -.

Бесплатная юридическая помощь

Практически любая работа, так или иначе, подразумевает общение с людьми, будь это работодатель, коллеги или клиенты. К сожалению, человеческая сущность многогранна, что не исключает хамства, грубости и доже агрессивного поведения. Что делать, если Вас оскорбили во время работы?

Статья Оскорбление работника милиции или народного дружинника. Оскорбление работника милиции или народного дружинника, а также военнослужащего в связи с исполнением этими лицами возложенных на них обязанностей по охране общественного порядка -. N Закрыть закон о воинской службе Федеральный закон О прокуратуре РФ закон об исполнительном закон об охране окружающей Федеральный закон О правах ребенка о защите детей N ФЗ фз закон о ветеранах трудовой кодекс Федеральный закон О дополнительных мерах для укрепления стабильности банковской системы в период до 31 декабря года N ФЗ закон о полиции Гражданский процессуальный кодекс ГПК РФ.

Законодательная база Российской Федерации

Добрый день! Работаю врачом-неврологом на приеме в поликлинике. Участились случаи оскорбления, шантажа, клеветы необоснованно со стороны пациентов в мой адрес. Могу ли я записывать разговоры с такими пациентами на диктофон, предупредив их, что идет запись разговора дабы обезопасить и защитить себя? И могу ли вызвать полицию в отдельных случаях невменяемости пациентов?

Нюансы ст. Оскорбление • 3 ответа правоведа, клиент отозвался положительно, вопрос № Нюансы ст. Оскорбление: если обидчик выражает недовольство какими-либо моими действиями или вообще мной в целом.

Поделиться «Статья 5. Нарушение трудового законодательства и иных нормативных правовых актов, содержащих нормы трудового права. Терминологический комментарий». Кодекс об Административных Правонарушениях РФ. Статья 5.

Статья закона РФ об оскорблении личности

Как реализовать свои права для защиты чести и достоинства? Свидетелями могут являться охрана, коллеги, обслуживающий вспомогательный персонал, другие пациенты. Последнее особенно важно.

Оскорбление медицинского работника

Было возбуждено дело, и по итогам его рассмотрения мировым судьей пациент Ш. К сожалению, медработники не знают по большей части о своих правах и юридически неграмотны, а потому и число исков невелико, сообщает Национальная медицинская палата, эксперты которой как раз и занимаются защитой прав медицинских работников. А это значит, что оскорбления, унижение врача или медсестры, проявление агрессии или неуважения остаются безнаказанными и становятся нормой.

Являясь частью социума человек так или иначе взаимодействует с другими людьми. Не всегда взаимодействие происходит в положительном ключе.

Хорошо, когда пребывание на рабочем месте доставляет удовольствие. Однако даже любимую работу могут омрачить не обременённые знаниями этикета люди. Клиенты, сослуживцы, партнёры, начальство — вот основные виновники, когда речь идёт об оскорблении на рабочем месте. О том, что делать, как противостоять и реагировать человеку на оскорбления на работе, расскажем в данной статье. Многие люди, когда сталкиваются с оскорбителями, грозят обидчикам уголовным наказанием.

Оскорбление сотрудника на рабочем месте клиентом

Что делать, если вас оскорбляют на работе? Коллеги, выбирающие на их взгляд наиболее уязвимого человека в коллективе, веселятся и забавляются, оскорбляя честь и личное достоинство работника. Неудивительно, что психическое состояние сотрудника нарушается. Оскорбления на работе статья тк рф 1. Трудового кодекса Российской Федерации, при устройстве на работу лица, которые будут заниматься педагогической деятельностью, а также деятельностью в сфере образования, воспитания, развития несовершеннолетних, организации их отдыха и оздоровления, медицинского обеспечения, обязательно предоставляют справки из УВД об отсутствии судимости На основании статей , Со мной на работе произошел очень неприятный инцидент.

Статья 5.61 КоАП РФ. Оскорбление (действующая редакция)

Бардина, 4а г. Екатеринбург 26 декабря г. Продукция Производители Поставщики. Как реализовать свои права для защиты чести и достоинства?

Административное право. Тест 5 — ДЕКАН ТЕСТ

1. Кто не рассматривает дела об административных правонарушениях, предусмотренных законами субъектов РФ?
Таможенные органы дела об административных правонарушениях, предусмотренных законами субъектов РФ.

2. Дела об административных правонарушениях, совершенных гражданами, призванными на военные сборы, рассматривают:
судьи гарнизонных военных судов

3. Дисквалификации, как вид административного взыскания, могут быть подвергнуты:
физические лица

4. Что может быть доказательствами по делу об административных правонарушениях?
Доказательства по делу об административных правонарушениях могут быть любые фактические данные, на основании которых может быть установлено правонарушение.

5. Законами субъектов Российской Федерации в качестве меры административного наказания могут устанавливаться:
в качестве меры административного наказания может устанавливаться административный штраф

6. Юридическое лицо, согласно КоАП РФ, как субъект административных правонарушений относится к:
общим субъектам

7. К мерам обеспечения производства по делу об административном правонарушении не относится:
предупреждение не относится к мерам обеспечения производства по делу об административном правонарушении.

8. К обстоятельствам, исключающим производство по делу об административном правонарушении, относится:
отмена закона, установившего административную ответственность

9. К обстоятельствам, смягчающим административную ответственность, не относятся:
совершение административного правонарушения в условиях стихийного бедствия или при других чрезвычайных обстоятельствах

10. Какие из указанных видов деятельности относятся к административному производству:
производство по делам об административном производстве

11. КоАП РФ предусматривает ответственность за административные:
правонарушения (проступки)

12. Лицом, которому административным правонарушением причинен физический, имущественный или моральный вред, является:
потерпевший

13. Лишение специального права применяется к:
физическому лицу

14. Налоговые органы рассматривают дела об административных правонарушениях:
выполнение работ и оказания услуг без контрольно-кассовых машин

15. Не является административным наказанием:
выговор

Протокол

CoAP: Пошаговое руководство — DZone IoT

В этой статье описывается, что такое CoAP и как его использовать на устройствах IoT. CoAP — это протокол Интернета вещей, который имеет интересные функции, специально разработанные для устройств с ограничениями. Существуют и другие протоколы IoT, которые можно использовать для создания решения IoT, например MQTT и т. Д.

IoT — одно из самых интересных и многообещающих технологических направлений. Это экосистема, в которой объекты, люди, устройства взаимосвязаны и обмениваются данными. В этом блоге мы рассмотрели IoT с нескольких точек зрения, разработали проекты IoT и затронули несколько аспектов, связанных с IoT.

Что такое протокол CoAP?

Как было сказано ранее, CoAP — это протокол Интернета вещей. CoAP означает протокол ограниченного приложения и определен в RFC 7252. CoAP — это простой протокол с низкими издержками, специально разработанный для ограниченных устройств (таких как микроконтроллеры) и ограниченных сетей. Этот протокол используется в обмене данными M2M и очень похож на HTTP, даже если есть важные отличия, которые мы рассмотрим позже.

Основные характеристики протоколов CoAP:

Веб-протокол, используемый в M2M с ограниченными требованиями
Асинхронный обмен сообщениями
Низкие накладные расходы и очень простой анализ
Поддержка URI и типов содержимого
Возможности прокси и кеширования

Как вы могли заметить, некоторые функции очень похожи на HTTP, даже если CoAP не следует рассматривать как сжатый протокол HTTP, потому что CoAP специально разработан для IoT и, более подробно, для M2M, поэтому он очень оптимизирован для этой задачи.

На уровне протокола абстракции CoAP может быть представлен как:

Как видите, существует два разных уровня, которые составляют протокол CoAp: сообщения и запрос / ответ. Уровень сообщений имеет дело с UDP и асинхронными сообщениями. Уровень запроса / ответа управляет взаимодействием запрос / ответ на основе сообщений запроса / ответа.

CoAP поддерживает четыре разных типа сообщений:

Подтверждается
Не подтверждается
Благодарность
Сброс

Прежде чем углубиться в протокол CoAp, полезно определить структуру, чтобы определить некоторые термины, которые мы будем использовать позже:

Конечная точка : объект, который участвует в протоколе CoAP.Обычно конечная точка идентифицируется с хостом
Отправитель : объект, отправляющий сообщение
Получатель : место назначения сообщения
Клиент : объект, который отправляет запрос, и место назначения ответа
Сервер : объект, который получает запрос от клиента и отправляет ответ клиенту

Сообщения CoAP Модель

Это самый нижний уровень CoAP.Этот уровень имеет дело с UDP-обменом сообщениями между конечными точками. Каждое сообщение CoAP имеет уникальный идентификатор; это полезно для обнаружения дубликатов сообщений. Сообщение CoAP состоит из следующих частей:

Двоичный заголовок
Компактные варианты
Полезная нагрузка

Позже мы опишем формат сообщения более подробно.

Как было сказано ранее, протокол CoAP использует два типа сообщений:

Подтверждаемое сообщение
Неподтвержденное сообщение

Подтверждаемое сообщение — это надежное сообщение.При обмене сообщениями между двумя конечными точками эти сообщения могут быть надежными. В CoAP надежное сообщение получается с помощью подтверждаемого сообщения (CON). Используя этот тип сообщения, клиент может быть уверен, что сообщение будет доставлено на сервер. Подтверждаемое сообщение отправляется снова и снова, пока другая сторона не отправит подтверждающее сообщение (ACK). Сообщение ACK содержит тот же идентификатор подтверждаемого сообщения (CON).

На рисунке ниже показан процесс обмена сообщениями:

Если у сервера возникли проблемы с управлением входящим запросом, он может отправить обратно сообщение Rest (RST) вместо сообщения подтверждения (ACK):

Другой категорией сообщений являются сообщения без подтверждения (NON).Это сообщения, которые не требуют подтверждения со стороны сервера. Это ненадежные сообщения или, другими словами, сообщения, не содержащие важной информации, которая должна быть доставлена на сервер. К этой категории относятся сообщения, содержащие значения, считанные с датчиков.

Даже если эти сообщения ненадежны, у них есть уникальный идентификатор.

Модель запроса / ответа CoAp

Запрос / ответ CoAP — это второй уровень на уровне абстракции CoAP. Запрос отправляется с использованием сообщения с подтверждением (CON) или без подтверждения (NON).Существует несколько сценариев в зависимости от того, может ли сервер немедленно ответить на запрос клиента или ответ, если он недоступен.

Если сервер может немедленно ответить на запрос клиента, то, если запрос передается с использованием подтверждаемого сообщения (CON), сервер отправляет обратно клиенту сообщение подтверждения, содержащее ответ или код ошибки:

Как вы можете заметить в сообщении CoAP, есть токен. Токен отличается от идентификатора сообщения и используется для сопоставления запроса и ответа.

Если сервер не может немедленно ответить на запрос, исходящий от клиента, он отправляет сообщение подтверждения с пустым ответом. Как только ответ доступен, сервер отправляет клиенту новое сообщение Confirmable, содержащее ответ. На этом этапе клиент отправляет обратно сообщение с подтверждением:

Если запрос, исходящий от клиента, передается с использованием НЕ подтверждаемого сообщения, то сервер отвечает с использованием НЕ подтверждаемого сообщения.

Формат сообщения CoAp

В этом параграфе рассматривается формат сообщения CoAP. К настоящему времени мы обсудили различные типы сообщений, которыми обмениваются клиент и сервер. Пришло время проанализировать формат сообщения. Протокол ограниченного приложения — это мясо для ограниченных сред, и по этой причине он использует компактные сообщения. Чтобы избежать фрагментации, сообщение занимает раздел данных дейтаграммы UDP. Сообщение состоит из нескольких частей:

Где:

Ver : это 2-битовое целое число без знака, указывающее версию
T : это 2-битовое целое число без знака, указывающее тип сообщения: 0 подтверждаемое, 1 неподтвержденное
TKL : Длина маркера — это 4-битная длина маркера
Код : это кодовый ответ (длина 8 бит)
Идентификатор сообщения : Это идентификатор сообщения, выраженный 16 битами
И так далее.

Еще полезные ресурсы:

Аспекты безопасности CoAP

Одним из важных аспектов работы с протоколами IoT являются аспекты безопасности. Как указывалось ранее, CoAP использует UDP для передачи информации. CoAP полагается на аспекты безопасности UDP для защиты информации. Поскольку HTTP использует TLS через TCP, CoAP использует датаграмму TLS через UDP. DTLS поддерживает RSA, AES и так далее. В любом случае, мы должны учитывать, что в некоторых ограниченных устройствах некоторые из шифров DTLS могут быть недоступны.Важно отметить, что некоторые комплекты шифров привносят некоторую сложность, и ограниченным устройствам может не хватить ресурсов для управления этим.

CoAP против MQTT

Важно рассмотреть основные различия между CoAP и MQTT. Как вы, возможно, знаете, MQTT — еще один протокол, широко используемый в IoT. Между этими двумя протоколами есть несколько различий. Первое, на что следует обратить внимание, — это используемая другая парадигма. MQTT использует издателя-подписчика, в то время как CoAP использует парадигму запроса-ответа.MQTT использует центрального брокера для отправки сообщений, поступающих от издателя, клиентам. CoAP — это, по сути, протокол «один-к-одному», очень похожий на протокол HTTP. Более того, MQTT — это протокол, ориентированный на события, тогда как CoAP больше подходит для передачи состояния.

Не забудьте поделиться этой статьей!

Протокол ограниченных приложений для Интернета вещей

Аннотация:

Интернет вещей (IoT) — важная часть технологии нового поколения, благодаря которой каждый объект, будь то вещи или человек, может быть подключен к Интернету.Существует множество беспроводных протоколов (например, IEEE 802.11 Series, 802.15 Series, Zigbee и т. Д.) Для связи между устройствами. Однако, учитывая, что многие небольшие устройства не могут эффективно взаимодействовать с ограниченными ресурсами, Инженерная группа Интернета (IETF) разработала упрощенный протокол: протокол ограниченного приложения (CoAP). Во-первых, в этом документе кратко описаны некоторые беспроводные протоколы. Затем вводится CoAP и соответствующий протокол безопасности DTLS. Наконец, подана заявка.

Ключевые слова

IoT, CoAP, DTLS, беспроводные протоколы, умный дом, система управления энергопотреблением

Содержание:

1. Введение

Интернет вещей (IoT) представлен как глобальная сеть, которая разумно соединяет все объекты, будь то устройства, системы или человека, с самонастройкой возможности, основанные на стандартных и совместимых протоколах и форматах [Петербург 12]. Благодаря интеллектуальному распознаванию, технологиям идентификации и убедительным вычислениям Интернет вещей стал называется Третьей волной в информационной индустрии вслед за компьютером и Интернетом.IoT поддерживает сотни протоколов. Из множества протоколов беспроводные протоколы играют важную роль в развитии Интернета вещей.

В разделе 1 представлены некоторые беспроводные протоколы на разных уровнях IoT. Приведен один последний протокол для CoAP прикладного уровня, а также его функции и обобщены функции. Сравнивая его с протоколом передачи гипертекста (HTTP), его представлены преимущества. В разделе 2 объясняются некоторые важные модели CoAP. детали, такие как модель уровня сообщения, модель уровня запроса / ответа и сообщение формат.В разделах 3 описан протокол безопасности Datagram Transport Layer Security (DTLS). для защиты трансмиссии. Достигнут необходимые элементы для крепления CoAP, как целостность, аутентификация и конфиденциальность. Затем приложение CoAP Описаны умные дома, которые помогают пользователям управлять системами управления энергопотреблением, что снижает энергопотребление и предотвращение несчастных случаев.

2. Обзор беспроводных протоколов для Интернета вещей

Интернет вещей должен включать в себя различные датчики, компьютерное и коммуникационное оборудование, которое используя разные протоколы связи.Беспроводные протоколы в основном используются на трех уровнях: которые являются уровнем PHY / MAC, уровнем сети / связи и уровнем приложения.

CoAP — один из последних протоколов прикладного уровня, разработанный IETF для интеллектуальных устройств. для подключения к Интернету. Существует столько же устройств, сколько компонентов в транспортных средствах и зданиях с ограниченные ресурсы, это приводит к большим изменениям в мощности вычислений, коммуникации пропускная способность и т. д. Таким образом, облегченный протокол CoAP предназначен для использования и рассматривается как замена HTTP на протокол прикладного уровня IoT.

2.1 Протоколы на разных уровнях

Уровни IoT PHY / MAC включают в себя все распространенные технологии беспроводной связи, такие как как серия IEEE 802.11, серия 802.15, HART (удаленный датчик с адресацией на магистрали), Стандарт IEEE 802.15.4 определяет часть MAC / PHY для беспроводной личной зоны большого радиуса действия. сеть (LR-WPAN). Zigbee, WirelessHART основаны на IEEE802.15.4 от добавление верхних слоев.

Поскольку TCP / IP закладывает основу для Интернета, таким образом, сеть связи IoT в основном используют протоколы TCP и UDP.По сравнению с протоколом UDP, протокол TCP более сложный, что затрудняет использование на устройствах с ограниченными ресурсами. Сейчас большая часть Интернета вещей использует протокол UDP. Но UDP нестабилен, что нужно комбинировать с прикладным слоем для повышения стабильности.

Прикладной уровень обычно использует HTTP для предоставления веб-сервисов, но HTTP имеет высокую сложность вычислений, низкая скорость передачи данных и высокое энергопотребление. Таким образом, IETF имеет разработал несколько облегченных протоколов, например.g., CoAP, встроенный двоичный HTTP (EBHTTP), Lean Transport Protocol (LTP). Протокол ограниченного приложения (CoAP) — это специализированный протокол веб-передачи для использования с ограниченными узлами и ограниченными (например, маломощные, с потерями) сети [Z.Shelby13]. EBHTTP — это двоичный формат, экономичное кодирование без сохранения состояния стандартного протокола HTTP / 1.1 [G.Tolle13]. EBHTTP в первую очередь предназначен для передачи небольших данных между ограниченными ресурсами узлов, что похоже на CoAP.LTP — это легкий транспортный протокол веб-службы, который обеспечивает прозрачный обмен сообщениями веб-сервисов между всеми видами ресурсов ограниченные устройства и системы класса серверов или ПК [Glombitza10]. Таблица 1 обобщает протоколы в разных слоях.

2.2 Характеристики CoAP

Ожидается, что после завершения спецификации CoAP будет миллион устройств, развернутых в различных областях приложений в будущем.Диапазон этих приложений от умной энергии, умной сети, управления зданием, интеллектуального управления освещением, промышленного системы управления, отслеживание активов, мониторинг окружающей среды. CoAP станет стандартом протокол для обеспечения взаимодействия между устройствами и поддержки приложений Интернета вещей [S.Keoh23]. Ограниченная среда RESTful (CoRE) — это рабочая группа в IEFT, которая разрабатывает протокол CoAP.

CoAP необходимо рассмотреть возможность оптимизации длины дейтаграммы и соответствия протоколу REST для поддержки URI (унифицированный идентификатор ресурса).Также необходимо обеспечить надежную связь на основе по протоколу UDP. В таблице 2 показаны характеристики CoAP [Петербург12]

2.3 Сравнение CoAP и HTTP

CoAP — это сетевой протокол, использующий функции, аналогичные HTTP, но также позволяющий для низких накладных расходов, многоадресной рассылки и т. д. Поскольку протокол HTTP является долгосрочным успешным стандартом, он может использовать небольшой скрипт для интеграции различных ресурсов и сервисов. Обеспечено взаимодействие HTTP является ключевым моментом IoT, для этого HTTP используется на уровне приложений.Однако, HTTP основан на протоколе TCP с использованием модели связи точка-точка (p2p), которая не подходит для сервисов push-уведомлений. Кроме того, для устройств с ограничениями HTTP слишком сложен.

В отличие от протоколов на основе HTTP, CoAP работает через UDP вместо использования сложной перегрузки. управление как в TCP [Koojana11]. CoAP основан на архитектуре REST, которая является общей дизайн для доступа к Интернет-ресурсам. Чтобы преодолеть недостаток в ограниченном ресурс, CoAP необходимо оптимизировать длину дейтаграммы и обеспечить надежную связь.С одной стороны, CoAP предоставляет URI, метод REST, такой как GET, POST, PUT и DELETE. С другой стороны, основанный на облегченном протоколе UDP, CoAP позволяет многоадресную IP-рассылку, что обеспечивает групповое общение. для Интернета вещей. Чтобы компенсировать ненадежность протокола UDP, CoAP определяет повторную передачу механизм и обеспечивает механизм обнаружения ресурса с описанием ресурса [Shelby11]. Рис. 1 показывает стеки протоколов HTTP и CoAP.

Рис.1: Стеки протоколов HTTP и CoAP

CoAP — это не просто сжатие протокола HTTP.Учитывая низкую вычислительную мощность и низкое энергопотребление требования ограниченного ресурса, CoAP переработал некоторые функции HTTP, чтобы учесть эти ограничения. HTTP используется без ограничений сеть и CoAP используются в ограниченной сети. В последнее время HTTP-CoAP межпротокольный прокси вызывает научный интерес, он имеет и важно роль в решении проблемы перегрузки в стесненной среде [Кастеллани12].

3. Модель структуры CoAP

Интерактивная модель CoAP похожа на модель клиент / сервер HTTP.На рис. 2 показано, что CoAP использует двухуровневую структуру. Нижний уровень — это уровень сообщений, который был разработан для работы с UDP и асинхронной коммутацией. Уровень запроса / ответа касается метода связи и обработки сообщения запроса / ответа.

Рис. 2: Абстрактный слой CoAP [Z.Shelby13]

3.1 Модель уровня сообщений

Уровень сообщений поддерживает 4 типа сообщений: CON (подтверждаемое), NON (неподтвержденное), ACK (подтверждение), RST (сброс) [Z.Shelby13].

a) Надежный транспорт сообщений: продолжайте повторную передачу, пока не получите ACK с тем же идентификатором сообщения (например, 0x8c56 на рис. 3). Использование тайм-аута по умолчанию и экспоненциальное уменьшение времени счета при передаче CON. Если получатель не может обработать сообщение, он отвечает заменой ACK на RST. На рис. 3 показан надежный транспорт сообщений.

Рис. 3: Надежный транспорт сообщений

б) Ненадежный транспорт сообщений: транспортировка с сообщением типа НЕ.Его не нужно подтверждать, но он должен содержать идентификатор сообщения для наблюдения. в случае ретрансляции. Если получатель не может обработать сообщение, сервер отвечает RST. На рис. 4 показан ненадежный транспорт сообщений.

Рис. 4: Ненадежная передача сообщений

3.2 Модель уровня запроса / ответа

a) Piggy-backed: клиент отправляет запрос с использованием типа CON или типа NON. сообщение и немедленно получает ответный ACK с подтверждающим сообщением.На рис. 5, для успешного ответа ACK содержит ответное сообщение (укажите с помощью токена), для ответа о сбое ACK содержит код ответа о сбое.

Рис. 5: Результаты успешного и неудачного ответа метода GET

б) Отдельный ответ: если сервер получил сообщение типа CON, но не получил может немедленно ответить на этот запрос, он отправит пустой ACK в случае, если клиент повторно отправит это сообщение. Когда сервер готов ответить этот запрос, он отправит новый CON клиенту, и клиент ответит подтверждаемое сообщение с подтверждением.ACK только для подтверждения CON сообщение, независимо от того, запрос или ответ на перенос сообщения CON (рис. 6).

Рис. 6. Запрос Get с отдельным ответом

c) Неподтверждаемый запрос и ответ: в отличие от ответа Piggy-backed переносить подтверждаемое сообщение, в неподтвержденном запросе клиент отправляет НЕ тип сообщение указывает, что сервер не нуждается в подтверждении. Сервер повторно отправит NON введите сообщение с ответом (рис. 7).

Фиг.7: неподтвержденный запрос и ответ

3.3 Формат сообщения

CoAP основан на обмене компактными сообщениями, которые, по умолчанию передаются через UDP (т.е. каждое сообщение CoAP занимает раздел данных одной дейтаграммы UDP) [Petersburg12]. Сообщение CoAP использует простой двоичный формат. Сообщение = 4-байтовый заголовок фиксированного размера плюс токен переменной длины плюс последовательность опций CoAP плюс полезная нагрузка. Формат представлен в таблице 3.

Номер варианта = дельта варианта + номер варианта ex.Формат показан на рис. 8.

Рис.8: Формат опции CoAP

4. Протокол безопасности и приложение для CoAP

CoAP теперь становится стандартным протоколом для приложений Интернета вещей. Безопасность важна для защиты связи между устройствами. В следующей части протокол безопасности Вводится DTLS. Также в этом разделе описывается одно из приложений CoAP — Умные дома.

При рассмотрении вопроса о безопасности можно выделить три основных элемента, а именно: целостность, аутентификация и конфиденциальность.DTLS может достичь всего из них [Котмайр 12]. IETF модифицирует DTLS для разработки другого протокола DTLS. DTLS использует TCP, что слишком сложно. DTLS решает две проблемы: переупорядочивание и потеря пакета. Он добавляет три инструмента: 1 повторная передача пакета. 2 присвоение порядкового номера в рукопожатии. 3 обнаружения повтора.

В отличие от протоколов безопасности сетевого уровня, DTLS на прикладном уровне (рис.9) защитить сквозную связь. Никакая сквозная защита связи не сделает злоумышленнику легко получить доступ ко всем текстовым данным, которые проходят через скомпрометированный узел.DTLS также позволяет избежать проблем с криптографическими накладными расходами, которые возникают в протоколах безопасности нижнего уровня.

4.1 Зачем использовать DTLS для защиты CoAP

При рассмотрении безопасности есть три основных элемента, а именно целостность, аутентификация и конфиденциальность. DTLS может достичь всех из них [Kothmayr12]. IETF модифицирует DTLS для разработки другого протокола DTLS. DTLS использует TCP, который слишком сложно. DTLS решает две проблемы: переупорядочение и потерю пакетов. Он добавляет три Реализует: повторную передачу 1 пакета.2 присвоение порядкового номера в рукопожатии. 3 обнаружения повтора.

В отличие от протоколов безопасности сетевого уровня, DTLS на прикладном уровне (рис. 9) защитить сквозную связь. Никакая сквозная защита связи не будет облегчить злоумышленнику доступ ко всем текстовым данным, которые проходят через скомпрометированный узел. DTLS также позволяет избежать криптографических накладных расходов, которые возникают. в протоколах безопасности нижнего уровня.

Рис.9: DTLS в стеке протоколов

4.2 Структура DTLS

В DTLS есть два уровня. Нижний содержит протокол записи. Верхний включает три протокола: оповещение, рукопожатие и данные приложения, в некоторых случаях протокол Change Cipher Spec может заменить один из них. Изменять Сообщение Cipher Spec используется для уведомления протокола записи для защиты последующих записи с набором шифров и ключами только для согласования. [Raza13]

Протокол записи [E.Rescorla12] защищает данные приложения с помощью ключей генерируется во время рукопожатия.Для исходящего сообщения протокол разделения, сжатия, зашифровать и применить к ним код аутентификации сообщения (MAC). Для входящего сообщения протокол собрать, распаковать, расшифровать и проверить их. Заголовок записи состоит из две части, одна — тип содержимого, а другая — поле фрагмента. Тип контента решает, что содержится в поле фрагмента. Это может быть протокол оповещения, протокол рукопожатия или Данные приложений. Сравните с DTLS Record, протокол рукопожатия довольно сложен. один, который включает в себя множество этапов обмена.Отдельные сообщения сгруппированы в сообщение полеты. На рис. 10 показан процесс рукопожатия.

Рис.10: Процесс установления связи

Архитектура, показанная ниже (рис. 11), предназначена для одноадресной связи. (клиент взаимодействует с одним или несколькими серверами). Также клиенту нужны чтобы узнать, какой сертификат или необработанный открытый ключ он должен использовать с конкретным сервером [Hartke13].

Рис.11: Модель связи Uni-cast

4.3 Приложение CoAP для умных домов

Информационная аппаратура, контрольная аппаратура и коммуникационное оборудование в сетях Умного дома имеют характер дешевизны и легкости. Таким образом, CoAP можно рассматривать как лучший выбор протокола для домашних сетей связи.

Сеть умного дома обеспечивает контроль и мониторинг энергии домашних устройств. Системы управления энергопотреблением используют интеллектуальное управление розетками и контролируют энергопотребление оборудование для предоставления информации о напряжении, токе и другой энергии.Он мог понять предупреждение об авариях, дистанционное управление и динамическое энергосбережение. Структура системы показано на рис. 12. Каждый узел сбора данных с клиентом CoAP мог обмениваться информацией с другими узлами. CoAP может быть установлен как в локальной сети, так и в Интернете. В отличие от многих беспроводных протоколы для домашних автомобильных устройств, CoAP не ограничен в локальной сети но обеспечивают фундаментальную основу сети [Bergmann12]. В этой системе прокси CoAP-HTTP используются для обеспечения подключения клиента HTTP к ресурсам CoAP и наоборот.

Рис.12: Система управления энергопотреблением

В системной сети узлы сбора данных состоят из одного прокси, умного гнезда и беспроводной модуль сбора данных. Информация об энергии и окружающей среде оборудования собирается умной розеткой и транспортируется в модуль сбора данных через беспроводной канал, а затем отправить последовательные данные на прокси-сервер для обработки и упаковки данных. Сервер управления анализирует все данные и сохраняет их в базе данных.Система интегрирует домашняя сеть и Интернет, пользователи могут получить доступ к веб-странице системы для удаленного управления переключателем, управлять конфигурацией, запрашивать потребление энергии и т. д. В то же время i1 / 4OE эта система следить за ситуацией в окружающей среде. Если произойдет что-то ненормальное (например, высокая температура или напряжение за пределами безопасного диапазона) система проанализирует его и закроет соответствующее оборудование.

5. Заключение

В этом отчете обобщены некоторые беспроводные протоколы для Интернета вещей и представлены Подробно о протоколе CoAP с описанием основных функций и модулей.CoAP основан на протоколе HTTP и предназначен для ограниченных ресурсов устройств. Сравнивая CoAP и HTTP вместе, преимущества CoAP для IoT. Этот отчет также обеспечивает соответствующую безопасность протокол DTLS и одно возможное применение CoAP для IoT. Как ряд протоколы совершенствуются, все больше и больше умных домов будут использовать эти беспроводные протоколы для интеллектуального управления.

6. Список литературы

[Петербург12] г. Санкт-Петербург.Санкт-Петербург, «Интернет вещей, интеллектуальные пространства и сети нового поколения», Россия, 27-29 августа 2012 г. http://link.springer.com/book/10.1007%2F978-3-642-32686-8
[Z. Shelby13] З. Шелби, Сенсиноуд, К. Хартке, «Протокол ограниченного приложения (CoAP)», draft-ietf-core-coap-18. [2013-06-28] http://tools.ietf.org/html/draft-ietf-core-coap-18
[G.Tolle13] G.Tolle, Arch Rock Corporation. Встроенный двоичный HTTP (EBHTTP) draft-tolle-core-ebhttp-00.[2010-03-23] https://tools.ietf.org/html/draft-tolle-core-ebhttp-00
[Glombitza10] Glombitza, N .; Pfisterer, D .; Фишер, С., «LTP: эффективный протокол передачи веб-сервисов для устройств с ограниченными ресурсами», Sensor Mesh and Ad Hoc Communications and Networks (SECON), 7-я ежегодная конференция IEEE Communications Society, 2010 г., том, №, стр.1 , 9, 21-25 июня 2010 г. http://ieeexplore.ieee.org/document/5508255/
[С. Keoh23] С.Кео, Philips Research, З. Шелби, Sensinode. Профилирование DTLS для приложений Интернета вещей на основе CoAP draft-keoh-dice-dtls-profile-iot-00 [2013-11-05] http://tools.ietf.org/html/draft-keoh-dice-dtls-profile-iot-00
[Koojana11] Кожана Куладинити, Олаф Бергманн, Томас Потч, Маркус Беккер, Кармелита Горг, «Внедрение CoAP и его применение в транспортной логистике», в материалах семинара по распространению Интернета на маломощные и потерянные сети (апрель 2011 г.) http: // hinrg.cs.jhu.edu/joomla/images/stories/coap-ipsn.pdf
[Shelby11] Зак Шелби, «Формат ссылки CoRE», draft-ietf-core-link-format-07 https://tools.ietf.org/html/draft-ietf-core-link-format-01
[Castellani12] Castellani, A .; Fossati, T .; Лорето, С., «Межпротокольный прокси HTTP-CoAP: точка зрения реализации», Mobile Adhoc and Sensor Systems (MASS), 2012 IEEE 9th International Conference on, vol.Supplement, no., Pp.1,6, 8-11 Октябрь 2012 г. http: // ieeexplore.ieee.org/document/6708523/
[Kothmayr12] Архитектура сквозной безопасности на основе DTLS для Интернета вещей с двусторонней аутентификацией Томас Котмайр, Коринна Шимитт, Вен Ху, Майкл Брюнинг. 2012 г. http://kothmayr.net/wp-content/papercite-data/pdf/kothmayr2012dtls.pdf
[Raza13] Raza, S .; Shafagh, H .; Hewage, K .; Hummen, R .; Фойгт, Т., «Lithe: легкий безопасный протокол CoAP для Интернета вещей», журнал Sensors, IEEE, vol.13, № 10, с. 3711,3720, октябрь 2013 г. http://ieeexplore.ieee.org/document/6576185/
[E. Rescorla12] E. Rescorlai, N. Modadugu, «Datagram Transport Layer Security Version 1.2», RFC Standard 6347, январь 2012 г. http://tools.ietf.org/html/rfc6347
[Hartke13] Клаус Хартке, Ханнес Чофениг, Профиль DTLS для Интернета вещей draft-hartke-dice-profile-00, [2013-11-04] http://tools.ietf.org/html/draft-hartke-dice-profile-00
[Bergmann12] Бергманн, О.; Hillmann, K.T .; Гердес, С., «Шлюз CoAP для умных домов», «Компьютеры, сети и коммуникации» (ICNC), Международная конференция 2012 г., стр. 446 450, 30 января 2012 г. — февраль. 2 2012 http://ieeexplore.ieee.org/document/6167461/

7. Сокращения

Интернет вещей	Интернет вещей
ИЭФТ	Инженерная группа Интернета
CoAP	Протокол ограниченного приложения
HTTP	Протокол передачи гипертекста
HART	Дистанционный датчик с адресацией по магистрали
LR-WPAN	Низкоскоростная беспроводная персональная сеть
EBHTTP	Встроенный двоичный HTTP
LTP	Протокол бережливого транспорта
CoRE	Ограниченные среды RESTful
ОТДЫХ	Государственная передача представления
URI	Универсальный идентификатор ресурса
P2P	От точки к точке
DTLS	Дейтаграмма безопасности транспортного уровня

Последнее изменение: 30 апреля 2014 г.
Этот и другие документы по текущим вопросам беспроводных и мобильных сетей доступны в Интернете по адресу http: // www.cse.wustl.edu/~jain/cse574-14/index.html
Вернуться на домашнюю страницу Раджа Джайна

Усовершенствования и проблемы в CoAP — обзор

CoAP используется в WSN и средах IoT в различных областях. Реализация CoAP в различных приложениях выявила некоторые недостатки в базовой архитектуре CoAP. Поэтому в архитектуру CoAP были внесены различные улучшения. В текущем разделе подробно обсуждаются улучшения, внесенные в механизм управления перегрузкой CoAP, безопасность CoAP, совместимость CoAP и так далее.

4.1. Механизмы управления перегрузкой в CoAP

В этом разделе рассматриваются механизмы управления перегрузкой, представленные в CoAP по умолчанию, и множество других расширенных механизмов управления перегрузкой для CoAP, основанных на измерениях RTT, градиентах измерений RTT, узкой полосе пропускания сетевого канала, скорости трафика или коэффициенте потери пакетов.

4.1.1. CoAP по умолчанию

Контроль перегрузки в CoAP по умолчанию: CoAP по умолчанию использует метод BEB для управления перегрузкой в сети [2].В случае надежной передачи сообщение CON передается от клиентского узла к серверному узлу. Если сообщение не было успешно передано с первой попытки, выполняется повторная передача. CoAP выбирает случайное значение RTO для первой передачи между 2–3 с. Если первая повторная передача не удалась, BEB удваивает RTO, чтобы избежать перегрузки. Следовательно, новое значение RTO (RTOnew) в два раза больше предыдущего значения RTO (RTOprev) в соответствии с уравнением (1).

Этот метод контроля перегрузки не очень эффективен, так как он вызывает длительные задержки в сети и не учитывает динамические состояния сети.Чтобы сделать его эффективным, был разработан усовершенствованный механизм контроля перегрузки, названный «Контроль перегрузки / Расширение» (CoCoA).

4.1.2. CoCo-RED

CoAP по умолчанию не обеспечивает эффективное групповое общение и наблюдение за ресурсами. Поэтому в [22] представлен механизм управления перегрузкой для наблюдения за групповой связью, названный как случайное раннее обнаружение управления перегрузкой (CoCo-RED). Основные компоненты схемы включают:

Определение и расчет таймера RTO
Управление с использованием алгоритма исправленного случайного раннего обнаружения (RevRED) для предотвращения перегрузки
Алгоритм предварительного приращения Фибоначчи (FPB) для реализации таймер отсрочки передачи

CoCo-RED изначально устанавливает значение RTO случайным образом от 2 до 4 с и использует FPB в случае повторных передач для установки RTO.Чтобы избежать перегрузки с помощью метода управления буфером (BMT), предлагаемый механизм работает динамически и использует RevRED для расчета плотности сети на основе среднего размера очереди (AvgQ). Алгоритм RevRED отбрасывает приходящий пакет до того, как буферная очередь клиента переполнится. Размер AvgQ рассчитывается с использованием экспоненциально взвешенного скользящего среднего. Алгоритм работает по следующим принципам:

Если AvgQ
Если Min threshold
Если AvgQ> Max threshold, прибывающий пакет отбрасывается на основе формулы экспоненциальной вероятности отбрасывания, представленной предложенным методом

В случае, если пакеты отбрасываются из-за перегрузки, выполняются повторные передачи.Для расчета RTO для повторных передач пакетов используется FPB. Для каждой повторной передачи FPB умножается на предыдущее значение RTO для нахождения нового значения RTO для следующей повторной передачи. FBP использует числа Фибоначчи для умножения на предыдущее RTO при каждой повторной передаче, что позволяет достичь более низкого значения RTO по сравнению с двоичным экспоненциальным откатом CoAP по умолчанию при каждой последующей повторной передаче.

CoCo-RED помогает сократить время отклика сети в дополнение к потере пакетов. Однако значения отсрочки фиксированы и не меняются в зависимости от динамических условий сети.

4.1.3. CoCoA

Чтобы преодолеть проблемы в управлении перегрузкой CoAP по умолчанию, CoCoA вводит функцию расчета адаптивного RTO в дополнение к Variable Backoff Factor (VBF) вместо BEB и механизму устаревания RTO. CoCoA определяет две оценки RTO: слабую RTO и сильную оценку RTO [6]. Оценщик сильного RTO вычисляет значения RTO для следующей передачи сообщения на основе измерения сильного RTT, тогда как модуль оценки слабого RTO вычисляет значения RTO на основе слабого RTT.Сильное значение RTT — это значение RTT, полученное после первой успешной передачи, а значение слабого RTT — это значение RTT, полученное по крайней мере после одной повторной передачи. Расчет окончательного общего RTO основан на значениях слабого и сильного RTT и значений RTO. Подробные расчеты общего RTO можно найти в [6].

Для значения отсрочки передачи CoCoA применяет VBF в соответствии с информацией о состоянии сети, чтобы избежать длительных задержек простоя. В зависимости от начального значения RTO передачи, VBF применяется к повторным передачам.Если начальное RTO очень мало, то есть меньше 1 секунды, применяется больший VBF, а для большого значения RTO, то есть больше 3 секунд, применяется меньшая отсрочка. Для значения от 1 до 3 с значение VBF устанавливается на оптимальное значение 2, что соответствует BEB. Значения VBF указаны в [6].

Другая проблема, связанная с устареванием значений RTO, регулируется CoCoA. Механизм устаревания RTO применяется в случае малых и больших оценок RTO. Для оценочного значения RTO ниже 1 с и выше 3 с, если новые измерения RTT не производятся в 16 или 4 раза больше текущего значения RTO соответственно, CoCoA использует механизм устаревания RTO и изменяет значение RTO таким образом, чтобы оно приближалось к значению по умолчанию. Начальное значение.

CoCoA превосходит стандартный механизм управления перегрузкой CoAP; однако есть неоднозначность в вычислении оценки слабого RTT. Более того, значение слабого RTT может изменяться в каждом последовательном вычислении, поскольку неизвестно, после того, сколько повторных передач будет получено ACK сообщения. Это приводит к длительным общим показателям RTO и, в свою очередь, к большим задержкам на холостом ходу.

4.1.4. Схема четырехуровневого оценщика

Поскольку CoCoA не может различить, какой повторной передаче принадлежит полученный ACK, он выполняет вычисления RTO на основе исходного времени начала, что вызывает задержки простоя между последовательными передачами.Чтобы преодолеть эту проблему, авторы [23] предложили схему оценки с 4 состояниями, чтобы увеличить степень детализации отсрочки. Схема работает по принципу меньшего реагирования на потери, возникшие вначале при передаче пакета, и большей реакции, когда наблюдаются большие потери. Каждая передача называется состоянием, в котором каждая передача соответствует состоянию 1, 2, 3 или 4. Каждый номер состояния соответствует количеству повторных передач. Когда выполняется новая транзакция, состояние транзакции считается равным 1.Это состояние увеличивается каждый раз на единицу по мере выполнения повторной передачи. Аналогично, всякий раз, когда пакет передается успешно без каких-либо повторных передач, состояние уменьшается на единицу. Таким образом устанавливаются соответствующие значения отсрочки. Оптимизация значений отсрочки может выполняться по значениям состояния внутри транзакции, а также по нескольким транзакциям.

Переменный коэффициент отсрочки передачи рассчитывается для каждого значения состояния. Для значений отсрочки и формул, используемых для расчета этих значений; читателю отсылаем к [23].В отличие от двух оценок CoCoA (слабой и сильной), предлагаемая схема имеет четыре уровня оценок. По мере увеличения потерь и увеличения количества отказов передач к расчету RTO добавляется более высокий процент отсрочки передачи. В документе используется следующее уравнение (уравнение (2)) для расчета общего RTO:

RTOобщее = w ∗ RTOполучено + (1-w) ∗ RTOобщее

(2)

Параметр w здесь представляет собой вес для полученный RTO.

4.1.5. Адаптивное управление перегрузкой

Проблема неоднозначности в значениях слабой оценки и для установки соответствующих значений констант для VBF и механизма устаревания RTO, чтобы решить, следует ли и как предпринимать правильные действия, покрывается алгоритмом адаптивного управления перегрузкой. предложено в [4].Опция подсчета передач добавлена в заголовок сообщения CoAP, чтобы решить проблему слабой оценки. В случае повторной передачи сообщения CON инкапсулируется новая копия того же сообщения с другим идентификатором сообщения. Это помогает в идентификации количества повторных передач и, следовательно, устраняется неоднозначность, является ли сообщение ACK от передачи или повторной передачи для слабой оценки.

Для того, чтобы значения VBF были адаптированы к реальным условиям сети, алгоритм рассматривает RTOstrong в качестве эталона.Кроме того, нижний и верхний пороги заменяются на (1/3) * RTOstrong и (5/3) * RTOstrong соответственно. Нижняя граница позволяет значению RTO увеличиваться от RTOstrong до второй повторной передачи, в то время как верхняя граница позволяет быстро увеличить RTO. В случае значения RTO по умолчанию, равного 2 с, эти значения почти возвращаются к значениям по умолчанию 0,7 с и 3,3 с для нижнего и верхнего порогов соответственно.

Диапазон значений RTO устанавливается на (1/3 * RTOstrong, 5/3 * RTOstrong) в случае устаревания RTO и настраивается принудительным образом, когда значение выходит за пределы диапазона или не обновляется в течение более длительных периодов времени. время.

4.1.6. CoCoA +

Betzler et al. в [7] предлагается усовершенствованный механизм управления перегрузкой (CoCoA +) в качестве другого решения проблем в CoCoA. CoCoA + был предложен для преодоления недостатков CoCoA. Поскольку оценка слабого RTT в CoCoA неоднозначна и влияет на общий расчет RTO, CoCoA + предлагает уменьшить влияние оценки слабого RTT на расчет общего RTO, уменьшив значение K (множитель дисперсии RTT) с 4 до 1. .

RTOX = RTTX + KX ∗ RTTVARX

(3)

Более того, вес оценки слабого RTO ограничен в общем вычислении RTO.Он снижен с 50% до 25%.

RTOобщее = 0,25 * RTOweak + 0,75 * RTOобщее

(4)

Кроме того, для измерений слабого RTT CoCoA + ограничивает измерения, которые должны быть взяты только от первой передачи и первой повторной передачи.

Эти решения помогают избежать больших приращений общих значений RTO. CoCoA + пока не может выбрать правильное значение RTO в случае пакетного трафика. Это вызвано неточными измерениями повторно переданного RTT во время импульсного трафика, что приводит к ложным повторным передачам.Фактически, Анчиллотти и Бруно в [39] оценили эффективность управления перегрузкой CoAP и CoCoA + по умолчанию и обнаружили, что в различных сетевых условиях CoCoA + работает значительно хуже, чем механизм управления перегрузкой CoAP по умолчанию, например, в случае малых значений RTT и для бурный трафик.

4.1.7. Улучшенное адаптивное управление перегрузкой

Ранее предложенные методы не рассматривают проблему выбора правильного значения RTO в случае пакетного трафика. Кроме того, эти методы также не учитывают коэффициент потери пакетов.Коэффициент потери пакетов определяется как количество пакетов, полученных на стороне получателя, по сравнению с количеством пакетов, отправленных отправителем. Коэффициент потерь пакетов используется для оценки эффективности метода по потерям. [24] предлагает улучшенный алгоритм управления перегрузкой, основанный на коэффициенте потери пакетов и значениях RTT предыдущей передачи. Метод предлагает два сценария с использованием коэффициента потери пакетов в качестве ключевого параметра и соответствующим образом регулирует значение RTO на основе предыдущих значений RTT.

Случай 1: Значение RTO обновляется в соответствии с формулой, представленной в уравнении (5) в случае, когда коэффициент потери пакетов ниже 50%, чтобы предотвратить излишне длительные задержки простоя, тогда как значение RTO обновляется в соответствии с представленной формулой в уравнении (1), чтобы скорректировать значение потерь.

RTOrecent = RTT * packetlossratio + (1-packetlossratio) * RTOprevious

(5)

RTOrecent = RTOprevious * packetlossratio + (1-packetlossratio) * RTT

(6)

Поскольку значение RTO обновляется в каждой передаче Что касается коэффициента потери пакетов, нет необходимости в механизме устаревания RTO. Расчет значения RTO при каждой передаче вызывает слишком много накладных расходов и может вызвать задержку передачи.

4.1.8. CACC

Контекстно-зависимое управление перегрузкой (CACC), предложенное в [25], решает проблему различения сценария потери пакетов из-за частоты ошибок по битам и перегрузки.Он определяет правильный RTT повторно переданного сообщения ACK с учетом динамических условий сети. Он состоит из трех оценщиков RTT; слабая оценка RTT, сильная оценка RTT и неудачная оценка RTT. Сильный и неудачный RTT, объединенные вместе, представляют успешную доставку и отбрасывание пакета, где сильный RTT рассчитывается в случае успешной доставки, а неудачный RTT — в случае отбрасывания пакета. Этот сценарий подчеркивает вероятность конфликта пакетов на канальном уровне, поскольку некоторые пакеты доставляются, а остальные отбрасываются.С другой стороны, высокое значение слабого RTT представляет задержку перегрузки на уровне узла. Этот метод также ограничивает сжатие RTO, чтобы избежать отрицательного изменения RTT, которое вызывает ложные повторные передачи. В дополнение к этому, CACC также учитывает информацию о количестве повторных передач (RC) при передаче / повторных передачах сообщения, что позволяет ему точно обнаруживать слабые значения RTT и сглаженные значения RTT. Наконец, он включает механизм устаревания RTO как для малых, так и для больших оценок RTO, чтобы избежать ложных значений RTO в некоторых сетевых условиях.Этот метод устаревания основан на механизме CoCoA + и ожидает, пока CACC в конечном итоге повысит производительность после того, как значение RTO будет установлено по умолчанию в механизме устаревания. Это вызывает дополнительные задержки при ожидании повышения производительности CACC с течением времени. Более того, переменная RTTVAR стремится к нулю в случае, если последовательность одинаковых RTT является выборкой. Это приводит к тому, что значения RTO приближаются к измерению RTT. Кроме того, в случае импульсного трафика ни малый вес слабого RTT (K = 1), ни устранение слабой оценки не выгодны.Кроме того, значение RTO может резко увеличиваться из-за отсутствия механизма устаревания слабого RTO.

4.1.9. FASOR

Этот механизм управления перегрузкой работает в случае состояния буферной памяти и справляется с высокой частотой ошибок канала. В Fast-Slow RTO (FASOR) [26] вычисление RTO разделено на две категории. Вычисление быстрого RTO используется для однозначных выборок RTT, в то время как вычисление медленного RTO выполняется для неоднозначных выборок RTT, чтобы преодолеть глубокий буферный буфер и сильную перегрузку.Это позволяет избежать дополнительных задержек, а также помогает избежать ошибок под каналом за счет сокращения завершения потока.

Для отсрочки таймера повторной передачи FASOR представляет новый самонастраивающийся таймер, содержащий три переходных состояния, то есть FAST / FAST-SLOW-FAST / SLOW-FAST. Каждое из этих состояний имеет разную логику отсрочки передачи и адаптируется к динамическим состояниям сети. Это позволяет FASOR предотвращать дополнительное потребление энергии из-за ненужных повторных передач и баланс между агрессивными и консервативными повторными передачами.

Основная проблема предлагаемой схемы заключается в том, что она не включает в себя особую логику для отправителей, остающихся в режиме ожидания, что типично для CoAP. Более того, верхняя граница медленного RTO сохраняется 60 с, что может быть улучшено в дальнейшем.

4.1.10. pCoCoA

Bolettieri et al. выделите проблемы CoCoA + в [8] и предложите pCoCoA — точный алгоритм управления перегрузкой для решения этих проблем. Предлагаемый механизм основан на двух основных элементах:

Метод точной привязки запросов к ответам даже в случае повторных передач
Несколько модификаций алгоритма оценки RTO

Для точной привязки запросов к ответам , используется опция CoAP счетчика передач (TC).Это связывает сообщение ACK каждой передачи с соответствующим сообщением CON. Значение TC обновляется даже при повторных передачах; следовательно, он также обнаруживает ложные повторные передачи. Для случая ложной повторной передачи pCoCoA устанавливает флаг, чтобы учесть его при будущих вычислениях RTO.

Чтобы избежать исчезновения переменной RTTVAR из-за аналогичной выборки RTT за короткий период времени, оценивается максимальное среднее отклонение RTO. Таким образом, можно избежать проблем, связанных с внезапным изменением RTT, за счет использования максимального среднего отклонения, для уменьшения которого требуется больше времени, поэтому уменьшение конечного значения RTO ограничено.Кроме того, в случае ложных передач оценка SRTO растет быстрее из-за увеличения веса RTTVAR, что помогает ограничить последовательные ложные передачи.

4.1.11. CoCoA ++

CoCoA ++: Управление перегрузкой на основе градиента задержки: Другой механизм управления перегрузкой, основанный на градиенте измерений RTT во времени, предложен Rathod et al. в [27]. Предлагаемый метод обеспечивает устранение проблем с контролем перегрузки в стандартных CoAP, CoCoA и его вариантах, таких как CoCoA +.Эти методы используют измерения RTT для каждого пакета для прогнозирования перегрузки в сети, но эти измерения зашумлены и ненадежны. CoCoA ++, с другой стороны, полагается на Градиент задержки CAIA (CDG) [40] с целью прогнозирования сетевой перегрузки путем получения градиента RTT во времени и обеспечивает вероятностный коэффициент отсрочки передачи (PBF) для управления перегрузкой в сети.

Благодаря использованию градиента задержки, CoCoA ++ устраняет цель оценки слабого и сильного RTO. Кроме того, в отличие от CoCoA и CoCoA +, значение RTO не обновляется на основе выборок RTT для каждого пакета, вместо этого RTO обновляется после получения периодической информации о градиентах задержки от CDG.Это позволяет CoCoA ++ не полагаться на VBF и, следовательно, заменять его на PBF. Формула для расчета PBF приведена в уравнении (7).

PBF = 1,42, P [откат]> Xandg> 00,7, в противном случае

(7)

где P [отсрочка] — вероятность отсрочки, которую возвращает CDG, «X» — равномерно распределенное случайное значение, а «g» — градиент задержки. Вероятность отсрочки платежа сравнивается с равномерно распределенной случайной величиной «X». Отсрочка применяется к RTO только в том случае, если у нас есть положительная скорость изменения RTT.Это представлено условием g> 0.

В случае перегрузки, PBF увеличивает RTO в 1,42 раза, тогда как он уменьшает RTO в 0,7 раза при отсутствии перегрузки.

Проблема с CoCoA ++ заключается в том, что при более высокой средней скорости отправки пакетов последующие повторные передачи могут происходить быстро, в результате чего на узле быстро заканчиваются повторные передачи.

4.1.12. Genetic CoCoA ++

Другой алгоритм управления перегрузкой, основанный на CoCoA ++, предложенный Yadav et al.в [28], помимо проблемы больших изменений оценок RTO в CoCoA +, также упоминается, что алгоритмы управления перегрузкой, сохраняющие предыдущие состояния, недоступны для ограниченных устройств IoT из-за ограничений памяти. Поэтому они предлагают использовать CDG и генетический алгоритм (GA) для расчета RTO в течение фиксированного интервала времени. Метод использует RTT (min) вместо RTT (max) для расчета, чтобы получить лучшие результаты. Для определения перегрузки в сети используется разница между текущим и предыдущим RTT (мин.).RTT (мин) отслеживается в течение 5 с, и в этот период наблюдения минимальное значение RTT выбирается из всех наблюдаемых. После выбора выполняется кроссовер, который выполняется с учетом предыдущего и нового значения минимального RTT (RTTmin), а затем вычисляется PBF в соответствии с CDG, полученным из разницы предыдущего и нового RTT (min). Наконец, он вычисляет RTO и продолжает тот же процесс. Хотя он решает некоторые проблемы контроля перегрузки CoAP и CoCoA +, но 5-секундное время наблюдения может быть недостаточно для случая подводной и мобильной связи.Более того, предлагаемая схема не учитывает пакетный трафик.

4.1.13. Обратная связь о потере сообщения на основе

Схема управления перегрузкой с использованием обратной связи о потере сообщения: Схема управления перегрузкой на основе скорости была предложена в [29] для решения проблемы обнаружения перегрузки в CoAP по умолчанию. Для CoAP по умолчанию, по крайней мере, 2 из 16 сообщений должны быть переданы как сообщения CON для обнаружения перегрузки. Чтобы преодолеть эту проблему и обнаружить перегрузку в случае ненадежной передачи, предлагаемый метод определяет 1-битное поле в заголовке сообщения как «поле CS».Значение поля равно 0 или 1 в зависимости от типа переданного сообщения как CON или NON соответственно. Для каждой передачи пакет записывает поле CS в «CS_list_S», который представляет собой список, содержащий значения поля CS для отправителя. При получении сообщения узел-получатель обновляет тот же список на стороне получателя, называемый «CS_list_R». Список получателей затем отправляется обратно отправителю с ACK в случае сообщения CON. Однако в случае потери сообщения NON количество потерянных пакетов указывается в списке i на стороне получателя.е., CS_list_R и отправляет его отправителю в следующем сообщении ACK. Узел-отправитель сравнивает значение в своем списке при получении ACK и вычитает его, чтобы найти номер потери пакета. Это число потерь пакетов используется для определения текущей скорости передачи, которая, в свою очередь, вычисляет значение перегрузки. Таким образом, предлагаемый метод обнаруживает перегрузку в сети.

Для управления перегрузкой метод изменяет скорость передачи, а не размер окна перегрузки. Он использует механизм корзины с токенами для управления перегрузкой, предполагая, что размер корзины не ограничен.Когда есть пакет данных для отправки, он проверяет оставшийся размер токена и передает, только если размер токена больше, чем размер данных, в противном случае он ждет, пока не будет создан токен с большим размером. Предлагаемый метод изменяет скорость передачи пакетов в соответствии с загруженностью сети, регулируя скорость генерации токена. Хотя этот подход работает лучше с точки зрения скорости успешной передачи и пропускной способности; однако он не учитывает сценарий, при котором количество сообщений CON и NON будет одинаковым.В таком случае скорость потери передачи для сообщений CON не может быть определена.

4.1.14. На основе свежести контента

Схема управления перегрузкой предложена в [30], которая противодействует проблеме перегрузки в сети, контролируя размер окна перегрузки в реальном времени. Окно перегрузки варьируется на основе измеренного коэффициента перегрузки и актуальности информации о соотношении перегрузки. Каждый раз, когда узел-отправитель получает новое сообщение ACK, измеряется коэффициент перегрузки. Когда коэффициент перегрузки (CR), измеренный в предыдущем ACK, больше, чем текущее значение CR, размер окна перегрузки уменьшается, а когда предыдущее значение CR меньше текущего значения CR, окно перегрузки увеличивается, чтобы разрешить дополнительную передачу пакетов.Кроме того, исходный узел также измеряет актуальность информации о коэффициенте перегрузки, измеряя интервал в дополнение к текущему значению CR. Этот интервал является разницей между временем приема текущего и предыдущего ACK. Если интервал большой, информация CR считается устаревшей. Наконец, при приеме сообщения ACK исходный узел также измеряет RTT и различает его как слабый RTT (WRTT) или сильный RTT (SRTT). Если RTT — это SRTT, исходный узел рассматривает обновление в текущем размере окна перегрузки как окончательный размер окна перегрузки до приема следующего сообщения ACK, тогда как, если RTT равен WRTT, источник делит его на 2 и определяет, больше ли WRTT, чем 2xSRTT. .В случае, когда WRTT меньше 2xSRTT, предполагается, что сеть испытывает небольшую перегрузку, и достаточно небольшого уменьшения окна перегрузки. Однако в случае, когда WRTT больше 2xSTT, наблюдается высокая перегрузка в сети, и окно перегрузки должно быть уменьшено в достаточной степени.

4.1.15. BDP-CoAP

BDP-CoAP предлагает метод управления перегрузкой на основе скорости для CoAP [31], который является производным от протокола BBR (полоса пропускания узкого места и время двустороннего распространения).Система оценки узких мест (BW) BBR переработана, чтобы справляться с проблемами, связанными с потерями каналов и краткосрочной несправедливостью канала в сетях IoT. В случае краткосрочной несправедливости конкретный узел в сети IoT может получить канал на короткий период времени во временном окне и получить высокие мгновенные скорости доставки. Это заставляет BBR переоценивать доступную пропускную способность. BDP-CoAP использует средство оценки, которое объединяет измерения максимальной и минимальной скорости доставки для получения оценок пропускной способности узких мест, чтобы избежать завышенной оценки BW в случае краткосрочной несправедливости доступа к каналу.

BDP-CoAP также отслеживает количество пропущенных выборок полосы пропускания за период наблюдения и использует эту информацию, чтобы сделать оценку BW узкого места более или менее агрессивной для изменения скорости передачи соответственно.

4.1.16. CoAP-R

Другой механизм управления перегрузкой на основе скорости предложен Ancillotti et al. в [32] для решения проблем производительности CoCoA в случае легких и скачкообразных условий трафика и проблемы несправедливого распределения полосы пропускания в различных сценариях трафика.

Предлагаемый метод называется CoAP-R, который использует древовидную структуру маршрутизации развертываний IoT, чтобы помочь в обнаружении узких мест. Используя информацию об узких местах, предлагаемый метод использует справедливое распределение максимальной и минимальной доступной полосы пропускания в сети распределенным образом. Затем этот процесс регулирует скорость передачи сообщений устройств CoAP соответственно. Однако, поскольку предложенная схема предназначена для древовидной структуры маршрутизации, если узел неактивен в дереве, он пропустит время, когда будет выполнено распределение полосы пропускания.Кроме того, при неактивном узле оценка пропускной способности канала была бы невозможна, и это привело бы к неправильному распределению полосы пропускания между другими узлами.

Электроника | Бесплатный полнотекстовый | Управление потоковой передачей на основе CoAP для приложений Интернета вещей

1. Введение

С ростом количества услуг Интернета вещей (IoT) [1,2] были развернуты различные потоковые приложения, в которых мультимедийные данные, измеренные датчиками, будут доставляться на сервер с помощью потокового транспорта [ 3]. Потоковый транспорт отличается периодической и последовательной передачей данных.Сообщается, что обычные транспортные схемы с использованием HTTP и TCP не подходят для доставки приложений IoT, поскольку эти протоколы являются слишком тяжелыми и сложными операциями для поддержки небольших сенсорных устройств в сетях IoT. Между тем, недавно был предложен протокол ограниченного приложения (CoAP). CoAP — это протокол прикладного уровня поверх UDP, который можно использовать для повышения производительности связи с ограниченными устройствами на основе Интернета вещей в беспроводных сенсорных сетях.CoAP является более легким по сравнению с HTTP и предоставляет множество функций для служб Интернета вещей, например обнаружение ресурсов и передачу блоков.

Однако традиционная схема CoAP не учитывает обработку ошибок и управление потоком для потоковой передачи, и, таким образом, производительность пропускной способности имеет тенденцию ухудшаться, в частности, в беспроводных сенсорных сетях. Например, в CoAP через UDP, если сообщение потеряно, повторная передача произойдет после события тайм-аута, и, таким образом, механизм восстановления после ошибок может иметь тенденцию увеличивать большую задержку передачи.CoAP через TCP может быстро восстановить потерянный пакет, используя быструю повторную передачу TCP, но механизм TCP может добавить некоторые накладные расходы в среду IoT. Кроме того, CoAP поверх TCP наследует сложность механизмов TCP, которые не подходят для потоковых служб в реальном времени в среде IoT, как показано в проблеме блокировки заголовка (HOL).

Чтобы преодолеть эти проблемы, мы предлагаем управление потоком на основе CoAP (CoAP-SC), которое является расширением CoAP поверх UDP с обработкой ошибок и контролем потока для повышения пропускной способности.Предлагаемая схема разработана с учетом порядкового номера сообщения с данными, использования сообщений ACK и размера буфера отправителя.

Эта статья организована следующим образом. В разделе 2 кратко рассматриваются существующие схемы потокового транспорта. В разделе 3 мы описываем предлагаемую схему CoAP-SC (CoAP с потоковым управлением). В разделе 4 обсуждаются результаты экспериментов по анализу производительности. Наконец, раздел 5 завершает эту статью.

2. Сопутствующие работы

2.1. CoAP через UDP

CoAP [4] — широко используемый протокол в ограниченных сетевых средах, таких как сенсорные сети. Первоначально CoAP на основе UDP был разработан для минимизации потерь сетевых ресурсов из-за установления соединения и повторной передачи в сетевых средах с низким энергопотреблением, высокими потерями и низкой пропускной способностью сети [5]. CoAP поддерживает архитектуру передачи репрезентативного состояния (REST), учитывая совместимость с веб-службами [6,7]. Кроме того, он предоставляет важные функции для разработки служб, которые не поддерживаются UDP, например, надежную передачу данных.CoAP был стандартизирован в IETF CoRE WG. На рисунке 1 показан формат заголовка CoAP поверх UDP.

Первые 4 бита заголовка CoAP over UDP относятся к версии. Сообщение CoAP имеет четыре типа: подтверждаемое, неподтвержденное, подтверждение и сброс. Это выражается в следующих 4 битах. Следующие 8 бит — это длина токена. TKL указывает длину токена от 0 до 8, а 9-15 зарезервированы. Поле кода разделено на 3-битный класс (старшие значащие биты) и 5-битные детали (младшие значащие биты).Поле кода указывает тип сообщения, такой как GET, POST, PUT, DELETE, в сообщении запроса и код ответа, например 2.01 Created, в ответном сообщении. Идентификатор сообщения используется для обнаружения дублирования, а также для дополнительной надежности. Пары сообщений запрос-ответ имеют одинаковый идентификатор сообщения. Если длина токена не равна 0, токен (обозначенный TKL) будет расположен после поля идентификатора сообщения. Значение токена служит идентификатором транзакции. Если через сообщение CoAP передаются большие данные, они фрагментируются из-за характеристик UDP.Все фрагментированные сообщения и соответствующее ответное сообщение указывают на то, что это фрагмент данных с одинаковым значением токена. Опция CoAP расположена между основным заголовком CoAP и полезной нагрузкой, и большинство расширений CoAP используют это поле опции.

CoAP предоставляет множество функций, которые UDP не предоставляет для развития услуг. Однако он не подходит для потоковых сервисов [8,9]. Для потоковой передачи беспроводной датчик (клиент или отправитель) периодически и последовательно передает свои потоковые данные обнаружения на сервер (или получатель).По сути, CoAP через UDP разработан для простой передачи сообщений и, следовательно, имеет некоторые ограничения для потоковой передачи. Это связано с тем, что CoAP был разработан на основе модели REST и использует UDP в качестве основного протокола. CoAP предоставляет только простой механизм восстановления после ошибок с использованием типов CON и ACK при передаче данных. На рисунке 2 показан механизм обработки ошибок CoAP через UDP. На этапе (1) сообщения ACK передаются для всех сообщений CON. Этот механизм может создавать ненужные ACK.Как вы также можете видеть на шаге (2), в этом протоколе нет поля для порядкового номера. На рисунке 3 показан сценарий обработки ошибок для CoAP через UDP. На этом рисунке сообщение ACK для сообщения PUT (/ stream / 20) было потеряно, и сообщение PUT повторно передается после отправки сообщения PUT (/ stream / 25). Кроме того, CoAP через UDP повторно передает сообщения данных, если происходит событие тайм-аута. Таким образом, это может привести к снижению производительности в случае, если сообщения должны обрабатываться последовательно. Кроме того, CoAP поверх UDP не предоставляет никакого механизма управления потоком для облегчения потоковой передачи данных на отправителе.Эти функции, как правило, приводят к снижению производительности в беспроводных сетях и сетях с потерями. Некоторые работы были проведены для преодоления недостатков базовой модели CoAP, которая включает схемы CoAP-Observe [10,11,12]. На рисунке 4 показан сценарий CoAP-Observe. Получатель инициирует наблюдение, отправляя отправителю сообщение запроса GET, содержащее параметр CoAP-Observe. Отправитель уведомляет получателя об изменении статуса, отправляя сообщение, включающее параметр «Наблюдать», всякий раз, когда изменяется статус ресурса.В настоящее время параметр «Наблюдать» может служить порядковым номером. Однако эти схемы не позволяют эффективно устранять ошибки и управление потоком для потоковой передачи. Значения, включенные в параметр «Наблюдать», можно использовать только для изменения порядка. То есть его нельзя использовать для других целей, например для быстрой повторной передачи. Таким образом, они по-прежнему подвержены снижению производительности в беспроводной сети с потерями.

Следует отметить, что существующая схема CoAP / UDP предоставляет простой механизм CON / ACK для надежности, тогда как в этом документе предлагается более разработанный механизм управления потоковой передачей, учитывая порядковый номер сообщения данных, использование сообщений ACK и буфер размер отправляющего буфера.Это будет полезно для повышения производительности в сетях с потерей данных.

2.2. CoAP через TCP

По мере постепенного роста сервисов Интернета вещей активно проводятся исследования конвергенции с веб-сервисами. В связи с требованием поддержки TCP для IoT был предложен CoAP поверх TCP [13]. Поскольку сообщение CoAP доставляется с использованием TCP, надежная передача гарантируется, и поэтому сообщения CoAP Confirmable и Acknowledge больше не нужны [14]. По этой причине поле типа было удалено.Вместо этого были добавлены поля для выражения информации о длине сообщения (поле длины и поле расширенной длины), поскольку заголовок TCP не включает поле для информации о длине. На рисунке 5 показан формат заголовка CoAP через TCP. Если CoAP через TCP используется для потоковой службы, будут использоваться механизмы управления потоком TCP и контроля ошибок [15]. Как показано на шагах (1) и (2) рисунка 6, можно воспользоваться функцией накопительного ACK TCP. Таким образом, мы ожидаем, что CoAP через TCP может обеспечить лучшую производительность, чем CoAP через UDP, если сообщения данных должны обрабатываться последовательно.Однако для устройств IoT в беспроводной сети сообщения трехстороннего подтверждения TCP (показанные на шаге (3) на рисунке 6) станут обузой. Следовательно, это может вызвать снижение производительности. На рисунке 7 показан механизм обработки ошибок CoAP через TCP. На этапе (1) сообщение PUT (/ stream / 10) было потеряно, и сообщение повторной передачи было немедленно отправлено алгоритмом быстрой повторной передачи TCP. Кроме того, TCP может уменьшить количество повторных передач за счет линейных комбинаций данных и совокупного ACK [16,17,18].На шаге (2) мы видим, что размер повторно переданного TCP-пакета увеличился. Это потому, что этот пакет включает два сообщения PUT (/ stream / 10, / stream / 11). Мы также можем видеть совокупный ACK на рисунке. ACK-сообщение TCP может уменьшить задержку повторной передачи. Однако это может увеличить количество повторных передач из-за потери сообщения ACK. Рисунок 8 иллюстрирует эту ситуацию. На этом рисунке сообщение PUT (/ stream / 12) было повторно передано из-за потери ACK. Кроме того, трехсторонний механизм подтверждения TCP не подходит для потоковой передачи данных IoT в реальном времени в мобильных сетях, в которых многие может произойти повторное подключение.На рисунке 9 отправитель повторно подключается к получателю в результате передачи обслуживания. В это время произошла задержка около 500 мс из-за процесса трехэтапного установления связи. Кроме того, мы видим, что переданное сообщение PUT (/ stream / 14, / stream / 15) было потеряно, пока отправитель не подтвердил, что соединение было разорвано. TCP обеспечивает надежность во время соединения, но не обеспечивает надежность при повторном подключении. Таким образом, разработчик должен выполнять дополнительные работы на прикладном уровне.Задержка, вызванная трехсторонним рукопожатием или дополнительной работой, делает TCP непригодным для потоковых сервисов в реальном времени. Более того, CoAP поверх TCP имеет тенденцию унаследовать проблемы снижения производительности TCP, такие как проблема блокировки Head of Line (HoL) в беспроводные сети, поскольку он работает поверх TCP [19,20,21]. Другой недостаток CoAP over TCP состоит в том, что мы должны модифицировать ядро для решения этих проблем [22].

3. Предлагаемая схема управления потоковой передачей CoAP

На основе анализа, приведенного в предыдущем разделе, в этом документе предлагается усовершенствованная схема CoAP с управлением потоковой передачей (CoAP-SC) для потоковой передачи IoT.Поскольку UDP не предоставляет функции обработки ошибок и управления потоком, TCP может использоваться для служб, требующих надежности. Однако CoAP через TCP по-прежнему подвержен модификации ядра и снижению производительности потокового транспорта IoT. Таким образом, в этой статье мы проектируем схему CoAP-SC на основе CoAP поверх UDP.

В предлагаемой схеме мы предполагаем, что отправитель (клиент) периодически и последовательно передает потоковые данные получателю (серверу) для потоковой передачи IoT.Мы предлагаем механизмы управления потоковой передачей для повышения пропускной способности. Предлагаемый механизм управления выполняет функции обработки ошибок и управления потоком. Для этого отправитель присваивает каждому сообщению данных порядковый номер (SN), а получатель дает номер ACK (AN) для подтверждения успешного приема сообщения с данными.

3.1. Инициализация для CoAP-SC

Предлагаемая схема использует существующую операцию инициализации CoAP, чтобы организовать ресурсы для потоковой передачи между двумя конечными узлами.Эти операции будут полезны для создания соединения для потокового транспорта. На рисунке 10 показан процесс инициализации в CoAP-SC.

На рисунке отправитель сначала запрашивает создание ресурса у получателя с помощью сообщения POST. Это сообщение будет включать параметры, связанные со службой потоковой передачи, например информацию для аутентификации. Для CoAP-SC размер буфера отправителя для потоковой передачи также должен быть включен в сообщение POST. Следует отметить, что остальная информация и операции такие же, как и в существующем CoAP.Когда ресурс успешно создан, получатель возвращает URL-адрес сгенерированного ресурса в ответном сообщении 2.01. Затем отправитель отправляет запрос GET на полученный URL, а получатель отвечает сообщением ответа 2.05.

Следует отметить, что GET и его ответные сообщения должны содержать поля порядкового номера (SN) и номера ACK (AN). SN последовательно назначается для каждого сообщения данных отправителем, тогда как AN определяется получателем, чтобы указать, что соответствующие сообщения данных были успешно приняты.Обратите внимание, что AN используется как совокупный номер ACK. В процессе инициализации и SN, и AN будут установлены на 0.

3.2. Обработка ошибок для CoAP-SC

В CoAP с потоковым управлением отправитель передает сообщения данных получателю, а получатель отвечает отправителю сообщениями ACK, если необходимо, в соответствии с обработкой ошибок и управлением потоком.

Все сообщения с данными, генерируемые отправителем, должны содержать опцию CoAP-SC, которая будет указана в Разделе III-D этого документа.Опция CoAP-SC в сообщении с данными включает поля SN и AN, которые обозначаются dataMsg.SN и dataMsg.AN соответственно. Первое сообщение с данными будет иметь dataMsg.SN = 1 и dataMsg.AN = 0.

Каждый раз, когда получатель получает сообщение с данными от отправителя, он обновляет свое собственное значение AN (обозначается Receiver.AN и изначально устанавливается на 0. ) как наибольшее значение SN сообщений с данными, которые были успешно получены в совокупности. Как это сделано в существующем CoAP, если получатель не получает никаких сообщений с данными в течение определенного времени, он отправляет сообщение ACK, чтобы проинформировать отправителя о статусе AN.

В нормальном режиме работы получатель получит сообщение с данными с dataMsg.SN = Receiver.AN + 1, а затем обновит свой файл Receiver.AN как dataMsg.SN.

На основе этого описания при обработке ошибок CoAP-SC потеря сообщения данных определяется получателем, если выполняется следующее условие:

dataMsg.SN−receiver.AN> 1

Обратите внимание, что указанное выше условие указывает на возможную потерю сообщений данных, поскольку получатель будет ожидать сообщения данных с dataMsg.SN = получатель.AN + 1. Таким образом, если обнаружена потеря данных, получатель отправляет сообщение ACK отправителю в качестве запроса на повторную передачу. Это сообщение ACK включает в себя опцию CoAP-SC с SN сообщений данных, которые должны быть повторно переданы.

На рисунке 11 показан пример операций обработки ошибок для CoAP-SC. На рисунке первые данные (SN = 1, AN = 0) передаются, и получатель обновляет свой получатель. AN как 1. Второе сообщение данных потеряно, а третье успешно получено получателем.В этом случае dataMsg.SN (= 3)> Receiver.AN (= 1) + 1, что указывает на потерю сообщения данных с SN = 2. Это обнаружение потери побуждает получатель генерировать сообщение ACK с SN = 2 и AN = 1. Такое сообщение ACK генерируется повторно до тех пор, пока соответствующее сообщение данных не будет повторно передано и восстановлено, как показано на рисунке. На рисунке 12 получатель подтверждает, что сообщения PUT (SN: 39 ~ 43, AN: 36) были отправлены. потеряно, когда он получает сообщение PUT (SN: 44, AN: 36) и отправляет управляющие сообщения (SN: 39 ~ 43, AN: 38), чтобы запросить повторную передачу.Отправитель повторно передает запрошенные сообщения. В CoAP-SC механизм обработки ошибок может преодолеть недостатки CoAP по UDP, обеспечивая быструю повторную передачу.

3.3. Управление потоком для CoAP-SC

При обработке ошибок приемник сгенерирует сообщение ACK, если обнаружена потеря данных. Сообщения ACK также будут созданы для управления потоком. Это сообщение ACK предназначено для предоставления обновленной информации AN отправителю и, таким образом, облегчить отправителю передачу как можно большего количества данных.Это приведет к увеличению пропускной способности.

Управление потоком для CoAP-SC разработано с учетом следующих двух моментов. Во-первых, сообщение ACK получателя может быть потеряно в сети. Во-вторых, сообщения ACK полезны для повышения пропускной способности, тогда как слишком большое количество сообщений ACK может скорее ухудшить производительность пропускной способности. Таким образом, генерацией ACK для управления потоком нужно управлять соответствующим образом.

Исходя из этих соображений, получатель будет генерировать сообщения ACK на основе значений SN и AN сообщения данных и размера буфера отправителя.Обратите внимание, что размер буфера отправителя уже сообщается получателю в процессе инициализации (см. Раздел 3.1). В частности, при получении сообщения с данными получатель отправит сообщение ACK отправителю, если выполняются следующие условия:

(a) dataMsg.SN − dataMsg.AN≥ 13 · bufsize или

(b) dataMsg.SN−dataMsg.AN ≥ 23 · bufsize

Когда условие (a) становится истинным, сообщение ACK генерируется только один раз. С другой стороны, всякий раз, когда условие (b) истинно, для каждого сообщения данных генерируется сообщение ACK.Обратите внимание, что условие (a) указывает на предыдущий сигнал тревоги о заполнении буфера, тогда как условие (b) представляет собой критический сигнал для заполнения буфера, который может быть получен из потери сообщения ACK.

На рисунке 13 показан пример операций управления потоком для CoAP-SC. На рисунке предполагается, что отправляющий буфер может хранить максимум шесть сообщений с данными (размер буфера = 6). Первое сообщение ACK для управления потоком генерируется условием (a), когда получатель принимает второе сообщение данных (SN = 2, AN = 0).Второе сообщение ACK также генерируется условием (a) для сообщения данных (SN = 4, AN = 2), но оно теряется. Третье сообщение ACK генерируется условием (b) для сообщения данных (SN = 6, AN = 2). Сообщения ACK для управления потоком содержат те же значения SN и AN, как показано на рисунке. На рисунке 14 сообщение управления (SN: 21, AN: 21) потеряно. В случае TCP потеря ACK вызывает повторную передачу. Однако в CoAP-SC отправителю не нужно повторно передавать. На рисунке, когда получатель получает управляющее сообщение (SN: 25, AN: 18), он проверяет, что буфер отправителя заполнен более чем на 2/3, а затем передает управляющее сообщение, чтобы очистить буфер каждый раз. он получает сообщение с данными.На этом рисунке были переданы управляющие сообщения (SN: 25, AN: 25 / SN: 26, AN: 26, SN: 27, AN: 27 / SN: 28, AN: 28). Отправитель, который получает управляющие сообщения, очищает буфер и обновляет его значение AN. После приема управляющего сообщения (SN: 28, AN: 28) можно подтвердить, что значение AN было обновлено в сообщении PUT (SN: 29, AN: 28).

3.4. Опция CoAP для CoAP-SC

Для CoAP-SC мы определяем заголовок опции CoAP-SC, как показано на рисунке 15, который включает 8-байтовые поля Option Delta, 4-байтовые поля SN и 4-байтовые поля AN.Все сообщения с данными и сообщения ACK, используемые для управления ошибками и потоками, будут включать эту опцию CoAP-SC. В этом письме номер опции CoAP-SC произвольно установлен на 100.

4. Экспериментальный анализ производительности

Для анализа производительности предложенная схема CoAP-SC реализована и сравнивается с существующими схемами. Существующие схемы CoAP через TCP и CoAP через UDP экспериментируются с использованием готовых библиотек с открытым исходным кодом [23]. Предлагаемая схема CoAP-SC также реализуется с использованием go-coap, и полученные исходные коды публично распространяются [24].Для экспериментов в качестве отправителя использовался Raspberry Pi, а в качестве получателя — универсальный персональный компьютер. На рисунке 16 показана тестовая среда. Отправители и получатели подключаются через точку доступа (AP). Пропускная способность между точками доступа была установлена на 1 Мбит / с. Чтобы смоделировать потерю пакетов, мы генерируем событие потери пакета, используя случайно сгенерированное число на AP каждую секунду, как показано на рисунке 17.

Для оценки общей производительности CoAP-SC в сети с коэффициентом ошибок 0.1, мы сначала сравнили средние задержки передачи для трех схем-кандидатов. В этом эксперименте клиент измеряет температуру каждые 500 мсек и отправляет измеренные данные (через 100 сообщений) на сервер. Всего было проведено 10 экспериментов и получены средние задержки.

На рисунке 18 показаны средние задержки, необходимые для передачи 100 сообщений последовательно в течение 10 попыток. На этом рисунке мы видим, что CoAP через UDP дает большую задержку, чем CoAP через TCP. Это связано с недостатком CoAP по UDP, который повторно передается, когда происходит событие тайм-аута для потери пакета.Кроме того, мы видим, что предложенная схема CoAP-SC обеспечивает меньшие задержки, чем две существующие схемы. Это связано с тем, что CoAP-SC обеспечивает быструю повторную передачу, а также потому, что повторные передачи из-за потери ACK могут быть уменьшены.

С этого момента мы проводим еще несколько различных экспериментов, чтобы оценить производительность предложенной схемы CoAP-SC. Для потоковой передачи отправитель передает получателю всего 600 сообщений данных (N) с размером полезной нагрузки 150 байтов. Интервал времени между двумя последовательными сообщениями данных установлен на 500 мс.С другой стороны, для оценки производительности используются разные коэффициенты ошибок пакетов и размеры буферов. Частота ошибок пакетов (P (E)) в сети настраивается в диапазоне 0–0,3 (30%), а размер буфера отправителя варьируется от 1 до 10 сообщений с данными.

Для каждого эксперимента измеряются три показателя производительности: количество повторно переданных пакетов (NRP), общее время блокировки (TBT) и общая задержка передачи (TTD).

4.1. Количество повторно переданных пакетов (NRP)

NRP представляет собой общее количество сообщений с данными, которые были повторно переданы отправителем во время передачи данных.Следует отметить, что NRP будет зависеть от того, насколько эффективно выполняется управление потоком при потоковой передаче. Обычно повторная передача происходит при потере пакета данных. Повторная передача также будет происходить без необходимости, если пакет ACK потерян. Обратите внимание, что предложенная схема была разработана с учетом потери ACK.

На рисунке 19 показаны характеристики NRP для различных коэффициентов ошибок. На рисунке мы видим, что NRP увеличиваются по мере увеличения количества ошибок пакетов для всех схем-кандидатов. Однако мы отмечаем, что предлагаемая схема CoAP-SC дает меньшие NRP, чем существующие схемы CoAP.Разрыв в производительности увеличивается по мере увеличения количества ошибок. Это связано с тем, что предлагаемая схема выполняет обработку ошибок и управление потоком с учетом потери ACK, тогда как существующие схемы имеют тенденцию выполнять ненужные повторные передачи. В случае существующих схем, если сообщение ACK сообщения данных потеряно, сообщение данных также передается повторно. Среди существующих схем CoAP на основе TCP обеспечивает лучшую производительность, чем CoAP на основе UDP. Это связано с тем, что схема CoAP через TCP поддерживает кумулятивный ACK, и, таким образом, количество повторных передач из-за потери пакета ACK может быть уменьшено по сравнению со схемой CoAP через UDP.По результатам мы отмечаем, что предложенная схема CoAP-SC использует преимущества выборочного ACK, а также кумулятивного ACK через управление потоковой передачей с SN и AN. В целом, мы видим, что предложенная схема CoAP-SC дает лучшую производительность, чем две существующие схемы. На рисунке 20 сравнивается производительность NRP для разных размеров буфера. Схема CoAP через UDP обеспечивает более крупные NRP, чем CoAP через TCP и CoAP-SC. Следует отметить, что CoAP-SC дает лучшую производительность, чем CoAP по TCP для больших размеров буфера.Это связано с тем, что предлагаемая схема может уменьшить ненужные повторные передачи за счет использования обработки ошибок и управления потоком. Следует отметить, что предложенная схема CoAP-SC выполняет управление потоком на основе отправляющего буфера. Таким образом, количество сообщений ACK может быть уменьшено, поскольку получатель будет проверять состояние буфера отправителя, используя значения SN и AN. Получатель также может активно передавать управляющее сообщение, чтобы очистить буфер отправителя.

4.2. Общее время блокировки (TBT)

TBT означает время, в течение которого буфер отправки находится в состоянии заполнения, в течение которого дальнейшие передачи данных будут заблокированы.Следует отметить, что TBT будет зависеть от того, насколько эффективно выполняется управление потоком при потоковой передаче.

На рисунке 21 показаны TBT схем-кандидатов для различных коэффициентов ошибок. Все схемы-кандидаты обеспечивают почти одинаковые TBT для низкого уровня ошибок. Однако предложенная схема CoAP-SC обеспечивает лучшую производительность, чем две существующие схемы, для высокого уровня ошибок. Это связано с тем, что предлагаемая схема может эффективно выполнять управление потоком даже в сетевых средах с потерями. В схеме CoAP через UDP управление потоком не выполняется.Таким образом, все сообщения удаляются из буфера при получении соответствующего сообщения ACK. Однако CoAP через TCP обеспечивает кумулятивный ACK с быстрой повторной передачей. Это делает его менее чувствительным к событию потери ACK по сравнению с CoAP через UDP. Между тем, CoAP-SC обеспечивает кумулятивный ACK и быструю повторную передачу, как это сделано в TCP. Кроме того, поскольку получатель передает управляющее сообщение в соответствии со статусом буфера отправителя, полезно уменьшить время блокировки. На рисунке 22 сравниваются TBT схем-кандидатов для разных размеров буфера.По мере увеличения размера буфера TBT имеет тенденцию уменьшаться для всех схем-кандидатов. Между тем, мы видим, что предложенная схема CoAP-SC дает лучшую производительность среди трех схем-кандидатов за счет использования эффективного управления потоком, когда размер буфера небольшой.

4.3. Общая задержка передачи (TTD)

TTD означает время, в течение которого пакеты были успешно доставлены. Следует отметить, что TTD зависит от того, насколько эффективно выполняется управление потоком и обработка ошибок при потоковой передаче.

На рисунках 23 и 24 показаны TTD трех схем-кандидатов для разных частот ошибок и размеров буфера соответственно. Из рисунков видно, что предложенная схема обеспечивает более низкие значения TTD, чем две существующие схемы для всех экспериментов. Этот выигрыш в производительности происходит из-за ошибок и управления потоком в предлагаемой схеме. Разрыв в производительности увеличивается по мере увеличения количества ошибок и размера буфера в сети.

CoAP через UDP выполняет повторную передачу в зависимости от тайм-аута при возникновении ошибки, но CoAP через TCP сокращает задержку, выполняя быструю повторную передачу на основе ACK.CoAP-SC также выполняет быструю повторную передачу. Однако, в отличие от TCP, количество повторных передач будет уменьшено в CoAP-SC, поскольку получатель запрашивает повторную передачу только при получении следующего сообщения с данными. Это, как правило, дает лучшую производительность с точки зрения общей задержки передачи для всех сообщений.

5. Выводы

В этой статье мы предложили схему управления потоком CoAP с обработкой ошибок и управлением потоком для потокового транспорта IoT. Из результатов экспериментов видно, что предложенная схема обеспечивает лучшую пропускную способность, чем существующие схемы CoAP на основе UDP и CoAP на основе TCP.Похоже, что этот прирост производительности достигается за счет операций управления потоковой передачей на основе порядкового номера (SN), номера ACK (AN) и буфера отправки. В заключение, существующие схемы CoAP / UDP и CoAP / TCP могут использоваться для надежных услуг. Однако предложенная схема также может рассматриваться как схема-кандидат для потоковых сервисов в реальном времени, в частности, в сетях IoT с потерями данных, с управлением соответствующими параметрами, такими как SN и AN и т. Д. С другой стороны, похоже, что предложенная схема требует еще некоторых доработок для уменьшения размера пакета для среды IoT.Для дальнейшего изучения необходимо изучить некоторые методы, которые включают линейные комбинации данных, стирающее кодирование и сжатие заголовка [25].

Enhanced DTLS со схемой аутентификации на основе CoAP для Интернета вещей в приложении для здравоохранения

Krawczyk H, Paterson KG, Wee H (2013) О безопасности протокола TLS: систематический анализ. В: Достижения в криптологии — CRYPTO 2013. Springer, Берлин, стр. 429–448

Глава Google Scholar

Jager T, Kohlar F, Schäge S, Schwenk J (2017) Установление аутентифицированного конфиденциального канала и безопасность TLS-DHE. J Cryptol 20: 1–49

MathSciNet МАТЕМАТИКА Google Scholar

Paulson LC (1999) Индуктивный анализ Интернет-протокола TLS. ACM Trans Inf Syst Secur (TISSEC) 2 (3): 332–351

Статья Google Scholar

Сантос-Гонсалес I, Риверо-Гарсия А., Молина-Хиль Дж., Кабальеро-Хил П. (2017) Внедрение и анализ протоколов потоковой передачи в реальном времени.Датчики 17 (4): 846

Артикул Google Scholar

Schulzrinne H, Rosenberg J (2000) Протокол инициирования сеанса: Интернет-ориентированная сигнализация. IEEE Commun Mag 38 (10): 134–141

Статья Google Scholar

Keoh SL, Kumar SS, Tschofenig H (2014) Защита Интернета вещей: перспектива стандартизации. IEEE Internet Things J 1 (3): 265–275

Статья Google Scholar

Kothmayr T, Schmitt C, Hu W, Brünig M, Carle G (2013) Безопасность на основе DTLS и двусторонняя аутентификация для Интернета вещей. Ad Hoc Netw 11 (8): 2710–2723

Статья Google Scholar

Li X, Niu J, Khan MK, Liao J (2013) Улучшенная схема аутентификации удаленного пользователя по паролю на основе смарт-карты. J Netw Comput Appl 36 (5): 1365–1371

Статья Google Scholar

Li X, Ma J, Wang W, Xiong Y, Zhang J (2013) Новая схема аутентификации удаленного пользователя на основе смарт-карты и динамического идентификатора для многосерверных сред. Math Comput Model 58 (1): 85–95

Статья Google Scholar

10.

Li X, Niu J, Kumari S, Wu F, Choo KKR (2017) Надежная схема трехфакторной аутентификации на основе биометрии для глобальных мобильных сетей в умном городе. Fut Gener Comput Syst. https://doi.org/10.1016/j.future.2017.04.012

Артикул Google Scholar

11.

Li X, Ибрагим MH, Kumari S, Sangaiah AK, Gupta V, Choo KKR (2017) Схема анонимной взаимной аутентификации и согласования ключей для носимых датчиков в беспроводных телесетях. Comput Netw. https://doi.org/10.1016/j.comnet.2017.03.013

Артикул Google Scholar

12.

Альгамди Т.А., Ласеба А., Айаш М. (2013) Анализ безопасности протокола ограниченного приложения в Интернете вещей.В: Вторая международная конференция по коммуникационным технологиям будущего поколения (FGCT), 2013 г. IEEE, pp. 163–168

13.

Ishaq I, Hoebeke J, Moerman I., Demeester P (2016) Экспериментальная оценка одноадресной и многоадресной групповой связи Coap. Датчики 16 (7): 1137

Артикул Google Scholar

14.

Hummen R, Wirtz H, Ziegeldorf JH, Hiller J, Wehrle K (2013) Настройка сквозных протоколов IP-безопасности для Интернета вещей.В: 21-я Международная конференция по сетевым протоколам (ICNP), 2013 г. IEEE, pp. 1–10

15.

Укил А., Бандйопадхьяй С., Бхаттачарья А., Пал А., Бозе Т. (2014) Облегченная схема безопасности для приложений Интернета вещей с использованием CoAP. Int J Perv Comput Commun 10 (4): 372–392

Google Scholar

16.

Modadugu N, Rescorla E (2004) Разработка и реализация датаграммы TLS. In: NDSS

17.

Rescorla E, Modadugu N (2012) Версия 1 безопасности транспортного уровня дейтаграмм.2

18.

Сегал А., Перельман В., Курила С., Шонвальдер Дж. (2012) Управление устройствами с ограниченными ресурсами в Интернете вещей. IEEE Commun Mag 50 (12): 1–6

Статья Google Scholar

19.

Вучинич М., Тураншо Б., Руссо Ф., Дуда А., Дэймон Л., Гиззетти Р. (2015) ОСКАР: архитектура безопасности объектов для Интернета вещей. Ad Hoc Netw 32: 3–16

Статья Google Scholar

20.

Tiloca M, Gehrmann C, Seitz L (2016) О повышении устойчивости к отказу в обслуживании и масштабируемости предоставления ключей при рукопожатии DTLS. Int J Inf Secur 17: 1–21

Google Scholar

21.

Porambage P, Schmitt C, Kumar P, Gurtov A, Ylianttila M (2014) Pauthkey: всеобъемлющий протокол аутентификации и схема создания ключей для беспроводных сенсорных сетей в распределенных приложениях IOT. Int J Distrib Sensor Netw 10 (7): 357–366

Артикул Google Scholar

22.

Schonwalder J, Marinov V (2011) О влиянии протоколов безопасности на производительность SNMP. IEEE Trans Netw Serv Manag 8 (1): 52–64

Статья Google Scholar

23.

Nguyen KT, Laurent M, Oualha N (2015) Обзор безопасных протоколов связи для Интернета вещей. Ad Hoc Netw 32: 17–31

Статья Google Scholar

24.

Park J, Kwon H, Kang N (2016) Сотрудничество IoT-Cloud для установления безопасного соединения для легких устройств.Wirel Netw 23: 1–12

Статья Google Scholar

25.

Раза С., Зейтц Л., Ситенков Д., Селандер Г. (2016) S3K: масштабируемая безопасность с симметричными ключами — создание ключей DTLS для Интернета вещей. IEEE Trans Autom Sci Eng 13 (3): 1270–1280

Статья Google Scholar

26.

Hennebert C, Dos Santos J (2014) Протоколы безопасности и вопросы конфиденциальности в стеке 6LoWPAN: синтез.IEEE Internet Things J 1 (5): 384–398

Статья Google Scholar

27.

Bormann C, Castellani AP, Shelby Z (2012) Coap: протокол приложения для миллиардов крошечных интернет-узлов. IEEE Internet Comput 16 (2): 62–67

Статья Google Scholar

28.

Shelby Z (2010) Встроенные веб-службы. IEEE Wirel Commun 17 (6): 234–249

Google Scholar

29.

Ludovici A, Moreno P, Calveras A (2013) TinyCoAP: реализация нового протокола ограниченного приложения (CoAP) для встраивания веб-сервисов RESTful в беспроводные сенсорные сети на основе TinyOS. J Sensor Actuator Netw 2 (2): 288–315

Артикул Google Scholar

30.

Sheng Z, Yang S, Yu Y, Vasilakos A, Mccann J, Leung K (2013) Обзор набора протоколов IETF для Интернета вещей: стандарты, проблемы и возможности.IEEE Wirel Commun 20 (6): 91–98

Статья Google Scholar

31.

Raza S, Shafagh H, Hewage K, Hummen R, Voigt T (2013) Lithe: легкий безопасный CoAP для Интернета вещей. IEEE Sens J 13 (10): 3711–3720

Статья Google Scholar

32.

Карагианнис В., Хатзимисиос П., Васкес-Галлего Ф., Алонсо-Сарате Дж. (2015) Обзор протоколов прикладного уровня для Интернета вещей.Trans IoT Cloud Comput 3 (1): 11–17

Google Scholar

33.

Ge M, Hong JB, Guttmann W, Kim DS (2017) Платформа для автоматизации анализа безопасности Интернета вещей. J Netw Comput Appl 83: 12–27

Статья Google Scholar

34.

Maleh Y, Ezzati A, Belaissaoui M (2016, октябрь) Улучшенный протокол DTLS для приложений Интернета вещей. В: Международная конференция по беспроводным сетям и мобильной связи, 2016 г. (WINCOM).IEEE, pp. 168–173

35.

Osterlind F, Dunkels A, Eriksson J, Finne N, Voigt T (2006) Межуровневое моделирование сенсорной сети с помощью cooja. В: Proceedings 2006 31-я конференция IEEE по локальным компьютерным сетям. IEEE, pp. 641–648

36.

Maleh Y, Abdellah E, Belaissaoui M (2016) Анализ DoS-атак и улучшение протокола DTLS для Интернета вещей. В: Международная конференция ACM по большим данным и передовым беспроводным технологиям (BDAW’2016)

37.

Гарсия-Морчон О., Кео С.Л., Кумар С., Морено-Санчес П., Видал-Мека Ф., Зигельдорф Дж. Х. (2013 г.) Защита Интернета вещей на основе IP с помощью HIP и DTLS. В: Материалы шестой конференции ACM по безопасности и конфиденциальности в беспроводных и мобильных сетях. ACM, pp. 119–124

38.

Канг Н., Парк Дж., Квон Х., Юнг С. (2015) ESSE: эффективное безопасное установление сеанса для интегрированных в Интернет беспроводных сенсорных сетей. Int J Distrib Sensor Netw 11 (8): 43–54

Артикул Google Scholar

39.

Moosavi SR, Gia TN, Rahmani AM, Nigussie E, Virtanen S, Isoaho J, Tenhunen H (2015) SEA: безопасная и эффективная архитектура аутентификации и авторизации для здравоохранения на основе Интернета вещей с использованием интеллектуальных шлюзов. Процедуры Comput Sci 52: 452–459

Статья Google Scholar

40.

Moosavi SR, Gia TN, Nigussie E, Rahmani AM, Virtanen S, Tenhunen H, Isoaho J (2016) Сквозная схема безопасности для мобильности позволила медицинскому Интернету вещей.Fut Gener Comput Syst 64: 108–124

Статья Google Scholar

41.

Шмитт К., Ноак М., Ху В., Котмайр Т., Стиллер Б. (2015) Двусторонняя аутентификация для Интернета вещей. В: Alzaid H, Alomair B, Almotiri S, Nasser N (eds) Защита Интернета вещей с помощью прогрессивного обнаружения угроз и управления ими. Серия книг о достижениях в области информационной безопасности, конфиденциальности и этики (AISPE). IGI Global

42.

Маногаран Г., Тота С., Лопес Д., Сундарасекар Р. (2017) Аналитика безопасности больших данных для отрасли здравоохранения 4.0. В кибербезопасности для индустрии 4.0. Спрингер, США, стр. 103–126

Google Scholar

43.

Granjal J, Monteiro E (2016) Сквозная прозрачная безопасность транспортного уровня для мобильных сенсорных устройств, интегрированных в Интернет. В: IFIP Networking Conference (IFIP Networking) and Workshops, 2016. IEEE, pp 306–314

44.

Hummen R, Shafagh H, Raza S, Voig T, Wehrle K (2014) Аутентификация и авторизация на основе делегирования для Интернет вещей на основе IP.В: Одиннадцатая ежегодная международная конференция IEEE по зондированию, коммуникации и сетям (SECON), 2014 г. IEEE, стр. 284–292

45.

Алаба Ф.А., Осман М., Хашем IAT, Алотайби Ф. (2017) Безопасность Интернета вещей: обзор. J Netw Comput Appl

46.

Chen X (2014) Протокол ограниченного приложения для Интернета вещей. http://www1.cse.wustl.edu/~jain/cse574-14/ftp/coap

47.

Thota C, Manogaran G, Lopez D, Vijayakumar V (2017) Платформа безопасности больших данных для распределенных облачных центров обработки данных.В: Нарушения кибербезопасности и проблемы, связанные с защитой от сетевых угроз. IGI Global, США, стр. 288–310

Отделение Google Scholar

48.

Приян М.К., Деви ГУ (2017) Энергоэффективный алгоритм выбора узла на основе индекса производительности узла и модели мобильности случайных путевых точек в Интернете транспортных средств. Clust Comput 1–15

49.

Kumar PM, Gandhi UD (2017) Новая трехуровневая архитектура Интернета вещей с алгоритмом машинного обучения для раннего обнаружения сердечных заболеваний.Comput Electr Eng

50.

Varatharajan R, Manogaran G, Priyan MK, Sundarasekar R (2017) Носимые сенсорные устройства для раннего обнаружения болезни Альцгеймера с использованием алгоритма динамической деформации времени. Clust Comput 1–10

51.

Варатхараджан Р., Маногаран Г., Приян М.К., Балаш В.Е., Барна С. (2017) Визуальный анализ модели пригодности геопространственной среды обитания на основе обратного взвешивания расстояний с анализом парных сравнений. Multimed Tools Appl 1–21

52.

Тота С., Сундарасекар Р., Маногаран Г., Варатхараджан Р., Приян М.К. (2018) Централизованная платформа безопасности туманных вычислений для Интернета вещей и облачных вычислений в системе здравоохранения.В: Изучение конвергенции больших данных и Интернета вещей. IGI Global, pp 141–154

53.

Varatharajan R, Vasanth K, Gunasekaran M, Priyan M, Gao XZ (2017) Алгоритм кригинговой интерполяции на основе адаптивного решения для удаления с изображений шума соли и перца высокой плотности. Comput Electr Eng

54.

Manogaran G, Lopez D (2017) Алгоритм пространственной совокупной суммы с аналитикой больших данных для обнаружения изменения климата. Вычислить Электр Eng

55.

Manogaran G, Lopez D (2017) Фреймворк обработки больших данных на основе гауссовского процесса в кластерной вычислительной среде. Clust Comput 1–16

Использование RELOAD и CoAP для глобальной сети датчиков и исполнительных механизмов | Журнал EURASIP по беспроводной связи и сети

В этом разделе мы представим результаты моделирования в разделах 8.1 и 8.2. В Разделе 8.3 мы представим результаты запуска экспериментального прототипа нашей архитектуры в реальных сетях и оборудовании.

8.1 Задержки

В первом наборе моделирования мы сосредоточились на измерении задержек, связанных с установлением отношений наблюдения CoAP. Задержки для четырех сценариев показаны на рисунках 7 и 8. Рисунок 7 показывает среднюю задержку установления отношения наблюдения CoAP, тогда как рисунок 8 показывает среднюю задержку отдельных транзакций CoAP. Планки погрешностей на рисунках представляют собой 95% доверительные интервалы.

Рисунок 7

Задержка установления отношения наблюдения CoAP .На рисунке показана средняя задержка установления отношений наблюдения CoAP. На рисунке сравниваются четыре сценария: (1) оверлей RELOAD используется вместе с выделенными соединениями для CoAP, (2) используется оверлей RELOAD и передача сигналов CoAP туннелируется через оверлей, (3) используется архитектура клиент / сервер и используются выделенные соединения. используется для CoAP, и (4) используется архитектура клиент / сервер, и сообщения CoAP отправляются через центральный сервер.

Рисунок 8

Задержка транзакций CoAP .На рисунке показана задержка последующих транзакций CoAP, отправленных после установления отношения наблюдения CoAP.

Из рисунка 7 видно, что задержки установления отношения наблюдения CoAP с использованием выделенного соединения с согласованием ICE составляют 28,1 с и 6,3 с в сценариях, предназначенных для RELOAD и C / S, соответственно. Когда все сообщения CoAP туннелируются, задержки установления отношения наблюдения CoAP составляют 25,5 с и 3,0 с для сценариев RELOAD-tunnel и C / S-tunnel соответственно.Как и ожидалось, задержки RELOAD в несколько раз превышают задержки C / S. Это связано с дополнительной задержкой, связанной с отправкой сообщений RELOAD Fetch, Attach и Tunnel через несколько переходов через оверлей. Каждый переход включает в себя отправку сообщения дважды через беспроводной радиоинтерфейс 3G (т. Е. В сетях беспроводного доступа отправителя и получателя).

Из рисунка видно, что причина, по которой выделенные соединения дороже для сценариев RELOAD и C / S, чем использование запросов RELOAD Tunnel для установления отношений наблюдения, связана с переговорами ICE, которые занимают примерно 3 раза.2 с для RELOAD и C / S (разница в задержках между сценариями RELOAD и C / S не является статистически значимой).

На рисунке 8 показаны задержки последующих транзакций CoAP, отправленных после установления отношения наблюдения. Как и ожидалось, задержки равны, примерно 1,1 с для сценариев RELOAD и C / S. Задержки туннелирования сообщений CoAP через оверлей или через центральный сервер составляют 11,7 с и 1,8 с для сценариев RELOAD-tunnel и C / S-tunnel соответственно.Таким образом, туннелированные сценарии имеют явно более высокую стоимость, чем сценарии с использованием выделенных соединений. В частности, стоимость туннелирования CoAP через оверлей RELOAD настолько высока, что это может оказаться невозможным на практике, если наблюдателям требуется информация от датчиков в реальном или близком к реальному времени.

Хотя задержка, связанная с установлением отношения наблюдения CoAP, в 4,5 раза выше для сценария, выделенного для RELOAD, чем для сценария, выделенного для C / S, стоит отметить, что эта задержка происходит только один раз при установлении отношения.В сценарии, посвященном RELOAD, после этой единовременной стоимости последующие транзакции CoAP не испытывают дополнительной задержки по сравнению со случаем, посвященным C / S. Таким образом, если можно допустить эти единовременные дополнительные расходы, как и следовало ожидать в типичном случае использования, использование наложения RELOAD не дороже, чем использование центрального сервера, когда дело доходит до задержек CoAP.

8.2 Загрузка трафика

8.2.1 Первый набор моделирования

Поскольку все PN используют сотовый радиодоступ, интересно сравнить общие нагрузки трафика, генерируемые в наших четырех сценариях.Нагрузку трафика следует минимизировать, чтобы минимизировать нагрузку на сеть сотового доступа, а также из соображений энергоэффективности. Сначала мы опишем результаты для нагрузки трафика в первом наборе моделирования. Результаты второго и третьего сеансов моделирования описаны в разделах ниже.

Общий объем трафика протокола приложения (т. Е. CoAP, RELOAD и STUN), которым обмениваются в оверлее в течение часового периода в первом наборе моделирования, показан на рисунке 9 для наших четырех сценариев.В сценарии, специально предназначенном для RELOAD, трафик состоит из сообщений CoAP, трафика поддержки активности STUN для RELOAD и CoAP, а также служебного трафика наложения RELOAD. В сценарии RELOAD-tunnel трафик состоит из трафика обслуживания RELOAD, трафика приложения RELOAD (т. Е. Запросов туннеля) и сообщений проверки активности STUN для RELOAD. В сценарии, посвященном C / S, трафик состоит из сообщений поддержки активности STUN для CoAP и RELOAD (мы использовали сообщения RELOAD для передачи сигналов клиент / сервер между PN и центральным сервером) и сообщений CoAP.В сценарии C / S-туннеля трафик состоит только из сообщений поддержки активности STUN и сообщений CoAP (сообщения CoAP были инкапсулированы в сообщения туннеля RELOAD).

Рисунок 9

Общий трафик, 2000 прокси-узлов . На рисунке показан общий объем трафика протокола приложений, которым обменивается система в течение периода измерения при использовании 2000 прокси-узлов и 10-минутного интервала уведомления CoAP. Предполагалось, что прокси-узлы расположены за NAT, дружественным к P2P.

Из рисунка видно, что в сценарии, выделенном для RELOAD, общий трафик в течение часового периода составляет 938 МБ, тогда как в сценарии, выделенном для C / S, он составляет 365 МБ.Сценарий RELOAD-туннеля генерирует 750 МБ трафика, тогда как C / S-туннель генерирует только 124 МБ. Более высокая стоимость сценариев RELOAD объясняется, в частности, трафиком обслуживания наложения RELOAD и большим объемом трафика STUN, необходимого для поддержания соединений RELOAD между PN (каждый PN поддерживает соединения со всеми одноранговыми узлами в таблице маршрутизации, размер которой составляет 8 пальцев, 3 преемника и 3 предшественника, как описано в таблице 1). Во всех сценариях большая часть общего трафика — это STUN keeplives.Процентные значения составляют 71%, 43%, 96% и 53% для сценариев RELOAD-выделенный, RELOAD-туннель, выделенный C / S и C / S-туннель соответственно. Для сценариев, предназначенных для RELOAD и C / S, крупнейшим источником трафика являются пакеты поддержки активности STUN для подключений CoAP. Доля сообщений проверки активности STUN для CoAP от общего трафика составляет 40% и 89% для сценариев RELOAD и C / S, соответственно.

Таким образом, мы можем сделать вывод, что, как и ожидалось, с моделью трафика, описанной в таблице 1, сценарии C / S генерируют значительно меньше общего трафика, чем сценарии RELOAD.Однако основное различие, конечно, состоит в том, что в сценарии C / S центральный сервер должен обрабатывать либо весь (C / S-туннель), либо часть (C / S-специализированный) общего трафика. Поэтому интересно изучить также входящий трафик, который необходимо обрабатывать центральному серверу. Мы сделаем это во втором наборе моделирования, описанном ниже.

8.2.2 Второй набор симуляций

Во втором наборе симуляций мы сравнили транспортную нагрузку наших четырех различных сценариев в более сложных условиях (которые были описаны в Разделе 7.3).

Общий объем трафика, которым обмениваются в каждом из четырех сценариев во втором наборе моделирования, показан на рисунке 10. Ось y на рисунке использует логарифмическую шкалу. Из рисунка видно, что сценарий C / S-туннеля по-прежнему имеет самый низкий общий объем трафика. В отличие от рисунка 9, сценарий RELOAD-туннеля теперь имеет наибольший общий объем трафика (за исключением случая, когда на каждый WSN приходится только один LN). Объем трафика в сценарии с выделенным C / S начинает приближаться и в конечном итоге становится почти равным трафику в сценарии с выделением RELOAD по мере увеличения количества LN на WSN.Это связано с тем, что сообщения CoAP и пакеты поддержки активности STUN для CoAP начинают преобладать, и, таким образом, дополнительные затраты на использование RELOAD поверх C / S становятся незначительными при рассмотрении общих уровней трафика.

Рисунок 10

Общий трафик, 10 000 прокси-узлов . На рисунке показан общий объем трафика протокола приложений, которым обменивается система в течение периода измерения при использовании 10 000 прокси-узлов (PN), 1–100 локальных узлов (LN) на PN и 10-минутного интервала уведомления CoAP.Предполагалось, что подмножество PN находится за P2P-недружественными NAT.

На рисунке 11 показано количество входящих Мбит / с для центрального сервера в сценариях C / S и для среднего однорангового узла в сценариях RELOAD. Для оси y на рисунке используется логарифмический масштаб. Из рисунка видно, что в сценариях RELOAD PN особо не загружаются. Однако в сценариях C / S нагрузка на центральный сервер начинает быстро расти. Например, при наличии 10 LN на WSN сервер должен уже иметь возможность обрабатывать нагрузку входящего трафика, равную 3.6 и 11,1 Мбит / с в сценариях выделенного C / S и C / S-туннеля соответственно. Таким образом, мы можем сделать вывод, что масштабируемость сценариев RELOAD оказывается намного лучше, чем масштабируемость архитектуры C / S.

Рисунок 11

Входящий трафик в секунду, 10 000 прокси-узлов . На рисунке показано количество входящих Мбит / с для центрального сервера в сценариях C / S и для среднего однорангового узла в сценариях RELOAD при использовании 10 000 прокси-узлов (PN), 1-100 локальных узлов (LN) на PN и 10-минутный интервал уведомления CoAP.Предполагалось, что подмножество PN находится за P2P-недружественными NAT.

8.2.3 Третий набор симуляций

В нашем третьем и последнем наборе симуляций мы уменьшили средний интервал уведомлений CoAP до 60 с, сохраняя при этом значения всех других параметров идентичными по сравнению со вторым набором симуляций. Итоговый общий трафик в наших четырех сценариях показан на рисунке 12. Из рисунка мы можем заметить, что при высокой частоте уведомлений CoAP сценарии RELOAD-туннеля и C / S-туннеля становятся явно более дорогостоящими, чем RELOAD. специализированные и специализированные сценарии C / S с точки зрения общего трафика.Кроме того, если посмотреть на количество входящих Мбит / с на средний одноранговый узел (сценарии RELOAD) или на центральный сервер (сценарии C / S), показанные на рисунке 13, мы можем увидеть, что сценарий, посвященный RELOAD, явно превосходит другие сценарии. В худшем случае (100 LN на WSN) средний Мбит / с, полученный средним одноранговым узлом или центральным сервером, составляет 0,04 Мбит / с, 0,40 Мбит / с, 42 Мбит / с и 1078 Мбит / с для выделенного RELOAD , Сценарии RELOAD-tunnel, выделенный C / S и C / S-туннель соответственно. Таким образом, мы снова можем видеть, что сценарии RELOAD (особенно RELOAD выделенные) очень хорошо масштабируются, тогда как в сценариях C / S нагрузка трафика для центральных серверов может стать очень высокой.

Рисунок 12

Общий трафик, 10 000 прокси-узлов, интервал уведомления 60 с . На рисунке показан общий объем трафика протокола приложений, которым обменивается система в течение периода измерения при использовании 10 000 прокси-узлов (PN), 1–100 локальных узлов (LN) на PN и интервала уведомления CoAP 60 с. Предполагалось, что подмножество PN находится за P2P-недружественными NAT.

Рисунок 13

Входящий трафик в секунду, 10 000 прокси-узлов, интервал уведомления 60 с .На рисунке показано количество входящих Мбит / с для центрального сервера в сценариях C / S и для среднего однорангового узла в сценариях RELOAD при использовании 10 000 прокси-узлов (PN), 1-100 локальных узлов (LN) на PN и интервал уведомления CoAP 60 секунд. Предполагалось, что подмножество PN находится за P2P-недружественными NAT.

8.3 Оценка системы в реальной сети и аппаратном обеспечении

Мы работаем над испытательным прототипом нашей сетевой архитектуры датчиков и исполнительных механизмов.В прототипе мы используем небольшие одноплатные компьютеры Gumstix Overo Earth COM ^— с процессором ARM Cortex-A8 600 МГц в качестве узлов сети. Одноплатные компьютеры работают под управлением встроенной операционной системы Linux. Мы оснастили одноплатные компьютеры ключом 3G и ключом Libelium Waspmote ^b ZigBee Gateway, оба из которых подключаются через USB. Ключ 3G обеспечивает широкополосное соединение (например, Интернет). Ключ ZigBee Gateway используется для связи с ZigBee WSN.Мы используем датчики Libelium Waspmote ZigBee в качестве устаревших LN. В прототипе используется та же кодовая база, что и в нашем симуляторе. Это обеспечивается уровнем абстракции, скрывающим тот факт, используется ли реальный или смоделированный сетевой уровень. Поскольку наш прототип основан на Java, мы запускаем виртуальную машину Java CACAO, ^c, которая поддерживает процессоры ARM, на одноплатных компьютерах. Мы также разработали несколько дополнительных модулей для прототипа. К ним относятся, например, модуль, обеспечивающий взаимодействие между CoAP / UDP / IP и стеком протоколов ZigBee.Наконец, мы используем стороннюю библиотеку ZigBee API под названием xbee-api ^d для взаимодействия прототипа с устройством шлюза ZigBee.

Мы провели серию дополнительных измерений, используя наш экспериментальный прототип. Во всех этих измерениях использовался сценарий, специально предназначенный для ПЕРЕЗАГРУЗКИ. В измерениях две сети PN, PN-A и PN-B, действовали как клиенты в оверлейной сети RELOAD из 1000 узлов, работающей в PlanetLab. Мы решили использовать наложение PlanetLab, а не наложение, созданное только PN, чтобы иметь возможность экспериментировать с достаточно большим количеством узлов (у нас было только ограниченное количество доступного оборудования PN).Узлы PlanetLab использовали ту же версию Java Standard Edition нашего прототипа, что и одноплатные компьютеры. Оба PN были расположены за NAT с использованием независимого отображения конечных точек и режима фильтрации. В измерениях мы сосредоточились на измерении задержек связи, связанных с одним LN, LN-A, начиная с наблюдения за ресурсом CoAP другого LN, LN-B, расположенного за другим PN. Мы измеряли отдельно задержки между каждым LN и его PN, а также задержки между двумя PN. Поскольку наложение выполнялось в PlanetLab, только первый переход (от PN к узлу PlanetLab) и последний переход (от узла PlanetLab к PN) в наложении проходил по сотовой радиосвязи.При измерениях LN и PN располагались в одном помещении без препятствий между ними.

Результаты измерений показаны в таблице 3. Таблица содержит среднюю задержку, рассчитанную по 100 измерениям для каждого компонента задержки. Задержка сбора кандидатов ICE в LN-A показана отдельно в таблице. В таблице значение в скобках представляет собой стандартное отклонение. Результаты выглядят немного иначе по сравнению с результатами по задержке в нашем моделировании из-за того, что при измерениях только первый и последний переходы в оверлее RELOAD проходили через радиоинтерфейс 3G; все промежуточные переходы маршрутизации происходили между узлами PlanetLab.Мы видим, что общая задержка с момента, когда LN-A инициирует сообщение CoAP, до момента получения ответа CoAP от LN-B составляет в среднем 12,9 с. Связь через ZigBee составляет только 10% от общей задержки. Самый большой компонент задержки — это процедура Attach. Большая задержка прикрепления, особенно по сравнению со значительно меньшей задержкой поиска, объясняется двумя факторами. Во-первых, запрос и ответ на присоединение дважды проходят через радиоинтерфейс 3G (в сетях доступа PN-A и PN-B).Напротив, на запрос Lookup отвечает узел PlanetLab, и поэтому он проходит через 3G только на стороне отправляющего PN. В общем, все компоненты задержки, которые требуют обмена сообщениями по сети 3G как на стороне A, так и на стороне B, высоки. К ним относятся задержка присоединения, задержка согласования ICE и задержка PN-PN CoAP. Вторая причина большой задержки Attach заключается в том, что она также включает сбор кандидатов ICE в PN-B. Основным дополнительным результатом этих измерений по сравнению с моделированием является то, что связь между LN и PN составляет лишь незначительную часть сквозной задержки.

Таблица 3 Измерения в PlanetLab

MQTT и CoAP, протоколы IoT

IoT требует стандартных протоколов.
Два самых перспективных для маленькие устройства — это MQTT и CoAP.

И MQTT, и CoAP:

Открытые стандарты
Лучше подходят для ограниченных сред, чем HTTP
Обеспечить механизмы для асинхронной связи
Работает на IP
Имеют ряд реализаций

MQTT дает гибкость в моделях общения и действует исключительно как канал для двоичных данных.
CoAP разработан для взаимодействия с Интернетом.

MQTT

MQTT — это протокол обмена сообщениями публикации / подписки, предназначенный для облегченная связь M2M. Первоначально он был разработан IBM и теперь это открытый стандарт.

Архитектура

MQTT имеет модель клиент / сервер, где каждый датчик является клиентом и подключается к серверу, известному как брокер, через TCP.

MQTT ориентирован на сообщения. Каждое сообщение представляет собой отдельный фрагмент данные, непрозрачные для брокера.

Каждое сообщение публикуется по адресу, известному как тема. Клиенты может подписаться на несколько тем. Каждый клиент подписался на тему получает каждое сообщение, опубликованное в теме.

Например, представьте простую сеть с тремя клиентами и центральный брокер.

Все три клиента открывают TCP-соединения с брокером. Клиенты B и C подписаться на тема температуры .

Позже клиент A публикует значение 22.5 по теме температура . Брокер пересылает сообщение всем подписанным клиентам.

Модель подписчика издателя позволяет клиентам MQTT обмениваться данными один к одному, один ко многим и многие к одному.

Соответствие тем

В MQTT темы являются иерархическими, как файловая система (например, кухня / духовка / температура). Подстановочные знаки разрешены при регистрации подписка (но не при публикации), позволяющая целым иерархиям быть под наблюдением клиентов.

Подстановочный знак + соответствует любому отдельному имени каталога, # соответствует любому количество каталогов любого названия.

Например, тема кухня / + / температура соответствует kitchen / foo / temperature, но не кухня / foo / бар / температура

кухня / # спички кухня / холодильник / компрессор / клапан1 / температура

Уровень приложения QoS

MQTT поддерживает три уровня качества обслуживания: «Включил и забыл», «Доставлено хотя бы один раз» и «доставлено ровно один раз».

Последняя воля и завещание

клиентов MQTT могут зарегистрировать специальную «последнюю волю и завещание» сообщение, которое будет отправлено брокером, если они отключатся. Эти сообщения может использоваться, чтобы сигнализировать абонентам, когда устройство отключается.

Стойкость

MQTT поддерживает постоянные сообщения, хранящиеся на брокере. Когда публикуя сообщения, клиенты могут запросить, чтобы брокер оставался сообщение. Сохраняется только самое последнее постоянное сообщение.Когда клиент подписывается на тему, любое постоянное сообщение будет отправлено клиенту.

В отличие от очереди сообщений, брокеры MQTT не позволяют сообщения для резервного копирования внутри сервера.

Безопасность

Брокеры

MQTT могут потребовать аутентификацию имени пользователя и пароля от клиентов для подключения. Для обеспечения конфиденциальности TCP-соединение может быть зашифровано с помощью SSL / TLS.

MQTT-SN

Несмотря на то, что MQTT спроектирован как легкий, у него есть два недостатки для очень ограниченных устройств.

Каждый клиент MQTT должен поддерживать TCP и обычно имеет соединение открыто для брокера в любое время. Для некоторых сред где потеря пакетов высока или вычислительные ресурсы ограничены, это проблема.

Названия тем

MQTT часто представляют собой длинные строки, что делает их непрактичными. для 802.15.4.

Оба эти недостатка устраняются протоколом MQTT-SN, который определяет UDP-отображение MQTT и добавляет поддержку брокера для индексирование названий тем.

CoAP

CoAP — это протокол ограниченного приложения от CoRE (Среды с ограниченными ресурсами) Группа IETF.

Архитектура

Как и HTTP, CoAP — это протокол передачи документов. В отличие от HTTP, CoAP разработан для нужд устройств с ограниченными возможностями.

Пакеты

CoAP намного меньше, чем потоки HTTP TCP. Битовые поля и сопоставления строк с целыми числами широко используются для экономии пространство. Пакеты просты в создании и могут быть проанализированы на месте без использования дополнительной оперативной памяти на устройствах с ограниченными возможностями.

CoAP работает по UDP, а не по TCP. Клиенты и серверы общаются через датаграммы без установления соединения. Повторные попытки и изменение порядка реализован в стеке приложения. Устранение необходимости в TCP может разрешить полноценную IP-сеть в небольших микроконтроллерах. CoAP позволяет UDP широковещательная и многоадресная рассылка, которые будут использоваться для адресации.

CoAP следует модели клиент / сервер. Клиенты обращаются к серверы, серверы отправляют ответы. Клиенты могут ПОЛУЧИТЬ, ПОСТАВИТЬ, ПОСЛАТЬ и УДАЛИТЬ ресурсы.

CoAP разработан для взаимодействия с HTTP и RESTful web на большой через простые прокси.

Поскольку CoAP основан на дейтаграммах, его можно использовать поверх SMS и другие протоколы пакетной связи.

Уровень приложения QoS

Запросы и ответные сообщения могут быть помечены как «подтверждаемые» или «Неподтвержденный». Подтверждаемые сообщения должны быть подтверждены приемник с пакетом подтверждения.

Неподтвержденные сообщения — это «запустил и забыл».

Согласование содержимого

Как и HTTP, CoAP поддерживает согласование содержимого. Клиенты используют Принять параметры для выражения предпочтительного представления ресурса и серверы отвечают Content-Type возможность рассказать клиентам, что они получают. Как и в случае с HTTP, это позволяет клиенту и серверу развиваться независимо, добавляя новые представления, не влияя друг на друга.

Запросы CoAP могут использовать строки запроса в форме ? A = b & c = d .Их можно использовать для обеспечения поиска, разбиения по страницам и других функций для клиентов.

Безопасность

Поскольку CoAP построен поверх UDP, а не TCP, SSL / TLS не доступны для обеспечения безопасности. DTLS, транспортный уровень дейтаграмм Безопасность обеспечивает те же гарантии, что и TLS, но для передачи данные по UDP. Обычно устройства CoAP с поддержкой DTLS будут поддерживать RSA. и AES или ECC и AES.

Соблюдайте

CoAP расширяет модель HTTP-запроса с возможностью наблюдения ресурс.Когда флаг наблюдения установлен в запросе CoAP GET, сервер может продолжить отвечать после того, как исходный документ был переведен. Это позволяет серверам передавать изменения состояния клиентам как они происходят. Любая из сторон может отменить наблюдение.

Обнаружение ресурсов

CoAP определяет стандартный механизм обнаружения ресурсов. Серверы предоставить список своих ресурсов (вместе с метаданными о них) по адресу /.well-known/core. Эти ссылки находятся в формате приложения / ссылки тип носителя и позволить клиенту узнать, какие ресурсы предоставлены и какие это типы носителей.

Проблемы с NAT

В CoAP сенсорный узел обычно является сервером, а не клиентом (хотя может быть и то, и другое). Датчик (или исполнительный механизм) предоставляет ресурсы, которые могут быть доступны клиентам для чтения или изменения состояния датчика.

Поскольку датчики CoAP являются серверами, они должны иметь возможность принимать входящие сообщения. пакеты. Для правильной работы за NAT устройство может сначала отправить запрос к серверу, как это сделано в LWM2M, позволяя маршрутизатору чтобы связать эти два.Хотя CoAP не требует IPv6, он проще всего использовать в IP-средах, где устройства имеют прямую маршрутизацию.

Сравнение

MQTT и CoAP полезны как протоколы IoT, но имеют принципиальные отличия.

MQTT — это протокол связи «многие ко многим» для передачи сообщений. между несколькими клиентами через центрального брокера. Он разъединяет производителя и потребителя, позволяя клиентам публиковать и имея брокер решает, куда направлять и копировать сообщения.Хотя в MQTT есть поддержка настойчивости, она лучше всего работает как коммуникационная шина для живые данные.

CoAP — это, прежде всего, протокол «один-к-одному» для передачи состояния информация между клиентом и сервером. Хотя он поддерживает наблюдая за ресурсами, CoAP лучше всего подходит для модели передачи состояний, не только на основе событий.

MQTT-клиенты устанавливают долговременное исходящее TCP-соединение с брокером. Обычно это не представляет проблемы для устройств за NAT.CoAP клиенты и серверы отправляют и получают пакеты UDP. В NAT среды, туннелирование или переадресация портов могут использоваться для разрешения CoAP, или устройства могут сначала инициировать соединение с головным узлом как в LWM2M.

MQTT не поддерживает маркировку сообщений типами или другими метаданные, чтобы помочь клиентам понять это. Могут использоваться сообщения MQTT для любых целей, но все клиенты должны знать форматы сообщений заранее, чтобы разрешить общение. CoAP, наоборот, обеспечивает встроенную поддержка согласования и обнаружения контента, позволяющая устройствам зондировать друг друга, чтобы найти способы обмена данными.

У обоих протоколов есть свои плюсы и минусы, выбор правильного зависит от в вашем приложении.

Проводите эксперименты, создавайте прототипы и развертывайте тестовые устройства на сети.

Тоби Джаффи — основатель и технический директор компании 1248, которая предоставляет знания и системы, которые помогут производителям быстро соединить свои продукты и эффективно, в большом масштабе.

Дополнительная литература

MQTT

CoAP

Эта работа находится под лицензией Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Непортированный Лицензия.

Конституционный Суд РФ проверил конституционность положений части 5 статьи 28.1 КоАП РФ и части 3 статьи 201 АПК РФ

8,5 тысячи нарушителей и один труп. Комтранс Петербурга отчитался о работе с нарушителями правил парковки — Авто — Новости Санкт-Петербурга

Активист из Воронежа пожаловался на преследование полицией из-за надписей «Путин, уходи» и «ПТН ПНХ»

В Пскове полиция изъяла листовки в офисе КПРФ

Сайт заблокирован?

КоАП РФ последняя редакция на 2021 с изменениями. Кодекс об административных правонарушениях с комментариями (ФЗ №195)

Статус КоАП как документа федерального уровня

Функция Кодекса об административных правонарушениях

Специальные административные дела

Нарушения в сфере управления и охраны общественного порядка

Кто несёт ответственность по нормам КоАП

Как и за что наказывают

Полезное видео

Оскорбление медицинского работника статья 5 61 коап

Какая статья за оскорбление личности?

Оскорбление на рабочем месте или что делать, если оскорбили на работе?

Какая статья оскорбление детей со стороны родителей

Оскорбление медицинских работников пациентами

Бесплатная юридическая помощь

Законодательная база Российской Федерации

Статья закона РФ об оскорблении личности

Оскорбление медицинского работника

Оскорбление сотрудника на рабочем месте клиентом

Статья 5.61 КоАП РФ. Оскорбление (действующая редакция)

Административное право. Тест 5 — ДЕКАН ТЕСТ

CoAP: Пошаговое руководство — DZone IoT

Что такое протокол CoAP?

Сообщения CoAP Модель

Модель запроса / ответа CoAp

Формат сообщения CoAp

Аспекты безопасности CoAP

CoAP против MQTT

Протокол ограниченных приложений для Интернета вещей

Аннотация:

Ключевые слова

Содержание:

1. Введение

2. Обзор беспроводных протоколов для Интернета вещей

2.1 Протоколы на разных уровнях

2.2 Характеристики CoAP

2.3 Сравнение CoAP и HTTP

3. Модель структуры CoAP

3.1 Модель уровня сообщений

3.2 Модель уровня запроса / ответа

3.3 Формат сообщения

4. Протокол безопасности и приложение для CoAP

4.1 Зачем использовать DTLS для защиты CoAP

4.2 Структура DTLS

4.3 Приложение CoAP для умных домов

5. Заключение

6. Список литературы

7. Сокращения

Усовершенствования и проблемы в CoAP — обзор

4.1. Механизмы управления перегрузкой в ​​CoAP

4.1.1. CoAP по умолчанию

4.1.2. CoCo-RED

4.1.3. CoCoA

4.1.4. Схема четырехуровневого оценщика

4.1.5. Адаптивное управление перегрузкой

4.1.6. CoCoA +

4.1.7. Улучшенное адаптивное управление перегрузкой

4.1.8. CACC

4.1.9. FASOR

4.1.10. pCoCoA

4.1.11. CoCoA ++

4.1.12. Genetic CoCoA ++

4.1.13. Обратная связь о потере сообщения на основе

4.1.14. На основе свежести контента

4.1.15. BDP-CoAP

4.1.16. CoAP-R

Электроника | Бесплатный полнотекстовый | Управление потоковой передачей на основе CoAP для приложений Интернета вещей

1. Введение

2. Сопутствующие работы

2.1. CoAP через UDP

2.2. CoAP через TCP

3. Предлагаемая схема управления потоковой передачей CoAP

3.1. Инициализация для CoAP-SC

3.2. Обработка ошибок для CoAP-SC

3.3. Управление потоком для CoAP-SC

3.4. Опция CoAP для CoAP-SC

4.1. Механизмы управления перегрузкой в CoAP