[prig 0]

Зашла тема с использованием NB-IoT. В определённом смысле оказалось сюрпризом (правда и не отслеживал особо).

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

 

Имха, короткая история собственно NB-IoT похожа на стремительный финал более чем 25-летних манёвров. С последующей жуткой массовостью подключения к инетам всего и вся.

Обещают, что NB-IoT - это 10 лет работы в сетях сотовой связи на одной батарейке. И даже выглядит, не как просто замануха.

Понятно, что с жёстким ограничением трафика, да и батарейка может оказаться не самой маленькой.

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

И ещё более серьёзно то, с какой скоростью оно накатывает...

 

А на форуме даже упоминания "NB-IoT" не встречается. Вот такая интересная хрень.

Ну да ладно, это всего лишь лирическое отступление. Есть и конкретные вопросы.

 

Кто-нибудь сколько-нибудь серьёзно разбирался с NB-IoT?

Хотелось бы понять, можно ли говорить о гарантированном минимальном времени активного режима NB-IoT?

И если да, то где и как добыть соответствующие спеки?

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

 

Буду признателен любому, кто хоть что-нибудь полезное подскажет.

За спеки с меня пиво.

 

 

[x893 34]

Открываете datasheet по нужному модулю (например bc66) и смотрите потребление при передаче и приеме.

Скорости передачи тоже там есть.

В России какой оператор поддерживает NB-IoT ?

Не знаю ни одного.

Можно и 100 лет написать - толку то ?

[prig 0]

Открываете datasheet по нужному модулю (например bc66) и смотрите потребление при передаче и приеме.

...

...

В России какой оператор поддерживает NB-IoT ?

Не знаю ни одного.

 

- Читать даташиты приучен. В данном случае они не закрывают весь вопрос.

В инетах есть статья от скандинавов. У них получается изрядная зависимость от оператора на одном и том же тесте с одним и тем же модулем.

Оно и понятно. Если время "активного состояния" разное, будет разное потребление.

Собственно, об этом параметре и был вопрос.

 

- NB-IoT очень скоро будут поддерживать все. Ну очень скоро.

[Integro 0]

Если простыми словами, NB-IoT это тот же GSM только без голоса и только SMS.

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

10 лет это конечно громко сказано но реальность, все зависит от интенсивности передачи и емкости батареи.

Токи передачи, от 50 до 200мА, зависит от модема и выходной мощности. Токи сна микроамперы.

Для примера, токи можно посмотреть на модеме ublox https://www.u-blox.com/sites/default/files/...15025564%29.pdf

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

В Беларуси, NB-IoT первым стал поддерживать оператор "Velcom" в декабре 2017, поэтому думаю что в России эта технология уже давно в ходу.

 

 

[nbn 1]

Peak current 120–300 mA

Sleep current 5 µA

[AlexandrY 2]

Кто-нибудь сколько-нибудь серьёзно разбирался с NB-IoT?

У нас NB-IoT все захватывает энергетическая компания.

О продаже физ лицам или мелким фирмам речи не идет.

Так что интерес нулевой.

[vladec 7]

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

Оно и понятно. Если время "активного состояния" разное, будет разное потребление.

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

[prig 0]

Если простыми словами...

...

В Беларуси, NB-IoT первым стал поддерживать оператор "Velcom" в декабре 2017, поэтому думаю что в России эта технология уже давно в ходу.

 

Спасибо за ответ. Но в общем-то, он мало что мне дал.

 

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

- Вообще-то, стандарт принят в 2016 г.

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

В России в 2018г. утрясли вопросы лицензирования частот и обещали коммерческую эксплуатацию к концу года.

Запущена ли уже где-то коммерческая эксплуатация, не скажу. Да это и не так принципиально. Но "давно в ходу" - это достаточно сильно сказано.

 

- Ну и собственно к вопросу, который меня интересует.

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

 

Сценарий использования следующий:

переход в режим передачи и передача серверу сравнительно короткого пакета UDP (Active),

переход в режим приёма и ожидание ответа от сервера (Idle),

переход в спящий режим (Sleep).

 

В части потребного времени для Idle особых вопросов нет. Есть некоторая разножопица в части Latency для данных из разных источников (встречалось 10с и 3с), но это не слишком принципиально.

Наибольший интерес представляет минимально возможное и гарантированное стандартом время Active. Если стандарт это как-то определяет, ессно.

- И до кучи. Вопрос по времени Active интересен и для стандарта eMTC.

 

 

У нас NB-IoT все захватывает энергетическая компания.

О продаже физ лицам или мелким фирмам речи не идет.

Так что интерес нулевой.

 

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

Да и вообще, я такую тематику в принципе недолюбливаю. И тут пришёл запрос...

 

 

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

 

В том-то и дело, что и без коллизий много вопросов(тесты у скандинавов). А с коллизиями ещё "страньше".

За слух об испанцах спасибо. Мне не попадалось. Попробую в инетах пошарить.

 

[wless.ru 0]

