У нас А4400 подключена к городу по E1, плата PRA2. Все работало классно. А сейчас начались проблемы. Говорят, что наша станция не синхронизируется с городской станцией. Причем на разговоры это не влияет, а влияет только на модемную и факсовую связь. Скажите, как проверить эту синхронизацию? Мы должны ее получать, как узнать, получаем или нет? Ответьте, плиз, побыстрее, а то работа просто встала!

Посмотрите по ветке Shelf/Board/DigitalAccess/Synchronization priority. Стоящий там параметр должен отличаться от 255 и желательно меньше 200. Если у вас один поток поставьте, например 50. Если потоков несколько, наиболее приоритетный должен быть с меньшим значением. Сотояние синхронизации можно посмотреть командой infocs.

Понятно, с этим разобрался. А вот такой вопрос - если потоков больше одного и они от разных провайдеров, как тогда синхронизироваться?

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

ак вопрос в догонку,
если мы ставим 0 - то берем синхру с потока,
если 255 - то плюем на синхру с потока.
вопрос - для чего нам нужна синхра?
если на нормального синхронного обмена в режиме ведущий-ведомый ( по физике ). и тут 2 варианта - либо я ведущий либо ведомый.
зачем весь остальной диапазон возможных значений 1-254?

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

Системы с потоками в любом случае - плезиохронные, другое дело, что транспорт, который доставляет потоки, может быть синхронным, например, SDH - синхронная цифровая иерархия. Разные цифры нужны в случае наличия нескольких источников синхронизации, различных как по надежности, так и по качеству, и построения сложных многоуровневых систем(сетей). В случае наличия нескольких операторов, которые синхронизируются от разных источников синхронизации, возникают конфликты на границе зон синхронизации, которые не исправить никакими ухищрениями, только попросив операторов засинхронизироваться от одного источника синхронизации. Более подробно с этими вопросами можно ознакомиться на курсах по сетям.

По поводу ведущий-ведомый... как данное надо принять тот факт, что ведущим синхронизации для своего оператора вы не должны быть никогда по определению, иначе начнется хаос в сети. Осцилляторы в процессорах алкатель достаточно нестабильные по современным меркам - 5ппм, в перечне системных плат есть плата SYNC обеспечивающая 1ппм в режиме свободного полета. Но даже в этом случае выполняется частотная но не фазовая синхронизация. По поводу необходимости наличия приоритетов в диапазоне 1-254 подробно с картинками расписано в доке. проблемы синхронизации в плезиохронной сети можно избежать включая себя в один мультиплексор стм, если вы берете несколько потоков с одного мультиплексора - они будут синхронны между собой имхо, но это более организационная проблема оператора, нам трудно повлиять на нее.

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

дак вот вопрос снова ДЛЯ ЧЕГО НУЖНА СИНХРА.и как она прикручивается к станции.

то что не для работы поаты PRI эьто точно. у нее должна быть своя, и на каждый поток.

знатоки обьясните.

Все, что дальше будет написано, касается не только алкателевских станций, а вообще принципов синхронизации.

1. Платы потоков Е1 не настолько тупы, чтобы сразу гнать принятый битовый поток на TDM шину станции. У них есть свой буфер, чтобы компенсировать некоторые гуляния фазы и частоты принимаемого сигнала. Это к вопросу о том, что если один поток засинхронизирован, то второй по определению работать не будет. Будет как миленький.

2. Синхронизация строится по иерархическому принципу. На самом верхнем (национальном) уровне есть очень стабильный первичный задающий генератор, и все остальные станции синхронизируются в конечном итоге от него - если не напрямую (что, естественно, затруднительно), то от тех станций, кто засинхронизирован от него, либо от тех, кто засинхронизирован от тех, которые засинхронизированы от него :)
Национальные сети на международном уровне между собой не засинхронизированы, так стабильность (и стоимость ;) ) этих генераторов настолько высока, что их частоты не расходятся друг с другом за разумное время.

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

4. Когда все эти требования соблюдены, то оконечная станция, подключенная к двум независимым операторам и засинхронизированная от одного из них, проблем с синхронизацией со вторым оператором испытывать не будет, так как оба этих оператора в конечном итоге должны быть засинхронизированы от одного источника. Если это не так, то имеет смысл сначала стравить этих двух операторов, чтобы они проверили свои планы синхронизации, если это не поможет - то вы имеете полное право пожаловаться в государственные регулирующие органы на предмет несоответствия предоставляемой услуги нормам. Так операторам прямо и можно сказать - на них это обычно хорошо действует :)

