ПРОТОКОЛ МАРШРУТИЗАЦИИ
ROUTING PROTOCOL

Перекрестная ссылка
Данная заявка испрашивает приоритет предварительной патентной заявки США № 60/913988, поданной 4.25.07, озаглавленной "Methods and Apparatus for Providing Route Protocol", и предварительной патентной заявки США № 60/949297, поданной 7.12.07, озаглавленной "Route Protocol Design for UMB", переуступленных правообладателю настоящей заявки и полностью включенных в данный документ посредством ссылки.
Область техники, к которой относится изобретение
Последующее описание, в общем, относится к системам беспроводной связи, а более конкретно к установлению коммуникационных маршрутов или туннелей в системах беспроводной связи.
Уровень техники
Беспроводные системы связи стали доминирующим средством, посредством которого большинство людей по всему миру осуществляют связь. Эти системы могут быть системами множественного доступа, обеспечивающими поддержку связи с множеством пользователей посредством совместного использования доступных системных ресурсов (к примеру, ширины полосы и мощности передачи). Примеры таких систем множественного доступа включают в себя системы множественного доступа с кодовым разделением (CDMA), системы множественного доступа с временным разделением (TDMA), системы множественного доступа с частотным разделением (FDMA) и системы множественного доступа с ортогональным частотным разделением (FDMA) и другие системы.
Типичная система или сеть беспроводной связи (к примеру, использующая технологии частотного, временного и кодового разделения) включает в себя одну или более базовых станций, которые предоставляют зону покрытия, и один или более мобильных (к примеру, беспроводных) терминалов, которые позволяют передавать и принимать данные в зоне покрытия. Типичная базовая станция может одновременно передавать несколько потоков данных для услуг широковещательной, многоадресной и/или одноадресной передачи, при этом потоком данных является поток данных, который может представлять отдельный интерес для приема посредством мобильного терминала. Мобильный терминал в зоне покрытия базовой станции может быть заинтересован в приеме одного, нескольких или всех потоков данных, переносимых посредством составного потока. Аналогично, мобильный терминал может передавать данные в базовую станцию или другой мобильный терминал.
В таких системах связи желательно предоставлять непрерывное обслуживание, когда мобильное устройство перемещается между соседними географическими сотами, называемое передачей обслуживания. Эта передача важна, поскольку прерывание может приводить к ухудшению качества, незавершенному обмену данными или другим нежелательным ситуациям. Таким образом, есть потребность поддерживать передачи обслуживания от текущей базовой станции к целевой базовой станции.
Раскрытие изобретения
Далее представлена упрощенная сущность одного или более аспектов, для обеспечения базового понимания этих аспектов. Эта сущность не является всесторонним обзором всех рассматриваемых аспектов и не предназначена ни для выявления ключевых или важнейших элементов всех аспектов, ни для определения объема каких-либо или всех аспектов. Ее единственная цель - представить некоторые понятия одного или более аспектов в упрощенной форме в качестве вступления к более подробному описанию, которое представлено далее.
В соответствии с одним или более аспектов и их соответствующим раскрытием сущности различные аспекты описаны в связи с созданием туннелей между двумя или более базовыми станциями.
Один аспект относится к способу для создания туннельной взаимосвязи между мобильным устройством и базовой станцией. Способ включает в себя выбор, по меньшей мере, одной базовой станции для установления связи через туннель и передачу сообщения, которое включает в себя заголовок создания маршрута, по меньшей мере, в одну базовую станцию. Заголовок создания маршрута содержит один или более параметров, ассоциированных с определением туннеля. Способ также включает в себя ожидание подтверждения заголовка создания маршрута и переход из состояния ожидания открытия, если подтверждение принято. Подтверждение указывает создание туннельной взаимосвязи.
Другой аспект относится к устройству беспроводной связи, которое включает в себя запоминающее устройство и процессор. Запоминающее устройство сохраняет инструкции, связанные с выбором, по меньшей мере, одной базовой станции для установления связи через туннель и передачей сообщения, которое включает в себя заголовок создания маршрута, по меньшей мере, в одну базовую станцию. Запоминающее устройство дополнительно сохраняет инструкции, связанные с ожиданием подтверждения заголовка создания маршрута и переходом из состояния ожидания открытия, если подтверждение принято. Заголовок создания маршрута содержит один или более параметров, ассоциированных с определением туннеля. Процессор соединен с запоминающим устройством и выполнен с возможностью осуществлять инструкции, сохраненные в запоминающем устройстве.
Дополнительный аспект относится к компьютерному программному продукту, содержащему машиночитаемый носитель. Машиночитаемый носитель включает в себя первый набор кодов для побуждения компьютера выбрать, по меньшей мере, одну базовую станцию для установления связи через туннель и второй набор кодов для побуждения компьютера передать сообщение, которое включает в себя заголовок создания маршрута, по меньшей мере, в одну базовую станцию. Заголовок создания маршрута содержит один или более параметров, ассоциированных с определением туннеля. Машиночитаемый носитель включает в себя третий набор кодов для побуждения компьютера ожидать подтверждения заголовка создания маршрута и четвертый набор кодов для побуждения компьютера переходить из состояния ожидания открытия, если подтверждение принято. Подтверждение включает в себя прием пакета, по меньшей мере, от одной базовой станции.
Дополнительный аспект относится к устройству, которое включает в себя средство для выбора, по меньшей мере, одной базовой станции для установления связи через туннель и средство для передачи сообщения, которое включает в себя заголовок создания маршрута, по меньшей мере, в одну базовую станцию. Заголовок создания маршрута содержит один или более параметров, ассоциированных с определением туннеля. Устройство также включает в себя средство для ожидания подтверждения заголовка создания маршрута. Подтверждение включает в себя прием пакета, по меньшей мере, от одной базовой станции. Средство для передачи сообщения может повторно передавать сообщение, которое включает в себя заголовок создания маршрута, по меньшей мере, в одну базовую станцию до тех пор, пока подтверждение не будет принято. Также включено средство для перехода из состояния ожидания открытия, когда подтверждение принято.
Еще один другой аспект относится, по меньшей мере, к одному процессору для протокола маршрутизации. Процессор содержит первый модуль, выполненный с возможностью выбирать, по меньшей мере, одну базовую станцию для установления связи через туннель, и второй модуль, выполненный с возможностью передавать сообщение, которое включает в себя заголовок создания маршрута, по меньшей мере, в одну базовую станцию. Заголовок создания маршрута содержит один или более параметров, ассоциированных с определением туннеля. Процессор также включает в себя третий модуль, выполненный с возможностью ожидать подтверждения заголовка создания маршрута. Подтверждение включает в себя прием пакета, по меньшей мере, от одной базовой станции. Также в процессор включен четвертый модуль, выполненный с возможностью повторно передавать сообщение, которое включает в себя заголовок создания маршрута, по меньшей мере, в одну базовую станцию до тех пор, пока подтверждение не будет принято, и пятый модуль, выполненный с возможностью переходить из состояния ожидания открытия, когда подтверждение принято.
Другой аспект относится к способу для создания туннельной взаимосвязи между мобильным устройством и базовой станцией. Способ включает в себя прием сообщения, которое включает в себя заголовок создания маршрута, от мобильного устройства. Заголовок создания маршрута содержит один или более параметров, ассоциированных с определением туннеля. Способ также включает в себя определение того, находится ли мобильное устройство в состоянии ожидания открытия, и анализ заголовка создания маршрута на предмет, по меньшей мере, одной ошибки, если устройство находится в состоянии ожидания открытия. Дополнительно, способ включает в себя создание сообщения протокола маршрутизации в ответ на принимаемое сообщение и передачу созданного сообщения протокола маршрутизации в мобильное устройство.
Еще один другой аспект относится к устройству беспроводной связи, которое включает в себя запоминающее устройство и процессор. Запоминающее устройство сохраняет инструкции, связанные с приемом сообщения, которое включает в себя заголовок создания маршрута, от мобильного устройства. Заголовок создания маршрута содержит один или более параметров, ассоциированных с определением туннеля. Запоминающее устройство также сохраняет инструкции, связанные с определением того, находится ли мобильное устройство в состоянии ожидания открытия, и анализом заголовка создания маршрута на предмет, по меньшей мере, одной ошибки, если устройство находится в состоянии ожидания открытия. Запоминающее устройство дополнительно сохраняет инструкции, связанные с созданием сообщения протокола маршрутизации в ответ на принимаемое сообщение и передачу созданного сообщения протокола маршрутизации в мобильное устройство. Процессор соединен с запоминающим устройством и выполнен с возможностью осуществлять инструкции, сохраненные в запоминающем устройстве.
Дополнительный аспект относится к компьютерному программному продукту, который включает в себя машиночитаемый носитель. Машиночитаемый носитель включает в себя первый набор кодов для побуждения компьютера принимать сообщение, которое включает в себя заголовок создания маршрута, от мобильного устройства. Заголовок создания маршрута содержит один или более параметров, ассоциированных с определением туннеля. Машиночитаемый носитель также включает в себя второй набор кодов для побуждения компьютера определять то, находится ли мобильное устройство в состоянии ожидания открытия, и третий набор кодов для побуждения компьютера анализировать заголовок создания маршрута на предмет, по меньшей мере, одной ошибки, если устройство находится в состоянии ожидания открытия. Дополнительно в машиночитаемый носитель включен четвертый набор кодов для побуждения компьютера создавать сообщение протокола маршрутизации в ответ на принимаемое сообщение и пятый набор кодов для побуждения компьютера передавать созданное сообщение протокола маршрутизации в мобильное устройство.
Еще один аспект относится к устройству, которое включает в себя средство для приема сообщения, которое включает в себя заголовок создания маршрута, от мобильного устройства. Заголовок создания маршрута содержит один или более параметров, ассоциированных с определением туннеля. Устройство также включает в себя средство для определения того, находится ли мобильное устройство в состоянии ожидания открытия, и средство для анализа заголовка создания маршрута на предмет, по меньшей мере, одной ошибки, если устройство находится в состоянии ожидания открытия. Дополнительно, устройство включает в себя средство для создания сообщения протокола маршрутизации в ответ на принимаемое сообщение и средство для передачи созданного сообщения протокола маршрутизации в мобильное устройство.
Другой аспект относится, по меньшей мере, к одному процессору для протокола маршрутизации. Процессор включает в себя первый модуль, выполненный с возможностью принимать сообщение, которое включает в себя заголовок создания маршрута, от мобильного устройства. Заголовок создания маршрута содержит один или более параметров, ассоциированных с определением туннеля. Процессор также включает в себя второй модуль, выполненный с возможностью определять, находится ли мобильное устройство в состоянии ожидания открытия, и третий модуль, выполненный с возможностью анализировать заголовок создания маршрута на предмет, по меньшей мере, одной ошибки, если устройство находится в состоянии ожидания открытия. Заголовок создания маршрута игнорируется, если устройство не находится в состоянии ожидания открытия. Дополнительно в процессор включен четвертый модуль, выполненный с возможностью создавать сообщение протокола маршрутизации в ответ на принимаемое сообщение, и пятый модуль, выполненный с возможностью передавать созданное сообщение протокола маршрутизации в мобильное устройство.
Для достижения вышеуказанных и связанных целей один или более аспектов содержат признаки, далее полностью описанные и конкретно указанные в формуле изобретения. Нижеследующее описание и прилагаемые чертежи подробно излагают определенные иллюстративные признаки одного или более аспектов. Тем не менее, эти признаки являются показательными только для немногих из различных способов, которыми могут использоваться принципы различных аспектов. Другие преимущества и новые признаки должны стать очевидными из следующего подробного описания, если рассматривать их вместе с чертежами, и раскрытые аспекты включают в себя все эти аспекты и их эквиваленты.
Краткое описание чертежей
Фиг. 1 иллюстрирует систему беспроводной связи в соответствии с различными аспектами, представленными в данном документе.
Фиг. 2 иллюстрирует систему, которая упрощает реализацию протокола маршрутизации в среде беспроводной связи.
Фиг. 3 иллюстрирует систему, которая упрощает реализацию протокола маршрутизации в среде беспроводной связи.
Фиг. 4 иллюстрирует два примера пакетов протокола маршрутизации.
Фиг. 5 иллюстрирует примерные заголовки протокола маршрутизации и то, как эти различные заголовки взаимодействуют.
Фиг. 6 иллюстрирует способ для создания туннельной взаимосвязи между мобильным устройством и базовой станцией.
Фиг. 7 иллюстрирует способ для установления связи между мобильным устройством и базовой станцией через туннель.
Фиг. 8 иллюстрирует примерную систему, которая создает туннельную взаимосвязь между мобильным устройством и базовой станцией.
Фиг. 9 иллюстрирует примерную систему, которая создает туннельную взаимосвязь между мобильным устройством и базовой станцией.
Осуществление изобретения
Различные аспекты описываются далее со ссылкой на чертежи. В нижеследующем описании, для целей пояснения, многие конкретные детали поясняются для того, чтобы предоставить полное понимание одного или более аспектов. Тем не менее, может быть очевидным, что такие аспекты могут применяться на практике без этих конкретных деталей. В иных случаях распространенные структуры и устройства показаны в форме блок-схем для упрощения описания этих аспектов.
При использовании в данной заявке термины "компонент", "модуль", "система" и т.п. предназначены для ссылок на связанный с компьютером объект, будь то аппаратные средства, микропрограммное обеспечение, комбинация аппаратных средств и программного обеспечения, программное обеспечение или программное обеспечение в ходе исполнения. Например, компонент может быть, но не только, процессом, запущенным на процессоре, процессором, объектом, исполняемым файлом, потоком исполнения, программой и/или компьютером. В качестве иллюстрации, и приложение, запущенное на вычислительном устройстве, и вычислительное устройство могут быть компонентом. Один или более компонентов могут постоянно размещаться внутри процесса и/или потока исполнения, и компонент может быть локализован на компьютере и/или распределен между двумя и более компьютерами. Кроме того, эти компоненты могут выполняться с различных машиночитаемых носителей, сохраняющих различные структуры данных. Компоненты могут обмениваться данными посредством локальных и/или удаленных процессов, например, в соответствии с сигналом, имеющим один или более пакетов данных (к примеру, данных из одного компонента, взаимодействующего с другим компонентом в локальной системе, распределенной системе и/или по сети, например по Интернету с другими системами посредством сигнала).
Более того, различные аспекты описываются в данном документе в связи с беспроводным терминалом. Беспроводной терминал также может называться системой, абонентским устройством, абонентской станцией, мобильной станцией, мобильным аппаратом, мобильным устройством, удаленной станцией, удаленным терминалом, терминалом доступа, пользовательским терминалом, терминалом, устройством беспроводной связи, пользовательским агентом, пользовательским устройством или пользовательским оборудованием (UE). Беспроводным устройством может быть сотовый телефон, беспроводной телефон, телефон по протоколу инициирования сеанса (SIP), смартфон, станция беспроводного абонентского доступа (WLL), персональное цифровое устройство (PDA), карманное устройство связи, карманное вычислительное устройство, спутниковое радиоустройство и/или другое обрабатывающее устройство для обмена данными в беспроводной системе. Помимо этого различные аспекты описываются в данном документе в связи с базовой станцией. Базовая станция может быть использована для обмена данными с беспроводным терминалом(ами) и также может упоминаться как точка доступа, узел B или определяться каким-либо другим термином.
Различные аспекты или признаки представляются относительно систем, которые могут включать в себя ряд устройств, компонентов, модулей и т.п. Следует понимать и принимать во внимание, что различные системы могут включать в себя дополнительные устройства, компоненты, модули и т.д. и/или могут не включать в себя все из устройств, компонентов, модулей и т.д., поясненных в связи с чертежами. Также может использоваться комбинация этих подходов.
На фиг. 1 проиллюстрирована система 100 беспроводной связи в соответствии с различными аспектами, представленными в данном документе. Система 100 может содержать одну или более базовых станций в одном или более секторов, которые принимают, передают, ретранслируют и т.п. сигналы беспроводной связи друг другу и/или в одно или более мобильных устройств. Каждая базовая станция может содержать несколько трактов передатчика и трактов приемника (к примеру, по одному для каждой передающей и приемной антенны), каждый из которых, в свою очередь, может содержать множество компонентов, ассоциированных с передачей и приемом сигналов (к примеру, процессоров, модуляторов, мультиплексоров, демодуляторов, демультиплексоров, антенн и т.д.). Каждое мобильное устройство может содержать один или более трактов передатчика и трактов приемника, которые могут быть использованы для системы со многими входами и многими выходами (MIMO). Каждый тракт передатчика и приемника может содержать множество компонентов, ассоциированных с передачей и приемом сигналов (к примеру, процессоров, модуляторов, мультиплексоров, демодуляторов, демультиплексоров, антенн и т.д.), как должно быть ясно специалистам в данной области техники.
Как проиллюстрировано, мобильное устройство 102 может посылать и/или принимать пакеты с базовой станции 104 по линии беспроводной связи, упоминаемой в данном документе как первичная базовая станция 104. В системе 100 беспроводной связи могут быть другие базовые станции, такие как базовые станции 106 и 108, которые находятся вне досягаемости мобильного устройства 102. Таким образом, подключение не может быть установлено непосредственно с этими базовыми станциями 106, 108. Тем не менее, технология, упоминаемая как туннелирование, может быть использована для того, чтобы мобильное устройство 102 обменивалось данными с базовыми станциями 106 и 108 через первичную базовую станцию 104. Базовые станции 106 и 108 упоминаются в данном документе как вторичные базовые станции. Хотя ряд мобильных устройств 102 и базовых 104, 106 и 108 станций могут быть включены в систему 100 беспроводной связи, следует принимать во внимание, что для простоты проиллюстрировано одно мобильное устройство 102, которое передает сигналы данных, передаваемых по системам связи, в одну первичную базовую станцию 104, которая туннелирует эти сигналы в две вторичные базовые станции 106, и 108.
Например, мобильное устройство 102 может наблюдать радиосигнал (к примеру, форму пилотного сигнала) от вторичной базовой станции 106 и/или 108, однако наблюдаемый сигнал может быть недостаточно сильным (к примеру, слабый сигнал), чтобы предоставлять возможность прямой связи с вторичными базовыми станциями 106 или 108. Однако мобильному устройству 102 было бы желательно установить взаимосвязь с одной или более из вторичных базовых станций 106, 108 посредством установления туннеля через первичную базовую станцию 104 и получения зарезервированных ресурсов во вторичной базовой станции 106, 108. Если сигнал с одной или более из вторичных базовых станций 106, 108 становится более сильным, мобильному устройству 102 может быть желательным установить прямую связь с вторичными базовыми станциями 106, 108 на физическом уровне. Таким образом, туннель может быть установлен в ожидании наличия в конечном счете прямой связи с одной или более из вторичных базовых станций 106, 108. Туннель может резервировать ресурсы во вторичных базовых станциях 106, 108, что дает возможность мобильному устройству 102 устанавливать защищенную взаимосвязь с вторичными базовыми станциями 106, 108. Таким образом, плавная и/или эффективная передача обслуживания может достигаться по мере того, как обслуживание мобильного устройства 102 передается от первичной базовой станции 104 к вторичной базовой станции 106, 108.
Различные аспекты, раскрытые в данном документе, относятся к установлению и/или разрыву взаимосвязи (к примеру, маршрута или туннеля) между терминалом доступа 102 и базовыми станциями 106 и 108. Один или более из аспектов, раскрытых в данном документе, относятся к адресации или сигнализации, которая используется для установления и/или удаления туннелей. Дополнительно или альтернативно, некоторые из аспектов относятся к типу сообщений и типу функциональностей, которые могут быть реализованы посредством туннелей. Подробности, касающиеся этих аспектов, детально поясняются со ссылкой на следующие чертежи и подробное описание.
Фиг. 2 иллюстрирует систему 200, которая упрощает реализацию протокола маршрутизации в среде беспроводной связи. Система 200 включает в себя устройство 202 беспроводной связи, которое, как показано, передает данные по каналу. Хотя проиллюстрировано как передающее данные, устройство 202 беспроводной связи также может принимать данные по каналу (к примеру, устройство 202 беспроводной связи может одновременно передавать и принимать данные, устройство 202 беспроводной связи может передавать и принимать данные в различное время, выполнять комбинацию вышеозначенного и т.д.). Устройство 202 беспроводной связи, например, может быть мобильным устройством (к примеру, мобильным устройством 102 по фиг. 1). Для целей понимания устройство 202 беспроводной связи упоминается в данном документе как мобильное устройство 202.
В мобильное устройство 202 включен модуль 204 выбора маршрута, который может определять то, должен ли создаваться туннель через первичную базовую станцию к одной или более вторичных базовых станций. Этот туннель может давать возможность мобильному устройству 202 обмениваться данными с одной или более вторичных базовых станций через первичную базовую станцию. Туннель может реализовываться посредством протокола маршрутизации и протокола межмаршрутного туннелирования. Заголовки в этих протоколах предоставляют конкретную функциональность для различных туннелей. Заголовок создания маршрута включает в себя один или более параметров, ассоциированных с заданием туннеля. Например, заголовок создания маршрута может передавать информацию, связанную с персонализацией, выбранной для маршрута, идентификатор маршрута, должны ли существующие маршруты быть удалены, а также другие параметры, ассоциированные с созданием и/или удалением маршрутов (или туннелей).
Модуль 206 идентификатора маршрута может определять идентификатор маршрута (RouteID), который является различным для каждого туннеля, созданного посредством мобильного устройства 202. RouteID включается в заголовок создания маршрута посредством модуля 206 идентификатора маршрута. Как базовая станция, так и мобильное устройство могут обнаруживать неактуальные сообщения (сообщения, не направленные в экземпляр текущего используемого маршрута) посредством использования RouteID. Поскольку базовые станции создают и удаляют маршруты к мобильным устройствам, может быть возможность несовпадения между экземпляром маршрута в базовой станции и мобильном устройстве. Например, базовая станция может иметь экземпляр старого маршрута для мобильного устройства, даже если мобильное устройство создало новый маршрут. RouteID дает возможность базовой станции и мобильному устройству определять то, используется ли одинаковый экземпляр маршрута для осуществления связи, что может быть определено, когда экземпляр маршрута создан. Выполняется определение для передач через радиоинтерфейс и/или преобразования "один-к-одному" между MACID и RouteID.
Для туннелированной связи RouteID включается в заголовки протокола межмаршрутного туннелирования (IRTP). RouteID в IRTP-заголовке включается в передачу между базовыми станциями (в заголовок туннеля канального уровня), и наоборот.
В соответствии с некоторыми аспектами маршрут или туннель могут быть уже установлены с вторичной базовой станцией. В этой ситуации пакет может приниматься от базовой станции в ответ на запрос на создание маршрута. Пакет может включать в себя код ошибки уже установленного маршрута и идентификатор установленного маршрута. На основе этой информации мобильное устройство 202 может определить, что туннельная взаимосвязь уже установлена и, следовательно, не должна повторно устанавливаться.
Может быть несколько туннелей, ассоциированных с мобильным устройством 202. Например, мобильное устройство 202 может иметь несколько туннелей для нескольких (вторичных) базовых станций (к примеру, один туннель для базовой станции 106 по фиг. 1 и второй туннель для базовой станции 108). Каждый туннель имеет различный RouteID. В соответствии с некоторыми аспектами RouteID является семибитовым идентификатором, например семь из следующих неиспользуемых младших битов (LSB) RouteCounter.
В целях примера, а не ограничения, каждый раз, когда сообщения отправляются по туннелю, который уже установлен, мобильное устройство 202 отправляет сообщения в первичную базовую станцию, с которой оно непосредственно соединено. Первичная базовая станция перенаправляет сообщения в базовую станцию точки туннелирования (к примеру, вторичную базовую станцию). Когда первичная базовая станция отправляет сообщение во вторичную базовую станцию, сообщение включает в себя RouteID для каждого сообщения. В некоторых ситуациях, возможно, осуществляется попытка установления нескольких туннелей с одной и той же вторичной базовой станцией. Например, первый туннель установлен, а затем принимается ошибка, поскольку второй туннель установлен. Эти два туннеля имеют различные идентификаторы маршрута. Вследствие дрожания фазы или плохих условий распространения по сети сообщения могут начинать поступать во вторичную базовую станцию в некорректном порядке. Поскольку RouteID включается в каждое сообщение, вторичная базовая станция может отклонять сообщения, которые соответствуют уже несуществующему туннелю, который заменяется наличием другого туннеля (идентифицированного посредством RouteID). Таким образом, RouteID в каждом сообщении может уменьшать неактуальные сообщения, которые посланы в уже несуществующий туннель.
Другим полем, включенным в протокол маршрутизации, является персонализация, которая определяет персонализацию для маршрута, которая определяется посредством модуля 208 персонализации. Это определение может быть выполнено на основе заранее согласованных типов туннелей, которые поддерживаются посредством мобильного устройства 202. Персонализация - это совокупность типов протоколов и совокупность определенных значений атрибутов или параметров. Каждый протокол включает в себя атрибуты, которые указывают признаки, которые активируются в любой момент времени. Персонализация также может включать в себя номер версии для протокола. Чтобы подключение было возможным между мобильным устройством 202 и пунктом назначения (к примеру, базовой станцией на другом конце туннеля, вторичной базовой станцией), оба объекта (к примеру, мобильное устройство и вторичная базовая станция) должны согласовывать язык связи. После того как эти два объекта (к примеру, мобильное устройство и вторичная базовая станция) согласуют то, какая персонализация должна использоваться, может происходить обмен данными. Список заранее определенных персонализаций и заголовок создания маршрута могут идентифицировать то, какой язык должен использоваться в конкретном маршруте. Персонализация - это идентификатор начального набора протоколов (IPSI) и индекс персонализации (или идентификатор набора протоколов (PSI)). Если предусмотрен переключатель незавершенной персонализации, мобильное устройство присваивает персонализации значение незавершенной персонализации.
В соответствии с некоторыми аспектами персонализация, выбранная посредством модуля 208 персонализации, может не поддерживаться посредством вторичной базовой станции. В этой ситуации мобильное устройство 202 принимает код ошибки от вторичной базовой станции, указывающий, что персонализация не поддерживается. Мобильное устройство 202 также может принимать список персонализаций, которые поддерживаются и из которых модуль 208 персонализации может анализировать список и выбирать персонализацию, поддерживаемую посредством мобильного устройства 202. Пакет заголовка создания маршрута может модифицироваться так, чтобы включать в себя выбранную информацию персонализации, и передавать информацию в выбранную базовую станцию. В соответствии с некоторыми аспектами список персонализаций, принимаемых от базовой станции, ранжируется в порядке предпочтения, как определено посредством базовой станции. Если мобильное устройство поддерживает первую ранжированную персонализацию, эта персонализация используется. Если первая ранжированная персонализация не поддерживается, может быть использована вторая ранжированная персонализация и т.д.
В соответствии с некоторыми аспектами мобильное устройство 202 может иметь несколько персонализаций, активных практически одновременно. Например, мобильное устройство 202 имеет несколько открытых маршрутов (к примеру, поддерживает связь с несколькими вторичными базовыми станциями). Каждый маршрут может иметь различную персонализацию, которая является функцией от характеристик базовой станции и характеристик мобильного устройства.
Также в мобильное устройство 202 включен модуль 210 идентификатора терминала доступа (ATI), который используется посредством мобильного устройства 202 для того, чтобы указывать его идентификационные данные вторичной базовой станции с тем, чтобы между этими двумя объектами могла быть установлена связь. Идентификационные данные мобильного устройства включаются в заголовок идентификатора терминала доступа (ATI), который передает идентификатор терминала доступа (ATI). ATI-заголовок задается равным UATI (ATI для одноадресной передачи), если UATI назначен мобильному устройству. Если UATI не назначен мобильному устройству, ATI-заголовок задается равным RATI (случайный ATI).
Вторичная базовая станция может принимать ATI-заголовок и может передавать ATI-заголовок обратно в мобильное устройство, чтобы подтверждать, совпала ли базовая станция с корректным ATI для корректного мобильного устройства. Например, базовая станция может задавать ATI-заголовок равным значению ATI, принимаемому от мобильного устройства 202. Если ATI-заголовок, принимаемый от базовой станции, является корректным заголовком ATI (к примеру, ATI-заголовком, который соответствует мобильному устройству 202), мобильное устройство 202 может достигать состояния ATI привязки, которое указывает, что базовая станция и мобильное устройство 202 имеют сведения друг о друге. В соответствии с некоторыми аспектами ATI-заголовок может быть 128-битовым идентификатором мобильного устройства 202.
ATI-заголовок включается посредством мобильного устройства 202, если протокол подключенного состояния находится в состоянии BindATI. Например, мобильное устройство 202 остается в BindATI, если заголовок протокола маршрутизации, который содержит ATI-заголовок, идентичный заголовку ATI, отправляемому посредством мобильного устройства 202, не принимался от вторичной базовой станции. Мобильное устройство 202 выводит из состояния BindATI, если заголовок протокола маршрутизации, принимаемый от вторичной базовой станции, содержит идентичный ATI-заголовок, отправляемый посредством мобильного устройства 202.
Заголовок создания маршрута отсылается посредством передающего устройства 212, ассоциированного с мобильным устройством 202, до тех пор пока не будет принято подтверждение того, что вторичная базовая станция создавала туннель, и/или пока не принят пакет от базовой станции. Подтверждение указывает создание туннельной взаимосвязи. До тех пор пока это подтверждение не будет принято, мобильное устройство 202 находится в состоянии ожидания открытия, и мобильное устройство продолжает передавать заголовок создания маршрута. Состояние ожидания открытия указывает, что мобильное устройство 202 не приняло пакеты от вторичной базовой станции на этом маршруте. Передатчик 212 может продолжать отсылать заголовок создания маршрута до тех пор, пока подтверждение не будет принято. Практически одновременно с тем, как подтверждение принято, мобильное устройство 202 выходит (или переходит из) состояния ожидания открытия, и заголовок создания маршрута больше не отсылается посредством передающего устройства 212.
В соответствии с некоторыми аспектами практически одновременно с приемом ATI-заголовка от вторичной базовой станции, мобильное устройство 202 отсылает индикатор ATIReceived(ATIType, ATI, RouteStatus) (используемый посредством протокола подключенного состояния (CSP)). В соответствии с этими аспектами, если ATI-заголовок отсутствует или присутствует заголовок ErrorCode, RouteStatus задается равным Failure (0x1). В противном случае RouteStatus задается равным 0x0.
Следует отметить, что информация ATI-заголовка используется при осуществлении связи с вторичной базовой станцией, а не первичной базовой станцией, с которой мобильное устройство 202 имеет возможность прямого подключения на физическом уровне. Дополнительно, ATI-заголовок не отсылается во время передачи обслуживания. Однако ATI-заголовок отсылается один раз, когда устанавливается первое соединение с первой вторичной базовой станцией. После установления с первой вторичной базовой станцией (которая теперь знает идентификационные данные мобильного устройства), последующие туннели, которые устанавливаются с другими вторичными базовыми станциями, координируются друг с другом, чтобы совместно использовать идентификационные данные мобильного устройства 202. Таким образом, для последующего создания ATI-туннеля ATI-заголовок (и ATI-модуль 210), возможно, не должен выполнять последующие функции, если базовые станции могут передать информацию ATI-заголовка.
Таким образом, в некоторых ситуациях, базовая станция, к которой создается туннель (к примеру, вторичная базовая станция), возможно, не знает последний идентификатор мобильного устройства, поскольку адрес мобильного устройства изменялся. В случаях, если адрес не изменялся, обслуживающая базовая станция (к примеру, первичная базовая станция) может передать адрес во вторичную базовую станцию. Но если адрес изменялся в последнее время, обслуживающая базовая станция может не иметь сведений об изменении в адресе, поскольку изменение адреса - это процесс между SRNC (центральным контроллером) и мобильным устройством, о котором обслуживающая базовая станция не знает. Например, если адрес изменялся за последние X секунд (где X - это целое число, к примеру, 5 в одном примере), то мобильное устройство включает новый адрес во время создания маршрута, а в противном случае опускает адрес. Это дает возможность вторичной базовой станции иметь последнюю информацию об адресе мобильного устройства, если адрес недавно изменялся, и позволяет уменьшать объем служебной информации при включении адреса в случаях, если адрес не изменялся недавно.
Например, если мобильное устройство 202 установило туннели с различными базовыми станциями в одном географическом местоположении (к примеру, в Нью-Йорке), эти базовые станции должны иметь возможность передавать ATI-заголовок между собой. Но если мобильное устройство выключено, к примеру, если пользователь мобильного устройства летит в Феникс, мобильное устройство должно создавать и передавать заголовок создания маршрута, который включает в себя информацию ATI-заголовка, в базовые станции, находящиеся в области Феникса.
Согласно некоторым аспектам, для того чтобы передать сообщение, которое включает в себя заголовок создания маршрута, выполняется определение в отношении того, должны ли два или более пакетов протокола консолидации пакетов переноситься в одном MAC-пакете. Каждый пакет протокола консолидации пакетов включает в себя запись элемента заголовка. Если несколько пакетов протокола консолидации пакетов должны отсылаться, запись элемента заголовка из всех кроме одного из пакетов протокола консолидации пакетов может быть опущена, что позволяет экономить ресурсы и повышать эффективность системы 200.
В соответствии с некоторыми аспектами сеанс с сетью, возможно, должен закрываться вследствие различных ситуаций (к примеру, учетные данные мобильного устройства истекли). Если сеанс должен быть закрыт, мобильное устройство может принимать пакет, который включает в себя код ошибки закрытия сеанса и CRCErrorDetectPattern, от вторичной базовой станции. Мобильное устройство 202 может повторно аутентифицироваться в сети (которая включает в себя вторичную базовую станцию), если CRCErrorDetectPattern указывает, что код ошибки кода сеанса не обусловлен ошибкой в линии связи.
Модуль 214 удаления маршрута может определить, что конкретный маршрут или туннель должен быть удален, и, в соответствии с некоторыми аспектами, новый туннель запущен. Модуль 214 удаления маршрута может конфигурировать бит, в заголовке создания маршрута, чтобы указать, что маршрут должен быть удален. Этот бит может упоминаться как бит "удаления старого маршрута". В соответствии с некоторыми аспектами бит удаления старого маршрута составляет один бит по длине. Если модуль 214 удаления маршрута задает этот бит равным "1", это дает возможность удаления и перезапуска туннеля при необходимости. Если бит удаления старого маршрута задается равным "0", это указывает, что маршруты не должны быть удалены. В соответствии с некоторыми аспектами мобильному устройству может быть желательным сбросить туннель вследствие сбоя, чтобы изменить персонализацию или по другим причинам. Триггеры, которые могут указывать, должен ли быть задан флаг удаления старых маршрутов, могут включать в себя ситуацию, когда мобильное устройство потеряло состояние протокола линии радиосвязи (RLP).
Например, источник питания вынут из мобильного устройства 202 или возникает сбой, приводящий к тому, что мобильное устройство 202 теряет отслеживание предыдущих настроек, включая все туннели, которые, возможно, установлены. Мобильному устройству 202 может потребоваться сброс туннеля и состояния различных действий, к примеру, если мобильное устройство 202 согласовывало определенные фильтры пакетов и/или атрибуты и вследствие сбоя мобильное устройство 202 "забыло" то, что согласовано. Таким образом, мобильное устройство должно удалить туннель и запустить процесс установления туннеля повторно.
В соответствии с некоторыми аспектами, относительно IRTP-заголовков, мобильное устройство 202 использует заголовок идентификатора узла (или сети) доступа (ANID), если RCP (протокол управления маршрутизацией) находится в состоянии ожидания открытия. ANID-заголовок выдается в ответ на сообщение RouteCreate. В соответствии с некоторыми аспектами мобильное устройство 202 не использует заголовок RouteID для маршрута назначения, если сообщение RouteMap, содержащее преобразование ANID к RouteID для этого маршрута назначения, не отправлялось в эту базовую станцию. Таким образом, когда мобильное устройство туннелируется через первую базовую станцию (к примеру, первичную базовую станцию) к другой (к примеру, вторичной) базовой станции, применяются различные технологии адресации. Например, определенные технологии используют более длинный адрес, который упоминается как ANID, и предусмотрен более короткий адрес, называемый идентификатором маршрута. Более короткий адрес (к примеру, идентификатор маршрута) может быть использован после того, как мобильное устройство установило то, что преобразование между более длинным адресом и более коротким адресом является доступным для (вторичной) базовой станции. Мобильное устройство может предоставлять таблицу (к примеру, сообщение маршрутной карты), указывающую, какой короткий адрес преобразуется в какой более длинный адрес. Преобразование может сохраняться в базовой станции. Если принимается идентификатор маршрута, который базовая станция не распознает, базовая станция может отправить сообщение запроса, запрашивающее, чтобы мобильное устройство сообщило, какой ANID соответствует идентификатору маршрута. Мобильное устройство может ответить с ANID.
Согласно некоторым аспектам мобильное устройство может принимать сообщение RouteMapRequest, запрашивающее карту текущего маршрута, если обслуживающая (к примеру, первичная) базовая станция принимает заголовок RouteID (короткий адрес) и не распознает RouteID. Мобильное устройство может передавать маршрутную карту на основе запроса. В соответствии с некоторыми аспектами мобильное устройство не использует заголовок RouteID для маршрута назначения, если сообщение RouteMap, содержащее преобразование ANID в RouteID для этого маршрута назначения, не отправлялось в эту базовую станцию (к примеру, сеть доступа).
Фиг. 3 иллюстрирует систему 300, которая упрощает реализацию протокола маршрутизации в среде беспроводной связи. Система 300 включает в себя устройство 302 беспроводной связи, которое, как показано, передает данные по каналу. Хотя проиллюстрировано как передающее данные, устройство 302 беспроводной связи также может принимать данные по каналу (к примеру, устройство 302 беспроводной связи может одновременно передавать и принимать данные, устройство 302 беспроводной связи может передавать и принимать данные в различное время, комбинация вышеозначенного и т.д.). Устройство 202 беспроводной связи, например, может быть базовой станцией (к примеру, базовой станцией 104, 106 или 108 по фиг. 1). Устройство 302 может задавать различные коды ошибок в ответ на заголовок создания маршрута, принимаемый посредством мобильного устройства. Для целей понимания устройство 302 упоминается как базовая станция 302 в последующем пояснении.
Базовая станция 302 может принимать заголовок создания маршрута от мобильного устройства (такого как мобильное устройство 102 по фиг. 1, мобильное устройство 202 по фиг. 2). Практически одновременно с приемом этого заголовка базовая станция 302 игнорирует заголовок, если протокол создания маршрута (RCP) не находится в состоянии ожидания открытия или в состоянии ожидания закрытия. Если DeleteOldRoutes задан (к примеру, равным "1"), базовая станция 302 выдает команду DeleteOldRoutes, которая используется посредством RCP для того, чтобы удалять существующие маршруты с этим мобильным устройством. Если RCP находится в состоянии ожидания закрытия, индикатор RouteReopen отправляется посредством базовой станции 302. Этот RouteReopen используется RCP для того, чтобы переходить в открытое состояние.
Модуль 304 подтверждения идентификатора терминала доступа (ATI) выполнен с возможностью подтверждать, что ATI, принимаемый от мобильного устройства, является корректным ATI для этого мобильного устройства. Чтобы подтверждать эту информацию, модуль 304 подтверждения ATI может задавать значение ATI в заголовке ATI равным значению ATI, принимаемому от мобильного устройства, и отправлять ответ. Мобильное устройство, после приема ATI-заголовка, который включает в себя ATI, может подтверждать, что базовая станция 302 корректно (или некорректно) идентифицировала мобильное устройство.
Модуль 306 поддерживаемых персонализаций может определять, поддерживается ли персонализация, выбранная мобильным устройством для туннеля, посредством базовой станции 302. Если персонализация не поддерживается, может отправляться код ошибки персонализации. В соответствии с некоторыми аспектами этот код ошибки задается посредством "0000". Персонализация - это комбинация типов протоколов и атрибутов. Если базовая станция 302 не поддерживает один или более из комбинации типов протоколов и атрибутов, код ошибки персонализации отправляется в мобильное устройство, чтобы мобильное устройство могло выбирать новую персонализацию.
Практически одновременно с тем, как код ошибки персонализации (к примеру, код ошибки 0000) передается в мобильное устройство, список предлагаемых персонализаций, которые должно использовать мобильное устройство, также может отправляться посредством базовой станции 302. Список персонализаций, поддерживаемых посредством базовой станции 302, может сохраняться посредством модуля 306 поддерживаемых персонализаций. Если персонализация, выбранная посредством мобильного устройства, не включена в этот список, модуль 306 поддерживаемых персонализаций указывает, что он не поддерживает выбранную персонализацию, и предоставляет предложения относительно других персонализаций, которые мобильное устройство может выбирать из тех, которые поддерживаются посредством базовой станции 302.
Персонализации, поддерживаемые посредством базовой станции 302, которые отправляются в мобильное устройство, могут быть функцией от идентификационных данных мобильного устройства (к примеру, идентифицированного посредством модуля 304 подтверждения ATI). На основе идентификационных данных мобильного устройства базовая станция 302 может определять то, какие персонализации должны быть подходящими для мобильного устройства, что является функцией от характеристик базовой станции 302 и требований этого конкретного мобильного устройства. Например, базовая станция 302 имеет сведения о персонализациях или протоколах, которые она может поддерживать (к примеру, программные и аппаратные характеристики базовой станции). Таким образом, если идентификационные данные мобильного устройства указывают, что оно является устройством с низким уровнем мощности, базовая станция 302 может выполнять функции иначе с этим мобильным устройством, чем базовая станция 302 выполняет с мобильным устройством с высоким уровнем мощности. Например, некоторые персонализации могут иметь режимы энергосбережения, тогда как другие персонализации не поддерживают режимы энергосбережения, и т.д.
В соответствии с некоторыми аспектами базовая станция 302 осуществляет доступ к сеансовому опорному сетевому контроллеру (SRNC) и запрашивает подробную информацию, касающуюся мобильного устройства, на основе ATI. Подробная информация может включать в себя приложения, поддерживаемые посредством мобильного устройства. Например, SRNC может включать в себя информацию о том, является мобильное устройство видеотелефонным устройством, устройством передачи речи, устройством передачи только данных и т.д. SRNC является центральным объектом в сети и может функционировать аналогично базе данных. На основе информации, получаемой из SRNC, которая включает в себя интерпретацию идентификаторов персонализации, принимаемых в заголовке создания маршрута, базовая станция 302 может предлагать одну или более персонализаций, которые мобильное устройство может использовать для того, чтобы устанавливать туннель с базовой станцией 302. Персонализации могут быть ранжированы в порядке предпочтения.
В соответствии с некоторыми аспектами мобильное устройство может пытаться создавать новый туннель, когда уже имеет действующий туннель с базовой станцией 302. Модуль 308 обнаружения дублированного маршрута может верифицировать, что маршрут уже существует, и может отправлять код ошибки, чтобы извещать мобильное устройство о том, что уже есть туннель, установленный с мобильным устройством, и, следовательно, новый запрос на туннелирование отклоняется. В этой ситуации флаг удаления всех маршрутов задается равным нулю, тем самым мобильное устройство не запрашивает сброс или повторное создание туннеля, а запрашивает открытие маршрута (который является дубликатом) с базовой станцией 302. В соответствии с некоторыми аспектами код ошибки уже существующего маршрута задается посредством "0001".
Примером того, когда запрос на то, чтобы создавать туннель, отклоняется, является ситуация, когда мобильное устройство инициирует создание туннеля на основе пилотных сигналов, которые оно принимает от базовой станции 302. Базовая станция 302 может излучать несколько пилотных сигналов, как если бы она являлась многосекторной базовой станцией 302, которая излучает несколько пилотных сигналов. Мобильное устройство может обнаруживать первый пилотный сигнал и создавать туннель. Когда мобильное устройство обнаруживает второй или другие пилотные сигналы, оно может пытаться создать второй или более туннелей, поскольку, когда запрос на туннелирование выполняется, оно не знает о том, что это та же базовая станция 302, с которой взаимосвязь уже существует. Таким образом, второй (или более) туннель не требуется, и базовая станция 302 может отправить код ошибки уже существующего маршрута, указывающий, что эти туннели не требуются.
В соответствии с некоторыми аспектами модуль 310 закрытия сеанса включен в базовую станцию 302. Модуль 310 закрытия сеанса может обнаруживать серьезную ошибку относительно мобильного устройства и может автоматически закрывать сеанс с мобильным устройством. В соответствии с некоторыми аспектами модуль 310 закрытия сеанса принимает инструкции от сеансового опорного сетевого контроллера, которые указывают то, что сеанс должен быть закрыт. Код ошибки может отправляться в мобильное устройство, указывающее эту ошибку. В соответствии с некоторыми аспектами этот код ошибки задается посредством "0010". Например, мобильное устройство может пытаться инициировать установление туннеля или может пытаться обмениваться данными через туннель. Сеть доступа может обнаруживать, что подписка (к примеру, доступ к сети) неактуальна (к примеру, есть значительный непогашенный остаток на поддержание подписки). Эта информация может получаться, когда базовая станция 302 осуществляет доступ к SRNC для того, чтобы определять конфигурацию мобильного устройства. SRNC может указывать, что учетные данные мобильного устройства истекли, и мобильное устройство не должно иметь доступ к сети. Таким образом, эта ошибка отправляется, чтобы закрывать сеанс. После того как сеанс закрыт, мобильное устройство должно повторно аутентифицироваться в сети, чтобы получить доступ к сети. Повторная аутентификация может включать в себя представление ключей защиты, чтобы дать возможность сети верифицировать, разрешено ли мобильному устройству входить в сеть. В соответствии с некоторыми аспектами мобильное устройство может пытаться получать доступ к сети через другой набор ключей защиты или другими способами восстановления доступа к сети.
Ошибка закрытия сеанса - это серьезная операция, поскольку мобильному устройству не разрешается иметь доступ к сети до тех пор, пока оно не сможет повторно установить свои учетные данные безопасности. Таким образом, при отправке ошибки закрытия сеанса, модуль 310 закрытия сеанса может включать шаблон обнаружения ошибок CRC-контролем. CRC-контроль может быть x-битовой строкой из "1" и "0", которые чередуются определенное количество раз, где x - целое число, и в соответствии с некоторыми аспектами x составляет шестнадцать. Таким образом, если имеется ошибка в пакете физического уровня, эта заранее заданная конфигурация может не совпадать с той, которую мобильное устройство ожидает, и позволяет уменьшать ошибочные закрытия сеанса (к примеру, так что сеанс не закрывается вследствие ошибки в линии связи). Практически одновременно с тем, как мобильное устройство принимает эту ошибку, если конфигурация CRC-контроля совпадает, мобильное устройство возвращает CloseSession, который используется протоколом управления сеансом (SCP), чтобы закрывать сеанс.
Модуль 312 наличия сеанса может определять, имеет или нет мобильное устройство существующий маршрут с базовой станцией 302. Это определение может быть выполнено на основе приема пакета, который не включает в себя заголовок создания маршрута, и определения, что маршрут не установлен с мобильным устройством. Мобильное устройство находится не в состоянии ожидания открытия, когда эта ошибка возникает. Этот сценарий может возникать, когда мобильное устройство принимает форму пилотного сигнала и полагает, что форма пилотного сигнала принадлежит одной из существующих базовых станций, с которыми взаимосвязь уже установлена. Однако форма пилотного сигнала принадлежит базовой станции, с которой взаимосвязь не установлена. Если маршрут не существует, модуль 312 наличия сеанса задает бит кода ошибки, чтобы указать, что маршрут не принадлежит базовой станции 302. В соответствии с некоторыми аспектами этот код ошибки указывается посредством "0011".
Код ошибки отсутствия маршрута может возникать вследствие понятия постоянного маршрута. В некоторых случаях, когда мобильное устройство находится в состоянии бездействия (к примеру, нет обмена данными), мобильное устройство имеет один постоянный маршрут (называемый маршрутом SRNC). Когда мобильное устройство выходит из состояния бездействия и пытается устанавливать соединение, мобильное устройство пытается подключиться к конкретной базовой станции (к примеру, базовой станции, от которой он принимает сильный сигнал). Мобильное устройство выполняет определение того, является ли эта базовая станция той же базовой станцией, с которой у него имеется уже существующий маршрут, или она является новой базовой станцией. Если маршрут считается существующим маршрутом, то мобильное устройство не отправляет заголовок создания маршрута и предполагает, что туннель или маршрут уже установлен. Мобильное устройство будет начинать отправку пакетов, как если бы маршрут уже был установлен. Однако в некоторых случаях мобильное устройство делает ошибку, и это не та же базовая станция, с которой мобильное устройство имеет установленный маршрут, а новая базовая станция. Новая базовая станция может указать мобильному устройству, что новая базовая станция не имеет маршрута с мобильным устройством, и при этом новая базовая станция не имеет сведений об этом мобильном устройстве, и может запросить заголовок создания маршрута.
Эти ситуации могут возникать, когда мобильное устройство находится в пограничной области. Мобильное устройство, возможно, первоначально создало маршрут с исходной базовой станцией, и затем мобильное устройство потеряло контакт с этой базовой станцией. Однако мобильное устройство входит в покрытие новой базовой станции с аналогичной частотой и/или пилотными сигналами pn и начинает отправку информации в новую базовую станцию, как если бы она была существующей базовой станцией. Однако с новой базовой станцией нет соединения. Практически одновременно с приемом этого кода ошибки мобильное устройство может создать новый маршрут, чтобы обмениваться данными с новой базовой станцией.
Также включен модуль 314 сбоя UATI, который может определять то, изменялся ли идентификатор терминала мобильного устройства, и, если имеется изменение, может передаваться код ошибки сбоя UATI. В соответствии с некоторыми аспектами этот код ошибки задается посредством "0100". В соответствии с некоторыми аспектами идентификационные данные мобильного устройства могут являться ошибочными на основе информации, принятой от сеансового опорного сетевого контроллера. Эта ситуация может возникать, когда UATI (идентификатор терминала) мобильного устройства изменяется практически одновременно с тем, как создается новый маршрут. Например, когда мобильное устройство пытается устанавливать новый маршрут или туннель с удаленной базовой станцией (к примеру, вторичной базовой станцией), мобильное устройство не включает собственный UATI в процессе создания маршрута. UATI совместно используется между базовыми станциями по транзитному соединению. Базовая станция, с которой мобильное устройство соединено напрямую непосредственно (к примеру, первичная базовая станция), передает информацию в новую базовую станцию, идентифицированную мобильным устройством. Если UATI изменился, новая добавленная базовая станция может отправить код ошибки, чтобы указать, что UADI более недействителен. Практически одновременно с приемом кода ошибки мобильное устройство возвращает индикатор UATIFailed (используемый посредством RCP для разъединения маршрута). Мобильное устройство может создать новый маршрут к этой базовой станции после того, как UATI обновлен.
В соответствии с некоторыми аспектами, относительно IRTP-заголовков, базовая станция 302 не использует заголовок идентификатора узла доступа (ANID) до тех пор, пока RouteMap не будет принят. Если базовая станция 302 принимает заголовок RouteID, и базовая станция не распознает RouteID, происходит следующее. Если RCP находится в состоянии ожидания открытия, базовая станция доставляет полезную нагрузку в протокол маршрутизации для маршрута SessionAnchor. В противном случае базовая станция отправляет сообщение RouteMapRequest в мобильное устройство, чтобы запросить карту текущего маршрута.
Согласно некоторым аспектам заголовок RouteID (короткий адрес) может приниматься от мобильного устройства, однако обслуживающая базовая станция не распознает заголовок RouteID. В этой ситуации обслуживающая базовая станция может отправить сообщение RouteMapRequest в мобильное устройство, запрашивающее карту текущего маршрута. В соответствии с некоторыми аспектами мобильное устройство не использует заголовок RouteID для маршрута назначения, если сообщение RouteMap, содержащее преобразование ANID к RouteID для этого маршрута назначения, не отправлялось в эту сеть доступа (к примеру, базовую станцию).
Для полного понимания раскрытых аспектов фиг. 4 иллюстрирует два примера пакетов 400 и 402 протокола маршрутизации. Пакет 400 протокола маршрутизации включает в себя полезную нагрузку 404 протокола маршрутизации и заголовок 406 протокола маршрутизации. Пакет 402 протокола маршрутизации включает в себя заголовок 406 протокола маршрутизации. Пакет 400, 402 протокола маршрутизации добавляет заголовок 406 протокола маршрутизации, чтобы передавать параметры, используемые для идентификации стека протоколов, ассоциированного с этим маршрутом, либо протоколы межмаршрутного туннелирования этого или другого маршрута. Пакет 400, 402 протокола маршрутизации также может определять, должны пакеты протокола маршрутизации для передачи доставляться в протокол консолидации пакетов этого маршрута, либо в протокол межмаршрутного туннелирования этого или другого маршрута. Маршрут включает в себя стек протоколов InUse, ассоциированный с сетью доступа.
Протокол 400, 402 может возвращать различные индикаторы, которые могут включать в себя ATIReceived(ATIType, ATI, RouteStatus), PersonalityFailure, RouteExists, RouteReopen, UATIFailed, RouteDoesNotExist. В соответствии с некоторыми аспектами протокол 400, 402 может делать общедоступным подтип для этого протокола, последний переданный ATI (только для мобильного устройства) и данные, заданные как статические атрибутные данные, статические неатрибутные данные и локальные общие данные. Протокол 400 принимает пакет от вышележащего уровня (к примеру, пакет 408 протокола управления потоком) и доставляет его на нижележащий уровень (к примеру, протокол 410 консолидации пакетов).
Фиг. 5 иллюстрирует примерные заголовки 500 протокола маршрутизации и то, как эти различные заголовки взаимодействуют. Далее поясняются подробности, касающиеся различных полей, перед пояснением примерных заголовков 500 протокола маршрутизации. Следует отметить, что соглашение об именах, длины и настройки этих полей приводятся в целях иллюстрации, и другие соглашения об именах, длины и/или настройки могут быть использованы в раскрытых аспектах.
Заголовок протокола маршрутизации может иметь поле ExtendedHeaderIncluded, которое может составлять около одного бита по длине. Отправитель может задавать поле ExtendedHeaderIncluded равным "1", если одна или более записей HeaderElement включены. В противном случае, отправитель может задавать это поле равным "0". Если поле ExtendedHeaderIncluded задано равным "1", отправитель должен включать одно или более появлений следующей записи HeaderElement, которыми являются MoreHeader или HeaderType. Таким образом, заголовок протокола маршрутизации может иметь нуль или более экземпляров HeaderElement, которые, в соответствии с некоторыми аспектами, могут составлять 8n битов по длине.
Формат HeaderElement может включать в себя поле MoreHeader, которое может составлять примерно один бит по длине. Отправитель может задавать поле MoreHeader равным "1", если есть другая запись HeaderElement после этой записи HeaderElement. Иначе отправитель может задавать это поле равным "0".
Формат HeaderElement может включать в себя поле HeaderType, которое составляет приблизительно три бита по длине. Это поле задается отправителем, чтобы указывать тип записи HeaderElement. Если значение HeaderType равно 000 (двоичный формат), RouteCreation задается для обратной линии связи. Если значение HeaderType равно 001, запись ATI HeaderElement задается. Если HeaderType равно 010, запись ErrorCode HeaderElement задается для прямой линии связи. Для других значений задается запись Reserved HeaderElement.
Также в формат HeaderElement могут включаться поля HeaderTypeSpecific, которые могут иметь переменные длины, и поле Reserved, которое может составлять от нуля до приблизительно семи битов по длине, в зависимости от потребности.
Если поле HeaderType задано равным "000", мобильное устройство может включать HeaderTypeSpecificFields переменной длины. Эти поля могут включать в себя поле PSIIncluded, которое составляет приблизительно один бит по длине. Поле PSIIncluded задается равным "1" посредством мобильного устройства, если поле PSI включено в этот заголовок. Мобильное устройство задает поле PSIIncluded равным "0", если поля IPSI и PersonalityIndex включены в этот заголовок.
Поле IPSI, которое составляет нуль или приблизительно четыре бита по длине, является еще одним полем HeaderTypeSpecific. Мобильное устройство может опускать поле IPSI, если поле PSIIncluded задано равным "1". В противном случае, мобильное устройство включает это поле. Мобильное устройство задает поле ISPI равным InitialProtocolSetIdentifier, соответствующим персонализации, выбранной для маршрута. Когда персонализация, выбранная для этого маршрута, соответствует сохраненной персонализации, это поле задается равным InitialProtocolSetIdentifier, ассоциированным с сохраненной персонализацией.
Также включается поле PersonalityIndex, которое может составлять нуль или приблизительно четыре бита по длине. Мобильное устройство опускает поле PersonalityIndex, если поле PSIIncluded задано равным "1". В противном случае мобильное устройство включает это поле. Поле, если включено, задается равным PersonalityIndex персонализации, выбранной для этого маршрута. Когда персонализация, выбранная для этого маршрута, не соответствует сохраненной персонализации (к примеру, IPSI), мобильное устройство задает это поле равным "1111".
Поле PSI составляет нуль или примерно шестнадцать битов по длине. Мобильное устройство опускает это поле, если поле PSIIncluded задано равным "0". В противном случае мобильное устройство включает это поле. Если это поле включено, мобильное устройство задает это поле равным ProtocolSetIdentifier, соответствующим персонализации, выбранной для этого маршрута.
Дополнительно, HeaderTypeSpecificFields может включать в себя RouteID, которое составляет приблизительно семь битов по длине. Мобильное устройство задает поле RouteID равным RouteID, назначенным этому маршруту (общедоступные данные RouteID протокола управления маршрутизацией).
Поле DeleteOldRoutes, которое составляет приблизительно один бит по длине, также может быть включено. Мобильное устройство задает это поле равным "1", если сеть доступа должна удалять все существующие маршруты к этому мобильному устройству, если они имеются.
Если поле HeaderType задано равным "001", отправитель включает поле ATIType, которое составляет приблизительно два бита по длине. Отправитель задает это поле следующим образом. Если ATIType равно "00" или "01", ATIType Description зарезервировано. Если ATIType равно "10", ATIType Description - это ATI для одноадресной передачи (UATI) и составляет приблизительно сто двадцать восемь битов по длине. Если ATIType равно "11", ATIType Description - это случайный ATI (RATI) и составляет приблизительно сто двадцать восемь битов по длине.
Также включено поле ATI, которое составляет приблизительно сто двадцать восемь битов по длине. Если поле ATIType задано равным "10", отправитель задает это поле равным UATI (к примеру, общедоступные данные CurrentATI протокола управления маршрутизацией), соответствующему этому мобильному устройству. Если поле ATIType задано равным "11", отправитель задает это поле равным RATI (к примеру, общедоступные данные CurrentATI протокола управления маршрутизацией), соответствующему этому мобильному устройству. Также включено SessionSignatureLSB, которое составляет приблизительно два бита по длине. Отправитель задает это поле равным двум LSB в SessionSignature.
Если поле HeaderType задано равным "010", сеть доступа включает следующую запись переменной длины. Поле ErrorCode, которое составляет приблизительно четыре бита по длине. Сеть доступа задает поле ErrorCode следующим образом, чтобы указывать код ошибки. Если ErrorCode равен 0000 (двоичный формат), это указывает, что персонализация не поддерживается. Код ошибки 0001 указывает, что маршрут существует. Код ошибки 0010 указывает закрытый сеанс. Код ошибки 0011 указывает, что маршрут не существует. Код ошибки 0100 указывает, что UATI является ошибочным. Другие значения кода ошибки зарезервированы.
Также может быть включено RouteID, которое составляет нуль или приблизительно семь битов по длине. Сеть доступа опускает поле RouteID, если поле ErrorCode не задано равным "0001". В противном случае сеть доступа включает это поле и задает его равным RouteID, соответствующему существующему маршруту.
CRCErrorDetectPattern, которое составляет нуль или шестнадцать битов по длине, также может быть включено. Сеть доступа опускает это поле, если поле ErrorCode не задано равным "0010". В противном случае сеть доступа включает это поле и задает его равным "1010101010101010".
Отправитель включает поле длиной от нуля до семи битов, чтобы делать эту запись HeaderElement выровненной по октету. Отправитель задает эти биты равными нулю. Приемное устройство игнорирует эти биты.
На фиг. 5 проиллюстрирован пакет 502 протокола маршрутизации, который включает в себя пакет 504 протокола управления потоком и поле 506 включения расширенного заголовка (ExHeaderIncl). В этом пакете 502 поле ExHeaderIncl задается равным "0", что указывает то, что расширенный заголовок не включен.
Пакет протокола маршрутизации с заголовком 508 создания маршрута также проиллюстрирован. Этот пакет 508 включает в себя пакет 504 протокола управления потоком и поле 506 ExHeaderIncl, которое для этого пакета 508 задается равным "1", чтобы указывать то, что имеется включенный расширенный заголовок. Другим полем, которое также включается, является поле 508 More, которое задается равным "0". Поле More указывает, включено ли более одного заголовка одновременно, или то, может ли в одном пакете быть более одного заголовка. Поле 510 Type задается равным "созданию маршрута", чтобы указать, что заголовок - это заголовок создания маршрута и поле 512 Value, которое указывает поля создания маршрута. Также включено поле 514 Reserved.
Пакет протокола маршрутизации с заголовками 516 создания маршрута и ATI включает в себя пакет 504 протокола управления потоком и поле 506 ExHeaderIncl, которое задается равным "1". Также включено поле 508 More, которое задается равным 1, и поле 510 Type, указывающее создание маршрута. Также включено поле 512 Value, которое указывает поля создания маршрута. Этот пакет 516 также включает в себя два поля 514 Reserved. Дополнительно включено второе поле 520 More, заданное равным "0", и поле 522 Type, которое указывает UATI. Также включено поле 524 Value, заданное равным UATI.
В соответствии с некоторыми аспектами, если несколько пакетов протокола консолидации пакетов должны переноситься в одном MAC-пакете, записи HeaderElement во всех пакетах консолидации пакетов кроме первого в MAC-пакете могут быть опущены. Это позволяет уменьшать объем служебной информации в случае, если несколько пакетов отправляются вместе, и все они совместно используют один заголовок. Мобильное устройство может выполнять оптимизацию и включать заголовок только в первый пакет. Это позволяет экономить ресурсы радиоинтерфейса, чтобы повышать эффективность или оптимизировать систему.
Ссылочной позицией 526 обозначен пакет протокола маршрутизации с заголовком кода ошибки. Включены поле 528 Padding ("0000000"), поле 514 Reserved и поле 506 ExtHeaderlncl, которое задается равным "1". Также включено поле 508 More, заданное равным "0", и поле 510 Type, заданное равным "Error Code". Для этого пакета 526 поле 512 Value задается равным конкретным полям ErrorCode.
Принимая во внимание примерные системы, показанные и описанные выше, технологии, которые могут быть реализованы в соответствии с раскрытым изобретением, должны лучше пониматься со ссылкой на нижеследующие блок-схемы последовательности операций способа. Хотя, в целях упрощения пояснения, технологии показаны и описаны как последовательность этапов, необходимо понимать и принимать во внимание, что заявленное изобретение не ограничено числом или порядком этапов, поскольку некоторые этапы могут осуществляться в другом порядке и/или практически одновременно с этапами, отличными от этапов, показанных и описанных в данном документе. Кроме того, не все проиллюстрированные этапы могут требоваться для того, чтобы реализовать технологии, описанные далее. Следует принимать во внимание, что функциональность, ассоциированная с этапами, может быть реализована посредством программного обеспечения, аппаратных средств, их комбинации или любых других подходящих средств (к примеру, устройства, системы, процесса, компонента). Дополнительно, следует принимать во внимание, что технологии, раскрываемые далее и по всему подробному описанию, допускают сохранение в изделии, чтобы упрощать перенос и передачу этих технологий в различные устройства. Специалисты в данной области техники должны понимать и принимать во внимание, что технологии альтернативно могут быть представлены как последовательность взаимосвязанных состояний или событий, к примеру, на диаграмме состояний.
Фиг. 6 иллюстрирует способ 600 для создания туннельной взаимосвязи между мобильным устройством и базовой станцией. Туннельные взаимосвязи могут предоставлять плоские сетевые архитектуры посредством предоставления возможности мобильному устройству обмениваться данными с отдельными узлами сотовой связи (к примеру, базовыми станциями) независимо без центрального контроллера. Подход использования нескольких маршрутов также может упрощать обмен данными между мобильным устройством и базовой станцией, а также обмен данными между интерфейсами базовой станции.
Способ 600 начинается на этапе 602, когда осуществляется выбор, по меньшей мере, одной базовой станции, чтобы устанавливать связь через туннель. Это решение может приниматься на основе формы пилотного сигнала, который обнаруживается от базовой станции, с которой мобильное устройство не имеет прямого подключения. Туннель может быть установлен от мобильного устройства, через базовую станцию, с которой у мобильного устройства есть прямое подключение (к примеру, первичную базовую станцию), к одной или более вторичных базовых станций.
На этапе 604 сообщение, которое включает в себя заголовок создания маршрута, передается в одну или более выбранных базовых станций. Это сообщение может отправляться через первичную базовую станцию. Заголовок создания маршрута включает в себя один или более параметров, ассоциированных с заданием туннеля. В заголовок создания маршрута включаются различные поля, которые могут включать в себя идентификатор терминала доступа (ATI), выбор персонализации, идентификатор маршрута, информацию о том, должны ли существующие маршруты быть удалены, и т.д. Например, идентификатор для туннеля, по меньшей мере, к одной базовой станции может быть создан, и персонализация для туннеля выбрана, при этом персонализация включает в себя один или более типов протоколов и одно или более значений атрибутов. Идентификатор туннеля и выбранная персонализация могут быть включены в заголовок создания маршрута. Когда новый маршрут должен быть создан, мобильное устройство находится в состоянии "ожидания открытия". Это состояние указывает, что пакет или подтверждение создаваемого туннеля еще не принято от (вторичной) базовой станции.
В соответствии с некоторыми аспектами передача сообщения включает в себя определение того, должны ли один или более пакетов протокола консолидации пакетов переноситься в одном MAC-пакете. Каждый пакет протокола консолидации пакетов включает в себя запись элемента заголовка. Таким образом, записи элемента заголовка из всех кроме одного из пакетов протокола консолидации пакетов могут быть опущены, что позволяет экономить ресурсы и повышать эффективность.
В соответствии с некоторыми аспектами протокол управления маршрутизацией выбирает InitialProtocolSetIdentifier или PersonalityIndex, чтобы описывать персонализацию нового стека протоколов. Если служебная информация, соответствующая этим пилотным сигналам, доступна, InitialProtocolSetIdentifier, соответствующий выбранной персонализации, равен одному из значений InitialProtocolSetIdentifier, оповещаемых посредством сети доступа, соответствующей этим пилотным сигналам; в противном случае терминал доступа может выбрать InitialProtocolSetIdentifier или PersonalityIndex на основе определяемого реализацией решения.
Способ 600 может ожидать подтверждения заголовка создания маршрута. На этапе 606 выполняется определение в отношении того, принято ли подтверждение запроса на туннелирование от (вторичной) базовой станции. Подтверждение указывает создание туннельной взаимосвязи между мобильным устройством и базовой станцией. Подтверждение может включать в себя прием пакета, по меньшей мере, от одной базовой станции. Если подтверждение не принято, "НЕТ", то на этапе 608 выполняется определение в отношении того, принят ли один или более кодов ошибок. Если ни одного кода ошибок не принято, "НЕТ", способ переходит к этапу 604, когда сообщение повторно передается. Если один или более кодов ошибок приняты, "ДА", то на этапе 610 коды ошибок корректируются, и способ переходит к этапу 604. Дополнительная информация, касающаяся этих кодов ошибок, предоставлена ниже.
Если определение на этапе 606 состоит в том, что подтверждение принято, "ДА", то на этапе 612 выполняется определение в отношении того, включает ли подтверждение в себя прием заголовка от (вторичной) базовой станции, которая включает в себя поле ATI, которое задано равным полю ATI, переданному посредством мобильного устройства в заголовке создания маршрута. Если поля ATI совпадают, "ДА", это указывает, что (вторичная) базовая станция распознает это мобильное устройство. Если поля не совпадают, "НЕТ", то базовая станция не распознает мобильное устройство. В соответствии с некоторыми аспектами заголовок создания маршрута повторно передается на этапе 604, если поля ATI не совпадают.
Если поля ATI совпадают на этапе 612 ("ДА"), способ 600 переходит к этапу 614, где выполняется определение в отношении того, принят ли один или более кодов ошибок в пакете, отправленном посредством вторичных базовых станций. Эти коды ошибок могут включать в себя то, что персонализация, предлагаемая мобильным устройством, не поддерживается базовой станцией, и что маршрут или туннель между базовой станцией и мобильным устройством уже существует. Другой код ошибки может указывать, что базовая станция (или сеть) хочет закрыть сеанс вследствие различных причин. Другие коды ошибок включают в себя индикатор того, что маршрут между базовой станцией и мобильным устройством не существует, хотя мобильное устройство по ошибке считало, что маршрут фактически существовал, и произошел сбой UATI. В соответствии с некоторыми аспектами более одного кода ошибки может передаваться посредством базовой станции в мобильное устройство.
Если коды ошибок не приняты, "НЕТ", то способ 600 переходит к этапу 616, с переходом из состояния "ожидания открытия". Если один или более кодов ошибок приняты ("ДА") на этапе 614, коды ошибок могут быть скорректированы на этапе 610, и сообщение с обновленным заголовком протокола маршрутизации может быть отправлено на этапе 604.
Тип ошибки может быть ошибкой персонализации, которая может приниматься в пакете от базовой станции, пакет включает в себя код ошибки персонализации. Ошибка персонализации может быть скорректирована посредством анализа списка ранжированных персонализаций, принимаемых с пакетом, который включает в себя персонализации, поддерживаемые посредством базовой станции. Эти персонализации могут быть ранжированы посредством базовой станции на основе критериев мобильного устройства и/или базовой станции. Ранжирование может включать в себя порядок предпочтения. Персонализация выбирается из перечня персонализаций, поддерживаемых посредством базовой станции. Пакет заголовка создания маршрута может быть модифицирован так, чтобы включать в себя выбранную персонализацию, и модифицированный пакет заголовка создания маршрута может передаваться в базовую станцию на этапе 604.
Другой тип ошибки, принимаемой в пакете, может быть ошибкой закрытия сеанса. Пакет также может включать в себя CRCErrorDetectPattern. В этом случае мобильное устройство может пытаться повторно устанавливать сетевое соединение с сетью, которая включает в себя базовую станцию. RC-аутентификация с сетью может быть установлена, если CRCErrorDetectPattern указывает, что код ошибки закрытия сеанса не обусловлен ошибкой в линии связи.
Другой код ошибки, включенный в пакет, может указывать, что маршрут уже установлен с базовой станцией. В пакет включается идентификатор установленного маршрута. В этом случае может быть определено, что туннельная взаимосвязь между мобильным устройством и базовой станцией не требуется, поскольку взаимосвязь уже существует. Таким образом, способ 600 может завершиться вместо отправки нового сообщения на этапе 604.
Дополнительный тип ошибки - это отсутствие маршрута, как указано посредством кода ошибки. В этом случае заголовок протокола маршрутизации может отправляться в базовую станцию, чтобы установить маршрут к этой базовой станции. Если принята ошибка UATI, то корректный ATI, уже установленный, может быть послан в заголовке протокола маршрутизации на этапе 604.
Фиг. 7 иллюстрирует способ 700 для установления связи между мобильным устройством и базовой станцией через туннель. Способ начинается на этапе 702, когда заголовок протокола создания маршрута принимается от мобильного устройства. Заголовок протокола создания маршрута может включать в себя один или более параметров, ассоциированных с заданием туннеля. Этот заголовок может приниматься в сообщении и может включать в себя различную информацию, такую как идентификатор терминала доступа (ATI), выбор персонализации, идентификатор маршрута, должны ли существующие маршруты быть удалены и т.д.
В соответствии с некоторыми аспектами заголовок RouteID (короткий адрес) может приниматься от мобильного устройства, однако базовая станция не распознает заголовок RouteID (к примеру, нет преобразования между заголовком RouteID и ANID).
В этой ситуации базовая станция может отправить сообщение RouteMapRequest в мобильное устройство, запрашивающее карту текущего маршрута. В соответствии с некоторыми аспектами мобильное устройство не использует заголовок RouteID для маршрута назначения, если сообщение RouteMap, содержащее преобразование ANID к RouteID для этого маршрута назначения, не отправлялось в эту сеть доступа (к примеру, базовую станцию).
На этапе 704 выполняется определение в отношении того, находится ли мобильное устройство в состоянии ожидания закрытия, как указано посредством поля в заголовке протокола создания маршрута. Если устройство находится в состоянии ожидания закрытия, "ДА", на этапе 706 индикатор RouteReopen отправляется в мобильное устройство, чтобы перейти в открытое состояние. Способ 700 может продолжаться на этапе 702, когда сообщение принимается от мобильного устройства.
Если устройство не находится в состоянии ожидания закрытия ("НЕТ"), на этапе 708 выполняется определение в отношении того, находится ли устройство в состоянии ожидания открытия, как указано в поле заголовка. Если устройство не находится в состоянии ожидания открытия, и заголовок создания маршрута не включает в себя флаг удаления всех маршрутов, на этапе 710 заголовок игнорируется (поскольку устройство не находится ни в состоянии ожидания открытия, ни в состоянии ожидания закрытия). В соответствии с некоторыми аспектами, если маршрут уже установлен с мобильным устройством, то заголовок игнорируется. Если устройство находится в состоянии ожидания открытия, то на этапе 712 выполняется определение в отношении того, должны ли все маршруты быть удалены. Триггеры, которые могут указывать, должен ли быть задан флаг удаления старых маршрутов, могут включать в себя ситуацию, когда мобильное устройство потеряло состояние протокола линии радиосвязи (RLP). Если все маршруты должны быть удалены ("Да"), то на этапе 714 выдается команда удаления старых маршрутов, и способ 700 завершается до тех пор, пока новый маршрут не будет установлен.
Если на этапе 712 определено, что старые маршруты не должны быть удалены ("НЕТ"), то способ 700 переходит к этапу 716, где проверяются состояния ошибки (находится ли устройство в состоянии ожидания открытия).
Состояние ошибки может возникать, если персонализация, предлагаемая посредством мобильного устройства, не поддерживается базовой станцией. Персонализация содержит один или более типов протоколов и одно или более значений атрибутов. Если предлагаемая персонализация не поддерживается, то код ошибки отправляется в ответ на заголовок создания маршрута. Персонализация содержит один или более типов протоколов и одно или более значений атрибутов. Практически одновременно с тем, как отправляется код ошибки, перечень или рекомендуемая персонализация также может быть отправлена в сообщении протокола маршрутизации, отправляемом в ответ на принимаемый заголовок создания маршрута. Этот перечень может быть ранжирован в порядке предпочтения, при этом более предпочтительная персонализация приводится первой. Предпочтение может быть определено на основе производительности, поскольку некоторые персонализации могут обеспечивать более высокие скорости передачи пакетов или данных, и эти персонализации могут быть более предпочтительны. Например, некоторые персонализации подстраиваются для различных приложений. Если мобильное устройство является, например, устройством видеоконференц-связи, оно может иметь другую персонализацию. Базовая станция может ранжировать эти персонализации на основе критериев, которые применяются к типам приложений, которые мобильное устройство выполняет, и характеристик мобильного устройства. Ранжирование может указывать персонализации, которые должны предоставлять мобильному устройству наибольшую скорость передачи данных или наибольшую производительность, которые перечисляются первыми. Если мобильное устройство может поддерживать первую ранжированную персонализацию, она выбирается, иначе мобильное устройство пытается использовать следующую ранжированную персонализацию и т.д. Таким образом, порядок предпочтения является конкретным для базовой станции (к примеру, характеристик базовой станции), а также конкретным для мобильного устройства. В соответствии с некоторыми аспектами базовая станция может предоставлять определенный порядок предпочтения первому мобильному устройству и другой порядок предпочтения другому мобильному устройству.
Другой код ошибки возникает в случае, когда маршрут между базовой станцией и мобильным устройством уже существует. В этой ситуации нет необходимости создавать другой маршрут. Идентификатор уже установленного маршрута может быть включен в сообщение протокола маршрутизации, отправляемое в ответ на заголовок создания маршрута.
Другой код ошибки возникает в случае, когда сеанс должен быть закрыт, к примеру, если мобильное устройство более не имеет учетных данных, необходимых для того, чтобы осуществлять доступ к сети. Инструкции, указывающие, что маршрут должен быть закрыт, могут приниматься от сеансового опорного сетевого контроллера. Практически одновременно с тем, как этот код ошибки отправляется, может отправляться CRCErrorDetectPattern, чтобы уменьшать вероятность закрытия сеанса вследствие ошибки в линии связи.
Другой код ошибки отправляется, если маршрут между базовой станцией и мобильным устройством не существует. Эта ситуация возникает, когда мобильное устройство полагает, что маршрут существует, тем не менее он не установлен. В этом случае код ошибки включается в сообщение протокола маршрутизации, которое указывает, что маршрут не существует. Определение этой ошибки может быть выполнено на основе приема пакета, который не включает в себя заголовок создания маршрута, и маршрут не установлен с мобильным устройством. Мобильное устройство находится не в состоянии ожидания открытия, когда эта ошибка возникает.
Дополнительный код ошибки может возникать, если UATI является ошибочным, поскольку ATI не совпадает. Это происходит, если ATI изменялся в то время, когда маршрут устанавливался. Устройство после приема этого кода ошибки может предоставлять корректный ATI, чтобы устанавливать обмен данными с базовой станцией. Идентификация мобильного устройства может быть безуспешной на основе информации, принятой от сеансового опорного сетевого контроллера.
В некоторых ситуациях базовая станция, к которой создается туннель (к примеру, вторичная базовая станция), может не знать последний идентификатор мобильного устройства, поскольку адрес мобильного устройства изменялся. В случаях, если адрес не изменялся, обслуживающая базовая станция (к примеру, первичная базовая станция) может передать адрес во вторичную базовую станцию. Однако если адрес изменялся в последнее время, обслуживающая базовая станция может не иметь сведений об изменении в адресе, поскольку изменение адреса - это процесс между SRNC (центральным контроллером) и мобильным устройством, о котором обслуживающая базовая станция не знает. Например, если адрес изменялся за последние X секунд (где X - целое число, например, 5), то мобильное устройство включает новый адрес во время создания маршрута, а в противном случае опускает адрес. Это дает возможность вторичной базовой станции иметь последнюю информацию об адресе мобильного устройства в случае, если адрес недавно изменялся, и позволяет уменьшать объем служебной информации при включении адреса в случаях, если адрес не изменялся недавно.
На этапе 718 сообщение протокола маршрутизации создается с учетом всех обнаруженных ошибок, а также других критериев (к примеру, поле ATI). Сообщение протокола маршрутизации отправляется в мобильное устройство на этапе 720, чтобы установить взаимосвязь (к примеру, туннель) между базовой станцией и мобильным устройством.
Чтобы обеспечить полное понимание раскрытых аспектов, далее представляются сведения по передаче и приему заголовков протокола маршрутизации. Понятно, что хотя ниже предоставлены конкретные сведения по одной реализации раскрытых аспектов, в раскрытых аспектах могут быть использованы другие технологии реализации.
Далее представлена процедура передачи с точки зрения мобильного устройства. Базовый протокол маршрутизации принимает пакет протокола управления потоком для передачи или желает послать пакет протокола маршрутизации без полезной нагрузки. В мобильном устройстве протокол маршрутизации посылает пакет без полезной нагрузки, когда предоставляет полезную нагрузку в MAC-уровень и нет доступных пакетов протокола управления потоком. В этой ситуации базовый протокол маршрутизации может выполнять следующую описываемую процедуру. Базовый протокол маршрутизации добавляет заголовок протокола маршрутизации, чтобы создать пакет протокола маршрутизации, посредством определения того, должна ли добавляться одна или более записей HeaderElement.
Запись HeaderElement HeaderType в "000" (к примеру, заголовок RouteCreation) добавляется, если общедоступные данные протокола управления маршрутизацией указывают состояние ожидания открытия, и мобильное устройство не принимало пакетов от сети доступа на этом маршруте.
Если запись HeaderElement HeaderType "000" (к примеру, заголовок RouteCreation) добавляется, мобильное устройство может создавать персонализацию. Если имеется запрос переключения незавершенной персонализации от сети доступа, мобильное устройство задает значение поля PersonalityIndex заголовка равным значению общедоступных данных PendingPersonalityIndex протокола управления сеансом. Если мобильное устройство создало этот маршрут в ответ на сообщение RouteCreate, то мобильное устройство может включить или поле PSI, или поля IPSI и PersonalityIndex в заголовок. В противном случае мобильное устройство включает поля IPSI и PersonalityIndex в заголовок.
Запись HeaderElement HeaderType "001" (к примеру, ATI-заголовок) добавляется, если общедоступные данные протокола подключенного состояния заданы равными BindATI, и мобильное устройство не приняло заголовок протокола маршрутизации от сети доступа, содержащий ATI-заголовок, идентичный отправляемому посредством мобильного устройства.
Если запись HeaderElement HeaderType "001" (к примеру, ATI-заголовок) добавляется, мобильное устройство может выполнить следующую процедуру. Если общедоступные данные CurrentATI протокола управления маршрутизацией заданы равными UATI, мобильное устройство задает поле ATIType равным "10" и задает поле ATI равным общедоступным данным CurrentATI протокола управления маршрутизацией. Если общедоступные данные CurrentATI протокола управления маршрутизацией заданы равными RATI, мобильное устройство задает поле ATIType равным "11" и задает поле ATI равным общедоступным данным CurrentATI протокола управления маршрутизацией. Мобильное устройство задает LastTransmittedATI равным (значению поля ATIType | значению поля ATI).
Если несколько пакетов протокола консолидации пакетов должны переноситься в одном MAC-пакете, базовый протокол маршрутизации опускает записи HeaderElement во всех пакетах протокола консолидации пакетов кроме первого, включенного в MAC-пакет. Протокол маршрутизации использует информацию от протокола консолидации пакетов, чтобы выполнить эту процедуру.
Если нет необходимости добавлять какие-либо записи HeaderElement, базовый протокол маршрутизации задает поле ExtendedHeaderIncluded равным "0". В противном случае базовый протокол маршрутизации задает поле ExtendedHeaderIncluded равным "1" и добавляет требуемое число записей HeaderElement. В соответствии с некоторыми аспектами, если это соответствует пакету протокола маршрутизации без полезной нагрузки, базовый протокол маршрутизации может задавать поле Padding равным "0000000".
Если в настоящий момент нет маршрута, который является обслуживающим маршрутом обратной линии связи (как указано посредством общедоступных данных RLSS MAC-протокола обратного канала управления), протокол маршрутизации выдает команду AirlinkManagement.OpenConnection. В противном случае протокол управления маршрутизацией может выполнить следующее. Если этот маршрут является обслуживающим маршрутом обратной линии связи (как указано посредством общедоступных данных RLSS MAC-протокола обратного канала управления), базовый протокол маршрутизации доставляет пакет протокола маршрутизации в протокол консолидации пакетов своего маршрута, но может доставить пакет протокола маршрутизации в протокол межмаршрутного туннелирования своего маршрута. В противном случае базовый протокол маршрутизации доставляет пакет протокола маршрутизации в протокол межмаршрутного туннелирования обслуживающего маршрута обратной линии связи (как указано посредством общедоступных данных RLSS MAC-протокола обратного канала управления).
Далее представлена примерная процедура передачи с точки зрения базовой станции. Если базовый протокол маршрутизации принимает пакет протокола управления потоком для передачи или желает отправить пакет протокола маршрутизации без полезной нагрузки, базовый протокол маршрутизации может выполнить следующее. Базовый протокол маршрутизации добавляет заголовок протокола маршрутизации, чтобы создать пакет протокола маршрутизации, следующим образом. Базовый протокол маршрутизации определяет, должна ли добавляться одна или более записей HeaderElement, следующим образом. Запись HeaderElement HeaderType "010" (к примеру, заголовок ErrorCode) может быть включена следующим образом.
Сеть доступа не включает более одной записи HeaderElement HeaderType "010" (к примеру, заголовок ErrorCode). Если сеть доступа принимает заголовок RouteCreation от мобильного устройства, и персонализация, предлагаемая посредством мобильного устройства, не поддерживается сетью доступа, сеть доступа задает поле ErrorCode равным "0000". Если сеть доступа принимает заголовок RouteCreation от мобильного устройства с DeleteOldRoutes, заданным равным "0", маршрут уже существует для этого мобильного устройства, и общедоступные данные состояния протокола управления маршрутизацией не заданы равными состоянию WaitingToClose, сеть доступа задает поле ErrorCode равным "0001". Поле ErrorCode задается равным "0010", если сеть доступа запрошена для того, чтобы закрыть сеанс. Если сеть доступа принимает запись HeaderElement HeaderType "001" (к примеру, ATI-заголовок) от мобильного устройства, но без записи HeaderElement HeaderType "000" (к примеру, заголовок RouteCreation), сеть доступа не является SessionAnchor, и если маршрут не существует для этого мобильного устройства, то сеть доступа задает поле ErrorCode равным "0011".
Запись HeaderElement HeaderType "001" (к примеру, ATI-заголовок) включается, если общедоступные данные ProtocolState протокола подключенного состояния заданы равными BindATI. Сеть доступа задает поля ATIType и ATI равными соответствующим значениям, принимаемым от мобильного устройства.
Если нет необходимости добавлять какие-либо записи HeaderElement на основе вышеупомянутых правил, базовый протокол маршрутизации задает поле ExtendedHeaderIncluded равным "0". В противном случае, базовый протокол маршрутизации задает поле ExtendedHeaderlncluded равным "1" и добавляет требуемое число записей HeaderElement. Если это соответствует пакету протокола маршрутизации без полезной нагрузки, базовый протокол маршрутизации задает поле Padding равным "0000000".
Базовый протокол маршрутизации может выполнять следующее. Если этот маршрут является обслуживающим маршрутом прямой линии связи (как указано посредством общедоступных данных FLSS MAC-протокола обратного канала управления), базовый протокол маршрутизации может доставить пакет протокола маршрутизации в протокол консолидации пакетов своего маршрута, но может доставить пакет протокола маршрутизации в протокол межмаршрутного туннелирования своего маршрута. В противном случае базовый протокол маршрутизации доставляет пакет протокола маршрутизации в протокол межмаршрутного туннелирования обслуживающего маршрута прямой линии связи (как указано посредством общедоступных данных FLSS MAC-протокола обратного канала управления).
Далее представлена примерная процедура приема с точки зрения мобильного устройства. Если базовый протокол маршрутизации принимает пакет протокола маршрутизации от протокола консолидации пакетов своего маршрута или от протокола межмаршрутного туннелирования своего маршрута или другого маршрута, базовый протокол маршрутизации может выполнять следующее. Базовый протокол маршрутизации удаляет текущий заголовок протокола маршрутизации, чтобы сформировать пакет протокола управления потоком или поле Padding, следующим образом.
Если запись HeaderElement HeaderType "010" (к примеру, заголовок ErrorCode) присутствует с полем ErrorCode, равным "0000", базовый протокол маршрутизации возвращает индикатор PersonalityFailure. Если запись HeaderElement HeaderType "010" (к примеру, заголовок ErrorCode) присутствует с полем ErrorCode, равным "0001", базовый протокол маршрутизации возвращает индикатор RouteExists. Если запись HeaderElement HeaderType "010" (к примеру, заголовок ErrorCode) присутствует с полем ErrorCode, равным "0010", и поле CRCErrorDetectPattern задано равным "1010101010101010", базовый протокол маршрутизации выдает команду SessionControl.Deactivate. Если запись HeaderElement HeaderType "010" (к примеру, заголовок ErrorCode) присутствует с полем ErrorCode, равным "0011", базовый протокол маршрутизации возвращает индикатор RouteDoesNotExist. Если запись HeaderElement HeaderType "010" (к примеру, заголовок ErrorCode) присутствует с полем ErrorCode, равным "0100", базовый протокол маршрутизации возвращает индикатор UATIFailed.
Базовый протокол маршрутизации возвращает индикатор ATIReceived(ATIType, ATI, RouteStatus). Этот индикатор может использоваться, когда общедоступные данные состояния протокола подключенного состояния равны ATI привязки. Если этот индикатор используется, аргументы могут быть заданы следующим образом. Если запись HeaderElement HeaderType "001" (к примеру, ATI-заголовок) присутствует, аргументы ATIType и ATI могут быть заданы равными соответствующим значениям, принимаемым в заголовке. Если запись HeaderElement HeaderType "001" (к примеру, ATI-заголовок) отсутствует, аргументы ATIType и ATI могут быть заданы равными NULL. Если запись HeaderElement HeaderType "001" (к примеру, ATI-заголовок) отсутствует или если запись HeaderElement HeaderType "010" присутствовала, RouteStatus может быть задан равным 0x1. В противном случае, RouteStatus может быть задан равным 0x0.
Если пакет протокола маршрутизации состоит из поля Padding "0000000", а не полезной нагрузки протокола управления потоком, базовый протокол маршрутизации отбрасывает поле Padding. В противном случае базовый протокол маршрутизации доставляет пакет протокола управления потоком в протокол управления потоком своего маршрута.
Далее представлена примерная процедура приема с точки зрения базовой станции. Если базовый протокол маршрутизации принимает пакет протокола маршрутизации от протокола консолидации пакетов своего маршрута или от протокола межмаршрутного туннелирования своего маршрута или другого маршрута, базовый протокол маршрутизации может выполнять следующее. Базовый протокол маршрутизации удаляет текущий заголовок протокола маршрутизации, чтобы сформировать пакет протокола управления потоком или поле Padding, следующим образом.
Если запись HeaderElement HeaderType "001" (к примеру, ATI-заголовок) присутствует, базовый протокол маршрутизации возвращает индикатор ATIReceived(ATIType, ATI, RouteStatus) с ATI, заданным равным принимаемому значению ATI. Если запись HeaderElement HeaderType "000" (к примеру, заголовок RouteCreation) присутствует, сеть доступа может выполнять следующее. Сеть доступа может игнорировать этот заголовок, если общедоступные данные состояния протокола управления маршрутизацией не равны состоянию ожидания открытия или состоянию ожидания закрытия.
Если заголовок не игнорируется, сеть доступа может выполнять следующее. Если поле DeleteOldRoutes задано равным "1", базовый протокол маршрутизации выдает команду RouteControl.DeleteOldRoutes. Если общедоступные данные состояния протокола управления маршрутизацией заданы равными состоянию ожидания закрытия, протокол маршрутизации возвращает индикатор RouteReopen.
Если пакет протокола маршрутизации состоит из поля Padding "0000000", а не полезной нагрузки протокола управления потоком, базовый протокол маршрутизации отбрасывает поле Padding. В противном случае базовый протокол маршрутизации доставляет пакет протокола управления потоком в протокол управления потоком своего маршрута.
На фиг. 8 проиллюстрирована примерная система 800, которая создает туннельную взаимосвязь между мобильным устройством и базовой станцией. Система 800 может постоянно размещаться, по меньшей мере, частично в мобильном устройстве. Следует принимать во внимание, что система 800 представлена как включающая в себя функциональные блоки, которые могут быть функциональными блоками, представляющими функции, реализованные посредством процессора, программного обеспечения или комбинации вышеозначенного (к примеру, микропрограммного обеспечения).
Система 800 включает в себя логическое группирование 802 электрических компонентов, которые могут действовать по отдельности или совместно. Логическое группирование 802 может включать в себя электрический компонент для выбора, по меньшей мере, одной базовой станции для установления связи через туннель 804. Также в логическое группирование включен электрический компонент для передачи сообщения, которое включает в себя заголовок создания маршрута, по меньшей мере, в одну базовую станцию 806. Заголовок создания маршрута содержит один или более параметров, ассоциированных с заданием туннеля.
Логическое группирование 802 также включает в себя электрический компонент для ожидания подтверждения заголовка создания маршрута 808. Подтверждение включает в себя прием пакета, по меньшей мере, от одной базовой станции. Электрический компонент 806 может повторно передавать сообщение, которое включает в себя заголовок создания маршрута, по меньшей мере, в одну базовую станцию до тех пор, пока подтверждение не будет принято. Дополнительно, логическое группирование 802 включает в себя электрический компонент для перехода из состояния ожидания открытия, когда подтверждение принято 810.
В соответствии с некоторыми аспектами логическое группирование 802 включает в себя электрический компонент для определения того, что два или более пакетов протокола консолидации пакетов должны переноситься в одном MAC-пакете. Каждый пакет протокола консолидации пакетов включает в себя запись элемента заголовка. Также в логическое группирование 802 может быть включен электрический компонент для опускания записи элемента заголовка из всех кроме одного из пакетов консолидации пакетов.
В соответствии с некоторыми аспектами логическое группирование может включать в себя электрический компонент для приема пакета, по меньшей мере, от одной базовой станции. Пакет включает в себя код ошибки персонализации. Также в логическое группирование включен электрический компонент для анализа списка ранжированных персонализаций, принимаемых с пакетом, и электрический компонент для выбора персонализации из списка ранжированных персонализаций. Дополнительно, логическое группирование может включать в себя электрический компонент для модификации пакета заголовка создания маршрута так, чтобы включать в себя выбранную персонализацию, и электрический компонент для передачи модифицированного пакета заголовка создания маршрута, по меньшей мере, в одну базовую станцию.
В соответствии с некоторыми аспектами логическое группирование 802 включает в себя электрический компонент для приема пакета, по меньшей мере, от одной базовой станции. Пакет включает в себя код ошибки уже установленного маршрута и идентификатор установленного маршрута. Также включен электрический компонент для определения того, что туннельная взаимосвязь не требуется.
В соответствии с некоторыми аспектами логическое группирование включает в себя электрический компонент для приема пакета, по меньшей мере, от одной базовой станции. Пакет включает в себя код ошибки закрытия сеанса и CRCErrorDetectPattern. Также в логическое группирование 802 включен электрический компонент для повторной аутентификации в сети, которая включает в себя, по меньшей мере, одну базовую станцию, если CRCErrorDetectPattern указывает, что код ошибки закрытия сеанса не обусловлен ошибкой в линии связи.
Дополнительно система 800 может включать в себя запоминающее устройство 812, которое сохраняет инструкции для выполнения функций, ассоциированных с электрическими компонентами 804, 806, 808 и 810 или другими компонентами. Хотя эти компоненты показаны внешними по отношению к запоминающему устройству 812, следует понимать, что один или более из электрических компонентов 804, 806, 808 и 810 могут существовать в рамках запоминающего устройства 812.
На фиг. 9 проиллюстрирована примерная система 900, которая создает туннельную взаимосвязь между мобильным устройством и базовой станцией. Система 900 может постоянно размещаться, по меньшей мере, частично в базовой станции. Следует принимать во внимание, что система 900 представлена как включающая в себя функциональные блоки, которые могут быть функциональными блоками, которые представляют функции, реализованные посредством процессора, программного обеспечения или комбинации вышеозначенного (к примеру, микропрограммного обеспечения).
Система 900 включает в себя логическое группирование 902 электрических компонентов, которые могут действовать по отдельности или совместно. Логическое группирование 902 может включать в себя электрический компонент для приема сообщения, которое включает в себя заголовок создания маршрута, от мобильного устройства 904. Заголовок создания маршрута содержит один или более параметров, ассоциированных с заданием туннеля. Также в логическое группирование 902 включен электрический компонент для определения того, находится ли мобильное устройство в состоянии ожидания открытия 904. Дополнительно логическое группирование включает в себя электрический компонент для анализа заголовка создания маршрута на предмет, по меньшей мере, одной ошибки, если мобильное устройство находится в состоянии ожидания открытия 908. Также включен электрический компонент для создания сообщения протокола маршрутизации в ответ на принимаемое сообщение 910. Дополнительно логическое группирование 902 может включать в себя электрический компонент для передачи созданного сообщения протокола маршрутизации в мобильное устройство. В соответствии с некоторыми аспектами логическое группирование 902 включает в себя электрический компонент для игнорирования заголовка создания маршрута от мобильного устройства, если устройство не находится в состоянии ожидания открытия.
Согласно некоторым аспектам логическое группирование включает в себя электрический компонент для определения того, поддерживается или нет персонализация, запрашиваемая в принимаемом заголовке создания маршрута, и электрический компонент для осуществления доступа к сеансовому опорному сетевому контроллеру, чтобы определять персонализации, которые поддерживаются. Также в логическое группирование 902 может быть включен электрический компонент для ранжирования поддерживаемых персонализаций в порядке предпочтения и электрический компонент для включения ранжированных поддерживаемых персонализаций в сообщение протокола маршрутизации.
Дополнительно система 900 может включать в себя запоминающее устройство 914, которое сохраняет инструкции для выполнения функций, ассоциированных с электрическими компонентами 904, 906, 908, 910 и 912 или другими компонентами. Хотя компоненты показаны внешними по отношению к запоминающему устройству 914, следует понимать, что один или более из электрических компонентов 904, 906, 908, 910 и 912 могут существовать в рамках запоминающего устройства 914.
Следует понимать, что аспекты, описанные в данном документе, могут быть реализованы посредством аппаратных средств, программного обеспечения, микропрограммного обеспечения, промежуточного программного обеспечения, микрокода или любой комбинации вышеозначенного. Когда системы и/или способы выполнены в программном обеспечении, микропрограммном обеспечении, промежуточном программном обеспечении или микрокоде, программном коде или сегментах кода, они могут быть сохранены на машиночитаемом носителе, таком как компонент накопителя. Сегмент кода может представлять процедуру, функцию, подпрограмму, программу, стандартную процедуру, вложенную процедуру, модуль, комплект программного обеспечения, класс или любое сочетание инструкций, структур данных или программных операторов. Сегмент кода может быть связан с другим сегментом кода или аппаратной схемой посредством передачи и/или приема информации, данных, аргументов, параметров или содержимого памяти. Информация, аргументы, параметры, данные и т.д. могут быть переданы, переадресованы или пересланы посредством любого надлежащего средства, в том числе совместного использования памяти, передачи сообщений, эстафетной передачи данных, передачи по сети и т.д.
Различные иллюстративные логические элементы, блоки, модули и схемы, описанные в связи с раскрытыми в данном документе аспектами, могут быть реализованы или выполнены с помощью процессора общего назначения, процессора цифровых сигналов (DSP), специализированной интегральной схемы (ASIC), программируемой пользователем вентильной матрицы (FPGA) или другого программируемого логического устройства, дискретного логического элемента или транзисторной логики, дискретных компонентов аппаратных средств либо любой комбинации вышеозначенного, предназначенной для того, чтобы выполнять описанные в данном документе функции. Процессором общего назначения может быть микропроцессор, но в альтернативном варианте, процессором может быть любой традиционный процессор, контроллер, микроконтроллер или конечный автомат. Процессор также может быть реализован как комбинация вычислительных устройств, к примеру комбинация DSP и микропроцессора, множество микропроцессоров, один или более микропроцессоров вместе с ядром DSP либо любая другая подобная конфигурация. Дополнительно, по меньшей мере, один процессор может содержать один или более модулей, выполненных с возможностью осуществлять один или более из этапов и/или действий, описанных выше.
При реализации в программном обеспечении описанные в данном документе технологии могут быть реализованы с помощью модулей (к примеру, процедур, функций и т.п.), которые выполняют описанные в данном документе функции. Программные коды могут быть сохранены в запоминающем устройстве и приведены в исполнение посредством процессоров. Запоминающее устройство может быть реализовано в процессоре или внешним образом по отношению к процессору, причем во втором случае оно может быть функционально подсоединено к процессору с помощью различных средств, известных в данной области техники. Дополнительно, по меньшей мере, один процессор может включать в себя один или более модулей, выполненных с возможностью осуществлять функции, описываемые в данном документе.
Более того, различные аспекты или признаки, описанные в данном документе, могут быть реализованы как способ, устройство или изделие с помощью стандартных технологий программирования и/или разработки. Термин "изделие" при использовании в данном документе имеет намерение содержать в себе компьютерную программу, доступную из любого машиночитаемого устройства, носителя или среды. Например, машиночитаемые носители могут включать в себя, но не только, магнитные устройства хранения (к примеру, жесткий диск, гибкий диск, магнитную ленту и т.д.), оптические диски (к примеру, компакт-диск (CD), универсальный цифровой диск (DVD) и т.д.), смарт-карты и устройства флэш-памяти (к примеру, EPROM, карточка, карта, флэш-драйв и т.д.). Дополнительно, различные носители хранения, описанные в данном документе, могут представлять одно или более устройств и/или других машиночитаемых носителей для хранения информации. Термин "машиночитаемый носитель" может включать в себя, без ограничений, беспроводные каналы и различные другие носители, допускающие хранение, размещение и/или перенос команд(ы) и/или данных. Дополнительно, компьютерный программный продукт может включать в себя машиночитаемый носитель, имеющий одну или более инструкций или кодов, выполненных с возможностью инструктировать компьютеру выполнять функции, описываемые в данном документе.
Дополнительно, этапы и/или действия способа или алгоритма, описанные в связи с раскрытыми в данном документе аспектами, могут быть реализованы непосредственно в аппаратных средствах, в программном модуле, приводимом в исполнение посредством процессора, или в их комбинации. Программный модуль может постоянно размещаться в памяти типа RAM, флэш-памяти, памяти типа ROM, памяти типа EPROM, памяти типа EEPROM, в регистрах, на жестком диске, сменном диске, CD-ROM или любой другой форме носителя хранения данных, известной в данной области техники. Типичный носитель хранения данных может быть соединен с процессором, причем процессор может считывать информацию и записывать информацию на носитель хранения данных. В альтернативном варианте носитель хранения данных может быть встроен в процессор. Дополнительно, в некоторых аспектах, процессор и носитель хранения данных могут постоянно размещаться в ASIC. Дополнительно, ASIC может постоянно размещаться в пользовательском терминале. В альтернативном варианте, процессор и носитель хранения данных могут постоянно размещаться как дискретные компоненты в пользовательском терминале. Дополнительно, в некоторых аспектах, этапы и/или действия способа или алгоритма могут постоянно размещаться как один или любая комбинация или набор кодов и/или инструкций на машиночитаемом носителе и/или компьютерночитаемом носителе, который может быть включен в компьютерный программный продукт.
Технологии, описанные в данном документе, могут использоваться для различных систем беспроводной связи, таких как системы CDMA, TDMA, FDMA, OFDMA, SC-FDMA и другие системы. Термины "система" и "сеть" зачастую используются взаимозаменяемо. CDMA-система может реализовывать такую технологию радиосвязи, как универсальный наземный радиодоступ (UTRA) CDMA2000 и т.д. UTRA включает в себя широкополосную CDMA (W-CDMA) и другие варианты CDMA. Дополнительно, cdma2000 охватывает стандарты IS-2000, IS-95 и IS-856. TDMA-система может реализовывать такую технологию радиосвязи, как глобальная система мобильной связи (GSM). OFDMA-система может реализовывать такую технологию радиосвязи, как усовершенствованная UTRA (E-UTRA), сверхширокополосная передача для мобильных устройств (UMB), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDMD и т.д. UTRA и E-UTRA являются частью универсальной системы мобильной связи (UMTS). Стандарт долгосрочного развития (LTE) 3GPP является версией UMTS, которая использует E-UTRA, которая применяет OFDMA в нисходящей линии связи и SC-FDMA в восходящей линии связи. UTRA, E-UTRA, UMTS, LTE и GSM описываются в документах организации, называемой Партнерским проектом третьего поколения (3GPP). Дополнительно, cdma2000 и UMB описываются в документах организации, называемой Партнерским проектом третьего поколения 2 (3GPP2). Дополнительно, эти системы беспроводной связи дополнительно могут включать в себя одноранговые (к примеру, между мобильными станциями) произвольно организующиеся сетевые системы, зачастую использующие непарные нелицензированные спектры, беспроводную LAN по стандарту 802.xx, технологию Bluetooth и любые другие технологии беспроводной связи ближнего и дальнего действия.
Хотя вышеприведенное раскрытие сущности поясняет иллюстративные аспекты и/или аспекты, следует отметить, что различные изменения и модификации могут быть выполнены в них без отступления от объема описанных аспектов и/или аспектов, задаваемых прилагаемой формулой изобретения. Следовательно, описанные аспекты имеют намерение охватывать все подобные преобразования, модификации и разновидности, которые попадают под сущность и объем прилагаемой формулы изобретения. Дополнительно, хотя элементы описанных аспектов и/или аспектов могут быть описаны или сформулированы в единственном числе, множественное число подразумевается, если ограничение на единственное число не указано в явной форме. Дополнительно, весь или часть любого аспекта и/или аспекта может использоваться со всем или частью любого другого аспекта и/или аспекта, если не заявлено иное.
В рамках того, как термин "включает в себя" используется в подробном описании или в формуле изобретения, этот термин должен интерпретироваться включающим образом, аналогично термину "содержит", как термин "содержит" интерпретируется, когда используется в качестве переходного слова в формуле изобретения. Кроме того, термин "или" при использовании в подробном описании или формуле изобретения подразумевается "не исключающим или".