Разбор сообщения по первой части КП

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

Замечания к сообщению Попова Артема

Сообщение tor_root » 23 ноя 2011, 16:01

Артем!
1. Требуется сформулировать список основных и дополнительных услуг, предоставляемых сетью. Каждая услуга, как основная, так и дополнительная, должна найти свое отражение либо на функциональной схеме, либо на схеме информационной подсистемы сети - по обстоятельствам.
2. Сформулировать задачи терминалов, БС и коммутаторов с точки зрения назначения сети, проработать их функциональные схемы.
3. Обосновать способ совместной организации зон радиопокрытия нескольких БС, исключающий взаимные помехи между БС.
4.Изложить концепцию ПО, действующей в сети.
5. Для такого размера сети модуль подлинности использовать нецелесообразно. Решите соответствующую проблему иным образом.
6. Предусмотрите возможность эксплуатации нескольких подобных сетей на одной территории: конфигурирование, ЭМС и т.п.
7. Рисунки должны быть пронумерованы и дополнены подписями и ссылками из текста.

Кроме того, напоминаю:
1. Требования к оформлению сообщений: Правила
2. Обсуждение ошибок работ Ваших товарищей: Обсуждения
3. Ознакомьтесь с материалом ссылок и скорректируйте структуру Вашего сообщения.

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

Замечания к сообщению Кристины Маркиной

Сообщение tor_root » 25 ноя 2011, 09:43

Обсуждаемое сообщение
Кристина!
Отмечу следующее:
1. отсутствует схема физ. уровня, иллюстрирующая те задачи, которыми Вы его наделили (наподобие соответствующего рис. из методических указаний работы по GSM);
2. утверждать о параметрах помехоустойчивого кодека и видах модуляции преждевременно - это обосновывается только на этапе энергетического расчета; здесь можно строить только предположения, но в любом случае нужно указывать способ управления профилями, т.е. как будут передаваться команды на переключение, на основании чего, какой профиль будет действовать по-умолчанию?
3. представленная на рис. диаграмма состояний по всей видимости относится к верхнему слою модели, т.е. в Вашем случае к двум слоям канального уровня; следовательно, на диаграмме в целом должны быть отражены задачи и функции этих слоев; кроме того, диаграмма состояний должна включать и ТСД, как главного объекта сети;
4. прилично описан сценарий функционирования сети на физ. уровне - не хватает соответствующей иллюстрации;
5. осталось нераскрытым решение проблемы коллизий - как следствия наличия множественного доступа; т.е. неясно, как будет обслуживать радиомаяки ТСД в условиях, когда неизвестно, какие радиомаяки находятся в ее зоне радиопокрытия?
6. проработка структуры пакетов несколько преждевременна - это вопрос проработки радиоинтерфейса; если Вы считаете, что именно здесь целесообразно осуществить синтез структуры пакетов, то тогда обоснованию назначения полей пакетов надо уделить большее внимание. В этом случае, в разделе разработки радиоинтерфейса останется провести уточнение ранее предложенного варианта интерфейса (если потребуется) и выяснить вопрос с размерностью полей.
7. при пояснении задач физ. уровня Вы заложили инструмент борьбы с многолучевостью в виде эквалайзеров, но эта идея не получила поддержки на уровне структуры полей пакетов; аналогично - по помехоустойчивому кодеку (где-то в описании и на рисунке должны появиться фразы типа "зашифрованные данные").

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

Замечания к сообщению Горюшкина Руслана

Сообщение tor_root » 27 ноя 2011, 22:05

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

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

Замечания к сообщению Попова Артема

Сообщение tor_root » 27 ноя 2011, 23:25

