1、 TSB-151-B-1 August 2010IP Network Architecture Model for cdma2000 Spread Spectrum Systems NOTICE TIA Engineering Standards and Publications are designed to serve the public interest through eliminating misunderstandings between manufacturers and purchasers, facilitating interchangeability and impro
2、vement 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 co
3、nforming 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 Instit
4、ute (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 regulat
5、ory 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-AD1, formulated under the cognizance of the TIA TR-45 Mobi
6、le (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 i
7、nvolve 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
8、 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 IPR. TIA will neither be a party to discussions of any licensing terms or c
9、onditions, 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 re
10、spects 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 otherwi
11、se), 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
12、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 IPR in the records or publications of the other SSO shall not constitute ide
13、ntification 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
14、 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 PURPOSE OR USE, ITS MERCHANTABILITY AND ITS NONINFRINGEMENT OF ANY THIRD PARTYS
15、 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, RULE OR REGULATION, OR THE SAFETY OR HEALTH EFFECTS OF THE CONTENTS OR ANY PR
16、ODUCT 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, INC
17、IDENTAL 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 FOREGOI
18、NG 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. S.R0037-B v2.0 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 4
19、6 47 48 49 50 51 52 53 54 55 56 57 58 59 60 i IP Network Architecture Model for cdma2000 Spread Spectrum Systems CONTENTS PREFACE iii SCOPE .iv 1. PURPOSE.1 1.1 Informative 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 Abbreviati
20、ons5 2. ARCHITECTURE MODELS 7 2.1 3GPP2 Wireless All-IP Network Architecture Model7 3. ALL-IP NAM DETAILED VIEWS.36 3.1 Planar Views.36 3.3 Mobile Station (MS) View .46 4. SERVICE CREATION AND MANAGEMENT.53 S.R0037-B v2.0 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
21、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 ii LIST OF FIGURES Figure 2.1 3GPP2 Wireless All-IP Network Architecture Model.9 Figure 3.1.1 Access Plane37 Figure 3.1.2 Network Plane .38 Figure 3.1.3 Multimedia Bearer Plane .39 Figure 3.1.4a Multimedia A
22、pplication Server Control Plane 40 Figure 3.1.4b Multimedia SIP Services Control Plane 42 Figure 3.1.4c Multimedia Data Services Control Plane.43 Figure 3.2. Authentication and Authorization View45 Figure 3.3 Mobile Station (MS) View 46 Figure 3.4 Legacy MS Domain Control and Bearer View48 Figure 3.
23、5 Multimedia Domain Control and Bearer View50 Figure 3.6 Domain Interworking Control View52 Figure 4.1 Service Creation and Management53 S.R0037-B v2.0 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 5
24、3 54 55 56 57 58 59 60 iii PREFACE This 3GPP2 Wireless IP Network Architecture Model depicts packet mode operations and gateway information. S.R0037-B v2.0 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
25、52 53 54 55 56 57 58 59 60 iv SCOPE This document recommends the basic 3GPP2 Wireless IP Network Architecture Model. S.R0037-B v2.0 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
26、60 1 1. PURPOSE This document recommends the basic 3GPP2 Wireless IP Network Architecture Model (NAM). 1.1 Informative 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 T
27、S 25.401 “Technical Specification Group Radio Access Network; UTRAN Overall Description (Release 6)”, December 2006. 3GPP TS 23.002 “Technical Specification Group Services and Systems Aspects; Network Architecture (Release 6)”, December 2005. 3GPP2 3GPP2 N.S0008-0, “Circuit Mode Services”, Version 1
28、.0, December 1997. 3GPP2 N.S0011-0, “OTASP and OTAPA”, Version 1.0, January 1999. 3GPP2 X.S0011-001-D, “cdma2000 Wireless IP Network Standard: Introduction”, Version 2.0, November 2008, 3GPP2 X.S0013-000-B, “All-IP Core Network Multimedia Domain: Overview”, Version 1.0, December 2007. 3GPP2 X.S0017-
29、0, “Open Service Access (OSA) Application Programming Interface (API)”, Version 1.0, September 2003. 3GPP2 X.S0022-A, “Broadcast and Multicast Service in cdma2000 Wireless IP Network”, Version 1.0, February 2007. 3GPP2 X.S0025-0, “Legacy MS Domain Step 2”, February, 2006. 3GPP2 X.S0028-000-A, “cdma2
30、000 Packet Data Service: Wireless Local Area Network (WLAN) Interworking Revision A”, Version 1.0, June 2008. 3GPP2 C.S0001-A, “Introduction to cdma2000 Standards for Spread Spectrum Systems Release A”, July 2000. 3GPP2 C.S0001-D, “Introduction to cdma2000 Standards for Spread Spectrum Systems Relea
31、se D”, Version 2.0, September 6, 2005. 3GPP2 C.S0016-C, “Over-the-Air Service Provisioning of Mobile Stations in Spread Spectrum Standards”, Version 2.0, October 32, 2008. 3GPP2 S.S0028-A, “OAM Telecommunications Industry Association; October 2004. EIA/TIA/IS-553-A, Mobile Station - Land Station Com
32、patibility Specification; November 1999. S.R0037-B v2.0 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 2 1.2 Terminology This document uses the following “verbal forms” and “ve
33、rbal form definitions”: 1. “should” and “should not” indicate items of interest that are highly desirable and particularly suitable, without identifying or excluding other items; or (in the negative form) indicate items of interest that are not desirable, are not particularly suitable, or are not re
34、commended 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.3 Assumptions a. The architecture described in this document assumes the following protocols: 1. SIP (Session Initiation Protocol), 2. Rem
35、ote Authentication Dial In User Service (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 in this document, but whether IPv6 should be used exclusively needs to be strongly considered
36、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 Processor). Some of these interfaces are shown in additional diagrams in this document, but not
37、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 entity beyond the Border Router and the CSCF). Some of these interfaces are shown in addition
38、al 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 architecture. While these statements are too general to be treated as specific requirements, they form a
39、 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 the use of IP-based protocols. b. The All-IP core network should be independent of the access n
40、etwork. The core network should have the ability to support multiple access network technologies (e.g., cable, radio access technologies, wireless Local Area Network (LAN), Digital Subscriber Line - DSL). The core network should have the ability to support access networks as they evolve and as new a
41、ccess technologies are identified. This implies that network 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 furt
42、her study. c. A phased migration of existing networks to the All-IP network should be possible. S.R0037-B v2.0 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 3 d. All pertinent
43、 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 than those found in legacy networks. g. The All-IP netwo
44、rk 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. i. The All-IP network architecture and protocols shou
45、ld be scalable. j. The All-IP network architecture development process should aim to identify and reuse solutions from other initiatives within the International Mobile Telecommunications-2000 (IMT-2000) family (especially 3GPP), whenever possible and reasonable. k. The All-IP network should support
46、 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 to all
47、ow 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 legacy t
48、erminals). 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 figures with
49、in 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. S.R0037-B v2.0 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 4 1.6 Definitions This section provides definitions of some terms used within this
