FILE TRANSFER BY MOBILE USER COLLABORATION

Technical Field

[0001] The present disclosure relates to file transfer in a wireless

communications network.

Background

[0002] The evolution of 4 ^th Generation (4G) wireless communications networks such as Long Term Evolution (LTE) and LTE-Advanced (LTE-A) is being driven by customer demand for higher capacity and peak throughput. A number of approaches have been developed to meet such demand. However, low data rate cell-edge users continue to pose challenges to meeting these demands. Such users tend to be interference limited. Additionally, where such users are located indoors, there may be coverage gaps that constrain

performance.

[0003] Coordinated Multi-Point (CoMP) is a framework of methods to improve both peak user throughput as well as aggregated network throughput in a mobile cellular network. These methods employ multiple access points or base stations (known in the LTE environment as evolved NodeBs or eNodeBs or eNBs) grouped in a CoMP set of cooperating nodes to communicate with a wireless device (a User Equipment (UE) in LTE) of interest.

[0004] CoMP methods may be configured in either a centralized coordinated approach or through a distributed processing architecture to improve capacity. A centralized approach to CoMP where a central node or server coordinates CoMP transmissions between CoMP sets benefit from complete knowledge of the CoMP signals and context. However, such approaches rely on high capacity backhaul interconnects (e.g. via an S1 and/or X2 interface) between the base stations in the CoMP set. Centralized CoMP transmission and reception techniques use multiple transmit and receive antennas from different locations to send / receive data and to reduce signal interference to the UE. In contrast, distributed processing architectures for CoMP may achieve lower latency and reduced backhaul complexity but may experience reduced performance relative to a centralized CoMP approach.

[0005] In LTE-A, CoMP currently includes methods such as Coordinated Scheduling (CS), Coordinated Beamforming (CB), Joint Processing (JP), and Dynamic Point Selection.

[0006] In CS, the resource assignment is coordinated among multiple base stations, and transmitted / received from / to a selected base station. In CB, coordination among base stations or access points is coordinated so that their transmissions are beamformed and directed toward the UE. In downlink (DL) JP, common data is transmitted by multiple base stations and processed jointly by the UE. In uplink (UL) JP, data from the UE is provided to multiple base stations. Two challenges faced in JP, especially UL JP, are the backhaul latency and the backhaul bandwidth called for to transmit data from the receiving base stations to a single process node, which may, in some implementations, be a base station. As such, systems and methods for improved data file upload performance are needed.

Summary

[0007] Systems and methods for file transfer by mobile user collaboration are provided. In some embodiments, a method of operation of a serving network node in a wireless communications network includes determining to perform a handover for a wireless device served by the serving network node to a new serving network node. The wireless device is one of multiple wireless devices uploading a data file as multiple pieces to a destination network node. The method also includes sending to the new serving network node an indication of a status of the upload of the data file and handing over the wireless device to the new serving network node. In this way, the upload of the data file may continue after the wireless device is handed over.

[0008] In some embodiments, the indication of the status of the upload of the data file includes a message that includes a status of which pieces of the data file have been received and which pieces of the data file are outstanding. [0009] In some embodiments, the indication of the status of the upload of the data file includes a Data File Descriptor (DFD) message which describes how the data file to be uploaded is partitioned into the pieces or a DFD Complements (DFDC) message for the data file to be uploaded.

[0010] In some embodiments, the indication of the status of the upload of the data file includes the DFDC message for the data file to be uploaded. In some embodiments, the DFDC message comprises an indication of a size of each of the plurality of pieces to be uploaded to the destination network node. In some embodiments, the indication of the size of each of the plurality of pieces in the DFDC message is an indication that the size of each of the plurality of pieces is a uniform size. In some embodiments, the indication of the size of each of the plurality of pieces in the DFDC message is an indication of the size of each of the plurality of pieces where the size of each of the plurality of pieces may be variable. In some embodiments, the indication of the size of each of the plurality of pieces in the DFDC message is an indication that the size of each of the plurality of pieces may be dynamic. In some embodiments, the DFDC message includes the size of each of the pieces that has been determined.

[0011] In some embodiments, the wireless device is an owner of the data file, and the remainder of the wireless devices uploading the data file are helping the wireless device. In some embodiments, the wireless device is helping the owner of the data file upload the data file.

[0012] In some embodiments, the new serving network node is one of a Coordinated Multi Point (CoMP) set of cooperating nodes serving the wireless device. In some embodiments, the new serving network node is not one of the CoMP set of cooperating nodes serving the wireless device. In some

embodiments, the new serving network node is one of a CoMP set of

cooperating nodes to serve the wireless device.

[0013] In some embodiments, the method also includes sending, to one or more network nodes in the CoMP set of cooperating nodes of the wireless device in the wireless communication network, an indication that the new serving network node is the new serving network node for the wireless device. [0014] In some embodiments, the method also includes sending to the new serving network node a Super Set (SS) information message indicating that one or more network nodes in multiple CoMP sets of cooperating nodes in the wireless communication network are assisting in uploading the data file as multiple pieces to the destination network node. Each CoMP set is associated with one of the wireless devices uploading the data file.

[0015] In some embodiments, the method also includes sending, to the one or more network nodes in the CoMP sets that are assisting in uploading the data file, an indication that the new serving network node is the new serving network node for the wireless device.

[0016] In some embodiments, the method also includes sending, to a central- serving network node of the CoMP sets, an indication that the new serving network node is the new serving network node for the wireless device.

[0017] In some embodiments, the method also includes receiving one or more pieces of the data file to be uploaded and sending the one or more pieces to the new serving network node.

[0018] In some embodiments, the method also includes sending an indication to the new serving network node that there will be no more updates.

[0019] In some embodiments, the destination network node is the serving network node of the wireless device. In some embodiments, the destination network node is a node in a core network of the wireless communications network.

[0020] In some embodiments, a method of operation of a new serving network node in a wireless communications network includes receiving, from a serving network node of a wireless device that is uploading a data file as multiple pieces to a destination network node, an indication of a status of the upload of the data file and receiving a handover of the wireless device from the serving network node.

[0021] In some embodiments, the indication of the status of the upload of the data file includes a DFD message which describes how the data file to be uploaded is partitioned into the pieces and/or a DFDC message for the data file to be uploaded. In some embodiments, the indication of the status of the upload of the data file includes the DFDC message for the data file to be uploaded.

[0022] In some embodiments, the method also includes receiving from the serving network node an SS information message indicating that one or more network nodes in CoMP sets of cooperating nodes in the wireless communication network are assisting in uploading the data file as multiple pieces to the destination network node.

[0023] In some embodiments, the method also includes receiving, from the serving network node, one or more pieces of the data file to be uploaded. In some embodiments, the method also includes receiving an indication from the serving network node that there will be no more updates.

[0024] In some embodiments, the method also includes suspending retransmission requests for the wireless device. In some embodiments, the method also includes removing the suspension of retransmission requests for the wireless device based on a lapse of a predetermined amount of time since suspending the retransmission requests.

[0025] In some embodiments, the method also includes removing the suspension of retransmission requests for the wireless device based on receiving an indication from the serving network node that there will be no more updates.

[0026] In some embodiments, a serving network node is adapted to determine to perform a handover for a wireless device served by the serving network node to a new serving network node, where the wireless device is uploading a data file as multiple pieces to a destination network node. The serving network node is also adapted to send to the new serving network node an indication of a status of the upload of the data file and hand over the wireless device to the new serving network node.

[0027] In some embodiments, a computer program includes instructions which, when executed on one or more processors, cause the one or more processors to carry out any of the preceding methods. In some embodiments, the computer program is contained in a carrier which is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium. [0028] In some embodiments, a serving network node in a wireless communications network includes a handover determination module operative to determine to perform a handover for a wireless device served by the serving network node to a new serving network node, where the wireless device is uploading a data file as multiple pieces to a destination network node; an upload assistance module operative to send to the new serving network node an indication of a status of the upload of the data file; and a handover module operative to hand over the wireless device to the new serving network node.

[0029] In some embodiments, a serving network node in a wireless communications network includes a processor and memory. The memory contains instructions executable by the processor whereby the serving network node is operative to determine to perform a handover for a wireless device served by the serving network node to a new serving network node, where the wireless device is uploading a data file as multiple pieces to a destination network node. The serving network node is operative to send to the new serving network node an indication of a status of the upload of the data file and hand over the wireless device to the new serving network node.

[0030] Those skilled in the art will appreciate the scope of the present disclosure and realize additional aspects thereof after reading the following detailed description of the embodiments in association with the accompanying drawing figures.

Brief Description of the Drawings

[0031] The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.

[0032] Figure 1 illustrates a wireless communications network including multiple base stations (BSs) and multiple User Equipments (UEs) according to some embodiments of the present disclosure; [0033] Figure 2 is a flow chart illustrating a process for initiating a data file upload by an owner UE according to some embodiments of the present disclosure;

[0034] Figure 3 is a flow chart illustrating a process performed by the owner UE according to some embodiments of the present disclosure;

[0035] Figure 4 is a flow chart illustrating a process performed by a helper UE according to some embodiments of the present disclosure;

[0036] Figure 5 is a flow chart illustrating a process performed by a BS according to some embodiments of the present disclosure;

[0037] Figures 6A through 6C illustrate an interaction between multiple UEs for uploading a data file according to some embodiments of the present disclosure;

[0038] Figures 7A and 7B illustrate soft combining of Transport Blocks (TBs) according to some embodiments of the present disclosure;

[0039] Figures 8A through 8D illustrate an interaction between multiple BSs according to some embodiments of the present disclosure;

[0040] Figures 9A through 9G illustrate receiving multiple TBs at multiple BSs according to some embodiments of the present disclosure;

[0041] Figure 10 is a flow chart illustrating a process of determining a sender BS for a piece of the data file uploaded by the owner UE according to some embodiments of the present disclosure;

[0042] Figure 1 1 is a flow chart illustrating a process of determining a sender BS for a piece of the data file using one or more helper UEs according to some embodiments of the present disclosure;

[0043] Figure 12 is a flow chart illustrating a process of renewing assistance of one or more helper UEs according to some embodiments of the present disclosure;

[0044] Figure 13 is a flow chart illustrating a process of reconstructing the data file according to some embodiments of the present disclosure; [0045] Figure 14 is a flow chart illustrating a process of reconstructing the data file when dynamic piece sizes may have been used according to some embodiments of the present disclosure;

[0046] Figure 15 illustrates that two UEs may use the same set of BSs as their coordination set but they have different serving BSs, according to some embodiments of the present disclosure;

[0047] Figure 16 illustrates the formation of a Super Set (SS) in the

arrangement shown in Figure 15, according to some embodiments of the present disclosure;

[0048] Figure 17 illustrates that two UEs may have the same serving BS and different non-serving BSs, according to some embodiments of the present disclosure;

[0049] Figure 18 illustrates the formation of an SS in the arrangement shown in Figure 17, according to some embodiments of the present disclosure;

[0050] Figure 19 illustrates the coordination sets of two UEs with different serving BSs and a different set of non-serving BSs, according to some

embodiments of the present disclosure;

[0051] Figure 20 illustrates coordination sets of two UEs with different subsets of BSs, according to some embodiments of the present disclosure;

[0052] Figure 21 is a flow chart illustrating a process of uploading a data file in multiple pieces according to some embodiments of the present disclosure;

[0053] Figure 22 is a flow chart illustrating the creation of an SS according to some embodiments of the present disclosure;

[0054] Figure 23 is a flow chart illustrating a process of sending uploaded pieces to a destination network note such as a Mobility Management Entity

(MME), according to some embodiments of the present disclosure;

[0055] Figure 24 is a flow chart illustrating the validation of the upload of the data file, according to some embodiments of the present disclosure;

[0056] Figure 25 is a flow chart illustrating the creation of an SS according to some embodiments of the present disclosure; [0057] Figure 26 illustrates an SS of an owner UE with two helper UEs according to some embodiments of the present disclosure;

[0058] Figure 27 is a flow chart illustrating a process of handing over a UE that is uploading a data file as multiple pieces, according to some embodiments of the present disclosure;

[0059] Figure 28 is a flow chart illustrating a process of handing over a UE;

[0060] Figure 29 is a flow chart illustrating a process of handing over a UE that is uploading a data file as multiple pieces, according to some embodiments of the present disclosure;

[0061] Figures 30-35 illustrate various SS changes that can result from the movement of a UE, according to some embodiments of the present disclosure;

[0062] Figures 36 is a flow chart illustrating the handover process when an SS is used and the owner UE changes its serving BS, according to some

embodiments of the present disclosure;

[0063] Figures 37 is a flow chart illustrating the handover process when an SS is used and the helper UE changes its serving BS, according to some

embodiments of the present disclosure;

[0064] Figure 38 is a diagram of a network node according to some embodiments of the present disclosure;

[0065] Figure 39 is a diagram of a wireless device according to some embodiments of the present disclosure;

[0066] Figure 40 is a diagram of a network node including modules according to some embodiments of the present disclosure; and

[0067] Figure 41 is a diagram of a network node including modules according to some embodiments of the present disclosure.

Detailed Description

[0068] The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure and the accompanying claims.

[0069] Users of a wireless communications network desire high data rates for both downloading and uploading information. Providing these high data rates can be difficult in some situations. For example, low data rate cell-edge users continue to pose challenges to meeting these demands for high data rates. Such users tend to be interference limited. Furthermore, where such users are located indoors, there may be coverage gaps that constrain performance. In order to address this and other issues, Figure 1 illustrates a wireless communications network 10 including multiple base stations (BSs) 12-1 through 12-3 (sometimes referred to herein as BS 12 and BSs 12) and multiple User Equipments (UEs) 14- 1 through 14-5 (sometimes referred to herein as UE 14 and UEs 14) according to some embodiments of the present disclosure. While the term UE is generally used herein, a UE may be any type of wireless device, which is capable of at least communication through wireless communication. Examples of such UEs are sensors, modems, smart phones, Machine Type Communication (MTC), devices also referred to as Machine-to-Machine (M2M) devices, Internet of Things (loT) devices, narrow band loT devices, PDAs, iPads, tablets, Laptop Embedded Equipment (LEE), Laptop Mounted Equipment (LME), USB dongles etc.

