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

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

Севостьянову Михаилу

Сообщение tor_root » 28 ноя 2014, 15:46

Замечания к сообщению Тема 2. Доставка сообщений в структурированной радиосети. Часть 2

1. материал п.1.2.4 противоречит идее, изложенной в п.1.2.2. Кроме того, представленный материал в п.1.2.4 в целом не соответствует заданию: "на основании каких событий формируются служебные сообщения, конечное назначение сообщений. Обоснование широковещательных параметров сети" - не надо пояснять по каким ЛК передаются сообщения. Перечень служебных сообщений должен следовать исключительно из п.1.2.2, необходимо также пояснять какая служба подготавливает сообщение, на основании какого события (потребности) и для каких действий на стороне-адресата (цель доставки служебного сообщения, исполнитель команды). Надо четко постараться пояснить - каждое конкретное служебное сообщение - это команда или ответ на ранее переданную команду/запрос. Как-то так. Дополнительно требуется пояснить состав данных, передаваемых по BCCH - исключительно основанный на домыслах п.1.2.2.
Как пример, структура одного из видов сообщений ВССН GSM:

Сообщение Bbis в шестнадцатеричной форме (23 байта)
49 06 1b 89 1e 52 f0 20 18 43 c8 02 50 54 65 04 9c 00 00 1c 13 2b 2b
Расшифровка (определенные биты каждого байта отвечают за какую-либо информацию):
0: 49 010010-- Pseudo Length: 18
1: 06 0------- Direction: From originating site
1: 06 -000---- 0 TransactionID
1: 06 ----0110 Radio Resouce Management
2: 1b 00011011 RRsystemInfo3C
3: 89 35102 [0x891e] Cell identity
5: 52 250 Mobile Country Code (Russian Federation)
6: f0 02f Mobile Network Code (Megafon)
8: 18 6211 [0x1843] Local Area Code
10: c8 1------- Spare bit (should be 0)
10: c8 -1------ MSs in the cell shall apply IMSI attach/detach procedure
10: c8 --001--- Number of blocks: 1
10: c8 -----000 1 basic physical channel for CCCH, not combined with SDCCHs
11: 02 00000--- spare bits (should be 0)
11: 02 -----010 4 multi frames period for paging request
12: 50 01010000 T3212 TimeOut value: 80
13: 54 0------- spare bit (should be 0)
13: 54 -1------ Power control indicator is set
13: 54 --01---- MSs shall use uplink DTX
13: 54 ----0100 Radio Link Timeout: 20
14: 65 011----- Cell Reselect Hyst. : 6 db RXLEV
14: 65 ---xxxxx Max Tx power level: 5
15: 04 0------- No additional cells in SysInfo 7-8
15: 04 -0------ New establishm cause: not supported
15: 04 --xxxxxx RXLEV Access Min permitted = -110 + 4dB
16: 9c 10------ Max. of retransmiss : 4
16: 9c --0111-- slots to spread TX : 10
16: 9c ------0- The cell is barred : no
16: 9c -------0 Call reestabl.i.cell: allowed
17: 00 -----0-- Emergency call EC 10: allowed
17: 00 00000--- Acc ctrl cl 11-15: 0 = permitted, 1 = forbidden
17: 00 ------00 Acc ctrl cl 8- 9: 0 = permitted, 1 = forbidden
17: 00 -------0 Ordinary subscribers (8)
17: 00 ------0- Ordinary subscribers (9)
17: 00 -----0-- Emergency call (10): Everyone
17: 00 ----0--- Operator Specific (11)
17: 00 ---0---- Security service (12)
17: 00 --0----- Public service (13)
17: 00 -0------ Emergency service (14)
17: 00 0------- Network Operator (15)
18: 00 00000000 Acc ctrl cl 0- 7: 0 = permitted, 1 = forbidden
18: 00 00000000 Ordinary subscribers (0-7)
19: 1c YYYYYYYY REST OCTETS (2)

2. п.1.2.5 не выполнен, т.к. в нем изложено какое-то умозрительное отражение Вашего понимания задания, слабо связанное с п.1.2.2. Для выполнения задачи радиоизмерений требуется наличие события, инициирующего процесс измерений, модуль-исполнитель, который который собственно проводит какие-то измерения (?) в строго отведенные для измерений время (? в сценарии п.1.2.2), кто является получателем данных измерения и как эти данные (в составе какого сообщения) будут переданы той службе, которой эти сведения нужны. И последнее - какие события могут развиваться на основании анализа данных? Это д.б. своеобразный сценарий, запускаемый периодически (?) или эпизодически (?) и который имеет точку входа и несколько точек выхода.
"терминал слишком удалился от ТД или сигнал стал слабый. В этом случае ТД должна отправить терминалу уведомление о том, что необходимо повысить мощность или приблизится к ТД. В противном случае сигнал может быть потерян." - это не практический пример способа контроля. Это изложение примитивной декларации о намерениях.
3. п.1.2.6 совершенно не понятный. В п.1.2.2 нет подробного описания метода множественного доступа, как на него можно ссылаться? Переход от рис. 2.5 на основании фразы "В рамках задания структура пакетов канального уровня будет выглядеть следующим образом" вызывает по крайней мере недоумение. Кроме того, задание подразумевает оценку размерности полей сообщений. И, в общем-то, давно назрела иллюстрация уровней модели, отражающей Ваши идеи и движения различных сообщений.
4. п.1.2.7. - отсталый во всех смыслах. И, более того, совершенно неверный. Ни одной задачи из сформулированных: "Обоснование и подробное описание задач, выполняемых на физическом уровне. Проработка вопросов, связанных с обеспечением синхронизации сетевых устройств на физическом уровне" не было решено. Вместо этого детская преамбула и не менее взрослая структура пакетов физ. уровня.

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

Соколову Николаю

Сообщение tor_root » 28 ноя 2014, 16:36

замечания к сообщению: Передача данных с уведомлением о доставке" Часть 1 (исправление 4)

1. Основной вопрос: зачем CSMA при радиомостовом соединении вида "мастер-помощник"??? Канал связи находится под управлением мастера, с кем ему еще конкурировать?
2. Как в рамках описанного сценария сможет передавать сообщения Т2? Не понятно. Похоже, что никак.

В остальном отмечаю наличие прогресса.
Удачи.


Вернуться в «Стандарты и технологии подвижной связи»

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

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