ROHC header compression for MPTCP

Abstract

Methods for Robust Header Compression (ROHC) of Multipath Transmission Control Protocol (MPTCP) data packets, including: Determine (1602), based on initial information contained in the headers of a stream of data packets, that an initial section of the stream of data packets is formatted according to the transmission control protocol, TCP, with an enabled multipath TCP option, MPTCP option; Establishing (1604) a context with a suitable decompressor, wherein, if the context indicates that the suitable decompressor supports decompression of TCP data packets with the MPTCP option enabled, the procedure further comprises: Performing (1608) a robust header compression, ROHC compression, on the stream of data packets, thereby generating a chain of compressed data packets, wherein in a first compression mode the MPTCP option is not compressed, wherein in a second compression mode the MPTCP option is compressed; and Transferring the chain of compressed data packets to the appropriate decompressor.

Description

TECHNICAL AREA

[0001] The present application relates to wireless communication, including the provision of techniques for ROHC header compression for MPTCP packets. DESCRIPTION OF THE STATE OF THE ART

[0002] The use of wireless communication systems is increasing rapidly. Furthermore, wireless communication technology has evolved beyond purely voice communication and now also includes the transmission of data such as internet and multimedia content.

[0003] ROHC (Robust Header Compression) is a standardized (see, for example, the Internet Engineering Task Force (IETF) Request for Comments (RFC) series IETF RFC 3095, IETF RFC 3759, IETF RFC 4815, IETF RFC 5225, and IETF RFC 6846) method for compressing the headers of various types of Internet packets, such as UPD (User Datagram Protocol), RTP (Real-Time Transport Protocol), and TCP (Transmission Control Protocol), among others. In typical streaming applications, headers range from 40 bytes for IPv4 (Internet Protocol version 4) to 60 bytes for IPv6. ROHC compresses headers from these 40 to 60 bytes to 1 or 3 bytes using a compressor placed before a link. A decompressor after the link decompresses the headers.

[0004] MPTCP is a transport layer protocol that builds upon traditional TCP to provide a transport layer where applications can send / receive data over multiple paths (see, for example, IETF RFC 6824). For instance, multipath TCP can be used to combine TCP connections or subflows created across multiple networks on a multi-networked device into a single line or main line for sending / receiving data. IETF RFC 6846 standardizes ROHC for TCP packets and has also been implemented for use with MPTCP packets.

[0005] Document US 9426693 B2 describes a method, a compressor and a system for robust header compression in mobile communication systems.

[0006] However, in many cases, ROHC of MPTCP packets led to transmission errors, partly due to the format of the MPTCP packets themselves. Therefore, improvements in this area are desired. SUMMARY

[0007] This document presents embodiments of, among other things, a user equipment device (UE) and associated methods for performing ROHC header compression on TCP packets with the MPTCP option enabled.

[0008] In some embodiments, a compressor enclosed in a user entity (e.g., one or more processors or processing switching logic) can determine, based (at least partially) on initial information contained in the headers of a stream of data packets, that an initial portion of the data packet stream is formatted according to the Transmission Control Protocol (TCP) with the Multipath TCP (MPTCP) option enabled. The compressor can establish a context with a corresponding decompressor and, based on this context, can operate in one of three compression modes. In some embodiments, if the context indicates that the corresponding decompressor supports decompression of TCP data packets with the MPTCP option enabled, the compressor can operate in either the first or second compression mode.In some implementations, if the context indicates that the relevant decompressor does not support decompression of TCP data packets with the MPTCP option enabled, the compressor can operate in a third compression mode. The compressor can then generate a chain of compressed data packets and transmit this chain to the relevant decompressor.

[0009] In some embodiments, the first compression mode (e.g., a safe compression mode) may include transmitting the first part of the data packet stream with the MPTCP option enabled using partial ROHC and transmitting a second part of the data packet stream with the MPTCP option disabled using ROHC. In some embodiments, partial ROHC may include performing ROHC on a data packet without the MPTCP option and transmitting the MPTCP option as part of a compressed list. In some embodiments, the second compression mode (e.g., a full compression mode) may include transmitting the first part of the data packet stream with the MPTCP option enabled using ROHC and transmitting the second part of the data packet stream with the MPTCP option disabled using ROHC. In some embodiments, the third compression mode (e.g.,Non-compression mode) includes the transmission of the first part of the stream of data packets with the MPTCP option enabled without compression and the transmission of the second part of the stream of data packets with the MPTCP option not enabled with ROHC.

[0010] The techniques described herein can be implemented and / or used in a number of different types of devices, including mobile phones, tablet computers, body-worn computing devices, portable media players, and any other computing devices.

[0011] This summary is intended to provide a brief overview of some of the items described in this document. Accordingly, it should be noted that the features described above are merely examples and should not be interpreted as limiting the scope of protection or the spirit of the item described herein in any way. Further features, aspects, and advantages of the item described herein will become apparent from the following detailed description, figures, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] A better understanding of the present subject matter can be achieved by considering the following detailed description of the embodiments in conjunction with the following drawings. Fig. Figures 1-2 illustrate exemplary wireless communication systems according to some embodiments. Fig. Figure 3 illustrates a mobile communication base station (eNB / gNB) and a Wi-Fi (or WLAN) access point (AP) communicating with a wireless user equipment device (UE) according to some embodiments. Fig. Figure 4 is a block diagram illustrating an exemplary UE, according to some embodiments. Fig. Figure 5 illustrates an exemplary block diagram of a base station according to some embodiments. Fig. Figure 6 illustrates an exemplary simplified block diagram of a WLAN access point (AP) according to some embodiments. Fig. Figure 7A illustrates an example of a technique for compressing IP packets according to ROHC. Fig. Figure 7B illustrates an example of a technique for decompressing IP packets according to ROHC. Fig. Figure 8A illustrates an example of a ROHC compressor state machine. Fig. Figure 8B illustrates an example of a ROHC decompressor state machine. Fig. Figure 9A illustrates an example of the operation of a ROHC compressor state machine for a unidirectional operating mode. Fig. Figure 9B illustrates an example of the operation of a ROHC compressor state machine for a bidirectional optimistic operating mode. Fig. Figure 9C illustrates an example of the operation of a ROHC compressor state machine for a bidirectional reliable operating mode. Fig. Figure 10 illustrates the TCP header and the options available for ROHC compression according to IETF RFC 6846. Fig. Figure 11 illustrates a TCP packet format according to IETF RFC 793. Fig. Figure 12 illustrates an MPTTCP options format of a TCP header according to IETF RFC 6824. Fig. Figure 13 illustrates MPTCP subtypes according to IETF RRFC 6824. Fig. Figure 14 illustrates an example of a ROHC-MPTCP compressor state machine according to some embodiments. Fig. Figure 15 illustrates an example of an element option mapping table according to some embodiments. Fig. Figure 16 illustrates a block diagram of an example of a method for ROHC compression of MPTCP packets according to some embodiments.

[0013] While the features described herein are open to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and described in detail herein. It should be understood, however, that the drawings and the detailed description thereto are not intended to be limited to the specific disclosed form, but rather that the invention is intended to cover all modifications, equivalents, and alternatives that fall within the spirit and scope of protection of the subject matter as defined by the attached claims. DETAILED DESCRIPTION Terminology

