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

Каждый сервис использует свои решения для маскировки номеров клиентов и курьеров. В данной статье я расскажу, как сделать это с помощью key-value хранилища в Voximplant.

Как это будет работать

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

У нас будет только один нейтральный номер, на который будут звонить и клиент, и курьер. Номер мы арендуем в панели Voximplant. Затем создадим некую структуру данных, где клиент и курьер будут связаны между собой номером заказа (то есть ключом в терминологии key-value storage).

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

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

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

Перейдем непосредственно к реализации.

Вам понадобятся

• верифицированный аккаунт Voximplant, который можно создать здесь;

• приложение Voximplant со сценарием и правилом для сценария (их мы создадим вместе);

• телефонные номера для тестов: арендованный в панели номер, номер клиента, курьера и оператора (в тестовой реализации номер оператора можно не указывать).

1) Чтобы начать разработку, войдите в свой аккаунт: manage.voximplant.com/auth. В меню слева нажмите Приложения, затем Создать приложение в правом верхнем углу. Дайте ему имя, например, numberMasking и снова кликните Создать.

2) Зайдите в новое приложение, переключитесь на вкладку Сценарии и создайте сценарий, нажав на +. Назовём его kvs-scenario. Здесь мы будем писать код, но об этом чуть позже.

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

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

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

5) Осталось привязать его к нашему приложению. Заходим в приложение, открываем вкладку Номера Доступные и нажимаем Прикрепить. В открывшемся окне можно также прикрепить наше правило, тогда оно будет автоматически назначено для входящих вызовов, а все остальные правила будут проигнорированы.

6) Далее необходимо верифицировать аккаунт, чтобы использовать этот номер для звонков.

Отлично, структура готова, осталось заполнить key-value хранилище и добавить код в сценарий.

Key-value хранилище

Чтобы сценарий заработал, нужно положить что-то в хранилище. Это можно сделать, воспользовавшись Voximplant Management API. Я буду использовать Python API client, он работает с Python 2.x или 3.x с установленным pip и setuptools> = 18.5.

1) Зайдем в папку проекта и установим SDK, используя pip:

python -m pip install --user voximplant-apiclient

2) Создадим файл с расширением .py и добавим в него код, при выполнении которого данные о заказе попадут в key-value хранилище. Применим метод set_key_value_item:

from voximplant.apiclient import VoximplantAPI, VoximplantExceptionif __name__ == "__main__":    voxapi = VoximplantAPI("credentials.json")        # SetKeyValueItem example.    KEY = 12345    VALUE = '{"courier": "79991111111", "client": "79992222222"}'    APPLICATION_ID = 1    TTL = 864000        try:        res = voxapi.set_key_value_item(KEY,            VALUE,            APPLICATION_ID,            ttl=TTL)        print(res)    except VoximplantException as e:        print("Error: {}".format(e.message))

Файл с необходимыми credentials вы сможете сгенерировать при создании сервисного аккаунта в разделе Служебные аккаунты в настройках панели.

APPLICATION_ID появится в адресной строке при переходе в ваше приложение.

В качестве ключа (KEY) будет использоваться пятизначный номер заказа, а в качестве значений телефонные номера: courier номер курьера, client номер клиента. TTL нам здесь необходимо для указания срока хранения значений.

3) Осталось запустить файл, чтобы сохранить данные заказа:

python3 kvs.py

Если мы больше не захотим, чтобы клиент и курьер беспокоили друг друга, можно будет удалить их данные из хранилища. Информацию о всех доступных методах key-value storage вы найдёте в нашей документации: management API и VoxEngine.

Код сценария

Код, который необходимо вставить в сценарий kvs-scenario, представлен ниже, его можно смело копировать as is:

