Pull to refresh

Comments 63

Ставим плюс за детальное описание довольно узкоспециализированного протокола. Но всё таки сложновато xD
Из статьи не связистам совершенно непонятно для чего этот стек протоколов нужен. Не описаны преимущества и которые дала эта технология. Одно из главных преимуществ — это то что можно управлять звонком не только в момент соединения, но так же в течение разговора и во время завершения (переадресация, конференц-связь, удержание вызова, подвижная связь и т.д.).

Читается как узко-специализированное и значительное число читателей таких руководств искренне удивляются когда рассказываешь им как часто они сталкиваются с SS7, к примеру при объяснении чем определен размер SMS.

Но все равно хорошо что эта статья появилась. Очень интересный набор технологий. Особенно на мой взгляд IN часть и SS7overIP. И не такой страшный как выглядит с первого взгляда.
IN весьма и весьма устаревшее представление о развитии ДВО (VAS). копайте глубже, в сторону IMS, вот там творятся реальные чудеса :)
Абсолютно согласен. Опять же имхо, в IMS надо вникать после разбора основ IN.
IMS вообще ортогонален к IN. Изучайте отдельно. Главное понимать, что IMS — это одна из инициатив текущего тренда перехода в IP. Предыдущая — NGN рассматривала переход опорной сети в IP, а IMS — это уже взаимодействие опорной сети с терминальным оборудованием.
Хм, а я как-то не сразу решился опубликовать эту статью. Думал, что мало конкретики и всё представлено в общем виде, а получилось наоборот, судя по комментарию выше.

Мне эта система далась легко. Сразу понял расположение и назначения уровней, связи между ними, сообщения.
А можно не скромный вопрос — какова цель публикации этой статьи?
Хотел зарегистрироваться на сайте для того, чтобы было удобнее пользоваться ресурсом. Выбрал эту тему, т.к. думал, что она возможно будет интересна. Кроме того — возможность обсудить материал.
Я в принципе закрываю глаза на то, что это copy-paste из какой то методички и даже немного рад, что затронута такая тема, но мне не понятно само практическое назначение статьи. Ведь в ней детально описаны нижние уровни семерки (MTP-SCCP), которые даже разработчики уже не касаются (стеки протоколов сто лет как реализованы и выверены донельзя).

Было бы лучше, если бы вы на примере workflow диаграмм показали, каким образом общаются две станции, немного осветили ISDN и тоже набросали какой нибудь вызов для GSM, а подитожили все это пресловутой сессией GPRS под управлением CAMEL в роуминге, благо это тема сейчас больная и очень популярная.

А так регистрация на хабре выходит получена практически на халяву…
Уж прошу прощения за оффтопик.

«а подитожили все это пресловутой сессией GPRS под управлением CAMEL в роуминге, благо это тема сейчас больная и очень популярная»

Да, bill-shock из-за передачи данных в роуминге стал популярной темой )

Если трафик приземляется на GGSN в домашней сети, то проще уж интегрироваться по DCCA с OCS, благо железки сейчас умные пошли и технология не сложная. Куда проще чем с каждым SGSN партнера интегрироваться.
CAMEL это хорошо, но он не очень удобен для оценки дата-трафика.
Ну если можно было бы почитать про Diameter & Radius, то это ваще было бы мегакруто! Кстати, никто не в курсе, как выкрутился мегафон?
А что там выкручитваться-то? GGSN у всех дома. Нет и небыло никаких проблем тарифицировать Prepaid в реальном времени.

Про RADIUS и DIAMETER писать нечего, ибо помимо реализации былового контейнера каждый вендор реализует то, что в голову всбредет: стандартно в RADIUS нет поддердки Prepaid-модели, а в DIAMETER-е достаточно обобщенный контейнер в DCCA (rfc4006). Да, и не забываем, что и RADIUS и DIAMETER (в особенности) — это контейнеры общего назначения, использующиеся не только для функции credit-control.
Угу. Оба этих протокола имеют много серых зон в описании, что затрудняет выяснение отношений между вендорами.
О! Какие люди! :)
Я ты сказал, что многое еще и от заказчика зависит %)
Ага, ага ) Про протоколы это я так — поздороваться )

В этом случае от заказчика зависит практически все — кого он меньше любит, тот свою часть AVP и переписывает ;)
У нас, кстати, брэнч как на RADIUS, так и на DIAMETER. Офицально. :)
А вы, простите, на кого работаете?
Ибо в Мегафоне DCCA делают только два вендора…
Забавно. :) Первое — с чего вы взяли что я работаю у вендора? Второе — у нас кроме Мегафона операторов нет?
В статье говорится как о базовых штуках, таких как описание двух принципов передачи сигнальных сообщений, так и о низкоуровневых фактах (структуре MSU). Сложно в таком объеме текста описать все что можно реализовать средствами семерки.

Но повторюсь, очень хорошо что материалы на эту тему появляются, на популярных околотехнических ресурсах эти вопросы почти не обсуждаются.
На этом «узкоспециализированном» стеке протоколов работает вся современная связь. Если брать аналогию из IT, то SS7 это эквивалент IP (SS7, он же семерка, он же ОКС).

GSM, UMS, LTE — все это железо для управление соединениями и ресурсами сети используют семерку.
ну про всю современную связь вы загнули :) интернет это тоже вид связи, а ss7 для работы интернета не нужен. даже сказав «вся современная телефонная связь» будете не правы — есть h323/sip, есть skype который совсем другой. и им всем не нужна ss7.
imho, ss7 даже близко не стоит рядом с миром ip.
Вы не поверите. С появлением SIGTRAN эти 2 мира объединились.
не поверю :) SIGTRAN нужен чтоб ss7 работало нормально поверх ip, его иногда даже кличут как IEC SS7 over IP.
так что это просто поддержка legacy-standarts
Хорошо, поясню.

1) После того как появился SS7overIP сигнальный трафик замечательно передается через интернет. Особенно это актуально в случае соединения с SMS хабами.
2) IP трафик довольно часто заворачивают в ОКС7 потоки

Правда и с тем и с другим явлением монополисты пытаются бороться, но не важно.
Важно то, что для ОКС7 можно использовать IP как транспорт. И нет в этом никакого противоречия.

И коммутаторы новые замечательно работают одновременно как с SS7 так и с SIP.
И упомянутая выше технология IMS описана в рекомендациях 3gpp.
Смысла разделять эти 2 технологии тоже нет. Просто для разных целей тот или иной протокол удобнее\дешевле\надежнее\проще (нужное подчеркнуть).
2) IP трафик довольно часто заворачивают в ОКС7 потоки

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

1) SS7overIP (SIGTRAN) не нужен сетям IP, он нужен традиционным сетям чтоб выжить в современном мире.
2) ip по потокам ss7 это динозавр который почти вымер. ip over t1/e1/t3/e3, особенно когда eX unframed, то есть просто чистый g703, никаким боком не относится к ss7. так что ip через сеть ss7 — это когда у вас есть PRI/BRI, ваш роутер звонит через эти pri/bri другому роутеру, в промежутке между ними происходит вся чехарда с сигнализацией, устанавливается соединение между роутерами и поверх него начинает бегать IP. А пока оно бегает вы платите поминутно за 30 телефонных звонков. Кому это надо? Да оно есть, в Африке или у идиотов.

так что мой тезис о том, что SS7 — это дааааалеко не вся связь вполне себе верен. Более того, ip over ss7 — это геморрой и пережиток. И наконец, сейчас ss7 сохранена по простой и банальной причине обратной совместимости и наличия миллионов тонн древних коммутаторов.
А не буду. Вы меня поняли что возможны оба варианта, я вас понял и согласен что ip over ss7 пережиток.

И SS7 не вся связь, я выдвинул тезис о том что смысла нет уже делить, эти 2 стека очень прочно связаны.

И вообще, день рабочий, уж простите.
У нас есть куча монополистов, которые очень не любят IP и придумывают клевые законы, о том, что международный трафик по IP гонять запрещено. Выводы делайте сами
у нас это в США? или во Франции? для меня «мы» может быть другим, вам не кажется? :)
да и вообще — речь о технологиях, а не чьих-то амбициях
А что, вы полагаете, что в США, Европе или иных странах нет своих монополистов? Там до недавних пор операторы запрещали Skype трафик как раз таки по причине финансовых потерь.
точно знаю, что такой бред у нас и в Африке. в США за такие вещи операторы быстро получили по сусалам и стали думать по-другому.
и повторяю, разговор о каких-то идиотских запретах и монополиях никак не относится к теме развития/противоборства технологий. это human fucktor.
глупо все ровнять под одну гребёнку. Там где есть клёвые IP сети разумеется можно гонять и видео и трафик по IP. Хотя насущным остается вопрос к QoS.

Там где нет IP, либо качество ниже плинтуса, либо стоит он столько, что можно только и мечтать про заморский американский мега интернет, остаются все те же старые допотопные сети связи. При этом такие сети есть и у нас, и в Штатах и в Европе.

Не видел ни одного нормального коммутатора, кроме абон уплотнителей и мелких атс-ок которые бы работали по PRI. Всякую мелкую сошку обычно пристыковывают по PRI
Как насчет MC240?
PRI удобен в настройках, указал Network/User side указал каналы и не паришься.

С ОКС7, надо думать уже об OPC, DPC, о CICах и прочем. Но ОКС7 дает преимущество в 2 разговорных канала на E1.

Про R1,5 Молчу =)
Вот за это PRI я и считаю суть абонентской сигнализацией.
Для небольшого коммутатора типа городской/сельской атс без транзитного трафика, с простой конфигой, это конечно проще. Но когда надо, например сделать резервные маршруты для сигнализации, когда в направлении несколько линксетов сразу ОКС начинаеш ценить за стройную мощь.
Преимущества в 2 разговорных канала — мнимое, ибо 1 линк держит 1024 таймслота, на фоне которых экономия 1 канала — ничто.

