Локализованное выявление перегрузки

Локализованное выявление перегрузки

Иллюстрации

Показать все

Реферат

ПЕРЕКРЕСТНАЯ ССЫЛКА НА РОДСТВЕННЫЕ ЗАЯВКИ

Эта заявка испрашивает приоритет предварительной заявки на патент США № 61/378,980, поданной 1 сентября 2010 года, которая включена в настоящий документ посредством ссылки.

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

Варианты осуществления настоящего изобретения относятся к области использования сетей; а более конкретно, к предотвращению перегрузки в области использования сетей.

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

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

Явное уведомление о перегрузке (ECN) является известной схемой избегания перегрузок, которая предполагает маркирование пакетов вместо их отбрасывания, в случае начинающейся перегрузки. Объект сети, поддерживающий ECN, испытывая начинающуюся перегрузку, может маркировать поля ECN в заголовке пакетов, чтобы указать, что наблюдается перегрузка, вместо того, чтобы отбрасывать пакеты. Для примера, ECN может использовать два наименее значащих бита в поле DiffServ в заголовке IP-протокола (IPv4 или IPv6), которые назначены полю ECN, чтобы кодировать четыре разные кодовые точки ECN. Кодовая точка ECN, равная 00, может указывать транспорт без возможности ECN (то есть, не ECT), если конечная точка не поддерживает или не желает поддерживать транспорт с возможностью ECN. Любая из двух кодовых точек ECN, а именно 10 или 01 (ECT(0) и ECT(l) соответственно), может указывать транспорт с возможностью ECN (ECT).

Кодовая точка ECN, равная 11, может указывать, что была испытана или встречена перегрузка (ECN-CE). К примеру, узел или очередь с возможностью ECN могут вероятностно установить поле ECN равным 11, если перегрузка встречается или испытывается, и затем переслать ECN-маркированный пакет. Чтобы избежать тяжелой перегрузки, маршрутизаторы и другие объекты сети могут маркировать пакеты с вероятностью, зависящей от средней длины очереди. Примеры подходящих протоколов для задания обратной связи для ECN включают в себя TCP, DCCP, SCTP и RTP/UDP. Процентное или количественное отношение маркированных пакетов может указывать и прямо относиться к уровню перегрузки в сети. В ECN конечный приемник ECN-маркированных пакетов может вернуть обратную связь или информацию о процентном или количественном отношении маркированных пакетов или уровне перегрузки отправителю с целью уведомить отправителя о том, что сеть испытывает перегрузку. Ожидается, что отправитель снизит свою скорость передачи, чтобы будущие пакеты не отбрасывались. Предпочтительно, ECN может помочь снизить объем перегрузки в сети и число отбрасываемых пакетов.

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

Re-ECN является известной реализацией выявления перегрузок. Re-ECN описан в проекте Интернет-документа Рабочей группы транспортной области Инженерного совета Интернета (IETF), озаглавленном "Re-ECN: Adding Accountability for Causing Congestion to TCP/IP" (Добавление отслеживаемости вызываемых перегрузок в TCP/IP), авторы Bob Briscoe и другие, датированном 25 Октября 2010 года, страницы 1-51. Протокол re-ECN предусматривает поле в каждом пакете, так что когда пакет пересекает любой интерфейс в межсетевом взаимодействии, он несет верный прогноз перегрузки на остатке его маршрута.

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

Фиг. 1 иллюстрирует примерный вариант осуществления локализованного выявления перегрузок сотовой сети связи стандарта долгосрочного развития (LTE) Проекта партнерства третьего поколения (3GPP).

Фиг. 2 является примерным вариантом осуществления внешних и внутренних IP-заголовков.

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

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

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

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

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

Фиг. 8 иллюстрирует второй примерный вариант осуществления локализованного выявления перегрузок в сотовой сети связи 3GPP LTE, в которой ECN поддерживается на всем протяжении.

Фиг. 9 иллюстрирует третий примерный вариант осуществления локализованного выявления перегрузок в сотовой сети связи 3GPP LTE, в которой как ECN, так и выявление перегрузок поддерживаются на всем протяжении.

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

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

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

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

