Интерфейс rf: Использование RF-модулей / Хабр

Использование RF-модулей / Хабр

Иногда, между устройствами требуется установить беспроводное соединение. В последнее время для этой цели все чаще стали применять Bluetooth и Wi-Fi модули. Но одно дело передавать видео и здоровенные файлы, а другое — управлять машинкой или роботом на 10 команд. С другой стороны радиолюбители часто строят, налаживают и переделывают заново приемники и передатчики для работы с готовыми шифраторами/дешифраторами команд. В обеих случаях можно использовать достаточно дешевые RF-модули. Особенности их работы и использования под катом.

Типы модулей

RF-модули для передачи данных работают в диапазоне УКВ и используют стандартные частоты 433МГц, 868МГц либо 2,4ГГц (реже 315МГц, 450МГц, 490МГц, 915МГц и др.) Чем выше несущая частота, тем с большей скоростью можно передавать информацию.
Как правило, выпускаемые RF-модули предназначены для работы с каким-либо протоколом передачи данных. Чаще всего это UART (RS-232) или SPI. Обычно UART модули стоят дешевле, а так же позволяют использовать нестандартные (пользовательские) протоколы передачи. Вначале я думал склепать что-то типа такого, но вспомнив свой горький опыт изготовления аппаратуры радиоуправления выбрал достаточно дешевые HM-T868 и HM-R868 (60грн. = менее $8 комплект). Существуют также модели HM-*315 и HM-*433 отличающиеся от нижеописанных лишь несущей частотой (315МГц и 433МГц соответственно). Кроме того есть множество других модулей аналогичных по способу работы, поэтому информация может быть полезной обладателям и других модулей.

Передатчик

Почти все RF-модули представляют собой небольшую печатную плату с контактами для подключения питания, передчи данных и управляющих сигналов. Рассмотрим передатчик(трансмиттер) HM-T868
На нем имеется трехконтактный разъем: GND(общий), DATA(данные), VCC(+питания), а также пятачок для припайки антенны(я использовал огрызок провода МГТФ на 8,5см — 1/4 длинны волны).

Приемник

Ресивер HM-R868, внешне, очень похож на соответствующий ему трансмиттер

но на его разъеме есть четвертый контакт — ENABLE, при подаче на него питания приемник начинает работать.

Работа

Судя по документации, рабочим напряжением является 2,5-5В, чем выше напряжение, тем большая дальность работы. По сути дела — это радиоудлинитель: при подаче напряжения на вход DATA передатчика, на выходе DATA приемника так же появится напряжение (при условии что на ENABLE также будет подано напряжение). НО, есть несколько нюансов. Во-первых: частота передачи данных (в нашем случае — это 600-4800 бит/с). Во-вторых: если на входе DATA нету сигнала более чем 70мс, то передатчик переходит в спящий режим(по-сути отключается). В-третьих: если в зоне приема ресивера нету работающего передатчика — на его выходе появляется всякий шум.

Проведем небольшой эксперимент: к контактам GND и VCC трансмиттера подключим питание. Вывод DATA соединим с VCC через кнопку или джампер. К контактам GND и VCC ресивера также подключаем питание, ENABLE и VCC замыкаем между собой. К выходу DATA подключаем светодиод (крайне желательно через резистор). В качестве антенн используем любой подходящий провод длинной в 1/4 длинны волны. Должна получиться такая схемка:

Сразу после включения приемника и/или подачи напряжения на ENABLE должен загореться светодиод и гореть непрерывно (ну или почти непрерывно). После нажатии кнопки на передатчике, со светодиодом также ничего не происходит — он продолжает гореть и дальше. При отпускании кнопки светодиод мигнет(погаснет и снова загорится) и продолжает гореть дальше. При повторном нажатии и отпускании кнопки все должно повторится. Что же там происходило? Во время включения приемника, передатчик находился в спящем состоянии, приемник не нашел нормального сигнала и стал принимать всякий шум, соответственно и на выходе появилась всякая бяка. На глаз отличить непрерывный сигнал от шума нереально, и кажется, что светодиод светит непрерывно. После нажатия кнопки трансмиттер выходит из спячки и начинает передачу, на выходе ресивера появляется логическая «1» и светодиод светит уже действительно непрерывно. После отпускания кнопки передатчик передает логический «0», который принимается приемником и на его выходе также возникает «0» — светодиод, наконец, гаснет. Но спустя 70мс передатчик видит что на его входе все тот же «0» и уходит в сон, генератор несущей частоты отключается и приемник начинает принимать всякие шумы, на выходе шум — светодиод опять загорается.

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

Формат пакета

RF-модули данного типа можно подключить напрямую к аппаратному UART или компьютеру через MAX232, но учитывая особенности их работы я бы посоветовал использовать особые протоколы, описанные программно. Для своих целей я использую пакеты следующего вида: старт-биты, байты с информацией, контрольный байт(или несколько) и стоп-бит. Первый старт-бит желательно сделать более длинным, это даст время чтобы передатчик проснулся, приемник настроился на него, а принимающий микроконтроллер(или что там у Вас) начал прием. Затем что-то типа «01010», если на выходе приемника такое, то это скорее всего не шум. Затем можно поставить байт идентификации — поможет понять какому из устройств адресован пакет и с еще большей вероятностью отбросит шумы. До этого момента информацию желательно считывать и проверять отдельными битами, если хоть один из них неправильный — завершаем прием и начинаем слушать эфир заново. Дальше передаваемую информацию можно считывать сразу по байтам, записывая в соответствующие регистры/переменные. По окончании приема выполняем контрольное выражение, если его результат равен контрольному байту — выполняем требуемые действия с полученной информацией, иначе — снова слушаем эфир. В качестве контрольного выражения можно считать какую-нибудь контрольную сумму, если передаваемой информации немного, либо Вы не сильны в программировании — можно просто посчитать какое-то арифметическое выражение, в котором переменными будут передаваемые байты. Но необходимо учитывать то, что в результате должно получится целое число и оно должно поместится в количество контрольных байт. Поэтому лучше вместо арифметических операций использовать побитовые логические: AND, OR, NOT и, особенно, XOR. Если есть возможность, делать контрольный байт нужно обязательно так как радиоэфир — вещь очень загаженная, особенно сейчас, в мире электронных девайсов. Порой, само устройство может создавать помехи. У меня, например, дорожка на плате с 46кГц ШИМ в 10см от приемника очень сильно мешала приему. И это не говоря о том, что RF-модули используют стандартные частоты, на которых в этот момент могут работать и другие устройства: рации, сигнализации, радиоуправление, телеметрия и пр.

Что еще можно почитать

HM-T и HM-R — описание и документация на сайте производителя.
1, 2 и 3 — интересные статьи и наблюдения (много чего полезного можно найти в комментариях).

АО Радио и Микроэлектроника — Концентратор RF-PLC РМ 025.03

Каталог

Автоматизированные системы коммерческого учета электроэнергии (АСКУЭ)

Компоненты АСКУЭ

Концентратор RF-PLC РМ 025.

03

Концентратор предназначен для работы в составе автоматизированной системы контроля потребления электроэнергии (далее — АС). Концентратор предназначен для сбора по интерфейсу RF информации от счетчиков  электрической энергии разработки ЗАО «Радио и Микроэлектроника», оснащенных интерфейсом RF, временного сохранения данных в энергонезависимой памяти и последующей их передачи по интерфейсу PLC  по запросу устройства верхнего уровня АС, например,  устройства сбора и передачи данных РМ 2064 (М), маршрутизатора каналов связи РиМ 099.02, терминала мобильного РиМ 099.01 и др. Полностью заменяет концентратор RF-PLC РМ 025.01.

Основные функции  и особенности концентратора

• опрос счетчиков с интерфейсом RF;
• накопление и сохранение данных в энергонезависимой памяти;
• передача накопленных данных по запросу внешнего устройства АС по интерфейсу PLC;
• трансляция по интерфейсу PLC команд от внешнего устройства АС другим концентраторам или счетчикам и их ответов внешнему устройству АС;
• считывание данных только со счетчиков, интерфейс RF которых работает в режиме SR («радиомаяка»), например счетчиков РиМ 532. 01, СОЭБ-2ПДР-65, СТЭБ-04Н-50(7,5)-Р и других счетчиков с индексом Р;
• может использоваться в составе АС как ретранслятор данных и команд по интерфейсу PLC;
• устанавливается непосредственно на опоре воздушной линии электропередач.

 

Технические характеристики

Номинальное напряжение питания, В	220
Полная потребляемая мощность, ВА, не более	30
Время сохранения данных, лет, не менее	10
Количество номеров счетчиков, заносимых в список приема концентратора, не более	256
Максимальная дальность обмена по интерфейсу PLC, м, не менее	100
Максимальная дальность действия интерфейса RF, м, не менее	100
Масса, кг, не более	0,5
Габаритные размеры, мм, не более	345х125х45
Диапазон температур, оС	от -40 до +55
Средний срок службы, лет	10
Гарантия производителя, месяцев	18

DB9 Интерфейс RS232 RF Беспроводной Bluetooth Модуль HC-06 Раб Серийный порт для Arduino

1.

Промышленный последовательный порт bluetooth, замену для проводных подключений последовательного, транспарентного использования. Вы можете использовать его просто для последовательной замены порта, чтобы установить связь между MCU и GPS, ПК для встроенного проекта и т.д..

2. Настройка порта по умолчанию serail : 9600, N, 8, 1 3. Код привязки : 1234 4. Выполняя роль раба: Сопряжение с ключа и мастер модуль BT 5. Спаренные режим: Два модуля будет установить связь автоматически при включении питания. 6. Режим ПК размещенных: Пара модуль с bluetooth dongle непосредственно как виртуальный серийный.