[0070] Notably, much of the discussion herein focuses on embodiments in which the wireless communications network 10 is a 3 ^rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) cellular communications network. As such, 3GPP terminology is oftentimes used herein. However, while the embodiments described herein focus on 3GPP LTE, the embodiments and concepts disclosed herein may be used in any suitable type of existing or future cellular communications network including for example, 3 ^rd Generation (3G) networks (e.g. Universal Mobile Telecommunications System (UMTS)), 4 ^th Generation (4G) networks (Worldwide Interoperability for Microwave Access (WiMAX), LTE, Long Term Evolution Advanced (LTE-A)), 5 ^m Generation (5G) or other future networks.

[0071] In Figure 1 , each BS 12 is shown as serving three cells, for example. In this example, a first wireless device UE 14-1 has a data file that needs to be uploaded. Herein, the UE 14 that has a data file to be transferred (uploaded or downloaded) is sometimes referred to as the owner UE 14. This is not intended to imply any actual ownership of the data file or any legal relationship. In some embodiments, the owner UE 14 will have help from one or more second wireless devices such as UEs 14-2 through 14-5. Herein, a UE 14 that helps an owner UE 14 to transfer a data file is sometimes referred to as a helper UE 14.

[0072] In some embodiments, one or more of the BSs 12 are part of a

Coordinated Multi-Point (CoMP) set of cooperating nodes in the wireless communications network 10. In some embodiments, one or more of the UEs 14 is able to communicate via Device-to-Device (D2D) communication as in LTE implementations, and/or is able to communicate via other wireless technologies. Examples of non-LTE wireless technologies include variants of the IEEE 802.1 1 standards suite, such as Wi-Fi and Wi-Fi Direct, as well as Bluetooth, Zigbee, cordless phone technologies, or the like. Systems based on these technologies may operate in an unlicensed spectrum.

[0073] Recently, D2D communications as an underlay to cellular networks have been proposed as a method for taking advantage of the proximity of communicating devices and at the same time to allowing devices to operate in a controlled interference environment. This is referred to as network-assisted D2D communication. Typically, it is suggested that such D2D communication shares the same spectrum as the cellular system, for example by reserving some of the cellular uplink resources for D2D purposes. Devices that want to communicate, or even just discover each other, typically need to transmit various forms of signaling. One example of such signaling is the so-called discovery signal (which may possibly include a full message), which at least carries some form of identity and is transmitted by a device that wants to be discoverable by other devices. Other devices can scan for the discovery signals. Once they have detected the discovery signal, they can take the appropriate action, for example trying to initiate a connection setup with the device transmitting the discovery message.

[0074] While not limited thereto, the owner UE 14 may communicate with one or more helper UEs 14 via D2D communication to help upload a data file. One embodiment of this for the wireless communications network 10 of Figure 1 is shown in Figure 2, which is a flow chart illustrating a process for initiating a data file upload by an owner UE 14-1 according to some embodiments of the present disclosure. In this embodiment, owner UE 14-1 creates a Data File Descriptor (DFD) (step 100). Generally, a DFD describes the data file to be uploaded, and several examples of a DFD will be discussed below. The owner UE 14-1 should construct a DFD which indicates how the target file to be uploaded is partitioned into pieces for the upload process. One of the fields in the DFD is piece length or size. With respect to this file piece size, three different embodiments are envisioned.

[0075] In a first embodiment, all the pieces of the file are the same size referred to as a Uniform Piece Size (UPS). In order to determine the piece size, at least (but not limited to) two factors are considered by the owner UE 14-1 : the total file size, and the quality of the communication in the channel between the owner UE 14-1 and its serving BS 12. As one example, in an LTE system, channel quality can be based on SINR as measured by an RSRP or RSRQ type measurement on the Sounding Reference Symbol (SRS) on the uplink. One important point to consider is that very small piece sizes may lead to too many pieces and this may impose an unnecessary overhead onto the network. On the other hand, the problem with the very large pieces is that it may be difficult to send them in a reasonable number of segments, since larger pieces will need to be divided into lots of segments in the lower layers of the LTE protocol architecture. A trade-off between the data file size and communication channel quality and the piece size is considered. The current assumption for the smallest and the largest piece size regardless of the data file size is 128 Kbyte (KB) and 2048 KB, respectively. However, the present disclosure is not limited thereto. The piece size in the current assumption can be one of the following numbers in KB: 128, 256, 512, 1024 and 2048. As Table 1 shows, the DFD file size is small enough (it includes 6 numbers and a file name) that the owner UE 14-1 can easily upload the DFD to its serving BS 12. In one embodiment, the owner UE 14-1 determines the piece size solely before uploading the file independent of the number of helper UEs 14. The DFD pertaining to this mode has the fields described in the following table:

[0076] In another embodiment referred to as a Variable Piece Size (VPS), the owner UE 14-1 considers multiple piece sizes and divides the data file based on these sizes. During the upload process and after receiving a confirmation message from the helper UEs 14 (discussed in detail below), the owner UE 14-1 sends larger pieces to the helper UEs 14 with a larger preferred piece size or a larger upload data rate. The owner UE 14-1 sends smaller pieces to the helper UEs 14 with lower preferred piece size or lower upload data rate. To do so, the owner UE 14-1 should announce different sizes of the pieces in DFD file, and the helper UEs 14 select their preferred piece size based on their current condition. They let the owner UE 14-1 know about their decision by using the confirmation message. Table 2 shows the content of DFD for VPS approach: Field Name Field Type Value

1 Message ID Integer (Unitless) 12

2 Data File Name String

3 Data File Size Float (In MB)

4 Piece Size Integer Array (In KB)

5 Number of the Pieces Integer (Unitless)

6 Owner UE ID Integer (Unitless)

Table 2: Variable Piece Size DFD Message Content

[0077] In a third embodiment referred to as Dynamic Piece Size (DPS), the owner UE 14-1 determines the piece size during the transfer process based on a number of criteria. These criteria may include, but are not limited to, the simultaneous channel quality of the owner UE 14-1 and the helper UEs 14.

Therefore, the number of pieces is not known at the owner UE 14-1 until the file transfer procedure is completed. Table 3 defines the DFD message structure for this approach.

Table 3: Dynamic Piece Size DFD Message Content

[0078] As can be seen in Tables 1 through 3, there are differences among the structure of the DFD messages for these three methods. It should also be noted that these are only examples for a DFD message, and this disclosure is not limited thereto. In UPS approach, there is just one piece size, and based on this selected piece size, the owner UE 14-1 knows that the data file is divided into how many pieces. The same situation is valid for VPS method except for the fact that in VPS, the owner UE 14-1 uses more than one piece size. In both cases, the owner UE 14-1 knows the number of the pieces and the length of each piece before starting the upload phase. Therefore, the owner UE 14-1 can insert this information to the related DFD message and then send it for the BSs 12 in the CoMP set. The serving BS 12 can use the same DFD message to check the correct reception of all the pieces at the end of the upload.

[0079] In case of DPS, the owner UE 14-1 does not know the piece size prior to the upload process. Therefore, the owner UE 14-1 does not know how many pieces are required to upload the whole data file. When the owner UE 14-1 starts to upload the data file, it determines each piece size, for instance, based on its communication channel condition to the BS 12 at the time of transmitting to the network. In addition, when the owner UE 14-1 wants to send a part of the data to the helper UE 14, it may determine the piece size based on the provided information from helper UEs 14. As a result, at the beginning of the upload process (before the owner UE 14-1 starts to send the pieces), the owner UE 14-1 sends the DFD message of DPS mode as defined in Table 3 above to the BSs 12 in the CoMP set. As can be seen, there is no information about the pieces inside this message structure. During the upload process (when the owner UE 14-1 starts to create the pieces and send them), it completes the DFD message by inserting the information of each piece (piece number, piece size, the first byte address in the data file, the last byte address in the data file), for example. At the end of the upload process (after all the pieces are transmitted), the owner UE 14- 1 sends the final version of the DFD message (the one that has all the

information about all the pieces) for the BSs 12 in the CoMP set. The serving BS 12 uses this version of the DFD message to determine if there are any

differences between the control information of received pieces and their control information in final DFD. This process enables the serving BS 12 to perform the proper action in the case of an error condition.

[0080] Returning now to Figure 2, the owner UE 14-1 then sends an upload request message to one or more BSs 12 (step 102). This message may be transmitted to more than one BS 12, for example, if the BSs 12 are part of a CoMP set. Note that in addition to the legacy LTE feature of a UE 14 requesting resources from its serving BS 12, the owner UE 14-1 may also be able to request resources from the cooperating BSs 12 in the CoMP set. These BSs 12 cooperate with each other to support the owner UE 14-1 upload process. Table 4 below shows an example upload request message:

Table 4: Upload Request Message Definition

[0081] The owner UE 14-1 then sends an upload assistance message to or more helper UEs 14 (step 104). Table 5 below illustrates a possible

corresponding upload assistant message structure for the UPS and VPS methods:

Table 5: Upload Assistant Message definition (UPS and VPS) [0082] In case of DPS, the upload assistance message structure does not require the last two fields of Table 5 (piece size and number of the pieces). The reason is that in the DPS method, the owner UE 14-1 does not have any information about the pieces prior to the actual upload of the pieces. A possible upload assistance message structure for the DPS method is illustrated in Table 6 below:

Table 6: Upload Assistant Message definition (DPS) [0083] The owner UE 14-1 may receive a handshake message from the one or more BSs 12 (step 106). Depending on the implementation, these handshake messages may include information related to uplink scheduling resources, the BSs 12 that are part of a CoMP set, et cetera. In some embodiments, the handshake message may be similar to the one provided in Table 7:

Table 7: UE Upload Handshake Message

[0084] The owner UE 14-1 sends the DFD message to its serving BS 12-1 (step 107).

[0085] The owner UE 14-1 then receives one or more confirmation messages from the one or more helper UEs 14 (step 108). These messages may indicate whether or not a particular helper UE 14 is willing to help the owner UE 14-1 upload the data file. As used herein, being willing to help indicates willing and able to help. These messages may also contain information regarding the number and/or size of the pieces the helper UE 14 is willing to help with, along with information such as a physical location of the helper UE 14 or an upload bit rate or channel quality indication. Helper UEs 14 can voluntarily or by instruction from a BS 12 listen to the upload assistance request message from the owner UE 14-1 . If a candidate helper UE 14 is capable of assisting the owner UE 14-1 , it transmits the confirmation message to the owner UE 14-1 .

[0086] There are a number of parameters that a helper UE 14 can use to announce itself as a potential helper, including: the communication channel condition, the remaining battery life of the helper UE 14, security issues, and service provider rewards or incentives for the helper UE 14, for example.

[0087] In the UPS method, the helper UE 14 informs owner UE 14-1 of the maximum number of the pieces that the helper UE 14 can accept (based on the piece size in the upload assistance message). It should be noted that in this embodiment it is assumed that neither the BSs 12 nor the helper UEs 14 have any part of the data file, but in other embodiments, they could have part of the data file and they may let the owner UE 14-1 know which part of the data file is available to them. The following table shows a possible message structure of the Confirmation message in the UPS method. Note that the value of the fourth field of this message (list of the available pieces) is always NULL in this example:

Table 8: Helper UE Confirmation Message (UPS)

[0088] In the case of using either the VPS or DPS methods, the helper UE 14 may use the following table as the confirmation message structure. In both cases, the helper UEs 14 define their preferred piece size based on the previously described criteria. Upon receiving the helper confirmation message, the owner UE 14-1 sends one or more pieces of the data file, such that each piece size is equal to or less than the preferred piece size defined for the helper UE 14. Again, if there is any available piece of the same data file to be uploaded at the helper UE 14, it may insert the address of the first byte and the last byte of the available pieces into the confirmation message as well. This aids the owner UE 14-1 in determining which part of the data file is already available at the helper UE 14. A possible confirmation message in VPS or DPS is shown in Table 9:

Table 9: Helper UE Confirmation Message (VPS or DPS)

[0089] While the messages of Figure 2 are shown in a particular order, this disclosure is not limited thereto. For instance, the owner UE 14-1 may receive a handshake message from the one or more BSs 12 before sending an upload assistance message to the one or more helper UEs 14.

[0090] Helper UEs 14 able to assist the owner UE 14-1 and selected for assistance (such as by the owner UE 14-1 ) are also sending upload request messages to the one or more BSs 12 (step not shown). These upload request messages may be similar to the upload request message from the owner UE 14- 1 to the BS 12, shown in step 102.

[0091] Figure 3 is a flow chart illustrating a process performed by the owner UE 14-1 according to some embodiments of the present disclosure. The owner UE 14-1 divides a data file to be uploaded into a plurality of pieces (step 200). The owner UE 14-1 then creates a DFD which describes how the data file to be uploaded is partitioned into a plurality of pieces (step 202). The owner UE 14-1 sends an upload request message to a serving BS 12 of the owner UE 14-1 (step 204) and sends an upload assistance message to one or more helper UEs 14 (step 206). Depending on the embodiment, steps 204 and 206 may be performed in a different order or may be performed in parallel.

[0092] The owner UE 14-1 receives an upload assistance confirmation message from one or more of the helper UEs 14 (step 208) and, in response, sends one or more pieces of the plurality of pieces to the one or more helper UE 14 to be uploaded to the destination network node (step 210). The owner UE 14- 1 then optionally uploads one or more pieces of the plurality of pieces to the destination network node (step 212). In some embodiments, the destination network node is the serving BS of the owner UE 14-1 . In other embodiments, the destination network node is a node in a core network of the wireless

communications network 10 such as a Mobility Management Entity (MME) 16. In some embodiments, the destination network node, such as the MME 16, is reached indirectly via one or more intermediate destination network nodes.

[0093] Figure 4 is a flow chart illustrating a process performed by a helper UE 14 according to some embodiments of the present disclosure. The helper UE 14 receives an upload assistance message from an owner UE 14-1 (step 300). If willing to help, the helper UE 14 sends an upload assistance confirmation message to the owner UE 14-1 (step 302). The helper UE 14 receives one or more pieces of the plurality of pieces from the owner UE 14-1 to be uploaded to the destination network node (step 306) and uploads the one or more pieces of the plurality of pieces to the destination network node (step 306).

