DE102014208162A1 - Mehrweg-tcp-subflow-aufbau und -steuerung - Google Patents

Mehrweg-tcp-subflow-aufbau und -steuerung Download PDF

Info

Publication number
DE102014208162A1
DE102014208162A1 DE102014208162.9A DE102014208162A DE102014208162A1 DE 102014208162 A1 DE102014208162 A1 DE 102014208162A1 DE 102014208162 A DE102014208162 A DE 102014208162A DE 102014208162 A1 DE102014208162 A1 DE 102014208162A1
Authority
DE
Germany
Prior art keywords
network interface
mptcp
establish
remote endpoint
over
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
DE102014208162.9A
Other languages
English (en)
Other versions
DE102014208162B4 (de
Inventor
c/o Apple Inc. Biswas Anumita
c/o Apple Inc. Graessley Joshua V.
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Apple Inc
Original Assignee
Apple Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Apple Inc filed Critical Apple Inc
Publication of DE102014208162A1 publication Critical patent/DE102014208162A1/de
Application granted granted Critical
Publication of DE102014208162B4 publication Critical patent/DE102014208162B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • H04L67/141Setup of application sessions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/24Multipath
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/14Multichannel or multilink protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/10Connection setup
    • H04W76/15Setup of multiple wireless link connections
    • H04W76/16Involving different core network technologies, e.g. a packet-switched [PS] bearer in combination with a circuit-switched [CS] bearer

Abstract

Techniken für elektronische Vorrichtungen zum Steuern einer Mehrpfad-Übertragungssteuerungsprotokoll(MPTCP)-Verbindung. Eine MPTCP-Verbindung zwischen zwei Endpunkten kann aufgebaut werden. Die MPTCP-Verbindung kann zumindest einen MPTCP-Subflow umfassen. Zumindest einer der Endpunkte kann eingerichtet sein zum Agieren als ein Master in Bezug auf die MPTCP-Verbindung. Der Master kann eine oder mehrere Steuerungsoperationen auf der MPTCP-Verbindung ausführen, während, wenn einer der Endpunkte nicht ein Master ist, dieser Endpunkt nicht Steuerungsoperationen auf der MPTCP-Verbindung ausführen kann. Die Steuerungsoperationen können Initiieren oder Aufbauen neuer MPTCP-Subflows oder Modifizieren einer Prioritätsstufe eines oder mehrerer MPTCP-Subflows der MPTCP-Verbindung umfassen.

Description

  • HINTERGRUND
  • Gebiet der Erfindung
  • Die vorliegende Offenbarung bezieht sich auf elektronische Vorrichtungen, und insbesondere auf ein System und ein Verfahren für eine drahtlose Vorrichtung zum Aufbauen und Steuern von Mehrweg-TCP-Subflows.
  • Beschreibung der verwandten Technik
  • Die Verwendung von drahtlosen Kommunikationssystemen wächst schnell. Zusätzlich existieren viele unterschiedliche drahtlose Kommunikationstechnologien und -standards. Einige Beispiele von drahtlosen Kommunikationsstandards umfassen GSM, UMTS (WCDMA), LTE, LTE Advanced (LTE-A), 3GPP2 CDMA2000 (z. B. 1xRTT, 1xEV-DO, HRPD, eHRPD), IEEE 802.11 (WLAN oder Wi-Fi), IEEE 802.16 (WiMAX), Bluetooth und andere.
  • Einige dieser Standards können komplementären Funktionen dienen, während andere typischerweise als Konkurrenten betrachtet werden können, die versuchen, ähnliche Bedürfnisse der Verbraucher zu erfüllen. Dementsprechend ist es üblich für zumindest einige drahtlose Vorrichtungen unter Verwendung mehrerer drahtloser Technologien oder Standards zu kommunizieren. Zum Beispiel können einige drahtlose Vorrichtungen (wie beispielsweise Smartphones usw.) fähig zu zellularer Kommunikation sowie Wi-Fi-Kommunikation sein.
  • ZUSAMMENFASSUNG
  • Ausführungsformen eines Verfahrens werden hierin dargestellt für eine elektronische Vorrichtung zum Aufbauen und Einrichten einer Steuerung von Mehrweg-TCP (MPTCP)-Verbindungen und -Subflows, und einer elektronischen Vorrichtung, welche eingerichtet ist, das Verfahren zu implementieren.
  • Techniken zum Aufbauen von MPTCP-Verbindungen werden hierin beschrieben, welche verschiedene Charakteristika unterschiedlicher Typen von Netzwerkschnittstellen berücksichtigen können. Zum Beispiel ist klar, dass viele drahtlose (z. B. mobile) Vorrichtungen sowohl Wi-Fi- als auch zellulare Netzwerkschnittstellen umfassen können, welche fähig sind, Datenverbindungen bereitzustellen, während viele Server (und andere feste/stationäre Vorrichtungen) primär oder exklusiv verdrahtete Netzwerkschnittstellen umfassen können.
  • Da unterschiedliche Netzwerkschnittstellen unterschiedliche Verfügbarkeiten haben können und Verwendungspräferenzen in Bezug auf unterschiedliche Netzwerkschnittstellen sich im Allgemeinen unterscheiden können, kann gemäß einigen der hierin dargestellten Techniken eine Vorrichtung die Verfügbarkeit ihrer Netzwerkschnittstellen überwachen und/oder Netzwerkschnittstellen-Verwendungspräferenzen berücksichtigen, welche spezifisch für die Vorrichtung oder Klasse von Vorrichtungen sind, beim Bestimmen wie und in welcher Reihenfolge zu versuchen ist, eine MPTCP-Verbindung aufzubauen.
  • Auch hierin beschrieben sind Techniken zum Steuern einer MPTCP-Verbindung. Unter erneuter Berücksichtigung von verschiedenen Charakteristika von unterschiedlichen Typen von Netzwerkschnittstellen und Vorrichtungen, welche diese verschiedenen Typen von Netzwerkschnittstellen implementieren, kann gemäß einigen der hierin dargestellten Techniken eine Vorrichtung die Leitung ausüben/sich selbst deklarieren ein Master in Bezug auf eine MPTCP-Verbindung zu sein, oder im Gegenteil kann sie Nicht-Leitung ausüben/sich selbst deklarieren ein Slave in Bezug auf eine MPTCP-Verbindung zu sein. Auf solch eine Weise können Vorrichtungen, welche stärkere Netzwerkschnittstellen-Verwendungspräferenzen haben (wie beispielsweise mobile Vorrichtungen in einigen Fällen) eine MPTCP-Verbindung gemäß ihrer Netzwerkschnittstellen-Verwendungspräferenzen steuern, während Vorrichtungen mit schwächeren oder nicht-existierenden Netzwerkschnittstellen-Verwendungspräferenzen (wie beispielsweise feste/stationäre Vorrichtungen in einigen Fällen) nicht beabsichtigte Verletzungen der Netzwerkschnittstellen-Verwendungspräferenzen der Vorrichtungen vermeiden können, mit welchen sie MPTCP-Verbindungen aufbauen.
  • Unter der Annahme von Rollen als Master oder Slave in Bezug auf eine MPTCP-Verbindung können Vorrichtungen entweder die Fähigkeit zum Ausführen bestimmter Steuerungsoperationen auf der MPTCP-Verbindung annehmen oder darauf verzichten. Zum Beispiel kann eine Erlaubnis zum Initiieren irgendwelcher neuer MPTCP-Subflows einer MPTCP-Verbindung für Vorrichtungen reserviert sein, welche eine Master-Rolle in Bezug auf eine MPTCP-Verbindung annehmen. Als ein anderes Beispiel kann eine Erlaubnis zum Modifizieren von Prioritäts-Stufen von MPTCP-Subflows einer MPTCP-Verbindung für Vorrichtungen reserviert sein, welche eine Master-Rolle in Bezug auf eine MPTCP-Verbindung annehmen.
  • Die hierin beschriebenen Techniken können mit einer Anzahl von unterschiedlichen Typen von Vorrichtungen implementiert sein und/oder verwendet werden, einschließlich aber nicht beschränkt auf tragbare Mediaplayer, Mobiltelefone, Tablet Computer, Set-Top-Box-Vorrichtungen, Fernsehsysteme, Server und andere Rechnervorrichtungen.
  • Diese Zusammenfassung soll eine kurze Übersicht eines Teils des Gegenstands bereitstellen, welcher in diesem Dokument beschrieben wird. Entsprechend ist klar, dass die oben beschriebenen Merkmale lediglich Beispiele sind und nicht ausgelegt werden sollen, den Geltungsbereich oder den Geist des Gegenstands, welcher hierin beschrieben wird, auf irgendeine Weise zu begrenzen. Andere Merkmale, Aspekte und Vorteile des Gegenstands, welcher hierin beschrieben wird, werden aus der folgenden detaillierten Beschreibung, den Figuren und den Ansprüchen offensichtlich werden.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Ein besseres Verständnis des vorliegenden Gegenstands kann erreicht werden, wenn die folgende detaillierte Beschreibung der bevorzugten Ausführungsform in Verbindung mit den folgenden Zeichnungen betrachtet wird, in welchen:
  • 1 bis 2 beispielhafte (und vereinfachte) drahtlose Kommunikationssysteme zeigen;
  • 3 eine zellulare Basisstation und einen Wi-Fi-Zugangspunkt in Kommunikation mit einer drahtlosen Benutzerausrüstungsvorrichtung zeigt;
  • 4 ein beispielhaftes Blockdiagramm einer drahtlosen Benutzerausrüstungsvorrichtung zeigt;
  • 5 einen beispielhaften Protokollstapel zeigt, welcher verwendet werden kann in Verbindung mit Mehrweg-Übertragungssteuerungsprotokollkommunikationen;
  • 6 ein Flussdiagramm ist, welches Aspekte einer Technik zum Aufbauen einer MPTCP-Verbindung zeigt; und
  • 7 ein Nachrichtensequenzdiagramm ist, welches eine beispielhafte Nachrichtensequenz zeigt, welche verwendet werden kann als Teil eines Aufbauens einer MPTCP-Verbindung.
  • Während die hierin beschriebenen Merkmale verschiedenen Modifikationen und alternativen Formen zugänglich sind, werden spezifische Ausführungsformen davon beispielhaft in den Zeichnungen gezeigt und werden hierin im Detail beschrieben. Jedoch ist klar, dass die Zeichnungen und die detaillierte Beschreibung dazu nicht die spezielle offenbarte Form beschränken sollen, sondern im Gegenteil ist die Absicht, alle Modifikationen, Äquivalente und Alternativen, welche in den Geist und den Geltungsbereich des Gegenstands, wie er durch die angehängten Ansprüche definiert ist, abzudecken.
  • DETAILLIERTE BESCHREIBUNG DER AUSFÜHRUNGSFORMEN Ausdrücke
  • Das Folgende ist ein Glossar von Ausdrücken, welche in der vorliegenden Offenbarung verwendet werden:
    Speichermedium – irgendeiner von verschiedenen Typen von Speichervorrichtungen oder Speicherungsvorrichtungen. Der Ausdruck „Speichermedium” soll ein Installationsmedium, z. B. eine CD-ROM, Floppy Disks, oder Bandvorrichtung; einen Computersystemspeicher oder Speicher mit wahlfreiem Zugriff, wie beispielsweise DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, usw.; einen nicht-flüchtigen Speicher, wie beispielsweise einen Flash, magnetische Medien, z. B. eine Festplatte oder optischen Speicher; Register, oder andere ähnliche Typen von Speicherelementen, usw. umfassen. Das Speichermedium kann ebenso andere Typen von Speicher oder Kombinationen davon umfassen. Zusätzlich kann das Speichermedium in einem ersten Computersystem angeordnet sein, in welchem die Programme ausgeführt werden, oder kann in einem zweiten unterschiedlichen Computersystem angeordnet sein, welches über ein Netzwerk mit dem ersten Computersystem verbunden wird, wie beispielsweise das Internet. In dem letzeren Fall kann das zweite Computersystem Programminstruktionen an den ersten Computer zur Ausführung bereitstellen. Der Ausdruck „Speichermedium” kann zwei oder mehrere Speichermedien umfassen, welche in unterschiedlichen Orten liegen können, z. B. in unterschiedlichen Computersystemen, welche über ein Netzwerk verbunden sind. Das Speichermedium kann Programminstruktionen speichern (z. B. verkörpert als Computerprogramme), welche durch einen oder mehrere Prozessoren ausgeführt werden können.
  • Trägermedium – ein Speichermedium wie oben beschrieben, sowie ein physisches Übertragungsmedium, wie beispielsweise ein Bus, Netzwerk und/oder anderes physisches Übertragungsmedium, welches Signale übermittelt, wie beispielsweise elektrische, elektromagnetische oder digitale Signale.
  • Programmierbares Hardwareelement – umfasst verschiedene Hardwarevorrichtungen, welche mehrere programmierbare Funktionsblöcke aufweisen, welche über eine programmierbare Verbindung verbunden sind. Beispiele umfassen FPGAs (feldprogrammierbare Gate Arrays), PLDs (programmierbare Logikvorrichtungen), FPOAs (feldprogrammierbare Objekt-Arrays) und CPLDs (komplexe PLDs). Die programmierbaren Funktionsblöcke reichen von feinkörnig (kombinatorische Logik oder Nachschlagetabellen) bis grobkörnig (arithmetische Logikeinheiten oder Prozessorkerne). Ein programmierbares Hardwareelement kann auch bezeichnet werden als „rekonfigurierbare Logik”.
  • Computersystem – irgendeines von verschiedenen Typen von Rechner- oder Verarbeitungssystemen einschließlich einem Personal Computersystem (PC), Mainframe Computersystem, Workstation, Netzwerkgerät, Internetgerät, persönlicher digitaler Assistent (PDA), persönliche Kommunikationsvorrichtung, Smartphone, Fernsehsystem, räumlich verteiltes Rechnersystem (grid computing system) oder andere Vorrichtungen oder Kombinationen von Vorrichtungen. Im Allgemeinen kann der Ausdruck „Computersystem” breit definiert werden, um irgendeine Vorrichtung (oder Kombinationen von Vorrichtungen) zu umfassen, welche zumindest einen Prozessor aufweist, welcher Instruktionen von einem Speichermedium ausführt.
  • Benutzerausrüstung (UE) (oder „UE-Vorrichtung”) – irgendeines von verschiedenen Typen von Computersystemvorrichtungen, welche mobil oder tragbar sind und welche drahtlose Kommunikationen ausführen. Beispiele von UE-Vorrichtungen umfassen Mobiltelefone oder Smartphones (z. B. iPhoneTM, AndroidTM-basierte Telefone), tragbare Spielvorrichtungen (z. B. Nintendo DSTM, PlayStation PortableTM, Gameboy AdvanceTM, iPhoneTM), Laptops, PDAs, tragbare Internetvorrichtungen, Musikplayer, Datenspeicherungsvorrichtungen oder andere Handheld-Vorrichtungen, usw. Im Allgemeinen kann der Ausdruck „UE” oder „UE-Vorrichtung” breit definiert sein, um irgendeine elektronische, Rechner- und/oder Telekommunikationsvorrichtung (oder Kombination von Vorrichtungen) zu umfassen, welche leicht durch einen Benutzer transportiert wird und zu drahtloser Kommunikation fähig ist.
  • Basisstation – Der Ausdruck „Basisstation” hat die volle Breite seiner gewöhnlichen Bedeutung und umfasst zumindest eine drahtlose Kommunikationsstation, welche an einem festen Ort installiert ist und verwendet wird zum Kommunizieren als Teil eines drahtlosen Telefonsystems oder Funksystems.
  • Verarbeitungselement – bezieht sich auf verschiedene Elemente oder Kombinationen von Elementen. Verarbeitungselemente umfassen z. B. Schaltkreise, wie beispielsweise einen ASIC (anwendungsspezifischen integrierten Schaltkreis), Abschnitte oder Schaltkreise von Einzelprozessorkernen, ganze Prozessorkerne, Einzelprozessoren, programmierbare Hardwarevorrichtungen, wie beispielsweise ein feldprogrammierbares Gate Array (FPGA), und/oder größere Abschnitten von Systemen, welche mehrere Prozessoren umfassen.
  • Automatisch – bezieht sich auf eine Handlung oder Operation, welche durch ein Computersystem (z. B. Software, welche durch das Computersystem ausgeführt wird) oder Vorrichtungen (z. B. Schaltung, programmierbare Hardwareelemente, ASICs, usw.) ausgeführt wird, ohne Benutzereingabe, welche die Handlung oder Operation direkt spezifiziert oder ausführt. Somit steht der Ausdruck „automatisch” im Gegensatz zu einer Operation, welche durch den Benutzer manuell ausgeführt oder spezifiziert wird, wo der Benutzer Eingabe bereitstellt zum direkten Ausführen der Operation. Eine automatische Prozedur kann durch Eingabe, welche durch den Benutzer bereitgestellt wird, initiiert werden, aber die nachfolgenden Handlungen, welche „automatisch” ausgeführt werden, werden nicht durch den Benutzer spezifiziert, d. h. nicht „manuell” ausgeführt, wobei der Benutzer jede Handlung zum Ausführen spezifiziert. Zum Beispiel füllt ein Benutzer, welcher ein elektronisches Formblatt ausfüllt durch Auswählen jedes Feldes und Bereitstellen von Eingabe, welche Informationen spezifiziert (z. B. durch Eintippen von Information, Auswählen von Checkboxen, Radio-Auswahl, usw.) das Formblatt manuell aus, obwohl das Computersystem das Formblatt in Antwort auf die Benutzerhandlungen aktualisieren muss. Das Formblatt kann automatisch durch das Computersystem ausgefüllt werden, wobei das Computersystem (z. B. Software, welche auf dem Computersystem ausgeführt wird) die Felder des Formblattes analysiert und das Formblatt ausfüllt, ohne irgendeine Benutzereingabe auf die Felder, welche die Antworten spezifiziert. Wie oben gezeigt, kann der Benutzer das automatische Ausfüllen des Formblattes aufrufen, aber ist nicht beteiligt an dem tatsächlichen Ausfüllen des Formblattes (z. B. spezifiziert der Benutzer nicht manuell die Antworten auf Felder, sondern sie werden vielmehr automatisch vervollständigt). Die vorliegende Beschreibung stellt verschiedene Beispiele von Operationen bereit, welche automatisch ausgefüllt werden in Antwort auf Handlungen, welche der Benutzer vorgenommen hat.
  • Fig. 1 bis Fig. 2 – Kommunikationssystem
  • 1 bis 2 zeigen beispielhafte (und vereinfachte) Kommunikationssysteme. Es ist klar, dass die Systeme von 1 bis 2 lediglich Beispiele von möglichen Systemen sind und Ausführungsformen in irgendwelchen von verschiedenen Systemen wie gewünscht implementiert werden können.
  • Das beispielhafte drahtlose Kommunikationssystem, welches in 1 gezeigt ist, umfasst zwei Endpunkte mit mehreren Kommunikationspfaden zwischen ihnen. Somit kann der Endpunkt 102 fähig sein zum Kommunizieren mit dem Endpunkt 104 über den Pfad 106 oder den Pfad 108.
  • Jeder der Endpunkte 102 und 104 kann ein „fester” oder „mobiler” Endpunkt sein. Ein fester Endpunkt kann ein Endpunkt sein, welcher im Wesentlichen stationär ist und/oder welcher über eine oder mehrere verdrahtete Kommunikationstechniken kommuniziert. Einige Beispiele könnten einen Servercomputer, welcher Cloud-basierte Dienste über das Internet bereitstellt, einen Personal Desktop Computer oder eine Workstation, Set Top Box oder Fernseher und so weiter umfassen. Ein mobiler Endpunkt kann ein Endpunkt sein, welcher im Wesentlichen mobil ist und/oder welcher über einen oder mehrere drahtlose Kommunikationstechniken kommuniziert. Einige Beispiele könnten ein Mobiltelefon oder Smartphone, Tablet Computer, tragbare Spielvorrichtung, tragbaren Mediaplayer usw. umfassen. Zu beachten ist, dass die hybriden Endpunkte, welche Eigenschaften von sowohl festen als auch mobilen Endpunkten teilen, auch möglich sind. Zum Beispiel können viele Laptop-Computer fähig sein zum Ausführen sowohl drahtloser (z. B. Wi-Fi) als auch verdrahteter (z. B. Ethernet) Kommunikation, und können zusätzlich fähig sein zu substantieller Bewegung (z. B. wenn von einer Batteriereserveleistung betrieben) oder können im Wesentlichen stationär sein (z. B. wenn an eine Wandsteckdose für Leistung gedockt und/oder verbunden) zu verschiedenen Zeiten.
  • Einer oder beide der Endpunkte 102, 104 können mehrfach untergebracht (multi-homed) sein. Zum Beispiel können einer oder beide der Endpunkte 102, 104 fähig sein zum Kommunizieren über mehrere Netzwerkschnittstellen. Als solche kann es mehrere mögliche Kommunikationspfade 106, 108 zwischen den Endpunkten 102, 104 geben. Zu beachten ist, dass, obwohl zwei Pfade (d. h. Pfad 106 und Pfad 108) in 1 gezeigt sind, es klar ist, dass irgendeine Anzahl von Pfaden zwischen den Endpunkten existieren kann. Zum Beispiel, wenn jeder der Endpunkte 102, 104 fähig ist zum Kommunizieren über zwei unterschiedliche Netzwerkschnittstellen, könnte es vier mögliche Kommunikationspfade zwischen ihnen geben. Andere Anzahlen von unterschiedlichen Netzwerkschnittstellen und möglichen Kommunikationspfaden sind auch möglich.
  • Die mehreren Kommunikationspfade 106, 108 können verwendet werden zum Aufbauen einem Mehrweg-Übertragungssteuerungsprotokoll(MPTCP)-Link oder -Verbindung zwischen den Endpunkten 102 und 104. Zum Beispiel kann ein Subflow der MPTCP-Verbindung aufgebaut werden über den Pfad 106, während ein anderer Subflow der MPTCP-Verbindung aufgebaut werden kann über den Pfad 108. Solch eine MPTCP-Verbindung kann gemäß verschiedenen Aspekten der vorliegenden Offenbarung aufgebaut und eingerichtet/gesteuert werden.
  • Das beispielhafte drahtlose Kommunikationssystem, welches in 2 gezeigt ist, stellt ein mögliches Kommunikationssystem mit den Charakteristiken des beispielhaften drahtlosen Kommunikationssystems dar, welches in 1 gezeigt ist. Insbesondere kann ein erster Endpunkt (d. h. eine drahtlose Benutzerausrüstungs(„UE”)-Vorrichtung 206) fähig sein zum Kommunizieren mit einem anderen Endpunkt (d. h. Server 210) unter Verwendung von entweder einem ersten Kommunikationspfad (d. h. über die zellulare Basisstation 204, Kernnetzwerk 208 und Großraumnetzwerk 200) oder einem zweiten Kommunikationspfad (d. h. über den Wi-Fi-Zugangspunkt 202 und das Großraumnetzwerk 200).
  • Wie gezeigt, kommuniziert die UE-Vorrichtung 206 mit einem Wi-Fi-Zugangspunkt 202 und mit einer zellularen Basisstation 204. Der Zugangspunkt 202 kann ein Zugangspunkt sein, welcher ein drahtloses lokales Bereichsnetzwerk (WLAN) bereitstellt. Der Zugangspunkt 202 kann ausgerüstet sein zum Kommunizieren mit einem Großraumnetzwerk (WAN) 200, wie beispielsweise das Internet. Somit kann der Zugangspunkt 202 Kommunikation zwischen der UE 206 und dem Netzwerk 200 ermöglichen. Der Zugangspunkt 202 und die UE 206 können eingerichtet sein zum Kommunizieren über das Übertragungsmedium unter Verwendung von Wi-Fi, einschließlich irgendeiner von verschiedenen Versionen von IEEE 802.11 (z. B. a, b, g, n, ac, usw.). Zu beachten ist, dass der Zugangspunkt 202 auch Kommunikation zwischen der UE und anderen Rechnervorrichtungen ermöglichen kann, welche auch direkt in dem WLAN teilnehmen.
  • Die Basisstation 204 kann eine Basis-Transceiver-Station (BTS) oder ein Zellenstandort (cell site) (eine „zellulare Basisstation”) sein, und kann Hardware umfassen, welche drahtlose Kommunikation mit zellularen Vorrichtungen (wie beispielsweise UE 206) gemäß einem oder mehreren zellularen Kommunikationsprotokollen ermöglicht. Die UE 206 und die zellulare Basisstation 204 können unter Verwendung irgendeiner von verschiedenen zellularen Kommunikationstechnologien kommunizieren, wie beispielsweise GSM, UMTS (WCDMA), LTE, LTE Advanced (LTE-A), 3GPP2 CDMA2000 (z. B. 1xRTT, 1xEV-DO, HRPD, eHRPD), usw.
  • Wie gezeigt, kann die zellulare Basisstation ausgerüstet sein zum Kommunizieren mit einem Kernnetzwerk 208 eines zellularen Dienstanbieters. Somit kann die Basisstation 204 Kommunikation zwischen der UE 206 und dem Kernnetzwerk 208 ermöglichen. Das Kernnetzwerk 208 kann wiederum ausgerüstet sein zum Kommunizieren mit WAN 200 (z. B. dem Internet oder einem anderen Großraumnetzwerk). Zu beachten ist, dass das Kernnetzwerk 208 auch oder alternativ ausgerüstet sein kann zum Kommunizieren mit einem oder mehreren anderen Netzwerken (z. B. einem Telekommunikationsnetzwerk, wie beispielsweise einem öffentlichen Telekommunikationsnetz (public switched telephone network, PSTN), oder einem oder mehreren Kernnetzwerken anderer zellularer Dienstanbieter, usw.). Die zellulare Basisstation 204 kann somit der UE 206 (und potentiell vielen anderen UEs) verschiedene Telekommunikationsfähigkeiten bereitstellen, wie beispielsweise Sprach- und SMS-Dienste (z. B. typischerweise über leitungsvermittelte drahtlose Links) und/oder Datendienste (z. B. typischerweise über paketvermittelte drahtlose Links).
  • Somit kann die UE 206 fähig sein zum Kommunizieren unter Verwendung von mehreren drahtlosen Kommunikationsstandards, einschließlich zumindest einem drahtlosen Netzwerkprotokoll (z. B. Wi-Fi) und zumindest einem zellularen Kommunikationsprotokoll (z. B. GSM, UMTS (WCDMA), LTE, LTE Advanced (LTE-A), 3GPP2 CDMA2000 (z. B. 1xRTT, 1xEV-DO, HRPD, eHRPD), usw.). Zu beachten ist zusätzlich, dass die UE 206 auch oder alternativ eingerichtet sein kann zum Kommunizieren unter Verwendung eines oder mehrerer globaler Navigationssatellitensysteme (GNSS, z. B. GPS oder GLONASS), eines oder mehrerer mobiler Fernsehausstrahlungsstandards (z. B. ATSC-M/H oder DVB-H) und/oder irgendeines anderen drahtlosen Kommunikationsprotokolls, wenn es gewünscht ist. Zusätzlich oder als eine Alternative kann die UE 206 fähig sein zum Kommunizieren unter Verwendung eines oder mehrerer verdrahteter Kommunikationsstandards. Zum Beispiel kann die UE 206 fähig sein zum Kommunizieren mit einem oder mehreren verdrahteten Zugangspunkten, z. B. über Ethernet. Es kann z. B. möglich sein für die UE 206, über verdrahtete Mittel mit dem Wi-Fi-Zugangspunkt 202 zu koppeln, zusätzlich zu oder als Alternative zum Verwenden von Wi-Fi-Kommunikation. Andere Kombinationen von drahtlosen und verdrahteten Kommunikationsstandards (einschließlich mehr als zwei drahtlose und/oder verdrahtete Kommunikationsstandards) sind auch möglich.
  • Der Server 210 kann auch ausgerüstet sein zum Kommunizieren mit WAN 200. Der Server 210 kann z. B. ein Server in einer Serverfarm sein, eingerichtet zum Bereitstellen eines Cloud-basierten Dienstes über das Internet. Es ist zu beachten, dass während der Server 210 gezeigt ist als direkt mit dem WAN 200 verbunden, es der Fall sein kann, dass der Server 210 mit dem WAN 200 durch eine oder mehrere Zwischenvorrichtungen und/oder -Entitäten verbunden ist, wie beispielsweise Gateways, Router, Firewalls und/oder irgendwelche von verschiedenen anderen „Mittelboxen”. Zusätzlich ist zu beachten, dass während es nicht explizit gezeigt ist, der Server 210 irgendeine Anzahl von Netzwerkschnittstellen umfassen kann zum Verbinden mittels dem WAN 200, einschließlich einer oder mehrerer verdrahteter Netzwerkschnittstellen und/oder einer oder mehrerer drahtloser Netzwerkschnittstellen.
  • 3 zeigt die UE-Vorrichtung 206 in Kommunikation mit der zellularen Basisstation 204 und dem Wi-Fi-Zugangspunkt 202. Die UE 106 kann eine Vorrichtung sein mit mehrfacher drahtloser Netzwerkkonnektivität, wie beispielsweise ein Mobiltelefon, eine Handheld-Vorrichtung, ein Computer oder ein Tablet, oder nahezu jeder Typ von drahtloser Vorrichtung.
  • Die UE 206 kann einen Prozessor umfassen, welcher eingerichtet ist zum Ausführen von Programminstruktionen, welche im Speicher gespeichert sind. Die UE 206 kann irgendeines der Verfahrensausführungsformen ausführen, welche hierin beschrieben sind, durch Ausführen solcher gespeicherter Instruktionen. Alternativ oder zusätzlich kann die UE 206 ein programmierbares Hardwareelement umfassen, wie beispielsweise ein FPGA (feldprogrammierbares Gate Array), welches eingerichtet ist zum Ausführen irgendeiner der Verfahrensausführungsformen, welche hierin beschrieben sind, oder irgendeines Abschnittes irgendeines der Verfahrensausführungsformen, welche hierin beschrieben sind.
  • Die UE 206 kann eingerichtet sein zum Kommunizieren unter Verwendung irgendeines der mehreren drahtlosen Kommunikationsprotokolle. Zum Beispiel kann die UE 206 eingerichtet sein zum Kommunizieren unter Verwendung zumindest eines zellularen Kommunikationsprotokolls (wie beispielsweise CDMA2000, LTE, LTE-A, usw.) und Wi-Fi. Andere Kombinationen von drahtlosen und/oder verdrahteten Kommunikationsstandards sind auch möglich.
  • Die UE 206 kann eine oder mehrere Antennen zum Kommunizieren umfassen unter Verwendung eines oder mehrerer drahtloser Kommunikationsprotokolle. Die UE 206 kann einen oder mehrere Teile einer Empfangen- und/oder Übertragen-Kette zwischen mehreren drahtlosen Kommunikationsstandards teilen; z. B. könnte die UE 206 eingerichtet sein zum Kommunizieren unter Verwendung jeder der CMDA2000 (1xRTT/1xEV-DO/HRPD/eHRPD) oder LTE unter Verwendung von teilweise oder gesamt geteilten drahtlosen Kommunikationsschaltungen (z. B. unter Verwendung einer geteilten Funkeinheit oder zumindest geteilten Funkkomponenten). Die geteilte Kommunikationsschaltung kann eine einzelne Antenne umfassen, oder kann mehrere Antennen umfassen (z. B. für MIMO) zum Ausführen von drahtlosen Kommunikationen. Alternativ kann die UE 206 separate Übertragen- und/oder Empfangen-Ketten (z. B. einschließlich getrennte Antennen und andere Funkkomponenten) für jedes drahtlose Kommunikationsprotokoll umfassen, mit welchem es zum Kommunizieren eingerichtet ist. Als eine weitere Möglichkeit kann die UE 206 ein oder mehrere Funkeinheiten oder Funkkomponenten umfassen, welche zwischen mehreren drahtlosen Kommunikationsprotokollen geteilt werden, und ein oder mehrere Funkeinheiten oder Funkkomponenten, welche verwendet werden exklusiv durch ein einzelnes drahtloses Kommunikationsprotokoll. Zum Beispiel könnte die UE 206 eine geteilte Funkeinheit zum Kommunizieren unter Verwendung von einem von LTE oder CDMA2000 1xRTT, und separate Funkeinheiten umfassen zum Kommunizieren unter Verwendung von jedem aus Wi-Fi und Bluetooth. Andere Konfigurationen sind auch möglich.
  • Fig. 4 – Beispielhaftes Blockdiagramm einer UE
  • 4 zeigt ein beispielhaftes Blockdiagramm einer UE 206. Wie gezeigt, kann die UE 206 ein System auf einem Chip (SOC) 400 umfassen, welches Abschnitte für verschiedene Zwecke umfassen kann. Zum Beispiel wie gezeigt, kann das SOC 400 einen Prozessor(en) 402, welche(r) Programminstruktionen für die UE 206 ausführen kann, und Anzeigeschaltung 404 umfassen, welche Graphikverarbeitung ausführen kann und Anzeigesignale an die Anzeige 460 bereitstellen kann. Der Prozessor/die Prozessoren 402 können auch mit einer Speicherverwaltungseinheit (MMU) 440 gekoppelt sein, welche eingerichtet sein kann zum Empfangen von Adressen von dem Prozessor/den Prozessoren 402 und diese Adressen zu Orten im Speicher übersetzen kann (z. B. Speicher 406, Nur-Lese-Speicher (ROM) 450, NAND-Flashspeicher 410) und/oder zu anderen Schaltungen oder Vorrichtungen, wie beispielsweise die Anzeigeschaltung 404, drahtlose Kommunikationsschaltung 430 (auch bezeichnet als ein „Funkeinheit”), Verbinder I/F 420, und/oder Anzeige 460. Die MMU 440 kann eingerichtet sein zum Ausführen von Speicherschutz und Seitentabellenübersetzung oder Setup. In einigen Ausführungsformen kann die MMU 440 umfasst sein als ein Abschnitt des Prozessors/der Prozessoren 402.
  • Wie gezeigt, kann das SOC 400 mit verschiedenen anderen Schaltungen der UE 206 gekoppelt sein. Zum Beispiel kann die UE 206 verschiedene Typen von Speicher (z. B. einschließlich NAND-Flash 410), eine Verbinderschnittstelle 420 (z. B. zum Koppeln mit einem Computersystem, Dock, Ladestation, usw.), die Anzeige 460 und drahtlose Kommunikationsschaltung (oder „Funkeinheit”) 430 (z. B. für LTE, LTE-A, CDMA2000, Bluetooth, Wi-Fi, GPS, usw.) umfassen.
  • Wie oben genannt, kann die UE 206 eingerichtet sein zum drahtlosen Kommunizieren unter Verwendung von mehreren drahtlosen Kommunikationsstandards. Wie weiter oben genannt, kann in solchen Fällen die drahtlose Kommunikationsschaltung (Funkeinheit(en)) 430 Funkkomponenten, welche zwischen mehreren drahtlosen Kommunikationsstandards geteilt werden, und/oder Funkkomponenten umfassen, welche exklusiv für die Verwendung gemäß eines einzelnen drahtlosen Kommunikationsstandards eingerichtet sind. Wie gezeigt, kann die UE-Vorrichtung 206 zumindest eine Antenne umfassen (und möglicherweise mehrere Antennen, z. B. für MIMO und/oder zum Implementieren unterschiedlicher drahtloser Kommunikationstechnologien unter verschiedenen Möglichkeiten), zum Ausführen drahtloser Kommunikation mit Basisstationen, Zugangspunkten und/oder anderen Vorrichtungen. Zum Beispiel kann die UE-Vorrichtung 206 eine Antenne 435 verwenden zum Ausführen der drahtlosen Kommunikation.
  • Die UE 206 kann auch eine oder mehrere Benutzerschnittstellenelemente umfassen und/oder eingerichtet sein zur Verwendung dieser. Die Benutzerschnittstellenelemente können irgendwelche von verschiedenen Elementen umfassen, wie beispielsweise eine Anzeige 460 (welche eine Berührungsbildschirmanzeige sein kann), eine Tastatur (welche eine diskrete Tastatur sein kann oder implementiert sein kann als Teil einer Berührungsbildschirmanzeige), eine Maus, ein Mikrofon und/oder Lautsprecher, eine oder mehrere Kameras, einen oder mehrere Tasten, und/oder irgendeine von verschiedenen anderen Elementen, welche fähig sind zum Bereitstellen von Information an einen Benutzer und/oder Empfangen/Interpretieren von Benutzereingabe.
  • Wie hierin beschrieben, kann die UE 206 Hardware- und Softwarekomponenten umfassen zum Implementieren von Merkmalen zum Aufbauen und/oder Steuern von MPTCP-Verbindungen, wie beispielsweise jene, welche hierin beschrieben sind mit Verweis auf unter anderem 5 bis 7. Der Prozessor 402 der UE-Vorrichtung 206 kann eingerichtet sein zum Implementieren eines Teils oder aller Merkmale, welche hierin beschrieben sind, z. B. durch Ausführen von Programminstruktionen, welche auf einem Speichermedium gespeichert sind (z. B. ein nicht-flüchtiges, computerlesbares Speichermedium). Alternativ (oder zusätzlich) kann der Prozessor 402 eingerichtet sein als ein programmierbares Hardwareelement, wie beispielsweise ein FPGA (feldprogrammierbares Gate Array) oder als ein ASIC (anwendungsspezifischer integrierter Schaltkreis). Alternativ (oder zusätzlich) kann der Prozessor 402 der UE-Vorrichtung 206 zusammen mit einer oder mehreren der anderen Komponenten 400, 404, 406, 410, 420, 430, 435, 440, 450, 460, eingerichtet sein zum Implementieren eines Teils oder aller der Merkmale, welche hierin beschrieben sind, wie beispielsweise die Merkmale, welche hierin beschrieben sind mit Verweis auf unter anderem 5 bis 7.
  • Fig. 5 – MPTCP-fähiger Protokollstapel
  • 5 zeigt einen beispielhaften Protokollstapel, welcher verwendet werden kann durch eine UE 500 zum Aufbauen, Einrichten und Steuern von MPTCP-Verbindungen und -Subflows zwischen der UE 500 und einem Server 518, mittels einer Mittelbox 516, gemäß verschiedenen Aspekten der vorliegenden Offenbarung. Es ist klar, dass während der beispielhafte Protokollstapel, welcher in 5 gezeigt ist, einen möglichen Protokollstapel darstellt, welcher verwendet werden kann zum Implementieren von Aspekten der vorliegenden Offenbarung, MPTCP-Verbindungen und -Subflows aufgebaut, eingerichtet und/oder gesteuert werden können in Verbindung mit irgendeinem von zahlreichen alternativen Protokollstapeln in Verbindung mit unterschiedlichen Vorrichtungen als UE 500 und Server 518 und/oder ohne eine Zwischen-Mittelbox 516 (oder mit mehreren Mittelboxen). Als solches sollte der beispielhafte Protokollstapel, welcher in 5 gezeigt ist, nicht betrachtet werden als die Offenbarung als ein Ganzes beschränkend.
  • Wie gezeigt kann eine Netzwerkanwendung 502 auf der UE 500 ausgeführt werden. Die Netzwerkanwendung kann irgendeine Anwendung sein, welche eine Netzwerkverbindung verwendet zum Kommunizieren über ein Netzwerk. Zum Beispiel kann die Anwendung (oder „App”) 502 eine Browseranwendung, Emailanwendung, Chatanwendung, Social-Media-Anwendung, Musikdienstanwendung, Spieleanwendung, Intelligenter-Persönlicher-Assistent-Anwendung und/oder irgendeine einer Vielfalt von anderen Typen von Netzwerkanwendungen sein.
  • Die Netzwerkanwendung 502 kann mit einem Netzwerk-Framework 504 eine Schnittstelle bilden, welche durch ein Betriebssystem bereitgestellt werden kann, welches auf der UE 500 ausgeführt wird. Das Netzwerk-Framework 504 kann eine Abstraktionsstufe zwischen der Anwendung 502 und der Netzwerkfunktionalität niedrigerer Stufe, welche durch die UE 500 bereitgestellt wird, bereitstellen. Das Netzwerk-Framework 504 kann wiederum mit einer TCP-Verbindungsbibliotheksentität 506 eine Schnittstelle bilden. Die TCP-Verbindungsbibliothek 506 kann Kenntnis von dem Status verschiedener Netzwerkschnittstellen haben durch Kommunikation mit einer Netzwerkschnittstellen-Statusentität 508.
  • Die Netzwerkschnittstellen-Statusentität 508 kann Up/Down-Status überwachen und die Netzwerkschnittstellen-Aufrechterhaltung verschiedener Netzwerkschnittstellen, welche für die UE 500 verfügbar sind, unterstützen. Information bezüglich des Status der verschiedenen Netzwerkschnittstellen, welche für die UE 500 verfügbar sind, kann insbesondere hilfreich sein für eine mobile Vorrichtung, welche fähig ist zum Verwenden einer oder mehrerer Formen von drahtloser Kommunikation, wie beispielsweise zellulare Kommunikation und Wi-Fi. Zum Beispiel kann die Netzwerkschnittstellen-Statusentität 508 wissen, ob eine zellulare Datenverbindung zu einer gegebenen Zeit verfügbar ist oder nicht, und kann in ähnlicher Weise wissen, ob eine Wi-Fi-Verbindung zu einer gegebenen Zeit verfügbar ist oder nicht. Die Netzwerkschnittstellen-Statusentität 508 kann in ähnlicher Weise auch irgendwelche zusätzlichen oder alternativen Netzwerkschnittstellen überwachen. In einigen Fällen kann die Netzwerkschnittstellen-Statusentität 508 auch von irgendwelchen weiteren Betrachtungen bezüglich verschiedener verfügbarer Netzwerkschnittstellen wissen, wie beispielsweise Netzwerkschnittstellen-Verwendungspräferenzen. Zum Beispiel für viele mobile Vorrichtungen kann Wi-Fi-Datenkommunikation weniger teuer sein als zellulare Datenkommunikation (z. B. wenn ein zellularer Dienstanbieter gebührenpflichtige Datenverwendung anbietet, während ein Wi-Fi-Dienstanbieter nicht gebührenpflichtige Datenverwendung anbietet); in solch einem Fall kann eine Präferenz zum Verwenden einer Wi-Fi-Netzwerkschnittstelle eher als einer zellularen Netzwerkschnittstelle für Datenkommunikation, wenn möglich durch die Netzwerkschnittstellen-Statusentität 508 in der UE 500 festgestellt werden. Andere Präferenzen oder Betrachtungen können auch oder alternativ gespeichert werden.
  • Mit dem Wissen von solch einer Information durch ihre Kommunikation mit der Netzwerkschnittstellen-Statusentität 508 kann dann die TCP-Verbindungsbibliothek 506 als ein Transportverbindungsverwalter agieren und intelligent TCP-Verbindungen für die Netzwerkanwendung 502 verwalten. Zum Beispiel kann die TCP-Verbindungsbibliothek 506 fähig sein, TCP-Verbindungen (einschließlich MPTCP-Subflows) mit vernetzten Entitäten (wie beispielsweise Server 518) über verschiedene Netzwerkschnittstellen zu initiieren und abzubrechen, MPTC-Subflow-Prioritäten herzustellen und/oder zu modifizieren und Steuerung über MPTCP-Subflow-Erzeugung und Prioritätsstatusmodifikation auszuüben, wie beispielsweise weiter nachfolgend hierin beschrieben. Die TCP-Verbindungsbibliothek 506 kann so handeln durch Socket-Lagers-BSD-Socket 510, MPTCP-Socket 512 und TCP-Verbindung/Subflows 514.
  • Wie gezeigt können die resultierenden MPTCP-Subflows aufgebaut werden als Teil einer MPTCP-Verbindung mit dem Server 518 durch die Mittelbox 516. Die Mittelbox 516 kann irgendeine einer Vielfalt von Typen von Mittelboxfunktionalität umfassen, wie beispielsweise eine Firewall, Lastenausgleich, Netzwerkadressübersetzung, usw. Zu beachten ist in einigen Fällen (z. B. abhängig von der Mittelboxfunktionalität), dass eine MPTCP-Verbindung bei der Mittelbox 516 beendet werden kann, welche wiederum Daten an den Server 518 in einer separaten Verbindung (z. B. gemäß eines Lastenausgleichsalgorithmus innerhalb einer Serverfarm) routen kann.
  • Fig. 6 – MPTCP-Subflow-Aufbauflussdiagramm
  • 6 ist ein Flussdiagramm, welches einen beispielhaften MPTCP-Aufbauprozess zeigt. Der Prozess, welcher in 6 gezeigt ist, kann insbesondere für mobile Vorrichtungen nützlich sein (z. B. Vorrichtungen, wie beispielsweise die UE 206, welche in 2 bis 4 gezeigt ist, und die UE 500, welche in 5 gezeigt ist). Zum Beispiel, wie vorher genannt, für viele solcher Vorrichtungen, kann die Verwendung einer Wi-Fi-Datenverbindung für Netzwerkkommunikationen vorzuziehen sein, wenn sie verfügbar ist, weil die Datennutzung für viele Wi-Fi-Datenverbindungen nicht gebührenpflichtig sein kann, während die Verwendung einer zellularen Datenverbindung vorzuziehen ist für Netzwerkkommunikationen als ein Backup (z. B. wenn Wi-Fi- und/oder andere Netzwerkschnittstellen nicht verfügbar sind), weil die Datennutzung für viele zellulare Datenverbindungen gebührenpflichtig sein kann. Entsprechend kann der beispielhafte MPTCP-Aufbauprozess eine MPTCP-Verbindung zunächst aufbauen und vorzugsweise versuchen, einen Wi-Fi-MPTCP-Subflow aufzubauen und nachfolgend/sekundär versuchen, einen zellularen MPTCP-Subflow wenn möglich aufzubauen.
  • Das Verfahren, welches in 6 gezeigt ist, kann verwendet werden in Verbindung mit irgendwelchen der Computersysteme oder Vorrichtungen, welche in den obigen Figuren gezeigt sind, unter anderen Vorrichtungen. Einige der Verfahrenselemente, welche gezeigt sind, können gleichzeitig ausgeführt werden, in einer unterschiedlichen Reihenfolge als gezeigt, oder können weggelassen werden. Zusätzliche Verfahrenselemente können auch wie gewünscht ausgeführt werden. Wie gezeigt, kann das Verfahren wie folgt operieren:
    In 602 kann eine MPTCP-Sitzung bei einer Vorrichtung initiiert werden. Die MPTCP-Sitzung kann initiiert werden als Teil einer Operation einer Netzwerkanwendung (z. B. Netzwerkanwendung 502, welche in 5 gezeigt ist). Die MPTCP-Sitzung kann vorgesehen sein, zumindest einen und vorzugsweise mehrere Kommunikationspfade zwischen einer ersten Vorrichtung und einer zweiten Vorrichtung in der Form einer MPTCP-Verbindung bereitzustellen. Insbesondere für eine drahtlose Vorrichtung kann Aufbauen mehrerer Kommunikationspfade wünschenswert sein, um erhöhte Stabilität bereitzustellen, z. B. in dem Fall, dass einer der Kommunikationspfade fehlschlägt (wie es manchmal drahtlose Verbindungen tun, insbesondere unter mobilen Bedingungen) oder entfernt wird. Die MPTCP-Sitzung kann verwaltet werden durch eine TCP-Verbindungsverwaltungsentität, welche auf der Vorrichtung ausgeführt wird, wie beispielsweise die TCP-Verbindungsbibliothek 506, welche in 5 gezeigt ist.
  • In 604 kann bestimmt werden, ob eine Wi-Fi-Datenverbindung vorliegt oder nicht. Wi-Fi kann vorliegen z. B. wenn die Vorrichtung innerhalb eines Bereichs eines Wi-Fi-Zugangspunkts ist und die Vorrichtung eingerichtet ist zum Kommunizieren mit dem Wi-Fi-Zugangspunkt, wie beispielsweise wenn die Vorrichtung sich in dem Haus eines Benutzers der Vorrichtung, in einem Café, welches einen bekannten Wi-Fi-Hotspot hat, in einem Arbeitsplatz mit einem Wi-Fi-Netzwerk, usw. befindet. Jedoch in vielen Fällen, wie beispielsweise wenn ein Benutzer der Vorrichtung unterwegs ist und entweder nicht innerhalb eines kommunikativen Bereichs irgendeines Wi-Fi-Netzwerks ist oder nicht eingerichtet ist zum Kommunizieren mit (z. B. nicht ein Mitglied ist von) irgendwelchen Wi-Fi-Netzwerken innerhalb des kommunikativen Bereichs, kann keine Wi-Fi-Datenverbindung vorliegen. Als eine andere Möglichkeit kann eine Wi-Fi-Datenverbindung nicht vorliegen, wenn ein Benutzer der Vorrichtung die Vorrichtung eingerichtet hat, seinen Wi-Fi-Funkeinheit auszuschalten.
  • Wenn eine Wi-Fi-Datenverbindung nicht vorliegt, kann in 606 bestimmt werden, ob eine zellulare Datenverbindung vorliegt oder nicht. Eine zellulare Datenverbindung kann z. B. vorliegen, wenn die Vorrichtung innerhalb der kommunikativen Reichweite einer Basisstation ist, welche fähig ist zum Bereitstellen von zellularem Dienst (z. B. welcher abhängen kann von den zellularen Technologiefähigkeiten der Vorrichtungen der Basisstation und/oder dem zellularen Dienstanbieter der Vorrichtung und Operator der Basisstation). Obwohl zellulare Netzwerke typischerweise viel breitere Abdeckung als Wi-Fi-Netzwerke bereitstellen, ist es in einigen Fällen auch möglich, dass keine zellulare Datenverbindung vorliegt, wie beispielsweise, wenn ein Benutzer der Vorrichtung in einem entfernten Bereich ist, welcher außerhalb der kommunikativen Reichweite irgendeiner Basisstation ist, oder nicht eingerichtet ist zum Kommunizieren mit (z. B. nicht ein Teilnehmer (subscriber) von) irgendwelchen zellularen Netzwerken innerhalb der kommunikativen Reichweite. Zusätzlich kann es auch möglich sein, dass eine zellulare Datenverbindung nicht vorliegen kann, wenn ein Benutzer der Vorrichtung die Vorrichtung eingerichtet hat, seine zellulare Funkeinheit auszuschalten.
  • Wenn weder eine Wi-Fi-Datenverbindung noch eine zellulare Datenverbindung verfügbar ist, kann in 608 bestimmt werden, dass das Internet zu der Zeit nicht verfügbar ist. In diesem Fall kann es sein, dass die gewünschte MPTCP-Sitzung zu der Zeit nicht aufgebaut werden kann.
  • Wenn eine Wi-Fi-Datenverbindung in der Entscheidung 604 vorliegt, oder wenn keine Wi-Fi-Datenverbindung in der Entscheidung 604 vorliegt, aber eine zellulare Datenverbindung in der Entscheidung 606 vorliegt, kann in 610 ein Versuch zum Aufbauen eines ersten MPTCP-Subflows gemacht werden. Abhängig davon, ob von der Entscheidung 604 oder Entscheidung 606 ankommend, kann der Versuch entweder auf der Wi-Fi-Datenverbindung oder auf der zellularen Datenverbindung gemacht werden.
  • In 612 kann bestimmt werden, ob der Subflow erfolgreich als ein MPTCP-Subflow aufgebaut wurde. Wenn der Subflow erfolgreich als ein MPTCP-Subflow aufgebaut wurde, kann in 614 Lesen/Schreiben über den ersten Subflow ausgeführt werden. Wenn jedoch die MPTCP-Aushandlung fehlschlägt, kann die Verbindung zurückfallen auf reguläres TCP in 616. Wenn die reguläre TCP-Verbindung erfolgreich aufgebaut wurde, kann in 618 Lesen/Schreiben über den regulären TCP bis zum Ende der Sitzung ausgeführt werden bei 620.
  • Wenn sowohl MPTCP- als auch TCP-Verbindungen nicht in der Lage sind ausgehandelt zu werden während eines Versuchs zum Aufbauen eines Subflows über Wi-Fi, kann in 622 ein zellulares Rückfallmerkmal (fallback feature) initiiert werden und zurückkehrend zu Schritt 610 kann ein Versuch zum Aufbauen eines MPTCP-Subflows über eine zellulare Datenverbindung ausgeführt werden. Wenn keine zellulare Datenverbindung vorliegt beim Versuchen des zellularen Rückfalls, in Schritt 622, kann in 624 (ähnlich zu Schritt 608) bestimmt werden, dass das Internet zu dieser Zeit nicht verfügbar ist.
  • Ansonsten kann ein zellularer Rückfallversuch zum Aufbauen eines ersten MPTCP-Subflows einem ähnlichen Arbeitsablauf wie einem Versuch zum Aufbauen eines ersten MPTCP-Subflows über eine Wi-Fi-Datenverbindung folgen.
  • Sobald ein erster MPTCP-Subflow aufgebaut ist (z. B. über Wi-Fi oder zellular) und Lesen/Schreiben über den ersten Subflow in 614 ausgeführt wird, kann bestimmt werden, ob die Lese-/Schreibvorgänge über den hergestellten MPTCP-Subflow erfolgreich sind oder nicht, in 626. Wie weiter nachfolgend hierin mit Verweis auf 7 beschrieben wird, kann es möglich sein, dass, selbst wenn der erste Subflow offensichtlich als ein MPTCP-Subflow hergestellt wurde, versuchte Lese- und/oder Schreib-Operationen auf dem MPTCP-Subflow nicht erfolgreich MPTCP-Charakteristika beibehalten können. In diesem Fall können in 628 die Lese-/Schreib-Operationen entweder als eine reguläre TCP-Verbindung (TCP-Rückfall) erfolgreich sein, oder können gänzlich nicht erfolgreich sein. Wenn der Rückfall auf eine reguläre TCP-Verbindung erfolgreich ist, können in 630 Lese-/Schreibvorgänge über das reguläre TCP bis zum Ende der Sitzung ausgeführt werden bei 620. Wenn der Rückfall auf eine reguläre TCP-Verbindung nicht erfolgreich ist, kann in 632 die Sitzung als nicht erfolgreich abgebrochen werden.
  • Wenn jedoch in 626 bestimmt wird, dass zumindest eine Lese- und/oder Schreib-Operation als ein MPTCP-Subflow erfolgreich ist, kann in 634 bestimmt werden, ob eine andere Netzwerkschnittstelle verfügbar ist. Somit, z. B. wenn der erste Subflow über eine Wi-Fi-Datenverbindung ist, und die zellulare Datenverbindung auch verfügbar ist, kann in 636 ein anderer MPTCP-Subflow auf der zellularen Datenverbindung initiiert werden. In ähnlicher Weise, wenn der erste Subflow über eine zellulare Datenverbindung ist (z. B. wenn kein Wi-Fi verfügbar war oder das Subflow-Setup über Wi-Fi nicht erfolgreich war), und eine andere Netzwerkschnittstelle auch verfügbar ist (z. B. wenn eine Wi-Fi-Datenverbindung verfügbar geworden ist, wenn die Vorrichtung eine weitere verfügbare Netzwerkschnittstelle hat, oder einfach als ein anderer Versuch auf eine verfügbare Wi-Fi-Datenverbindung, auf welche ein vorheriger nicht erfolgreicher Versuch bei MPTCP-Subflow-Aufbau und/oder ein Einzel-Fluss-TCP-Verbindungsaufbau gemacht wurde), kann in 636 ein anderer MPTCP-Subflow auf der ausgewählten Netzwerkschnittstelle initiiert werden. Wenn, bei Entscheidung 638, Aufbauen des zusätzlichen Subflows erfolgreich ist, kann die Sitzung (d. h. die in 602 gestartete MPTCP-Verbindung) Ausführen von Lese- und/oder Schreib-Operationen über mehrere Subflows umfassen bei 640. Wenn bei Entscheidung 638 Aufbauen des zusätzlichen Subflows nicht erfolgreich ist, zurückkehrend zu 620, können Lese- und/oder Schreib-Operationen nur auf dem erfolgreich aufgebauten Subflow ausgeführt werden, bis die Sitzung endet.
  • Wie gezeigt, ist auch möglich, dass während einer Sitzung mit zumindest einem aktiven aufgebauten Subflow Subflow-Unterbrechung auftreten kann. Zum Beispiel könnte ein Benutzer die Vorrichtung aus der kommunikativen Reichweite eines Wi-Fi-Zugangspunkts bewegen und dadurch Konnektivität auf ihrer Wi-Fi-Datenverbindung verlieren. In solch einem Fall (z. B. von Schritten 618 oder 640 bis 642 über Block 'B'), kann IP-Adressenverlust auftreten und TCP-Neuübertragungsversuche können auf dem unterbrochenen Subflow fehlschlagen. Es kann dann bestimmt werden in 644, ob ein alternativer Pfad (z. B. ein anderer MPTCP-Subflow) vorliegt. Wenn ein alternativer Pfad vorliegt, kann in 646 Failover zu einem anderen Subflow auftreten. Somit, in dem oben beschriebenen beispielhaften Fall, in welchem Konnektivität auf einer Wi-Fi-Datenverbindung verlorengeht, wenn ein MPTCP-Subflow auf einer zellularen Datenverbindung hergestellt worden ist, kann Failover zu dem zellularen Subflow auftreten und irgendwelche Lese- oder Schreib-Operationen, welche als Teil der Sitzung auftreten, können über diesen Subflow ausgeführt werden, zumindest bis ein zusätzlicher MPTCP-Subflow erneut aufgebaut werden kann. Wenn jedoch kein alternativer Pfad bei Entscheidung 644 vorliegt, kann die Sitzung bei 648 abgebrochen werden, weil keine TCP-Verbindung zu dieser Zeit verfügbar sein kann.
  • Fig. 7 – Subflow-Aufbau-Nachrichtensequenzdiagramm
  • 7 ist ein Nachrichtensequenzdiagramm, welches einen beispielhaften Nachrichtensequenzfluss zwischen Endpunkten zeigt, welche versuchen, eine MPTCP-Verbindung miteinander über mehrere Kommunikationspfade aufzubauen. Insbesondere, ein Endpunkt, als der Endpunkt, welcher die MPTCP-Verbindung initiiert, kann als ein MPTCP-Client 702 agieren, während der andere Endpunkt als der MPTCP-Server 704 agieren kann. Der Client 702 kann sowohl eine zellulare Datenverbindung als eine erste Netzwerkschnittstelle als auch eine Wi-Fi-Datenverbindung als eine zweite Netzwerkschnittstelle aufweisen.
  • Das Verfahren, welches in 7 gezeigt ist, kann in Verbindung mit irgendeinem der Computersysteme oder Vorrichtungen, welche in den obigen Figuren gezeigt sind, neben anderen Vorrichtungen verwendet werden. Zum Beispiel, als eine Möglichkeit, kann der Client 702 eine drahtlose Benutzerausrüstungs(UE)-Vorrichtung sein, wie beispielsweise UE 206 und/oder UE 500, während der Server der Server 210 und/oder der Server 518 sein könnte, welche in Bezug auf verschiedene der obigen Figuren gezeigt und beschrieben sind. Allgemeiner gesagt, können einer von beiden oder beide des Client 702 und des Server 704 „feste” oder „mobile” Endpunkte sein.
  • Zu beachten ist zusätzlich, dass einige der Nachrichten, welche gezeigt sind, gleichzeitig übertragen werden können in einer unterschiedlichen Reihenfolge als gezeigt, oder können weggelassen werden. Zusätzliche Nachrichten können wie gewünscht auch übertragen werden. Wie gezeigt, kann die Sequenz gemäß dem folgenden Fluss operieren.
  • Der Client 702 kann eine Syn-Nachricht 706 an den Server 704 als den ersten Teil eines/einer Dreiphasen-Handshake-Prozesses/Verbindungsaufbauprozedur übertragen. Wie gezeigt, kann die Syn-Nachricht 706 eine MP_Capable-Option umfassen zum Anzeigen, dass der Client 702 Aufbau einer MPTCP-Verbindung anstelle einer Standard(Einzelpfad)-TCP-Verbindung anfragt.
  • Wenn der Server 704 MPTCP-fähig ist und keine Mittelbox die Syn-Nachricht hat fallen lassen oder modifiziert hat zum Entfernen der MP_Capable-Option (z. B. Ersetzen der MP-Optionen mit keinen Operationen/NOPs), kann der Server 704 eine Syn_Ack-Nachricht 708 mit einer MP_Capable-Option übertragen zum Anzeigen, dass der Server 704 die MPTCP-Anfrage des Clients 702 bestätigt und zum Anzeigen, dass der Server 704 auch MPTCP-fähig ist.
  • Nochmals, wenn keine Mittelbox die Syn_Ack-Nachricht hat fallen lassen oder modifiziert hat zum Entfernen der MP_Capable-Option, kann der Client 702 eine Ack-Nachricht 710 an den Server 704 übertragen. Die Ack-Nachricht 710 kann auch einen oder mehrere Schlüssel (z. B. zur Verwendung beim Authentifizieren des Hinzufügen von zukünftigen Subflows zu der MPTCP-Verbindung) wie gezeigt umfassen.
  • Zu beachten ist, dass, wenn die MP_Capable-Option (z. B. durch eine Mittelbox) von einem oder beiden der Syn-Nachricht 706 oder der Syn_Ack-Nachricht 708 fallen gelassen wird, aber diese Nachrichten anderweitig intakt geliefert werden, kann fortgesetzt werden die TCP-Verbindung als eine Standard(Einzelpfad)-TCP-Verbindung aufzubauen ohne irgendeine zusätzliche Verzögerung, welche durch Versuche zum Aufbauen der TCP-Verbindung als ein MPTCP-Subflow verursacht wird. Wenn eine oder beide der Syn-Nachricht 706 oder der Syn_Ack-Nachricht 708 fallen gelassen wird, kann der Client 702 versuchen, die Syn-Nachrichten mit MPTCP-Optionen n(welche eine konfigurierbare oder vorbestimmte Zahl ist)-mal erneut zu übertragen, und dann, wenn der Verbindungsaufbau immer noch nicht erfolgreich ist, können weitere erneute Syn-Übertragungen ohne MPTCP-Optionen gemacht werden, um auf eine Standard-TCP-Verbindung zurückzufallen. In diesem Fall kann eine bestimmte Zeitdauer (z. B. die Zeitdauer, welche mit den n erneuten Übertragungsversuchen mit MPTCP-Optionen assoziiert ist) zu der Aufbauzeit der Einzelpfad-TCP-Verbindung hinzugefügt werden.
  • Sobald die Dreiphasen-MPTCP-Handshake-Prozedur erfolgreich mit der Ack-Nachricht 710 fertiggestellt wird, kann der Client 702 versuchen, Datenpakete 712 über den aufgebauten MPTCP-Subflow zu übertragen. Als Teil eines MPTCP-Subflows können die Datenpakete 712 eine MP_DSS(Datensequenzsignal)-Option umfassen.
  • Der Server 704 kann wiederum eine Ack-Nachricht 714 mit einer MP_DSS-Option in Antwort auf die Datenpakete 712 übertragen. Der Server kann zusätzlich seine eigenen Datenpakete 716 an den Client 702 über den hergestellten MPTCP-Subflow übertragen. Diese Pakete 716 können auch eine MP_DSS-Option umfassen.
  • Zu beachten ist, dass sogar nachdem eine TCP-Handshake-Prozedur erfolgreich mit MPTCP-Optionen ausgehandelt wurde, es immer noch möglich sein kann, dass eine Mittelbox die MP_DSS-Option auf Daten- oder Bestätigungspakete fallen lässt. Wenn dies auftritt, kann die Verbindung auf eine Standard-TCP-Verbindung zurückfallen.
  • Auch aus diesem Grund kann der Client 702 warten, bis eine Bestätigung für zumindest ein Datenpaket mit einer MP_DSS-Option, welche selbst eine MP_DSS-Option hat, wie beispielsweise die Ack-Nachricht 714, empfangen wird, bevor er versucht, einen zweiten MPTCP-Subflow aufzubauen.
  • Wenn eine TCP-Handshake-Prozedur erfolgreich mit MPTCP-Optionen ausgehandelt wird, und zumindest eine erfolgreiche Lese- oder Schreib-Operation (d. h. zumindest ein Datenpaket und Ack werden erfolgreich übertragen) mit MPTCP-Optionen intakt ausgeführt wird, und der Client 702 eine zellulare Datenverbindung hat, welche zusätzlich zu der Wi-Fi-Datenverbindung verfügbar ist, kann der Client 702 eine Syn-Nachricht 718 an den Server 704 mittels seiner zellularen Netzwerkschnittstelle übertragen, um eine Handshake-Prozedur zu initiieren zum Versuchen, einen anderen Subflow der MPTCP-Verbindung aufzubauen. Als ein zusätzlicher Subflow einer existierenden MPTCP-Verbindung, kann die Syn-Nachricht 718 eine MP_Join-Option umfassen. Zusätzlich, da die zellulare Netzwerkschnittstelle nicht eine bevorzugte Netzwerkschnittstelle in Bezug auf die Wi-Fi-Netzwerkschnittstelle sein kann, kann die Syn-Nachricht 718 ein „Backup”-Flag umfassen, welches anzeigt, dass der zellulare Subflow ein Backup wäre.
  • Ähnlich dem Subflow-Aufbau-Nachrichtenfluss zum Aufbauen des Wi-Fi-Subflows kann der Server 704 durch Übertragen einer Syn_Ack-Nachricht 720, welche auch eine MP_Join-Option umfassen kann, an den Client 702 antworten. Der Client 702 kann dann mit einer Ack-Nachricht 722 folgen, welche auch eine MP_Join-Option umfassen kann.
  • Mit erfolgreich aufgebauten MPTCP-Subflows zwischen dem Client 702 und dem Server 704 über sowohl Wi-Fi- als auch zellulare Datenverbindungen, können an diesem Punkt die Datenpakete über eine von beiden oder beide MPTCP-Subflows übertragen werden.
  • Wie vorher genannt, kann solch ein Szenario, wie in Bezug auf 7 gezeigt und beschrieben, in welchem ein Client sowohl Wi-Fi- als auch zellulare Netzwerkschnittstellen umfasst, von welchen beide, eine oder keine zu einer gegebenen Zeit verfügbar sein kann, für viele mobile Vorrichtungen üblich sein. Wi-Fi- und zellulare Netzwerkschnittstellen können verschiedene Charakteristika haben, welche Benutzer solcher Vorrichtungen leiten können, Benutzungspräferenzen in Bezug auf diese Netzwerkschnittstellen zu haben. Zum Beispiel können viele zellulare Netzwerke auf einer Pro-Daten-Verwendungsbasis Gebühren erheben (d. h. können gebührenpflichtige (metered) Datennutzung bereitstellen, z. B. anstelle von oder zusätzlich zu einer monatlichen Teilnahmegebühr), wohingegen viele Wi-Fi-Netzwerkanbieter keine Gebühren auf einer Pro-Daten-Nutzungsbasis erheben können, sondern vielmehr unbegrenzte Datennutzung bereitstellen (z. B. für eine monatliche Teilnahmegebühr). Während es erkannt werden wird, dass solche Charakteristika nicht allgemeine Merkmale von zellularen und Wi-Fi-Netzwerken sind, weil solche Charakteristika in vielen Fällen üblich sein können, können viele mobile Anwendungen bevorzugen, zellulare Netzwerke primär oder exklusiv als einen Backup-Kommunikationspfad zu verwenden, während Wi-Fi, wenn verfügbar, ein bevorzugter Kommunikationspfad sein kann.
  • Feste Endpunkte können nicht die gleichen Prioritäten aufweisen. Zum Beispiel kann ein fester Endpunkt mit zumindest einer verdrahteten Netzwerkschnittstelle keine signifikante Variation bei der Verfügbarkeit seiner Netzwerkschnittstelle(n) haben, aufgrund sowohl der im Wesentlichen stationären Natur des festen Endpunkts als auch dem höheren Grad von Zuverlässigkeit/Verfügbarkeit, welche typischerweise durch eine verdrahtete Netzwerkschnittstelle in Bezug auf drahtlose Netzwerkschnittstellen bereitgestellt wird. Des Weiteren unabhängig von der festen gegen die mobile Natur eines entfernten Endpunkts einer MPTCP-Verbindung, kann ein lokaler Endpunkt nicht von Unterschieden bei Verwendungspräferenzen des entfernten Endpunkts zwischen unterschiedlichen Subflows wissen. Dementsprechend, zumindest in einigen Fällen, wenn eine MPTCP-Verbindung zwischen einem mobilen Endpunkt und einem festen Endpunkt hergestellt wird, kann es vorzuziehen sein, dem mobilen Endpunkt zu ermöglichen zu diktieren, welche seiner Netzwerkschnittstellen (und somit welcher MPTCP-Subflow) als der aktive Pfad und welcher als der Backup-Pfad zu verwenden ist. Entsprechend kann es für einen festen Endpunkt nicht wünschenswert sein, die Beschränkungen einer MPTCP-Verbindung mit einem mobilen Endpunkt zu diktieren.
  • Es ist auch wert anzumerken, dass allgemeiner unabhängig davon, ob fest oder mobil, ein lokaler Endpunkt nicht von irgendwelchen Unterschieden bei Benutzungspräferenzen eines entfernten Endpunkts zwischen unterschiedlichen Subflows wissen kann. Somit, wenn beide Endpunkte einer MPTCP-Verbindung mobil sind, kann jede Seite Benutzungspräferenzen haben, welche der anderen unbekannt sind. Zum Beispiel kann ein Endpunkt wissen, welche Subflows seine zellulare Netzwerkschnittstelle benutzen und welche Subflows seine Wi-Fi-Netzwerkschnittstelle benutzen, aber kann nicht wissen, welche Subflows welchen Netzwerkschnittstellen des anderen Endpunkts entsprechen und umgekehrt.
  • Es ist klar, dass die oben beschriebenen Beispiele in Bezug auf Fest- und Mobil-Endpunkt-Netzwerkschnittstellen-Charakteristika und Benutzungspräferenzen als Erklärung bereitgestellt werden und nicht als die Offenbarung beschränkend betrachtet werden sollten. Irgendeine Anzahl von zusätzlichen oder alternativen Benutzungspräferenzprofilen, Netzwerkschnittstellenkombinationen und/oder Variationen bei festen und mobilen Endpunktkombinationen sind auch möglich. Jedoch sind diese Beispiele allgemeiner beispielhaft für die potentiellen Vorteile des Einführens zusätzlicher Elemente von Verbindungssteuerung und Konfiguration auf MPTCP-Verbindungen.
  • Zum Beispiel kann es wünschenswert sein, einen Weg für einen oder beide Endpunkte bereitzustellen, Steuerung über eine MPTCP-Verbindung auszuüben. In solch einem Fall kann ein steuernder Endpunkt in der Lage sein, neue Subflows zu erzeugen, Priorität (z. B. aktiv/primär gegen Backup/sekundär) von Subflows zu diktieren, und Datenübertragungsfluss entlang primärer und Backup-Subflows zu steuern zum Ermöglichen schnellerer Übergänge zu einem funktionalen Subflow von einem nicht-funktionalen Subflow. Im Gegensatz dazu kann ein nicht-steuernder Endpunkt nicht (z. B. kann gehindert werden an oder nicht die Erlaubnis haben zu) neue Subflows initiieren oder Subflow-Prioritäten modifizieren und kann der Leitung des steuernden Endpunkts in Bezug auf Datenübertragungsfluss entlang primärer und Backup-Subflows folgen. Zum Beispiel kann ein nicht-steuernder Endpunkt überwachen/bestimmen, auf welchem MPTCP-Subflow Daten zuletzt empfangen worden sind und kann Daten über den MPTCP-Subflow übertragen, auf welchem Daten zuletzt empfangen worden sind.
  • Somit könnte in einem beispielhaften Szenario, in welchem ein Client (wie beispielsweise Client 702) ein mobiler Client ist, welcher eine Wi-Fi- und eine zellulare Netzwerkschnittstelle aufweist, während ein Server (wie Server 704) ein fester Server ist, welcher eine verdrahtete Netzwerkschnittstelle aufweist, der Client Steuerung über die MPTCP-Verbindung ausüben, während der Server nicht Steuerung über die MPTCP-Verbindung ausüben könnte. Der Client könnte in diesem Fall diktieren, dass der Wi-Fi-Subflow primär wäre und der Server könnte diese Priorität nicht modifizieren. Des Weiteren könnte der Client in diesem Fall wählen, einen zellularen Subflow aufzubauen oder nicht, während der Server nicht versuchen würde, einen Subflow auf der zellularen Netzwerkschnittstelle des Clients zu initiieren. Zusätzlich, wenn die Wi-Fi-Netzwerkschnittstelle fehlschlagen würde und der Client übergehen würde zum Übertragen von Daten auf dem (z. B. Backup) zellularen Schnittstellen-Subflow, würde der Server der Leitung des Clients folgen und auch Daten auf dem zellularen Schnittstellen-Subflow übertragen, selbst wenn der Server keine Anzeige empfangen hat, die Priorität dieses Subflows zu erhöhen (z. B. aufgrund von Unzuverlässigkeit einer Prioritätsmodifikationsoption).
  • Es kann auch möglich sein, einen Weg für mehrere Endpunkte bereitzustellen, Steuerung über eine MPTCP-Verbindung auszuüben. Dies kann z. B. wünschenswert sein in dem oben beschriebenen beispielhaften Szenario, in welchem beide Endpunkte mobil sind und ihre eigenen einzigartigen Benutzungspräferenzen bezüglich der Netzwerkschnittstellen und entsprechenden Subflows haben. In solch einem Fall kann jede Seite in der Lage sein, irgendeine vorherige Signalisierung der Pfadpriorität zu überschreiben und die Pfadpriorität herabzustufen/heraufzustufen. Somit, z. B. wenn ein Subflow von der Wi-Fi-Netzwerkschnittstelle eines Endpunkts zu der zellularen Netzwerkschnittstelle des anderen Endpunkts aufgebaut wird, kann der empfangende Endpunkt es bevorzugen, die Priorität des Subflows auf Backup herabzustufen, wenn ein anderer Subflow über seine Wi-Fi-Netzwerkschnittstelle verfügbar ist.
  • Allgemeiner gesagt, wenn beide Endpunkte Steuerung über eine MPTCP-Verbindung ausüben, können beide Endpunkte in der Lage sein, aktiv über Subflow-Aufbau und Pfadprioritäten abzustimmen. Zum Beispiel können beide Endpunkte in der Lage sein, Subflows zu initiieren. Beide Endpunkte können auch oder alternativ in der Lage sein, Subflows von primärer zu Backup-Priorität herabzustufen und Subflow-Priorität von Backup zu primär heraufzustufen (z. B. wenn kein anderer Pfad verfügbar ist). Zusätzlich können beide Endpunkte versuchen, der Leitung des anderen Endpunkts in Bezug darauf zu folgen, über welchen Subflow Daten zuletzt angekommen sind. Mit anderen Worten kann jeder Endpunkt überwachen/bestimmen, auf welchem MPTCP-Subflow Daten zuletzt empfangen worden sind, und kann Daten über den MPTCP-Subflow übertragen, auf welchem Daten zuletzt empfangen worden sind, wann immer möglich.
  • Eine weitere Betrachtung in Bezug auf Subflow-Initiierung kann sein, dass viele mobile Vorrichtungen hinter Netzwerkadressenübersetzern (network adress translators, NATs) liegen können. In solch einem Fall kann ein mobiler Endpunkt nicht in der Lage sein, direkt eine lokale Adresse für einen entfernten Endpunkt, mit dem zu verbinden ist, bekanntzugeben unter Verwendung der ADD_ADDR-Option des MPTCP. Selbst wenn die Endpunkte einen Mechanismus außer der Reihe zur Adressentdeckung und NAT-Hole-Punching verwenden, kann es kontraproduktiv für Subflow-Erzeugung sein, lediglich durch die ADD_ADDR-Option diktiert zu werden, weil der End-Host, welcher die ADD_ADDR-Option empfängt und die Verbindung initiiert, keine Kenntnis von den Kostencharakteristika der Netzwerkschnittstellen des entfernten Endpunkts haben kann (z. B. drahtlose Netzwerke).
  • Entsprechend kann es vorzuziehen sein, im Allgemeinen für mobile Endpunkte Initiatoren von Subflows zu sein, und es kann vorzuziehen sein, im Allgemeinen für feste Endpunkte nicht die Initiatoren von Subflows mit mobilen Endpunkten zu sein, weil sie nicht davon wissen können, mit welchem Typ von Netzwerkschnittstelle (z. B. Wi-Fi oder zellular) der mobile Endpunkt verbunden ist, selbst wenn sie Mechanismen außer der Reihe zum Entdecken der übersetzten/öffentlichen Transportadressen der mobilen Endpunkte haben. In einem Szenario, in welchem ein fester Endpunkt wünscht, einen mobilen Endpunkt über eine zusätzliche Adresse zu informieren, bei welcher ein MPTCP-Subflow initiiert werden kann, dann kann der feste Endpunkt eine ADD_ADDR-Option an den mobilen Endpunkt für die mobilen Vorrichtungen, mit welchen zu verbinden ist, senden.
  • Steuerung einer MPTCP-Verbindung kann auf irgendeinem einer Vielzahl von Wegen ausgeübt werden. Als eine Möglichkeit kann die Zuweisung von Steuerung erreicht werden durch (z. B. fest verdrahtete) Konfiguration der Endpunkte. Somit kann ein Endpunkt eingerichtet sein, ein Master/Controller von MPTCP-Verbindungen (z. B. im Falle eines mobilen Endpunkts) für alle MPTCP-Verbindungen, welche diesen Endpunkt umfassen, zu sein, oder ein Slave/Nicht-Controller von MPTCP-Verbindungen (z. B. im Falle eines festen Endpunkts) für alle MPTCP-Verbindungen zu sein (z. B. für welche der entfernte Endpunkt eingerichtet ist, als ein Master in Bezug auf die MPTCP-Verbindung zu agieren). Wie vorher genannt, sind auch hybride feste/mobile Endpunkte möglich; in solch einem Fall kann die Konfiguration verwendet werden, solch eine Vorrichtung als entweder einen mobilen Endpunkt oder einen festen Endpunkt zu behandeln.
  • Als eine andere Möglichkeit kann das MPTCP-Drahtprotokoll verwendet werden, um dynamisch Leitung zuzuweisen/anzunehmen. Zum Beispiel kann ein Subflow-Initiator einen MPTCP-Subflow mit einer Syn-Nachricht, welche eine MP_Capable-Option aufweist, initiieren, wie beispielsweise Syn-Nachricht 706, welche in 7 gezeigt ist. Während es klar sein sollte, dass alternative Formate auch möglich sind, ist ein mögliches beispielhaftes Format für die MP_Capable-Option in 8 gezeigt.
  • Das „Versions”-Feld, welches wie gezeigt illustriert ist, kann in diesem Fall auf i gesetzt werden. In Version 1 kann das Flag 'C' verwendet werden, Leitung zu deklarieren/Masterstatus der MPTCP-Verbindung auszuüben. In diesem Fall würde 'C' auf 1 gesetzt werden.
  • Ein MPTCP-fähiger Empfänger solch einer MP_Capable-Option kann mit einem Syn_Ack antworten, welcher auch eine MP_Capable-Option umfasst, wie beispielsweise Syn_Ack-Nachricht 708, welche in 7 gezeigt ist. Während es wieder klar sein sollte, dass alternative Formate auch möglich sind, kann als eine Möglichkeit diese Antwort-MP_Capable-Option das beispielhafte Format haben, welches in 9 gezeigt ist.
  • Wenn der Empfänger der MP_Capable-Option ein fester Endpunkt ist (oder ansonsten nicht wünscht, Steuerung über die MPTCP-Verbindung auszuüben), kann dieser Endpunkt stoppen, Subflows zu initiieren. Dieser Endpunkt kann auch nicht länger Pfadprioritäten setzen und kann der Leitung des steuernden Endpunkts folgen, wenn er von einem Subflow zu einem anderen übergeht. Solch ein Endpunkt kann seine Nicht-Leitung ausüben/Slave-Status der MPTCP-Verbindung signalisieren durch Nichtsetzen des 'C'-Flags (d. h. Setzen des 'C'-Flags auf o) in seiner MP_Capable-Antwort, wenn er Version 1 unterstützt, und durch Setzen des Versionsfelds auf 1.
  • Wenn der Empfänger der MP_Capable-Option ein mobiler Endpunkt ist (oder ansonsten wünscht, Steuerung über die MPTCP-Verbindung auszuüben), kann dieser Endpunkt verstehen, dass der entfernte Endpunkt auch wünscht, Steuerung über die Verbindung auszuüben (z. B. weil der entfernte Endpunkt auch mobil sein kann), und kann kollaborativ erlauben, dass Pfadprioritäten heraufgestuft oder herabgestuft werden. In ähnlicher Weise können beide Endpunkte der Leitung des anderen bei Datenübertragung folgen, wenn von einem Subflow-Pfad zu einem anderen Subflow-Pfad gewechselt wird. Solch ein Endpunkt kann seine Leitungs ausüben/Master-Status der MPTCP-Verbindung signalisieren durch Setzen des 'C'-Flags (d. h. Setzen des 'C'-Flags auf 1) in seiner MP_Capable-Antwort, wenn er Version 1 unterstützt, und durch Setzen des Versionsfelds auf 1.
  • Ausführungsformen der vorliegenden Offenbarung können auf irgendwelche verschiedenen Formen realisiert werden. Zum Beispiel können einige Ausführungsformen realisiert werden als ein computerimplementiertes Verfahren, ein computerlesbares Speichermedium oder ein Computersystem. Andere Ausführungsformen können realisiert werden unter Verwendung einer oder mehrerer kundenspezifischer (custom-designed) Hardwarevorrichtungen, wie beispielsweise ASICs. Noch andere Ausführungsformen können realisiert werden unter Verwendung einer oder mehrerer programmierbarer Hardwareelemente, wie beispielsweise FPGAs.
  • In einigen Ausführungsformen kann ein nicht-flüchtiges computerlesbares Speichermedium so eingerichtet sein, dass es Programminstruktionen und/oder Daten speichert, wobei die Programminstruktionen, wenn sie durch ein Computersystem ausgeführt werden, das Computersystem veranlassen, ein Verfahren auszuführen, z. B. irgendeine der Verfahrensausführungsformen, welche hierin beschrieben sind, oder irgendeine Kombination der Verfahrensausführungsformen, welche hierin beschrieben sind, oder irgendeine Untermenge irgendeiner der Verfahrensausführungsformen, welche hierin beschrieben sind, oder irgendeine Kombination solcher Untermengen.
  • In einigen Ausführungsformen kann eine Vorrichtung (z. B. eine UE) eingerichtet sein, einen Prozessor (oder einen Satz von Prozessoren) und ein Speichermedium zu umfassen, wobei das Speichermedium Programminstruktionen speichert, wobei der Prozessor eingerichtet ist zum Lesen und Ausführen der Programminstruktionen von dem Speichermedium, wobei die Programminstruktionen ausführbar sind zum Implementieren irgendeines der verschiedenen Verfahrensausführungsformen, welche hierin beschrieben sind (oder irgendeine Kombination der Verfahrensausführungsformen, welche hierin beschrieben sind, oder irgendeiner Untermenge irgendeiner der Verfahrensausführungsformen, welche hierin beschrieben sind, oder irgendeine Kombination solcher Untermengen). Die Vorrichtung kann in irgendeiner der verschiedenen Formen realisiert sein.
  • Obwohl die obigen Ausführungsformen in umfangreichem Detail beschrieben worden sind, werden dem Fachmann zahlreiche Variationen und Modifikationen klar sein, sobald die obige Offenbarung vollständig gewürdigt ist. Es ist beabsichtigt, dass die folgenden Ansprüche interpretiert werden, um alle solche Variationen und Modifikationen zu erfassen.
  • Bezugszeichenliste
  • 102
    Endpunkt
    104
    Endpunkt
    106
    Pfad
    108
    Pfad
    200
    WAN
    202
    Wi-Fi-Zugangspunkt
    204
    Zellulare Basisstation
    206
    UE
    208
    Kernnetzwerk
    210
    Server
    400
    SOC
    402
    Prozessor(en)
    404
    Anzeigeschaltung
    406
    Speicher
    410
    NAND
    420
    Dock I/F
    430
    Funkeinheit
    435
    Antenne
    440
    MMU
    450
    ROM
    460
    Anzeige
    500
    UE
    502
    Netzwerkanwendung
    504
    Netzwerk-Framework
    506
    TCP-Verbindungsbibliothek
    508
    Netzwerkschnittstellen Statusentität
    510
    BSD Socket
    512
    MPTCP Socket
    514
    TCP
    518
    Server
    516
    Mittelbox
    602
    Starten der MPTCP-Sitzung
    604
    Wi-Fi vorhanden?
    606
    Zelle vorhanden?
    608
    Internet nicht verfügbar
    610
    Starten des ersten Subflows
    612
    MPTCP?
    614
    Lesen/Schreiben
    616
    TCP Zurückfallen?
    618
    Lesen/Schreiben
    620
    Sitzungsende
    622
    Zellulares Zurückfallen?
    624
    Internet nicht verfügbar
    626
    MPTCP erfolgreich?
    628
    TCP Zurückfallen?
    630
    Lesen/Schreiben
    632
    Abbruch
    634
    Alternatives Netzwerk?
    636
    Starten eines anderen Subflows
    638
    Erfolgreich?
    640
    Lesen/Schreiben auf mehrere Subflows
    642
    Subflow-Trennung und IP-Adressenverlust Ende-TCP Neuübertragungsversuche
    644
    Alternativer Pfad vorhanden?
    646
    Failover zu anderem Subflow
    648
    Abbruch
    702
    Client
    704
    Server
    706
    Syn + MP_Capable
    708
    Syn_Ack + MP_Capable
    710
    Ack + Keys
    712
    Data + MP_DSS option
    714
    Ack + MP_DSS_Ack option
    716
    Data + MP_DSS option
    718
    Syn + MP_Join + Backup
    720
    Syn_Ack + MP_Join
    722
    Ack + MP_Join
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Nicht-Patentliteratur
    • IEEE 802.11 [0002]
    • IEEE 802.16 [0002]
    • IEEE 802.11 [0033]

Claims (15)

  1. Drahtlose Benutzerausrüstungs(UE)-Vorrichtung, aufweisend: eine Wi-Fi-Netzwerkschnittstelle; eine zellulare Netzwerkschnittstelle; ein Verarbeitungselement, welches betriebsfähig gekoppelt ist mit der Wi-Fi-Netzwerkschnittstelle und der zellularen Netzwerkschnittstelle; wobei die UE eingerichtet ist zum: Versuchen, einen Mehrpfad-Übertragungssteuerungsprotokoll(MPTCP)-Subflow mit einem entfernten Endpunkt vorzugsweise über die Wi-Fi-Netzwerkschnittstelle aufzubauen; Versuchen, eine Nicht-Mehrpfad-TCP-Verbindung mit dem entfernten Endpunkt über die Wi-Fi-Netzwerkschnittstelle aufzubauen, wenn das Versuchen, den MPTCP-Subflow mit dem entfernten Endpunkt über die Wi-Fi-Netzwerkschnittstelle aufzubauen, nicht erfolgreich ist; Versuchen, einen MPTCP-Subflow mit dem entfernten Endpunkt über die zellulare Netzwerkschnittstelle aufzubauen, wenn das Versuchen, die Nicht-Mehrpfad-TCP-Verbindung mit dem entfernten Endpunkt über die Wi-Fi-Netzwerkschnittstelle aufzubauen, nicht erfolgreich ist; und Versuchen, eine Nicht-Mehrpfad-TCP-Verbindung mit dem entfernten Endpunkt über die zellulare Netzwerkschnittstelle aufzubauen, wenn das Versuchen, die MPTCP-Verbindung mit dem entfernten Endpunkt über die zellulare Netzwerkschnittstelle aufzubauen, nicht erfolgreich ist.
  2. UE nach Anspruch 1, wobei die UE weiter eingerichtet ist zum: Versuchen, einen zusätzlichen MPTCP-Subflow mit dem entfernten Endpunkt über die zellulare Netzwerkschnittstelle aufzubauen, wenn das Versuchen, einen MPTCP-Subflow mit einem entfernten Endpunkt über die Wi-Fi-Netzwerkschnittstelle aufzubauen, erfolgreich ist.
  3. UE nach Anspruch 1, wobei zum Versuchen, einen MPTCP-Subflow aufzubauen, die UE eingerichtet ist zum Versuchen, eine Drei-Phasen-Handshake-Prozedur mit dem entfernten Endpunkt auszuführen, wobei jede Nachricht, welche in der Drei-Phasen-Handshake-Prozedur übertragen wird, eine Mehrpfad-TCP-Header-Option aufweist, wobei die UE weiter eingerichtet ist zum: Bestimmen, dass jede Nachricht in der Drei-Phasen-Handshake-Prozedur mit dem entfernten Endpunkt mit ihrer jeweiligen Mehrpfad-TCP-Header-Option erfolgreich empfangen wird; Versuchen, MPTCP-Daten über den MPTCP-Subflow zu übertragen oder zu empfangen, basierend auf Bestimmen, dass jede Nachricht in der Drei-Phasen-Handshake-Prozedur mit dem entfernten Endpunkt mit ihrer jeweiligen Mehrpfad-TCP-Header-Option erfolgreich empfangen wird; Bestimmen, dass die MPTCP-Daten ohne eine Mehrpfad-TCP-Header-Option empfangen werden; Zurückfallen auf Nicht-Mehrpfad-TCP-Kommunikation mit dem entfernten Endpunkt basierend auf Bestimmen, dass die MPTCP-Daten ohne die Mehrpfad-TCP-Header-Option empfangen werden.
  4. UE nach Anspruch 1, wobei zum Versuchen, einen MPTCP-Subflow aufzubauen, die UE eingerichtet ist zum Versuchen, eine Drei-Phasen-Handshake-Prozedur mit dem entfernten Endpunkt auszuführen, wobei jede Nachricht, welche in der Drei-Phasen-Handshake-Prozedur übertragen wird, eine Mehrpfad-TCP-Header-Option aufweist, wobei die UE weiter eingerichtet ist zum: Bestimmen, dass zumindest eine Nachricht in der Drei-Phasen-Handshake-Prozedur nicht empfangen wird; Ausführen eines oder mehrerer zusätzlicher Versuche, einen MPTCP-Subflow mit dem entfernten Endpunkt aufzubauen; Versuchen, eine Nicht-Mehrpfad-TCP-Verbindung mit dem entfernten Endpunkt aufzubauen, wenn der eine oder die mehreren zusätzlichen Versuche, einen MPTCP-Subflow mit dem entfernten Endpunkt aufzubauen, nicht erfolgreich sind.
  5. UE nach Anspruch 1, wobei die UE eingerichtet ist zum Überwachen des Netzwerkschnittstellenstatus jeder der Wi-Fi-Netzwerkschnittstelle und der zellularen Netzwerkschnittstelle, wobei die UE eingerichtet ist, vorzugsweise Datenkommunikation über die Wi-Fi-Netzwerkschnittstelle im Verhältnis zu der zellularen Netzwerkschnittstelle auszuführen, wenn sowohl die Wi-Fi-Netzwerkschnittstelle als auch die zellulare Netzwerkschnittstelle verfügbar sind.
  6. Verfahren für eine drahtlose Vorrichtung zum Aufbauen einer Mehrpfad-TCP-(MPTCP-)Verbindung mit einem entfernten Endpunkt, wobei die drahtlose Vorrichtung sowohl eine Wi-Fi-Netzwerkschnittstelle als auch eine zellulare Netzwerkschnittstelle aufweist, wobei das Verfahren aufweist: Empfangen von Information, welche den Verfügbarkeitsstatus jeder der Wi-Fi-Netzwerkschnittstelle und der zellularen Netzwerkschnittstelle anzeigt; und Versuchen, einen MPTCP-Subflow mit einem entfernten Endpunkt aufzubauen, wobei Versuchen, den MPTCP-Subflow mit dem entfernten Endpunkt aufzubauen, vorzugsweise über die Wi-Fi-Netzwerkschnittstelle ausgeführt wird, wenn die Wi-Fi-Netzwerkschnittstelle verfügbar ist.
  7. Verfahren nach Anspruch 6, wobei, wenn das Versuchen, einen MPTCP-Subflow mit einem entfernten Endpunkt über die Wi-Fi-Netzwerkschnittstelle aufzubauen, nicht erfolgreich ist, der Versuch des Aufbauens des MPTCP-Subflows über die Wi-Fi-Netzwerkschnittstelle zurückfällt auf einen Versuch, eine Standard-TCP-Verbindung mit dem entfernten Endpunkt über die Wi-Fi-Netzwerkschnittstelle aufzubauen.
  8. Verfahren nach Anspruch 7, wobei, wenn der Versuch, eine Standard-TCP-Verbindung mit dem entfernten Endpunkt über die Wi-Fi-Netzwerkschnittstelle aufzubauen, nicht erfolgreich ist, und die zellulare Netzwerkschnittstelle verfügbar ist, das Verfahren weiter aufweist: Versuchen, einen MPTCP-Subflow mit dem entfernten Endpunkt über die zellulare Netzwerkschnittstelle aufzubauen.
  9. Verfahren nach Anspruch 8, wobei, wenn das Versuchen, einen MPTCP-Subflow mit dem entfernten Endpunkt über die zellulare Netzwerkschnittstelle aufzubauen, nicht erfolgreich ist, der Versuch des Aufbauens des MPTCP-Subflows über die zellulare Netzwerkschnittstelle zurückfällt auf einen Versuch, eine Standard-TCP-Verbindung mit dem entfernten Endpunkt über die zellulare Netzwerkschnittstelle aufzubauen.
  10. Verfahren nach Anspruch 6, wobei das Versuchen, den MPTCP-Subflow mit dem entfernten Endpunkt aufzubauen, über die zellulare Schnittstelle ausgeführt wird, wenn der Aufbau einer TCP-Verbindung über die Wi-Fi-Netzwerkschnittstelle misslingt.
  11. Verfahren nach Anspruch 6, wobei das Verfahren weiter aufweist: Bestimmen, dass ein erster MPTCP-Subflow mit dem entfernten Endpunkt erfolgreich über die Wi-Fi-Netzwerkschnittstelle aufgebaut wird; Bestimmen, dass die zellulare Netzwerkschnittstelle verfügbar ist; und Versuchen, einen zweiten MPTCP-Subflow mit dem entfernten Endpunkt über die zellulare Netzwerkschnittstelle aufzubauen basierend auf dem Bestimmen, dass der erste MPTCP-Subflow mit dem entfernten Endpunkt erfolgreich über die Wi-Fi-Netzwerkschnittstelle aufgebaut wird, und dem Bestimmen, dass die zellulare Netzwerkschnittstelle verfügbar ist.
  12. Verfahren nach Anspruch 6, wobei das Verfahren implementiert wird durch eine Transportverbindungsverwaltungsschicht, welche in der drahtlosen Vorrichtung ausgeführt wird, wobei die Transportverbindungsverwaltungsschicht eingerichtet ist zum Bestimmen von Netzwerkschnittstellen-Benutzungspräferenzen basierend auf ein oder mehreren von: Netzwerkschnittstellen-Verfügbarkeitsinformation; Netzwerkschnittstellen-Verbindungsqualitätscharakteristika; oder Netzwerkschnittstellen-Benutzungskostencharakteristika.
  13. Nicht-flüchtiges computerzugreifbares Speichermedium, welches Programminstruktionen aufweist, welche, wenn sie an einem Verarbeitungselement einer Vorrichtung ausgeführt werden, die Vorrichtung veranlassen, ein Verfahren zu implementieren, aufweisend: Empfangen einer Anzeige, eine TCP-Sitzung mit einem entfernten Endpunkt zu initiieren; Bestimmen, ob eine erste Netzwerkschnittstelle der Vorrichtung derzeitig verfügbar ist oder nicht; Bestimmen, ob eine zweite Netzwerkschnittstelle der Vorrichtung derzeitig verfügbar ist oder nicht; Versuchen, einen MPTCP-Subflow mit dem entfernten Endpunkt über die erste Netzwerkschnittstelle aufzubauen, wenn bestimmt wird, dass die erste Netzwerkschnittstelle der Vorrichtung derzeitig verfügbar ist; und Versuchen, einen MPTCP-Subflow mit dem entfernten Endpunkt über die zweite Netzwerkschnittstelle aufzubauen, wenn bestimmt wird, dass die erste Netzwerkschnittstelle derzeitig nicht verfügbar ist und die zweite Netzwerkschnittstelle derzeitig verfügbar ist, oder wenn der erste MPTCP-Subflow erfolgreich aufgebaut wird und die zweite Netzwerkschnittstelle auch verfügbar ist.
  14. Speichermedium nach Anspruch 13, wobei das Verfahren weiter aufweist: Versuchen, eine Einzelpfad-TCP-Verbindung mit dem entfernten Endpunkt über die erste Netzwerkschnittstelle aufzubauen, wenn die erste Netzwerkschnittstelle der Vorrichtung derzeitig verfügbar ist, aber der Versuch, den MPTCP-Subflow mit dem entfernten Endpunkt über die erste Netzwerkschnittstelle aufzubauen, nicht erfolgreich ist, wobei, wenn die Einzelpfad-TCP-Verbindung mit dem entfernten Endpunkt über die erste Netzwerkschnittstelle erfolgreich aufgebaut wird, kein Versuch gemacht wird, einen MPTCP-Subflow mit dem entfernten Endpunkt über die zweite Netzwerkschnittstelle aufzubauen. wobei, wenn die Einzelpfad-TCP-Verbindung mit dem entfernten Endpunkt über die erste Netzwerkschnittstelle nicht erfolgreich aufgebaut wird und bestimmt wird, dass die zweite Netzwerkschnittstelle der UE derzeitig verfügbar ist, das Verfahren auch Versuchen, einen MPTCP-Subflow mit dem entfernten Endpunkt über die zweite Netzwerkschnittstelle aufzubauen, aufweist.
  15. Speichermedium nach Anspruch 13, wobei die erste Netzwerkschnittstelle eine Wi-Fi-Netzwerkschnittstelle ist, wobei die zweite Netzwerkschnittstelle eine zellulare Netzwerkschnittstelle ist.
DE102014208162.9A 2013-06-06 2014-04-30 Mehrweg-tcp-subflow-aufbau und -steuerung Active DE102014208162B4 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/911,759 US9456464B2 (en) 2013-06-06 2013-06-06 Multipath TCP subflow establishment and control
US13/911,759 2013-06-06

Publications (2)

Publication Number Publication Date
DE102014208162A1 true DE102014208162A1 (de) 2014-12-11
DE102014208162B4 DE102014208162B4 (de) 2023-12-14

Family

ID=52005400

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102014208162.9A Active DE102014208162B4 (de) 2013-06-06 2014-04-30 Mehrweg-tcp-subflow-aufbau und -steuerung

Country Status (3)

Country Link
US (4) US9456464B2 (de)
CN (2) CN108418751B (de)
DE (1) DE102014208162B4 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102015208666B4 (de) 2014-05-30 2018-07-05 Apple Inc. Langlebige MPTCP-Sitzungen

Families Citing this family (64)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10721269B1 (en) 2009-11-06 2020-07-21 F5 Networks, Inc. Methods and system for returning requests with javascript for clients before passing a request to a server
US10075987B2 (en) * 2013-12-18 2018-09-11 Telefonaktiebolaget Lm Ericsson (Publ) Multipath TCP subflow establishing on single IP connection
MX358438B (es) * 2014-01-24 2018-08-21 Ericsson Telefon Ab L M Métodos, nodos de red, sistemas, y productos de programas de cómputo para controlar el uso de tcp de trayectoria múltiple.
KR102143620B1 (ko) * 2014-02-17 2020-08-11 삼성전자주식회사 전자 장치에서 다중 인터페이스를 이용한 응용 계층의 요청 처리 장치 및 방법
US20150281367A1 (en) * 2014-03-26 2015-10-01 Akamai Technologies, Inc. Multipath tcp techniques for distributed computing systems
FR3019421A1 (fr) * 2014-03-31 2015-10-02 Orange Procede de communication par chemins multiples entre deux terminaux
US9843522B2 (en) * 2014-04-09 2017-12-12 Hcl Technologies Ltd. Efficient mechanism to improve data speed between systems by MPTCP and MIMO combination
FR3023106A1 (fr) * 2014-06-30 2016-01-01 Orange Procede de communication tcp via des chemins multiples entre deux terminaux
JP6573658B2 (ja) 2014-07-21 2019-09-11 華為技術有限公司Huawei Technologies Co.,Ltd. リンク制御ノードおよびリンク制御方法、および通信システム
FR3024004A1 (fr) * 2014-07-21 2016-01-22 Orange Procede de communication tcp via des chemins multiples entre deux terminaux
US10148764B2 (en) * 2014-09-30 2018-12-04 Google Llc Backup wide area network connection for access points and routers
US10306025B2 (en) * 2014-10-27 2019-05-28 Nec Corporation Method of managing an MPTCP connection and network device
US10212753B2 (en) * 2014-10-30 2019-02-19 Telefonaktiebolaget Lm Ericsson (Publ) Handling of backup paths in radio access networks
US9681481B2 (en) * 2014-12-19 2017-06-13 At&T Intellectual Property I, L.P. Mobility management of wireless networks based on multipath transfer control protocol
US9742659B2 (en) * 2015-01-28 2017-08-22 Dell Products Lp Multipath bandwidth usage
US9871723B2 (en) * 2015-02-09 2018-01-16 Telefonaktiebolaget Lm Ericsson (Publ) Method and device for handling multi path connections
MY194317A (en) * 2015-02-13 2022-11-28 Ericsson Telefon Ab L M Multi-path transmission control protocol connections
US10397379B2 (en) * 2015-03-06 2019-08-27 Apple Inc. Robust multipath TCP stateless connection establishment
JP6631017B2 (ja) * 2015-03-06 2020-01-15 富士通株式会社 端末装置、端末装置の接続方法、端末装置の接続プログラム
CN104702527B (zh) * 2015-03-24 2018-06-19 大连理工大学 多路径tcp中面向多优先级连接的拥塞时间窗控制方法
US10673991B2 (en) * 2015-04-10 2020-06-02 Deutsche Telekom Ag Method and system for the scheduling of packets in a bundling scenario based on TCP tunnels and native TCP information
CN107113285B (zh) * 2015-04-24 2020-09-22 海南乐事科技发展有限公司 Mptcp子流的建立方法及设备
CN107078999B (zh) * 2015-05-05 2020-01-03 华为技术有限公司 传输数据的方法和装置
US10362508B2 (en) * 2015-06-05 2019-07-23 Apple Inc. Communication adaptation based on link-performance characteristics
US10069719B2 (en) 2015-06-16 2018-09-04 Samsung Electronics Co., Ltd. Method and apparatus for multipath media delivery
US10602560B2 (en) 2015-06-26 2020-03-24 Telefonaktiebolaget Lm Ericsson (Publ) First network node and methods therein, for determining whether a second multi path transmission control protocol connection is to be initiated
WO2017007705A1 (en) 2015-07-06 2017-01-12 Shape Security, Inc. Asymmetrical challenges for web security
US10476992B1 (en) * 2015-07-06 2019-11-12 F5 Networks, Inc. Methods for providing MPTCP proxy options and devices thereof
DE102015114164A1 (de) 2015-08-26 2017-03-02 Technische Universität Darmstadt Verfahren zur Aufrechterhaltung der Performance einer Multipath-TCP-Verbindung
FR3040851B1 (fr) 2015-09-07 2018-07-27 Worldline Procede et dispositif d'etablissement et de maintien d'un acces a internet par utilisation d'un protocole de communication sans fil en reseau informatique local a partir d'une station cliente mobile
CN105490933B (zh) * 2015-12-28 2019-06-11 中国电子科技集团公司第五十四研究所 基于多路径传输协议mptcp的路径管理方法及装置
WO2017157457A1 (en) * 2016-03-18 2017-09-21 Nec Europe Ltd. Sdn support for disjoint multipath configuration
US9992786B2 (en) 2016-03-31 2018-06-05 At&T Intellectual Property I, L.P. Facilitation of multipath scheduling
US10193781B2 (en) 2016-04-14 2019-01-29 At&T Intellectual Property I, L.P. Facilitation of multipath transmission control protocols
WO2018032517A1 (zh) * 2016-08-19 2018-02-22 华为技术有限公司 业务流路由方法和设备
EP3297322B1 (de) * 2016-09-15 2022-06-22 Alcatel Lucent Mehrpfadübertragung von daten
US10257283B2 (en) * 2016-10-03 2019-04-09 International Business Machines Corporation System, method and computer program product for network function modification
US10498868B2 (en) * 2017-02-14 2019-12-03 Alcatel Lucent Multipath transport communications
US11088940B2 (en) 2017-03-07 2021-08-10 Akamai Technologies, Inc. Cooperative multipath
CN108667880A (zh) * 2017-03-31 2018-10-16 华为技术有限公司 一种负载均衡系统、方法及装置
CN108881008B (zh) * 2017-05-12 2021-06-08 华为技术有限公司 一种数据传输的方法、装置和系统
WO2018222007A1 (en) 2017-06-02 2018-12-06 Samsung Electronics Co., Ltd. Methods and systems for accounting for data usage in mptcp
WO2019061337A1 (en) 2017-09-29 2019-04-04 Apple Inc. ROHC HEADER COMPRESSION FOR MPTCP
CN111837423A (zh) * 2018-03-13 2020-10-27 松下知识产权经营株式会社 设备管理系统、设备以及控制方法
US10708170B2 (en) 2018-03-14 2020-07-07 At&T Intellectual Property I, L.P. Transferring data over multiple network paths using decoupled sub-flows
US11343697B2 (en) * 2018-05-16 2022-05-24 Comcast Cable Communications, Llc Systems and methods for network device management
CN109005124A (zh) * 2018-06-25 2018-12-14 成都鼎桥通信技术有限公司 一种mptcp负荷分担方法和装置
CN108965262B (zh) * 2018-06-26 2021-06-18 成都鼎桥通信技术有限公司 专网的mptcp鉴权方法和系统
CN110875799B (zh) 2018-09-04 2023-07-07 华为技术有限公司 一种传输控制方法和装置
CN111031078B (zh) * 2018-10-09 2021-05-04 华为技术有限公司 一种通信方法及装置
CN109413169A (zh) * 2018-10-15 2019-03-01 北京东土军悦科技有限公司 设备间通信方法、装置、计算机设备以及存储介质
CN111107672B (zh) 2018-10-26 2023-04-18 华为技术有限公司 一种建立多路径连接的子流的方法、装置和系统
CN111372329B (zh) * 2018-12-25 2022-08-19 华为技术有限公司 一种连接建立方法及终端设备
US10659569B1 (en) 2019-01-18 2020-05-19 Hewlett Packard Enterprise Development Lp End-to-end multipath TCP through network gateways
US10951514B2 (en) * 2019-05-21 2021-03-16 Cisco Technology, Inc. Traffic distribution approaches in multipath TCP with monetary link-cost awareness
US10880702B1 (en) 2019-06-04 2020-12-29 Sprint Communications Company L.P. Data communications for user applications that are executing in a wireless user device
US11558733B2 (en) * 2019-07-10 2023-01-17 Samsung Electronics Co., Ltd. Managing sub-flow communications in user equipment
CN111131017B (zh) * 2019-11-19 2021-06-29 中国科学院计算技术研究所 一种基于多蜂窝无线接入网关的mptcp跨层优化方法及系统
CN111200557B (zh) * 2019-11-22 2021-08-10 荣耀终端有限公司 一种连接建立方法及终端设备
CN112020112B (zh) * 2020-07-27 2021-10-01 北京邮电大学 Sdn架构下基于mptcp的异构网络切换方法和系统
CN114531475A (zh) * 2020-11-02 2022-05-24 中兴通讯股份有限公司 一种业务传输方法、通信设备及存储介质
CN113347681B (zh) * 2021-05-31 2023-07-14 浙江大华技术股份有限公司 数据传输方法、装置、存储介质及电子装置
CN115379469B (zh) * 2022-08-12 2023-11-28 江苏省电力试验研究院有限公司 一种基于机器学习的多接入异构网络mptcp子流调度方法
EP4354808A1 (de) * 2022-10-14 2024-04-17 Elmos Semiconductor SE Gateway zur verbindung mit einem host-prozessor und mehreren slaves und verfahren zum betreiben des gateways

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101132347A (zh) * 2006-08-24 2008-02-27 华为技术有限公司 一种实现tcp连接备份的系统及方法
EP2514159B1 (de) * 2009-12-14 2021-02-17 Nokia Technologies Oy Verfahren und vorrichtung für mehrwegekommunikation
WO2011153415A1 (en) * 2010-06-04 2011-12-08 Interdigital Patent Holdings, Inc. Mptcp and mobil ip interworking
TW201233111A (en) * 2010-10-15 2012-08-01 Interdigital Patent Holdings Socket application program interface (API) extension
US8750188B2 (en) 2010-12-01 2014-06-10 Deutsche Telekom Ag System support for accessing and switching among multiple wireless interfaces on mobile devices
CN103299710B (zh) 2011-01-14 2016-08-17 诺基亚技术有限公司 用于基于查找表进行多路径调度的方法
US20120188949A1 (en) 2011-01-20 2012-07-26 Motorola-Mobility, Inc. Wireless communication device, wireless communication system, and method of routing data in a wireless communication system
EP2495927B1 (de) * 2011-03-02 2014-10-08 Alcatel Lucent Konzept zur Bereitstellung von Informationen in einer Datenpaketassoziation und zur Weiterleitung eines Datenpakets
CN102761470B (zh) * 2011-04-29 2015-04-08 清华大学 一种多径tcp传输协议报文调度方法
US20120331160A1 (en) * 2011-06-22 2012-12-27 Telefonaktiebolaget L M Ericsson (Publ) Multi-path transmission control protocol proxy service
US9699274B2 (en) * 2011-07-25 2017-07-04 Alcatel Lucent Method and apparatus for reliable session migration
US8780693B2 (en) * 2011-11-08 2014-07-15 Massachusetts Institute Of Technology Coding approach for a robust and flexible communication protocol
US9820200B2 (en) 2011-12-19 2017-11-14 Facebook, Inc. Captive portal state detection and avoidance for multiple-interface traffic offloading
US8817797B2 (en) * 2012-01-31 2014-08-26 Alcatel Lucent Method and apparatus for multipath protocol packet relay
US8824480B2 (en) * 2012-01-31 2014-09-02 Alcatel Lucent Method and apparatus for end-host based mobility, multi-homing and multipath protocols
US10064241B2 (en) 2012-02-15 2018-08-28 T-Mobile Usa, Inc. Dynamically enabled Wi-Fi
CN102595544A (zh) 2012-03-21 2012-07-18 厦门市凌拓通信科技有限公司 一种实现wifi与4g网络在移动设备上自动切换的方法
EP2645780A1 (de) 2012-03-30 2013-10-02 British Telecommunications Public Limited Company Zugangspunkterkennung
WO2014044333A1 (en) * 2012-09-24 2014-03-27 Telefonaktiebolaget L M Ericsson (Publ) Traffic shaping and steering for a multipath transmission control protocol connection
US9407701B2 (en) 2012-12-14 2016-08-02 Apple Inc. Address family preference in multiple network interface environments
EP2962429B1 (de) * 2013-02-26 2019-12-11 Telefonaktiebolaget LM Ericsson (publ) Verkehrswiederherstellung in openflow-netzwerken

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
IEEE 802.11
IEEE 802.16

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102015208666B4 (de) 2014-05-30 2018-07-05 Apple Inc. Langlebige MPTCP-Sitzungen

Also Published As

Publication number Publication date
US9948725B2 (en) 2018-04-17
CN104243443A (zh) 2014-12-24
CN108418751B (zh) 2020-12-01
CN108418751A (zh) 2018-08-17
CN104243443B (zh) 2018-04-20
US10735524B2 (en) 2020-08-04
US20160373533A1 (en) 2016-12-22
US20140362765A1 (en) 2014-12-11
DE102014208162B4 (de) 2023-12-14
US20200336550A1 (en) 2020-10-22
US9456464B2 (en) 2016-09-27
US20180213041A1 (en) 2018-07-26

Similar Documents

Publication Publication Date Title
DE102014208162B4 (de) Mehrweg-tcp-subflow-aufbau und -steuerung
DE102015208666B4 (de) Langlebige MPTCP-Sitzungen
DE112014005501B4 (de) Kommunikation von Gerät zu Gerät mit Carrier-Aggregation
DE112020001183T5 (de) Multi-slice-unterstützung für mec-fähige 5g-implementierungen
DE102021211176A1 (de) Interoperables framework für sicheren verbrauch von dual-modus-edge-anwendungsprogrammierungsschnittstellen in hybriden edge-computing-plattformen
DE102020201015A1 (de) Technologien zum verteilen iterativer berechnungen in heterogenen computerumgebungen
DE102021209988A1 (de) Techniken zur klassifizierung und priorisierung von mehrfachzugangsverwaltungsdienstpaketen
DE112015003181T5 (de) Verfahren für leitungsvermitteltes Fallback in 3GPP
US20150201046A1 (en) Multipath TCP Signaling with Application Specific Tags
CN110351186A (zh) 多路径传输控制协议代理在蜂窝网络中的使用
DE112013005322T5 (de) Ausdehnen der Nutzung einer Mobilkommunikationsfähigkeit in einer kabellosen Vorrichtung auf eine andere Vorrichtung
DE102016206941A1 (de) Kommunizieren über Nur-IPv6 Netzwerke unter Verwendung von IPv4 Wortkennungen
WO2011148234A1 (en) System, method, and apparatus for determining a network interface preference policy
DE102022211529A1 (de) Methoden zum einreihen und neuordnen für mehrfachzugangsverwaltungsdienste
DE102020205514A9 (de) Intelligente kernnetzauswahl
DE112015006864T5 (de) Drahtlosen persönlichen Netzen zugrundliegende Zellennetze
DE102020206415A1 (de) Sidelink-Verbesserung für Benutzerausrüstung
DE102016206944A1 (de) Verwendung von Basisband-Triggern zum Verschmelzen von Anwendungsdatenaktivität
DE102015203353A1 (de) EDCA-Betrieb zum Verbessern von VoIP-Leistung in einem dichten Netzwerk
US20160366195A1 (en) Relayed Communication Channel Establishment
DE102019128185A1 (de) Heterogenes drahtloses wechseln eines informationszentrischen netzwerks
DE112013004554B4 (de) Vorrichtung und Verfahren zur Kommunikation
DE102022208685A1 (de) Sicherheit des direktzugriffskanals
DE102021113144A1 (de) Relais-(neu-)auswahl über sidelink in zellularen netzwerken
DE112021002671T5 (de) Ki-basierte mobilfunknetzverwaltung und -orchestrierung

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication
R016 Response to examination communication
R018 Grant decision by examination section/examining division