WO2016101171A1

WO2016101171A1 - Inter-sim aggregation

Info

Publication number: WO2016101171A1
Application number: PCT/CN2014/094789
Authority: WO
Inventors: Xipeng Zhu; Lizhong Jin; Huichun LIU; Jilei Hou; Jing Li
Original assignee: Qualcomm Incorporated
Priority date: 2014-12-24
Filing date: 2014-12-24
Publication date: 2016-06-30
Also published as: WO2016101631A1

Abstract

A method for aggregating data connections may include: configuring a plurality of tunnels for connections between the first and second SIMs of the mobile communication device and a network gateway; uplinking data packets for the one data flow from the first SIM and the second SIM to the network gateway through the plurality of tunnels; aggregating the connections at layer 2, 3, or 4 of the IP protocol stack of the network gateway; and reordering the data packets of the one data flow.

Description

INTER-SIM AGGREGATION

BACKGROUND

3GPP standards support five carrier-carrier aggregation (5C-CA) for packet-switched (PS) service， for example LTE. 5C-CA enables aggregating up to 100MHz frequency for data transmission. Future 3GPP standards may support greater carrier aggregation， for example up to 32C-CA. However， network operators typically only have frequency resource to support 2C or 3C-CA. Further， wireless connections are usually not reliable as a result of fading， mobility， congestion， and interference.

SUMMARY

Apparatuses and methods for inter-SIM aggregation are provided.

According to various embodiments there is provided a method. In some embodiments， the method may include： configuring a plurality of tunnels for point-to-point connections between first and second subscriber identity modules (SIMs) of the mobile communication device and a network gateway at layer 2 of an IP protocol stack； uplinking data packets for the one data flow from the first SIM and the second SIM to the network gateway through the plurality of tunnels； aggregating the point-to-point connections at layer 2 of the IP protocol stack of the network gateway； and reordering the data packets of the one data flow.

According to various embodiments there is provided a method in some embodiments， the method may include： configuring a plurality of tunnels for point-to-point connections between the network gateway and first and second subscriber identity modules (SIMs) of a mobile communication device at layer 2 of an IP protocol stack； downlinking data packets for the one data flow from the network gateway to the first SIM and the second SIM； aggregating the point-to-point connections at layer 2 of the IP protocol stack of the mobile communication device； and reordering the packets of the one data flow.

According to various embodiments there is provided a method in some embodiments， the method may include： generating a plurality of IP tunnels with different care-of addresses (CoAs) for an IP flow between a mobile communication device and a network gateway； uplinking data packets out of sequence from the first and second SIMs to the network gateway through the plurality of tunnels； receiving the data packets out of sequence at the network gateway； and reordering the packets based on the sequence numbers in the multipath headers.

According to various embodiments there is provided a method in some embodiments， the method may include： binding one or more CoAs to an IP flow using Dual Stack Mobile Intemet Protocol version 6 (DSMIPv6) with multipath (MP) headers having sequence numbers； downlinking data packets out of sequence from the network gateway to the first and second SIMs through the plurality of tunnels； receiving the data packets out of sequence at the first and second SIMs； and reordering the packets based on the sequence numbers in the multipath headers.

According to various embodiments there is provided a method in some embodiments， the method may include： generating a plurality of tunnels between a network gateway and first and second SIMs； routing a data flow through the plurality of tunnels between the network gateway and the first and second SIMs； and aggregating the data packets from the first SIM and the second SIM on layer 4 of the IP protocol stack.

Other features and advantages of the present inventive concept should be apparent from the following description which illustrates by way of example aspects of the present inventive concept.

BRIEF DESCRIPTION OF THE DRAWINGS

Aspects and features of the present inventive concept will be more apparent by describing example embodiments with reference to the accompanying drawings， in which：

FIG. 1 is a block diagram illustrating a wireless communication device according to various embodiments；

FIG. 2 is a diagram illustrating an example network configuration according to various embodiments；

FIG. 3 is a diagram illustrating a protocol stack for the example network architecture illustrated in FIG. 2 according to various embodiments；

FIG. 4 is a diagram illustrating an example network architecture without an AGW configured to have a dedicated APN according to various embodiments；

FIG. 5 is a diagram illustrating a protocol stack for the example network architecture illustrated in FIG. 4 according to various embodiments；

FIG. 6A is a flowchart illustrating a method for data aggregation on an uplink according to various embodiments；

FIG. 6B is a flowchart illustrating a method for data aggregation on a

downlink according to various embodiments；

FIG. 7 is a table illustrating an example of different IP flows carried over different CoAs according to various embodiments；

FIG. 8 is a diagram illustrating a protocol stack used with a UDP tunnel according to various embodiments；

FIG. 9 is a diagram illustrating an example of an MP header used in multi-path encoding according to various embodiments；

FIG. 10 is a diagram illustrating an example DSMIPv6 based IP multi-path solution on the example network architecture of FIG. 2 according to various embodiments；

