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

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

Иллюстрации

Показать все

Реферат

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

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

УРОВЕНЬ ТЕХНИКИ

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

RFC 4006, озаглавленный «Diameter Credit-Control Application» (DCCA), предоставляет техническое описание, которое может использоваться для реализации кредитного управления в режиме реального времени для многообразия услуг конечного пользователя, таких как услуг сетевого доступа, услуг Протокола Инициации Сеанса (SIP), услуг обмена сообщениями, услуг загрузки. RFC 4006 представляет общее решение в отношении расчета стоимости и кредитного контроля в режиме реального времени в системах тарификации.

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

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

Фиг. 2 иллюстрирует систему тарификации согласно Фиг. 1, включающую в себя централизованную базу данных, которая образует хранилище информации, указывающее местоположения и соединения Точки Данных об Услуге (SDP);

Фиг. 3 иллюстрирует три сетевых узла, которые выполнены с возможностью предоставления отчета об их местоположениях и соединениях Системе Доменных Имен (DNS), которая включает в себя централизованную базу данных;

Фиг. 4 иллюстрирует схему операций и связанных потоков сообщений, которые выполняются сетевым Узлом 0 для записи своего местоположения в записи Услуги (SRV) и записи Указателя Полномочий Имени (NAPTR) собственно DNS согласно Фиг. 3;

Фиг. 5 иллюстрирует схему операций и связанных потоков сообщений, которые выполняются сетевым Узлом 1 для записи своего местоположения в записи SRV и записи NAPTR собственно DNS согласно Фиг. 3;

Фиг. 6 иллюстрирует схему операций и связанных потоков сообщений, которые выполняются сетевым Узлом N для записи своего местоположения в записи SRV и записи NAPTR собственно DNS согласно Фиг. 3;

Фиг. 7 иллюстрирует схему операций и связанных потоков сообщений, которые выполняются сетевым узлом N для опроса DNS согласно Фиг. 3, для идентификации любых существующих соединений с сетевым Узлом 0;

Фиг. 8 иллюстрирует схему операций и связанных потоков сообщений, которые выполняются сетевыми Узлами N и 0, для создания соединения между ними и для добавления соединения в качестве записи SRV в DNS согласно Фиг. 3;

Фиг. 9 иллюстрирует три сетевых узла согласно Фиг. 3 с новым соединением, которое создано между сетевыми Узлами N и 0;

Фиг. 10 иллюстрирует схему операций и связанных потоков сообщений, которые выполняются сетевым Узлом 1 для опроса DNS согласно Фиг. 9, для идентификации любых существующих соединений с Узлом N;

Фиг. 11 иллюстрирует схему операций и связанных потоков сообщений, которые выполняются сетевыми Узлами 1 и N для создания соединения между ними и для добавления соединения в качестве записи SRV в DNS согласно Фиг. 9;

Фиг. 12 иллюстрирует три сетевых узла согласно Фиг. 9 с новым соединением, которое создано между сетевыми Узлами 1 и N;

Фиг. 13 является структурной схемой операций и способов, которые могут выполняться каждым сетевым узлом для отслеживания и представления отчета DNS о значении Качества Услуги (QoS) на каждое созданное соединение с другим сетевым узлом;

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

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

Фиг. 16 иллюстрирует схему операций и связанных потоков сообщений, которые выполняются сетевыми Узлами 0 и 1 для установки нового сеанса с прямым соединением между ними в ответ на опрос DNS согласно Фиг. 12 и принятые значения QoS для соединений;

Фиг. 17 иллюстрирует три сетевых узла согласно Фиг. 12 с новым соединением, которое создано между сетевыми Узлами 0 и 1;

Фиг. 18 иллюстрирует схему операций и связанные потоки сообщений, которые выполняются сетевым Узлом 0 для принятия решения между использованием прямого соединения между сетевыми Узлами 0 и 1, или непрямого соединения между сетевыми Узлами 0 и 1 через сетевой Узел N, в ответ на опрос записей DNS согласно Фиг. 17; и

