WO2016101631A1

WO2016101631A1 - Inter-subscriber identity module (sim) aggregation

Info

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

Abstract

A method for carrier aggregation on an uplink performed by a network gateway may include: configuring, by the network gateway, a plurality of tunnels for point-to-point connections between first and second subscriber identity modules (SIMs) of a mobile communication device and the network gateway on an Internet Protocol (IP) protocol stack; uplinking, by the network gateway, data packets for one data flow from the first SIM and the second SIM to the network gateway through the plurality of tunnels; aggregating, by the network gateway, the point-to-point connections on the IP stack of the network gateway; and forwarding the data packets for the one data flow from the aggregated point-to-point connections to an application server.

Description

INTER-SUBSCRIBER IDENTITY MODULE (SIM) AGGREGATION

BACKGROUND

This application is a continuation-in-part of International Application No. PCT/CN2014/094789， filed December， 24， 2014， the disclosure of which is incorporated herein in its entirety by reference.

The 3rd Generation Partnership Project (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-CA (two-carrier-CA) or 3C-CA (three-carrier-CA) .

SUMMARY

According to various embodiments， a method for carrier aggregation on an uplink performed by a network gateway may include： configuring， by the network gateway， a plurality of tunnels for point-to-point connections between first and second subscriber identity modules (SIMs) of a mobile communication device and the network gateway on an Internet Protocol (IP) protocol stack； uplinking， by the network gateway， data packets for one data flow from the first SIM and the second SIM to the network gateway through the plurality of tunnels； aggregating， by the network gateway， the point-to-point connections on the IP stack of the network gateway； and forwarding the data packets for the one data flow from the aggregated point-to-point connections to an application server.

According to various embodiments， a method for carrier aggregation on a downlink performed by a mobile communication device may include： configuring， by the mobile communication device， a plurality of tunnels for point-to-point connections between a network gateway and first and second subscriber identity modules (SIMs) of a mobile communication device on an Internet Protocol (IP) protocol stack； receiving downlinked data packets for one data flow from the network gateway at the first SIM and the second SIM； aggregating the point-to-point connections on the IP stack of the mobile communication device； forwarding the data packets for the one data flow from the aggregated point-to-point connections to an application on the mobile communication device.

According to various embodiments， a method for aggregating data flow on an uplink performed by a network gateway may include： configuring， by the network gateway， a plurality of Internet Protocol (IP) tunnels with different care-of addresses (CoAs) for an IP flow between a mobile communication device and the network gateway； uplinking， by the network gateway， data packets out of sequence from a first SIM and a second SIM of the mobile communication device to the network gateway through the plurality of tunnels； receiving the data packets out of sequence at the network gateway； and reordering the data packets based on the sequence numbers contained in headers of the received data packets.

According to various embodiments， a method for aggregating data flow on a downlink performed by a mobile communication device may include：； downlinking data packets having one or more care-of addresses (CoAs) bound to an Internet Protocol (IP) flow using Dual Stack Mobile Internet Protocol version 6 (DSMIPv6) with headers having sequence numbers out of sequence from the network gateway to the first and second SIMs of the mobile communication device through the plurality of tunnels； receiving the data packets out of sequence at the first and second SIMs； and reordering the data packets based on the sequence numbers in the headers.

According to various embodiments， a method of aggregating data performed by a mobile communication device may include： configuring， by the mobile communication device， a plurality of tunnels between a network gateway and first and second subscriber identity modules (SIMs) of the mobile communication device； routing， by the mobile communication device， 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 of an Internet Protocol (IP) stack.

According to various embodiments， a method of aggregating data performed by a network gateway may include： configuring， by the network gateway， a plurality of tunnels between the network gateway and first and second subscriber identity modules (SIMs) of a mobile communication device； routing a data flow through the plurality of tunnels between the network gateway and the first and second SIMs； and aggregating， by the network gateway， data packets received from the first SIM and the second SIM on an Internet Protocol (IP) stack.

BRIEF DESCRIPTION OF THE DRAWINGS

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

FIG. 1 is a block diagram illustrating a mobile 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 according to various embodiments；

FIG. 4 is a diagram illustrating an example network configuration without an access gateway (AGW) according to various embodiments；

FIG. 5 is a diagram illustrating a protocol stack 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 User Datagram Protocol (UDP) tunnel according to various embodiments；

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

FIG. 10 is a diagram illustrating an example Dual Stack Mobile Internet Protocol version 6 (DSMIPv6) based Internet Protocol (IP) multi-path solution according to various embodiments；

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

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

FIG. 11B is a flowchart illustrating a method 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 illustrating an example of inter-SIM carrier aggregation according to various embodiments；

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

FIG. 14B is a flowchart illustrating a method 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.

Various mobile applications require very reliable packet switched (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. P 1 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 second SIM (SIM2) ) ， respectively. If P1＝P2＝99％， then the availability of PS1+PS2 aggregation would be： 1 - (1-P1) (1-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×150 Mbps＝750Mbps with PS1+PS2 aggregation. Uplink (UL) data throughput may be aggregated as well.

FIG. 1 is a block diagram illustrating a mobile communication device 100 according to various embodiments. As illustrated in FIG. 1， the mobile 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 mobile 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 mobile 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 universal SIM (USIM) applications， enabling access to global system for mobile communication (GSM) and/or Universal Mobile Telecommunications System (UMTS) networks. Alternatively， in a code division multiple access (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 ofa 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 (Sub1) 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 Sub1 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/1x/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 mobile 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 mobile 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 a data link layer (i.e.， Layer 2) of an Internet Protocol (IP) protocol stack. FIG. 2 is a diagram illustrating an example network configuration 200 according to various embodiments. Referring to FIGS. 1 and 2， the network configuration 200 may include a first cellular network 210 (e.g.， first communication network 190) ， a second cellular network 220 (e.g.， second communication network 195) ， a first access gateway (AGW) 230， a second AGW 240， a first tunnel 250， a second tunnel 260， and mobile virtual network operator gateway (MVNO GW) 270. The MVNO GW 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 GW 270 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 220 may be configured with a dedicated APN for the second AGW 240. Each of the first AGW 230 and the second AGW 240 may be a gateway of one access network， for example， but not limited to， a packet data network gateway (PGW) for LTE， a Gateway General Packet Radio Service (GPRS) Support Node (GGSN) for universal mobile telecommunications system (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 GW 270. The second tunnel 260 may be configured to route data traffic between the second AGW 240 and 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， Generic Routing Encapsulation (GRE) ， L2TP， etc. ， to configure the tunnels. In some embodiments， the first and

second tunnels

250， 260 may be User Datagram Protocol (UDP) based tunnels， for example， if network address translation (NAT) /firewall (FW) traversal is required. In some embodiments， Internet Protocol Security (IPsec) may be applied， for example， 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 configuration 200 illustrated in FIG. 2 according to various embodiments.

With reference to FIGS. 1-3， in various embodiments， the first and

second AGW

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

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 configuration400 without an AGW according to various embodiments.

Referring to FIGS. 1-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 third and

fourth tunnels

450， 460 may be UDP based tunnels if NAT/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 configuration400 illustrated in FIG. 4 according to various embodiments.

With reference to FIGS. 1-5， 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) . The 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) .

In various embodiments， multiple carrier aggregation capability is shared by two or more SIMs (e.g.， the first SIM 140 and the second SIM 150) . The control unit 110 may assign the carrier aggregation capability between the SIMs. For example， the control unit 110 may assign 5C-CA capability as 3C-CA to the first SIM 140 and 2C-CA to the second SIM 150. The control unit 110 may then cause the mobile communication device 100 to report 3C-CA capability to a serving node for the first SIM 140 (e.g.， a first base station of the first communication network 190) and report 2C-CA capability to the serving node for the second SIM 150 (e.g.， a second base station of the second communication network 195) . However， the mobile communication device 100 may not know the CA capabilities ofa network (e.g.， network configuration 200， 400) .

In some embodiments， the mobile communication device 100 may determine the CA capabilities of the network based on historical usage information. Alternatively， the mobile communication device provider may update the mobile communication device 100 configuration via a software upgrade， for example， but not limited to， by an over-the-air (OTA) upgrade.

In some embodiments， the network may broadcast the CA capability of the network. For example， the CA capability of the network may be included in one or more of the system information blocks (SIBs) periodically broadcast by the network.

Further， dynamic radio capability reporting for the mobile communication device 100 may not be supported by the communication protocol (e.g.， the 3GPP standard) . In some embodiments， the control unit 110 may cause the mobile communication device 100 to transmit a tracking area update (TAU) request to the network to update the dynamic radio capability for the mobile communication device 100.

In some embodiments， multiple radio capability profiles may be defined for the mobile communication device 100. For example， different profiles may enable different CA capabilities for the mobile communication device 100. The radio capability profiles may be stored on the mobile communication device 100， for example， in the storage 180 or internal storage for the control unit 110. The mobile communication device 100 may communicate with the serving cell to select a radio capability profile.

With CA， one data flow may be carried by two or more links using two or more SIMs. Different links may have different capacities. Therefore， link selection may impact data packet delay and throughput. Accordingly， an optimal link may be selected to transmit a data packet. A link having more capacity may be assigned more data packet traffic. Link quality may be estimated based on various parameters， for example， but not limited to， radio channel status (e.g.， reference signal received power (RSRP) ， reference signal received quality (RSRQ) ， channel quality indicators (CQI) ， etc. ) ， serving cell load， backhaul load， historical information， buffer status， flow control window status， etc. A link priority may be determined and a packet may be transmitted on a link having a high priority. For example， the link priority may be determined based on an estimated bitrate on the link and the buffer status of the link.

In the uplink (UL) ， the mobile communication device 100 may transmit a buffer status report (BSR) as well as reporting the power headroom (PHR) to the serving cell. The BSR informs the serving cell of the amount of UL data in a buffer of the mobile communication device 100 to send. Based on link quality and priority， the mobile communication device 100 may separate the pending UL data amount into two (or more) BSRs.

The PHR report informs the network about the remaining transmit power of the mobile communication device 100. To conform to specific absorption rate (SAR) requirements， the sum of transmit power on both SIMs cannot exceed a maximum power threshold. The network may consider PHR to determine transport block size (TBS) for each SIM. In addition， more power may be allocated to a SIM having a higher link quality.

In the DL， the MVNO GW (e.g.， the MVNO GW 270) may perform link selection with assistance information from the access network.

FIG. 6A is a flowchart illustrating a method 600 for data aggregation on an uplink according to various embodiments. Referring to FIGS. 1-6A， in block 605， 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. In block 610， a plurality of tunnels may be configured at layer 2 of the IP 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. In various embodiments， access gateways (e.g.， the first AGW 230 and the second AGW 240) may configure a plurality of tunnels between the access gateways and the MVNO GW 270 (or other network gateway) . In various embodiments， control unit 110 of the mobile communication device 100 may configure the plurality of tunnels to the MVNO GW 270 (or other network gateway) .

In block 615， MLPPP may be used to uplink the component carriers through the tunnels over a tunneling protocol， for example， but not limited to， L2TP. In block 620， the MVNO GW 270 may receive data packets from the point-to-point connections. In block 625， the MVNO GW 270 may aggregate the connections at layer 2 of the IP stack. In block 630， the MVNO GW 270 may forward data packets to one or more application servers (e.g.， application server 295) over the Internet 290 or other network. Optionally， the MVNO GW 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. Referring to FIG. 6B， in block 655， on a downlink， the MVNO GW 270 may generate one or more component carriers for one data flow. In block 660， if not already configured by the mobile communication device 100， the MVNO GW 270 may configure tunnels at layer 2 of the IP 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. In block 665， MLPPP may be used to downlink data packets on the component carriers through the tunnels over a tunneling protocol， for example， but not limited to， L2TP.

In block 670， the control unit 110 may cause the first and

second SIMS

140， 150 to receive the data packets from the point-to-point connections on the one or more component carriers for the one data flow. In block 675， the control unit 110 may cause the mobile communication device 100 to aggregate the connections at layer 2 of the IP stack. For example， the control unit 110 may assign carrier aggregation capabilities between the first SIM 140 and the second SIM 150 based on carrier aggregation capabilities of a network associated with each SIM. The control unit 110 may determine the carrier aggregation capabilities of the network associated with each SIM by， for example， but not limited to， at least one of historical network usage information， pre-configured network information， and system information broadcast by the network. In block 680， the control unit 110 may cause the mobile communication device 100 to forward data packets to an application on the mobile communication device 100. Optionally， the control unit 110 of the mobile communication device 100 may reorder the data packets and forward data packets to one or more applications on the mobile communication device 100.

In various embodiments， carrier aggregation may take place on the transport layer (i.e.， Layer 3) of the IP 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 FIGS. 1-7， with CoA1 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 identifications (FIDs) to CoA1. Binding a flow to both CoA1 and CoA2 with same priority achieves both high throughput and high reliability. In various embodiments， the DSMIPv6 protocol may be enhanced to support binding a flow to both CoA1 and CoA2 with the same priority. In particular embodiments， the DSMIPv6 protocol may be enhanced with a multi-path (MP) header. For instance， to achieve higher data throughput， an MP header may be added on the tunnel protocol of the network configuration400. 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.

With reference to FIGS. 1-8， 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 implemented， 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 implemented 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 900， a special IP ID may be assigned. IfUDP is used in DSMIPv6， then a special UDP port number may be assigned.

Referring to FIGS. 1-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 number for the encapsulated packet in the payload.

If the 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＝NextUnreceived 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 an example network configuration (e.g.， 200 in FIG. 2) according to various embodiments. Referring to FIGS. 1-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. 11A is a flowchart illustrating a method 1100 for data aggregation on an uplink according to various embodiments. Referring to FIGS. 1-11A， in block 1105， the control unit 110 may configure a plurality of tunnels for an IP flow between the mobile communication device 100 and the MVNO GW 270 (or other network gateway) . In various embodiments， the MVNO GW 270 (or other network gateway) may configure the plurality of tunnels. In block 1110， the first and

second SIMS

140， 150 may assign CoAs to the IP flow.

In block 1115， the CoAs may be bound to the IP flow using DSMIPv6 with MP headers having sequence numbers. If in-sequence packet delivery is implemented 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 implemented， 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.

In block 1120， packets may be uplinked through the plurality of tunnels out of sequence based on DSMIPv6 with the MP headers. In block 1125， the access gateway (e.g.， the MVNO GW 270 or other network access gateway) may receive the out of sequence packets from the multiple paths (i.e.， tunnels) . In block 1130， the access gateway (e.g.， the MVNO GW 270 or other network access gateway) may reorder the out of sequence packets based on the sequence numbers in the MP headers. In block 1135， the access gateway may forward the packets to an application server (e.g.， application server 295 over the Internet 290) .

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

In block 1165， the CoAs may be bound to the IP flow using DSMIPv6 with MP headers having sequence numbers. If in-sequence packet delivery is implemented 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.

In block 1170， the MVNO GW 270 (or other network gateway) may downlink packets through the tunnels out of sequence based on DSMIPv6 with the MP headers. In block 1175， the first and

second SIMS

140， 150 of the mobile communication device 100 may receive the out of sequence packets from the multiple paths (i.e.， tunnels) . In block 1180， the control unit 110 may reorder the out of sequence packets based on the sequence numbers in the MP headers. In block 1185， the first and

second SIMS

140， 150 may forward the packets to an application.

In various embodiments， data aggregation may take place on the IP layer (i.e.， Layer 4) of the IP 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 configuration200， 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 configuration400， 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.

With reference to FIGS. 1-12， 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 FIGS. 1-13，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. An 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， in block 1405， the control unit 110 may initiate a first TCP session on one SIM (e.g.， the first SIM 140) . In block 1410， 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) . In block 1415， the control unit 110 may combine the additional subflow with the first TCP session. 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.

In block 1420， 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 stack using MPTCP. 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， in block 1455， 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. In block 1460， 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) . In block 1465， the MVNO GW 270 (or other network gateway) may combine the additional subflow with the first TCP session. 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.

