Содержание

Ст. 2.1 КОАП РФ. Административное правонарушение

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

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

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

См. все связанные документы >>>

1. Часть первая комментируемой ст. 2.1 КоАП РФ определяет понятие административного правонарушения.

Исторически в правовой науке и в законодательстве сложились два подхода к пониманию административных правонарушений.

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

Такое представление о сущности административных деликтов и ответственности за их совершение легло в основу построения административного законодательства Франции, ФРГ, Англии, США.

Второй подход, который условно называют карательным, первоначально, до возникновения понятия административных правонарушений в собственном смысле, доминировал в Германии в XVIII – XIX вв. Проступки, за которые наступала ответственность, назывались exekutivstrafen, позднее – полицейскими, или фискальными, деликтами. Они представляли собой уголовные проступки. Лица, их совершившие, несли уголовную ответственность. В целом законодательством Пруссии, а затем Германии закреплялось административное усмотрение на уголовное принуждение. Таким образом, сложилось иное понимание административных правонарушений – как неисполнение населением административных предписаний государственной власти либо совершение таких действий, наказание за которые назначались в административном порядке. Целью подобных наказаний было не восстановление нарушенного права, а наказание за ослушание.

В настоящее время в Германии взыскания, устанавливаемые в административном порядке, предназначаются для обеспечения выполнения административных постановлений, а не для кары, и применяются достаточно редко, поскольку карательные нормы содержатся в основном в уголовном законодательстве (Административное право: Курс лекций: Учебное пособие для вузов / Под ред. Э.Г. Липатова, С.Е. Чаннова. М., 2006. С. 281 – 282).