require(Modules.ApplicationStorage);/** * @param {boolean} repeatAskForInput - была ли просьба ввода произнесена повторно * @param longInputTimerId - таймер на отсутствие ввода * @param shortInputTimerId - таймер на срабатывание фразы для связи с оператором * @param {boolean} firstTimeout - индикатор срабатывания первого таймаута * @param {boolean} wrongPhone - индикатор совпадения номера звонящего с номером, полученным из хранилища * @param {boolean} inputRecieved - получен ли ввод от пользователя *  */let repeatAskForInput;let longInputTimerId;let shortInputTimerId;let firstTimeout = true;let wrongPhone;let inputRecieved;const store = {    call: null,    caller: '',    callee: '',    callid: '74990000000',    operator_call: null,    operatorNumber: '',    input: '',    data: {        call_operator: '',        order_number: '',        order_search: '',        phone_search: '',        sub_status: '',        sub_available: '',        need_operator: '',        call_record: ''    }}const phrases = {    start: 'Здр+авствуйтте. Пожалуйста, -- введите пятизначный номер заказa в тт+ооновом режиме.',    repeat: 'Пожалуйста , , - - введите пятизначный номер заказа в т+оновом режиме,, или нажмите решетку для соединения со специалистом',    noInputGoodbye: 'Вы - ничего не выбрали. Вы можете посмотреть номер заказа в смс-сообщении и позвонить нам снова. Всего д+обровоо до свидания.',    connectToOpearator: 'Для соединения со специалистом,, нажмите решетку',    connectingToOpearator: 'Ожидайте, соединяю со специалистом',    operatorUnavailable: 'К сожалению,, все операторы заняты. Пожалуйста,,, перезвоните позднее. Всего д+обровоо до свидания.',    wrongOrder: 'Номер заказа не найден. Посмотрите номер заказа в смс-сообщении и введите его в т+оновом режиме. Или свяжитесь со специалистом,, нажав клавишу решетка.',    wrongOrderGoodbye: 'Вы ничего не выбрали, всего д+обровоо до свидания.',    wrongPhone: 'Номер телефона не найден. Если вы кли+ент, перезвоните с номера, который использовали для оформления заказа. Если вы курьер, перезвоните с номера, который зарегистрирован в нашей системе. Или свяжитесь со специалистом,,- нажав клавишу решетка.',    wrongPhoneGoodbye: 'Вы ничего не выбрали. Всего доброго, до свидания!',    courierIsCalling: `Вам звонит курьер по поводу доставки вашего заказа, - - ${store.data.order_number}`,    clientIsCalling: `Вам звонит клиент по поводу доставки заказа, - - ${store.data.order_number} `,    courierUnavailable: 'Похоже,,, курь+ер недоступен. Пожалуйста,,, перезвоните через п+ару мин+ут. Всего д+обровоо до свидания.',    clientUnavailable: 'Похоже,,, абонент недоступен. Пожалуйста,,, перезвоните через пп+ару мин+ут. Всего д+обровоо до свидания.',    waitForCourier: 'Ожидайте на линии,, - соединяю с курьером.',    waitForClient: 'Ожидайте на линии,, соединяю с клиентом.'}VoxEngine.addEventListener(AppEvents.Started, async e => {    VoxEngine.addEventListener(AppEvents.CallAlerting, callAlertingHandler);})async function callAlertingHandler(e) {    store.call = e.call;    store.caller = e.callerid;    store.call.addEventListener(CallEvents.Connected, callConnectedHandler);    store.call.addEventListener(CallEvents.Disconnected, callDisconnectedHandler);    store.call.answer();}async function callDisconnectedHandler(e) {    await sendResultToDb();    VoxEngine.terminate();}async function callConnectedHandler() {    store.call.handleTones(true);    store.call.addEventListener(CallEvents.RecordStarted, (e) => {        store.data.call_record = e.url;    });    store.call.record();    store.call.addEventListener(CallEvents.ToneReceived, dtmfHandler);    await say(phrases.start);    addInputTimeouts();}function dtmfHandler(e) {    clearInputTimeouts();    store.input += e.tone;    Logger.write('Введена цифра ' + e.tone)    Logger.write('Полный код ' + store.input)    if (e.tone === '#') {        store.data.need_operator = "Да";        store.call.removeEventListener(CallEvents.ToneReceived);        store.call.handleTones(false);        callOperator();        return;    }    if (!wrongPhone) {        if (store.input.length >= 5) {            repeatAskForInput = true;            Logger.write(`Получен код ${store.input}. `);            store.call.handleTones(false);            store.call.removeEventListener(CallEvents.ToneReceived);            handleInput(store.input);            return;        }    }    addInputTimeouts();}function addInputTimeouts() {    clearInputTimeouts();    if (firstTimeout) {        Logger.write('Запущен таймер на срабатывание фразы для связи с оператором');        shortInputTimerId = setTimeout(async () => {            await say(phrases.connectToOpearator);        }, 1500);        firstTimeout = false;    }    longInputTimerId = setTimeout(async () => {        Logger.write('Сработал таймер на отсутствие ввода от пользователя ' + longInputTimerId);        store.call.removeEventListener(CallEvents.ToneReceived);        store.call.handleTones(false);        if (store.input) {            handleInput(store.input);            return;        }        if (!repeatAskForInput) {            Logger.write('Просим пользователя повторно ввести код');            store.call.handleTones(true);            store.call.addEventListener(CallEvents.ToneReceived, dtmfHandler);            await say(phrases.repeat);            addInputTimeouts();            repeatAskForInput = true;        } else {            Logger.write('Код не введен. Завершаем звонок.');            await say(inputRecieved ? phrases.wrongOrderGoodbye : phrases.noInputGoodbye);            store.call.hangup();        }    }, 8000);    Logger.write('Запущен таймер на отсутствие ввода от пользователя ' + longInputTimerId);}function clearInputTimeouts() {    Logger.write(`Очищаем таймер ${longInputTimerId}. `);    if (longInputTimerId) clearTimeout(longInputTimerId);    if (shortInputTimerId) clearTimeout(shortInputTimerId);}async function handleInput() {    store.data.order_number = store.input;    Logger.write('Ищем совпадение в kvs по введенному коду: ' + store.input)    inputRecieved = true;    let kvsAnswer = await ApplicationStorage.get(store.input);    if (kvsAnswer) {        store.data.order_search = 'Заказ найден';        Logger.write('Получили ответ от kvs: ' + kvsAnswer.value)        let { courier, client } = JSON.parse(kvsAnswer.value);        if (store.caller == courier) {            Logger.write('Звонит курьер')            store.callee = client;            store.data.sub_status = 'Курьер';            store.data.phone_search = 'Телефон найден';            callCourierOrClient();        } else if (store.caller == client) {            Logger.write('Звонит клиент')            store.callee = courier;            store.data.sub_status = 'Клиент';            store.data.phone_search = 'Телефон найден';            callCourierOrClient();        } else {            Logger.write('Номер звонящего не совпадает с номерами, полученными из kvs');            wrongPhone = true;            store.data.phone_search = 'Телефон не найден';            store.input = '';            store.call.handleTones(true);            store.call.addEventListener(CallEvents.ToneReceived, dtmfHandler);            await say(phrases.wrongPhone);            addInputTimeouts();        }    } else {        Logger.write('Совпадение в kvs по введенному коду не найдено');        store.data.order_search = 'Заказ не найден';        store.input = '';        store.call.handleTones(true);        store.call.addEventListener(CallEvents.ToneReceived, dtmfHandler);        await say(phrases.wrongOrder);        Logger.write(`Очищаем таймер ${longInputTimerId}. `);        addInputTimeouts();    }}async function callCourierOrClient() {    clearInputTimeouts();    Logger.write('Начинаем звонок курьеру/клиенту');    await say(store.data.sub_status === 'Курьер' ? phrases.waitForClient : phrases.waitForCourier, store.call);    const secondCall = VoxEngine.callPSTN(store.callee, store.callid);    store.call.startPlayback('http://cdn.voximplant.com/toto.mp3');    secondCall.addEventListener(CallEvents.Connected, async () => {        store.data.sub_available = 'Да';        await say(store.data.sub_status === 'Курьер' ? phrases.courierIsCalling : phrases.clientIsCalling, secondCall);        store.call.stopPlayback();        VoxEngine.sendMediaBetween(store.call, secondCall);    });    secondCall.addEventListener(CallEvents.Disconnected, () => {        store.call.hangup();    });    secondCall.addEventListener(CallEvents.Failed, async () => {        store.data.sub_available = 'Нет';        store.call.stopPlayback();        await say(store.data.sub_status === 'Курьер' ? phrases.clientUnavailable : phrases.courierUnavailable, store.call);        store.call.hangup();    });}async function callOperator() {    Logger.write('Начинаем звонок оператору');    await say(phrases.connectingToOpearator, store.call);    store.call.startPlayback('http://cdn.voximplant.com/toto.mp3');    store.operator_call = VoxEngine.callPSTN(store.operatorNumber, store.callid);    store.operator_call.addEventListener(CallEvents.Connected, async () => {        store.data.call_operator = 'Оператор свободен';        VoxEngine.sendMediaBetween(store.call, store.operator_call);    });    store.operator_call.addEventListener(CallEvents.Disconnected, () => {        store.call.hangup();    });    store.operator_call.addEventListener(CallEvents.Failed, async () => {        store.data.call_operator = 'Оператор занят';        await say(phrases.operatorUnavailable, store.call);        store.call.hangup();    });}async function sendResultToDb() {    Logger.write('Данные для отправки в БД');    Logger.write(JSON.stringify(store.data));    const options = new Net.HttpRequestOptions();    options.headers = ['Content-Type: application/json'];    options.method = 'POST';    options.postData = JSON.stringify(store.data);    await Net.httpRequestAsync('https://voximplant.com/', options);}function say(text, call = store.call, lang = VoiceList.Yandex.Neural.ru_RU_alena) {    return new Promise((resolve) => {        call.say(text, lang);        call.addEventListener(CallEvents.PlaybackFinished, function callback(e) {            resolve(call.removeEventListener(CallEvents.PlaybackFinished, callback));        });    });};

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

