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

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

Иллюстрации

Показать все

Реферат

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

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

Перечень сокращений представлен в конце описания.

Предшествующий уровень техники

На фиг.1а представлена обобщенная схема системы UMTS, образующей предпочтительный, но не исключительный вариант осуществления для применения настоящего изобретения. Описание приводится для системы UMTS (Универсальная мобильная телекоммуникационная система) с FDD (дуплексный режим с частотным уплотнением) и TDD (дуплексный режим с временным уплотнением), к которой хорошо подходит заявленный способ, ввиду конкретной сетевой архитектуры; однако он может быть легко расширен на сотовые сети иного типа, например, GSM, которые используют подобную сетевую архитектуру.

Система UMTS, показанная на фиг.1а, содержит базовую сеть 1 (см. TS 23.002), соединенную с сетью радиодоступа (UTRAN) (см. TS 25.401), в свою очередь соединенную по радиоканалу с различными мобильными пользовательскими устройствами UЕ. Сеть UTRAN и обслуживаемые ею пользовательские устройства UЕ образуют подсистему радиосети (RNS) (см. TS 23.110). Сеть UTRAN включает в себя определенное число контроллеров радиосети (RNC) типа 2 и 3, каждый из которых соединен с соответствующей группой так называемых узлов Node B 4, 5 и 6, 7, взаимодействующих с пользовательскими устройствами UЕ. Как известно, все сети PLMN (наземная сеть мобильной связи общего пользования) развернуты на территории, подразделенной на непрерывно расположенные ячейки обслуживания, причем каждая из них соответствует зоне покрытия радиосвязью стационарной базовой станции. Одна или более ячеек образуют узел Node B. Два контроллера RNC 2 и 3 соединены следующим образом: друг с другом через lur-интерфейс, с узлами Node B 4-7 через такое же количество lub-интерфейсов, и с базовой сетью 1 через lu-интерфейс. Узлы Node B и пользовательские устройства UЕ соединены друг с другом через Uu- интерфейс. Передачи по Uu-интерфейсу основаны на методе CDMA (множественный доступ с кодовым разделением каналов), который означает, что множество сигналов могут передаваться в одном и том же временном интервале в том же самом частотном диапазоне, но разделяться в кодовой области. В зависимости от принятого стандарта, передачи CDMA могут дополнительно основываться на методе TDMA (множественный доступ с временным разделением каналов). Метод TDMA означает, что каждый кадр подразделяется на фиксированное число временных сегментов, каждый из них переносит один или более пакетов CDMA, и различные временные сегменты могут быть назначены различным пользователям или, альтернативно, пилот-сигналам общего канала сигнализации.

Со ссылкой на примерную сетевую архитектуру, описанную на фиг.1b, базовая сеть CN включает в себя сегмент «с коммутацией каналов» (CS) и сегмент «с пакетной коммутацией» (PS). Первый из них соединен с сетью PSTN (коммутируемая телефонная сеть общего пользования), а второй соединен с сетью IP (Интернет-протокол). Сегмент с коммутацией каналов включает в себя сетевые элементы MSC (центр коммутации каналов)/VLR (регистр посещаемого местоположения), которые совместно позволяют пользователям перемещаться в пределах территории, покрываемой сетью. Сегмент с коммутацией пакетов включает в себя два сетевых элемента, известных как SGSN (обслуживающий узел поддержки GPRS) и GGSN (шлюзовой узел поддержки GPRS). Первый из них взаимодействует с MSC/VLR и с HLR (регистр исходного местоположения) для получения информации о местоположении пользовательских устройств UЕ в области сегмента с коммутацией пакетов. S-RNC (обслуживающий контролер RNC) взаимодействует с блоком MSC/VLR через lu(CS)-интерфейс и с узлом SGSN через lu(PS)-интерфейс. Узел SGSN, кроме того, взаимодействует с IP-сетью через Gi-интерфейс.

Что касается функционирования, то узел RNC ответственен за стеки протоколов Уровня 2 (RLC, MAC) и Уровня 3 (RRC), а также за запрашиваемые протоколы линий связи для взаимодействия базовой сети и управляемых узлов Node B. Узел Node B ответственен за Уровень 1, а также за запрашиваемые протоколы линий связи для взаимодействия пользовательских устройств UЕ и контролера RNC. В противоположность GSM, в системе UMTS радиосоединение между пользовательским устройством UЕ и сетью радиодоступа может использовать более одной линии радиосвязи; общее количество линий радиосвязи образует так называемый «активный набор», и функциональные возможности, обеспечиваемые ими, представляют собой так называемое «макро разнесение», также полезное для процедуры «гибкой передачи обслуживания». Макро разнесение позволяет пользовательскому устройству UЕ использовать прием из множества линий связи, комбинируя все принятые сигналы наиболее эффективным образом. В процессе соединения количество ячеек, составляющих активный набор, может изменяться, то есть некоторые ячейки могут удаляться, а некоторые другие добавляться, отслеживая мобильность пользовательского устройства UЕ. Например, фиг.2 показывает случай пользовательского устройства UЕ, сначала соединенного с ячейкой А и поэтому имеющего активный набор, образованный только одной ячейкой (ячейкой А), затем добавляющего ячейку В и поэтому с двумя ячейками в активном наборе (ячейки А и В) и, наконец, заменяющего ячейку А на ячейку С, то есть вновь с двумя ячейками (ячейки А и С) в активном наборе. В случае, когда ячейка А соединена с первым контроллером RNC, а ячейка В и ячейка С - со вторым контроллером RNC, то получается, что в итоге пользовательское устройство UЕ соединено только с ячейкой А и ячейкой С, косвенным образом управляемыми первым контроллером RNC. Это случай, разумеется, применим, если в процессе этого не происходит никакого перераспределения контроллеров RNC, то есть если управление соединением не переносится от первого контроллера RNC ко второму контроллеру RNC, что представляет собой операцию, которая в действительности происходит не часто.

На протяжении множества ячеек и, возможно, также множества узлов Node B, только один контроллер RNC управляет, поддерживает и завершает управление радиосоединением. Управляющий контроллер RNC называется обслуживающим контроллером RNC (S-RNC), в то время как другие контроллеры RNC называются подчиненными контроллерами RNC (D-RNC). Контроллеры D-RNC несут ответственность за управление ресурсами непосредственно управляемого узла(ов) Node B и за передачу информации между этими узлами Node B и контроллером S-RNC. Контроллер D-RNC осуществляет информационный обмен с контроллером S-RNC через lur-интерфейс. Контроллер S-RNC принимает решение о присоединении, удалении или замене радиолиний активного набора и завершает вызовы, направленные к базовой сети. Фиг.3 представляет применение примера по фиг.2 к системе UTRAN по фиг.1а, где контроллер RNC 2 играет роль контроллера S-RNC, а контроллер RNC 3 играет роль контроллера D-RNC. В сценарии по фиг.3 соединения и интерфейсы активного набора показаны жирными линиями.

Стандарт 3GPP (Проект партнерства по созданию систем 3-го поколения) обеспечивает стандартизацию сетей радиодоступа режимов FDD и TDD системы UMTS. Документ 3GPP TS 25.423: “Technical Specification Group Radio Access Network; UTRAN lur interface RNSAP Signalling” определил сообщения, обмен которыми производится через lur-интерфейс между контроллером S-RNC и контроллером D-RNC для добавления или удаления линий радиосвязи; эти сообщения Уровня 3 соответствуют протоколу RNSAP. Протокол RNSAP поддерживает базовый мобильный режим между контроллерами RNC и передачу трафика выделенного канала (DCH) и трафика общего канала (ССН).

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

- число попыток радиодоступа;

- число успешных радиодоступов;

- число сбоев линии радиосвязи;

- число попыток передачи обслуживания и т.д.

