cpu6-2 OXE 8.0.1, dect развернут на платах ua32

воспользовался поиском по синхронизации dect, нашел что надо поставить DTM синхро yes, но это относится к системам RBS или этот парамерт тоже относится с IBS?

ibs синхронизируется как-нибудь???

В 8-м релизе была хохма - если выбирается DECT IBS, то исчезает пункт RBS где указывается синхронизация (номер шелфа где стоит CPU6 например).
Рекомендую в этом случае указать тип декта- смешанный, и в разделе RBS указать DTM synchro=yes и shelf=0.
Команда infocs в этом случае покажет в том числе и синхронизацию дект.

тоже думал об миксе.
спасибо

18-го числа прописал микс, в разделе RBS указал DTM synchro=yes на shelf=0

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

смотрел инциденты на наличие ухода в аутсерсис баз - нет

Вернуть можно взад, но начинать следует с infocs - от чего синхронизируется собственно станция и DECT, может проблема с внешним подключением? Ведь неделю работало.

и месяца не прошло как dect 4 раза на ibs обваливался, лечилось путем выдергиванием плат ua32

прописка микс и указанием в разделе RBS указал DTM synchro=yes на shelf=0 не помогает

что-то уж тяжолый релиз 8

RBS включаются через плату контроллера которая смотрит в кристал 30-ю каналами. Подозреваю, что это что-то типа потока Е1, поэтому синхронизация наверно относится к этому элементу, чего на цифровой плате естественно нет.

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

Что значит дект отвалился? - вышли из зоны, трубка потеряла связь с базой? Если при выключении и включении трубки она находит базу, а при выходе из зоны и вновь возвращение в зону не может найти базу, то в принципе это нормальное явление. В этом случае регистрация трубки в системе происходит длительное время (до 20 мин),почему это происходит - затрудняюсь сказать. Этот эффект я наблюдал на MD110 Ericsson. Понятно что при этом абонент "Бьется в истерике".

в одном кабинете 4 абонента декта, на 3-х сразу потеря базы пройдет через минуту другую все нормализуется (по этажам здания хоатично такое происходит бывает что 2-3 этажа на 2-3 минуты пропадает дект), а 4-ой уровень сигнала падает но не теряется, часто бывает что связка тандема цифровой терминал с дектом просто не работает т.е. звонит цифровой терминал а отзвон на дект не идет
когда вышел из зоны и обратно зашел трубка подхватывается на ура (как выставили правильно синхру такой проблемы не наблюдалось что надо выключать трубку и включать заново)

физику от плат до баз проверяли

Переключи трубку в тестовый режим и пройди по территории, посмотри перекрываются ли зоны БС, сколько баз видит трубка?
На Цифровых платах (покрайней мере для ОХО) нечетные порты подключаются как мастер БС, а четные как слуга - может здесь нестыковка? Порядок подключения БС на порты лучше с последних. Пробуй.



Редактировано 2 раз. Последний раз 31.10.2008 19:26 пользователем TMC.

спасибо
будем пробывать

Вернусь к тому, что говорил в начале - что рисует команда infocs - пожалуйста продемонстируйте.
А так же - есть ли инциденты на тему DECT и/или синхронизации, пропадании потоков и т.п..
Особенно все будет забавно если внешнее подключение - базовый доступ ISDN.

(102)xa000000> infocs

Tue Dec 2 11:41:23 MSK 2008


+----------------------------------------------------------------------+
| N_CR | N_CPL | TYPE | N_ACCES | PRIO | SYNC_CLOCK | TG/LK |
+----------------------------------------------------------------------+
| 0 | 17 | PRA2 | 0 | 0 | SYNCHRO | TG:10 |
+----------------------------------------------------------------------+

+---------------------------------------------------------------------+
| Synchronization on global domain |
+---------------------------------------------------------------------+


+========================== Synchro DECT ==================================+

+--------------------------------------------------------------------------+
| N_CR | N_CPL | TYPE | DECT_CLOCK | Depending Crystals |
+--------------------------------------------------------------------------+
| 0 | 6 | CPU6 | DTM PRESENT | |
| 0 | 20 | CPU6 | DTM SYNCHRO | |
+--------------------------------------------------------------------------+


+========= campus synchronization via INTOFS ====================+

this node 2 is SLAVE of campus synchronization (master node = ?)
synchro = PHASE_NO_OPERATION (phase shift values = 0,0)
info1=0 info2=0 info3=0 info4=0


(102)xa000000>


в основном вылазиют такие инциденты, пропадании синхру инциндентов не нашел, бывает изредка только это "20/10/08 07:35:12 001002M|000/02/0/031|=3:4101=Maximum number of trunks on an acces 0-17-0 is overflown" т.е. переполнения каналов на pri

31/10/08 15:07:25 001002M|---/--/-/---|=3:1376=DECT Action requested by handset 1981 rejected
31/10/08 16:04:12 001002M|---/--/-/---|=4:1387=Inconsistent DECT table : lce_t_adm_lcei[298]
01/11/08 13:22:48 001002M|---/--/-/---|=3:1376=DECT Action requested by handset 1952 rejected
26/11/08 11:55:26 001002M|000/16/0/018|=5:3958=IBS operational



этот фрагмент взять полность без всяких вырезаний строк, замечено когда выдазиет индицент "3958=IBS operational" происходит обвал декта

26/11/08 02:57:06 001002M|---/--/-/---|=2:1288=4635 : general error 0001:0064 a 00000000
26/11/08 03:58:13 001002M|---/--/-/---|=2:1288=4635 : general error 0003:0064 a 00000000
26/11/08 11:55:26 001002M|000/16/0/018|=5:3958=IBS operational
26/11/08 13:37:28 001002M|---/--/-/---|=3:1376=DECT Action requested by handset 1944 rejected
26/11/08 14:54:05 001002M|000/14/0/019|=3:4101=Maximum number of trunks on an acces 0-17-0 is overflown
26/11/08 15:26:15 001002M|---/--/-/---|=3:1376=DECT Action requested by handset 1633 rejected
26/11/08 17:23:59 001002M|---/--/-/---|=4:0274=DTMF receiver release error
26/11/08 22:14:39 001002M|---/--/-/---|=2:1288=4635 : general error 0001:0064 a 00000000
27/11/08 01:01:23 001002M|---/--/-/---|=2:1288=4635 : general error 0003:0064 a 00000000

еще попутный вопрос появился - из каких идеалогий атс сама начинает формировать в одну ibs группу по несколько rpn, причем rpn группируется не подрят а как-то своебразно. после инициализации prn было в каждой группе по одному rpn, минут через 20 глянул и опять в одной группе по несколько rpn

в атс прописано 1 area 256 base

в начале декабря подняли софт на атс до G1.503.17b и в общем думали что эту проблемму победили но спустя 2 недели опять началось тоже самое

у меня такое ощущение что установка нового пачта или же перегрузить атс полность то вся проблемма дектом пропадет на 2 недели (этот промежуток времени равный 2-м неделям всплывает уже третий раз и как говорится фразе из книги "запад эдема" один рас это случайность, два раза это совпадение, три раза это закономерность)

вопрос к участникам форума - кто-нибудь поднимал IBS на релизе 8.0.1 и как он ведет себя?

Подняты IBS на 6.2.

А с Antenna Divercity не пробовали поиграть?