Способ и система для изменения подписки

Способ и система для изменения подписки

Иллюстрации

Показать все

Реферат

ОБЛАСТЬ ТЕХНИКИ

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

ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ

Для того чтобы достичь независимости доступа и поддерживать гладкое взаимодействие с проводными терминалами по Интернет, IMS, определенная, например, в спецификации 3GPP TS 23.228, была разработана для совместимости со «Стандартами Интернет» IETF (проблемной группы проектирования Интернет). Подсистема мультимедийной базовой сети протокола Интернет (IM CN) позволяет сетевым операторам мобильных или сотовых сетей предлагать своим подписчикам мультимедийное обслуживание, основанное и построенное на приложениях, услугах и протоколах Интернет. Цель состоит в разработке таких услуг мобильными сетевыми операторами и другими поставщиками третьей стороны, включая поставщиков в пространстве Интернет, с использованием механизмов, обеспеченных Интернет и подсистемой IM CN. IMS, таким образом, позволяет осуществлять преобразования и доступ к речевым технологиям, видеотехнологиям, технологиям передачи сообщений, технологиям данных и Web-технологиям для беспроводных пользователей, и объединяет рост Интернет с ростом мобильной связи.

Фиг. 1 показывает архитектуру сети IMS согласно вышеупомянутой спецификации 3GPP (проект участия 3-го поколения). Эта архитектура основана на принципе, что управление услугой для собственных услуг подписки для перемещающегося по роумингу подписчика находится в собственной сети HN, например, обслуживающий функциональный блок управления состоянием вызова (S-CSCF, ОФУСВ) расположена в собственной сети HN (СС). На фиг. 1 показаны текущий или старый S-CSCFo 10 и будущий или новый S-CSCFn 12, между которыми оконечное устройство или оборудование пользователя (UE, ОП) 40 должно быть передано из-за измененных требуемых возможностей, вызванных изменением профиля подписчика UE 40.

В общем, S-CSCF выполняет обслуживание управления сеансом связи для обслуживаемых UE. Она поддерживает состояние сеанса связи, необходимое для сетевого оператора для поддержки услуг. В пределах сети оператора различные S-CSCF могут иметь различные функциональные возможности. Функциями, выполняемыми S-CSCF во время соответствующего сеанса связи, являются, например, регистрация, управление потоками сеанса, управление загрузкой и использованием ресурсов. Когда подписчик перемещается в посещаемую сеть VN, посещаемая сеть поддерживает уполномоченный (прокси) функциональный блок CSCF (P-CSCF, УФУСВ) 30, который позволяет передавать управление сеансом связи к соответствующему S-CSCF, расположенному в собственной сети HN и обеспечивающему управление обслуживанием. Кроме того, опрашивающий CSCF (I-CSCF, ОпФУСВ) 50 обеспечен в собственной сети HN как точка контакта в пределах сети оператора для всех подключений, предназначенных для подписчика этого сетевого оператора, или находящегося в условиях роуминга оператора, расположенного в данный момент в пределах области обслуживания этого сетевого оператора. В пределах сети оператора может быть много I-CSCF. Функции, выполняемые I-CSCF 50, включают в себя назначение S-CSCF пользователю, выполняющему процедуру регистрации, маршрутизацию запроса, принятого от другой сети по направлению к S-CSCF, поддержание адреса S-CSCF от базы данных подписчика, например, собственного сервера подписчика (HSS, ССП) 20, как показано на фиг. 1, и/или передача запросов или ответов к S-CSCF, определенного на основе адреса изменения от HSS 20.

Функциональный блок P-CSCF 30 является первой точкой контакта в пределах IMS. Ее адрес исследуется UE 40, с последующий активацией контакта PDP (протокола пакетных данных). P-CSCF 30 действует как агент, т.е. он принимает запросы и обслуживает их внутри или передает их, возможно, после трансляции. P-CSCF 30 может также действовать как агент пользователя, т.е. в аномальных условиях он может завершать и независимо генерировать транзакции. Функциями, выполняемыми блоком P-CSCF 30, являются передача запросов регистров, принимаемых от UE 40 к I-CSCF, например, блоку I-CSCF 50, определенного с использованием имени собственной области, как обеспечено UE 40, и передача запросов или ответов к UE 40.

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

