Действительно, такой вариант имеет право на жизнь. Можно предположить, что мошенники используют базу данных фиктивных e-mail, а невезунчикам приходят чеки лишь потому, что их адреса попали в эту базу случайно.
Но вопрос: зачем мошенникам указывать в чеках лишние, не обязательные данные? Не логично.
Спасибо за комментарий. Сам я таких цен давно не видел (я не оптовый покупатель). На всякий случай не стал указывать на продавца, чтобы не стать клеветником, если ошибаюсь.
Осталось выяснить, кто и зачем использовал мой e-mail для отправки чеков? Ещё момент: по основным кодам, чек в базе не находится. Только если включить расширенный поиск и ввести дату и время. Косвенно, это может быть признаком того, что продажа отменена и был возврат средств. Но, повторяю, я не знаю, как ЭДО работает на самом деле.
Помогите найти решение, не знаком с ассемблером x86.
Попробовал по аналогии включить виртуализацию в стареньком Packard Bell EasyNote BG48. После распаковки биоса утилитой MMTool_v3.12.exe:
ID модуля: 1B;
Single Link Arch BIOS;
ROM Location: 0002CBD0;
Run Location: Dynamic
Первое место, прямо сначала, 0x0001260E:
0001260D C3 ret
0001260E 66B93A000000 mov ecx,0x3a
00012614 0F32 rdmsr
00012616 A801 test al,0x1
00012618 752F jnz 0x2649
0001261A 6633C0 xor eax,eax
0001261D 6633D2 xor edx,edx
00012620 9A174E00F0 call 0xf000:0x4e17
00012625 7402 jz 0x2629
00012627 0C08 or al,0x8
00012629 24F9 and al,0xf9
0001262B 50 push ax
0001262C B8C414 mov ax,0x14c4
0001262F 9A887600F0 call 0xf000:0x7688
00012634 58 pop ax
00012635 740E jz 0x2645
00012637 26F6063F3D01 test byte [es:0x3d3f],0x1
0001263D 7406 jz 0x2645
0001263F A802 test al,0x2
00012641 7502 jnz 0x2645
00012643 0C04 or al,0x4
00012645 0C01 or al,0x1
00012647 0F30 wrmsr
00012649 C3 ret
Грубо говоря, на уровне медной проволоки, до демодулятора, подходы одинаковы.
Хочу убедиться, что вы понимаете, что никакой «цифровой обработки сигнала на близкой к гигагерцу частоте в реальном времени» в UNB-системах, равно как и в LoRa, не ведётся. Эта ваша формулировка недвусмысленно предполагает, что цифровая обработка сигнала ведётся на частоте выборки порядка 1ГГц. Это не соответствует действительности для практических реализаций ни UNB, ни LoRaWAN систем. И там, и там используются приёмники прямого преобразования и принцип нулевой промежуточной частоты, когда частота выборок сигнала, на которой ведётся цифровая обработка, лишь немного превышает ширину обрабатываемой полосы эфира. Поправьте, пожалуйста, в статье.
По полосе эфира малой БС попробую спросить у Стрижа. Если полоса уже, то под эту БС нужен отдельная серия («батч») модемов прошитых на конкретную частоту. Что не отменяет совместимости этих модемов с «большой» БС.
Касательно обратного канала Стрижа. При проверке БС я не увидел в полосе 868МГц передачи от БС, но обратный канал при этом срабатывал. Впрочем, я мог принять сигнал БС за часть ответа модема, который даётся после получения сообщения от БС. Ещё, антенна обратного канала отдельная. Из поставки Стрижа — диполь. И мне она показалась великоватой для 868МГц. Так что мне пока совсем непонятно, на какой частоте и с какой модуляцией реализован обратный канал.
Почитайте что-нибудь на досуге. Потом ответьте сами себе на вопрос, надо ли вообще оцифровывать несущую или куда-либо её переносить в LoRa.
Почитал. В статье "Возможности использования радиотрансиверов компании Semtech" картинка (с моими пометками):
Стандартная схема. Во всех ВЧ радиоинтерфейсах стараются сразу перенести полосу сигнала на нижние частоты при помощи простых квадратурных смесителей. В на картинке после смесителя АЦП с передискретизацией, поэтому частота работы модуляторов дельта-сигма АЦП больше итоговой частоты дискретизации полосы сигнала. Дальше дециматор/ФНЧ. На демодулятор отсчёты квадратурных составляющих сигнала поступают уже с частотой дискретизации лишь чуть больше полосы принимаемого сигнала. И это даже не десятки МГц, а в лучшем случае единицы МГц.
То же самое и у UNB Стрижа. АЦП и ЦОС работают с частотами дискретизации порядка 200кГц-500кГц, не более. Поэтому меня покоробило ваше утверждение, что нужно производить обработку сигнала на гигагерце в реальном времени. Оно, по моему, не соответствует действительности.
Вообще удивительно, как вы игнорируете физический уровень, который у LoRa и Стрижа тупо разный.
Разный он только с точки зрения модуляции и протокола. На уровне радиочастотной части (до АЦП включительно) принципиальных отличий нет. Так же при оптимальном приёме — с точки зрения радиочастотного ресурса и соотношения энергий все способы передачи равноценны. Вопрос лишь в том, насколько оптимальный приём удаётся организовать.
Мне она кажется простой, потому что я немного знаю схему модуляции LoRa, а также держу в руках крошечный копеечный чип, способный эту модуляцию демодулировать. А не Jetson TK1 с NVIDIA CUDA, которому вентилятор нужен, чтобы он от натуги не сдох (кстати, интересно, как оно будет работать в необслуживаемом варианте зимой на крыше дома, кхм).
И этот крошечный чип может одновременно декодировать сотни сигналов модемов?
Конечно, в нормальных условиях за счёт работы ближних LoRaWAN модемов на высоких скоростях, у вашего копеечного чипа хватит ресурсов на много пользователей. На большой скорости модемы быстрее «отстерляются» в эфир, чем UNB. Но количество одновременно декодируемых каналов меньше, чем у UNB BS с мощным DSP. На больших площадях покрытия с низкими SF уже вопрос, какая БС окажется эффективнее.
Насколько мне известно, уже доступны маленькие БС Стриж как наружного исполнения, так и для помещений. Наверняка они имеют меньшую производительность и ёмкость, чем большие БС на CUDA. И меньшую стоимость.
Ну то есть CUDA и отсутствие полноценной обратной связи вы считаете низкой ценой?
Вопрос в применении. Для БС операторского класса на большую площадь покрытия, с учётом того, что модемы UNB пока дешевле, узкополосная система может быть выгодна. Кроме того, вопрос обратного канала (на LoRaWAN или на 433МГц — я ещё не разобрался) у Стрижа решён — держал в руках и тестировал оборудование, на котором нисходящий канал работает. Для применения уровня ТСЖ — да, LoRaWAN интересное решение, может быть собрано «на коленках». С другой стороны, у Стрижа уже есть маленькие БС. Так что это уже вопрос предпочтений: ценит ли заказчик открытость решений и возможнотсь выбора поставщиков радиомодулей и сильно ли ему нужно создавать свою независимую сеть?
В антенну прилетел почти гигагерц — соответственно, этот почти гигагерц таки надо как минимум оцифровать. С хорошим частотным и временным разрешением.
Не нужно оцифровывать гигагерц. Используем прямой перенос спектра (естественно, с хорошим временным разрешением) и АЦП с частотой дискретизации чуть выше, чем желаемая полоса эфира. То есть, после переноса спектра, который не слишком сложен, используются обычные, чуть ли не аудио АЦП. Не нужен «рилтайм» на ГГц. Достаточно квадратурного смесителя с контролируемым джиттером.
На выходе квадратурные составляющие, из которых восстанавливается целый спектр шириной плюс-минус частота дискретизации от 1/4 частоты опорного генератора. Для субгигагерца немногим сложнее, чем на рисунке. Или в LoRa не так делается? Они гигагерц напрямую оцифровывают? Вряд ли.
Не порите чушь, ей больно. В LoRa задача найти в 500 кГц эфира, где именно тут только что квакнул передатчик с полосой 100 Гц, вообще не стоит.
Угу. Задача декодирования широкополосного сигнала много проще, по-вашему. ПМСМ, обработку успешно упаковали в чип, поэтому она вам кажется такой простой.
Про стабильность частоты: не можешь побороть? Возглавь! Весма действенный принцип. Нет смысла достигать стабильности высокой ценой (стоимость и потребление TXCO) в то время как вероятность коллизй с потерей данных невысока даже при активности сотни нескоординированных модемов в полосе ~200кГц.
Да, можете отметить в табличке. Из открытых материалов Стрижа, используемая модуляция — DBPSK. Относительная двоичная фазовая манипуляция.
…оцифровка и последующий спектральный анализ широкого диапазона радиоэфира (десятки-сотни килогерц) в реальном времени… Такая система действительно позволяет принимать большое число абонентских устройств одновременно, но это — цифровая обработка сигнала на близкой к гигагерцу частоте в реальном времени, то есть, тяжелая вычислительная задача, требующая от БС весьма серьёзных ресурсов.
Ниже:
Как мы увидели выше, для эффективной работы БС должна делать спектральный анализ принимаемого широкополосного сигнала в реальном времени, выделяя из него узкополосные сигналы отдельных абонентов. Слова «в реальном времени» имеют здесь вполне конкретный количественный смысл: частота вычисления БПФ — это частота дискретизации сигналов абонентов. Поэтому любая попытка серьёзно увеличить скорость связи с абонентами в UNB-системе требует столь же серьёзного увеличения производительности системы цифровой обработки сигнала. А при том, что мы говорим о ЦОС с исходной частотой почти в гигагерц — приятного в таком требовании мало..
Ну вы и загнули — обработка гигагераца в реальном времени! Обработка ведётся не на гигагерце, а, всего лишь, на сотнях кГц. Не слишком широкая полоса спектра под телеметрию целиком переносится, можно сказать, на низкие частоты — квадратурные составляющие с дискретизацией порядка 200кГц. Не бог весть какая скорость. Хотя да, для реализации приёма, близкого к оптимальному, вычислений много — Стриж пишет, что NVIDIA CUDA применяет в «больших» БС. Вы пишите так, будто бы с точки зрения обработки LoRa нужно меньше ресурсов. Если обработка и там, и там оптимальна, то необходимая производительность определяется лишь количеством информации, которое необходимо получить. Для полноценной LoRaWAN полоса обрабатываемого эфира ещё шире, поэтому «рилтаймовость» даже больше. Просто до поры до времени она от вас спрятана в относительно скромном чипе.
Одна из серьёзных технических проблем UNB-систем — нестабильность частоты кварцевых резонаторов, задающих рабочую частоту абонентского устройства. Типовой хороший кварц имеет суммарную погрешность ±25 ppm, то есть при частоте несущей 869 МГц реальное отклонение от неё может достигать 21,725 кГц.
3. При уходе частоты на 30 % от ширины полосы (т.е. в стандартном случае — на 37,5 кГц) будет 10 % ошибок в принятых пакетах. С потерями ничего не делать — изначально проектировать систему так, чтобы они были приемлемыми; для LoRa в этом нет принципиальных сложностей — на абонентское устройство ставится кварц с ±10±15 ppm, на БС — TCXO, там лишний доллар стоимости роли не играет.
Выходит, проблема со стабильностью частоты стоит и перед LoRaWAN. Как я вижу по водопаду спектра передатчиков UNB Стрижа, они наплевали на нестабильность частот передатчиков в аплинке, передавая сообщение с одного модема последовательно на двух разных частотах. Не замерял, возможно, со случайным сдвигом между передачами. Так что побоку повышенная точность кварцев — можно использовать дешёвые. Доллар в пользу UNB.
Если на стороне БС для UNB удастся реализовать оптимальное декодирование DBPSK с избыточностью, то не исключаю возможности успешного декодирования сообщений даже при их взаимном наложении в эфире. Если взаимные помехи модемов не мультипликативны и сообщения не когерентны, то сигнал-шум упадёт, но возможнось расшифровки не пропадет полностью. В общем, чем ближе методы приёма к оптимальным, тем размытее граница между широкополосными и узкополосными модуляциями. Остаются лишь соотношения энергий сигнала и шума за время и в полосе сообщения. И мне нравится фундаментальное преимущество узкой полосы — низкая энергия посторонних шумов эфира и приёмного тракта в полосе сигнала.
В защиту LoRaWAN скажу, что сеть будет внедряться и работать повсеместно. Протоколы взаимодействия хорошие, гибкие. Все проблемы решаются спросом. Будет спрос — буду БС стоять хоть в каждом квартале, каждом дворе — пикосоты. Проблемы ёмкости отпадают с увеличением количества малых БС.
Он не застал :)))
Участие жертвы лишь в том, что был указан её e-mail. Сложно будет доказать, что жертва вдруг купила яблок за 1000км от дома.
Я о том, что там, в чеке, адрес магазина, адрес сайта и, в каждой позиции по чеку, телефон поставщика. Зачем всё это?
Прошу прощения, промахнулся кнопкой и "не одобрил" чей-то развёрнутый и по делу комментарий. Извините, нечаянно.
Спасибо. Тоже версия. Но я никогда не получал скидок от овощной конторы...
Действительно, такой вариант имеет право на жизнь. Можно предположить, что мошенники используют базу данных фиктивных e-mail, а невезунчикам приходят чеки лишь потому, что их адреса попали в эту базу случайно.
Но вопрос: зачем мошенникам указывать в чеках лишние, не обязательные данные? Не логично.
Спасибо за комментарий. Сам я таких цен давно не видел (я не оптовый покупатель). На всякий случай не стал указывать на продавца, чтобы не стать клеветником, если ошибаюсь.
Осталось выяснить, кто и зачем использовал мой e-mail для отправки чеков? Ещё момент: по основным кодам, чек в базе не находится. Только если включить расширенный поиск и ввести дату и время. Косвенно, это может быть признаком того, что продажа отменена и был возврат средств. Но, повторяю, я не знаю, как ЭДО работает на самом деле.
Попробовал по аналогии включить виртуализацию в стареньком Packard Bell EasyNote BG48. После распаковки биоса утилитой MMTool_v3.12.exe:
Первое место, прямо сначала, 0x0001260E:
0001260D C3 ret0001260E 66B93A000000 mov ecx,0x3a
00012614 0F32 rdmsr
00012616 A801 test al,0x1
00012618 752F jnz 0x2649
0001261A 6633C0 xor eax,eax
0001261D 6633D2 xor edx,edx
00012620 9A174E00F0 call 0xf000:0x4e17
00012625 7402 jz 0x2629
00012627 0C08 or al,0x8
00012629 24F9 and al,0xf9
0001262B 50 push ax
0001262C B8C414 mov ax,0x14c4
0001262F 9A887600F0 call 0xf000:0x7688
00012634 58 pop ax
00012635 740E jz 0x2645
00012637 26F6063F3D01 test byte [es:0x3d3f],0x1
0001263D 7406 jz 0x2645
0001263F A802 test al,0x2
00012641 7502 jnz 0x2645
00012643 0C04 or al,0x4
00012645 0C01 or al,0x1
00012647 0F30 wrmsr
00012649 C3 ret
Второе место 0x00038AF3:
00038AD1 C3 ret00038AD2 7505 jnz 0x8ad9
00038AD4 EAA916E551 jmp 0x51e5:0x16a9
00038AD9 1E push ds
00038ADA 56 push si
00038ADB 6800F0 push word 0xf000
00038ADE 1F pop ds
00038ADF F6063F3D01 test byte [0x3d3f],0x1
00038AE4 74D0 jz 0x8ab6
00038AE6 E813C3 call 0x4dfc
00038AE9 B8C414 mov ax,0x14c4
00038AEC 9A99330040 call 0x4000:0x3399
00038AF1 8BF8 mov di,ax
00038AF3 66B93A000000 mov ecx,0x3a
00038AF9 0F32 rdmsr
00038AFB A801 test al,0x1
00038AFD 74AB jz 0x8aaa
00038AFF 33C9 xor cx,cx
00038B01 A806 test al,0x6
00038B03 7401 jz 0x8b06
00038B05 41 inc cx
00038B06 33C0 xor ax,ax
00038B08 3BCF cmp cx,di
00038B0A 7401 jz 0x8b0d
00038B0C 40 inc ax
00038B0D 9A3D8300F0 call 0xf000:0x833d
00038B12 7396 jnc 0x8aaa
00038B14 8BD9 mov bx,cx
00038B16 B8C414 mov ax,0x14c4
00038B19 9AA8330040 call 0x4000:0x33a8
00038B1E B403 mov ah,0x3
00038B20 EB8A jmp short 0x8aac
00038B22 B8E153 mov ax,0x53e1
00038B25 EB3B jmp short 0x8b62
00038B27 B8053F mov ax,0x3f05
00038B2A 8BD8 mov bx,ax
00038B2C 8AC7 mov al,bh
00038B2E C0E804 shr al,byte 0x4
00038B31 E82100 call 0x8b55
00038B34 8AC7 mov al,bh
00038B36 E81C00 call 0x8b55
00038B39 6726C6072E mov byte [es:edi],0x2e
00038B3E 6647 inc edi
00038B40 8AC3 mov al,bl
00038B42 C0E804 shr al,byte 0x4
00038B45 E80D00 call 0x8b55
00038B48 8AC3 mov al,bl
00038B4A E80800 call 0x8b55
00038B4D 6726C60700 mov byte [es:edi],0x0
00038B52 6647 inc edi
00038B54 C3 ret
Спасибо!
Хочу убедиться, что вы понимаете, что никакой «цифровой обработки сигнала на близкой к гигагерцу частоте в реальном времени» в UNB-системах, равно как и в LoRa, не ведётся. Эта ваша формулировка недвусмысленно предполагает, что цифровая обработка сигнала ведётся на частоте выборки порядка 1ГГц. Это не соответствует действительности для практических реализаций ни UNB, ни LoRaWAN систем. И там, и там используются приёмники прямого преобразования и принцип нулевой промежуточной частоты, когда частота выборок сигнала, на которой ведётся цифровая обработка, лишь немного превышает ширину обрабатываемой полосы эфира. Поправьте, пожалуйста, в статье.
По полосе эфира малой БС попробую спросить у Стрижа. Если полоса уже, то под эту БС нужен отдельная серия («батч») модемов прошитых на конкретную частоту. Что не отменяет совместимости этих модемов с «большой» БС.
Касательно обратного канала Стрижа. При проверке БС я не увидел в полосе 868МГц передачи от БС, но обратный канал при этом срабатывал. Впрочем, я мог принять сигнал БС за часть ответа модема, который даётся после получения сообщения от БС. Ещё, антенна обратного канала отдельная. Из поставки Стрижа — диполь. И мне она показалась великоватой для 868МГц. Так что мне пока совсем непонятно, на какой частоте и с какой модуляцией реализован обратный канал.
Почитал. В статье "Возможности использования радиотрансиверов компании Semtech" картинка (с моими пометками):
Стандартная схема. Во всех ВЧ радиоинтерфейсах стараются сразу перенести полосу сигнала на нижние частоты при помощи простых квадратурных смесителей. В на картинке после смесителя АЦП с передискретизацией, поэтому частота работы модуляторов дельта-сигма АЦП больше итоговой частоты дискретизации полосы сигнала. Дальше дециматор/ФНЧ. На демодулятор отсчёты квадратурных составляющих сигнала поступают уже с частотой дискретизации лишь чуть больше полосы принимаемого сигнала. И это даже не десятки МГц, а в лучшем случае единицы МГц.
То же самое и у UNB Стрижа. АЦП и ЦОС работают с частотами дискретизации порядка 200кГц-500кГц, не более. Поэтому меня покоробило ваше утверждение, что нужно производить обработку сигнала на гигагерце в реальном времени. Оно, по моему, не соответствует действительности.
Разный он только с точки зрения модуляции и протокола. На уровне радиочастотной части (до АЦП включительно) принципиальных отличий нет. Так же при оптимальном приёме — с точки зрения радиочастотного ресурса и соотношения энергий все способы передачи равноценны. Вопрос лишь в том, насколько оптимальный приём удаётся организовать.
И этот крошечный чип может одновременно декодировать сотни сигналов модемов?
Конечно, в нормальных условиях за счёт работы ближних LoRaWAN модемов на высоких скоростях, у вашего копеечного чипа хватит ресурсов на много пользователей. На большой скорости модемы быстрее «отстерляются» в эфир, чем UNB. Но количество одновременно декодируемых каналов меньше, чем у UNB BS с мощным DSP. На больших площадях покрытия с низкими SF уже вопрос, какая БС окажется эффективнее.
Насколько мне известно, уже доступны маленькие БС Стриж как наружного исполнения, так и для помещений. Наверняка они имеют меньшую производительность и ёмкость, чем большие БС на CUDA. И меньшую стоимость.
Вопрос в применении. Для БС операторского класса на большую площадь покрытия, с учётом того, что модемы UNB пока дешевле, узкополосная система может быть выгодна. Кроме того, вопрос обратного канала (на LoRaWAN или на 433МГц — я ещё не разобрался) у Стрижа решён — держал в руках и тестировал оборудование, на котором нисходящий канал работает. Для применения уровня ТСЖ — да, LoRaWAN интересное решение, может быть собрано «на коленках». С другой стороны, у Стрижа уже есть маленькие БС. Так что это уже вопрос предпочтений: ценит ли заказчик открытость решений и возможнотсь выбора поставщиков радиомодулей и сильно ли ему нужно создавать свою независимую сеть?
Не нужно оцифровывать гигагерц. Используем прямой перенос спектра (естественно, с хорошим временным разрешением) и АЦП с частотой дискретизации чуть выше, чем желаемая полоса эфира. То есть, после переноса спектра, который не слишком сложен, используются обычные, чуть ли не аудио АЦП. Не нужен «рилтайм» на ГГц. Достаточно квадратурного смесителя с контролируемым джиттером.
На выходе квадратурные составляющие, из которых восстанавливается целый спектр шириной плюс-минус частота дискретизации от 1/4 частоты опорного генератора. Для субгигагерца немногим сложнее, чем на рисунке. Или в LoRa не так делается? Они гигагерц напрямую оцифровывают? Вряд ли.
Угу. Задача декодирования широкополосного сигнала много проще, по-вашему. ПМСМ, обработку успешно упаковали в чип, поэтому она вам кажется такой простой.
Про стабильность частоты: не можешь побороть? Возглавь! Весма действенный принцип. Нет смысла достигать стабильности высокой ценой (стоимость и потребление TXCO) в то время как вероятность коллизй с потерей данных невысока даже при активности сотни нескоординированных модемов в полосе ~200кГц.
Да, можете отметить в табличке. Из открытых материалов Стрижа, используемая модуляция — DBPSK. Относительная двоичная фазовая манипуляция.
Ниже:
Ну вы и загнули — обработка гигагераца в реальном времени! Обработка ведётся не на гигагерце, а, всего лишь, на сотнях кГц. Не слишком широкая полоса спектра под телеметрию целиком переносится, можно сказать, на низкие частоты — квадратурные составляющие с дискретизацией порядка 200кГц. Не бог весть какая скорость. Хотя да, для реализации приёма, близкого к оптимальному, вычислений много — Стриж пишет, что NVIDIA CUDA применяет в «больших» БС. Вы пишите так, будто бы с точки зрения обработки LoRa нужно меньше ресурсов. Если обработка и там, и там оптимальна, то необходимая производительность определяется лишь количеством информации, которое необходимо получить. Для полноценной LoRaWAN полоса обрабатываемого эфира ещё шире, поэтому «рилтаймовость» даже больше. Просто до поры до времени она от вас спрятана в относительно скромном чипе.
olartamonov, а здесь вы пишите:
И ниже в комментариях:
Выходит, проблема со стабильностью частоты стоит и перед LoRaWAN. Как я вижу по водопаду спектра передатчиков UNB Стрижа, они наплевали на нестабильность частот передатчиков в аплинке, передавая сообщение с одного модема последовательно на двух разных частотах. Не замерял, возможно, со случайным сдвигом между передачами. Так что побоку повышенная точность кварцев — можно использовать дешёвые. Доллар в пользу UNB.
Если на стороне БС для UNB удастся реализовать оптимальное декодирование DBPSK с избыточностью, то не исключаю возможности успешного декодирования сообщений даже при их взаимном наложении в эфире. Если взаимные помехи модемов не мультипликативны и сообщения не когерентны, то сигнал-шум упадёт, но возможнось расшифровки не пропадет полностью. В общем, чем ближе методы приёма к оптимальным, тем размытее граница между широкополосными и узкополосными модуляциями. Остаются лишь соотношения энергий сигнала и шума за время и в полосе сообщения. И мне нравится фундаментальное преимущество узкой полосы — низкая энергия посторонних шумов эфира и приёмного тракта в полосе сигнала.
В защиту LoRaWAN скажу, что сеть будет внедряться и работать повсеместно. Протоколы взаимодействия хорошие, гибкие. Все проблемы решаются спросом. Будет спрос — буду БС стоять хоть в каждом квартале, каждом дворе — пикосоты. Проблемы ёмкости отпадают с увеличением количества малых БС.