×
10.06.2016
216.015.478e

МОНИТОРИНГ СЕТИ И ИДЕНТИФИКАЦИЯ АБОНЕНТА В РЕАЛЬНОМ МАСШТАБЕ ВРЕМЕНИ С ПОМОЩЬЮ УСТРОЙСТВА, СРАБАТЫВАЮЩЕГО ПО ТРЕБОВАНИЮ

Вид РИД

Изобретение

Юридическая информация Свернуть Развернуть
№ охранного документа
0002585971
Дата охранного документа
10.06.2016
Краткое описание РИД Свернуть Развернуть
Аннотация: Изобретение относится к области мониторинга трафика в сети поставщика услуг. Технический результат - эффективный мониторинг сети для сбора данных о сетевых потоках по мере их прохождения в сети. Система получает уведомление о начале передачи потока сетевых данных, отвечая на запрос абонентского устройства на получение контента с сервера источника. Затем система определяет, целесообразно ли осуществлять мониторинг потока данных, поступающего с сервера источника на абонентское устройство. Если да, то система собирает статистику о потоке данных и сохраняет эту статистику в записях о потоках в базе данных. Кроме того, система соотносит запись о потоке с конкретным абонентом сети поставщика услуг, анализируя статистику по потоку данных, и оценивает пропускную способность в отношении этого потока данных, обеспеченную сетью поставщика услуг, исходя из результатов анализа статистики по указанному потоку данных. 3 н. и 18 з.п. ф-лы, 8 ил.
Реферат Свернуть Развернуть

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

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

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

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

Имеющиеся сетевые элементы могут дать операторам представление о текущем состоянии трафика в их сетях, но они не могут определить степень их «качественности», т.е. выявить, насколько гибкой является сеть, или сколько еще данных она в состоянии обработать. Этот показатель важен при доставке мультимедийного контента, поскольку хорошее восприятие пользователя обычно зависит от способности сети надежно и бесперебойно доставлять данные. Минимальная скорость обработки данных требуется для предотвращения срыва потока данных и их повторной буферизации во время потоковой передачи мультимедийного контента; при этом для улучшения качества восприятия большое значение имеет обеспечение достаточной полосы пропускания. Обычно поставщики мультимедийного контента обладают достаточными средствами его доставки, уровень которых намного превосходит уровень возможностей беспроводной инфраструктуры. Таким образом, на поставщиков услуг беспроводной связи ложится задача по обеспечению оптимизации сетевых данных для снижения интенсивности трафика и максимального повышения восприятия сети каждым пользователем. В настоящее время, однако, поставщики услуг мобильной связи часто вынуждены пользоваться довольно грубыми инструментами с низкой просматриваемостью трафика сети, за счет чего некоторые сетевые сегменты часто оказываются перегруженными, а оптимизируются потоки, которые не требуют никакой оптимизации.

Обычно поставщики услуг мобильной связи используют встраиваемые сетевые устройства, которые непрерывно контролируют каждый бит трафика абонентов для оценки пропускной способности сети. Это серьезно нагружает систему, поскольку она вынуждена ежесекундно обрабатывать от сотен тысяч до миллионов сетевых запросов через единственную точку доступа к сети. Более того, поставщики сетевых услуг часто вынуждены использовать эти методы мониторинга на микроуровне (например, в расчете на установку оборудования RAN), реагируя на состояние сети, обусловленное возросшими издержками. Кроме того, значительная часть Интернет-трафика состоит из мелких объектных запросов, которые могут затруднять мониторинг сети на любом уровне из-за короткого срока своего существования и возможности создания периодической пиковой нагрузки.

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

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

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

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

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

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

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

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

На фиг. 7 проиллюстрирован один из вариантов реализации элементов кэш-памяти потоков, управляемой сетевым контроллером.

Подробное описание изобретения

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

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

Обзор

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

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

В другом варианте осуществления настоящего изобретения отслеживаются и замеряются крупные объекты, такие как видеофайлы и видеоданные, проходящие по сети. Вместо простого измерения полосы пропускания, связанной с доставкой крупных объектов, оценивается потребная в будущем пропускная способность сети, исходя из результатов указанных измерений. Крупные объекты, в свою очередь, могут быть выборочно оптимизированы для поддержания пропускной способности сети. Для объектов в виде видео потоковая скорость передачи данных дает параметр, который можно сравнить с емкостью сети с тем, чтобы определить, способна ли сеть поддерживать требуемый уровень своей пропускной способности. Часто целесообразно ограничивать скорость передачи данных с тем, чтобы она не превышала известный верхний предел. Если поток данных может быть доставлен со скоростью, лежащий в диапазоне между минимальным уровнем, потребным для предотвращения срыва потока видео, и верхним пределом ограничения скорости, то можно сказать, что сетевой сегмент, через который проходит поток, способен поддерживать требуемую скорость передачи потока данных в битах. Доставка крупных объектов, таких как видео и изображения, занимает определенное время, что дает возможность измерить время ожидания сервера источника и обнаружить перегрузку сети точнее, чем при доставке мелких объектов. Например, приемлемые пороговые значения, отделяющие крупные объекты от мелких, могут быть заданы в диапазоне от 512 Кб до 1 Мб, а также от 50 Кб и до значений, характеризующих средние объекты. Возможны также и иные варианты.

В некоторых вариантах осуществления настоящего изобретения пропускная способность, достигнутая одним потоком данных, может оказаться достаточной для определения пропускной способности сетевого сегмента/сегментов, через которые проходит поток. Следовательно, за счет относительно небольшого развертывания сетевого контроллера/контроллеров можно точно определить основные точки перегрузки сети. В частности, для выявления перегрузок в сети нет необходимости в отслеживании каждого потока, проходящего через сетевой сегмент. Поскольку в настоящее время видео занимает около 50% сетевого трафика, но лишь 5% от всех потоков данных, карту статистически значимой части сети может составить лишь относительно небольшое количество выборок потоков крупных объектов данных.

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

Мониторинг трафика в реальном масштабе времени

На фиг. 1 представлена бок схема высокого уровня иллюстративной физической среды (100) передачи данных для выборочного мониторинга сети и идентификации абонента по требованию в реальном масштабе времени. Физическая среда (100) включает в себя абонентские устройства (110), сервер (160) источника, управляющее устройство (130), сетевой контроллер (140), оптимизатор (150) видео и сеть (120). Сеть (120) представляет собой коммуникационную сеть, которая осуществляет обмен данными между абонентскими устройствами (110), управляющим устройством (130) и сервером (160) источника и/или оптимизатором (150) видео. В одном из вариантов осуществления настоящего изобретения сеть (120) включает в себя беспроводную сеть и Интернет.

Стратегия поддержания эффективности сети, в соответствии с которой капиталовложения не могут превышать доходы, должна быть уравновешена потребностями потребителей для улучшения восприятия сети пользователями, которое все больше зависит от возможности увеличения объема передаваемых данных. В настоящее время операторы мобильной связи используют множество инструментов для управления пропускной способностью, включая лимитирование трафика данных, разгрузку за счет перенаправления трафика данных в Wi-Fi-сети и рациональную оптимизацию. Физическая среда (100) демонстрирует такое решение, которое обеспечивает унифицированную базу с интеллектуальным управлением сеансами, управлением интегральными услугами и динамической адаптивностью любых предоставляемых услуг. Сетевой контроллер (140) и оптимизатор (150) видео вместе предоставляют решение по оптимизации мультимедиа на уровне мировых стандартов, которое дает оперативное преимущество в плане пропускной способности операторам беспроводной связи, а также поставщикам услуг Интернета, с большей экономией затрат в режиме пиковой нагрузки в сравнении с альтернативными решениями.

В одном из вариантов осуществления настоящего изобретения абонентские устройства (110) представляют собой вычислительные устройства, обладающие сетевыми возможностями. Например, в качестве абонентских устройств (110) часто выступают беспроводные мобильные устройства с веб-браузером и возможностями отображения мультимедийных данных. К абонентским устройствам (110) в виде мобильных устройств могут относиться лэптопы, нетбуки, планшетные компьютеры, смартфоны или карманные персональные компьютеры (КПК). Хотя на фиг. 1 показано только два абонентских устройства (110A) и (110B), физическая среда (100) может содержать тысячи и даже миллионы таких устройств. Веб-браузеры могут представлять собой программные приложения, выполняемые мобильными устройствами (110) для извлечения Интернет-контента из сервера (160) источника и отображения Интернет-контента на дисплее, который соединен с мобильным устройством. Интернет-контент, к которому имеет доступ абонентские устройства (110) включает в себя текст, изображения, аудио- и видео-контент. Мультимедийный контент может воспроизводиться браузерами, например, HTML5-совместимыми браузерами, встроенными или автономными проигрывателями мультимедиа. Браузеры могут также активизировать проигрыватели мультимедиа или дополнительные модули (плагины), имеющиеся в абонентских устройствах (110), и передавать изображения, аудио- и/или видеоданные на проигрыватель мультимедиа или плагин для воспроизведения.

