WO2019069124A1

WO2019069124A1 - Universal transmission protocol (utp)

Info

Publication number: WO2019069124A1
Application number: PCT/IB2017/058337
Authority: WO
Inventors: Sai Srinivas Kiran GARIMELLA; Shubham MALHOTRA; Kavin Bharti MITTAL
Original assignee: Hike Private Limited; Motiveprime Consumer Electronics Private Limited
Priority date: 2017-10-05
Filing date: 2017-12-22
Publication date: 2019-04-11

Abstract

A system and method for UTP based communication has been described. A plurality of application data segments of an application using USSD session. The plurality of application data segments is converted from a text format to original application data format to obtain the application data. The application data is displayed at a user interface of an application requesting the application data.

Description

UNIVERSAL TRANSMISSION PROTOCOL (UTP)

TECHNICAL FIELD

[1] The present disclosure relates to offline data communication. More particularly, the present disclosure relates to UTP for handling offline data communication.

BACKGROUND

[2] In telecommunications industry, Unstructured Supplementary Service Data (USSD) as an option to initiate a communication with a mobile phone has become extremely popular. The USSD channel provides a simple menu using a real-time and session based connection. The connection allows a two-way exchange of data thereby making it interactive and easy to use as the user is required to key-in few characters to send a response via USSD. Moreover, communication via USSD is usually not chargeable.

[3] However USSD has several limitations including:

a) the USSD have a telco assigned maximum limit of 160 characters that may be transferred; b) USSD only allows transferring data in text format and does not support transfer of data in other formats, for example binary arbitrary data;

c) USSD data (menu and user selections) are delivered as a popup on the user interface of the mobile phone which is extremely undesirable compared to the delivery of data at in-app Ul when the user is online, i.e., connected to the internet;

d) One of the other issue with USSD is that any ongoing transmission of data segments is dropped when the underlying session closes. An underlying session may close due to several reasons. For example, USSD may have a limit of n data segments, which includes n/2 received data segments and n/2 transmitted data segments, during a session. After the n^th data segment is send, the connection is suspended and can be resumed after some time. To avoid this, the session may be closed on any message between 1 and (n-1) message by sending a close message. After sending the close message all incoming and outgoing transmissions are cleared. Due to this limitation, any ongoing transmission needs to be resend and a message larger than n segments cannot be transmitted by the USSD.

[4] Therefore, using USSD may not be desirable when a user wants to large data set in any non-text format.

SUMMARY

[5] This section is intended to introduce certain embodiments and aspects of the present disclosure in a simplified form that are further described below in the detailed description. This summary is not intended to identify the key features or the scope of the claimed subject matter.

[6] Embodiments of the present invention may relate to a method of data communication using UTP. The method comprising receiving a plurality of application data segments of an application data via a USSD session. Converting the plurality of application data segments from a text format to original application data format to obtain the application data. Finally, the application data is displayed at a user interface (Ul) of an application requesting the application data.

[7] Embodiments of the present invention may also relate to a portable electronic device

that receive a plurality of application data segments of an application data via a USSD session. The plurality of application data segments are converted from a text format to original application data format to obtain the application data. Finally, the application data is displayed at a user interface (Ul) of an application requesting the application data. BRIEF DESCRIPTION OF FIGURES

[8] FIG. 1 is a block diagram illustrating a system for UTP based communication, according to an embodiment;

[9] FIG. 2 is a line diagram illustrating transmission of different packets during a UTP communication, according to an embodiment;

[10] FIG. 3 is a flow diagram illustrating a process to transmit and receive data between an application at a portable electronic device and an offline or online communication module, according to an embodiment;

[11] FIG. 4 is an exemplary embodiment illustrating a UTP based data communication between two portable electronic devices, according to an embodiment.

DETAILED DESCRIPTION [12] Embodiments of the present disclosure are explained in detail below with reference to the various figures. In the following description, numerous specific details are set forth to provide an understanding of the embodiments and examples. However, those of ordinary skill in the art will recognize a number of equivalent variations of the various features provided in the description. Furthermore, the embodiments and examples may be used together in various combinations.

[13] Embodiments of the present disclosure are directed to a system and a method for

UTP based data communication using USSD. FIG. 1 is a block diagram illustrating a system 100 for UTP based communication, according to an embodiment. Universal transfer protocol (UTP) is a new transfer protocol that allows transfer of data in any format, including arbitrary binary data, between two nodes. In one embodiment, the UTP allows transfer of any data, including arbitrary binary data, between two nodes using USSD as a transport means. The UTP may allow transfer of data when the node/s are offline, i.e., not connected to a data network or a Wi-Fi. In one embodiment, the node may be a redistribution point or a communication endpoint that supports UTP based data transfer between the nodes. The nodes may include any electronic instrument. For example, the electronic instrument may include a Point of Sale (PoS) terminal or a portable electronic device 102 that can send and receive data to and from a data store, for example, an offline communication module 104. A portable electronic device 102 may include a mobile phone, smartphone, or a wearable device. An offline communication module 104 may include a data server that manages reception and transfer of data to the portable electronic device.

[14] The UTP protocol may have several properties including:

a) UTP does not follow a request-response model, i.e., a request may or may not result a response. For example, when pushing analytical data from an application it is not necessary to receive a response; and

b) UTP ensures delivery of data segments and provides a failure message in case a data segment is not delivered.

[15] UTP defines several packets to establish communication between two nodes and maintain a session. These packets include:

^"SYINT: This packet indicates a new USSD connection/session between the nodes. When this packet is received by a node then: a) session state is reset to open; b) any ongoing data segment transmission is cleared; and c) data segments that are currently being transmitted are marked for retransmission.

^"ACK^": An acknowledgment message is sent to a remote node after a node has received a data segment. ^"MM^": Message meta packet. This packet indicates beginning of a new data. This packet contains a unique data ID, length of the data, its source and destination node.

"DAT^": Data packet contains the data segments.

^"ERR^": Error packet. Sent by either node to indicate an error in protocol.

"CLS^": Close packet is sent by either node to indicate that the current session can be closed. On receiving this packet, the node will clear the resources taken up by this session and close the connection.

'CAN^': Cancel transmission packet is sent by the node which is sending data segments to cancel it. On receiving this packet node will clear up the resources allocated for the transmission.

[16] As shown in FIG. 1, the portable electronic device 102 and the offline communication module 104 include a UTP modules 106 and 108, respectively, that manages UTP based data transmission between the portable electronic device 102 and the offline communication module 104. The UTP modules 106 and 108 at the portable electronic device 102 and the offline communication module 104, respectively, includes four layers, i.e., application layers 110 and 112, respectively, the transmission layers 114 and 116, respectively, the protocol layers 118 and 120, respectively, and the USSD- based transport layers 122 and 124, respectively. The application layers 110 and 112 are defined to manage communication between offline communication module 104 and applications (apps) running on the portable electronic device 102. The application layer 110 at the portable electronic device 102 initiates a request for receiving an application data from the portable electronic device 102. The request may include the registered mobile number, the application (app) identity of the application requesting the data, and the request for data. For example, when the application is a messaging application then the request for application data may include a request to send and/receive messages at the messaging application, the messaging application id, and the mobile number of the portable electronic device that send the request.

[17] In one embodiment, the application layer 110 ensures that the application data requested at the portable electronic device 102 is displayed at the User Interface (Ul) of the application requesting the application data. The application layer 110 ensures that the requested data, for example data related to an application, is displayed at the application requesting the data such that the application experience when the portable electronic device is offline is same as when the portable electronic device is online. The application layer 110 ensures that the application data is displayed as an in-app Ul, and not as a popup like in current USSD based apps, which has the same user experience as when the application is accessed online. In one embodiment, multiple applications may use the application layer 112 to send and/or receive requested data from the offline communication module 104.

[18] In one embodiment, the application layer 112 at the offline communication module

104 generates a unique transmission identity (id) and sends it to the application that requested the data. The id is then used to track the progress and state of transmission by the offline communication module 104 and the app executing at the portable electronic device 102.

[19] The UTP modules 106 and 108 at the portable electronic device 102 and the offline communication module 104, respectively, also includes transmission layers 114 and 116, respectively, that handles assembling/disassembling, multiplexing, compression/decompression, and encryption/decryption of transmissions. The transmission layers 114 and 116 also provides transmission progress and state to the application layers 110 and 112, respectively, that communicates it to the respective application. [20] The application layers 110 and 112 transmits the application data, which may include an application data request at the portable electronic device 102 or the requested application data at the offline communication module 104, to transmission layers 114 and 116, respectively, included in the UTP modules 106 and 108, respectively. In one embodiment, the application data is a random binary data that may be understood at both the UTP nodes, for example, a portable electronic device 102 and the offline communication module 104.

[21] The transmission layers 114 and 116 may either be receiving a requested application data, for example at the portable electronic device 102, or may be forwarding a requested data, for example from the offline communication module 104. In case the transmission layers 114 and 116 are forwarding the requested data, the transmission layer compress, encrypts, and breaks the application data into application data segments when the requested application data is received at the transmission layers 114 and 116. An application data segment is a portion of the application data. The application data is broken into application data segments of smaller size as USSD, used by UTP for data transfer, has a limit on the data size that may be transmitted. The length of segment is selected so that it may be transmitted using USSD. In one embodiment, an application data segment may be further broken into several application data packets, and the USSD may transfer one of these application data packets. In one embodiment, the transmission layer 114 at the portable electronic device 102 combines the different data packets received at the protocol layer 118 to obtain the application data.

[22] The transmission layer 114 at the portable electronic device 102 analyzes and process the received application data packet. For example, when a MM (message meta packet) is received then the transmission layer 114 sends this information to the application using the application layer 110. The application may decide to accept or reject this message. In case the application rejects this message then a CAN packet is sent from the portable electronic device 102 to the offline communication module 104. In case the app accepts the transmission then transmission manager adds the MM packet to the partial transmission list. The partial transmission list collects the application data segments of the application data until all the application data segments of the application data are received from the offline communication module 104.

[23] In case a DAT packet is received then the transmission layers 114 or 116 adds data part of packet to the pending partial transmission and reports the progress to the application layer 110 that is reported to the app. After all the DAT packets of a requested application data is received then the transmission layer 114 decrypts, decompress, and sends the transmission to application using application layers 110 and 112.

[24] In case a CAN packet is received then the transmission layers 114 and 116 removes partial transmission from incoming transmission list and reports the cancellation to apps using the application layers 110 and 112.

[25] Further, the UTP modules 106 and 108 at the portable electronic device 102 and the offline communication module 104 also include protocol layers 118 and 120 that is responsible for creation, management, and recovery of UTP sessions. In one embodiment, the protocol layers 118 and 120 encodes an application data segment received from transmission layers 114 and 116 in an original application data format, for example binary format, received from the transmission layers 114 and 116 to text format or decodes application data segment received from transmission layers 114 and 116 in a text format to the original application data format. In one embodiment, a binary-to-text converting algorithm, for example, a 'Base 64' algorithm may be used to convert the application data segments to text format. The application data segments are converted to text format as USSD transfers data in text format. [26] In case the protocol layer 120 is receiving an application data, for example at the offline communication module 106, then the transmission layer 116 may send a notification to the protocol layer 120 indicating availability of an outgoing session. The protocol layer 120 checks whether a USSD session is already open between the offline communication module 104 and the portable electronic device 102. In case a USSD session is not already open then the protocol layer 120 initiates a new USSD session by auto-dialing a USSD code or number to initiate a session between the offline communication module 104 and the portable electronic device 102. In one embodiment, the USSD code also encodes different information, including client version, service identity, etc. Encoding this additional information allows the offline communication module 104 to support multiple protocol versions and obtain the client, for example the portable electronic device 102, information before opening the USSD session. The protocol layer 120 then waits for arrival of a SYN packet, from the offline communication module 104 with which the USSD session is established. On arrival of SYN packet, protocol layer 118 configures itself using the configuration information from the SYN packet and sends client SYN packet to offline communication module 104. After this the session is considered to be open.

[27] The protocol layer 120 then requests queued outgoing packets from the transmission layer 116 and creates a segment using multiple/single packet(s). This segment is then encoded to application data segments in text format using Base 64 or any other encoding mechanism and the application data segments in text format is sent to the portable electronic device 102. The protocol layer 120 then awaits an acknowledgment about delivery of the USSD message and after receiving the acknowledgement generates and transmits the next segment. In case an acknowledgment is not received the protocol layer 120 will resend the same segment after a certain timeout. This process continues until all the application data segments of the application data are delivered. In case USSD session disconnects for any reason before all outgoing segments are delivered then the USSD session is reopened and the transmission is resumed from the last delivered data packet.

[28] In case the protocol layer 118 is at the node receiving application data, for example at the portable electronic device 102, then the protocol layer 118 waits for incoming segments. On arrival of new segment the session manager performs validity checks on the segment. When the application data segment is valid and no errors are detected by the protocol layer 118 then the protocol layer sends acknowledgment to the other node, for example the offline communication module 104, extracts packets from application data segment and passes the application data segments to transmission layer 114 for further processing. In case an error is detected then the protocol layer 118 sends an ERR packet to the other node, for example the offline communication module 104. If ERR packet delivery fails then session is closed and reopened in order to correct the order.

[29] Finally, the UTP modules 106 and 108 include USSD based transport layers 122 and

124, respectively, that analyzes incoming messages and forwards it to protocol layers 118 and 120, respectively, when the received application data segments have UTP application data segments. The USSD based transport layers 122 and 124 also identifies SYN packet based on the special sequence of characters at beginning of a SYN packet. Information such as version and encoder identifier included in the SYN packet is provided to the transmission layers 114 and 116 to decode an encoded application data segment. Data part of SYN packet is used to configure session parameters and identify server state.

[30] The established USSD session allows sending/receiving 124 application data segments over a USSD session. As UTP, unlike USSD, has no limitation on the number of characters that may be transmitted and/or the type of data that may be transmitted, data of any data type corresponding to the original data type of the application, for example random binary data, and of any size may be transmitted using UTP. Further, the UTP ensures that the user experience of the displayed application data, when the portable electronic device 102 is offline, is same as the online user experience.

[31] In one embodiment, UTP also addresses the data size limit issue when sending application data segments using USSD. When transferring an application data segment, UTP adds a binary character to an application data segment before transmitting the application data segment. In every session, the first application data segment may be provided a number '0' and then this number alternates between and '0' for subsequent application data segments. This number sequence is added based on the principle that only one application data segment may be lost in one direction. The nodes, for example, the portable electronic device 102 and the offline management module 104, are provided with a message sequence managers 126 and 128, respectively, that stores and tracks the sequence number. Further, the SYN message does not include a sequence number as the SYN message is being sent to establish a session. In case of SYN message two bits are added to the SYN message, where the first bit is set depending on the bit value of the previous data segment received at nodes, for example, the portable electronic device 102 and the offline management module 104. For example, when the previous data segment, which is the last data segment of the previous session, has a bit set to 1 then the bit is set. The second bit for the SYN message is set if the nodes, for example, the portable electronic device 102 and the offline management module 104, are capable of resuming a previous session.

[32] The combination of SYN message bits and the application data segments are used to send an application data of large size, which cannot be transmitted due to data size restriction on USSD, as data segments in a series of USSD sessions and detecting any error during transmission of the data segments. For example, an application data segment received after a SYN message should have a sequence 0 else the connection is closed. Similarly, if a received segment has a same sequence number same as the last received segment then an error is detected and the session is closed.

[33] When the last sent data segment contains a ^"MM^" or ^"DAT^" packet then the node examines the sequence and ensures that the data segment is delivered. Irrespective of the data segment being delivered the node may decide to re-send the same data segment (if not delivered) or construct a new data segment and send it.

[34] When the last data segment sent by the node is ^"ACK^" packet then a check is performed to determine whether the remote node is interested in resuming the session (if it has some pending data segments that are to be transmitted). If the remote node is interested in resuming the session while the node is not capable of doing it then the remote node should decline the message sending request by unsetting the second bit of sequence information in ^'SYINT packet.

[35] When a new session is opened then one of the following cases may occur:

a) If the node has no incomplete transmissions then the node sets the sequence information to no-resume state. There might be transmissions pending for delivery in the queue at this state but their delivery is not required to be resumed as they have not started.

b) If the session is broken in between a data transfer and the node wants to resume then the node should set the second bit of SYN message to indicate that the transmission is to be resumed. The first bit of the SYN message is set depending on the last data segment received.

[36] The offline communication module 104 also includes a UTP notification module 130 that manages delivery of notifications using UTP. The UTP notification module 130 includes a notification API that is exposed to a third party that wants to send notifications to several users. The API receives as input a list of users to whom the third party wants to deliver the notification and the notification payload. The API checks the list of users to determine users, i.e., the portable electronic device 102 of the user, from the list that support UTP communication. The API provides the determined users as a result to the third party. The UTP notification module 126 also track users, i.e., portable electronic device 102, that are currently active on UTP. The notification for these users may be send immediately in the ongoing session. The UTP notification module 130 also tracks the number of sessions opened or closed by a client. This data may be used to:

a) Throttle the to-be-delivered notification; and

b) Detect the users that are always offline or rarely online.

[37] The application executing on the offline communication module 104 uses an

Advanced Messaging Queueing Protocol (AMQ.P) to communicate between the application and the UTP module 108. In case of the portable electronic device 102 an Android Inter process Communication protocol is used for communication between the app executing at the portable electronic device and the UTP module 106.

[38] FIG. 2 is a flow diagram 200 illustrating transmission of different packets during a

UTP communication between portable electronic device 202 and an offline communication module 204, according to an embodiment. Initially the portable electronic device 202 sends a service provider specific code 206 via a USSD session to initiate a communication with the offline communication module 204. The service provider may include a telecommunication service provider that is providing the USSD channel for USSD based data transfer between the portable electronic device 202 and the offline communication module 204. In one embodiment, the offline communication module 204 may be sent Next SYN packet 208 is sent from the offline communication module 204 to the portable electronic device 202 to initiate a new UTP session creation. The portable electronic device 202 in reply sends a message meta (MM) packet 210 to the offline communication module 204. The offline communication module 204 then sends an ACK packet 212 to acknowledge receipt of the MM packet. Next the portable electronic device may send either a data (DAT)/MM packet 214, a data (DAT) packet may include a portion of application data request to retrieve application data from the offline communication module 204 or MM packet/s to initiate more application data requests to the offline communication module.

[39] In response, the offline communication module 204 may either send an ACK/MM packet (216) to acknowledge the receipt of data or MM packet or to initiate delivery of the requested data, in case the offline communication module 204 has a response ready for the received application data request. The portable electronic device may then send one of an ACK/DAT/MM packet 218, the MM packet may be sent to initiate a new request, a DAT packet may be sent to request application data, and an ACK packet may be sent to acknowledge receipt of application data from the offline communication module 204.

[40] Next the offline communication module 204 may send an ACK/DAT/MM packet

(220) the MM packet to initiate delivery of a new application data packet, a DAT packet including the requested application data, or an ACK packet to acknowledge receipt of an application request. The process continues until application data for all the requests have been delivered to the portable electronic device 202.

[41] FIG. 3 is a flow diagram illustrating a process 300 to transmit and receive data between an application at a portable electronic device and an offline or online communication module, according to an embodiment. In one embodiment, the offline and online communication management module are data servers that manage offline communication and online communication, respectively, between the application at the portable electronic device and the different communication modules. The online communication module initiates an application data delivery to the portable electronic device (302). The application data delivery may be initiated based on a request initiated by an app executing at the portable electronic device. [42] Next a check is then performed to determine whether the portable electronic device is online (304). In case the portable electronic device is online then the application data is delivered online (306). In case the portable electronic device is not online a check is performed to determine whether the portable electronic device is UTP-enabled (308). To determine whether the portable electronic device is UTP enabled, a check is performed to determine whether the portable electronic device is able to perform a handshake with the offline communication module. In case the portable electronic device is able to perform the handshake then the mobile number corresponding to the portable electronic device is included in the list of numbers that are UTP- complaint. In case the portable electronic device is not able to perform a handshake after three attempts then the mobile number corresponding to the portable electronic device is included in list of non-UTP compliant numbers.

[43] Next in case the portable electronic device is UTP-enabled then the application data is transferred from the offline communication module to the portable electronic device (310). The offline communication module transmits the application data to the application at the UTP- enabled portable device using UTP based data communication that uses USSD for data transfer, as explained in FIGS. 1-2.

[44] FIG. 4 is an exemplary system diagram 400 illustrating a UTP based data communication between two portable electronic devices 402 and 404, according to an embodiment. Initially a data to be delivered to another portable electronic device 404 is received at one of the portable electronic device 402. Next the message is transferred to an online communication module 406. A check is then performed to determine whether another portable electronic device 404 to which the message is to be transferred is online. In case the other portable electronic device 404 is online then the online communication module 406 transfers the message to the other portable electronic device 404. In case the other portable electronic device 404 is not online then the online communication module 406 checks whether the other portable electronic device 404 is UTP-compliant. When the other portable electronic device 404 is identified as UTP-compliant then the online communication module 406 transfers the message to the offline communication module 408. The offline communication module 408 finally transfers the message to the other portable electronic device by UTP based data communication.

[45] Embodiments and examples are described above, and those skilled in the art will be able to make various modifications to the described embodiments and examples without departing from the scope of the embodiments and examples.

[46] Although the processes illustrated and described herein include series of steps, it will be appreciated that the different embodiments of the present disclosure are not limited by the illustrated ordering of steps, as some steps may occur in different orders, some concurrently with other steps apart from that shown and described herein. In addition, not all illustrated steps may be required to implement a methodology in accordance with the present disclosure. Moreover, it will be appreciated that the processes may be implemented in association with the apparatus and systems illustrated and described herein as well as in association with other systems not illustrated.

Claims

We Claim:

1. A computer implemented method for a UTP based communication, the method comprising:

at a portable device, receiving a plurality of application data segments of an application data via a USSD session;

converting the plurality of application data segments from a text format to original application data format to obtain the application data; and

displaying the application data at a user interface (Ul) of an application requesting the application data.

2. The computer implemented method according to claim 1, further comprising:

determining whether the USSD session is established between the portable electronic device and an offline communication module; and

auto-dialing a USSD code to establish a USSD session when the USSD session is not established between the portable electronic device the offline communication module.

3. The computer implemented method according to claim 1, further comprising:

receiving a SYN packet indicating an initiation of the USSD session, wherein one of a plurality of bits in SYN packet is set to indicate that the USSD session is resuming delivery of the plurality of application data from a previous session.

4. The computer implemented method according to claim 1, further comprising:

at an offline communication module, receiving a request for the application data from the application executing at the portable electronic device;

segmenting the application to the plurality of application segments;

converting the plurality of application segments from the original application data format to text format; and forwarding the plurality of application segments to the portable electronic device via the USSD session.

5. The computer implemented method according to claim 1, further comprising:

determining whether the portable electronic device is online; and

transferring the application data segments via the USSD session when the portable electronic device is offline.

6. The computer implemented method according to claim 1, further comprising:

adding alternating binary bits to the plurality of application data segments that tracks sequence of the application data segments received at the portable electronic device.

7. A portable electronic device comprising:

a memory storing a program code; and

a processor executing the program code to:

receive a plurality of application data segments of an application data via a USSD session;

convert the plurality of application data segments from a text format to original application data format to obtain the application data; and

display the application data at a user interface (Ul) of an application requesting the application data.

8. The portable electronic device according to claim 7, further executing the program code to:

determine whether the USSD session is established between the portable electronic device and an offline communication module; and

auto-dialing the USSD code to establish a USSD session.

9. The portable electronic device according to claim 7, further executing the program code to:

receive a SYN packet indicating an initiation of the USSD session, wherein one of a plurality of bits in SYN packet is set to indicate that the USSD session is resuming delivery of the plurality of application data from a previous session,

10. The portable electronic device according to claim 7, further executing the program code to:

determining whether the portable electronic device is online; and