В силу ряда причин именно “прусский” подход получил второе рождение в нашем государстве в XIX веке и после 1917 года. Произошла трансформация административных правонарушений в иное явление, обозначаемое прежним термином. Из средства контроля за решениями органов государственной власти институт административных правонарушений, как, собственно, и вся отрасль административного права, превратился в придаток уголовного права, обеспечивая контроль государства над обществом, охраняя правопорядок угрозой наказания (Честнов И.Л. Институт административных правонарушений в системе права: Дис.

… канд. юрид. наук. СПб., 1994. С. 9 – 11). Полицейское право играет важную роль и в построении науки современного российского административного права (Бельский К.С. К вопросу о предмете административного права // Гос. и право. 1997. N 11. С. 14 – 21; Соловей Ю.П. Российское полицейское право: история и современность // Гос. и право. 1995. N 6; Бельский К.С., Елисеев Б.П., Кучеров И.И. Полицейское право как подотрасль административного права // Гос. и право. 2001. N 12. С. 45 – 53; и др.).

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

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

– противоправность. Противоправность означает, что совершением данного деяния (действия или бездействия) обязательно нарушены нормы права. Никакое деяние не может быть признано административным правонарушением и за его совершение не может наступить административная ответственность, если при этом не были нарушены нормы права. Так, например, административное правонарушение, предусмотренное ст. 12.6 КоАП РФ: “Нарушение правил применения ремней безопасности или мотошлемов”, связано с нарушением правил, установленных п. 2.1.2 Правил дорожного движения Российской Федерации (утверждены Постановлением Совета Министров – Правительства Российской Федерации от 23 октября 1993 г. N 1090): при движении на транспортном средстве, оборудованном ремнями безопасности, быть пристегнутым и не перевозить пассажиров, не пристегнутых ремнями. При управлении мотоциклом быть в застегнутом мотошлеме и не перевозить пассажиров без застегнутого мотошлема;

– виновность. Виновность означает, что являющееся административным правонарушением деяние совершается при наличии вины. Отсутствие вины не позволяет считать данное деяние (даже противоправное) административным правонарушением. Вина может выступать в двух формах: в форме умысла и в форме неосторожности (см. об этом комментарий к ст. 2.2 КоАП РФ). Статья 1.5 КоАП РФ непосредственно указывает, что лицо подлежит административной ответственности только за те административные правонарушения, в отношении которых установлена его вина, а п. 3 ст. 26.1 КоАП РФ – что по делу об административном правонарушении выяснению подлежит виновность лица в совершении административного правонарушения.

Часть 2 комментируемой статьи регламентирует особенности определения вины юридических лиц:

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

Так, например, в соответствии с абз. 1 п. 10.2 Правил дорожного движения Российской Федерации в населенных пунктах разрешается движение транспортных средств со скоростью не более 60 км/ч. При этом ст. 12.9 КоАП РФ устанавливает административную ответственность за превышение установленной скорости движения транспортного средства начиная от превышения не менее 20 км/ч. Таким образом, движение транспортного средства в населенном пункте, например, со скоростью 79 км/ч будет противоправным, но не административно наказуемым деянием.

Таковое деяние имеет некоторые признаки, характерные для административного правонарушения (общественная опасность, противоправность, виновность), за исключением наказуемости, и именно в силу отсутствия последнего административным правонарушением не является.

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

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

В связи с этим в научной литературе и в нормативных документах предлагались различные подходы к определению вины юридических лиц. Так, распространенным является понимание вины юридических лиц как психологического отношения к содеянному коллектива, определяемого по доминирующей воле в этом коллективе (Петров М.П. Административная ответственность организаций (юридических лиц): Автореф. дис. … канд. юрид. наук. Саратов, 1998. С. 6). Аналогичное по конструкции понятие вины содержится в ст. 110 Налогового кодекса РФ.

В науке административного права имеет место и иной подход к вине юридического лица. Он основан на приоритете объективного аспекта в деятельности юридического лица. При таком рассмотрении вина юридического лица определяется как “комплекс негативных элементов, характеризующихся дезорганизацией деятельности юридического лица, непринятием им необходимых мер для надлежащего исполнения возложенных на него обязанностей, неприложением требуемых усилий для предупреждения правонарушений и устранения их причин” (Овчарова Е.В. Административная ответственность юридических лиц: Автореф. дис. … канд. юрид. наук. М., 2001. С. 13).

Эта концепция оказалась положена в основу законодательного определения вины, данного в ч. 2 комментируемой статьи. Суть данного подхода заключается в определении реальной возможности или невозможности для юридического лица соблюсти те нормы и правила, за нарушение которых и установлена административная ответственность. В юридической литературе данный подход к определению вины юридического лица получил название комплексного, включающего объективный и субъективный критерии. Как отмечает А.С. Дугенец, объективная вина – это вина организации, с точки зрения государственного органа, назначающего административное наказание в зависимости от характера конкретных действий или бездействия юридического лица, нарушающих установленные правила поведения; это то, что известно как объективное вменение; субъективная вина – отношение организации в лице ее коллектива, администрации, должностных лиц к противоправному деянию (Дугенец А.С. Административная ответственность в российском праве: Автореф. дис. … д-ра юрид. наук. М., 2005. С. 11).

Конституционный Суд Российской Федерации в своем Определении от 21 апреля 2005 г. N 119-О указал, что положения ч. 2 ст. 2.1 КоАП РФ, предусматривающие основания, при обязательном наличии которых юридическое лицо может быть признано виновным в совершении административного правонарушения, направлены на обеспечение действия презумпции невиновности (ст. 1.5 КоАП РФ) и имеют целью исключить возможность привлечения юридических лиц к административной ответственности при отсутствии их вины.

Несмотря на указание в КоАП РФ на необходимость установления вины юридических лиц для привлечения их к ответственности, проблему все же трудно считать решенной. Совершенно очевидно, что такие формулировки, как “имелась возможность для соблюдения правил и норм”, “не были приняты все зависящие от него меры”, носят оценочный характер и оставляют широкий простор для усмотрения правоприменителя. Это, собственно, и было подтверждено Конституционным Судом Российской Федерации в том же Определении от 21 апреля 2005 г.: установление того, имелась ли у юридического лица возможность для соблюдения норм и правил, за нарушение которых предусмотрена административная ответственность, и были ли приняты все зависящие от него меры по их соблюдению, а также проверка доказательств, свидетельствующих о наличии или отсутствии его вины (умышленной или неосторожной), связано с исследованием фактических обстоятельств дела, что является прерогативой судов общей и арбитражной юрисдикции и не входит в компетенцию Конституционного Суда РФ, определенную ст. 125 Конституции РФ и ст. 3 Федерального конституционного закона “О Конституционном Суде Российской Федерации” (данная позиция была подтверждена Конституционным Судом Российской Федерации также в Определениях от 02.04.2009 N 486-О-О; от 19.05.2009 N 572-О-О и от 07.12.2010 N 1620-О-О).

В Постановлении от 25.02.2014 N 4-П Конституционный Суд Российской Федерации указал, что “содержательно вина юридического лица в совершении административного правонарушения может выражаться различным образом – в полном игнорировании требований законодательства, в уклонении от исполнения отдельных правовых предписаний, в неиспользовании всех доступных средств для соблюдения установленных правил и т.п. Составообразующего значения для квалификации совершенного юридическим лицом административного правонарушения эти обстоятельства не имеют, однако в правоприменительной практике назначения административного наказания их учет не лишен смысла”.

На необходимость выяснения виновности лица в совершении административного правонарушения обращал внимание Пленум Высшего Арбитражного Суда РФ в п. 16 Постановления от 02.06.2004 N 10 “О некоторых вопросах, возникших в судебной практике при рассмотрении дел об административных правонарушениях” (Постановление сохраняет свою силу до принятия соответствующих решений Пленумом Верховного Суда Российской Федерации).

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

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

Однако на практике, как правило, правоприменители исходят из того, что наличие вины работника юридического лица в совершенном правонарушении свидетельствует о том, что данное юридическое лицо не приняло все зависящие от него меры по соблюдению установленных норм и правил. Так, например, Девятый арбитражный апелляционный суд, рассматривая дело о привлечении к административной ответственности потребительского общества “Органика” по ч. 2 ст. 14.5 КоАП РФ (Неприменение контрольно-кассовой техники в установленных законодательством Российской Федерации о применении контрольно-кассовой техники случаях), в частности, указал: по смыслу ч. 3 ст. 2.1 КоАП РФ вина конкретного работника в совершении административного правонарушения не может являться основанием для освобождения юридического лица от административной ответственности за правонарушение. Поскольку Столярова Р.Д. осуществляла свою деятельность от имени и в интересах потребительского общества (Заявителя) и является его работником (пайщиком), то названное Общество является ответственным за применение ККТ (Постановление Девятого арбитражного апелляционного суда от 15 июня 2017 г. по делу N А40-8138/2017). Арбитражный суд Камчатского края, признавая виновным общество с ограниченной ответственностью “Курильский пролив” в совершении административного правонарушения, предусмотренного ч. 1 ст. 18.1 КоАП РФ (Нарушение правил пересечения Государственной границы Российской Федерации лицами и (или) транспортными средствами либо нарушение порядка следования таких лиц и (или) транспортных средств от Государственной границы Российской Федерации до пунктов пропуска через Государственную границу Российской Федерации и в обратном направлении), указал: ответственность за административное правонарушение по части 1 статьи 18.1 КоАП РФ наступает вне зависимости от вины конкретных должностных лиц Общества. Неисполнение данными должностными лицами (в частности, капитаном судна) своих должностных обязанностей не исключает возможности привлечения самого юридического лица к административной ответственности в силу части 3 статьи 2.1 названного Кодекса (решение Арбитражного суда Камчатского края от 12 мая 2017 г. по делу N А24-1294/2017). Аналогичные по смыслу заключения можно встретить и во многих иных актах судебных органов.

Пленум Высшего Арбитражного Суда Российской Федерации также отметил, что, в отличие от физических лиц, в отношении юридических лиц КоАП РФ формы вины (статья 2.2 КоАП РФ) не выделяет. Следовательно, и в тех случаях, когда в соответствующих статьях Особенной части КоАП РФ возможность привлечения к административной ответственности за административное правонарушение ставится в зависимость от формы вины, в отношении юридических лиц требуется лишь установление того, что у соответствующего лица имелась возможность для соблюдения правил и норм, за нарушение которых предусмотрена административная ответственность, но им не были приняты все зависящие от него меры по их соблюдению (часть 2 статьи 2. 1 КоАП РФ). Обстоятельства, указанные в части 1 или части 2 статьи 2.2 КоАП РФ, применительно к юридическим лицам установлению не подлежат (п. 16.1 Постановления).

Верховный Суд Российской Федерации в своих постановлениях неоднократно констатировал, что наличие возможности для соблюдения правил и норм, за нарушение которых предусмотрена административная ответственность, всегда анализируется судами при рассмотрении дел в отношении юридических лиц (см., например: Постановления от 09.11.2016 N 303-АД16-12333 по делу N А04-2847/2016; от 04.10.2016 N 306-АД16-12487 по делу N А06-8433/2015; от 04.12.2015 N 308-АД15-10495 по делу N А32-36328/2014 и др.)

При этом в качестве обоснования наличия вины юридического лица в совершении административного правонарушения суды, как правило, указывают на то, что указанными юридическими лицами не представлены доказательства, свидетельствующие о том, что правонарушение вызвано чрезвычайными обстоятельствами и другими непредвиденными, непреодолимыми препятствиями, находящимися вне их контроля (см. , например: Постановление Двадцать первого арбитражного апелляционного суда от 15 февраля 2017 г. по делу N А83-4040/2016; решение Арбитражного суда города Москвы от 13 февраля 2017 г. по делу N А40-237018/2016; решение Арбитражного суда города Москвы от 15 февраля 2017 г. по делу N А40-254089/2016; и др.).

Хотя по общему правилу установление вины юридического лица в совершенном им административном правонарушении является обязательным, КоАП РФ содержит несколько исключений из этого правила. В соответствии с ч. ч. 3 – 6 ст. 2.10 КоАП РФ при реорганизации юридических лиц (слиянии, присоединении, разделении, преобразовании) вновь возникшие юридические лица несут ответственность независимо от того, было ли известно привлекаемому к административной ответственности юридическому лицу о факте административного правонарушения до завершения реорганизации, то есть при отсутствии его вины. Более подробно см. об этом комментарий к ст. 2.10.

3. Назначение административного наказания юридическому лицу не освобождает от административной ответственности за данное правонарушение виновное физическое лицо, равно как и привлечение к административной или уголовной ответственности физического лица не освобождает от административной ответственности за данное правонарушение юридическое лицо. Как указал Конституционный Суд Российской Федерации в своем Постановлении от 25.02.2014 N 4-П, “такое правовое регулирование, будучи обусловленным спецификой административной деликтоспособности юридических лиц, сопряженной с причастностью к совершению административных правонарушений не отдельных индивидов, а создаваемых в установленном законом порядке коммерческих и некоммерческих организаций, на которые как на участников гражданского оборота возлагаются и сопутствующие осуществляемой ими деятельности риски и которые – в отличие от физических лиц – не признаются субъектами уголовной ответственности, является конституционно допустимым (Постановления Конституционного Суда Российской Федерации от 27 апреля 2001 года N 7-П, от 26 ноября 2012 года N 28-П и от 17 января 2013 года N 1-П)”.

Согласно позиции Пленума Высшего Арбитражного Суда Российской Федерации, выраженной в Постановлении от 02.06.2004 N 10, “в случае, если до рассмотрения арбитражным судом дела о привлечении к административной ответственности юридического лица (а равно дела об оспаривании решения административного органа о привлечении к административной ответственности юридического лица) судом общей юрисдикции рассмотрено дело о привлечении к административной или уголовной ответственности за данное нарушение физического лица (а равно дело об оспаривании решения административного органа о привлечении к административной ответственности физического лица), квалификация, данная судом общей юрисдикции совершенному деянию, с учетом статьи 69 АПК РФ не является обязательной для арбитражного суда. При этом оценка, данная судом общей юрисдикции, обстоятельствам, которые установлены в рассмотренном им деле, принимается во внимание арбитражным судом” (п. 16.2).

Федеральная антимонопольная служба в Методических рекомендациях по применению антимонопольными органами статьи 2.9 КоАП (в части прекращения дел об административных правонарушениях, связанных с нарушением антимонопольного законодательства, по малозначительности) (http://orel.f.isfb.ru), указала, что в случае освобождения юридического лица, совершившего административное правонарушение, от административной ответственности в соответствии со статьей 2.9 КоАП РФ (то есть в связи с малозначительностью) следует решить вопрос об освобождении от административной ответственности за данное правонарушение и физического лица.

Апелляционная жалоба по административным правонарушениям

ПОРЯДОК ОБЖАЛОВАНИЯ ПОСТАНОВЛЕНИЙ И РЕШЕНИЙ ПО ДЕЛАМ ОБ АДМИНИСТРАТИВНЫХ ПРАВОНАРУШЕНИЯХ, ПРЕДУСМОТРЕННЫЙ ГЛАВОЙ  30 КоАП РФ

 

1.       Право на обжалование постановления по делу об административном правонарушении

Постановление по делу об административном правонарушении может быть обжаловано следующими лицами:

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

– потерпевшим

– законными представителями физического лица

– законными представителями юридического лица

– защитником и представителем потерпевшего

– Уполномоченным при Президенте Российской Федерации по защите прав предпринимателей

Постановление по делу об административном правонарушении может быть обжаловано:

1) вынесенное судьей – в вышестоящий суд;

2) вынесенное коллегиальным органом – в районный суд по месту нахождения коллегиального органа;

