СИСТЕМА МОБИЛЬНОЙ СВЯЗИ Российский патент 2013 года по МПК H04W12/12 H04W4/22 H04W28/16 

Область техники, к которой относится изобретение

Настоящее изобретение относится к системе мобильной связи.

Уровень техники

Считается, что формы промышленного использования базовой фемто-станции (домашний узел B; далее сокращенно HNB) включают в себя, например, форму использования, такую как небольшая беспроводная базовая станция, предназначенная для домашнего использования, и форму использования, такую как небольшая беспроводная базовая станция на предприятии.

Обеспечение услуг посредством HNB включает в себя, например, следующие преимущества:

(1) возможность предоставления услуги вызова в зоне молчания, куда не достигают радиоволны от макробазовой станции;

(2) возможность предоставления услуги выставления счета, стоимость которых ниже, чем стоимость типовых услуг, предоставляемых макробазовой станцией;

(3) возможность использования преимуществ высокоскоростных технологий 64QAM (64-ричная квадратурная амплитудная модуляция) и MIMO (система с множеством входов и множеством выходов), что позволяет обеспечить подчинение услуги высокоскоростной передачи пакетов узлу HNB, поскольку расстояние между базовой станцией и мобильной станцией невелико, и мобильная станция может поддерживать высокое качество беспроводной связи (Ec/Io); и

(4) возможность предоставления услуги передачи специализированного контента, используя преимущество локальности HNB.

Как было описано выше, обслуживание посредством HNB имеет множество преимуществ. Соответственно, предпочтительно предоставлять такое обслуживание только тем абонентам, которые подписали контракт с поставщиком, и тем абонентам, которые получили разрешение от владельца HNB.

Таким образом, 3GPP (Проект партнерства 3-го поколения), в версии 8, ввел CSG (закрытую абонентскую группу), такую что только мобильные станции в разрешенной группе могут иметь доступ к HNB и пользоваться услугами.

CSG подробно описана ниже со ссылкой на фиг. 1.

Система мобильной связи третьего поколения, показанная на фиг. 1, включает в себя HNB 20, шлюз (шлюз GW домашнего узла B; далее сокращенно HNB-GW) 30 базовой фемто-станции, станцию (центр коммутации мобильной связи; далее сокращенно MSC) 40 коммутации каналов, станцию (обслуживающий узел поддержки GPRS; далее сокращенно SGSN) 50 коммутации пакетов и мобильные станции 10-1 и 10-2 третьего поколения.

На фиг. 1 мобильная станция 10-1 из числа мобильных станций 10-1 и 10-2, находящихся в области, подчиненной узлу HNB 20, является авторизованной мобильной станцией. С другой стороны, мобильная станция 10-2 является мобильной станцией, которая стремится принимать услуги посредством HNB 20 неавторизованным образом, и далее эту станцию называют неавторизованной мобильной станцией 10-2. В случае, когда мобильная станция себя не идентифицирует, такая мобильная станция будет называться мобильной станцией 10.

HNB 20 соединен с базовой сетью оператора через HNB-GW 30.

Базовая сеть, которая является устройством базовой сети, включает в себя MSC 40, который управляет коммутацией каналов, и SGSN 50, который управляет коммутацией пакетов.

Если HNB 20 поддерживает функцию CSG, то HNB 20 сообщает мобильной станции 10, находящейся в области, подчиненной узлу HNB 20, идентификатор CSG (идентификационный номер CSG) собственной соты CSG.

Мобильная станция 10-1 декодирует идентификатор CSG, сообщенный от HNB 20, и определяет, включен ли этот идентификатор группы CSG в состав списка CSG, включенный в состав мобильной станции 10-1.

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

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

Этот механизм разрешает доступ к HNB 20 только выбранной мобильной станции 10-1 с идентификатором соты CSG узла HNB 20.

Однако может иметь место случай, когда возможно принимать услугу неавторизованным путем в изначально недоступной соте CSG узла HNB 20, как и в случае неавторизованной мобильной станции 10-2, показанной на фиг. 1, даже если поддерживается функция CSG.

В таком случае MSC 40 или SGSN 50 проверяет IMSI (Международный идентификационный номер абонента мобильной связи) мобильной станции 10 и идентификатор CSG соты CSG, где находится мобильная станция 10, и тем самым выполняет регулировку доступа, регулирующую доступ от мобильной станции 10 к HNB 20 (3GPP TS25.467, версия 8.0.0, раздел 5.1.3).

С другой стороны, поскольку функция CSG была введена из Версии 8 проекта 3GPP, имели место случаи, когда мобильная станция 10-1 (до выпуска Версии 8) не поддерживала функцию CSG. Кроме того, имеют место случаи, когда функция CSG не поддерживается узлом HNB 20.

В этих случаях HNB 20 выполняет процедуру (3GPP TS24.008, версия 8.4.0) идентификации на мобильной станции 10-1, чтобы узнать IMSI мобильной станции 10-1. HNB 20 выполняет процедуру (3GPP TS25.469 версия 8.0.0) HNBAP (прикладная часть HNB): UE REGISTER REQUEST в HNB-GW 30, чтобы зарегистрировать мобильную станцию 10-1 в HNB-GW 30. Здесь HNB-GW 30 проверяет, доступен или нет IMSI мобильной станции 10-1 узлу HNB 20, и таким образом регулирует доступ.

Если HNB-GW 30 определяет, что мобильная станция 10-1 имеет доступ к HNB 20, HNB-GW 30 уведомляет HNB 20 о разрешении доступа посредством сообщения HNBAP: UE REGISTER ACCEPT. Соответственно, HNB 20 предоставляет обслуживание мобильной станции 10-1.

С другой стороны, если мобильная станция 10 является неавторизованной мобильной станцией 10-2, показанной на фиг. 1, IMSI неавторизованной мобильной станции 10-2 не будет зарегистрирован для доступа в CSG. Соответственно, HNB-GW 30 определяет, что неавторизованная мобильная станция 10-2 не может иметь доступ к HNB 20 и уведомляет HNB 20 о том, что доступ не может быть разрешен посредством сообщения HNBAP: UE REGISTER REJECT. На этом завершается соединение RRC (управление радиоресурсами) между неавторизованной мобильной станцией 10-2 и HNB 20 (3GPP TS25.467, версия 8.0.0, раздел 5.1.2).

Как было описано выше, в случае предоставления обслуживания посредством HNB 20, если неавторизованная мобильная станция 10-2, доступ которой к HNB 20 не разрешен, порождает вызов, то сеть мобильной связи отклоняет доступ к HNB 20 в процессе установления сигнала, поскольку MSC 40, SGSN 50 или HNB-GW 30 регулирует доступ на основе IMSI мобильной станции 10.

С другой стороны, стандарты 3GPP указывают, что породить вызов может даже мобильная станция 10, у которой изначально нет доступа к HNB 20, если тип вызова является экстренным вызовом (3GPP TS22.011, версия 8.6.0, раздел 8.5.1).

Если тип вызова является экстренным вызовом, то мобильная станция 10-1 устанавливает значение «Экстренный вызов» для параметра «Причина установления», который представляет причину запроса установления в сообщении RRC: RRC CONNECTION REQUEST или RRC: INITIAL DIRECT TRANSFER, подлежащем передаче на HNB 20 по запросу установления соединения RRC или по запросу установления соединения для сигнализации (3GPP TS25.331, версия 8.5.0, раздел 10.3.3.11, патентная литература 1).

Затем HNB 20 устанавливает значение «Экстренный вызов» параметра «Причина регистрации» в сообщении HNBAP: UE REGISTER REQUEST, подлежащем передаче на HNB-GW 30.

Если параметр «Причина регистрации» имеет значение «Экстренный вызов», то HNB-GW 30 не осуществляет регулировку доступа на основе IMSI (3GPP TS25.467, версия 8.0.0, раздел 5.1.2).

Этот способ позволяет мобильной станции 10, которая изначально не имеет возможности доступа к HNB 20, избежать регулировки доступа шлюза HNB-GW 30 и получить доступ к HNB 20, если тип вызова является экстренным вызовом.

Здесь на фиг. 2 показана конфигурация сообщения RRC: RRC CONNECTION REQUEST; на фиг. 3 показана конфигурация сообщения RRC: INITIAL DIRECT TRANSFER; на фиг. 4 показана конфигурация параметра «Причина установления» протокола RRC; на фиг. 5 показана конфигурация сообщения HNBAP: UE REGISTER REQUEST; а на фиг. 6 показана конфигурация параметра «Причина регистрации» протокола HBNAP.

Список ссылок

Патентная литература

Патентная литература 1: JP 2003-244284A

Сущность изобретения

Техническая проблема

Вышеупомянутый способ позволяет избежать регулировки доступа шлюза HNB-GW 30 и разрешает мобильной станции 10 получить доступ к HNB 20, если мобильная станция 10 породила вызов в виде экстренного вызова.

Таким образом, это дает возможность даже мобильной станции 10, которая изначально не могла получить доступ к HNB 20, например, неавторизованной мобильной станции 10-2, получить доступ к HNB 20 посредством ложного представления параметра «Причина установления» в протоколе RRC как «Экстренный вызов» и путем отказа от регулировки доступа шлюза HNB-GW 30.

Считается, что такая неавторизованная мобильная станция 10-2 может быть легко создана посредством модификации программного обеспечения, с тем чтобы фальсифицировать единственный параметр - «Причину установления».

Зато имеет место случай, когда между авторизованной мобильной станцией 10-1 и HNB 20 существует устройство, которое декодирует сообщение RRC: RRC CONNECTION REQUEST, подлежащее передаче от авторизованной мобильной станции 10-1 в общий канал (RACH: канал произвольного доступа), причем это сообщение не маскируется или не подвергается мерам против фальсификации; заменяет параметр «Причина установления» на «Экстренный вызов»; кодирует сообщение RRC: RRC CONNECTION REQUEST и передает его на HNB 20. В этом случае с авторизованной мобильной станцией 10-1 обращаются таким же образом, как обращаются с вышеупомянутой неавторизованной мобильной станцией 10-2.