FIG. 10 is a diagram illustrating a protocol stack according to various embodiments；

FIG. 1 lA is a flowchart illustrating a method 1100 for data aggregation on an uplink according to various embodiment；

FIG. 1 lB is a flowchart illustrating a method 1150 for data aggregation on a downlink according to various embodiments；

FIG. 12 is a diagram of a protocol stack according to various embodiments；

FIG. 13 is a diagram of a protocol stack 1300 illustrating an example of MPTCP time division duplex (TDD) LTE + frequency division duplex (FDD) LTE inter-SIM carrier aggregation according to various embodiments；

FIG. 14A is a flowchart illustrating a method 1400 for data aggregation on an uplink according to various embodiments； and

IG. 14B is a flowchart illustrating a method 1450 for carrier aggregation on a downlink according to various embodiments.

DETAILED DESCRIPTION

While certain embodiments are described， these embodiments are presented by way of example only， and are not intended to limit the scope of protection. The apparatuses， methods， and systems described herein may be embodied in a variety of other forms. Furthermore， various omissions， substitutions， and changes in the form of the example methods and systems described herein may be made without departing from the scope of protection.

Wireless connections for mobile communication devices may not be reliable， for example， due to： fading， mobility， congestion， and interference. However， some mobile applications require very reliable PS connections (e.g.， remote control applications， online games， video surveillance， etc. ) . PS + PS Dual Subscriber Identity Module (SIM) Dual Active (DSDA) mobile communication devices， as well as other multi-SIM multi-active (MSMA) mobile communication devices， support concurrent PS + PS data activities on different subscriptions. P1 and P2 may be defined as the reliability of a first PS connection (PS 1) (e.g.， using a first SIM (SIM1) ) and a second PS connection (PS2) (e.g.， using a first SIM (SIM2) ) ， respectively. IfP1 ＝ P2 ＝ 99％， then the availability of PS 1 + PS2 aggregation would be： 1 - (1-P 1) (l-P2) ＝ 99.99％. The reliability may be further improved by aggregating more PS connections.

High data throughput may also be realized through inter-SIM aggregation. On a 5C-CA platform， the peak downlink (DL) data throughput may be up to 5 ×l50 Mbps ＝ 750Mbps with PS1 + PS2 aggregation. Uplink (UL) data throughput may be aggregated as well.

FIG. 1 is a block diagram illustrating a wireless communication device 100 according to various embodiments. As illustrated in FIG. 1， the wireless communication device 100 may include a control unit 110， a first communication unit 120， a second communication unit 125， a first antenna 130， a second antenna 135， a first SIM 140， a second SIM 150， a user interface device 170， and a storage 180.

The wireless communication device 100 may be， for example but not limited to， a mobile telephone， smartphone， tablet， computer， etc. ， capable of communication with one or more wireless networks. One of ordinary skill in the art will appreciate that the wireless communication device 100 may include one or more transceivers (communication units) and may interface with one or more antennas without departing from the scope of the present inventive concept.

The first communication unit 120 may include， for example， but not limited to， a first transceiver (not shown) having a first transmitter (not shown) and a first receiver (not shown) . The second communication unit 125 may include， for example， but not limited to， a second transceiver (not shown) having a second transmitter (not shown) and a second receiver (not shown) . in active mode， a transceiver receives and transmits signals. In idle mode， a transceiver receives but does not transmit signals.

One of ordinary skill in the art will appreciate that other configurations of the communication units are possible without departing from the scope of the present inventive concept. For example， if aggregation is needed for DL traffic only， the mobile communication device may share one transmitter between subscriptions since concurrent transmission on the subscriptions is not required.

A SIM (e.g.， 140， 150) in various embodiments may be a Universal Integrated Circuit Card (UICC) that is configured with SIM and/or USIM applications， enabling access to GSM and/or UMTS networks. Alternatively， in a CDMA network， a SIM may be a UICC removable user identity module (R-UIM) or a CDMA subscriber identity module (CSIM) on a card. A SIM card may have a CPU， ROM， RAM， EEPROM and I/O circuits. However， a SIM may be implemented within a portion of memory of a multi-SIM， Multi-Active (MSMA) mobile communication device (e.g.， a DSDA mobile communication device) ， and thus need not be a separate or removable circuit， chip， or card.

As part of the network provisioning information， a SIM may store home identifiers (e.g.， a System Identification Number (SID) /Network Identification Number (NID) pair， a Home Public Land Mobile Network (HPLMN) code， etc. ) to indicate the SIM card network operator provider.

The first SIM 140 may associate the first communication unit 120 with a first subscription (Subl) 192 on a first communication network 190 and the second SIM 150 may associate the second communication unit 125 with a second subscription (Sub2) 197 on a second communication network 195. For convenience， throughout this disclosure Subl is associated with the first communication unit 120 and Sub2 is associated with the second communication unit 125. One of ordinary skill in the art will appreciate that either subscription may be associated with either communication unit without departing from the scope of the present inventive concept. Further， one of ordinary skill in the art will appreciate that the present inventive concept may be extended to mobile communication devices having more than two SIMS (i.e.， multi-SIM， multi-active (MSMA) mobile communication devices) without departing from the scope of the present inventive concept.