Параметры:

1. Протокол Bluetooth : Спецификация Bluetooth v2.0 + EDR 2. Частота : 2.4 ГГц ISM полоса 3. Модуляция : GFSK(Гаусса частотный сдвиг кеинга) 4. E мощность : < = 4 дБм, класс 2 5. Чувствительность : < =-84dBm на 0.1% BER 6. Скорость : Асинхронные: 2.1Mbps(Макс) / 160 кбит/с, синхронные: 1 Мбит / с 1Mbps 7. Безопасность : Аутентификация и шифрование 8. Профили : Последовательный порт Bluetooth 9.

Чип КСО : Bluetooth v2.0 10. Волна полоса : 2.4 ГГц-2.8 ГГц ISM полоса 11. Протокол : Bluetooth V2.0 12. Класс мощности : (+ 6dbm) 13. Чувствительность приема: -85dBm 14. Напряжения : 3.3 (2.7В-4.2В) 15. Текущий : Кожура 8mA — 35mA, подключен- 16. Температура : -40 ~ 105 градусов Цельсия 17. Определяемые пользователем скорость : 4800, 9600, 19200, 38400, 57600, 115200, 230400,460800,921600, 1382400. 18. Измерение : 26.9 * 13 мм * 2.2 мм

Определение ПИН:

1. PIO8 соединяет с LED cathodea с 470 Ом резистор между. LED НЕГАТИВНЫЕ подключается к земле. Он используется для обозначения состояния модуля. После того, как питание, мигающий интервалы отличаются в разных государствах. 2. PIO9 используется для управления индикатор, указывающий кожура. Это будет горит когда кожура успешно. 3. PIO11, состояние модуля, переключение ПИН. ВЫСОКАЯ-> ответ на команды; НИЗКИЙ или плавающие-> статус регулярной работы. 4. С строить в сброса цепи Сброс завершен автоматически после того, как работает на. 5. Шаги, чтобы установить мастер: 6. PIO11 высоко посаженные с 10K резистора между. 7. Питания, модуль вступает в состояние ответа команды 8. Откройте HyperTerminal или другой серийный инструмент, установить скорость передачи 38400, 8 бит данных, 1 стоп бит, не бит чётности, нет потока

Метод управления:

1. Через последовательный порт, отправки символов «AT + роль = 1 r n», если успешно, возвращаемое «ОК r n», где n является перевозка возврата. 2. Задать PIO11 низкий, повторно питания, затем в мастер государства, автоматический поиск slave-модуля и подключения.

Пакет включен:

1PCS для arduino DB9 RS232 RF Беспроводной Bluetooth Модуль HC-06 Раб Серийный порт

Тип товара: Электронные модули

радиоприемники с WIEGAND выходом и считыватели для идентификации

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

Радиоприемник CONNECT с выходом Виганд
Радиоприемник предназначен для радиоканальной идентификации в составе любой системы контроля доступа, поддерживающей следующие интерфейсы: WIEGAND, CLOCK & DATA и JCM. Идентификаторами являются радиоканальные брелоки с рабочим расстоянием до 100 м. Брелоки могут поставляться с интегрированной проксимити меткой HID, что позволяет использовать брелоки как обычные карты для похода через точки доступа, оборудованные считывателями HID.

Функциональные параметры
Приемник CONNECT совместим с передатчиками с динамическим кодированием GO, GO-PRO, GO-SWITCH и GO-PROPUSH в качестве идентификаторов, и поддерживает различные протоколы связи для интеграции в состав любой системы контроля доступа.

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

2. Многоканальный режим работы позволяет транслировать код без проверки состояния входа разблокировки частотного канала.

Технические параметры CONNECT

Параметры	Значения
Рабочая частота:	868,35 МГц
Выходные интерфейсы:	WIEGAND 26 (8 бит + 16 бит – код), WIEGAND 37, CLOCK&DATA, JCM/C4+
Входы:	2 входа для разблокировки определенного частотного канала
Количество каналов:	1 (из 4)
Напряжение питания:	12 В (DC) (9 – 21 В (DC))
Потребляемый ток:	36 мА
Рабочая температура:	от -20 до +85 °С
Класс защиты:	IP54 (IP65 при использовании фитингов)
Размеры:	82х190х40 мм

Радиоприемник INTERFACE RF/WG с выходом Виганд
Радиоприемник предназначен для радиоканальной идентификации в составе любой системы контроля доступа, поддерживающей следующие интерфейсы: WIEGAND, CLOCK & DATA и JCM. Идентификаторами являются радиоканальные брелоки с рабочим расстоянием до 100 м. Брелоки могут поставляться с интегрированной проксимити меткой EM-MARIN, что позволяет использовать брелоки как обычные карты для похода через точки доступа, оборудованные считывателями EM-MARIN.

Функциональные параметры
Приемник INTERFACE RF/WG совместим с передатчиками с динамическим кодированием NEO и TWIN в качестве идентификаторов, и поддерживает различные протоколы связи для интеграции в состав любой системы контроля доступа.

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

4. Многоканальный режим работы позволяет транслировать код без проверки состояния входа разблокировки частотного канала.

Технические параметры INTERFACE RF/WG

Параметры	Значения
Рабочая частота:	433,92 МГц
Выходные интерфейсы:	WIEGAND 26 (8 бит – сайт код + 16 бит – код брелока), WIEGAND 37, CLOCK&DATA, JCM/C4+
Входы:	2 входа для разблокировки определенного частотного канала
Количество каналов:	1 (из 4)
Напряжение питания:	12 В (DC)
Потребляемый ток:	12,6 мА
Рабочая температура:	от -20 до +85 °С
Класс защиты:	IP54
Размеры:	70х127х52 мм

Считыватель EVOPROX
Проксимити считыватели EVOPROX могут использоваться совместно с контроллером ACCESS-500 или в составе любой другой системы контроля доступа через интерфейс WIEGAND. Считыватель совместим с идентификаторами GO-EVO (имеет встроенную проксимити метку), EVO-TAG и EVO-CARD.

Технические параметры EVOPROX

Параметры	Значения
Рабочая частота:	13.56 МГц (MIFARE)
Протокол:	WIEGAND 26, CONTROLLER-6000, C4+, BUS-L
Радиус действия:	5 cм
Напряжение питания:	12 В DC
Потребляемый ток покоя/рабочий:	110 мА
Рабочая температура:	от -20 до +85 °С
Класс защиты:	IP66
Размеры:	84х75х14 мм

Подробные технические характеристики и цены на радиоприемники и считыватели JCM Technologies приведены в каталоге СКУД в подразделе «радиоприемники». Все цены в каталоге являются розничными и включают НДС. Для дилеров, монтажных организаций и постоянных клиентов компании «АРМО-Системы» действует гибкая система скидок, а также осуществляется бесплатная техническая поддержка клиента в период выбора, инсталляции, гарантийного и сервисного обслуживания оборудования.

Для получения дополнительной информации на радиоприемники и считыватели JCM Technologies и других компаний обращайтесь по эл. почте [email protected] или по телефонам: (495) 787-3342, 937-9057 к менеджерам отдела продаж компании «АРМО-Системы», являющейся официальным российским дистрибьютором оборудования JCM Technologies, либо в региональные офисы «АРМО».

ТЕХНОЛОГИЯ «HYBRID» PLC+RF

Технология «Hybrid» PLC+RF

Гибрид – это результат объединения нескольких характеристик разных предметов для получения одного с наилучшими свойствами.
Компания «Матрица» совместно со своими партнерами «ADDGrup» и «STMicroelectronics» – компаниями-разработчиками высокотехнологичных решений мирового уровня – тоже решила собрать лучшие современные технологии в одну для получения бóльших возможностей и наилучших результатов.
В настоящее время наша компания запустила производство новой линейки оборудования 8 версии «Advanced» с двумя каналами связи PLC+RF на базе технологии «Hybrid». Данное оборудование разработано с учетом последних нормативно-правовых документов, в том числе с учетом требований Федерального закона от 27.12.2018 №522-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации в связи с развитием системы учета электрической энергии (мощности) в Российской Федерации».
Технология «Hybrid» — это комбинированное решение коммуникаций по силовым линиям G3-PLC с возможностью альтернативной коммуникации по радиоканалу. Ключевой особенностью технологии является способность приборов учета адаптироваться и выбирать индивидуально более качественный на данный момент канал связи.
Сильное экранирование сигнала из-за зданий или неровной местности в начале линии и локальный шум по одной фазе в середине линии приводят к отсутствию связи на всем участке как отдельно для RF, так и отдельно для PLC. А интеллектуальная мультиканальная система на базе технологии «Hybrid» (PLC+RF) продолжает надежно работать. Таким образом, инновационное комбинированное решение работает лучше, чем два независимых канала передачи данных.

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

 

УСПД-коммуникатор МИР МК-01.А — от производителя НПО МИР

