RU2480931C2 - Способ задания максимального размера передаваемого блока данных (mtu) линии связи в пользовательском устройстве (ue) - Google Patents

Способ задания максимального размера передаваемого блока данных (mtu) линии связи в пользовательском устройстве (ue) Download PDF

Info

Publication number
RU2480931C2
RU2480931C2 RU2009138928/07A RU2009138928A RU2480931C2 RU 2480931 C2 RU2480931 C2 RU 2480931C2 RU 2009138928/07 A RU2009138928/07 A RU 2009138928/07A RU 2009138928 A RU2009138928 A RU 2009138928A RU 2480931 C2 RU2480931 C2 RU 2480931C2
Authority
RU
Russia
Prior art keywords
mtu
sae
network
lte
communication line
Prior art date
Application number
RU2009138928/07A
Other languages
English (en)
Other versions
RU2009138928A (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
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=39766613&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=RU2480931(C2) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Телефонактиеболагет Лм Эрикссон (Пабл) filed Critical Телефонактиеболагет Лм Эрикссон (Пабл)
Publication of RU2009138928A publication Critical patent/RU2009138928A/ru
Application granted granted Critical
Publication of RU2480931C2 publication Critical patent/RU2480931C2/ru

Links

Images

Classifications

    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • 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/36—Flow control; Congestion control by determining packet size, e.g. maximum transfer unit [MTU]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/166—IP fragmentation; TCP segmentation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/18—Information format or content conversion, e.g. adaptation by the network of the transmitted or received information for the purpose of wireless delivery to users or terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/20—Control channels or signalling for resource management
    • H04W72/23—Control channels or signalling for resource management in the downlink direction of a wireless link, i.e. towards a terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/06—Transport layer protocols, e.g. TCP [Transport Control Protocol] over wireless
    • 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)
  • Quality & Reliability (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Изобретение относится к системам связи. Технический результат заключается в снижении фрагментации сети. В сети радиосвязи архитектуры развития системной архитектуры/долговременного развития (SAE/LTE) сеть выполнена с возможностью задания в пользовательском устройстве (UE) MTU линии связи для каждого канала передачи данных, причем заданный сетью MTU линии связи может представлять MTU тракта для службы SAE передачи данных в полной сети или части конкретной сети SAE/LTE. 3 н. и 9 з.п. ф-лы, 3 ил.

Description

Описание
ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ
Настоящее изобретение относится к способам и устройствам в телекоммуникационной системе, конкретно к способам и устройствам для управляемого сетью задания максимального размера передаваемого блока данных (MTU) линии связи в пользовательском устройстве (UE).
УРОВЕНЬ ТЕХНИКИ
В рамках Проекта (3GPP) партнерства систем связи 3-го поколения в настоящее время продолжается работа над технологией «долговременного развития» (LTE) универсальной сети наземного радиодоступа (UTRAN). Архитектура System Architecture Evolution/Long Term Evolution (SAE/LTE) (Развитие системной архитектуры/долговременное развитие), которая перемещает PDCP (протокол сходимости пакетных данных), относящиеся к плоскости пользователя шифрование и компрессию заголовка на усовершенствованный Узел B (eNB), изменяет потребности обработки длины кадров по протоколам S1-U (и X2-U), поскольку длины кадра по S1-U (и X2-U) в таком случае значительно возрастают. Следовательно, необходимы надлежащие решения, касающиеся длины максимального передаваемого блока данных (MTU). В то же время были несколько повышены возможности снижения вероятности фрагментации кадра S1-U.
С фрагментацией связаны следующие проблемы.
Транспортные издержки: каждый фрагмент включает в себя дополнительный заголовок IP-протокола; следовательно, это добавляет дополнительные издержки передачи. Это составляет 20 октетов (хотя это зависит от использования необязательных заголовков) на один фрагмент в случае протокола IPv4 и 48 октетов в случае протокола IPv6 (то есть 40 октетов обычного IPv6-заголовка плюс 8 октетов для заголовка фрагмента). Типовая дейтаграмма транспортного уровня будет переноситься в 2 фрагментах. Следовательно, выбор длины дейтаграммы транспортного уровня таким образом, чтобы она вмещалась в один IP-пакет, обеспечивает значительно более низкие общие издержки.
Неполный сброс: в случае если пакеты отбрасываются вследствие перегрузки, вероятно что фрагменты той же дейтаграммы сбрасываются независимо. Следовательно, используются транспортные сетевые ресурсы, чтобы пересылать данные, которые будут отбрасываться в приемнике, в обслуживающем шлюзе (SGW) или eNB. В случае серьезной перегрузки это может вести к дальнейшему сбрасыванию и, следовательно, к большему числу неполных дейтаграмм.
Эффективность обработки: общепринято, что интерфейс S1 является «узким местом». Следовательно, даже в нормальном состоянии может присутствовать значительная потеря пакетов и разброс времени задержки для интерактивных потоков и потоков с максимальной возможной скоростью передачи данных, чтобы максимизировать скорость передачи данных, воспринимаемую конечным пользователем, и использование недостаточных ресурсов S1. Это может требовать значительного объема обработки и относительно долговременного резервирования памяти для повторной сборки исходных дейтаграмм в приемнике, поскольку буферы повторной сборки должны выделяться по меньшей мере на длительность воспринимаемого разброса времени задержки на применимом тракте передачи.
Угроза безопасности: следует отметить, что обычные реализации предполагают, что фрагментируется только часть дейтаграмм, и, если дейтаграммы фрагментируются, фрагменты поступают с очень коротким интервалом. Это дает возможность ограничения памяти, требуемой для повторной сборки. Следовательно, передача неполных дейтаграмм является обычным способом введения атак отказа от обслуживания, поскольку в течение протяженных периодов используются недостаточные буферы повторной сборки, и законные фрагментированные дейтаграммы могут сбрасываться вследствие недостатка буферов/устройств повторной сборки. Хотя для (логического) SGW и eNB это в действительности не является трудностью, поскольку эти узлы используют безопасную сеть, это может быть проблемой для шлюзов безопасности (SEG) в случае если фрагментация выполняется на тракте между несколькими SEG.
Ложная повторная сборка: идентификационный заголовок, используемый для повторной сборки, представляет только 16 битов в случае IPv4 (32 бита в случае IPv6). При рассмотрении пиковой скорости передачи данных, измеряемой в пакетах в секунду, имеется высокая вероятность циклического возврата идентификатора (ID) и, следовательно, некорректной повторной сборки (хотя это также зависит от установки таймера повторной сборки в приемнике). Ложная повторная сборка приводит по меньшей мере к дополнительной потере данных, которая может быть обнаружена приемником, или даже к нарушению целостности (и потенциально - конфиденциальности).
Таким образом, существует потребность в архитектуре системы, которая устраняет или по меньшей мере уменьшает проблемы, относящиеся к фрагментации.
РАСКРЫТИЕ ИЗОБРЕТЕНИЯ
На MTU тракта, то есть тракта между сервером приложений и UE в сети LTE, такой как сеть, изображенная на фиг.1, влияют многие события. Каждая линия связи в IP-сети имеет заданный параметр «максимальный размер передаваемого блока данных» (MTU), и то же относится к линии связи, которая используется IP-хостом в UE. Было замечено, что существует проблема того, каким образом в UE задавать MTU линии связи. В целом, любое «приемлемое» заданное по умолчанию значение, которое обновляется в зависимости от определения MTU тракта, может использоваться изначально.
Однако следует отметить, что имеется ряд конфигураций/вариантов выполнения (например, брандмауэров/шлюзов), которые отбрасывают ряд сообщений протокола управляющих сообщений Интернет (ICMP) для версии IPv4, включая сообщение «Packet Too Big». Следовательно, можно предполагать, что определение MTU сквозного тракта не используется в случае IPv4. Это в свою очередь ведет к фрагментации в сети и всем проблемам, связанным с такой фрагментацией.
Для устранения указанных трудностей сеть выполнена с возможностью конфигурирования в UE параметра MTU линии связи для каждого канала передачи, причем конфигурированный сетью MTU линии связи может представлять MTU тракта для SAE службы передачи данных в полной сети или части конкретной сети SAE/LTE.
Если узлы SAE/LTE выполняются осведомленными о MTU, поддерживаемом в сети SAE/LTE, сеть может приспосабливаться для конфигурирования MTU линии связи в UE так, чтобы можно было избежать фрагментации в сети SAE/LTE или по меньшей мере значительно уменьшить ее вероятность. Если этот MTU становится доступным хосту в UE, стеку в UE дается возможность обеспечивать нижеследующее поведение, которое значительно уменьшает необходимость фрагментации в сети:
- в случае протокола транспортного уровня, который имеет характеристику «максимальный размер сегмента» (MSS), например протокола управления передачей (TCP) или протокола передачи с управлением потоком (SCTP), оба MSS передачи и приема могут выбираться UE с учетом конфигурированного сетью MTU линии связи, и, следовательно, фрагментации можно избежать в целом (или по меньшей мере в домене сети SAE/LTE); В случае TCP значение MSS приема может сигнализироваться на узел того же уровня в виде сообщений SYN и SYN ACK при установлении соединения TCP;
- в случае протокола транспортного уровня, который не имеет характеристики «максимальный размер сегмента» (MSS), например протокола дейтаграмм пользователя (UDP), UE может фрагментировать передаваемую дейтаграмму в источнике в соответствии с конфигурированным сетью MTU линии связи, и, следовательно, фрагментации можно избежать по меньшей мере в направлении восходящей линии связи.
Изобретение также распространяется на узлы в сети SAE/LTE, выполненной с возможностью передавать MTU линии связи в UE, а также в UE, выполненное с возможностью принимать MTU линии связи и основывать передачу на MTU линии связи.
Таким образом, в соответствии с настоящим изобретением MTU, поддерживаемый сетью SAE/LTE, сигнализируется в UE.
Одно преимущество настоящего изобретения состоит в том, что UE имеет возможность использовать оптимизированный MTU для сети SAE/LTE без добавления значительной дополнительной сложности. Кроме того, допустимые временные ограничения для увеличения MTU путем определения MTU тракта не позволяют эффективно воспользоваться преимуществом изменений в MTU тракта вследствие мобильности (то есть усовершенствованные Узлы B (eNB), между которыми перемещается UE, могут быть соединены с различными IP-сетями с отличающимся MTU). Передачи обслуживания рассматриваются в сети мобильной связи значительно более часто, чем заданные временные ограничения для определения MTU тракта.
КРАТКОЕ ОПИСАНИЕ ФИГУР ЧЕРТЕЖЕЙ
Фиг.1 иллюстрирует влияние на MTU тракта, оказываемое архитектурой протокола SAE/LTE относительно S1-U.
Фиг.2 иллюстрирует установление/изменение канала SAE.
Фиг.3 иллюстрирует установление/изменение радиоканала.
ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ
Как упомянуто выше, на MTU тракта, то есть тракта между сервером приложений и UE, как изображено, например, на фиг.1, могут влиять многие факторы, включая:
- несжатый заголовок исходных (то есть сквозных пользовательских) IP-пакетов;
- протокол туннелирования S1-U (GTP-U) (протокол туннелирования для пакетной передачи данных);
- туннель по протоколу IPSec (инкапсуляция зашифрованных данных (ESP), Ассоциации по безопасности (SA) в режиме туннеля) для защиты целостности и конфиденциальности в сети доступа между шлюзами безопасности (SEG);
- MTU, обеспечиваемый уровнем линии передачи данных в конкретном экземпляре интерфейса S1;
- MTU, установленный для конкретного административного (и обеспечения качества обслуживания (QoS)) домена IP-сети;
- используемая версия протокола Internet (то есть IPv4 или IPv6).
Аспекты, описанные в контексте некоторых из вышеуказанных проблем, могут вносить переменный MTU тракта передачи прежде всего вследствие мобильности пользователя. Другим источником переменного MTU тракта могут быть отказы линий связи и последующее изменение маршрутизации в сети IP.
Кроме того, весьма вероятно, что сеть SAE/LTE имеет наименьший MTU на сквозном тракте.
Каждая линия связи в IP-сети имеет заданный MTU и тоже относится к линии связи, которая используется IP-хостом в UE. Было замечено, что будет существовать проблема того, каким образом в UE задавать MTU линии связи. В целом, может изначально использоваться любое приемлемое заданное по умолчанию значение, которое обновляется в зависимости от определения MTU тракта. Однако следует отметить, что имеется ряд конфигураций/вариантов выполнения (например, бранмауэров/шлюзов), которые отбрасывают ряд ICMP-сообщений для IPv4, включая тип сообщений «Packet Too Big». Следовательно, может полагаться, что определение MTU для сквозного тракта не используется в случае IPv4. Это в свою очередь ведет к фрагментации в сети и всем проблемам, связанным с такой фрагментацией. Фрагментация в случае использования, как проиллюстрировано на фиг.1, может происходить на различных уровнях, включая фрагментацию сквозной дейтаграммы, фрагментацию дейтаграммы протокола S1-U, фрагментацию туннельной дейтаграммы протокола IPSec.
Если узлы SAE/LTE получают информацию о MTU, поддерживаемом в сети SAE/LTE, сети дается возможность задавать MTU линии связи в UE так, что фрагментация в сети SAE/LTE может быть исключена или по меньшей мере значительно уменьшена. Если этот MTU доступен хосту в UE, стек в UE способен обеспечивать следующее поведение, чтобы уменьшить необходимость фрагментации в сети:
в случае протокола транспортного уровня, который имеет характеристику «максимальный размер сегмента» MSS, например протокола TCP, посредством UE могут выбираться оба MSS и передачи, и приема путем рассмотрения заданного сетью значения MTU «линии связи», и, следовательно, фрагментация может быть исключена в целом или по меньшей мере в домене сети SAE/LTE;
в случае протокола транспортного уровня, который не имеет характеристику «максимальный размер сегмента» (MSS), например протокола UDP, UE может фрагментировать передаваемую дейтаграмму в источнике в соответствии с заданным сетью значением MTU «линии связи», и, следовательно, фрагментация может избегаться по меньшей мере в направлении восходящей линии связи.
В соответствии с настоящим изобретением MTU, поддерживаемый сетью SAE/LTE, сигнализируется в UE.
Нижеследующее описывает с помощью неограничивающих примеров различные варианты осуществления для сигнализации MTU линии связи.
В соответствии с первым вариантом осуществления MTU линии связи сигнализируется в сообщении «Non Access Stratum» (NAS) от модуля управления мобильностью (MME). Поскольку сигнализированный MTU линии связи концептуально представляет MTU, поддерживаемый службой SAE передачи данных, он выражен в явном виде. Сигнализация NAS для установления и изменения канала SAE проиллюстрирована на фиг.2. Таким образом, сначала в сообщении 201 посылается сообщение Non Access Stratum (NAS) от модуля управления мобильностью (MME), включающее «запрос установления/изменения канала SAE» и MTU линии связи. В ответ на сообщение 201 UE передает сообщение 203 NAS, подтверждающее, что завершено установление/изменение канала SAE.
В соответствии с одним вариантом осуществления настоящего изобретения сигналы MME в сообщении NAS запроса установления/изменения канала SAE (или подобного сообщения) сигнализируют значение MTU линии связи, который может представлять MTU тракта для службы канала SAE в полной или в части конкретной сети SAE/LTE. Сигнализированный MTU линии связи может, например, быть установлен в самое высокое значение, поддерживаемое сетью SAE/LTE, так что сеть не нуждается в исполнении IP-фрагментации исходной сквозной дейтаграммы или какой-либо из (вложенных) дейтаграмм туннелирования, инкапсулирующих сквозную дейтаграмму. Как только UE принимает MTU линии связи для конкретного канала SAE при установлении или изменении канала SAE, UE может применять сигнализированный MTU линии связи для конкретного канала SAE.
В соответствии с другим вариантом осуществления настоящего изобретения MTU линии связи сигнализируется в сообщении протокола управления радиоресурсами (RRC) от усовершенствованного Узла B (eNB). Сигнализируемый MTU линии связи может, например, быть частью процедуры установления/изменения радиоканала и может в таком случае лишь в неявном виде представлять MTU, поддерживаемый службой SAE передачи данных.
Сигнализация RRC для установления и реконфигурации радиоканала проиллюстрирована на фиг.3. В соответствии с одним вариантом осуществления настоящего изобретения eNB сигнализирует в RRC сообщении 301 запроса установки/реконфигурации радиоканала (или подобном сообщении) значение MTU линии связи, который может неявно представлять MTU тракта для службы SAE передачи данных в полной или в части конкретной сети SAE/LTE в качестве известного для eNB. Сигнализируемый MTU линии связи может, например, быть установлен в самое высокое значение, поддерживаемое сетью SAE/LTE, так что сеть не нуждается в исполнении IP-фрагментации исходной сквозной дейтаграммы или какой-либо из (вложенных) дейтаграмм туннелирования, инкапсулирующих сквозную дейтаграмму. Как только UE принимает MTU линии связи для конкретного радиоканала в сообщении установления или реконфигурации радиоканала, UE предпочтительно устанавливается с возможностью применять сигнализированный MTU линии связи для конкретного канала SAE. Также в ответ на сообщение 303 UE подтверждает, что завершена установка/реконфигурация радиоканала.
При задании MTU домена в SGW и eNB MTU линии связи также является характеристикой административного домена, к которому относится линия связи. Обычно это приведет к тому, что обладающая наименьшей пропускной способностью линия связи определяет MTU для всего домена. Кроме того, можно предполагать, что очень малые значения MTU не используются в современных IP-сетях. Следовательно, можно в целом предполагать, что минимальный MTU линии связи для протокола S1-U (X2-U) будет приблизительно в 1500 октетов минус применяемые служебные сигналы. В соответствии с одним вариантом осуществления настоящего изобретения узлы eNB, имеющие между собой заданные X2-интерфейсы, устанавливаются как принадлежащие одному и тому же административному домену IP-сети. Подобным образом соответствующие экземпляры S1-U в UPE предпочтительно становятся частью того же административного домена.
Кроме того, чтобы избежать небольших изменений значений MTU, которые могут приводить к худшей рабочей характеристике, чтобы получить увеличение на несколько октетов для конкретной линии связи, предпочитают задавать MTU административного домена для каждой соответствующей линии связи в eNB и UPE. Одна причина для задания MTU административного домена для каждой соответствующей линии связи в eNB и SGW состоит в том, что функциональность «too big packets» может быть осуществлена в eNB и UPE, как описано ниже.
Имеются три способа фрагментации:
Фрагментация сквозного IP-пакета: эта возможность допускается только в случае IPv4 и только в случае, если не был установлен бит «do not fragment» (DF). Однако имеется ряд вариантов реализации, которые выполняют фрагментацию, даже если был установлен бит DF. Фрагментация при установленном бите DF, например, иногда используется, чтобы преодолеть ограничения для исполнения в IPv4 сетях определения MTU тракта.
Преимуществом использования фрагментации сквозного IP-пакета независимо от установки бита DF, как описано выше, является то, что повторная сборка переносится на конечные хосты, и, следовательно, не расходуются сетевые ресурсы на повторную сборку. Это применимо только в случае, если SGW и eNB конфигурированы с учетом MTU линии связи, который соответствует MTU тракта согласно S1-U (X2-U), или если используется определение MTU линии связи относительно S1-U (X2-U). В качестве дополнения хосты, завершающие сквозной поток, могут сами выполнять фрагментацию/повторную сборку в соответствии с MTU линии связи, заданным для канала связи, связанного с хостами.
Фрагментация для IP-пакетов туннелирования согласно S1-U (X2-U): если фрагментация является решением, используемым для обработки «слишком больших пакетов» («too big packets»), то фрагментация IP-пакетов туннелирования согласно S1-U (X2-U) является предпочтительной возможностью, если сквозным потоком является поток согласно IPv6. Это может также применяться в случае сквозных потоков согласно IPv4. Кроме того, фрагментация может быть оставлена узлу, который осуществляет интерфейс с линией связи с самым малым MTU для тракта S1-U (X2-U) в случае IPv4-тракта относительно S1-U (X2-U). В случае если S1-U (X2-U) является IPv6-трактом, то фрагментация может быть выполнена посредством eNB/SGW. Однако следует отметить, что повторная сборка является наиболее интенсивным с точки зрения обработки и памяти процессом, и следовательно она выполняется в eNB/SGW и для очень большого числа потоков.
Фрагментация туннелирования IP-пакета согласно IPSec: принцип является почти таким же, как для фрагментации туннелирования IP-пакетов согласно S1-U (X2-U). Однако одно отличие состоит в том, что повторная сборка должна выполняться в шлюзе безопасности (SEG), тогда как фрагментация может выполняться в узле, который осуществляет интерфейс с линией связи с самым малым MTU для тракта S1-U (X2-U) в случае IPSec туннеля по IPv4, тогда как это должно выполняться SEG в случае IPSec туннеля по IPv6.
Кроме того, определение MTU может быть разделено на различные типы определения MTU, а именно определение MTU сквозного тракта, определение MTU тракта для S1-U (X2-U) и определение MTU тракта для SEG-SEG (между шлюзами безопасности).
Для определения MTU сквозного тракта IP-хосты, завершающие сквозной IP-поток, могут выполнять определение MTU тракта. Однако следует отметить, что имеется ряд конфигураций/вариантов реализации (для брандмауэров/шлюзов), которые отбрасывают ряд сообщений ICMP для IPv4, включая сообщение «Packet Too Big». Следовательно, может полагаться, что определение MTU сквозного тракта не используется в случае IPv4.
С другой стороны, в случае IPv6 хосты имеют две возможности: использовать MTU в 1280 октетов (то есть минимальный MTU, который должен поддерживать каждый узел с возможностью IPv6) либо использовать определение MTU сквозного тракта. При рассмотрении проблем, связанных с определением MTU тракта, для TCP предпочитают применять общее значение MTU тракта для S1-U (X2-U) в полном административном домене для узлов eNB в любом случае, чтобы избегать изменения MTU сквозного тракта вследствие мобильности. Следует отметить, что если общий MTU не применяется в административном домене для узлов eNB, то допустимые временные ограничения для увеличения MTU эффективно ликвидируют выгоды от «переменного» MTU в административном домене, поскольку передачи обслуживания являются на несколько порядков более частыми.
Для определения MTU тракта для S1-U (X2-U), eNB и SGW могут использовать определение тракта MTU вместо административно задаваемого MTU тракта для S1-U (X2-U). Поскольку S1-U (X2-U) задаются для использования доверенных сетей, можно также полагать, что оператор имеет прямой или опосредованный контроль над обработкой сообщений ICMP, и, следовательно, определение MTU тракта может использоваться независимо от версии IP, используемого для туннелирования по S1-U (X2-U).
Для определения MTU тракта для SEG-SEG SEG может использовать определение MTU тракта вместо административно задаваемого MTU туннеля. Однако это может использоваться только в случае IPSec-туннеля для IPv6, поскольку он не может основываться на сообщениях ICMP «Packet Too Big» в случае туннеля для IPv4.
Для eNB может быть задан MTU линии связи в соответствии с MTU административного домена, к которому он относится. Кроме того, можно рассматривать вариант, когда MME осведомлен о заданном MTU линии связи в eNB. Если этот MTU будет доступен хосту в UE, стек IP в UE может обеспечивать нижеследующее поведение, которое значительно уменьшает необходимость фрагментации в сети.
В случае протокола транспортного уровня, который имеет MSS, например, протокола TCP, UE могут выбирать как MSS передачи, так и MSS приема с учетом задаваемого сетью MTU «линии связи», и, следовательно, фрагментация может быть исключена в целом (или по меньшей мере в домене сети SAE/LTE). В случае протокола транспортного уровня, который не имеет MSS, например протокола UDP, UE может фрагментировать передаваемую дейтаграмму в источнике в соответствии с задаваемым сетью MTU «линии связи», и, следовательно, фрагментация может избегаться по меньшей мере в направлении восходящей линии связи.
С учетом выгод, обеспечиваемых путем задания MTU «линии связи» в UE в соответствии с MTU административного домена, к которому относится eNB, причем по отношению к UE установлен канал SAE, рекомендуется обеспечивать функциональность задания MTU «линии связи» при установлении/изменении канала SAE (например, включаемую в NAS: установление/изменение канала SAE) в соответствии с известным MME значением MTU тракта для S1-U для соответственного eNB.

Claims (12)

1. Способ задания максимального размера передаваемого блока данных (MTU) линии связи в пользовательском устройстве (UE), выполненном с возможностью соединения с сетью радиосвязи архитектуры развития системной архитектуры/долговременного развития (SAE/LTE), отличающийся этапом, на котором сигнализируют поддерживаемое сетью SAE/LTE значение MTU в UE в одном из сообщения Non Access Stratum (NAS) от модуля управления мобильностью (ММЕ) и сообщения управления радиоресурсами (RRC) от усовершенствованного узла В (eNB).
2. Способ по п.1, в случае, если протокол транспортного уровня линии связи имеет характеристику «максимальный размер сегмента» (MSS), отличающийся тем, что MSS передачи и/или приема выбирают на основании MTU, сигнализированного в UE.
3. Способ по п.2, отличающийся тем, что протокол транспортного уровня поддерживает сигнализацию MSS приема и выбор MSS передачи.
4. Способ по п.2, отличающийся тем, что протоколом транспортного уровня является протокол управления передачей (TCP) или протокол передачи с управлением потоком (SCTP).
5. Способ по п.1, в случае, если в протоколе транспортного уровня для линии связи отсутствует сигнализация максимального размера сегмента (MSS) приема, отличающийся тем, что UE выполнено с возможностью фрагментации передаваемой дейтаграммы в источнике на основе MTU, сигнализированного в UE.
6. Способ по п.5, отличающийся тем, что протоколом транспортного уровня является UDP.
7. Способ по любому из пп.1-6, отличающийся тем, что сигнализированный MTU линии связи устанавливается в самое высокое значение, поддерживаемое сетью SAE/LTE.
8. Пользовательское устройство (UE), выполненное с возможностью соединения с сетью радиосвязи архитектуры развития системной архитектуры/долговременного развития (SAE/LTE) и отличающееся средством для приема данных, содержащих максимальный размер передаваемого блока данных (MTU) линии связи, поддерживаемый сетью SAE/LTE, причем упомянутое средство содержит одно из средства для приема MTU линии связи в сообщении Non Access Stratum (NAS) и средства для приема MTU линии связи в сообщении управления радиоресурсами (RRC).
9. Пользовательское устройство (UE) по п.8, отличающееся средством для выбора максимального размера сегмента (MSS) передачи и/или приема для протокола транспортного уровня на основе MTU, сигнализированного в UE.
10. Пользовательское устройство (UE) по п.8, отличающееся средством для обеспечения возможности фрагментации передаваемой дейтаграммы в источнике на основании MTU, сигнализированного в UE.
11. Узел в сети радиосвязи архитектуры развития системной архитектуры/долговременного развития (SAE/LTE), отличающийся средством для сигнализации MTU, поддерживаемого сетью SAE/LTE, в пользовательское устройство (UE), соединенное с сетью, причем упомянутое средство содержит одно из средства для сигнализации MTU линии связи в сообщении Non Access Stratum (NAS) и средства для сигнализации MTU линии связи в сообщении управления радиоресурсами (RRC).
12. Узел по п.11, отличающийся средством для установки сигнализированного MTU линии связи в самое высокое значение, поддерживаемое сетью SAE/LTE.
RU2009138928/07A 2007-03-22 2008-02-05 Способ задания максимального размера передаваемого блока данных (mtu) линии связи в пользовательском устройстве (ue) RU2480931C2 (ru)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
SE0700725-5 2007-03-22
SE0700725 2007-03-22
PCT/SE2008/050142 WO2008115124A2 (en) 2007-03-22 2008-02-05 Method for configuring the link maximum transmission unit (mtu) in a user equipment (ue)

Publications (2)

Publication Number Publication Date
RU2009138928A RU2009138928A (ru) 2011-04-27
RU2480931C2 true RU2480931C2 (ru) 2013-04-27

Family

ID=39766613

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2009138928/07A RU2480931C2 (ru) 2007-03-22 2008-02-05 Способ задания максимального размера передаваемого блока данных (mtu) линии связи в пользовательском устройстве (ue)

Country Status (15)

Country Link
US (2) US9088915B2 (ru)
EP (1) EP2122927A4 (ru)
JP (1) JP2010522465A (ru)
KR (1) KR20100014507A (ru)
CN (1) CN101663864B (ru)
AU (1) AU2008227222B2 (ru)
BR (1) BRPI0807398A2 (ru)
CA (1) CA2681314A1 (ru)
IL (1) IL199289A (ru)
MA (1) MA31262B1 (ru)
MX (1) MX2009006849A (ru)
NZ (1) NZ577563A (ru)
RU (1) RU2480931C2 (ru)
WO (1) WO2008115124A2 (ru)
ZA (1) ZA200904102B (ru)

Families Citing this family (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
BRPI0816232A2 (pt) * 2007-08-20 2015-02-24 Ntt Docomo Inc Método de transmissão e estação móvel e base de rádio
JP5374929B2 (ja) * 2008-06-05 2013-12-25 富士通株式会社 移動通信システム、移動通信方法および通信装置
US9069727B2 (en) * 2011-08-12 2015-06-30 Talari Networks Incorporated Adaptive private network with geographically redundant network control nodes
JP5091205B2 (ja) * 2009-07-02 2012-12-05 株式会社エヌ・ティ・ティ・ドコモ 移動通信方法、移動通信システム及び移動局
CN102939729B (zh) * 2010-06-09 2017-06-09 三星电子株式会社 移动通信系统和移动通信系统中的分组控制方法
CN103262606B (zh) * 2010-12-21 2018-10-12 瑞典爱立信有限公司 对gtp隧道中的ip分片的改进
CN102833750A (zh) * 2011-06-16 2012-12-19 中兴通讯股份有限公司 消息传输方法及装置
CN102355656B (zh) * 2011-07-27 2014-01-01 大唐移动通信设备有限公司 获取ue身份标识相关信息的方法及装置
EP2737731B1 (en) * 2011-07-29 2016-05-18 SCA IPLA Holdings Inc. Reduced context or context-less short message transmission for machine-type-communication
US9276810B2 (en) * 2011-12-16 2016-03-01 Futurewei Technologies, Inc. System and method of radio bearer management for multiple point transmission
CN103391528B (zh) * 2012-05-11 2016-12-14 南京中兴新软件有限责任公司 一种在终端侧自动配置mtu值的方法及相应装置
GB2513344B (en) * 2013-04-23 2017-03-15 Gurulogic Microsystems Oy Communication system utilizing HTTP
CN103297348A (zh) * 2013-05-10 2013-09-11 汉柏科技有限公司 防止esp/ah报文分片的方法
US9973596B2 (en) * 2013-06-19 2018-05-15 Cisco Technology, Inc. Dynamically adjusting frame MTU to support low-latency communication
US20150106530A1 (en) * 2013-10-15 2015-04-16 Nokia Corporation Communication Efficiency
US9338231B2 (en) * 2014-03-18 2016-05-10 Sling Media, Inc Methods and systems for recommending communications configurations
US9787596B2 (en) * 2015-01-26 2017-10-10 Mediatek Inc. Maximum transmission unit size reporting and discovery by a user equipment
WO2017142575A1 (en) * 2016-02-19 2017-08-24 Intel Corporation Maximum transmission unit (mtu) size reconfiguration for an lwip operation
EP3280109B1 (en) * 2016-08-02 2019-10-09 Nash Innovations GmbH Apparatus, method and computer program for a base station transceiver of a mobile communication system
US10476808B1 (en) 2018-03-07 2019-11-12 Sprint Spectrum L.P. Dynamic configuration of maximum transmission unit of UE, based on receipt of oversized packet(s) at network entity
US10638363B2 (en) * 2018-04-04 2020-04-28 At&T Intellectual Property I, L.P. Legacy network maximum transmission unit isolation capability through deployment of a flexible maximum transmission unit packet core design
US10841834B2 (en) 2018-04-04 2020-11-17 At&T Intellectual Property I, L.P. Legacy network maximum transmission unit isolation capability through deployment of a flexible maximum transmission unit packet core design
CN111163037A (zh) * 2018-11-07 2020-05-15 大唐移动通信设备有限公司 Ip分片优化方法和装置
EP3884630A1 (en) * 2018-11-20 2021-09-29 Telefonaktiebolaget Lm Ericsson (Publ) Method and arrangement for determining indication of maximum datagram size supported without fragmentation in an ip network
CN113162866B (zh) * 2020-01-22 2023-08-01 中国移动通信有限公司研究院 一种报文传输方法、通信设备及介质
CN112367685B (zh) * 2020-10-22 2022-07-08 Tcl通讯（宁波）有限公司 一种改进NR eMBB业务传输性能的方法、装置及移动终端
US20230319633A1 (en) * 2022-03-31 2023-10-05 Fortinet, Inc. Steering fragmentation of data packets on data communication networks based on data packet size

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005054986A2 (en) * 2003-11-25 2005-06-16 Nokia Corporation Apparatus, and associated method, for facilitating communication of unfragmented packet-formatted data in a radio communication system
RU2258251C2 (ru) * 2000-04-24 2005-08-10 Майкрософт Корпорейшн Предоставление удаленных услуг в соответствии со спецификацией интерфейса сетевого драйвера в беспроводной радиочастотной среде
JP2006157544A (ja) * 2004-11-30 2006-06-15 Kyocera Corp パケット通信装置、パケット通信システムおよびパケット通信制御方法

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7512120B2 (en) * 2002-07-09 2009-03-31 Ntt Docomo, Inc. Node, correspondent node, mobility anchor point, and home agent in packet communication system, packet communication system, and path MTU discovery method
US7542471B2 (en) * 2002-10-30 2009-06-02 Citrix Systems, Inc. Method of determining path maximum transmission unit
GB2398699A (en) * 2003-02-18 2004-08-25 Motorola Inc Determining a maximum transmission unit which may be transmitted over a particular route through a network
KR100513282B1 (ko) * 2003-05-02 2005-09-09 삼성전자주식회사 에드 혹 네트워크에서의 패스 엠티유를 이용하여 데이터를 송신하는 데이터 송신 노드 및 송신 방법
KR100506529B1 (ko) * 2003-08-06 2005-08-03 삼성전자주식회사 데이터 통신 네트워크에서의 경로 엠티유 발견 네트워크장치, 시스템 및 그 방법
US7684440B1 (en) * 2003-12-18 2010-03-23 Nvidia Corporation Method and apparatus for maximizing peer-to-peer frame sizes within a network supporting a plurality of frame sizes
US7505484B2 (en) * 2004-08-26 2009-03-17 International Business Machines Corporation Remote discovery and storage of a path maximum transmission unit (PMTU) value
ES2560450T3 (es) * 2005-04-13 2016-02-19 Vringo Infrastructure Inc. Técnicas de gestión de recursos de radioenlaces en redes inalámbricas destinadas al tráfico de paquetes de datos
WO2007077526A2 (en) * 2006-01-05 2007-07-12 Nokia Corporation A flexible segmentation scheme for communication systems
US7738495B2 (en) * 2006-01-23 2010-06-15 Cisco Technology, Inc. Method of determining a maximum transmission unit value of a network path using transport layer feedback
EP1853011A1 (en) * 2006-05-02 2007-11-07 Alcatel Lucent Method for transmission of high speed uplink packet access data information in a cellular communications system
KR20080071500A (ko) * 2007-01-30 2008-08-04 이노베이티브 소닉 리미티드 무선통신시스템에서 패킷을 처리하는 방법 및 장치
US8855099B2 (en) * 2007-03-19 2014-10-07 Qualcomm Incorporated Selective phase connection establishment

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2258251C2 (ru) * 2000-04-24 2005-08-10 Майкрософт Корпорейшн Предоставление удаленных услуг в соответствии со спецификацией интерфейса сетевого драйвера в беспроводной радиочастотной среде
WO2005054986A2 (en) * 2003-11-25 2005-06-16 Nokia Corporation Apparatus, and associated method, for facilitating communication of unfragmented packet-formatted data in a radio communication system
JP2006157544A (ja) * 2004-11-30 2006-06-15 Kyocera Corp パケット通信装置、パケット通信システムおよびパケット通信制御方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
3GPP TR R3.018 V0.7.1, Evolved UTRA and UTRAN; Radio Access Architecture and Interfaces, 02.2007, http://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_55/docs/R3-070296.zip. 3GPP TSG-RAN3#55, NTT DoCoMo, Impact of IP Fragmentation in E-UTRAN interfaces, 15.02.2007, http://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_55/docs/R3-070080.zip. *

Also Published As

Publication number Publication date
CN101663864B (zh) 2012-08-22
IL199289A (en) 2013-06-27
US9088915B2 (en) 2015-07-21
NZ577563A (en) 2012-04-27
WO2008115124A2 (en) 2008-09-25
US20110243063A1 (en) 2011-10-06
US9603057B2 (en) 2017-03-21
AU2008227222A1 (en) 2008-09-25
RU2009138928A (ru) 2011-04-27
MX2009006849A (es) 2009-10-08
JP2010522465A (ja) 2010-07-01
BRPI0807398A2 (pt) 2014-05-27
EP2122927A2 (en) 2009-11-25
KR20100014507A (ko) 2010-02-10
AU2008227222B2 (en) 2011-06-02
US20150326487A1 (en) 2015-11-12
WO2008115124A8 (en) 2009-08-27
MA31262B1 (fr) 2010-03-01
EP2122927A4 (en) 2014-12-24
CA2681314A1 (en) 2008-09-25
ZA200904102B (en) 2010-08-25
WO2008115124A3 (en) 2008-11-13
CN101663864A (zh) 2010-03-03

Similar Documents

Publication Publication Date Title
RU2480931C2 (ru) Способ задания максимального размера передаваемого блока данных (mtu) линии связи в пользовательском устройстве (ue)
JP6328196B2 (ja) 移動通信システムにおける無線プロトコル処理方法及び移動通信送信機
US7143282B2 (en) Communication control scheme using proxy device and security protocol in combination
TWI394408B (zh) 在一無線通訊系統中傳輸資料的方法
US8462692B2 (en) System and method for reassembling packets in relay node
US20130279464A1 (en) Ip fragmentation in gtp tunnel
EP1698190B1 (en) Arrangements and method for handling macro diversity in utran transport network
KR100624686B1 (ko) 패킷 투 빅 메시지를 이용하여 아이피브이식스 천이터널에서 패킷 최대전송단위를 설정하는 시스템 및 그 방법
WOZNIAK et al. The Need for New Transport Protocols on the INTERNET
EP3103279B1 (en) Mtc device, serving node, and various methods for implementing an uplink stack reduction feature
Oran et al. Security Review and Performance Analysis of QUIC and TCP Protocols
Cruickshank et al. Broadband Satellite Multimedia (BSM) security architecture and interworking with performance enhancing proxies
Cruickshank et al. Broadband satellite multimedia (BSM) interworking with performance enhancing proxies
Koukoutsidis TCP over 3G links: Problems and Solutions
Genkov An algorithm and software for finding proper packet size in an IPv6 network using double connection
Koukoutsidis TCP over 3G links
Gkroustiotis QoS in heterogeneous mobility management