The first communication network 190 and the second communication network 195 may be operated by the same or different service providers， and/or may support the same or different radio access technologies (RATs) ， for example， but not limited to， WCDMA/lx/DO， long term evolution (LTE) ， and GSM.

The user interface device 170 may include an input device 172， for example， but not limited to a keyboard， touch panel， or other human interface device， and a display device 174， for example， but not limited to， a liquid crystal display (LCD) ， light emitting diode (LED) display， or other video display. One of ordinary skill in the art will appreciate that other input and display devices may be used without departing from the scope of the present inventive concept.

The control unit 110 may control overall operation of the wireless communication device 100 including control of the first communication unit 120， the second communication unit 125， the user interface device 170， and the storage 180. The control unit 110 may be a programmable device， for example， but not limited to， a microprocessor or microcontroller. The control unit 110 may incorporate firmware 112 in a nonvolatile memory internal to the control unit 110. Alternatively， the firmware 112 may reside in nonvolatile memory external to the control unit 110.

The storage 180 may store application programs necessary for operation of the wireless communication device 100 that are executed by the control unit 110， as well as application data and user data.

In various embodiments， carrier aggregation may take place on the data link layer (i.e.， Layer 2) of the Intemet Protocol (IP) protocol stack. FIG. 2 is a diagram illustrating an example network architecture 200 according to various embodiments. Referring to FIGS. 1 and 2， the network configuration 200 may include a first cellular network 210， a second cellular network 220， a first access gateway (AGW) 230， a second AGW 240， a first tunnel 250， a second tunnel 260， and mobile virtual network operator (MVNO) AGW 270. The MVNO) AGW 270 may aggregate the connections and forward data packets to application servers (e.g.， application server 295) over the internet 290 or other network. One of ordinary skill in the art will appreciate that the MVNO AGW may alternatively or additionally be a gateway provided by a non-MVNO party without departing from the scope of the present inventive concept.

The first cellular network 210 may be configured with a dedicated access point name (APN) for the first AGW 230. The second cellular network may be configured with a dedicated APN for the second AGW 240. Each AGW230， 240 may be the gateway of one access network， for example， but not limited to， a packet data network gateway (PGW) for LTE， a Gateway GPRS Support Node (GGSN) for UMTS， a packet data serving node (PDSN) for cdma2000， a WiFi gateway， etc.

The first tunnel 250 may be configured to route data traffic between the first AGW 230 and the MVNO AGW 270. The second tunnel 260 may be configured to route data traffic between the second AGW 240 and the MVNO AGW 270. L2TP may be used as the tunnel protocol. One of ordinary skill in the art will appreciate that various tunnel protocols， for example， but not limited to， Generic Routing Encapsulation (GRE) ， L2TP， etc. ， to configure the tunnels. The first and

second tunnels

250， 260 may be User Datagram Protocol (UDP) based tunnels if network address translation (NAT) /firewall (FW) traversal is required. Intemet Protocol Security (IPsec) could be applied if security is required.

The MVNO GW 270 may aggregate the two (or more) PS connections by various ways， for example using Multilink Point-to-Point Protocol (MLPPP) or Multipath Transmission Control Protocol (MPTCP) . FIG. 3 is a diagram illustrating a protocol stack 300 for the example network architecture 200 illustrated in FIG. 2 according to various embodiments.

In various embodiments， the first and

second AGW

250， 260 may operate as link access control (LAC) on behalf of mobile communication device 100. The MVNO GW 270 may operate as an L2TP network server (LNS) . MLPPP may aggregate the PPP connections carried over L2TP. The LNS may allocate IP addresses for the mobile communication device 100 using link control protocol (LCP) . Application may run over the LNS allocated IP.

In various embodiments connections between the mobile communication device 100 and the MVNO GW 270 may be configured without an AGW configured with a dedicated APN. FIG. 4 is a diagram illustrating an example network architecture 400 without an AGW configured to have a dedicated APN according to various embodiments.

Referring to FIGS. 1 and 4， a third tunnel 450 may connect the first cellular network 210 to the MVNO GW 270. A fourth tunnel 460 may connect the second cellular network 220 to the MVNO GW 270. Layer 2 Tunneling Protocol (L2TP) may be used as the tunnel protocol. One of ordinary skill in the art will appreciate that various tunnel protocols， for example， but not limited to， GRE， L2TP， etc. ， to configure the tunnels. The first and

second tunnels

250， 260 may be UDP based tunnels ifNAT/FW traversal is required. IPsec could be applied if security is required.