Согласно обычной сетевой архитектуре в вышеупомянутой спецификации 3GPP версии 5 HSS 20 не знает типа возможностей, которые имеет специфический S-CSCF в сети. Напротив, HSS 20 знает, в каком типе возможностей нуждается S-CSCF для поддержки конкретного подписчика. Эта информация хранится в профиле конкретного подписчика. Во время процесса начальной регистрации UE 40, HSS 20 посылает запрашиваемые возможности S-CSCF к I-CSCF 50, и фактический выбор S-CSCF осуществляется I-CSCF 50. Выбор в I-CSCF 50 выполняется на основе информации, указывающей требуемые возможности (способности), и принимается от HSS 20.

Однако, когда имеется необходимость в обновлении профиля подписчика, например, в S-CSCFo 10, обслуживающем в данный момент UE 40, HSS 20 не может знать, способен ли еще выбранный S-CSCFo 10 адекватно обслуживать подписчика UE 40. Может быть возможным то, что новые возможности, требуемые согласно новому профилю подписчика, не поддерживаются S-CSCFo 10. Другой возможностью является то, что поставщик услуг удалил некоторую услугу из профиля подписчика и тем самым воспрепятствовал использованию этой услуги или части услуги.

Если возможность S-CSCFo 10 не удовлетворяют обновленный профиль подписчика, подписчик не способен использовать все подписанные услуги, или может принять услуги, которые он или она больше не желают иметь. Кроме того, подписчик может быть сделан ответственным за услуги, которые он или она отменили. Кроме того, если сетевой оператор отказался от услуг, подписчик может все же быть способным использовать эти услуги, которые ни ему, ни ей больше не разрешено использовать.

КРАТКОЕ ИЗЛОЖЕНИЕ СУЩЕСТВА ИЗОБРЕТЕНИЯ

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

Эта задача достигается посредством способа для изменения информации подписки подписчика в сети передачи данных, причем указанный способ предусматривает стадии:

обнаружение изменения в указанной информации подписки указанного подписчика;

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

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

Кроме того, вышеуказанная задача решается системой для изменения информации подписки подписчика в сети передачи данных, причем указанная система содержит:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Далее, данное изобретение будет описано более подробно на основе предпочтительных вариантов со ссылкой на сопутствующие чертежи, в которых:

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

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

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

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

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

ОПИСАНИЕ ПРЕДПОЧТИТЕЛЬНЫХ ВАРИАНТОВ

Предпочтительные варианты описаны ниже на основе сетевой архитектуры IMS, показанной на фиг. 1.

IMS, показанная на фиг. 1, относится к набору объектов базовой сети, использующих услуги, обеспеченные областью коммутации пакетов, для предложения мультимедийных услуг. HSS (ССП) 20 является главной базой данных для данного пользователя и включает в себя функциональные узлы обычных регистров собственного расположения (HLR), а также новые функциональные возможности, определенные для сетей IP, таких как IMS. HSS 20 является объектом, содержащим относящуюся к подписке информацию для поддержки сетевых объектов, реально управляющих вызовами и/или сеансами связи. Собственная сеть HN может содержать один или несколько HSS в зависимости от числа мобильных подписчиков, от производительности оборудования и от организации сети. HSS 20 может интегрировать гетерогенную информацию и позволяет усовершенствованным особенностям в базовой сети быть предложенными приложению и области обслуживания. В частности, HSS 20 отвечает за поддержание информации, связанной с пользователем, такой как идентификация пользователя, информация о нумерации и адресации, информация безопасности пользователя, информация о расположении пользователя и информация профиля пользователя. На основе этой информации, HSS 20 также отвечает за поддержание объектов управления вызовом и сеансом связи различных областей и подсистем, таких как IMS, подсистема радиосети (RNS) и т.д.

Согласно предпочтительным вариантам процедура регистрации для регистрации UE 40 для нового блока S-CSCFn 12 инициируется, если проверка (функциональных) возможностей указывает, что текущий S-CSCFo 10 (ОФУСВ) больше не способен обслуживать UE (ОП) 40 после изменения в информации подписки соответствующего подписчика. Эта автоматическая или полуавтоматическая адаптация обслуживающего сетевого элемента или объекта в ответ на проверку возможности может быть выполнена различными способами, описанными в следующих четырех предпочтительных вариантах. Когда подписка или профиль подписчика изменяется для подписчика, например подписчик подписывается на новую услугу (услуги), возможно то, что уже назначенный S-CSCFo 10 не может поддерживать новую услугу (услуги).

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

