TIA TSB-151-B-2010 IP Network Architecture Model for cdma2000 Spread Spectrum Systems《cdma2000扩谱系统用IP网络体系结构模型》.pdf

《TIA TSB-151-B-2010 IP Network Architecture Model for cdma2000 Spread Spectrum Systems《cdma2000扩谱系统用IP网络体系结构模型》.pdf》由会员分享，可在线阅读，更多相关《TIA TSB-151-B-2010 IP Network Architecture Model for cdma2000 Spread Spectrum Systems《cdma2000扩谱系统用IP网络体系结构模型》.pdf（66页珍藏版）》请在麦多课文档分享上搜索。

1、 IP Network Architecture Model for cdma2000 Spread Spectrum Systems TSB-151-B September 2010NOTICE TIA Engineering Standards and Publications are designed to serve the public interest through eliminating misunderstandings between manufacturers and purchasers, facilitating interchangeability and impr

2、ovement 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 non-member of TIA from manufacturing or selling products not c

3、onforming 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 TIA in accordance with the American National Standards Insti

4、tute (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 safety problems associated with its use or all applicable regula

5、tory 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 Standards Proposal No. 3-0122-RV2, formulated under the cognizance of the TIA TR-45 Mobile

6、(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 any editing process. The use or practice of contents of this Document may invo

7、lve 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 published pending patent applications are claimed and called to TIAs attention, a st

8、atement 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 IPR. TIA will neither be a party to discussions of any licensing terms or cond

9、itions, 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 practices suggested or provided in the Manual have been complied with as respe

10、cts 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 (whether designated as a standard, specification, recommendation or otherwise)

11、, 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 other SSO for IPR or letters of assurance relating to any such Normative Ref

12、erence; (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 IPR in the records or publications of the other SSO shall not constitute identi

13、fication 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 investigate products, designs or services or any claims of compliance with the co

14、ntents 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 PURPOSE OR USE, ITS MERCHANTABILITY AND ITS NONINFRINGEMENT OF ANY THIRD PARTYS IN

15、TELLECTUAL 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, RULE OR REGULATION, OR THE SAFETY OR HEALTH EFFECTS OF THE CONTENTS OR ANY PRODU

16、CT 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 CONTAINED HEREIN, INCLUDING WITHOUT LIMITATION ANY AND ALL INDIRECT, SPECIAL, INCIDE

17、NTAL 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 OTHERWISE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THE FOREGOING

18、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. TSB-151-B All-IP NAM i IP Network Architecture Model for cdma2000 Spread Spectrum Systems CONTENTS LIST OF FIGURES.ii PREFACE iii REVISION HISTOR

19、Y.iii 1. PURPOSE AND SCOPE1 1.1 References 1 1.2 Terminology .2 1.3 Assumptions .2 1.4 Architectural Principles 2 1.5 Legend 3 1.6 Definitions 4 1.7 Abbreviations5 2. ARCHITECTURE MODELS.6 2.1 3GPP2 Wireless All-IP Network Architecture Model6 3. ALL-IP NAM DETAILED VIEWS .35 3.1 Planar Views.35 3.3

20、Mobile Station (MS) View .45 4. SERVICE CREATION AND MANAGEMENT .53 TSB-151-B ii All-IP NAM LIST OF FIGURES Figure 2.1 3GPP2 Wireless All-IP Network Architecture Model.8 Figure 3.1.1 Access Plane36 Figure 3.1.2 Network Plane .37 Figure 3.1.3 Multimedia Bearer Plane .38 Figure 3.1.4a Multimedia Appli

21、cation Server Control Plane 39 Figure 3.1.4b Multimedia SIP Services Control Plane 41 Figure 3.1.4c Multimedia Data Services Control Plane.42 Figure 3.2. Authentication and Authorization View44 Figure 3.3 Mobile Station (MS) View 45 Figure 3.4 Legacy MS Domain Control and Bearer View48 Figure 3.5 Mu

22、ltimedia Domain Control and Bearer View50 Figure 3.6 Domain Interworking Control View52 Figure 4.1 Service Creation and Management53 TSB-151-B All-IP NAM iii PREFACE This 3GPP2 Wireless IP Network Architecture Model depicts packet mode operations and gateway information. REVISION HISTORY Document Da

23、te Description TSB-151 December 2003 Initial publication TSB-151-A July 2007 First revision TSB-151-B August 2007 Second revision Revised primarily to add support for Voice Call Continuity Copyright Telecommunications Industry Association 2007. All rights reserved. This document is subject to change

24、. TSB-151-B iv All-IP NAM (This page intentionally left blank.) TSB-151-B 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 All-IP NAM 1 1. PURPOSE AND SCOPE This document recomme

25、nds the basic 3GPP2 Wireless IP Network Architecture Model. 1.1 References 3GPP 3GPP TS 23.127 - “Technical Specification Group Services and System Aspects; Virtual Home Environment (VHE)/Open Service Access (OSA) (Release 6)”, June 2004. 3GPP TS 25.401 “Technical Specification Group Radio Access Ne

26、twork; UTRAN Overall Description (Release 6)”, December 2004. 3GPP TS 23.002 “Technical Specification Group Services and Systems Aspects; Network Architecture (Release 6)”, December 2004. 3GPP2 3GPP2 N.S0005-0, “Cellular Radiotelecommunications Intersystem Operations”, Version 1.0, July 1997. 3GPP2

27、N.S0008-0, “Circuit Mode Services”, Version 1.0, December 1997. 3GPP2 N.S0011-0, “OTASP and OTAPA”, Version 1.0, January 1999. 3GPP2 N.S0026-A, “Wireless Radio Telecommunication Intersystem Non-Signaling Data Communication DMH, Revision A”, Version 1.0, December 2001. 3GPP2 X.S0011-D, “cdma2000 Wire

28、less IP Network Standard”, Version 1.0, March 2006, 3GPP2 X.S0013-000-A, “All-IP Core Network Multimedia Domain: Overview”, Version 1.0, November 2005,. 3GPP2 X.S0017-0, “Open Service Access (OSA) Application Programming Interface (API)”, Version 1.0, September 2003. 3GPP2 X.S0022-A, “Broadcast and

29、Multicast Service in cdma2000 Wireless IP Network”, Version 1.0, February 2007. 3GPP2 X.S0028-0, “Wireless Local Area Network (WLAN) Interworking”, Version 1.0, March 2007. 3GPP2 C.S0001-A, “Introduction to cdma2000 Standards for Spread Spectrum Systems Release A”, July 2000. 3GPP2 C.S0001-D, “Intro

30、duction to cdma2000 Spread Spectrum Systems Revision D”, Version 1.0, March 2004. 3GPP2 C.S0016-C, “Over-the-Air Service Provisioning of Mobile Stations in Spread Spectrum Standards”, November 2004. 3GPP2 S.S0028-A, “OAM Telecommunications Industry Association; October 2004. EIA/TIA/IS-553-A, Mobile

31、 Station - Land Station Compatibility Specification; November 1999. 1.2 Terminology This document uses the following “verbal forms” and “verbal form definitions”: 1. “should” and “should not” indicate items of interest that are highly desirable and particularly suitable, without identifying or exclu

32、ding other items; or (in the negative form) indicate items of interest that are not desirable, are not particularly suitable, or are not recommended but not prohibited, and 2. “may” and “may not” indicate items of interest that are optional but permissible within the limits of this recommendation. 1

33、.3 Assumptions a. The architecture described in this document assumes the following protocols: 1. SIP (Session Initiation Protocol), 2. RADIUS, 3. DIAMETER, and 4. MOBILE IP (i.e., IPv4 and/or IPv6). b. The use, support, and interoperation of IPv4 and IPv6 in the All-IP network is currently assumed

34、in this document, but whether IPv6 should be used exclusively needs to be strongly considered in ongoing work. c. There are known bearer paths not shown in Figure 2.1 (e.g., bearer paths between the Application Servers and the Border Router, the Application Servers and the Media Resource Function Pr

35、ocessor). Some of these interfaces are shown in additional diagrams in this document, but not numerically labeled. (See Section 3) d. There are known signaling paths not shown in Figure 2.1 (e.g., signaling paths between two Call Session Control Functions (CSCFs), two AAAs, two AGWs, an external SIP

36、 entity beyond the Border Router and the CSCF). Some of these interfaces are shown in additional diagrams in this document, but not numerically labeled. (See Section 3) 1.4 Architectural Principles The statements contained in this section should guide the development of the All-IP network architectu

37、re. While these statements are too general to be treated as specific requirements, they form a set of principles meant to govern the overall development of the All-IP network, they are: a. The All-IP network architecture should be independent of the underlying Layer 1 and Layer 2 protocols through t

38、he use of IP-based protocols. TSB-151-B 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 All-IP NAM 3 b. The All-IP core network should be independent of the access network. The

39、core network should have the ability to support multiple access network technologies (e.g., cable, radio access technologies, wireless LAN, DSL). The core network should have the ability to support access networks as they evolve and as new access technologies are identified. This implies that networ

40、k functions such as call control and service control should be independent of access functions. How this independence is maintained for mobility management and location-based services (which may be dependent on access technology) is for further study. c. A phased migration of existing networks to th

41、e All-IP network should be possible. d. All pertinent interfaces in the All-IP network should be defined in an open manner. e. The All-IP network should promote efficient use of radio interface resources. f. The All-IP network should be capable of supporting reliability levels equal to or better tha

42、n those found in legacy networks. g. The All-IP network should support capabilities for rapid service creation, including service creation by the user and by third parties as well as service profile customization by end users. h. The All-IP network should permit separate signaling and bearer paths.

43、i. The All-IP network architecture and protocols should be scalable. j. The All-IP network architecture development process should aim to identify and reuse solutions from other initiatives within the IMT-2000 family (especially 3GPP), whenever possible and reasonable. k. The All-IP network should s

44、upport Quality of Service equal to or better than that found in legacy networks. l. The All-IP network architecture should be defined in terms of separate functions and clear interfaces such that it is possible to separate bearer from signaling. m. The All-IP network should be functionally designed

45、to allow and encourage reduced complexity and/or resource utilization. n. The All-IP network should support a range of terminal types (e.g., voice-only terminals, IP Multimedia terminals, laptop computers). Not all these terminals may be able to support end-to-end IP capabilities (e.g., 2G and 3G le

46、gacy terminals). o. The All-IP architecture should be designed in such a way that a migration from IPv4 to IPv6 is feasible and that IPv4 and IPv6 based All-IP networks may interoperate. 1.5 Legend This section provides a definition of the different styles of lines and rectangles used in many figure

47、s within this recommendation, as: Dashed Line Signaling interface, Dashed Rectangle Collective Network Entity and Composite Network Entity, Heavy Dashed Line Radio Link (air interface), Solid Line Circuit Bearer or Packet Bearer interface, and Solid Rectangle Network Entity. TSB-151-B 1 2 3 4 5 6 7

48、8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 TSB-151-B 4 All-IP NAM 31 32 1.6 Definitions This section provides definitions of some terms used within this document, as: Quality of Service (QoS)

49、QoS refers to a set of capabilities that a network may provide to a communications session. These capabilities can be specified so that particular applications (e.g., voice, video, streaming audio) fulfill human factors or other requirements with respect to fidelity and performance. QoS in a packet network consists of at least the following components: a. Bandwidth: Data rate (e.g., 64 kbps), b. Delay: End-to-end or roundtrip latency (e.g., 300 ms), c. Jitter: Inter-packet latency variation (e.g., 10 ms), and d. Loss: Rate at which