The MVNO GW 270 may aggregate the two (or more) PS connections by various ways， for example using Multilink Point-to-Point Protocol (MLPPP) ， Dual Stack Mobile Internet Protocol version 6 (DSMIPv6) ， or Multipath TCP (MPTCP) . FIG. 5 is a diagram illustrating a protocol stack 500 for the example network architecture 400 illustrated in FIG. 4 according to various embodiments.

In various embodiments， the mobile communication device 100 may operate as the LAC. The MVNO GW 270 may operate as an L2TP network server (LNS) . MLPPP may aggregate the PPP connections carried over L2TP. The LNS may allocate IP addresses for the mobile communication device 100 using link control protocol (LCP) . Application may run over the LNS allocated IP.

FIG. 6A is a flowchart illustrating a method 600 for data aggregation on an uplink according to various embodiments. Referring to FIGS. 1-6A， the control unit 110 may cause the mobile communication device 100 to generate one or more component carriers for one data flow for the first SIM 140 and one or more component carriers for the same one data flow for the second SIM 150 (605) . A plurality of tunnels may be configured at layer 2 of the IP protocol stack for point-to-point connections between the mobile communication device 100 and the MVNO GW 270 (or other network gateway) for transmitting data packets on the one or more component carriers for the first and second SIMS 140， 150 (610) . In various embodiments， access gateways (e.g.， the first AGW 250 and the second AGW 260) may configure the tunnels between the access gateways and the MVNO GW 270 (or other network gateway) . In various embodiments， the mobile communication device 100 may configure the tunnels to the MVNO GW 270 (or other network gateway) . MLPPP may be used to uplink the component carriers through the tunnels over a tunneling protocol， for example， but not limited to， L2TP (615) . The MVNO AGW 270 may receive data packets from the point-to-point connections (620) . The MVNO AGW 270 may aggregate the connections at layer 2 of the IP protocol stack (625) and forward data packets to one or more application servers (e.g.， application server 295) over the intemet 290 or other network (630) . Optionally， the MVNO AGW 270 may reorder the data packets， and forward data packets to one or more application servers.

FIG. 6B is a flowchart illustrating a method 650 for data aggregation on a downlink according to various embodiments. On a downlink， the MVNO AGW 270 may generate one or more component carriers for one data flow (655) . If not already configured， the MVNO AGW 270 may configure tunnels at layer 2 of the IP protocol stack for point-to-point connections between the MVNO GW 270 and the mobile communication device 100 for the one or more component carriers for the first and second SIMS 140， 150 (660) . MLPPP may be used to downlink the component carriers through the tunnels over a tunneling protocol， for example， but not limited to， L2TP (665) . The control unit 110 may cause the first and

second SIMS

140， 150 to receive the one or more component carriers for the one data flow (670) . The control unit may cause the mobile communication device 100 to aggregate the connections at layer 2 of the IP protocol stack (675) and forward data packets to an application (680) . Optionally， the mobile communication device may reorder the data packets， and forward data packets to one or more application servers.

In various embodiments， carrier aggregation may take place on the transport layer (i.e.， Layer 3) of the IP protocol stack using DSMIPv6. DSMIPv6 is an extension of Mobile IPv6 with IPv4 Care-of address CoA (Care-of address) and IPv4 Home Address (HoA) . DSMIPv6 supports IP Flow Mobility (IFOM) which enables different IP flows to be carried over different CoAs. FIG. 7 is a table 700 illustrating an example of different IP flows carried over different CoAs according to various embodiments.

Referring to FIG. 7， with CoAl provided by SIM1 and CoA2 provided by SIM2， a Bind Update procedure may be used to bind one or more IP flows identified by flow IDs (FID) to CoAl. Binding a flow to both CoAl and CoA2 with different priority， achieves high reliability. Binding a flow to both CoAl and CoA2 with same priority achieves both high throughput and high reliability. The DSMIPv6 protocol needs to be enhanced to support binding a flow to both CoAl and CoA2 with the same priority. The DSMIPv6 protocol may be enhanced with a multi-path (MP) header. To achieve higher data throughput， an MP header may be added on the tunnel protocol of the network architecture illustrated in FIG. 4. Adding an MP header may achieve in-sequence delivery of a flow as well as load balance.

FIG. 8 is a diagram illustrating a protocol stack 800 used with a UDP tunnel according to various embodiments. One of ordinary skill in the art will appreciate that other tunnel protocols may be used without departing from the scope of the present inventive concept.

If in-sequence packet delivery is required per the CoA， the MP headers may contain sequence numbers. The sequence number of a packet is only valid for the associated IP flow. If finer grained packet sequence delivery is required， an FID may be included in the MP header to identify the IP flow. The FID may be generated from a 5-tuple of the encapsulated packet.

If in-sequence packet delivery is required for an IP flow， an FID may be generated by a sender and may be unique on the mobile communication device 100. Packets of the IP flow may carry increasing sequence numbers when the packets are distributed to multiple DSMIPv6 tunnels. If in-sequence packet delivery is not required for the IP flow， then sequencing may be disabled for the IP flow by a receiver. If in-sequence packet delivery is required， the receiver may support reordering for the identified IP flow.

