WO2019014426A1 - Gestion de trajet de communication - Google Patents

Gestion de trajet de communication Download PDF

Info

Publication number
WO2019014426A1
WO2019014426A1 PCT/US2018/041782 US2018041782W WO2019014426A1 WO 2019014426 A1 WO2019014426 A1 WO 2019014426A1 US 2018041782 W US2018041782 W US 2018041782W WO 2019014426 A1 WO2019014426 A1 WO 2019014426A1
Authority
WO
WIPO (PCT)
Prior art keywords
address
addresses
mptcp
interface
wtru
Prior art date
Application number
PCT/US2018/041782
Other languages
English (en)
Other versions
WO2019014426A9 (fr
WO2019014426A8 (fr
Inventor
Michelle Perras
Robert D. GAZDA
Xavier De Foy
Original Assignee
Interdigital Patent Holdings, 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 Interdigital Patent Holdings, Inc. filed Critical Interdigital Patent Holdings, Inc.
Publication of WO2019014426A1 publication Critical patent/WO2019014426A1/fr
Publication of WO2019014426A8 publication Critical patent/WO2019014426A8/fr
Publication of WO2019014426A9 publication Critical patent/WO2019014426A9/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/24—Multipath
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/14—Multichannel or multilink protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing

Definitions

  • communication devices establish communication paths through networks and use those paths to send and receive data. Communication paths are created and maintained using various communication protocols.
  • mobile wireless networks such as, for example, 3rd Generation Partnership Project (3GPP) networks, may employ the Transmission Control Protocol (TCP) to create communication paths and to communicate data.
  • TCP Transmission Control Protocol
  • TCP provides for a device to maintain a single communication path for a given communication interface.
  • Other communication technologies allow for a communication device to maintain multiple simultaneous communication paths through a network for a single communication interface.
  • communication protocols such as Multi-path TCP (MPTCP) and Stream Control Transmission Protocol (SCTP) allow communication devices to establish multiple communication paths for a communication interface.
  • MPTCP Multi-path TCP
  • SCTP Stream Control Transmission Protocol
  • a mobile device may collect and maintain data for multiple communication paths that are available to the mobile device.
  • the mobile device may use the stored data to select the communication path(s) that are well suited for particular uses, For example, the mobile device may use the stored data regarding the available communication paths to select a communication path for use in providing additional bandwidth.
  • the mobile device may select, using the stored data, a communication path for use as a backup communication path.
  • the mobile device may select, based on the stored data regarding available paths, a communication path that provides the shortest data path, [0004]
  • a mobile communication device may determine a piuraiity of internet protocol (IP) addresses, wherein each of the plurality of IP addresses is associated with a communication path, For example, as the mobile communication device moves and switches between network access points, the mobile device may receive an IP address from each of the access points,
  • IP internet protocol
  • the mobile device stores the piuraiity of IP addresses.
  • An IP address from the piuraiity of IP addresses may be stored in relation to one of a plurality of interface identifiers, which may correspond to a communication interface over which the corresponding communication path may be established, For example, the mobile device may store each of the IP addresses in relation to an interface identifier that corresponds to the physical interface with which the IP address was received.
  • the mobile device may store the IP address in relation to an interface identifier corresponding to the WiFi Interface.
  • the mobile device may store the IP address in relation to an interface identifier corresponding to the cellular interface,
  • the mobile device may use the stored IP addresses and related Interface identifiers to select a communication path.
  • a mobile device may determine a need for an additional communication path to provide additional communication bandwidth.
  • the mobile device selects one of the stored plurality of IP addresses to provide the additional communication path based at least in part on the interface identifier with which the one of the plurality of IP addresses is associated.
  • the mobile device may have an existing communication path over a first interface such as, for example, a WiFi interface,
  • the mobile device may select for the additional communication path one of the stored plurality of IP addresses that is associated with, or corresponds to, a different communication interface such as, for example, a cellular interface. Selecting a communication path associated with an interface different than that of the existing communication path, may improve the possibility that the additional communication path will result in increased available bandwidth.
  • the mobile device may determine a need for an additional communication path to provide a backup or secondary communication path for use in case of failure of a primary communication path.
  • the mobile device selects one of the stored plurality of IP addresses to provide the additional communication path based at least in part on the interface identifier with which the one of the plurality of IP addresses is stored, For example, the mobile device may have an existing communication path over a first interface such as, for example, a WiFi interface, The mobile device may select as the backup communication path one of the stored plurality of IP addresses that is associated with or corresponds to a different communication interface such as, for example, a cellular interface. Selecting a communication path associated with an interface different than that of the
  • the mobile device may determine to select a communication path through a network that Is relatively direct, or short in terms of its network path,
  • the shortest path through the network is often provided by the IP address that corresponds to the most recently established connection to the network.
  • the mobile device may select an IP addresses that will provide the shortest data path based at least in part on the state of a connection, a type of connection associated with an IP address, or an interface identifier with which the IP address is associated.
  • the mobile device may select an IP address that is associated with a direct network connection and is associated with the communication interface that is currently being used.
  • the IP address that is most recently assigned to the device may provide a direct network connection, may be associated with the existing communication interface, and may offer the shortest data path.
  • a mobile device may be adapted to support network session continuity, in an example scenario, the mobile device may receive a first IP address in response to an application creating a socket for communicating on a mobile network such as a 5G network.
  • the mobile device may identify a first session continuity service (SCS) type and store the SCS type with the first IP address.
  • SCS session continuity service
  • the mobile device may store the first IP address and associated SCS type in communication protocol stack.
  • the mobile device may receive a second IP address and may Identify an SCS type associated with the second IP address.
  • the mobile device may determine whether or not to employ the second IP address for creating a communication path based at least upon the first SCS type associated with the first IP address and the second SCS type associated with the second IP address. For example, the mobile device may determine to use the second IP address to create a subflow where first SCS type has a value of Fixed or Session Lasting and the second SCS type has a value of Non Persistent.
  • FIG, 1 A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented.
  • FIG. 1 B is a system diagram illustrating an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1 A according to an embodiment.
  • WTRU wireless transmit/receive unit
  • FiG. 1 C Is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1 A according to an embodiment.
  • RAN radio access network
  • CN core network
  • FIG, 1 D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated In FIG. 1A according to an embodiment.
  • FIG, 2 Is a diagram of an example DMM-based mobile network system.
  • FiG. 3 Is a diagram of an example multi-homed PDU session
  • FIG, 4 is a diagram of example processing in a multi-path environment for additional bandwidth path management
  • FIG. 5 Is a diagram of example processing in a multi-path environment for additional bandwidth path management.
  • FiG. 6 Is a diagram of example processing in a multi-path environment for backup path management.
  • FIG. 7 is a diagram of example processing in a multi-path environment for backup path management.
  • FIG, 8 is a diagram of example processing in a multi-path environment for session continuity.
  • FiG. 9 Is a diagram of example processing in a multi-path environment for session continuity
  • FIG, 10 is a diagram of an example router advertisement message format.
  • FIG. 11 is a diagram of an example router advertisement message format.
  • FIG. 12 is a diagram of an example DHCP message format.
  • FIG, 13 is a diagram of an example DHCP message format
  • FiG. 14 is a diagram of an example MPTCP message format
  • FIG, 15 is a diagram of an example PTCP message format.
  • FIG. 16 is a diagram of an example PTCP message format.
  • FIG. 17 is a diagram of an example MPTCP message format.
  • FIG. 18 is a diagram of an example SCTP message format.
  • FIG, 19 is a diagram of an example SCTP message format.
  • FIG. 20 is a diagram of example processing in a multi-path environment for MPTCP additional bandwidth path management.
  • FIG. 21 is a diagram of example processing in a multi-path environment for MPTCP backup path management.
  • FIG, 22 is a diagram of example processing in a multi-path environment for SCTP backup path management.
  • FIG. 23 is a diagram of example processing In a multi-path environment for MPTCP data path length management.
  • FIG. 24 is a diagram of example processing in a multi-path environment tor SCTP data path length management.
  • FIG, 25 is a diagram of example processing by a 5G stack for setting the compatibility group of a network interface.
  • FIG. 26 is a diagram of an example enhanced Multipath Capable ( P . CAPABLE) option.
  • FIG. 27 is a diagram of an example enhanced Join Connection (MP_JOIN) Option.
  • FIG, 28 is a diagram of an example enhanced Join Connection (MP_JOIN) Option.
  • FIG. 29 is a diagram of an example enhanced Add Address (ADD .. ADDR) Option.
  • FIG, 30 is a diagram of an example format for a TCP option ASSOCIATE_SCS . TYPE.
  • FIG. 31 is a diagram of an example format for TCP option ASSOCIATE .. SCS .. TYPE,
  • FIG. 32 is a diagram of an example Address ID field.
  • FIG, 33 is a diagram of an example procedure for establishing and maintaining an application session over MPTCP in a 5G network
  • FIG. 1 A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be Implemented.
  • the communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users.
  • the communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth.
  • the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank muitiearrier (FBMC), and the like.
  • CDMA code division multiple access
  • TDMA time division multiple access
  • FDMA frequency division multiple access
  • OFDMA orthogonal FDMA
  • SC-FDMA single-carrier FDMA
  • ZT UW DTS-s OFDM zero-tail unique-word DFT-Spread OFDM
  • UW-OFDM unique word OFDM
  • FBMC filter bank muitiearrier
  • the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104/113, a CN 106/115, a public switched telephone network (PSTN) 108, the Internet 1 10, and other networks 112, though it wiii be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements.
  • WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment.
  • the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e,g,, remote surgery), an industrial device and applications (e.g..
  • UE user equipment
  • PDA personal digital assistant
  • HMD head-mounted display
  • any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a UE.
  • the communications systems 100 may also include a base station 114a and/or a base station 114b, Each of the base stations 1 14a, 1 14b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106/115, the Internet 1 10, and/or the other networks 1 12,
  • the base stations 1 14a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a gNB, a NR NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 1 14a, 114b are each depicted as a single element, it will be appreciated that the base stations 1 14a, 1 14b may include any number of Interconnected base stations and/or network elements,
  • the base station 114a may be part of the RAN 104/1 13, which may also Include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc.
  • the base station 1 14a and/or the base station 1 14b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown), These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of !icensed and suitcensed spectrum.
  • a DC! may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time.
  • the ceil may further be divided into cell sectors.
  • the cell associated with the base station 114a may be divided into three sectors.
  • the base station 1 14a may include three transceivers, i.e., one for each sector of the cell.
  • the base station 114a may employ multiple-input multiple output (Ml MO) technology and may utilize multiple transceivers for each sector of the cell.
  • Ml MO multiple-input multiple output
  • beamforming may be used to transmit and/or receive signals in desired spatial directions.
  • the base stations 114a, 114b may communicate with one or more of the VVTRUs 102a, 102b, 102c, 102d over an air interface 1 16, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (!R), ultraviolet (UV), visible light, etc.),
  • the air interface 116 may be established using any suitable radio access technology (RAT),
  • the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA. SC-FDMA, and the like.
  • the base station 1 14a in the RAN 104/1 13 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air Interface 115/116/117 using wideband CDMA (WCDMA).
  • WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+).
  • HSPA may Include High-Speed Downlink (DL) Packet Access (HSDPA) and/or High-Speed UL Packet Access (HSUP.A).
  • the base station 1 14a and the WTRUs 102a, 102b, 102c may Implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A) and/or LTE-Advanced Pro (LTE-A Pro).
  • E-UTRA Evolved UMTS Terrestrial Radio Access
  • LTE Long Term Evolution
  • LTE-A LTE-Advanced
  • LTE-A Pro LTE-Advanced Pro
  • the base station 1 14a and the WTRUs 102a, 102b, 102c may Implement a radio technology such as NR Radio Access, which may establish the air Interface 116 using New Radio (NR).
  • a radio technology such as NR Radio Access, which may establish the air Interface 116 using New Radio (NR).
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies.
  • the base station 1 14a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles.
  • DC dual connectivity
  • the air interface utilized by VVTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to/from multiple types of base stations (e.g., a [0057] in other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802,1 1 (i.e., Wireless Fidelity (W ' iFi), IEEE 802,16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (iSIG)
  • the base station 114b in FIG. 1 A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like.
  • the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.1 1 to establish a wireless local area network (WLAN).
  • WLAN wireless local area network
  • the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN),
  • the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc) to establish a picoceii or femtoce!l.
  • a cellular-based RAT e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc
  • the base station 1 14b may have a direct connection to the internet 110,
  • the base station 114b may not be required to access the Internet 1 10 via the CN 106/115.
  • the RAN 104/1 13 may be in communication with the CN 106/1 15, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a. 102b, 102c, 102d.
  • the data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like
  • QoS quality of service
  • the CN 106/1 15 may provide call control, billing services, mobile location-based services, pre-paid calling, internet connectivity, video distribution, etc, and/or perform high-level security functions, such as user authentication, Although not shown in FIG.
  • the RAN 104/113 and/or the CN 106/115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104/1 13 or a different RAT.
  • the CN 106/115 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.
  • the CN 106/115 may also serve as a gateway for the " WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or the other networks 112.
  • the PSTN 108 may include circuit- switched telephone networks that provide plain old telephone service (POTS),
  • POTS plain old telephone service
  • the Internet 110 may include a global system of Interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and/or the internet protocol (IP) in the TCP/IP internet protocol suite.
  • TCP transmission control protocol
  • UDP user datagram protocol
  • IP internet protocol
  • the networks 112 may include wired and/or wireless communications networks owned and/or operated by other service providers,
  • the networks 1 12 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104/1 13 or a different RAT,
  • VVTRUs 102a, 102b, 102c, 102d in the communications system 100 may- include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links).
  • the WTRU 102c shown in FIG. 1 A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology,
  • FIG, 1 B is a system diagram illustrating an example WTRU 102
  • the WTRU 102 may include a processor 1 18, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and/or other peripherals 138, among others, It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment,
  • GPS global positioning system
  • the processor 1 18 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like,
  • the processor 1 18 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment.
  • the processor 1 18 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. 1 B depicts the processor 1 18 and the transceiver 120 as separate components, it will be appreciated that the processor 1 18 and the transceiver 120 may be integrated together in an electronic package or chip.
  • the transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 1 14a) over the air interface 1 16.
  • a base station e.g., the base station 1 14a
  • the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals.
  • the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example.
  • the transmit/receive element 122 may be configured to transmit and/or receive both RF and light signals, It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals,
  • the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ IMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.
  • the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.
  • the transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122.
  • the WTRU 102 may have multi-mode capabilities.
  • the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11 , for example.
  • the processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the dispiay/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit).
  • the processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the dispiay/touchpad 128,
  • the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132.
  • the non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device.
  • the removable memory 132 may Include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like.
  • SIM subscriber identity module
  • SD secure digital
  • the processor 1 18 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).
  • the processor 1 18 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102.
  • the power source 134 may be any suitable device for powering the " WTRU 102.
  • the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickei-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc), solar cells, fuel cells, and the like.
  • the processor 1 18 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102.
  • location information e.g., longitude and latitude
  • the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location- determination method while remaining consistent with an embodiment.
  • the processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity.
  • the peripherals 138 may include an acceierometer, an e-compass, a satellite transceiver, a digital camera (for photographs and/or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and/or Augmented Reality (V ' R/AR) device, an activity tracker, and the like
  • the peripherals 138 may include one or more sensors, the sensors may be one or more of a gyroscope, an acceierometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor;
  • the WTRU 102 may include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for both the UL (e.g., for transmission) and downlink (e.g., for reception) may be concurrent and/or simultaneous.
  • the full duplex radio may include an interference management unit to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 1 18).
  • the WRTU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the downlink (e.g., for reception)).
  • a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the downlink (e.g., for reception)).
  • FIG, 1 C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment.
  • the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air Interface 1 16.
  • the RAN 104 may also be in communication with the CN 106.
  • the RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may Include any number of eNode-Bs while remaining consistent with an embodiment.
  • the eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the eNode-Bs 160a, 160b, 160c may implement MI O technology,
  • the eNode-B 160a for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a.
  • Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, and the like. As shown in F!G. 1 C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.
  • the CN 106 shown in FIG, 1 C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.
  • MME mobility management entity
  • SGW serving gateway
  • PGW packet data network gateway
  • the MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an 81 interface and may serve as a control node.
  • the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like.
  • the MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown ⁇ that employ other radio technologies, such as GSM and/or WCDMA.
  • the SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface.
  • the SGW 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b. 102c.
  • the SGW 164 may perform other functions, such as anchoring user planes during inter- eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.
  • the SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices,
  • the CN 106 may facilitate communications with other networks.
  • the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices,
  • the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108.
  • IMS IP multimedia subsystem
  • the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.
  • the WTRU is described in FIGS, 1 A-1 D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network.
  • the other network 1 12 may be a WLAN.
  • a VVLAN in infrastructure Basic Service Set (BSS) mode may have an Access ! :> oint (AP) for the BSS and one or more stations (STAs) associated with the AP,
  • the AP may have an access or an interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic in to and/or out of the BSS, Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations, Traffic between STAs within the BSS may be sent through the AP.
  • DS Distribution System
  • the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA.
  • the traffic between STAs within a BSS may be considered and/or referred to as peer-to- peer traffic.
  • the peer-to-peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS).
  • the DLS may use an 802,11 e DLS or an 802.1 1z tunneled DLS (TDLS).
  • a WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other.
  • the IBSS mode of communication may sometimes be referred to herein as an "ad- hoc" mode of communication.
  • the AP may transmit a beacon on a fixed channel, such as a primary channel.
  • the primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling.
  • the primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP.
  • Carrier Sense Multiple Access with Collision Avoidance may be implemented, for example in in 802.1 1 systems, for CSMA/CA, the STAs (e.g., every STA), including the AP, may sense the primary channel, If the primary channel is sensed/detected and/or determined to be busy by a particular STA, the particular STA may back off.
  • One STA e.g., only one station
  • High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.
  • VHT STAs may support 20MHz, 40 MHz, 80 MHz, and/or 160 MHz wide channels
  • the 40 MHz, and/or 80 MHz, channels may be formed by combining contiguous 20 MHz channels
  • a 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80 ⁇ 80 configuration.
  • the data, after channel encoding may be passed through a segment parser that may divide the data into two streams.
  • Inverse Fast Fourier Transform (IFFT) processing, and time domain processing may be done on each stream separately.
  • IFFT Inverse Fast Fourier Transform
  • the streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting ST.A.
  • the herein described operation for the 80 ⁇ 80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).
  • MAC Medium Access Control
  • Sub 1 GHz modes of operation are supported by 802,1 1 af and 802.11 ah.
  • the channel operating bandwidths, and carriers, are reduced in 802.11 af and 802.1 1 ah relative to those used in 802.1 1 ⁇ , and 802.11 ac.
  • 802.11 af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum
  • 802.11 ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non- TV ' WS spectrum.
  • 802.11 ah may support Meter Type
  • MTC devices may have certain capabilities, for example, limited capabilities Including support for (e.g., only support for) certain and/or limited bandwidths.
  • the MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life),
  • WLAN systems which may support multiple channels, and channel bandwidths, such as 802.11 ⁇ , 802. 1 ac, 802.1 l af, and 802.11 ah, include a channel which may be designated as the primary channel.
  • the primary channel may have a bandwidth equal to the largest common operating bandwidth supported by ail STAs in the BSS,
  • the bandwidth of the primary channel may be set and/or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode.
  • the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., may only support) a 1 MHz mode, even if the AP, and other STAs In the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and/or other channel bandwidth operating modes.
  • Carrier sensing and/or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which may support only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idie and may be available.
  • STAs e.g., MTC type devices
  • NAV Network Allocation Vector
  • the available frequency bands which may be used by 802.11 ah, are from 902 MHz to 928 MHz. in Korea, the available frequency bands are from 917.5 MHz to 923,5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.1 1 ah is 6 MHz to 26 MHz depending on the country code.
  • FIG. 1 D is a system diagram illustrating the RAN 113 and the CN 1 15 according to an embodiment.
  • the RAN 1 13 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the RAN 1 13 may also be in communication with the [0090]
  • the RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 1 13 may include any number of gNBs while remaining consistent with an embodiment,
  • the gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the gNBs 180a, 180b, 180c may implement M IMO technology.
  • gNBs 180a, 108b may utilize beamforming to transmit signals to and/or receive signals from the gNBs 180a, 180b, 180c.
  • the gNB 180a may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the VVTRU 102a.
  • the gNBs 180a, 180b, 180c may implement carrier aggregation technology.
  • the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum.
  • the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology.
  • VVTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and/or gNB 180c),
  • the WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and/or OFDM subcarrier spacing may vary for different transmissions, different cells, and/or different portions of the wireless transmission spectrum.
  • the WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing varying number of OFDM symbols and/or lasting varying lengths of absolute time).
  • TTIs subframe or transmission time intervals
  • the gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and/or a non-standalone configuration. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c).
  • RANs e.g., such as eNode-Bs 160a, 160b, 160c.
  • WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point, In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration " WTRUs 102a, 102b, 102c may communicate with/connect to gNBs 180a, 180b, 180c while also communicating with/connecting to another RAN such as eNode-Bs 160a, 160b, 160c.
  • eNode-Bs 160a, 160b, 160c eNode-Bs
  • WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously.
  • eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and/or throughput for servicing WTRUs 102a, 102b, 102c, [0093]
  • Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, support of network slicing, dual connectivity, interworking between NR and E- UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control
  • UPF User Plane
  • the CN 115 shown in FIG. 1 D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the foregoing elements are depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator,
  • the AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c In the RAN 1 13 via an N2 interface and may serve as a control node,
  • the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, and the like, Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c.
  • network slicing e.g., handling of different PDU sessions with different requirements
  • Network slicing may be used by the AMF 182a, 18
  • the AMF 162 may provide a control plane function for switching between the RAN 1 13 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and/or non-3GPP access technologies such as WiFi.
  • the SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 115 via an N11 interface, The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 115 via an N4 interface, The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b.
  • the SMF 183a, 183b may perform other functions, such as managing and allocating UE IP address, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and the like.
  • a PDU session type may be IP-based, non-IP based, Ethernet- based, and the like.
  • the UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102G and IP-enabled devices.
  • the UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user piane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like.
  • the CN 115 may facilitate communications with other networks.
  • the CN 115 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108.
  • IMS IP multimedia subsystem
  • the CN 115 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may Include other wired and/or wireless networks that are owned and/or operated by other service providers.
  • the WTRUs 102a, 102b, 102c may be connected to a local Data Network (DN) 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.
  • DN local Data Network
  • one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 1 14a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and/or any other device(s) described herein, may be performed by one or more emulation devices (not shown).
  • the emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein.
  • the emulation devices may be used to test other devices and/or to simulate network and/or WTRU functions.
  • the emulation devices may be designed to implement one or more tests of other devices in a lab environment and/or In an operator network environment.
  • the one or more emulation devices may perform the one or more, or all, functions while being fully or partially implemented and/or deployed as part of a wired and/or wireless communication network in order to test other devices within the communication network.
  • the one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented/deployed as part of a wired and/or wireless communication network.
  • the emulation device may be directly coupled to another device for purposes of testing and/or may performing testing using over-the-air wireless communications.
  • the one or more emulation devices may perform the one or more, including all, functions while not being implemented/deployed as part of a wired and/or wireless communication network,
  • the emulation devices may be utilized in a testing scenario in a testing laboratory and/or a non-deployed (e.g., testing) wired and/or wireless communication network in order to implement testing of one or more components.
  • the one or more emulation devices may be test equipment.
  • Direct RF coupling and/or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and/or receive data.
  • Applicants disclose systems and methods for managing communication paths in a multipath communication environment, in an example embodiment, as a mobile device connects to anchor points in a wireless network, the mobile device may determine a plurality of internet protocol (IP) addresses, with each of the plurality of IP addresses being associated with a communication path.
  • IP internet protocol
  • the mobile device stores the plurality of IP addresses.
  • An interface identifier corresponding to a physical interface over which an IP address was received is stored in relation to each IP address,
  • An interface identifier from the plurality of interface identifiers may correspond to a physical communication interface such as a WiFi Interface or cellular interface.
  • the mobile device may use the stored data to select an IP address corresponding to a communication path.
  • the mobile device may select a communication path associated with one of the plurality of IP addresses based at least upon the interface identifier stored in relation to the one of the plurality of IP addresses, in an example scenario, the mobile device may select a communication path associated with one of the plurality of IP address based at least upon the associated interface identifier corresponding to a communication interface that is different than that used by the existing communication path.
  • the disclosed systems and methods for managing communication paths may be implemented with any suitable communication protocols.
  • the disclosed processes may be implemented, for example, using Multipath TCP (PTCP) and/or Stream Control Transmission Protocol ion
  • Multi-path TCP may be considered an extended version of TCP and may allow hosts to use multiple paths to send and receive data belonging to one connection.
  • MPTCP may operate at the transport layer and may be transparent to both higher and lower layers.
  • PCTP may provide a set of additional features in addition to those provided by standard TCP,
  • An MPTCP connection may be composed of several TCP connections, which may be referred to as sub-flows, MPTCP manages the creation, removal, and utilization of sub-flows used In transmitting data.
  • a host device may take one Input data stream from an application, split the Input data stream into one or more sub-flows, and provide sufficient control information to allow the sub-flows to be reassembled and delivered reliably to the recipient application.
  • the use of these multiple paths (e.g. sub-flows) for a TCP/IP session may Improve resource usage within the network and, may improve user experience through higher data throughput and Improved resilience to network interruptions,
  • the use of these multiple paths (sub-flows) may be simultaneous.
  • a host device may indicate at Initial sub-flow setup whether they wish the sub-flow to be used as a regular or backup path.
  • a backup path may be used if a regular path may not be available. This setting may be referred to as sub-flow priority.
  • hosts may request a change in the priority of a sub-flow.
  • MPTCP may be used transparently to legacy TCP applications
  • MPTCP-specific socket API calls may have been defined for MPTCP-aware applications.
  • the MPTCP API call TCP .. MULTI PATH . ADD may be made available to and accessed by applications.
  • TCP .. MULTIPATH . ADD API call may be applied both before connection setup and during a connection, if implemented before connection setup, the API call controls the local addresses that an MPTCP connection can use. if called during a connection, the TCP_MULTIPATH_ADD API allows MPTCP to use an additional local address, if there has been a restriction before connection setup. It will be appreciated that the TCP_MULTIPATH_ADD API call is referenced as an example and that the same or similar functionality may be provided by another specific socket API (in the form of, e.g., setsockopt) now existing or established in the future.
  • another specific socket API in the form of, e.g., setsockopt
  • SCTP Stream Control Transmission Protocol
  • SCTP Stream Control Transmission Protocol
  • IP connectionless packet network service
  • SCTP may be used as a transport protocol for public telephony network signaling over packet-switched IP networks, such as, for example, SS7 signaling over IP.
  • SCTP provides some of the service features of both UDP and TCP.
  • SCTP may be message-oriented like UDP and ensures reliable, in-sequence transport of messages with congestion control like TCP.
  • SCTP may differ from UDP and TCP, however, in that it may provide multi-homing and alternate paths to increase resilience and reliability.
  • SCTP similarly to PTCP, supports multi-homing, e.g., usage of multiple IP addresses over multiple interfaces, for the transmission of data toward an SCTP peer.
  • a destination IP address is selected as the primary address and is used to create a primary path which may include source and destination IP addresses,
  • the primary path may be used for transmission, and any other addresses/paths are used for redundancy purposes, For example, an alternate or backup address/path may be used if the primary communication path becomes inactive or if packet retransmission needs to be performed.
  • Different IP addresses may be bound to different interfaces/networks, which may provide resiliency in case of a network failure.
  • the sender may transmit packets (e.g. automatically transmit new packets) to an alternate destination address if one exists and is active, If more than one alternate address is active when the primary path is marked inactive, one transport address may be chosen and used as the new destination transport address.
  • packets e.g. automatically transmit new packets
  • IP addresses assigned to an SCTP peer may be exchanged during the association phase (e.g., using IN IT and INIT-ACK). New IP addresses may be added later and existing ones may be removed (e.g., using ASCONF).
  • An IP address may, at the same time, be suggested as the primary IP address, The selection of the primary IP address may be done on a (e.g., each) communication side and may differ from the suggested one.
  • SCTP may have defined messages, which may be referred to as chunks, which may be used to configure communication paths.
  • defined messages i N IT, INIT-ACK may be used to initiate an SCTP association between two endpoints.
  • Multiple IP addresses may be specified, One of these IP address may be identified as the suggested Primary IP address (using the Set Primary IP Address parameter),
  • the SCTP defined message ASCONF may be used to communicate a configuration change to its SCTP peer.
  • the change may be, for example, to add an IP address, remove an IP address, set an IP address as Primary, etc.
  • Further information regarding SCTP and related messages may be those found in IETF RFC 4980, Stream Control Transmission Protocol and IETF RFC 5061 , Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration,
  • DMM Distributed Mobility Management
  • DMM may push mobility anchors towards the edge of the network.
  • FIG, 2 depicts an example D -based network architecture, As shown, the Distributed Gateway (D-GW) logical entity may be p!aced at the edge of the network, close to the mobile node. Multiple D-GWs may exist in a DMM domain and may be used to anchor mobility sessions of the mobile nodes attached to the domain.
  • D-GW Distributed Mobility Management
  • IP addresses may be allocated over the same interface. Session continuity for previously executing or running applications may be handled via data tunneling between anchors. An already running application may continue using the same IP address and the associated data traffic may be tunneled to its anchor node. Newly started applications may be associated with the newly obtained IP address may be anchored at the directly connected anchor node. This mechanism may be the shortest data path selection for new applications that get started after the handover.
  • Some networking technologies such as, for example 5GC, support a service, which may be referred to as a PDU Connectivity Service, that may provide an exchange of PDUs between a device and a data network. Additional information may be found in 3GPP TS 23.501 vO.3.1 (2017-03), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System Architecture for the 5G System; Stage2 (Release 15).
  • a PDU Session may be associated with multiple IPv6 prefixes. Such a session may be referred to as multi-homed PDU Session.
  • the PDU Session may provide access to the Data Network via more than one PDU (IPv6) anchor.
  • IPv6 PDU
  • the different user plane paths leading to the IP anchors branch out at a UPF, which may be referred to as a UPF supporting "Branching Point" functionality.
  • the Branching Point provides forwarding of UL traffic towards the different IP anchors and merging of DL traffic to the mobile device.
  • the BP may merge the traffic from the different IPv6 anchors on the link towards the device. As illustrated in FIG.
  • the same UPF may support both the Branching Point and the PDU session anchor functionalities.
  • the use of multiple IPv6 prefixes in a PDU session relies on several networking features, For example, the UPF supporting a Branching Point functionality Is configured by the SMF to spread the UL traffic between the IP anchors based on the Source Prefix of the PDU (e.g., selected by the device based on rules received from the network).
  • the multi- homed PDU Session may be used to support make-before-break service continuity to support SSC mode 3 as illustrated in FIG. 3. Additionally, the multi-homed PDU session may also be used to support cases where device needs to access both a local service and a central service such as, for example, the Internet.
  • MPTCP and SCTP may enable the usage of multiple IP addresses assigned to the same device interface, e.g., multi-homing on a single physical interface, which may occur in DMM and 5G networks, Transport protocols, like MPTCP and SCTP, may interpret multi-homing as separate network interfaces. Communication Path Selection Using MPTCP or SCTP
  • MPTCP, SCTP, and other networking technologies may provide the capability to establish multiple communication paths for a single communication interface
  • these technologies may not be without shortcomings.
  • existing technologies do not collect and preserve data that allow for determining how a particular IP address is reached, e.g., whether the device is directly connected to the anchor node or reachable through a tunnel.
  • existing technologies do not collect and preserve data for determining with which interface an IP address is associated.
  • Existing technologies with the possibility of IP addresses being allocated from a local network, centra! network, etc., do not collect and preserve information sufficient to determine where an anchor node is located and to which interface it is assigned.
  • existing networking protocols do not collect and preserve information that may help setting up efficient paths in terms of available bandwidth (BW), latency, path-cost, etc.
  • PTCP offers the possibility of increasing the BW associated with a TCP session transparently from the application which created the TCP session.
  • MPTCP provides the option of additional BW by allowing for the creation of sub-flows over interfaces other than the one already in use (e.g., using different IP addresses) and associating these sub-flows to the existing TCP session, which altogether form the MPTCP session.
  • the total BW available for an MPTCP session is the accumulation of all the sub-flows associated with the same MPTCP session.
  • MPTCP may make it possible to have multiple IP addresses associated with a single interface. Management of the IP addresses may be performed in the network by the serving node, e.g. D-GW or BP.
  • the serving node e.g. D-GW or BP.
  • FIG. 4 depicts operation of existing MPTCP processing while a mobile device switches between anchor nodes in a wireless network
  • a mobile device which may be any suitable device such as, for example, a WTRU, connects to the network via a first access point (PoA1) which may be any suitable device or system such as, for example a wireless router or eNode B.
  • the mobile device receives a first IP address (IP1 ) via the access point.
  • IP1 IP address
  • the mobile device may use a first physical interface which may be, for example, a WiFi interface.
  • An application (APP1) running on the device may be started, Application APP1 starts a TCP session, which may be intercepted by the MPTCP stack.
  • An MPTCP session may be started with a remote MPTCP peer which is depicted as APP1 server, A first sub-f!ow (sub- fiowl) of type REGULAR may be configured for the newly established MPTCP session, It will be appreciated that the MPTCP peer, which is depicted as a remote peer, may be located anywhere in the network, even at the edge of the network, close to the mobile device. The process related to MPTCP sub- flow selection, creation and usage remain the same regardless of the location of the MPTCP peer.
  • the mobile device moves, performs a handover to another access point (PoA2), and obtains a second IP address (IP2) from a second anchor node,
  • the MPTCP stack may be updated to reflect the newly available IP address.
  • the mobile device may not use the newly available IP address.
  • the MPTCP session used by APP1 does not employ IP2. Rather, APP1 traffic continues to use the same TCP session associated with IP1.
  • Data traffic using IP1 continues through PoA2 and is tunneled to PoA1 before being sent toward APP1 server. The tunnel allows for maintaining session continuity in the network
  • the device employs another interface (IF2) to connect to the network and gets anchored at anchor node 3.
  • the second interface IF2 may be any suitable interface, such as a cellular interface, for example, IP3 is obtained (in addition to existing IP1 and IP2) from anchor node 3,
  • IP3 is obtained (in addition to existing IP1 and IP2) from anchor node 3
  • the device may be simultaneously connected to PoA2 and PoA3.
  • IP1 IP1
  • anchor node 3 may be located at the edge of the network (as Anchorl and Anchor 2) or in the core network. The location of the anchor node does not impact the MPTCP behavior.
  • FIG. 5 depicts further processing by the MPTCP stack.
  • the MPTCP stack may determine that APP1 traffic is Increasing and that more BW may be needed.
  • the MPTCP stack creates a new sub-flow to be associated with the existing MPTCP session to obtain more BW, As shown, sub-fiow2 is created which employs IP2, APP1 traffic is distributed between the two MPTCP sub-flows (sub-flow 1 and sub-flow 2), in FIG. 5, at 5, the second sub- flow was added with the expectation that more BW would be available for APP1 traffic. However, this may not be the result.
  • both of the sub-flows (sub-flow 1 and sub-flow 2) are created over the same physical interface IF1 . Accordingly, both sub-flows share the same interface and the same limited amount of bandwidth.
  • the MPTCP stack may have 2 IP addresses available for the new sub-flow creation (i.e. IP2 and IP3). But in existing versions of MPTCP, specific rules do not exist for the IP address selection. In the depicted scenario, the MPTCP stack selected IP2, which may have been the first one to show up in a list of IP addresses. In the example scenario, a better and more effective selection would have been IP3 as it uses a separate physical interface allowing for simultaneous use of two different physical interfaces, IF1 and IF2.
  • Existing MPTCP processing may also provide less than desired results in the management of backup communication paths.
  • Existing MPTCP processing allows for the association of multiple sub-flows to an MPTCP session, with one or many of these sub-flows being identified as "backup" sub-flows.
  • Backup sub-flows may be used when a reguiar sub-flow may not be available such as when a link failure occurs,
  • FIG. 6 depicts backup communication path management using existing MPTCP processing.
  • the mobile device is connected to the network over IF1.
  • !PI is obtained from a first anchor node,
  • An application, APP1 is started and creates a TCP session.
  • the MPTCP stack running on the device intercepts the TCP session requests and transparently creates an MPTCP session with the remote MPTCP peer.
  • This MPTCP session may be associated with a sub-flow (sub-f!owl ) of type REGULAR,
  • the device may move and connect, using the same interface (IF1), to a second anchor node,
  • the device obtains a second IP address (IP2) from the second anchor node. Both the first IP address and the second IP address are allocated over the same interface, IF1 .
  • the device may obtain a third IP address (IP3).
  • IP3 IP address
  • the third IP address may be associated with a second interface (IF2).
  • the device may determine to configure a backup path for the existing MPTCP session.
  • IP2 is selected to create a backup path to the existing sub-flow1 .
  • Sub-flow2 of type BACKUP is created with the peer MPTCP. It will be appreciated that the decision to create a backup path and the selection of the IP address may be done by the MPTCP stack or by another entity such as, for example, a connection manager which is adapted to configure the available IP addresses to the MPTCP stack as needed,
  • SCTP like MPTCP. supports multi-homing may refer to using multiple IP addresses over multiple interfaces for the transmission of data toward an SCTP peer.
  • SCTP may allow for an IP address to be selected as the primary address and to be used for transmission.
  • Other IP addresses are primarily used for redundancy purposes, For example, if the primary path becomes unavailable or communication with the device requires packet retransmission, the backup or redundant IP address and corresponding communication path may be used.
  • SCTP may have similar shortcomings as MPTCP. While SCTP provides for establishing connections with multiple anchors over the same physical interface (e.g., multiple IP addresses assigned to the same physical interface and anchored at multiple anchor nodes - as supported in DMM networks and with 5G BP functionality), existing SCTP processing may result in inefficient alternate path management handling and non-optimal data path usage.
  • SCTP provides for establishing connections with multiple anchors over the same physical interface (e.g., multiple IP addresses assigned to the same physical interface and anchored at multiple anchor nodes - as supported in DMM networks and with 5G BP functionality)
  • existing SCTP processing may result in inefficient alternate path management handling and non-optimal data path usage.
  • FIG, 7 depicts example processing for alternate path management using existing SCTP processing, Referring to FIG. 7, at 1 , the mobile device connects to the network over interface IF1. !PI may be obtained from a first anchor node (Anchor 1). An SCTP application may be started which creates an association with a peer SCTP application. This SCTP association may be configured on the peer side with a path of type REGULAR using IP1 . The path created using IP1 may be identified as the primary path for data transfer. [0140] in an example scenario, the device moves and connects, using the same interface (IF1), to a second anchor node (Anchor 2), The device obtains a second IP address (IP2), The device has two IP addresses allocated over the same interface,
  • IF1 first anchor node
  • An SCTP application may be started which creates an association with a peer SCTP application. This SCTP association may be configured on the peer side with a path of type REGULAR using IP1 . The path created using IP1 may be identified as the primary path for data
  • the mobile device may subsequently connect to the network using a second interface (IF2) via PoA3, A third IP address (IP3) may be obtained from Anchor 3.
  • IP3 IP address
  • the anchors may be distributed In the network, For example, the anchors may be located close to the edge of the network and anchors may be located in a more central location in the network.
  • the SCTP stack on the device registers the two new IP addresses (IP2 and IP3) with its SCTP peer. Two new paths may be configured on the peer side. These may be kept as alternate paths in case the primary path becomes unavailable. In SCTP, one primary path may be configured; all other paths are for redundancy purposes.
  • the primary path using IP1 may be used for data transfer, While the primary path is operable, the two alternate paths (using IP2 and IP3) are not used. However, in the situation that IF1 becomes unavailable, the primary path may become inoperable due to its reliance on interface IF1 . SCTP reverts to the alternate paths for data transfer. In existing SCTP processing, the alternate path using IP2 may be selected. But because the selected alternate path uses the same interface IF1 as the primary path, the alternate path may also be unavailable, Existing SCTP may provide for further processing that eventually identifies a second alternate path using IP2 and interface IF1 , although the additional processing results in additional delay.
  • existing SCTP processing does not have effective logic for selecting an IP address and corresponding communication path for use as an alternate path. As illustrated by the example of FIG. 7, existing SCTP processing results in selection of a path corresponding to IP2, which may have been the first listed IP address for potential alternate paths. A better selection may have been IP3 since It uses a different interface IF2 which would have been immediately available after IF1 became unavailable.
  • Tunnels may be used In the network to re-route data traffic between the previous anchor nodes and the current one, The re-routing of traffic may be possible using, for example, DMM-enabied networks and 3GPP networks deploying branching.
  • executing or running applications may continue using the same IP addresses and may remain anchored to the same anchor nodes even
  • the device moves and connects to another network node, which becomes the current anchor node
  • an application using a TCP session may continue using the same TCP session (socket) while the device moves and becomes connected to different anchor nodes and obtains additional IP addresses.
  • the original session is maintained via use of tunneling, even though the device may have moved several times, the path of data through the network may become less than optimal.
  • an anchor node may be selected based on the shortest data path. But maintaining session continuity over time often may result in the path becoming other than the shortest data path.
  • FIG. 8 Illustrates changing path lengths resulting from session continuity as a device moves between network devices, As shown, at 1 , a device attaches to the network and obtains an IP address (IP1 ) from a first anchor node (Anchor 1 ). An application is started and a MPTCP session is created for communication with a remote peer.
  • IP1 IP address
  • An application is started and a MPTCP session is created for communication with a remote peer.
  • IP2 IP 2
  • IP2 IP 2
  • IP2 IP 2
  • IP 2 IP 2
  • the MPTCP stack on the device registers the new IP address (IP2) with its peer as a new sub-flow of type "backup" for the current MPTCP session. The backup is Intended to be used if the regular path becomes unavailable.
  • IP1 may have the benefit of preserving session continuity.
  • the path of data from the device through the network may not be the shortest path. Rather, the data may be now tunneled through Anchorl in uplink and downlink directions.
  • sub-flows are created and registered with the peer if needed. For example, sub-flows may be created and registered if more bandwidth Is needed. In the situation where an application does not need more BW than is currently available, it is possible that one IP address gets registered with the peer, in such a scenario, the shortest data path may not be used after the device connects to other PoAs/anchor nodes.
  • all registered sub-flows/IP addresses may be used by the appiication.
  • the data distribution toward the possible data paths may not consider to which anchor node the IP address is anchored since this Information may not be known by the device, e.g., the MPTCP stack and applications, nor by the MPTCP peer which takes its own decisions for the sub-flows usage.
  • FIG. 9 illustrates a scenario where existing SCTP processing results in maintaining session continuity while the data path becomes less than optimal.
  • a device attaches to the network and obtains an IP address (IP1 ) from a first anchor node (Anchor 1).
  • IP1 IP address
  • An application is started and an SCTP session is created for communication with a remote SCTP peer.
  • IP2 IP 2
  • IP3 IP 3rd IP address
  • IP1 continues to be used even though the device is attached to PoA3 and anchored at AnchorS. Session continuity Is maintained by using tunnels In the network, However, the data path may be less than optimal.
  • session continuity may be enabled by having the P-GW and IP address of the mobile device maintained over time, even under circumstances when the device moves around, !n 5G systems, different types of session continuity may be provided, and may be indicated by a Session and Service Continuity (SSC) mode value of 1 , 2 or 3,
  • SSC mode value may be an SSC mode value as defined in 3GPP TS 23,501.
  • a PDU session may be associated with a single SSC mode, which may not be changed during the PDU session.
  • SSC mode 1 may use a centralized anchor providing a fixed IP address maintained across mobility events.
  • SSC mode 2 may use distributed anchors with a break- before-make allocation of different IP addresses over time.
  • SSC mode 3 may use distributed anchors with a make-before-break allocation of different IP addresses over time,
  • MPTCP was developed before the design of session and service continuity in 5G
  • MPTCP may be adapted to 5G and may be adapted to handle IP address changes within a given SSC mode.
  • Adapting MPTCP to 5G may involve identifying and storing Information needed to handle IP address changes within a given SSC mode.
  • MPTCP processing may be adapted to address the issue of IP addresses being specific to network slices, SSC modes, data networks, etc.
  • the adaptation may further involve limiting an application from using a new IP address which is made available to the MPTCP stack.
  • Adapting MPTCP processing may also involve providing MPTCP local and remote peers with access to information that may be used by those peers.
  • the behavior of the PTCP stack may be adapted to take into account the additional processing and the information needed to support that processing.
  • MPTCP and SCTP processing may be expanded to improve selection of communication paths intended to provide, for example, additional bandwidth, backup communications, and shortened data paths.
  • MPTCP and SCTP may be adapted to collect and store additional information including, for example, information about anchors nodes, allocated IP addresses, and associated characteristics.
  • additional information collected and stored by the protocols may enable Improved and more efficient decisions regarding communication paths,
  • the additional Information enables MPTCP and SCTP processing, for example, 1) to prevent selection of IP addresses allocated over the same physical interface when the goal is to increase the available BW or create a backup path, and 2) to select IP addresses allocated over the same interface when the goal is to enable using the shortest data path.
  • MPTCP and SCTP processing may be modified to collect and store information specifying for each IP address, the corresponding interface identifier Identifying a physical interface.
  • the additional information may enable MPTCP and SCTP processing to consider both the IP address and the associated physical Interface when determining a suitable communication path that provides additional bandwidth, backup, and/or a shortest data path.
  • the MPTCP and SCTP in addition to, or as a substitute for storing an identifier of the physical interface associated with an !P address, the MPTCP and SCTP may be associated with corresponding groupings, Accordingly, in addition to or as a substitute for collecting information pairing a physical Interface used with a specific IP address, the MPTCP and SCTP may collect information assigning the IP addresses to specific groups.
  • IP addresses and corresponding sub-flows or communication paths may be based on selecting IP addresses and corresponding sub-flows pertaining to the same group or different groups, depending of the desired behavior such as, for example, providing additional bandwidth, a backup, or shortest path,
  • IP addresses associated with the same interface may be assigned to the same group
  • Associating IP addresses and corresponding communication paths with groups adds fiexibiiity as compared to directly associating an IP address with a physical interface. Any suitable criteria may be used to determine which IP address may be put into which group
  • virtual interfaces may be used on a device and may be presented to upper layers as different interfaces although using the same physical interface. Grouping the IP addresses obtained over these various virtual interfaces enables MPTCP to make clever decisions while still making use of the virtual interfaces as if they were
  • the grouping option may be used by MPTCP-aware applications which would group the IP addresses as desired.
  • MPTCP may use the physical interface value and not the group identifier.
  • the MPTCP processes which may implement the MPTCP stack and protocol and operate on mobile devices, may collect and store information for a MPTCP session (e.g., each MPTCP session).
  • the collected information may be known by both MPTCP peers that are part of an MPTCP session, information collected locally by one peer may be sent to the other peer via MPTCP specific messages or other suitable means,
  • the MPTCP processes may collect and store sub-flow identifiers associated with an MPTCP session.
  • an MPTCP process may store a list of IP addresses corresponding to
  • the MPTCP process may also store in its stack an interface Identifier corresponding to an interface over which the sub- flow designated by the IP address is carried.
  • Each interface identifier may correspond to an interface such as, for example, a cellular, WiFi, or Ethernet interface.
  • the MPTCP processes may store a group identifier
  • the group identifier may represent or correspond to an interface on the device. In a scenario that a device has multiple interfaces of the same type, these interfaces may be associated with different group identifiers. In the scenario where a device has multiple interfaces that use the same physical interface (e.g., sharing BW to reach the access network), the interfaces may be associated with the same group identifier, It will be appreciated that a group identifier may represent any suitable grouping or characteristic (e.g., one or many) that may be useful to the PTCP process in selecting a sub-flow. For example, the group identifier may correspond to a physical interface, a logical interface, or slice Identifier,
  • the MPTCP processes may also collect and store a Type in relation to each IP address and its corresponding sub-flow or communication path.
  • the Type may be used to designate whether a sub-flow or communication path is a REGULAR or BACKUP.
  • REGULAR indicates the corresponding IP address/sub-flow is used for regular data transmission.
  • BACKUP indicates the corresponding IP address/sub-flow is used as a backup,
  • the MPTCP process may further collect and store a State value in relation to an IP address and its corresponding sub-flow or communication path.
  • the State may be used to designate whether or not the sub-flow is directly connected to its anchor node.
  • the State information may be used by a MPTCP process to determine whether a sub-flow provides the shortest data route.
  • the MPTCP processes may be programmed to implement various rules or logic relating to selection of sub-flows using the collected data regarding the available sub-flows.
  • the MPTCP processes may be programmed such that, in the instance where bandwidth is to be increased, sub-flows of a type REGULAR may be selected, and sub-flows pertaining to the same interface or group identifier as the current sub-flow may not be selected.
  • the MPTCP processes may be programmed to use the collected information in selecting a sub- flow to operate as a backup.
  • the MPTCP processes may be programmed such that a sub- flow of type BACKUP may be used as a fallback to a sub-flow pertaining to a different interface identifier or group identifier.
  • the MPTCP may select such a sub-flow as the preferred backup sub-flow.
  • the MPTCP process may be programmed such that a sub-flow of type BACKUP may be used as a fallback to a sub- flow pertaining to the same interface identifier or group identifier.
  • the MPTCP may be programmed to identify such a backup sub-flow as the least preferred choice and may be used if there are no other sub- flows pertaining to a different physical interface or group identifier.
  • the MPTCP may be further programmed such that a sub-flow of type BACKUP may be used as a fallback to a sub-flow of type BACKUP, although, the preferred case may be that the associated sub-flows (e.g. REGULAR, BACKUP1 , BACKUP2) may have different interface identifiers or group identifiers.
  • the MPTCP processes may be programmed to use the collected information in selecting a sub- flow or communication interface thai provides the shortest data path.
  • the MPTCP may be programmed to identify sub-flows with state DIRECT for data transfer.
  • the MPTCP may be further programmed to select a sub-flow with a state DIRECT that may also be associated with the same interface or group identifier as is currently being used,
  • the sub-flow with these characteristics typically offers an optimal, or shortest, data path,
  • the SCTP processes which may be programmed to implement SCTP functionality including maintaining an SCTP stack and implementing SCTP related functionality, may collect and store information for an SCTP session.
  • the collected information may be known by both SCTP peers that are part of an SCTP session. Where Information is local to one peer, it may be sent to the related peer via SCTP specific messages or using any other suitable mechanism.
  • SCTP processes may collect and store communication path IP addresses associated with an SCTP session.
  • the IP address may be viewed as corresponding to sub-flows or communication paths.
  • the SCTP process may also store in its stack an interface identifier corresponding to an interface over which the communication path designated by the IP address is carried.
  • An (e.g., each) interface Identifier may correspond to an interface such as, for example, a cellular, WIFI, or Ethernet interface,
  • a group identifier may be stored in relation to the IP address/communication path identifier.
  • the group identifier may represent or correspond to an interface on the device.
  • the interfaces may be associated with different group identifiers.
  • the interfaces may be associated with the same group identifier.
  • a group identifier may represent any suitable grouping or characteristic that may be useful to the SCTP process in selecting a communication path.
  • the group identifier may correspond to a physical interface, a logical interface, or slice identifier.
  • the SCTP processes may also collect and store a Type in relation to an IP address (e.g., each IP address) and its corresponding sub-flow or communication path.
  • the Type may be used to designate whether a sub-flow or communication path is a PRIMARY or BACKUP.
  • a designation as PRIMARY indicates the corresponding IP address/communication path is used as the primary path for data transmission.
  • a designation as BACKUP indicates the corresponding IP address/communication path is used as a backup.
  • the SCT! :> process may further collect and store a State in relation to an IP address (e.g., each IP address) and Its corresponding sub-flow or communication path.
  • the State may be used to designate whether or not the communication path is directly connected to its anchor node,
  • the State Information may be used by an SCTP process to determine whether a communication path provides the shortest data route.
  • the SCTP processes may be programmed to implement various rules or logic relating to selection of communication paths using the collected data regarding the available communication paths. For example, the SCTP processes may be programmed to perform alternate path selection based upon rules or logic. An SCTP process may be programmed to select an alternate path as soon as more than one IP address is available. The SCTP process may identify alternate paths which the SCTP may record in preference order. The preferred alternate path may use an IP address associated with a different group or interface Identifier than the IP address used for the primary path, When the IP address associated with the primary path changes, the backup paths are re-evaluated and may be modified to follow the rules noted herein,
  • the SCTP processes may be further programmed to select the shortest data path as the primary path, In the primary path selection, an IP address with state DIRECT may be used for the primary path. An IP address of state DIRECT which is used for the primary path and that is modified to state INDIRECT may stop being used. Another IP address of type DIRECT and of the same interface identifier or group identifier may be selected instead to be the primary path.
  • existing Router Advertisement or DHCP messages may be modified to provide more information to the device about the offered IP addresses, For example, the messages may be modified to indicate if an IP address may be directly or indirectly (e.g., via tunneling) reachable. This information may be used, for example, to enable the shortest data path usage.
  • the information about the offered IP address may be stored using one of the reserved bits in a Router Advertisement (RA) message as illustrated in FIG, 10, As shown, a 1-bit "Direct" or D bit may have been added. When set to 1 , it may designate a direct connection, When the bit is set to 0, it may designate an indirect connection,
  • RA Router Advertisement
  • a new bit may be defined in the expanded flags option field in the RA message.
  • FIG. 11 depicts an example message format. As shown, the D bit is comprised in the options field.
  • An option may be added to be used with the DHCP message that carries the IP address aiiocated/advertised to the client,
  • FIG. 12 depicts an example embodiment, A new code "IP address state" may be defined. As depicted in FIG, 12, the !P address state code may be OPTION .. ADDR .. STATE. When "D" is set to 1 , the flag indicates directly connected, When the flag is set to 0, it may not be directly connected (e.g., connection is via tunneling).
  • Existing message formats may be expanded. Such existing message formats may be found in IETF RFC 3315, Dynamic Host Configuration Protocol for IPv6 (DHCPv6).
  • a flag for carrying the IP address state may be added to the DHCP message.
  • FIG. 13 depicts an example implementation.
  • the "D" bit may be a 1-bit "Direct" flag. When set to 1 , the flag may indicate a direct connection. When set to 0, the flag may indicate that the connection is indirect (e.g., via tunneling).
  • Existing DHCP message formats may be expanded. Existing DHCP message formats may be found in IETF RFC 2131 , Dynamic Host Configuration Protocol.
  • a new prefix or IP address may be obtained from the anchor node with the "D" bit set (e.g., indicated a direct connection). Previous prefixes or IP address may be advertised using any of the embodiments described herein with the state set to indirect ("D" bit set to 0).
  • the MPTCP socket API may be enhanced to allow for additional information to be stored and used by the MPTCP in creating and selecting sub-flows.
  • the MPTCP stack may manage (e.g.
  • MPTCP autonomously manages) the sub-flows that are associated with an MPTCP session.
  • MPTCP may request to be aware of the available IP addresses (e.g. locally on the device and remotely on the peer side) and their associated physical interface (or group identifier as discussed herein).
  • the following socket APIs are examples from the existing socket API calls.
  • the APIs may be replaced by any other APIs (e.g., setsockopt or getsockopt) thai may provide the requested functionality.
  • the APIs may be called by any MPTCP-aware application or system functionality such as, for example, a connection manager or interface manager, that may expose (or not) IP addresses to MPTCP stack when desired. They may be applied per socket or globally to the MPTCP stack.
  • the MPTCP API may include mptcp_set_ip (sd, IP addr, physical interface or group Identifier, state). This API may be called: (a) to Inform the MPTCP stack about a new available IP address which may be used to create a sub-flow; (b) to associate the IP address with a physical interface or group identifier; and (c) to update the state of a known IP address.
  • the mptcp_set_ip API call may take several parameters.
  • Parameter "sd” may refer to a socket descriptor. It may identify a specific socket, The parameter may be omitted, in which case the added IP address applies to MPTCP globally, and thereby, to all MPTCP sessions. If specified, the IP address may be made available to this specific socket.
  • the parameter "physical interface or group identifier" may be obtained, for example, from network advertisements or by using system built-in APIs, For system calls, values for this parameter may be obtained from "ipeonfig" which provides a list of IP addresses and the corresponding interfaces. For network indications, indication messages may be received on the interface to which they apply. For example, values may be received as specified herein in connection with the discussion of network enhancements. For group identifiers, it may be assumed that the group identifier is generated by the application using the socket APi call. The application may know about the interface and may use network indications or system calls. If logical interfaces are used on top of physical Interfaces, the corresponding physical interface is retrieved, for example, from the logical interface value which may include the physical interface information in its construct.
  • the "state” parameter indicates whether the device is directly connected to the anchor that provided the IP address or whether the device is indirectly connected (e.g., via a tunnel).
  • the information may be obtained using the network enhancements as described herein.
  • the MPTCP APi may also include mptcp_get_ip (sd, IP addr, physical interface or group identifier, state).
  • the API may be called to (a) get the state and (b) physical interface or group identifier of a known IP address.
  • the "sd” parameter refers to a socket descriptor and identifies a specific socket. The parameter may be optional. If specified, and if no IP address may be specified, then all IP addresses associated with this socket are returned. It will be appreciated that either or both "sd" or "IP addr" may be specified.
  • IP addr reiers to an IP address. This parameter may be optional, if specified, information related to this specific IP address may be returned. If omitted, one or more IP addresses related to the specified socket may be returned, Again, either or both "sd" or "IP addr" may be specified,
  • the "Physical interface or group identifier" and “state” parameters may be output parameters of the API
  • the MPTCP API may include TCP_MULTIPATH_ADD.
  • the existing TCP_MULTIPATH_ADD API call may be extended to specify, in addition to the IP address and port, the associated physical interface identifier or a group identifier, and the state (e.g., direct or indirect).
  • the API call may take data specifying, for example, a local source address, a port, and a physical interface identifier or group identifier.
  • the MPTCP API may further include TCP_ U LTI PAT H_STATE which causes the MPTCP to set or modify the state of an IP address that may be known by the MPTCP.
  • the call may be used to set the state of a sub-flow to either DIRECT or INDIRECT.
  • the call may require specifying the local source address and the appropriate state of the source address
  • MPTCP socket APIs may be the existing MPTCP socket APIs that may be found in IETF RFC 6897, Multipath TCP (MPTCP) Application Interface
  • SCTP socket API may be modified or enhanced to allow for assigning and modifying the state (direct/indirect) associated with an IP address.
  • an API may be defined that operates to specify the interface or group identifier.
  • the SCTP socket API may be modified to allow for setting a state associated with an IP address (e.g., specific IP address).
  • An example structure for setting the state may be defined as sctp_setipstate which may be defined as follows:
  • ssp_addr this parameter is the IP address to which the state is set state: this is the state (direct/indirect)
  • the SCTP socket API may further be modified to allow for setting the interface or group identifier associated with a specific IP address.
  • An example structure for setting the interface or group identifier may be defined as sctp_ setipgroupid, which may be defined as follows:
  • this parameter is the IP address to which the group (or interface) identifier is set
  • the existing MPTCP protocol may be modified or enhanced to aiiow for Information about sub- flows to be shared between MPTCP peers, For example, in the processing described herein, the MPTCP peers may be enabled to know for an IP address (e.g., each IP address), an associated physical Interface or group identifier, and a state, e.g., whether the connection is a direct or indirect connection, if the physical interface or group identifier may not be specified, the IP addresses which are advertised may be assumed to be on different physical interfaces or associated with different group identifiers.
  • IP address e.g., each IP address
  • an associated physical Interface or group identifier e.g., an associated physical Interface or group identifier
  • a state e.g., whether the connection is a direct or indirect connection, if the physical interface or group identifier may not be specified, the IP addresses which are advertised may be assumed to be on different physical interfaces or associated with different group identifiers.
  • MPTCP protocol messages may be modified to support the functionality described herein.
  • the protocol may be an existing protocol such as that found in IETF RFC 6824, Milti_Path TCP.
  • the MPTCP protocol message P_CAPABLE may be modified as follows.
  • a field for group identifier (or physical interface identifier)
  • the physical interface or group identifier may be deduced based on the IP address format:
  • a flag (D) - state set to direct (1 ) for directly connected to anchor node; otherwise, not direct (0) for indirect connection with anchor node reachable via e.g. tunnel
  • FIG. 14 depicts an example modified message format for MP_CAPABLE. As shown, a Group ID "D" has been added,
  • the MPTCP message MPJOIN may be modified as follows:
  • FIG. 15 depicts an example modified message format for MP_JOIN for use in an initial synchronization. As shown in FIG. 15, the length may be specified as being 16 and a Group ID "D" has been added.
  • FIG. 16 depicts an example modified message format for MP . JOIN for use in responding to a synchronization or acknowledgement message, As shown, the length is specified as being 20 and a Group ID "D" has been added.
  • the MPTCP message MP_PRIO may be modified as follows:
  • sub-flow may change from direct to not direct or the reverse
  • FIG. 17 depicts an example modified message format for MP ... PRIO. As shown, a flag "D" for the state has been added.
  • the existing SCTP protocol may be modified or enhanced to allow for information about sub- flows and available IP addresses to be shared between SCTP peers.
  • Parameter types e.g., new parameter types
  • the new parameter types may appear in IN IT, !NIT-ACK, and ASCONF messages or chunks.
  • the following new parameter types may be defined: Set IP Address State and Set IP Address Group (or Interface).
  • the new parameter Set IP Address State may comprise the following information:
  • This parameter may already exist and may represent the IP address to which the state may apply
  • FIG. 18 depicts an example format for Set IP Address State, which may be a new parameter.
  • the new parameter Set IP Address Group (or Interface) may comprise the following information:
  • This parameter may already exist and may represent the IP address to which the interface or group identifier may be associated interface or Group Identifier:
  • FIG. 19 depicts an example format for Set IP Address Group (or Interface), which may be a new parameter.
  • the disclosed methods and systems may be facilitated by enhancements to existing network indications, MPTCP/SCTP socket APIs and MPTCP/SCTP protocols.
  • Some of the proposed modifications relate to IP address and prefix state, including, for example, to noting whether a path is direct or indirect,
  • a preferred IP address/prefix may be specified instead of or in addition to employing direct/indirect state.
  • a 'P' bit may be used instead of, or in addition to using the ' bit. Setting the ' ⁇ ' bit to 1 may mean the related IP address/prefix Is preferred over others which have a V bit set to 0,
  • the 'P' bit may be represented as a set of bits that could be utilized to indicate a relative preference order for IP addresses/prefixes, For example, a length of two bits for 'P' could represent four levels of preference.
  • Preference ranking may be used by MCTCP/SCTP peers when selecting interfaces. This feature may apply to any of the previous enhancements, such as, network indications, MPTCP and/or SCTP socket APIs, and MPTCP and/or SCTP protocols,
  • the enhanced collection and storing of data relating to communication paths or sub-flows allows for improved management of communication path selection.
  • MPTCP processes use the additional data specifying interface Identifiers or group identifiers associated with an IP address (e.g., each IP address) to select IP addresses that may be more likely to provide additional bandwidth or provide reliable backup.
  • SCTP processes use the additional data specifying interface identifiers or group identifiers associated with an IP address (e.g., each IP address) to select IP addresses associated with communication paths that provide reliable backup to a primary path.
  • both the IP address and the associated physical interface may be considered for purposes of selecting a path for additional bandwidth or backup. This may provide improved processing, for example, by enabling additional Information stored In the MPTCP stack.
  • the additional information may include, for example, the additional information regarding corresponding anchors nodes, allocated IP addresses, and corresponding physical interface
  • the enhanced data may be collected using any suitable means including, for example, via socket API's as discussed herein. Since both endpoints of a MPTCP session may create new sub-flows, the collected information may be shared between peers.
  • the MPTCP protocol may rely upon the collected data to implement or enforce rules, as described herein, to create and select sub-flows or communication paths. For example, for an BW management handling, the MPTCP stack processes may follow rules when creating sub-flows to Increase the available BW for a specific application that has opened a TCP session. The rules may prevent the creation of sub-flows using IP addresses allocated over the same physical interface as the existing sub- flow, or associated with the same group as the existing sub-flow for which additional bandwidth may be requested,
  • FIG. 20 An example process for MPTCP selection of a communication path for additional bandwidth is depicted in FIG. 20.
  • an application using TCP executes on a device having two physical interfaces such as, for example, W ' iFi and cellular.
  • the device further has MPTCP operating thereon,
  • the device connects to a network which supports multi-homing (e.g., multiple IP addresses allocation over the same interface) and which may have anchors distributed in the network, e.g. at the edge of the network, deep in the network, centrally located, etc., that support session continuity (e.g., via tunneling between the anchors), While the device moves and connects to different anchor nodes, a request for more bandwidth may be detected.
  • the MPTCP processes use information collected about the various potential communication paths or sub-flows, including the relevant interfaces, to select a sub-flow to provide additional bandwidth.
  • the device connects to PoAI using a first interface (IF1).
  • the MPTCP stack is updated to identify the IP address, IP1 , of the communication path and to reflect that IP1 may have been allocated over interface IF1 ,
  • the MPTCP stack may be updated to reflect that the IP1 may be associated with a grouping such as, for example, Group A.
  • the information may be received and stored in the MPTCP stack using any suitable processing,
  • the information may be received and stored using API socket operations such as, for example, mptcp_set_ip() and/or
  • TCP_MULTIPATH_ADD An application, designated APP1 in FIG, 20, begins executing on the device, The application creates a TCP session, The TCP creation may be intercepted by the MPTCP stack which may create an MPTCP session with its remote peer, MPTCP peer, using any suitable mechanism such as, for example, a MP_CAPABLE message.
  • the MPTCP stack may generate a first sub-flow, designated sub- fiowl in the FIG, and may associate the sub-flow with IP1 ,
  • the MPTCP stack may associate the sub-flow and IP1 with either an identifier (IF1 ) for the physical interface over which the sub-flow communications occur, or an identifier for a group with which the flow is to be associated.
  • IF1 an identifier
  • IP1 and the sub-flow1 may be stored In association with groupA.
  • GroupA may be associated with IF1 and may be specified instead of IF1 so as to make the sub-flow creation more flexible, it will be appreciated that IFI may be directly specified instead of mapping it to a group identifier.
  • the device may move and attach to PoA2, rather than PoAI , using a handover while still using communication via interface IFI .
  • Another IP address IP2 may be obtained from PoA2.
  • the device may update its MPTCP stack with the new IP address IP2 and may associate IP2 with groupA as IP2 may also be associated with the same communication interface. While MPTCP updates the MPTCP stack to reflect SP2, in an example scenario, the device may not begin communications using the new IP address. In the example scenario, the new IP address (IP2) may not be shared with the MPTCP peer.
  • the device may connect to PoA3 using another interface, IF2.
  • a third IP address (IP3) may be obtained by the device from PoA3 and may be associated with IF2 and groupB.
  • IP3 IP address
  • additional bandwidth may be requested to serve the running application (APP1 ) on the device.
  • the MPTCP stack on the device may determine to create a new sub-flow to be associated with the existing MPTCP session to increase the avaiiabie bandwidth for the application (APP1 ).
  • the MPTCP stack may determine based on the previously received and stored data that the same interface, IF1 , or group identifier, groupA, is used for IP1 and IP2.
  • the MPTCP stack determines, based on the stored data, that because IP2 uses the same interface, IF1 , or is associated with the same group, groupA, IP2 may not be a valid candidate to Increase bandwidth, Rather, the MPTCP stack may determine that because IP3 Is associated with a different interface, IF2, or is associated with a different group, groupB, IPS may be a better candidate to improve bandwidth and selects IP3.
  • a new sub-flow is created and added to the existing MPTCP session using a MP .. JOIN message, Thereafter, APP1 data traffic may be distributed over the two sub-flows corresponding to IP1 and IPS.
  • the improved MPTCP processing for selecting a backup communication path or sub-flow may involve consideration of the IP address of potential sub-flows and the physical interface or group identifier associated with a sub-flow (e.g. each of the sub-flows),
  • the improved processing may be enabled by the additional information stored In the MPTCP stack including, for example, the additional information regarding corresponding anchors nodes, allocated IP addresses, and corresponding physical Interface characteristics,
  • the enhanced data may be collected using any suitable means including, for example, via socket API's as discussed herein, Since both endpoints of a MPTCP session may create new sub-flows, the collected information may be shared between peers,
  • the MPTCP protocol may rely upon the collected data to implement or enforce rules, as referenced herein, to create and select sub-flows or communication paths.
  • the MPTCP stack follows rules when creating and selecting sub-flows to serve as backups or alternative flow paths.
  • the rules prevent the creation of backup sub-flows using IP addresses allocated over the same physical interface as the existing sub-flow, or associated with the same group as the existing sub-flow for which a backup path may be needed.
  • the rules enforced by the MPTCP stack stipulate that the creation of backup sub-flows may use IP addresses allocated over a different physical interface, or associated with a different group, as the existing sub-flow In the MPTCP session for which a backup path may be requested.
  • a backup path may be created over the same physical interface as the existing sub-flow.
  • a potential backup sub-flow is not the preferred backup path.
  • Many backup paths may be defined for an MPTCP session and may be organized and selected for use in a preferred order,
  • an application using TCP may execute on a device having two physical interfaces.
  • the device supports MPTCP
  • the device connects to a network which supports multi- homing (e.g., multiple IP addresses allocation over the same interface) and which has anchors distributed in the network, e.g., at the edge of the network, deep in the network, centrally located, etc., that support session continuity (e.g., via tunneling between the anchors).
  • a need for a backup path may be detected by the MPTCP stack.
  • the MPTCP stack processes use the information collected from the various potential communication paths or sub-flows, including the associated interfaces, to select a backup sub-flow,
  • the device may connect to PoA1 using a first interface (IF1 ).
  • the MPTCP stack may be updated to identify the IP address, IP1 , of the communication path and to reflect that IP1 may be allocated over IF1 .
  • the MPTCP stack may be updated to reflect that IP1 is associated with a grouping such as, for example, Group A.
  • the information may be received and stored in the PTCP stack using any suitable processing. For example, the information may be received and stored using API socket operations such as, for example, setipQ and/or TCP__MULT!PATH__ADD,
  • An application, designated APP1 in the FIG, begins executing on the device. The application creates a TCP session.
  • the TCP creation may be intercepted by the MPTCP stack which creates an MPTCP session with its remote peer, MPTCP peer, using any suitable mechanism such as, for example, a MP_CAPABLE message.
  • the MPTCP stack may generate a first sub-flow, designated sub-flow1 in the FIG., and may associate the sub-flow with IP1 .
  • the MPTCP stack may associate the sub-flow with either an identifier (!FI) corresponding to the physical interface over which the sub-flow communications are made, or an identifier for a group with which the flow may be associated,
  • the device may move and may attach to PoA2, rather than PoAI using a handover while still communicating over interface IF1.
  • Another IP address, IP2 may be obtained from PoA2,
  • the device may update its MPTCP stack with the new IP address, IP2, and may associate IP2 with groupA as ⁇ 2 may also be associated with the same communication interface.
  • MPTCP processes update the MPTCP stack to reflect IP2, in an example scenario, the device may not begin communications using the new IP address, In the example scenario, APP1 traffic continues to be transmitted using IP1 , although being sent via PoA2 and Anchor 2. The traffic is tunneled through Anchor 1 to maintain session continuity. The tunneling is not illustrated to maintain visual clarity of the FIG.
  • the device may connect to PoA3 using another interface, IF2.
  • a third IP address, IP3, may be obtained by the device from PoA3 and may be associated with IF2 and groupB.
  • the MPTCP stack may determine to create a backup sub-flow for the existing MPTCP session.
  • the MPTCP stack may determine based on the previously received and stored data that the same interface, IF1 , or group identifier, groupA, is used for IP1 and IP2,
  • the MPTCP stack may determine, based on the stored data, that because IP2 uses the same interface, IF1 , or is associated with the same group, groupA, IP2 may not be a valid candidate for being used as a backup sub-flow.
  • the MPTCP stack may determine that because IP3 is associated with a different interface, IF2, or is associated with a different group, groupB, IP3 may be a good candidate to serve as a backup and selects IP3, A new sub-flow may be created and added to the existing MPTCP session using a MP_JOIN message. Thereafter, if APP1 data traffic is disrupted due to a failure in the existing sub-flow, traffic may be re-directed to sub-flow 2 (IF3) using IP3,
  • SCTP like MPTCP, the enhanced collection and storing of data relating to communication paths or sub-flows may allow for improved management of communication path selection.
  • SCTP processes may use the additional data specifying interface identifiers or group identifiers associated with an IP address (e.g. each IP address) to select one or more IP addresses associated with
  • FIG. 22 An example process tor SCT ' P selection of a backup communication path is Illustrated in FIG. 22.
  • the device may connect to PoA1 using a first interface, IF1 .
  • An IP address, IP1 may be obtained from PoA1 , IP address IP1 may be anchored at Anchorl ,
  • An SCTP application begins executing.
  • An SCTP may be created with an SCTP peer.
  • the IP address ⁇ 1 and an identifier of the corresponding interface IF1 may be stored by the SCTP process.
  • IP1 may be shared with the SCTP peer using an IN IT message.
  • the group identifier may be specified on the message, It will be appreciated that in another embodiment, the physical interface IF1 may be specified in the communication to the SCTP peer, The SCTP peer may save information pairing !PI with the received group or interface Identifier.
  • This initial path may be designated as the primary path for the session and information relating to the path and its designation as the primary path is stored at least at the SCTP peer.
  • the device may move and connect to another Po.A, PoA2, using the same interface (IF1).
  • the network supports multi-homing, Accordingly, a new IP address, IP2, may be allocated to the device (anchored at Anchor2) in addition to IP1 .
  • the network may provide session continuity. Accordingly, a communication tunnel may be created between Anchor2 and Anchorl so that the traffic using IP1 may be routed.
  • the local SCTP stack may be updated to reflect the new IP address, IP2, and its relationship with physical interface IF1 ,
  • the peer SCTP may also be informed of the new IP address (IP2) along with information specifying that the IP address is associated with groupA, the same group as is associated with IP1. In another embodiment, the information may specify the IP address is associated with interface IF1 .
  • the Information may be communicated to the SCTP peer using an ASCONF message,
  • the device may move again and may connect to PoA3 using a different interface, IF2, PoA3 may assign IP address ⁇ 3 to the device which is anchored at Anchor3.
  • the local SCTP stack may be updated to reflect that iP3 has been added and that it corresponds to physical interface IF2.
  • the peer SCTP may also be informed of the new IP address (IP3) along with information specifying that the IP address is associated with groupB, In another embodiment, the information may specify the IP address may be associated with interface IF2, The information may be communicated to the SCTP peer using an ASCON message.
  • the SCTP processes may create an alternate path associated with IP3 and designate the created path as the preferred alternate path (over the path associated with IP2) because it may use a different group identifier, e.g., groupB, (or different interface identifier in another embodiment), than that used by the existing primary path corresponding to IP1 which is associated with groupA.
  • groupB group identifier
  • the SCPT processing may identify the alternate path associated with IPS and groupB to be used, Data relevant to APP1 may continue to be transferred, but via IF2 and IP3, MP 1 CP Data Path Distance Management
  • MPTCP and SCTP In addition to collecting and processing data for purposes of selecting communication paths to provide additional bandwidth or backup, also may be adapted to use collected information to identify and select a shortest data path.
  • Using sub-flows over the same interface may enable the shortest data path usage for TCP-based applications (e.g. all TCP-based applications) running on a device, and not just the newly started applications. Selecting a better data path (or combination of data paths) contributes to providing improved quality of experience (QoE) to the user.
  • MPTCP may be used in networks permitting usage of multiple IP addresses/anchors over a single Interface and may enable the usage of the shortest data path, even for already running applications anchored at nodes reachable via tunnels in the network.
  • DMM may enable a device to be anchored simultaneously at multiple points In the network, providing session continuity for the applications running on the device while the device is moving.
  • the continuity may be provided over a single physical interface IF.
  • the device may accumulate multiple IP addresses associated with the same Interface, and maintain session continuity of the running applications.
  • the executing applications continue using the same anchor point/IP address, but may not use the shortest data path.
  • Continuity may be preserved, but the shortest data path may not.
  • New applications that begin executing use the latest IP address that has been allocated in order to use the shortest data path in the network.
  • MPTCP may enable both session continuity and shortest data path usage for already running applications.
  • the MPTCP layer running on the device has data stored thereon regarding, and is aware of the IP address (IP) to interface identifier (IF) mapping as well as the IP address state, e.g., whether the connection provided by the IP address may be direct or indirect.
  • IP address IP
  • IF interface identifier
  • the MPTCP peer may also have this same information.
  • the address state may be deduced.
  • DMM may be used to Identify advertised IP addresses as deprecated; validity time may be set to 0 on the advertisement message, instead of modifying the RA or DHCP messages, the deprecated state may be used to deduce the state (e.g., deprecated is interpreted as "indirect” state).
  • the MPTCP layer may create sub-flows using IP addresses associated with the same interface to Identify and use the shortest data path selection, Indeed, a TCP-based application running on the device may keep using the same TCP session while the MPTCP layer may, transparently to the device, send the uplink (UL) data over the sub-flow which is anchored at the current anchor node (e.g., having DIRECT state) which may make use of the shortest data path.
  • the data is sent in the network using the latest IP address assigned to the device over this interface.
  • receiving data using this IP address may be permitted as the remote peer may be running MPTCP and may be aware that this IP address is associated with this MPTCP session.
  • the MPTCP stack may have sufficient information and processing logic to create sub-flows over a single interface to enable using the shortest data path.
  • FIG. 23 depicts an example process for selecting the shortest data path in a system employing MPTCP
  • the mobile device may be connected to PoAI and anchored at Anehorl , Prefixl ::/64 may have been obtained from this anchor and, using this prefix, the device may configure an IP address, such as IP1 .
  • An application designated APP in FIG, 23, may be started and may create a TCP session.
  • MPTCP may be running on the device and starts an MPTCP session using a TCP session associated with IP1 over IF1 (sub-fiow1 ).
  • "group A" may be shared with the peer instead of the interface identifier, although other embodiments may share the interface identifier.
  • Information identifying IP1 and corresponding interface IF1 may be stored by the MPTCP processes on the device.
  • the device may move out of PoA1 coverage and connect to PoA2.
  • a second prefix may be obtained from Anchor2 and IP address IP2 may be configured.
  • the first prefix may also be advertised by Anchor2, optionally specifying indirect state.
  • Anchor2 may be aware of this information (e.g., IP1 allocated to the device) since the various anchors in the network share IP address allocation for session continuity handling. The information may be shared, for example, using a common database. If the IP address state may not be advertised by Anchor 2, the PTCP stack may deduce it by learning that the device may be connected to a new anchor - making the connection with the previous anchors indirect.
  • the MPTCP stack may create another TCP session and may associate it with the existing MPTCP session (sub-flow2) with its peer.
  • the MPTCP may determine the shortest path by identifying the IP address that may have a direct connection and which may be associated with the existing physical interface or group. Since the shortest data path may be obtained via Anchor2, which may be the currently connected node, PTCP may determine to use sub-flow2 for the data exchange over the MPTCP session.
  • the two sub-flows that have been created and associated with the MPTCP session may be of REGULAR type and may be associated with the same interface, IF1.
  • the MPTCP stack determines that this sub-flow, e.g., the one with a regular connection type and using the existing physical interface or grouping, may be selected to keep using the shortest data path.
  • the information may be communicated to the MPTCP peer, so that the peer may use the information and may not request using the sub-flows as backups or for bandwidth increases, but rather may continue using the shortest data path.
  • the device may again move and attach to PoA3, anchored at Anchors.
  • a 3rd IP address, IP3, may be configured.
  • the MPTCP processes may create a new TCP session and associate it with the existing MPTCP session, such as, sub-f!ow3.
  • MPTCP may determine to use sub-flow3 for the data exchange over the MPTCP session.
  • the MPTCP processing updates the previously used sub-flow (e.g., sub-f!ow2) to "indirect" state.
  • Sub-flow3 is now the "direct" sub-flow to be used for data transfer,
  • the PTCP peer receives and updates its Information reflecting the changes.
  • the regular mechanism for session continuity handling e.g., tunnels
  • traffic sent over MPTCP may end-up being tunneled for a short time in the HO-MPTCP sub-flow
  • the MPTCP stack running on the device determines which sub-flow may be used for the data transfer.
  • the corresponding remote peer which may be, for example, an application server, may mimic the device and use the same sub-flow.
  • TCP sessions and IP addresses which are not used may eventually be closed/released by the MPTCP stack on the device,
  • the described processing applies to any type of network (e.g., DMM or 5G implementing the BP functionality, etc) that enables the allocation of multiple IP addresses over the same interface.
  • the anchors shown in FIG 23 may be. for example, D-GW (DMM anchor) or BP (UPF implementing branching point and PDU session anchor functionalities), or may be centrally located in the core network.
  • SCTP like MPTCP, may be used to collect and process data for purposes of identifying and selecting a shortest data path
  • the SCTP stack may be adapted to register one primary path and multiple alternate paths with its SCTP peer, If the device is performing handovers and becomes anchored at different nodes over the same interface, session continuity of the primary path may be preserved by using tunnels in the network. In other words, data transfer using the primary IP address may be supported, in such an instance, and using existing SCTP capabilities, the shortest data path may not be used for data transfer,
  • SCTP may be modified to enable selection of the shortest data path.
  • the SCTP processes may modify a PRIMARY path's state to "indirect.” and set the state of the directly connected data path to "direct.”
  • the primary path selection may be performed based on the stored information and the shortest data path may selected by identifying the "direct" IP address for the primary path,
  • FIG, 24 depicts an example process for enabling shortest data path usage in a system employing SCTP
  • the device may be connected to PoA1 and anchored at Anchorl .
  • Prefix " ! ::/64 may have been obtained from Anchorl .
  • the device may use the prefix to configure an IP address, such as IP1.
  • An application, designated APP in FIG. 24, may have been started and may initiate the creation of an SCTP session.
  • the SCTP processes may create an association between IP1 and groupA (or interface identifier !F1). The association may be communicated to the SCTP peer.
  • groupA may be shared with the peer instead of the interface identifier, but the interface identifier may have been shared.
  • the peer SCTP may also send its available IP addresses with associated group identifier and state.
  • the SCTP messages exchanged between the device and the SCTP peer are not ail shown.
  • ECHO messages are not shown on the FIG. it will be appreciated that the SCTP session information kept at the peer and illustrated on the FIG. is a subset of all the information that may be stored. Also, it will be appreciated that the information illustrated at the SCTP peer In the F!G. 24, is what may be kept at 3 after the reception of the ASCONF message,
  • the device may move out of PoA1 coverage and connects to PoA2,
  • a second prefix may be obtained, on the same interface as IP1 (groupA), from Anchor2 this time and IP address (IP2) may be configured.
  • the first prefix may also be advertised by Anchor2, optionally specifying indirect state.
  • Anchor2 may be aware of this information (e.g., IP1 allocated to the device) since the various anchors in the network share IP addresses allocation for session continuity handling.
  • the anchors may share a common database
  • the SCTP stack or SCTP application may deduce it by learning that the device is connected to a new anchor - making the connection with the previous anchors indirect
  • the SCTP stack may add the newly allocated IP address (IP2) to the existing SCTP session using an ASCONF message
  • SCTP may determine the shortest path by identifying the IP address that has a direct network connection and which is associated with physical interface or group that is currently selected, Since the new IP address may have a direct network connection and may be associated with the same group Identifier (e.g., groupA in this example), the shortest data path is obtained via Anchor2 (currently connected node),
  • the SCTP stack on the mobile device and the SCTP peer both determine to use !P2 for the data exchange over the SCTP session,
  • the STP processes may select the data path using IP2 as Primary path instead of !PI .
  • IP2 offers a direct network connection and is associated with the presently selected groupA.
  • the IP1 state may be modified to "indirect" in the same message (ASCONF), A separate message may also have been used, [0241]
  • the device may move and may become attached to PoA3, anchored at Anchor3.
  • a third IP address (!P3) may be configured.
  • the first prefix and second prefixes may also be advertised by Anchor3 (optionally specifying indirect state, as specified in 2).
  • the SCTP stack may add the newly allocated IP address (IP3) to the existing SCTP session using ASCONF message.
  • the SCTP stack and its peer both may determine to use IP3 for the data exchange over the SCTP session.
  • the SCTP processes may select the data path using IP3 as Primary path Instead of IP2.
  • the SCTP processes may modify the state of IP2 to indirect.
  • the regular mechanism for session continuity handling may continue to be used In the network to handle traffic.
  • minima! traffic sent over SCTP streams may end up being tunneled for a short time in the HO-SCTP sub-flow creation/configuration transition time.
  • SCTP sessions and IP addresses which are not used may eventually be closed/released by the SCTP application or stack on the device, In this case, the SCTP may be informed of the released IP address.
  • the described processing applies to any type of network (e.g. D or 5G implementing the BP functionality, etc.) that may enable the allocation of multiple IP addresses over the same Interface
  • the anchors shown in FIG, 24 may be, for example, D-GW (DMM anchor) or BP (UPF implementing branching point and PDU session anchor functionalities), or may be centrally located in the core network.
  • MPTCP may be adapted to be compatible with 5G continuity.
  • IP addresses on a 5G device may be attributed a "session continuity service” (SCS) type,
  • SCS session continuity service
  • the SCS type maps to IP addresses allocated at different stages in various SSC modes, and may, therefore, be used by MPTCP stacks to adapt their behavior, Existing MPTCP stack processing does not transmit this session continuity service type over the MPTCP protocol, which may be requested for the remote peer to adapt its behavior.
  • Applicant discloses adapting the MPTCP protocol to associate SCS type information with an IP address (e.g., each IP address) used by MPTCP.
  • the 5G stack may request a PDU session, and a network slice and SSC mode may be determined.
  • An IP address and network interface may be assigned for the session,
  • An MPTCP stack may look up the type and compatibility group of the network interface and/or IP address and may store these values for future use.
  • MPTCP packet options may be used to communicate an SCS type to a remote peer which may store the SCS type.
  • a mobility event by the mobile device may trigger the creation of a new PDU session and/or new IP address.
  • the 5G stack may assign a compatibility group to the newly created network interface
  • the MPTCP stack may be made aware of the new IP address and/or network interface by an internal programmatic event.
  • the MPTCP stack may look up the compatibility group of the new network interface and/or IP address, if the compatibility group for the new network interface/IP address does not match the stored compatibility group value for the ongoing session, the MPTCP does not use the new IP address/network interface. However, if the compatibility group value matches the stored value, the MPTCP may look up the SCS type of the latest IP address and may determine based upon the SCS types of the existing and latest IP address whether to create a new subf!ow using the new IP address. Where a new subflow is created, the SCS type may be communicated to the remote peer.
  • a programmatic API may be used to expose a compatibility group to API users such as the Iocal PTCP stack or user space programs.
  • a set of rules may be used to control MPTCP behavior, information inputs including SCS type and/or compatibility group may be used in applying the rule sets on both peers of an MPTCP session,
  • a programmatic API may be used for network interface or !P address compatibility.
  • applications running on a device may request to use different PDU sessions.
  • different PDU sessions may correspond to different network interfaces.
  • the different PDU sessions may be requested, for example, because the applications require different network slices or SSC modes.
  • MPTCP implementation it may be useful to be aware of which network interfaces may be available to which iocal applications.
  • the mapping between network Interfaces and iocal applications may be known to the 5G stack, and may be made available to an MPTCP implementation running on the device, The information may be made available using an API,
  • An API may be used to make the mapping information available to the MPTCP stack.
  • T e network stack may expose information that may contribute to network Interface compatibility.
  • an API may be used to make available information such as a network slice ID, SSC mode, and a data network name associated with a network interface.
  • the MPTCP stack may then collect this information for each network interface, and implement logic to determine which interfaces are available to an application. For example, the MPTCP stack may use the network slice ID, SSC mode, and/or a data network name associated with the Initial interface/IP address used by the application as reference values.
  • the 5G network stack may expose a compatibility group ID, which may be, for example, a numerical value, associated with a network interface (or with an IP address), which may be the same for one or more network interfaces (e.g., all network interfaces) that may be interchangeably used by an application,
  • a 5G stack may create compatibility groups that map (e.g., uniquely map) to tuples (network slice, SSC mode), and associate these groups with network interfaces (or IP addresses) that are tied to this network slice and SSC mode.
  • the Initial network interface (or IP address) used by an application can provide the reference compatibility group for this application
  • the MPTCP stack may use the compatibility group of the initial IP address/network interface of the session to selectively choose other IP addresses/network interfaces for new sub-flow creations.
  • Exposing a compatibility group ID may decorrelate the 5G stack from MPTCP since the MPTCP stack may not request to be aware of compatibility logic.
  • a new compatibility group information element which may be, for example, an integer field, may be stored in the network stack of an operating system, along with attributes associated with a network interface and/or attributes associated with an IP address.
  • the MPTCP stack which may be implemented as a component of the operating system, may, thereby, have access to this information.
  • the path management component of MPTCP may, when made aware of a new IP address/prefix on the UE, access the compatibility group information element for this IP address or the network interface this IP address is tied to, and use it to decide whether to use this new IP address/prefix for a specific application (e.g. may use it if it is equal to the group of the initial IP address/network interface used by this application, may not use it otherwise).
  • a user plane application may access the compatibility group using an API call.
  • Any suitable API call me employed.
  • a new input /output control (“IOCTL") call may be used and thereby extend the existing sockets interface which is used to configure network devices (including, e.g., SiOCGIF!NDEX, SIOCG!FFLAGS, etc.), New proposed IOCTL operations may be designated with S!OCG!FCO PATGROUP and SiOCGIFCOMPATGROUP.
  • the call may use the struct ifreq_data structure as a parameter.
  • the structure may be enhanced to support compatibility groups, including adding ifr_compat_group.
  • An example structjfreq structure may be as follows:
  • ifr_compat_group may be an integer, where, for example, a va!ue of 0 indicates "no group," and may be the default value, and where any other positive integer may be a valid compatibility group.
  • An example call. SIOCGIFCO PATGROUP may be used to associate the compatibility group with the interface Identified by the Ifrjiame field, while another example call, SIOCSIFCOMPATGROUP, may be used to set the compatibility group.
  • an internal, in- kernel programmatic API equivalent may be used to set compatibility group of a network Interface created in relation to a new PDU session.
  • FIG. 25 depicts example processing for setting the compatibility group of a network interface by the 5G stack.
  • the 5G stack creates a network interface to serve as an end point to the PDU session.
  • the 5G stack collects the "compatibility set" of PDU session parameters, For example, the 5G stack may collect a slice ID and SSC type, or collect a slice ID, a SSC type, and a Data Network Name ("DNN").
  • the 5G stack may determine, using the collected Information, if there is an active compatibility group associated with the compatibility set. if so, the 5G stack sets the compatibility group of the network interface. If the 5G stack determines that that there may not be an active compatibility group associated with the compatibility set, the 5G stack may allocate a previously unused compatibility group number and associates the compatibility set to it.
  • the network interface may be usable.
  • Another example method of conveying a compatibility group for network interfaces may be to use a naming convention.
  • the first 8 letters of the interface may be known to be the same between multiple compatible network Interfaces.
  • the letters of a first interface are "5g-12345-ifQ”
  • the letters of a second Interface are "5g-12345-if1 ”
  • the first eight letters match, which indicates the interfaces may be used by the same application.
  • the letters of the second interface are "5g-12346-if0”
  • the first eight digits do not match, which indicates the interfaces may not be used by the same application.
  • a naming approach may require no in-depth changes in the network stack, although it may require some a priori knowledge on the naming scheme by the user (e.g. the MPTCP stack).
  • Adapting MPTCP to 5G may also involve a programmatic API for accessing network interface or IP address session continuity service type ("SCS" type).
  • SCS IP address session continuity service type
  • An MPTCP stack may be adapted to comprise an input SCS type for an IP address allocated by the network.
  • the information may or may not directly indicate which SSC mode the application is using.
  • the information may be sufficient for the PTCP stack to appropriately and non-ambiguously decide how to handle new IP addresses in the context of SSC In 5G.
  • the SSC mode may be inferred from the SCS type of the initial IP address used by the application.
  • Example SCS types may comprise the following: FIXED IP address which may specify an address that may be valid for a very long time for session continuity and IP address reachability; SESS!ON__LASTING IP address which may specify a valid address for the lifetime of an IP session, even if the mobility host moves; NON_PERSISTENT IP address which may specify an address that may not provide session continuity nor IP address reachability; and GRACEFUL_REPLACEMENT IP address which may be similar to a non-persistent address, but may add a limited time period for graceful transition from one address to another.
  • An application typically opens a socket, which may trigger the 5G stack to request a new or updated PDU session, and which may ultimately provide a source IP address to the socket.
  • the IP address may be associated with an SCS type such as those noted herein,
  • the SCS type field which may be an integer field with values mapping to the defined SCS types, can be stored along with attributes associated with an IP address.
  • the MPTCP stack implementation which may be a component of the operating system, may have access to this information.
  • the path management component of MPTCP may, when made aware of a new IP address/prefix on the UE, access the SCS type for this IP address, and use this information to decide how to handle the address.
  • the ADD_ADDR, MPJOlN and MP_CAPABLE TCP packet options defined for the MPTCP protocol may be enhanced to carry an SCS type.
  • the following example encoding may be used.
  • the enhancement may be a new SCS 3-bit field that replaces a reserved 3-bit field when possible, or may be added as a new field in the option.
  • ADD_ADDR, MP_JOIN, and MP_CAPABLE may have in common that they may introduce explicitly (ADD_ADDR, MPJOlN) or implicitly (MP_CAPABLE) IP addresses to the other MPTCP peer. They may be appropriate for placing an SCS type field. Other approaches may be used as well,
  • an MPTCP peer may update its internal state to associate the IP address, identified by its address ID, with the given SCS type. The MPTCP peer may then make use of the SCS type, !t will be appreciated that there may not be a request to transmit the compatibility group information over the air because the local MPTCP stack may not use nor advertise an IP address with a compatibility group different from its original source IP address, since the application session may not use such an address.
  • FIG. 26 depicts an example enhanced Multipath Capable (MP_CAPABLE) option.
  • the enhanced MP_CAPABLE has conditional fields, For example, it may comprise a Sender's key If option length may be greater than 4, e.g., such as in initial SYN packet,
  • the SCS field (and potentially reserved bits rsv) may be placed either before or after the conditional field.
  • the SCS field (+ rsv bits) may also be conditional.
  • the SCS field may be present in TCP SYN and SYN/ACK packets, which may provide the SCS type of initial IP addresses on both sides.
  • the SCS field may be present In TCP SYN/ACK, and ACK packets.
  • FIG. 27 depicts an example enhanced Join Connection (MP .. JOIN) Option for Initial synchronization (e.g., initial SYN).
  • FIG. 28 depicts an example enhanced Join Connection (MP .. JOIN) Option for responding synchronization and acknowledgement (SYN/ACK).
  • FIG. 29 depicts an example enhanced Add Address (ADD_ADDR) Option. It will be appreciated that in MP_JOIN and ADD_ADDR, the SCS field may use three currently reserved bits.
  • 0 may be used for non on-demand or unknown-type IP addresses (e.g., address that may not be provided by a mobile network); 1 may be used for NON-PERSISTENT addresses; 2 may be used for SESS!ON_LASTING addresses; 3 may be used for FIXED addresses; 4 may be used for GRACEFUL . REPLACEMENT addresses; and 5-7 may be reserved for future use, It will be appreciated that values 1-4 may have the same meaning as SrvTp field values 1 -4 for encoding the SCS type in router advertisements. Other fields may have a suitable format and value. For example, the Kind field may be 30 in an MPTCP option (e.g., all MPTCP options), Subtype for ADD__.ADDR may be 0x3,
  • Association to an SCS type may be performed separately from MP_CAPABLE, MP_JOIN and/or ADD__.ADDR messages using an explicit association.
  • a new ASSOCIATE_SCS_TYPE TCP option (or an experimental equivalent) may be used to associate an SCS type to an IP address.
  • Such an MPTCP option may be sent at any time following or preceding a MP_CAPABLE, MP_JOIN and/or ADD .. ADDR option.
  • FIG. 30 depicts an example format for a TCP option ASSOCIATE_SCS_ TYPE, in an example, Kind may be equal to 30, Length may be equal to 4, and Subtype may be equal to 0x9.
  • FIG. 31 depicts another example format for TCP option ASSOCIATE_SCS_TYPE.
  • Experiment ID field may be a 16 bit value that may be registered in the Multipath TCP Experimental Option Identifiers (MPTCP ExIDs) IANA registry,
  • the SCS field may be as defined herein and the rsv bit reserved for future use,
  • the Address JD field has the same meaning as in other TCP options for MPTCP,
  • the kind, Length, Subtype, S, and U fields may be any suitable values.
  • Encoding may be done, for example, in an Address ID. Except for the initial IP address, which may be implicitly identified with address ID 0 and may not be identified using an address ID field, the address ID of other IP addresses (e.g., all other IP addresses) may have 3 bits allocated to the SCS type of the address (using encoding of SCS described herein), The remaining 5 bits may be sufficient for identifying addresses (e.g., uniquely identifying all addresses) actively used in a session, This new address ID encoding may be used in ADD .. ADDR and MP . JOIN.
  • FIG. 32 depicts an example Address ID field including the encoding of the SCS type of the address.
  • an application opens a MPTCP socket, which may result in a request for 5G connection (e.g.. PDU session) by the network stack, on behalf of the application,
  • the 5G network may create a new PDU session or update an existing PDU session, which may result in a new or existing IP address being associated, as a source IP address, with the initial application connection.
  • the MPTCP stack collects information on this Initial IP address.
  • the MPTCP stack may collect its SCS type using, for example, a programmatic API as discussed herein.
  • the MPTCP may also collect its compatibility group Information using, for example, a programmatic API as discussed herein.
  • a SCS type may be associated with an IP address
  • compatibility group may be associated with a network interface.
  • initial SCS type may be FIXED or 8E8SION _LA8T!NG
  • an MPTCP processing algorithm may be applied, which may include the following, For example, MPTCP may not close a subf!ow (e.g., ail subflows) originated from this IP address at a point (e.g., any point) during the session, since this IP address may be guaranteed to be maintained over time for this application. Also, the remote peer may be signaled the IP address FIXED or SESSION . LASTING SCS type over MPTCP signaling (e.g.
  • MPTCP may check if it is compatible with (e.g., has the same compatibility group as) the initial IP address of the application. If this is the case, MPTCP may create new subflows for the application, using this IP address (this IP address may provide shorter path subflows, but may disappear at any time) and using an enhanced MP .. JOIN option including the NON .. PERSISTENT SCS type of the new IP address.
  • an MPTCP processing algorithm may be applied that may include the following.
  • the current NON_PERS!STENT IP address may be taken down by the network stack.
  • the MPTCP stack may wait for another NON ..
  • the MPTCP stack may create new subflows using this new address (effectively following the existing break-beiore- make behavior present in MPTCP),
  • the remote peer may be signaled the IP address SCS type over MPTCP signaling (e.g., enhanced MP .. CAPABLE option for the initial address, and MP ..
  • the peer may implement break-before-make support by waiting for its peer to open new subflows from a new remote NON_PERS!STENT IP address, if an initial backup IP address is a NON__PER8!STENT address, the MPTCP stack may consider any subsequent compatible NON ... PERSISTENT IP address as a backup IP address in replacement of the initial NON .. PERSISTENT address.
  • initial SCS type is GRACEFUL .
  • REPLACEMENT an MPTCP algorithm may be applied that may include the following.
  • a new GRACEFUL_REPLACEMENT IP address may be brought up by the network stack,
  • the MPTCP stack may check if it is compatible (e.g., with the same compatibility group) with the previous GRACEFUL ..
  • REPLACEMENT IP address If this is the case, the MPTCP stack may create new subflows using this new address.
  • the remote peer may be signaled the IP address GRACEFUL_REPLACEMENT SCS type over MPTCP signaling (e.g., enhanced MP_CAPABLE option for the initial address, and MP_JOIN for subsequent addresses), to ensure that the remote MPTCP stack behaves appropriately. For example, the remote peer may gracefully transfer traffic from the first to the second GRACEFUL_REPLACE ENT IP address. If an Initial backup IP address is a GRACEFUL_REPLACEMENT address, the local MPTCP stack may consider any subsequent compatible GRACEFUL . REPLACEMENT IP address as the new backup IP address, in replacement of the first GRACEFUL .. REPLACEMENT IP address.
  • MPTCP signaling e.g., enhanced MP_CAPABLE option for the initial address, and MP_JOIN for subsequent addresses
  • FIG. 33 depicts a sequence diagram of an example procedure for establishing and maintaining an application session over MPTCP in a 5G network.
  • a server application may create a socket (e.g., an MPTCP socket) and listen for incoming connections.
  • a socket e.g., an MPTCP socket
  • a client application running on a UE may create a socket for communicating over the 5G network
  • the 5G stack may request a PDU session for the application
  • the UE and/or network determines based on, for example, the application profile, subscriber profile and network operator policy, which network slice and SSC mode to use for this PDU session.
  • a new or existing IP address and network interface may be used for socket.
  • the MPTCP stack Initializes its Internal state by, for example, creating a meta-socket for use for future subflows.
  • the MPTCP stack may look up the SCS type and compatibility group of the initial network interface and/or IP address, it may store these values for future use in the internal state it maintains for this MPTCP session.
  • the application session may be set up over TCP, using MPTCP options.
  • packets including the enhanced MPTCP options MP ... CAPABLE and/or ADD ... ADDR and/or MP .. JOIN including a SCS type (or otherwise associating IP addresses with SCS types, as further described herein) may be sent between remote peers.
  • the UE may send a TCP SYN with an enhanced MP_CAPABLE option (with SCS type set to the SCS type of the IP address used as source).
  • the peer may reply with a TCP SYN/ACK with a MP_CAPABLE option (possibly also enhanced with SCS type),
  • the UE may respond with a TCP ACK with a MP ... CAPABLE option,
  • the UE and/or peer may then send additional MPTCP options including, for example, MP_JOIN and ADD_ADDR options enhanced with SCS types, to add subflows or backup IP addresses,
  • the MPTCP stack on the remote peer may store the SCS type of the added IP address(s) In its internal state for future use.
  • a mobility event related to the UE may occur.
  • the UE may leave a network anchor service area.
  • the mobility event may trigger the creation or update of a PDU session, A new IP address (and possibly a new network interface if, for example, a new PDU session is created) is available on the LIE,
  • the 5G stack may assign a compatibility group to the newiy created network interface, if any. as described herein.
  • the MPTCP stack may be made aware of the new IP address and/or network interface by. for example, an internal programmatic event it subscribed to.
  • the MPTCP stack may look up the compatibility group of the new network interface and/or IP address.
  • the MPTCP stack may use API's as described herein to retrieve the compatibility group information.
  • the MPTCP stack determines If the compatibility group matches the value stored earlier for the particular MPTCP session. At 10a, if the compatibility group does not match the value stored eariier for this MPTCP session, the MPTCP stack may not use new IP address/network interface for this session. Under this circumstance, the processing of the new IP address/network interface by the MPTCP stack ends.
  • MPTCP may look up the SCS type of the latest IP address.
  • MPTCP may make decisions based on the SCS types of iP addresses (e.g., all !P addresses) involved in the session. For example, MPTCP may make decisions based on SCS types of the initial IP address and the latest IP address as described herein.
  • the MPTCP stack may determine to create new subflow(s) using a new IP address. Longer term action may depend on SCS type values as described herein.
  • the MPTCP stack may set up new subflow(s) using the latest IP address and/or advertise the subflow to the peer. At some point during this setup. TCP packet(s) including the enhanced MPTCP option " ⁇ _ ⁇ ! ⁇ ” and/or "ADD_ADDR" (or an alternative as described herein), including a SCS type, may be sent to the remote peer,
  • the remote MPTCP stack may store the SCS type of the newiy added IP address in its internal state.
  • the MPTCP stack may make decisions based, in part, on the SCS type of involved IP addresses as described herein.
  • the IP address compatibility group may be exposed to end users of the UE,
  • the IP address compatibility group may be exposed as the output of common IP configuration tools such as ifconfig in Linux, ipconfig in Windows, or equivalent in other Operating Systems, Enhanced TCP options for MPTCP may be observed in data traffic to/from the UE, [0285]
  • Applicants have disclosed systems and methods for managing communication paths in a multipath communication environment, in an example embodiment, as a mobile device connects to anchor points In a wireless network, the mobile device determines a plurality of internet protocol (IP) addresses, with each of the plurality of IP addresses being associated with a communication path.
  • IP internet protocol
  • the mobile device stores the plurality of IP addresses, with each of the plurality of IP addresses being stored in relation to one of a plurality of interface identifiers.
  • Each of the plurality of interface identifiers may correspond to a physical communication interface such as a WIFI interface or celiuiar interface,
  • the mobile device may subsequently use the stored data to select an IP address corresponding to a communication path.
  • the mobile device may select a communication path associated with one of the plurality of IP addresses based at least upon the interface identifier stored in relation to the one of the plurality of IP addresses, In an example scenario, the mobile device may select a communication path associated with one of the plurality of IP address based at least upon the associated interface identifier corresponding to a communication interface that is different than that used by the existing communication path.
  • the method(s) may be implemented in the form of software (I.e., computer-executable instructions) stored in a memory of a mobile device and/or network node, such as the node or computer system, which computer executable instructions, when executed by a processor of the node, perform the processes discussed, it is also understood that any transmitting and receiving processes illustrated in FIGs may be performed by communication circuitry of the node under control of the processor of the node and the computer-executable Instructions (e.g., software) that it executes.
  • the various techniques described herein may be implemented in connection with hardware or software or, where appropriate, with a combination of both.
  • the methods and apparatus of the subject matter described herein, or certain aspects or portions thereof may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the subject matter described herein.
  • program code i.e., instructions
  • the computing device In the case where program code is stored on media, it may be the case that the program code in question is stored on one or more media that collectively perform the actions in question, which is to say that the one or more media taken together contain code to perform the actions, but that - in the case where there is more than one single medium - there is no requirement that any particular part of the code be stored on any particular medium.
  • the computing device In the case of program code execution on programmable computers, the computing device generally Includes a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device.
  • One or more programs that may implement or utilize the processes described in connection with the subject matter described herein, e.g., through the use of an API, reusable controls, or the like, Such programs are preferably implemented in a high level procedural or object oriented programming language to communicate with a computer system.
  • the program(s) can be implemented in assembly or machine language, if desired, in any case, the language may be a compiled or interpreted language, and combined with hardware implementations.
  • example embodiments may refer to utilizing aspects of the subject matter described herein in the context of one or more stand-alone computer systems, the subject matter described herein is not so limited, but rather may be implemented in connection with any computing environment, such as a network or distributed computing environment, Still further, aspects of the subject matter described herein may be implemented in or across a plurality of processing chips or devices, and storage may similarly be affected across a plurality of devices, Such devices might include persona! computers, network servers, handheld devices, supercomputers, or computers integrated into other systems such as automobiles and airplanes.
  • Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).
  • ROM read only memory
  • RAM random access memory
  • register cache memory
  • semiconductor memory devices magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).
  • a processor In association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

La présente invention concerne un dispositif mobile qui se connecte à un point d'ancrage et peut déterminer une pluralité d'adresses de protocole internet (IP), chacune de la pluralité d'adresses IP étant associée à un trajet de communication. Le dispositif mobile stocke chacune de la pluralité d'adresses IP en lien avec l'un d'une pluralité d'identificateurs d'interface. Chacun de la pluralité d'identificateurs d'interface peut correspondre à une interface de communication physique telle qu'une interface Wi-Fi ou une interface cellulaire. Le dispositif mobile peut utiliser les données stockées pour sélectionner une adresse IP correspondant à un trajet de communication au moins sur la base de l'identificateur d'interface stocké en lien avec l'adresse IP de la pluralité d'adresses IP. Le dispositif mobile peut également stocker un type de SCS pour chaque adresse IP, et peut utiliser les types de SCS associés aux adresses IP afin de déterminer si une adresse IP particulière doit être utilisée pour créer un trajet de communication.
PCT/US2018/041782 2017-07-14 2018-07-12 Gestion de trajet de communication WO2019014426A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201762532952P 2017-07-14 2017-07-14
US62/532,952 2017-07-14
US201862666514P 2018-05-03 2018-05-03
US62/666,514 2018-05-03

Publications (3)

Publication Number Publication Date
WO2019014426A1 true WO2019014426A1 (fr) 2019-01-17
WO2019014426A8 WO2019014426A8 (fr) 2019-02-28
WO2019014426A9 WO2019014426A9 (fr) 2019-11-21

Family

ID=63174380

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2018/041782 WO2019014426A1 (fr) 2017-07-14 2018-07-12 Gestion de trajet de communication

Country Status (1)

Country Link
WO (1) WO2019014426A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112312510A (zh) * 2019-07-30 2021-02-02 华为技术有限公司 一种数据转发方法、装置及系统
CN112788696A (zh) * 2020-12-31 2021-05-11 北京工业大学 一种区域内移动端无线网络切换的通讯延迟降低方法和系统
US11412437B2 (en) * 2018-07-23 2022-08-09 Huawei Technologies Co., Ltd. Data transmission method and electronic device
CN112866000B (zh) * 2019-11-26 2024-04-02 瞻博网络公司 高可用性集群的冗余接口中的有线和无线接口的绑定
WO2024113803A1 (fr) * 2022-12-01 2024-06-06 中兴通讯股份有限公司 Procédé d'optimisation de réseau, dispositif périphérique et support de stockage lisible par ordinateur

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015150875A1 (fr) * 2014-04-04 2015-10-08 Nokia Technologies Oy Gestion d'accès avec un transport multi-chemin
US20160183129A1 (en) * 2014-12-19 2016-06-23 At&T Intellectual Property I, L.P. Mobility Management of Wireless Networks Based on Multipath Transfer Control Protocol

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015150875A1 (fr) * 2014-04-04 2015-10-08 Nokia Technologies Oy Gestion d'accès avec un transport multi-chemin
US20160183129A1 (en) * 2014-12-19 2016-06-23 At&T Intellectual Property I, L.P. Mobility Management of Wireless Networks Based on Multipath Transfer Control Protocol

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11412437B2 (en) * 2018-07-23 2022-08-09 Huawei Technologies Co., Ltd. Data transmission method and electronic device
CN112312510A (zh) * 2019-07-30 2021-02-02 华为技术有限公司 一种数据转发方法、装置及系统
CN112312510B (zh) * 2019-07-30 2022-09-23 华为技术有限公司 一种数据转发方法、装置及系统
CN112866000B (zh) * 2019-11-26 2024-04-02 瞻博网络公司 高可用性集群的冗余接口中的有线和无线接口的绑定
CN112788696A (zh) * 2020-12-31 2021-05-11 北京工业大学 一种区域内移动端无线网络切换的通讯延迟降低方法和系统
WO2024113803A1 (fr) * 2022-12-01 2024-06-06 中兴通讯股份有限公司 Procédé d'optimisation de réseau, dispositif périphérique et support de stockage lisible par ordinateur

Also Published As

Publication number Publication date
WO2019014426A9 (fr) 2019-11-21
WO2019014426A8 (fr) 2019-02-28

Similar Documents

Publication Publication Date Title
CN111837371A (zh) 基于增强mptcp的应用移动性
US20220117015A1 (en) Methods and wireless transmit/receive units for supporting virtual machine migration
WO2019014426A1 (fr) Gestion de trajet de communication
US11985062B2 (en) Methods and apparatuses for enabling multi-host multipath secure transport with QUIC
WO2021062256A1 (fr) Relocalisation transparente d'instances d'application mec entre des dispositifs 5g et des hôtes mec
US20210211510A1 (en) Pinning service function chains to context-specific service instances
WO2020219670A1 (fr) Support de relais sans fil à bonds multiples
US20210266254A1 (en) Device to device forwarding
EP3959858A1 (fr) Protocole d'attribution d'adresse de commande d'accès au support (mac) de multidiffusion et de monodiffusion (mumaap)
EP4128724A1 (fr) Procédés, appareils et systèmes pour la découverte de serveurs de gestion de réseau de périphérie
EP4275286A1 (fr) Changement d'identifiants de liaison pc5 entre la wtru et le relais wrtu-wrtu de couche 2
EP4133790A1 (fr) Procédés, appareils et systèmes destinés à un changement d'une wtru à un relais wtru
WO2020150620A1 (fr) Procédés permettant de spécifier le type d'adresse mac avec des mécanismes d'attribution dynamique
WO2022241233A1 (fr) Procédés, architectures, appareils et systèmes pour applications informatiques en périphérie multi-accès sur des unités d'émission-réception sans fil
US11736905B2 (en) Methods and apparatus for Layer-2 forwarding of multicast packets
EP4154594A1 (fr) Procédé de transfert intercellulaire de wtru à relais de réseau
US20230107614A1 (en) Methods and apparatus for performing local lifecycle management with distributed sfc control
WO2023091764A1 (fr) Procédés, architectures, appareils et systèmes pour interface programmable pour mandataire de communication de service
WO2024035879A1 (fr) Continuité de service associée à des changements de communication inter-pine d'un mode direct à l'utilisation d'un pegc intermédiaire
WO2020185588A1 (fr) Procédés et appareils pour prendre en charge la mobilité et la volatilité de ressources dans des environnements dans le brouillard

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18753486

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18753486

Country of ref document: EP

Kind code of ref document: A1