В настоящее время использование ECN, re-ECN и выявление перегрузки очень ограниченно. Значительно влияющим на это фактором является то, что эти схемы предотвращения перегрузки обычно бывает очень затруднительно развернуть на всем протяжении от конца терминала получателя до конца терминала отправителя сквозь сеть общего пользования, такую как сеть Интернет. Одной причиной сложности реализации полного развертывания на всем протяжении является то, что это обычно требует модификации терминалов получателя и отправителя, таких как сотовые телефоны, смартфоны, дорожные компьютеры, серверы, маршрутизаторы, коммутаторы и так далее, чтобы они поддерживали эти схемы предотвращения перегрузок. К примеру, отправителю необходимо иметь возможность вставлять обратную связь обратно в сеть связи при выявлении перегрузки. Это обычно требует поддержки, к примеру, со стороны стеков протокола управления передачей (TCP)/Интернет протокола (IP) в интересующей операционной системе (например, Linux, Windows и так далее для серверов и Android, Windows mobile и так далее для сотовых телефонов). Однако существует большое число разных производителей/ поставщиков подобных оконечных терминалов и сложно убедить всех этих производителей/поставщиков согласиться с тем, чтобы оконечные терминалы имели поддержку этих схем предотвращения перегрузок.

Другая причина того, что сложно достичь полного развертывания на всем протяжении, состоит в том, что производители маршрутизаторов для Интернета проявляют нежелание модифицировать свои маршрутизаторы для поддержки ECN и выявления перегрузки. Для того чтобы поддерживать ECN и выявление перегрузки, маршрутизаторы вдоль маршрута связи, особенно на линиях, являющихся узкими местами, должны маркировать поле ECN, чтобы обозначить перегрузку, и если они не делают этого, ECN может не работать должным образом. Более того, является обычным иметь промежуточные обработчики (middleboxes), такие как межсетевые экраны (брандмауэры) или системы детектирования проникновения (IDS), размещенные на маршруте. Структура выявления перегрузки должна быть такой, чтобы эти промежуточные обработчики не очищали маркеры ECN или информацию выявления перегрузки. Это сложно обеспечить, поскольку промежуточные обработчики могут принадлежать разным объектам управления сетью связи. По вышеупомянутым причинам, является разумным предположить, что развертывание выявления перегрузки, которое работает на всем протяжении, будет затруднительными и займет значительное время.

Способы и устройство для локализованного выявления перегрузки раскрываются в настоящем документе. Термин "локализованное выявление перегрузки" должен охватывать локализованное re-ECN. К примеру, вариант осуществления локализованного re-ECN также является вариантом осуществления локализованного выявления перегрузки. В локализованном выявлении перегрузки информация выявления перегрузки является локализованной, а не только сквозной (т.е. на всем протяжении). Преимуществом локализованного выявления перегрузки является локальность. Локализованное выявление перегрузки применимо, к примеру, когда невозможно или нецелесообразно обеспечить выявление перегрузки на всем протяжении, и может, к примеру, применяться на конкретном маршруте. Все предыдущие предложения по выявлению перегрузки были сделаны исключительно на сквозной основе (на всем протяжении) и, как отмечалось выше, требуют модификации оконечных хостов для поддержки выявления перегрузки. Это может создать препятствия в развертывании для перехода на протокол с выявлением перегрузки. Новое локализованное выявление перегрузки устраняет подобные ограничения. Локализованное выявление перегрузки может обеспечить значительное управление ресурсами без какой-либо модификации оконечных хостов. Поскольку число узлов инфраструктуры при локализованном выявлении перегрузки обычно намного меньше, чем число оконечных хостов, и узлы инфраструктуры могут находиться под управлением одного и того же объекта администрирования сети, затраты на развертывание могут быть значительно сокращены. При этом выявление перегрузки на всем протяжении может быть неэффективным, поскольку возможность ECN может быть обнулена, или заголовки расширения IPv6 могут быть удалены промежуточными обработчиками на маршруте, но этой проблемы можно избежать или, по меньшей мере, сделать ее более управляемой при локализованном выявлении перегрузки. Кроме того, подход с локальным выявлением перегрузки, раскрываемый в настоящем документе, может внедряться постепенно и может служить естественным трамплином к выявлению перегрузки на всем протяжении, после того как он будет широко внедрен.