FIG. 9 is a diagram illustrating an example of an MP header 900 used in multi-path encoding according to various embodiments. In order to identify the MP header 800， a special IP protocol ID may be assigned. IfUDP is used in DSMIPv6， then a special UDP port number may be assignedA.

Referring to FIG. 9， the following fields may be defined in the MP header 900：

Opt Len： length in 32-bit words in the MP header

S： the presence of a sequence option 910.

Protocol Type： IP protocol number for the encapsulated packet in the payload.

If S field indicates the presence of a sequence option 910， a sequence window may be defined to control the sequence. Packet sequencing may operate as follows：

If the packet is received in the sequence window and：

If (Expected+Window ＞＝ Received ＞ Expected) ， wait for the late packet.

If (Received ＝ Expected) ， flush packets with sequence number from

[Expected， NextUnreceived Number] ， and Expected ＝ Next Unreceived Number + 1.

If (Received ＞ Expected+Window) ， flush the packet from [Expected， Received-Window] ， and Expected ＝ Received-Window + 1

If (Received ＜ Expected) ， send the packet immediately.

FIG. 10 is a diagram illustrating an example DSMIPv6 based IP multi-path solution 1000 on the example network architecture of FIG. 2 according to various embodiments. Referring to FIG. 10， four packets 1010a belonging to one IP flow may be delivered from the mobile communication device 100 to the MVNO GW 270.

Packets

1 and 3 may be delivered through the fourth IP tunnel 460， and

packets

2 and 4 may be delivered through the third IP tunnel 450. The MVNO GW 270 may reorder the packets 1010b， and forward the reordered packets 1010b to the Internet 290 with a packet sequence of 1， 2， 3， 4. The reorder capability may be provided by the MP Header 900.

FIG. 1 lA is a flowchart illustrating a method 1100 for data aggregation on an uplink according to various embodiments. Referring to FIGS. 1-1 lA， a plurality of tunnels may be configured for an IP flow between the mobile communication device 100 and the MVNO GW 270 (or other network gateway) (1105) . In various embodiments， the mobile communication device 100 may configure the tunnels to the MVNO GW 270 (or other network gateway) . CoAs may be assigned to the IP flow by the first and second SIMS 140， 150 (1110) .

The CoAs may be bound to the IP flow using DSMIPv6 with MP headers having sequence numbers (1115) . If in-sequence packet delivery is required per the CoA， the MP headers may contain sequence numbers. Packets of the IP flow may carry increasing sequence numbers when the packets are distributed to multiple DSMIPv6 tunnels. The sequence number of a packet is only valid for the associated IP flow. If finer grained packet sequence delivery is required， an FID may be included in the MP header to identify the IP flow. The FID may be generated from a 5-tuple of the encapsulated packet.

Packets may be uplinked through the plurality of tunnels out of sequence based on DSMIPv6 with the MP headers (1120) . The out of sequence packets may be received at the access gateway (e.g.， the MVNO AGW 270 or other network access gateway) from the multiple paths (i.e.， tunnels) (1125) . The out of sequence packets may be reordered based on the sequence numbers in the MP headers (1130) . The access gateway may forward the packets to an application server (e.g.， application server 295 over the Intemet 290) (1135) .

FIG. 1 lB is a flowchart illustrating a method 1150 for data aggregation on a downlink according to various embodiments. Referring to FIGS. 1-1 lB， tunnels may be configured in IP flow between the mobile communication device 100 and the MVNO GW 270 (or other network gateway) (1155) . In various embodiments， the MVNO GW 270 (or other network gateway) may configure the tunnels to the mobile communication device 100. CoAs may be assigned to the IP flow by the MVNO GW 270 (or other network gateway) (1160) .

The CoAs may be bound to the IP flow using DSMIPv6 with MP headers having sequence numbers (1165) . If in-sequence packet delivery is required per the CoA， the MP headers may contain sequence numbers. Packets of the IP flow may carry increasing sequence numbers when the packets are distributed to multiple DSMIPv6 tunnels. The sequence number of a packet is only valid for the associated IP flow. If finer grained packet sequence delivery is required， an FID may be included in the MP header to identify the IP flow. The FID may be generated from a 5-tuple of the encapsulated packet.

Packets may be downlinked through the tunnels out of sequence based on DSMIPv6 with the MP headers (1170) . The out of sequence packets may be received at the first and

second SIMS

140， 150 of the mobile communication device 100 from the multiple paths (i.e.， tunnels) (1175) . The out of sequence packets may be reordered based on the sequence numbers in the MP headers (1180) . The first and

second SIMS

140， 150 may forward the packets to an application (1185) .

In various embodiments， data aggregation may take place on the IP layer (i.e.， Layer 4) of the IP protocol stack using MPTCP to aggregate multiple PS connections. MPTCP is a backward compatible extension to regular Transmission Control Protocol (TCP) to enable a transport connection to operate over multiple paths (i.e.， subflows) simultaneously.