Такая неавторизованная мобильная станция 10-2 вызывает следующие проблемы.

(1) Установленный дома или на предприятии HNB 20 используется неавторизованной мобильной станцией 10-2 неавторизованным образом.

(2) Неавторизованная мобильная станция 10-2 может воспользоваться услугой выставления счета, которая дешевле, чем обычная услуга выставления счета, посредством порождения вызова через HNB 20 неавторизованным образом.

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

Рассмотрен способ решения этих проблем, согласно которому, когда мобильная станция 10 породила вызов в качестве экстренного вызова, устройство базовой сети выполняет процесс разъединения вызова на мобильной станции 10. Для этого требуется, чтобы устройство базовой сети знало, что мобильная станция 10 породила вызов в виде экстренного вызова.

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

Вместо вышеизложенного, также рассмотрено, что HNB-GW 30 выполняет процесс разъединения вызова на мобильной станции 10, которая породила вызов в виде экстренного вызова. Для этого необходимо, чтобы HNB-GW 30 знал, является ли тип вызова, фактически порожденного мобильной станцией 10, экстренным вызовом или нет.

Однако в настоящей конфигурации HNB-GW не может знать тип вызова, в действительности порожденного мобильной станцией 10.

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

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

Решение проблемы

Согласно настоящему изобретению система мобильной связи включает в себя:

мобильную станцию;

базовую станцию, связанную беспроводно с мобильной станцией; и

шлюзовое устройство, соединенное с базовой станцией и базовой сетью,

причем базовая станция включает в себя:

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

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

причем шлюзовое устройство включает в себя:

первое приемное средство для приема сообщения о регистрации от базовой станции;

второе приемное средство для приема от базовой станции сообщения об установлении, относящегося к установлению экстренного вызова; и

средство проверки для проверки согласованности между сообщением о регистрации и сообщением об установлении.

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

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

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

средство проверки для проверки согласованности между сообщением о регистрации и сообщением об установлении.

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

мобильную станцию;

базовую станцию, связанную беспроводно с мобильной станцией; и

шлюзовое устройство, соединенное с базовой станцией и базовой сетью,

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

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

шлюзовое устройство принимает сообщение о регистрации от базовой станции,

шлюзовое устройство принимает от базовой станции сообщение об установлении, относящееся к установлению экстренного вызова;

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

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

прием от базовой станции сообщения о регистрации для регистрации мобильной станции в шлюзовом устройстве;

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

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

Преимущественные результаты изобретения

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

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

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

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

Краткое описание чертежей

Фиг. 1 является схемой, показывающей конфигурацию системы мобильной связи третьего поколения.

фиг. 2 является схемой, показывающей конфигурацию сообщения RRC CONNECTION REQUEST.

фиг. 3 является схемой, показывающей конфигурацию сообщения INITIAL DIRECT TRANSFER.

фиг. 4 является схемой, показывающей конфигурацию параметра «Причина установления».

фиг. 5 является схемой, показывающей конфигурацию сообщения UE REGISTER REQUEST.

фиг. 6 является схемой, показывающей конфигурацию параметра «Причина регистрации».

фиг. 7 является блок-схемой, показывающей конфигурацию HNB согласно первому примерному варианту осуществления.

фиг. 8 является блок-схемой, показывающей конфигурацию HNB-GW согласно первому примерному варианту осуществления.

фиг. 9 является блок-схемой, показывающей конфигурацию MSC согласно первому примерному варианту осуществления.

фиг. 10 является блок-схемой, показывающей конфигурацию SGSN согласно первому примерному варианту осуществления.

фиг. 11 является блок-схемой, показывающей конфигурацию HNB согласно второму примерному варианту осуществления.

фиг. 12 является блок-схемой, показывающей конфигурацию HNB-GW согласно второму примерному варианту осуществления.

фиг. 13 является блок-схемой, показывающей конфигурацию MSC согласно второму примерному варианту осуществления.

фиг. 14 является блок-схемой, показывающей конфигурацию SGSN согласно второму примерному варианту осуществления.

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

фиг. 16 является схемой, показывающей конфигурацию сообщения CM SERVICE REQUEST.

фиг. 17 является схемой, показывающей конфигурацию параметра «Тип услуги CM».

фиг. 18 является блок-схемой последовательности операций, показывающей процесс определения посредством HNB параметра «Причина регистрации».

фиг. 19 является схемой, показывающей конфигурацию сообщения INITIAL UE MESSAGE, куда был добавлен параметр «Причина экстренного вызова» согласно настоящему изобретению.

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

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

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

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

фиг. 24 является блок-схемой, показывающей конфигурацию HNB-GW согласно третьему примерному варианту осуществления.

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

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

фиг. 27 является схемой, показывающей конфигурацию HNB-GW согласно четвертому примерному варианту осуществления.

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

фиг. 29 является блок-схемой последовательности операций процесса определения параметра «Тип вызова» посредством MSC согласно четвертому примерному варианту осуществления.

фиг. 30 является схемой, показывающей конфигурацию сообщения COMMON ID согласно настоящему изобретению.

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

фиг. 32 является блок-схемой последовательности операций, показывающей процесс определения посредством SGSN параметра «Тип вызова» согласно четвертому примерному варианту осуществления.

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

фиг. 34 является схемой, показывающей конфигурацию сообщения DIRECT TRANSFER согласно настоящему изобретению.

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

фиг. 36 является схемой, показывающей конфигурацию сообщения RAB ASSIGNMENT REQUEST согласно настоящему изобретению.

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

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

фиг. 39 является схемой, показывающей параметр приоритета распределения/сохранения согласно седьмому примерному варианту осуществления.

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

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

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

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

Описание вариантов осуществления изобретения

Далее со ссылкой на чертежи описываются примерные варианты осуществления.

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

(Первый примерный вариант осуществления)

На фиг. с 7 по 10 показаны конфигурации HNB 20, HNB-GW 30, MSC 40 и SGSN 50 соответственно согласно этому примерному варианту осуществления.

Обратимся к фиг. 7, где HNB 20 согласно этому примерному варианту осуществления включает в себя: контроллер 21А, который включает в себя информацию, указывающую в сообщении Протокола RANAP (Часть сетевого приложения радиодоступа), что мобильная станция 10 породила вызов в виде экстренного вызова; и передатчик 22А, который передает на HNB-GW 30 сообщение протокола RANAP. Сообщение протокола RANAP является сообщением на прикладном уровне сети беспроводного доступа и включает в себя, например, функциональную возможность прозрачной пересылки в RAN сигнала CC/MM, подлежащего передаче и приему между UE (пользовательским оборудованием) и устройством базовой сети.

Обратимся к фиг. 8, где HNB-GW 30 согласно этому примерному варианту осуществления включает в себя: приемник 31А, который принимает от HNB 20 сообщение протокола RANAP; контроллер 32А, извлекающий сообщение протокола RANAP; и передатчик 33А, который передает сообщение протокола RANAP в MSC 40 или SGSN 50.

Обратимся к фиг. 9, где MSC 40 согласно этому примерному варианту осуществления включает в себя: приемник 41А, принимающий от HNB-GW 30 сообщение протокола RANAP; и контроллер 42А, который, если в состав сообщения протокола RANAP включена информация, указывающая, что мобильная станция 10 породила вызов в виде экстренного вызова, определяет, является ли тип вызова, который действительно порожден мобильной станцией 10, экстренным вызовом или нет, и выполняет процесс разъединения вызова, если тип не является экстренным вызовом.

Обратимся к фиг. 10, где SGSN 50 согласно этому примерному варианту осуществления включает в себя: приемник 51А, принимающий от HNB-GW 30 сообщение протокола RANAP; и контроллер 52А, который, если в состав сообщения протокола RANAP включена информация, указывающая, что мобильная станция 10 породила вызов в виде экстренного вызова, определяет, является ли тип вызова, который действительно порожден мобильной станцией 10, экстренным вызовом или нет, и выполняет процесс разъединения вызова, если тип не является экстренным вызовом.

Соответственно, в этом примерном варианте осуществления MSC 40 или SGSN 50 способен узнавать, что мобильная станция 10 породила вызов в виде экстренного вызова.

В результате, если мобильная станция 10 сфальсифицировала «Причину установления» и ложно представила вызов как экстренный вызов, то MSC 40 или SGSN 50 может выполнить на мобильной станции 10 процесс разъединения вызова. Соответственно, это может предотвратить неавторизованное использование услуги посредством HNB 20.

(Второй примерный вариант осуществления)

На фиг. 11 и 14 показаны конфигурации HNB 20, HNB-GW 30, MSC 40 и SGSN 50 соответственно согласно этому примерному варианту осуществления. Этот примерный вариант осуществления является примером, в котором конфигурации и функционирование узла HNB 20, шлюза HNB-GW 30, центра MSC 40 и узла SGSN 50 согласно первому примерному варианту осуществления, показанному на фиг. 7-10, представлены более подробно.

Обратимся к фиг. 11, где HNB 20 согласно этому примерному варианту осуществления включает в себя: передатчик/приемник 201А сигналов на и от мобильной станции; процессор 202А сообщений RUA (адаптация пользователя RANAP); передатчик/приемник 203А сигналов на и от HNB-GW; процессор 204А сообщений HNBAP; котроллер 205А вызовов; процессор 206А сообщений RRC; и процессор 207А сообщений RANAP.

На фиг. 11 процессор 202А сообщений RUA, процессор 204А сообщений HNBAP, котроллер 205А вызовов, процессор 206А сообщений RRC и процессор 207А сообщений RANAP образуют контроллер 21А, показанный на фиг. 7. Передатчик/приемник 203А сигналов на и от HNB-GW является примером передатчика 22А, показанного на фиг. 7.

Передатчик/приемник 201А сигналов на и от мобильной станции включает в себя в качестве функциональных возможностей передачи и приема сообщения протокола RRC на и от мобильной станции 10: функциональную возможность маскирования, маскирующую (кодирующую и декодирующую) сообщения; функциональную возможность подтверждения доставки сигнала, подтверждающую доставку сообщения; и функциональную возможность распределения сигнала, распределяющую сообщение.

