Prior art
[0001] The invention relates to the general field of
10 telecommunications.
[0002] More specifically, it relates to the management
of encrypted communications in a telecommunications
network. The invention has a preferred application, in
particular within the context of a 5G telecommunications
15 network as defined by the 3GPP (Third Generation
Partnership Project) standard. However, it also can be
applied within the context of another network, such as a
4G network, a proprietary network, etc.
[0003] The user equipments of the telecommunications
20 networks, and in particular the terminals, such as
smartphones or personal computers (or PC), are now
capable of activating and operating several logical
interfaces linked to one or more physical interfaces, so
that they may or may not simultaneously connect to
25 various types of network (for example, fixed network,
mobile network, wireless local area network) via various
IP (Internet Protocol) addresses. Such user equipments
are called “Multi-InterFaces” (or MIF).
[0004] It should be noted that the MIF feature of a user
30 equipment is volatile since its ability to use several
interfaces depends on the conditions for connecting to
the one or more networks, its location, or even other
factors. An MIF user equipment can particularly use all
or some of the interfaces it has available when
35 establishing a simple connection with a correspondent
(i.e., established along a single path with this
correspondent), or even after establishing a simple
connection. Moreover, it also should be noted that an MIF
WO 2022/069825 PCT/FR2021/051663
2
user equipment does not know a priori whether it is
possible to use several distinct paths to establish
communication with a given correspondent: the user
equipment only acquires this information, if applicable,
5 on completion of a phase during which it attempts to
establish communication with the correspondent by using
multiple paths.
[0005] When a user equipment has several interfaces
capable of connecting it to various access networks (for
10 example, fixed, mobile, WLAN (Wireless Local Area
Network)) in order to connect to a core network, it then
benefits from access that is referred to as “hybrid”
access, combining different access network technologies.
The offers of services concerning a user equipment having
15 a hybrid access rely on introducing functions into the
core network that allow all the network connections of a
user equipment to be aggregated (for example: WLAN and
4G, or ADSL, WLAN and 5G). It should be noted that
aggregating links involves consolidating several links
20 associated with several logical interfaces as if it were
a single link associated with a single interface, in
particular with the aim of increasing the throughput
beyond the limits of a single link, of applying the same
operating procedures to all the links thus aggregated,
25 of distributing the traffic between several links, or
even of causing other interfaces (and therefore other
access networks) to take over if one of these links fails
(redundancy principle). Link aggregation applies to any
type of traffic routed along these links, including IP
30 traffic.
[0006] The MPTCP (Multi-Path Transmission Control
Protocol) protocol was initially proposed to address the
requirements raised by a context where a user equipment
is able to connect to a network via several interfaces
35 in order to establish communication based on the TCP
protocol. The MPTCP protocol particularly addresses the
requirements of ensuring clear session continuity for the
user in the event of any mobility of the user equipment.
WO 2022/069825 PCT/FR2021/051663
3
By way of a reminder, the TCP connections of a user
equipment are identified by an IP address and a port
number, so that any modification of this identification
information is likely to be detrimental to the operation
5 of an ongoing TCP connection, and thus the service using
said TCP connection. Such a change in IP address or port
number is particularly detrimental when the user
equipment is assigned a new IP address, or because the
user equipment is connected to another network, or even
10 when the interface with which the IP address is
associated is no longer available. Means for notifying
the remote TCP correspondent that an IP address is no
longer valid are then necessary to ensure that an
existing connection is maintained (for example, in the
15 case of long duration TCP connections). The MPTCP
protocol has been proposed particularly in order to
minimize the risks of the untimely interruption of the
TCP connections linked to such modifications of the IP
addressing.
20 [0007] However, the MPTCP protocol is only a partial
solution to the general problem of aggregating links
because, by definition, it does not allow connections to
be established using a transport protocol other than TCP
on multiple paths, such as, for example, the UDP (User
25 Datagram Protocol) transport protocol or other transport
protocols.
[0008] However, several transport protocols have been
proposed, which are standardized and implemented by the
Internet community in order to meet the requirements of
30 the applications. For example, some applications require
more transport functions than those offered by the TCP
and UDP protocols, whereas others consider that the
transport functions offered by TCP or UDP are not (all)
necessary given their requirements. The transport
35 functions are defined as being the list of services
offered by a protocol used to multiplex connections on
the transport layer. This list contains, for example, the
ordered transmission of the data, the reliable
WO 2022/069825 PCT/FR2021/051663
4
transmission of the data, congestion control, or
integrity checking.
[0009] It is for this reason that:
 the SCTP (Stream Control Transmission Protocol)