In block 1470， 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 stack using MPTCP.

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， if user aggregation for DL traffic is needed， the mobile communication device 100 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 operations 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 operations 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 operations； 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 operations 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 operations 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 operations 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 operations 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 performed by a network gateway， the method comprising：

configuring， by the network gateway， a plurality of tunnels for point-to-point connections between first and second subscriber identity modules (SIMs) of a mobile communication device and the network gateway on an Internet Protocol (IP) stack；

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

aggregating， by the network gateway， the point-to-point connections on the IP stack of the network gateway； and

forwarding the data packets for the one data flow from the aggregated point-to-point connections to an application server.
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， further comprising reordering， by the network gateway， the data packets for the one data flow.
The method of claim 1， wherein carrier aggregation capabilities are assigned between the first SIM and the second SIM based on carrier aggregation capabilities of a network associated with each SIM.
The method of claim 5， wherein the carrier aggregation capabilities of the network associated with each SIM are determined by historical network usage information， pre-configured network information， and system information broadcast by the network， or a combination thereof.
The method of claim 1， wherein carrier aggregation capabilities are assigned between the first SIM and the second SIM based on stored radio capability profiles.
The method of claim 1， wherein the data packets for the one data flow are assigned to the one data flow from one of the first SIM and the second SIM based on a link priority for the first SIM and the second SIM.
A method for carrier aggregation on a downlink performed by a mobile communication device， the method comprising：

