Русский
Русский
English
Статистика
Реклама

Radio

Из песочницы Еще раз о визуализации input типа checkbox и radio. Для тех, кто забыл как

15.07.2020 14:22:53 | Автор: admin
Тема старая и уже, как выяснилось, подзабытая.

Недавно у меня была короткая работа по разработке ТЗ на модернизацию давно существующего проекта. И, в частности дело касалось стилизации пресловутых <input type="checkbox">. Выяснилось, что исполнитель, программист на все руки даже не понял, что я ему на словах объяснял как это сделать. Пришлось делать примеры и, как результат, появился этот текст.

Напомню, что сейчас checkbox и radiobox разные сайты изображают по-разному. Бывает, что не отмеченный input сразу и не разглядишь такой он дизайнерский красивый, а у последних версий Chrome выбранные checkbox стали гнусного цвета циан.

Итак, ситуация


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

Маркетологи и рекламщики тоже его используют. Что эта система делает неважно, на чем написано неважно.

А важно, что на сайте этого продукта есть много страниц с формами, на которых много input checkbox и radio.

Жалобы сотрудников


Директор: На большом экране плохо видно и незаметны крыжики.
Главбух: На моем компе крыжики выглядят так, у сотрудниц иначе, дома тоже не так, а на планшете совсем иначе.
Маркетолог: А можно, так что бы некоторые не выбранные позиции были красными, а другие выбранные были зелеными?
И т.д., и т.п.

Итак, задача


  1. Минимальными затратами и минимальными изменениями исправить внешний вид checkbox и radiobox.
  2. Сделать стилизацию checkbox и radiobox для разных юзеров. Важно: это закрытый сайт, там всё свои, красоты не нужны, а нужна эффективность восприятия.

Что нельзя


1. Серверную часть трогать нельзя.
2. Файлы javascript трогать нельзя, свой javascript вставлять нельзя.
3. Файлы css трогать нельзя.

А что можно


1. Править html шаблоны.
2. Создать файл стилей для всех юзеров.
4. Создать файл стилей для конкретного юзера или группы юзеров.
А что сделали можно сразу посмотреть на codepen.io, но лучше почитать дальше.

Предварительное изучение показало


1. Почти все <input type="checkbox"> имеют поле name, а которые не имеют, то у них есть id.
2. Все <input type="radio"> имеют поле name, некоторые имеют id.
3. Соответственно, в css к checkbox можно обращаться как по id, так и по name. К radio или по id, или по номеру потомка у родителя.

Фрагменты исходного кода:

/* вариант 1 */<tag><input type="checkbox"> Некий текст</tag>/* вариант 2 */<tag><input type="checkbox"> Некий текст<br><input type="checkbox"> Некий текст</tag>/* вариант 3 */...<label><input type="checkbox"> Некий текст</label>.../* вариант 4 */<td><input id="idxxx" type="checkbox"></td><td><label for="idxxx">Некий текст</label></td>

Так исправим код:

/* вариант 1 */<tag><label class="new-input"><input type="checkbox"><s></s><span>Некий текст</span></label></tag>/* вариант 2 */<tag><label class="new-input"><input type="checkbox"><s></s><span>Некий текст</span></label><br>...</tag>/* вариант 3 */...<label class="new-input"><input type="checkbox"><s></s><span>Некий текст</span></label>.../* вариант 4 */<td><label class="new-input new-input-one"><input id="idxxx" type="checkbox"><s></s></label></td><td><label for="idxxx">Некий текст</label></td>

Всё тоже самое и для <input type="radio">, класс у LABEL тот же.

Что конкретно сделали?


  1. Каждый input (корме варианта 3) обернули тэгом LABEL с нашим классом. Варианту 3 просто добавили класс.
  2. Сразу после input вставили пустой тэг S. Так как сам input будет не видим, то это тэг будет визуализировать это input.
  3. Сопроводительный текст обернули тэгом SPAN (кроме варианта 4). Этот тэг понадобиться, когда будем решать вопрос выравнивания визуального input относительно этого текста.
  4. Варианту 4 добавили еще класс, что бы не осуществлять это выравнивание, раз сопроводительный текст стоит в другой ячейки таблицы. Строго говоря, надо было бы сделать на оборот вариантам 1-3 добавить класс, отвечающий за выравнивание. Но, вариантов 1-3 гораздо больше, чем 4-го и что бы не раздувать html сделано так.

