Sign In to Follow Application
View All Documents & Correspondence

A Method For Transferring Vehicular Bulk Data From A Source To A Destination Over A Wireless Network And A System Thereof

Abstract: ABSTRACT A Method for Transferring Vehicular Bulk Data from a Source to a Destination over a Wireless Network and a System thereof The present invention relates to method (300) and system (100) for transferring vehicular bulk data from a source to a destination over a wireless network. The method (300) has the steps of packetizing the bulk data into ‘n’ number of packets at the source; generating a first parameter (N1), dynamically determining an optimum value of the first parameter (N1), generating a second parameter (N2), dynamically determining an optimum value of the second parameter (N2), dividing the bulk data into one or more batches, such that each batch has number of packets equal to the optimum determined value of the first parameter, and transferring each batch from the source to the destination, with a wait time equal to the optimum determined value of the second parameter (N2) between every packet, reconstructing the bulk data, and completing the bulk data transfer, if the bulk data is found to be integral. Reference Figure 3

Get Free WhatsApp Updates!
Notices, Deadlines & Correspondence

Patent Information

Application #
Filing Date
29 December 2020
Publication Number
26/2022
Publication Type
INA
Invention Field
COMMUNICATION
Status
Email
kcopatents@khaitanco.com
Parent Application

Applicants

SEDEMAC Mechatronics Pvt Ltd
211, 2nd Floor, Bldg No 1, Sona Udyog Ind. Estate Parsi Panchayat Road, Andheri East Mumbai 400069 Maharashtra India

Inventors

1. Sudeep Chandrasekaran
4/119, Kurunji, A R Nair Colony, Kunnathurmedu Palakkad Kerala India 678013
2. Kunjan Gandhi
Rustomjee Regency, 3B51, JS Road, Dahisar West, Mumbai Maharashtra India 400068
3. Rajdeep Mandal
A-204, Silver Oak - 1, Beverly Park, Mira Road East, Thane Maharashtra India 401107

Specification

DESC:FIELD OF THE INVENTION
[001] The present invention relates to transferring of vehicular bulk data from a source to a destination over a wireless network.

BACKGROUND OF THE INVENTION
[002] Applications like real time vehicle geo-tracking, engine condition monitoring, remote firmware upgradation, theft prevention etc. demand remote exchange of information between servers and vehicles. For this purpose, typically a vehicle is integrated with a vehicle telematics system. The vehicle telematics system typically consists of a communication gateway powered by battery, the gateway being connected to other electronic controllers in the vehicle using a suitable vehicle local network such as Controller Area Network (CAN) bus. Further, the gateway is typically connected to a remote server via a wireless wide area network (WWAN).
[003] In such systems, the gateway is responsible for bi-directional exchange of suitable information between various controllers in the vehicle and the remote server. A typical communication gateway used in a vehicle telematics system is constrained with relatively low computational capacity and is also constrained with relatively low Random-Access Memory RAM.
[004] Many use cases like over-the-air firmware upgrades, configuration upgrades, error log exchange etc. demand the exchange of large information (i.e bulk data) between the gateway and the server. Conventionally bulk data is exchanged with the gateway by serializing the data into multiple packets such that each packet can be accommodated in the RAM and processed by the gateway at once. Due to the minimal RAM availability in the gateway, the bulk data needs to be serialized in a large number of packets.
[005] Two approaches are widely used to exchange the packets between the gateway and the server, wherein one of either the gateway or the server acts as a “source” of data transfer, and the other acts as a “destination” of data transfer. In the first approach, the bulk data destination sends a request to initiate bulk data transmission, and the source continually sends packets one after another, until all packets have been transferred. This approach has minimal bandwidth overhead and works satisfactorily when the WWAN (wireless wide area network) is consistently reliable. However, when the network is not reliable, the bulk data source will end up sending undelivered packets and this would lead to wastage of bandwidth and computation on the data source. In the second approach a request is sent by the destination to the source, for each packet. This approach allows the detection of undelivered packets and network inconsistencies early on during the data transmission activity and is suitable when the WWAN network is extremely unreliable. However, this approach has high bandwidth overhead and increases the bulk data transfer time because of the high number of transactions between the source and destination. Both mechanisms of transferring bulk data between source and destination have drawbacks resulting from the fact that the approaches do not account for the state 5 of WWAN network reliability.
[006] Thus, there is a need in the art for a method and system for transferring vehicular bulk data from a source to a destination over a wireless network which addresses at least the aforementioned problems.