Отчет о конкретном событии может быть сделан со ссылкой на конкретную причину, например число попыток радиодоступа «для соединения сигнализации» или «для пакетного вызова», или для вызова с коммутацией каналов» и т.д. Данные, собранные РМ-счетчиком, могут выявлять проблемы или неэффективные операции в сети, которые невозможно выявить иным образом. Сбой аппаратных средств может немедленно сигнализироваться конкретной предупредительной сигнализацией, если предусмотрено, но, например, сбой программного обеспечения или подоптимальная регламентация ячейки не завершается явным уведомлением посредством предупредительной сигнализации. Здесь только после сбора соразмерного объема трафика данных и выполнения некоторой пост-обработки может быть сделан осмысленный вывод. В настоящее время РМ-счетчики в действительности являются счетчиками событий трафика, которые допускают такую постобработку. Поэтому для такого рода проблем они остаются единственным эффективным инструментом в руках оператора для контроля его сети. Однако для того чтобы РМ-счетчик был эффективным, важно, чтобы он не только сообщал о количественных данных для конкретного события, но также обеспечивал информацию о том, откуда взяты собранные данные. Это, в частности, имеет место для РМ-счетчиков, осуществляющих сбор данных в отношении событий сбоя линии радиосвязи, то есть о количестве таких событий, которые обусловили разъединение линии радиосвязи и, возможно, потерю вызова. Для этих случаев для оператора очень важно знать затронутые при этом ячейки, чтобы начать анализ и, в конечном счете, осуществить вмешательство в соответствии с тем, как это требуется.

Характеристика технической проблемы

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

Следующие чертежи, представленные на фиг.4, 5 и 6, взятые из TS 25.423, иллюстрируют это положение. Фиг.4 иллюстрирует процедуру удаления линии радиосвязи, осуществляемую через lur-интерфейс, показанный на фиг.3, в случае успеха. Как показано на фиг.4, контролер S-RNC посылает RSNAP-сообщение «запрос удаления линии радиосвязи» к контролеру D-RNC, который сначала успешно завершает удаление линии радиосвязи, существующей между пользовательским устройством UE и ячейкой С, и затем посылает назад сообщение «ответ на запрос удаления линии радиосвязи» к контроллеру S-RNC. Линия радиосвязи, существующая между пользовательским устройством UE и ячейкой С, непосредственно удаляется контроллером S-RNC. На фиг.5 показано содержание RSNAP-сообщения «запрос удаления линии радиосвязи», а на фиг.6 показано содержание сообщения «ответ на запрос удаления линии радиосвязи». Со ссылкой на фиг.5, значение различных элементов из IE/Group Name (информационный элемент/имя группы) перечислено ниже:

- «Тип сообщения» уникальным образом идентифицирует посылаемое сообщение.

- «ID (идентификатор) транзакции» используется для связывания всех сообщений, принадлежащих одной и той же процедуре. Сообщения, принадлежащие одной и той же процедуре, должны использовать тот же самый «ID транзакции». Этот ID определяется инициирующим узлом процедуры.

- «ID RL (идентификатор радиолинии)» является уникальным идентификатором (ID) для одной радиолинии (RL), связанной с пользовательским устройством UE.

Как показано на фиг.5, сообщение «запрос удаления линии радиосвязи», посланное контролером S-RNC, не содержит указания для контроллера D-RNC относительно того, будет ли радиосоединение продолжать действовать после удаления данной линии радиосвязи или оно будет разъединено. В результате можно заключить, что в настоящее время контроллер S-RNC может только отсчитать число событий разъединения радиосоединения, следующих за удалением линии радиосвязи. В настоящее время, как пояснено выше, удаление линии радиосвязи может быть инициировано плохим качеством приема, например потерей синхронизации с данной линией радиосвязи в принимающем узле Node B. Потеря синхронизации восходящей линии, которая заканчивается разъединением радиосоединения, рассматривается как аномальное событие, которого следует избегать по мере возможности. Его возникновение может выявить недостаток в покрытии радиосвязью или наличие неожиданной взаимной помехи, и эти проблемы должны быть разрешены оператором. Однако, как пояснено выше, для того чтобы оператор мог предпринять соответствующие меры в условиях большого количества разъединений радиосоединений по причине сбоя линии радиосвязи, необходимо обязательно знать идентификацию ячейки, в которой произошло такое большое количество событий отказов. Чтобы обеспечить требуемую географическую информацию вместе с собранными данными, контроллер S-RNC должен сохранять такое количество РМ-счетчиков для событий разъединения соединения вследствие отказа линии радиосвязи, которое равно числу непосредственно контролируемых ячеек, то есть ячеек, принадлежащих к узлам Node B, соединенным с контроллером S-RNC через lub-интерфейс, а также, вероятно, косвенным образом контролируемых ячеек, то есть ячеек, принадлежащих к узлам Node B, соединенным с контроллером S-RNC через lur-интерфейс. В то время как хранение идентификаторов ячеек, относящихся к непосредственно контролируемым ячейкам, является возможным и обычно выполняется, это не имеет места для других ячеек, в принципе, из-за того, что их число чрезвычайно велико. В качестве примера можно привести следующее: в среднем, число ячеек, которые непосредственно управляются контроллером RNC, может составлять порядка 1000. При этом контроллеры RNC могут иметь до 8 lur-соединений с различными контроллерами RNC, поэтому можно заключить, что запись контекста ячеек соседних контроллеров RNC увеличит число РМ-счетчиков с 1000 до 8000. Это явно сложная и дорогостоящая задача для выполнения, с учетом того, что множество дополнительных информационных полей, иных, чем предназначенные только для отсчета, связаны с каждым РМ-счетчиком для событий разъединения соединений, обусловленных сбоями линии радиосвязи.

