ImageVerifierCode 换一换
格式:PDF , 页数:32 ,大小:3.53MB ,
资源ID:438458      下载积分:10000 积分
快捷下载
登录下载
邮箱/手机:
温馨提示:
如需开发票,请勿充值!快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝扫码支付 微信扫码支付   
注意:如需开发票,请勿充值!
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【http://www.mydoc123.com/d-438458.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(ANSI TIA-41.321-E-2007 Mobile Application Part (MAP) C Voice Feature Scenarios Call Delivery《移动应用部分(MAP).声音特点想定 呼叫转移》.pdf)为本站会员(deputyduring120)主动上传,麦多课文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知麦多课文库(发送邮件至master@mydoc123.com或直接QQ联系客服),我们立即给予删除!

ANSI TIA-41.321-E-2007 Mobile Application Part (MAP) C Voice Feature Scenarios Call Delivery《移动应用部分(MAP).声音特点想定 呼叫转移》.pdf

1、TIA-41.321-E September 2007Mobile Application Part (MAP) Voice Feature Scenarios: Call Delivery ANSI/TIA-41.321-E-2007 APPROVED: JULY 11, 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.321-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.321-EMobile Application Part (MAP) - Voice Feature Scenarios:

19、 Call DeliveryREVISION HISTORYCopyright Telecommunications Industry Association 2007. All rights reserved.This document is subject to change.Revision Date RemarksTIA-41.321-E January 2007 Initial publication.TIA-41.321-EiiThis page is left blank intentionally.TIA-41.321-E1234567891011121314151617181

20、92021222324252627282930313233343536373839404142434445464748495051525354555657585960321-1 Call Delivery1 Call DeliveryThis section depicts the interactions between network entities in various situations related toautomatic roaming and Call Delivery (CD). These scenarios are informative.1.1 CD Demand

21、Activation or De-ActivationFor a description of the demand activation or deactivation of CD by an authorized MS, seePart 311 Section 2.1.1.2 CD Invocation to an Idle MS on Another MSCThis scenario describes call delivery to an MS that is outside the serving area of the MSC wherethe call originates.

22、MSCs in the functional model described in NAM contain switching functionsTIA-41.321-ECall Delivery123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960321-2only and must interact with their associated HLR and VLR to obtain database informatio

23、n foran MS; in a real application, the HLR/VLR functions may be integrated with the MSC.a. A call origination and the dialed MS address digits (i.e., directory number) are receivedby the Originating MSC.b. The Originating MSC sends a LOCREQ to the HLR associated with the MS; thisassociation is made

24、through the dialed MS address digits (which may not be the MIN).c. If the dialed MS address digits are assigned to a legitimate subscriber, the HLR sendsa ROUTREQ to the VLR where the MS is registered.d. The VLR then forwards the ROUTREQ to the current Serving MSC. Note that the MSmay have roamed wi

25、thin the domain of the Serving VLR and reported its new locationto that VLR (via the new Serving MSC); the Serving VLR may not have reported thischange in location to the HLR.In reaction to the ROUTREQ, the Serving MSC consults its internal data structures to determine if the MS is already engaged i

26、n a call on this MSC. In this scenario, since the MS is idle, we are assuming that the MS is not known to the Serving MSC.e. The Serving MSC may then obtain the service profile of the MS from its VLR bysending it a QUALREQ.Figure 1 CD Invocation to an Idle MS on Another MSC abcdefghijklMSCVLRHLR MSC

27、call origination Serving System routreq TLDN Originating System ROUTREQ MSID QUALREQ routreq TLDN LOCREQ DGTSDIAL call setup QUALREQ qualreq qualreq LRT RRT RRTTLDNAT QRTlocreq TERMLIST, REDIND QRTLOCREQ DGTSDIAL TIA-41.321-E123456789101112131415161718192021222324252627282930313233343536373839404142

28、434445464748495051525354555657585960321-3 Call DeliveryThis step can be eliminated if the service profile is obtained by the Serving MSC prior to the termination attempt (e.g., when the MS registers). Subsequent scenarios do not explicitly show this step; they assume that the Serving MSC either alre

29、ady has the profile available when the ROUTREQ arrives or obtains the profile in a manner similar to that shown here.f. If the MS is unknown to the VLR or if the information requested by the MSC is notavailable at the VLR, the VLR sends a QUALREQ to the HLR associated with the MS.g. The HLR sends a

30、qualreq to the VLR.h. The VLR sends a qualreq to the Serving MSC.i. The Serving MSC allocates a TLDN (Temporary Local Directory Number) and returnsthis information to the VLR in the routreq.j. The VLR sends the routreq to the HLR.k. When the routreq is received by the HLR, it returns a locreq to the

31、 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_RedirectionIndicator parameter.l. The Originating MSC establishes a voice path to the Serving MSC usin

32、g existinginterconnection protocols (e.g. SS7) and the routing information specified in thelocreq.TIA-41.321-ECall Delivery123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960321-41.3 CD Invocation to an Idle, Local MSThis scenario describes