[0094] Figure 5 is a flow chart illustrating a process performed by a BS 12 according to some embodiments of the present disclosure. The BS 12 receives an upload request message from an owner UE 14-1 and one or more helper UEs (14-2, 14-N) (step 400). Optionally, upon receiving the upload request message from the owner and helper UEs 14, BS 12 sends a handshake message to all the UEs 14 requesting upload, indicating that the BS 12 can support the upload (step not shown). Next, the BS 12 receives a DFD from the owner UE 14-1 (step 401 ). The DFD describes how the data file to be uploaded is partitioned into a plurality of pieces. The upload request message from the owner UE 14-1 and the DFD information may be included in several messages exchanged between the BS 12 and the owner UE 14s as shown in Figure 2, for example, or may all be included in a single message sent from the owner UE 14-1 . The BS 12 receives one or more pieces of the plurality of pieces from one or more helper UEs 14(step 402- 1 ). Optionally, the BS 12 receives one or more other pieces of the plurality of pieces from the owner UE (step 402-2). The one or more other pieces of the plurality of pieces, or remaining pieces of the plurality of pieces, are pieces from the plurality of pieces not received by the BS 12 from any helper UEs 14. In some embodiments, the BS 12 may also receive one or more pieces of the plurality of pieces from any combination of one or more serving BS 12 of the respective one or more helper UEs 14, one or more non-serving BSs 12 of the one or more helper UEs 14 and one or more non-serving BSs 12 of the owner UE 14-1 .

[0095] In some embodiments, the destination network node is some other network node, such as a node in the core network, for example MME 16. In this case, the BS 12 forwards the received pieces to this other network node. In another embodiment, the BS 12 itself is the destination network node, and then the data file has arrived in the correct location. According to some further embodiments, in all these scenarios, the BS 12 determines if each of the plurality of pieces has been received (step 406). If not all of the pieces have been received, the process optionally returns to a point in the flow prior to steps 402-1 and 402-2 to receive more pieces. If all of the pieces have been received, the destination network node (which, as noted, can be either BS 12 or another network node), uses the plurality of pieces to create the data file to be uploaded (step 408). As the destination network node is not necessarily BS 12, step 408 is optional when Figure 5 relates to steps performed at BS 12. [0096] Figures 6A through 6C illustrate an interaction between multiple UEs 14 for uploading a data file according to some embodiments of the present disclosure. In this example, Figure 6A shows that the data file is divided into 21 pieces by the owner UE 14-1 . These pieces may conform to any of the methods disclosed above such as UPS, VPS, or DPS. Figure 6B shows that pieces 18 through 21 have been sent to helper UE 14-2 and pieces 12 through 17 have been sent to UE 14-3. As discussed above, the determination regarding how many pieces and which size pieces (when applicable) may be based on several criteria such as channel quality between a helper UE 14 and its serving BS 12. Figure 6C shows the helper UE 14-2 and helper UE 14-3 have uploaded their assigned pieces and owner UE 14-1 has uploaded (or still needs to upload) the remaining pieces 1 through 1 1.

[0097] After determining the DFD, the UEs 14 start to send their pieces to the BSs 12 in the CoMP set. Both owner UEs 14 and helpers UEs 14 send their pieces to the BSs 12 within range. Table 10 shows a possible structure of the message that the UEs 14 use in the UPS, VPS and DPS methods to send their pieces for the BSs 12. When the BSs 12 receive a piece message, they save the piece data. In addition, the BSs 12 save control information about the received data file and its pieces (including the data file name, data file size, number of the pieces, and which pieces are available at the BS 12). This information aids the BSs 12 in preventing future uploading of the same data by the other UEs 14.

[0098] Note that in some embodiments there is no guarantee that in future uploads that the UEs 14 will use the same piece length to upload the same data file. Therefore the piece number is not a good metric to provide information about the available data parts at the BSs 12. A better solution is to use the address of the first and the last byte of the piece in the data file. This information can assist the UEs 14 to understand which part of the data file is already available at the BS side.

[0099] If an owner UE 14-1 uploads a piece, the owner UE ID and the sender UE ID will be the same in the related piece message structure. Otherwise, if a helper UE 14 uploads a piece then the sender UE ID will be the ID of this helper UE. In addition, if the UEs 14 implement the DPS method, the owner UE 14-1 updates the DFD after creating each piece message in some embodiments.

Table 10: Structure of Piece Messages [0100] By receiving a confirmation message from a helper UE 14, the owner UE 14-1 will need to decide whether it will employ that helper UE 14 or not. This decision can be made based on different factors including the quality of the communication channel between the owner UE 14-1 and the helper UE 14 and the number of helper UEs 14. Upon selection of the helper UEs 14, the owner UE 14-1 sends a number of pieces to the helper UE 14. The number of pieces is determined based on the information in the confirmation message. The owner UE 14-1 keeps track of the pieces that are assigned to each helper UE 14. In addition, if the DPS method is being employed, the owner UE 14-1 may update the DFD after creating each piece message or after some number or piece messages are created. Table 1 1 shows a possible message structure that the owner UE 14-1 may use in the UPS, VPS and DPS methods to send pieces to the helper UEs 14.

Table 1 1 : The piece message structure for a UE-to-UE communication in UPS,

VPS, and DPS

[0101] After a piece is uploaded to one or more BSs 12, it must be determined if the data was received correctly. Error checking may be performed at three different levels. The receivers (the BSs 12 in the CoMP set of a certain UE 14) perform the first two error checking steps in the Media Access Control (MAC) and Radio Link Control (RLC) layers of LTE protocol stack. The serving BS 12 performs the last and highest level of error checking at the end of the upload process in the upper layers of LTE protocol stack. The MAC and RLC layers are responsible for the first and second levels of error checking, respectively. To discuss the retransmission process in the MAC layer, it is necessary to know that the RLC layer dynamically divides the pieces that it receives from Packet Data Convergence Protocol (PDCP) layer into a number of segments (known as RLC Protocol Data Units (PDUs)) based on the contemporary communication channel condition. The MAC layer then uses the RLC PDUs and MAC headers to form Transport Blocks (TBs), again based on the contemporary communication channel condition. Therefore, the data unit in the MAC layer is the TB.

[0102] There may be a number of BSs 12 which form the CoMP coordination set to support a UE 14 upload. It is important to mention that the serving BS 12 is usually the only BS 12 in the CoMP set that sends control messages such as Acknowledgement (ACK) or Negative Acknowledgement (NACK) for the UE 14. In addition, the non-serving BSs 12 usually send a feedback to the serving BS 12 when they receive a TB. For example, Figure 1 shows a CoMP set of three BSs 12 supporting a UE 14 upload. In this example, BS 12-1 is the serving BS 12, and BS 12-2 and BS 12-3 are the non-serving BSs 12 of the CoMP coordination set. When the UE 14 transmits its TB in the upload process, one of the following two situations can happen at the BS 12 receivers. Either the TB does not need to be retransmitted, or it does need to be retransmitted.

[0103] In the following three situations, the serving BS 12 does not need to send a retransmission request to the UE 14, because at least one of the BSs 12 in the CoMP set is able to recover data from the received TB:

1 . All the BSs 12 of the CoMP set receive the transmitted TB without error. As a result, the serving BS 12 sends an ACK message for the UE 14.

2. A subset of the BSs 12 of the CoMP set, including the serving BS 12, receives the transmitted TB without error, and the rest of the BSs 12 receive it with error. In this case, the serving BS 12 sends an ACK message for the UE 14.

3. A subset of the BSs 12 of the coordination set that the serving BS

12 is not one of receives the transmitted TB without error, and the rest of the BSs 12, including the serving BS 12, receive it with error. In this situation, the serving BS 12 waits for the feedback from other non-serving BSs 12 about the

transmitted TB. If at least one of the non-serving BSs 12 sends a positive acknowledgement for the serving BS 12, the serving BS 12 is able to send an ACK for the UE 14. [0104] If none of these situations occur, and none of the BSs 12 in the CoMP set correctly recover the data from the received TB, the serving BS 12 requests a retransmission of that TB. In this case, it is possible to use Hybrid Automatic Repeat Request (HARQ) with soft combining as a retransmission scheme.

HARQ with soft combining is categorized into Chase Combining (CC) and

Incremental Redundancy (IR). CC resends the same bits in each retransmission, which can be soft combined. In IR, each retransmission sends a new

redundancy version - i.e. a new set of coded bits different from the first. Both of these methods work as follows: the receiver asks for the retransmission up to three times if it cannot recover the data from the initial transmission. In addition, the receiver uses previous erroneous TBs for data recovery in addition to the new received TB. This method increases the accumulated received E_b/N_0 for each retransmission and increases the chance to recover the original data from the received TBs. If after completing four transmissions the BSs 12 cannot recover the original data from the TBs, the MAC layer does not do anything about this TB, and it leaves the error recovery for the upper layer (RLC layer). Figures 7A illustrates how CC may work in one example, and Figure 7B illustrates how IR may work in one example.

[0105] One problem with these methods is that each transmission and retransmission consumes UE 14 process time. For example, the initial transmission and the first two retransmissions provide an opportunity for the BSs 12 to perform CC based on the three TBs that are identical, but this means that three time slots are wasted to transmit the same TB. In addition, if the BSs 12 are allowed to send retransmission requests to the UE 14 in an independent manner, then another problem arises. Figures 8A through 8D illustrate an interaction between multiple BSs 12 where the same TB is transmitted a total of four times to each of the three BSs 12. Consider the case in which one of the BSs 12 receives the transmitted TB error free during some transmission and the other two BSs 12 receive it with error. The second and third BSs 12 may send retransmission requests to the UE 14 directly and as a result, the UE 14 starts the retransmission process. This process is wasteful since the first BS 12 received the TB without error and in essence, a retransmission is not required as discussed above. Rather, the BSs 12 could communicate and let each other know about the status of TB reception at their side. By reducing unnecessary retransmissions, the performance of a UE 14 is enhanced.

[0106] Figures 9A through 9G illustrate receiving multiple TBs at multiple BSs according to some embodiments of the present disclosure. As in the previous discussion, a CoMP coordination set of three BSs 12 similar to the one shown in Figure 1 supports the UE 14 upload. In this example, BS 12-1 is the serving BS again, and BS 12-2 and BS 12-3 are the non-serving BSs of the CoMP set.

[0107] The UE 14 starts to upload the initial TB, and each of the BSs 12 receives this TB. As it is shown in Figure 9A, the serving BS 12 tries to recover the data from the received TB. The non-serving BSs 12 try to recover the data from the received TB at their side as well. Also they send their feedback to the serving BS 12-1 . If at least one of the BSs 12 was able to receive the TB without error, the problem is solved, but if not, the serving BS 12-1 asks the non-serving BSs 12 to send their TB to the serving BS12. Note that during this time, the UE 14 continues uploading other pieces. After receiving the TB from the other BSs 12, the serving BS 12 is able to perform CC on them as it is shown in Figure 9A. As mentioned earlier, this process increases the chance of recovering the data from the TB. This allows for a CC iteration after only one transmission of the UE 14 instead of the UE 14 needing to repeat the upload two more times to provide three identical TBs for the BSs 12 to increase the chance of data recovery.

Rather, the non-serving BSs 12 can send their TBs to the serving BS 12. By doing this, there is the same amount of information at the serving BS 12 that can be used to recover the original data using CC.

[0108] If the first CC does not work, the serving BS 12 sends a NACK message regarding this TB to the UE 14. The UE 14 retransmits this TB based on an IR approach in this embodiment (i.e. using a different redundancy version than in the first transmissions) as is shown in Figure 9B. After receipt of the second redundancy version from the UE 14, the serving BS 12 tries to recover data using IR based on the newly received TB and the previously CC TBs from previous step. At the same time, the non-serving BSs 12 try to recover the TB data from the newly received redundancy version (they just have the new TB and the previous one that they received in previous step in this embodiment, but in other embodiments the TBs may be shared among each BS 12 in the CoMP set). If no BS 12 can recover the original data, then the serving BS 12 again asks the non-serving BSs 12 to send their TB for the serving BS 12. After that, the serving BS 12 performs the CC based on the previous and new TBs as illustrated in Figure 9C to recover the original data. Again, if the process is successful, the serving BS 12 sends an ACK to the UE 14 but if not, then it sends a NACK to the UE 14. In the latter case, the retransmission process continues up to three times. The next steps are shown in Figures 9D through 9G. If after all these steps none of the BSs 12 are able to recover the original data from the received TBs, the MAC layer leaves the task of error free data recovery for the upper layer (RLC layer).

[0109] As was discussed previously regarding LTE, the RLC layer may divide the pieces into a number of PDUs, and the MAC layer forms TBs based on the contemporary communication channel condition. If at least one of the BSs 12 of the CoMP set has all the TBs of a piece, the serving BS 12 can ask that BS 12 (if it is not the serving BS 12 itself) to send that piece to the destination network node such as MME 16 or to some other destination network node. It is also possible that none of the BSs 12 of the CoMP set has successfully received all of the TBs of a piece. For this second scenario, it should be noted that the serving BS 12 has all the information about the pieces and their TBs at the non-serving BSs 12, since the non-serving BSs 12 send feedback per each TB to the serving BS 12.

[0110] If the second scenario occurs, the serving BS 12 may select one of the BSs 12 of CoMP set (perhaps the one with the most correctly decoded TBs) as the sender BS 12. The sender BS 12 is the BS 12 which is responsible for sending the current piece to the destination network node (the MME 16 in this and later examples). Figure 10 is a flow chart illustrating a process of

determining a sender BS 12 for a piece of the data file uploaded by the owner UE 14-1 according to some embodiments of the present disclosure. First, an owner UE 14-1 sends TBs of a piece to the BSs in the CoMP set as initial transmissions or in a retransmission phase (step 500). The owner UE 14-1 then receives either an ACK or a NACK for a TB and may need to retransmit one or more of the TBs (step 502). These steps may proceed as in any of the previous embodiments discussed in regard to correctly decoding TBs. Once all of the TBs for a piece have been correctly received by one or more BSs 12, the serving BS 12-1 checks who will be the sender BS 12 for this piece (step 504). But in this case, the sender BS 12 (which can be the serving BS 12-1 itself or one of non-serving BSs 12) does not have one or some of the TBs of a piece. The serving BS 12-1 solves this problem by querying the BSs 12 to determine which BSs 12 have the missing pieces and requests that they be sent to the sender BS 12 (step 506). The following table shows the message structure that the serving BS 12-1 uses to query the BSs 12 to send specific TBs to the sender BS 12. The serving BS 12-1 may send this message to more than one BS 12 to query for the different TBs of a single piece. In this situation, it inserts the TBs number that it wants from each BS 12 in the 'missing TBs number' field of the message.