Вводим номер заказа

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

store.input += e.tone;

Если звонящий ввел #, сразу соединяем его с оператором:

if (e.tone === '#') {    store.data.need_operator = "Да";    store.call.removeEventListener(CallEvents.ToneReceived);    store.call.handleTones(false);    callOperator();    return;}

Если он ввел последовательность из 5 цифр, вызываем функцию handleInput:

if (store.input.length >= 5) {    repeatAskForInput = true;    Logger.write('Получен код ${store.input}. ');    store.call.handleTones(false);    store.call.removeEventListener(CallEvents.ToneReceived);    handleInput(store.input);    return;}

Ищем заказ в хранилище

Здесь мы будем сравнивать введенный номер заказа с номером в хранилище, используя метод ApplicationStorage.get(), в качестве ключа используем введенную последовательность:

store.data.order_number = store.input;Logger.write('Ищем совпадение в kvs по введенному коду: ' + store.input)inputRecieved = true;let kvsAnswer = await ApplicationStorage.get(store.input);

Если заказ найден, получаем для него номера клиента и курьера:

if (kvsAnswer) {    store.data.order_search = 'Заказ найден';    Logger.write('Получили ответ от kvs: ' + kvsAnswer.value)    let { courier, client } = JSON.parse(kvsAnswer.value);

Теперь осталось разобраться, кому звонить. Если номер звонящего принадлежит курьеру, будем выполнять переадресацию на клиента, если клиенту на курьера. В этом нам поможет функция callCourierOrClient:

if (store.caller == courier) {    Logger.write('Звонит курьер')    store.callee = client;    store.data.sub_status = 'Курьер';    store.data.phone_search = 'Телефон найден';    callCourierOrClient();} else if (store.caller == client) {    Logger.write('Звонит клиент')    store.callee = courier;    store.data.sub_status = 'Клиент';    store.data.phone_search = 'Телефон найден';    callCourierOrClient();}

Если номера нет в хранилище, просим перезвонить с другого номера, который указывался при оформлении заказа:

else {    Logger.write('Номер звонящего не совпадает с номерами, полученными из kvs');    wrongPhone = true;    store.data.phone_search = 'Телефон не найден';    store.input = '';    store.call.handleTones(true);    store.call.addEventListener(CallEvents.ToneReceived, dtmfHandler);    await say(phrases.wrongPhone);    addInputTimeouts();}

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

else {    Logger.write('Совпадение в kvs по введенному коду не найдено');    store.data.order_search = 'Заказ не найден';    store.input = '';    store.call.handleTones(true);    store.call.addEventListener(CallEvents.ToneReceived, dtmfHandler);    await say(phrases.wrongOrder);    Logger.write(`Очищаем таймер ${longInputTimerId}. `);    addInputTimeouts();}

Звоним клиенту/курьеру

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

await say(store.data.sub_status === 'Курьер' ? phrases.waitForClient : phrases.waitForCourier, store.call);const secondCall = VoxEngine.callPSTN(store.callee, store.callid);store.call.startPlayback('http://cdn.voximplant.com/toto.mp3');

В этот же момент сообщим второй стороне о том, что звонок касается уточнения информации по заказу:

secondCall.addEventListener(CallEvents.Connected, async () => {    store.data.sub_available = 'Да';    await say(store.data.sub_status === 'Курьер' ? phrases.courierIsCalling : phrases.clientIsCalling, secondCall);    store.call.stopPlayback();    VoxEngine.sendMediaBetween(store.call, secondCall);});

Обработаем событие дисконнекта:

secondCall.addEventListener(CallEvents.Disconnected, () => {    store.call.hangup();});

И оповестим звонящего, если вторая сторона недоступна:

secondCall.addEventListener(CallEvents.Failed, async () => {    store.data.sub_available = 'Нет';    store.call.stopPlayback();    await say(store.data.sub_status === 'Курьер' ? phrases.clientUnavailable : phrases.courierUnavailable, store.call);    store.call.hangup();});

За все фразы, который произносит робот, отвечает функция say, а сами фразы перечислены в ассоциативном массиве phrases. В качестве TTS провайдера мы используем Yandex, голос Alena:

function say(text, call = store.call, lang = VoiceList.Yandex.Neural.ru_RU_alena) {    return new Promise((resolve) => {        call.say(text, lang);        call.addEventListener(CallEvents.PlaybackFinished, function callback(e) {            resolve(call.removeEventListener(CallEvents.PlaybackFinished, callback));        });    });};

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

Тестируем

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

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

Если все сделано верно, клиент и курьер смогут созваниваться и обсуждать детали заказа, не зная настоящих номеров друг друга, а значит, не нарушая прайваси. Круто, не так ли?) Желаем вам успешной разработки и беспроблемной доставки!

P.S. Также мой коллега недавно рассказал, как обезопасить общение клиента и курьера с помощью Voximplant Kit (наш low-code/no-code продукт). Если эта тема вас заинтересовала, переходите по ссылке :)

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

Книга довольно поверхностно объясняет как работает WebRTC "под капотом", для подробностей надо читать RFC. Ссылки на RFC различных используемых протоколов буду приводить. Стоит особо отметить главу "Отладка", где неплохо описываются идеи того, как отлаживать различные проблемы с сетью, задержками и прочим.

Итак, часть 1 - вводная.

Что такое Webrtc?

Web Real-Time Communication или сокращенно WebRTC, является и протоколом и API одновременно. WebRTC как протокол - это множество правил для безопасного обмена информацией (обычно медиа) в режиме дуплекс между двумя агентами в сети. WebRTC как API в свою очередь позволяет разработчикам работать с протоколом. API формально определено только для JavaScript.

Такое же разделение и в отношении HTTP и Fetch API: WebRTC-протокол - это как HTTP, а WebRTC API - это как Fetch API в данном случае.