Как показано на фиг. 2, HSS 20 дерегистрирует подписчика путем посылки соответствующего сообщения дерегистрации через S-CSCFo 10 к UE 40 (стадии 1 и 2), которое приводит к ситуации, когда UE 40 автоматически инициирует новую процедуру начальной регистрации, так как сообщение дерегистрации содержит код причины, который указывает причину дерегистрации. Этот код причины или информация причины добавляется HSS 20 в ответ на обнаружение изменения в информации подписки или профиле подписчика рассматриваемого подписчика. Это приведет к ситуации, когда новый S-CSCF, например S-CSCFn 12, будет выбран на основе нового профиля подписчика. Для того чтобы избежать ненужных дерегистраций, HSS 20 может содержать некоторую информацию конфигурации, используемую для определения того, какие типы услуг нуждаются в специальных S-CSCF. UE 40 посылает сообщение регистрации для новой регистрации к I-CSCF 50 (стадия 3). I-CSCF (ОпФУСВ) затем посылает сообщение авторизации регистрации к HSS 20 (стадия 4). Поскольку HSS 20 знает, что подписка была изменена, он посылает ответ авторизации регистрации с информацией о возможностях и имя текущего S-CSCFo 10 к I-CSCF 50, вместо только имени S-CSCF 50, как это имеет место в обычной процедуре. Отметим, что HSS 20 может также только послать информацию о возможностях текущего S-CSCFo 10 (стадия 5). Затем, I-CSCF 50 может использовать обе или только информацию о возможностях S-CSCF для решения, какие действия он должен предпринять, то есть выбирать ли новый S-CSCF или нет (стадия 6). На основе результата проверки, I-CSCF 50 посылает сообщение регистрации либо к текущему S-CSCFo 10, либо к выбранному новому S-CSCFn 12, имеющему требуемые возможности (стадия 7).

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

Фиг. 3 показывает диаграмму передачи и обработки сигналов сообщений, указывающую процедуру изменения подписки согласно второму предпочтительному варианту. Во втором предпочтительном варианте, HSS 20 не инициирует никаких действий перед тем, как UE 40 посылает нормальное периодическое сообщение регистрации к сети, например к I-CSCF 50 (стадия 1). Когда периодическая регистрация, т.е. сообщение авторизации регистрации прибывает в HSS 20 (стадия 2), HSS 20 знает, что подписка была изменена и посылает ответное сообщение авторизации регистрации, содержащее информацию о производительности и имя текущего S-CSCFo 10 к I-CSCF 50, вместо только имени текущего S-CSCFo 10 (стадия 3). Также в данном случае отметим, что HSS 20 может послать только информацию о (функциональных) возможностях. I-CSCF 50 использует обе или только информацию о возможностях S-CSCF для решения, какие действия следует предпринять, т.е. следует ли выбрать новый S-CSCF, например новый S-CSCFn 12, или нет (стадия 4). В случае, показанном на фиг. 3, новый S-CSCFn 12 выбирается путем передачи сообщения регистрации к S-CSCFn 12 (стадия 5), так как старый назначенный S-CSCFo 10 не удовлетворяет требованиям для обеспечения подходящих услуг для подписчика UE 40.

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

Согласно следующим третьему и четвертому предпочтительным вариантам HSS 20 сначала проверяет, поддерживает ли текущий S-CSCFo 10 новые требования, в которых нуждается измененный профиль подписчика или информация подписки, и инициирует соответствующий профиль подписчика или выбор обслуживающего объекта или процедуру изменения, на основе результата операции проверки. Если текущий S-CSCFo 10 может поддержать новые требования, то новый профиль подписчика обновляется в текущем S-CSCFo 10. Если текущий S-CSCFo 10 не может поддержать новые требования, то HSS 20 начинает процедуру, ведущую к изменению, в отношении нового S-CSCFn 12. Отметим, что в третьем и четвертом предпочтительном вариантах предполагается, что UE 10 расположено в посещаемой сети VN и подключено через P-CSCF 30.