Передатчик/приемник 203А сигналов на и от HNB-GW включает в себя в качестве функциональной возможности передачи и приема сообщения протокола HNBAP или сообщения протокола RUA на и от HNB-GW 30: функциональную возможность маскирования; функциональную возможность подтверждения доставки сигнала; и функциональную возможность распределения сигнала.

Процессор 206А сообщений RRC включает в себя: функциональную возможность кодирования сообщения протокола RRC, подлежащего передаче на мобильную станцию 10; и функциональную возможность декодирования сообщения протокола RRC, принятого от мобильной станции 10.

Процессор 204А сообщений HNBAP включает в себя: функциональную возможность кодирования сообщения протокола HNBAP, подлежащего передаче на HNB-GW 30; и функциональную возможность декодирования сообщения протокола HNBAP, принятого от HNB-GW 30.

Процессор 207А сообщений RANAP включает в себя: функциональную возможность кодирования сообщения RANAP, подлежащего передаче на HNB-GW 30; и функциональную возможность декодирования сообщения протокола RANAP, принятого от HNB-GW 30.

Протокол RUA служит для пересылки сообщения протокола RANAP. Процессор 202А сообщений RUA включает в себя: функциональную возможность кодирования сообщения протокола RUA, подлежащего передаче на HNB-GW 30; и функциональную возможность декодирования сообщения протокола RUA, принятого от HNB-GW 30.

Контроллер 205А вызовов инициирует различные процессы вызовов, такие как установление соединения RRC, установление однонаправленного канала и управление мобильностью на основе сообщения протокола RRC и сообщения протокола RANAP. Кроме того, контроллер 205А вызовов инициирует протокол HNBAP и выполняет процесс регистрации мобильной станции 10 в HNB-GW 30. Вышеописанные функциональные возможности, как правило, включены в состав контроллера вызовов, реализованного в HNB 20.

Вдобавок к этому, контроллер 205А вызовов включает в себя функциональную возможность установки значения «Причина экстренного вызова» сообщения протокола RANAP, подлежащего передаче на HNB-GW 30, на основе параметра «Причина регистрации» сообщения протокола HNBAP, принятого от HNB-GW 30, в качестве специальной функциональной возможности, характерной для этого примерного варианта осуществления.

Обратимся к фиг. 12, где HNB-GW 30 согласно этому примерному варианту осуществления включает в себя: передатчик/приемник 301А сигналов на и от HNB; процессор 302А сообщений RUA; передатчик/приемник 303А сигналов на и от SGSN; передатчик/приемник 304А сигналов на и от MSC; процессор 305А сообщений HNBAP; контроллер 306А вызовов; процессор 307А сообщений RANAP; и память 308А для хранения станционных данных.

На фиг. 12 процессор 302А сообщений RUA, процессор 305А сообщений HNBAP, контроллер 306А вызовов, процессор 307А сообщений RANAP и память 308А для хранения станционных данных образуют контроллер 32А, показанный на фиг. 8. Передатчик/приемник 301А сигналов на и от HNB является примером приемника 31А, показанного на фиг. 8. Передатчик/приемник 303А сигналов на и от узла SGSN и передатчик/приемник 304А сигналов на и от MSC являются примерами передатчика 33А, показанного на фиг. 8.

Передатчик/приемник 301А сигналов на и от HNB включает в себя в качестве функциональных возможностей для передачи и приема сообщения протокола RUA и сообщения протокола HNBAP на и от HNB 20: функциональную возможность маскирования и функциональную возможность подтверждения доставки сигнала.

Передатчик/приемник 304А сигналов на и от MSC включает в себя в качестве функциональных возможностей передачи и приема сообщения протокола RANAP на и от MSC 40: функциональную возможность управления последовательностью, управляющей последовательностью сообщений, и функциональную возможность подтверждения доставки.

Передатчик/приемник 303А сигналов на и от SGSN включает в себя в качестве функциональных возможностей передачи и приема сообщения протокола RANAP на и от SGSN 50: функциональную возможность подтверждения доставки и функциональную возможность управления последовательностью.

Процессор 305А сообщений HNBAP включает в себя: функциональную возможность кодирования сообщения протокола HNBAP, подлежащего передаче на HNB 20, и функциональную возможность декодирования сообщения протокола HNBAP, принятого от HNB 20.

Процессор 302А сообщений RUA включает в себя: функциональную возможность кодирования сообщения протокола RUA, подлежащего передаче на HNB 20, и функциональную возможность декодирования сообщения протокола RUA, принятого от HNB 20.

Процессор 307А сообщений RANAP включает в себя: функциональную возможность кодирования сообщения протокола RANAP, подлежащего передаче в MSC 40, и функциональную возможность декодирования сообщения протокола RANAP, принятого из MSC 40.

Контроллер 306А вызовов выполняет процесс регистрации HNB 103 и процесс регистрации мобильной станции 10. Контроллер 306А вызовов выполнен с возможностью доступа к данным станции, хранящимся в памяти 308А для хранения станционных данных. В станционных данных установлен список доступных IMSI для каждой CSG. HNB-GW 30 регулирует доступ к HNB 20 на основе этого списка IMSI. Вышеописанные функциональные возможности, как правило, включены в состав контроллера вызовов, реализованного в HNB-GW 30.

Обратимся к фиг. 13, где MSC 40 согласно этому примерному варианту осуществления включает в себя: передатчик/приемник 401А сигналов на и от HNB-GW; процессор 402А сообщений RANAP; процессор 403А сообщений NAS (уровня, не связанного с предоставлением доступа); контроллер 404А вызовов и память 405А для хранения станционных данных.

На фиг. 13 процессор 402А сообщений RANAP, процессор 403А сообщений NAS, контроллер 404А вызовов и память 405А для хранения станционных данных образуют контроллер 42А, показанный на фиг. 9. Передатчик/приемник 401А сигналов на и от HNB-GW является примером приемника 41А, показанного на фиг. 9.

Передатчик/приемник 401А сигналов на и от HNB-GW включает в себя в качестве функциональных возможностей передачи и приема сообщения протокола RANAP на и от HNB-GW 30: функциональную возможность подтверждения доставки и функциональную возможность управления последовательностью.

Процессор 402А сообщений протокола RANAP включает в себя: функциональную возможность кодирования сообщения RANAP, подлежащего передаче на HNB-GW 30, и функциональную возможность декодирования сообщения протокола RANAP, принятого от HNB-GW 30.

Процессор 403А сообщений NAS включает в себя функциональную возможность передачи и приема сообщения протокола NAS (протокола CC (управления вызовами) и протокола ММ (управления мобильностью)) на и от мобильной станции 10.

Контроллер 404А вызовов включает в себя: обработку вызовов функциональной возможности, выполняющей процессы вызова, такие как установление вызова и разъединение вызова; функциональную возможность управления мобильностью, выполняющую управление мобильностью, например, регистрацию местоположения и передачу управления; и дополнительно функциональную возможность регулировки доступа, регулирующую доступ к HNB 20. Контроллер 404А вызовов выполнен с возможностью доступа к станционным данным, хранящимся в памяти 405А для хранения станционных данных. В станционных данных список доступных IMSI установлен для каждой CSG. MSC 40 регулирует доступ к HNB 20 на основе этого списка IMSI. Вышеописанная функциональная возможность, как правило, включена в состав контроллера вызовов, реализованного в MSC 40.

Вдобавок к этому, контроллер 404А вызовов включает в себя в качестве функциональной возможности, специфической для этого примерного варианта осуществления: функциональную возможность анализа сообщения NAS и определения того, является ли тип вызова, который порожден мобильной станцией 10, экстренным вызовом или нет, когда в сообщении протокола RANAP, принятом от HNB-GW 30, установлен параметр «Причина экстренного вызова». Если вызов не является экстренным вызовом, то контроллер 404А вызовов выполняет процесс разъединения вызова.

Обратимся к фиг. 14, где SGSN 50 согласно этому примерному варианту осуществления включает в себя: передатчик/приемник 501А сигналов на и от HNB-GW; процессор 502А сообщений RANAP; процессор 503А сообщений NAS; контроллер 504А вызовов и память 505А для хранения станционных данных.

На фиг. 14 процессор 502А сообщений RANAP, процессор 503А сообщений NAS, контроллер 504А вызовов и память 505А для хранения станционных данных образуют контроллер 52А, показанный на фиг. Передатчик/приемник 501А сигналов на и от HNB-GW является примером приемника 51А, показанного на фиг. 10.

Передатчик/приемник 501А сигналов на и от HNB-GW включает в себя в качестве функциональных возможностей передачи и приема сообщения протокола RANAP на и от HNB-GW 30: функциональную возможность подтверждения доставки и функциональную возможность управления последовательностью.

Процессор 502А сообщений RANAP включает в себя: функциональную возможность кодирования сообщения RANAP, подлежащего передаче на HNB-GW 30, и функциональную возможность декодирования сообщения протокола RANAP, принятого от HNB-GW 30.

Процессор 503А сообщений NAS включает в себя функциональную возможность передачи и приема сообщения протокола NAS (протокола СС и протокола ММ) на и от мобильной станции 10.

Контроллер 504А вызовов включает в себя: функциональную возможность обработки вызовов, функциональную возможность управления мобильностью, и дополнительно функциональную возможность регулировки доступа. Контроллер 504А вызовов выполнен с возможностью доступа к станционным данным, хранящимся в памяти 505А для хранения станционных данных. В станционных данных для каждой CSG установлен список доступных IMSI. SGSN 50 регулирует доступ к HNB 20 на основе этого списка IMSI. Вышеописанные функциональные возможности, как правило, включены в состав контроллера вызовов, реализованного в SGSN 50.

Вдобавок к этому, контроллер 504А вызовов в качестве функциональной возможности, характерной для этого примерного варианта осуществления, включает в себя функциональную возможность анализа сообщения NAS и определения, является ли вызов, который порожден мобильной станцией 10, экстренным вызовом или нет, когда в сообщении протокола RANAP, принятом от HNB-GW 30, установлен параметр «Причина экстренного вызова». Если вызов не является экстренным вызовом, то контроллер 504А вызовов выполняет процесс разъединения вызова.