Помимо JavaScript протокол WebRTC реализован также и на других языках програмирования. Можно найти множество реализаций серверов, библиотек, реализующих протокол, примером может стать реализация на go pion/webrtc. Пишется реализация и на rust: https://github.com/webrtc-rs/webrtc (проект довольно интересный, потому что это переписываение pion/webrtc на rust).

Протокол WebRTC поддерживается в IETF в группе rtcweb. API WebRTC задокументировано в W3C как webrtc-pc.

Приемущества WebRTC

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

Итак, приемущества WebRTC:

• Открытый стандарт

• Множество различных реализаций

• Можно работать прямо из браузера

• Обязательное шифрование

• NAT Traversal

• Перепрофилированная существующая технология, то есть не изобретали колес, когда делали WebRTC

• Контроль за перегруженностью

• Задержка (latency, имеется в виду задержка аудио и/или видеопотока) в пределах 1 секунды

WebRTC это набор разных технологий

Это тема, для объяснения которой потребуется целая книга. Для начала разобъем ее на четыре части:

• Сигналинг

• Соединение пиров

• Безопасность

• Общение пиров

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

Интересный факт в WebRTC это то, что каждый шаг использует множество других протоколов!

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

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

Сигналинг или как агенты находят друг друга в сети

Когда запускается WebRTC-агент, он не знает с кем ему соединиться, и какого рода информацией он будет обмениваться. Сигналинг (Signaling) решает эту проблему! Сигналинг нужен для того, чтобы два агента могли найти и вызвать друг друга в сети перед тем, как начать обмен информацией.

Сигналинг использует существующий протокол SDP (Session Description Protocol). SDP это простой текстовый протокол. Каждое SDP-сообщение состоит из пар ключ-значение, расположенных в строгом порядке (rfc4566), которые в свою очередь составляют набор медиа-секций. SDP-сообщения, которыми обмениваются WebRTC-агенты содержит такую информацию как:

• адреса IP и порты агентов, по которым можно соединиться с агентом (это т.н. ICE-кандидаты)

• сколько аудио и видео треков агент желает отправить

• какие аудио и видео кодеки поддерживает каждый из агентов

• значения используемые во время соединения (uFrag/uPwd).

• значения используемые для безопасности (отпечаток сертификата)

Отметим, что сигналинг обычно работает как бы в сторонке; то есть приложения не используют WebRTC для обмена SDP сообщениями. Тут подходит любой способ обмена этими сообщениями: REST, Websocket, да хоть письмом по почте можно отправить другому пиру SDP-сообщение, а тот в свою очередь отправит свое. В своем приложении для тестов я вообще использовал firebase для сигналинга.

Установка соединения и NAT Traversal с помощью STUN/TURN

Теперь у обоих сторон WebRTC агентов достаточно информации о том, чтобы соединиться друг с другом. Далее используется другая устоявшаяся технология под названием ICE.

ICE (Interactive Connectivity Establishment) - это протокол предваряющий WebRTC. ICE позволяет установить связь между двумя агентами. Эти агенты могуть быть в одной и той же сети, а могут быть и на противоположных концах света. ICE решает проблему установления прямой связи без использования промежуточного сервера.

Настоящая магия здесь это т.н. NAT Traversal и STUN/TURN сервера. Обе эти концепции необходимы для соединения с ICE агентом из другой сетки. Далее мы изучим этот вопрос глубже.

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

Шифрование передачи информации с помощью DTLS и SRTP

После того как мы установили дуплексную связь между двумя пирами через ICE, нам необходимо установить шифрованное соединение для обеспечения безопасности при передаче данных. Это обеспечиватся двумя протоколами, которые также предваряют WebRTC: DTLS (Datagram Transport Layer Security), который просто добавляет слой TLS над UPD. (TLS - криптографический протокол используемый для безопасного обмена через https). Второй протокол - это SRTP (Secure Real-time Transport Protocol).

Сначала WebRTC выполняет DTLS-"рукопожатие" через соединение установленное ранее через ICE. В отличие от HTTPS WebRTC не использует CA для сертификатов. Вместо этого просто сверяет отпечатки сертификатов, полученных в ходе обмена SDP-сообщениями на этапе сигналинга. Установленное DTLS соединение далее используется для DataChannel, для обмена простыми данными - бинарными или текстовыми, например сообщения в чате.

Для видео/аудио в WebRTC используется другой протокол: RTP. Для шифрования RTP-пакетов используется протокол SRTP. SRTP сессия инициализируется с помощью ключей шифрования полученных в ходе DTLS сессии (rfc5764). Далее мы обсудим, почему для медиа-данных используется свой собственный протокол.

Теперь все готово! У нас есть двунаправленный и безопасный канал. Если у вас стабильное соединение между вашими WebRTC-агентами, то вышеописанный комплекс процедур достаточен чтобы начать им (агентам) общаться. Однако в жизни все не так идеально, как кажется: мы постоянно будем сталкиваться с потерей пакетов в сети, ограниченной пропускной способностью сети. Дальше мы подумаем, как справляться со всеми этими проблемами.

Общение между пирами через RTP и SCTP

Сейчас мы имеем два WebRTC-агента с безопасным двунаправленным соединением. Давайте начнем взаимодействие! И снова мы используем уже существующие протоколы: RTP (Real-time Transport Protocol), и SCTP (Stream Control Transmission Protocol). Используйте RTP для обмена аудио/видео шифрованным по протоколу SRTP и SCTP для обмена DataChannel-сообщениями, шифрованными с помощью DTLS.

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

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

WebRTC это набор протоколов

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

Кратко: как работает WebRTC (API)

В этой части показано как JavaScript API отображается на протокол. Это не демонстрация WebRTC API, а скорее некоторый набросок для создания у вас ментальной модели, как все работает вместе. Если вы не знакомы с каким-либо из пунктов, не переживайте, можете вернуться сюда когда узнаете больше!

new RTCPeerConnection

RTCPeerConnection - это основа для установления WebRTC-сессии. Объект RTCPeerConnection реализует "под капотом" все протоколы, упомянутые выше. Здесь инициализируются все подсистемы, и пока что ничего больше не происходит.

addTrack

Метод addTrack создает новый RTP-поток. Для потока генерируется случайный Synchronization Source (SSRC). Созданный RTP поток будет затем описан в Session Description-сообщении внутри медиа-секции после вызова createOffer метода. Каждый вызов addTrack создает новый SSRC и добавляет медиа-секцию в SDP-сообщение.