Управляющее устройство (130) может представлять собой выравниватель нагрузки или маршрутизатор, расположенный между абонентским устройством (110) и сетью (120). Управляющее устройство (130) обеспечивает абонентскому устройству (110) доступ в сеть; и, таким образом, представляет собой шлюз, через который поток трафика из абонентского устройства поступает в сеть и наоборот. В одном из вариантов осуществления настоящего изобретения управляющее устройство (130) классифицирует направленный через него трафик с целью идентификации потоков данных, представляющих интерес, для их дальнейшего анализа сетевым контроллером (140). В альтернативном варианте сетевой контроллер (140) сопрягается с управляющим устройством (130) для координации мониторинга и классификации сетевого трафика, например, идентификации крупных и мелких объектов данных в потоках HTTP-трафика. В этом случае управляющее устройство (130) получает команды от сетевого контроллера (140) по требуемым критериям для распределения потоков, представляющих интерес, по категориям для их последующего анализа.

Однако управляющее устройство (130), находящееся между сетью сотовой связи и проводным Интернетом, часто не обладает какой-либо информацией о стороне беспроводных/сотовых абонентских устройств (110). Например, часто отсутствует информация об идентификаторах вышек, связанных с мобильными устройствами (110). Данные, связанные с вышками, передаются только тогда, когда мобильные устройства (110) подключаются к сети в первый раз. Кроме того, абонентские устройства (110) обычно не сообщают какие-либо идентификационные сведения о себе, за исключением IP-адреса. Следовательно, мониторинг сетевого трафика и выявление перегрузки осуществляется автоматически и управляется детектором (140) таким образом, что сеть оптимизируется под конечного пользователя без какого-либо участия пользователя мобильного устройства.

В отличие от стандартных встроенных устройств мониторинга пропускной способности TCP, которые отслеживают по отдельности каждый переданный и полученный пакет данных, сетевой контроллер (140) представляет собой «внеполосный» компьютерный сервер, сопряженный с управляющим устройством (130) для выборочного контроля потоков данных, представляющих интерес для пользователя. Сетевой контроллер (140) может также идентифицировать пользовательские потоки (например, среди потоков, представляющих интерес для пользователя) для их последующей оптимизации. В одном из вариантов осуществления настоящего изобретения сетевой контроллер (140) может быть реализован в управляющем устройстве (130) для мониторинга трафика. В других вариантах осуществления настоящего изобретения сетевой контроллер (140) соединен и сообщается с управляющим устройством (130) для мониторинга и оптимизации трафика. После запроса, выданного управляющим устройством (130), сетевой контроллер (140) определяет, следует ли данный сетевой поток оставлять без внимания, отслеживать дальше или оптимизировать. Решение об оптимизации потока часто принимается в начале потока, поскольку практически невозможно переключиться на оптимизированный контент в середине потока после начала доставки неоптимизированного контента. Однако сетевой контроллер (140) может определить, что имеющиеся потоки, связанные с конкретным абонентом или иным объектом, нуждаются в оптимизации. В свою очередь, могут быть оптимизированы новые потоки (например, полученные после запросов на поиск в аудиовизуальной среде, запросов на новые медиа, возобновления после паузы и т.п.), которые были определены как связанные с объектом. Для принятия решения о мониторинге или оптимизации сетевой контроллер (140) использует данные о состоянии сети, а также статистические данные о трафике за прошлые периоды. Когда речь идет об оптимизации данных, важнейшее значение имеют сведения о текущем состоянии сети, например, о перегрузке.

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

Оптимизатор (150) видео представляет собой компьютерный сервер, обеспечивающий оптимизацию видеоданных и изображений, а также доставку оптимизированного видео-контента и содержимого изображений на абонентские устройства (110) через сеть (120). Оптимизация видео и изображений представляет собой услугу по запросу, предоставляемую за счет перекодировки видео-контента и содержимого изображений. Например, когда абонентское устройство пытается снять видео с сервера (160) источника, сетевой контроллер (140) может решить, что поток данных соответствует определенным критериям для оптимизации контента. После этого сетевой контроллер (140) перенаправляет абонентские устройства (110) на оптимизатор (150) видео для съема оптимизированного контента. По запросу на перенаправление оптимизатор (150) видео получает с абонентских устройств (110) или с сетевого контроллера (140) информацию о видео-контенте или содержимом изображений, подлежащем оптимизации, и снимает видео-контент или содержимое изображений с соответствующего сервера (160) источника для оптимизации и последующей доставки на абонентские устройства (110).

В раскрытых вариантах осуществления настоящего изобретения упор сделан на оптимизации видео, поскольку видео имеет намного большее значение, чем любой другой вид трафика, когда дело касается перегрузок сети. Видеотрафик составляет около половины всего сетевого трафика, и из года в год его доля в процентном выражении только возрастает. Следовательно, оптимизация видеотрафика может существенно уменьшить перегрузку сети. Кроме того, потоки видеоданных или видеопотоки характеризуются долговечностью, обладают большими размерами пакетов и требуют высокой скорости передачи в битах; при этом мониторинг потоков видеоданных является эффективным способом выявления перегрузки в сети. Более того, поскольку потоки видеоданных требуют устойчивой и постоянной полосы пропускания, именно на них в первую очередь сказываются перегрузки и уменьшение пропускной способности сети. И наоборот, незначительные перегрузки сети с кратковременными периодами повышенной нагрузки обычно не оказывают негативного влияния на текстовое содержание веб-страниц и изображения. Главное отличие оптимизации видео от оптимизации прочего веб-контента заключается в следующем: видеоданные характеризуются большой длиной, и стратегические решения по оптимизации, принимаемые в начале видео, оказывают существенное влияние на способность обеспечивать его устойчивое восприятие по всей продолжительности.

Оптимизатор (150) видео, равно как и сервер (160) источника, обычно состоит из одного или нескольких компьютеров. Хотя в физической среде (100), проиллюстрированной на фиг. 1, представлено только по одному серверу в качестве оптимизатора (150) видео и сервера (160) источника, в разных вариантах осуществления настоящего изобретения может быть предусмотрено множество веб-серверов и видео-серверов, управляемых одним или несколькими объектами. В других вариантах реализации заявленного изобретения один сервер может выполнять разные функции, например, осуществлять доставку веб-контента в качестве веб-сервера и обслуживать оптимизированный видео-контент.

Архитектура вычислительной машины

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

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

Иллюстративная компьютерная система (200) включает в себя один или несколько процессоров (202) (например, центральный процессор (ЦП), графический процессор (ГП), цифровой сигнальный процессор (ЦСП), одну или несколько заказных интегральных микросхем (ASIC), одну или несколько радиочастотных интегральных микросхем (RFIC) или комбинацию указанных устройств); ОЗУ (204); и статическое ЗУ (206); при этом указанные устройства выполнены с возможностью сообщаться друг с другом через шину (208). Компьютерная система (200) может также включать в себя графический дисплей (210) (например, плазменную панель (ПП), ЖК-дисплей (LCD), проектор или электронно-лучевую трубку (ЭЛТ)). Компьютерная система (200) может также включать в себя буквенно-цифровое устройство (212) ввода данных (например, клавиатуру), устройство (214) управления курсором (например, мышь, трекбол, джойстик, датчик движения или иной указатель), блок (216) памяти и устройство (220) сопряжения с сетью; при этом указанные устройства также выполнены с возможностью сообщаться друг с другом через шину (208).

Блок (216) памяти содержит машиночитаемый носитель (222), на котором хранятся команды (224) (например, программируемые), обуславливающие реализацию одного или нескольких способов или функций, описанных в настоящем документе. Команды (224) (например, программируемые) могут также содержаться - полностью или, по меньшей мере, частично - в ОЗУ (204) или в процессоре (202) (например, в быстродействующей буферной памяти процессора) во время их исполнения компьютерной системой (200); при этом ОЗУ (204) и процессор (202) также образуют машиночитаемый носитель. Команды (224) (например, программируемые) могут передаваться или приниматься по сети (110) через устройство (220) сопряжения с сетью.

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

Системные компоненты сетевого контроллера