5 protocol has been specified to meet the requirements
of the applications that require more transport
functions than those supported by TCP such as,
typically, preserving the structure of the data as
generated by the application or supporting
10 communications via multiple paths;
 the DCCP (Datagram Congestion Control Protocol)
protocol is another transport protocol that has been
specified for applications that require more
transport functions than those supported by UDP
15 (such as, for example, supporting congestion
control), but without necessarily inheriting the
constraints of a connection-oriented protocol such
as TCP (such as, for example, ensuring reliable
transmission);
20  the UDP-lite protocol is a simple version of the UDP
protocol that has been proposed for applications
that do not require all the functions offered by UDP
(such as, for example, integrity checking), whereas
the TLS (Transport Layer Security) and DTLS
25 (Datagram TLS) protocols have been standardized for
the encryption requirements of the applications on
the transport layer;
 the QUIC protocol is a protocol that is based on the
UDP transport protocol and that is intended to
30 reduce the latency times generally observed when
establishing TCP connections, while avoiding the
problems of blocking (or Head-of-line blocking);
 etc.
[0010] Given that TCP and UDP are the two transport
35 protocols mainly used by the applications for
communicating over the Internet, link aggregation should
form part of the functions supported by UDP, echoing what
is supported by TCP. Thus, the 3GPP standard has edited,
WO 2022/069825 PCT/FR2021/051663
5
for 5G networks, the TR 23.793 report entitled “3GPP;
Technical Specification Group Services and System
Aspects; Study on access traffic steering, switch and
splitting support in the 5G system architecture”, Release
5 16, v16.0.0, December 2018, the purpose of which was to
study how a 5G network (or 5G System (5GS)) can be
modified to support the link aggregation functions,
called ATSSS (Access Traffic Steering, Switching and
Splitting) in the 3GPP report, between 3GPP access
10 networks and other non-3GPP access networks. All the
ATSSS functions deployed in a 5G core network (or more
simply in the “5G network” suite) must be able to be used
to route the TCP traffic and the UDP traffic (including
the QUIC traffic).
15 [0011] One solution specific to the TCP protocol was thus
introduced into 3GPP document TS 23.501 entitled “3GPP;
Technical Specification Group Services and System
Aspects; System architecture for the 5G System (5GS);
Stage 2”, Release 16, v16.5.1, August 2020. This solution
20 is based on the MPTCP and Convert Protocol (described in
document RFC 8803 edited by the IETF) protocols. The 3GPP
study of the solutions for offering the ATSSS functions
to non-TCP traffic, such as, for example, traffic
conveyed by the QUIC protocol, which in 2020 represents
25 a significant share of the traffic, are based on the UDP
protocol.
[0012] In a known manner, QUIC not only encrypts the
payload data but also the control information of a
connection; the QUIC information that is sent unencrypted
30 is limited to the absolute minimum, and includes, for
example, the connection identifier. As a result, the
known solutions that are based on the MPTCP protocol and
on the assistance of the network are not reusable for the
QUIC protocol, since the QUIC traffic cannot be
35 intercepted by the network due to its encryption.
Moreover, the QUIC protocol uses only a single path at a
time to send the data packets relating to the same
connection, which does not meet the requirements of the
WO 2022/069825 PCT/FR2021/051663
6
ATSSS functions defined by the 3GPP standard.
[0013] The options that are currently being studied by
the 3GPP to offer ATSSS functions in conjunction with the
QUIC protocol are briefly disclosed in the document by
5 M. Boucadair et al., entitled “3GPP Access Traffic
Steering Switching and Splitting (ATSSS) - Overview for
IETF Participants”, 30 May 2020 (hereafter referred to
as document D1). In this document D1, a reference
architecture is considered, according to which a user
10 equipment is attached to two different access networks
(including at least one 3GPP network of an operator of a
5G core network, with the other network being able to be
managed by a separate administrative entity), and
interacts with a remote server. This interaction occurs
15 via an ATSSS UPF (User Plane Function) function, located
in the 5G network of the operator and responsible for
associating the data received from the user equipment via
the various access networks (in other words, via various
paths) and for relaying them to the remote server.
20 [0014] Document D1 describes three options using the QUIC
protocol as an encapsulation mechanism between the user
equipment and the ATSSS UPF function located in the
network of the operator, for any type of traffic (TCP,
UDP, IP, QUIC, etc.). According to these options, the
25 QUIC connections established between the user equipment
and the ATSSS UPF function are either simple connections
(i.e., each of these connections is established according
to the basic QUIC procedure described in the document by
J. Iyendar et al., entitled “QUIC: A UDP-based
30 Multiplexed and Secure Transport”, draft-ietf-quictransport,
May 2020), or connections established
according to a new extension to the QUIC protocol defined
to support the QUIC connections via multiple paths. When
simple QUIC connections are used, an application function
35 associating the various connections with one another is
then necessary.
[0015] The three options that are currently discussed by
the 3GPP nevertheless suffer from the following
WO 2022/069825 PCT/FR2021/051663
7
disadvantages.
[0016] The use of the QUIC protocol as an encapsulation
mechanism between the user equipment and the ATSSS UPF
function induces a surplus (also called “overhead”)
5 relative to the various encapsulation mechanisms already
present in the 3GPP networks. Figure 1 illustrates the
required protocol stacks (and the resulting encapsulation
schemes) on each entity of the aforementioned reference
architecture (user equipment UE, N3IWF (Non-3GPP
10 InterWorking Function) and UPF entities of the 5G network
of the operator, gNB base station and remote server) for
implementing the ATSSS UPF function, as a function of the
access network used by the user equipment UE to connect
to the 5G (3GPP access network (or “5G-AN” for 5G Access
15 Network) or non-3GPP access network, such as a WLAN
network, for example).

