Post on 16-Oct-2015
Network Communication Architecture and ProtocolsA network architecture is a blueprint of the complete computer communication network, which provides a framework and technology foundation for designing, building and managing a communication network. It typically has a layered structure. Layering is a modern network design principle which divides the communication tasks into a numbers of smaller parts, each part accomplishing a particular sub-task and interacting with the other parts in a small number of well-defined ways. Layering allows the parts of a communication to be designed and tested without a combinatorial explosion of cases, keeping each design relatively simple.If a network architecture is open, no single vendor owns the technology and controls its definition and development. Anyone is free to design hardware and software based on the network architecture. The TCP/IP network architecture, which the Internet is based on, is such an open network architecture and it is adopted as a worldwide network standard and widely deployed in local area network (LAN), wide area network (WAN), small and large enterprises, and last but not the least, the Internet.Open Systems Interconnection (OSI) network architecture, developed by International Organization for Standardization (ISO), is an open standard for communication in the network across different equipment and applications by different vendors. Though not widely deployed, the OSI 7 layer model is considered the primary network architectural model for inter-computing and inter-networking communications.In addition to the OSI network architecture model, there exist other network architecture models by many vendors, such as IBM SNA (Systems Network Architecture), Digital Equipment Corporation (DEC; now part of HP) DNA (Digital Network Architecture), Apple computers AppleTalk, and Novells NetWare. Actually, the TCP/IP architecture does not exactly match the OSI model. Unfortunately, there is no universal agreement regarding how to describe TCP/IP with a layered model. It is generally agreed that TCP/ IP has fewer levels (from three to five layers) than the seven layers of the OSI model. Network architecture provides only a conceptual framework for communications between computers. The model itself does not provide specific methods of communication. Actual communication is defined by various communication protocols.
Network Protocol: Definition and OverviewThe OSI model, and any other network communication model, provide only a conceptual framework for communication between computers, but the model itself does not provide specific methods of communication. Actual communication is defined by various communication protocols. In the context of data communication, a protocol is a formal set
1
of rules, conventions and data structure that governs how computers and other network devices exchange information over a network. In other words, a protocol is a standard procedure and format that two data communication devices must understand, accept and use to be able to talk to each other.In modern protocol design, protocols are layered according to the OSI 7 layer model or a similar layered model. Layering is a design principle which divides the protocol design into a number of smaller parts, each part accomplishing a particular sub-task, and interacting with the other parts of the protocol only in a small number of well-defined ways. Layering allows the parts of a protocol to be designed and tested without a combinatorial explosion of cases, keeping each design relatively simple. Layering also permits familiar protocols to be adapted to unusual circumstances.
Protocols we will study in this research can be divided into three main Groups:
2
(1) TCP / IP Protocols (Internet Protocols) IP | IPv6 | TCP | UDP | others |
(2) VoIP Protocols (Telephone Protocols) H.323 | MGCP | SIP |Skinny | others |
(3) Cellular Protocols (Mobile Protocols) UMTS | GPRS | CDMA | CDMA2000 |GSM | WAP | others |
3
TCP / IPThe TCP/IP protocol suite establishes the technical foundation of the Internet. Development of
the TCP/IP started as DOD projects. Now, most protocols in the suite are developed by the
Internet Engineering Task Force (IETF) under the Internet Architecture Board (IAB), an
organization initially sponsored by the US government and now an open and autonomous
organization. The IAB provides the coordination for the R&D underlying the TCP/IP protocols
and guides the evolution of the Internet. The TCP/IP protocols are well documented in the
Request For Comments (RFC), which are drafted, discussed, circulated and approved by the
IETF committees. All documents are open and free and can be found online in the IETF site
listed in the reference.
TCP/IP architecture does not exactly match the OSI model. Unfortunately, there is no universal
agreement regarding how to describe TCP/IP with a layered model. It is generally agreed that
TCP/IP has fewer levels (from three to five layers) than the seven layers of the OSI model. In
this document, we force TCP/IP protocols into the OSI 7 layers structure for comparison
purpose.
The TCP/IP suites core functions are addressing and routing (IP/IPv6 in the networking layer)
and transportation control (TCP, UDP in the transport layer).
IP - Internet Protocol Addressing of network components is a critical issue for information
routing and transmission in network communications. Each technology has its own convention
for transmitting messages between two machines within the same network. On a LAN, messages
are sent between machines by supplying the six bytes unique identifier (the MAC address). In
an SNA network, every machine has Logical Units with their own network addresses. DECNET,
AppleTalk, and Novell IPX all have a scheme for assigning numbers to each local network and to
each workstation attached to the network.
On top of these local or vendor specific network addresses, IP assigns a unique number to every
network device in the world, which is called an IP address. This IP address is a four-byte value
in IPv4 that, by convention, is expressed by converting each byte into a decimal number (0 to
255) and separating the bytes with a period. In IPv6, the IP address has been increased to 16
bytes. Details of the IP and IPv6 protocols are presented in separate documents.
TCP - Transmission Control Protocol TCP provides a reliable stream delivery and virtual
connection service to applications through the use of sequenced acknowledgment with
retransmission of packets when necessary. TCP provides stream data transfer, transportation
reliability, efficient flow control, full-duplex operation, and multiplexing. Check the TCP section
4
for more details. In the follwoing TCP/IP protocol stack table, we list all the protocols according
to their functions in mapping to the OSI 7 layers network communication reference model.
However, the TCP/IP architecture does not follow the OSI model closely, for example, most
TCP/IP applications directly run on top of the transport layer protocols, TCP and UDP, without
the presentation and session layers in between.
TCP/IP Protocol Stack
OSI Network Architecture 7 Layers ModelOpen Systems Interconnection (OSI) model is a reference model developed by ISO (International
Organization for Standardization) in 1984, as a conceptual framework of standards for
communication in the network across different equipment and applications by different vendors.
It is now considered the primary architectural model for inter-computing and internetworking
communications. Most of the network communication protocols used today have a structure
based on the OSI model. The OSI model defines the communications process into 7 layers,
dividing the tasks involved with moving information between networked computers into seven
smaller, more manageable task groups. A task or group of tasks is then assigned to each of the
seven OSI layers. Each layer is reasonably self-contained so that the tasks assigned to each
layer can be implemented independently. This enables the solutions offered by one layer to be
updated without adversely affecting the other layers.
The OSI 7 layers model has clear characteristics at each layer. Basically, layers 7 through 4
deal with end-to-end communications between data source and destinations, while layers 3 to 1
deal with communications between network devices. On the other hand, the seven layers of the
OSI model can be divided into two groups: upper layers (layers 7, 6 & 5) and lower layers
(layers 4, 3, 2, 1). The upper layers of the OSI model deal with application issues and generally
are implemented only in software. The highest layer, the application layer, is closest to the end
user. The lower layers of the OSI model handle data transport issues. The physical layer and the
data link layer are implemented in hardware and software. The lowest layer, the physical layer,
is closest to the physical network medium (the wires, for example) and is responsible for placing
data on the medium.
5
Protocols according to OSI Network Architecture layers :
i- Data Link Layer
ii- Network Layer
iii- Transport Layer
iv- Session Layer
v- Application Layer
vi- Routing
vii- Tunneling
viii- Security
Data Link Layer
ARP/RARP
DCAPAddress Resolution Protocol/Reverse Address
Data Link Switching Client Access Protocol
Network Layer
6
DHCP
DVMRP
ICMP/ICMPv6
IGMP
IP
IPv6
MARS
PIM
RIP2
RIPng for IPv6
RSVP
VRRP
Dynamic Host Configuration Protocol
Distance Vector Multicast Routing Protocol
Internet Control Message Protocol
Internet Group Management Protocol
Internet Protocol version 4
Internet Protocol version 6
Multicast Address Resolution Server
Protocol Independent Multicast-Sparse Mode (PIM-SM)
Routing Information Protocol
Routing Information Protocol for IPv6
Resource ReSerVation setup Protocol
Virtual Router Redundancy Protocol
Transport Layer
ISTP
Mobile IP
RUDP
TALI
TCP
UDP
Van Jacobson
XOT
Mobile IP Protocol
Reliable UDP
Transport Adapter Layer Interface
Transmission Control Protocol
User Datagram Protocol
compressed TCP
X.25 over TCP
Session Layer
BGMP
Diameter
DIS
DNS
ISAKMP/IK
E
iSCSI
LDAP
MZAP
NetBIOS/IP
Border Gateway Multicast Protocol
Distributed Interactive Simulation
Domain Name Service
Internet Security Association and Key Management Protocol and Internet Key
Exchange Protocol
Small Computer Systems Interface
Lightweight Directory Access Protocol
Multicast-Scope Zone Announcement Protocol
NetBIOS/IP for TCP/IP Environment
Application Layer Protocols
7
COPS
FANP
Finger
FTP
HTTP
IMAP4
IMPPpre/IMPPmes
IPDC
IRC
ISAKMP
ISP
NTP
POP3
Radius
RLOGIN
RTSP
SCTP
S-HTTP
SLP
SMTP
SNMP
SOCKS
TACACS+
TELNET
TFTP
WCCP
X-Window
Common Open Policy Service
Flow Attribute Notification Protocol
User Information Protocol
File Transfer Protocol
Hypertext Transfer Protocol
Internet Message Access Protocol rev 4
Instant Messaging and Presence Protocols
IP Device Control
Internet Relay Chat Protocol
Internet Message Access Protocol version 4rev1
Network Time Protocol
Post Office Protocol version 3
Remote Authentication Dial In User Service
Remote Login
Real-time Streaming Protocol
Stream Control Transmision Protocol
Secure Hypertext Transfer Protocol
Service Location Protocol
Simple Mail Transfer Protocol
Simple Network Management Protocol
Socket Secure (Server)
Terminal Access Controller Access Control System
TCP/IP Terminal Emulation Protocol
Trivial File Transfer Protocol
Web Cache Coordination Protocol
X Window
Routing
BGP-4
EGP
EIGRP
HSRP
IGRP
NARP
NHRP
OSPF
TRIP
Border Gateway Protocol
Exterior Gateway Protocol
Enhanced Interior Gateway Routing Protocol
Cisco Hot Standby Router Protocol
Interior Gateway Routing
NBMA Address Resolution Protocol
Next Hop Resolution Protocol
Open Shortest Path First
Telephony Routing over IP
8
Tunneling
ATMP
L2F
L2TP
PPTP
Ascend Tunnel Management Protocol
The Layer 2 Forwarding Protocol
Layer 2 Tunneling Protocol
Point to Point Tunneling Protocol
Security
AH
ESP
TLS
Authentication Header
Encapsulating Security Payload
Transport Layer Security Protocol
Protocols Within Layers s Map
9
IP ProtocolThe Internet Protocol (IP), is the routing layer datagram service of the TCP/IP suite. All other protocols within the TCP/IP suite, except ARP and RARP, use IP to route frames from host to host. The IP frame header contains routing information and control information associated with datagram delivery.The IP header structure is as follows:
4 8 16 32 bits
Ver. IHL Type of service Total length
10
Identification Flags Fragment offset
Time to live Protocol Header checksum
Source address
Destination address
Option + Padding
Data
IP header structureVersionVersion field indicates the format of the Internet header.IHL [International Hockey League]Internet header length is the length of the Internet header in 32-bit words. Points to the beginning of the data. The minimum value for a correct header is 5.Type of serviceIndicates the quality of service desired. Networks may offer service precedence, meaning that they accept traffic only above a certain precedence at times of high load. There is a three-way trade-off between low delay, high reliability and high throughput.
Bits 0-2: Precedence
111 Network control.
110 Internetwork control.
101 CRITIC/ECP.
100 Flash override.
011 Flash.
11
010 Immediate.
001 Priority.
000 Routine.
Bit 3: Delay
0 Normal delay.
1 Low delay.
Bit 4: Throughput
0 Normal throughput.
1 High throughput.
Bit 5: Reliability
0 Normal reliability.
1 High reliability.
Bits 6-7: Reserved for future use.Total lengthLength of the datagram measured in bytes, including the Internet header and data. This field allows the length of a datagram to be up to 65,535 bytes, although such long datagrams are impractical for most hosts and networks. All hosts must be prepared to accept datagrams of up to 576 bytes, regardless of whether they arrive whole or in fragments. It is recommended that hosts send datagrams larger than 576 bytes only if the destination is prepared to accept the larger datagrams.IdentificationIdentifying value assigned by the sender to aid in assembling the fragments of a datagram.Flags3 bits. Control flags:Bit 0 is reserved and must be zeroBit 1: Dont fragment bit:
12
0 May fragment.
1 Dont fragment.
Bit 2: More fragments bit:
0 Last fragment.
1 More fragments.
Fragment offset13 bits. Indicates where this fragment belongs in the datagram. The fragment offset is measured in units of 8 bytes (64 bits). The first fragment has offset zero.Time to liveIndicates the maximum time the datagram is allowed to remain in the Internet system. If this field contains the value zero, the datagram must be destroyed. This field is modified in Internet header processing. The time is measured in units of seconds. However, since every module that processes a datagram must decrease the TTL by at least one (even if it processes the datagram in less than 1 second), the TTL must be thought of only as an upper limit on the time a datagram may exist. The intention is to cause undeliverable datagrams to be discarded and to bound the maximum datagram lifetime.ProtocolIndicates the next level protocol used in the data portion of the Internet datagram.Header checksumA checksum on the header only. Since some header fields change, e.g., Time To Live, this is recomputed and verified at each point that the Internet header is processed.Source address / destination address32 bits each. A distinction is made between names, addresses and routes. A nameindicates an object to be sought. An address indicates the location of the object. A routeindicates how to arrive at the object. The Internet protocol deals primarily with addresses. It is the task of higher level protocols (such as host-to-host or application) to make the mapping from names to addresses. The Internet module maps Internet addresses to local net addresses. It is the task of lower level procedures (such as local net or gateways) to make the mapping from local net addresses to routes.OptionsOptions may or may not appear in datagrams. They must be implemented by all IP modules (host and gateways). What is optional is their transmission in any particular datagram, not their implementation. In some environments, the security option may be required in all datagrams.The option field is variable in length. There may be zero or more options. There are two possible formats for an option:
A single octet of option type. An option type octet, an option length octet and the actual option data octets.
The length octet includes the option type octet and the actual option data octets.The option type octet has 3 fields:1 bit: Copied flag. Indicates that this option is copied into all fragments during fragmentation:
0 Copied.
13
1 Not copied.
2 bits: Option class
0 Control.
1 Reserved for future use.
2 Debugging and measurement.
3 Reserved for future use.
5 bits: Option number.
IPv6 ProtocolIP version 6 (IPv6) is a new version of the Internet Protocol based on IPv4. IPv4 and IPv6 are demultiplexed at the media layer. For example, IPv6 packets are carried over Ethernet with the content type 86DD (hexadecimal) instead of IPv4s 0800.IPv6 increases the IP address size from 32 bits to 128 bits, to support more levels of addressing hierarchy, a much greater number of addressable nodes and simpler auto-configuration of addresses. Scalability of multicast addresses is introduced. A new type of address called an anycast address is also defined, to send a packet to any one of a group of nodes.Improved support for extensions and options - IPv6 options are placed in separate headers that are located between the IPv6 header and the transport layer header. Changes in the way IP header options are encoded allow more efficient forwarding, less stringent limits on the length of options, and greater flexibility for introducing new options in the future. The extension headers are: Hop-by-Hop Option, Routing (Type 0), Fragment, Destination Option, Authentication, Encapsulation Payload.Flow labeling capability - A new capability has been added to enable the labeling of packets belonging to particular traffic flows for which the sender requests special handling, such as non-default Quality of Service or real-time service.The IPv6 header structure is as follows:
4 4 16 24 32 bits
14
Ver. Priority Flow label
Payload length
Next header Hop limit
Source address(128 Bits)
Destination address(128 bits)
IPv6 header structureVersionInternet Protocol Version number (IPv6 is 6).PriorityEnables a source to identify the desired delivery priority of the packets. Priority values are divided into ranges: traffic where the source provides congestion control and non-congestion control traffic.Flow labelUsed by a source to label those products for which it requests special handling by the IPv6 router. The flow is uniquely identified by the combination of a source address and a non-zero flow label.Payload lengthLength of payload (in octets).Next headerIdentifies the type of header immediately following the IPv6 header.Hop limit8-bit integer that is decremented by one by each node that forwards the packet. The packet is discarded if the Hop Limit is decremented to zero.Source address128-bit address of the originator of the packet.Destination address128-bit address of the intended recipient of the packet.
15
TCP ProtocolTransmission Control Protocol (TCP). TCP provides a reliable stream delivery and virtual connection service to applications through the use of sequenced acknowledgment with retransmission of packets when necessary.The TCP header structure is as follows:
16 32 bits
Source port
Destination port
Sequence number
Acknowledgement number
Offset Resrvd U A P R S F Window
Checksum
Urgent pointer
Option + Padding
Data
TCP header structureSource portSource port number.Destination portDestination port number.Sequence numberThe sequence number of the first data octet in this segment (except when SYN is present). If SYN is present, the sequence number is the initial sequence number (ISN) and the first data octet is ISN+1.
16
Acknowledgment numberIf the ACK control bit is set, this field contains the value of the next sequence number which the sender of the segment is expecting to receive. Once a connection is established, this value is always sent.Data offset4 bits. The number of 32-bit words in the TCP header, which indicates where the data begins. The TCP header (even one including options) has a length which is an integral number of 32 bits.Reserved6 bits. Reserved for future use. Must be zero.Control bits6 bits. The control bits may be (from right to left):
U (URG) Urgent pointer field significant.
A (ACK) Acknowledgment field significant.
P (PSH) Push function.
R (RST) Reset the connection.
S (SYN) Synchronize sequence numbers.
F (FIN) No more data from sender.
Window16 bits. The number of data octets which the sender of this segment is willing to accept, beginning with the octet indicated in the acknowledgment field.Checksum16 bits. The checksum field is the 16 bit ones complement of the ones complement sum of all 16-bit words in the header and text. If a segment contains an odd number of header and text octets to be checksummed, the last octet is padded on the right with zeros to form a 16-bit word for checksum purposes. The pad is not transmitted as part of the segment. While computing the checksum, the checksum field itself is replaced with zeros.Urgent Pointer16 bits. This field communicates the current value of the urgent pointer as a positive offset from the sequence number in this segment. The urgent pointer points to the sequence number of the octet following the urgent data. This field can only be interpreted in segments for which the URG control bit has been set.OptionsOptions may be transmitted at the end of the TCP header and always have a length which is a multiple of 8 bits. All options are included in the checksum. An option may begin on any octet boundary.
There are two possible formats for an option:
A single octet of option type. An octet of option type, an octet of option length, and the actual option data octets.
17
The option length includes the option type and option length, as well as the option data octets.
The list of options may be shorter than that designated by the data offset field because the contents of the header beyond the End-of-Option option must be header padding i.e., zero.A TCP must implement all options.
DataTCP data or higher layer protocol.
UDP ProtocolThe User Datagram Protocol (UDP), defined by IETF RFC768, provides a simple, but unreliable message service for transaction-oriented services. Each UDP header carries both a source port identifier and destination port identifier, allowing high-level protocols to target specific applications and services among hosts.The UDP header structure is shown as follows:
16 32 bits
Source port Destination port
Length Checksum
Data
UDP header structureSource portSource port is an optional field. When used, it indicates the port of the sending process and may be assumed to be the port to which a reply should be addressed in the absence of any other information. If not used, a value of zero is inserted.Destination portDestination port has a meaning within the context of a particular Internet destination address.LengthThe length in octets of this user datagram, including this header and the data. The minimum value of the length is eight.ChecksumThe 16-bit ones complement of the ones complement sum of a pseudo header of information from the IP header, the UDP header and the data, padded with zero octets at the end (if necessary) to make a multiple of two octets.
18
DataUDP data field.
The OSI Seven-Layer Model - ConclusionIn conclusion, A network is any two or more entities -- be they people, organizations, machines,
or whatever -- that:
Need to share a resource (in computer geekspeak referred to as services),
Have a pathway for contacting one another (referred to as transmission media), and
Have rules for using their common pathway to communicate about the sharing of resources (referred to as protocols).
Before a network can be effective, participants must have clearly established these three things.
In computer networking, fortunately, the services, transmission media, and protocols have long
since been codified so that the uninitiated can quickly master the concepts.
Since 1977, the International Standards Organization (ISO) has promulgated the Open Systems
Interconnection (OSI) Reference Model. The OSI seven-layer model, as it has come to be known,
consists of (get this!) seven layers:
Application (Layer 7)
Presentation (Layer 6)
Session (Layer 5)
Transport (Layer 4)
Network (Layer 3)
Data Link (Layer 2)
Physical (Layer 1)
The seven layers collectively are often referred to as a protocol stack, although in actuality only
the transport and higher layers deal directly with protocols, per se.
Each layer is responsible for specific functions of network communications. It is important to
note, however, that the model is theoretical; actual network operating systems (NOSs) handle
the practical implementation of each of these theoretical functions in different ways.
Nevertheless, the model does help clarify the relationships and define the interactions the
multiple protocol stacks of the various NOSs have to and with one another.
In networking, each layer in a computer's protocol stack communicates with the corresponding
layers in other computers' stacks. This works both horizontally and vertically:
As data is passed from the Transport layer in one computer, it is received and interpreted by the Transport layer in other computers. However,
To get to the corresponding layers in other computers, the data must pass down through the other layers of the originating computer and up through the lower layers of the
receiving computers. As the data is handed down to lower layers, each layer adds
instructions and other information (called a header) to the beginning of the data. Then, as
the data arrives at each layer of the receiving computer, the corresponding headers are
19
stripped off and any instructions are carried out before the data is handed up to the next
layer.
Voice Over IPDescription Voice over IP (VOIP) uses the Internet Protocol (IP) to transmit voice as packets
over an IP network. Using VOIP protocols, voice communications can be achieved on any IP
network regardless whether it is Internet, Intranet or Local Area Networks (LAN). In a VOIP
enabled network, the voice signal is digitized, compressed and converted to IP packets and then
transmitted over the IP network. VOIP signaling protocols are used to set up and tear down
calls, carry information required to locate users and negotiate capabilities. The key benefits of
Internet telephony (Voice over IP) are the very low cost, the integration of data, voice and video
on one network, the new services created on the converged network and simplified management
of end user and terminals.
SignalingH.323 H.323
Megaco H.248 Gateway Control Protocol
MGCP Media Gateway Control Protocol
RVP over IP Remote Voice Protocol Over IP Specification
SAPv2 Session Announcement Protocol
SGCP Simple Gateway Control Protocol
SIP Session Initiation Protocol
Skinny Skinny Client Control Protocol (Cisco)
MediaDVB Digital Video Broadcasting
H.261 Video stream for transport using the real-time transport
H.263 Bitstream in the Real-time Transport Protocol
20
RTCP RTP Control protocol
RTP Real-Time Transport
H.323 ProtocolH.225 Covers narrow-band visual telephone services
H.225 Annex G
H.225E
H.235 Security and authentication
H.323SET
H.245 Negotiates channel usage and capabilities
H.450.1 Series defines Supplementary Services for H.323
H.450.2 Call Transfer supplementary service for H.323
H.450.3 Call diversion supplementary service for H.323
H.450.4 Call Hold supplementary service
H.450.5 Call Park supplementary service
H.450.6 Call Waiting supplementary service
H.450.7Message Waiting Indication supplementary
service
H.450.8Calling Party Name Presentation supplementary
service
H.450.9 Completion of Calls to Busy Subscribers
supplementary service
H.450.10 Call Offer supplementary service
H.450.11 Call Intrusion supplementary service
H.450.12 ANF-CMN supplementary service
RAS Manages registration, admission, status
T.38 IP-based fax service maps
T.125Multipoint Communication Service Protocol
(MCS).
21
The H.323 standard provides a foundation for audio, video, and data communications across IP-
based networks, including the Internet. H.323 is an umbrella recommendation from the International
Telecommunications Union (ITU) that sets standards for multimedia communications over Local
Area Networks (LANs) that do not provide a guaranteed Quality of Service (QoS). These networks
dominate todays corporate desktops and include packet-switched TCP/IP and IPX over Ethernet,
Fast Ethernet and Token Ring network technologies. Therefore, the H.323 standards are important
building blocks for a broad new range of collaborative, LAN-based applications for multimedia
communications. It includes parts of H.225.0 - RAS, Q.931, H.245 RTP/RTCP and audio/video
codecs, such as the audio codecs (G.711, G.723.1, G.728, etc.) and video codecs (H.261, H.263)
that compress and decompress media streams.
Media streams are transported on RTP/RTCP. RTP carries the actual media and RTCP carries
status and control information. The signalling is transported reliably over TCP. The following
protocols deal with signalling:
The H.323 suite is illustrated here in relation to the OSI model
22
MGCP Protocol
23
Media Gateway Control Protocol (MGCP) is used for controlling telephony gateways from external
call control elements called media gateway controllers or call agents. A telephony gateway is a
network element that provides conversion between the audio signals carried on telephone circuits
and data packets carried over the Internet or over other packet networks.
MGCP assumes a call control architecture where the call control intelligence is outside the
gateways and handled by external call control elements. The MGCP assumes that these call control
elements, or Call Agents, will synchronize with each other to send coherent commands to the
gateways under their control. MGCP is, in essence, a master/slave protocol, where the gateways
are expected to execute commands sent by the Call Agents.
The MGCP implements the media gateway control interface as a set of transactions. The
transactions are composed of a command and a mandatory response. There are eight types of
commands:
MGCP Commands
MGC --> MG CreateConnection: Creates a connection between two endpoints;
uses SDP to define the receive capabilities of the paricipating
endpoints.
MGC --> MG ModifyConnection: Modifies the properties of a connection; has
nearly the same parameters as the CreateConnection command.
MGC MG DeleteConnection: Terminates a connection and collects
statistics on the execution of the connection.
MGC --> MG NotificationRequest: Requests the media gateway to send
notifications on the occurrence of specified events in an
endpoint.
MGC MG AuditEndpoint: Determines the status of an endpoint.
MGC --> MG AuditConnection: Retrieves the parameters related to a
connection.
MGC
from the session description by an empty line.
MGCP uses a transaction identifier to correlate commands and responses. Transaction identifiers
have values between 1 and 999999999. An MGCP entity cannot reuse a transaction identifier
sooner than 3 minutes after completion of the previous command in which the identifier was used.
The command header is composed of:
A command line, identifying the requested action or verb, the transaction identifier, the endpoint towards which the action is requested, and the MGCP protocol version,
A set of parameter lines, composed of a parameter name followed by a parameter value.The command line is composed of:
Name of the requested verb. Transaction identifier correlates commands and responses. Values may be between 1 and
999999999. An MGCP entity cannot reuse a transaction identifier sooner than 3 minutes
after completion of the previous command in which the identifier was used.
Name of the endpoint that should execute the command (in notifications, the name of the endpoint that is issuing the notification).
Protocol version.These four items are encoded as strings of printable ASCII characters, separated by white spaces,
i.e., the ASCII space (0x20) or tabulation (0x09) characters. It is recommended to use exactly one
ASCII space separator.
SIP ProtocolSession Initiation Protocol (SIP) is a application layer control simple signalling protocol for VoIP
implementations using the Redirect Mode.
SIP is a textual client-server base protocol and provides the necessary protocol mechanisms so
that the end user systems and proxy servers can provide different services:
1. Call forwarding in several scenarios: no answer, busy , unconditional, address manipulations (as 700, 800 , 900- type calls).
2. Callee and calling number identification3. Personal mobility4. Caller and callee authentication5. Invitations to multicast conference6. Basic Automatic Call Distribution (ACD)
SIP addresses (URL) can be embedded in Web pages and therefore can be integrated as part of
powerful implementations (Click to talk, for example).
SIP using simple protocol structure, provides the market with fast operation, flexibility, scalability
and multiservice support.
25
SIP provides its own reliability mechanism. SIP creates, modifies and terminates sessions with one
or more participants. These sessions include Internet multimedia conferences, Internet telephone
calls and multimedia distribution. Members in a session can communicate using multicast or using a
mesh of unicast relations, or a combination of these. SIP invitations used to create sessions carry
session descriptions which allow participants to agree on a set of compatible media types. It
supports user mobility by proxying and redirecting requests to the user's current location. Users
can register their current location. SIP is not tied to any particular conference control protocol. It
is designed to be independent of the lower-layer transport protocol and can be extended with
additional capabilities.
SIP transparently supports name mapping and redirection services, allowing the implementation of
ISDN and Intelligent Network telephony subscriber services. These facilities also enable personal
mobility which is based on the use of a unique personal identity
SIP supports five facets of establishing and terminating multimedia communications:
User location
User capabilities
User availability
Call setup
Call handling.
SIP can also initiate multi-party calls using a multipoint control unit (MCU) or fully-meshed
interconnection instead of multicast. Internet telephony gateways that connect Public Switched
Telephone Network (PSTN) parties can also use SIP to set up calls between them.
SIP is designed as part of the overall IETF multimedia data and control architecture currently
incorporating protocols such as RSVP, RTP RTSP, SAP and SDP. However, the functionality and
operation of SIP does not depend on any of these protocols.
SIP can also be used in conjunction with other call setup and signalling protocols. In that mode, an
end system uses SIP exchanges to determine the appropriate end system address and protocol
from a given address that is protocol-independent. For example, SIP could be used to determine
that the party can be reached using H.323 to find the H.245 gateway and user address and then use
H.225.0 to establish the call.
SIP Operation
Sip works as follows:
Callers and callees are identified by SIP addresses. When making a SIP call, a caller first locates
the appropriate server and then sends a SIP request. The most common SIP operation is the
invitation. Instead of directly reaching the intended callee, a SIP request may be redirected or may
trigger a chain of new SIP requests by proxies. Users can register their location(s) with SIP
servers.
SIP messages can be transmitted either over TCP or UDP
SIP messages are text based and use the ISO 10646 character set in UTF-8 encoding. Lines must
be terminated with CRLF. Much of the message syntax and header field are similar to HTTP.
Messages can be request messages or response messages.
Protocol header structure.
The protocol is composed of a start line, message header, an empty line and an optional message
body.
Request Messages
The format of the Request packet header is shown in the following illustration:
Method Request URI SIP version
SIP request packet structureMethod
26
The method to be performed on the resource. Possible methods are Invite, Ack, Options, Bye,
Cancel, Register
Methods Command FunctionINVITE Initiate CallACK Confirm final responseBYE Terminate and transfer callCANCEL Cancel searches and "ringing"OPTIONS Features support by other sideREGISTER Register with location service
Request-URIA SIP URL or a general Uniform Resource Identifier, this is the user or service to which this
request is being addressed.
SIP versionThe SIP version being used; this should be version 2.0
Response Message
The format of the Response message header is shown in the following illustration:
SIP version Status code Reason phrase
SIP response packet structure
Response Codes
Response Code Prefix Function1xx Searching, ringing, queuing
2xx Success
3xx Fowarding
4xx Client mistakes
5xx Server failures
6xx Busy, refuse, not available anywhere
SIP versionThe SIP version being used.
Status-codeA 3-digit integer result code of the attempt to understand and satisfy the request.Reason-phraseA textual description of the status code.
Skinny ProtocolCisco protocol
Skinny Client Control Protocol (SCCP). Telephony systems are moving to a common wiring plant. The end
station of a LAN or IP- based PBX must be simple to use, familiar and relatively cheap. The H.323
recommendations are quite an expensive system. An H.323 proxy can be used to communicate with the
Skinny Client using the SCCP. In such a case the telephone is a skinny client over IP, in the context of
H.323. A proxy is used for the H.225 and H.245 signalling.
27
The skinny client (i.e. an Ethernet Phone) uses TCP/IP to transmit and receive calls and RTP/UDP/IP
to/from a Skinny Client or H.323 terminal for audio. Skinny messages are carried above TCP and use port
2000.
The messages consist of Station message ID messages.
They can be of the following types:
Code Station Message ID Message
0x0000 Keep Alive Message
0x0001 Station Register Message
0x0002 Station IP Port Message
0x0003 Station Key Pad Button Message
0x0004 Station Enbloc Call Message
0x0005 Station Stimulus Message
0x0006 Station Off Hook Message
0x0007 Station On Hook Message
0x0008 Station Hook Flash Message
0x0009 Station Forward Status Request Message
0x11 Station Media Port List Message
0x000A Station Speed Dial Status Request Message
0x000B Station Line Status Request Message
0x000C Station Configuration Status Request Message
0x000D Station Time Date Request Message
0x000E Station Button Template Request Message
0x000F Station Version Request Message
0x0010 Station Capabilities Response Message
0x0012 Station Server Request Message
0x0020 Station Alarm Message
0x0021 Station Multicast Media Reception Ack Message
0x0024 Station Off Hook With Calling Party Number Message
0x22 Station Open Receive Channel Ack Message
0x23 Station Connection Statistics Response Message
0x25 Station Soft Key Template Request Message
0x26 Station Soft Key Set Request Message
0x27 Station Soft Key Event Message
0x28 Station Unregister Message
0x0081 Station Keep Alive Message
0x0082 Station Start Tone Message
0x0083 Station Stop Tone Message
0x0085 Station Set Ringer Message
0x0086 Station Set Lamp Message
0x0087 Station Set Hook Flash Detect Message
0x0088 Station Set Speaker Mode Message
0x0089 Station Set Microphone Mode Message
0x008A Station Start Media Transmission
0x008B Station Stop Media Transmission
28
0x008F Station Call Information Message
0x009D Station Register Reject Message
0x009F Station Reset Message
0x0090 Station Forward Status Message
0x0091 Station Speed Dial Status Message
0x0092 Station Line Status Message
0x0093 Station Configuration Status Message
0x0094 Station Define Time & Date Message
0x0095 Station Start Session Transmission Message
0x0096 Station Stop Session Transmission Message
0x0097 Station Button Template Message
0x0098 Station Version Message
0x0099 Station Display Text Message
0x009A Station Clear Display Message
0x009B Station Capabilities Request Message
0x009C Station Enunciator Command Message
0x009E Station Server Respond Message
0x0101 Station Start Multicast Media Reception Message
0x0102 Station Start Multicast Media Transmission Message
0x0103 Station Stop Multicast Media Reception Message
0x0104 Station Stop Multicast Media Transmission Message
0x105 Station Open Receive Channel Message
0x0106 Station Close Receive Channel Message
0x107 Station Connection Statistics Request Message
0x0108 Station Soft Key Template Respond Message
0x109 Station Soft Key Set Respond Message
0x0110 Station Select Soft Keys Message
0x0111 Station Call State Message
0x0112 Station Display Prompt Message
0x0113 Station Clear Prompt Message
0x0114 Station Display Notify Message
0x0115 Station Clear Notify Message
0x0116 Station Activate Call Plane Message
0x0117 Station Deactivate Call Plane Message
0x118 Station Unregister Ack Message
29
DVB ProtocolCertain implementations suitable for Digital Video Broadcasting (DVB) broadcasting systems are supported
by CATV infrastructures. Specifically, implementations of the Return Channel for interactive services are
supported by CATV.
DVB involves a standard link.
The format of the DVB packet is shown in the following illustration:
Mpeg Header (4) Upstream Marker (3)
Slot Number(2)
MAC Flag Control (3)
MAC Flags(26)
Ext. Flags(26)
MAC Message(40)
MAC Message(40)
MAC Message(40)
Rsrvc.(40)
DVB packet structure
Mpeg Header4 byte Mpeg-2 transport stream header as defined in ISO 13818-1 with a specific PID designated for MAC
messages. The value of this PID is 0 x 1C. The transport scrambling control field of the MPEG header is
set to 00.
Upstream Marker24 bit field, 3 byte marker that provides upstream QPSK synchronization information. At least one packet
with synchronization information must be sent in every period of 3 msec. The definition of the field is as
follows:
Bit 0: Upstream Marker Enable - When this field has the value 1, the slot marker pointer is valid. When
this field has the value 0, the slot marker pointer is not valid.
Bits 1 - 3: MAC Message Framing - Bit 1 relates to the first MAC message slot within the MPEG frame, bit
2 to the second MAC message within the MPEG frame, and bit 3 to the last MAC message within the MPEG
frame. Possible values:
0 - A MAC message terminates in this slot.
1 - A MAC message continues from this slot into the next, or the slot is unused. If the slot is unused, the
first two bytes of the slot are
30
0 x 0000.
Bits 4 - 7: Reserved
Bits 8 - 23: Upstream Slot Marker Pointer - A 16 bit unsigned integer which indicates the number of
downstream symbol clocks between the next Sync byte and the next 3 msec time marker. Bit 23 is
considered the most significant bit of this field.
Slot Number4A 16 bit field which is defined as follows:
Bit 0: Slot Position Register Enable (msb) - When this field has the value 1, the slot position register is
valid. When this field has the value 0, the slot position register is not valid.
Bits 1-3: Reserved
Bit 4: Set to the value 1. This bit is equivalent to M12 in the case of OOB downstream.
Bit 5: Odd Parity - This bit provides odd parity for upstream slot position register. It is equivalent to M11
in the case of OOB downstream.
Bits 6 - 15: Upstream Slot Position Register - 10 bit counter which counts from 0 to n with bit 6 the msb.
These bits are equivalent to M1 - M10 in the case of OOB downstream.
MAC Flag Control24 bit field (b0 (msb), b1, b2 . . . b23) that provides control information used in conjunction with the MAC
Flags and Extension Flags fields. The definition of the MAC Flag Control field is as follows:
b0 - b2 - Channel 0 control field. b3 - b5 - Channel 1 control field. b6 - b8 - Channel 2 control field. b9 - b11 - Channel 3 control field. b12 - b14 - Channel 4 control field. b15 - b17 - Channel 5 control field. b18 - b20 - Channel 6 control field. b21 - b23 - Channel 7 control field.
RTP ProtocolThe Real-time Transport (RTP) Protocol provides end-to-end network transport functions suitable for
applications transmitting real-time data such as audio, video or simulation data, over multicast or unicast
network services. RTP does not address resource reservation and does not guarantee quality-of-service
31
for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring
of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and
identification functionality. RTP and RTCP are designed to be independent of the underlying transport and
network layers. The protocol supports the use of RTP-level transla tors and mixers.
The format of the RTP Fixed Header Fields is shown in the following illustration:
0 1 2 3 4 5 6 7 Octet
V P X CSRC count 1
M Payload type 2
Sequence number 34
Timestamp 5678
SSRC 9101112
CSRC 0-60octets
RTP structure
VVersion. Identifies the RTP version.
PPadding. When set, the packet contains one or more additional padding octets at the end which are not part
of the payload.
XExtension bit. When set, the fixed header is followed by exactly one header extension, with a defined
format.
CSRC countContains the number of CSRC identifiers that follow the fixed header.
MMarker. The interpretation of the marker is defined by a profile. It is intended to allow significant events
such as frame boundaries to be marked in the packet stream.
Payload typeIdentifies the format of the RTP payload and determines its interpretation by the application. A profile
specifies a default static mapping of payload type codes to payload formats. Additional payload type codes
may be defined dynamically through non-RTP means.
Sequence numberIncrements by one for each RTP data packet sent, and may be used by the receiver to detect packet loss
and to restore packet sequence.
TimestampReflects the sampling instant of the first octet in the RTP data packet. The sampling instant must be
derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter
calculations. The resolution of the clock must be sufficient for the desired synchronization accuracy and for
measuring packet arrival jitter (one tick per video frame is typically not sufficient).
32
SSRCIdentifies the synchronization source. This identifier is chosen randomly, with the intent that no two
synchronization sources within the same RTP session will have the same SSRC identifier.
CSRCContributing source identifiers list. Identifies the contributing sources for the payload contained in this
packet.
CDMA & GSM Cellular TechnologyGSM and CDMA protocols described here include:
BSMAP Base Station Management Application Part
BSSAP BSS Application Part
BSSLAP
BSSAPLE
BSSMAP BSS Managment Application Part
BTSM Base Transceiver Station Management
CC Call Control
DTAP (CDMA) Direct Transfer Application Part for CDMA
DTAP (GSM) Direct Transfer Application Part for GSM
MM Mobility Management
MMS
33
Mobile IP Mobile Internet Protocol
RR Radio Resource
SMS Short Message Service
SMSTP Short Message Transfer Layer Protocol
GSM
In 1989, GSM responsibility was transferred to the European Telecommunication Standards Institute
(ETSI), and phase I of the GSM specifications were published in 1990. Commercial service was started in
mid1991, and by 1993 there were 36 GSM networks in 22 countries, with 25 additional countries having
already selected or considering GSM In addition to Europe, South Africa, Australia, and many Middle and
Far East countries have chosen to adopt GSM. By the beginning of 1994, there were 1.3 million subscribers
worldwide. The acronym GSM now (aptly) stands for Global System for Mobile telecommunications.
From the beginning, the planners of GSM wanted ISDN compatibility in services offered and control
signaling used. The radio link imposed some limitations, however, since the standard ISDN bit rate of 64
Kbps could not be practically achieved.
The digital nature of GSM allows data, both synchronous and asynchronous data, to be transported as a
bearer service to or from an ISDN terminal. The data rates supported by GSM are 300 bps, 600 bps, 1200
bps, 2400 bps, and 9600 bps.
The most basic teleservice supported by GSM is telephony. A unique feature of GSM compared to older
analog systems is the Short Message Service (SMS). Supplementary services are provided on top of
teleservices or bearer services, and include features such as international roaming, caller identification,
call forwarding, call waiting, multiparty conversations, and barring of outgoing (international) calls, among
others.
CDMA
Code Division Multiple Access (CDMA) is a digital air interface standard, claiming eight to fifteen times the
capacity of traditional analog cellular systems. It employs a commercial adaptation of a military spread-
spectrum technology. Based on spread spectrum theory, it gives essentially the same services and qualities
as wireline service. The primary difference is that access to the local exchange carrier (LEC) is provided
via a wireless phone.
Though CDMAs application in cellular telephony is relatively new, it is not a new technology. CDMA has
been used in many military applications, such as:
Anti-jamming (because of the spread signal, it is difficult to jam or interfere with a CDMA signal). Ranging (measuring the distance of the transmission to know when it will be received). Secure communications (the spread spectrum signal is very hard to detect).
CDMA is a spread spectrum technology, which means that it spreads the information contained in a
particular signal of interest over a much greater bandwidth than the original signal. With CDMA, unique
digital codes, rather than separate RF frequencies or channels, are used to differentiate subscribers. The
codes are shared by both the mobile station (cellular phone) and the base station, and are called pseudo-
random code sequences. Since each user is separated by a unique code, all users can share the same
frequency band (range of radio spectrum). This gives many unique advantages to the CDMA technique over
other RF techniques in cellular communication.
CDMA is a digital multiple access technique and this cellular aspect of the protocol is specified by the
Telecommunications Industry Association (TIA) as IS-95. In CDMA, the BSSAP is divided into the DTAP
and BSMAP (which corresponds to BSSMAP in GSM).
34
DTAP (CDMA) Protocol
The Direct Transfer Application Part (DTAP) messages are used to transfer call processing and mobility
management messages to and from the MS. The BS does not use DTAP messages, but must map messages
going to and coming from the MSC into the appropriate air interface signaling protocol. Transaction IDs are
used to associate the DTAP messages with a particular MS and the current call.
The format of the header is shown in the following illustration:
8 7 6 5 4 3 2 1 OctetTransaction
identifier
Protocol
discriminator
1
Message type 2Information elements 3-n
DTAP header structure
Protocol discriminatorThe protocol discriminator specifies the message being transferred (CC, MM, RR).
Transaction identifier
Distinguishes multiple parallel activities (transactions) within one mobile station. The format of the
transaction identifier is as follows:
8 7 6 5
TI flag TI value
Transaction identifier
TI flagIdentifies who allocated the TI value for this transaction. The purpose of the TI flag is to resolve
simultaneous attempts to allocate the same TI value.
TI valueTI values are assigned by the side of the interface initiating a transaction. At the beginning of a transaction,
a free TI value is chosen and assigned to this transaction. It then remains fixed for the lifetime of the
transaction. After a transaction ends, the associated TI value is free and may be reassigned to a later
transaction. Two identical transaction identifier values may be used when each value pertains to a
transaction originated at opposite ends of the interface.
Message TypeThe message type defines the function of each DTAP message.
Information elementsEach information element has a name which is coded as a single octet. The length of an information
35
element may be fixed or variable and a length indicator for each one may be included.
DTAP (GSM) ProtocolThe Direct Transfer Application Part (DTAP) is used to transfer call control and mobility management
messages between the MSC and the MS. The DTAP information in these messages is not interpreted by the
BSS. Messages received from the MS are identified as DTAP by the Protocol Discriminator Information
Element. The majority of radio interface messages are transferred across the BSS MSC interface by DTAP,
except for messages belonging to the Radio Resource (RR) management protocol.
The DTAP function is in charge of transferring layer 3 messages from the MS (or from the MSC) to the
MSC (or to the MS) without any analysis of the message contents. The interworking between the layer 2
protocol on the radio side and signalling system 7 at the landside is based on the use of individual SCCP
connections for each MS and on the distribution function.
The format of the DTAP header is shown in the following illustration:
8 7 6 5 4 3 2 1 Octet
Protocol
Distriminator
Transaction / Skip
1
0 N(SD)Messa
ge Type
2
Information Elements 3-n
GSM L3 structure
Protocol discriminatorIdentifies the L3 protocol to which the standard layer 3 message belongs. Values may be as follows:
0000 Group call control
0001 Broadcast call control
0010 PDSS1
0011 Call control; call related SS messages
0100 PDSS2
0101 Mobility Management Messages
0110 Radio resources management messages
1001 SMS messages
1011 Non-call related SS messages
1110 Extension of the PD to one octet length
1111 Tests procedures described in TS GSM 11.10
Transaction ID / Skip identifierEither a transaction identifier, or a skip indictor depending on the level 3 protocol. The transaction
identifier contains the transaction value and flag which identifies who allocated the TI.
N(SD)For MM and CM, N(SD) is set to the value of the send state variable. In other level 3 messages, bit 7 is set
to 0 by the sending side. Messages received with bit 7 set to 1 are ignored.
Message typeUniquely defines the function and format of each GSM L3 message. The message type is mandatory for all
messages. The meaning of the message type is therefore dependent on the protocol (the same value may
have different meanings in different protocols) and direction (the same value may have different meanings
36
in the same protocol, when sent from the Mobile Station to the network and when sent from the network to
the Mobile Station).
MMS ProtocolThe WAP Multimedia Messaging Service (MMS) uses WAP WSP/HTTP as underlying protocols to transfer
MMS PDUs between the MMS Client, which resides on the terminal (MS) and the MMS Proxy -Relay.
This structure is based on the well-known message structure of Internet email binary encoding of MMS
PDUs. Because of the limited bandwidth of the air interface of mobile networks MMS PDUs are transferred
between an MMS Client and an MMS Proxy -Relay in binary encoded message format. This process is
called encapsulation. WSP PDUs or HTTP messages, which contain MMS PDUs as their body, are used for
this transport.
MMS PDUs, which are described in this specification, are included in WSP PDUs/HTTP messages of
different types. The entire MMS information is contained in MMS PDUs, which are encapsulated in WSP
PDUs/HTTP messages.
The content type of WSP PDUs/HTTP messages containing MMS PDUs is
"application/vnd.wap.mms - message."
MMS has no header structure as it consists of messages.
Field Reference Number:
0x81 Bcc
0x82 Cc
0x83 X-Mms-Content-Location
0x84 Content-Type
0x85 Date
0x86 X-Mms-Delivery-Report
0x87 X-Mms-Delivery-Time
0x88 X-Mms-Expiry
0x89 From
0x8A X-mms-Message-Class
0x8B Message-ID
0x8C X-Mms-Message-Type
0x8D X-Mms-MMS-Version
0x8E X-Mms-Message-Size
0x8F X-Mms-Priority
0x90 X-Mms-Read-Report
0x91 X-Mms-Report-Allowed
0x92 X-Mms-Response-Status
0x93 X-Mms-Response-Text
0x94 X-Mms-Sender-Visibility
0x95 X-Mms-Status
0x96 Subject
0x97 To
0x98 X-Mms-Transaction-Id
0x99 X-Mms-Retrieve-Status
0x9A X-Mms-Retrieve-Text
37
0x9B X-Mms-Read-Status
0x9C X-Mms-Reply-Charging
0x9D X-Mms-Reply-Charging-Deadline
0x9E X-Mms-Reply-Charging-ID
0x9F X-Mms-Reply-Charging-Size
0xA0 X-Mms-Previously-Sent-By
0xA1 X-Mms-Previously-Sent-Date
Message TypeThe following message types are contained in the PDU:
128 m-send-req
129 m-send-conf
130 m-notification-ind
131 m-notifyresp-ind
132 m-retrieve-conf
133 m-acknowledge-ind
134 m-delivery-ind
135 m-read-rec-ind
136 m-read-orig-ind
137 m-forward-req
138 m-forward-conf
SMS Protocol
38
The purpose of the Short Message Service (SMS)is to provide the means to transfer messages between a
GSM PLMN Mobile Station and a Short Message Entity via a Service Center, as described in TS GSM
03.40. The terms "MO" - Mobile Originating - and "MT" - Mobile Terminating - are used to indicate the
direction in which the short message is sent.
The SMS structure is as follows for control messages:
8 7 6 5 4 3 2 1 Octet
Protocol
distriminator
Skip indicat
or
1
Message type 2
Information elements 3-n
SMS CP structure
Protocol discriminator1001 identifies the SMS protocol.
Transaction IdentifierSee CC for the format of the Transaction ID.
Message typeThe message type, together with the protocol discriminator, identifies the function of the message being
sent. Messages may be of the following:
00000001 CP-DATA
00000100 CP-ACK
00010000 CP-ERROR
Information ElementEach IE has an identifier which is coded as a single octet. The length of an IE may be fixed or variable and
may or may not include a length indicator.
The SMS structure is as follows for relay messages:
8 7 6 5 4 3 2 1 Octet
0 0 0 0 0 MTI 1
Message Reference 2Information elements 3-n
SMS structure
MTIMessage type indicator. Values are as follows:
Bit Value (3 2 1) Direction RP-Message
0 0 0 ms -> n RP-DATA
0 0 0 n -> ms Reserved
0 0 1 ms -> n Reserved
0 0 1 n -> ms RP-DATA
0 1 0 ms -> n RP-ACK
0 1 0 n -> ms Reserved
0 1 1 ms -> n Reserved
0 1 1 n -> ms RP-ACK
1 0 0 ms -> n RP-ERROR
39
1 0 0 n -> ms Reserved
1 0 1 ms -> n Reserved
1 0 1 n -> ms RP-ERROR
1 1 0 ms -> n RP-SMMA
1 1 0 n -> ms Reserved
1 1 1 ms -> n Reserved
1 1 1 n -> ms Reserved
Message ReferenceUsed to link an RP-ACK message or RP-ERROR message to the associated RP-DaATA or RP-SMNA
message.
Information ElementEach IE has an identifier which is coded as a single octet. The length of an IE may be fixed or variable and
may or may not include a length indicator.
CONCLUSIONWhile the age-old concept of the network is foundational in virtually
all areas of society, Computer Networks and Protocols have forever
changed the way humans will work, play, and communicate. Forging
powerfully into areas of our lives that no one had expected, digital
networking is further empowering us for the future. New protocols
and standards will emerge, new applications will be conceived, and
our lives will be further changed and enhanced. While the new will
only be better, the majority of digital networking's current
technologies are not cutting-edge, but rather are protocols and
standards conceived at the dawn of the digital networking age that
have stood solid for over thirty years.
40
41
Network Communication Architecture and ProtocolsNetwork Protocol: Definition and Overview
IP ProtocolIPv6 ProtocolTCP ProtocolUDP ProtocolVoice Over IPH.323 ProtocolMGCP ProtocolSkinny ProtocolDVB Protocol Certain implementations suitable for Digital Video Broadcasting (DVB) broadcasting systems are supported by CATV infrastructures. Specifically, implementations of the Return Channel for interactive services are supported by CATV. DVB involves a standard link.RTP ProtocolCDMA & GSM Cellular Technology