Фиг. 19 является блок-схемой сетевого узла.

ПОДРОБНОЕ ОПИСАНИЕ

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

Фиг. 1 иллюстрирует примерную систему 100, которая включает в себя систему 110 тарификации, которая контролирует расходы, которые связаны с пользованием сетевой услугой конечными пользователями и которая может функционировать в соответствии с некоторыми вариантами осуществления. Обращаясь к Фиг. 1, система 100 может включать в себя конечных пользователей с 102-1 по 102-N, соединенных с базовой сетью 120. Сеть 120 может включать в себя клиентов с 115-1 по 115-M, которые выступают в качестве промежуточных устройств для переадресации события 122 услуги, связанного с сетевой услугой, элементу 124 услуги, который предоставляет сетевую услугу конечным пользователям с 102-1 по 102-N. Каждый из клиентов с 115-1 по 115-M может включать в себя клиента кредитного контроля (например, клиент кредитного контроля протокола Diameter, как указано в IETF RFC 4006), который взаимодействует с системой 110 тарификации. Каждый из клиентов с 115-1 по 115-M может отслеживать пользование представляемой услугой в соответствии с инструкциями, которые обеспечены системой 110 тарификации. Элемент 124 услуги может включать в себя сетевой узел или устройство, которое предоставляет сетевую услугу конечным пользователям с 102-1 по 102-N. В некоторых вариантах осуществления, элемент 124 услуги и клиент (например, клиент 115-M) могут быть объединены в одном сетевом узле или устройстве, и элемент 124 услуги/клиент 115-M могут выступать в качестве клиента кредитного контроля. Примеры элемента 124 услуги могут включать в себя сервер сетевого доступа (NAS), прокси-сервер SIP, Обслуживающий Узел Поддержки Пакетной Радиосвязи Общего Назначения (GPRS) (SGSN), узел GPRS, или сервер приложений, такой как, например, сервер обмена сообщениями, сервер контента, и/или игровой сервер.

В качестве не ограничивающего примера, событие 122 услуги, предназначенное для одного или более конечных пользователей с 102-1 по 102-N, может приниматься клиентом 115-1. Клиент 115-1 может переадресовать событие услуги клиенту 115-M, который, в свою очередь, может переадресовать событие услуги элементу 124 услуги для предоставления связанной услуги одному или более конечным пользователям с 102-1 по 102-N. Вместе с переадресацией события услуги, каждый клиент с 112-1 по 112-M может отправлять запрос тарификации (например, запрос единиц услуги - не показан) системе 110 тарификации, запрашивая авторизацию/отказ в доставке события 122 услуги соответствующему одному из конечных пользователей с 102-1 по 102-N. В ответ на каждый запрос тарификации, система 110 тарификации может отправить сообщение авторизации, которое разрешает доставку услуги (например, доставку разрешенной квоты единиц услуги) соответствующему конечному пользователю, или сообщение отказа, которое отказывает в доставке услуги соответствующему конечному пользователю, исходя из исполнения механизмов кредитного контроля.

Каждый из конечных пользователей с 102-1 по 102-N может включать в себя сотовый радиотелефон, персональный цифровой помощник (PDA), терминал Персональных Систем Связи (PCS), портативный компьютер, настольный компьютер, карманный компьютер, или любой другой тип устройства или аппарата, который включает в себя приемопередатчик связи, который предоставляет устройству возможность осуществления связи с другими устройствами. Терминал PCS может объединять возможности сотового радиотелефона с возможностями обработки данных, факсимильной связи и связи по передаче данных. PDA может включать в себя радиотелефон, пейджер, устройство доступа к сети Интернет/интрасети, web-браузер, органайзер, календари, и/или приемник глобальной системы позиционирования (GPS). PCS или PDA могут включать в себя Пользовательский Агент (SIP UA) Протокола Инициации Сеанса (SIP), который может использоваться для сигнализации SIP в домене Подсистемы Передачи Мультимедиа (IMS) на основе Интернет Протокола (IP).

