﻿
]>
Considerations for MPTCP operation in 5GInterDigital Communications, LLC1000 Sherbrooke WestMontrealCanadaXavier.Defoy@InterDigital.comInterDigital Communications, LLCMontrealCanadaMichelle.Perras@InterDigital.comHuawei USA2330 Central ExpresswaySanta Clara95050USACAuma.chunduri@huawei.comNational Institute of Information and Communications TechnologyYRP Center No.1 Building 7F, 3-4 Hikarinooka, YokosukaKanagawa239-0847Japankienng@nict.go.jpNational Institute of Information and Communications TechnologyYRP Center No.1 Building 7F, 3-4 Hikarinooka, YokosukaKanagawa239-0847Japanmirza.kibria@nict.go.jpNational Institute of Information and Communications TechnologyYRP Center No.1 Building 7F, 3-4 Hikarinooka, YokosukaKanagawa239-0847Japanishidu@nict.go.jpNational Institute of Information and Communications TechnologyYRP Center No.1 Building 7F, 3-4 Hikarinooka, YokosukaKanagawa239-0847Japanf-kojima@nict.go.jp
This document describes scenarios where the behavior of the 5G mobility management framework is different
from earlier cellular generations, and describes how it may benefit from some form of adaptation of MPTCP
implementations and protocol aspects in the 5G system.
This document also describes how MPTCP may be leveraged in 5G system specifications.
MPTCP is being deployed and widely adopted in today’s smart devices,
which typically have multiple network interfaces such as Cellular and Wifi.
It provides reliability, bandwidth aggregation capability, and handover efficiency.
This document describes scenarios where the behavior of the 5G mobility management
framework is different from earlier cellular generations, and describes how it may
benefit from some form of adaptation of MPTCP implementations and protocol aspects
in the 5G system (see ).
This document also describes how MPTCP may be leveraged in 5G system specifications
(see ).
With regards to 5G session and service continuity mechanisms,
MPTCP stack behavior (including path manager and scheduling)
should be updated to achieve optimal performance:
Proposed 5G MPTCP behavior is described in ,
and .
To enable this behavior, MPTCP will need additional information about local IP addresses:
(1) its session continuity service type and (2) a notification that a new IP address has been provided
for service continuity.
This is described in .
Remote MPTCP peers may need access to the IP address SCS type (through MPTCP signaling
or otherwise). This is discussed in .
With regards to dual connectivity, MPTCP can be closely integrated with the 5G stack
to avoid duplicating its feature in 5G, as discussed in .
As a summary:
MPTCP should be aware of the
presence of multiple DC radio links, which may be exposed as a single or distinct
network interfaces/IP addresses.
MPTCP should optimally partition
traffic or duplicate a data flow over DC links, depending on the
application's need, network policy and conditions.
One of the goals of 5G systems, as outlined in ,
is to enable low latency services and access to local data networks where mobility anchors
can be deployed close to devices, thereby satisfying use cases with stringent transmission
delay and high reliability.
Mobility in 4G networks, as described at the architecture level in
,
was based on a central mobility solution that made it difficult to relocate mobility anchors
closer to the end user.
In contrast, 5G uses a distributed mobility solution based on multiple
anchors providing different IP addresses as the device moves from one area to another.
The base scenario in this section is: a 5G device connected to a single-homed server
is in an area with no usable Wifi coverage.
An application using MPTCP sends traffic over a single subflow,
over the cellular air interface.
Then, as the device moves, the 5G device reacts to
mobility events.
Additionally, we briefly discuss cases where the device switches from a Wifi to a cellular backup
connection,
and other cases where both MPTCP peers are 5G mobile devices.
In 5G, every unit of a network connectivity service (PDU session) has a type which
can be IP (IPv4 or IPv6),
Ethernet or
unstructured.
While session continuity is supported for all types, we will focus on
PDU sessions of IP type primarily.
Different PDU sessions will typically correspond to distinct network interfaces on the device
(though this is not explicit in the standard, and some implementations may possibly
behave differently).
In 4G networks, session continuity is enabled by
anchoring a PDN Connection (as PDU Sessions are referred to in 4G networks) to a
P-GW which allocates an IP address to the mobile device:
PDN connection and IP address allocation are maintained as long as
the device remains attached to the network, even when the device moves around.
In 5G, different types of session continuity can be provided, and are indicated by a
"Session and Service Continuity" (SSC) mode value of 1, 2 or 3 (defined in
section 5.6.9).
Every PDU session is associated
with a single SSC mode, which cannot be changed on this PDU session.
The following sub-sections will study how 5G handles each SSC mode, and potential
effects on MPTCP.
IP Address Session Continuity Service Type
The "session continuity service type" (SCS type)
of an IP address allocated by the network can be used as input by MPTCP implementations. It has
been defined for on-demand mobility management , as:
FIXED IP address: valid for a very long time, for session continuity and IP address reachability.SESSION_LASTING IP address: valid for the lifetime of an IP session, even if the mobility host moves.NON_PERSISTENT IP address: which does not provide session continuity nor IP address reachability.GRACEFUL_REPLACEMENT IP address: similar to a non-persistent address,
but adding a limited graceful period for the transition from one address to another.
This information needs to be conveyed to the device by the network that allocates the address: for example,
as described in ,
the SCS type of IP address may be conveyed through router advertisements.
The MPTCP stack may obtain the SCS type of a local IP address using a programmatic API.
This information does not directly tell which SSC mode the application is using, nevertheless it
is sufficient for MPTCP to appropriately and non-ambiguously decide how to handle
new IP addresses in the context of SSC in 5G.
Notification of a New IP Address from Session Continuity
As in non-5G cases, MPTCP starts handling the initial socket created by the application.
The initial connection attempt triggers the creation of the first PDU session
(or the reuse of an existing one), associated
with a network interface and an IP address on this interface.
Later on, the network decides to use a new anchor,
e.g., when a mobility event occurs or when a Local Data Network becomes available.
The network then triggers the modification of the existing PDU session,
or creation of a new PDU session, and ultimately
a new IP address is provided to the 5G device, respectively on the same or a new network interface.
The 5G stack on the device is aware of the relationship between the old and new IP addresses,
and can therefore notify the MPTCP stack.
Such a notification may include both the old and new IP addresses
, which ensures that the MPTCP stack has all necessary information
(for example, the MPTCP stack may then obtain the SCS type of the new IP address,
and the validity lifetime associated with the old IP address, if it is still up).
In SSC mode 1 the same network anchor is kept regardless of device location.
An application running
on the device will therefore be able to keep using the same IP address on the same interface.
Additionally, in SSC mode 1, the network may decide to add and remove, dynamically,
additional network anchors (and therefore IP addresses)
to the PDU session, while always keeping the initial one.
PROPOSED MPTCP BEHAVIOR SPECIFICATION:
These steps are applicable when the initial IP address returned by the network stack is FIXED or SESSION_LASTING.
MPTCP should not close all subflows originated
from this original IP address at any point during the session, since this IP address is the only one
that is guaranteed, under normal circumstances, to be maintained over time for this application.
At any time during the session, a new IP address of SCS type NON_PERSISTENT may become available.
MPTCP may create new subflows for the application, using this IP address
(this IP address is likely to provide shorter path subflows, but may disappear at any time).
SSC mode 2 has a break-before-make behavior. When the device leaves the service area of
its first network anchor,
the network stops using it and starts using a new second network anchor closer to the device.
(Such service areas may have a highly variable size depending on network deployments.)
On the device, this can result in the currently used network interface being brought down, and
after a short time a new network interface being brought up.
The time between these 2 events is not standardized and implementation dependent.
Break-before-make within cellular technology
When MPTCP is active on cellular only, this break-before-make behavior is similar to
the existing break-before-make capability usually used in cellular/Wifi offload
(section 3.1.3 of
and section 2.2 of ).
A similar MPTCP behavior is therefore needed: wait for a given time for a new IP
address to be configured.
As per , to benefit from this MPTCP resilience feature,
the application should not request using a specific network interface.
Cellular and Wifi
Additionally, when Wifi is active and cellular is used as backup, MPTCP implementations should also
support this break-before-make behavior to maintain a usable backup IP address on cellular.
In rare cases where a switch-to-cellular backup would be needed during a break-before-make
transition on cellular, MPTCP's existing break-before-make capability can ensure MPTCP waits for
a new cellular-facing IP address to be available.
PROPOSED MPTCP BEHAVIOR SPECIFICATION:
These steps are applicable when the initial IP address returned by the network stack is NON_PERSISTENT.
At any point in time, the current NON_PERSISTENT IP address may be taken down by the
network stack.
The MPTCP stack should wait for another NON_PERSISTENT IP address to be made
available by the network stack.
If such an address is made available within a given time limit, the MPTCP stack should
create new subflows using this new address (effectively following the existing break-before-make
behavior present in MPTCP).
Additionally, if an initial backup IP address is a NON_PERSISTENT address, the MPTCP stack
should consider any subsequent NON_PERSISTENT IP address as a backup IP address in
replacement of the initial NON_PERSISTENT address.
SSC mode 3 has a make-before-break behavior. When the device leaves the service area of
its first network anchor, the network selects a second network anchor closer to the device, and either creates
a new PDU session (i.e. new IP address on new network interface) or
share the existing PDU session (i.e. new IP address on same network interface).
The first network anchor keeps being used for a given time period,
which is communicated to the device by the network using the "valid lifetime" field
of a prefix information option in a router advertisement (,
).
5G does not mandate a specific range for this valid lifetime.
The first/older IP address should not be used to create any new traffic ( section 5.5.4).
In some implementations, the network (SMF) may decide to release the first network anchor as soon as
it stops carrying traffic.
There is no limit set by the 5G standard for the number of concurrently used network anchors.
We expect that in usual cases the first network anchor will be released before a third network anchor starts
being used.
Nevertheless, to our knowledge nothing prevents a 5G system deployment to allow a third network anchor to be
selected while the first one is still in use.
On the 5G device, when using SSC mode 3, mobility will therefore result in a new IP address
being configured, either on the same
network interface initially used, or on a different interface.
In general, an application will see a single cellular-facing IP address,
and during transient phase it will see 2 IP addresses
(with a possibility for more than 2 concurrent IP addresses on some 5G system implementations).
In cases where the server is single-homed and the Wifi interface is down, and assuming
a full-mesh path manager policy, there will be in general one subflow, and from time to time,
temporarily 2 subflows (or more on some 5G systems).
In cases where two mobile 5G devices are communicating with each other over MPTCP
and with the same assumptions on Wifi
and path manager policy, there will be in general one subflow, and from time to time, temporarily 2
or even more rarely 4 subflows (again, possibly more on some 5G systems).
MPTCP must create new subflows when a new IP address
on a same or a new cellular-facing network interface becomes available to the application.
MPTCP may keep using the first subflow during a transient phase.
Here are some considerations related to this transient phase:
When compared with simply waiting for the first IP address to be brought down,
ramping down usage of the first subflow will not incur
inefficiencies from resending lost segments.
This may especially help low-latency applications by avoiding throughput drop.
Assuming a lowest-rtt-first scheduling policy is used, after the initial TCP slow start,
the shortest path subflow should typically carry the most traffic.
Ramping down should ideally start after the initial slow start is over.
To make sure the ramping down completes before the interface is brought down by the network,
the MPTCP stack should be aware of how long will the first network anchor be kept in use, e.g. through
configuration or communication with the local 5G stack.
Ramping down and closing flows on the first network anchor as soon as possible will help recycling
network resources more rapidly. This is especially true in cases where more than 2
network anchors may be used concurrently.
There may be some level of contention between subflows during the transient phase,
since they share the same air interface, and especially if they share the same PDU session and QoS marking.
The shortest path subflow may therefore not reach its full capacity during the transient phase.
Additionally, the shortest subflow must not be closed during the transient
phase (even if it is less efficient for some reason), to avoid losing all connectivity
at the end of the transient phase.
To avoid this issue, the MPTCP stack could for example follow a policy not to close
any subflow created using the latest IP address, during the transient period (in SSC mode 3).
In cases where cellular is used for backup, there is a possibility that
the switch to using backup occurs during a transient phase.
To support this case, MPTCP should keep creating and releasing subflows as described above,
even when cellular subflows are used as backup, to ensure that the backup is always usable.
When a backup event occurs during a transient phase, MPTCP should use the subflows associated
with the most recent cellular-facing IP address, i.e. corresponding to the latest/closest network anchor.
PROPOSED MPTCP BEHAVIOR SPECIFICATION:
These steps are applicable when the initial IP address returned by the network stack is GRACEFUL_REPLACEMENT.
At any point in time, a new GRACEFUL_REPLACEMENT IP address may be made available by the
network stack.
The MPTCP stack must create new subflows using this new address,
gracefully transfer traffic to these new subflow(s), and close subflow(s) using the previous
GRACEFUL_REPLACEMENT IP address before its scheduled closing (known by obtaining the valid
lifetime of the IP address from the operating system).
Additionally, if an initial backup IP address is a GRACEFUL_REPLACEMENT address, the MPTCP stack
should consider any subsequent GRACEFUL_REPLACEMENT IP address as the new backup IP address,
in replacement of the first GRACEFUL_REPLACEMENT IP address.
The SCS type of an IP address is only available locally, which limits to only one peer the
MPTCP behavior specified in sections ,
and .
This can potentially cause problems:
A remote may for example close subflows that should be maintained
e.g. closing all subflows to a SESSION_LASTING IP address or to the latest GRACEFUL_REPLACEMENT address.
A remote may also not behave optimally in some
cases, e.g. because it cannot distinguish between a transition from GRACEFUL_REPLACEMENT to GRACEFUL_REPLACEMENT,
from a temporary addition of a NON_PERSISTENT address to a SESSION_LASTING address.
There are two possible ways to handle this: either explicitly transmit the SCS type over MPTCP signalling,
or use heuristics on the remote peer (e.g. never close a subflow created by a peer, mirror behavior
of peer, etc.).
In the explicit solution, a MPTCP peer provides the SCS type of IP addresses to its remote peer,
using existing or new options (mp_capable, add_addr, mp_join, or an experimental option).
When compared to using heuristics, transmitting the SCS type can
lead to a less complex and more explicit implementation, which can help
better handling unusual or error cases, and adapt to future evolution of 5G or other mobility
management systems.
One of the key features of 5G [_3GPP.23.501] is dual connectivity (DC).
With DC, a 5G device can be served by two different base stations.
DC may play an essential role in leveraging the benefit of 5G new radio,
especially in the evolving architecture with the coexistence of 4G and 5G radios.
On a 5G device with DC, an application is able to send data to the
destination (e.g., a single-home server) through multiple radio
links, over one or more PDU sessions.
Some PDU sessions may be over a single radio link, while others may
have flows over each radio link.
Therefore, in a first case, DC can be made visible to applications
through different IP addresses, while in a second case, DC can be
used by different flows terminated at the same IP address on the device.
In any of those cases, the issues of out of order delivery and diverse
latency values need to be supported in DC.
However, such
reliable communication scenarios have not been addressed in the
current DC architecture.
Based on the design history of DC in earlier systems,
the 5G system will need to incorporate features
to support robustness/reliability (e.g., backup and duplication),
that will likely result in added complexity.
Meanwhile, similar issues have been solved in MPTCP (e.g., two types of sequences
at subflow and connection levels for out of order delivery, etc.).
MPTCP hence could be leveraged in those scenarios.
On the other hand, to satisfy new QoS requirements of 5G applications as well as to benefit the most from DC,
5G devices are expected to include advanced algorithms that control data transmissions over
each radio link optimally.
For example, those algorithms could aim to minimize
overall latency or satisfy latency requirements of applications.
Hence, the 5G device needs to dynamically select the most suitable path for a given radio condition.
Additionally, algorithms for shifting, based on congestion, ongoing traffic between transmissions
over radio links are also necessary.
MPTCP, which includes path manager, scheduler, and congestion
control functions, shows a lot of potential to address the issues mentioned above.
MPTCP could, therefore, be integrated with DC and the 5G protocol stack,
as an alternative to developing 5G-specific solutions.
As part of this integration, the MPTCP stack should be aware of the
presence of multiple radio links, whether they are exposed
using multiple IP addresses or hidden under a single IP address.
MPTCP's scheduler should optimally partition
traffic or duplicate a data flow over different links, depending on the
application's need, network policy, and conditions.
This document requests no IANA actions.
No new security considerations are identified at this time.
Thanks to following people for contributing, reviewing or providing feedback:
Debashish Purkayastha,
Akbar Rahman,
Ulises Olvera-Hernandez,
Sri Gundavelli.
&rfc4861;
&rfc4862;
&rfc6824;
&rfc6897;
&rfc8041;
&I-D.feng-dmm-ra-prefixtype;
&I-D.ietf-dmm-ondemand-mobility;
System Architecture for the 5G System
3GPPGeneral Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access
3GPP