Сразу после того, как SRTP сессия установлена, зашифрованные медиа-пакеты начнут отправляеться через ICE.

createDataChannel

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

Сразу после того, как DTLS сессия установлена, SCTP пакеты начнут отправляться через ICE.

createOffer

createOffer генерирует Session Description для отправки удаленному пиру.

Вызов createOffer ничего не меняет на локальном пире.

setLocalDescription

setLocalDescription фиксирует все, что менялось в созданном RTCPeerConnection для локального пира. Методы addTrack, createDataChannel и другие осуществляют временные изменения до тех пор, пока метод setLocalDescription не будет вызван. В этот метод нужно передавать строку session description сгенерированную методомcreateOffer.

После вызова setLocalDescription сгенерированное SDP-сообщение также отправляется на удаленный пир (выше обусждалось, что это можно делать любым способом), и далее на удаленном пире SDP-сообщение (offer) передается в метод setRemoteDescription. Удаленный пир в свою очередь отправляет свой локальный SDP в ответ (answer), который также нужно передать локально в setRemoteDescription.

addIceCandidate

addIceCandidate позволяет WebRTC-агенту добавить больше удаленных ICE-кандидатов.

ontrack

ontrack - это колбек (функция обратного вызова), который срабатывает как только RTP-пакет был получен от удаленного пира.

oniceconnectionstatechange

oniceconnectionstatechange - это также колбек, который отражает состояние ICE агента. Любые проблемы с сетью отражаются через этот колбек.

onstatechange

onstatechange - этот колбек служит для отслеживания окончания сбора всех ICE-кандидатов. Как только аргумент этого обратного вызова станет null, все ICE-кандидаты собраны.

В следующей части разберем Signaling и SDP.

• Часть 1 Основы передачи данных по линиям электропередач

• Часть 2 Основные блоки устройства (начало)

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

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

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

Zero cross детектор

Как говорилось ранее, передающие и принимающие устройства синхронизируются между собой с помощью отдельного блока zero cross детектора.

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

В электросетях с частотой 50 Гц, синусоида напряжения пересекает ноль 100 раз в секунду.

Есть несколько вариантов исполнения ZC детектора. Ниже я покажу пример реализации на оптопаре.

Начнём с конца схемы сначала представим, как сигнал с ZC детектора попадает на контроллер.

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

На место ключа ставим оптрон. Оптрон (оптопара) это простой элемент, в котором с одной стороны светодиод, а с другой фототранзистор.

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

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

Для выпрямления можно использовать smd мостовой выпрямитель.

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

В datasheet на оптопару пишут максимальный ток, на который рассчитан фотодиод, исходя из этого нужно выбрать сопротивление с расчётом на 310 В. Чтобы резистор не перегрелся, можно вместо одного последовательно поставить несколько резисторов для эффективного отвода тепла (это особенно полезно если у вас SMD резисторы).

Из datasheet на PLC817

На примере PC817 видно, что максимальный ток, который выдержит светодиод - 50 мА. Максимальный коэффициент передачи при 20 мА. И "замыкать ключ" он будет уже и при >1 мА.

SMD резисторы типоразмера 1210 выдерживают рассеивание до 0.5 Вт мощности. Максимальный постоянный ток, который мы может пропускать при 310 вольт равен 0.5/310 = 0.00161 А. С учетом, того что у нас пульсирующее напряжение, округлим до 0.002 А (2 мА). Этого тока достаточно, чтобы "ключ замыкался". Номинал сопротивления при этом равен 310/0.002 = 155000 Ом. Итог: ставим последовательно три SMD резистора, типоразмером 1210, номиналом 51 кОм каждый.

В итоге, схема ZC детектора выглядит примерно так.

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

Схема согласования сигнальных цепей с линией 220 В

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

Из электросети должны проходить только высокочастотные сигналы. Основная гармоника 50 Гц, на которой передаётся электроэнергия, не должна попасть в сигнальные цепи устройства. Также в этой схеме обычно располагается защита от скачков напряжения и перегрузок.

Эта часть схемы принимает различный вид в разных datasheet на готовые PLC микросхемы. Опишем минимально работоспособный вариант.

Можно взять ферритовое кольцо типа 17,5x8,2x5 М2000Н, есть в любом магазине электроники. Провод МГТФ наматываем сразу 3 обмотки в 20 витков.

Конденсатор плёночный из серии MKP или любой аналогичный, который выдерживает от 220 В переменки (с запасом).

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

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

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

Входная цепь измерение полезного сигнала

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

• отфильтровать грубый входящий сигнал, срезав все лишнее;

• после этого усилить сигнал до приемлемого уровня, подходящего для измерения и оцифровки с помощью ЦАП микроконтроллера.

Фильтрация

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

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

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

Усиление

У АЦП есть такая характеристика как разрешение. Оцифровка сигнала происходит с некоторой дискретностью. А после пассивной фильтрации входной сигнал заметно похудеет в амплитуде. И если подать на АЦП очень слабый сигнал, то его форма сильно исказится и потеряется большая часть информации о сигнале.

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

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

Бывает, что одного ОУ не хватает для усиления сигнала до приемлемого уровня. В этом случае можно сразу после первого ОУ поставить второй по аналогичной схеме. В продаже есть микросхемы сразу с двумя ОУ в одном корпусе.

Ссылки на статьи про операционные усилители и их про каскадное подключение оставил в конце статьи.

Выходная цепь генерация полезного сигнала

Задача выходной цепи фильтровать и усиливать сигнал из ЦАП микроконтроллера.

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

Далее сигнал сглаживается фильтром и отправляется в аналоговую часть схемы (усилитель и схема согласования с 220 В).

Можно подумать, что форма сигнала не особо важна при кодировании, так как преобразование Фурье всё равно может вычленить основную гармонику полезного сигнала, отбросив всё лишнее. Но чем сигнал ближе по форме к синусоиде, тем меньше энергии мы будем тратить в пустоту, просто добавляя высокочастотный шум в сеть. И выходной усилитель будет работать стабильнее. Как уже говорилось на входе важна лишь основная гармоника сигнала. Остальные гармоники это шум.

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

При выборе усилителя разбегаются глаза. Не буду рассказывать про всё многообразие, но подскажу вариант для ленивых, как я. Можно использовать одну из готовых микросхем для усиления аудио сигналов в аудиоплеерах. Мощность у них обычно не большая около 1W.

Гуглить их можно по фразе audio amplifier btl 1w. Но тут нужно учесть, что они обычно рассчитаны на аудио сигналы до 20 кГц, и производитель не рассчитывал, что их будут использовать в PLC модеме. Есть модели, которые хорошо усиливают частоты до 100-150 кГц, и обычно в datasheet об этом не пишут.

