Cell Reselection, C1, C2, CRO

Сообщение **Lev** » Пт, 31-03-2006, 14:52

DMaster писал(а): 2 Lev: собственно, вот и причина, по которой у тебя в разные моменты времени в логах получаются разные CRO, на что анализатор ругается нехорошими словами типа repeated change. Надо просто всегда брать последнее значение.

Нет, это не то. У меня в логе CRO считается только для текущей соты, а там он уже (почти?) всегда без offset. Исключения, которые я видел (по 1 разу за несколько месяцев записи логов):
- С2=+100, что Сименс показал как +00

- запись лога параллельно с разговором: прошел хэндовер (у которого, как известно, свои критерии) на ранее не виденную в соседях соту, я положил трубку и получил по ней некорректное C2

А repeated change чаще всего возникает в случае, когда параметры канала считываются постепенно: поймали BCCH - изменили в базе, уточнили BSIC - тоже, стали известны RXAM и CRO - изменили и их.

Waveman · Сообщение **Waveman** » Пт, 31-03-2006, 14:57

Резонный вопрос.... нет это параметры не соседей.... я думаю в BCCH-Information мы получаем все temporary_offset и penalty_time соседних ячеек. И как только C2(NCELL)>C2(SERV) начинаем отсчитывать Penalty time, понижая при этом C2(NCELL) на величину temporary_offset. Если в течение этого усливие уже не выполняется MS сбрасывает счетчик. Вроде так должно быть.... надо будет в документации порыться (BSS кстати Motorola). Может у других нет такой фичи

Сообщение **Lev** » Пт, 31-03-2006, 15:18

По-моему, все-таки penalty time начинает считаться прямо с момента считывания BCCH, а не по достижении каких-то условий.

ash · Сообщение **ash** » Сб, 01-04-2006, 07:25

В нет мониторе Нокии замечена такая вещь , что если параметр С2 соседа устанавливается в -99 или -100 в зависимости от модели то хэндовер на эту частоту не возможен даже если уровень будет на много больше уровня той частоты на которой сидит телефон.
Инетересно с чем это связано?

Сб, 01-04-2006, 09:42

ash писал(а):Инетересно с чем это связано?

С тем, что критерии выбора канала не имеют никакого отношения к хендоверам!..

Waveman · Сообщение **Waveman** » Сб, 01-04-2006, 09:44

ash писал(а):В нет мониторе Нокии замечена такая вещь , что если параметр С2 соседа устанавливается в -99 или -100 в зависимости от модели то хэндовер на эту частоту не возможен даже если уровень будет на много больше уровня той частоты на которой сидит телефон.
Инетересно с чем это связано?

Я думаю, что это значит, что C2 для этого соседа не вычислен, или что у него неверный BSIC

ash · Сообщение **ash** » Сб, 01-04-2006, 11:18

Алексей Березин писал(а):
ash писал(а):Инетересно с чем это связано?
С тем, что критерии выбора канала не имеют никакого отношения к хендоверам!..

это я знаю ,но если это происходит то хэндовера не будет в 100% случаев!

Сб, 01-04-2006, 16:54

ash писал(а):если это происходит то хэндовера не будет в 100% случаев!

Точно! Не сообразил сразу.

У Нокии такое наблюдается и с С1...

Fisky · Сообщение **Fisky** » Пн, 03-04-2006, 13:56

В Москве у Мегафона очень часто встречается Рenalty Time =20 на сотах через одну! Создается впечатление, что хотят минимизировать СR или еще чего?

У Билайна в метро появился C1=10 на 900 частотах с RXAM= -111
Хотят чтобы телефон держался до последнего? Критерии по RXAM и по С2 выкинут теелфон с сектора одновременно. Зачем тогда?

Сообщение Vl » Пн, 03-04-2006, 15:23

Fisky писал(а):В Москве у Мегафона очень часто встречается Рenalty Time =20 на сотах через одну!

20 - это в каких единицах? Точнее, чему равна единица PT?

Сообщение **DMaster** » Пн, 03-04-2006, 15:33

Кстати, а где в FTD можно увидеть значение ТО? Где значение PT - уже нашел.
Интересно, что FTD показал PT = 620 на одной из 900-ок МТСа, светящих на меня дома.

Печёночный-Сосальщикъ · Вт, 04-04-2006, 11:29

Fisky писал(а): У Билайна в метро появился C1=10

