Тема 11. Радиосеть сбора данных с ПО

tor_root
Сообщения: 2182
Зарегистрирован: 15 фев 2011, 22:44

Тема 11. Радиосеть сбора данных с ПО

Сообщение tor_root » 30 сен 2019, 22:03

Автор темы: Виноградов Никита
Задание: Радиосеть сбора данных с ПО

Виноградов_619
Сообщения: 17
Зарегистрирован: 10 сен 2019, 12:16

Re: Тема 11. Радиосеть сбора данных с ПО

Сообщение Виноградов_619 » 10 окт 2019, 00:42

Прикрепляю аннотацию к работе студента группы 519 Фадькина Ильи по теме "Радиосеть сбора данных с ПО"
Вложения
анотация.docx
(18.65 КБ) 173 скачивания

tor_root
Сообщения: 2182
Зарегистрирован: 15 фев 2011, 22:44

Рецензия

Сообщение tor_root » 17 окт 2019, 23:43

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

На ресурсе выбранной КР есть видеопрезентации - интересна Ваша оценка видеовыступлений.
Прошу также добавить в сообщение выше ссылки на статьи выбранной КР.

tor_root
Сообщения: 2182
Зарегистрирован: 15 фев 2011, 22:44

Замечания к сообщению

Сообщение tor_root » 01 ноя 2019, 22:54

Замечания к сообщению «Радиосеть сбора данных с ПО» Часть 1

1. В тексте сообщения требуется выделить подразделы, к примеру
1.1.1. Интерпретация назначения сети в виде произвольного прикладного решения в контексте заданной темы.
...
1.1.2. Формализация телекоммуникационной услуги на основании анализа отношений "пользователь-сеть", схематизация отношений.
...
1.1.3. Задачи служб уровня приложения пользователя.

2. Измеряемые параметры:<-- начало предложения, окончание предложения отсутствует.
3. Необходимо учесть возможность/необходимость наложения зон радиопокрытия КТ
4. "1.1.2. Формализация телекоммуникационной услуги на основании анализа отношений "пользователь-сеть", схематизация отношений." - требуются иллюстрации с нарастающей детализацией. Пример анализа отношений "пользователь-сеть", схематизация отношений - работа Елецкого Владислава Высокоскоростной радиомост(ресурс).
5. "Задачи терминального оборудования и интерфейса пользователя/объекта управления" - то, что терминал лишен какого-либо интерфейса для взаимодействия с ПО является недостатком рекламируемого решения. Немного изменить практические условия работы и решение уже не подходит.
6. "1.2.1. Пояснение сеанса предоставления телекоммуникационной услуги, выявление ключевых параметров сеанса." - поверхностная проработка: что-то явно упущено и это сказалось на целостности пояснения. Сеанс должен начинаться с обнаружения сетевого объекта?
7. "1.2.2. Характеристика информационного трафика в прямом и обратном направлениях передачи: вид трафика, производительность или предполагаемый объем сообщений и т.п." - требуются доп. подробности: оценка производительности информационного потока, объем сообщений и т.п. "1.2.3. Формализация требований к качеству и условиям предоставления услуги." - не выполнено.
8. "Проработка сценария выполнения телекоммуникационной задачи с использованием многозвеньевой модели взаимодействия элементов сети." - требуется сформулировать телекоммуникационную задачу; далее целесообразно привести необходимые пояснения предлагаемой диаграммы с использованием маркеров, как в примере ниже из работы Исаева М.:
Изображение
9. Сформулировать список замечаний, полученных в ходе обсуждения выступления и отработать их в новой версии статьи.
10. В сообщении необходимо использовать результаты анализа выбранной Вами работы и привести ссылку на ресурс работы и рецензию - для возможности оперативного сравнения двух работ

tor_root
Сообщения: 2182
Зарегистрирован: 15 фев 2011, 22:44

Замечания к сообщению

Сообщение tor_root » 13 дек 2019, 00:35

Замечания к сообщению Радиосеть сбора данных с ПО (часть 1) (исправленная)

