Page 1 of 28
`
`(cid:49)(cid:50)(cid:57)(cid:36)(cid:55)(cid:40)(cid:47) (cid:40)(cid:59)(cid:43)(cid:44)(cid:37)(cid:44)(cid:55) (cid:20)(cid:19)(cid:22)(cid:19)
`
`

`
`Library of Congress Cataloging—in-Publication Data
`
`Gallagher, Michael D.
`Mobile telecommunications networking with IS-41 / Michael D.
`Gallagher, Randall A. Snyder.
`13.
`cm.
`
`Includes bibliographical references and index.
`ISBN 0-07'-063314-2 (alk. paper)
`1. Personal communication. service systems.
`communication systems.
`I. Snyder, Randall A.
`TK5103.485.G35
`1997
`62l.3845’6’02187~—~dc21
`
`-
`
`2. Mobile
`II. Title.
`
`96-51017
`CIP
`
`'
`
`McG’raw-Hill
`
`A Division ofTl1cMcGraw-Hill Companies
`
`Copyright © 1997 by Michael D. Gallagher and Randall A. Snyder. All
`rights reserved. Printed in the United States of America. Except as
`permitted under the United States Copyright Act of 1976, no part of
`this publication may be reproduced or distributed in any form or by
`any means, or stored in a data base or retrieval system, without the
`prior Written permission of the publisher.
`
`5 6 7 8 9 BKMBKM 909876543210
`
`ISBN 0-07-0633 14-2
`
`The sponsoring editor for this book was Stephen S. Chapman, the editing
`supervisor was Paul Sobei, and the production supervisor was Suzanne
`W. B. Rapcavage. It was set in Century Schcolbook by Victoria Khavkina
`ofMcGraw—HiZi’s Professional Book Group composition unit.
`
`McGraw-Hill books are available at special quantity discounts to use
`as premiums and sales promotions, or for use in corporate training pro-
`grams. For more information, please write to the Director of Special
`Sales, McGraW-Hill,
`11 West 19th Street, New York, NY 10011. Or
`contact your local bookstore.
`
`Information contained in this work has been obtained by The
`McG-raw-Hill Companies, Inc. (“McGraw-Hill”) from sources
`believed to be reliable. However, neither McGraw—Hill nor its
`authors guarantees the accuracy or completeness of any informa-
`tion published herein and neither McGraW—Hill nor its authors
`shall be responsible for any errors, omissions, or damages aris-
`ing‘ out of use of this information. This work is published with
`the understanding that McGraw-Hill and its authors are supply-
`ing information but are not attempting to render engineering or
`other professional services. If such services are required, the
`
`assistance of an appropriate professional should be sought.
`
`Page 2 of 28
`Page 2 of 28
`
`

`
`
`
`Chapter
`
`13
`
`Short Message
`Service Functions
`
`In this chapter, we discuss the IS—41-C mobile telecommunications
`network" functions related to short message service (SMS). These
`functions are divided into the following categories:*
`
`I Short message entity (SMET) service qualification
`
`I SME location management
`
`I SME state management
`
`I Short message processing
`
`We also examine the IS-41—C application processes that support these
`network functions. In the course of describing the processes, we iden-
`tify the IS-41-C mobile application part (MAP) operations (e.g.,
`SMSRequest) that are used to accomplish SMS process tasks. We
`summarize this information at the end of the chapter. Note that We
`employ the IS-41-C convention for operation component acronyms;
`i.e., the Invoke component acronym is in all-capital letters (e.g.,
`SMSREQ), while the Return Result component acronym is in all-low-
`. ercase letters (e.g., smsreq). Refer to the IS-41-C standard for the
`descriptions of the individual IS—41—C operations and parameters.
`Also, consult the Glossary for a description of general terms (e.g.,
`servging system) that are not explicitly defined in this chapter.
`
`*The list of SMS functions reflects the authors’ subjective categorization of certain
`IS-41—C functions. Likewise, the process descriptions are the authors’ subjective inter-
`pretation of the IS~41-C procedures.
`
`TThe short message entity acronym, SME, should not be confused with the same
`acronyin used for signaling message encryption in Chap. 12.
`
`Page 3 of 28
`Page 3 of 28
`
`285
`
`

`
`286
`
`I3-41 Revision C Explained
`
`Throughout this chapter we consider the servi.ng system as a single
`entity encompassing the mobile switching center (MSC) and visitor
`location register (VLR) functional entities. This simplifies the descrip-
`tions of the IS—4l—C SMS functions and also is representative of a
`large percentage‘ of the IS-41 implementations currently in service.
`However, keep in mind that the potential for separation of the MSC
`and VLR exists and is fully defined in IS-41-0.
`
`What Is Short Message Service?
`
`IS—41—C specifies a set of data services collectively known as the short
`message service (SMS). SMS includes services that are specially
`designed for the mobile environment. Most traditional data services
`are not appropriate for this environment since they require bulky ter-
`minals compared to the size of a handheld mobile station (MS). That
`is, data services are generally not designed for an integrated imple-
`mentation on mobile telephones since they usually require a keyboard
`and a reasonably large display screen. However, SMS supports the
`transmission and reception of simple messages that are convenient
`for display on mobile terminals.
`The IS-41—C SMS is desi.gned as a generic short-message transport
`mechanism. The following design imperatives were applied to the
`SMS:
`
`I Support a variety of teleservice applications.
`
`I Make use of commonly implemented transport protocols.
`
`I Incorporate a flexible addressing scheme.
`
`I Easily interwork with other packet-switched data networks.
`
`I Be compatible with electronic mail services, paging services, and
`other commonly used messaging services.
`
`The SMS is categorized into the following two types of services:
`SMS bearer service and SMS teleservices. These services require two
`functional entities in addition to those used for basic mobile telecom-
`munications: the message center (MC) and the short message entity
`(SME). These services and functional entities are described in detail
`in the following sections.
`
`SMS bearer service
`The SMS bearer service is the basic transport mechanism to convey a
`short message as a packet of data between two points on the network.
`The short message may have length up to 200 octets.
`
`Page 4 of 28
`Page 4 of 28
`
`

`
`Short Message Service Functions
`
`287
`
`The SMS bearer service does not contain many features itself. This
`allows for the flexibility of custom applications (i.e., teleservices) to
`use a simple transport mechanism. The bearer service supports the
`standardized teleservices described in the next section.
`The SMS bearer service is designed to use any one of the following
`transport protocols:
`'
`
`I Signaling System No. 7 (SS7)
`
`I X25 '
`
`I Internet protocol (IP)
`
`In addition, IS—41—C does not preclude the use of a proprietary data pro-
`tocol for transport of the SMS bearer service messages ("see Fig. 13.1).
`The SMS bearer service is described in TIA / EIA IS—53-A as the
`“Short Message DeliVery—Point—to—Point Bearer Service.” The points
`are short message entities, which are essentially applications that
`can both send and receive short messages. Thus, the bearer service is
`bidirectional and symmetrical,‘ and there is no technical service differ-
`entiation (aside from signaling procedures) between mobile-originated
`SMS and mobile—terminated SMS.
`
`The bearer service always attempts todeliver a short message to an
`MS-based SME whenever the MS is registered, even if the mobile sta-
`
` SS7, ISDN,
`
`
`Frame Relay
`or proprietary
`
`Figure 13.1 The basic network architecture supporting IS—41 SMS. SS7, X25, and IP can
`be used for transport of short messages. If a packet-switched protocol other than SS7 is
`used, the serving MSC requires an interworking function to support that protocol.
`
`Page 5 of 28
`Page 5 of 28
`
`

`
`288
`
`IS-41 Revision C Explained
`
`tion is engaged in a call. The network is informed whether a message
`has been received by the MS. This allows the messages to be held by
`the sender in cases of unsuccessful delivery and then retransmitted to
`
`the destination when possible.
`
`SMS teleservices
`
`An SMS teleservice is defined as an SMS service that provides the
`complete application capability, including terminal equipment func-
`tions, for communication between SMS users (i.e., SMES) according to
`application protocols established between the users. The SMS teleser-
`vices are designed as special applications that use the SMS bearer
`service as a transport mechanism (see Fig. 13.2). There are currently
`two TIA—standardized teleservices:
`
`1. Cellular paging teleservice (CPT). The CPT specifies a short mes-
`sage—based teleservice to provide paging-like services to an MS.
`CPT is based upon a minimal character set, including uppercase
`letters A through Z and digits 0 through 9, with a maximum mes-
`sage length of 63 characters.
`
`2. Cellular messaging teleservice (CMT). The CMT specifies a short
`message—based teleservice to provide a generic short messaging
`application to an MS. CMT is based upon an extensive character
`set an.d a maximum message length of 200 characters.
`
`Short Message
`Entity
`
`SMS
`
`teleservices
`application
`
`IS-41 SMS MAP
`bearer service
`
`SS7 TCAP
`
`dala link layer
`
`physical layer
`
`
`
`SMD-PF’
`
`transport
`------------ -- - X25, IP or SS7
`
`I
`
`transmission
`
`transmission
`
`l
`
`Figure 13.2 Layered protocol model showing the SMS teleservices as applications sup-
`ported by the SMS bearer service (i.e., SMS point-to-point delivery service). Note that
`X.25, IP, or SS7 can be used for network transport of short messages.
`
`Page 6 of 28
`Page 6 of 28
`
`Short Message
`Entity
`
`Message
`Center
`
`
`
`- short messages
`
`
`
`SMS
`teleservices
`application
`
`1s—41 sMs MAP
`bearer service
`
`.
`
`SS7 TCAP
`
`
`
`><.25. IP or 357 4
`
`data link layer
`
`physical layer
`
`N
`
`l
`
`
`
`___‘_~3M|_3_-E’_Fj___
`
`'
`
`
`transport
`' ------------ --
`
`
`IS-41 SMS MAP
`bearer service
`
`SS7 TCAF’
`
`data link layer
`
`physical layer
`
`
`
`
`
`short messages
`SMS
`
`. . . . . . . . . . . . -.>
`teleservices
`. _ _ . . . . . . . . . CF»
`
`
`application
`
`
`
`
`

`
`Short Message Service Functions
`
`, 289
`
`Although stage 1 of CPT and CMT is standardized in TIA IS—53-A,
`stages 2 and 3 are designed to be network—independent and are not
`specified in IS-41-C.
`
`Message center
`
`The message center (MC) provides the store~o.nd—forward function for
`most (see below) mobile-originated short messages and for all mobile-
`terminated short messages. The MO is typically implemented as a
`physically separate network. entity, but it may be combined with other
`functional entities. Many MCs may be connected on a single network,
`or a single MC may be connected to many networks.
`SMS subscribers are associated with an MC, known as the home
`MC, in the MS’s home system. The MC maintains the mobile identifi-
`cation number (MIN) address information of the MSs that it serves
`for mobile-terminated messages. The MO is addressable by the direc-
`tory number addresses of the MSS that it serves for mobile—terminat-
`ing messages. In general, an MC provides the following capabilities:
`
`I Forward messages to the addressed MS-based SME.
`
`I Store short messages for unavailable MS-based SMES.
`
`I Apply originating and terminating SMS supplementary services to
`short messages.
`
`I Optionally, provide interworking between different transport proto-
`cols.
`
`IS-41-C supports bypassing the MC for mobile-originated short
`messages, so that messages can be sent directly to the destination
`SME from the serving MSG. However, no originating supplementary
`services can be applied to these messages.
`
`Short message entity
`
`The short message entity is a functional entity capable of composing
`(originating) "and decomposing (receiving) a short message. An SME
`may be located in a fixed network (outside the IS—41 network), in a
`mobile station, or Within the IS-4.1 network. An SME is generally con-
`sidered to be an application entity that represents the originator and
`recipient of short messages provided via the point-to-point short mes-
`sage delivery service. In general, an SME has the following capabilities:
`
`I Compose short messages.
`
`I Dispose of, act upon, or display short messages.
`
`I Request supplementary services.
`
`Page 7 of 28
`Page 7 of 28
`
`

`
`290
`
`I341 Revision C Explained
`
`I Store received short messages.
`
`I Manage stored messages.
`
`The methods for performing these tasks are implementation—depen-
`dent and are not addressed by IS—41-C.
`
`Where Are SMS Functions Specified in IS-41-C?
`
`SMS functions are specified in three parts of IS—41—C:
`
`1. IS-41.5-C provides the required formats of all the IS—41-C opera-
`tion components, including those used for SMS. IS—41.5—C' defines
`both the messages (e.g., SMSRequest Invoke) and the message
`parameters (eg, SMS_Address).
`'
`
`2.
`
`IS-41.6—C provides algorithmic descriptions of the procedures that
`are associated with sending and receiving most IS-41—C messages,
`including those used for SMS. This part of IS—41—C also includes an
`example of an air interface definition for SMS in the informative
`(i.e., not technically a requirement of the standard) Annex C. This
`information is intended to illustrate the assumptions regarding
`the air interface SMS support that Were made in the design of the
`IS—41—C SMS network protocols and procedures.
`
`3.
`
`IS—41.3-C steps back from the protocol details contained in parts 5
`and 6 and attempts to explain, using information flow diagrams
`and step—by-step descriptions, how the operations are used individ—
`ually and together to accomplish SMS application process tasks.
`
`Issues Associated with SMS
`
`The following issues need to be addressed in the implementation of
`SMS:
`
`I Delivering short messages to roaming subscribers. Location, status,
`and address information needs to be obtained from the serving sys-
`
`tem to deliver a mobi1e—terminated short message.
`
`I Delivering short messages during intersystem handoff". Short mes-
`sages being delivered during intersystem handoff must be delivered
`to the subscriber intact.
`
`I Methods for originating short messages from an MS. Typical mobile
`stations do not have an adequate keypad for entering message
`information to be transmitted. In a basic implementation, a mes-
`sage may be selected from a predetermined set of messages stored
`in the MS; alternatively, operator assistance or portable computers
`can be used to generate messages.
`
`Page 8 of 28
`Page 8 of 28
`
`