Фиг. 1 иллюстрирует примерный вариант осуществления локализованного выявления перегрузки в сотовой сети 100 связи стандарта долгосрочного развития (LTE) Проекта партнерства третьего поколения (3GPP). Локализованное выявление перегрузки является полезным и применимым в сетях связи LTE. В этом примерном варианте осуществления ни ECN, ни выявление перегрузки не поддерживается на оконечном хосте. Это, вероятно, будет являться преобладающим случаем на начальном этапе.

Иллюстрация изображает пример архитектуры LTE сотовой сети 100 связи и маршрут плоскости передачи данных для трафика данных в сотовой сети связи 3GPP LTE. Базовая станция сети связи LTE называется eNodeB 103. Следует понимать, что могут существовать другие базовые станции (не показанные) в данной сети. Данный eNodeB используют для осуществления текущих беспроводных соединений 102 между пользовательскими устройствами или оборудованием 101 и сетью связи. Полезная нагрузка пользовательских данных (пакеты Интернет протокола (IP)) от/к пользовательскому оборудованию обрабатывается двумя логическими узлами, называемыми обслуживающим шлюзом (Serving-GW или S-GW) 105 и шлюзом сети с коммутацией пакетов (PDN-GW) 106. Обслуживающим шлюзом заканчивается интерфейс S1-U плоскости пользователя в сторону eNodeB. Обслуживающий шлюз также буферизует IP-пакеты нисходящей линии связи, предназначенные для пользовательского оборудования 101, что имеет место в режиме ожидания. PDN-GW служит шлюзом в направлении Интернета 108. PDN-GW является точкой соединения с внешними IP сетями связи (например, сетью Интернет) через интерфейс SGi. PDN-GW также включает в себя функциональные возможности для назначения IP адресов, тарификации, фильтрации пакетов и управления потоками на основании политик. S-GW и PDN-GW являются согласно LTE логически раздельными объектами, но следует понимать, что они могут быть физически расположены в одной или нескольких физических системах.

S-GW и PDN-GW являются составными частями Эволюции Системной Архитектуры (SAE), которая представляет собой ядро сетевой архитектуры LTE. Основной компонент или ядро SAE известен как ядро SAE или Развитое Пакетное Ядро (EPC). Показанная архитектура LTE также включает в себя первый маршрутизатор 104 между eNodeB и S-GW и второй маршрутизатор 107, подключающий PDN-GW к Интернету. Следует понимать, что сеть связи может включать в себя большее или меньшее число маршрутизаторов (например, больше маршрутизаторов между базовой станцией и S-GW, один или несколько маршрутизаторов между S-GW и PDN-GW, больше маршрутизаторов между PDN-GW и Интернет, и так далее). Первый маршрутизатор 104, eNodeB, S-GW, PDN-GW обычно принадлежат и управляются одним и тем же объектом оператора сети. Интернет включает в себя маршрутизаторы, из которых для простоты показан только третий маршрутизатор 109. Источник или сервер 110 соединены с сотовой сетью связи через Интернет.

В примере инфраструктуры LTE, как показано на Фиг. 1, перегрузка может случиться во многих местах, таких как eNodeB (наиболее вероятно), S-GW, PDN-GW и маршрутизаторах и коммутаторах на маршруте. В последнее время произошло значительное увеличение в трафике данных в сотовых сетях связи, отчасти из-за нисходящей загрузки видеоданных и тому подобного. В сценарии нисходящей загрузки пользовательское устройство (например, сотовый телефон) 101 загружает содержимое (например, потоковое видео) с сервера или источника 110. На иллюстрации сценарий нисходящей загрузки является примерным, поскольку объем трафика в направлении нисходящей загрузки обычно намного больше, чем в восходящем направлении. В результате сценарии нисходящей загрузки с большей вероятностью вызовут перегрузку из-за больших объемов трафика, и в этом случае локализованное выявление перегрузки имеет большее преимущество. Как будет описано дополнительно ниже, сходная установка может быть сделана для сценариев восходящей загрузки, хотя преимущества локализованного выявления перегрузки здесь могут быть не очевидны, если только, или пока, объем трафика в восходящем направлении не увеличится до точки, которая вызовет перегрузку (например, если пользовательское оборудование использует видео-телефонию, посылает видео или другим способом посылает большие объемы данных).

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

