(19)
(11)EP 3 920 509 B1

(12)EUROPEAN PATENT SPECIFICATION

(45)Mention of the grant of the patent:
03.08.2022 Bulletin 2022/31

(21)Application number: 20178017.8

(22)Date of filing:  03.06.2020
(51)International Patent Classification (IPC): 
H04W 76/10(2018.01)
H04L 69/18(2022.01)
H04W 48/18(2009.01)
H04W 4/80(2018.01)
H04W 4/33(2018.01)
H04W 88/06(2009.01)
(52)Cooperative Patent Classification (CPC):
H04W 4/33; H04W 4/80; H04W 76/10; H04W 88/06; H04W 48/18; H04L 69/18

(54)

ACCESS TO A HOME NETWORK WITHIN A MULTI-CONNECTIVITY FRAMEWORK

ZUGANG ZU EINEM HEIMNETZWERK INNERHALB EINES MULTI-KONNEKTIVITÄTSRAHMENS

ACCÈS À UN RÉSEAU DOMESTIQUE À L'INTÉRIEUR D'UN CADRE MULTI-CONNECTIVITÉ


(84)Designated Contracting States:
AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

(43)Date of publication of application:
08.12.2021 Bulletin 2021/49

(73)Proprietor: Deutsche Telekom AG
53113 Bonn (DE)

(72)Inventors:
  • AMEND, Markus
    63667 Nidda (DE)
  • BOGENFELD, Eckard
    67316 Carlsberg (DE)
  • HENZE, Thomas
    53173 Bonn (DE)
  • HELLEBRAND, Katja
    61118 Bad Vilbel (DE)

(74)Representative: Vossius & Partner Patentanwälte Rechtsanwälte mbB 
Siebertstrasse 3
81675 München
81675 München (DE)


