Ответы на вопросы
Добавлено: 07 янв 2020, 22:17
Никита, здравствуйте.
1. "3.5. Проработать сценарий гарантированной доставки сообщений одного из ключевых ЛКС в виде повторной передачи неверно принятого сообщения (ARQ)" - пространных пояснений сделано более чем достаточно. Здесь требуется отразить пример практической реализации сценария - как протокола обмена сетевыми сообщениями: происходит прием сообщения данных/сигнализации, выявляется его ошибочность (?) и далее что? От общих слов к конкретной ситуации - формат сигнальных сообщений ARQ, начало/окончание сессии ARQ, предотвращение зацикливания процесса ARQ и.т.п.
2.2) реализация ARQ не поддерживается предложенным форматом сообщений DCH - это замечание на очередную пространную фразу "Если при передаче сообщений некоторый пакет был принят с ошибками, то в службу ARQ поступит номер данного сообщения" - согласно Вашему описанию сообщения канала DCH не нумеруются (нумеруются только блоки сообщения при фрагментации- но это совсем другое), поэтому формально в службу ARQ передавать будет нечего. Кроме того, указанная выше фраза не соответствует концепту п.3.7. Была бы выполнена практическая проработка сценария ARQ - подобного наверняка не возникло.
3. "Также возник вопрос о формате сообщений L3 уровня. " - да, хотя бы пример, иллюстрирующий структуру любого сообщения единственной службы. В данном случае предоставляется хорошая возможность проиллюстрировать практическое использование введенных ранее ID (п.2.3).
4. Безусловно да. Возможны разные варианты, в том числе и предложенный Вами. Замечание п.7 не подвергает сомнению Ваше решение, оно указывает на необходимость четкого пояснения того, как сигнальные данные переменной длины будут передаваться при помощи поля фиксированной длины, т.е. как службы "отсекут" неизбежные незначащие биты заполнения?
1. "3.5. Проработать сценарий гарантированной доставки сообщений одного из ключевых ЛКС в виде повторной передачи неверно принятого сообщения (ARQ)" - пространных пояснений сделано более чем достаточно. Здесь требуется отразить пример практической реализации сценария - как протокола обмена сетевыми сообщениями: происходит прием сообщения данных/сигнализации, выявляется его ошибочность (?) и далее что? От общих слов к конкретной ситуации - формат сигнальных сообщений ARQ, начало/окончание сессии ARQ, предотвращение зацикливания процесса ARQ и.т.п.
2.2) реализация ARQ не поддерживается предложенным форматом сообщений DCH - это замечание на очередную пространную фразу "Если при передаче сообщений некоторый пакет был принят с ошибками, то в службу ARQ поступит номер данного сообщения" - согласно Вашему описанию сообщения канала DCH не нумеруются (нумеруются только блоки сообщения при фрагментации- но это совсем другое), поэтому формально в службу ARQ передавать будет нечего. Кроме того, указанная выше фраза не соответствует концепту п.3.7. Была бы выполнена практическая проработка сценария ARQ - подобного наверняка не возникло.
3. "Также возник вопрос о формате сообщений L3 уровня. " - да, хотя бы пример, иллюстрирующий структуру любого сообщения единственной службы. В данном случае предоставляется хорошая возможность проиллюстрировать практическое использование введенных ранее ID (п.2.3).
4. Безусловно да. Возможны разные варианты, в том числе и предложенный Вами. Замечание п.7 не подвергает сомнению Ваше решение, оно указывает на необходимость четкого пояснения того, как сигнальные данные переменной длины будут передаваться при помощи поля фиксированной длины, т.е. как службы "отсекут" неизбежные незначащие биты заполнения?