Claims
[Claim 1] A method for configuring a user equipment
(UE1), which method is intended to be implemented by said
5 user equipment and comprises a step (E80, F120, G20) of
deactivating, for at least one encrypted communication
of said user equipment with a remote device (S1) via a
network (CN), at least one encryption procedure selected
by said user equipment and implemented with a first
10 entity (FF) of the network involved in routing data
exchanged between the user equipment and the remote
device during said encrypted communication, with said
data being subject to at least one other encryption
procedure distinct from said at least one deactivated
15 encryption procedure.
[Claim 2] The configuration method as claimed in claim
1, wherein the deactivation step further comprises
deactivating a procedure for establishing a tunnel with
20 said first entity.
[Claim 3] The configuration method as claimed in claim 1
or 2, wherein said at least one other encryption
procedure is:
25 - an encryption procedure implemented with another
entity of the network involved in routing said data;
and/or
- an encryption procedure implemented on a network
used by said user equipment to exchange said data
30 with said remote device; and/or
- an encryption procedure implemented with said remote
device for exchanging said data.
[Claim 4] The configuration method as claimed in any one
35 of claims 1 to 3, wherein the deactivation step is
conditional upon the reception (E50, F40, F70, F100) of
a prior authorization originating from a second entity
(CF, FF) of the network and requested by the user
WO 2022/069825 PCT/FR2021/051663
63
equipment.
[Claim 5] The configuration method as claimed in claim
4, further comprising, prior to said deactivation step,
5 a step of receiving, originating from said second entity
of the network, at least one item of information
(Optimized-INFO), called deactivation context
information, providing at least one indication concerning
at least one encryption procedure and/or at least one
10 tunnel establishment procedure that can be deactivated
by said user equipment.
[Claim 6] The configuration method as claimed in claim
5, wherein said at least one item of deactivation context
15 information comprises at least one indication of:
- at least one entity of the network with which an
encryption procedure and/or a tunnel establishment
procedure can be deactivated; and/or
- at least one type of connection during which one of
20 said procedures can be deactivated; and/or
- at least one network for accessing said network for
which one of said procedures can be deactivated.
[Claim 7] The configuration method as claimed in claim 5
25 or 6, wherein said at least one item of deactivation
context information further comprises a security key
intended to be presented by said user equipment to said
first entity of the network with which the encryption
procedure and/or the tunnel establishment procedure is
30 deactivated.
[Claim 8] The configuration method as claimed in any one
of claims 5 to 7, wherein said at least one encryption
procedure and/or the tunnel establishment procedure
35 selected by said user equipment is(are) selected as a
function of said at least one item of deactivation
context information received from the second entity.
WO 2022/069825 PCT/FR2021/051663
64
[Claim 9] The configuration method as claimed in any one
of claims 1 to 3, comprising, following the deactivation
step:
- a step (G30) of requesting the establishment of a
5 first connection with or via the first entity, in
which step the encryption procedure and/or the
tunnel establishment procedure is(are) deactivated;
- in the event of the rejection of said first
connection by the first entity, a step (G70) of
10 requesting the establishment of a second connection
with or via the first entity, in which step said
encryption procedure and/or the tunnel
establishment procedure is(are) activated between
the user equipment and the first entity.
15
[Claim 10] A method for negotiating between an entity
(CF, FF), called second entity, of a network (CN) and a
user equipment (UE1) of said network, said method
comprising:
20 - a step of receiving, by the second entity, an
authorization request by the user equipment for
deactivating, for at least one encrypted
communication of the user equipment with a remote
device via said network, at least one encryption
25 procedure implemented with at least one entity,
called first entity, of the network involved in
routing data exchanged between said user equipment
and said remote device during said encrypted
communication;
30 - if the request is accepted, a step of sending, by
said second entity, at least one item of
information, called deactivation context
information, intended for said user equipment, with
said at least one item of information providing at
35 least one indication concerning at least one of said
encryption procedures that can be deactivated by
said user equipment.
WO 2022/069825 PCT/FR2021/051663
65
[Claim 11] The negotiation method as claimed in claim 10,
further comprising a step (E30) of configuring, by the
second entity (CF), said first entity (FF) in order to
process data exchanged between said user equipment and
5 said remote device during said encrypted communication
when an encryption procedure with said first entity is
deactivated by said user equipment.
[Claim 12] A method for managing a connection of a user
10 equipment (UE1) of a network (CN) by a first entity (FF)
of the network involved in routing data exchanged between
said user equipment and a remote device (S1) during an
encrypted communication, said management method
comprising:
15 - a step (H10) of receiving, from the user equipment,
a request to establish a first connection with or
via the first entity, in which step at least one
encryption procedure between the first entity and
said user equipment, selected by said user
20 equipment, is deactivated;
- if the first entity accepts the establishment of the
first connection (H30), a step (H40) of processing
data exchanged, during said encrypted
communication, between said user equipment and said
25 remote device via said first connection;
- otherwise (H50), a step (H60) of processing data
exchanged, during said encrypted communication,
between said user equipment and said remote device
via a second connection established by the user
30 equipment with or via the first entity, in which
step said encryption procedure is activated between
the user equipment and the first entity.
[Claim 13] The method as claimed in any one of claims 1
35 to 12, wherein said second entity is said first entity
(FF), or a network control entity (CF) capable of
configuring said first entity to deactivate said
encryption procedure or another network control entity
WO 2022/069825 PCT/FR2021/051663
66
capable of relaying the authorization request from the
user equipment to this control entity.
[Claim 14] The method as claimed in any one of claims 1
5 to 13, wherein the QUIC protocol is implemented during
said encrypted communication.
[Claim 15] A user equipment (UE1) of a telecommunications
network (CN) comprising a deactivation module (7C),
10 configured to deactivate, for at least one encrypted
communication of said user equipment with a remote device
via the network, at least one encryption procedure
selected by said user equipment and implemented with a
first entity of the network involved in routing data
15 exchanged between the user equipment and the remote
device during said encrypted communication, with said
data being subject to at least one other encryption
procedure distinct from said at least one deactivated
encryption procedure.
20
[Claim 16] The user equipment as claimed in claim 15,
wherein the deactivation module is configured to
deactivate said at least one encryption procedure
following a prior authorization, received from a second
25 entity of the network, requested by the user equipment.
[Claim 17] The user equipment as claimed in claim 15,
further comprising a communication module (7A) configured
for:
30 - requesting the establishment of a first connection
with or via the first entity in which said
encryption procedure is deactivated;
- in the event of the rejection of the first
connection by the first entity, requesting the
35 establishment of a second connection with or via the
first entity in which said encryption procedure is
activated between the user equipment and the first
entity.
WO 2022/069825 PCT/FR2021/051663
67
[Claim 18] An entity (CF, FF), called second entity, of
a network comprising:
- a reception module (14A, 13E), configured to process
5 a request by a user equipment of said network to
authorize the deactivation, for at least one
encrypted communication of the user equipment with
a remote device via said network, of at least one
encryption procedure implemented with at least one
10 entity, called first entity, of the network involved
in routing data exchanged between said user
equipment and said remote device during said
encrypted communication;
- a sending module (14A, 13E), which is activated if
15 the request is accepted and is configured to send
at least one item of information, called
deactivation context information, intended for said
user equipment, with said at least one item of
information providing at least one indication
20 concerning at least one of said encryption
procedures that can be deactivated by said user
equipment.
[Claim 19] An entity (FF), called first entity, of a
25 network likely to be involved in routing data exchanged
between a user equipment of the network and a remote
device during an encrypted communication, said first
entity comprising:
- a deactivation module (13B) configured to
30 deactivate, during said encrypted communication, an
encryption procedure with the user equipment,
selected by said user equipment; and
- a processing module (13C) configured to process the
data exchanged during said encrypted communication
35 between the user equipment and the remote device,
passing through the first entity.
[Claim 20] The first entity of a network as claimed in
WO 2022/069825 PCT/FR2021/051663
68
claim 19, comprising:
- a first processing module (13A), configured to
process an establishment request, received from the
user equipment, to establish a first connection with
5 or via the first entity in which at least one
encryption procedure between the first entity and
said user equipment, selected by said user
equipment, is deactivated during said encrypted
communication;
10 - a second processing module (13C), which is activated
if the establishment request is accepted and is
configured to process the data exchanged, during the
encrypted communication, between the user equipment
and the remote device via said first connection; and
15 - a third processing module (13C), which is activated
if the establishment request is rejected and is
configured to process data exchanged, during said
encrypted communication, between the user equipment
and the remote device via a second connection
20 established by the user equipment in which said
encryption procedure is implemented between the user
equipment and the first entity.
[Claim 21] A telecommunications system (1) comprising:
25 - at least one user equipment (UE1) of a network (CN)
as claimed in any one of claims 15 to 17; and
- at least one entity (CF, FF) of the network as
claimed in claim 18 and/or an entity (FF) of the
network as claimed in claim 19 or 20.