Обсуждаемое сообщение
1. Рис.2 и рис.3 имеют отношение к описанию сценариев обслуживания МС в сети, но никак не к функциональным схемам сетевых объектов. В Вашем описании МС и БС - "черные" ящики с неизвестной функциональной "начинкой" - именно это надо раскрыть.
2. Для такой небольшой сети выделять отдельно коммутатор - явно лишнее. Вспомните демонстрацию на занятиях работы БС GSM: всего ничего - один ноутбук и цифровой трансивер - 3 одновременных сеансов связи GSM.
Для Ваших целей куда перспективнее использовать подход VoiceOverIP. На каждой БС имеется свой информационный регистр, регистры могут взаимодействовать через удаленный сетевой узел (сервер), на котором будет хранится информационная система (содержимое всех регистров) в полном объеме.
3. "Частоты работы БС определяются администратором сети." - эта возможность, помимо всего остального, должна быть отражена на соответствующей функциональной схеме БС
Как и Горюшкину Руслану:
4. Поскольку Вы приняли решение о делении зоны радиопокрытия на несколько зон меньшего размера, то от Вас потребуется оценка размера получающихся зон радиопокрытия и определение "экономии" по мощности терминалов.

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

Замечания к сообщению Ильи Минаева

Сообщение tor_root » 28 ноя 2011, 17:36

Обсуждаемое сообщение
1. Доработать предшествующие сообщения, с учетом замечаний и используемых аббревиатур и сокращений.
2. По возможности, не используйте жаргоны и упрощения тех. языка. Это касается «на прямую», "транзитов" и т.п.
3. "Согласно предыдущим статьям" - при упоминании своих сообщений делайте ссылки на работы.
4. "Поэтому, для того, чтобы терминалы рассматривали предназначенные для них сообщения, необходимо только добавить блок, анализирующий идентификационные номера. «Ненужные» пакеты он будет отбрасывать." - это взаимодействие никак не отражено в п.1.1 - 1.6. Кроме того, куда добавляется блок? В состав соответствующей функциональной схемы?
5. "Поэтому при получении кадров маяка, КУ начинает борьбу в случае если в кадре присутствует ID своей ТС" - аналогично п.4. Противоречие материалу п.1.4-1.6. "Кадр маяка" очень неудачное обозначение; может подойдет "широковещательное сообщение"?
6. "ПС хранит в своей базе все ID ТС, либо идентификаторы точек своей зоны обслуживания, в случае если поселение больших размеров" - предложение непонятное и, кроме того, с аббревиатуры оно не должно начинаться. Что за "база"? Мелкооптовой торговли?
7. "КУ посылает небольшое число данных, которое умещается в рамках одного пакета. В рамках одного мультикадра, КУ передаёт 1 пакет. И если произошла ошибка, то КУ передаёт его заново, пройдя цикл борьбы за канал (см статью 2). В случае передачи данных от ТС к ПС, речь идёт о других размерах информации. Приходится использовать несколько пакетов." - непонятно. О чем идет речь? Приводите ссылки на определенные разделы ранних сообщений

Материал, отмеченный в пп.4-7, имеет непосредственное отношение к п.1.4-1.6 задания. Целесообразно это перенести в предыдущее сообщение с устранением имеющихся противоречий.

