Mobile peer-to-peer spreading of content Csaba Varga *† , Laszlo Blazovics *‡ , Hassan Charaf *§ and Frank H.P. Fitzek ¶ * Faculty of Electrical Engineering and Informatics Budapest University of Technology and Economics 1111 Budapest, Goldmann Gyorgy square 3, Hungary † Email: csaba.varga@aut.bme.hu ‡ Email: laszlo.blazovics@aut.bme.hu § Email: hassan@aut.bme.hu ¶ Mobile Device Group Aalborg University Niels Jernes Vej 12, 9220 Aalborg, Denmark E-mail: ff@es.aau.dk Abstract—In areas where Internet access is only sporadically available, or not available at all, delivering content (text, image, video, audio, application, etc.) to the people is not easy. In this paper, we introduce a novel method to spread content in such areas in a mobile peer-to-peer way. First we describe the architecture of the system along with the proposed communication protocol among the nodes. Then we discuss the advantages for the users and some scenarios where such a system may be useful. Finally, we examine the cooperation among the nodes and how users may be motivated to share their resources with others. I. I NTRODUCTION The method discussed in this paper is basically a self- organizing mobile peer-to-peer network with two kinds of logical nodes: spreaders and clients. The spreaders spread the content they have in the network, and the clients are the ones who would like to get these items from the spreaders. Physical nodes (the mobile devices) may combine these behaviors: they may act as a client to get some items from spreaders and then spread them to other nodes, who may spread them even further. II. THE ARCHITECTURE OF THE SYSTEM Figure 1 shows the architecture of the spreader network. A network consists of two types of nodes: clients and spreaders. Clients may connect to a spreader via Bluetooth or WLAN and download content from him. Spreaders may have an Internet connection (GPRS, 3G, LTE, etc.) that they can share with the clients, so that the clients may download any content from the Internet, but it is not necessary for them as they may share the content that they have in their local storage. A. The communication protocol In this section we will propose a protocol for the commu- nication between a client and a spreader. The communication can be split up to two phases: the connection establishment phase and the cooperation phase: the communication that takes place after the nodes are connected. Before nodes can connect to each other, however, they need to have a unique identifier that is independent from the physical layer, so a node will have the same ID when it communicates over either WLAN or Bluetooth. Establishing a connection over Bluetooth is different from WLAN: in the case of Bluetooth, a spreader may publish a Bluetooth service (or a range of Bluetooth services to handle more than one client) that the clients can look for and then they may connect to him if they want to. The spreader may publish the Bluetooth services according to his load, so that clients will find him as an available spreader only if he has enough free capacity for them. In the case of WLAN, each spreader may create an ad-hoc network. If a client wants to connect to a spreader, first he needs to connect to such a network. After that, he needs to send a query message to all nodes (he may simply broadcast it) to find out whether that node is a spreader or not. Each node has to send back a query response. A spreader has to respond with a positive acknowledgement that has to contain whether he can handle the new client or not, while other nodes have to respond with a negative acknowledgement which may contain the ID of the spreader who created the network. If the spreader cannot handle any more clients, or the client cannot even make direct contact with him, the client needs to look for another network. When the connection is established between the client and the spreader and the client has already identified the spreader, he may send a get status message to the spreader who has to send back a get status response message containing every information that a client may need to determine whether it is sensible staying connected to that spreader or not. For example, the message may contain the spreader’s load, a list of available contents, whether the spreader has Internet connection or not, etc., but this will be explained in detail later. When the client wishes to get some content from the spreader, he needs to send a get content message to the spreader which contains the resource identifier of the desired content (e.g. the URL of a website, or the filename of a local file). After that the spreader can send back the content in a get content response.