Параметр	Значение
Интерфейс – ZigBee (при наличии символа «Z», «Z1» в коде коммуникатора)
Модификация коммуникатора	«Z»		«Z1»
Поддерживаемые технологии	Mesh-сеть по технологии ZigBee 2007 г.		Mesh-сеть по технологии ZigBee Pro v3.0 2015 г.
Режим работы	«Базовая станция» или «Удаленная станция»		«Базовая станция» или «Удаленная станция»
Максимальное число устройств в сети	80		600
Диапазон рабочих частот, МГц	2400 – 2483,5
Мощность несущей частоты передатчика ZigBee, мВт	100
Скорость передачи данных, кбит/с	250
Количество частотных каналов	16
Интерфейс – PLC (при наличии символа «P», «P1», «P2», «P3» в коде коммуникатора)
Модификация коммуникатора	«P»	«P1»	«P2»	«P3»
Поддерживаемые технологии	Mesh-сеть по технологии Y-NET; вид модуляции DCSK	Mesh-сеть по техно-логии Y-NET; вид модуляции DCSK	Mesh-сеть по технологии G3-PLC; вид модуляции OFDM	Mesh-сеть по техно-логии G3-PLC; вид модуляции OFDM
Режим работы	«Базовая станция» или «Удаленная станция»	«Базовая станция» или «Удаленная станция»	«Базовая станция» или «Удаленная станция»	«Базовая станция» или «Удаленная станция»
Скорость передачи данных, бит/с	625 или 2500 (автоматический выбор)	625 или 2500 (автоматический выбор)	до 33400 (автоматический выбор)	до 33400 (автоматический выбор)
Диапазон рабочих частот, кГц	20 – 80	95 – 125	35,9 – 90,6	98,4 – 121,9
Уровень выходного сигнала PLC на эквиваленте силовой сети сопротивлением 5 Ом, В	1,4	1,4	5,0	5,0
Уровень входного сигнала PLC, при котором обеспечивается прием, мВ, не более	1,0	1,0	1,0	1,0
Количество ретрансляций	7	7	7	7
Разъем выхода сигнала PLC	«A B C N»	«PLC2»	«A B C N»	«PLC2»

Зачем нужны RF-модуляторы?

Раньше, когда цифрового ТВ еще не было, во всей бытовой воспроизводящей телевизионной технике были встроенные аналоговые RF-модуляторы. Это давало возможность при отсутствии низкочастотного интерфейса (разъемы RCA, они же «колокольчики» или «тюльпаны») подключить устройство (видеомагнитофон/видеоплеер, игровые приставки, видеокамеру или видео глазок, спутниковый приёмник) подключить к телевизору через антенный вход. С появлением цифрового ТВ в видеовоспроизводящих устройствах перестали использовать RF-модуляторы, поскольку цифровые устройства нуждаются в модуляторах с другим типом модуляции. Такие модуляторы, способные модулировать сигнал в формате DVB-C или DVB-T, стоят уже других денег и конечно увеличат стоимость бытового видеовоспроизводящего устройства достаточно ощутимо. Но потребность в них не отпала, просто производители стали выпускать такие модуляторы в виде отдельного устройства и клиент по своему желанию может самостоятельно докупить цифровой модулятор.