Далее описывается функционирование системы мобильной связи согласно этому примерному варианту осуществления.

(А) Случай вызова с коммутацией каналов

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

Обратимся к фиг. 15, где мобильная станция 10 на этапе S101 устанавливает параметр «Причина установления» (фиг. 4) в виде сообщения RRC: RRC CONNECTION REQUEST (фиг. 2); и на этапе S102 передает сообщение RRC: RRC CONNECTION REQUEST на HNB 20.

После установления беспроводных ресурсов HNB 20 на этапе S103 уведомляет об этом мобильную станцию 10 посредством сообщения RRC: RRC CONNECTION SETUP.

После установления соединения RRC на этапе S104 мобильная станция 10 уведомляет об этом HNB 20 посредством сообщения RRC: RRC CONNECTION SETUP COMPLETE.

После этого мобильная станция 10 на этапе S105 устанавливает параметру «Тип услуги СМ» (фиг. 17) сообщения CM SERVICE REQUEST (фиг. 16), которое является сообщением протокола MM значение «Установление экстренного вызова» и включает сообщение CM SERVICE REQUEST в состав сообщения RRC:INITIAL DIRECT TRANSFER (фиг. 3).

Кроме того, на этапе S106 мобильная станция 10 устанавливает параметру «Причина установления» (фиг. 4) сообщения RRC:INITIAL DIRECT TRANSFER значение «Экстренный вызов», и передает сообщение RRC:INITIAL DIRECT TRANSFER (фиг. 3) на HNB 20.

В HNB 20 процессор 707А сообщений протокола RRC декодирует сообщение RRC: RRC CONNECTION REQUEST, переданное на этапе S102, и сообщение RRC:INITIAL DIRECT TRANSFER, переданное на этапе S106.

Кроме этого, контроллер 205А вызовов в HNB 20 хранит значение «Причина установления» (фиг. 4), переданное от мобильной станции 10, посредством сообщения RRC: RRC CONNECTION REQUEST и сообщения RRC: INITIAL DIRECT TRANSFER; и на этапе S107 определяет параметр «Причина регистрации» на основе значения «Причина установления» и устанавливает этот параметр в сообщении HNBAP: UE REGISTER REQUEST (фиг. 5)

На фиг. 18 показана блок-схема последовательности операций процесса определения параметра «Причина регистрации».

Обратимся к фиг. 18, где контроллер 205А вызовов на этапе S201 определяет, является ли значение «Причина установления» значением «Экстренный вызов» или нет; и когда это значение является значением «Экстренный вызов», контроллер 205А на этапе S202 определяет параметру «Причина регистрации» значение «Экстренный вызов», а когда это значение не является значением «Экстренный вызов», контроллер 205А на этапе S203 определяет, что параметр «Причина регистрации» является значением «Нормальный вызов».

Обратимся снова к фиг. 15, где HNB 20 на этапе S108 передает на HNB-GW 30 сообщение HNBAP: UE REGISTER REQUEST (фиг. 5), установленное с параметром «Причина регистрации».

В HNB-GW 30 передатчик/приемник 301А сигналов на и от HNB принимает сообщение HNBAP: UE REGISTER REQUEST. Процессор 305А сообщений HNBAP декодирует сообщение HNBAP: UE REGISTER REQUEST. На этапе S109 контроллер 306А вызовов определяет, выполнять или нет регулировку доступа (этап S110), на основе параметра «Причина регистрации», установленного в сообщении HNBAP: UE REGISTER REQUEST.

Если параметр «Причина регистрации» является значением «Экстренный вызов», то HNB-GW 30 не регулирует доступ. В этом случае контроллер 306А вызовов присваивает используемой мобильной станции 10 контекстный ID (идентификатор); процессор 305А сообщений HNBAP кодирует сообщение HNBAP: UE REGISTER ACCEPT; и на этапе S111 передатчик/приемник 301А сигналов на и от HNB передает на HNB 20 сообщение HNBAP: UE REGISTER ACCEPT.

В HNB 20 после приема сообщения HNBAP: UE REGISTER ACCEPT контроллер 205А вызовов на этапе S112 определяет, является ли параметр «Причина регистрации» значением «Экстренный вызов» или нет; если этот параметр является значением «Экстренный вызов», то на этапе S112 контроллер 205А вызовов генерирует параметр «Причина экстренного вызова», который введен в настоящем изобретении (фиг. 19). Процессор 207а сообщений RANAP кодирует сообщение RANAP: INITIAL UE MESSAGE, включая параметр «Причина экстренного вызова». Кроме того, процессор 207А сообщения RANAP устанавливает параметр NAS-PDU (протокольный блок данных) в сообщение RANAP: INITIAL UE MESSAGE и устанавливает сообщение CM SERVICE REQUEST протокола ММ, принятое от мобильной станции 10 в параметр NAS-PDU. Процессор 703А сообщений RUA генерирует сообщение RUA: CONNECT, включающее в себя сообщение RANAP: INITIAL UE MESSAGE. То есть на этапе S114 сообщение RANAP: INITIAL UE MESSAGE передается от HNB 20 на HNB-GW 30 посредством сообщения RUA: CONNECT.

В HNB-GW 30 процессор 302А сообщений RUA декодирует сообщение CONNECT протокола RUA. Контроллер 306А вызовов извлекает сообщение RANAP: INITIAL UE MESSAGE, которое уже было закодировано в HNB 20. На этапе S115 процессор 307А сообщений RANAP передает в MSC 40 сообщение RANAP: INITIAL UE MESSAGE на основе информации о маршрутизации, такой как ID домена CN.

В MSC 40 процессор 402А сообщений RANAP декодирует сообщение RANAP: INITIAL UE MESSAGE. Кроме того, процессор 403А сообщений NAS декодирует сообщение CM SERVICE REQUEST, установленное в NAS-PDU. Эти декодированные результаты сообщаются контроллеру 404А вызовов. На этапе S116 контроллер 404А вызовов определяет, установлен ли параметр «Причина экстренного вызова», который введен в настоящем изобретении, или нет. Если параметр «Причина экстренного вызова» установлен, то на этапе S117 контроллер 404А вызовов инициирует процесс противодействия мошенничеству, предусмотренный для услуги CS (коммутация каналов).

На фиг. 20 показана блок-схема последовательности операций процесса противодействия мошенничеству, предусмотренного для услуги CS.

Обратимся к фиг. 20, где на этапе S301 контроллер 404А вызовов проверяет, является ли параметр «Тип услуги CM» (TS24.008, версия 8.5.0, раздел 10.5.3.3), установленный в сообщении CM SERVICE REQUEST (TS24.008, версия 8.5.0, раздел 9.2.9) протокола ММ, переданного от мобильной станции 10, значением «Установление экстренного вызова» или нет.

Далее на этапе S302 контроллер 404А вызовов проверяет, является ли телефонный номер (TS24.008, версия 8.5.0, раздел 10.5.4.7) сообщения SETUP (TS24.008, версия 8.5.0, раздел 9.3.23 «Установка») протокола СС, который является исходящим сигналом, переданным из MSC, номером экстренных служб или нет. В частности, на фиг. 10.5.91/3GPP TS24.008 цифра 1, цифра 2, цифра 3 и т.п. информационного элемента вызываемой стороны TS24.008, версия 8.5.0 в BCD (двоично-десятичном коде) соответствуют телефонному номеру. Выполняют проверку, чтобы определить, являются ли эти телефонные номера номерами экстренных служб или нет. Число BCD вызываемой стороны в разделе 10.5.4.7 TS24.008 указывает входящий номер. BCD (двоично-десятичное число) является формой представления численного значения в компьютере и указывает, что одну цифру в десятичном исчислении представляют в виде четырех двоичных чисел, каждое из которых представляет одну цифру от 0 до 9.

Далее на этапе S303 контроллер 404А вызовов проверяет, выполнена ли на мобильной станции 10 процедура EMERGENCY SETUP (TS24.008, версия 8.5.0, раздел 9.3.8) или нет. Например, при приеме от мобильной станции 10 сообщения для инициирования «Установление экстренного вызова» контроллер 404А вызовов проверяет исходя из информационного элемента «Тип сообщения установки экстренного вызова», выполнена ли процедура EMERGENCY SETUP или нет.

Если любая из проверок на этапах S301-S303 увенчалась успехом, то контроллер 404А вызовов определяет, что тип вызова является экстренным вызовом, и продолжает процесс вызова для экстренного вызова. С другой стороны, если ни одна из проверок не увенчалась успехом, то на этапе S304 контроллер 404А вызовов определяет, что тип вызова является нормальным вызовом, определяет, что это неавторизованная мобильная станция 10-2, и инициирует процесс разъединения вызова.

Это может предотвратить ситуацию, когда неавторизованная мобильная станция 10-2, исходно не имеющая доступа к HNB 20, фальсифицирует «Причину установления», ложным образом представляя вызов как экстренный вызов, и пользуется услугами посредством HNB 20.

(В) Случай вызова с коммутацией пакетов

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

Последовательность функционирования случая вызова с коммутацией пакетов такая же, как и в вышеописанном случае, за исключением того, что процессы, выполняемые в MSC 40, в случае вызова с коммутацией каналов, теперь выполняются в SGSN 50. Однако при коммутации пакетов в качестве сообщений NAS применяются сообщение протокола SM (управление сессией) и сообщение протокола GMM (управление мобильностью GPRS). Соответственно, процессом противодействия мошенничеству, инициированным на этапе S117, является процесс противодействия мошенничеству, предусмотренный для услуги PS (коммутация пакетов). Способ в этом процессе для идентификации экстренного вызова отличается от способа в услуге CS. Кроме того, в случае использования аудио для коммутации пакетов используют способ VoIP (передача речи по IP). GMM является протоколом для управления мобильностью в услуге пакетной передачи (PS).

На фиг. 21 показана блок-схема последовательности операций процесса противодействия мошенничеству, предусмотренного для услуги PS.