configuring， by the mobile communication device， a plurality of tunnels for point-to-point connections between a network gateway and first and second subscriber identity modules (SIMs) of the mobile communication device on an Internet Protocol (IP) stack；

receiving downlinked data packets for one data flow from the network gateway at the first SIM and the second SIM；

aggregating the point-to-point connections on the IP stack of the mobile communication device； and

forwarding the data packets for the one data flow from the aggregated point-to-point connections to an application on the mobile communication device.
The method of claim 9， wherein the network gateway is a mobile virtual network operator gateway (MVNO GW) .
The method of claim 9， further comprising reordering the data packets for the one data flow.
A method for aggregating data flow on an uplink performed by a network gateway， the method comprising：

configuring， by the network gateway， a plurality of Internet protocol (IP) tunnels with different care-of addresses (CoAs) for an IP flow between a mobile communication device and the network gateway；

uplinking， by the network gateway， data packets out of sequence from a first subscriber identity module (SIM) and a second SIM of the mobile communication device to the network gateway through the plurality of IP tunnels；

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

reordering the data packets based on sequence numbers contained in headers of the received data packets.
The method of claim 12， further comprising：

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

binding the HoA to one or more of the CoAs at the network gateway.
The method of claim 12， wherein the network gateway is a mobile virtual network operator gateway (MVNO GW) .
The method of claim 12， wherein the sequence numbers of the data packets are only valid for the IP flow associated with the data packets.
The method of claim 12， wherein each of the headers comprises a flow identification (FID) identifying the IP flow.
The method of claim 12， further comprising forwarding the reordered data packets to an application server.
A method for aggregating data flow on a downlink performed by a mobile communication device， the method comprising：