Согласно третьему предпочтительному варианту начинается инициированная сетью процедура дерегистрации, которая ведет к ситуации, когда UE 40 автоматически инициирует новую начальную процедуру повторной регистрации из-за того факта, что сообщение дерегистрации, выданное HSS 20, содержит код причины, который однозначно раскрывает причину для дерегистрации. Это приводит к ситуации, когда новый S-CSCFn 12 будет выбран на основе нового профиля подписчика.

Фиг. 4 показывает диаграмму передачи и обработки сигналов сообщений, указывающую процедуру изменения подписки согласно третьему предпочтительному варианту. Когда новый профиль подписчика был выдан, HSS 20 посылает запрос о возможностях к текущему выбранному S-CSCFo 10 (стадия 1). Запрос о возможностях содержит новые требуемые возможности. Отметим, что эта операция может быть добавлена к существующему профилю, загружающему в удаленный компьютер от HSS 20 к текущего S-CSCFo 10, или она может быть новым механизмом между HSS 20 и текущим S-CSCFo 10. Текущий S-CSCFo 10 сравнивает свои собственные возможности с требуемыми возможностями и принимает решение, может ли он поддерживать требуемые возможности или нет. Затем, текущий S-CSCFo 10 посылает ответ о возможностях к HSS 20, включая положительное или отрицательное подтверждение (стадия 2). Если текущий S-CSCFo 10 не может больше обслуживать подписчика из-за недостатка возможностей, то он пошлет отрицательное подтверждение. Если текущий S-CSCFo 10 все же может обслуживать подписчика, то он пошлет положительное подтверждение к HSS 20. Если был послан новый профиль подписчика, то текущий S-CSCFo 10 может хранить его для дальнейшего использования.

Если HSS 20 принимает положительное подтверждение, то он оканчивает процедуру выбора и изменения. Если профиль подписчика не был послан на стадии 1, то HSS 20 запускает процедуру загрузки профиля подписчика в удаленный компьютер, определенную в вышеупомянутой спецификации 3GPP.

Если HSS 20 принимает отрицательное подтверждение, то он инициирует инициируемый сетью процесс дерегистрации путем посылки сообщения дерегистрации к текущему S-CSCFo 10 с кодом причины, который ясно идентифицирует то, что причиной была необходимость в обновлении профиля подписчика (стадия 3). Текущий S-CSCFo 10 принимает это сообщение от HSS 20 и генерирует соответствующее сообщение SIP (протокола инициирования сеанса связи), например, сообщение извещения, с соответствующим кодом причины и посылает его к P-CSCF 30 (стадия 4). P-CSCF 30 затем передает сообщение SIP к UE 40 (стадия 5). Это позволяет UE 40 автоматически и немедленно начать процедуру повторной регистрации. В частности, UE 40 принимает сообщение SIP, передаваемое на стадиях 4 и 5, и обнаруживает необходимость в регистрации. Затем, UE 40 запускает процесс регистрации, определенный в вышеупомянутых технических условиях 3GPP (стадия 6). Тем самым может быть выбран адекватный обслуживающий сетевой объект.

Согласно четвертому предпочтительному варианту HSS 20 запускает новую процедуру, которая может изменить назначенный текущий S-CSCFo 10 на новый S-CSCFn 12, поддерживающий новые требования без включения UE 40. Может быть возможным то, что сеть не способна распространить инициированное сетью сообщение дерегистрации к UE 40, например, если UE 40 не было подписано на пакет отчета о событиях регистрации.

Фиг. 5 показывает диаграмму передачи и обработки сигналов сообщений, указывающую процедуру изменения подписки согласно четвертому варианту. Когда был выдан новый профиль подписчика, HSS 20 посылает запрос о возможностях к текущему S-CSCFo 10 (стадия 1). Запрос о возможностях содержит новые требуемые возможности согласно новому профилю подписчика. Также в данном случае, эта операция может быть добавлена к существующему профилю, загружающемуся в удаленный компьютер от HSS 20 к текущему S-CSCFo 10, или это может быть новый механизм между HSS 20 и текущим S-CSCFo 10.