Плюсы:

• они очень удобны тем что там встроенная стабилизация сигнала;

• есть режим mute - мизерное потребление в режиме простоя;

• хватает однополярного питания не надо париться с блоком питания.

Минусы:

• во включенном состоянии из-за обратной связи съедают входящий сигнал, поэтому усилитель надо выключать, когда устройство в режиме прослушивания (приёма);

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

Примерно так выглядит усиление с однополярным питанием.

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

Итого

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

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

Полезные ссылки

Общее:

• https://nag.ru/articles/article/24485/strasti-po-plc.html Интересная статья по истории PLC;

• https://cmi.to/разрешение-и-разрядность-ацп/ Про разрешение АЦП;

• https://ru.wikipedia.org/wiki/Частотная_манипуляция FSK модуляция;

• http://personeltest.ru/aways/habr.com/ru/post/312810/ - интересно, подробно про ЦАП в stm32;

• https://narodstream.ru/stm-urok-30-hal-dac-sinus-dma/ STM32, синус через DMA;

• http://www.electrosad.ru/Electronics/zaschita.htm Защита электронных схем.

Фильтры:

• https://www.ruselectronic.com/passive-filters/ Пассивные фильтры;

• https://www.ruselectronic.com/achh-and-fchh/ Про АЧХ и ФЧХ.

Операционные усилители:

• https://cxem.net/beginner/beginner96.php ОУ для начинающих;

• http://hardelectronics.ru/lm358.html Примеры одного дешевого ОУ;

• http://easyelectronics.ru/operacionnyj-usilitel.html ещё про ОУ

• http://zpostbox.ru/kaskadnoye_vklyucheniye_operatsionnykh_usiliteley.html Каскадное подключение ОУ.

ZC детекторы:

• https://cxemka.com/62-detektor-perehoda-cherez-nol-s-galvanicheskoi-razvjazkoi-i-bez-neyo.html - пример 1;

• https://radio-samodel.ru/detektor%20nulya.html - пример 2;

• http://radiopolyus.ru/radiolicbez/39-radiokonstruktoru/257-detektor-perexoda-cherez-nol - ещё пример;

Схемы согласования с 220 В в доках на PLC микросхемы:

• https://data.electronshik.ru/z/Datasheet/S/ST7540.pdf ST7540;

• http://old.angstrem.ru/netcat_files/229/254/kr1446xk1.pdf КР1446ХК1;

• https://www.electronshik.ru/catalog/interfeys-modemy-plc PLC микросхемы с datasheet, там много схем и характеристик.

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

Что происходит

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

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

Борьба за сети

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

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

Регулирование рекламы

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

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

Что дальше

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

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

Дополнительное чтение:

• ЖКХ и телеком зачем и почему им работать вместе

• Слияния телеком-операторов: причины и последствия

• На что пересесть провайдеру после ACCEL-PPP

• Новые технологии шифрования: как они работают

• Что лучше x86 или ARM

Четыре года назад одноклассница попросила посоветовать, какое технологическое направление выбрать в вузе её брату: среди рассматриваемых вариантов были разработка ПО, алгоритмы и машинное обучение, математика. Я посмотрела актуальный список специализаций и как типичный бывший связист удивила ответом: "телекоммуникации и связь". Сейчас уже год как выпускник работает в операторе связи, увлекается безопасностью сетей связи и говорит, что ещё три года назад не верил своим ушам и думал, что сфера мертва. Сейчас он больше боится не успеть за всем, что происходит на выбранном пути. А ведь в его размышлениях была доля правды: я помню, как умирал CDMA, как взлетел и сдулся WiMax, как потерпели крушение сервисы из пула VAS, последнее, что я застала, - тихое отмирание 3G. Закрывались профильные курсы по основам связи, устаревали учебники, которые были золотым стандартом, переписывались инструкции, нормы, стандарты, укрупнялись субъекты рынка - казалось, что уходит эпоха и смерть мобильной связи тоже не за горами. Но вскоре стало понятно, что это и была та самая цифровая трансформация - только не из пустых докладов, а реальная, по живому, органичная и правильная. Да, у связи есть будущее - и оно потрясающее для всего человечества.

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

Но это уже реальность, а что же ждёт сферу связи и телекоммуникаций в ближайшем будущем?

Позитивные перспективы

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

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

Интернет вещей и M2M ещё одно направление, которое будет только развиваться, особенно в части использования беспроводных технологий связи. Многочисленные датчики, приёмники, метки, структуры и системы умного дома, умного предприятия, умного транспорта и т.д. представляют большую ценность за счёт высокой энергоэффективности, сбора больших данных и относительной простоты и дешевизны установки, управления и проектирования систем под них. Однако это наиболее уязвимый сегмент с точки зрения атак на инфраструктуру. Поэтому это будет та сфера, где будут нужны даже не DevOps, а настоящие универсальные инженеры 4-в-1: разработчик + сисадмин + сетевик + безопасник. А если в руках такого универсала будет ещё и профильное образование (медицина, промышленность, нефтепереработка и добыча, сельское хозяйство и т.д.), то уже можно начинать присматривать виллу в Каннах востребованность на рынке обеспечена на многие годы вперёд.

Сотовые сети 5G это уже реальность, данность, которая скорее всего в 2022-2023 годах получит активное распространения, преодолев все препятствия со стороны регуляторов и рынка. Думаю, что лаг времени между стандартами 5G и 6G будет не меньше, а то и больше, чем между 4-4,5G и 5G, поэтому все научные открытия, рыночные перспективы и потребительские фишки у нас впереди. Запасаемся конечным оборудованием!

Ещё одно направление, которое уже год кажется перспективным и супер соблазнительным для стартапов и частной разработки, это видеосвязь и видеоконференцсвязь. Действительно, что бы мы без них делали весь 2020 и начало 2021 года? Однако это направление так и останется нишевым и корпоративным продуктом, интерес к которому равномерно спадёт вместе с отступлением пандемии. Дело в том, что видеосвязь для массового потребителя (например, всех абонентов операторов связи) неудобная, сложная в управлении и не всегда эстетичная технология. Нужна качественная видеокамера (они дорого стоят), либо удобный интерфейс закрепления смартфона с хорошей камерой, подготовка, работа над собой Для массового пользователя текстовые мессенджеры и звонки (по фиксированной связи, мобильным сетям и посредством IP-телефонии) остаются приоритетным и наиболее удобным способом быстрой коммуникации.