downlinking data packets having one or more care-of addresses (CoAs) bound to an Internet Protocol (IP) flow using Dual Stack Mobile Internet Protocol version 6 (DSMIPv6) with headers having sequence numbers out of sequence from a network gateway to first and second subscriber identity modules (SIMs) of the mobile communication device through a plurality of tunnels；

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

reordering the data packets based on the sequence numbers in the headers.
The method of claim 18， wherein the network gateway is a mobile virtual network operator gateway (MVNO GW) .
The method of claim 18， further comprising：

configuring， by the mobile communication device， the plurality of tunnels between the network gateway and the mobile communication device.
The method of claim 18， wherein the sequence numbers of the data packets are only valid for the IP flow associated with the data packets.
The method of claim 18， wherein each of the headers comprises a flow identification (FID) identifying the IP flow.
The method of claim 18， further comprising forwarding the reordered data packets to an application on the mobile communication device.
A method of aggregating data performed by a mobile communication device， the method comprising：

configuring， by the mobile communication device， a plurality of tunnels between a network gateway and first and second subscriber identity modules (SIMs) of the mobile communication device；

routing， by the mobile communication device， a data flow through the plurality of tunnels between the network gateway and the first and second SIMs； and

aggregating data packets from the first SIM and the second SIM on an Internet Protocol (IP) stack.
The method of claim 24， wherein the network gateway is a mobile virtual network operator gateway (MVNO GW) .
The method of claim 24， further comprising forwarding the aggregated data packets to an application on the mobile communication device.
The method of claim 24， wherein the aggregating the data packets on the IP stack comprises：