Сеть 120 может включать в себя одну или более сетей любого типа, включая локальную сеть (LAN); глобальную сеть (WAN); городскую сеть (MAN); телефонную сеть, такую как коммутируемую телефонную сеть общего пользования (PSTN) или Наземную Мобильную Сеть Общего Пользования (PLMN); спутниковую сеть; интрасеть, сеть Интернет; или сочетание этих и/или сетей других типов. PLMN могут дополнительно включать в себя подсеть с коммутацией пакетов, такую как, например, сеть Пакетной Радиосвязи Общего Назначения (GPRS), сеть Цифровой Пакетной Передачи Данных (CDPD), Мобильную сеть по Интернет Протоколу (IP), или сеть IMS.

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

Фиг. 2 иллюстрирует пример конфигурации системы 110 тарификации согласно Фиг. 1 в соответствии с некоторыми вариантами осуществления. Обращаясь к Фиг. 2, система 100 тарификации может включать в себя множество Узлов Управления Стоимостью (CCN) с 202-1 по 202-X, которые обеспечивают интерфейс для клиентов с 115-1 по 115-M, для приема и ответа на запросы тарификации и отслеживания пользования услугами, которые авторизованы для конечных пользователей с 102-1 по 102-N. Множество узлов с 204-1 по 204-Y Точек Данных об Услуге (SDP) хранят записи счетов пользователей, которые опрашиваются и обновляются CCN с 202-1 по 202-X (например, используя протокол Diameter), в ответ на запросы тарификации, принятые от различных клиентов 115 для конкретных конечных пользователей 102. CCN с 202-1 по 202-X могут опрашивать узлы с 206-1 по 206-Z Поиска Счетов (AF) (например, используя протокол Системы Доменных Имен (DNS)) для идентификации того, который из узлов с 204-1 по 204-Y SDP содержит (обладает) записи счетов пользователя применительно к конкретному конечному пользователю 102, который связан с запросом услуги от одного или более клиентов с 115-1 по 115-M. Доступ к записям счетов пользователя в узлах SDP с 204-1 по 204-Y может быть получен и они могут меняться в целях администрирования (например, для отражения увеличившегося/уменьшившегося кредита пользователя) через, например, эфирный узел с 208-1 по 208-XX.

Базовая сеть 120 может требовать, чтобы система тарификации отвечала на запрос тарификации от одного из клиентов 115 в пределах, например, 1 секунды. Реализация такой оперативности может быть особенно сложна, когда базовая сеть 120 включает в себя большое количество клиентов 115 и/или когда система 110 тарификации включает в себя большое число CCN 202 и/или SDP 204 и, более того, когда пути соединения связи между CCN 202 и SDP 204 устанавливаются и конфигурируются локально каждой CCN 202 и SDP 204 (например, используя протокол Diameter). По мере роста количества SDP 204, каждому CCN требуется иметь возможность размещения и создания новых путей к добавленной SDP 204.

Введение возможностей совместно используемого счета в систему 110 тарификации оплат дополнительно усложняет функционирование системы и увеличивает служебное сигнализирование, связанное с обновлением CCN 202 и SDP 204 по мере роста системы 110. Совместно используемые счета относятся к конечному пользователю (абоненту), который может использовать другой счет конечного пользователя (поставщика). Записи счетов пользователя для поставщика могут размещаться или могут не размещаться на одном и том же SDP 204, как и записи счетов пользователя для абонента. Следовательно, одному из SDP с 204-1 по 204-Y, который имеет запись счета пользователя для абонента, может потребоваться выступать в качестве посредника для получения записи совместно используемого счета для счета поставщика, который размещается в другом одном из SDP с 204-1 по 204-Y. Вследствие этого наличие совместно используемых счетов создает потребность в новых путях сигнализации сообщений между SDP, и может увеличить объем сигнализации сообщений и задержку ответа, который требуется для ответа на запрос кредита клиента, который относится к общим счетам.

