1、 TIA-41.323-E September 2007Mobile Application Part (MAP) Voice Feature Scenarios: Call Waiting ANSI/TIA-41.323-E-2007 APPROVED: JULY 12, 2007 REAFFIRMED: JANUARY 10, 2013 NOTICE TIA Engineering Standards and Publications are designed to serve the public interest through eliminating misunderstanding
2、s between manufacturers and purchasers, facilitating interchangeability and improvement of products, and assisting the purchaser in selecting and obtaining with minimum delay the proper product for their particular need. The existence of such Standards and Publications shall not in any respect precl
3、ude any member or non-member of TIA from manufacturing or selling products not conforming to such Standards and Publications. Neither shall the existence of such Standards and Publications preclude their voluntary use by Non-TIA members, either domestically or internationally. Standards and Publicat
4、ions are adopted by TIA in accordance with the American National Standards Institute (ANSI) patent policy. By such action, TIA does not assume any liability to any patent owner, nor does it assume any obligation whatever to parties adopting the Standard or Publication. This Standard does not purport
5、 to address all safety problems associated with its use or all applicable regulatory requirements. It is the responsibility of the user of this Standard to establish appropriate safety and health practices and to determine the applicability of regulatory limitations before its use. (From Project No.
6、 3-3590.323-RV5-RF1, formulated under the cognizance of the TIA TR-45 Mobile (b) there is no assurance that the Document will be approved by any Committee of TIA or any other body in its present or any other form; (c) the Document may be amended, modified or changed in the standards development or a
7、ny editing process. The use or practice of contents of this Document may involve the use of intellectual property rights (“IPR”), including pending or issued patents, or copyrights, owned by one or more parties. TIA makes no search or investigation for IPR. When IPR consisting of patents and publish
8、ed pending patent applications are claimed and called to TIAs attention, a statement from the holder thereof is requested, all in accordance with the Manual. TIA takes no position with reference to, and disclaims any obligation to investigate or inquire into, the scope or validity of any claims of I
9、PR. TIA will neither be a party to discussions of any licensing terms or conditions, which are instead left to the parties involved, nor will TIA opine or judge whether proposed licensing terms or conditions are reasonable or non-discriminatory. TIA does not warrant or represent that procedures or p
10、ractices suggested or provided in the Manual have been complied with as respects the Document or its contents. If the Document contains one or more Normative References to a document published by another organization (“other SSO”) engaged in the formulation, development or publication of standards (
11、whether designated as a standard, specification, recommendation or otherwise), whether such reference consists of mandatory, alternate or optional elements (as defined in the TIA Engineering Manual, 4thedition) then (i) TIA disclaims any duty or obligation to search or investigate the records of any
12、 other SSO for IPR or letters of assurance relating to any such Normative Reference; (ii) TIAs policy of encouragement of voluntary disclosure (see Engineering Manual Section 6.5.1) of Essential Patent(s) and published pending patent applications shall apply; and (iii) Information as to claims of IP
13、R in the records or publications of the other SSO shall not constitute identification to TIA of a claim of Essential Patent(s) or published pending patent applications. TIA does not enforce or monitor compliance with the contents of the Document. TIA does not certify, inspect, test or otherwise inve
14、stigate products, designs or services or any claims of compliance with the contents of the Document. ALL WARRANTIES, EXPRESS OR IMPLIED, ARE DISCLAIMED, INCLUDING WITHOUT LIMITATION, ANY AND ALL WARRANTIES CONCERNING THE ACCURACY OF THE CONTENTS, ITS FITNESS OR APPROPRIATENESS FOR A PARTICULAR PURPO
15、SE OR USE, ITS MERCHANTABILITY AND ITS NONINFRINGEMENT OF ANY THIRD PARTYS INTELLECTUAL PROPERTY RIGHTS. TIA EXPRESSLY DISCLAIMS ANY AND ALL RESPONSIBILITIES FOR THE ACCURACY OF THE CONTENTS AND MAKES NO REPRESENTATIONS OR WARRANTIES REGARDING THE CONTENTS COMPLIANCE WITH ANY APPLICABLE STATUTE, RUL
16、E OR REGULATION, OR THE SAFETY OR HEALTH EFFECTS OF THE CONTENTS OR ANY PRODUCT OR SERVICE REFERRED TO IN THE DOCUMENT OR PRODUCED OR RENDERED TO COMPLY WITH THE CONTENTS. TIA SHALL NOT BE LIABLE FOR ANY AND ALL DAMAGES, DIRECT OR INDIRECT, ARISING FROM OR RELATING TO ANY USE OF THE CONTENTS CONTAIN
17、ED HEREIN, INCLUDING WITHOUT LIMITATION ANY AND ALL INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES (INCLUDING DAMAGES FOR LOSS OF BUSINESS, LOSS OF PROFITS, LITIGATION, OR THE LIKE), WHETHER BASED UPON BREACH OF CONTRACT, BREACH OF WARRANTY, TORT (INCLUDING NEGLIGENCE), PRODUCT LIABILITY OR
18、OTHERWISE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THE FOREGOING NEGATION OF DAMAGES IS A FUNDAMENTAL ELEMENT OF THE USE OF THE CONTENTS HEREOF, AND THESE CONTENTS WOULD NOT BE PUBLISHED BY TIA WITHOUT SUCH LIMITATIONS. TIA-41.323-EMobile Application Part (MAP) - Voice Feature Scenarios:
19、 Call WaitingREVISION HISTORYCopyright Telecommunications Industry Association 2007. All rights reserved.This document is subject to change.Revision Date RemarksTIA-41.323-E January 2007 Initial publication.TIA-41.323-EiiThis page is left blank intentionally.TIA-41.323-E12345678910111213141516171819
20、2021222324252627282930313233343536373839404142434445464748495051525354555657585960323-1323INTRODUCTIONPART 3231 INTRODUCTIONUnless otherwise noted, the scenarios in this Part depict features operating individually; i.e.,feature interactions are not considered unless specifically noted. The scenarios
21、 in this Part do not include a complete listing of operation parameters, either in thefigures or in the accompanying text descriptions. Parameters are included where they aredeemed necessary to improve the understanding of the scenario. For a complete description ofthe parameters associated with eac
22、h operation, refer to Parts-540 and -550.2 Call TransferNo feature-specific intersystem operations are required for the Call Transfer feature.3 Call WaitingThis section depicts the interactions between network entities in various situations related toautomatic roaming and Call Waiting (CW). These sc
23、enarios are for illustrative purposes only.3.1 CW Demand Activation or De-ActivationThe information flows required for the demand activation or de-activation of CW by anauthorized MS are described in Part-311 Section 2.1.TIA-41.323-ECall Waiting1234567891011121314151617181920212223242526272829303132
24、33343536373839404142434445464748495051525354555657585960323323-23.2 CW Demand Cancellation with CallThis scenario describes the demand cancellation of CW by an authorized MS. The cancellationoccurs as part of the call request.a. A call origination and dialed digits are received by the Serving MSC. D
25、uring analysisof the dialed digits, the Serving MSC detects a feature code string. The feature codestring also contains a terminating address (e.g. phone number). b. The dialed digits are included in a FEATREQ and sent from the Serving MSC to theHLR associated with the MS. The Serving MSC also inclu
26、des theOneTimeFeatureIndicator parameter if any of its status bits are set (i.e., if any specialfeature processing is active for the call).c. The HLR determines that the dialed digits include a Cancel Call Waiting (CCW)request and that the MS is authorized for this service and sends a featreq to the
27、Serving MSC. The featreq includes call routing information in the TerminationListparameter (e.g. based on the Termination Address extracted from the dialed digits). Italso includes the OneTimeFeatureIndicator parameter, with an indication that CallWaiting is de-activated for the call.d. The Serving
28、MSC stores the CCW OneTimeFeatureIndicator, de-activates CW, andprovides treatment to the served MS as indicated in the featreq. In this case, thetreatment is to apply feature confirmation, and.Figure 1 CW Demand Cancellation with CallAdditional Parameters Usage TypeOTFI (Current Call) Indicates spe
29、cial feature processing active for duration of call in progress.OAdditional Parameters Usage TypeOTFI (Current Call) Modify feature processing for duration of call in progress = De-activate CW.RabcdefMS MSC HLR Serving System*FC0+#+TA+ SENDFEATREQ DGTSDIAL, OTFI featreq OTFI, TERMLIST feature confir
30、mation call setup call release FRRT TIA-41.323-E123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960323-3323Call Waitinge. .set up the call using the call routing information in the TerminationList parameter.f. The CCW OneTimeFeatureIndicato
31、r (and, thus, Cancel Call Waiting) remains activeuntil the end of the call, at which time it is discarded by the Serving MSC. The callwaiting activation status then returns to its pre-call condition.3.3 CW Demand Cancellation (during call)This scenario describes the demand cancellation of CW by an a
32、uthorized MS. The cancellationoccurs during a call.a. A call involving the served MS is in progress.b. Dialed digits are received by the Serving MSC. During analysis of the dialed digits,the Serving MSC detects a feature code string.c. The dialed digits are included in a FEATREQ and sent from the Se
33、rving MSC to theHLR associated with the MS. The Serving MSC also includes theOneTimeFeatureIndicator parameter if any of its status bits are set (i.e., if any specialfeature processing is active for the call).d. The HLR detects the authorized Cancel Call Waiting (CCW) request and sends afeatreq to t
34、he Serving MSC. The featreq includes theOneTimeFeatureIndicator parameter, with an indication that Call Waiting is de-activated for the call.Figure 2 CW Demand Cancellation (during call)Additional Parameters Usage TypeOTFI (Current Call) Indicates special feature processing active for duration of ca
35、ll in progress.OAdditional Parameters Usage TypeOTFI (Current Call) Modify feature processing for duration of call in progress = De-activate CW.RabcdefMS MSC HLR Serving System*FC0+SEND FEATREQ DGTSDIAL, OTFI FRRTfeatreq OTFI feature confirmation call in progress call release TIA-41.323-ECall Waitin
36、g123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960323323-4e. The Serving MSC stores the CCW OneTimeFeatureIndicator, de-activates CW, andprovides treatment to the served MS as indicated in the ACTCODE parameter. In thiscase, the treatment
37、 is to apply feature confirmation.f. The CCW OneTimeFeatureIndicator remains active until the end of the call, at whichtime it is discarded by the Serving MSC. The call waiting activation status then returnsto its pre-call condition.TIA-41.323-E1234567891011121314151617181920212223242526272829303132
38、33343536373839404142434445464748495051525354555657585960323-5323Call Waiting3.4 CW InvocationThis scenario describes call delivery to an MS that is currently engaged in a call but has callwaiting active.a. A call involving the served MS is in progress.b. A call origination and the dialed MS address
39、digits (i.e., directory number) are receivedby the Originating MSC.c. The Originating MSC sends a LOCREQ to the HLR associated with the MS; thisassociation is made through the dialed MS address digits (which may not be the MIN).d. If the dialed MS address digits are assigned to a legitimate subscrib
40、er, the HLR sendsa ROUTREQ to the VLR where the MS is registered.e. The VLR then forwards the ROUTREQ to the current Serving MSC.f. In reaction to the ROUTREQ, the Serving MSC checks its internal data structures anddetermines that the MS is busy in another call but has CW active (due to MSs profileo
41、r indicated by the OTFI). Therefore, the Serving MSC allocates a TLDN (TemporaryLocal Directory Number) and returns this information to the VLR in the routreq.g. The VLR forwards the routreq to the HLR.Figure 3 CW InvocationabcdefghijMSC VLR MS Originating SystemHLR MSC calll setup locreq TERMLIST,
42、REDIND routreq TLDN call in progress ROUTREQ MSID, OTFI LOCREQ DGTSDIAL call origination Serving SystemROUTREQ MSID, OTFI routreq TLDN call waiting alert TLDNATRRTLRT RRTTIA-41.323-ECall Waiting1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575
43、85960323323-6h. When the routreq is received by the HLR, it returns a locreq to the OriginatingMSC. The locreq includes routing information in the form of the TerminationListparameter, along with an indication of the reason for extending the incoming call(i.e., for CD) in the DMH_RedirectionIndicato
44、r parameter.i. Upon receiving the locreq, the Originating MSC sets up a voice path to the ServingMSC using the protocols defined by the interconnection method.j. When the (second) inter-MSC call is received at the Serving MSC, the MS receivesnormal call waiting treatment. Note that the Originating M
45、SC and the HLR cannotdistinguish this scenario from that of Part-321 Section 2.2.TIA-41.323-E123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960323-7323Call Waiting3.5 CW Interaction after HandoffThis scenario describes a busy, authorized M
46、S for which CW is active, after intersystem handoffof the MS. This scenario illustrates the particular case in which out-of-band signaling is used toprovide the call waiting notification to the served MS. a. A call involving the served MS is in progress.b. A call origination with a dialed MS address
47、 digits (i.e., directory number) is receivedby the Originating MSC.c. The Originating MSC sends a LOCREQ to the MSs HLR.d. The HLR constructs a ROUTREQ, and sends it to the VLR where the MS is registered.e. The VLR forwards the ROUTREQ to the current Serving MSC. Figure 4 CW Interaction After Handof
48、fabcdefghijklmnMSC VLR MSC MS Originating System Serving System HLR MSC call origination routreq TLDN locreq TERMLIST, REDIND inter-MSC call setup INFOFWD ANNLIST ROUTREQ MSID LOCREQ DGTSDIAL MSC Anchor System Tandem System ROUTREQ MSID routreq TLDN call waiting notification infofwd infofwd call in
49、progress INFOFWD ANNLIST TLDNATRRTLRT RRTIFT IFTTIA-41.323-ECall Waiting123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960323323-8f. In reaction to the ROUTREQ, the Serving MSC checks its internal data structures anddetermines that the MS is busy in another call but has CW active. Therefore, theServing MSC allocates a TLDN (Temporary Local Directory Number) and returns thisinformation to the VLR in the routreq. The Serving MSC stores the receivedinformation.g. The VLR sends the rou