Вернемся к фиг. 1, на которой представлен сетевой контроллер (140), позволяющий операторам сети применять принципы точечной оптимизации для достижения высокого качества восприятия (QoE), исходя из перегрузок на вышках сотовой связи, типов используемых устройств, профилей абонентов и тарифных планов с минимальными издержками на аппаратно-программные средства. Архитектура сетевого контроллера (140) обеспечивает абсолютное соответствие нормам сетевого нейтралитета по «надлежащему управлению сетью» и лучшее соответствие закону об авторском праве (DMCA) в сравнении с решениями, основанными на долговременном кэшировании. Обладая способностью отслеживать сетевой трафик на поабонентской, попоточной или пофайловой (для видео) основе, сетевой контроллер (140) также выборочно отслеживает и оптимизирует только то подмножество трафика, которое в наибольшей степени обеспечивает отдачу от оптимизации, в результате чего достигается, как масштабируемость, так и эффективность оптимизации по конкурентоспособным ценам. В основе сетевого контроллера (140) лежат механизмы выявления и уменьшения перегрузок, позволяющих максимально эффективно и точечно расходовать ресурсы на оптимизацию.

Теперь обратимся к фиг. 3, на которой проиллюстрирован один из вариантов реализации архитектуры сетевого контроллера (140), обеспечивающего выборочный мониторинг сети и идентификацию абонентов в реальном масштабе времени. Сетевой контроллер (140) включает в себя анализатор (312) потоков, подсистему (314) обработки политик, интерфейс (316) сопряжения с управляющим устройством, систему (318) переадресации оптимизатора видео, кэш-память (322) потоков и журнал (324) абонентов. В других вариантах осуществления настоящего изобретения сетевой контроллер (140) может содержать дополнительные компоненты, меньшее количество компонентов или иные компоненты для различных сфер применения. Стандартные компоненты, такие как сетевые интерфейсы, функции обеспечения защиты, отказоустойчивые серверы, пульты управления сетевыми и управленческими операциями и прочие устройства подобного рода не показаны, чтобы они не мешали обзору деталей архитектуры системы.

Анализатор (312) потоков отслеживает крупные потоки данных в сети, анализирует собранные по потокам статистические данные для оценки пропускной способности сети и, соответственно, выбирает потоки, которые подлежат оптимизации. Для точной оценки состояния сети анализатору (312) потоков нет необходимости «видеть» все потоки. Анализатор (312) потоков обрабатывает статистические данные о трафике, хранящиеся в кэш-памяти (322) потоков, и информацию о пользователях, содержащуюся в журнале (324) абонентов, например, путем соотнесения сетевых потоков, идентифицированных по IP-адресу источника, с абонентом или пользователем сети мобильной связи, который идентифицирован по своему ID-номеру или ID устройства. Пользовательские потоки данных также соотносятся с уровнем перегрузки в текущей подсети (например, в узле сотовой связи, к которому привязаны абонентские устройства) с тем, чтобы решение об оптимизации можно было принять в начале передачи данных.

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

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

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

Кроме того, статистика по потокам за более продолжительный период помогает анализатору (312) потоков выявить повторяющиеся модели и тепловые карты определенных участков сети и спрогнозировать их перегрузку в будущем. В этом случае статистические данные по потокам, хранящиеся в кэш-памяти (322), могут отображаться по категориям трафика для последующего анализа; например, долговременные средние значения пропускной способности для потоков видеоданных помогают определить целесообразность оптимизации. Более того, оцененная пропускная способность на поабонентской основе (или по каждой соте согласно ID, по каждой вышке или по каждому маршрутизатору) в динамике по времени может служить контрольным показателем, рассчитанным анализатором (312) потоков с целью определения краткосрочной потребности в оптимизации. Например, анализатор (312) потоков может принять решение об оптимизации потоков, соотнесенных с конкретной сотой по ID (или потоков для идентифицированных высокоскоростных пользователей по ID соты), по факту достижения порогового количества высокоскоростных пользователей, подключенных к той же вышке сотовой связи, которая соответствует ID соты. Причина, по которой анализатор (312) потоков выборочно отслеживает крупные потоки, заключается в том, что статистические данные по протоколу TCP в отношении мелких объектов, которые составляют абсолютное большинство веб-потоков, могут быть заведомо ложными и приводить к серьезным ошибкам при оценке пропускной способности.

Интерфейс (316) сопряжения с управляющим устройством взаимодействует с внешним маршрутизатором, таким как управляющее устройство (130), для перенаправления части сетевого трафика (например, сетевых потоков крупных объектов). Маршрутизаторы, используемые в настоящее время в большинстве сетей операторов связи, рассчитаны на обработку больших объемов сетевого трафика. Однако они не идеальны в управлении для мониторинга и анализа отдельных потоков. Через интерфейс (316) сопряжения с управляющим устройством сетевой контроллер (140) может сообщаться с внешним маршрутизатором, таким как управляющее устройство (130), для направления части сетевого трафика на сетевой контроллер (140), если соблюдены определенные условия. Обычно сетевые потоки, представляющие интерес для сетевого контроллера (140), содержат более крупные медиа-объекты, такие как видео и изображения. В одном из вариантов осуществления настоящего изобретения более мелкие объекты, такие как веб-страницы и текстовая информация, не перенаправляются интерфейсом (316) сопряжения с управляющим устройством.

В кэш-памяти (322) хранится информация об отслеженных потоках, которая обновляется с каждой транзакцией, выполненной управляющим устройством (130). В одном из вариантов осуществления настоящего изобретения данные, хранящиеся в кэш-памяти потоков, классифицированы в таблице по хэш-кодам, которые могут иметь длину до 64 бит и выше. Занесение данных в хэш-таблицу кэш-памяти может быть организовано через связанный список, допускающий хэш-коллизии. В альтернативном варианте для увеличения скорости бинарного поиска в таблице кэш-памяти потоков может быть также использовано сокращение числа битов в хэш-коде. Например, вместо использования 64-битного хэш-кода, которому в наихудшем случае требуется 64 операции для нахождения узла, длина хэш-кода может быть сокращена до 16-24 битов. В других вариантах осуществления настоящего изобретения для дальнейшей оптимизации поиска хэш-коллизий вместо связанного списка могут быть использованы таблицы или бинарные деревья других типов.

В журнале (324) абонентов хранится информация о пользователях или абонентах, в частности, идентификационные номера пользователей или абонентов и сведения об их устройствах. В одном из вариантов осуществления настоящего изобретения информация о пользователях и их устройствах вносится в журнал (324) абонентов администраторами или операторами сетей поставщиков услуг или операторов связи. В других вариантах осуществления настоящего изобретения информация о пользователях или устройствах сетей операторов связи (например, поставщиков услуг мобильного Интернета) недоступна для сетевого контроллера (140). Это затрудняет измерение пропускной способности, поскольку устройства множества пользователей могут разделять один и тот же IP-адрес при использовании протокола NAT (трансляции сетевых адресов). Соответственно, анализатор (312) потоков может реализовать алгоритмы, которые разделяют множество пользователей с одним IP-адресом, чтобы определить величину пропускной способности, доступной отдельным абонентам.

Данные, хранящиеся в кэш-памяти (322) потоков и в журнале (324) абонентов, используются для мониторинга пропускной способности и идентификации абонентов с помощью анализатора (312) потоков. Анализатор (312) потоков сканирует все записи в таблице кэш-памяти. Поскольку прочие операции, такие как добавление новых записей в кэш-память или обновление статистики по потокам, могут мешать сканированию и вызывать искажение данных, анализатор (312) потоков блокирует кэш-память на время идентификации абонента и мониторинга пропускной способности. Для сведения к минимуму времени блокирования сканирование может быть приостановлено после выполнения заданного количества операций. Анализатор (312) потока может возобновить сканирование с того места, на котором оно было приостановлено. Это достигается, например, с помощью итератора последней сканированной позиции в таблице. В случае если следующая операция приводит к изменениям в итераторе, итератор должен быть отрегулирован соответствующим образом, чтобы удостовериться в его пригодности.

Подсистема (314) обработки политик определяет политики в области оптимизации крупных потоков медиа-объектов с целью уменьшения перегрузки сети. Для выявления перегрузки сети и определения дальнейших действий, обусловленных такой перегрузкой, упор в конструкции сетевого контроллера (140) сделан на использовании представленной чрезвычайно гибкой подсистемы обработки политик. Подсистема (314) обработки политик способна принимать практически любые входные данные, как выведенные из HTTP-заголовков или полезной нагрузки (например, через интерфейс RADIUS/Gx), так и предоставленные сетевой инфраструктурой через API-интерфейс; и принимать решения в отношении применения оптимизации, основываясь на отдельных входных данных или комбинации таких входных данных. Политики в области оптимизации могут применяться к крупным потокам данных непрерывно или по времени суток, на поабонентской основе и/или в зависимости от состояния сети.