Обратимся к фиг. 21, где на этапе S401 контроллер 504А вызовов узла SGSN 50 проверяет, является ли APN (имя точки доступа) (3GPP TS24.008 9.5.1 10.5.6.1), установленное в сообщении запроса активированного контекста PDP (Протокол пакетных данных) (3GPP TS24.008, версия 8.5.0, раздел 9.5.1) протокола SM, переданного от мобильной станции 10, специфическим для экстренного вызова или нет.

Далее на этапе S402 контроллер 504А вызовов проверяет, является ли процедура GMM, выполненная на мобильной станции 10, процедурой «Приписывание статуса экстренности» (TR23.869, версия 9.0.0) или нет.

Далее на этапе S403 контроллер 504 вызовов проверяет, является ли контекст PDP, активированный в SGSN 50, контекстом PDP, предусмотренным для экстренного вызова или нет. Например, контроллер 504А вызовов проверяет, является ли контекст PDP, активированный в SGSN 50, экстренным контекстом PDP в TR23.869, версия 9.0.0 или нет.

Если любая из проверок на этапах S401-S403 оказывается успешной, контроллер 504А вызовов определяет, что тип вызова является экстренным вызовом, и продолжает процесс вызова для экстренного вызова. С другой стороны, если все указанные проверки оказываются безуспешными, то на этапе S504 контроллер 504А вызовов определяет, что тип вызова является нормальным вызовом, определяет, что это неавторизованная мобильная станция 10-2, и инициирует процесс разъединения вызова.

Также в случае VoIP с коммутацией пакетов можно предотвратить ситуацию, когда неавторизованная мобильная станция 10-2, которая исходно не имеет доступа к HNB 20, фальсифицирует «Причину установления», ложным образом представляя вызов как экстренный вызов, и использует услугу посредством HNB 20.

(Третий примерный вариант осуществления)

На фиг. 22-24 показаны конфигурации MSC 40, SGSN 50 и HNB-GW 30 согласно этому примерному варианту осуществления соответственно.

Обратимся к фиг. 22, где MSC 40 согласно этому примерному варианту осуществления включает в себя: контроллер 41В, который определяет, является ли тип вызова, который в действительности порожден мобильной станцией 10, экстренным вызовом или нет, и включает в себя информацию, представляющую, что тип вызова является экстренным вызовом в сообщении протокола RANAP; и передатчик 42В, который передает сообщение протокола RANAP в HNB-GW 30.

Обратимся к фиг. 23, где SGSN 50 согласно этому примерному варианту осуществления включает в себя: контроллер 51В, который определяет, является ли тип вызова, который в действительности порожден мобильной станцией 10, экстренным вызовом или нет, и включает в себя информацию, представляющую, что тип вызова является экстренным вызовом в сообщении протокола RANAP; и передатчик 52В, который передает сообщение протокола RANAP на HNB-GW 30.

Обратимся к фиг. 24, где HNB-GW 30 согласно этому примерному варианту осуществления включает в себя: приемник 31В, который принимает сообщение протокола RANAP из MSC 40 или от SGSN 50, и контроллер 32В, который выполняет процесс разъединения вызова, когда в состав сообщения протокола RANAP включена информация, представляющая, что тип вызова является экстренным вызовом.

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

В результате, когда мобильная станция 10 фальсифицировала «Причину установления» и ложным образом представила вызов как экстренный вызов, HNB-GW 30 может выполнить процесс разъединения вызова на мобильной станции 10. Соответственно, это может предотвратить использование неавторизованным образом услуги посредством HNB 20.

(Четвертый примерный вариант осуществления)

На фиг. 25-27 показаны конфигурации MSC 40, SGSN 50 и HNB-GW 30 согласно этому примерному варианту осуществления соответственно. Этот примерный вариант осуществления является примером, в котором конфигурации и принципы действия MSC 40, SGSN 50 и HNB-GW 30 согласно третьему примерному варианту осуществления на фиг. 22-24 представлены более детально.

Обратимся к фиг. 25, где MSC 40 согласно этому примерному варианту осуществления включает в себя: передатчик/приемник 401В сигналов на и от HNB-GW 30; процессор 402В сообщений RANAP; процессор 403В сообщений NAS; контроллер 404В вызовов и память 405В для хранения станционных данных.

На фиг. 25 процессор 402В сообщений RANAP, процессор 403В сообщений NAS, контроллер 404В вызовов и память 405В для хранения станционных данных образуют контроллер 41В, показанный на фиг. 22. Передатчик/приемник 401В сигналов на и от HNB-GW является примером передатчика 42В, показанного на фиг. 22.

Передатчик/приемник 401В сигналов на и от HNB-GW, процессор 402В сообщений RANAP, процессор 403В сообщений NAS и память 405В для хранения станционных данных включают в себя функциональные возможности, аналогичные функциональным возможностям передатчика/приемника 401А сигналов на и от HNB-GW, процессора 402А сообщений RANAP, процессора 403А сообщений NAS и памяти 405А для хранения станционных данных, показанных на фиг. 13, соответственно.

Контроллер 404В вызовов включает в себя функциональную возможность, как правило, включенную в состав контроллера вызовов, реализованного в MSC 40, как и контроллер 404А вызовов, показанный на фиг. 13.

Вдобавок к этому, контроллер 404В вызовов включает в себя, в качестве функциональной возможности, характерной для этого примерного варианта осуществления, функциональную возможность анализа сообщения NAS, определения того, является ли тип вызова, в действительности порожденного мобильной станцией 10, экстренным вызовом или нет, и установки параметра «Тип вызова» сообщения протокола RANAP, подлежащего передаче на HNB-GW 30, на основе определенного результата.

Обратимся к фиг. 26, где SWGSN 50 согласно этому примерному варианту осуществления включает в себя: передатчик/приемник 501В сигналов на и от HNB-GW; процессор 502В сообщений RANAP, процессор 503В сообщений NAS; контроллер 504В вызовов и память 505В для хранения станционных данных.

На фиг. 26 процессор 502В сообщений RANAP, процессор 503В сообщений NAS; контроллер 504В вызовов и память 505В для хранения станционных данных образуют контроллер 51В, показанный на фиг. 23. Передатчик/приемник 301А сигналов на и от HNB-GW является примером передатчика 52В, показанного на фиг. 23.

Передатчик/приемник 501В сигналов на и от HNB-GW, процессор 502В сообщений RANAP, процессор 503В сообщений NAS и память 505В для хранения станционных данных включают в себя функциональные возможности, аналогичные функциональным возможностям передатчика/приемника 501А сигналов на и от HNB-GW, процессора 502А сообщений RANAP, процессора 503А сообщений NAS и памяти 505А для хранения станционных данных, показанные на фиг. 14, соответственно.

Контроллер 504В вызовов включает в себя функциональную возможность, как правило, включенную в состав контроллера, реализованного в SGSN 50, как и контроллер 504А вызовов, показанный на фиг. 14.

Вдобавок к этому, контроллер 504В вызовов включает в себя, в качестве функциональной возможности, характерной для этого примерного варианта осуществления, функциональную возможность анализа сообщения NAS, определения того, является ли тип вызова, в действительности порожденного мобильной станцией 10, экстренным вызовом или нет, и установки параметра «Тип вызова» сообщения протокола RANAP, подлежащего передаче на HNB-GW 30, на основе определенного результата.

Обратимся к фиг. 27, где HNB-GW 30 согласно этому примерному варианту осуществления включает в себя: передатчик/приемник 301В сигналов на и от HNB; процессор 302В сообщений RUA, передатчик/приемник 303B сигналов на и от SGSN; передатчик/приемник 304B сигналов на и от MSC, процессор 305В сообщений HNBAP; контроллер 306В вызовов; процессор 307В сообщений RANAP и память 308В для хранения станционных данных.

На фиг. 27 процессор 302В сообщений RUA, процессор 305В сообщений HNBAP, контроллер 306В вызовов, процессор 307В сообщений RANAP и память 308В для хранения станционных данных образуют контроллер 32B, показанный на фиг. 24. Передатчик/приемник 303В сигналов на и от SGSN и передатчик/приемник 304В сигналов на и от MSC являются примерами приемника 31В, показанного на фиг. 24.

Передатчик/приемник 301В сигналов на и от HNB, процессор 302В сообщений RUA, передатчик/приемник 303B сигналов на и от SGSN, передатчик/приемник 304B сигналов на и от MSC, процессор 305В сообщений HNBAP, процессор 307В сообщений RANAP и память 308В для хранения станционных данных включают в себя функциональные возможности, аналогичные функциональным возможностям передатчика/приемника 301А сигналов на и от HNB, процессора 302А сообщений RUA, передатчика/приемника 303А сигналов на и от SGSN, передатчика/приемника 304А сигналов на и от MSC, процессора 305А сообщений HNBAP, процессора 307А сообщений RANAP и памяти 308А для хранения станционных данных, показанных на фиг. 12 соответственно.

Контроллер 306В вызовов включает в себя функциональную возможность, как правило, включенную в состав контроллера вызовов, реализованного в HNB-GW 30, как и контроллер 306А вызовов, показанный на фиг. 12.

Вдобавок к этому, контроллер 306В вызовов включает в себя, в качестве функциональной возможности, характерной для этого примерного варианта осуществления, функциональную возможность, состоящую в том, что, когда параметру «Тип вызова» сообщения протокола RANAP, принятого от MSC 40 или SGSN 50, устанавливают значение «Нормальный вызов», контроллер 306В определяет, что тип вызова, порожденного мобильной станцией 10, является нормальным вызовом, и выполняет процесс разъединения вызова, если мобильная станция 10 породила этот вызов в виде экстренного вызова.

Конфигурация HNB 20 согласно этому примерному варианту осуществления может быть аналогична конфигурации на фиг. 9. Заметим, что контроллеру 205А вызовов узла HNB 20 необходимо иметь функциональную возможность, как правило, включенную в состав контроллера вызовов, реализованного в HNB 20.

Далее описываются функционирования системы мобильной связи согласно этому примерному варианту осуществления.

(1) Пример 1 функционирования

Этот пример функционирования является примером, в котором уведомление о результате определения типа вызова, определенного в MSC 40 или SGSN 50, осуществляется посредством сообщения COMMON ID протокола RANAP (3GPP TS25.413).