1. "На первом уровне детализации (рис.2) будет показано взаимодейтсвие оператора пункта охраны с устройством видеосъемки, датчиками и охранником" - внимательное чтение п.1.1.2 создает ошибочное впечатление того, что и видеопоток для поста охраны формируется на Т, из представленного анализа требуется исключить неоднозначную трактовку иллюстраций и задач.
2. Есть ряд замечаний к иллюстрации схемы взаимодействия рис.4:
  • не наследуется совершенно правильная идея рис.2, отражающая взаимодействие служб без посредников; пример правильного понимания:
Изображение
  • наличие у ТД двух интерфейсов означает разделение слоев на две части в модели ТД
  • "служба сбора данных" на ТД - несоответствие изложенному ранее материалу: ТД не занимается сбором данных
3. п.1.1.3 выполнен неудачно и фрагментировано.
4. п.1.2.1 - отсутствует собранность и целостность материала, попытка его интерпретации с использованием концепции рис.5 заканчивается неудачей. Кроме того, встречаются непонятные и ошибочные пояснения, к примеру: "В случае, когда передаются данные телеметрии, то пункт охраны всегда отправляет сообщение о достоверности приема, вследствие чего передача телеметрии на пункт охраны с ТД оканчивается, либо идет повторная отправка сообщений" - примените эту фразу к рис. 5... Пояснение сеанса предоставления телекоммуникационной услуги - выполняется по схеме максимальной детализации (рис. 5); пропущено начало раздела, а имеющийся материал слабо (неудачно) подходит под пояснение правил предоставления ТК услуги. В разрабатываемой радиосети под предоставлением телекоммуникационной услуги подразумевается .... Процесс предоставления пользователям ТК услуги включает выполнение нескольких независимых задач:.... Это означает организацию по крайней мере 2 и более независимых ТК сеансов пульта охраны с .... И т.п. примерно в таком виде.
5. В данной сети они будут передаваться со скоростью 16 кбит/с, чего вполне достаточно. - неправильно, обсуждалось неоднократно, к примеру п.9.
6. п.1.2.3 - формализация требований к качеству и условиям отсутствует. Представлен лишь поверхностный анализ ситуации.
7. "Основная задача сети: передача данных телеметрии с терминалов на пункт охраны, поэтому архитектуру сети выберем типа “дерево”" - неверно. Сетевые объекты в радиосети находятся в едином адресном пространстве, в Вашем случае терминалы и ТД создают свое изолированное адресное пространство (со своими правилами адресации ТД<->Т), а пульт охраны и ТД - свое, уже другое адресное пространство со своими правилами адресации (П<->ТД). По факту - две сети с соответствующей топологией. Необходимо разобраться.
8. п.1.3.2 выполняется по обоснованной ранее схеме максимальной детализации, т.е. в соответствии с рис.5 (с учетом п.2) - схема рис.8 не совсем корректно отражает решение задачи.Как пример, схема установления логического соединения в GPRS (активизация PDP контекста)
Изображение
или процедура обновления местоположения Т в GSM сети:
Изображение
9. п.8,9 предыдущих замечаний не выполнены!
10. По оформлению: требуется убрать пустые строки из текста и использовать единый шрифт при оформлении текста.

Виноградов_619
Сообщения: 17
Зарегистрирован: 10 сен 2019, 12:16

Re: Тема 11. Радиосеть сбора данных с ПО

Сообщение Виноградов_619 » 18 дек 2019, 01:16

Список замечаний, полученных в ходе обсуждения первого выступления:
1)Выявлен недостаток - зоны радиопокрытия ТД не пересекаются. Из этого следует, что, если охранники будут вне зоны обслуживания и на них нападут оповещение не сможет прийти на пункт охраны.
2)Пункт охраны никак не взаимодействует с терминалом, не может отправлять на терминал оповещения или сообщения. Необходимо доработать.
3)Функциональные схемы выполнены неверно, данные схемы скорее являются структурными. На функциональных схемах должны отображаться функции сетевых объектов.