Например, подсистема (314) обработки политик может быть выполнена с возможностью применения оптимизации по времени суток для разных сегментов сети. Конфигурация по времени суток может быть задана на основании статистических данных о потоке за прошлый период, сохраненных в кэш-памяти (322), с использованием сведений о моделях состояния сети и потреблении пропускной способности определенных сегментов сети в течение заданного времени суток или недели. Например, если «высокая перегрузка» по всей сети наблюдается каждый день в период с 19.00 по 22.00, то политика может быть настроена на оптимизацию видео в этот период времени, когда скорость передачи видеоданных с источника превышает 225 кбит/с. Если каждый день по всей сети наблюдается «средняя перегрузка» в период с 15.00 по 19.00, то видеоданные оптимизируются, если скорости передачи данных с источника превышает 300 кбит/с. Существует также возможность вручную перезаписать политику на повременной основе при возникновении перегрузки.

Подсистема (314) обработки политик может корректировать подходы к оптимизации, исходя не только из перегрузки сети, но также с учетом общей производительности оптимизации. В зависимости от производительности оптимизации, установленной для обслуживания сети, запросы на оптимизацию могут превышать лимит на оптимизирующих серверах. Сетевой контроллер (140) и пул серверов оптимизатора (150) видео обмениваются между собой сообщениями о «проверке работоспособности» с тем, чтобы обеспечить мониторинг производительности оптимизации. Если указанный пул работает с полной производительностью, то об этом уведомляется сетевой контроллер (140). По мере того, как указанны пул достигает полной производительности, сетевой контроллер (140) может динамически регулировать пороговую скорость передачи данных в битах таким образом, чтобы под оптимизацию подпадали только крупные потоки данных.

Например, предположим, что сеть перегружена, а плановая скорость передачи потока данных составляет, по меньшей мере, 225 кбит/с. Обычно подсистема (314) обработки политик оптимизирует любой поток видеоданных, скорость передачи которых на 15% и более превышает плановую скорость (т.е. около 260 кбит/с). Но как только производительность оптимизатора (150) видео достигает 85%, подсистема (314) обработки политик повышает порог с тем, чтобы оптимизации подвергались только те потоки видеоданных, скорость передачи которых составляет 300 кбит/с и выше, для максимальной экономии пропускной способности. Так как коэффициент использования оптимизатора (150) видео может достигать и более высоких показателей, пороговый уровень может быть увеличен еще больше. Например, может быть оптимизировано только видео высокого разрешения, поскольку именно «тяжелое» видео в наибольшей степени оказывает влияние на восприятие пользователя.

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

Следует отметить, что решение об оптимизации видео часто принимается до начала потоковой передачи данных, поскольку оптимизация видеоданных с середины потока обуславливает серьезные технические проблемы. Как только поток видеоданных начинает передаваться на устройство, из-за оптимизации некоторые параметры оказываются недоступными. Например, в середине потоковой передачи данных нельзя изменить разрешение видео (ширину × высоту), и поэтому невозможно использовать особую методологию оптимизации. Другой пример: во время потоковой передачи данных скорость передачи видеокадров может быть изменена только за счет пропуска отдельных кадров; при этом отсутствует возможность перекодировки видео на другую скорость передачи. Таким образом, внутрикадровая информация подвергается негативному воздействию, что в значительной мере сказывается на качестве видео. Кроме того, в середине потоковой передачи данных технически невозможно адаптировать преобладающий формат потокового видео, такой как MP4, используемый для большинства приложений iOS и Android. Формат файлов MP4 требует, чтобы все решения по оптимизации принимались до того, как будет отправлен первый байт информации. Следовательно, сетевой контроллер (140) всегда определяет уровень оптимизации в начале потоковой передачи видеоданных. Целевая оптимизация предусматривает задание определенной конфигурации, представляющей собой сочетание таких параметров, как разрешение, скорость передачи видеокадров и полоса пропускания, обеспечивающее устойчивое восприятие сети абонентом от начала до конца передачи данных.

Система (318) переадресации оптимизатора видео генерирует запрос переадресации к URL, который указывает на оптимизатор (150) видео, если видео считается перекодированным. В одном из вариантов осуществления настоящего изобретения URL может содержать, по меньшей мере, один из таких параметров, как разрешение видео, скорость передачи видеоданных в битах, делитель частоты видеокадров, частота аудиовыборки и количество каналов, скорость передачи аудиоданных в битах, URL источника, пользовательский агент клиента, cookie-файл исходной области и другие данные аутентификации оптимизатором (150) видео. Система (318) переадресации оптимизатора видео переписывает первоначальный ответ на HTTP Redirect (Переадресация) и задает новому URL заголовок местоположения. Это приводит к тому, что абонентские устройства (110) посылают новый запрос к оптимизатору (150) видео. Система (318) переадресации оптимизатора видео также характеризуется наличием логической схемы, отслеживающей входящие URL, сгенерированные им самим, во избежание повторных перехватов.

Мониторинг сети и выявление перегрузки

На фиг. 4А и 4В проиллюстрирован один из вариантов реализации рабочих режимов сетевого контроллера по обеспечению выборочного мониторинга сети и идентификации абонента по требованию в реальном масштабе времени. Вместе с сетевым контроллером (140) на фигуре представлено абонентское устройство (110), управляющее устройство (130) и сервер (160) источника. Сетевой контроллер (140) соединен с управляющим устройством (130) через интерфейс (316) сопряжения с управляющим устройством. В одном из вариантов осуществления настоящего изобретения сетевой контроллер (140) и управляющее устройство (130) взаимодействуют друг с другом по протоколу ICAP (протокол адаптации Интернет-контента). Интерфейс (316) сопряжения с управляющим устройством использует сервер (406) ICAP, который взаимодействует с клиентом (404) ICAP, выполняемым на управляющем устройстве (130). Согласно другим вариантам осуществления настоящего изобретения для обмена информацией между сетевым контроллером (140) и управляющим устройством (130) могут быть использованы аналогичные или разные протоколы.

Протокол адаптации Интернет-контента (ICAP) представляет собой упрощенный протокол, предназначенный для выполнения облегченного удаленного вызова процедур по протоколу HTTP. Протокол ICAP повышает эффективность использования граничных устройств, помогая оказывать дополнительные виды услуг с использованием прозрачных кэширующих HTTP прокси-серверов. Адаптация контента относится к выполнению конкретной дополнительной услуги, такой как манипулирование контентом или иная обработка контента, для запроса/ответа HTTP-клиента. ICAP-клиенты передают HTTP-сообщения на серверы ICAP для их преобразования или иной обработки. ICAP-сервер, в свою очередь, выполняет функцию по предобразованию HTTP-сообщений и отсылает ответы ICAP-клиенту. В основе этого процесса лежит кэширование, позволяющее проксировать все клиентские транзакции и обрабатывать их с помощью ICAP-серверов, которые могут быть сфокусированы на выполнение конкретных функций, таких как вставка, сканирование на наличие вирусов, трансляция контента, перевод с одного языка на другой или фильтрация контента. ICAP-серверы, например, используемые сетевым контроллером (140), обрабатывают эти задания для снятия дополнительных услуг с абонентских устройств, включая ICAP-клиента, такого как управляющее устройство (130). За счет снятия дополнительных услуг с управляющего устройства (130) инфраструктура обработки (например, сервисы оптимизации и сетевые контроллеры) может масштабироваться независимо от управляющих устройств, обрабатывающих исходную HTTP-производительность.

Как показано на фиг. 4А, сетевой трафик исходит с абонентского устройства (110) и через управляющее устройство (130) поступает в сервер (160) источника по сетевому тракту запроса. Но, например, браузер абонентского устройства (110) может запросить веб-контент с сервера (160) источника. Запросное сообщение HTTP, инициированное абонентским устройством (110), передается на управляющее устройство (130) по сетевой линии (411) связи. После этого устройство (402) коммутации данных внутри управляющего устройства (130) переключает запросное сообщение на сервер (160) источника по сетевой линии (412) связи. В противоположном направлении сетевой трафик, исходящий с сервера (160) источника, поступает обратно в абонентское устройство (110) через управляющее устройство (130) по сетевому тракту запроса. Например, сервер (160) источника отвечает на запрос пользователя, пересылая веб-контент по сетевой линии (413) связи на управляющее устройство (130), которое направляет веб-контент далее на абонентское устройство (110) по сетевой линии (416) связи. Следует отметить, что сетевые линии (411) и (416) представляют собой два противоположных направления одной и той же физической линии связи, равно как и пара сетевых линий (412) and (413). С другой стороны, пара сетевых линий (412) и (413) может занимать один и тот же или разные сетевые тракты, поскольку маршрут трафика между управляющим устройством (130) и сервером (160) источника в противоположных направлениях может быть проложен по-разному через один или несколько маршрутизаторов.

