Добрый день!

Уважаемые коллеги, хочу обратиться к вам вот с каким вопросом.

У клиента поставили 3х кабинетную 11 опцию, рел.4.5.
Первый кабинет расширения (слоты с 11 по 20) подключен к главному как Fiber Expansion Cabinet, второй кабинет (слоты с 21 по 30) подключен как IP Expansion Cabinet с опцией Survivability и находится от главного на расстоянии 600 м.

Имеется аналоговый маршрут (TIE, транки XADASE), у которого запрограммирован SRCH RRB. Всего в маршруте 4 транка, два первых находятся в главном кабинете (TN 7 0 и 7 2), а два других - во втором кабинете (TN 24 0 и 24 2). Так сделано потому, что каналы связи приходят в разные помещения (отсюда и выносной кабинет на 600 м).

Но вот в чем трабл. Когда абоненты занимают транки, то циклически они перебирают их только в своем кабинете (хотя на маршруте стоит RRB) . Т.е абоненты главного кабинета занимают по циклу (RRB) только транки в своем кабинете (7 0 и 7 2). И только если транки главного кабинета заняты, переходят на транки выносного кабинета. Аналогично, абоненты выносного кабинета могут занять транки главного кабинета, если только заняты транки кабинете расширения.

Получается проблема - если на К-60 пропадает канал, то абонент, занимая транк, попадает в тишину. Но с точки зрения Меридина транк свободен. Поэтому, если занят один из двух транков, абонент постоянно долбит во второй канал, получает при этом тишину, а не занимает транки во втором кабинете.

Вопрос: корректная ли работа RRB этом случае?

заодно распечатай эти транки, чтобы было видно RTMB

Вот транки:

DES
TN 007 0 00 00
TYPE TIE
CDEN 8D
CUST 0
XTRK XDID
LDOP LOOP
TIMP 600
BIMP 3COM
TRK ANLG
NCOS 1
RTMB 0 3
TGAR 0
SIGL LDR
STRI/STRO IMM IMM
SUPN YES
AST NO
IAPG 0
CLS TLD DIP WTA LPR APN THFD XREP
P10 NTC MID
TKID
AACR NO
DATE 7 MAY 2007

DES
TN 007 0 00 02
TYPE TIE
CDEN 8D
CUST 0
XTRK XDID
LDOP LOOP
TIMP 600
BIMP 3COM
TRK ANLG
NCOS 1
RTMB 0 4
TGAR 0
SIGL LDR
STRI/STRO IMM IMM
SUPN YES
AST NO
IAPG 0
CLS TLD DIP WTA LPR APN THFD XREP
P10 NTC MID
TKID
AACR NO
DATE 7 MAY 2007

DES
TN 024 0 00 00
TYPE TIE
CDEN 8D
CUST 0
XTRK XDID
LDOP LOOP
TIMP 600
BIMP 3COM
TRK ANLG
NCOS 1
RTMB 0 1
TGAR 0
SIGL LDR
STRI/STRO IMM IMM
SUPN YES
AST NO
IAPG 0
CLS TLD DIP WTA LPR APN THFD XREP
P10 NTC MID
TKID
AACR NO
DATE 7 MAY 2007


DES
TN 024 0 00 02
TYPE TIE
CDEN 8D
CUST 0
XTRK XDID
LDOP LOOP
TIMP 600
BIMP 3COM
TRK ANLG
NCOS 1
RTMB 0 2
TGAR 0
SIGL LDR
STRI/STRO IMM IMM
SUPN YES
AST NO
IAPG 0
CLS TLD DIP WTA LPR APN THFD XREP
P10 NTC MID
TKID
AACR NO
DATE 7 MAY 2007

Но дело здесь, наверное, не в RTMB - должны заниматься по кругу/циклу.

captain пишет
Вопрос: корректная ли работа RRB этом случае?
Работает принцип минимизации трафика между кабинетами.
Может быть попробовать перегруппировать транки в два маршрута и задействовать RLB?

2 PhoneMan

Это, конечно же выход, и неплохой из ситуации.

Но тут играет роль такой фактор. У клиента принят набор по XADASE через ACOD (у меня ACOD 0) для того, чтобы слышать готовность встречной станции, и, таким образом, определять работоспособность ТЧ канала.

а через CDP тоже можно слышать готовность

кажется, можно сделать DSC 0 FLEN 1 - вот ты и вышел на маршрут.
в маршруте поставить PANS NO

captain пишет
У клиента принят набор по XADASE через ACOD (у меня ACOD 0) для того, чтобы слышать готовность встречной станции, и, таким образом, определять работоспособность ТЧ канала.
А если поручить прослушивание готовности фиче Dial Tone Detection?
Гудеть абоненту после набора 0 можно при помощи DTAD.

Предположим, я создаю два маршрута, например Route 0 и Route 1.

Создаю RLB

RLI 0
Entry 0
Rout 0
Entry 1
Rout 1

Но ведь Entry 1 займется, если транки в Entry 0 либо заняты, либо выключены, либо в локауте.

Но станция не знает, что пропал ТЧ канал. Она считает, что транк в Entry 0 свободен и исправен, стало быть в Entry 1 не перейдет.

Или я чего-то не так понимаю? Поправьте меня, пожалуйста, если что-то не так.

PhoneMan пишет
А если поручить прослушивание готовности фиче Dial Tone Detection?
Гудеть абоненту после набора 0 можно при помощи DTAD.
Вряд ли! Если УВ.captain работает на сети "Укртрансгаз"(поскольку к-60 вроде только там осталась и ещё гдето на ЖД) то там ситуация такого рода:
Диспетчерам переодически необходимо проверять ТЧ каналы набирая акод, переучить людей будет сложно!

2 PhoneMan

Dial Tone Detection не работает на XADASE.