Чтобы способствовать осуществлению связи между узлами SDP 204, CCN 202 и/или другими сетевыми узлами, система 110 тарификации включает в себя Систему 220 Доменных Имен (DNS), которая включает в себя центральную базу данных, которая образует хранилище информации, которая идентифицирует местоположения сетевых узлов и соединения, которые в настоящий момент существуют между сетевыми узлами. Например, DNS 220 может образовывать хранилище информации, которое идентифицирует местоположения и соединения SDP, которые в настоящий момент существуют между SDP с 204-1 по 204-Y. DNS 220 может включать в себя записи 222 Услуги (SRV) и записи 224 Указателя Полномочия Имени (NAPTR).

В качестве примера, при добавлении нового SDP в систему 110 тарификации оплат, новый SDP может добавить свое местоположение в качестве записи 222 SRV и записи 224 NAPTR в DNS 220. Когда первому одному из SDP с 204-1 по 204-Y требуется осуществить связь со вторым одним из SDP с 204-1 по 204-Y, то первый SDP может опросить DNS 220 в отношении записей 222 SRV, идентифицирующих любые существующие соединения со вторым SDP. Когда идентифицировано существующее соединение, то первый SDP может осуществить связь со вторым SDP, используя существующее соединение.

Например, запись счета пользователя, которая хранится в SDP 204-1, может содержать указатель на запись совместно используемого счета пользователя, которая хранится в SDP 204-Y. Когда SDP 204-1 принимает запрос тарификации применительно к этой записи счета пользователя, SDP 204-1 может опросить DNS 220, запрашивая записи 222 SRV, идентифицирующие любые существующие соединения между SDP 204-1 и 204-Y. SDP 204-1 может ответить на существующее соединение между SDP 204-1 и 204-Y, которое было идентифицировано DNS 220, посредством создания сеанса связи с SDP 204-Y, используя существующее соединение для запроса и приема записи совместно используемого счета пользователя от SDP 204-Y. Затем SDP 204-1 может использовать эту запись счета пользователя для формирования ответа (например, сообщения авторизации) клиенту 115, который сформировал запрос тарификации.

Каждый из SDP с 204-1 по 204-Y могут быть выполнены с возможностью формирования значения Качества Услуги, QoS, на каждое созданное соединение с другим SDP 204, которое указывает уровень QoS, который обеспечивается SDP 204 для связи, используя данное соединение, и передачи сформированного значения QoS собственно DNS 220. Как будет более подробно объяснено позже, значение QoS может храниться в поле веса и/или поле приоритета записи 222 SRV для связанного соединения.

Когда идентифицировано множество существующих соединений между первым и вторым SDP (например, прямое соединение и одно или более непрямых соединений через другие SDP), в ответ на опрос DNS 220 со стороны первого SDP, то первый SDP может использовать принятое значение QoS для каждого существующего соединения, чтобы принять решение создавать ли сеанс связи со вторым SDP, используя любое из существующих соединений. Например, первый SDP может выбрать существующее соединение из множества существующих соединений, которые идентифицированы в записях 222 SRV, и которое обладает наиболее приемлемым QoS (например, соединение, которое будет обеспечивать наивысший уровень QoS для сеанса).

Продолжая с приведенным выше примером, вторая запись счета пользователя в SDP 201-1 может содержать указатель на запись совместно используемого счета пользователя, которая хранится в SDP 204-2. Когда SDP 204-1 принимает запрос тарификации в отношении второй записи счета пользователя, то SDP 204-1 может опросить DNS 220, запрашивая записи 222 SRV, идентифицирующие любые существующие соединения между SDP 204-1 и 204-2. Когда записи 222 SRV идентифицируют, что существует прямое соединение между SDP 204-1 и SDP 204-2 и непрямое соединение между SDP 204-1 и SDP 204-2 через SDP 204-Y, то SDP 204-1 может сравнить значения QoS, принятые с записями 222 SRV для каждого из соединений, чтобы выбрать либо прямое соединение, либо непрямое соединение в зависимости, например, от того, какое из соединений обеспечит наивысшее QoS для сеанса. Затем SDP 204-1 может создать сеанс, используя выбранное соединение.

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

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