В показанном варианте осуществления базовая станция или eNodeB служит в качестве принимающего узла выявления перегрузки, а PDN-GW служит в качестве посылающего узла выявление перегрузки. Узлы на маршруте между PDN-GW и eNodeB (например, как показано, S-GW, eNodeB и первый маршрутизатор 104 между S-GW и eNodeB) могут маркировать биты ECN пакетов, чтобы указать, что испытывается перегрузка ("Маркирование бита 113 ECN"). Базовая станция или eNodeB может предоставлять обратную связь, в зависимости от указателей ECN в пакетах, чтобы указать уровень перегрузки, испытываемый пакетами ("Маркирование обратной связи 111 ECN"). PDN-GW может принимать эту обратную связь и повторно вставлять обратную связь или информацию о перегрузке обратно в сеть связи как информацию выявления перегрузки или re-ECN ("Повторное вставление обратной связи 112"). Выявление перегрузки кодирует уведомление о перегрузке в заголовки данных. Пакеты, посланные от PDN-GW, могут нести правильный прогноз об условиях перегрузки на оставшейся части из маршрута.

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

В сотовой сети связи LTE, пакеты между узлом PDN-GW и узлом eNodeB (базовой станцией сети связи LTE) туннелируют через протокол туннелирования (GTP) общей службы пакетной радиопередачи (GPRS). GTP является протоколом передачи, чтобы доставлять данные для протокола полезной нагрузки. GTP является протоколом туннелирования через протокол пользовательских дейтаграмм (UDP)/Интернет протокол (IP). GTP может быть использован как с UDP, так и с TCP. UDP и TCP относятся к транспортному слою или уровню. Транспортный слой или уровень является более высоким слоем или уровнем, чем IP. IP является слоем или уровнем в сети Интернет. Кроме того, GTP логически находится выше, чем UDP. Маршрут GTP идентифицируют в каждом узле по IP адресу и номеру порта UDP. Протокол GTP включает в себя как трафик данных (GTP-U), так и управляющий трафик (GTP-C). То есть трафик плоскости пользователя или маршрут между PDN-GW и eNodeB туннелируют через GTP-U (U обозначает плоскость пользователя) туннели, и отдельный протокол GTP-C существует для сигнализации управления. Это сильно отличается от сквозного маршрута в Интернете, где пересылка пакетов выполняется на IP уровне.

В показанном варианте осуществления данного изобретения выявление перегрузки развернуто на GTP-U маршруте между PDN-GW и eNodeB. То есть GTP-U маршрут поддерживает выявление перегрузки. Реализация локализованного выявления перегрузки на более высоком уровне GTP облегчает реализацию. Эти протоколы туннелирования дают оператору большую степень гибкости в управлении механизмом перегрузки, встроенным в протоколы GTP. Существующий GTP туннель является протоколом туннелирования на основе UDP без каких-либо механизмов предотвращение перегрузок. Поддержка ECN на данном маршруте в настоящее время неопределенна, но относительно ясна. Ссылка может быть сделана на ECN для общего туннелирования IP-через-IP.

Фиг. 2 является примерным вариантом осуществления внешнего IP заголовка 215 и внутреннего IP заголовка 216. Внешний IP заголовок содержит маркеры (CEo) 217 встречающейся или испытываемой внешней перегрузки. Внутренний IP заголовок содержит маркеры (CEi) 218 встречающейся или испытываемой внутренней перегрузки. Реализация поддержки ECN в туннелях GTP-U может включать в себя внешний IP заголовок, указанный как имеющий возможность ECN. Подобная поддержка маркировки ECN в GTP туннелировании предполагается новой. В одном аспекте, ECN-CE маркировка во внешнем IP заголовке может не быть скопирована во внутренний IP заголовок на выходе из туннеля, если внутренний заголовок не имеет возможности ECN. В одном аспекте, протокол GTP-U может использовать необязательный порядковый номер, чтобы сделать отчеты обратной связи надежными.