Всё-таки С1 или CRO?

Fisky писал(а): на 900 частотах с RXAM= -111
Хотят чтобы телефон держался до последнего? Критерии по RXAM и по С2 выкинут телефон с сектора одновременно. Зачем тогда?

Хорошо бы ещё знать про RXAM и CRO на наземных 900/1800. В Питере, например, вначале CRO в метро был равен нулю, а на наземных 1800 CRO = +20, в результате при спуске вниз телефон до одурения сидел на наружном секторе, при том, что подземный светил вовсю. Потом в метро CRO подняли до +20, что обеспечило приоритет подземным каналам против наземных 1800 (RXAM = -111 против -105 у наземных DCS). Это малость перекосило ситуацию в обратную сторону: телефон долго продолжал висеть на подземных секторах. Недавно я краем глаза заметил, что вроде бы CRO на метрошных секторах снизили до где-то в районе +15. А вообще-то это делается имхо для балансировки загрузки наружных и подземных секторов.

Fisky · Сообщение **Fisky** » Вт, 04-04-2006, 11:53

Печёночный-Сосальщикъ писал(а):Всё-таки С1 или CRO?

Конечно CRO:-)

Хорошо бы ещё знать про RXAM и CRO на наземных 900/1800. В Питере, например, вначале CRO в метро был равен нулю, а на наземных 1800 CRO = +20, в результате при спуске вниз телефон до одурения сидел на наружном секторе, при том, что подземный светил вовсю.

А что на 1800 секторах был RXAM -111?

20 - это в каких единицах? Точнее, чему равна единица PT?

В секундах, я так понимаю.

Eug · Сообщение **Eug** » Вт, 04-04-2006, 15:32

Данная функция чаще всего используется для того чтобы быстро движущиеся объекты не регистрировались в микросотах. Фича для idle mode. К примеру выполняется условие выбора/перевыбора соты, в этом случае запускается таймер PT. На время этого таймера С2=С1 + CRO - TO, причём TO > CRO. Соответственно С2 становится меньше С1. Таким образом на время PT микросота становится непривлекательной. Это делается для того чтобы быстродвижущиеся объекты (те которые успели проехать микросоту за время PT) не выбирали микросоту. Если условие выбора/перевыбора соты по прежнему выполняется по истечении таймера PT, то микросота становится привлекательной. Т.е. С2=С1+CRO. Таким образом к примеру можно отличать движение автомобиля и пешехода вдоль оживлённой дороги. Для того чтобы не ухудшить качество загоняя абонентов в микросоты параметром CRO, используется RXLEVAMI (Minimum received level) который задаёт минимальный уровень регистрации. Таким образом если к примеру извесно что микросота нормально работает с уровнем не хуже чем -100dbm, то в микросоту можно загнать абонентов (с помощью CRO) только имеющих уровень больше чем -100 указав параметр RXLEVAMI=11 (рассчитывается: -111+RXLEVAMI).

Fisky · Сообщение **Fisky** » Вт, 04-04-2006, 15:47

Eug писал(а):Данная функция чаще всего используется для того чтобы быстро движущиеся объекты не регистрировались в микросотах. Фича для idle mode. К примеру выполняется условие выбора/перевыбора соты, в этом случае запускается таймер PT. На время этого таймера С2=С1 + CRO - TO, причём TO > CRO. Соответственно С2 становится меньше С1. Таким образом на время PT микросота становится непривлекательной. Это делается для того чтобы быстродвижущиеся объекты (те которые успели проехать микросоту за время PT) не выбирали микросоту.).

С этом все ясно. Но не может же весь город делиться поровну между сотами и микросотами???

Eug писал(а):Для того чтобы не ухудшить качество загоняя абонентов в микросоты параметром CRO, используется RXLEVAMI (Minimum received level) который задаёт минимальный уровень регистрации. Таким образом если к примеру извесно что микросота нормально работает с уровнем не хуже чем -100dbm, то в микросоту можно загнать абонентов (с помощью CRO) только имеющих уровень больше чем -100 указав параметр RXLEVAMI=11 (рассчитывается: -111+RXLEVAMI).

Ой, я только слышал об RXAM, это не тоже самое? RXLEVAMI=11?

NetMonitor.Ru Forum

Cell Reselection, C1, C2, CRO — Общие вопросы, касающиеся принципов работы GSM-сетей