An MPTCP connection begins similarly to a regular TCP connection. If extra paths are available， additional TCP sessions， termed MPTCP subflows， are created on these paths. The additional MPTCP subflows are combined with the existing session， which continues to appear as a single connection to the applications at both ends. For operating systems that support MPTCP， applications may determine whether or not to enable MPTCP. User control may be provided (e.g.， via system preferences) .

The PS connections from the first SIM 140 and the second SIM 150 may be aggregated on the MVNO GW 270 which acts as MPTCP proxy. If an application server 295 supports MPTCP， the PS connections may be aggregated on the application server 295 directly.

A tunnel (e.g.， tunnels 250， 260) may be needed to route data traffic to and from the MVNO GW 270 (or other network gateway) . Referring to the example network architecture illustrated in FIG. 2， the first AGW 230 may establish the tunnel (e.g.， tunnels 250) to the MVNO GW 270 on behalf of mobile communication device 100. Alternatively， referring to the example network architecture illustrated in FIG. 4， the mobile communication device 100 may establish the tunnel (e.g.， tunnels 450) to the MVNO GW 270. FIG. 12 is a diagram illustrating a protocol stack 1200 according to various embodiments.

For example， in various embodiments， the mobile communication device 100 may setup and maintain the tunnel (e.g.， tunnels 450) with the MVNO GW 270. Upstream TCP traffic (i.e.， from the mobile communication device 100 to the MVNO GW 270) may be routed through the tunnel. For downstream TCP traffic， (i.e.， from the MVNO GW 270 to the mobile communication device 100) the mobile communication device 100 may receive the traffic through MPTCP (e.g.， tunnels 450) through the tunnel.

In various embodiments， the MVNO GW 270 may setup and maintain the tunnel (e.g.， tunnels 250) with mobile communication device 100. After receiving upstream TCP traffic from the mobile communication device 100， the MVNO GW 270 may perform MPTCP Proxy. When receiving downstream TCP traffic from the remote server (e.g.， application server 295) ， the MVNO GW 270 may distribute the traffic to the mobile communication device 100 through MPTCP through the tunnel (e.g.， tunnel 250) .

FIG. 13 is a diagram of a protocol stack 1300 illustrating an example of MPTCP time division duplex (TDD) LTE + frequency division duplex (FDD) LTE inter-SIM carrier aggregation according to various embodiments. Referring to FIG. 11， TDD LTE may support two component carrier (CC) aggregations and FDD LTE may support two CC aggregations. One of ordinary skill in the art will appreciate that more than two component carriers may be supported without departing from the scope of the present inventive concept. Further， if dual connectivity is used， the two CCs may be two cells providing packet data protocol (PDCP) layer aggregation.

When MPTCP is enabled， the MPTCP connection initiation begins with a SYN， SYN/ACK， ACK exchange on a single path. Once an MPTCP connection has begun with the MP_CAPABLE exchange， further subflows can be added to the connection. The exchange of keys in the MP_CAPABLE handshake provides material that can be used to authenticate the endpoints when new subflows are set up. Additional subflows begin in the same way as initiating a normal TCP connection， but the SYN， SYN/ACK， and ACK packets also carry the MP_JOIN option.

A token generated from a key is used to identify which MPTCP connection the subflow is joining， and Hash-based Message Authentication Code (HMAC) is used for authentication. a Hash-based Message Authentication Code (HMAC) uses the keys exchanged in the MP_CAPABLE handshake and random numbers (nonces) exchanged in the MP_JOIN options. MP_JOIN also contains flags and an Address ID that can be used to refer to the source address without the sender needing to know if the source address has been changed by a NAT.

FIG. 14A is a flowchart illustrating a method 1400 for data aggregation on an uplink according to various embodiments. Referring to FIGS. 1-14A， the control unit 110 may initiate a first TCP session on one SIM (e.g.， the first SIM 140) (1405) . The control unit 110 may then open at least one additional TCP session (i.e.， subflow) on another SIM (e.g. the second SIM 150) (1410) . The additional subflow may be combined with the first TCP session (1415) . The combined session appear as a single connection to applications at both ends of the connection. The data traffic may be routed through a tunnel (e.g.， tunnels 250， 260) between the mobile communication device 100 and the MVNO GW 270 (or other network gateway) . One of ordinary skill in the art will appreciate that more than one additional TCP session (i.e.， subflow) may be opened on each SIM without departing from the scope of the present inventive concept.

The MVNO GW 270 (or other network gateway) may aggregate the data packets from the first SIM 140 and the second SIM 150 on layer 4 of the IP protocol stack using MPTCP (1420) . If an application server (e.g.， application server 295) supports MPTCP， the PS connections may be aggregated on the application server 295 directly.

