Разбор публикаций по темам КП

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

Милованову Сергею

Сообщение tor_root » 06 ноя 2012, 11:21

Обсуждаемое сообщение "С.А.Милованов - Система сбора данных с подвижных станций (часть 2)"

Сергей, Ваше сообщение понравилось. Проработка задач - на уровне. Выскажу следующие замечания:
1. Целесообразно привести схему уровней Вашей системы - этот рисунок надо будет разработать именно по приведенному Вами исчерпывающему описанию. Такого рисунка очень не хватает в сообщении.
2. Не ясно как сообщения подсистемы сигнализации распределяются по физ. каналам. Правда, это задача построения радиоинтерфеса, подождем...
3. "Канальный уровень принимает от верхнего уровня пакет данных, а также указание, какому узлу его передать. Канальный уровень формирует из принятых пакетов собственные протокольные единицы данных — кадры, состоящие из поля данных и заголовка. Канальный уровень помещает принятый пакет в поле данных одного или нескольких кадров (в зависимости от объема пакета) и заполняет собственной служебной информацией заголовок кадра [3]" -как это соотносится с решаемыми системой задачами? Это концепция работы терминалов?
4. "Канальный уровень должен иметь возможность обнаружения и коррекции ошибок" - вторая функция как раз и необязательна. Тем более Вы ее не используете. Вопрос: что-же тогда обеспечивает гарантированную доставку данных? Будет иметь место ARQ при передаче речи? Для всех ли видов сообщений будет действовать сценарий ARQ?
5. Как в сценариях, так и при описании доступа к ФК как-то пропущен вопрос об идентификации оптимального профиля и не отражена стратегия использования данных подсистемы радиоизмерений (как ее задачи трансформируются в специфику обработки рассматриваемых ниже сценариев?).
6. По физ. уровню: рис.1 не полностью отражает те задачи и службы, о которых было сказано в сообщении (служебная информация физ. уровня - синхронизация, обучающие последовательности , пакеты физ. уровня, управление профилями и т.п.). То, что отражено на рис. 1 - подходит для сообщений всех логических каналов: для каналов трафика, BCCH, RACH и т.д.? Есть сомнения по этому поводу...
7. При обсуждении служб канального и физ. уровней как-то упущено рассмотрения ряда проблем, связанных с организацией дуплексного радиотелефонного соединения.

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

Лашко Сергею

Сообщение tor_root » 06 ноя 2012, 11:45

Обсуждаемое сообщение "КП “Радиосистема управления освещением” Часть 2"

Сергей, к Вашему сообщению есть следующие замечания:
1. Описание уровней взаимодействия моделей Ваших сетевых объектов необходимо пояснять в виде пояснения процедуры доставки сообщения верхнего уровня от одного сетевого объекта к другому по всем нисходящим уровням модели. Должно быть четкое разделение сообщений трафика, широковещательной рассылки и сообщений подсистемы сигнализации.
Многие вещи в сообщении присутствуют, только изложены не в требуемом порядке. Единственно, что не совсем понравилось - описание физ. уровня, рис. 1. считаю лишним. Это описание потребуется скорректировать с т.з. приведенного выше требования: как через физ. уровень будут доставляться различные сообщение канального уровня? Какого рода появляется служебная информация на физ. уровне? Подобные моменты должны быть представлены на рис.2.
Вместе в описанием задач физ. уровня целесообразно приводить и структуру полей пакетов - если Вы уж сочли уместным их приводить в этом сообщении.
2. Целесообразно при описании служб канального уровня привести сводную таблицу всевозможных соощений канального уровня, привести их условное обозначение, краткую расшифровку. Введенные обозначения привести на поясняющих рисунках 3 и 4. От этого качество сообщения только выиграет.
3. Рисунки 3 и 4 целесообразно дополнить альтернативной формой пояснения - временными диаграммами наподобие наподобие рис.17 из учебного пособия.

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

Подкопаевой Светлане

Сообщение tor_root » 08 ноя 2012, 22:25

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