Известные решения представленной технической проблемы

Предложено, по меньшей мере, три способа частичного решения вышеуказанной проблемы, они пояснены ниже. Первый из них заключается в обеспечении контроллера S-RNC РМ-счетчиком улавливающего типа, который получает приращение всякий раз, когда соединение аномальным образом разъединяется ввиду того, что контроллер D-RNC сообщает о сбое линии радиосвязи, обнаруженном в одной из непосредственно связанных с ним ячеек. Недостаток данного способа заключается в том, что, при наличии уникального РМ-счетчика для всех возможных косвенным образом соединенных ячеек, не может обеспечиваться информация о географическом положении затронутых ячеек. Второй способ заключается в том, чтобы определить в контроллере S-RNC количество РМ-счетчиков, соответствующее количеству контроллеров D-RNC, которые могут подсоединяться; каждый раз, когда соединение аномальным образом разъединяется, ввиду чего подсоединенный контроллер D-RNC направляет сообщение с указанием события сбоя линии радиосвязи, конкретный РМ-счетчик, ассоциированный с этим контроллером D-RNC, будет получать соответствующее приращение. Хотя этот способ позволяет знать то, в каком контроллере RNC произошло событие сбоя, однако географическая информация по-прежнему не известна. Третий предложенный способ состоит в том, чтобы определить в контроллере S-RNC такое количество РМ-счетчиков, которое равно числу возможных косвенным образом связанных ячеек, которые принадлежат к первому кольцу соседнего местоположения. Также и в этом случае информация точного географического местоположения ячейки, представляющей интерес, не всегда доступна, несмотря на увеличенное количество РМ-счетчиков.

Задача изобретения

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

Сущность изобретения и его преимущества

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

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

- аномальное завершение вызова вследствие потери синхронизации восходящей линии связи от мобильной станции;

- сбой линии радиосвязи без потери вызова;

- нормальное завершение вызова;

- аномальное завершение вызова ввиду чрезмерного трафика внутри обслуживаемой области;

- удаление линии радиосвязи с завершением или без завершения вызова, ввиду сбоя установления RAB (например, для дополнительной речевой/пакетной услуги к существующей в данный момент услуге);

- удаление линии радиосвязи ввиду других причин, по усмотрению оператора.

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

Как следствие, другим объектом настоящего изобретения является RNSAP-сообщение запроса удаления линии радиосвязи, содержащего конкретную причину запроса удаления, как раскрыто в соответствующем пункте формулы изобретения.

Сущность изобретения хорошо согласуется с системой UMTS FDD, но может быть расширена на режим TDD, что предусматривает ту же самую сетевую архитектуру и тот же самый обмен сообщениями через интерфейсы линий связи, а также на любую другую систему, которая предусматривает прямое логическое соединение между двумя контроллерами радиосвязи (например, RNC и BSC).

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

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

Фиг.1а - обобщенная схема системы UMTS;

Фиг.1b - обобщенная схема базовой сети по фиг.1а;

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

Фиг.3 - иллюстрация с помощью выделенных линий применения примера по фиг.2 к сети UTRAN по фиг.1а;

Фиг.4 - случай успешной процедуры удаления линии радиосвязи через lur-интерфейс по фиг.3, согласно 3GPP TS 25.423;