Связь станет одним из драйверов развития автомобильной отрасли (и транспорта в целом). Беспроводной стандарт Vehicle-to-Everything (V2X) автомобиль (а точнее, транспорт), подключенный ко всему позволит автомобилям не только транслировать информацию и передавать водителю (и другим машинам в самом широком смысле слова) важные, критические данные, но и позволит реализовать современные решения в медиа сервисах, безопасности, навигации, управлении контентом и т.д. Кроме этого, продолжат развиваться стандарты V2V (транспорт к транспорту), V2I (транспорт к инфраструктуре), и это опять же станет частью крупных отраслевых систем, а не только пользовательской историей. Учитывая, что сейчас а таких автомобильных сетях активно используется 4G/LTE, 5G очевидно ускорит эти процессы. Думаю, подключённые автомобили станут отраслевым стандартом в течение 5 лет.

Связь (проводная и беспроводная) уже сейчас стала фактором сращивания множества отраслей, дальше взаимопроникновение и созависимость будут только глубже: промышленность, образование, медицина, разработка ПО, строительство станут первыми отраслями, где процессы будут самыми заметными. Огромное значение в отрасли связи нарастят языковые технологии и технологии обработки NLP (Natural Language Processing) причём запрос на такой анализ будет исходить как от науки, так и от коммерции. Кстати, именно на стыке NLP и систем коммуникации искусственный интеллект может стать по-настоящему приближенным к естественному.

А теперь о неожиданном. В 2013-2015 годах по российскому телекому гремела идея виртуальных операторов связи MVNO (Mobile Virtual Network Operator операторы, которые имеют операционную деятельность и биллинг, но работают на чужих инженерных мощностях и наземной инфраструктуре) были какие-то частные решения, туристические операторы, где-то до сих пор можно увидеть пакеты подключения Ашана. Но потом идея в России заглохла (в Европе они живут и процветают) и MVNO осталось не так много, а на слуху так, пожалуй, одна Yota. Между тем после открытия границ и окончания (или приемлемого ослабления) пандемии идеи MVNO могут резко ожить, послужить на благо туристической отрасли и получить хороший ARPU. Но для этого желательно, а то и обязательно одно условие: нужно продумать и закрепить возможности безопасного дистанционного оформления электронных SIM-карт. Это способно неплохо встряхнуть рынок и смахнуть пыль с сильно подорожавших тарифных планов сотовых операторов.

Туманные перспективы

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

Ещё одна идея с сомнительным будущим спутниковая связь как массовый продукт (Starlink от SpaceX, проекты Amazon, Facebook). Перспектива скоростного и доступного Интернета в любой точке земного шара выглядит перспективно и привлекательно как с точки зрения обычного пользователя, так и с точки зрения конвергентных систем. Но у нас нет единого мира, без экономических, политических, технологических и идеологических барьеров и границ а значит, паутины поверх паутины не выйдет, будут те же сегментированные, лоскутные части космической связи и, подозреваю, местами не особо доступные. Но мечта о едином надрегуляторном пространстве связи всего мира пожалуй, даже красивее мечты о покорении других планет.

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

Такие направления развития будут иметь несколько важных особенностях, о которых нужно знать, если вы хотите присоединиться к рядам тех, кто 7 мая поднимает тост за связь без брака и коннект без единого разрыва. Итак.

• Самая приятная побочка любых систем связи это big data. Ни один банк не может похвастаться таким объёмом и такой полнотой данных, какая доступна операторам связи. С помощью анализа и обработки всего массива информации можно не только рассылать рекламу (а без этого, увы, не обойдётся), но и совершенствовать сервис и обслуживание абонентов, проводить научные исследования, масштабировать сети, выстраивая оптимальную и самую экономичную инфраструктуру. Кстати, запрос на хорошие аналитические системы и платформы также существует.

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

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

А ведь ещё есть огромный сегмент LPWAN (беспроводных дистанционных сетей с низким энергопотреблением), программно-определяемое радио (SDR), сети с обратным рассеянием с ультранизким энергопотреблением - направления, которые активно развиваются и уже используются. И это новые формы существования связи и радио, которые очевидно будут более гибкими, дешёвыми и менее материальными. Есть фантастический мир виртуальных копий физического мира и интернета чувств и нейроинтерфейсов прогнозируемое экспертами будущее, которое кажется научной фантастикой. Но ведь и связь 5G какое-то время назад казалась какой-то очень туманной перспективой (а сейчас уже здесь), а Bluetooth был средством передачи музыки у студентов и связью для гарнитуры в ухе (а сейчас одна из основных и самых надёжных технологий обмена информацией между устройствами).

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

73, друзья.

Ваш РегионСофт

P.S.: пользуясь, случаем, дадим ссылку на интересную статью, которой очень гордимся, "Связь - нервы войны". Кстати, его id = 500000 ;-)

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

Как квазичастицы помогут в разработке квантовой памяти

Новый физтех Indicator

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

Этим проектом занимается Иван Иорш, профессор Нового физтеха ИТМО. Ранее он вместе с коллегами показал, как можно работать с неклассическими состояниями света: получать одиночные и парные фотоны, добиваться эффекта квантованного движения атомов фактически условий для записи информации в формате квантовой памяти.

За счет чего квазикристалл сумел задержать свет

Новый физтех N+1 Advanced Optical Materials

Михаил Рыбин, доктор науки доцент Нового физтеха ИТМО, простыми словами объясняет суть проделанной работы. Она сконцентрирована в области полупроводников и направлена на расширение знаний о природе, свойствах и законах распространения частиц в их кристаллических структурах. Речь идет о разработке так называемых ловушек для света, которые могли бы открыть новые возможности для проектирования лазеров и сенсоров.

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

Зачем управлять цветом лазера с помощью наночастиц

Новый физтех Коммерсантъ Applied Physics Letters

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

Артем Черепахин, являющийся инженером ДВФУ и выпускником Университета ИТМО, вместе с Сергеем Макаровым, возглавляющим нашу лабораторию гибридной нанофотоники и оптоэлектроники, делятся результатами и объясняют перспективы научной работы.

Как пролить свет под правильным углом

Новый физтех Коммерсантъ ACS Photonics

Олег Ермаков и Андрей Богданов, представляющие Новый физтех, вместе с коллегами из Германии и Австралии предложили новый подход к захвату света оптоволокном. Их решение позволяет работать без существенных потерь даже при углах падения, превышающих семьдесят градусов. Этих результатов они добились за счет использования диэлектрической наноструктуры на торце оптоволокна. Она выступает и в роли кольцевой дифракционной решетки, направляющей свет вдоль оси оптики вне зависимости от исходного угла падения.

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