Спасибо за внимание.

Все платы в станции синхронизируются от генератора платы процессора. В свою очередь плата процессора может синхронизироваться от ИКМ, первичного, базового доступа или платы DECT. В каждый момент времени синхронизация берется только от одного источника синхронизации. От какого именно - можно посмотреть командой infocs. Здесь же можно посмотреть состояние потенциальных(возможных) источников синхронизации, т.е. тех доступов, на которых Synchronization priority отлична от 255.
Если у вас нет синхронизации с вашим провайдером, то во время разговора вы можете слышать щелчки, это если разбег по частоте - небольшой. Это проявление эффекта "проскальзывания" или Slip.
Если нет возможности приехать на курсы, то читайте учебники и документацию. Транслировать учебники на форуме - не вижу смысла.

Добавлю свое "ква": в OXE, где выносы могут соединяться по VoIP, который, как понятно, синхронизацию передавать не может, станция делится на несколько независимых доменов синхронизации. Домен задается путем выставления приоритета синхронизации 200. Вторичные источники синхронизации в домене задаются путем задания приоритетов 201-254. Чем, соответственно, выше число, тем меньше приоритет. И как справедливо было сказано, все это великолепно видно по команде infocs.

мдааа, напоминает докаательство теории относительности - в итоге никто никто не может ответить на элементарные вопросы, а все потому что аксиома.

по поводу книжек - автор название , иначе все лирика.
дока - название файла или ссылка.

По-моему, ответ на изначальный вопрос дан, и вполне конкретный - станцию синхронизировать надо, как - указано, как посмотреть, что это произошло - тоже указано, как это должно работать в случае наличия потоков от двух и более операторов - тоже расписано, куда обращаться в случае, если это не так - тоже расписано.
Вопросы синхронизации для OXE R6 расписаны в файле ID09011b028019cc14.pdf (это если у вас последняя версия документации с BPWS), либо в файле -PCX_synchronization.pdf (если у вас дока от OXE 5.1) либо в файле 10-PABX_synchronisation-01.pdf, если у вас дока от 4400 R4.2. Что касается популярных книжек - "сходите в библиотеку" (C) RU.PHREAKS, почитайте какой-нибудь учебник для связистов.

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

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

а ответа почему станция будет работать с двумя потоками я не увидел.
из всего сказанного могу сделать выводы:
1. на каждой плате свой собственный генератор с ФАПЧ. иначе ниче работать не будет.
2. синхронизация берется CPU c наименьшим номером приоритета. внутренняя шина работает синхронно с CPU.
3. все потоки с бОльшими номерами приоритета работают плезиохронно с внутренней шиной.
4. для компенсации разности частот и набегов фаз нужен буфер между шиной и потоком.
5 из п4 вытекает что длительность работы шины и потока определяется размером буфера.
6. после его переполнения необходимо провести заново процесс ( кжись цикловой) синхронизации.
7. на период восстановления будет прервана нормальная предача данных, валятся модемы /факсы)


вывод - нормальная работа факсов/модемов возможна только на потоке с наименьшим номером приоритета.

пойду печятать файло - почтаю на ночь глядя :)

Как показала практика, бывают проблемы с синхронизацией (понимаем - факсы и модемы), когда потоки добегают из одного места до другого разными дорогами (через разное оборудование). Особенно если чего-то прямо, а чего-то через SDH (без функции retiming).
Проблемы с потоками от разных операторов решаются плохо, возникает вопрос берет ли второй провайдер синхронизацию из правильного места.

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

> 4. для компенсации разности частот и набегов фаз нужен буфер между шиной и потоком.

Вот он, отчасти ложный постулат. При _правильной_ схеме синхронизации будет только разница в фазе сигнала, а не в частоте - см. мое письмо относительно построения иерархической системы синхронизации в ТФОП. Разница же в фазе компенсируется буфером на плате Е1, данные в который поступают с любой фазой, а вот выдаются на внутреннюю TDM-шину станции в соответствии с задающим генератором CPU, который засинхронизирован от какого-то одного потока.

Так что будут работать по этому потоку и модемы, и факсы. Это не голословное утверждение - такая ситуация вполне типична для мелких операторов связи, работающих на разных PBXинах и имеющих выходы сразу на нескольких других более крупных операторов. Так вот: при грамотном выборе источника синхронизации факсы и модемы работают по всем потокам, проверено.

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