SUMMARY OF THE INVENTION
[007] In one aspect, the present invention is directed towards a method for transferring vehicular bulk data from a source to a destination over a wireless network, having the steps of: sending a request from the destination to the source to initiate bulk data transfer; packetizing the bulk data into ‘n’ number of packets at the source; generating a first parameter for exchange of packets between the source and the destination, the first parameter referring to the number of packets to be sent from the source in response to a request from the destination, the first parameter ?[1,??) ; dynamically determining an optimum value of the first parameter based on network and physical parameters; generating a second parameter for exchange of packets between the source and the destination, the second parameter referring to wait time between transfer of successive packets, the second parameter ?(0,8); dynamically determining an optimum value of the second parameter based on network and physical parameters; dividing the bulk data into one or more batches, such that each batch has number of packets equal to the optimum determined value of the first parameter; transferring each batch from the source to the destination, with a wait time equal to the optimum determined value of the second parameter between every packet; determining whether all packets in a batch have been received at the destination; determining whether all batches have been received at the destination; reconstructing the bulk data from the transferred batches at the destination; determining the integrity of the transferred bulk data at the destination; and completing the bulk data transfer, if the bulk data is found to be integral.
[008] In an embodiment of the invention, the source of the bulk data transfer is a remote server, or a vehicular communication gateway connected to a set of electronic control units of a vehicle.
[009] In another embodiment of the invention, the destination of the bulk data transfer is the vehicular communication gateway if the source is the remote server. In an alternative embodiment, the destination of the bulk data transfer is the remote server if the source is the vehicular communication gateway.
[010] In a further embodiment of the invention, the steps of generating the first and the second parameter, and determining an optimum value of the first and the second parameter are performed at the vehicular communication gateway.
[011] In another embodiment of the invention, the number of packets ‘n’ is determined based upon number of bytes available in the Random Access Memory of the vehicular communication gateway, and the proportion of the volatile memory available for bulk data processing at the vehicular communication gateway.
[012] In a further embodiment of the invention, the optimum value of the first parameter is determined based upon non weighted linear averages of the network and physical parameters, and a current value of the first parameter.
[013] In a further embodiment of the invention, the optimum value of the second parameter is determined based upon non weighted linear averages of the network and physical parameters, and a current value of the second parameter.
[014] In a further embodiment of the invention, the network parameters include a received signal strength indicator and physical parameters comprise a vehicle speed and geo coordinates of the vehicle.
[015] In another aspect, the present invention is directed towards a system for transferring vehicular bulk data from a source to a destination over a wireless network. The system has a first bulk data transceiver and a first bulk data packetizer provided at the destination, and the first bulk data transceiver is configured for sending a request from the destination to the source to initiate bulk data transfer. The system further has a second bulk data transceiver and a second bulk data packetizer provided at the source and the second bulk data packetizer is configured for packetizing the bulk data into ‘n’ number of packets at the source. An adaptive parametrizer unit is configured for: generating a first parameter for exchange of packets between the source and the destination, wherein the first parameter refers to the number of packets to be sent from the source in response to a request from the destination, the first parameter ?[1,??), and dynamically determining an optimum value of the first parameter based on network and physical parameters. The adaptive parametrizer unit is further configured for generating a second parameter for exchange of packets between the source and the destination wherein the second parameter referring to wait time between transfer of successive packets, the second parameter ?(0,8) and for dynamically determining an optimum value of the second parameter based on network and physical parameters. The adaptive parametrizer unit is further configured for dividing the bulk data into one or more batches, such that each batch has number of packets equal to the optimum determined value of the first parameter. The second bulk data transceiver is configured for transferring each batch from the source to the destination, with a wait time equal to the second parameter between every packet. The first bulk data transceiver is further configured for determining whether all packets in a batch have been received at the destination, determining whether all batches have been received at the destination, reconstructing the bulk data from the transferred batches at the destination, determining the integrity of the transferred bulk data at the destination, and completing the bulk data transfer, if the bulk data is found to be integral.
[016] In an embodiment of the invention, the source of the bulk data transfer is a remote server, or a vehicular communication gateway connected to a set of electronic control units of a vehicle.
[017] In another embodiment of the invention, the destination of the bulk data transfer is the vehicular communication gateway if the source is the remote server. In an alternative embodiment, the destination of the bulk data transfer is the remote server if the source is the vehicular communication gateway.