В одном из вариантов осуществления настоящего изобретения по мере того, как управляющее устройство (130) осуществляет мониторинг откликов сети, оно отслеживает потоки, которые совпадают с одной или несколькими сигнатурами видео или изображений. При обнаружении совпадающего потока управляющее устройство (130) направляет HTTP-запрос и часть HTTP-ответа на сетевой контроллер (140) через интерфейс (404) ICAP-клиента. После получения запроса и части ответа интерфейсом (406) ICAP-сервера анализатор (312) потоков сетевого контроллера (140) проводит углубленную проверку потока, чтобы определить, имеет ли смысл осуществлять мониторинг пропускной способности для этого потока и/или идентифицировать абонента. Например, в ходе анализа потока, проведенного анализатором (312), можно определить, действительно ли данный поток содержит объекты большого или среднего размера (например, размером свыше 50 Кб), и/или принадлежит ли IP-адрес источника потока одному пользователю или группе пользователей, которые должны отслеживаться согласно текущей политике. Анализатор (312) потоков может также определить, следует ли оптимизировать поток, исходя из статистических данных за прошлый период.

Если поток представляет интерес, то управляющее устройство (130) уведомляется о необходимости регулирования потока через сетевой контроллер (140). Такой режим мониторинга пропускной способности называется «непрерывным». В «непрерывном» режиме сетевой контроллер (140) сопрягается с управляющим устройством (130) для функционирования, по запросу, в качестве стандартного сетевого элемента управления потоками, которые представляют интерес. Таким образом, сетевой контроллер (140) принимает сетевой поток на анализ, после чего пересылает его дальше по сетевому тракту запроса. Например, в отношении данного конкретного потока, сервер (160) источника отвечает на запрос пользователя путем пересылки видеоданных или изображений по сетевой линии (413) связи на управляющее устройство (130), которое пересылает эти видеоданные или изображения на сетевой контроллер (140) по сетевой линии (414) связи. После того как сетевой контроллер (140) обновит статистику по потоку, видеоданные или изображения возвращаются в управляющее устройство (130) по сетевой линии (415) связи, которое передает видеоданные или изображения в абонентское устройство (110) по сетевой линии (416) связи.

Сразу после поступления данных о потоке в сетевой контроллер (140) в кэш-памяти (322) создается запись об этом потоке. Запись в кэш-памяти фиксирует параметры потока и соответствующей полосы пропускания. Что касается потока, мониторинг которого осуществляется в «непрерывном» режиме, то всякий раз, когда управляющее устройство (130) передает очередную порцию полезной информации об этом потоке сетевому контроллеру (140), кэш-память (322) обновляет количество байт, переданных с потоком. За счет мониторинга количества байт в расчете на поток, изменяемого в динамике по времени, анализатор (312) потоков может определить оценочное значение пропускной способности для этого потока. Кроме того, поскольку управляющее устройство (130) не имеет объемного буфера пакетов, в случае возникновения перегрузки в сетевой линии (416) связи, соединяющей управляющее устройство (130) с абонентским устройством (110), в управляющем устройстве (130) идет вразнос механизм адаптации к загруженности сети в TCP, что может привести к замедлению и/или даже к остановке приема данных с сервера (160) источника по сетевой линии (413) связи. Во время перегрузки управляющее устройство (130) не передает какие-либо данные на сетевой контроллер (140), поскольку линия (416) перегружена, и сетевой контроллер (140) не в состоянии передавать данные на абонентское устройство (110). Таким образом, сетевой контроллер (140), представляющий собой промежуточный элемент, может выявлять перегрузки сети и оценивать пропускную способность, связанную с любыми потоками, представляющими интерес, выбранными сетевым контроллером (140). Однако в «непрерывном» режиме сетевой контроллер (140) не модифицирует и не преобразует HTTP-сообщения, которые он получает через интерфейс ICAP. Сетевой контроллер (140) просто обновляет статистику по потокам и возвращает видеоданные или изображения в управляющее устройство (130) для их последующей передачи на абонентское устройство (110).

На основе статистики по потокам, сохраненной в кэш-память (322), сетевой контроллер (140) может также объединять потоки, соотнесенные с конкретным абонентом или пользователем, для определения общей доступной полосы пропускания, занятой этим абонентом или пользователем. В одном из вариантов осуществления настоящего изобретения сетевой контроллер (140) отслеживает все записи в кэш-памяти, отыскивая потоки, поступающие с общего IP-адреса источника, или с одним идентификатором абонентского устройства. После этого анализатор (312) потоков сетевого контроллера (140) пытается сгруппировать эти потоки с целью формирования единой статистики по потокам для отдельного пользователя или абонента. Кроме того, сетевой контроллер (140) идентифицирует пользователей или абонентов, используя две компоненты данных в записи кэш-памяти: TCP-порт источника и HTTP cookies, связанные с потоком. Используя статистические данные по потокам за прошлый период, сетевой контроллер (140) устанавливает модель, после чего идентифицирует пользователей или абонентов и сохраняет информацию об абонентах в журнале (324) абонентов. Более подробно о кэш-памяти и отображении пользователей сказано ниже в привязке к соответствующей фигуре.

На фиг. 4В показан один из вариантов реализации второго рабочего режима сетевого контроллера по обеспечению выборочного мониторинга сети по требованию. На фиг. 4В сетевой тракт запроса состоит из сетевой линии (421) связи, соединяющей абонентское устройство (110) с управляющим устройством (130), и сетевой линии (422), соединяющей управляющее устройство (130) с сервером (160) источника. Что касается противоположного направления, то сетевой тракт запроса состоит из сетевой линии (423) связи, идущей от сервера (160) источника к управляющему устройству (130), и сетевой линии (424), идущей от управляющего устройства (130) обратно к абонентскому устройству (110). Следует отметить, что пара сетевых линий (421) и (424) занимают одну и ту же физическую линию связи, равно как и пара сетевых линий (425) and (426).

Как и в случае с «непрерывным» режимом, после получения исходного HTTP-сообщения о потоке и принятия решения о мониторинге потока сетевой контроллер (140) уведомляет управляющее устройство (130) о работе в «счетном» режиме мониторинга пропускной способности. В отличие от «непрерывного» режима, после обнаружения подходящего под «счетный» режим потока управляющее устройство (130) передает HTTP-ответ непосредственно на абонентское устройство (110). Одновременно с этим управляющее устройство (130) передает индивидуализированное ICAP-сообщение на сетевой контроллер (140) по сетевой линии (425) связи. В одном из вариантов осуществления настоящего изобретения индивидуализированное ICAP-сообщение содержит заголовки HTTP-запроса и HTTP-ответа, а также подсчитанный размер полезной нагрузки текущего потока. После обновления статистики по потокам сетевой контроллер (140) может подтвердить шлюз по сетевой линии (426) связи. В «счетном» режиме сетевой контроллер (140) не включается в сетевой тракт ответа в качестве промежуточного сетевого элемента; при этом он просто ожидает подсчета размеров потока. Преимущество «счетного» режима заключается в том, что сетевой контроллер (140) освобождается от приема сетевого потока и его передачи в сетевой тракт ответа, но при этом он сохраняет возможность обнаружения перегрузок сети и оценки пропускной способности, связанной с потоками, представляющими интерес.