[0014] The following is a glossary of terms used in this disclosure: Storage medium – any of the various types of non-volatile memory devices or storage devices. The term “storage medium” is intended to include an installation medium, e.g., a CD-ROM, floppy disks, or a tape device; a computer system memory or random-access memory, such as DRAM, DDR-RAM, SRAM, EDO-RAM, Rambus-RAM, etc.; non-volatile memory such as flash memory; magnetic storage media, e.g., a hard disk or optical storage; registers or other similar types of memory elements, etc. The storage medium may include other types of non-transient memory as well as combinations thereof.Furthermore, the storage medium can be located in a first computer system where the programs are executed, or it can be located in a second, different computer system connected to the first computer system via a network, such as the internet. In the latter case, the second computer system can provide the first computer with program instructions for execution. The term "storage medium" can include two or more storage media, which may be located in different places, for example, in different computer systems connected via a network. Program instructions (e.g., in the form of computer programs) that can be executed by one or more processors can be stored on the storage medium.

[0015] Carrier medium - a storage medium as described above, as well as a physical transmission medium, such as a bus, a network and / or another physical transmission medium that transmits signals, such as electrical, electromagnetic or digital signals.

[0016] Programmable hardware element – ​​encompasses various hardware devices comprising multiple programmable functional blocks connected via a programmable interconnect. Examples include FPGAs (Field Programmable Gate Arrays), PLDs (Programmable Logic Devices), FPOAs (Field Programmable Object Arrays), and CPLDs (Complex PLDs). The programmable functional blocks can range from fine-grained (combinatorial logic or lookup tables) to coarse-grained (arithmetic logic units or processor cores). A programmable hardware element can also be referred to as "reconfigurable logic."

[0017] Computer system – any of various types of computing or processing systems, including a personal computer system (PC), mainframe system, workstation, network device, internet device, personal digital assistant (PDA), television system, grid computing system, or any other device or combination of devices. In general, the term "computer system" can be broadly defined to include any device (or combination of devices) with at least one processor that executes instructions from a storage medium.

[0018] User equipment (UE) (or "UE device") – any of various types of computer system devices that are mobile or portable and capable of wireless communication. Examples of UE devices include mobile phones or smartphones (e.g., iPhone™, Android™-based phones), portable gaming devices (e.g., Nintendo DS™, PlayStation Portable™, Gameboy Advance™, iPhone™), laptops, body-worn devices (e.g., smartwatches, smartglasses), PDAs, portable internet devices, music players, data storage devices, or other handheld devices, etc. In general, the term "UE" or "UE device" can be broadly defined to encompass any electronic, computing, and / or telecommunications device (or combination of devices) that can be easily transported by a user and is capable of wireless communication.

[0019] Base station - The term "base station" (also referred to as "eNB" or "gNB") encompasses the full breadth of its usual meaning and includes at least one wireless communication station installed in a fixed location and used for communication as part of a wireless mobile communication system.

[0020] TCP – refers to the transmission control protocol for the transmission of Internet packets and encompasses the full range of its usual meaning. TCP is standardized at least by IEFT RFCs 675, 793, 1122, and 7414.

[0021] MPTCP refers to Multipath TCP, a transport layer protocol built on top of traditional TCP to provide a transport layer where applications can send / receive data over multiple paths (see, for example, IETF RFC 6824). MPTCP encompasses the full breadth of its common meaning. MPTCP is standardized, at least by IETF RFC 6824.

[0022] ROHC – refers to Robust Header Compression and encompasses the full range of its usual meaning. ROHC is standardized by at least IETF RFCs 3095, 3759, 4815, 4996, 4997, 5225, 5795, and 6846.

[0023] Wi-Fi – The term “Wi-Fi” encompasses the full breadth of its usual meaning and includes at least one wireless communications network or RAT (Radio Access Technology) served by wireless LAN (WLAN) access points, which provides connectivity to the internet through these access points. State-of-the-art Wi-Fi networks (or WLAN networks) are based on IEEE 802.11 standards and are marketed under the name “Wi-Fi.” A Wi-Fi network (WLAN network) is distinct from a cellular network.

[0024] Bluetooth - The term “BLUETOOTH™” has the full breadth of its usual meaning and includes at least any one of the various implementations of the Bluetooth standard, including Bluetooth Low Energy (BTLE) and Bluetooth Low Energy for Audio (BTLEA), including, but not limited to, future implementations of the Bluetooth standard.

[0025] Processing element – ​​refers to different elements or combinations of elements. Processing elements include, for example, circuits such as an ASIC (Application Specific Integrated Circuit), sections or circuits of individual processor cores, complete processor cores, individual processors, programmable hardware devices such as a field programmable gate array (FPGA), and / or larger sections of systems that include multiple processors.

[0026] Automatic – refers to an action or operation performed by a computer system (e.g., software executed by the computer system) or a device (e.g., switching logic, programmable hardware elements, ASICs, etc.) without user input that directly specifies the action or operation. Thus, the term "automatic" contrasts with an operation performed or specified manually by the user, where the user provides input to directly execute the operation. An automatic procedure may be initiated by user input, but the subsequent actions performed "automatically" are not specified by the user; that is, they are not performed "manually" with the user specifying each action to be carried out.For example, a user who completes an electronic form by selecting each field and providing input that specifies information (e.g., by typing information, selecting checkboxes, choosing a radio button, etc.) is manually filling out the form, even though the computer system needs to update the form in response to the user's actions. The form can be automatically filled out by the computer system, where the computer system (e.g., software running on the computer system) analyzes the form's fields and completes the form entirely without any user input specifying the answers to the fields. As mentioned above, the user can request automatic form completion but is not involved in the actual process of filling out the form (e.g., the user does not manually specify answers for fields; these are filled in automatically).The following description provides various examples of operations that are performed automatically in response to actions taken by the user.

[0027] Approximately refers to a value that is almost correct or exact. For example, "approximately" may refer to a value that is within 1 to 10 percent of the exact (or desired) value. However, it should be noted that the actual threshold (or tolerance) may be application-dependent. For example, in one embodiment, "approximately" may mean within 0.1% of a specified or target value, while in other embodiments, the threshold may be, for example, 2%, 3%, 5%, and so on, as desired or required by the specific application.

[0028] The headings used herein serve only organizational purposes and are not intended to limit the scope of the description. As used in this application, the word "can" is used in the enabling sense (i.e., meaning "possessing the potential to") and not in the compelling sense (i.e., meaning "must"). The words "include," "including," and "includes," etc., indicate open relationships and therefore mean inclusive but not limited to. Likewise, the words "possess," "possessing," and "possesses," etc., also indicate open relationships and therefore mean possessing but not limited to. The terms "first," "second," "third," and so forth, as used herein, are used as identifiers for the nouns they precede and do not imply any kind of order (e.g., spatial, temporal, logical, etc.) unless such order is expressly indicated otherwise.For example, a “third component electrically connected to the module substrate” does not preclude scenarios in which a “fourth component electrically connected to the module substrate” is connected before the third component, unless otherwise specified. Similarly, a “second” feature does not require that a “first” feature be implemented before the “second” feature, unless otherwise specified.