initiating， by the mobile communication device， a first transmission control protocol (TCP) subflow on the first SIM for a downlink data flow；

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

combining the one or more additional TCP subflows on the second SIM with the first TCP subflow on the first SIM.
The method of claim 27， wherein carrier aggregation capabilities are assigned between the first SIM and the second SIM based on carrier aggregation capabilities of a network associated with each SIM.
The method of claim 28， wherein the carrier aggregation capabilities of the network associated with each SIM are determined by historical network usage information， pre-configured network information， system information broadcast by the network， or a combination thereof.
The method of claim 27， wherein carrier aggregation capabilities are assigned between the first SIM and the second SIM based on stored radio capability profiles.
The method of claim 27， wherein data packets are assigned to the data flow from one of the first SIM and the second SIM based on a link priority for the first SIM and the second SIM.
A method of aggregating data performed by a network gateway， the method comprising：

configuring， by the network gateway， a plurality of tunnels between the network gateway and first and second subscriber identity modules (SIMs) of a mobile communication device；

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

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

initiating， by the network gateway， a first transmission control protocol (TCP) subflow from the first SIM for the data flow；

opening， by the network gateway， one or more additional TCP subflows for the data flow from the second SIM； and

combining the one or more additional TCP subflows from the second SIM with the first TCP subflow from the first SIM.
The method of claim 35， wherein carrier aggregation capabilities are assigned between the first SIM and the second SIM based on carrier aggregation capabilities of a network associated with each SIM.
The method of claim 36， wherein the carrier aggregation capabilities of the network associated with each SIM are determined by historical network usage information， pre-configured network information， system information broadcast by the network， or a combination thereof.
The method of claim 35， wherein data packets are assigned to the data flow to one of the first SIM and the second SIM based on a link priority for the first SIM and the second SIM.