Риторические вопросы и риторические же ответы
1. Зачем тэг S? Ну, не нравится S можно использовать любой другой строчный элемент. Просто он должен быть, его можно стилизовать в зависимости от состояния предшествующего input.

2. Почему тэги S и SPAN без классов? Ну, зачем раздувать html? Тем более, что не очевидно, что одна из конструкций ниже будет работать медленнее другой.

  .new-input > S { }  .new-input > .new-input-S {}

3. Как вы догадались, мне не нравятся идеи БЭМ, тем более идея раздувать html файл обилием упоминаний разных классов. В реальном проекте мы использовали только два класса mni и mnio. :-))

Некоторые предварительные рассуждения и настройки css касательно box-sizing:border-box, нормализации LABEL, селекторов A + B, A ~ B и [attr], псевдоклассов :checked, :disabled и ::before. Кто не уверен, что знает или хочет освежить знания смотрит под катом.

Предварительные рассуждения
1. Напомню, что в старом css (box-sizing:content-box) свойства width и height задают только ширину и высоту содержимого, а padding и border добавляются к этим значениям. box-sizing:border-box меняет схему так, что padding и border включаются в width и height.

2. Проверка показала, что в нашем случае используется старая модель, а менять настройки страниц запрещено. Не наши LABEL это простые строчные элементы, в них только текст. Поэтому стилизуем ВСЕ LABEL.

LABEL {    box-sizing:border-box; cursor:pointer; user-select:none;}LABEL *,LABEL *::before,LABEL *::after {    box-sizing:inherit;}

Т.е., ставим box-sizing:border-box для тэга LABEL, всем его потомкам. Заодно ставим курсор и запрещаем выделение текст (что бы не мешало клику).

3. Комбинация селекторов A + B означает, что стили будут применяться только к селектору B, если он следует сразу ПОСЛЕ селектора A, т.е. только для первого B. С другой стороны, A ~ B означает, что ко всем селекторам B после селектора A, т.е. для первого и последующих.
Естественно, всё в пределах одного родителя.

Как это будем использовать?

<label class="new-input"><input type="checkbox"><s></s><span>Некий текст</span></label><label class="new-input"><input type="radio"><s></s><span>Некий текст</span></label>

/* 1 */.new-input > INPUT + S {}.new-input > INPUT ~ SPAN {}/* 2 */.new-input > INPUT:not(:checked) + S {}.new-input > INPUT:not(:checked) ~ SPAN {}/* 3 */.new-input > INPUT:checked + S {}.new-input > INPUT:checked ~ SPAN {}/* 4 */.new-input > INPUT:disabled + S {}.new-input > INPUT:disabled ~ SPAN {}/* 5 */.new-input > INPUT[type="radio"] + S {}

Первая группа общие стили для тэгов S и SPAN.
Вторая группа стили только когда INPUT НЕ выбран.
Третья стили только когда INPUT выбран.
Четвертая когда INPUT заблокирован.

И, наконец, пятая группа общие стили для тэга S ТОЛЬКО, если он стоит после input radio.
Таким образом, можно изменять стили тэгов S и SPAN в зависимости от состояния input.

4. Поскольку у нас тэг S будет изображать из себя input, то самому input поставим display:none, его не будет видно, а тэг LABEL будет его переключать, а тэг S будет соответственно меняться. Почему не используем html свойство hidden у input? Потому, что на некоторых браузерах hidden у input работает не совсем верно, плюс не будем перегружать html файл.

Итак, начинаем визуализацию input


Пример N 1. Самый простой используем алфавитные символы
html код тот же, а css будет такой:

