MNP. Mobile number portability. Схема реализации
Схема организации MNP
Суть решения. Есть требования регламента, согласно которым в предоставлении MNP абоненту не должен участовать оператор-донор. В самом деле, если абонент от него ушел, то какое может быть оказание услуги, когда абонента уже тошнит от этого оператора.
Наше решение сходится к тому, что ни в сети оператора донора, ни в сети реципиента не нужно делать каких-то решений. Когда вызов поступает в сеть донора и сеть понимает, что этот номер ей больше не принадлежит, то все, что ей нужно сделать - это отбить этот номер. И дальше этот вызов будет перенаправлен на оператора, который, собственно, будет обладать комплексом технических средств, необходимых для перенаправления вызова на сеть реципиента. Это может быть МТТ, а может быть и не МТТ. Единственное, что должен сделать регулятор - это обеспечить наличие одного такого оператора или коммутатора на территории каждого сегмента переносимости. Это нужно, чтобы не нарваться на те же "грабли", на которые в свое время нарвались в США. Когда там начали внедрять переносимость на всей территории США, выяснилось, что непонятно, как объявлять абоненту о стоимости вызова. Вызовы соседу могли обернуться вызовами в соседние штаты. Есть разные технические решения, есть информирование со специальными сигналами, запросы в базы данных. Но все это сложно, не работает, вызывает истерики абонентов. В итоге была внедрена локальная переносимость номеров, переносимость в рамках локального сегмента, где тариф плоский. То же самое предлагается сделать в России, но при этом мы не давали определения такого сегмента, это должен сделать регулятор. Может быть это будет субъект федерации, может быть это будет полстраны. В итоге мы придем, наверное, к плоским тарифам.
И любой оператор может стать тем оператором, который обеспечивает переносимость номеров, например, на основании конкурса. Другие операторы, субсидиарно финансируя могу создать такого оператора.
Мы говорим о подходе, который технически позволяет осуществить это на сети. И не пытаемся "перетягивать на себя одеяло".
Номерной диапазон DEF принадлежит оператору-донору. Но абонент ушел к реципиенту. Что происходит, когда поступает вызов? Несмотря на то, что у нас нумерация как бы негеографическая, на деле вызов нужно куда-то "приземлить", в конкретную географическую точку. Когда из любой сети поступает вызов, он поступает в сеть "донор" (1).
Конечно, есть разные подходы, например, есть подход, согласно которому каждый оператор, являющийся так называемым (n-1) оператором, зная, что для данного номера следующий оператор будет уже конечным, обязан сделать запрос в базу данных БДНП (горизонтальная пунктирная линия). И поняв, что номер уже не принадлежит "донору", а принадлежит "реципиенту", направить вызов на "реципиента" (наклонная пунктирная линия). Это называется all call query (ACQ) подход, связанный с бешеными расходами. Каждому оператору, на каждом коммутаторе нужно понять, что каждый вызов является (n-1)-м, сделать запрос и перенаправление. Это технически сложное решение. Есть еще два других варианта, на которых не хотелось бы здесь останавливаться.
Суть нашего предложения состоит в следующем. В каждом сегменте переносимости есть, как минимум, один коммутатор, который умеет делать запросы к БДНП. Вот он всегда делает запросы ACQ. И это означает, что воспроизводит этот механизм на всех других коммутаторах ни для чего не нужно. Тем не менее, никто не запрещает оператору делать запросы, если ему это хочется делать. Главное, что ему предоставляется возможность, НЕ делая запроса, выполнять требования по перемаршрутеризации вызова.
Итак, когда к донору приходит вызов (1), ему достаточно "отбить" его с указанием соответствующей причины REL (НП), что номер перенесен (2). Далее наш вызывающий оператор путем второго выбора, направляет вызов (3) маршрутеризирующему оператору (коммутатору). Маршрутеризирующий оператор делает свой ACQ-запрос в БДНП (4) и по существующему пучку отправляет вызов (5) туда, где обслуживается абонент.
На самом деле схема чуть более сложная. Запрос будет делаться в HLR, и если абонент находится в роуминге, то вызов будет, соответственно, ему перенаправлен. Это называется global interrogation - может применяться, может не применяться.
Click to viewСуть решения. Есть требования регламента, согласно которым в предоставлении MNP абоненту не должен участовать оператор-донор. В самом деле, если абонент от него ушел, то какое может быть оказание услуги, когда абонента уже тошнит от этого оператора.
Наше решение сходится к тому, что ни в сети оператора донора, ни в сети реципиента не нужно делать каких-то решений. Когда вызов поступает в сеть донора и сеть понимает, что этот номер ей больше не принадлежит, то все, что ей нужно сделать - это отбить этот номер. И дальше этот вызов будет перенаправлен на оператора, который, собственно, будет обладать комплексом технических средств, необходимых для перенаправления вызова на сеть реципиента. Это может быть МТТ, а может быть и не МТТ. Единственное, что должен сделать регулятор - это обеспечить наличие одного такого оператора или коммутатора на территории каждого сегмента переносимости. Это нужно, чтобы не нарваться на те же "грабли", на которые в свое время нарвались в США. Когда там начали внедрять переносимость на всей территории США, выяснилось, что непонятно, как объявлять абоненту о стоимости вызова. Вызовы соседу могли обернуться вызовами в соседние штаты. Есть разные технические решения, есть информирование со специальными сигналами, запросы в базы данных. Но все это сложно, не работает, вызывает истерики абонентов. В итоге была внедрена локальная переносимость номеров, переносимость в рамках локального сегмента, где тариф плоский. То же самое предлагается сделать в России, но при этом мы не давали определения такого сегмента, это должен сделать регулятор. Может быть это будет субъект федерации, может быть это будет полстраны. В итоге мы придем, наверное, к плоским тарифам.
И любой оператор может стать тем оператором, который обеспечивает переносимость номеров, например, на основании конкурса. Другие операторы, субсидиарно финансируя могу создать такого оператора.
Мы говорим о подходе, который технически позволяет осуществить это на сети. И не пытаемся "перетягивать на себя одеяло".
Номерной диапазон DEF принадлежит оператору-донору. Но абонент ушел к реципиенту. Что происходит, когда поступает вызов? Несмотря на то, что у нас нумерация как бы негеографическая, на деле вызов нужно куда-то "приземлить", в конкретную географическую точку. Когда из любой сети поступает вызов, он поступает в сеть "донор" (1).
Конечно, есть разные подходы, например, есть подход, согласно которому каждый оператор, являющийся так называемым (n-1) оператором, зная, что для данного номера следующий оператор будет уже конечным, обязан сделать запрос в базу данных БДНП (горизонтальная пунктирная линия). И поняв, что номер уже не принадлежит "донору", а принадлежит "реципиенту", направить вызов на "реципиента" (наклонная пунктирная линия). Это называется all call query (ACQ) подход, связанный с бешеными расходами. Каждому оператору, на каждом коммутаторе нужно понять, что каждый вызов является (n-1)-м, сделать запрос и перенаправление. Это технически сложное решение. Есть еще два других варианта, на которых не хотелось бы здесь останавливаться.
Суть нашего предложения состоит в следующем. В каждом сегменте переносимости есть, как минимум, один коммутатор, который умеет делать запросы к БДНП. Вот он всегда делает запросы ACQ. И это означает, что воспроизводит этот механизм на всех других коммутаторах ни для чего не нужно. Тем не менее, никто не запрещает оператору делать запросы, если ему это хочется делать. Главное, что ему предоставляется возможность, НЕ делая запроса, выполнять требования по перемаршрутеризации вызова.
Итак, когда к донору приходит вызов (1), ему достаточно "отбить" его с указанием соответствующей причины REL (НП), что номер перенесен (2). Далее наш вызывающий оператор путем второго выбора, направляет вызов (3) маршрутеризирующему оператору (коммутатору). Маршрутеризирующий оператор делает свой ACQ-запрос в БДНП (4) и по существующему пучку отправляет вызов (5) туда, где обслуживается абонент.
На самом деле схема чуть более сложная. Запрос будет делаться в HLR, и если абонент находится в роуминге, то вызов будет, соответственно, ему перенаправлен. Это называется global interrogation - может применяться, может не применяться.