[0029] Various components may be described as "configured to" perform one or more tasks. In such contexts, "configured to" is a broad term that generally means "possessing a structure that" performs the task or tasks during operation. Thus, the component may be configured to perform the task even if it is not currently performing that task (e.g., a set of electrical conductors may be configured to electrically connect one module to another, even if the two modules are not connected). In some contexts, "configured to" may be a broad term referring to a structure that generally means "possessing switching logic that" performs the task or tasks during operation.Therefore, the component can be configured to perform the task even if it is not currently powered on. Generally, the switching logic that forms the structure accordingly "configured to" can include hardware circuits.

[0030] Various components may, for convenience, be described in the description as performing a task or tasks. Such descriptions should be interpreted as including the phrase "configured to." The citation of a component that is configured to perform one or more tasks does not expressly imply reliance on an interpretation under 35 U.S.C. § 112(f) for that component. Figures 1-3 - Wireless communication systems

[0031] Fig. Figures 1-2 show exemplary (and simplified) communication systems. It is noted that the systems are from Fig. 1-2 merely represent examples of possible systems and embodiments can be implemented in any of the various systems as desired.

[0032] The in Fig. Figure 1 illustrates an exemplary wireless communication system that includes two endpoints with multiple communication paths between them. Thus, endpoint 122 can be capable of communicating with endpoint 124 via path 126 or path 128.

[0033] Both endpoint 122 and endpoint 124 can be either a "fixed" or a "mobile" endpoint. A fixed endpoint can be one that is essentially stationary and / or communicates using one or more wired communication technologies. Some examples might include a server computer providing cloud-based services over the internet, a bridge, a load balancer, a personal desktop computer or workstation, a set-top box, a television, and so on. A mobile endpoint can be one that is essentially mobile and / or communicates using one or more wireless communication technologies. Some examples might include a user equipment (UE) device (such as a mobile phone, smartphone, or tablet computer), a portable gaming device, a portable media player, and so forth.It should be noted that hybrid endpoints, which exhibit characteristics common to both fixed and mobile endpoints, are also possible. For example, many laptops can be capable of both wireless (e.g., Wi-Fi / Bluetooth) and wired (e.g., Ethernet) communication, and in addition, they may be capable of significant movement at different times (e.g., when operating on battery backup) or they may be essentially stationary (e.g., when docked and / or connected to a power outlet).

[0034] One or both of the endpoints 122, 124 can be networked multiple times. For example, one or both of the endpoints 122, 124 can be capable of communication via multiple network interfaces. Therefore, there can be several possible communication paths 126, 128 between the endpoints 122, 124. Although two paths (e.g., path 126 and path 128) in Fig. As shown in Figure 1, it should be noted that any number of paths can exist between the endpoints. For example, if each of the endpoints 122 and 124 is capable of communication via two different network interfaces, there could be four possible communication paths between endpoints 122 and 124. Other numbers of different network interfaces and possible communication paths are also possible.

[0035] The multiple communication paths 126 and 128 can be used to establish a Multipath Transmission Control Protocol (MPTCP) session or a connection between endpoints 122 and 124. The MPTCP session can be established according to the MPTCP specification IETF RFC 6824 and / or include various features described in the MPTCP specification IETF RFC 6824. For example, one subflow of the MPTCP connection can be established via path 126, while another subflow of the MPTCP connection can be established via path 128. Such an MPTCP connection can be established and configured / controlled according to various aspects of this disclosure.

[0036] The in Fig. The exemplary wireless communication system shown in section 2 represents a possible communication system with the properties of the one described in [reference missing]. Fig. Figure 1 represents an exemplary communication system. In particular, a first endpoint (e.g., a wireless user equipment device (UE) 106) can be capable of communicating with another endpoint (e.g., server 210) either using a first communication path (e.g., via cellular base station 102, core network 100, and wide area network 104) or a second communication path (e.g., via Wi-Fi access point 112 and wide area network 104).

[0037] As outlined, the UE 106 can communicate with a Wi-Fi access point (AP) 112 and a cellular base station 102. The AP 112 can be an access point providing a wireless local area network (WLAN). The AP 112 can be equipped to communicate with a wide area network (WAN) 104, such as the internet. Thus, the AP 112 can facilitate communication between the UE 106 and the WAN 104. The AP 112 and the UE 106 can be configured to communicate using Wi-Fi, including any of the different versions of IEEE 802.11 (e.g., a, b, g, n, ac, ad, and / or ax), or LTE over the transmission medium in an unlicensed band (LAA). It should be noted that the AP 112 can also facilitate communication between the UE and other computing devices that also participate directly in the WLAN.

[0038] The Base Station 102 can be a Base Transceiver Station (BTS) or Cell Site (a "Cell Base Station") and can include hardware that enables wireless communication with the mobile devices (such as UE 106) according to one or more cellular communication protocols. The communication area (or coverage area) of the Base Station 102 can be referred to as a "cell." The Base Station 102 and the UE 106 can be configured to communicate over the transmission medium using any of the various Radio Access Technologies (RATs) or wireless communication technologies, such as GSM, UMTS (WCDMA, TDS-CDMA), LTE, LTE-Advanced (LTE-A), 5G-NR, HSPA, 3GPP2 CDMA2000 (e.g., 1xRTT, 1xEV-DO, HRPD, eHRPD), Wi-Fi, WiMAX, etc. An example of LTE or LTE-A communications is VoLTE (Voice over LTE).

[0039] As outlined, the mobile base station can be equipped for communication with a mobile network operator's core network 100. Thus, base station 102 can facilitate communication between UE 106 and core network 100. Core network 100, in turn, can be equipped for communication with WAN 1040 (e.g., the internet or another wide area network). It should be noted that core network 100 can also be equipped, or alternatively, for communication with one or more other networks (e.g., a telecommunications network such as a public switched telephone network (PSTN), one or more core networks of other mobile network operators, etc.). Therefore, mobile base station 102 can provide UE 106 (and potentially numerous other UEs) with various telecommunications functions, such as voice and text messaging, e.g., SMS (Short Message Service) and similar text messaging technologies like iMessage, Facebook Messenger, WhatsApp, etc.and / or provide data services.

[0040] Thus, the UE 106 can be capable of communicating using multiple wireless communication standards, including at least one wireless network protocol (e.g., Wi-Fi) and at least one cellular communication protocol (e.g., GSM, UMTS (WCDMA), LTE, LTE-Advanced (LTE-A), 5G-NR, 3GPP2 CDMA2000 (e.g., 1xRTT, 1xEV-DO, HRPD, eHRPD), etc.). It should also be noted that the UE 106 can be configured, alternatively, to communicate using one or more global navigation satellite systems (GNSS, e.g., GPS or GLONASS), one or more mobile television broadcasting standards (e.g., ATSC-M / H or DVB-H), and / or any other wireless communication protocol (e.g., Bluetooth, NAN, Wi-Fi Direct, etc.), if desired. Additionally or alternatively, the UE 106 may be capable of communication using one or more standards for wired communication.For example, the UE 106 can be capable of communicating with one or more wired access points, e.g., via Ethernet. Thus, it may be possible, in addition to or as an alternative to using Wi-Fi communication, to connect to the Wi-Fi access point 112 via wired means. Further combinations of standards for wireless or wired communication (including more than two standards for wireless and / or wired communication) are also possible.