On 9/28/2018 at 11:00 AM, prig said:

Quote

Наибольший интерес представляет минимально возможное и гарантированное стандартом время Active. Если стандарт это как-то определяет, ессно.

- И до кучи. Вопрос по времени Active интересен и для стандарта eMTC.

 

Насколько соображаю, если на модуле отключить режим PSM, то устройство будет оставаться в режиме Active. Команда AT+CPSMS=0 (по крайней мере для neoway) как раз отключает PSM.

Под временем Active понимается время, в течение которого устройство остаётся доступно со стороны сети после процедур Attach, TAU или передачи данных, и определяется т.н. таймером "T3324 Active Timer", максимальный период - вроде как 3 часа и 6 минут. Но поведение устройства определяется не только T3324, но и другим таймером - "T3412 Periodic-TAU". Причем, если правильно понимаю, чтобы устройство переходило в PSM, T3412 должен быть больше, чем T3324, ибо длительность PSM - разница между T3412 и T3324. Без разницы, NB-IoT или eMTC (LTE-M).

А минимально возможное время Active - 0. Правда, в спецификации где-то сказано, что совсем в 0 его ставить не рекомендуется.

Сначала показалось, что вопрос - о максимальном времени)

Поправьте, если что не так.

 

 

Изменено 10 октября, 2018 пользователем wless.ru

[wless.ru 0]

Плюс, вероятно, настройки eDRX могут на поведение влиять...

[wless.ru 0]

В релизе 13 3GPP, TS 23.682, пункте 4.5.4 UE Power Saving Mode про минимальное время Active написано вот что:

Quote

NOTE 2:   The minimum recommended length for the Active Time is the time allowing for the 'msg waiting flag' in the MME/SGSN to trigger the SMSC via the HSS to deliver an SMS to the MME/SGSN, e.g. 2 DRX cycles plus 10 seconds.

...

An Active Time may be shorter than the time estimated for delivering a waiting SMS to the UE in NOTE 2 above, e.g. 0 seconds. If the MME/SGSN allocates such a shorter Active Time to the UE, the MME/SGSN (for signalling only connections and if the 'msg waiting flag' is set) and the RAN (for connections with RAB(s) set up) should be configured to keep the connection with the UE sufficiently long such that a waiting SMS can be delivered.

Эти же фразы сохранились и в релизе 16.

Возникает вопрос: а что если мне и не нужны входящие SMS, нам на них наплевать?

При этом ещё не факт, что сама сеть позволит использовать очень короткое Active Time, последнее слово - за операторскими настройками...

 

Изменено 10 октября, 2018 пользователем wless.ru

[prig 0]

On 10/10/2018 at 10:49 AM, wless.ru said:

Сначала показалось, что вопрос - о максимальном времени)

 

Ну, формулировка вопроса у меня иногда страдает...

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

[prig 0]

On 10/10/2018 at 11:58 AM, wless.ru said:

...Эти же фразы сохранились и в релизе 16.

Возникает вопрос: а что если мне и не нужны входящие SMS, нам на них наплевать?

При этом ещё не факт, что сама сеть позволит использовать очень короткое Active Time, последнее слово - за операторскими настройками...

 

 

А это уже совсем интересные моменты.

 

Впрочем, тема у меня успела слегка закиснуть. Заказчик думает. И по большей части не на предмет NB-IoT.

Но отслеживать эту тему стоит, имха. Я даже сознательно не стал её размещать в разделе сотовой связи, ч.б. не замылилась.

Короче, бу посмотреть, во что оно выльется.

И спасибо за участие. Если появится что-нить свеженькое, вываливайте.

[wless.ru 0]

1 hour ago, prig said:

Ну, формулировка вопроса у меня иногда страдает...

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

С формулировкой всё в порядке, моя вина. Но на всякий случай не стал стирать картинку с пояснениями - вдруг кому пригодится.

[wless.ru 0]

49 minutes ago, prig said:

А это уже совсем интересные моменты.

 

Впрочем, тема у меня успела слегка закиснуть. Заказчик думает. И по большей части не на предмет NB-IoT.

Но отслеживать эту тему стоит, имха. Я даже сознательно не стал её размещать в разделе сотовой связи, ч.б. не замылилась.

Короче, бу посмотреть, во что оно выльется.

И спасибо за участие. Если появится что-нить свеженькое, вываливайте.

Отслеживать - не помешает, это точно.

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

Quote

When the UE wants to use the PSM it shall request an Active Time value during every Attach and TAU/RAU procedures. If the network supports PSM and accepts that the UE uses PSM, the network confirms usage of PSM by allocating an Active Time value to the UE. The network takes the UE requested value, the Maximum Response Time (defined in clause 5.6.1.4), if provided with the Insert Subscriber Data message from HSS, and any local MME/SGSN configuration into account for determining the Active Time value that is allocated to the UE. If the UE wants to change the Active Time value, e.g. when the conditions are changed in the UE, the UE consequently requests the value it wants in the TAU/RAU procedure.

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