(1-А) Случай вызова с коммутацией каналов

Сначала с помощью схемы последовательности операций согласно фиг. 28 описывается пример функционирования согласно случаю, в котором MSC 40 уведомляет о результате определения типа вызова с коммутацией каналов посредством сообщения COMMON ID протокола RANAP. На фиг. 28 показано функционирование после завершения процесса, показанного на фиг. 15. Однако процессы на этапах S112, S113, S116 и S117, показанных на фиг. 15, не выполняются. Кроме того, параметр «Причина экстренного вызова» не включен в состав сообщения RANAP: INITIAL UE MESSAGE, переданного на этапах S114 и S115.

Как правило, как описано в 3GPP TS25.413, устройство базовой сети передает сообщение RANAP: COMMON ID на HNB-GW 30 после установления соединения для сигнализации.

Обратимся соответственно к фиг. 28, где на этапе S501 контроллер 404В вызовов в MSC 40 устанавливает соединение для сигнализации, а затем на этапе S502 инициирует процесс определения параметра «Тип вызова».

На фиг. 29 показана блок-схема последовательности операций процесса определения параметра «Тип вызова» в MSC 40.

Обратимся к фиг. 29, где на этапе S601 контроллер 404В вызовов проверяет, является ли параметр «Тип услуги СМ» (TS24.008, версия 8.5.0, раздел 10.5.3.3), установленный в сообщении CM SERVICE REQUEST (TS24.008, версия 8.5.0, раздел 9.2.9) протокола MM, переданного от мобильной станции 10, значением «Установление экстренного вызова» или нет.

Далее на этапе S602 контроллер 404В проверяет, является ли телефонный номер (TS24.008, версия 8.5.0, раздел 10.4.7) сообщения SETUP (TS24.008 9.3.23, версия 8.5.0, раздел установки) протокола СС, который является сигналом исходящего вызова, переданным посредством MSC 40, значением номера экстренной службы или нет. В частности, на фиг. 10.5.91/3GPP TS24.008 цифра 1, цифра 2, цифра 3 и т.п. информационного элемента вызываемой стороны TS24.008, версия 8.5.0 в BCD (двоично-десятичном коде) соответствуют телефонному номеру, и контроллер 404B вызовов проверяет, являются ли телефонные номера номерами экстренных служб или нет. Число BCD вызываемой стороны в разделе 10.5.4.7 TS24.008 указывает входящий номер. BCD является формой представления численного значения в компьютере и указывает, что одну цифру в десятичном исчислении представляют в виде четырех двоичных чисел, каждое из которых представляет одну цифру от 0 до 9.

Далее на этапе S603 контроллер 404В вызовов проверяет, была ли выполнена процедура EMERGENCY SETUP (TS24.008, версия 8.5.0, раздел 9.3.8) на мобильной станции 10 или нет. Например, при приеме сообщения для инициирования «Установление экстренного вызова» от мобильной станции 10 контроллер 404В вызовов проверяет, выполнена ли процедура EMERGENCY SETUP или нет, исходя из информационного элемента «Тип сообщения об установке экстренного вызова».

Если любая из проверок на этапах S601-S603 оказалась успешной, то на этапе S604 контроллер 404В вызовов определяет, что тип вызова является экстренным вызовом, и определяет, что параметр «Тип вызова» является «Нормальным вызовом». С другой стороны, если ни одна из проверок не оказалась успешной, то на этапе S605 контроллер 404В определяет, что тип вызова является нормальным вызовом, и определяет, что параметр «Тип вызова» является «Экстренным вызовом».

Вновь обратимся к фиг. 28, где на этапе S503 контроллер 404В вызовов в MSC 40 задает параметр «Тип вызова», если этот параметр типа вызова определен при передаче сообщения RANAP: COMMON ID на HNB-GW 30. На фиг. 30 показана конфигурация сообщения RANAP: COMMON ID согласно настоящему изобретению.

В HNB-GW 30 на этапе S504, если включен в состав параметр «Тип вызова» при приеме сообщения RANAP: COMMON ID, то на этапе S505 контроллер 306В вызовов сравнивает этот параметр с параметром «Причина регистрации» (фиг. 6) сообщения HNBAP: UE REGISTER REQUEST (фиг. 5), когда мобильная станция 10 осуществила доступ к HNB-GW 30.

На фиг. 31 представлена схема, показывающая таблицу для определения процесса в HNB-GW 30 согласно типу вызова согласно этому примерному варианту осуществления.

Например, в случае 2, показанном на фиг. 31, параметр «Тип вызова», который был сообщен посредством MSC 40, является «Нормальным вызовом», несмотря на то, что параметр «Причина регистрации» сообщения HNBAP: UE REGISTER REQUEST является «Экстренным вызовом». На этой основе HNB-GW 30 определяет, что мобильная станция 10 сфальсифицировала вызов как экстренный вызов и получила доступ к узлу HNB 20 неавторизованным образом, и выполняет процесс разъединения вызова.

Это может предотвратить ситуацию, когда неавторизованная мобильная станция 10-2, исходно не имеющая доступа к HNB 20, фальсифицирует «Причину установления», ложным образом представляя вызов как экстренный вызов, и пользуется услугами посредством HNB 20.

(1-В) Случай вызова с коммутацией пакетов

Далее описывается пример функционирования согласно случаю, в котором SGSN 50 сообщает результат определения типа вызова с коммутацией пакетов посредством сообщения COMMON ID протокола RANAP.

Последовательность операций согласно случаю вызова с коммутацией пакетов аналогична вышеописанному случаю, за исключением того, что процессы, выполняемые в MSC 40 в случае вызова с коммутацией каналов, выполняются в SGSN 50. Однако процесс определения параметра «Тип вызова», инициированного посредством S502, будет другим.

На фиг. 32 показана блок-схема последовательности операций процесса определения параметра «Тип вызова» в SGSN 50.

Обратимся к фиг. 32, где на этапе S701 контроллер 504В вызовов проверяет, является ли APN (3GPP TS24.008 9.5.1 10.5.6.1), установленное в сообщении с запросом активированного контекста PDP (3GPP TS24.008, версия 8.5.0, раздел 9.5.1), установленном в протоколе SM, переданном от мобильной станции 10, характерным для экстренного вызова или нет.

Далее на этапе S702 контроллер 504В вызовов проверяет, является ли процедура GMM, выполненная на мобильной станции 10, процедурой «Приписывание статуса экстренности» (TR23.869, версия 9.0.0) или нет.

Затем на этапе S703 контроллер 504В вызовов проверяет, является ли контекст PDP, активированный в SGSN 50, контекстом PDP, предусмотренным для экстренного вызова или нет. Например, контроллер 504В вызовов проверяет, является ли контекст PDP, активированный в SGSN 50, экстренным контекстом PDP согласно TR23.869, версия 9.0.0 или нет.

Если любая из проверок на этапах S701-S703 оказывается успешной, то на этапе S704 контроллер 504В вызовов определяет, что тип вызова является экстренным вызовом, и определяет, что параметр «Тип вызова» является «Нормальным вызовом». С другой стороны, если ни одна из проверок не оказалась успешной, то на этапе S705 контроллер 504В вызовов определяет, что тип вызова является нормальным вызовом, и определяет, что параметр «Тип вызова» является «Экстренным вызовом».

Когда на HNB-GW 30 передается сообщение RANAP: COMMON ID, и если определен параметр «Тип вызова», то контроллер 504В вызовов в SGSN 50 задает этот параметр «Тип вызова». Конфигурация сообщения RANAP: COMMON ID согласно настоящему изобретению является такой же, как и в случае MSC 40, как показано на фиг. 30.

Если параметр «Тип вызова» включен в состав, когда принимается сообщение RANAP: COMMON ID, то контроллер 306В вызовов в HNB-GW 30 сравнивает этот параметр с параметром «Причина регистрации» (фиг. 6) сообщения HNBAP: UE REGISTER REQUEST (фиг. 5), когда мобильная станция 10 осуществляет доступ к HNB-GW 30.

Например, в случае 2, показанном на фиг. 31, параметр «Тип вызова», о котором сообщил SGSN 50, является «Нормальным вызовом», несмотря на то что параметр «Причина регистрации» сообщения HNBAP: UE REGISTER REQUEST является «Экстренным вызовом». На основе этого HNB-GW 30 определяет, что мобильная станция ложным образом представляет этот вызов как экстренный вызов, и осуществляет доступ к HNB 20 неавторизованным образом, и выполняет процесс разъединения вызова.

Это может предотвратить ситуацию, когда неавторизованная мобильная станция 10-2, исходно не имеющая доступа к HNB 20, фальсифицирует «Причину установления», ложным образом представляя вызов как экстренный вызов, и пользуется услугами посредством HNB 20 даже в случае VoIP с коммутацией пакетов.

(2) Пример 2 функционирования

Этот пример функционирования является примером, когда уведомление о результате определения типа вызова в MSC 40 или SGSN 50 выполняется посредством сообщения DIRECT TRANSFER протокола RANAP (3GPP TS25.413).

(2-А) Случай вызова с коммутацией каналов

Сначала с помощью схемы последовательности операций (фиг. 33) описывается пример функционирования согласно случаю, в котором MSC 40 уведомляет о результате определения типа вызова с коммутацией каналов посредством сообщения DIRECT TRANSFER протокола RANAP. На фиг. 33 показано функционирование после завершения процесса, показанного на фиг. 15. Однако, процессы на этапах S112, S113, S116 и S117, показанных на фиг. 15, не выполняются. Кроме того, параметр «Причина экстренного вызова» не включен в состав сообщения RANAP: INITIAL UE MESSAGE, переданного на этапах S114 и S115.

Как правило, как описано в 3GPP TS25.413, когда устройство базовой сети передает сообщения NAS, например, по протоколу СС или протоколу ММ, устройство базовой сети передает на HNB-GW 30 сообщение RANAP: DIRECT TRANSFER.

