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

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

Info

Publication number
RU2590917C2
RU2590917C2 RU2013114385/07A RU2013114385A RU2590917C2 RU 2590917 C2 RU2590917 C2 RU 2590917C2 RU 2013114385/07 A RU2013114385/07 A RU 2013114385/07A RU 2013114385 A RU2013114385 A RU 2013114385A RU 2590917 C2 RU2590917 C2 RU 2590917C2
Authority
RU
Russia
Prior art keywords
congestion
packets
node
downlink packets
localized
Prior art date
Application number
RU2013114385/07A
Other languages
English (en)
Other versions
RU2013114385A (ru
Inventor
Ин Чжан
Ингемар ЙОХАНССОН
Говард ГРИН
Original Assignee
Телефонактиеболагет Л М Эрикссон (Пабл)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Телефонактиеболагет Л М Эрикссон (Пабл) filed Critical Телефонактиеболагет Л М Эрикссон (Пабл)
Publication of RU2013114385A publication Critical patent/RU2013114385A/ru
Application granted granted Critical
Publication of RU2590917C2 publication Critical patent/RU2590917C2/ru

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2483—Traffic characterised by specific attributes, e.g. priority or QoS involving identification of individual flows
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0205—Traffic management, e.g. flow control or congestion control at the air interface
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/10—Flow control between communication endpoints
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/11—Identifying congestion
    • H04L47/115—Identifying congestion using a dedicated packet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/127—Avoiding congestion; Recovering from congestion by using congestion prediction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/26—Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0231—Traffic management, e.g. flow control or congestion control based on communication conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0231—Traffic management, e.g. flow control or congestion control based on communication conditions
    • H04W28/0242—Determining whether packet losses are due to overload or to deterioration of radio communication conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0247—Traffic management, e.g. flow control or congestion control based on conditions of the access network or the infrastructure network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0284—Traffic management, e.g. flow control or congestion control detecting congestion or overload during communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/10—Flow control between communication endpoints
    • H04W28/12—Flow control between communication endpoints using signalling between network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/04—TPC
    • H04W52/30—TPC using constraints in the total amount of available transmission power
    • H04W52/34—TPC management, i.e. sharing limited amount of power among users or channels or data types, e.g. cell loading
    • H04W52/343—TPC management, i.e. sharing limited amount of power among users or channels or data types, e.g. cell loading taking into account loading or congestion level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/22—Traffic shaping
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/2592—Translation of Internet protocol [IP] addresses using tunnelling or encapsulation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0289—Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04—Large scale networks; Deep hierarchical networks
    • H04W84/042—Public Land Mobile systems, e.g. cellular systems

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

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

Description

ПЕРЕКРЕСТНАЯ ССЫЛКА НА РОДСТВЕННЫЕ ЗАЯВКИ
Эта заявка испрашивает приоритет предварительной заявки на патент США № 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 локализованного выявления перегрузки, выполненного с возможностью локализованного выявления перегрузки в пределах локального контура в сотовой сети связи. В одном варианте осуществления принимающий узел локализованного выявления перегрузки может быть eNodeB или другой базовой станцией.
Принимающий узел локализованного выявления перегрузки имеет первый интерфейс 535, выполненный с возможностью принимать пакеты 536 нисходящей лини связи, предназначенные нижестоящему пользовательскому устройству через соединение 537. Пакеты нисходящей линии связи имеют заголовки, которые указывают уровень перегрузки, испытываемый пакетами нисходящей линии связи (например, маркеры ECN-CE или другие указатели того, что перегрузка была встречена или испытана). Заголовки также указывают уровень ожидаемой перегрузки в нисходящем направлении, объявленный вышестоящим узлом (например, информация re-ECN или другая информация выявления перегрузки).
В одном варианте осуществления пакеты нисходящей линии связи при получении могут иметь внешние заголовки, которые указывают транспорт с возможностью ECN, и внутренние заголовки, которые указывают транспорт без возможности ECN. В одном варианте осуществления пакеты нисходящей линии связи могут быть приняты через туннель, который не является туннелем IP-через-IP, и внешний заголовок пакетов нисходящей линии связи при получении может указывать транспорт с возможностью ECN. В одном аспекте данный туннель может быть туннелем протокола туннелирования (GTP) Общей службы пакетной радиопередачи (GPRS) и уровень ожидаемой перегрузки в нисходящем направлении, объявленный вышестоящим узлом, может быть указан в GTP и/или внешних IP заголовках пакетов нисходящей линии связи, принятых через туннель GTP. В одном аспекте уровень ожидаемой перегрузки в нисходящем направлении может передаваться в расширениях IP заголовка. В другом аспекте, уровень ожидаемой перегрузки в нисходящем направлении может передаваться с использованием битов из поля метки потока в IPv6 заголовке.
Принимающий узел локализованного выявления перегрузки имеет второй интерфейс 538, выполненный с возможностью посылать пакеты нисходящей линии связи 539 нижестоящему пользовательскому устройству через беспроводное соединение 540. В одном варианте осуществления, к примеру, когда нижестоящее пользовательское устройство не поддерживает выявление перегрузки, пересылаемые пакеты нисходящей линии связи могут не указывать уровень ожидаемой перегрузки в нисходящем направлении, объявленный вышестоящим узлом.
Принимающий узел локализованного выявления перегрузки имеет модуль 541 вставки обратной связи, чтобы вставлять обратную связь, указывающую уровень перегрузки, испытываемый пакетами нисходящей линии связи, в пакеты 542, которые посылаются в восходящем направлении через первый интерфейс. Модуль вставки обратной связи может вставлять обратную связь, включающую в себя один или несколько видов информации, показанных на Фиг. 4. Модуль вставки обратной связи может быть реализован в программном, программно-аппаратном или аппаратном обеспечении (например, схемах) или их сочетании.
В одном варианте осуществления, контур локализованного выявления перегрузки может включать в себя отбрасыватель 543 (например, отбрасыватель краев на выходе) или другой предохранитель на выходе, чтобы предотвратить или противодействовать преуменьшению ожидаемой перегрузки в нисходящем направлении. В одном аспекте отбрасыватель или предохранитель может быть внедрен на последнем сетевом выходе, хотя это не обязательно.
Локализованное выявление перегрузки, как в инфраструктуре re-ECN, может определять положительные и отрицательные потоки, которые означают потоки, где скользящее среднее показателя перегрузки в нисходящем направлении постоянно является положительным или отрицательным. Негативный поток является потоком, который имеет больше маркированных пакетов о встречающейся или испытываемой (CE) перегрузке, чем объявил или заявил отправитель. В положительных потоках объявленная или заявленная перегрузка больше, чем ее действительный уровень. Наличие отрицательного потока или показателя может возникнуть, поскольку оно получается путем вычитания действительного уровня перегрузки из объявленного или заявленного уровня перегрузки.
Предохранитель или отбрасыватель 543 может отбрасывать пакеты в потоках, которые становятся негативной перегрузкой в нисходящем направлении, то есть, если вызванная ими в действительности перегрузка выше, чем заявленная или объявленная. Когда трафик покидает последний сетевой узел перед приемником, доля положительных октетов в потоке должна равняться доле негативных октетов, внесенных маркированием перегрузки, оставляя баланс нулевым. При позитивном значении отбрасыватель может не принимать мер, подразумевая, что источник медленнее, чем должен быть. Маршрутизатор или отбрасыватель может отбрасывать пакеты в негативных потоках, к примеру, чтобы обеспечить равнодоступность. Преимущественно, это может способствовать обеспечению того, чтобы перегрузка объявлялась честно и чтобы скорость передачи отправителя реагировала должным образом. Более того, в качестве опции, отбрасыватель может быть пропущен, к примеру, если маршрут между PDN-GW и eNodeB является надежным.
Подход локализованного выявления перегрузки вводит необходимость средств поощрения (например, способов «кнута и пряника») для источников, чтобы обеспечить такое их поведение, что чрезмерная перегрузка может быть предотвращена. Это может привести к более стабильному качеству пользования сети Интернет для всех пользователей. В одном аспекте подход локализованного выявления перегрузки может быть нейтральным к сети, таким, чтобы не выносить решений на основании вида трафика (например, видео по запросу (VoD), одноранговый (p2p), и так далее.), вместо этого, подход локализованного выявления перегрузки заботится только о величине перегрузки, которую вызывает трафик, хотя объем данного изобретения не ограничен в этом отношении.
Ссылаясь снова на Фиг. 5, в одном варианте осуществления базовая станция или eNodeB могут иметь маркировщик ECN или другой маркировщик 544 встречающейся/испытываемой перегрузки. Маркировщик ECN может маркировать поле ECN пакетов (например, маркировать ECN-CE). Альтернативно, в другом варианте осуществления, базовая станция или eNodeB не обязательно могут иметь маркировщик ECN. К примеру, базовая станция или eNodeB могут знать, какие пакеты они должны ECN-маркировать, и могут встраивать такие пакеты в обратную связь, не ECN-маркируя их.
В одном варианте осуществления примерный вариант осуществления принимающего узла локализованного выявления перегрузки на Фиг. 5 может выполнять примерный вариант осуществления действий и способа на Фиг. 3. Однако следует понимать, что действия и способ на Фиг. 3 могут выполняться альтернативными вариантами осуществления данного изобретения, отличающимися от варианта, описанного со ссылкой на Фиг. 5. Кроме того, принимающий узел локализованного выявления перегрузки на Фиг. 5 может выполнять другие действия и способы, отличные от тех, что показаны на Фиг. 3.
Фиг. 6 является блок-схемой примерного варианта осуществления способа 648 для локализованного выявления перегрузки в пределах локального контура в сотовой сети связи, выполняемого посылающим узлом локализованного выявления перегрузки локального контура. В одном варианте осуществления посылающим узлом локализованного выявления перегрузки может быть шлюз сотовой сети связи (например, PDN-GW или S-GW). Альтернативно, посылающим узлом локализованного выявления перегрузки может быть маршрутизатор.
Способ включает в себя прием пакетов нисходящей линии связи, предназначенных нижестоящему пользовательскому устройству, на этапе 649. В одном варианте осуществления, к примеру, когда оконечный терминал не поддерживает выявление перегрузки, пакеты нисходящей линии связи при получении могут не иметь объявления ожидаемой перегрузки в нисходящем направлении (например, в них может не быть информации re-ECN или другой информации выявления перегрузки). В одном варианте осуществления пакеты нисходящей линии связи при получении могут иметь заголовки, которые указывают транспорт без возможности ECN.
Способ включает в себя прием пакетов, имеющих обратную связь, указывающую уровень перегрузки от нижестоящего узла сотовой сети связи, на этапе 650. В одном варианте осуществления обратная связь может включать в себя любой один или несколько видов информации, показанных на Фиг. 4. Возможные примеры подобной информации могут включать в себя одно или несколько из общего количества пакетов, отброшенных базовой станцией, общего количества пакетов, отброшенных узлами до базовой станции, общего количества пакетов ECN-CE-маркированных базовой станцией, общего количества пакетов, ECN-CE-маркированных узлами до базовой станции, и так далее.
Способ включает в себя вставку объявления уровня ожидаемой перегрузки в нисходящем направлении в заголовки принимаемых пакетов нисходящей линии связи на этапе 651. В одном варианте осуществления информация объявления или заявки ожидаемой перегрузки в нисходящем направлении может включать в себя информацию re-ECN или другую информацию выявления перегрузки. Следует понимать, что объем изобретения не ограничен в отношении объявляемого или заявляемого уровня ожидаемой перегрузки в нисходящем направлении тем, чтобы он точно соответствовал действительному уровню (например, объявляемый или заявляемый уровень перегрузки может быть ложным, не ограничивая объем изобретения).
Способ включает в себя пересылку пакетов нисходящей линии связи, имеющих объявление уровня ожидаемой перегрузки в нисходящем направлении, вставленное в их заголовки, по направлению к нижестоящему пользовательскому устройству, на этапе 652. В одном варианте осуществления пакеты нисходящей линии связи могут пересылаться через туннель, который не является IP-через-IP туннелем, а внешний заголовок пакетов нисходящей линии связи при пересылке может указывать на транспорт с возможностью ECN. В одном аспекте, туннель может быть GTP туннелем, и объявление уровня ожидаемой перегрузки в нисходящем направлении может быть указано в GTP заголовках пакетов нисходящей линии связи. В одном варианте осуществления PDN-GW может повторно вставлять информацию о перегрузке в GTP-U заголовки.
Фиг. 7 является функциональной схемой примерного варианта осуществления посылающего узла 706 локализованного выявления перегрузки, выполненного с возможностью локализованного выявления перегрузки в пределах локального контура в сотовой сети связи. Посылающий узел локализованного выявления перегрузки расположен в локальном контуре между базовой станцией и сетью Интернет. В одном варианте осуществления посылающим узлом локализованного выявления перегрузки может быть шлюз сотовой сети связи (например, PDN-GW или S-GW). Альтернативно, посылающим узлом локализованного выявления перегрузки может быть маршрутизатор.
Посылающий узел локализованного выявления перегрузки имеет первый интерфейс 755, выполненный с возможностью принимать пакеты 756 нисходящей линии связи, предназначенные нижестоящему пользовательскому устройству, через первое соединение 757. В одном варианте осуществления, к примеру, когда оконченный терминал не поддерживает выявление перегрузки, данный интерфейс может принимать пакеты нисходящей линии связи, которые не имеют объявления ожидаемой перегрузки в нисходящем направлении (например, в них может не быть информации re-ECN или другой информации выявления перегрузки). В одном варианте осуществления данный интерфейс может принимать пакеты нисходящей линии связи, которые имеют заголовки, указывающие транспорт без возможности ECN.
Посылающий узел локализованного выявления перегрузки имеет второй интерфейс 758, выполненный с возможностью принимать пакеты 759, которые имеют обратную связь, указывающую уровень перегрузки от нижестоящего узла сотовой сети связи, через второе соединение 760. В одном варианте осуществления, второй интерфейс может принимать обратную связь, которая может включать в себя любой один или несколько видов информации, показанных на Фиг. 4.
Посылающий узел локализованного выявления перегрузки имеет модуль 761 вставки выявления перегрузки, выполненный с возможностью вставлять объявления об уровне ожидаемой перегрузки в нисходящем направлении в заголовки принятых пакетов 762 нисходящей линии связи. В одном варианте осуществления модуль вставки выявления перегрузки может вставлять информацию об объявлении или заявлении ожидаемой перегрузки в нисходящем направлении, которая включает в себя информацию re-ECN или другую информацию выявления перегрузки. Модуль вставки выявления перегрузки может быть реализован в программном, программно-аппаратном, аппаратном обеспечении (например, схемах) или их сочетании. Посылающий узел выполнен с возможность пересылать пакеты нисходящей линии связи, имеющие объявление уровня ожидаемой перегрузки в нисходящем направлении, вставленное в их заголовки, в направлении нижестоящего пользовательского устройства.
Для обеспечения честного маркирования сеть связи может включать в себя несколько объектов, чтобы помочь обеспечить корректное поведение. Один объект является объектом управления перегрузкой источника. Отправитель может уменьшать свою скорость передачи, по мере увеличения перегрузки в нисходящем направлении, с помощью некоторой версии дружественной к TCP реакции на перегрузку. Как было описано ранее, сотовая сеть связи может иметь отбрасыватель краев на выходе. Более того, в одном варианте осуществления сотовая сеть связи может иметь ограничитель входа (средство ограничения на основе политик). Протоколы Re-ECN и выявления перегрузки обеспечивают, чтобы пакеты несли информацию об их собственной ожидаемой перегрузке в нисходящем направлении. В одном варианте осуществления PDN-GW или маршрутизатор доступа может применять ограничитель на своих входах, чтобы проверять, что источник соответствует управлению перегрузкой, которую он должен использовать. Ограничитель может отбрасывать пакеты или останавливать потоки для агрессивных потоков/пользователей на входе, чтобы помочь избежать бесполезного расходования ресурсов в нисходящем направлении. Как показано, в одном варианте осуществления, PDN-GW может необязательно иметь ограничитель 763. Альтернативно, другой компонент (например, маршрутизатор доступа или маршрутизатор первого транзитного участка, соединяющий PDN-GW с сетью Интернет) может иметь подобный ограничитель.
Это ограничение (например, осуществляемое посредством PDN-GW) может выполняться на основе «по потоку» или «по пользователю». В качестве примера, чтобы обеспечить уверенность в том, что поток, пользователь или набор потребителей не создадут больше перегрузки в сети связи, чем их надлежащая квота, модифицированный групповой сегмент записей жетонов может поддерживаться для назначения ресурсов постепенно по времени. Жетоны могут представлять собой величину перегрузки, которую позволено потребить каждому пользователю в сети связи. Модифицированный групповой сегмент записей жетонов может иметь параметры, такие как начальный уровень жетонов, скорость заполнения и глубина сегмента записей. Весь трафик от пользователя за время действия его подписки может быть ограничен одним и тем же сегментом записей жетонов. Подобный модифицированный групповой сегмент записей жетонов не является обязательным. Альтернативно, другие подходы для представления величины перегрузки, которую позволено потребить каждому пользователю в сети связи, и/или для назначения сетевых ресурсов могут быть использованы вместо него, например, различные виды скользящего среднего значения или подходы, известные для re-ECN или выявления перегрузки.
PDN-GW или ограничитель может применять ограничение на потоках, в зависимости от предпочтений оператора. Так, например, PDN-GW или ограничитель может отбрасывать пакеты на входе для источников, которые вызывают больше чем 1% доли ECN или величины перегрузки, к примеру. Доля ECN может представлять собой число маркированных ECN-CE пакетов, деленное на общее число пакетов. Это значение обычно вычисляют относительно окна передачи переменной длительности, например относительно последних 100 пакетов. Как другой пример, более дружественным действием является снабжение поставщиков содержимого обратной связью о том, как сильно их услуги перегружают сети связи.
Ссылаясь снова на Фиг. 7, PDN-GW также включает в себя необязательный анализатор 764 обратной связи, чтобы анализировать обратную связь. Анализатор обратной связи может быть реализован в программном, программно-аппаратном, аппаратном обеспечении или их сочетании. PDN-GW получает обратную связь или информацию о перегрузке (например, виды информации, показанные на Фиг. 4) от базовых станций или eNodeB. PDN-GW или анализатор обратной связи может на основании этой информации детектировать или находить одно или несколько из нижеследующего:
(a) находить вредоносные потоки;
(b) находить неправильно ведущих себя пользователей;
(c) находить агрессивные источники трафика; и/или
(d) более легко находить перегруженные места в сети связи.
Детектирование может быть реализовано посредством хранения статистического значения ECN-маркированных пакетов. Как пример возможных действий, PDN-GW может замечать, если несколько пользователей подключены к конкретному источнику (например, популярной услуги видео по запросу (VoD)), что все эти потоки вызывают очень высокую долю ECN. Тогда, возможно, источнику требуется улучить свои алгоритмы управления перегрузкой. Другим интересным случаем является случай, когда один пользователь получает данные из многих источников и демонстрирует высокую общую долю ECN. Тогда, возможно, что этот пользователь является объектом распределенной атаки отказа в обслуживании (DDoS). Оба эти два сценария могут быть детектированы посредством мониторинга доли маркирования ECN в PDN-GW.
Если взять случай использования нисходящей загрузки, может быть заманчивым реализовать ECN и некоторый вид ограничения только в eNodeB, что является одной из опций для варианта осуществления данного изобретения. Однако одним потенциальным недостатком такого подхода является то, что тогда трудно узнать, является ли некий конкретный источник ответственным за перегрузку (например, отказ в обслуживании (DoS) или несоответствующие алгоритмы управления перегрузкой в источнике). Лучше, если eNodeB будет возвращать PDN-GW маркеры ECN, чтобы PDN-GW мог выполнять лучший анализ для локализации неправильно ведущих себя источников на основании групповых данных, и таким образом, принимать лучшие решения об ограничении. Кроме того, приведение в исполнение решений об ограничении на входном транзитном участке, к примеру, PDN-GW, является эффективным способом удержания зловредного трафика от потребления большего количества сетевых ресурсов.
В одном варианте осуществления, S-GW и PDN-GW (например, исходящая очередь) могут иметь возможность ECN. К примеру, каждый из них может иметь маркировщик ECN, который способен устанавливать ECN-CE, чтобы указывать встречающуюся или испытываемую перегрузку во внешнем IP заголовке. В одном аспекте, они могут маркировать пакеты с вероятностью, зависящей от среднего размера очереди. Для кодирования уровня перегрузки в пакет авторам настоящего изобретения требуются маршрутизаторы с возможностью ECN, которые маркируют пакеты, когда случается перегрузка. Маршрутизаторы на маршруте также могут иметь возможность ECN. В одном аспекте, это может быть реализовано совместно с произвольным детектированием перегрузки на раннем этапе (RED), которое широко поддерживается в коммерческих маршрутизаторах. Как показано, изображенный посылающий узел 706 имеет необязательный маркировщик ECN или другой модуль вставки 765 выявления перегрузки. Альтернативно, как показано на Фиг. 1, PDN-GW может находиться за пределами диапазона и не обязательно должен ECN-маркировать пакеты, скорее, это может выполняться другими узлами (например, S-GW, маршрутизаторами и так далее).
В одном примерном варианте осуществления примерный вариант осуществления принимающего узла локализованного выявления перегрузки на Фиг. 7 может выполнять примерный вариант осуществления действий и способа на Фиг. 6. Однако следует понимать, что действия и способ на Фиг. 6 могут выполняться альтернативными вариантами осуществления изобретения, отличающимися от варианта, описанного со ссылкой на Фиг. 7. Кроме того, принимающий узел локализованного выявления перегрузки на Фиг. 7 может выполнять другие действия и способы, отличающиеся от тех, что показаны на Фиг. 6.
Фиг. 8 иллюстрирует второй примерный вариант осуществления локализованного выявления перегрузки в сотовой сети 800 связи 3GPP LTE, в которой ECN поддерживается на всем протяжении. Возможность ECN обеспечена в обеих конечных точках (например, пользовательском оборудовании 801 и источнике 810). Маршрутизаторы сети Интернет также могут поддерживать ECN.
Показанная сотовая сеть связи LTE включает в себя пользовательское оборудование 801, eNodeB 803, имеющий беспроводное соединение 802 с пользовательским оборудованием, первый маршрутизатор 804, S-GW 805, PDN-GW 806. Сотовая сеть связи LTE может быть такой, как описанная ранее, и может иметь любые ранее описанные вариации. Также показаны сеть Интернет 808, второй маршрутизатор 807, третий маршрутизатор 809 и источник 810.
ENodeB выполнен с возможностью ECN. Источник также выполнен с возможностью ECN. ENodeB обеспечивает обратную связь ("обратная связь ECN-маркирования 811") источнику с возможностью ECN. ENodeB, первый маршрутизатор, S-GW, PDN-GW, и маршрутизаторы сети Интернет могут выполнять ECN-маркирование ("Маркирование бита 813 ECN"). PDN-GW может выполнять ограничение. PDN-GW может обеспечивать информацию выявления перегрузки ("Повторная вставка обратной связи 812").
В одном варианте осуществления локализованное выявление перегрузки в сотовой сети связи LTE может быть в первую очередь интересно для защиты трафика, который идет от PDN-GW к eNodeB (или UE). По этой причине, в одном аспекте может рассматриваться только ECN-CE маркирование, которое имеет место в локальной сети связи. Ограничение или ограничитель на входе PDN-GW (или в другом отправителе локализованного выявления перегрузки) может таким образом вычитать измеренную входящую долю ECN (на входе PDN-GW) из переданной обратной связью доли ECN от eNodeB или базовой станции (или другого приемника локализованного выявления перегрузки). Это обеспечит показатель того, насколько поток перегружен на нисходящем маршруте от PDN-GW.
Фиг. 9 иллюстрирует третий примерный вариант осуществления локализованного выявления перегрузки в сотовой сети 900 связи 3GPP LTE, в которой и ECN и выявление перегрузки поддерживаются на всем протяжении. Возможность ECN обеспечена в обеих конечных точках (например, пользовательском оборудовании 901 и источнике 910). Выявление перегрузки также является возможным в обеих конечных точках. Маршрутизаторы сети Интернет также могут поддерживать ECN и выявление перегрузки.
Показанная сотовая сеть связи LTE включает в себя пользовательское оборудование 901, eNodeB 903, имеющий беспроводное соединение 802 с пользовательским оборудованием, первый маршрутизатор 904, S-GW 905, PDN-GW 906. Сотовая сеть связи LTE может быть такой, как описанная ранее, и может иметь любые ранее описанные вариации. Также показаны Интернет 908, второй маршрутизатор 907, третий маршрутизатор 909 и источник 910.
Пользовательское оборудование или устройство с возможностью ECN предоставляют обратную связь ("Обратная связь ECN-маркирования") источнику с возможностью ECN. Источник с возможностью ECN может предоставлять информацию выявления перегрузки ("Повторная вставка обратной связи ") обратно в сеть связи, и она может проходить весь путь до пользовательского оборудования или устройства с возможностью ECN. ENodeB, первый маршрутизатор, S-GW, PDN-GW и маршрутизаторы сети Интернет могут выполнять ECN-маркирование ("Маркирование бита ECN").
PDN-GW может иметь ограничитель. ENodeB может иметь отбрасыватель и может служить в качестве отбрасывателя краев на выходе. Сквозной маршрут (полной протяженности) может быть установлен между пользовательским оборудованием (UE) и серверами поставщика данных, где IP соединение устанавливается поверх оверлейного маршрута поверх eNodeB, S-GW, и так далее. Ограничитель может быть расположен на первом транзитном участке маршрута, находящемся под управлением оператора, то есть PDN-GW. Отбрасыватель расположен на выходе маршрута, в этом примере, на последнем транзитном участке передачи сотового трафика, eNodeB. Он также может быть расположен в S-GW, в зависимости от проблем состязания за обладание ресурсами в сети связи, или на последнем транзитном участке перед eNodeB, к примеру.
Примерные варианты осуществления локализованного выявления перегрузки были показаны и описаны для сотовых сетей связи 3GPP LTE. В данном контексте, термин LTE должен охватывать и будущие версии и выпуски LTE, к примеру, Улучшенный LTE, 4G и так далее. Более того, варианты осуществления способов и устройств для локализованного выявления перегрузки, раскрытые в настоящем документе, могут быть использованы в будущих не-LTE сотовых сетях связи, таких как наследники 3G, LTE, и 4G сотовых сетей связи.
Преимущественно, локализованное выявление перегрузки может достигаться в пределах локального контура в сотовой сети связи, независимо от того, поддерживается или нет выявление перегрузки за пределами локального контура. Преимущественно, один или несколько узлов сотовой сети связи могут использовать информацию локализованного выявления перегрузки для одного или нескольких из: назначения или управления ресурсами, отбрасывания пакетов, поиска вредоносных потоков, поиска неправильно ведущих себя пользователей, удерживания зловредного трафика от потребления большего числа сетевых ресурсов и так далее.
Сценарии нисходящей загрузки, в которых пакеты загружают в пользовательское оборудование из сети Интернет, были приведены для примера, из-за большого объема трафика, испытываемого в настоящее время в нисходящем направлении, к примеру, нисходящих загрузок видеоданных в сотовые телефоны. Однако большой объем трафика также может наблюдаться в восходящем направлении, когда пакеты загружают из пользовательского оборудования (например, сотовых телефонов) в сеть Интернет по пути к другим пользовательским оборудованиям или серверам. К примеру, это может быть в случае видеотелефонии, или когда сотовые телефоны или другое пользовательское оборудование осуществляют восходящую загрузку видеоданных или других больших объемов данных.
Фиг. 10 иллюстрирует примерный вариант осуществления локализованного выявления перегрузки в сотовой сети связи 3GPP LTE для сценария восходящей загрузки, в котором пакеты загружают из пользовательского оборудования в сеть Интернет. Локализованное выявление перегрузки в случае, когда конечные точки не поддерживают выявление перегрузки или ECN, использовано в целях иллюстрации, хотя другие варианты осуществления применимы для сценариев на Фиг. 8-9.
Иллюстрация показывает сотовую сеть связи 1000 LTE, включающую в себя пользовательское оборудование 1001, eNodeB 1003, имеющий беспроводное соединение 1002 с пользовательским оборудованием, первый маршрутизатор 1004, S-GW 1005, PDN-GW 1006. Сотовая сеть связи LTE может быть такой, как описанная ранее, и может иметь любую из ранее описанных вариаций. Также показаны сеть Интернет 1008, второй маршрутизатор 1007, третий маршрутизатор 1009 и источник 1010.
В этом сценарии восходящей загрузки, PDN-GW является принимающим узлом выявления перегрузки, а eNodeB является посылающим узлом выявления перегрузки. Альтернативно, другой узел (например, S-GW) может быть посылающим узлом выявление перегрузки, а другой узел (например, первый маршрутизатор 1104) может быть посылающим узлом выявления перегрузки. Узлы на маршруте между PDN-GW и eNodeB (например, как показано, S-GW, eNodeB и первый маршрутизатор 1004 между S-GW и eNodeB) могут ECN-маркировать пакеты, чтобы указать, что была испытана перегрузка ("Маркирование бита 1013 ECN"). PDN-GW может предоставлять обратную связь о ECN-маркировании в пакетах, чтобы указать уровень перегрузки, испытываемой пакетами ("Обратная связь ECN-маркирования 1011"). Базовая станция или eNodeB могут принимать эту обратную связь и повторно вставлять обратную связь или информацию о перегрузке обратно в сеть связи, как информацию выявления перегрузки или информацию re-ECN ("Повторная вставка обратной связи 1012"). Базовая станция или eNodeB может, по желанию, иметь ограничитель и выполнять ограничение. Ограничение может также или альтернативно выполняться в другом узле (например, первом маршрутизаторе 1104 или S-GW). PDN-GW может иметь отбрасыватель и может выполнять отбрасывание пакетов на основании информации о перегрузке. Отбрасыватель может также или в качестве альтернативы быть включен в другой узел (например, первый маршрутизатор 1104 или S-GW).
Предполагается, что есть дополнительные альтернативные варианты осуществления. После описания вариант(ов) осуществления данного изобретения, будет описан альтернативный(е) вариант(ы) осуществления. Подобно предыдущему варианту(ам) осуществления, эти альтернативные вариант(ы) осуществления являются локализованными схемами предотвращения перегрузок.
Первый альтернативный вариант осуществления принадлежит к локализованному явному уведомлению о перегрузке (ECN) в пределах локального контура в сотовой сети связи или мобильной транзитной сети связи, или в GTP туннеле, независимо от наличия или отсутствия локализованного выявления перегрузки. К примеру, отправитель ECN может обозначить внешний заголовок как имеющий возможность ECN, даже когда внутренние заголовки пакетов, принятых отправителем ECN, указаны как не имеющие возможности ECN. Если внутренние заголовки указаны как имеющие возможность ECN, отправитель ECN может, по желанию, игнорировать, или изымать входящие маркировки ECN. Отправитель ECN может пересылать пакеты через GTP туннель. Один или несколько нижестоящих узлов могут ECN-маркировать внешние заголовки, даже когда внутренние заголовки указаны как не имеющие возможности ECN. Приемник ECN может возвращать обратную связь касательно ECN-CE-маркированных пакетов.
Второй альтернативный вариант осуществления принадлежит локализованному ECN или локализованному выявлению перегрузки в несотовой или немобильной транзитной сети связи. В различных вариантах осуществления система подключения кабельных модемов (CMTS), мультиплексор доступа к цифровой абонентской линии (DSLAM), или другое устройство цифровой абонентской линии (DSL), или мультисервисный граничный маршрутизатор (MSER) могут включать в себя признаки конечного устройства (отправителя или приемника) для локализованного ECN или локализованного выявления перегрузки, как раскрыто в настоящем документе.
Хотя функциональные схемы на чертежах показывают конкретный порядок действий, выполняемых некоторыми вариантами осуществления данного изобретения, следует понимать, что подобный порядок является примерным (например, альтернативные варианты осуществления могут выполнять действия в другом порядке, объединять некоторые действия, совмещать некоторые действия и так далее).
В описании и формуле изобретения могут использоваться термины "подключен" и "соединен", а также их производные. Следует понимать, что эти термины не рассматриваются как синонимы друг для друга. "Подключен" используется, чтобы обозначить, что два или более элементов, которые могут иметь, а могут не иметь прямой физический или электрический контакт друг с другом, объединяются или взаимодействуют друг с другом. "Соединен" используется, чтобы обозначить установление связи между двумя или более элементами, которые подключены друг к другу.
Хотя данное изобретение было описано со ссылкой на несколько вариантов осуществления, специалисты в данной области техники признают, что данное изобретение не ограничено описанными вариантами осуществления и может быть реализовано на практике с модификациями и изменениями, в пределах сущности и объема прилагаемой формулы изобретения. Описание, таким образом, должно рассматриваться как пояснительное, а не ограничивающее.

Claims (23)

1. Способ для локализованного выявления перегрузки в пределах локального контура в сотовой сети связи, выполняемый принимающим узлом локализованного выявления перегрузки локального контура, причем упомянутый способ содержит этапы, на которых:
принимают, на принимающем узле локализованного выявления перегрузки локального контура в сотовой сети связи, пакеты нисходящей линии связи, предназначенные нижестоящему пользовательскому устройству, причем пакеты нисходящей линии связи имеют внешние заголовки, указывающие уровень перегрузки, испытываемый пакетами нисходящей линии связи, и уровень ожидаемой перегрузки в нисходящем направлении, объявленный вышестоящим узлом, и имеют внутренние заголовки, указывающие транспорт без возможности явного уведомления о перегрузке, при этом принимающий узел локализованного выявления перегрузки содержит беспроводную базовую станцию;
пересылают, с помощью беспроводной базовой станции, пакеты нисходящей линии связи нижестоящему пользовательскому устройству через беспроводное соединение, при этом пересылка включает в себя пересылку пакетов нисходящей линии связи без указания уровня перегрузки и с внутренними заголовками, которые указывают транспорт без возможности явного уведомления о перегрузке; и
посылают пакеты, которые имеют обратную связь, указывающую уровень перегрузки, испытываемый пакетами нисходящей линии связи, и перегрузку, испытываемую в пределах принимающего узла локализованного выявления перегрузки, в восходящем направлении на сетевой узел, который также находится в локальном контуре сотовой сети связи и который находится между принимающим узлом локализованного выявления перегрузки и сетью Интернет.
2. Способ по п. 1, в котором пересылка содержит этап, на котором пересылают пакеты нисходящей линии связи, без указания уровня ожидаемой перегрузки в нисходящем направлении.
3. Способ по п. 1, в котором прием содержит этап, на котором принимают пакеты нисходящей линии связи, имеющие внешние заголовки, которые указывают транспорт с возможностью явного уведомления о перегрузке.
4. Способ по п. 1, в котором прием содержит этап, на котором принимают пакеты нисходящей линии связи через туннель, который не является туннелем Интернет протокола (IP) через IP, и в котором внешние заголовки пакетов нисходящей линии связи, принятых через туннель, указывают транспорт с возможностью явного уведомления о перегрузке.
5. Способ по п. 4, в котором прием содержит этап, на котором принимают пакеты нисходящей линии связи через туннель протокола туннелирования (GTP) Общей службы пакетной радиопередачи (GPRS) и в котором уровень ожидаемой перегрузки в нисходящем направлении, объявленный вышестоящим узлом, указывается в одном из GTP заголовков и внешних IP заголовков пакетов нисходящей линии связи, принятых через GTP туннель.
6. Способ по п. 1, в котором обратная связь указывает уровень перегрузки, испытываемой пакетами нисходящей линии связи, указываемый внешними заголовками пакетов нисходящей линии связи, и число пакетов, отброшенных принимающим узлом локализованного выявления перегрузки.
7. Способ по п. 1, в котором посылка содержит этап, на котором посылают пакеты, которые имеют обратную связь, включающую в себя информацию, выбранную из: (1) числа пакетов, которые были отброшены базовой станцией; (2) числа пакетов, которые были отброшены узлами до базовой станции; (3) числа пакетов, которые базовая станция маркировала, чтобы указать, что была испытана перегрузка; и (4) числа пакетов, маркированных узлами до базовой станции, чтобы указать, что была испытана перегрузка.
8. Способ по п. 1, в котором прием содержит этап, на котором принимают пакеты нисходящей линии связи, которые указывают уровень перегрузки, испытываемый только в пределах локального контура в сотовой сети связи.
9. Способ по п. 1, в котором прием содержит этап, на котором принимают пакеты нисходящей линии связи через туннель в eNodeB сотовой сети связи стандарта долгосрочного развития (LTE).
10. Принимающий узел локализованного выявления перегрузки, выполненный с возможностью выполнения локализованного выявления перегрузки в пределах локального контура в сотовой сети связи, причем принимающий узел локализованного выявления перегрузки содержит:
беспроводную базовую станцию;
первый интерфейс, выполненный с возможностью принимать пакеты нисходящей линии связи, предназначенные нижестоящему пользовательскому устройству, причем пакеты нисходящей линии связи имеют внешние заголовки, указывающие уровень перегрузки, испытываемый пакетами нисходящей линии связи, и уровень ожидаемой перегрузки в нисходящем направлении, объявленный вышестоящим узлом, и имеют внутренние заголовки, указывающие транспорт без возможности явного уведомления о перегрузке;
второй интерфейс, выполненный с возможностью посылать с помощью беспроводной базовой станции пакеты нисходящей линии связи нижестоящему пользовательскому устройству через беспроводное соединение, при этом второй интерфейс выполнен с возможностью посылать пакеты нисходящей линии связи без уровня испытанной перегрузки и с внутренними заголовками, указывающими транспорт без возможности явного уведомления о перегрузке; и
модуль вставки обратной связи, чтобы вставлять обратную связь, указывающую уровень перегрузки, испытываемый пакетами нисходящей линии связи, и перегрузку, испытываемую в пределах принимающего узла локализованного выявления перегрузки, в пакеты, которые посылаются в восходящем направлении через первый интерфейс на сетевой узел в локальном контуре сотовой сети связи между принимающим узлом локализованного выявления перегрузки и сетью Интернет.
11. Узел по п. 10, в котором второй интерфейс выполнен с возможностью посылать пакеты нисходящей линии связи нижестоящему пользовательскому устройству без уровня ожидаемой перегрузки в нисходящем направлении.
12. Узел по п. 10, в котором первый интерфейс выполнен с возможностью принимать пакеты нисходящей линии связи, имеющие внешние заголовки, которые указывают транспорт с возможностью явного уведомления о перегрузке.
13. Узел по п. 10, в котором первый интерфейс выполнен с возможностью принимать пакеты нисходящей линии связи через туннель, который не является туннелем Интернет протокола (IP) через IP, и в котором внешние заголовки пакетов нисходящей линии связи указывают транспорт с возможностью явного уведомления о перегрузке.
14. Узел по п. 13, в котором первый интерфейс выполнен с возможностью принимать пакеты нисходящей линии связи через туннель протокола туннелирования (GTP) Общей службы пакетной радиопередачи (GPRS) и в котором уровень ожидаемой перегрузки в нисходящем направлении, объявленный вышестоящим узлом, указывается в одном из GTP заголовков и внешних IP заголовков принятых пакетов нисходящей линии связи.
15. Узел по п. 10, в котором модуль вставки обратной связи выполнен с возможностью вставлять обратную связь, указывающую сочетание уровня перегрузки, испытываемого пакетами нисходящей линии связи, указываемого внешними заголовками пакетов нисходящей линии связи, и числа пакетов, отброшенных принимающим узлом локализованного выявления перегрузки.
16. Узел по п. 10, причем модуль вставки обратной связи выполнен с возможностью вставлять обратную связь, включающую в себя информацию, выбранную из: (1) числа пакетов, которые были отброшены базовой станцией; (2) числа пакетов, которые были отброшены узлами до базовой станции; (3) числа пакетов, которые базовая станция маркировала, чтобы указать, что была испытана перегрузка; и (4) числа пакетов, маркированных узлами до базовой станции, чтобы указать, что была испытана перегрузка.
17. Узел по п. 10, в котором первый интерфейс выполнен с возможностью принимать пакеты нисходящей линии связи, которые указывают уровень перегрузки, испытываемый только в пределах локального контура в сотовой сети связи.
18. Узел по п. 10, причем узел содержит eNodeB сотовой сети связи стандарта долгосрочного развития (LTE).
19. Способ для локализованного выявления перегрузки в пределах локального контура в сотовой сети связи, выполняемый принимающим узлом локализованного выявления перегрузки локального контура, причем упомянутый способ содержит этапы, на которых:
принимают на принимающем узле локализованного выявления перегрузки локального контура в сотовой сети связи пакеты нисходящей линии связи, предназначенные нижестоящему пользовательскому устройству, через туннель, осуществленный по протоколу, который выполнен на более высоком сетевом уровне, чем Интернет протокол (IP), причем пакеты нисходящей линии связи имеют внешние заголовки, указывающие уровень перегрузки, испытываемый пакетами нисходящей линии связи только в пределах локального контура в сотовой сети связи, и уровень ожидаемой перегрузки в нисходящем направлении, объявленный вышестоящим узлом, и имеют внутренние заголовки, указывающие транспорт без возможности явного уведомления о перегрузке, при этом принимающий узел локализованного выявления перегрузки содержит беспроводную базовую станцию;
пересылают с помощью беспроводной базовой станции нижестоящему пользовательскому устройству через беспроводное соединение пакеты нисходящей линии связи без уровня ожидаемой перегрузки в нисходящем направлении, объявленного вышестоящим узлом, и с внутренними заголовками, указывающими транспорт без возможности явного уведомления о перегрузке; и
посылают пакеты в восходящем направлении, которые имеют обратную связь, указывающую уровень перегрузки, испытываемый пакетами нисходящей линии связи, и перегрузку, испытываемую в пределах принимающего узла локализованного выявления перегрузки, причем пакеты, посылаемые в восходящем направлении, посылаются на сетевой узел в локальном контуре сотовой сети связи между принимающим узлом локализованного выявления перегрузки и сетью Интернет.
20. Способ по п. 19, в котором пересылка содержит этап, на котором пересылают пакеты нисходящей линии связи без уровня ожидаемой перегрузки в нисходящем направлении.
21. Способ по п. 19, в котором прием содержит этап, на котором принимают пакеты нисходящей линии связи через туннель протокола туннелирования (GTP) Общей службы пакетной радиопередачи (GPRS).
22. Способ по п. 19, в котором посылка содержит этап, на котором посылают пакеты в восходящем направлении, которые имеют обратную связь, указывающую число пакетов, отброшенных принимающим узлом локализованного выявления перегрузки.
23. Способ по п. 19, в котором прием содержит этап, на котором принимают пакеты нисходящей линии связи в eNodeB сотовой сети связи стандарта долгосрочного развития (LTE).
RU2013114385/07A 2010-09-01 2011-07-19 Локализованное выявление перегрузки RU2590917C2 (ru)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US37898010P 2010-09-01 2010-09-01
US61/378,980 2010-09-01
US12/976,067 2010-12-22
US12/976,067 US8982694B2 (en) 2010-09-01 2010-12-22 Localized congestion exposure
PCT/IB2011/053223 WO2012028972A1 (en) 2010-09-01 2011-07-19 Localized congestion exposure

Publications (2)

Publication Number Publication Date
RU2013114385A RU2013114385A (ru) 2014-10-10
RU2590917C2 true RU2590917C2 (ru) 2016-07-10

Family

ID=44504032

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2013114385/07A RU2590917C2 (ru) 2010-09-01 2011-07-19 Локализованное выявление перегрузки

Country Status (8)

Country Link
US (4) US8982694B2 (ru)
EP (1) EP2612469B1 (ru)
JP (1) JP5842003B2 (ru)
KR (1) KR101783507B1 (ru)
CN (1) CN103069758B (ru)
AU (1) AU2011298104B2 (ru)
RU (1) RU2590917C2 (ru)
WO (1) WO2012028972A1 (ru)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2675900C1 (ru) * 2018-01-31 2018-12-25 Федеральное государственное казенное военное образовательное учреждение высшего образования "Академия Федеральной службы охраны Российской Федерации" (Академия ФСО России) Способ защиты узлов виртуальной частной сети связи от ddos-атак за счет управления количеством предоставляемых услуг связи абонентам

Families Citing this family (75)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8965380B2 (en) * 2009-08-11 2015-02-24 Cisco Technology, Inc. System and method for providing access in a network environment
US9007914B2 (en) * 2009-09-30 2015-04-14 Qualcomm Incorporated Methods and apparatus for enabling rate adaptation across network configurations
US8914520B2 (en) * 2009-11-16 2014-12-16 Cisco Technology, Inc. System and method for providing enterprise integration in a network environment
US9001663B2 (en) * 2010-02-26 2015-04-07 Microsoft Corporation Communication transport optimized for data center environment
US8982694B2 (en) * 2010-09-01 2015-03-17 Telefonaktiebolaget L M Ericsson (Publ) Localized congestion exposure
EP2614619B1 (en) * 2010-09-07 2019-05-08 Nec Corporation A framework of an efficient congestion exposure audit function
US20120087245A1 (en) 2010-10-06 2012-04-12 Qualcomm Incorporated Methods and apparatus for ecn receiver driven congestion control
EP2652985B1 (en) * 2010-12-17 2015-05-20 Telefonaktiebolaget L M Ericsson (PUBL) Performance monitoring in a mobile communication network
KR101752707B1 (ko) * 2011-01-03 2017-07-03 삼성전자 주식회사 이동통신 시스템에서 혼잡 제어 방법
JP5790665B2 (ja) * 2011-01-25 2015-10-07 富士通株式会社 通信装置、通信システム、通信方法、および通信プログラム
US9363278B2 (en) * 2011-05-11 2016-06-07 At&T Mobility Ii Llc Dynamic and selective response to cyber attack for telecommunications carrier networks
WO2012175117A1 (en) * 2011-06-21 2012-12-27 Telefonaktiebolaget L M Ericsson (Publ) Managing communications within a wireless communications network
EP2727284B1 (en) * 2011-06-30 2018-06-06 British Telecommunications public limited company Determining path congestion measures
US20130007196A1 (en) * 2011-06-30 2013-01-03 Alfano Frank M Connectionless Operation in a Wireless Network
JPWO2013005818A1 (ja) * 2011-07-01 2015-02-23 日本電気株式会社 通信システムおよび基地局装置
US20140233390A1 (en) * 2011-09-06 2014-08-21 Nec Europe Ltd. Method and system for congestion avoidance in mobile communication networks
US8769088B2 (en) * 2011-09-30 2014-07-01 International Business Machines Corporation Managing stability of a link coupling an adapter of a computing system to a port of a networking device for in-band data communications
US9509805B2 (en) * 2011-12-01 2016-11-29 Telefonaktiebolaget Lm Ericsson (Publ) Reduction of packet header compression overhead due to high ECN rate
EP3509387B1 (en) 2012-03-08 2021-07-28 Samsung Electronics Co., Ltd. Method for controlling services in wireless communication system
WO2013133665A1 (ko) * 2012-03-08 2013-09-12 삼성전자 주식회사 무선 통신 시스템의 혼잡 관리를 위한 방법 및 장치
US9912597B2 (en) * 2012-03-08 2018-03-06 Samsung Electronics Co., Ltd. Method and apparatus for controlling traffic of radio access network in a wireless communication system
KR20130111157A (ko) * 2012-03-29 2013-10-10 삼성전자주식회사 무선 통신 시스템의 혼잡 관리를 위한 방법 및 장치
US9100206B1 (en) * 2012-03-30 2015-08-04 Juniper Networks, Inc. Seamless architecture for cable access networks
US9112804B2 (en) * 2012-05-31 2015-08-18 International Business Machines Corporation Network congestion notification preservation and modification during transmission of network data between physical network and virtual network
CN103532864B (zh) * 2012-07-06 2017-02-01 华为技术有限公司 上行/下行拥塞信息传输方法、装置及***
US9203764B2 (en) * 2012-07-11 2015-12-01 Telefonaktiebolaget L M Ericsson (Publ) Quality of experience enhancement through feedback for adjusting the quality of service in communication networks
US20140022900A1 (en) * 2012-07-17 2014-01-23 Cisco Technology, Inc. System and method for indicating a level of ran congestion for user plane traffic in a network environment
CN104756539A (zh) * 2012-10-29 2015-07-01 阿尔卡特朗讯公司 用于在具有移动http自适应流的无线网络中的拥塞管理的方法与装置
WO2014074802A1 (en) * 2012-11-09 2014-05-15 Interdigital Patent Holdings, Inc. Controlling traffic in information centric networks
EP2731373A1 (en) 2012-11-13 2014-05-14 NTT DoCoMo, Inc. Method and apparatus for congestion notification
KR102090515B1 (ko) * 2013-01-18 2020-03-18 삼성전자주식회사 혼잡 상황에서 서비스 레벨을 조절하는 방법 및 장치
KR102066130B1 (ko) * 2013-01-18 2020-02-11 삼성전자주식회사 무선 통신 시스템에서 트래픽 제어 방법 및 장치
US9306854B2 (en) * 2013-02-27 2016-04-05 Cisco Technology, Inc. Method and apparatus for diagnosing interface oversubscription and microbursts
KR102099650B1 (ko) * 2013-03-11 2020-05-15 삼성전자 주식회사 이동통신 네트워크의 혼잡 상황 제어 방법 및 장치
EP2785104A3 (en) * 2013-03-29 2016-10-05 Samsung Electronics Co., Ltd. Method and apparatus for controlling congestion in wireless communication system
KR20140118659A (ko) * 2013-03-29 2014-10-08 삼성전자주식회사 무선 통신 시스템에서 혼잡 제어 방법 및 장치
US9722929B2 (en) * 2013-04-08 2017-08-01 Telefonaktiebolaget Lm Ericsson (Publ) Congestion aware throughput targets
KR102017167B1 (ko) * 2013-06-27 2019-09-02 삼성전자주식회사 무선 통신 시스템에서 데이터 트래픽 분산을 위한 방법 및 장치
CN104521197B (zh) * 2013-06-28 2017-10-17 华为技术有限公司 拥塞信息反馈方法及装置、网关
EP3025544B1 (en) * 2013-07-24 2019-01-30 Telefonaktiebolaget LM Ericsson (publ) Method and network node for congestion management in a wireless communications network
EP2843886A1 (en) * 2013-08-30 2015-03-04 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Load balancing among alternative paths
KR102119112B1 (ko) * 2013-09-17 2020-06-29 삼성전자 주식회사 트래픽 품질 제어 방법 및 장치
US9413666B2 (en) 2013-10-02 2016-08-09 Cisco Technology, Inc. Reporting radio access network congestion information in a network sharing environment
EP2869513A1 (en) * 2013-10-30 2015-05-06 Telefonaktiebolaget L M Ericsson (Publ) Method and network node for controlling sending rates
US9419900B2 (en) * 2013-12-31 2016-08-16 International Business Machines Corporation Multi-bit indicator set according to feedback based on an equilibrium length of a queue
US9473414B2 (en) 2014-02-06 2016-10-18 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for supporting packet prioritization at a data network
EP3120512B1 (en) 2014-03-20 2019-02-27 Telefonaktiebolaget LM Ericsson (publ) Tunnel congestion volume policing
US9591509B2 (en) * 2014-04-10 2017-03-07 Qualcomm Incorporated Congestion control scheme
CN105099929B (zh) * 2014-04-18 2018-11-27 海尔集团公司 网络控制方法、装置及相应设备
US9660914B1 (en) * 2014-05-08 2017-05-23 Google Inc. System and method for providing congestion notification in layer 3 networks
US9860791B1 (en) * 2014-07-02 2018-01-02 Sprint Communications Company L.P. Long term evolution communication policies based on explicit congestion notification
US9538563B2 (en) * 2014-10-13 2017-01-03 At&T Intellectual Property I, L.P. System and methods for managing a user data path
US20170366374A1 (en) * 2014-10-31 2017-12-21 Nec Corporation Gateway apparatus and control method thereof
US9660915B2 (en) * 2015-05-11 2017-05-23 Oracle International Corporation Congestion control for tunneled real-time communications
US10230767B2 (en) 2015-07-29 2019-03-12 At&T Intellectual Property I, L.P. Intra-carrier and inter-carrier network security system
US10009277B2 (en) 2015-08-04 2018-06-26 Mellanox Technologies Tlv Ltd. Backward congestion notification in layer-3 networks
US10237376B2 (en) * 2015-09-29 2019-03-19 Mellanox Technologies, Ltd. Hardware-based congestion control for TCP traffic
US10524278B2 (en) 2015-11-20 2019-12-31 Qualcomm Incorporated Scheduling and token bucket for communication co-existence
US10009912B2 (en) * 2015-11-20 2018-06-26 Qualcomm Incorporated Scheduling and token bucket for communication co-existence
US9882629B2 (en) 2015-11-20 2018-01-30 At&T Mobility Ii Llc Facilitation of dual mode wireless device transmissions
US10298510B1 (en) * 2015-12-16 2019-05-21 Amazon Technologies, Inc. Controlling data transmission rates of multiple devices
CN107547418B (zh) * 2016-06-29 2019-07-23 华为技术有限公司 一种拥塞控制方法和装置
US10142886B2 (en) 2016-09-30 2018-11-27 Cisco Technology, Inc. System and method to facilitate group reporting of user equipment congestion information in a network environment
KR102380619B1 (ko) * 2017-08-11 2022-03-30 삼성전자 주식회사 이동 통신 시스템 망에서 혼잡 제어를 효율적으로 수행하는 방법 및 장치
CN111279658B (zh) * 2017-10-26 2023-08-22 华为技术有限公司 用于检测和减轻数字数据网络拥塞的设备和方法
GB2590857B (en) * 2018-02-01 2022-06-15 Openwave Mobility Inc Signalling congestion status
GB2570676B (en) * 2018-02-01 2021-04-21 Openwave Mobility Inc Signalling congestion status
CN109245959B (zh) * 2018-09-25 2021-09-03 华为技术有限公司 统计活跃流数目的方法、网络设备和***
US10277586B1 (en) * 2018-10-29 2019-04-30 Syniverse Technologies, Llc Mobile authentication with URL-redirect
CN111490943A (zh) * 2019-01-29 2020-08-04 中兴通讯股份有限公司 拥塞控制方法、终端及可读存储介质
EP3918831A1 (en) 2019-02-01 2021-12-08 Telefonaktiebolaget Lm Ericsson (Publ) Detecting congestion at an intermediate iab node
US11005770B2 (en) * 2019-06-16 2021-05-11 Mellanox Technologies Tlv Ltd. Listing congestion notification packet generation by switch
US11641305B2 (en) * 2019-12-16 2023-05-02 Vmware, Inc. Network diagnosis in software-defined networking (SDN) environments
US11252177B2 (en) * 2020-07-07 2022-02-15 Charter Communications Operating, Llc Methods and system for automated ad hoc customer premise equipment bi-directional vulnerability scanning
WO2022089747A1 (en) * 2020-10-29 2022-05-05 Telefonaktiebolaget Lm Ericsson (Publ) Congestion marking in mobile networks

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2256299C2 (ru) * 2000-08-25 2005-07-10 Моторола, Инк. Способ и устройство для поддержания информации о подтверждении радиосвязи для однонаправленного канала передачи пользовательских данных
RU2313915C2 (ru) * 2003-01-28 2007-12-27 Телефонактиеболагет Лм Эрикссон (Пабл) Способ и устройство уведомления о перегруженности в сетях пакетной передачи с указанием нескольких различных причин перегруженности
EP1873968A1 (en) * 2006-06-26 2008-01-02 BRITISH TELECOMMUNICATIONS public limited company Monitoring networks
RU2008138710A (ru) * 2006-03-31 2010-04-10 Майкрософт Корпорейшн (Us) Управление усовершенствованными совокупностями присутствия

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE69933130T2 (de) * 1998-06-05 2007-03-08 British Telecommunications P.L.C. Abrechnung in einem Kommunikationsnetz
US6741555B1 (en) * 2000-06-14 2004-05-25 Nokia Internet Communictions Inc. Enhancement of explicit congestion notification (ECN) for wireless network applications
JP2002217972A (ja) * 2001-01-12 2002-08-02 Nec Corp 輻輳状況対応型ＶｏＩＰシステム、及び、ＶｏＩＰシステムの輻輳回避方法
EP1450514A1 (en) * 2003-02-18 2004-08-25 Matsushita Electric Industrial Co., Ltd. Server-based rate control in a multimedia streaming environment
GB0410254D0 (en) 2004-05-07 2004-06-09 British Telecomm Processing of data in networks
CN101056260B (zh) * 2007-05-21 2010-07-21 中南大学 混合网络中基于ecn机制的拥塞控制方法
FI20075578A0 (fi) * 2007-08-17 2007-08-17 Nokia Siemens Networks Oy Paketin välittäminen tietoliikenneverkossa
EP2249527B1 (en) * 2007-08-22 2018-09-26 Telefonaktiebolaget LM Ericsson (publ) Data transmission control methods and devices
US20090168680A1 (en) * 2007-12-27 2009-07-02 Motorola, Inc. Multiple multicast data stream delivery in a communication network
EP2243302B1 (en) * 2008-01-14 2018-10-10 Telefonaktiebolaget LM Ericsson (publ) Method and nodes for congestion notification
US8718928B2 (en) * 2008-04-23 2014-05-06 Verizon Patent And Licensing Inc. Traffic monitoring systems and methods
US8045555B2 (en) * 2008-08-20 2011-10-25 Futurewei Technologies, Inc. Method and apparatus for tunnel packet optimization
EP2324604A1 (en) * 2008-09-08 2011-05-25 Nokia Siemens Networks Oy Method and device for classifying traffic flows in a packet-based wireless communication system
EP2230803A1 (en) 2009-03-16 2010-09-22 BRITISH TELECOMMUNICATIONS public limited company Path characterisation in networks
EP2234346A1 (en) * 2009-03-26 2010-09-29 BRITISH TELECOMMUNICATIONS public limited company Policing in data networks
WO2010127683A1 (en) * 2009-05-05 2010-11-11 Nokia Siemens Networks Oy Local breakout with parameter access service
US8605584B2 (en) * 2009-07-02 2013-12-10 Qualcomm Incorporated Transmission of control information across multiple packets
EP2282458A1 (en) 2009-07-17 2011-02-09 BRITISH TELECOMMUNICATIONS public limited company Usage policing in data networks
US9007914B2 (en) 2009-09-30 2015-04-14 Qualcomm Incorporated Methods and apparatus for enabling rate adaptation across network configurations
US8619587B2 (en) 2010-01-05 2013-12-31 Futurewei Technologies, Inc. System and method to support enhanced equal cost multi-path and link aggregation group
US8982694B2 (en) 2010-09-01 2015-03-17 Telefonaktiebolaget L M Ericsson (Publ) Localized congestion exposure

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2256299C2 (ru) * 2000-08-25 2005-07-10 Моторола, Инк. Способ и устройство для поддержания информации о подтверждении радиосвязи для однонаправленного канала передачи пользовательских данных
RU2313915C2 (ru) * 2003-01-28 2007-12-27 Телефонактиеболагет Лм Эрикссон (Пабл) Способ и устройство уведомления о перегруженности в сетях пакетной передачи с указанием нескольких различных причин перегруженности
RU2008138710A (ru) * 2006-03-31 2010-04-10 Майкрософт Корпорейшн (Us) Управление усовершенствованными совокупностями присутствия
EP1873968A1 (en) * 2006-06-26 2008-01-02 BRITISH TELECOMMUNICATIONS public limited company Monitoring networks

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2675900C1 (ru) * 2018-01-31 2018-12-25 Федеральное государственное казенное военное образовательное учреждение высшего образования "Академия Федеральной службы охраны Российской Федерации" (Академия ФСО России) Способ защиты узлов виртуальной частной сети связи от ddos-атак за счет управления количеством предоставляемых услуг связи абонентам

Also Published As

Publication number Publication date
EP2612469A1 (en) 2013-07-10
RU2013114385A (ru) 2014-10-10
AU2011298104B2 (en) 2015-07-09
US20150172954A1 (en) 2015-06-18
EP2612469B1 (en) 2015-09-02
US9445300B2 (en) 2016-09-13
KR101783507B1 (ko) 2017-09-29
US9762498B2 (en) 2017-09-12
JP2013542629A (ja) 2013-11-21
US9866492B2 (en) 2018-01-09
US20120051216A1 (en) 2012-03-01
CN103069758B (zh) 2016-06-08
US20160359752A1 (en) 2016-12-08
US8982694B2 (en) 2015-03-17
US20150156120A1 (en) 2015-06-04
KR20130105847A (ko) 2013-09-26
CN103069758A (zh) 2013-04-24
JP5842003B2 (ja) 2016-01-13
AU2011298104A1 (en) 2013-03-21
WO2012028972A1 (en) 2012-03-08

Similar Documents

Publication Publication Date Title
RU2590917C2 (ru) Локализованное выявление перегрузки
EP2243302B1 (en) Method and nodes for congestion notification
CN102356601B (zh) 网络中的路径特性
US11159423B2 (en) Techniques for efficient multipath transmission
US20130204988A1 (en) Method and system for loopback proxy
JP5899328B2 (ja) Ｔｃｐトラフィックをハンドリングするための方法及びネットワークノード
EP3214808A1 (en) Gateway apparatus and method of controlling gateway apparatus
US20160014029A1 (en) Method and Apparatus for Congestion Signalling for MPLS Networks
Vakilinia et al. Latency control of icn enabled 5g networks
De Schepper et al. RFC 9330: Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture
US20100040071A1 (en) Communication system
US20100214914A1 (en) Method of bandwidth management in packet networks
US10454826B2 (en) Technique for signalling congestion in a packet communication network
De Schepper RFC 9331: The Explicit Congestion Notification (ECN) Protocol for Low Latency, Low Loss, and Scalable Throughput (L4S)
WO2012114328A1 (en) System and method for active queue management per flow over a packet switched network
Braun et al. Transport Area Working Group B. Briscoe, Ed. Internet-Draft CableLabs Intended status: Informational K. De Schepper Expires: January 9, 2020 Nokia Bell Labs
Zhang et al. Metering Re-ECN: Performance evaluation and its applicability in cellular networks
Briscoe Internet-Draft BT Intended status: Informational M. Sridharan Expires: January 10, 2013 Microsoft July 09, 2012

Legal Events

Date Code Title Description
MM4A The patent is invalid due to non-payment of fees

Effective date: 20200720