Список замечаний, полученных в ходе обсуждения второго выступления:
1)Не понятно назначение службы управления мобильность, так как такового управления мобильностью нет, не переходит передача обслуживания при пересечении зоны обслуживания ТД. Необходимо убрать данную службу, либо описать процесс передачи обслуживания.
2)Контроль качества соединения выполнен неверно, так как данный вид контроля активного соединения применим при длительном соединении. В моей же работе подразумевается передача данных и сообщений небольшого объема, поэтому логичнее предусмотреть на данным уровне службу ARQ, которая уже после приема сообщения, если возникнут ошибки, отправит запрос о повторной передаче.

tor_root
Сообщения: 2182
Зарегистрирован: 15 фев 2011, 22:44

Замечания к сообщению

Сообщение tor_root » 18 дек 2019, 16:41

Замечания к сообщению Радиосеть сбора данных с ПО (часть 2)

1. Сформулировать список замечаний, полученных в ходе обсуждения выступления и отработать их в новой версии статьи.
2. Рекомендации Особенности выполнения раздела №2
3. п.2.1.1 - связать с первым сообщением
4. п.2.1.2 - преимущественно неактуально для условий Вашей работы; "Однако может быть и обратная ситуация ..." - довольно спорное решение: множество терминалов, управляющие одной ТД?
5. п.2.1.3 - кроме того, что имеется в рекомендациях, остались вопросы относительно формирования BCCH, совместной работе БС с пересекающимися зонами радиопокрытия.
6. п.2.2 - требует доп.проработки, обсуждалось. Кроме того, службы, которые функционируют в пределах базовых зон радиопокрытия, должны входить в состав канального уровня в виде отдельного слоя. На сетевом (L3) уровне располагаются службы, обеспечивающие прямое взаимодействие Т-ПО.
7. п.2.3.1 - описание каких-либо процедур/процессов не требуется. Достаточно анализа необходимости идентификации различных объектов, каналов, служб и т.п. К примеру: после отработки службы доступа SRV_ACCESS, Т назначается временный идентификатор сессии, который будет обозначать установленное логическое соединение между ТД-Т и/или ПО-Т (при необходимости). Любая доставка сообщений по этому соединению будет включать указание соответствующего номера сессии. После успешного завершения задачи службы доставки телеметрии SRV_PROVIDER, установленная ранее сессия прекращается.
8. п.2.4. должен строится с учетом терминов служб и материала п.2.1, см. рекомендации Особенности выполнения раздела №2. Событие (4) на рис.2 противоречит приведенному описанию.
9. п.2.5 - рекомендации Особенности выполнения раздела №2

tor_root
Сообщения: 2182
Зарегистрирован: 15 фев 2011, 22:44

Замечания к сообщению

Сообщение tor_root » 05 янв 2020, 21:40

Замечания к сообщению Радиосеть сбора данных с ПО часть2 (исправленная)

1. п.2.3 - привести именные обозначения вводимых в разработку идентификаторов, эти именные ID должны использоваться при проработке слоев L2 и L1 (при необходимости)
2. п.2.5 - сценарии отсутствуют. Представлено краткое пояснение того, как соответствующие сценарии должны работать. Ожидается описание сценария в виде протокола обмена соответствующими сообщениями - как реакция на определенное событие.

tor_root
Сообщения: 2182
Зарегистрирован: 15 фев 2011, 22:44

Замечания к сообщению

Сообщение tor_root » 05 янв 2020, 22:55

Замечания к сообщению Радиосеть сбора данных с ПО часть 3