33、 CD invocation to an idle MS that is served by the MSC where the calloriginates.a. A call origination and the dialed MS address digits (i.e., directory number) are receivedby the Originating MSC.b. The Originating MSC sends a LOCREQ to the HLR associated with the MS; thisassociation is made through

34、the dialed MS address digits (which may not be the MIN).c. If the dialed MS address digits are assigned to a legitimate subscriber and the HLRdetermines that the subscriber is currently served by the Originating MSC, the HLRsends a locreq to the Originating MSC.d. The Originating MSC, recognizing it

35、self as the Serving MSC via the MSCIDparameter contained in the TerminationList parameter, then attempts to terminate thecall to the MS identified in the locreq.Figure 2 CD Invocation to an Idle, Local MSabcdMSC MS HLROriginating SystemLOCREQ DGTSDIAL call termination call origination locreq TERMLIS

36、T, REDIND LRTTIA-41.321-E123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960321-5 Call Delivery1.4 CD Invocation to a Busy MSThis scenario describes CD invocation to an MS that is busy in a call outside of the serving areawhere the call ori

37、ginates.a-d. Same as CD, see Part 321, sec. 1.2, Steps a-d.e. In reaction to the ROUTREQ, the Serving MSC checks its internal data structures anddetermines that the MS is busy in another call. The status of the MS is returned to theVLR by the Serving MSC via the AccessDeniedReason parameter in the r

38、outreq.1f. The VLR sends the routreq to the HLR.g. The HLR returns the busy status to the Originating MSC in the locreq.h. The Originating MSC then returns a busy indication to the calling party.Figure 3 CD Invocation to a Busy MS1In some environments it may be necessary to return a TLDN in addition

39、 to, or in place of, the MS status.Handling of these situations is not illustrated by the above figure.abcdefghMSCVLR HLR MSC call origination Serving System ROUTREQ MSID locreq ACCDEN=Busy Originating System ROUTREQ MSID routreq ACCDEN=Busy LOCREQ DGTSDIAL busy indication routreq ACCDEN=Busy LRT RR

40、TRRT TIA-41.321-ECall Delivery123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960321-61.5 CD Invocation with No Page Response or No AnswerThis scenario describes CD invocation to an MS when no page response or no answer isreceived by the Se

41、rving MSC after TLDN call arrival.a-d. Same as CD, see Part 321, sec. 1.2, Steps a-d.e-h. Same as CD, see Part 321, sec. 1.2, Steps i-l, respectively.i. Either the MS fails to respond to the page or does not answer after alerting.j. The Serving MSC routes the call to an appropriate tone or announcem

42、ent.k. The call is then disconnected using the protocols defined by the interconnectionmethod.Figure 4 CD Invocation with No Page Response or No AnswerabcdefghijkMSCVLR HLR MSC call origination Serving System ROUTREQ MSID locreq TERMLIST, REDIND Originating System ROUTREQ MSID routreq TLDN LOCREQ DG

43、TSDIAL call setuproutreq TLDN page or answer timeoutannouncementcall release call release LRT RRT RRT TIA-41.321-E123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960321-7 Call Delivery1.6 CD Invocation to an Inaccessible MSThis scenario des

44、cribes CD invocation to an MS that is inaccessible due to: CD inactive, MS inactive MS unregistered.a-b. Same as CD, see Part 321, sec. 1.2, Steps a-b.c. The HLR determines that the MS is not accessible (e.g., CD is inactive, MS is inactive,or MS is not registered). The HLR returns a locreq to the O

45、riginating MSC includingthe reason for denying access in the AccessDeniedReason parameter.d. The Originating MSC provides treatment to the served MS as implied by theAccessDeniedReason parameter and, if present, the AnnouncementList parameter. Inthis case, the treatment is to provide call refusal tr

46、eatment.e. The Originating MSC releases the call.Figure 5 CD Invocation to an Inaccessible MSabcdeMSC HLROriginating SystemLOCREQ DGTSDIAL call refusal treatment locreq ACCDEN, ANNLIST call origination call release LRT TIA-41.321-ECall Delivery12345678910111213141516171819202122232425262728293031323

47、3343536373839404142434445464748495051525354555657585960321-81.7 CD Invocation with Intersystem PagingThis scenario describes CD invocation involving intersystem paging from the serving system toborder systems. Intersystem paging may help overcome location uncertainties in border systemTIA-41.321-E12

48、3456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960321-9 Call Deliveryareas allowing paging to be performed in border systems and by performing call routing towardsthe system where the subscriber is found.a-d. Same as CD, see Part 321, sec. 1

49、.2, Steps a-d.e-f. Before initiating local paging, at the time of local page initiation or after first page time-out, the Serving MSC may send an ISPAGE to one or more bordering MSCs according to its “topographical map” with a parameter indicating an area where the Figure 6 CD Invocation with Intersystem PagingabcdefghijklmnopqrstuvwxMSC VLR VLR MSCOriginating System Border System HLR MSC call origination LOCREQ DGTSDIAL ISPAGE PageIndicator QUALREQ ispage TLDN, EXTMSCID(Border) ROUTREQ MSID page request QUALREQ q

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1