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