Способы и системы для адаптивного выбора сервера в беспроводной связи

Способы и системы для адаптивного выбора сервера в беспроводной связи

Иллюстрации

Показать все

Реферат

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

Настоящее описание относится, в основном, к системам связи. Более конкретно, варианты осуществления, описанные в данном документе, относятся к адаптивному выбору сервера в беспроводной связи.

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

Системы беспроводной связи широко используются для предоставления различных видов связи (например, речь, данные и т.д.) многочисленным пользователям. Такие системы могут основываться на многостанционном доступе с кодовым разделением каналов (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 временных интервалов). Пусть сектор А будет текущим обслуживающим сектором и сектор В - в качестве другого сектора в активном наборе ТД. Параметр, названный «балл» в данном документе и обозначенный C_B, может сохраняться для сектора В и обновляться следующим образом:

Уравнение 4

где

Уравнение 5

В вышеприведенном, SINR_A(n) и SINR_B(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 А» может быть сделана возможной услуга непрерывной передачи данных (например, данные/потоки ПРП) посредством использования канала УИД. Она может выполняться посредством декодирования канала УИД перед границей изменения УИД и выполнением многоадресной рассылки КСД данных на некоторые или все секторы в активной наборе ТД между ранним обнаружением и окончательным обнаружением на границе УИД. В некоторых ситуациях многоадресная рассылка может применяться только в приложениях ПРП (например, чувствительные к задержке данные, такие данные ПРПИ), чтобы ограничить воздействие на трафик обратной доставки.

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

Чтобы способствовать пересылке очереди и ограничить пакет с многочисленными временными интервалами вокруг T_d, может быть желательным раннее принятие решения. Например, каждая ТЧД может обеспечивать решение по декодированию УИД в момент T_pd, который предшествует T_d на предварительно определенное (например, конфигурируемое в масштабе системы) количество временных интервалов (например, 12 временных интервалов). Этот же порог энергии может использоваться в окончательном решении при T_d. Могут быть ситуации, когда эти ранние обнаружения не являются такими же надежными, как и окончательное решение; они могут компенсироваться, однако, многоадресной сущностью передачи данных между T_pd и T_d.

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

- Обслуживающая ТЧД: ТЧД, которая объявила сообщение (например, ForwardDesiredInd) для КСД и рассматривается как обслуживающая ТЧД до тех пор, пока она не объявит другое сообщение (например, ForwardStoppedInd) для КСД. (Обслуживающий сектор может ссылаться на сектор, обслуживаемый обслуживающей ТЧД.)

- Активная обслуживающая ТЧД: ТЧД, которая объявила сообщение ForwardDesiredInd для КСД и рассматривается КСД обслуживающей данные на ТД.

- Необслуживающая ТЧД: ТЧД, которая объявила сообщение ForwardStoppedInd для КСД и рассматривается как необслуживающая ТЧД до тех пор, пока она не объявит сообщение ForwardDesiredInd для КСД. (Необслуживающий сектор может ссылаться на сектор, обслуживаемый необслуживающей ТЧД.)

В дополнение к сообщениям ForwardStoppedInd и ForwardDesiredInd новое сообщение, называемое «DSCChangedInd» в данном документе, может использоваться ТЧД для указания КСД изменения в декодированном значении, связанном с каналом УИД. Это указание может выдаваться любой обслуживающей ТЧД в активном наборе ТД и указывает одно из следующего:

- Значение УИД, указывающее идентификацию ТЧД, на которую ТД предполагает выполнить передачу обслуживания. В данном случае, также может предусматриваться время изменения УИД, указывающее момент времени, при котором может оказать действие указанное значение УИД.

- Стирание, указывающее, что ТЧД не смогла успешно декодировать канал УИД.

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

- ForwardDesiredInd: ТЧД успешно декодировала канал УИД, принятый от ТД, и декодированное значение УИД является таким же, что и ее собственное значение (или самозначение) УИД. Оно может генерироваться в момент T_pd и T_d.

- DSCChangedInd(Erased): ТЧД не может декодировать канал УИД, принимаемый от ТД. Оно может генерироваться в момент T_pd и T_d.

- DSCChangedInd(Changed): ТЧД успешно декодировала канал УИД, принятый от ТД, и декодированное значение УИД отличается от ее собственного значения УИД. Оно может генерироваться в момент T_pd.

- ForwardStoppedInd: Оно генерируется тогда, когда ТЧД успешно определила, что значение УИД не является тем же, что и ее собственное значение УИД для конфигурируемого количества временных интервалов. Оно может генерироваться в момент T_d.

Таблица 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 успешно декодирует канал УИД в момент T_pd1 времени и посылает сообщение ForwardDesiredInd на КСД.

4. В момент T_d1 времени ТЧД1 делает вывод, что ТД переключается на ТЧД2 и посылает сообщение ForwardStoppedInd на КСД.

5. КСД устанавливает активной обслуживающей ТЧД для ТД ТЧД2, останавливает многоадресную рассылку и начинает посылать прямой трафик только на ТЧД2.

Фиг.6 иллюстрирует вариант осуществления последовательности событий, происходящих во втором сценарии режима мягкой передачи обслуживания, когда активная обслуживающая ТЧД (или «ТЧД1») может правильно обнаруживать изменение УИД, и необслуживающая ТЧД (или «ТЧД2») обнаруживает стирание УИД. На различных этапах, изображенных на фиг.6:

1. ТЧД1 декодирует канал УИД и определяет, что ТД больше не указывает своим УИД на ТЧД1. ТЧД1 затем посылает сообщение DSCChangedInd на КСД, которое может включать в себя новое значение УИД, текущий уровень очереди, предсказываемое время переключения и т.д.

2. КСД входит в состояние многоадресной рассылки, например, начиная выполнять многоадресную рассылку прямого трафика по всем ТЧД в активном наборе ТД.

3. ТЧД2 успешно декодирует канал УИД (который указывает на самого себя) и посылает сообщение ForwardDesiredInd на КСД.

4. ТЧД2 декодирует стирание УИД и посылает сообщение DSCChangedInd на КСД.

5. В момент T_d1 времени ТЧД1 делает вывод, что ТД переключается на ТЧД2 и посылает сообщение ForwardStoppedInd на КСД. КСД устанавливает активной обслуживающей ТЧД для ТД ТЧД2.

6. ТЧД2 успешно декодирует многочисленные символы УИД (которые являются такими же, что и ее собственное значение). Так как ТЧД2 только что послало сообщение DSCChangedInd на КСД, оно посылает другое сообщение ForwardDesiredInd для подтверждения КСД, что ТД действительно переключается на ТЧД2.

7. КСД останавливает многоадресную рассылку и начинает посылать прямой трафик только на ТЧД2.

Фиг.7 иллюстрирует вариант осуществления последовательности событий, происходящих в третьем сценарии режима мягкой передачи обслуживания, когда активная обслуживающая ТЧД (или «ТЧД1») обнаруживает изменение УИД после стирания УИД, и необслуживающая ТЧД (или «ТЧД2») может правильно обнаруживать изменение УИД. На различных этапах, изображенных на фиг.7:

1. ТЧД2 успешно декодирует канал УИД (который является таким же, что и ее собственное значение) и посылает сообщение ForwardDesiredInd на КСД.

2. КСД входит в состояние многоадресной рассылки, например, начинает выполнять многоадресную рассылку прямого трафика на все ТЧД в активном наборе ТД.

3. В момент T_d1 времени ТЧД1 декодирует стирание УИД и посылает сообщение DSCChangedInd на КСД.

4. ТЧД1 декодирует канал УИД (который указывает на другую ТЧД) и посылает сообщение DSCChangedInd на КСД.

5. В момент T_d2 времени ТЧД1 делает вывод, что ТД переключается на ТЧД2 и посылает сообщение ForwardStoppedInd на КСД. КСД устанавливает активной обслуживающей ТЧД для ТД ТЧД2.

6. КСД останавливает многоадресную рассылку и начинает посылать прямой трафик только на ТЧД2.

Фиг.8 иллюстрирует вариант осуществления последовательности событий, происходящих в четвертом сценарии режима мягкой передачи обслуживания, когда активная обслуживающая ТЧД (или «ТЧД1») восстанавливается от стирания УИД, и необслуживающая ТЧД (или «ТЧД2») восстанавливается от стирания УИД. На различных этапах, изображенных на фиг.8:

1. ТЧД1 декодирует стирание УИД и посылает сообщение DSCChangedInd на КСД.

2. КСД входит в состояние многоадресной рассылки, например, начиная многоадресную рассылку прямого трафика на все ТЧД в активном наборе ТД.

3. ТЧД2 успешно декодирует УИД (который указывает на самого себя) и посылает сообщение ForwardDesiredInd на КСД.

4. ТЧД2 декодирует стирание УИД и посылает сообщение DSCChangedInd на КСД.

5. В момент T_d1 времени ТЧД1 делает вывод, что ТД переключается на ТЧД2 и посылает сообщение ForwardStoppedInd на КСД. КСД устанавливает активной обслуживающей ТЧД для ТД ТЧД2.

6. ТЧД2 успешно декодирует другие символы УИД (которые являются такими же, что и ее собственное значение). Так как ТЧД2 только что послала сообщение DSCChangedInd на КСД, она посылает другое сообщение ForwardDesiredInd для подтверждения КСД, что ТД действительно переключается на ТЧД2.

7. КСД останавливает многоадресную рассылку и начинает посылать прямой трафик только на ТЧД2.

Имеются другие сценарии и реализации передачи обслуживания. Например, в некоторых вариантах осуществления КСД может выполнять многоадресную рассылку прямого трафика (например, данных ПРП) по поднабору ТЧД в активном наборе ТД в состоянии многоадресной рассылки. Как изображено выше, использование многоадресной рассылки может компенсировать стирание УИД или ошибку в обслуживающем или необслуживающем секторе.

В случае, когда активная обслуживающая ТЧД выполняет неправильное обнаружение УИД и все же считает, что УИД указывает на само себя, может не посылаться сообщение DSCChangedInd. Следовательно, состояние многоадресной рассылки не может начинаться в момент T_pd или T_d, даже если другая ТЧД посылает сообщение ForwardDesiredInd. Другими словами, состояние многоадресной рассылки может начинаться только после того, как будет послано сообщение DSCChangedInd из активного обслуживающего сектора.

В некоторых вариантах осуществления, когда ТЧД посылает сообщение DSCChangedInd или ForwardStoppedInd на КСД, она также может посылать информацию о своей очереди. Например, сообщение может указывать последний байт, который был послан.

В некоторых вариантах осуществления, в конце состояния многоадресной рассылки КСД может рассылать команды на каждую ТЧД, которая больше не считается в качестве обслуживающего сектора, например, сбрасывая их соответствующие очереди данных. Эти команды, вместе с открытием и закрытием потока, отмечают период передачи. КСД может связывать каждый пакет, который он рассылает, с кодовой меткой, которая изменяется шагами (например, на единицу «1») для каждого периода передачи. Это может быть полезным при уникальной идентификации пакетов на ТЧД.

Фиг.9 иллюстрирует блок-схему последовательности