1. рис.1 - рис.3 целесообразно сделать самой.
2. п.2 из замечаний в сущности не выполнен: вместо пояснения основной услуги разрабатываемой сети (характер передаваемых сообщений, способ доставки сообщения, возможность real-time и т.п. - вот это анализ) - набор общих, малозначимых фраз.
Непонятно, как терминалы радиосети смогут передавать сообщения сетевым устройствам проводной сети? это еще одна услуга или все та же, которая основная? Сетевой уровень случаем не нужен?
По второй услуге - совсем непонятна мысль "Сведения о других активных абонентах (в режиме реально времени) необходимы для оптимизации работы сети.": что имеется в виду под реальным временем? Что означает фраза "для оптимизации работы сети"? Это услуга заказываемая абонентами? Имеется ли возможность доставки сообщения напрямую между терминалами или через ТД? Вместо ответов на подобные вопросы - зачастую банальные вещи.
3. "В данном проекте работой сети управляет администратор через сеть Internet." - это как, на всякий случай? Пусть читатель домысливает, с какой целью управляет админ работой сети (!?) через Интернет... И почему через Инет?
4. Относительно перечисления функций ТД и Т: пояснение перечисляемых функций целесообразно приводить сразу после их наименования - так читабельней.
- "Предоставление услуг связи;", "Формирование запроса на предоставление определенных услуг связи" - каких это услуг? Требуется попытаться пояснить разнообразие услуг.
- "Формирование сообщений для передачи , прием сообщений;" - сообщения разве не формируются в приложени пользователя (ПК)?
- "Формирование отчета о доставке сообщения" - что за доставка сообщения терминалом - до мыслительного аппарата абонента?
- "Аутентификация пользователей..." - непонятно, откуда ТД будет знать о данных аутентификации? Как подобные данные будут загружаться в ТД? Неужели admin с приставной лестницей будет совершать обход ТД?
и т.п. Подобных моментов, требующих элементарных пояснений, много.
5. вместо (см. рис 1) достаточно привети (рис. 1) - читающая публика в основном не глупая, сообразит, какое действие подразумевается подобным указанием.
6. "Сценарий обслуживания (профили работы) сети представлены в виде некой таблицы (см. табл. 1). Изменение данных профилей, в зависимости от ситуации, оптимизируют работу данной сети." - неграмотно, поверхостно, а с содержимым табл.1 как-то получается глупо.
7. Считаю, что "МУ" не является частью ИС. Это, по всей видимости, тяжелая доля УМа...
8. "В журнале предоставляемых услуг прописан весь перечень услуг, которые может предоставить проектируемая локальная сеть (см. п.1,1 )" - спасибо, конечно, за ссылку, но вот в п.1.1 отражена по существу только одна услуга...
9. Примите к сведению следующие замечания , в особенности п.1,2 и 4, а также эти. Они обязательны к пробработке. Уверен - справитесь.
10. В условиях серьезной переработки сообщения считаю целесообразным создавать новый документ, а не исправлять существующий (чтобы когда-нибудь, в комфортной обстановке, не без удовольствия наблюдать за эволюционным прорывом...)

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

Кривошеиной Марии

Сообщение tor_root » 13 ноя 2012, 20:48

Замечания к сообщению Марии Кривошеиной "Компактная система радиотелефонной связи. 3 этап."