По принятии запроса о возможностях, текущий S-CSCFo 10 сравнивает свои собственные возможности с требуемыми возможностями и принимает решение, может ли он поддержать требуемые возможности или нет. Если текущий S-CSCFo 10 не может больше обслуживать подписчика из-за недостатка возможностей, то он посылает ответ о возможностях с отрицательным подтверждением к HSS 20 (стадия 2). Если текущий S-CSCFo 10 все же может обслуживать подписчика, то он посылает положительное подтверждение к HSS 20. Если новый профиль подписчика был послан к текущему S-CSCFo 10, то он сохраняет его для дальнейшего использования.

Если HSS 20 принимает положительное подтверждение, то он завершает процедуру.

Если профиль подписчика не был послан на стадии 1, то HSS 20 запускает процедуру загрузки профиля подписчика в удаленный компьютер, определенную в вышеупомянутых технических условиях 3GPP.

Если HSS 20 принимает отрицательное подтверждение, как показано на фиг. 5, то HSS 20 посылает сообщение дерегистрации к текущему или старому S-CSCFo 10, который в данный момент обслуживает подписчика UE 40. Это сообщение содержит запрос адреса и/или имени P-CSCF 30 посещаемой сети VN (стадия 3). Текущий S-CSCFo 10 принимает сообщение дерегистрации и подтверждает сообщение с адресом и/или именем P-CSCF 30 (стадия 4). Текущий S-CSCFo 10 может затем удалить существующий профиль подписчика рассматриваемого подписчика. Из-за того факта, что сообщение дерегистрации содержало требование послать адрес и/или имя P-CSCF 30, текущий S-CSCFo 10 не посылает какого-либо извещения к P-CSCF 30. HSS 20 принимает подтверждение с адресом и/или именем P-CSCF 30 и временно сохраняет адрес и/или имя P-CSCF подписчика (стадия 5). Отметим, что адрес и/или имя P-CSCF 30 может постоянно храниться в HSS 20. Затем, не обязательно для HSS 20 запрашивать адрес и/или имя P-CSCF 30 на стадии 3.

На стадии 6, HSS 20 посылает сообщение к I-CSCF 50, включая идентичность подписчика и новые возможности, требуемые подписчиком согласно измененной информации подписки. Этим сообщением может быть сообщение инициировать функцию выбора для выбора нового обслуживающего объекта. В ответ на прием этого сообщения, I-CSCF 50 инициирует новый выбор S-CSCF для подписчика на основе новых требуемых возможностей (стадия 7). Затем, I-CSCF 50 посылает сообщение регистрации к вновь выбранному S-CSCFn 12, включая идентификационную информацию подписчика (стадия 8). В ответ на это, новая S-CSCFn 12 запускает процедуру загрузки в удаленный компьютер профиля подписчика, определенную в вышеупомянутой спецификации 3GPP (стадии 9-12). Когда профиль подписчика был обновлен, новая S-CSCFn 12 генерирует соответствующее сообщение SIP, например сообщение извещения, включающее адрес нового S-CSCFn 12, и посылает его к P-CSCF 30 (стадия 13). На стадии 14, P-CSCF 30 сохраняет или обновляет адрес S-CSCF, подлежащий использованию в будущих сеансах связи (стадия 14). Наконец, P-CSCF 30 дает подтверждение для нового S-CSCFn 12 сообщением SIP 200 OK, новый S-CSCFn 12 дает подтверждение для I-CSCF 50 сообщением SIP 200 OK, и I-CSCF 50 посылает соответствующее подтверждение к HSS 20. После этого обслуживающий сетевой объект адаптирован для измененного профиля подписчика.

Операция проверки возможностей, выполняемая HSS 20 в третьем и четвертом предпочтительных вариантах, может быть заменена следующей процедурой проверки. Согласно этой альтернативной процедуре проверки HSS 20 может послать запрос на список возможностей к I-CSCF 50. Это сообщение может содержать требуемые возможности нового S-CSCF. Затем, I-CSCF 50 проверяет требуемые возможности и дает отчет списком допустимых S-CSCF для HSS 20. HSS 20 затем проверяет, включен ли текущий S-CSCFo 10 в этот список возможностей.