На фиг. 5 представлена блок-схема, иллюстрирующая вариант осуществления трассировки событий в «непрерывном» режиме между абонентским устройством (110), управляющим устройством (130), сетевым контроллером (140), оптимизатором (150) видео и сервером (160) источника. Процесс начинается тогда, когда абонентское устройство (110) инициирует запрос (512) HTTP GET на получение контента с сервера (160) источника. Управляющее устройство (130) перехватывает все запросы, инициируемые абонентским устройством (110). В одном из вариантов осуществления настоящего изобретения управляющее устройство (130) передает запрос (512) HTTP GET на соответствующий сервер (160) источника и получает ответ (514) с сервера (160) источника. Затем управляющее устройство (130) посылает запросное сообщение (516) ICAP, содержащее заголовок запроса HTTP GET и часть ответной полезной нагрузки, на сетевой контроллер (140), который анализирует это сообщение с тем, чтобы определить, целесообразно ли отслеживать поток или оптимизировать видеоданные. В этом случае сетевой контроллер (140) дает ответ с переадресацией для оптимизаций видеоданных в ICAP-ответе (518). После получения команды управляющее устройство (130) переписывает ответ (514) на HTTP-ответ (520) переадресации, в результате чего абонентское устройство (110) инициирует запрос на видеофайл с оптимизатора (150) видео. В другом варианте осуществления настоящего изобретения сетевой контроллер (140) посылает HTTP-запрос (520) переадресации непосредственно на абонентское устройство (110). В случае если поток не содержит видео-объектов или объектов в виде изображений, или если сетевой контроллер (140) посчитает, что мониторинг потока не нужен, управляющее устройство (130) перешлет ответ на абонентское устройство (110).

После получения абонентским устройством (110) HTTP-запроса (520) переадресации абонентское устройство (110) перешлет запрос по сети на оптимизатор (150) видео. В одном из вариантов осуществления настоящего изобретения сетевой контроллер (140) осуществляет мониторинг трафика и/или запросов с клиентского устройства (110) по мере того, как HTTP-запрос (520) переадресации передается на оптимизатор (150) видео. При такой конфигурации оптимизатор (150) видео «видит» запросы только на те видеофайлы, которые должны быть перекодированы (т.е. оптимизированы), и которые соотнесены с HTTP-запросом (520) переадресации. В связи с этим оптимизатор (150) видео не перегружен всеми запросами, которые были сгенерированы абонентским устройством (110).

После получения запроса оптимизатор (150) видео пересылает запросы (522) HTTP GET на видеоданные на сервер (160) источника, и в ответ получает с сервера (160) источника видеофайл (524). Оптимизатор (150) видео перекодирует видеофайл в формат, который может использовать абонентское устройство (110), исходя из пропускной способности сети, доступной абонентскому устройству (110). Затем оптимизированное видео (526) передается с оптимизатора (150) видео на управляющее устройство (130). В одном из вариантов осуществления настоящего изобретения оптимизированное видео (526) перехватывается управляющим устройством (130). После принятия сетевым контроллером (140) решения о мониторинге потока в «непрерывном» режиме оптимизированное видео (526) передается в сетевой контроллер (140) перед тем как вернуться в управляющее устройство (130) и в итоге поступить в абонентское устройство (110). В результате клиент получает оптимизированное видео (512) для его воспроизведения практически в реальном масштабе времени с помощью приложения, установленном на абонентском устройстве (110).

В одном из вариантов осуществления настоящего изобретения, чутко реагируя на запрос (522) HTTP GET к серверу (160) источника, оптимизатор видео может получить с сервера (160) источника HTTP-ошибку (404), а не видеофайл. В этом случае оптимизатор (150) видео снабжает HTTP-запрос переадресации флажком «Не перекодировать» и возвращает его в абонентское устройство (110), которое повторно пересылает запрос по сети на сервер (160) источника. Сервер (160) источника реагирует на запрос соответствующим образом, отсылая обратно видео (524), которое перехватывается управляющим устройством (130) и сетевым контроллером (140), как промежуточным элементом сети, в целях мониторинга.

На фиг. 6 представлена блок-схема, иллюстрирующая один из вариантов реализации трассировки событий в «счетном» режиме между абонентским устройством (110), управляющим устройством (130), сетевым контроллером (140), оптимизатором (150) видео и сервером (160) источника. Процесс начинается тогда, когда абонентское устройство (110) инициирует запрос (612) HTTP GET на получение контента с сервера (160) источника. Управляющее устройство (130) перехватывает все запросы, исходящие с абонентского устройства (110). В одном из вариантов осуществления настоящего изобретения управляющее устройство (130) передает запрос HTTP GET (612) на соответствующий сервер (160) источника и получает с этого сервера источника ответ (614). Затем управляющее устройство (130) посылает запросное ICAP-сообщение (616), содержащее заголовок запроса HTTP GET и часть ответной полезной нагрузки, на сетевой контроллер (140), который анализирует это сообщение с тем, чтобы определить, целесообразно ли отслеживать поток или оптимизировать видеоданные. В этом случае сетевой контроллер (140) дает ответ с переадресацией для оптимизации видеоданных в ICAP-ответе (618). После получения команды управляющее устройство (130) переписывает ответ (614) на HTTP-ответ (620) переадресации, в результате чего абонентское устройство (110) инициирует запрос на видеофайл с оптимизатора (150) видео. В еще одном из вариантов осуществления настоящего изобретения сетевой контроллер (140) посылает HTTP-запрос (620) переадресации непосредственно на абонентское устройство (110). В случае если поток не содержит видео-объектов или объектов в виде изображений, подлежащих переадресации, управляющее устройство (130) перешлет ответ на абонентское устройство (110).

После получения абонентским устройством (110) HTTP-запроса (620) переадресации абонентское устройство (110) перешлет запрос по сети на оптимизатор (150) видео. В одном из вариантов осуществления настоящего изобретения сетевой контроллер (140) осуществляет мониторинг трафика и/или запросов, поступающих с клиентского устройства (110) по мере того, как HTTP-запрос (620) переадресации передается на оптимизатор (150) видео. При такой конфигурации оптимизатор (150) видео «видит» запросы только на те видеофайлы, которые должны быть перекодированы (т.е. оптимизированы), и которые соотнесены с HTTP-запросом (620) переадресации. В связи с этим оптимизатор (150) видео не перегружен всеми запросами, которые были сгенерированы абонентским устройством (110).

После получения запроса оптимизатор (150) видео пересылает запросы (622) HTTP GET на видеоданные на сервер (160) источника, и в ответ получает с сервера (160) источника видеофайл (624). Оптимизатор (150) видео перекодирует видеофайл в формат, который может использовать абонентское устройство (110), исходя из пропускной способности сети, доступной абонентскому устройству (110). Затем оптимизированное видео (626) передается с оптимизатора (150) видео на управляющее устройство (130). В одном из вариантов осуществления настоящего изобретения оптимизированное видео (626) перехватывается управляющим устройством (130). После этого управляющее устройство (130) посылает ICAP-запрос на сетевой контроллер (140) для анализа. Сетевой контроллер (140) признает этот поток подлежащим мониторингу и отсылает ICAP-ответ (630). Затем управляющее устройство (130) дает разрешение на прохождение потока в абонентское устройство (110). После этого управляющее устройство (130) будет периодически пересылать на сетевой контроллер (140) ICAP-обновления (632) «подсчета» до тех пор, пока не завершится передача потока данных. В результате клиент получает оптимизированное видео (626) для его воспроизведения практически в реальном масштабе времени с помощью приложения, установленном на абонентском устройстве (110).

В одном из вариантов осуществления настоящего изобретения, если оптимизатор (150) видео не смог снять запрошенный пользователем видеофайл с сервера (160) источника, оптимизатор (150) видео снабжает HTTP-запрос переадресации флажком «Не перекодировать» и возвращает его в абонентское устройство (110), которое повторно пересылает запрос по сети на сервер (160) источника. Сервер (160) источника реагирует на запрос соответствующим образом, отсылая обратно видео (624), которое перехватывается только управляющим устройством (130). Управляющее устройство (130) передает видео на абонентское устройство (110) и одновременно с этим сообщает сетевому контроллеру (140) размеры потока в целях мониторинга.

Кэш-память потоков и отображение пользователей

На фиг. 7 представлена блок-схема, иллюстрирующая один из вариантов реализации внутренних элементов кэш-памяти потоков. Карта (700) кэш-памяти содержит множество записей о потоках, таких как записи (710) и (712), которые классифицированы по хэш-кодам. С каждой записью в кэш-памяти может быть соотнесен связанный список, не показанный на иллюстративной блок-схеме, который позволяет связать записи в кэш-памяти, привязав их к определенному хэш-коду. Хэширование кэша потоков может основываться на IP-адресе источника, MAC-адресе, ID абонента или ином идентификаторе, указывающего на конкретного абонента, группу абонентов или абонентское устройство.