а если рассмотреть такой пример: взять один поток с узла и подать напрямую в мою атс, второй с этогоже узла, но заслать его через ..цать операторов по всей стране и воткнуть в мою атс.
1. распростронения сигнала по линиям имеет конечную скорость.
2. задержки в аппаратуре тоже никто не отменял.
3. величина ошибки сопровождения синхросигнала - зависит только от схемы, и заложеных параметрах на ошибку, причем величина ошибки зависит от скорости изменения параметров сигнала за которым следим. при последовательном включении эти ошибки будут накапливаться. и где гарантия что на какомнибуть участке мы влезем в полосу захвата ФАПЧ и в допустимую скорость сопровождения. такчто фаза и частота будут изменятся.

вот и получим 1 и 2 можно считать константами ,а вот 3 - шумоподобный характер, форму характеристики сказать не берусь.

и если смотреть на взаимное расположение сигналов, то второй будет задержан на 1+2, и частотнофазовыми характеристиками по закону 3.

> странный метод доказательства - раз глобальная синхронизация , значит все должно работать.

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

> а если рассмотреть такой пример: взять один поток с узла и подать напрямую в мою атс, второй с этогоже узла, но заслать его через ..цать операторов по всей стране и воткнуть в мою атс.

Перечитайте, пожалуйста, мое письмо относительно организации синхронизации еще раз, в частности, тот пункт, в котором говорится, что через Nное количество звеньев передачи синхросигнал должен быть восстановлен путем организации прямого канала до источника стабильного синхросигнала или установки местного высокостабильного генератора. И это число N как раз расчитывается исходя из приведенных вами в п.п.1-3 критериев.
Кстати, операторов связи ГСН (или как он там сейчас после всех реформ называется) за такую прокидку отымеет по полной программе. И будет прав, между прочим. Вот в корпоративных сетях с этим обстоит хуже. О чем, собственно, косвенно эта дискуссия и свидетельствует.

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

я так понял чтто Вы отказываетесь признать нарушения синхронной работы с двумя потоками только потому что это запрещено актами ГСН и мистическим выражением (можно читать заклинание) "глобальная синхронизация".

напоминает спор слепого с глухим :)

В этом споре есть один момент, все хорошо пока подключение нормальное - альтернативный оператор включен в ГТС потоком и синхронизируется от него.
Но в практике были случаи, когда второй оператор давал поток, но при этом не имел нормального подключения в город (например R1.5 3-х проводки). При этом он был нужен (неважно дальше дешевый межгород, IP телефония, интернет, передача данных или еще чего). При этом синхронизацию от вас брать не может или не хочет - вот тогда наступает песня.
При этом его интерфейс в ГТС не обязательно должен быть столь архаичен, например он включается кучкой базовых доступов ISDN, с ними еще веселее - есть у него соединения в город - есть синхронизация. Никто с городом не общается - в России на базовом доступе в этом случае физический сигнал (первый уровень) отсутствует, соответственно начинаются проблемы с синхронизацией.

to xandr: Нарушения синхронной работы я признавать не отказываюсь. Хотя бы потому, что сам с ними встречался. Я говорю, что при грамотно построенной системе синхронизации их быть не должно. И, кстати, нет. Опять же говорю это потому, что сам с этим также встречался. И зависит это и от нашей позиции (т.е. позиции инженеров) в этом вопросе тоже. Потому что если в операторе, подключенном в город 3-х проводками, о котором говорит vad, сидит инженер типа вас, который говорит "пошли вы нах, все-равно это может и не работать, а раз может не работать - значит и х с ним, а ГСНом нас не испугаешь - только вчера с ними водку пьянствовали", то оно и не будет работать. И чем больше таких инженеров будет - тем больше будет проблем. И не только с синхронизацией - такой подход имеет тенденцию распространяться и на другие области, в том числе и не имеющие отношения к телекоммуникациям. И, увы, распространяется. Так что проблема синхронизации сети в первую очередь не в оборудовании, а в головах.
В общем, подытоживая эту дискуссию, хочу сказать, что делать свою работу нужно хорошо. А плохо - оно и само получится, без наших усилий. Собственно, эту мысль относительно проблемы синхронизации я и вытался до вас донести. Судя по вашей последней фразе - безуспешно :(