[0041] The Server 210 can also be equipped for communication with WAN 104. The Server 210 can provide access to a cluster or server farm configured to offer one or more cloud-based services over the internet. For example, the Server 210 can also be equipped to communicate with service centers, each of which may include one or more computing devices (e.g., servers) configured to provide cloud-based services. Each service center could, for example, be configured to provide a service related to a specific application, such as a mapping application, a smart personal assistant application, an e-commerce application, a media streaming application, a gaming application, etc. It should be noted that the Server 210 is in Fig. Although shown as one possible example access port (and potential MPTCP endpoint), any of the various devices (alternatively or in combination with Server 210) can be used as intermediate access port devices / units to service centers, such as gateways, routers, firewalls, and / or one of various other "middleboxes," if desired. Furthermore, it should be noted that Server 210, although not explicitly shown, can contain any number of network interfaces for connecting to WAN 104, including one or more wired network interfaces and / or one or more wireless network interfaces.

[0042] Fig. Figure 3 illustrates the UE 106 communicating with the cellular base station 102 and the Wi-Fi access point 112. The UE 106 can be a device with multiple wireless network connectivity options, such as a mobile phone, handheld device, computer, or tablet, or virtually any type of wireless device.

[0043] The UE 106 can include a processor configured to execute program instructions stored in memory. The UE 106 can perform any of the procedure execution modes described herein by executing such stored instructions. Alternatively or additionally, the UE 106 can include a programmable hardware element, such as a field-programmable gate array (FPGA), configured to perform any of the procedure execution modes described herein or any portion thereof.

[0044] The UE 106 can be configured to communicate using any of several wireless communication protocols. For example, the UE 106 can be configured to communicate using at least one cellular communication protocol (such as CDMA2000, LTE, LTE-A, 5G-NR, etc.) and Wi-Fi. Other combinations of wireless and / or wired communication standards are also possible.

[0045] The UE 106 can include one or more antennas for communication using one or more wireless communication protocols. The UE 106 can use one or more parts of a receive and / or transmit chain for multiple wireless communication standards; for example, the UE 106 could be configured to communicate using one of CDMA2000 (1xRTT / 1xEV-DO / HRPD / eHRPD) or LTE / LTE-A using partially or fully shared wireless communication switching logic (e.g., using a shared radio device or at least shared radio components). As another example, the UE 106 could be configured to communicate using one of LTE / LTE-A or 5G-NR using partially or fully shared wireless communication switching logic (e.g., using a shared radio device or at least shared radio components).to communicate using a shared radio device or at least shared radio components. The shared radio device can be coupled with a single antenna or with multiple antennas (e.g., for MIMO) to perform wireless communication. Alternatively, the UE 106 can include separate transmit and / or receive chains for each wireless communication protocol with which it is configured to communicate (e.g., including separate antennas and other radio components). As another possibility, the UE 106 can include one or more radio devices or radio components shared by multiple wireless communication protocols and one or more radio devices or radio components used exclusively by a single wireless communication protocol.For example, the UE 106 could include a shared radio for communication using one of LTE / LTE-A or CDMA2000 1xRTT (or one of LTE or GSM) and separate radios for communication using either Wi-Fi or Bluetooth. For example, the UE 106 could also include a shared radio for communication using either 5G-NR or LTE / LTE-A and separate radios for communication using either Wi-Fi and / or Bluetooth. Other configurations are also possible. Figure 4 - Example block diagram of a lesson

[0046] Fig. Figure 4 illustrates a possible block diagram of a user equipment device (UE) 106. As shown, the UE 106 can include a system-on-chip (SOC) 300, which can contain sections for various purposes. As shown, the SOC 300 can, for example, include one or more processors 302, which can execute program instructions for the UE 106, and a display switching logic 304, which can perform graphics processing and provide display signals to the display 360. The one or more processors 302 can also be coupled with a memory management unit (MMU) 340, which can be configured to receive addresses from the one or more processors 302 and translate these addresses to locations in memory (e.g., memory 306, read-only memory (ROM) 350, flash memory 310).The MMU 340 can be configured to perform memory protection and page table translation or setup. In some embodiments, the MMU 340 can be enclosed as a section of one or more 302 processors.

[0047] The UE 106 can also include other circuits or devices, such as display circuit 304, radio device 330, connector interface 320, and / or display 360.

[0048] In the illustrated embodiment, ROM 350 can include a bootloader that is executed by the processor(s) 302 during bootup or initialization. As also shown, the SOC 300 can be coupled with various other circuits of the UE 106. For example, the UE 106 can include various types of memory, a connector interface 320 (e.g., for coupling with a computer system), the display 360, and switching logic for wireless communication (e.g., for communication using 5G-NR, LTE, CDMA2000, Bluetooth, Wi-Fi, NFC, GPS, etc.).

[0049] The UE 106 can include at least one antenna, and in some embodiments multiple antennas, for performing wireless communication with base stations and / or other devices. For example, the UE 106 can use antenna 335 to perform wireless communication. As mentioned above, the UE 106 can be configured in some embodiments to communicate wirelessly using a plurality of wireless communication standards or Radio Access Technologies (RATs).

[0050] As described herein, UE 106, according to embodiments of this disclosure, may include hardware and software components for implementing the disclosure. The processor 302 of UE 106 may be configured to implement all or part of the methods described herein, for example, by executing program instructions stored on a storage medium (e.g., a non-volatile, computer-readable storage medium). In other embodiments, the processor 302 may be designed as a programmable hardware element, for example, as an FPGA (user-programmable gate array) or as an ASIC (user-specific integrated circuit). Figure 5 - Example block diagram of a base station

[0051] Fig. Figure 5 illustrates an exemplary block diagram of a base station 102 according to some embodiments. It is noted that the base station is Fig. Figure 5 is merely an example of a possible base station. As explained, the base station 102 can include one or more processors 504 that can execute program instructions for the base station 102. The one or more processors 504 can also be coupled with a memory management unit (MMU) 540, which can be configured to receive addresses from the one or more processors 504 and translate these addresses to locations in memory (e.g., memory 560 and read-only memory (ROM) 550) or to other circuits or devices.

[0052] The base station 102 can include at least one network port 570. The network port 570 can be configured to establish a connection to a telephone network and provide access to the telephone network to a plurality of devices, such as the UEs 106.

[0053] The Network Port 570 (or an additional Network Port) can also be configured, or alternatively configured, to connect to a mobile network, such as a mobile network operator's core network. The core network can provide mobility-related services and / or other services to multiple devices, such as the UEs 106. In some cases, the Network Port 570 can connect to the telephone network via the core network, and / or the core network can provide a telephone network (e.g., between other UE devices served by the mobile network operator).

[0054] The base station 102 can include at least one antenna 534 and possibly several antennas. The antenna(s) 534 can be configured to operate as a wireless transceiver and can further be configured to communicate with the UEs 106 via a radio device 530. The antenna 534 communicates with the radio device 530 via a communication chain 532. The communication chain 532 can be a receive chain, a transmit chain, or both. The radio device 530 can be configured to communicate using various wireless telecommunications standards, including 5G-NR, LTE, LTE-A, UMTS, CDMA2000, Wi-Fi, etc.

