Title: Communications Systems Lecture
1Communications SystemsLecture 7
- David Andrews
- dandrews_at_eecs.ukans.edu
2What We Will Cover Today
- Real Time Communication Requirements
- Time
- Fault Tolerance
- Network Configurations
- Single Node
- Multiple Nodes
- Protocols
- Lower Level Data Transmission Formats
3Real Time Communication Requirements
- Must Support System Requirements
- Hard/Soft Requirements
- Computer Delay Times
- Predictable versus Variable Delays
- Transit Time Jitter
- Reliability Issues
- Guaranteed Delivery
- Error Detection
- Support Reconfiguration
- Standardization
- No One Standard Yet For R.T. Systems
4Real Time Communications
- Modern Systems Distributed
- Attempting to Employ More Standards
- Message Passing Protocols
- Network Protocols
- Network Topology Adopts Hierarchical Protocols
- Allows Heterogeneous Operations
- Application programs modified without need to
modify low level protocols - Addition of Nodes Easier
- Composable Protocols
- Application Layer
- Transport
- Network Layer
- Physical Layer
5OSI Reference Model
- OSI Open Systems Interconnection
- Were going to deal mostly with Transport
Network Data Link Layers
6Example Distributed Pattern Using OSI Model
- Each Layer forms virtual interconnections
7Embedded Network Standards
- The nice thing about standards is that you have
so many to choose from. Furthermore, if you do
not like any of them, you can just wait for next
year's model. - - - - Tanenbaum '89
8IEEE Standards
- IEEE 802.1 - Interface definitions
- A document that contains an introduction to
the standards and interface definitions - IEEE 802.2 - Logic Link Control (LLC)
- The upper part of the Data Link layer
- Establishes/terminates links...
- IEEE 802.3 - CSMA/CD - Carrier Sense Multiple
Access/Collision Detection - IEEE 802.4 - Token Bus
- IEEE 802.5 - Token Ring
- IEEE 802.11 Wireless LAN
- IEEE 802.15 Wireless Personal Area Network
(WPAN) - IEEE 1394 - Firewire (consumer electronics)
9Physical TopologiesLinear Networks
- BUS
- Good fit to long skinny systems
- elevators, assembly lines, etc...
- Flexible - many protocol options
- Break in the cable splits the bus
- May be a poor choice for fiber optics due to
problems with splitting/merging - Was prevalent for early desktop systems
- TREE
- An extension of a bus
- Better fault isolation
- Be careful that root node is not a single
point of failure
10Other Network Topologies
- Star
- Can emulate bus functions
- Easy to detect and isolate failures
- Broken wire only affects one node
- Good for fiber
- Broken hub is catastrophic
- Requires more wiring common for current
desktop systems - No contention over a shared wire
- Nodes act as repeaters
- Requires bypass for failed node
- Popular choice for fiber optics
11Example Distributed Topology
12Application/Transport Protocols
- Application Layer Defines Message Passing
Protocols - Supports Synchronous/Asynchronous Communications
- Supports Error Detection
- Separates Node from Network
- Transmission error detection
- Node error detection
- Supports Composability
- Encapsulates Node
- Transport Layer (OS) Provides Implementation
Additional Functionality - Common Characteristics (Well look in more detail
later) - Application Protocols
- Asynchronous/Synchronous Send/Receive
- End to End Acknowledgements
- Transport Protocols
- Flow Control
- OS Timeout and Retries
13Example Message Passing Pattern
- SEND( Channel_ID in CHANNEL_PTR_TYPE
- MSG_SIZE in MSG_SIZE_TYPE
- Buffer_Ptr in BUFFER_PTR_TYPE) return
TX_PTR_TYPE
14Message Transfer Protocol
- User message to Communication Buffer
- Message Executive Header (to OS at receiving
node) - Request to send (OS -gt send network)
- Message Transfer (segmented)
- Transfer Complete (send network -gt receive
network) - Transfer Complete (receive network -gt receive OS)
- Header uploaded (receive network -gt receive OS)
- Message uploaded (receive network -gt app)
- Status return (receive OS -gt receive network)
- Status return (receive -gt send network)
- State return (send network -gt send OS)
15Header Information
- Increasing functionality requires more
complicated structures/processing
Â
CCM Executive Header Layout
CCM Communications control message (OS lt-gt
Network) information CCM keeps transport
information based on OS protocols
Executive Header (OS lt-gt OS) keeps information
between OSs
16Error Detection
- Application Layer
- Message Context (Validity of Data)
- OS Layer
- Can Check for the following Problems
- Data corrupted during transfer
- Checksum errors, CRC checks
- Reciever Must Reproduce Checksums, CRCs
- Message Not delivered
- Receiver Node/OS Down
- Network Clogged
- Time Out (Watchdog Timer) set on each
transmission goes off before ack - OS Can Attempt Resolution by Resending Message
- Single Segments Within Bigger Message
- OS Can Status OS on Receiver Node
- May be Network instead of OS
- Network Layer
- Check for transmission of bit streams between
nodes complete - Parity check, Network Connectivity
-
17Network Protocols
- OS Bridges between application program and
network - Network has own Data/Invocation protocols
- Examples of Data Protocols
- CSMA/CD Carrier Sense Multiple Access/Collision
Detection - Ethernet
- CSMA/CA Carrier Sense Multiple Access/Collision
Avoidance - CAN (control area network) We will study more
next class - Examples of Invocation Protocols
- BPP Buffered Pipe Protocol
- Mailbox
18Generic Protocol Message(Transport and Network)
- Transport/Network Both Have Protocols
- Usually mutually supportive
- Header
- Routing information (source, destination)
- Transport Logical ID for programs
- Network Node ID
- Global priority information (which message
gets on bus first?) - Data
- Application- or high-level-standard defined
data field ( 1 Meg message) - Transport Segments (typically 1k bytes)
- Network Packets (typically lt 100 bytes)
-
- Error detection
- Detects corrupted data (e.g., using a CRC)
- Embedded networks can have very high bit error
rates
19Distributed Node Hardware Support
- Hardware Support For Message Passing
- Decouple Network From Transport/Application
Program - Typical DMA Channels, Built in Error Checking
(CRC) - Example Shows Event Driven Interface
20Physical Layer
- Transmission Issues of Physical Channel
- Channel Characteristics
- Logic Levels of voltage
- Transmission speeds
- Width of logic 1/0
- Bit Encodings
- Non-recurring-zero (NRZ)
- No timing info contained within message
- Timing is initiated with start bit, but thats it
! - Synchronous
- Introduces intentional line changes within
message bits to synch on
21Basic Bit Encoding - NRZ
- Asynchronous
- No Synchronization within data stream
- Timing at start of transmission
- Separate send/receive clocks must be close in
frequency - Number bits in message limited by drift (approx.
10)
22Synchronous EncodingManchester Code
- Manchester Encoding
- Data encoded by transition from high-to-low or
low-to-high - Self-clocking scheme
0
0
1
1
23General Considerations
- Flexibility Generally Traded Off With Temporal
Accuracy - Additional support (retries/flow control) require
more processing - Jitter introduced with variable functionality
- Hierarchical Protocols Introduce Composability
- Good Expansion, Better Abstractions
- More Complexity