Фиг.5 - содержание RNSAP-сообщения «запрос удаления линии радиосвязи», согласно 3GPP TS 25.423;

Фиг.6 - содержание сообщения «ответ на запрос удаления линии радиосвязи», согласно 3GPP TS 25.423;

Фиг.7 - схематичное представление обобщенной архитектуры протокола сигнализации, используемой в сети UMTS по фиг.1а и 1b;

Фиг.8 - стеки протоколов плоскости управления CS (коммутация каналов) и PS (коммутация пакетов) на различных интерфейсах сети UMTS по фиг.1а и 1b;

Фиг.9 - содержание предложенного RNSAP-сообщения «запрос удаления линии радиосвязи», согласно настоящему изобретению.

Детальное описание варианта осуществления изобретения

Описание предпочтительного варианта осуществления изобретения использует описание предыдущих чертежей, относящихся к сети UMTS. Сеть развернута на территории, разделенной на непрерывные ячейки обслуживания, каждая из которых соответствует области покрытия радиосвязью, обеспечиваемого стационарной базовой станцией. Одна или более ячеек образуют так называемый узел Node B. Каждый узел Node B соединен радиосвязью с множеством пользовательских устройств UE. Несколько смежных узлов Node B физически соединены с контроллером RNC, который, в свою очередь, соединен базовой сетью.

Фиг.7 схематично представляет обобщенную архитектуру протокола сигнализации, используемую в сети UMTS. С этой целью сеть подразделяется на части UE, UTRAN, CN, отделенные соответственно Uu- и lu-интерфейсами (хотя на фиг.7 не показано, но система UTRAN имеет lur- и lub-интерфейсы). Уровень доступа с наложенным на него уровнем отсутствия доступа (NAS) показаны на представленной архитектуре. Уровень доступа включает в себя: lu-протоколы, определенные в TAS 25.41x, lur-/lub-протоколы, определенные в TAS 25.42x/TAS 25.43x, и протоколы радиосвязи, определенные в TAS 25.2хх и 25.3хх. Пользовательские данные и управляющая информация передаются между базовой сетью CN и пользовательскими устройствами UE с использованием протоколов радиосвязи и lu-протоколов уровня доступа. Эти протоколы содержат механизмы для прозрачного переноса NAS-сообщений, т.е. так называемые процедуры прямого переноса (DT). NAS-уровень включает в себя протоколы более высоких уровней для регулирования аспектов управления, такие как СМ, ММ, GММ, SMS и т.п.

На фиг.8 представлены основные стеки протоколов в плоскости управления CS и PS, относящиеся к системе UMTS по фиг.1а и 1b. В нижней части чертежа представлены следующие элементы: пользовательское устройство UE, узел Node B, контроллеры D-RNC, S-RNC, базовая сеть CN и соответствующие интерфейсы: Uu, lub, lur, lu [lu(CS), lu(PS)]. Нижняя часть плоскости управления включает в себя транспортный уровень, на котором находятся протоколы радиосвязи и протоколы уровня отсутствия доступа. Транспортный уровень включает в себя Уровень 1 (L1), и Уровень 2 (L2), и часть ALCAP. Средняя часть уровня управления включает в себя протоколы радиосвязи. NAS-протоколы показаны сверху. Согласно фиг.8, транспортная плоскость на Uu-интерфейсе состоит из режима FDD или TDD системы UMTS Уровня 1 (физический уровень) и протоколов MAC и RLC Уровня 2. Транспортная плоскость на lub-, lur- и lu-интерфейсах состоит из того же Уровня 1 для пользовательской плоскости. Пользовательская плоскость включает в себя поток(и) данных и канал(ы)-носитель(ли) для потока(ов) данных. Каждый поток данных характеризуется одним или более протоколов кадров, определенных для этих интерфейсов. Протоколы ATM и AAL2/AAL5 используются в качестве протоколов сигнализации Уровня 2, в частности, посредством ALCAP.