FIG. 14B is a flowchart illustrating a method 1450 for carrier aggregation on a downlink according to various embodiments. Referring to FIGS. 1-14B， the MVNO GW 270 (or other network gateway) may initiate a first TCP session with one SIM (e.g.， the first SIM 140) of the mobile communication device 100 (1455) . The MVNO GW 270 (or other network gateway) may then open at least one additional TCP session (i.e.， subflow) with another SIM (e.g. the second SIM 150) (1460) . The additional subflow may be combined with the first TCP session (1465) . The combined session appear as a single connection to applications at both ends of the connection. The data traffic may be routed through a tunnel (e.g.， tunnels 250， 260) between the mobile communication device 100 and the MVNO GW 270 (or other network gateway) . One of ordinary skill in the art will appreciate that more than one additional TCP session (i.e.， subflow) may be opened on each SIM without departing from the scope of the present inventive concept.

The control unit 110 may aggregate the PS connections from the first SIM 140 and the second SIM 150 on layer 4 of the IP protocol stack using MPTCP (1470) .

While various example embodiments have been described in terms of two PS connections， one of ordinary skill in the art will appreciate that the methods for inter-SIM aggregation are applicable to aggregating more than two PS connections without departing from the scope of the present inventive concept. The PS connections may be provided by other types of connections， for example， but not limited to， cellular wireless access or WiFi， with or without dependency on SIMs or subscriptions. Further， ifuser aggregation for DL traffic is needed， the mobile communication device may not necessarily be a dual transmitter (Tx) device (i.e.， concurrent transmission on subscription 1 and subscription 2) . One Tx may be shared by two subscriptions. In addition， one of ordinary skill in the art will appreciate that an MVNO GW may also be a GW provided by non-MVNO party without departing from the scope of the present inventive concept.

The accompanying claims and their equivalents are intended to cover such forms or modifications as would fall within the scope and spirit of the protection. For example， the example apparatuses， methods， and systems disclosed herein can be applied to multi-SIM wireless devices subscribing to multiple communication networks and/or communication technologies. The various components illustrated in the figures may be implemented as， for example， but not limited to， software and/or firmware on a processor， ASIC/FPGA/DSP， or dedicated hardware. Also， the features and attributes of the specific example embodiments disclosed above may be combined in different ways to form additional embodiments， all of which fall within the scope of the present disclosure.

The foregoing method descriptions and the process flow diagrams are provided merely as illustrative examples and are not intended to require or imply that the steps of the various embodiments must be performed in the order presented. As will be appreciated by one of skill in the art the order of steps in the foregoing embodiments may be performed in any order. Words such as “thereafter， ” “then， ” “next， ” etc. are not intended to limit the order of the steps； these words are simply used to guide the reader through the description of the methods. Further， any reference to claim elements in the singular， for example， using the articles “a， ” “an， ” or “the” is not to be construed as limiting the element to the singular.

The various illustrative logical blocks， modules， circuits， and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware， computer software， or combinations of both. To clearly illustrate this interchangeability of hardware and software， various illustrative components， blocks， modules， circuits， and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application， but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

The hardware used to implement the various illustrative logics， logical blocks， modules， and circuits described in connection with the aspects disclosed herein may be implemented or performed with a general purpose processor， a digital signal processor (DSP) ， an application specific integrated circuit (ASIC) ， a field programmable gate array (FPGA) or other programmable logic device， discrete gate or transistor logic， discrete hardware components， or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor， but， in the alternative， the processor may be any conventional processor， controller， microcontroller， or state machine. A processor may also be implemented as a combination of receiver devices， e.g.， a combination of a DSP and a microprocessor， a plurality of microprocessors， one or more microprocessors in conjunction with a DSP core， or any other such configuration. Alternatively， some steps or methods may be performed by circuitry that is specific to a given function.

In one or more exemplary aspects， the functions described may be implemented in hardware， software， firmware， or any combination thereof. If implemented in software， the functions may be stored as one or more instructions or code on a non-transitory computer-readable storage medium or non-transitory processor-readable storage medium. The steps of a method or algorithm disclosed herein may be embodied in processor-executable instructions that may reside on a non-transitory computer-readable or processor-readable storage medium. Non-transitory computer-readable or processor-readable storage media may be any storage media that may be accessed by a computer or a processor. By way of example but not limitation， such non-transitory computer-readable or processor-readable storage media may include RAM， ROM， EEPROM， FLASH memory， CD-ROM or other optical disk storage， magnetic disk storage or other magnetic storage devices， or any other medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer. Disk and disc， as used herein， includes compact disc (CD) ， laser disc， optical disc， digital versatile disc (DVD) ， floppy disk， and Blu-ray disc where disks usually reproduce data magnetically， while discs reproduce data optically with lasers. Combinations of the above are also included within the scope of non-transitory computer-readable and processor-readable media. Additionally， the operations of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a non-transitory processor-readable storage medium and/or computer-readable storage medium， which may be incorporated into a computer program product.

Although the present disclosure provides certain example embodiments and applications， other embodiments that are apparent to those of ordinary skill in the art， including embodiments which do not provide all of the features and advantages set forth herein， are also within the scope of this disclosure. Accordingly， the scope of the present disclosure is intended to be defined only by reference to the appended claims.