Блок (720) кэш-памяти, на который указывает запись (712) в кэше, содержит информацию об IP-адресе (722) источника, а также один или несколько блоков пользовательских потоков, которые обозначают логически связанную группу потоков, соотнесенных с конкретным пользователем, абонентом или объектом, представляющим собой потенциального абонента. Примером таких блоков пользовательских потоков служит блок (724) пользовательских потоков по умолчанию и блок (726) соотнесенных пользовательских потоков. В блоке (724) пользовательских потоков по умолчанию хранятся сведения о потоках, которые еще не соотнесены с конкретным пользователем или абонентом. Если ID или иные идентификаторы абонента, соотнесенные с конкретным пользователем известны априори, то все потоки, связанные с этим конкретным абонентом или пользователем, будут закреплены за блоком (726) соотнесенных пользовательских потоков. Блок (726) соотнесенных пользовательских потоков содержит также потоки, которые уже соотнесены или находятся в процессе соотнесения с пользователем или абонентом анализатором (312) потоков. Соотнесенные пользовательские потоки в блоке (726) могут быть классифицированы по ID абонентов.

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

Пример блока (730) пользовательских потоков, который может быть включен в блок (724) пользовательских потоков по умолчанию и в блок (726) соотнесенных пользовательских потоков, содержит поля данных, такие как идентификатор (732) абонента (псевдо- или реальный); измеренная пропускная способность (П\С) (734); список (736) всех потоков, соотнесенных с идентификатором (732) абонента; список (738) хэш-значений cookie; и другая информация о потоках. Каждая запись в списке (738) хэш-значений cookie содержит один уникальный cookie-файл, наблюдаемый в потоках. Список (736) потоков содержит один или несколько блоков (740) статистики по потокам. Каждый блок (740) статистики по потокам содержит идентификатор (742) IP потока (например, srcIP, dstIP, srcPort и dstPort); предметную область и cookie-файл (744); общее число (746) байтов, наблюдаемых в каждом направлении; и общее число (748) байтов в каждом направлении на момент последнего обновления. Может быть также предусмотрен список хэш-значений cookie, соотнесенных с конкретным потоком и временем истечения, который не показан на фиг. 7.

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

Приблизительная пропускная способность (734) в блоке (700) пользовательских потоков может быть рассчитана следующим образом. В одном из вариантов осуществления настоящего изобретения всякий раз, когда в кэше создается или обновляется блок (730) пользовательских потоков, он отмечается флажком «Черновой» («Dirty»). Флажок «Черновой» указывает анализатору (312) на то, что для данного потока данных может потребоваться повторное вычисление пропускной способности. Это сделано для того, чтобы анализатору (312) не надо было просматривать каждый блок пользовательских потоков для определения необходимости его обновления. Флажок «Черновой» может быть установлен в блоке (700) пользовательских потоков или в блоке (740) статистики по потокам. Повторный расчет или обновление пропускной способности может выполняться периодически (например, с интервалом в одну секунду, десять секунд или минуту). При обновлении разница между переданными (и/или полученными) байтами после последнего обновления используется для измерения числа байтов в динамике по времени, процентной доли потребленной пропускной способности в сравнении с общей пропускной способностью, пропускной способности в направлении приема (rx) и в направлении передачи (tx) за определенный интервал времени. Число переданных (и/или принятых) байтов за определенный период времени может быть также суммировано для всех потоков, соотнесенных с конкретным пользователем, для измерения расчетной пропускной способности на прием для данного конкретного пользователя.

При расчете пропускной способности потоки подразделяются на сегменты по размерам передаваемых объектов. Объекты небольшого размера могут не включаться в расчет пропускной способности, поскольку они могут появляться и исчезать в течение одного интервала времени. Например, могут игнорироваться потоки с размером полезной нагрузки менее 50 Кб, так как передача 50 Кб практически не в состоянии охватить всю потенциальную пропускную способность канала связи. Хотя потоки большего размера могут занимать всю полосу пропускания канала связи в течение длительного периода времени, они сгруппированы в сегменты размерами 50-75 Кб, 75-100 Кб и >100 Кб, поскольку характеристики потоков этих размеров могут отличаться друг от друга, и поэтому пропускная способность по каждому из этих сегментов измеряется и рассчитывается отдельно. В других вариантах осуществления настоящего изобретения диапазоны размеров сегментов (например, 50-75 Кб, 75-100 Кб и >100 Кб) могут изменяться в зависимости от сетевого трафика и размеров передаваемых объектов. Кроме того, размеры сегментов перед передачей клиенту могут также регулироваться, исходя из топологии сети, например, размеров буфера. Рассчитанная пропускная способность в расчете на сегмент сохраняется в структуре данных типа «очередь», что позволяет вычислять и обновлять минимальные, максимальные и/или средние измерения по каждому сегменту. В одном из вариантов осуществления настоящего изобретения хвост текущей записи сегмента размером >100 Кб проверяется по средней пропускной способности сегмента размером >100 Кб. Если текущая запись меньше среднего значения, умноженного на число записей в очереди, то текущая запись добавляется к расчету пропускной способности для текущего интервала. Эта схема помогает отфильтровывать крупные пакеты данных из временных незанятых потоков. Если пропускная способность превышает это значение, то ряд байтов (например, 125 Кб) будет вычтено из текущей записи за счет TCP-буферов в сети.

После распределения по соответствующим сегментам всех потоков, соотнесенных с конкретным пользователем, для каждого из этих сегментов рассчитывается пропускная способность путем объединения измеренных данных по всем потокам, которые были распределены по соответствующим сегментам. В одном из вариантов осуществления настоящего изобретения размеры потоков в сегменте >100 Кб сначала сравниваются с максимальной величиной пакета. Если размер потока в сегменте >100 Кб превышает определенный процент (например, 25%) максимальной величины пакета, то этот поток не включается в расчетную пропускную способность. В частности, пока какое-то время поток не занят, большой объем данных может быть передан одним пакетом до того, как сеть обеспечит резервирование за счет сетевых буферов. Максимальная величина пакета фиксирует максимальную пропускную способность для потоков размерами >100 Кб (или сегментов с более высокой пропускной способностью) для конкретного пользователя. Если размер потока намного меньше (например, менее 25%) максимальной величины пакета, то он добавляется к расчетной пропускной способности.

Расчетная пропускная способность вычисляется путем суммирования значений пропускной способности, рассчитанных по каждому из сегментов для текущего интервала времени. Расчетная пропускная способность обновляется только в том случае, если во время этого интервала были пересланы какие-то данные, т.е. если один или несколько сегментов оказываются занятыми. Кроме того, для обновления расчетной пропускной способности должно быть передано некое минимальное число байтов. Это достигается путем взвешивания средней пропускной способности в расчете на сегмент, умноженной на предельное значение младшего бита сегмента (например, 50, 75 или 100 Кб), для придания большего веса данным из сегментов больших размеров. Расчетная пропускная способность обновляется только тогда, когда общий вес по каждому из сегментов превышает некое пороговое значение. Это сделано для того, чтобы предотвратить создание ложных обновлений пропускной способности мелкими пакетами данных в сегментах небольших размеров.

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

При обнаружении нового потока поиск записей в кэше осуществляется путем сопоставления IP-адреса (722) источника, если недоступен ID абонента или иные идентификаторы потока. В случае, когда множество пользователей разделяют один и тот же IP-адрес, анализатору (312) потоков необходимо найти шаблоны или иные идентификаторы в потоках для их привязки к конкретным абонентам. Потоки данных без идентифицированных абонентов добавляются в блок кэша потоков в раздел (724) пользовательских потоков по умолчанию, предназначенный для хранения новых потоков данных по умолчанию. Позднее анализатор (312) потоков просканирует пользовательские потоки по умолчанию, содержащие cookie-файлы или иные идентификаторы, которые могут быть использованы для определения реального пользователя или абонента, соотнесенного с этим потоком. Если поток содержит идентификаторы, не соотнесенные с имеющимся реальным абонентом, то создается новый пользователь или абонент, и блок пользовательских потоков переходит к вновь созданному (или соотнесенному) пользователю или абоненту.

Анализатор (312) потоков может также соотносить потоки с пользователями (абонентами сети мобильной связи или сетевой службы) в записях кэша путем сопоставления хэш-значений cookie, MAC-адреса (или иных уникальных идентификаторов устройства) или портов источника TCP. Например, если два потока разделяют между собой один и тот же порт источника, то высока вероятность того, что они принадлежат одному и тому же пользователю, поскольку TCP-порты часто многократно используются одним и тем же пользователем, а не несколькими. Кроме того, порты источника могут также использоваться для соотнесения пользователей, когда развернута трансляция сетевых адресов (NAT). В типовой сети с конфигурацией NAT каждому пользователю назначается блок (например, 32) портов источника TCP. Затем снимается случайный номер порта в блоке для каждого вновь инициированного пользовательского потока. При наличии таких данных все порты источника в блоке могут быть агрегированы под идентификатором одного и того же пользователя. В некоторых случаях, когда пользователю приписан не один блок портов, для сведения таких блоков могут быть использованы хэш-значения cookie.

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

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