Фиг. 3 иллюстрирует три сетевых узла, сетевой Узел 0, сетевой Узел 1, и сетевой Узел N, которые выполнены с возможностью предоставления отчета о своих местоположениях и соединениях DNS 300, которая включает в себя централизованную базу данных. DNS 300 может быть выполнена как показано на Фиг. 2, чтобы включать в себя записи 222 SRV и записи 224 NAPTR. DNS 300 является внешней по отношению к сетевым Узлам 0, 1, N и может размещаться удалено от сетевых Узлов 0, 1, N с помощью одного или более широкополосных сетевых соединений, обеспечивающих связь между DNS 300 и каждым из сетевых Узлов 0, 1, N.

Фиг. 4 иллюстрирует схему операций и связанные потоки сообщений, которые выполняются сетевым Узлом 0 для записи своего местоположения в записи SRV и записи NAPTR собственно DNS 300 согласно Фиг. 3. Обращаясь к Фиг. 4, сетевой Узел 0 имеет примерный адрес «Область=0.ПРИМЕР.COM, Имяхоста=Node0.example.com, IP=192.0.2.1» (этап 400). В ответ на инициализацию (например, включение) или другое событие, запускается процесс (этап 402), который предписывает сетевому Узлу 0 добавить свой адрес в качестве записи в DNS 300. Сетевой Узел 0 может сформировать (этап 404) значение QoS, которое указывает уровень качества услуги, который он может обеспечить для связи к/от другого сетевого узла, такое как скорость(и) передачи данных, которую он может обеспечить через свои порты соединения, его настоящую загрузку, настоящий статус очереди (например, оставшийся размер буфера очереди), типичную задержку данных между вводом и выводом данных, и т.д. Дополнительно, или в качестве альтернативы, сетевой Узел 0 может установить свое значение QoS с тем, чтобы стимулировать другие узлы либо на то, чтобы избегать соединения с сетевым Узлом 0, либо на запрос соединения с сетевым Узлом 0.

Сетевой Узел 0 отправляет сообщение записи SRV (этап 406), которое может включать в себя значение QoS, к DNS 300, которая отвечает посредством добавления (этап 408) записи SRV и отправки ответа подтверждения сетевому Узлу 0. Сетевой Узел 0 также отправляет сообщение записи NAPTR (этап 410), которое может включать в себя значение QoS, к DNS 300, которая отвечает посредством добавления (этап 412) записи NAPTR и отправки ответа подтверждения сетевому Узлу 0.

Сетевой Узел 0 может записать значение QoS в поле веса и/или поле приоритета записи SRV. Затем другие сетевые узлы (например, Узел 1 и Узел N) могут получить доступ к записи SRV через DNS 300 для получения значения QoS, которое записано Сетевым Узлом 0. Например, как показано на Фиг. 4, примерная запись SRV перечисляет «_diameter-sctp.Node0.example.com 86400 IN SRV 0 0 1234 Node0.example.com», где сегмент «0 0» соответствует полю приоритета и полю веса, соответственно, причем оба эти поля были установлены в значение 0. Низкое значение в поле приоритета и/или поле веса может указывать на высокое QoS, в то время как более высокое значение, может указывать на низкое QoS, или наоборот.

Фиг. 5 иллюстрирует схему операций и связанных потоков сообщений, которые выполняются сетевым Узлом 1 для записи своего местоположения в записи SRV и записи NAPTR собственно DNS 300 согласно Фиг. 3. Сетевой Узел 1 может выполнять точно такие же операции или аналогичные тем, что описаны выше в отношении Фиг. 4 для сетевого Узла 0, для добавления своего местоположения в записи DNS 300. Обращаясь к Фиг. 5, сетевой Узел 1 имеет примерный адрес «Область=1.EXAMPLE.COM, Имяхоста=node1.example.com, IP=192.0.2.1» (этап 500). В ответ на инициализацию или другое событие, запускается процесс (этап 502), который предписывает сетевому Узлу 1 добавить свой адрес в качестве записи в DNS 300. Сетевой Узел 1 может формировать (этап 504) значение QoS, которое указывает уровень качества услуги, который он может обеспечить для связи к/от другого сетевого узла, такое как скорость(и) передачи данных, которую он может обеспечить через свои порты соединения, его текущую загрузку, текущий статус очереди (например, оставшийся размер буфера очереди), типичную задержку данных между вводом и выводом данных, и т.д. Дополнительно, или в качестве альтернативы, сетевой Узел 1 может установить свое значение QoS с тем, чтобы стимулировать другие узлы либо на то, чтобы избегать соединения с сетевым Узлом 1, либо на запрос соединения с сетевым Узлом 1.