Как добиться максимальной добротности

Новый физтех Коммерсантъ

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

Другие материалы Нового физтеха на Хабре:

• Новый физтех: избранные исследования [первая подборка]

• Как мы готовили курс по компьютерному моделированию в бакалавриате

• Что общего между каплями в чашке кофе и квантовой механикой

• Как математика помогает создавать перспективные устройства

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

В каждый дом

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

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

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

Право каждого

В конце апреля Бундестаг впервые вынес на уровень законопроекта право на быстрый доступ в интернет. До настоящего момента гарантии в этом отношении предусматривали лишь канал в 56 Кбит/с. Однако пока не ясно, что законодатели понимают под быстрым интернетом, так как в документе не указаны новые требования. Их предстоит определить Федеральному сетевому агентству по предварительным оценкам, нижняя планка составит 20 Мбит/с.

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

Решение Бундестага раскритиковали и представители оппозиционных партий. По их мнению, предполагаемый порог в 20 Мбит/с на домохозяйство недостаточен. В Финляндии аналогичный закон действует с 2010 года там правительство и провайдеры ориентируются на 100 Мбит/с. Возможно, немецким регуляторам еще предстоит проанализировать этот опыт.

Качество цифровой жизни

Развитием широкополосного интернета занимаются и в Швеции. Согласно плану, утвержденному правительством (стр.6), к 2025-му 98% граждан должны иметь гигабитный доступ в сеть. Для оставшихся двух процентов пропускная способность не должна падать ниже 30 Мбит/с.

В конце 2020-го Шведское управление связи и телекоммуникаций отобрало 44 инфраструктурных проекта, и готовится выделить 12 млн долларов субсидий на развитие широкополосных сетей в регионах. Общие расходы на развитие высокоскоростной связи, запланированные только на этот год, там оценивают в 159 млн долларов.

Такая динамика модернизации сетей не является для этой страны чем-то экстраординарным. Швеция занимает второе место в мире по цифровому качеству жизни (Digital Quality of Life Index), уступая только Дании. Индекс DQL включает в себя уровень цифровых государственных услуг, их степень защищенности, безопасность персональных данных, а также качество и доступность широкополосного интернета. Возможно, запуск новых высокоскоростных сетей позволит стране выйти на первое место в мире в этом рейтинге.

Что почитать по теме в блоге у нас на сайте:

• На что пересесть после ACCEL-PPP

• Может ли слишком большой трафик сломать интернет

• Слияния телеком-операторов: причины и последствия

• Оптимизация сетей провайдера: как сделать все правильно

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

Регион пониженных скоростей

Великобритания может похвастаться одним из самых медленных подключений в Европе. Согласно отчету, составленному организациями M-Lab, Code for Science and Society, исследовательской лабораторией Принстонского университета и Google, средний даунстрим по стране не превышает 38 Мбит/с. На первый взгляд, ситуация не выглядит проблемной, но только пока дело не доходит до анализа происходящего в отдельных уголках страны. Так, в деревушке Тримли-сен-Мартин скорость загрузки контента составляет менее 0,7 Мбит/с.

Британское правительство уже занимается решением этого вопроса. Власти инициировали программу, в рамках которой к 2025 году планируют протянуть оптоволокно в каждый дом. Чтобы стимулировать провайдеров, регулятор субсидировал развитие инфраструктуры, и в British Telecom (BT) решили начать тестировать полое оптоволокно (hollowcore fiber).

Что такое полое оптоволокно

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

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

Перспективы

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

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

Кто еще работает этой технологией

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

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

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

Больше материалов о работе интернет-провайдеров в нашем блоге на сайте:

• В чем причина дефицита жестких дисков и как он повлияет на провайдеров

• Экономия на спичках: критические ошибки в строительстве сетей операторов связи

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

• Зачем провайдеру выделять VLAN каждому клиенту

  ---

Продолжаем делиться материалами [раз, два] о работе операторов связи, их инструментарии и вопросах, с которыми они периодически сталкиваются. В этой подборке посты о причинах дефицита сетевого оборудования и HDD, альтернативах VPN/IPoE-сервера ACCEL-PPP и прокладке новых широкополосных линий связи в развитых странах.

Мировые практики и регулирование

ЖКХ и телеком зачем и почему им работать вместе. Разбираемся, насколько эффективен вид сотрудничества, когда застройщик и телеком-оператор внедряют в новостройке элементы умного дома. Обсуждаем опыт зарубежных стран Тайвани, Испании, Великобритании и объясняем, можно ли эффективно адаптировать его для российских реалий.

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

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

Что мешает работе провайдеров

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

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

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

Сети и протоколы

На что пересесть после ACCEL-PPP. Это открытый VPN/IPoE-сервер для Linux. Он позволяет настроить доступ абонентов к интернету и отлично подходит для небольших провайдеров. Но с ростом клиентской базы его возможностей начинает не хватать. Приводим плюсы и минусы ряда альтернативных решений, которые можно найти на рынке.

CG-NAT зачем нужен и как начать пользоваться. Статья, где мы разбираем несколько решений для работы с CG-NAT, в том числе A10 Networks Thunder, F5 BIG-IP и Cisco ASR 9000. Также приводим небольшую инструкцию, как самостоятельно настроить NAT и управлять им.

Почему шифрование DNS не всегда эффективно обсуждаем экспертные мнения. Обзорный материал о том, почему DoH и DoT не оказывают положительного влияния на защищенность подключений и даже могут вредить ей. В этом хабрапосте мы обсуждаем уязвимые места протоколов Server Name Indication (SNI) и ответы Online Certificate Status Protocol (OCSP) а также новые кибератаки, использующие DNS-over-HTTPS.

Как масштабировать BRAS ключевые требования. Рассказываем, как расширить возможности сетевой инфраструктуры в частности, говорим о вертикальном и горизонтальном масштабировании для схем L3 и L2 BRAS. В первом случае система взаимодействует с абонентами через промежуточные маршрутизаторы, а во втором напрямую. Кейсы разбираем с примерами на базе серверов Intel и AMD и схемами подключения.

Дополнительное чтение у нас в блоге и на Хабре:

• Что лучше x86 или ARM

• Может ли слишком большой трафик сломать интернет

• Зачем британскому провайдеру полое оптоволокно

• Фейковые комментарии могли повлиять на решение об отмене сетевого нейтралитета

• Вам не нужен end-to-end? Борьба с шифрованием в западном мире набирает обороты