[0055] The Base Station 102 can be configured to communicate wirelessly using multiple wireless communication standards. In some cases, the Base Station 102 may include multiple radio devices, enabling it to communicate using several wireless communication technologies. For example, the Base Station 102 may include an LTE radio device for LTE communication, as well as a Wi-Fi radio device for Wi-Fi communication. In such a case, the Base Station 102 can operate as both an LTE base station and a Wi-Fi access point. Alternatively, the Base Station 102 may include a multi-mode radio device capable of communicating using any of several wireless communication technologies (e.g., LTE and Wi-Fi).The Base Station 102 may include hardware and software components for implementing or supporting the implementation of features described herein. Figure 6 - Access Point Block Diagram

[0056] Fig. Figure 6 illustrates an example block diagram of an access point (AP) 112. It is noted that the block diagram of the AP is from Fig. Figure 6 is only one example of a possible system. As explained, the access point 112 can include one or more processors 604 that can execute program instructions for the AP 112. The processor or processors 604 can also be coupled to a memory management unit (MMU) 640, which can be configured to receive addresses from the processor(s) 604 and translate these addresses to locations in memory (e.g., memory 660 and read-only memory (ROM) 650) or to other circuits or devices.

[0057] The AP 112 can include at least one Network Port 670. The Network Port 670 can be configured to connect to a wired network and provide internet access to multiple devices, such as the UEs 106. For example, the Network Port 670 (or an additional Network Port) can be configured to connect to a local area network, such as a home or business network. For example, the Network Port 670 can be an Ethernet port. The local area network can then provide connectivity to additional networks, such as the internet.

[0058] The AP 112 can include at least one antenna 634, which can be configured to operate as a wireless transceiver and can further be configured to communicate with the mobile device 106 via a wireless communication switching logic 630. The antenna 634 communicates with the wireless communication switching logic 630 via the communication chain 632. The communication chain 632 can include one or more receive chains, one or more transmit chains, or both. The wireless communication switching logic 630 can be configured to communicate via Wi-Fi or WLAN, e.g., 802.11.The switching logic for wireless communication 630 can also be configured, or alternatively configured, to communicate via various other wireless communication technologies, including but not limited to Long-Term Evolution (LTE), LTE Advanced (LTE-A), LLA, 5G-NR, Global System for Mobile (GSM), Wideband Code Division Multiple Access (WCDMA), CDMA2000, etc., for example, if the AP is located in the same place as a base station in the case of a small cell or in other cases where it may be desirable for the AP 112 to communicate via various different wireless communication technologies.

[0059] AP 112 may include hardware and software components for implementing or supporting the implementation of features described herein. ROHC compression for MPTCP packets

[0060] In existing implementations, the Robust Header Compression (ROHC) protocol is used to reduce bandwidth usage on network connections with limited capacity and / or higher costs, such as mobile networks. ROHC defines a lossless compression scheme for network headers. The ROHC protocol is capable of compressing various Internet packets, such as IPv4, IPv6, and TCP packets. It is important to note that the ROHC protocol only compresses network headers and exploits the information redundancy within them. As described in Fig. As shown in Figure 7A, the ROHC compressor can parse uncompressed packets at 702, and at 704 the ROHC compressor can assign the parsed uncompressed packets to a stream or chain (e.g., packets with redundancy between packets). At 706 the ROHC compressor can generate corresponding ROHC packets (e.g., by appending non-redundant (or irregular) elements as they appear in the uncompressed packets), and at 708 the ROHC compressor can transfer the corresponding ROHC packets to an associated ROHC decompressor. As shown in Figure 7A, the ROHC compressor can then be configured to process the packets in a stream or chain (e.g., packets with redundancy between packets). Fig. As shown in Figure 7B, an ROHC decompressor can receive ROHC packets at 710, and at 712 the ROHC decompressor can parse the ROHC packets. At 714 the ROHC decompressor can decode packet fields of the ROHC packets according to the ROHC protocol, and at 716 the ROHC can form uncompressed packets based on the decoded packet fields.

[0061] As in Fig. As shown in Figure 8A, a ROHC compressor can operate in one of three states. As shown, a ROHC compressor can operate in an initialization and update state at state 810. Once context with a ROHC decompressor is established, the ROHC compressor can transition to either state 812 or 814. State 812 represents a first-order state, and state 814 represents a second-order state. As the ROHC compressor becomes more familiar with the context of the ROHC decompressor, it can transition from state 812 to 814, which represents an increase in packet header compression. In contrast, the ROHC compressor can transition from state 814 to either state 812 or 810 (and analogously from state 812 to state 810) when the ROHC compressor becomes less familiar with the context of the ROHC decompressor (e.g., through feedback packets indicating fault states at the ROHC decompressor).Furthermore, in some cases the ROHC compressor can periodically transition from a higher state (e.g., states 814, 812) to a lower state (e.g., states 812, 810) to ensure context validity at the ROHC decompressor.

[0062] Similarly, as in Fig. As shown in Figure 8B, a ROHC decompressor can operate in one of three states. As explained, an ROHC decompressor can initially operate in a contextless state at state 820. Once the ROHC decompressor has received and successfully decompressed an initialization and update packet (e.g., generated by an ROHC compressor in state 810) containing both static and dynamic information, the decompressor can generate context information and transition to a full-context state at state 824. The ROHC decompressor can then transition to a lower state (e.g., states 822, 820) after an error state. Note that when transitioning from state 824 to a lower state, the ROHC decompressor may first transition to state 822 (e.g., a static context state) and attempt to recover and transition back to state 824.However, if the fault condition persists, the ROHC decompressor may revert to the contextless state 820, causing the ROHC compressor to revert to state 810.

[0063] Furthermore, the ROHC protocol defines three operating modes and the selection of an operating mode can be based on one or more parameters, including the availability of (a) feedback channel(s), error probabilities and / or variations in header size. Fig. Figure 9A illustrates a unidirectional operating mode of a ROHC compressor, Fig. Figure 9B illustrates a bidirectional optimistic operating mode of a ROHC compressor and Fig. Figure 9C illustrates a reliable bidirectional operating mode of a ROHC compressor. As shown in Fig. As shown in Figure 9A, the ROHC compressor starts in state 810 and transmits several initialization and update packets (IR packets) to the ROHC decompressor, then transitions to state 814 (e.g., at 910). It's important to note that in a unidirectional operating mode of the ROHC compressor, the packets are sent in one direction only, from the ROHC compressor to the ROHC decompressor. Once state 814 is reached, a timeout / update mechanism can be activated to periodically transition the ROHC compressor from state 814 to state 812 (e.g., at 920). Additionally, a timeout mechanism can be activated during state 814 to return the ROHC compressor to state 810 if necessary (e.g., at 912). Once state 812 is reached, another time limit mechanism can be activated to transition from state 812 to state 810 (e.g., at 916), for example, if required.Furthermore, if the state machine does not trigger the timeout in state 812, the ROHC compressor can return to state 814 (e.g., at 918). Additionally, if the state machine returns to state 810, it can optionally return to either state 812 (e.g., at 914) or state 814 (e.g., at 910). It should be noted that if the ROHC compressor receives feedback from the ROHC decompressor, it can determine the transition to one of the two bidirectional operating modes.

