`The CDPD Approach
`
`Apostolis K. Salkintzis, The University of British Columbia
`
`ABSTRACT
`
`Cellular digital packet data is a mobile packet data technology
`that operates on the spectrum assigned to a telephone cellular
`network, such as the Advanced Mobile Phone Service. This article undertakes a thorough
`survey of the CDPD radio interface and explores the main functional layers of this inter-
`face. Specifically, it extensively studies the physical layer, the data link layer, and the sub-
`network-dependent convergence protocol, and explains their semantics and functional
`characteristics. Furthermore, it emphasizes several significant aspects such as the medium
`access procedure, the forward and reverse channel configurations, the data multiplexing
`scheme; and the channel hopping procedure.
`
`C data technology that permits subordinate packet
`
`ellular digital packet data (CDPD) is a mobile
`
`data operation on the spectrum assigned to a telephone cel-
`lular network, such as the Advanced Mobile Phone Service
`(AMPS). It was first introduced by IBM as a packet-switch-
`ing overlay to the existing analog cellular voice network and
`frequencies. Later, a CDPD System Specification [ l ] was
`formed by a consortium of cellular carriers including Air-
`Touch, McCaw Cellular, Southwestern Bell Mobile Systems,
`NYNEX, Ameritech, GTE, Bell Atlantic Mobile, and Con-
`tel Cellular [2]. Now, CDPD technology is being deployed
`by a number of cellular companies in the United States,
`including Bell Atlantic, Ameritech, GTE, and McCaw Cellu-
`lar, and related equipment is provided by a variety of manu-
`facturers.
`An industry association that handles the shaping of CDPD
`technology and supports the growth of the commercial mar-
`ketplace is the Wireless Data Forum [3]. According to this
`forum, by the end of the third quarter of 1997, CDPD was
`available in 195 markets in the United States - 118
`metropolitan statistical areas (MSAs), 41 rural statistical areas
`(RSAs), and 36 international markets - and was available to
`53 percent of the U.S. population.
`This article focuses on the wireless interface of CDPD and
`explores the main functional layers of this interface. Specifi-
`cally, the next section provides a general outlook on CDPD,
`and explains its major network elements and their interaction
`and functionality. The following three sections concentrate on
`the wireless interface and outline the physical, medium access
`control, and logical link control layers, respectively. In this
`context, several significant aspects are studied such as the
`medium access protocol, the forward and reverse channel con-
`figurations, and the data link establishment procedures. The
`article then focuses on the subnetwork-dependent conver-
`gence protocol (SNDCP), and demonstrates its major charac-
`teristics and the services it provides. The channel hopping
`procedure is underlined, and finally, the last section summa-
`rues our conclusions.
`A CDPD OVERVIEW
`The primary elements of a CDPD network are the end sys-
`tems (ESs) and intermediate systems (ISs), as shown in Fig. 1.
`(In Internet terminology, the ESs are known as hosts and ISs
`as routers.) The ESs represent the actual physical and logical
`
`end nodes that exchange information,
`while the Iss represent the CDPD infra-
`structure elements that store, forward,
`and route the information.
`There are two kinds of ESs: The
`mobile ES (M-ES), which is a device
`used by a subscriber to access the
`CDPD network over the wireless inter-
`face, and the fixed ES (F-ES), which is a common host, serv-
`er, or gateway connected to the CDPD backbone and
`providing access to specific applications and data. By defini-
`tion, the location of an F-ES is fixed, whereas the location of
`an M-ES may change.
`Typically, an M-ES consists of a mobile terminal (personal
`computer, personal digital assistant, or other standard equip-
`ment) and a CDPD radio modem, which attaches to the
`mobile terminal and manages the radio link and protocols.
`Usually, the communication between the radio modem and
`the mobile terminal is supported by standard serial protocols,
`such as the Serial Line Internet Protocol (SLIP) or Point-to-
`Point Protocol (PPP).
`On the other hand, there are two kinds of 1%: a generic
`IS, which is simply a router (in most cases, an Internet Proto-
`col, IP, router) with no knowledge of CDPD and mobility
`issues, and a mobile data IS (MD-IS), which is a specialized
`IS that routes messages based on its knowledge of the current
`location of M-ESs. The MD-IS is a set of hardware compo-
`nents and software functions that provide switching, account-
`ing, registration, authentication, encryption, and mobility
`management functions. The mobility management software
`allows the switching system to track the M-ESs regardless of
`their location in the network and allows the M-ESs to use a
`single network address. The CDPD mobility management
`software follows the mobile IP model [4] established by the
`Internet Engineering Task Force (IETF).
`Besides the ESs and ISs, there is also another element, the
`mobile data base station (MDBS), which is analogous to a
`common cellular base station. An MDBS performs no net-
`working functions, but rather relays data link information
`between a number'of M-ESs and their serving MD-IS (it is a
`data link functional element). Furthermore, it performs radio
`resource management procedures, the most important being
`the hopping of the CDPD radio frequency (RF) channel in
`response to voice network activity (see [SI for details). In sum-
`mary, the MDBS creates and manages the air interface
`between the M-ESs and the CDPD backbone under the con-
`straints arising out of the underlying voice network.
`The CDPD backbone provides connectionless transport ser-
`vices, also called datagram services. This means that the network
`individually routes packets based on the destination address
`each packet carries and the knowledge of the current network
`topology. For the routing of packets, CDPD supports both IP
`and the Connectionless Network Protocol (CLNP), which is an
`open systems interconnection (OSI) standard protocol.
`
`152
`
`0163-6804/99/$10.00 0 1999 IEEE
`
`IEEE Communications Magazine June 1999
`
`Authorized licensed use limited to: Reprints Desk. Downloaded on March 23,2022 at 21:05:45 UTC from IEEE Xplore. Restrictions apply.
`
`1
`
`SAMSUNG 1031
`
`
`
`greater than the central carrier fre-
`quency represents a logical 1, whilst a
`logical 0 is represented by a frequency
`less than the central carrier frequency.
`The modulation rate on both the for-
`ward and reverse R F channels is 19.2
`kbls.
`MEDIUM ACCESS CONTROL
`As shown in Fig. 3, the MAC layer
`models a functional entity logically
`operating between the PHY and link
`layer control (LLC) layers. The MAC
`layer within an M-ES cooperates with
`the corresponding MAC layer within
`the MDBS. The purpose of this layer is
`to convey information, namely link
`protocol data units (LPDUs), between
`peer LLC entities across the CPDP air
`interface. For this purpose, the MAC
`layer provides the following services:
`*Encapsulates LPDUs into frame
`structures to ensure LPDU delimit-
`ing, frame synchronization, and
`data transparency
`*Encodes LPDUs to provide error
`protection against mobile channel
`impairments
`*Detects and corrects bit errors
`within received frames
`Arbitrates access to the shared reverse channel
`Synchronizes with the forward channel transmissions to
`make feasible the reception of data as well as control
`information transmitted in every CDPD cell
`The MAC layer communicates through an implementa-
`tion-dependent interface with the RRME. Through that inter-
`face, the MAC layer notifies the RRME whether it has
`acquired synchronization with the currently selected forward
`channel (next section), and also passes to the RRME status
`information regarding the number of received bit and block
`errors. In this way, the RRME may estimate the acceptability
`of a given CDPD channel and provide the radio resource
`management functionality [SI.
`FORWARD CHANNEL CONFIGURATION
`The forward channel characteristics are among the most essen-
`tial issues required to understand CDPD operation. In order to
`
`THE PHYSICAL LAYER
`As indicated in Fig. 2, the physical (PHY) layer in CDPD cor-
`responds to a functional entity that accepts a sequence of bits
`from the medium access control (MAC) layer and transforms
`them into a modulated waveform for transmission onto a phys-
`ical 30 lcHz RF channel.
`Communications between an MDBS and an M-ES take
`place over a pair of such RF channels (having a fixed frequen-
`cy separation). The first channel, called the forward channel,
`accommodates transmissions in the direction from the MDBS
`to the M-ESs and is either dedicated to CDPD use or shared
`with the voice cellular network. In any case, transmission on
`the forward channel is continuous as long as it is in use for
`CDPD. The second channel, called the reverse channel,
`accommodates transmissions in the direction from the M-ESs
`to the MDBS and is shared among all M-ESs communicating
`with the same MDBS. A pair of associated reverse and for-
`ward channels forms a CDPD channel
`stream.
`As illustrated in Fig. 2, the PHY layer
`interfaces with another entity, the radio
`resource management entity (RRME).
`Through this interface the RRME can:
`Tune the PHY layer to a specific R F
`channel pair
`Set the transmission power level to the
`desired value
`Measure the received signal level of an
`R F channel and estimate its potential
`to offer acceptable communication
`Suspend and resume operation of the
`PHY layer in cases where power saving
`facilities are required
`The modulation employed on a R F chan-
`nel stream is Gaussian minimum shift keying
`(GMSK) [6] with BT = 0.5. A frequency
`
`1 Figure 2. The PHYlayer model: operation and interaction with otherfunctional
`entities.
`
`IEEE Communications Magazine June 1999
`
`153
`
`Authorized licensed use limited to: Reprints Desk. Downloaded on March 23,2022 at 21:05:45 UTC from IEEE Xplore. Restrictions apply.
`
`2
`
`
`
`is a special pattern assigned to every individ-
`ual CDPD channel stream and is used for
`cochannel interference detection. Three bits
`within this pattern are MD-IS-specific; they
`have the same value in all channel streams
`transmitted in the set of cells controlled by a
`given MD-IS. On the other hand, the other
`five bits of the color code are MDBS-specif-
`ic; they specify an individual channel stream
`within the set of cells controlled by a given
`MD-IS. Inside a cell, all R F channels avail-
`able for CDPD use are assigned the same
`value of color code.
`Data blocks are encoded using a systematic
`(63,47) Reed-Solomon error correcting code.
`From an encoding point of view, each data
`block represents an information field of 47 6-
`bit symbols (or codewords). The encoding of
`this information field generates a 16-symbol parity field (96
`bits), which is appended at the end of the information field. In
`this manner, a consecutive sequence of Reed-Solomon (RS)
`encoded blocks is generated, as shown in Fig. 4. These encod-
`ed blocks, each with a fixed length of 378 bits, form the basic
`transmission units of the forward channel. The (63,47) Reed-
`Solomon encoding is common to both the forward and reverse
`channels and typically is capable of correcting as many as 8
`bits within each encoded block.
`Prior to actual transmission on the forward channel, each
`RS block is passed through a ninth-order scrambler with a
`generator polynomial,g(x) = x9 + x8 + x5 + x4 +l. This pro-
`cess reduces the likelihood of having long strings of binary 1s
`and Os within the transmission bitstream. Such long strings are
`generally avoided because they are difficult to track by certain
`
`W Figure 3. An operational model of the medium access control layer.
`
`outline the configuration and the semantics of the forward
`channel, we will discuss how the LPDUs in an MDBS are trans-
`formed within a sequence of stages before they construct a con-
`tinuous bitstream for transmission.
`As shown in Fig. 4, the sequence of LPDUs pending for
`transmission are first flag-delimited (using the well-known bit
`pattern 01111110) and zero-stuffed, and then linked together
`to form a continuous frame data bitstream. The continuity of
`this bitstream is ensured because, even when there are no
`data LPDUs for transmission, either control LPDUs o r
`sequences of contiguous flags are transmitted.
`The frame data bitstream is divided into segments of
`274 consecutive bits, each of which is prefixed by an 8-bit
`color code. Hence, a series of consecutive data blocks is
`formed, each with a fixed length of 282 bits. The color code
`
`W Figure 4. Formulation of the forward channel data stream.
`
`154
`
`IEEE Communications Magazine June 1999
`
`Authorized licensed use limited to: Reprints Desk. Downloaded on March 23,2022 at 21:05:45 UTC from IEEE Xplore. Restrictions apply.
`
`3
`
`
`
`W Figure 5 . Detailed construction of a forward channel data stream.
`
`types of demodulators (e.g., PLLs) and may result in reduced
`performance or increased implementation complexity.
`As illustrated in Fig. 4, what is actually transmitted on the
`forward channel is the contiguous sequence of RS blocks
`(after scrambling)? interleaved with special control flags.
`These flags carry synchronization information that helps M-
`ESS acquire block synchronization and decode the forward
`channel, as well as MAC-level control information that helps
`M-ESs effectively share the common reverse channel.
`Figure 5 illustrates in detail the forward channel transmis-
`sion structure. It shows how the control flags are constructed
`and how they are interleaved with the forward channel RS
`blocks. Each control flag is composed of one decode status bit
`plus five more bits, which derive from an exclusive-OR opera-
`tion between a 5-bit section of the forward synchronization
`word (FSW) and busylidle status bits. The FSW is a 35-bit
`sequence that provides a reference marker within the forward
`channel bitstream to discriminate between control flags and
`RS block boundaries. Additionally, it provides a timing refer-
`ence for the reverse channel microslot clock. This microslot
`clock as well as the decode status and busy/idle status bits
`form the primary elements of the MAC procedure and are
`discussed later.
`Since the FSW is transmitted after being exclusively-ORed
`with the busy/idle status bits, its discrimination within the
`transmitted bitstream would be impossible if the value of
`busy/idle status bits was not known. Fortunately, as discussed
`later, the busy/idle status can be either 11111 or 00000; there-
`fore, the 5-bit portion of the FSW carried within every control
`flag is either inverted (when the busy/idle status is 11111) or
`not inverted (when the busy/idle status is 00000).
`An M-ES is actually synchronized with a forward CDPD chan-
`nel as long as it can receive and decode the forward blocks of this
`channel with some acceptable error rate. If the level of error rate
`rises above a threshold, which is implementation-dependent (this
`
`is where commercial CDPD modems may defer), the M-ES starts
`searching through a series of RF channels to find another more
`suitable CDPD data stream (see [5] for details).
`REVERSE CHANNEL CONFIGURATION
`The structure of the data transmitted by M-ESs in a CDPD
`network (i.e., the structure of transmissions on the reverse
`channel) is now discussed.
`Consider an M-ES having, for example, three LPDUs
`pending transmission, as illustrated in Fig. 6. These LPDUs
`are flag-delimited and zero-stuffed, and thereafter are joined
`together to form a frame data bitstream. The first 274 bits of
`this bitstream are prefixed by an 8-bit color code (which is the
`same as the color code transmitted on the forward channel)
`and form a 282-bit data block. The rest of the frame data bit-
`stream is padded with interframe time fill (usually a consecu-
`tive sequence of 1s) and divided into an integer number of
`sequential data blocks, each 282 bits long.
`All the data blocks formed this way are thereafter subject to
`(63,47) Reed-Solomon coding, and thus a sequence of contigu-
`ous RS blocks, each with a fixed length of 378 bits, is construct-
`ed. After these RS blocks are scrambled, they are ready to be
`transmitted on the reverse channel. However, prior to their
`transmission are transmitted a) a 38-bit sequence of alternat-
`ing 1s and Os (the preamble), which helps the MDBS detect
`the transmission start and acquire timing synchronization; and
`b) a reverse synchronization word (RSW), which is a 22-bit
`pattern that helps the MDBS acquire block synchronization.
`The transmission of RS blocks follows right after the RSW.
`As shown in Fig. 6 , a 7-bit continuity indicator is inter-
`leaved with each RS block; 1 bit every nine 6-bit symbols. This
`continuity indicator is a sequence that signals whether the
`reverse transmission burst is completed or not. A sequence of
`all 1s indicates that more RS blocks follow, whereas a
`sequence of all Os marks the final transmission block. Note
`
`IEEE Communications Magazine June 1999
`
`155
`
`Authorized licensed use limited to: Reprints Desk. Downloaded on March 23,2022 at 21:05:45 UTC from IEEE Xplore. Restrictions apply.
`
`4
`
`
`
`that since the continuity indicator is not error-protected, it
`features high redundancy and time-diverse transmission
`(which effectively uncorrelates the errors that may occur with-
`in its 7 bits). Note also that the continuity indicator carries in-
`band information regarding the transmission progress, which
`results in more robust and less complex reception. Should the
`continuity indicator not be used, the moment a transmission
`ends would be derived from received signal analysis - a more
`complex and time-costly procedure.
`THE MEDIUM ACCESS PROCEDURE
`An M-ES can access the reverse channel using a slotted non-
`persistent digital sense multiple access with collision detection
`(DSMNCD) algorithm. This is similar to carrier sense multi-
`ple access with collision detection ( C S W C D ) used in Ether-
`net. However, in CDPD because the M-ESs cannot sense the
`status of the reverse channel directly (because they employ
`different reception and transmission frequency bands), a dif-
`ferent collision detection scheme is applied.
`DSMNCD makes use of the busylidle and decode status
`flags. As previously stated, the busylidle flag is a 5-bit
`sequence transmitted on the forward channel once every 60
`bits (i.e., once every microslot period). This flag provides peri-
`odic binary information with one microslot resolution indicat-
`ing whether the reverse channel is busy or idle.
`On the other hand, the decode status flag is a 5-bitl
`sequence that carries binary information indicating whether
`
`the MDBS has decoded the preceding block on the reverse
`channel successfully or not. O n successful decoding the
`decode status flag is 00000, on unsuccessful decoding 11111.
`An M-ES wishing to transmit senses first the busylidle flag -
`actually, a locally stored version of it which is updated once every
`microslot period. If the reverse channel is found busy, the M-ES
`defers for a random number of microslots and then repeats the
`sensing of the busylidle flag. Because the M-ES does not persist
`in continuously sensing the busylidle flag, the access scheme is
`referred to as nonpersistent. Once the reverse channel is found
`idle, the M-ES may initiate transmission. Note that a transmis-
`sion may initiate only at a microslot boundary, which is why the
`access scheme is termed slotted. As soon as the MDBS detects a
`transmission start on the reverse channel it sets the busyhdle
`flag in order to prevent further transmissions.
`After an M-ES has started a transmission, it checks the
`decode status flag in every forward channel block it receives
`(this assumes full duplex operation*) and resumes or suspends
`transmission depending on the value of this flag. This flag
`provides “real-time” information regarding the progress of its
`ongoing transmission. The M-ES continues transmission if the
`decode status flag indicates that the MDBS encountered no
`decoding errors so far, whereas it ceases transmission in the
`opposite case (note that the MDBS cannot distinguish
`between errors due to collision and those due to channel
`impairments). In the latter situation, the M-ES attempts to
`regain access to the reverse channel after an appropriate
`
`‘Although M-ESs &code a 5-bit decode status flag, the MDBS tmnsmits 6 or
`7 bits of decoa’e stamper revme channel block; the exact number d e p e d on
`the relative timing difference between the forward and reverse channels [I].
`
`M-ESs may be either full-duplex or halfduplex Half-duplex M-ESs are
`subject to certain restrictions regarding access to the reverne channel due to
`their inability to receive the decode status flag while transmitting.
`
`156
`
`IEEE Communications Magazine June 1999
`
`Authorized licensed use limited to: Reprints Desk. Downloaded on March 23,2022 at 21:05:45 UTC from IEEE Xplore. Restrictions apply.
`
`5
`
`
`
`exponential backoff retransmission delay.
`This delay is increased exponentially by a
`factor of two on every subsequent retrans-
`mission attempt; hence the name exponen-
`tial backoff.
`LOGICAL LINK CONTROL
`The purpose of the LLC layer is to convey
`information between network-layer enti-
`ties across the CDPD air interface. The
`protocol applied in the context of this
`layer is called Mobile Data Link Protocol
`(MDLP). As illustrated in Fig. 7, MDLP
`implemented in an M-ES communicates
`with a peer MDLP located in its serving
`MD-IS. Hence, it is seen that the func-
`tionality of an MDBS is restricted within
`the PHY and MAC lavers. Above the
`MAC layer, an MDBS iscompletely trans-
`parent.
`The primary service offered by the MDLP to the upper layer
`(the SNDCP) is the provision and control of one or more logical
`data link connections on a CDPD channel stream. Above the
`LLC layer, these data link connections are treated as individual
`bit pipes that may be used to convey messages back and forth
`between an MD-IS and one or more M-ESs. Within each data
`link connection, one or more network traffic flows may be
`accommodated through facilities provided from the SNDCP.
`Discrimination between data link connections is by means
`of an address label contained in each message (also called
`frame). This address label is called a temporary equipment
`identifier (TEI) and is a pure LLC layer concept; it is used
`internally by the LLC layer and is not necessarily known by
`other functional layers.
`A data link connection may be either point-to-point or
`broadcast, depending on its endpoints. A broadcast data link
`is used for point-to-multipoint or multipoint-to-point commu-
`nications on a CDPD channel stream. Two broadcast data
`links are specified employing two predefined and well-known
`values of TEI:
`A channel with TEI = 1 identifies a layer 3 broadcast
`channel. According to Fig. 7, all received frames from
`this channel are forwarded to the SNDCP. This broad-
`cast channel is used only by the network side (the MD-
`IS) to transmit certain control information.
`A channel with TEI = 0 identifies a broadcast channel
`used for data link management procedures. As shown in
`Fig. 7, frames from this channel are delivered either to
`the TEI management entity or to the RRME depending
`on the layer management entity identifier (LMEI) value.
`With the aid of this channel, the RRME within an M-ES
`receives radio resource management information that is
`broadcast in every CDPD cell (see [5] for details). Typi-
`cally, it receives channel stream identification parameters,
`cell configuration parameters, channel access parameters,
`and channel quality evaluation parameters.
`In contrast to broadcast data links, point-to-point data links
`are single-ended and used to convey information between a sin-
`gle M-ES and its serving MD-IS. Before a point-to-point data
`link connection is established, a specific TEI value (from the
`range 16 to 227 - 1) is allocated to the M-ES that is associated
`to this connection (see [l] for details). Thereafter, the M-ES
`transmits on the point-to-point connection using the allocated
`TEI value and accepts all received frames containing the allo-
`cated TEI value. Hence, the TEI is used as a channel identifier
`or an M-ES data link address. Typically, every M-ES is allocat-
`
`W Figure 7 . The model of the LLC layer and its interaction with other entities.
`
`ed a single TEI value, which is used to multiplex all network-
`layer traffic between this M-ES and its serving MD-IS.
`Two operation modes are supported for information trans-
`fer within a data link connection: unacknowledged and
`acknowledged. Information transfer on a broadcast channel is
`carried out using only the unacknowledged mode, wherein
`neither error recovery nor flow control mechanisms are
`applied. Therefore, information transfer with the unacknowl-
`edged mode provides for unreliable transmission. On the
`other hand, information transfer on a point-to-point data link
`channel is carried out using either the unacknowledged or
`acknowledged mode of operation, depending on the quality of
`service required by the network layer. For every acknowl-
`edged mode data link connection, the MDLP establishes con-
`trol mechanisms in order to ensure a given level of service
`quality. For example, the MDLP provides sequence control to
`maintain the sequential order of the frames across the data
`link connection. Also, it detects several errors, initiates proce-
`dures to recover from them, and provides flow control.
`FRAME STRUCTURE
`Information transfer between peer LLC entities is carried out
`through a number of frames or LPDUs. The general structure
`of a frame is illustrated in Fig. 8. The address field specifies
`whether the frame is a command or response (field C/R) and
`identifies the virtual data link channel that carries the frame
`via the TEI value (in other words, for a point-to-point link it
`identifies the intended receiver of a command frame and the
`transmitter of a response frame). The extension address (EA)
`field is used to indicate the length of the address field.
`The control field identifies the generic type of the frame,
`which can be one of the following: numbered information (I),
`supervisory (S), and unnumbered (U). S frames are used to
`perform data link supervisory control, for example, to
`acknowledge the reception of correct I frames or request the
`retransmission of erroneous frames. U frames are used to
`provide additional control functions (e.g., the establishment
`and release of data link connections) and to transfer data
`using the unacknowledged information transfer mode.
`Observe that no frame check sequence (FCS) field is
`included in a frame because the MDLP does not need to
`detect any errors. This is done at the MAC layer, which dis-
`cards the frames containing unrecoverable numbers of errors
`and forwards only correct frames to the MDLP. However, the
`MDLP identifies the missing frames (which have been
`dropped at the MAC level) by checking the sequence num-
`bers, whereupon it requests their retransmission.
`
`IEEE Communications Magazine June 1999
`
`157
`
`Authorized licensed use limited to: Reprints Desk. Downloaded on March 23,2022 at 21:05:45 UTC from IEEE Xplore. Restrictions apply.
`
`6
`
`
`
`INFORMATION TRANSFER
`
`During the lifetime of a data link, information
`transfer is based on a sliding window (with a win-
`dow size of 128 frames) protocol with a selective
`repeat scheme for error recovery. This is a well-
`known method for information transmission and
`will not be discussed further in this article. The
`MDLP uses special frames, selective reject (SREJ)
`frames, to report missing data frames and request
`their retransmission in order to keep the data
`integrity.
`Generally, the concepts and procedures applied to
`MDLP are based extensively on International
`Telecommunication Union - Telecommunication
`Standardization Sector (ITU-T) Recommendations
`Q.920 and Q.921, which specify the Link Access Pro-
`cedure for the D-channel (LAPD) protocol. Many of
`the formats and procedures between the MDLP and LAPD are
`similar or nearly identical with some minor differences, for
`example, in addressing formats and TEI management proce-
`dures. For more details, the reader is referred to [l].
`
`SUBNETWORK-DEPENDENT
`CONVERGENCE PROTOCOL
`Functionally, SNDCP lays between the data link and network
`layers. The latter is assumed to be subnetwork-independent; it is
`built to work virtually over any data link, and therefore does not
`take into account the specific features of the MDLP. For this
`reason, the services assumed by the network protocol(s) may not
`map directly into the services provided by MDLP. In this case,
`SNDCP operates to provide the required cooperation.
`More specifically, SNDCP provides the following functions:
`Segmentation: Network protocol data units (NPDUs) are
`segmented and reassembled where needed in order to be
`accommodated within the limited length of the data link
`frames. With this segmentation, the maximum size of an
`NPDU can be 2048 bytes, while the maximum size of
`user data supported by MDLP is considerably smaller
`(default value 130 bytes).
`Encryption: To provide user data confidentiality over the
`
`CDPD air interface, NPDUs are encrypted after being
`segmented. The secret keys used for encryption and
`decryption are obtained by means of a security manage-
`ment entity (SME) that operates on top of SNDCP as a
`network layer entity (Fig. 9).
`Multiplexing: SNDCP provides the means to multiplex
`several network-layer traffic types within the same data
`link connection (note that this facility is not provided by
`the MDLP). This makes feasible the simultaneous uti-
`lization of various network-layer entities on top of
`SNDCP. For example, as indicated in Fig. 9, two network
`protocols (IP and CNLS) as well as two management
`entities (the SME and the Mobile Network Registration
`Protocol,3 MNRP, management entity) may simultane-
`ously operate on top of SNDCP. Each is distinguished by
`its own network-layer protocol identifier (NLPI).
`Header compression: SNDCP compresses and recovers
`redundant network control information to increase data
`link performance and efficiency.
`Data compression: To further increase data link perfor-
`mance, the data portion of the NPDUs is compressed
`according to ITU-T V.42 bis (as in all V.34-compliant
`wireline modems).
`Quality of service: Two data transport modes are provided
`by the SNDCP: the acknowledged mode, which transfers
`NPDUs within the data link control
`procedures, and the unacknowledged
`mode, which transfers NPDUs outside
`the data link control. The transport ser-
`vice mode utilized depends on the qual-
`ity of service parameter requested by the
`network layer.
`
`CHANNEL HOPPING
`Since CDPD was specified after the tele-
`phone cellular networks were already in
`operation, its design was subject to the con-
`straint that no changes should need to be
`made to the existing cellular systems. For
`this reason, CDPD has been designed to be
`
`3After establishing a point-to-point data link con-
`nection and erchanging the ciphering keys, an M-ES
`uses the MNRP to authenticate and register all the
`network protocols it employs. Besides providing an
`additional level of security, the MNRP lets the MD-
`IS obtain information about the network addresses
`of an M-ES and route its packets accordingly.
`
`IEEE Communications Magazine June 1999
`
`Figure 9. The model of SNDCP and its interaction with the other entities.
`
`158
`
`Authorized licensed use limited to: Reprints Desk. Downloaded on March 23,2022 at 21:05:45 UTC from IEEE Xplore. Restrictions apply.
`
`7
`
`
`
`completely transparent to the underlying cellular systems.
`Consequently, when a cellular system selects a new channel
`for voice transmission, it is not aware of the existeace of
`CDPD, and therefore it may acquire the channel mggently
`used by CDPD. In that case, the CDPD channel
`should be preempted as soon as possible (voice has
`over data) and established on another idle channel to
`ue CDPD operation. In effect, CDPD operates in a chan
`hopping environment, which has several effects on its down-
`link performance [7].
`The means by which the MDBS finds an available channel
`for transmission is implementation-specific. 'I)rpically, either a
`suitable communication protocol is implemented between the
`MDBS