Обратимся соответственно к фиг. 33, где на этапе S801 контроллер 404В вызовов в MSC 40 передает сообщение NAS, а затем на этапе S802 инициирует процесс определения параметра «Тип вызова». Процесс определения параметра «Тип вызова» в MSC 40 является таким же, как и в примере 1 функционирования и как описано на фиг. 29.

В MSC 40, когда контроллер 404В вызовов передает на HNB-GW 30 сообщение RANAP: DIRECT TRANSFER, и если определен параметр «Тип вызова», то на этапе S803 контроллер 404В вызовов задает этот параметр «Тип вызова». На фиг. 34 показана конфигурация сообщения RANAP: DIRECT TRANSFER согласно настоящему изобретению.

В HNB-GW 30 в случае, когда контроллер 306В вызовов принимает сообщение RANAP: DIRECT TRANSFER, и если на этапе S804 включен в состав параметр «Тип вызова», то на этапе S805 контроллер 306В вызовов сравнивает этот параметр с параметром «Причина регистрации» (фиг. 6) сообщения HNBAP: UE REGISTER REQUEST (фиг. 5), когда мобильная станция 10 осуществила доступ к HNB-GW 30.

Например, в случае 2, показанном на фиг. 31, параметр «Тип вызова», о котором уведомил MSC 40, является «Нормальным вызовом» несмотря на то, что параметр «Причина регистрации» сообщения HNBAP: UE REGISTER REQUEST является «Экстренным вызовом». На основе этого, HNB-GW 30 определяет, что мобильная станция 10 ложным образом представляет этот вызов в качестве экстренного вызова и осуществляет доступ к HNB 20 неавторизованным образом, и выполняет процесс разъединения вызова.

Это может предотвратить ситуацию, когда неавторизованная мобильная станция 10-2, исходно не имеющая права доступа к HNB 20, фальсифицирует «Причину установления», ложным образом представляя вызов как экстренный вызов, и пользуется услугами посредством HNB 20.

(1-В) Случай вызова с коммутацией пакетов

Далее описывается пример функционирования согласно случаю, когда SGSN 50 уведомляет о результате определения типа вызова с коммутацией пакетов посредством сообщения DIRECT TRANSFER протокола RANAP.

Последовательность операций случая вызова с коммутацией пакетов аналогична вышеописанному случаю, за исключением того, что процессы, выполняемые в MCS 40 в случае коммутации каналов, теперь выполняются в SGSN 50. Однако процесс определения параметра «Тип вызова», инициированный на этапе S802, будет другим. Процесс определения параметра «Тип вызова» в SGSN 50 является таким же, как и в примере 1 функционирования и как описано на фиг. 32.

В SGSN 50 в случае, когда контроллер 504В вызовов передает на HNB-GW 30 сообщение RANAP: DIRECT TRANSFER и если определен параметр «Тип вызова», то контроллер 504В вызовов устанавливает этот параметр «Тип вызова». Конфигурация сообщения RANAP: DIRECT TRANSFER согласно настоящему изобретению является такой же, как и в случае MSC 40 и как показано на фиг. 34.

В HNB-GW 30 в случае, когда контроллер 306В вызовов принимает сообщение RANAP: DIRECT TRANSFER, если включен в состав параметр «Тип вызова», то контроллер 306В вызовов сравнивает этот параметр с параметром «Причина регистрации» (фиг. 6) сообщения HNBAP: UE REGISTER REQUEST (фиг. 5), когда мобильная станция 10 осуществила доступ к HNB-GW 30.

Например, в случае 2, показанном на фиг. 31, параметр «Тип вызова», о котором уведомил SGSN 50, является «Нормальным вызовом», несмотря на то, что параметр «Причина регистрации» сообщения HNBAP: UE REGISTER REQUEST является «Экстренным вызовом». На основе этого, HNB-GW 30 определяет, что мобильная станция 10 ложным образом представляет этот вызов в качестве экстренного вызова и осуществляет доступ к HNB 20 неавторизованным образом, и тогда выполняет процесс разъединения вызова. Это может предотвратить ситуацию, когда неавторизованная мобильная станция 10-2, исходно не имеющая доступа к HNB 20, фальсифицирует «Причину установления», ложным образом представляя вызов как экстренный вызов, и пользуется услугами посредством HNB 20 даже в случае использования VoIP с коммутацией пакетов.

(3) Пример 3 функционирования

Этот пример функционирования является примером, когда уведомление о результате определения типа вызова в MSC 40 или SGSN 50 выполняется посредством сообщения RAB (однонаправленный канал радиодоступа) ASSIGNMENT REQUEST протокола RANAP (3GPP TS25.413).

(3-А) Случай вызова с коммутацией каналов

Сначала с помощью схемы последовательности операций (фиг. 35) описывается пример функционирования согласно случаю, в котором MSC 40 уведомляет о результате определения типа вызова с коммутацией каналов посредством сообщения RAB ASSIGNMENT REQUEST протокола RANAP. На фиг. 35 показано функционирование после завершения процесса, показанного на фиг. 15. Однако процессы на этапах S112, S113, S116 и S117, показанных на фиг. 15, не выполняются. Кроме того, параметр «Причина экстренного вызова» не включен в состав сообщения RANAP: INITIAL UE MESSAGE, переданного на этапах S114 и S115.

Как правило, как описано в 3GPP TS25.413, когда устройство базовой сети принимает от мобильной станции 10 запрос на установление вызова и устанавливает однонаправленный канал беспроводного доступа, устройство базовой сети передает на HNB-GW 30 сообщение RANAP: RAB ASSIGNMENT REQUEST.

Обратимся соответственно к фиг. 35, где на этапе S901 контроллер 404В вызовов в MSC 40 принимает от мобильной станции 10 запрос на установление вызова, а затем на этапе S902 определяет QoS (Качество обслуживания) для однонаправленного канала беспроводного доступа и затем на этапе S903 инициирует процесс определения параметра «Тип вызова». Процесс определения параметра «Тип вызова» в MSC 40 является таким же, как и в примере 1 функционирования, как описано на фиг. 29.

В MSC 40, когда на этапе S904 контроллер 404В вызовов передает на HNB-GW 30 сообщение RANAP: RAB ASSIGNMENT REQUEST, и если определен параметр «Тип вызова», то тогда контроллер 404В вызовов устанавливает этот параметр «Тип вызова». На фиг. 36 показана конфигурация сообщения RANAP: RAB ASSIGNMENT REQUEST согласно настоящему изобретению.

В HNB-GW 30 в случае, когда контроллер 306В вызовов принимает сообщение RANAP: RAB ASSIGNMENT REQUEST, и если на этапе S905 включен в состав параметр «Тип вызова», то на этапе S906 контроллер 306В вызовов сравнивает этот параметр с параметром «Причина регистрации» (фиг. 6) сообщения HNBAP: UE REGISTER REQUEST (фиг. 5), когда мобильная станция 10 осуществила доступ к HNB-GW 30.

Например, в случае 2, показанном на фиг. 31, параметр «Тип вызова», о котором уведомил центр MSC 40, является «Нормальным вызовом», несмотря на то, что параметр «Причина регистрации» сообщения HNBAP: UE REGISTER REQUEST является «Экстренным вызовом». На основе этого, HNB-GW 30 определяет, что мобильная станция 10 ложным образом представляет этот вызов в качестве экстренного вызова и осуществляет доступ к HNB 20 неавторизованным образом, и выполняет процесс разъединения вызова.

Это может предотвратить ситуацию, когда неавторизованная мобильная станция 10-2, исходно не имеющая доступа к HNB 20, фальсифицирует «Причину установления», ложным образом представляя вызов как экстренный вызов, и пользуется услугами посредством HNB 20.

(1-В) Случай вызова с коммутацией пакетов

Далее описывается пример функционирования согласно случаю, когда SGSN 50 уведомляет о результате определения типа вызова с коммутацией пакетов посредством сообщения RAB ASSIGNMENT REQUEST протокола RANAP.

Последовательность операций случая вызова с коммутацией пакетов аналогична вышеописанному случаю, за исключением того, что процессы, выполняемые в MCS 40 в случае коммутации каналов, теперь выполняются в SGSN 50. Однако процесс определения параметра «Тип вызова», инициированный на этапе S802, будет другим. Процесс определения параметра «Тип вызова» в SGSN 50 является таким же, как и в примере 1 функционирования, как описано на фиг. 32.

В SGSN 50 в случае, когда контроллер 504В вызовов передает на HNB-GW 30 сообщение RANAP: RAB ASSIGNMENT REQUEST и если определен параметр «Тип вызова», то контроллер 504В вызовов устанавливает этот параметр «Тип вызова». Конфигурация сообщения RANAP: RAB ASSIGNMENT REQUEST согласно настоящему изобретению является такой же, как и в случае MSC 40 и как показано на фиг. 36.

В HNB-GW 30 в том случае, когда контроллер 306В вызовов принимает сообщение RANAP: RAB ASSIGNMENT REQUEST, и если включен в состав параметр «Тип вызова», то контроллер 306В вызовов сравнивает этот параметр с параметром «Причина регистрации» (фиг. 6) сообщения HNBAP: UE REGISTER REQUEST (фиг. 5), когда мобильная станция 10 осуществила доступ к HNB-GW 30.

В случае 2, показанном на фиг. 31, параметр «Тип вызова», о котором уведомил SGSN 50 является «Нормальным вызовом», несмотря на то, что параметр «Причина регистрации» сообщения HNBAP: UE REGISTER REQUEST является «Экстренным вызовом». На основе этого, HNB-GW 30 определяет, что мобильная станция 10 ложным образом представляет этот вызов в качестве экстренного вызова и осуществляет доступ к HNB 20 неавторизованным образом, и выполняет процесс разъединения вызова.

Это может предотвратить ситуацию, когда неавторизованная мобильная станция 10-2, исходно не имеющая доступа к HNB 20, фальсифицирует «Причину установления», ложным образом представляя вызов как экстренный вызов, и пользуется услугами посредством HNB 20 даже в случае использования VoIP с коммутацией пакетов.

Способы, выполняемые в HNB 20, HNB-GW 30, MSC 40 и SGSN 50 настоящего изобретения, могут быть применены к программам, подлежащим исполнению посредством компьютера. Программа может храниться в запоминающей среде и может быть предоставлена внешним устройствам через сеть.

