Способы и системы для адаптивного выбора сервера в беспроводной связи
Варианты осуществления, описанные в данном документе, относятся к способам и системам для обеспечения адаптивного выбора сервера в беспроводной связи. Технический результат заключается в улучшении качества услуги и повышении эффективности системы. Для этого терминал доступа может быть сконфигурирован с возможностью определения метрики качества прямой линии связи, связанной с каждым из множества секторов, обслуживаемых множеством точек доступа; назначения баллов каждому сектору в отношении метрики качества прямой линии связи; и изменение значения управления источником данных (УИД), если баллы, накопленные для необслуживающего сектора на границе изменения УИД, превышают предварительно определенный порог, причем необслуживающий сектор и обслуживающий сектор для терминала доступа принадлежат разным сотам. Терминал доступа дополнительно может быть сконфигурирован с возможностью изменения покрытия управления скоростью передачи данных (УСПД) в соответствии с изменением УИД. Использование УИД может обеспечивать раннюю индикацию передачи обслуживания, таким образом, позволяя существенно снизить перерыв в обслуживании, связанный с переключением сервера. 4 н. и 25 з.п. ф-лы, 20 ил., 1 табл.
Область техники, к которой относится изобретение
Настоящее описание относится, в основном, к системам связи. Более конкретно, варианты осуществления, описанные в данном документе, относятся к адаптивному выбору сервера в беспроводной связи.
Уровень техники
Системы беспроводной связи широко используются для предоставления различных видов связи (например, речь, данные и т.д.) многочисленным пользователям. Такие системы могут основываться на многостанционном доступе с кодовым разделением каналов (CDMA, МДКР), многостанционном доступе с временным разделением каналов (TDMA, МДВР), многостанционном доступе с частотным разделением каналов (FDMA, МДЧР) или других методах многостанционного доступа. Система беспроводной связи может быть разработана для реализации одного или нескольких стандартов, таких как IS-95, cdma2000, IS-856, широкополосный МДКР (W-CDMA, ШМДКР), многостанционный доступ с временным разделением каналов синхронно с кодовым разделением каналов (TD-SCDMA, МДВРСКР) и других стандартов.
Так как системы беспроводной связи пытаются предоставить разнообразные услуги всегда с более высокими скоростями передачи данных все возрастающему количеству пользователей, то проблема заключается в улучшении качества услуги и повышении эффективности системы.
Краткое описание чертежей
Фиг.1 иллюстрирует вариант осуществления системы беспроводной связи;
фиг.2А-2С иллюстрируют варианты осуществления временных шкал режима мягкой передачи обслуживания в системах типа «1xEV-DO (эволюция - только данные) Release 0 (версия 0)» и «1xEV-DO Revision А (версия А)»;
фиг.3 иллюстрирует вариант осуществления рабочих временных шкал каналов управления источником данных (DSC, УИД) и управления скоростью передачи данных (DRC, УСПД);
фиг.4 иллюстрирует вариант осуществления изменения покрытия УСПД;
фиг.5 иллюстрирует вариант осуществления последовательности событий, происходящих в первом сценарии режима мягкой передачи обслуживания;
фиг.6 иллюстрирует вариант осуществления последовательности событий, происходящих во втором сценарии режима мягкой передачи обслуживания;
фиг.7 иллюстрирует вариант осуществления последовательности событий, происходящих в третьем сценарии режима мягкой передачи обслуживания;
фиг.8 иллюстрирует вариант осуществления последовательности событий, происходящих в четвертом сценарии режима мягкой передачи обслуживания;
фиг.9 иллюстрирует блок-схему последовательности операций процесса, который может использоваться для реализации некоторых описанных вариантов осуществления;
фиг.10 иллюстрирует блок-схему последовательности операций процесса, который может использоваться для реализации некоторых описанных вариантов осуществления;
фиг.11 иллюстрирует блок-схему последовательности операций процесса, который может использоваться для реализации некоторых описанных вариантов осуществления;
фиг.12 иллюстрирует блок-схему последовательности операций процесса, который может использоваться для реализации некоторых описанных вариантов осуществления;
фиг.13 иллюстрирует блок-схему устройства, в котором могут быть реализованы некоторые описанные варианты осуществления;
фиг.14 иллюстрирует блок-схему устройства, в котором могут быть реализованы некоторые описанные варианты осуществления;
фиг.15 иллюстрирует блок-схему устройства, в котором могут быть реализованы некоторые описанные варианты осуществления;
фиг.16 иллюстрирует вариант осуществления гистерезиса, связанного с установкой бита DRCLock (захват УСПД);
фиг.17 иллюстрирует блок-схему последовательности операций процесса в связи с отображением стирания УСПД;
фиг.18А-I иллюстрируют блок-схемы последовательности операций нескольких процессов, которые могут использоваться для реализации признаков, изображенных на фиг.17;
фиг.19 иллюстрирует блок-схему последовательности операций процесса, который может использоваться для реализации признаков, изображенных на фиг.17 и фиг.18А-I; и
фиг.20 иллюстрирует блок-схему устройства, в котором могут быть реализованы некоторые описанные варианты осуществления.
Подробное описание
Варианты осуществления, описанные в данном документе, относятся к способам и системам для обеспечения адаптивного выбора сервера в беспроводной связи.
Точка доступа (AP, ТЧД), описанная в данном документе, может включать в себя и/или реализовать функции системы приемопередатчика базовой станции (BTS, СППБС), приемопередатчика сети доступа (ANT, ППСД), приемопередатчика модемного пула (MPT, ППМП) или узла В (например, в системе типа ШМДКР) и т.д. Сота может ссылаться на зону покрытия, обслуживаемую ТЧД. Сота может дополнительно включать в себя один или несколько секторов. Далее, контроллер сети доступа (ANC, КСД) может ссылаться на часть системы связи, сконфигурированную для сопряжения с базовой сетью (например, сетью передачи пакетных данных) и маршрутизировать пакеты данных между терминалами доступа (AT, ТД) и базовой сетью, выполнять различные функции радиодоступа и технического обслуживания линии связи (такие как режим мягкой передачи обслуживания), управлять радиопередатчиками и приемниками и т.д. КСД может включать в себя и/или реализовать функции контроллера базовой станции (BSC, КБС), такие как содержащиеся в беспроводной сети 2-го, 3-го или 4-го поколения. КСД и одна или несколько ТЧД могут составлять часть сети доступа (AN, СД).
ТД, описанный в данном документе, может ссылаться на различные типы устройств, включая (но не ограничиваясь ими) беспроводный телефон, сотовый телефон, портативный компьютер, мультимедийное беспроводное устройство, карту беспроводной связи персонального компьютера (PC, ПК), персональный цифровой помощник (PDA, ПЦП), внешний или внутренний модем и т.д. ТД может быть любым устройством передачи данных, который обменивается данными по беспроводному каналу и/или по проводному каналу (например, при помощи волоконно-оптического или коаксиального кабеля). ТД может иметь различные названия, такие как блок доступа, узел доступа, абонентский блок, мобильная станция, мобильное устройство, мобильный блок, мобильный телефон, мобильник, удаленная станция, удаленный терминал, удаленный блок, пользовательское устройство, пользовательское оборудование, портативное устройство и т.д. Различные ТД могут быть объединены в систему. ТД могут быть мобильными или стационарными и могут быть рассредоточены по системе связи. ТД могут обмениваться данными с одним или несколькими ТЧД на прямой линии связи (FL, ПЛ) и/или обратной линии связи (RL, ОЛ) в данный момент.
Фиг.1 иллюстрирует систему 100 беспроводной связи, сконфигурированную на поддержку нескольких пользователей, в которой могут быть реализованы различные описанные варианты осуществления и аспекты, как дополнительно описано ниже. В качестве примера, система 100 обеспечивает связь для нескольких сот 102, включая соты 102а-102g, причем каждая сота обслуживается соответствующей ТЧД 104 (такой как 104а-104g). Каждая сота может дополнительно разделяться на один или несколько секторов. Различные ТД 106, включая ТД 106а-106k, рассредоточены по системе. Каждый ТД 106 может обмениваться данными с одной или несколькими ТЧД 104 на прямой линии связи и/или обратной линии связи в данный момент в зависимости от того, является ли ТД активным, и находится ли он, например, в режиме мягкой передачи обслуживания.
На фиг.1 сплошная линия со стрелкой может указывать передачу информации (например, данных) от ТЧД на ТД. Каждая пунктирная линия со стрелкой может указывать, что ТД принимает пилот-сигнал и другие сигнальные/опорные сигналы от соответствующих ТЧД (например, те, которые присутствуют в активном наборе ТД), как дополнительно описано ниже. Для ясности и простоты, обмен данными обратной линии связи не показан явно на фиг.1.
В системе высокоскоростной передачи пакетных данных (HRPD, ВСППД) (например, как указано в спецификации «cdma2000 High Rate Packet Data Air Interface Specification», 3GPP2 (проект 2 партнерства по системам третьего поколения) C.S0024-0 версия 4.0, 25 октября 2002 г., упоминаемая в данном документе как система типа «1xEV-DO Release 0»; «cdma2000 High Rate Packet Data Air Interface Specification», 3GPP2 C.S0024-A, версия 2, июль 2005 г., упоминаемая как система типа «1xEV-DO Revision А» и т.д.), например, передача по прямой линии связи разделяется на последовательность кадров; каждый кадр дополнительно делится на временные интервалы (например, 16 временных интервалов, каждый с длительностью 1,667 мс); и каждый временной интервал включает в себя множество каналов, мультиплексированных с разделением по времени.
Фиг.2А-2С иллюстрируют варианты осуществления временных шкал режима мягкой передачи обслуживания в системах типа «1xEV-DO Release 0» и «1xEV-DO Revision А», относящиеся к ситуациям, когда ТД переключает свой обслуживающий сектор прямой линии связи с исходного сектора (например, сектора А) на целевой сектор (например, сектор В). Условие запуска для переключения ТД своего обслуживающего сектора прямой линии связи может быть вследствие состояния канала прямой линии связи, например, отфильтрованное отношение сигнала к помехам и шуму (SINR, ОСПШ) (например, основанное на измерении пилот-сигнала и/или других сигналов прямой линии связи) от целевого сектора сообразно выше, чем отношение от исходного сектора в соответствии с предварительно определенной схемой, такой как изображенная на фиг.2А и дополнительно описанная ниже.
В системе типа «1xEV-DO Release 0», такой как изображенная на фиг.2В, ТД может использовать канал управления скоростью передачи данных (УСПД) для указания СД выбранного обслуживающего сектора и требуемой скорости передачи данных, связанных с передачей по прямой линии связи. Канал УСПД также предусматривает механизм обратной связи, связывающий информацию о качестве канала с СД. Часть данных и часть сектора в УСПД может упоминаться в данном документе как «скорость передачи УСПД» и «покрытие УСПД», соответственно. Скорость передачи УСПД и покрытие УСПД составляют «значение УСПД».
Покрытие УСПД может изменяться на любой границе изменения УСПД, например, во временном интервале Т, так что
|
(уравнение 1) |
где FrameOffset (смещение кадра) может измеряться в единицах временных интервалов, mod обозначает операцию по модулю, и DRCLength может представлять собой предварительно определенное количество временных интервалов в длительности (например, 8 временных интервалов). Покрытие УСПД и скорость передачи УСПД могут вводиться в действие через половину временного интервала после окончания передачи и оставаться в действии в течение нескольких временных интервалов, равных DRCLength.
Как для режима мягкой передачи обслуживания, так и для режима более мягкой передачи обслуживания может требоваться минимум две длительности УСПД нулевого покрытия между различными покрытиями УСПД (например, связанные с переключением с сектора А на сектор В), как иллюстрируют следующие примеры.
1) Если текущее покрытие УСПД ТД представляет собой покрытие сектора, тогда следующим покрытием УСПД ТД не может быть другое покрытие сектора. Им может быть только это же покрытие сектора или нулевое покрытие.
2) Если самое последнее покрытие сектора ТД соответствует сектору А, тогда ТД не может использовать покрытие сектора, соответствующее сектору В, до тех пор, пока ТД не определит, что пакеты, принимаемые от сектора В, не будут перекрываться во времени с пакетами, принимаемыми от сектора А.
Рассмотрим ситуацию, когда ТД принимает решение переключить свое УСПД с сектора А на В в конце временного интервала n, которое снижается на границе изменения УСПД. Покрытием УСПД в действии на уровне управления доступом к среде (MAC, УДС) от временного интервала (n+1) до временного интервала (n+DRCLength) может быть все еще сектор А, и ТД может планироваться для передачи при помощи СД во время этого времени. В результате, ТД не сможет мгновенно изменить покрытие УСПД на сектор В. Таким образом, необходима передача нулевого покрытия от временного интервала (n+1) до временного интервала (n+DRCLength). СД может планировать пакет на ТД во временном интервале (n+DRCLength). Если пакет с конкретной скоростью передачи данных (например, индекс 1 скорости передачи с 1024 битами по 16 временным интервалам), он может иметь преамбулу в 1024 чипа по длительности, которая представляет собой временной сдвиг между изменением УСПД и соответствующей передачей пакета данных. ТД не может быть уверен, что нет пакета для него, когда он определяет покрытие УСПД для временного интервала (n+DRCLength+1). Поэтому, необходимо передавать нулевое покрытие от временного интервала (n+DRCLength+1) до (n+2×DRCLength). По существу, может требоваться по меньшей мере два нулевых покрытия между изменениями покрытия УСПД.
Если сектор А и сектор В не находятся в одной и той же соте (например, при режиме мягкой передачи обслуживания), КСД может потребовать направлять данные в сектор В до того, как он начнет обслуживать ТД. При обнаружении изменения покрытия УСПД сектор А может передавать сообщение (например, «ForwardStopped» (прямая остановлена)), и сектор В также может передавать сообщение (например, «ForwardDesired» (прямая требуется)) на КСД для указания режима мягкой передачи обслуживания, как показано на фиг.2В. Таким образом, ТД может не обслуживаться в течение по меньшей мере одного времени двойного пробега ТЧД-КСД плюс две DRCLength во время режима мягкой передачи обслуживания. Для режима более мягкой передачи обслуживания время необслуживания может составлять по меньшей мере две DRCLength. Время необслуживания может называться «перерывом в обслуживании» (или «темным временем») в данном документе, как показано на фиг.2В. Перерыв в обслуживании может представлять собой потерю чувствительных к задержке приложений, таких как данные «передачи речи по протоколу Интернета (VoIP, ПРПИ)».
Чтобы уменьшить перерыв в обслуживании во время передачи обслуживания, может быть введен канал управления источником данных (УИД) (такой как в системе типа «1xEV-DO Revision А»), представляющий обслуживающую соту или источник данных на прямой линии связи. ТД может использовать канал УИД для указания СД выбранной обслуживающей соты на прямой линии связи и использовать канал УСПД для указания СД выбранного обслуживающего сектора на прямой линии связи. Примеры использования канала УИД, способствующие выбору сервера в отношении ТД и СД, приведены ниже.
Фиг.2В и 2С изображают сравнение временных шкал режима мягкой передачи обслуживания в системах типа «1xEV-DO Release 0» и «1xEV-DO Revision А». Для иллюстрации и ясности, явно показаны только случаи с минимальными нулевыми покрытиями УСПД. Отметьте, что как для режима мягкой передачи обслуживания, так и для режима более мягкой передачи обслуживания, если имеются какие-либо передающиеся в данный момент пакеты перед переуказанием УСПД, ТД может посылать нулевые покрытия УСПД до тех пор, пока не будут завершены все пакеты. (Это так как в системе типа «1xEV-DO Release 0», так и в «1xEV-DO Revision А».)
УИД может конфигурироваться так, чтобы иметь предварительно определенные границы, на которых УИД может меняться. Например, УИД может меняться во временном интервале Т, так что
|
(уравнение 2) |
где DRCLength может составлять предварительно определенное количество временных интервалов в длительности (например, 16 временных интервалов). Как описано выше, УСПД может изменяться во временном интервале Т, так что
|
уравнение 3 |
УИД может вызывать действие через один временной интервал после окончания передачи и оставаться в действии в течение временных интервалов DSCLength; тогда как УСПД может вызывать действие через половину временного интервала после окончания передачи и оставаться в действии в течение нескольких временных интервалов, равных DRCLength.
УСПД может согласовываться с УИД. Например, если покрытие УСПД представляет собой покрытие сектора, источник данных, указанный УИД, включается в активный набор ТД, и бит DRCLock, связанный с источником данных, устанавливается в «1», тогда сектор, указанный покрытием УСПД, может принадлежать источнику данных, указанному УИД, который находится в действии во время следующих временных интервалов DRCLength, следующих за передачей УСПД.
УИД может использоваться в качестве раннего указания на передачу обслуживания, тем самым позволяя минимизировать, или, по существу, устранять, перерыв в обслуживании, связанный с пересылкой очереди (или «пересылкой очереди») между ТЧД и КСД. В одном варианте осуществления множество ТЧД в активном наборе ТД могут предпринимать попытку обнаружения УИД перед границей длительности УИД (например, на основе временных интервалов). Когда какой-либо сектор сообщает о возможных изменениях УИД, КСД может начать многоадресную рассылку данных, связанных с приложениями с приоритетным потоком (EF, ПРП) (например, чувствительные к задержке данные, такие как пакеты ПРПИ), на некоторые или все секторы в активном наборе ТД. Примеры механизма многоадресной рассылки дополнительно описываются ниже. Многоадресная рассылка позволяет сектору В быть готовым для обслуживания, когда покрытие УСПД начинает указывать на него.
Минимум две длительности УСПД нулевого покрытия также могут потребоваться в системе типа «1xEV-DO Revision А» как для режима мягкой передачи обслуживания, так и для режима более мягкой передачи обслуживания. По существу, перерыв в обслуживании для данных ПРП в режиме мягкой передачи обслуживания может быть снижен до двух DRCLength нулевого покрытия. Для режима более мягкой передачи обслуживания он может оставаться на двух DRCLength нулевого покрытия. Различие между режимом мягкой передачи обслуживания и режимом более мягкой передачи обслуживания в таких системах может заключаться в том, что последний происходит на любой границе изменения УСПД.
В качестве примера, фиг.3 иллюстрирует вариант осуществления временной шкалы канала УИД для DRCLength двух временных интервалов и DRCLength восьми временных интервалов.
Фиг.4 иллюстрирует вариант осуществления изменения покрытия УСПД. УСПД А и УСПД В обозначают покрытия УСПД, связанные с сотой А и сотой В, соответственно. DRC NULL указывает УСПД с нулевым покрытием. PKT (пакет) A и PKT B указывают потенциальное начало нового пакета от соты А или соты В. PKT NULL указывает отсутствие нового пакет из-за УСПД с нулевым покрытием.
В некоторых вариантах осуществления, чтобы избежать длительного сильного дисбаланса, УИД может не указывать на соту со слабой обратной линией связи. Например, если ТД принимает бит DRCLock, который установлен в «0», от сектора в его активном наборе, ТД может не указывать его УИД источнику данных, связанному с этим сектором (например, чтобы исключить инициирование ТД режима мягкой передачи обслуживания).
Во время режима мягкой передачи обслуживания переуказание УИД/УСПД может задерживаться, например, до двух DRCLength в наихудшем случае. В результате, может быть желательна короткая DSCLength, чтобы уменьшить задержку и возможное ухудшение обслуживания из-за плохого состояния канала. С другой стороны, может быть необходима более высокая мощность передачи, чтобы сохранить надежность канала УИД в таких случаях. Таким образом, необходимо оценивать дополнительные служебные сигналы в обмен на преимущество более короткой задержки.
Переуказание УИД/УСПД может инициироваться ТД, например, основываясь на отфильтрованных измерениях ОСПШ прямой линии связи от различных секторов. Может использоваться фильтр с бесконечной импульсной характеристикой (IIR, БИХ-фильтр) первого порядка (например, с постоянной времени 64 временных интервалов). Пусть сектор А будет текущим обслуживающим сектором и сектор В - в качестве другого сектора в активном наборе ТД. Параметр, названный «балл» в данном документе и обозначенный CB, может сохраняться для сектора В и обновляться следующим образом:
|
Уравнение 4 |
где
|
Уравнение 5 |
В вышеприведенном, SINRA(n) и SINRB(n) обозначают отфильтрованные измерения ОСПШ пилот-сигнала для сектора А и сектора В, соответственно, и n обозначает временной индекс. X и Y могут представлять собой предварительно определенные пороги (например, измеренные в дБ). Может быть два параметра передачи обслуживания, названные «SofterHandoffDelay” (задержка режима более мягкой передачи обслуживания) и «SoftHandoffDelay” (задержка режима мягкой передачи обслуживания) в данном документе, связанные с минимальными длительностями прерывания/задержки, когда ТД переключает свое УСПД с исходного сектора на целевой сектор, принадлежащий этой же и другой соте, соответственно. В некоторых вариантах осуществления значения таких параметров передачи обслуживания могут быть выражены в единицах временных интервалов (например, 8 временных интервалов). Например, может использоваться SofterHandoffDelay = 8 временных интервалов и SoftHandoffDelay = 64 временных интервалов (например, в системе типа или «1xEV-DO Release 0», или «1xEV-DO Revision А»). Эти параметры, например, могут использоваться при определении порога накопленных баллов.
В системе типа «1xEV-DO Release 0» как для режима мягкой передачи обслуживания, так и для режима более мягкой передачи обслуживания, количество баллов, необходимых для переуказания, может равняться SoftHandoffDelay. Так как передача обслуживания вызывает перерыв в обслуживании, большой порог на баллы может ограничивать частоту, с которой ТД инициирует передачу обслуживания.
В системе типа «1xEV-DO Revision А» из-за уменьшения перерыва в обслуживании могут использоваться меньшие пороги. Например:
- Если ТД находится в только режиме более мягкой передачи обслуживания (например, все члены его активного набора принадлежат одной и той же соте), порог на баллы может определяться следующим выражением max(1, SofterHandoffDelay-DRCLength);
- В противном случае, порог может определяться выражением max(1, SoftHandoffDelay-DSCLength).
Отметьте, что порог может определяться составом активного набора ТД (в противоположность тому, на какой сектор ТД собирается выполнить переуказание). Баллы могут вычисляться на границе изменения УСПД для более мягкого переуказания и на границе УИД для мягкого переуказания. Чтобы избежать частого переуказания УИД/УСПД, может быть установлен таймер, когда происходит мягкое/более мягкое переуказание, так что ТД может не инициировать другое переуказание, пока не истечет период, установленный в таймере. В некоторых вариантах осуществления период истечения таймера может быть равен SofterHandoffDelay и SoftHandoffDelay, соответственно. (По существу, SofterHandoffDelay и SoftHandoffDelay могут означать стоимость режима более мягкой и режима мягкой передачи обслуживания.)
В системе типа «1xEV-DO Release 0» может быть два сообщения от ТЧД на КСД, относящихся к переуказанию сектора: например, сообщение, названное «ForwardStopped» в данном документе, от сектора А и другое сообщение, названное «ForwardDesired» в данном документе, от сектора В. Эти сообщения обрабатываются КСД для выполнения пересылки очереди от сектора А сектору В, и перерыв в обслуживании связывается с этой пересылкой очереди (такой как изображенная на фиг.2В). В системе типа «1xEV-DO Revision А» может быть сделана возможной услуга непрерывной передачи данных (например, данные/потоки ПРП) посредством использования канала УИД. Она может выполняться посредством декодирования канала УИД перед границей изменения УИД и выполнением многоадресной рассылки КСД данных на некоторые или все секторы в активной наборе ТД между ранним обнаружением и окончательным обнаружением на границе УИД. В некоторых ситуациях многоадресная рассылка может применяться только в приложениях ПРП (например, чувствительные к задержке данные, такие данные ПРПИ), чтобы ограничить воздействие на трафик обратной доставки.
В одном варианте осуществления каждый сектор в активном наборе ТД может предпринимать попытку декодирования канала УИД. Окончательное решение принимается на границе УИД, обозначенной как Td в данном документе. В момент Td значение УИД с максимально накопленной энергией может объявляться как УИД в действии для следующей DRCLength, если накопленная энергия больше порога; в противном случае, может объявляться стирание УИД.
Чтобы способствовать пересылке очереди и ограничить пакет с многочисленными временными интервалами вокруг Td, может быть желательным раннее принятие решения. Например, каждая ТЧД может обеспечивать решение по декодированию УИД в момент Tpd, который предшествует Td на предварительно определенное (например, конфигурируемое в масштабе системы) количество временных интервалов (например, 12 временных интервалов). Этот же порог энергии может использоваться в окончательном решении при Td. Могут быть ситуации, когда эти ранние обнаружения не являются такими же надежными, как и окончательное решение; они могут компенсироваться, однако, многоадресной сущностью передачи данных между Tpd и Td.
Следующие термины могут использоваться в ситуациях, включающих в себя многоадресную рассылку между КСД и ТЧД (например, те, которые находятся в активном наборе ТД):
- Обслуживающая ТЧД: ТЧД, которая объявила сообщение (например, ForwardDesiredInd) для КСД и рассматривается как обслуживающая ТЧД до тех пор, пока она не объявит другое сообщение (например, ForwardStoppedInd) для КСД. (Обслуживающий сектор может ссылаться на сектор, обслуживаемый обслуживающей ТЧД.)
- Активная обслуживающая ТЧД: ТЧД, которая объявила сообщение ForwardDesiredInd для КСД и рассматривается КСД обслуживающей данные на ТД.
- Необслуживающая ТЧД: ТЧД, которая объявила сообщение ForwardStoppedInd для КСД и рассматривается как необслуживающая ТЧД до тех пор, пока она не объявит сообщение ForwardDesiredInd для КСД. (Необслуживающий сектор может ссылаться на сектор, обслуживаемый необслуживающей ТЧД.)
В дополнение к сообщениям ForwardStoppedInd и ForwardDesiredInd новое сообщение, называемое «DSCChangedInd» в данном документе, может использоваться ТЧД для указания КСД изменения в декодированном значении, связанном с каналом УИД. Это указание может выдаваться любой обслуживающей ТЧД в активном наборе ТД и указывает одно из следующего:
- Значение УИД, указывающее идентификацию ТЧД, на которую ТД предполагает выполнить передачу обслуживания. В данном случае, также может предусматриваться время изменения УИД, указывающее момент времени, при котором может оказать действие указанное значение УИД.
- Стирание, указывающее, что ТЧД не смогла успешно декодировать канал УИД.
Сообщения передачи обслуживания могут генерироваться при следующих условиях и также изображены в таблице 1 ниже:
- ForwardDesiredInd: ТЧД успешно декодировала канал УИД, принятый от ТД, и декодированное значение УИД является таким же, что и ее собственное значение (или самозначение) УИД. Оно может генерироваться в момент Tpd и Td.
- DSCChangedInd(Erased): ТЧД не может декодировать канал УИД, принимаемый от ТД. Оно может генерироваться в момент Tpd и Td.
- DSCChangedInd(Changed): ТЧД успешно декодировала канал УИД, принятый от ТД, и декодированное значение УИД отличается от ее собственного значения УИД. Оно может генерироваться в момент Tpd.
- ForwardStoppedInd: Оно генерируется тогда, когда ТЧД успешно определила, что значение УИД не является тем же, что и ее собственное значение УИД для конфигурируемого количества временных интервалов. Оно может генерироваться в момент Td.
Таблица 1 ниже иллюстрирует комбинации сообщений и моментов времени во время передачи обслуживания.
| Таблица 1 | ||
| Комбинации сообщений и моментов времени передачи обслуживания | ||
| Сообщение | Tpd | Td |
| DSCChangedInd(Erased) | Обслуживающая ТЧД | Обслуживающая ТЧД |
| DSCChangedInd(Changed) | Обслуживающая ТЧД | |
| ForwardStoppedInd | Обслуживающая ТЧД | |
| ForwardDesiredInd | Обслуживающая/ необслуживающая ТЧД | Обслуживающая/ необслуживающая ТЧД |
В некоторых ситуациях различные сообщения передачи обслуживания могут приниматься в любом порядке на КСД за исключением следующего: DSCChangedInd не может сразу же следовать за ForwardStoppedInd.
КСД может войти в состояние многоадресной рассылки при приеме одного из следующих событий:
- DSCChangedInd от активной обслуживающей ТЧД. Прием DSCChangedInd указывает, что состояние канала УИД изменилось. Оно может означать, что или декодирование канала УИД является успешным, и УИД указывает на другую ТЧД, или что декодирование канала УИД является неуспешным.
- ForwardStoppedInd от обслуживающей ТЧД, которая ведет к необслуживающей ТЧД в активном наборе ТД.
КСД может выйти из состояния многоадресной рассылки, если имеется только одна обслуживающая ТЧД в активном наборе ТД, и она не сообщила никакого изменения УИД.
В случае, если исходный обслуживающий сектор выпадает из активного набора ТД, он может послать сообщение ForwardStoppedInd на КСД, и механизм многоадресной рассылки может нормально управлять этой ситуацией. В некоторых вариантах осуществления данные между КСД и ТЧД могут передаваться с использованием протокола пользовательских дейтаграмм (UDP, ППД), тогда как сигнальные сообщения могут передаваться с использованием протокола управления передачей (TCP, ПУП) для надежности.
Фиг.5 иллюстрирует вариант осуществления последовательности событий, происходящих в первом сценарии режима мягкой передачи обслуживания, когда как активная обслуживающая ТЧД (или «ТЧД1» для простоты), так и необслуживающая ТЧД (или «ТЧД2» для простоты) могут правильно обнаруживать изменение УИД. На различных этапах, изображенных на фиг.5:
1. ТЧД1 декодирует канал УИД и определяет, что ТД больше не указывает свое УИД на ТЧД1. ТЧД1 затем посылает сообщение DSCChangedInd на КСД, которое может включать в себя новое значение УИД, текущий уровень очереди, предсказываемое время переключения и т.д.
2. КСД входит в состояние многоадресной рассылки, например, начиная выполнять многоадресную рассылку прямого трафика (например, данные ПРП) по всем ТЧД в активном наборе ТД.
3. ТЧД2 успешно декодирует канал УИД в момент Tpd1 времени и посылает сообщение ForwardDesiredInd на КСД.
4. В момент Td1 времени ТЧД1 делает вывод, что ТД переключается на ТЧД2 и посылает сообщение ForwardStoppedInd на КСД.
5. КСД устанавливает активной обслуживающей ТЧД для ТД ТЧД2, останавливает многоадресную рассылку и начинает посылать прямой трафик только на ТЧД2.
Фиг.6 иллюстрирует вариант осуществления последовательности событий, происходящих во втором сценарии режима мягкой передачи обслуживания, когда активная обслуживающая ТЧД (или «ТЧД1») может правильно обнаруживать изменение УИД, и необслуживающая ТЧД (или «ТЧД2») обнаруживает стирание УИД. На различных этапах, изображенных на фиг.6:
1. ТЧД1 декодирует канал УИД и определяет, что ТД больше не указывает своим УИД на ТЧД1. ТЧД1 затем посылает сообщение DSCChangedInd на КСД, которое может включать в себя новое значение УИД, текущий уровень очереди, предсказываемое время переключения и т.д.
2. КСД входит в состояние многоадресной рассылки, например, начиная выполнять многоадресную рассылку прямого трафика по всем ТЧД в активном наборе ТД.
3. ТЧД2 успешно декодирует канал УИД (который указывает на самого себя) и посылает сообщение ForwardDesiredInd на КСД.
4. ТЧД2 декодирует стирание УИД и посылает сообщение DSCChangedInd на КСД.
5. В момент Td1 времени ТЧД1 делает вывод, что ТД переключается на ТЧД2 и посылает сообщение ForwardStoppedInd на КСД. КСД устанавливает активной обслуживающей ТЧД для ТД ТЧД2.
6. ТЧД2 успешно декодирует многочисленные символы УИД (которые являются такими же, что и ее собственное значение). Так как ТЧД2 только что послало сообщение DSCChangedInd на КСД, оно посылает другое сообщение ForwardDesiredInd для подтверждения КСД, что ТД действительно переключается на ТЧД2.
7. КСД останавливает многоадресную рассылку и начинает посылать прямой трафик только на ТЧД2.
Фиг.7 иллюстрирует вариант осуществления последовательности событий, происходящих в третьем сценарии режима мягкой передачи обслуживания, когда активная обслуживающая ТЧД (или «ТЧД1») обнаруживает изменение УИД после стирания УИД, и необслуживающая ТЧД (или «ТЧД2») может правильно обнаруживать изменение УИД. На различных этапах, изображенных на фиг.7:
1. ТЧД2 успешно декодирует канал УИД (который является таким же, что и ее собственное значение) и посылает сообщение ForwardDesiredInd на КСД.
2. КСД входит в состояние многоадресной рассылки, например, начинает выполнять многоадресную рассылку прямого трафика на все ТЧД в активном наборе ТД.
3. В момент Td1 времени ТЧД1 декодирует стирание УИД и посылает сообщение DSCChangedInd на КСД.
4. ТЧД1 декодирует канал УИД (который указывает на другую ТЧД) и посылает сообщение DSCChangedInd на КСД.
5. В момент Td2 времени ТЧД1 делает вывод, что ТД переключается на ТЧД2 и посылает сообщение ForwardStoppedInd на КСД. КСД устанавливает активной обслуживающей ТЧД для ТД ТЧД2.
6. КСД останавливает многоадресную рассылку и начинает посылать прямой трафик только на ТЧД2.
Фиг.8 иллюстрирует вариант осуществления последовательности событий, происходящих в четвертом сценарии режима мягкой передачи обслуживания, когда активная обслуживающая ТЧД (или «ТЧД1») восстанавливается от стирания УИД, и необслуживающая ТЧД (или «ТЧД2») восстанавливается от стирания УИД. На различных этапах, изображенных на фиг.8:
1. ТЧД1 декодирует стирание УИД и посылает сообщение DSCChangedInd на КСД.
2. КСД входит в состояние многоадресной рассылки, например, начиная многоадресную рассылку прямого трафика на все ТЧД в активном наборе ТД.
3. ТЧД2 успешно декодирует УИД (который указывает на самого себя) и посылает сообщение ForwardDesiredInd на КСД.
4. ТЧД2 декодирует стирание УИД и посылает сообщение DSCChangedInd на КСД.
5. В момент Td1 времени ТЧД1 делает вывод, что ТД переключается на ТЧД2 и посылает сообщение ForwardStoppedInd на КСД. КСД устанавливает активной обслуживающей ТЧД для ТД ТЧД2.
6. ТЧД2 успешно декодирует другие символы УИД (которые являются такими же, что и ее собственное значение). Так как ТЧД2 только что послала сообщение DSCChangedInd на КСД, она посылает другое сообщение ForwardDesiredInd для подтверждения КСД, что ТД действительно переключается на ТЧД2.
7. КСД останавливает многоадресную рассылку и начинает посылать прямой трафик только на ТЧД2.
Имеются другие сценарии и реализации передачи обслуживания. Например, в некоторых вариантах осуществления КСД может выполнять многоадресную рассылку прямого трафика (например, данных ПРП) по поднабору ТЧД в активном наборе ТД в состоянии многоадресной рассылки. Как изображено выше, использование многоадресной рассылки может компенсировать стирание УИД или ошибку в обслуживающем или необслуживающем секторе.
В случае, когда активная обслуживающая ТЧД выполняет неправильное обнаружение УИД и все же считает, что УИД указывает на само себя, может не посылаться сообщение DSCChangedInd. Следовательно, состояние многоадресной рассылки не может начинаться в момент Tpd или Td, даже если другая ТЧД посылает сообщение ForwardDesiredInd. Другими словами, состояние многоадресной рассылки может начинаться только после того, как будет послано сообщение DSCChangedInd из активного обслуживающего сектора.
В некоторых вариантах осуществления, когда ТЧД посылает сообщение DSCChangedInd или ForwardStoppedInd на КСД, она также может посылать информацию о своей очереди. Например, сообщение может указывать последний байт, который был послан.
В некоторых вариантах осуществления, в конце состояния многоадресной рассылки КСД может рассылать команды на каждую ТЧД, которая больше не считается в качестве обслуживающего сектора, например, сбрасывая их соответствующие очереди данных. Эти команды, вместе с открытием и закрытием потока, отмечают период передачи. КСД может связывать каждый пакет, который он рассылает, с кодовой меткой, которая изменяется шагами (например, на единицу «1») для каждого периода передачи. Это может быть полезным при уникальной идентификации пакетов на ТЧД.
Фиг.9 иллюстрирует блок-схему последовательности операций процесса 900, который может использоваться для реализации некоторых описанных вариантов осуществления (таких как описанные выше). Этап 910 определяет метрику качества прямой линии связи (ПЛ), связанной с каждым из множества секторов, обслуживаемых множеством ТЧД (например, в активном наборе ТД). Этап 920 назначает баллы с увеличением их количества каждому сектору в отношении метрики качества ПЛ, как определено. Этап 930 определяет, что баллы, накопленные для необслуживающего сектора на границе изменения УИД, больше предварительно определенного порога, где необслуживающий сектор обслуживается необслуживающей ТЧД, отличной от обслуживающей ТЧД для ТД. Если результатом этапа 930 является «Да», этап 940 следует за ним и изменяет значение УИД с обслуживающей ТЧД на необслуживающую ТЧД. Этап 950 передает значение УИД на множество ТЧД. Этап 960 изменяет покрытие УИД в соответствии с изменением УИД (например, переуказывая покрытие УИД на необслуживающее покрытие). Если результатом этапа 930 является «Нет», процесс 900 возвращается на этап 910.
Фиг.10 иллюстрирует блок-схему последовательности операций процесса 1000, который может использоваться для реализации некоторых описанных вариантов осуществления (таких как описанные выше). Этап 1010 декодирует значение УИД, принятое от ТД (как описано в варианте осуществления по фиг.9). Этап 1020 определяет, является ли успешным декодирование. Если результатом этапа 1020 является «Да», этап 1030 определяет, имеется ли изменение декодированного значения УИД. Если результатом этапа 1030 является «Да», этап 1040 следует за ним и посылает сообщение DSCChangedInd на КСД. Если результатом этапа 1030 является «Нет», процесс 1000 возвращается на этап 1010. Если результатом этапа 1020 является «Нет», этап 1050 следует за ним и посылает сообщение DSCChangedInd(Erased) на КСД.
Фиг.11 иллюстрирует блок-схему последовательности операций процесса 1100, который может использоваться для реализации некоторых описанных вариантов осуществления (таких как описанные выше). Этап 1110 декодирует значение УИД, принятое от ТД (как описано в варианте осуществления по фиг.9). Этап 1120 определяет, является ли декодированное значение УИД равным собственному значению (например, значению необслуживающей ТЧД). Если результатом этапа 1120 является «Да», этап 1130 следует за ним и посылает сообщение ForwardDesiredInd на КСД. Если результатом этапа 1120 является «Нет», процесс 1100 возвращается на этап 1110.
Фиг.12 иллюстрирует блок-схему последовательности операций процесса 1200, который может использоваться для реализации некоторых описанных вариантов осуществления (таких как описанные выше). Процесс 1200 начинается на этапе 1205. Этап 1210 определяет, было ли принято сообщение DSCChangedInd от обслуживающей ТЧД (например, ТЧД1, описанной выше). Если результатом этапа 1210 является «Да», этап 1220 следует за ним и начинает многоадресную рассылку прямого трафика (например, данных ПРП), связанного с ТД, на множество ТЧД (например, тех, которые находятся в активном наборе ТД). Этап 1230 определяет, было ли принято сообщение ForwardDesiredInd от необслуживающей ТЧД (например, ТЧД2, описанной выше). Этап 1240 определяет, было ли принято сообщение ForwardStoppedInd от ТЧД1. Если результатами обоих этапов 1230 и 1240 являются «Да», этап 1250 следует за ними и назначает ТЧД2 активной обслуживающей ТЧД для ТД. Если результатом или этапа 1230, или этапа 1240 является «Нет», процесс 1200 возвращается на этап 1220.
На фиг.12, если результатом этапа 1210 является «Нет», этап 1260 следует за ним и определяет, было ли принято сообщение ForwardDesiredInd от необслуживающей ТЧД (например, ТЧД2, описанной выше). Если результатом этапа 1260 является «Да», этап 1270 следует за ним и начинает многоадресную рассылку прямого трафика (например, данных ПРП), связанного с ТД, на множество ТЧД (например, тех, которые находятся в активном наборе ТД). Этап 1280 определяет, было ли принято сообщение DSCChangedInd от обслуживающей ТЧД (например, ТЧД1, описанной выше). Этап 1290 определяет, было ли принято сообщение ForwardStoppedInd от ТЧД1. Если результатами обоих этапов 1280 и 1290 являются «Да», процесс 1200 переходит на этап 1250. Если результатом или этапа 1280, или этапа 1290 является «Нет», процесс 1200 возвращается на этап 1270. Если результатом этапа 1260 является «Нет», процесс 1200 возвращается на этап 1205.
Фиг.13 иллюстрирует блок-схему устройства 1300, в котором могут быть реализованы некоторые описанные варианты осуществления (такие как описанные выше). В качестве примера, устройство 1300 может включать в себя блок (или модуль) 1310 оценки качества канала, сконфигурированный на определение метрики качества прямой линии связи, связанной с каждым из множества секторов, обслуживаемых множеством ТЧД (например, тех, которые находятся в активном наборе ТД); блок 1320 назначения баллов, сконфигурированный на назначение баллов каждому сектору в отношении метрики качества ПЛ; блок 1330 выбора УИД, сконфигурированный на выбор/изменение значения УИД для ТД (например, если баллы, накопленные для необслуживающего сектора на границе изменения УИД, превышают предварительно определенный порог); передающий блок 1340, сконфигурированный на передачу значения УИД на множество ТЧД; и блок 1350 выбора УСПД, сконфигурированный на выбор/изменение покрытия УСПД в соответствие с изменением УИД.
В устройстве 1300 блок 1310 оценки качества канала, блок 1320 назначения баллов, блок 1330 выбора УИД, передающий блок 1340 и блок 1350 выбора УСПД могут быть подсоединены к шине 1360 передачи данных. Блок 1370 обработки и блок 1380 памяти также могут быть подсоединены к шине 1360 передачи данных. Блок 1370 обработки может конфигурироваться на управление и/или координирование работы различных блоков. Блок 1380 памяти может реализовывать выполнение инструкций блоком 1370 обработки.
Устройство 1300 может быть реализовано в ТД (например, ТД 106 на фиг.1) или в других устройствах связи.
Фиг.14 иллюстрирует блок-схему устройства 1400, которое может использоваться для реализации некоторых описанных вариантов осуществления (таких как описанные выше). В качестве примера, устройство 1400 может включать в себя блок (или модуль) 1410 декодирования, сконфигурированный на определение значения УИД, принятого от ТД; блок 1420 генерирования сообщения, сконфигурированный на генерирование сообщения в соответствие с декодированием УИД (например, сообщения DSCChangedInd, ForwardDesiredInd, ForwardStoppedInd или им подобных, таких как описанные выше); и передающий блок 1430, сконфигурированный на посылку сообщения, сгенерированного, таким образом, на КСД.
В устройстве 1400 блок 1410 декодирования, блок 1420 генерирования сообщения и передающий блок 1430 могут быть подсоединены к шине 1440 передачи данных. Блок 1450 обработки и блок 1460 памяти также могут быть подсоединены к шине 1440 передачи данных. Блок 1450 обработки может конфигурироваться на управление и/или координирование работы различных блоков. Блок 1460 памяти может реализовывать выполнение инструкций блоком 1450 обработки.
Устройство 1400 может быть реализовано в ТЧД (например, ТЧД1 или ТЧД2, описанных выше) или в других элементах сетевой инфраструктуры.
Фиг.15 иллюстрирует блок-схему устройства 1500, которое может использоваться для реализации некоторых описанных вариантов осуществления (таких как описанные выше). В качестве примера, устройство 1500 может включать в себя блок (или модуль) 1510 обработки сообщения, сконфигурированный на прием сообщения от ТЧД (например, сообщения DSCChangedInd, ForwardDesiredInd или ForwardStoppedInd от ТЧД1 или ТЧД2, описанных выше); блок 1520 многоадресной рассылки, сконфигурированный на многоадресную рассылку прямого трафика (например, данных ПРП), связанного с ТД, на множество ТЧД (например, тех, которые находятся в активном наборе ТД); и блок 1530 выбора сервера, сконфигурированный на выбор активной обслуживающей ТЧД для ТД.
В устройстве 1500 блок 1510 обработки сообщения, блок 1520 многоадресной рассылки и блок 1530 выбора сервера могут быть подсоединены к шине 1540 передачи данных. Блок 1550 обработки и блок 1560 памяти также могут быть подсоединены к шине 1540 передачи данных. Блок 1550 обработки может конфигурироваться на управление и/или координирование работы различных блоков. Блок 1560 памяти может реализовывать выполнение инструкций блоком 1550 обработки.
Устройство 1500 может быть реализовано в КСД (таком как описанный выше) или в другом средстве контроллера сети.
Мощность передачи служебных каналов обратной линии связи (например, каналы УСПД, УИД, индикатора обратной скорости передачи (ИОСП), подтверждения приема (ПП) и т.д.) может быть связана с фиксированными смещениями с мощностью передачи пилот-сигнала. Последняя может управляться посредством управления мощностью, которое может включать в себя управление мощностью с внутренним контуром и управление мощностью с внешним контуром. Например, управление мощностью с внутренним контуром может конфигурироваться на поддержание принимаемой мощности пилот-сигнала на ТЧД примерно равной порогу, который, в свою очередь, может определяться посредством управления мощностью с внешним контуром. В некоторых ситуациях корректировка порога посредством управления мощностью с внешним контуром может основываться на рабочих характеристиках канала передачи данных. В результате, может потребоваться, чтобы рабочие характеристики канала передачи данных рассматривались отдельно. Это может быть особенно важным в случае режима мягкой передачи обслуживания по обратной линии связи. Причина в том, что декодирование данных может извлекать пользу из объединения выбора (например, объединяя результаты декодирования от множества ТЧД в активном списке ТД) на КСД, в то время как служебные каналы не могут. Рабочие характеристики УСПД могут быть плохими особенно в присутствие дисбаланса, когда ТД указывает свое УСПД на один сектор, с которым он имеет наилучшую прямую линию связи, но его мощность управляется другим сектором, с которым он имеет лучшую обратную линию связи.
Что касается канала УСПД, если ТЧД выполняет неправильное декодирование и планирует передачу пакета, основываясь на этом, пакет может не приниматься соответствующим ТД, и все временные интервалы передачи могут заканчиваться безрезультатно. Если ТЧД не может успешно декодировать канал УСПД и объявляет стирание УСПД, ТД не может обслуживаться. В ситуации с множеством пользователей с потоками нечувствительных к задержке данных (например, с максимальными усилиями), это может вызывать малые потери пропускной способности сектора. Поэтому, умеренная скорость передачи стирания УСПД может допускаться в отношении низкой вероятности ошибки декодирования УСПД. Во время декодирования УСПД вариант УСПД с максимальной принимаемой энергией может сравниваться с порогом. Этот вариант может стать УСПД в действии, когда энергия будет больше порога; в противном случае, может объявляться стирание УСПД. Так как мощность передачи УСПД связана с мощностью пилот-сигнала, порог для энергии УСПД может быть эквивалентным порогу для принимаемой мощности пилот-сигнала (названной «Ecp/Nt» в данном документе). В качестве примера, стирание УСПД может объявляться, если Ecp/Nt падает ниже, например, -25 дБ или около этого.
Сектор(ы) может передавать на ТД ОСПШ обратной линии связи или скорость передачи стирания УСПД при помощи петли обратной связи, например, посредством бита DRCLock. Каждый сектор может устанавливать бит DRCLock для ТД в соответствии с оцененной скоростью передачи стирания. Например, бит DRCLock в «1» («в состояние захвата») может указывать, что скорость передачи стирания УСПД является допустимой; бит DRCLock в «0» («вне состояния захвата») может указывать, что скорость передачи стирания УСПД является недопустимой.
Некоторые механизмы могут быть разработаны так, чтобы избегать длительного перерыва для ТД, испытывающего сообразно высокую скорость передачи стирания: например, один может быть медленным механизмом, использующим бит DRCLock на прямой линии связи, указывающий ТД высокую скорость передачи стирания и рекомендующий ТД выполнить передачу обслуживания; другой может быть быстрым механизмом отображения стирания УСПД, и т.д.
В системе типа «1xEV-DO Release 0», например, бит DRCLock может мультиплексироваться с временным разделением каналов с каналом управления мощностью. Он может передаваться один раз каждый временной интервал DRCLockPeriod и повторяться каждую DRCLockLength. (Эквивалентным коэффициентом обратной связи может быть [600/DRCLockPeriod×DRCLockLength)] Гц, например.) Значениями по умолчанию для DRCLockPeriod и DRCLockLength могут быть, например, 8 временных интервалов. В системе типа «1xEV-DO Revision А» бит DRCLock может передаваться вместе с битом управления мощностью на синфазной или квадратурной фазе одного и того же канала УДС. Бит DRCLock может передаваться один раз каждые 4 временные интервала, например. Параметр DRCLockLength может сохраняться для бита DRCLock для повторения. Значением по умолчанию для DRCLockLength может быть 16 временных интервалов, например.
Значение бита DRCLock может основываться на отфильтрованной скорости передачи стирания УСПД. Каждое событие стирания УСПД может отображаться на двоичное значение и использоваться для обновления БИХ-фильтра. Отфильтрованное значение может рассматриваться как средняя скорость передачи стирания УСПД. Постоянная времени по умолчанию для БИХ-фильтра может составлять 32 временных интервала, например. Гистерезис может присутствовать при определении порога отфильтрованной скорости передачи стирания УСПД. Например, бит DRCLock может устанавливаться на «1», если отфильтрованная скорость передачи стирания составляет ниже 30%; бит DRCLock устанавливается на «0», если отфильтрованная скорость передачи стирания составляет выше 50%. Фиг.16 иллюстрирует вариант осуществления гистерезиса, связанного с установкой бита DRCLock, где события стирания УСПД могут оставаться постоянными или на 0 (отсутствие стирания) или на 1 (стирание) в течение относительно длительного времени. Операция фильтрации, описанная таким образом, может представлять бит DRCLock стабильным, все же медленно реагирующим на изменения канала.
Встроенная задержка при установке бита DRCLock может предполагать большую длительность последовательности импульсов стирания УСПД (период времени, в течение которого происходят последовательные стирания УСПД). Это может учитываться при передаче обслуживания. Для данных ПРП (например, чувствительных к задержке), эти стирания могут приводить к недопустимой величине перерыва в обслуживании. Таким образом, существует потребность в алгоритме отображения стирания УСПД, сконфигурированного на минимизирование перерыва в обслуживании на прямой линии связи.
В одном варианте осуществления алгоритм отображения стирания УСПД может выполняться на ТЧД при каждой DRCLength для каждого ТД. Для каждого ТД алгоритм может выполняться на каждой соте, которая имеет активную очередь (например, устанавливаемую КСД в состоянии одноадресной или многоадресной рассылки) для ТД. Когда активизируется отображение стирания УСПД, поток может быть пригодным для «ограниченного» планирования прямой линии связи (например, обслуживаемой только многопользовательскими пакетами). Стоимость отображения стирания УСПД может происходить из посылки данных без сведений о качестве канала прямой линии связи и бесполезном расходовании ассоциированных временных интервалов передачи, если ТД не может декодировать пакет. Поэтому, в некоторых ситуациях алгоритм отображения стирания УСПД может активизироваться тогда, когда выполняется все из нижеследующего:
- Длительность последовательности импульсов стирания УСПД достаточно продолжительная.
- Задержка передачи пакета, наблюдаемая планировщиком, достаточно продолжительная.
Порог (например, называемый «Max_Ers_Len» в данном документе) может ассоциироваться с длительностью последовательности импульсов стирания УСПД. Для данных/потоков ПРП (например, данных ПРПИ), установка порога может быть, например, в диапазоне от 0 до 16 временных интервалов.
Отображение стирания УСПД должно быть надежным для продолжительных длительностей последовательности импульсов стирания УСПД. Например, ТД может выполнять переключение обслуживающего сектора; однако сектор, который принимает стертые УСПД, может не иметь сведений об этом. В данной ситуации, канал УИД может использоваться в качестве дополняющей информации, способствующей принятию решения об отображении стирания УСПД, как дополнительно изображено ниже.
Подобно механизму многоадресной рассылки между КСД и ТЧД (такому как описан выше), многоадресная рассылка по радиосвязи (ПРС) может выполняться с многочисленных секторов на ТД, чтобы повысить надежность алгоритма отображения стирания УСПД, как дополнительно описано ниже.
фиг.17 иллюстрирует вариант осуществления процесса 1700, который ТЧД может выполнять для каждого ТД, который имеет этот ТЧД в своем активном наборе. Процесс 1700 начинается на этапе 1705. Этап 1710 определяет, стирается ли покрытие УСПД, принимаемое от ТД. Если результатом этапа 1710 является «Нет», этап 1720 следует за ним и планирует передачу для ТД из сектора, на который указывает покрытие УСПД. Если результатом этапа 1710 является «Да», этап 1730 следует за ним и определяет, выполняются ли критерии стирания покрытия УСПД для покрытия УСПД от ТД. Критерии стирания покрытия УСПД могут включать в себя, например, то, что длительность последовательности импульсов стирания УСПД больше Max_Ers_Len, и т.д. Если результатом этапа 1730 является «Да», этап 1740 следует за ним и определяет, стирается ли значение УИД, принимаемое от ТД. Если результатом этапа 1740 является «Нет», этап 1750 следует за ним и определяет, соответствует ли значение УИД соте, обслуживаемой ТЧД (называемой «данной сотой» в настоящем документе). Если результатом этапа 1750 является «Да», этап 1760 следует за ним и инициирует многоадресную рассылку ПРС (например, передавая прямой трафик на ТД с множества секторов, которые находятся в активном наборе ТД и в данной соте), как дополнительно иллюстрирует фиг.19. Если результатом этапа 1740 является «Да», процесс 1700 аналогичным образом переходит на этап 1760.
В процессе 1700, если результатом этапа 1750 является «Нет», процесс 1700 завершается на этапе 1770. Если результатом этапа 1730 является «Нет», процесс 1700 аналогичным образом переходит на этап 1770.
Фиг.18A-I иллюстрируют несколько процессов, которые могут использоваться для реализации процесса 1700, изображенного на фиг.17, в некоторых вариантах осуществления. На фиг.18А этап 1810 определяет, не стирается ли покрытие УСПД, принимаемое от ТД (например, Ecp/Nt выше порога стирания), не является ли нулевым покрытие УСПД (или «DRC_Cover») и является ли таким же DRC_Cover, что и последнее успешно декодированное покрытие УСПД (называемое «LDC» в данном документе), или являются ли нулевыми LDC и предпоследнее успешно декодированное покрытие УСПД (называемое «2LDC» в данном документе). Если результатами всех этих решений являются «Да», этап 1811 следует за ними и устанавливает последним действительным покрытием УСПД (или «Last_Valid_DRC_Cover») DRC_Cover и флаг, связанный с изменением покрытия УСПД (или «DRCCoverChangedFlag»), нулевым (или «0»). DRCCoverChangedFlag может использоваться для указания совместимости, связанной с покрытиями УСПД, принятыми от ТД, которая может определяться посредством сравнения покрытия УСПД с одним или несколькими ранее принятыми покрытиями УСПД от ТД. Например, DRCCoverChangedFlag может устанавливаться на «0», если покрытие УСПД совместимо с (например, по существу то же самое или сравнимое с) по меньшей мере одним из ранее принятых покрытий УСПД (например, LCD) от ТД. Предварительно определенные критерии также могут применяться при оценке совместимости, связанной с покрытием УСПД, включая (но не ограничиваясь ими), является ли покрытие УСПД действительным (например, не стирается и не является нулевым), является ли изменение покрытия УСПД в результате переключения сектора, и т.д.
На фиг.18В этап 1820 определяет, стирается ли покрытие УСПД (или «DRC_Erasure»). Если результатом этапа 1820 является «Нет», этап 1821 следует за ним и устанавливает: (1) 2LDC равным LDC; (2) LDC равным DRC_Cover; (3) последний действительный индекс УСПД (или «Last_Valid_DRC_Index») равным скорости передачи УСПД (или «DRC_Rate»), связанной с покрытием УСПД; и (4) подсчет количества стираний (или «Erasure_Count») равным «0». Если результатом этапа 1820 является «Да», этап 1822 следует за ним и устанавливает Erasure_Count увеличенным на DRCLength.
На фиг.18С для каждого активного ТД в момент Td времени этап 1830 определяет, стирается ли значение УИД, переданное с ТД, или является ли недействительным значение УИД (например, имеющее нулевое значение). Если результатом этапа 1830 является «Да», этап 1831 следует за ним и устанавливает сохраненное значение УИД (или «Stored_DSC_Value») равным значению УИД, связанному с данной сотой (или «This_Cell_DSC_Value»); флаг, связанный со стиранием УИД (или «DSC_Erased_Flag»), равным единице (или «1»); и счетчик (или «StopDRCErasureMap_dueto_DSCErasure_Counter») равным предварительно определенному периоду времени, такому как Tpd (или предварительно определенному количеству DRCLength). Если результатом этапа 1830 является «Нет», этап 1832 устанавливает Stored_DSC_Value равным декодированному значению УИД (или «DSC_Value») и DSC_Erased_Flag равным «0».
На фиг.18D этап 1840 определяет, является ли Stored_DSC_Value равным последнему действительному значению УИД (или «Last_Valid_DSC_Value»). Если результатом этапа 1840 является «Нет», этап 1841 следует за ним и устанавливает флаг, связанный с обновлением Last_Valid_DSC_Value (или «LastValidDSCValue_needs_to_be_updated_flag»), равным «1». Этап 1842 затем определяет, является ли Stored_DSC_Value равным This_Cell_DSC_Value. Если результатом этапа 1842 является «Да», этап 1843 следует за ним и устанавливает Delay_Counter равным задержке (например, измеренной в единицах временных интервалов), накопленной для переключения УИД (или «DSCSwitchDelayInSlots”). Если результатом этапа 1842 является «Нет», этап 1844 следует за ним и устанавливает Delay_Counter равным «0».
На фиг.18Е, для каждого активного ТД в каждом временном интервале, этап 1850 определяет, является ли DSC_Erased_Flag равным «1» и является ли StopDRCErasureMap_dueto_DSCErasure_Counter больше «0». Если результатом этапа 1850 является «Да», этап 1851 следует за ним и уменьшает StopDRCErasureMap_dueto_DSCErasure_Counter на «1».
На фиг.18F этап 1860 определяет, является ли Last_ValidDSCValue_needs_to_be_updated_flag равным «1». Если результатом этапа 1860 является «Да», этап 1861 следует за ним и определяет, является ли Delay_Counter равным «0». Если результатом этапа 1861 является «Нет», этап 1862 следует за ним и уменьшает Delay_Counter на «1». Если результатом этапа 1861 является «Да», этап 1863 следует за ним и устанавливает LastValidDSCValue_needs_to_be_updated_flag равным «0», и Last_Valid_DSC_Value равным Stored_DSC_Value. Этап 1864 затем определяет, является ли Stored_DSC_Value таким же, что This_Cell_DSC_Value. Если результатом этапа 1864 является «Да», этап 1865 следует за ним и устанавливает LastValidDSC_Pointing_State равным «1». В противном случае, оно устанавливается на «0», как показано на этапе 1866.
На фиг.18G этап 1870 определяет, является ли Erasure_Count больше Max_Ers_Len и является ли LastValidDSC_Pointing_State равным «1». Если результатом этапа 1870 является «Да», тогда ТД может быть пригодным для отображения стирания УСПД из данной соты, например, посредством установки Erasure_Mapped_Flag равным «1», как показано на этапе 1871.
На фиг.18H этап 1880 определяет, является ли DSC_Erased_Flag равным «1» и является ли StopDRCErasureMap_dueto_DSCErasure_Counter равным «0». Если результатом этапа 1880 является «Да», тогда ТД не является пригодным для отображения стирания УСПД из соты, например, посредством установки Erasure_Mapped_Flag равным «0», как показано на этапе 1881.
На фиг.18I этап 1890 определяет, не стирается ли покрытие УСПД и является ли DRCCoverChangedFlag равным «0». Если результатом этапа 1890 является «Да», этап 1891 следует за ним и планирует передачу для ТД из сектора, на который указывает DRC_Cover и с соответствующей DRC_Rate. Если результатом этапа 1890 является «Нет», этап 1892 следует за ним и определяет, является ли Erasure_Mapped_Flag равным «1». Если результатом этапа 1892 является «Да», этап 1893 следует за ним и инициирует многоадресную рассылку ПРС на ТД, как дополнительно описано ниже.
Фиг.19 иллюстрирует вариант осуществления процесса 1900, например, для реализации этапа многоадресной рассылки ПРС (такого как описан выше). Процесс 1900 начинается на этапе 1905. Этап 1910 определяет, имеются ли какие-либо данные для ТД в очереди, которые пригодны для отображения стирания УСПД (например, чувствительный к задержке поток с достаточно длительной задержкой передачи пакета). Если результатом этапа 1910 является «Да», этап 1920 следует за ним и передает данные для ТД из множества секторов, которые находятся в данной соте и в активном наборе ТД, используя конкретный формат пакета (называемый «DRC_index_mapped» в данном документе). Например, может использоваться формат многопользовательского пакета, совместимый с предварительно определенным набором индексов УСПД. Если результатом этапа 1920 является «Нет», процесс 1900 завершается на этапе 1930.
В одном варианте осуществления для каждого интервала DRCLength процессор прямой линии связи (например, процессор цифровой обработки сигналов (ПЦОС)) может принимать 8-битовую информацию УСПД от процессора обратной линии связи (например, ПЦОС), включающую в себя: 1-битовый флаг стирания УСПД, указывающий, что Ecp/Nt ниже порога стирания (или «DRC_Erasure»); 3-битовое покрытие УСПД (или «DRC_Cover»); 4-битовую скорость передачи УСПД (или «DRC_Rate»). В моменты Tpd и Td времени процессор прямой линии связи может принимать декодированное значение УИД (или «DSC_Value», такое как описанное выше). Алгоритм отображения стирания УСПД может выполняться (например, один раз каждую DRCLength) следующим образом:
Фиг.20 иллюстрирует блок-схему устройства 2000, которое может быть реализовано в ТЧД для выполнения некоторых описанных процессов (таких, которые описаны выше). В качестве примера, устройство 2000 может включать в себя блок (или модуль) 2010 оценки УСПД; блок 2020 оценки УИД; и блок 2030 планирования.
В устройстве 2000 блок 2010 оценки УСПД может конфигурироваться на определение значения УСПД, принимаемого от ТД; оценку, выполняются ли критерии стирания покрытия УСПД; оценку совместимости принятых покрытий УСПД; выполнение отображения стирания УСПД; и т.д. (так, как описано выше). Блок 2020 оценки УИД может конфигурироваться на определение значения УИД, принимаемого от ТД, оценку, произошло ли стирание УИД; выполнение различных функций в связи с УИД; и т.д. (так, как описано выше). Блок 2030 планирования может конфигурироваться на планирование передачи для ТД так, как описано выше. Блок 2030 планирования может дополнительно включать в себя блок 2035 многоадресной рассылки ПРС, сконфигурированный на многоадресную рассылку прямого трафика (например, данных) на ТД из многочисленных секторов (так, как описано выше).
В устройстве 2000 блок 2010 оценки УСПД, блок 2020 оценки УИД и блок 2030 планирования (вместе с блоком 2035 многоадресной рассылки ПРС) могут быть подсоединены к шине 2040 передачи данных. Блок 2050 обработки и блок 2060 памяти также могут быть подсоединены к шине 2040 передачи данных. Блок 2050 обработки может конфигурироваться на управление и/или координирование работы различных блоков. Блок 2060 памяти может реализовывать выполнение инструкций блоком 2040 обработки.
Устройство 2000 может быть реализовано в ТЧД и/или в другом средстве сетевой инфраструктуры.
Варианты осуществления, описанные в данном документе (так, как описано выше), обеспечивают некоторые варианты осуществления адаптивного выбора сервера в беспроводной связи. Существуют другие варианты осуществления и реализации. Различные варианты осуществления, описанные в данном документе, могут быть реализованы в ТД, ТЧД, КСД и/или в других элементах сетевой инфраструктуры.
Различные блоки/модули и варианты осуществления, описанные в данном документе, могут быть реализованы аппаратными, программными, программно-аппаратными средствами или их комбинацией. При аппаратной реализации различные блоки могут быть реализованы на одной или нескольких специализированных интегральных схемах (специализированных ИС), процессоре цифровой обработки сигналов (ПЦОС), устройствах цифровой обработки сигналов (УЦОС), программируемых пользователем вентильных матрицах (ППВМ), процессорах, микропроцессорах, контроллерах, микроконтроллерах, программируемых логических устройствах (ПЛУ), других электронных блоках, или любой их комбинации. При программной реализации различные блоки могут быть реализованы при помощи модулей (например, процедур, функций и т.п.), которые выполняют функции, описанные в данном документе. Программные коды могут храниться в блоке памяти и исполняться процессором (или блоком обработки). Блок памяти может быть реализован внутри процессора или вне процессора, в этом случае он может подсоединяться к процессору с возможностью передачи данных при помощи различных средств, известных в технике.
Различные описанные варианты осуществления могут быть реализованы в контроллере, ТД и других средствах для обеспечения услуг широковещательной/многоадресной рассылки. Варианты осуществления, описанные в данном документе, могут быть применены в системе обработки данных, системе беспроводной связи, однонаправленной широковещательной системе и любой другой системе, требующей эффективной передачи информации.
Специалисты в данной области техники понимают, что информация и сигналы могут представляться с использованием любых разнообразных и различных технологий и методик. Например, данные, инструкции, команды, информация, сигналы, биты, символы и чипы, которые могут упоминаться в вышеприведенном описании, могут представляться напряжениями, токами, электромагнитными волнами, магнитными полями или частицами, оптическими полями или частицами или любой их комбинацией.
Специалисты в данной области также понимают, что различные иллюстративные логические блоки, модули, схемы и этапы алгоритмов, описанные в связи с вариантами осуществления, описанными в данном документе, могут быть реализованы в виде электронных аппаратных средств, компьютерных программных средств или их комбинацией. Чтобы ясно проиллюстрировать эту взаимозаменяемость аппаратных и программных средств, различные иллюстративные компоненты, блоки, модули, схемы и этапы были описаны выше, в основном, на языке их функциональных возможностей. Реализуется ли такая функциональная возможность в виде аппаратных или программных средств зависит от конкретного применения и конструктивных ограничений, накладываемых на всю систему. Квалифицированный специалист может реализовать требуемую функциональную возможность различными путями для каждого конкретного применения, но такие решения по реализации не должны интерпретироваться как вызывающие отступление от объема настоящего изобретения.
Различные иллюстративные логические блоки, модули и схемы, описанные в связи с вариантами осуществления, описанными в данном документе, могут быть реализованы или выполнены при помощи процессора общего назначения, процессора цифровой обработки сигналов (DSP, ПЦОС), специализированной интегральной схемы (специализированной ИС, ASIC), программируемой пользователем вентильной матрицы (FPGA, ППВМ) или другого программируемого логического устройства, дискретного вентиля или транзисторной логики, дискретных аппаратных компонентов или любой их комбинации, предназначенной для выполнения функций, описанных в данном документе. Процессором общего назначения может быть микропроцессор, но в альтернативе, процессором может быть любой обычный процессор, контроллер, микроконтроллер или конечный автомат. Процессор также может быть реализован в виде комбинации вычислительных устройств, например, комбинации ПЦОС и микропроцессора, множества микропроцессоров, одного или нескольких микропроцессоров вместе с ядром ПЦОС, или любой другой такой конфигурации.
Этапы способа или алгоритма, описанные в связи с вариантами осуществления, описанными в данном документе, могут осуществляться непосредственно аппаратными средствами, программным модулем, исполняемым процессором или их комбинацией. Программный модуль может постоянно находиться в оперативном запоминающем устройстве (RAM, ОЗУ), флэш-памяти, постоянном запоминающем устройстве (ROM, ПЗУ), электрически программируемом ПЗУ (EPROM, ЭППЗУ), электрически стираемом программируемом ПЗУ (EEPROM, ЭСППЗУ), регистрах, на жестком диске, съемном диске, компакт-диске или на любом другом виде запоминающего носителя информации, известного в технике. Примерный запоминающий носитель информации соединяется с процессором, так что процессор может считывать информацию с запоминающего носителя информации и записывать информацию на него. Альтернативно, запоминающий носитель информации может быть выполнен за одно целое с процессором. Процессор и запоминающий носитель информации могут постоянно находиться в специализированной ИС. Специализированная ИС может постоянно находиться в ТД. Альтернативно, процессор и запоминающий носитель информации могут постоянно находиться в качестве дискретных компонентов в ТД.
Предшествующее описание раскрытых вариантов осуществления предусматривается для того, чтобы предоставить возможность любому специалисту в данной области техники выполнить или использовать настоящее изобретение. Различные модификации этих вариантов осуществления легко очевидны для специалиста в данной области техники, и общие принципы, определенные в данном документе, могут быть применены в других вариантах осуществления без отступления от сущности или объема изобретения. Таким образом, как предполагается, настоящее изобретение не ограничивается вариантами осуществления, показанными в данном документе, но должно согласовываться с наибольшим объемом, совместимым с принципами и новыми признаками, описанными в данном документе.
1. Способ (900) беспроводной связи, заключающийся в том, что
определяют (910) метрику качества прямой линии связи, связанную с каждым из множества секторов (102), обслуживаемого множеством точек (104) доступа;
назначают (920) баллы каждому сектору в отношении метрики качества прямой линии связи;
изменяют (940) значение управления источником данных (УИД), если баллы, накопленные для необслуживающего сектора на границе изменения УИД, превышают предварительно определенный порог и истек срок в предварительно определенном таймере, причем необслуживающий сектор обслуживается необслуживающей точкой доступа, отличной от обслуживающей точки доступа, связанной с терминалом (106) доступа; и
передают (950) значение УИД.
2. Способ по п.1, в котором дополнительно изменяют покрытие управления скоростью передачи данных (УСПД) в соответствии с изменением в значении УИД.
3. Способ по п.1, в котором метрика качества прямой линии связи включает в себя отношение сигнала к помехам и шуму (ОСПШ) прямой линии связи.
4. Способ по п.1, в котором множество секторов находятся в активном наборе терминала доступа.
5. Способ по п.1, в котором
декодируют значение управления источником данных (УИД), принятое от терминала доступа; и
посылают сообщение контроллеру сети доступа, если декодирование показывает изменение в значении УИД.
6. Способ по п.5, в котором сообщение посылают посредством обслуживающей точки доступа, связанной с терминалом доступа, показывающее стирание при декодировании значения УИД.
7. Способ по п.5, в котором сообщение посылают посредством обслуживающей точки доступа, связанной с терминалом доступа, показывающее переуказание значения УИД с обслуживающей точки доступа на необслуживающую точку доступа.
8. Способ по п.5, в котором сообщение посылают посредством необслуживающей точки доступа, показывающее указание значения УИД на необслуживающую точку доступа.
9. Способ по п.1, в котором
принимают от первой точки доступа первое сообщение, указывающее изменение в значении управления источником данных (УИД), связанным с терминалом доступа; и
осуществляют многоадресную рассылку прямого трафика, связанного с терминалом доступа, в множество точек доступа.
10. Способ по п.9, в котором прямой трафик включает в себя данные приоритетного потока (ПП).
11. Способ по п.9, в котором множество точек доступа находятся в активном наборе терминала доступа.
12. Способ по п.9, в котором дополнительно
принимают от второй точки доступа второе сообщение, подтверждающее указание значения УИД на вторую точку доступа; и
назначают вторую точку доступа в качестве активной обслуживающей точки доступа для терминала доступа.
13. Способ по п.12, в котором дополнительно завершают многоадресную рассылку и посылают прямой трафик, связанный с терминалом доступа, во вторую точку доступа.
14. Способ по п.9, в котором дополнительно
принимают второе сообщение от второй точки доступа, подтверждающее переуказание значения УИД со второй точки доступа на первую точку доступа; и
назначают первую точку доступа в качестве активной обслуживающей точки доступа для терминала доступа.
15. Устройство (1300), предназначенное для беспроводной связи, содержащее
средство для определения (1310) метрики качества прямой линии связи, связанной с каждым из множества секторов, обслуживаемого множеством точек доступа;
средство для назначения (1320) баллов каждому сектору в отношении метрики качества прямой линии связи;
средство для изменения (1330) значения управления источником данных (УИД), если баллы, накопленные для необслуживающего сектора на границе изменения УИД, превышают предварительно определенный порог и истек срок в предварительно определенном таймере, причем необслуживающий сектор обслуживается необслуживающей точкой доступа, отличной от обслуживающей точки доступа, связанной с терминалом доступа; и
средство для передачи (1340) значения УИД.
16. Устройство по п.15, дополнительно содержащее средство для изменения покрытия управления скоростью передачи данных (УСПД) в соответствии с изменением в значении УИД.
17. Устройство по п.15, в котором множество секторов находится в активном наборе терминала доступа.
18. Устройство по п.15, содержащее
средство для декодирования значения управления источником данных (УИД), принятого от терминала доступа; и
средство для посылки сообщения в контроллер сети доступа, если декодирование показывает изменение в значении УИД.
19. Устройство по п.18, в котором сообщение посылается обслуживающей точкой доступа, связанной с терминалом доступа, показывающее стирание при декодировании значения УИД.
20. Устройство по п.18, в котором сообщение посылается обслуживающей точкой доступа, связанной с терминалом доступа, показывающее переуказание значения УИД с обслуживающей точки доступа на необслуживающую точку доступа.
21. Устройство по п.18, в котором сообщение посылается необслуживающей точкой доступа, показывающее указание значения УИД на необслуживаюшую точку доступа.
22. Устройство по п.15, содержащее
средство для приема от первой точки доступа первого сообщения, показывающего изменение в значении управления источником данных (УИД), связанным с терминалом доступа; и
средство для многоадресной рассылки прямого трафика, связанного с терминалом доступа, в множество точек доступа.
23. Устройство по п.22, в котором прямой трафик включает в себя данные приоритетного потока (ПП).
24. Устройство по п.22, в котором множество точек доступа находятся в активном наборе терминала доступа.
25. Устройство по п.22, дополнительно содержащее
средство для приема от второй точки доступа второго сообщения, подтверждающего указание значения УИД на вторую точку доступа; и
средство для назначения второй точки доступа в качестве активной обслуживающей точки доступа для терминала доступа.
26. Устройство по п.25, дополнительно содержащее средство для завершения многоадресной рассылки и средство для посылки прямого трафика, связанного с терминалом доступа, во вторую точку доступа.
27. Устройство по п.22, дополнительно содержащее
средство для приема второго сообщения от второй точки доступа, подтверждающего переуказание значения УИД со второй точки доступа на первую точку доступа; и
средство для назначения первой точки доступа в качестве активной обслуживающей точки доступа для терминала доступа.
28. Способ беспроводной связи, заключающийся в том, что
определяют (910) метрику качества прямой линии связи, связанную с каждым из множества секторов, обслуживаемого множеством точек доступа;
назначают (920) баллы каждому сектору в отношении метрики качества прямой линии связи;
изменяют (940) значение управления источником данных (УИД), если баллы, накопленные для необслуживающего сектора на границе изменения УИД, превышают предварительно определенный порог и истек срок в предварительно определенном таймере, причем необслуживающий сектор обслуживается необслуживающей точкой доступа, отличной от обслуживающей точки доступа, связанной с терминалом доступа;
передают (950) значение УИД;
декодируют (1010) значение УИД, принятое от терминала доступа;
посылают (1040) сообщение контроллеру сети доступа, если декодирование показывает изменение в значении УИД;
принимают (1210) сообщение, показывающее изменение в значении УИД, связанном с терминалом доступа; и
осуществляют (1220) многоадресную рассылку прямого трафика, связанного с терминалом доступа, на множество точек доступа.
29. Система беспроводной связи, содержащая
средство для определения (1310) метрики качества прямой линии связи, связанной с каждым из множества секторов, обслуживаемого множеством точек доступа;
средство для назначения (1320) баллов каждому сектору в отношении метрики качества прямой линии связи;
средство для изменения (1330) значения управления источником данных (УИД), если баллы, накопленные для необслуживающего сектора на границе изменения УИД, превышают предварительно определенный порог и истек срок в предварительно определенном таймере, причем необслуживающий сектор обслуживается необслуживающей точкой доступа, отличной от обслуживающей точки доступа, связанной с терминалом доступа;
средство для передачи (1340) значения УИД;
средство для декодирования (1410) значения УИД, принятого от терминала доступа;
средство для посылки (1420, 1430) сообщения контроллеру сети доступа, если декодирование показывает изменение в значении УИД;
средство для приема (1510) сообщения, показывающего изменение в значении УИД, связанном с терминалом доступа; и
средство для многоадресной рассылки (1520) прямого трафика, связанного с терминалом доступа, в множество точек доступа.