Адаптивное кодирование видеоинформации

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

В одном из вариантов осуществления настоящего изобретения оптимизатор видео действует как прокси-сервер по требованию, активизируемый сетевым контроллером через HTTP-запрос переадресации. Например, сетевой контроллер (140), представленный на фиг. 1, перенаправляет абонентское устройство (110) на оптимизатор (150) видео для получения видеоданных, которые оптимизатор (150) видео снимает с сервера (160) источника, указанного в сообщении переадресации. Сразу после перекодировки видеоданных по требованию оптимизатором (150) видео поток видеоданных направляется на абонентское устройство. Соответственно, оптимизатор (150) видео может отслеживать, сколько данных он в состоянии пропустить через сеть.

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

Еще один из рабочих режимов оптимизатора (150) видео предусматривает выявление критических величин скорости передачи данных в битах. Если скорость передачи данных из циклического буфера значительно ниже текущей скорости передачи данных кодировщиком, то скорость передачи данных кодировщиком может быть уменьшена. Эта функция может оказаться полезной, поскольку иногда заданная последовательность аудио- или видеоданных не требует кодирования большого числа битов. Скорость передачи данных в битах может быть увеличена, поскольку время задержки остается на низком уровне. Однако последовательность может быть изменена, и может потребоваться большое число битов, что может вызвать искажение алгоритма кодирования. В свою очередь, система может обновлять скорость передачи битов каждые несколько секунд (например, каждые 5 секунд) для предотвращения резких колебаний качества видеоданных. Для предотвращения резких изменений качества также регулируется величина скорости передачи данных в битах, которая корректируется в ту или иную сторону.

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

Полевые испытания показали, что решение с сетевым контроллером (140) в сочетании с оптимизатором (150) видео дает революционную систему мгновенной адаптации, которая может оптимизировать практически любою объект в виде изображения или видео в течение миллисекунд. Эта система характеризуется широким охватом форматов (например, Flash, MP4 и ABR video), и дает в среднем 60-процентную экономию данных по видео и 50-процентную экономию данных по изображениям, что вместе дает в среднем 35-процентную экономию всего трафика для типовых сетей мобильной связи. Это 35-процентное сокращение рассчитывается во время наибольшей нагрузки на сеть, что снижает капитальные и эксплуатационные расходы в отличие от экономии, достигаемой за счет ограничения скорости передачи/плавного регулирования сетевого трафика, не влияющего на кривую капитальных расходов. Это решение легко внедряется, поддерживается и масштабируется по широкому спектру сетей за счет совмещения мощи облачных вычислений и существующей интеллектуальной маршрутизации в сети.

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

Дополнительные факторы, влияющие на конфигурацию

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

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

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

Различные операции в рамках проиллюстрированных способов (например, в привязке к фиг. 4А, 4В, 5, 6 и 7), описанных в настоящем документе, могут быть выполнены, по меньшей мере, частично одним или несколькими процессорами (например, процессором (102)), выполненными с временной возможностью (например, реализованной программно) или постоянной возможностью выполнения соответствующих операций. Вне зависимости от того, характеризуются ли процессоры временной или постоянной конфигурацией, они могут образовывать модули, реализованные на основе процессоров, которые предназначены для выполнения одной или нескольких операций или функций. В некоторых иллюстративных вариантах осуществления настоящего изобретения модули, упомянутые в настоящей заявке, могут представлять собой модули, реализованные на основе процессоров.

Некоторые части настоящего описания переданы на языке алгоритмов или символического представления операций с данными, сохраненными в виде битов или двоичных цифровых сигналов в памяти машины (например, в памяти компьютера (104)). Эти алгоритмы или символические представления являются примерами методик, которые используются рядовыми специалистами в области обработки данных для передачи сути своей работы другим специалистам в данной области техники. В контексте настоящего документа «алгоритм» представляет собой логическую последовательность операций или иную обработку данных подобного рода, которые дают требуемый результат. В этом контексте алгоритмы или операции предусматривает физическое манипулирование физическими величинами. Обычно, но не обязательно, такие величины могут принимать форму электрических, магнитных или оптических сигналов, к которым может быть обеспечен доступ и которые могут быть сохранены, переданы, объединены, сопоставлены, или иным образом обработаны машиной. Иногда удобно - главным образом, из-за их широкого применения - обозначать эти сигналы такими словами, как «данные», «контент», «биты», «значения», «символы», «элементы», «знаки», «цифры», «номера», «члены» и т.п. Эти слова, однако, служат просто удобными обозначениями, и они должны быть соотнесены с соответствующими физическими величинами.

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

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

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

В контексте настоящего документа термины «содержит», «включает в себя», «содержащий», «имеет», «имеющий» и их производные охватывают неисчерпывающие включения. Например, процесс, способ, изделие или устройство, которые содержат набор элементов, не обязательно ограничены только этими элементами, а могут включать в себя и другие элементы, прямо не указанные или присущие такому процессу, способу, изделию или устройству. Кроме того, если специально не оговорено иное, «или» относится к включающему «или», а не к исключающему «или». Например, условие А или В считается выполненным в одном из следующих случаев: А истинно (или имеет место), а В ложно (или не имеет места); А ложно (или не имеет места), а В истинно (или имеет место); или оба условия - как А, так и В - истинны (или имеют место).

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

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


МОНИТОРИНГ СЕТИ И ИДЕНТИФИКАЦИЯ АБОНЕНТА В РЕАЛЬНОМ МАСШТАБЕ ВРЕМЕНИ С ПОМОЩЬЮ УСТРОЙСТВА, СРАБАТЫВАЮЩЕГО ПО ТРЕБОВАНИЮ
МОНИТОРИНГ СЕТИ И ИДЕНТИФИКАЦИЯ АБОНЕНТА В РЕАЛЬНОМ МАСШТАБЕ ВРЕМЕНИ С ПОМОЩЬЮ УСТРОЙСТВА, СРАБАТЫВАЮЩЕГО ПО ТРЕБОВАНИЮ
МОНИТОРИНГ СЕТИ И ИДЕНТИФИКАЦИЯ АБОНЕНТА В РЕАЛЬНОМ МАСШТАБЕ ВРЕМЕНИ С ПОМОЩЬЮ УСТРОЙСТВА, СРАБАТЫВАЮЩЕГО ПО ТРЕБОВАНИЮ
МОНИТОРИНГ СЕТИ И ИДЕНТИФИКАЦИЯ АБОНЕНТА В РЕАЛЬНОМ МАСШТАБЕ ВРЕМЕНИ С ПОМОЩЬЮ УСТРОЙСТВА, СРАБАТЫВАЮЩЕГО ПО ТРЕБОВАНИЮ
МОНИТОРИНГ СЕТИ И ИДЕНТИФИКАЦИЯ АБОНЕНТА В РЕАЛЬНОМ МАСШТАБЕ ВРЕМЕНИ С ПОМОЩЬЮ УСТРОЙСТВА, СРАБАТЫВАЮЩЕГО ПО ТРЕБОВАНИЮ
МОНИТОРИНГ СЕТИ И ИДЕНТИФИКАЦИЯ АБОНЕНТА В РЕАЛЬНОМ МАСШТАБЕ ВРЕМЕНИ С ПОМОЩЬЮ УСТРОЙСТВА, СРАБАТЫВАЮЩЕГО ПО ТРЕБОВАНИЮ
МОНИТОРИНГ СЕТИ И ИДЕНТИФИКАЦИЯ АБОНЕНТА В РЕАЛЬНОМ МАСШТАБЕ ВРЕМЕНИ С ПОМОЩЬЮ УСТРОЙСТВА, СРАБАТЫВАЮЩЕГО ПО ТРЕБОВАНИЮ
МОНИТОРИНГ СЕТИ И ИДЕНТИФИКАЦИЯ АБОНЕНТА В РЕАЛЬНОМ МАСШТАБЕ ВРЕМЕНИ С ПОМОЩЬЮ УСТРОЙСТВА, СРАБАТЫВАЮЩЕГО ПО ТРЕБОВАНИЮ
МОНИТОРИНГ СЕТИ И ИДЕНТИФИКАЦИЯ АБОНЕНТА В РЕАЛЬНОМ МАСШТАБЕ ВРЕМЕНИ С ПОМОЩЬЮ УСТРОЙСТВА, СРАБАТЫВАЮЩЕГО ПО ТРЕБОВАНИЮ
Источник поступления информации: Роспатент
+ добавить свой РИД