(Пятый примерный вариант осуществления)

Во втором примерном варианте осуществления процесс противодействия мошенничеству выполняется в MSC 40 или SGSN 50. Однако в этом примерном варианте осуществления процесс противодействия мошенничеству выполняется в HNB-GW 30.

На фиг. 37 показана последовательность операций в этом случае. На фиг. 37 показан случай, когда HNB-GW был заранее уведомлен о том, что «Причина регистрации» = «Экстренный вызов» в процедуре «Регистрация UE», и HNB-GW проверяет содержание сообщения NAS и инициирует процесс противодействия мошенничеству. Это соответствует случаю, в котором, когда MSC уведомлен шлюзом HNB-GW о том, что UE породило вызов в виде экстренного вызова (фиг. 15), MSC выполняет процесс проверки сообщения протокола ММ или СС на фиг. 20. Это соответствует случаю, в котором, когда HNB-GW указывает, что UE породило вызов в виде экстренного вызова, SGSN выполняет процесс проверки сообщения протокола GMM или SM (фиг. 21). Сообщение NAS указывает на уровень, не связанный с предоставлением доступа, и указывает протокол, на зависящий от системы беспроводного доступа.

Этот примерный вариант осуществления вызывает следующие преимущественные результаты.

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

По сравнению со вторым примерным вариантом осуществления нет необходимости в добавлении нового параметра в протокол RANAP. Это позволяет уменьшить размер сообщения протокола RANAP, а также позволяет сократить объем сигнализации, которая поддерживается между HNB-GW и MSC или SGSN.

HNB-GW способен узнавать, является ли вызов экстренным вызовом или нормальным вызовом, посредством быстрого просмотра сообщения NAS. Соответственно, HNB-GW способен поднять приоритет процедуры экстренного вызова выше приоритета нормального вызова в отношении распределения ресурсов и планирования трафика даже без уведомления о типе вызова со стороны MSC или SGSN.

(Шестой примерный вариант осуществления)

В пятом примерном варианте осуществления в случае, когда терминал породил вызов в виде экстренного вызова, HNB-GW быстро просматривает сообщение NAS и на его основе реализует процесс противодействия мошенничеству. В этом примерном варианте осуществления процесс противодействия мошенничеству выполняется в HNB. То есть, как показано на фиг. 38, HNB быстро просматривает сообщение NAS и инициирует процесс противодействия мошенничеству.

Этот примерный вариант осуществления вызывает следующие преимущественные результаты.

Поскольку HNB выполняет процесс противодействия мошенничеству, связь с неавторизованным терминалом может быть завершена быстрее, чем в случае, когда процесс противодействия мошенничеству выполняет устройство более высокого уровня. Это позволяет улучшить коэффициент использования сетевых ресурсов и позволяет уменьшить объем сигнализации между HNB и HNB-GW.

HNB способен распознать, является ли вызов экстренным или нормальным вызовом, посредством быстрого просмотра сообщения NAS. Соответственно, HNB способен повысить приоритет процедуры экстренного вызова по сравнению с нормальным вызовом в отношении распределения ресурсов и планирования трафика без уведомления о типе вызова со стороны MSC или SGSN.

(Седьмой примерный вариант осуществления)

В третьем примерном варианте осуществления MSC или SGSN сообщает шлюзу HNB-GW информацию об экстренном вызове, причем HNB-GW верифицирует, пыталось ли UE получить доступ в виде экстренного вызова или нет. В четвертом примерном варианте осуществления параметр «Типа вызова» используется в протоколе RANAP.

В этом примерном варианте осуществления применяется параметр, уже определенный в 3GPP TS25.413 в виде информации, представляющей экстренный вызов RANAP, и этот параметр называется «Приоритет распределения/сохранения» (смотри фиг. 39).

Способ использования параметра «Приоритет распределения/сохранения» хорошо известен как публично известный способ и не входит в объем настоящего изобретения. Например, этот способ используют для преимущественного права, согласно которому, когда не могут быть обеспечены ресурсы для распределения нового однонаправленного канала, выполняется разъединение другого однонаправленного канала, имеющего меньший приоритет, и освобождаются ресурсы, что позволяет новому однонаправленному каналу получить ресурсы.

В случае экстренного вызова MSC или SGSN устанавливает этот параметр «Приоритет распределения/сохранения» в сообщении RAB ASSIGNMENT REQUEST следующим образом.

Уровень приоритета = 1

Возможность преимущественного права = «преимущественное право можно инициировать»

Уязвимость преимущественного права = преимущественное право невозможно

В соответствии с такой установкой можно уведомить о том, что вызов должен быть установлен как экстренный вызов. Кроме того, можно использовать сообщение, отличное от сообщения RAB ASSIGNMENT REQUEST протокола RANAP. В этом случае логика установки параметра «Приоритет распределения/сохранения» в виде экстренного вызова в MSC или SGSN аналогична логике, показанной на фиг. 29 и 32, и является такой же, как на фиг. 40 и 41.

На фиг. 40 и 41 параметр «Приоритет распределения/сохранения» указывает на нормальный вызов. Однако в случае, когда значение «Причина регистрации» в процедуре «Регистрация UE» указывает на экстренный вызов, HNB-GW определяет, что UE фальсифицировало «Причину установления» и пыталось получить доступ, и выполняет разъединение вызова. На фиг. 41 показана последовательность операций для этого случая.

Этот примерный вариант осуществления вызывает следующие преимущественные результаты.

Выполняется уведомление о том, является ли вызов экстренным вызовом или нет, посредством использования существующего «Приоритета распределения/сохранения», в связи с чем отпадает необходимость соответствующей модификации в MSC или SGSN. Соответственно, не надо модифицировать уже эксплуатирующийся MSC или SGSN при внедрении фемто-решения. Это позволяет легко внедрить фемто-систему.

По сравнению с четвертым примерным вариантом осуществления, здесь нет необходимости в добавлении нового параметра в протокол RANAP. Это позволяет уменьшить размер сообщения протокола RANAP, а также позволяет уменьшить объем сигнализации между HNB-GW и MSC или SGSN.

(Восьмой примерный вариант осуществления)

В седьмом примерном варианте осуществления HNB-GW определяет параметр «Приоритет распределения/сохранения» и реализует процесс противодействия мошенничеству. Однако в этом примерном варианте осуществления этот процесс противодействия мошенничеству выполняется в HNB. То есть, как показано на фиг. 43, когда HNB принимает сообщение RAB ASSIGNMENT REQUEST протокола RANAP, HNB определяет «Приоритет распределения/сохранения»; в случае, когда определение указывает на нормальный вызов, и если «Причиной регистрации» в процедуре «Регистрация UE» является экстренный вызов, то HNB-GW определяет, что UE ложным образом представило «Причину установления» и попыталось получить доступ, и выполняет разъединение вызова.

В третьем и четвертом примерных вариантах осуществления HNB-GW выполняет процесс сравнения типа вызова, сообщенного от MSC или SGSN, с «Причиной регистрации», когда UE попыталось получить доступ друг к другу. Однако этот процесс сравнения может выполняться в HNB.

Данный примерный вариант осуществления вызывает следующие преимущественные результаты.

HNB-GW завершает сообщение протокола RANAP и устраняет необходимость определения типа вызова посредством использования «Приоритета распределения/сохранения». Это позволяет упростить процесс обработки в HNB-GW.

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

Например, во втором примерном варианте осуществления установка значения «Причина экстренного вызова» в сообщении протокола RANAP сделана в HNB 20. Однако это может быть сделано и в HNB-GW 30.

Кроме того, в примерных вариантах осуществления с первого по четвертый информация, представляющая, что мобильная станция 10 породила вызов в виде экстренного вызова, или информация, представляющая, что действительный тип вызова, порожденного мобильной станцией 10, является экстренным вызовом, передается между HNB 20, HNB-GW 30 и устройством (MSC 40 или SGSN 50) базовой сети c использованием сообщения протокола RANAP. Однако это не ограничивается сообщением протокола RANAP. Этим сообщением может быть другое сообщение, способное передавать информацию между HNB 20 и HNB-GW 30 или устройством базовой сети.

Настоящая заявка претендует на приоритет патентной заявки Японии №2009-229391, поданной 1 октября 2009 года, раскрытие которой целиком внедрено сюда по ссылке.

Изобретение относится к системе мобильной связи. Технический результат - расширение функциональных возможностей за счет предоставления услуги вызова в зоне молчания, куда не достигают радиоволны от макробазовой станции, предоставления услуги выставления счета, использования высокоскоростных технологий при высокоскоростной передаче пакетов. Для этого система мобильной связи включает в себя: мобильную станцию; базовую станцию, связанную беспроводно с мобильной станцией; и шлюзовое устройство, соединенное с базовой станцией и базовой сетью. Базовая станция включает в себя: первое передающее средство для передачи сообщения о регистрации для регистрации мобильной станции в шлюзовом устройстве; и второе передающее средство для передачи сообщения, относящегося к установлению экстренного вызова, порожденного мобильной станцией. Шлюзовое устройство включает в себя: первое приемное средство для приема сообщения о регистрации от базовой станции; второе приемное средство для приема от базовой станции сообщения об установлении, относящегося к установлению экстренного вызова; и средство проверки для проверки согласованности между сообщением о регистрации и сообщением об установлении. 2 н. и 1 з.п. ф-лы, 43 ил.

1. Мобильная станция в системе мобильной связи, содержащей шлюзовое устройство и базовую станцию, которая соединена со шлюзовым устройством, при этом мобильная станция содержит:
средство для установления соединения связи с базовой станцией; и
средство для связи с базовой станцией, которое передает сообщение о регистрации для регистрации мобильной станции в шлюзовом устройстве, и сообщение об установлении экстренного вызова, который порождается мобильной станцией, на шлюзовое устройство посредством указанного соединения связи,
при этом согласованность между указанными сообщением о регистрации и сообщением об установлении проверяется шлюзовым устройством.

2. Мобильная станция по п.1,
в которой соединение связи является соединением управления радиоресурсами (RRC).

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