3) вынесенное должностным лицом – в вышестоящий орган, вышестоящему должностному лицу либо в районный суд по месту рассмотрения дела;

3.1) вынесенное должностным лицом, указанным в части 2 статьи 23. 79 (органы исполнительной власти субъектов Российской Федерации – городов федерального значения Москвы и Санкт-Петербурга), части 2 статьи 23.79.1 или части 2 статьи 23.79.2 (органы исполнительной власти субъектов Российской Федерации) КоАП РФ, – в вышестоящий орган, вышестоящему должностному лицу, в уполномоченный соответствующим нормативным правовым актом Президента Российской Федерации, Правительства Российской Федерации или соглашением о передаче осуществления части полномочий федеральный орган исполнительной власти либо в районный суд по месту рассмотрения дела;

4) вынесенное иным органом, созданным в соответствии с законом субъекта Российской Федерации, – в районный суд по месту рассмотрения дела.

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

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

По результатам рассмотрения жалобы выносится решение.

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

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

 

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

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

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

Жалоба может быть подана непосредственно в суд, вышестоящий орган, вышестоящему должностному лицу, уполномоченным ее рассматривать.

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

Жалоба на постановление по делу об административном правонарушении государственной пошлиной не облагается.

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

Важно!!!

Поданные со дня начала деятельности кассационных и апелляционных судов общей юрисдикции жалобы (протесты) на вступившие в законную силу постановление по делу об административном правонарушении и (или) решения, вынесенные по результатам рассмотрения жалоб (протестов), подлежат рассмотрению кассационными судами общей юрисдикции и Верховным Судом Российской Федерации (статья 2 Федерального закона от 12 ноября 2018 года N 417-ФЗ “О внесении изменений в статью 30. 13 Кодекса Российской Федерации об административных правонарушениях”).

Первый кассационный суд общей юрисдикции

Адрес: ул. Первомайская, д. 74, г. Саратов, 410031

Телефон: (8452) 98-28-84

Интернет-сайт: hppts://1kas.sudrf.ru

 

Судебная коллегия по административным делам Верховного Суда Российской Федерации.

Адрес: ул. Поварская, д. 15, г. Москва, 121260

Телефон: (495) 627-02-47

Интернет-сайт: https://www.vsrf.ru/

 

3.      Срок обжалования постановления по делу об административном правонарушении

Жалоба на постановление по делу об административном правонарушении может быть подана в течение десяти суток со дня вручения или получения копии постановления.

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

Жалобы на постановления по делам об административных правонарушениях, предусмотренных статьями 5.1 – 5.25, 5.45 – 5.52, 5.56, 5.58, 5.69 настоящего Кодекса, могут быть поданы в пятидневный срок со дня вручения или получения копий постановлений.

Об отклонении ходатайства о восстановлении срока обжалования постановления по делу об административном правонарушении выносится определение.

 

4.      Сроки рассмотрения жалобы на постановление по делу об административном правонарушении

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

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

Жалобы на постановления по делам об административных правонарушениях, предусмотренных статьями 5.1 – 5.25, 5.45 – 5.52, 5.56, 5.58, 5.69 КоАП РФ, подлежат рассмотрению в пятидневный срок со дня их поступления со всеми материалами в суд, правомочный рассматривать жалобы.

Жалоба на постановление об административном аресте либо административном выдворении подлежит рассмотрению в течение суток с момента подачи жалобы, если лицо, привлеченное к административной ответственности, отбывает административный арест либо подлежит административному выдворению.

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

 

5.      Пересмотр решения, вынесенного по жалобе на постановление по делу об административном правонарушении

Постановление по делу об административном правонарушении, вынесенное должностным лицом, и (или) решение вышестоящего должностного лица по жалобе на это постановление могут быть обжалованы в суд по месту рассмотрения жалобы, а затем в вышестоящий суд.

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

Подача последующих жалоб на постановление по делу об административном правонарушении и (или) решения по жалобе на это постановление, их рассмотрение и разрешение осуществляются в порядке и в сроки, установленные статьями 30.2 – 30.8 КоАП РФ.

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

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

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

 

6.      Принесение протеста на не вступившее в законную силу постановление по делу об административном правонарушении и последующие решения

Не вступившее в законную силу постановление по делу об административном правонарушении и (или) последующие решения вышестоящих инстанций по жалобам на это постановление могут быть опротестованы прокурором в порядке и в сроки, установленные статьями 30.1, 30.2, частями 1 и 3 статьи 30.3 КоАП РФ.

Протест прокурора на постановление по делу об административном правонарушении и (или) последующие решения по жалобам на это постановление рассматриваются в порядке и в сроки, установленные статьями 30.4 – 30.8 КоАП РФ.

Копия решения по протесту прокурора на постановление по делу об административном правонарушении направляется прокурору, принесшему протест, и лицам, указанным в статьях 25. 1 – 25.5.1 КоАП РФ, в трехдневный срок после вынесения решения.

 

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

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

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

– потерпевшим

– законными представителями физического лица

– законными представителями юридического лица

– защитником и представителем потерпевшего

– Уполномоченным при Президенте Российской Федерации по защите прав предпринимателей

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

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

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

 

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

Жалобы подаются, протесты приносятся в кассационные суды общей юрисдикции, в том числе кассационный военный суд, Верховный Суд Российской Федерации.

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

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

 

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

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

Жалоба, протест на вступившие в законную силу постановление по делу об административном правонарушении, решения по результатам рассмотрения жалоб, протестов должны содержать:

1) наименование суда, в который подается жалоба, приносится протест;

2) сведения о лице, подавшем жалобу, прокуроре, принесшем протест;

3) сведения о других участниках производства по делу об административном правонарушении;

4) указание на постановление по делу об административном правонарушении, решение по результатам рассмотрения жалоб, протестов;

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

6) перечень материалов, прилагаемых к жалобе, протесту;

7) подпись лица, подавшего жалобу, прокурора, принесшего протест.

К жалобе, протесту должны быть приложены:

1) копия постановления по делу об административном правонарушении;

2) копии решений по результатам рассмотрения жалоб, протестов, если такие решения вынесены;

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

4) копия жалобы, протеста, число которых соответствует числу других участников производства по делу об административном правонарушении, указанных в статьях 25.1 – 25.4, 25.11 КоАП РФ.

Полиция задержала депутата Мосгордумы от КПРФ

https://ria.ru/20211001/deputat-1752669610.html

Полиция задержала депутата Мосгордумы от КПРФ

Полиция задержала депутата Мосгордумы от КПРФ – РИА Новости, 01.10.2021

Полиция задержала депутата Мосгордумы от КПРФ

Депутата Мосгордумы Николая Зубрилина и начальника отдела горкома КПРФ Павла Иванова задержала полиция, на них составили протоколы по статье о нарушении порядка РИА Новости, 01. 10.2021

2021-10-01T14:33

2021-10-01T14:33

2021-10-01T14:33

политика

происшествия

москва

московская городская дума

госдума рф

кпрф

россия

/html/head/meta[@name=’og:title’]/@content

/html/head/meta[@name=’og:description’]/@content

https://cdnn21.img.ria.ru/images/07e5/06/1b/1738803079_286:520:2254:1627_1920x0_80_0_0_645b1c4ce5d558078213c1598e8ecccf.jpg

МОСКВА, 1 окт – РИА Новости. Депутата Мосгордумы Николая Зубрилина и начальника отдела горкома КПРФ Павла Иванова задержала полиция, на них составили протоколы по статье о нарушении порядка проведения митингов, сообщили РИА Новости в пресс-службе столичного главка МВД.”…Гражданин Иванов, добровольно находившийся в офисе юридической службы московского горкома КПРФ по адресу Симферопольский бул., 24, более 6 суток, самостоятельно покинул помещение и был задержан сотрудниками полиции”, – говорится в сообщении.Уточняется, что он был доставлен в отдел полиции, на него составили административный протокол по статье о нарушении установленного порядка организации или проведения митингов (статья 20. 2 КоАП).Вместе с ним в отдел полиции доставили депутата Московской городской думы от КПРФ Николая Зубрилина, на него составили протокол по той же статье – он призывал к участию в несогласованных акциях, а также сам участвовал в несогласованном мероприятии 20 сентября.В ведомстве отметили, что столичная полиция продолжает искать участников несанкционированных акций и тех, кто призывал в них участвовать.Мэрия Москвы, исходя из действующих в столице противокоронавирусных мер, не согласовала КПРФ проведение митингов, на которых заявлялось о несогласии с результатами онлайн-голосования в Москве, но коммунисты все равно провели мероприятия, назвав их встречами с избирателями.Общественный штаб по наблюдению за выборами в Москве после критики ДЭГ поручил технической группе провести аудит результатов голосования, чтобы убедиться в их корректности. В пятницу, 1 октября, общественный штаб сообщил, что аудит не подтвердил версии о возможных нарушениях при онлайн-голосовании в Москве на выборах 17-19 сентября. Президент РФ Владимир Путин, комментируя тему ДЭГ на встрече с руководством партий, прошедших в Госдуму, заявил, что электронное голосование, как и технический прогресс, невозможно остановить, важно следить за качеством его проведения. Он добавил, что сомнения в электронном голосовании в Москве возникли, видимо, потому, что кому-то не понравился результат, и предложил совместно с партиями продумать вопросы контроля.