1. "Описание назначения сервисов канального уровня исходя из контекста решаемых задач" - отсутствует. Это описание должно основываться на материале п.1.4 и отражать вполне конкретные сервисы канального уровня.
2. "Исходя из концепции построения системы можно сделать вывод, что для безошибочного предоставления услуг связи, необходимо точно знать следующие параметры..." - совершенно не понятно, как цитируемое перечисление связано с задачей
Определение способов адресной и широковещательной доставки сообщений канального уровня.
3. "непозволительно перезапрашивание потерянных пакетов еще раз" - непонятен атрибут "потерянный" пакет - не дошедший до приемной антенны? Будьте внимательней.
4. "Но, в системе каналы открыты и сотрудники завода периодически перемещаются, а значит и условия передачи будут изменчивы." - сотрудники перемещаются по открытым каналам? О чем идет речь? Условия передачи чего будут изменчивы?
5. "Если система не справилась с исправлением, то речевые пакеты можно отбрасывать, поскольку на передаваемом сообщении это никак не скажется." - не справилась с исправлением чего?
Примитивный и умозрительный способ изложения своих мыслей. Если для п.1.1 - 1.3 подобный стиль еще можно принять, в п.1.4 и далее - совершенно неподходящий.
В п.1.6 Вы должны абсолютно четко отразить возможность передачи разнообразных сообщений, генерируемых на всех этапах сценария соединения, по отдельным логическим каналам.
Насколько качественно надо "закрывать" от ошибок сообщения различных ЛКС? Где такой анализ? В ответ лишь: " длина речевого сообщения не должна быть слишком большой, для отсутствия «квакающего» звука в трубке абонента...". «Квакающий» звук в трубке - это ее такая шутка над абонентом?
Считаю, что не следует переносить жаргонные выражения в квалификационную работу.
6. " допустимо не более трех ошибок на 10е-5 переданных символов" - ??? это как себе предстваляете? одна стотысячная какого-то символа?
Вывод: 1.6.2. Выделение типов логических каналов связи, используемых на канальном уровне. Назначение сообщений, передаваемых по каждому ЛКС. Оценка возможности применения ARQ в ЛКС. Способ обеспечения достоверности принимаемых сообщений. - не раскрыт

7."Рассмотрим способ обеспечения достоверности принимаемых сообщений." - ниже по тексту сообщения следует пояснение совершенно правильных идей, которые выглядят весьма глупо на фоне п.1.4 и не выполненного п.1.6.1.
8. "В проектируемой системе используем логические каналы:" - где завершение этого предложения? Почему обоснование ЛКС выполнено в отрыве от сценариев взаимодействия МС-сеть?
9. "Проведем оценку полного трафика системы" - практически отсутствует аргументация, рабочие материалы обсуждения перенесены в сообщение без какого-либо осмысления. "щепотку того, щепотку этого - пожалуйте - 128кбит/с!"
Как, кстати, будет реализовываться двусторонний обмен? Временной, частотны дуплекс? В таблице отразить долевую оценку каждого ЛКС и указать ссылку на те фазы сценария, в которых используются ЛКС. "FCCH" - далее по тексту "потерян".
10. В разделе 1.6.4. "Анализ необходимости наличия разных профилей настройки физического уровня. Способ оперативного управления профилями ФУ." представлена откровенная халтура неясного происхождения. Видимо, с инет-помойки...
11. "Пользовательское устройство считывает информацию, которая передается по данному каналу, и определяет параметры сети. Далее происходит синхронизация терминала по частоте и по времени. " - это просто праздник какой-то. Поясните пож. - как можно "считать" информацию по каналу ВССН, а уже потом осуществлять синхронизацию по частоте и времени? Как сложно понимать вас, гениев...
12. "Сигнал на радио интерфейсе системы сотовой связи редко когда распространяется по прямой." - все по кривой, да по наклонной... В избранное, однозначно.
13. п.1.7.3 - выполнен неполностью. Связь с рис.11?? Какие еще меры противодействия многолучевости применяются в Вашей работе? Это задача физ. уровня, не так ли?
14. рис.10 - неверный, где его соответствие рис.4?

По расчету.
1. формулы пронумеровать.
2. учесть, что формулы являются частью предложения - расставить знаки препинания.
3. пояснить все величины, входящие в выражения; в особенности - поля табл.??
4. "В вакууме.." нет воздуха и справедливости - расчет неверен.
5. Выбор способа модуляции неясен и затушеван.
6. "Обоснованный выбор помехоустойчивого кодирования, перемежения, деперемежения, оценка эффективности кодирования" не нашел
7. df - как получилось такое значение? Во всех выражениях требуется раскрывать значения применяемых величин - в целях борьбы с недостаточной освещенностью...


Оставшиеся 53 замечания, наверное, будут изложены позже.

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

Ночной Анне

Сообщение tor_root » 16 ноя 2012, 00:34