Про R1,5 я предлагаю забыть как страшный сон. Время релейной и ламповой техники слава богу ушло.
В плане транзита, да ОКС рулит. А вот мне на одной железке на днях пришлось на коммутаторе потоков конвертировать R1.5 в ОКС, на московских АТС…
Охотно верю, что такое может происходить даже в ДС, что меня печалит.
За такие дела операторам связи надо мне кажется ноги и руки менять местами.
Все правильно, PRI это исключительно абонентский сегмент, Q931 мало пригоден для транзитного трафика. Тут и начинает рулить ISUP.
LTE уже все через DIAMETER :) семерки тама почти и нет :(
Спасибо за статью! Нет ли желания продолжить цикл SIGRAN'ом (M3UA, M2UA)? Было бы очень интересно!
Да лучще тогда SIP-T. SIGTRAN ущербен по своей идеологии. :)
С SIP-T/SIP-I все просто, это обычный SIP c бинарными аттачами, там ничего интересного. А насчет SIGTRAN'а не соглашусь. Имхо, это лучший способ для конвергенции IP и SS7 сетей в ядре софтсвичей. Один SCTP стоит многого.
Есть другое мнение. :) SIGTRAN тащит за собой адресацию SPC со всеми вытикающими в виде шкафа со скелетом. SIP-T и SIP-I максимально от этого абстрагируется, неся ISUP в качестве дополнительной справочной информации, обеспечивая истинно IP-шную коммутацию.
Безусловно SIP-T/SIP-I выглядит гораздо логичнее в наше время. Но, к сожалению, далеко не каждый вендор его поддерживает. По моему опыту, на западе вообще мало известен. Чаще используются стыки по M2UA или M3UA используя сигнальные и медиа-шлюзы. Типа того же AudioCodes Mediant/TelcoBridges/Iskratel. Опять же, говорю исходя из своего опыта. Возможно, ситуация выглядит иначе
Да. Видимо мы с вами различными вендорами мыслим: Ericsson и Dialogic (Veraz).
да, с Dialogic как-то успешно стыковался по SIP-T.
Вообще-то по русски SS7 переводится как ОКС-7 (Общеканальная система сигнализации № 7). Так во всей русской документации. Ну а если кого заинтересовал вопрос — вперёд за Гольдштейном. У него много книжек.
Ну, сказать честно, книжки у Гольдштейна я бы рекомендовать не стал. Часто это либо плохой перевод RFC либо труды его студентов (мне так показалось)
К сожалению статья для галочки, ибо у автора понимания ОКС7 нет. Ну начал бы тогда с E1 и PCM30, чтобы хоть какие-то азы читателю дать. Выглядит копи-пастом с какого-нибуть сотовика.
Хотелось бы, чтоб для обывателей были даны основные понятия в адресации на сигнальной сети — SPC и GT, основной упор на прикладные MAP и ISUP.
Signaling System #7 / Система сигнализации №7 — это набор сетевых протоколов, обеспечивающих обмен служебными сообщениями между мобильными станциями (мобильными телефонами) и телефонными станциями, а также между самими телефонными станциями.

К мобильным телефонам ОКС7 особого отношения не имеет.

SS#7 – это стек протоколов, описывающий способы коммуникации между телефонными распределителями (switches) в открытых телефонных сетях.

Первый раз вижу перевод switch (чаще — коммутатор, реже — телефонная станция) как «телефонный распределитель».
Автор имеет ввиду, что базовые станции и вся сигнализация за ними используют SS7
Тоже прочитал «телефонный распределитель» и сразу подумал что это компиляция из методичек и какой-то переводной статьи.
Я switch перевел на собеседовании как переключатель, ибо по образованию не связист, а промэлектронщик, что тогда простительно было.
А подскажите пожалуйста книги по основам ОКС-7 — работаю с ней, но знания очень поверхностные. Хочется иметь общее понимает структуры и функций каждого элемента, но без подробностей в виде стуктуры пакетов с длинной полей.
Есть очень хороший автор Гольдштейн, у него много книг по сигнализациям, в том числе и по ОКС
НЛО прилетело и опубликовало этот коментарий здесь:
«У меня имеется виртуальная машина под RedHat на которой крутится рабочий SS7 TIETO стек с конфигуратором/отладчиком и тп… на нем можно проводить экспиременты и получать вполне работоспособные конфигурации. Ну и если статья будет подкреплена скриншотами tvtool'a и конфигуратора — будет совсем другое дело. В случае, если автор статьи продолжит публикации в этом направлении, я готов предоставить доступ к своей машине для экспериментов. Также имеется очень много информации по этому вопросу. В качестве контакта со мной можете использовать почту: yaroslav@berezhinskiy.name»
как все сложно.
не проще связываться по 3G а звонить через internet
А как вы будете принимать входящие звонки? Все время держать tcp connection? Батарея вашего телефона проживет 2 часа, вместо 2х недель.
Прям-таки обуяла ностальгия по студенческим временам…
Частично для систематизации своих знаний, частично из альтруистских соображений, частично в качестве задела на будущий бизнес освещаю различные аспекты темы в блоге «SS7 для чайников» — ss7.powerpbx.ru
Only those users with full accounts are able to leave comments. Log in, please.