https://ria.ru/20210930/deputat-1752534414.html

https://ria.ru/20210929/golosovanie-1752274263.html

https://ria.ru/20210929/boykot-1752269283.html

москва

россия

РИА Новости

[email protected]

7 495 645-6601

ФГУП МИА «Россия сегодня»

https://xn--c1acbl2abdlkab1og.xn--p1ai/awards/

2021

РИА Новости

[email protected]

7 495 645-6601

ФГУП МИА «Россия сегодня»

https://xn--c1acbl2abdlkab1og.xn--p1ai/awards/

Новости

ru-RU

https://ria. ru/docs/about/copyright.html

https://xn--c1acbl2abdlkab1og.xn--p1ai/

РИА Новости

[email protected]

7 495 645-6601

ФГУП МИА «Россия сегодня»

https://xn--c1acbl2abdlkab1og.xn--p1ai/awards/

https://cdnn21.img.ria.ru/images/07e5/06/1b/1738803079_316:521:2265:1983_1920x0_80_0_0_d08790acff286d1ab1af7c8d9539a0d2.jpg

РИА Новости

[email protected]

7 495 645-6601

ФГУП МИА «Россия сегодня»

https://xn--c1acbl2abdlkab1og.xn--p1ai/awards/

РИА Новости

[email protected]

7 495 645-6601

ФГУП МИА «Россия сегодня»

https://xn--c1acbl2abdlkab1og.xn--p1ai/awards/

политика, происшествия, москва, московская городская дума, госдума рф, кпрф, россия

МОСКВА, 1 окт – РИА Новости. Депутата Мосгордумы Николая Зубрилина и начальника отдела горкома КПРФ Павла Иванова задержала полиция, на них составили протоколы по статье о нарушении порядка проведения митингов, сообщили РИА Новости в пресс-службе столичного главка МВД.

“…Гражданин Иванов, добровольно находившийся в офисе юридической службы московского горкома КПРФ по адресу Симферопольский бул., 24, более 6 суток, самостоятельно покинул помещение и был задержан сотрудниками полиции”, – говорится в сообщении.

30 сентября, 17:32

Депутата Мосгордумы от КПРФ доставили в Тверской суд

Уточняется, что он был доставлен в отдел полиции, на него составили административный протокол по статье о нарушении установленного порядка организации или проведения митингов (статья 20.2 КоАП).

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

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

Мэрия Москвы, исходя из действующих в столице противокоронавирусных мер, не согласовала КПРФ проведение митингов, на которых заявлялось о несогласии с результатами онлайн-голосования в Москве, но коммунисты все равно провели мероприятия, назвав их встречами с избирателями. 29 сентября, 11:30Выборы в Государственную думуКПРФ подала 31 иск по итогам онлайн-голосования в Москве

Общественный штаб по наблюдению за выборами в Москве после критики ДЭГ поручил технической группе провести аудит результатов голосования, чтобы убедиться в их корректности. В пятницу, 1 октября, общественный штаб сообщил, что аудит не подтвердил версии о возможных нарушениях при онлайн-голосовании в Москве на выборах 17-19 сентября.

Президент РФ Владимир Путин, комментируя тему ДЭГ на встрече с руководством партий, прошедших в Госдуму, заявил, что электронное голосование, как и технический прогресс, невозможно остановить, важно следить за качеством его проведения. Он добавил, что сомнения в электронном голосовании в Москве возникли, видимо, потому, что кому-то не понравился результат, и предложил совместно с партиями продумать вопросы контроля.29 сентября, 11:04Выборы в Государственную думуФракция КПРФ бойкотировала первое после летнего перерыва заседание МГД

На главу фракции КПРФ в Мосгордуме составили протокол за призывы и участие в несанкционированной акции

Полиция задержала руководителя фракции КПРФ в Мосгордуме Николая Зубрилина, написала в Telegram другой депутат Мосгордумы — Екатерина Енгалычева. На него составили протокол по статье о нарушении порядка проведения митингов (статья 20.2 КоАП РФ).

Госпожа Енгалычева в беседе с изданием Sota рассказала, что Николай Зубрилин вышел из здания московского комитета КПРФ с коммунистом Павлом Ивановым и их задержали вместе. Позже депутат Мосгордумы от КПРФ Евгений Ступин написал в своем Telegram-канале, что господин Зубрилин находится в Тверском ОВД.

Позднее стало известно, что Николаю Зубрилину и Павлу Иванову выписали протоколы за призывы и участие в несанкционированной акции. «В отношении депутата Зубрилина составлен административный материал по статье 20.2 КоАП РФ (нарушение установленного порядка организации либо проведения собрания, митинга, демонстрации, шествия или пикетирования)»,— сообщили в МВД.

Напомним, 20 и 25 сентября в Москве на Пушкинской площади прошли акции коммунистов против результатов дистанционного электронного голосования на выборах в Госдуму. Столичные власти мероприятия не санкционировали. В связи с этим были задержаны несколько членов КПРФ.

В среду, 29 сентября, фракция КПРФ в знак протеста покинула первое после летнего перерыва заседание Московской городской думы, проходившее в формате видеоконференции. Николай Зубрилин тогда заявил, что партию не устраивают преследование коммунистов и блокировка здания московского горкома, дистанционный формат заседаний, а также итоги электронного голосования на выборах в Госдуму. Кроме того, господин Зубрилин обратился к начальнику столичного ГУВД с требованием «немедленно прекратить преследование коммунистов и Коммунистической партии», а также освободить всех задержанных представителей КПРФ.

Подробнее о претензиях коммунистов к результатам выборов и реакции властей — в материале «Ъ» «На дальних подступах к суду».

«Спартак» высказался о ситуации с арестованным фанатом

4 октября состоялось судебное заседание, на котором болельщика московского «Спартака», жителя столицы Евгения Кравченко приговорили к десяти суткам ареста по статье 20.1 КоАП РФ («Мелкое хулиганство»). При этом статья не подразумевает запрет на посещение спортивных мероприятий в дальнейшем. Основанием для вынесения приговора послужил протокол, составленный при задержании Кравченко.

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

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

«Спартак» отреагировал на решение суда. Глава пресс-службы столичной команды Дмитрий Зеленов заявил, что после появления информации об инциденте сотрудники клуба отправились в подтрибунное помещение, чтобы оказать всю возможную помощь Кравченко.

«На месте мы запросили всю информацию у представителей МВД, оперативно получили доступ к задержанному болельщику, убедились, что он здоров и ему ничего не угрожает. Решение суда вы знаете — статья 20.1 КОАП, десять суток. Держим ситуацию на контроле, чтобы после истечения срока ареста человек целым и невредимым вернулся домой. Насколько мы знаем, в Грозном на это время решил остаться товарищ задержанного», — приводит слова Зеленова «Спорт-Экспресс».

Ставший свидетелем задержания Кравченко болельщик «Спартака» Роман в комментарии «Спорт-Экспрессу» признался, что уже много лет ездит на выездные матчи команды в Грозный, и до этого проблем никаких не было – самое главное, соблюдать установленные правила.

Он подчеркнул, что не оправдывает поступок задержанного. После сделанного замечания фанат «проехался по религии», что вызвало гнев бойцов полка имени Героя России Ахмата-Хаджи Кадырова отдельной бригады оперативного назначения Северо-Кавказского округа Росгвардии.

«Его по порядку должны были задержать и отправить в отдел полиции, а потом суд ему изберет наказание. В данном же случае толпа озверевших начала бить его ногами, применять дубинки и спецсредства. Они сначала его избили, потом поняли, что все заснято. Повезли его в отделение, за ними поехали товарищи этого парня», — подчеркнул Роман.

Также фанат заявил, что если бы видеозапись задержания не появилась в социальных сетях, то Кравченко могли отпустить. Однако после ее публикации «руководство захотело получить разъяснения от своих подчиненных», отметил Роман. Он рассказал, что в отделении задержанный никакой злости к сотрудникам не испытывал и просил его отпустить.

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