`
`Short Message Service Functions
`
`291
`
`I Subscribers may roam into areas where SMS is not supported. The
`- subscriber may not have access to SMS in all cellular coverage
`areas. Subscribers may not be aware that they have lost service.
`
`I Different air interface protocols support different message lengths.
`NAMPS supports transmission of only 14 characters at a time,
`whereas the digital protocols support short messages of at least 140
`characters. Different systems may also support varying maximum-
`message lengths, possibly limited by the service provider to con-
`serve bandwidth.
`
`I SMS interconnection to other data networks. A primary considera-
`~
`tion in the design of SMS is support of standardized transport pro-
`tocols for easy access to packet data networks such as the Internet
`or X25, in addition to SS7.
`'
`
`SME Service Qualification"
`
`The IS-41-C SME service qualification function encompasses the
`processes which establish an SME’s financial accountability and service
`capabilities in a serving system. There are two types of SMEs defined
`for SMS: MS-based SME and fixed SME. IS-41-0 defines the service
`
`qualification procedures for MS-based SMES only; qualification proce-
`dures for fixed SMES are determined by individual service providers.
`The IS—41—C lV.[S—based SME service qualification processes are tight-
`ly coupled to the service qualification of the host MS itself; i.e., if the
`MS is qualified, generally the SME is also qualified. These procedures
`are described in Chap. 10 and use the following IS-41-C operations:
`
`I RegistrationNotificati0n
`
`I QualificationRequest
`
`I QualificationDirectiVe
`
`The only significant SME—related addition to MS service qualification is
`that the HLR sends the SME service profile information—in the form -of
`-the IS—41-‘C SMS_OriginationRestrictions and SMS_Termination-
`Restrictions parameters—to the SMS—capable serving system, along
`with the other MS—related profile parameters (see Fig. 13.3).
`
`SME Location Management
`
`Like the associated MS function described in Chap. 10, the SME loca-
`tion management function comprises two components:
`
`1. SME location update processes have the effect of creating or modi-
`fying the SME-related location information in an MS’S temporary
`
`Page 9 of 28
`Page 9 of 28
`
`

`
`292
`
`IS-41 Revision 0 Explained
`
`SMS-capable
`MS
`
`MS r'nit:'ab'y detected
`
`\
`
`REGNOT
`
`
`
`MS detected outside j
`
`limited service area
`
`
`regnot [includes SMS
`service profile information]
`
`Figure 13.3 An example of SMS service qualification using the
`Registrationl\Totif1cation operation.
`
`record in a Visited system and updating the SME location informa-
`tion in an MS’s record in the HLR.
`
`2. SME location cancellation processes have the effect of deleting
`S1VIE—related location information in an MS’s temporary record in
`a visited system and updating the SME location information in an
`MS’s record in the HLR.
`
`The IS—41-C MS—based SME location management processes are
`tightly coupled to the associated processes of the host MS itself; i.e., the
`location of the MS is the location of the SME as well. These procedures
`are described in Chap. 10 and use the following IS-41-C operations:
`
`1. To update location:
`
`I RegistrationNotification
`
`2. To cancel location:
`
`I MSInactive, including the DeregistrationType parameter
`
`I BulkDeregistration
`
`I RegistrationCancel_lation
`
`I Unreliab1eRoamerDataDirectiVe
`
`Note that the serving system also includes a temporary routing
`address—the SlV.[S_Address parameter-—-in the Registration
`Notification Invoke message. This is used for routing short messages
`
`Page 10 of 28
`Page 10 of 28
`
`

`
`Short Message Service Functions
`
`293
`
`to the serving system on their way to the visiting SME. However, We
`consider this address to be functionally associated with short message
`termination (described later in this chapter) rather than the SME
`location update process—someWhat analogous to the serving system’s
`providing a temporary number (i.e., the TLDN) for call termination
`purposes (see Chap. 12). Note also that, based on this approach, the
`MC does not maintain “location information” for the SME. In fact, the
`MC does not need to know the mobile network location for the SME—
`
`merely an address that the MC can use to get a message to the SME’s
`location.
`
`SME State Management
`
`The IS—41-C SME state management function encompasses the
`processes by which the short message termination availability state
`of an MS—based SME is maintained in the HLR.
`
`Note that there is no formal definition of an SME state in IS—41-C.
`
`There are, however, procedures that define how the HLR responds to
`the MC’s requests for short—message termination routing information.
`We use the concept of an SME state, having value either available or
`unavailable, to aid our explanation of these procedures. Generally, if
`the SME’s state is unavailable, the HLR Will indicate this to the MC;
`otherwise, the HLR either vvill provide the MC with the routing infor-
`mation currently stored in its database or will attempt to obtain more
`up-to—date routing information from the serving system. The HLR
`may consider an MS-based SME unavailable because:
`
`1. The MS is not “registered.” When the HLR does not have a valid
`location for the MS, the associated MS—based SME is considered
`unavailable.
`
`2. The MS is registered on an SMS-incapable system.
`
`3. The SME is not authorized for SMS service on the current serving
`system, although the SME is generally authorized for SMS service
`on other systems.
`
`4. The host MS is out of radio contact. The MS may have missed
`autonomous registration events due to a loss of radio contact and
`been designated inactive by the serving system. The SME state in
`this case is system-dependent.
`
`5. The host MS is intentionally inaccessible. The MS may have gone
`into a mode (e.g., sleep mode) whereby it is intentionally inaccessi-
`ble. The SME state in this case is also system-dependent.
`
`Note that the SME state is not necessarily the same as the MS state
`
`Page 11 of 28
`Page 11 of 28
`
`

`
`294
`
`IS-41 Revision C Explained
`
`described in Chap. 10; an inactive MS may be available for short mes-
`sage service deliveries, based on system-dependent algorithms.
`The HLR SME state management process makes use of inforination
`provided by the serving system and HLR location management process-
`es. Generally, the SME state is set to available by the HLR after a suc-
`cessful location update for the MS. Likewise, after a successful location
`cancellation, the HLR sets the SME state to unavailable; the state may
`be reset to available if the location cancellation is nested Within a loca-
`
`tion update process. In this sense, the HLR SME state management
`process makes use of the same operations as the location update and
`location cancellation processes, i.e., RegistrationNotification,
`RegistrationCancellation, MSInactive, BulkDeregistration, and
`UnreliableRoamerDataDirective. Additionally, the SME state may be
`explicitly set to unavailable in the HLR in the following Ways:
`
`1. When the HLR receives a valid IS-4.-1—C REGNOT message includ-
`ing a valid AvailabilityType parameter from the serving system, it
`may set the SlVIE’s state to unavailable (see Fig. 13.4).
`
`2. VVhen the HLR receives a valid IS-41-C MSINACT message from
`the serving system, it may set the SME’s state to unavailable (see
`Fig. 13.5). Note that this message may also result in location cancel-
`lation for the MS if the Deregistration’I‘ype parameteris included.
`
`3. When the HLR receives a valid IS-41-C RoutingRequest RETURN
`RESULT (routreq) message from the serving system, including
`
` SMS-capable
`
`MS
`
`operating in a mode "“*
`where it is inaccessibie
`
`REGNOT [Availabi!ityType] MS initially detected
`
`for call delivery
`
`Figure 13.4 Setting the SME’s state to unavailable by using the
`Registration1\Tot;ification operation.
`
`Page 12 of 28
`Page 12 of 28
`
`

`
`Short Message Service Functions
`
`295
`
`
`
`MSINACT
`
`msinact
`
`MS determined
`to be inactive :>
`
`Figure 13.5 Setting the SME’s state to unavailable by using the
`MSInactive operation.
`
`
`
`SMS-capable
`MS
`
`
`
`
` ROUTREQ
`
`cab’ delivery or
`other request
`€— for MS routing
`information
`
`routreq [ACCDEN=inactive]
`
`Figure 13.6 Setting the SME’s state to unavailable by using the
`RoutingRequest operation.
`
`the AccessDeniedReason parameter set to inactive, the HLR may
`set the SME’s state to unavailable (see Fig. 13.6).
`
`Once set, the SME’s state remains unavailable until a serving sys-
`tem—for which the SME is SMS—auth0rized—sends a valid REGNOT
`
`message to the HLR that includes the SMS_Address parameter but
`does not include the Avai1abi1ityType parameter.
`
`Page 13 of 28
`Page 13 of 28
`
`

`
`296
`
`IS—41 Revision C Explained
`
`Short Message Processing
`
`The IS—41-C short message processing functions encompass the
`processes that enable, restrict, supplement, or otherwise impact an
`SME’s ability to originate and terminate a short message.
`Figure 13.7 illustrates a basic message origination and termination
`sequence for message transfer between two MS—based SlV[Es; SME-A
`is the originator, and SME-B is the destination. The key SMS ele-
`ments that apply to the scenario shown in Fig. 13.7 are:
`
`MS-based
`SME-A
`
`'
`
`MS~based
`SME-B
`
`SME-A's
`serving
`system
`
`SME—B's
`serving
`system
`
`SMD-REC)
`
`
`
`(:3 ___~°:'§'I‘?:E‘_E_":’--
`
`Figure 13.7 A basic message origination and termination sequence for short message
`transfer between two MS~based SMEs: (1) MS-based SME-A sends an air interface mes-
`sage, SMD—REQUEST (SMD~REQ), to the serving system. (2) The serving system routes
`the short message to SN[E—A’s MC, using the IS-41-C SMSDeliveryPoint’IbPoint Invoke
`(SMDPP) message. Each of the SMDPP messages shown in this scenario may be rout-
`ed by using the same SS7 signaling network as is used for routing other IS-41-C mes-
`sages; alternatively, a separate network, based on TCP/IP or some other network proto-
`col, may be employed. ‘When the acknowledgrnent (i.e., the smdpp message) is received
`from the MC, the serving system converts it to an air interface acknowledginent, the
`SMD—ACK message. (3) SME-Ks MC may apply an originating supplementary service to
`the short message (this is not currently defined in IS—41-C); the SNEDPP message is
`then routed to the destination SME’s MC. (4) SME-B's MC may apply a terminating
`supplementary service to the short message (this is not currently defined in IS-41-C);
`the Sll/[DPP message is then routed to the destination SME’s serving system. (5) The
`serving system forwards the short message to the destination SME by using the air
`interface SMDJREQ message. SME~B responds with an automatic acknowledgment
`(SMD-ACK) to signal acceptance of the SMD-REQ message.
`
`Page 14 of 28
`Page 14 of 28
`
`

`
`Short Message Service Functions
`
`29?
`
`I Short message addressing and routing
`
`II Short message barring, i.e., enforcing messaging restrictions
`
`I Applying SMS supplementary services
`
`Short message addressing and routing
`
`Because of the store-and—forvvard nature of the short message trans-
`fer process, messages may take a circuitous path from the originator
`to the final destination. The addressing mechanisms defined in IS--41-
`C provide for this.
`Refer to Fig. 13.7. IS—41-C allows the originating SME (SME—A) to
`provide up to four pieces of address information in the air interface
`(e.g., TDMA or CDMA) equivalent of the SMD-REQ message:
`
`1. Origina10riginatingAddress
`
`2. OriginalDestinationAddI'ess
`
`3. OriginalOriginatingSubaddress
`
`4. OriginalDestinationSubaddress
`
`In general, the OriginalOriginatingAddress information is required
`for message termination but is not necessarily included for message
`origination; likewise, the OriginalDestinati0nAddress information is
`required for message origination but is not necessarily included for
`message termination.
`'
`IS-41—C defines six SMS address parameters for the SMSDelivery-
`PointToPoint Invoke (SMDPP) message:
`
`SMS_OriginalOriginatingAddress
`
`. SMS_OriginalOriginatingSubaddress
`
`91:?-W53?‘
`
`. SlV[S_OriginatingAddress
`
`SMS_Origina1DestinationAddress
`SMS_OriginalDestinationSubaddress
`
`6. SMS_DestinationAddress
`
`The air interface Origina10riginatingSubaddress and Original-
`DestinationSubaddress information is optional and, if provided, is
`passed transparently from end to end by the SMS point—to—point bear-
`er service in the SMS_OriginalOriginatingSubaddress and
`SMS_OriginalDestinationSubaddress parameters, respectively.
`Various numbering formats are supported for the other SMS
`address parameters, including:
`
`I ITU-T E.164 format
`
`Page 15 of 28
`Page 15 of 28
`
`

`
`293
`
`I341 Flevision c: Explained
`
`I ITU—T X.121 format
`
`I Private numbering plan formats
`
`I Internet protocol (IP) address format
`
`A probable scenario is for each l\/IS-based SME in Fig. 13.7 to be
`addressed by its host MS’s MIN, MIN-A (for SME-A) and lVIIN—B (for
`SME—B); the MIN—based addresses are encoded by using the E.164
`format. Table 13.1 summarizes the relationship between the air inter-
`face address values in the SMD-REQ messages and the IS-41-C SMS
`address Values in the SMDPP messages for each step identified in
`Fig. 13.7. For the purposes of illustration, We assume that all possible
`address parameters—with the exception of the subaddress parame-
`ters—are included in each message.
`Most of the mappings between the air interface and IS-41-C
`address elements are straightforward:
`
`I The air interface OriginalOriginatingAddress parameter maps to
`the IS-41-C SMS_OriginalOriginatingAddress parameter.
`
`I The air interface OriginalDestinationAddress parameter maps to
`the IS—41-C SMS_OriginalDestinationAddress parameter.
`
`the values of the SMS_Originati'ngAddress and
`However,
`SMS_DestinationAddress parameters vary depending on the particu-
`lar information flow in Fig. 13.7 and are set to ensure correct routing
`ofthe message:
`'
`
`I In step 2, the SMS_DestinationAddress parameter is set to MIN-A,
`rather than to MIN-B, to route the SMDPP message to SBrlE—A’s MC.
`
`I In step 3, the SMS_OriginatingAddress parameter is set to MIN-A,
`to identify the source of the message as SME—A’s MC; the
`
`TABLE 13.1 Relationship between Air Interface and IS-41-C SMS Address
`Information
`
`SI_V.[S_
`SlVIS__Original
`SMS_
`SMS_Original
`Original
`Original
`Originating Destination Originating Originating Destination Destination
`Address
`Address
`Address
`Address
`Address
`Address
`
`Step
`
`1
`
`2
`
`3
`
`4
`
`5
`
`MIN—A
`
`MIN-B
`
`MIN-A
`
`MIN—B
`
`MIN-A
`
`MIN-A
`
`MIN-A
`
`MIN-A
`
`MIN—A
`
`MIN—B
`
`MIN-B
`
`MIN -B
`
`MIN-B
`
`MIN-A -
`
`MIN—B
`
`MIN-B
`
`Page 16 of 28
`Page 16 of 28
`
`

`
`Short Message Service Functions
`
`299
`
`SMS__DestinationAddress parameter is set to MIN—B, to route the
`SMDPP message to SME—B’s MC.
`-
`‘
`'
`
`I In step 4, the SMS_OriginatingAddress parameter is set to MIN~B,
`rather than to MIN-A, to identify the source‘ of the message as
`SME—B’s MC.
`
`To route the message to SME-A’s MC in step 2, the serving system
`can maintain a table of MIN—to—MC addresses (e.g., MIN to SS7 desti-
`nation point code), as is often done today in IS-41 networks for routing
`IS—41 messages to an MS’s I-ILR. If messages are transported by using
`an SS7 signaling network, the serving system can use the SS7 global
`title translation (GTT) capability. In this case, the serving system cre-
`ates a global title address containing the SMS_DestinationAddress
`parameter value and requests a MIN-to-MC global title translation.
`These same routing possibilities exist for SME—A’s MC in step 3;
`i.e., to route the message to SME-B’s MC, either a fixed MIN-to—MC
`address table or GTT on MIN—B' may be employed, although the latter
`approach is much more likely (i.e., it is far easier to maintain the
`MIN—to—MC routing information in the SST network than in each and
`every accessible MC).
`‘
`'
`
`Terminating short messages to MS-based SMES. Steps 2 and 3 in Fig.
`13.7 involve message routing between fixed points. In step 4, the desti-
`nation SME (SME-B) is mobile; therefore, if it does not already have
`one, SME-B’s MC must get a valid routing address for the system cur-
`rently serving SME—B.
`IS—41—C provides the SMSRequest operation
`specifically for this purpose; this routing requirement also impacts the
`RegistrationNotification operation, as explained below (see Fig. 13.8):
`
`1. When a new SMS—capable MS is detected, the serving system
`sends a RegistrationNotification Invoke (REGNOT) message to the
`HLR. If the serving system is SMS-capable, the message includes the
`SMS_Address parameter that is used to route short messages to the
`serving system for delivery to the MS—based SME. For example, if the
`short—message transport network is SS7—based, the SMS_'Addr,ess
`parameter may contain an SS7 point code and subsystem number;
`when the serving system receives an SMDPP message addressed to
`this point code and subsystem number, it assumes the message is
`intended for a visiting MS—based SME. The specific destination MS is
`identified by the address parameters Within -the SMDPP message. _
`2. When the_MC requires a current routing address foran MS-
`based SME, it sends an SMSRequest Invoke (SMSREQ) message to
`the MS’s HLR.
`
`3. The HLR then makes a decision: Is" the SMS_Ad-dress received in
`step 1 sufficiently current for SMS delivery purposes, or should the
`
`Page 17 of 28
`Page 17 of 28
`
`

`
`300
`
`IS-41 Revision C Explained
`
`MS-based
`SME-A I
`
`. ----------------- --
`
`REGNOT [Ms-A,
`SMS_Address]
`
`fmegsaégreq
`or M -
`(—————
`SMSREQ [MS-A] ®
`smsreq
`® [SMS_Address]
`
`
`
`SMD-REC)
`— - n a u _ . - — _ — _ _ _ » — --
`
`SMDPP [MS-A]
`
`GD
`
`Figure 13.8 Obtaining an SMS routing address for short message termination.
`
`HLR attempt to obtain a new address? If the SlVIS_Address is consid-
`ered valid, the HLR returns it to the MC in the SlVISRequest Return
`Result (smsreq) message; otherwise (not shown in Fig. 13.8), the
`HLR- may send an SMSREQ message to the serving system, request-
`ing an update on the MS’s accessibility and routing information.
`4. The MC uses the SMS_Address to route the SMDPP message to
`the serving system.
`5. The serving system sends the message to the MS-based SME
`identified in the SMDPP message.
`
`SMS delivery pending flag (SMSDPF) management. The MC may become
`aware of an MS—based SME’s unavailability under three circum-
`stances:
`'
`
`1. The HLR returns the Sh/IS_A'ccessDeniedReason (SMSACCDEN)
`parameter in the smsreq message in response to the MC’s request
`for a current routing address for the MS—based SME.
`
`Page 18 of 28
`Page 18 of 28
`
`

`
`Short Message Service Functions
`
`301
`
`2. The serving system returns the SMSACCDEN parameter in the
`smdpp message in response to the MC’s request for delivery of a
`short message to the MS-based SM