Table 12: Sender Query Message [0111 ] The one or more BSs 12 send the required TBs of this piece to the sender BS 12 (step 508). By following this process, the sender BS 12 is the serving BS 12-1 , then the serving BS 12-1 is able to form the whole piece and send it to the MME 16 (step 510).

[0112] If another BS 12 is the sender BS 12, the serving BS 12-1 asks the non-serving BS 12 to forward the piece to the MME 16 (step 512). The serving BS 12-1 may use the message structure in Table 13 to ask the sender BS 12 (if the serving BS 12-1 itself is not the sender BS 12) to forward the piece to the MME 16.

Table 13: Sender Forwarding Message [0113] The sender BS 12 then sends the piece to the MME 16 (step 514). In all three approaches (UPS, VPS and DPS), the BSs 12 may use the message structure in Table 14 to forward a piece for the MME 16. The required information to fill this message is already available in the received piece.

Field Name Field Type Value

1 Message ID Integer (Unitless) 72

2 Owner UE ID Integer (Unitless)

3 Serving BS ID Integer (Unitless)

4 Sender BS ID Integer (Unitless)

5 Data File Name String

6 Pieces Number Integer (Unitless)

7 First Byte Address Integer (Unitless)

8 Last Byte Address Integer (Unitless)

9 Data Load

Table 14: Message structure that BSs use to send a piece for the MME

[0114] Lastly, the serving BS 12-1 updates a DFD Complements (DFDC) file for the data file being uploaded, if it is required (step 516). This will be discussed in more detail below.

[0115] Figure 10 only showed how pieces were handled when the owner UE 14-1 uploaded the piece itself. Figure 1 1 is a flow chart illustrating a process of determining a sender BS 12 for a piece of the data file using one or more helper UEs 14 according to some embodiments of the present disclosure. First, an owner UE 14-1 sends pieces to one or more helper UEs 14 as discussed above (step 600). The owner UE 14-1 receives either an ACK or a NACK regarding this transmission (step 602) and may resend and pieces that were not correctly received. Once a helper UE such as helper UE 14-2 has the piece, the helper UE 14-2 sends TBs of a piece to the BSs in the CoMP set as initial transmissions or in a retransmission phase (step 604). The helper UE 14-2 then receives either an ACK or a NACK for a TB and may need to retransmit one or more of the TBs (step 606). These steps may proceed as in any of the previous embodiments discussed in regard to correctly decoding TBs. Once all of the TBs for a piece have been correctly received by one or more BSs 12, the serving BS 12-1 checks who will be the sender BS 12 for this piece (step 608). In this case, the sender BS 12 (which can be the serving BS 12-1 itself or one of non-serving BSs 12) does not have one or some of the TBs of a piece. The serving BS 12-1 solves this problem by querying the BSs 12 to determine which BSs 12 have the missing pieces and requests that they be sent to the sender BS 12 (step 610). This step may use the same format as discussed above in regard to step 506. The serving BS 12-1 may send this message to more than one BS 12 to query for the different TBs of a single piece. In this situation, it inserts the TBs number that it wants from each BS 12 in the 'missing TBs number' field of the message.

[0116] The one or more BSs 12 send the required TBs of this piece to the sender BS 12 (step 612). By following this process, the sender BS 12 is the serving BS 12-1 , then the serving BS 12-1 is able to form the whole piece and send it to the MME 16 (step 614). If another BS 12 is the sender BS 12, the serving BS 12-1 asks the non-serving BS 12 to forward the piece to the MME 16 (step 616). The serving BS 12-1 may use the message structure in Table 13 to ask the sender BS 12 (if the serving BS 12-1 itself is not the sender BS 12) to forward the piece to the MME 16. The sender BS 12 then sends the piece to the MME 16 (step 618). In all three approaches (UPS, VPS and DPS), the BSs 12 may use the message structure in Table 14 to forward a piece to the MME 16. The required information to fill this message is already available in the received piece. Lastly, the serving BS 12-1 updates a DFD Complements (DFDC) file for the data file being uploaded, if it is required (step 620). This will be discussed in more detail below.

[0117] During any of these processes, an owner UE 14-1 may want to extend its cooperation with a helper UE 14. Figure 12 is a flow chart illustrating a process of renewing assistance of one or more helper UEs 14 according to some embodiments of the present disclosure. In this case, the owner UE 14-1 sends a renewal message to the helper UE 14-2 to inform it of the remaining pieces that are required to be uploaded (step 700). The owner UE 14-1 may select one of the message structures in Tables 15 to 17 based on the selected method. Field Name Field Type Value

1 Message ID Integer (Unitless) 81

2 Owner UE ID Integer (Unitless)

3 Data File Name String

4 Number of Remaining Pieces Integer (Unitless)

Table 15: Renewal message si ructure in UPS met hod

[0118] The owner UE 14-1 uses the renewal message when it estimates that the helper UE 14 is close to finishing the upload of the assigned pieces. The owner UE 14-1 can make such an estimation based on the total size of the pieces that it sent for the specific helper UE 14 and the elapsed time since that time. Also, it can use the ACK feedback from the serving BS 12-1 (ACK messages of the received pieces show how much data is left at the helper UE 14 that is required to be uploaded). Another important factor is the upload data rate of the helper UE 14. There are two approaches that help the owner UE 14-1 to receive this information. The helper UE 14 may announce its upload data rate to the owner UE 14-1 when it sends the confirmation message (although it can change as the time passes). Also, the serving BS 12-1 may send a control message for the owner UE 14-1 in the fixed intervals that show the latest upload data rate of the helper UEs 14.

[0119] In response to receiving the renewal message, the helper UE 14 sends back a renewal approval message that indicates if it wants to continue the cooperation with the owner UE 14-1 or not (step 702). It may use one of the message structures in Table 18 or 19 (based on the selected method). In case of VPS, the helper UE 14 must select the preferred piece sizes based on the provided information in the received renewal message. In case of using DPS, the helper UE 14 considers the preferred piece size based on its communication channel condition with the serving BS 12-1 (or the BSs 12 in the CoMP set). If the helper UE 14 finishes the upload of the pieces that was assigned to it by the owner UE 14-1 , it may want to help the owner UE 14-1 further. To do so, the helper UE 14 may send a renewal approval message even before receiving a renewal request from the owner UE 14-1 .

Table 18: Renewal approval message structure in UPS method Field Name Field Type Value

1 Message ID Integer (Unitless) 85

2 Renewal Boolean

3 Helper UE ID Integer (Unitless)

4 Max Data Size Offer to Help in Upload Integer (In KB)

Preferred Piece Size Integer (In KB)

5

Datafile Name String

6

Tab e 19: Renewal approval message structure in VPS and DPS methods

[0120] Once all of the pieces have been uploaded, they may need to be reassembled. Figure 13 is a flow chart illustrating a process of reconstructing the data file according to some embodiments of the present disclosure. After sending all the pieces of the data file to the BSs 12 in the CoMP set, the owner UE 14-1 may use the message structure in Table 20 to send a done message to the CoMP set to announce that it finished the upload of all the pieces (step 800).

Table 20: Done message in UPS, VPS and DPS

[0121] One or more of the BSs 12 may send an ACK or NACK indicating that the done message was properly received or not (step 802).

[0122] The third and the last level of error checking occur in the layers above the RLC layer. In this step, the serving BS 12-1 checks the received pieces information with the DFD file (step 804) to make sure that the BSs 12 of the CoMP set collectively received the pieces of the UE data file completely and correctly. As described in the previous sections, during the upload process, the non-serving BSs 12 of the CoMP set send the control information of the received pieces to the serving BS 12-1. Therefore, at the end of the upload process, the serving BS 12-1 has the control information of all the received pieces in some embodiments. It inserts the information of each piece into a DFDC list. A possible DFDC structure is illustrated in Table 21. In this table, the piece's status is one (1 ) if it has been received correctly otherwise it is zero (0). The length of the piece number array is equal to the number of the pieces and there is a corresponding piece status array, which includes the information about the reception of the pieces.

Table 21 : DFDC structure in UPS, VPS and DPS methods

[0123] After receiving the done message from the owner UE 14-1 , the serving BS 12-1 checks the DFD and DFDC together to see if their information about the pieces are the same. If the information does not match, the serving BS 12-1 sends a report (DFDC) to the owner UE 14-1 (step 806) to let it know about the pieces that have not been correctly received. The owner UE 14-1 tries to resend erroneous pieces based on what has been discussed in the previous sections (steps 808 through 812). After that, the owner UE 14-1 sends the done message to the BSs 12 of the CoMP set again (step 814). The serving BS 12-1 again checks the pieces (step 816). If these steps help the serving BS 12-1 to resolve the problem, then the serving BS sends the final DFD for the MME 16 (step 818). Otherwise, the serving BS 12-1 may cancel the whole upload process and inform the owner UE 14-1 that the upload process was unsuccessful. In this

embodiment, the MME 16 may reconstruct the data file using the DFD (step 820).

[0124] In the UPS and VPS methods, once the owner UE 14-1 creates the DFD at the beginning of the upload process, it does not change the DFD during the upload process. Therefore, the serving BS 12-1 uses the same DFD file that it received in the primary steps of the upload process to check if all the pieces were received correctly or not. In the case of the DPS method, this process is a bit different. When an owner UE 14-1 uses the DPS method for the upload process, it should update the DFD during the upload process and send the final DFD to the serving BS 12-1 after sending the done message in some

embodiments. This embodiment is shown in Figure 14, which is a flow chart illustrating a process of reconstructing the data file when dynamic piece sizes may have been used according to some embodiments of the present disclosure. After sending all the pieces of the data file to the BSs 12 in the CoMP set, the owner UE 14-1 may use the message structure in Table 20 to send a done message to the BSs in the CoMP set to announce that it finished the upload of all the pieces (step 900). In this embodiment, the owner UE 14-1 also sends the final DFD to the BSs 12 in the CoMP set (step 902). One or more of the BSs 12 may send an ACK or NACK indicating that the done message was properly received or not (step 904).

[0125] The serving BS 12-1 checks the received pieces information with the DFD file to make sure that the BSs 12 of the CoMP set collectively received the pieces of the UE data file completely and correctly. As described in the previous sections, during the upload process, the non-serving BSs 12 of the CoMP set send the control information of the received pieces to the serving BS 12-1 .

Therefore, at the end of the upload process, the serving BS 12-1 has the control information of all the received pieces in some embodiments. It inserts the information of each piece into a DFDC list. After receiving the done message from the owner UE 14-1 , the serving BS 12-1 checks the DFD and DFDC together to see if their information about the pieces are the same (step 906). If the information does not match, the serving BS 12-1 sends a report (DFDC) to the owner UE 14-1 (step 908) to let it know about the pieces that have not been correctly received. The owner UE 14-1 tries to resend erroneous pieces based on what has been discussed in the previous sections (steps 910 through 914). After that, the owner UE 14-1 sends the done message to the BSs 12 of the CoMP set again (step 916). The serving BS 12-1 again checks the pieces (step 918). If these steps help the serving BS 12-1 to resolve the problem, then the serving BS sends the final DFD for the MME 16 (step 920). Otherwise, the serving BS 12-1 may cancel the whole upload process and inform the owner UE 14-1 that the upload process was unsuccessful. In this embodiment, the MME 16 may reconstruct the data file using the DFD (step 922).

[0126] The systems and methods described above in relation to Figures 1 through 14 are referred to generally as Upload User Collaboration (UUC) and are also described in co-owned International Patent Application Serial No.

PCT/IB2015/054524 filed June 15, 2015, entitled "File Transfer by Mobile User Collaboration." In some embodiments, UUC focuses on enhancing the cell-edge UE upload process by multiplexing across the uplinks of multiple users that are sufficiently close to each other to allow for D2D communication between the UEs. Performing a user data upload based on UUC exploits D2D communication with a cluster of UEs such that different pieces of a data file can be uploaded through multiple communication channels at the same time from multiple UEs within the cluster to base stations within a CoMP coordination set.

[0127] In the embodiments discussed above, the owner UE and its helper UEs are usually served by the same subset of the BSs as their coordination set. However, letting the UEs within the D2D cluster communicate with different subsets of BSs as their CoMP coordination set can result in additional throughput gains. As an example, consider the situation in which the owner UE shares some part of the data file with the helper UEs and then one of the UEs (the owner UE or the helper UE) wants to move in such a way that this movement results in the existing CoMP coordination set not being optimal for that particular UE. Allowing a different optimal subset of eNBs to be the next CoMP

coordination set may result in throughput and performance improvements in some embodiments.

[0128] In relation to the following figures, embodiments of UUC are discussed where the coordination set is not fixed. For example, the owner UE and its helper UEs can employ different CoMP coordination sets, with possibly different BSs in each CoMP coordination set. In this context, these embodiments define the notion of a Super Set (SS) that handles the upload process of different parts of a same data file by multiple UEs which are using different coordination sets.

[0129] In some embodiments, the UEs that are involved in the upload process of an owner UE might use partially the same or a completely different

coordination set of BSs. Besides UUC, other upload methods and protocols could potentially use this method to extend their functionality. This method could also be used in the download process as well.

[0130] As before, if a UE (i.e., an owner UE) in a mobile network wants to upload a data file using UUC, there is at least one UE (i.e., a helper UE) that wants to assist the owner UE with the upload process. If the owner UE and the helper UE use different BSs in their coordination set, the serving BS of the owner UE can establish an SS to support the UE's upload process. In some

embodiments, the serving BS ensures that the UEs remain coordinated during the upload process and they do not upload a piece more than once.

[0131] Some embodiments fall into either a Type I SS or a Type II SS. A Type II SS is used when the UEs (the owner UE and the helper UE) use different BSs as their serving BS and they might or might not have different non-serving BSs in their coordination sets. A Type I SS is used when the UEs have the same serving BS but they use different non-serving BSs in their coordination sets. In both embodiments, the serving BS of the owner UE establishes an SS to be able to communicate with other BSs to gather information about the upload process of the owner UE data file. This information is forwarded to the owner UE to keep the owner UE updated about the upload status of the pieces of the data file.

[0132] The notion that UEs use the same subset of the BSs as their coordination set implies that the same group of the BSs supports DL and UL communication to/from the UEs. However, this definition is not restrictive to requiring that the UEs have the same serving BS or non-serving BSs. As an example, consider Figure 15 which illustrates a case in which both UE1 and UE2 have BS1 , BS2, and BS3 in their coordination set. The serving BS of UE1 is BS1 , and the other two BSs (BS2 and BS3) are the non-serving BSs of the UE1 coordination set. Furthermore, BS2 could be the serving BS of UE2 and the other two BSs (BS1 and BS3) could be the non-serving BSs of the UE2 coordination set.

[0133] The notion that non-serving BSs of the coordination set of two UEs are not the same means that there is at least one non-serving BS in one of the coordination sets which is not a member of the other coordination set. In Figure 15, the non-serving BSs of the UE1 and UE2 are not the same, i.e., BS2 is a non-serving BS member of the UE1 coordination set, and it is not a non-serving BS member of UE2 coordination set.

[0134] In some embodiments, a group of BSs is called an SS of a specific UE if the group satisfies the following conditions:

a. An SS is comprised of at least two different coordination sets, i.e., the coordination sets have different serving BSs or a different set of non-serving BSs or both, and it inherits the coordination set characteristic.

b. The SS supports the upload process of the group of the UEs in a

D2D cluster (i.e., an owner UE and its helper UEs) that implement the transfer of the different parts of a same data file into multiple coordination sets of the BSs.

c. An SS has at least one serving BS (note that in some instantiations multiple coordination sets may use the same BS as their serving

BS). d. Among all the serving BSs of the SS, one BS is able to gather all the information regarding the uploaded pieces to the different coordination sets of the SS. This BS is called the central serving BS of the SS and typically is the serving BS of the owner UE.

e. An SS has only one central serving BS.

f. Other serving BSs of the SS are denoted non-central serving BSs of the SS.

g. The non-central serving BSs are the serving BSs of the

coordination set of at least one UE. They are responsible for controlling the upload/download process in their coordination sets and providing feedback for the central serving BS as well.

h. The non-central serving BSs feedback is a type of control message. i. The non-serving BSs of the coordination sets of an SS are simply called BS members of the SS.

j. The BS members of an SS do not need to be neighbors. k. The number of the BSs of an SS may be equal to or greater than the number of the BSs of the coordination sets that construct this SS together.

[0135] Figure 16 shows the arrangement of Figure 15 where the BS1 is the central serving BS of the SS. BS2 is a non-central serving BS of the SS since it is the serving BS of UE2. BS3 is a member of the SS, but is not a serving BS.

[0136] Considering the serving BSs of the coordination sets, two types of the SSs exist. Figures 17 through 18 illustrate the basic concepts of the different SS types more clearly. In a Type 1 SS, all of the coordination sets of the SS have the same serving BS (i.e., there is only one serving BS in the SS). This is illustrated in Figure 17 where BS1 is the serving BS of both UE1 and UE2.

Furthermore, this means that the serving BS is the central serving BS of the SS and there are no non-central serving BSs in the SS. Since the central serving BS of the SS is the serving BS of all the coordination sets that together formed the SS, it has all the information about the uploaded pieces in the different

coordination sets of the SS. [0137] In a Type 2 SS, there are at least two coordination sets which have different serving BSs. Thus there is more than one serving BS in the SS. In some embodiments, the serving BS of the owner UE will be the central serving BS of the SS and the serving BSs of the helper UEs will be the non-central serving BSs of the SS. Initially, the central serving BS of the SS has just the information of the uploaded pieces in its coordination set (for which it is the serving BS of the owner UE). However, the central serving BS of the SS needs to gather all the required information of the uploaded pieces in the different coordination sets of the SS. To do so, the non-central serving BSs (that are the serving BSs of the other coordination sets of the SS) should send the information of the uploaded pieces in their coordination set to the central serving BS as is illustrated in Figure 18.

[0138] In the context of the SS definition, the usage of coordination sets and SSs in the different scenarios that can occur when a helper UE cooperates with an owner UE is discussed below. Table 22 compares the coordination set of an owner UE and a helper UE, and it covers the different scenarios that can occur. In Table 22, if all the BSs in the coordination sets of an owner UE and its helper UE are the same, then the value of the first column is True, otherwise, it is False. If the coordination sets are partially similar (i.e., they share one or more BSs, but not all BSs), then the value of the second column is True, otherwise it is False. If the owner UE and the helper UE have the same serving BS, then the value of the third column is True, otherwise it is False. If the owner UE and the helper UE have the same non-serving BS(s), then the value of the fourth column is True, otherwise it is False. So, these four parameters can form 16 different cases. Table 22 shows all the possible cases, but some of these cases are not possible. For example, from row 9 to row 12, if all the BSs in both coordination sets are completely similar (based on the True value in the first column), then the False value for the second column is not possible. Such cases are discarded, and the valid cases are considered in more detail. The valid cases of Table 22 can be divided into three main categories: namely: a. UEs (the owner UE and its helper UEs) have the same subset of BSs as their coordination set

b. Their coordination sets are partially similar; and

c. They have different coordination sets.

Table 22: Comparison of owner UE versus helper UE coordination sets (SS: SS,

CS: coordination set, NA: not applicable [0139] This section considers two scenarios in which owner and helper UEs have same set of BSs in their coordination sets.

[0140] One case corresponds to row 16 of Table 22. In this case the same coordination set of BSs is supporting the upload of the owner and helper UEs. Considering the fact that the serving BS and the non-serving BSs of the owner UE and the helper UEs are the same, there is no need for extra coordination among the BSs and the normal single coordination set can support the upload process. In this case there is no need for an SS.

[0141] Another case corresponds to row 13 of Table 1 , in which the owner UE and the helper UEs use the same subset of BSs as their coordination set.

However, they have different serving BSs, and furthermore, their non-serving BSs are not the same as was illustrated in Figure 15. In this case, an SS Type 2 is required to support the owner UE upload process. Assume that UE1 is an owner UE and UE2 is a helper UE. Both UEs are supported by the same set of BSs including BS1 , BS2, and BS3. In this example, BS1 and BS2 are the serving BSs of the UE1 and UE2 coordination sets respectively. Therefore, pairs of (BS2, BS3) and (BS1 , BS3) are the non-serving BSs of the UE1 and UE2 coordination sets, respectively. According to this example, the UE1 SS will have two serving BSs (BS1 and BS2) and one non-serving BS (BS3). BS1 , as the serving BS of the owner UE, will be the central serving BS of the SS, and BS2 will be the non-central serving BS of the SS as was illustrated in Figure 16.

[0142] It should be noted that in the above case and similar cases, there are two levels of coordination among the BSs. The first level is based on the conventional concept of the coordination sets. For example, BS2 as the serving BS of the UE2 coordination set collaborates with non-serving BSs of the UE2 coordination set (BS1 , and BS3) to enhance UE2 performance. Based on UUC, BS2 has complete information on the pieces that UE2 uploads to its coordination set (which is constructed by BS2, BS1 , and BS3). The second level of coordination includes being members of the SS. BS2, as a non-central serving BS of the UE1 (i.e., the owner UE) SS, is responsible to send control information about the pieces uploaded by UE2 (the helper UE) to the central serving BS of the SS, which is BS1 (i.e., the serving BS of the owner UE). In these

embodiments, the responsibilities of the BSs at the first level are independent from the second level. BS2, regardless of the fact it is part of SS or not, takes care of the upload of UE2 based on the UUC mechanism.

[0143] In other cases, some of the BSs in the coordination sets of the both UEs are similar, and some of them are not. In other words, there is at least one BS in one of the coordination sets which is not a member of the other

coordination sets. Also, there is at least one BS that is common between two coordination sets. Based on the above, the following scenarios can occur regarding the coordination sets of the owner UE and its helper UE.

[0144] The first case corresponds to row 7 of Table 22, where both

coordination sets have the same serving BS and different sets of non-serving BSs. Therefore, in this case, a Type I SS is sufficient to address the UE's upload. Based on the previous sections, in this scenario there is only one central serving BS and there are no non-central serving BSs. In other words, the SS consists of a central serving BS and one or more BS members. For example, in Figure 17, BS1 is the serving BS of both UE1 and UE2 coordination sets. BS2 and BS3 are the non-serving BSs of the UE1 coordination set, and BS3 and BS4 are the non-serving BSs of the UE2 coordination set. As defined earlier, the set of non-serving BSs of two UEs coordination sets is not the same when there is at least one BS in one of the sets which is not a member of the other set (such as BS4 in this example). Finally, in this example, BS1 has the upload information of both coordination sets since it is the serving BS of both of them.

[0145] Another scenario corresponds to row 6 of Table 22. Since the coordination sets of the UEs (i.e., UE1 as the owner UE and UE2 as the helper UE) have different serving BSs, the network requires that updates concerning the uploaded pieces of the helper UE be sent to the serving BS of the owner UE. Therefore, a Type 2 SS is established to perform the second level of the coordination. For example, in Figure 18, BS2 and BS4 are the serving BSs of UE1 and UE2 respectively. Also, BS1 and BS3 are the non-serving BSs of both UEs. The central BS of the SS is BS2, and BS4 is the non-central serving BS of the SS. BS1 and BS3 are the non-serving BSs of the SS. As a result, BS4 sends the updates dedicated to the uploaded piece of the helper UE to the BS2.

[0146] Figure 19 illustrates an example of the scenario that corresponds to row 5 of Table 22 in which BS1 , BS2, and BS3 form the coordination set of UE1 , and BS3, BS4, and BS5 form the coordination set of UE2. Furthermore, BS2 and BS4 are the serving BSs of UE1 and UE2 respectively. The pairs of (BS1 , BS3) and (BS3, BS5) are the non-serving BSs of UE1 and UE2 respectively. Since the coordination sets of the UEs (the owner UE and the helper UE) have different serving BSs, a Type 2 SS is established to perform the second level of the coordination (as in the previous case). In this example, BS2 is the central serving BS of the SS, and BS4 is the non-central serving BS of the SS. Also, BS1 , BS3, and BS5 are the non-serving BSs of the SS. When UE2 (the helper UE) uploads a piece to its coordination set successfully, BS4 as the serving BS of the UE2 and as the non-central serving BS of the SS of UE1 (the owner UE), sends a message to the BS2 (the central serving BS of the SS) to notify BS2 of the successful upload of that piece.

[0147] In other embodiments, the UEs (the owner UE and the helper UE) use different sets of BSs as their coordination sets. The following scenario can occur for the owner UE and a helper UE. This scenario corresponds to the first row of Table 22 in which two coordination sets do not have any common BSs in their sets. As a result, the serving BS of the owner UE establishes a Type 2 SS (considering itself as the central serving BS of the SS) to support the data file upload from multiple sources. For example, in Figure 20, UE1 uses BS1 , BS2, and BS3 as its coordination set, whereas UE2 uses BS4 and BS5 for the same purpose. The rest of the settings are similar to the previously discussed cases. Considering Figure 20 as an example of this situation, BS2 is the central serving BS of the SS, and BS4 is the non-central serving BS of the SS. Also, BS1 , BS3, and BS5 are the non-serving BSs of the SS.

[0148] Some of the different scenarios that need to be supported by UUC to support multiple coordination set cooperation for single data file upload have been discussed. However, in some of these embodiments, changes may be needed to the messages discussed above for UUC. Also, some new messages may also be needed. In the following discussions, in all the message structures, the first field (message ID field) illustrates the type of the message and assists the receiver to understand the different fields of this message and how the receiver should deal with them. In addition, the second and the third fields of the message structure are the destination (receiver) and the source (sender) of the messages respectively. Although the name of the second and the third fields may be different in the various messages, their concept is the same. Also, the last field of the message structures (transmission counter field) shows if the received message is an initial transmission or a retransmission of an earlier message. In this case, value "1 " means that this message is an initial transmission, and value N, where N is an integer and 1 < N < 5, shows that this message, is a retransmission of a previously transmitted message. The value of the last field of the message structure shows the number of the transmissions of the same message. While these specific message structures are presented to aid in understanding, the present disclosure is not limited to only these structures. Any suitable messaging structure could also be used.

[0149] As a first example, the upload request message structure may be updated to the format in Table 23. The sender UE ID and serving BS ID are the ID of the UE that sends this upload request and its serving BS respectively. If the owner UE field and sender UE field carry the same values, it means that the owner UE is the one who has sent this message. Otherwise, the helper UE is the transmitter of this message. If the helper UE sends this upload request to the BSs of its coordination set, the data file size field represents amount of data that the helper UE wants to upload (which usually is smaller than the actual data file size). Field Name Field Type Value UPS VPS DPS

1 message ID integer 2

2 serving BS ID integer

3 sender UE ID integer

4 owner UE ID integer

5 data file name string

6 data file size double (in MB)

7 transmission counter integer

Table 23: The structure of the upload request message

[0150] If the sender of the upload request message is a helper UE and the serving BS of the helper UE is not as same as the serving BS of the owner UE, then the serving BS of the helper UE should notify the serving BS of the owner UE of the helper UE upload status. The serving BS of the helper UE uses the message structure in Table 24 to inform the serving BS of the owner UE of the status of this helper UE. In Table 24, the receiver BS ID shows the ID of the serving BS of the owner UE. The sender BS ID field represents the ID of the serving BS of the helper UE, which is the actual sender of this message. Also, the list of the non-serving BSs ID field represents the ID of the non-serving BSs of the helper UE coordination set. The helper UE ID and owner UE ID fields represent the ID of the helper UE and the owner UE respectively. The data file name reveals the name of the file that the owner UE and the helper UEs are trying to upload.

Table 24: The structure of the helper U E detected message

[0151] Upon receiving a Helper UE Detected message from other serving BSs, the serving BS of the owner UE creates an SS (considering itself as the central serving BS of the SS) to support the upload of the data file. The central serving BS sends an SS message as shown in Table 25 to the serving BS of the detected helper UE to inform it that it should start to send its information to the central serving BS. In Table 25, the non-central serving BS ID field represents the receiver BS ID, and the central serving BS ID has the ID of the sender of this message. This message includes the ID of the owner UE and the helper UE and their serving BSs as well as the data file name. Finally, this message allows the non-central BS to forward the received pieces to the MME or another network node that is receiving the upload pieces by writing 0 in the correspondence field. If this value is 1 , the non-central serving BS sends the received pieces to the central serving BS. In addition, a value of 2 for this field means that the non- serving BS should not send the received piece to any destination and it should retain the received piece.

Table 25: The structure of the SS message

[0152] The non-serving BSs of the SS send their feedback regarding the received pieces to the central serving BS by using the message structure described in Table 26. This table includes information about the received piece, the helper UE that uploaded this piece, the owner UE (owner of the data file and SS), and the serving BSs of these UEs. This message helps the central serving BS (the serving BS of the owner UE) to keep track of the upload process and provide accurate information about the uploaded pieces for the owner UE. In Table 26, the central serving BS ID field represents the receiver BS ID and the non-central serving BS ID has the ID of the sender of this message. Both the address of the first byte of the received piece field and address of the last byte of the received piece field represent the exact address of the location of the piece in the actual data file.

Table 26: The structure of the received piece report message [0153] After receiving a report about a received piece (that was uploaded by a helper UE) at the non-central serving BS coordination set, the central serving BS of the SS uses the message structure, described in Table 27, to provide a piece acknowledgement message corresponding to the received piece for the owner UE. This message informs the owner UE that a helper UE uploaded a piece of the data file successfully.

Table 27: The structure of the piece acknowledgement message

[0154] As discussed above, in some instances, a Type 1 SS (with same serving BS) is used to dynamically and optimally select more than one CoMP coordination set based on the concept of a CoMP SS. This is used when all the UEs that are participating in the upload process of a specific data file employ the same BS as their serving BS in their coordination set. In other words, the helper UE has same serving BS as the owner UE. However, the helper UE and the owner UE use a different set of BSs as their non-serving BSs in their

coordination set (like UE 1 and UE 2 in Figure 17). Table 28 shows the information of the coordination sets of the UE1 and UE2 according to Figure 17.

Tab e 28: Coordination Set (CS) information for UE1 and UE2 from Figure 17

[0155] Figure 21 illustrates an example operation when a Type 1 SS is used. The process is very similar to the general case described above in relation to Figure 2. As such, some details are not repeated. The owner UE (e.g., UE 14-1 ) starts the upload process by creating a DFD (step 1000). The owner UE then sends an upload request to the BSs of the coordination set (e.g., BS 12-1 through 12-N) (step 1002). The BSs 12 that will support the owner UE upload respond with a handshake message (step 1004). Upon receiving the handshake, the owner UE 14-1 sends the DFD message to the serving BS 12-1 (step 1006).

[0156] After that, for all pieces of the data file, the owner UE 14-1 starts to upload the piece messages to the BSs of the coordination set by sending TBs of a piece for the BSs in the CoMP set as an initial transmission or in a

retransmission phase (step 1008). In addition, the owner UE 14-1 sends the upload assistance messages to the neighbor UEs (not shown in Figure 21 ). The neighbor UEs cooperating with the owner UE 14-1 upload send back a

confirmation message. Subsequently, the owner UE 14-1 sends one or more of the pieces (based on their agreement, which was established through the previous messages) to the helper UEs (not shown in Figure 21 ), and the helper UEs assist the owner UE 14-1 by uploading these pieces on behalf of the owner UE 14-1 . If another BS receives a TB of a piece of the data file, the status of that TB is sent to the serving BS 12-1 of the owner UE 14-1 (step 1010). The serving BS 12-1 of the owner UE 14-1 may then send an ACK or NACK to the owner UE 14-1 to inform it of the status of the upload process and which helper UEs are assisting (step 1012).

[0157] To accomplish this, the helper UE needs to request the upload resources from its serving BS 12-1 (which in this scenario is the serving BS of the owner UE as well). Therefore the helper UE sends the updated upload request message (Table 23) to the serving BS. Upon receiving a message from the helper UE, the serving BS 12-1 creates an SS based on the coordination set of both the owner UE 14-1 and the helper UE as discussed above.

[0158] The remainder of the upload process closely follows the method discussed above. After correct reception of each of the pieces, the serving BS updates the DFDC and determines the transporter BS to send that piece to the MME. After uploading all the pieces, the owner UE sends the done message to the serving BS. The serving BS 12-1 then performs the final check, and if there are any errors in the uploaded pieces, it informs the owner UE. Finally, the MME reconstructs the uploaded file based on the received pieces and the DFD.

[0159] Figures 22 through 24 provide more details of a possible embodiment. Figure 22 shows that the owner UE 14-1 sends an upload assistance message to one or more helper UEs 14-2 through 14-N (step 1 100). The owner UE receives one or more confirmation messages from the one or more helper UEs (step 1 102). Then, for each of the pieces that are supposed to be sent to the helper UEs, the owner UE sends pieces to the helper UEs (step 1 104). This may be accomplished in any suitable way as discussed above such as by using D2D communication between the owner UE and the one or more helper UEs. The one or more helper UEs will send an ACK/NACK in response to the piece transmissions (step 1 106).

[0160] The helper UEs may then send an updated upload request to the serving BS (e.g., BS 12-1 ) (step 1 108) which will be acknowledged with a handshake message from the serving BS (step 1 1 10). The serving BS then establishes an SS and becomes the central serving BS of the SS. Now the helper UEs send TBs of one or more pieces for the BSs in their CoMP sets as an initial transmission or in a retransmission phase (step 1 1 12). The BSs send TB status messages to the central serving BS (step 1 1 14), and the central serving BS sends ACK/NACK messages in response (step 1 1 16).

[0161] Figure 23 illustrates the pieces being sent to a destination network node such as MME 16. The serving BS first determines which BS will be the sender BS (or transporter BS) for a particular piece as discussed in more detail above (step 1200). If needed, the serving BS asks for the non-serving BSs to send the required TBs of this piece to the transporter BS (step 1202). The BSs then send the TBs to the transporter BS (step 1204).

[0162] If the serving BS is the transporter BS, then the serving BS sends this piece to the MME or other destination network node (step 1206). If the serving BS is not the transporter BS, the serving BS asks for the transporter BS to forward the piece to the MME (step 1208). In this case, the transporter BS then sends the piece to the MME (step 1210). The serving BS may then update the DFDC if it is required (step 1212).

[0163] Figure 24 illustrates the completion of the upload process according to some embodiments. After sending all the pieces of the data file to the BSs in the CoMP set, the owner UE 14-1 may send a done message to the BSs in the CoMP set to announce that it finished the upload of all the pieces (step 1300). In this embodiment, the owner UE 14-1 also sends the final DFD to the BSs (e.g. BS 12-1 through 12-N) in the CoMP set (step 1302).

[0164] The serving BS checks the received pieces information with the DFD file to make sure that the BSs of the CoMP set collectively received the pieces of the UE data file completely and correctly. As described in the previous sections, during the upload process, the non-serving BSs of the CoMP set send the control information of the received pieces to the serving BS. Therefore, at the end of the upload process, the serving BS has the control information of all the received pieces in some embodiments. It inserts the information of each piece into a DFDC list. After receiving the done message from the owner UE, the serving BS checks the DFD and DFDC together to see if their information about the pieces is the same (step 1304). If the information does not match, the serving BS sends a report (DFDC) to the owner UE 14-1 (step 1306) to let it know about the pieces that have not been correctly received. The owner UE 14-1 tries to resend erroneous pieces based on what has been discussed in the previous sections (steps 1308). After that, the owner UE 14-1 sends the done message to the BSs of the CoMP set again (step 1310). The serving BS again checks the pieces (step 1312). If these steps are unsuccessful and there is still a difference between the DFD and the DFDC, the serving BS may cancel the whole upload process and inform the owner UE 14-1 that the upload process was unsuccessful (step 1314). Otherwise, if the DFD and the DFDC are the same, the serving BS sends an "Upload Finished" message to the owner UE 14-1 (step 1316) and sends the final DFD to the MME (step 1318). In this embodiment, the MME may reconstruct the data file using the DFD (step 1320).

[0165] In some embodiments, the helper UE and the owner UE use different BSs as their serving BS. This situation leads to creation of Type II SS for supporting the UE's upload. Figure 25 illustrates this process in detail. The upload process starts with the same steps as described above. Specifically, the owner UE 14-1 sends an upload assistance message to one or more helper UEs 14-2 through 14-N (step 1400). The owner UE 14-1 receives one or more confirmation messages from the one or more helper UEs (step 1402). Then, for each of the pieces that are supposed to be sent to the helper UEs, the owner UE 14-1 sends pieces to the helper UEs (step 1404). This may be accomplished in any suitable way or in any way discussed above such as by using D2D

communication between the owner UE 14-1 and the one or more helper UEs. The one or more helper UEs will send an ACK/NACK in response to the piece transmissions (step 1406).

[0166] However, when the helper UE sends the updated upload request to its serving BS (step 1408) which will be acknowledged with a handshake message from the serving BS (step 1410), that serving BS sends a helper UE detected message to the serving BS of the owner UE 14-1 (step 1412). Upon receiving this message, the serving BS of the owner UE 14-1 establishes a Type II SS and announces itself as the central serving BS of the SS. The central serving BS sends to the serving BS of the helper UE the SS information by use of the SS message (step 1414). At this point, the one or more serving BSs of the helper UEs are now the non-central serving BSs of the owner UE SS. When the non- central serving BSs receive a piece from the helper UEs (step 1416), they send a received piece report to the central serving BS (step 1418). The central serving BS may now send a piece acknowledgement message to the owner UE (step 1420). This process informs the owner UE of the pieces that have been uploaded already.

[0167] Notably, in some embodiments, the formation of an SS when an owner UE has more than one helper UE is not different from the scenarios when there is only one helper UE. This may be accomplished by the serving BS of the owner UE dealing with each helper UE detected message independently. In this way, it does not matter how many helper UEs will be detected by other BSs. As shown in Figure 26, UE1 is an owner UE that with the assistance of UE2 and UE3 (as the helper UEs) will upload a data file. The UE1 coordination set includes BS1 , BS2, and BS3, where BS2 is the serving BS. The UE2

coordination set consists of BS3, BS4, and BS5, where BS4 is the serving BS. The UE3 coordination set includes BS6 and BS7, where BS6 is the serving BS. When UE2 and UE3 send their upload requests to their serving BSs, their serving BSs (BS4 and BS6 respectively) send a helper UE detected message to the serving BS of the owner UE, which is BS2. Upon receiving these messages, BS2 creates an SS with the characteristics as shown in Figure 26 and it sends the SS message to the BS4 and BS6. In this way, the upload assistance can be extended to any number of helper UEs with various arrangements of shared and non-shared BSs.

[0168] In the previous discussions, the UEs are stationary and do not change their serving BS or their host cell during the upload process. This is not the case when the UE positions in the network may change one or more times over the duration of the UUC upload resulting in a change of the serving cell of a given UE. As a result, additional steps may be added to the UUC and SS coordination algorithms to accommodate the mobility of the served UEs. In some embodiments, one or more UEs may need to change their serving BS in order to maintain a communications link of sufficient quality.

[0169] Figure 27 is a flow chart illustrating a process of handing over a UE that is uploading a data file as multiple pieces, according to some embodiments of the present disclosure. A current serving network node (such as a BS 12-1 ) in a wireless communications network determines that it need perform a handover for a wireless device (such as UE 14-1 ) served by the serving network node to a new serving network node (such as a BS 12-2), where the wireless device is uploading a data file as a plurality of pieces to a destination network node (step 1500). As will be discussed in more detail below, this handover decision may be made in any way. The current serving BS then sends to the new serving BS an indication of a status of the upload of the data file (step 1502). This indication may include information in various forms and may or may not include many different pieces of information as discussed below. The current serving BS then hands over the wireless device to the new serving BS (step 1504). In this way, the upload of the data file may continue after the wireless device is handed over. According to some embodiments, this provides a handover capability when a user uses any of the methods discussed above such as the UUC algorithm. Also, this may allow the UEs to remove one or more BSs from their coordination set and add other BSs into their coordination set in order to optimize the UE throughput, or for any other reason. These embodiments also support handover for scenarios and use cases in which adaptive CoMP coordination sets (SS) are employed.

[0170] In the following examples, LTE specific terminology is used. These are used for examples and the present disclosure is not limited thereto. Additionally, some steps are described with fewer details or omitted altogether where appropriate. Figure 28 illustrates an example handover from one BS to another BS. In some LTE standards such as 3rd Generation Partnership Project, Technical Specification Group Radio Access Network, '3GPP TS 36.300', V13.0.0, June 2015, incorporated herein by reference, the serving BS (such as current serving BS 12-1 ) of the UE (such as UE 14-1 ) set the measurement thresholds according to the area restrictions. The serving BS may provide measurement control (step 1600), packet data (step 1602), and UL allocations (step 1604). Considering these thresholds, the UE 14-1 sends its measurement reports to the serving BS (step 1606).

[0171] The serving BS of the UE 14-1 uses this information to determine if the signal strength of the neighbor BSs is greater than the signal strength of the current serving BS of the UE. If so, the current serving BS 12-1 of the UE selects that BS to be the new serving BS 12-2 of the UE, and the current serving BS 12- 1 sends a handover request message to the selected serving BS 12-2 (step 1608). This message includes the necessary information to prepare the selected serving BS 12-2 for the handover process. Upon receiving the handover request, the selected serving BS 12-2 carries out an admission control process to determine if there are available resources to accept this session.

[0172] If the selected serving BS 12-2 selects to grant the resources then it sends a handover request acknowledge message to the current serving BS 12-1 (step 1610). Subsequently, the current serving BS 12-1 , the selected BSs 12-2, and the UE 14-1 perform additional steps to avoid data loss during the handover process (such as an X2 bearer establishment between the BSs to carry the user data during the handover). These steps provide the basis for handover in the LTE protocol. This may include DL allocations being sent to the UE 14-1 (step 1612) as well as an established RRC connection with the UE 14-1 that may signal the UE 14-1 to move to the selected serving BS 12-2 (step 1614).

[0173] At this point, the UE 14-1 detaches from the old cell and synchronizes to the new cell. Any buffered or in transit packets are delivered from the original serving BS 12-1 to the new, selected serving BS 12-2 so that the data can be delivered to the UE. The current serving BS 12-1 transfers the sequence number status to the selected serving BS 12-2 (step 1616) and forwards data as needed (step 1618). Some more steps may be included in this process but are omitted here for brevity.

[0174] When the hand over is complete, the selected serving BS 12-2 sends a UE context release to the original serving BS 12-1 (step 1620). At this point, the original serving BS 12-1 knows that responsibility for the UE 14-1 has been transferred to the selected serving BS and the resources that were being used for the UE may be released. In this way, a UE may be handed over from one BS to another BS.

[0175] If the UE that is being handed over is taking part in an upload as discussed above, as either the owner UE or as a helper UE, additional steps and messages may need to be added to the LTE handover process. Specific examples of such messages are provided below. However, the present disclosure is not limited thereto and any mechanism may be used to send to the new serving BS an indication of a status of the upload of the data file.

[0176] In addition to the LTE handover steps described in the previous section, additional steps and messages are included in Figure 29. The

determination to hand over a UE may be similar or the same as described above. Specifically, the current serving BS 12-1 may provide measurement control (step 1700), packet data (step 1702), and UL allocations (step 1704). Considering these thresholds, the UE 14-1 sends its measurement reports to the current serving BS 12-1 (step 1706).

[0177] The current serving BS 12-1 of the UE 14-1 uses this information to determine if the signal strength of the neighbor BSs is greater than the signal strength of the current serving BS 12-1 of the UE 14-1. If so, the current serving BS 12-1 of the UE 14-1 selects that BS to be the new serving BS 12-2 of the UE 14-1 , and the current serving BS 12-1 sends a handover request message to the selected serving BS 12-2 (step 1708). This message includes the necessary information to prepare the selected serving BS 12-2 for the handover process. Upon receiving the handover request, the selected serving BS 12-2 carries out an admission control process to determine if there are available resources to accept this session.

[0178] If the selected serving BS 12-2 selects to grant the resources, then it sends a handover request acknowledge message to the current serving BS 12-1 (step 1710). Subsequently, the current serving BS 12-1 , the selected serving BS 12-2, and the UE perform additional steps to avoid data loss during the handover process (such as an X2 bearer establishment between the BSs to carry the user data during the handover). These steps provide the basis for handover in the LTE protocol. This may include DL allocations being sent to the UE 14-1 (step 1712) as well as an established RRC connection with the UE that may signal the UE 14-1 to move to the selected serving BS 12-2 (step 1714).

[0179] At this point, the UE 14-1 detaches from the old cell and synchronizes to the new cell. Any buffered or in transit packets are delivered from the original serving BS 12-1 to the new, selected serving BS 12-2 so that the data can be delivered to the UE 14-1. The current serving BS 12-1 transfers the sequence number status to the selected serving BS 12-2 (step 1716). In addition to the previous data forwarding, the original serving BS 12-1 also updates the new serving BS 12-2 about the latest upload status of the owner UE 14-1 by sending a message such as the DFDC message and other messages (step 1718).

[0180] At this point, the new serving BS 12-2 may suspend the retransmission requests from the owner UE 14-1 and may set a timer (step 1720). In some embodiments, this allows time for data to be forwarded from one or more other BSs instead of requesting a retransmission that may not be needed. In some embodiments, this suspension will last for a predetermined time. In some embodiments, this suspension may last until an indication is received that no more updates will be sent.

[0181] When the handover is complete, the selected serving BS 12-2 sends a UE context release to the original serving BS 12-1 (step 1722). The original serving BS 12-1 may then send a message to one or more BSs that are in the coordination set or SS indicating that the serving BS of the UE has changed (step 1724). These messages may be acknowledged so that the original serving BS 12-1 knows the messages were received (step 1726).

[0182] The original serving BS 12-1 then forwards any data packets that possibly were received during the handover process to the new, selected serving BS 12-2 (step 1728). The original serving BS 12-1 sends a message indicating that it is the last update, or otherwise indicating that no additional updates will be sent (step 1730). Upon receiving this indication, the selected serving BS 12-2 may remove the retransmission request suspension (step 1732). Otherwise, as discussed above, the suspension may be removed based on the passage of a predetermined amount of time.

[0183] In the embodiments discussed above, the serving BS of the owner UE keeps track of the upload process of the owner UE by saving the related information in a corresponding DFDC structure. Upon selecting a new serving BS for the owner UE (based on the previous section), the current serving BS sends both the Data File Descriptor (DFD) and the latest version of the Handover DFDC message (shown below in Table 29) to the selected (new) serving BS. As such, the selected new serving BS is updated by the latest status of the UE upload/download process.

[0184] In this context, in all the message structures in the examples below, the first field {i.e., the message ID field) defines the type of the message which indicates the different fields of the message and the range of responses to the message. In addition, the second and the third fields of the messages define the destination (receiver) and the source (sender) of the messages respectively. Although the name of the second and the third fields may be different in the various messages, the purposes of the fields are the same. Furthermore, the last field of the message structure (the transmission counter field) is indicative of whether the received message is an initial transmission or a retransmission of an earlier message. A value of "1 " denotes that the message is an initial

transmission and value N, where N is an integer and 1 < N < 5, for example, denotes that the message is a retransmission of a previously transmitted message. Thus, the value of the last field of the messages structure is indicative of the number of the transmissions of the same message.

[0185] In Table 29, the new serving BS ID and current serving BS ID fields represent the ID of the new serving BS and current serving BS of the owner UE in order. The owner UE ID defines the ID of the owner UE of the data file. The DFD type field defines which of the UUC methods (UPS, VPS or DPS) is employed by the owner UE to divide the data file into the pieces. The data file name and data file size fields define the name and the size of the file that the owner UE will upload. The piece length field defines the size of the pieces (this field is employed when the owner UE employs UPS or VPS). The number of the pieces field defines how many different pieces should be uploaded to complete the upload of the data file, and the number of the received pieces field defines how many pieces have been uploaded by the UEs. Note that the list of the received pieces field includes the ID of the received pieces. The corresponding address of these received pieces is saved in the address of the first byte of the received pieces and address of the last byte of the received pieces' fields.

Table 29: The structure of the handover D FDC message [0186] It should be noted that it is possible that during the handover process, after DFDC submission to the new serving BS, the current serving BS may receive information about the owner UE upload process. This missing

information in the DFDC message may cause a retransmission request by the new serving BS (because it does not know about this information). Therefore, the next serving BS suspends the retransmission process. In addition to sending the updates to the selected serving BS, the current serving BS must also inform the other BSs that are involved in the UE upload/download process about the handover changes. These BSs are part of the UEs coordination sets. The current serving BS uses the serving BS changed message (Table 30) to update other non-serving BSs regarding the serving BS change. The receiver BS ID represents the ID of the destination BS. The next serving BS ID and the owner UE ID fields define the ID of the next serving BS of the owner UE and the ID of owner UE respectively. The remaining fields were previously discussed above.

[0187] Note that in some embodiments, the previous serving BS of the owner UE accepts the messages regarding the owner UE upload process until it receives a BS changes confirmed message from all the BSs that it has sent them the serving BS changed message or until the end of a specific time interval. Table 31 shows the structure of the BS changes confirmed message. The previous serving BS ID field in Table 31 has the same value as the current serving BS ID field in Table 30. Also, sender BS ID reveals the ID of the sender of this message, which is equal to the value of the receiver BS ID field in Table 30. The remaining fields were discussed in the previous sections.

able 31 : The structure of the BS Changes Confirmed message

[0188] As discussed above, the previous serving BS of the owner UE may receive packets regarding the upload process of the owner UE even after it has been replaced by another BS as the serving BS. In this situation, the previous serving BS forwards all the received handover context information to the new current serving BS of the owner UE by using the message structure in Table 32 (new update message). This process continues until the previous serving BS receives the BS changes confirmed messages from all the BSs that it sent a serving BS changed message to or after a specific time interval. At this point, the previous serving BS discards the received packets that are related to the upload process of this owner UE. In Table 32, the piece holder BS ID field defines which of the BSs has the complete uploaded piece. Subsequently, the new serving BS can request that the piece holder BS forward the complete uploaded piece to a new destination (i.e., such as the MME or the new serving BS). Field

Field Name Value UPS VPS DPS

Type

1 message ID integer ✓ ✓ ·

2 new serving BS ID integer ✓ ✓ · current serving BS

3 integer ✓ ✓

ID

4 owner UE ID integer ✓ ✓ ·

5 data file name integer ✓ ✓ ·

6 received piece ID integer ✓ · ·

7 piece holder BS ID integer ✓ · ·

8 retransmission boolean ✓ · · transmission

9 integer ✓

counter

Table 32: The structure of the New Update message

[0189] In addition, after receiving all the BS changes confirmed messages or after a specific time interval, the previous serving BS sends the last update message (Table 33) to the new serving BS. By receiving this message, the new serving BS removes the suspension on the retransmission request process.

Field

Field Name Value UPS VPS DPS

Type

1 message ID integer ✓ ✓ ·

2 serving BS ID integer ✓ ✓ · previous serving BS

3 integer ✓ ✓

ID

4 owner UE ID integer ✓ ✓ ·

5 data file name integer ✓

6 retransmission boolean ✓ · · transmission

7 integer ✓

counter

Table 33: The structure of the Last Update message

[0190] Additional messages and steps may be needed when an SS is used. Using an SS allows the owner UE and its helper UEs to partially use the same or completely different subset of BSs as their CoMP coordination sets as well as using the same subset of the BSs for their coordination set. Therefore, the UEs that are trying to upload different parts of a same data file (such as an owner UE and its helper UEs) are eligible to communicate with different subsets of the BSs as their coordination set. In the SS embodiments discussed above, the use of coordination sets and an SS can occur in different scenarios when a helper UE cooperates with an owner UE in the upload process. In this context, six valid cases have been defined that should be considered. These six modes can be categorized into three main groups as follows (A, B, C):

[0191] A. The UEs use the same subset of the BSs for their CoMP

coordination set:

1 . They have the same serving BS and same non serving BSs. (A1 )

2. They have a different serving BS and different non-serving BSs.(A2)

[0192] B. The UEs use partially same subset of the BSs as their CoMP coordination set:

3. They have same serving BSs and different non-serving BSs. (B3) 4. They have different serving BSs and the same non-serving BSs. (B4)

5. They have a different serving BS and different non-serving BSs. (B5)

[0193] C. The UEs use different subset of the BSs as their coordination set:

6. They have a different serving BS and different non-serving BSs. (C6)

[0194] The first mode (A1 ) does not require an SS, and a single CoMP coordination set is sufficient to address the upload process of multiple UEs. In the remainder of five modes (from A2 to C6), the notion of an SS is employed to handle the multiple CoMP coordination set cooperation.

[0195] For scenarios is which an owner UE and its helper UE that are uploading different pieces of a same data file, the possible CoMP coordination set or SS structure that will be employed is one of the above defined modes A1 ,

A2, B3, B4, B5 or C6. If one or more of the UEs is mobile during the UUC process, one of several events can occur:

(i) loss of a connection with a BS;

(ii) establishment of a connection with a new BS;

(iii) change of the serving BS with a non-serving BS; and

(iv) change of the non-serving BS with a serving BS.

[0196] As a result, the UE movement can lead to changing the current mode of the coordination set or the SS structure into another mode, and at the same time, it may lead to a handover process. Table 34 defines the mode changes possible in the SS relationship due to UE movements. Note that the table only defines those mode changes that are possible with a single UE movement. This embodiment defines the steps in the handover process when converting from one SS mode to another.

A1 A2 B3 B4 B5 C6

A1

A2

B3

B4

B5

C6

Table 34: Possible mode changes between di ferent structure of the BSs that support UEs upload

[0197] As used in the following discussion, the definitions below apply. UE movement or mobility is defined as meaning either the owner UE movement or the helper UE movement. Therefore, this phrase applies to both categories of UE movement. Furthermore, although specific examples are provided to discuss each of the possible types of the SS mode changes, different examples for the same types of changes exist. Finally, the UE movement can have an effect on the SS structure. Based on the type of this effect, different steps of the embodiment are required to be performed. Table 35 defines the steps required to deal with different types of changes in the SS configuration, according to some embodiments. Based on the type of changes, the method of the embodiment can determine which of the mentioned actions in Table 35 are required as well as the required messages structure for each of these steps.

Type Field

UE movement Changing the central serving BS (C-S-BS) of the SS effect

Required action Handover at SS level

I

Description The current C-S-BS (which is the current serving BS of the owner UE) is will change. Therefore, the current C-S-BS needs to perform the following steps: 1. It receives context information of the new central serving BS of the SS (from the owner UE).

2. It sends the context information of the SS to the new C-S-BS.

3. It sends the context information of the received pieces to the new C-S-BS.

4. It updates other the BSs with respect to the changing C-S-BS event.

UE movement Changing of one of the non-central serving BSs (non- effect C-S-BS) of the SS

Required action Handover at coordination set level

Description A non-C-S-BS of the SS (which is the current serving

BS of the coordination set of one of the helper UEs) is going to change, then the current serving BS of the coordination set of the helper UE needs to perform the following steps:

1. It receives context information about the new serving BS of the coordination set (from the helper UE).

2. It sends the context information of the coordination set to the new serving BS of the coordination set of the helper UE.

3. It sends the context information of the received pieces to the new serving BS of the coordination set of the helper UE.

UE movement Changing of one of the non-serving BSs of one of the effect UEs

Required action An update

Description The non-serving BS is a member of the coordination set of a UE. The serving BS of that coordination set needs to perform the following steps:

1. It receives the context information with respect to this event from the UE.

2. It informs the central serving BS of the SS of this change.

Table 35: UE mobility impacts on the configuration of the SS

[0198] As noted in Table 34, a UE movement can change the owner UE and its helper UE coordination set (mode A1 ) to an SS with mode A2 and vice versa. Figure 30 illustrates how this conversion can occur. In this example, the movement of UE2 converts the configuration of its coordination set with mode A1 into the SS with mode A2. As seen in this figure, both of the UEs use the same subset of the BSs as their coordination set. In this example, the initial state of the UEs and the BSs is illustrated by the right side of the Figure 30 (mode A2). The UE2 movement to a new position as illustrated by the left side of Figure 30 converts the coordination set structure to mode A1 . Note that this mode change is a bidirectional relationship.

[0199] A UE movement can also convert the owner UE and its helper UE coordination set (mode A1 ) to an SS with mode A3 and vice versa. Figure 31 illustrates how the movement of UE2 converts the configuration of its

coordination set from mode A1 into the SS with mode B3. As seen in this figure, both of the UEs use the same subset of the BSs for their coordination set.

[0200] An SS in mode A2 can convert to an SS with mode B5 and vice versa. In Figure 32, both UEs use same set of BSs for their coordination set. In this example, UE2 transitions its position as depicted in Figure 32. This movement disconnects the communication channel between UE2 and the BS1 . As a result, it causes a change in the UE2 coordination set (BS1 is not part of the

coordination set of the UE2 anymore) and it changes the SS structure from mode A2 to mode B3.

[0201] As an additional example, assume that the initial position of UE2 is as illustrated in right side of Figure 32 and UE2 transitions to a new position as illustrated in left side of Figure 32. Establishing a connection between UE2 and BS1 changes the coordination set of the UE2 and finally the SS.

[0202] A UE movement can also change the mode of SS from mode B3 to mode B5. Figure 33 illustrates such an event, in which the movement of UE2 leads to degradation in the communication channel between UE2 and BS1 and an improvement in the communication channel between UE2 and BS3. As a result, UE2 switches its serving BS from BS1 to BS3. This event also changes the configuration of the SS as well. Furthermore, note that this conversion can occur from mode B5 (as the initial mode) to mode B3 as well.

[0203] Figure 34 illustrates the steps for an SS in mode B4 that converts to an SS with mode B5 and vice versa. In the left side of Figure 34, UE2 uses BS4 as its serving BS. In this example, as UE2 moves toward BS3 the quality of its communication channel with BS3 will surpass the quality of the channel to BS4. The resulting handover of the serving BS for UE2 converts the configuration of the SS from mode B4 to the mode B5. A corresponding transition is illustrated in Figure 34 for which the serving BS of UE2 will transition from BS3 to BS4, and the SS mode will transition from mode B5 to mode B4.

[0204] Figure 35 illustrates an SS in mode B5 that converts to an SS with mode C6 and vice versa. UE2 movement results in it terminating its

communication channel with BS3, and as a result, BS3 is removed from the UE2 coordination set. This event completely separates the coordination sets of UE1 and UE2 from each other (bottom half of Figure 35) and changes the

configuration of the SS. In addition, if it is assumed that the initial condition of the UEs is as illustrated in the bottom half of Figure 35, the movement of UE2 towards BS3 will add BS3 to the coordination set of the UE2 (as in the top half of Figure 35).

[0205] Several messages are now described that could support handover with adaptive CoMP coordination {i.e., use of SS). The actions that need to be taken to update the new serving BS of the UE without the use of an SS were described above. When using an SS, the following actions may be needed. [0206] If an owner UE is required to change its serving BS (which in this example is the central serving BS of the SS), it will transmit the context information of the SS (including coordination sets and their members) to the new serving BS (new central BS of the SS). Table 35 below defines the message structure that the current serving BS employs to send the SS information to the next serving BS. The coordination set field is a list of list pointers in which each pointer indicates a list of BS IDs. The first ID belongs to the serving BS of the coordination set and the remainder of the list represents the non-serving BSs of the same coordination set.

Table 35: The structure of the Super Set Info message for handover

[0207] If a helper UE is required to change its serving BS, then the current serving BS of the helper UE will send the SS information to the new serving BS, using the message defined in Table 36, and inform the central serving BS (serving BS of the owner UE) of these changes using the message defined in Table 37. Field Name Field Type Value UPS VPS DPS

1 message ID integer

2 new serving BS ID integer

3 current serving BS ID integer

4 owner UE ID integer

5 data file name integer

6 central serving BS integer

7 retransmission boolean

8 transmission counter integer

Table 36: The structure o the handover Super Set Info message

Table 37: The structure of the Update Super Set Central BS message [0208] Figures 36 and 37 below show the flow diagram of the handover process when an SS is used and the owner UE changes its serving BS or the helper UE changes its serving BS, respectively.

[0209] In Figure 36, the owner UE 14-1 changes its serving BS. This process is similar to the ones previously discussed. Specifically, the current serving BS 12-1 may provide measurement control (step 1800), packet data (step 1802), and UL allocations (step 1804). Considering these thresholds, the UE 14-1 sends its measurement reports to the current serving BS 12-1 (step 1806). [0210] The current serving BS 12-1 of the UE uses this information to determine if the signal strength of the neighbor BSs is greater than the signal strength of the current serving BS 12-1 of the UE 14-1. If so, the current serving BS 12-1 of the UE 14-1 selects that BS to be the new serving BS 12-2 of the UE, and the current serving BS 12-1 sends a handover request message to the selected serving BS 12-2 (step 1808). In some embodiments, the UE 14-1 makes the decision to handover to a new BS. The handover request message includes the necessary information to prepare the selected BS for the handover process. Upon receiving the handover request, the selected serving BS 12-2 carries out an admission control process to determine if there are available resources to accept this session.

[0211] If the selected serving BS 12-2 selects to grant the resources then it sends a handover request acknowledgement message to the current serving BS 12-1 (step 1810). Subsequently, the current serving BS 12-1 , the selected BS 12-2, and the UE 14-1 perform additional steps to avoid data loss during the handover process (such as an X2 bearer establishment between the BSs to carry the user data during the handover). These steps provide the basis for handover in the LTE protocol. This may include DL allocations being sent to the UE 14-1 (step 1812) as well as an established RRC connection with the UE 14-1 that may signal the UE 14-1 to move to the selected serving BS 12-2 (step 1814).

[0212] At this point, the UE 14-1 detaches from the old cell and synchronizes to the new cell. Any buffered or in transit packets are delivered from the original serving BS 12-1 to the new, selected serving BS 12-2 so that the data can be delivered to the UE 14-1. The current serving BS 12-1 transfers the sequence number status to the selected serving BS 12-2 (step 1816). In addition to the previous data forwarding, the original serving BS 12-1 also updates the new serving BS 12-2 about the latest upload status of the owner UE 14-1 by sending a message such as the DFDC message and other messages (step 1818).

[0213] At this point, the new serving BS 12-2 may suspend the retransmission requests from the owner UE 14-1 and may set a timer (step 1820). In some embodiments, this allows time for data to be forwarded from one or more other BSs instead of requesting a retransmission that may not be needed. In some embodiments, this suspension will last for a predetermined time. In some embodiments, this suspension may last until an indication is received that no more updates will be sent.

[0214] When the handover is complete, the selected serving BS 12-2 sends a UE context release to the original serving BS 12-1 (step 1822). The original serving BS 12-1 may then send an SS info message to the new serving BS 12-2 of the UE 14-1 , as discussed above (step 1824). The original serving BS 12-1 may then send a message to one or more BSs that are in the coordination set or SS indicating that the serving BS of the UE has changed (step 1826). These messages may be acknowledged so that the original serving BS 12-1 knows the messages were received (step 1828).

[0215] The original serving BS 12-1 then forwards any data packets that possibly were received during the handover process to the new, selected serving BS 12-2 (step 1830). The original serving BS 12-1 sends a message indicating that it is the last update, or otherwise indicating that no additional updates will be sent (step 1832). Upon receiving this indication, the selected serving BS 12-2 may remove the retransmission request suspension (step 1834). Otherwise, as discussed above, the suspension may be removed based on the passage of a predetermined amount of time.

[0216] In Figure 37, the helper UE 14-2 changes its serving BS. This process is similar to the ones previously discussed. Specifically, the serving BS 12-1 may provide measurement control (step 1900), packet data (step 1902), and UL allocations (step 1904). Considering these thresholds, the UE 14-2 sends its measurement reports to the serving BS 12-1 (step 1906).

[0217] The serving BS 12-1 of the UE 14-2 uses this information to determine if the signal strength of the neighbor BSs is greater than the signal strength of the current serving BS 12-1 of the UE 14-2. If so, the current serving BS 12-1 of the UE 14-2 selects that BS to be the new serving BS 12-2 of the UE, and the current serving BS 12-1 sends a handover request message to the selected serving BS 12-2 (step 1908). This message includes the necessary information to prepare the selected serving BS 12-2 for the handover process. Upon receiving the handover request, the selected BS 12-2 carries out an admission control process to determine if there are available resources to accept this session.

[0218] If the selected serving BS 12-2 selects to grant the resources, then it sends a handover request acknowledgement message to the current serving BS 12-1 (step 1910). Subsequently, the current serving BS 12-1 , the selected BS 12-2, and the UE 14-2 perform additional steps to avoid data loss during the handover process (such as an X2 bearer establishment between the BSs to carry the user data during the handover). These steps provide the basis for handover in the LTE protocol. This may include DL allocations being sent to the UE 14-2 (step 1912) as well as an established RRC connection with the UE 14-2 that may signal the UE 14-2 to move to the selected serving BS 12-2 (step 1914).

[0219] At this point, the UE 14-2 detaches from the old cell and synchronizes to the new cell. Any buffered or in transit packets are delivered from the original serving BS 12-1 to the new, selected serving BS 12-2 so that the data can be delivered to the UE 14-2. The current serving BS 12-1 transfers the sequence number status to the selected serving BS 12-2 (step 1916). In addition to the previous data forwarding, the original serving BS 12-1 also updates the new serving BS 12-2 about the latest upload status of the owner UE 14-2 by sending a message such as the DFDC message and other messages (step 1918).

[0220] At this point, the new serving BS 12-2 may suspend the retransmission requests from the UE 14-2 and may set a timer (step 1920). In some

embodiments, this allows time for data to be forwarded from one or more other BSs instead of requesting a retransmission that may not be needed. In some embodiments, this suspension will last for a predetermined time. In some embodiments, this suspension may last until an indication is received that no more updates will be sent.

[0221] When the handover is complete, the selected serving BS 12-2 sends a UE context release to the original serving BS 12-1 (step 1922). The original serving BS 12-1 may then send an SS info message to the new serving BS 12-2 of the UE, as discussed above (step 1924). The original serving BS 12-1 may then send an update central-serving BS message to the new central-serving BS 12-2, as discussed above (step 1926). The original serving BS 12-1 may then send a message to one or more BSs that are in the coordination set or SS indicating that the serving BS of the UE 14-2 has changed (step 1928). These messages may be acknowledged so that the original serving BS 12-1 knows the messages were received (step 1930).

[0222] The original serving BS 12-1 then forwards any data packets that possibly were received during the handover process to the new, selected serving BS 12-2 (step 1932). The original serving BS 12-1 sends a message indicating that it is the last update, or otherwise indicating that no additional updates will be sent (step 1934). Upon receiving this indication, the selected serving BS 12-2 may remove the retransmission request suspension (step 1936). Otherwise, as discussed above, the suspension may be removed based on the passage of a predetermined amount of time.

[0223] Figure 38 is a diagram of a network node 12 according to some embodiments of the present disclosure. As used herein, this network node 12 may be a BS 12 or any other network node capable of performing the processes discussed herein. In some embodiments, the network node 12 includes circuitry containing instructions, which when executed, cause the network node 12 to implement the methods and functionality described herein. In one example, the circuitry can be in the form of processing means which may include a processor and a memory containing instructions. As illustrated, the network node 12 includes a baseband unit 28 that includes at least one processor 30 and memory 32. The baseband unit 28 also includes a network interface 34. As illustrated, the network node 12 also includes a radio unit 36 with a one or more transmitters 38, one or more receivers 40, and one or more antennas 42. In some

embodiments, the network node 12, or the functionality of the network node 12 described with respect to any one of the embodiments described herein, is implemented in software that is stored in, e.g., the memory 32 and executed by the processor 30. The network interface 34 may include one or more components (e.g., network interface card(s)) that connect the network node 12 to other systems.

[0224] In some embodiments, a computer program including instructions which, when executed by the at least one processor 30, causes the at least one processor 30 to carry out the functionality of the network node 12 according to any one of the embodiments described herein is provided. In some

embodiments, a carrier containing the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as the memory 32).

[0225] Figure 39 is a diagram of a wireless device 14 according to some embodiments of the present disclosure. As illustrated, the wireless device 14 includes at least one processor 48 and memory 50. The wireless device 14 also includes a transceiver 52 with one or more transmitters 54, one or more receivers 56, and one or more antennas 58. In some embodiments, wireless device 14, or the functionality of the wireless device 14 described with respect to any one of the embodiments described herein, is implemented in software that is stored in, e.g., the memory 50 and executed by the processor 48. The transceiver 52 uses the one or more antennas 58 to transmit and receive signals and may include one or more components that connect the wireless device 14 to other systems.

[0226] In some embodiments, a computer program including instructions which, when executed by at least one processor 48, causes the at least one processor 48 to carry out the functionality of the wireless device 14 according to any one of the embodiments described herein is provided. In some

embodiments, a carrier containing the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as the memory 50).

[0227] Figure 40 is a diagram of a network node 12 including a handover determination module 60, an upload assistance module 62, and a handover module 64 according to some embodiments of the present disclosure. The handover determination module 60, the upload assistance module 62, and the handover module 64 are each implemented in software that, when executed by a processor of the network node 12, causes the network node 12 to operate according to one of the embodiments described herein. The handover determination module 60 operates to determine and to perform a handover for a wireless device served by the network node 12, as described above with respect to the determining step 1500. The upload assistance module 62 operates to send an indication of a status of the upload of a data file as discussed above with respect to step 1502. The handover module 64 operates to hand over a wireless device as discussed above with respect to step 1504.

[0228] Figure 41 is a diagram of a network node 12 including an upload assistance module 66 and a handover module 68 according to some

embodiments of the present disclosure. The upload assistance module 66 and the handover module 68 are each implemented in software that, when executed by a processor of the network node 12, causes the network node 12 to operate according to one of the embodiments described herein. The upload assistance module 66 operates to receive an indication of a status of the upload of a data file as discussed above with respect to step 1502. The handover module 68 operates to receive a hand over of a wireless device as discussed above with respect to step 1504.

[0229] The following acronyms are used throughout this disclosure.

• 3GPP 3 ^rd Generation Partnership Project

• 3G 3rd Generation

• 4G 4th Generation

• 5G 5th Generation

• ACK Acknowledgement

• CB Coordinated Beamforming

• CC Chase Combining

• CoMP Coordinated Multi-Point

• CS Coordinated Scheduling

• D2D Device to Device • DFD Data File Descriptor

• DFDC DFD Complements

• DL Downlink

• DPS Dynamic Piece Size

• eNB evolved Node B

• HARQ Hybrid Automatic Repeat Request

• loT Internet of Things

• IR Incremental Redundancy

• JP Joint Processing

• LEE Laptop Embedded Equipment

• LME Laptop Mounted Equipment

• LTE Long Term Evolution

• LTE-A LTE-Advanced

• M2M Machine-to-Machine

• MAC Media Access Control

• MME Mobility Management Entity

• MTC Machine Type Communication

• NACK Negative Acknowledgement

• PDCP Packet Data Convergence Protocol

• PDU Protocol Data Unit

• RLC Radio Link Control

• SRS Sounding Reference Symbol

• SS Super Set

• TB Transport Block

• UE User Equipment

• UL Uplink

• UMTS Universal Mobile Telecommunications System

• UPS Uniform Piece Size

• UUC Upload User Collaboration

• VPS Variable Piece Size • WiMAX Worldwide Interoperability for Microwave Access

[0230] Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein and the claims that follow.