Глава практики спортивного права фирмы CMS Валерий Федореев, говоря о сложившейся ситуации, заявил, что на сегодняшний момент не видит причин, по которым футбольный клуб «Ахмат» и стадион «Ахмат Арена» должны быть подвергнуты каким-либо санкциям в связи с арестом болельщика московского клуба.

«Санкции на стадион налагаются, если происходят какие-то противоправные действия со стороны болельщиков любой команды – своей или приглашенной, и это влечет за собой какие-то негативные последствия. При этом принимающая сторона не принимает никаких мер. В данном случае, если я правильно понял ситуацию, болельщик «Спартака» нарушил законодательство, его быстро повязала местная полиция. Получается, что принимающий клуб – «Ахмат» — обеспечил на территории стадиона соблюдение правопорядка.

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

Они имеют право это делать, и, получается, что «Ахмат», обеспечил соблюдение правопорядка на стадионе.

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

В «Спартаке» отреагировали на арест болельщика после инцидента в Грозном :: Футбол :: РБК Спорт

Клуб заявил, что контролирует ситуацию, для того чтобы болельщик целым и невредимым вернулся в Москву

Читайте нас в

Новости Новости

Фото: Global Look Press

«Спартак» держит под контролем ситуацию с задержанным в Грозном после матча с «Ахматом» болельщиком «красно-белых», заявил руководитель пресс-службы клуба Дмитрий Зеленов.

«Решение суда вы знаете — статья 20.1 КоАП, десять суток. Держим ситуацию на контроле, чтобы после истечения срока ареста человек целым и невредимым вернулся домой. Насколько мы знаем, в Грозном на это время решил остаться товарищ задержанного», — приводятся слова Зеленова в заявлении клуба.

В РПЛ раскрыли детали инцидента с болельщиком на матче «Спартака» в Чечне

Встреча десятого тура «Тинькофф» — Российской премьер-лиги (РПЛ) прошла в Грозном 3 октября и завершилась победой «Спартака» со счетом 1:0. В Telegram-канале «Выездные заметки» появилась информация, что на матче «Ахмат» — «Спартак» были избиты двое болельщиков московской команды, а также опубликовано короткое видео, где сотрудники с нашивками «Полк А. А.Кадырова» окружили упавшего человека.

Суд над задержанным болельщиком прошел в Грозном 4 октября. Тот был осужден по ст. 20.1 Кодекса об административных правонарушениях (мелкое хулиганство) и арестован на десять суток. Отбывает наказание болельщик в столице Чечни. Максимальный срок ареста по указанной статье составляет 15 суток.

Позднее директор РПЛ по безопасности Александр Мейтин сообщил, что болельщик «Спартака» находился в неадекватном состоянии: оскорблял людей на национальной почве и пытался избить медиков, которые оказывали ему помощь. По словам Мейтина, болельщика никто не бил.

Авторы

Иван Витченко, Грант Гетадарян

Суд арестовал блогера из Таджикистана Руслана Бобиева на 10 суток и решил выдворить из России

Автор фото, Yegor Aleyev\tass

Блогер из Таджикистана Руслан Бобиев, который выложил в соцсетях фото, по словам полиции, “провокационного содержания” с девушкой на фоне храма Василия Блаженного в центре Москвы, арестован Замоскворецким судом на 10 суток.

Суд счел фотосессию на Красной площади вульгарной и принял решение о выдворении Бобиева за пределы России.

Участвовавшая в фотосессии подруга блогера Анастасия Чистова (на снимке девушка была одета в куртку с надписью “Полиция”) также арестована на 10 суток, передает ТАСС со ссылкой на пресс-службу суда.

Ранее сообщалось, что материалы в отношении Бобиева переданы в территориальное подразделение Следственного комитета, где решается вопрос о возбуждении в отношении него уголовного дела.

Безработный пранкер

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

В настоящее время аккаунт Бобиева удален.

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

В отношении блогера также составлен протокол по статье о нарушении режима пребывания в России, сообщили в ведомстве.

В опубликованном российскими СМИ видео допроса Бобиева он говорит, что занимается “пранками”, за которые его ранее забирали в полицию. Он называет себя безработным, утверждает, что у него 100 тысяч подписчиков в “Инстаграме”, но аккаунт заблокирован.

Бобиев на полицейской записи несколько раз приносит извинения.

Нежелательный комик

В августе МВД России объявило о нежелательности пребывания на территории страны комика Идрака Мирзализаде, гражданина Беларуси и уроженца Азербайджана.

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

9 августа Мирзализаде арестовали на 10 суток по обвинению в возбуждении ненависти (статья 20. 3.1 КоАП РФ) из-за шутки, которая прозвучала в YouTube-шоу “Разгоны”. В рассказе комика о том, как он искал жилье и выбрасывал из съемной квартиры грязный матрас, прокуратура нашла “признаки унижения группы лиц по национальному признаку”.

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

16 сентября Замоскворецкий суд Москвы приостановил решение МВД о нежелательности пребывания Идрака Мирзализаде в России.

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 В сообществе Attribution-NonCommercial-ShareAlike 3.0 без портирования Лицензия.

Об авторах

Протокол

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

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

Интернет вещей – одно из самых интересных и многообещающих технологических направлений.Это экосистема, в которой объекты, люди, устройства взаимосвязаны и обмениваются данными. В этом блоге мы рассмотрели 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. Сообщение состоит из нескольких частей:

Где:

  • Версия : это 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 больше подходит для передачи состояния.

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

Улучшения и проблемы в 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). Основные компоненты схемы включают в себя:

  1. Определение и расчет таймера RTO

  2. Управление с использованием алгоритма исправленного случайного раннего обнаружения (RevRED) для предотвращения перегрузки

  3. Алгоритм предварительного приращения Фибоначчи (FPB) для реализации таймер отсрочки передачи

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

  1. Если AvgQ

  2. Если Min threshold

  3. Если 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 при каждой передаче вызывает слишком много накладных расходов и может вызвать задержку передачи.

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 – точный алгоритм управления перегрузкой для решения этих проблем. Предлагаемый механизм основан на двух основных элементах:

  1. Метод точной привязки запросов к ответам даже в случае повторных передач

  2. Несколько модификаций алгоритма оценки 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 (пропускная способность узкого места и время распространения в оба конца).Программа BBR по оценке пропускной способности узких мест (BW) переработана, чтобы справляться с проблемами, связанными с потерями каналов и краткосрочной несправедливостью канала в сетях IoT. В случае краткосрочной несправедливости конкретный узел в сети IoT может получить канал на короткий период времени во временном окне и получить высокие мгновенные скорости доставки. Это заставляет BBR переоценивать доступную пропускную способность. BDP-CoAP использует средство оценки, которое объединяет измерения максимальной и минимальной скорости доставки для получения оценок пропускной способности узких мест, чтобы избежать завышенной оценки BW в случае краткосрочной несправедливости доступа к каналу.

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

4.1.16. CoAP-R

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

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

