Основные ссылки

На правах рекламы:

Произвольная ссылка:

Описание

Источник публикации

М.: ФГБУ "Институт стандартизации", 2025

Примечание к документу

Документ введен в действие с 01.02.2025.

Название документа

"ГОСТ Р 71586.3-2024. Национальный стандарт Российской Федерации. Цифровая профессиональная подвижная радиосвязь. Транкинговый режим связи абонентских станций"

(утв. и введен в действие Приказом Росстандарта от 19.12.2024 N 1943-ст)

"ГОСТ Р 71586.3-2024. Национальный стандарт Российской Федерации. Цифровая профессиональная подвижная радиосвязь. Транкинговый режим связи абонентских станций"
(утв. и введен в действие Приказом Росстандарта от 19.12.2024 N 1943-ст)

Оглавление

ГОСТ Р 71586.3-2024. Национальный стандарт Российской Федерации. Цифровая профессиональная подвижная радиосвязь. Транкинговый режим связи абонентских станций

3 Термины и определения

4 Сокращения

5 Общее описание возможностей оборудования цифровой профессиональной подвижной радиосвязи в транкинговом режиме

5.1 Транкинговая сеть ППР. Общие положения

5.2 Услуги и функциональные возможности оборудования транкинговой сети

5.3 Типы каналов транкинговой станции

5.4 Рабочие каналы

5.5 TSCC

5.6 Кадровая синхронизация

5.7 CACH

5.8 Передача речевых сообщений

5.9 План распределения частот канала

5.10 Архитектура сети

5.11 Режимы транкинговой передачи. Общие положения

6 Требования к архитектуре протокола

6.1 Архитектура протокола

6.2 Радиоинтерфейс физического уровня (уровень 1)

6.3 Радиоинтерфейс канального уровня (уровень 2)

6.4 Радиоинтерфейс уровня управления вызовами (уровень 3)

6.5 Общая классификация каналов транкинговой станции

6.6 Структура рабочих каналов передачи информации с множественным доступом с временным разделением каналов TDMA

6.7 Кадровая синхронизация в рабочих каналах транкинговой станции

6.8 Источники синхронизации и канал передачи пользовательских данных транкинговых станций

6.9 TSCC и CACH

7 Процедуры транкинговой передачи

7.1 Базовая структура

7.2 Процедуры произвольного доступа

7.3 Получение и удержание TSCC

7.4 Регистрация, энергосбережение и процедуры аутентификации

7.5 Процедуры осуществления вызова

7.6 Процедуры управления системой

8 Передача коротких данных с использованием UDT

8.1 Общие положения

8.2 Передача коротких данных с помощью механизма UDT по TSCC

8.3 Процедуры выполнения услуги передачи коротких данных с помощью механизма UDT для АС

8.4 Инициирование услуги "Передача коротких данных"

8.5 Ответ на услугу "Передача коротких данных" вызовом произвольного доступа

8.6 Подтверждения, полученные вызывающей АС при оказании ей услуги "Передача коротких данных"

8.7 Тайм-аут в ожидании дальнейшей сигнализации

8.8 Процедуры для АС, принимающей короткие данные через UDT

8.9 MSC выполнения процедуры "Короткое информационное сообщение"

9 Услуга передачи пакетных данных

9.1 Процедуры соединения с пакетной передачей данных. Общие положения

9.2 Процедуры соединения с пакетной передачей данных для TSCC

9.3 Процедуры вызова с передачей пакетных данных для АС

9.4 Процедуры для рабочего канала при предоставлении услуги "Передача пакетных данных"

9.5 Передача прикладных данных службой передачи данных по протоколу IP

10 Требования к формату пакета стека протоколов уровня 2 в транкинговом режиме

10.1 Сокет вокодера

10.2 Особенности применения CACH

10.3 Обратный канал

11 Требования к сигнализации в транкинговом режиме в рабочих каналах

11.1 Типы и структура сообщений LC в транкинговом режиме в рабочих каналах

11.2 Структура сообщения для передачи шифрованных данных (PI DT PDU) в рабочих каналах

11.3 Структура CSBK

11.4 Структура MBC

12 Функциональные возможности

12.1 Ограничение времени передачи

12.2 Сервис FNS

13 Требования к общим услугам в транкинговом режиме

13.1 Услуги и функциональные возможности

13.2 Адреса устройств

13.3 Обычные/транкинговые системы

13.4 Возможности регистрации АС

13.5 Услуги транкинговой сети

13.6 Организация физического канала связи

13.7 TDMA-пакет и структура канала

13.8 Структура ТС

14 Требования к протоколу PDP

14.1 Протокол PDP - общие положения

14.2 Формат AD

15 Требования к блоку данных протокола канального уровня (уровень 2) в транкинговом режиме

15.1 Описание PDU DLL - общие положения

15.2 PDU для речевого пакета, общий пакет данных в транкинговом режиме

15.3 Описание данных, связанных с PDU

15.4 Кодирование IE уровня 2

16 Описание блоков управления уровня управления вызовами стека протоколов (уровень 3)

16.1 Описание PDU CCL в транкинговом режиме - общие положения

16.2 Типы PDU CCL (уровень 3) стека протоколов, их назначение и структура

16.3 Кодовые обозначения в IE уровня управления вызовами (уровень 3) стека протоколов в транкинговом режиме

17 Требования к физическому уровню стека протоколов (уровень 1)

17.1 Отклонение частоты передатчика транкинговой станции от номинального значения

17.2 Временные параметры таймслотов в режиме с ретрансляцией в восходящем канале

18 Требования к встроенной диагностике транкинговой станции

Приложение А. Функции индикации времени, постоянные уровни и адреса

Приложение Б. Справочный список операционных кодов

Приложение В. План физического канала

Приложение Г. Процедуры поиска TSCC

Приложение Д. Использование схем MSC и SDL

Библиография

Утвержден и введен в действие

Приказом Федерального агентства

по техническому регулированию

и метрологии

от 19 декабря 2024 г. N 1943-ст

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ЦИФРОВАЯ ПРОФЕССИОНАЛЬНАЯ ПОДВИЖНАЯ РАДИОСВЯЗЬ

ТРАНКИНГОВЫЙ РЕЖИМ СВЯЗИ АБОНЕНТСКИХ СТАНЦИЙ

Digital professional mobile radio communication. Trunking

mode of communication of subscriber stations

(ETSI TR 102 398 V1.4.1:2018, NEQ)

(ETSI TS 102 361-1 V2.5.1:2017, NEQ)

(ETSI TS 102 361-2 V2.4.1:2017, NEQ)

(ETSI TS 102 361-3 V1.3.1:2017, NEQ)

(ETSI TS 102 361-4 V1.11.1:2021, NEQ)

ГОСТ Р 71586.3-2024

ОКС 33.070.99

Дата введения

1 февраля 2025 года

Предисловие

1 РАЗРАБОТАН Федеральным государственным бюджетным учреждением "Ордена Трудового Красного Знамени Российский научно-исследовательский институт радио имени М.И. Кривошеева" (ФГБУ НИИР)

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 480 "Связь"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 19 декабря 2024 г. N 1943-ст

4 В настоящем стандарте учтены основные нормативные положения следующих документов Европейского института по стандартизации в области телекоммуникаций (ETSI):

- ETSI TR 102 398 V1.4.1:2018 "Электромагнитная совместимость и вопросы радиочастотного спектра (ERM). Цифровая мобильная радиосвязь (DMR). Общий дизайн системы" [ETSI TR 102 398 V1.4.1:2018 "Electromagnetic compatibility and Radio spectrum Matters (ERM). Digital Mobile Radio (DMR). General System Design", NEQ];

- ETSI TS 102 361-1 V2.5.1:2017 "Электромагнитная совместимость и вопросы радиочастотного спектра (ERM). Системы цифровой мобильной радиосвязи (DMR). Часть 1. Протокол радиоинтерфейса (AI) DMR" [ETSI TS 102 361-1 V2.5.1:2017 "Electromagnetic compatibility and Radio spectrum Matters (ERM). Digital Mobile Radio (DMR) Systems. Part 1: DMR Air Interface (AI) protocol", NEQ];

- ETSI TS 102 361-2 V2.4.1:2017 "Электромагнитная совместимость и вопросы радиочастотного спектра (ERM). Системы цифровой мобильной радиосвязи (DMR). Часть 2. Голосовые и общие услуги и средства DMR" [ETSI TS 102 361-2 V2.4.1:2017 "Electromagnetic compatibility and Radio spectrum Matters (ERM). Digital Mobile Radio (DMR) Systems. Part 2: DMR voice and generic services and facilities", NEQ];

- ETSI TS 102 361-3 V1.3.1:2017 "Электромагнитная совместимость и вопросы радиочастотного спектра (ERM). Системы цифровой мобильной радиосвязи (DMR). Часть 3. Протокол данных DMR" [ETSI TS 102 361-3 V1.3.1:2017 "Electromagnetic compatibility and Radio spectrum Matters (ERM). Digital Mobile Radio (DMR) Systems. Part 3: DMR data protocol", NEQ];

- ETSI TS 102 361-4 V1.11.1:2021 "Электромагнитная совместимость и вопросы радиочастотного спектра (ERM). Системы цифровой мобильной радиосвязи (DMR). Часть 4. Транкинговый протокол DMR" [ETSI TS 102 361-4 V1.11.1:2021 "Electromagnetic compatibility and Radio spectrum Matters (ERM). Digital Mobile Radio (DMR) Systems. Part 4: DMR trunking protocol", NEQ]

5 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

Введение

Комплекс национальных стандартов на цифровую профессиональную подвижную радиосвязь разработан в связи с необходимостью соблюдения национальных интересов Российской Федерации в области профессиональной подвижной радиосвязи и обеспечения производства унифицированного российского оборудования профессиональной подвижной радиосвязи.

При разработке комплекса национальных стандартов на цифровую профессиональную подвижную радиосвязь учтены требования, выдвинутые федеральными органами исполнительной власти Российской Федерации и ведущими российскими организациями, использующими сети профессиональной подвижной радиосвязи.

В комплекс национальных стандартов на цифровую профессиональную подвижную радиосвязь входят:

- ГОСТ Р 71586.1-2024 "Цифровая профессиональная подвижная радиосвязь. Общие положения. Режим прямой конвенциональной связи абонентских станций";

- ГОСТ Р 71586.2-2024 "Цифровая профессиональная подвижная радиосвязь. Режим связи абонентских станций через ретранслятор";

- ГОСТ Р 71586.3-2024 "Цифровая профессиональная подвижная радиосвязь. Транкинговый режим связи абонентских станций".

Комплекс национальных стандартов на цифровую профессиональную подвижную радиосвязь может быть дополнен другими стандартами по мере их разработки и утверждения установленным порядком.

1 Область применения

Настоящий стандарт распространяется на радиооборудование цифровой профессиональной подвижной радиосвязи (абонентские станции, ретрансляторы и транкинговые станции), работающее в радиочастотных диапазонах, выделенных для подвижной службы радиосвязи в соответствии с решениями Государственной комиссии по радиочастотам.

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

ГОСТ 34.12 Информационная технология. Криптографическая защита информации. Блочные шифры

ГОСТ 15150 Машины, приборы и другие технические изделия. Исполнения для различных климатических районов. Категории, условия эксплуатации, хранения и транспортирования в части воздействия климатических факторов внешней среды

ГОСТ 31610.10-1 (IEC 60079-10-1:2020) Взрывоопасные среды. Часть 10-1. Классификация зон. Взрывоопасные газовые среды

ГОСТ 31610.15 (IEC 60079-15:2017) Взрывоопасные среды. Часть 15. Оборудование с видом взрывозащиты "n"

ГОСТ Р 34.12 Информационная технология. Криптографическая защита информации. Блочные шифры

ГОСТ Р 53801 Связь федеральная. Термины и определения

ГОСТ Р 55897 Сети подвижной радиосвязи. Зоны обслуживания. Методы расчета

ГОСТ Р 56153-2014 Аналоговые радиостанции. Основные параметры. Технические требования

ГОСТ Р 56172 Радиостанции и ретрансляторы стандарта DMR. Основные параметры. Технические требования

ГОСТ Р 71586.1-2024 Цифровая профессиональная подвижная радиосвязь. Общие положения. Режим прямой конвенциональной связи абонентских станций

ГОСТ Р 71586.2-2024 Цифровая профессиональная подвижная радиосвязь. Режим связи абонентских станций через ретранслятор

ГОСТ Р ИСО/МЭК 18384-1 Информационные технологии. Эталонная архитектура для сервис-ориентированной архитектуры (SOA RA). Часть 1. Терминология и концепции SOA

Примечание - При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю "Национальные стандарты", который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя "Национальные стандарты" за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.

3 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

3.1 абонентская станция [радиостанция]: Пользовательское оборудование, подключаемое к сети подвижной связи.

Примечания

1 Абонентские станции [радиостанции] могут быть портативными, носимыми, возимыми или стационарными.

2 Под абонентом в настоящем комплексе стандартов понимается не только абонент, с которым заключен договор об оказании услуг связи, но и пользователь сетей связи, предназначенных для обеспечения деятельности предприятий и организаций.

3.2 активный канал: Канал связи, по которому в данное время осуществляется прием/передача информации.

3.3 асинхронный режим: Режим работы, при котором работа приемного оборудования не синхронизирована по времени с работой передающего оборудования.

3.4 блок: Последовательность битов информации, которая используется для представления данных и рассматривается как единое целое.

3.5 вокодер: Программное или аппаратное устройство, предназначенное для кодирования и декодирования оцифрованной речи.

Примечание - В результате кодирования по радиоэфиру передаются информационные биты, позволяющие после декодирования восстановить оцифрованную речь.

3.6 восходящий канал: Канал передачи информации от абонентской станции к ретранслятору (транкинговой станции) или к абонентской станции, работающей в качестве ретранслятора.

3.7 временные параметры таймслотов канала: Границы таймслотов 1 и 2.

3.8 время удержания канала: Временной интервал, в течение которого система резервирует канал связи для обеспечения передачи ответного пакета.

3.9 дуплексная радиосвязь; дуплекс: Двусторонняя радиосвязь, при которой передача и прием информации осуществляются одновременно по разным каналам.

3.10 идентификация: Процедура, в результате выполнения которой выявляется определяющий признак (идентификатор), однозначно указывающий на субъект идентификации.

3.11 информационный элемент: Минимальная структурная единица информации в блоке данных протокола.

3.12 кадр: Два последовательных таймслота, обозначенных как таймслот 1 и таймслот 2 и составляющих временной интервал 60 мс.

3.13 кадр вокодера: Преобразованный в цифровую форму блок речевого сообщения длительностью 7,5 мс, закодированный кодом Голея.

3.14 канал управления транкинговой станции: Логический канал в частотном канале транкинговой станции, предназначенный для управления сетью абонентских станций.

3.15 ключ: Изменяемый параметр в виде последовательности символов, определяющий криптографическое преобразование.

3.16 коды Голея, Хэмминга, Рида-Соломона, решетчатый код: Виды помехоустойчивого кодирования, используемые для повышения качества радиосвязи.

3.17 конвенциональный режим: Режим связи, при котором любая абонентская станция может осуществлять прямую связь с другими абонентскими станциями с фиксированным закреплением каналов связи (без использования протокола автоматического перераспределения каналов связи).

3.18 контроллер транкинговой станции: Компонент оборудования транкинговой станции, который управляет ее работой, а также обеспечивает выход во внешнюю телефонную сеть путем маршрутизации соответствующего трафика через шлюз сети связи общего пользования, подключение к сети передачи данных, линиям управления и мониторинга, линиям связи между транкинговыми станциями и т.д.

3.19 логический канал: Канал передачи данных между логическими конечными точками (двумя или более устройствами).

Примечание - Логический канал может состоять из подканалов, например, кадровой синхронизации, встроенной сигнализации и т.д.

3.20 нисходящий канал: Канал передачи информации от ретранслятора (транкинговой станции) или абонентской станции, работающей в качестве ретранслятора, к абонентской станции.

3.21 обратный канал: Логический канал, по которому осуществляется передача данных в направлении от получателя к отправителю.

3.22 пакет; слот: Элементарное количество битов в физическом канале.

3.23 пакетные данные: Пользовательские данные, содержащиеся в пакете, без учета заголовков и битов синхронизации (сигнализации).

3.24 перемежение: Процесс перестановки по установленному правилу элементов или группы элементов относительно друг друга на некотором интервале.

3.25 перемежитель компонентных кодов: Программное или аппаратное устройство, реализующее процесс перемежения элементов кодовых слов каскадного кода.

3.26 поле: Часть данных, имеющая функционально самостоятельное значение и рассматриваемая как отдельный элемент.

3.27 полезная нагрузка: Часть передаваемых данных, которая является информацией, предназначенной непосредственно абоненту.

3.28 прерыватель: Информационный элемент блока данных, предназначенный для прерывания (остановки) какого-либо процесса (например, передачи речевого вызова <1>).

--------------------------------

ИС NORMPROD: примечание.

В официальном тексте документа, видимо, допущена опечатка: стандарт имеет номер ГОСТ Р 53801, а не ГОСТ 53801.

<1> Определение к термину "вызов" установлено в ГОСТ 53801.

3.29 прямой режим: Режим непосредственной радиосвязи абонентской станции с другими абонентскими станциями без участия дополнительного (промежуточного) оборудования (например, ретранслятора, абонентской станции в режиме ретранслятора, транкинговой станции).

3.30 режим двухчастотной ретрансляции: Режим, при котором ретранслятор принимает информацию на одной радиочастоте, а передает ее на другой радиочастоте.

3.31 режим одночастотной ретрансляции: Режим, при котором ретранслятор принимает и передает информацию на одной радиочастоте в разных таймслотах.

3.32 режим ретранслятора: Режим работы, при котором абонентские станции могут поддерживать связь через промежуточные устройства с функцией ретрансляции.

3.33 ретранслятор: Радиотехническое устройство, предназначенное для приема, преобразования, усиления, последующей передачи радиосигнала и (или) изменения направления его распространения.

Примечания

1 Ретранслятором может быть абонентская станция в режиме ретрансляции.

2 Ретранслятор может вводить управляющую информацию.

3.34 сайт: Совокупность транкинговой станции (ретранслятора), оборудования управления транкинговой системой (при наличии) и подмножества абонентских станций, вызовы которых обрабатываются данной транкинговой станцией (ретранслятором).

3.35 сервис переноса информации: Сервис по передаче информации между точками доступа.

3.36 сигнализация: Совокупность служебных данных, предназначенных для установления и контроля соединений, а также управления сетью.

3.37 симплексная радиосвязь; симплекс: Двусторонняя радиосвязь, при которой передача и прием на каждой абонентской станции (ретрансляторе, транкинговой станции) осуществляются поочередно.

Примечание - Симплексная радиосвязь может быть одночастотной и двухчастотной.

3.38 синхронизация: Процесс установления и поддержания синхронной и синфазной работы устройств при передаче и приеме информации по каналу связи.

3.39 сокет вокодера: Пакет полезной нагрузки вокодера размером 216 бит.

3.40 сообщение: Короткое текстовое сообщение, состоящее из букв или символов, набранных в определенной последовательности, предназначенное для передачи по сети профессиональной подвижной радиосвязи.

Примечание - В стандарте применяется в контексте пользовательской или управляющей информации.

3.41 специальный символ "wildcard": Подстановочный символ "*", который устанавливается вызывающим абонентом в адресе вызываемой группы абонентских станций и который указывает, что при этом будут вызваны все абонентские станции, в номерной позиции которых вместо символа "*" имеются цифры от 0 до 9.

3.42 суперкадр: Шесть последовательных пакетов речевой информации в логическом канале.

3.43 таймслот: Элементарный временной интервал в физическом канале.

Примечание - В данном комплексе стандартов таймслот имеет длительность 30 мс и может быть пронумерован "1" либо "2".

3.44 транкинговая связь: Режим работы, при котором обеспечивается автоматическое распределение каналов связи между абонентами сети.

Примечание - Все абоненты радиосети используют общую группу каналов, а выделение свободных каналов для абонентских станций осуществляется оборудованием управления транкинговой системой.

3.45 транкинговая станция: Средство электросвязи, которое размещается стационарно, на специализированном транспортном средстве или другом перемещаемом узле связи и обеспечивает в транкинговом режиме соединение по радиочастотным каналам множества абонентских станций, находящихся в зоне ее обслуживания <1>, с узлом коммутации сети беспроводной связи и (или) другими транкинговыми станциями.

--------------------------------

ИС NORMPROD: примечание.

В официальном тексте документа, видимо, допущена опечатка: стандарт имеет номер ГОСТ Р 55897, а не ГОСТ 55897.

<1> Определение к данному термину установлено в ГОСТ 55897.

3.46 унифицированная передача данных: Универсальная технология передачи информации, в которой реализовано управление потоком данных и контроль их целостности.

3.47 физический канал: Совокупность технических средств и среды распространения, которая обеспечивает передачу сигналов радиосвязи в нормированной полосе частот и (или) с нормированной скоростью передачи.

3.48 физический уровень радиоинтерфейса: Уровень взаимодействия между элементами радиосети, обеспечивающий побитовую транспортировку пакетов данных через физическую среду, соединяющую сетевые устройства. Определяет процедуры и функции, выполняемые оборудованием при передаче информации.

3.49 флаг: Один или несколько битов в блоке, используемые для определения его состояния.

3.50 цветовой код канала: Идентификатор, предназначенный для защиты от внутриканальных помех, создаваемых в результате возможного перекрытия зон обслуживания различных систем радиосвязи (или разных сайтов одной системы), использующих одни и те же физические радиоканалы.

3.51 цифровая профессиональная подвижная радиосвязь: Цифровая подвижная радиосвязь, организуемая по профессиональному признаку и предназначенная для обеспечения общественной безопасности, производственной деятельности организаций, управления технологическими процессами в производстве, проведения других мероприятий.

4 Сокращения

В настоящем стандарте применены следующие сокращения.

АС - абонентская станция;

ГЛОНАСС - глобальная навигационная спутниковая система;

КО - коммутационное оборудование;

ППР - профессиональная подвижная радиосвязь;

ПУ - пульт управления;

РЧ - радиочастота, радиочастотный;

СОРМ - система оперативно-розыскных мероприятий;

ТС - транкинговая станция;

ТФОП - телефонная сеть общего пользования;

ACK - подтверждение (ACKnowledgement);

ACKD - подтверждение получения данных в нисходящем канале (ACKnowledgement outbound);

ACKU - подтверждение получения данных в восходящем канале (ACKnowledgement inbound);

AD - добавленные данные (Appended Data);

AI - радиоинтерфейс (Air Interface);

ALLMSID - идентификатор для адресации всех абонентских станций в системе (ALL Mobile Station IDentifiers);

ALLMSIDL - идентификатор для адресации всех абонентских станций внутри одного сайта (ALL Mobile Station IDentifiers Local);

ALLMSIDZ - идентификатор для адресации всех абонентских станций внутри нескольких сайтов (ALL Mobile Station IDentifiers Zone);

ALS - услуга прослушивания окружения (Ambient Listening Service);

AT - тип доступа (Access Type);

AUTHI - идентификатор шлюза аутентификации (AUTHentication Identifier);

BC_AP - абсолютные параметры вещания (BroadCast_Absolute Parameters);

BCD - десятичное число, представленное в двоичном коде (Binary Code Decimal);

BER - коэффициент битовых ошибок (Bit Error Rate);

BMP - основная многоязычная плоскость (Basic Multilingual Plane);

CACH - общий канал передачи уведомлений (Common Announcement CHannel);

CC - цветовой код (Colour Code);

CCL - уровень управления вызовами (Call Control Layer);

CG - назначение канала (Channel Grant);

CG_AP - абсолютные параметры назначения канала (Channel Grant_Absolute Parameters);

CH - канал (CHannel);

CLI - информация о линии вызова (Caller Line Identity);

COG - направление относительно земли (Course Over Ground);

CRC - циклический избыточный код (Cyclic Redundancy Check);

CS - контрольная сумма (CheckSum);

CSBK - одноблочное сообщение управления (Control Signalling BlocK);

CSBKO - код операции одноблочного сообщения управления (CSBK Opcode);

DGNA - динамическое присвоение нумерации группам (Dynamic Group Numbering Assignment);

DGNAHD - автоматическое назначение нумерации группы в заголовке (Dynamic Group Numbering Assignment Header outbound);

DGNAI - адрес для идентификации динамического присвоения номера группы (Dynamic Group Number Assignment Identity);

DISCON - разъединение (DISCONnect);

DISPATDI - адрес диспетчера системы, использующей синхронизацию со смещением полезной нагрузки (address of the system dispatcher using payload offset timing);

DLL - канальный уровень (Data Link Layer);

DMR - цифровая подвижная радиосвязь (Digital Mobile Radio);

DMRLA - зона обслуживания цифровой подвижной радиосвязи (Digital Mobile Radio Location Area);

DOP - снижение точности (Dilution Of Precision);

DT - поле типа данных для общих пакетов данных (Data Type);

EDEG - градусы долготы (East longitude DEGrees);

EMB - встроенное поле сигнализации (EMBedded signalling field);

EMINF - доли минут по долготе (East longitude MINutes Fractions);

EN_PTT - нажатая тангента "нажать и говорить" (Enable_Press To Talk);

ERM - электромагнитная совместимость и спектр радиочастот (Electromagnetic compatibility and Radio spectrum Matters);

EW - направление долготы (запад или восток) (East West);

FEC - канальный помехоустойчивый код (Forward Error Correction);

FID - информационное поле в структуре PDU, кодирующее значение SFID или MFID (Feature set IDentifier);

FIFO - обслуживание очереди по принципу "первый зашел, первый вышел" (First In First Out);

FLCO - код операции управления соединением (Full Link Control Opcode);

FNS - функция не поддерживается (Feature Not Supported);

FOACSU - установление вызова без использования канала (Full Off Air Call Set Up);

FULL_LC - полное сообщение управления соединением (Full_Link Control);

GN - номер группы (Group Number);

GPI - групповой идентификатор (адрес) (Group Identity);

GPS - глобальная система позиционирования (Global Positioning System);

ID - идентификатор (IDentifier);

IE - информационный элемент (Information Element);

IETF - Инженерный совет интернета (Internet Engineering Task Force);

IP - интернет-протокол (Internet Protocol);

IPDI - адрес для шлюза IP, использующего синхронизацию со смещением полезной нагрузки (address for services to an IP gateway using payload offset timing);

IPI - идентификатор интернет-протокола (Internet Protocol Identity);

IPv4 - интернет-протокол 4-й версии (Internet Protocol version 4);

IPv6 - интернет-протокол 6-й версии (Internet Protocol version 6);

IV - вектор инициализации (Initializing Vector);

LB - последний блок (Last Block);

LBT - протокол по принципу "слушай, перед тем как передавать" (Listen Before Transmit);

LC - управление соединением (Link Control);

LFSR - регистр сдвига с линейной обратной связью (Linear Feedback Shift Register);

LINEDI - адрес для услуг для шлюза линии связи, использующей синхронизацию со смещением полезной нагрузки (address for services to a line gateway using payload offset timing);

LINEI - идентификатор линии (LINE Identity);

LIP - протокол обработки информации о местоположении (Location Information Protocol);

LSB - младший бит (Least Significant Bit);

MANET - децентрализованная сеть (Mobile Ad hoc NETwork);

MBC - многоблочное сообщение управления (Multiple Block Control);

MFID - идентификатор производителя, разработавшего набор дополнительных функций (Manufacturer's FID).

Примечание - Для специфических функций, разработанных в рамках данного стандарта в пользу российских потребителей, зарезервировано значение MFID, равное 56₁₆;

MOD - модуль (MODulus);

MODEL - вид сетевой модели;

MSB - старший бит (Most Significant Bit);

MSC - диаграмма последовательности сообщений (Message Sequence Chart);

MSI - идентификация абонентской станции (Mobile Station Identity);

MSID - идентификатор абонентской станции (Mobile Station IDentifier);

MV_AP - абсолютные параметры перемещения (MoVe_Absolute Parameters);

NA - не применяется (Not Applicable);

NACK - подтверждение недостоверного получения (отрицательное подтверждение) (Negative ACKnowledgement);

NACKD - подтверждение недостоверного получения в нисходящем канале (Negative ACKnowledgement outbound);

NACKU - подтверждение недостоверного получения данных в восходящем канале (Negative ACKnowledgement inbound);

NDEG - градусы широты (North latitude Degrees);

NET - сеть (NETwork);

NMEA - Национальная ассоциация морской электроники (National Maritime Electronic Association);

NMINF - доли минут широты (North latitude MINute Fractions);

NS - направление широты (север или юг) (North South);

OACSU - установление неэфирного вызова (Off Air Call SetUp);

OPCODE - код операции (OPeration CODE);

PABX - учрежденческая автоматическая телефонная станция (Private Automatic Branch eXchange);

PABXDI - идентификатор адреса шлюза для обслуживания учрежденческой автоматической телефонной станции, использующего синхронизацию со смещением полезной нагрузки (gateway address identifier for services to the Private Automatic Branch eXchange using payload offset timing);

PABXI - идентификатор учрежденческой автоматической телефонной станции (Private Automatic Branch eXchange Identity);

PAR - разделение, информационный элемент, используемый для распределения абонентских станций на транкинговых станциях, имеющих два канала управления (PARtition);

PATCS - установление вызова по принципу "нажать и говорить" (Press And Talk Call Setup);

PCt - содержание полезной нагрузки (Payload Contents);

PDP - протокол пакетной передачи данных (Packet Data Protocol);

PDU - блок данных протокола (Protocol Data Unit);

PF - флаг защиты (Protect Flag);

PI - индикатор конфиденциальности (Privacy Indicator);

PL - физический уровень (Physical Layer);

PN - добавочный полубайт (Pad Nibble);

PowI - индикатор управления мощностью и приоритетом прерывания (pre-emption and Power control Indicator);

ppm - частей на миллион (10^-6) (parts per million);

PS_RQ - запрос режима энергосбережения (Power Save_ReQuest);

PSN - физический серийный номер (Physical Serial Number);

PSTN - коммутируемая телефонная сеть общего пользования (Public Switched Telephone Network);

PSTNDI - идентификатор адреса шлюза для предоставления услуг коммутируемой телефонной сети общего пользования с использованием синхронизации смещения полезной нагрузки (gateway address identifier for services to the Public Switched Telephone Network using payload offset timing);

PSTNI - идентификатор адреса шлюза для предоставления услуг коммутируемой телефонной сети общего пользования (Public Switched Telephone Network Identity);

PTT - "нажать и говорить", передача информации абонентской станцией с момента нажатия тангенты до момента ее отжатия (Push To Talk);

QACK - подтверждение очереди (Queue ACKnowledgement);

QACKD - подтверждение очереди в нисходящем направлении (Queue ACKnowledgement outbound);

R - зарезервированное поле для будущего развития стандарта (Reserved);

RC - обратный канал (Reverse Channel);

RFC - готовность к коммуникации (ведению связи) (Ready For Communications);

RQ - запрос (Request);

RX - прием (Receive);

SAP - идентификатор точки доступа к услуге (Service Access Point);

SARQ - выборочный автоматический запрос повторной передачи (Selective Automatic Repeat request);

SDL - язык спецификаций и описаний (Specification and Description Language);

SDM - короткое сообщение (Short Data Message);

SDMI - идентификация коротких сообщений (Short Data Message Identity);

SDU - блок служебных данных (Service Data Unit);

SEP - разделение (SEParation);

SF - дополнительный флаг (Supplementary Flag);

SFID - идентификатор набора основных функций стандарта (константа, равная 0₁₆) (Standards FID);

SIMI - одноэлементные или многоэлементные данные (Single Item Multi-Item data);

SITE - идентификатор сайта внутри сети;

SLC - управление короткими соединениями (Short Link Control);

SLCO - код операций управления короткими соединениями (Short Link Control Opcode);

SUPLI - дополнительная идентификация (Supplementary Identity);

SV - услуга (сервис) (SerVice);

SYNC - синхронизация (SYNChronization);

SYS - система (SYStem);

TACT - тип доступа к каналам Time Division Multiple Access (Time Division Multiple Access Channel Type);

TATTSI - идентификатор для адресации рассылочного сервиса разговорной группы (address to identify the talkgroup subscription/attachment service);

TCh - канал Time Division Multiple Access (Time Division Multiple Access Channel);

TCP - протокол управления передачей (Transmission Control Protocol);

TD - признак конца передачи данных (Terminator Data);

TD_LC - прерыватель данных, содержащий сообщение управления соединением (Terminator Data_Link Control);

TDD - временное разделение дуплексных каналов (Time Division Duplex);

TDMA - многостанционный доступ с временным разделением (Time Division Multiple Access);

TO - максимальное время ожидания (Time Out);

TP - попытка синхронизации (Timing Push);

TSCC - канал управления транкинговой станцией (Trunk Station Control Channel);

TSCCAS - альтернативный канал управления транкинговой станцией в другом логическом канале (другом таймслоте) (Trunk Station Control Channel Alternate Slot);

TSI - идентификатор транкинговой станции (Trunk Station Identifier);

TX - передача (Transmit);

UAB - добавочные блоки (Unified data transport Appended Blocks);

UDP - протокол дейтаграммы абонента (User Datagram Protocol);

UDT - унифицированная передача данных (Unified Data Transport);

UDTHD - транспортный заголовок для унифицированной передачи данных в нисходящем направлении (Unified Data Transport Header outbound);

UDTHU - транспортный заголовок для унифицированной передачи данных в восходящем направлении (Unified Data Transport Header inbound);

Unicode - международный стандарт кодировки символов, который предоставляет уникальный номер каждому символу (Universal Code);

USBD - унифицированный одиночный блок данных (Unified Single Block Data);

UTC - всемирное координированное время (Universal Time Coordinated);

UTF - формат преобразования универсального кода (Unicode Transformation Format);

VN_AP - подтверждение ожидания (Vote Now_Absolute Parameters);

WACK - ожидание подтверждения (Wait ACKnowledgement);

WACKD - ожидание подтверждения в нисходящем канале (Wait ACKnowledgement outbound);

WD - удаленный (исключенный) (WithDrawn).

Общесистемное описание возможностей радиооборудования, соответствующего настоящему комплексу стандартов цифровой ППР, приведено в ГОСТ Р 71586.1-2024 (раздел 5).

5.1 Транкинговая сеть ППР. Общие положения

В настоящем стандарте описываются алгоритмы работы оборудования, обеспечивающие режим работы транкинга (trunking - объединение в пучок). Транкинг был разработан с целью рационального использования частотных каналов. В основе идеи транкинга лежит выделение общей группы каналов всем абонентам сети. Свободный канал динамически распределяется каждому абоненту, инициировавшему соответствующий вызов, на время соединения. Это позволяет эффективно использовать ресурсы системы, повысить конфиденциальность разговора и качество предоставляемых услуг.

Примечание - Под услугами в настоящем стандарте понимается не только оказание возмездных услуг связи или использование функций сети для обеспечения деятельности предприятий, но и фактический перевод слова "сервис" (например, речевые услуги).

Режим транкинга используется для обеспечения большей зоны радиопокрытия <1> по отношению к конвенциональным системам и увеличения количества абонентов.

--------------------------------

<1> Определение к данному термину установлено в ГОСТ Р 55897.

Для сетей, работающих в транкинговом режиме, также характерны большая пропускная способность, определяемая достижимым количеством абонентов, работающих на одном канале, и оперативность связи, определяемая временем установления связи (соединения с абонентом).

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

ТС является основным элементом развертываемой сети транкинговой связи, включает в себя приемо-передающее оборудование с антенно-фидерными устройствами и контроллером, который управляет работой АС и ретрансляторов с помощью коммутации каналов передачи, а также обеспечивает выход в телефонную сеть организации или ТФОП.

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

Соединение ТС между собой осуществляется с помощью КО.

Структурная схема организации транкинговой сети подвижной радиосвязи приведена на рисунке 1.

Рисунок 1 - Структурная схема организации сети подвижной

радиосвязи настоящего комплекса стандартов

с использованием режима транкинга

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

Услуги и функциональные возможности, определенные в настоящем стандарте, могут быть использованы для оборудования транкинговых сетей и называются "набор функций по умолчанию", который выделяется для SFID. Стандарт ППР дает возможность производителям определять и реализовывать "частные" наборы функциональных возможностей и услуг, которые содержат дополнительные "частные" услуги и функциональные возможности, которые могут быть не реализуемы оборудованием, не поддерживающим этот "частный" набор функций. Кроме того, PDU SFID могут содержать опциональные IE конкретного производителя.

Важным классом сетей ППР являются децентрализованные сети.

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

Системы связи на базе технологии MANET могут быть основаны на различных реализациях данной технологии для удовлетворения специфики применения системы связи в заданных условиях.

Варианты реализации могут включать в себя одну или несколько технологий, например:

- маршрутизируемые;

- без маршрутизации;

- локальные;

- масштабируемые;

- плоские;

- многоуровневые;

- стационарные и др.

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

5.2 Услуги и функциональные возможности оборудования транкинговой сети

"Стандартный набор функций" включает в себя следующие услуги и функциональные возможности:

а) общие услуги:

1) контроль и управление доступом к АС с использованием TSCC и протокола произвольного доступа,

2) определение местоположения АС в пределах зоны обслуживания системы радиосвязи по идентификации сайта и регистрации,

3) поиск TSCC,

4) применение разрешения на использование системы,

5) использование механизма UDT для поддержки сервиса коротких данных UDT, услуги передачи данных через шлюзы supplementary_user и extended_addresses,

6) трансляция системных параметров в АС,

7) аутентификация АС,

8) информирование о том, что та или иная функциональная возможность не поддерживается,

9) динамический контроль мощности АС,

10) управление прерыванием передачи;

б) основные голосовые услуги:

1) обслуживание группового вызова,

2) обслуживание индивидуального вызова;

в) вторичные голосовые услуги:

1) услуга вызова всех АС,

2) услуга широковещательной передачи голосового вызова,

3) услуга вызова "режим открытого голосового канала";

г) основные услуги при работе с данными:

1) служба <1> передачи "коротких" данных,

--------------------------------

<1> Определение к данному термину установлено в ГОСТ Р ИСО/МЭК 18384-1.

2) служба пакетной передачи данных;

д) состояние службы:

1) состояние службы доставки,

2) состояние службы опроса;

е) дополнительные услуги:

1) услуга передачи данных supplementary_user (дополнительные данные, передаваемые при первичном установлении вызова),

2) блокировка и разблокировка АС,

3) удаленное безвозвратное приведение АС в неработоспособное состояние и (или) удаление программного обеспечения на АС,

4) услуга ответа на вызов,

5) услуга отмены/окончания вызова.

Для описания услуг и функциональных возможностей при необходимости используются диаграммы, которые показывают специфические моменты в использовании TSCC и при передаче пользовательской информации.

5.3 Типы каналов транкинговой станции

ТС организует несколько типов радиоканалов.

Настоящим стандартом транкинговой ППР предусмотрено использование централизованного управления поиском и назначением свободного канала ТС для коммутации абонентских станций между собой.

С этой целью предусмотрено использование ТС трех типов каналов:

- рабочие каналы;

- TSCC;

- CACH.

Все типы каналов являются цифровыми.

5.4 Рабочие каналы

Рабочие каналы предназначены для передачи информации между пользователями (речь, данные пользователей произвольной длины), которые эквивалентны каналам передачи данных в режиме ретрансляции сигналов и описаны в 6.6.

По рабочим каналам могут быть переданы и приняты следующие типы сообщений:

- речевые;

- пользовательские данные произвольной длины;

- аварийные;

- статусные сообщения;

- данные о местоположении;

- короткие блоки данных.

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

5.5 TSCC

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

Канал управления представляет собой как минимум один таймслот TDMA-кадра, передаваемого на одной радиочастоте.

Обычно TSCC, как и рабочие каналы, физически представляют собой полосы радиочастот и могут выделяться парами, с частотным разделением в соответствии с ГОСТ Р 71586.1-2024 (пункт 6.5.1). Каждая пара включает восходящее и нисходящее направления рабочего канала. Восходящее направление рабочего канала организуется на одной радиочастоте, а нисходящее направление рабочего канала - на другой радиочастоте. Разнос частот между каналами должен обеспечить функционирование ТС и АС одновременно как на восходящем, так и на нисходящем направлениях.

В режиме ожидания АС постоянно контролирует передаваемую информацию в нисходящем направлении TSCC (на выделенной радиочастоте в назначенном для ТС таймслоте под логический нисходящий канал управления либо на одной радиочастоте в восходящем и нисходящем направлениях в таймслоте, выделенном как нисходящее направление TSCC).

В пакетах TSCC (в передаваемых служебных сообщениях), так же как и в рабочих каналах, передается кадровая SYNC, которая располагается в середине пакета TDMA (см. ГОСТ Р 71586.1-2024, подраздел 6.6) и соответствует битовым комбинациям, структура которых описана в ГОСТ Р 71586.2-2024 (подраздел 6.6).

5.6 Кадровая синхронизация

Кадровая синхронизация определяет тип передаваемой информации (сообщения, которые для TSCC являются только служебными) и тип направления передачи: восходящее (от АС к ТС) или нисходящее (от ТС к АС). В случае совмещенного канала при передаче в нем пользовательской информации кадровая синхронизация обеспечивает разделение по типам передаваемых сообщений аналогично рабочим каналам, как это описано в 6.7.

Типы синхронизации в рабочих каналах транкинговой станции соответствуют ретрансляционным каналам и описаны в ГОСТ Р 71586.2-2024 (подраздел 6.6).

В служебных сообщениях TSCC передаются синхрокомбинации, которые обеспечивают определение направления передачи:

- для нисходящего направления TSCC - служебные сообщения, источником которых является ТС;

- для восходящего направления TSCC - данные, источником которых является АС.

Таймеры, а также константы и адреса в АС, необходимые для обеспечения работы в транкинговом режиме, приведены в приложении А. Операционные коды для управления каналом связи приведены в приложении Б.

5.7 CACH

CACH не является ни TSCC, ни рабочим каналом (описание CACH для рабочих каналов приведено в ГОСТ Р 71586.2). Кроме того, под него не выделяется отдельная радиочастота. Он передается в TSCC аналогично рабочим каналам в нисходящем направлении канала. Передача CACH производится номинально непрерывно, он занимает положение между таймслотами управления TSCC. В CACH передается номер таймслота, содержащего информацию TSCC, сведения о занятости таймслота, обеспечении идентификации транкинговой сети и определении режима экономии электроэнергии АС. Работа CACH при использовании TSCC описана в 6.9.2.

TSCC могут быть выделенными, совмещенными или асинхронными.

Выделенный TSCC всегда является каналом управления и никогда не переключается в режим передачи полезной нагрузки (речь, пользовательские данные).

Совмещенный TSCC является каналом управления, пока есть свободные каналы ТС. Когда все рабочие каналы, передающие пользовательский трафик, заняты текущими вызовами, и нужно установить еще одно соединение, то совмещенный TSCC выполняет функции рабочего канала. В случае когда освобождается один из рабочих каналов, совмещенный канал возвращает свои функции TSCC, прекращая передачу полезной нагрузки.

Асинхронный TSCC используется несколькими ТС, но отсутствуют четкие правила его использования по времени. ТС занимает TSCC, когда он свободен, и использует его. После завершения использования TSCC в асинхронном режиме одной из ТС канал остается свободным, пока не будет занят какой-либо другой ТС.

Более подробно работа в TSCC описана в 6.9.4.

5.8 Передача речевых сообщений

Требования по построению сокета вокодера соответствуют конвенциональным режимам и определены в ГОСТ Р 71586.1-2024 (подраздел 10.2).

5.9 План распределения частот канала

Транкинговая сеть поддерживает несколько способов определения номинала частоты рабочего канала для АС.

Физические каналы радиосвязи могут быть определены либо фиксированным, либо гибким планом распределения частот.

При фиксированном плане частота передатчика и приемника отображается/переносится на номер логического канала. Протокол транкинговой сети позволяет организовать до 4094 таких логических/физических отношений способом, согласно которому абсолютные частоты передатчика и приемника указаны в PDU и передаются между ТС и АС через радиоинтерфейс.

Планы каналов позволяют организовать частотное планирование и определяют физические радиочастоты, на которых передаются логические каналы. Планом каналов могут быть назначены отдельные полосы частот, как например 134 - 176 МГц, 403 - 470 МГц, 450 - 527 МГц и т.д.

Стандартом предусмотрено 4094 частотных канала, что определяет максимально возможную полосу значением 51 175 кГц.

При фиксированном плане рабочая частота определяется по формуле (В.1).

Пример - Для двух частот 450,125 МГц и 430,325 МГц:

450,125 = 450 + ((11 - 1)·(12,5/1000));

430,325 = 430 + ((27 - 1)·(12,5/1000)).

Фиксированный план распределения частот используют в основном в случаях, когда частота передачи и приема совпадает. В таблице 1 показан пример выделения частот при использовании фиксированного плана.

Таблица 1

Пример определения частот при использовании

фиксированного плана

Частота передачи ТС, МГц	Частота приема ТС, МГц
450,125	450,125
470,175	470,175
430,325	430,325
460,475	460,475
450,625	450,625

Гибкий план распределения частот каналов позволяет определять номиналы дискретных частот и связывать их с логическим номером канала (от 1 до 4094). Применяется в случаях, когда частотный разнос неодинаков.

В таблице 2 показан пример выделения частот при использовании гибкого плана.

Таблица 2

Пример выделения частот при использовании гибкого плана

Частота передачи ТС, МГц	Частота приема ТС, МГц
450,125	460,625
425,375	415,175
456,525	451,325
455,475	430,475
451,625	452,625

По гибкому плану частоты f_Rx и f_Tx определяются по следующим формулам:

f_Tx = Tx[МГц] + (Tx[кГц]·125)/1000 Мгц; (1)

f_Rx = Rx[МГц] + (Rx[кГц]·125)/1000 Мгц, (2)

где Tx[МГц], Rx[МГц] - коды SDU, определяющие целую часть несущей частоты, выраженной в МГц;

Tx[кГц], Rx[кГц] - коды SDU, определяющие дробную часть несущей частоты, выраженной в кГц.

Примечание - Значения SDU кодов определяются в соответствии с таблицей В.7.

Пример - Для частоты 450,125 МГц:

450,125 (МГц) = 450 + (1·125)/1000.

5.10 Архитектура сети

5.10.1 Архитектура сети. Общие положения

Транкинговый протокол настоящего стандарта обеспечивает предоставление услуг и функциональных возможностей в части беспроводного интерфейса в соответствии со стеком протоколов, как описано в разделе 6.

Шлюзы к PSTN и другие шлюзы, не относящиеся к радиоинтерфейсу, не описываются в настоящем документе. Они показаны только в информационных целях.

5.10.2 Сетевые функции

5.10.2.1 Служебные процедуры

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

5.10.2.2 Доступ к физическому каналу

Особенностью транкинговой системы является то, что получение физического канала выполняется автоматически, когда АС включается. Пользователю не нужно вручную выбирать физические каналы. Соответствующий физический канал хранится в памяти АС, или АС автоматически выполняет поиск приемлемого TSCC.

5.10.2.3 Идентификатор сети

Все ТС содержат идентификатор сайта и сети. Этот идентификатор называется "Код идентификации системы" и, как правило, передается в TSCC в служебных сообщениях IE C_SYScode. C_SYScode передается в CSBK, а также встроен в поля передаваемых служебных сообщений CACH. IE C_SYScode состоит из информационных полей MODEL, NET, SITE и PAR. В рамках одной сети значения, установленные в информационных полях MODEL и NET, остаются постоянными. Каждой ТС присвоен уникальный параметр SITE. АС должна использовать получаемые ею значения в информационных полях служебных сообщений MODEL и NET, чтобы определить, может ли она стать активной (начать вести радиопередачу и получить в дальнейшем доступ) в этой сети.

5.10.3 Местоположение АС методом регистрации

Зона радиопокрытия транкинговой сети рассчитывается в соответствии с ГОСТ Р 55897 и делится на ряд областей (Location DMRLAs). DMRLA соответствует одному сайту или небольшому числу сайтов, структурированных как DMRLA. Неявная регистрация является функцией сети, которая позволяет регистрировать местоположение АС без необходимости передачи служебных сообщений в PDU явной регистрации. Неявная регистрация может быть выполнена с помощью любого служебного сообщения в PDU, содержащем индивидуальный идентификатор АС. Например, это может быть запрос вызова или ответное служебное сообщение на полученный запрос.

Возможно, что из-за воздействия различных неблагоприятных факторов регистрационная информация, хранящаяся в сетях и касающаяся конкретных АС, отличается. Для того чтобы восстановить и сохранить регистрационные записи, возможны следующие действия:

- система может обновить свои регистрационные записи из запросов вызова произвольного доступа АС (сеть, однако, может отказать в запрашиваемой услуге АС по другим причинам);

- ответы, полученные от АС (например, в результате проверки радиоканала), также неявно обновляют регистрационную запись в системе.

5.10.4 Обеспечение ОРМ в режиме транкинговой связи

Требования к техническим средствам и информационным системам для проведения оперативно-розыскных мероприятий в сетях профессиональной подвижной радиосвязи, в том числе с использованием режима транкинговой связи, устанавливаются федеральным органом исполнительной власти в области связи по согласованию с уполномоченными органами, осуществляющими оперативно-розыскную деятельность или обеспечение безопасности Российской Федерации.

В случае применения криптографической защиты (кодирования) передаваемых данных и речи, на ПУ СОРМ уполномоченного органа, осуществляющего оперативно-розыскную деятельность на территории Российской Федерации, указанные данные и речь передаются в соответствии с требованиями, установленными федеральным органом исполнительной власти в области связи по согласованию с уполномоченными органами, осуществляющими оперативно-розыскную деятельность или обеспечение безопасности.

5.11 Режимы транкинговой передачи. Общие положения

Транкинговая сеть (система) настоящего стандарта позволяет осуществлять три режима транкинговой передачи: "транкинг сообщений", "транкинг передачи" и "квазитранкинговая передача".

5.11.1 Транкинг сообщений

Транкинг сообщений обеспечивает удержание рабочего канала на протяжении всего времени соединения. Пользователям в этом режиме обеспечивается минимальная задержка для каждой единичной передачи (вызова), так как в этом случае в системе не организуется очередь при выделении ресурсов рабочего канала. Отсутствие каких-либо ощутимых задержек при активации PTT (нажатии тангенты) на АС гарантирует, что разговор может продолжаться без прерывания. Данный режим минимизирует обработку и затраты на сигнализацию в сетевой инфраструктуре.

Выделение рабочего канала в случае вызова разговорной группы прекращается только тогда, когда вызов прерывается его инициатором явным образом, с использованием предусмотренных конструктивных возможностей АС. Одна из сторон инициирует отбой во время индивидуального вызова, или отбой происходит, если истекает таймер активности. В этом режиме ТС может сбросить вызов в любое время, при этом ТС должна быть уверена, что все стороны, участвующие в вызове, получили PDU о прекращении вызова. Для этого ТС перед сбросом вызова должна отправить соответствующие служебные сообщения и получить ответы на них.

Недостатком этого режима является то, что рабочий канал остается выделенным даже тогда, когда возможны существенные перерывы в активации PTT, что может привести к менее эффективному использованию пропускной способности рабочего канала.

5.11.2 Транкинг передачи

Транкинг передачи обеспечивает удержание рабочего канала на время передачи АС.

Когда пользователь отпускает тангенту, рабочий канал перераспределяется и АС возвращается к отслеживанию служебных сообщений и выполнению своих функций на TSCC. При очередной активации PTT (нажатии тангенты) на АС транкинговой станцией вновь выделяется новый рабочий канал, который является свободным и может быть предоставлен АС для текущего вызова.

Пользователи в этом режиме могут испытывать задержки для каждого вызова (радиопередачи). В частности, такие задержки могут происходить, когда система занята, так как рабочие каналы заняты и не могут быть немедленно предоставлены для запрашиваемого вызова. В этом случае транкинговая сеть (контроллер транкинговой сети) должна поставить АС, пытающуюся осуществить вызов, в очередь до того времени, пока ресурс рабочих каналов не станет доступен.

Преимуществом этого режима является более эффективное использование имеющейся пропускной способности рабочего канала. Когда пользователь АС отпускает тангенту (PTT), рабочий канал перераспределяется в системе. При очередной активации PTT транкинговая станция выделяет новый рабочий канал, который является свободным и может быть предоставлен данной АС для текущего вызова.

5.11.3 Квазитранкинговая передача

Рабочий канал распределяется между вызываемой и вызывающей сторонами в начале вызова. Когда пользователь отпускает тангенту (размыкание PTT), система в течение короткого промежутка времени, определенного таймером удержания, удерживает рабочий канал для данного вызова, чтобы разрешить другой стороне передавать информацию. Когда время таймера истекает, рабочий канал перераспределяется. Этот метод исключает задержку транкинговой передачи, но пользователи для своих вызовов ограничены временем таймера удержания.

6 Требования к архитектуре протокола

6.1 Архитектура протокола

Общее описание структуры протокола работы в транкинговом режиме соответствует базовым требованиям и приведено в ГОСТ Р 71586.1-2024 (подраздел 6.1).

6.2 Радиоинтерфейс физического уровня (уровень 1)

Радиоинтерфейс уровня 1 является физическим интерфейсом, который работает с физическим пакетом, состоящим из битов, подлежащих передаче и/или приему.

Перечень функций, выполняемых протоколом физического уровня в транкинговом режиме, соответствует режиму связи через ретранслятор, описанному в ГОСТ Р 71586.2.

6.3 Радиоинтерфейс канального уровня (уровень 2)

Радиоинтерфейс уровня 2 стека протоколов предназначен для работы с логическими соединениями.

Базовый перечень функций, выполняемых протоколом канального уровня, требования к которому соответствуют настоящему стандарту ППР, описаны в ГОСТ Р 71586.1.

Кроме базового перечня функций стека протоколов на канальном уровне в транкинговом режиме используются дополнительные функции:

- адресация каналов передачи (источник и/или получатель);

- взаимодействие речевых приложений (данных вокодера) с PL;

- услуги переноса данных;

- обмен сигнализацией и/или пользовательскими данными с CCL;

- аутентификация способом вызова и ответа.

6.4 Радиоинтерфейс уровня управления вызовами (уровень 3)

Радиоинтерфейс уровня 3 (CCL) стека протоколов предназначен для передачи служебных сообщений.

Базовые требования к радиоинтерфейсу уровня 3 (CCL) соответствуют настоящему стандарту ППР и описаны в ГОСТ Р 71586.1.

Для управления вызовами в транкинговом режиме интерфейс уровня управления может иметь дополнительные встроенные функции:

а) активация/деактивация ТС/TSCC (для асинхронного режима доступа);

б) установление, поддержание и прекращение вызовов;

в) передача и прием индивидуальных и групповых вызовов;

г) адресация получателя (идентификаторы АС или шлюзы в зависимости от обстоятельств);

д) поддержка встроенных услуг (аварийная сигнализация, упреждение, поздний вход и т.д.);

е) управление вызовами передачи данных;

ж) анонсирующая сигнализация;

и) управление имеющимися ресурсами:

1) управление ресурсами TSCC с помощью протокола произвольного доступа,

2) организация очереди к полезной нагрузке ресурса;

к) установка индивидуальных или групповых вызовов через выделенный канал сигнализации;

л) информация о местоположении АС по регистрации ее в сети;

м) информация о параметрах режима энергосбережения АС;

н) трансляция параметров транкинговой сети на АС.

6.5 Общая классификация каналов транкинговой станции

6.5.1 Классификация по типам, способу поиска и назначению канала

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

Для этого в ТС предусмотрено использование трех типов каналов:

- рабочие каналы;

- CACH;

- TSCC.

Все указанные каналы являются цифровыми.

По рабочим каналам могут быть переданы и приняты следующие типы сообщений:

- речевые;

- пользовательские данные произвольной длины;

- экстренные сообщения (обеспечение возможности АС оповестить диспетчера или других абонентов об экстренной ситуации);

- статусные сообщения;

- данные о местоположении;

- короткие блоки данных.

CACH не является каналом управления или рабочим каналом. Для каналов управления и рабочих каналов CACH передается в нисходящей линии. Для TSCC передача CACH производится постоянно. CACH занимает временное положение между двумя таймслотами управления TSCC. В CACH передается служебная информация, содержащая номер таймслота, несущего информацию TSCC, данные о занятости таймслота и другая информация. Работа CACH при использовании TSCC описана в 6.9.2.

TSCC предназначены для получения и направления в транкинговую сеть запросов на регистрацию от АС, аутентификацию АС в сети, предоставление услуг связи АС, проверки радиодоступности вызываемой АС, извещения АС о назначении ей рабочего канала для соединения, отклонении запроса или о постановке запроса в очередь в соответствии с назначенным приоритетом.

Для одной ТС может существовать один или несколько TSCC. TSCC - это всегда пара направлений: восходящее и нисходящее. Физически TSCC могут быть расположены на разных частотах в виде восходящего направления от АС к ТС и нисходящего направления от ТС к АС или на одной радиочастоте.

6.5.2 Классификация TSCC

TSCC настоящего стандарта могут быть выделенными, совмещенными или асинхронными.

Выделенный TSCC всегда является каналом управления и никогда не переключается в режим передачи полезной нагрузки (речь, пользовательские данные). Выделенный TSCC передает служебную информацию непрерывно, что облегчает роуминг и обеспечивает полный контроль над абонентами. Абоненты выходят в эфир только по "приглашению". Могут быть сайты с несколькими выделенными каналами для балансировки нагрузки (для очень больших сайтов с высоким трафиком).

Совмещенный TSCC является каналом управления, пока есть свободные каналы. Когда все рабочие каналы, передающие пользовательский трафик, заняты текущими вызовами, а нужно установить еще одно соединение, то совмещенный TSCC выполняет функции рабочего канала. Когда освобождается один из рабочих каналов, совмещенный канал возвращает свои функции как TSCC, прекращая передачу полезной нагрузки. Совмещенный канал используется только для малозагруженных сайтов при небольших объемах управляющей информации. Это связано с тем, что, когда TSCC используется для передачи пользовательской информации, может быть потерян доступ к ТС, а АС не смогут найти сайт и зарегистрироваться. Преимуществом организации совмещенного TSCC в транкинговой системе является возможность увеличения общей емкости сайта на один дополнительный рабочий канал, что актуально при небольшом количестве каналов.

Асинхронный TSCC по умолчанию выключен (de-keyed), а его частота может использоваться для нужд сторонних абонентов, как транкинговых, так и в конвенциональном режиме с ретрансляцией сигналов. ТС занимает TSCC, когда он свободен, и использует его, пока не освободит. Для получения сервисов АС в транкинговом режиме работы должна сначала активировать контрольный канал (по аналогии с процедурой активации ретранслятора в конвенциональном режиме), а затем вести работу в транкинговом режиме. В некоторых случаях организация такого TSCC является целесообразной. Например, когда одни и те же радиочастоты выделены разным ведомствам. В этом случае одно ведомство использует оборудование, работающее в конвенциональном режиме с ретрансляцией сигналов, а другое ведомство работает в транкинговом режиме. После использования TSCC в асинхронном режиме этот канал остается свободным. Так как трафик небольшой, то коллизии в эфире случаются редко.

Подробно работа в TSCC описана в 6.9.4.

6.6.1 Расположение пакета на временной оси и структура рабочих каналов транкинговой станции

Транкинговые станции, соответствующие настоящему комплексу стандартов, обеспечивают передачу трафика (речевых сообщений, пользовательских данных, пользовательских сообщений) между абонентами с помощью рабочих каналов.

Рабочие каналы физически представляют собой радиочастоты и могут назначаться с частотным разделением в соответствии с ГОСТ Р 71586.2-2024 (пункт 6.5.1) парами. Каждая пара включает восходящее и нисходящее направления рабочего канала. Восходящее направление рабочего канала организуется на одной радиочастоте, а нисходящее - на другой радиочастоте. Также восходящие и нисходящие направления рабочего канала могут быть организованы на одной и той же радиочастоте.

При передаче пользовательской информации (речь, пользовательские данные) в рабочих каналах в одночастотном или двухчастотном режиме используется способ разнесения логических каналов по времени в двухслотовой структуре TDMA. Передача служебной информации в рабочих каналах ТС соответствует аналогичной процедуре в режиме ретрансляции, описанной в ГОСТ Р 71586.2-2024 (пункт 6.5.1), за исключением типов служебных сообщений, описанных в 16.2.2.4 и 16.2.2.5.

В рабочих TSCC должны передаваться служебные сообщения, описание которых приведено в 6.9.5.4 и 6.9.5.5.

6.6.2 Структура пакетов и кадров, передаваемых транкинговой станцией в рабочих каналах

Структура пакетов и кадров, передаваемых ТС в рабочих каналах, соответствует структуре пакетов и кадров, передаваемых в режиме ретранслятора, и описана в ГОСТ Р 71586.2-2024 (подраздел 6.5).

6.7 Кадровая синхронизация в рабочих каналах транкинговой станции

Кадровая синхронизация (SYNC) в рабочих каналах ТС обеспечивается аналогично режиму ретрансляции с помощью специальной последовательности бит, которая располагается в центре пакета TDMA (см. ГОСТ Р 71586.1-2024, подраздел 6.6).

Кадровая синхронизация позволяет определить тип передаваемой информации (сообщения, речь) и направление передачи: восходящее - от АС к ТС, или нисходящее - от ТС к АС.

Типы синхронизации в рабочих каналах транкинговой станции соответствуют типам синхронизации в режиме ретрансляции и описаны в ГОСТ Р 71586.2-2024 (подраздел 6.6).

6.8 Источники синхронизации и канал передачи пользовательских данных транкинговых станций

Для передачи пользовательской информации (речь, данные) используются рабочие каналы. Синхронизация в рабочих каналах транкинговых станций соответствует работе ретранслятора и описана в ГОСТ Р 71586.2-2024 (подраздел 6.7).

6.9 TSCC и CACH

6.9.1 Структура TSCC во временной области

TSCC представляет собой как минимум один таймслот TDMA-кадра, передаваемого на одной радиочастоте.

Обычно TSCC, как и рабочие каналы, физически представляют собой радиочастоты и могут назначаться с частотным разнесением в соответствии с ГОСТ Р 71586.2-2024 (пункт 6.5.1) парами, каждая пара включает восходящее и нисходящее направления TSCC. Восходящее направление TSCC организуется на одной радиочастоте, а нисходящее - на другой. Разнос частот между каналами должен обеспечить функционирование ТС и АС одновременно как на восходящем, так и на нисходящем направлении.

В режиме ожидания АС постоянно контролирует передаваемую информацию в нисходящем направлении TSCC (выделенную радиочастоту в выделенном для ТС таймслоте под логический нисходящий TSCC либо, если радиочастота одна, то в таймслоте, выделенном как нисходящее направление TSCC).

В пакетах TSCC, так же как и в рабочих каналах, передается кадровая синхронизация, которая располагается в середине пакета TDMA (см. ГОСТ Р 71586.1-2024, подраздел 6.6) и соответствует битовым комбинациям, требования к которым описаны в ГОСТ Р 71586.2-2024 (подраздел 6.6).

Кадровая синхронизация позволяет определить тип передаваемой информации (сообщения, которые для TSCC являются служебными) и тип направления передачи - восходящее или нисходящее. В случае совмещенного канала при передаче в нем пользовательской информации кадровая синхронизация позволяет определить тип передаваемых сообщений аналогично рабочим каналам, как это описано в 6.7.

Типы синхронизации в рабочих каналах ТС соответствуют типам синхронизации режима ретрансляции и описаны в ГОСТ Р 71586.2-2024 (подраздел 6.6). Следует учитывать, что синхрокомбинации обеспечивают передачу служебных сообщений в TSCC.

Для нисходящего направления TSCC ТС передает служебные сообщения, источником которых она является. Для восходящего направления TSCC ТС передает данные, источником которых является АС.

Сигнализация (передача служебных сообщений) в нисходящем направлении TSCC номинально непрерывна, при этом каждый TDMA-кадр включает в себя два независимых логических канала, располагаемых во

области в таймслотах 1 и 2. В каждом нисходящем направлении TSCC между двумя TDMA-каналами (таймслотами), предназначенными для передачи служебного трафика, всегда расположен CACH, обеспечивающий нумерацию этих каналов, доступ к логическим каналам, идентификацию транкинговой сети и определение режима экономии электроэнергии АС.

На рисунке 2 изображены таймслоты, TDMA-кадры, кадры произвольного доступа и кадры экономии электроэнергии (энергосбережения). Таймслот описан в ГОСТ Р 71586.1-2024 (подраздел 6.5).

Рисунок 2 - Таймслоты и кадры TSCC

На рисунке 2 показано, что TDMA-кадр включает в себя два непрерывных таймслота: 1 и 2 или 2 и 1.

Кадр экономии электроэнергии определяется путем передачи одного служебного сообщения, расположенного последовательно в четырех последовательных коротких LC-блоках управления с использованием PDU, встроенных в CACH. Кадр экономии электроэнергии передается в нисходящем направлении TSCC каждые 480 мс.

6.9.2 Использование CACH, передаваемого на радиочастоте TSCC

6.9.2.1 Система разграничения доступа АС к TSCC по их типам

В CACH должен передаваться короткий LC, который содержит 3 байта данных и описан в ГОСТ Р 71586.2-2024 (подраздел 11.1).

Если один из передаваемых логических каналов настроен как TSCC, то в нисходящем направлении TSCC в CACH должны непрерывно или периодически передаваться служебные сообщения C_SYS_Parms в структуре короткого LC (Short LC), предназначенные для широковещательной передачи служебной информации, содержащей "Идентификационный код системы" (System Identity Code) и IE Reg и Common_Slot_Counter.

Вся информация, передаваемая с помощью Short LC в CACH, относится к обоим логическим каналам. Передача одного служебного сообщения Short LC производится в четырех пакетах CACH (учитывая количество бит Short LC и возможность размещения их в CACH), следовательно, SLCO, который используется в структуре Short LC, должен быть передан четыре раза по 30 мс, итого - 120 мс.

Примечание - ТС использует бит AT, передаваемый в CACH в качестве ключевого элемента протокола случайного доступа, описанного в ГОСТ Р 71586.2-2024 (пункт 15.5.4).

6.9.2.2 C_SYS_Parms и P_SYS_Parms - подмножества кодов идентификации системы

Полный IE C_Syscode (см. 16.3.7, таблица 124) имеет длину 16 бит и находится в обоих C_CYS_Parms (см. 16.2.3.1, таблица 117) и P_SYS_Parms PDU (см. 16.2.3.2, таблица 118). Только самые значимые 14 бит C_SYScode переносятся в CACH, поскольку CACH является общим для двух логических каналов. Один физический канал может иметь один или два TSCC. Каждый TSCC идентифицируется двумя битовыми IE PAR, которые помещаются в два младших значащих бита (биты LSB) C_SYScode.

Поскольку CACH является общим для обоих логических TSCC, поле PAR допускается не указывать. Не все служебные сообщения CSBK, передаваемые в нисходящем канале, содержат IE C_SYScode. Если АС осуществляет поиск TSCC и пытается определить, разрешен ли доступ, она может игнорировать разделенный канал посредством декодирования CACH. Если совпадения нет, то АС нет необходимости продолжать поиск CSBK, который содержит C_Syscode.

6.9.2.3 IE Reg служебного сообщения C_SYS_Parms

IE Reg в служебном сообщении C_SYS_Parms содержит флаг, который указывает, требуется ли в данной транкинговой системе регистрация АС перед ее активацией. Элемент Reg также содержится в служебном сообщении Aloha, передаваемом в CSBK PDU нисходящего TSCC.

6.9.2.4 Данные Common_Slot_Counter в C_SYS_Parms

Common_Slot_Counter транслируется в C_SYS_Parms и представляет собой целое положительное число в диапазоне от 0 до 511. Счетчик увеличивается на единицу в каждом последующем полученном сообщении C_SYS_Parms Short Link Control PDU. Когда счетчик доходит до значения 511, он переходит в состояние 0. Таким образом, каждые 120 мс происходит увеличение на единицу Common_Slot_Counter.

На рисунке 3 показано, как Common_Slot_Counter передается в CACH и происходит последовательное приращение этого счетчика. АС считывает значение Common_Slot_Counter для синхронизации периодов энергосбережения с циклами спящего режима (см. 7.4.8).

Рисунок 3 - Общий счетчик таймслотов

6.9.3 Сигнализация в транкинговом режиме

Протокол транкингового режима настоящего стандарта использует CSBK и сигнальную пакетную структуру MBC, состоящую из трех блоков данных, описанную в ГОСТ Р 71586.1-2024 (подраздел 11.6). MBC PDU, адресованное отдельной АС при индивидуальном вызове или разговорной группе, должно содержать адрес источника.

Передаваемые данные по протоколу транкингового режима настоящего стандарта являются "неподтверждаемыми данными" (без подтверждения их достоверности на принимающей стороне), передача таких данных приведена в ГОСТ Р 71586.1-2024 (подраздел 9.3). Способом передачи неподтверждаемых данных является механизм UDT, описанный в ГОСТ Р 71586.1-2024 (подраздел 14.2). UDT блоки состоят из заголовка и ряда последовательно передающихся промежуточных блоков. С помощью механизма UDT передается заголовок UDT [см. ГОСТ Р 71586.1-2024 (подпункт 14.3.2.2)], который встроен в PDU, с последующей передачей от одного до четырех добавочных блоков данных (промежуточных блоков UDT), или передачи данных переменной длины, пользовательских данных или данных с расширенной адресацией (extended_addresses) между объектами.

6.9.4 Режимы TSCC

6.9.4.1 Выделенные TSCC

Выделенный (Dedicated) TSCC, как правило, применяется в транкинговой системе, где работает большое количество ТС и, следовательно, используется большое количество рабочих каналов передачи полезной нагрузки (речь, пользовательские данные). Преимуществами выделенного TSCC являются:

а) TSCC всегда доступен для АС, которая отслеживает его и обращается за оказанием соответствующей и действующей в сети услуги;

б) TSCC всегда доступен для предоставления вторичных услуг, таких как определение местоположения (регистрации) АС, передача коротких сообщений с использованием механизма UDT, коротких пользовательских данных и т.д.;

в) TSCC всегда доступен для приема поступивших запросов доступа от АС и организует очередь таких запросов, если ресурс рабочих каналов недоступен во время получения запросов о доступе к ресурсам рабочих каналов;

г) TSCC может передавать информацию АС чаще, так как TSCC является выделенным и его функционирование не прерывается на передачу трафика пользователей (речь, пользовательские данные).

6.9.4.2 Совмещенный TSCC

Совмещенный (невыделенный, Non-Dedicated) TSCC не является выделенным специально под функции управления. Он может приостановить выполнение функции TSCC и работать в режиме передачи полезной нагрузки, когда все рабочие каналы заняты передаваемым пользовательским трафиком. Такой TSCC устанавливается в ТС, которые имеют небольшое количество рабочих каналов, и ожидается трафик, превышающий возможности этих каналов. Переключение TSCC для передачи полезной нагрузки (речь, пользовательские данные) обеспечивает пользователей еще одним дополнительным рабочим каналом. Когда TSCC переключается в режим передачи полезной нагрузки, он должен прекратить передачу служебных сообщений C_SYS_Parms SLC и начать передавать P_SYS_Parms SLC в CACH, а также передавать двухбитовые комбинации кода системной идентификации и IE, обозначающего тип рабочего канала. IE "Тип рабочего канала" информирует АС, что TSCC переключился в режим полезной нагрузки. Использование в ТС совмещенного TSCC имеет следующие недостатки:

а) TSCC недоступен для предоставления вторичных услуг, таких как определение местоположения (регистрации) АС, вызовы, передача коротких данных с использованием механизма UDT и т.д.;

б) TSCC не может принимать запросы произвольного доступа с постановкой их в очередь вызовов. Прерывание работы TSCC может привести к тому, что АС теряет свою позицию в очереди на ожидание установления соединения.

6.9.4.3 TSCC с асинхронным режимом доступа

В асинхронном режиме доступа TSCC остается неактивным, в нем отсутствует радиопередача до момента его активации путем отправки короткого служебного информационного сообщения.

После активации асинхронного TSCC транкинговой станции АС синхронизируется с активированным TSCC, прежде чем сделать запрос доступа к услугам.

Процедуры асинхронного режима доступа к TSCC описаны в 7.2.2.

6.9.5 Служебные сообщения CSBK/MBC/UDT/USBD, передаваемые в каналах управления и рабочих каналах транкинговой станции

6.9.5.1 Блочная структура передаваемых служебных сообщений CSBK/MBC/UDT/USBD

Для сигнализации в TSCC предусмотрена возможность передачи служебных сообщений CSBK/MBC/UDT/USBD в PDU, которые могут быть отправлены ТС в нисходящем направлении TSCC или АС в восходящем направлении TSCC.

В случаях когда длина отправляемых служебных сообщений превышает размер одного блока CSBK PDU, для передачи должны использоваться многоблочные служебные сообщения в PDU типа MBC или UDT.

При передаче служебных сообщений в многоблочных PDU значения IE "Тип данных" должны быть установлены в соответствии с перечнем, приведенным в ГОСТ Р 71586.1-2024 (таблица 17, подраздел 10.3).

При многоблочной передаче сообщений управления в PDU с использованием процедуры UDT должны быть выполнены следующие требования:

- в IE "Тип данных" не должны использоваться типы "Заголовок MBC" и "Продолжение MBC";

- IE "Тип данных" должен быть установлен в значения: для заголовка данных - "Заголовок данных" [структура заголовка блока неподтверждаемых данных описана в ГОСТ Р 71586.1-2024 (подпункт 14.3.2.2)], для последующих блоков должны использоваться неподтверждаемые данные, а их тип должен соответствовать типам "Продолжение данных с FEC со скоростью кодирования 1/2" и "Продолжение данных с FEC со скоростью кодирования 3/4" [структура блока неподтверждаемых данных описана в ГОСТ Р 71586.1-2024 (подпункт 14.3.2.2)]. Указанные сообщения могут передаваться в нисходящем и восходящем направлениях TSCC.

6.9.5.2 Классификация служебных сообщений CSBK/MBC/UDT/USBD PDU, передаваемых в нисходящем TSCC

Служебные сообщения CSBK/MBC/UDT/USBD с использованием структуры PDU в нисходящем направлении TSCC должны передаваться ТС. Они классифицируются по типам, как показано на рисунке 4, и приведены в таблице 3.

Таблица 3

Перечень служебных сообщений CSBK/MBC/UDT/USBD PDU,

передаваемых в нисходящем TSCC

Тип сообщений	Обозначение	Назначение PDU	Описание
Широковещательные	C_GRANT	Получение/предоставление канала	Передача вызова в рабочий канал
	C_GRANT_DX	Получение/предоставление дуплексного канала	Передача вызова в дуплексном режиме в рабочем канале
	C_MOVE	Переключение на новый физический канал	АС должны переключиться на альтернативный TSCC
	C_ALOHA	ALOHA (приветствие)	Управление асинхронным режимом доступа в TSCC
	C_BCAST	Извещение/уведомление	PDU, предназначенные для использования всеми АС, прослушивающими данный TSCC
AHOY	C_AHOY	Приветствия	Отправляется к АС и требует от нее ответа
ACK	C_xACKD	Подтверждения	Ответы на PDU от АС со следующими типами: C_ACKD, C_NACKD, C_WACKD, C_QACKD
Нисходящая передача в TSCC с использованием процедуры UDT	C_UDTHD	Короткое нисходящее системное сообщение <1>	Системный PDU, адресованный АС с индивидуальным адресом и требующий ответа
Нисходящая передача в TSCC с использованием процедуры UDT	C_UDTHD	Короткое нисходящее сообщение данных <1>	Сообщение с короткими данными с использованием процедуры UDT, адресованное индивидуальной АС или речевой группе и требующее от них ответа
USBD	C_USBDD	Унифицированный одиночный блок данных: управление/данные <2>	Опрос входящих данных USBD от АС
<1> PDU C_UDTHD передается в сообщении, состоящем из нескольких блоков, и должен содержать заголовок UDT, за которым следуют от одного до четырех дополнительных блоков данных UDT, - см. приложение Б. <2> Применимо как к TSCC, так и к TSCCAS.

Рисунок 4 - Структура служебных сообщений CSBK/MBC/UDT/USBD,

передаваемых ТС в нисходящем TSCC

6.9.5.3 Классификация служебных сообщений CSBK/MBC/UDT/USBD PDU, передаваемых в восходящем направлении TSCC

В восходящем направлении TSCC служебные сообщения CSBK/MBC/UDT/USBD PDU должны передаваться АС. Они классифицируются, как показано на рисунке 5, и приведены в таблице 4.

Рисунок 5 - Структура служебных сообщений CSBK/MBC/UDT/USBD,

передаваемых АС в восходящем TSCC

Таблица 4

Перечень служебных сообщений CSBK/MBC/UDT/USBD PDU,

передаваемых в восходящем направлении TSCC

Тип сообщений	Обозначение	Назначение PDU	Описание
Random Access	C_RAND	Произвольный доступ	Запросы произвольного доступа
Ackvitation	C_ACKVIT	Ответ на запрос	Ответ на PDU, которые запрашивают еще один ответ
ACK	C_xACKU	Подтверждения	Ответ на PDU от TSCC, который требует ответа C_ACKU, C_NACKU
Inbound UDT	C_UDTHU	Короткое восходящее системное сообщение <1>	Системный PDU, адресованный АС с индивидуальным адресом или TSCC, как ответ на AHOY PDU от TSCC
Inbound UDT	C_UDTHU	Короткое восходящее сообщение данных	Сообщение коротких данных UDT, адресованное индивидуальной АС или TSCC, как ответ на AHOY PDU от TSCC
USBD	C_USBDU	Унифицированный одиночный блок данных: данные <1>	Опрос входящих данных USBD от АС
<1> C_USBDU и C_NACKU применяются как для TSCC, так и для TSCCAS.

6.9.5.4 Служебные сообщения CSBK/MBC PDU, передаваемые транкинговой станцией в нисходящем направлении рабочего канала

Служебные сообщения управления транкинговой сети могут передаваться в рабочих каналах. Служебные сообщения, передаваемые в одноблочных и многоблочных CSBK/MBC PDU в нисходящем направлении рабочего канала, должны передаваться ТС. Они классифицируются, как показано на рисунке 6, и приведены в таблице 5.

Таблица 5

Перечень служебных сообщений CSBK PDU, передаваемых

в нисходящем направлении рабочего канала ТС

Тип сообщений	Обозначение	Назначение PDU	Описание
Широковещательные	P_GRANT	Получение/предоставление канала <1>	Перемещает вызов на новый рабочий канал или уведомляет о текущем вызове до начала передачи
	P_CLEAR	Освобождение рабочего канала	Освобождает рабочий канал от текущего вызова
	P_PROTECT	Защита канала	Контроль доступа
AHOY	P_AHOY	Приветствия	Отправляется к АС и требует ответа
ACK	P_xACKD	Подтверждения	Ответ на PDU от АС со следующими типами: P_ACKD, P_NACKD, P_WACKD, P_QACKD
<1> PDU предоставления канала передается ТС на рабочий канал для перемещения текущего входящего вызова на новый рабочий канал или уведомляет о текущем вызове до начала передачи.

Рисунок 6 - Структура CSBK нисходящего рабочего канала

6.9.5.5 Служебные сообщения CSBK PDU, передаваемые в восходящем направлении рабочего канала

В восходящем направлении рабочего канала служебные сообщения с использованием PDU должны передаваться АС. Они классифицируются, как показано на рисунке 7, и приведены в таблице 6.

Рисунок 7 - Структура сообщений CSBK, передаваемых АС

в восходящем рабочем канале

Таблица 6

Перечень служебных сообщений CSBK, передаваемых АС

в восходящем направлении рабочего канала

Тип сообщений	Обозначение	Назначение PDU	Описание
Произвольный доступ	P_RAND	Асинхронный режим доступа	Запросы асинхронного режима доступа
Подтверждения	P_xACKU	Подтверждения	Ответ на PDU от ТС, со следующими типами: P_ACKU, P_NACKU,
Обслуживание	P_MAINT	PDU обслуживания вызова	Разъединение

7 Процедуры транкинговой передачи

7.1 Базовая структура

7.1.1 Структура каналов

7.1.1.1 TSCC, регулирующий доступ АС с постоянной передачей на радиочастоте

Для доступа к транкинговой сети АС должна использовать TSCC. ТС для управления доступом АС к транкинговой сети должна организовать один канал, который будет использоваться в качестве TSCC. ТС также может иметь один дополнительный (альтернативный) TSCC.

TSCC предназначен для предоставления следующих услуг:

а) для управления и контроля доступа к каналу АС способом произвольного доступа;

б) обработки запросов на выполнение услуг, направленных абонентским станциям или полученным от АС, а также, опционально, направленных внешним пользователям, подключенным к сети ППР (например, через шлюз) или полученным от них;

в) выделения ресурсов для передачи пользовательской информации (пользовательских вызовов);

г) передачи служебной системной информации к АС;

д) управления определением местоположения АС с помощью ее регистрации в сети;

е) предоставления таких услуг, как опрос коротких данных и передача коротких данных с использованием процедуры UDT.

7.1.1.2 TSCC в асинхронном режиме

В этом режиме работы TSCC у АС должен быть настроен режим доступа к каналу с использованием основных правил доступа к каналам, описанных в ГОСТ Р 71586.1-2024 (пункт 7.3.1).

В асинхронном режиме работы TSCC персональными настройками АС должна быть разрешена передача в восходящем TSCC сигнализации "активация/включение ТС" в соответствии с требованиями "активация/включение ретранслятора", описанными в ГОСТ Р 71586.2-2024 (подпункт 13.1.1.2). После активации TSCC (включения канала) ТС начинает радиопередачу в нисходящем направлении. После активации TSCC АС должна синхронизироваться с ним. При активации TSCC в PDU передается служебное сообщение, разрешающее асинхронный доступ к TSCC.

Нисходящий канал должен быть активирован в одном TDMA-канале для использования в качестве TSCC и передавать Aloha (приветствие) и/или широковещательные служебные сообщения блоками PDU в соответствии с процедурами асинхронного режима доступа, указанными в настоящем стандарте.

ТС должна иметь таймер T_BS_Inactive (время контроля активности TSCC), который ограничивает время работы TSCC в асинхронном режиме при отсутствии запросов доступа от АС в восходящем канале. Таймер T_BS_Inactive должен быть запущен ТС при отсутствии радиопередачи в восходящем TSCC. Если время таймера T_BS_Inactive истекает, то ТС в соответствии с ГОСТ Р 71586.2-2024 (пункт А.2.3) должна перейти в состояние Hibernating и прекратить радиопередачу в нисходящем TSCC (отключить канал).

7.1.1.3 Структура TSCCAS

Один из физических каналов (радиочастота) может поддержать TSCC в одном логическом канале и TSCCAS - в другом логическом канале (другом таймслоте).

Если на одной радиочастоте поддерживаются TSCC и TSCCAS, то в служебных широковещательных сообщениях в TSCC должно сообщаться о возможностях TSCCAS для АС. В режиме ожидания АС, которые поддерживают прием обоих типов каналов (как TSCC, так и TSCCAS), должны контролировать оба типа каналов.

7.1.2 Требования к определению номинала радиочастот и логических каналов для передачи пользовательской информации

Для обеспечения возможности переназначения радиочастот ТС должна поддерживать два типа частотных планов, определяющих номинал частоты физического канала:

- фиксированный частотный план каналов ТС;

- гибкий частотный план каналов ТС.

Номиналы используемых конкретных радиочастот, установленных при производстве ТС, должны быть разрешенными в местах развертывания транкинговой сети.

ТС должна иметь возможность работы в выделенных полосах радиочастот или на фиксированных частотах.

ТС должна обеспечить выделение используемого номинала частоты физического радиоканала в соответствии со следующими правилами:

а) фиксированным планом логического канала, в соответствии с которым частота работы передатчика и приемника ТС (пары частот нисходящего и восходящего радиоканала) жестко закреплена идентификатором внутри сети и передается в IE CHAN. Общая емкость пар частот определяется CHAN и должна иметь максимальное значение до 4094 таких логических/физических пар, и/или

б) способом определения номинальных пар дискретных радиочастот, связанных с логическим номером канала (от 1 до 4094), посредством которого частоты передатчика и приемника ТС (пары частот нисходящего и восходящего радиоканала) указаны в IE блоков PDU, передаваемых между объектами сети по радиоинтерфейсу. Такой способ определения дискретных частот приема и передачи используется в случаях, когда частотный разнос неодинаков. Примеры таких пар частот:

1) частота передачи равна 450,125 МГц, а приема - 460,625 МГц;

2) частота передачи равна 425,375 МГц, а приема - 415,174 МГц, и т.д.

Примечание - Вариант определения номинала частоты радиоканала, указанный в пункте "б", имеет недостаток перед вариантом, указанным в пункте "а", так как объем информации, которая должна быть передана между объектами, больше. Перераспределенные номиналы частот физических и логических каналов для АС могут быть переданы служебными сообщениями с помощью TSCC.

Требования к распределению логических каналов на физических радиочастотах содержатся в приложении В.

7.1.3 Разделение АС по группам для доступа в транкинговую сеть

При планировании транкинговой сети для рационального использования ее ресурсов доступ к ТС всей совокупности радиостанций может быть разделен на группы, с привязкой каждой из них к разным TSCC или к разным транкинговым станциям.

Для разделения АС на группы в служебных сообщениях, передаваемых в TSCC, при адресации используются специальные IE, которые могут быть направлены TSCC и применимы только к конкретной АС или группе АС. Примерами таких служебных сообщений являются Aloha (C_ALOHA PDU) и Broadcast (C_BCAST PDU), которые содержат служебную информацию размером 24 бита об индивидуальном адресе АС и 5 бит (IE "Маска"), используемые для определения групп радиостанций. Разделение всех АС на группы достигается за счет использования спецификатора/определителя адреса ("Маски"), передаваемого в служебном сообщении в одноблочном или многоблочном PDU. Этот параметр указывает АС на то, что необходимо сравнить младшие биты его индивидуального адреса с младшими битами передаваемого числового значения в IE "Маска" адресного поля PDU, содержащего этот элемент, чтобы определить, применим ли данный PDU к АС.

IE "Маска" определяет совокупность АС, для которых предназначен (применим) данный PDU. PDU применим к АС, если младшие биты, передаваемые в IE "Маска" адреса служебного сообщения Aloha, соответствуют младшим битам "Маски" индивидуального адреса АС.

Таким образом, вся совокупность АС транкинговой сети может быть разделена на две части по "Маске":

- если "Маска" = 0₂, то нет совпавших битов адреса, а значит, что нет разделения АС на группы и сообщение может быть применимо для всех АС в зависимости от их индивидуального адреса;

- если "Маска" = 1₂, то этот PDU должен рассматриваться как применимый к данной АС только в том случае, если младший значащий бит индивидуального адреса АС соответствует/совпал с младшими значимыми битами индивидуального адреса из полученного PDU.

Разделение на группы может быть реализовано до максимального значения "Маски", равного 24₁₀. В этом случае PDU применим только к одной АС, индивидуальный адрес которой совпадает с адресом в служебном сообщении.

На рисунке 8 представлен пример PDU АС с индивидуальным адресом 0000 0000 0010 1010 0001 1001₂, содержащий IE "Маска".

Рисунок 8 - Пример PDU, содержащего IE "Маска"

Получен PDU, который содержит IE "Маска". Таким образом, АС должна определить, применим PDU или нет.

Примеры

1 IE "Маска" содержит значение 0 0100₂. Значение "Маски" - 4, поэтому АС сравнивает 4 младших бита поля адреса, полученного PDU с 4 младшими битами индивидуального адреса АС.

Младшие 4 бита сравниваются, как показано на рисунке 9.

Рисунок 9 - Сравнение 4 младших бит адреса, полученного PDU,

и индивидуального адреса АС (вариант, когда PDU применим)

Если биты совпадают, то PDU применим для этой конкретной АС (если элемент "Маска" имел любое другое значение от 0 до 4, то PDU по-прежнему будет применим).

2 IE "Маска" содержит значение 0 0101₂. Значение "Маски" - 5, следовательно, АС сравнивает 5 младших бит IE адреса в полученном PDU, с 5 младшими битами индивидуального адреса АС.

5 младших бит сравниваются, как показано на рисунке 10. В этом случае биты НЕ совпадают, а значит, этот PDU не должен быть применим к данной конкретной АС (если "Маска" имела любое значение от 5 до 24, то PDU по-прежнему не применим).

Рисунок 10 - Сравнение 5 младших бит адреса, полученного PDU

и индивидуального адреса АС (вариант, когда PDU не применим)

7.2 Процедуры произвольного доступа

7.2.1 Общие положения

Способ произвольного доступа АС предполагает, что АС может передавать запросы доступа к каналу (общей среде передачи) в случайные моменты времени.

Из-за случайности моментов времени, в которые АС могут решить начать передачу, не исключена возможность того, что две или несколько АС могут выйти на связь в пересекающиеся промежутки времени. Это приводит к столкновениям (коллизиям), которые сначала должны быть распознаны, а затем разрешены с помощью TSCC.

Произвольный доступ должен осуществляться в соответствии с правилами протокола соединения по запросу, который основан на "разделенных приветствиях" и обеспечивает:

- контроль столкновений (коллизий) одновременных попыток произвольного доступа от разных АС к TSCC;

- управление произвольным доступом самим TSCC, чтобы свести к минимуму задержки доступа;

- обеспечение стабильности работы транкинговой сети при увеличении нагрузки и вероятности возникновения коллизий;

- поддержку оптимальной пропускной способности при большом трафике.

Произвольный доступ - это единственный метод, который разрешен для АС, а регулирование процесса использования ресурсов ТС должно производиться с помощью TSCC.

При инициации произвольного доступа АС к асинхронному TSCC, если он выключен, АС сначала активирует TSCC. После включения (активации) TSCC в его нисходящем направлении должны передаваться служебные сообщения, которые регулируют процесс доступа для АС.

7.2.2 Принципы произвольного доступа

7.2.2.1 Основные принципы произвольного доступа

Условные цветовые обозначения, использованные в разделах описания процедур произвольного доступа, приведены на рисунке 11.

	Таймслот, доступный для произвольного доступа		PDU, содержащее back-off параметр N в нисходящем канале
	Изъятый таймслот, произвольный доступ запрещен
			PDU, требующий ответа, т.е. исключающий следующие TDMA-кадры (след. кроме одного)
	PDU, переданное АС по восходящему каналу

Рисунок 11 - Условные обозначения, используемые в рисунках

при описании процедур произвольного доступа

Расположение на временной оси таймслотов и TDMA-кадров показано на рисунке 2.

Служебные сообщения с использованием PDU, передаваемые ТС по TSCC в нисходящем направлении, должны быть разделены на PDU, которые разрешают произвольный доступ (например, Aloha), и PDU, которые запрещают произвольный доступ. Запрет произвольного доступа производится для исключения коллизий при ожидании ответа от запрошенной АС в восходящем направлении TSCC и одновременных радиопередач в этом же таймслоте с запросами произвольного доступа от других АС. С целью обеспечения

интервала (таймслота), гарантированно свободного для получения ответа от запрошенной АС, используются PDU "изъятия" одного или более таймслотов, как описано в 7.2.2.2 ("Изъятие таймслотов произвольного доступа").

7.2.2.2 Управление произвольным доступом АС

TSCC в нисходящем направлении предназначен для обеспечения доступа АС, управления и контроля использования ресурсов ТС.

Для управления асинхронным режимом доступа АС к TSCC используется PDU на уровне 3 стека протокола C_ALOHA PDU, который содержит три IE "Random Backoff", "Маска" и Service Function ("Функция обслуживания для управления и контроля с произвольным доступом"). Существуют и другие служебные сообщения, передаваемые с помощью блоков PDU в TSCC, которые также содержат IE "Random Backoff".

Все АС могут в любой момент времени инициировать запрос к ТС на предоставление требуемых им услуг путем запроса асинхронного доступа. Для осуществления попытки АС получить доступ к ТС она должна посылать служебное сообщение с запросом на обслуживание с помощью произвольного доступа с использованием PDU до тех пор, пока:

- доступ не будет запрещен IE "Маска" [см. 7.2.2.2 ("Разделение АС на группы")];

- доступ не будет запрещен с помощью сервисной функции [см. 7.2.2.2 ("Проверка поддерживаемых услуг Service Function")];

- выбранный таймслот не изъят из произвольного доступа [см. 7.2.2.2 ("Изъятие таймслотов произвольного доступа")].

Разделение АС на группы

Служебные сообщения, использующие блоки PDU C_ALOHA, содержат IE с адресом и IE "Маска". Таким образом, применяется процедура, описанная в 7.1.3.

АС должна принимать в нисходящем направлении TSCC информацию о разделении передаваемых служебных сообщений в PDU Aloha для различных групп АС и применимости полученного служебного сообщения для данной АС. АС использует полученную служебную информацию для получения или запрета доступа к ресурсам ТС. При попытке произвольного доступа АС должна проверить, разрешается ли ей доступ к ресурсам ТС в соответствии с разделением на группы с помощью значения, передаваемого в IE "Маска", и значения "Адрес", передаваемого в IE "Адреса" PDU Aloha. Для "Маски" с численными значениями от 0 до 24 PDU применим к АС, если младшие биты "Маски" адреса PDU Aloha совпадают с младшими битами "Маски" его индивидуального адреса.

Такое правило доступа АС применяется для последующих кадров TDMA, передаваемых блоками PDU, которые не содержат IE "Маска", до обновления или изменения следующим PDU Aloha.

Таким образом, все АС, которые могут послать запрос произвольного доступа к ресурсам ТС, подразделяются на 2^Mask подмножеств по значению, передаваемому в IE "Маска":

- если "Маска" = 0, то запрос на произвольный доступ к ресурсам ТС применим для всех АС, нет разделения АС на группы (обычная ситуация при нормальном объеме передаваемых сообщений) и сообщение может быть применимо для всех АС в зависимости от их индивидуального адреса;

- если "Маска" = 1, то отправить запрос произвольного доступа неэкстренного типа могут только АС, младшие биты индивидуального адреса которых совпадают с младшими битами передаваемого адреса в PDU Aloha. Таким образом, все АС на сети могут быть разделены на две группы;

- разделение на группы может быть продолжено до числового значения, передаваемого в IE "Маска" и равного 24. В этом случае только одной АС должна быть разрешена реализация попытки произвольного доступа (если АС не запросила экстренную/вспомогательную службу, после чего она может сделать случайную попытку доступа для всех значений "Маски", кроме значения 24).

Когда АС становится активной в TSCC, в том числе при возврате АС из рабочего канала, она должна либо предположить, что совокупность АС не разделена (т.е. что последний PDU C_ALOHA был применим ко всем АС), либо дождаться PDU C_ALOHA перед попыткой произвольного доступа.

Проверка поддерживаемых услуг Service Function

Для запросов на обслуживание, за исключением чрезвычайных ситуаций:

- каждая АС должна принимать передаваемые значения в IE Service Function служебного сообщения PDU C_ALOHA. АС не должна передавать сообщения для произвольного доступа, произвольный доступ для АС разрешен не для всех услуг и не совпадает с типом запрашиваемой услуги, предложенным IE Service Function;

- Service Function должен использоваться до тех пор, пока он не обновляется очередным PDU C_ALOHA.

Для аварийных запросов АС не требуется проверять значения IE Service Function.

Значения IE Service Function приведены в таблице 7.

Таблица 7

Значения IE Service Function

Значение	Описание
00₂	Произвольный доступ разрешен для всех услуг
01₂	Произвольный доступ предлагается для услуг, требующих рабочего канала. Произвольный доступ предлагается для регистрационных запросов
10₂	Произвольный доступ предлагается для услуг, не требующих рабочего канала. Произвольный доступ предлагается для регистрационных запросов
11₂	Произвольный доступ предлагается только для регистрационных запросов

Изъятие таймслотов произвольного доступа

TSCC должен передавать PDU (состоящие из CSBK, MBC или MBC на базе механизма передачи сообщений без подтверждения их получения UDT) в нисходящем направлении TSCC, который запрашивает ответ от указанной АС. Ответ АС должен направляться в TDMA-кадре, следующем за последним блоком служебного сообщения, передаваемым в TSCC PDU. Для того чтобы предотвратить коллизию между запрошенным ответом и передачей от другой АС запроса произвольного доступа, TSCC изымает этот таймслот, тем самым запрещая любые передачи произвольного доступа в нем. Для запрета передачи должен быть использован бит AT (см. 15.4.4), передаваемый в CACH, чтобы указать всем АС, что следующий таймслот изъят. Такая установка бита AT позволяет АС, которая намеревается передать в заданном таймслоте свой PDU с запросом произвольного доступа по случайному принципу, по значению бита в CACH убедиться, что выбранный временной интервал не был изъят и передача запросов в нем произвольного доступа не запрещена.

На рисунке 12 показан пример, когда в нисходящем направлении TSCC был передан запрос с использованием USBD PDU, и в следующем таймслоте после приема этого служебного сообщения с запросом ожидается ответ от АС. Для гарантии получения ответа от АС путем предотвращения коллизий, вызванных возможными служебными сообщениями, отправляемыми от других АС, этот таймслот изымается (помечается TSCC как "занятый").

	PDU, предлагающий произвольный доступ		Сообщение, требующее ответа от АС с индивидуальным адресом
	Таймслот, доступный для произвольного доступа		Изъятый таймслот, произвольный доступ запрещен

Рисунок 12 - Пример изъятия таймслотов

В TSCC должны передаваться следующие информационные сообщения с помощью PDU, разрешающие произвольный доступ:

а) PDU Aloha разрешают произвольный доступ <1>. Поэтому АС разрешено передавать служебные сообщения с использованием PDU произвольного доступа. CACH, следующий после каждого PDU Aloha, устанавливает бит AT в значение 0₂. Служебные сообщения PDU Aloha никогда не изымают таймслотов, кроме случая служебного сообщения PDU Aloha с "Маской", равной 24, и АС с адресом ADRNULL, при котором должен быть принудительно запрещен произвольный доступ, даже если таймслот не изъят;

--------------------------------

<1> Другие блоки PDU также разрешают произвольный доступ.

б) TSCC для требующих ответа служебных сообщений с использованием PDU должен устанавливать сразу после их передачи в CACH бит AT в значение 1₂. Таким образом, следующий таймслот, помеченный на рисунке 12 как "Ответ от АС(Б) к ТС", указывается как занятый и становится недоступным ("изымается") для запросов произвольного доступа от АС. В этом случае TSCC освобождает один указанный таймслот, так как PDU со служебным сообщением к АС(Б) требует ответа от этой АС в восходящем канале ТС;

в) АС(Б) передает служебное сообщение PDU с подтверждением;

г) если таймслот, выбранный для произвольного доступа в случайном порядке, не доступен, так как изъят, то АС должна выбрать другой таймслот для последующей попытки произвольного доступа с использованием случайных процедур Backoff, указанных в 7.2.2.2 ("Метод Random Backoff").

Ответы в нисходящем направлении TSCC на попытки произвольного доступа от АС

После получения служебного сообщения с PDU запроса произвольного доступа в нисходящем направлении TSCC должен быть отправлен ответ. Ответы, отправляемые TSCC, указаны в описании процедуры регистрации и обработки вызовов. Ответ может быть послан в TDMA-кадре, следующем за PDU произвольного доступа, или позже (может быть задержан). TSCC должен использовать IE NRand_Wait в последнем передаваемом служебном сообщении C_ALOHA PDU, чтобы указать задержку (в TDMA-кадрах). АС должны подождать, прежде чем выбрать другой таймслот с использованием случайного таймера отсрочки передачи для повтора попытки произвольного доступа.

Отметка о задержке ответа

АС получает параметр задержки для таймера задержки NRand_Wait из каждого C_ALOHA PDU, который она использует в соответствии с таблицей 8. Параметр задержки указывает на количество TDMA-кадров NWait, на которые может быть отложен ответ TSCC на PDU произвольного доступа. Если NWait = 0, то это означает, что ответ ожидается АС без задержки в следующем после PDU случайного доступа TDMA-кадре. В начале сеанса, до получения Aloha PDU, АС устанавливает значение параметра задержки NWait по умолчанию соответствующего NDefault.

Таблица 8

Системные задержки ответа, указанные параметром задержки

NRand_Wait

NRand_Wait	NWait (TDMA-кадры)
0	0
1	1
2	2
3	3
4	4
5	5
6	6
7	7
8	8
9	9
10	10
11	11
12	12
13	13
14	15
15	24

Метод Random Backoff

При увеличении нагрузки увеличивается и вероятность коллизий, что может привести к возможной неустойчивости работы транкинговой сети. Метод Random Backoff определяет время попыток получения запросов произвольного доступа случайным образом от АС в восходящем направлении TSCC. Для управления произвольным доступом TSCC в нисходящем направлении передает значение таймера Random Backoff, указанное в TDMA-кадрах.

Когда АС инициирует вызов, она должна послать первый запрос с использованием PDU произвольного доступа в следующем

интервале, в зависимости от "Маски", функции обслуживания, времени и факта изъятия таймслота, указанных в 7.2.2.2 ("Метод Random Backoff") в перечислениях а), б) и в).

АС должна вызывать Random Backoff, если:

а) АС не может осуществить попытку произвольного доступа, поскольку доступ запрещен "Маской";

б) АС не может осуществить попытку произвольного доступа, поскольку доступ запрещен с помощью сервисной функции;

в) АС не может осуществить попытку произвольного доступа, так как таймслот был изъят;

г) АС пыталась осуществить попытку произвольного доступа, но эта попытка оказалась неудачной (в TSCC в нисходящем направлении нет ответа до истечения срока действия таймера с параметрами NRand_Wait).

Если АС осуществляет попытку произвольного доступа, и она оказывается неудачной [перечисление г)], то АС должна выбрать таймслот для своей следующей попытки произвольного доступа путем выбора случайного числа в диапазоне от единицы и до значения числа, полученного с помощью статистически равновероятного закона распределения.

На рисунке 13 показана диаграмма работы TSCC с использованием параметров NRand_Wait, установленного в значение 0. Самая последняя величина отсрочки равна 4.

Примечания

1 Во

интервале, обозначенном как сообщение (А), АС совершает попытку асинхронного доступа. NRand_Wait, установленный в значение 0, указывает на то, что в нисходящем направлении TSCC ответ будет в следующем TDMA-кадре в (Б).

2 После TDMA-кадра (Б) ответ не был получен, поэтому АС случайным образом выбирает один из таймслотов 1, 2, 3, 4 для следующей попытки доступа.

Рисунок 13 - Random Backoff (параметр NRand_Wait = 0)

На рисунке 14 показана диаграмма работы TSCC с использованием NRand_Wait, установленного в значение 1. Самая последняя величина отсрочки равна 4.

Примечания

1 АС совершает попытку произвольного доступа. NRand_Wait, установленный в значение 1, указывает на то, что в нисходящем направлении TSCC ответ будет в одном из следующих двух TDMA-кадров, обозначенных как "Б".

2 После TDMA-кадра "Б" ответ не был получен, поэтому АС выбирает один из таймслотов 1, 2, 3, 4 случайным образом для следующей попытки доступа.

Рисунок 14 - Random Backoff (параметр NRand_Wait = 1)

Ряд блоков PDU нисходящего направления TSCC, включая PDU ALOHA, содержит IE Backoff.

Примечание - Будущие версии стандарта могут определять сообщения CACH, которые содержат этот IE.

Время попыток произвольного доступа случайным образом по методу Random Backoff может быть изменено путем передачи сообщений в нисходящем направлении TSCC и транслироваться на АС в ответ при различной загрузке TSCC и рабочих каналов с пользовательским трафиком при эксплуатации. Если загрузка TSCC и рабочих каналов небольшая, то потери производительности будут небольшими, поэтому случайные задержки асинхронного доступа уменьшаются. Если объем передаваемой информации увеличивается, то ТС должны быть введены более продолжительные задержки для распределения конкурирующих попыток произвольного доступа от разных АС через восходящее направление TSCC. Этот объем трафика может быть оценен на основе имеющегося опыта эксплуатации или может быть вычислен исходя из количества пакетов данных, поступающих в данное время.

Параметр Random Backoff может изменяться, когда АС пытается осуществить попытку случайного доступа. Если АС выбрала случайный таймслот, то он должен сохраняться в течение времени текущей попытки доступа в асинхронном режиме. Любое новое значение параметра для таймера отсрочки TSCC должно быть использовано, если АС должна случайно выбрать новый таймслот для своей следующей попытки асинхронного доступа.

Для блоков PDU, которые содержат IE Backoff, определенному количеству отсроченных TDMA-кадров (Backoff TDMA-кадры) присваивается номер Backoff. Таким образом может быть реализовано больше отсрочек TDMA-кадров, чем это позволило бы двоичное представление. Точное количество Backoff TDMA-кадров в зависимости от номера Backoff приведено в таблице 9.

Таблица 9

Количество Backoff TDMA-кадров в зависимости

от номера Backoff

Номер Backoff	Backoff TDMA-кадры
0	R
1	1
2	2
3	3
4	4
5	5
6	8
7	11
8	15
9	20
10	26
11	33
12	41
13	50
14	70
15	100

Следует обратить внимание, что:

а) служебное сообщение C_ALOHA PDU с M = 24 разрешает доступ только одной конкретной индивидуальной АС;

б) в примере, приведенном на рисунке 12, если АС выбрала для попытки доступа в асинхронном режиме таймслот, помеченный как "изъятый", то она, проанализировав бит AT, передаваемый в CACH, определяет, что этот таймслот исключен из доступа. АС не должна в этом случае делать попытку произвольного доступа, она должна выбрать другой таймслот с учетом случайного параметра отсрочки передачи;

в) АС должна учитывать значение бита AT, чтобы определить, не изъят ли следующий таймслот асинхронного доступа. Если АС не может получить предшествующий бит AT, то она устанавливает для себя, что таймслот изъят.

Решение о повторных попытках и времени запросов

После отправки PDU произвольного доступа АС должна ждать ответ в нисходящем направлении TSCC. В качестве ответа на запрос произвольного доступа могут быть приняты различные блоки PDU (как указано в пунктах, описывающих процедуры регистрации и обработки вызовов).

АС должна отказаться от своей попытки произвольного доступа, если она отправила максимальное разрешенное количество запросов на получение произвольного доступа для конкретной запрашиваемой услуги и не получила положительного ответа. Это количество запросов зависит от службы и запрашиваемого приоритета обслуживания:

- для неаварийных запросов произвольного доступа определено значение NRand_NR;

- для аварийных запросов произвольного доступа определено значение NRand_NE.

АС должна также использовать таймер TRand_TCh, который определяет максимальное время ожидания получения произвольного доступа, и отказаться от попытки, если это время истечет.

Если попытка произвольного доступа не удалась в результате истечения времени TRand_TCh, то в этих случаях:

а) если АС не передала PDU, она должна вернуться в исходное состояние (и может указать пользователю на неспособность установить соединение);

б) в противном случае (АС предприняла по крайней мере одну попытку произвольного доступа) если время таймера TRand_TCh истекает в период времени, когда АС ожидает NWait плюс один TDMA-кадр для последней попытки произвольного доступа, то АС дождется завершения NWait плюс один TDMA-кадр, прежде чем отказаться от своей очередной попытки случайного доступа.

SDL произвольного доступа (неэкстренные сообщения) для АС (см. 7.2)

На рисунках 15 - 17 показаны неэкстренные SDL-процедуры произвольного доступа.

Рисунок 15 - SDL-процедура произвольного доступа

Рисунок 16 - SDL-процедура произвольного доступа

Рисунок 17 - SDL-процедура произвольного доступа

Диаграммы SDL для произвольного доступа аварийных вызовов АС

На рисунках 18 - 20 показаны SDL-процедуры произвольного доступа при аварийных ситуациях, как это определено в 7.2.2.

Рисунок 18 - SDL-процедура произвольного доступа

в аварийных ситуациях

Рисунок 19 - SDL-процедура произвольного доступа

в аварийных ситуациях

Рисунок 20 - SDL-процедура произвольного доступа

в аварийных ситуациях

7.2.2.3 Действия после получения подтверждения

АС не должна повторно передавать любой последующий PDU произвольного доступа, когда в нисходящем направлении TSCC было получено соответствующее подтверждение. Различные блоки PDU, которые принимаются в дополнение к специальным PDU подтверждения, указаны в процедурах, описанных в настоящем стандарте. Положительный ответ в нисходящем TSCC на запрос произвольного доступа должен запустить таймер АС. Этот таймер может быть перезапущен дополнительным PDU подтверждения в нисходящем направлении TSCC. Для этого таймера указаны два значения. Первое значение TP_Timer должно использоваться, если услуга асинхронного режима доступа требует предоставления рабочего канала для передачи полезной нагрузки. Второе значение TNP_Timer должно использоваться для служб, которые используют только TSCC (например, для служб регистрации или коротких данных).

7.2.2.4 Доступ АС к TSCC

Регулирование доступа к каналу для транкинговых систем, определяемых настоящим стандартом, осуществляется с помощью TSCC, обеспечивающего передачу сигнализации в нисходящем канале с PDU, определяющими порядок доступа к каналу. Кроме того, в процедурах регулирования доступа к каналу в качестве идентификатора сети применяется CC, предназначенный для исключения помех в соседнем канале используемого радиочастотного диапазона.

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

В транкинговой системе настоящего стандарта физические каналы назначаются автоматически, следовательно, АС и ТС должны знать и согласовать, какой CC выделяется для каждого физического радиоканала. Для этого могут быть использованы следующие варианты:

а) CC по умолчанию - 0000₂. Если CC не был назначен специально или передан в нисходящем направлении TSCC в расширенном PDU назначения канала, либо в расширенном Move PDU, то CC должен быть установлен по умолчанию;

б) АС может содержать список логических номеров каналов и соответствующие им заданные CC (см. приложение В);

в) АС определяет CC, переданный в нисходящем направлении TSCC. Этот CC должен также быть использован в рабочих каналах, выделяемых TSCC, если иной CC не передается в расширенном PDU назначения канала или расширенном Move PDU.

Когда рабочий канал активен, ТС в TSCC должна исключать любые PDU, поступающие в восходящем направлении TSCC, если они имеют несовпадающий CC.

АС должна сначала дождаться получения IE CC. Если CC, передаваемый в нисходящем направлении TSCC, имеет значение, равное 0000₂, то АС должна пропустить проверку CC и проверить C_SYScode, как указано в 7.2.2.4, перечисление б). Если CC, передаваемый TSCC, имеет значение, отличное от 0000₂, то АС должна проверить, что этот конкретный канал передачи CC соответствует одному из вариантов, указанных в настоящем подразделе.

Затем АС должна ждать получения C_SYScode, передающегося по TSCC. Если АС разрешен доступ к этим TSCC, она должна ждать положительного PDU C_ALOHA и обновления активных временных настроек в соответствии с информацией, отправленной в нисходящем направлении TSCC для получения асинхронного режима доступа, определенного выше в данном разделе.

7.3 Получение и удержание TSCC

7.3.1 Общие положения

Если рабочий канал не назначен (в том числе и сразу после включения), АС должна пытаться найти TSCC, соответствующий выбранной для работы сети. Поиск TSCC может быть выполнен с помощью общего поиска во всех возможных каналах или путем использования параметров TSCC, хранящихся в АС. Порядок поиска TSCC АС описан в приложении Г.

АС не должна производить никаких передач в восходящем направлении TSCC, если она не активна на этом канале. АС не должна начинать передачу, пока не получит C_SYScode, который разрешает АС получить доступ к этому TSCC.

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

- способ, с помощью которого АС осуществляет поиск соответствующего TSCC;

- критерии, которым должен соответствовать TSCC исходя из разрешений АС;

- процедуры для возврата к процессу обнаружения TSCC.

Настоящим стандартом предусмотрены различные варианты построения TSCC, как выделенных, так и невыделенных.

Выбор типа TSCC должен быть осуществлен на этапе проектирования транкинговой сети с учетом различных факторов, в том числе:

а) получение для АС TSCC с возможными краткосрочными перебоями [затухание в радиоканале и многолучевой прием (multi-path)];

б) долгосрочные перебои в приеме TSCC, в течение которых соответствующий TSCC не может быть получен АС (невыделенные TSCC или перемещение АС вне зоны радиопокрытия сети связи);

в) расположение на такой территории, где возможно получение АС более одного TSCC от выбранной сети;

г) получение сообщений об освобождении TSCC;

д) получение сообщений об освобождении или потеря доступа к TSCC в результате перераспределения сетевой нагрузки;

е) получение инструкций для перехода на другой TSCC с помощью служебного сообщения Vote Now (анонсирование сетевой системы).

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

Настоящим стандартом предусмотрены процедуры, описывающие требования к АС по периодическому опросу соседних ТС для поиска TSCC, которые могут обеспечить улучшенный уровень обслуживания для пользователей АС. Это достигается путем передачи по TSCC служебного сообщения с указанием всем АС прекратить использование TSCC. В течение этого времени TSCC может прекратить вызовы. Производители могут разрабатывать свои собственные процедуры, которые позволят АС оставить текущий TSCC и осуществить поиск альтернативного TSCC. Вместе с тем следует учитывать, что если АС освобождает TSCC, то она может пропустить передаваемые в TSCC служебные сообщения.

7.3.2 Параметр АС Volatility

При выключении АС должна сохранить в своей внутренней памяти параметры используемой транкинговой сети в соответствии с таблицей 10.

Параметры АС, касающиеся выбранной сети и не перечисленные в таблице 10, при выключении АС не сохраняются.

Таблица 10

АС Параметр Volatility для обнаружения и удержания TSCC

Параметр	Подпункт или приложение настоящего стандарта	Не изменяется в процессе персонализации АС. Сохраняется после выключения АС	Изменяется в процессе операций и сохраняется после выключения АС	Изменяется в процессе операций и стирается после выключения АС
MODEL	7.3.3.3 ("Проверка кода идентификации системы")	X	-	-
NET	7.3.3.3 ("Проверка кода идентификации системы")	X	-	-
DMRLA	7.3.3.3 ("Проверка кода идентификации системы")	X	-	-
Категория АС	7.3.3.3 ("Управление категориями радиомодулей")	X	-	-
Данные обнаружения авторизации	7.3.3.3 ("Процедура авторизации TSCC")	X <1>	-	-
Список поиска логического канала	Приложение В	X	-	-
Дополнения к списку поиска из полученных уведомлений	16.3.20.2	-	X	-
Любые неперечисленные (неуказанные) параметры	-	-	-	X
<1> Длина данных авторизации зависит от параметра MODEL: очень большая - 10 бит, большая - 8 бит, маленькая - 5 бит, минимальная - 3 бита.

7.3.3 Процедуры обнаружения TSCC

7.3.3.1 Этапы обнаружения TSCC

Процедура обнаружения TSCC должна состоять из этапов проверки C_SYScode (верификации), передаваемых в служебных сообщениях TSCC в нисходящем направлении и, в случае успешной проверки и измерения АС качества сигнала, с последующим подтверждением, как показано на рисунке 21.

Рисунок 21 - Этапы проверки и подтверждения

7.3.3.2 Процедуры получения доступа АС к TSCC

Для получения доступа к ресурсам ТС АС, которой не назначен рабочий канал, должна выполнить процедуру получения доступа к TSCC.

Эта процедура обеспечивает поиск каналов - кандидатов на роль TSCC и направление от АС запросов доступа к TSCC путем авторизации АС на выбранном TSCC. Результатом запросов доступа (авторизации) к TSCC является решение ТС о том, имеет ли АС право стать активной в выбранном TSCC.

АС производит выполнение процедуры получения доступа к TSCC в следующих случаях:

а) включение АС;

б) смена выбранной сети, инициированная пользователем;

в) отказ от текущего TSCC в соответствии с процедурами, указанными в 7.3.4;

г) получение соответствующих служебных сообщений P_CLEAR PDU в рабочем канале;

д) посылка PDU отключения P_MAINT (Maint_Kind соответствует DISCON) или истечение времени на радиочастоте рабочего канала;

е) получение на радиочастоте рабочего канала PDU P_AHOY с указанием освободить этот физический канал (IE Service_Kind установлен в значение 1111₂, что означает отмену услуг обработки вызовов).

На протяжении всей процедуры получения TSCC микрофон АС должен быть выключен, радиопередача производиться не должна.

Порядок поиска TSCC приведен в приложении Г.

7.3.3.3 Процедура определения TSCC - кандидата

Определение TSCC - кандидата

При поиске подходящего TSCC АС должна проверять каждый выбранный канал на соответствие его структуре TSCC. АС должна принимать в качестве кандидата на TSCC любой канал, на котором обнаружена SYNC-последовательность TSCC.

Метод, с помощью которого АС во время поиска идентифицирует кандидатов на TSCC, в настоящем стандарте подробно не описан. В частности, не определено максимально допустимое время для этой процедуры, хотя обращается внимание на необходимость завершения проверки как можно быстрее, особенно на каналах, которые могут быть легко отвергнуты в качестве кандидатов на TSCC (например, из-за наличия ошибочных параметров от C_SYScode), так как в целом скорость поиска (и, таким образом, эффективность обслуживания пользователя) зависит от скорости, с которой выполняются эти проверки.

Проверка кода идентификации системы

При определении АС кандидата на TSCC она должна проверить значения полей C_SYScode из PDU TSCC, которые содержат этот IE.

Время, которое АС может затратить на поиск значения IE C_SYScode, не определено, так как это зависит от регулярности, с которой TSCC передает в нисходящем направлении PDU, содержащие IE C_SYScode. Следует отметить, что основные параметры C_SYScode для поиска TSCC передаются также в CACH.

Когда АС выбрала IE C_SYScode для проверки, она должна определить, может ли она работать с этим TSCC [см. 7.3.3.3 ("Процедура авторизации TSCC")]. Если это возможно, то АС должна попытаться получить доступ к указанному TSCC и начать процедуры проверки качества сигнала, указанные в 7.3.3.4.

Для получения доступа АС к TSCC после проверки качества сигнала и до подтверждения АС не должна передавать никакие PDU с запросом доступа любого типа. Но по мере необходимости АС должна исполнять любые полученные и применимые к ней PDU (при условии, что ей не потребуется передача PDU с запросом по TSCC).

Структура кода идентификации системы (C_SYScode)

Транкинговые сети ППР настоящего стандарта могут представлять собой архитектуры от небольших систем, состоящих из малого числа сайтов, до очень больших систем, охватывающих обширный географический район. Чтобы обслуживать такой широкий диапазон сетей, настоящий стандарт определяет четыре сетевые модели, каждая из которых обладает соответствующими характеристиками, представленными в таблице 11.

Таблица 11

Сетевая модель

Сетевая модель	Кодировка/шифр модели	Номера сетей	Количество сайтов в сети	DMRLA
Минимальная	00₂	512	8	от 0 до 3
Маленькая	01₂	128	32	от 0 до 5
Большая	10₂	16	256	от 0 до 8
Очень большая	11₂	4	1024	от 0 до 10

Чтобы идентифицировать сеть и сайт АС, в нисходящем направлении TSCC передается служебное сообщение C_SYScode. АС должны проверять C_SYScode, чтобы определить, разрешен ли им доступ к выбранному TSCC и разрешено ли в нем вести радиопередачу. IE C_SYScode структурированы в соответствии с таблицей 12.

Таблица 12

Описание IE C_SYScode

Параметр	Наименование	Описание
MODEL	Сетевая модель	Сетевая модель с градацией по размерам сети: минимальная, маленькая, большая, очень большая
NET	Сетевой идентификатор	Идентификатор определенной транкинговой сети
SITE	Сайт	Идентификатор определенного сайта в сети
PAR	Разделение	Для распределения АС при наличии двух TSCC у одной ТС

Расположение IE Syscode в структуре сообщения и распределение IE NET и SITE в Syscode показано на рисунке 22.

Рисунок 22 - Распределение IE NET и SITE в IE C_SYScode

Параметр "MODEL" определяет длину IE "NET" и "SITE". В той или иной географической зоне может быть использовано, например, большое число небольших сетей, а крупных сетей - только несколько. Параметр "MODEL" позволяет определять целый ряд различных сетей.

Примечание - Параметр DMRLA, показанный на рисунке 22, используется для регистрации. Протокол регистрации описан в 7.4.2.

Совмещенные TSCC

Транкинговые сети ППР настоящего стандарта могут работать с одним или двумя TSCC в одном сайте. Сайт может подразделять общую совокупность АС, чтобы обеспечить распределение нагрузки между различными TSCC. Эта возможность обеспечивается полем (параметром) PAR в IE C_SYScode и управлением категоризации АС.

Управления категориями радиомодулей

При сетевой персонализации АС должна быть присвоена категория управления, хранящаяся в фиксированном энергонезависимом запоминающем устройстве АС. Доступны две категории управления, которые обозначены буквами А и Б.

Категория управления регулирует процедуру захвата и удержания TSCC, так как поле (параметр) PAR в IE C_SYScode указывает, какие категории АС могут стать активными.

IE PAR

IE PAR занимает два бита в IE C_SYScode. Четырем возможным значениям PAR соответствуют следующие категории:

- 00₂ - зарезервировано;

- 01₂ - допускаются только АС категории А;

- 10₂ - допускаются только АС категории Б;

- 11₂ - допускаются АС категорий А и Б.

Множественные TSCC с их разделением по параметру PAR представлены на рисунке 23.

Рисунок 23 - Множественные TSCC с разделением их

по параметру PAR

Пример - Транкинговая сеть ППР настоящего стандарта имеет ряд сайтов, которые используют один TSCC и один сайт, который оснащен двумя TSCC. Различные множества АС персонифицированы таким образом, что общая численность АС равномерно распределяется между категориями А и Б. Как показано на рисунке 24, сайт 1 оснащен двумя TSCC и отправляет PAR = 01₂ в первом TSCC, PAR = 10₂ - во втором TSCC. Любые АС категории А или Б могут стать активными и перейти на TSCC от сайта 2 к сайту 3. Когда АС переходят на сайт 1, они всегда группируются по соответствующим TSCC.

Процедура авторизации TSCC

АС должна распознавать сообщение с IE C_SYScode, передающимся в нисходящем направлении TSCC:

а) проверка параметра MODEL.

АС должна сравнить IE MODEL, переданный в служебном сообщении C_SYScode на нисходящем направлении TSCC, с IE MODEL, хранящимся в фиксированном энергонезависимом запоминающем устройстве АС. Если совпадения нет, то АС не должна использовать проверяемый TSCC;

б) проверка параметра NET.

Если проверка согласно перечислению а) прошла успешно, то АС должна сравнить параметр NET, передаваемый в поле SYS на нисходящем направлении TSCC, с параметром NET, хранящимся в энергонезависимом запоминающем устройстве АС. Если совпадений нет, то АС не должна использовать проверяемый TSCC;

в) проверка данных для авторизации в сайте (SITE_Acquisition Authorization).

Если проверка согласно перечислениям а) и б) прошла успешно, то АС должна сначала проверить, сохранены ли какие-либо параметры авторизации SITE для получения доступа к сайту. Если параметры авторизации SITE не сохранены, то проверка авторизации на получение доступа к сайту не выполняется. Однако если у АС сохранен хотя бы один параметр, каждое сохраненное значение сравнивается с параметром SITE, переданным в служебном сообщении C_SYScode в нисходящем направлении TSCC. Если совпадений нет, то АС не должна использовать проверяемый TSCC;

г) проверка IE PAR.

Если АС успешно провела проверку в соответствии с перечислениями а), б) и в), то она исследует IE PAR с учетом своей категории управления, хранящейся в основной энергонезависимой памяти. Если категория "Управление АС" не является одной из категорий, которым разрешен доступ по значению PAR, то АС не имеет права получать/принимать проверяемый TSCC.

АС должна выполнить попытку доступа к TSCC путем авторизации в соответствии с алгоритмом, представленным на рисунке 24, в котором описана процедура авторизации TSCC в соответствии с 7.3.3.3 ("Процедура авторизации TSCC"). В соответствии с указанной процедурой АС должна принять сообщение C_SYScode и проверить в нем значения IE MODEL, NET, "SITE_Acquisition Authorization", PAR.

Рисунок 24 - Проверка C_SYScode

Проверка IE SYS_AREA

Если АС успешно проверила C_SYScode в соответствии с 7.3.3.3 ("Процедура авторизации TSCC"), то она должна определить значение IE SYS_AREA из C_SYScode. SYS_AREA формируется путем применения "Маски" к IE SITE с параметрами, заданными DMRLA. Далее АС должна сравнить значения, полученные в IE SYS_AREA, со списком отклоненных регистраций, применимых в выбранной сети, хранящимся в АС (этот список стирается, когда АС выключена в соответствии с 7.3.3.3 и 7.4.3).

Если значение IE SYS_AREA при рассмотрении совпадает с любой из записанных отклоненных регистраций, применимых в выбранной сети, то АС не должна использовать проверяемый TSCC.

Порядок проверки IE SYS_AREA представлен на рисунке 25.

ИС NORMPROD: примечание.

Нумерация рисунков дана в соответствии с официальным текстом документа.

Рисунок 23 - Проверка IE SYS_AREA из C_SYScode

Пример - В большой сети АС с параметром DMRLA, установленным в значение 6, производит поиск TSCC и пытается получить доступ к TSCC и ресурсам ТС. АС извлекает IE SYS_AREA из C_SYScode и сравнивает его с каждой записью в списке запрещенных регистраций. Если есть совпадение хотя бы в одной из позиций, то АС не должна использовать проверяемый TSCC.

Время жизни записей SYS_AREA в списке отклоненных регистраций

Весь список отклоненных регистраций стирается, когда АС выключается, как описано в 7.4.3.

Если время T_DENREG таймера не равно нулю, то отдельные записи в списке отклоненных регистраций имеют ограниченный параметр "Время жизни". В этом случае АС контролирует время таймера для каждого из элементов. Если время таймера для конкретного IE SYS_AREA истекает, то значение IE, переданное в SYS_AREA, должно быть удалено из списка.

7.3.3.4 Подтверждение - мониторинг качества сигнала нисходящего TSCC

В то время как TSCC находится в режиме "Свободен", АС должна контролировать качество сигнала в нисходящем направлении TSCC. Показателем качества сигнала может быть, например, измерение коэффициента ошибок в зависимости от уровня радиочастотного сигнала.

АС должна поддерживать два порога качества сигнала:

а) первый порог должен использоваться при поиске АС TSCC до получения подтверждения порядком, описанным в 7.3.3;

б) второй порог должен использоваться после проверки и подтверждения, когда АС находится в режиме "свободна" на TSCC.

Примечание - Когда АС переходит в режим вызова, она приостанавливает измерения качества сигнала в TSCC.

7.3.3.5 Считывание CC

После подтверждения по TSCC АС определяет CC, который должен быть передан в нисходящем направлении TSCC. Этот CC должен использоваться в рабочих каналах, передающих полезную нагрузку (пользовательские речь, данные), и TSCC.

Когда рабочий канал активен, TSCC должен отклонить любые PDU, передаваемые в его восходящем направлении, которые имеют несовпадающий с нужным значением CC.

7.3.4 Освобождение АС TSCC

7.3.4.1 Причины для освобождения TSCC, когда он активен, но свободен

Когда АС ведет радиопередачу (активна), она должна контролировать/проверять TSCC и вернуться к процедурам поиска, если произойдет какое-либо из следующих событий:

а) после подтверждения коэффициент битовых ошибок превышает минимум, предусмотренный порогами качества, определенными в 7.3.3.4;

б) значение полученного C_SYScode отличается от значения, полученного при авторизации последующих за NSYSerr событий;

в) нет декодируемых блоков PDU TSCC, полученных АС за T_Nosig секунд;

г) пользователь инициирует замену выбранной сети;

д) получен C_MOVE PDU, применимый к АС. В этом случае АС должна сохранить значение, полученное в IE CONT из служебного сообщения C_MOVE PDU;

е) АС принимает значение IE C_NACKD (Reason соответствует Reg_Denied) в результате отправки регистрационного служебного сообщения с использованием PDU произвольного доступа. В случае регистрации запроса произвольного доступа АС переходит к поиску, который выполнялся последним перед попыткой регистрации;

ж) после подтверждения C_SYScode АС получает C_NACKD (Reason соответствует Reg_Refused) как результат процедур регистрации произвольного доступа. В этом случае АС переходит в стадию поиска TSCC, которая выполнялась последней перед попыткой регистрации;

и) после подтверждения того, что у АС истекло время после случайной процедуры регистрации доступа до достижения NRand_NR или превышения Trand_TCh. В этом случае АС должна вернуться в стадию поиска TSCC, которая выполнялась последней перед попыткой регистрации;

к) после подтверждения того, что у АС истекло время после попытки асинхронного доступа для запроса на обслуживание, за исключением регистрации, до достижения NRand_NR или NRand_NE или превышения TRand_TCh.

7.3.4.2 Освобождение TSCC во время ожидания сигнализации

АС, ожидающая сигнализацию, должна освободить TSCC, на котором она в настоящее время ведет радиопередачу (активна), когда происходит любое из событий, указанных в 7.3.4.1, перечисления б), в) и д). АС сохраняет свое состояние ожидания сигнализации во время любых процедур поиска и при последующих проверках подтверждения TSCC. Время всех таймеров, связанных с состоянием ожидания АС, должно быть сохранено.

7.4 Регистрация, энергосбережение и процедуры аутентификации

7.4.1 Общие положения

Процедуры, определенные в настоящем подразделе, предназначены для поддержки общих и дополнительных услуг. Служебные сообщения, передаваемые с помощью PDU, которыми обмениваются ТС и АС, содержат адреса устройств, которые идентифицируют либо конкретные устройства (например, АС), либо шлюзы (см. А.4). Это указывает на то, что услуга поддерживается. Для наглядности перечень услуг и служебных сообщений с использованием PDU, а также перекрестные ссылки на адреса приведены в таблице 13.

Таблица 13

Услуги, PDU и перекрестные ссылки на адреса

Услуга	PDU	Источник	Адрес источника	Адрес получателя	Комментарии
Регистрация	Запрос произвольного доступа	АС	АС ID	REG_ADDR	0000 0000₂ + C_SYScode
Регистрация	Подтверждение	ТС	REGI	АС ID	К запросу произвольного доступа или финальному подтверждению, если регистрация была частью аутентификации
Аутентификация или часть регистрации АС	C_AHOY	ТС	Вызов аутентификации	АС ID	-
Аутентификация или часть регистрации АС	Подтверждение	АС	АС ID	Результат аутентификации	К вызову аутентификации
Блокировка/разблокировка	C_AHOY	ТС	STUNI	АС ID	-
Блокировка/разблокировка	Подтверждение	АС	АС ID	STUNI	К C_AHOY или финальному подтверждению, если блокировка/разблокировка была частью аутентификации
Блокировка/разблокировка (АС аутентифицирует ТС)	C_AHOY	ТС	STUNI	АС ID	-
	C_ACVIT	АС	MD_ID	Вызов аутентификации	-
	Подтверждение	ТС	Результат аутентификации	MD_ID	-
	Подтверждение	АС	АС ID	STUNI	-
Приведение АС в неработоспособное состояние путем аутентификации	C_AHOY	ТС	KILLI	АС ID	Приведение АС в неработоспособное состояние должно всегда быть аутентифицировано
	C_ACVIT	АС	MS_ID	Вызов аутентификации
	Подтверждение	ТС	Результат аутентификации	MS_ID
	Подтверждение	АС	АС ID	KILLI
Регистрация с рекомендацией IP-соединения	Запрос произвольного доступа	АС	АС ID	REG_ADDR	0000 0000₂ + C_SYScode
	Подтверждение	ТС	REGI	АС ID	Только C_WACK или C_NACK
	C_AHOY	ТС	IPI	АС ID	-
	C_UDTHU+AD	АС	АС ID	IPI	-
	Подтверждение	ТС	IPI	АС ID	-
Незапрошенная радиопроверка АС	C_AHOY P_AHOY	ТС	TSI	АС ID или речевой группы	ID обозначает индивидуальную АС или речевую группу
Незапрошенная радиопроверка АС	Подтверждение	АС	АС ID	TSI	-
Услуги данных Supplementary_user, с поддержкой базовых услуг	C_AHOY	ТС	SUPLI	АС ID вызывающей стороны	Фаза восходящей передачи
	C_UDTHU+AD	АС	АС ID	SUPLI	Фаза восходящей передачи
	C_UDTHD+AD	ТС	SUPLI	АС ID вызванной стороны	Фаза нисходящей передачи (если применима)
	Подтверждение	АС	АС ID	SUPLI	Фаза нисходящей передачи (если применима)

7.4.2 Регистрация

7.4.2.1 Общие положения

Регистрация представляет собой способ закрепления АС по территориальному признаку за определенной областью (зоной) или группой областей (зон), в которых АС, вероятно, будет работать (вести радиопередачу) в пределах многозоновой транкинговой сети. Эта информация позволяет избежать поиска АС по всей сети и, следовательно, сокращает время установки вызовов и уменьшает загрузку TSCC.

Вторичной функцией регистрации является ограничение услуг для АС по отношению к конкретным ТС с разрешением сети отклонять другие запросы на регистрацию, как описано в 7.4.5.2 ("В регистрации отказано").

Настоящим стандартом предусмотрено два вида регистрации в транкинговом режиме. Первым видом является явная регистрация, которая осуществляется с помощью процедуры произвольного (в асинхронном режиме) доступа АС. Вторым - регистрация, которая осуществляется в результате обмена PDU между TSCC и АС. Явная регистрация также позволяет АС запросить режим работы с экономией энергии (описан в 7.4.8). Простая процедура радиопроверки присутствия "на радиосвязи" АС позволяет TSCC проводить простой опрос АС в любой момент. Эта процедура описана в 7.4.13.

7.4.2.2 Принцип работы

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

а) запрос регистрации не получен сетью, в этом случае сеть будет рассматривать предыдущую успешную запись регистрации как действующую в настоящее время;

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

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

Регистрационные записи должны быть извлечены из служебного сообщения с IE C_SYScode с помощью следующей процедуры:

а) АС извлекает параметр SITE из C_SYScode;

б) затем АС извлекает информацию о SYS_AREA из параметра SITE путем применения "Маски" наиболее значимых битов (MSB) с DMRLA.

Рисунок 26 - Извлечение регистрационной записи из C_SYScode

Пример - На рисунке 26 показан процесс извлечения регистрационной записи из C_SYScode в большой сети. Параметр SITE для такой сети имеет длину поля, равную 8 битам. DMRLA в этом примере равна 6, поэтому наиболее значимые 6 бит становятся регистрационной записью.

7.4.3 Параметр АС Volatility

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

В таблице 14 приведены изменения каждого из таких параметров.

Таблица 14

Изменения регистрационных параметров АС

Параметр	Пункт, подпункт настоящего стандарта	Не изменяется в процессе персонализации АС. Сохраняется после выключения АС	Изменяется в процессе операций и сохраняется после выключения АС	Изменяется в процессе операций и стирается после выключения АС
Текущая запись регистрации	7.4.5	-	X	-
Список запрещенных регистраций	7.3.3.3 ("Проверка информационного элемента SYS_AREA") <1>	-	-	X
<1> При получении TSCC, по которому было отказано в попытке регистрации АС, проверяется по крайней мере восемь различных значений IE SYS_AREA из принятого C_SYScode. Они должны быть организованы как список FIFO: когда АС имеет полный список записей, любое дальнейшее добавление к списку вытесняет самую раннюю запись. Примечание - Отдельные записи в списке запрещенных регистраций могут быть удалены по истечении времени таймера запрещенных регистраций T_DENREG [см. 7.3.3.3 ("Время жизни записей SYS_AREA в списке отклоненных регистраций") и 7.4.5.2 ("В регистрации отказано")].

7.4.4 Действия АС в ответ на подтверждение от TSCC

АС не делает никаких попыток асинхронного (произвольного) доступа, пока не будет получено подтверждение в нисходящем направлении TSCC.

Когда АС получает такое подтверждение, она должна выполнить одно из следующих действий:

а) если IE Reg = 0 (содержится в C_ALOHA PDU и в CACH), то АС не будет пытаться зарегистрироваться путем асинхронного доступа и не будет создавать или изменять любую регистрационную запись. АС должна зафиксировать, что регистрация не требуется и что АС может инициировать вызовы;

б) если IE SYS_AREA из C_SYScode соответствует любой из записей в списке запрещенных регистраций, то АС не должна использовать проверяемый TSCC. АС должна возобновить поиск;

в) если АС не имеет записи успешной регистрации для проверенного SYS_AREA, то АС должна пытаться зарегистрироваться с помощью произвольного доступа.

IE Reg, передающийся в служебных сообщениях C_ALOHA PDU и в CACH, должен иметь одинаковое значение.

Примечание - IE Reg в C_ALOHA PDU всегда применим и не зависит от параметра "Маска" (C_ALOHA).

После подтверждения в нисходящем направлении TSCC АС не должна передавать какие-либо PDU, кроме одного из следующих случаев:

а) использование службы регистрации PDU запроса асинхронного (произвольного) доступа;

б) подтверждение запроса аутентификации, как это указано в 7.4.9.4, до тех пор, пока не будет сохранена запись успешной регистрации, относящаяся к проверенному SYS_AREA, кроме ситуаций, когда Reg = 0.

Если АС содержит запись успешной регистрации, относящуюся к проверенному коду SYS_AREA, она может свободно передавать любой PDU в соответствии с требованиями настоящего стандарта.

7.4.5 Процедура регистрации

7.4.5.1 Основные положения

Процедуры регистрации АС определены в 7.4.5.2 ("Общие положения", "Промежуточное подтверждение", "Регистрация принята", "Регистрация отклонена", "В регистрации отказано", "Вызов и отклик аутентификации", "Время попытки регистрации истекло", "При регистрации произвольного доступа получен запрос на регистрацию", "После максимально разрешенного числа попыток произвольного доступа не был получен ответ", "Действия регистрации при включении или аналогичных действиях"). Процессы регистрации в виде MSC (информацию о схемах MSC см. в приложении Д), включая необязательные стадии аутентификации, показаны на рисунках 28 - 30.

7.4.5.2 Регистрация путем произвольного доступа

Общие положения

Когда АС определяет, что требуется регистрация, она должна пытаться сделать это путем произвольного доступа, используя процедуры, определенные в 7.2. Если время ожидания произвольного доступа C_RandTCh истекает и АС не посылает запрос на регистрацию произвольного доступа, то АС должна начать процедуры получения TSCC.

IE запроса произвольного доступа передаются на CCL стека протоколов и должны быть установлены, как это предписано в таблице 15.

Таблица 15

IE C_RAND для регистрационной службы АС

IE	Размер, бит	Длина, бит	Имя	Значение	Комментарий
Service_Options	7	1	-	0₂	Занят (R)
		1	-	0₂	Конфиденциальность (R)
		1	IP_INFORM	0₂	АС не рекомендует IP-соединение
		1	IP_INFORM	1₂	АС рекомендует IP-соединение
		3	PS_RQ	0₂	Энергосбережение не запрашивается
		3	PS_RQ	От 001₂ до 111₂	Энергосбережение запрашивается
		1	REG_DEREG	0₂	Если IP_Inform = 0₂, то АС дерегистрируется, если IP_Inform = 1₂, то АС удаляет IP-соединение
		1	REG_DEREG	1₂	Если IP_Inform = 0₂, то АС пытается зарегистрироваться, если IP_Inform = 1₂, то АС пытается зарегистрироваться и/или добавить IP-соединение
Proxy Flag	1	-	PROXY	0₂	-
Target_Address Content	2	-	TRGT_ADR_CNTS	00₂	0000 0000₂ + C_SYSCode
				01₂	ID подписки речевой группы
				10₂	TATTSI
				11₂	Зарезервировано
Appended_Short_Data	2	-	Если TRGT_ADR_CNTS больше или меньше 10₂	00₂	Зарезервировано
Appended_Short_Data	2	-	Если TRGT_ADR_CNTS = 10₂	-	Количество добавочных блоков, необходимое для передачи разговорной группы
Service_Kind	4	-	REG_SRV	1110₂	Услуга регистрации
Target_Address или Gateway	24	-	Если TRGT_ADR_CNTS = 00₂	Value	0000 0000₂ + C_SYSCode
			Если TRGT_ADR_CNTS = 01₂	-	ID подписки речевой группы
			Если TRGT_ADR_CNTS = 10₂	-	TATTSI
Source_Address	24	-	-	Value	Индивидуальный адрес вызываемой АС

Сразу после отправки запроса на регистрацию путем произвольного доступа АС должна удалить текущий SYS_AREA код, сохраненный при предыдущей регистрации. Допустимыми ответами, направляемыми в нисходящем направлении TSCC на запрос произвольного доступа, являются C_WACKD (в котором Reason соответствует Wait) - ожидание дальнейшей сигнализации, C_ACKD (в котором Reason соответствует Reg_Accepted), C_NACKD (в котором Reason соответствует Reg_Refused), C_NACKD (в котором Reason соответствует Reg_Denied) или C_AHOY (в котором Source_Address соответствует Authentication_Challenge) (см. 7.4.9). Служебные сообщения, передаваемые с помощью PDU типа ACK, в качестве адреса получателя используют индивидуальный адрес АС и адрес источника REGI. Если TRGT_ADR_CNTS соответствует 00₂, то TSCC в своем нисходящем направлении передает только ответ на запрос произвольного доступа. При этом C_SYScode в IE REG_ADDR из C_RAND должен совпадать с C_SYScode, передаваемым по TSCC. Если IE REG_ADDR в C_RAND, полученный по TSCC, не соответствует C_SYScode, передаваемому по TSCC, TSCC должен игнорировать сообщения о регистрации C_RAND. Требования по возможным ответам на запрос регистрации АС определены в 7.4.5.2. Служебное сообщение с использованием PDU окончательного подтверждения определяет, будет ли АС разрешен доступ к этому TSCC.

Если окончательное подтверждение АС, полученное в нисходящем направлении TSCC, - "Отказ в регистрации", то АС должна возобновить поиск нового TSCC. Если АС не находит альтернативный TSCC, который разрешает доступ к нему АС, то она возвращается к первоначальному TSCC и повторяет процедуру. В сильно загруженной системе это может привести к большому количеству регистрируемого трафика. Однако если в нисходящем направлении TSCC передается сообщение "Отказ в регистрации в качестве окончательного подтверждения", АС добавляет SYS_AREA в список запрещенных регистраций. Процедура, определенная в 7.4.4, перечисление б), запрещает АС дальнейшие запросы регистрации произвольного доступа к этому TSCC. Таким образом, отказ в регистрации является окончательным ответом TSCC об отказе абонентской станции в получении конкретного TSCC.

После выключения АС список отказов в регистрации должен быть очищен.

Промежуточное подтверждение

В случае если TSCC не может немедленно ответить на запрос произвольного доступа, он может отправить в нисходящем направлении на АС подтверждение ожидания C_WACKD (Reason соответствует Wait). Это подтверждение должно запустить таймер TNP_Timer в соответствии с 7.2.2.3. Если по истечении времени таймера дальнейшая сигнализация не будет получена, АС должна выполнить процедуры, описанные в 7.4.5.2 ("Время попытки регистрации истекло").

Регистрация принята

Попытка регистрации считается успешной при получении подтверждения ACK (Reason соответствует Reg_Accepted). АС должна записать информацию SYS_AREA, полученную из нисходящего направления TSCC в служебном сообщении, содержащем IE C_SYScode. АС необходимо заменить старую запись о регистрации новой записью, извлеченной из IE C_SYScode.

Регистрация отклонена

Попытка регистрации считается неуспешной, если АС получает отказ в регистрации C_NACKD (Reason соответствует Reg_Refused).

АС должна возобновить поиск нового TSCC и после подтверждения обнаружения нового TSCC и получения соответствующего служебного сообщения C_ALOHA PDU повторить попытку регистрации произвольного доступа.

До тех пор, пока регистрация не будет принята, АС не должна совершать попытки передачи запросов, кроме передачи запросов о регистрации произвольного доступа.

В регистрации отказано

Попытка регистрации получает отказ, если АС получает сообщение C_NACKD (Reason соответствует Reg_Denied).

АС должна добавить код SYS_AREA в список получивших отказ регистраций и выполнить процедуры обнаружения TSCC.

Если T_DENREG не равен нулю, АС необходимо запустить таймер, равный значению T_DENREG для того, чтобы получить доступ к списку получивших отказ регистраций.

Вызов и отклик аутентификации

TSCC может обращаться к промежуточному этапу аутентификации АС при ее регистрации.

Рисунок 27 - Регистрация с проверкой аутентификации

Рисунок 27 отображает процедуру регистрации АС с опциональными этапами "Б" и "В":

а) на этапе "А" АС совершает попытку регистрации произвольного доступа;

б) AHOY PDU на этапе "Б" является подтверждением произвольного доступа и вызывает АС для ответа на отклик аутентификации. Запущен таймер TNP_Timer;

в) этап "В" - отклик АС на обращение к TSCC, содержащий отклик аутентификации;

г) TSCC отправляет АС итоговое C_ACKD или C_NACKD.

Конкретные процедуры аутентификации описаны в 7.4.9.

Время попытки регистрации истекло

Если время ожидания сигнализации о регистрации в АС истекло (истечение времени таймера TNP_Timer), то АС необходимо выполнить процедуры обнаружения TSCC.

При регистрации произвольного доступа получен запрос на регистрацию

ТС должна исключать или минимизировать конфликты при регистрации следующим образом. Если в течение ожидания ответа на запрос регистрации произвольного доступа АС получает PDU C_BCAST (Announcement_type соответствует MassReg) PDU, применимый к АС, то АС необходимо записать IE C_BCAST и инициализировать процедуру, описанную в 7.4.6.2, а затем продолжить регистрировать запрос в соответствии с процедурами произвольного доступа.

После отправки максимально разрешенного числа попыток произвольного доступа не был получен ответ

Если в пределах таймслотов ожидания (WAIT) плюс один таймслот не получено ответа после того, как АС произвела NRand_NR попыток произвольного доступа, она не должна вносить никаких последующих изменений в свои записи регистрации.

Действие регистрации при включении или аналогичных действиях

Если АС определяет, что TSCC запрашивает о регистрации, то она должна зарегистрироваться путем произвольного доступа при включении или смене выбранной сети.

Диаграммы последовательности передачи сообщений при регистрации

MSC, иллюстрирующие процедуры регистрации, представлены в 7.4.5.2. Обобщенная MSC при регистрации АС, кроме того, представлена на рисунке 28.

Рисунок 28 - MSC при регистрации АС

Регистрация с аутентификацией АС

SDL, иллюстрирующие процесс регистрации с аутентификацией АС, представлены на рисунках 29 и 30.

Рисунок 29 - SDL-диаграмма процесса регистрации

с аутентификацией. Часть 1

Рисунок 30 - SDL-диаграмма процесса регистрации

с аутентификацией. Часть 2

Прием инициированных пользователем запросов на обслуживание

Для передачи голоса и данных пользователи запрашивают определенную услугу путем передачи запроса на обслуживание произвольного доступа. TSCC может потребовать от АС регистрацию, прежде чем принимать такой запрос на обслуживание. Если TSCC определил, что прием таких запросов осуществляется только для зарегистрированных АС, а посылающая запрос АС не зарегистрирована, то он отвечает отклонением C_NACKD (Reason соответствует MS_Not_Registered).

Подписка и присоединение разговорной группы

АС, поддерживающие работу в транкинговом режиме, могут быть членами одной или нескольких разговорных групп. Разговорные группы могут на постоянной основе записываться в АС в процессе персонализации. Настоящим стандартом определены три постоянные разговорные группы: ALLMSIDL, ALLMSIDZ и ALLMSID (см. раздел 4). Процедуры этого подпункта описывают регистрацию в разговорной группе и присоединение к ней. АС не следует выполнять присоединение разговорной группы для тех разговорных групп, которые были назначены АС на постоянной основе.

Регистрация и присоединение разговорной группы позволяет АС информировать TSCC об определенной разговорной группе. TSCC может использовать эту информацию при создании группового вызова:

а) для регистрации разговорной группы. Такая регистрация включает только сайты, содержащие зарегистрированные АС. В результате этого оптимизируется использование частот системы, так как вызов не устанавливается на сайтах, не содержащих зарегистрированные АС. В этом случае АС, обнаружившая TSCC, но еще не зарегистрированная в разговорной группе, должна быть способна получать вызов этой разговорной группы и участвовать в нем;

б) присоединения разговорной группы. Это процесс, позволяющий убедиться, что, когда АС выбирает разговорную группу, она имеет право на ее использование и что сеть знает индивидуальный адрес АС, связанный с этой группой. Когда пользователь АС выбирает разговорную группу для работы в ней, процедура назначения ID для этой группы позволяет АС и TSCC совершать обмен информацией об идентификаторах недавно присоединенных разговорных групп в АС, т.е. адресах, которые АС отнесет к верным адресам разговорных групп в случае обращения PDU нисходящего канала к определенной разговорной группе. В результате регистрации разговорной группы радиосеть знает, для каких АС нужно установить групповой вызов и, следовательно, какие сайты необходимо включить при создании вызова. До тех пор, пока процедура регистрации разговорной группы не будет завершена, разговорная группа будет недоступна для АС. АС может подключаться к одной или нескольким разговорным группам. Она также может подключать идентификаторы разговорной группы, когда первоначально регистрируется в TSCC. Позже АС может инициировать процедуру присоединения с помощью другой процедуры регистрации (например, для добавления другой разговорной группы). За исключением уже имеющихся разговорных групп, АС может быть включена в вызов разговорной группы только при условии, что прежде она была зарегистрирована в этой группе с помощью процедур, описанных в данном подпункте.

Регистрация с подпиской и присоединением одной разговорной группы

АС может включать запрос на подписку/присоединение только одной разговорной группы наряду с ее запросом на регистрацию. При запросе на регистрацию одновременно с подпиской/присоединением разговорной группы АС следует передать C_RAND с Trgt_Adr_Cnts, установленным в значение 01₂, а также адресом получателя или значением шлюза, соответствующим ID подписки/присоединения разговорной группы. При получении C_RAND TSCC должен отправить подтверждение вида "Адрес источника соответствует REGI, адрес получателя соответствует адресу АС, отправившей C_RAND". Если TSCC принял и запрос на регистрацию, и запрос разговорной группы на подписку и присоединение, то ему необходимо передать C_ACK (Reason соответствует Reg_Accepted) на АС. После получения АС должна вести себя согласно 7.4.5.2 ("Регистрация принята").

Если TSCC не принял запрос на регистрацию, он должен передать АС либо C_NACK (Reason соответствует Reg_Refused), либо C_NACK (Reason соответствует Reg_Denied). После получения АС должна выполнить действия, описанные в 7.4.5.2 ("Регистрация отклонена" и "В регистрации отказано" соответственно).

Возможен вариант, при котором TSCC принимает запрос на регистрацию на сайте, но не принимает запрос на подписку/присоединение. В этом случае TSCC должен передать служебное сообщение C_ACK (в котором Reason Code установлен в значение "Подписка/присоединение" - 0110 0101₂ и Response_Info установлен в значение 000 0000₂). После получения АС может выполнить процедуры обнаружения нового TSCC для сайта, который разрешает подписку/присоединение разговорной группы, или получить подтверждение на этом TSCC. Для того чтобы удалить ранее принятую подписку/присоединение разговорной группы, АС необходимо использовать процедуру подписки/присоединения одной разговорной группы с адресом назначения ADRNULL.

Регистрация в списке присоединений и подписок разговорной группы

В своем запросе на регистрацию АС может сообщить TSCC, что она также запрашивает подписку/присоединение к списку разговорных групп. Регистрация с подпиской и присоединением не может быть объединена с энергосбережением или IP_INFORM. Поэтому значение PS_RQ должно быть равным 000₂, а значение IP_INFORM - равным 0₂.

Список подписок/присоединений разрешает запрашивать у TSCC до семи адресов разговорной группы. Каждый адрес в списке (от ADDRESS1 до ADDRESS7) должен быть проверен TSCC в индивидуальном порядке так, как показано в подтверждении PDU.

В таблице 16 приведено распределение битов проверки, где "x" - это бит проверки для адреса разговорной группы.

Таблица 16

Распределение битов для проверки адресов разговорной группы

Список	Response_Info, биты
ADDRESS1	x------
ADDRESS2	-x-----
ADDRESS3	--x----
ADDRESS4	---x---
ADDRESS5	----x--
ADDRESS6	-----x-
ADDRESS7	------x

Если транзакция подписки/подключения разговорной группы завершилась без ошибок, то вызывающий TSCC должен отправить финальное подтверждение C_ACK вызывающей АС. Биты Response_Info в C_ACK (Reason соответствует Message_Accepted) должны содержать один бит для каждого из семи адресов разговорной группы, отправленных TSCC. Если соответствующий Response_Info бит установлен в значение 1₂, то TSCC принял этот адрес. Если бит Response_Info установлен в значение 0₂, то TSCC отклонил адрес разговорной группы. TSCC может принять транзакцию, но отправить Response_Info, установленный в значение 000 0000₂. В этом случае TSCC отклонил все адреса из списка. Для того чтобы удалить ранее принятые подписки/присоединения разговорной группы, транзакцию присоединения необходимо повторить, заменив соответствующие разговорные группы на ADRNULL.

Для изменения подписки/присоединения разговорной группы необходимо выполнить новую транзакцию и заменить существующий список списком из новой транзакции.

Если АС запрашивает регистрацию вместе со списком подписок/присоединений разговорной группы, то она должна передать C_RAND с Trgt_Adr_Cnts, установленным в значение 10₂; адрес получателя при этом должен соответствовать адресу шлюза TATTSI, Appended_Short_Data равен количеству добавочных блоков UDT для передачи списка подписок/присоединений.

Если TSCC не принимает запрос на регистрацию, то он должен передать АС либо C_NACK (Reason соответствует Reg_Refused), либо C_NACK (Reason соответствует Reg_Denied), при этом адрес источника должен соответствовать TATTSI, а адрес получателя - адресу АС, передающей C_RAND. После их получения АС должна выполнить действия, описанные в 7.4.5.2 ("Регистрация отклонена" и "В регистрации отказано" соответственно).

Если TSCC принимает запрос на регистрацию, то он передает служебное сообщение C_AHOY, IE которого приведены в таблице 17.

Таблица 17

IE служебного сообщения C_AHOY для списка

подписок/присоединений разговорной группы

IE	Длина, бит	Значение
Service_Options_Mirror	7	-
Service_Kind_Flag	1	1₂ - данные о подписке/присоединении разговорной группы
ALS	1	0₂ - не применимо
G/I	1	0₂ - адрес получателя - это индивидуальный адрес АС
Appended_Blocks	2	По мере необходимости
Service_Kind	4	1110₂ - служба регистрации
Target_Address	24	Адрес посылающей запрос АС
Source_Address или Gateway	24	TATTSI

Значение флага Service_Kind, равное 1₂, указывает, что TSCC запрашивает список подписок/присоединений разговорной группы и не выполняет запрос аутентификации. После получения C_AHOY АС должна немедленно передать список подписок/присоединений с использованием (посредством) UDT. Идентификаторы подписки/присоединения должны быть переданы с UDT-заголовками IE в формате UDT (формат адреса: 0001₂), как это определено в Б.3.3, и с TATTSI в качестве адреса получателя.

После получения UDT TSCC подтверждает, что данные UDT были успешно получены. Такое подтверждение осуществляется методом передачи одного или более подтверждений PDU (источник - TATTSI, адрес получателя - это адрес АС, инициирующей C_RAND). Если данные UDT были успешно получены, подтверждение должно быть C_ACK.

Если TSCC принимает список подписок/присоединений, он передает АС подтверждение C_ACK (Reason соответствует Reg_Accepted) или C_ACK [в котором Reason Code установлен в значение "Подписка/присоединение" (0110 0101₂)], а Response_Info = 111 1111₂. Это означает, что все разговорные группы были приняты (см. таблицу 16). После получения подтверждения АС должна отработать действия, описанные в 6.4. Полностью этот процесс представлен на рисунке 31.

Рисунок 31 - Список подписок/присоединений

разговорной группы

Возможен вариант, при котором TSCC принимает запрос на регистрацию на сайте, но не принимает запрос на подписку/присоединение. В этом случае TSCC должен передать C_ACK [в котором Reason Code соответствует значению "Подписка/присоединение" (0110 0101₂)], Response_Info - в значение, показывающее, какие разговорные группы были приняты или не приняты (см. таблицу 16). После получения подтверждения АС может либо подтвердить данный TSCC, либо выполнить процедуры обнаружения TSCC для сайта, который разрешает подписку/присоединение разговорной группы.

Регистрация с подпиской/присоединением разговорной группы и с аутентификацией приведена на рисунке 32.

Рисунок 32 - Регистрация с подпиской/присоединением

разговорной группы и аутентификацией

При добавлении аутентификации в процесс регистрации и подписки/присоединения АС отвечает на вызов C_AHOY подтверждением C_ACK. C_ACK сопровождается UDT и списком подписок/присоединений разговорной группы. В TSCC должно быть передано два служебных сообщения C_AHOY для того, чтобы правильно зарезервировать входящий канал. Первое из переданных служебных сообщений предназначено для регистрации вызова, а второе служебное сообщение - для передачи списка подписок/присоединений разговорной группы с использованием UDT.

7.4.6 Массовая перерегистрация

7.4.6.1 Общие положения

Сеть с большим количеством АС полагается на достоверность записей о регистрации для организации управления с использованием информации о местоположении АС. В связи с географическим перемещением АС между различными ТС записи могут быть устаревшими по многим причинам, включая потерю каналов между ТС. Перерегистрация АС предназначена для восстановления регистрационных записей и является механизмом, посредством которого TSCC может восстановить регистрационные записи, полученные от АС и подтвержденные на этом TSCC. В этих целях в нисходящем направлении TSCC должен передаваться широковещательный PDU, вызывающий все подходящие для данного TSCC АС (имеющие права регистрации на данном TSCC), перерегистрация которых подтверждается путем произвольного доступа. Если эта процедура перерегистрации активируется на ТС, то должны быть приняты меры, направленные на исключение перегруженности TSCC из-за повышенной активности запросов асинхронного (произвольного) доступа АС к TSCC. Для управления этим процессом широковещательное служебное сообщение с использованием PDU содержит IE Reg_Window, который позволяет АС совершать попытку регистрации доступа в асинхронном режиме (произвольного доступа) в течение продолжительного периода времени.

АС должна записать значение параметра задержки Reg_Window из принятого PDU C_BCAST (Announcement_type соответствует MassReg), которое АС получает в нисходящем направлении текущего TSCC, и использовать таблицу 18, чтобы извлечь из нее соответствующее временное окно для проведения попытки регистрации произвольного доступа.

Процедура массовой регистрации может быть использована для регистрации конкретных АС. Это обеспечивается подстановкой индивидуального адреса АС в широковещательном PDU массовой регистрации и использованием "Маски" в значении 24.

7.4.6.2 Процедуры для АС при получении вещания массовой перерегистрации

После подтверждения на TSCC АС должна использовать информацию из PDU C_BCAST (Announcement_type соответствует MassReg). Этот PDU может быть передан в нисходящем направлении TSCC, чтобы перерегистрировать все АС или их подмножество путем произвольного доступа.

АС должна зафиксировать данные о подмножестве абонентских станций, содержащиеся в каждом PDU C_BCAST (Announcement_type соответствует MassReg), который она получает (как описано в 7.1.3), используя спецификатор ("Маска") и поле адреса из PDU C_BCAST. Для "Маски" со значением от 0 до 24 PDU применим к АС, если младшие значащие биты "Маски" поля адреса из PDU C_BCAST совпадают с младшими значащими битами "Маски" ее индивидуального адреса.

Таблица 18

Подстановка Reg_Window для массовой регистрации

Reg_Window	Treg_Window
0	Отмена Mass Reg
1	0,5
2	1
3	2
4	5
5	10
6	20
7	30
8	100
9	300
10	1000
11	3000
12	10 000
13	30 000
14	100 000
15	200 000

Если АС определяет, что PDU C_BCAST (Announcement_type соответствует MassReg) применимо, то она должна:

а) сравнить значение IE Reg_Window, полученное из C_BCAST (Announcement_type соответствует MassReg). Если оно не равно нулю, то АС должна использовать временное окно TReg_Window (в секундах) для регистрации попытки произвольного доступа с использованием таблицы 18;

б) выбрать случайное число (с использованием статистически равновероятного распределения) от нуля до значения TReg_Window;

в) отсчитать в режиме реального времени, сколько секунд пройдет до тех пор, пока не будет достигнута случайная величина;

г) совершить попытку регистрации произвольного доступа с помощью процедур, описанных в 7.4. Если АС находится в режиме энергосбережения, IE PowerSave_RQ в Service_Options запроса регистрационной службы должен быть установлен в значение поддержания режима энергосбережения в рабочем состоянии;

д) отсчитать в режиме реального времени, сколько секунд осталось до того момента, пока не будет достигнут TReg_Window. Если АС получает другие применимые PDU C_BCAST (с Announcement_type, соответствующим MassReg), содержащие IE Reg_Window, значение которого не равно нулю, прежде чем будет достигнуто допустимое время регистрации Reg_Window, она должна игнорировать эти PDU;

е) если работает режим энергосбережения, то TSCC должен обеспечить передачу данных, касающихся процедуры массовой регистрации, в период активности.

Если АС подтверждена в нисходящем направлении TSCC и принимает другие применимые служебные сообщения C_BCAST (Announcement_type соответствует MassReg), содержащие IE Reg_Window, значение которого равно нулю, процедура массовой перерегистрации и любые ожидающие попытки произвольного доступа должны быть отменены. Если такой сигнал будет приниматься в то время, когда процедура произвольного доступа находится в процессе обработки, то она должна быть завершена до отмены процедуры массовой перерегистрации.

Если АС выходит из текущего TSCC и успешно подтверждается в другом TSCC, то процедура массовой регистрации должна быть отменена.

7.4.7 Отмена регистрации

Когда пользователь выключает АС (например, нажатием кнопки "Выкл.") или производится инициированная пользователем смена используемой транкинговой сети, АС должна сначала попытаться отменить регистрацию в этой транкинговой сети. АС может сделать это с помощью произвольного доступа, используя процедуры, определенные в 7.2. В служебном сообщении "Запрос регистрационной службы" (Service_Options) должны быть установлены следующие значения IE: IP_Inform установлен в значение 0₂, Reg_Dereg - в значение 0₂ и PowerSave_RQ - в значение 000₂.

При выключении АС или смене транкинговой сети АС должна запустить таймер T_Dereg.

Сразу после отправки запроса отмены регистрации методом произвольного доступа АС должна удалить текущий код SYS_AREA, оставшийся от ее регистрации в сети.

После получения служебного сообщения об отмене регистрации TSCC должен отправить в нисходящем направлении TSCC ответ на запрос отмены произвольного доступа служебным сообщением C_ACKD (Reason соответствует Reg_Accepted). При получении подтверждения АС должна выключиться или завершить процесс смены транкинговой сети.

Примечание - Процедура отмены регистрации при выключении нужна для информирования ТС о том, что данная АС больше не присутствует в этом сайте. Это полезно, например, если АС - единственный представитель своей группы в этом сайте. Тогда после выключения АС групповые вызовы, предназначенные для такой группы, в этот сайт больше распределяться не будут, и тем самым экономится общий ресурс транкинговой сети.

Если при отмене регистрации время запущенного АС таймера T_Dereg истекает, АС должна отказаться от процедуры отмены регистрации и завершить действия по смене сети или выключению.

7.4.8 Энергосбережение

7.4.8.1 Общие положения

Транкинговая система в соответствии с требованиями настоящего стандарта должна поддерживать синхронизированную функцию энергосбережения.

АС должна синхронизироваться с временными параметрами, полученными в результате обмена взаимными служебными сообщениям в TSCC, и периодически переходить в состояние "сна". Вызовы, поступающие на эту АС, должны быть засинхронизированы с периодами энергосбережения, которые согласованы между АС и TSCC (см. рисунок 33).

Периоды энергосбережения определяются IE PS_Counter с подмножеством Common_Slot_Counter, передаваемым в CACH. АС, находящаяся в режиме "сна", должна быть приведена в активное состояние для назначенного периода энергосбережения. Если в нисходящем направлении TSCC должно быть передано служебное сообщение с использованием PDU или транзакция (передача информации) для АС, находящейся в режиме "сна", то этот PDU должен быть поставлен в очередь до тех пор, пока назначенный период энергосбережения не закончится в нисходящем направлении TSCC. АС или другой объект, который инициирует транзакцию (передачу информации) на АС, находящуюся в режиме "сна" (или группу АС), должны быть поставлены в очередь в TSCC, пока не закончится текущий период энергосбережения. Такие периоды показаны на рисунке 33. Для каждого логического канала имеется восемь таймслотов, доступных для сигнализации АС в течение установленного периода энергосбережения.

Рисунок 33 -

структура периода энергосбережения

Функция энергосбережения имеет следующие особенности:

а) АС и TSCC должны предварительно установить конкретный период выхода АС из режима "сна";

б) ТС, используя TSCC должна знать, когда конкретная АС стала активной (вышла из режима "сна") и способна принимать адресованные ей служебные сообщения и пользовательскую информацию. Если несколько АС входят в группу и участвуют в вызове разговорной группы, то все АС в этой разговорной группе могут совместно использовать один и тот же период пробуждения. Способ управления энергосбережением и выделение определенных периодов пробуждения не прописан в настоящем стандарте и определяется оборудованием контроллера ТС;

в) различные АС, использующие один и тот же TSCC, могут иметь различные режимы энергосбережения, поэтому TSCC и АС должны поддерживать любые из этих режимов;

г) сообщения SLC, содержащие счетчик энергосбережения, не обязательно передаются непрерывно. АС должны быть способны рассчитать периоды энергосбережения с момента получения SLC энергосбережения. АС могут периодически обновлять соответствующие PDU SLC.

7.4.8.2 Процедуры энергосбережения

Варианты циклов энергосбережения

Для использования режима энергосбережения АС должна быть зарегистрирована в ТС, используя TSCC. В запросе на регистрацию АС также должна отправить служебное сообщение об использовании режима энергосбережения с желаемыми для АС параметрами, содержащее ненулевой трехбитовый IE PowerSave_RQ с номером от 1 до 7.

Для отключения используемого режима энергосбережения или отказа от его использования АС должна отправить запрос о регистрации с нулевым PowerSave_RQ.

В случае запроса АС об использовании режима энергосбережения и невозможности его поддержки TSCC в его нисходящем направлении должно быть отправлено служебное сообщение C_NACKD с использованием IE Reason, соответствующего Reg_Denied.

ИС NORMPROD: примечание.

В официальном тексте документа, видимо, допущена опечатка: имеется в виду таблица 125, а не 102.

В случае запроса АС об использовании режима энергосбережения и ответа в нисходящем направлении TSCC служебным сообщением Response_Info (см. таблицу 102, пункт 16.3.8) с параметром IE PowerSave_Offset, установленным в значение 0, АС должна интерпретировать это как принятие регистрации без использования режима энергосбережения, так как он либо не поддерживается, либо недоступен.

Если TSCC поддерживает запрашиваемый АС режим энергосбережения, то в нисходящем направлении TSCC должно быть передано служебное сообщение, содержащее IE Response_Info с положительным ответом, являющееся ответом на запрос от АС. В служебном сообщении Response_Info, переданном в нисходящем направлении TSCC, должен быть указан применяемый для АС цикл энергосбережения с помощью числового значения PowerSave_Offset, переданный в IE Response_Info с длиной, равной 7 бит. Числовые значения, указывающие на тип цикла энергосбережения, находятся в диапазоне от 1 до 3, от 1 до 7, от 1 до 15, от 1 до 31, от 1 до 63 или от 1 до 127, что соответствует параметрам, указанным в таблице 19.

Таблица 19

IE и их значения для режима энергосбережения

при регистрации АС в транкинговой сети

Энергосбережение	PowerSave_RQ	PowerSave_Offset
OFF	0	0
1:2	1	1
1:4	2	От 1 до 3
1:8	3	От 1 до 7
1:16	4	От 1 до 15
1:32	5	От 1 до 31
1:64	6	От 1 до 63
1:128	7	От 1 до 127

В случае запроса АС об использовании режима энергосбережения и ответа в нисходящем направлении TSCC служебным сообщением с параметром IE PowerSave_RQ, установленным в значение 1, АС должна интерпретировать это как меандровый рабочий цикл АС в режиме энергосбережения, что означает пребывание в режиме "сна" в одном периоде и пробуждение в следующем (втором) рабочем периоде с использованием режима энергосбережения.

Использование в служебном сообщении IE PowerSave_RQ с числовым значением 2 означает, что АС должна выйти из режима "сна" и быть в активном состоянии в одном периоде энергосбережения, а находиться в режиме "сна" - во втором и третьем периодах рабочего цикла с использованием режима энергосбережения.

При наличии в служебном сообщении IE PowerSave_RQ с числовым значением 3 АС должна выйти из режима "сна" и быть в активном состоянии в одном периоде режима энергосбережения, а со второго по восьмой период находиться в режиме "сна", и так далее.

ИС NORMPROD: примечание.

В официальном тексте документа, видимо, допущена опечатка: имеется в виду таблица 19, а не 17.

В приведенных в таблице 17 возможных вариантах использования режима энергосбережения наибольшая экономия электроэнергии от источника электропитания для АС будет при PowerSave_RQ, установленном в значение 7, что означает пробуждение АС только в один активный период из возможных 128 периодов в режиме энергосбережения.

На запрос использования режима энергосбережения от АС TSCC при положительном решении отвечает подтверждением в служебном сообщении с использованием PDU Response_Info, содержащем значение PowerSave_Offset, в котором указан номер периода энергосбережения (рабочего цикла), который TSCC применяет к запрашивающей АС.

TSCC может отправлять усредненную сигнализацию по всем периодам энергосбережения для различных групп (или различных разговорных групп). АС должна считать номер периода энергосбережения, и, в зависимости от требуемого ей цикла режима энергосбережения, применить "Маску". Ответ на запрос содержит номер периода для значения энергосбережения, запрошенного при регистрации. В соответствии с полученным номером периода энергосбережения АС должна рассчитать свой временной график работы и режима "сна" (периоды, когда пробуждаться для принятия входящего трафика и когда находиться в режиме "сна").

Пример - АС запрашивает цикл работы с использованием режима энергосбережения, равного 4, установив PowerSave_RQ в запросе на регистрацию в значение 2. В этом случае в нисходящем направлении TSCC должно быть отправлено служебное сообщение PDU Response_Info с числовым значением Powersave_Offset, установленным в значение 2.

В АС счетчик рабочего цикла режима энергосбережения PS_Counter подсчитывает номер цикла.

Пример - Счетчик PS_Counter при увеличении рабочего цикла равен 65₁₀. В таблице 20 наглядно показано, как в TSCC определяется, когда "пробуждается" конкретная АС. TSCC применяет "Маску" длиной PowerSave_RQ. В приведенном примере "Маска" составляет два бита. При значении счетчика PS_Counter с "Маской", соответствующей PowerSave_Offset, TSCC может распознавать состояние АС и передавать ей информацию.

Таблица 20

Пример определения состояния АС в режиме энергосбережения

PS_Counter	Подсчет	Расчет "Маски" с PowerSave RQ								Состояние АС
...	...	...							...	...
65	010 0001₂	0	1	0	0	0	0	1	-	Сон
66	010 0010₂	0	1	0	0	0	1	0	-	Активное
67	010 0011₂	0	1	0	0	0	1	1	-	Сон
68	010 0100₂	0	1	0	0	1	0	0	-	Сон
69	010 0101₂	0	1	0	0	1	0	1	-	Сон
70	010 0110₂	0	1	0	0	1	1	0	-	Активное
...	...	..	..	..	..	..	..	..		...

АС может постоянно принимать CACH, передаваемый между таймслотами TSCC, считывать в нем PDU C_CYS_Parms со значением общего счетчика таймслотов Common_Slot_Counter длиной 9 бит и определять, когда будет период ее выхода из режима "сна" и перехода в активное состояние. Затем АС может находиться в режиме "сна" до периода ее "пробуждения".

PDU, передаваемый АС по ее индивидуальному адресу, должен содержать время "пробуждения" АС, определенное значением таймера T_Awake. Каждая АС, которой было направленно служебное сообщение по индивидуальному адресу или адресу разговорной группы, переданное с использованием PDU в нисходящем направлении TSCC, "пробуждается" с использованием таймера T_Awake. Если по истечении времени таймера T_Awake АС не передала и не приняла ни одного PDU, то она должна вернуться в режим "сна", сохраняя свои предыдущие настройки энергосбережения.

При работе в период активности цикла энергосбережения (в период "пробуждения") и получении PDU C_AHOY для вызова по принципу OACSU (который приведет к назначению рабочего канала и переключения на него АС) АС должна находиться в активном состоянии в течение всего времени T_Pending, обеспечивающего передачу PDU предоставления канала порядком, описанным в 16.2.2.4 ("Служебные сообщения PDU предоставления канала (P_GRANT) с использованием CSBK/MBC"). Когда такой вызов завершается и АС возвращается на TSCC, она должна ожидать в течение времени, определяемого таймером T_Awake, а затем вернуться в режим "сна".

Если АС вышла из режима "сна" и получает предназначенное ей PDU C_AHOY для вызова по принципу FOACSU, который приведет к назначению рабочего канала, она должна находится в активном состоянии в течение времени, определяемого таймером T_AnswerCall для передачи PDU предоставления канала, как описано в 16.2.2.4 ("Служебные сообщения PDU предоставления канала (P_GRANT) с использованием CSBK/MBC"). Когда этот вызов завершается и АС возвращается на TSCC, она должна ожидать в течение времени таймера T_Awake, а затем вернуться в режим "сна".

Когда во время периода активности цикла энергосбережения АС получает служебное сообщение C_MOVE PDU, она должна учитывать время своего таймера T_Awake и вернуться в режим "сна" по истечении времени этого таймера, если не был заменен TSCC и АС не была перерегистрирована, в результате чего был выполнен обмен IE, которые определили режим и цикл энергосбережения.

7.4.9 Процедуры аутентификации

7.4.9.1 Общие положения

Аутентификация представляет собой процедуру, позволяющую убедиться в подлинности АС на стороне ТС. ТС может затребовать процедуру аутентификации в процессе регистрации АС. Процедура аутентификации основана на генерации контрольного числа на обеих сторонах при помощи алгоритма шифрования, входными параметрами которого являются ключ аутентификации (K), PSN АС и случайное число RAND, генерируемое ТС. Когда АС пытается зарегистрироваться путем произвольного доступа, ТС в качестве запроса посылает трехбайтное случайное число (RAND) в служебном сообщении C_AHOY PDU и ожидает ответ. АС должна вычислить трехбайтное контрольное число и передать его в качестве ответа. ТС сравнивает сгенерированное у себя контрольное число с контрольным числом, полученным в ответе АС. Процедура аутентификации считается успешной, если оба контрольных числа совпадают. Процедура схематично показана на рисунке 34.

Рисунок 34 - Процедура аутентификации

В качестве процедуры генерации контрольного числа используется базовый блочный шифр "Магма" (описан в ГОСТ 34.12 и ГОСТ Р 34.12), как показано на рисунке 35. Контрольное число формируется за две итерации блочного шифра. Начальным заполнением входного регистра является синхропосылка <1> (Initializing Vector, IV, вектор инициализации) размером 64 бита, сформированная путем объединения RAND и PSN. Результат шифрования, полученный после первой итерации (итерация N₁), снова поступает во входной регистр. Старшие 24 бита шифртекста <1>, полученного после второй итерации N₂, являются контрольным числом, где C₂ - это старший байт контрольного числа, а C₀ - младший.

--------------------------------

<1> Определение к данному термину установлено в ГОСТ 34.12 и ГОСТ Р 34.12.

Рисунок 35 - Генерация контрольного числа

На рисунке 35 обозначены:

- RAND - случайное число;

- PSN - физический серийный номер АС;

- e_k - алгоритм шифрования с использованием ключа k;

- N₁, N₂ - первая и вторая итерации генерации шифртекста;

- C₂, C₁, C₀ - три байта контрольного числа.

Формирование вектора инициализации показано на рисунке 36. В регистр 1 загружается RAND, сдвинутый влево на 8 бит, младшие 8 бит регистра обнуляются. В младшие разряды регистра 2 загружается PSN, старшие 8 бит регистра 2 обнуляются. Результат сложения по модулю 2 регистров 1 и 2 заносится в регистр 3. Содержимое регистра 3 образует старшие 32 бита вектора инициализации. Затем содержимое регистра 3 модифицируется в LFSR для формирования младшей части вектора инициализации.

Рисунок 36 - Формирование вектора инициализации

Схема регистра LFSR показана на рисунке 37. Схема состоит из 32-ступенчатого сдвигового регистра, выполняющего сдвиг справа налево. Содержимое разрядов 31, 3 и 1 складывается по модулю 2, чтобы создать вход обратной связи для младшего разряда. Когда содержимое регистра 3 загружается в регистр LFSR, младшей частью вектора инициализации будет содержимое регистра LFSR после 32 сдвигов.

Рисунок 37 - Схема регистра LFSR

7.4.9.2 Управление ключами и PSN

Ключ аутентификации (K) длиной 56 бит должен быть уникальным для каждой АС и должен храниться в ее энергонезависимой памяти. Ключ аутентификации (K) каждой АС также должен быть известен ТС. Если ключ аутентификации конкретной АС скомпрометирован, он должен быть заменен как в АС, так и в контроллере управления сетью.

Формат ключа аутентификации, ограниченного до 56 бит, показан на рисунке 38. Ограничение должно быть реализовано методом замены всех младших 25 байт ключа алгоритма "Магма" (256 бит) на константу 01₁₆. Ограничение должно быть реализовано производителем в программаторе АС и в конфигураторе контроллера управления сетью.

Рисунок 38 - Формат ключа аутентификации

Описанный в настоящем стандарте PSN представляет собой физический серийный номер АС, который заносится в АС при производстве и должен удовлетворять следующим условиям:

- длина PSN - не менее 3 байт;

- PSN уникален для каждого произведенного образца;

- PSN невозможно изменить доступными пользователю инструментами (программатором);

- должна быть обеспечена возможность чтения PSN из АС для его занесения в контроллер управления сетью.

Ниже приведен пример генерации контрольного числа.

Пример - Генерация контрольного числа.

Входные данные для процедуры аутентификации:

- ключ аутентификации:

FFEEDDCCBBAA9901010101010101010101010101010101010101010101010101₁₆;

- случайное число (RAND): 123456₁₆;

- серийный номер АС (PSN): E5A4FD₁₆.

Формирование вектора инициализации:

- объединение RAND и PSN: 12D1F2FD₁₆;

- вектор инициализации: 12D1F2FDA0E6161A₁₆.

Генерация шифртекста представлена в таблице 21.

Таблица 21

Генерация шифртекста

Блок	Итерация 1	Итерация 2
Входной блок	12 D1 F2 FD A0 E6 16 1A	F2 AD 98 F8 2B B0 E0 BA
Выходной блок	F2 AD 98 F8 2B B0 E0 BA	A3 C0 DD 80 B9 1D E0 97

Выходные данные алгоритма шифрования:

- шифртекст: A3C0DD80B91DE097₁₆;

- контрольное число: A3C0DD₁₆.

7.4.9.3 Процедуры аутентификации для TSCC, выполняющего проверку подлинности АС

TSCC должен вызывать АС путем передачи PDU C_AHOY, содержащего IE, указанные в таблице 22, на индивидуальный адрес АС.

Таблица 22

IE из состава PDU C_AHOY для вызова аутентификации

Наименование	Длина, бит	Значение
Service_Options_Mirror	7	-
Service_Kind_Flag	1	0₂
ALS	1	0₂ - не применимо
G/I	1	0₂ - адрес получателя - это индивидуальный адрес АС
Appended_Blocks	2	00₂
Service_Kind	4	1110₂ - служба аутентификации
Target_Address	24	Адрес посылающей запрос АС
Source_Address или Gateway	24	Значение вызова аутентификации (должно находиться в интервале от 000000₁₆ до FFFCDF₁₆).

Если PDU C_AHOY передается в нисходящем направлении TSCC при проведении процедуры регистрации АС, то IE Service_Options_Mirror, передаваемый в восходящем направлении PDU C_AHOY, переключается с PDU C_Rand (описано в 16.2.2.3) на Service_Options.

Если PDU C_AHOY передается в ответ на запрос установки вызова, то Service_Options_Mirror переключается с PDU C_Rand на Service_Options.

Если PDU C_AHOY передается как опрос аутентификации от TSCC (и не связан с процедурой регистрации), Service_Options_Mirror должен быть установлен в значение 000 0000₂.

7.4.9.4 Процедуры аутентификации для АС

Если АС принимает относящееся к ней служебное сообщение C_AHOY PDU, она запускает алгоритм аутентификации. Результат работы этого алгоритма - последовательность аутентификации из 24 бит. Она передается в восходящем направлении TSCC с помощью служебного сообщения о подтверждении ответа C_ACKU PDU. Соответствующие IE показаны в таблице 23.

Таблица 23

IE отклика аутентификации

Наименование	Длина, бит	Значение
Response_Info	7	XXX XXXX₂
Reason	7	0100 1000₂ - отклик аутентификации
R	1	0₂
Target_Address	24	Отклик вызова аутентификации
Дополнительная информация (адрес источника)	24	Индивидуальный адрес АС, по которому передается подтверждение

7.4.10 Блокировка/разблокировка АС

7.4.10.1 Общие положения

АС может быть отказано в доступе к некоторым службам транкинговой сети ППР с помощью процедуры блокировки. Если АС была отключена с помощью такой процедуры, то она не может запрашивать или получать какие-либо инициированные пользователем службы транкинговой сети. Однако поиск и регистрация, аутентификация, блокировка/разблокировка остаются активными.

В то время как АС заблокирована, она может поддерживать службу опроса коротких данных NMEA (см. [1]), описанную в 7.5.4.2 ("Процедура опроса коротких данных от шлюза TSCC"). АС должна быть заблокирована/разблокирована из шлюза TSCC с помощью отправки идентификатора блокирования/разблокирования АС STUNI (см. А.5) в служебном сообщении, как описано в 7.4.10.2 ("Процедуры блокировки/разблокировки, передаваемые в TSCC").

7.4.10.2 Блокировка/разблокировка АС без аутентификации

Общие положения

На рисунке 39 показаны процедуры, при которых АС не требует аутентификации перед блокировкой.

Примечания

1 В нисходящем направлении TSCC к АС посылается служебное сообщение C_AHOY PDU [см. 16.2.2.2 ("Приветствие C_AHOY CSBK")] в заголовке управления LC с идентификатором, соответствующим процедуре блокирования/разблокирования STUNI (см. А.5) на этапе "А".

2 АС осуществляет соответствующее подтверждение на этапе "Б".

Рисунок 39 - Процедуры блокировки/разблокировки АС

Процедуры блокировки/разблокировки, передаваемые в TSCC

В нисходящем направлении TSCC передается PDU C_AHOY с IE, представленными в таблице 24.

Таблица 24

IE PDU C_AHOY для блокировки/разблокировки

Название	Длина, бит	Значение
Service_Options_Mirror	7	000 0000₂
Service_Kind_Flag	1	0₂ - для блокировки, 1₂ - для разблокировки
ALS	1	0₂ - не применимо
G/I	1	0₂ - PDU обращается по индивидуальному адресу АС
Appended_Blocks	2	00₂
Service_Kind	4	Дополнительная служба - 1101₂
Target_Address	24	Индивидуальный адрес блокируемой АС
Source_Address или Gateway	24	STUNI (см. А.5)

Примечания

1 Если получен ответ в PDU C_ACKU со значением IE Reason, соответствующим Message_Accepted, то TSCC подтверждает, что процедура блокировки/разблокировки прошла успешно.

2 Если получен ответ в PDU C_NACKU со значением IE Reason, соответствующим MSNot_Supported, то TSCC подтверждает, что блокировка/разблокировка не поддерживается АС.

Процедуры блокировки/разблокировки для АС

Если АС получает относящуюся к ней команду блокировки/разблокировки в PDU C_AHOY, но не поддерживает ее, то она должна отправить ответ в PDU C_NACKU со значением IE Reason, соответствующим MSNot_Supported.

Если АС получает относящуюся к ней команду блокировки/разблокировки в PDU C_AHOY и поддерживает ее, то она должна проверить полученное значение IE (флага) Service_Kind_Flag и в соответствии с полученным значением вызвать необходимую процедуру блокировки или разблокировки, а также отправить в восходящее направление TSCC ответ, содержащий PDU C_ACKU со значением IE Reason, соответствующим Message_Accepted.

7.4.10.3 Блокировка/разблокировка АС с аутентификацией

Общие положения

На рисунке 40 представлена процедура аутентификации TSCC до ее блокировки.

Рисунок 40 - Блокировка/разблокировка АС с аутентификацией

В ходе аутентификации:

а) в нисходящем направлении TSCC должен быть отправлен PDU C_AHOY с идентификатором, соответствующим процедуре блокирования/разблокирования STUNI (см. А.5) на этапе "А", для того чтобы заблокировать АС;

б) АС должна вызвать процедуру аутентификации TSCC на этапе "Б" путем передачи в восходящем направлении PDU C_ACVIT. Это служебное сообщение является ответом на предварительное подтверждение полученной команды с использованием PDU C_AHOY от TSCC;

в) на этапе "В" TSCC отправляет ответ на вызов от АС. АС проверяет подлинность ответа на вызов. Если ответ на вызов подтвержден АС, то она блокируется/разблокируется и посылает ответное PDU C_ACKU со значением IE Reason, соответствующим Authentication_Response. Если ответ на вызов не подтвержден, то АС должна отправить в ответ PDU C_NACKU со значением IE Reason, соответствующим Recipient_Refused (этап "Г") и не должна заблокироваться. TSCC может повторить этап "C", если ответ не будет успешно получен на этапе "Г";

г) на этапе "Г" должно быть отправлено окончательное подтверждение в TSCC. Если ответ на вызов подтвержден АС, то она блокируется/разблокируется и отправляет PDU C_ACKU со значением IE Reason, соответствующим Message_Accepted. Если ответ на вызов не подтвержден, то АС должна отправить PDU C_NACKU со значением IE Reason, соответствующим Recipient_Refused, и не должна заблокироваться. TSCC может повторить этап "В", если ответ не будет успешно получен на этапе "Г".

Процедуры блокировки/разблокировки с аутентификацией для TSCC

TSCC передает PDU C_AHOY с IE, приведенными в таблице 24.

Если в ответ АС передает служебное сообщение в PDU CSBK C_Ackvitation (C_ACKVIT) с параметрами, записанными в IE: адрес получателя - значение запроса, адрес источника - MS_ID, то TSCC должен интерпретировать этот PDU как подтверждение того, что TSCC является подлинным.

TSCC направляет ответ в PDU C_ACKD, в котором Reason соответствует Authentication_Response ("Отклик аутентификации") с IE, представленными в таблице 25.

Таблица 25

IE отклика аутентификации

Название	Длина, бит	Значение
Response_Info	7	XXX XXXX₂
Reason	8	0110 0100₂ - отклик аутентификации
R	1	0₂
Target_Address	24	Адрес заблокированной АС
Дополнительная информация (адрес источника)	24	Ответ на вызов аутентификации

Когда АС получает ответ на вызов от TSCC, она отправляет окончательное подтверждение:

а) если окончательное подтверждение, передаваемое АС в PDU C_ACKU, соответствует Message_Accepted, то TSCC определяет, что процедура блокировки/разблокировки прошла успешно;

б) если окончательное подтверждение, передаваемое АС в PDU C_NACKU, соответствует Recipient_Refused, то TSCC определяет, что аутентификация была неудачной.

Процедуры блокировки/разблокировки с аутентификацией для АС

Если АС получает команду на блокировку/разблокировку в PDU C_AHOY, но не поддерживает ее, то она должна отправить ответ в PDU C_NACKU со значением IE Reason, соответствующим MSNot_Supported.

Если АС получает команду на блокировку/разблокировку в служебном сообщении C_AHOY PDU, то она должна проверить подлинность TSCC путем передачи служебного сообщения C_Ackvitation PDU с IE, приведенными в таблице 26.

Таблица 26

PDU C_Ackvitation - АС вызывает TSCC

Название	Длина, бит	Значение
Service_Options_Mirror	7	000 0000₂
Service_Kind_Flag	1	0₂ - для блокировки, 1₂ - для разблокировки
R	2	0₂
Appended_Blocks	2	00₂
Service_Kind	4	Дополнительная служба - 1101₂
Target_Address	24	Значение вызова аутентификации. Значение вызова должно находиться в промежутке от 000000₁₆ до FFFCDF₁₆
Source_Address или Gateway	24	Индивидуальный адрес АС

АС должна проверить ответ на запрос аутентификации и проверить его подлинность. Затем АС должна отправить окончательное подтверждение путем передачи PDU C_ACKU со значением IE Reason, соответствующим MS_Accepted, если аутентификация прошла успешно, или передачи PDU C_NACKU со значением IE Reason, соответствующим Recipient_Refused, если аутентификация была неудачной.

Если АС поддерживает блокировку/разблокировку, она должна проверить значение IE (флага), записанного в Service_Kind_Flag, и вызвать соответствующую процедуру блокировки или разблокировки. IE, задействованные в окончательном подтверждении блокировки/разблокировки, приведены в таблице 27.

Таблица 27

IE окончательного подтверждения процедуры

блокировки/разблокировки

Название	Длина, бит	Значение
Response_Info	7	XXX XXXX₂
Reason	8	MS_Accepted - 0100 0100₂
Reason	8	Recipient_Refused - 0001 0100₂
R	1	0₂
Target_Address	24	STUNI (см. А.5)
Дополнительная информация (адрес источника)	24	Индивидуальный адрес АС

7.4.11 Безвозвратное приведение АС в неработоспособное состояние

7.4.11.1 Общие положения

АС может быть приведена в безвозвратное неработоспособное состояние с помощью процедуры "уничтожения" (KILLI). Если АС была отключена с помощью этой процедуры, то она теряет все функциональные возможности. АС не может быть восстановлена из этого состояния при помощи сгенерированного AI сообщения.

АС может быть приведена в безвозвратное неработоспособное состояние TSCC с помощью процедуры KILLI.

Рисунок 41 иллюстрирует процесс приведения АС в неработоспособное состояние:

а) TSCC посылает служебное сообщение C_AHOY PDU с идентификатором KILLI на этапе "А", чтобы привести АС в неработоспособное состояние;

б) АС получает команду в служебном сообщении C_AHOY PDU в следующем таймслоте и вызывает процедуру аутентификации на этапе "Б" путем передачи служебного сообщения C_ACVIT PDU. Этот ответ, посланный АС, является подтверждением первоначального служебного сообщения C_AHOY PDU, полученного от TSCC;

в) на этапе "В" TSCC отправляет АС ответ на вызов. АС проверяет подлинность ответа. Этот ответ может быть отложен в соответствии с выбором определенного времени произвольного доступа, установленного в 7.2.2.2 ("Ответы в нисходящем направлении TSCC на попытки произвольного доступа от АС");

г) на этапе "Г", если ответ на вызов подтвержден АС, то она должна послать служебное сообщение C_ACKU PDU со значением IE Reason, соответствующим Message_Accepted. После получения подтверждения АС отключает все свои функции. Если ответ на вызов не прошел подтверждение, то АС должна отправить служебное сообщение C_NACKU PDU со значением IE Reason, соответствующим Recipient_Refused ("Г"), сообщая о том, что процедура приведения в неработоспособное состояние не проведена.

АС может повторить шаг "Б", если ответ на вызов не был принят TSCC на этапе "В".

Рисунок 41 - Приведение АС в неработоспособное

состояние с аутентификацией

Примечание - Может возникнуть ситуация, когда окончательное подтверждение C_ACKU было отправлено АС (у АС отключены все функциональные возможности), но не было получено подтверждение от TSCC. В этом случае повторение процедуры "уничтожения" с этапа "А" не приведет к какой-либо реакции со стороны АС. TSCC следует учитывать возможность возникновения такой ситуации.

7.4.11.2 Процедуры приведения в безвозвратное неработоспособное состояние с аутентификацией TSCC

TSCC передает служебное сообщение C_AHOY PDU с IE, приведенными в таблице 28.

Таблица 28

IE C_AHOY PDU для приведения АС

в неработоспособное состояние

Название	Длина, бит	Значение
Service_Options_Mirror	7	000 0000₂
Service_Kind_Flag	1	0₂
ALS	1	0₂ - не применимо
G/I	1	0₂ - PDU обращается по индивидуальному адресу АС
Appended_Blocks	2	00₂
Service_Kind	4	Дополнительная служба - 1101₂
Target_Address	24	Индивидуальный адрес вызываемой АС
Source_Address или Gateway	24	KILLI (см. А.4)

Если АС в ответ посылает служебное сообщение C_Ackvitation PDU со следующими значениями IE: адрес получателя соответствует значению запроса, адрес источника соответствует MS_ID, то TSCC интерпретирует этот PDU как подтверждение и то, что необходимо дополнительное подтверждение подлинности TSCC.

TSCC направляет в ответ служебное сообщение C_ACKD PDU со значениями IE Reason, соответствующими Authentication_Response, которые приведены в таблице 29.

Таблица 29

IE элементы отклика аутентификации

Название	Длина, бит	Значение
Response_Info	7	XXX XXXX₂
Reason	8	0110 0100₂ - отклик аутентификации
R	1	0₂
Target_Address	24	Индивидуальный адрес "уничтожаемой" АС
Дополнительная информация (адрес источника)	24	Ответ на вызов аутентификации

После передачи ответа TSCC в сторону АС она должна отправить окончательное подтверждение:

а) если окончательное подтверждение, передаваемое АС, в служебном сообщении C_ACKU PDU соответствует Message_Accepted, то TSCC определяет, что процедура приведения в неработоспособное состояние АС прошла успешно;

б) если окончательное подтверждение, передаваемое АС, в служебном сообщении C_NACKU PDU соответствует Recipient_Refused, то TSCC определяет, что приведение в неработоспособное состояние АС не состоялось.

7.4.11.3 Процедуры "уничтожения" с аутентификацией для АС

Если АС получила PDU C_AHOY с указанием о приведении в неработоспособное состояние, но не поддерживает эту процедуру, то она должна отправить ответ в PDU C_NACKU, установив IE Reason в значение MSNot_Supported.

При получении АС служебного сообщения C_AHOY PDU для применения процедуры приведения в неработоспособное состояние (если функциональные возможности АС поддерживают такую процедуру), она должна проверить подлинность TSCC путем передачи служебного сообщения C_Ackvitation PDU в восходящем направлении TSCC с IE, перечисленными в таблице 30.

Таблица 30

IE служебного сообщения C_Ackvitation PDU при вызове АС TSCC

Название	Длина, бит	Значение
Service_Options_Mirror	7	0000 000₂
Service_Kind_Flag	1	0₂
R	2	0₂
Appended_Blocks	2	00₂
Service_Kind	4	Дополнительная служба - 1101₂
Target_Address	24	Значение вызова аутентификации. Значение вызова должно находиться в промежутке от 000000₁₆ до FFFCDF₁₆
Source_Address или Gateway	24	Индивидуальный адрес АС

АС проверяет ответ на вызов аутентификации и его подлинность. Затем АС должна отправить окончательное подтверждение в служебном сообщении C_ACKU PDU с установленным значением IE Reason, соответствующим MS_Accepted, если аутентификация прошла успешно, или служебное сообщение C_NACKU PDU с установленным значением IE Reason, соответствующим Recipient_Refused, если аутентификация была неудачной (как приведено в таблице 31).

Таблица 31

IE окончательного подтверждения

Название	Длина, бит	Значение
Response_Info	7	XXX XXXX₂
Reason	8	MS_Accepted - 0100 0100₂
Reason	8	Recipient_Refused - 0001 0100₂
R	1	0₂
Target_Address	24	KILLI (см. А.4)
Дополнительная информация (адрес источника)	24	Индивидуальный адрес АС

7.4.12 Подключение по интернет-протоколу IP

7.4.12.1 Рекомендации по подключению IP - общие положения

Для отправки IP-адреса при подключении к транкинговой сети АС должна использовать процедуры, указанные в 7.4.5, в целях регистрации (или повторной регистрации) в TSCC (см. примечание).

Примечание - АС может быть уже зарегистрирована в транкинговой сети. Однако повторение процедуры регистрации является удобным механизмом для передачи IP-адреса подключения.

В запросе на регистрацию для определения опций предоставления услуги в служебном сообщении АС должна установить IE IP_Inform в соответствии со следующими правилами. Если АС регистрируется с IP_Inform, установленным в значение 1₂, то TSCC должен вызвать процедуры регистрации с использованием механизма UDT и отправить служебное сообщение AHOY PDU, запрашивая у АС IP-адрес ее подключения, при этом:

а) АС может повторить эту процедуру, если у нее есть несколько IP-адресов для отправки в ТС;

б) АС может удалить подключение IP путем отправки отмены регистрации служебным сообщением с установкой IE Reg_Dereg - в значение 0₂ и IP_Inform - в 1₂ (эта комбинация IE не отменяет регистрацию самой АС).

Если у TSCC имеются IP-адреса для зарегистрированных АС, то в нем могут быть установлены перекрестные ссылки на IP-адрес с индивидуальным адресом АС при условии, что АС активировала режим энергосбережения.

Порядок подключения АС с использованием интернет-протокола показан на рисунке 42. На рисунке продемонстрирован обмен служебными сообщениями с использованием механизма PDU для добавления или удаления подключения IP и запроса использования режима энергосбережения.

Рисунок 42 - Порядок подключения АС

с использованием интернет-протокола

Рисунок 42 иллюстрирует процедуру регистрации АС с опциональными этапами "Б" и "В":

а) на этапе "А" АС совершает попытку регистрации произвольного доступа с установкой IE IP_Inform в значение 1₂;

б) с целью подтверждения возможности произвольного доступа и разрешения на подключение IP для АС должно быть отправлено служебное сообщение AHOY PDU на этапе "Б" и должен быть запущен таймер TNP_Timer;

в) АС должна отреагировать на служебное сообщение от TSCC в "C" ответом в формате UDT IP;

г) в нисходящем направлении TSCC к АС должны быть отправлены служебные сообщения C_ACKD PDU или C_NACKD PDU, являющиеся окончательным ответом о возможности предоставления услуги.

7.4.12.2 Процедуры подключения IP для АС

Общие положения

Если АС необходимо изменить подключение IP (добавить или удалить IP-адрес), она должна сделать это с помощью процедур регистрации, указанных в 7.4.5. Признаком того, что запрос регистрации выполняется с целью обеспечения подключения услуги, обеспечивающей соединение АС с использованием интернет-протокола (IP connection advice), является IE IP_Inform, который должен быть установлен в значение 1₂ в IE Service_Options (см. 16.3.14). Этот элемент определяет вид запрашиваемой услуги в PDU C_RAND (см. 7.4.5, таблица 15).

В нисходящем направлении TSCC должен быть отправлен один из ответов в виде служебных сообщений на запрос произвольного доступа:

- C_WACKD PDU с установкой IE Reason в значение Wait для получения дополнительной сигнализации;

- C_NACKD PDU (Reason соответствует Reg_Refused) или C_NACKD PDU (Reason соответствует Reg_Denied) с адресом назначения PDU, соответствующим адресу АС ID, и адресом источника REGI;

- C_NACKD PDU (Reason соответствует IP_Connection_failed) с адресом назначения PDU, соответствующим адресу АС ID, и адресом источника IPI;

- C_AHOY PDU с адресом назначения PDU, соответствующим адресу АС ID, и адресом источника - IPI.

Если АС получен любой из следующих ответов, то регистрация прошла успешно:

- C_AHOY PDU от источника или шлюза с ранее запрошенным адресом IPI, приглашающий АС отправить адрес соединения IP;

- C_NACKD PDU (Reason соответствует IP_Connection_failed), что указывает на то, что регистрация проведена, но IP-сервисы недоступны в этом сайте.

Если АС приняла C_NACKD PDU со значением Reason, соответствующим IP_Connection_failed, то дальнейшие действия АС (остаться в этом сайте и продолжить работу без подключения IP или осуществлять поиск нового сайта) определяются производителем оборудования.

Попытка регистрации истекла

Если время ожидания АС сигнализации для запроса подключения IP истекло и АС не была зарегистрирована ранее (истечение времени таймера TNP_Timer), то она должна выполнить процедуры обнаружения TSCC. Если АС была ранее зарегистрирована, то она должна вернуться в исходное состояние на TSCC.

Действия в случае отсутствия ответа после отправки максимально разрешенного числа попыток произвольного доступа

Если ответ не будет получен в пределах таймслотов WAIT плюс 1 после того, как АС произвела попытки произвольного доступа NRand_NR путем передачи служебных сообщений, она не должна делать никаких последующих изменений в записи подключения IP.

Ответ АС на C_AHOY PDU для отправки IP-адреса

АС должна послать IP-адрес с помощью процедуры UDT. Ответ должен быть передан в виде служебного сообщения, состоящего из заголовка (HEAD) и приложенных данных. IE HEAD должны быть установлены в значения: UDT_Format - в 0110₂, UAB - в 00₂ для IPV4 или UAB - в 01₂ для IPV6, SF - в 1₂, Target_Address должен соответствовать ID АС, а Source_Address - IPI.

Окончательное подтверждение подключения IP

АС может получить служебное сообщение C_ACKD PDU со значением IE Reg_Accepted. В этом случае TSCC предоставляет АС услугу подключения IP.

В случае отказа TSCC от использования услуги подключения IP АС должна получить служебное сообщение C_NACKD PDU с IE Reason, установленным в значение IP_Connection_failed. В этом случае услуга подключения IP отклонена TSCC. В случае такого отказа АС не должна проводить у себя никаких изменений в записи подключений IP.

7.4.12.3 Процедуры подключения IP для TSCC

При получении TSCC служебного сообщения с запросом о регистрации произвольного доступа с IP_Inform, установленным в значение 1₂, TSCC должен получить адрес IP-соединения. Для получения адреса IP-соединения TSCC отправляет в нисходящем направлении служебное сообщение C_AHOY PDU от IPI с требованиями АС отправить IP-адрес с помощью механизма UDT.

TSCC может передавать любое из подтверждений в виде служебных сообщений с установленными параметрами: C_WACKD PDU (Reason соответствует Wait) для ожидания дополнительной сигнализации, C_NACKD PDU (Reason соответствует Reg_Refused), C_NACKD PDU (Reason соответствует Reg_Denied) или C_AHOY PDU (адрес источника или шлюза соответствует IPI). Если ответ служебным сообщением в нисходящем направлении TSCC является подтверждением, то адрес назначения в служебном сообщении с использованием PDU должен быть ID АС, а адрес источника - REGI.

TSCC может по какой-либо причине не принять IP-адрес. В этом случае в нисходящем направлении TSCC должно быть направлено служебное сообщение C_NACKD PDU с параметром в IE Reason, соответствующем IP_Connection_failed. В этом случае TSCC не должен изменять запись подключения IP.

7.4.13 Проверка радиодоступности АС без установления вызова

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

Рисунок 43 иллюстрирует обмен сообщениями для проверки радиодоступности в произвольные моменты времени по TSCC методом отправки в нисходящем направлении к АС служебного сообщения C_AHOY PDU.

Рисунок 43 - Проверка радиодоступности АС

с использованием TSCC

ТС может провести проверку радиодоступности как с индивидуальной АС, в том числе находящейся в разговорной группе, так и со всеми АС разговорной группы.

Проверка радиодоступности АС также может проводиться с использованием рабочих каналов методом отправки в нисходящем направлении к АС служебного сообщения P_AHOY PDU.

Структура служебного сообщения в структуре CSBK PDU, направляемого ТС в нисходящем направлении каналов обоих типов, представлена в таблице 32.

Таблица 32

IE C_AHOY/P_AHOY PDU для проверки радиодоступности АС

в произвольные моменты времени в нисходящем

направлении каналов

Название	Длина, бит	Значение
Service_Options_Mirror	7	000 0000₂
Service_Kind_Flag	1	0₂ - не применимо
ALS	1	0₂ - не применимо
G/I	1	0₂ - адрес получателя - ID АС
G/I	1	1₂ - адрес получателя - разговорная группа
Appended_Blocks	2	00₂
Service_Kind	4	Регистрация/аутентификация/проверка радиодоступности АС - 1110₂
Target_Address	24	Опрошенная АС
Source_Address или Gateway	24	TSI (см. А.5)

При получении запроса радиодоступности в виде сообщения C_AHOY/P_AHOY PDU АС направляет ответ служебным сообщением C_ACKU PDU с установленными параметрами Reason, соответствующими Message_Accepted, и структурой IE, описанных в таблице 33.

Таблица 33

Параметры IE ответа АС при проверке радиодоступности

Название	Длина, бит	Значение
Response_Info	7	XXX XXXX₂
Reason	8	0100 0100₂
R	1	0₂
Target_Address	24	TSI
Дополнительная информация (адрес источника ответа)	24	Индивидуальный адрес опрашиваемой АС

В запросе проверки радиодоступности АС адрес источника в служебном сообщении C_ACKU PDU всегда должен соответствовать индивидуальному адресу АС вне зависимости от того, была ли АС опрошена по ее индивидуальному адресу или в разговорной группе.

7.4.14 Услуга передачи дополнительных данных пользователя

7.4.14.1 Общие положения

Услуга передачи дополнительных данных пользователя может применяться как часть другой услуги. Это позволяет передавать дополнительные данные пользователя между объектами в сети ППР в рамках установления речевого или информационного вызова.

АС должна запрашивать дополнительные данные при установлении вызова путем отправки служебного сообщения C_RAND PDU с IE Service_Options SUPED_SV, находящимся в значении 1₂. Если TSCC не поддерживает дополнительные данные или не желает их принять в текущее время, то по TSCC следует выполнить одно из следующих действий:

а) продолжать обрабатывать установление вызова и отказаться от запроса на дополнительные данные пользователя;

б) передать служебное сообщение C_NACKD PDU, чтобы указать на сбой вызова.

7.4.14.2 Инициация и передача дополнительных данных от АС к источнику их запроса (восходящая фаза)

Инициация передачи дополнительных данных от АС должна быть выполнена с помощью отправки запроса к АС служебного сообщения C_AHOY PDU в нисходящем направлении TSCC (см. рисунок 44). В служебном сообщении C_AHOY PDU, адресованном АС, должны быть установлены следующие параметры: адрес источника соответствует SUPLI, IE Service_Kind соответствует значению IE Service_Kind из служебного сообщения C_RAND, которым был инициировал вызов. Ответом АС является многоблочное служебное сообщение UDTHU PDU с параметрами: адрес источника соответствует ID АС, Target_Address соответствует SUPLI с добавлением от одного до четырех блоков дополнительных данных.

Для обеспечения услуги передачи дополнительных данных в восходящем направлении TSCC обмен такими данными должен осуществляться после запроса AHOY/Acknowledgement в блоках CSBK PDU, которые являются частью установления вызова.

Рисунок 44 - Услуга передачи дополнительных данных АС

в восходящем направлении TSCC

IE C_AHOY PDU показаны в таблице 34.

Таблица 34

Состав и содержание C_AHOY PDU для запроса передачи

дополнительных данных от запрашиваемой АС

к источнику запроса

Название	Длина, бит	Значение
Service_Options_Mirror	7	000 0000₂
Service_Kind_Flag	1	0₂ - не применимо
ALS	1	0₂ - не применимо
G/I	1	0₂
Appended_Blocks	2	Количество добавочных блоков данных
Service_Kind	4	Service_Kind из C_RAND, использующихся при установлении вызова
Target_Address	24	Адрес инициировавшей вызов АС
Source_Address или Gateway	24	SUPLI

IE UDT блоков PDU для передачи в восходящем направлении дополнительной информации, запрошенной с помощью C_AHOY PDU, приведены в таблице 35.

Таблица 35

Состав и содержание многоблочного сообщения с использованием

UDT PDU для передачи дополнительных данных

в восходящем направлении от АС

Длина, бит

Комментарий

Функциональные элементы

& G/I

0₂ соответствует назначению - индивидуальный адрес АС

1₂ соответствует назначению - разговорная группа

0₂

UDT_DIV

0₂

& Формат

0000₂

& SAP

Точка доступа к услуге - 0000₂ для UDT

UDT_Format

Формат данных, следующих за заголовком UDT

& Target_Address или Gateway

SUPLI

& Source_Address или Gateway

ID, инициировавшей вызов АС

0₂

UAB

Количество блоков, приложенных к этому UDT заголовку

00₂ = 1 UDT блок добавочных данных;

01₂ = 2 UDT блока добавочных данных;

10₂ = 3 UDT блока добавочных данных;

11₂ = 4 UDT блока добавочных данных

1₂ = Этот заголовок UDT, содержащий дополнительные данные и поддерживающий другие услуги уровня 3

Зарезервирован для использования в будущем

Код операции (UDTHU)

Должен быть установлен в значение 01 1011₂

ИС NORMPROD: примечание.

Здесь и далее ячейки таблицы, обведенные утолщенной линией в официальном тексте документа, в электронной версии документа обозначены символом "&".

Примечание - IE, определенные в ГОСТ Р 71586.1, обведены утолщенной линией.

Структура дополнительных данных и количество добавочных блоков должны быть заранее определены между транкинговой системой и АС.

7.4.14.3 Инициация и передача дополнительных данных от запрашиваемой АС к источнику запроса (нисходящая фаза)

Передача дополнительных данных к АС, запрашивающей такие данные, показана на рисунке 45.

АС должна использовать многоблочный PDU с применением служебного сообщения C_UDTHD PDU со следующими параметрами: адрес источника соответствует SUPLI, Target_Address соответствует ID АС, а также с добавлением от одного до четырех добавочных блоков данных. Если АС принимает дополнительные данные пользователя, то подтверждение должно быть с использованием C_ACKU PDU с параметрами message_accepted, а также с Source_Address, соответствующими ID АС, и Target_Address, соответствующим SUPLI.

Рисунок 45 - Услуга передачи дополнительных данных

пользователя в нисходящем направлении к АС от TSCC

IE UDT заголовка для передачи в нисходящем направлении приведены в таблице 36.

Таблица 36

Дополнительные данные заголовка UDT контента PDU

IE	Длина, бит	Комментарий
Функциональные элементы
& G/I	1	0₂ = назначение - индивидуальный адрес АС
& G/I	1	1₂ = назначение - адрес разговорной группы. Ответ не предполагается
A	1	1₂ = необходим ответ, если назначение - это индивидуальный адрес АС
Критическое положение	1	0₂ = этот PDU не поддерживает приоритетный экстренный вызов
Критическое положение	1	1₂ = этот PDU поддерживает приоритетный экстренный вызов
UDT_Option_Flag	1	См. 16.3.13.3 ("IE UDT_Option_Flag")
& Формат	4	0000₂
& SAP	4	SAP - 0000₂ для UDT
UDT_Format	4	Формат данных, следующих за заголовком UDT
& Target_Address или Gateway	24	Вызываемый абонент
& Source_Address или Gateway	24	SUPLI
PN	5	-
R	1	0₂
UAB	2	Количество блоков, приложенных к этому UDT заголовку: 00₂ = 1 UDT-блок добавочных данных; 01₂ = 2 UDT-блока добавочных данных; 10₂ = 3 UDT-блока добавочных данных; 11₂ = 4 UDT-блока добавочных данных
SF	1	1₂ = этот заголовок UDT, содержащий дополнительные данные и поддерживающий другие услуги уровня 3
PF	1	Зарезервирован для использования в будущем
Код операции (UDTHU)	6	Должен быть установлен в значение 01 1010₂
Примечание - IE, определенные в ГОСТ Р 71586.1, обведены утолщенной линией.

Для услуги передачи дополнительных данных в нисходящем направлении TSCC к АС, а также вызовов, которые не выделяют канал (например, передача коротких данных с использованием механизма UDT), завершающий блок UDT многоблочного PDU, несущий полезную нагрузку (получаемые данные), должен быть последним блоком UDT в нисходящем направлении от TSCC к АС. То есть запрос передачи дополнительных данных в нисходящем направлении должен предшествовать передаче многоблочного UDT с полезной нагрузкой (передаваемыми дополнительными данными от TSCC).

Пример полного цикла речевого вызова, ссылающегося на дополнительные данные пользователя, показан на рисунке 46.

	Aloha		Ahoy		Заголовок UDT для добавленных данных		Предоставление канала
	Запрос произвольного доступа		Подтверждение		Добавленные данные - данные GPS		Получатель сообщения

Рисунок 46 - Процедура UDT, в ходе которой осуществляется

передача дополнительных данных для речевого вызова

В этом примере TSCC принимает дополнительные данные.

Описание процедуры:

а) "А", когда АС(А) посылает запрос вызова, тогда АС(А) устанавливает SUPED_SV, указывающий, что запрашиваются дополнительные данные [источник - АС(А), получатель - АС(Б)];

б) "Б", TSCC посылает AHOY [получатель - АС(А), источник - SUPLI];

в) "В", АС(А) посылает HEAD [получатель - АС(А), источник - SUPLI плюс AD (дополнительные данные)];

г) "Г", TSCC посылает HEAD [источник - SUPLI, получатель - АС(Б) плюс AD (дополнительные данные)];

д) "Д", АС(Б) посылает ACK [источник - АС(Б), получатель - SUPLI];

е) "Е", TSCC посылает CG [источник - АС(А), получатель - АС(Б)].

В описанном варианте в служебном сообщении AHOY проверка радиодоступности вызываемым абонентом не была отправлена TSCC. Тот факт, что при передаче данных в АС от TSCC (нисходящей фазе) ответом АС(Б) на дополнительные данные было HEAD с AD, информирует TSCC, что АС(Б) приняла дополнительные данные, но не знает адрес отправителя, поскольку адрес вызывающего абонента не включен в заголовок HEAD PDU многоблочного сообщения (вызываемый абонент будет знать адрес вызывающего абонента только в том случае, если отправляются блоки CG PDU). Вызываемый абонент указал, что он прослушивает TSCC, но не имеет возможности отклонения вызова [возможно, потому, что АС(Б) не желает принимать вызовы от АС(А)]. TSCC может отправить запрос проверки радиодоступности с использованием AHOY перед отправкой дополнительных данных на АС(Б).

Пример короткого информационного вызова, ссылающегося на дополнительные данные пользователя, показан на рисунке 47.

Рисунок 47 - Процедура UDT, в ходе которой осуществляется

передача дополнительных данных для короткого

информационного вызова

Описание процедуры:

а) "А", когда АС(А) инициирует запрос короткого информационного вызова произвольного доступа, АС(А) устанавливает SUPED_SV, указывающий, что запрашиваются дополнительные данные [источник - АС(А), получатель - АС(Б)];

б) "B", TSCC посылает AHOY [получатель - SUPLI, источник - АС(А)];

в) "C", АС(А) посылает HEAD [получатель - АС(А), источник - SUPLI с AD (дополнительные данные)];

г) "Г", TSCC посылает AHOY [получатель - SDMI, источник - АС(А)];

д) "Д", АС(А) посылает HEAD [получатель - АС(А), источник - SDMI с AD (пользовательские данные)];

е) "Е", TSCC посылает HEAD [источник - SUPLI, получатель - АС(Б) с AD (дополнительные данные)];

ж) "Ж", АС(Б) посылает ACK;

и) "И", TSCC посылает заголовок HEAD [источник - АС(А), получатель - АС(Б) с AD (пользовательские данные)];

к) "К", АС(Б) посылает ACK;

л) "Л", TSCC посылает АС(А) окончательное сообщение подтверждения ACK.

На этапе, когда дополнительные данные были получены на АС(Б), АС(Б) не знает, кто их отправил. Источник идентифицируется на фазе выгрузки пользовательских данных. Поэтому АС(Б) хранит дополнительные данные до того времени, пока фаза выгрузки пользовательских данных не будет завершена.

7.4.15 Управление мощностью АС и размыкание PTT

7.4.15.1 Общие положения

Управление мощностью с обратной связью представляет собой метод, с помощью которого ТС способна динамически управлять выходной мощностью передатчика АС. Если ТС или АС в транкинговой сети поддерживают эту функцию, то функция должна быть реализована согласно требованиям, определенным в настоящем разделе.

Транкинговая сеть может использовать АС, которые поддерживают или не поддерживают эту функцию. Кроме того, данная функция использует RC, а он не всегда может быть доступен. Этот фактор должен учитываться при создании транкинговой системы.

Принцип управления мощностью: ТС измеряет мощность принимаемого сигнала передающей АС и сравнивает полученное значение с двумя программируемыми порогами. Пороговые значения представляют собой верхний предел для мощности принимаемого сигнала (L_Power_Hi) и нижний предел (L_Power_Low). Если мощность принимаемого сигнала превышает порог L_Power_Hi, то ТС отправляет служебное сообщение с использованием PDU для снижения мощности на АС. Если уровень сигнала ниже нижнего предела L_Power_Low, то АС отправляет служебное сообщение к АС с использованием PDU управления мощностью для ее увеличения.

Принцип размыкания PTT: размыкание PTT может быть реализовано с целью принудительного прерывания передачи АС, для того чтобы этот канал мог использоваться для обслуживания нового вызова с более высоким приоритетом.

7.4.15.2 Обратный канал

И управление мощностью АС, и размыкание PTT используют обратный канал. 4 бита команды RC обратного канала приведены в таблице 37.

Таблица 37

IE обратного канала АС для управления мощностью

и контролем передатчика

Команда RC
Длина, бит	Значение	Описание
4	0000₂	Увеличивает мощность на одну ступень
	0001₂	Уменьшает мощность на одну ступень
	0010₂	Устанавливает самую высокую мощность
	0011₂	Устанавливает самую низкую мощность
	0100₂	Останавливает команду передачи
	0101₂	Прекращает запрос передачи
	От 0110₂ до 1111₂	Зарезервировано для будущего использования
Примечание - Размер шага между ступенями мощности (Power step) устанавливает производитель.

7.4.15.3 Процедуры управления мощностью

Если АС получает служебное сообщение в RC управления с использованием PDU с командами RC, установленными в значения 0000₂, 0001₂, 0010₂, то она должна изменить настройку мощности передачи. Если АС осуществляет передачу на максимальной мощности и получает команду RC "увеличение мощности", она должна сохранять свою максимальную настройку мощности. Аналогичным образом, если АС осуществляет передачу на минимальной мощности и получает команду "уменьшение мощности", она должна сохранять минимальную настройку мощности.

7.4.15.4 Процедуры размыкания PTT

АС может поддерживать принудительное размыкание PTT при получении служебного сообщения. ТС должна передать один или несколько блоков PDU с командой RC, установленной в значение 0100₂ (команда прекращения передачи), чтобы АС прекратила передачу. АС, получив команду о прекращении текущего вызова, останавливает передачу в конце текущего речевого суперкадра, как это определено в ГОСТ Р 71586.2-2024 [подпункт 7.2.2.3 ("Окончание передачи речи")].

ТС должна контролировать активность АС в канале, чтобы установить, прекратила ли АС свою радиопередачу. Если АС не прекратила передачу, то возможно, что АС не смогла принять PDU RC (он был потерян в радиоканале или АС не поддерживает данную функцию).

TSCC также может передавать один или несколько блоков PDU с командой RC, установленной в значение 0101₂ (запрос прекращения передачи), чтобы позволить АС определить свои системные установки (должна ли она прекратить передачу или продолжать ее). Если АС принимает решение прекратить передачу, то это должно произойти в конце речевого суперкадра, как это определено в ГОСТ Р 71586.1-2024 [подпункт 7.2.1.3 ("Окончание передачи речи")].

7.4.16 Прерывание передачи

7.4.16.1 Прерывание, инициированное TSCC

Процедуры, определенные настоящим стандартом, поддерживают вызовы с экстренным высоким приоритетом. Если рабочий канал (канал полезной нагрузки) не доступен во время инициализации экстренного вызова с высоким приоритетом, то TSCC с помощью отправки в рабочем канале одного или нескольких служебных сообщений CSBK P_Clear PDU может прервать вызов с более низким приоритетом. Такие сообщения не требуют ответа от участвующего в вызове абонента. Затем TSCC может инициировать экстренный вызов с высоким приоритетом на этом рабочем канале.

Если один из участвующих в вызове абонентов ведет радиопередачу, то должно быть инициировано принудительное размыкание PTT с помощью RC (команда RC - 0100₂), описанное в 7.4.15.4, чтобы заставить АС прекратить передачу. После окончания передачи управляющих входящих блоков PDU рабочий канал может отправить один или несколько CSBK P_Clear PDU, чтобы завершить существующий вызов и дать возможность экстренному приоритетному вызову использовать этот рабочий канал.

7.4.16.2 Команда принудительного прерывания передачи по рабочему каналу

Принудительное прерывание передачи по рабочему каналу - общие положения

Если участвующей в вызове АС необходимо прервать передачу той АС, которая участвует в текущем вызове, и ТС принимает решение передать служебное сообщение о прекращении радиопередачи прерываемой АС с помощью TSCC, то должна быть применена процедура, описанная в настоящем разделе.

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

Чтобы вызвать прерывание текущего вызова абонентской станции с меньшим приоритетом, прерывающая АС должна освободить рабочий канал и перейти в TSCC, инициируя вызов, запрашивающий состояние Status установлен в значение 125 и адресованный:

а) при индивидуальном вызове - той АС, передача которой будет прервана (с указанием ее ID);

б) при вызове разговорной группы - прерываемой разговорной группе (с указанием ее адреса).

TSCC должен ответить подтверждением (источник - TSI, получатель - прерывающая АС). Если в запросе на прерывание отказано, то по TSCC прерывающей АС передается служебное сообщение C_NACKD PDU. Если запрос на прерывание от АС-инициатора прерывания получен, то ей по TSCC передается служебное сообщение C_ACKD PDU. Прерывающая АС должна вернуться на рабочий канал.

Если в прерывании отказано, то текущий вызов не должен быть прерван.

Если прерывание выполняется, то прерывающая АС должна ждать PDU в нисходящем направлении TSCC, в котором будет указано, что прерывающая АС может осуществлять передачу.

На рисунке 48 показан пример прерывания текущего вызова в рабочем канале.

	Aloha		Ahoy		Предоставление канала	Sync		RC		Terminator_with_LC
	Запрос произвольного доступа		Подтверждение		Получатель сообщения		Речевая полезная нагрузка			Речевой заголовок

Рисунок 48 - Прерывание рабочего канала

Прерывание рабочего канала включает следующие этапы и подпункты:

а) этап "А" - осуществляется текущий речевой вызов. АС(А) и АС(Б) заняли рабочий канал текущим речевым вызовом. Текущий вызов может быть либо индивидуальным, либо вызовом разговорной группы. В рабочих каналах используется синхронизация передачи трафика с выравниванием каналов. АС(А) передает речевые кадры на АС(Б). АС(Б) необходимо прервать передачу АС(А);

б) позиция "Б" - АС(Б) должна покинуть рабочий канал и, как только протокол произвольного доступа даст разрешение, совершить вызов состояния. Вызываемый абонент - АС(А), вызывающий абонент - АС(Б), IE Service_Kind должен быть установлен как "Status". Значение его состояния 125 (11 1101₂) должно быть определено TSCC как запрос прерывания передачи;

в) позиция "C" - если TSCC принимает запрос на прерывание АС, осуществляющей текущую передачу по рабочему каналу, то должно быть отправлено служебное сообщение о подтверждении C_ACKD PDU с параметром Reason, соответствующим Message_Accepted. Если TSCC не принимает запрос на прерывание, то подтверждение должно быть отправлено в служебном сообщении C_NACKD PDU с параметром Reason, соответствующим Not_Supported или Perm_User_Refused. Если TSCC не принимает запрос, то АС(А) продолжает текущий вызов без перерыва. Если TSCC принимает запрос на прерывание, то должны последовать действия, перечисленные в д), е) и ж);

г) позиция "Г" - АС возвращается на рабочий канал;

д) этап "Е" - это RC. Команда RC соответствует 0100₂ (команда прекращения передачи);

е) позиция "Е" - АС(А) прекращает передачу;

ж) на этапе "Ж" передача речи АС(Б) полностью осуществляется на рабочем канале.

Для того чтобы предотвратить передачу другими участвующими в вызове абонентами после того, как прерывание было принято, рабочий канал должен отправить блоки служебного сообщения P_PROTECT PDU с параметрами IE (Protect_Kind соответствует EN_PTT_ONE_MS) с адресом АС(Б) в качестве адреса получателя.

Процедуры TSCC и ТС для прерывания передачи на рабочем канале

Если TSCC получает сообщения о попытке произвольного доступа с вызовом состояния со значением, равным 125, то адрес вызываемого абонента должен быть сопоставлен с ID АС, вовлеченных в речевые вызовы на рабочих каналах. Если происходит совпадение адреса вызываемого абонента с ID АС, то TSCC воспринимает это как запрос на прерывание передачи.

Если прерывание передачи невозможно, то TSCC должен отправить ответ прерывающей АС в служебном сообщении C_NACKD PDU со следующими параметрами IE: источник - TSI, получатель - прерывающая АС.

Если прерывание передачи возможно, то:

а) TSCC должен отправить служебное сообщение C_ACKD со следующими параметрами IE (Message_Accepted): источник - TSI, получатель - прерывающая АС;

б) ТС должна отправить команду 0100₂ в RC (команда прекращения передачи) на соответствующий рабочий канал и ждать, пока передающая АС прекратит передачу.

ТС может отправить служебные сообщения P_Protect PDU с IE Protect_Kind, соответствующим EN_PTT_ONE_MS, в нисходящем направлении рабочего канала, чтобы предотвратить передачу другими АС, кроме прерывающей. ТС должна ограничить количество служебных сообщений P_Protect PDU, чтобы занимающая рабочий канал АС могла продолжить передачу, если по какой-либо причине прерывание передачи не произойдет.

Процедуры прерывающей АС для прерывания передачи на рабочем канале

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

Прерывающая АС должна вернуться на TSCC. При обнаружении TSCC АС должна сделать запрос о состоянии вызова (Status установлен в значение 125) для прерываемой АС. АС должна отправить служебное сообщение в ответ TSCC. Если в ответе содержится служебное сообщение C_NACKD PDU с параметрами IE Reason, соответствующими Not_Supported или Perm_User_Refused, то АС воспринимает запрос на прерывание как неудачный. Если ответ является служебным сообщением C_ACKD PDU, в котором Reason соответствует Message_Accepted, то запрос на прерывание должен интерпретироваться как успешный.

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

Если запрос на прерывание прошел успешно, то АС должна ждать нисходящие PDU и биты AT в CACH, указывающие на остановку передачи прерывающей АС. Прерывающая АС затем может принудительно разомкнуть PTT АС, осуществляющей текущий вызов. В зависимости от конструктивных особенностей АС может обеспечиваться визуальная и/или звуковая индикация об этом событии для прерванного пользователя.

Процедуры АС для прерываемой АС

В период активности на рабочем канале и во время осуществления передачи АС должна контролировать нисходящий RC. Если в этом RC получена команда 0100₂ (команда прекращения передачи), то АС завершает свой речевой суперкадр путем передачи речевого пакета "F", отправляет PDU Terminator_with_LC, а затем прекращает передачу. После этого АС должна контролировать нисходящий канал и соблюдать процедуры, определенные в 7.5.3.3.

7.4.16.3 Запрос на прерывание в рабочем канале

Общие положения

Если участвующая в текущем вызове АС должна прервать того, кто ведет радиопередачу, и TSCC разрешает это, то необходимо применять процедуру, описанную в разделе 7.

Чтобы вызвать прерывание, инициирующая его АС незамедлительно покидает рабочий канал и, при обнаружении TSCC, инициирует вызов состояния (Status соответствует значению 125):

а) в случае для индивидуального вызова - с указанием адреса АС, вызов которой будет прерван;

б) в случае вызова разговорной группы - с указанием адреса прерываемой разговорной группы.

TSCC должен ответить подтверждением со следующими параметрами: источник - TSI, получатель - прерывающая АС. Если в служебном сообщении получен ответ C_NACKD PDU, то запрос на прерывание получил отказ. Если получен ответ C_ACKD PDU, то запрос на прерывание разрешен. Прерывающая АС должна затем в любом случае вернуться к рабочему каналу.

Если в прерывании отказано, то текущий вызов должен продолжаться без перерыва.

Если прерывание разрешено, то прерывающая АС должна ждать нисходящего PDU, который укажет, что она может осуществлять передачу.

АС(Б) прерывает передачу пользовательских сообщений (речь, данные) АС(А) поэтапно:

а) АС(Б) покидает рабочий канал, и, как только протокол произвольного доступа дает разрешение, АС(Б) совершает вызов состояния. Вызываемый абонент - АС(А), вызывающий абонент - АС(Б). У АС(Б) в IE Service_Kind устанавливается значение "Status", равное 125 (11 1101₂). TSCC должен распознать это как запрос прерывания передачи;

б) если TSCC принимает запрос на прерывание АС, осуществляющей передачу по рабочему каналу, то подтверждение должно быть передано в служебном сообщении C_ACKD PDU с IE Reason, соответствующим Message_Accepted. Если TSCC не принимает запрос на прерывание, то подтверждение должно быть отправлено в служебном сообщении C_NACKD PDU с параметрами в IE Reason, соответствующими Not_Supported или Perm_User_Refused. Если TSCC не принимает запрос на прерывание, то АС(А) не прерывает передачу и текущий вызов продолжается без перерыва. Если TSCC принимает запрос на прерывание, то выполняются этапы, указанные в перечислениях г), д) и е);

в) АС(Б) возвращается на рабочий канал;

г) TSCC передает в RC команду 0100₂ (команда прекращения передачи);

д) если АС(А) указано прервать полезную нагрузку, то она перестает осуществлять передачу, а если нет, то продолжает передачу;

е) когда АС(А) прекращает осуществлять передачу, АС(Б) начинает свою передачу.

Чтобы предотвратить передачу другими участвующими в вызове абонентами после того, как прерывание принято, по рабочему каналу могут быть отправлены блоки P_PROTECT (Protect_Kind соответствует EN_PTT_ONE_MS) с адресом АС(Б) в качестве адреса получателя.

Процедуры для TSCC и ТС при прерывании передачи

Если TSCC получает служебное сообщение с попыткой произвольного доступа, содержащей значение Status, равное 125, то адрес вызываемого абонента должен соответствовать ID АС, участвующих в текущих речевых вызовах на рабочих каналах. Если адрес совпадает, то TSCC интерпретирует это служебное сообщение как запрос на прерывание передачи.

Если прерывание передачи невыполнимо, то TSCC должен отправить ответ в служебном сообщении C_NACKD PDU со следующими параметрами в IE: источник - TSI, получатель - прерывающая АС.

Если прерывание передачи возможно и система позволяет передающей АС разрешить прерывание, то:

а) TSCC отправляет служебное сообщение C_ACKD PDU со следующими параметрами IE (Message_Accepted): источник - TSI, получатель - прерывающая АС;

б) ТС отправляет по RC команду 0100₂ (команда прекращения передачи) на соответствующем рабочем канале и ожидает, пока передающая АС либо прекратит, либо продолжит передачу.

Если АС прекращает передачу, то ТС должна отправить служебное сообщение P_Protect PDU с параметром IE Protect_Kind, соответствующим EN_PTT_ONE_MS, в нисходящем направлении по рабочему каналу, чтобы предотвратить передачу другими АС, кроме прерывающей. ТС ограничивает количество передаваемых служебных сообщений P_Protect PDU так, чтобы АС, занимающая рабочий канал, могла продолжать текущий вызов, если по какой-либо причине прерывания передачи не произойдет.

Если АС продолжает осуществлять передачу, то ТС следует продолжать обслуживание текущих речевых вызовов.

Процедуры для прерывающей АС

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

Прерывающая АС должна вернуться на TSCC. При обнаружении TSCC она делает запрос о состоянии вызова (Status установлен в значение 125) для прерываемой АС. АС должна отправить ответ в TSCC. Если ответом является служебное сообщение C_NACKD PDU с IE Reason, соответствующим Not_Supported или Perm_User_Refused, то АС интерпретирует запрос на прерывание как неудачный. Если ответом является служебное сообщение C_ACKD PDU с параметром Reason, соответствующим Message_Accepted, запрос на прерывание интерпретируется как успешный.

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

Если запрос на прерывание прошел успешно, то АС следует ожидать нисходящие сообщения PDU и биты AT в CACH, указывающие на остановку передачи прерывающей АС. Прерывающая АС затем может принудительно разомкнуть PTT. АС также может обеспечивать визуальную и/или звуковую индикацию для прерванного пользователя. Если передающая АС не прекращает передачу, то прерывающей АС нужно продолжить вызов.

Процедуры для прерываемой АС

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

Если в RC получена команда 0101₂ (прекращение запроса передачи) и передающая АС поддерживает прерывание пользовательского трафика в рабочем канале, то она завершает свой речевой суперкадр передачей речевого пакета "E", отправляет PDU Terminator_with_LC, а затем прекращает передачу. После этого АС контролирует нисходящий канал с соблюдением процедур, определенных в 7.5.3.4. В зависимости от конструктивных особенностей АС может обеспечиваться визуальная и/или звуковая индикация для прерванного пользователя.

Если по RC получена команда 0101₂ (прекращение запроса передачи), а передающая АС не поддерживает прерывание полезной нагрузки, то она должна продолжать передачу.

7.5 Процедуры осуществления вызова

7.5.1 Процедуры вызова - общие положения

Доступ АС к услугам транкинговой сети осуществляется с использованием протокола произвольного доступа, описанного в 7.2. В сообщениях произвольного доступа CSBK C_RAND PDU содержатся все параметры, необходимые для обозначения конкретной запрашиваемой услуги транкинговой сети:

а) услуга индивидуального речевого вызова;

б) услуга речевого вызова разговорной группы;

в) услуга индивидуального вызова передачи пакетных данных;

г) услуга группового вызова передачи пакетных данных;

д) служба передачи индивидуальных коротких данных;

е) служба передачи коротких данных разговорной группы;

ж) услуга переадресации вызова;

и) услуга опроса коротких данных (от АС);

к) услуга включения индивидуального вызова (только для рабочего канала);

л) услуга включения группового вызова (только для рабочего канала);

м) услуга регистрации (см. 7.4);

н) услуга ответа на вызов;

п) услуга отмены вызова;

р) услуга дуплексного индивидуального речевого вызова между АС;

с) услуга дуплексного индивидуального вызова с пакетной передачей данных между АС;

т) услуга дуплексного индивидуального речевого вызова от АС к конечной станции (Fixed End);

у) услуга дуплексного индивидуального вызова с пакетной передачей данных от АС к конечной станции;

ф) услуга индивидуального многокомпонентного вызова с пакетной передачей данных;

х) услуга многокомпонентного вызова с пакетной передачей данных для разговорной группы.

Для поддержки перечисленных и улучшения качества других услуг в протоколе транкинговой сети реализован дополнительный механизм передачи данных между объектами, описанный ниже.

С целью вызова АС другой АС, разговорной группы или всех АС полный адрес источника и адрес назначения закладывается в служебное сообщение C_RAND PDU так, чтобы была вызвана процедура одноблочного установления вызова. АС для вызовов по направлениям, связанным через шлюз (например, PSTN), в процедуре многоблочного установления вызова в качестве адреса назначения задает соответствующий адрес шлюза в C_RAND PDU. TSCC затем запрашивает информацию о расширенном адресе (добавочных номерах) у вызывающей АС, используя процедуру UDT (см. 14.2).

На рисунке 49 показан пример многоблочного установления вызова по добавочному номеру PABX.

Рисунок 49 - Пример многоблочной процедуры вызова

Процедура многоблочного вызова включает следующие этапы:

а) "А" - это C_RAND PDU с произвольным доступом. Адрес назначения установлен как PABXI и указывает на многоблочное установление вызова для обслуживания вызовов к PABX;

б) "Б" - с помощью служебного сообщения C_AHOY PDU от PABXI у вызывающей АС запрашиваются цифры добавочного номера PABX;

в) "В" - в нисходящем канале содержится многоблочный UDT, состоящий из заголовка и добавочного блока данных, содержащего цифры добавочного номера PABX;

г) "Г" - TSCC отправляет абонентской станции PDU предоставления канала.

Процедуры для речи и пакетных данных указаны в 7.5.3 и разделе 9 соответственно. Они включают в себя:

а) установку вызова:

1) запрос на вызов произвольного доступа,

2) возможную процедуру AHOY/UDT, обеспечивающую расширенную адресацию для вызовов через шлюзы,

3) проверку доступности для вызываемого абонента,

4) предоставление канала;

б) управление вызовами на рабочем канале:

1) обслуживание вызовов,

2) очистку вызовов.

7.5.2 Процедуры, общие для речевых вызовов и вызовов с пакетной передачей данных

7.5.2.1 Проверка доступности АС

Доступность вызывающей АС

АС запрашивает услугу вызова путем передачи запроса произвольного доступа. Во время установки вызова TSCC может проверить, находится ли запрашиваемая АС по-прежнему на связи в данное время, отправив ей служебное сообщение C_AHOY PDU. C_AHOY PDU требует ответа от вызывающей АС.

Радиодоступность вызываемого абонента как составляющая вызова

ТС может провести проверку радиодоступности абонента, передавая служебные сообщения как в TSCC, так и в рабочих каналах с помощью сообщения AHOY.

В случае использования TSCC для проведения проверки радиодоступности вызываемого абонента на этапе установления вызова в нисходящем направлении должно быть отправлено служебное сообщение C_AHOY PDU.

При проверке ТС радиодоступности абонента с использованием рабочих каналов в нисходящем направлении должно быть отправлено служебное сообщение PDU P_AHOY PDU.

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

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

Существует вероятность, что при проверке радиодоступности разговорной группы все АС получат и отправят ответ. Однако, несмотря на вероятность такого события, данная функция полезна, поскольку она сообщает ТС, что по крайней мере одна разговорная группа находится на этом канале.

Общая проверка радиодоступности АС

В дополнение к отправленным в рамках установления вызова проверкам радиодоступности вызывающей АС и вызываемых абонентов, ТС может произвольно (в любой момент времени) в любом типе каналов отправить служебное сообщение со структурой CSBK из группы AHOY, чтобы проверить, находится ли на связи АС или разговорная группа.

Требования к проведению проверки радиодоступности АС с использованием служебных сообщений из группы AHOY (C_AHOY/P_AHOY PDU) приведены в 7.4.13.

7.5.2.2 Отмена вызова

Общие положения

В стек протоколов (CCL) добавлена функция отмены текущего вызова. При запросе АС услуг речевого вызова или пакетной передачи пользовательских данных до завершения передачи всех требуемых PDU асинхронного режима доступа через TSCC может быть инициирована принудительная отмена передачи. В этом случае АС должна прекратить радиопередачу и вернуться в исходное состояние.

Отмена OACSU вызова

Если АС инициировала услугу речевого вызова, а вызов еще не состоялся (из-за процедуры передачи PDU предоставления канала в TSCC), то он может быть отменен вызывающей стороной путем инициирования запроса услуги отмены вызова. Для этого в запросе произвольного доступа из перечня PDU предоставления канала IE Service_Kind устанавливается в значение 1111₂ ("Запрос на отмену вызова").

В ответ на запрос отмены вызова TSCC должен отправить служебное сообщение C_ACKD PDU с IE Reason, установленным в значение Message_accepted.

Отмена FOACSU вызова

Если была инициирована услуга речевого вызова по типу FOACSU, а вызов еще не состоялся (из-за процедуры передачи PDU предоставления канала в TSCC), то вызов может быть отменен с помощью процедур, предусмотренных в данном разделе.

Если вызов был инициирован АС, то он может быть отменен вызывающей стороной с помощью инициирования запроса услуги отмены вызова. Для этого в запросе произвольного доступа IE Service_Kind устанавливается в значение 1111₂ ("Запрос на отмену вызова").

IE C_AHOY для отмены FOACSU вызова описаны в таблице 38.

Таблица 38

IE C_AHOY для отмены FOACSU вызова

Название	Длина, бит	Значение
Service_Options_Mirror	7	000 0000₂
Service_Kind_Flag	1	0₂ - указывает, что адрес назначения - индивидуальный адрес получателя
ALS	1	0₂ - не применимо
G/I	1	0₂ - ID АС является адресом получателя
Appended_Blocks	2	00₂
Service_Kind	4	Услуга отмены вызова - 1111₂, Service_Kind_Flag - 0₂
Target_Address	24	Индивидуальный адрес вызываемой АС
Source_Address или Gateway	24	Индивидуальный адрес вызывающей АС или шлюз

При выполнении процедуры FOACSU вызываемой АС должно быть отправлено служебное сообщение AHOY с IE Service_Kind_flag, установленным в значение 1₂, чтобы указать, что этот вызов является FOACSU. Если вызываемая АС отвечает подтверждением, что она приняла этот вызов, то АС должна предупредить пользователя о данном вызове. Если вызов отменен до того, как вызываемый абонент был готов к связи, то:

а) TSCC должен отменить вызов путем отправки для вызываемой АС служебного сообщения C_AHOY PDU с IE Service_Kind, установленным в значение 1111₂;

б) при получении служебного сообщения C_AHOY PDU с IE Service_Kind, установленным в значение 1111₂, вызываемая АС должна отправить ответ служебным сообщением C_ACKU PDU с использованием параметра MS_Accepted, отменить предупреждение и принять отказ от вызова;

в) если вызов поступил от АС, TSCC должен отправить вызывающей АС подтверждение служебным сообщением C_ACKD PDU с параметром MessageAccepted, означающим, что вызов отменен.

7.5.2.3 Подтверждения, отправляемые на вызывающую АС

При инициации группового вызова АС TSCC должен отправить подтверждающие PDU, чтобы информировать вызывающую АС о ходе процедуры запроса вызова:

а) TSCC может отправить PDU, которые завершат или прервут запрос на обслуживание текущего вызова:

1) TSCC может отправить служебное сообщение C_NACKD PDU для информирования вызывающей АС о том, что вызов не состоялся. В этом служебном сообщении должен содержаться IE Reason со значениями, сообщающими вызывающему абоненту, почему запрос на обслуживание не удался,

2) TSCC может послать заголовок UDT и добавочный UDT блок для информирования о том, что вызов будет переадресован. Со стороны TSCC транзакция услуги завершается. АС может либо указать переадресованный адрес абоненту и вернуться в исходное состояние, либо автоматически создать новый запрос на обслуживание с новым адресом назначения,

3) TSCC может отправить служебное сообщение C_ACKD PDU с параметром Callback в IE Mirrored_Reason, информирующее вызывающую АС, что вызывающий абонент перезвонит;

б) в процессе обработки запроса текущего вызова АС TSCC может передать в PDU подтверждение в качестве ответа на запрос произвольного доступа:

1) C_WACKD - промежуточное подтверждение, за которым последуют дополнительные сообщения,

2) C_QACKD - TSCC поставил вызов в очередь, потому что запрошенный ресурс или вызываемый абонент занят,

3) C_AHOY - TSCC отправляет служебное сообщение C_AHOY PDU с адресом вызывающей АС в ее IE Source или Target_Address.

7.5.2.4 Процедура ответа вызываемого абонента

Общие положения

TSCC может обрабатывать отдельные речевые вызовы и вызовы с пакетной передачей данных, используя OACSU или FOACSU.

При вызове с использованием OACSU рабочий канал назначается, как только ресурс становится доступным для подключения к этому каналу. Блоки PDU предоставления канала отправляются вызывающему и вызываемому абонентам. Когда вызываемый абонент получил PDU о предоставлении канала, он может быть предупрежден о входящем вызове.

При вызове с использованием FOACSU должна быть проведена проверка того, что вызываемый абонент доступен, но TSCC не посылает PDU о предоставлении канала до того момента, пока вызываемый абонент не укажет, что готов к ведению связи (RFC) (например, с помощью способа "повешенной трубки"), как показано на рисунке 50.

- Исходные сообщения, TDMA-канал 1

- Сообщения TSCC, TDMA-канал 2

- Рабочий канал, TDMA-канал 1

- Получатель сообщения

Рисунок 50 - Процедура ответа на вызов по принципу FOACSU

АС(А) делает запрос на обслуживание на этапе "А". В этом примере TSCC посылает служебное сообщение AHOY PDU (этап "В") на АС(Б), которая требует подтверждения. В AHOY PDU IE Service_Kind_Flag должен быть установлен в значение 1₂, чтобы указать, что вызов установлен с помощью FOACSU. АС(Б) отвечает подтверждением на этапе "В", и ACK передается на АС(А) на этапе "Г". На этом этапе АС(Б) предупреждает пользователя о входящем вызове и отправляет "зеркальное" подтверждение АС(А), указывая на то, что АС(Б) находится в режиме приема. Если вызываемый абонент готов к связи (находится в режиме "повешенной трубки" (RFC) и не ведет текущего вызова), то:

а) вызываемый абонент немедленно отвечает на вызов на этапе "Е", для чего АС(Б) отправляет ответ на запрос произвольного доступа в TSCC. Состояние оповещения отменяется;

б) если ресурс канала трафика доступен, то TSCC посылает PDU предоставления канала, адресованные АС(А) и АС(Б) на этапе "Е" (в противном случае TSCC может поставить вызов в очередь, пока канал трафика не станет доступным).

Ответ TSCC в асинхронном режиме доступа (call answer random access)

При получении TSCC PDU запроса услуги асинхронного режима доступа (call answer random access) он должен отправить ответ в соответствии с процедурами произвольного доступа, предусмотренными в 7.2.

Эти блоки PDU могут содержать различные ответы на запрос произвольного доступа:

а) если АС подтверждает, что вызов принят (ACCEPT установлен в значение 0₂):

1) подтверждение в служебном сообщении C_WACKD PDU: вызов поставлен в очередь, последуют дополнительные сообщения,

2) подтверждение в служебном сообщении C_QACKD PDU (Reason соответствует 1010 0000₂): вызов поставлен в очередь, ожидая получение ресурса сети,

3) подтверждение в служебном сообщении C_NACKD PDU: отказ сети, сообщение не разрешено,

4) передаются PDU предоставления канала для этого вызова;

б) если АС указывает на то, что вызов отклонен (ACCEPT установлен в значение 1₂):

1) подтверждение в служебном сообщении C_NACKD PDU: отказ сети, запрос отклонен,

2) подтверждение в служебном сообщении C_ACKD PDU: запрос принят.

Ответ от участвующего в вызове абонента АС

АС должна подтвердить, что она готова к связи и не находится в текущем вызове (RFC, "трубка повешена"), путем отправки служебного сообщения о запросе произвольного доступа C_RAND PDU с соблюдением процедур произвольного доступа, описанных в 7.2. IE запроса произвольного доступа представлены в таблице 39, они передаются на CCL. IE ACCEPT должен указывать на то, что вызываемый абонент может принять (значение 0₂) или отклонить (значение 1₂) запрашиваемый вызов.

Таблица 39

IE C_RAND для услуги ответа на вызов

IE	Размер, бит	Длина, бит	Имя	Значение	Комментарий
Service_Options	7	1	EMERG	0₂	-
		1	-	0₂	Конфиденциальность (R)
		1	SUPED_SV	0₂	Не применимо
		1	BCAST_SV	0₂	-
		1	R	0₂	-
		2	PRIORTY_SV	00₂	-
Proxy Flag	1	-	PROXY	0₂	-
R	2	-	-	00₂	-
Accept/Reject	1	-	ACCEPT	0₂	Пользователь принял вызов FOACSU
Accept/Reject	1	-	ACCEPT	1₂	Пользователь отказывается принимать данный вызов
R	1	-	-	0₂	-
Service_Kind	4	-	CALL_ANS	1001₂	Услуга ответа на вызов
Target_Address или Gateway	24	-	-	XX...X₂	Адрес получателя <1>
Source_Address	24	-	-	XX...X₂	Индивидуальный адрес запрашиваемой АС <2>
<1> Target_Address представляет собой индивидуальный адрес АС или шлюза, инициировавших вызов. <2> Адрес АС, которую вызывает инициирующая вызов АС.

7.5.2.5 Поддержка ожидания вызова с помощью таймеров

Таймер ожидания вызова для вызывающей АС

При инициации запроса АС конкретной услуги TSCC может отправлять подтверждающие PDU, чтобы информировать вызывающую АС о ходе выполнения запроса на обслуживание. Если вызывающая АС получает подтверждение на запрос произвольного доступа, то она запускает один из двух таймеров. Таймер TP_Timer должен быть запущен для запроса услуг передачи речи или пакетной передачи данных с произвольным доступом, что требует выделения рабочего канала. Таймер TNP_Timer запускается, если для вызова используется только TSCC. Если во время работы таймера АС получает одно из подтверждающих PDU или служебное сообщение C_AHOY PDU, применимое к этому вызову, таймер должен быть перезапущен. Если время таймера истекает, то АС считает, что TSCC отказался от вызова. В этом случае АС возвращается в исходное состояние.

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

Таймер ожидания вызова для вызываемой АС

Если АС получает индивидуально адресованный вызов в служебных сообщениях:

- C_AHOY PDU (Service_Kind установлен в значение 0000₂, Service_Kind_Flag установлен в значение 0₂);

- C_AHOY PDU (Service_Kind - в значение 0010₂, Service_Kind_Flag - в 0₂);

- C_AHOY PDU (Service_Kind - в значение 1010₂, Service_Kind_Flag - в 0₂);

- C_AHOY PDU (Service_Kind - в значение 1011₂, Service_Kind_Flag - в 0₂),

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

Если АС получает индивидуально адресованный вызов в служебных сообщениях:

- C_AHOY PDU (Service_Kind установлен в значение 0000₂, Service_Kind_Flag - в 1₂);

- C_AHOY PDU (Service_Kind - в значение 1010₂, Service_Kind_Flag - в 1₂);

- C_AHOY PDU (Service_Kind - в значение 0010₂, Service_Kind_Flag - в 1₂);

- C_AHOY PDU (Service_Kind - в значение 1011₂, Service_Kind_Flag - в 1₂),

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

Если АС или разговорная группа во время работы любого из таймеров T_Pending или T_AnswerCall получает PDU предоставления канала речевого вызова или предоставления канала пакетной передачи данных, содержащий IE Emergency, установленный в значение 1₂, то АС должна незамедлительно прервать текущий вызов и вернуться на рабочий канал, указанный в специальном PDU аварийного вызова (emergency channel grant).

Если АС или разговорная группа во время работы любого из таймеров T_Pending или T_AnswerCall получает PDU предоставления канала речевого вызова или предоставления канала с пакетной передачей данных, содержащий IE Emergency, установленный в значение 0₂, то АС не должна реагировать на этот PDU.

Если время одного из таймеров T_Pending или T_AnswerCall истекает и АС не был предоставлен рабочий канал, то АС определяет, что TSCC отказал в вызове, который был указан в служебном сообщении C_AHOY PDU. Если вызов был установлен с FOACSU, то АС должна перейти в состояние предупреждения об отказе в вызове, а по истечении времени таймера T_AnswerCall должна выйти из этого состояния.

Во время работы таймеров T_Pending или T_AnswerCall (таймеры запущены) TSCC может передавать служебные сообщения:

- C_AHOY PDU (Service_Kind установлен в значение 0000₂);

- C_AHOY PDU (Service_Kind установлен в значение 1010₂);

- C_AHOY PDU (Service_Kind установлен в значение 0010₂);

- C_AHOY PDU (Service_Kind установлен в значение 1011₂).

После приема указанных сообщений АС должна перезапустить соответствующий таймер.

Если во время работы таймеров T_Pending или T_AnswerCall по TSCC передается индивидуально адресованный C_AHOY PDU, содержащий команду отмены вызова (в C_AHOY PDU элемент Service_Kind установлен в значение 1111₂), то таймер должен быть остановлен. АС определяет, что TSCC отказал в предоставлении вызова.

Если служебное сообщение о предоставлении канала отправлено или получено, то таймеры T_Pending или T_AnswerCall TSCC и АС должны быть остановлены (не должны использоваться).

7.5.2.6 Назначение рабочего канала для передачи полезной нагрузки

Назначение рабочего канала

TSCC должен назначить рабочий канал для вызова с помощью передачи PDU предоставления канала для поддерживаемой услуги (для индивидуальной АС или разговорной группы).

PDU предоставления канала могут быть в формате одноблочного CSBK, если логический канал, относящийся к абсолютным частотам Tx/Rx, известен, или в формате MBC. PDU предоставления канала могут иметь добавочный блок MBC со значениями абсолютных частот Tx/Rx.

При индивидуальном речевом вызове и пакетной передаче данных в направлении к некоторым шлюзам и от них рабочий канал может иметь смещение во времени, чтобы обеспечить дуплексную работу АС. TSCC назначает различные идентификаторы шлюза для того, чтобы отличать режимы работы рабочего канала с выравниванием и со смещением во времени при назначении этого рабочего канала для передачи полезной нагрузки (речь, пользовательские данные):

а) для синхронизации с выравниванием во времени для PSTNI, PABXI, LINEI, IPI, DISPATI (см. А.5);

б) для синхронизации без смещения во времени PSTNDI, PABXDI, LINEDI, IPDI, DISPATDI (см. А.5).

PDU предоставления канала могут быть переданы ТС по рабочему каналу, чтобы установить способ выравнивания во времени каналов для текущего вызова перед началом передачи вызова или смены канала при переназначении канала для вызова.

Если разговорная группа участвует в текущем вызове на рабочем канале, то TSCC может продолжать передавать соответствующие PDU предоставления канала через регулярные промежутки времени для обеспечения позднего входа АС при уже установленном вызове (АС, которые только что подключились к TSCC). Таким образом, АС могут подключиться к текущему вызову разговорной группы.

Требования к синхронизации рабочих каналов для распределения полезной нагрузки по ним и к PDU полезной нагрузки и синхронизации

PDU полезной нагрузки и синхронизации - общие положения

АС выделяется физический/логический рабочий канал для предоставления услуг передачи речи и передачи данных. Если АС предоставлен рабочий канал, то она должна выполнить требования по работе в выделенном ей временном промежутке, определенные в настоящем разделе.

Если ни один из таймслотов рабочего канала не занят, то требования к настройке рабочего канала не предъявляются. Если хотя бы один из таймслотов рабочего канала становится активным (в нем ведется радиопередача), то рабочий канал настраивается.

В рабочем канале, который не участвует в вызове, должны непрерывно отправляться служебные сообщения IDLE PDU (сообщения "холостого хода"), обозначающие канал как свободный.

По рабочему каналу, который участвует в вызове, могут быть переданы следующие сообщения:

- служебные сообщения PDU для рабочего канала;

- служебные сообщения P_PROTECT PDU, чтобы запретить работу АС, которые по какой-либо причине не должны использовать канал передачи пользовательского трафика;

- служебные сообщения P_CLEAR PDU для определения окончания текущего вызова и разъединения АС;

- служебные сообщения P_AHOY и подтверждения P_xACK PDU;

- речевые сообщения (или пользовательские данные), принятые в восходящем направлении;

- PDU прерывания входящих речевых вызовов или передачи пользовательских данных.

TSCC и рабочие каналы, засинхронизированные по таймслоту сайта

Если ТС выбирает таймслот 1 в рабочем канале, то АС должна иметь возможность принимать или передавать информацию при повторном появлении таймслота 1 в рабочем канале после того, как этот канал был выделен TSCC для работы.

Если ТС выбирает таймслот 2 в рабочем канале, то АС должна иметь возможность приема или передачи информации при третьем появлении таймслота 2 в рабочем канале после того, как этот канал был выделен TSCC для работы.

Независимо от назначения TSCC таймслота 1 или 2 для передачи пользовательских сообщений (речь, данные) в рабочем канале в нем должна начаться передача в нисходящем направлении служебных сообщений в блоках PDU из перечня, указанного в 7.5.2.6 ("PDU полезной нагрузки и синхронизации - общие положения"), до тех пор, пока в рабочем канале не начнется передача пользовательских данных.

TSCC и рабочие каналы, не синхронизированные по таймслотам

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

ТС перед передачей в контрольном канале PDU предоставления рабочего канала активирует этот рабочий канал. То есть в момент, когда АС переключится на рабочий канал, в нем уже будет передаваться CACH. Период синхронизации включает в себя передачу до четырех CACH в рабочем канале после первой для АС возможности засинхронизироваться. Это позволяет осуществлять надежную синхронизацию в сложных ситуациях с помощью битов IE "TCh", описание которого приведено в ГОСТ Р 71586.2-2024 (пункт 15.5.5).

Независимо от назначения полезной нагрузки таймслоту 1 или 2 в рабочем канале, рабочий канал должен начинать передачу в нисходящем направлении IDLE PDU или блоков PDU из перечня, указанного в 7.5.2.6, после первой передачи по TSCC разрешения на предоставление канала. Эти PDU должны передаваться до тех пор, пока не будет передано до четырех CACH после первой возможности получения синхронизации АС. АС необходимо получить хотя бы один полный кадр, содержащий синхронизацию и CACH с нужным таймслотом для получения бита AT.

Примечания

1 Вопросы, касающиеся применения CACH, подробно рассмотрены в ГОСТ Р 71586.2.

2 В зависимости от фактического радиопокрытия для предполагаемой зоны обслуживания количество пропущенных CACH может быть изменено.

Рекомендуется иметь возможность программирования количества пропускаемых CACH с устанавливаемым значением от 1 до 4 для ТС и АС.

7.5.2.7 Вызовы к ALLMSID, ALLMSIDZ и ALLMSIDL

Настоящий стандарт предусматривает три вида широковещательных вызовов всех АС.

АС может запросить вызов ALLMSID, ALLMSIDL или ALLMSIDZ (см. А.5).

Вызов ALLMSID - это широковещательный вызов разговорной группы, направляемый всем АС на всех сайтах определенной системы.

Вызов ALLMSIDZ - широковещательный вызов разговорной группы, направляемый на определенные сайты в определенной системе. Выбор сайтов, включенных в этот вызов, определяется при развертывании сети.

Вызов ALLMSIDL - широковещательный вызов разговорной группы, направляемый всем АС сайта, в пределах которого инициирован.

Для точной идентификации широковещательного вызова необходимо, чтобы у АС, инициирующей этот вызов, соответствующие IE в служебном сообщении C_RAND PDU были установлены правильно.

7.5.3 Процедуры речевого вызова

7.5.3.1 Общие положения

Для речевых вызовов требуется рабочий канал, по которому такой вызов будет осуществляться.

Вызовы могут выполняться между объектами, представленными в таблице 40.

Таблица 40

Объекты для предоставления услуги речевого вызова

Инициатор	Получатель
АС	АС или разговорная группа
АС	Все АС (широковещательные)
АС	Направление соединительной линии через шлюз: - PABX-расширение (добавочный номер); - PSTN-направление; - другой шлюз, оборудованный для передачи речи
Источник вызова, подключенный к линии соединения через шлюз: - PABX-расширение (добавочный номер); - PSTN-направление; - другой шлюз, оборудованный для передачи речи	АС, разговорная группа или все АС

PDU индивидуального вызова или PDU разговорной группы в запросе на услугу произвольного доступа определяет, выбрал ли абонент услугу транкинговой сети для индивидуальной АС или разговорной группы.

IE Service_Options в C_RAND PDU запроса на услугу произвольного доступа должен активировать следующие опции для запроса услуги речевого вызова:

- экстренная служба. Экстренные вызовы должны иметь приоритет над всеми другими вызовами. Если запрашиваемый ресурс для экстренного вызова недоступен, то в интересах такого вызова должен быть отменен другой вызов с меньшим приоритетом;

- услуга передачи дополнительных данных пользователя для речевого вызова. Такие данные могут быть отправлены вызываемому абоненту как часть, необходимая для поддержки другой службы этого вызова. Например, идентификатор линии вызывающего абонента PSTN может быть передан вызываемому абоненту как часть настройки речевого вызова;

- услуга вещания. Услуга широковещательного речевого вызова обеспечивает односторонний речевой вызов от любого пользователя к заданной разговорной группе;

- приоритет. Опция приоритета позволяет отправителю выбрать один из четырех уровней приоритета. TSCC может управлять и переставлять вызовы в очереди, чтобы вызовы с более высоким приоритетом совершались быстрее;

- вызов всех АС. Речевой вызов может быть сделан ко всем АС. В этом случае АС или шлюз выбирает идентификатор ALLMSID, ALLMSIDL или ALLMSIDZ (см. А.5) в качестве адреса назначения. При таком вызове должна использоваться услуга вещания (указана выше).

7.5.3.2 Процедуры речевого вызова для TSCC

Общие положения

АС запрашивает услугу передачи речи транкинговой сети посредством формирования запроса PDU произвольного доступа с указанием одного из перечисленных вариантов адреса получателя:

а) индивидуальный адрес АС (одноблочное установление вызова);

б) адрес разговорной группы АС (одноблочное установление вызова);

в) адрес шлюза, который указывает на многоблочное установление вызова. Адрес шлюза определяет направление, например, PABXI - для вызова PABX, PSTNI - для вызова PSTN, LINEI - для вызова к направлению соединительной линии, DISPATI - для вызова диспетчера системы. Для гибкости вызовы соединительной линии и диспетчера системы обрабатываются таким же образом, как PABX- и PSTN-вызовы. Для того чтобы определить дуплексные фиксированные вызовы конечной станции, должны использоваться соответствующие дуплексные шлюзы.

Когда TSCC отвечает на запрос произвольного доступа, он должен запустить таймер (TP_Timer). Этот таймер должен быть обновлен, если TSCC посылает вызывающему абоненту связанные блоки PDU дальнейшего вызова: C_WACKD, C_QACKD или C_AHOY.

Ответ TSCC на одноблочное установление речевого вызова

Когда PDU речевой услуги произвольного доступа принимаются TSCC, он отправляет ответ в соответствии с процедурами произвольного доступа, предусмотренными в 7.2.

Эти блоки PDU, являющиеся ответом на запрос произвольного доступа на обслуживание одноблочного речевого вызова, представляют собой:

а) подтверждение PDU C_NACKD, C_QACKD, C_WACKD, C_ACKD (mirrored_reason соответствует значению "Обратный вызов");

б) заголовок UDT (UDT Head) с добавочными блоками (речевой вызов переадресуется), при этом в PDU заголовка UDT Source_Address соответствует DIVERTI (передача переадресованного адреса), Supplementary_Flag установлен в значение 1₂, IE A установлен в значение 0₂ (описание IE A см. в 16.3.24);

в) C_AHOY PDU для вызываемого абонента MSID (проверка радиодоступности вызываемого абонента), если вызов направлен по отдельному адресу АС. При этом C_AHOY Service_Kind установлен в значение 0000₂, адрес источника установлен в значение ID АС вызывающего абонента, адрес получателя - в значение ID АС вызываемого абонента (см. 7.5.3.2);

г) C_AHOY PDU, адрес источника соответствует значению вызова аутентификации (проверка подлинности АС) (см. 7.4.9.3);

д) C_AHOY PDU для вызывающего абонента. При этом C_AHOY Service_Kind установлен в значение 0000₂, адрес источника - SUPLI, адрес получателя - ID АС вызывающего абонента (для того, чтобы вызывающая АС передала дополнительные данные пользователя) (см. 7.4.14);

е) PDU предоставления канала для этого вызова.

При структуре блока, описанной в перечислении д), TSCC должен вызвать процедуру UDT, отправив вызывающей АС служебное сообщение C_AHOY PDU для передачи дополнительных данных пользователя. Формат дополнительных данных пользователя указывается в UDT. Если TSCC не принимает UDT от АС, он может повторить отправку служебного сообщения C_AHOY PDU или передать служебное сообщение C_NACKD PDU, чтобы указать на сбой вызова, или продолжить устанавливать вызов и отказаться от дополнительных данных пользователя.

Порядок, в котором блоки со структурой, указанной в перечислениях в) и д), должны быть отправлены, описан в 7.4.14.

Примечание - TSCC может отправить служебное сообщение C_AHOY, адресованное разговорной группе (C_AHOY Service_Kind установлен в значение 0001₂, адрес источника соответствует ID АС вызывающего абонента, адрес получателя соответствует адресу разговорной группы), чтобы удостовериться в том, что по крайней мере один член разговорной группы принимает TSCC.

Получатель C_AHOY PDU при структуре блока, описанной в перечислениях в), г) и д), определяется с помощью IE Source_Address в C_AHOY PDU. Для вызываемого абонента это ID вызывающего абонента АС. Для проверки аутентификации этим адресом является адрес шлюза AUTHI. При варианте, описанном в перечислении д) - это SUPLI.

Ответ TSCC на многоблочное установление речевого вызова

Для звонков на расширенные адреса (extended_addresses) АС запрашивает многоблочную адресацию путем формирования запроса произвольного доступа на услугу речевого вызова с IE Destination_Address, в котором установлен адрес шлюза (PABXI, PSTNI и т.д.), а также IE Proxy Flag, указывающим, что могут понадобиться один или два добавочных блока UDT для передачи значений расширенных адресов от АС. При звонках на PABX/PSTN/LINE/DISPAT следует учитывать, что один UDT может переносить до 20 набранных цифр. В этом случае IE Proxy Flag должен быть установлен в значение 0₂. Для передачи набранных цифр в количестве от 21 до 44 IE Proxy Flag должен быть установлен в значение 1₂.

Эти PDU, являющиеся ответом на запрос произвольного доступа на обслуживание многоблочного речевого вызова, представляют собой:

а) подтверждение PDU C_NACKD, C_WACKD, C_QACKD;

б) C_AHOY PDU от исходного адреса PABXI, PSTNI, LINEI, DISPATI или соответствующих дуплексных шлюзов для вызывающей АС с целью отправки информации о расширенном адресе;

в) C_AHOY PDU от исходного адреса SUPLI для вызывающей АС с целью передачи дополнительных данных пользователя (см. 6.4).

Порядок, при котором блоки, указанные в перечислениях б) и в), должны быть отправлены, описан в 7.4.14.

Для блока со структурой, описанной в перечислении б), TSCC должен вызвать процедуру UDT путем передачи вызывающей АС C_AHOY PDU с указанием об отправке информации о расширенном адресе. Для вызова PABX, PSTNI, LINEI или DISPATI информация о расширенных адресах соответствующих дуплексных шлюзов должна быть представлена в виде цифр в формате BCD. IE Proxy Flag в C_AHOY PDU должен быть скопирован из IE Proxy Flag, содержащегося в C_RAND PDU, полученном от АС. Если TSCC не принял UDT от АС, то TSCC может повторить C_AHOY или передать C_NACKD, чтобы указать на сбой вызова.

Для блока со структурой, описанной в перечислении в), TSCC должен вызвать процедуру UDT путем отправки вызывающей АС служебного сообщения C_AHOY PDU для передачи дополнительных данных пользователя. Формат дополнительных данных пользователя указывается в UDT. Если UDT от АС не получен TSCC, то он может повторить C_AHOY PDU или передать C_NACKD, чтобы указать на сбой вызова, или продолжить установку вызова и отказаться от дополнительных данных пользователя.

Подтверждения, отправленные TSCC вызывающей АС (речевой вызов)

TSCC может посылать подтверждающие PDU после получения запроса речевой услуги произвольного доступа, чтобы узнать о ходе вызова, завершить вызов или затребовать обратный вызов. Если TSCC посылает служебные сообщения в PDU для того, чтобы узнать о состоянии вызова, он должен запустить таймер ожидания TP_Timer (вызывающая АС должна поддерживать работу аналогичного таймера):

а) PDU состояния вызова являются:

1) C_WACKD: промежуточное подтверждение (далее последуют другие PDU),

2) C_QACKD: вызываемая АС занята в другом вызове,

3) C_QACKD: вызов поставлен в очередь, потому что ресурс в данный момент используется другим вызовом.

Если вызов установлен с FOACSU, то C_ACKD (Mirrored_Reason соответствует MS_ALERTING) предназначен для того, чтобы указать вызывающей стороне, что вызываемый абонент отправляет подтверждение на полученный C_AHOY PDU с Service_Kind, установленным в значение 0000₂ и Service_Kind_Flag, установленным в значение 1₂;

б) PDU для прерывания выбираются из соответствующего IE Reason в C_NACKD PDU (см. 16.3.9): C_NACKD;

в) PDU обратного вызова указывают вызывающей АС, что услуга речевого вызова принята вызываемым абонентом для осуществления обратного вызова: C_ACKD (mirrored_reason соответствует CallBack);

г) если ТС ранее приняла переадресацию вызова, указывая тем самым, что этот тип запроса на обслуживание должен быть направлен другому вызываемому абоненту, то TSCC должен вызвать UDT и отправить заголовок UDT (UDT Head) с добавленными данными вызывающему абоненту. Адрес источника в UDT Head PDU соответствует DIVERTI (передача переадресованного адреса), IE Supplementary_Flag установлен в значение 1₂ и IE A - в значение 0₂.

Проверка речевой радиосвязи

Для организации вызовов, предназначенных для отдельных АС, ТС с помощью TSCC должна проверить, что вызываемый абонент находится на связи и сможет принимать вызов после того, как ему будет выделен рабочий канал.

По TSCC доступность абонента проверяется следующими способами:

а) отправкой C_AHOY PDU вызываемому абоненту. Если сообщение C_AHOY Service_Kind установлено в значение 0000₂, а Service_Kind_Flag - в значение 0₂, то TSCC проверяет наличие связи с АС и ее способность принять вызов немедленно. Если сообщение C_AHOY Service_Kind установлено в значение 0000₂, а Service_Kind_Flag - в 1₂, то TSCC проверяет готовность АС к связи [RFC ("трубка повешена") и предыдущий вызов закончен];

б) отправкой многоблочных UDT с дополнительными данными пользователя (если услуга дополнительных данных пользователя активна для данного вызова).

Если отправляется многоблочный UDT согласно перечислению б), то он должен отправляться после выполнения способа, описанного в перечислении а) (см. 7.4.14).

Если от вызываемой стороны не получен ответ, то TSCC может повторить передачу служебного сообщения C_AHOY. Проверка доступности требует ответа от вызываемого абонента:

- если ответом является C_NACKU, то TSCC должен отправить вызывающей АС соответствующую информацию о сбое вызова и отобразить его причину в C_NACKU PDU (mirrored_reason);

- если ответом является C_ACKU [причина - обратный вызов (Reason соответствует CallBack)], то TSCC должен отправить ответ об обратном вызове (CallBack) вызывающей АС, C_ACKD (mirrored_reason установлен в значение 0100 0101₂);

- если ответ C_ACKU (Reason соответствует Message_Accepted), то TSCC должен выполнить запрос на обслуживание и выделить рабочий канал, передав соответствующие PDU предоставления канала;

- если на вызываемой АС включен FOACSU, то верным ответом на C_AHOY Service_Kind, установленным в значение 0000₂, и Service_Kind_Flag, установленным в значение 1₂, будет C_ACKU (Reason соответствует MS_ALERTING), т.е. АС отправляет оповещения, но "трубка еще не повешена" (RFC).

Примечание - Многоблочный UDT может не передать все параметры предоставления услуги для вызываемого абонента. Если какие-то из параметров предоставления услуги имеют важное значение для функционирования системы, на АС могут быть отправлены C_AHOY/response (ответ) и многоблочный UDT/response.

Проверка доступности для речевых вызовов, подключаемых через шлюзы

Для вызовов, подключенных через шлюзы, ТС может подождать, пока адресат не перейдет в режим "трубка повешена" (RFC), прежде чем выделять ему рабочий канал. Например, ТС может подождать, пока PSTN не будет дан ответ, а потом отправлять PDU предоставления канала.

7.5.3.3 Процедуры речевого вызова для АС

Общие положения

АС может запросить услугу речевого вызова другой АС или разговорной группы с помощью одноблочного запроса на обслуживание. Для речевой услуги, запрашиваемой с использованием расширенных адресов через шлюз, АС осуществляет многоблочный запрос на обслуживание.

В таком многоблочном запросе АС указывает адрес шлюза в качестве вызываемого абонента. Полный адрес назначения затем загружается из АС в TSCC с помощью процедуры UDT.

АС запрашивает речевую услугу, отправив запрос произвольного доступа служебным сообщением C_RAND PDU, соблюдая процедуры такого доступа (см. 7.2). IE запроса произвольного доступа передаются на CCL стека протоколов, их описание приведено в таблице 41.

Таблица 41

IE C_RAND для услуги речевого вызова

IE	Размер, бит	Длина, бит	Наименование	Значение	Комментарий
Service_Options	7	1	EMERG	0₂	Неэкстренная служба
		1	EMERG	1₂	Экстренная служба
		1	-	0₂	Конфиденциальность (R)
		1	SUPED_SV	0₂	Услуга передачи дополнительных данных пользователя для этого вызова не требуется <1>
		1	SUPED_SV	1₂	Необходима услуга передачи дополнительных данных пользователя для этого вызова
		1	BCAST_SV	0₂	Не услуга вещания
		1	BCAST_SV	1₂	Услуга вещания <2>
		1	R	0₂	Зарезервировано
		2	PRIORTY_SV <3>	00₂	Нормальный (низкий) приоритет
				01₂	Средний приоритет
				10₂	Высокий приоритет
				11₂	Самый высокий приоритет
Proxy Flag	1	-	PROXY	0₂	Число расширенных цифр BCD для адресации через шлюз = от 1 до 20
Proxy Flag	1	-	PROXY	1₂	Число расширенных цифр BCD для адресации через шлюз = от 21 до 44
Appended_Supplementary_Data	2	-	SUPED_VAL	XX₂	Количество добавочных блоков UDT, необходимых для передачи дополнительных данных пользователя
ALS	1	-	ALS_SERV	0₂	Услуга прослушивания окружения не запрашивается
ALS	1	-	ALS_SERV	1₂	Запрашивается услуга прослушивания окружения
R	1	-	-	0₂	-
Service_Kind	4	-	IND_V_SRV	0000₂	Услуга индивидуального речевого вызова
Service_Kind	4	-	GRP_V_SRV	0001₂	Услуга речевого вызова разговорной группы
Target_Address или Gateway	24	-	-	XX...X₂	Адрес получателя <4>
Source_Address	24	-	-	XX...X₂	Индивидуальный адрес запрашивающей АС
<1> Если SUPED_SV установлен в значение 0₂, то SUPED_VAL установлен в значение 00₂. <2> Опция вещания применима только к услуге вызова разговорной группы. <3> Если EMERG установлен в значение 1₂, тогда PRIORTY_SV установлен в значение 00₂. <4> Если Service_Kind соответствует IND_V_SRV, то Target_Address представляет собой индивидуальный адрес. Если Service_Kind соответствует GRP_V_SRV, то Target_Address представляет собой адрес разговорной группы.

Инициализация услуги одноблочного речевого вызова

Для запроса услуги речевой связи к отдельной АС или разговорной группе адрес назначения задается IE Target_Address в PDU произвольного доступа. IE Service_Kind определяет, предназначена ли услуга речевого вызова индивидуальному адресу или адресу разговорной группы.

Ответ на запрос услуги одноблочного речевого вызова

АС следует обработать следующие PDU в качестве ответа на одноблочный запрос речевой услуги:

а) подтверждение C_WACKD, C_QACKD, C_NACKD, C_NACKD (mirrored_reason), C_ACKD [mirrored_reason соответствует значению Callback (обратный вызов)];

б) C_AHOY (проверка радиодоступности вызываемого абонента);

в) заголовок UDT и добавочный блок UDT. Заголовок UDT содержит IE Source_Address, соответствующий DIVERTI (передача переадресованного адреса), IE Supplementary_Flag, установленный в значение 1₂, и IE A - в значение 0₂;

г) PDU предоставления канала;

д) если C_RAND Service_Options SUPED_SV установлен в значение 1₂, то C_AHOY передается от SUPLI для загрузки дополнительных данных пользователя, полученных от вызывающей АС.

Порядок, при котором блоки, указанные в перечислениях б) и д), должны быть отправлены, описан в 7.4.14.

Если АС запросила дополнительные данные пользователя, установив в запросе на установление вызова IE C_RAND Service_Options SUPED_SV в значение 1₂, а TSCC не поддерживает передачу дополнительных данных или не может принять их в данный момент, то TSCC либо продолжает устанавливать вызов и отказывается от запроса дополнительных данных пользователя, либо передает C_NACKD, чтобы указать на сбой вызова.

Ответ на составной запрос речевой услуги

АС должна принять следующие PDU в качестве ответа на составной запрос речевой услуги:

а) PDU подтверждения C_WACKD, C_QACKD, C_NACKD;

б) PDU C_AHOY от PABXI, PSTNI, LINEI, DISPATI для загрузки расширенных адресов (extended_address):

1) C_AHOY для загрузки набранных цифр при вызове к PABXI/PSTNI/LINEI/DISPATI или к соответствующим дуплексным шлюзам,

2) если Service_Options SUPED_SV установлено в значение 1₂, от SUPLI может быть послан C_AHOY для загрузки дополнительных данных от вызывающей АС.

Для PDU указанного в перечислении б), если для запроса услуги речевого вызова требуется информация о расширенном адресе, а вызывающая АС выбрала в Service_Options параметр "Дополнительные данные" (Supplementary data), то TSCC загружает информацию в два этапа. Порядок, в соответствии с которым загружается информация, настоящим стандартом не установлен, поскольку C_AHOY PDU указывает, какая восходящая процедура UDT вызывается, устанавливая определенные значения IE шлюза (Gateway) в PDU C_AHOY.

IE C_AHOY PDU для поддержки речевых услуг при многоблочном установлении вызова представлены в таблице 42.

Таблица 42

IE C_AHOY PDU для многоблочного установления речевого вызова

Действие	Тип услуги	Адрес шлюза	Комментарий
АС посылает цифры PSTN	0000₂ - услуга "Индивидуальный вызов"	PSTNI	Вызывающая сторона должна отправить набранные цифры BCD
АС посылает цифры PABX	0000₂ - услуга "Индивидуальный вызов"	PABXI	Вызывающая сторона должна отправить набранные цифры BCD
АС посылает цифры в линию	0000₂ - услуга "Индивидуальный вызов"	LINEI	Вызывающая сторона должна отправить набранные цифры BCD
АС посылает цифры для набора диспетчера	0000₂ - услуга "Индивидуальный вызов"	DISPATI	Вызывающая сторона должна отправить набранные цифры BCD
АС посылает данные supplementary_user	0000₂ - услуга "Индивидуальный вызов"	SUPLI	Формат данных должен быть определен вызывающей стороной

Подтверждения, принимаемые вызывающей АС (речь)

В некоторый момент после отправки PDU произвольного доступа запроса речевой услуги вызывающая АС может получить подтверждение. Получив подтверждение, АС должна запустить или перезапустить таймер ожидания TP_Timer (TSCC должен поддерживать аналогичный таймер).

АС должна выполнить следующие действия:

а) PDU прохождения для одноблочного запроса услуги речевого вызова следующие:

1) C_WACKD: промежуточное подтверждение. Далее будут следовать другие PDU. АС должна ожидать дальнейшую сигнализацию в течение времени таймера TP_Timer и может указать вызывающей АС на возможную задержку,

2) C_QACKD: вызываемая АС занята другим вызовом. АС должна ожидать в течение времени таймера TP_Timer для дальнейшей сигнализации,

3) C_QACKD: вызов ставится в очередь, поскольку ресурс используется в настоящий момент. АС должна ожидать в течение времени таймера TP_Timer для дальнейшей сигнализации и может указать вызывающей АС на возможную задержку (АС может выбрать между вариантами 1, 2 и 3, обеспечивая вызывающей АС визуальную или звуковую индикацию для каждого из условий);

б) PDU прерывания выбираются из соответствующего IE Reason в C_NACKD PDU (см. 16.3.9). Если вызов был отклонен вызывающей стороной, PDU прерывания, отправленный ТС, должен быть C_NACKD PDU (mirrored_reason): вызов отклонен и прерван. C_NACKD PDU может содержать различные значения Reason и Mirrored Reason, указывающие вызывающей стороне, почему запрос услуги прерван. Вызывающая сторона должна вернуться в состояние ожидания;

PDU обратного вызова (Callback PDU), чтобы указать вызывающей АС, что услуга речевого вызова была принята вызываемой стороной для обратного вызова. Оказание услуги завершено. Вызывающая сторона должна вернуться в состояние ожидания: C_ACKD (mirrored_reason соответствует CallBack);

в) если ТС ранее приняла переадресацию вызова, указывающую, что этот тип запроса услуги будет направлен другому вызываемому абоненту, то заголовок UDT с добавочными данными указывает измененный (переадресованный) адрес.

Проверка радиодоступности вызываемого абонента (речь)

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

- вызываемая АС должна ответить C_NACKU, если она не может принять вызов (по TSCC в адрес вызывающей АС передается ответ с информацией о сбое вызова);

- вызываемая АС должна ответить C_ACKU (Reason соответствует CallBack), если она планирует "перезвонить" вызывающей АС позже (по TSCC в адрес вызывающей АС передается ответ CallBack);

- вызываемый абонент должен ответить служебным сообщением C_ACKU PDU (Reason соответствует MS_Accepted), если вызов принимается, и АС может принять вызов немедленно (TSCC продолжает служебный запрос и выделяет рабочий канал путем передачи соответствующего PDU предоставления канала);

- если АС разрешено FOACSU и сообщением, на которое АС отправляет подтверждение, является C_AHOY со значением IE Service_Kind, установленным в значение 0000₂, Service_Kind_Flag - в значение 1₂, то верным ответом является C_ACKU (Reason соответствует MS_ALERTING). То есть АС оповещена о вызове, но она еще не находится в режиме "трубка повешена" (RFC). После отправки подтверждения АС может инициировать RFC путем отправки C_RAND (услуга "Вызов ответа", при этом IE ACCEPT установлен в значение 0₂). Если вызываемая АС получила вызывной сигнал, но пользователь не будет принимать этот вызов, то она должна отправить C_RAND (услуга "Вызов ответа", при этом IE ACCEPT установлен в значение 1₂), чтобы отклонить вызов;

- если АС разрешено FOACSU (вызов включает дополнительные данные и сообщением, на которое АС отправляет подтверждение, является HEAD Source, соответствующее значению SUPLI с адресом назначения, соответствующим адресу АС с дополнительными данными AD, а UDT_Option_Flag установлен в значение 1₂), то верным ответом является C_ACKU (Reason соответствует MS_ALERTING). То есть вызов АС получен, но она еще не находится в режиме "трубка повешена" (RFC). После отправки подтверждения АС может указывать RFC путем отправки C_RAND (услуга "Вызов ответа", IE ACCEPT установлен в значение 0₂). Если вызываемая АС получила вызов, оповестила об этом пользователя световым, звуковым или иным сигналом, но пользователь не будет принимать вызов, то АС должна послать C_RAND (услуга "Вызов ответа", ACCEPT установлен в значение 1₂), чтобы отклонить вызов.

Выделение рабочего канала

АС должна проверить адресные IE, полученные в блоках данных протокола предоставления речевого канала. Если АС определила, что PDU предоставления канала применим, то она должна перестроиться на указанный физический/логический рабочий канал для передачи речи.

Если вызов направлен разговорной группе и транкинговая сеть поддерживает поздний вход (см. 7.5.3.5), то TSCC может продолжать посылать блоки данных протокола предоставления канала (Late_Entry установлен в значение 1₂) с интервалом T_Late, пока вызов активен. АС, которая только что включилась или стала активной в TSCC, может быть присоединена к разговорной группе.

Для PDU CSBK предоставления конфиденциального речевого канала: если АС принимает такой PDU и в нем IE Source_Address или Target_Address совпадают с ее индивидуальным адресом, то PDU применим.

PDU CSBK предоставления речевого канала разговорной группы:

а) если АС принимает PDU предоставления канала разговорной группы с IE Target_Address, совпадающим с одним из адресов разговорной группы, то PDU применим;

б) если АС принимает PDU предоставления канала разговорной группы с Source_Address, совпадающим с ее индивидуальным адресом, то PDU применим;

в) если АС принимает PDU предоставления широковещательного канала разговорной группы с Target_Address, совпадающим с одним из адресов разговорной группы, то PDU применим;

г) если АС принимает PDU предоставления широковещательного канала разговорной группы с Source_Address, совпадающим с ее индивидуальным адресом, то PDU применим.

Вызывающая АС в SDL одноблочного установления речевого вызова

На рисунках 51 и 52 приведены SDL одноблочного установления речевого вызова OACSU.

Рисунок 51 - SDL одноблочного установления

речевого вызова OACSU. Часть 1

Рисунок 52 - SDL одноблочного установления

речевого вызова OACSU. Часть 2

Примечание - Названия состояния не связаны с названиями состояния в ГОСТ Р 71586.1 и ГОСТ Р 71586.2.

MSC установления вызова, передающего дополнительные данные пользователя (supplementary_user)

На рисунке 53 приведена MSC установления вызова, в которой данные supplementary_user передаются как часть установления вызова.

Рисунок 53 - Установление вызова OACSU АС

с дополнительными данными

7.5.3.4 Процедуры для речевого рабочего канала

Общие положения

АС выделяется речевой физический/логический рабочий канал, указанный в TSCC. При прерывании речевого вызова АС возвращается в TSCC и рабочий канал переназначается другому вызову.

Речевой вызов может распространяться на несколько элементов PTT АС на время продолжительности вызова (пока вызов не будет прерван досрочно по истечении таймера речевой полезной нагрузки), если система определила вызов как "транкинг сообщений". Если система определила вызов как "транкинг передачи", вызов должен быть прерван после завершения каждого элемента PTT. Третий возможный вариант - вызов определен как "квазитранкинговая передача". В этом случае короткий интервальный таймер (TV_Hangtime) между элементами PTT удерживает рабочий канал. Если время короткого интервального таймера истекает, то вызов прерывается и следующий элемент PTT устанавливает новый вызов.

Речевой рабочий канал может быть отнесен к одной из двух основных моделей временного выравнивания таймслотов. Конкретная модель временного выравнивания таймслотов задается в TSCC и сообщается АС блоками данных протокола предоставления канала, как это описано в ГОСТ Р 71586.1:

а) синхронизация с выравниванием поддерживает сигнализацию RC, обеспечивая АС, принимающей RC в нисходящем направлении, возможность передачи информации по восходящему каналу без потери какого-либо нисходящего трафика. Синхронизация с выравниванием не поддерживает дуплексные вызовы;

б) синхронизация со смещением поддерживает дуплексный трафик между АС и позволяет им передавать в одном таймслоте и принимать нисходящую передачу в альтернативном таймслоте.

Процедуры АС и ретранслятора при речевом вызове в рабочем канале описаны в ГОСТ Р 71586.2. Процедуры ТС также соответствуют этому описанию, однако в транкинговом режиме между ТС и АС в дополнение к PDU, описанным в ГОСТ Р 71586.2, осуществляется обмен PDU сопровождения (обслуживания) вызовов.

При активации рабочего канала по нему должен быть передан CACH с любым SLC (в том числе по выбору производителя), за исключением SLC C_SYS_Parms.

В начале вызова должен использоваться метод PATCS, как описано в ГОСТ Р 71586.1-2024 (пункт 13.1.2). При услуге вызова индивидуальной АС частью процедуры установления вызова является проверка радиодоступности.

Процедуры ТС для речевого вызова в рабочем канале

Процедуры ТС для речевого рабочего канала. Основные положения

Физический рабочий канал может передавать один или два независимых речевых вызова. Если новый физический канал выделен в TSCC, CCL_BS должен начать процессы CCL_1 и CCL_2 путем активации канала (описано в ГОСТ Р 71586.2-2024, подпункт 13.1.1.2) и запустить таймер речевого вызова в рабочем канале следующим образом:

а) T_MS-MS_TIMER для индивидуального вызова от АС к АС или вызова от АС к разговорной группе нормального или высокого приоритета;

б) T_MS-Line_TIMER для вызова шлюзовой индивидуальной АС или вызова разговорной группы нормального или высокого приоритета;

в) T_EMERG_TIMER для экстренного вызова.

Проверка радиодоступности АС

ТС может опросить АС, чтобы проверить ее активность (возможность работы) в рабочем канале путем передачи P_AHOY PDU с IE, установленными определенным образом.

TSCC в нисходящем направлении передает P_AHOY PDU с IE, представленными в таблице 43.

Таблица 43

IE P_AHOY для индивидуальной проверки радиодоступности АС

IE	Длина, бит	Комментарий
Service_Options_Mirror	7	000 0000₂
Service_Kind_Flag	1	0₂
ALS	1	0₂ - вызывающая сторона не запросила ALS
ALS	1	1₂ - вызывающая сторона запросила ALS <1>
G/I	1	0₂ - адрес получателя является индивидуальным ID АС
Appended_Blocks	2	00₂
Service_Kind	4	Услуга "Индивидуальный вызов" - 0000₂
Target_Address	24	Индивидуальный адрес вызываемой АС
Source_Address или Gateway	24	TSI
<1> Ответом является P_ACKU PDU (Reason соответствует Message_Accepted).

ТС может также опрашивать разговорную группу, чтобы проверить, активен ли хотя бы один из участников разговорной группы в рабочем канале, методом передачи P_AHOY PDU с IE, представленными в таблице 44.

Таблица 44

IE P_AHOY для проверки радиодоступности разговорной группы

IE	Длина, бит	Комментарий
Service_Options_Mirror	7	000 0000₂
Service_Kind_Flag	1	0₂
ALS	1	0₂ - не применяется
G/I	1	1₂ - адресом получателя является разговорная группа
Appended_Blocks	2	00₂
Service_Kind	4	Услуга "Вызов разговорной группы" - 0000₂
Target_Address	24	Адрес разговорной группы
Source_Address или Gateway	24	TSI

Ответом является P_ACKU (Reason соответствует Message_Accepted). Если более чем одна АС отвечает на этот PDU, то есть вероятность того, что ТС не сможет принять его из-за коллизий. Целью этой процедуры является определение того, активны ли какие-либо разговорные группы, следовательно, ТС может использовать факт наличия пакета для результата проверки радиодоступности разговорной группы.

Примечание - ТС может опрашивать индивидуальную АС или разговорную группу, чтобы проверить, активна ли АС в рабочем канале, без установления вызова. Эта процедура описана в 7.4.13.

Проверка аутентификации

Процедуры аутентификации идентичны процедурам аутентификации, описанным в 7.4.9.3 с учетом замены PDU C_AHOY на PDU P_AHOY.

Дистанционные запрет и разрешение PTT пользователей

ТС в любое время может отправить служебное сообщение P_PROTECT PDU (Protect_Kind соответствует DIS_PTT), направленное индивидуальной АС, разговорной группе или ALLMSID, для запрета PTT. Поскольку PDU P_PROTECT является неподтвержденным, PDU может быть повторен на уровне 2.

ТС может также в любое время послать служебное сообщение P_PROTECT PDU (Protect_Kind соответствует EN_PTT), направленное индивидуальной АС, разговорной группе или ALLMSID, для разрешения PTT. Поскольку PDU P_PROTECT является неподтвержденным, PDU может быть повторен на уровне 2.

В то время как ТС передает PDU P_PROTECT (Protect_Kind соответствует EN_PTT_ONE_MS), направленные индивидуальным пользователям, АС, адрес которой указан в этом PDU, должна активировать PTT и ей разрешается осуществлять передачу, как только рабочий канал освободится. Во время передачи PDU у всех остальных АС PTT должен быть отключен.

Смена рабочего канала

Перестановка вызова на заменяющий речевой рабочий канал

ТС может отправлять блоки данных протокола предоставления канала по рабочему каналу, чтобы переместить уже активную АС на альтернативный (другой) рабочий канал для передачи речи. Если АС ранее получила служебное сообщение в рабочем канале P_PROTECT PDU, чтобы запретить PTT, то PTT должен быть повторно разрешен в новом рабочем канале при передаче речи, в случае если услуга вызова не была широковещательной, когда вызываемые абоненты должны сохранять состояние PTT (запрет/разрешение) из первоначального вызова.

Удаление АС, не являющихся законными абонентами, из рабочего канала

ТС может передать служебное сообщение P_PROTECT (ILLEGALLY_PARKED) PDU в следующих случаях:

а) при индивидуальном вызове, если значение IE Target_Address, переданного в P_PROTECT (ILLEGALLY_PARKED) PDU, совпадает с Target_Address, переданным в PDU предоставления канала, и IE Source_Address, переданный в P_PROTECT (ILLEGALLY_PARKED) PDU, совпадает со значением элемента Source_Address, переданным в PDU предоставления канала, то АС не должна предпринимать какие-либо действия. В противном случае АС должна покинуть рабочий канал;

б) при вызове разговорной группы, если значение IE Target_Address, переданное в P_PROTECT (ILLEGALLY_PARKED) PDU, совпадает со значением Target_Address, переданным в PDU предоставления канала, то АС не должна предпринимать какие-либо действия, в противном случае АС должна покинуть рабочий канал;

в) если установлен индивидуальный вызов и оба абонента активны в рабочем канале, то служебное сообщение P_PROTECT (ILLEGALLY_PARKED) PDU может быть отправлено ТС в промежутках между элементарными периодами передачи полезной нагрузки. Однако если одна из АС инициирует вызов, адресованный третьей стороне, то в вызове участвуют три стороны. Тогда ТС между периодами передачи полезной нагрузки и пока вызов не будет сброшен:

- не должна передавать P_PROTECT (ILLEGALLY_PARKED) PDU;

- может передавать PDU "Прерыватель с LC".

Разъединение речевого вызова

ТС должна разъединить абонентов, вовлеченных в речевой вызов в рабочих каналах или совмещенном TSCC, если:

а) истекает время таймеров вызова T_MS-MS_TIMER, T_MS-Line_TIMER или T_EMERG_TIMER;

б) ТС принимает в рабочем канале служебное сообщение P_MAINT PDU (Maint_Kind соответствует DISCON);

в) ТС определяет любым другим способом, что вызов завершен (например, отключена линия связи с ТФОП);

г) истекает время интервального таймера TV_Hangtime.

ТС должна разъединить вызов путем передачи служебного сообщения P_CLEAR PDU. Поскольку этот PDU не является подтвержденным, он может быть повторен на уровне 2.

MSC одноблочного прерывания речевого вызова ТС

На рисунке 54 приведена MSC прерывания речевого вызова ТС для вызовов между АС или вызовов "АС - разговорная группа" в рабочем канале, как описано в 7.5.3.4 ("Разъединение речевого вызова").

Примечание - Опция "ТС определяет любым другим способом, что вызов завершен" не изображена на этой MSC.

Рисунок 54 - MSC прерывания речевого вызова

Разъединение конкретной АС или разговорной группы

ТС может выборочно разъединить индивидуальную АС путем передачи в нисходящем направлении рабочего канала P_AHOY PDU с IE, указанными в таблице 45.

Таблица 45

IE P_AHOY PDU для разъединения индивидуальных АС

в рабочем канале при передаче речевого вызова

IE	Длина, бит	Комментарий
Service_Options_Mirror	7	000 0000₂
Service_Kind_Flag	1	0₂ указывает, что адрес источника - это индивидуальный адрес
ALS	1	0₂ - не применяется
G/I	1	0₂ - адресом источника является индивидуальный ID АС
Appended_Blocks	2	00₂
Service_Kind	4	Отмена услуги "Вызов" - 1111₂ Service_Kind_Flag - 0₂
Target_Address	24	Индивидуальный адрес АС
Source_Address или Gateway	24	TSI (см. А.5)

Разрешенным ответом является P_ACKU PDU (Message_Accepted).

ТС может разъединить разговорную группу путем передачи в нисходящем направлении рабочего канала P_AHOY PDU с IE, указанными в таблице 46.

Таблица 46

IE служебного сообщения P_AHOY PDU для разъединения

разговорной группы с речевым рабочим каналом

IE	Длина, бит	Комментарий
Service_Options_Mirror	7	000 0000₂
Service_Kind_Flag	1	1₂ указывает, что адрес источника - разговорная группа
ALS	1	0₂ - не применяется
G/I	1	1₂ - адрес источника - разговорная группа
Appended_Blocks	2	00₂
Service_Kind	4	Отмена услуги "Вызов" - 1111₂
Target_Address	24	Разговорная группа
Source_Address или Gateway	24	TSI

Разрешенным ответом является служебное сообщение P_ACKU (Message_Accepted) PDU, передаваемое в рабочем канале.

Процедуры АС для речевого вызова в рабочем канале

АС принимает служебное сообщение "Проверка радиодоступности АС"

Если АС принимает на свой индивидуальный адрес в служебном сообщении P_AHOY PDU с IE, указанными в таблице 43, то она должна ответить P_ACKU PDU с параметром IE Reason, соответствующим значению MS_Accepted.

Если АС принимает на адрес разговорной группы P_AHOY PDU, ранее переданный в PDU предоставления рабочего канала, который определил АС рабочий канал для передачи пользовательских сообщений (речь, данные) (PDU, указанные в таблице 44), то она должна ответить служебным сообщением P_ACKU PDU с параметрами IE Reason, соответствующего значению MS_Accepted.

АС принимает запрос проверки аутентификации

Процедуры аутентификации идентичны процедурам аутентификации, описанным в 7.4.9.3, но с заменой PDU C_ACKU ответа аутентификации на PDU P_ACKU.

Запрет/разрешение PTT пользователей

Если АС принимает в рабочем канале служебное сообщение P_PROTECT (в котором Protect_Kind соответствует DIS_PTT) на ее индивидуальный адрес или на адрес разговорной группы, переданный ранее в PDU предоставления канала (Channel Grant), которым она была переведена на рабочий канал или значение ALLMSID в адресе получателя PDU предоставления канала, то АС должна запретить PTT.

Если АС принимает в рабочем канале служебное сообщение P_PROTECT (в котором Protect_Kind соответствует EN_PTT) на ее индивидуальный адрес или на адрес разговорной группы, переданный ранее в PDU предоставления канала, которым она была переведена на рабочий канал, или значение ALLMSID в адресе получателя PDU предоставления канала, то АС должна снова разрешить PTT, за исключением случая, когда она принимает широковещательный вызов.

В то время как АС получает направленный на ее индивидуальный адрес P_PROTECT PDU с параметром Protect_Kind, соответствующим EN_PTT_ONE_MS, она должна разрешить PTT. Все остальные АС должны запретить PTT.

АС принимает служебное сообщение с использованием PDU предоставления канала

Если АС принимает соответствующий PDU предоставления канала, направленный на ее индивидуальный адрес или на адрес разговорной группы, предварительно переданный в PDU предоставления канала, который предоставил АС рабочий канал, то АС должна перенастроиться на новый назначенный физический/логический канал. Если PTT был запрещен до получения PDU предоставления канала, PTT должен быть повторно разрешен, если эта АС не была получателем установления широковещательного вызова или вызова к ALLMSIDL, ALLMSIDZ или ALLMSID (см. А.5).

Завершение вызова

Если вызов является индивидуальным вызовом или АС является инициатором вызова разговорной группы, АС должна обозначить завершение вызова путем передачи нескольких служебных сообщений P_MAINT PDU с параметром в IE Maint_Kind, соответствующим DISCON. АС должна послать блоки данных протокола служебными сообщениями P_MAINT PDU последовательно, затем вернуться к процедурам обнаружения TSCC (предполагается, что первоначально выбранным TSCC является TSCC, который передал вызов в рабочий канал).

Если АС является участником разговорной группы, то она должна завершить этот вызов без отправки любых PDU и вернуться к процедурам обнаружения TSCC (предполагается, что первоначально выбранным TSCC является TSCC, который передал вызов в рабочий канал).

АС принимает служебное сообщение PDU P_CLEAR

Если АС принимает служебное сообщение P_CLEAR PDU, то она должна перейти к TSCC, обозначенному номером логического физического канала, как указано в 16.2.2.4 ("Служебное сообщение PDU Clear (P_CLEAR), передаваемое с использованием CSBK").

АС принимает избирательный отбой P_AHOY PDU

Если АС принимает индивидуально адресованный IE P_AHOY PDU, в котором Service_Kind установлен в значение 1111₂, Service_Kind_Flag установлен в значение 0₂, то она должна отправить P_ACKU PDU с параметром IE Reason, соответствующим значению MS_Accepted, покинуть рабочий канал и вернуться к процедурам обнаружения TSCC (предполагается, что первоначально выбранным TSCC является TSCC, который передал вызов в рабочий канал).

Если АС принимает служебное сообщение P_AHOY PDU с IE Service_Kind, установленным в 1111₂, Service_Kind_Flag, установленным в 1₂, направленное на адрес разговорной группы, предварительно переданный в служебном сообщении с использованием PDU предоставления канала разговорной группы, то она должна отправить служебное сообщение P_ACKU PDU (в котором Reason соответствует MS_Accepted), покинуть рабочий канал и вернуться к процедурам обнаружения TSCC (предполагается, что первоначально выбранным TSCC является TSCC, который передал вызов в рабочий канал).

АС принимает блоки данных протокола P_PROTECT PDU

Если АС принимает P_PROTECT(ILLEGALLY_PARKED) PDU, то:

а) при индивидуальном вызове, если значение IE Target_Address, полученное из P_PROTECT(ILLEGALLY_PARKED) PDU, совпадает со значением Target_Address из PDU предоставления канала, а Source_Address, переданный P_PROTECT(ILLEGALLY_PARKED) PDU, совпадает с Source_Address, переданным PDU предоставления канала, то АС не должна предпринимать никаких действий, в противном случае АС должна покинуть рабочий канал без каких-либо дальнейших передач;

б) при вызове разговорной группы, если значение служебного элемента Target_Address, полученное из служебного сообщения P_PROTECT(ILLEGALLY_PARKED) PDU, совпадает со значением Target_Address, переданным PDU предоставления канала, то АС не должна предпринимать никаких действий, в противном случае АС должна покинуть рабочий канал без каких-либо дальнейших передач.

Тайм-аут в рабочем канале

АС должна поддерживать несколько таймеров, пока она активна в речевых вызовах в рабочем канале:

а) таймер неактивности.

АС должна измерять продолжительность времени, в течение которого она не может обнаружить надлежащее качество канала. Если АС не может обнаружить канал с надлежащим качеством в течение установленного времени таймера неактивности TV_Inactive, то она должна предположить, что вызов завершен и вернуться к процедурам обнаружения TSCC без отправки какой-либо сигнализации о прерывании (завершении) вызова (предполагается, что выбранным TSCC является TSCC, который передал вызов в рабочий канал);

б) таймер длительности элементарного периода текущего вызова (время передачи полезной нагрузки).

АС должна поддерживать таймер максимальной длительности элементарного периода передачи полезной нагрузки. Если АС достигает определенной этим таймером максимальной длительности элементарного периода передачи полезной нагрузки TV_Item, то она должна передать "Прерыватель с LC", запретить PTT и ждать, пока пользователь не выключит PTT, прежде чем повторно разрешить PTT;

в) таймер вызова общей полезной нагрузки.

Если истекает время таймеров речевого вызова (вызова общей речевой полезной нагрузки) T_MS-MS_TIMER, T_MS-Line_TIMER или T_EMERG_TIMER, то АС должна последовательно передать номер (N_Maint) в служебном сообщении P_MAINT PDU, затем вернуться к процедурам обнаружения TSCC (предполагается, что выбранным TSCC является TSCC, который передал вызов в рабочий канал). Если АС посылала речевые кадры, когда истекло время таймера текущего речевого вызова, то она должна передать "Прерыватель с LC" перед передачей блоков данных протокола P_MAINT PDU.

7.5.3.5 Поздний вход

Принцип позднего входа

Для установления вызова, адресованного разговорной группе, этой группе назначается рабочий канал с помощью передачи по TSCC одного или более служебных сообщений с использованием PDU предоставления канала. Эти PDU содержат IE Late_Entry, установленный в значение 0₂ для исходных PDU предоставления канала.

При речевых вызовах в разговорной группе АС может включиться или просто войти в зону действия TSCC через некоторое время после того, как вызов был установлен. Если сеть использует поздний вход, пока вызов активен в рабочем канале, то TSCC должен послать служебное сообщение с использованием PDU предоставления канала (Late_Entry установлен в значение 1₂) в интервалы из T_Late секунд, адресованное одной разговорной группе. Этот PDU называется PDU предоставления канала Late_Entry. АС, которая становится активной в TSCC, в то время, пока такой вызов существует, будет включена в вызов разговорной группы блоками данных протокола предоставления канала Late_Entry.

В течение вызова разговорной группы АС может отключиться от рабочего канала этой группы, покинув остальных участников вызова. Эта АС возвращается в TSCC. Вызов все еще активен, поэтому TSCC продолжает отправлять PDU предоставления канала Late_Entry. АС должна быть способна отличить PDU предоставления канала Late_Entry от PDU предоставления канала, отправляемых во время установления вызова, и избегать повторного включения в вызов разговорной группы.

Таймер вызова

Служебное сообщение C_BCAST PDU (Announcement_type установлен в значение 0 0001₂) может быть передано TSCC, чтобы сообщить АС о максимальном времени вызова для рабочего канала. Если важно, чтобы таймеры вызова любых АС, входящих в вызов по принципу позднего входа (Late_Entry), были засинхронизированы с АС, занимающими рабочий канал, то TSCC может предварить предоставление канала Late_Entry служебным сообщением C_BCAST (в котором Announcement_type установлен в значение 0 0001₂), указывая на оставшееся время уже установленного вызова. TSCC, в случае необходимости в обнулении таймера передачи вызова для установления новых вызовов, сразу после предоставления канала Late_Entry отправляет служебное сообщение C_BCAST PDU (Announcement_type установлен в значение 0 0001₂).

7.5.3.6 Оповещение о приоритетном вызове

Принцип оповещения

Как правило, если АС присоединилась к одному групповому вызову, то она не сможет присоединиться к другим. Однако в некоторых случаях АС может отдавать приоритет новым вызовам перед текущими. С помощью процедуры уведомления о приоритетном вызове TSCC может информировать АС в текущем групповом вызове о новом вызове, который является более предпочтительным для некоторых АС в этой группе. При получении уведомления АС может либо покинуть текущий вызов и перейти к новому вызову, либо проигнорировать уведомление и остаться в текущей переговорной группе.

Уведомление о новом вызове в рабочем канале

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

Значения IE в P_GRANTS для различных вызовов в рабочем канале, а также действия АС при их получении определяются производителем.

7.5.3.7 Услуга прослушивания окружения (ALS)

ALS - введение

ALS позволяет вызывающей стороне (АС или шлюзу) инициировать передачу от вызываемой АС без каких-либо действий со стороны пользователя последней.

Процедуры ALS для установки вызова

АС или шлюз способны запросить услугу голосового вызова для другой индивидуальной АС, вызвав процедуру ALS с помощью единичного запроса голосовой службы.

АС запрашивает голосовую услугу ALS, посылая запрос произвольного доступа C_RAND в соответствии с процедурами произвольного доступа, описанными в 7.2. IE запроса произвольного доступа передаются на CCL стека протоколов и устанавливаются, как указано в таблице 47. В данном случае бит ALS_SERV установлен в значение 1₂, Service_Kind установлен в значение 0000₂, что указывает TSCC на то, что АС запросила услугу ALS. Вызывающая АС может повысить уровень срочности, установив EMERG в значение 1₂, инициировав тем самым экстренный запрос ALS. TSCC должна ответить в соответствии с 7.5.2 и 7.5.3.

Если шлюз запрашивает услугу ALS, то процесс установления вызова AI начинается с передачи TSCC вызываемой АС сообщения C_AHOY (бит ALS_SERV соответствует 1₂).

Примечание - PDU предоставления канала не содержит информации о том, что была вызвана услуга ALS. Эта информация содержится в C_AHOY, который предшествует предоставлению канала.

Процедуры TSCC идентичны обычному голосовому вызову, за исключением того, что для PDU C_RAND и PDU C_AHOY бит ALS_SERV установлен в значение 1₂.

По TSCC должен быть передан C_AHOY PDU с IE, указанными в таблице 47, чтобы проверить, примет ли АС вызов ALS.

Таблица 47

IE C_AHOY для проверки возможности приема ALS

абонентской станцией

IE	Длина, бит	Комментарий
Service_Options_Mirror	7	000 0000₂
Service_Kind_Flag	1	0₂ - не используется
Ambient Listening Service (ALS_SERV)	1	1₂ - радиопроверка, слушает ли АС
G/I	1	0₂ - адрес ID АС получателя
Appended_Blocks	2	00₂
Service_Kind	4	0000₂ - служба индивидуальных голосовых вызовов
Target_Address	24	Адрес индивидуальной АС
Source_Address или Gateway	24	Адрес вызывающей АС или шлюза
Примечание - ALS применим только к индивидуальным вызовам АС.

Если вызываемая АС поддерживает ALS, то ответ должен быть C_ACKU (в котором Reason соответствует Message_Accepted). Затем вызываемая АС должна запустить таймер T_ALS_REQUEST_LIFE_SPAN, и если во время работы этого таймера АС получает PDU Private Channel Grant с адресом источника и адресом назначения, совпадающими с адресами в предыдущем C_AHOY, то АС отрабатывает этот вызов как вызов ALS.

Вызываемый абонент должен принимать вызовы ALS как OACSU.

С момента, когда АС приняла приглашение участвовать в вызове ALS, применяются правила выполнения вызова, определенные в 7.5.3.7 ("Процедуры ALS для рабочего канала").

Если время таймера T_ALS_REQUEST_LIFE_SPAN истекает до получения PDU Private Channel Grant канала, АС с этого момента должна рассматривать все соответствующие PDU Private Channel Grant как тип вызова, не относящийся к ALS.

Если АС не поддерживает ALS, то ответ должен быть C_NACKU (в котором Reason соответствует MSNot_Supported) с IE, как показано в таблице 48.

Таблица 48

Элементы ответа на радиопроверку ALS АС

IE	Длина, бит	Комментарий
Response_Info	7	XXX XXXX₂
Reason_Code	8	0000 0000₂ = MSNot_Supported
R	1	0₂
Target_Address	24	Адрес вызывающей стороны
Additional_Information (Source_Address)	24	Индивидуальный адрес АС

Процедуры ALS для рабочего канала

Настоящий документ:

а) не предписывает, предоставляет или не предоставляет АС вызываемой стороны индикацию пользователю о том, что была вызвана служба ALS;

б) не исключает возможность того, что во время прослушивания окружения вызываемая АС может отменить или не отменять вызов ALS и осуществлять, а также принимать вызовы в обычном режиме.

Процедуры ALS поддерживают приоритетные вызовы.

Пока активен рабочий канал ALS, вызываемая АС должна непрерывно передавать данные в течение времени, определяемого таймерами T_ALS или T_ALS_E.

При активном рабочем канале вызывающая сторона в основном прослушивает канал, но для прерывания передачи АС, осуществляющей вызов с использованием ALS, с целью ответной передачи может быть использована функция прерывания полезной нагрузки, как определено в 7.5.3.7 ("Прерывание полезной нагрузки для ALS"). Когда прерывающая АС закончит свою передачу, прерванная АС должна возобновить свою передачу на оставшееся время таймера ALS.

Таймаут в рабочем канале ALS

АС, осуществляющая вызов с использованием ALS, должна поддерживать следующие таймеры, пока она активна в речевом рабочем канале ALS (см. таблицу А.1):

а) T_ALS - определяет общее время для неэкстренных приоритетных вызовов;

б) T_ALS_E - определяет общее время для экстренных вызовов.

Завершение вызова для ALS

Если при активном рабочем канале вызываемая АС прекращает передачу, TSCC может завершить вызов с помощью любой из процедур, предусмотренных 7.5.3.4 ("Завершение вызова", "АС принимает служебное сообщение PDU P_CLEAR", "АС принимает избирательный отбой P_AHOY PDU").

Если время общего таймера вызова речевой полезной нагрузки (T_ALS или T_ALS_E) истекает, то АС должна последовательно передать определенное количество (N_Maint) PDU P_MAINT (в которых Maint_Kind соответствует DISCON) для индикации окончания вызова, а затем вернуться к процедурам обнаружения и сбора данных по TSCC (предполагается, что выбранным TSCC является тот TSCC, который перевел вызов в рабочий канал). Если АС передавала речевые кадры в момент истечения времени общего таймера вызова речевой полезной нагрузки, то она должна передать "Прерыватель с LC" перед передачей PDU P_MAINT.

В дополнение к способам, определенным выше, если ALS была инициирована АС, эта АС может запросить ТС о завершении вызова ALS. Процедуры для этого определены в 7.5.3.7.

Прерывание полезной нагрузки для ALS

В транкинговой сети могут использоваться АС, поддерживающие и не поддерживающие услугу прерывания полезной нагрузки (Payload Interrupt). Если транкинговая сеть поддерживает эти услуги, то они должны быть реализованы и для процедуры ALS в соответствии с настоящим стандартом (см. 7.4.15 и 7.4.16).

Если АС поддерживает услугу Payload Interrupt во время вызова ALS, то АС автоматически возобновит передачу, когда заметит, что прерывающий абонент прекратил разговор, о чем свидетельствует отсутствие исходящих речевых PDU.

TSCC может использовать PDU P_PROTECT (в которых Protect_Kind соответствует EN_PTT_ONE_MS), адресованные прерывающей стороне, чтобы предотвратить автоматическую повторную передачу прерванной АС, осуществлявшей вызов с использованием ALS, после запроса прерывания передачи на исходящем канале.

АС, использующая ALS, может также использовать таймер T_ALS_RETRANSMIT_DELAY для задержки автоматического повторного включения своей передачи, чтобы учесть задержки в представлении ТС действительной исходящей активности от прерывающей АС, когда ТС не поддерживает использование P_PROTECTS. Таймер T_ALS_RETRANSMIT_DELAY должен запускаться АС при прекращении своей передачи после принятия запроса на прерывание передачи.

7.5.4 Услуга "Опрос коротких данных с использованием процедуры UDT"

7.5.4.1 Услуга "Опрос коротких данных" - общие положения

Услуга "Опрос коротких данных" позволяет опрашивать данные у АС с использованием TSCC. С помощью этой услуги может быть передано до 368 бит данных в нескольких форматах, включая двоичный, BCD, семибитный текст ISO (см. [2]), восьмибитные символы ISO (см. [3]), отформатированные данные о местоположении NMEA (см. [1]) и конкретные собственные форматы производителя. Если опрашиваются отформатированные двоичные данные переменной длины, максимальное число битов равно 367, потому что один бит используется для обозначения окончания соответствующих данных (см. Б.3.2).

Примечание - Вызывающая и опрашиваемая АС будут определять количество добавочных UDT, требуемых для транспортировки опрашиваемых данных.

Услуга "Опрос коротких данных" использует одноблочное установление вызова.

На рисунке 55 в качестве примера применения услуги "Опрос коротких данных" отображен процесс передачи опроса коротких данных UDT от АС:

	Aloha		Ahoy		Основная часть для добавления данных		Aloha M = 24 Address = NULL
	RQ произвольного доступа		Ответ Ack		Добавленные данные		Получатель сообщения

Рисунок 55 - Пример передачи опроса коротких данных

Процедура передачи опроса коротких данных включает следующие этапы и подпункты:

а) АС(А) определяет количество добавочных UDT для опрашиваемых коротких данных UDT. В этом примере требуется один добавочный UDT;

б) "А" - служебное сообщение произвольного доступа C_RAND PDU. В IE Target_Address должен быть установлен адрес опрашиваемой стороны, в Service_Kind установлен "Short Data Polling" и в IE Appended_Short_Data - количество блоков данных для транспортировки опрашиваемых коротких данных UDT;

в) "Б" - служебное сообщение C_AHOY PDU от вызывающей стороны, которая запрашивает у АС(Б) передачу коротких данных UDT, используя процедуру UDT;

г) "В" - фаза загрузки, состоящая из многоблочного заголовка UDT с добавочными данными;

д) "Г" - фаза выгрузки, состоящая из многоблочного заголовка UDT с добавочными данными;

е) "Д" - окончательное подтверждение от АС(А).

Максимальное количество битов, которое может быть передано с использованием услуги опроса коротких данных UDT, ограничено максимальным числом UDT AD. Протокол транкинговой сети разрешает до четырех добавочных UDT.

На рисунке 56 показана передача опроса коротких данных UDT от шлюза к АС. TSCC запрашивает короткие данные UDT с помощью передачи служебного сообщения C_AHOY PDU от шлюза с идентификатором SDMI на адрес АС(А). АС(А) отвечает заголовком UDT с короткими данными UDT.

	Aloha		Ahoy		Заголовок для добавленных данных
	Добавленные данные		Получатель сообщения		Aloha M = 24 Address = NULL

Рисунок 56 - Пример опроса коротких данных UDT от шлюза

7.5.4.2 Процедуры опроса коротких данных для TSCC

Общие положения

АС запрашивает услугу опроса коротких данных UDT для транкинговой сети путем создания PDU запроса произвольного доступа с IE Target_Address, который может содержать:

- адрес АС;

- адрес разговорной группы;

- адрес шлюза (UDT для передачи расширенного адреса назначения от АС).

Когда TSCC отвечает на запрос произвольного доступа, он должен запустить таймер TNP_Timer. Этот таймер должен быть перезапущен, если TSCC отправляет вызывающей стороне дополнительные PDU о ходе выполнения вызова.

Ответ TSCC на запрос опроса UDT от АС

Когда служебные сообщения с использованием PDU услуги опроса коротких данных UDT произвольного доступа принимаются по TSCC, TSCC должен отправить ответ в соответствии с процедурами произвольного доступа, описанными в 7.2.

PDU, представляющие ответ на запрос произвольного доступа услуги опроса коротких данных UDT к АС, следующие:

а) служебные сообщения с использованием PDU подтверждения C_NACKD, C_QACKD, C_WACKD;

б) служебные сообщения C_AHOY PDU от вызывающей стороны, дающие команду опрашиваемой АС передавать опрашиваемые короткие данные, используя процедуру UDT (C_AHOY Service_Kind установлен в значение 0110₂, Source_Address соответствует MSID вызывающей стороны, Target_Address соответствует MSID опрашиваемой стороны);

в) служебное сообщение C_AHOY PDU от AUTHI (проверка аутентификации АС).

Когда TSCC отправляет C_AHOY PDU, описанный выше в перечислении б), опрашиваемая АС знает адрес вызывающей стороны и может отправить опрашиваемые данные, которые являются специфическими для конкретной АС, или отклонить запрос опроса, если он был не от конкретной АС.

Если опрашиваемая АС переадресовала свои вызовы, то ответом должен быть C_NACKD PDU (в котором Reason соответствует Div_Cause_Fail).

Проверка радиодоступности вызываемой АС (опрос коротких данных UDT)

TSCC перед тем, как проводить опрос коротких данных UDT, может проверить радиодоступность вызываемой АС.

TSCC может проверить радиодоступность опрашиваемой стороны методом отправки C_AHOY PDU на индивидуальный адрес опрашиваемой АС. Если ответ от опрашиваемой стороны не получен, TSCC может повторить C_AHOY PDU на уровне 2.

IE в служебном сообщении с использованием PDU проверки радиодоступности должны соответствовать приведенным в 7.4.13 (таблица 32).

При проверке радиодоступности требуется ответ от вызываемой стороны:

а) если ответом является C_NACKU PDU, TSCC должен отказаться от опроса коротких сообщений, отправить вызывающей АС соответствующий ответ о сбое вызова, а IE Reason в C_NACKD PDU установить в значение mirrored_reason;

б) если ответом является C_ACKU PDU (в котором IE Reason установлен в значение MS_Accepted), TSCC должен инициировать запрос услуги и провести опрос коротких данных UDT, используя процедуру UDT.

Доставка опрашиваемых данных вызывающей стороне

В нисходящей фазе TSCC передает вызывающей стороне опрашиваемое сообщение коротких данных UDT, используя процедуру UDT.

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

Окончательное подтверждение вызывающей стороны к TSCC

Окончательной фазой транзакции опроса является подтверждение вызывающей АС успешного получения опрашиваемых данных. Если TSCC не принял ответ, он может повторить нисходящую фазу, описанную в 7.5.4.2 ("Доставка опрашиваемых данных вызывающей стороне").

Процедуры опроса коротких данных от шлюза TSCC

Услуга опроса коротких данных через шлюз показана на рисунке 56. TSCC передает C_AHOY PDU от шлюза с идентификатором SDMI, адресованный индивидуальной АС (C_AHOY Service_Kind установлен в значение 0110₂, Source_Address соответствует адресу SDMI, Target_Address соответствует MSID опрашиваемой стороны).

После передачи служебного сообщения C_AHOY PDU необходим ответ о его получении:

а) если ответом является C_NACKU PDU, при этом TSCC должен отказаться от транзакции опроса коротких сообщений;

б) если ответом является многоблочная передача с использованием процедуры UDT, содержащая опрашиваемые данные, и транзакция завершена.

7.5.4.3 Процедуры опроса коротких данных для АС

АС запрашивает услугу вызова опроса коротких данных UDT у другой индивидуальной АС, используя одноблочный запрос услуги.

АС запрашивает услугу опроса коротких данных UDT путем отправки запроса произвольного доступа служебным сообщением C_RAND PDU с соблюдением процедур произвольного доступа, описанных в 7.2. IE в запросе произвольного доступа передаются на CCL стека протоколов и устанавливаются в соответствии с таблицей 49.

Таблица 49

IE C_RAND PDU для услуги опроса коротких данных

IE	Размер, бит	Длина, бит	Имя	Значение	Комментарий
Service_Options	7	1	EMERG	Не применяется - 0₂
		1	-	0₂	Конфиденциальность (R)
		1	SUPED_SV	0₂	Не применяется - 0₂
		4	POL_FMT	XXXX₂	Формат опрашиваемых данных
Proxy Flag	1	-	PROXY	0₂	Не определен для услуги опроса
R	2	-	-	00₂	-
Appended_Short_Data	2	-	SDATA_VAL	00₂	Количество UDT, требуемых для передачи опрашиваемых коротких данных UDT
Service_Kind	4	-	SD_P_SRV	0110₂	Услуга опроса коротких данных
Target_Address	24	-	-	XX...X₂	Адрес опрашиваемой АС
Source_Address	24	-	-	XX...X₂	Адрес запрашивающей АС

7.5.4.4 Инициирование услуги опроса коротких данных

Для запроса услуги опроса коротких данных UDT к индивидуальной АС адрес опрашивающей АС указывается в IE Target_Address в PDU произвольного доступа C_RAND. IE Service_Kind указывает, что запрашиваемая услуга - опрос коротких данных.

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

7.5.4.5 Ответ на сообщение опроса коротких данных UDT произвольного доступа

Вызывающая АС должна принять следующие PDU в качестве подтверждающего ответа на запрос произвольного доступа опроса коротких данных UDT:

а) PDU подтверждения C_NACKD, C_QACKD, C_WACKD;

б) C_AHOY PDU, дающий команду опрашиваемой АС передать ее короткое информационное сообщение UDT, используя процедуру UDT, как описано в 7.5.4.2 ("Ответ TSCC на запрос опроса коротких данных UDT от АС"). При этом:

1) при опросе от шлюза адресом вызывающей стороны является SDMI,

2) при опросе от АС адресом вызывающей стороны является индивидуальный адрес АС.

7.5.4.6 Окончательное подтверждение от вызывающей АС

В нисходящей фазе TSCC передает вызывающей стороне сообщение опроса коротких данных UDT. Ответами для TSCC должны быть следующие:

а) подтверждения в служебном сообщении C_NACKU PDU, указывающие на то, что транзакция потерпела неудачу;

б) подтверждения в служебном сообщении C_ACKU PDU (Reason соответствует MS_Accepted), указывающие на то, что транзакция была успешной.

7.5.4.7 Тайм-аут в ожидании дальнейшей сигнализации

АС, ожидающая дальнейшей сигнализации, должна отказаться от услуги опроса коротких данных UDT и вернуться в свободное состояние, если время таймера TNP_Timer истекает.

7.5.4.8 АС, принимающая сообщения C_AHOY PDU для опроса коротких данных UDT

Если АС принимает C_AHOY PDU с IE Target_Address, совпадающим с ее индивидуальным адресом и значением Service_Kind, соответствующим услуге опроса коротких данных UDT, то она должна ответить с помощью:

а) многоблочного PDU UDT Head с IE Target_Address, совпадающим с адресом вызывающего абонента (источника) из C_AHOY PDU. IE Appended_Blocks в заголовке UDT указывает количество добавочных блоков UDT;

б) C_NACKU PDU, если опрашиваемая АС не может принять запрос на опрос коротких данных UDT.

7.5.5 Служба статусных сообщений

7.5.5.1 Общие положения

Служба статусных сообщений позволяет обмениваться короткими прекодированными (заранее определенными и закодированными цифровыми значениями) сообщениями по TSCC. С использованием этой службы могут быть переданы 7 бит информации. Служба статусных сообщений объекта (АС) передает сообщения о его состоянии от инициатора к отдельному получателю или разговорной группе. Служба статусных сообщений дает возможность инициатору запросить сообщение состояния у адресуемого объекта. Для этого передаются 7 бит, с помощью которых могут быть сформированы 128 сообщений, запрограммированных в оборудовании транкинговой сети (АС, контроллер ТС) и указывающих на заранее определенные состояния объекта.

Возможные варианты состояния объекта можно запрограммировать 100 значениями состояния от 0 до 99 (от 000 0000₂ до 110 0011₂), которые могут быть использованы для службы статусных сообщений и имеют определяемое пользователем значение. Эти варианты программируются при развертывании сети и не описаны в настоящем стандарте. Другие варианты состояния имеют следующие значения:

- значения состояния в диапазоне от 100 до 124 (от 110 0100₂ до 111 1100₂) зарезервированы;

- значение состояния 125 (111 1101₂) является состоянием системы, определенным для процедуры "Прерывание передачи" (см. 7.4.16);

- значение состояния 126 (111 1110₂) является состоянием системы, используемым для аварийной сигнализации (см. 7.5.5.4). Процедуры по передаче этого состояния идентичны процедурам, описанным в 7.5.5.2;

- значение состояния 127 (111 1111₂) определяет услугу "Опрос состояния" (см. 7.5.5.3). Сообщения состояния, адресуемые от АС к TSCC, являются системными сообщениями.

7.5.5.2 Процедура предоставления услуги "Доставка состояния"

Общие положения

Процедура предоставления услуги "Доставка состояния" использует механизм передачи данных с промежуточным накоплением. АС может послать сообщение состояния индивидуальной АС, разговорной группе, PSTN или PABX, шлюзу соединительной линии, шлюзу диспетчера или TSCC. TSCC может также передать короткое информационное сообщение UDT от шлюза или специального идентификатора на имя индивидуальной АС или разговорной группы.

На рисунке 57 приведен пример передачи сообщения состояния от одной АС к другой:

а) "А" - служебное сообщение произвольного доступа C_RAND PDU. Вызываемой стороной является АС(Б) с IE Service_Kind, установленным в значение "Status". Значение состояния находится в диапазоне от 000 0000₂ до 111 1110₂;

б) "Б" - служебное сообщение C_AHOY PDU от АС(А), содержащее значение состояния;

в) "В" - подтверждение от АС(Б);

г) "Г" - окончательное подтверждение для вызываемой стороны АС(А). Следует отметить, что подтверждение повторяется для надежности передачи.

Рисунок 57 - Пример услуги "Доставка состояния" для АС

Процедуры услуги "Доставка состояния" для TSCC

Процедуры услуги "Доставка состояния" для TSCC - общие положения

АС инициирует услугу "Доставка состояния" способом произвольного доступа, направленным:

а) в адрес АС (одноблочное установление вызова);

б) в адрес шлюза (многоблочное установление вызова);

в) TSCC.

Когда TSCC отвечает на запрос произвольного доступа, он должен запустить таймер (TNP_Timer). Этот таймер должен быть перезапущен, если TSCC отправляет дополнительные сообщения о ходе выполнения вызова вызывающей стороне.

Ответ TSCC на одноблочное установление вызова услуги "Доставка состояния"

При получении запроса произвольного доступа услуги TSCC должен передать на выбор:

а) служебные сообщения с использованием PDU подтверждения C_NACKD, C_WACKD (в котором Reason соответствует Wait), C_QACKD, адресованные вызывающей АС;

б) служебное сообщение C_AHOY PDU, адресованное вызываемой АС для проверки ее состояния;

в) служебное сообщение C_AHOY PDU от AUTHI (проверка аутентификации АС);

г) заголовок UDT с добавочными блоками (услуга сообщения состояния переадресовывается). Если ТС ранее приняла переадресацию вызова, указывающую на то, что запрос услуги будет направлен другой вызываемой стороне, TSCC должен вызвать процедуру передачи с использованием процедуры UDT и отправить вызывающей стороне заголовок UDT с добавочными данными.

Ответ TSCC на многоблочное установление вызова услуги "Доставка состояния"

Для вызовов по расширенным адресам (extended_addresses) АС запрашивает многоблочную адресацию, генерируя запрос произвольного доступа вызова состояния с IE адреса назначения (Destination_Address), содержащим адрес шлюза (PAXBI, PSTNI и т.д.) и IE Proxy Flag, для указания количества цифр расширенных адресов (extended_addresses). Для количества набранных цифр от 1 до 20 IE Proxy Flag должен быть установлен в значение 0₂.

Для количества набранных цифр от 21 до 44 IE Proxy Flag должен быть установлен в значение 1₂. PDU, представляющие верный ответ на многоблочный запрос произвольного доступа услуги "Доставка состояния", следующие:

а) служебное сообщение подтверждения C_NACKD PDU, C_WACKD (в котором Reason соответствует Wait);

б) служебное сообщение C_AHOY PDU от PABXI, PSTNI, LINEI, DISPATI, IPI для вызывающей АС, чтобы отправить информацию extended_address;

в) служебное сообщение C_AHOY PDU от SUPLI для вызывающей АС, чтобы отправить дополнительные данные пользователя (supplementary_user) (см. 7.4.14).

Для перечисления б) TSCC должен затем вызвать процедуру передачи данных с использованием процедуры UDT путем отправки C_AHOY PDU вызывающей АС, чтобы отправить информацию extended_address. Для вызова состояния к PABX или PSTN информация extended_address должна быть представлена в формате BCD. IE Proxy Flag в C_AHOY PDU должен быть скопирован из IE Proxy Flag, содержащегося в PDU C_RAND, который принят от АС. Если TSCC не смог успешно принять данные с использованием процедуры UDT от АС, TSCC может повторить передачу служебного сообщения C_AHOY PDU либо передать C_NACKD PDU, чтобы указать на сбой вызова.

Для перечисления в TSCC должен затем вызвать процедуру передачи данных с использованием процедуры UDT путем отправки C_AHOY PDU вызывающей АС, чтобы отправить дополнительные данные. Формат дополнительных данных определен в UDT. Если TSCC не смог принять данные с использованием процедуры UDT от АС, то TSCC может повторить передачу служебного сообщения C_AHOY PDU и передать C_NACKD PDU, чтобы указать на сбой вызова, или продолжить установление вызова и отказаться от дополнительных данных.

Подтверждения, которые TSCC посылает вызывающей АС (состояние)

TSCC может отправить PDU подтверждения после запроса произвольного доступа услуги "Доставка состояния", чтобы указать ход выполнения вызова или прервать его. Если TSCC отправляет служебные сообщения с использованием PDU для указания хода выполнения вызова, он должен запустить таймер ожидания TNP_Timer (вызывающая АС должна работать с аналогичным таймером).

а) Служебные сообщения с использованием PDU прохождения могут быть следующими:

1) C_WACKD PDU: промежуточное подтверждение. Будут переданы дополнительные PDU,

2) C_QACKD PDU: вызываемая АС занята другим вызовом,

3) C_QACKD PDU: вызов в очереди, потому что ресурс используется в настоящее время;

б) PDU прерывания вызова считываются из соответствующего IE Reason в PDU C_NACKD (см. 16.3.9). В данном случае таким элементом является C_NACKD PDU;

в) PDU подтверждения C_ACKD PDU, указывающий, что транзакция была успешной.

Доставка состояния вызываемой стороне

TSCC доставляет данные о состоянии вызываемой АС путем передачи C_AHOY PDU, содержащего IE Status. Сообщение состояния могло исходить от другой АС, шлюза или TSCC. Для обеспечения услуги доставки состояния к индивидуальному ID АС с помощью C_AHOY PDU запрашивается ответ от вызываемой АС. Если ответом является C_ACKU PDU (в котором Reason соответствует MS_Accepted), то TSCC должен отправить равнозначное подтверждение C_ACKD PDU (в котором Mirrored_Reason соответствует MS_Accepted) вызывающей стороне. Если ответом является C_NACKU PDU, вызывающей стороне должен быть отправлен такой же C_NACKD PDU. Если ответа не было получено, TSCC может повторить C_AHOY PDU или отказаться от услуги и сообщить вызываемой стороне о сбое путем передачи C_NACKD PDU. Если услуга доставки состояния направляется разговорной группе, то разговорная группа не должна передавать подтверждение, при этом никакое подтверждение от TSCC не ожидается. C_AHOY PDU может быть повторен для надежности.

Для доставки состояния разговорной группе ответ от вызываемой стороны не ожидается, однако TSCC должен отправить по крайней мере один C_ACKD PDU (в котором Reason соответствует Message_Accepted) вызывающей стороне, чтобы указать, что транзакция выполнена (см. рисунок 58).

Рисунок 58 - Пример услуги "Доставка состояния"

разговорной группе

Тайм-аут вызова

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

Процедуры услуги "Доставка состояния" для АС

Процедуры услуги "Доставка состояния" для АС - общие положения

АС запрашивает услугу доставки состояния к другой индивидуальной АС или разговорной группе, используя одноблочный запрос услуги, или шлюзу, используя многоблочный запрос услуги. Для вызовов на extended_address отправка по таким адресам осуществляется с помощью процедуры UDT.

АС запрашивает услугу доставки состояния методом отправки запроса произвольного доступа C_RAND PDU, соблюдая процедуры произвольного доступа, описанные в 7.2.

IE в запросе произвольного доступа передаются на CCL стека протоколов и устанавливаются в соответствии с таблицей 50.

Таблица 50

IE C_RAND для услуги "Доставка состояния" для АС

IE	Размер, бит	Длина, бит	Имя	Значение	Комментарий
Service_Options	1	-	G/I	0₂	Адресом получателя является индивидуальный ID АС
	1	-	G/I	1₂	Адресом получателя является разговорная группа
	1	-	SUPED_SV	0₂	Передача данных supplementary_user не требуется
	1	-	SUPED_SV	1₂	Данные supplementary_user требуются для этого вызова
	5	-	Status(5)	XXXXX₂	Наиболее значимые 5 битов Status <1>
Proxy Flag	1	-	PROXY	0₂	Число расширенных цифр в формате BCD для адресации через шлюз - от 1 до 20
Proxy Flag	1	-	PROXY	1₂	Число расширенных цифр в формате BCD для адресации через шлюз - от 21 до 44
Appended_Supplementary_Data	2	-	SUPED_VAL	XX₂	Число добавочных UDT, требуемых для передачи вспомогательных данных
Appended_Supplementary_Data	2	-	Status(2)	XX₂	Наименее значимые 2 бита Status <1>
Service_Kind	4	-	IND_ST_SRV	0111₂	Услуга "Передача состояния"
Target_Address или Gateway	24	-	-	XX...X₂	Адрес получателя <2>
Source_Address	24	-	-	XX...X₂	Индивидуальный адрес запрашивающей АС
<1> STATUS находится в диапазоне от 000 0000₂ до 111 1110₂. <2> Target_Address представляет индивидуальный адрес, адрес шлюза или адрес разговорной группы, если G/I = 1₂. Примечание - Если SUPED_SV = 0₂, то SUPED_VAL = 00₂.

Услуга "Доставка состояния" к индивидуальной АС или шлюзу

Инициирование услуги "Доставка состояния" к АС или шлюзу

Для запроса услуги "Доставка состояния" к индивидуальной АС адрес назначения записывается в IE Target_Address запроса произвольного доступа C_RAND PDU. G/I установлен в значение 0₂. Service_Kind определяет услугу вызова сообщения состояния. Для вызовов на адрес шлюза Target_Address или в IE Gateway в C_RAND PDU записывается адрес шлюза.

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

Ответ на запрос произвольного доступа услуги "Доставка состояния"

Вызывающая АС должна принять следующие PDU в качестве возможного ответа на запрос произвольного доступа услуги доставки состояния:

а) служебные сообщения с использованием PDU подтверждения C_NACKD, C_QACKD, C_WACKD;

б) передаваемые данные: заголовок UDT с добавочными блоками (вызов статуса переадресовывается);

в) служебное сообщение C_AHOY PDU к вызываемой АС, содержащее данные о состоянии;

г) служебное сообщение C_AHOY PDU от AUTHI (проверка аутентификации АС);

д) служебное сообщение C_AHOY PDU, дающее команду вызывающей АС передать дополнительные данные, используя процедуру UDT;

е) для вызова на extended_address служебное сообщение C_AHOY PDU от PABXI, PSTNI, LINEI, DISPATI, IPI, дающее команду вызывающей стороне об отправке отправить своего extended_address, используя процедуру UDT.

Порядок отправки PDU по перечислениям в) и д) описан в 7.4.14.

Если АС запросила дополнительные данные, установив IE Service_Options SUPED_SV в значение 1₂ в служебном сообщении C_RAND PDU запроса вызова, а TSCC либо не поддерживает дополнительные данные, либо не может принять дополнительные данные в этот момент, то TSCC должен действовать по одному из двух вариантов:

а) продолжить установление вызова и отказаться от запроса дополнительных данных пользователя;

б) передать служебное сообщение C_NACKD PDU, чтобы указать на сбой вызова.

Подтверждения, принимаемые вызывающей АС

Когда вызывающая сторона передает служебное сообщение C_RAND PDU, она может получить начальный ответ, как это описано в 7.5.5.2 ["Подтверждения, которые TSCC отправляет вызывающей АС (состояние)"].

Затем вызывающей стороне направляются следующие служебные сообщения:

а) служебное сообщение C_NACKD PDU - в любое время для указания сбоя вызова. IE Reason должен быть установлен, чтобы указать причину сбоя вызова. Если C_NACKD PDU, отправленный вызывающей АС, является результатом C_NACK PDU от вызываемой АС, то вызывающей АС должен быть отправлен код mirrored_reason;

б) служебное сообщение C_WACKD PDU, если будет следовать дальнейшая сигнализация;

в) служебное сообщение C_ACKD PDU (Mirrored_Reason соответствует MS_Accepted) - после успешной передачи сообщения состояния.

Если принято служебное сообщение C_NACKD PDU, вызывающая АС должна отказаться от вызова сообщения состояния и вернуться в свободное состояние.

Если принято служебное сообщение C_WACKD PDU, АС должна запустить или перезапустить TNP_Timer и ожидать дальнейшей сигнализации.

TNP_Timer должен быть перезапущен при получении любого подтверждения или C_AHOY PDU.

Тайм-аут в ожидании дальнейшей сигнализации

АС, ожидающая дальнейшей сигнализации, должна отказаться от услуги сообщения состояния и вернуться в свободное состояние, если истекло время TNP_Timer.

АС вызываемой стороны, принимающая сообщение состояния

Если АС принимает служебное сообщение C_AHOY PDU с IE Target_Address, совпадающим с ее индивидуальным адресом, она должна ответить соответствующим подтверждением. IE Service_Options содержит пять наиболее значимых битов сообщения состояния. Appended_Blocks содержат два наименее значимых бита сообщения состояния.

Услуга "Доставка сообщения состояния разговорной группе"

Инициирование услуги "Доставка сообщения состояния разговорной группе"

Для запроса услуги доставки сообщения состояния разговорной группе адрес назначения полностью определяется IE Target_Address в PDU произвольного доступа C_RAND PDU, при этом G/I должен быть установлен в значение 1₂. IE Service_Kind определяет услугу доставки сообщения состояния.

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

Ответ на запрос произвольного доступа услуги "Доставка сообщения состояния разговорной группы"

Вызывающая АС должна принять следующие PDU в качестве верного ответа на запрос произвольного доступа услуги доставки состояния:

а) служебные сообщения с использованием PDU подтверждения C_NACKD, C_QACKD, C_WACKD;

б) данные - заголовок UDT с добавочными блоками (вызов опроса состояния переадресовывается);

в) служебное сообщение C_AHOY PDU к вызываемой разговорной группе, содержащее состояние;

г) служебное сообщение PDU C_AHOY от AUTHI (проверка аутентификации АС);

д) служебное сообщение PDU C_AHOY, дающее команду вызывающей АС о передаче дополнительных данных с использованием процедуры UDT.

Порядок, в котором должны быть отправлены служебные сообщения по перечислениям в), г) и д), описан в 7.4.14.

Подтверждения, принимаемые вызывающей АС

Когда вызывающая сторона передает C_RAND PDU, она может принять начальный ответ, как это описано в 7.5.5.2 ["Подтверждения, которые TSCC посылает вызывающей АС (состояние)"].

Далее вызывающей стороне могут быть отправлены следующие служебные сообщения:

а) C_WACKD PDU, если будет следовать дальнейшая сигнализация.

Если принят C_WACKD PDU, АС должна запустить или перезапустить TNP_Timer и ожидать дальнейшую сигнализацию.

TNP_Timer должен быть перезапущен при получении любого подтверждения или C_AHOY PDU.

Тайм-аут в ожидании дальнейшей сигнализации

АС, ожидающая дальнейшей сигнализации, должна отказаться от услуги доставки сообщения состояния и вернуться в свободное состояние, если TNP_Timer истекает.

Разговорная группа, принимающая сообщение доставки состояния

Если разговорная группа принимает сообщение C_AHOY PDU с IE Target_Address, совпадающим с ее адресом, она должна сохранить значение состояния, но не должна передавать подтверждение.

7.5.5.3 Процедура услуги "Опрос состояния"

Общие положения

Процедура услуги "Опрос состояния" содержит механизм передачи данных с промежуточным накоплением. АС или шлюз могут запрашивать сообщение состояния у индивидуальной АС.

Услуга "Опрос состояния" отличается от услуги "Доставка состояния" вызывающей стороной, инициирующей услугу состояния с IE Status, установленным в значение 111 1111₂ (см. 16.3.32).

На рисунке 59 приведен пример передачи опроса состояния от АС к АС.

Рисунок 59 - Пример выполнения услуги "Опрос состояния"

В ходе выполнения услуги передаются:

а) "А" - служебное сообщение с использованием PDU произвольного доступа C_RAND PDU. Опрашиваемой стороной является АС(Б) с IE Service_Kind, установленным в значение Status, равное 111 1111₂;

б) "Б" - служебное сообщение C_AHOY PDU от АС(А), которая запрашивает значение опрашиваемого состояния у АС(Б). Значение Status равно 111 1111₂ и соответствует указанному в "А";

в) "C" - подтверждение от АС(Б). Подтверждение содержит значение опрашиваемого состояния в IE Response_Info;

г) "Г" - окончательное подтверждение вызывающей стороне АС(А). Подтверждение содержит значение опрашиваемого состояния в IE Response_Info. Следует отметить, что подтверждение повторяется для надежности.

Процедуры услуги "Опрос состояния" для TSCC

Процедуры услуги "Опрос состояния" для TSCC - общие положения

АС инициирует услугу "Опрос состояния" посредством передачи запроса произвольного доступа с указанием индивидуального адреса опрашиваемой АС. Шлюз инициирует опрос служебным сообщением AHOY PDU, адресованным опрашиваемой АС.

Ответ TSCC на услугу "Опрос состояния" от АС

Когда TSCC отвечает на запрос произвольного доступа, он запускает таймер (TNP_Timer). Этот таймер должен быть обновлен, если TSCC отправляет дальше сообщения прохождения вызова к вызывающей стороне.

При получении запроса услуги произвольного доступа TSCC должен передать:

а) служебные сообщения с использованием PDU подтверждения C_NACKD, C_WACKD (Reason соответствует Wait), C_QACKD, адресованные вызывающей АС;

б) служебное сообщение PDU C_AHOY адресованное опрашиваемой АС для этого вызова, чтобы передать состояние вызывающей АС;

в) служебное сообщение PDU C_AHOY от AUTHI (проверка аутентификации АС);

г) данные - заголовок UDT с добавочными блоками (услуга сообщения состояния переадресовывается). Если ТС ранее приняла переадресацию вызова, указывающую на то, что этот запрос услуги будет направлен другой вызываемой стороне, то TSCC должен вызвать процедуру передачи данных с использованием процедуры UDT и отправить заголовок UDT с добавочными данными вызывающей стороне.

Подтверждения, которые TSCC отправляет вызывающей АС

TSCC может отправить служебные сообщения с использованием PDU подтверждения после запроса произвольного доступа на предоставление услуги "Опрос состояния", чтобы указать ход выполнения вызова или прервать его. Если TSCC отправляет PDU для указания хода вызова, он должен запустить таймер ожидания TNP_Timer (АС вызывающей стороны запускает аналогичный таймер).

При этом:

а) служебные сообщения с использованием PDU хода выполнения вызова могут быть следующими:

1) C_WACKD: промежуточное подтверждение. Будут переданы дополнительные PDU,

2) C_QACKD: вызываемая АС занята другим вызовом,

3) C_QACKD: вызов поставлен в очередь, поскольку ресурс используется в настоящий момент;

б) PDU прерывания выбираются из соответствующих значений IE Reason в C_NACKD PDU (см. 16.3.9).

Доставка опрошенного состояния вызывающей стороне

TSCC опрашивает состояние АС путем передачи служебного сообщения C_AHOY PDU, содержащего IE Status, установленный в значение 111 1111₂. C_AHOY PDU может передаваться в результате запроса произвольного доступа на предоставление услуги "Опрос состояния" от вызывающей АС, шлюза или TSCC. Для получения услуги опроса состояния, адресованной конкретной АС, в C_AHOY PDU содержится запрос ответа от опрашиваемой АС.

Если опрос состояния пришел от АС, то:

а) если ответом опрашиваемой АС являются служебные сообщения C_ACKU PDU или C_NACKU PDU, то TSCC должен отправить равнозначное подтверждение вызывающей АС (Mirrored_Reason). Если ответ не получен, TSCC может повторить передачу служебного сообщения C_AHOY PDU или отказаться от услуги и указать вызывающей АС на сбой путем передачи C_NACKD PDU;

б) если ответом опрашиваемой АС является C_ACKU PDU (в котором Reason соответствует Accepted для услуги "Опрос состояния"), IE Response_Info содержит информацию об опрашиваемом состоянии. TSCC должен отразить (передать обратно без изменений) Response_Info в C_ACKD PDU (в котором IE Mirrored_Reason соответствует Accepted для услуги "Опрос состояния"). Этот отраженный ответ TSCC может быть для надежности повторен.

Тайм-аут вызова

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

Процедуры услуги "Опрос состояния" для АС

Процедуры услуги "Опрос состояния" для АС - общие положения

АС запрашивает услугу вызова сообщения опроса состояния к индивидуальной АС, используя одноблочный запрос услуги.

АС запрашивает услугу "Опрос состояния" путем отправки запроса произвольного доступа C_RAND PDU, соблюдая процедуры произвольного доступа, описанные в 7.2. IE в запросе произвольного доступа передаются на CCL и устанавливаются в соответствии с таблицей 51.

Таблица 51

IE C_RAND PDU для услуги "Опрос состояния"

IE	Размер, бит	Длина, бит	Имя	Значение	Комментарий
Service_Options	1	-	G/I	0₂	Адресом получателя является индивидуальный ID АС
	1	-	Supplementary_user Data	0₂	Не требуется передача данных supplementary_user
	1	-	Supplementary_user Data	1₂	Данные supplementary_user требуются для этого вызова
	5	-	Status(5)	1 1111₂	Наиболее значимые 5 битов Status <1>
Proxy Flag	1	-	PROXY	0₂	Число расширенных цифр в формате BCD для адресации через шлюз составляет от 1 до 20
Proxy Flag	1	-	PROXY	1₂	Число расширенных цифр в формате BCD для адресации через шлюз составляет от 21 до 44
Appended_Supplementary_Data	2	-	SUPED_VAL	XX₂	Число добавочных UDT, требуемых для передачи дополнительных данных
Appended_Supplementary_Data	2	-	Status(2)	11₂	Наименее значимые 2 бита Status <1>
Service_Kind	4	-	IND_ST_SRV	0111₂	Услуга "Передача состояния"
Target_Address или Gateway	24	-	-	XX...X₂	Адрес получателя <2>
Source_Address	24	-	-	XX...X₂	Индивидуальный адрес запрашивающей АС
<1> STATUS = 111 1111₂ указывает на услугу "Опрос состояния". <2> Target_Address представляет "Индивидуальный адрес". Примечание - Если SUPED_SV = 0₂, то SUPED_VAL = 00₂.

Услуга "Опрос состояния", адресованная индивидуальной АС

Инициирование услуги "Опрос состояния", адресованной АС или шлюзу

Для запроса услуги опроса состояния у индивидуальной АС адрес назначения передается в IE Target_Address в служебном сообщении произвольного доступа C_RAND PDU. Service_Kind определяет услугу вызова "Опрос состояния".

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

Ответ на запрос произвольного доступа услуги "Опрос состояния"

Вызывающая АС должна принять следующие служебные сообщения как ответ на запрос произвольного доступа услуги "Опрос состояния":

а) PDU подтверждения C_NACKD, C_QACKD, C_WACKD;

б) данные - заголовок UDT с добавочными блоками (вызов коротких данных UDT переадресовывается);

в) C_AHOY PDU к вызываемой АС, содержащий значение состояния, равное 111 1111₂;

г) C_AHOY PDU от AUTHI (проверка аутентификации АС);

д) C_AHOY PDU, дающий команду вызывающей АС передать дополнительные данные, используя процедуру UDT.

Примечание - Служебные сообщения по перечислениям г) и д) могут быть выполнены в любом порядке.

Подтверждения, принимаемые вызывающей АС

Когда вызывающая сторона передает C_RAND PDU, она может получить начальный ответ, как это описано в 7.5.5.3 ("Подтверждения, которые TSCC отправляет вызывающей АС").

В любое время после этого вызывающей стороне могут быть отправлены следующие служебные сообщения:

а) C_NACKD PDU - в любое время для указания сбоя вызова. IE Reason должен быть установлен в значение, указывающее на причину сбоя вызова. Если C_NACKD PDU, отправленный вызывающей АС, является результатом C_NACK PDU от вызываемой АС, то вызывающей АС должно быть отправлено сообщение mirrored_reason;

б) C_WACKD PDU, если ожидается поступление дальнейшей сигнализации;

в) C_ACKD PDU (mirrored_reason) - после успешной передачи сообщения состояния.

Если принят C_NACKD PDU, то вызывающая АС должна отказаться от вызова сообщения состояния и вернуться в свободное состояние.

Если принят C_WACKD PDU, то АС должна запустить или перезапустить TNP_Timer и ожидать дальнейшей сигнализации.

TNP_Timer должен быть перезапущен при получении любого подтверждения или C_AHOY PDU.

Тайм-аут в ожидании дальнейшей сигнализации

АС, ожидающая дальнейшей сигнализации, должна отказаться от услуги сообщения состояния и вернуться в свободное состояние, если время таймера TNP_Timer истекает.

АС, принимающая сообщение состояния

Если АС принимает сообщение C_AHOY PDU с IE Target_Address, совпадающим с ее индивидуальным адресом, она должна ответить соответствующим подтверждением. IE Response_Info содержит информацию об опрашиваемом состоянии.

7.5.5.4 Определенные значения IE Status для услуги "Вызов состояния"

Аварийная сигнализация

Услуга "Вызов состояния" используется, чтобы указать условие аварийной сигнализации (IE Status установлен в значение 111 1110₂) от АС к другой АС, разговорной группе или диспетчеру без инициирования экстренного речевого вызова.

7.5.6 Переадресация вызова

7.5.6.1 Услуга "Переадресация вызова"

Введение

Инициатором услуги переадресации вызова может выступать АС, которая может запросить, чтобы все будущие услуги были перенаправлены другому получателю. Запросы применимы к следующим услугам:

а) услуге речевого вызова;

б) услуге передачи пакетных данных;

в) услуге доставки сообщения коротких данных UDT;

г) услуге доставки сообщения состояния.

Соответствующие услуги могут быть перенаправлены к другой АС, разговорной группе или на расширенные адреса (extended_address) через шлюз.

Услуга "Переадресация вызова" использует многоблочное установление вызова, где измененный адрес отправляется абонентом с использованием процедуры UDT. Необходимость переадресации указывается в IE DIVONOFF запроса услуги переадресации вызова, в котором значение "Set Call Diversion" = 1₂. На рисунке 60 показан пример выполнения услуги "Переадресация вызова".

Рисунок 60 - Пример выполнения услуги "Переадресация вызова"

Переадресация вызова включает следующие этапы:

а) АС(А) определяет количество добавочных данных UDT, необходимых для транспортировки измененных адресов по TSCC. В данном примере требуется один добавочный UDT;

б) "А" - служебное сообщение с использованием PDU произвольного доступа C_RAND PDU. IE Service_Kind установлен в значение "Call Diversion Service", а Appended Short Data PDU указывает количество добавочных блоков данных UDT для транспортировки измененных адресов;

в) "Б" - служебное сообщение C_AHOY PDU от DIVERTI, которое запрашивает у АС(Б) передачу измененного адреса с использованием процедуры UDT;

г) "В" - восходящая фаза, состоящая из многоблочного заголовка UDT с добавочными данными, передающими измененный адрес в TSCC;

д) "Г" - подтверждение от TSCC.

Для вызовов, переадресованных АС, переадресация вызова может быть отменена либо АС, ее инициировавшей, либо АС, являющейся получателем переадресованного вызова. В этом случае запрос одноблочного установления вызова делается с помощью IE DIVONOFF Service_Options в запросе услуги "Переадресация вызова", установленного в значение "Clear Diversion":

а) если АС, инициировавшая переадресацию вызова, желает отменить переадресацию, то в запросе услуги вызова Target_Address должен быть установлен в значение TSI;

б) если получатель переадресованного вызова желает отменить все переадресации вызова, для которых АС является получателем, то в запросе услуги вызова Target_Address должен быть установлен в значение DIVERTI.

Для вызовов, переадресованных разговорной группе, только АС, являющаяся инициатором переадресации вызова, должна иметь право отменить переадресацию.

Процедуры TSCC для услуги "Переадресация вызова"

Процедуры TSCC для услуги "Переадресация вызова" - общие положения

АС инициирует услугу "Установка переадресации вызова" запросом произвольного доступа, адресуемым идентификатору шлюза, соответствующему измененному назначению (адресу АС, разговорной группы, PSTN, PABX или IP). Услуга "Установка переадресации вызова" использует многоблочное установление вызова. При ответе на запрос произвольного доступа TSCC должен запустить таймер (TNP_Timer). Этот таймер должен быть перезапущен, если TSCC отправляет вызывающей стороне дополнительные PDU прохождения вызова.

АС инициирует услугу "Сброс переадресации вызова" запросом произвольного доступа, адресуемым идентификатору шлюза TSI или DIVERTI [см. 7.5.6.1 ("Процедуры АС для услуги "Переадресация вызова")]. Услуга "Сброс переадресации вызова" использует одноблочное установление вызова. Когда TSCC отвечает на запрос произвольного доступа, он должен запустить таймер (TNP_Timer). Этот таймер должен быть перезапущен, если TSCC отправляет вызывающей стороне дополнительные PDU прохождения вызова.

АС инициирует услугу "Сброс переадресации входящего вызова" запросом произвольного доступа, адресуемым идентификатору шлюза DIVERTI. Услуга "Сброс переадресации входящего вызова" также использует одноблочное установление вызова.

Ответ TSCC на многоблочное установление вызова услуги "Установка переадресации вызова"

Для услуги "Установка переадресации вызова" АС генерирует запрос произвольного доступа на услугу переадресации с IE C_RAND PDU, указанными в таблице 54, и IE DIVONOFF, в котором "Set Call Diversion" установлен в значение 1₂.

PDU, которые должны быть отправлены в ответ на многоблочный запрос произвольного доступа услуги "Установка переадресации вызова", следующие:

а) PDU подтверждения C_NACKD, C_WACKD (в котором IE Reason соответствует Wait). При этом IE Source_Address (адрес источника) должен быть установлен в значение Target_Address (адрес назначения) из C_RAND PDU, а IE Target_Address (адрес назначения) должен быть установлен в значение Source_Address (адрес источника) из C_RAND PDU;

б) C_AHOY PDU от DIVERTI для вызывающей АС, чтобы послать измененный адрес, используя процедуру UDT;

в) C_AHOY PDU, в котором IE Source_Address соответствует значению запроса аутентификации (проверка аутентификации АС).

Для перечисления б) TSCC должен вызвать процедуру UDT путем отправки C_AHOY PDU вызывающей АС, чтобы передать измененный адрес. Для переадресации вызова в PABX или PSTN информация измененного адреса должна быть записана в формате BCD. IE Proxy Flag в C_AHOY PDU должен быть идентичен IE Proxy Flag из PDU C_RAND, который получен от АС. Если TSCC неудачно принимает данные с использованием процедуры UDT от АС, то он может повторить передачу служебного сообщения C_AHOY PDU либо передать служебное сообщение C_NACKD PDU, чтобы указать на сбой вызова.

Элементы целевой информации заголовка UDT для услуги "Установка переадресации вызова" представлены в таблице 52.

Добавочные блоки содержат измененный адрес.

Таблица 52

Элементы целевой информации заголовка UDT для услуги

"Установка переадресации вызова"

Действие	Адрес шлюза	Комментарий
Отправить адрес индивидуальной АС	MSI	Вызывающий абонент должен отправить АС измененный индивидуальный адрес
Отправить адрес разговорной группы	GPI	Вызывающий абонент должен отправить АС измененный адрес разговорной группы
Отправить цифры PSTN	PSTNI	Вызывающий абонент должен отправить набранные цифры BCD
Отправить цифры PABX	PABXI	Вызывающий абонент должен отправить набранные цифры BCD
Отправить цифры LINE	LINEI	Вызывающий абонент должен отправить набранные цифры BCD
Отправить цифры диспетчера	DISPATI	Вызывающий абонент должен отправить набранные цифры BCD
Отправить адрес IP	IPI	Вызывающий абонент должен отправить адрес IPV4 или IPV6

Окончательное подтверждение к АС

В восходящей фазе АС отправляет в TSCC измененный адрес.

TSCC должен отправить соответствующее окончательное подтверждение служебным сообщением C_RAND PDU с IE Source_Address, установленным в значение Target_Address, от инициирующей переадресацию вызова АС к вызывающей стороне, чтобы указать результат переадресации вызова.

Подтверждения на услугу "Установка переадресации вызова" представлены в таблице 53.

Таблица 53

Подтверждения на услугу "Установка переадресации вызова"

Подтверждение	Код Reason	Примечание
C_ACK	0110 0000₂	Переадресация вызова, принятая ТС
C_NACK	0010 0000₂	Подтверждение на начальный запрос переадресации вызова, если система не поддерживает переадресацию вызова <1>
C_NACK	0010 0011₂	Вызов не может быть переадресован в это место назначения <1>
<1> Если переадресация вызова не поддерживается системой, TSCC отправляет код Reason C_NACK = 0010 0000₂ к исходному инициатору запроса услуги произвольного доступа. Если система не может установить переадресацию в место назначения, указанное АС в фазе загрузки измененного адреса, то TSCC отправляет код Reason C_NACK = 0010 0011₂ в качестве окончательного подтверждения.

Ответ TSCC на одноблочное установление услуги "Сброс переадресации вызова"

Для услуги "Сброс переадресации вызова" АС генерирует запрос произвольного доступа услуги переадресации с IE C_RAND PDU, указанными в таблице 54, и IE DIVONOFF, установленным в значение "Clear Call Diversion", равное 0₂.

PDU, представляющие ответ на многоблочный запрос произвольного доступа сброса услуги переадресации вызова, могут быть следующими:

а) C_NACKD PDU, указывающий, что запрос услуги не состоялся;

б) C_WACKD PDU (в котором Reason соответствует Wait), указывающий на то, что будет передана дальнейшая сигнализация;

в) C_ACKD PDU, указывающее, что запрос услуги состоялся;

г) C_AHOY PDU от AUTHI (проверка аутентификации АС).

Примечание - Ответ C_WACKD PDU позволяет услуге переадресации вызова продолжиться после того, как вызов был поставлен в очередь.

Процедуры АС для услуги "Переадресация вызова"

Процедуры АС для услуги "Переадресация вызова" - введение

АС запрашивает услугу переадресации вызова, используя запрос услуги произвольного доступа.

Если АС переадресовывает свой вызов, то IE DIVONOFF в Service_Options устанавливается в значение "Set Diversion", равное 1₂. Вызывается многоблочный запрос услуги. IE в запросе произвольного доступа передаются на CCL стека протоколов и устанавливаются в соответствии с таблицей 54.

Таблица 54

IE C_RAND PDU для услуги "Переадресация вызова"

IE	Размер, бит	Длина, бит	Имя	Значение	Комментарий
Service_Options	7	1	EMERG	Не применяется - 0₂
		1	R	0₂	Конфиденциальность (R)
		1	DIVONOFF	0₂	Сброс переадресации вызова
		1	DIVONOFF	1₂	Установка переадресации вызова
		1	DIV_VD	Активный 1₂; неактивный 0₂	Переадресовать речевые вызовы
		1	DIV_PD	Активный 1₂; неактивный 0₂	Переадресовать вызовы пакетных данных
		1	DIV_SD	-	Переадресовать вызовы коротких данных
		1	DIV_S	-	Переадресовать вызовы состояния
Proxy Flag	1	-	PROXY	0₂	Число расширенных цифр в формате BCD для адресации через шлюз - от 1 до 20 или IPV4
Proxy Flag	1	-	PROXY	1₂	Число расширенных цифр в формате BCD для адресации через шлюз - от 21 до 44 или IPV6
R	2	-	-	00₂	-
Appended_Short_Data	2	-	SDATA_VAL	00₂	Число добавочных блоков UDT для передачи измененного адреса
Service_Kind	4	-	DIV_SRV	1000₂	Услуга "Переадресация вызова"
Source_Address	24	-	-	XX...X₂	Индивидуальный адрес запрашивающей АС
Target_Address или Gateway	24	-	-	XX...X₂	Идентификатор шлюза (для переадресации вызова - MSI, GPI, PSTNI, PABXI или IPI, для сброса переадресации вызова - TSI, для сброса переадресации входящего вызова - DIVERTI)

Если АС отменяет ранее установленную переадресацию, то она отправляет такой же запрос произвольного доступа, который использовался при установлении переадресации вызова, но с IE Target_Address, соответствующим TSI, и DIVONOFF, установленным в значение 0. Если АС хочет отменить входящую переадресацию, то запрос произвольного доступа отправляется с Target_Address, соответствующим DIVERTI и DIVONOFF, установленным в значение 0.

Если DIVONOFF установлен в значение 1₂, то DIV_VD, DIV_PD, DIV_SD и DIV_S, для которых установлено значение Active, равное 1₂, определяют, какие услуги должны быть переадресованы для этого запроса услуги переадресации вызова.

Если DIVONOFF установлен в значение 0₂, то DIV_VD, DIV_PD, DIV_SD и DIV_S, для которых установлено значение Active, равное 1₂, определяют, для каких услуг переадресация вызова должна быть отменена.

IE для услуги "Переадресация вызова" перечислены в таблице 55.

Таблица 55

IE для услуги "Переадресация вызова"

Измененный адрес	Адрес получателя или шлюз	Proxy Flag
Адрес индивидуальной АС	MSI	0₂
Адрес разговорной группы	GPI	0₂
Адрес PSTN (от 1 до 20 набранных цифр)	PSTNI	0₂
Адрес PSTN (от 21 до 44 набранных цифр)	PSTNI	1₂
Адрес PABX (от 1 до 20 набранных цифр)	PABXI	0₂
Адрес PABX (от 21 до 44 набранных цифр)	PABXI	1₂
Адрес IPv4	IPI	0₂
Адрес IPv6	IPI	1₂

АС отправляет адрес переадресации

После того как АС совершит запрос услуги переадресации вызова, TSCC отправляет C_AHOY PDU, на который АС должна ответить передачей данных с заголовком UDT и добавочными блоками, используя процедуру UDT. Заголовок передаваемых данных UDT должен содержать тип адреса назначения (АС, PSTN и т.д.), добавочные блоки должны содержать измененный адрес (адрес переадресации).

IE для заголовка восходящей передачи данных UDT представлены в таблице 56.

Таблица 56

Назначения IE для заголовка восходящей передачи данных UDT

(услуга "Переадресация вызова")

Измененный адрес	IE заголовка восходящего канала UDT
Измененный адрес	Формат UDT	Добавочные блоки	Адрес назначения или шлюза	Адрес источника или шлюза
Индивидуальная АС	Адрес - 0001₂	00₂	MSI	Адрес АС
Разговорная группа	Адрес - 0001₂	00₂	GPI	Адрес АС
Назначение PSTN	BCD - 0010₂	Цифры от 1 до 20 - 00₂ цифры от 21 до 44 - 01₂	PSTNI	Адрес АС
Назначение PABX	BCD - 0010₂	Цифры от 1 до 20 - 00₂ цифры от 21 до 44 - 01₂	PABXI	Адрес АС
Назначение LINE	BCD - 0010₂	Цифры от 1 до 20 - 00₂ цифры от 21 до 44 - 01₂	LINEI	Адрес АС
Назначение диспетчера	BCD - 0010₂	Цифры от 1 до 20 - 00₂ цифры от 21 до 44 - 01₂	DISPATI	Адрес АС
Назначение IP	IP - 0110₂	IPV4 - 00₂ IPV6 - 01₂	IPI	Адрес АС
Примечание - Supplementary_Flag = 0₂, A = 0₂, Service_Kind = 1000₂, UDT_DIV = 1₂.

Получатель переадресованных вызовов отменяет все входящие переадресации

Если получатель переадресованных вызовов отменяет все входящие переадресации, то он должен сгенерировать запрос произвольного доступа услуги с IE C_RAND PDU, представленными в таблице 57.

Таблица 57

IE C_RAND для отмены входящей переадресации

IE	Размер, бит	Длина, бит	Имя	Значение	Комментарий
Service_Options	7	1	EMERG	Не применяется - 0₂
		1	R	0₂	Конфиденциальность (R)
		1	DIVONOFF	0₂	Сброс переадресации вызова
		1	DIV_VD	Активный 1₂; неактивный 0₂	Сброс переадресации речевых вызовов
		1	DIV_PD		Сброс переадресации вызовов с пакетными данными
		1	DIV_SD		Сброс переадресации вызовов коротких данных
		1	DIV_S		Сброс переадресации вызовов состояния
Proxy Flag	1	-	PROXY	0₂	Не определен для отмены входящей переадресации
Appended_Supplementary_Data	2	-	SUPED_VAL	00₂	Не определен для услуги "Переадресация вызова"
Appended_Short_Data	2	-	SDATA_VAL	00₂	Не определен для услуги "Переадресация вызова"
Service_Kind	4	-	DIV_SRV	1000₂	Услуга "Переадресация вызова"
Target_Address или Gateway	24	-	-	XX...X₂	DIVERTI
Source_Address	24	-	-	XX...X₂	Адрес запрашивающей АС

Ответ TSCC на запрос отмены входящей переадресации

Для отмены переадресации входящего вызова ответ должен содержать следующие служебные сообщения:

а) C_NACKD PDU, указывающий на то, что запрос услуги не выполнен;

б) C_WACKD PDU (Reason соответствует Wait), указывающий на то, что будет передана дальнейшая сигнализация;

в) C_ACKD PDU [в котором значение Sourse (источник) соответствует DIVERTI, а Destination (назначение) соответствует ID АС], указывающее, что запрос услуги состоялся;

г) C_AHOY PDU от AUTHI (проверка аутентификации АС).

7.5.6.2 Переадресованные вызовы

АС выполняет запрос услуги с произвольным доступом. Если выбранный адрес назначения является адресом индивидуальной АС и система решает, что вызовы к этому адресу переадресованы, то TSCC должен подтвердить запрос произвольного доступа с заголовком передаваемых данных UDT и добавочным блоком с измененным адресом.

Рисунок 61 - Доставка TSCC измененного адреса к АС

Заголовок передаваемых данных UDT устанавливает следующие IE:

а) Supplementary_Flag установлен в значение 1₂;

б) UDT Response - в значение 0₂;

в) Target_Address или Gateway - соответствуют адресу вызывающей АС.

IE ADDRESS1, передаваемый в добавленном блоке UDT, должен содержать измененный адрес.

В таблице 58 представлены IE заголовка UDT для передачи измененного адреса.

Таблица 58

IE заголовка UDT для передачи измененного адреса

Запрос услуги	Куда переадресован	IE заголовка UDT
Запрос услуги	Куда переадресован	Формат UDT	Добавочные блоки	Service_Kind	Адрес источника
Конфиденциальная речь (R)	Адрес АС	Адрес - 0001₂	00₂	0000₂	MSI
	Разговорная группа	Адрес - 0001₂	00₂		GPI
	PSTN	BCD - 0010₂	Цифры от 1 до 20 - 00₂ цифры от 21 до 44 - 01₂		PSTNI
	PABX	BCD - 0010₂	Цифры от 1 до 20 - 00₂ цифры от 21 до 44 - 01₂		PABXI
Конфиденциальные пакетные данные (R)	Адрес АС	Адрес - 0001₂	00₂	0010₂	MSI
	Разговорная группа	Адрес - 0001₂	00₂		GPI
	PSTN	BCD - 0010₂	Цифры от 1 до 20 - 00₂ цифры от 21 до 44 - 01₂		PSTNI
	PABX	BCD - 0010₂	Цифры от 1 до 20 - 00₂ цифры от 21 до 44 - 01₂		PABXI
	IP	IP - 0110₂	IPV4 - 00₂ IPV6 - 01₂		IPI
Короткие данные	Адрес АС	Адрес - 0001₂	00₂	0100₂	MSI
	Разговорная группа	Адрес - 0001₂	00₂		GPI
	PSTN	BCD - 0010₂	Цифры от 1 до 20 - 00₂ цифры от 21 до 44 - 01₂		PSTNI
	PABX	BCD - 0010₂	Цифры от 1 до 20 - 00₂ цифры от 21 до 44 - 01₂		PABXI
	IP	IP - 0110₂	IPV4 - 00₂ IPV6 - 01₂		IPI
Состояние	Адрес АС	Адрес - 0001₂	00₂	0111₂	MSI
	PSTN	BCD - 0010₂	Цифры от 1 до 20 - 00₂ цифры от 21 до 44 - 01₂		PSTNI
	PABX	BCD - 0010₂	Цифры от 1 до 20 - 00₂ цифры от 21 до 44 - 01₂		PABXI
	IP	IP - 0110₂	IPV4 - 00₂ IPV6 - 01₂		IPI

7.5.7 Услуга DGNA

7.5.7.1 Общие положения

Транкинговая система может предоставлять услугу создания и удаления динамических групп.

АС должна быть способна хранить один или более идентификаторов разговорной группы, которые могут быть предварительно запрограммированы или динамически добавлены/удалены с использованием процедуры UDT. В данном пункте описаны процедуры добавления или удаления ранее добавленных адресов разговорной группы АС. АС могут быть назначены до 16 адресов динамически создаваемых групп:

а) режим DGNA_Address дает возможность динамически назначить до 15 адресов разговорных групп;

б) режим DGNA_Alias позволяет динамически присваивать АС один адрес разговорной группы и связанный с ним позывной пользователя в текстовом формате длиной до 21 символа. Режим DGNA_Alias также позволяет передавать текстовую строку и связывать ее с одним из 15 адресов разговорной группы, назначенных с использованием режима DGNA_address.

Услуга DGNA должна быть направлена только к индивидуальной АС. Процедура может быть инициирована от АС или шлюза. На рисунке 62 показан пример выполнения процедуры.

Услуга DGNA, инициируемая от АС к АС, использует процедуру передачи с использованием UDT.

В Б.3.3 описана структура добавленных блоков данных для транспортировки адресов из 24 бит при передаче адресов разговорных групп с использованием режима DGNA_Address. Для выполнения услуги DGNA в восходящем направлении (в фазе загрузки) UDT должен содержать список динамически назначенных адресов разговорной группы от ADDRESS1 до ADDRESSx (или ADRNULL). В нисходящем направлении (в фазе скачивания) UDT значения от ADDRESS1 до ADDRESSx должны быть скопированы из переданных в восходящем направлении. Получатель передаваемых адресов в режиме DGNA_Address должен удалить все 15 предыдущих адресов DGNA и заменить их адресами, полученными в результате новой передачи DGNA.

Формат добавочных блоков UDT, использующийся при передаче адресов разговорной группы и текстового значения в режиме DGNA_Alias, приведен в Б.3.10.

АС может быть способна работать в режиме вызова одной разговорной группы одной клавишей (One-key_talkgroup). One-key_talkgroup отличается от других разговорных групп тем, что вызов такой разговорной группы может быть выполнен сочетанием клавиш или нажатием PTT.

Услуга DGNA использует многоблочное установление вызова. Если услуга DGNA инициируется от шлюза TSCC, то допускается только нисходящая фаза с передачей данных UDT.

На рисунке 62 показан пример передачи DGNA UDT от АС к АС. В этом примере передаваемые данные с использованием процедуры UDT вызывающей АС содержат два добавочных блока, следовательно, динамически назначаются до семи разговорных групп.

	Aloha		Ahoy		Заголовок для добавленных данных		Aloha M = 24 Address = NULL
	RQ произвольного доступа		Ответ Ack		Добавленные данные		Получатель сообщения

Рисунок 62 - Пример передачи данных при DGNA

Пример передачи данных при организации динамических групп с помощью услуги DGNA включает следующие этапы и подпункты:

а) АС(А) вычисляет количество блоков добавочных данных UDT, необходимых для передачи адресов DGNA. В данном примере выбраны два блока добавочных данных UDT;

б) "А" - служебное сообщение произвольного доступа C_RAND PDU. Вызываемая сторона - DGNAI, в Service_Kind установлена "Supplementary Data" и в SUPED_VAL указано количество блоков данных, необходимых для передачи данных DGNA. В этом примере SUPED_VAL соответствует 01₂;

в) "Б" - C_AHOY PDU от DGNAI, запрашивающий АС(А) передать адреса разговорной группы, используя процедуру UDT;

г) "В" - фаза загрузки данных, состоящая из многоблочного заголовка UDT и добавочных данных. Адресом получателя этих пакетных данных UDT является АС(Б);

д) "Г" - фаза скачивания данных, состоящая из многоблочного заголовка UDT и добавочных адресов разговорной группы. Адресом источника этих пакетных данных UDT является АС(А). Адресом получателя этих пакетных данных UDT является АС(Б);

е) "Д" - подтверждение от АС(Б);

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

Синхронизация для фаз загрузки и скачивания не предусмотрена.

7.5.7.2 Правила назначения адресов динамической группы

Общие положения

Вызывающая сторона выбирает конкретный режим DGNA (DGNA_Address или DGNA_Alias), устанавливая IE соответствующим образом в заголовке служебного сообщения с использованием PDU во время восходящей фазы вызова (фазы загрузки), как показано в таблице 59.

Таблица 59

IE заголовка UDT восходящей фазы вызова

IE заголовка UDT	Режим DGNA_Address	Режим DGNA_Alias
UDT_Format (формат UDT)	0001₂	1010₂
Target_Address (адрес получателя)	ID АС - получатель DGNA
Source_Address (адрес источника)	Вызывающая сторона
PN	0₂	См. таблицу Б.9
R	0₂
UAB (добавочные блоки)	См. таблицу 60	См. таблицу 61
SF (вспомогательный флаг)	0₂
PF (флаг защиты)	0₂
Opcode (операционный код)	10 0101₂

Режим DGNA_Address

Механизм передачи данных с использованием процедуры UDT позволяет передать до пятнадцати адресов DGNA длиной 24 бита в четырех блоках UDT. Если предполагается передача менее четырех блоков UDT, то доступны не все элементы в динамической разговорной группе. Таблица 60 показывает взаимосвязь между количеством добавочных блоков и списком адресов разговорной группы.

Таблица 60

Сохранение в АС адресов назначенных разговорных групп

в режиме DGNA_Address

Четыре добавочных блока данных

Три добавочных блока данных

Два добавочных блока данных

Один добавочный блок данных

Добавочные данные

UAD1 = 11₂

UAD1 = 10₂

UAD1 = 01₂

UAD1 = 00₂

ADDRESS1 <1>

ADDRESS2

ADDRESS3

ADDRESS4

ADDRESS5

ADDRESS6

ADDRESS7

ADDRESS8

ADDRESS9

ADDRESS10

ADDRESS11

ADDRESS12

ADDRESS13

ADDRESS14

ADDRESS15

ИС NORMPROD: примечание.

<1> Если OK = 1₂, то ADDRESS1 представляет One-key_talkgroup.

Примечание - Утолщенная линия обозначает недоступность адресов при получении неполного количества блоков добавочных данных.

Если адресов разговорной группы недостаточно для того, чтобы полностью заполнить добавочный блок, то неиспользованные адреса должны быть установлены в значение ADRNULL. ADDRESS1 может быть назначен как One-key_talkgroup путем установки флага OK в значение 1₂ в первом добавочном блоке. Если АС успешно принимает передачу DGNA, то существующий список разговорных групп от ADDRESS1 до ADDRESS15, поддерживаемый АС, должен быть удален и заменен новыми разговорными группами DGNA.

Все динамические разговорные группы могут быть удалены передачей данных с использованием процедуры UDT со следующими настройками: UAD1 установлен в значение 00₂, OK установлен в значение 0₂, ADDRESS1 соответствует ADRNULL, ADDRESS2 соответствует ADRNULL, ADDRESS3 соответствует ADRNULL.

Режим DGNA_Alias

Процедура передачи данных UDT позволяет передать один адрес динамической разговорной группы (24 бита) и связанное с этой группой имя текстовой строки, содержащей до 21 юникод-символа в четырех UDT блоках. Если требуется передать меньше, чем 21 символ, то они будут переданы в меньшем количестве блоков UDT. В таблице 61 показана взаимосвязь между добавочными блоками, адресами разговорных групп и именами строк. Режим DGNA_Alias также позволяет передать текстовую строку, связанную с одним из пятнадцати адресов, ранее переданных в режиме DGNA_Address. В этом случае ADDRESS содержит адрес, ранее переданный в текстовой строке, который находится в ALIASx. Если это One-key_talkgroup, то IE OK в первом добавочном UDT установлен в значение 1₂.

Таблица 61

Сохранение АС адресов назначений разговорных групп и имен

в режиме DGNA_Alias

Четыре добавочных блока данных	Три добавочных блока данных	Два добавочных блока данных	Один добавочный блок данных	Добавочные данные
OK = 0₂, если ADDRESS не является One-key_talkgroup. OK = 1₂, если ADDRESS является One-key_talkgroup				OK
UAD1 = 11₂	UAD1 = 10₂	UAD1 = 01₂	UAD1 = 00₂	ADDRESS
				ALIAS1
				ALIAS2
				ALIAS3
			&	ALIAS4
				ALIAS5
				ALIAS6
				ALIAS7
				ALIAS8
				ALIAS9
		&		ALIAS10
				ALIAS11
				ALIAS12
				ALIAS13
				ALIAS14
				ALIAS15
	&			ALIAS16
				ALIAS17
				ALIAS18
				ALIAS19
				ALIAS20
				ALIAS21
Примечание - Утолщенная линия обозначает недоступность адресов при получении неполного количества блоков добавочных данных.

Эта процедура позволяет назначать АС до 16 разговорных групп DGNA (15 - через режим DGNA_Address и еще одну - через режим DGNA_Alias). С помощью команды режима DGNA_Alias каждая из этих разговорных групп должна быть связана с текстовой строкой размером до 21 символа юникода.

Если ADDRESS представляет собой групповой адрес формата One-key_talkgroup для АС-получателя, то OK в первом добавочном UDT должен быть установлен в значение 1₂. Если АС ранее хранила групповой адрес формата One-key_talkgroup, то новым групповым адресом One-key_talkgroup станет полученный ADDRESS.

Если OK установлен в значение 0₂, то ADDRESS не станет новым групповым адресом формата One-key_talkgroup. В этом случае если в АС ранее хранился адрес One-key_Talkgroup, то он остается без изменений.

Для удаления шестнадцатой разговорной группы DGNA, которая назначается только с помощью команды в режиме DGNA_Alias, DGNA_Alias передается с ADDRESS, установленном в значение ADRNULL, OK установлен в значение 0₂, PN - в значение 0₂, UAB - в значение 0₂, ALIASx - в значение 000₁₆.

7.5.7.3 Процедуры DGNA для TSCC

Общие положения

АС запрашивает услугу передачи данных с использованием процедуры UDT для выполнения процедуры DGNA в транкинговом режиме сети путем создания произвольного запроса с помощью служебного сообщения с использованием PDU доступа с адресом получателя, соответствующим адресу шлюза Gateway DGNAI.

Когда TSCC отвечает на запрос произвольного доступа, то он должен запустить таймер (TNP_Timer). Этот таймер должен быть обновлен, если TSCC отправляет вызывающей стороне сообщения о ходе обработки вызова.

Ответ TSCC на вызов индивидуальной АС или разговорной группы

Когда служебное сообщение с использованием PDU услуги произвольного доступа динамической нумерации группы получено TSCC, то TSCC должен отправить ответ в соответствии с процедурами произвольного доступа, описанными в 7.2.

Служебными сообщениями, которые должны быть переданы в ответ на запрос АС о произвольном доступе к динамической нумерации группы UDT, являются:

а) сообщения подтверждения C_NACKD PDU, C_QACKD PDU, C_WACKD PDU;

б) передаваемые данные - заголовок UDT и добавочные блоки (АС отклонила вызовы);

в) C_AHOY PDU, в котором IE Source_Address соответствует значению запроса аутентификации (проверка аутентификации АС);

г) C_AHOY PDU из DGNAI, который дает указание вызывающей АС передать ее динамическое назначение адресов разговорной группы, используя процедуру UDT (C_AHOY, в котором IE Service_Kind установлен в значение 1101₂, Source_Address соответствует DGNAI, Target_Address соответствует ID вызывающей АС, а также добавочные блоки из запроса произвольного доступа АС).

Нисходящая фаза передачи данных UDT

После успешного завершения фазы восходящей передачи данных с использованием процедуры UDT TSCC должен передать динамические адреса разговорных групп вызываемой стороне. Состав HEAD PDU для нисходящей фазы передачи данных UDT приведен в таблице 62.

Таблица 62

Состав HEAD PDU для нисходящей фазы передачи данных UDT

IE	Длина, бит	Комментарий
Функциональные элементы
Элементы, определенные в ГОСТ Р 71586.1
G/I	1	0₂ = пункт назначения - адрес индивидуальной АС
A	1	1₂ = запрос ответа, если пункт назначения - адрес индивидуальной АС
Emergency (экстренный вызов)	1	0₂ = PDU не поддерживает приоритетный экстренный вызов
UDT_Option_Flag	1	См. 16.3.13.3
Format (формат)	4	0000₂
SAP	4	SAP - 0000₂ для UDT
UDT_Format	4	Режим DGNA_Address = 0001₂
UDT_Format	4	Режим DGNA_Alias = 1010₂
Target_Address или Gateway	24	ID вызываемой АС
Source_Address или Gateway	24	ID вызывающей АС (или Gateway)
PN	5	Режим DGNA_Address = 0 0000₂
PN	5	Режим DGNA_Alias = PN (см. таблицу Б.9)
R	1	0₂
UAB	2	Число добавочных блоков (см. таблицу 60): 00₂ = 1 добавочный блок данных UDT; 01₂ = 2 добавочных блока данных UDT; 10₂ = 3 добавочных блока данных UDT; 11₂ = 4 добавочных блока данных UDT
SF	1	0₂ = этот заголовок UDT содержит данные услуг, запрошенных пользователем
PF	1	Зарезервировано для будущего использования
Opcode (C_DGNAHD)	6	Должен быть установлен в значение 10 0100₂

Заключительное подтверждение вызывающей стороне

При нисходящей передаче TSCC передает динамические адреса разговорных групп принимающей стороне. Получателем является АС, поэтому она должна отправить подтверждение в TSCC.

TSCC должен направить соответствующее подтверждение вызывающей стороне, чтобы сообщить о результатах передачи UDT динамических адресов разговорных групп. Если загрузка данных UDT прошла без ошибок, то подтверждение должно быть C_ACKU PDU (в котором Reason соответствует MS_Accepted). Такое же подтверждение, но в C_ACKD PDU (в котором Mirrored_Reason соответствует MS_Accepted) должно быть отправлено вызывающей АС.

7.5.7.4 Процедуры DGNA для АС

Общие положения

АС запрашивает услугу DGNA у другой индивидуальной АС, используя процедуру UDT. АС запрашивает услугу, отправив запрос произвольного доступа C_RAND PDU, соблюдая процедуры, описанные в 7.2. Блоки служебного сообщения с использованием PDU в запросе произвольного доступа передаются на CCL стека протоколов. IE C_RAND PDU для услуги DGNA приведены в таблице 63.

Таблица 63

IE C_RAND PDU для услуги DGNA

IE	Размер, бит	Длина, бит	Имя	Значение	Комментарий
Service_Options	7	1	EMERG	Не применяется - 0₂
		1	-	0₂	Конфиденциальность (R)
		1	SUPED_SV	0₂	Не применяется - 0₂
		1	BCAST_SV	0₂	Не применяется - 0₂
		1	R	0₂	Не применяется - 0₂
		2	PRIORTY_SV	00₂	Не применяется - 00₂
Proxy Flag	1	-	PROXY	0₂	-
Appended_Supplementary_Data	2	-	SUPED_VAL	XX₂	Количество добавочных UDT, которое требуется для передачи дополнительной информации
Appended_Short_Data	2	-	SDATA_VAL	00₂	-
Service_Kind	4	-	IND_DG_SRV	1101₂	Услуга "Вызов дополнительных данных"
Target_Address или Gateway	24	-	-	XX...X₂	DGNAI
Source_Address	24	-	-	XX...X₂	Индивидуальный адрес запрашивающей АС

Инициирование услуги DGNA

Для запроса услуги DGNA от АС к другой АС адрес назначения не предоставляется TSCC, пока не будет завершена восходящая фаза передачи данных UDT.

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

Запрос услуги DGNA от шлюза (Gateway) возможен только в нисходящей фазе передачи данных с использованием механизма UDT.

Ответ на запрос услуги DGNA

Вызывающая АС должна принять следующие служебные сообщения как ответ на запрос услуги DGNA в произвольном доступе:

а) сообщения подтверждения C_NACKD PDU, C_QACKD PDU, C_WACKD PDU;

б) данные - заголовок UDT и добавочные блоки (АС отклонила вызовы);

в) C_AHOY PDU, в котором Source_Address соответствует значению запроса аутентификации (проверка аутентификации АС);

г) C_AHOY PDU от DGNAI, дающий указания вызывающей АС передать ее динамические адреса группы, используя механизм UDT (C_AHOY, в котором Service_Kind установлен в значение 1101₂, Source_Address соответствует DGNAI, Target_Address соответствует ID вызывающей АС), и добавочные блоки от запроса произвольного доступа АС.

Ответ АС на сообщение TSCC AHOY для восходящей фазы передачи данных UDT

АС должна передать динамические адреса разговорных групп в TSCC. Состав HEAD PDU для восходящей фазы передачи данных UDT приведен таблице 64.

Таблица 64

Состав HEAD PDU для восходящей фазы передачи данных UDT

Длина, бит

Комментарий

Функциональные элементы

& G/I

0₂ = назначение - адрес индивидуальной АС

& A

1₂ = запрос ответа, если назначение - адрес индивидуальной АС

0₂

UDT_DIV

0₂ = этот UDT не поддерживает переадресацию вызова

& Format

0000₂

& SAP

SAP - 0000₂ для UDT

UDT_Format

Режим DGNA_Address = 0001₂

Режим DGNA_Alias = 1010₂

& Target_Address

ID вызываемой АС

& Source_Address

ID вызывающей АС

Режим DGNA_Address = 0 0000₂

Режим DGNA_Alias = PN (см. таблицу Б.9)

0₂

UAB

Количество добавленных блоков:

00₂ = 1 добавочный блок данных UDT;

01₂ = 2 добавочных блока данных UDT;

10₂ = 3 добавочных блока данных UDT;

11₂ = 4 добавочных блока данных UDT

0₂ = этот заголовок UDT содержит информацию об услугах, инициированных пользователем

Зарезервировано для будущего использования

Opcode (C_DGNAHU)

Должен быть установлен в значение 10 0101₂

ИС NORMPROD: примечание.

Ячейки таблицы, обведенные утолщенной линией в официальном тексте документа, в электронной версии документа обозначены символом "&".

Примечание - IE, определенные в ГОСТ Р 71586.1, обведены утолщенной линией.

Подтверждения, получаемые вызывающей АС

Когда служебное сообщение C_RAND PDU передано вызывающей стороной, она может получить ответ, описанный в 7.5.7.4 ("Ответ АС на сообщение TSCC AHOY для восходящей фазы передачи данных UDT").

В любое время вызывающей стороной могут быть отправлены следующие служебные сообщения:

а) C_NACKD PDU - чтобы указать, что произошел сбой вызова. IE Reason должен быть установлен в значение, указывающее на причину сбоя вызова;

б) C_WACKD PDU, если передача сигналов продолжается;

в) C_ACKD PDU (в котором Mirrored_Reason соответствует MS_Accepted) - после восходящей фазы передачи данных с использованием механизма UDT при успешной передаче сообщения.

Если получен ответ в служебном сообщении C_NACKD PDU, то вызывающая АС должна отменить вызов DGNA UDT и вернуться в состояние "свободен".

Любое полученное подтверждение прохождения вызова должно перезапустить TNP_timer. Для случая, указанного в перечислении в):

- если короткие данные UDT адресованы индивидуальной АС, то причина подтверждения должна быть C_ACKD PDU (в котором Mirrored_Reason соответствует MS_Accepted);

- если короткие данные UDT адресованы разговорной группе, то подтверждение должно быть ACK (Message_Accepted). Но в этом случае не будет известно, получены ли какой-либо одной или всеми разговорными группами короткие данные UDT. Будет известно только то, что сеть отправила данные в разговорную группу;

- если короткие данные UDT адресованы шлюзу (например, line dispatcher), то подтверждение должно быть C_ACKD PDU (в котором Mirrored_Reason соответствует Message_Accepted).

Ожидание последующей сигнализации после таймаута

АС, ожидающая последующей сигнализации, должна отменить услугу короткого информационного сообщения с использованием процедуры UDT и вернуться в состояние "свободен", если истекает время TNP_Timer.

АС, получающая служебное сообщение PDU UDT DGNA

Если АС получает многоблочный UDT Head PDU с адресом назначения, совпадающим с ее индивидуальным адресом, то она должна ответить соответствующим подтверждением. IE Appended_Blocks в заголовке UDT указывает количество добавленных блоков UDT.

7.5.8 Процедуры дуплексного речевого вызова от АС к АС

7.5.8.1 Общие положения

Речевые вызовы требуют наличия канала, обеспечивающего передачу полезной нагрузки, по которому вызов передается каждому из участников. Вызовы могут совершаться между объектами, показанными в таблице 65.

Таблица 65

Объекты услуги "Дуплексный речевой вызов"

Режим	Инициатор	Получатель
Дуплексный речевой вызов	АС	АС

Только АС могут быть получателями при дуплексном речевом вызове от АС к АС.

PDU Service_Options в запросе услуги "Произвольный доступ" должен приводить в действие запрос услуги "Дуплексный речевой вызов" от АС к АС. IE Service_Options должен быть идентичен такому же элементу, используемому в процедуре стандартного речевого вызова (см. 7.5.3), за исключением услуг широковещательной передачи и вызова всех АС, которые являются вызовами разговорной группы.

7.5.8.2 Процедуры дуплексного речевого вызова от АС к АС для TSCC

Общие положения

АС запрашивает в транкинговой сети услуги дуплексной речевой связи от АС к АС, отправляя в восходящее направление TSCC служебное сообщение запроса произвольного доступа C_RAND PDU с адресом получателя, являющимся индивидуальным адресом АС.

TSCC должен направить ответ на запрос произвольного доступа и запустить таймер (TP_Timer). Этот таймер должен быть обнулен при отправке TSCC связанных с вызовом служебных сообщений C_WACKD PDU, C_QACKD PDU или C_AHOY PDU вызывающей стороне.

Ответ TSCC на одноблочное установление речевого вызова

При получении TSCC служебного сообщения с использованием PDU запроса речевой услуги произвольного доступа TSCC должен отправить ответ в соответствии с процедурами произвольного доступа, описанными в 7.2.

Ответом TSCC на запрос услуги одиночного речевого вызова являются следующие служебные сообщения:

а) сообщения подтверждения C_NACKD PDU, C_QACKD PDU, C_WACKD PDU, C_ACKD PDU (в котором mirrored_reason соответствует Callback);

б) данные - заголовок UDT и добавочные блоки (речевой вызов переадресован), при этом PDU заголовка UDT Source_Address соответствует DIVERTI (передача адреса для переадресации), IE Supplementary_Flag установлен в значение 1₂ и IE A - в значение 0₂;

в) C_AHOY PDU от вызывающей АС (проверка вызываемой стороны) (C_AHOY PDU с IE: Source_Address, соответствующим ID вызывающей АС, Destination_Address - соответствующим ID вызываемой АС) [см. 7.5.8.2 ("Проверка речевой связи")];

г) C_AHOY PDU с IE Source_Address, соответствующим значению запроса аутентификации (проверка аутентификации АС) (см. 7.4.9.3);

д) C_AHOY PDU от SUPLI для вызывающей АС, чтобы отправить дополнительные данные пользователя supplementary_user (см. 7.4.14);

е) PDU предоставления каналов для этого вызова (PD_GRANT_DX).

Для служебного сообщения по перечислению д) TSCC должен вызвать процедуру передачи данных UDT, посылая служебное сообщение C_AHOY PDU вызывающей АС для передачи данных supplementary_user. Формат данных supplementary_user указывается в UDT. Если TSCC не получил данные UDT от АС, то он может повторить C_AHOY PDU, или передать C_NACKD PDU, чтобы указать на сбой вызова, или продолжить устанавливать вызов и отменить передачу данных supplementary_user.

Порядок, в соответствии с которым служебные сообщения по перечислениям в), г) и д) должны быть отправлены, описан в 7.4.14.

Ответ TSCC на многоблочное установление речевого вызова

Многоблочное установление речевого вызова не поддерживается услугой дуплексного речевого вызова от АС к АС.

Подтверждения, отправленные по TSCC вызывающей АС (речь)

TSCC может отправить служебное сообщение с использованием PDU подтверждения вслед за запросом речевой услуги произвольного доступа, чтобы определить состояние вызова, прервать вызов или указать на обратный вызов. Процедуры аналогичны тем, что описаны в 7.5.2.3.

Проверка речевой связи

TSCC должен проверить, что вызываемый абонент находится в зоне доступа и примет вызов до того, как будет распределен рабочий канал.

TSCC должен проверить наличие (радиодоступность) вызываемого абонента, посылая служебное сообщение C_AHOY PDU вызываемой стороне. Если отправляемое служебное сообщение C_AHOY PDU с IE Service_Kind, установленным в значение 1010₂, а Service_Kind_Flag - в значение 0₂, то TSCC проверяет возможность АС принять этот вызов немедленно. Если отправлено служебное сообщение C_AHOY PDU с IE Service_Kind, установленным в значение 1010₂, а Service_Kind_Flag - в значение 1₂, то TSCC проверяет готовность АС к работе ["повешена ли трубка" на вызываемой АС (RFC)].

Проверка доступности путем отправки нескольких блоков данных с использованием процедуры UDT с передачей данных supplementary_user невозможна в режиме дуплекса от АС к АС, поскольку требуемый вызов не может быть передан в дуплексном режиме.

Если ответ от вызываемой АС не получен, то TSCC может повторить отправку служебного сообщения C_AHOY PDU. При проверке доступности предусмотрены следующие действия в зависимости от ответа вызываемой АС:

- если ответ - C_NACKU PDU, то TSCC должен отправить вызывающей АС соответствующий ответ о неудачном завершении вызова и установить в служебном сообщении PDU C_NACKD PDU IE Reason в значение mirrored_reason;

- если ответ - C_ACKU PDU (в котором Reason соответствует CallBack), то TSCC должен отправить соответствующий ответ CallBack (обратный вызов) вызывающей АС, отправив служебное сообщение C_ACKD PDU (mirrored_reason установлен в значение 0100 0101₂);

- если ответ - C_ACKU (в котором Reason соответствует Message_Accepted), то TSCC должен продолжить запрос и распределить рабочий канал, передавая соответствующие PDU предоставления канала;

- если вызываемой АС разрешено использовать установление вызова по методу FOACSU, то значимым ответом на C_AHOY PDU с IE: Service_Kind, установленным в значение 1010₂, Service_Kind_Flag - в значение 1₂, является C_ACKU PDU (в котором Reason соответствует MS_ALERTING), то есть АС оповещает абонента о вызове, но еще не находится в состоянии готовности к коммуникации (RFC).

7.5.8.3 Процедуры дуплексного речевого вызова от АС к АС для АС

Общие положения

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

АС запрашивает услугу дуплексного речевого вызова от АС к АС, отправляя запрос произвольного доступа C_RAND PDU с соблюдением процедур произвольного доступа, описанных в 7.2. IE в запросе произвольного доступа передаются на CCL стека протоколов и устанавливаются в соответствии с таблицей 66.

Таблица 66

IE C_RAND для услуги дуплексного речевого вызова от АС к АС

IE	Размер, бит	Длина, бит	Имя	Значение	Комментарий
Service_Options	7	1	EMERG	0₂	Неэкстренная услуга
		1	EMERG	1₂	Экстренная услуга
		1	-	0₂	Конфиденциальность (R)
		1	SUPED_SV	0₂	Услуга передачи данных supplementary_user не является обязательной
		1	SUPED_SV	1₂	Услуга передачи данных supplementary_user является обязательной для этого вызова
		1	BCAST_SV	0₂	Не применяется для дуплексных речевых вызовов от АС к АС
		1	R	0₂	-
		2	PRIORTY_SV (см. прим. 1)	00₂	Нормальный (низкий) приоритет
				01₂	Средний приоритет
				10₂	Высокий приоритет
				11₂	Наивысший приоритет
Proxy Flag	1	-	PROXY	0₂	Не применяется для дуплексных речевых вызовов от АС к АС
Appended_Supplementary_Data	2	-	SUPED_VAL	XX₂	Количество добавочных UDT, которое требуется для передачи данных supplementary_user
ALS	1	-	ALS_SERV	0₂	ALS не требуется
ALS	1	-	ALS_SERV	1₂	ALS требуется
R	1	-	-	0₂	-
Service_Kind	4	-	IND_V_SRV_DX	1010₂	Услуга дуплексного индивидуального речевого вызова от АС к АС
Target_Address	24	-	-	XX...X₂	Адрес получателя
Source_Address	24	-	-	XX...X₂	Индивидуальный адрес запрашиваемой АС
Примечания 1 Если EMERG = 1₂, то PRIORTY_SV устанавливается в значение 00₂. 2 Если SUPED_SV = 0₂, то SUPED_VAL = 00₂.

Инициирование одноблочной услуги речевого вызова

Для дуплексного запроса речевой услуги от АС к АС на индивидуальную АС адрес назначения полностью задается в IE Target_Address в служебном сообщении с использованием PDU произвольного доступа, при этом Service_Kind всегда установлен в значение 1010₂ для указания услуги индивидуального дуплексного вызова от АС к АС.

Ответ на одноблочный запрос речевой услуги

Ответом для АС на одноблочный запрос речевой услуги должны быть следующие служебные сообщения:

а) подтверждение C_WACKD PDU, C_QACKD PDU, C_NACKD PDU, C_NACKD PDU (mirrored_reason), C_ACKD PDU [mirrored_reason соответствует значению Callback (обратный вызов)];

б) C_AHOY PDU - проверка радиодоступности вызываемой стороны;

в) данные - заголовок UDT плюс добавочный блок UDT. В заголовке UDT Source_Address соответствует DIVERTI (передача измененного адреса), IE Supplementary_Flag установлен в значение 1₂ и IE A - в значение 0₂;

г) служебное сообщение с использованием PDU предоставления канала (PV_GRANT_DX);

д) если в IE Service_Options установлено значение SUPED_SV, равное 1₂, то требуется запрос C_AHOY PDU из шлюза SUPLI для загрузки дополнительных пользовательских данных (supplementary_user) от вызывающей АС.

Ответ на многоблочный запрос речевой услуги

Многоблочное установление речевого вызова не поддерживается услугой дуплексного речевого вызова от АС к АС.

Подтверждения, полученные вызывающей АС (речь)

После отправки запроса речевых услуг служебным сообщением с использованием PDU произвольного доступа вызывающая АС может получить подтверждение. При получении подтверждения она должна запустить или перезапустить таймер ожидания TP_Timer (TSCC запускает аналогичный таймер).

АС должна выполнить следующие действия:

а) отправить служебные сообщения, информирующие о ходе выполнения запроса услуги речевого вызова:

1) C_WACKD PDU: промежуточное подтверждение. Далее будут следовать служебные сообщения с использованием PDU, информирующие о дальнейшем состоянии хода выполнения запроса. АС должна ждать завершения истечения времени таймера TP_Timer для дальнейшей передачи и может указывать на возможную задержку пользователю,

2) C_QACKD PDU: вызываемая АС занята другим вызовом. АС должна ждать завершения истечения времени таймера TP_Timer для дальнейшей передачи,

3) C_QACKD: вызов поставлен в очередь, поскольку ресурс используется в данный момент. АС должна ждать завершения истечения времени таймера TP_Timer для дальнейшей передачи и может указывать на возможную задержку пользователю;

б) АС может выбирать между действиями 1), 2) и 3), предоставляя пользователю аудио- или визуальную индикацию по каждому из состояний;

в) PDU завершения вызова должны быть выбраны из соответствующих значений IE Reason в C_NACKD PDU, как описано в 16.3.9.3. Если вызов был отклонен вызываемой стороной, то отправленные ТС PDU прерывания должны быть C_NACKD PDU (mirrored_reason):

1) C_NACKD PDU: вызов отклонен и прерван. В служебном сообщении C_NACKD PDU используются коды Reason и Mirrored Reason, чтобы информировать вызывающую сторону о причине прекращения запроса услуги. Вызывающая сторона должна вернуться в состояние "свободен",

2) C_NACKD PDU (mirrored_reason соответствует MS_Duplex_Not_Supported): Вызываемая АС показывает, что она не поддерживает услугу дуплексного речевого вызова от АС к АС. Вызывающая АС должна пытаться установить другой вызов, используя услугу индивидуального речевого вызова с теми же свойствами;

г) служебные сообщения с использованием PDU обратного вызова уведомляют вызывающую АС, что услуга голосового вызова была принята вызываемой стороной. Оказание услуги завершено. Вызывающая сторона должна вернуться в состояние "свободен": C_ACKD PDU [в котором mirrored_reason соответствует значению Callback (обратный вызов)].

д) если ТС ранее приняла переадресацию вызова, показывающую, что этот тип запроса услуги должен быть перенаправлен другому вызываемому абоненту, то к запросу добавляются UDT HEAD и добавочная информация, содержащая адрес перенаправления.

Проверка доступности вызываемой стороны (речь)

Для установки дуплексного вызова от АС к АС вызываемая АС должна получить сигнал радиопроверки, на который она отвечает соответствующим подтверждением:

- вызываемая сторона должна ответить C_NACKU PDU, если она не может принять вызов (TSCC должен отправить соответствующий ответ о сбое вызова вызывающей АС);

- если вызываемая АС не поддерживает дуплексные вызовы от АС к АС, то она должна установить IE Reason в значение MS_Duplex_Not_Supported. Вызывающая сторона может затем попытаться установить вызов с помощью индивидуального речевого вызова;

- вызываемая АС должна ответить C_ACKU PDU (в котором Reason соответствует CallBack), если она желает получить этот вызов позднее (TSCC должен отправить соответствующий ответ CallBack (mirrored_reason) вызывающей АС);

- вызываемая сторона должна ответить служебным сообщением C_ACKU PDU (в котором Reason соответствует MS_Accepted), если вызов получен и АС может отработать его незамедлительно (TSCC должен продолжить запрос услуги и распределить рабочий канал для передачи полезной нагрузки (речь), передавая соответствующие служебные сообщения с использованием PDU предоставления канала);

- если АС разрешено установление вызова по методу FOACSU и сообщение, на которое АС отправляет подтверждение, является C_AHOY PDU с установленными IE Service_Kind, установленным в значение 1010₂ и Service_Kind_Flag, установленным в значение 1₂, то ответом должно быть служебное сообщение C_ACKU PDU (в котором Reason соответствует MS_ALERTING), т.е. АС оповещает абонента о получении вызова, но еще не отправляет сигнал (RFC). После отправки подтверждения АС может отправить сигнал готовности к работе ("трубка повешена", RFC) с помощью служебного сообщения C_RAND PDU (услуга "Вызов ответа", при этом IE ACCEPT установлен в значение 0₂). Если вызываемая АС оповещает о вызове, но пользователь не желает его принять, то АС должна отправить служебное сообщение C_RAND PDU (услуга "Вызов ответа", при этом IE ACCEPT установлен в значение 1₂), чтобы отклонить вызов.

Выделение рабочего канала для передачи полезной нагрузки

АС должна проверить адреса в IE, полученные в служебных сообщениях с использованием PDU предоставления дуплексного конфиденциального речевого канала (Duplex Private Voice Channel Grant PDU). Если определено, что полученное служебное сообщение с использованием PDU предоставления канала применимо для АС (соответствует ее адресу), тогда она должна перенастроиться на указанный физический/логический рабочий канал, чтобы начать предоставление речевой услуги (начать речевой вызов).

Если АС получает служебное сообщение с использованием PDU предоставления дуплексного конфиденциального речевого канала (PV_GRANT_DX), где IE Target_Address (адрес получателя) совпадает с ее индивидуальным адресом, то это служебное сообщение является применимым к АС.

TSCC может отправить два PV_GRANT_DX PDU для данного вызова, по одному для каждого участника.

Каждая АС должна ожидать свой личный ID АС в поле получатель, чтобы принять служебное сообщение PV_GRANT_DX PDU.

Вызывающая АС при одноблочном установлении речевого вызова

При одноблочном установлении вызова действия вызывающей АС должны соответствовать описанным в диаграмме SDL, приведенной в 7.5.3.3 ("Вызывающая АС в SDL одноблочного установления речевого вызова") (рисунки 51 и 52).

MSC установления вызова с передачей данных supplementary_user

MSC установления вызова с передачей данных supplementary_user приведена в 7.5.3.3 ("MSC установления вызова, передающего данные supplementary_user") и проиллюстрирована на рисунке 53.

7.5.8.4 Требования к синхронизации при выделении рабочего канала

Требования, определенные в 7.5.2.6 ("Требования синхронизации рабочих каналов для распределения полезной нагрузки по ним и к PDU полезной нагрузки и синхронизации"), должны применяться для дуплексных вызовов от АС к АС.

7.5.8.5 Процедуры для речевого рабочего канала

Общие положения

АС направляются на физический/логический речевой рабочий канал по TSCC. Когда речевой вызов прерывается, АС возвращается к TSCC, а рабочий канал переназначается другому вызову.

Порядок и особенности работы при организации речевого вызова в статусах "транкинг сообщений", "транкинг передачи", "квазитранкинговая передача" соответствуют приведенным в 7.5.3.4 ("Общие положения").

Для услуги дуплексного индивидуального речевого вызова от АС к АС синхронизация должна быть со смещением, как определено в ГОСТ Р 71586.2-2024 [подпункт 7.2.1.2 ("Смещенный канал")].

Процедуры для ТС и АС в речевом рабочем канале описаны в ГОСТ Р 71586.2-2024 (пункт 7.2.2). Однако в транкинговой связи в дополнение к PDU, описанным в ГОСТ Р 71586.2, между ТС и АС применяются также PDU поддержки вызова.

Дуплексные вызовы от АС к АС используют синхронизацию с TDD, как описано в ГОСТ Р 71586.2-2024 (подпункт 7.2.4.3).

В активном состоянии рабочий канал должен передавать CACH в форме, определенной в ГОСТ Р 71586.2-2024 (подпункт 16.3.2.2).

В начале вызова должен использоваться метод PATCS в соответствии с ГОСТ Р 71586.2-2024 (пункт 13.2.2) и ГОСТ Р 71586.1-2024 (пункт 13.1.2). Для услуги вызова индивидуальной АС вызываемая сторона уже будет проверена в рамках процедуры установки вызова.

Процедуры ТС для речевого рабочего канала

Процедуры ТС для дуплексного речевого вызова в рабочих каналах от АС к АС должны соответствовать описанию в 7.5.3.4 ("Процедуры ТС для речевого вызова в рабочем канале").

Процедуры АС для речевого вызова в рабочем канале

Процедуры АС для дуплексного речевого рабочего канала от АС к АС должны соответствовать описанию в 7.5.3.4 ("Процедуры АС для речевого вызова в рабочем канале").

7.5.9 Процедуры дуплексного соединения с пакетной передачей данных от АС к АС

7.5.9.1 Общие положения

Дуплексное соединение с пакетной передачей данных от АС к АС требует использования рабочего канала, по которому будет проводиться вызов. Вызовы могут производиться между объектами, показанными в таблице 67.

Таблица 67

Услуги при соединении с пакетной передачей данных

Режим	Инициатор	Получатель
Передача пакетных данных	АС	АС

Дуплексный рабочий канал для передачи полезной нагрузки с пакетной передачей данных может поддерживать множественные одновременные вызовы.

7.5.9.2 Процедуры для TSCC при дуплексном соединении с пакетной передачей данных от АС к АС

Общие положения

АС запрашивает услугу транкинговой сети, генерируя запрос служебным сообщением произвольного доступа C_RAND PDU, устанавливая в IE Target_Address индивидуальный адрес АС (используется одноблочное установление вызова).

Когда TSCC отвечает на запрос произвольного доступа, он должен запустить таймер (TP_Timer). Этот таймер должен обновляться, если TSCC отправляет служебное сообщение с использованием PDU для информирования вызывающей стороны о состоянии процесса вызова.

Ответ TSCC на запрос установления вызова с одноблочной пакетной передачей данных

Когда служебное сообщение с использованием PDU произвольного доступа пакетной информации принимается по TSCC, TSCC должен отправить ответ в соответствии с процедурами произвольного доступа, описанными в 7.2.

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

а) сообщения подтверждения C_NACKD PDU, C_QACKD PDU, C_WACKD PDU;

б) данные - заголовок UDT с добавочными блоками (соединение с пакетной передачей данных переадресовывается) UDT. PDU заголовка Source_Address соответствует DIVERTI (передача измененного адреса), IE Supplementary_Flag установлен в значение 1₂, IE A - в значение 0₂;

в) C_AHOY PDU (проверка по радиоканалу вызываемой АС) (C_AHOY Source_Address соответствует ID вызывающей АС, Destination_Address соответствует ID вызываемой АС) [см. 7.5.3.2 ("Проверка речевой радиосвязи")].

г) C_AHOY PDU (в котором Source_Address соответствует значению запроса аутентификации (проверка аутентификации АС).

д) C_AHOY PDU от SUPLI для пересылки дополнительной информации от вызывающей АС.

е) PDU предоставления канала для этого вызова (PD_GRANT_DX). Порядок, согласно которому должны отправляться служебные сообщения по перечислениям в), г) и д), описан в 7.4.14.

Ответ TSCC на запрос установки вызова с многоблочной пакетной передачей данных

Многоблочное соединение с пакетной передачей данных не поддерживается услугой дуплексного соединения с пакетной передачей данных от АС к АС.

Подтверждения, отправленные по TSCC вызываемой АС (пакетная информация)

TSCC может отправлять PDU подтверждения выполнения процедуры вызова или его прекращения.

Процедуры аналогичны описанным в 9.2.4.

Проверка радиодоступности при пакетной передаче данных

Для вызовов на индивидуальные АС TSCC должен проверить, что вызываемая сторона находится на связи, и принять вызов до того, как будет выделен рабочий канал. Проверка радиосвязи может также означать, что оконечное оборудование данных вызываемой стороны находится в состоянии готовности.

TSCC должен проверить доступность вызываемой стороны, отправив ей служебное сообщение C_AHOY PDU.

Если ответ на вызов не получен вызывающей стороной, то TSCC может повторить передачу служебного сообщения C_AHOY PDU. В результате проверки доступности предусмотрены следующие действия:

- если получен ответ C_NACKU PDU, то TSCC должен отправить соответствующий ответ о сбое вызова вызывающей АС и отразить это в IE Reason служебного сообщения C_NACKD PDU;

- если получен ответ C_ACKU PDU (Reason соответствует Message_Accepted), то TSCC должен продолжить запрос услуги и выделить рабочий канал, передавая соответствующие служебные сообщения с использованием PDU предоставления канала.

7.5.9.3 Процедуры для АС при дуплексном соединении с пакетной передачей данных от АС к АС

Общие положения

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

АС запрашивает услугу дуплексного соединения от АС к АС с пакетной передачей данных, отправляя запрос произвольного доступа C_RAND PDU в соответствии с процедурой, описанной в 7.2. IE в запросе произвольного доступа соответствуют CCL стека протоколов и устанавливаются в соответствии с таблицей 68.

Таблица 68

IE C_RAND для услуги вызова с пакетной передачей данных

IE	Размер, бит	Длина, бит	Имя	Значение	Комментарий
Service_Options	7	1	EMERG	0₂	Неэкстренная услуга
		1	EMERG	1₂	Экстренная услуга
		1	-	0₂	Конфиденциальность (R)
		1	SUPED_SV	0₂	Для этого вызова не требуется услуга "Передача дополнительных данных"
		1	SUPED_SV	1₂	Для этого вызова требуется услуга "Передача дополнительных данных"
		1	HI_RATE	0₂	Не применяется при полнодуплексном вызове с пакетной передачей данных от АС к АС
		1	R	0₂	-
		2	PRIORTY_SV <1>	00₂	Нормальный (низкий) приоритет
				01₂	Средний приоритет
				10₂	Высокий приоритет
				11₂	Наивысший приоритет
Proxy Flag	1	-	PROXY	0₂	Не применяется при полнодуплексном вызове с пакетной передачей данных от АС к АС
Appended_Supplementary_Data	2	-	SUPED_VAL	XX₂	Количество добавочных UDT, которое требуется для передачи дополнительных данных
Appended_Short_Data	2	-	SDATA_VAL	00₂	Не применяется при пакетной передаче данных
Service_Kind	4	-	IND_D_SRV_DX	1011₂	Услуга индивидуального вызова с пакетной передачей данных
Target_Address	24	-	-	XX...X₂	Адрес получателя
Source_Address	24	-	-	XX...X₂	Адрес запрашивающей АС
<1> Если EMERG = 1₂, то PRIORTY_SV устанавливается в значение 00₂. Примечание - Если SUPED_SV = 0₂, то SUPED_VAL устанавливается в значение 00₂.

Инициирование одноблочной услуги соединения с пакетной передачей данных

Для запроса услуги дуплексной пакетной передачи данных от АС к АС или разговорной группе адрес назначения задается в IE Target_Address в PDU произвольного доступа. Значение Service_Kind = 1011₂, что указывает на услугу дуплексной пакетной передачи данных от АС к АС.

Ответ на запрос одноблочной услуги пакетной передачи данных

АС должна принять следующие служебные сообщения как ответ на запрос услуги одноблочной пакетной передачи данных:

а) сообщения подтверждения C_WACKD PDU, C_QACKD PDU, C_NACKD PDU;

б) C_AHOY PDU от вызывающей АС ID - проверка по радиоканалу вызываемой АС;

в) PDU предоставления канала (PD_GRANT_DX);

г) C_AHOY PDU от SUPLI для загрузки дополнительных данных от вызывающей АС, если Service_Options SUPED_SV установлен в значение 1₂;

д) данные - заголовок UDT с добавочными блоками PDU (Source_Address соответствует DIVERTI, Embedded_Flag установлен в значение 1₂).

Ответ на запрос услуги многоблочной пакетной передачи данных

Установление многоблочного соединения с пакетной передачей данных не поддерживается услугой дуплексного соединения с пакетной передачей данных от АС к АС.

Подтверждения, полученные вызывающей АС (пакетная информация)

После отправки запроса услуги пакетной передачи данных PDU произвольного доступа вызывающая АС может получить подтверждение. При получении подтверждения АС должна запустить или перезапустить таймер ожидания TP_Timer (TSCC запускает аналогичный таймер).

АС должна осуществить следующие действия:

а) отправить служебное сообщение с использованием PDU процесса выполнения вызова для запроса услуги одноблочного соединения с пакетной передачей данных:

1) C_WACKD PDU: промежуточное подтверждение. Далее будут следовать дополнительные PDU. АС должна ждать в течение времени таймера TP_Timer для дальнейшей передачи и может указывать вызывающей АС на возможную задержку,

2) C_QACKD PDU (Reason соответствует Queued_for_Busy): вызываемая АС занята другим вызовом. АС должна ждать в течение времени TP_Timer для дальнейшей передачи и может указывать на возможную задержку пользователю,

3) C_QACKD PDU (Reason соответствует Queued_for_Resource): вызов поставлен в очередь, поскольку ресурс используется в данный момент. АС должна ждать в течение времени таймера TP_Timer для дальнейшей передачи и может указывать на возможную задержку пользователю.

АС может выбирать между действиями 1, 2 и 3, предоставляя вызывающей АС конкретный индикатор для каждого из состояний;

б) прерывания выбираются из IE Reason служебного сообщения C_NACKD PDU (см. 16.3.9) в следующих случаях:

1) C_NACKD PDU: вызов отклонен и прерван. C_NACKD PDU в IE Reason указывает вызывающей стороне причину прекращения запроса услуги. Вызывающая сторона должна вернуться в состояние "свободен". Если вызов был отклонен вызывающей стороной, то отправленные ТС PDU прерывания должны быть C_NACKD PDU (mirrored_reason),

2) C_NACKD PDU (mirrored_reason соответствует MS_Duplex_Not_Supported): вызываемая АС показывает, что она не поддерживает дуплексную услугу пакетной передачи данных от АС к АС.

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

Проверка доступности вызываемой АС (пакетная передача данных)

Для установки дуплексного вызова от АС к АС вызываемая АС должна получить сигнал проверки радиодоступности, на который она должна ответить соответствующим подтверждением:

- вызываемая сторона должна ответить C_NACKU PDU, если она не может принять вызов или ее оконечное оборудование данных не готово. TSCC должен отправить соответствующий ответ о сбое вызова вызывающей АС (с IE mirrored_reason);

- вызывающая сторона должна ответить C_ACKU PDU (Reason соответствует Message_Accepted), если вызов принят (TSCC должен продолжить запрашивать услугу и выделить рабочий канал, передав соответствующие сообщения предоставления канала с использованием PDU).

Выделение рабочего канала

АС должна проверить IE адресной информации, полученные в служебных сообщениях с использованием PDU предоставления канала дуплексной передачи пакетной информации. Если определено, что служебное сообщение с использованием PDU предоставления канала применимо, то АС должна перенастроиться на указанный физический/логический рабочий канал, чтобы начать пакетную передачу данных.

Если АС получает служебное сообщение PDU предоставления дуплексного конфиденциального канала, где IE Target_Address совпадает с индивидуальным адресом, то такое служебное сообщение считается применимым и должно быть выполнено.

TSCC может отправить два PDU PD_GRANT_DX для данного вызова, по одному для каждого участника.

АС должны ожидать свой личный ID в поле "Получатель", чтобы принять PDU PD_GRANT_DX.

7.5.9.4 Процедуры для рабочего канала с пакетной передачей данных

Общие положения

АС направляются на физический/логический канал пакетной передачи данных по TSCC. Когда соединение с пакетной передачей данных ограничивается ТС или АС, АС должна вернуться к TSCC. Когда физический канал был назначен, пользовательские данные с использованием PDU данных произвольной длины передаются по радиоинтерфейсу, используя процедуры, описанные в ГОСТ Р 71586.1 и ГОСТ Р 71586.2.

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

Услуга дуплексной передачи данных от АС к АС не поддерживает режим высокоскоростной передачи данных.

Процедуры для ТС и АС в рабочем канале при передаче полезной нагрузки с пакетной передачей данных описаны в ГОСТ Р 71586.2. В транкинговой сети служебные сообщения с использованием PDU поддержки вызова передаются между АС и ТС в дополнение к служебным сообщениям с использованием PDU, описанным в ГОСТ Р 71586.2.

Дуплексные вызовы от АС к АС используют синхронизацию с TDD, как описано в ГОСТ Р 71586.2-2024 (подпункт 7.2.4.3).

ТС, находясь в активном состоянии в рабочем канале, должна передавать CACH в форме, описанной в ГОСТ Р 71586.2-2024 (подпункт 16.3.2.2).

В системе ППР может быть организовано несколько независимых вызовов с пакетной передачей данных по одному и тому же каналу передачи пакетных данных. В этом случае АС могут совместно использовать этот канал, но следует иметь в виду, что, пока АС находятся вне TSCC, они не смогут принимать новые вызовы. Новые соединения с пакетной передачей данных, направленные АС, которая активна в канале передачи пакетных данных, могут быть либо поставлены в очередь системой, либо такой вызов может быть направлен на канал пакетной передачи данных. В этом случае он также будет использовать канал совместно с другими текущими вызовами.

Если АС принимает установку соединения с пакетной передачей данных с адреса IPv4 или IPv6, то процедура UDT может отправить полный IP-адрес вызывающей стороны как часть установления вызова, используя услугу передачи дополнительных данных. Тогда система может использовать IPI в качестве адреса источника для вызова с пакетной передачей данных.

Процедуры ТС для рабочего канала с пакетной передачей данных

Процедуры ТС для дуплексного рабочего канала с пакетной передачей данных от АС к АС должны соответствовать описанным в 9.4.2.

Процедуры АС для рабочего канала с пакетной передачей данных

Процедуры АС для дуплексного рабочего канала с пакетной передачей данных от АС к АС должны соответствовать описанию, приведенному в 9.4.3.

7.5.10 Служба опроса с использованием USBD

7.5.10.1 Введение

Служба опроса через USBD позволяет опрашивать АС и получать данные либо по TSCC, либо по TSCCAS. Посредством PDU ответа на опрос (Poll Response PDU) АС может передать до 68 бит данных. PDU заявки на опрос (Poll Request PDU) может передать опрашиваемой АС до 48 бит информации. Форматы IE различных USBD PDU также различны, так как Poll Request PDU передается только в восходящем канале, а Poll Response PDU - только в нисходящем. Рисунки 63, 64 и 65 иллюстрируют примеры опросов через USBD по TSCCAS.

Пример опроса через USBD по TSCCAS включает следующие этапы и подпункты:

а) "А" - это Poll Request PDU, передаваемый по TSCCAS к АС(А);

б) "Б" - это Poll Response PDU, исходящий от АС(А);

в) "В" - это Poll Request PDU, передаваемый по TSCCAS к АС(Б) в те же моменты, что и "Б";

г) "Г" - это Poll Response PDU, исходящий от АС(Б);

д) "Д" - это Poll Request PDU, передаваемый по TSCCAS к АС(В) в те же моменты, что и "Г";

е) "Е" - это Poll Response PDU, исходящий от АС(В);

ж) "Ж" - это Poll Request PDU, передаваемый по TSCCAS к АС(X) в те же моменты, что и "Е";

и) "И" - это Poll Response PDU, исходящий от АС(X).

	Aloha			Получатель сообщения
	TSCC		Альтернативный TSCC			Унифицированный одиночный блок данных

Рисунок 63 - Пример USBD-опроса по TSCCAS с синхронизацией

по времени (Responce Delay установлен в значение 00₂)

	Aloha			Получатель сообщения
	TSCC		Альтернативный TSCC			Унифицированный одиночный блок данных

Рисунок 64 - Пример USBD-опроса по TSCCAS со смещенной

синхронизацией по времени (Responce Delay соответствует 00₂)

	Aloha			Получатель сообщения
	TSCC		Альтернативный TSCC			Унифицированный одиночный блок данных

Рисунок 65 - Пример USBD-опроса по TSCCAS

с синхронизацией по времени и задержкой ответа

90 мс (Responce Delay соответствует 01₂)

Примечание - В приведенных примерах IE Response_Delay и тип синхронизации канала определяют, когда отвечают АС.

7.5.10.2 Процедуры службы опроса с использованием USBD для TSCC и TSCCAS

Для запроса на USBD-опрос индивидуальной АС адрес назначения полностью определяется IE Target_Address в USBD Poll Request PDU.

IE Service_Type может указывать на 16 различных типов опроса. IE Response_Delay указывает, в каком таймслоте ожидается ответ на запрос (Poll Response PDU). Формат USBD Poll Request PDU определяется, как показано в таблице 69.

Таблица 69

IE USBD Poll Request PDU

Название	Длина, бит	Значение	Комментарий
Service_Type	4	0000₂	Короткий запрос геолокации
		0001₂ - 0111₂	Зарезервировано
		1000₂ - 1111₂	Определяется производителем
Response_Delay <1>	2		Синхронизация	Смещенная синхронизация
		00₂	Задержка 30 мс. Ответ на запрос ожидается в следующем TDMA-кадре	Задержка 60 мс. Ответ на запрос ожидается в следующем TDMA-кадре + 1 таймслот
		01₂	Задержка 90 мс. Задержка в два TDMA-кадра	Задержка 120 мс. Два TDMA-кадра + 1 таймслот задержки
		10₂	Задержка 150 мс. Три TDMA-кадра задержки	Задержка 180 мс. Три TDMA-кадра + 1 таймслот задержки
		11₂	Задержка 210 мс. Четыре TDMA-кадра задержки	Задержка 240 мс. Четыре TDMA-кадра + 1 таймслот задержки
PCt	1	-	Содержание полезной нагрузки
R	1	0₂	-
Parameters	48	-	Зависит от Service_Type
Target_Address	24	-	Адрес получателя
<1> См. рисунки 63, 64 и 65.

Если запрос отправлен по TSCC, последний должен убедиться, что на таймслот, в котором ожидается ответ, не распространяется режим произвольного доступа.

7.5.10.3 Процедуры службы опроса с использованием USBD для АС

При получении USBD Poll Request PDU АС(А) должна зафиксировать значение времени задержки ответа (Response_Delay), чтобы рассчитать правильный таймслот для отправки USBD Poll Response PDU.

Если при получении USBD Poll Request PDU АС(А) поддерживает указанный в PDU тип сервиса (Service_Type), то она должна отправить соответствующий ответ.

Если АС поддерживает службу опроса, но не поддерживает указанный в принятом PDU тип сервиса, в качестве ответа она может отправить C_NACK с указанием Answer Response, соответствующим MSNot_Supported (0000 0000₂).

7.5.10.4 Служба опроса с использованием USBD - LIP

Общие положения

Служба USBD-опросов поддерживает значительную часть LIP (см. [4]). Этот функционал в совокупности со службой USBD-опросов предоставляет высокоэффективный метод поддержания большого количества обновлений локаций. USBD Poll Request используется в роли сжатого немедленного запроса обновления локации (LIP Immediate Location Update Request), а USBD Poll Response - в виде короткого отчета о позиционировании (LIP Short Location Report).

Для полной поддержки LIP:

- немедленный запрос на обновление локации сжимается в Poll Request PDU;

- по получении Poll Request PDU АС восстанавливает запрос LIP из сжатого вида;

- ответный короткий отчет о локации (LIP Short Location Report) сжимается в Poll Response PDU;

- по получении Poll Response PDU, TSCC или TSCCAS восстанавливают короткий отчет LIP;

- все остальные LIP-сообщения передаются как UDT по контрольному каналу.

Примечание - Полная поддержка LIP не является обязательной для определения локации через сервис USBD-опросов. USBD Poll Request PDU и Poll Response PDU могут использоваться без полной поддержки LIP.

USBD Poll Request PDU применительно к LIP

При полной поддержке LIP, TSCC или TSCCAS получают немедленный запрос на обновление локации и передают Poll Request PDU АС-получателю.

Формат USBD Poll Request PDU для LIP приведен в таблице 70.

Таблица 70

IE USBD Poll Request PDU для LIP

Название	Длина, бит	Комментарий
Service_Type	4	0000₂ = LIP
Response_Delay	2	-
PCt	1	-
R	1	0₂
Элементы полезной нагрузки
Payload	48	0x000000, когда PCt = 0₂
Элементы адресации
Logical Link ID (LLID)	24	Адрес назначения

IE немедленного запроса LIP на обновление локации не отправляются в Poll Request PDU. По получении Poll Request PDU для LIP АС, обладающая полной поддержкой LIP, распаковывает Poll Request PDU, чтобы сформировать немедленный запрос на обновление локации. IE этого запроса не содержатся в Poll Request PDU, а добавляются в результате процесса декомпрессии (распаковки) PDU. Эти IE приведены в таблице 71.

Таблица 71

IE немедленного запроса на обновление локации LIP

Название	Длина, бит	Комментарий
PDU Type	2	00₂ - короткий запрос локации
PDU Type Extension	4	0001₂ - немедленный запрос на обновление локации
Request/Response	1	0₂ - запрос
Report Type	2	11₂ - короткий отчет о локации (предпочтительно)
Direction of Travel and Direction of Travel Accuracy (направление движения и точность показателя)	3	000₂ - направление движения (обязательно)
Horizontal Position and Horizontal Position Accuracy (горизонтальная позиция и точность показателя)	4	0000₂ - горизонтальная позиция (обязательно)
Horizontal Velocity and Horizontal Velocity Accuracy (горизонтальная скорость и точность показателя)	3	000₂ - горизонтальная скорость (обязательно)
Maximum Information Age (срок актуальности данных)	7	111 1111₂ - наибольший возможный срок
Примечание - Значения, указанные в этой таблице, установлены в значения по умолчанию, т.о. конфигурация АС может изменить его на любое подходящее значение, как определено в [4].

USBD Poll Response PDU применительно к LIP

По получении Poll Request PDU АС должна отправить в ответ LIP Poll Response PDU в отведенный таймслот (см. 7.5.10.2).

Формат USBD Poll Response PDU для LIP приведен в таблице 72.

Таблица 72

IE USBD Poll Response PDU для LIP

Название	Длина, бит	Комментарий
Service_Type	4	0000₂ - LIP
Элементы полезной нагрузки
Time Elapsed (затраченное время)	2	Определено в [4]
Longtitude (долгота)	25	Определено в [4]
Latitude (широта)	24	Определено в [4]
Position Error (ошибка определения позиции)	3	Определено в [4]
Horizontal Velocity (горизонтальная скорость)	7	Определено в [4]
Direction of Travel (направление движения)	4	Определено в [4]
Reason for Sending	3	000₂
Элементы адресации
Hashed Source_Address	8	Сжатый адрес АС-источника <1>
<1> Для вычисления хэша адреса применяется циклический код верификации CRC-8, описанный в ГОСТ Р 71586.1-2024 (подраздел Б.13).

IE Reason for Sending

IE Reason for Sending не включает все опции, предусматриваемые LIP. После получения сжатого LIP Poll Response PDU, TSCC или TSCCAS, полностью поддерживающие LIP, восстанавливают LIP Short Location Report, преобразуя полученный "Reason for Sending" в соответствующее значение для LIP.

В USBD Poll Response АС указывает причину отправки PDU, как показано в таблице 73.

Таблица 73

Тип IE добавочных данных

Название	Длина, бит	Значение	Комментарий
Reason for Sending	3	000₂	Ответ на немедленный запрос (значение LIP = 32)
Reason for Sending	3	001₂ - 111₂	Зарезервировано

7.6 Процедуры управления системой

7.6.1 Объявления сетевой системы

7.6.1.1 Общие положения

Служебные сообщения с использованием PDU объявления передаются TSCC и содержат информацию о параметрах системы для данной ТС или другой ТС. PDU объявления могут передаваться часто, и поэтому они содержат код System Identity (идентификационный код системы) для идентификации TSCC.

Тип объявления (BCASTTYP) устанавливает, какие системные параметры передаются:

а) добавление/отключение TSCC;

б) установление параметров таймера вызова;

в) предложение смены TSCC;

г) объявление местного времени;

д) массовая регистрация;

е) объявление связи логического физического канала;

ж) информация о соседнем сайте.

7.6.1.2 Объявление/удаление TSCC

Это объявление добавляет и/или отключает радио TSCC, который активен в системе. PDU объявления содержит до двух элементов с номерами логических физических каналов. Если объявлен только один номер логического физического канала, то оставшийся элемент должен быть установлен в значение CHNULL. АС должны добавлять/удалять логический(е) канал(ы) в список/из списка Short Hunt физических каналов для поиска (см. приложение Г).

7.6.1.3 Установление параметров таймера вызова

Это служебное сообщение с использованием PDU устанавливает параметры таймера вызова:

а) для вызовов между двумя АС или АС и разговорной группой;

б) вызовов между внешними абонентами, подключенными к линии (шлюзу), и АС или разговорной группой;

в) вызовов, которые используют услугу пакетной передачи данных;

г) экстренных вызовов.

7.6.1.4 Предложение смены TSCC

Служебные сообщения с использованием PDU системных сетевых сообщений (Vote Now Advice, "Смена TSCC") дают возможность "свободным" (незанятым) АС оценить качество сигнала TSCC, указанного в этих служебных сообщениях. PDU содержит идентификационный код системы (C_SYSCode) и номер логического TSCC (CH_VOTE), качество сигнала которого предлагается оценить АС.

Пока АС оценивают соседний TSCC, они не могут получить PDU установления вызова. Поэтому TSCC не должен использовать кадры TDMA VOTE_BLK, указанные в А.3, чтобы сигнализировать АС об оценке соседнего сайта. Только следующие блоки служебных сообщений PDU могут быть переданы по TSCC в VOTE_BLK после передачи сообщения "Предложение смены TSCC":

а) PDU Aloha с адресом АС, соответствующим ADRNULL и IE "Маска", установленным в значение 24;

б) C_WACKD PDU.

Транкинговая сеть может влиять на то, какой TSCC получает АС. Это может быть не тот сайт, который обладает лучшим качеством сигнала (по мощности сигнала, параметру BER или другим параметрам).

Можно использовать две стратегии работы:

а) "Radiated Preference Strategy" (план с предпочтительным распределением). Очередность (приоритет) сайтов распределяется в "Предложении смены TSCC". АС должна использовать эту очередность и учитывать качество сигнала, чтобы определить, какие TSCC принимать или на каких TSCC остаться включенной;

б) "No Radiated Preference Strategy" ("План без предпочтительного распределения"). Очередность сайтов не распределяется в "Предложении смены TSCC", и АС может использовать любой доступный критерий, чтобы определить, надо ли переходить на новый сайт или стоит оставаться на старом сайте. Например, возможно простое сравнение качества двух сигналов, также возможно использование запрограммированных ранее значений приоритетности в TSCC (Ch_Pref) (см. А.3).

Стратегия для использования обозначена комбинацией полей, описание которых приведено ниже (их расположение в поле "Параметры вещания" приведено в 16.3.20.4).

Идентификационный код системы (System Identity) - 14 бит C_SYSCode АС, передаваемых на соседний сайт. System Identity используется для того, чтобы АС, зарегистрированная в конкретном сайте, могла определить C_SYSCode, который передается в соседнем сайте, не тестируя и не используя при этом TSCC соседнего сайта.

Номер канала (12 бит) - номер физического канала соседнего сайта, подлежащего проверке. Если номер канала находится в пределах от 1 до 4094, то он представляет собой логический номер канала для физической частоты передатчика и приемника. Если значение номера канала 4095, то он - MBC, где абсолютная частота передатчика и приемника определена во втором блоке, который связан с этим блоком [см. 16.3.20.4 ("Добавленный PDU MBC абсолютных параметров смены TSCC (VN_AP)")].

Флаг доступности активного соединения (Active Connection Available Flag) (1 бит) устанавливается, если состояние сетевого соединения соседних сайтов известно и доступно. Эта процедура необходима, поскольку информация может быть неизвестна подтвержденному сайту (например, если им потеряно подключение к сети). Если подключение установлено, то АС может использовать флаг Active Connection для анализа соседнего сайта. Если этот флаг не установлен (снят), то АС должна игнорировать флаг Active Connection.

Флаг активного соединения (Active Connection Flag) (1 бит) определен в других частях этого стандарта. Он указывает, что соседний сайт имеет полноценную связь с остальной частью сети. Радиоканал может использовать эту информацию при оценке пригодности соседнего сайта.

Подтвержденный приоритет канала (3 бита) и приоритет смежного канала (3 бита) передают приоритет текущего (подтвержденного) сайта и приоритет соседнего сайта для проведения проверки. Значения, содержащиеся в этих полях, показаны в таблице 74.

Таблица 74

Приоритет канала

Значение	Предпочтение
1	Предпочтительный сайт - наивысший приоритет
2	Предпочтительный сайт - приоритет 2
3	Предпочтительный сайт - приоритет 3
4	Предпочтительный сайт - приоритет 4
5	Предпочтительный сайт - приоритет 5
6	Предпочтительный сайт - приоритет 6
7	Предпочтительный сайт - низкий приоритет
0	Сайт без предпочтения

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

Значение 0 (без предпочтения) используется для указания того, что никакая предпочтительная информация не будет передана и АС может свободно использовать собственную методику для определения приоритета путем использования Ch_Pref data. Поэтому обычно ТС либо передает все "Предложения смены TSCC" с приоритетной очередностью, либо она должна передать все "Предложения смены TSCC" без приоритетной очередности. При передаче без приоритетной очередности следует учитывать возможность нестабильной работы системы.

Следует отметить, что при использовании сообщений "Предложение смены TSCC" с системным кодом, установленным номером канала и остальными полями, установленными в значение 0, эта комбинация воссоздаст (создаст заново) формат трансляций с "Предложением смены TSCC", как описано в настоящем стандарте. Не будет никаких указаний на активное подключение, и приоритеты как подтвержденного, так и соседнего сайтов не будут предпочтительными.

7.6.1.5 Объявление местного времени

Это служебное сообщение с использованием PDU передает АС местную дату и время. PDU разрешает не принимать во внимание дату и UTC_OFFSET, содержащиеся в сообщении.

Если смещение времени относительно UTC не учитывается, то значение UTC_OFFSET должно быть установлено в значение 1 1111₂, если UTC_OFFSET больше или меньше значения 1 1111₂, то время UTC равно сумме B_HOURS, UTC_OFFSET и UTC_OFFSET_FRACTION в 24-часовом формате.

7.6.1.6 Массовая регистрация

Служебное сообщение с использованием PDU отправляет приглашение всем АС или группе АС для регистрации в короткий или длительный период времени. Описание и процедуры указаны в 7.4.5.

7.6.1.7 Объявление связи логического и физического каналов

Этот PDU объявляет связь логического и физического каналов. PDU определяет физический передатчик и приемник, которые будут назначены логическому каналу.

7.6.1.8 Информация о соседнем сайте

Этот PDU объявляет информацию об используемых TSCC на участках (сайтах) радиосвязи в непосредственной близости от TSCC, чтобы содействовать АС в получении соответствующего TSCC, если АС перемещается в зону отсутствия радиосвязи с текущим TSCC.

PDU вещания содержит номер логического канала (Logical Channel Number) и C_SYScode, который передается объявленным TSCC. Меры, которые должны быть приняты АС по получении этого PDU, не прописаны в настоящем стандарте. Однако тем, кто будет реализовывать процессы, использующие информацию о соседнем сайте, предлагается обусловить следующее: при выборе TSCC АС ищет его в списке физических каналов-кандидатов до тех пор, пока соответствующий TSCC не будет выбран и подтвержден. Номер физического канала (CH_ADJ), полученного в PDU соседнего сайта, может быть использован для изменения поиска TSCC в пользу радиоканалов, которые с наибольшей вероятностью предоставят услугу удовлетворяющего качества, чем другие радиоканалы, которые могут быть указаны в параметрах поиска.

8 Передача коротких данных с использованием UDT

8.1 Общие положения

Услуга UDT позволяет передавать небольшие по объему данные между различными объектами сети с использованием TSCC. С помощью этой услуги может быть передано до 368 бит данных в нескольких форматах, включая двоичный, BCD, семибитный текст, восьмибитные символы, NMEA (см. [1]), шестнадцатибитовый юникод UTF-16BE, IP, специальные собственные форматы аутентификации и производителя. Если передаются отформатированные двоичные данные переменной длины, то максимальное количество бит в одной передаче - 367, потому что один бит используется для обозначения конца соответствующих данных (см. Б.3.2).

Процедура передачи коротких данных с помощью UDT использует многоблочное установление вызова. АС может отправить небольшие по объему данные с помощью этой процедуры другой АС, разговорной группе, PSTN или PABX, шлюзу соединительной линии, шлюзу диспетчера или одному из идентификаторов всех АС ALLMSID, ALLMSIDL или ALLMSIDZ (если это будет разрешено TSCC). TSCC может также передать короткие данные UDT, адресованные АС или разговорной группе, от шлюза.

На рисунке 66 приведен пример передачи короткого информационного сообщения от АС к АС с помощью UDT:

а) АС(А) вычисляет количество блоков добавочных данных (AD), необходимых для передачи коротких данных. В этом примере требуется два блока;

б) "А" - это служебное сообщение с использованием PDU произвольного доступа C_RAND PDU. Вызываемым абонентом является АС(Б), при этом Service_Kind установлен в значение "Short Data", в Appended Short Data PDU указано количество информационных блоков, необходимых для передачи коротких данных с помощью UDT;

в) "Б" - это служебное сообщение C_AHOY PDU от SDMI, который запрашивает услугу у АС(А) для передачи коротких данных, используя процедуру UDT;

г) "В" - восходящая фаза передачи данных, состоящая из многоблочного заголовка UDT с добавочными данными;

д) "Г" - нисходящая фаза передачи данных, состоящая из многоблочного заголовка UDT с добавочными данными;

е) "Д" - это подтверждение от АС(Б);

ж) "Е" - это окончательное подтверждение вызывающему абоненту АС(А). Следует отметить, что подтверждение повторяется для надежности.

	Aloha		Ahoy		Заголовок для добавленных данных		Aloha M = 24 Address = NULL
	RQ произвольного доступа		Ответ Ack		Добавленные данные		Получатель сообщения

Рисунок 66 - Пример передачи короткого информационного

сообщения с помощью механизма UDT

При вызове на расширенные адреса (extended_address) TSCC использует процедуру UDT, чтобы передать информацию extended_address. В этом случае восходящая фаза должна использовать две процедуры UDT. Блоки данных PDU в C_AHOY PDU указывают, какая восходящая передача данных UDT запрашивается.

Максимальное количество битов, которые могут быть транспортированы услугой UDT, ограничено максимальным числом блоков AD. Протокол транкинговой сети разрешает до четырех блоков добавочных данных.

Для услуги UDT к разговорной группе вызываемая сторона не должна отправлять ответ. TSCC может повторить нисходящую фазу, чтобы повысить вероятность успешной передачи сообщения. TSCC должен отправить окончательное подтверждение вызывающей стороне, даже если нет уверенности в успешном получении коротких данных через UDT. Окончательное подтверждение не должно быть отправлено вызывающей стороне, пока не будет завершена последняя нисходящая фаза.

Временные параметры для восходящей и нисходящей фаз передачи данных в настоящем документе не определены. На рисунке 67 показаны примеры других применимых способов доставки коротких данных через UDT.

В первом примере заголовок UDT и добавленные блоки UDT повторно передаются TSCC, как только они были получены. Преимущество такой синхронизации заключается в минимизации сквозной задержки (между двумя АС). Однако сообщения, полученные с обнаруженными, но неисправленными ошибками в восходящей фазе приводят к появлению сообщений, содержащих неисправленные ошибки в нисходящей фазе, что приводит к потере пропускной способности. Этапы восходящей и нисходящей фазы в таком случае придется повторять.

Если восходящая фаза полностью завершается, как показано во втором примере (и на рисунке 66), то при обнаружении неисправимых ошибок эта фаза может быть повторена до перехода к нисходящей фазе. Однако в этом случае будет потеряна сквозная задержка (задержка между двумя АС).

	Aloha		Ahoy		Заголовок для добавленных данных		Aloha M = 24 Address = NULL
	RQ произвольного доступа		Ответ Ack		Добавленные данные		Получатель сообщения

Рисунок 67 - Примеры передачи коротких данных с помощью UDT

8.2 Передача коротких данных с помощью механизма UDT по TSCC

8.2.1 Общие положения

АС запрашивает услугу передачи коротких данных через UDT в транкинговой сети путем создания и отправки служебного сообщения PDU запроса произвольного доступа с указанием в IE Target_Address адреса, соответствующего:

а) адресу индивидуальной АС;

б) адресу АС разговорной группы;

в) адресу шлюза (UDT, чтобы передать расширенный адрес назначения от АС).

Когда TSCC отвечает на запрос произвольного доступа для услуги передачи коротких данных с помощью UDT, он должен запустить таймер (TNP_Timer). Этот таймер должен быть обновлен, если TSCC отправляет далее сообщение о прохождении вызова вызывающей стороне.

8.2.2 Ответ TSCC на вызов к индивидуальной АС или разговорной группе (фаза загрузки)

При получении TSCC служебного сообщения с использованием PDU запроса произвольного доступа для услуги передачи коротких данных UDT, TSCC должен отправить ответ служебным сообщением в соответствии с процедурами произвольного доступа, описанными в 7.2.

Служебные сообщения ответа на запрос произвольного доступа услуги передачи коротких данных через UDT к АС или разговорной группе должны быть следующие:

а) сообщения подтверждения C_NACKD PDU, C_QACKD PDU, C_WACKD PDU;

б) данные - заголовок UDT с добавочными блоками (вызов коротких данных переадресовывается);

в) C_AHOY PDU, в котором Source_Address соответствует значению запроса аутентификации (проверка аутентификации АС);

г) C_AHOY PDU от SDMI, дающий команду вызывающей АС передать ее короткие данные UDT, используя процедуру UDT (C_AHOY, в котором Service_Kind установлен в значение 0100₂, Source_Address соответствует SDMI, Target_Address соответствует MSID вызывающей стороны);

д) C_AHOY PDU от SUPLI, дающий команду вызывающей АС передать AD, используя процедуру UDT (в служебном сообщении C_AHOY PDU должны быть установлены значения параметров в IE: Service_Kind установлен в значение 0100₂, Source_Address соответствует SUPLI, Target_Address соответствует MSID вызывающей стороны).

Порядок, по которому должны быть отправлены служебные сообщения по перечислениям г) и д), обозначен в 7.4.14.

8.2.3 Ответ TSCC на вызов по адресу назначения extended_address (фаза загрузки)

При получении служебного сообщения с использованием PDU произвольного доступа для услуги передачи коротких данных через UDT по TSCC, TSCC должен послать ответ в соответствии с процедурами произвольного доступа, описанными в 7.2.

К PDU, которые представляют собой ответ на запрос произвольного доступа услуги передачи коротких данных с помощью процедуры UDT по расширенному адресу назначения (extended_address), относятся:

а) служебные сообщения подтверждения C_QACKD PDU, C_WACKD PDU;

б) служебное сообщение C_AHOY PDU от SDMI, дающее команду вызывающей АС передать ее сообщение коротких данных с использованием процедуры UDT (в служебном сообщении C_AHOY PDU должны быть установлены следующие значения в параметрах IE: Service_Kind установлен в значение 0100₂, Source_Address соответствует SDMI, Target_Address соответствует MSID вызывающей стороны);

в) служебное сообщение C_AHOY PDU от SUPLI, дающее команду вызывающей АС передавать AD, используя механизм UDT (в служебном сообщении C_AHOY PDU должны быть установлены значения в параметрах IE: Service_Kind установлен в значение 0100₂, Source_Address соответствует SUPLI, Target_Address соответствует MSID вызывающей стороны);

г) служебное сообщение для вызова на extended_address, C_AHOY PDU от PABXI, PSTNI, LINEI, DISPATI, IPI, дающее команду вызывающей АС отправить ее extended_address (такой как PSTN, PABX), используя процедуру UDT (в служебном сообщении C_AHOY PDU должны быть установлены значения в параметрах IE: Service_Kind установлен в значение 0100₂, Source_Address соответствует PABXI, PSTNI, LINEI, DISPATI, IPI, Target_Address соответствует MSID вызывающей стороны).

Если служебное сообщение по перечислению в) будет отправлено, то сообщение перечисления б) должно следовать за в) в соответствии с требованиями, определенными в 7.4.14.

Перечень адресов шлюзов для передачи блоков данных протокола, которые могут быть указаны в служебном сообщении C_AHOY PDU, поддерживающих услугу передачи коротких данных с помощью UDT, представлены в таблице 75.

Таблица 75

IE C_AHOY для услуги передачи коротких данных UDT к шлюзу

Действие	Адрес шлюза	Комментарий
Отправить цифры PSTN для адресата коротких данных	PSTNI	Вызывающая сторона должна передать набранные цифры BCD в восходящем направлении
Отправить цифры PABX для адресата коротких данных	PABXI	Вызывающая сторона должна передать набранные цифры BCD в восходящем направлении
Отправить цифры LINE для адресата коротких данных	LINEI	Вызывающая сторона должна передать набранные цифры BCD в восходящем направлении
Отправить цифры диспетчера для адресата коротких данных	DISPATI	Вызывающая сторона должна передать набранные цифры BCD в восходящем направлении
Передать в восходящем направлении IP-адрес для адресата коротких данных	IPI	Вызывающая сторона должна передать адрес IPv4 или IPv6 в восходящем направлении

а) C_NACKD PDU: вызов отклонен и прерван. Вызывающая сторона должна вернуться в свободное состояние. Если прерывание вызова стало результатом отказа вызываемой стороны, C_NACKD PDU должен использовать значение IE mirrored_reason;

б) если ТС ранее приняла переадресацию вызова, указывающую, что этот тип запроса услуги коротких данных будет направлен другой вызываемой стороне, заголовок UDT и AD, указывающие измененный адрес.

Фаза загрузки завершается, когда вызывающая АС отвечает с передачей следующих данных: заголовка и AD.

8.2.4 Проверка доступности вызываемой АС для выполнения услуги передачи коротких данных через UDT

При вызовах к индивидуальной АС TSCC может проверить, что вызываемая сторона находится в радиодоступности перед скачиванием коротких данных с использованием процедуры UDT.

TSCC может проверить доступность вызываемой стороны путем:

а) отправки служебного сообщения C_AHOY PDU вызываемой стороне (в служебном сообщении C_AHOY PDU должны быть установлены значения в параметрах IE: Service_Kind установлен в значение 0100₂, Source_Address соответствует MSID вызывающей стороны, Target_Address соответствует MSID вызывающей стороны);

б) отправки многоблочного UDT с AD (если услуга UDT активна для этого вызова).

Если ответ от вызывающей стороны не принят, то TSCC может повторить передачу служебного сообщения C_AHOY PDU. Проверка доступности требует ответа от вызываемой стороны:

- если ответом является C_NACKU PDU, то TSCC должен отказаться от отправки вызова короткого сообщения, отправить соответствующий ответ сбоя вызова вызывающей АС и передать служебное сообщение C_NACKD PDU с параметром mirrored_reason;

- если ответом является C_ACKU PDU (Reason соответствует Message_Accepted), то TSCC должен продолжить запрос услуги и скачать короткое информационное сообщение, используя процедуру UDT.

8.2.5 Отправка коротких данных через UDT вызываемой стороне (фаза скачивания)

В фазе скачивания TSCC загружает вызываемому абоненту заголовок короткого информационного сообщения с AD. Для индивидуальной транзакции коротких данных, если не было получено подтверждение вызываемой стороны, заголовок UDT с AD может быть повторен. При передаче коротких данных в разговорную группу ответ не ожидается, но TSCC может повторить фазу скачивания для надежности.

8.2.6 Окончательное подтверждение вызывающей стороне о выполнении услуги "Передача коротких данных"

В нисходящей фазе TSCC скачивает короткие данные UDT вызываемой стороне (источнику запроса услуги). Если получателем выступает индивидуальная АС, подтверждение должно быть получено по TSCC. При передаче коротких данных разговорной группе фаза скачивания может быть повторена, но подтверждение не ожидается.

TSCC должен отправить соответствующее подтверждение вызывающей стороне, чтобы сообщить о результатах запроса UDT. При индивидуальной передаче коротких данных, если они были приняты без ошибок, подтверждением должно быть C_ACKU [Reason соответствует MS_Accepted (код Reason 0100 0100₂)]. Затем вызывающей АС должно быть отправлено служебное сообщение C_ACKD PDU с Mirrored_Reason, соответствующим MS_Accepted (код Reason 0100 0100₂). При передаче коротких данных разговорной группе подтверждением должно быть служебное сообщение C_ACKU PDU [в котором Reason соответствует Message_Accepted (код Reason 0110 0000₂)].

8.3 Процедуры выполнения услуги передачи коротких данных с помощью механизма UDT для АС

АС запрашивает услугу "Передачи коротких данных" через UDT к другой индивидуальной АС, разговорной группе или шлюзу, используя многоблочный запрос услуги. Для вызовов на extended_address передача extended_address и коротких данных осуществляется путем двух отдельных передач с использованием процедуры UDT.

АС запрашивает услугу "Передача коротких данных" путем отправки запроса произвольного доступа служебным сообщением C_RAND PDU, соблюдая процедуры произвольного доступа, описанные в 7.2. Служебное сообщение с использованием PDU в запросе произвольного доступа передается на CCL стека протоколов и устанавливаются в соответствии с таблицей 76.

Таблица 76

IE C_RAND для услуги "Передача коротких данных"

IE	Размер, бит	Длина, бит	Имя	Значение	Комментарий
Service_Options	7	1	EMERG	Не применяется - 0₂
		1	-	0₂	Конфиденциальность (R)
		1	SUPED_SV	0₂	Нет услуги "Передача AD", необходимой для этого вызова
		1	SUPED_SV	1₂	Услуга "Передача AD", необходимая для этого вызова
		1	BCAST_SV	0₂	Не применяется - 0₂
		1	R	0₂	Не применяется - 0₂
		2	PRIORTY_SV	00₂	Не применяется - 00₂
Proxy-Flag	1	-	PROXY	0₂	Количество расширенных цифр BCD для адресации через шлюз - от 1 до 20
Proxy-Flag	1	-	PROXY	1₂	Количество расширенных цифр BCD для адресации через шлюз - от 21 до 44
Appended_Supplementary_Data	2	-	SUPED_VAL	XX₂	Количество добавочных блоков UDT, требующихся для транспортировки AD <1>
Appended_Short_Data	2	-	SDATA_VAL	XX₂	Количество добавочных UDT, требующихся для транспортировки AD
Service_Kind	4	-	IND_SD_SRV	0100₂	Услуга "Вызов индивидуальных коротких данных"
Service_Kind	4	-	GRP_SD_SRV	0101₂	Услуга "Вызов индивидуальных коротких данных разговорной группы"
Target_Address или Gateway	24	-	-	XX...X₂	Адрес получателя <2>
Source_Address	24	-	-	XX...X₂	Индивидуальный адрес запрашивающей АС
<1> Если SUPED_SV = 0₂, то SUPED_VAL = 00₂. <2> Если Service_Kind = IND_SD_SRV, то Target_Address представляет индивидуальный адрес. Если Service_Kind = GRP_SD_SRV, то Target_Address представляет разговорную группу.

8.4 Инициирование услуги "Передача коротких данных"

Для запроса услуги "Передача коротких данных" к индивидуальной АС или разговорной группе адрес назначения устанавливается в IE Target_Address в служебном сообщении произвольного доступа C_RAND PDU. IE Service_Kind определяет, будет ли услуга вызова "Передача коротких данных" направлена на индивидуальный адрес или к разговорной группе. Для вызовов шлюза в IE Target_Address или Gateway в C_RAND PDU записывается адрес шлюза.

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

8.5 Ответ на услугу "Передача коротких данных" вызовом произвольного доступа

Ответом для вызывающей АС на запрос произвольного доступа услуги "Передача коротких данных" должны быть:

а) подтверждения служебными сообщениями C_NACKD PDU, C_QACKD PDU, C_WACKD PDU;

б) передаваемые данные: заголовок UDT с добавочными блоками (вызов услуги "Передача коротких данных" переадресовывается);

в) служебное сообщение C_AHOY PDU от SDMI, дающее команду вызывающей АС передать ее короткие данные, используя процедуру UDT (в служебном сообщении C_AHOY PDU должны быть установлены значения параметров в IE: Service_Kind установлен в значение 0100₂, Source_Address соответствует SDMI, Target_Address соответствует MSID вызывающей стороны);

г) PDU C_AHOY от SUPLI, дающий команду вызывающей АС передавать AD, используя процедуру UDT (в служебном сообщении C_AHOY PDU должны быть установлены значения параметров в IE: Service_Kind установлен в значение 0100₂, Source_Address соответствует SUPLI, Target_Address соответствует MSID вызывающей стороны);

д) служебное сообщение C_AHOY PDU для вызова на extended_address от PABXI, PSTNI, LINEI, DISPATI, IPI, дающее команду вызывающей стороне отправить ее extended_address, используя процедуру UDT (в служебном сообщении C_AHOY PDU должны быть установлены значения параметров в IE: Service_Kind установлен в значение 0100₂, Source_Address соответствует PABXI, PSTNI, LINEI, DISPATI, IPI, Target_Address соответствует MSID вызывающей стороны).

Если отправлено служебное сообщение с конкретным PDU, то порядок должен соответствовать описанному в перечислениях а), в), г) и д).

8.6 Подтверждения, полученные вызывающей АС при оказании ей услуги "Передача коротких данных"

При передаче служебного сообщения C_RAND PDU вызывающей стороной первый ответ может быть получен, как это указано в 8.5.

Вызывающей стороне должны быть отправлены следующие служебные сообщения в зависимости от выполнения услуги:

а) C_NACKD PDU, чтобы указать сбой вызова, при этом должен быть установлен IE Reason в значения, указывающие причину сбоя вызова;

б) C_WACKD PDU, если будет следовать дальнейшая сигнализация в служебных сообщениях;

в) C_ACKD PDU с установленным значением в IE Mirrored_Reason, соответствующим MS_Accepted (после успешного выполнения услуги "Передача коротких данных" и завершения передачи коротких данных).

Если принято служебное сообщения C_NACKD PDU, вызывающая АС должна отказаться от дальнейших попыток вызова услуги "Передача коротких данных" и вернуться в исходное состояние.

Любое полученное соответствующее подтверждение прохождения вызова должно быть перезапущено по завершении работы таймера TNP_timer в следующих случаях [для варианта, описанного в перечислении в) при получении C_ACKD PDU]:

а) если короткие данные UDT адресованы индивидуальной АС, то причиной подтверждения должно быть служебное сообщение C_ACKD PDU, в котором Mirrored_Reason соответствует MS_Accepted;

б) если короткие данные адресованы разговорной группе, подтверждением должно быть служебное сообщение C_ACK PDU с установленным значением Message_Accepted. В этом случае не было бы известно, получил ли кто-то из разговорной группы короткие данные, а только то, что сеть отправила данные в разговорную группу;

в) если короткие данные адресованы шлюзу (например, диспетчер линии), подтверждением должно быть служебное сообщение C_ACK PDU с параметрами Mirrored_Reason, соответствующими Message_Accepted.

8.7 Тайм-аут в ожидании дальнейшей сигнализации

АС, ожидающая дальнейшую сигнализацию, должна отказаться от услуги "Передача коротких данных" и вернуться в исходное состояние, если истекает время таймера TNP_Timer.

8.8 Процедуры для АС, принимающей короткие данные через UDT

Если АС получает многоблочный PDU UDT_HEAD [см. ГОСТ Р 71586.1-2024 (пункт 15.4.14)] с адресом получателя, заказавшим услугу (Target_Address), совпадающим с ее индивидуальным адресом, она должна ответить соответствующим подтверждением. IE Appended_Blocks в заголовке многоблочного сообщения UDT указывает количество добавленных блоков UDT.

Если АС принимает многоблочный PDU заголовка UDT с Target_Address, совпадающим с адресом разговорной группы, АС должна принять информацию, содержащуюся в добавочных блоках, но не передавать ответ.

8.9 MSC выполнения процедуры "Короткое информационное сообщение"

На рисунке 68 представлено выполнение процедуры "Короткое информационное сообщение" с помощью механизма UDT по отношению к индивидуальной АС или к разговорной группе, как определено в разделе 8.

Рисунок 68 - MSC выполнения услуги "Короткое информационное

сообщение" с помощью механизма UDT

9 Услуга передачи пакетных данных

9.1 Процедуры соединения с пакетной передачей данных. Общие положения

Для соединения с пакетной передачей данных должен быть использован рабочий канал, по которому ведется вызов. Передаваемые пакетные данные могут быть IP-данными или короткими данными, использующими неподтверждаемые или подтверждаемые (с подтверждением достоверности на принимающей стороне) данные услуги переноса информации DLL, как это определено в ГОСТ Р 71586.1 или ГОСТ Р 71586.2. Вызовы могут быть осуществлены между объектами, представленными в таблице 77.

Таблица 77

Услуги соединения с пакетной передачей данных

Режим	Инициатор	Получатель
Передача пакетных данных	АС	АС или разговорная группа
	АС	Все АС (широковещательные)
	АС	Назначение соединительной линии через шлюз: - шлюз IP; - шлюз данных; - другой шлюз, оборудованный для данных
	Источник соединительной линии через шлюз: - шлюз IP; - шлюз данных; - другой шлюз, оборудованный для данных	АС, разговорная группа или все АС

Рабочий канал для передачи пакетных данных может поддерживать одновременно несколько вызовов.

9.2 Процедуры соединения с пакетной передачей данных для TSCC

9.2.1 Общие положения

АС запрашивает услугу транкинговой сети путем создания и отправки служебного сообщения с использованием PDU запроса произвольного доступа с адресом, установленным в IE Target_Address и имеющим следующие значения:

а) адрес индивидуальной АС (одноблочное установление вызова);

б) адрес разговорной группы АС (одноблочное установление вызова);

в) адрес шлюза, который указывает на многоблочное установление вызова.

Когда TSCC отвечает на запрос произвольного доступа, он должен запустить таймер (TP_Timer). Этот таймер должен быть обновлен, если TSCC отправляет дальнейшие PDU прохождения вызова вызывающей стороне.

9.2.2 Ответ TSCC на одноблочное установление вызова пакетных данных

При получении TSCC запроса произвольного доступа для передачи пакетных данных TSCC должен отправить ответ в соответствии с процедурами произвольного доступа, описанными в 7.2.

Ответом TSCC на одноблочный запрос произвольного доступа услуги установления вызова пакетных данных должны быть следующие служебные сообщения:

а) подтверждения C_NACKD PDU, C_QACKD PDU, C_WACKD PDU;

б) передаваемые данные: заголовок UDT с добавочными блоками (соединение с пакетной передачей данных переадресовывается). В PDU заголовка UDT содержатся IE: Source_Address, соответствующий DIVERTI (передача измененного адреса), Supplementary_Flag, установленный в значение 1₂, и IE A, установленный в значение 0₂;

в) C_AHOY PDU к MSID вызываемого абонента, если вызов осуществляется к индивидуальной АС (C_AHOY, в котором Service_Kind в значение 0010₂, Source_Address соответствует MSID вызывающей стороны, Target_Address соответствует MSID вызываемой стороны), как указано в таблице 78;

г) C_AHOY PDU, в котором Source_Address соответствует значению запроса аутентификации (проверка аутентификации АС);

д) C_AHOY PDU к вызывающему абоненту (в служебном сообщении C_AHOY PDU должны быть установлены следующие значения параметров в IE: Service_Kind - в значение 0010₂, Source_Address - SUPLI, Target_Address - MSID вызывающей стороны) для вызывающей АС, чтобы передать данные supplementary_user;

е) служебное сообщение в PDU предоставления канала для этого вызова.

Порядок, в котором PDU, указанные в перечислениях в) и д), будут отправлены, описан в 7.4.14.

Примечание - Многоблочная передача UDT не отправляет все опции предоставления услуги вызываемому абоненту. Если опции предоставления услуги важны для работы системы, АС должны быть отправлены служебные сообщения C_AHOY/ответ и UDT Multi_block/ответ.

Таблица 78

IE C_AHOY услуги вызова пакетных данных

IE	Размер, бит	Длина, бит	Имя	Значение	Комментарий
CSBKO	6	-	CSBKO	011100₂	C-AHOY
FID	8	-	SFID	0x00	Стандартный набор функций ID
Параметры	7	1	EMERG	0₂	Неэкстренная служба
		1	EMERG	1₂	Экстренная служба
		1	-	0₂	Конфиденциальность (R)
		1	SUPED_SV	0₂	Нет услуги "Передача дополнительных данных, необходимых для этого вызова"
		1	SUPED_SV	1₂	Услуга "Передача дополнительных данных, необходимых для этого вызова"
		1	HI_RATE	0₂	АС запрашивает данные рабочего канала одинарного таймслота
		1	HI_RATE	1₂	АС запрашивает данные рабочего канала двойного таймслота
		1	SIMI	0₂	Однокомпонентные данные
		1	SIMI	1₂	Многокомпонентные данные
		2	PRIORITY_SV	00₂	Нормальный (низкий) приоритет
				01₂	Средний приоритет
				10₂	Высокий приоритет
				11₂	Самый высокий приоритет
Service_Kind_Flag	1	-	-	0₂	Не применяется
Appended_Blocks	2	-	-	00₂	Не применяется
ALS	1	-	-	0₂	Не применяется
G/I	1	-	-	0₂	Адрес получателя - ID индивидуальной АС
G/I	1	-	-	1₂	Адрес получателя - групповой ID
Service_Kind	4	-	IND_D_SRV	0010₂	Индивидуальная услуга "Соединение с пакетной передачей данных"
Service_Kind	4	-	GPR_D_SRV	0011₂	Услуга "Соединение с пакетной передачей данных разговорной группы"
Target_Address или Gateway	24	-	-	XX...X₂	Адрес вызываемой АС
Source_Address	24	-	-	XX...X₂	Индивидуальный адрес запрашивающей АС

9.2.3 Ответ TSCC на многоблочное установление соединения с пакетной передачей данных

Для вызовов на extended_addresses АС должна запросить многоблочную адресацию путем создания запроса произвольного доступа соединения с пакетной передачей данных с IE Destination_Address, содержащим адрес шлюза (PABXI, PSTNI, IPI и т.д.), и IE Proxy Flag, чтобы указать количество цифр для extended_address. При количестве набранных цифр от 1 до 20 IE Proxy Flag должен быть установлен в значение 0₂. При количестве набранных цифр от 21 до 44 IE Proxy Flag должен быть установлен в значение 1₂.

Ответом на многоблочный запрос произвольного доступа услуги передачи пакетных данных должны представлять следующие служебные сообщения:

а) подтверждения C_NACKD PDU, C_WACKD PDU (Reason соответствует Wait);

б) C_AHOY PDU от PABXI, PSTNI, LINEI, DISPATI или соответствующих дуплексных шлюзов для вызывающей АС, чтобы послать информацию extended_address (в служебном сообщении C_AHOY PDU должны быть установлены следующие значения параметров в IE: Service_Kind - в значение 0010₂, Source_Address соответствует PABXI, PSTNI, LINEI, DISPATI, Target_Address соответствует MSID вызывающей стороны);

в) C_AHOY PDU от SUPLI для вызывающей АС, чтобы послать AD [в служебном сообщении C_AHOY PDU должны быть установлены следующие значения параметров в IE: Service_Kind - в значение 0010₂, Source_Address соответствует SUPLI, Target_Address соответствует MSID вызываемой стороны (см. 14.2)].

Для выполнения перечисления б) TSCC должен затем вызвать процедуру передачи данных UDT способом отправки вызывающей АС C_AHOY PDU, чтобы отправить информацию extended_address. Для вызова к PABX или PSTN информация extended_address должна быть в виде чисел BCD. IE Proxy Flag в C_AHOY PDU должен быть скопирован из IE Proxy Flag, полученного C_RAND PDU от АС.

Для выполнения перечисления в) TSCC должен затем вызвать процедуру передачи данных UDT способом отправки вызывающей АС C_AHOY PDU, чтобы отправить дополнительные данные. Формат AD определен в UDT.

Если TSCC принимает с ошибками данные UDT от АС, TSCC может повторить передачу служебного сообщения C_AHOY PDU или передать служебное сообщение C_NACKD PDU, чтобы указать на сбой вызова.

9.2.4 Подтверждения, посылаемые по TSCC вызывающей АС при выполнении услуги "Передача пакетных данных"

TSCC может отправить блоки данных протокола подтверждения после запроса произвольного доступа услуги передачи пакетных данных, чтобы сообщить о процессе прохождения вызова или прервать вызов. Если TSCC отправляет служебное сообщение в PDU, чтобы сообщить о прохождении вызова, TSCC должен запустить таймер ожидания TP_Timer (АС вызывающей стороны также запускает подобный таймер).

Различают следующие служебные сообщения о прохождении вызова:

а) C_WACKD PDU: промежуточное подтверждение. Далее будут следовать PDU;

б) C_QACKD PDU: вызываемая АС занята другим вызовом;

в) C_QACKD PDU: вызов в очереди, потому что ресурс используется в настоящий момент.

PDU прерывания выбираются из соответствующего IE Reason в PDU C_NACKD (см. 16.3.9): В данном случае таким PDU прерывания является C_NACKD PDU.

Если ТС ранее приняла переадресацию вызова, указывающую, что этот тип запроса услуги будет направлен другой вызываемой стороне, то TSCC должен вызвать UDT и передать заголовок UDT и AD вызывающей стороне.

9.2.5 Проверка радиодоступности при передаче пакетных данных

При вызовах, адресованных индивидуальной АС, TSCC должен проверить, что вызываемая сторона находится в радиодоступности, и принять вызов до того, как рабочий канал будет выделен. Такая проверка указывает, что оборудование вызываемой стороны готово к работе.

TSCC может проверять доступность вызываемой стороны следующими способами:

а) отправкой C_AHOY PDU вызываемой стороне;

б) отправкой многоблочной передачи UDT с AD (если услуга передачи AD активна для этого вызова).

Если ответ от вызываемой стороны не принят, то TSCC может повторно отправить C_AHOY PDU. После получения служебного сообщения с проверкой радиодоступности должен быть отправлен ответ от вызываемой стороны:

- если ответом является C_NACKU PDU, то TSCC должен отправить соответствующий ответ о сбое вызова вызывающей АС и повторить IE Reason в C_NACKD PDU;

- если ответом является C_ACKU PDU с Reason, соответствующим Message_Accepted, то TSCC должен отправить запрос услуги и выделить рабочий канал путем передачи соответствующих служебных сообщений в PDU предоставления канала.

При вызовах, адресованных разговорным группам, использующим услугу "передача пакетных данных", TSCC должен проверить, что хотя бы один участник разговорной группы принимает TSCC путем отправки служебного сообщения C_AHOY PDU, адресованного разговорной группе.

9.2.6 Проверка радиодоступности для услуги "Передача пакетных данных", связанных через шлюзы

Для вызовов, подключенных через шлюзы, оборудование ТС может ожидать готовности адресата перед выделением рабочего канала. Например, ТС ожидает, пока оборудование PSTN не свяжет терминал данных перед отправкой PDU предоставления канала.

9.3 Процедуры вызова с передачей пакетных данных для АС

9.3.1 Общие положения

АС должна иметь возможность запроса услуги "Передача пакетных данных" к другой индивидуальной АС или разговорной группе с использованием одноблочного запроса этой услуги. Для услуги "Передача пакетных данных", запрашиваемой по расширенным адресам (extended_addresses) через шлюз, АС использует многоблочный запрос услуги. Для многоблочного запроса услуги АС устанавливает адреса шлюза в качестве адреса вызываемой стороны. Полный адрес назначения АС передает TSCC с помощью процедуры UDT.

АС запрашивает услугу "Передача пакетных данных" путем отправки запроса произвольного доступа служебного сообщения C_RAND PDU, соблюдая процедуры произвольного доступа, описанные в 7.2. IE в запросе произвольного доступа передаются на CCL стека протоколов и устанавливаются в соответствии с таблицей 79.

Таблица 79

IE C_RAND для запроса услуги "Передача пакетных данных"

IE	Размер, бит	Длина, бит	Имя	Значение	Комментарий
Service_Options	7	1	EMERG	0₂	Неэкстренная служба
		1	EMERG	1₂	Экстренная служба
		1	-	0₂	Конфиденциальность (R)
		1	SUPED_SV	0₂	Нет услуги передачи дополнительных данных, необходимых для этого вызова
		1	SUPED_SV	1₂	Услуга передачи дополнительных данных, необходимых для этого вызова
		1	HI_RATE	0₂	АС запрашивает данные рабочего канала одинарного таймслота
		1	HI_RATE	1₂	АС запрашивает данные рабочего канала двойного таймслота
		1	SIMI	0₂	Однокомпонентные данные
		1	SIMI	1₂	Многокомпонентные данные
		2	PRIORTY_SV <1>	00₂	Нормальный (низкий) приоритет
				01₂	Средний приоритет
				10₂	Высокий приоритет
				11₂	Самый высокий приоритет
Proxy Flag	1	-	PROXY	0₂	Количество расширенных BCD цифр для адресации через PSTN/PABX шлюз = 1 до 20. Для IP-шлюза extended_address - IPV4
Proxy Flag	1	-	PROXY	0₂	Количество расширенных BCD цифр для адресации через PSTN/PABX шлюз = 21 до 44. Для IP-шлюза extended_address - IPV6
Appended_Supplementary_Data	2	-	SUPED_VAL	XX₂	Количество добавочных блоков UDT, требуемых для транспортировки AD
Appended_Short_Data	2	-	SDATA_VAL	00₂	Не применяется для передачи пакетных данных
Service_Kind	4	-	IND_D_SRV	0010₂	Индивидуальная услуга "Соединение с передачей пакетных данных"
Service_Kind	4	-	GRP_D_SRV	0011₂	Услуга "Соединение с передачей пакетных данных" разговорной группы
Target_Address или Gateway	24	-	-	XX...X₂	Адрес получателя <2>
Source_Address	24	-	-	XX...X₂	Индивидуальный адрес запрашивающей АС
<1> Если EMERG = 1₂, то PRIORTY_SV установлен в значение 00₂. <2> Если Service_Kind = IND_D_SRV, то Target_Address представляет индивидуальный адрес. Если Service_Kind = GRP_D_SRV, то Target_Address представляет разговорную группу. Примечание - Если SUPED_SV = 0₂, то SUPED_VAL = 00₂.

9.3.2 Инициирование услуги "Передача пакетных данных" одноблочным соединением

При запросе услуги передачи пакетных данных к индивидуальной АС или разговорной группе адрес назначения должен быть указан в IE Target_Address служебного сообщения в PDU произвольного доступа. IE Service_Kind определяет, будет ли услуга вызова с передачей пакетных данных направлена на индивидуальный адрес или разговорной группе.

9.3.3 Ответ на одноблочный запрос услуги "Передача пакетных данных"

АС должна принимать следующие служебные сообщения в PDU на одноблочный запрос услуги "Передача пакетных данных":

а) подтверждения C_WACKD, C_QACKD, C_NACKD PDU;

б) C_AHOY PDU от идентификатора АС вызывающей стороны - проверка радиодоступности вызываемого абонента;

в) служебные сообщения в PDU предоставления канала (Channel Grant PDU);

г) если IE Service_Options SUPED_SV соответствует 1₂, то C_AHOY PDU от SUPLI для загрузки дополнительных данных от вызываемой АС;

д) передаваемые данные: заголовок UDT с добавочными блоками. PDU заголовка UDT имеют Source_Address, соответствующий DIVERTI, и Embedded_Flag, установленный в значение 1.

Порядок, в котором служебные сообщения по перечислениям б) и г) должны быть отправлены, описан в 7.4.14.

Если АС запросила AD путем установки в служебном сообщении (в запросе вызова C_RAND PDU) IE Service_Options SUPED_SV со значением 1₂, а TSCC не поддерживает AD или не может их принимать в это время, то TSCC должен:

а) продолжить обработку установления вызова и отказаться от запроса AD пользователя или

б) передать C_NACKD PDU, чтобы указать на сбой вызова.

9.3.4 Инициирование услуги "Передача пакетных данных" многоблочным соединением

Для запроса услуги "Передача пакетных данных", использующей шлюз (PSTNI, PABXI, LINEI или DISPATI), адрес назначения не содержится в PDU служебного сообщения произвольного доступа, а передается отдельным сообщением, используя процедуру UDT передачи данных. При использовании одного из идентификаторов получателя IE PROXY в C_RAND PDU указывает количество добавляемых UDT, необходимых для загрузки расширенной адресации. IE Service_Kind указывает, адресована ли услуга "Передача пакетных данных" отдельному адресу или разговорной группе.

Если инициирующая вызов АС при запросе многокомпонентной услуги пакетной передачи данных будет также передавать дополнительные данные (например, навигационные данные ГЛОНАСС, GPS, других систем спутниковой навигации), то для этого необходимо установить IE Supplementary_Data_Service_Options в значение 1₂. В этом случае IE Appended_Supplementary_Data указывает количество добавляемых UDT, необходимых для загрузки дополнительных данных.

9.3.5 Ответ на многоблочный запрос услуги "Передача пакетных данных"

АС должна получить следующие служебные сообщения в PDU в качестве ответа на многоблочный запрос услуги "Передача пакетных данных":

а) подтверждения C_WACKD PDU, C_QACKD PDU, C_NACKD PDU;

б) C_AHOY PDU от PABXI, PSTNI, LINEI, DISPATI для загрузки extended_address:

1) при вызове к PABX/PSTN/LINEI, DISPATI или соответствующим дуплексным шлюзам C_AHOY PDU для загрузки набранных цифр,

2) для вызова к IP-назначению, C_AHOY PDU для загрузки IP-адреса,

3) если IE Service_Options SUPED_SV соответствует 12, то SUPLI может быть отправлен в служебном сообщении C_AHOY PDU для загрузки AD от вызывающей АС.

Примечание - Для сообщения, описанного в перечислении б), если запрос услуги соединения с пакетной передачей данных требует информацию extended_address и вызывающая АС выбрала дополнительные данные в опциях предоставления услуги, то TSCC загружает информацию в два шага. Этот порядок загрузки информации описан в 7.4.14.

9.3.6 Подтверждения, принятые вызывающей АС для услуги "Передача пакетных данных"

После отправки служебного сообщения в PDU произвольного доступа запроса услуги передачи пакетных данных вызывающая АС может принять подтверждение. Получив это подтверждение, АС должна запустить или перезапустить таймер ожидания TP_Timer (TSCC поддерживает аналогичный таймер).

АС должна отправить служебные сообщения, содержащие:

а) PDU о прохождении одноблочного запроса услуги соединения с передачей пакетных данных:

1) C_WACKD PDU: промежуточное подтверждение. Далее будут следовать другие PDU. АС должна ожидать в течение времени, определенного TP_Timer для дальнейшей сигнализации, и может указать вызывающей АС на возможную задержку,

2) C_QACKD PDU (Reason соответствует Queued_for_Busy): вызываемая АС занята другим вызовом. АС должна ожидать TP_Timer для дальнейшей сигнализации, и может указать вызывающей АС на возможную задержку,

3) C_QACKD PDU (Reason соответствует Queued_for_Resource): вызов в очереди, потому что ресурс используется в настоящее время. АС должна ожидать в течение времени, определенного TP_Timer для дальнейшей сигнализации, и может указать вызывающей АС на возможную задержку. АС может выбрать между сообщениями по вариантам 1), 2) и 3), предоставив вызывающей АС конкретное указание для каждого из условий;

б) информацию о прекращении вызова, которая определяется в PDU соответствующим IE Reason в C_NACKD PDU (см. 16.3.9). В данном случае это C_NACKD PDU: вызов отклонен или прерван. C_NACKD PDU имеет универсальный набор кодов для IE Reason, чтобы указать вызывающей стороне, почему запрос услуги был прерван. Вызывающая сторона должна вернуться в свободное состояние. Если вызов был отклонен вызывающей стороной, ТС должна отправить служебное сообщение прерывания C_NACKD PDU (mirrored_reason).

9.3.7 Проверка доступности вызываемой АС для услуги "Передача пакетных данных"

При установлении вызова с услугой "Передача пакетных данных" для индивидуальной АС вызываемая АС должна провести проверку радиодоступности, на которую она должна ответить соответствующим подтверждением:

- вызываемая сторона должна ответить C_NACKU PDU в случае невозможности принять вызов или если ее терминальное оборудование не готово [TSCC должен отправить соответствующий ответ сбоя вызова вызывающей АС (mirrored_reason)];

- вызывающая сторона должна ответить C_ACKU PDU (Reason соответствует Message_Accepted), если вызов принят (TSCC должен продолжить запрос услуги и выделить рабочий канал путем передачи соответствующих служебных сообщений в PDU предоставления канала).

9.3.8 Выделение рабочего канала для услуги "Передача пакетных данных"

АС должна проверить адресные IE, принятые в блоках данных протокола предоставления канала передачи пакетных данных. Если определено, что служебное сообщение в PDU предоставления канала применимо, то она должна перестроиться на указанный физический/логический рабочий канал, чтобы начать использовать услугу "Передача пакетных данных".

Если вызов направлен разговорной группе и транкинговая сеть использует поздний вход (см. 7.5.3.5), то TSCC может продолжить отправлять блоки данных протокола предоставления канала с интервалами T_Late, пока вызов активен. АС, которая только что включилась, может быть добавлена в разговорную группу.

При условиях, описанных в 7.5.3.5 ("Таймер вызова"), АС может "отбрасывать" блоки данных протокола предоставления канала позднего входа:

а) для служебных сообщений в PDU CSBK предоставления конфиденциального канала пакетных данных, если АС принимает служебные сообщения в PDU предоставления конфиденциального канала, в которых IE Source_Address или Target_Address совпадают с индивидуальным адресом, то PDU применим для нее;

б) для служебных сообщений в PDU CSBK предоставления канала для услуги "Передача пакетных данных" разговорной группы:

1) если АС принимает служебное сообщение в PDU предоставления канала разговорной группы с IE Target_Address, совпадающим с одним из адресов разговорной группы, то такой PDU для нее применим,

2) если АС принимает служебное сообщение в PDU предоставления канала разговорной группы с Source_Address, совпадающим с индивидуальным адресом, то такой PDU для нее применим.

9.4 Процедуры для рабочего канала при предоставлении услуги "Передача пакетных данных"

9.4.1 Общие положения

АС выделяется физический/логический рабочий канал при предоставлении услуги "Передача пакетных данных" с помощью передачи служебных сообщений по TSCC. Когда соединение с пакетной передачей данных прекращено ТС или АС, тогда АС должна вернуться в TSCC. Если выделен физический рабочий канал, то пользовательские данные передаются в PDU данных произвольной длины по радиоинтерфейсу с использованием метода пакетной передачи, описанного в ГОСТ Р 71586.1 и ГОСТ Р 71586.2.

Соединение с пакетной передачей данных может продолжаться, пока оно не будет прервано АС, ТС или пока оно не прервется досрочно в результате истечения времени таймера рабочего канала при выполнении вызова "Передача пакетных данных".

Физический канал может быть сконфигурирован так, что системе доступны два независимых рабочих канала (режим передачи одинарного таймслота) или режим высокоскоростных данных (режим передачи двойного таймслота), в которых оба логических канала организованы для обеспечения услуги высокоскоростной передачи пакетных данных. Конкретная скорость передачи данных запрашивается вызывающей АС и сигнализируется сторонам блоками данных протокола предоставления канала.

Процедуры для режимов ТС/АС в рабочем канале пакетных данных описаны в ГОСТ Р 71586.1 и ГОСТ Р 71586.2. В транкинговой среде, однако, блоки данных протокола поддержания дополнительного вызова могут быть перераспределены между АС и ТС в дополнение к PDU, описанным в ГОСТ Р 71586.1 и ГОСТ Р 71586.2.

Канал передачи пакетных данных поддерживает сессии однокомпонентных и многокомпонентных данных. Сессии многокомпонентных данных состоят из двух или более элементарных сеансов передачи данных между объектами.

Когда ТС активна в рабочем канале, она должна передавать CACH с любым SLC (в том числе по выбору производителя), кроме C_SYS_Parms SLC.

Система может направить несколько независимых вызовов с передачей пакетных данных в один канал передачи пакетных данных. АС могут делить этот канал, но следует отметить, что, пока АС не находятся в TSCC, они не способны принять новые вызовы. Новые вызовы с пакетной передачей данных, направленные АС, активным в канале пакетных данных, могут быть поставлены в очередь системой, либо такие вызовы могут быть направлены в канал передачи пакетных данных и делить канал с другими текущими вызовами.

Если адрес задан в IPv4 или IPv6, то адрес назначения должен быть уточнен вызывающей стороной как функция многоблочного установления вызова. Поэтому, когда АС направляется в рабочий канал для передачи пакетных данных, система будет иметь полный адрес назначения. Таким образом, АС может установить адрес назначения к IPI для всех элементарных периодов передачи полезной нагрузки пакетных данных.

Если АС принимает установление вызова пакетных данных от адреса IPv4 или IPv6, процедура UDT способна отправить полный IP-адрес вызывающей стороны как часть установления вызова с использованием службы передачи дополнительных данных. Система может затем использовать IPI в качестве адреса источника для соединений с пакетной передачей данных.

9.4.2 Процедуры транкинговой станции для рабочего канала при предоставлении услуги "Передача пакетных данных"

9.4.2.1 Общие положения

Если новый физический канал выделен TSCC, CCL_BS должен начать процессы CCL_1 и CCL_2, как это описано в ГОСТ Р 71586.2-2024 (подпункт 13.1.1.2), и запустить таймер для рабочего канала при передаче пакетных данных T_PACKET_TIMER.

9.4.2.2 Проверка радиодоступности АС при предоставлении услуги "Передача пакетных данных"

ТС может опрашивать индивидуальные АС, чтобы проверить, активна ли АС в рабочем канале, путем передачи PDU P_AHOY PDU с IE, представленными в таблице 80.

Таблица 80

IE P_AHOY проверки радиодоступности для индивидуальной

услуги "Передача пакетных данных"

IE	Длина, бит	Комментарий
Service_Options_Mirror	7	000 0000₂
Service_Kind_Flag	1	0₂
ALS	1	0₂ - не применяется
G/I	1	0₂ - адрес получателя - индивидуальный ID АС
Target_Address	24	Индивидуальный адрес вызываемой АС
Appended_Blocks	2	00₂
Service_Kind	4	Услуга индивидуального вызова пакетных данных - 0010₂
Source_Address или Gateway	24	TSI

Ответом является C_ACKU PDU с параметром в IE Reason, соответствующим Message_Accepted.

Чтобы проверить, активен ли хотя бы один из участников разговорной группы в рабочем канале, ТС может опросить разговорную группу методом передачи P_AHOY PDU с IE, представленными в таблице 81.

Таблица 81

IE P_AHOY проверки радиодоступности разговорной группы

для услуги "Передача пакетных данных"

IE	Длина, бит	Комментарий
Service_Options_Mirror	7	0000000₂
Service_Kind_Flag	1	0₂
ALS	1	0₂ - не применяется
G/I	1	1₂ - адресом получателя является разговорная группа
Appended_Blocks	2	00₂
Service_Kind	4	Услуга "Соединение с пакетной передачей данных разговорной группы" - 0000₂
Target_Address	24	Адрес разговорной группы
Source_Address или Gateway	24	TSI

Ответом должно быть служебное сообщение P_ACKU PDU со значением IE Reason, соответствующим Message_Accepted.

Если на это служебное сообщение в PDU отвечают несколько АС, то вполне вероятно, что ТС не сможет его обработать из-за коллизий. Цель этой процедуры - определить, активны ли какие-либо разговорные группы, следовательно, ТС может использовать наличие пакета для проверки радиодоступности разговорной группы.

9.4.2.3 Проверка аутентификации в режиме "Передача пакетных данных"

Процедуры аутентификации идентичны процедурам аутентификации, описанным в 7.4.9.3 с учетом замены служебного сообщения PDU C_AHOY на служебное сообщение PDU P_AHOY.

9.4.2.4 Запрет/разрешение пользователям на пакетную передачу данных

ТС в любое время может отправить служебное сообщение P_PROTECT (Protect_Kind соответствует DIS_PTT), адресованное индивидуальной АС, разговорной группе или ALLMSID (см. А.5), для запрета всех передач АС в течение оставшейся части вызова. Поскольку служебное сообщение P_PROTECT PDU является неподтверждаемым, передача его может быть повторена.

ТС может также в любое время отправить служебное сообщение P_PROTECT PDU (Protect_Kind соответствует EN_PTT), адресованное индивидуальной АС, разговорной группе или ALLMSID (см. А.5), для разрешения передачи пользователям. Поскольку P_PROTECT PDU является неподтвержденным, PDU может быть повторен на канальном уровне стека протоколов [уровень 2 (DLL)].

В то время как ТС передает служебное сообщение P_PROTECT PDU (Protect_Kind соответствует EN_PTT_ONE_MS), направленное индивидуальному MSID (идентификатору АС), АС, которой адресовано это служебное сообщение в PDU, должна активировать PTT и может осуществлять передачу, как только рабочий канал освободится. Тем не менее в то время, пока передаются PDU, все остальные АС должны отключить (запретить) PTT.

9.4.2.5 Смена рабочего канала в режиме "Передача пакетных данных" (перестановка текущего вызова на заменяющий рабочий канал)

ТС должна обеспечить возможность отправки служебного сообщения в PDU предоставления нового канала, чтобы переместить АС, уже ведущую радиопередачу (участвующую в вызове), на альтернативный рабочий канал для пакетной передачи данных. Если АС ранее получила служебное сообщение P_PROTECT PDU, чтобы прекратить свою радиопередачу, то эта передача должна быть повторно разрешена в заменяющем рабочем канале (вновь назначенном) для передачи пакетных данных. Заменяющий канал передачи пакетных данных должен быть с той же конфигурацией таймслотов (одинарный или двойной таймслот). Если рабочий канал для передачи пакетных данных поддерживает несколько одновременных вызовов, то служебные сообщения в PDU предоставления канала должны быть переданы для каждой АС или разговорной группы, которые активны в данный момент (участвуют в вызове) в рабочем канале.

9.4.2.6 Разъединение канала в режиме "Передача пакетных данных"

ТС должна разъединить (отключить) передачу пакетных данных служебным сообщением P_CLEAR PDU с установленными IE в значении Target_Address, соответствующем ALLMSI. Поскольку PDU является неподтвержденным, PDU может быть повторен на канальном уровне стека протоколов [уровень 2 (DLL)].

9.4.2.7 Разъединение конкретной АС или разговорной группы в режиме "Передача пакетных данных"

ТС должна быть способна разъединить АС, участвующие в вызове в рабочем канале, в следующих случаях:

а) ТС принимает служебное сообщение P_MAINT PDU (Maint_Kind соответствует DISCON);

б) ТС определяет, что пакетный вызов завершен:

1) для элементарных сеансов передачи данных по окончании времени ожидания данных для принятого сообщения данных (от шлюза или АС) с использованием услуги переноса информации DLL "Подтверждаемые данные",

2) для элементарных сеансов передачи данных по передаче или получению сообщения данных (от шлюза или АС) с использованием услуги переноса информации DLL "Неподтверждаемые данные".

Ответом ТС на соответствующее служебное сообщение P_MAINT PDU (Maint_Kind-DISCON) является служебное сообщение P_CLEAR PDU.

ТС может выборочно разъединять АС путем передачи P_AHOY PDU с IE, указанными в таблице 82.

Таблица 82

IE P_AHOY для разъединения АС в рабочем канале

в режиме "Передача пакетных данных"

IE	Длина, бит	Комментарий
Service_Options_Mirror	7	000 0000₂
Service_Kind_Flag	1	0₂ указывает, что получатель - с индивидуальным адресом
ALS	1	0₂ - не применяется
G/I	1	0₂ - адресом получателя является индивидуальный ID АС
Appended_Blocks	2	00₂
Service_Kind	4	Отмена услуги вызова - 1111₂ Service_Kind_Flag - 0₂
Target_Address	24	Индивидуальный адрес АС
Source_Address или Gateway	24	TSI

Разрешенным ответом является P_ACKU PDU (Message_Accepted).

Для любых случаев, кроме приема служебного сообщения P_MAINT PDU, ТС передает P_CLEAR PDU. Поскольку этот PDU является неподтвержденным, он может быть повторен на канальном уровне стека протоколов [уровень 2 (DLL)].

9.4.3 Процедуры АС для рабочего канала в режиме "Передача пакетных данных"

9.4.3.1 Получение АС служебного сообщения о проверке радиодоступности с АС P_AHOY PDU в режиме "Передача пакетных данных"

Если АС получает служебное сообщение P_AHOY PDU на свой индивидуальный адрес с IE, указанными в таблице 82, то она должна ответить служебным сообщением P_ACKU PDU (Reason соответствует MS_Accepted).

Если АС получает служебное сообщение P_AHOY PDU на соответствующий ей адрес разговорной группы, предварительно переданный в PDU предоставления канала, который направил эту АС в рабочий канал, то она должна ответить служебным сообщением P_ACKU PDU (Reason соответствует MS_Accepted).

9.4.3.2 АС принимает запрос проверки аутентификации в режиме "Передача пакетных данных"

Процедуры аутентификации идентичны процедурам аутентификации, описанным в 7.4.9.3 с учетом замены в ответе аутентификации служебных сообщений с C_ACKU PDU на PDU P_ACKU.

9.4.3.3 Запрет/разрешение передачи АС в режиме "Передача пакетных данных"

Если АС принимает служебное сообщение P_PROTECT PDU (Protect_Kind соответствует DIS_PTT), направленное на ее индивидуальный адрес или на адрес разговорной группы, предварительно переданное служебным сообщением в PDU предоставления канала, или ALLMSID (см. А.5), то АС должна прекратить свою передачу.

Если АС принимает служебное сообщение P_PROTECT (Protect_Kind соответствует EN_PTT), направленное на ее индивидуальный адрес или на адрес разговорной группы, ранее переданное служебным сообщением в PDU предоставления канала, или ALLMSID (см. А.5), то АС разрешено работать на передачу.

9.4.3.4 Прием АС блоков данных протокола предоставления канала в режиме "Передача пакетных данных"

Если АС принимает служебное сообщение в PDU предоставления канала, направленное на ее индивидуальный адрес или на адрес разговорной группы, предварительно переданное в PDU предоставления канала, то она должна перестроиться на новый назначенный физический/логический канал. Если PTT был запрещен до получения PDU предоставления канала, то PTT должен быть заново разрешен в случае если эта АС не была получателем широковещательного вызова, а также вызова к ALLMSIDL, ALLMSIDZ или ALLMSID (см. А.5).

9.4.3.5 Завершение вызова в режиме "Передача пакетных данных"

АС может завершить вызов путем передачи нескольких служебных сообщений P_MAINT PDU (Maint_Kind соответствует DISCON). Давая команду в TSCC о завершении вызова, АС должна передать служебные сообщения P_MAINT PDU, затем вернуться к процедурам обнаружения TSCC (предполагается, что выбранный TSCC - это TSCC, который передал вызов в рабочий канал).

Альтернативно для простых сеансов передачи данных АС может просто покинуть рабочий канал и вернуться к процедурам обнаружения TSCC. Такой сценарий может быть осуществлен:

а) после того, как АС передаст неподтверждаемые данные;

б) после того, как АС получит неподтверждаемые данные;

в) после того, как АС передаст подтверждаемые данные и получит подтверждение ACK L2;

г) после того, как АС получит подтверждаемые данные и передаст подтверждение ACK L2;

д) после того, как АС передаст подтверждаемые данные и завершит все повторные попытки (полные и/или SARQ) без получения подтверждения ACK.

9.4.3.6 АС принимает служебное сообщение P_CLEAR PDU

Если АС принимает служебное сообщение P_CLEAR PDU, то она должна отказаться от назначенного ей рабочего канала и перейти к TSCC, определенному служебным сообщением PDU номера логического канала в физическом канале.

9.4.3.7 АС принимает избирательный отбой P_AHOY PDU

Если АС принимает индивидуально адресованный P_AHOY PDU, IE Service_Kind соответствует 1111₂, а Service_Kind_Flag соответствует 0₂, то АС должна отправить P_ACKU PDU (Reason соответствует MS_Accepted), покинуть рабочий канал и вернуться к процедурам обнаружения TSCC (предполагается, что первоначально выбранный TSCC - это TSCC, который передал вызов в рабочий канал).

Если АС принимает IE P_AHOY PDU, Service_Kind соответствует 1111₂, Service_Kind_Flag соответствует 1₂, направленный на адрес разговорной группы, предварительно переданный в PDU предоставления канала разговорной группы, то АС должна отправить PACKU (Reason соответствует MS_Accepted), покинуть рабочий канал и вернуться к процедурам обнаружения TSCC (предполагается, что первоначально выбранный TSCC - это TSCC, который передал вызов в рабочий канал).

9.4.3.8 Тайм-аут в рабочем канале в режиме "Передача пакетных данных"

АС должна запустить несколько таймеров, пока она активна в рабочем канале пакетных данных:

а) таймер неактивности.

АС должна измерить продолжительность времени, когда она не способна обнаружить надлежащее качество сигнала. Если АС не способна обнаружить надлежащее качество сигнала в течение времени работы TV_Inactive, то она должна предположить, что вызов был завершен, и вернуться к процедурам обнаружения TSCC без отправки какой-либо сигнализации прекращения вызова (предполагается, что выбранный TSCC - это TSCC, который передал вызов в рабочий канал);

б) таймер текущего вызова.

Если истекает время таймера вызова общей полезной нагрузки пакетных данных T_PACKET_TIMER, то АС должна последовательно передать количество (N_Maint) блоков данных протокола P_MAINT PDU, затем вернуться к процедурам обнаружения TSCC (предполагается, что выбранный TSCC - это TSCC, который передал вызов в рабочий канал). Если АС посылает данные, когда истекает время таймера вызова общей полезной нагрузки передачи пакетных данных, АС должна передать PDU "Прерыватель данных с LC" (TD_LC PDU) перед передачей блоков данных протокола P_MAINT PDU.

9.5 Передача прикладных данных службой передачи данных по протоколу IP

9.5.1 Общие положения

С помощью интернет-протоколов UDP/IPv4 можно осуществлять передачу всех типов прикладных данных. Основные приложения, которые поддерживают обмен текстовыми сообщениями и местоположением, дополнительно определены в следующих ниже пунктах.

9.5.2 Обмен текстовыми сообщениями

Текстовые сообщения должны использовать кодировку символов UTF-16BE (см. [5]) в плоскости 0 (основная многоязычная плоскость, BMP). В процессе обмена используется порт 5016 UDP стандартной радиосети. Рекомендуется, чтобы порт UDP был сконфигурирован таким образом, чтобы устранить конфликты при подключении к уже установленной сети.

9.5.3 Местоположение

Для процедуры определения местоположения необходимо использовать протокол обработки информации о местоположении, приведенный в ГОСТ Р 71586.2.

10 Требования к формату пакета стека протоколов уровня 2 в транкинговом режиме

Требования по содержанию полей пакетов уровня 2 стека протоколов для рабочих каналов соответствуют описанным в разделе 15.

Для TSCC содержание полей пакетов 3 уровня стека протоколов описаны в разделе 16.

10.1 Сокет вокодера

Требования по построению сокета вокодера определены в ГОСТ Р 71586.1-2024 (подраздел 10.2).

10.2 Особенности применения CACH

CACH передается только в нисходящем канале. Он предоставляет информацию о кадрировании и доступе для пакетов, а также низкоскоростных данных. CACH не связан с каналами 1 или 2, однако является для них общим.

Для рабочих каналов CACH описан в ГОСТ Р 71586.2-2024 (подраздел 10.3).

Для транкинговых каналов CACH описан в 6.9.2.

10.3 Обратный канал

10.3.1 Выделенный (inbound) пакет обратного канала, передаваемый в восходящем канале транкинговой станции

Выделенный пакет обратного канала, передаваемый в восходящем канале ТС, описан в ГОСТ Р 71586.2-2024 (пункт 10.4.1).

10.3.2 Встроенный пакет (RC), передаваемый в нисходящем канале ретранслятора

Встроенный пакет обратного канала, передаваемый в нисходящем канале ТС, описан в ГОСТ Р 71586.2-2024 (пункт 10.4.2).

11 Требования к сигнализации в транкинговом режиме в рабочих каналах

11.1 Типы и структура сообщений LC в транкинговом режиме в рабочих каналах

В транкинговом режиме в рабочих каналах для сигнализации в восходящем и нисходящем канале могут использоваться два типа сообщений:

- полное сообщение LC (Full LC);

- короткое сообщение LC (Short LC).

Структура и передача на уровне 2 и уровне 3 сообщения Full LC в режиме с ретрансляцией в восходящем и нисходящем канале соответствует прямому режиму и описана в ГОСТ Р 71586.1-2024 (подраздел 11.1, пункт 11.2.1), а прерыватель (сообщение об окончании) речевого вызова - в ГОСТ Р 71586.1-2024 (пункт 11.2.3).

11.1.1 Встроенная сигнализация в речевом вызове нисходящего канала

Передача встроенной сигнализации в нисходящем канале в режиме ретрансляции предназначена для обеспечения позднего вхождения в связь при передаче речевых вызовов, при этом данные LC заголовка повторяются в виде встроенного LC в течение всего периода передачи речевой информации.

Передача встроенной сигнализации в пакетах A - E соответствует прямому режиму и описана в ГОСТ Р 71586.1-2024 (пункт 7.2.1). Речевой пакет A всегда содержит речевую синхрогруппу. Четыре речевых пакета (от B до E) речевого суперкадра содержат сообщение встроенной сигнализации.

В рабочих каналах в транкинговом режиме в нисходящем канале пакет F содержит сигнализацию RC в соответствии с требованиями, описанными в ГОСТ Р 71586.2-2024 (пункт 10.4.2), или ретранслирует информацию в восходящем канале, связанную с конфиденциальностью.

11.2 Структура сообщения для передачи шифрованных данных (PI DT PDU) в рабочих каналах

Сообщение PI DT PDU, содержащее информацию о шифровании передаваемых данных в текущем вызове, а также порядок его передачи соответствуют прямому режиму и описаны в ГОСТ Р 71586.1-2024 (подраздел 11.2). При работе в режиме ретрансляции зашифрованные данные между АС передаются через ретранслятор (АС в режиме ретрансляции) без обработки (перешифрования).

11.3 Структура CSBK

11.3.1 Введение

Общая структура CSBK, которое содержит информационное поле (96 бит), приведена в ГОСТ Р 71586.1-2024 (подраздел 11.4).

11.3.2 Формирование CSBK

Формирование CSBK длиной 96 бит описано в ГОСТ Р 71586.1-2024 (пункт 11.4.2).

11.4 Структура MBC

Назначение, структура и порядок формирования для передачи по радиоканалу MBC от АС приведены в ГОСТ Р 71586.1-2024 (подраздел 11.6).

12 Функциональные возможности

12.1 Ограничение времени передачи

АС, соответствующие настоящему комплексу стандартов, должны иметь таймер T_TO, который ограничивает время передачи каждой отдельной передаваемой единицы информации. Такой таймер должен быть установлен в значение, указанное в ГОСТ Р 71586.1-2024 (приложение Д) при каждом нажатии тангенты PTT, и отсчитываться в обратном порядке до нуля.

При работе АС в транкинговом режиме значение времени данного таймера может быть изменено.

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

Примечание - Остановка передачи речи по окончании текущего суперкадра плюс одного пакета позволяет АС закончить передачу речи в нормальном режиме работы путем завершения суперкадра и отправки "Прерывателя с LC".

12.2 Сервис FNS

Сервис FNS должен использоваться, когда АС направляется запрос, содержащий сигнализацию о функциональной возможности, которую она не поддерживает. Сигнализация неподдерживаемой функции, полученная АС, должна быть передана служебным сообщением в PDU, который включает в себя SFID и CSBKO, которые АС не поддерживает. Подробно сервис описан в ГОСТ Р 71586.1-2024 (подраздел 12.3).

13 Требования к общим услугам в транкинговом режиме

13.1 Услуги и функциональные возможности

Услуги и функциональные возможности, определенные в настоящем стандарте, могут быть использованы для транкинговых сетей и называются "набор функций по умолчанию". Этот набор выделяется для SFID. Настоящий стандарт позволяет производителям определять и реализовывать "частные" наборы функций, которые содержат дополнительные услуги и функциональные возможности, которые могут не поддерживаться оборудованием, содержащим только стандартный набор функций. Кроме того, SFID PDU могут содержать опциональные IE конкретного производителя.

"Стандартный набор функций" включает в себя следующие услуги и функциональные возможности:

а) общие услуги:

1) контроль и управление доступом к АС с использованием TSCC и протокола произвольного доступа,

3) поиск TSCC,

4) разрешение на использование системы,

5) механизм передачи унифицированных данных для поддержки сервиса коротких данных UDT, услуги передачи данных через шлюзы supplementary_user и extended_addresses,

6) трансляция системных параметров в АС,

7) аутентификация АС,

8) сервис FNS,

9) система динамического контроля мощности АС,

10) контроль состояния АС;

б) основные голосовые услуги:

1) обслуживание группового вызова,

2) обслуживание индивидуального вызова;

в) вторичные голосовые услуги:

1) услуга вызова всех АС (All_MS),

2) услуга широковещательной передачи голосового вызова,

3) услуга вызова "режим открытого голосового канала";

г) основные услуги при работе с данными:

1) служба передачи "коротких" данных,

2) служба пакетной передачи данных;

д) состояние службы:

1) состояние службы доставки,

2) состояние службы опроса;

е) дополнительные услуги:

1) услуга передачи данных Supplementary_user (дополнительные данные, передаваемые в качестве части первичного установления вызова),

2) блокировка и разблокировка АС,

3) приведение АС в неработоспособное состояние ("уничтожение"),

4) услуга ответа на вызов,

5) услуга отмены/окончания вызова.

Для описания услуг и функциональных возможностей при необходимости используются диаграммы, на которых показаны специфические моменты использования TSCC и передачи пользовательской информации.

13.2 Адреса устройств

13.2.1 Адреса АС

АС в транкинговых сетях должны быть персонифицированы по меньшей мере одним индивидуальным идентификатором. АС могут состоять в одной или нескольких группах.

Примечание - Индивидуальные и групповые адреса АС занимают выделенное адресное пространство, как описано в ГОСТ Р 71586.1-2024 (приложение А). Исходя из этого, возможны варианты, когда группа будет иметь такое же числовое значение адреса, как индивидуальная АС.

13.2.2 Адреса для идентификации услуг и шлюзов

Протокол транкинговой сети определяет дополнительные адреса для идентификации услуг и шлюзов в блоках PDU, которыми обмениваются между собой АС и ТС порядком, описанным в ГОСТ Р 71586.1-2024 (приложение А). Адреса, предписанные для транкинговой сети, определены в А.5.

13.3 Обычные/транкинговые системы

Многие из обычных операций, таких как выбор физического канала радиосвязи, автоматизированы транкинговым протоколом:

а) один сайт транкинговой сети состоит из АС, связанных с одним адресом транкинговой станции;

б) многозоновые транкинговые системы состоят из множества АС, связанных с множеством ТС.

ТС работают по одному или нескольким физическим каналам. Каждая ТС может быть сконфигурирована с одним или двумя TSCC. Два TSCC могут находиться в одном или в отдельных физических каналах. Для эффективного распределения нагрузки транкинговая сеть может разделять множество АС между несколькими TSCC.

Для полностью регулируемой системы по меньшей мере один канал должен быть сконфигурирован как TSCC для управления АС, а также трансляции параметров системы. Доступ к АС строго контролируется в TSCC.

Асинхронный режим доступа разрешает АС доступ по протоколу LBT.

13.4 Возможности регистрации АС

АС при перемещении по многозоновой сети может находиться в зоне обслуживания нескольких транкинговых станций. Регистрация представляет собой метод, с помощью которого система может определить, в каком сайте или группе сайтов расположена АС в пределах многозоновой сети. Эта информация позволяет избежать поиска АС по всей сети и, следовательно, сокращает время установки вызовов и уменьшает загрузку TSCC.

Регистрация также может быть использована единой системой сайта, чтобы определить, когда АС активны и способны принимать вызовы.

Регистрация, кроме того, позволяет передавать параметры энергосбережения между АС и системой.

При выключении АС или внесения пользователем изменений, касающихся выбора сети, АС может попытаться отменить регистрацию. Если процедура отмены регистрации не будет завершена в течение заданного промежутка времени (T_dereg), то этот процесс прекращается.

13.5 Услуги транкинговой сети

13.5.1 Типы вызовов

Транкинговая станция ППР может распределять ресурсы для целого ряда услуг, в том числе для индивидуальных вызовов, групповых вызовов, вызовов по подключенной линии, а также предоставлять услугу передачи данных.

Групповые вызовы могут быть ограничены сетью, подсоединенной к одному сайту или ко множеству связанных сайтов. Конкретные сайты, участвующие в вызове, могут быть определены сетью с помощью ручной настройки или автоматического выбора.

С использованием услуги передачи данных во время установления соединения между АС и сетью могут быть отправлены AD для опроса или предоставления дополнительной информации по методу UDT. Ниже приведены примеры отправки таких данных:

а) восходящая передача (extended_addressing) цифр набора номера для звонков на PSTN, PABX или точечных адресов для IP-шлюзов;

б) передача информации о местоположении АС, с использованием данных, собранных с устройств, информация о совместимости которых приведена в [1];

в) передача любых дополнительных данных о пользователе;

г) нисходящая передача CLI для звонков с PSTN, PABX, LINE и диспетчерских шлюзов к вызываемой(ым) АС;

д) нисходящая передача IP-адреса вызываемой АС.

13.5.2 Инициирование вызовов АС

АС может инициировать вызов к любой из следующих вызываемых сторон:

а) индивидуальная АС;

б) терминальное устройство, подключенное к линии, включая внутренние линии учрежденческих PABX или PSTN;

в) разговорная группа или все АС в системе.

Система должна направлять отказ в ответ на любые вызовы, запрашивающие использование не соответствующих для конкретного адреса назначения услуг и функциональных возможностей.

Во время фазы установления соединения в TSCC может передаваться информация обратно вызывающей стороне, чтобы обозначить ход выполнения вызова. Например, информация о причинах каких-либо задержек в установке вызова или причине сбоя вызова.

13.5.3 Прием вызовов подвижной станцией АС

13.5.3.1 Прием вызовов АС. Введение

АС может принимать вызовы от АС или терминального устройства, подключенного к линии (это может быть, например, PABX или PSTN).

Кроме того, некоторые блоки служебных сообщений в PDU могут создаваться самой ТС.

АС должна послать уведомление об отказе в обслуживании любого индивидуального вызова, запрашивающего несоответствующие или недопустимые услуги и функциональные возможности.

При вызове адрес вызывающей АС должен передаваться к вызываемому абоненту. В случае вызова от выделенной линии, соединяемой с шлюзами, такими как PABX или PSTN, протокол позволяет доставлять к АС информацию об адресе источника (примером может служить CLI-информация с внутренней линии PABX или PSTN).

Входящие вызовы могут быть адресованы непосредственно АС или разговорной группе.

Вызываемая АС может передавать различные виды подтверждений приема в зависимости от того, отвечает ли пользователь на вызов, входит ли вызов в стек вызовов или следует оставить голосовое сообщение. Подтверждения могут быть использованы вызывающей АС для информирования своего пользователя о процессе вызова. Это может быть информативный текст и/или какое-либо обусловленное предупреждение пользователю.

13.5.3.2 Прием АС индивидуальных вызовов

Общие положения

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

Для голосовых вызовов система может использовать стратегии OACSU и FOACSU, описанные ниже.

OACSU

ТС определяет, когда должен быть назначен канал передачи трафика. Назначение может быть осуществлено в любое время после установления вызова, инициированного ТС. Канал выделяется для вызова вне зависимости от того, есть ответ от вызываемого абонента или нет.

FOACSU

Канал передачи трафика назначается только тогда, когда вызываемый абонент-участник однозначно ответил на вызов. После ответа абонента сеть инициирует назначение канала передачи трафика к АС.

13.5.3.3 АС, принимающая вызовы для разговорной группы

АС может входить в любое количество разговорных групп.

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

13.5.3.4 Прием АС вызовов на All_MS

В данном стандарте зарезервировано три идентификатора для организации широковещательных вызовов, а именно: ALLMSID - вызов всех АС в системе, ALLMSIDL - вызов всех АС в сайте, в котором находится вызывающая АС, ALLMSIDZ - вызов всех АС в некотором подмножестве сайтов системы. Возможность и способы организации вызовов для данных ID на стороне АС и TSCC определяет производитель.

13.6 Организация физического канала связи

13.6.1 Организация физического канала связи. Введение

Этот протокол использует физический стек протоколов уровня 1 в соответствии с 6.2 и должен соответствовать требованиям ГОСТ Р 71586.2-2024 (раздел 17).

13.6.2 Распределение радиочастот

Транкинговая сеть поддерживает несколько способов определения номинала частоты рабочего канала для АС.

Физические каналы радиосвязи могут быть определены:

а) фиксированным логическим частотным планом канала, в соответствии с которым частота передатчика и приемника отображается/переносится на номер логического канала. Протокол транкинговой сети позволяет организовать до 4094 таких логических/физических каналов;

б) и/или способом, согласно которому абсолютные частоты передатчика и приемника указаны в блоках PDU, которые передаются между ТС и АС через радиоинтерфейс.

13.6.3 CC

CC присутствует в EMB и общих пакетных данных, обеспечивает разграничение доступа АС к каналам связи в действующих радиосетях и позволяет защитить каналы от внутриканальных помех, создаваемых в результате возможного перекрытия зон обслуживания различных систем радиосвязи (или разных сайтов одной системы), использующих одни и те же физические радиоканалы. В транкинговых сетях АС должны соблюдать принцип распределения по CC (см. 7.3.3.5).

В транкинговых сетях физические каналы назначаются автоматически, при соблюдении условия, что CC ТС выделен для каждого физического канала и разрешен для АС. Процедура получения доступа к каналу, который может быть использован АС в транкинговой сети, описана в 7.2.2.4.

При активном использовании рабочих каналов ТС TSCC должен автоматически игнорировать любые сообщения, передающиеся в восходящем направлении и не имеющие соответствующий конкретной ТС CC.

13.7 TDMA-пакет и структура канала

Приведенное решение основано на структуре двухслотового TDMA, описанной в ГОСТ Р 71586.2-2024 (подраздел 6.5).

Логические каналы разделены на две категории:

- TSCC, по которым передаются блоки сигнализации;

- рабочие каналы, предназначенные для передачи пользовательской информации (речь и пользовательские данные).

В целом АС работают с временными параметрами в соответствии с ГОСТ Р 71586.2-2024 (подраздел 7.2), указанными в TSCC с использованием служебного сообщения C_ALOHA PDU. Полный дуплекс возможен для вызовов по линии, соединяющей терминалы с использованием многостанционного доступа с временным разделением TDMA в соответствии с ГОСТ Р 71586.2-2024 (подпункт 7.2.4.3), тем самым позволяя АС передавать и получать информацию в одном временном интервале. АС, которые передают информацию в физическом канале с временными параметрами со смещением, должны быть уведомлены идентификатором, переданным АС во время установления вызова.

Обобщенная диаграмма обмена между TSCC и АС показана на рисунке 69, где изображены таймслоты для физических каналов TDMA.

Рисунок 69 - Ключевые моменты для TSCC

Ниже приведены пояснения по ключевым моментам, специфическим для транкинга уровня 3 и показанным на рисунке 69.

Во время работы TSCC в двух нисходящих логических каналах осуществляется непрерывная передача, даже при отсутствии информации для отправки. Если какой-либо из логических каналов был сконфигурирован в качестве TSCC и этот TSCC находится в режиме ожидания, то постоянно передается информация управления доступом и широковещательные параметры для АС.

Пакеты каналов 1 и 2 в восходящем направлении смещены на 30 мс во времени относительно пакетов каналов 1 и 2 в нисходящем направлении. Такая схема позволяет использовать один и тот же номер канала в поле идентификатора канала в нисходящем CACH, когда речь идет о восходящих и нисходящих направлениях каналов.

TSCC должен передавать используемые временные параметры. Может быть сконфигурировано два независимых TSCC или один TSCC плюс один рабочий канал. TSCC может временно выполнять функции рабочего канала. Унифицированные операции синхронизации позволяют сократить время установления вызова. Смещение операций синхронизации позволяет реализовать один дуплексный вызов от одной АС к другой на одной несущей или дуплексные вызовы соединительной линии в одном таймслоте.

Как показано на рисунке 69, пакет произвольного доступа в восходящем канале, обозначенном "А", должен быть подтвержден путем отправки PDU по нисходящему каналу. Это подтверждение может быть передано в таймслоте "Б", однако протокол может отложить подтверждение, чтобы обеспечить вычислительные или сетевые задержки.

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

Ответ АС в таймслоте "Д" не может вступать в противоречие с другим пакетом случайного доступа, поскольку таймслот защищен путем соответствующей установки бита AT, если CACH занят. АС должна проверить этот бит, прежде чем сделать попытку произвольного доступа. Произвольный доступ не допускается, если AT = 1.

Нисходящий канал определяет CACH между пакетами TDMA, который управляет кадрированием, доступом к логическим каналам и обеспечивает низкоскоростной канал для сигнализации. Биты кадрирования CACH позволяют низкоскоростному каналу поддерживать все описанные в настоящем стандарте PDU.

13.8 Структура ТС

13.8.1 Введение в структуру ТС

Протокол транкинговой сети управляет доступом АС и предоставлением услуг с помощью TSCC. АС запрашивают оказание услуг с помощью случайного доступа. Протокол транкинговой сети обеспечивает широкий выбор конфигураций для соответствия специальным и общим требованиям радиочастотного спектра. Исходящий TSCC может быть:

а) непрерывно передающим таймслоты, предлагающие доступ АС, транслирующие широковещательные системные параметры и управляющие ресурсами, доступными для АС;

б) передающим информацию согласно перечислению а), но с восстановлением рабочего канала, когда другие рабочие каналы не доступны;

в) неактивным до момента активации с помощью соответствующего пакета АС при совместном использовании радиочастотного спектра.

13.8.2 Пример индивидуального голосового вызова

13.8.2.1 Индивидуальный вызов с использованием OACSU

Две АС, АС(А) и АС(Б) активно обрабатывают TSCC. АС(А) запрашивает услугу передачи речи к АС(Б). Перед тем, как рабочий канал назначается TSCC, система проверяет, что АС(Б) находится на радиосвязи и готова принять вызов. Если АС(Б) посылает положительный ответ о подтверждении приема [означающий, что АС(Б) примет вызов], то система распределяет полезную нагрузку канала для вызова.

На рисунке 70 описываются некоторые ключевые аспекты:

а) канал TDMA 2 назначен в качестве TSCC. Канал TDMA 1 находится в режиме ожидания;

б) когда TSCC не имеет текущих вызовов, он будет передавать служебные сообщения в PDU системного управления или системные широковещательные служебные PDU на все АС, слушающие TSCC. АС могут прослушивать канал TDMA 1 с целью измерения частоты ошибок, но не должны использовать любую информацию из этих блоков PDU;

в) АС(А) делает запрос на обслуживание в точке "А" с использованием выровненного канала в соответствии с ГОСТ Р 71586.2-2024 (пункт 7.2.1);

г) TSCC отправляет служебное сообщение AHOY PDU (точка "Б"), которое требует подтверждения, на имя АС(Б);

д) АС(Б) отвечает подтверждением в точке "В";

е) в точке "Г" TSCC посылает служебное сообщение в PDU предоставления канала на имя АС(А) и АС(Б). IE логического канала в PDU предоставления канала указывает АС определенный физический и логический канал. PDU предоставления канала не подтверждается, поэтому на "Д" происходит повторение для надежности. TSCC может повторно передавать PDU предоставления канала последовательно или через несколько таймслотов;

ж) в этом конкретном примере TSCC выбран для вызова логическим каналом 1 данного физического канала. Поэтому логический канал 1 переключается из режима ожидания в режим рабочего канала сразу после того, как TSCC передает первый PDU предоставления канала;

и) поскольку каждый TDMA-пакет занимает 30 мс, то в лучшем случае время установки индивидуального вызова уровня 3 составляет 210 мс.

- Сообщения "свободен" (TDMA-канал 1)

- Сообщения TSCC (TDMA-канал 2)

- Рабочий канал (TDMA-канал 1)

Рисунок 70 - Установление индивидуального вызова OACSU

13.8.2.2 Индивидуальный вызов с использованием FOACSU

Две АС, АС(А) и АС(Б) активно прослушивают TSCC. АС(А) запрашивает услугу передачи речи к АС(Б). Перед тем, как рабочий канал назначается TSCC, система проверяет, что АС(Б) находится в радиоконтакте и готова принять вызов. Если АС(Б) посылает положительное подтверждение, то она предупреждает об этом пользователя. Только тогда, когда АС(Б) отвечает на вызов, система выделяет для вызова рабочий канал.

На рисунке 71 описываются некоторые ключевые аспекты:

а) канал TDMA 2 назначен в качестве TSCC. Канал TDMA 1 находится в режиме ожидания;

б) АС(А) делает запрос на обслуживание в точке "А" с использованием установленной TSCC синхронизации [типы синхронизации определены в ГОСТ Р 71586.2-2024 (пункт 7.2.1)];

в) TSCC отправляет служебное сообщение AHOY PDU (точка "Б"), которое требует подтверждения, на имя АС(Б);

г) АС(Б) отвечает подтверждением в точке "Б". АС(Б) предупреждает пользователя;

д) TSCC посылает PDU подтверждения зеркально (точка "Г") обратно в АС(А), чтобы указать АС(А), что АС(Б) предупреждена;

е) пользователь активно отвечает на вызов в точке "Г", заставляя АС(Б) отправить ответный запрос TSCC. TSCC посылает PDU предоставления канала на адреса АС(А) и АС(Б). Предупреждение, сгенерированное в точке "В", отменяется;

ж) IE логического канала в PDU предоставления канала направляет АС к определенному физическому и логическому каналу. PDU предоставления канала не подтверждается, поэтому этот PDU для надежности повторяется на "Е". TSCC может повторно передавать PDU предоставления канала последовательно или через несколько таймслотов.

В данном примере TSCC выбирает для вызова отдельный физический канал радиосвязи. Конкретные физические и логические IE канала TDMA отражены в PDU предоставления канала. Для надежности PDU предоставления канала повторяются.

- Сообщения "свободен"

TDMA канал-1

- Сообщения TSCC

TDMA канал-2

- Рабочий канал

TDMA канал-1

- Получатель сообщения

Рисунок 71 - Установление индивидуального вызова FOACSU

13.8.3 Пример вызова разговорной группы

Для вызова разговорной группы, если АС(Б) находится в радиоконтакте, промежуточный этап проверки не требуется, так что в оптимальном случае время установления вызова составит 90 мс.

Рисунок 72 иллюстрирует процедуру установления вызова разговорной группы. АС(Б) является участником этой разговорной группы. Если АС(Б) находится в радиодоступе, то для установления вызова разговорной группы промежуточный этап проверки не требуется, так что лучшее время установки вызова составляет 90 мс на TSCC с выровненной синхронизацией и 120 мс на TSCC со смещенной синхронизацией.

В данном примере TSCC выбирает для вызова отдельный физический канал радиосвязи. Конкретные физические и логические IE канала TDMA присутствуют в PDU предоставления канала. Для надежности PDU предоставления канала повторяются.

Ключевые аспекты описанной процедуры:

а) когда оба рабочих канала находятся в режиме ожидания, не требуется никакая радиопередача;

б) если назначается по меньшей мере один рабочий канал, то передатчик активируется и один логический канал передает полезную нагрузку для вызова. Другой логический канал остается бездействующим;

в) хотя в примере на рисунке 72 таймеры и пакеты в рабочем канале синхронизируются с TSCC, такое требование не установлено.

- Сообщения "свободен" (TDMA-канал 1)

- Сообщения TSCC (TDMA-канал 2)

- Рабочий канал (TDMA-канал 1)

Рисунок 72 - Пример установления вызова разговорной группы

14 Требования к протоколу PDP

14.1 Протокол PDP - общие положения

Данный раздел определяет требования к PDP. Посылка данных произвольной длины передается по радиосвязи на основе технологии передачи IP-пакетов.

Оборудование, соответствующее настоящему комплексу стандартов, поддерживает протоколы третьего уровня, описанные в ГОСТ Р 71586.1-2024 (раздел 14):

- интернет-протокол;

- протокол передачи данных;

- протокол передачи сообщений.

14.2 Формат AD

14.2.1 Механизм UDT транкинговой сети

Если в режиме передачи коротких данных требуется переслать данные, длина которых превышает максимальную, предусмотренную этим режимом, то может быть использована процедура передачи AD. В этой процедуре для передачи используется TSCC и общий для всех услуг передачи метод - процедура UDT.

Процедура UDT предназначена для следующих услуг:

а) услуга передачи AD:

1) передача адресов назначения, которые подключены через шлюзы системы, в восходящем направлении,

2) восходящая передача цифр номеров PSTN и PABX от АС,

3) восходящая передача адресов IPv4/IPv6,

4) восходящая передача информации о местоположении АС NMEA (см. [1]),

5) передача удаленных адресов, подключенных через шлюзы системы, по нисходящему каналу,

6) передача CLI от сетей PSTN и PABX по нисходящему каналу,

7) передача по нисходящему каналу информации об адресах IPv4/IPv6 из IP-сетей,

8) передача адреса источника в ряде стандартных и собственных форматов по нисходящему каналу,

9) передача данных о местоположении АС NMEA (см. [1]) по нисходящему каналу,

10) передача AD пользователя как часть другой услуги,

11) восходящая передача адресов/цифр для услуги переадресации вызова,

12) передача адресов разговорной группы для услуги DGNA,

13) восходящая передача адресов разговорной группы для услуги присоединения разговорной группы;

б) услуга передачи коротких данных;

в) услуга опроса коротких данных.

Примечание - При оказании услуги, приведенной в перечислении а), бит SF в UDT Head PDU должен быть установлен в значение 1₂. Для услуг, указанных в перечислениях б) и в), бит SF в UDT Head PDU устанавливается в значение 0₂.

Структура передачи данных одинакова для передачи с использованием нисходящего направления TSCC и передачи с использованием восходящего направления TSCC. Для передачи данных с использованием процедуры UDT должно применяться сообщение UDT PDU. Первый блок заголовка показан на рисунке 73. Этот блок содержит адреса отправителя и получателя, формат передаваемых данных и формат UDT, который указывает на то, какая услуга поддерживается. Для осуществления передачи данных в заголовке может содержаться до четырех добавочных блоков данных. Все блоки UDT должны передаваться последовательно.

Рисунок 73 - Заголовок UDT

IE Appended_Blocks указывает количество UDT блоков, которые добавляются в этот заголовок. Для блока с UDT данными, адресованного индивидуальной АС, IE A обозначает, ожидается ли ответ на этот многоблочный UDT.

На рисунке 74 приведен пример использования процедуры UDT службой передачи коротких данных с помощью механизма UDT. Короткие данные используют методы сохранения и пересылки, а также процедуры, описанные в 8.1.

	Aloha		Ahoy		Заголовок UDT для добавленных данных		Aloha M = 24 Address = NULL
	RQ произвольного доступа		Подтверждение		Добавленные данные		Получатель сообщения

Рисунок 74 - Короткий информационный вызов, использующий

процедуру UDT

Фазы загрузки и выгрузки UDT-данных, описанные в этих пунктах, показаны слева на рисунке. В этом примере блоки UDT состоят из заголовка и одного добавочного блока.

На рисунке 75 показана процедура установки вызова от АС к PABX/PSTN. Такие вызовы требуют осуществления передачи набранного адреса системе. В этом примере передачи данных UDT состоит из заголовка и одного добавочного блока, содержащего до 20 набранных цифр.

	Aloha		Ahoy		Заголовок UDT для добавленных данных		Предоставление канала
	Запрос произвольного доступа		Подтверждение		Добавленные данные Набранные цифры		Получатель сообщения

Рисунок 75 - Вызов от АС к PABX/PSTN, использующий

процедуру UDT

На рисунке 76 показан еще один пример вызова из PSTN. TSCC выбирает CLI (идентификатор вызывающего абонента) для отправки получателю в рамках настройки этого вызова. IE Service_Kind передается в заголовке, поэтому принимающая АС должна определить, что вызов - восходящий и он поступил из PSTN. Так как Service_Kind известен получателю, вторичной функцией процедуры передачи данных с помощью UDT является то, что он может служить в качестве проверки радиосвязи. Только при положительном подтверждении (C_ACKU) от АС вызов считается состоявшимся.

	Aloha		Ahoy		Заголовок UDT для добавленных данных		Предоставление канала
	Запрос произвольного доступа		Подтверждение		Добавленные данные - Данные GPS		Получатель сообщения

Рисунок 76 - Вызов от PSTN/PABX, использующий процедуру UDT

На рисунке 77 показано, что AD пользователя могут быть частью вызова. АС(А) отправляет свои навигационные данные как часть процедуры установления речевого вызова. В этом случае АС должна указать, что AD пользователя доступны в IE Service_Options путем установки Supplementary_Data в значение 1₂. TSCC загружает AD пользователя и передает данные получателю. Этот UDT дополнительно служит для проверки радиодоступности.

	Aloha		Ahoy		Заголовок UDT для добавленных данных		Предоставление канала
	Получатель сообщения		Подтверждение		Добавленные данные - Цифры CLI

Рисунок 77 - Процедура UDT, передающая AD

14.2.2 Формат AD - общие положения

Формат AD определен в приложении В. Стандартные форматы следующие:

а) формат адреса - AD содержит адреса объекта профессиональной подвижной радиосвязи;

б) двоичный формат - AD содержит двоичные данные;

в) формат BCD - AD содержат закодированные цифры;

г) семибитный закодированный текст - AD - это текст, закодированный с использованием ISO семибитного набора символов (см. [2]);

д) восьмибитный закодированный символ - AD - это символ, закодированный с использованием ISO восьмибитного набора символов (см. [3]);

е) формат местоположения NMEA (см. [1]) - AD кодируются специально для данных о местоположении NMEA (см. [1]);

ж) формат шестнадцатибитового UTF-16BE Unicode (см. [6]).

14.2.3 Структура блоков UDT

Структура блоков UDT описана в ГОСТ Р 71586.1-2024 в следующих подпунктах:

- заголовок: 14.3.2.9;

- блоки данных, кроме последнего: 14.3.3.2;

- последний блок данных: 14.3.3.6.

14.2.4 Контент UDT для услуг, предоставляющихся в нисходящем канале

Процедура UDT нисходящего канала может быть вызвана как часть службы транкинговой сети ППР. PDU заголовка UDT содержит все параметры для UDT АС или разговорной группы. Данные, которые должны быть получены, содержатся в TSCC и IE, представленных в таблице 83.

Таблица 83

IE нисходящего направления TSCC для передачи UDT данных

Механизм UDT нисходящего канала
Услуга	Операция	Service_Kind	Блоки PDU нисходящего канала					Ответ АС, заголовок и данные
			Флаг AD	UDT-формат	A (см. ГОСТ Р 71586.1)	Адрес получателя или шлюз	Адрес источника или шлюз
Речевой вызов от PSTN к отдельной АС	Отправить CLI из PSTN	Услуга индивидуального речевого вызова (0000₂)	1₂	BCD (0010₂)	0₂ опция	Адрес АС назначения	PSTNI/PSTNDI	Нет
					1₂ опция			ACK, NACK
Речевой вызов от PABX к отдельной АС	Отправить CLI из PABX	Услуга индивидуального речевого вызова (0000₂)	1₂	BCD (0010₂)	0₂ опция	Адрес АС назначения	PABXI/PABXDI	Нет
					1₂ опция			ACK, NACK
Речевой вызов от PSTN к разговорной группе	Отправить CLI из PSTN	Услуга вызова разговорной группы (0001₂)	1₂	BCD (0010₂)	0₂	Назначение. Разговорная группа	PSTNI	Нет
Речевой вызов от PABX к разговорной группе	Отправить CLI из PABX	Услуга вызова разговорной группы (0001₂)	1₂	BCD (0010₂)	0₂	Назначение. Разговорная группа	PABXI	Нет
Речевой вызов от АС к отдельной АС	Отправить NMEA информацию из источника АС	Услуга индивидуального речевого вызова (0000₂)	1₂	NMEA формат (0101₂)	0₂ опция	Адрес АС назначения	Источник АС	Нет
					1₂ опция			ACK, NACK
Речевой вызов от АС к отдельной АС	Отправить дополнительный текст PDU как часть установки вызова	Услуга индивидуального речевого вызова (0000₂)	1₂	Семибитный текст (0011₂)	0₂ опция	Адрес АС назначения	Источник АС	Нет
					1₂ опция			ACK, NACK
Короткий информационный вызов от АС к АС	Нисходящая фаза коротких данных	Индивидуальные короткие данные (0100₂)	0₂	UDT_Format	1₂	Адрес АС назначения	Источник АС	ACK, NACK
Короткий информационный вызов от Диспетчера к АС	Нисходящая фаза коротких данных	Индивидуальные короткие данные (0100₂)	0₂	UDT_Format	1₂	Адрес АС назначения	DISPATI	ACK, NACK
Отправка адреса переадресации звонящему	См. 7.5.6
Услуга DGNA	См. 7.5.7

IE блоков PDU в заголовках UDT приведены в таблице 84.

Таблица 84

IE блоков PDU в заголовках UDT

Название	Назначение
UDT_Format	Определяет формат данных, передаваемых в добавочных блоках данных многоблочного UDT Если нисходящий UDT, являющийся второй фазой, предшествует восходящему UDT, то UDT_Format должен быть скопирован из заголовка восходящего UDT
Appended_Blocks	Определяет количество добавочных блоков данных, которые объединяются в заголовке
Supplementary_Flag	Определяет: - содержит ли этот заголовок UDT данные для инициированной пользователем услуги (например, передача коротких данных); - содержит ли этот заголовок UDT AD пользователя, поддерживая другую услугу
A (см. ГОСТ Р 71586.1)	Определяет, ожидает ли TSCC ответ от этой выгрузки UDT: - если UDT обращается к отдельной АС и UDT поддерживает передачу AD пользователя, то этот IE нужно либо установить, либо очистить для службы коротких данных, в этом случае IE должен быть установлен в значение 1₂ - ожидается ответ; - если UDT обращается к разговорной группе, то IE UDT должен быть установлен в значение 0₂ - ответ не ожидается.
Service_Kind	Определяет, поддерживается ли услуга механизмом UDT
Target_Address или Gateway	Индивидуальный адрес АС разговорной группы или всего блока
Source_Address или Gateway	Адрес АС-источника для подключения к внутреннему номеру PABX и обслуживания исходящих от PABX услуг, PSTNI для услуг от ТФОП, IPI для услуг от IP-сети.

15 Требования к блоку данных протокола канального уровня (уровень 2) в транкинговом режиме

15.1 Описание PDU DLL - общие положения

PDU DLL обеспечивают передачу пользовательской информации (речь, пользовательские сообщения и данные) в рабочих каналах или в совмещенном TSCC (невыделенном, Non-Dedicated) при выполнении им функции рабочего канала (в случае приостановки им выполнения функции TSCC и перехода в режим передачи пользовательских данных).

15.2 PDU для речевого пакета, общий пакет данных в транкинговом режиме

Требования к блокам пользовательских данных PDU для речевого пакета и общего пакета данных описаны в ГОСТ Р 71586.1-2024 (подраздел 15.2).

В рабочих каналах в транкинговом режиме на канальном уровне используются дополнительные синхрогруппы и PDU, которые соответствуют ГОСТ Р 71586.2-2024 (раздел 15).

15.2.1 PDU кадровой синхронизации в транкинговом режиме

Кадровая синхронизация при передаче информации в транкинговом режиме в TSCC и рабочих каналах соответствует требованиям, определенным в ГОСТ Р 71586.2-2024 (пункт 15.2.1).

15.2.2 PDU TACT

PDU TACT передается в CACH и соответствует требованиям, описанным в ГОСТ Р 71586.2-2024 (пункт 15.2.2).

15.2.3 PDU RC

PDU RC используется для RC сигнализации в восходящем направлении рабочих каналов. Требования к PDU RC описаны в ГОСТ Р 71586.2-2024 (пункт 15.2.3).

15.2.4 PDU короткого сообщения управления соединением (PDU SHORT LC)

Использование и требования к PDU SHORT LC описаны в ГОСТ Р 71586.2-2024 (пункт 15.2.4).

15.3 Описание данных, связанных с PDU

Требования к PDU уровня 2, связанные с протоколом пакетной передачи данных, которые применяются в радиоинтерфейсе, описаны в ГОСТ Р 71586.1-2024 (подраздел 15.3).

15.4 Кодирование IE уровня 2

15.4.1 Общие положения

Основные требования к IE, содержащимся в PDU уровня 2, приведены в ГОСТ Р 71586.1-2024 (подраздел 15.4).

В транкинговом режиме также предъявляется ряд дополнительных требований, описанных ниже и соответствующих каналу встроенной сигнализации или CACH.

15.4.2 CC

Использование IE CC является средством разграничения доступа АС к транкинговым каналам связи, как описано в 7.3.3.5. Требования по использованию IE CC приведены в ГОСТ Р 71586.2-2024 (пункт 15.5.2).

15.4.3 PowI

Управление мощностью АС транкинговой станцией описано в 7.4.15.

Требования к IE PowI, передаваемому в канале RC, определены в ГОСТ Р 71586.2-2024 (пункт 15.5.3).

15.4.4 AT

IE AT передается в CACH. Он указывает, каким будет следующий таймслот в восходящем канале: свободным или занятым. Требования к IE AT описаны в ГОСТ Р 71586.2-2024 (пункт 15.5.4).

15.4.5 TCh

IE TCh передается в CACH, указывает номер таймслота в нисходящем или восходящем направлении TSCC и рабочих каналов и описан в ГОСТ Р 71586.2-2024 (пункт 15.5.5).

15.4.6 Проверочные элементы TACT

"Проверочные элементы TACT" имеют длину 3 бита, формируемые при кодировании (7,4)-кодом Хэмминга, описание которого приведено в ГОСТ Р 71586.1-2024 (пункт Б.10).

15.4.7 Проверочные элементы RC

"Проверочные элементы RC" имеют длину 21 бит, формируемые при кодировании кодом-произведением (32,11), описание которого приведено в ГОСТ Р 71586.1-2024 (пункт Б.4).

16 Описание блоков управления уровня управления вызовами стека протоколов (уровень 3)

16.1 Описание PDU CCL в транкинговом режиме - общие положения

В настоящем разделе изложены требования к блокам управления PDU и кодированию в них IE CCL стека протоколов (уровень 3) для предоставления транкинговых услуг и функциональных возможностей. Раздел содержит описание PDU и их IE.

Структура PDU в настоящем разделе представлена в таблицах. Состав таблиц:

- столбец "IE" с наименованиями содержащихся в нем элементов;

- столбец "Длина, бит", определяющий длину элемента в битах;

- столбец "Комментарий" с данными об IE. Элементы должны передаваться в порядке, определенном в ГОСТ Р 71586.1.

16.2 Типы PDU CCL (уровень 3) стека протоколов, их назначение и структура

16.2.1 PDU управления уровня 3 - общие положения

В настоящем разделе описываются PDU уровня 3 с учетом специфики транкинговой сети. Эти PDU используются для передачи данных (служебные и пользовательские сообщения) и управления. Они используют единый формат пакета и могут содержать два типа элементов:

- элементы, зависящие от содержания сообщения, передаваемые во встроенной сигнализации. Такие элементы являются видимыми для канального уровня (уровня 2) стека протоколов и могут быть использованы любой АС (которая способна их декодировать) независимо от адресации. Эти элементы (поле в пакете "Тип слота", EMB) зависят от элемента "Тип передаваемого сообщения". Некоторые из них генерируются уровнем 2 стека протоколов при передаче пользовательской информации (речь, данные) в процессе формировании полного сообщения, тогда как другие генерируются только на уровне 3 стека протоколов;

- функциональные элементы. Элементы относятся только к IE CCL стека протоколов и обрабатываются АС, которым они адресованы.

Если оба типа элементов передаются совместно в PDU, то они описаны в настоящем разделе отдельно.

16.2.2 Управляющий блок сигнализации (CSBK/MBC/UDT) PDU транкингового режима

16.2.2.1 Управляющий блок сигнализации (CSBK/MBC/UDT) PDU транкингового режима - общая характеристика

Радиопакеты, передаваемые с использованием структуры управляющих блоков служебных сообщений CSBK/MBC и UDT PDU, формируют основу стека протоколов уровня 3. Управляющие PDU сигнализации (служебные сообщения) классифицируются по функциональности в зависимости от их назначения.

Для CCL стека протоколов транкинговой сети ППР требуется три типа пакетов данных [описание приведено в ГОСТ Р 71586.1-2024 (подраздел 10.3)], которые используют одноблочную пакетную передачу на базе CSBK, многоблочную передачу с использованием процедуры MBC, передачу с использованием механизма передачи UDT и представлены служебными сообщениями в таблицах:

- в таблице 85 - PDU для нисходящего направления TSCC;

- в таблице 86 - PDU для восходящего направления TSCC;

- в таблице 87 - PDU для нисходящего направления рабочего канала;

- в таблице 88 - PDU для восходящего направления рабочего канала.

Таблица 85

Структура PDU, передаваемых в нисходящем направлении TSCC

Класс	Имя	Функция	Код операции	Тип информации	Значение
Broadcast (вещание)	PV_GRANT	Предоставление конфиденциального речевого канала (логический)	11 0000₂	CSBK	0011₂
Broadcast (вещание)	PV_GRANT	Предоставление конфиденциального речевого канала (абсолютный)	11 0000₂	Заголовок MBC	0100₂
Broadcast (вещание)	TV_GRANT	Предоставление речевого канала разговорной группы (логический)	11 0001₂	CSBK	0011₂
Broadcast (вещание)	TV_GRANT	Предоставление речевого канала разговорной группы (абсолютный)	11 0001₂	Заголовок MBC	0100₂
Broadcast (вещание)	BTV_GRANT	Предоставление вещательного речевого канала разговорной группы (логический)	11 0010₂	CSBK	0011₂
Broadcast (вещание)	BTV_GRANT	Предоставление вещательного речевого канала разговорной группы (абсолютный)	11 0010₂	Заголовок MBC	0100₂
Broadcast (вещание)	PD_GRANT	Предоставление конфиденциального канала передачи данных (логический)	11 0011₂	CSBK	0011₂
Broadcast (вещание)	PD_GRANT	Предоставление конфиденциального канала передачи данных (абсолютный)	11 0011₂	Заголовок MBC	0100₂
Broadcast (вещание)	TD_GRANT	Предоставление канала передачи данных разговорной группы (логический)	11 0100₂	CSBK	0011₂
Broadcast (вещание)	TD_GRANT	Предоставление канала передачи данных разговорной группы (абсолютный)	11 0100₂	Заголовок MBC	0100₂
Broadcast (вещание)	PV_GRANT_DX	Предоставление дуплексного конфиденциального речевого канала (логический)	11 0101₂	CSBK	0011₂
Broadcast (вещание)	PV_GRANT_DX	Предоставление дуплексного конфиденциального речевого канала (абсолютный)	11 0101₂	Заголовок MBC	0100₂
Broadcast (вещание)	PD_GRANT_DX	Предоставление дуплексного конфиденциального канала передачи данных (логический)	11 0110₂	CSBK	0011₂
Broadcast (вещание)	PD_GRANT_DX	Предоставление дуплексного конфиденциального канала передачи данных (абсолютный)	11 0110₂	Заголовок MBC	0100₂
Broadcast (вещание)	CG_AP	Добавочный MBC предоставления канала	Значение из заголовка	Продолжение MBC	0101₂
Broadcast (вещание)	C_MOVE	Move (перемещение) TSCC (логический)	11 1001₂	CSBK	0011₂
Broadcast (вещание)	C_MOVE	Move TSCC (абсолютный)	11 1001₂	Заголовок MBC	0100₂
Broadcast (вещание)	MV_AP	Move добавочного MBC	11 1001₂	Продолжение MBC	0101₂
Broadcast (вещание)	C_ALOHA	Aloha (Приветствие)	01 1001₂	CSBK	0011₂
Broadcast (вещание) (C_BCAST)	Ann_WD_TSCC	Объявление/Удаление TSCC (логический)	11 1000₂	CSBK	0011₂
	Ann_WD_TSCC	Объявление/Удаление TSCC (абсолютный)		Заголовок MBC	0100₂
	CallTimer_Parms	Установление параметров таймера вызова		CSBK	0011₂
	Vote_Now	Предложение смены TSCC		CSBK	0011₂
	Local_Time	Широковещательная передача местного времени		CSBK	0011₂
	MassReg	Массовая регистрация широковещательных вызовов		CSBK	0011₂
Broadcast (вещание) (C_BCAST	Chan_Freq	Сообщение о частотном соотношении логического/физического канала	11 1000₂	Заголовок MBC	0100₂
Broadcast (вещание) (C_BCAST	Adjacent Site	Широковещательная передача информации о соседнем сайте	11 1000₂	CSBK	0011₂
Broadcast (вещание)	BC_AP	Широковещательная передача добавочных MBC	10 1000₂	Продолжение MBC	0101₂
Приветствие Ahoy (AHOY)	AHOY	Блокировка/разблокировка/"уничтожение". Опрос АС. Проверка АС	01 1100₂	CSBK	0011₂
Подтверждение	C_ACKD C_NACKD C_QACKD C_WACKD	Положительное подтверждение. Отрицательное подтверждение. Вызов поставлен в очередь. Ожидание следующих PDU.	10 0000₂	CSBK	0011₂
Унифицированная передача данных	C_UDTHD	Заголовок унифицированной передачи данных	01 1010₂	Заголовок UDT	0110₂
Унифицированная передача данных	UDT	Заголовок унифицированной передачи данных	-	Неподтвержденное продолжение информации	0111₂

Таблица 86

Структура PDU, передаваемых в восходящем направлении TSCC

Класс	Имя	Функция	Код операции	Тип информации	Значение
Произвольный доступ	C_RAND	Запросы произвольного доступа	01 1111₂	CSBK	0011₂
Ответ на приглашение	C_ACKVIT	Ответ на приглашение	01 1110₂	CSBK	0011₂
Подтверждение	C_ACKU C_NACKU	Подтверждение	10 0001₂	CSBK	0011₂
Унифицированная передача данных	C_UDTHU	Заголовок унифицированной передачи данных	01 1011₂	Заголовок UDT	0110₂
Унифицированная передача данных	UDT	Добавочные данные унифицированной передачи данных	-	Неподтвержденное продолжение информации	0111₂

Таблица 87

Структура PDU, передаваемых в нисходящем направлении

рабочего канала

Класс	Имя	Функция	Код операции	Тип информации	Значение
Broadcast (вещание)	P_GRANT	Предоставление канала (логическое)	Значение из предоставления канала	CSBK	0011₂
Broadcast (вещание)	P_GRANT	Предоставление канала (абсолютное)	Значение из предоставления канала	Заголовок MBC	0100₂
Broadcast (вещание) (сброс)	P_CLEAR	Очистить рабочий канал от вызова. АС возвращается к TSCC	10 1110₂	CSBK	0011₂
Broadcast (вещание) (защищенный)	P_PROTECT	Защита канала	10 1111₂	CSBK	0011₂
Приветствие AHOY	P_AHOY	Проверка АС	01 1100₂	CSBK	0011₂
Подтверждения	P_ACKD P_NACKD	Положительное подтверждение. Отрицательное подтверждение	10 0010₂	CSBK	0011₂

Таблица 88

Структура PDU, передаваемых в восходящем направлении

рабочего канала

Класс	Имя	Функция	Код операции	Тип информации	Значение
Произвольный доступ	P_RAND	Произвольный доступ, включая запрос	01 1111₂	CSBK	0011₂
Подтверждение	P_ACKU	Подтверждение	10 0011₂	CSBK	0011₂
Поддержка	P_MAINT	Поддержка вызова	10 1010₂	CSBK	0011₂

На рисунке 78 показана структура служебных сообщений, передаваемых с помощью PDU в нисходящем направлении TSCC.

Рисунок 78 - Структура и иерархия служебных

сообщений, передаваемых с использованием

PDU в нисходящем направлении TSCC

Верхний уровень структуры, представленной на рисунке 86, описывающий основной режим работы, определен в таблице 89.

Таблица 89

Структура верхнего уровня нисходящего направления TSCC,

передаваемых с использованием CSBK/MBC/UDT

Элемент уровня	Комментарий
Broadcast (вещание)	Блоки PDU, отправленные через TSCC для управления доступом к каналу, передают АС или в разговорные группы рабочих каналов и оповещают об информации от ТС
Ahoys	Блоки PDU, являющиеся запросами и требующие ответа от АС и также подтверждения разрешение доступа произвольного канального доступа
Подтверждения	Предоставление ответа UDT
UDT	Передача данных между TSCC и АС

Структура служебных сообщений, передаваемых с помощью PDU в восходящем направлении TSCC, показана на рисунке 79.

Рисунок 79 - Структура и иерархия служебных сообщений,

передаваемых с использованием PDU в восходящем

направлении TSCC от АС к ТС

Основные режимы работы, определяемые служебными сообщениями с использованием PDU в восходящем направлении TSCC, и способы их реализации показаны в таблице 90.

Таблица 90

Структура верхнего уровня АС по восходящему направлению TSCC

Элемент уровня	Комментарий
Произвольный доступ	Используется для доступа к каналу и запросу услуг транкингового режима
Подтверждения	Для предоставления ответов на Ahoys и UDT
UDT	Для передачи данных между TSCC и АС

Структура служебных сообщений, передаваемых в нисходящем направлении рабочего канала, показана на рисунке 80.

Рисунок 80 - Структура и иерархия служебных сообщений,

передаваемых в PDU нисходящего направления TSCC

с использованием процедуры одноблочного или

многоблочного сообщений CSBK/MBC в рабочих каналах

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

Таблица 91

Структура верхнего уровня служебных сообщений, передаваемых

АС с использованием PDU в восходящем направлении

рабочего канала в сигнализации с использованием CSBK

Элемент уровня	Комментарий
Broadcast (вещание)	Блоки PDU, отправленные ТС к АС для управления рабочим каналом, переключают АС на новый рабочий канал. Блоки аннулируют участников процедуры и защищают канал во время перерывов между передачами АС
Приветствия Ahoys	Предназначенные для АС, проводящей запросы, и требующие ответа
Подтверждения	Для предоставления ответа на Ahoys и UDT

Структура и иерархия служебных сообщений, передаваемых с использованием PDU в восходящем направлении рабочего канала, представлена на рисунке 81.

Рисунок 81 - Структура и иерархия служебных сообщений,

передаваемых с использованием PDU в восходящем

направлении рабочего канала

Основные служебные сообщения, передаваемые с использованием PDU в восходящем направлении рабочего канала, и их иерархия приведены на рисунке 89.

Структура верхнего уровня этих служебных сообщений показана в таблице 92.

Таблица 92

Структура верхнего уровня служебных сообщений АС,

передаваемых в восходящем направлении рабочего канала

Элемент уровня	Комментарий
Произвольный доступ	Используется для запроса включенных речевых услуг
Подтверждения	Для предоставления ответов на Ahoys и UDT
Поддержка	Для предоставления PDU поддержки вызова

16.2.2.2 Служебные сообщения, передаваемые в нисходящем направлении TSCC с использованием механизмов CSBK/MBC/UDT

PDU предоставления канала с использованием CSBK/MBC

PDU предоставления конфиденциального речевого канала с использованием CSBK/MBC

Нулевой и первый байты PI PDU предоставления конфиденциального речевого канала с использованием CSBK соответствуют структуре LC, как показано в ГОСТ Р 71586.1-2024 (рисунок 59), при этом CSBKO заменяет FLCO. Байты со второго по девятый содержат специальную информацию о предоставлении конфиденциального речевого канала, приведенную в таблице 93. Предоставление конфиденциального речевого канала передается ТС и не требует ответа. PDU предоставления конфиденциального речевого канала передается по TSCC или в рабочих каналах как CSBK или как MBC.

Для IE Physical Channel Number:

а) если значение = 0000 0000 0000₂, то номер физического канала - неверный;

б) если значение составляет от 0000 0000 0001₂ до 1111 1111 1110₂, то номер физического канала показывает Logical Channel Number для частоты физического передатчика и приемника. PDU предоставления конфиденциального речевого канала передается по TSCC как CSBK;

в) если значение = 1111 1111 1111₂, то номер физического канала определяет MBC, в котором абсолютная частота передатчика и приемника определена во втором блоке, который связан с этим блоком [определено в 16.2.2.2 ("Параметры PDU предоставления канала (CG_AP) добавочного MBC")].

Служебные сообщения предоставления конфиденциального речевого канала разговорной группы указаны на рисунке 82.

Рисунок 82 - Служебные сообщения предоставления

конфиденциального речевого канала

Таблица 93

Содержание PDU предоставления конфиденциального

речевого канала

IE	Длина, бит	Комментарий
Зависящие от сообщения элементы
LB	1	Этот бит должен быть установлен на 1₂ для одноблочного сообщения CSBK или на 0₂, если это заголовок MBC
PF	1	-
Функциональные элементы
CSBKO	6	Должен быть установлен на 11 0000₂
FID	8	Должен быть установлен на 0000 0000₂
Logical Physical Channel Number (номер логического физического канала)	12	Рабочий канал для вызова или индикатора, чья абсолютная частота передатчика и приемника определена в добавочном блоке CSBK
Logical Channel Number (номер логического канала)	1	0₂ - канал 1 с TDMA; 1₂ - канал 2 с TDMA
R	1	0₂ - зарезервировано
Emergency (экстренный вызов)	1	0₂ - неэкстренный вызов; 1₂ - экстренный вызов
Offset (смещение)	1	0₂ - рабочий канал использует синхронизацию с выравниванием; 1₂ - рабочий канал использует синхронизацию со смещением
Target_Address	24	Индивидуальный адрес АС вызываемой стороны или адрес шлюза
Source_Address	24	Вызывающая сторона или шлюз

Предоставление дуплексного конфиденциального речевого канала (PV_GRANT_DX) CSBK/MBC PDU

Нулевой и первый байты PDU предоставления дуплексного конфиденциального речевого канала CSBK преобразуются в структуру формата LC, как показано в ГОСТ Р 71586.1-2024 (рисунок 59), при этом CSBKO заменяет FLCO. Байты со второго по девятый содержат специальную информацию о предоставлении дуплексного конфиденциального речевого канала (см. таблицу 94). Служебные сообщения предоставления конфиденциального дуплексного речевого канала представлены на рисунке 83. Предоставление дуплексного конфиденциального речевого канала передается ТС и не требует ответа. PDU предоставления дуплексного конфиденциального речевого канала передается по TSCC или по рабочему каналу как CSBK или MBC. Для IE Physical Channel Number:

а) если значение = 0000 0000 0000₂, то номер физического канала - неверный;

б) если значение находится в пределах от 0000 0000 0001₂ до 1111 1111 1110₂, то номер физического канала представляет Logical Channel Number для физической частоты передатчика и приемника. Предоставление дуплексного конфиденциального речевого канала PDU передается по TSCC как CSBK;

в) если значение = 1111 1111 1111₂, то номер физического канала определяет MBC, в котором абсолютная частота передатчика и приемника определена во втором блоке этого MBC [определено в 16.2.2.2 ("Параметры PDU предоставления канала (CG_AP) добавочного MBC")].

Рисунок 83 - Служебные сообщения предоставления

конфиденциального дуплексного речевого канала

Таблица 94

Содержание PDU предоставления дуплексного

конфиденциального речевого канала

IE	Длина, бит	Комментарий
Зависящие от сообщения элементы
LB	1	Этот бит должен быть установлен на 1₂ для CSBK или на 0₂, если это заголовок MBC
PF	1	-
Функциональные элементы
CSBKO	6	Должен быть установлен на 11 0101₂
FID	8	Должен быть установлен на 0000 0000₂
Logical Physical Channel Number	12	Рабочий канал для вызова или индикатор того, что абсолютная частота передатчика и приемника определена в добавочном блоке CSBK
Logical Channel Number	1	0₂ - канал 1 с TDMA 1₂ - канал 2 с TDMA
R	1	0₂ - зарезервировано
Emergency	1	0₂ - неэкстренный вызов; 1₂ - экстренный вызов
Call Direction (направление вызова)	1	0₂ - адрес получателя принимает вызов от АС; 1₂ - адрес получателя вызывает АС
Target_Address	24	ID АС вызываемой стороны
Source_Address	24	ID АС вызывающей стороны
Примечание - Рабочие каналы предоставления дуплексного конфиденциального речевого канала всегда используют синхронизацию со смещением.

Служебные сообщения предоставления речевого канала разговорной группы (TV_GRANT), передаваемые с помощью PDU в CSBK/MBC

Нулевой и первый байты CSBK PDU предоставления речевого канала разговорной группы преобразуются в структуру формата LC, как показано в ГОСТ Р 71586.1-2024 (рисунок 59), при этом CSBKO заменяет FLCO. Байты со второго по девятый содержат специальную информацию о предоставлении речевого канала разговорной группы, приведенную в таблице 95. Предоставление речевого канала разговорной группы передается ТС и не требует ответа. PDU предоставления речевого канала разговорной группы передается по TSCC или рабочему каналу как CSBK или MBC.

Для IE Physical Channel Number:

а) если значение = 0000 0000 0000₂, то номер физического канала - неверный;

б) если значение находится в пределах от 0000 0000 0001₂ до 1111 1111 1110₂, то номер физического канала представляет Logical Channel Number для физической частоты передатчика и приемника. Предоставление речевого канала разговорной группы PDU передается по TSCC как CSBK;

Служебные сообщения предоставления конфиденциального речевого канала разговорной группы приведены на рисунке 84.

Рисунок 84 - Служебные сообщения предоставления

конфиденциального речевого канала разговорной группы

Таблица 95

Содержание PDU предоставления речевого канала

разговорной группы

IE	Длина, бит	Комментарий
Зависящие от сообщения элементы
LB	1	Этот бит должен быть установлен на 1₂ для одноблочного сообщения CSBK или на 0₂, если это заголовок MBC
PF	1	-
Функциональные элементы
CSBKO	6	Должен быть установлен на 11 0001₂
FID	8	Должен быть установлен на 0000 0000₂
Logical Physical Channel Number	12	Рабочий канал для вызова или индикатора, чья абсолютная частота передатчика и приемника определена в добавочном блоке CSBK
Logical Channel Number	1	0₂ - канал 1 с TDMA; 1₂ - канал 2 с TDMA
Late_Entry	1	0₂ - предоставление канала отправляется как часть процедуры установки вызова; 1₂ - предоставление канала отправляется после установки
Emergency	1	0₂ - неэкстренный вызов; 1₂ - экстренный вызов
Offset	1	0₂ - рабочий канал использует синхронизацию с выравниванием; 1₂ - рабочий канал использует синхронизацию со смещением
Destination_Address (адрес получателя)	24	Адрес разговорной группы АС
Source_Address	24	Вызывающая сторона или шлюз

Если Target_Address - это ALLMSIDL, ALLMSIDZ или ALLMSID (см. А.5), то АС должна определять этот PDU как вещание.

PDU предоставления вещательного речевого канала разговорной группы (BTV_GRANT) CSBK/MBC

Нулевой и первый байты CSBK PDU предоставления вещательного речевого канала разговорной группы преобразуются в структуру формата LC, как показано в ГОСТ Р 71586.1-2024 (рисунок 59), при этом CSBKO заменяет FLCO. Байты со второго по девятый содержат специальную информацию о предоставлении вещательного речевого канала разговорной группы, приведенную в таблице 96. PDU предоставления вещательного речевого канала разговорной группы представлено на рисунке 85. Предоставление вещательного речевого канала разговорной группы передается ТС и не требует ответа. PDU предоставления вещательного речевого канала разговорной группы передается по TSCC или по рабочему каналу как CSBK или MBC. Для IE Physical Channel Number:

а) если значение = 0000 0000 0000₂, то номер физического канала - неверный;

б) если значение находится в пределах от 0000 0000 0001₂ до 1111 1111 1110₂, то номер физического канала представляет Logical Channel Number для физической частоты передатчика и приемника. Предоставление вещательного речевого канала разговорной группы передается по TSCC как CSBK;

в) если значение = 1111 1111 1111₂, то номер физического канала определяет MBC, в котором абсолютная частота передатчика и приемника определена во втором блоке этого MBC.

Рисунок 85 - PDU предоставления вещательного речевого канала

разговорной группы

Таблица 96

Содержание PDU предоставления вещательного речевого канала

разговорной группы

IE	Длина, бит	Комментарий
Зависящие от сообщения элементы
LB	1	Этот бит должен быть установлен на 1₂ для одноблочного сообщения CSBK или на 0₂, если это заголовок MBC
PF	1	-
Функциональные элементы
CSBKO	6	Должен быть установлен на 11 0010₂
FID	8	Должен быть установлен на 0000 0000₂
Logical Physical Channel Number	12	Рабочий канал для вызова или индикатора, чья абсолютная частота передатчика и приемника определена в добавочном блоке CSBK
Logical Channel Number	1	0₂ - канал 1 с TDMA; 1₂ - канал 2 с TDMA
R	1	0₂ - предоставление канала отправляется как часть процедуры установки вызова; 1₂ - предоставление канала отправляется после установки вызова
Emergency_Flag	1	1₂ - экстренный вызов
Offset	1	0₂ - рабочий канал использует синхронизацию с выравниванием
Destination_Address	24	Адрес разговорной группы АС <1>
Source_Address	24	Вызывающая сторона или Gateway
<1> Адресами для всех вызовов являются ALLMSID, ALLMSIDZ и ALLMSIDL.

PDU CSBK/MBC предоставления конфиденциального канала передачи данных

PDU CSBK/MBC предоставления конфиденциального канала передачи данных (PD_GRANT)

Нулевой и первый байты PDU CSBK предоставления конфиденциального канала передачи данных приводятся к структуре формата LC, как показано в ГОСТ Р 71586.1-2024 (рисунок 59), при этом CSBKO заменяет FLCO. Байты со второго по девятый содержат специальную информацию о предоставлении конфиденциального канала передачи данных, приведенную в таблице 97. Предоставление конфиденциального канала передачи данных передается ТС и не требует ответа. PDU предоставления конфиденциального канала передачи данных передается по TSCC или по рабочему каналу как CSBK или MBC. Для IE Physical Channel Number:

а) если значение = 0000 0000 0000₂, то номер физического канала неверный;

б) если значение находится в пределах от 0000 0000 0001₂ до 1111 1111 1110₂, то номер физического канала представляет Logical Channel Number для физической частоты передатчика и приемника. PDU предоставления конфиденциального канала передачи данных передается по TSCC как CSBK;

Рисунок 86 - PDU предоставления конфиденциального канала

передачи данных

Таблица 97

Содержание PDU предоставления конфиденциального канала

передачи данных

IE	Длина, бит	Комментарий
Зависящие от сообщения элементы
LB	1	Этот бит должен быть установлен в значение 1₂ для одноблочного сообщения CSBK или на 0₂, если это заголовок MBC
PF	1	-
Функциональные элементы
CSBKO	6	Единичный элемент данных должен быть установлен в значение 11 0011₂; множественный элемент данных должен быть установлен в значение 11 0111₂
FID	8	Должен быть установлен в значение 0000 0000₂
Logical Physical Channel Number	12	Рабочий канал для вызова или индикатора, чья абсолютная частота передатчика и приемника определены в добавочном блоке CSBK
Logical Channel Number	1	0₂ - канал 1 с TDMA; 1₂ - канал 2 с TDMA
HI_RATE	1	0₂ - рабочий канал использует одинарный таймслот; 1₂ - рабочий канал использует двойной таймслот
Emergency	1	0₂ - неэкстренный вызов; 1₂ - экстренный вызов
Offset	1	0₂ - рабочий канал использует синхронизацию с выравниванием; 1₂ - рабочий канал использует синхронизацию со смещением
Destination_Address	24	Индивидуальный адрес АС вызываемой стороны или Gateway
Source_Address	24	Вызывающая сторона или Gateway

PDU предоставления дуплексного конфиденциального канала передачи данных (PD_GRANT_DX) CSBK/MBC

Нулевой и первый байты PDU предоставления дуплексного конфиденциального канала передачи данных CSBK PDU приводятся к структуре формата LC как показано в ГОСТ Р 71586.1-2024 (рисунок 59), при этом CSBKO заменяет FLCO. Байты со второго по девятый содержат специальную информацию о предоставлении дуплексного конфиденциального канала передачи данных, приведенную в таблице 98. PDU предоставления дуплексного конфиденциального канала передачи данных передается ТС и не требует ответа. PDU предоставления дуплексного конфиденциального канала передачи данных, как указано на рисунке 87, передается по TSCC или по рабочему каналу как CSBK или MBC. Для IE Physical Channel Number:

а) если значение = 0000 0000 0000₂, то номер физического канала - неверный;

б) если значение находится в пределах от 0000 0000 0001₂ до 1111 1111 1110₂, то номер физического канала представляет Logical Channel Number для физической частоты передатчика и приемника. Предоставление дуплексного конфиденциального канала передачи данных PDU передается по TSCC как CSBK;

Рисунок 87 - PDU предоставления дуплексного

конфиденциального канала передачи данных

Таблица 98

Содержание PDU предоставления дуплексного конфиденциального

канала передачи данных

IE	Длина, бит	Комментарий
Зависящие от сообщения элементы
LB	1	Этот бит должен быть установлен на 1₂ для одноблочного сообщения CSBK или на 0₂, если это заголовок MBC
PF	1	-
Функциональные элементы
CSBKO	6	Должен быть установлен на 11 0110₂
FID	8	Должен быть установлен на 0000 0000₂
Logical Physical Channel Number	12	Рабочий канал для вызова или индикатора, чья абсолютная частота передатчика и приемника определены в добавочном блоке
Logical Channel Number	1	0₂ - канал 1 с TDMA; 1₂ - канал 2 с TDMA
HI_RATE	1	0₂ - дуплексный рабочий канал всегда использует одиночный таймслот
Emergency	1	0₂ - неэкстренный вызов; 1₂ - экстренный вызов
Call Direction	1	0₂ - Destination_Address принимает вызов от АС; 1₂ - Destination_Address вызывает АС
Destination_Address	24	ID АС вызываемой стороны
Source_Address	24	ID АС вызывающей стороны
Примечание - Рабочие каналы, обеспечивающие предоставление дуплексного конфиденциального канала передачи данных, всегда используют режим синхронизации со смещением.

PDU CSBK/MBC предоставления канала передачи данных разговорной группы (TD_GRANT)

Нулевой и первый байты PDU CSBK предоставления канала передачи данных разговорной группы преобразуются в структуру формата LC, как показано в ГОСТ Р 71586.1-2024 (рисунок 59), при этом CSBKO заменяет FLCO. Байты со второго по девятый содержат специальную информацию о предоставлении канала передачи данных разговорной группы, приведенную в таблице 99. Предоставление канала передачи данных разговорной группы передается ТС и не требует ответа. PDU предоставления канала передачи данных разговорной группы передается по TSCC или по рабочему каналу как CSBK или MBC, как указано на рисунке 88. Для IE Physical Channel Number:

а) если значение = 0000 0000 0000₂, то номер физического канала неверный;

б) если значение находится в пределах от 0000 0000 0001₂ до 1111 1111 1110₂, то номер физического канала представляет Logical Channel Number для физической частоты передатчика и приемника. Предоставление канала передачи данных разговорной группы передается по TSCC как CSBK;

Рисунок 88 - PDU предоставления канала передачи данных

разговорной группы

Таблица 99

Содержание PDU предоставления канала передачи данных

разговорной группы

IE	Длина, бит	Комментарий
Зависящие от сообщения элементы
LB	1	Этот бит должен быть установлен в значение 1₂ для одноблочного сообщения CSBK или на 0₂, если это заголовок MBC
PF	1	-
Функциональные элементы
CSBKO	6	Однокомпонентные данные должны быть установлены в значение 11 0100₂
FID	8	Должен быть установлен в значение 0000 0000₂
Logical Physical Channel Number	12	Рабочий канал для вызова или индикатора, чья абсолютная частота передатчика и приемника определены в добавочном блоке CSBK
Logical Channel Number	1	0₂ - канал 1 с TDMA; 1₂ - канал 2 с TDMA
HI_RATE	1	0₂ - рабочий канал использует одинарный таймслот; 1₂ - рабочий канал использует двойной таймслот
Emergency	1	0₂ - неэкстренный вызов; 1₂ - экстренный вызов
Offset	1	0₂ - рабочий канал использует синхронизацию с выравниванием; 1₂ - рабочий канал использует синхронизацию со смещением
Destination_Address	24	Адрес разговорной группы АС
Source_Address	24	Вызывающая сторона или Gateway

Параметры PDU предоставления канала (CG_AP) добавочного MBC

Второй блок составного MBC предоставления канала приводится к формату, показанному в таблице 100. PDU CdefParms детально излагается в 16.3.20.8, и его физические характеристики приведены в приложении Б.

Таблица 100

Содержание PDU CG_AP добавленного MBC

IE	Длина, бит	Комментарий
Зависящие от сообщения элементы
LB	1	Этот бит должен быть установлен в значение 1₂, поскольку этот PDU прикрепляется к соответствующему заголовку MBC предоставления канала
PF	1	-
Функциональные элементы
CSBKO	6	Должен быть установлен на CSBKO первого блока MBC
R	4	0000₂
CC	4	Используется для назначения физического канала
Cdeftype	4	Значение CdefParms (см. 16.3.20.8)
R	2	00₂
CdefParms	58	IE, описывающие взаимосвязь частот логического/физического канала

PDU перемещения TSCC (C_MOVE) с использованием CSBK/MBC

Перемещение TSCC (C_MOVE) - общие положения

Нулевой и первый байты PDU C_MOVE, передаваемые в TSCC с использованием CSBK, преобразуются в структуру формата LC, как показано в ГОСТ Р 71586.1-2024 (рисунок 59), при этом CSBKO заменяет FLCO. Байты со второго по девятый содержат специальную информацию о Move TSCC, приведенную в таблице 101. PDU C_MOVE передается по TSCC как CSBK или MBC, как указано на рисунке 89. Для IE Physical Channel Number:

а) если значение = 0000 0000 0000₂, то номер физического канала неверный;

б) если значение находится в пределах от 0000 0000 0001₂ до 1111 1111 1110₂, то номер физического канала представляет Logical Channel Number для физической частоты передатчика и приемника. PDU C_MOVE передается по TSCC как CSBK;

в) если значение = 1111 1111 1111₂, то номер физического канала определяет MBC, в котором абсолютная частота передатчика и приемника определена во втором блоке этого MBC [см. 16.2.2.2 ("Параметры PDU перемещения (MV_AP) добавочного MBC")].

Рисунок 89 - PDU C_MOVE TSCC в общей структуре и иерархии

служебных сообщений, передаваемых в нисходящем

направлении TSCC

Таблица 101

Содержание PDU C_MOVE TSCC

IE	Длина, бит	Комментарий
Зависящие от сообщения элементы
LB	1	Этот бит должен быть установлен на 1₂ для одноблочного сообщения CSBK или на 0₂, если это заголовок MBC
PF	1	-
Функциональные элементы
CSBKO	6	Должен быть установлен на 11 1001₂
FID	8	Должен быть установлен на 0000 0000₂
R	9	0 0000 0000₂
"Маска"	5	-
R	5	-
Reg	1	Этот бит устанавливается, если TSCC требует от АС регистрации до того, как она становится активной
Backoff (Отклонение)	4	Номер отклонения
R	4	-
Номер физического канала	12	Рабочий канал для вызова или индикатор того, что абсолютная частота передатчика и приемника указаны в добавочном блоке CSBK
MS Address (Адрес АС)	24	Индивидуальный адрес АС

Параметры PDU перемещения (MV_AP) добавочного MBC

Второй блок Move MBC имеет структуру, приведенную в таблице 102. CdefParms, и детально рассмотрен в 16.3.20.8, а его физические характеристики приведены в приложении Б.

Таблица 102

Содержание PDU перемещения MV_AP добавочного MBC

IE	Длина, бит	Комментарий
Зависящие от сообщения элементы
LB	1	Этот бит должен быть установлен в значение 1₂, поскольку этот PDU добавлен к соответствующему заголовку Move MBC
PF	1	-
Функциональные элементы
CSBKO	6	Должен быть установлен на CSBKO первого блока MBC
R	4	0000₂
CC	4	CC используется для назначения физического канала
Cdeftype	4	Значение CdefParms (см. 16.3.20)
R	2	00₂
CdefParms	58	IE, описывающие частотное соотношение логического/физического канала

Служебные сообщения, передаваемые в PDU приветствия Aloha (C_ALOHA) с использованием CSBK

Нулевой и первый байты PDU C_ALOHA CSBK преобразуются в структуру формата LC как показано в ГОСТ Р 71586.1-2024 (рисунок 59), при этом CSBKO заменяет FLCO. Байты со второго по девятый содержат специальную информацию о PDU C_ALOHA, который приведен в таблице 103. PDU C_ALOHA передаются по TSCC. PDU приветствия C_ALOHA в общей структуре и иерархии служебных сообщений в нисходящем направлении TSCC представлено на рисунке 90.

Рисунок 90 - PDU приветствия C_ALOHA в общей структуре

и иерархии служебных сообщений в нисходящем направлении TSCC

Таблица 103

Содержание PDU приветствия C_ALOHA

IE	Длина, бит	Комментарий
Зависящие от сообщения элементы
LB	1	Этот бит должен быть установлен в значение 1₂
PF	1	-
Функциональные элементы
CSBKO	6	Должен быть установлен в значение 01 1001₂
FID	8	Должен быть установлен в значение 0000 0000₂
R	2	-
Синхронизация таймслотов сайта	1	0₂ - TSCC и все рабочие каналы являются несинхронизированными таймслотами; 1₂ - TSCC и все рабочие каналы являются синхронизированными таймслотами
Version	3	Проверка версии документа
Offset	1	0₂ - TSCC использует синхронизацию с выравниванием; 1₂ - TSCC использует синхронизацию со смещением
Active_Connection	1	0₂ - ТС не имеет связи с сетью; 1₂ - ТС имеет связь с сетью
"Маска"	5	-
Service Function	2	-
NRand_Wait	4	-
Reg	1	Этот бит устанавливается, если TSCC требует от АС регистрации до того, как она становится активной
Backoff	4	Номер отклонения
Код System Identity	16	-
MS Address	24	Индивидуальный адрес АС

PDU C_ALOHA содержит IE Version, который указывает АС, с которой система совместима (см. 16.3.33).

PDU объявления (C_BCAST), передаваемые с помощью CSBK/MBC

PDU объявления (C_BCAST) - общие положения

Нулевой и первый байты PDU C_BCAST преобразуются в структуру формата LC, как показано в ГОСТ Р 71586.1-2024 (рисунок 59), при этом CSBKO заменяет FLCO. Байты со второго по девятый содержат специальную информацию о PDU C_BCAST. Служебное сообщение PDU C_BCAST передается по TSCC как CSBK или как MBC.

PDU C_BCAST показан в таблице 104. PDU широковещания C_BCAST в общей структуре и иерархии служебных сообщений в нисходящем направлении TSCC представлены на рисунке 91.

Таблица 104

Содержание PDU C_BCAST

IE	Длина, бит	Комментарий
Зависящие от сообщения элементы
LB	1	Этот бит должен быть установлен в значение 1₂ для одноблочного сообщения CSBK или на 0₂, если это заголовок MBC
PF	1	-
Функциональные элементы
CSBKO	6	Должен быть установлен в значение 10 1000₂
FID	8	Должен быть установлен в значение 0000 0000₂
Announcement_type (Тип объявления)	5	Определяет, какие параметры системы передаются
Broadcast Parms 1 (Параметры вещания 1)	14	-
Reg	1	Этот бит устанавливается, если TSCC требует от АС регистрации до того, как она становится активной
Backoff	4	Номер отклонения
System Identity code (Идентификационный код системы)	16	-
Broadcast Parms 2 (параметры вещания 2)	24	-

Рисунок 91 - PDU C_BCAST в общей структуре и иерархии

служебных сообщений в нисходящем направлении TSCC

PDU C_BCAST определяет категорию объявления:

а) объявление/удаление TSCC;

б) установление параметров таймера вызова;

в) предложение смены TSCC;

г) объявление местного времени;

д) передача массовой регистрации;

е) объявление связи логического физического канала;

ж) объявление информации о соседнем сайте.

Параметры PDU вещания (BC_AP) добавочного MBC

PDU вещания BC_AP добавочного MBC (объявление логического/абсолютного частотного соотношения) приводится к структуре, как показано в таблице 105. При этом PDU CdefParms определен в 16.3.20.8 и его физические характеристики приведены в приложении Б.

Таблица 105

Содержание PDU вещания BC_AP добавочного MBC

IE	Длина, бит	Комментарий
Зависящие от сообщения элементы
LB	1	Этот бит должен быть установлен в значение 1₂, поскольку этот PDU прикреплен к соответствующему заголовку MBC объявления (Announcement MBC Header)
PF	1	-
Функциональные элементы
CSBKO	6	Должен быть установлен на первый блок MBC CSBKO
R	8	-
Cdeftype	4	-
R	2	-
CdefParms	58	IE, описывающие частотное соотношение логического/физического канала

PDU приветствия Ahoy (AHOY) CSBK

Нулевой и первый байты PDU приветствия AHOY CSBK преобразуются в структуру формата LC, как показано в ГОСТ Р 71586.1-2024 (рисунок 59), при этом CSBKO заменяет FLCO. Байты со второго по девятый содержат специальную информацию C_AHOY. Типичный PDU приветствия AHOY приведен в таблице 106, а в общей структуре и иерархии служебных сообщений в нисходящем направлении TSCC он представлен на рисунке 92. PDU AHOY передаются ТС в нисходящем направлении TSCC.

PDU AHOY передается ТС как CSBK.

Рисунок 92 - PDU приветствия AHOY в общей структуре

и иерархии служебных сообщений в нисходящем направлении TSCC

Таблица 106

Содержание PDU AHOY

IE	Длина, бит	Комментарий
Зависящие от сообщения элементы
LB	1	Этот бит должен быть установлен в значение 1₂
PF	1	-
Функциональные элементы
CSBKO	6	Должен быть установлен в значение 01 1100₂
FID	8	Должен быть установлен в значение 0000 0000₂
Service_Options_Mirror	7	- <1>
Service_Kind_Flag	1	Значение зависит от Service_Kind
ALS	1	0₂ - вызывающая сторона не требует ALS; 1₂ - вызывающая сторона требует ALS <1>
G/I	1	0₂ - адрес получателя - ID индивидуальной АС; 1₂ - адрес получателя - разговорная группа
Appended_Blocks [Status(2)]	2	При запросе к АС на отправку UDT с количеством блоков добавочных данных <1>
Service_Kind	4	Услуги, для которых C_AHOY поддерживается
Target_Address	24	Адрес вызываемой АС или разговорной группы
Source_Address или Gateway	24	Адрес вызывающей АС, шлюза или значение запроса аутентификации
<1> Для услуги статуса Appended_Blocks содержат два наименее значимых бит значения статуса, а Service_Options_Mirror содержат 5 наиболее значимых бит значения статуса. Примечание - ALS применим только для речевого вызова индивидуальной АС.

PDU подтверждения ответа (C_ACKD) TSCC CSBK

Нулевой и первый байты PDU подтверждения ответа (C_ACKD) CSBK преобразуются в структуру формата LC, как показано в ГОСТ Р 71586.1-2024 (рисунок 59), при этом CSBKO заменяет FLCO. Байты со второго по девятый содержат специальную информацию о подтверждении ответа. Универсальный (обобщенный) PDU подтверждения ответа приведен в таблице 107, в общей структуре и иерархии служебных сообщений в нисходящем направлении TSCC он представлен на рисунке 93.

Примечание - Подтверждения ответа передаются как ТС, так и АС.

Рисунок 93 - PDU подтверждения ответа ТС в общей структуре

и иерархии служебных сообщений в нисходящем направлении TSCC

Таблица 107

Содержание PDU подтверждения ответа ТС

IE	Длина, бит	Комментарий
Зависящие от сообщения элементы
LB	1	Этот бит должен быть установлен в значение 1₂
PF	1	-
Функциональные элементы
CSBKO	6	Должен быть установлен в значение 10 0000₂
FID	8	Должен быть установлен в значение 0000 0000₂
Response_Info	7	Дополнительная информация в ответе
Reason Code	8	Код причины
R	1	Этот бит должен быть установлен в значение 0₂
Target_Address	24	Индивидуальный адрес АС, инициирующей запрос
Additional_Information (Source_Address) [дополнительная информация (адрес источника)]	24	Адрес запрашиваемого назначения или шлюз

PDU подтверждения ответа подразделяются на классы:

- C_ACKD - положительное подтверждение (есть ответ);

- C_NACKD - отрицательное подтверждение (нет ответа);

- C_QACKD - постановка в очередь;

- C_WACKD - промежуточное подтверждение.

PDU заголовка нисходящей фазы UDT (C_UDTHD)

Этот PDU - многоблоковый UDT, приведенный к формату, показанному в таблице 108, а в общей структуре и иерархии служебных сообщений в нисходящем направлении TSCC он представлен на рисунке 94. Количество добавочных блоков данных UDT определяется в IE UAB.

Формат добавочных данных UDT приведен в приложении Б.

Примечание - Заголовки UDT передаются как ТС, так и АС.

Рисунок 94 - PDU заголовка PDU нисходящей фазы UDT

в общей структуре и иерархии служебных сообщений

в нисходящем направлении TSCC

Таблица 108

Содержание заголовка PDU нисходящей фазы UDT

Длина, бит

Комментарий

Функциональные элементы

& G/I

0₂ = назначение - индивидуальный адрес АС;

1₂ = назначение - адрес разговорной группы. Ответ не ожидается

& A

0₂ = ответ не требуется, если назначение - адрес индивидуальной АС;

1₂ = ответ требуется, если назначение - адрес индивидуальной АС

Emergency

0₂ = этот PDU не поддерживает приоритетный экстренный вызов;

1₂ = этот PDU поддерживает приоритетный экстренный вызов

UDT_Option_Flag

См. 16.3.13.3

Format

0000₂

SAP

SAP - 0000₂ для UDT

UDT_Format

Формат данных, который следует за заголовком UDT

& Target_Address или Gateway

& Source_Address или Gateway

0₂

UAB

Количество блоков, добавленных к этому Заголовку UDT:

00₂ = 1 добавочный блок информации UDT;

01₂ = 2 добавочных блока информации UDT;

10₂ = 3 добавочных блока информации UDT;

11₂ = 4 добавочных блока информации UDT

0₂ = заголовок UDT передает информацию для услуг, инициированных пользователем (короткое сообщение, опрос данных);

1₂ = заголовок UDT передает вспомогательную информацию, поддерживая другие услуги уровня 3

Зарезервирован для будущего использования

Opcode (UDTHD)

ИС NORMPROD: примечание.

Примечание - IE, определенные в ГОСТ Р 71586.1, обведены утолщенной линией.

16.2.2.3 Служебные сообщения в восходящем направлении TSCC, передаваемые АС с помощью CSBK/UDT

PDU запроса произвольного доступа (C_RAND)

Нулевой и первый байты PDU запроса произвольного доступа CSBK (C_RAND_CSBK) преобразуются в структуру формата LC, как показано в ГОСТ Р 71586.1-2024 (рисунок 59), при этом CSBKO заменяет FLCO. Байты со второго по девятый содержат специальную информацию о запросе произвольного доступа, приведенную в таблице 109. В общей структуре и иерархии служебных сообщений в восходящем направлении TSCC, передаваемых от АС, C_RAND_CSBK представлен на рисунке 95. Запросы произвольного доступа отправляются АС.

Таблица 109

Содержание PDU запроса произвольного доступа

IE	Длина, бит	Комментарий
Зависящие от сообщения элементы
LB	1	Этот бит должен быть установлен в значение 1₂
PF	1	-
Функциональные элементы
CSBKO	6	Должен быть установлен в значение 01 1111₂
Manufacturers Feature ID (идентификация производителя)	8	Должен быть установлен в значение 0000 0000₂
Service_Options	7	-
Proxy Flag	1	0₂ - количество цифр BCD при адресации через шлюз от 1 до 20; 1₂ - количество цифр BCD при адресации через шлюз от 21 до 44
-	4	Содержимое зависит от типа поддерживаемых услуг
Service_Kind	4	Запрос услуги
Target_Address или Gateway	2	-
Source_Address	2	Адрес нужной АС

Рисунок 95 - PDU запроса произвольного доступа в общей

структуре и иерархии служебных сообщений в восходящем

направлении TSCC, передаваемых от АС

PDU ответа на запрос (C_Ackvitation) CSBK

Нулевой и первый байты PDU ответа на запрос (C_Ackvitation, C_ACKVIT) CSBK преобразуются в структуру формата LC, как показано в ГОСТ Р 71586.1-2024 (рисунок 59), при этом CSBKO заменяет FLCO. Байты со второго по девятый содержат специальную информацию о C_Ackvitation. Универсальный (обобщенный) PDU C_Ackvitation приведен в таблице 110, в общей структуре и иерархии служебных сообщений в восходящем направлении TSCC, передаваемых от АС, он представлен на рисунке 96. PDU C_Ackvitation передаются АС.

C_Ackvitation PDU передается АС как CSBK.

Рисунок 96 - PDU ответа на запрос (C_Ackvitation) в общей

структуре и иерархии служебных сообщений в восходящем

направлении TSCC, передаваемых от АС

Таблица 110

Содержание PDU C_Ackvitation

IE	Длина, бит	Комментарий
Зависящие от сообщения элементы
LB	1	Этот бит должен быть установлен в значение 1₂ для одноблочного сообщения CSBK или на 0₂ для всех, кроме последнего блока MBC
PF	1	-
Функциональные элементы
CSBKO	6	Должен быть установлен в значение 01 1110₂
FID	8	Должен быть установлен в значение 0000 0000₂
Service_Options_Mirror	7	-
Service_Kind_Flag	1	Значение зависит от Service_Kind
R	2	00₂
UAB	2	00₂
Service_Kind	4	Услуги, для которых поддерживается C_Ackvitation
Target_Address	24	Значение запроса аутентификации
Source_Address	24	Индивидуальный адрес АС, отправляющей C_Ackvitation

PDU ответа АС C_Acknowledge (C_ACKU) CSBK

Нулевой и первый байты PDU подтверждения ответа (C_ACKU) CSBK преобразуются в структуру формата LC, как показано в ГОСТ Р 71586.1-2024 (рисунок 59), при этом CSBKO заменяет FLCO. Байты со второго по девятый содержат специальную информацию о C_ACKU. Типичный C_ACKU приведен в таблице 111.

Таблица 111

Содержание PDU ответов подтверждения АС

IE	Длина, бит	Комментарий
Зависящие от сообщения элементы
CSBKO	1	Этот бит должен быть установлен в значение 1₂
PF	1	-
Функциональные элементы
CSBKO	6	Должен быть установлен в значение 10 0001₂
FID	8	Должен быть установлен в значение 0000 0000₂
Response_Info	7	Дополнительная информация в ответе
Reason	8	-
R	1	Этот бит должен быть установлен в значение 0₂
Target_Address или Authentification (аутентификация)	24	Адрес источника из PDU АС, для которой это подтверждение передается, или готовится ответ на запрос аутентификации, если это подтверждение - часть запроса аутентификации
Additional_Information (Source_Address) [дополнительная информация (адрес источника)]	24	Индивидуальный адрес АС, которая передает подтверждение

PDU C_ACKU в общей структуре и иерархии служебных сообщений представлен на рисунке 97.

Примечание - Ответы подтверждения передаются как ТС, так и АС.

Рисунок 97 - PDU подтверждения в общей структуре

и иерархии служебных сообщений

PDU подтверждения ответа подразделяются на классы:

- C_ACKU - положительное подтверждение;

- C_NACKU - отрицательное подтверждение.

PDU заголовка восходящей фазы UDT (C_UDTHD)

PDU C_UDT отправляются ТС и АС. Этот PDU - многоблочный UDT, приведенный к формату, показанному в таблице 112, в общей структуре и иерархии служебных сообщений он показан на рисунке 98. Количество добавочных блоков UDT указывается IE UAB.

Примечание - Заголовки UDT передаются как ТС, так и АС.

Рисунок 98 - PDU заголовка PDU C_UDT TSCC в общей структуре

и иерархии служебных сообщений

Таблица 112

Содержание PDU C_UDT восходящего канала

Длина, бит

Комментарий

Функциональные элементы

& G/I

0₂ - назначение - индивидуальный адрес АС;

1₂ - назначение - адрес голосовой группы

& A

0₂ - ответ не ожидается, если назначение - индивидуальный адрес АС;

1₂ - ответ требуется, если назначение - индивидуальный адрес АС

0₂

UDT_DIV

0₂ - UDT не поддерживает назначение информации переадресации вызова;

1₂ - UDT поддерживает назначение информации переадресации вызова

& Format

0000₂

& SAP

Служебная точка доступа для UDT - 0000₂

UDT_Format

Формат данных, которые следуют за заголовком UDT

& Target_Address или Gateway

& Source_Address или Gateway

UAB

Число блоков, прикрепленных к заголовку UDT:

00₂ - 1 добавочный блок информации UDT;

01₂ - 2 добавочных блока информации UDT;

10₂ - 3 добавочных блока информации UDT;

11₂ - 4 добавочных блока информации UDT

0₂ - этот заголовок UDT передает информацию для услуг, инициированных пользователем (короткое сообщение, опрос данных);

1₂ - этот заголовок UDT передает вспомогательную информацию, поддерживая другие услуги уровня 3

Зарезервирован для будущего использования

Opcode (UDTHU)

ИС NORMPROD: примечание.

Примечание - IE, определенные в ГОСТ Р 71586.1, обведены утолщенной линией.

16.2.2.4 Служебные сообщения, передаваемые транкинговой станцией в нисходящем направлении рабочего канала с использованием CSBK

Служебные сообщения PDU предоставления канала (P_GRANT) с использованием CSBK/MBC

PDU предоставления канала, передаваемые в рабочих каналах, преобразуются в такую же структуру, что и PDU предоставления канала, передаваемые по TSCC. При передаче такого PDU по рабочему каналу с целью перемещения вызова на новый рабочий канал ТС должна сохранить все IE в значениях, указанных TSCC в PDU предоставления канала, кроме номера логического канала (и абсолютной частоты, если PDU предоставления канала имеет добавочный блок CSBK) (см. таблицу 113). При передаче такого PDU в рабочем канале для объявления текущего вызова до первой передачи во время вызова ТС будет возвращать все IE к значениям из TSCC PDU предоставления канала.

PDU предоставления рабочего канала передается в TSCC как CSBK или MBC. Для IE Physical Channel Number:

а) если значение = 0000 0000 0000₂, то номер физического канала - неверный;

б) если значение находится в пределах от 0000 0000 0001₂ до 1111 1111 1110₂, то номер физического канала представляет Logical Channel Number для физической частоты передатчика и приемника. PDU о предоставлении конфиденциального канала передачи данных передается по TSCC как CSBK;

в) если значение = 1111 1111 1111₂, то номер физического канала определяет MBC, в котором абсолютная частота передатчика и приемника передается во втором блоке этого MBC [см. 16.2.2.2 ("Параметры PDU предоставления канала (CG_AP) добавочного MBC")].

PDU предоставления рабочих каналов в общей структуре и иерархии служебных сообщений представлен на рисунке 99.

Рисунок 99 - PDU предоставления рабочего канала

в общей структуре и иерархии служебных сообщений

Таблица 113

Содержание PDU предоставления рабочего канала

IE	Длина, бит	Комментарий
Зависящие от сообщения элементы
LB	1	Этот бит должен быть установлен в значение 1₂ для одноблочного сообщения CSBK или в значение 0₂, если это заголовок MBC
PF	1	-
Функциональные элементы
CSBKO	6	Должно быть установлено значение из PDU предоставления канала, отправленного TSCC, который направил эту АС в канал передачи данных
FID	8	Должен быть установлен в значение 0000 0000₂
Logical Physical Channel Number	12	Рабочий канал для вызова или индикатор того, что абсолютная частота передатчика и приемника указаны в добавочном блоке CSBK
Logical Channel Number	1	0₂ - канал 1 с TDMA; 1₂ - канал 2 с TDMA
Emergency HI_RATE Offset	3	HI_RATE в случае передачи данных Emergency и Offset (синхронизация со смещением или синхронизация с выравниванием) от TSCC, который направил эту АС в канал передачи данных
Destination_Address	24	Индивидуальный адрес АС вызываемого абонента, шлюза или разговорной группы
Source_Address	24	Вызывающая сторона или шлюз

Служебное сообщение PDU Clear (P_CLEAR), передаваемое с использованием CSBK

Нулевой и первый байты PDU P_CLEAR CSBK преобразуются в структуру формата LC как показано в ГОСТ Р 71586.1-2024 (рисунок 59), при этом IE CSBKO заменяет FLCO. Байты со второго по девятый содержат специальную информацию о P_Clear PDU, которая приведена в таблице 114, а в общей структуре и иерархии служебных сообщений он представлен на рисунке 100. P_Clear передается ТС только по рабочему каналу и не требует ответа.

Рисунок 100 - PDU P_Clear, передаваемый в рабочих каналах

в общей структуре и иерархии служебных сообщений

Таблица 114

Содержание PDU P_Clear

IE	Длина, бит	Комментарий
Зависящие от сообщения элементы
LB	1	Этот бит должен быть установлен в значение 1₂
PF	1	-
Функциональные элементы
CSBKO	6	Должен быть установлен в значение 10 1110₂
FID	8	Должен быть установлен в значение 0000 0000₂
Logical Physical Channel Number	12	Канал, на который должна перейти вызываемая сторона, или индикатор того, что абсолютная частота передатчика и приемника указана в добавочном блоке CSBK
R	3	000₂
G/I	1	0₂ - адрес получателя - АС ID; 1₂ - адрес получателя - это разговорная группа
Target_Address	24	ID вызываемой АС, разговорной группы или ALLMSI <1>
Source_Address	24	TSI
<1> Если Target_Address - ALLMSI, то G/I = 0₂.

PDU P_Clear передается ТС как CSBK или MBC. Для IE Physical Channel Number:

а) если значение = 0000 0000 0000₂, то соответствующие АС должны перейти на номер TSCC, на котором АС были подтверждены в последний раз;

б) если значение находится в пределах от 0000 0000 0001₂ до 1111 1111 1110₂, то номер физического канала представляет Logical Channel Number для физической частоты передатчика и приемника. PDU Clear передается по TSCC как CSBK;

В большинстве транкинговых сетей PDU P_Clear используется для отключения всех АС и разговорных групп от канала передачи трафика. Таким образом, этот канал может быть переадресован на новый вызов. Для выполнения этого режима работы Target_Address устанавливается на ALLMSI.

PDU Protect (P_PROTECT), передаваемое с использованием одноблочного сообщения CSBK

Нулевой и первый байты PDU P_Protect CSBK преобразуются в структуру формата LC, как показано в ГОСТ Р 71586.1-2024 (рисунок 59), при этом CSBKO заменяет FLCO. Байты со второго по девятый содержат специальную информацию о P_Protect и приведены в таблице 115. PDU P_Protect передается ТС только по рабочему каналу и не требует ответа. PDU P_Protect передается ТС как CSBK. В общей структуре и иерархии служебных сообщений PDU P_Protect представлен на рисунке 101.

Рисунок 101 - PDU P_Protect, передаваемый в рабочих каналах,

в общей структуре и иерархии служебных сообщений

Таблица 115

Содержание PDU P_Protect

IE	Длина, бит	Комментарий
Зависящие от сообщения элементы
LB	1	Этот бит должен быть установлен в значение 1₂
PF	1	-
Функциональные элементы
CSBKO	6	Должен быть установлен в значение 10 1111₂
FID	8	Должен быть установлен в значение 0000 0000₂
R	12	0000 0000 0000₂
Protect_Kind	3	-
G/I	1	-
Target_Address	24	Адрес получателя
Source_Address	24	Адрес источника

Служебное сообщение PDU Ahoy (P_AHOY), передаваемое с использованием CSBK

PDU Ahoy (P_AHOY) - общие положения

Нулевой и первый байты PDU AHOY CSBK преобразуются в структуру формата LC, как показано в ГОСТ Р 71586.1-2024 (рисунок 59), при этом CSBKO заменяет FLCO. Байты со второго по девятый содержат специальную информацию о P_AHOY, которая приведена в таблице 106. PDU P_AHOY, передаваемый в общей структуре и иерархии служебных сообщений, представлен на рисунке 102. P_AHOY передается ТС в рабочих каналах и, если адресуется разговорной группе, то не требует ответа.

Рисунок 102 - PDU P_AHOY, передаваемый в рабочих каналах,

в общей структуре и иерархии служебных сообщений

PDU проверки присутствия АС P_AHOY

ТС может отправить запрос на проверку присутствия P_AHOY по рабочему каналу для того, чтобы определить, находится ли конкретная АС в рабочем канале.

Проверка аутентификации АС

ТС может отправить запрос на проверку аутентификации АС P_AHOY по рабочему каналу для АС.

Проверка присутствия разговорной группы

ТС может отправить запрос на проверку присутствия разговорной группы P_AHOY по рабочему каналу для проверки того, присутствует ли хотя бы одна разговорная группа в рабочем канале.

PDU подтверждения P_Acknowledgement

PDU подтверждения P_Acknowledgement передается по рабочему каналу, прикрепленное к тому же структурному элементу, что и PDU подтверждения, которые передаются по TSCC. PDU P_Acknowledgement, передаваемый в общей структуре и иерархии служебных сообщений, представлен на рисунке 103.

Рисунок 103 - PDU P_Acknowledgement, передаваемый в рабочих

каналах, в общей структуре и иерархии служебных сообщений

16.2.2.5 Служебные сообщения с использованием CSBK, передаваемые АС в восходящем направлении рабочих каналов

PDU запроса произвольного доступа P_RAND

PDU P_RAND, которые передаются по рабочему каналу, приводятся к той же структуре, что и PDU запроса произвольного доступа, которые передаются по TSCC. Однако только IE Service_Kind PDU P_RAND, который передается по рабочему каналу, может содержать требование о включении данной услуги. PDU P_RAND в общей структуре и иерархии служебных сообщений представлен на рисунке 104.

Рисунок 104 - PDU P_RAND, передаваемый в рабочих каналах,

в общей структуре и иерархии служебных сообщений

PDU подтверждения P_ACK PDU

PDU подтверждения P_ACK PDU, передаваемые в рабочих каналах, приводятся к той же структуре, что и PDU подтверждения, передаваемые по TSCC. PDU P_ACK в общей структуре и иерархии служебных сообщений представлено на рисунке 105.

Рисунок 105 - PDU P_ACK, передаваемый в рабочих каналах

в общей структуре и иерархии служебных сообщений

PDU поддержания P_MAINT

Нулевой и первый байты PDU P_MAINT CSBK преобразуются в формат LC как показано в ГОСТ Р 71586.1-2024 (рисунок 59), при этом CSBKO заменяет FLCO. Байты со второго по девятый содержат специальную информацию о P_MAINT, приведенную в таблице 116. P_MAINT передается АС только по рабочему каналу. PDU P_MAINT передается АС как CSBK. PDU P_MAINT в общей структуре и иерархии служебных сообщений представлен на рисунке 106.

Рисунок 106 - PDU P_MAINT, передаваемый в рабочих каналах,

в общей структуре и иерархии служебных сообщений

Таблица 116

Содержание PDU P_MAINT

IE	Длина, бит	Комментарий
Зависящие от сообщения элементы
LB	1	Этот бит должен быть установлен в значение 1₂
PF	1	-
Функциональные элементы
CSBKO	6	Должен быть установлен в значение 10 1010₂
FID	8	Должен быть установлен в значение 0000 0000₂
R	12	-
Maint Kind (тип поддержки)	3	-
R	1	-
Target_Address	24	TSI
Source_Address	24	Адрес АС

16.2.3 PDU управления короткими соединениями

16.2.3.1 Системные параметры TSCC

Первые четыре бита нулевого байта системных параметров PDU TSCC (C_SYS_Parms) короткими соединениями имеют значения, приведенные в ГОСТ Р 71586.2-2024 (подраздел 11.1). Байты с первого по третий содержат специальную информацию о системных параметрах. Значения элементов PDU C_SYS_Parms приведены в таблице 117.

Таблица 117

Содержание PDU C_SYS_Parms

IE	Длина, бит	Значение	Комментарий
Элементы
SLCO	4	0010₂	-
MODEL	2	00₂	Минимальная сетевая модель
		01₂	Маленькая сетевая модель
		10₂	Большая сетевая модель
		11₂	Очень большая сетевая модель
NET	12	-	Указание сети и сайта
SITE	12	-	Указание сети и сайта
Reg	1	0₂	Этот TSCC не требует регистрации АС, пока она не активна
Reg	1	1₂	Этот TSCC требует регистрации АС, пока она не активна
Common_Slot_Counter	9	-	Общий счетчик таймслотов

PDU C_SYS_Parms передает информацию в CACH, когда один или оба таймслота физического канала являются TSCC, в частности, если используется совмещенный TSCC, когда один таймслот физического канала - это TSCC, а другой таймслот - рабочий канал. Передача невозможна в случае, если ни один из таймслотов физического канала не является TSCC.

16.2.3.2 Системные параметры рабочего канала

Первые четыре бита нулевого байта системных параметров рабочего канала (P_SYS_Parms) PDU короткого сообщения управления соединением (Short LC) имеют значения, описанные в ГОСТ Р 71586.2-2024 (подраздел 11.1). Байты с первого по третий содержат специальную информацию о системных параметрах. PDU P_SYS_Parms приведен в таблице 118.

Таблица 118

Содержание PDU P_SYS_Parms

IE	Длина, бит	Значение	Комментарий
Элементы
SLCO	4	0011₂	-
MODEL	2	00₂	Минимальная сетевая модель
		01₂	Маленькая сетевая модель
		10₂	Большая сетевая модель
		11₂	Очень большая сетевая модель
NET	12	-	Определение сети и сайта
SITE	12	-	Определение сети и сайта
Payload Channel Type	1	0₂	Нормальный рабочий канал
Payload Channel Type	1	1₂	Рабочий канал является смешанным (может выполнять функции TSCC или рабочего канала)
Common_Slot_Counter	9	-	Общий счетчик таймслотов

PDU P_SYS_Parms передает информацию в CACH, когда оба таймслота физического канала являются рабочими каналами, в частности, если используется совмещенный TSCC, когда один таймслот физического канала - это TSCC, который стал рабочим каналом для передачи пользовательских данных, а второй таймслот - это рабочий канал. Передача невозможна в случае, если один из таймслотов физического канала является TSCC.

16.3 Кодовые обозначения в IE уровня управления вызовами (уровень 3) стека протоколов в транкинговом режиме

16.3.1 Общие положения

Подраздел содержит описание IE в PDU уровня 3 стека протоколов в транкинговом режиме и описывает связь элементов с их двоичным представлением.

Структура таблиц представлена следующим образом:

- графа "IE" содержит наименование элемента;

- графа "Длина, бит" определяет длину элемента в битах;

- графа "Значение" указывает фиксированные значения или диапазон значений;

- графа "Комментарий" определяет значение IE в отношении каждого из его числовых значений, представленных в битах, или содержит дополнительную информацию об элементе.

16.3.2 IE "Маска"

IE "Маска" имеет длину 5 бит и представлен в таблице 119.

Таблица 119

Описание IE "Маска"

IE	Длина, бит	Значение	Комментарий
"Маска"	5	0 - 24	Значение в диапазоне от 0 до 24 (десятичное число)

16.3.3 IE Service Function (функция услуги)

IE Service Function имеет длину 2 бита и приведен в таблице 120.

Таблица 120

Описание IE Service Function

IE	Длина, бит	Значение	Комментарий
Service Function	2	00₂	Произвольный доступ, предлагаемый для всех услуг
		01₂	Произвольный доступ, предлагаемый для услуг, которым требуется рабочий канал, произвольный доступ, предлагаемый для запросов регистрации
		10₂	Произвольный доступ, предлагаемый для услуг, которым требуется рабочий канал, произвольный доступ, предлагаемый для запросов регистрации
		11₂	Произвольный доступ, предлагаемый только для запросов регистрации произвольного доступа

16.3.4 IE NRand_Wait

IE NRand_Wait имеет длину 4 бита и представлен в таблице 121. TSCC должен определить, используя NRand_Wait, задержку (в TDMA-кадрах), которую должна выдержать АС, прежде чем принять решение о повторной передаче и выбрать другой интервал из нового кадра произвольного доступа.

Таблица 121

NRand_Wait

IE	Длина, бит	Значение	Комментарий
NRand_Wait	4	0-15	Ответ TSCC на запрос случайного доступа 0 = ответ в следующем TDMA-кадре 1 - АС должна ожидать 1 кадр TDMA 2 - АС должна ожидать 2 кадра TDMA 3 - АС должна ожидать 3 кадра TDMA 4 - АС должна ожидать 4 кадра TDMA 5 - АС должна ожидать 5 кадров TDMA 6 - АС должна ожидать 6 кадров TDMA 7 - АС должна ожидать 7 кадров TDMA 8 - АС должна ожидать 8 кадров TDMA 9 - АС должна ожидать 9 кадров TDMA 10 - АС должна ожидать 10 кадров TDMA 11 - АС должна ожидать 11 кадров TDMA 12 - АС должна ожидать 12 кадров TDMA 13 - АС должна ожидать 13 кадров TDMA 14 - АС должна ожидать 15 кадров TDMA 15 - АС должна ожидать 24 кадра TDMA

16.3.5 IE Reg (регистрация)

IE Reg имеет длину 1 бит и представлен в таблице 122.

Таблица 122

Описание IE Reg

IE	Длина, бит	Значение	Комментарий
Reg	1	0₂	Регистрация АС не требуется
Reg	1	1₂	Требуется регистрация АС

16.3.6 IE Backoff (отклонение)

IE Backoff имеет длину 4 бита и представлен в таблице 123.

Таблица 123

Описание IE Backoff

IE	Длина, бит	Значение	Комментарий
Backoff	4	0	Зарезервировано
		1	Длина кадра произвольного TDMA = 1
		2	Длина кадра произвольного TDMA = 2
		3	Длина кадра произвольного TDMA = 3
		4	Длина кадра произвольного TDMA = 4
		5	Длина кадра произвольного TDMA = 5
		6	Длина кадра произвольного TDMA = 8
		7	Длина кадра произвольного TDMA = 11
		8	Длина кадра произвольного TDMA = 15
		9	Длина кадра произвольного TDMA = 20
		10	Длина кадра произвольного TDMA = 26
		11	Длина кадра произвольного TDMA = 33
		12	Длина кадра произвольного TDMA = 41
		13	Длина кадра произвольного TDMA = 50
		14	Длина кадра произвольного TDMA = 70
		15	Длина кадра произвольного TDMA = 100

16.3.7 IE System Identity Code (идентификационный код системы)

IE System Identity Code имеет длину 16 бит и представлен в таблице 124.

Таблица 124

Описание IE System Identity Code

IE	Длина, бит	Значение	Комментарий
System Identity Code C_SYScode	16	XX...X₂	Идентификационный код системы, передаваемый в TSCC

16.3.8 IE Response_Info

IE Response_Info содержит дополнительную информацию в PDU подтверждения. Он имеет длину 7 бит и представлен в таблице 125.

Таблица 125

Описание IE Response_Info

IE	Длина, бит	Значение	Комментарий
Код причины подтверждения = Reg_Accepted (0110 0010₂)
Response_Info	7	PowerSave_Offset	Подтверждение запроса регистрации произвольного доступа, который активирует энергосбережение (см. 7.4.8). Адрес получателя - индивидуальный ID АС.
Код причины подтверждения = принят для услуги Опрос состояния (0110 0011₂)
Status	7	Значение состояния	Исходящее подтверждение. Адрес получателя - индивидуальная АС
Код причины подтверждения = услуга подписки/присоединения к разговорной группе (0110 0101₂)
Validation_Index	7	Индексная схема	Схема указывает разговорные группы, которые были приняты/которым было отказано
Все другие подтверждающие коды причин
G/I	1	0₂	Адрес получателя - индивидуальный ID АС или шлюз
G/I	1	1₂	Адрес получателя - разговорная группа
Response_Check	6	XXXXXX₂	6 младших бит из элементов NET + SITE из C_SYScode, переданных TSCC <1>
<1> Биты 8, 7, 6, 5, 4 и 3 показаны на рисунке 26.

16.3.9 IE Reason (причина)

16.3.9.1 Общие положения

IE Reason имеет длину 8 бит и представлен в таблицах 126 - 129. Классификации C_ACK, C_NACK, C_QACK, C_WACK представлены в отдельных таблицах.

Биты Reason представлены как t t d a a a a a.

t t - тип ACK: 00₂ соответствует NACK; 01₂ соответствует ACK; 10₂ соответствует QACK; 11₂ соответствует WACK.

d - направление: 1₂ соответствует от ТС к АС; 0₂ соответствует от АС к ТС, или переданные ТС для отражения подтверждения, отправленного АС другим применимым сторонам.

a a a a a - подтвержденная причина.

Существуют случаи, в соответствии с которыми код причины для подтверждения от АС должен быть повторно передан ТС. В этом случае код Reason от АС полностью отражается ТС. Такое подтверждение описано в настоящем стандарте как Mirrored_Reason.

16.3.9.2 Служебное сообщение подтверждения C_ACK

Таблица 126 отображает положительные окончательные подтверждения.

Таблица 126

Описание служебного сообщения C_ACK

IE	Длина, бит	Значение	Наименование	Комментарий
Reason	8	Подтверждение, переданное ТС. Сообщение, принятое АС
		0110 0000₂	Message_Accepted	Сообщение, принятое ТС, - продолжать
		0110 0001₂	Store_Forward	Вызов помещается в запоминающее устройство и пересылается в буфер для последующей передачи, когда вызываемая АС проводит регистрацию
		0110 0010₂	Reg_Accepted	Запрос регистрации от АС принят
		Подтверждение, передаваемое от АС. Сообщение, принятое ТС (может быть отправлено от АС)
		0110 0011₂	Принято для услуги "Опрос состояния"	Сообщение принято для услуги "Опрос состояния". Response_Info содержит значение состояния
		0110 0100₂	Аутентификационный ответ	Ответ ТС на вызов аутентификации
		0110 0101₂	Reg_Subscription/дополнительная услуга	Ответ от АС на запрос регистрации с подпиской/присоединением
		0100 0100₂	MS_Accepted	Сообщение, принятое АС (или отраженное ТС)
		0100 0101₂	CallBack	Вызываемая АС указывает ТС, что она отправит обратный вызов позднее (или отраженный ТС)
		0100 0110₂	MS_ALERTING	Предупреждение АС, но еще не RFC (или отраженный ТС)
		0100 0111₂	Принято для услуги "Опрос состояния"	Сообщение, принятое для услуги "Опрос состояния". Response_Info содержит значение состояния
		0100 1000₂	Аутентификационный ответ	Ответ ТС на вызов аутентификации

Существуют некоторые обмены PDU между АС и TSCC, посредством которых подтверждение, переданное АС, повторно передается с помощью ТС с использованием идентичного кода причины. Это подтверждение представляет собой зеркальный код Reason и определяется, как указано в описаниях процедур вызовов.

16.3.9.3 Служебное сообщение подтверждения C_NACK PDU

Таблица 127 содержит перечень подтверждений отклонения услуг:

а) для сообщений/услуг, отклоненных сетью:

- не поддерживается (0010 0000₂).

АС регистрируется в сети и делает запрос произвольного доступа к услуге, не поддерживаемой сетью;

- Perm_User_Refused (0010 0001₂).

АС регистрируется в сети и делает запрос произвольного доступа к услуге, на которую сеть не дает разрешения пользователю;

- Temp_User_Refused (0010 0010₂).

АС регистрируется в сети и делает запрос произвольного доступа к услуге, которую сеть поддерживает, но по некоторым причинам сеть не может обеспечить вызов в это время (например, сеть предлагает доступ к PSTN, но соединение между системой и PSTN срабатывает неправильно);

- Transient_Sys_Refused (0010 0011₂).

Запрос отклонен, так как данная услуга для этой сети в настоящее время недоступна;

- NoregMSaway_Refused (0010 0100₂).

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

- MSaway_Refused (0010 0101₂).

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

- Div_Cause_Fail (0010 0110₂).

АС опрошена другой АС для передачи коротких данных UDT, но опрошенная АС перенаправила свои вызовы, поэтому опрос не может продолжаться [см. 7.5.4.2 ("Ответ TSCC на запрос опроса коротких данных от АС")];

- SYSbusy_Refused (0010 0111₂).

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

- SYS_NotReady (0010 1000₂).

АС зарегистрирована в сети и сделала запрос произвольного доступа к услуге. Запрос был отклонен, поскольку сеть в это время не функционирует. Система может находиться на техническом обслуживании или в стадии разработки;

- Call_Cancel_Refused (0010 1001₂).

АС зарегистрирована в сети и сделала запрос произвольного доступа к услуге. ТС отправляет подтверждение в виде служебных сообщений C_QACK или C_WACK PDU. После этого подтверждения вызывающая АС должна отправить дополнительный запрос произвольного доступа для отмены вызова. Сеть не может отменить вызов и посылает через ТС следующие PDU, чтобы проинформировать вызывающего абонента о том, что вызов не может быть отменен;

- Reg_Refused (0010 1010₂). См. описание в 7.4.5;

- Reg_Denied (0010 1011₂). См. описание в 7.4.5.

Далее должны быть выполнены процедуры в соответствии с 7.4.12.2 ("Окончательное подтверждение подключения IP") и 7.4.12.3:

- MS_Not_Registered (0010 1101₂).

Если сети требуется, чтобы АС зарегистрировала себя, то, используя TSCC перед выполнением запроса на обслуживание, она должна это сделать. Если АС нарушила требование сети, то ей будет отказано в обслуживании;

- Called_Party_Busy (0010 1110₂).

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

Called_Group_Not_Allowed (0010 1111₂).

АС зарегистрирована в сети и сделала запрос произвольного доступа для обслуживания в разговорной группе. Идентификатор разговорной группы не разрешен ТС с применением служебного сообщения в нисходящем направлении TSCC;

- получена ошибка CRC в фазе загрузки сообщения с использованием передачи данных UDT (0011 0000₂).

АС запросила услугу, которая требует загрузить данные с использованием UDT. Ошибка CRC в UDT сделала невозможной процедуру вызова;

- Duplex_Congestion (0011 0001₂).

Система не имеет достаточных ресурсов для установления запрашиваемого вызова в качестве дуплексного вызова. АС вместо этого должна попытаться установить симплексный вызов;

- Refused_Reason_Unknown (0011 1111₂).

АС зарегистрирована в сети и сделала запрос произвольного доступа к услуге. Вызов был отклонен, но причина неизвестна;

б) для сообщений/услуг, отклоненных АС:

- MSNot_Supported (0000 0000₂).

В нисходящем направлении TSCC должно быть передано служебное сообщение с использованием PDU к вызывающей АС, ранее запросившей ответ на запрос о предоставлении услуги, если запрашиваемая услуга не поддерживается вызываемой АС, направившей ответ:

- LineNot_Supported (0001 0001₂).

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

- StackFull_Refused (0001 0010₂).

TSCC сделал попытку отправить информацию, которую должна сохранить АС. Память АС переполнена и поэтому АС не может принять информацию. Например, АС может хранить адреса вызывающих абонентов, от которых не был получен ответ на этот вызов, и вызываемая сторона должна сохранить адрес вызывающего абонента. Если память переполнена, то соответствующим ответом является Stack_Full_Refused;

- EquipBusy_Refused (0001 0011₂).

TSCC сделал запрос АС о наличии доступного дополнительного оборудования и его готовности. Если такое оборудование занято, формируется соответствующий ответ;

- Recipient_Refused (0001 0100₂).

TSCC сделал попытку вызова или транзакции, которую АС вызываемого абонента не хочет принимать;

- Custom_Refused (0001 0101₂).

Данный ответ относится к любой другой причине отказа от вызова, предусмотренной производителем оборудования по требованию заказчика, исключая процедуры регистрации;

- MS_Duplex_Not_Supported (0001 0110₂).

По TSCC отправлен запрос на проверку дуплексной радиосвязи от АС к АС, но такой вид радиосвязи не поддерживается;

- Refused_Reason_Unknown (0001 1111₂).

PDU для АС был отклонен по неизвестной причине.

Таблица 127

Служебные сообщения C_NACK PDU, содержащие различные

варианты подтверждений отклонения услуг

IE	Длина, бит	Значение	Наименование	Комментарий
Reason	8	Сообщение/услуга, отклоненная сетью (ТС)
		0010 0000₂	Not_Supported	Сеть не поддерживает данную услугу
		0010 0001₂	Perm_User_Refused	Запрос отклонен, т.к. услуга не авторизована для этого пользователя (постоянного). Критерии "постоянного пользователя" определяются производителем
		0010 0010₂	Temp_User_Refused	Запрос отклонен, т.к. услуга на текущий момент не авторизована для данного пользователя (временного). Критерии "временного пользователя" определяются производителем
		0010 0011₂	Transient_Sys_Refused	Запрос отклонен, т.к. услуга недоступна в данное время для данной сети
		0010 0100₂	NoregMSaway_Refused	Запрос отклонен, т.к. с вызываемым абонентом не установлена радиосвязь (и он не зарегистрирован в сети)
		Сообщение/услуга, отклоненная сетью (ТС)
		0010 0101₂	MSaway_Refused	Запрос отклонен, т.к. с вызываемым абонентом не установлена радиосвязь (но он зарегистрирован в сети)
		0010 0110₂	Div_Cause_Fail	Вызов не может быть обработан, т.к. АС отклонила данные вызовы
		0010 0111₂	SYSbusy_Refused	Запрос отклонен, т.к. сеть испытывает перегрузку (Network Overload)
		0010 1000₂	SYS_NotReady	Запрос отклонен, т.к. сеть не готова (попробовать позже)
		0010 1001₂	Call_Cancel_Refused	Запрос отменить вызов был отклонен, т.к. вызов все еще может дойти
		0010 1010₂	Reg_Refused	Запрос от ТС к регистру был отклонен
		0010 1011₂	Reg_Denied	Запрос от АС к регистру был запрещен
		0010 1100₂	IP_Connection_failed	Запрос от АС на сообщение о неудавшемся уведомлении по IP-соединению
		0010 1101₂	MS_Not_Registered	Данная система запрашивает АС о ее регистрации перед приемом запроса на обслуживание пользователя. АС не зарегистрирована
		0010 1110₂	Called_Party_Busy	Вызываемый абонент занят и сеть не хочет ставить вызов в очередь
		0010 1111₂	Called_Group_Not_Allowed	ID разговорной группы не разрешен TSCC
		0011 0000₂	CRC_error_in_the_UDT_Upload_phase	CRC была обнаружена в фазе загрузки UDT
		0011 0001₂	Duplex_Congestion	Инфраструктура не имеет достаточно свободных ресурсов для установления дуплексного вызова
		Сообщение/Услуга, отклоненная АС (может быть перенаправлена ТС)
		0011 1111₂	Refused_Reason_Unknown	Запрос был отклонен, но причина неизвестна
		0000 0000₂	MSNot_Supported	АС не поддерживает услугу или функцию
		0001 0001₂	LineNot_Supported	Запрос отклонен, т.к. услуга не поддерживается вызываемым абонентом
		0001 0010₂	StackFull_Refused	Запрос отклонен, т.к. внутренний стек вызовов вызываемого абонента переполнен и не использует FIFO
		0001 0011₂	EuipBusy_Refused	Запрос отклонен, т.к. вспомогательное оборудование вызываемого абонента занято
		0001 0100₂	Recipient_Refused	Запрос отклонен пользователем вызываемой стороны (аналогично FOACSU)
		0001 0101₂	Custom_Refused	Запрос отклонен из-за причины, определенной пользователем
		0001 1111₂	Refused_Reason_Unknown	PDU для АС отклонен, но причина неизвестна

16.3.9.4 Служебное сообщение о подтверждении C_QACK, C_WACK PDU

Варианты ответов, передаваемых в служебных сообщениях C_QACK и C_WACK PDU, представлены в таблицах 128 и 129 соответственно.

Таблица 128

Варианты ответа в служебном сообщении C_QACK PDU

IE	Длина, бит	Значение	Наименование	Комментарий
Reason	8	Подтверждение, переданное ТС
		1010 0000₂	Queued-for-resource (например, рабочий канал)	Сообщение, принятое ТС, - далее будут поступать сообщения
		1010 0001₂	Queued-for-busy	Вызываемый абонент занят другим вызовом

Таблица 129

Варианты ответа в служебном сообщении C_WACK PDU

IE	Длина, бит	Значение	Имя	Комментарий
Reason	8	Подтверждение, переданное ТС
Reason	8	1110 0000₂	Wait	Сообщение, принятое ТС, - далее будут поступать сообщения

16.3.10 IE Digits (цифры)

IE Digits представляет собой набранные цифры, закодированные, как приведено в таблице 130.

Таблица 130

Числовые значения, передаваемые в IE Digits

IE	Длина, бит	Значение	Имя	Комментарий
Digits	4	0000₂	Цифра "0"	-
		0001₂	Цифра "1"	-
		0010₂	Цифра "2"	-
		0011₂	Цифра "3"	-
		0100₂	Цифра "4"	-
		0101₂	Цифра "5"	-
		0110₂	Цифра "6"	-
		0111₂	Цифра "7"	-
		1000₂	Цифра "8"	-
		1001₂	Цифра "9"	-
		1010₂	Цифра "*"	символ *
		1011₂	Цифра "#"	символ #
		1100₂	R	-
		1101₂	R	-
		1110₂	R	-
		1111₂	Неопределенное значение	-

16.3.11 IE Active_Connection (связь активной сети)

IE определяет, есть ли у ТС активное сетевое соединение с остальной частью сети, т.е. возможна ли связь с другими сайтами.

Таблица 131

Числовые значения, передаваемые в IE Active_Connection

IE	Длина, бит	Значение	Комментарий
Active_Connection	1	0₂	0₂ - ТС не имеет связи с сетью
Active_Connection	1	1₂	1₂ - ТС имеет связь с сетью

16.3.12 IE HI_RATE

IE HI_RATE имеет длину 1 бит и представлен в таблице 132.

Таблица 132

Режим передачи пакетов

IE	Длина, бит	Значение	Комментарий
HI_RATE	1	0₂	0₂ - рабочий канал использует одиночный таймслот данных
HI_RATE	1	1₂	1₂ - рабочий канал использует двойной таймслот данных

16.3.13 IE Service_Kind (вид услуги)

16.3.13.1 Перечень возможных значений IE Service_Kind

IE Service_Kind имеет длину 4 бита и представлен в таблице 133.

Таблица 133

Перечень значений IE Service_Kind

IE	Длина, бит	Значение	Комментарий
Service_Kind	4	0000₂	Услуга "Индивидуальный речевой вызов" (включает услугу "Индивидуальный речевой вызов" в случае отправки по рабочему каналу)
		0001₂	Услуга "Речевой вызов разговорной группы" (включает услугу "Речевой вызов разговорной группы" в случае отправки по рабочему каналу)
		0010₂	Услуга "Индивидуальный вызов с пакетной передачей данных"
		0011₂	Услуга "Вызов с пакетной передачей данных" для разговорной группы
		0100₂	Услуга "Индивидуальный сеанс передачи коротких сообщений"
		0101₂	Услуга "Сеанс передачи коротких сообщений" разговорной группы
		0110₂	Услуга "Опрос коротких сообщений"
		0111₂	Услуга "Передача состояния"
		1000₂	Услуга "Переадресация вызова"
		1001₂	Услуга "Ответ на вызов"
		1010₂	Услуга "Дуплексный речевой вызов от АС к АС"
		1011₂	Услуга "Дуплексный вызов с пакетной передачей данных от АС к АС"
		1100₂	Зарезервировано
		1101₂	Дополнительная услуга
		1110₂	Услуга регистрации/аутентификации (и снятия с регистрации)/проверки радиодоступности АС
		1111₂	Услуга "Отмена вызова"

16.3.13.2 IE Service_Kind_Flag

IE Service_Kind_Flag имеет длину 1 бит и представлен в таблице 134. Значение Service_Kind_Flag поддерживает IE Service_Kind. Значение Service_Kind_Flag зависит от сообщения, содержащего этот IE.

Таблица 134

IE Service_Kind_Flag

Значение Service_Kind	Сообщение	Значение Service_Kind_Flag	Комментарий
TSCC
0000₂	Проверка индивидуальной радиодоступности речевой услуги C_AHOY	0₂	Проверяет, находится ли вызываемая АС на связи и может ли принять этот вызов немедленно (OACSU)
0000₂		1₂	Проверяет готовность вызываемой АС для принятия речевого или информационного вызова (FOACSU)
0001₂	Проверка радиодоступности разговорной группы речевой услуги C_AHOY	0₂	Проверяет, находится ли как минимум один член вызываемой разговорной группы на связи
0010₂	Проверка индивидуальной радиодоступности с пакетной передачей данных C_AHOY	0₂	Проверяет, находится ли вызываемая АС на связи
0011₂	Проверка радиодоступности разговорной группы с пакетной передачей данных C_AHOY	0₂	Проверяет, находится ли как минимум один член вызываемой разговорной группы на связи
0100₂	Услуга "Индивидуальный сеанс передачи коротких сообщений"	0₂	Не применяется
0101₂	Услуга "Сеанс передачи коротких сообщений разговорной группы"	0₂	Не применяется
0110₂	Услуга "Опрос коротких сообщений"	0₂	Не применяется
0111₂	Услуга "Передача состояния"	0₂	Не применяется
1000₂	Услуга "Переадресация вызова"	0₂	Не применяется
1001₂	Проверка радиодоступности P_AHOY для адреса индивидуальной АС	0₂	Общая проверка присутствия независимо от поддерживаемой услуги
1001₂	Проверка радиодоступности P_AHOY для разговорной группы	1₂
1010₂	Проверка дуплексной индивидуальной радиосвязи речевой услуги от АС к АС C_AHOY	0₂	Проверка того, поддерживает ли АС радиосвязь и может ли принять этот вызов немедленно (OACSU)
1010₂		1₂	Проверяет, готова ли АС к приему речевого или информационного вызова (FOACSU)
1011₂	Проверка дуплексной индивидуальной радиосвязи с пакетной передачей данных от АС к АС C_AHOY	0₂	Проверка того, поддерживает ли вызываемая АС радиосвязь
1100₂	R	0₂	Зарезервировано
1101₂ (see note)	Блокирование/разблокирование C_AHOY	0₂	Блокирование
	Блокирование/разблокирование C_AHOY	1₂	Разблокирование
	C_AHOY Kill	0₂	Не применяется
1110₂	Регистрация/вызов аутентификации/проверка радиодоступности АС	0₂	Не применяется
1110₂	Данные подписки разговорной группы	1₂	-
1111₂	Услуга "Отмена вызова"	0₂	Не применяется
Рабочий канал
0000₂	Проверка индивидуальной радиодоступности речевой P_AHOY	0₂	-
0001₂	Проверка радиосвязи разговорной группы речевой услуги P_AHOY	0₂	-
0010₂	Проверка индивидуальной радиосвязи с пакетной передачей данных P_AHOY	0₂	-
0011₂	Проверка радиосвязи разговорной группы с пакетной передачей данных P_AHOY Voice	0₂	-
1001₂	Проверка радиосвязи P_AHOY для адреса индивидуальной АС	0₂	Общая проверка на присутствие независимо от поддерживаемой услуги
1001₂	Проверка радиосвязи P_AHOY для разговорной группы	1₂
1111₂	Разъединение P_AHOY индивидуальной АС от речевого рабочего канала	0₂	0₂ указывает, что получателем является индивидуальный адрес
1111₂	Разъединение P_AHOY разговорной группы от речевого рабочего канала	1₂	1₂ указывает, что получателем является разговорная группа
Примечание - Service_Kind = 1101₂ - услуга передачи дополнительных данных. Адрес назначения дополнительно определяется ID шлюза, определенным в данном PDU.

16.3.13.3 IE UDT_Option_Flag

В 7.4.14 описана услуга передачи данных Supplementary_user. На рисунке 44 показан пример речевого вызова, который включает в себя AD. В этом случае фаза загрузки с использованием процедуры UDT требует подтверждения от вызываемого абонента и поэтому может заменить проверку вызываемого абонента AHOY. PDU AHOY имеет IE Service_Kind_Flag, который указывает, является ли вызов OACSU или FOACSU. UDT_Option_Flag имеет то же назначение.

Таблица 135

Перечень значений IE UDT_Option_Flag

Поддержка UDT	Сообщение	Значение UDT_Option_Flag	Комментарий
Речевая услуга (Service_Kind - 0000₂) Пакетные данные (Service_Kind - 0010₂)	Нисходящий PDU UDTHD, передающий дополнительные данные	0₂	Проверяет, находится ли вызываемая АС на связи и может ли принять данный вызов немедленно (OACSU)
Речевая услуга (Service_Kind - 0000₂) Пакетные данные (Service_Kind - 0010₂)	Нисходящий PDU UDTHD, передающий дополнительные данные	1₂	Проверяет, готова ли вызываемая АС к принятию речевого или информационного вызова (FOACSU)
Все другие услуги	UDTHD	0₂	Зарезервировано

16.3.14 IE Service_Options (опция предоставления услуги)

16.3.14.1 Общие положения

Применяемые в IE Service_Options значения зависят от запрашиваемой услуги. IE Service_Options имеет длину 7 битов и представлен для каждой соответствующей услуги в 16.3.14.2 - 16.3.14.10.

16.3.14.2 Перечень значений, передаваемых в IE Service_Options для запроса услуги передачи речи

Информация для запроса услуги передачи речи представлена в таблице 136.

Таблица 136

Service_Options для запроса услуги передачи речи

IE	Длина, бит	Значение	Комментарий
Emergency	1	0₂	Неэкстренное обслуживание
Emergency	1	1₂	Экстренное обслуживание
Privacy	1	0₂	Конфиденциальность (R)
Supplementary Data	1	0₂	Нет услуг передачи дополнительных данных, необходимых для данного вызова
Supplementary Data	1	1₂	Для данного вызова требуется услуга передачи дополнительных данных
Broadcast (вещание)	1	0₂	Услуга нешироковещательного вызова
Broadcast (вещание)	1	1₂	Услуга широковещательного вызова <1>
R	1	0₂	Зарезервировано
Priority level	2	00₂	Обычный (низкий) приоритет
		01₂	Приоритет 1 <2>
		10₂	Приоритет 2 <2>
		11₂	Приоритет 3 <2>
<1> Широковещательный вызов применим к разговорным группам. <2> Приоритет 3 является высшим приоритетом.

16.3.14.3 Перечень значений Service_Options для запроса услуги "Пакетные данные"

Информация Service_Options для запроса услуги "Пакетные данные" представлена в таблице 137.

Таблица 137

Перечень значений Service_Options для запроса

услуги "Пакетные данные"

IE	Длина, бит	Значение	Комментарий
Emergency	1	0₂	Неэкстренное обслуживание
Emergency	1	1₂	Экстренное обслуживание
Privacy	1	0₂	Конфиденциальность (R)
Supplementary Data	1	0₂	Для данного вызова не требуется услуга передачи дополнительных данных
Supplementary Data	1	1₂	Для данного вызова запрашивается услуга передачи дополнительных данных
Hi Rate	1	0₂	Рабочий канал ожидает синхронизацию данных в одном таймслоте
Hi Rate	1	1₂	Рабочий канал ожидает синхронизацию данных в двух таймслотах
SIMI	1	0₂	Одноэлементные данные
SIMI	1	1₂	Многоэлементные данные
Priority level	2	00₂	Обычный (низкий) приоритет
		01₂	Приоритет 1 <1>
		10₂	Приоритет 2 <1>
		11₂	Приоритет 3 <1>
<1> Приоритет 3 является высшим приоритетом.

16.3.14.4 Service_Options для запроса услуги "Переадресация вызова"

Информация Service_Options для запроса услуги "Переадресация вызова" представлена в таблице 138.

Таблица 138

Перечень значений IE Service_Options для запроса

услуги "Переадресация вызова"

IE	Длина, бит	Значение	Комментарий
Emergency	1	0₂	Не применяется
Privacy	1	0₂	Конфиденциальность (R)
Divert On/Off	1	0₂	Удаление переадресации вызова
Divert On/Off	1	1₂	Установка переадресации вызова
Divert Kind	1	Активно 1₂; неактивно 0₂	Переадресация применима к речевым вызовам
	1		Переадресация применима к вызовам с пакетной передачей данных
	1		Переадресация применима к вызовам коротких данных
	1		Переадресация применима к вызовам состояния

16.3.14.5 Значения Service_Options для запроса услуги "Регистрация"

Информация Service_Options для запроса услуги "Регистрация" представлена в таблице 139.

Таблица 139

Перечень значений Service_Options для запроса

услуги "Регистрация"

IE	Длина, бит	Значение	Комментарий
R	1	0₂	-
Privacy	1	0₂	Конфиденциальность (R)
IP_Inform	1	0₂	АС не уведомляет о подключении к IP
IP_Inform	1	1₂	АС уведомляет о подключении к IP
PowerSave_RQ	3	000₂	Энергосбережение не запрашивается
PowerSave_RQ	3	001₂ - 111₂	Энергосбережение запрашивается
Reg_Dereg	1	0₂	Если IP_Inform = 0₂, то АС пытается удалить регистрацию. Если IP_Inform = 1₂, то АС удаляет подключение к IP
Reg_Dereg	1	1₂	Если IP_Inform = 0₂, то АС пытается зарегистрироваться Если IP_Inform = 1₂, то АС пытается зарегистрироваться и/или добавить подключение к IP

16.3.14.6 Перечень значений Service_Options для запроса услуги "Включение вызова"

Информация Service_Options для запроса услуги "Включение вызова" представлена в таблице 140. Запросы услуги включения вызова должны ограничиваться рабочим каналом.

Таблица 140

Перечень значений IE Service_Options для услуги

"Включение вызова"

IE	Длина, бит	Значение	Комментарий
R	1	0₂	-
Privacy	1	0₂	Конфиденциальность <1>
R	5	0 0000₂	-
<1> Конфиденциальность не определена в настоящем стандарте.

16.3.14.7 Перечень значений Service_Options для запроса услуги "Передача текущего состояния"

Информация Service_Options для запроса "Передача текущего состояния" представлена в таблице 141. Запросы услуги вызова "Передача текущего состояния" должны ограничиваться TSCC.

Таблица 141

Перечень значений Service_Options для услуги

"Передача текущего состояния"

IE	Длина, бит	Значение	Комментарий
G/I	1	0₂	Адрес получателя представляет собой индивидуальный АС ID
G/I	1	1₂	Адрес получателя представляет собой разговорную группу
Supplementary_user Data	1	0₂	Нет передачи запрошенных данных supplementary_user
Supplementary_user Data	1	1₂	Для данного вызова запрашиваются данные supplementary_user
Status (наиболее значимые 5 бит)	5	XXXXX₂	Наиболее значимые 5 бит текущего состояния, которые будут передаваться <1>
<1> Текущее состояние не является частью опции предоставления услуги, но представлено в данном подпункте для общего понимания.

16.3.14.8 Перечень значений Service_Options для запроса услуги "Короткие данные"

Информация Service_Options для запроса услуги "Короткие данные" представлена в таблице 142.

Таблица 142

Перечень значений Service_Options для запроса

услуги "Короткие данные"

IE	Длина, бит	Значение	Комментарий
Emergency	1	0₂	Не применимо - 0₂
Privace	1	0₂	Конфиденциальность (R)
Supplementary Data	1	0₂	Для данного вызова не запрашивается услуга "Передача дополнительных данных"
Supplementary Data	1	1₂	Для данного вызова запрашивается услуга "Передача дополнительных данных"
BCAST_SV	1	0₂	Не применимо - 0₂
R	1	0₂	Не применимо - 0₂
Priority	2	00₂	Не применимо - 00₂

16.3.14.9 Перечень значений Service_Options для запроса услуги "Дополнительные данные"

Информация Service_Options для запроса услуги "Дополнительные данные" представлена в таблице 143.

Таблица 143

Перечень значений Service_Options для запроса

услуги "Дополнительные данные"

IE	Длина, бит	Значение	Комментарий
Emergency	1	0₂	Не применимо - 0₂
Privacy	1	0₂	Конфиденциальность (R)
R	1	0₂	Не применимо - 0₂
R	1	0₂	Не применимо - 0₂
R	1	0₂	Не применимо - 0₂
Priority	2	00₂	Не применимо - 00₂

16.3.14.10 Перечень значений Service_Options для запроса услуги "Опрос коротких данных"

Информация Service_Options для запроса услуги "Опрос коротких данных" представлена в таблице 144.

Таблица 144

Перечень значений Service_Options для запроса

услуги "Опрос коротких данных"

IE	Длина, бит	Значение	Комментарий
Emergency	1	0₂	Не применимо - 0₂
Privacy	1	0₂	Конфиденциальность (R)
Supplementary Data	1	0₂	Не применимо - 0₂
Polling Format	4	0₂	Формат данных для опроса

16.3.15 IE Service_Options_Mirror

16.3.15.1 Service_Options_Mirror. Введение

IE Service_Options_Mirror передается в служебном сообщении PDU C_AHOY.

Если PDU C_AHOY передается как немедленное (или отложенное) подтверждение для запроса услуги C_RAND, то в IE Service_Options для служебного сообщения C_RAND PDU должны быть установлены значения IE Service_Options_Mirror.

16.3.15.2 Service_Options_Mirror для аутентификации АС

Если PDU C_AHOY передан как результат опроса PDU от TSCC для аутентификации, то Service_Option_Mirror должен быть установлен для значений, определенных в таблице 145.

Таблица 145

Service_Options_Mirror для опроса аутентификации АС

IE		Длина, бит	Значение	Комментарий
Service_Options_Mirror	R	1	0₂	-
	Конфиденциальность (R)	1	0₂	-
	R	5	0 0000₂	-

16.3.15.3 Service_Options_Mirror для блокирования/разблокирования АС

Если служебное сообщение PDU C_AHOY передано (как результат запроса служебными сообщениями с использованием PDU) TSCC для блокирования/разблокирования АС, то в Service_Option_Mirror должны быть установлены значения, определенные в таблице 146.

Таблица 146

Значения IE Service_Options_Mirror для выполнения

запроса "Заблокировать/разблокировать АС"

IE		Длина, бит	Значение	Комментарий
Service_Options_Mirror	R	1	0₂	-
	Конфиденциальность (R)	1	0₂	-
	R	5	0 0000₂	-
Примечание - Блокирование/разблокирование является вторичной услугой.

16.3.15.4 Service_Options_Mirror для приведения АС в неработоспособное состояние

Если служебное сообщение C_AHOY PDU передано как результат запроса служебными сообщениями с использованием PDU TSCC для приведения АС в неработоспособное состояние, то значения IE Service_Option_Mirror должны быть установлены в соответствии с указанными в таблице 147.

Таблица 147

Service_Options_Mirror для приведения АС

в неработоспособное состояние

IE		Длина, бит	Значение	Комментарий
Service_Options_Mirror	R	1	0₂	-
	Конфиденциальность (R)	1	0₂	-
	R	5	0 0000₂	-

16.3.16 IE Proxy Flag (флаг прокси)

Для вызовов абонентов, подключенных через шлюз ТС, флаг прокси должен указывать количество AD с использованием процедуры UDT, необходимых для загрузки адреса конечного пункта назначения. Для вызова PABX или PSTN один блок UDT AD будет содержать до 20 набранных цифр, а два блока UDT дополнительных данных будут содержать до 44 набранных цифр.

Таблица 148

Перечень возможных значений IE Proxy Flag

IE	Длина, бит	Значение	Комментарий
Proxy Flag	1	0₂	Количество UDT дополнительных данных, необходимых для загрузки адреса конечного пункта назначения, равно 1. Количество цифр расширенного BCD для адресации через шлюз PSTN/PABX составляет от 1 до 20. Для шлюза IP extended_address соответствует IPV4
Proxy Flag	1	1₂	Количество UDT расширенных данных, необходимое для загрузки адреса конечного пункта назначения, равно 2. Количество цифр расширенного BCD для адресации через шлюз PSTN/PABX gateway составляет от 21 до 44. Для шлюза IP extended_address соответствует IPV6

16.3.17 IE POL_FMT (формат данных опроса)

При использовании услуги коротких информационных сообщений, которая позволяет опрашивать данные у АС с использованием TSCC для всех значений POL_FMT в диапазоне от 0000₂ до 1001₂, POL_FMT должен быть установлен формат данных опроса из процедуры "Опрос коротких данных", определенной в 7.5.4.4. POL_FMT, установленный в значение 1010₂, устанавливает услугу "Опрос состояния", определенную в 7.5.4.3. Иные значения приведены в таблице 149.

Таблица 149

Перечень возможных значений IE POL_FMT

IE	Длина, бит	Значение	Комментарий
POL_FMT	4	0000₂	Двоичное
		0001₂	Адреса ТС
		0010₂	BCD 4 бита
		0011₂	Семибитный набор символов ISO (см. [2])
		0100₂	Восьмибитный набор символов ISO (см. [3])
		0101₂	Информация о местоположении NMEA
		0110₂	Адрес IP
		0111₂	Символы шестнадцатибитового Unicode UTF-16BE
		1000₂	Опционально <1>
		1001₂	Опционально <1>
		1010₂	Состояние
		1011₂	Зарезервировано
		1100₂	Зарезервировано
		1101₂	Зарезервировано
		1110₂	Зарезервировано
		1111₂	Зарезервировано
<1> Определяется производителем.

16.3.18 IE UAB

Если услуга "Дополнительные данные" была вызвана в качестве опции с другими речевыми или информационными услугами, то IE Appended_Supplementary_Data должен быть использован для указания количества передаваемых UDT блоков AD, необходимых для загрузки этих данных.

Если была вызвана услуга "Короткие данные", IE Appended_Short_Data используется АС для передачи количества блоков AD, необходимых для загрузки коротких данных. Перечень значений IE Appended_Supplementary_Data приведен в таблице 150.

Таблица 150

Перечень значений IE Appended_Supplementary_Data

IE	Длина, бит	Имя	Значение	Комментарий
Appended_Block	2	UAB	00₂	Количество UDT AD, необходимое для загрузки дополнительных данных, равно 1
			01₂	Количество UDT AD, необходимое для загрузки дополнительных данных, равно 2
			10₂	Количество UDT AD, необходимое для загрузки дополнительных данных, равно 3
			11₂	Количество UDT AD, необходимое для загрузки дополнительных данных, равно 4

16.3.19 IE Opcode (код операции)

IE Opcode определяет функцию "Заголовок CSBK/MBC/UDT". IE Opcode приведен в таблице 151.

Таблица 151

Opcode

IE	Длина, бит	Значение	Комментарий
Opcode	6	См. комментарий	Определено в Б.1
			Другие значения зарезервированы

16.3.20 IE Announcement_type (тип объявления)

16.3.20.1 Формат типа объявления

IE Announcement_type Format Code (код формата типа объявления) имеет длину 5 бит и показан на рисунке 79, на котором представлена структура и иерархия служебных сообщений, передаваемых с использованием PDU в восходящем направлении TSCC от АС к ТС. Перечень значений IE Announcement_type приведен в таблице 152.

Таблица 152

Перечень значений IE Announcement_type

IE	Длина, бит	Значение	Имя	Комментарий
Announcement_type	5	0 0000₂	Ann_WD_TSCC	Объявленный/удаленный TSCC
		0 0001₂	CallTimer_Parms	Временные параметры установления вызова
		0 0010₂	Vote_Now	Смена TSCC
		0 0011₂	Local_Time	Местное время широковещательного вызова
		0 0100₂	MassReg	Mass_Registration
		0 0101₂	Chan_Freq	Объявление логического канала/частоты соединения
		0 0110₂	Adjacent_Site	Информация о соседнем сайте
		0 0111₂ - 1 1101₂	-	Зарезервировано
		1 1110₂	-	Опционально <1>
		1 1111₂	-	Опционально <1>
<1> Определяется производителем.

16.3.20.2 Объявление/удаление TSCC (Ann-WD_TSCC)

Перечень значений IE "Объявление/удаление TSCC" приведен в таблице 153.

Таблица 153

Перечень значений IE "Объявление/удаление TSCC"

IE	Длина, бит	Значение	Имя	Комментарий
Broadcast Parms 1 (параметры вещания 1)	4	0₂	-	Зарезервировано
	4	XXXX₂	-	CC для CH_1 (по умолчанию = 0000₂)
	4	XXXX₂	-	CC для CH_2 (по умолчанию = 0000₂)
	1	0₂	AW_FLAG1	Добавление BCAST_CH1 в список поиска
	1	1₂	AW_FLAG1	Удаление BCAST_CH1 из списка поиска
	1	0₂	AW_FLAG2	Добавление BCAST_CH2 в список поиска
	1	1₂	AW_FLAG2	Удаление BCAST_CH2 из списка поиска
Broadcast Parms 2 (параметры вещания 2)	12	От 0 или 1 до 4095	BCAST_CH1	CHNULL или логический номер физического канала
Broadcast Parms 2 (параметры вещания 2)	12	От 0 или 1 до 4095	BCAST_CH2	CHNULL или логический номер физического канала

16.3.20.3 Определение временных параметров вызова (CallTimer_Parms)

Перечень значений IE, определяющего временные параметры вызова, приведен в таблице 154.

Таблица 154

Значения IE, определяющего временные параметры вызова

IE	Длина, бит	Значение	Имя	Комментарий
Broadcast Parms 1 (параметры вещания 1)	9	0	T_EMERG_TIMER	АС использует свой внутренний таймер экстренной связи
		1 - 510		Таймер вызова для экстренных вызовов (см. А.2)
		511		Таймер экстренных вызовов не ограничен
Broadcast Parms 1 (параметры вещания 1)	5	0	T_PACKET_TIMER	АС использует свой внутренний таймер пакетов
		1 - 30		Таймер вызовов для пакетной передачи данных (см. А.2)
		31		Таймер пакетных вызовов не ограничен
Broadcast Parms 2 (параметры вещания 2)	12	0	T_MS-MS_TIMER	АС использует свой внутренний таймер для вызовов АС - АС
		1 - 4094		Таймер вызовов для вызовов АС - АС (см. А.2)
		4095		Таймер вызовов АС - АС не ограничен
Broadcast Parms 2 (параметры вещания 2)	12	0	T_MS-LINE_TIMER	АС использует свой внутренний таймер для вызовов соединительной линии
		1 - 4094		Таймер вызовов для вызовов соединительной линии (см. А.2)
		4095		Таймер вызовов соединительной линии не ограничен

16.3.20.4 IE "Смена TSCC" (Vote_Now)

Перечень значений IE "Смена TSCC", определяющего логический рабочий канал, приведен в таблице 155.

Таблица 155

Перечень значений элемента "Смена TSCC"

IE	Длина, бит	Значение	Имя	Комментарий
Broadcast Parms 1 (параметры вещания 1)	14	-	-	Оцениваются наиболее значимые 14 бит идентификационного кода системы TSCC
Broadcast Parms 2 (параметры вещания 2)	1	-	-	Если 1, информация Active_connection доступна, если 0, информация Active_connection не доступна
	1	-	-	Active_connection
	3	-	-	Подтвержденный приоритет канала
	3	-	-	Приоритет соседнего канала
	4	0000₂	R	-
	12	1 - 4095	CH_VOTE	Оценен номер физического канала

Возможные значения IE "Смена TSCC", определяющего логический рабочий канал:

а) если CH_VOTE = 0000 0000 0000₂, то номер физического канала неверен;

б) если CH_VOTE находится в пределах от 0000 0000 0001₂ до 1111 1111 1110₂, то номер физического канала представляет собой номер логического канала для физической частоты передатчика и приемника. PDU Vote Now Advice передается на TSCC как CSBK;

в) если CH_VOTE = 1111 1111 1111₂, номер физического канала определяет MBC, где абсолютная частота передатчика и приемника определена во втором блоке, соединенном с данным блоком в соответствии с подпунктом "Добавленный PDU MBC абсолютных параметров смены TSCC (VN_AP)".

Добавленный PDU MBC абсолютных параметров смены TSCC (VN_AP)

Второй (в продолжение) блок MBC смены TSCC согласовывает формат, определенный в таблице 156. PDU CdefParms определен в 16.3.20.8, описывающем связь с абсолютной частотой работы, а физические характеристики радиоканала описаны в приложении Б.

Таблица 156

Содержание добавленного PDU MBC VN_AP

IE	Длина, бит	Комментарий
Зависимые элементы сообщений
LB	1	Данный бит должен быть установлен в значение 1₂, потому что данный PDU добавляется, либо применим, к заголовку MBC "Предоставление канала"
PF	1	-
Общие элементы
CSBKO	6	Должен устанавливаться для CSBKO первого блока MBC
R	4	0000₂
CC	4	CC используется для физического канала пункта назначения
Cdeftype	4	Значение CdefParms (см. 16.3.20.8)
R	2	00₂
CdefParms	58	IE, описывающие связь частоты логического/физического канала

16.3.20.5 Местное время широковещательного вызова (Local_Time)

Общий перечень значений

Общий перечень значений IE Local_Time приведен в таблице 157.

Таблица 157

Местное время широковещательного вызова

IE	Длина, бит	Значение	Имя	Комментарий
Broadcast Parms 1 (параметры вещания 1)	5	-	B_DAY	День месяца от 1 до 31 (или 0, если дата не транслировалась)
	4	-	B_MONTH	Месяц от 1 до 12 (или 0, если месяц не транслировался)
	5	-	UTC_OFFSET	Смещение между локальным временем и временем MCB [как число в диапазоне от 0 до 23 (или 11111₂, если смещение не транслировалось)]
Broadcast Parms 2 (параметры вещания 2)	5	-	B_HOURS	Часы от 0 до 23
	6	-	B_MINS	Минуты от 0 до 59
	6	-	B_SECS	Секунды от 0 до 59
	3	-	DAYOF_WEEK	День недели (или 0, если в этот день недели не было широковещательного вызова)
	2	00₂	UTC_OFFSET_F R ACTION	Нет дополнительного смещения
		01₂		Добавление 15 минут
		10₂		Добавление 30 минут
		11₂		Добавление 45 минут
	2	00₂	R	Зарезервировано

Содержание IE значений B_MONTH и DAYOF_WEEK определяется в таблицах 158 и 159.

Местное время широковещательного вызова - месяц (B_MONTH)

Таблица 158

Перечень значений IE B_MONTH

IE	Длина, бит	Значение	Комментарий
B_MONTH	4	0000₂	Месяц не транслируется
		0001₂	Январь
		0010₂	Февраль
		0011₂	Март
		0100₂	Апрель
		0101₂	Май
		0110₂	Июнь
		0111₂	Июль
		1000₂	Август
		1001₂	Сентябрь
		1010₂	Октябрь
		1011₂	Ноябрь
		1100₂	Декабрь

Местное время широковещательного вызова - день недели (DAYSOF_WEEK)

Таблица 159

Перечень значений IE DAYSOF_WEEK

IE	Длина, бит	Значение	Комментарий
DAYSOF_WEEK	3	000₂	Дни недели не транслируются
		001₂	Воскресенье
		010₂	Понедельник
		011₂	Вторник
		100₂	Среда
		101₂	Четверг
		110₂	Пятница
		111₂	Суббота

16.3.20.6 Широковещательный запрос регистрации (MassReg)

Тип вызова

Перечень значений IE "Широковещательный запрос регистрации" приведен в таблице 160.

Таблица 160

Перечень значений IE "Широковещательный запрос регистрации"

IE	Длина, бит	Значение	Имя	Комментарий
Broadcast Parms 1 (параметры вещания 1)	5	0 0000₂	-	Зарезервировано
	4	-	-	Reg_Window
	5	-	-	"Маска" Aloha
Broadcast Parms 2 (параметры вещания 2)	24	-	-	ADRNULL или индивидуальный адрес АС

IE Reg_Window

Перечень значений IE Reg_Window приведен в таблице 161.

Таблица 161

Перечень значений IE Reg_Window

IE	Длина, бит	Значение	Время задержки, с	Комментарий
Reg_Window	4	0	-	Аннулирование регистрации массива
		1	0,5	Значения в секундах
		2	1
		3	2
		4	5
		5	10
		6	20
		7	30
		8	100
		9	300
		10	1 000
		11	3 000
		12	10 000
		13	30 000
		14	100 000
		15	200 000

16.3.20.7 Информация о соседнем сайте широковещательного вызова

Перечень значений IE "Информация о соседнем сайте широковещательного вызова" приведен в таблице 162.

Таблица 162

Перечень значений IE "Информация о соседнем сайте

широковещательного вызова"

IE	Длина, бит	Значение	Положение	Комментарий
Broadcast Parms 1 (параметры вещания 1)	14	-	-	Наиболее значимые 14 битов идентификационного кода системы TSCC, которые были оценены
Broadcast Parms 2 (параметры вещания 2)	1	-	-	Если 1, информация Active_connection доступна, если 0, информация Active_connection недоступна
	1	-	-	Active_connection
	3	-	-	Подтвержденный приоритет канала
	3	-	-	Приоритет соседнего канала
	4	0000₂	R	-
	12	1 - 4095	CH_ADJ	Номер физического канала соседнего сайта, который будет оценен

16.3.20.8 Связь с абсолютной частотой CdefParms

Перечень значений IE CdefParms приведен в таблице 163.

Таблица 163

Перечень значений IE CdefParms

CdefParms	IE	Длина, бит	Значение	Имя	Комментарий
Cdeftype = 0000₂	Номер логического физического канала	12	-	CHAN	-
	Абсолютная частота передатчика - целое число в МГц	10	-	TXMHz	Абсолютная частота передатчика - целое число в МГц
	Абсолютная частота передатчика	13	-	TXKHz	Отображение частоты передатчика в МГц с шагом в 125 Гц
	Абсолютная частота приемника - целое число в МГц	10	-	RXMHz	Абсолютная частота приемника - целое число в МГц
	Абсолютная частота приемника	13	-	RXKHz	Отображение частоты приемника в МГц с шагом в 125 Гц
Cdeftype = 0001₂ - 1111₂	-	58	Зарезервировано

Механизм расчета абсолютной частоты определен в приложении Б.

16.3.21 IE (групповой или индивидуальный) (G/I)

Перечень значений IE G/I приведен в таблице 164.

Таблица 164

Значения IE G/I

IE	Длина, бит	Значение	Имя	Комментарий
G/I	1	0₂	G/I	IE об адресе адрес получателя в PDU представляет индивидуальный адрес АС
G/I	1	1₂	G/I	IE об адресе адрес получателя в PDU представляет разговорную группу

16.3.22 IE Protect_Kind (вид защиты)

Перечень значений IE Protect_Kind приведен в таблице 165.

Таблица 165

Перечень значений IE Protect_Kind

IE	Длина, бит	Значение	Имя	Комментарий
Protect_Kind	3	000₂	DIS_PTT	Запрещение передачи конкретной АС или разговорной группе
		001₂	EN_PTT	Разрешение передачи конкретной АС или разговорной группе
		010₂	ILLEGALLY_PARKED	Отключение от рабочего канала АС, чей адрес не соответствует адресам источника или назначения
		011₂	EN_PTT_ONE_MS	Разрешение PTT для АС, соответствующей адресу назначения. Все другие АС запрещены
		100₂	R	Зарезервировано
		101₂	R	Зарезервировано
		110₂	R	Зарезервировано
		111₂	R	Зарезервировано

16.3.23 IE Maint_Kind (вид обслуживания)

Перечень значений IE Maint_Kind приведен в таблице 166.

Таблица 166

Перечень значений IE Maint_Kind

IE	Длина, бит	Значение	Имя	Комментарий
Maint_Kind	3	000₂	DISCON	Разъединение. Окончание использования рабочего канала
		001₂	R	Зарезервировано
		010₂	R	Зарезервировано
		011₂	R	Зарезервировано
		100₂	R	Зарезервировано
		101₂	R	Зарезервировано
		110₂	R	Зарезервировано
		111₂	R	Зарезервировано

16.3.24 IE Response_Requested (A) (запрошенный ответ)

Значения IE A приведены в таблице 167.

Таблица 167

Значения IE A

IE	Длина, бит	Значение	Имя	Комментарий
A	1	0₂	-	Ответ не ожидается
A	1	1₂	-	Ответ ожидается

16.3.25 IE Format (формат)

Перечень значений IE Format приведен в таблице 168.

Таблица 168

Перечень значений IE Format

IE	Длина, бит	Значение	Комментарий
Format	4	0000₂	Заголовок для UDT
		0001₂	Определен в ГОСТ Р 71586.1
		0010₂
		0011₂
		0100₂
		0101₂
		0110₂
		0111₂
		1000₂
		1001₂
		1010₂
		1011₂
		1100₂
		1101₂
		1110₂
		1111₂
Примечание - IE Format определен в ГОСТ Р 71586.1-2024 (пункт 15.5.14).

16.3.26 IE SAP (идентификатор точки доступа к услуге)

Значения IE SAP приведены в таблице 169.

Таблица 169

Перечень значений IE SAP

IE	Длина, бит	Значение	Комментарий
SAP	4	0000₂	UDT
		0001₂	Определен в ГОСТ Р 71586.1
		0010₂
		0011₂
		0100₂
		0101₂
		0110₂
		0111₂
		1000₂
		1001₂
		1010₂
		1011₂
		1100₂
		1101₂
		1110₂
		1111₂

16.3.27 IE PN (добавочный полубайт)

IE PN определяет количество добавочных полубайтов, которые добавляются к данным для формирования целого числа передаваемых блоков. IE PN для каждого формата данных, передаваемых с помощью процедуры UDT, определен в приложении Б. IE PN приведен в таблице 170.

Таблица 170

IE PN

IE	Длина, бит	Значение	Комментарий
PN	5	XXXXX₂	Количество добавочных полубайтов прилагается к данным

16.3.28 IE UDT_Format (формат UDT)

Определяет формат данных пользователя или системы, передаваемых в UDT для механизма UDT. Значения IE UDT_Format приведены в таблице 171.

Таблица 171

Значения IE UDT_Format

IE	Длина, бит	Значение	Комментарий
UDT_Format	4	0000₂	Двоичный
		0001₂	Адрес ТС или разговорной группы
		0010₂	Четырехбитное BCD
		0011₂	Семибитный набор символов ISO (см. [2])
		0100₂	Восьмибитный набор символов ISO (см. [3])
		0101₂	Закодированное местоположение NMEA (см. [1])
		0110₂	Адрес IP
		0111₂	Символы шестнадцатибитового Unicode UTF-16BE
		1000₂	Опционально <1>
		1001₂	Опционально <1>
		1010₂	Комбинированный. Добавленные блоки содержат адрес и символы Unicode UTF-16BE
		1011₂	Зарезервировано
		1100₂	Зарезервировано
		1101₂	Зарезервировано
		1110₂	Зарезервировано
		1111₂	Зарезервировано
<1> Закодированная программа пользователя (определяется производителем).

16.3.29 IE Offset (смещение)

IE определяет временное смещение нисходящего направления относительно входящего направления рабочего канала. Описание IE Offset приведено в таблице 172.

Таблица 172

IE Offset

IE	Длина, бит	Значение	Комментарий
Offset	1	0₂	Рабочий канал должен быть синхронизирован
Offset	1	1₂	Рабочий канал должен использовать сдвиг по времени

16.3.30 IE PF (флаг защиты)

Значение IE Флаг защиты приведено в таблице 173.

Таблица 173

Значение IE Флаг защиты

IE	Длина, бит	Значение	Комментарий
PF	1	0₂	Определен в ГОСТ Р 71586.1-2024 (пункт 15.5.9)

16.3.31 IE Privacy (конфиденциальность)

Значение IE Privacy приведено в таблице 174.

Таблица 174

Значение IE Privacy

IE	Длина, бит	Значение	Комментарий
Privacy	1	0₂	-

16.3.32 IE Status (состояние)

Перечень значений IE Status приведен в таблице 175.

Таблица 175

Перечень значений IE Status

IE	Длина, бит	Значение	Комментарий
Status	7	000 0000₂ - 110 0011₂	Значение Status верно для услуги "Доставка данных о состоянии"
		110 0100₂ - 111 1100₂	Зарезервировано
		111 1101₂	Значение Status для услуги "Прерывание передачи"
		111 1110₂	Значение Status для аварийной сигнализации
		111 1111₂	Значение Status для услуги "Опрос состояния"

16.3.33 IE Version (версия)

IE Version указывает номер версии, которой соответствует система. Значения IE Version приведены в таблице 176.

Таблица 176

Значения IE Version

IE	Длина, бит	Значение	Комментарий
Version	3	000₂	Данная система соответствует версии 1.5.1
		001₂	Данная система соответствует версии 1.6.1
		010₂	Данная система соответствует версии 1.7.1
		011₂ - 111₂	Зарезервировано

16.3.34 IE Target_Address_Contents (содержание адреса получателя)

IE Registration Service Target_Address_Contents (содержание адреса получателя услуги регистрации) определяет содержание адреса получателя или IE Gateway (шлюз) при запросе услуги регистрации. Значения IE Trg_Adr_Cnts приведены в таблице 177.

Таблица 177

Значения IE Trg_Adr_Cnts

IE	Длина, бит	Значение	Комментарий
TRGT_ADR_CNTS	2	00₂	00000000₂ + C_SYSCode
		01₂	ID подписки разговорной группы
		10₂	TATTSI
		11₂	Зарезервировано

16.3.35 IE Payload Channel Type (тип рабочего канала)

IE Payload Channel Type определяет, является ли рабочий канал стандартным рабочим каналом или совмещенным TSCC, как представлено в таблице 178.

Таблица 178

Payload Channel Type

IE	Длина, бит	Значение	Комментарий
Payload Channel Type	1	0₂	Стандартный рабочий канал
Payload Channel Type	1	1₂	Рабочий канал является совмещенным TSCC

16.3.36 IE Site Time Slot Synchronization (синхронизация таймслотов сайта)

IE Site Time Slot Synchronization транслируется по TSCC. Он информирует, являются ли TSCC и все рабочие каналы синхронизированными таймслотами. IE Site Time Slot Synchronization имеет длину 1 бит и представлен в таблице 179.

Таблица 179

Site Time Slot Synchronization

IE	Длина, бит	Значение	Имя	Комментарий
Site Time Slot Synchronization	1	0₂	-	0₂ - TSCC и все рабочие каналы на сайте являются несинхронизированными таймслотами
Site Time Slot Synchronization	1	1₂	-	1₂ - TSCC и все рабочие каналы на сайте являются синхронизированными таймслотами

16.3.37 IE OK (флаг формата "Один ключ")

IE OK применяется к услуге DGNA и описан в таблице 180.

Таблица 180

IE OK

IE	Длина, бит	Значение	Формат адреса AD	Смешанный формат AD
OK	1	0₂	ADDRESS1 в AD UDT "Формат адресации" не является One-Key_talkgroup	ADDRESS в AD UDT "Смешанный формат" не является One-Key_talkgroup
OK	1	1₂	ADDRESS1 в AD UDT "Формат адресации" является One-Key_talkgroup	ADDRESS в AD UDT "Смешанный формат" является One-Key_talkgroup

16.3.38 IE SIMI (одноэлементные/многоэлементные данные)

IE SIMI имеет длину 1 бит и представлен в таблице 181.

Таблица 181

Значение IE SIMI

IE	Длина, бит	Значение	Имя	Комментарий
SIMI	1	0₂	-	0₂ - одноэлементные данные
SIMI	1	1₂	-	1₂ - многоэлементные данные

17 Требования к физическому уровню стека протоколов (уровень 1)

Оборудование цифровой ППР по требованиям к физическому уровню радиоинтерфейса должно соответствовать:

- в случае использования цифрового режима работы - ГОСТ Р 56172;

- в случае использования аналогового режима работы - ГОСТ Р 56153 (в части, касающейся работы с разносом частот между соседними радиоканалами 12,5 кГц).

Технические требования к ряду параметров уточняются комплексом настоящих стандартов.

По требованиям устойчивости к климатическим и механическим воздействиям оборудование цифровой ППР должно соответствовать ГОСТ Р 56172, а ретрансляторы и ТС, кроме того, должны соответствовать требованиям ГОСТ 15150. При необходимости изготовления взрывозащищенного оборудования цифровой ППР должны быть выполнены требования ГОСТ 31610.15 и ГОСТ 31610.10-1.

17.1 Отклонение частоты передатчика транкинговой станции от номинального значения

Максимальное отклонение частоты передатчика ТС от номинального значения на заданной центральной несущей РЧ определено в таблице 182.

Таблица 182

Отклонение частоты передатчика ТС

Частотный диапазон	Максимальное отклонение частоты передатчика ТС
30 МГц - 300 МГц	+/- 2 ppm
300 МГц - 600 МГц	+/- 1 ppm
600 МГц - 800 МГц	+/- 0,75 ppm
800 MHz - 1 ГГц	+/- 0,3 ppm

17.2 Временные параметры таймслотов в режиме с ретрансляцией в восходящем канале

В восходящем канале ТС передаются общие пакеты физического уровня и пакеты со специальным RC. В нисходящем канале передаются пакеты с CACH и пакеты с выделенным RC.

Для восходящего канала структура кадра TDMA и структура таймслотов (пакетов) показана на рисунке 107.

Рисунок 107 - Кадр TDMA

Временные параметры для обычных пакетов восходящего канала приведены в ГОСТ Р 71586.1-2024 (приложение И).

Каждый кадр TDMA длиной 60 мс и состоит из двух пакетов с таймслотами по 30 мс. Обычно первый вызов использует таймслот 1 (пакет 1), а другой вызов использует таймслот 2 (пакет 2). Вызовы состоят из серии равных таймслотов. Информация, которая передается в таймслоте, размещается в его середине.

17.2.1 Общий пакет

Требования к общему пакету соответствуют ГОСТ Р 71586.2-2024 (пункт 17.2.1).

17.2.1.1 Общий пакет. Введение

Общий пакет должен использоваться для передачи речи, данных и управления. Он предусматривает 264 бита данных в пакете со скоростью передачи данных до 4,4 Кбит/с. Это пакет, используемый для большинства приложений.

17.2.1.2 Время линейного изменения мощности

Требования к времени линейного изменения мощности соответствуют ГОСТ Р 71586.2-2024 (подпункт 17.2.1.2).

17.2.1.3 Распределение символов во времени

Распределение символов во времени приведено в ГОСТ Р 71586.1-2024 (подраздел 17.2).

17.2.1.4 Время задержки распространения и передачи

Требования к времени распространения и передачи соответствуют ГОСТ Р 71586.2-2024 (подпункт 17.2.1.4).

17.2.2 Пакет RC - общее описание

Пакет RC является коротким пакетом, который может использоваться для обеспечения низкоскоростного канала передачи данных.

17.2.3 Время линейного изменения мощности канала RC

Требования к времени линейного изменения мощности канала RC соответствуют ГОСТ Р 71586.2-2024 (пункт 17.2.3).

17.2.4 Распределение во времени символов пакетов RC

Требования к распределению во времени символов пакетов RC соответствуют ГОСТ Р 71586.2-2024 (пункт 17.2.4).

17.2.5 Задержка распространения RC

Поскольку пакет короткий, то нет никакой опасности межслотового наложения, как это происходит с общим пакетом. Однако задержку распространения рассматривают, потому что она затрагивает случай, когда приемник нуждается в поиске пакета RC. Допуск распространения - 1 мс.

17.2.6 Ограничения времени синхронизации опорного генератора синтезатора частот

Требования к ограничению времени синхронизации опорного генератора синтезатора частот соответствуют ГОСТ Р 71586.2-2024 (пункт 17.2.6).

17.2.7 Ограничения кратковременного изменения частоты во время передачи символа

Требования к ограничению кратковременного изменения частоты во время передачи символа соответствуют ГОСТ Р 71586.2-2024 (пункт 17.2.7).

18 Требования к встроенной диагностике транкинговой станции

Требования к встроенной диагностике ТС соответствуют ГОСТ Р 71586.2-2024 (раздел 18).

Приложение А

(обязательное)

ФУНКЦИИ ИНДИКАЦИИ ВРЕМЕНИ, ПОСТОЯННЫЕ УРОВНИ И АДРЕСА

А.1 Таймеры, постоянные уровни и адреса - введение

Данное приложение перечисляет таймеры, а также постоянные уровни и адреса в АС настоящего стандарта.

Там, где это указано, значение должно выбираться из указанного диапазона. Для других таймеров и констант может быть задано значение по умолчанию и значение этих таймеров и констант должно быть реконфигурируемо в объекте (АС, ретранслятор или ТС).

А.2 Таймеры для оборудования транкинговых сетей

Таймеры уровня 3 приведены в таблице А.1.

Таблица А.1

Таймеры уровня 3

Мнемокод	Значение	Описание
Trand_TCh	2 секунды - 60 секунд	Тайм-аут для ТС, пытающейся осуществить случайный доступ
T_Nosig	1 секунда - 15 секунд	Тайм-аут для ввода процедур поиска, если не принят TSCC
T_EMERG_TIMER	1 секунда - 510 секунд	Аварийный таймер. См. таблицу А.2
T_EMERG_TIMER	511 секунд	Аварийный таймер не ограничен
T_PACKET_TIMER	1 секунда - 30 секунд	Пакетный таймер. См. таблицу А.3
T_PACKET_TIMER	31 секунда	Пакетный таймер не ограничен
T_MS-MS_TIMER	1 секунда - 4094 секунды	Таймер АС - АС. См. таблицу А.4
T_MS-MS_TIMER	4095 секунд	Таймер АС - АС не ограничен
T_MS-LINE_TIMER	1 секунда - 4094 секунды	Таймер АС - линия связи. См. таблицу А.5
T_MS-LINE_TIMER	4095 секунд	Таймер АС - линия связи не ограничен
TP_Timer	4 секунды - 60 секунд	Тайм-аут для вызываемой АС, ожидающей вызова, который требует рабочий канал
TNP_Timer	2 секунды - 60 секунд	Тайм-аут для вызываемой АС, ожидающей вызова, который не требует рабочий канал
T_Awake	0,1 секунды - 60 секунд	Время АС активно после приема PDU (с шагом 0,1 секунды)
TV_Hangtime	1 секунда - 60 секунд	Таймер времени ожидания речи полезной нагрузки
TV_Inactive	0 секунд - 20 секунд	Таймер пассивности речи полезной нагрузки
TD_Inactive	0 секунд - 20 секунд	Таймер активности данных полезной нагрузки
TD_Item	1 секунда - 60 секунд	Таймер максимального элемента пакетных данных полезной нагрузки
TD_Hangtime	1 секунда - 60 секунд	Таймер ожидания данных полезной нагрузки
T_AnswerCall	2 секунды - 60 секунд	Тайм-аут для вызываемой АС после приема AHOY для FOASCU
T_Pending	2 секунды - 60 секунд	Тайм-аут для вызываемой АС после приема AHOY для OACSU
T_dereg	0,2 секунды - 2 секунды	Таймер для снятия с регистрации перед отказом с шагом 0,1 с
T_BS_Inactive	1 секунда - 300 секунд	Таймер для спящего режима, если не входящей операции на нерегулируемый TSCC
T_DENREG	0	Таймер отклонения регистрации неактивен
T_DENREG	1 секунда - 1000 секунд	Время действия отклонения регистрации с шагом 10 секунд (например, 1 = 10 с, 2 = 20 с и т.д.).
T_Late	4 секунды - 60 секунд	Временной интервал между PDU предоставления канала поздних сообщений

Маркеры таймера вызовов T_EMERG_TIMER приведены в таблице А.2.

Таблица А.2

Маркеры таймера вызовов T_EMERG_TIMER

Имя	Значение	Содержание
T_EMERG_TIMER	1 - 10	Таймер вызовов в секундах
	11 - 20	Таймер вызовов с шагом 5 с от: 11 = 15 с до 20 = 60 с
	21 - 28	Таймер вызовов с шагом 15 с от: 21 = 75 с до 28 = 180 с
	29 - 40	Таймер вызовов с шагом 30 с от - 29 = 3,5 минуты до 40 = 9 минут
	41 - 51	Таймер вызовов с шагом 30 с от - 41 = 10 минут до 51 = 20 минут
	52 - 510	Таймер вызовов с шагом 5 минут от - 52 = 25 минут до 510 = 2 315 минут
	511	Таймер вызовов неограничен

Маркеры таймера вызовов T_PACKET_TIMER приведены в таблице А.3.

Таблица А.3

Маркеры таймера вызовов T_PACKET_TIMER

Имя	Значение	Содержание
T_PACKET_TIMER	1 - 5	Таймер вызовов в секундах
	6 - 10	Таймер вызовов с шагом 5 с от - 6 = 10 с до 10 = 30 с
	11 - 12	Таймер вызовов с шагом 15 с от - 11 = 45 с до 12 = 60 с
	13 - 20	Таймер вызовов с шагом 30 с от - 13 = 1,5 минуты до 20 = 5 минут
	21 - 25	Таймер вызовов с шагом 1 минута от - 21 = 6 минут до 25 = 10 минут
	26 - 30	Таймер вызовов с шагом 5 минут от - 26 = 15 минут до 30 = 35 минут
	31	Таймер вызовов не ограничен

Маркеры таймера вызовов T_MS-MS_TIMER приведены в таблице А.4.

Таблица А.4

Маркеры таймера вызовов T_MS-MS_TIMER

Имя	Значение	Содержание
T_MS-MS_TIMER	1 - 59	Таймер вызовов в секундах
	60 - 107	Таймер вызовов с шагом 5 с от - 60 = 60 с до 107 = 295 с
	108 - 138	Таймер вызовов с шагом 30 с от - 108 = 5 минут до 138 = 20 минут
	139 - 4 094	Таймер вызовов с шагом 1 минута от - 139 = 21 минута до 4 094 = 3 976 минут
	4 095	Таймер вызовов не ограничен

Маркеры таймера вызовов T_MS-LINE_TIMER приведены в таблице А.5.

Таблица А.5

Маркеры таймера вызовов T_MS-LINE_TIMER

Имя	Значение	Содержание
T_MS-LINE_TIMER	1 - 59	Таймер вызовов в секундах
	60 - 107	Таймер вызовов с шагом 5 с от: 60 = 60 с до 107 = 295 с
	108 - 138	Таймер вызовов с шагом 30 с от: 108 = 5 минут до 138 = 20 минут
	139 - 4 094	Таймер вызовов с шагом 1 минута от: 139 = 21 минута до 4 094 = 3 976 минут
	4 095	Таймер вызовов не ограничен

А.3 Константы для оборудования транкинговых сетей

Константы для оборудования транкинговых сетей приведены в таблице А.6.

Таблица А.6

Постоянные уровня 3

Мнемокод	Значение	Описание
NDefault_NW	5	NRand_Wait при включении АС
NRand_NR	6	Количество попыток случайного доступа для услуг с обычным и высоким приоритетом
NRand_NE	10	Количество попыток случайного доступа для услуги с экстренным приоритетом
N_Maint	4	Количество PDU P_MAINT, передаваемых АС для разъединения рабочего канала
Nmax_Ch	50	Минимальное количество каналов в сокращенном списке поиска
Ch_Pref	50	Каналы, которые маркированы как предпочтительный TSCC для Vote_Now
Low_Comp_Ch	1 - 4 095	Низший логический канал используется сетью
High_Comp_Ch	Low_Comp_Ch - 4 095	Высший логический канал используется сетью
Comp_Flag	True/False	Аннулирование расширенного поиска (см. приложение Г)
NSYSerr	1 - 3	Количество принятых C_SYScodes, которые отличаются от проверенного значения
DMRLA	1 - 10	Длина информационного поля SYS_AREA из C_SYScode
VOTE_BLK	2 - 10	Количество кадров TDMA, когда TSCC отменяет случайный доступ после предложения "Смена TSCC"

А.4 Подуровни для оборудования транкинговых сетей

Уровни сигналов для оборудования транкинговых сетей приведены в таблице А.7.

Таблица А.7

Уровни сигналов для оборудования транкинговых сетей

Мнемокод	Значение	Описание
L_Upper_SHort	Структурные элементы и значения определяются производителем	Порог качества сигнала, при превышении которого сигнал будет опробован первым в коротком поиске
L_Lower_SHort		Порог качества сигнала, ниже которого АС не сможет стать активной
L_Squelch		Уровень сигнала (или эквивалент), ниже которого физические каналы должны быть отклонены, поскольку качество принимаемого сигнала не соответствует требованиям.
L_Power_Hi		Нижний предел дискретного значения уровня сигнала, принятого ТС для управления мощностью
L_Power_Low		Верхний предел выборки сигнала, принятого ТС для управления мощностью

А.5 Шлюзы/идентификаторы транкинговой сети

Шлюзы/идентификаторы транкинговой сети приведены в таблице А.8.

Таблица А.8

Шлюзы/идентификаторы

ID	Имя	Комментарий
FFFEC0₁₆	PSTNI	Адрес шлюза для услуг PSTN, использующих временную синхронизацию полезной нагрузки
FFFEC1₁₆	PABXI	Адрес шлюза для услуг PABX, использующих временную синхронизацию полезной нагрузки
FFFEC2₁₆	LINEI	Адрес для услуг для шлюза линии связи, использующих временную синхронизацию полезной нагрузки
FFFEC3₁₆	IPI	Адрес для услуг для шлюза IP, использующих временную синхронизацию полезной нагрузки
FFFEC4₁₆	SUPLI	Адрес используется для определения услуги дополнительных данных
FFFEC5₁₆	SDMI	Адрес используется для определения услуги коротких данных UDT
FFFEC6₁₆	REGI	Адрес используется для определения услуги регистрации
FFFEC7₁₆	MSI	Адрес шлюза для переадресации вызова для АС
FFFEC8₁₆	R	Зарезервировано
FFFEC9₁₆	DIVERTI	Адрес используется для определения аннулирования переадресации вызова
FFFECA₁₆	TSI	Адрес ТС
FFFECB₁₆	DISPATI	Адрес диспетчера системы, использующего временную синхронизацию полезной нагрузки
FFFECC₁₆	STUNI	Идентификатор блокирования/разблокирования АС
FFFECD₁₆	AUTHI	Идентификатор шлюза аутентификации
FFFECE₁₆	GPI	Адрес шлюза для переадресации вызова для разговорной группы
FFFECF₁₆	KILLI	Идентификатор KILL АС
FFFED0₁₆	PSTNDI	Адрес шлюза для услуг для PSTN, использующих синхронизацию со смещением полезной нагрузки
FFFED1₁₆	PABXDI	Адрес шлюза для услуг для PABX, использующих синхронизацию со смещением полезной нагрузки
FFFED2₁₆	LINEDI	Адрес для услуг для шлюза линии связи, использующей синхронизацию со смещением полезной нагрузки
FFFED3₁₆	DISPATDI	Адрес диспетчера системы, использующей синхронизацию со смещением полезной нагрузки
FFFED4₁₆	ALLMSI	Совокупность всех индивидуальных АС и разговорных групп
FFFED5₁₆	IPDI	Адрес для услуг для шлюза IP, использующего синхронизацию со смещением полезной нагрузки
FFFED6₁₆	DGNAI	Адрес для определения динамического присвоения групповых идентификаторов
FFFED7₁₆	TATTSI	Адрес для определения услуги "Подписка/приложение разговорной группы"
FFFFFD₁₆	ALLMSIDL	ID, используемый для адреса всех АС, находящихся на одном сайте, как разговорная группа
FFFFFE₁₆	ALLMSIDZ	ID, используемый для адреса всех АС в подгруппе сайтов системы, как разговорная группа
FFFFFF₁₆	ALLMSID	ID, используемый для адреса всех АС на каждом сайте в системе, как разговорная группа
000000₁₆	ADRNULL	ID, который не присвоен никакому объекту
000₁₆	CHNULL	Логический физический канал, который не назначен
1111₂	DigitNULL	Идентификатор, который используется для заполнения неиспользованных IE BCD

Приложение Б

(обязательное)

СПРАВОЧНЫЙ СПИСОК ОПЕРАЦИОННЫХ КОДОВ

Б.1 Список операционных кодов CSBK/MBC/UDT

Список операционных кодов CSBK/MBC/UDT приведен в таблице Б.1.

Таблица Б.1

Список операционных кодов CSBK/MBC/UDT

OPCODE	OPCODE₂	Описание	Имя
Предоставление канала
48	11 0000₂	Предоставление конфиденциального речевого канала (R)	PV_GRANT
49	11 0001₂	Предоставление речевого канала разговорной группы	TV_GRANT
50	11 0010₂	Предоставление конфиденциального широковещательного речевого канала (R)	BTV_GRANT
51	11 0011₂	Предоставление конфиденциального канала передачи данных: одноэлементный (R)	PD_GRANT
52	11 0100₂	Предоставление канала передачи данных разговорной группы: одноэлементный	TD_GRANT
53	11 0101₂	Предоставление дуплексного конфиденциального речевого канала (R)	GRANT_DX
54	11 0110₂	Предоставление дуплексного конфиденциального канала передачи данных (R)	GRANT_DX
55	11 0111₂	Предоставление конфиденциального канала передачи данных: многоэлементный (R)	GRANT_MI
56	11 1000₂	Предоставление канала передачи данных разговорной группы: многоэлементный	GRANT_MI
Перемещение
57	11 1001₂	Перемещение PDU	C_MOVE
Приветствие Aloha
25	01 1001₂	PDU Aloha для протокола случайного доступа	C_ALOHA
Оповещение
40	10 1000₂	Оповещение о PDU, которые не требуют ответа. Объявление/удаление TSCC. Таймеры определения вызовов. Предложение смены TSCC. Объявление местного времени. Широковещательный запрос регистрации. Объявление о связи логического физического канала. Объявление информации о соседнем сайте	C_BCAST
46	10 1110₂	Сброс вызова	P_CLEAR
47	10 1111₂	Защита	P_PROTECT
Приветствие Ahoy PDU
28	01 1100₂	Ahoy - запрос от TSCC, который требует ответа от АС	C_AHOY P_AHOY
Подтверждение
32	10 0000₂	Подтверждение ответа нисходящего TSCC	C_ACKD
33	10 0001₂	Подтверждение ответа восходящего TSCC	C_ACKU
34	10 0010₂	Подтверждение ответа нисходящей полезной нагрузки	P_ACKD
35	10 0011₂	Подтверждение ответа восходящей полезной нагрузки	P_ACKU
Заголовок UDT
26	01 1010₂	Нисходящий заголовок передачи унифицированных данных	C_UDTHD
27	01 1011₂	Восходящий заголовок передачи унифицированных данных	C_UDTHU
36	10 0100₂	Передача унифицированных данных для нисходящего заголовка DGNA	C_DGNAHD
37	10 0101₂	Передача унифицированных данных для восходящего заголовка DGNA	C_DGNAHU
Запрос услуги "Случайный доступ"
31	01 1111₂	Запрос услуги "Случайный доступ"	C_RAND
Ответ на приглашение
30	01 1110₂	Ответ на приглашение PDU	C_ACKVIT
Поддержка PDU
42	10 1010₂	Поддержка	P_MAINT

Б.2 Короткий список операционных кодов управления каналом связи

Список операционных кодов SLCO приведен в таблице Б.2.

Таблица Б.2

Список операционных кодов SLCO

SLCO	Описание	Имя
0000₂	Нулевое сообщение	- <1>
0001₂	Обновление операции	- <1>
0010₂	Параметры системы TSCC и счетчик таймслотов	SYS_Parm
0011₂	Параметры системы рабочего канала	P_SYS_Parms
0100₂ - 1011₂	R	-
1100₂ - 1111₂	Опционально	- <2>
<1> Определено в ГОСТ Р 71586.2. <2> Определяется производителем.

Б.3 IE AD

Б.3.1 IE AD - введение

PDU UDT может передавать IE. PDU заголовка UDT передает адреса источника и пункта назначения и IE UDT_Format, который описывает формат AD.

Заголовок UDT является первым блоком многоблокового UDT. Количество блоков, создающих многоблоковый UDT, определяется IE Appended_Blocks. Все PDU определены в 7.2.

Структура заголовка UDT показана на рисунке Б.1.

Рисунок Б.1 - Блок заголовка UDT

Б.3.2 Двоичный формат AD

AD двоично-кодированные. Для формирования многоблокового PDU UDT с заголовком UDT может быть объединено до четырех добавленных блоков UDT. Может быть передано до 368 битов. Для передачи двоичного формата IE PN в заголовке UDT установлен в значение 0 0000₂. Если передаются двоичные данные переменной длины, последний бит данных пользователя может определяться следующим образом:

- 0₂ добавляется к данным пользователя и остаточным битам для заполнения блока UDT, который устанавливается в 1₂. Затем передаются заголовок UDT и добавленные блоки;

- приемник может определить конец данных пользователя путем подсчета в обратном направлении до первого 0₂, который будет достигнут. Такая точка является одним битом после данных пользователя;

- в этом случае максимальное количество битов AD составляет 96, умноженное на три, плюс 79, итого 367 бит.

На рисунках Б.2 - Б.5 предполагается, что передаются двоичные данные переменной длины.

Рисунок Б.2 - Формат передачи унифицированных данных

(двоичный) от 1 до 79 бит

Один добавленный UDT может передавать от 1 до 79 бит (потому что последний информационный бит должен определяться посредством добавления 0₂ к концу данных пользователя).

Рисунок Б.3 - Формат передачи унифицированных данных

(двоичный) от 80 до 175 бит

Два добавленных UDT могут передавать от 80 до (96 плюс 79), итого 175 бит.

Рисунок Б.4 - Формат передачи унифицированных данных

(двоичный) от 176 до 271 бит

Три добавленных UDT могут передавать от 176 до (96 плюс 96 плюс 79), итого 271 бит.

Рисунок Б.5 - Формат передачи унифицированных данных

(двоичный) от 272 до 376 бит

Четыре добавленных UDT могут передавать от 272 до (96 плюс 96 плюс 96 плюс 79), итого 367 бит.

Б.3.3 Формат адресации AD

AD представляют собой кодированный адрес (24 бита). Один UDT AD может быть соединен с заголовком AD UDT для формирования многоблокового PDU UDT. До трех адресов может передаваться, дополняя один блок, семь адресов, дополняя два блока, одиннадцать адресов, добавляя три блока, и 15 адресов, добавляя четыре блока.

IE неиспользуемых адресов заполняются ADRNULL.

На рисунках Б.6 - Б.9 представлены форматы адреса AD (для трех, семи, 11 и 15 адресов).

Рисунок Б.6 - Формат адреса AD (3 адреса)

Рисунок Б.7 - Формат адреса AD (7 адресов)

Рисунок Б.8 - Формат адреса AD (11 адресов)

Рисунок Б.9 - Формат адреса AD (15 адресов)

Б.3.4 Формат BCD AD

AD закодированы BCD. До четырех UDT AD могут объединяться с заголовком AD UDT для формирования многоблокового PDU UDT. Может передаваться до 92 цифр BCD. IE PN в заголовке UDT определяет количество четырехбитных полубайтов (1111₂), которые были добавлены к цифрам пользователя, чтобы полностью заполнить блок.

Количество цифр BCD пользователя и соответствующее значение UAB и PN представлены в таблице Б.3.

В 16.3.10 приведено сокращенное кодирование, если цифры BCD представляют набранные комбинации телефонных номеров.

Таблица Б.3

Связь цифр BCD пользователя, UAB и IE PN

Цифры BCD пользователя	UAB	PN
1	0	19
2	0	18
3	0	17
4	0	16
5	0	15
6	0	14
7	0	13
8	0	12
9	0	11
10	0	10
11	0	9
12	0	8
13	0	7
14	0	6
15	0	5
16	0	4
17	0	3
18	0	2
19	0	1
20	0	0
21	1	23
22	1	22
23	1	21
24	1	20
25	1	19
26	1	18
27	1	17
28	1	16
29	1	15
30	1	14
31	1	13
32	1	12
33	1	11
34	1	10
35	1	9
36	1	8
37	1	7
38	1	6
39	1	5
40	1	4
41	1	3
42	1	2
43	1	1
44	1	0
45	2	23
46	2	22
47	2	21
48	2	20
49	2	19
50	2	18
51	2	17
52	2	16
53	2	15
54	2	14
55	2	13
56	2	12
57	2	11
58	2	10
59	2	9
60	2	8
61	2	7
63	2	5
64	2	4
65	2	3
66	2	2
67	2	1
68	2	0
69	3	23
70	3	22
71	3	21
72	3	20
73	3	19
74	3	18
75	3	17
76	3	16
77	3	15
78	3	14
79	3	13
80	3	12
81	3	11
82	3	10
83	3	9
84	3	8
85	3	7
86	3	6
87	3	5
88	3	4
89	3	3
90	3	2
91	3	1
92	3	0

На рисунках Б.10 - Б.13 представлены форматы передачи унифицированных данных (BCD) (от 1 до 20, от 21 до 44, от 45 до 65 и от 66 до 92 цифр соответственно).

Рисунок Б.10 - Формат передачи унифицированных данных

(BCD) от 1 до 20 цифр

Рисунок Б.11 - Формат передачи унифицированных данных

(BCD) от 21 до 44 цифр

Рисунок Б.12 - Формат передачи унифицированных данных

(BCD) от 45 до 65 цифр

Рисунок Б.13 - Формат передачи унифицированных данных

(BCD) от 66 до 92 цифр

Б.3.5 Формат семибитного набора символов ISO AD

AD представляют собой кодированный семибитный набор символов ISO (см. [2]). До четырех UDT AD могут объединяться с заголовком AD UDT для формирования многоблокового PDU UDT. Может передаваться до 52 семибитных символов ISO. IE PN в заголовке UDT определяет количество четырехбитных полубайтов (1111₂), добавленных до семибитных символов, чтобы полностью заполнить блок. Точное соответствие добавленных полубайтов не всегда возможно, но имеется достаточно признаков однозначного указания количества символов.

Количество семибитных символов пользователя и соответствующее значение UAB и PN представлено в таблице Б.4.

Таблица Б.4

Связь семибитных символов ISO 7, UAB и IE PN

7 бит символов пользователя	UAB	PN
1	0	1
2	0	1
3	0	1
4	0	1
5	0	1
6	0	9
7	0	7
8	0	6
9	0	4
10	0	2
11	0	0
12	1	2
13	1	2
14	1	1
15	1	1
16	1	1
17	1	1
18	1	1
19	1	1
20	1	9
21	1	7
22	1	5
23	1	3
24	1	2
25	1	0
26	2	2
27	2	2
28	2	1
29	2	1
30	2	1
31	2	1
32	2	1
33	2	1
34	2	8
35	2	6
36	2	5
37	2	3
38	2	1
39	3	23
40	3	22
41	3	20
42	3	18
43	3	16
44	3	15
45	3	13
46	3	11
47	3	9
48	3	8
49	3	6
50	3	4
51	3	2
52	3	1

На рисунках Б.14 - Б.17 представлены форматы передачи унифицированных данных (7 бит ISO: от 1 до 11, от 12 до 25, от 26 до 38 и от 39 до 52 символов соответственно).

Рисунок Б.14 - Формат передачи унифицированных данных

(7 бит ISO) от 1 до 11 символов

Рисунок Б.15 - Формат передачи унифицированных данных

(7 бит ISO) от 12 до 25 символов

Рисунок Б.16 - Формат передачи унифицированных данных

(7 бит ISO) от 26 до 38 символов

Рисунок Б.17 - Формат передачи унифицированных данных

(7 бит ISO) от 39 до 52 символов

Б.3.6 Восьмибитный формат ISO AD

AD представляют собой кодированный восьмибитный формат символов ISO (см. [3]). До четырех UDT AD могут быть объединены с заголовком AD UDT для формирования многоблокового PDU UDT. Может быть передано до 46 восьмибитных символов ISO. IE PN в заголовке UDT определяет количество четырехбитных полубайтов (1111₂), которые были добавлены к символам, чтобы полностью заполнить блок.

Количество восьмибитных символов пользователя и соответствующее значение UAB и PN представлены в таблице Б.5.

Таблица Б.5

Связь восьмибитных символов, UAB и IE PN

Символы пользователя	UAB	PN
1	0	18
2	0	16
3	0	14
4	0	12
5	0	10
6	0	8
7	0	6
8	0	4
9	0	2
10	0	0
11	1	22
12	1	20
13	1	18
14	1	16
15	1	14
16	1	12
17	1	10
18	1	8
19	1	6
20	1	4
21	1	2
22	1	0
23	2	22
24	2	20
25	2	18
26	2	16
27	2	14
28	2	12
29	2	10
30	2	8
31	2	6
32	2	4
33	2	2
34	2	0
35	3	22
36	3	20
37	3	18
38	3	16
39	3	14
40	3	12
41	3	10
42	3	8
43	3	6
44	3	4
45	3	2
46	3	0

На рисунках Б.18 - Б.21 представлены форматы передаваемых унифицированных данных (восьмибитные символы: от 1 до 10, от 11 до 22, от 23 до 34, от 35 до 46 символов соответственно).

Рисунок Б.18 - Формат передаваемых унифицированных данных

(восьмибитные символы) от 1 до 10 символов

Рисунок Б.19 - Формат передачи унифицированных данных

(восьмибитные символы) от 11 до 22 символов

Рисунок Б.20 - Формат передачи унифицированных данных

(восьмибитные символы) от 23 до 34 символов

Рисунок Б.21 - Формат передачи унифицированных данных

(восьмибитные символы) от 35 до 46 символов

Б.3.7 Формат AD NMEA

Б.3.7.1 Общие положения

AD содержат данные для координат, отформатированных NMEA (см. [1]). До двух UDT AD могут быть объединены с заголовком данных UDT для формирования многоблокового PDU UDT. Описаны три формата, короткий формат NMEA, где данные в формате NMEA содержатся в одном добавленном UDT, и длинный формат, где два добавленных блока либо включают дополнительные данные в формате NMEA, которые будут передаваться, либо позволяют производителям реализовывать индивидуальный формат.

Для UDT формата NMEA IE PN в заголовке UDT должен быть установлен в значение 0 0000₂. Если блоки AD представляют краткий формат данных NMEA, то UAB в заголовке UDT должен быть установлен в значение 00₂. Если добавленные блоки представляют собой длинный заданный формат NMEA, то UAB должен быть установлен на 01₂. Если добавленные блоки представляют длинный неопределенный формат NMEA, то UAB должен быть установлен в 10₂. IE для добавленных блоков описаны в таблице Б.7. Таблица Б.6 определяет значение UAB и PN.

Таблица Б.6

Связь формата NMEA и UAB

Формат NMEA	UAB	PN
Короткий формат	00₂	0
Длинный формат (определенный формат)	01₂	0
Длинный формат (неопределенный формат)	10₂	0
R	11₂	0

Б.3.7.2 Короткий формат NMEA

UAB в заголовке UDT установлен в значение 00₂. Данные NMEA передаются в один добавленный UDT. IE UTCss3 передает время с шагом в 10 с.

Короткий формат NMEA AD представлен на рисунке Б.22.

Рисунок Б.22 - Короткий формат NMEA AD

Б.3.7.3 Определенный длинный формат NMEA

UAB в заголовке UDT устанавливается в значение 01₂. Данные NMEA передаются в два добавленных UDT. IE UTCss6 передает время с шагом 1 с. MFID устанавливается в SFID (0000 0000₂).

Определенный длинный формат NMEA AD представлен на рисунке Б.23.

Рисунок Б.23 - Определенный длинный формат NMEA AD

Б.3.7.4 Неопределенный длинный формат NMEA (IEC 61162-1)

UAB в заголовке UDT устанавливается в 10₂. Данные NMEA передаются в два добавленных UDT. MFID устанавливается в FID производителя.

Неопределенный длинный формат NMEA AD представлен на рисунке Б.24.

Рисунок Б.24 - Неопределенный длинный формат NMEA AD

Таблица Б.7

Элементы NMEA AD

Имя	Длина, бит	Значение	Описание
C	1	0	Незашифрованные данные
C	1	1	Зашифрованные данные
NS	1	0	Направление широты - Юг
NS	1	1	Направление широты - Север
EW	1	0	Направление долготы - Запад
EW	1	1	Направление долготы - Восток
Q	1	0	Индикатор качества сигнала системы спутниковой навигации - не определен
Q	1	1	Индикатор качества сигнала системы спутниковой навигации - фиксированное значение
SPEED	7	-	Скорость в узлах (от 0 до 127) 127 = больше, чем 126 узлов
NDEG	7	-	Градусы широты (до 00 до 89)
NMINmm	6	-	Минуты широты (от 00 до 59)
NMINF	14	-	Доли минут широты (от 0000 до 9999)
EDEG	8	-	Градусы долготы (от 000 до 179)
EMINmm	6	-	Минуты долготы (от 00 до 59)
EMINF	14	-	Доли минут долготы (от 0000 до 9999)
UTChh	5	-	Часы времени UTC (от 00 до 23)
UTCmm	6	-	Минуты времени UTC (от 00 до 59)
UTCss3	3	-	10 с времени UTC ((от 0 до 5) x 10)
UTCss6	6	-	Секунды времени UTC (от 00 до 59)
DOP	5	-	Показатель снижения точности (от 1 до 31)
COG	9	-	Курс относительно грунта в градусах
Spare		-	Опционально <1>
MFID	8	-	ID набора признаков производителей [см. ГОСТ Р 71586.1-2024 (приложение Ж)]
<1> Определяется производителем.

Б.3.8 Формат IP-пакета UDT транкинговой сети

Формат IP UDT показан на рисунках Б.25 и Б.26.

Рисунок Б.25 - Формат IPV4 AD

Рисунок Б.26 - Формат IPV6 AD

Б.3.9 Формат шестнадцатибитных символов Unicode UTF-16BE AD

AD являются кодированным форматом шестнадцатибитных символов Unicode UTF-16BE (см. [1]). До четырех UDT AD могут быть объединены с заголовком UDT AD для формирования многоблокового PDU UDT. Можно передавать до 23 символов Unicode. IE PN в заголовке UDT определяет количество четырехбитных полубайтов (1111₂), которые были дополнены до Unicode Characters, чтобы полностью заполнить блок.

Количество шестнадцатибитных пользовательских символов Unicode и соответствующее значение UAB и PN представлены в таблице Б.8.

Таблица Б.8

Связь шестнадцатибитных символов Unicode с UAB и IE PN

Символы пользователя	UAB	PN
1	0	1
2	0	1
3	0	8
4	0	4
5	0	0
6	1	2
7	1	1
8	1	1
9	1	8
10	1	4
11	1	0
12	2	2
13	2	1
14	2	1
15	2	8
16	2	4
17	2	0
18	3	2
19	3	1
20	3	1
21	3	8
22	3	4
23	3	0

На рисунках Б.27 - Б.30 представлены форматы передачи унифицированных данных (шестнадцатибитные символы: от 1 до 5, от 6 до 11, от 12 до 17 и от 18 до 23 символов соответственно).

Рисунок Б.27 - Формат передачи унифицированных данных

(шестнадцатибитные символы) от 1 до 5 символов

Рисунок Б.28 - Формат передачи унифицированных данных

(шестнадцатибитные символы) от 6 до 11 символов

Рисунок Б.29 - Формат передачи унифицированных данных

(шестнадцатибитный символ) от 12 до 17 символов

Рисунок Б.30 - Формат передачи унифицированных данных

(шестнадцатибитный символ) от 18 до 23 символов

Б.3.10 Смешанный формат AD

AD являются кодированными с одним адресом (24 бита) и шестнадцатибитным форматом символов Unicode UTF-16BE (см. [1]). До четырех UDT AD могут быть объединены с заголовком AD UDT для формирования многоблокового PDU UDT. Может передаваться один адрес (24 бита) и до 21 символа Unicode. IE PN в заголовке UDT определяет количество четырехбитных полубайтов (1111₂), которые были добавлены к символам Unicode, чтобы полностью заполнить блок.

Количество пользовательских шестнадцатибитных символов и соответствующее значение UAB и PN для смешанного формата AD представлены в таблице Б.9.

Таблица Б.9

Связь шестнадцатибитных символов Unicode, UAB и IE PN

Символы пользователя	UAB	PN
1	0	8
2	0	4
3	0	0
4	1	2
5	1	1
6	1	1
7	1	8
8	1	4
9	1	0
10	2	20
11	2	16
12	2	12
13	2	8
14	2	4
15	2	0
16	3	20
17	3	16
18	3	12
19	3	8
20	3	4
21	3	0

На рисунках Б.31 - Б.34 представлены смешанные форматы AD (один адрес плюс шестнадцатибитные символы: от 1 до 3, от 4 до 9, от 10 до 15 и от 16 до 21 буквенных символов соответственно).

Рисунок Б.31 - Смешанный формат AD. Один адрес плюс

шестнадцатибитные символы. От 1 до 3 буквенных символов

Рисунок Б.32 - Смешанный формат AD. Один адрес плюс

шестнадцатибитные символы. От 4 до 9 символов

Рисунок Б.33 - Смешанный формат унифицированных AD. Один

адрес плюс шестнадцатибитные символы. От 10 до 15 символов

Рисунок Б.34 - Смешанный формат AD. Один адрес плюс

шестнадцатибитные символы. От 16 до 21 символа

Б.3.11 LIP

UDT может передавать до 46 байтов данных протокола LIP. Формат данных в добавочных блоках определен в [4].

Приложение В

(обязательное)

ПЛАН ФИЗИЧЕСКОГО КАНАЛА

В.1 Номинальные частоты несущих

Номинальные частоты несущих для транкингового оборудования могут быть распределены в любом из частотных диапазонов в полосе от 50 МГц до 999 МГц. Верхние уровни стека протоколов определяют единый номер логического канала в диапазоне от 1 до 4094 для частоты передатчика и приемника. Поскольку настоящий стандарт поддерживает переназначение существующих аналоговых каналов, там, где это необходимо, обеспечивается гибкое изменение установленных канальных частотных планов.

Следовательно, настоящий стандарт может поддерживать:

- ряд фиксированных частотных планов каналов, где частота передачи АС, разделение между передачей и приемом, разнесение каналов и если частота приемника выше или ниже по отношению к частоте передатчика;

- гибкий частотный план канала, причем каждый логический канал может представлять пару частот передатчика и приемника;

- широковещательный PDU, который позволяет TSCC объявить логическую/физическую связь передатчика и приемника;

- PDU предоставления расширенного канала, который определяет физические частоты передатчика и приемника.

Транкинговое оборудование имеет только логический SDU CHAN для определения физических частот. Дополнительные параметры (тип частотного плана канала, разнесение частот передатчика и приемника и т.д.) существуют только на физическом уровне и запрограммированы в процессе персонализации или производства оборудования.

В.2 Фиксированный частотный план канала

Номинальные частоты передачи f_Tx и приема f_Rx определяются по формулам

; (В.1)

f_Rx = f_Tx +/- f_duplexsplit, (В.2)

где f_base - наименьшая частота в конкретном диапазоне, соответствующая номеру логического канала CHAN = 1, МГц;

CHAN - номер логического канала;

f_separation - разнос частот между двумя соседними каналами, кГц;

f_duplexsplit - дуплексное разделение; разница между частотами передачи и приема (для ясности: частота передачи минус частота приема), МГц.

Коды SDU и соответствующие им значения разноса частот приведены в таблице В.1.

Таблица В.1

Коды SDU и соответствующие им значения разноса частот

Код SDU (SEP)	f_separation, кГц
0000₂	5
0001₂	6,25
0010₂	10
0011₂	12,5
0100₂	15
0101₂	20
0110₂	25
0111₂	30
1xxx₂	R

f_split - индикатор верхнего/нижнего дуплексного разделения (расположения f_Tx относительно f_Rx).

Коды SDU и соответствующие им значения верхнего или нижнего разделения частот приведены в таблице В.2.

Таблица В.2

Коды SDU и соответствующие им значения

верхнего/нижнего разделения частот

Код SDU (TXRX_SPLIT)	Комментарий
0₂	Частота передачи выше частоты приема
1₂	Частота передачи ниже частоты приема

f_duplexsplit принимает значения от 0 МГц до 50 МГц с шагом 2,5 кГц.

Коды SDU и соответствующие им значения дуплексного разделения частот приведены в таблице В.3.

Таблица В.3

Коды SDU и соответствующие им значения

дуплексного разделения частот

Код SDU (DUPLEX_SPLIT)	f_duplexsplit, кГц
000 0000 0000 0000₂	0
000 0000 0000 0001₂	2,5
....................	....................
000 0111 0011 0000₂	4 600 (4,6 МГц)
....................	....................
000 1100 1000 0000₂	8 000 (8 МГц)
....................	....................
000 1111 1010 0000₂	10 000 (10 МГц)
....................	....................
100 0110 0101 0000₂	45 000 (45 MHz)

Коды SDU и соответствующие им полосы частот приведены в таблице В.4.

Таблица В.4

Коды SDU и соответствующие им полосы частот

Код SDU (BAND)	f_base, МГц
000 0011₂	30
000 0100₂	40
000 0101₂	50
000 0110₂	60
000 0111₂	70
....................	....................
010 1101₂	450
....................	....................
101 0000₂	800
110 0100₂	1 000

Номера логических каналов и соответствующие им коды SDU (CHAN) с CC приведены в таблице В.5.

Таблица В.5

Номера логических каналов и соответствующие им коды SDU

Номер канала	Код SDU (CHAN)	CC <1>
1	0000 0000 0001₂	XX...XX₂ <1>
....................	....................	....................
4 094	1111 1111 1110₂	XX...XX₂ <1>
<1> По умолчанию CC = 0000₂.

В.3 Гибкий канальный план

Номер каждого логического канала имеет определенную частоту передатчика и приемника. Гибкий канальный план представлен в таблице В.6.

Таблица В.6

Гибкий канальный план

Номер канала	Код SDU (CHAN)	Частота передатчика	Частота приемника	CC <1>
1	0000 0000 0001₂	-	-	XX...XX₂ <1>
............	............	............	............	............
4 094	1111 1111 1110₂	-	-	XX...XX₂ <1>
<1> По умолчанию CC = 0000₂.

В.4 Определение частоты передатчика и приемника из CdefParms

Абсолютная частота передатчика и приемника ТС задается с шагом 125 Гц, как представлено в таблице В.7.

Таблица В.7

Абсолютная частота передатчика и приемника SDU

Имя	Код SDU	Частота передатчика/приемника
TXMHz RXMHz	00 0011 0010₂	50 МГц
TXMHz RXMHz	11 1110 0111₂	999 МГц
TXKHz RXKHz	0 0000 0000 0000₂	0 Гц
	0 0000 0000 0001₂	+125 Гц
	0 0000 0000 0010₂	+250 Гц
	1 1111 0011 1111₂	+999 875 Гц

Абсолютные частоты передачи и приема определяются следующим образом:

; (В.3)

. (В.4)

Приложение Г

(обязательное)

ПРОЦЕДУРЫ ПОИСКА TSCC

Г.1 Введение

Для того чтобы найти нужный TSCC, АС ищет в списке кандидатов физические каналы до тех пор, пока не будет выбран и подтвержден соответствующий TSCC. Такой поиск TSCC может включать в себя множество поисковых последовательностей в зависимости от обстоятельств поиска. Настоящее приложение представляет структуру поисковой стратегии АС.

Так как два логических канала TDMA занимают один физический канал, АС может оценивать оба логических канала одновременно при выборе физического канала. АС может использовать информацию из CACH или PDU, которые содержат IE C_SYScode, предназначенный для процедур проверки, определенных в 7.3.3.3 ("Проверка кода идентификации системы").

Этапы процедуры поиска TSCC следующие:

а) "возобновление поиска TSCC" позволяет АС, после периода активности на физическом рабочем канале, возобновить тот TSCC, на котором она была последний раз подтверждена до PDU предоставления рабочего канала;

б) "запрограммированный канал поиска TSCC" используется, когда АС направлена по TSCC к конкретному TSCC (от C_MOVE или P_CLEAR PDU), или пытается восстановить TSCC после определенного периода бездействия в выбранной сети (из-за того, что она была выключена, или из-за изменения выбранной сети, инициированного пользователем, когда адреса последних подтвержденных TSCC были сохранены в энергонезависимой памяти АС);

в) "последовательность короткого поиска". Последовательность поиска, определяющая все физические номера каналов, которые, вероятно, будут использоваться в качестве TSCC в выбранной сети. Список номеров вероятных кандидатов физических каналов Nmax_Ch содержится в фиксированной энергонезависимой памяти АС выбранной сети. АС должна иметь место для хранения до 64 значений IE "Номер логического физического канала", определяющих размеры "последовательности короткого поиска". Неиспользованные ячейки памяти маркированы таким образом, что АС может их игнорировать. Конкретные номера физических каналов могут сохраняться в списке неоднократно, чтобы обеспечить смещение к этому конкретному TSCC;

г) "последовательность расширенного поиска". Последовательность поиска, которая собирает все возможные номера физических каналов, использованных сетью. Эта последовательность поиска обеспечивает дополнительные условия для обнаружения TSCC, даже если используются номера физического канала, как правило, не используемые для этой цели. "Последовательность расширенного поиска" может быть временно приостановлена, чтобы отобрать возможные физические каналы или повторить "последовательность короткого поиска". Постоянные уровня 3 Low_Comp_Ch и High_Comp_Ch, определяющие низший и высший логические каналы соответственно, находятся в фиксированной энергонезависимой памяти АС.

Примечание - "Последовательность расширенного поиска" может быть аннулирована с помощью персонализации сети.

При выполнении "возобновления канала поиска TSCC" или "запрограммированного канала поиска TSCC" процедура поиска считается завершенной, если АС была настроена непосредственно на физический канал и выполнила соответствующие процедуры проверки и подтверждения, определенные в 7.3.

На рисунке Г.1 представлена возможная реализация последовательности "короткого поиска" и "расширенного поиска".

Рисунок Г.1 - Поиск физического канала

Если АС нужно искать соответствующий TSCC, то этот процесс выполняет поиск наиболее вероятных кандидатов физических каналов в первую очередь. Этот пример возможной реализации осуществляет короткий поиск дважды, первый цикл осуществляет поиск TSCC, уровень сигнала которого превышает определенное значение (L_SigShort).

Последовательность поиска можно считать завершенной в следующих случаях:

а) найден физический канал, который отвечает требованиям проверочных испытаний и испытаний на соответствие техническим условиям TSCC, указанным в 7.3 (процедура поиска была успешной);

б) все физические номера каналов в рамках последовательности поиска были проверены без обнаружения физического канала, который отвечает требованиям испытаний на соответствие техническим условиям TSCC, определенным в 7.3 (последовательность поиска не удалась).

АС осуществляет процедуру поиска в порядке, описанном в настоящем подразделе. Если последовательность поиска неудачно завершена, то АС начинает следующую последовательность поиска. Заключительная последовательность поиска "последовательность расширенного поиска". Если эта последовательность поиска не может быть завершена, то АС остается в этой последовательности поиска до тех пор, пока TSCC не будет подтвержден. Тем не менее, приведенные выше положения настоящего подраздела могут быть менее строгими в следующих случаях:

- "последовательность расширенного поиска" может быть аннулирована персонализацией АС в сети;

- АС в "последовательности расширенного поиска" может выбрать выполнение последовательностей любого другого типа поиска, возвращаясь к "последовательности расширенного поиска" в случае невозможности подтвердить соответствующий TSCC;

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

Там, где стадия поиска включает в себя более одного физического канала, порядок, в котором физические каналы опрашиваются, не указывается. Тем не менее, в целях защиты от смещения по отношению к определенным физическим каналам, АС должны обеспечивать произвольный поиск, в котором физические каналы отбираются с помощью одного из следующих действий:

- поиск номеров физических каналов последовательно (например, от самого низкого до самого высокого номера), но начиная фазу поиска с произвольной позиции в последовательности каналов физических номеров;

- поиск номеров физических каналов в произвольном порядке.

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

Примечание - Указанные процедуры являются основой для АС. Использование дополнительных или отличающихся процедур не запрещается при условии, что они соответствуют процедурам проверки и подтверждения, определенным в настоящем документе.

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

Г.2 Возобновление канала поиска TSCC

При возобновлении канала поиска TSCC АС возвращается к номеру логического физического TSCC, который был подтвержден последним. АС должна осуществлять прием на канале исходящего TSCC, который она возобновляет в двух TDMA-кадрах в следующие моменты времени:

а) конец любого PDU P_CLEAR, который запрашивает АС о прекращении работы в рабочем канале, на который она в данный момент настроена;

б) конец последнего разъединенного P_MAINT PDU (Maint_Kind соответствует DISCON) полезной нагрузки, отправленный АС в рабочий канал;

в) конец любого PDU (P_AUTH) проверки авторизации вызова, принятого по рабочему каналу, когда IE адреса АС в P_AUTH PDU не совпадает с одним из адресов из PDU предоставления канала, который направлял АС в рабочий канал;

г) операция любого пользователя, инициировавшая "запрос окончания вызова" пользователем во время вызова разговорной группы, когда АС не была инициатором вызова.

Перед подтверждением TSCC АС должна проверить любой C_SYScode, принятый из канала в соответствии с процедурами, описанными в 7.3.3.3. В случае если C_SYScode не прошел процедуру проверки, последовательность поиска считается неудачно завершенной и АС переходит к "последовательности короткого поиска".

Г.3 Запрограммированный канал поиска TSCC

Г.3.1 Условия ввода запрограммированного поиска TSCC

"Поиск одного канала" применяется, когда АС направляется в TSCC, отличный от того, на котором она последний раз была подтверждена, или если она включена в то время, когда все еще сохраняется достоверная сетевая информация от предыдущей работы в выбранной сети, или пользователь инициирует замену выбранной сети и АС до сих пор сохраняет достоверную информацию о предыдущей работе в новой выбранной сети. АС должна иметь возможность принимать назначенный физический канал в течение трех таймслотов TDMA в следующие моменты времени:

а) конец какого-либо достоверного PDU C_MOVE, который применяется к АС;

б) АС включена при условии, что блок имеет верную запись номера канала, на котором АС последний раз была подтверждена;

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

Г.3.2 Назначенный канал для поиска одного канала

Назначенный канал - это:

а) номер логического физического канала, указанный в IE CONT PDU P_CLEAR; или

б) номер канала, указанный в IE CONT PDU C_MOVE; или

в) номер канала, сохраненный в памяти чтения/записи АС, как TSCC, в котором блок был совсем недавно подтвержден в выбранной сети.

АС не делает никаких передач на TSCC, пока она не подтвердила канал в соответствии с процедурой, указанной в 7.3. В случае выхода из строя TSCC для соответствия критериям подтверждения канала последовательность поиска считается неудачно завершенной. После неудачного завершения "Запрограммированного канала поиска TSCC" АС переходит к "Последовательности короткого поиска".

Г.3.3 Последовательность короткого поиска

Г.3.3.1 Общие положения

"Последовательность короткого поиска" определяет все физические каналы, которые вероятнее всего будут использоваться в качестве TSCC выбранной сетью. Существует много стратегий, которые могут быть использованы, но все методики из окончательного списка кандидатов следующие:

а) список вероятных физических каналов будет определяться внешней службой, сохраненный в фиксированной энергонезависимой памяти АС;

б) АС может изменять объем окончательного списка физических каналов информационного широковещательного сигнала сети и хранить в своей энергонезависимой памяти следующим образом:

1) путем добавления к диапазону поиска номеров каналов, принятых в PDU C_BCAST (объявленном/аннулированном) из выбранной сети,

2) путем удаления из диапазона поиска номеров каналов, принятых в PDU C_BCAST (объявленных/удаленных) из выбранной сети.

Одна из стратегий, показанная на рисунке Г.1, определяет поиск списка номеров физических каналов последовательно (например, от случайно выбранной позиции списка к высшей, затем, двигаясь по кругу, к низшей позиции списка), но начиная стадию поиска со случайной позиции в последовательности номеров физических каналов.

Другая возможная стратегия предполагает поиск полного списка номеров физических каналов последовательно (например, от низшей позиции списка до высшей позиции списка), записывая уровень сигнала и/или BER. После осуществления выборки всех каналов в списке АС выбирает наиболее подходящий TSCC.

Г.3.3.2 Условия запуска "Последовательности короткого поиска"

АС запускает "последовательность короткого поиска":

а) немедленно после включения, при условии, что АС не сохраняет достоверную информацию о предыдущей работе в выбранной сети;

б) если пользователь указывает изменение выбранной сети, при условии, что АС не сохраняет достоверную информацию о предыдущей работе в выбранной сети.

АС может запускать "последовательность короткого поиска" в любое время в течение "последовательности расширенного поиска" при разъединении АС.

АС не должна осуществлять передачу на TSCC, находящемся в "последовательности короткого поиска", до тех пор, пока не будет проверен и подтвержден канал в соответствии с процедурами, указанными в 7.3.

После неудачного завершения "последовательности короткого поиска" АС входит в "последовательность расширенного поиска", за исключением случаев, когда "последовательность расширенного поиска" была аннулирована персонализацией АС в сети.

Г.3.4 Последовательность расширенного поиска

Г.3.4.1 Общие положения

"Последовательность расширенного поиска" включает в себя поиск каждого канала в пределах диапазона, установленного самым низким и самым высоким значениями номера каналов, установленного параметрами персонализации сети, хранящимися в фиксированной энергонезависимой памяти АС.

Г.3.4.2 Условия запуска расширенного поиска канала

АС запускает "последовательность расширенного поиска", если "последовательность короткого поиска" была завершена неудачно.

АС может повторять "этап расширенного поиска" до тех пор, пока не будет найден физический канал, который соответствует требованиям TSCC, указанным в 7.3.

АС не делает никаких передач в TSCC, находящемся в "последовательности расширенного поиска", пока она не выбрала канал в соответствии с процедурами, указанными в 7.3.

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

Можно аннулировать "последовательность расширенного поиска" путем персонализации АС. В этом случае АС продолжает "последовательность короткого поиска" с порогом обнаружения, установленным на уровне L_Squelch, до тех пор, пока не будет подтвержден канал, который выдерживает испытания на соответствие техническим условиям, указанным в 7.3.

Г.3.5 Чувствительность приемника во время обнаружения TSCC

АС не должна делать попытку стать активной на любом физическом канале, для которого уровень принимаемого сигнала (или качество сигнала) меньше заданного порога обнаружения.

Уровень порога обнаружения L_SHort на входе приемника устанавливается в диапазоне от L_Upper_SHort до L_Lower_SHort (или эквиваленте антенны, если приемник измеряет качество сигнала). L_Squelch устанавливается на уровне, определенном изготовителем АС, который позволяет отклонить неподходящие физические каналы, на которых принятый сигнал является недостаточным для соответствующего класса обслуживания (или эквивалент, если приемник измеряет качество сигнала).

Примечание - АС может быть не в состоянии определить уровень принимаемого сигнала, но может использовать другие методы для определения качества сигнала, такие как измерение количества битовых ошибок на некотором интервале времени.

Приложение Д

(обязательное)

ИСПОЛЬЗОВАНИЕ СХЕМ MSC И SDL

Д.1 Введение

Настоящий документ использует схемы SDL и MSC для дополнения текстового описания режимов работы в части услуг транкинговой связи и протокола функциональных возможностей транкинговых сетей ППР.

Д.2 Основные положения

Диаграммы MSC и SDL поясняют то же поведение (требование), что и определенное текстовым описанием, таким образом, они лишь дополняют текстовое описание, чтобы предоставить альтернативный взгляд на требование. Создание этих диаграмм может также помогать проверке текстового описания, например, определение пропущенной остановки таймера, когда другое ожидаемое поведение происходит до таймаута.

Д.3 Система обозначений

MSC-диаграммы используют конструкции, показанные на рисунке Д.1.

Рисунок Д.1 - Система обозначений SDL

Диаграммы состоят из следующих элементов:

а) обмена сообщениями между отдельными элементами (линия со стрелкой, связанной с именем сообщения и параметрами, в скобках);

б) запуска таймера (горизонтальная линия с песочными часами);

в) остановки таймера (горизонтальная линия с "x");

г) времени действия таймера (горизонтальная линия со стрелкой и песочными часами);

д) необязательного встраиваемого конструктивного элемента (прямоугольник с ключевым словом "opt" в верхнем левом углу). Смыслом необязательного встраиваемого конструктивного элемента является то, что заключенная в нем характеристика не является обязательной;

е) необязательного встраиваемого конструктивного элемента (прямоугольник с ключевым словом "alt" в верхнем левом углу и пунктирные разделительные линии). Смыслом этого конструктивного элемента является то, что каждый из вариантов, разделенных пунктирной линией, представляет собой возможное поведение, одно из которых точно должно произойти для MSC;

ж) в схемах SDL используются только основные символы поведения процесса, то есть символы состояния, входа, выхода, решения, запуска и остановки таймера.

Д.4 Графическое представление языка SDL

Объекты, содержащиеся в диаграммах SDL, представлены в таблице Д.1. Пояснения по каждому объекту приведены ниже.

Таблица Д.1

Объекты, содержащиеся в диаграммах SDL

Графическое представление в SDL	Значение
	Система
	Блок
	Процедура
	Список каналов
	Каналы
	Межпроцессный канал
	Стартовый символ
	Состояние
	Прием сигнала
	Сохранение сигнала в определенном состоянии
	Метка
	Остановка
	Возврат из процедуры
	Присваивание
	Создание процесса
	Вызов процедуры
	Посылка сигнала
	Условие
	Окончание трассы объекта
	Комментарий
	Расширение

Д.4.1 Система

Объекты SDL, как правило, ограничиваются "рамкой", определяющей границы описываемого программного комплекса. Она называется "Система" и представляет собой основной контейнер для всех остальных объектов. Все, что находится вне этой границы, называется окружением системы. Внутри системы находится набор блоков. Взаимодействие между системой и ее окружением, а также между блоками внутри системы осуществляется только с помощью сигналов. Внутри системы сигналы передаются по каналам. Каналы соединяют блоки друг с другом или с окружением системы.

Д.4.2 Блок

Блок является контейнером для одного или более процессов или содержит вложенные блоки. Блок определяет структуру коммуникации для процессов в виде межпроцессных каналов между отдельными процессами, а также между процессами и окружением блока.

Д.4.3 Процедура

Процедура позволяет объединять набор состояний и переходов в единое целое и вводит некоторое имя для последующей работы с этим набором.

Д.4.4 Список сигналов

Список сигналов позволяет объединять несколько сигналов в единую группу и использовать имя этой группы в определениях каналов и т.д.

Д.4.5 Канал

Символ "Канал" обозначает маршрут передачи сигналов между двумя блоками или между блоком и его окружением. Каналы могут быть однонаправленные или двунаправленные. С каждым направлением может быть связан свой список допустимых сигналов. Каналы могут быть также межпроцессными.

Д.4.6 Стартовый символ

Стартовый символ определяет стартовый переход процесса, т.е. последовательность действий, выполняемую при порождении экземпляра данного процесса (статически или динамически).

Д.4.7 Состояние

Символ "Состояние" определяет набор реакций на сигналы (переходы). Каждое состояние имеет имя. Состояние со знаком "*" является особым: это способ определить переходы, общие для всех обычных состояний.

Д.4.8 Прием сигнала

Символ "Прием сигнала" определяет реакцию на данный сигнал (в данном состоянии). Непосредственно при получении сигнала переменные, указанные в символе приема сигнала, получают значения параметров сигнала.

Д.4.9 Сохранение сигнала в определенном состоянии

Сигналы, указанные в символе "Сохранение сигнала в определенном состоянии", игнорируются процессом в данном состоянии. Эти сигналы остаются во входном порте процесса (в порядке поступления) для последующей обработки в другом состоянии. Наличие механизма сохранения сигналов является важным, потому что в каждом состоянии определена стандартная реакция на любой сигнал, которая состоит в том, что сигнал изымается из очереди и уничтожается, тогда как процесс остается в старом состоянии.

Д.4.10 Метка

Символ "Метка" позволяет определять участки переходов, общие для нескольких состояний.

Д.4.11 Остановка

Выполнение остановки процесса приводит к уничтожению всех переменных процесса и всех необработанных сигналов из входного порта процесса.

Д.4.12 Возврат из процедуры

Возврат из процедуры означает продолжение того перехода, на котором произошел вызов процедуры.

Д.4.13 Присваивание

Присваивание - это механизм "связывания" различных процедур и объектов, позволяющий динамически изменять связи объектов данных (как правило, переменных) с их значениями.

Д.4.14 Создание процесса

Создание процесса - действие по описанию сведений о процессе, необходимых для управления им.

Д.4.15 Вызов процедуры

Вызов процедуры - это ссылка на процедуру с целью ее выполнения.

Д.4.16 Посылка сигнала

Посылка сигнала - процесс отправки от одного объекта к другому материального переносчика информации (изменяющейся физической величины, обеспечивающей передачу информации по линии связи).

Д.4.17 Условие

Условие (ветвление) - операция, применяющаяся в случаях, когда выполнение или невыполнение некоторого набора команд или действий должно зависеть от выполнения или невыполнения некоторого условия.

Д.4.18 Окончание трассы объекта

Окончание трассы объекта - символ, обозначающий окончание процесса, связанного с объектом ("трассы объекта").

Д.4.19 Комментарий

Комментарий - символ, содержащий информацию справочного характера.

Д.4.20 Расширение

Расширение - символ, содержащий информацию, которая является непосредственным продолжением содержания другого символа.

БИБЛИОГРАФИЯ

[1]	МЭК 61162-1:2024	Морское навигационное оборудование и средства радиосвязи. Цифровые интерфейсы. Часть 1. Один источник и несколько приемников сообщений (Maritime navigation and radiocommunication equipment and systems - Digital interfaces - Part 1: Single talker and multiple listeners)
[2]	ИСО/МЭК 646:1991 (все части)	Информационные технологии. Набор 7-битных кодированных символов ISO для обмена информацией (Information technology. ISO 7-bit coded character set for information interchange)
[3]	ИСО/МЭК 8859:1998 (все части)	Информационные технологии. 8-битный одиночный набор графических символов с байтовым кодированием (Information technology - 8-bit single-byte coded graphic character sets)
[4]	Протокол ETSI TS 100 392-18-1:2015	Наземное транкинговое радио TETRA. Голос плюс данные (V+D) и работа в прямом режиме (DMO); Часть 18. Приложения, оптимизированные для радиоинтерфейса; Подчасть 1. Протокол информации о местоположении (LIP) [Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D) and Direct Mode Operation (DMO); Part 18: Air interface optimized applications; Sub-part 1: Location Information Protocol (LIP)]
[5]	Протокол IETF RFC 2781:2000	UTF-16, кодировка из ISO 10646 (UTF-16, an encoding of ISO 10646)
[6]	Стандарт Unicode, версия 15.0 (2022)	Стандарт Unicode. Версия 15.0. Основные спецификации (The Unicode Standard. Version 15.0 - Core Specification)

УДК 621.396.7:006.354	ОКС 33.070.99
Ключевые слова: цифровая профессиональная подвижная радиосвязь, транкинговый режим, связь, абонентская станция

Вернуться в "Каталог нормативных документов"

Источник информации: https://internet-law.ru/documents/prod/gost-r_gosudarstvennyj-standart/16/gost_51300.html

На эту страницу сайта можно сделать ссылку:

На правах рекламы:

Разработка сайта
ArtStyle Group

Полное меню

Основные ссылки

Вернуться в "Каталог нормативных документов"