8. "Обеспечение достоверности будет реализовываться за счёт сравнения принятого пакета с параметрами этого пакета, хранящимися в нём же, такими как контрольная сумма и др." - требуется изложить подробнее: какие сообщения и каким образом предполагается защищать от ошибок? С исправлением или без? На каком уровне принимается решение о повторной передаче?
9. "Для передачи маяков используется широковещательный канал BCCH. Данные передаются по каналу трафика TCH. Для передачи подтверждений используется канал сигнализации SCH." - постройте развернутое обоснование необходимости ЛКС. Рассчитанную пропускную способность ЛКС отразите в таблице 1.
10. Все поля пакетов должны быть пояснены, оценены их размеры. Размеры некоторых рисунков можно уменьшить. Какой смысл отражать в предыдущем сообщении структуру полей пакетов канального уровня?
11. "Трафик между ТС и ПС существенно больше" - а до этого о чем шла речь??
12. п.1.7.7 - подробное изложение с применением обозначений ЛКС и в соответствии со сценарием обслуживания.
13. 1.8.1. -выполнен неверно;
1.8.2 - аргументация в принципе верная, выбор тех. решения явно неоптимален - странный выбор. Почему бы не использовать эквалайзер? Перемежение с кодированием можно рассматривать как элемент временного разнесения и в условиях медленных замираний - отличное решение.
1.8.3. - цитата из документа ГКРЧ относительно выбранного диапазона; требуется подробное изложение расчета отношения сигнал/шум, требуемого для обеспечения заданной вероятности битовой ошибки для выбранного вида (когерентный/некогерентный прием) и типа модуляции/демодуляции. В пояснительной записке потребуется полный энергетический расчет для BPSK, 2-FSK и QPSK. Сделайте сравнительный анализ и последующий выбор.
1.8.4 - здесь уместно как раз привести предполагаемую структуру пакетов физ. уровня и отразить применимость канального кодера к определенным полям пакетов физ. уровня. Без перемежения в подвижной радиосвязи делать нечего.
1.8.6 - медленно-медленно разгибаем пальцы и начинаем думать. Рисунок выполнен с ошибкой, он не соответствует сделанному ранее описанию работы системы и отражает примитивный взгляд на прием/передачу битов поля DATA. Как передается другая информация, где собираются пакеты физ. уровня? Передатчик - имеется в виду ТС, приемник - ПС? Из ничего появляется перемежение/деперемежение...
1.8.7 - не выполнен
1.8.8 - плюсовать не надо, достаточно отразить на рисунке и пояснить в тексте. Пояснить, что такое "параметры частоты и параметры синхронизации"

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

Замечания к сообщению Сергея Андреева

Сообщение tor_root » 29 ноя 2011, 07:58

Обсуждаемое сообщение
Имеются следующие замечания.
1. п.1.7.2 - не забывайте о модели системы - требуется обоснованное указание того, на каком уровне модели фиксируется проблема, на каком и кем (какой службой) принимается решение.
2. п.1.7.3 - есть ответ на Ваш вопрос. Обратите внимание, что надо провести обоснованный анализ всех каналов связи о применении к ним мер по защите данных. Этот пункт вполне может быть объединен с п.1.7.4
3. п.1.7.5 - не содержит информации, относящейся к Вашей системе. Более того, он противоречит изложенным в предыдущих сообщениях Вашим идеям.
4. п.1.7.6 - требуется обоснование размеров полей пакета. Нелишним будет несколько более подробное описание назначение полей пакетов. И еще, учтите, что CRC - это Cyclic redundancy check
5. п.1.7.7 - есть проблема, связанная с п.1.7.5 - никак не представлена организация доступа к физическому каналу связи (ранее было заявлено о применении технологии ALOHA? и магического TDMA при решении проблема доступа терминалов к ресурсам сети).

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

Замечания к сообщению Кристины Маркиной

Сообщение tor_root » 29 ноя 2011, 08:45

обсуждаемое сообщение
Замечания следующие.
1. Требуется разделить это сообщение на части с выделением разделов и подразделов - на Ваше усмотрение. Так существенно легче читать.
2. Эффективным средством уменьшения влияния многолучевости в условиях медленных замираний является перемежение с избыточным кодированием. Дополнительно надо учесть фактический интервал актуальности коэффициентов фильтра-эквалайзера, т.е. требуется оценка периодичности его настройки. Может оказаться, что его надо будет настраивать один раз за кадр или еще реже. С этим также связано определение глубины перемежения.
3. Пропускная способность ЛК - это фактически скорость передачи сообщений (битов) в единицу времени. Для Вашей темы работы вполне уместно именно здесь задать скорость передачи битов на физ. уровне и, учитывая примерную оценку избыточности пакетов физ. и канального уровня, рассчитать пропускную способность ЛК. В принципе, эту задачу лучше выполнить после того, как будут определены точные размеры полей пакетов физ. и канального уровней.
4. В условиях Вашей работы, по всей видимости, лучше подходит блоковый кодер, который кодирует весь сформированное на МАС-уровне сообщение с данными. Если выбирается сверточный код, то надо предусматривать периодический "сброс" кодера (вставка определенного количества нулевых битов) и, если скорость кодирования отлична от 1/2, то требуется пояснение и отражение на схеме физ. уровня прореживания битов. Кроме того, необходимо провести обоснованный анализ всех каналов связи о применении к ним мер по защите данных.
5. Расчет затухания в КС неверен - этот расчет необходимо всегда проверять выражением LOS (свободное пространство). Меньше LOS затухание не может быть получено.
6. В энергетическом расчете необходимо учесть выигрыш от избыточного кодирования, собственные шумы приемника и энергетический запас - см. материал прошлого семестра.
7. По РИ и структуре пакетов физ. уровня - требуются иллюстрации с указанием размеров полей и временными интервалами.

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

