Case 1:16-cv-02690-AT Document 121-15 Filed 08/05/16 Page 1 of 356
`Case 1:16-cv—02690-AT Document 121-15 Filed 08/05/16 Page 1 of 356
`
`E-5
`
`E-5
`
`

`

`Case 1:16-cv-02690-AT Document 121-15 Filed 08/05/16 Page 2 of 356
`
`Figure 1: Protocol Speci&ation The linkcost table of node i lists the cost of relaying information through each neighbor k. and the number of periodic update periods that have elapsed since node i received any error-ties messages from k. The cost of a failed link is considered to be infinity. ‘lhe way in which costs are assigned to links is beyond the scope of this specification. As an example, the cost of a link could simply be the number of hops, or the addition of the latency over the link plus some constant bias. The cost of the link from i to t (i, k) is denoted byl;,. The messagere.transmission list (MRL) specifies one or more re- transmission tntries, where the mth entry consists of the following: l The sequence number of an update message l A retransmission counter that is decremented every time node i sends a new update message l An ack-required flag (denoted by &,,) that specifies whether node L has sent an ACK to the update messagerepresented by the retransmission entry l The list of updates sent in the update message lhe above information permits node i to know which updates of an update message have to be retransmitted and which neighbors should be requested to acknowledge such retransmission. Node i retransmits the list of updates in an update message when the re- transmission counter of the corresponding entry in the MRL reaches 88
`
`

`

`Case 1:16-cv-02690-AT Document 121-15 Filed 08/05/16 Page 3 of 356
`
`(Dj, < DjhHDjb > Dj,d,b = .;)) t-d EmUpd” d (4) kd.W(RTEMPi + *),br hrrlld#bubdo~n rtmhrdpla, = (j,Di,pi)hRTEMPi Figure 2: Protocol Specitication (Cont..) zero. The retransmission counter of a new entry in the MRL is set equal to a small number (e.g.. 3 or 4). 2.3 Information Exchanged among Nodes In WRP, nodes exchange routing-table update messages (which we call “update messages” for brevity) that propagate only from a node to its neighbors. An update message contains the following information: 0 The identihr of the sending node. l A sequencenumber assigned by the sending node. l An update list of zero or more updates or ACKs to update messages. An update entry specifies a destination, a distance to the destination, and a predecessor to the destination. An ACK entry specifies the source and sequence number of the update message being acknowledged. l A response list of wo or more nodes that should send an ACK to the update message. In the event that the message space is not large enough to contain all the updates and ACKs that a node wants to report, they are sent in multiple update messages. An example of this event can be the case in which a node identities a new neighbor and sends its entire routing table. The response list of the update message is used to avoid the situation in which a neighbor is asked to send multiple ACKs to the same update message, simply because some other neighbor of the node sending the update did not acknowledge. The first transmission of an update message must ask all neigh- bors to send an ACK. of course, and this is accomplished by speci- fying the “all-neighbors address,” which consists of all 1’s. When the update message reports no updates, the “empty ad- dress” is specified; this address consists of all O’s and instructs the receiving nodes not to send an ACK in return. This type of up- date message is used as a “hello message” from a node to allow its neighbors to know that they maintain co~ectivity. even if no user messages or routing-table updates are exchanged. As we explain subsequently, an ACK entry refers to an entire update message, not an update entry in an update message, in order to conserve bandwidth. 2.4 Routing-Table Updating Pigures 1 and 2 specify important proceduresofW used toupdate the routing and distance tables. A node can decide to update its routing table after either receiving an update message from a neighbor, or detecting a change in the status of,a link to a neighbor. When a node i receives an update message from its neighbor k, it processes each update and ACK entry of the update message in order. In WW, a node checks the consistency of predecessor informa- tion reported by all its neighbors each time it processes an event involving a neighbor k. In contrast, all previous path-finding algo- rithms [4,10, 141 check the consistency of the predecessor only for the neighbor associated with the input event. This unique feature of WRP accounts for its fast convergenceafter a singleresourcefailure or recovery as it eliminates more temporary looping situations than previous path-tinding algorithms. 2.4.1 Processing an Update To process an update from neighbor k regarding destination j, the distance andthepredecessor entries in the distancetableareupdated. A flag (tag) is set to specify that this entry in the table has been 89
`
`

`

`Case 1:16-cv-02690-AT Document 121-15 Filed 08/05/16 Page 4 of 356
`
`changed. A unique feature of W is that node i also determines if the path to destination j through any of its other neighbors {b E Ni lb # k} includes node k. If the path implied by the predecessor information reported by node L includes node Is. then the distance entry of that path is also updated as D$, = D&, + 0; and the predecessor is updated as pfb = pt. Thus. a node can determine whether or not an update received from k affects its other distance and routing table entries. To update its distance and predecessor for destination j (Proce- dure RTUpdate). node i chooses a neighbor p that has reported routing information such that: l The path from p to j (which is implied by the predecessor information reported by p) does not include node i a Dj, 2; DJz for any other neighbor z, and Df, 5 Diz for any other neighbor z and for every node y in the path from i toj. ‘he above means that node i chooses node p as its successor to a destination j if that neighbor appears to offer a smallestcost loop-f&e path to j and all the intermediate nodes in the path to j. When ncde i sends an update message, it updates its ack-status table and message retransmission list. For each destination j for whom there. is an update being reported, node i sets the a&required flag for all its neighbors. It also adds an entry in the update- retransmission list containing the squence number given to the update message, and starts the retransmission timer for the entry. 2.4.2 Sending New and Retransmitted Update Messages Node i sends a new update message after processing updates from its neighbors or detecting a changein a link to a neighbor. Whenever node i sends a new update message, it must 0 Decrement theretransmissioncounterof alltheexistingentries intheMRL 0 Delete the updates in existing entries in the MRL that are included in the new update message l Add an entry in the MRL for the new update message When the list of updates of a MRL entry is emptied by the transmission of a new update message, node i erases that entry from the MRL. When the retransmission counter for a retransmission entry m in the MRL expires, node i sends an update message with a new sequencenumber, an update list containing the list of updates of the retransmiss.ion entry, and a response list specifying those neighbors who did not at&nowledge the update message earlier (i.e., every neighbor k for whom al,,, = 1). The retransmission counter of existing entries in the MRL is not mod&d. Note that, based on the above retransmission strategy, there is no limit on the number of times node i would retransmit an update message tat an existing neighbor. However, as we discuss below, node i stops considering node k as its neighbor after it fails to communicate with it for some tinite amount of tune. 2.4.3 Processing an ACK An ACK entry in an update message refers to another entire update message, i.e., it acknowledges all the updates included in the update message bearing the referenced sequence number. Therefore. it is up to the node whose update message is being acknowledged to ascertain which updates are implied by a received ACK. To process an ACK from neighbor k. node i scans its MRL for the sequence number matching the sequence number specified in the ACK received. Whenever a match is found, node i resets the a&required flag for neighbor k; if ad,,, = 0 for entry m and every neighbor p of node i, the retransmission entry is deleted. This schemeobtains short ACKs at the expenseof additional processing. Node i may receive an ACK for an updatemessage whoseretrans- mission entry has been erased after sending a more recent update message for the same destinations. In that case, node i simply ignores the ACK. 2.4.4 Handling Topology and Link-Cost Changes To ensure that nodes know that they have connectivity even when they do not transmit user messages or routing-table updates for some time, every node i must periodically send an update message reporting no changes (hello messages). Acknowledgments are not required for such update messages, and they can be very short (e.g.. a byte for control information and a byte for the node identifier. since the control information can imply that there is no sequence number, update list, or response list in the message). Alternatively. a node may retransmit an update message if it is not too long. When a node k comes up. it transmits a hello message. Given that short periodic update messages are transmitted by every node, the failure of a link to a neighbor is detected by the lack of any user or update messages being received from that neighbor over a period of time qua1 to a few update-message transmission periods. Similarly, new links and nodes are detected by means update messages or user messages. When node i receives an update or user message from node 1: and node k is not lisied in its routing table or distance table, it adds the corresponding entry to its distance or routing table for destination k. An intinite distance to all destinations through node k is assumed, with the exception of node ) itself and those destinations reported in node k’s updates, if the message received from k was an update message. In addition, node i notifies node k of the information in its routing table. This information can be transmitted in one or multiple update messages that only node k needs to acknowledge. When a link fails or a link-cost changes, node i recomputes the distances and predecessors to all affected destinations, and sends to all its neighbors an update message for all destinations whose distance or predecessor change. 2.5 Example The following example illustrates the working of WRP. Consider a four node network shown in Figure 3(a). All links and n.odes are assumed to havethe same propagation delays. Linkcosts ere as indicated in the figure. Node i is the source node, j is the destination node and nodes k and b are the neighbors of node i. The arrows next 90
`
`

`

`Case 1:16-cv-02690-AT Document 121-15 Filed 08/05/16 Page 5 of 356
`
`(Od J 10 10 * 5 Is+ 1 I 1 c-u cu) K 1 (a) (W (infinity,-) (cl to links indicate the direction of updates messages and the label in parentheses gives the distance and the predecessor to destination j. Each update will be acknowledged by an ACK message from the neighbor. ACKs are not shown in the figure. The figure focuses on update messages to destination j only. When link 6, k) fails, nodes j and k send update messages to their neighboring nodes as shown in Figure 3(b). In this example. node k is forced to report an infinite distance to j as nodes b and i have reported node k as part of their path to destination j. Node b processes node k’s update and selects link (b, j) to destination j . This is becauseof step(2) of WKB which forces node b to purge any path to node j involving node k. Also, when i gets node k’s update message, i updates its distance table entry through neighbor k and checks for the possible paths to destination j through any other neighboring nodes. Thus, a node examines the available paths through its other neighboring nodes and updates the distance and the routing table entries accordingly. This results in the selection of the link (i, j) to the destination j (Figure 3(c)). When node i receives neighbor b’s update rqorting an infinite distance, node i does not have to update its routing table as it already has correct path information (Figure 3(d)). Similarly. updates sent by node k reporting a distance of 11 to destination j will not affect the path information of nodes i and b. This illustrates how stq(2) of WRP helps in the reduction of the formation of temporary loops in the explicit paths. 3 Simulation Results To gain insight into the averagecase performance of WRP in a dynamic environment, we have simulated its operation using an actor-based, discreteevent simulation languagecalled Drama [151, together with a network simulation library. Link failures and recov- eries lue simulated by sending link status message to the nodes at the end points of the appropriate links. Node failures can be treated as all links connecting to that node going down at the same time and (0.j) (2.k) (infinity,-) (b) WV) Figure 3: Example of the algorithm’s operation the link cost changes can be treated as a fink failing and recovering with a new link cost. The connectivity of a mobile node is said to be lost when a node does not hear from a mobile node for a certain period of time. The connectivity with a node will be reestablished when a node hears from a mobile node again. Mobility is mod- eled as an arbitrary set of failures and recoveries of a mobile node at random points in time. All simulations are done assuming unit propagation time and zero packet processing time at each node. If a mobile node fails when the packets are in transit, the packets are assumed to get dropped. Our goal is to compare the performance of WBB against the per- formance of routing protocols based on DBF, DUAL, and ILS. To reduce the complexity of the simulation, we have eliminated those features of the protocols that were common to all; these features concern the reliable transmission of updates over unreliable links, and the identification of neighbors. Accordingly, our simulation as- sumed that, for any of the protocols simulated. any update message sent over an operational link is received correctly, and that a node always receives enough user messages to know that it continues to have COMCCtiViQ with a neighbor. According to these assumptions, there is no need to account for acknowledgments, retransmissions of updates, or periodic transmissions of update messages. However, our intent in running the simulations was to obtain insight on the comparative overhead of different protocols that nec- essarily require the transmission of acknowledgements to update messages. We approached this problem in the following manner: Jn a packet radio network, the same update messages sent by a node is received by all its neighbors i.e., each update message is broadcast to a node’s neighbors. However, to guarantee the reliable transmission of updates, each neighbor must send an acknowledge- ment to the sender of the update. Therefore, under the assumption that no errors or collisions occur in the network channel, count- ing the number of acknowledgements received for a single update broadcast to all neighbors is much the same as counting the number 91
`
`

`

`Case 1:16-cv-02690-AT Document 121-15 Filed 08/05/16 Page 6 of 356
`
`Figure 4: ARPANET Link Failure PFA l I------ DBF l D’-lk n I 15 B F 10 0 10 20 LINK%CO"&ES 50 60 70 0 10 20 LINK?kCO"&ES xl 60 70 Figure 5: ARPANET Link Recovery of updates sent by a node to its neighbors on a point-to-point ba- sis and with no acknowledgements-the two counts differ only by one. Accordingly, we simulated the routing protocols’ operation in a packet-racbo network using the same point-to-point links typical of wireline networks. The messagecount obtained from the simula- tion runs is not the exact number of updates and acknowledgements sent by each protocol. but accurately reflects the relative differences among protocols. The resulting simplified version of WRP we simulated is called “path finding algorithm” (FYA), and is the same basic algorithm tirst described in 1131. Similarly, ILS, DBF! and DUAL correspond to the ideal case of the best protocols that could be designed based on these algorithms. To simulate the routing algorithm, a node receives a packet and responds to it by running the routing algorithm, queueing the out- going packets and processing the updates one at a time in the order in which they arrive. Drama’s internals ensure that all the packets at a given time are processed before new updates are generated. The simulations were run on several network topologies such.as Los-Nettos, Nsfnet anddrpanet. We chose these topologies to com- pare the performance of routing algorithms for well-known cases given that we cannot sample a large enough number of networks to make statistically justifiable statements about how an algorithm scales with network parameters. The los-nettos topology has 11 nodes, a diameter of 4 hops, and each node has at most four neigh- bors. The Nsfnet topology has 13 nodes, a diameter of 4 hops, and each node has at most 4 neighbors. The ARPANET topology has 57 nodes, a diameter of 8 hops, and each node has a maximum of four neighbors. For the routing algorithms under consideration, there is only one shortest path between a source and a destination pair and we do not consider null paths from a node to itself. Data are collected for a large number of topology changes to determine statistical distribution. The statistics has been collected after each failure and recovery of a link. To obtain the average figures, we make each link (or node) in the network fail and count the number of steps and messages needed for each algorithm to converge. Then the same link (node) is made to recover and the process is repeated. The average is taken over all failures and recoveries. Again, this message count is not exact, but the relative difference from one 92
`
`

`

`Case 1:16-cv-02690-AT Document 121-15 Filed 08/05/16 Page 7 of 356
`
`PFA l DBF l DUAL n ILS x 15 al 25 30 35 40 45 xl 0 5 10 15 20 25 30 35 40 45 50 NODE FAILURES NODE FAILURES Figure 6: ARPANET Node Failure PFA l DBF l D% . * ? 60 t PFA l DBF l DUAL 8 l------ PFA l DBF l DUAL n ILS x 15 2 E 10 5 0 15 20 25 30 35 40 45 50 0 5 10 15 20 25 30 35 40 45 50 NODE RECOVERIES NODE RECOVERIES Figure 7: ARPANRT Node Recovery protocol to another is accurate. 3.1 Total Response to a Single Resource Change The graphs in Figures 4 and 5 depict the number of messages exchanged and the number of steps required before PFA, DBF. DUAL, and ILS converge for every link failing and recovering in the ARPANRT topology. We focus more on the results for the ARPANRT topology, because of its larger size. Similar graphs for every node failing and recovering are given in Figures 6 and 7 re- spectively. All topology changes are performed one at a time and the algorithms were allowed to converge after each such change before the next resource change occurs. The ordinates of the graphs repre- sent the identiers of the links and the nodes while the data points show thenumber of messagesexchangedafter each resourcechange (graphs on the left hand side) and the number of steps needed for convergence (graphs on the right hand side) in each of these figures. For a single resource failure, PFA outperforms DUAL. This is because, PFA does not use an internodal coordination mechanism that spans several hops to achieve loop freedom. The performance of PFA is comparable to that of ILS after resource failures. The performance of PFA and DUAL is much better than that of ILS after resource recoveries. The counting-to-infinity problem of DBF can be clearly seen in both resource failures and resource recoveries. Given that both resource recoveries and failures will occur in the WRP, PFA offers the best total response to single topology changes, in terms of both update messages and time required to obtain correct routing tables after a topology change. 3.2 Dynamics with Mobile Nodes We incorporated mobility to the existing fixed network topology by making the links fail and come back up arbitrarily at random points in time. The network is assumed to be fully connected with poten- tial links. At startup, the topology is initialized to some well known topology such as los-nettos. Nsfnet or ARPANET. After initialim- tion. to simulate the movement of a node, a node is assumed to have failed at its previous location and reappear in its new location. Node failure is simulated as all the links associated with that node going down at the same time. The gradual movement of a node from one location to another is simulated by means of link failures and additions. When a link fails, it can be assumedthat a nodeis no 93
`
`

`

`Case 1:16-cv-02690-AT Document 121-15 Filed 08/05/16 Page 8 of 356
`
`longer in the neighborhood of its previous neighbor. The addition of a new link is viewed as a movement of a node wherein, a node reappears in the new neighborhood. The links are chosen at random from the set of all the existing links in the fi~lly connectednetwork. Selecting any particular link is equally likely. The probability of a link failing or recovering is also equally likely. We also have imposed an additional condition in our simulations that a node at any given time cannot have more man z neighbors. Here, z indicates the degree of the node. This condition is imposed in order to make sure that all the links pertaining to one node alone will not be active. This helps in simulating the mobility more closely. The average number of messages and the average message length for each of these algorithms are obtained by varying the interarrival time between two events (Figures 8-10). An event can be either a link failure or a link recovery. For the purpose of event generation, we wnsidex a fully connected topology and start off with a given initial topology. Since any random link can fail or recover at any time. our mcdel simulates mobility closely. The above results indicate that the routing algorithm of WRP outperforms all other algorithms which we have simulated, namely, DBF, DUAL and JLS. We were not able to simulate ILS algorithm for ARPANET topology due to limited resources. The statistics about the average number of messages and the average message length have been collected for all the above mentioned topologies for all the four algorithms by varying the interarrival time between events (failures and recoveries). In all cases. the average number of messages for DBF and DUAL are more than that of WRP. ‘Ihis is because. DBF suffers from counting-to-intinity problem and DUAL uses an intemeighbor co- ordination mechanism to achieve loop-freedom and this synchro- nization mechanism spans the entire diameter of the network. lLS sends maximum number of messages since the complete topology information has to be transmitted to each node every time the topol- ogy changes. The average length of each message is the highest in DUAL as compared to all other algorithms. The average message length in case of JLS is almost constant since it always sends the complete topology information. Even though we do not have simulation results for JLS in case of ARPANET topology, we can extrapolate the results from the other two network topologies and can expect similar behavior for ARPANET topology also. 4 Conclusion A new routing protocol, WRP, for a packet radio network has been presented. This protocol is based on a path-finding algorithm which substantially reduces the number of cases in which routing loops can occur. A mechanism has been proposed for the reliable exchange of update messages. The performance of the routing algorithm in WRP has been compared with that of an ideal topology broadcast algorithm (ILS), DUAL and DBF for highly dynamic environment through simulat:ions. The simulation results show that WRP pro- vides about 50% improvement in the convergencetime as compared to DUAL. The results indicate that WRP is a good alternative for routing in packet radio networks. References 111 PI 131 [41 151 [61 r71 WI PI D. Beyer et. 01.. “Packet Radio Network Research, Develop- ment and Application”, Proc. SHAPE Conference on Packer Radio, Amsterdam. 1989. D. Beyer. “Accomplishments of the DARPA SURAN Pro- gram”, Proc. IEEE MILCOM 90, Monterey, California. Dec. 1990. D. Bertsekas andR. Gallager, Data Networks, SecondEd. Pren- tice Hall, Inc. 1992. C. Cheng, R. Reley. S. P. R Kumar and J. J. Garcia-Luna- Aceves. “A Loop-Free Extended Bellman-Ford Routing Pro- tocol without Bouncing Effect”, ACM Computer Communica- tions Review, 19 (4), 1989, pp.224-236. Charles E. Perkins and Pravin Bhagwat, “Highly Dynamic Destination-Sequenced Distance-Vector Routing (DSDV) for Mobile Computers”‘, ACM SIGCOMM. Vol.24 (No.4). Oct. 1994, pp.234-244. M. Scott Corson and Anthony Ephremides. “A Distributed Routing Algorithm for Mobile Wireless Networks”, ACM /. of Wireless Networks. Jan. 1995. pp. 61-81. JJ. Garcia-Luna-Aceves, “A Fail-Safe Routing Algorithm for Multihop Packet-Radio Networks”, IEEE INFOCOM April, 1986. J J. Garcia-Luna-Aceves. ‘Loop-Free Routing Using Diffusing Computations”, IEEEIACM Trans. Networking, Vol.1. No. 1. Feb. 1993. pp.130-141. J. Hagouel, “Issues in Routing for Large and Dynamic Net- works”, IBM Research Report, RC 9942 (No. 44055). April 1983. [lo] P.A. Humblet. “Another Adaptive Shortest-Pam Algorithm”, IEEE Trans. Comm., Vo1.39. No.6, June 1991, pp.995-1003. [ll] B.M. Lemer. DL. Nielson and F.A. Tobagi, Proc. IEEE. Packet Radio Networks Special Issue. Jan. 1987. 1121 J. Moy, “OSPF Version 2”. RFC 1583, March 1994. [ 133 Shree Murthy and J J. Garcia-Luna-Aceves. “A More Efficient Path-Finding Algorithm”, 2gth Asilomor Conference. Pacific Groove, CA, Nov. 1994. [14] B. Rajagopalan and M. Faiman, “A Responsive Distributed Shortest-Path Routing Algorithm within Autonomous Sys- tems,” Journal of Internetworking: Research and Experience, Vol. 2. No. 1, March 1991. pp. 5169. [15] W. T. Zaumen. “Simulations in Drama”, NehvorkInformci!tion System Center, SRI International, Menlo Park, California. Jan. 1991. 94
`
`

`

`Case 1:16-cv-02690-AT Document 121-15 Filed 08/05/16 Page 9 of 356
`
`L P;A -i DBF + DUAL a.- 119 * -I 1.0 10.0 100.0 1000.0 loan0 INTERARRIVAL TIME .I. .., . ..,- .., ..,- PFA - DBF + DUAL .I.... ILS * Figure 8: Los-Nettos 1.0 10.0 100.0 low.0 loooo.o INTERARRIVAL TIME PFA c DBF - DUAL . . . . . . 11s * 1.0 10.0 100.0 1000.0 loooo.o INTERARRIVAL TIME Pigure 9: Nshet _, __,_ .., . . . ... PFA - DBF - DUAL . ..-. 1.0 10.0 100.0 1000.0 10ooo.0 1.0 10.0 100.0 low.o lom.o INTERARRIVAL TIME INTERARRIVAL TIME , . , . PFA - DBF -- DUAL .I.... IL9 * 1.0 10.0 100.0 low.o loow.o INTERARRIVAL TIME _, PFA - DBF + DUAL -I.... .~ .._.) “.............. . ..~..C” /... a....) ._.“.“..... *.. “1 . . . . . . . . . “” A\- <\ . Figure 10: ARPANET 95
`
`

`

`I IIII IIIIIII Ill llll lllll llll lllll lllll Ill Ill llll 1111111111111111
`Case 1:16-cv-02690-AT Document 121-15 Filed 08/05/16 Page 10 of 356
`US005673252A
`5,673,252
`[111 Patent Number:
`Sep. 30, 1997
`[451 Date of Patent:
`
`United States Patent c191
`Johnson et al.
`
`[54) COMMUNICATIONS PROTOCOL FOR
`REMOTE DATA GENERATING STATIONS
`
`[75)
`
`Inventors: Dennis F. Johnson; Don Marcynuk;
`Erwin Holowick. all of Winnipeg,
`Canada
`
`[73) Assignee: Itron, Inc., Spokane. Wash.
`
`[21) Appl. No.: 451,386
`
`[22) Filed:
`
`May 26, 1995
`
`Related U.S. Application Data
`
`[63]
`
`[51]
`[52]
`[58]
`
`Continuation of Ser. No. 247,988, May 23, 1994, aban(cid:173)
`doned, which is a continuation-in-part of Ser. No. 124,495,
`Sep. 22, 1993, abandoned, which is a continuation of Ser.
`No. 732,183, Jul. 19, 1991, which is a continuation-in-part
`of Ser. No. 480,573, Feb. 15, 1990, Pat. No. 5,056,107.
`Int. CL 6
`........................................................ H04J 3/16
`U.S. CI ....................... 370/94.1; 370/95.2; 370/100.1
`Field of Search .................................. 370/95.1, 95.2,
`370/95.3, 105.1. 105.4, 105.2. 94.1, 94.2,
`94.3, 60, 60.1, 61, 100.1. 110.1, 85.1, 85.6,
`85.08; 375/354, 355, 356, 357, 359, 363,
`365, 366, 372; 340/825.5, 825.51. 825.52.
`825.08; 455/13.3, 13.4. 51.1, 54.2, 58.1
`
`[56]
`
`References Cited
`
`U.S. PATENT DOCUMENrS
`
`1,987,889
`3,705,385
`3,786,423
`3,860,870
`4,013,962
`
`111935 Beverage et al ........................ 342/367
`12/1972 Batz ........................................ 340/152
`11197 4 Martell .......... ...... .................... 340/151
`111975 Richardsn et al. ........................ 370/11
`3/1977 Beseke et al ............................. 370/11
`
`(List continued on next page.)
`
`FOREIGN PATENT DOCUMENTS
`
`0263421
`0366342
`2205260
`2060843
`
`411988 European Pat. Off ..
`5/1990 European Pat. Off ..
`10/1980 Germany .
`411981 Germany .
`
`OI'HER PUBLICATIONS
`
`W093/14585 (PCT/US93/00014) with International Search
`Report.
`
`Primary Examiner-Dang Ton
`Attorney, Agent, or Firm-Patterson & Keough, P.A.
`
`[57)
`
`ABSTRACT
`
`A method for communicating data between a central data
`terminal, a plurality of intermediate data terminals, a plu(cid:173)
`rality of remote cell nodes, and a plurality of network service
`modules, using a plurality of frames with each frame having
`a plurality of channels. The plurality of intermediate data
`terminals transmit IDT-synchronization signals to the plu(cid:173)
`rality of remote cell nodes on a first channel of the frame.
`The plurality of remote cell nodes transmit RCN(cid:173)
`synchronization signals to the plurality of network service
`modules on a second channel of the frame. The network
`service modules transmit data from a plurality of physical
`devices. using radio waves, as NSM-packet signals to the
`plurality of remote cell nodes using a fourth channel of the
`frame. The plurality of remote cell nodes store the incoming
`NSM-packet signals and. responsive to a first polling signal
`transmitted in a third channel of the frame from a particular
`intermediate data terminal, transmit the NSM-packet signals
`to the intermediate data terminal as RCN-packet signals on
`a fifth channel of the frame. The intermediate data terminal
`in turn stores the RCN-packet signals received from the
`plurality of remote cell nodes and, responsive to a second
`polling signal transmitted from the central data terminal on
`a sixth channel of the frame, transmits the RCN-packet
`signals as an IDT-packet signal on a seventh channel of the
`frame to the central data terminal.
`
`0244384 11/1987 European Pat. Off ..
`
`85 Claims, 3!> Drawing Sheets
`
`)COMMANDS
`
`/,.FORMATION
`
`NS Ms
`
`

`

`Case 1:16-cv-02690-AT Document 121-15 Filed 08/05/16 Page 11 of 356
`
`5,673,252
`Page 2
`
`U.S. PATENf DOCUMENTS
`
`4,040,046
`4,190,800
`4,361,851
`4,388,690
`4,495,596
`4,661,804
`4,7(17,679
`4,734,680
`4,780,910
`4,783,623
`4,799,059
`4,799,062
`4,804,938
`
`8/1977 Long et al .............................. 340/310
`2/1980 Kelly, Jr. et al ................... 340/310.02
`11/1982 Asip et al. ................................ 358/84
`6/1983 Lumsden ................................. 364/483
`1/1985 Sciulli ..................................... 364/900
`4/1987 Abel ........................................ 340/539
`11/1987 Kennon et al .......................... 340/310
`3/1988 Gehman et al. ........................ 340/539
`10/1988 Huddleston et al .................... 455/617
`11/1988 Edwards et al ......................... 3241156
`1/1989 Grindahl et al .................... 340/870.03
`1/1989 Sanderford et al. .................... 342/450
`2/1989 Rouse et aL ............................ 340/310
`
`4,815,106
`3/1989
`4,839,642
`6/1989
`4,887,259 12/1989
`4,952,928
`8/1990
`4,958,645
`9/1990
`5,014,213
`5/1991
`5,056,107 10/1991
`5,086,292
`2/1992
`5,132,968
`7/1992
`5,166,664 11/1992
`5,239,575
`8/1993
`5,264,828 11/1993
`5,381,136
`1/1995
`
`Propp et al. ............................. 3751257
`Batz et al. .............................. 340/825
`Morita ....................................... 370/60
`Carroll et al. ..................... 340/825.54
`Odell et al. ........................... 128/903
`Edwards et al. ........................ 364/483
`Johnson et al. . ........................ 375/200
`Johnson et al .......................... 340/637
`Cephus ................................... 370/94.1
`Fish ......................................... 340/539
`White et al. ............................ 379/107
`Meiksin et al ...