Замечания ксообщению Ночной Анны "КП на тему "Локальная радиосеть" п. 1.6-1.7 (часть №3)"
1. Относительно сервисов канального уровня
Общее замечание: весь материал п.1.6, а также п.1.7 должен быть непосредственным образом связан с предыдущими разделами: общие термины, решения, сокращения. Если при выполнении п.1.6 или п.1.7 появляются новые сведения о системе, то они должны найти свое аргументированное место в предшествующих пунктах. Как пример: «Канальный уровень может создаваться для различного сервиса, который может варьироваться от системы к системе. Однако, есть три общие вида сервиса…» - к чему это при наличии п.1.4??? Если забыли это указать в п.1.4 –корректируйте его, указав, разумеется, на необходимость и назначение новых функций/свойств (с т.з. транспортных функций 2 уровня). Здесь общие моменты построения КУ некой абстрактной системы неуместны.

1.6.1. Описание назначения сервисов канального уровня исходя из контекста решаемых задач.

Описание назначения сервисов канального уровня должно быть построено исключительно по материалу п.1.4 и целесообразно в том хронологическом порядке, который определяется проработанным в п.1.5 сценарием взаимодействия ТД и Т. Если Вы в этом разделе вводите новые задачи/цели канального уровня (никак не представленными в п.1.4), то п.1.4 должен быть соответствующим образом переработан.

2. «Как было уже сказано в предыдущих статьях, каждый терминал и ТД имеет свой уникальный ID-адрес … » - это имеет отношение к объяснению состояния поиска сети? В п.1.6 это описание не требуется. В любом случае, в подобных условиях требуется ссылка на соответствующий раздел пояснительной записки.

3. «Для осуществления маршрутизации при входе в сеть каждому терминалу присваивается временный идентификатор» - что-то непонятно… Зачем? Об этом шла речь в сообщении 2?

4. С адресацией в п.1.6 все же есть какая-то путаница. Непонятно. Поясните этот вопрос лучше на примере полного цикла доставки сообщения от одного Т к другому, отражая по ходу объяснения применения адресов/идентификаторов. С этой целью потребуется разработать соответствующий рисунок - в виде набора временных диаграмм, на подобие рис.17 из учебного пособия. Он же будет уместен в п.1.5.2.

5. «Терминалы, борясь за выделение им канала связи, участвуют в конкурентной борьбе. Для этого используется метод CSMA (неустойчивый)» - это материал п.1.5.2.Пояснение способа организации доступа к физическому каналу.
Именно там Вы должны были в деталях пояснить – что это такое «конкурентная борьба Т»? Как она практически будет проходить?

6. «Но в случае, если канал уже используется, то терминал ожидает случайный период времени и алгоритм повторяет заново.» - примитивно и неверно. Неосмысленное цитирование сомнительного источника из инет-помойки...