Фиг. 3 является блок-схемой примерного варианта осуществления способа 320 для локализованного выявления перегрузки в пределах локального контура в сотовой сети связи, выполняемого принимающим узлом локализованного выявления перегрузки данного локального контура. В одном варианте осуществления принимающий узел локализованного выявления перегрузки может быть eNodeB или другой базовой станцией.

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

В одном варианте осуществления пакеты нисходящей линии связи при получении могут иметь внешние заголовки, которые указывают транспорт с возможностью ECN, и внутренние заголовки, которые указывают транспорт без возможности ECN. В одном варианте осуществления пакеты нисходящей линии связи могут быть приняты через туннель, который не является туннелем IP-через-IP, и внешний заголовок пакетов нисходящей линии связи при получении может указывать транспорт с возможностью ECN. В одном аспекте туннель может быть туннелем туннельного протокола (GTP) общей службы пакетной радиопередачи (GPRS) и уровень ожидаемой перегрузки в нисходящем направлении, объявленный вышестоящим узлом, может быть указан в GTP заголовках пакетов нисходящей линии связи, принятых через GTP туннель.

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

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

eNodeB может собирать маркеры ECN-CE и предоставлять обратную связь в PDN-GW. Более того, планировщики в eNodeB являются вероятными точками, в которых может встречаться перегрузка. Другими точками может быть очередь в уровне управления радиоканалами (RLC) с алгоритмом активного управления очередью (AQM). Поскольку для внутреннего IP заголовка не обеспечена возможность ECN, пакеты могут быть отброшены при указании перегрузки. Эта информация о перегрузке также может быть передана по обратной связи в PDN-GW. В одном аспекте, эта информация о перегрузке может быть объединена (например, логически ORed) с маркерами ECN-CE во внешнем IP заголовке (CEi || CEo на Фиг. 2). Возможный интервал между отчетами может соответствовать одному отчету за каждый период кругового обращения сообщения (RTT) или, возможно, более редко. В одном варианте осуществления, обратная связь может обеспечиваться поточно, например, через биты кодовых точек ECN, распределенных по нескольким или многим пакетам.

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

(a) порядковый номер последнего принятого пакета 425;

(b) общее число принятых (eNodeB или базовой станцией) пакетов 426;

(c) общее число пакетов, отброшенных eNodeB или базовой станцией (например, в планировщике или AQM) 427;

(d) общее число пакетов, маркированных ECN-CE eNodeB или базовой станцией (например, в планировщике или AQM) 428;

(e) общее число пакетов, отброшенных узлами до eNodeB (GTP-U туннелированных пакетов) 429;

(f) общее число пакетов, маркированных ECN-CE узлами до eNodeB или базовой станции (GTP-U туннелированных пакетов) 430;

(g) список маркированных и/или отброшенных пакетов 431, который может быть полезен для вычисления величины перегрузки (суммы размеров маркированных или отброшенных пакетов).

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

Таким образом, eNodeB или базовая станция может обеспечивать обратную связь и служить в качестве принимающего узла в выявлении перегрузки/развертывании ECN. Преимущественно, различные виды информации, упомянутые выше, которые могут быть уже известны eNodeB или базовой станцией, могут не быть известны или уже быть известны сотовому телефону или другому пользовательскому оборудованию. Некоторая информация является тайной, внутренней или известной только базовой станции. К примеру, базовая станция обычно может знать или быть способной вычислить виды информации, перечисленные в (b), (c), (d), (e) или (f), но сотовый телефон или другое пользовательское оборудование может не знать или не иметь возможности распознать эти виды информации. К примеру, рассматривая виды информации, перечисленные в (c) и (e), базовая станция может знать или быть способной вычислить общее число пакетов, отброшенных ею, и общее число пакетов, отброшенных узлами до базовой станции (например, анализируя порядковые номера пакетов, чтобы увидеть, какие из них были потеряны). Однако сотовый телефон или другое пользовательское оборудование может быть способным только знать или вычислить общее число пакетов, отброшенных до сотового телефона, но может не быть способным отличить те из этих пакетов, которые были отброшены до базовой станции, от тех пакетов, которые были отброшены базовой станцией.

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

Фиг. 5 является функциональной схемой примерного варианта осуществления принимающего узла 503 локал