Показанные протоколы радиосвязи являются следующими: RRC, NBAP, RNSAP и RANAP. RRC-сообщение переносит всю информацию, требуемую для установки, изменения или освобождения линий радиосвязи (RL), которые несут в своей полезной нагрузке NAS-сигнализацию верхнего уровня и обеспечивают пользовательскому устройству UE мобильность в RRC-соединенном режиме. Протокол NBAP используется в качестве протокола Уровня 3 на lub-интерфейсе. Он несет общую сигнализацию или специализированную сигнализацию между контроллером RNC и узлами Node B. Протокол RNSAP используется в качестве протокола Уровня 3 на lur-интерфейсе. Он поддерживает базовую мобильность между контроллерами RNC и передачи трафика выделенного канала (DCH) и общего канала (CCH). Протокол RАNAP используется в качестве протокола Уровня 3 на lu-интерфейсе. Он используется для сигнализации между сетью UTRAN и базовой сетью 1. Протокол RАNAP отвечает на lu-интерфейсе, например, за следующее: поисковый вызов, распределение каналов-носителей радиосвязи (RAB), перераспределение контроллеров S-RNC, контроль защиты, и перегрузки, и перенос NAS-сигнализации.

Показанные NAS-протоколы являются следующими: MM, GMM, SM и CM. Протокол ММ поддерживает такие функции, как присоединение/отсоединение пользовательского устройства UE, функции защиты и обновление области местоположения/маршрутизации. Протокол SM поддерживает активацию/деактивацию PDP-контекста для PS-соединений. Протокол СМ используется для поддержки управления вызовом с коммутацией каналов, вспомогательных услуг и услуги SMS. Кроме того, протоколы RANAP и RRC содержат процедуры прямого переноса для прозрачного переноса NAS-сообщения между пользовательским устройством UE и базовой сетью.

В то время как протокол RNSAP является сегментом сигнализации, наиболее часто используемым в настоящем изобретении, некоторые другие обоснования выведены посредством 3GPP TS 25.423. Например, Таблица (раздел 7), показывает соответствие между функциями и элементарными процедурами протокола RNSAP. В числе этих функций распределение линий радиосвязи и измерения для администрирования линий радиосвязи в отношении выделенных ресурсов имеют основное значение для заявленного изобретения. Каждый контроллер RNC (как обслуживающий, так и подчиненный) может использовать процедуры, составляющие указанные функции, включая установку, поддержку, отслеживание и завершение линии радиосвязи, имеющей отношение к ячейке, принадлежащей к непосредственно сопряженному с ней узлу Node B. Упомянутая линия радиосвязи передает речевые сигналы и/или сигналы пакетных данных по выделенному каналу (DCH) как индивидуально, так и одновременно. С целью администрирования, каждый контроллер RNC имеет достаточный объем памяти для сохранения различных типов счетчиков характеристик, в частности счетчиков, предназначенных для отсчета сбоев линий радиосвязи в подсоединенных ячейках; число этих счетчиков равно полному числу ячеек всех узлов Node B, непосредственно сопряженных с контроллером RNC. Как уже отмечено выше, при введении концепции активного набора, каждый контроллер RNC может действовать как основной или подчиненный для множественной линии радиосвязи между пользовательским устройством UE и одним или более узлами Node B. Основные или подчиненные контроллеры RNC также определяются соответственно как S-RNC и D-RNC. Информационный обмен между двумя типами контроллеров RNC для выполнения процедур протокола RNSAP, описанный в Таблице, использует lur-интерфейс между двумя сетевыми элементами. Способ, соответствующий изобретению, использует возможности связи через lur-интерфейс, побуждая контроллер D-RNC отсчитывать каждое событие, связанное с причиной, переданной контролером S-RNC, выполняющим завершение путем удаления линии радиосвязи активного набора, которая непосредственно контролируется контроллером D-RNC. Знание причины для этого типа отсчета обычно принадлежит только контроллеру S-RNC в роли основного контроллера активного набора, но как только релевантная информация перенесена в контроллер D-RNC, последний может выполнить приращение счетчика по принципу «по каждой ячейке» и «по каждой причине». В процессе операции, содержимое RNSAP-сообщения «запрос удаления линии радиосвязи», показанного на фиг.5, обновляется, как показано на фиг.9. Обновленное сообщение отличается от известного сообщения, главным образом, за счет добавления поля «причина» в столбце IE (информационный элемент)/имя группы и некоторых связанных информационных элементов (IE) в соответствующей строке сообщения. Среди причин разъединения в столбце «описание семантики» может быть предусмотрено следующее:

Причина 1: Аномальное разъединение соединения ввиду определенной потери синхронизации на стороне пользовательского устройства UE.

Причина 2: Сбой линии радиосвязи без разъединения соединения.

Причина 3: Нормальное разъединение соединения.

Причина 4: Аномальное разъединение соединения вследствие чрезмерного трафика.

Причина 5: Удаление линии радиосвязи без разъединения соединения или нет ввиду сбоя установления RAB.

Причина 6: Удаление линии радиосвязи вследствие других причин по усмотрению оператора.

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

На основе полученной причины удаления, контроллер D-RNC может вызывать приращение соответствующего РМ-счетчика для соответствующей причины разъединения со ссылкой на релевантный контекст ячейки. В частности, в случае, когда контроллер D-RNC принимает от контроллера S-RNC сообщение «запрос разъединения линии радиосвязи», соответствующее причине 1, он будет вызывать приращение соответствующего РМ-счетчика со ссылкой на ячейку, которая управляла линией радиосвязи, запрашиваемой для удаления. В случае, когда более одной ячейки (например, М ячеек в активном наборе) управляло данным соединением, контроллер D-RNC может выбрать, например, ячейку, принятую последней в активный набор, или все их, тем самым вызывая приращение соответствующего одного или М РМ-счетчиков для указанной причины удаления. То же самое происходит и для других причин.

Периодически, сетевой оператор восстанавливает все РМ-счетчики из глобальной сети UTRAN, так что он может ассоциировать конкретные события сбоя линии радиосвязи с конкретной географической областью (ячейкой).

Перечень сокращений

AS	уровень доступа
ALCAP	часть приложения управления линией доступа
BSC	контроллер базовых станций
CDMA	множественный доступ с кодовым разделением каналов
CCH	общий канал
CN	базовая сеть
CM	управление соединением
CS	с коммутацией каналов
DCH	выделенный канал
D-RNC	подчиненный RNC
DT	прямой перенос
FDD	дуплексный режим с частотным уплотнением
GGSN	шлюзовой узел поддержки GPRS
GMM	управление мобильностью для GPRS
GSM	глобальная система мобильной связи
HLR	регистр исходного местоположения
IP	Интернет-протокол
MAC	уровень управления доступом к среде передачи
MM	управление мобильностью
NAS	уровень отсутствия доступа
NBAP	часть приложения узла Node B
NE	сетевой элемент
PDP	протокол пакетных данных
PLMN	наземная сеть мобильной связи общего пользования
PM	измерение характеристик
PS	с пакетной коммутацией
PSTN	коммутируемая телефонная сеть общего пользования
RAB	канал-носитель радиодоступа
RANAP	часть приложения сети радиодоступа
RLC	уровень управления линией радиосвязи
RNC	контроллер радиосети
RNS	подсистема радиосети
RNSAP	часть приложения подсистемы радиодоступа
RRC	уровень управления радиоресурсами
SM	управление сеансом
SMS	служба коротких сообщений
SGSN	обслуживающий узел поддержки GPRS
S-RNC	обслуживающий RNC
TDD	дуплексный режим с временным уплотнением
TDMA	множественный доступ с временным разделением каналов
UE	пользовательское устройство
UTRAN	универсальная наземная сеть радиодоступа
UMTS	универсальная мобильная наземная система
VLR	регистр посещаемого местоположения
3GPP	проект партнерства в создании систем 3-го поколения

Соответствие между функциями и элементарными процедурами RNSAP
Функция	Элементарная(ые) процедура(ы)
Управление линией радиосвязи	а) Установка линии радиосвязиb) Добавление линии радиосвязиc) Удаление линии радиосвязиd) Изменение конфигурации несинхронизированной линии радиосвязиe) Подготовка изменения конфигурации синхронизированной линии радиосвязиf) Фиксация изменения конфигурации синхронизированной линии радиосвязиg) Отмена изменения конфигурации синхронизированной линии радиосвязиh) Приоритетное прерывание обслуживания линии радиосвязиi) Активация линии радиосвязиj) Обновление параметра линии радиосвязи
Изменение конфигурации физического канала	Изменение конфигурации физического канала
Администрирование канала радиосвязи	a) Сбой линии радиосвязиb) В