Замечания к сообщению Кристины Маркиной

Сообщение tor_root » 30 ноя 2011, 08:30

Обсуждаемое сообщение
Имеются ошибки:
1. пропускная способность ЛКС не может быть выше скорости передачи битов физ. уровня, т.к. к сообщению L2 добавляется изрядная доля служебной информации, избыточности, которые отбирают на себя часть пропускной способности phy
2. Энергетический расчет с калькулятором не проверял, но на вскидку - есть ошибка: 16-PSK существенно энергетически более затратная, чем QPSK. И еще: учтите, что в используемых Вами расчетных соотношениях применяется Pc/Pш, однако Вы в них подставляете Eb/No, значение которого совпадает с Pc/Pш только для BPSK: Eb/No=Pc/Pш*1/k, где k=log2(M)=1.
3. Выбор кода (7,2) не понятен. Размерность инф. части кодового слова должна выбираться исходя из размера кодируемого поля данных (по тексту - 500 бит), т.е. один пакет физ. уровня - одно кодовое слово БЧХ. Выбор кода в Вашем случае может быть выполнен с помощью команд matlab: bchnumerr(511) или bchnumerr(1023), результат выполнения - 3 столбца: 1. размер кодового слова 2. кодируемое слово 3. количество исправл. ошибок.

Рекомендации:
1. В matlab есть замечательное средство - bertool (запускается в Command Window), которая строит зависимости BER от ОСШ для практически всех видов модуляции и для случая использования некоторых помехоустойчивых кодов. Для Вашего случая можно использовать код General с заданными параметрами (bchnumerr). Единственное ограничение - размер кодового блока не должен превосходить 511. Может скорректировать оценку размера поля данных до 400-430? Тогда вполне приличный результат может быть получен для кода 511.
2. В п.1.9. целесообразно добавить размерности полей.
3. Нумерация в пояснительной записке необязательно должна совпадать с нумерацией пунктов задания. Думаю, что лучше будет укрупнить разделы с указанием наиболее подходящего названия.

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

Замечания к сообщению Сергея Андреева

Сообщение tor_root » 02 дек 2011, 13:06

Обсуждаемое сообщение
Сергей!
1. В формуле PПД= PПМ+LС+GT+GR имеется ошибка: GT+GR должны уменьшать требуемую мощность излучения. Здесь речь должна идти о закладываемом энергетическом запасе.
2. PПМ= PШ, дБ+ Nш+PC/ PШ*1/log2(M)+ 10*log(Rb/ ПШ) - Nш уже учтен в PШ; PC/ PШ*1/log2(M) - во первых, это глупость, во вторых - разы нельзя перемешивать с дБ, замечу дополнительно вклад log2(M) учтен в 10*log(Rb/ ПШ). Вывод: Вам надо разобраться с тем, что и как Вы используете!
3. Там, где используется логарифмическая единица мощности, во избежание путаницы требуется применять размерность дБВт
4. п.1.8.7 - смысл приведенной фразы не понятен: вопрос не раскрыт.
5. п.1.8.8 - добавить временные интервалы
6. Вычислить информационную скорость передачи данных (поле Data) физ. уровня. На основании этой скорости вычислить точную пропускную способность ЛКС второго уровня.
7. перемежение - отсутствуют параметры, предполагаемая схема перемежения.
8. Эквалайзер: вычислить фактический интервал настройки эквалайзера, сравнить его с теоретической оценкой (на основе интервала корреляции свойств КС с замираниями), сделать выводы. Вопрос: на основании чего настраивается фильтр? На рис. 7 ничего подходящего для его настройки не увидел.
9. Было бы очень интересно познакомиться в Вашим видением реализации режима конкурентного доступа на физ. уровне. Как должны измениться структурная схема, ее описание? Другие режимы найдут на физ уровне свое особенное отражение?
10. Что за блоки битов используются в полях FCCH и FlagSync? В обратном направлении передаются пакеты той-же структуры? ТД подстраивается под генератор терминала, а терминал - под генератор ТД? Может основным источником синхронизации выбрать одну из сторон соединения? На что будет использован в обратном направлении ресурс Data?
11. Вас не смущает то обстоятельство, что размер пакета физ. уровня (и 2 поля пакета) не кратны 3? Не возникнет проблем при применении 8-psk?
12. В список литературы добавить ссылки на Ваши предшествующие статьи.

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

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