BRIEF DESCRIPTION OF THE DRAWINGS
[018] Reference will be made to embodiments of the invention, examples of which may be illustrated in accompanying figures. These figures are intended to be illustrative, not limiting. Although the invention is generally described in context of these embodiments, it should be understood that it is not intended to limit the scope of the invention to these particular embodiments.
Figure 1 illustrates a system for transferring vehicular bulk data from a source to a destination over a wireless network, in accordance with an embodiment of the invention.
Figure 2 illustrates a vehicular communication gateway, in accordance with an embodiment of the invention.
Figure 3 illustrates a method for transferring vehicular bulk data from a source to a destination over a wireless network, in accordance with an embodiment of the invention.
Figure 4 illustrates the packetization of bulk data, in accordance with an embodiment of the invention.
Figure 5 illustrates the determination of optimum value of a first parameter, in accordance with an embodiment of the invention.
Figure 6 illustrates the determination of optimum value of a second parameter, in accordance with an embodiment of the invention.
Figure 7 illustrates the method steps performed at a second bulk data transceiver at the source of the bulk data, in accordance with an embodiment of the invention.
Figure 8 illustrates the method steps performed at a first bulk data transceiver at the destination of the bulk data, in accordance with an embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION
[019] The present invention relates to a method and system for transferring vehicular bulk data from a source to a destination over a wireless network.
[020] Figure 1 illustrates a system 100 for transferring vehicular bulk data from a source to a destination that are connected over a wireless network. The system 100 comprises a first bulk data transceiver 120 and a first bulk data packetizer 130 provided at the destination. The first bulk data transceiver 120 is configured for sending a request from the destination to the source to initiate bulk data transfer. The system 100 further comprises a second bulk data transceiver 220 and a second bulk data packetizer 230 provided at the source and the second bulk data packetizer 230 is configured for packetizing the bulk data into ‘n’ number of packets at the source. In an embodiment, the source of the bulk data transfer is a remote server 210 or a vehicular communication gateway 110 connected to a set of electronic control units 150 of a vehicle. In the exemplary embodiment illustrated in Figure 1, the destination of the bulk data transfer is the vehicular communication gateway 110 if the source is the remote server 210. In an alternative embodiment, the destination of the bulk data transfer is the remote server 210 if the source is the vehicular communication gateway 110.
[021] As illustrated in Figure 1, the vehicular communication gateway 110 is in communication with a plurality of Electronic Control Units 150 of the vehicle through a vehicle local network for controlling the vehicle. As referenced in Figure 2, the vehicular communication gateway 110 further comprises of a vehicle local network transceiver 162 configured to be in communication with a vehicle local network, a central processing unit 164, a non volatile data memory 166, a non volatile program memory 168, a random access memory (RAM) 170 and a Wireless Network Transceiver 172 configured to be in communication over the wireless network.
[022] Reference is made to Figure 1, wherein as illustrated, the server 210 comprises of a compute unit 212 that has the second bulk data transceiver 220 and the second bulk data packetizer 230, in the case in which the server 210 is the source of the bulk data transfer. The server 210 further has a network card 260 configured to be in communication over the wireless network, and a Data Storage Unit 262 for storing the packets of data in the server 210.
[023] As further illustrated in Figure 1, the system 100 comprises an adaptive parametrizer unit 140. In an embodiment as illustrated in Figure 1, the adaptive parametrizer unit 140 is provided in the vehicular communication gateway 110. The adaptive parametrizer unit 140 is configured for generating a first parameter (N1) for exchange of packets between the source and the destination wherein the first parameter (N1) refers to the number of packets to be sent from the source in response to a request from the destination. The range of the first parameter (N1) is N1 ?[1,??). The first parameter (N1) is also known as Response Delay in Packets or RDIP. The adaptive parametrizer unit 140 is further configured for dynamically determining an optimum value of the first parameter (N1) based on network and physical parameters.
[024] The adaptive parametrizer unit 140 is further configured for generating a second parameter (N2) for exchange of packets between the source and the destination, wherein the second parameter (N2) refers to wait time (WT) between transfer of successive packets. The range of the second parameter (N2) is N2 ?(0,8). The adaptive parametrizer unit 140 is further configured for dynamically determining an optimum value of the second parameter (N2) based on network and physical parameters. Thereafter, the adaptive parametrizer unit 140 is configured for dividing the bulk data into one or more batches, such that each batch has number of packets equal to the optimum determined value of the first parameter (N1).
[025] Further, the second bulk data transceiver 220 is configured for transferring each batch from the source to the destination, with a wait time equal to the second parameter (N2) between every packet. The first bulk data transceiver 120 is then configured for determining whether all packets in a batch have been received at the destination and determining whether all batches have been received at the destination. The first bulk data transceiver 110 then reconstructs the bulk data from the transferred batches at the destination and determines the integrity of the transferred bulk data at the destination. If the bulk data is found to be integral, the bulk data transfer is completed.
[026] Figure 3 illustrates a method 300 for transferring vehicular bulk data from a source to a destination over a wireless network. At step 1A, a request is sent from the destination to the source to initiate bulk data transfer. At step 1B, the bulk data is packetized into ‘n’ number of packets at the source. The packetization of bulk data is illustrated in Figure 4. In the embodiment illustrated in Figure 4, this step comprises of a processing block which is parameterized with a parameter ‘m’ and another parameter ‘ . The parameter m is the number of bytes available in the RAM 170 in the vehicular communication gateway 110. The parameter is a constant such that , and represents the proportion of the volatile memory that is available for bulk data processing at the vehicular communication gateway gateway 110, while continuing to run functions of the vehicular communication gateway 110 like remote monitoring, wireless network connectivity etc. In this embodiment, in effect, the number of packets ‘n’ is determined based upon number of bytes available in the Random Access Memory 170 of the vehicular communication gateway 110, and the proportion of the volatile memory available for bulk data processing at the vehicular communication gateway 110.
[027] As illustrated in Figure 4, the packetization block takes as input the bulk data of size M bytes and generates as output a collection of serialized packets P1 to Pn. The size of the serialized packets is typically proportional to the available space in the RAM 170. The number of packets n would be determined by Mathematically, the processing block can be represented as , where corresponds to a packet which only contains metadata, and corresponds to metadata prepended to each packet. & contains information to aid transmission flow control, packet reassembly and integrity verification at the bulk data destination node. Further, size(M)
[028] At step 1C, a first parameter (N1) is generated for exchange of packets between the source and the destination, wherein the first parameter (N1) refers to the number of packets to be sent from the source in response to a request from the destination, and the first parameter (N1) ranges as N1 ?[1,??). At step 1D, an optimum value of the first parameter N1 is dynamically determined based on network and physical parameters. In an embodiment, as illustrated in Figure 5, the optimum value of the first parameter N1 is determined based upon non weighted linear averages of the network and physical parameters, and a current value of the first parameter N1. In an embodiment, the network parameters comprise a received signal strength indicator and physical parameters comprise a vehicle speed and geo coordinates of the vehicle. As illustrated in Figure 5, the network and physical parameters like RSSI, speed of vehicle etc. are passed onto a Feature Generator 510 to derive features. The derived features are passed onto a Model Trainer 520 to derive the feature weights . The optimal value of first parameter (N1) is determined dynamically as
[029] At step 1E, a second parameter (N2) is generated for exchange of packets between the source and the destination, wherein the second parameter (N2) refers to wait time between transfer of successive packets, and the second parameter (N2) ranges as N2 ?(0,8). At step 1F, an optimum value of the second parameter (N2) is dynamically determined based on network and physical parameters. In an embodiment, as illustrated in Figure 6, the optimum value of the second parameter (N2) is determined based upon non weighted linear averages of the network and physical parameters, and a current value of the second parameter (N2). As illustrated in Figure 6, the physical parameters are passed onto a Feature generator 610 to derive the features , and the generated features are passed to a Model Trainer 620 to derive weights . The optimum value of the second parameter (N2) is derived as .
[030] In an embodiment, the method steps 1D and 1F of determining the optimum value of the first parameter (N1) and the optimum value of the second parameter (N2) are performed at the adaptive parametrizer unit 140 that is provided in the vehicular communication gateway 110.
[031] At step 1G, the bulk data is divided into one or more batches, such that each batch has number of packets equal to the optimum determined value of the first parameter (N1). At step 1H, each batch is transferred from the source to the destination, with a wait time equal to the optimum determined value of the second parameter (N2) between every packet.
[032] Further at step 1I, whether all packets in a batch have been received at the destination is determined. At step 1J, whether all batches have been received at the destination is determined. At step 1K, the bulk data is reconstructed from the transferred batches at the destination. At step 1L, the integrity of the transferred bulk data at the destination is determined. At step 1M, if the bulk data is found to be integral, the bulk data transfer is concluded/completed.
[033] As explained hereinbefore, in an embodiment, the source of the bulk data transfer is the remote server 210 or the vehicular communication gateway 110 connected to the set of electronic control units 150 of the vehicle. In an embodiment, the destination of the bulk data transfer is the vehicular communication gateway 110 if the source is the remote server 210. In an alternative embodiment, the destination of the bulk data transfer is the remote server 210 if the source is the vehicular communication gateway 110.
[034] Figure 7 illustrates an exemplary embodiment of the method steps performed at the second bulk data transceiver (BDT) 220 at the source of the bulk data. At step 7A, the second BDT 220 fetches the first parameter (N1) as RDIP and the second parameter (N2) as WT. Depending on whether the source is the server 210 or the vehicular communication gateway 110, RDIP & WT will be fetched from the destination or could be readily available. At step 7B, the second BDT 220 determines the availability of metadata Pmeta request from the destination. Pmeta typically contains information like maximum packet size, number of packets etc. If Pmeta request is available, control passes to step 7C. Otherwise, control passes to step 7A. At step 7C, the second BDT 220 sends the metadata Pmeta to the destination and control passes to step 7D. At step 7D, the second BDT 220 determines the availability of a batch request. In that, the RDIP number of packets is called a batch. If the batch request is available, the control passes to step 7E. Otherwise, step 7D is repeated. At step 7E, the second BDT 220 sends a packet to the destination and waits for WT duration. At step 7F, the second BDT 220 determines whether all packets belonging to the batch have been sent. If sent, the control passes to step 7G. Otherwise, the control passes to step 7E. At step 7G, the second BDT 220 determines whether all batches have been sent. If sent, the transfer is deemed to be complete. Otherwise, control returns back to step 7D.
[035] Figure 8 illustrates an exemplary embodiment of the method steps performed at the first bulk data transceiver (BDT) 120 at the destination of the bulk data. At step 8A, the first BDT 120 fetches the first parameter (N1) as RDIP and the second parameter (N2) as WT to be used by further steps involved in reception. Depending on whether the source is the server or the gateway, RDIP & WT needs to be fetched from the destination or could be readily available. At step 8B, the first BDT 120 sends a request to the bulk data destination to fetch the metadata Pmeta. At step 8C, the first BDT 120 determines the availability of Pmeta. If Pmeta is received, the control passes to step 8D. Otherwise, control passes to step 8A to re-fetch RDIP & WT. At step 8D, the first BDT 120 validates the received metadata, for example, by ensuring the destination has enough RAM to receive the bulk data. If metadata is valid, control passes to step 8E. Otherwise, the download is halted. At step 8E, a request is sent to the destination to fetch a new batch of data. At step 8G, the first BDT 120 determines whether a valid bulk data packet has been received. If a valid packet is received, control passes to step 8H, otherwise, control passes to step 8F to recalibrate RDIP & WT, and redetermine the availability of a valid packet. At step 8H, the first BDT 120 determines whether all packets corresponding to the batch have been received. If received, control passes to step 8I, otherwise, control passes to step 8G. At step 8I, the first BDT 120 determines whether all batches have been received. If received, the control passes to step 8J. Otherwise, control passes to step 8E to request the next batch of data. At step 8J, reconstruction of bulk data is performed. At step 8K, the first BDT 120 determines the integrity of the received bulk data. If integral, the download is deemed to be complete. Otherwise, control passes to step 8A and the first BDT 120 attempts to reperform the download.
[036] Advantageously, the present invention provides for comprehensive and adaptive solution for bulk data exchange between a server and a vehicular gateway by presenting an efficient method for the dismantling of a bulk data at the source, transmitting it reliably, and later reassembling the bulk data at the destination, over any wireless wide area network.
[037] The present invention also provides for dynamic adaptability to sustain an efficient transfer of packets, that can recalibrate itself in slow or bad network conditions. The present invention can be employed in applications of remote transfer of bulk data are firmware upgrades, vehicle debug log collection from gateways, and historical data transfers. Firmware upgrades need not necessarily be only for updating the firmware of the gateway, but also for updating the firmware of the electronic control unit or other electronic components that are connected to the gateway,
[038] While the present invention has been described with respect to certain embodiments, it will be apparent to those skilled in the art that various changes and modification may be made without departing from the scope of the invention as defined in the following claims.
,CLAIMS:WE CLAIM:
1. A method (300) for transferring vehicular bulk data from a source to a destination over a wireless network, comprising the steps of:
sending a request from the destination to the source to initiate bulk data transfer;
packetizing the bulk data into ‘n’ number of packets at the source;
generating a first parameter (N1) for exchange of packets between the source and the destination, the first parameter (N1) referring to the number of packets to be sent from the source in response to a request from the destination, the first parameter (N1) ?[1,??) ;
dynamically determining an optimum value of the first parameter (N1) based on network and physical parameters;
generating a second parameter (N2) for exchange of packets between the source and the destination, the second parameter (N2) referring to wait time between transfer of successive packets, the second parameter (N2) ?(0,8);
dynamically determining an optimum value of the second parameter (N2) based on network and physical parameters;
dividing the bulk data into one or more batches, such that each batch has number of packets equal to the optimum determined value of the first parameter (N1);
transferring each batch from the source to the destination, with a wait time equal to the optimum determined value of the second parameter (N2) between every packet;
determining whether all packets in a batch have been received at the destination;
determining whether all batches have been received at the destination;
reconstructing the bulk data from the transferred batches at the destination;
determining the integrity of the transferred bulk data at the destination; and
completing the bulk data transfer, if the bulk data is found to be integral.

2. The method (300) as claimed in claim 1, wherein the source of the bulk data transfer is a remote server (210), or a vehicular communication gateway (110) connected to a set of electronic control units (150) of a vehicle.

3. The method (300) as claimed in claim 2, wherein the destination of the bulk data transfer is the vehicular communication gateway (110) if the source is the remote server (210).

4. The method (300) as claimed in claim 2, wherein the destination of the bulk data transfer is the remote server (210) if the source is the vehicular communication gateway (110).

5. The method (300) as claimed in claim 2, wherein the steps of generating the first parameter (N1) and the second parameter (N2), and determining an optimum value of the first parameter (N1) and the second parameter (N2) are performed at the vehicular communication gateway (110).

6. The method (300) as claimed in claim 2, wherein the number of packets ‘n’ is determined based upon number of bytes available in the Random Access Memory (170) of the vehicular communication gateway (110), and the proportion of the volatile memory available for bulk data processing at the vehicular communication gateway (110).

7. The method (300) as claimed in claim 1, wherein the optimum value of the first parameter (N1) is determined based upon non weighted linear averages of the network and physical parameters, and a current value of the first parameter (N1).

8. The method (300) as claimed in claim 1, wherein the optimum value of the second parameter (N2) is determined based upon non weighted linear averages of the network and physical parameters, and a current value of the second parameter (N2).

9. The method (300) as claimed in claims 7 and 8, wherein the network parameters comprise a received signal strength indicator and physical parameters comprise a vehicle speed and geo coordinates of the vehicle.

10. A system (100) for transferring vehicular bulk data from a source to a destination over a wireless network, comprising:
a first bulk data transceiver (120) and a first bulk data packetizer (130) provided at the destination, the first bulk data transceiver (120) configured for sending a request from the destination to the source to initiate bulk data transfer;
a second bulk data transceiver (220) and a second bulk data packetizer provided (230) at the source, the second bulk data packetizer (230) configured for packetizing the bulk data into ‘n’ number of packets at the source;
an adaptive parametrizer unit (140) configured for:
generating a first parameter (N1) for exchange of packets between the source and the destination, the first parameter (N1) referring to the number of packets to be sent from the source in response to a request from the destination, the first parameter (N1) ?[1,??);
dynamically determining an optimum value of the first parameter (N1) based on network and physical parameters;
generating a second parameter (N2) for exchange of packets between the source and the destination, the second parameter (N2) referring to wait time between transfer of successive packets, the second parameter (N2) ?(0,8);
dynamically determining an optimum value of the second parameter (N2) based on network and physical parameters;
dividing the bulk data into one or more batches, such that each batch has number of packets equal to the optimum determined value of the first parameter (N1);
the second bulk data transceiver (220) being configured for transferring each batch from the source to the destination, with a wait time equal to the optimum determined value of the second parameter (N2) between every packet; and
the first bulk data transceiver (120) being further configured for:
determining whether all packets in a batch have been received at the destination;
determining whether all batches have been received at the destination;
reconstructing the bulk data from the transferred batches at the destination;
determining the integrity of the transferred bulk data at the destination; and
completing the bulk data transfer, if the bulk data is found to be integral.

11. The system (100) as claimed in claim 10, wherein the source of the bulk data transfer is a remote server (210) or a vehicular communication gateway (220) connected to a set of electronic control units (150) of a vehicle.

12. The system (100) as claimed in claim 11, wherein the destination of the bulk data transfer is the vehicular communication gateway (110) if the source is the remote server (210).

13. The system (100) as claimed in claim 11, wherein the destination of the bulk data transfer is the remote server (210) if the source is the vehicular communication gateway (110).

Dated this 28th day of December 2021
SEDEMAC Mechatronics Pvt Ltd
By their Agent & Attorney

(Nikhil Ranjan)
of Khaitan & Co
Reg No IN/PA-1471

Documents

Application Documents

# Name Date
1 202021056983-STATEMENT OF UNDERTAKING (FORM 3) [29-12-2020(online)].pdf 2020-12-29
2 202021056983-PROVISIONAL SPECIFICATION [29-12-2020(online)].pdf 2020-12-29
3 202021056983-FORM 1 [29-12-2020(online)].pdf 2020-12-29
4 202021056983-DRAWINGS [29-12-2020(online)].pdf 2020-12-29
5 202021056983-Proof of Right [08-04-2021(online)].pdf 2021-04-08
6 202021056983-FORM-26 [08-04-2021(online)].pdf 2021-04-08
7 202021056983-DRAWING [28-12-2021(online)].pdf 2021-12-28
8 202021056983-CORRESPONDENCE-OTHERS [28-12-2021(online)].pdf 2021-12-28
9 202021056983-COMPLETE SPECIFICATION [28-12-2021(online)].pdf 2021-12-28
10 Abstract1.jpg 2022-04-08
11 202021056983-FORM 18 [26-08-2022(online)].pdf 2022-08-26
12 202021056983-FER.pdf 2022-12-19
13 202021056983-FORM 4(ii) [13-06-2023(online)].pdf 2023-06-13
14 202021056983-OTHERS [26-07-2023(online)].pdf 2023-07-26
15 202021056983-FER_SER_REPLY [26-07-2023(online)].pdf 2023-07-26
16 202021056983-COMPLETE SPECIFICATION [26-07-2023(online)].pdf 2023-07-26
17 202021056983-CLAIMS [26-07-2023(online)].pdf 2023-07-26
18 202021056983- ORIGINAL UR 6(1A) FORM 1-240723.pdf 2023-09-26

Search Strategy

1 202021056983E_16-12-2022.pdf