throbber
Packet Data over Cellular Networks:
`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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket