Способ согласования и передачи информации об интервале времени обновления местоположения

Изобретение относится к сетям беспроводной связи и может быть использовано для согласования и передачи информации об интервале времени обновления местоположения, в частности в архитектуре сети WiMAX. Техническим результатом является осуществление согласования и передачи информации об интервале времени обновления местоположения между шлюзами сети доступа, а также между шлюзом сети доступа и подвижной станцией в сети WiMAX так, чтобы интервалы времени обновления местоположения сетевой стороны и подвижной станции поддерживались согласованными. Способ включает: первый этап, на котором подвижная станция инициирует посылку запроса на первоначальный доступ к сети, запроса на переход в режим ожидания или запроса на обновление местоположения к шлюзу обслуживающей сети доступа; и второй этап, на котором при приеме упомянутого запроса шлюз обслуживающей сети доступа в соответствии с информацией о длительности таймера режима ожидания, переносимой в упомянутом запросе или ранее сохраненной, согласовывает длительность таймера режима ожидания и уведомляет подвижную станцию о согласованной длительности таймера режима ожидания. 14 з.п. ф-лы, 10 ил.

 

Область техники

Данное изобретение относится к сетям, использующим технологию глобальной совместимости для доступа на сверхвысоких частотах (World Interoperability for Microwave Access, WiMAX), и, более конкретно, к способу согласования и передачи информации об интервале времени обновления местоположения между шлюзами сети доступа (Access Service Network Gateways, ASN-GW), а также между шлюзом сети доступа и подвижной станцией в сети WiMAX.

Предпосылки создания изобретения

Консорциум WiMAX Forum - некоммерческая организация, состоящая из ведущих изготовителей системного оборудования, поставщиков компонентов (включая интегральные схемы, радиочастотное оборудование, антенны и так далее), поставщиков программного обеспечения и поставщиков услуг. Она создала сертификационную рабочую группу (Certification Working Group, CWG), техническую рабочую группу (Technical Working Group, TWG), регуляторную рабочую группу (по спектральной политике) (Regulatory Working Group, RWG), маркетинговую рабочую группу (Marketing Working Group, MWG), рабочая группу по провайдерам услуг (по требованиям к сетевым и радиоинтерфейсам) (Service Provider Working Group, SPWG), сетевую рабочую группу (Network Working Group, NWG) и рабочую группу по приложениям (Application Working Group, AWG).

Группа NWG разрабатывает и исследует спецификацию архитектуры сети WiMAX, и эта работа разделена на три этапа версий релизов, как это требуется процессом разработки. До настоящего времени был выпущен релиз 1.0.0, и эта версия дополнительно разделена на следующие три этапа: этап 1 выполняется в группе SPWG, и его целью является определение требований к функциям и рабочим характеристикам сети в режимах миграции, переноса, простого движения и всех мобильных режимах; этап 2 и этап 3 выполняются в группе NWG, и задачей этапа 2 является создание эталонной модели архитектуры сети, определение эталонных точек и функций сети и выполнение интерпретаций протокола и процедуры; этап 3 должен усовершенствовать реализацию протокола и процедуры на основе этапа 2.

Фиг.1 иллюстрирует эталонную модель архитектуры сети WiMAX, a фиг.2 и 3 изображают функциональную модель сервисной сети доступа (Access Service Network, ASN).

Модель на фиг.1 является эталонной моделью сети, основанной на стандартах 802.16 Института инженеров по электротехнике и электронике (Institute of Electrical and Electronics Engineers, IEEE). Эталонная модель состоит из трех логических объектов: подвижной станции (Mobile Station, MS)/стационарной станции (Stable Station, SS), сети доступа (ASN) и сети, обеспечивающей подключение к сетям на базе протокола Интернет (Internet Protocol, IP), (Connection Service Network, CSN), - и эти логические объекты соединяются друг с другом посредством стандартных эталонных точек (Reference Points, RP) R1-R5. Каждый логический объект представляет группу функциональных объектов, и каждая функция может быть реализована в одном физическом устройстве или в нескольких распределенных физических устройствах.

Эталонные точки будут подробно описаны ниже:

Эталонная точка R1: эта эталонная точка является интерфейсом между станцией SS/MS и сетью ASN и совместима с физическим уровнем и уровнем управления доступом к среде (Medium Access Control, MAC) no стандарту IEEE 802.16e-2005 или воздушным интерфейсом по стандарту IEEE 802.16d-2004, кроме того, эталонная точка R1 может содержать также дополнительный протокол плоскости управления.

Эталонная точка R2: эта эталонная точка является логическим интерфейсом между станцией SS/MS и сетью CSN, и она устанавливается на физическом соединении между станцией SS/MS и сетью CSN для аутентификации, авторизации услуги, управления конфигурацией сетевого узла протокола Интернет (IP) и так далее. При этом функция аутентификации эталонной точки R2 выполняется между подвижной станцией (MS) и сетью CSN провайдера услуг домашней сети (Home Network Service Provider, H-NSP), и в режиме роуминга сети ASN и CSN провайдера услуг гостевой сети (Visited Network Service Provider, V-NSP) также могут обрабатывать часть процедуры и механизма аутентификации; управление конфигурацией сетевого узла IP может выполняться между подвижной станцией и провайдером NSP домашнего места или сетью CSN гостевого места.

Эталонная точка R3: эта эталонная точка является интерфейсом взаимодействия между сетями ASN и CSN, она содержит ряд протоколов плоскости управления и плоскости переноса и поддерживает аутентификацию, авторизацию и учет (Authentication, Authorization and Accounting, AAA), обязательное выполнение правил (policy enforcement) и управление мобильностью. Кроме того, эталонная точка R3 может также включать способ, такой как установление туннеля, для передачи данных плоскости переноса между сетями ASN и CSN.

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

Эталонная точка R5: эта эталонная точка состоит из ряда протоколов плоскости управления и переноса для взаимодействия между гостевой сетью CSN и домашней сетью CSN.

Эталонная точка R6: см. описание эталонной точки R4.

Сеть ASN управляет воздушным интерфейсом IEEE 802.16 и предоставляет беспроводной доступ для пользователей WiMAX. Сеть ASN состоит по крайней мере из одной базовой станции (Base Station, BS) и одного шлюза ASN (Gateway, GW), и она может содержать единственный шлюз ASN-GW или несколько шлюзов ASN-GW. Фиг.2 и фиг.3 соответственно иллюстрируют эталонную модель сети ASN с единственным шлюзом ASN-GW и эталонную модель сети ASN с несколькими шлюзами ASN-GW.

На фиг.3 сеть ASN соединяется с подвижной станцией в эталонной точке R1, соединяется с сетью CSN в эталонной точке R3 и соединяется с другой сетью ASN в эталонной точке R4. Эталонная точка R4 является уникальной эталонной точкой, соединяющей сети ASN идентичных или различных профилей ASN в плоскости переноса и плоскости управления. Различные типы сетей ASN могут соединяться с исходной сетью ASN посредством определенных протоколов в R1, R3 и R4. Если сеть ASN состоит из n (n>1) шлюзов ASN-GW (как показано на фиг.3), мобильность внутри сети ASN связана с созданием сообщений управления и плоскости переноса R4. Для всех прикладных протоколов и процедур эталонная точка R4 в сети ASN должна быть полностью совместимой с эталонной точкой R4 между сетями ASN.

Базовая станция - это логический объект, и экземпляр базовой станции может реализовывать уровень MAC и физический уровень, специфицированные в стандарте IEEE 802.16. Экземпляр базовой станции представляет собой сектор, работающий на некоторой частоте, и он включает функции планирования распределения ресурсов восходящей линии и нисходящей линии, реализация которых зависит от изготовителя аппаратуры и выходит за пределы спецификации архитектуры сети. Что касается балансирования нагрузки и резервирования, то одной базовой станции может потребоваться подключение более чем к одному шлюзу ASN-GW (например, в показанном на фиг.3 случае, где может быть обеспечена досягаемость вышеупомянутых шлюзов ASN-GW).

Шлюз ASN-GW также является логическим объектом и представляет набор функциональных объектов плоскости управления, и эти функции могут иметь аналоги соответствующих функций (такие как функции в сети CSN в экземпляре базовой станции или функции в другой сети ASN) в сети ASN (такие как контроллер пейджинга, аутентификатор, которые будут описаны ниже, функция пути данных (Data Path Function, DPF) и так далее). Кроме того, шлюз ASN-GW также может выполнять маршрутизацию в плоскости переноса или функцию сетевого моста.

Эти компоненты будут подробно описаны ниже,

Аутентификатор: аутентификатор имеет свое определение в каждой модели третьей стороны по стандарту расширяемого протокола аутентификации (Extensible Authentication Protocol, EAP). Аутентификатор, расположенный на одном конце двухточечной линии, является блоком, помогающим подвижной станции соединяться с другим концом для аутентификации. Перед разрешением терминалу получить доступ к услуге аутентификатор выполняет обязательную аутентификацию. Аутентификатор может содержать также клиента ААА, осуществляющего связь с сервером сертификации на основе ААА и обеспечивающего услугу аутентификации для аутентификатора посредством протокола ААА. Вообще, аутентификатор располагается в том же самом месте, что и устройство распределения ключей, или может располагаться в том же самом месте, что и ретранслятор аутентификации и функция получения ключей. В этом описании аутентификатор как функциональный объект шлюза ASN-GW находится в шлюзе ASN-GW.

Контроллер пейджинга (Paging Controller, PC): контроллер пейджинга - это функциональный объект, осуществляющий управление действиями подвижных станций в режиме ожидания (idle mode) в сети. В IEEE 802.16е он идентифицируется 6-байтовым идентификатором (Identifier, ID) PC, который может отображаться на адрес функционального объекта в архитектуре сети согласно спецификации группы NWG. В этом отношении контроллер пейджинга (PC) может располагаться или в базовой станции (этот случай не рассматривается группой NWG) или находиться отдельно от базовой станции в шлюзе ASN-GW и быть связанным с базовой станцией через эталонную точку R6.

В настоящее время имеются в основном два типа контроллеров пейджинга:

Анкерный PC: для каждой подвижной станции в режиме ожидания должен быть контроллер PC (анкерный PC), содержащий информацию о местоположении подвижной станции.

Ретрансляционный PC: в сети может также быть один или несколько контроллеров PC (ретрансляционных PC), которые передают сообщения управления пейджингом или определением местоположения между базовой станцией зоны пейджинга (Paging Area, PA) и анкерным PC.

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

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

В архитектуре сети WiMAX процедура обновления местоположения является частью управления функциональным объектом контроллера пейджинга (сценарий, в котором контроллер пейджинга и базовая станция объединены, находится вне сферы рассмотрения данного описания, а также вне объема, определенного группой NWG, и входит в объем, определенный IEEE 802.16е); то, что рассматривается в этом описании, - это сценарий, в котором контроллер пейджинга размещается в объекте шлюза сети доступа, и в этом сценарии контроллер пейджинга взаимодействует с агентом пейджинга (функциональным объектом, находящимся в базовой станции для реализации функции пейджинга, определенной в IEEE 802.16е, и взаимодействия с контроллером PC через интерфейс R6 или внутренний интерфейс), чтобы осуществлять соответствующий обмен сообщениями, при этом обмен сообщениями между контроллерами пейджинга осуществляется через эталонную точку R4.

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

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

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

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

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

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

Кроме того, вышеупомянутый способ дополнительно предусматривает, что:

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

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

Кроме того, вышеупомянутый способ дополнительно предусматривает, что:

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

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

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

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

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

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

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

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

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

Кроме того, вышеупомянутый способ дополнительно предусматривает, что:

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

Кроме того, вышеупомянутый способ дополнительно предусматривает, что:

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

Кроме того, вышеупомянутый способ дополнительно предусматривает, что:

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

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

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

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

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

Чертежи, приведенные здесь, используются для обеспечения лучшего понимания данного изобретения и составляют часть данной заявки; примеры осуществления данного изобретения и их описание используются для объяснения данного изобретения и не ограничивают данное изобретение. На чертежах:

Фиг.1 - блок-схема эталонной модели архитектуры сети WIMAX согласно соответствующим технологиям.

Фиг.2 - блок-схема эталонной модели сети ASN с одним шлюзом ASN-GW согласно соответствующим технологиям.

Фиг.3 - блок-схема эталонной модели сети ASN с несколькими шлюзами ASN-GW согласно соответствующим технологиям.

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

Фиг.5 - блок-схема сигнализации примера 1 обработки в способе согласования и передачи информации об интервале времени обновления местоположения в соответствии с первой формой осуществления данного изобретения.

Фиг.6 - блок-схема сигнализации примеров 2 и 5 обработки в способе согласования и передачи информации об интервале времени обновления местоположения в соответствии с первой формой осуществления данного изобретения.

Фиг.7 - блок-схема сигнализации примера 3 обработки в способе согласования и передачи информации об интервале времени обновления местоположения в соответствии с первой формой осуществления данного изобретения.

Фиг.8 - блок-схема сигнализации примера 4 обработки в способе согласования и передачи информации об интервале времени обновления местоположения в соответствии с первой формой осуществления данного изобретения.

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

Фиг.10 - блок-схема способа согласования и передачи информации об интервале времени обновления местоположения в соответствии со второй формой осуществления данного изобретения.

На вышеупомянутых чертежах штриховая линия представляет сообщение плоскости управления, а сплошная линия - сообщение плоскости канала переноса.

Предпочтительные формы осуществления данного изобретения

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

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

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

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

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

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

Формы осуществления данного изобретения будут описаны подробно со ссылкой на чертежи. Реализация данного изобретения основана на спецификациях протокола (включающего этап 2 и этап 3), связанных с релизом 1.0.0, выпущенным группой NWG, а сообщения между подвижной станцией и базовой станцией принадлежат к сообщениям, определенным в IEEE 802.16е, вне объема, определенного группой NWG, и это описание касается процедуры обмена сообщениями между базовой станцией (BS) и шлюзом сети доступа.

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

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

Этап S402: подвижная станция (MS) инициирует запрос на первоначальное получение доступа к сети, запрос на переход в режим ожидания и запрос на обновление местоположения, посылаемые к шлюзу обслуживающей сети доступа (обслуживающий ASN-GW услуг).

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

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

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

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

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

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

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

Пример 1

В этом примере описывается обработка, выполняемая пользователем, когда он первоначально получает доступ к сети на основании способа, показанного на фиг.4.

Способ согласования и передачи информации об интервале времени обновления местоположения согласно данному примеру включает:

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

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

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

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

Вышеупомянутая обработка ниже будет подробно описана со ссылкой на фиг.5.

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

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

Этап S509: подвижная станция инициирует запрос на регистрацию, посылаемый к базовой станции посредством сообщения "запрос на регистрацию" (REG_REQ), переносящего длительность таймера режима ожидания.

Этап S510: базовая станция инициирует запрос на присоединение посредством сообщения "запрос на присоединение подвижной станции" (MS_Attach_Req), и добавляет к нему поле Idle Mode Timer (таймер режима ожидания), значение которого может быть получено из сообщения REG__REQ подвижной станции, и применяется как длительность таймера, которую подвижная станция просит согласовать.

Этап S511: аутентификатор согласовывает значение Idle Mode Timer согласно стратегии и посылает согласованное значение Idle Mode Timer (таймер режима ожидания) на базовую станцию посредством сообщения "ответ о присоединении подвижной станции" (MS_Attach_Rsp), а если аутентификатор использует это значение Idle Mode Timer в сообщении запроса на присоединения, то это значение не требуется посылать на базовую станцию.

Этап S512: базовая станция посылает сообщение "ответ о регистрации" (REG_RSP) на подвижную станцию, это сообщение содержит значение Idle Mode Timer, согласованное аутентификатором, а если сообщение ответа о присоединении не содержит значение Idle Mode Timer, то тогда может использоваться значение Idle Mode Timer из сообщения запроса на присоединение, посланного на аутентификатор базовой станцией.

Этап S513: базовая станция посылает сообщение "подтверждение присоединения подвижной станции" (MS_Attachment_Ack) на аутентификатор, чтобы подтвердить, что сообщение "ответ регистрации" (REG_RSP) было послано.

Этап S514: канал передачи данных устанавливается между подвижной станцией, базовой станцией и шлюзом сети доступа.

Пример 2

В этом примере описывается обработка, выполняемая при переходе в режим ожидания на основании способа, показанного на фиг.4.

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

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

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

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

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

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

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

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

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

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

Вышеупомянутая обработка будет подробно описана ниже.

Фиг.6 иллюстрирует процедуру сигнализации в примере обработки, выполняемой при переходе в режим ожидания на основании способа, показанного на фиг.4. В нижеследующем описании обмен сообщениями сигнализации, выполняемый в течение процесса перехода в режим ожидания, дает возможность подвижной станций перейти в режим ожидания, и этот процесс включает две части: этапы S601-S608, которые главным образом касаются обмена сообщениями для перехода в режим ожидания между подвижной станцией и контроллером пейджинга, и этапы S609-S613, которые касаются освобождения и обновления соответствующих ресурсов сети.

Как показано на фиг.6, это включает следующую обработку:

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

Этап S602: базовая станция посылает сообщение "запрос на изменение состояния для перехода в режим ожидания" (IM_Entry_State_Change_Req) на шлюз обслуживающей сети доступа (называемым ниже также ретрансляционным PC, потому что соответствующие операции выполняются ретрансляционным PC в шлюзе обслуживающей сети доступа), и добавляет поле Idle Mode Timer в сообщение, при этом значение может быть получено из сообщения DREG REQ подвижной станции и применено как значение длительности таймера, согласование которого запрашивает подвижная станция.

Этап S603: ретрансляционный PC пересылает IM_Entry_State_Change_Req на анкерный PC;

Этапы S604 и S605: анкерный PC получает контекст защиты от аутентификатора.

Этап S606: анкерный PC согласовывает значение Idle Mode Timer согласно его стратегии и посылает согласованное значение Idle Mode Timer в ретрансляционный PC посредством сообщения "ответ об изменении состояния для перехода в режим ожидания" (IM_Entry_State_Change_Rsp).

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

Этап S607: ретрансляционный PC пересылает IM_Entry_State_Change_Rsp на базовую станцию.

Этап S608: базовая станция посылает сообщение "ответ о дерегистрации" (DREG_RSP) на подвижную станцию, и это сообщение содержит значение Idle Mode Timer, согласованное анкерным PC.

Этапы S609a и S609b: от базовой стации в ретрансляционный PC и от ретрансляционного PC в анкерный PC посылается сообщение "подтверждение перехода в режим ожидания" (IM_Entry_State_Change_Ac), чтобы подтвердить, что ответ IM_Entry_State_Change_Rsp был послан.

Этапы S610 и S611: анкерный PC уведомляет анкерный функциональный объект канала данных индикацией о том, что был выполнен переход в режим ожидания, и анкерный функциональный объект канала данных посылает обратно подтверждение.

Этап S612: удаляется канал данных между обслуживающей сетью доступа и анкерным функциональным объектом канала данных.

Этап S613: обновляется параметр CMAC_KEY_Count защиты воздушного интерфейса.

Пример 3

В этом примере описывается обработка, выполняемая в случае, когда анкерный PC не изменяется во время обновления местоположения, на основании способа, показанного на фиг.4.

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

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

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

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

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

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

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

Вышеупомянутая обработка будет подробно описана ниже.

Фиг.7 иллюстрирует процедуру сигнализации при обработке, выполняемой в том случае, когда анкерный PC не изменяется во время обновления местоположения, на основании способа, показанного на фиг.4. Как показано на фиг.7, он включает следующую обработку:

Этап S701: подвижная станция посылает сообщение "запрос RNG" (RNG_REQ) на базовую станцию, чтобы указать на обновление местоположения, и это сообщение несет информацию о длительности таймера режима ожидания.

Этап S702: обслуживающая базовая станция посылает сообщение "запрос на обновление местоположения" (LU_Req) на шлюз обслуживающей сети доступа (ретрансляционный PC) и добавляет в сообщение поле Idle Mode Timer, а его значение может быть получено из сообщения RNG_REQ подвижной станции и принято как значение длительности таймера, которое подвижная станция просит согласовать.

Этап S703: ретрансляционный PC пересылает сообщение LU_Req на анкерный PC.

Этапы S704a и S704b: анкерный PC получает контекст защиты от аутентификатора посредством процедуры получения контекста.

Этап S705: анкерный PC согласовывает значение таймера режима ожидания согласно своей стратегии и посылает согласованное значение таймера режима ожидания в ретрансляционный PC посредством сообщения "ответ об обновлении местоположения" (LU_Rsp).

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

Этап S706: ретрансляционный PC пересылает сообщение LU_Rsp на базовую станцию.

Этап S707: базовая станция посылает сообщение "ответ RNG" (RNG_RSP) на подвижную станцию, и это сообщение содержит значение таймера режима ожидания, согласованное анкерным PC.

Этап S708: обновляется параметр CMAC_KEY_Count защиты воздушного интерфейса.

Этапы S709 и S710: от базовой стации в ретрансляционный PC и от ретрансляционного PC в анкерный PC посылается сообщение "подтверждение обновления местоположения" (LU_Cnf), чтобы подтвердить завершение процедуры обновления местоположения.

Пример 4

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

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

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

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

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

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

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

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

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

Вышеупомянутые этапы будут подробно описаны ниже со ссылкой на чертежи.

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

Этап S801: подвижная станция посылает сообщение "запрос RNG" (RNG__REQ) на обслуживающую базовую станцию, чтобы указать на обновление местоположения, это сообщение несет длительность таймера режима ожидания.

Этап S802: обслуживающая базовая станция посылает сообщение "запрос на обновление местоположения" (LU_Req) на шлюз обслуживающей сети доступа (ретрансляционный PC) и добавляет в это сообщение поле Idle Mode Timer, его значение может быть получено из сообщения RNG_REQ подвижной станции и принято как значение длительности таймера, которое подвижная станция просит согласовать.

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

Этапы S805a и S805b: исходный анкерный PC получает контекст защиты от аутентификатора посредством процедуры получения контекста.

Этап S806, исходный анкерный PC посылает релевантный пользовательский контекст новому анкерному PC посредством сообщения "ответ об обновлении местоположения" (LU_Rsp), переносящего значение таймера режима ожидания, успешно согласованное ранее.

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

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

Этап S808: ретрансляционный PC пересылает сообщение LU_Rsp на базовую станцию.

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

Этап S809: базовая станция посылает сообщение "ответ RNG" (RNG_RSP) на подвижную станцию, и это сообщение содержит значение таймера режима ожидания, согласованное анкерным PC.

Этап S810: обновляется параметр CMAC_KEY_Count защиты воздушного интерфейса.

Этапы S811, S812 и S817: от базовой стации в ретрансляционный PC и от ретрансляционного PC в новый анкерный PC, а также от нового анкерного PC в исходный анкерный PC посылается сообщение "подтверждение обновления местоположения" (LU_Cnf), чтобы подтвердить завершение процедуры обновления местоположения.

Этапы S813-S816: новый анкерный PC уведомляет аутентификатор и анкерный функциональный объект канала данных о завершении изменения анкерного PC и принимает сообщения подтверждения.

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

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

Этап S901: текущий анкерный контроллер пейджинга посылает сообщение "отчет о контексте" (Context_Rpt) в аутентификатор, и это сообщение несет новую согласованную длительность таймера режима ожидания.

