13183848
Description
Flashcards by Julian Rottenberg, updated more than 1 year ago
|
Created by Julian Rottenberg
about 6 years ago
|
|
| Question | Answer |
| Data (universal) | Representation of facts, concepts, ideas and instructions in a formalized manner, that is suitable for communication, interpretation and processing through human beings and/or technical devices |
| Data (picture) | |
| Information | The meaning, that a human being associates with data according to the conventions that were used when the data was generated The notion of information is only related to human beings Term should be avoided when talking about data communication, telecommunication, etc. |
| (Data) Communication (original meaning) | Exchange of data between human communication partners |
| (Data) Communication (universal meaning of "data") | Every concrete communication is a data communication |
| (Data) Communication (literature and daily language definition) | Transmission of digital data between telecommunication devices |
| (Data) Communication (definition of this class) | Data (tele-) communication is the generic term for all data exchange over an immaterial carrier and a significant distance between human beings and/or machines |
| Data transport over Immaterial Carrier | Flow of energy (e.g. electrical, optical, electro-magnetical wave, acoustic waves when speaking, current or voltage in a wire) |
| Data transport over Material Carrier | opposite of "immaterial carrier" (e.g. letter, magnetic tape, floppy disk, CD, DVD) |
| Signal | A signal is the physical representation of data in the form of a characteristic variation in space and/or time of one or more physical quantities |
| Signal (picture) | |
| Simplest Communication | Direct Physical Connection (e.g. Web example: Browser = client and sever - simplest case: directly connect them by a (pair of) cable) |
| Signal (short definition) | Representation of data by characteristic changes (in time or space) of physical variables |
| Immaterial Signals | Immaterial signals in physical media enable data communication between remote senders and receivers |
| What Good is a Physical Connection? - Signals (picture) | |
| What should be communicated? | Data, represented as bits |
| What can be communicated between remote entities? | Signals |
| What do we need to make (data) communication possible? | a means to transform bits into signals and from signals back into bits at the receiver |
| What do transmitting signals from a physical carrier result in? | Transmitting signals on a physical carrier results in some low-level properties |
| How long does it take for a signal to reach receiver? | Propagation delay d |
| How fast does a signal travel in the medium? | Propagation speed v |
| Formula for d (propagation delay) | d = distance / v |
| Speed of electromagnetic waves in vacuum? | Speed of light v = c |
| Speed of electromagnetic waves in copper? | v = 2/3 c |
| Low-Level Properties of Communication (picture) | |
| What happens in the first 'd' seconds after transmission starts? Where are the bits? | - Bits are transmitted and propagate towards the receiver - Sender keeps sending bits - First bit arrives after 'd' seconds - In this time, sender has transmitted 'd * r' bits - the bits are stored in the wire |
| Bandwidth / delay product (product of delay and data rate) | d * r |
| How Can a Wire Store Data? - Bandwidth-Delay Product | |
| Two-way communication (examples) | Telephony: Both parties want to say something WWW: Server needs to know which webpage shall be delivered |
| 3 different communication types and what they are | - Simplex: only one party transmits (e.g. radio boardcast; many recipients at the same time) - Half duplex: Parties alternatively send data (e.g. Conversation) - Full duplex: Both parties send all the time |
| Which communication types are showed here? | 1. Simplex: Only one party transmits (e.g. radio broadcast; many recipients at the same time) 2. Half duplex: Parties alternatively send data (e.g. Conversation) 3. Full duplex: Both parties send all the time |
| How to Realize Half-Duplexing? Which realization is better and what are their probelms? 1. Two pairs of cables, one for each direction 2. Use one cable | 1. wasteful 2. if used intelligently - participants alternatively transmit, wait their time until it is their turn -> Problem: => both sending at the same time would not work - signals interfere => How can one node decide that the other is done sending? |
| Realizing Half Duplex: What can we do to fix this problem when using 1 cable intelligently? - Both sending at the same time would not works, signals interfere. How can one node decide that the other is done sending? | - every node has X-Time for sending and then it's the other nodes turn (Time division duplex - TDD) - you end sending with a 'keyword', when the other node hears this 'keyword' they know you finished and they can start sending |
| How to realize Full-Duplexing? | - use 2 cables, but still overhead (installation, maintenance, ...) - use 1 cable and explore properties of the physical medium: transmissions in different frequencies do not interfere - use different frequencies for transmission in different directions (Frequency Division Duplex - FDD) |
| TO BE DONE: Quick Tour page 18 How to realize duplexing - full duplex by time divison duplexing | TO BE DONE |
| Advantages of circuit switching | - simple - once circuit is established, resources are guaranteed to participating terminals - once circuit is established, data only has to follow the circuit |
| disadvantages of circuit switching | - resources are dedicated - what if there is a pause in the communication? - circuit has to be set up before communication can commence |
| packet switching: | - avoid setting up a circuit for a complete communication - instead: chop up data into packets |
| packets | - contain some actual data that is to be delivered to the recipient ( can have a different size) - also needs administrative information (e.g. who the recipient is) - sender then occasionally sends out a packet, instead of continuous flow of data |
| Problems with packets | - How to detect start and end of a packet, which information to put into a packet? |
| packets (picture) | |
| Switch (and problems) | - direct physical between the sender and recipient - Problem: waste of resources |
| Packet Switching: Switches additional tasks? | - receive a complete packet - store the packet in a buffer - find out the packet's destination *forward* the packet to this next hop towards its destination (like the post office does it) => store-and-forward network |
| packet switching (advantages / disadvantages) | + connection is only used when it needs to be - decide where the packet should be sent next to reach its destination -> information about the network graph necessary |
| packet switching (picture) | |
| Multiplexing | - multiple sender, send to the swtich (multiplexer) which then organizes the forwarding packets over such a single, shared connection - multiplexeres in general need buffer space as well |
| Multiplexing Options for sending | other alternatives: - Code Division Multiplexing (CDM), Space Division Multiplexing (SDM) -> mostly relevant in wireless communication |
| Multiplexing: other options | - Code Division Multiplexing (CDM), Space Division Multiplexing (SDM) -> mostly relevant in wireless communication |
| Multiplexing: parallels / relations to duplex operation | - multiplexing describes how to operate several pairs of communicating entities - duplexing describes how a given pair of communicating entities can exchange data |
| The prupose of multiplexing | - it abstracts away that a physical connection has to be shared with other contending entities, each sending a logical flow - it allows the entities connected to the switch to 'imagine' that they alone are using the physical connection -> at somewhat lesser properties - virtualizes the actual, physical connection - needs a peer entity, a *demultiplexer*, to restore the original flows |
| concept of virtualizing and enriching properties of a simpler subsystem | - it is pivotal (zentral/lebenswichtig/entscheidend) for communication networks - as it is in software engineering, operating systems, etc. - it allows us to think in terms of increasingly more complex communication systems, build one atop the other |
| Multiplexing & Shared Resources | - can be viewed as a means to regulate the access to a resource that is shared by multiple users -> the switching element/its outgoing line -> with the switching element as a controler |
| examples of shared Resources | - classroom, with "air" as physical medium - shared copper wire, as opposed to direct connection |
| virtually shared vs shared | |
| common characteristics of a broadcast medium | - only a single sender at a time! -> exclusive access is neccessary (can easily be archieved with a multiplexer) => has to be ensured by all participants working together -> there are some exceptions using CDMA - |
| Problem of multiple access to a shared medium | - rules have to be agreed upon -> classroom approach: only speak when asked to, central instance |
| options for Next Hop Selection | - Flooding -> send to all neighbors - hot potato routing -> send to a randomly chosen neighbor |
| Routing tables | - for each switching element separately - separate entry for each destination - contains information about the (conjectured) shortest distance to a given destination via each neighbor |
| Source of errors / abnormal situations | - conversion from signals to bits can fail - access to a shared medium might not work - packets can be lost, e.g., because of buffer overflow - packets can be misrouted (because of incorrect routing tables), delayed, reordered - receiver might not be able to keep up with incoming stream of packets - routers can fail, resulting in incorrect routing tables - ... and many more |
| error control | - needed at various abstraction levels -> between two direct neighbors, over a given connection -> between end systems, to compare for errors not detected locally (e.g., incorrect order of packets) |
| congestion control | protect the network against buffer overflows, regulate the number of packets injected into the network |
| flow control | protect end systems against too many packets coming in |
| overload control | - congestion control - flow control |
| Where and how to implement error and overload control | - main options: in the end system or in the network - big difference between telephony system and Internet - telephony carrier are (traditionally) interested in network-based solutions to be able to charge for it |
| Layers | - are subsystems - each layer uses capabilities of a "lower" subsystem, adds own rules and procedures, to provide a more useful, advanced service |
| SAP | Service Access Point |
| Services (layers) | - expose a well defined interface to higher layers - are accessible at their Service Access Point (SAP) - is a promise what is going to happen to data when delivered to SAP |
| Service | - any act of performance that one party can offer to another that is essentially intangible and does not result in the ownership of anything - production may or may not be tied to a physical product - focus is on the output, the result of the service -> NOT the means to achieve it |
| Layers and Services | - Layers provide services to their users, at their interface - convention: consecutive numbering, higher numbers for more abstract layers/services - Services can be accessed at different places by different users |
| Layers and Services (Bild) | |
| Service Primitives | - set of operations available at the interface of a service - formal definition of the service |
| Bit Transmission Layer (Example) | SEND_BIT - sender can ask for the delivery of a bit to the receiver RECEIVE_BIT - receiver can wait for the arrival of a bit (blocking) INDICATE_BIT - indicate to the receive that bit is now available (asynchronous) |
| Main Groups (Service Primitives) | - Many different service primitives are conceivable - four main types / groups of such primitives are usually distinguished: -> Request (Req) -> Indication (Ind) -> Response (Res) -> Confirmation (Conf) - not all four types need to be available for all services |
| 4 Main Types / Groups - Service Primitives | => Request (Req) - Ask a layer to perform a particular service => Indication (Ind) - A layer indicates to its (higher-layer) user that "something has happened", an (asynchronous) notification => Response (Res) - A higher-layer user answers an indication (e.g. by accepting the delivered data and confirming its receipt) => Confirmation (Conf) - The original service requester is informed that the service request has been (successfully or unsuccessfully) completed |
| two main possibilities how to treat data in service primitive design | - unit of data are well-delimited messages - unit of data is individual byte, sequence of bytes or byte stream is transmitted |
| Unit of data are well-delimited messages (Service Primitives - Unit of Data) | - only complete messages are sent - only complete messages are received - "Half of messages" is not a useful concept |
| Unit of data is individual byte, sequence of bytes or byte stream is transmitted (Service Primitives - Unit of Data) | |
| Correctness Requirements | => Completeness - All data that is sent is eventually delivered => Correctness - If data is delivered, it is correct, i.e., the data that has been actually sent -> messages are not modified, original version is delivered -> byte sequence is free of errors => in order - Byte sequence / sequence of messages is delivered in the order it has been sent => Dependable - secure, available => Confirmed - Reception of data is acknowledged to the sender ~> Not all requirements are always necessary |
| Connection-oriented service | - Service can require preliminary setup phrase, e.g., to determine the receiver -> Three phases: connect, data exchange, release connection |
| Connection-less service | - Invocation of a service primitive can happen at any time, with all necessary information provided in the invocation |
| Connection-Oriented vs Connection-Less Service | - the distinction does NOT depend on circuit or packet switching - connection oriented services can be implemented on top of packet switching (and vice versa, even though a bit awkward) |
| Connection-Oriented Primitives to handle connection | => CONNECT - setup a connection to the communication partner => LISTEN - wait for incoming connection requests => INCOMING_CONN - indicate an incoming connection request => ACCEPT - accept a connection => DISCONNECT - terminate a connection |
| Typical Examples of Services | - Datagram service (connection-less) - Reliable byte stream (connection-oriented) ~> almost all possible combinations are conceivable! |
| Datagram service | - unit of data are messages - Correct, but not necessarily complete or in order - connection-less - usually insecure / not dependable, not confirmed |
| Reliable byte stream | - byte stream - correct, complete, in order, confirmed - sometimes, but not always secure / dependable - connection-oriented |
| A Concrete Service Interface - BSD Sockets | - most popular service interface are "BSD sockets" - model the network service like the access to a file => Sending data = Writing to a file => Receiving data = Reading from a file => Opening a file = Connection to a communication peer => Files - in UNIX - are treated via so-called file handles => file handles = represent communication peers |
| Datagram Communication Over Sockets (Bild / komplette Folie) | |
| Byte Streams Over a Connection-Oriented Socket (Bild / komplette Folie) | |
| What's a Protocol? | - Specific messages are sent - Specific actions are taken when messages received, or other events Protocols define: - format - order of messages sent - received among network entities - actions taken on message transmission and receipt |
| Human Protocol vs Network Protocol | |
| Layers are Distributed | |
| Distributed Layers Need to Follow Rules - Protocols | |
| Protocols | - are a set of rules -> describe how two (or more) remote parts of a layer cooperate to implement the service of the given layer --> behavior, packet formats, ... -> use the service of the underlying layer to exchange data with peer |
| Protocols - peer protocol entities / peers | - remote parts that cooperate to implement the service of a given layer |
| Protocols (Bild) | |
| Service and Protocol (Bild) | |
| Protocol Specification | - the formal behavior, the rules which constitute the protocol have to be precisely - protocol instance has several states - events/transitions between states - transition can have conditions - actions during transition |
| Protocol Specification - FSM | - (Extended) Finite State Machine (FSM) - popular method |
| Protocols and FSMs | - Finite state machines implement actual behavioral rules of a protocol - have to communicate with their remote peer |
| Protocols and FSMs (Bild) | |
| Protocols and FSMs - Communication Finite state machines to remote peer | - can't communicate directly -> have to use service of underlying communication layer -> via service primitives, which can also provide arriving data to the protocol |
| Protocols and Messages | - when using lower-layer services to communicate with their remote peer, administrative data is usually included in those messages |
| Protocols and Messages (Bild) | |
| Protocol Stacks | - typically, there are several layers and thus several protocols in a real system - Layers / Protocols are arranged as a (protocol) stack -> one atop the other, only using services from directly beneath |
| Protocol Stacks - Strict layering | - Protocol stacks that only use services from directly beneath them while being stacked atop the other |
| Protocol Stacking (Bild) | |
| Layers do not Care About Distributed Lower Layers | - a given layer n+1 does not care about the fact that its lower layer is actually distributed, has remote FSMs - layer n+1 imagines layer n as something that 'just works', has service access points where they are necessary - in reality, layers n is distributed in turn, relying on yet lower layers - the physical medium (layer 0) is transporting data/signals |
| Layers do not Care About Distributed Lower Layers (Bild) | |
| Protocol Mechanisms: What Do Protocols Do for a Living? - Addressing/naming - Fragmentation - Re-Sequencing | Addressing/naming: - manage identifiers Fragmentation: - divide large messages into smaller chunks to fit lower layer Re-Sequencing: - reorder out-of-sequence messages |
| Protocol Mechanisms: What Do Protocols Do for a Living? - Error control - Flow Control - Congestion control | Error control: - detection and correction of errors and losses (e.g. retransmission, forward error correction Flow control: - avoid flooding/overwhelming of slower receiver Congestion control: - avoid flooding of slower network nodes / links |
| Protocol Mechanisms: What Do Protocols Do for a Living? - Resource allocation - Multiplexing | Resource allocation: - administer bandwidth, buffers among contenders Multiplexing: - combine several higher-layer sessions into one "channel" |
| Protocol Mechanisms: What Do Protocols Do for a Living? - Compression - Privacy, authentication | Compression: - reduce data rate by encoding Privacy, authentication: - security policy (others are listening) |
| How to Structure Functions / Layers in Real Systems? | - Many functions have to be realized -> modularization and layering ease maintenance & updating of a system |
| How to actually group Functions / Layers so as to obtain a real, working communication system? | - Explicit structure allows identification, and specification of relationships of complex system's pieces - Layered reference model for discussion - Layering structure and according protocols define the communication architecture |
| Layered Communication System (Bild) | |
| Layering Considered Harmful? -> Benefits of layering | - Need layers to manage complexity: don't want to reinvent Ethernet-specific protocol for each application - Change of implementation of ones layer's service is transparent to the rest of a system - common functionality: "Ideal" network |
| Layering Considered Harmful? - Problems / Disadvantages of layering | - Layer N may duplicate lower layer functionality (e.g. error recovery) - Different layers may need same information - Layer N may need to peek into layer N+x |
| Layering Considered Harmful? - Main reference models | - ISO/OSI reference model -> International Standard Organization Open System Interconnection) -> TCP/IP reference model -> by IETF - Internet Engineering Taskforce) |
| ISO/OSI Reference Model - Basic design principles | - Basic design principles -> one layer per abstraction -> each layer has a well-defined function -> choose layer boundaries such that information flow across the boundary is minimized (minimize inter-layer interaction) - enough layers to keep separate things separate, few enough to keep architecture manageable |
| ISO/OSI Reference Model - 7-layer model | - not strictly speaking an architecture, because protocol details are not specified - only general duties of each layer are defined |
| ISO/OSI 7-Layer Reference Model (two entities) (Bild) | |
| ISO/OSI 7-Layer Reference Model (complete network) (Bild) | |
| OSI Layers - Physical Layer (PH) | - provides a bit transparent interface to the physical media - specifies mechanical, electrical, functional and procedural means to support physical connection between open systems - physical connection does not imply connection-oriented operation! - different real media can be used, different control procedures are needed - in-sequence delivery of Bits assures - error detection sometimes included |
| OSI Layers - Link Layer (L) | - supports transmission of service data units (SDU) bigger than "word" among systems connected to a single physical path - essential function is block synchronization - sometimes, error detection or even error control is also provided - in the case of half duplex or multipoint links, the medium access has to be controlled, and peer systems have to be addressed |
| OSI Layers - Network Layer (N) | - Creates a logical path between open systems connected to individual, possibly different, subnetworks -> this logical path can go through several, possibly different, intermediate subnetworks - supports routing; This N-Service users are not concerned with the path - is uniform regardless the variation of subnetwork technologies, topologies, QoS, organizations - Network address ~ end system address |
| OSI Layers - Transport Layer (T) | - Completes the transmission part of the OSI stack - supports transmission with required QoS, in an economic way between (T)-Users (usually processes in an end system), regardless of network structure - Several classes of protocol with different functionality are defined (connection-oriented / connectionless; reliable / unreliable) |
| OSI Layers - Session Layer (S) | - Supports the synchronization of the dialogue and managing the exchange of data (potentially spanning over multiple transport layer connections) - Quarantine data delivery - a whole group of transmitted S-SDUs is delivered on explicit request of the sending party - Interaction management allowed to explicitly define which of the S-Users obtains the right to transmit - Connection resetting to pre-defined synchronization points |
| OSI Layers - Presentation Layer (P) | - Supports translation of data and data structures into a unique representation - only the syntax is modified in order to maintain the semantics - Selection of one of the generally agreed transfer syntaxes - local syntax of each end systems is translated into/from the selected transfer syntax |
| OSI Layers - Application Layer (A) | - Supports directly the end user via providing a variety of application services - this can be of: -> General type (e.g. Remote Procedural Calls, Transaction Processing,...), or -> Specific type (e.g. virtual terminal, file transfer access and management, job transfer...) - classical example: virtual terminal (functions of a real terminal are mapped into the virtual functions |
| ISO/OSI Reference Model - Critique | - very influential until today, in its structuring of functions into layers - actual protocols developed for it are irrelevant in practive - ISO gaining market acceptance for its model - in the Internet protocol model, the upper three OSI layers are summarized in one (Internet-) application layer |
| Architectural Requirements of the Internet | - Generality - Heterogeneity - Robustness - Extensibility - Scalability |
| Architectural Requirements of the Internet - Generality | - Support ANY set of diverse applications - either datagrams (videos...) or virtual connections (web...) |
| Architectural Requirement of the Internet - Heterogeneity | - Interconnect ANY set of network technologies |
| Architectural Requirements of the Internet - Robustness / Extensibility | - More important than efficiency |
| Architectural Requirements of the Internet - Scalability | - A later discovery: How many ARPAnets could the world support? A few hundred, maybe...? |
| Towards the End-to-End Principle | Foundation of the Internet architecture: - dumb network, smart end systems (exact opposite of telephony network!) - dumb networks: require only least common service - smart host |
| Towards the End-to-End Principle - Dumb network: require only least common service | - Datagram service: no connection state in routers - Best effort: all packets treated equally - Can lose, duplicate, reorder packets |
| Towards the End-to-End Principle - Smart hosts | - maintain state to enhance service for applications - "Fate-sharing" -- if a host crashes and loses communication state, applications that are communicating share this fate |
| TCP/IP Reference Model - Internet Layer | - packet switching, addressing, routing & forwarding - Particularly for hierarchically organized networks ("networks of networks") - Internet Protocol (IP) defined |
| TCP/IP Reference Model - Transport Layer | - two services & protocols defined -> Reliable byte stream: Transport Control Protocol (TCP) -> Unreliable datagram: User Datagram Protocol (UDP) -> in addition, (de)multiplexing - lower and higher layers not really defined -> "host to host" communication assumed as a given -> applications assumed |
| TCP/IP Protocol Stack | |
| Protocol Layering and Data in the Internet | - Each layer takes data from (layer) above -> adds header information to create new data unit -> passes new data unit to layer below |
| Protocol Layering and Data in the Internet (Bild) | |
| TCP/IP Suite of Protocols | - Many application specific protocols over IP - IP (with best effort service model) over many media specific (L2) protocols -> "Hourglass" model of IP - Quality of Service added to IP as an "afterthought" |
| TCP/IP Suite of Protocols (Bild) | |
| ARPANet: Protocols and Stack | - IMP-Host Interface: defiend by BBN Report 1822 - Communication Service: -> Reliable delivery to a specified host system of a message of arbitrary bit length --> I.E. a "reliable datagram" service -> The 8-bit byte not universal yet; computers used 8,12,16,18,24,32,36,48,... bit words -> ARPAnet host addresses were 24 bit |
| ARPANet: Protocols and Stack | |
| TCP/IP Reference Model - Critique | - No clear distinction between service, protocol, interface -> reliable byte stream is equated with TCP, although there is a clear difference -> Particularly below IP - Very specialized stack, does not allow a generalization to other technologies/situations - Great void below IP - Many ad hoc, wildly hacked solutions in many places, without careful design -> mobility support is a typical area where problems result later on |
| ISO/OSI versus TCP/IP | |
| Standardization | - necessary for large networks - Internet -> Mostly centered around the Internet Engineering Task Force (IETF) with associated bodies (Internet Architectural Board (IAB), Internet Research Task Force (IRTF), Internet Engineering Steering Group (IESG)) -> consensus oriented, heavy focus on working implementations -> hope is quick time to market, but has slowed down considerably in recent years - Manufacturer bodies |
| Basic Service of Physical Layer: Transport Bits | - the physical layer should enable the transport of bits between two locations A and B - Abstraction: Bit sequence - correct, in order delivery |
| Basic Service of Physical Layer: Transport Bits | |
| A Bit-to-Signal Conversion Rule | |
| Example: Transmit Bit Pattern for Character "b" | |
| What Arrives at the Receiver? | |
| Some Background: Fourier Analysis | |
| Fourier Analysis - Computing Coefficients | |
| Applying Fourier Analysis to the Example (1) | |
| Applying Fourier Analysis to the Example (2) | |
| Fact 1: Signals are Attenuated in a Phsical Medium | |
| Fact 2: Not all Frequencies Pass Through a Medium | |
| Bandwidth-Limited Medium - Example | |
| Fact 3: Attenuation Depends on Frequency | |
| Example with Frequency-Dependent Attenuation | |
| Fact 4: Media does not only Attenuate, but also Distorts | |
| Example with Frequency-Dependent Attenuation and Jitter | |
| Fact 5: Real Media are Noisy | - A physical medium, in combination with the receiver, exhibits random (thermal) noise -> Fluctations in the receiver circuitry, interference from nearby transmissions, etc. - Materializes as random fluctuations around the (noise-free) received signal -> Typical model: noise as a Gaussian random variable of zero mean, uncorrelated in time -> More sophisticated model exists |
| Example w/ Frequency-Dependent Attenuation, Jitter & Random Noise | |
| Converting Signals to Data: Sampling | |
| Sampling Over a Noisy or Bandwidth-Limited Channel | |
| Sampling & Low Bandwidth | |
| Possible Way Out: Make Thresholds Wider? | |
| Way Out 2: Increase Time for a Single Bit | |
| Way Out 3: Use More Than Just 0 and 1 in the Channel | |
| Way Out 3: Use Four-Level Symbols to Encode Two Bits | |
| Data Rate with Multi-Valued Symbols - Nyquist | |
| Unlimited Data Rate with Many Symbol Levels? | - Nyquist's theorem appears to indicate that unlimited data rate can be archived when only enough symbol levels are used - is this plausible? - more and more symbol levels have to be spaced closer and closer together - what then about noise? -> even small random noise would then result in one symbol being misinterpreted for another - So not unlimited? |
| Shannon Limit on Achievable Data Rate | |
| When to Sample the Received Signal? - How does the receiver know WHEN to check the received signal for its value? | - One typical convention: in the middle of each symbol - But when does a symbol start? -> The length of a symbol is usually known by convention via the symbol rate |
| When to Sample the Received Signal? | - The reveicer has to be synchronized with the sendere at the bit level -> the link layer will have to deal with fram synchronization -> there is also "character" synchronization - omitted here |
| Overly Simplistic Bit Sychronization | |
| Options to Tell the Receiver when to Sample (1 - Clock) | - Rely on clock synchonization does not work - Provide and explicit clock signal -> needs parallel transmission over some additional channel -> must be in sync with the actual data, otherwise pointless => usefull only for short-range communication |
| Options to Tell the Reciver When to Sample (2 - Points) | - Synchronize the receiver at curcial points (e.g. start of a character or of a block) -> otherwise, let the receiver clock run freely -> relies on short-term stability of clock generators (do not diverge too quickly) |
| Options to Tell the Receiver When to Sample (3 - extract) | - Exctract clock information from the received signal itself |
| Extract Clock Information from Signal Itself - NRZ-L | |
| Extract Clock Information from Signal Itself - Manchester | |
| Baseband versus Broadband Transmission (Baseband transmission) | - directly puts the digital symbol sequences onto the wirse - at different levels of current, voltage, ... essentially, direct current (DC) is used for signaling |
| Baseband versus Broadband Transmission (Baseband transmission - Problems) | - limited bandwidth reshapes the signal at receiver - attenuation and sitortion depend on frequency and baseband transmissions have many different frequencies because of their wide Fourier spectrum |
| Boardband Transmission | |
| Amplitude Modulation | |
| Amplitude Modulation - Example | |
| Frequency Modulation | |
| Phase Modulation | |
| Phase Modulation With High Multiple Values per Symbol | |
| Combinations of Different Modulations | |
| Interlude: Digital vs Analog Signals | |
| Electromagnetic Spectrum and Media |
Want to create your own Flashcards for free with GoConqr? Learn more.