Claims

A method for carrier aggregation on an uplink， the method comprising：

configuring a plurality of tunnels for point-to-point connections between first and second subscriber identity modules (SIMs) of the mobile communication device and a network gateway at layer 2 of an IP protocol stack；

uplinking data packets for the one data flow from the first SIM and the second SIM to the network gateway through the plurality of tunnels；

aggregating the point-to-point connections at layer 2 of the IP protocol stack of the network gateway； and

reordering the data packets of the one data flow.
The method of claim 1， wherein the network gateway is a mobile virtual network operator gateway (MVNO GW) .
The method of claim 1， wherein one or more access gateways (AGWs) configure the plurality of tunnels between the mobile communication device and the network gateway.
The method of claim 1， wherein the mobile communication device configures the plurality of tunnels between the mobile communication device and the network gateway.
The method of claim 1， further comprising forwarding the data packets from the aggregated point-to-point connections to an application server.
A method for carrier aggregation on a downlink， the method comprising：

configuring a plurality of tunnels for point-to-point connections between the network gateway and the first and second subscriber identity modules (SIMs) of a mobile communication device at layer 2 of an IP protocol stack；

downlinking data packets for the one data flow from the network gateway to the first SIM and the second SIM；

aggregating the point-to-point connections at layer 2 of the IP protocol stack of the mobile communication device； and

reordering the packets of the one data flow.
The method of claim 6， wherein the network gateway is a mobile virtual network operator gateway (MVNO GW) .
The method of claim 6， wherein one or more access gateways (AGWs) configure the plurality of tunnels between the network gateway and the mobile communication device.
The method of claim 6， wherein the mobile communication device configures the plurality of tunnels between the network gateway and the mobile communication device.
The method of claim 6， further comprising forwarding the data packets from the aggregated point-to-point connections to an application on the mobile communication device.
A method for aggregating data flow on an uplink， the method comprising：

generating a plurality of IP tunnels with different care-of addresses (CoAs) for an IP flow between a mobile communication device and a network gateway；

uplinking data packets out of sequence from the first and second SIMs to the network gateway through the plurality of tunnels；

receiving the data packets out of sequence at the network gateway； and

reordering the packets based on the sequence numbers in the multipath headers.
The method of claim 11， further comprising：

allocating， by the network gateway， a home address (HoA) for the mobile communication device； and

binding the HoA to the one or more CoAs at the network gateway.
The method of claim 11， wherein the network gateway is a mobile virtual network operator gateway (MVNO GW) .
The method of claim 11， wherein the mobile communication device configures the plurality of tunnels between the mobile communication device and the network gateway.
The method of claim 11， wherein the sequence number of a packet is only valid for the associated IP flow.
The method of claim 11， wherein the multipath header comprises a flow identification (FID) identifying the IP flow.
The method of claim 11， further comprising forwarding the reordered packets to an application server.
A method for aggregating data flow on a downlink， the method comprising：

binding one or more CoAs to an IP flow using Dual Stack Mobile Internet Protocol version 6 (DSMIPv6) with multipath (MP) headers having sequence numbers；

downlinking data packets out of sequence from the network gateway to the first and second SIMs through the plurality of tunnels；

receiving the data packets out of sequence at the first and second SIMs； and

reordering the packets based on the sequence numbers in the multipath headers.
The method of claim 18， further comprising：

allocating， by the network gateway， a home address (HoA) for the mobile communication device； and

binding the HoA to the one or more CoAs at the network gateway.
The method of claim 18， wherein the network gateway is a mobile virtual network operator gateway (MVNO GW) .
The method of claim 18， wherein the mobile communication device configures the plurality of tunnels between the network gateway and the mobile communication device.
The method of claim 18， wherein the sequence number of a packet is only valid for the associated IP flow.
The method of claim 18， wherein the multipath header comprises a flow identification (FID) identifying the IP flow.
The method of claim 18， further comprising forwarding the reordered packets to an application.
A method of aggregating data， the method comprising：

generating a plurality of tunnels between a network gateway and first and second SIMs；

routing a data flow through the plurality of tunnels between the network gateway and the first and second SIMs； and

aggregating the data packets from the first SIM and the second SIM on layer 4of the IP protocol stack.
The method of claim 25， wherein the network gateway is a mobile virtual network operator gateway (MVNO GW) .
The method of claim 25， further comprising forwarding the aggregated data packets to an application server.
The method of claim 25， wherein the aggregating the data packets on layer 4 of the IP protocol stack further comprises：

initiating， by a mobile communication device， a first TCP subflow on a first SIM for a data flow on a downlink；

opening， by the mobile communication device one or more additional TCP subflows for the data flow on a second SIM； and

combining the additional TCP subflows on the second SIM with the first TCP subflow on the first SIM.
The method of claim 28， further comprising forwarding the aggregated data packets to an application server.