[0064] Thus, as in Fig. As shown in Figure 9B, once the context of the ROHC decompressor is established (e.g., at 930), the ROHC compressor transitions from state 810 to state 814. While in state 814, the ROHC compressor can remain there if it receives acknowledgments (ACKs) from the ROHC decompressor (e.g., at 942). However, if the ROHC compressor receives a negative ACK (NACK) or a request to update the context, it may transition to state 812 (e.g., at 940). Furthermore, if the ROHC compressor receives a static NACK while in state 814, it may revert to state 810 (e.g., at 932). Once the ROHC compressor is in state 812, it can return to state 814 (e.g., at 938) if it receives an ACK. Conversely, if the ROHC compressor receives a NACK or a static NACK, it can transition to state 810 (e.g., at 936).Once the ROHC compressor is in state 810, it can optionally return to either state 812 (e.g. at 934) or state 814 (e.g. at 930).

[0065] With reference to Fig. 9C allows the ROHC compressor to transition from state 810 to state 814 in bidirectional, reliable mode once the ROHC decompressor's context has been established and an ACK has been received from the ROHC decompressor (e.g., at 950). Once in state 814, the ROHC compressor can remain in state 814 if it receives acknowledgments (ACKs) from the ROHC decompressor (e.g., at 942). However, if the ROHC compressor receives a negative ACK (NACK) or a request to update the context, it can transition to state 812 (e.g., at 940). Furthermore, if the ROHC compressor receives a static NACK while in state 814, the ROHC compressor can revert to state 810 (e.g., at 932). Once the ROHC compressor is in state 812, it can revert to state 814 (e.g., at 958) if it receives an ACK.Conversely, if the ROHC compressor receives a NACK or a static NACK (e.g., at 936), it can transition to state 810. Once the ROHC compressor is in state 810, it can optionally return to either state 812 (e.g., at 954) or state 814 (e.g., at 950) after receiving an ACK from the ROHC decompressor.

[0066] As mentioned previously, the ROHC protocol was implemented for TCP packet compression. Fig. Figures 10-13 illustrate different structures and formats of TPC and MPTCP headers. Fig. Figure 10 illustrates, for example, a TCP packet format according to IETF RFC 793. It should be noted that, as shown, a check mark can represent a bit position. The TCP packet format includes header fields for source port (e.g., 16 bits for a source port number), destination port (e.g., 16 bits for a destination port number), sequence number (e.g., 32 bits for a sequence number of the first data byte in a segment), acknowledgment number (e.g., 32 bits for the value of the next sequence number that a sender of the segment expects to receive), data offset (e.g., 4 bits for a number of 32-bit words in the TCP header), reserved (e.g., 6 bits reserved for future use), control bits (e.g., 6 bits for controls such as URG (urgency pointer field significant), ACK (acknowledgment field significant), PSH (push function), RST (reset link), SYN (synchronize sequence numbers), and FIN (no more data from sender)), and windows (e.g.,16 bits for a number of data bytes starting with one specified in the acknowledgment field that the sender of the segment is willing to accept), checksum (e.g., 16 bits of the one's complement of the one's complement sum of all 16-bit words in the header and body), urgency pointer (e.g., 16 bits to transmit a current value of the urgency pointer as a positive offset from the sequence number in the segment), options (e.g., a variable number of bits in multiples of 8 bits), padding (e.g., a variable number of bits to ensure that the TCP header ends and the data begins on a 32-bit boundary). As explained, the data follows the header.

[0067] IETF RFC 6846 specifies various TCP header fields available for ROHC compression. As in Fig. As shown in Figure 11, the following TCP header fields, for example, are available for compression: IPv4 Identifier (IP ID), TCP Sequence Number (SN), TCP Acknowledge Number, TCP Reserved, TCP ECN Flags (ECN), TCP Window, and TCP Options. Further details are provided in Fig. Figure 11 shows that the supported TCP options include Maximum Segment Size (MSS), Window Scale (WSCALE), Selective Acknowledges (SACK) allowed, TCP SACK (SACK) and TCP Timestamp (TS).

[0068] Fig. Figure 12 illustrates an MPTCP options format of a TCP header according to IETF RFC 6824. IETF RFC 6824 defines a Multipath TCP Protocol (MPTCP Protocol) as a set of extensions to regular TCP to provide a multipath TCP service that allows a transport connection to operate over multiple paths simultaneously. For example, MPTCP can extend the use of the TCP options field, and all MPTCP signaling and control information can be carried in the TCP options field. Furthermore, since the field's data offset is 4 bits (0-15) and the maximum size of the TCP header is 60 bytes, the options field can occupy a maximum of 20 bytes. As shown in Figure 12, the options field can be used to display the following information: Fig. As shown in Figure 12, the TCP option fields include, for example, a "Type" field, a length field, a subtype field, and subtype-specific data (with variable lengths). It should be noted that a single TCP option number (e.g., the "Type" field) is assigned to MPTCP, and individual messages can be identified by a value in the subtype field.

[0069] Fig. Figure 13 illustrates MPTCP subtypes according to IETF RFC 6824. For example, a value of 0x0 indicates multipath capability (e.g., as defined in Section 3.1 of IETF RFC 6824), a value of 0x1 indicates adding a connection (e.g., as defined in Section 3.2 of IETF RFC 6824), a value of 0x2 is a data sequence signal (e.g., as defined in Section 3.3 of IETF RFC 6824), a value of 0x3 indicates adding an address (e.g., as defined in Section 3.4.1 of IETF RFC 6824), a value of 0x4 indicates removing an address (e.g., as defined in Section 3.4.2 of IETF RFC 6824), and a value of 0x5 indicates removing the To change the subflow priority (e.g., as defined in section 3.3.8 of IETF RFC 6824), a value of 0x6 indicates a fallback (e.g., as defined in section 3.6 of IETF RFC 6824), a value of 0x7 indicates a fast close (e.g., as defined in section 3.5 of IETF RFC 6824), the values ​​0x8 to 0xe are unassigned and one value of Oxf is reserved.

[0070] With the development of TCP, further options came into use, such as the MPTCP option described above. MPTCP is widely used on mobile devices; however, ROHC compression methods, as defined in IETF RFC 6824, do not explicitly support MPTCP packets, rendering compression of MPTCP packet headers ineffective. Furthermore, current methods often cause errors within the decompressor state machine when attempting ROHC compression of MPTCP packet headers, resulting in delays and / or failures in the transmission of MPTCP packets.

[0071] Thus, embodiments of this disclosure define (specify) a ROHC compression process and algorithm dedicated to MPTCP. In some embodiments, as described by the state machine 1400 in Fig. As shown in Figure 14, three additional modes of ROHC header compression for MPTCP can be enabled: a non-compression mode (e.g., state 1410), a safe compression mode (e.g., state 1420), and a full compression mode (e.g., state 1430). In some embodiments, a device such as the UE 106 described above can start in non-compression mode 1420 if both a compressor (e.g., contained in the device) and a decompressor (e.g., contained in a base station, such as base station 102 or AP 112) support ROHC-TCP, but the decompressor encounters an error condition while attempting to decompress TCP packets with the MPTCP option. In some embodiments, the non-compression mode can be entered in response to the decompressor's error feedback to the compressor, e.g., if the decompressor fails to decompress TCP packets with the MPTCP option enabled. B. when the compression operates in one of the bidirectional operating modes.In such cases, the compressor can only compress TCP packets without the MPTCP option to avoid future error feedback.