В качестве дальнейшей процедуры проверки, HSS 20 может послать адрес текущего или старого S-CSCFo 10 вместе с новыми требуемыми о возможностями согласно обновленному или измененному профилю подписчика к I-CSCF 50 в соответствующем сообщении обновления, на первой стадии. Затем, на второй стадии, I-CSCF 50 дает подтверждение для HSS 20, удовлетворяет ли старый S-CSCFo 10 новым требованиям. На основе подтверждения, принятого от I-CSCF 50, HSS 20 может затем действовать следующими альтернативными путями. Если требование (требования) выполнено (выполнены) старым S-CSCFo 10, то инициируется обновление профиля от HSS 20 на I-CSCF 50. Если нет, то HSS 20 инициирует инициируемую сетью процедуру дерегистрации или процедуру выбора S-CSCF, описанные в связи с фиг. 4 и 5 соответственно.

Необходимость в согласовании возможностей может быть уменьшена посредством использования S-CSCF по умолчанию вместо основанного на возможности выбора. Таким образом, когда обнаруживается, что текущий S-CSCFo 10 не способен обслуживать подписчика ввиду измененной информации подписки, может быть выбран S-CSCF по умолчанию.

Кроме того, запрос о возможностях HSS 20 может быть интегрирован в существующую команду диаметра PPR в интерфейсе Сх между HSS 20 и функциональными блоками S-CSCF и/или I-CSCF.

Если UE 40 не может быть информировано для осуществления новой регистрации в третьем предпочтительном варианте, то P-CSCF 30 может инициировать новую регистрацию после приема извещающего сообщения. Затем, единственным элементом, который требует изменений, был бы P-CSCF 30.

В качестве дальнейшей альтернативы, HSS 20 может знать все возможности S-CSCF, обеспеченные в сети. Для достижения этого, соответствующая таблица может храниться в HSS 20. Затем, запросы о возможностях либо от I-CSCF 50, либо от текущего S-CSCFo 10 не требовались бы в третьем и четвертом предпочтительных вариантах. Операция проверки может затем выполняться в HSS 20. Кроме того, если HSS 20 содержит некоторую информацию конфигурации, то можно избежать ненужных дерегистраций.

Кроме того, в контексте обновления профиля подписчика можно отметить, что старый S-CSCFo 10 не поддерживает новый профиль подписчика, размещенный в ней. Затем, изменение S-CSCF может быть инициировано на основе процедуры согласования, подобной запросам о возможностях первого и второго вариантов. То есть если старый S-CSCFo 10 принимает новый профиль подписчика от HSS 20, то он посылает сообщение подтверждения, которое может содержать причину, например «отсутствие обслуживания» или «обслуживание не известно» и т.д., к HSS 20, указывающее, что она не поддерживает этот вид профиля.

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

1. Способ изменения информации подписки подписчика в сети передачи данных, причем этот способ предусматривает стадии

a) обнаружения изменения в указанной информации подписки указанного подписчика,

b) проверки того, способен ли еще текущий обслуживающий сетевой элемент (10) обслуживать оконечное устройство (40) указанного подписчика в виду указанной измененной информации подписки, и

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

2. Способ по п.1, в котором указанная стадия обнаружения основана на обнаружении обновления профиля подписчика.

3. Способ по п.1, в котором указанная стадия обнаружения основана на обнаружении подписки указанного подписчика на новое обслуживание.

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

5. Способ по п.4, в котором указанная процедура повторной регистрации инициируется указанным оконечным устройством (40) в ответ на процедуру дерегистрации, инициированной после того как изменение указанной информации подписки было обнаружено в указанной стадии обнаружения.

6. Способ по п.4, в котором указанной процедурой повторной регистрации является периодическая процедура повторной регистрации, инициируемая в заданные интервалы времени.

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

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

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

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

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

12. Способ по п.11, в котором указанная информация причины используется указанным оконечным устройством (40) для обнаружения того, что требуется повторная регистрация.

13. Способ по п.7 или 8, в котором функция выбора указанной сети передачи данных инициируется с использованием указанной информации об указанной по меньшей мере одной требуемой возможности обслуживания, и результирующая информация идентификации указанного нового обслуживающего сетевого элемента (12) передается в качестве извещения к уполномоченному сетевому элементу (30), подключенному к указанному оконечному устройству (40).

14. Способ по п.13, в котором указанное извещение осуществляется с использованием идентификационной информации указанного уполномоченного сетевого элемента (30), хранимой в базе данных (20) подписчика.

1