Этап S902: аутентификатор сохраняет новую длительность таймера режима ожидания и посылает сообщение "подтверждение контекста" (Context_Ack) в текущий анкерный контроллер пейджинга.

Вторая форма осуществления изобретения

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

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

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

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

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

Это будет подробно описано с помощью нескольких примеров.

Пример 5

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

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

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

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

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

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

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

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

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

Вышеупомянутая обработка будет подробно описана ниже.

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

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

Этап S601: подвижная станция посылает сообщение "запрос на дерегистрацию" (DREG_REQ) на базовую станцию, указывающее на переход в режим ожидания, и это сообщение не несет длительность таймера режима ожидания.

Этап S602: базовая станция посылает сообщение "запрос на изменение состояния для перехода в режим ожидания" (lM_Entry_State_Change_Req) на шлюз обслуживающей сети доступа (ретрансляционный PC), и это сообщение не содержит поле Idle Mode Timer.

Этап S603: ретрансляционный PC пересылает сообщение IM_Entry_State_Change_Req в анкерный контроллер пейджинга (анкерный PC).

Этап S604: анкерный PC посылает сообщение "запрос на изменение состояния для перехода в режим ожидания" (IM_Entry_State_Change_Req) в аутентификатор, чтобы получить контекст, связанный с пользователем.

Этап S605: анкерный PC принимает сообщение "ответ об изменении состояния для перехода в режим ожидания" (IM_Entry_State_Change_Rsp) от аутентификатора, и это сообщение содержит значение таймера режима ожидания.

Этап S606: анкерный PC использует значение таймера режима ожидания, полученное на этапе S605, при этом сообщение "ответ об изменении состояния для перехода в режим ожидания" (IM_Entry_State_Change_Rsp), посылаемое в ретрансляционный PC, не несет значение таймера режима ожидания.

Этап S607: ретрансляционный PC пересылает сообщение IM_Entry_State_Change_Rsp на базовую станцию.

Этап S608: базовая станция посылает сообщение "ответ о дерегистрации" (DREG_RSP) на подвижную станцию, и так как значение таймера режима ожидания на этот раз не включено в сообщение, подвижная станция будет использовать значение таймера режима ожидания, последний раз сообщенное сетевой стороной посредством "ответа о регистрации" (REG_RSP), "ответа о дерегистрации" (DREG_RSP) или "ответа RNG" (RNG_RSP).

Этапы S609a и S609b: сообщение "подтверждение перехода в режим ожидания" (IM_Entry_State_Change_Ack) используется, чтобы подтвердить, что сообщение IM_Entry_State_Change_Rsp было послано.

Этапы S610 и S611: анкерный контроллер пейджинга уведомляет анкерный функциональный объект канала данных индикацией того, что был выполнен переход в режим ожидания.

Этап S612: удаляется канал данных между обслуживающей сетью доступа и функциональным объектом канала данных.

Этап S613: обновляется параметр CMAC_KEY_Count защиты воздушного интерфейса.

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

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

Промышленная применимость

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

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

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

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

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

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

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

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

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

9. Способ по любому из пп.1-8, в котором стратегией согласования, используемой аутентификатором или анкерным контроллером пейджинга в шлюзе обслуживающей сети доступа, является:
непосредственное использование длительности таймера режима ожидания, переносимой в одном из запросов, использование предварительной локальной установки длительности таймера режима ожидания или использование ранее согласованной длительности таймера режима ожидания.

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

11. Способ по любому из пп.1-4 и 6-8, в котором в случае, когда запрос, инициированный подвижной станцией, несет длительность таймера режима ожидания, сообщение ответа, посылаемое обратно на подвижную станцию базовой станцией, несет согласованную длительность таймера режима ожидания; или если согласованная длительность таймера режима ожидания является длительностью, переносимой в запросе, инициированном упомянутой подвижной станцией, то сообщение ответа, посылаемое обратно на подвижную станцию, не несет длительность, что указывает, что использование длительности в упомянутом запросе согласовывается по умолчанию.

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

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

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

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