Сетевой Узел 1 отправляет сообщение записи SRV (этап 506), которое может включать в себя значение QoS, к DNS 300, которая отвечает посредством добавления (этап 508) записи SRV и отправки ответа подтверждения сетевому Узлу 1. Сетевой Узел 1 также отправляет сообщение записи NAPTR (этап 510), которое может включать в себя значение QoS, к DNS 300, которая отвечает посредством добавления (этап 512) записи NAPTR и отправки ответа подтверждения сетевому Узлу 1.

Фиг. 6 иллюстрирует схему операций и связанные потоки сообщений, которые выполняются сетевым узлом N для записи своего местоположения в записи SRV и записи NAPTR собственно DNS 300 согласно Фиг. 3. Сетевой Узел N может выполнять точно такие же операции или аналогичные тем, что описаны выше в отношении Фиг. 4 для сетевого Узла 0, для добавления своего местоположения в записи DNS 300. Обращаясь к Фиг. 6, сетевой Узел N имеет примерный адрес «Область=N.EXAMPLE.COM, Имяхоста=nodeN.example.com, IP=192.0.2.N» (этап 600). В ответ на инициализацию или другое событие, запускается процесс (этап 602), который предписывает сетевому Узлу N добавить свой адрес в качестве записи в DNS 300. Сетевой Узел N может формировать (этап 604) значение QoS, используя точно такие же или аналогичные операции как те, что описаны выше для этапа 404 на Фиг. 4 и/или этапа 504 на Фиг. 5. Сетевой Узел N отправляет сообщение записи SRV (этап 606), которое может включать в себя значение QoS, к DNS 300, которая отвечает посредством добавления (этап 608) записи SRV и отправки ответа подтверждения сетевому Узлу N. Сетевой Узел N также отправляет сообщение записи NAPTR (этап 610), которое может включать в себя значение QoS, к DNS 300, которая отвечает посредством добавления (этап 612) записи NAPTR и отправки ответа подтверждения сетевому Узлу N.

Фиг. 7 иллюстрирует схему операций и связанные потоки сообщений, которые могут выполняться сетевым Узлом N в ответ на необходимость установки сеанса для передачи трафика данных сетевому Узлу 0. Обращаясь к Фиг. 7, сетевой Узел N отвечает (этап 700) на событие, которое запускает инициирование связи с сетевым Узлом 0 («Область 0.EXAMPLE.COM») посредством передачи (этап 702) сообщения опроса DNS 300 для поиска записи NAPTR применительно к сетевому Узлу 0. DNS 300 выполняет поиск и передает (этап 704) соответствующую запись NAPTR («diameter- sctp.Node0.example.com») сетевому Узлу N.

Затем сетевой Узел N передает (этап 706) другое сообщение опроса DNS 300 для поиска записи SRV применительно к сетевому Узлу 0. DNS 300 выполняет поиск и передает (этап 708) соответствующую запись SRV («_diameter- _sctp.Node0.example.com 86400 IN SRV 0 0 1234 Node0.example.com») сетевому Узлу N. Затем сетевой Узел N определяет (этап 710) из принятой записи SRV, что отсутствуют существующие соединения от сетевого Узла N к сетевому Узлу 0. Сетевой Узел N отвечает посредством инициирования процесса установки соединения для сеанса, как будет объяснено ниже в отношении Фиг. 8.

Фиг. 8 иллюстрирует схему операций и связанные потоки сообщений, которые выполняются сетевыми Узлами N и 0, для создания соединения между ними, для добавления соединения в качестве записи SRV в DNS согласно Фиг. 3, и для использования соединения для сеанса связи. Обращаясь к Фиг. 8, сетевой Узел N инициирует установку (этап 800) соединения с сетевым Узлом 0, для использования в сеансе связи. Сетевой Узел N предает (этап 802) сообщение установки сеанса сетевому Узлу 0, который отвечает сетевому Узлу N с помощью сообщения ответа подтверждения сеанса (этап 804), которое указывает на то, что сеанс и связанное соединение установлены. Фиг. 9 иллюстрирует сетевые Узлы 0, 1, N согласно Фиг. 3, с новым соединением, которое создано между сетевыми Узлами N и 0.

Сетевые Узлы N и 0 могут отслеживать (этапы 806 и 808) сообщения установки сеанса между ними для формирования значений QoS, которые указывают уровень QoS, который обеспечивается соответствующими сетевыми узлами для связи, используя данное соединение. Сетевые Узлы N и 0 могут в качестве альтернативы, или в дополнение, отслеживать прочие сообщения, которые передаются между Узлами N и 0, такие как тестовые сообщения, для определения уровня QoS, обеспечиваемого соединением, и могут продолжать отслеживать соединение для формирования обновленных значений QoS для соединения. Значения QoS могут в качестве альтернативы или в дополнение определяться, используя точно такие же или аналогичные операции как те, что описаны выше для этапа 404 на Фиг. 4 и/или этапа 504 на Фиг. 5.

Сетевой узел 0 может добавить информацию, которая идентифицирует соединение от него к сетевому Узлу N в качестве записи SRV в DNS 300 посредством передачи информации (этап 810), которая может включать в себя сформированное значение QoS (этап 806) к DNS 300. DNS 300 отвечает посредством добавления (этап 812) записи SRV, которая идентифицирует соединение. Аналогичным образом, Сетевой Узел N может добавить информацию, которая идентифицирует соединение от него к сетевому Узлу 0 в качестве записи SRV в DNS 300, посредством передачи информации (этап 814), которая может включать в себя сформированное значение QoS (этап 808) к DNS 300. DNS 300 отвечает посредством добавления (этап 816) записи SRV, которая идентифицирует соединение. Значение QoS может храниться в поле веса SRV и/или поле приоритета SRV. На Фиг. 8, обе записи SRV для Узла N и Узла 0 перечисляют «0 2», что соответствует значению приоритета равному «0» и значению веса равному «2». Значение QoS может быть определено таким образом, что более низкое значение соответствует более высокому качеству услуги или наоборот. Несмотря на то, что Узлы N и 0 были показаны на Фиг. 8 как добавляющие информацию в SRV (этапы 812 и 816) для их собственных соответствующих имен услуг, они, вместо этого, могут добавлять информацию для соответствующих имен услуг друг друга (т.е., стрелки между этапами 812 и 816 и соответственно идентифицирующими записями SRV могут быть поменяны местами).

Затем сетевые Узлы N и 0 могут использовать созданное соединение для передачи данных между ними во время сеанса. Так как соединение между сетевыми Узлами N и 0 определено в записях SRV собственно DNS, то прочие сетевые узлы могут обнаружить показанное соединение, и могут выбрать использование данного существующего соединения для другого сеанса связи между этими другими узлами. Другие сетевые узлы могут принять решение использовать ли существующее соединение в ответ на значение QoS, которое записано в записях SRV. Например, когда сетевой узел имеет множество существующих соединений, которые могут альтернативно использоваться для осуществления связи с другим сетевым узлом, то сетевой узел, который устанавливает сеанс связи, может выбрать одно из существующих соединений, которое обеспечит наивысшее (наилучшее) QoS для сеанса.