[0072] In some embodiments, the device (e.g., UE 106) can select the safe compression mode (e.g., state 1420) (or transition to it, e.g., at 1401). In such embodiments, the device can initially compress TCP packets without the MPTCP option and leave the MPTCP option portion uncompressed. In such embodiments, the device can transmit the MPTCP option in a compressed list. Furthermore, in some embodiments, the safe compression mode can initially be used during MPTCP initiation (e.g., during MPTCP connection establishment). In some embodiments, the same compression mode can be used when MPTCP address addition and / or MPTCP address removal is required.

[0073] In some embodiments, during safe compression mode 1420 and after context initiation (e.g., connection establishment) and presentation of the MPTCP option to the decompressor, irregular content (e.g., including the MPTCP option) can be sent (transmitted by the device) as part of an irregular chain, provided that the structure and content of the compressed list are unchanged and that the structure and content include the MPTCP option, the subtype, and subtype-specific data. In other words, if the structure and content of the compressed list are unchanged, no information about the compressed list needs to be sent in compressed base headers, and the irregular content can be sent (transmitted) as part of the irregular chain, including the MPTCP option.It should be noted that in some embodiments the MPTCP content can only be considered unchanged if the type, length, subtype and subtype-specific data are unchanged.

[0074] It should also be noted that a compressed header chain functions to group fields based on similar characteristics. For example, a chain is formed by appending an element to a chain for each field, in the order of its occurrence in an uncompressed packet. In some implementations, an irregular chain for a compressed MPTCP packet may contain irregular chain elements for the TCP option. It is important to note that these chain elements may be placed after irregular chain elements of the TCP header.

[0075] In some embodiments, during safe compression mode 1420 and after context initiation (e.g., connection establishment) and presentation of the MPTCP option to the decompressor, irregular content (e.g., including the MPTCP option) can be sent (transmitted by the device) as part of an irregular chain if the structure of the compressed list is constant and the content defined within the irregular format for options has changed. In other words, if the structure of the compressed list remains unchanged, but the content defined in the irregular format for options has changed, no information about the compressed list needs to be sent in compressed base headers, and the irregular content can be sent (transmitted) as part of the irregular chain, including the MPTCP option.It should be noted that in some implementations, the MPTCP content may be considered modified if any byte has changed in length, subtype and / or subtype-specific data.

[0076] In some embodiments, during safe compression mode 1420 and after context initiation (e.g., connection establishment) and presentation of the MPTCP option to the decompressor, a compressed list and irregular content can be sent (transmitted by the device) if the structure of the list changes. In other words, a compressed list can be sent in a compressed base header, including a representation of its structure and order. Furthermore, content defined within the irregular format of an option can be sent as part of the irregular chain, provided that the content of the element is not part of the compressed list.

[0077] In some embodiments, the device (e.g., UE 106) can select (or transition to, e.g., at state 1430) the full compression mode. In such embodiments, the device can compress the entire MPTCP packet, including the TCP header, TCP options, and MPTCP option. It should be noted that in some embodiments, the full compression mode can be enabled during the MPTCP data transmission phase (e.g., after context initiation). In some embodiments, the full compression mode can be enabled only for MPTCP subtype 0x02.

[0078] In some embodiments, during full compression mode 1430 and after context initiation (e.g., connection establishment) and presentation of the MPTCP option to the decompressor (e.g., the compressor has transmitted a complete compressed list of options), no information about the compressed list is sent in compressed base headers (e.g., transmitted by the device) if the structure and content of the compressed list are unchanged. In other words, if the structure and content of the compressed list are constant, the compressed list may not be transmitted, for example, to save transmission overhead.

[0079] In some embodiments, during full compression mode 1430 and after context initiation (e.g., connection establishment) and presentation of the MPTCP option to the decompressor (e.g., the compressor has transmitted a complete compressed list of options), irregular content (e.g., the MPTCP option) can be sent (transmitted by the device) as part of an irregular chain if the structure of the compressed list is constant and the content defined within the irregular format for options has changed. In other words, if the structure of the compressed list is unchanged (e.g., constant), but the content defined in the irregular format for options has changed, no information about the compressed list needs to be sent in compressed base headers, and the irregular content can be sent (transmitted) as part of the irregular chain.It should be noted that in some implementations the MPTCP content may be considered modified if any byte has changed in length, subtype and / or subtype-specific data.

[0080] In some embodiments, during full compression mode 1430 and after context initiation (e.g., connection establishment) and presentation of the MPTCP option to the decompressor, a compressed list and irregular content can be sent (transmitted by the device) if the structure of the list changes. In other words, a compressed list can be sent in a compressed base header, including a representation of its structure and order. Furthermore, content defined within the irregular format of an option can be sent as part of the irregular chain, provided that the content of the element is not part of the compressed list.

[0081] It should be noted that in some versions (e.g., UE 106), the device (e.g., UE 106) can transition from non-compression mode 1410 to safe compression mode 1420 (and vice versa) due to feedback (positive or negative ACKs) from the decompressor. Furthermore, the device (e.g., 1402) can transition from safe compression mode 1420 to full compression mode 1430. It should also be noted that if a fault condition occurs (or persists) during safe compression mode 1420, the device (e.g., 1403) can transition to non-compression mode 1410.

[0082] In some embodiments, a device (e.g., UE 106) can implement table-based element compression. As in Fig. As shown in Figure 15, a table can, for example, relate an index to an element. In some embodiments, a compressor (enclosed in or implemented by the device) can maintain the table. Furthermore, a decompressor (enclosed in or implemented on a base station, such as Base Station 106 or AP 112) can also maintain a table of all received (index, element) pairs. Thus, as shown in Fig. Figure 14 shows that an (index, element) pair of (7, MPTCP) specifies an MPTCP option. Furthermore, an (index, element) pair of (0, NOP) can specify a no-operation option, an (index, element) pair of (1, EOL) can specify the termination of option parsing, an (index, element) pair of (2, MSS) can specify the maximum segment size option, an (index, element) pair of (3, window scale) can specify a window scale option, an (index, element) pair of (4, timestamp) can specify a timestamp option, an (index, element) pair of (5, bag-allowed) can specify a bag-allowed option, an (index, element) pair of (6, bag) can specify a bag option, and indices 8-15 can specify various generic options.

[0083] Fig. Figure 16 illustrates a block diagram of an example of a method for ROHC compression of MPTCP packets according to some embodiments. The one in Fig.The method shown in Figure 16 can be used in conjunction with any of the systems or devices shown in the preceding figures, in addition to other devices. In various embodiments, some of the method elements shown can be performed simultaneously, in a different order than shown, or omitted. Furthermore, additional method elements can be performed as desired. As shown, this method can operate as follows.

[0084] At 1602, a compressor (e.g., one or more processors or processing logic of a UE, such as UE 106) can determine that the first segment of a stream of data packets is formatted according to a Multipath Transfer Protocol (MPTCP). In other words, the compressor can determine, for example, based on the contents of a header of one or more data packets, that the data packets are formatted using the Transfer Control Protocol (TCP) and an MPTCP option enabled by the TCP options. For example, initial information included in the headers of the data stream can indicate that the first segment of the stream of data packets is formatted according to TCP with the MPTCP option enabled.