ECC-CoAP: Протокол приложения ограничений на основе криптографии с эллиптическими кривыми для Интернета вещей

  • 1.

    Vasseur, J. P., & Dunkels, A. (2010). Соединение интеллектуальных объектов с помощью IP: следующий Интернет . Берлингтон, Массачусетс: Морган Кауфманн.

    Google ученый

  • 2.

    Миками С., Ватанабэ Д., Ли Ю. и Сакияма К. (2015). Полностью интегрированный пассивный UHF RFID-тег для протокола взаимной аутентификации на основе хэша. Научный мировой журнал. https://doi.org/10.1155/2015/498610.

    Артикул Google ученый

  • 3.

    Лопес Дж. И Рубио Дж. Э. (2018). Контроль доступа к кибер-физическим системам, подключенным к облаку. Computer Networks, 134, 46–54.

    Артикул Google ученый

  • 4.

    Кео, С. Л., Кумар, С. С., и Чофениг, Х. (2014). Обеспечение безопасности Интернета вещей: перспектива стандартизации. IEEE Internet of Things Journal, 1 (3), 265–275.

    Артикул Google ученый

  • 5.

    Капосселе А., Черво В., Де Чикко Г. и Петриоли К. (2015 г., июнь). Безопасность как ресурс CoAP: оптимизированная реализация DTLS для IoT.В Международная конференция по коммуникациям IEEE 2015 г. (ICC) (стр. 549–554). IEEE.

  • 6.

    Рахман, Р. А., и Шах, Б. (2016, март). Анализ безопасности протоколов IoT: в центре внимания CoAP. В 2016 3-я международная конференция MEC по большим данным и умному городу (ICBDSC) (стр. 1–7). IEEE.

  • 7.

    Нгуен, Х. В., и Яконо, Л. Л. (2015, сентябрь). REST-полная аутентификация сообщений CoAP. В международном семинаре 2015 по безопасному Интернету вещей (SIoT) (стр.35–43). IEEE.

  • 8.

    Брахманн, М., Гарсия-Морчон, О., и Кирше, М. (2011). Безопасность для практических приложений CoAP: проблемы и подходы к их решению . Штутгарт: GI / ITG KuVS Fachgesprch Sensornetze (FGSN). Университет Штутгарта.

    Google ученый

  • 9.

    Ясейн, М. Б., Шатнави, М. К., Альджварнех, С., и Аль-Хатми, Р. (2017, май). Интернет вещей: обзор и открытые вопросы протокола MQTT.В 2017 Международная конференция по проектированию и ИСУ (ICEMIS) (стр. 1–6). IEEE.

  • 10.

    Альянс, О. М. (2002). Загрузка универсального контента по беспроводной спецификации. v1. 0 декабря.

  • 11.

    Palattella, M. R., Accettura, N., Vilajosana, X., Watteyne, T., Grieco, L.A., Boggia, G., et al. (2012). Стандартизированный стек протоколов для Интернета (важных) вещей. IEEE Communications Surveys & Tutorials, 15 (3), 1389–1406.

    Артикул Google ученый

  • 12.

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

  • 13.

    Вильяверде, Б. К., Пеш, Д., Альберола, Р. Д. П., Федор, С., и Бубекер, М. (2012, июль).Протокол ограниченного приложения для встроенных сетей с низким энергопотреблением: обзор. In 2012 шестая международная конференция по инновационным мобильным и интернет-сервисам в области повсеместных вычислений (стр. 702–707). IEEE.

  • 14.

    Мориц, Г., Голатовски, Ф., и Тиммерманн, Д. (2011, октябрь). Облегченная транспортная привязка SOAP через CoAP для сетей с ограниченными ресурсами. В 2011 восьмая международная конференция IEEE по мобильной рекламе hoc и сенсорные системы (стр.861–866). IEEE.

  • 15.

    Шнайдер Дж., Камия Т., Пайнтнер Д. и Кюсаков Р. (2011). Формат эффективного обмена XML (EXI) 1.0. Предлагаемая рекомендация W3C, 20, 32.

    Google ученый

  • 16.

    Khalique, A., Singh, K., & Sood, S. (2010). Реализация алгоритма электронной подписи на эллиптических кривых. Международный журнал компьютерных приложений, 2 (2), 21–27.

    Артикул Google ученый

  • 17.

    Бхаттачарья, А., Бозе, Т., Бандйопадхьяй, С., Укил, А., и Пал, А. (2015, март). МЕНЬШЕ: облегченное установление безопасного сеанса: межуровневый подход с использованием шифрования каналов CoAP и DTLS-PSK. In 2015 29-я международная конференция IEEE по расширенным информационным сетям и семинарам по приложениям (стр. 682–687). IEEE.

  • 18.

    Granjal, J., Monteiro, E., & Сильва, Дж. С. (2015). Безопасность для Интернета вещей: обзор существующих протоколов и открытых исследовательских вопросов. IEEE Communications Surveys & Tutorials, 17 (3), 1294–1312.

    Артикул Google ученый

  • 19.

    Рэй С., Бисвас Г. П. и Дасгупта М. (2016). Безопасный универсальный мобильный банкинг с использованием криптографии на основе эллиптических кривых. Беспроводная персональная связь, 90 (3), 1331–1354.

    Артикул Google ученый

  • 20.

    Джонсон Д., Менезес А. и Ванстон С. (2001). Алгоритм цифровой подписи на эллиптической кривой (ECDSA). Международный журнал информационной безопасности, 1 (1), 36–63.

    Артикул Google ученый

  • 21.

    Леви А. и Савас Э. (2003, июль). Оценка производительности работы криптосистемы с открытым ключом в протоколе WTLS.В Труды восьмого симпозиума IEEE по компьютерам и коммуникациям. ISCC 2003 (стр. 1245–1250). IEEE.

  • 22.

    Раза, С., Хельгасон, Т., Пападимитратос, П., и Войт, Т. (2017). SecureSense: Архитектура сквозной защищенной связи для Интернета вещей с подключением к облаку. Компьютерные системы будущего поколения, 77, 40–51.

    Артикул Google ученый

  • 23.

    Иглесиас-Уркиа, М., Ориве, А., и Урбьета, А. (2017, январь). Анализ реализаций CoAP для промышленного Интернета вещей: обзор. В ANT / SEIT (стр. 188–195).

  • 24.

    Алаба, Ф. А., Осман, М., Хашем, И. А. Т., и Алотайби, Ф. (2017). Безопасность Интернета вещей: обзор. Журнал сетевых и компьютерных приложений, 88, 10–28.

    Артикул Google ученый

  • 25.

    Альбалас, Ф., Аль-Суд, М., Альмомани, О., и Альмомани, А. (2018). Протокол уровня приложений CoAP с учетом безопасности для Интернета вещей с использованием криптографии с эллиптической кривой. Мощность (мВт), 1333, 151.

    Google ученый

  • 26.

    Хариш, М., Картик, Р., Раджан, Р. М., и Ветриселви, В. (2018). Защита CoAP с помощью шифрования полезной нагрузки: использование криптографии на основе эллиптических кривых. Международная конференция по коммуникациям и киберфизической инженерии, 2018, 497–511.

    Google ученый

  • 27.

    Дей С. и Хоссейн А. (2019). Установление сеансового ключа и аутентификация в сети умного дома с использованием криптографии с открытым ключом. IEEE Sensors Letters, 3 (4), 1–4.

    Артикул Google ученый

  • 28.

    Йе, Х. Л., Чен, Т. Х., Лю, П. К., Ким, Т. Х., и Вэй, Х. У. (2011). Протокол защищенной аутентификации для беспроводных сенсорных сетей с использованием криптографии эллиптических кривых. Датчики, 11 (5), 4767–4779.

    Артикул Google ученый

  • 29.

    Коблиц, Н. (Ред.). (2000). К четверти века криптографии с открытым ключом . Нью-Йорк, штат Нью-Йорк: Kluwer Academic.

    MATH Google ученый

  • 30.

    Миллер В. С. (1985, август). Использование эллиптических кривых в криптографии. В конференции по теории и применению криптографических методов (стр.417–426). Берлин: Springer.

  • 31.

    Паар К. и Пельцл Дж. (2009). Понимание криптографии: Учебник для студентов и практиков . Берлин: Springer.

    MATH Google ученый

  • 32.

    Ислам, С. Х., Амин, Р., Бисвас, Г. П., Фараш, М. С., Ли, X., и Кумари, С. (2017). Усовершенствованный трехсторонний протокол обмена ключами с аутентификацией с использованием хэш-функции и криптографии с эллиптической кривой для сред мобильной коммерции. Журнал компьютерных и информационных наук Университета короля Сауда, 29 (3), 311–324.

    Артикул Google ученый

  • 33.

    Рэй С. и Бисвас Г. П. (2011, декабрь). Дизайн mobile-PKI для использования мобильных телефонов в различных приложениях. В 2011 международная конференция по последним тенденциям в информационных системах (стр. 297–302). IEEE.

  • 34.

    Ray, S., & Biswas, G.П. (2012, октябрь). Инфраструктура открытых ключей на основе ECC, используемая для мобильных приложений. В Труды второй международной конференции по вычислительной науке, технике и информационным технологиям (стр. 562–568).

  • 35.

    Садхухан, Д., Рэй, С., Бисвас, Г. П., Хан, М. К., и Дасгупта, М. (2020). Облегченная схема аутентификации удаленного пользователя для связи IoT с использованием криптографии на основе эллиптических кривых. Журнал суперкомпьютеров . https: // doi.org / 10.1007 / s11227-020-03318-7.

    Артикул Google ученый

  • 36.

    Трибеди Д., Садхухан Д. и Рэй С. (2018, июль). Криптоанализ схемы мобильного кошелька, обеспечивающей безопасность и конфиденциальность, с аутсорсинговой проверкой в ​​облачных вычислениях. В Международная конференция по вычислительному интеллекту, коммуникациям и бизнес-аналитике (стр. 411–424). Сингапур: Спрингер.

  • 37.

    Садхухан, Д., & Рэй, С. (2018, март). Криптоанализ упрощенной схемы аутентификации на основе криптографии с эллиптической кривой для связи в интеллектуальных сетях. В 2018 4-я международная конференция по последним достижениям в области информационных технологий (RAIT) (стр. 1–6). IEEE.

  • 38.

    Турканович М., Брумен Б. и Хёльбл М. (2014). Новая схема аутентификации пользователей и согласования ключей для гетерогенных одноранговых беспроводных сенсорных сетей, основанная на концепции Интернета вещей. Ad Hoc Networks, 20, 96–112.

    Артикул Google ученый

  • 39.

    Ван, Д., Ли, В., и Ван, П. (2018). Измерение схем двухфакторной аутентификации для доступа к данным в реальном времени в промышленных беспроводных сенсорных сетях. Транзакции IEEE по промышленной информатике, 14 (9), 4081–4092.

    Артикул Google ученый

  • 40.

    Chatterjee, U., Sadhukhan, D., & Ray, S.(2020). Улучшенный протокол аутентификации и согласования ключей для интеллектуальной системы здравоохранения в контексте Интернета вещей с использованием криптографии на основе эллиптических кривых. В Труды международной конференции по инклюзивной жизни IoT (ICIIL 2019), NITTTR, Чандигарх, Индия, (стр. 11–22). Сингапур: Спрингер.

  • 41.

    Дас, А. К., Шарма, П., Чаттерджи, С., и Синг, Дж. К. (2012). Схема динамической аутентификации пользователя на основе пароля для иерархических беспроводных сенсорных сетей. Журнал сетевых и компьютерных приложений, 35 (5), 1646–1656.

    Артикул Google ученый

  • 42.

    Мишра, Д., Дас, А. К., & Мухопадхьяй, С. (2014). Безопасная схема согласования ключей с аутентификацией и аутентификацией на нескольких серверах с сохранением анонимности пользователя с использованием смарт-карт. Экспертные системы с приложениями, 41 (18), 8129–8143.

    Артикул Google ученый

  • 43.

    Берроуз М., Абади М. и Нидхэм Р. М. (1989). Логика аутентификации. Труды Лондонского королевского общества. А. Математические и физические науки, 426 (1871), 233–271.

    MathSciNet Статья Google ученый

  • 44.

    Махмуд, К., Чаудри, С. А., Накви, Х., Кумари, С., Ли, X., и Сангайя, А. К. (2018). Облегченная схема аутентификации, основанная на криптографии с эллиптическими кривыми, для связи в интеллектуальной сети. Компьютерные системы будущего поколения, 81, 557–565.

    Артикул Google ученый

  • 45.

    Адхикари С., Рэй С., Обайдат М. С. и Бисвас Г. П. (2020). Эффективная и безопасная архитектура распространения контента для контент-ориентированной сети с использованием инфраструктуры открытых ключей на основе ECC. Computer Communications, 157, 187–203.

    Артикул Google ученый

  • 46.

    Чалла С., Вазид М., Дас А. К., Кумар Н., Редди А. Г., Юн Э. Дж. И др. (2017). Схема создания аутентифицированного ключа на основе безопасной подписи для будущих приложений Интернета вещей. IEEE Access, 5, 3028–3043.

    Артикул Google ученый

  • 47.

    Амин Р. и Бисвас Г. П. (2016). Безопасная облегченная схема для аутентификации пользователей и согласования ключей в беспроводных сенсорных сетях с несколькими шлюзами. Ad Hoc Networks, 36, 58–80.

    Артикул Google ученый

  • 48.

    Али, Р., Пал, А. К., Кумари, С., Каруппия, М., и Конти, М. (2018). Безопасная аутентификация пользователей и схема согласования ключей с использованием беспроводных сенсорных сетей для мониторинга сельского хозяйства. Компьютерные системы будущего поколения, 84, 200–215.

    Артикул Google ученый

  • 49.

    Адхикари С., Рэй С., Бисвас Г. П. и Обайдат М. С. (2019). Эффективная и безопасная бизнес-модель для контент-ориентированной сети с использованием криптографии на основе эллиптических кривых. Международный журнал коммуникационных систем, 32 (1), e3839.

    Артикул Google ученый

  • 50.

    Кумари, С., & Ом, Х. (2016). Протокол аутентификации для приложений беспроводных сенсорных сетей, таких как мониторинг безопасности на угольных шахтах. Компьютерные сети, 104, 137–154.

    Артикул Google ученый

  • 51.

    Шнайер, Б. (2007). Прикладная криптография: протоколы, алгоритмы и исходный код на C . Хобокен, Нью-Джерси: Уайли.

    MATH Google ученый

  • 52.

    Килинц Х. Х. и Яник Т. (2013). Обзор схем аутентификации SIP и согласования ключей. IEEE Communications Surveys & Tutorials, 16 (2), 1005–1023.

    Артикул Google ученый

  • 53.

    Вермезан, О., Фрисс, П., Гийемен, П., Сундмакер, Х., Эйзенхауэр, М., Месснер, К. и др. (2013). Программа стратегических исследований и инноваций Интернета вещей (стр. 7). Брайтон: Серия River Publishers в коммуникациях.

    Google ученый

  • 54.

    Кумар, П., Гуртов, А., Иинатти, Дж., Илианттила, М., и Саин, М.(2015). Легкая и безопасная схема создания сеансового ключа в среде умного дома. Журнал датчиков IEEE, 16 (1), 254–264.

    Артикул Google ученый

  • Использование 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-to-PN CoAP. Вторая причина большой задержки Attach заключается в том, что она также включает сбор кандидатов ICE в PN-B. Главный дополнительный результат этих измерений по сравнению с моделированием заключается в том, что связь между LN и PN составляет лишь незначительную часть сквозной задержки.

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

    (PDF) Протокол ограниченного приложения (CoAP) для IoT

    СЕМИНАР IOT, СИСТЕМА ВЫСОКОЙ ИНТЕГРИТНОСТИ, ФРАНКФУРТСКИЙ УНИВЕРСИТЕТ ПРИКЛАДНЫХ НАУК, 2018 4

    4 Основные элементы БЕЗОПАСНОСТИ 9000 В COAP 9000 при рассмотрении безопасности

    , а именно целостность, аутентификация и конфиденциальность.

    HTTP защищен с помощью протокола TLS

    через TCP [2], [9]. Поскольку TLS полагается на надежную передачу уровня транспортного уровня

    , TLS не может быть легко использован с CoAP.

    Во-первых, проверка целостности данных является последовательной. То есть, если конкретное сообщение

    не получено, проверка целостности следующего сообщения

    основана на неправильном порядковом номере, и поэтому

    не удастся. С другой стороны, рукопожатие TLS

    (аутентификация и обмен ключами) вообще не может иметь место

    , если обмен сообщениями осуществляется ненадежно, то есть беспорядочно или с потерями

    [4], [9].

    CoAP защищен с помощью дейтаграммы TLS (DTLS) поверх UDP

    [2].DTLS на прикладном уровне защищает сквозную связь

    . DTLS также позволяет избежать проблем

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

    две проблемы: переупорядочение и потерю пакетов. DTLS – это TLS с добавленными функциями

    для устранения ненадежной природы транспорта UDP

    . На рисунке 7 показано абстрактное разбиение на уровни защищенного CoAP DTLS-

    .

    Рис. 7. Абстрактное расслоение CoAP, защищенного DTLS [2].

    В отличие от TLS, сообщения DTLS явно нумеруются.

    TLS полагается на правильный порядок сообщений, резервные копии которых сохраняются только

    TCP. Явная нумерация сообщений теперь также снижает уровень защиты рукопожатия: DTLS снова передает пакеты

    (повторная передача), если по истечении определенного времени (таймаут) не было получено никакого ответа

    . Кроме того, записи DTLS

    могут быть как фрагментированными, так и дублированными.

    CoAP-устройству предоставляется информация о безопасности

    , которая ему нужна, включая материалы для ключей и списки контроля доступа

    [2].CoAP определяет четыре режима безопасности, в которых работает устройство CoAP

    , с обязательными NoSec и RawPublicKey

    для реализации:

    NoSec: DTLS не используется. В качестве альтернативы, CoAP может быть

    , используемым с IPsec [2], [4].

    PreSharedKey (PSK): DTLS включен, симметричные ключи

    распределяются по узлам заранее. и каждый ключ

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

    , как описано [2]

    RawPublicKey (RPK): DTLS включен, используется асимметричная пара ключей

    , но без сертификата.Открытые ключи

    устройства хранятся, например, во встроенном программном обеспечении «сырые»

    (без структуры X.509v3) и могут обновляться. Устройство

    также имеет идентификатор, вычисленный на основе открытого ключа, и список

    идентификаторов узлов, с которыми оно может взаимодействовать [2], [4].

    Сертификат: DTLS включен, используется асимметричная пара ключей

    с сертификатами X.509 X.509v3. Сертификат

    , выданный органом сертификации (CA). Устройство также имеет

    список корневых якорей доверия, которые можно использовать для проверки сертификата

    [2], [4].

    Подобно HTTP, CoAP определяет схему URI CoAP.

    Отличается от CoAP только спецификацией схемы.

    CoAP и CoAP должны рассматриваться как автономные серверы,

    , даже если спецификация хоста для URI совпадает. Порт по умолчанию

    для CoAP еще не определен [2].

    5 ЗАКЛЮЧЕНИЕ

    В этой работе был дан обзор нового прикладного протокола

    CoAP. CoAP предлагает преимущества архитектуры REST

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

    Рабочая группа IETF CoRE разрабатывает tocol pro

    , чтобы обеспечить доступ к ресурсам, аналогичный HTTP, для небольших устройств

    в M2M-коммуникации. Такие устройства становятся частью

    Интернета вещей. Заголовок

    CoAP, включая опции, составлен: вместо

    , кодирующего поля в виде строк, они сохраняются в двоичном формате,

    , т. Е. Как можно реже. Была представлена ​​двухуровневая модель взаимодействия

    CoAP: надежность передачи обеспечивается

    на уровне сообщений, а функциональность архитектуры REST

    реализована на уровне запроса-ответа.

    CoAP-сообщения могут быть защищены от касания с использованием шифрования

    протокола DTLS. Тонкая структура полей заголовка

    сообщения CoAP имеет убедительный эффект. Из

    функциональность CoAP, M2M отчетливо видна в качестве основного ориентира

    . Реальные преимущества и недостатки

    по сравнению с другими протоколами приложений, такими как HTTP, станут очевидными только в будущем с дальнейшим распространением

    и внедрением CoAP.

    БЛАГОДАРНОСТИ

    Технологии упростили обучение студентов с помощью новых устройств

    , но ничто не может сравниться с опытом прикосновения великих людей к

    . Спасибо, д-р инж. Эльпиники

    Цакалаки.

    СПРАВОЧНАЯ ИНФОРМАЦИЯ

    [1] Проф. Радж Джайн. Протокол ограниченного приложения для Интернета вещей

    Си Чен, chen857 (at) wustl.edu.

    [2] З. Шелби, К. Хартке, К. Борман, Протокол ограниченных приложений

    (CoAP), Universitaet Bremen TZI.[Июнь 2014 г.]

    [3] Эрик Браун (13 сентября 2016 г.). Кому нужен Интернет вещей ?.

    Linux.com. Проверено 23 октября 2016 г.

    [4] Роман Трапикин (2013-08-1), Протокол ограниченного приложения

    (CoAP): Einfhrung und berblick, Fakultt fr Informatik, Technische

    Universitt Mnchen.

    [5] З. Шелби, Учебное пособие по протоколу ограниченного приложения (CoAP) youtube

    видео, https://www.youtube.com/watch?v=4bSr5x5gKvA

    [6] Браун, Эрик (20 сентября 2016 г.).21 проект с открытым исходным кодом для Интернета вещей.

    Linux.com. Проверено 23 октября 2016 г.

    [7] Глобальная инициатива по стандартам Интернета вещей. ITU. Проверено 26 июня,

    ,

    , 2015.

    ,

    [8], Jonathan Fries (4 мая 2017 года). Почему разработчиков Интернета вещей сбивают с толку

    MQTT и CoAP? techtarget.com. Проверено 28 марта 2017 г.

    [9] Мохаммед Эр-Рияд Абдмезием, Джамель Танджауи и Имед

    Ромдхани, архитектор Интернета вещей: современное состояние. университет

    наук и технологий Houari Boumedienne.

    Интеллектуальное решение для приложений M2M

    Иллюстрация: © IoT For All

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

    Что такое CoAP?

    Представленный в 2014 г., CoAP представляет собой облегченный протокол RESTful, разработанный Целевой группой инженеров Интернета (IETF) CoRE (среды с ограниченными ресурсами). Обычно он используется для приложений «машина-машина» (M2M), таких как интеллектуальные устройства энергоснабжения и автоматизации зданий.

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

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

    Он также имеет механизмы для определения состояния питания устройства. Кроме того, поскольку существует сходство инфраструктуры с операциями HTTP REST, дизайнеры могут использовать свое понимание шаблонов RESTful при разработке приложений IoT, которые они предпринимают с помощью CoAP.

    Краткий обзор протоколов CoAP

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

    Поэтому неудивительно, что устройства IoT используют популярные протоколы CoAP для предотвращения кибератак в приложениях M2M. Они обеспечивают асинхронный обмен сообщениями, обеспечивают поддержку URI и типов содержимого, используют возможности прокси-сервера и кэширования и просты в синтаксическом анализе. Но прежде чем мы углубимся в протокол CoAP, важно понять его структуру, которая обычно состоит из следующих объектов:

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

    Типичный протокол CoAP может показаться похожим на протокол HTTP, поскольку CoAP развертывает протокол дейтаграмм пользователя (UDP) в качестве основного сетевого протокола.UDP, в свою очередь, помогает клиенту разместить запрос, а сервер передает ответ – точно так же, как это происходит в HTTP.

    Два уровня выделяют CoAP

    Уровень запроса / ответа обрабатывает взаимодействие запрос / ответ на основе сообщений запрос / ответ.
    Уровень сообщений имеет дело с асинхронными сообщениями и протоколом пользовательских дейтаграмм (UDP).

    Как видите, протоколы CoAP – это не просто сжатые версии протоколов HTTP, они специально разработаны для Интернета вещей.CoAP поддерживает четыре типа сообщений, в том числе:

    • Reset (RST)
    • Confirmable (CON)
    • Non-confirmable (NON)
    • Acknowledgment (ACK)

    Первичный обмен этими сообщениями является прозрачным к взаимодействиям запрос / ответ. CoAP – это единый протокол, в котором запрос / ответ и сообщения являются функциями заголовка CoAP.

    Как обычно работает CoAP

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

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

    Конструкция модели сообщений CoAP

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

    • Двоичный заголовок
    • Набор компактных опций (необязательно)
    • Полезная нагрузка (необязательно)

    Протокол CoAP определяет Два типа сообщений:

    Подтверждаемые

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

    Не подтверждается

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

    Раскрытие модели «запрос и ответ»

    Это второй уровень протокола. Запрос отправляется с использованием сообщения CON или NON. Если запрос отправляется с использованием сообщения CON, ответ сервера зависит от того, может ли сервер немедленно ответить на запрос клиента:

    • Если сервер может ответить быстро, сервер отправляет сообщение ACK обратно клиенту, состоящее из либо код ошибки, либо ответ, а также поле Token, отражающее поле Token в запросе.Токен отличается от идентификатора сообщения и используется для сопоставления запроса и ответа между двумя конечными точками.
    • Если сервер не может быстро ответить на запрос, полученный от клиента, с другой стороны, он отправляет сообщение ACK с пустым полем сообщения. Как только ответ доступен, сервер отправляет сообщение CON клиенту, разделяющему статус.

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

    Что такое формат сообщения?

    Сообщения CoAP кодируются в двоичной форме. Сообщение CoAP состоит из заголовка CoAP фиксированного размера, дополненного полезными данными и параметрами, указанными в формате «Тип-Длина-Значение» (TLV).

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

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

    • Версия (2-битная версия формата сообщения CoAP; иногда сокращенно «VER»)
    • Тип (2-битовое целое число без знака, которое соответствует типу сообщения RST. , CON, NON или ACK)
    • Token Length (4-битное поле, определяющее длину в байтах поля «токена»; иногда сокращенно «TKL»)
    • Code (8-битное поле, которое предоставляет дополнительную информацию о запросе или ответе)
    • Message-ID (уникальный идентификатор, связанный с сообщением, выраженный 16-битным значением)

    Внесение безопасности CoAP в учетную запись

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

    CoAP применяет UDP для транспортной информации и полагается на него в дальнейшем для защиты информации. Наименьшее возможное сообщение CoAP имеет длину 4 байта и использует два типа сообщений (ответы и запросы) с использованием простого двоичного формата базового заголовка.

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

    Over to You

    В приложениях M2M общие типы мультимедийных данных Интернета, такие как application / XML, application / octet-stream, или text / plain, не оказались полезными для реальных приложений в долгосрочной перспективе. Например, полезная нагрузка приложения Smart Energy может запрашивать более конкретный тип, например application / se + exi, потому что он передается как XML.

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

    По мере роста среды IoT возрастает и потребность в критически важных протоколах для обеспечения экономичной и безопасной передачи данных между устройствами.