Замечания к сообщению Ильи Минаева

Сообщение tor_root » 02 дек 2011, 14:30

Обсуждаемое сообщение
1. Поскольку первая часть статьи недоработана, то в последующий статьях наблюдается "каша" при попытках отразить взаимодействие сетевых объектов. Как следует из текста, Вы применяете 3-х звеньевую структуру сети. От Вас требуется четкое пояснение этой структуры, задач каждого звена и привязки к нем всех имеющихся пояснений и расчетов.
2. "Этот ID хранится в базе данных ТС" - БД быть не должно, необходимо использовать наименование целевой структуры информационной подсистемы
3. "Пропускную способность канала трафика рассчитаем для случая максимальной передачи данных, т. е. от ТС к ПС. Размер такого пакета- примерно 350 бит. Размер пакета на физ уровне – 600 бит. Пропускная способность канала трафика- 30 кбит/с." - это совсем другой радиоинтерфейс и иной протокол взаимодействия. Похоже, что Вы пытаетесь объединить эти интерфейсы. Это, безусловно, возможно - дело за детальным описанием подобного объединения.
4. Познакомьтесь со статьей Андреева Сергея - несмотря на ошибки, его сообщение не производит впечатление неряшливой работы. Замечания, представленные в рецензии на его сообщение, отчасти относятся и к Вашей работе.
5. п.10 предыдущей рецензии
6. п.1.7.7 - может возникнуть проблема скрытой станции? Ее решение на уровне описываемого сценария.
7. "Сигналы линии «вниз» не учувствуют в конкурентном доступе." Что это за сигналы? Сообщения от ТД?
8. Прикрепить к статье схему эквалайзера с обратной связью по решению недостаточно - требуется дополнительное пояснение компонент схемы и выделения новых задач физического уровня (обновление коэф. фильтров)
9. Относительно процедуры энергетического расчета - пример выполнения;
Pпрм=Pш+ Nk+Eb/N0 - имеется ошибка
10. п.1.8.6: как и в предыдущей рецензии - схема не отражает полноты задач физ. уровня и выполнена с ошибкой: не все задачи приема и передачи выполняются последовательно. Не отражено построение/использование пакетов физ. уровня, отсутствуют задачи, выполняемые приемником в режиме конкурентной борьбы.
Неясно, почему система работает без тактового генератора и без генератора радиосигнала. Поскольку оборудование системы должно быть настраиваемым (хотя бы на разные частоты в пределах диапазона), то это должно найти свое отражение на структурной схеме.
11. п.1.8.7 - привести предполагаемые битовые блоки, соответствующие этим полям.
12. "Размеры всех полей пакетов в п 1.7.4." - пропущено сказуемое. Это все равно не освобождает Вас от необходимости доработки рисунков, рис. 9 - аналогично. 1.7.4 необходимо использовать обозначения полей, как, впрочем, и по всему тексту.
13. физ ур, и тп, см, прм, прд - подобных сокращений быть не должно. Формула - часть предложения - если на формуле предложение заканчивается, то ставится точка.


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

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

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