Современная видео воспроизводящая техника (медиа-плееры, компьютеры, в том числе планшеты, кабельные и спутниковые ресиверы, Blu-Ray и DVD-плееры, видеокамеры и фотоаппараты, игровые консоли и т. п. имеет HDMI (High Definition Multimedia Interface) интерфейс для мультимедиа высокой чёткости, позволяющий передавать цифровые видеоданные высокого разрешения.

Как устроен цифровой DVB-C/T модулятор?

Не будем вдаваться в технические тонкости конструкции модулятора, но при этом стоит отметить, что такие устройства состоят их двух функциональных блоков – непосредственно самого модулятора, задача которого задать необходимую модуляцию транспортному потоку, и кодера, задача которого кодировать в формат h364 видеоданные, получаемые из встроенного интерфейса HDMI. Выглядит это так, на вход цифрового DVB-C/T модулятора, на HDMI разъем, подается сигнал с любого мультимедиа устройства, имеющего HDMI выход. Соединение HDMI интерфейсов производится HDMI кабелем. На консоли управления модулятора устанавливаются необходимые параметры модулятора (частота канала вещания, тип модуляции, символьная скорость, уровень сигнала). В итоге на RF-выходе модулятора будет присутствовать сигнал DVB-C (или T) на определенной частоте. Этот сигнал можно использовать по своему усмотрению.

Как можно использовать цифровой DVB-C/T модулятор?

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

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

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

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

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

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

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

Какие бывают DVB-C/T модуляторы?

Как сообщалось выше, DVB-C/T модулятор состоит из двух основных функциональных модулей – энкодера и модулятора. Задача энкодера (их еще называют кодерами) кодировать в формат h364 видеоданные, получаемые из встроенного интерфейса HDMI. На модуляторе устанавливаются необходимые параметры модулятора (частота канала вещания, тип модуляции, символьная скорость, уровень сигнала). В зависимости от набора функций, и соответственно возможностей, модуляторы имеют соответственно разную стоимость. Например, самый простой DVB-C/T модулятор RFTEL MTM-01. Этот модулятор отличает простота в эксплуатации. Отличное соотношение цены и качества. Энкодер и модулятор не требует настроек. Входной сигнал подается на HDMI интерфейс. Энкодер автоматически определяет разрешение входного сигнала и с таким же разрешением направляет транспортный поток на модулятор. В модуляторе также большинство параметров уже заданы (модуляция, символьная скорость, уровень сигнала и номер LCN) нужно лишь выставить необходимый частотный канал в диапазоне 139-950 МГц dip-переключателем. Такой модулятор будет полезен пользователям, которые не знакомы с особенностями настроек цифровой модуляции и кодирования. Ошибок быть не может. Если устройство исправно и на него подан сигнал, то готовность к работе подтвердит зеленый светодиод.

Еще одна группа цифровых модуляторов имеет большие возможности за счет расширенных функций. Можно задавать разрешение кодирования видео/аудио сигнала, тип модуляции, символьную скорость, уровень сигнала, данные NIT-таблицы. Такие модуляторы могут иметь кроме HDMI интерфейса дополнительно RCA интерфейс. Управление настройками осуществляется с передней панели кнопками, а отображение статуса настроек происходит на LCD дисплее также на передней панели. Эти устройства дороже и предназначены для пользователей знакомых с основами цифрового телевидения, например это DVB-C/T модулятор EM101 MPEG2/h364 SD/HD.

Более продвинутая группа цифровых модуляторов кроме опций установки разрешения кодирования видео/аудио сигнала, типа модуляции, символьной скорости, уровня сигнала, данных NIT-таблиц, интерфейсов HDMI и RCA (опционально), а также консоли управления на передней панели (кнопками и LCD дисплей) имеют еще и возможность дистанционного управления посредством вэб-интерфейса. Такие устройства как правило занимают верхний ценовой диапазон для подобных устройств и предназначены для продвинутых пользователей, хорошо знакомых с цифровым телевидением. Например, это DVB-T модулятор TERRA MHD101. Ниже приведен скриншот вэб-интерфейса модулятора.

Rf / Gz интерфейс | Разработка решений

dsTest поддерживает возможности эмуляции сервера и клиента для интерфейса 3GPP Diameter Rf / Gz. Протестируйте интерфейсы шлюза PDN (PGW) и интерфейсы функции управления сеансом вызовов IMS (CSCF) в сетях 4G и LTE с помощью нашего эмулятора автономной системы зарядки (OFCS). Используйте моделирование функции запуска зарядки (CTF) в приложении Rf Interface, чтобы проверить емкость и производительность OFCS. Протестируйте взаимодействие VoLTE и PCC с помощью приложения интерфейса Rf / Gz с другими приложениями интерфейса dsTest, такими как Gx, Rx, Ro и S6.Используйте эмулятор OFCS и приложение интерфейса RF в тандеме для тестирования агентов маршрутизации Diameter (DRA), прокси, агентов ретрансляции и агентов перенаправления. dsTest предоставляет больше инструментов для тестирования LTE. Интерфейсы Rf / Gz указаны в 3GPP TS 32.240, TS 32.251 и TS 32.299.

Реализация

Приложение Rf Interface поддерживает следующие сценарии тарификации:

• Тарификация на основе событий
• Тарификация на основе сеанса

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

Тестирование PGW / CSCF / CTF (эмуляция сервера)

Эмулятор OFCS обрабатывает автономные процедуры начисления платы на основе настраиваемых профилей абонентов, реагируя на события начисления платы от CTF и устраняя необходимость выделения производственной OFCS для лабораторных работ.

Узнайте больше о нашем эмуляторе OFCS .

Тестирование OFCS (клиентское моделирование)

Приложение Rf Interface можно использовать для моделирования функций CTF PGW или CSCF для определения влияния новых стратегий начисления платы или функций и стандартов OFCS до их развертывания в сети.Приложение Rf Interface позволяет пользователю проверять производительность и пропускную способность OFCS в реалистичной сетевой среде, копируя конфигурацию развертывания. CTF может имитировать следующие действия по учету диаметра в OFCS:

• Начало
• Промежуточный
• Остановка
• Событие
• Прервать

Расширенные функции тестирования

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

SmartMessageElement — вставляйте, удаляйте или заменяйте элементы в сообщениях Diameter, RADIUS, MAP, LDAP, GTP, REST или SOAP с помощью нашего решения SmartMessageElement.Определите патентованные сигнальные или поврежденные элементы, чтобы облегчить отрицательное тестирование. Вы можете указать, когда ваши элементы используются с SmartEvents.

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

Diameter Dictionary — Определите набор шаблонов сообщений, по которым все сообщения будут проверяться с помощью нашего Diameter-словаря. Независимо от того, проводите ли вы нагрузочное тестирование или тестируете функциональность, все сообщения проверяются.

Операционные измерения

dsTest предоставляет богатый набор измерений для приложения интерфейса Rf / Gz:

• Попытки, успешные и неудачные попытки транзакционного и транспортного уровня
• Продолжительность транзакции, количество транзакций в секунду и задержка приема-передачи
• Счетчики сообщений и байтов
• Обнаруженные ошибки и сообщения об ошибках, полученные в сообщениях

См. Нашу онлайн-справку по измерениям Rf / Gz, измерениям диаметра и измерениям гнезд.

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

Поддерживающие стандарты

Поддержка интерфейса

Rf — SBC Core 6.2.x Документация

Обзор

В этом документе описывается поддержка интерфейса Rf на SBC в качестве элементов сети IMS P-CSCF и IBCF.

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

• Подписка — начальная подписка, отмена подписки, отмена подписки с помощью уведомления, административная отмена подписки с помощью CLI / EMA
• Регистрация — начальная регистрация , отменить регистрацию, отменить регистрацию с помощью уведомления, Отменить регистрацию в административном порядке с помощью CLI / EMA
• Sessions — ACR (START / STOP / INTERIM / EVENT) для установки сеанса, прерывания, длительных вызовов и неудавшихся вызовов соответственно.
• Реле уведомления вне диалога — создается запись о событии
• Реле сообщения вне диалога
• Реле публикации вне диалога
• Реле опции вне диалога
• Реле REFER вне диалога

Сетевые элементы IMS обмениваются информацией о начислении платы друг с другом с помощью полей заголовка SIP. Заголовки SIP «P-charge-Vector» и «P-charge-Function-Address», как определено в RFC 3455, используются для передачи информации о начислении платы между элементами базовой сети IMS.

Сетевые элементы IMS (S-CSCF, P-CSCF, I-CSCF, BGCF, IBCF и MGCF) применяют автономную тарификацию через интерфейс Rf, используя адрес CDF, полученный через сигнализацию SIP, или локально настроенный адрес CDF в сетевой элемент IMS.

Архитектура начисления платы, реализующая Diameter, придерживается структуры, в которой все коммуникации для целей тарификации в автономном режиме между CTF (Diameter-клиентом) и CDF (Diameter-сервером) осуществляются в эталонной точке Diameter Rf, где CTF сообщает информацию о начислении платы. в функцию сбора данных (CDF).CDF использует эту информацию для построения и форматирования CDR.

Архитектура логической автономной зарядки 3GPP

Контрольная точка Rf от функции запуска зарядки (CTF) до функции данных зарядки (CDF) предназначена для передачи событий автономной зарядки. На следующем рисунке показано положение Rf в общей архитектуре начисления платы в рамках проекта партнерства третьего поколения (3GPP).

Рисунок: Сетевая архитектура 3GPP

Клавиша
CTF: функция триггера зарядки CDF: функция данных зарядки CGF: функция шлюза зарядки BD: домен биллинга.Это также может быть устройство посредничества при выставлении счетов / система постобработки.

Ядро SBC поддерживает следующие функциональные возможности интерфейса Rf:

• Автономный биллинг на основе интерфейса RF в формате IBCF или P-CSCF, который совместим со стандартной IMS вместе с CDR на основе файлов и потоков.
• Общесистемный флаг для выбора тарификации на основе CDR / потоковой передачи или тарификации на основе Rf-интерфейса.
• Диаметр основания по направлению к интерфейсу RF.
• Поддержка узла диаметра приложения Rf вместе с существующим приложением Rx.Узел Diameter использует «Таблицу маршрутов» для поиска однорангового узла для исходящего запроса на основе области назначения и приложения.

Интерфейс Rf настраивается с помощью следующих шагов:

1. Настроить узел Diameter — настроить конфигурацию узла Diameter (SBC), указав первичный и вторичный исходный хост, а также группу IP-интерфейсов и IP-адрес, используемый узлом для создания подключений к вглядеться.

   % set addressContext  diamNode  primaryOriginHost  secondaryOriginHost  ipV4Address  ipV6Address  ipV6Address  ipV6Address 
    

2. Настройка одноранговых узлов Diameter - Rf-серверы, которые используются в качестве CDF, настроены как одноранговые узлы Diameter, включая IP-адрес, имя FQDN и порт TCP.

   % set addressContext  diamNode  peer  fqdn  ipAddress  tcpPort  состояние включено 

3. Сконфигурируйте маршруты области для этого узла Diameter - определите полное доменное имя области для этого маршрута и однорангового узла, которому принадлежит область.

   % set addressContext  diamNode  realmRoute  область  peer  состояние включено 

Используйте объект глобальной сигнализации Diam Sig Controls для настройки глобальных средств управления сигнализацией диаметра, таких как включение приложения Rf Accounting на системном уровне для отправки учетной информации через интерфейс RF.См. «Сигнализация - интерфейс командной строки» для подробностей конфигурации.

Функция запуска зарядки

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

CTF состоит из двух функциональных блоков:

Сбор показателей учета

Этот процесс демонстрирует следующее поведение:

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

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

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

В зависимости от выбора реализации функции NE (например, обработка служебных событий или сигнализация / пользовательский трафик) распределяются между несколькими физическими «устройствами» в NE. Для сбора необходимой информации о начислении платы из сервисных событий или сигнализации / пользовательского трафика дизайн коллекции учетных показателей должен соответствовать физическому дизайну / распределению этих функций в сетевом элементе (другими словами, сборник учетных показателей сам становится распределенной функцией. ).

Пересылка учетных данных

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

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

Функция данных зарядки

Функция данных зарядки (CDF) получает события зарядки от функции запуска зарядки через контрольную точку Rf. Затем он использует информацию, содержащуюся в событиях начисления платы, для построения CDR. Эта процедура характеризуется следующими условиями:

• CDR могут быть построены из отдельных событий начисления платы, то есть отношения 1: 1 между событием и CDR.
• CDR могут быть построены из набора нескольких событий начисления платы, то есть отношения n: 1 между событием и CDR.
• Каждое событие начисления платы используется ровно для одного CDR, то есть отношение 1: n между событием и CDR (с n> 1) невозможно.
• Несколько событий начисления платы, которые используются для создания одного CDR, не обязательно могут быть одного типа.
• Нет никаких требований или предположений относительно какой-либо синхронизации между приемом события (событий) начисления платы и созданием результирующего CDR.Однако функция CDF способна принимать и обрабатывать события начисления платы и генерировать результирующий CDR почти в реальном времени.
• Связь между CDF и CTF может быть 1: 1 (интегрированная CDF) или 1: n (разделенная CDF). Это включает в себя возможность сетевых элементов разных типов передавать события зарядки в одну и ту же функцию CDF.
• Все события начисления платы, используемые для построения CDR, должны происходить из одного и того же сетевого элемента, т. Е. В функции CDF отсутствует корреляция событий начисления платы между сетями или сетевыми элементами.

Результатами задач CDF являются начисление платы за записи данных (CDR) с четко определенным содержанием и форматом. Содержание и формат этих CDR указываются для каждого домена / подсистемы / услуги в соответствующих спецификациях начисления платы среднего уровня.

Функция зарядного шлюза

CDR, созданные функцией CDF, немедленно передаются в функцию зарядного шлюза (CGF) через контрольную точку Ga. CGF действует как шлюз между сетью 3GPP и доменом биллинга.Он использует контрольную точку Bx для передачи файлов CDR на BD. Связь сущностей между CDF и CGF составляет m: 1, то есть одна или несколько функций CDF могут передавать CDR в один CGF. CGF включает в себя следующие основные функции:

• Прием CDR из CDF через опорную точку Ga в режиме, близком к реальному времени. Протоколы, которые могут пересекать эталонную точку Ga, указаны в 3GPP TS 32.295 [54].
• Предварительная обработка CDR:
  
  • Проверка, консолидация и (пере) форматирование CDR.
  • Обработка ошибок CDR.
  • Постоянное хранилище CDR.
• Маршрутизация и фильтрация CDR, то есть сохранение CDR в отдельных файлах на основе критериев фильтрации, таких как тип CDR, параметры CDR, исходный CDF и так далее.
• Управление файлами CDR, например, создание файлов, триггеры открытия / закрытия файлов, удаление файлов.
• Передача файла CDR на BD.

Функциональные возможности автономной начисления платы

Функциональные возможности автономной начисления платы основаны на том, что сетевые элементы сообщают учетную информацию при приеме различных сообщений, которые запускают формирование начисления платы, поскольку большая часть информации, относящейся к учету, содержится в этих сообщениях.Этот отчет достигается путем отправки запроса учета (ACR) [запуск, промежуточный результат, остановка и событие] от сетевых элементов в CDF.

Офлайн-тарификация подразделяется на следующие типы.

• Тарификация на основе сеанса (типы START, INTERIM, STOP).
• Тарификация на основе событий (тип СОБЫТИЕ) для OOD SUBSCRIBE, REFER, NOTIFY, REGISTER, OPTIONS, MESSAGE и PUBLISH.

Типы ACR START, INTERIM и STOP используются для учета данных, относящихся к успешным сеансам.SBC отправляет записи START и STOP, если включен учет Rf. SBC отправляет доступную информацию о начислении платы в соответствии со спецификациями интерфейса RF.

Напротив, учетные данные СОБЫТИЯ не связаны с сеансами и используются, например, для простой регистрации или опроса или успешного события обслуживания, инициированного сетевым элементом или неудачными попытками установления сеанса.

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

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

Автономная оплата может быть настроена оператором на узлах, для которых отправляются сообщения SIP с запросом учета. В следующей таблице перечислены все возможные ACR, которые могут быть отправлены из P-CSCF, I-CSCF, S-CSCF, MGCF или BGCF.

Таблица: Обработка сообщений диаметра SBC

Сообщение Diameter	Узел IMS Запуск методов SIP / сообщений ISUP
ACR [Start]	Узел IMS отправляет подтверждение ACR (начало) на сервер учета SIP 200 получено Начальное ПРИГЛАШЕНИЕ SIP.
ACR [Промежуточный]	Узел IMS отправляет ACR (Промежуточный) на сервер учета Rf, когда «Промежуточный интервал учета» для сеанса истекает.
	Когда AVP «Acct-Interim-Interval» получен от сервера AAA в сообщении ACA, SBC обрабатывает полученное значение как «Промежуточный интервал учета» для сеанса.
	Когда AVP «Acct-Interim-Interval» НЕ получен от сервера AAA в сообщении ACA, SBC обрабатывает значение «Промежуточный интервал учета» по умолчанию, настроенное в системе, как «Промежуточный интервал учета» для сеанса.
	Когда AVP «Acct-Interim-Interval» НЕ получен от сервера AAA в сообщении ACA и значение «Промежуточный интервал учета», настроенное в системе, равно «0», SBC НЕ отправляет сообщение ACR (Interim) для сессия.
	Когда AVP «Acct-Interim-Interval» получен от сервера AAA в сообщении ACA, SBC отправляет сообщение ACR (Interim) для сеанса на основе значения, полученного в «Acct-Interim-Interval AVP», независимо значения «Промежуточный интервал учета», настроенного в системе.
ACR [Stop]	Узел IMS отправляет ACR (STOP) с кодом причины AVP (код AVP 861) на сервер учета Rf при завершении сеанса. (Сессия, для которой узел изначально отправил ACR (Start)). Примеры завершения: Запрос SIP BYE, полученный для сеанса SIP INVITE от вызывающей или вызываемой стороны Любой аварийный разрыв сеанса SIP (внутренняя ошибка или вызов, выпущенный SBC, например, разъединение вызова из-за истечения таймера бездействия, длительное время звонок, сброс звонка из-за сбоя карты и так далее.)
	Когда текущий сеанс SIP обычно завершается либо пользователем, либо сетью (сообщение SIP BYE, инициированное пользователем или инициированное сетью, было получено узлом IMS после приема SIP Сообщение ACK), SBC отправляет ACR (STOP), как показано ниже.
	Если сеанс SIP не был успешно установлен (то есть, таймер H истекает и SIP ACK не получен, или SIP BYE получен после получения окончательного ответа 200 OK и SIP ACK не получен), SBC отправляет ACR: Код причины AVP (код AVP 861) = «Неудачная установка сеанса» 2
	Когда сеанс SIP завершается узлом IMS из-за системной ошибки (например, системная ошибка или сбой, сбой, сбой карты) после установления сеанса SBC отправляет ACR: Код причины AVP (код AVP 861) = «Неопределенная ошибка» 1 «Неопределенная ошибка» используется, когда конкретные коды причин не определены.SBC отправляет «1» для любых «внутренних» или неопределенных ошибок, которые не могут быть сопоставлены ни с одним из существующих кодов причин.
ACR [Попытка]	Узел IMS отправляет ACR (СОБЫТИЕ) на сервер учета Rf, чтобы сообщить о неудачной попытке сеанса в следующих сценариях: Завершить сеанс из-за получения SIP CANCEL до того, как сеанс INVITE будет установлено, Завершить сеанс из-за получения окончательного ответа SIP (4xx, 5xx, 6xx) до установления сеанса INVITE, Любой аварийный разрыв сеанса SIP из-за внутренней ошибки, например, сброс вызова из-за сбоя карты и т. д.до установления сеанса INVITE. На интерфейсе Rf отсутствует тип записи ACR (ATTEMPT), ACR (EVENT) используется для сообщения о записях попыток.
	Узел IMS отправляет ACR (СОБЫТИЕ) на сервер учета RF, чтобы сообщить о перенаправлении попытки сеанса в следующем сценарии. Сессия перенаправлена ​​из-за получения окончательного ответа SIP (3xx) до установления сеанса INVITE,
	Узел IMS отправляет ACR (СОБЫТИЕ) на сервер учета Rf, чтобы сообщить о перенаправлении сеанса попытаться по следующему сценарию. Сессия перенаправления из-за получения окончательного ответа SIP (3xx) до установления сеанса INVITE
ACR [Событие]	Узел IMS отправляет ACR (СОБЫТИЕ) на сервер учета Rf, чтобы сообщить о несессии связанные события сообщения SIP при получении следующих сообщений.
	Когда успешная транзакция, завершающая диалог регистрации, обнаруживается узлом IMS, узел отправляет ACR, как показано ниже. Код причины AVP (код AVP 861) = «Конец диалога РЕГИСТРАЦИИ» -3 В следующих сценариях: Запрос на отмену регистрации SIP получен от пользователя (истекает = 0). SIP NOTIFY с reg evnt получено уведомление об удалении регистрации. Удаление регистрации по истечении таймера истечения срока регистрации. Регистрация SIP удалена административно с помощью интерфейса командной строки / графического интерфейса пользователя.
	Когда транзакция SIP завершается из-за того, что узел IMS получает / инициирует окончательный ответ 3xx, Узел отправляет ACR, как показано ниже. · Код причины AVP (код AVP 861) = "3xx Redirection" -3xx
	Когда транзакция SIP (транзакция INVITE или Non-INVITE) завершается из-за получения / инициируя ответ об ошибке (то есть 4xx, 5xx, 6xx), узел отправляет ACR с соответствующим значением AVP кода причины (код AVP 861), как показано ниже. «4xx Ошибка запроса» 4xx «5xx Ошибка запроса» 5xx «6xx Ошибка запроса» 6xx
	Когда транзакция SIP (транзакция INVITE или Non-INVITE) завершается из-за узел IMS имеет внутреннюю или неизвестную ошибку (например, ошибку при обработке запроса / ответа), узел отправляет один из кодов причины в ACR, как показано ниже. · Код причины AVP (код AVP 861) = «Неопределенная ошибка» 1 Сбои транзакций, которые не соответствуют предыдущим требованиям, должны регистрироваться как внутренние или неизвестные ошибки. Это универсальный код причины.
	Когда успешная транзакция, завершающая диалог подписки, обнаруживается узлом IMS, узел отправляет ACR с кодом причины AVP (код AVP 861) = конец диалога ПОДПИСАТЬСЯ (-2). Запрос на отмену подписки SIP получен от пользователя (Expires = 0) SIP NOTIFY (в диалоговом окне) с заголовком состояния подписки установлено значение «завершено», уведомляя об удалении подписки Подписка удаляется по истечении таймера подписки SIP-подписка удаляется административно с помощью CLI / GUI
	Когда включен флаг eventAcctState , создаются записи СОБЫТИЙ для OOD SUBSCRIBE, REFER, NOTIFY, RISH, OPTIONS, MESSAGE и PUBLING.

На интерфейсе Rf отсутствует тип записи ACR (ATTEMPT), ACR (EVENT) используется для сообщения о записях попыток

Поддерживаемые пары атрибут-значение (AVP)

Следующие AVP поддерживаются для интерфейса Rf:

Таблица: Rf-интерфейс, поддерживающий пары атрибут-значение

AVP	Код AVP	Описание
Идентификатор сеанса	263	Это поле определяет сеанс операции.
Origin-Host	264	Это поле содержит идентификацию исходной точки операции и область ее инициатора.
Origin-Realm	296	Это поле содержит область инициатора операции.
Область назначения	283	Это поле содержит область домена оператора. Область будет адресована адресом домена соответствующего общедоступного URI.
Destination-Host	293	Это поле типа «DiameterIdentity». Он присутствует во всех незапрошенных сообщениях, инициированных агентом, может присутствовать в сообщениях запроса и не должен присутствовать в ответных сообщениях.
Accounting-Record-Type	480	Это поле определяет тип передачи, то есть событие для начисления на основе события и начало, промежуточный, остановка для начисления на основе сеанса.
Номер учетной записи	485	Это поле содержит порядковый номер переданных сообщений.
Acct-Application-Id	259	Поле соответствует идентификатору приложения для Diameter-приложения и определяется значением 3.
User-Name	1	Это поле содержит имя пользователя, определяемое доменом, то есть каналом-носителем, подсистемой или услугой, как описано в TS среднего уровня.
Acct-Interim-Interval	85	В этом поле указывается предпочтительное промежуточное значение интервала начисления.
Origin-State-Id	461	Это поле содержит состояние, связанное с CTF.
Отметка времени события	55	Это поле соответствует точному времени запроса учета.
Запись маршрута	282	Это поле содержит идентификатор, вставленный узлом ретрансляции или проксирования для идентификации узла, от которого получено сообщение.
Service-Context-Id	461	Это поле указывает услугу и соответствующий TS "среднего уровня".
Сервисная информация	873	Этот параметр содержит индивидуальные параметры услуги, как определено в соответствующем TS "среднего уровня".
Идентификатор подписки	443	Это поле содержит личный идентификатор пользователя и / или общедоступный идентификатор / идентификационные данные пользователя. Имя параметра Тип Код Описание Тип идентификатора подписки 450 Это поле содержит тип идентификатора. Subscription-Id-Data 444 Это поле содержит информацию об идентификаторе.
Информация IMS	876	Это поле позволяет передавать дополнительные элементы информации, относящиеся к услуге IMS.
Тип события	823	Это поле содержит метод SIP, содержимое заголовка «Событие» SIP и содержимое заголовка «истекает» SIP, если он присутствует в запросе SIP.
Функции узла	862	Это поле содержит функцию узла.
Роль узла	829	Это поле указывает, обслуживает ли узел IMS исходящую или завершающую сторону. AVP «Роль узла» используется, когда SBC действует как P-CSCF и IBCF. Значение AVP «Роль узла» определяется в SIPSG и отправляется в CAM через CC.
Идентификатор сеанса пользователя	830	Это поле содержит идентификатор сеанса.Для сеанса SIP идентификатор сеанса содержит идентификатор вызова SIP. Когда AS действует как B2BUA, входящий сеанс идентифицируется.
Адрес вызывающей стороны	831	Это поле содержит адрес (SIP URI или TEL URI) URI стороны (общедоступный идентификатор пользователя или общедоступный идентификатор службы), инициирующий сеанс или запрашивающий услугу.
Адрес вызываемой стороны	832	Для транзакций SIP, за исключением регистрации, это поле содержит адрес стороны (общедоступный идентификатор пользователя или идентификатор общедоступной службы), которому отправляется транзакция SIP.
Информация о переносимости номера	2024	Это поле содержит информацию о переносимости номера после запроса DNS / ENUM от узла IMS в домашней сети вызывающего пользователя.
Адрес запрошенной стороны	1251	Для транзакций SIP это поле содержит адрес стороны (общедоступный идентификатор пользователя или идентификатор общедоступной службы), которому была первоначально отправлена ​​транзакция SIP.
Inter-Operator-Identifier	838	Это поле имеет тип "Grouped" и содержит идентификацию сетевых соседей (исходящих и завершающихся), обмен которыми осуществляется посредством сигнализации SIP, если они доступны. Имя параметра Тип Код Описание Исходящий IOI 839 Это поле определяет сеть, которая инициировала диалог SIP. Terminating-IOI 840 Это поле определяет сеть, которая завершила диалог SIP.
Идентификатор начисления платы IMS	841	Это поле содержит идентификатор начисления платы IMS (ICID), сгенерированный узлом IMS для сеанса SIP.
Early-Media-Description	1272	Это поле содержит параметры сеанса и мультимедиа, относящиеся к компонентам мультимедиа, активным во время установления сеанса SIP и до того, как будет получен окончательный успешный или неудачный ответ SIP на начальный запрос SIP INVITE .
SDP-Media-Component	843	Это сгруппированное поле, состоящее из нескольких подполей, связанных с одним медиа-компонентом. Поскольку несколько компонентов мультимедиа могут существовать для сеанса параллельно, эти подполя могут встречаться несколько раз.Эта AVP вместе с основными медиа-атрибутами содержит все атрибуты OMR, включая строки посещаемой области и другие атрибуты OMR.
SDP-Session-Description	842	Это поле содержит содержимое «строки атрибутов» (i =, c =, b =, k =, a = и т. Д.), Относящейся к сеансу. Для SDP предложения эта AVP содержит информацию о соединении, представленную в строке c SDP предложения, полученного SBC. Для ответного SDP эта AVP содержит информацию о соединении, представленную в c-строке ответного SDP, отправленного SBC.
IP-адрес обслуживаемой стороны	848	Это поле содержит IP-адрес вызывающей или вызываемой стороны, в зависимости от того, находится ли P-CSCF на связи с вызывающей или вызываемой стороной.
Access-Network-Information	1263	Это поле содержит содержимое P-заголовка P-Access-Network-Info.
Код результата	268	Это поле содержит результат конкретного запроса.
Код причины	861	Это поле содержит значение кода причины от узла IMS, связанное с завершением сеанса.
Отметка времени	833	Это поле содержит отметку времени запроса SIP и отметку времени ответа на запрос SIP.
Subscription-Id-Data	444	Это поле используется для идентификации конечного пользователя.
SDP-Media-Name	844	Это поле содержит содержимое строки «m =» в данных SDP.
SDP-Media-Description	845	Это поле содержит содержимое «строки атрибута» (i =, c =, b =, k =, a = и т. Д.), Относящейся к компоненту мультимедиа. .
Media-Initiator-Flag	882	Это поле указывает сторону, которая запросила изменение сеанса.
Media-Initiator-Party	1288	Это поле содержит адрес стороны, которая инициирует медиа-действие, такое как добавление / удаление, подключение / отключение медиа.
Тип SDP	2036	Это поле содержит информацию о том, является ли медиа-компонент SDP либо предложением SDP, либо ответом SDP.
SDP-TimeStamps	1273	Это поле содержит время предложения SDP и ответа SDP.
SDP-Offer-Timestamp	1274	Это поле содержит время в формате UTC для предложения SDP.
SDP-Answer-Timestamp	1275	Это поле содержит время в формате UTC для ответа на предложение SDP.
Информация о NNI	2703	В этом поле содержится информация о NNI, используемом для соединения и роуминга. Эта AVP применима только для IBCF. В этом AVP присутствуют следующие поля: Имя параметра Тип Код Описание Направление сеанса Перечислимый 2707 Это поле указывает, используется ли для входящего NNI или исходящий запрос на обслуживание на уровне управления в случае соединения и роуминга. Тип NNI Перечислимый 2704 Это поле указывает, является ли тип используемого NNI не-роумингом, роумингом без кольцевой маршрутизации или роумингом с кольцевой маршрутизацией. Режим отношений Перечислимый 2706 Это поле указывает, рассматривается ли другой функциональный объект (например, точка контакта соседней сети) как часть того же домена доверия. Адрес соседнего узла IP-адрес 2705 Это поле содержит IP-адрес плоскости управления соседней точки сетевого контакта, которая обрабатывает запрос на обслуживание в случае соединения и роуминга.
Медиа-компонент	843	В этом AVP добавлены следующие поля: Имя параметра Тип Код Перечислимый 2604 Это поле указывает, вставлен ли локальный GW (TrGW, IMS-AGW) для медиа-компонента SDP. IP-область Значение по умолчанию Перечислимый 2603 Это поле указывает, является ли IP-область, используемая для медиа-компонента SDP, областью IP по умолчанию или нет. Индикация вставки транскодера Перечислимый 2605 Это поле указывает, вставлен ли транскодер для медиа-компонента SDP.
Transit-IOI-List	2701	SBC отправляет AVP «Transit-IOI-List» в сообщениях ACR [START, INTERMEDIATE, STOP, EVENT] через интерфейс Rf. Это выполняется как для сообщений INVITE, так и для сообщений non-INVITE. Это применимо как к сообщениям P-CSCF, так и к сообщениям IBCF Rf.Эта AVP встречается несколько раз в хронологическом порядке, то есть сначала указывается значение в запросе SIP, а затем значения, полученные в ответах SIP. Если доступно только значение для SIP-ответа, Transit-IOI-List для SIP-запроса включается со значением «unknown».
IMS-Communication-Service-Identifier	1281	SBC отправляет AVP «IMS-Communication-Service-Identifier» в сообщениях ACR [START] по интерфейсу Rf. Это применимо для сообщения INVITE.Он содержит идентификатор службы связи IMS (ICSI), содержащийся в заголовке P-Asserted-Service запроса SIP. Это применимо как к сообщениям P-CSCF, так и к сообщениям IBCF Rf.
From-Address	2708	SBC отправляет AVP «From-Address» в сообщениях ACR [START, INTERMEDIATE, STOP и EVENT] через интерфейс RF. В основном это касается сообщений INVITE и non-INVITE, включая информацию из заголовка SIP From. Это применимо как к сообщениям P-CSCF, так и к сообщениям IBCF Rf.
IMS-Emergency-Indicator	2322	SBC отправляет AVP «IMS-Emergency-Indicator» в сообщениях ACR [START, INTERMEDIATE, STOP и EVENT] через интерфейс RF. Это указывает на сеанс IMS как на экстренный сеанс IMS или регистрацию IMS. Это касается как сообщений INVITE, так и REGISTER. Это применимо только к сообщениям P-CSCF Rf
Access-Transfer-Information		Это поле имеет тип «Grouped», который предоставляет информацию о передаче доступа для непрерывности услуги IMS.
		Это поле имеет тип «Перечислимый», который указывает тип произошедшей передачи.
	1250	Это поле имеет тип «UTF8String» и содержит адрес (общедоступный идентификатор пользователя: SIP URI, E.164 и т. Д.) Окончательно заявленной вызываемой стороны.
SIP-Method	824	Это поле имеет тип «UTF8String» и содержит имя метода SIP (INVITE, UPDATE и т. Д.).
Событие	825	Это поле имеет тип «UTF8String» и содержит содержимое заголовка «Событие».
Истекает	888	Это поле типа «Unsigned32» и содержит содержимое заголовка «Истекает».
SIP-Request-Timestamp	834	Это поле имеет тип «Время» и содержит время в формате UTC для запроса SIP (например, Пригласить, Обновить и т. Д.).
SIP-Response-Timestamp	835	Это поле имеет тип «Время» и содержит время в формате UTC ответа на SIP-запрос (например, 200 OK).
IMS-Charging-Identifier	841	Это поле имеет тип «UTF8String» и содержит идентификатор тарификации IMS (ICID), сгенерированный узлом IMS для сеанса SIP.
IMS-Visited-Network-Identifier	2713	Это поле содержит значение заголовка P-Visited-Network-Id, вставленное SBC в исходящий запрос REGISTER.
SIP-Request-Timestamp-Fraction	2301	Это поле имеет тип Unsigned32 и содержит долю миллисекунд по отношению к SIP-Request-Timestamp.
SIP-Response-Timestamp-Fraction	2302	Это поле имеет тип Unsigned32 и содержит долю миллисекунд по отношению к SIP-Response-Timestamp.

Для получения дополнительной информации об AVP см. Следующие документы 3GPP на :

• 3GPP TS 32.299
• 3GPP TS 32.260

Влияние на описание полей варианта входящего и исходящего протокола

Если флаг Rf включен, данные, относящиеся к варианту входящего и исходящего протокола, содержат следующую дополнительную информацию, относящуюся к Rf.

• Функциональность узла: P-CSCF или IBCF.
• Роль узла: исходящий или завершающий. -специфические записи

  Данные
  

  Имя поля	Учет ASCII						Потоковый учет
  	Макс.	STOP	ATTEMPT	INTERMEDIATE	Streaming Идентификатор поля	GMI Тип
  Данные, относящиеся к варианту входящего протокола			1849	Персонажи	42	52	45	38	38	1849	Символы	55	69	59	51	68	СТРОКА

  SBC может вставлять символы, отличные от ASCII, в CDR, когда сообщения анализируются в начальном INVITE.

  рч интерфейс | Связь в реальном времени

  В прошлом посте мы говорили о зарядке VoLTE на высоком уровне. На этот раз мы сосредоточимся на роли сервера приложений телефонии (TAS) в автономной зарядке во время голосового / видеозвонка. Зарядка на TAS описана в 3GPP 32.260 и 32.275. Базовая зарядка довольно проста, но мы также должны учитывать дополнительные услуги, сценарии роуминга и сценарии дождливых дней.

  TAS Charging, Ro, Rf

  Мы уже знаем, что спецификация 3GPP требует, чтобы сетевые элементы, такие как TAS, обеспечивали выставление счетов в автономном режиме , чтобы поставщики услуг могли собирать и сопоставлять информацию о начислении платы из различных источников, а также создавать CDR. Система IMS состоит из множества объектов, которые могут генерировать события начисления платы, которые необходимо сопоставить, чтобы сформировать счет для клиента. Эти элементы упоминаются в нашей терминологии как Charging Trigger Functions (CTF) .Функция CTF работает в связи с обработкой вызовов TAS, получая события вызова SIP, переводя сообщения SIP в сообщения Diameter с параметрами вызова, скопированными в определенный 3GPP набор AVP, и отправляя сообщения Accounting Request (ACR) во внешний CDF. Функция CDF подтверждает получение сообщения ACR, отправляя обратно сообщение Accounting Answer (ACA) , указывающее на успех или неудачу операции. Связь между CTF (TAS) и CDF происходит через интерфейс Rf , который использует протокол Base Diameter.

  Читать далее →

  Нравится:

  Нравится Загрузка ...

  Размещено в IMS, VoLTE | Tagged 4g зарядка, ACR, mmtel, офлайн биллинг, RF интерфейс, RF reference poit, TAS зарядка, volte billing |

  Зарядка долгое время была в моем списке дел. Теперь пришло время, и вы можете ожидать пару сообщений, связанных с зарядкой, в основном, онлайн-зарядки. Сегодня мы рассмотрим самые простые вещи.Подробнее см. 3GPP 32.240.

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

  Charging Specification - источник 3GPP 32.240

  Зарядные механизмы

  Сети

  GSM / UMTS / EPC предоставляют функции, которые реализуют автономные и / или онлайн-механизмы тарификации на канале-носителе (например,грамм. EPC), подсистемы (например, IMS) и уровня обслуживания (например, SMS). Чтобы поддерживать эти механизмы начисления платы, сеть в реальном времени выполняет мониторинг использования ресурсов для этих трех уровней, чтобы обнаруживать соответствующие события, связанные с начислением платы.

  В целом мы распознаем механизмы Online и Offline зарядки . Они могут выполняться одновременно и независимо для одних и тех же событий зарядки.

  Читать далее →

  Нравится:

  Нравится Загрузка...

  Опубликовано в 5G, IMS, VoLTE | Tagged зарядка, функция вспенивания, интерфейс RF, интерфейс ro, зарядка от напряжения |

  MIPI RF Front-End Control Interface (RFFE)

  Первоначально выпущенный в июле 2010 года, MIPI RF Front End Control Interface, MIPI RFFE ^SM , является де-факто стандартным в мире интерфейсом для управления радиочастотным фронтальным интерфейсом. конечные (FE) подсистемы. Он обеспечивает быстрое, гибкое, полуавтоматическое и всестороннее управление сложной средой подсистемы RF, которая имеет строгие требования к производительности и может включать до 19 компонентов на экземпляр шины (до 15 подчиненных устройств и до четырех главных устройств), включая питание. усилители, малошумящие усилители, антенные тюнеры, фильтры и переключатели.

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

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

  Текущая версия MIPI RFFE v3.0 предназначена для обеспечения более точной синхронизации и сокращения задержек, необходимых для продвижения развертывания 5G по всему миру.Новая версия упрощает и оптимизирует интерфейс, чтобы обеспечить более быстрое и динамическое изменение конфигурации внутри подсистем RFFE и между ними, а также предоставить определенные возможности, необходимые для диапазона частот 1 (FR1) традиционных диапазонов сотовой связи до 6 ГГц.

  диапазонов RF для восходящей и нисходящей линий связи увеличились в 5G, а окна разнесения поднесущих (SCS) среди RF-пакетов сузились. MIPI RFFE v3.0 отвечает этим требованиям стандарта 3GPP 5G, предоставляя расширенные функции запуска и функциональные возможности для синхронизации и планирования изменений в настройках регистров либо в ведомом устройстве, либо на нескольких устройствах:

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

  MIPI RFFE v3.0 повышает эффективность пропускной способности и уменьшает задержку пакетов, а также повышает точность размещения триггеров. Например, для операций последовательного запуска, например, версия 3.0 обеспечивает 20-кратное улучшение точности синхронизации.

  MIPI RFFE разработан рабочей группой MIPI RF Front-End Control Working Group. Текущий выпуск, v3.0, был выпущен в 2020 году и обратно совместим с более ранними версиями спецификации.

  Спецификация доступна только членам MIPI Alliance.Для получения информации о присоединении к альянсу MIPI посетите сайт «Присоединиться к MIPI».

  DECT RF интерфейс | Физический уровень

  Физический уровень DECT / РЧ интерфейс включает в себя методы модуляции; доступ с несколькими несущими, маяки, выбор и выделение каналов и т. д.

  ---

  Беспроводные телефоны DECT включают:
  Основы DECT Стандарт DECT DECT RF интерфейс / физический уровень Каналы и диапазоны DECT Безопасность DECT Руководство по покупке беспроводного телефона

  ---

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

  Формат модуляции, система доступа с несколькими несущими, использующая принцип MC / TDMA / TDD (поясняется позже), передача маяковых радиосигналов и распределение несущих - все работают эффективно, не требуя при этом дорогостоящих компонентов.

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

  Модуляция DECT

  Сигнал модулируется с использованием формы модуляции, называемой гауссовой частотной манипуляцией (GFSK), и имеет BT 0,5. Это обеспечивает оптимальное использование спектра для системы.

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

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

  Принцип DECT MC / TDMA / TDD

  Радиоинтерфейс DECT использует ряд методов в своей методологии доступа. Схема использует множественный доступ с несколькими несущими, множественный доступ с временным разделением, дуплекс с временным разделением (MC / TDMA / TDD).

  Базовая система DECT имеет в общей сложности десять возможных несущих частот от 1880 до 1900 МГц, т.е.е. это система с несколькими несущими (MC).

  В дополнение к этому временные измерения для каждой несущей разделены, чтобы обеспечить временные рамки, повторяющиеся каждые 10 мс. Каждый кадр состоит из 24 временных интервалов, каждый из которых доступен индивидуально и может использоваться либо для передачи, либо для приема. Для базовой речевой услуги DECT два временных интервала - с разделением 5 мс - объединены в пару для обеспечения пропускной способности канала передачи для полнодуплексных соединений, обычно 32 кбит / с (кодированная речь ADPCM G.726).

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

  Структура DECT TDMA обеспечивает до 12 одновременных базовых полнодуплексных голосовых соединений DECT на приемопередатчик. Протокол DECT также предоставляет возможность использовать изменяющуюся полосу пропускания путем объединения нескольких каналов в один канал-носитель. Для целей передачи данных может быть достигнута защищенная от ошибок чистая пропускная способность n x 24 кбит / с, максимум до 552 кбит / с с полной безопасностью, применяемой базовым стандартом DECT.

  Использование радиочастотного спектра DECT

  Принцип MC / TDMA / TDD, используемый для базового DECT, обеспечивает в общей сложности 120 дуплексных каналов для устройства DECT в любой момент в любом месте.

  Использование одного и того же канала соседними базовыми станциями или сотами ограничено помехами между ними. Может быть достигнуто отношение несущей к помехам C / I = 10 дБ. Это обеспечивает очень высокий уровень использования спектра и повторное использование различных каналов.

  DECT RF канал вещания

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

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

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

  • Идентификатор базовой станции
  • Возможности системы
  • Статус запроса предложения
  • Пейджинговая информация

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

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

  Динамический выбор и выделение каналов

  Одним из важных аспектов интерфейса DECT RF / физического уровня является распределение каналов. Чтобы уменьшить помехи как для собственных, так и для других каналов, физический уровень DECT включает комплексную методологию для выбора необходимого канала и поддержания наилучших вариантов.

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

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

  Темы беспроводного и проводного подключения:
  Основы мобильной связи 2G GSM 3G UMTS 4G LTE 5G Вай-фай IEEE 802.15.4 Беспроводные телефоны DECT NFC - связь ближнего поля Основы сетевых технологий Что такое облако Ethernet Серийные данные USB SigFox LoRa VoIP SDN NFV SD-WAN
  Вернуться к беспроводному и проводному подключению

  RF Interface Unit

  Серия EX7000 со стандартной и модульной СВЧ- и ВЧ-коммутацией предлагает максимальную производительность, гибкие варианты конструкции и рабочий диапазон, который простирается до 40 ГГц - и все это при компактных размерах.Это инновационное семейство продуктов упрощает разработку индивидуальных требований RFIU с помощью общей аппаратной платформы и программного интерфейса связи, сохраняя при этом внешний вид стандартного продукта COTS.
  • Легко интегрируется в готовую коммерческую продукцию
  • Поддерживаемые и повторяемые сборки продукта
  • Документировано и рассчитано на долгосрочную поддержку по всему миру
  • Встроенные спецификации, детали конфигурации и спецификации компонентов доступны через Интернет из любой точки мира
  
  

  VTI СВЧ-ВИДЕО

  ВЫБОР ПАРТНЕРА
  
  VTI специализируется на разработке и производстве решений с открытой архитектурой для индивидуальных СВЧ-подсистем и широкополосной радиочастотной коммутации.Компания VTI была пионером в разработке первых миниатюрных микроволновых реле и использует более чем многолетний индивидуальный опыт наших инженеров-конструкторов наряду с современными инструментами тестирования и анализа, чтобы объединить преимущества индивидуальной инженерной группы и всемирной группы специалистов. инфраструктура обслуживания и поддержки для наших клиентов.

  Сертификат ISO 9001: 2008, VTI является опытным и проверенным поставщиком испытательных систем для критически важных приложений в аэрокосмической, оборонной, производственной, медицинской и перерабатывающей отраслях.

  class = "row">

  ЛИДЕРЫ ОТРАСЛИ И ЛУЧШИЕ ПАРТНЕРЫ ОТРАСЛИ
  
  Твердая приверженность VTI отрасли в сочетании с тесными отношениями с ведущими производителями лучших в своем классе компонентов дает клиентам VTI наиболее экономичные и комплексные решения, доступные сегодня на рынке.

  ГИБКИЕ РЕШЕНИЯ, ПРЕВОСХОДНЫЙ ДИЗАЙН
  Решения
  VTI используют уникальное сочетание модульности и возможности многократного использования, обеспечивая высочайший уровень гибкости на протяжении всего срока службы системы как с точки зрения аппаратного обеспечения, так и с точки зрения программного обеспечения.VTI включает в себя 3D-моделирование и свой веб-конфигуратор VTI Microwave Configurator, чтобы использовать проверенные передовые практики, методы и лучший в своем классе выбор и размещение компонентов. Клиенты VTI могут быть уверены, что мы используем самые эффективные и высококачественные продукты.

  class = "col-sm-4"> class = "col-sm-8"> class = "row">

  ЭКОНОМИЯ ВРЕМЕНИ И ДЕНЕГ
  
  Начните разработку своей микроволновой подсистемы уже сегодня с помощью Мастера проектирования VTI.

  Попробовать мастер сейчас >>>
  

  RF Интерфейсный кабель SMA / IPEX MHF, 15 см - 10056 - Интерфейсные кабели

  Доставка

  Доставка товаров на складе обычно осуществляется через 1-2 дня после даты заказа.Доставка товаров, отсутствующих на складе, обычно осуществляется через 3-5 недель после даты заказа, в зависимости от сроков поступления товаров и производственных мощностей производителя. Срок доставки клиенту зависит от запрошенного способа перевозки и пункта назначения. Информация о доставке должна рассматриваться только как приблизительная и ни в коем случае не гарантируется Techship.

  Условия поставки и передача права собственности

  Согласно оговоренным в заказе срокам отгрузки.
  1. FCA наш склад, Гётеборг, Швеция, в соответствии с Инкотермс 2010.Право собственности и риск потери и повреждения продукции переходят к Заказчику в соответствии с настоящими условиями поставки. Во избежание сомнений, любые пошлины и экспортные или импортные пошлины должны быть оплачены Заказчиком, если товары отправляются за пределы Швеции.
  2. CPT, Перевозка оплачена до места назначения, в соответствии с Инкотермс 2010. Право собственности и риск потери и повреждения продуктов переходят к Заказчику в соответствии с настоящими условиями доставки. Во избежание сомнений, любые пошлины и экспортные или импортные пошлины должны быть оплачены Заказчиком, если товары отправляются за пределы Швеции.

  Условия оплаты

  Согласно цитате, это может быть изменено в любое время в соответствии с кредитной политикой Techship по собственному усмотрению. При оплате кредитной картой взимается дополнительная комиссия в размере 3,5%, и ваш платеж будет обработан нашим платежным партнером Bambora после отправки заказа. При оплате через PayPal взимается дополнительная комиссия в размере 5%, и вы будете перенаправлены на PayPal после отправки заказа.

  Документация

  Techship предоставит основную документацию по продукту, доступную на веб-портале для клиентов.

  Настройка

  В этот заказ не включены никакие настройки.

  Сертификаты и утверждения оператора

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

  Обращение с неисправными устройствами

  Этот заказ не включает замену неисправных устройств, за исключением случаев, связанных с гарантией.

  Гарантия

  Techship не предоставляет никаких гарантий на продукт, кроме передачи Клиенту гарантии, предоставленной Производителем.

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

  Ограничение ответственности

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

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

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

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

  Программное обеспечение и документация

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

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

  Кроме того, Заказчик не имеет права модифицировать, декомпилировать, реконструировать, переводить, адаптировать, упорядочивать или исправлять ошибки или вносить любые другие изменения в Программное обеспечение или Документацию или создавать производные работы с использованием Программного обеспечения или Документации.

  Несмотря на что-либо в настоящих Условиях и любом Контракте об обратном, подразумевается, что ни Заказчик не получает никаких прав собственности или прав собственности на Программное обеспечение или Документацию, а также какие-либо другие права интеллектуальной собственности.

  Обязательства (Лицензия на программное обеспечение) остаются в силе бессрочно.

  Прочие положения и условия

  1. После получения заказа на поставку, должным образом оформленного в соответствии с настоящими Условиями, Techship в течение трех (3) рабочих дней уведомит Клиента о принятии или отклонении (вместе с разумным объяснением любого такого отклонения) такого заказа на покупку.Techship оставляет за собой право запросить любую дополнительную информацию, которую сочтет необходимой, как до, так и после принятия заказа на покупку. Если Techship по какой-либо причине отклонит такой заказ на покупку, любой полученный авансовый платеж будет возвращен Заказчику.
  2. Если иное не согласовано в письменной форме между сторонами, заказ, размещенный Клиентом, является обязательным и не может быть отменен Клиентом без письменного согласия Techship.
  3. Производитель может в любое время по своему усмотрению и за свой счет вносить изменения в Продукты по форме, соответствию или функциям, при условии, что Заказчик будет уведомлен о любых таких изменениях не менее чем за 30 (тридцать) дней и при условии, что функциональность равна или лучше по сравнению со спецификацией.
  4. Если Производитель прекращает производство и продажу Продуктов, Techship может в любое время по своему усмотрению и без ответственности перед Заказчиком прекратить поставку Продуктов. Techship приложит разумные усилия, чтобы уведомить об этом Клиента с уведомлением за три (3) месяца.
  5. Клиент несет ответственность за уплату всех налогов, таможенных и других пошлин или сборов, которые могут взиматься или начисляться в связи с этим заказом.
  6. Если в соответствии с действующими или будущими применимыми законами или нормативными актами, Techship будет обязан заплатить, или Клиент обязан вычесть из любого платежа Techship любую сумму в отношении любых налогов, таможенных или любых других пошлин или сборов, за которые Клиент несет ответственность. как указано выше, Клиент должен увеличить платеж Techship на сумму, чтобы покрыть такой платеж Techship или удержания Клиента.
  7. Techship приложит все разумные усилия для соблюдения согласованных сроков поставки. Если у Techship в любое время есть основания полагать, что доставка Продуктов будет отложена, Techship должен уведомить Заказчика в письменной форме и указать предполагаемый период задержки.
  8. Обстоятельства, не зависящие от Techship, включая, помимо прочего, обстоятельства, которые могут быть приписаны Клиенту или какой-либо третьей стороне, дают Techship право отложить любое из своих обязательств в такой степени, которая является разумной с учетом всех обстоятельств.
  9. Все транспортные расходы и риск потерь, понесенных в связи с ремонтом и / или заменой дефектных материалов, несет Заказчик при возврате в Techship. Заказчик обязуется соблюдать инструкции Techship относительно утилизации дефектных Продуктов.
  10. Заказчик несет ответственность за получение любых разрешений на экспорт или аналогичных разрешений от соответствующих органов, которые могут потребоваться для экспорта Продуктов или систем, в которых установлены Продукты.
  11. Стороны освобождаются от выполнения или своевременного выполнения любых своих обязательств в соответствии с настоящими Условиями, и любой Контракт, и такие обязательства должны быть продлены на период, разумный в данных обстоятельствах, если их выполнение предотвращается или задерживается промышленными (включая трудовые ресурсы) ) споры или любые причины, выходящие за пределы разумного контроля пострадавшей стороны, которые, не ограничивая каким-либо образом общность вышеизложенного, должны включать стихийные бедствия, стихийные бедствия, пожар, взрывы, беспорядки, войны (объявленные или нет), военные действия, революции , гражданские беспорядки, аварии, эмбарго или реквизиция, нехватка материалов, террористические акты, саботаж, ядерные инциденты, эпидемии, забастовки или задержки в работе субподрядчиков, вызванные любыми такими обстоятельствами (форс-мажор).
  12. Гарантии, данные в настоящих Положениях и условиях, представляют собой единственные гарантии и обязательства, взятые на себя Производителем или Techship в отношении продуктов или любой другой их части, и заменяют все другие гарантии товарной пригодности и пригодности для конкретной цели и средств правовой защиты, предусмотренных в настоящие Условия и положения являются единственными и исключительными средствами правовой защиты.
  13. Ни одна из сторон не имеет права рекламировать или публиковать какую-либо информацию, связанную с этим заказом, без предварительного письменного согласия Заказчика или Techship, в зависимости от обстоятельств.
  14. Настоящие Положения и условия и любой Контракт регулируются и толкуются в соответствии с законодательством Швеции (за исключением норм коллизионного права).

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

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