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

Формула изобретения

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.

Описание изобретения к патенту

Описание

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

Настоящее изобретение относится к способам и устройствам в телекоммуникационной системе, конкретно к способам и устройствам для управляемого сетью задания максимального размера передаваемого блока данных (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.