1、 TIA-41.332-E August 2012Mobile Application Part (MAP) - Voice Feature Scenarios: Remote Feature Control ANSI/TIA-41.332-E-2012 APPROVED: AUGUST 7, 2012 NOTICE TIA Engineering Standards and Publications are designed to serve the public interest through eliminating misunderstandings between manufactu
2、rers 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 preclude any member or n
3、on-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 Publications are adopted by
4、 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 to address all saf
5、ety 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. SP-3-3590.332-RV5-
6、A, formulated under the cognizance of the TIA TR-45 Mobile and Personal Communications Systems Standards, TR-45.8 Subcommittee on Core Networks- Mobile and Personal Communications Standards). Published by TELECOMMUNICATIONS INDUSTRY ASSOCIATION Standards and Technology Department 2500 Wilson Bouleva
7、rd Arlington, VA 22201 U.S.A. PRICE: Please refer to current Catalog of TIA TELECOMMUNICATIONS INDUSTRY ASSOCIATION STANDARDS AND ENGINEERING PUBLICATIONS or call IHS, USA and Canada (1-877-413-5187) International (303-397-2896) or search online at http:/www.tiaonline.org/standards/catalog/ All righ
8、ts reserved Printed in U.S.A. NOTICE OF COPYRIGHT This document is copyrighted by the TIA. Reproduction of these documents either in hard copy or soft copy (including posting on the web) is prohibited without copyright permission. For copyright permission to reproduce portions of this document, plea
9、se contact the TIA Standards Department or go to the TIA website (www.tiaonline.org) for details on how to request permission. Details are located at: http:/www.tiaonline.org/standards/catalog/info.cfm#copyright or Telecommunications Industry Association Technology (b) there is no assurance that the
10、 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 any editing process. The use or practice of contents of this Document may involve the use of intellectual proper
11、ty 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 published pending patent applications are claimed and called to TIAs attention, a statement from the holder thereof is
12、 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 IPR. TIA will neither be a party to discussions of any licensing terms or conditions, which are instead left to
13、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 practices suggested or provided in the Manual have been complied with as respects the Document or its contents.
14、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 (whether designated as a standard, specification, recommendation or otherwise), whether such reference consists
15、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 other SSO for IPR or letters of assurance relating to any such Normative Reference; (ii) TIAs policy of encour
16、agement 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 IPR in the records or publications of the other SSO shall not constitute identification to TIA of a claim of Esse
17、ntial 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 investigate products, designs or services or any claims of compliance with the contents of the Document. ALL WARRAN
18、TIES, 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 PURPOSE OR USE, ITS MERCHANTABILITY AND ITS NONINFRINGEMENT OF ANY THIRD PARTYS INTELLECTUAL PROPERTY RIGHTS. TIA EX
19、PRESSLY 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, RULE OR REGULATION, OR THE SAFETY OR HEALTH EFFECTS OF THE CONTENTS OR ANY PRODUCT OR SERVICE REFERRED TO IN THE D
20、OCUMENT 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 CONTAINED HEREIN, INCLUDING WITHOUT LIMITATION ANY AND ALL INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES (INC
21、LUDING 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 OTHERWISE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THE FOREGOING NEGATION OF DAMAGES IS A FUNDAMENT
22、AL ELEMENT OF THE USE OF THE CONTENTS HEREOF, AND THESE CONTENTS WOULD NOT BE PUBLISHED BY TIA WITHOUT SUCH LIMITATIONS. REVISION HISTORYRevision Date RemarksX.S0004-332-E v1.0 April 2008 Initial publication.X.S0004-332-E v1.012345678910111213141516171819202122232425262728293031323334353637383940414
23、2434445464748495051525354555657585960332-1 INTRODUCTION1 INTRODUCTIONUnless otherwise noted, the scenarios in this section depict features operating individually; i.e.,feature interactions are not considered unless specifically noted.Also, please note that the scenarios in this section do not includ
24、e a complete listing of operationparameters, either in the figures or in the accompanying text descriptions. Parameters areincluded where they are deemed necessary to improve the understanding of the scenario. For acomplete description of the parameters associated with each operation, refer to Parts
25、 540 and550.2 REMOTE FEATURE CONTROLThis section depicts the interactions between network entities in various situations related toautomatic roaming and Remote Feature Control (RFC). These scenarios are for illustrativepurposes only.2.1 Normal RFC Transaction SequenceThis scenario describes a typica
26、l RFC transaction sequence.X.S0004-332-E v1.0REMOTE FEATURE CONTROL123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960332-2Figure 1 Typical RFC Transaction Sequence abcdefghijklmnopqrstuMSC HLR RFC Access System RUIDIR ANNLIST, DGTCC connec
27、t RFC call LOCREQ DGTSDIAL ruidir DGTSDIAL Action on feature request completedconfirmation & prompt for PIN call to RFC DN CONV w/o PERMISSION QUERY w/ PERMISSION DN digits prompt for DN RUIDIR ANNLIST, DGTCC PIN digits ruidir DGTSDIAL RUIDIR ANNLIST, DGTCC confirmation & prompt for FC FC stringruid
28、ir DGTSDIAL RUIDIR ANNLIST, DGTCC LRTfeature identification & prompt for FC user releas ruidir locreq LRTCONV w/o PERMISSION CONV w/ PERMISSION CONV w/ PERMISSION CONV w/o PERMISSION CONV w/ PERMISSION RESPONSE SINGLETCAP TRANSACTION CONV w/o PERMISSION CONV w/ PERMISSION RUDTRUDTLRTLRTRUDTLRTRUDTX.
29、S0004-332-E v1.0123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960332-3 REMOTE FEATURE CONTROLa. An incoming call to the RFC Access DN arrives at the RFC Access System MSC(RFC-MSC).b. The RFC-MSC sends a LOCREQ to the HLR. The HLR, on rece
30、ipt of the LOCREQindicating an RFC call, initiates a user interaction session.c. The HLR sends a RUIDIR to the RFC-MSC.d. On receipt of the RUIDIR, the RFC-MSC turns off the LOCREQ timer and providescall treatment as indicated in the received message. In this case, the treatment is toanswer the call
31、 (i.e., connect the calling party to subsystem capable of user interaction).e. The RFC-MSC prompts the user based on the information in the received RUIDIR andwaits for digits.f. The user responds with its DN digits.g. The RFC-MSC sends a ruidir to the HLR, containing the digits dialed by the user.
32、h. The HLR sends a RUIDIR to the RFC-MSC, confirming the receipt and validation ofthe users DN and prompting for the users PIN.i. The RFC-MSC prompts the user based on the information in the received RUIDIR.j. The user responds with its PIN digits.k. The RFC-MSC sends a ruidir to the HLR, containing
33、 the digits dialed by the user. l. The HLR sends a RUIDIR to the RFC-MSC, confirming the receipt and validation ofthe users PIN and prompting for the users feature request. m. The RFC-MSC prompts the user based on the information in the received RUIDIR.n. The user responds with a feature code string
34、.o. The RFC-MSC sends a ruidir to the HLR, containing the digits dialed by the user. p. The HLR completes processing of the feature request.q. The HLR sends a RUIDIR to the RFC-MSC, indicating the result of the feature requestand prompting for another feature request. r. The RFC-MSC prompts the user based on the information in the received RUIDIR.s. The user releases the call.t. The RFC-MSC sends an empty ruidir to the HLR. u. The HLR terminates the user interaction session and sends a locreq to the RFC-MSC.