[0085] At 1604, the compressor can establish a data transmission context with a corresponding decompressor. It should be noted that the decompressor can be housed in (or integrated into) a base station or access point, such as the base station 106 or AP 112 described above.

[0086] At 1606, the context could indicate that the corresponding decompressor supports MPTCP and the procedure can continue at 1608. In other words, the context could indicate that the corresponding decompressor is configured to decompress data packets containing compressed MPTCP options. Alternatively, at 1616, the context could indicate that the corresponding decompressor does not support MPTCP and the procedure can continue at 1618. In other words, the context could indicate that the corresponding decompressor is not configured to decompress data packets containing compressed MPTCP options. In some embodiments, the indication can be provided by feedback received from the corresponding decompressor, such as an error message.

[0087] At version 1608, if the corresponding decompressor supports MPTCP, ROHC can be performed in a first or second compression mode. The compression can generate a chain of compressed data packets. In some embodiments, a first compression mode may consist of transmitting the first section of the data packet stream with partial ROHC and transmitting a second section of the data packet stream with ROHC. It should be noted that the second section of the data packet stream may include data packets in which the MPTCP option is not enabled. In some embodiments, partial ROHC may involve performing ROHC on a data packet without the MPTCP option and transmitting the MPTCP option as part of a compressed list.In some embodiments, the second compression mode can correspond to transmitting the first part of the data packet stream with ROHC and transmitting the second part of the data packet stream with ROHC. In some embodiments, to perform the ROHC in the second compression mode, the compressor can first detect that the first part of the data packet stream includes an MPTCP subtype (e.g., subtype 0x02) that supports the second compression mode.

[0088] At 1610, the compressor can transmit the chain of compressed data packets.

[0089] In version 1618, if the corresponding decompressor does not support MPTCP, the compressor can operate in a third compression mode where the first part of the data packet stream is not compressed, and the first part of the data packets is transmitted without compression. Furthermore, in version 1620 ROHC, the compressor can perform compression on the second part of the data packet stream (e.g., data packets without the MPTCP option enabled) and transmit the second part as compressed data packets.

[0090] Embodiments of the present disclosure can be realized in a variety of forms. For example, some embodiments can be realized as a computer-implemented method, a computer-readable storage medium, or a computer system. Other embodiments can be implemented using one or more user-adapted hardware devices, such as ASICs. Still other embodiments can be realized using one or more programmable hardware elements, such as FPGAs.

[0091] In some embodiments, a non-volatile, computer-readable storage medium may be configured to store program instructions and / or data, wherein the program instructions, when executed by a computer system, cause the computer system to perform a procedure, e.g., any one of the procedure execution forms described herein, or any combination of the procedure execution forms described herein, or any subset of any one of the procedure execution forms described herein, or any combination of such subsets.

[0092] In some embodiments, a device (e.g., a UE 106) can be configured to include a processor (or a set of processors) and a storage medium, wherein program instructions are stored on the storage medium, the processor being configured to read and execute the program instructions from the storage medium, and the program instructions being executable to implement a method, e.g., any of the various method implementations described herein (or any combination of the method implementations described herein, or any subset of any of the method implementations described herein, or any combination of such subsets). The device can be implemented in one of many forms.

[0093] Although the embodiments have been described above in considerable detail, numerous variations and modifications are apparent to the person skilled in the art after a full understanding of the foregoing disclosure. It is intended that the following claims be interpreted to include all such variations and modifications.

Claims

[1] Methods for Robust Header Compression, ROHC compression, of Multipath Transmission Control Protocol data packets, MPTCP data packets, comprising: Determine (1602), based on initial information contained in the headers of a stream of data packets, that an initial section of the stream of data packets is formatted according to the transmission control protocol, TCP, with an enabled multipath TCP option, MPTCP option; Establishing (1604) a context with a suitable decompressor, wherein, if the context indicates that the suitable decompressor supports decompression of TCP data packets with the MPTCP option enabled, the procedure further comprises: Performing (1608) a robust header compression, ROHC compression, on the stream of data packets, thereby generating a chain of compressed data packets, wherein in a first compression mode the MPTCP option is not compressed, wherein in a second compression mode the MPTCP option is compressed; and Transferring the chain of compressed data packets to the appropriate decompressor. [2] The method of claim 1, wherein, if the context indicates that the relevant decompressor does not support ROHC decompression of TCP data packets with the MPTCP option enabled, the method further comprises: Transmitting (1618) the first part of the stream of data packets with the MPTCP option enabled without compression; and Transmitting (1620) a second section of the stream of data packets with the MPTCP option not enabled using ROHC. [3] Method according to claim 2, wherein producing (1604) the context with the decompressor comprises: Receiving an error indicating that the corresponding decompressor does not support ROHC decompression of TCP data packets with the MPTCP option enabled. [4] Method according to any one of claims 1 to 3, wherein the method in the first compression mode further comprises: Transmitting the first part of the stream of data packets with the MPTCP option enabled with partial ROHC; and Transmitting a second section of the stream of data packets with the MPTCP option disabled using ROHC. [5] The method of claim 4, wherein the partial ROHC comprises: Performing ROHC on a data packet without the MPTCP option; and Transmitting the MPTCP option as part of a compressed list. [6] Method according to any one of claims 1 to 5, wherein in the second compression mode the method further comprises: Transmitting the first part of the stream of data packets with the MPTCP option enabled using ROHC; and Transmitting a second section of the stream of data packets with the MPTCP option disabled using ROHC. [7] Method according to any one of claims 1 to 6, wherein performing the ROHC compression in the second compression mode comprises: Determine that an initial section of the stream of data packets includes an MPTCP subtype that supports the second compression mode. [8] Method according to claim 7, wherein the MPTCP subtype comprises subtype 0x02. [9] Method according to any one of claims 1 to 8, further comprising: Maintaining a table of (index, element) pairs of TCP options included in the headers of the data stream. [10] Method according to claim 9, wherein the MPTCP option corresponds to a table index of 7. [11] Method according to any one of claims 1 to 10, further comprising: before transferring the compressed data packets to the corresponding decompressor: Transmitting a partially compressed header, where the partially compressed header does not include compression of the MPTCP option; and Receiving a notification from the relevant decompressor that the relevant decompressor supports MPTCP compression. [12] Method according to any one of claims 1 to 11, wherein the first compression mode is a safe compression mode; and wherein the second compression mode is a full compression mode. [13] Method according to any one of claims 1 to 12, wherein the method further comprises in a third compression mode: Transmitting the first part of the stream of data packets with the MPTCP option enabled without compression; and Transmitting the second part of the stream of data packets with the MPTCP option disabled using ROHC. [14] User equipment device, U, (106), comprising: at least one antenna for conducting wireless communication; at least one radio device coupled to the at least one antenna, wherein the at least one radio device is configured to perform mobile communication with a base station; and one or more processors coupled to the at least one radio device, wherein the one or more processors and the at least one radio device are configured to perform wireless communications using the at least one antenna; wherein one or more processors are configured as a data compressor, wherein the data compressor is configured to perform a method according to any one of claims 1 to 13. [15] Non-volatile computer-readable storage medium storing program instructions that can be executed by a processing circuit (302) of a user equipment device, UE, (106) to carry out a method according to any one of claims 1 to 13.

Images