(56)References cited: : 
WO-A1-03/017582
FR-A1- 3 072 529
WO-A1-2015/042189
  
      
    Note: Within nine months from the publication of the mention of the grant of the European patent, any person may give notice to the European Patent Office of opposition to the European patent granted. Notice of opposition shall be filed in a written reasoned statement. It shall not be deemed to have been filed until the opposition fee has been paid. (Art. 99(1) European Patent Convention).


    Description

    Field of the invention



    [0001] The invention relates to a system configured to provide multi-connectivity between a User Equipment, UE, and a multi-connectivity provider backend and to provide access to a home network within a multi-connectivity framework and a method thereon.

    Background



    [0002] Typically, Internet network operators provide one or several Internet accesses to customers such as, for example, fixed (e.g. xDSL), Wi-Fi (e.g. public Hotspots) and/or cellular (e.g. 2G-5G) access.

    [0003] Even if these customers own user equipment(s) (UEs), such as smartphones or residential gateways (RG), which are potentially capable of connecting to multiple accesses simultaneously, they do not make use of the capability to connect to multiple accesses simultaneously due to the lack of multi-connectivity technologies.

    [0004] In the case of smartphones, the common simultaneous connectivity to Wi-Fi and cellular network does not automatically mean that the smartphones can enjoy the benefit of being simultaneously connected to more than one network. In some cases, applications of these smartphones are stuck to one access and are unable to benefit from a second available access in terms of reliability and speed.

    [0005] Network protocols which could leverage the potential of multiple accesses like Multipath Transmission Protocol (MPTCP), Multipath Quick UDP Internet Connection (MP-QUIC), Multipath Datagram Congestion Control Protocol (MPDCCP) and Stream Control Transmission Protocol (SCTP) are not widely adopted and require usually an end-to-end implementation. A broad and fast availability is therefore unrealistic.

    Technical problem



    [0006] Standardized multi-connectivity architectures such as Access Traffic Steering Switching Splitting (ATSSS) part of 3GPP Rel. 16 standardization TS 23.501 version 16.4.0 or Hybrid Access Broadband Network Architecture such as Broadband Forum (BBF) specification TR-348, July 2016 or Nicolai Leymann and Cornelius Heidemann and Margaret Wasserman and Li Xue and Mingui Zhang, "Hybrid Access Network Architecture", draft-lhwxz-hybrid-access-network-architecture-02, January 2015, promise to provide a remedy and use such protocols between UE/RG and access operator network. Furthermore, these architectures give the operator of such architectures a comprehensive traffic management capability.

    [0007] FIG. 1 illustrates an exemplary ATSSS architecture as defined by the 3GPP TS 23.501. In FIG. 1, the ATSSS manages simultaneous connectivity for UEs over cellular (3GPP access) and non-cellular access (untrusted non-3GPP access e.g. Wi-Fi). As shown in FIG. 1, the UE connects to a Data Network (DN) over cellular (3GPP Access) and Wi-Fi (Untrusted Non-3GPP access) using the N3 interface towards the ATSSS-UPF (User Plane Function) part of a 5G Core.

    [0008] In FIG. 1, the untrusted non-3GPP access path is interconnected with the 5G Core through the Non-3GPP Interworking (N3IWF) entity/function, which is responsible to attach the non-3GPP access to the 5G core. The UPF can be understood as the interface between UE and Data Network (e.g. Internet) taking responsibility for traffic management. Other entities/functions forming part of the 5G Core as shown in FIG. 1 are: Authentication Server Function (AUSF), Unified Data Management (UDM), Access and Mobility Management Function (AMF), Session Management Function (SMF), Policy Control Function (PCF) and Application Function (AF) including the control plane and user plane. Further, FIG. 1 also shows the name of the interfaces that are exposed by each of these entities.

    [0009] The BBF and the Internet Engineering Task Force (IETF) specifies the residential use case, known as Hybrid Access. Currently BBF re-defines Hybrid Access to work with ATSSS also. Hybrid Access combines therefore fixed access (xDSL or fiber) and cellular access within a Residential Gateway (RG).

    [0010] However, those architectures require integration into the access provider network that provides at least one of the accesses of the simultaneous used accesses. In case of ATSSS, the integration happens in the cellular provider network, whereas for the Hybrid access, it might be either the cellular or the fixed access network provider.

    [0011] Usually an operator of at least one of the multi-connectivity architectures (e.g. in ATSSS or Hybrid Access) owns one or all accesses for multi-connectivity purposes.

    [0012] The document WO 2015/042189 A1 describes connectivity augmented services architecture, discovery and connection.

    [0013] Currently, there are no existing approaches that allow multi-connectivity network architectures to provide access to a home network without being physically attached to it.

    [0014] In view of the above, it is an object the present invention to provide an access to a home network within a multi-connectivity framework.

    Summary of the invention



    [0015] The above objects are achieved by the features of the independent claims.

    [0016] According to a first aspect, the invention provides a system comprising a User Equipment, UE, at least two Internet access providers (IAP-1, IAP-2), a multi-connectivity provider backend, a Home Network, HN, and a Data Network, DN, wherein the UE comprises at least two access interfaces, wherein the system is configured to provide multi-connectivity between the UE and the HN, wherein the multi-connectivity provider backend is configured to establish a connection to the HN, and to provide access from the UE to the HN.

    [0017] According to a preferred aspect, the establishment of the connection to the HN is done through a tunnel connection from the multi-connectivity provider backend through the DN.

    [0018] According to a preferred aspect, the establishment of the connection to the HN is done through routing from the multi-connectivity provider backend through the DN.

    [0019] According to a preferred aspect, the DN is the Internet.

    [0020] According to a preferred aspect, the multi-connectivity provider backend and the HN belong to a same operator and the multi-connectivity provider backend provides access to the HN without going through the DN.

    [0021] According to a preferred aspect, the multi-connectivity provider backend is further configured to: determine whether the UE is already connected to the HN through one of its access interfaces, and if it is determined that one access interface is already connected to the HN: stop the connection from the multi-connectivity provider backend to the HN; or route the HN related traffic to the UE through the already connected access interface.

    [0022] According to a preferred aspect, the determination of whether at least one of the UE's access interface is already connected to the HN, is based on: geo-location, Service Set Identifier, SSID, or signaling between UE and multi-connectivity provided backend.

    [0023] According to a preferred aspect, the tunnel connection is encrypted.

    [0024] According to a preferred aspect, the multi-connectivity provider backend is further configured to check whether the at least two access interfaces have conflicting IP addresses or overlapping IP addresses with the HN, and if the at least two access interfaces have conflicting IP addresses or overlapping IP addresses with the HN, the multi-connectivity provider backend is configured to apply counter-measures, or the multi-connectivity provider is configured to send a message to the UE, the message comprising an indication to the UE to apply counter-measures.

    [0025] According to a preferred aspect, the multi-connectivity provider backend is configured to establish the connection with the HN through a Residential Gateway, RG.

    [0026] According to a second aspect, the invention provides a method for providing multi-connectivity between a User Equipment, UE, and a Home Network, HN, in a system, the system comprising the UE, at least two Internet access providers (IAP-1, IAP-2), a multi-connectivity provider backend, the Home Network, HN, and a Data Network, DN, wherein the UE comprises at least two access interfaces, the method comprising: establishing, by the multi-connectivity provider backend, a connection to the HN; and providing, by the multi-connectivity provider backend, access from the UE to the HN.

    [0027] According to a preferred aspect, wherein the establishing of the connection to the HN is done through a tunnel connection from the multi-connectivity provider backend through the DN.

    [0028] According to a preferred aspect, the establishing of the connection to the HN is done through routing from the multi-connectivity provider backend through the DN.

    [0029] According to a preferred aspect, the DN is the Internet.

    [0030] According to a preferred aspect, the multi-connectivity provider backend and the HN belong to a same operator and the multi-connectivity provider backend provides access to the HN without going through the DN.

    [0031] According to a preferred aspect, the method further comprises: determining, by the multi-connectivity provider backend, whether the UE is already connected to the HN through one access interface, and if it is determined that one access interface is already connected to the HN: stopping the connection from the multi-connectivity provider backend to the HN, or routing the HN related traffic to the UE through the already connected access interface.

    [0032] According to a preferred aspect, the determination of whether at least one of the UE's access interface is already connected to the HN, is based on: geo-location, Service Set Identifier, SSID, or signaling between UE and multi-connectivity provided backend.

    [0033] According to a preferred aspect, the tunnel connection is encrypted.

    [0034] According to a preferred aspect, the method further comprises establishing, by the multi-connectivity provider backend, the connection with the HN through a Residential Gateway, RG.

    [0035] According to a preferred aspect, the method further comprises: checking, at the multi-connectivity provider backend, whether the at least two access interfaces have conflicting IP addresses or overlapping IP addresses with the HN, and if the at least two access interfaces have conflicting IP addresses or overlapping IP addresses with the HN, applying counter-measures at the multi-connectivity provider backend, or sending a message to the UE, the message comprising an indication to the UE to apply counter-measures.

    [0036] The invention has the following advantageous technical effects: enabling the possibility to keep a constant connection to a home network under consideration of multi-connectivity specific features. This allows customer to interact with home devices whenever at least one access is given even if this is not the direct physical access to the home network itself.

    [0037] Other aspects, features, and advantages will be apparent from the summary above, as well as from the description that follows, including the figures and the claims.

    Brief description of drawings



    [0038] In the drawings:
    FIG. 1
    illustrates an exemplary ATSSS architecture as defined by the 3GPP TS 23.501.
    FIG. 2
    illustrates a basic architecture for an OTT multi-connectivity provider according to an embodiment of the present invention.
    FIG. 3
    illustrates a Home Network access provided by a multi-connectivity provider according to an embodiment of the present invention.

    Detailed description of the invention



    [0039] According to an embodiment of the invention, there is provided a system comprising an access to a home network within a multi-connectivity framework without being physically attached to it. The following description and figures assume a User Equipment (UE) such as, for example, a smartphone, or Residential Gateway (RG), equipped with Wi-Fi and cellular access interfaces or fixed such as DSL and cellular access interfaces. However, this can be transferred to any other multi-connectivity scenario with more or other accesses.

    [0040] FIG. 2 illustrates an exemplary architecture for an OTT multi-connectivity provider according to an embodiment of the invention. The principle of this architecture requires a multi-connectivity UE or RG able to connect to more than one access network and a multi-connectivity provider acting over the top of the access provider networks. The multi-connectivity provider may be connected to a Data Network (DN), e.g. the Internet.

    [0041] The UE is configured to connect to the multi-connectivity provider across the access networks. The UE may do so with the help of tunnel accesses for each respective multipath, e.g. VPN connections or via routing principles. In FIG. 2, there is illustrated a first tunnel access (TA-1), that connects the UE to the multi-connectivity provider via a first internet access provider (IAP-1), and a N tunnel access (TA-N), that connects the UE to the multi-connectivity provider via a N internet access provider (IAP-N). The number N of tunnel accesses and internet access providers is a positive integer equal to or larger than two. However, under operation, this number may fall below two, e.g. if an access is broken, and may need to be restored.

    [0042] The multi-connectivity provider requires, at least, the functions of authentication and multi-connectivity traffic management. These functions are located in the multi-connectivity provider's backend, e.g. located in the operator network or in a public data center.

    [0043] The multi-connectivity provider may authenticate the tunnel to ensure that only eligible UEs can establish the tunnel and exchange in the following user plane traffic.

    [0044] The process of tunnel establishment, authentication and securing may follow any state of the art technologies like Extensible Authentication Protocol (EAP) methods. EAP is an authentication framework for providing common functions and negotiation of authentication methods called EAP methods.

    [0045] Once the tunnel has been authenticated, the traffic management function of the multi-connectivity provider re-directs the user plane traffic between the UE and the Data Network (DN). The redirection of traffic is performed by encapsulating the traffic into the tunnel instead of sending the traffic without encapsulation on the access interfaces.

    [0046] As a preferred alternative, the encapsulated user plane traffic may be encrypted.

    [0047] As a preferred alternative, the establishment and authentication of a tunnel and/or the encryption of the encapsulated user plane traffic is performed with an Extensible Authentication Protocol, EAP, method or a Transport Layer Security, TLS, method.

    [0048] Optionally, the multi-connectivity provider may further comprise the functions of Authorization and Accounting, Policy management or (meta-) data collection. However, these optional functions can be separated by e.g. Network Function Virtualization (NFV) or operated in one entity. This entity or these entities can run on bare metal servers or executed in virtual environments like Virtual Machines (VM) or in user space isolated environments typically called "Container".

    [0049] FIG. 3 illustrates a Home Network access provided by a multi-connectivity provider according to an embodiment of the present invention.

    [0050] On behalf of the UE, the multi-connectivity provider backend is configured to establish a connection to a home network.

    [0051] The multi-connectivity provider backend terminates the multi-connectivity connection, whereas the access operator backend provides connectivity to the RG. If both backends are located in the same environment, a trusted connection is possible without a "(secure) tunnel".

    [0052] Depending on where the multi-connectivity provider is located, this done through a (secure) tunnel connection from the multi-connectivity provider through the Internet to the residential Gateway (RG) of the home network (OTT approach). Otherwise it might profit from a deep integration level. A deep integration level occurs, for example, when the multi-connectivity provider backend and the RG access operator backend where the RG connects to are the same, and make use of other technologies to connect the RG and the UE, e.g. via routing.

    [0053] In both cases, the UE has direct IP connectivity (OSI Layer 3) to the home network or even MAC connectivity (OSI Layer 2).

    [0054] In order to avoid addressing, routing, and delay conflicts when one UE access interface of the multi-connectivity connection is already connected to the home network, there is required a kind of breakout mechanism. Such mechanism may be, for example, destructing, at the multi-connectivity provider, the connection from the backend to the home network or route the home network related traffic in the UE directly through the Wi-Fi interface.

    [0055] Mechanisms to detect an already established physical connection to the home network might be the geo-location (e.g. a predefined home network location based on geo-coordinates), Service Set Identifier (SSID) or signaling between UE and backend while comparing, for example, public IP addresses.

    [0056] The multi-connectivity provider backend may be further configured to check whether the at least two access interfaces have conflicting IP addresses or overlapping IP addresses with the Home Network (HN). If the at least two access interfaces have conflicting IP addresses or overlapping IP addresses with the HN, the UE or the multi-connectivity provider backend may apply counter-measures to solve the conflict.

    [0057] For example, some examples of such counter measures are: in order to avoid IPv4 address conflicts when the Wi-Fi network and the home network have overlapping IP subnets, a possible countermeasure according to a preferred alternative is to use IPv6 addressing only for reaching the home network or inform the user of the UE about this situation and let the user select the preferred network: home network or local Wi-Fi network.

    [0058] In case the UE is equipped with a Wi-Fi autologin feature it also possible that a user of the UE at home connects to a neighbor Wi-Fi due to better signal conditions. Therefore, a geo-location restriction may be applied only in a limited home area and not globally to avoid this scenario and keep the UE user connected to its home network.

    [0059] While the invention has been illustrated and described in detail in the drawings and foregoing description, such illustration and description are to be considered illustrative or exemplary and not restrictive. It will be understood that changes and modifications may be made by those of ordinary skill within the scope of the following claims. In particular, the present invention covers further embodiments with any combination of features from different embodiments described above and below.

    [0060] Furthermore, in the claims the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. A single unit may fulfil the functions of several features recited in the claims. The terms "essentially", "about", "approximately" and the like in connection with an attribute or a value particularly also define exactly the attribute or exactly the value, respectively. Any reference signs in the claims should not be construed as limiting the scope.


    Claims

    1. A system comprising a User Equipment, UE, at least two Internet access providers (IAP-1, IAP-2), a multi-connectivity provider backend, a Home Network, HN, and a Data Network, DN, wherein the UE comprises at least two access interfaces, wherein the system is configured to provide multi-connectivity between the UE and the HN, wherein the multi-connectivity provider backend is configured to establish a connection to the HN, and to provide access from the UE to the HN.
     
    2. The system of claim 1,

    wherein the establishment of the connection to the HN is done through a tunnel connection from the multi-connectivity provider backend through the DN, or

    wherein the establishment of the connection to the HN is done through routing from the multi-connectivity provider backend through the DN.


     
    3. The system of claim 1 or 2, wherein the DN is the Internet.
     
    4. The system of any one of claims 1 to 3, wherein the multi-connectivity provider backend and the HN belong to a same operator and the multi-connectivity provider backend provides access to the HN without going through the DN.
     
    5. The system of any one of claims 1 to 4, wherein the multi-connectivity provider backend is further configured to:

    determine whether the UE is already connected to the HN through one of its access interfaces, and

    if it is determined that one access interface is already connected to the HN:

    stop the connection from the multi-connectivity provider backend to the HN; or

    route the HN related traffic to the UE through the already connected access interface.


     
    6. The system of claim 5, wherein the determination of whether at least one of the UE's access interface is already connected to the HN, is based on: geo-location, Service Set Identifier, SSID, or signaling between UE and multi-connectivity provided backend.
     
    7. The system of any one of claims 2 to 6, wherein the tunnel connection is encrypted.
     
    8. The system of any one of claims 1 to 7, wherein the multi-connectivity provider backend is further configured to check whether the at least two access interfaces have conflicting IP addresses or overlapping IP addresses with the HN, and
    if the at least two access interfaces have conflicting IP addresses or overlapping IP addresses with the HN,

    the multi-connectivity provider backend is configured to apply counter-measures, or

    the multi-connectivity provider is configured to send a message to the UE, the message comprising an indication to the UE to apply counter-measures.


     
    9. The system of any one of claims 1 to 8, wherein the multi-connectivity provider backend is configured to establish the connection with the HN through a Residential Gateway, RG.
     
    10. A method for providing multi-connectivity between a User Equipment, UE, and a Home Network, HN, in a system, the system comprising the UE, at least two Internet access providers (IAP-1, IAP-2), a multi-connectivity provider backend, the Home Network, HN, and a Data Network, DN, wherein the UE comprises at least two access interfaces, the method comprising:

    establishing, by the multi-connectivity provider backend, a connection to the HN; and

    providing, by the multi-connectivity provider backend, access from the UE to the HN.


     
    11. The method of claim 10,

    wherein the establishing of the connection to the HN is done through a tunnel connection from the multi-connectivity provider backend through the DN, or

    wherein the establishing of the connection to the HN is done through routing from the multi-connectivity provider backend through the DN.


     
    12. The method of claims 10 or 11,

    wherein the DN is the Internet, or

    wherein the multi-connectivity provider backend and the HN belong to a same operator and the multi-connectivity provider backend provides access to the HN without going through the DN.


     
    13. The method of any one of claims 10 to 12, the method further comprising:

    determining, by the multi-connectivity provider backend, whether the UE is already connected to the HN through one access interface, and

    if it is determined that one access interface is already connected to the HN:

    stopping the connection from the multi-connectivity provider backend to the HN, or

    routing the HN related traffic to the UE through the already connected access interface;

    wherein the determination of whether at least one of the UE's access interface is already connected to the HN is based on: geo-location, Service Set Identifier, SSID, or signaling between UE and multi-connectivity provided backend.


     
    14. The method of any one of claims 10 to 13,

    wherein the tunnel connection is encrypted, and/or

    establishing, by the multi-connectivity provider backend, the connection with the HN through a Residential Gateway, RG.


     
    15. The method of any one of claims 10 to 14, the method further comprising:

    checking, at the multi-connectivity provider backend, whether the at least two access interfaces have conflicting IP addresses or overlapping IP addresses with the HN, and

    if the at least two access interfaces have conflicting IP addresses or overlapping IP addresses with the HN,

    applying counter-measures at the multi-connectivity provider backend, or

    sending a message to the UE, the message comprising an indication to the UE to apply counter-measures.


     


    Ansprüche

    1. System, das ein Benutzergerät, UE, mindestens zwei Internetzugangsanbieter (IAP-1, IAP-2), ein Multikonnektivitäts-Anbieter-Backend, ein Heimnetzwerk, HN, und ein Datennetzwerk, DN, aufweist, wobei das UE mindestens zwei Zugangsschnittstellen aufweist, wobei das System konfiguriert ist, eine Multikonnektivität zwischen dem UE und dem HN bereitzustellen, wobei das Multikonnektivitäts-Anbieter-Backend konfiguriert ist, eine Verbindung zum HN aufzubauen und einen Zugang vom UE zum HN bereitzustellen.
     
    2. System nach Anspruch 1,

    wobei der Aufbau der Verbindung zum HN durch eine Tunnelverbindung vom Multikonnektivitäts-Anbieter-Backend durch das DN erfolgt, oder

    wobei der Aufbau der Verbindung zum HN durch Routing vom Multikonnektivitäts-Anbieter-Backend durch das DN erfolgt.


     
    3. System nach Anspruch 1 oder 2, wobei das DN das Internet ist.
     
    4. System nach einem der Ansprüche 1 bis 3, wobei das Multikonnektivitäts-Anbieter-Backend und das HN zum selben Betreiber gehören und das Multikonnektivitäts-Anbieter-Backend den Zugang zum HN bereitstellt, ohne durch das DN zu gehen.
     
    5. System nach einem der Ansprüche 1 bis 4, wobei das Multikonnektivitäts-Anbieter-Backend ferner konfiguriert ist:

    festzustellen, ob das UE bereits über eine seiner Zugangsschnittstellen mit dem HN verbunden ist, und

    wenn festgestellt wird, dass eine Zugangsschnittstelle bereits mit dem HN verbunden ist:
    die Verbindung vom Multikonnektivitäts-Anbieter-Backend zum HN zu stoppen;

    oder den HN-bezogenen Verkehr über die bereits verbundene Zugangsschnittstelle an das UE zu leiten.


     
    6. System nach Anspruch 5, wobei die Feststellung, ob mindestens eine der Zugangsschnittstellen des UE bereits mit dem HN verbunden ist, basiert auf: einem Geo-Standort, einem Service Set Identifier, SSID, oder einer Signalisierung zwischen dem UE und dem Multikonnektivitäts-Anbieter-Backend.
     
    7. System nach einem der Ansprüche 2 bis 6, wobei die Tunnelverbindung verschlüsselt ist.
     
    8. System nach einem der Ansprüche 1 bis 7, wobei das Multikonnektivitäts-Anbieter-Backend ferner konfiguriert ist, zu prüfen, ob die mindestens zwei Zugangsschnittstellen kollidierende IP-Adressen oder überlappende IP-Adressen mit dem HN aufweisen, und wenn die mindestens zwei Zugangsschnittstellen kollidierende IP-Adressen oder sich überschneidende IP-Adressen mit dem HN aufweisen,

    das Multikonnektivitäts-Anbieter-Backend konfiguriert ist, Gegenmaßnahmen anzuwenden, oder

    der Multikonnektivitäts-Anbieter konfiguriert ist, eine Nachricht an das UE zu senden, wobei die Nachricht einen Anzeige an das UE enthält, Gegenmaßnahmen anzuwenden.


     
    9. System nach einem der Ansprüche 1 bis 8, wobei das Multikonnektivitäts-Anbieter-Backend konfiguriert ist, die Verbindung mit dem HN durch ein Residential Gateway, RG, aufzubauen.
     
    10. Verfahren zum Bereitstellen einer Mehrfachkonnektivität zwischen einem Benutzergerät, UE, und einem Heimnetzwerk, HN, in einem System, wobei das System das UE, mindestens zwei Internetzugangsanbieter (IAP-1, IAP-2), ein Multikonnektivitäts-Anbieter-Backend, das Heimnetzwerk, HN, und ein Datennetzwerk, DN, aufweist, wobei das UE mindestens zwei Zugangsschnittstellen aufweist, wobei das Verfahren aufweist:

    Aufbauen durch das Multikonnektivitäts-Anbieter-Backend einer Verbindung mit dem HN; und

    Bereitstellen durch das Multikonnektivitäts-Anbieter-Backend eine Zugangs vom UE zum HN


     
    11. Verfahren nach Anspruch 10,

    wobei das Aufbauen der Verbindung zum HN durch eine Tunnelverbindung vom Multikonnektivitäts-Anbieter-Backend durch das DN erfolgt, oder

    wobei das Aufbauen der Verbindung zum HN durch Routing vom Multikonnektivitäts-Anbieter-Backend durch das DN erfolgt.


     
    12. Verfahren nach Anspruch 10 oder 11,

    wobei das DN das Internet ist, oder

    wobei das Multikonnektivitäts-Anbieter-Backend und das HN zum selben Betreiber gehören und das Multikonnektivitäts-Anbieter-Backend den Zugang zum HN bereitstellt, ohne durch das DN zu gehen.


     
    13. Verfahren nach einem der Ansprüche 10 bis 12, wobei das Verfahren ferner aufweist:

    Feststellen durch das Multikonnektivitäts-Anbieter-Backend, ob das UE bereits mit dem HN über eine Zugangsschnittstelle verbunden ist, und

    wenn festgestellt wird, dass eine Zugangsschnittstelle bereits mit dem HN verbunden ist:

    Stoppen der Verbindung vom Multikonnektivitäts-Anbieter-Backend zum HN, oder

    Leiten des HN-bezogenen Verkehrs zum UE über die bereits verbundene Zugangsschnittstelle;

    wobei die Bestimmung, ob mindestens eine der Zugangsschnittstellen des UE bereits mit dem HN verbunden ist, basiert auf: einem Geo-Standort, einem Service Set Identifier, SSID, oder einer Signalisierung zwischen dem UE und dem Multikonnektivitäts-Anbieter-Backend.


     
    14. Verfahren nach einem der Ansprüche 10 bis 13,

    wobei die Tunnelverbindung verschlüsselt ist, und/oder

    Aufbauen der Verbindung mit dem HN durch das Multikonnektivitäts-Anbieter-Backend durch ein Residential Gateway, RG.


     
    15. Verfahren nach einem der Ansprüche 10 bis 14, wobei das Verfahren ferner aufweist:

    Prüfen am Multikonnektivitäts-Anbieter-Backend, ob die mindestens zwei Zugangsschnittstellen kollidierende IP-Adressen oder überlappende IP-Adressen mit dem HN aufweisen, und

    wenn die mindestens zwei Zugangsschnittstellen kollidierende IP-Adressen oder sich überschneidende IP-Adressen mit dem HN aufweisen,

    Anwenden von Gegenmaßnahmen am Multikonnektivitäts-Anbieter-Backend, oder

    Senden einer Nachricht an das UE, wobei die Nachricht einen Anzeige an das UE enthält, Gegenmaßnahmen anzuwenden.


     


    Revendications

    1. Système, comprenant un équipement utilisateur UE, au moins deux fournisseurs d'accès Internet (IAP-1, IAP-2), un système dorsal de fournisseur de multi-connectivité, un réseau domestique HN, et un réseau de données DN, où l'UE comprend au moins deux interfaces d'accès, où le système est prévu pour réaliser une multi-connectivité entre l'UE et le HN, où le système dorsal de fournisseur de multi-connectivité est prévu pour établir une connexion au HN, et pour fournir un accès de l'UE au HN
     
    2. Système selon la revendication 1,

    où l'établissement de la connexion au HN est effectué par connexion tunnel du système dorsal de fournisseur de multi-connectivité via le DN, ou

    où l'établissement de la connexion au HN est effectué par routage du système dorsal de fournisseur de multi-connectivité via le DN.


     
    3. Système selon la revendication 1 ou la revendication 2, où le DN est l'Internet.
     
    4. Système selon l'une des revendications 1 à 3, où le système dorsal de fournisseur de multi-connectivité et le HN appartiennent au même opérateur et le système dorsal de fournisseur de multi-connectivité donne accès au HN sans passer par le DN.
     
    5. Système selon l'une des revendications 1 à 4, où le système dorsal de fournisseur de multi-connectivité est en outre prévu pour :

    déterminer si l'UE est déjà connecté au HN via une de ses interfaces d'accès, et

    s'il est déterminé qu'une interface d'accès est déjà connectée au HN

    arrêter la connexion du système dorsal de fournisseur de multi-connectivité au HN ; ou router le trafic relatif au HN vers l'UE via l'interface d'accès déjà connectée.


     
    6. Système selon la revendication 5, où la détermination si au moins une des interfaces d'accès de l'UE est déjà connectée au HN est basée sur : une géolocalisation, un identifiant d'ensemble de services SSID, ou un signalement entre l'UE et le système dorsal de fournisseur de multi-connectivité.
     
    7. Système selon l'une des revendications 2 à 6, où la connexion tunnel est cryptée.
     
    8. Système selon l'une des revendications 1 à 7, où le système dorsal de fournisseur de multi-connectivité est en outre prévu pour contrôler si les au moins deux interfaces d'accès ont des adresses IP conflictuelles ou des adresses IP en chevauchement avec le HN, et

    si les au moins deux interfaces d'accès ont des adresses IP conflictuelles ou des adresses IP en chevauchement avec le HN,

    le système dorsal de fournisseur de multi-connectivité est prévu pour appliquer des contre-mesures, ou

    le fournisseur de multi-connectivité est prévu pour adresser un message à l'UE, ledit message comprenant une indication à l'UE pour l'application de contre-mesures.


     
    9. Système selon l'une des revendications 1 à 8, où le système dorsal de fournisseur de multi-connectivité est prévu pour établir la connexion avec le HN via une passerelle résidentielle RG.
     
    10. Procédé de réalisation d'une multi-connectivité entre un équipement utilisateur UE, et un réseau domestique HN dans un système, ledit système comprenant l'UE, au moins deux fournisseurs d'accès Internet (IAP-1, IAP-2), un système dorsal de fournisseur de multi-connectivité, le réseau domestique HN, et un réseau de données DN, où l'UE comprend au moins deux interfaces d'accès, ledit procédé comprenant :

    l'établissement, par le système dorsal de fournisseur de multi-connectivité, d'une connexion au HN ; et

    la fourniture d'un accès de l'UE au HN par le système dorsal de fournisseur de multi-connectivité,.


     
    11. Procédé selon la revendication 10,

    où l'établissement de la connexion au HN est effectué par connexion tunnel du système dorsal de fournisseur de multi-connectivité via le DN, ou

    où l'établissement de la connexion au HN est effectué par routage du système dorsal de fournisseur de multi-connectivité via le DN.


     
    12. Procédé selon la revendication 10 ou la revendication 11,

    où le DN est l'Internet, ou

    où le système dorsal de fournisseur de multi-connectivité et le HN appartiennent au même opérateur et le système dorsal de fournisseur de multi-connectivité donne accès au HN sans passer par le DN.


     
    13. Procédé selon l'une des revendications 10 à 12, ledit procédé comprenant en outre :

    la détermination, par le système dorsal de fournisseur de multi-connectivité, si l'UE est déjà connecté au HN via une interface d'accès, et

    s'il est déterminé qu'une interface d'accès est déjà connectée au HN l'arrêt de la connexion du système dorsal de fournisseur de multi-connectivité à l'EN, ou

    le routage du trafic relatif au HN vers l'UE via l'interface d'accès déjà connectée ;

    où la détermination si au moins une des interfaces d'accès de l'UE est déjà connectée au HN est basée sur : une géolocalisation, un identifiant d'ensemble de services SSID, ou un signalement entre l'UE et le système dorsal de fournisseur de multi-connectivité.


     
    14. Procédé selon l'une des revendications 10 à 13,

    où la connexion tunnel est cryptée, et/ou

    la connexion avec le HN est établie par le système dorsal de fournisseur de multi-connectivité via une passerelle résidentielle RG.


     
    15. Procédé selon l'une des revendications 10 à 14, ledit procédé comprenant en outre :

    le contrôle, au niveau du système dorsal de fournisseur de multi-connectivité, si les au moins deux interfaces d'accès ont des adresses IP conflictuelles ou des adresses IP en chevauchement avec le HN, et

    si les au moins deux interfaces d'accès ont des adresses IP conflictuelles ou des adresses IP en chevauchement avec le HN,

    l'application de contre-mesures au niveau du système dorsal de fournisseur de multi-connectivité, ou

    l'envoi d'un message à l'UE, ledit message comprenant une indication à l'UE pour l'application de contre-mesures.


     




    Drawing














    Cited references

    REFERENCES CITED IN THE DESCRIPTION



    This list of references cited by the applicant is for the reader's convenience only. It does not form part of the European patent document. Even though great care has been taken in compiling the references, errors or omissions cannot be excluded and the EPO disclaims all liability in this regard.

    Patent documents cited in the description




    Non-patent literature cited in the description