DTAD тоже вариант, но тогда, после набора номера на неисправном канале абонент снова услышит тишину.

captain пишет
Предположим, я создаю два маршрута, например Route 0 и Route 1.

Создаю RLB

RLI 0
Entry 0
Rout 0
Entry 1
Rout 1

Но ведь Entry 1 займется, если транки в Entry 0 либо заняты, либо выключены, либо в локауте.

Но станция не знает, что пропал ТЧ канал. Она считает, что транк в Entry 0 свободен и исправен, стало быть в Entry 1 не перейдет.

Или я чего-то не так понимаю? Поправьте меня, пожалуйста, если что-то не так.

Я хотел предложить сделать вот так:
RLB nn
entry 0, в нём Rout 0, в котором 2 транка из разных кабинетов 7_0 и 24_0
entry 1, в нём Rout 1, в котором аналогично 7_2 и 24_2

captain пишет
стало быть в Entry 1 не перейдет.
всё так.

Разве что вручную проверять и рулить транками через скрипт (опять же вручную его запускать). Можно использовать, например, TGAR-TARG.

PhoneMan пишет
Я хотел предложить сделать вот так:
RLB nn
entry 0, в нём Rout 0, в котором 2 транка из разных кабинетов 7_0 и 24_0
entry 1, в нём Rout 1, в котором аналогично 7_2 и 24_2

Но все равно для перехода в рут 1 необходима ситуация, когда 7_0 занят первым абонентом, второй абонент "слышит тишину в 24_0", а уже третий попадет в 7_2

captain пишет
2 PhoneMan

Это, конечно же выход, и неплохой из ситуации.

Но тут играет роль такой фактор. У клиента принят набор по XADASE через ACOD (у меня ACOD 0) для того, чтобы слышать готовность встречной станции, и, таким образом, определять работоспособность ТЧ канала.

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

Nicolay1 пишет
Но все равно для перехода в рут 1 необходима ситуация, когда 7_0 занят первым абонентом, второй абонент "слышит тишину в 24_0", а уже третий попадет в 7_2
Да это так.
Однако при RRB в рутах при уходе в аут каналов одной из карт, каждый второй вызов всё-таки уходит наружу по каналам второй карты. imho.

finair пишет
А сделайте каждый транк в отдельный рут, и пусть по разным акодам выходят, раз уж отвал канала так часто бывает.
Акоды можно посадить на кнопки цифровиков через хотлайн. Вроде даже будет показывать флажком, занят/не занят (вот тут не уверен, не помню).
И правда.
Если есть возможность задействовать несколько клавишь, то это будет самый надёжный выход.

finair пишет
А сделайте каждый транк в отдельный рут, и пусть по разным акодам выходят, раз уж отвал канала так часто бывает.
Акоды можно посадить на кнопки цифровиков через хотлайн. Вроде даже будет показывать флажком, занят/не занят (вот тут не уверен, не помню).

А вот еще идея, тож отдельные руты, а их акоды - в пилот DN с типом RRB.

Если бы у всех абонентов были бы цифровики, мне было бы счастье...

А вот перекрестить транки, как предложил ув.PhoneMan я как-то не додумался. Тоже вариант.

А может, такая работа RRB связана вот с чем:

Рапределение слотов опции 11С между сетевыми группами

- slots 1 to 20 are in group 0
- 21 to 40 are in group 1
- 41 to 50 are in group 2.

Я совершенно точно знаю, что на 81С RRB именно так и работает - транки в Group 1 не занимаются до тех пор, пока не будут заняты транки в Group 0.

Получается что мой 2й кабинет находится в группе 1.

Может мне поменять на проце дочерние платы оптического выноса и IP выноса местами?

Тогда транки в IP-кабинете станут в группе 0 и будет счастье?

finair пишет
А вот еще идея, тож отдельные руты, а их акоды - в пилот DN с типом RRB.

Не совсем понял.

Если не трудно, расскажите, пожалуйста, подробнее.

Карты поставить рядом нельзя - ТЧ каналы приходят в разные здания.

Ясное дело, карты поменяются TN'ами. Что-то придется перебить ручками, а абонентов - с помощью ОТМ или командой mov. Это не есть большая проблема.

captain пишет
Не совсем понял.

Если не трудно, расскажите, пожалуйста, подробнее.

Пилот DN - это то, что в LD 57 называется PLDN.
Применяется для создания групп обхода абонентов (group hunting). Тип обхода может быть и RRB.
Так вот, в Ght лист, на основе которого строится группа обхода, записываете акоды рутов. Руты создаются по принципу один транк=один рут.
Если заработает, номер PLDN можно поставить тот, который вам больше нравится. Например, тот же 0.

2 finair

Спасибо за разъяснение.

Что такое PLDN я знал, но не знал, что в список GHT можно включать ACOD'ы.

Век живи, век учись, все равно дураком умрешь. :)

И не кто не знал. Оно не даст акоды в список вставить. Скажет, что не тот тип DN...

Lev Serdukov пишет
И не кто не знал. Оно не даст акоды в список вставить. Скажет, что не тот тип DN...
Вот же будет Вам удивление, когда попробуете :)
Оно даст.

Lev Serdukov пишет
И не кто не знал. Оно не даст акоды в список вставить. Скажет, что не тот тип DN...

Никогда не говори никогда :)

Как много нам открытий чудных... Блин, оно все же дало. :eek:

Большое спасибо всем откликнувшимся за помощь (особенно PhoneMan и finair)!

При следующем посещении объекта обязательно попробую ваши предложения.

Объект посетил, проверил занятие аналоговых транков через PLDN - действительно работает (спасибо finair за новые знания!).

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

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

Теперь все стало на свои места, и RRB работает как положено.

Еще раз спасибо всем!