7. «В данной системе используются следующие логические каналы связи, используемые на канальном уровне» - в перечислении необходимы ссылки на рис. 3,4 и на содержимое п.1.5.3 сообщения №2. Почему обозначения ЛКС не используются на рис.1? М.б. они лишние в контексте Вашей работы?
8. «По данному каналу терминал передает запрос на регистрацию в сети. А также делает запрос на выделение канала трафика для передачи сообщений абонента.» - ??? И то, и другое? Может внимательней прочтем собственное творчество п.1.5.3?
9. «ACH (Access Channel) – канал разрешенного доступа, по которому точка доступа сообщает терминалу параметры выделяемого под сеанс связи канального ресурса.» - о чем идет речь? Если об этом говорилось ранее – ссылку.
10. «TCH Канал трафика - предназначен для передачи данных» - ??? Требуется пояснение с т.з. рис. 4 (п.1.5.2, сообщение 2) и рис.1 текущего сообщения.
11. «Для долевой оценки отведем на каждому интервалу свое процентное соотношение…» - к чему здесь непонятные битовые значения?? Откуда взялось 4 Мбит/с? Невысказанные мысли понимать не научен… Выполнено с ошибкой.
12. Рис.2 – неуместен. Лучше доработать рис.1.
13. О конкретном «наполнении» profiles станет известным только тогда, когда Вы сделаете вывод по сравнительным результатам энергетического расчета. Следовательно, таб. 2 – преждевременна. Откуда взялся ряд 6, 12, 24 Мбит/с?? В п.1.6.4. должно найти отражение «Анализ необходимости наличия разных профилей» и описание способа управления профилями – т.е. как Т и ТД договариваются об использовании конкретного профиля? На основании чего и на каком этапе. Четкое пояснение процесса на основе материала 1.5.2, 1.5.3 и, возможно, 1.6.1.
14. «Рассмотрим структуры пакетов канального уровня.» - идея мне в принципе понятна. Но непонятно следующее: как слой управления поймет, что за сообщение поступило с канального уровня? У Вас они все обезличенные… Непонятно – почему канальный уровень должен передавать сообщения разной длины? Очень неудобно. Почему бы не использовать поле «длина сообщения» и привести все сообщения КУ к одному формату? Вы хотя бы в пол глаза посмотрели бы на сообщения GSM и МАС 802.11… Как я понимаю, ARQ осталось не у дел? В сообщениях Вашего канального уровня FL представляется лишним. И, кстати, зачем в большинстве сообщений указывать ID ТД, на всякий случай?
15. «Пакет запроса на повторную передачу» - что-то я перестал понимать Ваш сценарий. В сообщении 2 отражается другая концепция. Впрочем, было бы весьма неожиданно ожидать иного к 5 часам утра…
16. «Опишем процедуры типового обмена сообщениями между объектами канального уровня» - обязательно требуется подготовить рисунки на подобие рис.17 из учебного пособия (аналогичное замечание в п.4). Здесь же необходимо использовать введенные Вами выше типы сообщений канального уровня.
17. Убрать бред, начиная с фразы «Основное назначением физического уровня..» до фразы «..пакета из капсулы называют декапсуляцией». Применить четкое описание задач и структуры PHY на основе п.1.4. Коротко пояснить то, что будет спланировано в п.1.7.9.
18. п.1.7.3 – короче, четче и без лишней воды. И так уже воды предостаточно…
19. ( http://rfcmd.ru/sphider/docs/GKRCh/GKRC ... 04-003.htm ) - оформить в виде ссылки на литературу. «Разрабатываемая сеть основана на стандарте IEEE 802.11a/» - вот это новость. В чем именно основана?
20. «Данная модель ITU – R 1238» - почему данная? Кем данная? Ссылка на инет-источник литературы по модели, желательно оригинал.
21. Постановочная часть расчета неграмотная, топорная. «R/ log2 (16)» - это что? Уж не BPSK случайно? Все это выглядит по крайней мере странно в свете п.1.7.9.
22. п.1.7.5 – что за код, его параметры? Сверточный код накладывает ограничения на формат сообщения КУ. Глубина перемежения?? п.1.7.6 неверен (1.7.4).
23. Профили физ. уровня? Самое время их вводить и делать сводную оценку энергетики. R будет разным? В формулах R – тоже разный?
24. Применяемые формулы пронумеровать и использовать ссылки на них из текста. Напоминаю, что формула – часть предложения.
25. рис.14 и соответствующее описание – неполные. Непонятно – как Вы собираетесь обрабатывать сообщения длиной 20-40 битов – в особенности перемежение…?
26. п.1.7.9. – не хватает пояснений, поясняющих отражение физического кадра на OFDM символы.

Не смотря на обилие просчетов и недостатков – работа проделана приличная и с присущим Вам характером. Хорошая основа для блестящей статьи.

an_nightly
Сообщения: 17
Зарегистрирован: 21 авг 2011, 13:43

Re: Разбор публикаций по темам КП

Сообщение an_nightly » 16 ноя 2012, 02:16

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

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

Re: Разбор публикаций по темам КП

Сообщение tor_root » 16 ноя 2012, 07:24

Остается пожелать удачи.
И высыпаться.


Вернуться в «Курсовой проект»

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

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