1. "В данной сети можно выделить следующие виды логических соединений" - неверно. Представлен перечень логических каналов связи.
Логические соединения характеризуются: видом и способами обмена сообщениями - широковещательное/адресное/прямое/обратное/двухстороннее; протоколом обмена; источником и получателем сообщений; идентификатором соединения (опционально) и т.п. П.3.1. должен отражать специфику разработки и наследовать многие вещи из 2 части работы. Обобщенные (вне контекста конкретного материала первой и второй частей) пояснения/размышления неуместны.
2.п.3.2 имеет несоответствия с представленным ранее материалом:
Изображение
Также к задачам службы передачи данных канального уровня имеют отношение выделенные Вами доп. службы.
3. "Сигнальные сообщения: ..." - некоторые моменты спорные. Следовательно, потребуется соответствующая аргументация о необходимости выделенных сигнальных сообщений.
4. п.3.5 не выполнен, т.к. 1) отсутствует сценарий исполнения сессии обмена сигнальными сообщениями; 2) реализация ARQ не поддерживается предложенным форматом сообщений DCH.
5. Интересует пояснения формата сообщений для службы L3 уровня.
6.п.3.6.1 - неверно: наложите обоснованную Вами архитектуру радиосети на обозначенный концепт п.3.6.1 - из этих двух решений никак не может следовать то, что представлено в п.3.7.
7. "Пакеты L2 уровня каналов BCCH, AGCH, ACH имеют достаточный объем, чтобы передать полностью информационные сообщения для служб управления" - а если транспортные возможности пакетов L2 избыточны для сигнальных сообщений, т.е., к примеру, передается сигнальное сообщение "ACK" (acknowledge) длиной 1..10 битов с помощью пакета DCH с полем для данных 205 битов - как служба "поймет" какие биты из 205 "по настоящему" информационные???
8. "В данной работе базовой скоростью кодирования будет 3/4, а при необходимости увеличения помехоустойчивости будет использоваться скорость кодирования 1/2." - не ясно: о какой службе идет речь? "при необходимости увеличения помехоустойчивости" - требуется ссылка на описание соответствующего сценария.
9. Задачи п.4.1 целесообразно решать с учетом п.3.7, целиком основываться на производительности источников инф. и сл. сообщений не стоит - L2 сообщения по физической среде могут передаваться с существенно большей скоростью: отношение полосы результирующего р/с к центральной частоте передачи желательно не допускать меньше 1е-4, иначе неизбежные сложности с процессом приема.
10. "В поле FEC находятся избыточные биты, полученные в результате помехоустойчивого кодирования;" - неверно
11. п.4.4 - неверно, т.к. не учтен фактор пакета L1 (рис.11)+ незапланированные мероприятия типа ARQ. Обобщенный энергетический расчет должен производиться в том числе с учетом п.3.6 и на основании п.3.7 (рис. 5)

Виноградов_619
Сообщения: 17
Зарегистрирован: 10 сен 2019, 12:16

Re: Тема 11. Радиосеть сбора данных с ПО

Сообщение Виноградов_619 » 07 янв 2020, 02:46

У меня есть вопросы касательно п. 4 и п. 5 замечаний:

1.Было указано, что отсутствует сценарий реализации ARQ. Но подробное описание сценария производилась во второй части в п. 2.5. Могу ли я просто сделать ссылку на него?

2.Вы сказали, что сообщения DCH не поддерживают реализацию ARQ. Я предполагал, что, если будет обмен сообщениями службы ARQ, то оно будет считаться служебным, то есть в поле флага будет указание на служебное сообщение, а в поле службы будет указание на службу ARQ. Тем самым будет понятно какое количество бит необходимо извлечь из информационного поля сообщения DCH и направить в службу ARQ. Остальные биты в информационном поле будут нулевыми. Похожая ситуация со всеми службами. Могу ли так описать?


3. Также возник вопрос о формате сообщений L3 уровня. На L3 уровне у меня присутствует лишь одна служба, то есть мне необходимо пояснить формат сообщений для неё с указанием всех полей и что в них расположено?

4. И последнее, на основании ваших замечаний начал сомневаться правильно ли я понял. В третьей части я рассматриваю форматы сообщений логических каналов. Все служебные сообщения подуровня управления на L2 уровне и соответственно служебные сообщения L3 уровня передаются в сообщениях этих логических каналов. Для логических каналов AGCH, BCCH, ACH заранее понятно каким службам адресованы сообщения, но вот в канале DCH предполагается передача сообщений нескольких служб, поэтому для их разделения и используется поле "тип службы". На основании информации этого поля принимается решение в какую службу подуровня управления L2 уровня или службу L3 уровня отправить данное сообщение. Могу ли я так описать все?


Вернуться в «Курсовые работы»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 2 гостя