Фиг. 10 иллюстрирует схему операций и связанные потоки сообщений, которые выполняются сетевым Узлом 1 в ответ на необходимость установки сеанса для передачи данных трафика сетевому Узлу N. Обращаясь к Фиг. 10, сетевой Узел 1 отвечает (этап 1000) на инициирующее событие, которое запускает инициирование связи между сетевым Узлом N («Область N.EXAMPLE.COM») посредством передачи (этапа 1002) сообщения опроса DNS 300, для поиска записи NAPTR применительно к сетевому Узлу N. DNS 300 выполняет поиск и передает (этап 1004) соответствующую запись NAPTR («diameter- sctp.nodeN.example.com») сетевому Узлу 1.

Затем сетевой Узел 1 передает (этап 1006) другое сообщение опроса DNS 300 для поиска записи SRV применительно к Узлу N. DNS 300 выполняет поиск и передает (этап 1008) соответствующие записи SRV («_diameter- _sctp.nodeN.example.com 86400 IN SRV 0 0 1234 nodeN.example.com» и «_diameter- _sctp.nodeN.example.com 86400 IN SRV 0 2 1234 Node0.example.com») сетевому Узлу 1. Затем сетевой Узел 1 определяет (этап 1010) из принятой записи SRV, что отсутствуют существующие соединения от сетевого Узла 1 к сетевому Узлу N. Сетевой Узел 1 отвечает посредством инициирования процесса установки соединения для сеанса, как будет объяснено ниже в отношении Фиг. 11.

Фиг. 11 иллюстрирует схему операций и связанные потоки сообщений, которые выполняются сетевыми Узлами 1 и N для создания соединения между ними, для добавления соединения в качестве записи SRV в DNS согласно Фиг. 9, и для использования соединения для сеанса связи. Обращаясь к Фиг. 11, сетевой Узел 1 инициирует установку (этап 1100) соединения с сетевым Узлом N для использования в сеансе связи. Сетевой Узел 1 передает (этап 1102) сообщение установки сеанса сетевому Узлу N, который отвечает сетевому Узлу 1 с помощью сообщения ответа подтверждения сеанса (этап 1104), которое указывает на то, что сеанс и связанное соединения установлены. Фиг. 12 иллюстрирует сетевые Узлы 0, 1, N согласно Фиг. 9 с новым соединением, которое создано между сетевыми Узлами 1 и N.

Сетевые Узлы 1 и N могут отслеживать (этапы 1106 и 1108) сообщения установки сеанса между ними для формирования значений QoS, которые указывают уровень QoS, который обеспечивается соответствующими сетевыми узлами для связи, используя данное соединение. Сетевые Узлы 1 и N могут в качестве альтернативы или в дополнение отслеживать прочие сообщения, которые передаются между Узлами 1 и N, такие как тестовые сообщения, для определения уровня QoS, которые обеспечивается соединением, и могут продолжать отслеживать соединение для формирования обновленных значений QoS для соединения. Значения QoS могут в качестве альтернативы или в дополнение определяться (этапы 1106 и 1108), используя точно такие же или аналогичные операции как те, что описаны выше для этапа 404 на Фиг. 4 и/или этапа 504 на Фиг. 5.

Сетевой узел N может добавить информацию, которая идентифицирует соединение от него к сетевому Узлу 1 в качестве записи SRV в DNS 300 посредством передачи информации (этап 1110), которая может включать в себя сформированное значение QoS (этап 1106) к DNS 300. DNS 300 отвечает посредством добавления (этап 111) записи SRV, которая идентифицирует соединение. Аналогично, сетевой Узел 1 может добавить информацию, которая идентифицирует соединение от него к сетевому Узлу N в качестве записи SRV в DNS 300 посредством передачи информации (этап 1114), которая может включать в себя сформированное значение QoS (этап 1108) к DNS 300. DNS 300 отвечает посредством добавления (этапа 1116) записи SRV, которая идентифицирует соединение. В примере на Фиг. 11, DNS 300 добавила запись SRV для сетевого Узла 1, со значением веса равным «4» и добавила запись SRV для сетевого Узла N со значением веса равным «5», которые могут соответствовать тому, что сетевой Узел 1 формирует (этап 1108) значение QoS равное 4, а сетевой Узел N формирует (этап 1106) значение