/* s1 */.new-input > INPUT + S::before {  content: "c";}/* s2 */.new-input > INPUT:checked + S::before {  content: "V";}/* s3 */.new-input > INPUT[type="radio"] + S::before {  content: "r";}/* s4 */.new-input > INPUT[type="radio"]:checked + S::before {  content: "X";}/* s5 */.new-input > INPUT:disabled + S::before {  opacity: 0.5;}/* s6 */.new-input > S {  text-decoration: none;  margin-left: 3px;  margin-right: 6px;}/* s7 */.new-input > S::before {  display: inline-block;  width: 1.25em;  text-align: center;  color: #fafafa;  background-color: #37474f;}/* s8 */.new-input > INPUT[type="radio"] + S::before {  border-radius: 50%;}

Тэг S буде визуализировать input. Но мы разделим его по функционалу: сам тэг S будет отвечать за размещение в LABEL и выравнивание относительно следующего SPAN.

А псевдоэлемент S::before разместится внутри тэга S и будет изображать из себя input.

Строка s1 определяет, какой символ будет помещен в S::before когда input не выбран. В принципе надо было бы написать .new-input > INPUT:not(:checked) + S::before, но некоторые браузеры (например, IE), подобную конструкцию могут и не исполнить.
Строка s2 определяет символ, когда input выбран.
Строки s3 и s4 делают то же для input radio.
Строка s5 описывает, что будет если input заблокирован в данном случае тэг S будет наполовину прозрачным.
Строка s6 определяет выравнивание, в данном случае дает отбивку слева и справа (только в этом примере). Плюс, убирает штатное перечеркивание.
Строка s7 делает квадратик, s8 превращает его в кружок для input radio.

Пример N 1 можно посмотреть на codepen.io. Там представлены нативные input и новые. Первые можно убрать.

Чуток подробнее про display: inline-block, font-size, line-height
Конченая высота строки текста определяется на основе заданных font-size, line-height. При единичном line-height высота будет по font-size, при числовом line-height высота будет по их произведению или, при указании единиц измерения для line-height высоту определит максимальное значение. В примере указан line-height:1.25, поэтому и у S::before указано width:1.25em.

Для S::before указано display: inline-block в этом случае S::before внутри себя будет блоком (можно указать ширину, высоту, рамки и пр.), а снаружи он останется строчным элементом. В дальнейшем об этом будет подробнее.


Вопрос:

Может можно использовать специальные символы? Типа вот этих:

Задать им нужный размер и всё. Нет?

Ответ:

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

Пример N 2. Рисуем элементы input средствами css

html код тот же, а css будет такой:

/* s1 */.new-input > S::before {  content: "";  display: inline-block;  width: 0.75em;  height: 0.75em;  border: 1px solid currentColor;  padding: 2px;  background-clip: content-box;  border-radius: 20%;}/* s2 */.new-input > INPUT[type="radio"] + S::before {  border-radius: 50%;}/* s3 */.new-input > INPUT:checked + S::before {  background-color: currentColor;}/* s4 */.new-input > INPUT:disabled + S::before {  opacity: 0.5;}/* s5 */.new-input > S {  text-decoration: none;  margin-left: 3px;  margin-right: 6px;}

Строка s1 определяет S::before для визуализации input. Это будет inline-block, ширина и высота которого установлена в 0.75em, что примерно равно высоте прописной буквы и зависит от font-size родителя. Задана тонкая рамка текущим цветом, внутренняя отбивка, небольшое скругление углов. И самое важное! установлено свойство background-clip:content-box. Это очень интересное свойство если будет установлен background-color, то он закрасит только контентную часть и не затронет отбивку (padding). Что нам и надо.

Строка s2 для input типа radio делает S::before круглым.
Строка s3 для отмеченного input устанавливает для S::before background-color текущим цветом. Т.е., рисует внутри квадратик или кружок.
Строка s4 отрабатывает блокировку input, строка s5 дает отбивки слева и справа.

Преимущества этого метода

  1. Всё очень просто. Работает на всех браузерах. Даже у IE10 (в эмуляции у 11-го).
  2. Можно раскрашивать по своему усмотрению.
  3. Раз S::before это inline-block, то он сидит на попе базовой линии ровно и никуда с нее не слезает. Если он по высоте будет больше текста, то просто увеличит высоту строки и останется на базовой линии.
  4. Раз визуализация input находится внутри тэга S, то его можно легко позиционировать и выравнивать.
  5. Размеры S::before в em дают возможность задавать его размер относительно размера текста подписи. Можно, к примеру, поставить предельные значения высоты и ширины.

Недостатки этого метода

В основном в использовании размеров в em. Дело в том, что может возникнуть ситуация когда ширина и высота при расчете (из em в px) будет иметь дробное значение. На обычных компьютерах с обычным экраном округление может произойти не корректно. Например, размеры 12.8px на 12.8px у той же Мозилы могут стать как 13px на 12px. Тогда надо ставить фиксированные размеры. Хотя на современных мониторах и видеокартах, ноутбуках, на планшетах и смартфонах этого не происходит из-за того, что точка (пиксель) браузера состоит из нескольких пикселей экрана.

Пример N 2 можно посмотреть на codepen.io. Там представлены нативные input и новые. Первые можно убрать.
Итак, первую задачу визуализацию input выполнили. Переходим к избранной раскраске.

Раскрашиваем input


html для примера:

<label class="new-input"><input name="chb1" type="checkbox" ...><s></s><span>Некий текст</span></label><label class="new-input"><input id="rb1" type="radio" ...><s></s><span>Некий текст</span></label>

К input типа checkbox будем обращаться по name, к radio по id.

Всё красим в синий

/* только input */.new-input > INPUT[name="chb1"] + S,.new-input > INPUT#rb1 + S {  color: #0091ea;}/* только text */.new-input > INPUT[name="chb1"] ~ SPAN,.new-input > INPUT#rb1 ~ SPAN {  color: #0091ea;}/* или всё */.new-input > INPUT[name="chb1"] ~ *,.new-input > INPUT#rb1 ~ * {  color: #0091ea;}

Помним о специфичности в css, эти стили будут более специфичны, чем базовые и сработают обязательно. Чем они отличаются от описанных выше? Тем, что применяются только к избранным input к тем, что имеет указанное значение name и id.

Тут всё хорошо кроме того, что не выбранные input будут не очень хорошо глядеться тонкая синяя рамка мало заметна.

Красим в зеленый, когда input выбран

/* только input */.new-input > INPUT[name="chb1"]:checked + S,.new-input > INPUT#rb1:checked + S {  color: #00c853;}/* только text */.new-input > INPUT[name="chb1"]:checked ~ SPAN,.new-input > INPUT#rb1:checked ~ SPAN {  color: #00c853;}/* или всё */.new-input > INPUT[name="chb1"]:checked ~ *,.new-input > INPUT#rb1:checked ~ * {  color: #00c853;}

Первый вариант, на мой взгляд, не очень хорош зеленым будут и рамка, и внутренний квадратик/кружок. Можно раскрасить только его.

/* только input и только внутри */.new-input > INPUT[name="chb1"]:checked + S::before,.new-input > INPUT#rb1:checked + S::before {  background-color: #00c853;}

Красим в красный, когда input НЕ выбран

/* только input */.new-input > INPUT[name="chb1"]:not(:checked) + S,.new-input > INPUT#rb1:not(:checked) + S {  color: #d50000;}/* только text */.new-input > INPUT[name="chb1"]:not(:checked) ~ SPAN,.new-input > INPUT#rb1:not(:checked) ~ SPAN {  color: #d50000;}/* или всё */.new-input > INPUT[name="chb1"]:not(:checked) ~ *,.new-input > INPUT#rb1:not(:checked) ~ * {  color: #d50000;}

Логика понятна? Можно и дальше делать более сложные конструкции.

Например, при не выбранном input текст должен быть красным и жирным, а при выбранном внутренний элемент input и текст должен быть зеленым. Элементарно!

/* текст, когда нет выбора */.new-input > INPUT[name="chb1"]:not(:checked) ~ SPAN,.new-input > INPUT#rb1:not(:checked) ~ SPAN {  color: #d50000;  font-weight: bold;}/* внутренний элемент input, когда выбран */ .new-input > INPUT[name="chb1"]:checked + S::before,.new-input > INPUT#rb1:checked + S::before {  background-color: #00c853;}/* текст, когда выбран */ .new-input > INPUT[name="chb1"]:checked ~ SPAN,.new-input > INPUT#rb1:checked ~ SPAN {  color: #00c853;}

А, к примеру, надо обработать целую группу input (10-15 штук). Что бы не писать кучу строк можно найти их общего родителя (.parent_element) и сократить условие.

.parent_element > .new-input > INPUT:not(:checked) ~ SPAN {  color: #d50000;  font-weight: bold;}.parent_element > .new-input > INPUT:checked + S::before {  background-color: #00c853;}.parent_element > .new-input > INPUT:checked ~ SPAN {  color: #00c853;}

Всё можно посмотреть в финальном примере на codepen.io

Вот, вроде как, и всё. Осталось только почесать родимые пятна перфекциониста проблемы выравнивания.

Выравнивание визуального input и сопроводительного текста


Для начала напомню общеизвестные вещи на тему размещения текста, форматирования и прочего. Всё под катом.

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

1. Свойство font-size не определяет размер букв, а только размер знакоместа. Есть базовая линия (baseline), по которой расположены нормальные буквы. У ненормальных g ц нижние элементы свисают ниже её. Есть линия капители (cap height) это верхняя граница нормальной прописной (заглавной) буквы. У ненормальных Ё Й верхние элементы вылезают выше её. Иными словами, размер прописной буквы это расстояние от базовой линии до капители, а знакоместо это чуть больше сверху и снизу. Обычно в нормальных шрифтах высота капители это 75% от высоты знакоместо. К примеру, font-size:16px, а размер буквы Н у шрифта Arial будет 12px. Но, бывают специалисты у шрифтов которых всё не так.

2. Свойство line-height определяет высоту строки. Если его вычисленное значение больше, чем указано в font-size, то браузер разместит текст так, что бы нормальная прописная буква была по середине высоты строки. Есть нюансы, но тут они не важны.

3. Соответственно, в нашем случае тэги S и SPAN должны иметь одинаковые значения font-size и line-height желательно заданные где-то выше у родителей. В нашем случае в примерах font-size:16px и line-height:1.25. Поэтому в примере N1 у S::before ширина указана 1.25em, а высота у него определяется автоматически. А в примере N2 (и финальный пример) у S::before ширина и высота 0.75em, что бы был по высоте с прописную букву. Задав другое значение font-size ничего менять не надо. Естественно, эту величину надо подогнать под конкретный шрифт.

4. Если перед текстом стоит какая-то квадратная или круглая штучка, то любой дизайнер скажет, что она должна быть по высоте с прописную букву. А отбивка между ними должна быть в определенных процентах от размера шрифта. Если высота меньше высоты буквы, то она должна быть визуально значительно меньше, но не меньше 50%. Если больше, то тоже визуально значительно больше, но не больше 150%. А вот чуть-чуть, на пару пикселей больше/меньше это ужас-ужас! Ну, и расположена эта штучка должна быть на базовой линии или по середине без всяких там чуть-чуть.

Зачем я это упомянул? А затем, что перфекционисту глаза режет, когда input криво стоит рядом с текстом или прилипает, или далеко, или чуть меньше, или чуть больше. Мы так делать не должны!

Что будет, если сопроводительный текст в SPAN будет выведен в две или три строки? Очевидно, что он залезет под input. Это не красиво, надо исправить.

Один древний метод такой: тэгу S делаем float:left, а тэгу SPAN display:block и overflow:hidden.

Получится колонка текста. Подразумевается, что у кого-то из них будет соответствующий margin, что даст отбивку между ними. Ну, ещё добавляется геморрой с прекращением float после SPAN. Мы пойдем современным путем применим flexbox. Он тут совершенно к месту.

.new-input {  display: flex;  flex-direction: row;  align-items: start;}.new-input > S {  margin-right: 4px;  flex: 0 0 auto;}.new-input > SPAN {  flex: 0 1 auto;}

В этом случае тэг LABEL (который .new-input) будет flex, S и SPAN будут блоками, разместятся вверху LABEL. Текст в SPAN в случае необходимости будет в несколько строк. Вот из-за этого визуальный input описали в S::before. Независимо от высоты SPAN S::before будет расположен на одной базовой линии с первой строкой SPAN. Как вариант можно было указать align-items:center тогда при однострочном SPAN визуальный input был бы вверху, а при двух строках посередине, а при трех у второй строки. В финальном примере можно переключать расположение input.

Вот и всё


Надеюсь, было интересно и кому-нибудь полезно. Прошу, не сильно меня ругать это мой первый опыт на Хабр.

Пример N 1 просто демонстрация взаимодействия изменения input и соседнего элемента.

Пример N 2 визуализация input средствами css, как основа решения.

Финальный пример всё описанное вместе.

Про конкретную реализацию


Там были обширные формы, где блоки полей возможные для правки конкретным пользователям выделялись слабым фоном, а остальным input имели свойство disabled и служили только для информации. Поэтому стиль .new-input > INPUT:disabled + S::before не применяли.
Подробнее..

Open RAN

20.12.2020 14:04:58 | Автор: admin
Disclaimer: все написанное здесь исключительно мое личное мнение, которое может не совпадать с мнением моего работодателя (Intel Corporation) и организации The 3rd Generation Partnership Project (3GPP), в которой я являюсь вице председателем WG3.

Одна из популярных тем последнее время, в России и не только, это концепция Open Radio Access Network (RAN). Название предполагает, что существующие на данный момент сети 3G и 4G, не являются открытыми. Под этим как правило подразумевается, что оператор, развернувший мобильную сеть вынужден использовать сетевое оборудование одного производителя (так называемый vendor lock-in). Идея Open RAN призвана позволить операторам (с относительной легкостью) использовать оборудование разных производителей (mix-and-match).

Возможно бы слышали об анонсах операторов о контрактах с несколькими производителями и не исключено, что это создало у вас впечатление о том, что мобильные сети позволяют использование оборудования разных вендоров. Ведь все компоненты сети и интерфейсы, соединяющие их, стандартизированы (см. организация 3GPP). Это впечатление -ложное. На практике, почти все операторы используют оборудование одного вендора в конкретном регионе если у оператора больше одного поставщика, оборудование разных производителей почти всегда установлено в разных регионах и практически не взаимодействует между собой. Единственным исключением является ядро сети (core network) примеров взаимодействия ядра и радио сети (через интерфейсы S1 в сетях 4G и NG в сетях 5G) разных производителей достаточно много. Что же касается RAN, то не смотря на наличие открытых стандартов для интерфейсов между базовыми станциями (X2 в сетях 4G и Xn в сетях 5G), взаимодействие базовых станций разных производителей явление очень редкое. Как объясняется ниже, открытых стандартов для этого недостаточно.

Интерес операторов изменить существующий статус-кво довольно очевиден -предполагается, что возможность легкой замены части оборудования (а не во всем регионе, как сейчас) увеличит конкуренцию и снизит цены. Это серьезный мотиватор, ведь расходы на радио сеть составляют по разным оценкам от 70% до 90% всех расходов операторов. Впрочем, на данный момент не очевидно, удастся ли операторам реализовать эти преимущества, даже в случае развертывания сетей Open RAN.

Причин как минимум две:
  1. Не смотря на то, что расходы на RAN составляют львиную часть расходов операторов, цена собственно радио оборудования -это только часть этих расходов. Существенной статьей расходов является так же аренда места для установки базовых станций, электричество и транспортная сеть (как правило оптоволокно или microwave). При всех преимуществах Open RAN, даже в теории он не позволяет сократить расходы на, например, аренду -а только на само оборудование.
  2. При использовании оборудования разных производителей возникает проблема интеграции. Эту задачу оператору придется либо взять на себя (т.е. понести дополнительные расходы увеличив штат) или отдать интегратору. Таким образом, как минимум в краткосрочной перспективе, расходы вряд ли значительно уменьшатся.

Стоит также отметить, что концепция Open RAN заинтересовала и регуляторов -как в России, так и в США. В РФ возлагают надежды на то, что это облегчит задачи импортозамещения например потому, что появится возможность заменять (на отечественные) компоненты сети постепенно, а не всю сеть за раз. Как ни странно, интерес США обусловлен похожими соображениями, ведь после падения Motorola и Nortel своих (больших) производителей оборудования для мобильных сетей в северной Америке не осталось. Впрочем, ситуация в США существенно лучше, чем в РФ -там по крайней мере есть такие фирмы как Altiostar, Mavenir и Parallel Wireless. Разумеется, по обьему продаж и линейке продуктов они не могут сравниться с ведущими производителями (Ericsson, Huawei, Nokia), но по крайней мере есть какая-то альтернатива.

Почему же сети 4G не считаются открытыми и что может измениться в 5G? Как уже отмечалось выше, необходимым (но не достаточным) условием для открытости сетей являются открытые стандарты. В области мобильной связи основной организацией по стандартизации является 3GPP, которая определяет как стандарты радио протоколов (air interface), так и стандарты сетевых интерфейсов. Например, в 4G интерфейс между базовыми станциями описан в стандарте
TS 36.423 , его аналог для 5G TS 38.423 (для простоты я привел в качестве примера только стандарт control plane).

Вышеуказанные стандарты находятся в свободном доступе и на первый взгляд может показаться, что этого достаточно для создания совместимых продуктов. Но, при внимательном изучении стандартов, становится ясно, что это не совсем так. Рассмотрим для иллюстрации один из параметров в стандарте TS 38.423 -Cell Capacity Class Value. Базовые станции используют этот параметр для того, чтобы сигнализировать (соседней станции) уровень загруженности. Этот параметр определен в стандарте как:

IE/Group Name Presence Range IE type and reference Semantics description
Capacity Class Value М INTEGER (1..100,...) Value 1 shall indicate the minimum cell capacity, and 100 shall indicate the maximum cell capacity. There should be a linear relation between cell capacity and Cell Capacity Class Value.

Т.е., загруженность базовой станции может принимать значения от 1 до 100 неопределенных единиц! Предположим, базовая станция А сигнализирует базовой станции Б загруженность в 83 попугая. Означает ли это, что базовая станция загружена настолько, что не в состоянии принимать новых пользователей? Или, может быть, парочку еще можно? Стандарт ничего об этом не говорит. Интерпретацию конкретных значений этого параметра (и многих других) при принятии решений (например, handover) приходится устанавливать в процессе интеграции (с конкретным производителем). Как не сложно догадаться, взаимодействие станций разных производителей при таком стандарте несколько затруднительно.

Но это только часть проблемы. Для нормального взаимодействия (multi-vendor interoperability) наличие (даже хорошего) стандарта -недостаточно. Вторым необходимым условием является conformance testing. Организация 3GPP, помимо стандартов, определяет так же test cases, а такие организации как The Global Certification Forum (GCF) занимаются сертификацией. Но и то и другое ориентированно исключительно и только на терминалы. Для сетевого оборудования не существует ни test cases, ни сертификации -каждый оператор делает это самостоятельно.

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

С одной стороны, стандарты базовых станций 5G прописаны со значительно большей детализацией, чем 4G. Например, в 4G стандарт полностью игнорировал вариант развертывания сети с централизацией ресурсов (centralised deployment), при котором функциональность верхних уровней базовой станции сосредоточены в дата центре -в результате, все реализации такого рода были proprietary. 5G устранил этот недочет, определив (помимо монолитной архитектуры базовой станции) еще два варианта:
  • CU/DU functional split
  • Control/user plane separation

С другой стороны, в дополнение к 3GPP была создана организация O-RAN Alliance, в задачу которой входит, среди всего прочего, определение test cases для сетевого оборудования (см. O-RAN WG5).

Полный обзор сетевой архитектуры 5G и сопутствующих технологий выходит за рамки одной статьи и тянет на книгу. Собственно, такая книга была написана -5G Radio Access Network Architecture: The Dark Side of 5G (Wiley IEEE) . Как редактор книги, я с удовольствием отвечу на вопросы по архитектуре радио сетей 5G в комментариях к этой статье.
Подробнее..

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

06.11.2020 22:13:06 | Автор: admin
Привет Хабр.

Тема приема и анализа сверхдлинных весьма интересна, и на Хабре она упоминается весьма редко. Попробуем восполнить пробел, и посмотрим как это работает.


Передатчик VLF в Японии (с) en.wikipedia.org/wiki/Very_low_frequency

VLF


Сверхнизкими считаются частоты радиодиапазона частотой менее 30 КГц. Интерес к ним со стороны военных появился еще давно, когда выяснилось что радиоволны столь большой длины (длина волны до 100 км!) могут проникать сквозь воду, и их можно использовать для связи с подводными лодками. Кто придумал такой способ, сказать сложно, но уже в 1943 г в Германии был запущен передатчик Goliath, передающий данные подводным лодкам на частотах 15-25 КГц. После войны передатчик был разобран, перевезен в СССР и запущен заново, причем согласно Википедии, он работает и до сих пор.

Эффективность любой антенны зависит от длины волны, и для сверхдлинных волн КПД антенны также является сверхнизким при мощности в мегаватт, излучаемая мощность (EIRP) составляет всего лишь 30-50 КВт. Однако, возможность скрытной передачи сигналов подводным лодкам является весьма привлекательной, так что это никого не остановило такие системы, разумеется, работают и сейчас. Передать сигналы диапазона VLF очень сложно, однако принять их может любой желающий. Для этого даже не нужен радиоприемник, частоты 20-30 КГц вполне доступны для обычной звуковой карты ПК. Для этого придется взять кабель подлиннее, подключить его ко входу звуковой карты и пойти с ноутбуком куда-нибудь в лес или в поле, где нет индустриальных помех. Хотя современные технологии предоставляют куда более удобный способ приема онлайн с помощью SDR. Для примера можно посмотреть панораму приемника голландского университета Twente:



Все вертикальные линии это действующие на данный момент системы. Результат удивительный, спектр СДВ забит ничуть не меньше, чем вечерний эфир на вещательном FM-диапазоне. Посмотрим, что мы здесь можем увидеть.

На частотах 12-15 КГц мы видим метки, относящиеся к российской радио-навигационной системе Альфа (полное название РСДН-20 Радиотехническая Система Дальней Навигации). Согласно Википедии, передатчики Альфы работают на частотах 11.9, 12.6 и 14.8 КГц, система обеспечивает точность определения положения до 1.5 км. Впрочем, на панораме никаких импульсов не видно, может у них выходной приемник в Twente недостаточно чувствителен для этого сигнала, или же радиосигналы передаются по какому-то расписанию. Следующим на частоте 16.4 КГц работает передатчик Noviken, расположенный в Норвегии. Перечислять остальные смысла нет, список можно посмотреть в Википедии.

Запись и анализ


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



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



Применим к сигналу FSK-демодулятор, и получаем последовательность бит:



Кстати, скорость передачи составляет 200 бит в секунду чтобы посмотреть youtube, определенно не хватит, но для подводной лодки на глубине 30м даже так и то неплохо. И как нетрудно догадаться, VLF-связь односторонняя ответить экипаж лодки из под воды не может.

Рассмотрим сигнал более подробно. Сохраним полученный файл в WAV, как показано на скриншоте. Разумеется, получить содержимое передачи мы не сможем сигнал скорее всего зашифрован. Но можно посмотреть структуру битового потока, для этого сохраненный файл можно вывести графически с помощью Python. Визуализация позволяет найти закономерности гораздо более наглядно.
Исходный код
from scipy.io import wavfileimport matplotlib.pyplot as pltfrom PIL import Image_, data = wavfile.read('websdr_recording_2020-11-06T15_00_00Z_23.4kHz_.wav')print("WAV: %d samples" % data.shape[0])for iw in range(400, 1024, 2):    print("Saving: {} of {}...".format(iw, 1024))    w, h = iw, 800    image = Image.new('RGB', (w, h))    px, py = 0, 0    for p in range(data.shape[0]):        image.putpixel((px, py), (0, data[p]//16, 0))        px += 1        if px >= w:            px = 0            py += 1            if py >= h:                break    image.save("image-%d.png" % iw)

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



Нетрудно видеть, что при определенной ширине картинки легко угадываются некоторые закономерности. Битовый поток в увеличенном виде:



Желающие могут поэкспериментировать с шириной картинки самостоятельно, принцип, надеюсь, понятен. Наклон линий обусловлен тем, что частоты передатчика и приемника не совпадают. Разумеется, чтобы получить полноценный битовый поток, 20 строчек кода явно недостаточно, а написание цифрового демодулятора с PLL явно выходит за рамки этой статьи. Да и по большому счету, смысла в этом не так уж много сигнал все равно зашифрован, и даже имея битовые данные, больше мы ничего не сделаем. Хотя желающие могут попробовать поискать закономерности самостоятельно.

Заключение


Как можно видеть, изучение подобных систем связи представляет не только технический, но и исторический интерес. А на сверхнизких частотах еще немало интересных сигналов, в том числе и природного происхождения, например резонансы Шумана на частотах 10-20 Герц.

Как бонус для тех, кто дочитал досюда: желающие увидеть вживую, как работает передача и прием на таких частотах, могут попробовать принять немецкую станцию Pinneberg, передающую метеосводки в открытом виде на частоте 147.3 КГц. Декодировать сигнал можно с помощью разных программ, например MultiPSK.

Как обычно, всем удачных экспериментов.
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru