1 / 7

Proposal for a Proximity-2 Protocol

Proposal for a Proximity-2 Protocol. Ed Greenberg Greg Kazz May 2001. Why Proximity 2. Projected minimum data rates allow for significant performance gains from use of high performing codes

arnon
Download Presentation

Proposal for a Proximity-2 Protocol

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Proposal for a Proximity-2 Protocol Ed Greenberg Greg Kazz May 2001

  2. Why Proximity 2 • Projected minimum data rates allow for significant performance gains from use of high performing codes • The LDPC family of codes provides substantial coding gains and offers these gains when transponder or RF bandwidth limits constrain the desired data rates. • Next generation Mars Orbiters will include highly elliptical orbits requiring increased link performance and increased contention for communications. • Newer flight transponders provide substantially increased storage for the “Go Back N” protocol allowing it to utilize larger values of N.

  3. Characteristics Desired for Prox-2 • Maintain the variable frame structure of the link layer but achieve maximum coding gain using the LDPC family of codes. • Maintain the current Protocol state table and actions but modify the frame and coding entities to achieve better performance and better controls when multiple remote units are in the same field of view of the Orbiter • The coding and the link layer framing need to be asynchronous to achieve the desired performance and maintain the structural aspects of the frame. • The use of the 1024 bit LDPC code is a compromise in performance, access delay and implementation difficulty yet still provides the significant performance and the ability to rapidly achieve and or switch communication session between remote users. • Utilization of HDLC bit stuffing coding as an inner code reduces overhead and simplifies implementation. • Frames containing both sender and receiver addresses within a frame eliminates ambiguity and enables the Orbiter to orchestrate communications sessions that are overlapping. • The inclusion of the PLCW within each information frame reduces overhead and reduces response time to link errors.

  4. Prox-2 Frame Structure Version- 2 bits • Type- 3 bit----- • Bit 1- Supervisory (0) or Information (1) • Bit 2- Bypass (0) or Sequence Controlled (1) • Bit 3- Addresses are 8 bits or 12 bits First Byte Received Sequence Error - 1 bit –- yes/no Spare- 2 bits - for signaling options or future use (e.g. to flag CRC or link security) Frame Length- Optional 16 bits (managed or in a different version that doesn’t use HDLC) To/From-- 8 or 12 bits each (currently on 4 bits would be necessary) Expected Frame Number- V(R)–8 bits All frames Contained Data Sequence Number- V(S)- 8 bits Only included when Type =“11x” Data------- Variable # of bytes (0-2k bytes) (could use the current supervisory commands) CRC------- Optional (16 bits) (not required when coupled with decoder error notice) • Notes: • Frame Delimitation is provided by HDLC encoding in this proposed version • Frame length not really required because of HDLC delimiting • CRC not required but could be useful to add extra frame validation • Supervisory commands could use same methodology as Proximity-1

  5. Coding Performance • LDPC (Codeblock length=1024) • Required db for 10-4 Bit Error Rates (BER): • --Uncoded ~9 db, LDPC Rate=1/2 1.6 db, LDPC Rate=4/5 3.6 db • Improved BER Performance from LDPC coding gains: • @BER of 10-8 for 1024 LDPC rate ½ requires 1.9 db • @BER of 10-8 for 1024 LDPC rate 4/5 requires 3.6 db • Thus the gain for Rate ½ LDPC is at least 7 db which could increase the data rates by about 5 times which is especially important at low rates and low BERs . • For Bandwidth limited situations (either RF or transceiver) the rate 4/5 LDPC still provides an improved data rate of 3 times while limiting the required bandwidth increase to only 13%. • Randomization would be applied synchronously with the LDPC Codeword. • The first byte of the codeword field could be used for other services (i.e. a sequence number for time tagging instead of using the frame sequence number) • HDLC Coding • A zero bit is inserted when a sequence of 5 one bits occurs • This insures that the “01111110” used as a frame delimiting flag and as fill is unique (can not occur in data) • The code requires the dropping of the “0” that is the last bit in a “0111110” sequence • This coding is only useful when the bit error rate is better than 10-10 • Combined Coding • Provides frame delimiting eliminating the need for a separate Frame Sync Word (FSW) to identify the beginning of the frame and a Frame Length Field to determine length of frame.

  6. Formatting Differences • The frame would contain both the sender’s and intended receiver’s addresses. • Thus each of the participants in a connection know with whom they are conversing. • This may have a greater significance for the Mavin Mission which will place an Orbiter at Mars in a highly elliptical orbit where multiple landers may be in the field of view of the Orbiter at the same time. • Information Frame will contain a PLCW so there would be no need to inset supervisory PLCWs, resulting in the shrinking of the PLCW effectively to 8 bits. • A Supervisory PLCW (if needed when no data is being transferred) will be just 12 bytes including the sync flag instead of Prox-1’s 14 bytes even though both sender and receiver addresses are included. • Frame delimiting is provided by a simple “01111110” detection • Because the LDPC decoder flags when it is not decoding and when it finds an erred codeblock this can be used to flush any subset of a frame that was received from a prior codeword and force the command process to look for a new frame. This feature and the infinitesimal undetected codeword error rate allows for the elimination of the CRC requirement.

  7. Proximity Timing • The Current Proximity 1 protocol provides for the gathering of time tagged data transferred across the prox link. This approach can be used to correlate to a few microseconds the time on the remote unit related to the Orbiter. • Current and near term projected requirements do not have requirements that are better than many tens of milliseconds. • If the requirements were to change then the time correlation of the Orbiters would need to improve dramatically and the time tagging of frames could not provide the desired accuracy. • In this case the time tagging could better use the code words but a sequence number for the code words be need to be incorporated. This feature could be accommodated by usurping the first byte of the decoded codeword for this purpose.

More Related